Re: Request to close tickets on some GIS ports

[Marius Schamschula]

Done!

> On Dec 9, 2023, at 4:15 AM, Nicklas Larsson via macports-dev 
>  wrote:
> 
> 
>> On 9 Dec 2023, at 02:19, Marius Schamschula  wrote:
>> 
>> I just closed almost all of these.
>> 
> 
> 
> Great, thanks you Marius!
> 
> 
> 
>> https://trac.macports.org/ticket/43431
>> 
>> Doesn’t seem to match the description, so I left it open.
>> 
> 
> Re #43431 I only wanted to remove grass and gdal from the “ports” list in the 
> ticket, not close the ticket
> 
> https://trac.macports.org/ticket/43431#comment:66
> https://trac.macports.org/ticket/43431#comment:67
> 
> 
> 
> 

Re: Request to close tickets on some GIS ports

[Marius Schamschula]

I just closed almost all of these.

https://trac.macports.org/ticket/43431

Doesn’t seem to match the description, so I left it open.

> On Oct 12, 2023, at 9:33 AM, Nicklas Larsson via macports-dev 
>  wrote:
> 
> There are a number of tickets – either outdated or already addressed 
> (alternatively
> no more reproducible) – on some GIS ports, which I’d be grateful if someone 
> with
> access could take care of:
> 
> Close following 'grass' and 'grass7' tickets:
> 
> https://trac.macports.org/ticket/40307
> https://trac.macports.org/ticket/42203
> https://trac.macports.org/ticket/60506
> https://trac.macports.org/ticket/61551
> https://trac.macports.org/ticket/68150
> 
> 
> Remove 'grass' and 'gdal' from "port" at:
> 
> https://trac.macports.org/ticket/43431
> 
> 
> Close following 'PDAL' tickets:
> 
> https://trac.macports.org/ticket/60532
> https://trac.macports.org/ticket/60623
> https://trac.macports.org/ticket/61932
> 
> 
> Close following 'py-gdal' ticket:
> 
> https://trac.macports.org/ticket/57621
> 
> 
> Close following 'gdal' tickets:
> 
> https://trac.macports.org/ticket/62118
> https://trac.macports.org/ticket/62671
> https://trac.macports.org/ticket/64141
> https://trac.macports.org/ticket/64413
> 
> 
> 
> Cheers,
> Nicklas
> 

Re: Clean up PROJ mess

[Marius Schamschula]

octave/octave-octproj works with proj >= 6.3.0

I just haven’t updated the Portfile to version 9.x, as there haven’t been any 
upstream changes in a while.

> On Jun 8, 2023, at 2:54 PM, Nicklas Larsson via macports-dev 
>  wrote:
> 
> Hello all,
> 
> 
> I'd like to propose to simplify the maintainance of the PROJ ports, which has
> become unnecessary cumbersome and in many cases leading to installments of
> multiple versions only because different ports are out-of-sync in respect to
> default proj variant.
> 
> The PROJ ports available now:
> 
> portversion
> ---
> proj4   4.9.3
> proj5.2.0
> proj6   6.3.2
> proj7   7.2.1
> proj8   8.2.1
> proj9   9.2.1
> 
> 
> It would be better to use the port name 'proj' for the latest version 
> available
> (independent of major version), which now is version 9.2.1. The present port
> 'proj', which is version 5.2.0, should be renamed to 'proj5'. Like this:
> 
> portversion
> ---
> proj4   4.9.3
> proj5   5.2.0
> proj6   6.3.2
> proj7   7.2.1
> proj8   8.2.1
> proj9.2.1
> 
> 
> The day when there is a new major version, e.g. 10.0.0, the 'proj' port will 
> be
> updated accordingly and 'proj9' will keep the 9.x.y version:
> 
> portversion
> ---
> proj4   4.9.3
> proj5   5.2.0
> proj6   6.3.2
> proj7   7.2.1
> proj8   8.2.1
> proj9   9.2.1
> proj10.0.0
> 
> 
> The ports with 'proj' dependency, which are actively updated and maintained,
> will in this way be kept in sync with less risk of installing multiple 
> versions.
> Ports, which do not support later versions of PROJ, can keep the pinned 
> version.
> 
> 
> List of ports with proj[x] dependency:
> 
> R/R-lwgeom  path:lib/proj5/lib/pkgconfig/proj.pc:proj
> R/R-proj4   path:lib/proj5/lib/pkgconfig/proj.pc:proj
> R/R-reproj  path:lib/proj5/lib/pkgconfig/proj.pc:proj
> R/R-rgdal   path:lib/proj5/lib/pkgconfig/proj.pc:proj
> R/R-sf  path:lib/proj5/lib/pkgconfig/proj.pc:proj
> R/R-terra   path:lib/proj5/lib/pkgconfig/proj.pc:proj
> R/R-vapour  path:lib/proj5/lib/pkgconfig/proj.pc:proj
> databases/mysql55-lib_mysqludf_fproj4   port:proj4
> databases/postgis   port:proj4
> databases/postgis2  port:proj6
> databases/postgis3  port:proj[6-9]
> databases/spatialite-tools  port:proj[6-9]
> databases/spatialiteport:proj[6-9]
> gis/gdalport:proj[6-9]
> gis/grass   port:proj[6-9]
> gis/grass7  port:proj[6-9]
> gis/liblas  port:proj[6-9]
> gis/libosmium   port:proj4
> gis/mapnik  port:proj4
> gis/mapserver   port:proj[6-9]
> gis/mod_tileport:proj4
> gis/osm2pgsql   port:proj8
> gis/qgis3   port:proj[6-9]
> gis/qlandkarte  port:proj4
> gis/qlandkartegtport:proj[4-7]
> gis/sagaport:proj8
> graphics/libgeotiff port:proj[7-9]
> octave/octave-octproj   port:proj8
> perl/p5-alien-proj  port:proj[6-9]
> perl/p5-alien-proj4 port:proj4
> python/py-cartopy   port:proj8
> python/py-pyprojport:proj8
> python/py-spatialiteport:proj4
> science/cdo port:proj8
> science/gerris  port:proj
> science/magicsppport:proj6
> science/metview port:proj6
> science/ncarg   port:proj
> science/relax3d port:proj7
> science/sumoport:proj4
> science/vapor   port:proj4
> science/wgrib2  port:proj8
> science/xastir  port:proj4
> 
> 
> 
> What do you think, could this be a good way to go forward?
> Suggestions, opinions?
> 
> 
> Best regards,
> Nicklas
> 

Marius
--
Marius Schamschula

Re: Review a fix for OpenSSL3 CVE

[Marius Schamschula]

> 
> On Nov 2, 2022, at 2:56 PM, Clemens Lang  <mailto:c...@macports.org>> wrote:
> 
> On Tue, Nov 01, 2022 at 07:04:40PM +0100, Kirill A. Korinsky via macports-dev 
> wrote:
>> OpenSSL team released a fix for found CVE:
>> https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ 
>> <https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/>
>> 
>> 
>> May I ask someone to review a PR to fix this CVE?
>> 
>> https://github.com/macports/macports-ports/pull/16545
>> 
>> I think that this CVE should be a reason to merge such PR ASAP without
>> maintainers confirmation.
> 
> I deal with OpenSSL for a living at my day job, so I was aware of this.
> 
> November 1st was a public holiday where I live, so I did not spend the
> entire day at my desk. I had planned to do the update in the CET evening
> hours of November 1st, but your PR beat me to it.
> 
> 
> On Tue, Nov 01, 2022 at 04:45:26PM -0400, Daniel J. Luke wrote:
>> I don't mind waiting a bit for the maintainer for this one (especially
>> since it looks like it's already been approved and merged by the
>> maintainer :) ), but the policy that allows waiving maintainer
>> permission was intended to specifically cover security issues (ie. we
>> discussed this when creating the policy and decided that point that
>> says 'A critical port is broken that affects many users' covered
>> security fixes to ports).
> 
> This is correct. We have previously merged security fixes without
> waiting for the maintainer. This would also have been OK in this
> instance.
> 
> Speaking of this CVE… we don't actually build with the common set of
> security flags in MacPorts, do we? We should probably look into getting
> the common set -fstack-protector-strong -fstack-clash-protection -fPIE
> (probably not required on modern macOS?) -D_FORTIFY_SOURCE=3
> -fcf-protection=full (on x86_64) and maybe -Wl,-bind_at_load
> -Wl,-read_only_stubs.

I’ve been thinking the same thing as I compile packages on my FreeBSD machines 
and see these flags over and over again.

> Does anybody have a good overview of what the recommended set of
> security compiler flags is on macOS? Quick testing suggests everything
> but -fstack-protector-strong and -D_FORTIFY_SOURCE is already on by
> default.

Marius
--
Marius Schamschula

Re: Using platforms in 2.8.0

[Marius Schamschula]

I haven’t tried to build MacPorts 2.8.0 under FreeBSD (the source tarball gives 
a 404), but I last tried 2.7.2 built and it installed cleanly, but was unusable 
as portindex failed. I could debug to the point where it failed, but never 
could figure out what was going on.

Marius
--
Marius Schamschula




> On Oct 22, 2022, at 3:50 AM, Joshua Root  wrote:
> 
> MacPorts 2.8.0 lets you specify which OS versions your ports work on via the 
> platforms option. This indicates a port that works on darwin versions from 
> 10.x to 19.x inclusive:
> 
> platforms {darwin >= 10 < 20}
> 
> Most ports will probably only need one comparison, but you can have as many 
> as you need. Operators supported are ==, !=, >, <, >= and <=. For == and !=, 
> a string comparison that allows globs is used. For the rest, vercmp is used. 
> If any comparison doesn't match, known_fail is set to yes.
> 
> Note that the comparison is against ${os.version}, not ${os.major}, so you'll 
> usually want to use e.g. < 20 for the upper bound rather than <= 19 (the 
> latter would exclude all 19.x versions).
> 
> These are all valid:
> 
> platforms {darwin >= 11}
> platforms {darwin < 19} freebsd
> platforms {darwin >= 16 != 18.2.* < 23} {linux != *}
> 
> The second one indicates FreeBSD support in a purely informational way, as 
> per the usage of the platforms option in older MacPorts versions. The last 
> one indicates that it doesn't work on Linux and will set known_fail there. 
> Again, most ports will probably only use something like the first example, 
> but the flexibility is there if you need it.
> 
> All of the above can be used without making your Portfile incompatible with 
> 2.7. There is another way that platforms can be used:
> 
> platforms any
> platforms {darwin any}
> 
> The first one indicates that the port will install identical files no matter 
> what platform it is built on, and will set the platform in the archive 
> filename to "any_any". The second one indicates that the port will install 
> identical files when built on any version of Darwin, but may install 
> different files when built on other platforms, and sets the platform in the 
> archive filename to "darwin_any" when on Darwin.
> 
> These will usually only be applicable to noarch ports, though rare exceptions 
> may exist. Ports that install only data files or scripts will often be able 
> to use "any". Python scripts are an exception because Python uses a framework 
> layout on Darwin only, so they will be "{darwin any}".
> 
> Since the archive filename is changed, using this will of course prevent 
> users on older MacPorts versions from using the archives. So we would 
> normally wait 2 weeks after the release of 2.8.0 before starting to use this 
> feature.
> 
> However, with the release of Ventura in a couple days, it may pay to set 
> these platforms values on as many eligible ports as possible, both to make 
> the archives available to Ventura users even before we have a Ventura 
> buildbot worker up and running, and to reduce the load on that worker once it 
> is up.
> 
> - Josh

Re: MacPorts 2.8.0-beta1 now available for testing

[Marius Schamschula]

Chris,

Correct!

I don’t want to use —autostash, as it may clobber WIP files in my local tree 
(per the git-pull man page).

I ran

git branch --set-upstream-to=origin/master master

to get rid of the error.

However, I shouldn’t use port sync (or for that matter port selfupdate), unless 
my local tree is clean.

> On Oct 20, 2022, at 10:37 AM, Chris Jones  wrote:
> 
> Hi
> 
> Go to your person checkout
> 
> /Users/marius/Development/MacPorts/ports
> 
> And then run
> 
> /opt/local/bin/git pull --rebase --autostash
> 
> You will I bet see the same issue, so the problem is nothing to do with 
> macports but your local checkout.
> 
> Chris
> 
>> On 20 Oct 2022, at 3:22 pm, Marius Schamschula  wrote:
>> 
>> 
>> Chris,
>> 
>> If I go to 
>> 
>> /opt/local/var/macports/sources/github.com/macports/macports-ports 
>> <http://github.com/macports/macports-ports>
>> 
>> and run
>> 
>> /opt/local/bin/git pull --rebase origin master
>> 
>> Which I do as part of a macro which also runs portindex on that directory, 
>> everything works as expected.
>> 
>> The only part of port selfupdate that’s failing is the port sync:
>> 
>> marius@Mira macports-ports % sudo port -d sync  
>> DEBUG: Copying /Users/marius/Library/Preferences/com.apple.dt.Xcode.plist to 
>> /opt/local/var/macports/home/Library/Preferences
>> --->  Updating the ports tree
>> Synchronizing local ports tree from 
>> file:///Users/marius/Development/MacPorts/ports 
>> 
>> DEBUG: euid/egid changed to: 501/20, env: HOME=/Users/marius 
>> SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.084KBeK49L/Listeners
>> DEBUG: /opt/local/bin/git pull --rebase --autostash
>> DEBUG: system -W /Users/marius/Development/MacPorts/ports: 
>> /opt/local/bin/git pull --rebase --autostash
>> There is no tracking information for the current branch.
>> Please specify which branch you want to rebase against.
>> See git-pull(1) for details.
>> 
>> git pull  
>> 
>> If you wish to set tracking information for this branch you can do so with:
>> 
>> git branch --set-upstream-to=origin/ master
>> 
>> Command failed: /opt/local/bin/git pull --rebase --autostash
>> Exit code: 1
>> DEBUG: command execution failed
>> while executing
>> "system -W $dir $cmd"
>> (procedure "macports::UpdateVCS" line 1)
>> invoked from within
>> "macports::UpdateVCS $cmd $dir"
>> Syncing local Git ports tree failed
>> DEBUG: euid/egid restored to: 0/0, env restored
>> Synchronizing local ports tree from 
>> file:///opt/local/var/macports/sources/github.com/macports/macports-ports/ 
>> 
>> DEBUG: euid/egid changed to: 501/20, env: HOME=/Users/marius 
>> SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.084KBeK49L/Listeners
>> DEBUG: /opt/local/bin/git pull --rebase --autostash
>> DEBUG: system -W 
>> /opt/local/var/macports/sources/github.com/macports/macports-ports: 
>> <http://github.com/macports/macports-ports:> /opt/local/bin/git pull 
>> --rebase --autostash
>> There is no tracking information for the current branch.
>> Please specify which branch you want to rebase against.
>> See git-pull(1) for details.
>> 
>> git pull  
>> 
>> If you wish to set tracking information for this branch you can do so with:
>> 
>> git branch --set-upstream-to=origin/ master
>> 
>> Command failed: /opt/local/bin/git pull --rebase --autostash
>> Exit code: 1
>> DEBUG: command execution failed
>> while executing
>> "system -W $dir $cmd"
>> (procedure "macports::UpdateVCS" line 1)
>> invoked from within
>> "macports::UpdateVCS $cmd $dir"
>> Syncing local Git ports tree failed
>> DEBUG: euid/egid restored to: 0/0, env restored
>> DEBUG: Synchronization of 2 sources failed
>> while executing
>> "mportsync [array get global_options]"
>> port sync failed: Synchronization of 2 sources failed
>> 
>> Note: this error doesn’t happen under MacPorts 2.7.2, as I rechecked two of 
>> my machines that haven’t been upgraded to MacPorts 2.8.0.
>> 
>>> On Oct 20, 2022, at 8:31 AM, Christopher Jones >> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>> 
>>> 
>>> No, thats not what I am saying. What you are doing works just fine for me…
>>> 
>>> My own checkout has
>>> 
>>> Oberon ~/Projects/MacPorts/ports > git remote -v
>>> cjones  g...@github.com 

