Help with +universal for gtk3[-devel]

Hi: Could someone lend a hand with the universal option for gtk3 / gtk3-devel? My system isn’t capable of building universal. I’ve developed a patch that brings the gtk3 ports up to the current release which includes changing to a meson-based build: https://trac.macports.org/ticket/66487

Re: intltool random perls

> On Feb 28, 2022, at 10:19 PM, Joshua Root wrote: > > On 2022-3-1 14:03 , Craig Treleaven wrote: >> The buildbots on OSX 10.12 and older are not finding a compatible version of >> XML::Parser and thus geany's configure fails. However, NONE of the >> buildbots (nor

intltool random perls

Hi: I committed an update to the geany port today and it failed to build on several buildbots. In reviewing the logs, I found that geany is using intltool and that various buildbots were trying to employ a different version of perl than that specified in the intltool portfile. The intltool

Re: www/unit build failer on Azure DevOps

> On Oct 3, 2021, at 5:30 PM, Sergey A. Osokin wrote: > I'm looking for details on the www/unit build failure on Azure DevOps > platform, > i.e. > https://dev.azure.com/macports/macports-ports/_build/results?buildId=17185=results I don’t know about the view you linked to. From the Checks tab

Re: [PATCH] databases/redis

> On Sep 24, 2021, at 4:09 PM, Sergey A. Osokin wrote: > > Hi, > > here's the update to update databases/redis to the recent version. > Would you be able to address the issue(s) raised in the reds tickets? https://trac.macports.org/ticket/61625

Re: Portfiles for an OpenStreetMap Tile Server

> On Aug 29, 2021, at 8:02 AM, Frank Dean wrote: > > I have a few questions to ask in relation to a series of Portfiles that > I have created to support installing and running a map tile server for > OpenStreetMaps [1]. > > [1]: https://switch2osm.org/serving-tiles/ > > The logical Portfiles:

Meson & non-Xcode compilers -- esp older OSX versions

Hi: Could someone with access to 10.9 and/or older OSX versions lend a hand? A user reported that ffmpeg on 10.9 compiled with clang-devel was failing on launch, thusly: $ffmpeg -version dyld: Library not loaded: @rpath/libdav1d.5.dylib Referenced from: /opt/MacPorts/bin/ffmpeg Reason: image

Re: Publicizing MacPorts

> On Apr 19, 2021, at 2:51 PM, Jason Liu wrote: > > On Mon, Apr 19, 2021 at 1:25 PM Craig Treleaven <mailto:ctrelea...@cogeco.ca>> wrote: > Also, why should we consider that MacPorts is in competition with Homebrew? > Both MacPorts and Homebrew seem to

Re: Publicizing MacPorts

> On Apr 19, 2021, at 10:47 AM, Karl-Michael Schindler > wrote: > > Am 19.04.2021 um 14:00 schrieb macports-dev-requ...@lists.macports.org: >> >> Date: Mon, 19 Apr 2021 13:24:51 +0200 >> From: Mojca Miklavec >> Subject: Re: Publicizing MacPorts >> Message-ID: >> >> Content-Type: text/plain;

Re: Desolate Condition

> On Apr 3, 2021, at 8:21 PM, wowfunha...@gmail.com > wrote: > >>> On 2021-1-27 02:57 , Andrew Janke wrote: >>> I didn't know that! I must be behind the times with the state of MacPorts. >>> Thanks for the update. >> About a decade behind -- the buildbot went live in 2011. ;) >> - Josh > > I

Re: Meson 0.56.2 and Python39 --> dav1d failing

> On Feb 6, 2021, at 4:47 AM, Ryan Schmidt wrote: > > > > On Feb 6, 2021, at 02:14, Ken Cunningham wrote: > >> On Feb 5, 2021, at 10:04 PM, Ryan Schmidt wrote: >> >>> That sounds like what Craig is saying: that meson is now adding a compiler >>> flag that old compilers don't understand.

Re: Meson 0.56.2 and Python39 --> dav1d failing

