Re: Allowing PortGroups to bump port revision

[Joshua Root]

On 2018-1-13 13:13 , Clemens Lang wrote:
> Hi,
> 
> On Fri, Jan 12, 2018 at 03:30:50PM -0800, Jeremy Huddleston Sequoia wrote:
>> In https://trac.macports.org/ticket/54744, we've been pondering adding
>> a PortGroup to allow concurrent installation of multiple providers of
>> the OpenSSL API (eg: openssl, libressl, libressl-devel) and allow
>> ports to specify which they are compatible with.
>>
>> It occurred to me that it would be nice if we could update the
>> PortGroup when one of the dependencies changed their dylib id rather
>> than revbumping all ports.  Is this something anyone else has
>> considered?
> 
> I'd love to use this feature for updates of GHC. For every new version
> of GHC, libraries built with it are installed in a new directory and get
> a new ID, which means that I have to find and revbump every haskell port
> with such an update.
> 
> Unfortunately ports are only re-indexed when their mtime changes, so
> while you could just set revision (or epoch, or some other variable) in
> a PortGroup, that would still not lead to those ports getting reindexed.
> 
> We'd have to keep a map from PortGroup to Portfiles that use this
> PortGroup to modify portindex to correctly re-index ports when a
> PortGroup changes; note that this might also take quite long. I can
> imagine changing the GitHub PortGroup would lead to index update times
> of more than 10 minutes. :(

If I understand the problem correctly, it seems like a better solution
would be maintaining a database of linkage. You could then look up which
dylibs a port provides and which ports link against them. The rev-bump
scripting already exists as mentioned earlier. Automated alerts when a
commit causes broken linking could also be done.

We could also consider adding an archive revision. This would just
increase whenever rev-upgrade is needed, and cause the buildbot to build
a new archive. Clients could probably virtually ignore it and just rely
on rev-upgrade finding the broken linking. That way nobody has to
reinstall anything that isn't broken (e.g. if their chosen variants
don't use the changed dylib.)

- Josh

Redistributable binaries for 10.5 or 10.6 from C++11 sources

[Mojca Miklavec]

Hi.

I would like to build and distribute some poppler-based command-line
utilities (I would compile them with compiler from MacPorts, but
distribute it to users with MacPorts).

I could use either gcc or clang, but what are the options to make that
work for 10.5/10.6?
Can libc++ or libstdc++ be linked with something like
@executable_path/../libl/libstdc++.dylib and then distributed
alongside the binaries? Can lib[std]c++ be built statically (I have an
impression that's not possible on mac)? What consequences would such
packages have for, say, users of 10.13 trying to run such binaries?

If this is not feasible, I would target 10.7, but if it's feasible, I
would optionally try to get it working also for PPC. I'm willing to
spend a bit of extra effort, but I have no experience with
transferring the binaries to a computer without lib[std]c++ libraries
yet. The target audience would be users of any system from the minimum
supported version up to 10.10. There will be another version for those
using a supported system compiled on 10.11.

Thank you,
Mojca

Re: Allowing PortGroups to bump port revision

[Clemens Lang]

Hi,

On Fri, Jan 12, 2018 at 03:30:50PM -0800, Jeremy Huddleston Sequoia wrote:
> In https://trac.macports.org/ticket/54744, we've been pondering adding
> a PortGroup to allow concurrent installation of multiple providers of
> the OpenSSL API (eg: openssl, libressl, libressl-devel) and allow
> ports to specify which they are compatible with.
> 
> It occurred to me that it would be nice if we could update the
> PortGroup when one of the dependencies changed their dylib id rather
> than revbumping all ports.  Is this something anyone else has
> considered?

I'd love to use this feature for updates of GHC. For every new version
of GHC, libraries built with it are installed in a new directory and get
a new ID, which means that I have to find and revbump every haskell port
with such an update.

Unfortunately ports are only re-indexed when their mtime changes, so
while you could just set revision (or epoch, or some other variable) in
a PortGroup, that would still not lead to those ports getting reindexed.

We'd have to keep a map from PortGroup to Portfiles that use this
PortGroup to modify portindex to correctly re-index ports when a
PortGroup changes; note that this might also take quite long. I can
imagine changing the GitHub PortGroup would lead to index update times
of more than 10 minutes. :(

-- 
Clemens

Re: Allowing PortGroups to bump port revision

[René J . V . Bertin]

On Friday January 12 2018 15:30:50 Jeremy Huddleston Sequoia wrote:

> It occurred to me that it would be nice if we could update the PortGroup when 
> one of the dependencies changed their dylib id rather than revbumping all 
> ports.  Is this something anyone else has considered?

I don't think I really understand what you mean, could you give an example?

If you mean something akin to setting the `version` in a PortGroup, this 
doesn't always work reliably. I have such a PG and it seems there are always 
some ports that don't show up in `port outdated` after I bump the version 
(presumably because PortIndex can fail to detect that a port imports certain 
PGs).

If you do think of setting a revision in the PortGroup: how do you propose 
coping with the fact that dependents may set their own revision, typically 
after including the PortGroup?

R.

Re: Allowing PortGroups to bump port revision

[Daniel J. Luke]

On Jan 12, 2018, at 6:30 PM, Jeremy Huddleston Sequoia  
wrote:
> In https://trac.macports.org/ticket/54744, we've been pondering adding a 
> PortGroup to allow concurrent installation of multiple providers of the 
> OpenSSL API (eg: openssl, libressl, libressl-devel) and allow ports to 
> specify which they are compatible with.
> 
> It occurred to me that it would be nice if we could update the PortGroup when 
> one of the dependencies changed their dylib id rather than revbumping all 
> ports.  Is this something anyone else has considered?

I've suggested this in the past (for p5 ports, specifically) that we could 
(ab)use revision to avoid having to rev-bump many ports. (I suggested we use a 
date-string so that individual ports that used the port-group could still set a 
higher revision if they needed to - but we'd still probably have to work out 
something to handle the case where a port wanted to set a revision and then 
later we wanted to update the revision in the portgroup). 

IIRC Ryan /hated/ that idea.

Alternatively, we could add something to base to let us specify this kind of 
dependency (which would be useful).

-- 
Daniel J. Luke

Allowing PortGroups to bump port revision

[Jeremy Huddleston Sequoia]

In https://trac.macports.org/ticket/54744, we've been pondering adding a 
PortGroup to allow concurrent installation of multiple providers of the OpenSSL 
API (eg: openssl, libressl, libressl-devel) and allow ports to specify which 
they are compatible with.

It occurred to me that it would be nice if we could update the PortGroup when 
one of the dependencies changed their dylib id rather than revbumping all 
ports.  Is this something anyone else has considered?

--Jeremy

Re: a no-homepage homepage for ports with dead homepages

[Ken Cunningham]

On 2018-01-12, at 2:12 AM, Rainer Müller wrote:
> 
> Nit pick: I would have called it NoHomepage (small letter p), as the
> compound form seems to be more common than two words and it is used this
> way as Portfile option and in the wiki page itself.


Done. I always seem to want to CamelCase syllables. 


Last thing is master_sites assuming we want to keep the port, but if 
upstream is gone and we have the distfiles mirrored,

leave master_sites pointing nowhere, or make it 

https://distfiles.macports.org/portname



or is that some kind of circular nightmare?

Re: 10.13 builder on our BuildBot is failing

[Vincent Habchi]

Ryan,

> as suggested in the thread. Thanks for pointing me toward it!

Glad to know it worked.

Have a great day!

GSoC 2018 Application

[Umesh Singla]

Hi,

Following the conversation on the dev mailing list, I have assumed the role
of organization administrator and Jackson Isaac as backup administrator and
a potential mentor for now.

I have registered MacPorts for participating in GSoC this year and
submitted the initial version of the application from MacPorts side on
GSoC'18 [0] website, in coordination with Jackson.

The corresponding pages of our Trac have been updated.

The application questionnaire [1] and the ideas page [2] have been modified
to include this year's dates and other relevant information.

Please feel free to suggest any improvements.

@Jackson: I invited you to be a backup admin from GSoC's website. Please
check and approve.

[0]: https://summerofcode.withgoogle.com/
[1]: https://trac.macports.org/wiki/SummerOfCodeOrgApplication
[2]: https://trac.macports.org/wiki/SummerOfCode

Regards,
Umesh Singla

On Mon, Jan 8, 2018 at 1:13 PM, Mojca Miklavec  wrote:

> Hi,
>
> The GSOC 2018 application period for organisations is now open,
> deadline for applying in January 23rd.
>
> I hope we are going to participate this year as well?
> If so, it would be about time to come up with additional ideas and
> clean up the ideas page.
>
> Mojca
>

Re: 10.13 builder on our BuildBot is failing

[Ryan Schmidt]

On Jan 11, 2018, at 11:11, Vincent Habchi wrote:

> That being said, there was a hack listed somewhere in the messages that 
> consisted of booting single user and touching a driver. Did you try that? It 
> can’t do any harm to try and test.

It was fixed with:

sudo touch /System/Library/Extensions
sudo kextcache -u /

as suggested in the thread. Thanks for pointing me toward it!

Re: a no-homepage homepage for ports with dead homepages

[Rainer Müller]

On 2018-01-11 22:22, Jan Stary wrote:
> On Jan 11 11:49:40, ken.cunningham.web...@gmail.com wrote:
>> I've been prospecting MacPorts errors reported by repology 
>> . A 
>> common error is that the homepage 404s out.
>>
>> Many of these ports still work install correctly, but have no homepage, no 
>> homepage can seem to be found, and there is none on archive.org.
>>
>> Rather than just have it error out forever, I made this page in the spirit 
>> of the gentoo page:
>>
>> 

I like the idea of the placeholder wiki page with a detailed explanation.

>> If that is acceptable, I'd like to use it, or some variation of it, for 
>> ports like biggersql, for example, to fix some of these errors.
> 
> What errors exactly will be "fixed" by that?

It documents that the upstream homepage is gone for good. That helps to
understand this software is most likely a dead project.

Nit pick: I would have called it NoHomepage (small letter p), as the
compound form seems to be more common than two words and it is used this
way as Portfile option and in the wiki page itself.

>> PS : Personally, I think asking users for a new homepage, if there is one, 
>> is better than just deleting the homepage variable requirement in Portfiles.
> 
> It might be useful to display a message when a port without a manpage is
> installed, saying something like you put on the page above, but shorter:
> 
>   $port does not have a manpage.
>   Please let $maintainer know if you know where it is.

This could add a lot of clutter, for example if a port is only installed
as a dependency. I think the port notes should only contain information
relevant to its usage.

> At any rate, this would imho be better displayed automaticaly with 
> "port notes" - not explicitly in Portfile of course, but implicitly
> for ports without a manpage. Meaning they don't have one in the Portfile,
> as opposed to "it has this 'homepage', but it's not really its homepage".

We could use the above wiki page URL as the default value for the
homepage option, so not setting anything in the Portfile would use that.

Rainer

Re: 10.13 builder on our BuildBot is failing

[Vincent Habchi]

Ryan,

so what was the problem?

Vincent