Re: MacPorts 2.8.0-beta1 now available for testing

[Marius Schamschula]

 list ... done
> ./
> 
> sent 66 bytes  received 98 bytes  109.33 bytes/sec
> total size is 113716736  speedup is 693394.73
> DEBUG: successful verification with key 
> /opt/local/share/macports/macports-pubkey.pem
> DEBUG: system: /usr/bin/tar -C 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/tmp
>  <http://rsync.macports.org/macports/release/tarballs/tmp> -xf 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base.tar
>  <http://rsync.macports.org/macports/release/tarballs/base.tar>
> MacPorts base version 2.8.0 installed,
> DEBUG: Rebuilding and reinstalling MacPorts if needed
> MacPorts base version 2.8.0 downloaded.
> --->  Updating the ports tree
> Synchronizing local ports tree from 
> file:///Users/chris/Projects/MacPorts/ports 
> 
> DEBUG: euid/egid changed to: 501/20, env: HOME=/Users/chris 
> SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.3Ry328lG9D/Listeners
> DEBUG: /opt/local/bin/git pull --rebase --autostash
> DEBUG: system -W /Users/chris/Projects/MacPorts/ports: /opt/local/bin/git 
> pull --rebase --autostash
> Already up to date.
> 
> So the git pull works just fine. ( It hangs after this but thats a different 
> issue. )
> 
> Why you are having problems I cannot say, but you should start by checking 
> how you have the remotes setup for your checkout.
> 
> Chris
> 
>> On 20 Oct 2022, at 1:52 pm, Marius Schamschula > <mailto:li...@schamschula.com>> wrote:
>> 
>> Chris,
>> 
>> In other words, I shouldn’t ever run port selfupdate in my local repo (which 
>> syncs to my personal GitHub repo), but rather in the 
>> 
>> /opt/local/var/macports/sources/github.com/macports/macports-ports 
>> <http://github.com/macports/macports-ports>
>> 
>> directory. Make sense, but the update has always worked in the past.
>> 
>>> On Oct 20, 2022, at 7:26 AM, Christopher Jones >> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>> 
>>> The message
>>> 
>>> There is no tracking information for the current branch.
>>> Please specify which branch you want to rebase against.
>>> See git-pull(1) for details.
>>> 
>>> git pull  
>>> 
>>> If you wish to set tracking information for this branch you can do so with:
>>> 
>>> git branch --set-upstream-to=origin/ master
>>> 
>>> Indicates you have 
>>> 
>>> /Users/marius/Development/MacPorts/ports 
>>> 
>>> 
>>> switched to a branch that does not have its tracking information set. This 
>>> normally happens if you have a feature branch (e.g. for a PR) checked out, 
>>> but the above is for master which is a bit weird.
>>> 
>>> running
>>> 
>>> git branch --set-upstream-to=origin/master master
>>> 
>>> might fix this, but again, it is a bit odd you need to do this for your 
>>> master checkout, unless you have done something ‘odd’ to it such that it 
>>> has lost its tracking info.
>>> 
>>> Chris
>>> 
>>>> On 20 Oct 2022, at 12:17 pm, Marius Schamschula >>> <mailto:li...@schamschula.com>> wrote:
>>>> 
>>>> I’m seeing something very similar with MacPorts 2.8.0 (release)
>>>> 
>>>> marius@Mira ports % sudo port selfupdate 
>>>> --->  Updating MacPorts base sources using rsync
>>>> MacPorts base version 2.7.2 installed,
>>>> MacPorts base version 2.8.0 downloaded.
>>>> --->  Updating the ports tree
>>>> --->  MacPorts base is outdated, installing new version 2.8.0
>>>> Installing new MacPorts release in /opt/local as root:wheel; permissions 
>>>> 0755
>>>> 
>>>> Error: Couldn't change permissions of the MacPorts sources at 
>>>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base
>>>>  <http://rsync.macports.org/macports/release/tarballs/base> to root: child 
>>>> killed: kill signal
>>>> Please run `port -v selfupdate' for details.
>>>> Error: /opt/local/bin/port: port selfupdate failed: Couldn't change 
>>>> permissions of the MacPorts sources at 
>>>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base
>>>>  <http://rsync.macports.org/macports/release/tarballs/base> to root: child 
>>>> killed: kill signal
>>>> marius@Mira ports % sudo port -v selfupdate
>>>> --->  Updating MacPorts base sources 

Re: MacPorts 2.8.0-beta1 now available for testing

[Marius Schamschula]

Chris,

In other words, I shouldn’t ever run port selfupdate in my local repo (which 
syncs to my personal GitHub repo), but rather in the 

/opt/local/var/macports/sources/github.com/macports/macports-ports 
<http://github.com/macports/macports-ports>

directory. Make sense, but the update has always worked in the past.

> On Oct 20, 2022, at 7:26 AM, Christopher Jones  
> wrote:
> 
> The message
> 
> There is no tracking information for the current branch.
> Please specify which branch you want to rebase against.
> See git-pull(1) for details.
> 
> git pull  
> 
> If you wish to set tracking information for this branch you can do so with:
> 
> git branch --set-upstream-to=origin/ master
> 
> Indicates you have 
> 
> /Users/marius/Development/MacPorts/ports 
> 
> 
> switched to a branch that does not have its tracking information set. This 
> normally happens if you have a feature branch (e.g. for a PR) checked out, 
> but the above is for master which is a bit weird.
> 
> running
> 
> git branch --set-upstream-to=origin/master master
> 
> might fix this, but again, it is a bit odd you need to do this for your 
> master checkout, unless you have done something ‘odd’ to it such that it has 
> lost its tracking info.
> 
> Chris
> 
>> On 20 Oct 2022, at 12:17 pm, Marius Schamschula > <mailto:li...@schamschula.com>> wrote:
>> 
>> I’m seeing something very similar with MacPorts 2.8.0 (release)
>> 
>> marius@Mira ports % sudo port selfupdate 
>> --->  Updating MacPorts base sources using rsync
>> MacPorts base version 2.7.2 installed,
>> MacPorts base version 2.8.0 downloaded.
>> --->  Updating the ports tree
>> --->  MacPorts base is outdated, installing new version 2.8.0
>> Installing new MacPorts release in /opt/local as root:wheel; permissions 0755
>> 
>> Error: Couldn't change permissions of the MacPorts sources at 
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base
>>  <http://rsync.macports.org/macports/release/tarballs/base> to root: child 
>> killed: kill signal
>> Please run `port -v selfupdate' for details.
>> Error: /opt/local/bin/port: port selfupdate failed: Couldn't change 
>> permissions of the MacPorts sources at 
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base
>>  <http://rsync.macports.org/macports/release/tarballs/base> to root: child 
>> killed: kill signal
>> marius@Mira ports % sudo port -v selfupdate
>> --->  Updating MacPorts base sources using rsync
>> 
>> Willkommen auf dem RSYNC-server auf ftp.fau.de <http://ftp.fau.de/>.
>> Nicht all unsere Mirror sind per rsync verfuegbar.
>> 
>> Welcome to the RSYNC daemon on ftp.fau.de <http://ftp.fau.de/>.
>> Not all of our mirrors are available through rsync.
>> 
>> 
>> receiving file list ... done
>> ./
>> 
>> sent 66 bytes  received 98 bytes  109.33 bytes/sec
>> total size is 113716736  speedup is 693394.73
>> MacPorts base version 2.8.0 installed,
>> MacPorts base version 2.8.0 downloaded.
>> --->  Updating the ports tree
>> Synchronizing local ports tree from 
>> file:///Users/marius/Development/MacPorts/ports 
>> 
>> There is no tracking information for the current branch.
>> Please specify which branch you want to rebase against.
>> See git-pull(1) for details.
>> 
>> git pull  
>> 
>> If you wish to set tracking information for this branch you can do so with:
>> 
>> git branch --set-upstream-to=origin/ master
>> 
>> Command failed: /opt/local/bin/git pull --rebase --autostash
>> Exit code: 1
>> Syncing local Git ports tree failed
>> Synchronizing local ports tree from 
>> file:///opt/local/var/macports/sources/github.com/macports/macports-ports/ 
>> 
>> From github.com <http://github.com/>:macports/macports-ports
>>  * [new tag] PRE_DESTROOT_TARGET-> 
>> PRE_DESTROOT_TARGET
>>  * [new tag] jkh-destrootification-base -> 
>> jkh-destrootification-base
>>  * [new tag] kevin-target-api-base  -> 
>> kevin-target-api-base
>>  * [new tag] post-landon-trace  -> post-landon-trace
>>  * [new tag] pre-chain-remove   -> pre-chain-remove
>>  * [new tag] pre-landon-trace   -> pre-landon-trace
>>  * [new tag] release_1_2_0-archive  -> 
>> release_1_2_0-archive
>>  * [new tag] 

Re: MacPorts 2.8.0-beta1 now available for testing

[Marius Schamschula]

I’m seeing something very similar with MacPorts 2.8.0 (release)

marius@Mira ports % sudo port selfupdate 
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.7.2 installed,
MacPorts base version 2.8.0 downloaded.
--->  Updating the ports tree
--->  MacPorts base is outdated, installing new version 2.8.0
Installing new MacPorts release in /opt/local as root:wheel; permissions 0755

Error: Couldn't change permissions of the MacPorts sources at 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base
  to root: child 