> On Feb 3, 2021, at 10:01 PM, Joshua Root wrote: > > On 2021-2-4 12:19 , Ken Cunningham wrote: >>> On Feb 3, 2021, at 11:49 AM, Craig Treleaven >>> wrote: >>> >>> But configure still failed on 10.7 and 10.8: >> Oh no! It looked so grea

Re: Meson 0.56.2 and Python39

> On Feb 2, 2021, at 7:26 PM, Craig Treleaven wrote: > > Anyway, I have 'port test meson' running on my 10.10 system even though I > don’t expect anything. I don’t have a working virtualization system at the > moment. Perhaps tomorrow I can get that back up and try th

Re: Meson 0.56.2 and Python39

ed as PRs (we have > been seeing some of that at times, hopefully I caught most of it), or > otherwise wholly untested PRs that are thrown up without even a passing local > build. > > That is asking too much of PR reviewers to have absolutely no trust in the PR > submitte

Meson 0.56.2 and Python39

Hi: It might be that the meson update and/or the switch to python39 has broken builds on older Mac OS versions. Specifically, I updated dav1d to 0.8.1 and it no longer configures successfully on 10.9 and older versions. Upstream says that the now-failing configure test (a simple test to see

Older buildbots "unable to create an executable file"

Hi: I updated the avidemux port to 2.7.6 and the older buildbots are falling over. The port built successfully on the 10.10 and newer builbots. (Well, except arm64 but that’s a different problem and I’ve contacted upstream.) On 10.9 and older, it fails while configuring an embedded

Re: Desolate Condition

> On Jan 26, 2021, at 9:13 PM, Andrew Janke wrote: > > Possibly relevant: I'm co-maintainer of Octave.app, a "native" Mac app > distribution of GNU Octave (https://octave-app.org/). It's currently > built on top of Homebrew. > > I'm tentatively planning on migrating Octave.app to be built on

Re: OpenJDK ports incorrectly shown as 'green' for unsupported OS versions on ports.macports.org

> On Jan 22, 2021, at 6:47 PM, Joshua Root wrote: > > On 2021-1-23 09:40 , Craig Treleaven wrote: >> The port watcher job therefore finished successfully even though no supports >> were actually built. I believe this “successful” result is what is >> displayed

Re: OpenJDK ports incorrectly shown as 'green' for unsupported OS versions on ports.macports.org

> On Jan 22, 2021, at 4:39 PM, Nils Breunese wrote: > > Hello, > > I maintain the openjdk* ports. These ports require Mac OS X 10.10 Yosemite or > later, and the Portfile contains an explicit check for OS version: >

Re: Buiildbots - Framework not found CoreMidi

> On Jan 18, 2021, at 10:01 PM, Ryan Schmidt wrote: > > On Jan 18, 2021, at 08:35, Craig Treleaven wrote: > >>> The correct spelling is CoreMIDI, not CoreMidi. You get away with it on a >>> case-insensitive filesystem. >> >> Thanks. I’ve pushed a c

Add nasm/yasm on Intel only?

Hi: With Apple Silicon macs taking over the world (eventually), I noticed that a few ports build on the new platform but still declare a dependency on the nasm or yasm assemblers. Obviously these aren’t used when building for arm64. What would be a clean, simple way of only adding the

Re: Buiildbots - Framework not found CoreMidi

> On Jan 18, 2021, at 8:08 AM, Joshua Root wrote: > > On 2021-1-18 23:45 , Craig Treleaven wrote: >> Hi: >> I developed a new port, openshot-qt and friends, where the libopenshot-audio >> port is failing to build on the OS X 10.13 and older buildbots claiming:

Buiildbots - Framework not found CoreMidi

Hi: I developed a new port, openshot-qt and friends, where the libopenshot-audio port is failing to build on the OS X 10.13 and older buildbots claiming: ld: framework not found CoreMidi clang: error: linker command failed with exit code 1 (use -v to see invocation) I tested the port locally

Re: Rosetta2 and supported_archs

> On Jan 11, 2021, at 9:07 PM, Ryan Schmidt wrote: > On Jan 11, 2021, at 19:38, Craig Treleaven wrote: > >> A user with a new Apple Silicon-based Mac had a go at building mythtv.28. >> It failed thusly: >> >> ---> Computing dependencies for mythtv.28 >

Qt and Apple Silicon

My MythTV ports depend heavily on Qt but I’m not up to speed on that project’s plans wrt the new Apple-silicon (ASi) Macs. AIUI, our current Qt5 port is X86_64 only. Is or will Qt5 be compatible with ASi? Do we need to port Qt6 to become compatible? Any rough timetable? If I’ve missed

Rosetta2 and supported_archs

A user with a new Apple Silicon-based Mac had a go at building mythtv.28. It failed thusly: ---> Computing dependencies for mythtv.28 Error: Cannot install mythtv-core.28 for the arch 'x86_64' because Error: its dependency logrotate does not build for the required arch by default

Re: MacPorts webapp project updates

> On Jul 12, 2020, at 2:55 PM, Arjun Salyan wrote: > > Hello all, > > This is in continuation to my previous emails regarding updates about the > webapp. The temporary version is deployed at http://macports.silentfox.tech/ > > > ... > Feedback and

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 11:29 AM, Ken Cunningham > wrote: > > All valid points. I thought we had more-or-less got past the “should we” and > moved on to the “how should we”, > > I am not necessarily championing this, but people are submitting these, and > there is demand.here are nearly 4000

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 10:10 AM, Ken Cunningham > wrote: > > How about I float a suggestion? We could append "_binary" to the name. > Otherwise leave the categories, notes, etc as they are now. > > So a port that installs the Zoom teleconferencing application would be called > "zoom_binary".

Re: MacPorts webapp project updates

> On Jul 12, 2020, at 2:55 PM, Arjun Salyan wrote: > ... > > "Splash screen" (upcoming) > It was pointed out that our current port page > (http://macports.silentfox.tech/port/cctools/ > ) contains a lot of technical > information which might not

Perl5 portgroup: 'make pure_install'

Hi: Could someone help me understand the “pure_install” target used in the perl5 portgroup? In my new xmltv port, I noticed that some sample configuration files are excluded from pure_install that would otherwise be installed if the normal “install” target was used. Upstream has essentially

Re: Call for designers for our ports website

> On Jun 13, 2020, at 2:24 PM, Arjun Salyan wrote: > > Thank you for the mockup and the inputs. > > http://macports.silentfox.tech/port/gnuplot/stats/?days=365 > my version of > it does not look as good as yours probably due to a

Re: Call for designers for our ports website

> On Jun 12, 2020, at 10:30 PM, Arjun Salyan wrote: > > Hi Craig, > > Thank you. You make a valid point regarding the possible distortion due to > weekly submissions being bundled to calculate monthly charts. > > But what we are seeing here is a known issue with the query that calculates >

Fwd: Call for designers for our ports website

Sorry, intended to send this to the dev list... > Begin forwarded message: > > From: Craig Treleaven > Subject: Re: Call for designers for our ports website > Date: June 12, 2020 at 2:31:52 PM EDT > To: Mojca Miklavec > >> On Jun 12, 2020, at 1:24 PM, Mojca M

Re: Perl portgroup, +perl5_30 depends on perl5.28, etc

> On May 23, 2020, at 12:39 AM, Ryan Schmidt wrote: > > On May 22, 2020, at 09:52, Craig Treleaven wrote: > >> I’m working on a new port and was using the fsdb port as a model. Oddly, >> when a non-default variant is selected, it seems the perl portgroup sti

Perl portgroup, +perl5_30 depends on perl5.28, etc

I’m working on a new port and was using the fsdb port as a model. Oddly, when a non-default variant is selected, it seems the perl portgroup still adds a dependency on the default perl version. In the case of fsdb, the default variant is +perl5_28: $ port info --variants --depends_lib fsdb

Re: Dependencies on non-default variants

> On Apr 2, 2019, at 5:40 PM, Ryan Schmidt wrote: > > On Mar 25, 2019, at 08:48, Craig Treleaven wrote: > >> On Mar 24, 2019, at 4:05 PM, Mojca Miklavec wrote: >> >>> I now checked the first two random MythTV ports, which basically boils down >>> to:

Re: Dependencies on non-default variants (was: GSoC 2019 [Collect build statistics])

n, 24 Mar 2019 at 19:55, Craig Treleaven wrote: >>> On Mar 24, 2019, at 1:09 PM, Mojca Miklavec wrote: >>> On Sun, 24 Mar 2019 at 01:06, Craig Treleaven wrote: > […] > I now checked the first two random MythTV ports, which basically boils down > to: > > require_

Re: GSoC 2019 [Collect build statistics]

> On Mar 24, 2019, at 5:57 PM, Fred Wright wrote: > > On Sun, 24 Mar 2019, Mojca Miklavec wrote: >> On Sat, 23 Mar 2019 at 17:49, Craig Treleaven wrote: >>> >>> I see no reason to report inactive ports. >> >> Neither do I. I would remove those a

Re: Dependencies on non-default variants (was: GSoC 2019 [Collect build statistics])

> On Mar 24, 2019, at 4:05 PM, Mojca Miklavec wrote: > > On Sun, 24 Mar 2019 at 19:55, Craig Treleaven wrote: >>> On Mar 24, 2019, at 1:09 PM, Mojca Miklavec wrote: >>> On Sun, 24 Mar 2019 at 01:06, Craig Treleaven wrote: >>>> >>>> Th

Re: GSoC 2019 [Collect build statistics]

> > On Mar 24, 2019, at 1:09 PM, Mojca Miklavec wrote: > > On Sun, 24 Mar 2019 at 01:06, Craig Treleaven wrote: >> >> please note that we can’t expect all ports to build successfully on the >> buildbots. > > Nobody said that, but we cannot blame th

Re: GSoC 2019 [Collect build statistics]

> On Mar 23, 2019, at 6:26 AM, Arjun Salyan via macports-dev > wrote: > > On Sat, Mar 23, 2019 at 3:15 PM Mojca Miklavec > wrote: > I would use the first definition: number of users currently having the > port installed. It might be pretty common to have to reinstall

Re: GSoC 2019 [Collect build statistics]

> On Mar 23, 2019, at 5:45 AM, Mojca Miklavec wrote: > > On Sat, 23 Mar 2019 at 10:35, Arjun Salyan via macports-dev wrote: >> >> Hi, >> I am working on the design of tables for installation statistics. I have a >> doubt here: >> >> Suppose there is a port P. Now for number of installations

Re: GSoC 2019 [Collect build statistics]

> On Mar 23, 2019, at 6:26 AM, Arjun Salyan via macports-dev > wrote: > > On Sat, Mar 23, 2019 at 3:15 PM Mojca Miklavec > wrote: > I would use the first definition: number of users currently having the > port installed. It might be pretty common to have to reinstall

Re: Update Qt5

> On Mar 20, 2019, at 8:19 PM, Ruben Di Battista > wrote: > > I’m working on pushing the new version of ParaView. It currently has problems > with Qt 5.11 and it’s reported in the Kitware Gitlab issue tracker that with > the new Qt (5.12.2) on Mojave, the problems vanish. Can we bump up the

Re: GSoC 2019 [Collect build statistics]

> On Mar 16, 2019, at 1:00 PM, Mojca Miklavec wrote: > > Dear Arjun, > > V sob., 16. mar. 2019 21:46 je oseba Arjun Salyan napisala: > I have tried to make some changes in portindex2json.tcl so that the value of > categories is outputted as a list and not just a string. > > Can someone please

Re: GSoC 2019 [Collect build statistics]

> On Mar 8, 2019, at 9:45 AM, Arjun Salyan via macports-dev > wrote: > > Thank you Mojca. > > The provided references have cleared a lot of my doubts and I am really > interested to do this project: 'Collect build statistics' > > Here is what I have understood so far: > 1. dynamic page for

Currently recommended Python version?

I was about to update one of my ports, libcec, which currently depends on python34. I see that python37 was added to MacPorts in the middle of 2018. I don’t even know how libcec actually uses python. I can’t see anything documented for the package that specifies or recommends a particular

SDK-installer port

Hi: For some months, my time has been consumed with other projects. While I was scanning though older messages, I thought I saw a mention that someone (Ryan?) was going to develop a port to help with installing now-missing Apple SDK’s. Is that right? I ask because I believe the QucikTime

Homebrew hacked

I ran across an article this morning describing how Homebrew was hacked with a few minutes effort: https://medium.com/@vesirin/how-i-gained-commit-access-to-homebrew-in-30-minutes-2ae314df03ab Has anybody checked to see if we have any similar exposures in the MacPorts infrastructure? Craig

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

> On May 18, 2018, at 2:18 PM, Marius Schamschula wrote: > > Drat. Autocorrect strikes again. The regex should be: > > > port file all | xargs grep cxx11 | grep 1.0 > I think that regex needs to be refined a little more: $ port file all | xargs egrep -e

Re: Qt5 port group

>> On May 9, 2018, at 5:00 PM, Craig Treleaven <ctrelea...@macports.org> wrote: >> >>> On May 9, 2018, at 2:07 PM, Ryan Schmidt <ryandes...@macports.org> wrote: >>> >>> >>> On May 9, 2018, at 07:18, Craig Treleaven wrote

Re: Qt5 port group

> On May 8, 2018, at 5:06 AM, Vincent Habchi wrote: > > Hi there, > > I was in the process of modifying the Qt5 Port group to allow for choosing > the Qt version one wants to link an application against using variants. > However, before I go further, I’d like to know if

Compiler blacklist 'shorthand'

Hi: A couple of times recently, I’ve noticed boilerplate in ports that require C++14. After including the compiler_blacklist_versions portgroup, they then do some gymnastics like: compiler.blacklist *gcc-3.* *gcc-4.* {*gcc-5.[0-3]} \ {clang < 800}

Re: [MacPorts] #56389: rrdtool @1.7.0: fix missing dependency for dejavu-fonts

> On May 1, 2018, at 6:50 PM, macpo...@parvis.nl wrote: > > >> On 2018-05-01, at 22:56, MacPorts wrote: >> (...) >> Tidy other deps based on port-depcheck.sh analysis > > - what is that? > - can I do that myself? > Various MacPorts maintainers have developed little

Re: Online MacPorts Meeting on 21st April at 13:00 UTC - suggestion

> On Apr 19, 2018, at 5:24 AM, Rainer Müller wrote: > > On 2018-04-18 01:11, Rainer Müller wrote: >> On 2018-04-13 13:34, Mojca Miklavec wrote: >>> If we find three volunteers (I volunteer, so only two more needed), we >>> could perhaps do a technology test run tomorrow at

Re: Is it possible to specify variant as part of depends_lib?

> On Apr 18, 2018, at 7:52 PM, Edward Maros wrote: > > On 4/18/18 3:39 PM, Ryan Schmidt wrote: >> On Apr 18, 2018, at 12:39, Edward Maros wrote: >> >>> I have a package (gds) that has a build requirement on port root5 with >>> the variant +python27. >>> >>> Currently

Re: Support for python 2.6, 3.3 and 3.4

> On Apr 12, 2018, at 8:42 PM, Ryan Schmidt wrote: > > > On Apr 12, 2018, at 04:59, Mojca Miklavec wrote: > >> There are still some python modules that provide support for python >> 2.6 and 3.3. Is it ok to put all of them to py-graveyard? >> >> There are a number of

Re: [MacPorts] #15712: Add versions to platforms

> On Apr 12, 2018, at 5:09 PM, MacPorts wrote: > > #15712: Add versions to platforms > --+ > Reporter: raimue | Owner: larryv > Type: enhancement | Status: assigned > Priority: Normal |

Re: How to submit changes with a GitHub Pull Request (was Re: CI system for PR builds)

> On Apr 12, 2018, at 1:35 PM, db wrote: > > On 12 Apr 2018, at 14:27, Mojca Miklavec wrote: >> What nobody mentioned so far is that one can also simply click "Edit" on the >> existing Portfile on GitHub interface and that will also open a pull request. >

Re: CI system for PR builds

> On Apr 11, 2018, at 10:37 AM, Mojca Miklavec wrote: > > On 11 April 2018 at 16:18, Joshua Root wrote: >> >> Certainly let's encourage contributors who have something to submit to >> use PRs. But I don't know that simply moving existing tickets over to >> PRs without the

Re: Using qt59 instead of qt5 (latest release)

> On Apr 4, 2018, at 9:54 AM, Vincent Habchi wrote: > > Hey Craig, > >> I am considering a similar move for mythtv.28. > > […] > > Thanks for that useful info. French has a saying which goes like this (more > or less, it’s difficult to translate): “The best is

Re: Using qt59 instead of qt5 (latest release)

> On Apr 4, 2018, at 8:33 AM, Vincent Habchi wrote: > > Hi there, > > I recently wanted to experiment with linking one of the ports I maintain > (Qgis3) with QT 5.9, if only to find out if 5.10 wasn’t the source of all the > glitches and crashes everyone experiences with

Re: MySQL 5.7 fails to build

> On Apr 3, 2018, at 5:28 AM, Bjarne D Mathiesen > wrote: > > I'm having issues with mysql57 not building under macOS 10.13 > I'm seeing this on three different computers > I had no issues with this exact same setup under MacOS 10.12 > A completely new install under

Oh sh!t git

If, like me, you sometimes don’t get git: http://ohshitgit.com Craig

Re: GSoC 2018 Project: Improve startupitem code

> On Feb 15, 2018, at 2:29 PM, Joshua Root wrote: > > On 2018-2-16 06:08 , Bradley Giesbrecht wrote: >> Is daemundo still needed? > > In many cases yes. You *cannot* call daemon() or do the equivalent under > launchd, and that's very common behaviour in the wider unix world.

Re: poppler, security updates in general...

> On Jan 10, 2018, at 4:20 AM, Clemens Lang wrote: > > Hi Perry, > > - On 9 Jan, 2018, at 18:27, Perry E. Metzger pe...@piermont.com wrote: > >> I note the version of poppler we're shipping is pretty old, and that >> there are CVEs outstanding against it. >> >> Am I

Re: homebrew's top 1000 requested installs

> On Nov 29, 2017, at 11:42 AM, Ken Cunningham > wrote: > > in case anyone is curious what people are requesting. > MacPorts has almost all of these, I thought, glancing down the list. > > https://brew.sh/analytics/install-on-request/ A bunch of random

MacPorts port naming conventions

have a couple of minor questions about port naming that are partly related to a recent ticket (55241): 1) lowercase versus CamelCase We seem to use CamelCase naming mostly for ports that provide software with a graphical user interface, eg AquaLess. But not exclusively (e.g. SourceKitten).

Re: git password

> On Oct 21, 2017, at 2:04 AM, Jeremy Huddleston Sequoia <jerem...@apple.com> > wrote: > >> On Oct 20, 2017, at 20:10, Joshua Root <j...@macports.org> wrote: >> >> On 2017-10-21 08:00 , Craig Treleaven wrote: >>> Hi: >>> Lately, I h

Re: git password

ould use the KeyChain, perhaps, to > keep the password loaded. > > Hopefully these are helpful, if not, then write back, and maybe someone else > can help. > > -Sterling > > - Original Message - >> From: "Craig Treleaven" <ctrelea...@macports.org> &g

git password

Hi: Lately, I have to enter my github username and password every time I commit; git used to just remember these. I suppose it is in a hidden config file somewhere but I don’t know where. Could some kind soul please give me directions in suitably small words for someone of limited git

Re: [GSoC 2017] Second Evaluation

> On Jul 26, 2017, at 8:33 AM, Zero King wrote: > > Another challenge is that I'm not good at wording so while I've spent a > lot of time on documentation and comments the results aren't ideal yet. Don’t be too hard on yourself; I would say you are doing fine. Expressing

Re: streamline github dev process

> On May 31, 2017, at 8:52 AM, Zero King wrote: > > On Wed, May 31, 2017 at 10:40:07AM +0200, Mojca Miklavec wrote: >> The new bot could solve some of those problems, but it's still a pity >> that maintainers cannot have slightly higher permissions set. > > What kind of

Re: alternative/leaner installer creation algorithm: GSoC idea?

> On May 13, 2017, at 1:11 PM, René J.V. Bertin <rjvber...@gmail.com> wrote: > > On Saturday May 13 2017 11:06:37 Craig Treleaven wrote: > >> Indeed. I presume it is the expanded installer payload that is 2 GB. For >> me, a 330 MB installer expands to just ove

Re: alternative/leaner installer creation algorithm: GSoC idea?

> On May 13, 2017, at 9:41 AM, Rainer Müller wrote: > > On 2017-05-13 10:24, René J.V. Bertin wrote: >> In an exchange with the port:rkward maintainer the subject came up that >> MacPorts creates huge packages if you use the installer-creation feature to >> generate a

MacPorts now listed on Repology.org

Just a heads up that MacPorts is now listed on a site that details all of the packages carried by a wide variety of repositories: https://repology.org/repository/macports From a MacPorts developer standpoint, it is not a huge deal but there are a couple of useful features. If you look up your

Re: LICENSE for macports-ports

> On Apr 19, 2017, at 6:58 AM, Zero King wrote: > I submmitted a PR to macports-ports adding a LICENSE file > (https://github.com/macports/macports-ports/pull/287). Please review. (This is try #3 to send this message.) Also, neither the -base or -ports reposititories [1] have

test to macports-dev@lists.macports.org

Trying to determine why my messages are not going through. Craig

Re: buildbot: +quartz ?

> On Mar 20, 2017, at 12:48 PM, Ryan Schmidt <ryandes...@macports.org> wrote: > > >> On Mar 4, 2017, at 08:10, Craig Treleaven <ctrelea...@macports.org> wrote: >> >>> On Mar 3, 2017, at 10:26 PM, Mojca Miklavec <mo...@macports.org> wrote: >>

Reinplace warnings

1) What happens if my port uses ‘reinplace -q …’ but the user hasn’t updated to MacPorts 2.4.1? Does the port fail or is the -q flag ignored? 2) My MythTV ports have scores of Perl and Python scripts where I need to reinplace the shebang lines. That works but the user now gets over 100

