Re: M1 CPU features

> On 26 Apr 2021, at 13:20, Jason Liu wrote: > > sysctl machdep.cpu.brand_string ; sysctl machdep.cpu | grep -i "avx\|sse” $ sysctl machdep.cpu.brand_string ; sysctl machdep.cpu | grep -i "avx\|sse” machdep.cpu.brand_string: Apple M1 -- arno s hautala/-| a...@alum.wpi.edu pgp

Re: M1 CPU features

> On 26 Apr 2021, at 13:28, Jason Liu wrote: > > Thanks Arno :) > > I'm kind of surprised that the M1 doesn't seem to support any SSE or AVX > > Does "sysctl machdep.cpu.features" return anything? Nope, nothing. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448

Re: Bash version on Big Sur?

> On 28 Jan 2021, at 13:11, Jason Liu wrote: > > What is the version of the built-in bash shell in Big Sur? > > Is it still "3.2.57(1)-release"? Yes And for reference: /bin/sh /bin/bash GNU bash, version 3.2.57(1)-release (arm64-apple-darwin20) Copyright (C) 2007 Free Software Foundation,

Re: port release candidate versioning question

> On 17 Aug 2020, at 17:22, Ryan Schmidt wrote: > > What is the benefit to anyone in being able to presume (but of course not to > know for certain without inspecting the git log/blame) that the epoch was > last changed in the port 15 years ago? > > I updated the guide 9 years ago with the

Re: port release candidate versioning question

> 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 need to > increase it, set it to 1; the second time, set it to 2, etc. Is there any specific

Re: port release candidate versioning question

> 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.macports.org/repository/macports/users/ryandesign/scrip

Re: port release candidate versioning question

> On 17 Aug 2020, at 13:28, Ken Cunningham > wrote: > > ie does macports see versions like this: > > 11.0.0 > 11-rc3 > 11-rc2 > 11-rc1 ? My understanding is that your example will indeed sort correctly. To verify this, and to test other cases, you can try the ‘vercmp’ script [1] [1]:

Re: port "cask" -- installing prebuilt binaries

> On 14 Aug 2020, at 19:11, Ken Cunningham > wrote: > > so -- what would a user typing > > sudo port -v install macvim +prebuild_binary -huge +big +ruby25 +tcl +xim > > be expected to get? It's a total shambles. > They’d see the same thing they see if they tried to run: > sudo port

Re: port "cask" -- installing prebuilt binaries

> On 7 Aug 2020, at 09:04, Ken Cunningham > wrote: > > If we use only category to mark as a binary port, what if we have a binary > port added (e.g. say lazarus) but then we later find out we can build that > port on some systems? Then we want the binary lazarus moved to > lazarus-binary,

Re: port "cask" -- installing prebuilt binaries

> 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 of that category? > > with a name suffix, easy. >

Re: port "cask" -- installing prebuilt binaries

> On 6 Aug 2020, at 11:03, Craig Treleaven wrote: > > So, pretend I don’t know how Homebrew’s cask system works. (I don’t.) > > 1) As a user, what is the advantage of this kind of system versus other > avenues for software (i.e. the Mac App Store or direct download of a dmg from > the

Re: port "cask" -- installing prebuilt binaries

> On 6 Aug 2020, at 10:10, 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. Could all of the “cask” ports be put in a second ports tree? Any source-based ports that wanted to

Re: Mirror size & completeness of binaries

On Fri, Mar 30, 2018 at 5:20 PM, Rainer Müller wrote: > > For example, in a future archive_sites.conf: > > name macports > platform darwin 18 > urls https://packages.macports.org/10.14/ \ >https://foo.bar.packages.macports.org/10.14/ > > name

Re: request for port peg command, to lock down a port at the currently installed version

I've seen this in other managers as "pin". Anyway, this gets tricky with managing dependencies. As you say, this would probably need to copy the current portfile, but it would also need to pin and copy anything that depends or is dependent on this port. And that's going to extend recursively out

Re: Search for a MacPorts Mascot: looking for talented artists

On Wed, Feb 21, 2018 at 3:50 PM, David Strubbe wrote: > I suggest a port crane (to fit with our name), e.g. > https://www.tripadvisor.com/LocationPhotoDirectLink-g32810-i36315229-Oakland_California.html I nominate "Portia McCrane - the MacPorts Port Crane". She'll be on

Re: [GSoC] migration

On Thu, Jul 13, 2017 at 11:34 AM, Joshua Root wrote: > > Depending on a variant is currently impossible. > > ... > > You do have to install the ports in dependency order to get it right, and > that is what restore_ports does. There may be cases where previously > inactive ports

Re: [GSoC] migration

On Wed, Jul 12, 2017 at 8:07 PM, Joshua Root wrote: > On 2017-7-13 08:10 , Umesh Singla wrote: >> >> 3. ensuring that active versions are installed after the inactive >> versions > > The install action of port(1) does execute the activate target, however your > code could

Re: Guidelines about trac tickets and pull requests

On Fri, Dec 30, 2016 at 10:43 AM, Mojca Miklavec wrote: > (a) Press the button to merge the changes, but the disadvantage is > that committer's email is then "quasi-random" (it cannot be configured > on per-project basis and I would get my personal email there instead > of the