killed: kill signal
Please run `port -v selfupdate' for details.
Error: /opt/local/bin/port: port selfupdate failed: Couldn't change permissions 
of the MacPorts sources at 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base
  to root: child 
killed: kill signal
marius@Mira ports % sudo port -v selfupdate
--->  Updating MacPorts base sources using rsync

Willkommen auf dem RSYNC-server auf ftp.fau.de .
Nicht all unsere Mirror sind per rsync verfuegbar.

Welcome to the RSYNC daemon on ftp.fau.de .
Not all of our mirrors are available through rsync.


receiving file list ... done
./

sent 66 bytes  received 98 bytes  109.33 bytes/sec
total size is 113716736  speedup is 693394.73
MacPorts base version 2.8.0 installed,
MacPorts base version 2.8.0 downloaded.
--->  Updating the ports tree
Synchronizing local ports tree from 
file:///Users/marius/Development/MacPorts/ports 

There is no tracking information for the current branch.
Please specify which branch you want to rebase against.
See git-pull(1) for details.

git pull  

If you wish to set tracking information for this branch you can do so with:

git branch --set-upstream-to=origin/ master

Command failed: /opt/local/bin/git pull --rebase --autostash
Exit code: 1
Syncing local Git ports tree failed
Synchronizing local ports tree from 
file:///opt/local/var/macports/sources/github.com/macports/macports-ports/ 

From github.com :macports/macports-ports
 * [new tag] PRE_DESTROOT_TARGET-> PRE_DESTROOT_TARGET
 * [new tag] jkh-destrootification-base -> 
jkh-destrootification-base
 * [new tag] kevin-target-api-base  -> kevin-target-api-base
 * [new tag] post-landon-trace  -> post-landon-trace
 * [new tag] pre-chain-remove   -> pre-chain-remove
 * [new tag] pre-landon-trace   -> pre-landon-trace
 * [new tag] release_1_2_0-archive  -> release_1_2_0-archive
 * [new tag] release_1_2_0-archive-rc1  -> 
release_1_2_0-archive-rc1
 * [new tag] release_1_2_0-rc2-archive  -> 
release_1_2_0-rc2-archive
 * [new tag] release_1_2_0-rc3-archive  -> 
release_1_2_0-rc3-archive
 * [new tag] release_1_2_1-archive  -> release_1_2_1-archive
 * [new tag] release_1_2_1-rc1-archive  -> 
release_1_2_1-rc1-archive
 * [new tag] release_1_3_0-archive  -> release_1_3_0-archive
 * [new tag] release_1_3_1-archive  -> release_1_3_1-archive
 * [new tag] release_1_3_2-archive  -> release_1_3_2-archive
 * [new tag] release_1_4_0-archive  -> release_1_4_0-archive
 * [new tag] release_1_5_0-archive  -> release_1_5_0-archive
 * [new tag] release_1_6_0-archive  -> release_1_6_0-archive
 * [new tag] release_1_7_0-archive  -> release_1_7_0-archive
 * [new tag] release_1_8_0-archive  -> release_1_8_0-archive
 * [new tag] release_1_9_0-archive  -> release_1_9_0-archive
 * [new tag] release_2_0_0-archive  -> release_2_0_0-archive
 * [new tag] release_2_1_0-archive  -> release_2_1_0-archive
 * [new tag] release_2_2_0-archive  -> release_2_2_0-archive
 * [new tag] release_2_3_0-archive  -> release_2_3_0-archive
 * [new tag] v2.4.0-archive -> v2.4.0-archive
 * [new tag] v2.5.0-archive -> v2.5.0-archive
 * [new tag] v2.6.0-archive -> v2.6.0-archive
 * [new tag] v2.7.0-archive -> v2.7.0-archive
 * [new tag] v2.8.0-archive -> v2.8.0-archive
There is no tracking information for the current branch.
Please specify which branch you want to rebase against.
See git-pull(1) for details.

git pull  

If you wish to set tracking information for this branch you can do so with:

git branch --set-upstream-to=origin/ master

Command failed: /opt/local/bin/git pull --rebase --autostash
Exit code: 1
Syncing local Git ports 

Re: OpenSSH 8.9p1 deprecated variants cleanup feedback request

[Marius Schamschula]

Indeed,

I keep openssh as a local port so I can get it updated w/o waiting for that 
problematic patch to be updated.

Marius
--
Marius Schamschula




> On Mar 15, 2022, at 4:12 PM, Daniel J. Luke  wrote:
> 
> On Mar 14, 2022, at 6:14 PM, grey  wrote:
>> Thank you in advance for any wisdom you may be able to share on this issue!
> 
> My suggestion previously was that the openssh port should just build upstream 
> openssh + any patches that a maintainer wants to keep updated - since 
> interest in forward-porting the gsskex and hpn patches always lags 
> (significantly) new openssh releases.
> 
> If people want slowly-updated versions of openssh with one (or both) of those 
> patches, they can go in a different port so that the vast majority of users 
> can get the current version of openssh and it can be maintained  by someone 
> who doesn't want/need/use those patches.
> 
> -- 
> Daniel J. Luke
> 

Re: [10.6.8] certbot & pyOpenSSL problems

[Marius Schamschula]

What does

port installed py39-openssl

say? On my machine I get 21.00.0_0.

Also, IIRC there was a change in py-cryptography versioning. On my machine I 
have 35.0.0_3.

Mixing pip with MacPorts will guarantee a broken installation within weeks.if 
not within days.

Marius
--
Marius Schamschula




> On Dec 16, 2021, at 5:17 PM, Bjarne D Mathiesen  
> wrote:
> 
> System Version: Mac OS X 10.6.8 (10K549)
> Kernel Version: Darwin 10.8.0
> 
> Ok, I've got certbot installed, but a recent upgrade of something has
> broken it :
> 
> #=> certbot certificates
> 
> gives the following error-message :
> 
> pkg_resources.ContextualVersionConflict: (cryptography 2.9.2
> (/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages),
> Requirement.parse('cryptography>=3.3'), {'PyOpenSSL'})
> 
> which to me indicates, that PyOpenSSL needs to be upgraded.
> So, I installed py39-pip, and did the following :
> 
> #=> pip install pyopenssl
> Requirement already satisfied: pyopenssl in
> /opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages
> (21.0.0)
> Collecting cryptography>=3.3
>  Downloading cryptography-36.0.1.tar.gz (572 kB)
> || 572 kB 1.0 MB/s
>  Installing build dependencies ... done
> 
> which resulted in the following error-message :
> 
>  running build_rust
> 
>  =DEBUG
> ASSISTANCE=
>  If you are seeing a compilation error please try the following
> steps to
>  successfully install cryptography:
>  1) Upgrade to the latest pip and try again. This will fix errors
> for most
> users. See: https://pip.pypa.io/en/stable/installing/#upgrading-pip
>  2) Read https://cryptography.io/en/latest/installation/ for specific
> instructions for your platform.
>  3) Check our frequently asked questions for more information:
> https://cryptography.io/en/latest/faq/
>  4) Ensure you have a recent Rust toolchain installed:
> https://cryptography.io/en/latest/installation/#rust
> 
>  Python: 3.9.9
>  platform: macOS-10.6.8-i386-64bit
>  pip: n/a
>  setuptools: 59.6.0
>  setuptools_rust: 1.1.2
>  =DEBUG
> ASSISTANCE=
> 
>  error: can't find Rust compiler
> 
> So, it's missing the rust compiler !
> OK, let me install that one :
> 
> --->  Fetching distfiles for rust-compiler-wrap
> Error: rust is only supported on macOS 10.7 or later.
> Error: Failed to fetch rust-compiler-wrap: unsupported platform version
> Error: See
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_rust/rust-compiler-wrap/main.log
> for details.
> Error: Follow https://guide.macports.org/#project.tickets if you believe
> there is a bug.
> Error: Processing of port rust failed
> 
> 
> Any ideas as to how I can upgrade PyOpenSSL -or- the cryptography ?
> Or am I just lost ???
> 
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> ---
> denne besked er skrevet i et totalt M$-frit miljø
> MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina
> 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM
> ATI Radeon RX 590 8 GB

Re: [NEW] www/unit

[Marius Schamschula]

Sergey,I’ve edited those parts:# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4

PortSystem  1.0

nameunit
version 1.25.0
categories  www
platforms   darwin
license Apache-2
maintainers osokin

description Dynamic web application server

long_description \
NGINX Unit is a dynamic web application server, designed \
to run applications in multiple languages.  Unit is lightweight, \
polyglot, and dynamically configured via API.  The design of the \
server allows reconfiguration of specific application parameters \
as needed by the engineering or operations.

homepagehttps://unit.nginx.org/

master_siteshttps://unit.nginx.org/download/

checksums   sha256  
4ab4f05a934dd00628c0e067f7d0c5ba62bb55e9e2e7a333fa3764a180b9765d \
size853280 \
rmd160  d08da7f6404e3fad4a69f31ba203cc9a3b69024c

depends_lib port:pcre2 \
port:zlib

set unit_vardir ${prefix}/var
set unit_dbdir  ${unit_vardir}/db/${name}
set unit_logdir ${unit_vardir}/log/${name}
set unit_logfile${unit_logdir}/${name}.log
set unit_rundir ${unit_vardir}/run/${name}
set unit_pidfile${unit_rundir}/${name}.pid
set unit_sockfile   ${unit_rundir}/control.unit.sock
set unit_tmpdir ${unit_vardir}/tmp/${name}
set unit_moddir ${prefix}/libexec/${name}/modules

configure.args  --prefix=${prefix} \
--log=${unit_logfile} \
--modules=libexec/${name}/modules \
--pid=${unit_pidfile} \
--state=${unit_dbdir} \
--tmp=${unit_tmpdir} \
--user=_www \
--group=_www

default_variants+debug +ssl

destroot.keepdirs   ${destroot}${unit_moddir}

subport ${name} {
post-destroot {
xinstall -d -m 755 ${destroot}${unit_dbdir}
xinstall -d -m 755 ${destroot}${unit_logdir}
xinstall -d -m 755 ${destroot}${unit_rundir}
xinstall -d -m 755 ${destroot}${unit_tmpdir}
}
}

subport ${name}-perl {
description Perl module for NGINX Unit

long_description{*}${description}

depends_run port:unit

post-configure {
system -W ${worksrcpath} "${configure.cmd} perl"
}

build {
system -W ${worksrcpath} "${build.cmd} perl"
}

destroot {
xinstall -d -m 755 ${destroot}${unit_moddir}
xinstall-m 644 ${worksrcpath}/build/perl.unit.so 
${destroot}${unit_moddir}/
}
}

subport ${name}-python {
description Python module for NGINX Unit

long_description{*}${description}

depends_run port:unit

post-configure {
system -W ${worksrcpath} "${configure.cmd} python"
}

build {
system -W ${worksrcpath} "${build.cmd} python"
}

destroot {
xinstall -d -m 755 ${destroot}${unit_moddir}
xinstall -m 644 ${worksrcpath}/build/python.unit.so 
${destroot}${unit_moddir}/
}
}

subport ${name}-ruby {
description Ruby module for NGINX Unit

long_description{*}${description}

depends_run port:unit

post-configure {
system -W ${worksrcpath} "${configure.cmd} ruby"
}

build {
system -W ${worksrcpath} "${build.cmd} ruby"
}

destroot {
xinstall -d -m 755 ${destroot}${unit_moddir}
xinstall -m 644 ${worksrcpath}/build/ruby.unit.so 
${destroot}${unit_moddir}/
}
}

startupitem.create  yes
startupitem.pidfile auto ${unit_pidfile}
startupitem.executable  ${prefix}/sbin/unitd

variant debug description "Enable debug logging" {
configure.args-append   --debug
}

variant ssl description "Support secure connections using OpenSSL" {
depends_lib-append  path:lib/libssl.dylib:openssl
configure.args-append   --openssl
}
On Sep 24, 2021, at 1:49 PM, Sergey A. Osokin <o...@freebsd.org> wrote:Hi Marius,thanks for your comments, the Portfile has been updated, attached.On Fri, Sep 24, 2021 at 01:13:15PM -0500, Marius Schamschula wrote:Sergey,A quick scan of the Portfile shows some whitespace inconsistencies: We prefer to use spaces, rather than tab stops.Instead of using ${description},  use {*}${description}, it’s a tcl thing!This suggestion is unclear to me, could you provide an example how toutilize that, thanks.No need for "post-destroot {}” in the various supports, if you put post-destroot inside a subport ${name} block. Same for “startupitem.create no"Fixed, thanks.On Sep 24, 2021, at 12:49 PM, Sergey A. Osokin <o...@freebsd.org> wrote:Hi,hope you're doing well these days.I'm working on the NGINX Unit port and created my first versionof the Portfile, and it's attached.NGINX Unit supports mostly all versions of:- perl- 

Re: [NEW] www/unit

[Marius Schamschula]

Sergey,

A quick scan of the Portfile shows some whitespace inconsistencies: We prefer 
to use spaces, rather than tab stops.

Instead of using ${description},  use {*}${description}, it’s a tcl thing!

No need for "post-destroot {}” in the various supports, if you put 
post-destroot inside a subport ${name} block. Same for “startupitem.create no"

> On Sep 24, 2021, at 12:49 PM, Sergey A. Osokin  wrote:
> 
> Hi,
> 
> hope you're doing well these days.
> 
> I'm working on the NGINX Unit port and created my first version
> of the Portfile, and it's attached.
> 
> NGINX Unit supports mostly all versions of:
> - perl
> - php
> - python
> - ruby
> and other languages, so I'm interested how to support all of
> those with macports.
> 
> Could you please provide your comments and guidance.
> Thank you.
> 
> -- 
> Sergey Osokin
> 

Marius
--
Marius Schamschula

Re: Segfaults on FreeBSD

[Marius Schamschula]

Rainer,

Thanks for the hints!

Here’s what I get:

(gdb)  break mktemp.c:99
Breakpoint 1 at 0x801290036: file mktemp.c, line 99.
(gdb) r
Starting program: /opt/local/libexec/macports/bin/tclsh8.5
% /opt/local/bin/portindex
[Attaching after LWP 114537 of process 29657 fork to child LWP 106805 of 
process 29675]
[New inferior 2 (process 29675)]
process 29675 is executing new program: /opt/local/libexec/macports/bin/tclsh8.5
Reading symbols from /opt/local/libexec/macports/bin/tclsh8.5...
Reading symbols from /opt/local/libexec/macports/lib/libtcl8.5.so...
Reading symbols from /opt/local/libexec/macports/lib/macports1.0/MacPorts.so...
Reading symbols from /opt/local/libexec/macports/lib/pextlib1.0/Pextlib.so...
Reading symbols from /opt/local/libexec/macports/lib/registry2.0/registry.so...
Reading symbols from /opt/local/libexec/macports/lib/tclx8.4/libtclx8.4.so...
Reading symbols from /opt/local/libexec/macports/lib/machista1.0/machista.so...
Creating port index in 
/opt/local/var/macports/sources/github.com/macports/macports-ports
[Switching to LWP 106805 of process 29675]

Thread 2.1 hit Breakpoint 1, MktempCmd (clientData=, 
interp=0x800a52550, objc=, objv=) at mktemp.c:99
99  tcl_result = Tcl_NewStringObj(sp, -1);
(gdb) p sp
$1 = 0xa51b60 
(gdb) p template
$2 = 0x800a51b60 "/tmp/mports.portindex.jSKMYigM"

Marius
__
Marius Schamschula
On Jun 24, 2021, 3:24 PM -0500, Rainer Müller , wrote:
> On 24/06/2021 03.30, Marius Schamschula wrote:
> > I’m a gdb noob, particularly as it relates to Tcl scripts.
>
> Of course you could also achieve the same checks by adding some printf
> statements to the C source. :-)
>
> > When I load
> >
> > gdb /opt/local/libexec/macports/bin/tclsh8.5 ./tclsh8.5.core
> >
> > And set my breakpoint
> >
> > (gdb) break mktemp.c:99
> >
> > And tell gdb to run, I get a tclsh prompt. If I launch
> > /opt/local/bin/portindex
> >
> > I get
> >
> > [Detaching after fork from child process 85805]
> > Creating port index in
> > /opt/local/var/macports/sources/github.com/macports/macports-ports
> > child killed: segmentation violation
>
> By default, gdb will only debug the parent process across a fork. You
> can change this with the following commands before running the program:
>
> set follow-fork-mode child
> set detach-on-fork off
>
> This way gdb will stay attached to all processes that are forked and
> also to the parent. You can view them with 'info inferior' and switch
> between them with 'inferior '.
>
> Rainer

Re: Segfaults on FreeBSD

[Marius Schamschula]

I’m a gdb noob, particularly as it relates to Tcl scripts. When I load

gdb /opt/local/libexec/macports/bin/tclsh8.5 ./tclsh8.5.core

And set my breakpoint

(gdb) break mktemp.c:99

And tell gdb to run, I get a tclsh prompt. If I launch /opt/local/bin/portindex

I get

[Detaching after fork from child process 85805]
Creating port index in 
/opt/local/var/macports/sources/github.com/macports/macports-ports
child killed: segmentation violation

Needless to say, that’s already past the breakpoint.

I also tried running

expect -D 1 /opt/local/bin/portindex

However, expect is compiled against a different version of tcl/tk and has no 
idea where the MacPorts package is

"can't find package macports"

Marius
__
Marius Schamschula
On Jun 23, 2021, 1:43 PM -0500, Rainer Müller , wrote:
> On 19/06/2021 17.58, atmail.dreamhost.com wrote:
> > Every now and then I try to get MacPorts to build and run on FreeBSD.
> >
> > Getting it to build requires less than a handful of edits.
> >
> > However, when running portindex I get a Segfault with a Signal 11.
> >
> > Here’s what gdb says (after recompiling with debug symbols enabled)"
>
> > [...]
>
> So it is failing at this point inside the Tcl_NewStringObj():
> https://github.com/macports/macports-base/blob/v2.7.1/src/pextlib1.0/mktemp.c#L99
>
> gdb already tells us that the pointer 0xa51b60 doesn't look good. But
> mktemp() is never supposed to return anything else than either the
> pointer given or NULL [1].
>
> Could you try to break in gdb here in line 99 (after the call to mktemp)
> and compare the variables sp and template? They must point to the same
> memory address.
>
> You could even check whether there is a proper C string terminated by
> '\0' in memory... but actually gdb already told us it is not, because it
> cannot access memory at this address. :-/
>
> Rainer
>
> [1] https://www.freebsd.org/cgi/man.cgi?mktemp(3)

Re: Publicizing MacPorts [installation]

[Marius Schamschula]

A script that’ll download the installer pkg and then run the installer cli 
command

i.e. something like

cd ~/Downloads
curl -OL /url/of/installer.pkg
sudo installer -pkg installer.pkg -target /


> On May 23, 2021, at 12:58 PM, Joshua Root  <mailto:j...@macports.org>> wrote:
> 
> On 2021-5-23 20:40 , Artem Loenko via macports-dev wrote:
>> If you ask me, `curl | sh` is a better option than `sudo make install`.
>> Even if we compare them both as anti-patterns.
> 
> If you haven't done any verification of the integrity of what you're 
> installing, 'make install' is certainly also a bad idea. But at least you had 
> the opportunity to verify the gpg signature or whatever of the tarball you 
> downloaded before running that. (And sure, a lot of people don't, hence the 
> preference of the pkg installer for general use, which will refuse to install 
> if the signature can't be verified.)
> 
>> Plus, `make` requires a few dependencies. But when you install a package,
>> all the logic/doctor checks can be implemented on the `ports` binary level.
>> Install CLT, Xcode, check the environment, etc. Simple is better.
> 
> Sure.
> 
> - Josh



Marius
--
Marius Schamschula

Freenode IRC

[Marius Schamschula]

It has come to my attention, on Twitter, that freenode.net, were MacPorts hosts 
it’s IRC channels, is having some serious issues [1]. The admins have resigned 
and control may now be in questionable hands.

It is suggested that channels be moved to libera.chat.

[1] https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409

Marius
--
Marius Schamschula

Re: pkg-config and opencv4

[Marius Schamschula]

I just opened a PR with the fix: 
https://github.com/macports/macports-ports/pull/9972

> On Feb 9, 2021, at 9:03 AM, Marius Schamschula  wrote:
> 
> Exactly my reading. However, there are many packages that depend on 
> opencv/opencv4 that prefer to use pkg-config rather than cmake. In my case 
> gmic in its multiple forms.
> 
>> On Feb 9, 2021, at 8:44 AM, Joël Brogniart  
>> wrote:
>> 
>> Even if posts in the issus show workarounds, it also looks like opencv 
>> developers consider the use of pkg-config .pc files obsolete so I will do 
>> without.
>> 
>>> Le 9 févr. 2021 à 14:43, Marius Schamschula  a écrit 
>>> :
>>> 
>>> It looks like this is an open issue:
>>> 
>>> https://github.com/opencv/opencv/issues/13154
>>> 
>>> It looks like one can patch opencv4 to fix this issue.
>>> 
>>> PS: I meant .pc not .po files.
>>> 
>>>> On Feb 9, 2021, at 7:40 AM, Marius Schamschula  
>>>> wrote:
>>>> 
>>>> pkg-config only works if the package generates .po files. cairo does, 
>>>> opencv does, but opencv4 does not.
>>>> 
>>>>> On Feb 9, 2021, at 6:44 AM, Joël Brogniart  
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> One should be able to obtain informations with pkg-config. ie. wiith 
>>>>> cairo installed it works fine
>>>>> pkg-config --cflags cairo
>>>>> pkg-config --libs cairo
>>>>> But not with opencv4.
>>>>> 
>>>>> Joël 
>>>>> 
>>>>>> Le 9 févr. 2021 à 12:10, Marius Schamschula  a 
>>>>>> écrit :
>>>>>> 
>>>>>> I haven’t had time to look into that. I’m not the maintain of opencv4. 
>>>>>> For the moment I downgraded opencv to version 3.4.13.
>>>>>> 
>>>>>>> On Feb 9, 2021, at 2:28 AM, Joël Brogniart 
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> I'm trying to adapt a portfile for a Linux application to depend on 
>>>>>>> opencv4 instead of opencv. The building of the application use 
>>>>>>> pkg-config to find directory, library et compiler settings for 
>>>>>>> different tools (opencv, cairo…). This works correctly except for 
>>>>>>> opencv.
>>>>>>> 
>>>>>>> On Macports, the opencv4 port doesn't populate pkg-config data with its 
>>>>>>> own information. Is there an explanation for the missing data?
>>>>>> 
>>>>>> Marius
>>>>>> --
>>>>>> Marius Schamschula
>>>> 
>>> 
>> 
> 

Marius
--
Marius Schamschula

Re: pkg-config and opencv4

[Marius Schamschula]

Exactly my reading. However, there are many packages that depend on 
opencv/opencv4 that prefer to use pkg-config rather than cmake. In my case gmic 
in its multiple forms.

> On Feb 9, 2021, at 8:44 AM, Joël Brogniart  
> wrote:
> 
> Even if posts in the issus show workarounds, it also looks like opencv 
> developers consider the use of pkg-config .pc files obsolete so I will do 
> without.
> 
>> Le 9 févr. 2021 à 14:43, Marius Schamschula  a écrit :
>> 
>> It looks like this is an open issue:
>> 
>> https://github.com/opencv/opencv/issues/13154
>> 
>> It looks like one can patch opencv4 to fix this issue.
>> 
>> PS: I meant .pc not .po files.
>> 
>>> On Feb 9, 2021, at 7:40 AM, Marius Schamschula  
>>> wrote:
>>> 
>>> pkg-config only works if the package generates .po files. cairo does, 
>>> opencv does, but opencv4 does not.
>>> 
>>>> On Feb 9, 2021, at 6:44 AM, Joël Brogniart  
>>>> wrote:
>>>> 
>>>> 
>>>> One should be able to obtain informations with pkg-config. ie. wiith cairo 
>>>> installed it works fine
>>>> pkg-config --cflags cairo
>>>> pkg-config --libs cairo
>>>> But not with opencv4.
>>>> 
>>>> Joël 
>>>> 
>>>>> Le 9 févr. 2021 à 12:10, Marius Schamschula  a 
>>>>> écrit :
>>>>> 
>>>>> I haven’t had time to look into that. I’m not the maintain of opencv4. 
>>>>> For the moment I downgraded opencv to version 3.4.13.
>>>>> 
>>>>>> On Feb 9, 2021, at 2:28 AM, Joël Brogniart  
>>>>>> wrote:
>>>>>> 
>>>>>> I'm trying to adapt a portfile for a Linux application to depend on 
>>>>>> opencv4 instead of opencv. The building of the application use 
>>>>>> pkg-config to find directory, library et compiler settings for different 
>>>>>> tools (opencv, cairo…). This works correctly except for opencv.
>>>>>> 
>>>>>> On Macports, the opencv4 port doesn't populate pkg-config data with its 
>>>>>> own information. Is there an explanation for the missing data?
>>>>> 
>>>>> Marius
>>>>> --
>>>>> Marius Schamschula
>>> 
>> 
> 

Re: pkg-config and opencv4

[Marius Schamschula]

A quick look at the Portfile shows that opencv4 uses cmake.

It is rare that cmake based builds also gernerate .po files by default, but 
there may be a switch.

It might be worth opening a trac ticket.

> On Feb 9, 2021, at 5:37 AM, Joël Brogniart  
> wrote:
> 
> One should be able to obtain informations with pkg-config. ie. wiith cairo 
> installed it works fine
>  pkg-config --cflags cairo
>  pkg-config --libs cairo
> But not with opencv4.
> 
> Joël 
> 
>> Le 9 févr. 2021 à 12:10, Marius Schamschula  a écrit :
>> 
>> I haven’t had time to look into that. I’m not the maintain of opencv4. For 
>> the moment I downgraded opencv to version 3.4.13.
>> 
>>> On Feb 9, 2021, at 2:28 AM, Joël Brogniart  
>>> wrote:
>>> 
>>> I'm trying to adapt a portfile for a Linux application to depend on opencv4 
>>> instead of opencv. The building of the application use pkg-config to find 
>>> directory, library et compiler settings for different tools (opencv, 
>>> cairo…). This works correctly except for opencv.
>>> 
>>> On Macports, the opencv4 port doesn't populate pkg-config data with its own 
>>> information. Is there an explanation for the missing data?
>> 
>> Marius
>> --
>> Marius Schamschula

Marius
--
Marius Schamschula

Re: Desolate Condition

[Marius Schamschula]

Andrew,

MacPorts provides pre-built packages for more macOS versions than Homebrew.

However, MacPorts is very careful not to provide packages where the upstream 
license prohibits us from doing so.

Other pre-built packages are not provided if they depend on said packages to be 
build by our buildbots.

Installing on my Mac using MacPorts is much faster than on my servers under 
FreeBSD where everything literally has to be build locally, as pre-built 
packages may be up three months out of date.

> On Jan 26, 2021, at 9:40 AM, Andrew Janke  wrote:
> 
> 
> 
> On 1/26/21 10:12 AM, Christopher Nielsen wrote:
>>> Ken Cunningham wrote:
>>> 
>>> homebrew is in shambles.
>>> 
>>> their long-touted "no-sudo" and "no PATH" advantage from installing into 
>>> /usr/local has been eliminated by Apple as the horrible security threat it 
>>> always was. They have to retool into /opt/homebrew and make 10,000 builds 
>>> respect the build args now.
>>> 
>>> They stripped out all their universal handling code a few years ago, can't 
>>> put it back, and so can't do the critical universal builds any more. They 
>>> tell everyone universal is wasteful, lipo things manually, and run the 
>>> x86_64 homebrew on Apple Silicon.
>>> 
>>> So MacPorts, which works great from 10.4 PPC to 11.x arm64, is the place to 
>>> be.
>> 
>> Personnally, I’ve never actually tried HomeBrew, as I didn’t want anything 
>> installed into core OS areas. And after choosing  MacPorts years ago - 10+ 
>> at this point? - I’ve always been very happy with the experience. Enough so 
>> that I’m finally giving back, as a contributor!
>> 
>> One advantage that HomeBrew does have, though, is cachet: There are so many 
>> times when articles - or even organizations, such as Google - simply 
>> recommend using HomeBrew… with no mention of MacPorts.
>> 
>> So, my feeling is that we need to up our public relations game. Do we have 
>> an active social media presence, for example? (Twitter in particular?)
>> 
>> Of note, while I’m not an expert in social media relations, I’d happily 
>> volunteer to help with it.
>> 
>> Thoughts?
> 
> Hi! Long-time user of both Homebrew and MacPorts here; former Homebrew 
> maintainer.
> 
> It's definitely a PR issue; Homebrew is winning on that front.
> 
> IMHO, the other thing is that Homebrew is fun to use and accessible to 
> less-technical users. Friendlier command output, low-jargon documentation, 
> sense of humor, fun emojis. MacPorts feels like more of a "pro" thing and 
> serious sysadmin tool, and its command output can be kind of technical and 
> intimidating. I think the Homebrew approach is attractive to a lot of general 
> Mac users, especially those approaching a package manager for the first time.
> 
> Another big thing is that Homebrew ships binaries for everything, so you can 
> do a full Homebrew install of a big toolchain in just a few minutes, where it 
> might take hours to compile. MacPorts still builds everything from source, 
> right?
> 
> Those are the reasons I always recommend Homebrew to new Mac package manager 
> users, even though I think both are good tools.
> 
> Cheers,
> Andrew

Re: Shutting down the Atlas port

[Marius Schamschula]

Ryan,

I don’t know about the others, but I have the following installed w/o atlas

R
py-numpy
py-scipy
sundails2

> On Nov 5, 2020, at 4:35 PM, Ryan Schmidt  wrote:
> 
> On Nov 3, 2020, at 04:52, Vincent Habchi wrote:
> 
>> Atlas, the software meant to provide scientific computing tools with a 
>> high-performance assembly-based library has, IMHO, reached its end of life. 
>> 
>> My case is this:
>> 
>> • Last developer (unstable) release is more than two years old;
>> • Last stable release is twice older (2016);
>> • Consequently, ASM snippets Atlas relies on might not be up to date with 
>> the latest Intel processors;
>> • Atlas will prolly never be ported to the new ARM-based architecture Apple 
>> is about to unveil;
>> • The method used by Atlas to select the best assembly snippet (a.k.a 
>> “kernel”) for a given computation task is defeated by the power saving steps 
>> included in recent versions of MacOS, namely a gradual lowering of the 
>> priority of any power consuming task. This can lead to erratic, 
>> non-reproducible, and sub-optimal choices, rendering Atlas pointless;
>> • Atlas build time from sources varies around 3 to 4 hours, regardless of 
>> the number of cores available (the selection process is mono-threaded), 
>> which makes Atlas cumbersome to build, and still more cumbersome to debug, 
>> barring on the quickest machines;
>> • Since Atlas is CPU-based, no precompiled binaries should be available: at 
>> best, they will be suboptimal; at worse, they could contain unknown 
>> instructions old CPUs would crash on.
>> 
>> For all these reasons, I’m convinced that pulling the plug on Atlas is a 
>> good idea. Any thoughts?
> 
> Can all of the ports that currently depend on atlas be made to work correctly 
> without atlas? If so, that would probably be the first step. You can't remove 
> atlas while other ports depend on it.
> 
> 
> DSDP
> R
> esmf
> gr-specest
> itpp
> levmar
> lua-numlua
> nco
> psfex
> py-numpy
> py-scipy
> scamp
> shogun
> shogun-devel
> source-extractor
> stimfit
> sundials
> sundials2
> 

Marius
--
Marius Schamschula

Re: update to icu has again broken all the macports-clang compilers

[Marius Schamschula]

Also related to the icu update, *webkit* ports are broken.

For example, see https://trac.macports.org/ticket/60975 
<https://trac.macports.org/ticket/60975> and 
https://trac.macports.org/ticket/60977

> On Aug 12, 2020, at 9:37 AM, Ken Cunningham  
> wrote:
> 
> not exactly sure how I'm going to get around this just yet
> 
> have to find some compiler that still works somewhere -- gcc? to rebuild 
> libxmls2 and then again rebuild libxml2 +universal once some clang works 
> again...
> 
> configure:3623: $? = 1
> configure:3643: checking whether the C compiler works
> configure:3665: /opt/local/bin/clang-mp-3.7 -pipe -Os -arch x86_64 -arch i386 
> -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names -arch 
> x86_64 -arch i386 conftest.c  >&5
> dyld: Library not loaded: /opt/local/lib/libicui18n.65.dylib
>  Referenced from: /opt/local/lib/libxml2.2.dylib
>  Reason: image not found
> 

Marius
--
Marius Schamschula

Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

[Marius Schamschula]

Agreed.

I’ve chosen to have my main build machine run perl5.30, but that causes ports 
like help2man to try to reinstall perl5.28.

On my FreeBSD machines you set the Perl branch in /etc/make.conf, and all the 
Makefiles respect that setting.

Marius
--
Marius Schamschula




> On Jun 22, 2020, at 9:59 AM, Ken Cunningham  
> wrote:
> 
> A simple used-to-be-quick  build of "curl" now requires two different perls 
> installed.
> 
> Perhaps unavoidable in some cases, but if you look around the web, this is in 
> fact the #1 complaint about MacPorts: bloat.
> 
> It might be an idea for the admins to "set" the perl version all ports will 
> use (barring some actual real need for another), and then --- all-at-once -- 
> change it to some new version to avoid this.
> 
> And ideally we could look at changing it once every few years.
> 
> Ken

Re: [certbot] port upgrade fails

[Marius Schamschula]

Bjarne,

Indeed!

Marius
--
Marius Schamschula




> On Sep 2, 2019, at 6:57 AM, Bjarne D Mathiesen  
> wrote:
> 
> Marius Schamschula wrote:
>> Bjarne,
>> 
>> I’ve rolled your additions into my local Portfile:
>> 
>> https://github.com/Schamschula/macports/commit/2c9091b91e0980aeeb8f88faa00f118726bdc593
> 
> you've got an error in line 63 :
> - if {![variant_isset python36] && ![variant_isset python36]} {
> + if {![variant_isset python27] && ![variant_isset python36]} {
> 
>> 
>> I’ll push this change to macports-ports master with the next upstream
>> update.
>> 
>> BTW: I’m using the GitHub PortGroup. 
>> 
>> Marius
>> --
>> Marius Schamschula
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> --
> denne besked er skrevet i et (næsten) M$-frit miljø
> MacOS X 10.13.6 High Sierra :
>   17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
>   2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
> MacOS X 10.6.8 Snow Leopard :
>   Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
>   Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz

Re: [certbot] port upgrade fails

[Marius Schamschula]

Bjarne,

I’ve rolled your additions into my local Portfile:

https://github.com/Schamschula/macports/commit/2c9091b91e0980aeeb8f88faa00f118726bdc593

I’ll push this change to macports-ports master with the next upstream update.

BTW: I’m using the GitHub PortGroup. 

Marius
--
Marius Schamschula




> On Aug 31, 2019, at 1:23 PM, Marius Schamschula  wrote:
> 
> Bjarne,
> 
> Thanks for adding all those missing sub-ports!
> 
> I had seen many of these in the FreeBSD ports on my servers (I currently only 
> use certbot under FreeBSD, as I no longer maintain any macOS based servers 
> that are exposed to the internet).
> 
> With some minor tweaks, I’ll fold this into the main certbot Portfile.
> 
> Marius
> --
> Marius Schamschula
> 
> 
> 
> 
>> On Aug 31, 2019, at 1:13 PM, Bjarne D Mathiesen > <mailto:macint...@mathiesen.info>> wrote:
>> 
>> Bjarne D Mathiesen wrote:
>>> 
>>> Presently, I'm trying to modify py-acme & cerbot to use git instead .
>>> These two ports are among the for me mission critical ones.
>>> And I spent several days getting certbot to integrate with my dns
>>> service. ( I have to use "dns-01 challenge" because I use *.domain i my
>>> certs).
>>> 
>>> I'll might also take a go at doing variants for the various dns-services
>>> certbot supports natively ; but they - as well as the apache & ngix
>>> server integration - are of no interest to me, because I've got a really
>>> complicated apache server configuration .
>> 
>> I've got the subports working 邏
>> 
>> I've updated the certbot Portfile :
>>https://macports.mathiesen.info/portfiles/security/certbot/Portfile 
>> <https://macports.mathiesen.info/portfiles/security/certbot/Portfile>
>> 
>> Feel free to steal whatever you can/need 邏
>> 
>> #=> port -d sync
>> DEBUG: Copying /var/root/Library/Preferences/com.apple.dt.Xcode.plist to
>> /macports/var/macports/home/Library/Preferences
>> --->  Updating the ports tree
>> Synchronizing local ports tree from
>> file:///Volumes/Bjarne/WebServer/MacPorts/newPorts 
>> 
>> DEBUG: system: /macports/bin/portindex
>> /Volumes/Bjarne/WebServer/MacPorts/newPorts
>> Creating port index in /Volumes/Bjarne/WebServer/MacPorts/newPorts
>> 
>> Adding port security/certbot
>> Adding subport certbot-apache
>> Adding subport certbot-nginx
>> Adding subport certbot-dns-cloudflare
>> Adding subport certbot-dns-cloudxns
>> Adding subport certbot-dns-digitalocean
>> Adding subport certbot-dns-dnsimple
>> Adding subport certbot-dns-dnsmadeeasy
>> Adding subport certbot-dns-gehirn
>> Adding subport certbot-dns-google
>> Adding subport certbot-dns-linode
>> Adding subport certbot-dns-luadns
>> Adding subport certbot-dns-nsone
>> Adding subport certbot-dns-ovh
>> Adding subport certbot-dns-rfc2136
>> Adding subport certbot-dns-route53
>> Adding subport certbot-dns-sakuracloud
>> 
>> Total number of ports parsed:17
>> Ports successfully parsed:   17
>> Ports failed:0
>> Up-to-date ports skipped:3
>> 
>> #=> port info certbot-nginx
>> certbot-nginx @0.37.2 (security)
>> Variants: python27, (+)python37, universal
>> 
>> Description:  The Nginx plugin should work for most
>>  configurations. We recommend backing up Nginx
>>  configurations before using it (though you
>>  can also revert changes to configurations with
>>  certbot "--nginx rollback"). You can use it by
>>  providing the "--nginx" flag on
>>  the commandline.
>>  https://certbot.eff.org/docs/using.html#nginx
>> Homepage: https://certbot.eff.org/
>> 
>> Fetch Dependencies:   git
>> Build Dependencies:   py37-setuptools
>> Library Dependencies: py37-configargparse, py37-configobj,
>>  py37-cryptography, py37-future, py37-mock,
>>  py37-openssl, py37-parsedatetime, py37-psutil,
>>  py37-pyrfc3339, py37-six, py37-tz,
>>  py37-zopecomponent, py37-zope-deferredimport,
>>  py37-zope-deprecation, py37-zopehookable,
>>  py37-acme
>> Platforms:darwin
>> License:  Apache-2
>> Maintainers:  GitHub: BjarneDMat
>>  Policy: openmaintainer
>&g

Re: [certbot] port upgrade fails

[Marius Schamschula]

Bjarne,

Thanks for adding all those missing sub-ports!

I had seen many of these in the FreeBSD ports on my servers (I currently only 
use certbot under FreeBSD, as I no longer maintain any macOS based servers that 
are exposed to the internet).

With some minor tweaks, I’ll fold this into the main certbot Portfile.

Marius
--
Marius Schamschula




> On Aug 31, 2019, at 1:13 PM, Bjarne D Mathiesen  
> wrote:
> 
> Bjarne D Mathiesen wrote:
>> 
>> Presently, I'm trying to modify py-acme & cerbot to use git instead .
>> These two ports are among the for me mission critical ones.
>> And I spent several days getting certbot to integrate with my dns
>> service. ( I have to use "dns-01 challenge" because I use *.domain i my
>> certs).
>> 
>> I'll might also take a go at doing variants for the various dns-services
>> certbot supports natively ; but they - as well as the apache & ngix
>> server integration - are of no interest to me, because I've got a really
>> complicated apache server configuration .
> 
> I've got the subports working 邏
> 
> I've updated the certbot Portfile :
>https://macports.mathiesen.info/portfiles/security/certbot/Portfile
> 
> Feel free to steal whatever you can/need 邏
> 
> #=> port -d sync
> DEBUG: Copying /var/root/Library/Preferences/com.apple.dt.Xcode.plist to
> /macports/var/macports/home/Library/Preferences
> --->  Updating the ports tree
> Synchronizing local ports tree from
> file:///Volumes/Bjarne/WebServer/MacPorts/newPorts
> DEBUG: system: /macports/bin/portindex
> /Volumes/Bjarne/WebServer/MacPorts/newPorts
> Creating port index in /Volumes/Bjarne/WebServer/MacPorts/newPorts
> 
> Adding port security/certbot
> Adding subport certbot-apache
> Adding subport certbot-nginx
> Adding subport certbot-dns-cloudflare
> Adding subport certbot-dns-cloudxns
> Adding subport certbot-dns-digitalocean
> Adding subport certbot-dns-dnsimple
> Adding subport certbot-dns-dnsmadeeasy
> Adding subport certbot-dns-gehirn
> Adding subport certbot-dns-google
> Adding subport certbot-dns-linode
> Adding subport certbot-dns-luadns
> Adding subport certbot-dns-nsone
> Adding subport certbot-dns-ovh
> Adding subport certbot-dns-rfc2136
> Adding subport certbot-dns-route53
> Adding subport certbot-dns-sakuracloud
> 
> Total number of ports parsed: 17
> Ports successfully parsed:17
> Ports failed: 0
> Up-to-date ports skipped: 3
> 
> #=> port info certbot-nginx
> certbot-nginx @0.37.2 (security)
> Variants: python27, (+)python37, universal
> 
> Description:  The Nginx plugin should work for most
>  configurations. We recommend backing up Nginx
>  configurations before using it (though you
>  can also revert changes to configurations with
>  certbot "--nginx rollback"). You can use it by
>  providing the "--nginx" flag on
>  the commandline.
>  https://certbot.eff.org/docs/using.html#nginx
> Homepage: https://certbot.eff.org/
> 
> Fetch Dependencies:   git
> Build Dependencies:   py37-setuptools
> Library Dependencies: py37-configargparse, py37-configobj,
>  py37-cryptography, py37-future, py37-mock,
>  py37-openssl, py37-parsedatetime, py37-psutil,
>  py37-pyrfc3339, py37-six, py37-tz,
>  py37-zopecomponent, py37-zope-deferredimport,
>  py37-zope-deprecation, py37-zopehookable,
>  py37-acme
> Platforms:darwin
> License:  Apache-2
> Maintainers:  GitHub: BjarneDMat
>  Policy: openmaintainer
> 
> #=> port install certbot-nginx
> --->  Computing dependencies for certbot-nginx
> --->  Fetching distfiles for certbot-nginx
> --->  Verifying checksums for certbot-nginx
> --->  Extracting certbot-nginx
> --->  Configuring certbot-nginx
> --->  Building certbot-nginx
> --->  Staging certbot-nginx into destroot
> --->  Installing certbot-nginx @0.37.2_0+python37
> --->  Activating certbot-nginx @0.37.2_0+python37
> --->  Cleaning certbot-nginx
> --->  Scanning binaries for linking errors
> --->  No broken files found.
> --->  No broken ports found.
> 
> #=> port install certbot-dns-cloudflare
> --->  Computing dependencies for certbot-dns-cloudflare
> --->  Fetching distfiles for certbot-dns-cloudflare
> --->  Verifying checksums for certbot-dns-cloudflare
> --->  Extracting certbot-dns-cloud

Re: [certbot] port upgrade fails

[Marius Schamschula]

Bjarne,

There are two ways of implementing what I have in mind:

1) variants, e.g. certbot-apache could be installed as certbot +apache 
(variants are very common in Portfiles)

2) sub-ports, where there are several sub-ports in a Portfile, e.g. php (maybe 
an extreme example) or sqlite3.

I didn’t develop the certbot-apache and certbot-nginx ports, but took over as 
maintainer, as I maintain py-acme and certbot. I would have implemented these 
as variants.

At this point option 2 is better, as the (sub-)port name won’t change, but I 
can update all three together  in a single Portfile.

> On Aug 30, 2019, at 9:24 AM, Bjarne D Mathiesen  
> wrote:
> 
> Marius Schamschula wrote:
>> Bjarne,
>> 
>> I’m probably going to combine the current three certbot* Portfiles into
>> a single Portfile in the near future.
> 
> Could you please point to a port, that implement what you want to do, as
> an example for me to follow :-) 邏
> 
>> 
>> Marius
>> --
>> Marius Schamschula
>> 
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> --
> denne besked er skrevet i et (næsten) M$-frit miljø
> MacOS X 10.13.6 High Sierra :
>   17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
>   2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
> MacOS X 10.6.8 Snow Leopard :
>   Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
>   Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz

Re: [certbot] port upgrade fails

[Marius Schamschula]

Bjarne,

I understand your situation. However, I only update when there is an official 
release. There is no such tag in GitHub.

What you are requesting is a development branch. I don’t want to chase that.

What does trouble me is your issue getting the 0.37.2 version downloaded. I 
don’t test the download after my initial build that are used to update the 
Portfiles.

There seems to be an issue with pypi.org.

> On Aug 30, 2019, at 7:48 AM, Bjarne D Mathiesen  
> wrote:
> 
> Marius Schamschula wrote:
>> Bjarne,
>> 
>> I’m not sure where you found a 0.38.0 release. It is not available @
>> GitHub or PyPi. Version 0.37.2 is current.
> 
> On certbot's github page - linked in (2) - they've bumped the version to
> 0.38.0 on Aug 21, 2019
> 
> I've "git clone https://github.com/certbot/certbot.git;
> bjarne@0125000629 14:26:22 ~/WebServer/MacPorts/git/certbot
> $=> grep -R 0.38.0 *
> CHANGELOG.md:## 0.38.0 - master
> acme/setup.py:version = '0.38.0.dev0'
> certbot/__init__.py:__version__ = '0.38.0.dev0'
> 
>> 
>> The certbot and py-acme Portfiles pull archives from pypi.org
>> <http://pypi.org>. ;
> 
> I can see that in the Porfiles ; but 0.37.2 fails to install as I
> describe in (1) and the thread "[certbot] failure to download distfiles"
> @ 24/08/2019, 17.57 . And I've tried daily on at least two of my computers.
> 
> When I change the Portfile back to 0.37.1, there're no problems.
> 
>> 
>> I’m probably going to combine the current three certbot* Portfiles into
>> a single Portfile in the near future.
> 
> Presently, I'm trying to modify py-acme & cerbot to use git instead .
> These two ports are among the for me mission critical ones.
> And I spent several days getting certbot to integrate with my dns
> service. ( I have to use "dns-01 challenge" because I use *.domain i my
> certs).
> 
> I'll might also take a go at doing variants for the various dns-services
> certbot supports natively ; but they - as well as the apache & ngix
> server integration - are of no interest to me, because I've got a really
> complicated apache server configuration .
> 
>> 
>> Marius
>> --
>> Marius Schamschula
>> 
>>> On Aug 29, 2019, at 5:53 PM, Bjarne D Mathiesen
>>> mailto:macint...@mathiesen.info>> wrote:
>>> 
>>> 1) upgrading these fails :
>>>certbot  0.37.1_0 < 0.37.2_0
>>>py37-acme0.37.1_0 < 0.37.2_0
>>>  I'm getting http 404 error on all repositories
>>> 
>>> 2) they have been upgraded to 0.38.0
>>>https://github.com/certbot/certbot/
>>>   but I'm also getting http 404 on all repositories for that
>>> 
>>> It seems as if all the necessry files are in
>>>https://github.com/certbot/certbot.git
>>> but I don't know how to properly integrate a git in a portfile
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> --
> denne besked er skrevet i et (næsten) M$-frit miljø
> MacOS X 10.13.6 High Sierra :
>   17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
>   2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
> MacOS X 10.6.8 Snow Leopard :
>   Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
>   Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz

Re: [certbot] port upgrade fails

[Marius Schamschula]

Bjarne,

I’m not sure where you found a 0.38.0 release. It is not available @ GitHub or 
PyPi. Version 0.37.2 is current.

The certbot and py-acme Portfiles pull archives from pypi.org.

I’m probably going to combine the current three certbot* Portfiles into a 
single Portfile in the near future.

Marius
--
Marius Schamschula




> On Aug 29, 2019, at 5:53 PM, Bjarne D Mathiesen  
> wrote:
> 
> 1) upgrading these fails :
>certbot  0.37.1_0 < 0.37.2_0
>py37-acme0.37.1_0 < 0.37.2_0
>  I'm getting http 404 error on all repositories
> 
> 2) they have been upgraded to 0.38.0
>https://github.com/certbot/certbot/
>   but I'm also getting http 404 on all repositories for that
> 
> It seems as if all the necessry files are in
>https://github.com/certbot/certbot.git
> but I don't know how to properly integrate a git in a portfile
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> --
> denne besked er skrevet i et (næsten) M$-frit miljø
> MacOS X 10.13.6 High Sierra :
>   17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
>   2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
> MacOS X 10.6.8 Snow Leopard :
>   Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
>   Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz

Re: Can buildbots open a window?

[Marius Schamschula]

IIRC, several octave packages also attempt this in the configure phase. I don’t 
remember off-hand which ones.

Marius
--
Marius Schamschula

On Jan 22, 2019, at 7:48 AM, Marcus Calhoun-Lopez  wrote:
> 
> In trying to fix one bug [1], I seem to have created another [2].
> I have been unable to fix the second bug, so I am revisiting the first.
> 
> When building, octave tries to open a window (using Qt).
> As far as I can tell, this caused an error with the buildbots [1].
> Is it true that the buildbots cannot open a window?
> If so, can anyone think of a workaround?
> 
> Thanks,
> Marcus
> 
> [1] https://trac.macports.org/ticket/57288
> [2] https://trac.macports.org/ticket/57850

Re: Error writing data to TLS socket: The specified session has been invalidated for some reason.

[Marius Schamschula]

Ken,

I just installed for surf and epiphany. I tested with my own websites that are 
using letsencrypt certificates.

Indeed, both browsers are broken, in the case of epiphany, I couldn’t even 
download the http version w/o an error, as it still tried pulling an external 
resource using https.

However, I doubt that the issue is with gnutls: I used both aria2 
+gnutls+sqlite3 (my default build) and curl +gnutls to pull down two of my 
https home pages as well as gitHub.com/macports/ w/o any issues.

The ABI for gnutls 3.6.x is a superset of version 3.5.x, no previous symbols 
have been removed or modified, only new functionality has been added:

https://lists.gnupg.org/pipermail/gnutls-devel/2017-August/008484.html

Marius
--
Marius Schamschula




> On Jan 18, 2019, at 6:08 PM, Ken Cunningham  
> wrote:
> 
> I’m not sure which port is causing this error I’m seeing since recent updates.
> 
> To see it, use something like epiphany or surf
> 
> surf www.github.com
> epiphany www.github.com
> 
> 
> I think the error is in gnutls, maybe in libidn2?
> 
> I’m narrowing it down to perhaps the srp authentication module, but I’m out 
> of my depth to an extent.
> 
> i’m not sure yet if it’s a MacPorts thing, or some new bug that slipped into 
> gnutls.
> 
> Anyway, it seems to stop the use of things that use gnutls against some 
> authenticating websites.
> 
> Ken

Re: leave revision 0 line in Portfile

[Marius Schamschula]

+1

Along with adding the size checksum, where missing.

> On Dec 24, 2018, at 10:14 AM, Michael Dickens  wrote:
> 
> I'm in agreement here about keeping "revision 0" lines & will start 
> implementing this in my ports as they get updates. - MLD
> 
> On Sun, Dec 23, 2018, at 5:54 AM, Mojca Miklavec wrote:
>> Dear Ken,
>> 
>> On Sat, 22 Dec 2018 at 16:49, Ken Cunningham wrote:
>>> 
>>> I would like to propose we stop asking people to remove the "revision 0" 
>>> line in Portfiles.
>> 
>> I totally agree.
>> 
>> I mean:
>> - if users submit a PR with "revision 0", we should not ask them to
>> remove that line
>> - if users submit a PR with revision removed, we should not ask them
>> to add it back either (at least not until we add that line to all
>> other ports for some well-grounded reasons)
>> - if users forget to change "revision 99" after version increase, we
>> should still ask them to either remove it or change it to 0
>> 
>>> So how about we embrace the "0" and move on to stuff that matters more!!!
>> 
>> +1
>> 
>> Mojca

Marius

Re: Looking for someone to create an initial Portfile for GitLab Runner (Go)

[Marius Schamschula]

Nils,

I didn’t want to dig down several layers, so the Portfile is incomplete.

I’ve put it in my personal repo:

https://github.com/Schamschula/macports/blob/master/devel/gitlab-runner/Portfile


> On Nov 28, 2018, at 4:32 AM, Nils Breunese  wrote:
> 
> Thanks for looking into this. Where can your Portfile be found?
> 
> Nils.
> 
>> Op 27 nov. 2018, om 20:52 heeft Marius Schamschula  
>> het volgende geschreven:
>> 
>> Nils,
>> 
>> I tried to put together a quick Portfile for gitlab-runner. The included 
>> Makefile still insists on downloading rebuild docker files
>> 
>> Judging by the FreeBSD port[2], that seems to be unavoidable.
>> 
>>> On Nov 27, 2018, at 1:19 PM, Nils Breunese  wrote:
>>> 
>>> Hello,
>>> 
>>> I’d like to be able to install GitLab Runner [0] via MacPorts. I’ve already 
>>> created a Portfile [1] that installs this single binary tool, but I’ve been 
>>> informed this tool should be built from source by the Portfile. I’m not 
>>> familiar enough with Go builds to create the initial Portfile and too tight 
>>> on time to learn it soon. So, I’m looking for someone that could create the 
>>> initial Portfile. I’d be willing to maintain this Portfile after the 
>>> initial creation to keep it up to date.
>>> 
>>> If anyone can help with this, please let me know. The source is hosted 
>>> here: https://gitlab.com/gitlab-org/gitlab-runner
>>> 
>>> Thanks, Nils.
>>> 
>>> [0] https://docs.gitlab.com/runner/
>>> [1] https://github.com/macports/macports-ports/pull/3081
>> 
>> [2] https://www.freshports.org/devel/gitlab-runner/
>> 
>> Marius
>> --
>> Marius Schamschula
>> 
>> 
>> 
> 

Marius
--
Marius Schamschula

Re: Looking for someone to create an initial Portfile for GitLab Runner (Go)

[Marius Schamschula]

Nils,

I tried to put together a quick Portfile for gitlab-runner. The included 
Makefile still insists on downloading rebuild docker files

Judging by the FreeBSD port[2], that seems to be unavoidable.

> On Nov 27, 2018, at 1:19 PM, Nils Breunese  wrote:
> 
> Hello,
> 
> I’d like to be able to install GitLab Runner [0] via MacPorts. I’ve already 
> created a Portfile [1] that installs this single binary tool, but I’ve been 
> informed this tool should be built from source by the Portfile. I’m not 
> familiar enough with Go builds to create the initial Portfile and too tight 
> on time to learn it soon. So, I’m looking for someone that could create the 
> initial Portfile. I’d be willing to maintain this Portfile after the initial 
> creation to keep it up to date.
> 
> If anyone can help with this, please let me know. The source is hosted here: 
> https://gitlab.com/gitlab-org/gitlab-runner
> 
> Thanks, Nils.
> 
> [0] https://docs.gitlab.com/runner/
> [1] https://github.com/macports/macports-ports/pull/3081 
> <https://github.com/macports/macports-ports/pull/3081>
[2] https://www.freshports.org/devel/gitlab-runner/

Marius
--
Marius Schamschula

Re: Potential problem with small subset of Cocoa ports on Xcode 10

[Marius Schamschula]

Perry,

I’ve just run into this problem with TeXShop4. The build phase succeeds, but 
destroot fails.

How does one revert to the “old” build system under Xcode 10?

> On Sep 28, 2018, at 8:12 AM, Perry E. Metzger  wrote:
> 
> [resending as I messed up the first time...]
> 
> On Fri, 28 Sep 2018 00:21:17 -0500 Ryan Schmidt
>  wrote:
>> On Sep 26, 2018, at 17:14, Perry E. Metzger wrote:
>> 
>>> It seems that there's a bad interaction between Xcode 10's new
>>> build system and certain ports. "pinentry-mac" is the only one
>>> I've hit so far but there may be others. The kludge is to tell
>>> Xcode 10 (if it is the version running) to use its old build
>>> system. If you hit this, try the kludge I've added to
>>> "pinentry-mac" as a temporary workaround.
>>> 
>>> (Note that Xcode 10 also seems to be much more strict about
>>> include file paths, which necessitated a distinct required fix
>>> on "pinentry-mac".)
>> 
>> Could you describe what the problem or error is, so we'll
>> recognize it if we run into it?
> 
> Sorry for being too oblique. It only impacts things built from Xcode
> projects, like Mac GUI apps.
> 
> The deal is that there's a distinction now between the "new" and
> "old" Xcode build system. "New" was added in 10. Xcode projects can
> simply fail to destroot when built with "new" because of an apparent
> bug. (We're pretty sure it's a bug because it will hit an empty,
> brand-new Cocoa project.)
> 
> You can see the symptoms by trying to build pinentry-mac without
> turning off the new build system.
> 
> You will hit this only on Xcode projects, not on building ordinary
> stuff, and you can kludge around it by turning off the new build
> system for the destroot phase as I've done for
> pinentry-mac. Unfortunately the flag is only understood by Xcode 10
> so it can't be just used all the time.
> 
> Note that the new build system is also much more strict about many
> things, you may have to clean up latent sloppy code (like the use of
>  for something that should be "include.h" in C) to get
> things to build with the new build system.
> 
> Perry
> --
> Perry E. Metzger  pmetz...@macports.org

Marius
--
Marius Schamschula

Re: tcl-sqlite3

[Marius Schamschula]

On Aug 28, 2018, at 1:27 AM, Joshua Root  wrote:
> 
> Moving to macports-dev.
> 
> On 2018-8-27 23:49 , Marius Schamschula wrote:
>>> On Aug 27, 2018, at 1:43 AM, Joshua Root >> <mailto:j...@macports.org>> wrote:
>>> 
>>> On 2018-8-27 10:37 , Ryan Schmidt wrote:
>>>> On Aug 26, 2018, at 07:54, Marius Schamschula wrote:
>>>> 
>>>>> On Aug 26, 2018, at 7:34 AM, Marius Schamschula wrote:
>>>>> 
>>>>> Note: tcl has to be modified not to install
>>>>> 
>>>>> ${prefix}/share/man/mann/sqlite3.n.gz
>>>> 
>>>> Do you want to do that or should I?
>>> 
>>> What about the rest of the redundant sqlite3 package that it installs?
>> 
>> The sqlite3-tcl subport uses the same source tarball as sqlite3 itself.
>> Do we want to duplicate the download and storage?
> 
> No, I wasn't suggesting duplicating, quite the opposite. I'm saying the
> tcl port has more than just the man page that should be pruned if we're
> providing this in a separate port.

Indeed. I made a local version of the tcl Portfile which does not build the 
sqlite3 extension (the only way to do this is to remove the whole extension 
package from the source tree).

I haven’t uploaded this to Github, as I’m unsure if the best way forward is to 
add a Portfile note about sqlite3-tcl having been split from tcl or to 
automatically install it somehow (the tcl Portfile can’t do it as sqlite3-tcl 
depends on tcl).

Marius
--
Marius Schamschula

Re: [macports-ports] branch master updated: octave 4.4.0: add missing qt5-sqlite-plugin dependency

[Marius Schamschula]

Ryan,

> On Jun 2, 2018, at 5:16 PM, Ryan Schmidt  wrote:
> 
> 
> On Jun 2, 2018, at 16:51, Marius Schamschula wrote:
> 
>> Marius Schamschula (Schamschula) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> 
>> https://github.com/macports/macports-ports/commit/4c13d30353d2d95d746769aad50070aebdb4b688
>> 
>> The following commit(s) were added to refs/heads/master by this push:
>> 
>> new 4c13d30  octave 4.4.0: add missing qt5-sqlite-plugin dependency
>> 
>> 4c13d30 is described below
>> 
>> 
>> commit 4c13d30353d2d95d746769aad50070aebdb4b688
>> 
>> Author: Marius Schamschula
>> AuthorDate: Sat Jun 2 16:51:26 2018 -0500
>> 
>> 
>>octave 4.4.0: add missing qt5-sqlite-plugin dependency
> 
> 
>> @@ -408,7 +408,7 @@ variant qt4 conflicts qt5 description {build the GUI 
>> using Qt4} {
>> variant qt5 conflicts qt4 description {build the GUI using Qt5} {
>> PortGroup qt5 1.0
>> qt5.depends_component qttools
>> 
>> -depends_lib-append port:qscintilla-qt5
>> +depends_lib-append port:qscintilla-qt5 port:qt5-sqlite-plugin
> 
> Shouldn't that be:
> 
> qt5.depends_component   qttools sqlite-plugin

That shows my ignorance of the qt5 PortGroup…

However, it should build either way. Will commit fix shortly.

Marius
--
Marius Schamschula

Re: [MacPorts] #56502: gcc5 @5.5.0_1 error: expected initializer before 'API_AVAILABLE'

[Marius Schamschula]

Murray, 

I see no change in the revision number.

However, that should not matter: as 5.5.0_1 did not install, the new changes 
should still be applied on your platform.

The update typically takes several hours to post to the main repository. So 
wait a bit and try again.

> On May 18, 2018, at 1:33 PM, Murray Eisenberg <mur...@math.umass.edu> wrote:
> 
> I’m still getting a long build that’s aborted with exactly the error:
> 
> :info:build 
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:663:61: 
> error: expected initializer before 'API_AVAILABLE’ 
> 
> - Should the version still be gcc5 @5.5.0_1? 
> 
> - Is there an issue of delay in getting the patched version posted in the 
> macports repository?
> 
> 
>> On 18 May2018, at 11:42 AM, MacPorts <nore...@macports.org 
>> <mailto:nore...@macports.org>> wrote:
>> 
>> #56502: gcc5 @5.5.0_1 error: expected initializer before 'API_AVAILABLE'
>> --+
>>  Reporter:  murrayE  |  Owner:  (none)
>>  Type:  defect   | Status:  new
>>  Priority:  Normal   |  Milestone:
>> Component:  ports|Version:  2.4.4
>> Resolution:   |   Keywords:
>>  Port:  gcc5 |
>> --+
>> 
>> Comment (by kencu):
>> 
>> See <https://github.com/macports/macports-ports/pull/1830 
>> <https://github.com/macports/macports-ports/pull/1830>>.
>> 
>> -- 
>> Ticket URL: <https://trac.macports.org/ticket/56502#comment:18 
>> <https://trac.macports.org/ticket/56502#comment:18>>
>> MacPorts <https://www.macports.org/ <https://www.macports.org/>>
>> Ports system for macOS
> 
> ——
> Murray Eisenbergmur...@math.umass.edu 
> <mailto:mur...@math.umass.edu>
> Mathematics & Statistics Dept.   
> Lederle Graduate Research Tower  phone 240 246-7240 (H)
> University of Massachusetts
> 710 North Pleasant Street 
> Amherst, MA 01003-9305
> 
> 
> 
> 

Marius
--
Marius Schamschula

Re: regex for finding all ports using the cxx11 1.0 PG and changing them en-masse to the cxx11 1.1 PG

[Marius Schamschula]

Drat. Autocorrect strikes again. The regex should be:


port file all | xargs grep cxx11 | grep 1.0


> On May 18, 2018, at 1:17 PM, Marius Schamschula <li...@schamschula.com> wrote:
> 
> Ken,
> 
> A quick regex:
> 
> port file all | args grep cxx11 | grep 1.0
> 
> There are currently 57 ports.
> 
>> On May 18, 2018, at 12:50 PM, Ken Cunningham 
>> <ken.cunningham.web...@gmail.com <mailto:ken.cunningham.web...@gmail.com>> 
>> wrote:
>> 
>> It seems that there is no reason for a port to still be in the cxx11 1.0 PG.
>> 
>> I stumble across them from time to time still.
>> 
>> Do any of the regex-masters have an easy way to find all the cxx11 1.0 PG 
>> entries and change them all to 1.1 PG?
>> 
>> Thanks, 
>> 
>> Ken
> 
> Marius
> --
> Marius Schamschula
> 
> 
> 
> 

Marius
--
Marius Schamschula

Re: regex for finding all ports using the cxx11 1.0 PG and changing them en-masse to the cxx11 1.1 PG

[Marius Schamschula]

Ken,

A quick regex:

port file all | args grep cxx11 | grep 1.0

There are currently 57 ports.

> On May 18, 2018, at 12:50 PM, Ken Cunningham 
> <ken.cunningham.web...@gmail.com> wrote:
> 
> It seems that there is no reason for a port to still be in the cxx11 1.0 PG.
> 
> I stumble across them from time to time still.
> 
> Do any of the regex-masters have an easy way to find all the cxx11 1.0 PG 
> entries and change them all to 1.1 PG?
> 
> Thanks, 
> 
> Ken

Marius
--
Marius Schamschula

Re: [macports-ports] 02/02: py-python-augeas05: mark as obsolete

[Marius Schamschula]

Ryan,

Thanks for the hint!

https://github.com/macports/macports-ports/commit/beecab8dc9d68c7aab16e240d3890fe9c6ddfbda

> On May 7, 2018, at 8:14 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
> On May 7, 2018, at 08:06, Marius Schamschula wrote:
> 
>> What is the proper way of dealing with obsoleted subports?
> 
> For each subport, mark it replaced by its replacement.
> 
> The py-cherrypy3 port shows one way that this could be accomplished.
> 

Marius
--
Marius Schamschula

Re: [macports-ports] 02/02: py-python-augeas05: mark as obsolete

[Marius Schamschula]

Ryan,

What is the proper way of dealing with obsoleted subports?

> On May 7, 2018, at 7:54 AM, Ryan Schmidt <ryandes...@macports.org 
> <mailto:ryandes...@macports.org>> wrote:
> 
> 
> On May 5, 2018, at 10:14, Marius Schamschula wrote:
> 
>> Marius Schamschula (Schamschula) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> 
>> https://github.com/macports/macports-ports/commit/183d848728bcdec1ac30dce5260f0437feeda485
>>  
>> <https://github.com/macports/macports-ports/commit/183d848728bcdec1ac30dce5260f0437feeda485>
>> 
>> commit 183d848728bcdec1ac30dce5260f0437feeda485
>> 
>> Author: Marius Schamschula
>> AuthorDate: Sat May 5 10:14:16 2018 -0500
>> 
>> 
>>py-python-augeas05: mark as obsolete
>> 
>> ---
>> python/py-python-augeas05/Portfile | 28 +---
>> 1 file changed, 5 insertions(+), 23 deletions(-)
>> 
>> 
>> diff --git a/python/py-python-augeas05/Portfile 
>> b/python/py-python-augeas05/Portfile
>> index 51038ea..648168e 100644
>> --- a/python/py-python-augeas05/Portfile
>> +++ b/python/py-python-augeas05/Portfile
>> @@ -1,31 +1,13 @@
>> # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>> 
>> PortSystem  1.0
>> -PortGroup   python 1.0
>> +replaced_by py-python-augeas
>> +PortGroup   obsolete 1.0
>> 
>> namepy-python-augeas05
>> -set real_name   python-augeas
>> epoch   1
>> version 0.5.0
>> -python.versions 27 34 35 36
> 
> This abruptly removed the py27-python-augeas05, py34-python-augeas05, 
> py35-python-augeas05, py36-python-augeas05 subports without transitioning 
> them to the replacement subports under the py-python-augeas port.
> 
> 

Marius
--
Marius Schamschula






Marius
--
Marius Schamschula

Re: [macports-ports] branch master updated: octave-octproj: fix build against proj4

[Marius Schamschula]

Ryan,

> On Mar 27, 2018, at 8:44 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
> On Mar 27, 2018, at 08:39, Marius Schamschula wrote:
> 
>> Marius Schamschula (Schamschula) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> 
>> https://github.com/macports/macports-ports/commit/94a0268cc3d8b7a46705b71c7f94a72255249587
>> 
>> The following commit(s) were added to refs/heads/master by this push:
>> 
>> new 94a0268  octave-octproj: fix build against proj4
>> 
>> 94a0268 is described below
>> 
>> 
>> commit 94a0268cc3d8b7a46705b71c7f94a72255249587
>> 
>> Author: Marius Schamschula
>> AuthorDate: Tue Mar 27 08:39:24 2018 -0500
>> 
>> 
>>octave-octproj: fix build against proj4
>> 
>> ---
>> math/octave-octproj/Portfile| 13 +++---
>> math/octave-octproj/files/patch-flags.diff  |  2 +-
>> math/octave-octproj/files/patch-proj_api.h.diff | 33 
>> +
>> 3 files changed, 43 insertions(+), 5 deletions(-)
> 
> 
>> +post-patch {
>> +reinplace "s|%PREFIX%|${prefix}|" ${worksrcpath}/src/Makefile
>> +copy ${prefix}/lib/proj49/include/proj_api.h ${worksrcpath}/src/
>> +}
> 
>> +-#include
>> ++#include "proj_api.h"
> 
> Yow. Isn't there a cleaner way to accomplish this? Isn't the problem just 
> because of -I/opt/local/include in CPPFLAGS, and if so, can't it be solved by 
> prepending -I/opt/local/lib/proj49/include to CPPFLAGS?
> 

My bad: l tried patching the Makefile, but modified CFLAGS rather than CPFLAGS. 

https://github.com/macports/macports-ports/commit/77ea2fb4cfe60ff0add1be3fbbb320052a75dd02

Marius
--
Marius Schamschula

Re: [macports-ports] branch master updated: py-octave_kernel: don't try to install a file on every parse

[Marius Schamschula]

Joshua, Ryan,

Sorry about that. When running portindex, this error confused me as well. The 
problem was that I meant to run this as part of post-destroot, but didn’t 
implement it that way.

> On Feb 2, 2018, at 3:55 PM, Ryan Schmidt <ryandes...@macports.org 
> <mailto:ryandes...@macports.org>> wrote:
> 
> 
> On Jan 29, 2018, at 20:23, Joshua Root wrote:
> 
>> Joshua Root (jmroot) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> 
>> https://github.com/macports/macports-ports/commit/2e764efee3293478fc1dd9788d64391ce2274b56
>>  
>> <https://github.com/macports/macports-ports/commit/2e764efee3293478fc1dd9788d64391ce2274b56>
>> 
>> The following commit(s) were added to refs/heads/master by this push:
>> 
>> new 2e764ef  py-octave_kernel: don't try to install a file on every parse
>> 
>> 2e764ef is described below
>> 
>> 
>> commit 2e764efee3293478fc1dd9788d64391ce2274b56
>> 
>> Author: Joshua Root
>> AuthorDate: Tue Jan 30 13:22:04 2018 +1100
>> 
>>py-octave_kernel: don't try to install a file on every parse
>> 
>>Also don't bypass destroot, and don't make the subports conflict.
>>Fortunately this should have failed due to permissions, so no rev bump
>>or cleanup code should be necessary.
> 
> It did cause a kernel.json file to appear unexpectedly in the ports tree on 
> the private rsync server. Because it was installed with 640 permissions, it 
> caused a permissions error when the public rsync server tried to get it, 
> which the administrator of the public server reported to me today:
> 
>> rsync: send_files failed to open 
>> "release/ports/python/py-octave_kernel/${prefix}/share/py-octave_kernel/kernel.json"
>>  (in macports): Permission denied (13)
> 
> Manually removing that "${prefix}" directory from the server has cleared up 
> the problem and syncs to the public server are happening normally again.
> 
> 

Marius
--
Marius Schamschula






Marius
--
Marius Schamschula

Re: Questions on Apache2 + mods

[Marius Schamschula]

Eric,

> On Nov 27, 2017, at 5:38 PM, iEFdev <e...@iefdev.se> wrote:
> 
> Hi,
> 
> Just brief before I start writing anything… If i have 
> questions/request/suggestion for changes on a port (apache2), should I do 
> that here (ie. discuss it first), or perhaps in the tracker->request (&/or 
> enhancment). There are also a couple of mod_* I'm missing and would like to 
> hear about them.
> 
I think your approach is correct:

1) the list is a good platform for discussing enhancements and additions

2) https://trac.macports.org is the proper place to ask for enhancements and 
additions to be implemented

3) openning a PR at https://github.com/macports/macports-ports with suggested 
enhancements and additions may be the fastest way to get them in place
> // I'm planning to move from my own custom Apache installation, to MacPorts.
> · Eric

Marius
--
Marius Schamschula

Re: ocaml ports need love

[Marius Schamschula]

Perry,

Since February almost (all?) ocaml ports have been nomaintainer, as mww 
relinquished maintainership.

See: 
https://github.com/macports/macports-ports/commit/2e31448cc2f8f2cbf65766288d2a8cafb738e5b8

Volunteers welcome!

> On Oct 23, 2017, at 7:20 PM, Perry E. Metzger <pe...@piermont.com> wrote:
> 
> Howdy!
> 
> The ocaml ecosystem and everything depending on it is rotting a bit.
> See, for example, ticket #52844. We're thus far behind on upgrading
> anything downstream, like Coq.
> 
> Thoughts on what we could do to goose this? There's going to be a
> need to fix a bunch of stuff in the course of upgrading.
> 
> Perry
> -- 
> Perry E. Metzger      pe...@piermont.com

Marius
--
Marius Schamschula

Re: [macports-ports] branch master updated: apache2: back up configuration files before activating

[Marius Schamschula]

Ryan,

I’m currently changing the approach to this. However, on the original approach, 
I went based on the .conf files installed by my local build (under Sierra).

The new approach globs the files in destroot, so it should only operate on the 
files present.

https://git.io/vdQFy

> On Oct 18, 2017, at 3:50 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
> On Oct 18, 2017, at 15:40, Marius Schamschula wrote:
> 
>> Marius Schamschula (Schamschula) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> 
>> https://github.com/macports/macports-ports/commit/b7e97e72c9811817fe802ae19891675a65dbc5cc
>> 
>> The following commit(s) were added to refs/heads/master by this push:
>> 
>> new b7e97e7  apache2: back up configuration files before activating
>> 
>> b7e97e7 is described below
>> 
>> 
>> commit b7e97e72c9811817fe802ae19891675a65dbc5cc
>> 
>> Author: Marius Schamschula <m...@macports.org>
>> AuthorDate: Wed Oct 18 15:40:12 2017 -0500
>> 
>> 
>>apache2: back up configuration files before activating
>> 
>> ---
>> www/apache2/Portfile | 14 +-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>> 
>> 
>> diff --git a/www/apache2/Portfile b/www/apache2/Portfile
>> 
>> index ecdd6b4..4f21ecd 100644
>> 
>> --- a/www/apache2/Portfile
>> 
>> +++ b/www/apache2/Portfile
>> 
>> @@ -1,11 +1,11 @@
>> 
>> # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>> 
>> PortSystem  1.0
>> 
>> -# Untested
>> 
>> PortGroup   apache2 1.0
>> 
>> nameapache2
>> version 2.4.28
>> 
>> +revision1
>> 
>> categories  www
>> maintainers {ryandesign @ryandesign} mathiesen.info:macintosh 
>> pixilla openmaintainer
>> license Apache-2
>> 
>> @@ -125,6 +125,18 @@ pre-activate {
>> 
>> }
>> }
>> }
>> 
>> +
>> 
>> +# back up configuration files
>> 
>> +set systemTime [clock seconds]
>> 
>> +set date_str [clock format ${systemTime} -format {%Y%m%d}]
>> 
>> +copy ${apache2.sysconfdir}/httpd.conf 
>> ${apache2.sysconfdir}/httpd.conf.${date_str}
>> 
>> +foreach f "httpd-autoindex.conf httpd-dav.conf httpd-default.conf \
>> 
>> +   httpd-fcgid.conf httpd-info.conf httpd-languages.conf \
>> 
>> +   httpd-manual.conf httpd-mpm.conf 
>> httpd-multilang-errordoc.conf \
>> 
>> +   httpd-ssl.conf httpd-userdir.conf httpd-vhosts.conf \
>> 
>> +   proxy-html.conf" {
>> 
>> +copy ${apache2.sysconfdir}/extra/${f} 
>> ${apache2.sysconfdir}/extra/${f}.${date_str}
>> 
>> +}
> 
> Fails on the buildbot workers:
> 
> 
> Error: Failed to activate apache2: error copying 
> "/opt/local/etc/apache2/extra/httpd-autoindex.conf": no such file or directory
> 
> 
> 

Re: [macports-ports] 02/37: apache24-devel: rename to apache2

[Marius Schamschula]

Ryan,

There were so many moving parts to the switch over from apache 2.2.x to 2.4.x, 
that some things feel through the cracks.

Commit 
https://github.com/macports/macports-ports/commit/d921c4a5be5ac76720c54702d066ff9914885fa2
 
<https://github.com/macports/macports-ports/commit/d921c4a5be5ac76720c54702d066ff9914885fa2>

> On Oct 16, 2017, at 3:03 PM, Ryan Schmidt <ryandes...@macports.org 
> <mailto:ryandes...@macports.org>> wrote:
> 
> 
> On Oct 15, 2017, at 13:29, Marius Schamschula wrote:
> 
>> Marius Schamschula (Schamschula) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> 
>> https://github.com/macports/macports-ports/commit/12fedbd20c5bd98b3dc91437384886d24ede3f52
>>  
>> <https://github.com/macports/macports-ports/commit/12fedbd20c5bd98b3dc91437384886d24ede3f52>
>> 
>> commit 12fedbd20c5bd98b3dc91437384886d24ede3f52
>> 
>> Author: Marius Schamschula <m...@macports.org>
>> AuthorDate: Sun Oct 15 12:40:08 2017 -0500
>> 
>> 
>>apache24-devel: rename to apache2
> 
> I had both apache2 and apache24-devel installed. Attempting to upgrade 
> apache2 to the new version failed to activate, because it conflicted with 
> files provided by apache24-devel.
> 
> --->  Activating apache2 @2.4.28_0+preforkmpm+universal
> Error: Failed to activate apache2: Image error: /opt/local/bin/ab is being 
> used by the active apache24-devel port.  Please deactivate this port first, 
> or use 'port -f activate apache2' to force the activation.
> Error: See 
> /opt/local/var/macports/logs/_Users_rschmidt_macports_macports-ports-svn-trunk_www_apache2/apache2/main.log
>  for details.
> 
> What you want to do here is reinstate the apache24-devel portfile, at the 
> same version as before, one revision higher, mark it as "replaced_by 
> apache2", and include "PortGroup obsolete 1.0". Keep this obsolete portfile 
> in the ports tree until all users have upgraded; usually 1 year is 
> sufficient. See:
> 
> https://guide.macports.org/#development.practices.rename-replace-port 
> <https://guide.macports.org/#development.practices.rename-replace-port>
> 
> Specifically:
> 
> https://guide.macports.org/#development.obsolete-portgroup
> 
> 

Marius
--
Marius Schamschula

Re: [macports-ports] branch master updated: gnutls 3.5.15: add doc variant

[Marius Schamschula]

gnutls has 

blacklist { clang < 400 } for i386 and x86_64

> On Sep 29, 2017, at 1:48 PM, Ken Cunningham <ken.cunningham.web...@gmail.com 
> <mailto:ken.cunningham.web...@gmail.com>> wrote:
> 
> argh
> 
> blacklist { clang < 500 }, I meant
> 
> 
> On 2017-09-29, at 11:47 AM, Ken Cunningham wrote:
> 
>>> But similar to cxx11 1.0, it doesn't do much on systems using libc++, i.e. 
>>> 10.9 or later.
>>> 
>> 
>> The only thing it does if libc++ is selected is blacklist  { clang > 500 } 
>> and *gcc*
>> 
>> Ken
> 

Marius
--
Marius Schamschula

Re: [macports-ports] branch master updated: gnutls 3.5.15: add doc variant

[Marius Schamschula]

> On Sep 29, 2017, at 1:08 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
> On Sep 29, 2017, at 11:53, Marius Schamschula wrote:
> 
>> Marius Schamschula (Schamschula) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> 
>> https://github.com/macports/macports-ports/commit/8cc85e0fb1b985598bd8873609ae61f82a3e05f2
>> 
>> The following commit(s) were added to refs/heads/master by this push:
>> 
>> new 8cc85e0  gnutls 3.5.15: add doc variant
>> 
>> 8cc85e0 is described below
>> 
>> 
>> commit 8cc85e0fb1b985598bd8873609ae61f82a3e05f2
>> 
>> Author: Marius Schamschula <m...@macports.org>
>> AuthorDate: Fri Sep 29 11:53:51 2017 -0500
>> 
>> 
>>gnutls 3.5.15: add doc variant
>> 
>> 
>> 
>>Disable doc build for universal builds
> 
> Why? I didn't previously have a problem building gnutls universal.
> 
> If this change is to remain, then the revision should be increased, otherwise 
> users who installed the port universal before this change would have 
> documentation and those who install it afterward won't, which is inconsistent.

Apparently, building examples (part of the documentation) using the universal 
variant under Yosemite needs -stdlib=libstdc++, in other words the cxx11 
PortGroup. This would disable gnutls for older systems.

I didn’t revbump, as this only affects those systems with the universal 
variant. For those the upgrade to gnutls 3.5.15 should have failed. All others 
should have built ( I got no contrary reports).

Marius
--
Marius Schamschula

Re: [macports-ports] 01/02: hunspell-en: SCOWL based hunspell dictionary for en_AU, en_CA, en_GB, and en_US

[Marius Schamschula]

Leonardo,

The reasoning behind the renaming is twofold:

1) I went by repology.org <http://repology.org/> for the more common package 
name used by other packaging systems: hunspell-en. Only MacPorts used 
hunspell-dict-en_*.

https://repology.org/metapackage/hunspell-en/versions 
<https://repology.org/metapackage/hunspell-en/versions>

2) The new package is fundamentally different in terms of its source and build 
mechanism, given that all hunspell-dict-* packages are currently broken (the 
list of dictionaries and source code was removed from OpenOffice.org 
<http://openoffice.org/>).

Marius
--
Marius Schamschula



> On Sep 29, 2017, at 8:30 AM, Leonardo Brondani Schenkel 
> <leona...@schenkel.net <mailto:leona...@schenkel.net>> wrote:
> 
> Quick question regarding the name of the port: I couldn't help but noticing 
> that the port names changed from "hunspell-dict-en" to "hunspell-en". Was is 
> the reasoning behind it? I'm asking because I'm the maintainer for "pt_BR" 
> and I'm going to submit "sv_SE" and I would like to know if the naming 
> convention is changing, so I can follow.
> 
> Another question is regarding the dependency on hunspell: is it really needed 
> at runtime? The fact that I want to install a dictionary does not necessarily 
> mean that I want to use hunspell (the command line tool); plenty of other GUI 
> tools, and macOS itself, support hunspell and can be told to use the 
> dictionaries.
> 
> Thanks!
> // Leonardo

Re: [macports-ports] branch master updated: hunspell-de 20161207: split dictionary into variants, default to +de_DE

[Marius Schamschula]

Ryan,

I’ve updated hunspell-de:

https://github.com/macports/macports-ports/commit/3fedea509cf2c6ec8f63940c064cdc349de791ad
 
<https://github.com/macports/macports-ports/commit/3fedea509cf2c6ec8f63940c064cdc349de791ad>

and hunspell-en:

https://github.com/macports/macports-ports/commit/24c49dd047a42bf9651a112a134cb36fd28c195c
 
<https://github.com/macports/macports-ports/commit/24c49dd047a42bf9651a112a134cb36fd28c195c>

(note: I had to grab a local copy of the source file from my home machine, as 
the mirrors seem not to be providing it at this time)

Marius
--
Marius Schamschula



> On Sep 26, 2017, at 10:56 AM, Ryan Schmidt <ryandes...@macports.org 
> <mailto:ryandes...@macports.org>> wrote:
> 
> 
> On Sep 25, 2017, at 16:31, Marius Schamschula wrote:
> 
>> Marius Schamschula (Schamschula) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> 
>> https://github.com/macports/macports-ports/commit/ada9952556fc64c387ee72cfcb5bfe68171ad85b
>>  
>> <https://github.com/macports/macports-ports/commit/ada9952556fc64c387ee72cfcb5bfe68171ad85b>
>> 
>> The following commit(s) were added to refs/heads/master by this push:
>> 
>> new ada9952  hunspell-de 20161207: split dictionary into variants, 
>> default to +de_DE
> 
> 
>> -destroot {
>> +pre-destroot {
>> xinstall -d -m 755 $installdir
>> +}
>> +
>> +variant de_AT description {Austrian German dictionary} {
>> +build.target-append hunspell/de_AT.dic hunspell/de_AT.aff
>> +
>> +destroot {
>> +xinstall -m 644 ${worksrcpath}/hunspell/de_AT.aff $installdir
>> +xinstall -m 644 ${worksrcpath}/hunspell/de_AT.dic $installdir
>> +}
>> +}
>> +
>> +variant de_CH description {Swiss German dictionary} {
>> +build.target-append hunspell/de_CH.dic hunspell/de_CH.aff
>> 
>> -xinstall -m 644 ${worksrcpath}/hunspell/de_AT.aff $installdir
>> -xinstall -m 644 ${worksrcpath}/hunspell/de_AT.dic $installdir
>> -xinstall -m 644 ${worksrcpath}/hunspell/de_CH.aff $installdir
>> -xinstall -m 644 ${worksrcpath}/hunspell/de_CH.dic $installdir
>> -xinstall -m 644 ${worksrcpath}/hunspell/de_DE.aff $installdir
>> -xinstall -m 644 ${worksrcpath}/hunspell/de_DE.dic $installdir
>> +destroot {
>> +xinstall -m 644 ${worksrcpath}/hunspell/de_CH.aff $installdir
>> +xinstall -m 644 ${worksrcpath}/hunspell/de_CH.dic $installdir
>> +}
>> }
>> 
>> +variant de_DE description {German dictionary} {
>> +build.target-append hunspell/de_DE.dic hunspell/de_DE.aff
>> +
>> +destroot {
>> +xinstall -m 644 ${worksrcpath}/hunspell/de_DE.aff $installdir
>> +xinstall -m 644 ${worksrcpath}/hunspell/de_DE.dic $installdir
>> +}
>> +}
>> +
>> +default_variants +de_DE
> 
> 
> Same observation about these variants as made previously about hunspell-en.
> 
> 
> Also, is there a reason why these should be variants, rather than subports?
> 

Re: [macports-ports] branch master updated: hunspell-de 20161207: split dictionary into variants, default to +de_DE

[Marius Schamschula]

Ryan,

I think the subport method is the best approach. I’m rewriting both hunspell-de 
and hunspell-en.

This will also let me give the proper replaced_by for the obsoleted ports.

> On Sep 26, 2017, at 10:56 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
> On Sep 25, 2017, at 16:31, Marius Schamschula wrote:
> 
>> Marius Schamschula (Schamschula) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> 
>> https://github.com/macports/macports-ports/commit/ada9952556fc64c387ee72cfcb5bfe68171ad85b
>> 
>> The following commit(s) were added to refs/heads/master by this push:
>> 
>> new ada9952  hunspell-de 20161207: split dictionary into variants, 
>> default to +de_DE
> 
> 
>> -destroot {
>> +pre-destroot {
>> xinstall -d -m 755 $installdir
>> +}
>> +
>> +variant de_AT description {Austrian German dictionary} {
>> +build.target-append hunspell/de_AT.dic hunspell/de_AT.aff
>> +
>> +destroot {
>> +xinstall -m 644 ${worksrcpath}/hunspell/de_AT.aff $installdir
>> +xinstall -m 644 ${worksrcpath}/hunspell/de_AT.dic $installdir
>> +}
>> +}
>> +
>> +variant de_CH description {Swiss German dictionary} {
>> +build.target-append hunspell/de_CH.dic hunspell/de_CH.aff
>> 
>> -xinstall -m 644 ${worksrcpath}/hunspell/de_AT.aff $installdir
>> -xinstall -m 644 ${worksrcpath}/hunspell/de_AT.dic $installdir
>> -xinstall -m 644 ${worksrcpath}/hunspell/de_CH.aff $installdir
>> -xinstall -m 644 ${worksrcpath}/hunspell/de_CH.dic $installdir
>> -xinstall -m 644 ${worksrcpath}/hunspell/de_DE.aff $installdir
>> -xinstall -m 644 ${worksrcpath}/hunspell/de_DE.dic $installdir
>> +destroot {
>> +xinstall -m 644 ${worksrcpath}/hunspell/de_CH.aff $installdir
>> +xinstall -m 644 ${worksrcpath}/hunspell/de_CH.dic $installdir
>> +}
>> }
>> 
>> +variant de_DE description {German dictionary} {
>> +build.target-append hunspell/de_DE.dic hunspell/de_DE.aff
>> +
>> +destroot {
>> +xinstall -m 644 ${worksrcpath}/hunspell/de_DE.aff $installdir
>> +xinstall -m 644 ${worksrcpath}/hunspell/de_DE.dic $installdir
>> +}
>> +}
>> +
>> +default_variants +de_DE
> 
> 
> Same observation about these variants as made previously about hunspell-en.
> 
> 
> Also, is there a reason why these should be variants, rather than subports?
> 

Re: how to efficiently work through generating patches using git and macports build process?

[Marius Schamschula]

On Aug 30, 2017, at 8:33 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
> On Aug 30, 2017, at 10:44, Ken Cunningham wrote:
> 
>> When trying to fix broken ports, I have so far been using the method of 
>> copying the source file to source.orig, editing the source files in place, 
>> and then noting the files I worked on, to individually diff them at the end 
>> to individual patch files.
>> 
>> It's easy to understand, but not super efficient, especially when I make a 
>> number of changes in different files.
> 
> This basically describes what I do. I'm happy with this process because I 
> understand it.
> 

I do a variation on this scheme as well. I have two scripts

1) to create the .orig file (using path information from port and the relative 
path)

2) to generate the diff and place the properly named patch file in the 
appropriate files directory.

Marius
--
Marius Schamschula

Re: Is it time for a libc_fixes library yet?

[Marius Schamschula]

Ken,

Yes please! I’ve lost count of how many ports I have had patch this fix into.

> On Jul 3, 2017, at 12:07 PM, Ken Cunningham <ken.cunningham.web...@gmail.com 
> <mailto:ken.cunningham.web...@gmail.com>> wrote:
> 
> So the last 10 or so tickets in trac seem like they are all for basically the 
> same issue - a few missing symbols from libc prior to 10.7.
> 
> It is easy enough, but time consuming, to patch each individual source file 
> that is missing the definition (there might be several, also, so you might 
> have to do it multiple times in different files).
> 
> With this library of these missing functions 
> <https://github.com/kencu/snowleopardfixes 
> <https://github.com/kencu/snowleopardfixes>>, all of them from the Apple open 
> source website IIRC, all you need to do is the following in the Portfile:
> 
> if {${os.platform} eq "darwin" && ${os.major} < 11}  {
>   depends_lib-append  port:snowleopardfixes
>   configure.ldflags-append   -lsnowleopardfixes
> }
> It could be better named, perhaps libcfixes, as it applies to 10.4 to 10.6, 
> not just SnowLeopard. 
> 
> It works for wine, and all the other ports that have had this issue. It takes 
> 10 seconds to do, and no patching.
> 
> Is it time for this? Or shall we continue as we are?
> 
> 
> Best,
> 
> Ken
> 
> 
> 
> 
> Addendum 1
> 
> I have a header in there as well to provide the function definitions, but 
> that header can cause trouble by bringing in other #defines, and it seems 
> that no port actually needs the header. Perhaps the header idea can be 
> improved by someone with more knowledge of #include_next, etc, or more 
> specific defines.
> 
> Addendum 2
> 
> As we have said before (last year) this library could be automatically linked 
> in by base. That would cause trouble with the ports that have already patched 
> in a def, tho.
> 

Marius
--
Marius Schamschula

Re: [macports-ports] branch master updated: samtools: add missing xz dependency

[Marius Schamschula]

Done: https://git.io/vHp7G <https://git.io/vHp7G>

> On Jun 16, 2017, at 7:59 PM, Rainer Müller <rai...@macports.org> wrote:
> 
> On 2017-06-17 02:20, Davide Liessi wrote:
>> Marius Schamschula (Schamschula) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> https://github.com/macports/macports-ports/commit/c979e27dcf04087efd83b38e5b5a8e8cbebe8a6e
>>  
>> <https://github.com/macports/macports-ports/commit/c979e27dcf04087efd83b38e5b5a8e8cbebe8a6e>
>> The following commit(s) were added to refs/heads/master by this push:
>>  new c979e27  samtools: add missing xz dependency
>> c979e27 is described below
>> 
>> commit c979e27dcf04087efd83b38e5b5a8e8cbebe8a6e
>> Author: Davide Liessi <davide.lie...@gmail.com> 
>> <mailto:davide.lie...@gmail.com>
>> AuthorDate: Fri Jun 16 12:12:26 2017 +0200
>> 
>> samtools: add missing xz dependency
>> ---
>>  science/samtools/Portfile | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>> 
>> diff --git a/science/samtools/Portfile b/science/samtools/Portfile
>> index 631c606..d2afd15 100644
>> --- a/science/samtools/Portfile
>> +++ b/science/samtools/Portfile
>> @@ -23,7 +23,9 @@ homepagehttp://www.htslib.org/ 
>> <http://www.htslib.org/>
>>  github.tarball_from releases
>>  use_bzip2   yes
>>  
>> -depends_lib port:zlib port:ncurses
>> +depends_lib port:zlib \
>> +port:ncurses \
>> +port:xz
>>  
>>  use_configure   no
>>  
> In order to have the new dependency properly recorded in the registry on 
> existing installations, this change also requires a revision bump.
> 
> Rainer

Re: Opportunistic (broken) build dependencies? (gdbm)

[Marius Schamschula]

I just added ac_cv_prog_AWK=awk to the configure.args for gdbm, as I did for 
gawk yesterday.

However, gdbm is not in the dependency chain of gawk, so I don’t know why 
MacPorts wants to install it before gawk.

> On Apr 25, 2017, at 5:41 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
>> 
>> On Apr 25, 2017, at 04:57, Mojca Miklavec <mo...@macports.org> wrote:
>> 
>> On 25 April 2017 at 11:45, Mojca Miklavec wrote:
>>> Hi,
>>> 
>>> I just experienced a failure to build gdbm during "port upgrade outdated".
>>> 
>>> The reason: configure checks for
>>>for ac_prog in gawk mawk nawk awk
>>> and then calls "gawk" which is temporarily broken due to readline
>>> which has been upgraded some seconds before (while gawk wasn't yet).
>>> But gawk is not listed as build dependency, so MacPorts didn't know
>>> that gawk should be updated first.
>>> 
>>> What's the best solution in such cases?
>>> 
>>> Adding:
>>>configure.env-append AWK=/usr/bin/awk
>>> 
>>> Or add a build dependency on gawk?
> 
> So far we've decided to do neither.
> 
>> The same problem when updating clisp. At which point I just "gave up"
>> and update gawk before running "port upgrade outdated" again.
> 
> This is what we've recommended so far.



Marius
--
Marius Schamschula

Re: [macports-ports] branch master updated: ps2eps 1.68: move to CTAN, use_zip, use modern hashes

[Marius Schamschula]

Ryan,

It is rather undesirable, but it currently is the only thing that is available.

Marius
--
Marius Schamschula



> On Mar 6, 2017, at 1:52 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
>> On Feb 24, 2017, at 14:23, Marius Schamschula <m...@macports.org> wrote:
>> 
>> Marius Schamschula (Schamschula) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> 
>> https://github.com/macports/macports-ports/commit/2d23de48016bd4ced56dc3cc6525976a58e1a082
>> 
>> The following commit(s) were added to refs/heads/master by this push:
>> 
>> new 2d23de4  ps2eps 1.68: move to CTAN, use_zip, use modern hashes
>> 
>> 2d23de4 is described below
>> 
>> 
>> commit 2d23de48016bd4ced56dc3cc6525976a58e1a082
>> 
>> Author: Marius Schamschula <m...@macports.org>
>> AuthorDate: Fri Feb 24 14:23:57 2017 -0600
>> 
>> 
>>ps2eps 1.68: move to CTAN, use_zip, use modern hashes
>> 
>> ---
>> print/ps2eps/Portfile | 14 --
>> 1 file changed, 8 insertions(+), 6 deletions(-)
>> 
>> 
>> diff --git a/print/ps2eps/Portfile b/print/ps2eps/Portfile
>> 
>> index b4cffd5..18ae1aa 100644
>> 
>> --- a/print/ps2eps/Portfile
>> 
>> +++ b/print/ps2eps/Portfile
>> 
>> @@ -2,12 +2,13 @@
>> 
>> 
>> PortSystem  1.0
>> nameps2eps
>> 
>> +distname${name}
> 
> 
> An unversioned distfile? Which uses zip and is therefore larger than the gz 
> file? This is not preferable.
> 
>