Re: buildbot: +quartz ?

> On Mar 20, 2017, at 12:48 PM, Ryan Schmidt <ryandes...@macports.org> wrote: > > >> On Mar 4, 2017, at 08:10, Craig Treleaven <ctrelea...@macports.org> wrote: >> >>> On Mar 3, 2017, at 10:26 PM, Mojca Miklavec <mo...@macports.org> wrote: >>

Re: buildbot: +quartz ?

> On Mar 3, 2017, at 10:26 PM, Mojca Miklavec <mo...@macports.org> wrote: > > On 4 March 2017 at 03:51, Craig Treleaven wrote: >> I know that we would like to find a clean solution to building ports with >> non-default variants. As an interim step, however, I wond

buildbot: +quartz ?

I know that we would like to find a clean solution to building ports with non-default variants. As an interim step, however, I wonder if we might consider a buildbot that is configured to default to “+quartz”? It seems to me that X11/Quartz is one of the most common splits amongst our ports.

Testing

Mary had a little lamb…that was delicious with red wine! Try the old and new -dev list addresses. Craig

Re: [macports-ports] branch master updated: libcec: add OpenSSLException

> On Jan 23, 2017, at 11:47 AM, Ryan Schmidt <ryandes...@macports.org> wrote: > > >> On Jan 23, 2017, at 07:15, Craig Treleaven <ctrelea...@macports.org> wrote: >> >> Craig Treleaven (ctreleaven) pushed a commit to branch master >> in repository

Re: mpkg/mdmg and scripts

> On Jan 17, 2017, at 3:46 PM, Daniel J. Luke <dl...@geeklair.net> wrote: > > On Jan 13, 2017, at 8:20 PM, Craig Treleaven <ctrelea...@macports.org> wrote: >>> On Jan 13, 2017, at 4:06 PM, Joshua Root <j...@macports.org> wrote: >>> On 2017-1-14 07:28

mpkg/mdmg and scripts

Hi: A few months ago, I had been working on a new mpkg installer for my mythtv.28 ports and I’m trying to get back to it. A new element was using Preinstall and Postinstall scripts to automate some of initialization steps. I was puzzled as the installer log showed that these scripts were