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

On Jun 22, 2020, at 09:59, 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 ide

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

I've just realized this discussion has been to the old list address from macosforge. Please always use the new list addresses at lists.macports.org. On Jun 22, 2020, at 14:34, Daniel J. Luke wrote: > We should just have one perl5 port that tracks the current release. You say this every year (o

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

On Jun 22, 2020, at 09:59, Ken Cunningham wrote: > Perhaps unavoidable in some cases, but if you look around the web, this is in > fact the #1 complaint about MacPorts: bloat. I can't corroborate that claim, but of course we are interested in reducing bloat in MacPorts and welcome any sugges

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

On Jun 22, 2020, at 22:26, Jason Liu wrote: >> We should just have one perl5 port that tracks the current release. We'd >> just need to either revbump everything that needs a rebuild when a new minor >> perl version comes out (all the p5- ports to start) OR some enhancement to >> base to mak

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

On Jun 22, 2020, at 23:00, Jason Liu wrote: > On Mon, Jun 22, 2020 at 11:21 PM Ryan Schmidt wrote: > >> I've just realized this discussion has been to the old list address from >> macosforge. Please always use the new list addresses at lists.macports.org. >> >

Proper value for os.arch on Apple Silicon

Now that Apple has announced that Macs will have ARM processors [1], what is the proper value for ${os.arch} on such systems? MacPorts base currently knows two values of ${os.arch}: "powerpc" is used on all 32-bit and 64-bit PowerPC systems while "i386" is used on all 32-bit and 64-bit Intel sy

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

On Jun 22, 2020, at 23:21, Nils Breunese wrote: > Jason Liu wrote: > >> Would it be possible to sort of split the difference? i.e. not _just_ have >> one single perl5 port and get rid of all the individual point releases, but >> rather to add perl5 as a sort of "metapackage" that is essentia

Re: Proper value for os.arch on Apple Silicon

On Jun 23, 2020, at 01:44, Joshua Root wrote: > On 2020-6-23 16:36 , Joshua Root wrote: >> The value of os.arch is intended to match `uname -p`. > > And assuming macOS 11 hasn't changed uname in this respect, it looks > like it should be "arm". [1] > > - Josh > > [1] >

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

On Jun 23, 2020, at 00:57, Ken Cunningham wrote: > On Jun 22, 2020, at 8:32 PM, Ryan Schmidt wrote: > >> I can't corroborate that claim, but of course we are interested in reducing >> bloat in MacPorts and welcome any suggestions or improvements toward that >> e

Re: macOS 11 and Apple Silicon

Everyone, please use the new list addresses at lists.macports.org, not the old macosforge addresses that were deprecated in 2016. On Jun 23, 2020, at 01:40, Vincent Habchi wrote: > Wouldn’t it be possible to somehow set up a new hardware machine with > MacPorts installed and give all maintainer

Re: macos as vm guest

On Jun 25, 2020, at 18:06, Michael wrote: > That's 10.15, that requires the root drive reformatting, with no compatible > driver for older systems, right? > > (Whether or not it's a better file system isn't the issue. 100% breaking > compatibility with everything older is a bad move.) Huh? On

Reminders about revisions and when to increase them

Hi all, I want to remind everyone about when you should increase a port's revision and when you should not. Please don't increase revisions unnecessarily because it wastes time on our build servers and on users systems. You SHOULD increase a port's revision if a user who already has the port

Re: macos as vm guest

On Jun 25, 2020, at 20:50, Ryan Schmidt wrote: > On Jun 25, 2020, at 18:06, Michael wrote: > >> That's 10.15, that requires the root drive reformatting, with no compatible >> driver for older systems, right? >> >> (Whether or not it's a better fi

shellescape proc

Somehow I missed that we have a shellescape proc. This is very exciting! I've wanted this function for a long time, and I'm just realizing now that it exists and that we've had it for 6 years. https://github.com/macports/macports-base/commit/494a1feafa2ad46c66f9714b760fb5b50ff5dd48 Thank you, C

Re: Cached distfile with the same name

On Jun 27, 2020, at 11:32, Herby G wrote: > I have a situation where a particular port is using a distfile of the same > name from version to version. > > So there's currently an older version of the port's distfile cached in the > MacPorts mirrors. > > Unfortunately, trying to update the p

Re: shellescape proc

On Jun 27, 2020, at 23:18, Fred Wright wrote: > On Fri, 26 Jun 2020, Ryan Schmidt wrote: > >> Somehow I missed that we have a shellescape proc. This is very exciting! >> I've wanted this function for a long time, and I'm just realizing now that >> it exists

Re: Reminders about revisions and when to increase them

On Jun 28, 2020, at 00:38, Blair Zajac wrote: > Is this on the wiki? The guide is where things should be documented. I don't know if all of this is already there. I'm guessing not, since there seems to have been so much confusion about it. I don't spend as much time as maybe I should in upd

Re: shellescape proc

On Jun 28, 2020, at 02:08, Fred Wright wrote: > On Sun, 28 Jun 2020, Ryan Schmidt wrote: >> On Jun 27, 2020, at 23:18, Fred Wright wrote: >>> On Fri, 26 Jun 2020, Ryan Schmidt wrote: > [...] >>>> Looks like neither shellescape nor quotemeta are documented in

Re: [MacPorts] FAQ modified

On Jun 29, 2020, at 07:54, MacPorts Wiki wrote: > Page "FAQ" was changed by Schamschula > Diff URL: > Revision 175 > Changes: > ---8<--8<--8<--8<--8<--8<--8<--8< > Index: FAQ > =

Re: our "sudo port install gnome" metaport is not working -- GNOME needs help

On Jul 1, 2020, at 12:09, Ken Cunningham wrote: > this I think “sudo port install gnome" is a popular metaport, but it’s > presently broken > > initially polari won’t build, but that’s because gjs won’t build, but that’s > because we don’t have mozjs68 … and then who knows... Is this build

Re: Building GTK-dependents +quartz vs. +x11

On Jul 3, 2020, at 06:45, David Richmond wrote: > I saw some old discussion on the user list > (https://lists.macports.org/pipermail/macports-users/2016-October/042063.html) > about some challenges of +quartz / +x11 builds and conflicts with GTK. So I > don't think (?) the following behavior

Re: Google Magenta Portfiles Help Request for new py-note-seq port

On Jul 3, 2020, at 14:23, Steven Smith wrote: >> revision20200622 revision should be 0. >> version 0.0.0 version should probably be 20200622, unless they have a real version number. >> test.env-append \ >> "PATH=$env(PATH):${workpath}/bin" \

Re: Google Magenta Portfiles Help Request for new py-note-seq port

On Jul 5, 2020, at 03:01, Joshua Root wrote: > On 2020-7-5 06:35 , Jason Liu wrote: >>If upstream doesn't have a useful version number, you need to make >>one up. It should monotonically increase over time. It should change >>whenever the upstream source code you are installing from ch

Re: clang, c++17, std::optional, and libc++.dylib

On Jul 5, 2020, at 00:33, Ken Cunningham wrote: > It is quite simple (I think) to inline a function implementing > bad_optional_access into the header. That could be used for 10.7 > to 10.12, and then all those systems could comfortably implement c++17, and > no problem. Otherwise we have to i

Re: Some questions regarding MacPorts legacy support package

On Jul 4, 2020, at 15:44, Jason Liu wrote: > Question 2: > > A related question is that in MacportsLegacySupport.h, you guys use version > numbers such as 101300, 1070, etc. instead of the constants that are defined > in AvailabilityMacros.h, such as MAC_OS_X_VERSION_10_13, > MAC_OS_X_VERSI

Re: Deepmind Tree Bazel Build Portfile Help Request

I can't provide any advice on bazel, but I can give a few comments on the portfile: >> # -*- 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 compilers 1.0 Are

Re: several messages

On Jul 5, 2020, at 17:15, Jason Liu wrote: > My guess, however, that the more likely reason upstream projects don't > typically keep these sorts of fixes around is because they don't want it > dirtying up their code for any longer than necessary. Even if you strip out > the comment lines, th

Re: Deepmind Tree Bazel Build Portfile Help Request

On Jul 7, 2020, at 06:17, Steven Smith wrote: > On Jul 6, 2020, at 11:54 AM, Ryan Schmidt wrote: > >> Usually the defaults of the github portgroup should be sufficient. But >> you're mixing it with the python portgroup, and it's possible that the >> python p

Re: Deepmind Tree Bazel Build Portfile Help Request

On Jul 7, 2020, at 12:53, Steven Smith wrote: > Fixed the issue: requires creation of TMPDIR > > xinstall -d ${worksrcpath}/tmp MacPorts already sets the TMPDIR environment variable to ${workpath}/.tmp and creates that directory for you. Sounds like this build system needs to be fixed to use $

Re: Deepmind Tree Bazel Build Portfile Help Request

On Jul 7, 2020, at 14:15, Steven Smith wrote: > New issue `port destroot` tries to build with bazel again, and this breaks > because of permissions issues. > > Is there a simple way to just copy the stuff it already built into destroot? That's what one would expect "make install" (or whateve

Re: Deepmind Tree Bazel Build Portfile Help Request

And that's a bug that they could fix by respecting the value of the TMPDIR environment variable. > On Jul 7, 2020, at 17:21, Steven Smith wrote: > > “The wonderful bazel build system” expects to see ./tmp, not ./.tmp. > >> On Jul 7, 2020, at 3:45 PM, Ryan Schmidt wrote

Re: Issues with qmake5 PortGroup

On Jul 11, 2020, at 02:29, Nicolas Pavillon wrote: > Recently, I had issues with updating several qt5 ports, such as > qscintilla-qt5 (updated recently), or py37-pyqt5, all related to the qmake5 > PortGroup. > > The errors I am experiencing are similar to the one reported in > https://trac.ma

Re: Could someone please give a look to this PR?

I had hoped the maintainer would comment, but since he didn't, I merged it. On Jul 20, 2020, at 13:40, Ruben Di Battista wrote: > Ping! :) > > On Thu, Jul 2, 2020 at 8:34 PM Ruben Di Battista wrote: >> >> https://github.com/macports/macports-ports/pull/6924

Re: Help with UsingTheRightCompiler

On Jul 23, 2020, at 10:18, Frank Schima wrote: > I’m trying to get the new Portfile ncplot to UseTheRightCompiler. It uses a > primitive Makefile but not a configure file. So I added the makefile 1.0 > portgroup. However, I get a build error when I do. Can anyone help? > > Error is: > > :in

Re: Help with UsingTheRightCompiler

> On Jul 23, 2020, at 11:27, Frank Schima wrote: > > Hi Ryan, > >> On Jul 23, 2020, at 9:52 AM, Ryan Schmidt wrote: >> >> On Jul 23, 2020, at 10:18, Frank Schima wrote: >> >>> I’m trying to get the new Portfile ncplot to UseTheRightCompiler

Re: Help with UsingTheRightCompiler

On Jul 23, 2020, at 11:53, Christopher Jones wrote: >> Mojave 10.14 and later doesn't provide /usr/include anymore. System headers >> like are only in the SDK now. Note the -isystem flag with the >> path to the SDK isn't in that compile line. MacPorts put that flag into >> CFLAGS, CXXFLAGS,

Re: Help with UsingTheRightCompiler

On Jul 24, 2020, at 13:47, Frank Schima wrote: > I tried setting CC like so: > > build.args CC="${configure.cpp} [get_canonical_archflags cc]" > > But it still does not work. Here is the resulting compiler used: > > /usr/bin/cpp -arch x86_64 -Wall -g -O2 -I/opt/X11/include -DPNG -DP

Re: PRs now going back 18 months -- let's close the clearly dead ones

> On Jul 25, 2020, at 15:38, Ken Cunningham wrote: > > There are ancient PRs that are never going to be committed in the queue. > > This is just noise, and prevents us from keeping things moving. > > The people who opened them seem attached to them, but they are clearly dead > and need to be

Re: Distfile Mirror Issues

On Jul 27, 2020, at 18:27, Fred Wright wrote: > While investigating the distfile fetch problem with the util-linux port, I > noticed that a couple of the mirrors seem to be misbehaving in ways unrelated > to the missing file: Thanks for letting us know. > DEBUG: Fetching distfile failed: Unkn

Re: Distfile Mirror Issues

On Jul 28, 2020, at 13:06, Fred Wright wrote: > On Tue, 28 Jul 2020, Ryan Schmidt wrote: >> On Jul 27, 2020, at 18:27, Fred Wright wrote: > [...] >>> DEBUG: Fetching distfile failed: Unknown SSL protocol error in connection >>> to jnb.za.distfiles.macports.org:-

Re: Distfile Mirror Issues

On Jul 28, 2020, at 20:29, Ryan Schmidt wrote: > I'll ask them if they want to enable older algorithms or allow non-https > access. If they want to do neither, I'll configure MacPorts to remove that > mirror on OS versions that can't connect to it. They've

Re: Distfile Mirror Issues

On Jul 29, 2020, at 16:56, Fred Wright wrote: > On Wed, 29 Jul 2020, Ryan Schmidt wrote: >> On Jul 28, 2020, at 20:29, Ryan Schmidt wrote: >> >>> I'll ask them if they want to enable older algorithms or allow non-https >>> access. If they want to do neit

Re: Specifying multiple executable arguments using startupitems

On Jun 14, 2020, at 16:08, Ryan Schmidt wrote: > On Jun 14, 2020, at 11:45, Ryan Schmidt wrote: > >> Is this a bug? > > On the assumption that it is, I believe this is the fix: > > https://github.com/macports/macports-base/pull/191 The bug has been fixed in 2.6.3.

Re: port "cask" -- installing prebuilt binaries

On Aug 5, 2020, at 07:52, Georges Martin wrote: > If MacPorts starts to mix both approaches, I worry we may end up having (open > source) packages depending on closed source, binary packages. We already have that, by necessity. For example, php-excel is an open source php module that depends

Re: port "cask" -- installing prebuilt binaries

On Aug 6, 2020, at 09:10, Ken Cunningham wrote: > So a port that installs the Zoom teleconferencing application would be called > "zoom_binary". (We can't use "zoom-binary" because variants us the + and - to > do their thing.) Calling it "zoom-binary" would be fine. Yes, "+" and "-" are used

Re: port "cask" -- installing prebuilt binaries

On Aug 6, 2020, at 10:32, Arno Hautala wrote: > Have any developers asked for source not to be mirrored? A few; see "port echo license:nomirror"

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 13:34, Arno Hautala wrote: > >> On 6 Aug 2020, at 14:06, Ken Cunningham wrote: >> >> Along with name-suffix, a category was actually one of the first suggestions >> in the original post 50 posts ago, but how does one see which ports you have >> installed that are members

Re: port "cask" -- installing prebuilt binaries

On Aug 6, 2020, at 21:20, Ruben Di Battista wrote: > If they've been built somewhere by the upstream developer, shouldn't we be > able to build them too and hence instead of providing them as binaries we > would fix the ports in order to build on old systems? I guess it's a matter > of how

Re: port "cask" -- installing prebuilt binaries

On Aug 7, 2020, at 10:49, Ken Cunningham wrote: > By the way, for an SDK port, Gcenx has done one in an interesting way that > might be useful too. > > Well that's just my port with further modifications. When I g

Writing useful comments in Portfiles

Most Portfiles don't need any comments. We especially want to avoid comments that do nothing but state what the code is doing; such comments are counterproductive because they force the reader to read more without giving them more information, and such comments can also easily get out of sync wi

Re: port release candidate versioning question

On Aug 17, 2020, at 13:39, Arno Hautala wrote: > On 17 Aug 2020, at 14:35, Arno Hautala wrote: > >> To verify this, and to test other cases, you can try the ‘vercmp’ script > > I should probably have included a link to the script, instead a test of the > comparisons… > > https://svn.macport

Re: port release candidate versioning question

> On Aug 17, 2020, at 15:11, Arno Hautala wrote: > > >> On 17 Aug 2020, at 15:40, Ryan Schmidt wrote: >> >> We do not recommend setting the epoch to a date-like value. Simply use an >> increasing integer value. Its default value is 0. The first time you nee

Re: bison

On Aug 18, 2020, at 22:45, Takeshi Enomoto wrote: > I experienced a build error probably due to the behaviour of a recent > version of bison. > > Is anyone in the list aware of the changes in bison? > > I fixed udunits by using Berkeley Yacc (byacc). > metview requires bison, so I used /usr/bin/

Re: activate hidden files

Do you mean files starting with "._"? If so, see: https://trac.macports.org/ticket/60749 > On Aug 19, 2020, at 00:55, Takeshi Enomoto wrote: > > I noticed that bsd tar ignores all the files starting with . > but gnutar includes them except for . and .. > > 2020年8月19日(水) 12:47 Takeshi Enomoto: >

Re: activate hidden files

files that ultimately get extracted upon activation to be the same. It would probably be a good idea to report this to the developers of MetView as a bug ask them to name their mv_iconlist and mv_viewinfo files differently so as to avoid the "._" prefix. On Aug 20, 2020, at 02:29

Re: supertuxkart non-redistributable?

On Aug 24, 2020, at 20:57, Kurt Hindenburg wrote: > https://trac.macports.org/browser/trunk/base/portmgr/jobs/port_binary_distributable.tcl That's a link to our old Subversion repository; we moved to Git in late 2016. The link to the current version of that script is: https://trac.macports.org/

Re: Need help with troubleshooting Blender PR

> On Aug 27, 2020, at 14:55, Jason Liu wrote: > > Yes, I see what you're talking about now. And since I've only used machines > that had a single SDK installed, I've never encountered this problem. > > As far as I can tell, the value of configure.sdkroot is empty That is the case sometimes,

Re: Need help with troubleshooting Blender PR

On Aug 27, 2020, at 19:06, Joshua Root wrote: > For that reason, we strongly prefer to use an SDK that matches the > deployment target. That will often only be available in the Command Line > Tools, which means you'll see paths in /Library/Developer even when > Xcode is being used. We have see

Re: Need help with troubleshooting Blender PR

On Aug 28, 2020, at 09:55, Jason Liu wrote: >>> However, later in the build, it looks like the MacPorts build system sets >>> SDKROOT based off the value MACOSX_DEPLOYMENT_TARGET. >> >> As far as I know, MacPorts does not do that. > > Then it's possible that CMake is doing that. Regardless,

Re: Portfile: fetching/verifying a single file

On Aug 28, 2020, at 21:52, Eric F wrote: > When downloading/fetching a single (script) file from a Git repo. If I use: > > ``` > fetch { > file mkdir ${worksrcpath} > system -W ${worksrcpath} "curl -qs ${master_sites}/${_file} -o > ${distpath}/${distname}" > } > > post-checksum { >

Re: Portfile: fetching/verifying a single file

On Aug 28, 2020, at 22:24, Jason Liu wrote: > If you're fetching a single script file from a Git repo, then can't you > simply use the built-in fetch keywords, set 'fetch.type git', and then set > the extract phase to be empty? Don't use fetch.type git unless fetching a distfile would not wo

Re: Need help with troubleshooting Blender PR

On Aug 29, 2020, at 01:41, Ken Cunningham wrote: > There is an idiosyncrasy in MacPorts base wherein if the SDKROOT is "/" then > MacPorts base leaves ${configure.sdkroot} as "". This causes a number of > ports to break, and we can't seem to agree on how to fix that, so you have to > test t

Re: Need help with troubleshooting Blender PR

> On Aug 29, 2020, at 14:03, Ken Cunningham wrote: > > > On 2020-08-29, at 1:42 AM, Ryan Schmidt wrote: > > >> >> Is there a ticket about this? > > This is the ticket <https://trac.macports.org/ticket/59798> Thanks, somehow I had been unable

Re: Factors determining binary archivability

On Sep 7, 2020, at 01:09, Jason Liu wrote: > It's a relief to see that the 10.15 and 10.12 builds completed successfully > on the buildbot server. I'm not really surprised by the failures for the 10.9 > and older builders... Blender's code isn't really supposed to be compatible > with such o

Re: Travis CI timeouts for MacPorts builds

> On Sep 7, 2020, at 08:50, Mojca Miklavec wrote: > > On Mon, 7 Sep 2020 at 10:46, Ralph Seichter wrote: >> >> I fail to remember the last time one of my builds successfully passed >> Travis CI. All I see are timeouts [1]. Other peoples' jobs apparently >> make it through Travis OK, so I wande

Re: Travis CI timeouts for MacPorts builds

On Sep 7, 2020, at 11:24, Ruben Di Battista wrote: > Would à Linux machine with some virtualization method (libvirt?) be > acceptable as CI runner? I can't see how, since we're trying to verify builds of ports, and there is no general expectation that port builds would work on non-Mac opera

Re: Travis CI timeouts for MacPorts builds

On Sep 7, 2020, at 13:25, Ralph Seichter wrote: > * Mojca Miklavec: > >> It tries to install dependencies as binaries, provided the binaries >> are available. > > Tries being the operative word here. ;-) What are you trying to say? It uses binary archives if available, and they should be av

Re: Travis CI timeouts for MacPorts builds

On Sep 8, 2020, at 11:39, Mojca Miklavec wrote: > On Tue, 8 Sep 2020 at 18:28, Ryan Schmidt wrote: >> On Sep 7, 2020, at 11:24, Ruben Di Battista wrote: >> >>> Would à Linux machine with some virtualization method (libvirt?) be >>> acceptable as CI runner? &g

Re: Travis CI timeouts for MacPorts builds

On Sep 9, 2020, at 06:31, Zero King wrote: > However, GitHub Actions does not provide a list of IP addresses > AFAIK, so integration with paste.macports.org would be difficult. Maybe > I should just use the other pastebin and hardcode the URL into mpbot-ci > to avoid it being inherited in macpo

Re: if we are going to support universal arm/x86_64 ports, we'll likely need a multi-architecture gcc again

On Sep 13, 2020, at 12:21, Ken Cunningham wrote: > I’m not sure if the MacPorts plan is to support universal arm/x86_64 builds, > but I can imagine that for some years we might want to consider doing that. Absolutely. That's why I sent out a message about it in April: https://lists.macports.org

Re: spread-sheet-widget not redistributable

On Sep 11, 2020, at 14:49, Christopher Chavez wrote: > Continuing the recent topic of (L)GPL port openssl dependency > nonredistributability: > > I notice the spread-sheet-widget port claims to be affected by this. > It is not a large port, but it only has coreutils and pkgconfig as build > de

Thoughts on switching our archive compression method

It would be nice if we could easily switch our precompiled archives from bzip2-compressed tarballs (tbz2) to better compression methods as they become available. For example, xz-compressed tarballs (txz) would be better today. OS X 10.9 Mavericks and later has built-in support for xz compression

Re: Thoughts on switching our archive compression method

On Sep 22, 2020, at 07:58, Vincent wrote: >> It would be nice if we could easily switch our precompiled archives from >> bzip2-compressed tarballs (tbz2) to better compression methods as they >> become available. For example, xz-compressed tarballs (txz) would be better >> today. OS X 10.9 Mave

Re: Thoughts on switching our archive compression method

On Sep 22, 2020, at 13:28, Vincent Habchi wrote: >> (xz is 85% of bz2 size) >> (xz is 70% of bz2 size) >> (xz is 57% of bz2 size) >> >> So I think we could save ourselves and our mirror providers, CDN, and users >> some disk space and bandwidth by switching to xz. bz2 was the best available

Re: Apple ARM binary codesign issue

On Sep 22, 2020, at 13:29, Michael Dickens wrote: > % codesign -v - --ignore-resources > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: > invalid signature (code or signature have been

Re: Apple ARM binary codesign issue

On Sep 22, 2020, at 14:19, Michael Dickens wrote: > I have macOS 11.0beta7 installed : check! > > Compare / contrast ARM Mac versus MacBook Pro 16 : check! > > I have Xcode 12.2 beta installed : check! > > I've removed "/Library/Developer/CommandLineTools" : check! > > I hope that Apple fix

Re: Apple ARM binary codesign issue

On Sep 22, 2020, at 14:52, Ken Cunningham wrote: > On 2020-09-22, at 11:58 AM, Ryan Schmidt wrote: >> >> I hope that Apple fixes their toolchain to work without such intervention. > > I believe this may ultimately come under the category of "intended >

Re: Apple ARM binary codesign issue

Leandro, feel free to make meaningful contributions to our conversations but please stop spamming the list with links to your "apple sucks" photo gallery or I will ban you. On Sep 23, 2020, at 13:07, Leandro neto wrote: > look please!!

Re: Apple ARM binary codesign issue

On Sep 23, 2020, at 03:37, Ruben Di Battista wrote: > Can't be an easier choice to push globally a linker switch, if it exists, to > disable codesigning altogether for MP software? macOS 11 on ARM now require codesigning. Binaries that are not codesigned cannot be used at all.

Re: Thoughts on switching our archive compression method

On Sep 23, 2020, at 04:29, Dan Ports wrote: > Also, bz2 is particularly slow at decompression, so even xz is likely > an improvement there. As far as compression/decompression time goes, the normal gzip, bzip2 and xz tools are single-threaded, as far as I know, so there is an opportunity to g

Re: Apple ARM binary codesign issue

On Sep 22, 2020, at 18:05, Richard L. Hamilton wrote: > How will additional signing requirements impact MacPorts binary distribution > (which is a huge timesaver for installs and updates, if one doesn't have to > build most packages oneself)? As I understand it, it should not affect that at all

Re: Apple ARM binary codesign issue

On Sep 22, 2020, at 17:24, Ken Cunningham wrote: > On 2020-09-22, at 12:58 PM, Ryan Schmidt wrote: >> >> To me it seems unrealistic for Apple to suggest that an infinite number of >> open source projects, many of whose developers have never seen a Mac, should >>

Re: Thoughts on switching our archive compression method

On Sep 24, 2020, at 08:39, Lothar Haeger wrote: > > Reading "xz" and "archive" in the same sentence reminds me of > https://www.nongnu.org/lzip/xz_inadequate.html > > While it's easy to read the above as a rant of a disappointed competitor, he > seems to make some valid points about why lzma/xz

Re: Apple ARM binary codesign issue

On Sep 24, 2020, at 08:51, Ruben Di Battista wrote: > Ok, that's what I didn't know. I thought It was mandatory for Apple Store > software and not everything... 😔 Yup. As of macOS Big Sur 11 beta 6, released September 3, 2020, codesigning is mandatory for everything on ARM Macs. How to deal

Re: Apple ARM binary codesign issue

On Sep 25, 2020, at 10:31, Michael Dickens wrote: > Install scripts are calling ‘install -s’ which in turn calls ‘strip’. > > After fighting with my hacks for a while I do think the best option is the > very-final-destroot as mentioned. > > I’d appreciate any advice on where and how to add t

Re: port "cask" -- installing prebuilt binaries

Lothar, I agree with most of your reasoning for why a variant is a reasonable choice for indicating a prebuilt binary. I am less concerned with how to indicate prebuilt status than I am with whether we should do it at all. For ports that are not available any way other than prebuilt, I'm not sur

Re: Supporting installing arbitrary port versions (was: Re: port "cask" -- installing prebuilt binaries)

On Oct 3, 2020, at 06:05, Lothar Haeger wrote: >> It's because, besides being an unimaginably large amount of work in >> rearranging our code to do it, I have absolutely no idea how it would be >> accomplished without providing the user with unlimited opportunities to >> create broken combin

Re: Supporting installing arbitrary port versions

On Oct 3, 2020, at 23:40, Jason Liu wrote: >> Just looking at your idea to distribute all portfile versions, let's start >> with the fact that portfile syntax has evolved over time. > > This is where portfile syntax itself can, and probably should, be versioned. > Maybe by incrementing PortSyst

Re: Package managers and package versioning

> On Oct 3, 2020, at 20:23, Jason Liu wrote: > >> On Fri, Oct 2, 2020 at 9:00 PM Ryan Schmidt wrote: >> >> On Oct 2, 2020, at 17:42, Lothar Haeger wrote: >>> Instead of creating separate copies of perl for each version, it would've >>> probably

Re: Supporting installing arbitrary port versions

On Oct 4, 2020, at 06:02, Ruben Di Battista wrote: > Is this something that really needs to be implemented from scratch? > There are other package managers that do this and are build to do this > (nix and spack come to mind). I don't know the difficulties of what > I'm going to propose, but wou

Re: How to abort a macports portfile on an error condition?

On Oct 3, 2020, at 05:42, Nils Breunese wrote: > There is also ‘known_fail yes’, which I see getting combined with ‘return > -code error’: https://trac.macports.org/ticket/60566 > > I’m not familiar with the precise differences between known_fail, ui_error > and return -code error. ui_error

Re: Package managers and package versioning

On Oct 4, 2020, at 14:09, Jason Liu wrote: >> Where by "this" you again mean the ability to specify a previously-available >> version, not an arbitrary version that was never in a portfile. > > Yes, of course. If you look at the folder for the Blender package on the > Debian repo > > http:/

Re: waf.python configurable?

On Oct 4, 2020, at 16:08, Zhenfu Shi wrote: > I’m working on mpv portfile but I couldn’t find a way to change {waf.python}, > the python executable needed for waf. It’s currently failing to configure on > buildbots. In https://trac.macports.org/ticket/57927 the original maker of > waf portgroup

Re: How to close a Trac ticket assigned to me

On Oct 15, 2020, at 20:51, Ralph Seichter wrote: > I checked https://trac.macports.org/wiki/TracTickets for details, but it > looks like I cannot change status and resolution for a Trac ticket which > is currently assigned to me. Is this deliberate? The "modify ticket" > section of the web UI o

Re: [MacPorts] #61327: py-rpy2 build fails with clang: error: unsupported option '-fopenmp'

On Oct 15, 2020, at 22:57, Christopher Chavez wrote: >> Comment (by kencu): > >> …Ryan has made it clear he does not want every build to be forced to a >> macports clang compiler as that causes the drives on the buildbots to die >> prematurely due to all the installing and uninstalling of macp

Re: Fetch problem on 10.11 and earlier (acpica)

On Oct 17, 2020, at 19:34, Joshua Root wrote: > On 2020-10-18 11:25 , Zhenfu Shi via macports-dev wrote: >> Hi all, >> >> I’m trying to update acpica port to the latest version, but it seems >> like curl on 10.11 and earlier systems have problem taking to the >> server: Details >>

Re: Updating OpenSSH port to 8.4p1

On Oct 16, 2020, at 20:26, Blake Garner wrote: > Thanks for the info and I'll have a look at the issues. I have setup a repo > to test updated and customized ports > https://github.com/trodemaster/blakeports . Successfully rolled the version > of openssh to 8.4p1 and incremented the port re

Re: [MacPorts] #61327: py-rpy2 build fails with clang: error: unsupported option '-fopenmp'

On Oct 17, 2020, at 04:56, Ken Cunningham wrote: >> It's correct that I would rather people didn't blacklist compilers that are >> capable of building a port. It wastes user and buildbot time and wears out >> the buildbot SSDs unnecessarily. > Half (more?) of the tickets on MP are from trying

Re: Fetch problem on 10.11 and earlier (acpica)

On Oct 18, 2020, at 20:04, Zhenfu Shi wrote: > So in the future I need to find another site that mirrored the newest source > and put it in (before the fix is implemented)? Ideally yes. > Also unrelated, how do I send messages from @macports.org address like you > all could do? I currently

Re: Fetch problem on 10.11 and earlier (acpica)

> On Oct 18, 2020, at 20:25, Zhenfu Shi wrote: > > > >> On Oct 18, 2020, at 21:07, Ryan Schmidt wrote: >> >> >> >> On Oct 18, 2020, at 20:04, Zhenfu Shi wrote: >> >>> So in the future I need to find another site that mirrore

<    2   3   4   5   6   7   8   9   10   11   >