Re: Using on macOS 10.13 with clang++-mp-13

[Ruben Di Battista]

More context:

basically it fills up (+ add the right library to link against) the `
filesystem.h.in` header template with the right #include and namespace
based on what is found on the platform. The idea was to use  or
 where available, and fallback to
https://github.com/gulrak/filesystem where not available.

On Wed, Jul 6, 2022 at 10:24 PM Ruben Di Battista 
wrote:

> A partial solution I implemented using `cmake` for a project of mine:
>
> 1.
> https://gitlab.com/rdbisme/mercurve/-/blob/master/cmake/ConfigureFilesystemHeader.cmake
> 2. https://gitlab.com/rdbisme/mercurve/-/blob/master/src/filesystem.h.in
> 3.
> https://gitlab.com/rdbisme/mercurve/-/blob/master/src/apps/CMakeLists.txt#L20
>
>
>
> That can be improved for the use case here mentioned? The check for macOS
> is commented in the ConfigureFilesystemHeader, but maybe it can be
> completed to make it work.
>
>
> On Sun, Jul 3, 2022 at 8:38 PM Ken Cunningham <
> ken.cunningham.web...@gmail.com> wrote:
>
>> This is an issue that will need solving, otherwise as filesystem is used
>> more (and it seems popular) all the systems prior to 10.15 will be left
>> behind.
>>
>> Filesystem uses features in libc++.dylib that are only present in 10.15
>> and newer. You are blocked from trying to use them on 10.14 and below by a
>> blocker in the clang "__config" header, that is easy to override, but when
>> you try to use filesystem, it will not find the libc++.dylib features and
>> will fail.
>>
>> You can (sometimes) use macports-libcxx to get past this. This however
>> introduces two versions of libc++.dylib into the softare mixture, and this
>> sometimes causes errors due to incompatibilities between libc++ versions
>> (ODR errors). If you are taking this route, linking in the newer libc++.a
>> statically has a higher chance of working properly (that is what Chrome
>> does on older MacOS systems).
>>
>> You can use gcc/libgcc, and newer versions of that have filesystem
>> support, but that causes it's own issues.
>>
>> There was an early version of filesystem available as
>>  with a linking static library on older versions
>> of clang. I forget when that disappeared, but maybe clang-8.0. It is
>> possible that this might be brought forward to newer clangs and made
>> available to older systems with modest effort. This is likely the most
>> robust approach going forward, as it is the same code (although older).
>>
>> There are a few versions of filesystem available from other places, some
>> header-only, that might or might not work in a general sense. These have
>> the disadvantage of having nothing to do with clang/llvm, therefore I
>> presume the chances of unfavourable interactions would be somewhat higher.
>>
>> Hope this is helpful,
>>
>> Ken
>>
>> On Sun, Jul 3, 2022 at 4:12 AM Mojca Miklavec  wrote:
>>
>>> Hi,
>>>
>>> I'm trying to build some sources that require  on 10.13
>>> using clang 13 (I can try with clang 14, but I doubt that it helps).
>>>
>>> What's the correct way to compile the following minimal example? Do I
>>> need to link against a newer libc++ somehow?
>>>
>>> If it's not feasible to do that, I'll target a newer OS, I was just
>>> silently hoping to have some success ;)
>>>
>>> Thank you,
>>> Mojca
>>>
>>> #include 
>>> #include 
>>>
>>> int main() {
>>> auto cwd = std::filesystem::current_path();
>>> printf("%s", cwd.c_str());
>>> return EXIT_SUCCESS;
>>> }
>>>
>>> > clang++-mp-13 test.cpp -o test
>>> test.cpp:5:16: error: no member named 'filesystem' in namespace 'std';
>>> did you mean 'std::__fs::filesystem'?
>>> auto cwd = std::filesystem::current_path();
>>>^~~
>>>std::__fs::filesystem
>>> /opt/local/libexec/llvm-13/bin/../include/c++/v1/filesystem:268:1:
>>> note: 'std::__fs::filesystem' declared here
>>> _LIBCPP_BEGIN_NAMESPACE_FILESYSTEM
>>> ^
>>> /opt/local/libexec/llvm-13/bin/../include/c++/v1/__config:816:58:
>>> note: expanded from macro '_LIBCPP_BEGIN_NAMESPACE_FILESYSTEM'
>>>   _LIBCPP_BEGIN_NAMESPACE_STD namespace __fs { namespace filesystem {
>>>  ^
>>> 1 error generated.
>>>
>>> > clang++-mp-13 -std=c++17 test.cpp -o test
>>> Undefined symbols for architecture x86_64:
>>>   "std::__1::__fs::filesystem::__cur

Re: Using on macOS 10.13 with clang++-mp-13

[Ruben Di Battista]

A partial solution I implemented using `cmake` for a project of mine:

1.
https://gitlab.com/rdbisme/mercurve/-/blob/master/cmake/ConfigureFilesystemHeader.cmake
2. https://gitlab.com/rdbisme/mercurve/-/blob/master/src/filesystem.h.in
3.
https://gitlab.com/rdbisme/mercurve/-/blob/master/src/apps/CMakeLists.txt#L20



That can be improved for the use case here mentioned? The check for macOS
is commented in the ConfigureFilesystemHeader, but maybe it can be
completed to make it work.


On Sun, Jul 3, 2022 at 8:38 PM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> This is an issue that will need solving, otherwise as filesystem is used
> more (and it seems popular) all the systems prior to 10.15 will be left
> behind.
>
> Filesystem uses features in libc++.dylib that are only present in 10.15
> and newer. You are blocked from trying to use them on 10.14 and below by a
> blocker in the clang "__config" header, that is easy to override, but when
> you try to use filesystem, it will not find the libc++.dylib features and
> will fail.
>
> You can (sometimes) use macports-libcxx to get past this. This however
> introduces two versions of libc++.dylib into the softare mixture, and this
> sometimes causes errors due to incompatibilities between libc++ versions
> (ODR errors). If you are taking this route, linking in the newer libc++.a
> statically has a higher chance of working properly (that is what Chrome
> does on older MacOS systems).
>
> You can use gcc/libgcc, and newer versions of that have filesystem
> support, but that causes it's own issues.
>
> There was an early version of filesystem available as
>  with a linking static library on older versions
> of clang. I forget when that disappeared, but maybe clang-8.0. It is
> possible that this might be brought forward to newer clangs and made
> available to older systems with modest effort. This is likely the most
> robust approach going forward, as it is the same code (although older).
>
> There are a few versions of filesystem available from other places, some
> header-only, that might or might not work in a general sense. These have
> the disadvantage of having nothing to do with clang/llvm, therefore I
> presume the chances of unfavourable interactions would be somewhat higher.
>
> Hope this is helpful,
>
> Ken
>
> On Sun, Jul 3, 2022 at 4:12 AM Mojca Miklavec  wrote:
>
>> Hi,
>>
>> I'm trying to build some sources that require  on 10.13
>> using clang 13 (I can try with clang 14, but I doubt that it helps).
>>
>> What's the correct way to compile the following minimal example? Do I
>> need to link against a newer libc++ somehow?
>>
>> If it's not feasible to do that, I'll target a newer OS, I was just
>> silently hoping to have some success ;)
>>
>> Thank you,
>> Mojca
>>
>> #include 
>> #include 
>>
>> int main() {
>> auto cwd = std::filesystem::current_path();
>> printf("%s", cwd.c_str());
>> return EXIT_SUCCESS;
>> }
>>
>> > clang++-mp-13 test.cpp -o test
>> test.cpp:5:16: error: no member named 'filesystem' in namespace 'std';
>> did you mean 'std::__fs::filesystem'?
>> auto cwd = std::filesystem::current_path();
>>^~~
>>std::__fs::filesystem
>> /opt/local/libexec/llvm-13/bin/../include/c++/v1/filesystem:268:1:
>> note: 'std::__fs::filesystem' declared here
>> _LIBCPP_BEGIN_NAMESPACE_FILESYSTEM
>> ^
>> /opt/local/libexec/llvm-13/bin/../include/c++/v1/__config:816:58:
>> note: expanded from macro '_LIBCPP_BEGIN_NAMESPACE_FILESYSTEM'
>>   _LIBCPP_BEGIN_NAMESPACE_STD namespace __fs { namespace filesystem {
>>  ^
>> 1 error generated.
>>
>> > clang++-mp-13 -std=c++17 test.cpp -o test
>> Undefined symbols for architecture x86_64:
>>   "std::__1::__fs::filesystem::__current_path(std::__1::error_code*)",
>> referenced from:
>>   std::__1::__fs::filesystem::current_path() in test-1b2bbf.o
>> ld: symbol(s) not found for architecture x86_64
>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>>
>

-- 
..
   /**\
  /\
 /\/\
/  \**/  \
   /\/\
  / /\/\
 / \   /  \  /  \
/   \ /\/\
\/\/\/
 \  /  \  /  \  /
  \/\/\/
/\
   / +\
   \+ /
\/
  rdb.is
   Book a meeting with me:
 https://calendly.com/rdbisme

Re: GitHub Sponsors

[Ruben Di Battista]

I can also act as local representative since I have an address in France. I
recently created the association to back the event https://spacecon.io and
I can maybe help on the procedure.

On Sat, Nov 13, 2021 at 5:57 PM Vincent Habchi  wrote:

> > On 13 Nov 2021, at 17:46, Mojca Miklavec  wrote:
> >
> > I've been in favour of establishing a French non-profit org (1901).
> > We've had one for more than 10 years and there's nearly no overhead.
> > One needs a trustworthy representative person with an address in
> > France, at least a president and an accountant (living anywhere in the
> > world), the bylaws need to be written, but other than that it's super
> > liberal and convenient.
>
> If it serves, I can act as local representative. Besides, I’ve been ‘at
> the rudder’ of my former ham-radio association for almost ten years, so I
> know the ropes.
>
> And no, you don’t need a president or an accountant. That’s what most
> people do, mostly because they believe it is compulsory, but it isn’t. You
> can setup a collegial leadership. The only requirement is to have someone
> accountable if the association goes astray (civil responsibility). But that
> someone can be someones :) I mean, in case of a collegial leadership, every
> member of the ‘head council’ would be equally accountable.
>
> If you’re interested, I can develop a bit more.
>
> Vincent
>
>

-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is
Book a meeting with me: https://calendly.com/rdbisme

Re: Help offered (macOS VMs)

[Ruben Di Battista]

I'm also very slowly working on this (the `slowly` is PhD related) and I
was targeting KVM. I'll probably give a try also to Hyper-V since I started
using Windows 11 with WSL for development.

You can probably search in the list posts from me where we discussed this a
bit in details.

On Tue, 7 Sep 2021, 10:09 Bjarne D Mathiesen, 
wrote:

> Mojca Miklavec wrote:
> > 5.) We're looking for someone willing to play around with macOS VMs,
> > in particular the older ones: 10.6 (or even 10.4/10.5 for utter geeks)
> > and newer. We currently run CI jobs just on what GitHub provides (2 or
> > 3 latest OSes), but it would be nice to set up disposable VMs where we
> > could fire up a VM, build the ports from CI, and destroy the VM.
>
> What hypervisor it the target ?
>
> I have tried to get a 10.6.8 to work in VirtualBox; but
> 1) it kept crashing
> 2) I couldn't get it to up the RAM above 2GB
>even though some mac systems ran 10.6 up to at least 8GB
>
> --
> 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 Port harfbuzz-devel/harfbuzz-devel-icu; Path-Style Dependency Now Needed

[Ruben Di Battista]

I’d guess targeting something like inkscape-gtk3-devel (bumping the version) 
would bring up most of the problems with all the dependencies. 
  
  _   
-. .´  | 
  ',  ;|∞∞ 
˜˜ |∞ RdB https://rdb.is
,.,|∞∞ 
  .'   '.  | 
-'   `’

> On 31 Aug 2021, at 16:11, Christopher Nielsen  
> wrote:
> 
>> On 2021-08-31-T, at 07:14, Christopher Nielsen  
>> wrote:
>> 
>>> On 2021-08-31-T, at 06:28, Ryan Schmidt  wrote:
>>> 
>>> I haven't been following everything closely and wasn't aware harfbuzz devel 
>>> ports were going to be introduced. But if they are, then you can make the 
>>> required dependency change to all ports in a single commit. I would not 
>>> consider it necessary to ask permission of the port maintainers since it's 
>>> not a matter of opinion; it's just a necessary change so that MacPorts can 
>>> continue to function as intended.
>> 
>> Sounds good; changes committed via the following:
>> 
>> https://github.com/macports/macports-ports/commit/f685ca73e40027b414af643d067ea402e754479c
>> https://github.com/macports/macports-ports/commit/77e3d9ee214f3c4826c4320a7ed3d7de1a00310d
> 
> Folks, now that this change is done, we can test dependent ports with the 
> Devel versions of harfbuzz/harfbuzz-icu, along with pango.
> 
> Does anyone know of any particularly fragile dependents on these - 
> particularly in terms of runtime behavior - that we can target? Meanwhile, 
> I’ll try to rebuild as many dependent ports as possible locally, to identify 
> obvious build issues.
> 
> And if any maintainers are interested in replacing their non-Devel versions 
> of pango/harfbuzz/harfbuzz-icu with the Devel versions, and testing locally, 
> we’d be grateful!
> 
> Any thoughts on the best approach to validate all of these, prior to updating 
> the non-Devel versions?
> 
> Thanks,
> -Chris

Re: New ports.macports.org website

[Ruben Di Battista]

 

On Tue, 20 Jul 2021, 18:54 Christopher Nielsen, 
wrote:

> Just took the new site for a spin, and all I can say is - WOW! It looks
> great, the design is very logical (if not perfect!), and it’s rich in
> functionality.
>
> It’s clear that a LOT of good thought/discussion went into the UI design,
> and boy did it pay off! Kudos to everyone involved in the effort!
>
> And I concur with Saagar, this is absolutely worthy of announcing via
> Twitter, and perhaps even a press release. Great stuff!

Re: Freenode IRC

[Ruben Di Battista]

I suggest switching to Matrix. It's very close to IRC experience (but
better), and it is more easily decentralizable. And it also works as
bouncer.

On Wed, May 19, 2021 at 8:27 PM Jeremy Lavergne via macports-dev <
macports-dev@lists.macports.org> wrote:

> This usually falls under "modern" expectations.
>
>
> On 5/19/21 2:25 PM, Andrew Janke wrote:
> > Have you considered using ZNC or another IRC "bouncer"? It'll retain and
> > replay history for you so you can get offline messages and have a
> > consistent message history between computers and devices. Pretty easy to
> > install if you have a Linux server somewhere, and hardly uses any
> resources.
>


-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is
Book a meeting with me: https://calendly.com/rdbisme

Re: [MacPorts] #59750: ffmpeg and ffmpeg-devel immediately crash with segfault 11 when input is mp4

[Ruben Di Battista]

I think so, yes!

On Tue, May 18, 2021 at 3:09 PM MacPorts  wrote:

> #59750: ffmpeg and ffmpeg-devel immediately crash with segfault 11 when
> input is
> mp4
> -+--
>   Reporter:  fdik|  Owner:  dbevans
>   Type:  defect  | Status:  assigned
>   Priority:  Normal  |  Milestone:
>  Component:  ports   |Version:  2.6.2
> Resolution:  |   Keywords:
>   Port:  ffmpeg  |
> -+--
>
> Comment (by mascguy):
>
>  Replying to [comment:14 rubendibattista]:
>  > In [changeset:"ab2056ca1b07d1dbc159473994516909a33b451a/macports-ports"
>  ab2056ca1b07d1dbc159473994516909a33b451a/macports-ports] (dar, master,
>  py38-reproject, revert-6945-rust-1.43.0, wireshark):
>  > {{{
>  > #!ConfigurableCommitTicketReference repository="macports-ports"
>  revision="ab2056ca1b07d1dbc159473994516909a33b451a"
>  > x264: Update snapshot
>  >
>  > This fixes a segmentation fault on Catalina
>  > See: https://trac.macports.org/ticket/59750
>  > }}}
>
>  Ruben, given the fix you committed a year ago, is this issue fixed?
>
> --
> Ticket URL: 
> MacPorts 
> Ports system for macOS
>


-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is
Book a meeting with me: https://calendly.com/rdbisme

Re: Homebrew Disables OSXFuse ports

[Ruben Di Battista]

I personally feel that the developer has the right of having their own
opinion, and rightly so. Lots of commercial software do not contribute back
to the foundation made by open source projects and the fact that it is
taken for granted that someone is working free on such important piece of
software makes me uncomfortable.

If the developer decides to stop working on the code, and the code stops
working on some machines, then maybe deleting the package has a reason.

At this point, I think Macports should keep shipping osxfuse and related
ports in binary form. But we already faced this discussion... 


On Tue, 18 May 2021, 02:27 Mark Anderson,  wrote:

> I agree with Perry, partly because the developer seems combative and I
> worry what happens if he decides to stop working on it one day.
>
> But I also don't want to remove all the ports - this kinda leads into why
> I want cask like functionality, but then again, who would notice if they
> just wanted to install ssh-fuse or something.
>
> My other issue is we have two ports - which I think Ryan indicated is
> kinda confusing/bad. That one seems easiest to fix.
>
> —Mark
> ___
> Mark E. Anderson 
> MacPorts Trac WikiPage 
> GitHub Profile 
>
>
>
> On Mon, May 17, 2021 at 7:06 PM Ryan Schmidt 
> wrote:
>
>> On May 17, 2021, at 08:44, Perry E. Metzger wrote:
>>
>> > On 5/17/21 01:44, Ryan Schmidt wrote:
>> >> On May 16, 2021, at 21:49, Mark Anderson wrote:
>> >>
>> >>> Given some of our recent back and forth, I found this interesting:
>> https://github.com/Homebrew/homebrew-core/pull/74812
>> >> Meh. They have different priorities than we do. No reason for us to
>> follow what they do.
>> >
>> > In this instance, though, I think their reasoning is correct.
>>
>> So you would like MacPorts to delete all ports that depend on osxfuse,
>> and all ports that depend on those ports, and so on?
>>
>> Each of those ports was added to MacPorts because someone wanted it. What
>> are they to do once we delete them?
>>
>>

Re: Homebrew Disables OSXFuse ports

[Ruben Di Battista]

I also agree with Ryan. Osxfuse is a dependency on some projects that are
very useful and shipping it in binary form is very therefore useful too.

On Mon, 17 May 2021, 07:44 Ryan Schmidt,  wrote:

> On May 16, 2021, at 21:49, Mark Anderson wrote:
>
> > Given some of our recent back and forth, I found this interesting:
> https://github.com/Homebrew/homebrew-core/pull/74812
>
> Meh. They have different priorities than we do. No reason for us to follow
> what they do.
>
>

Re: Becoming a legal entity and accepting donations (was: Re: Buildbot Performance)

[Ruben Di Battista]

Just as a side note, here in France I just created a non-profit association
for a project I'm working on related to the organization of an event, and
the process is almost free and reasonably fast. In a matter of few weeks we
had the association published on the official governmental gazette and a
bank account, also free of keeping charges.

Same thing in Italy.

I perfectly agree with the will of having the legal entity in US, but I
think the process in Europe might be less expensive at least, probably
faster.


On Mon, 17 May 2021, 08:02 Ryan Schmidt,  wrote:

> On May 16, 2021, at 14:46, Mark Anderson wrote:
>
> > I keep wondering if we became like a not-for-profit If we could get
> someone like MacStadium or Amazon or something to donate server time to us.
> Or accept donations from Github sponsorship. I could look into what that
> would take, although it might be way more trouble than it's worth. I think
> my current corp lawyer knows non-profit law - I could bring it up next time
> I see them.
>
> MacStadium already donates the use of an Apple Silicon Mac mini to us. I
> am not aware of whether Amazon offers free persistent Mac servers with root
> access to open source projects.
>
> Accepting donations through GitHub Sponsors or any other means would, I
> suspect, require the formation of a legal entity for MacPorts, which would
> be the owner of the business bank account we would probably have to open.
> We've discussed becoming a legal entity a few times over the years but it
> hasn't been done. If we do it, my preference would be for MacPorts to be a
> U.S. entity, since I am in the U.S. and since MacPorts was started by Apple
> and is for the benefit of Apple users and Apple is a U.S. company. A
> different suggestion was that we should join an existing free software
> organization and leave all the legalities up to them, and funnel donations
> through them. I don't think that idea was supported by everyone so that
> didn't happen either.
>
> If we accepted donations, we would have to develop guidelines for how the
> donations could be spent.
>
> Being recognized as a not-for-profit is a whole 'nother can of worms.
> First one has to form a legal entity, then one has to apply to be
> recognized as a not-for-profit (which incurs additional fees) and make a
> case for why that should be, a process which can take years, and the answer
> to the application could be no. For example there was increased scrutiny of
> non-profit organization applications in the field of open source software
> in 2010; see https://opensource.org/node/840. That's what I recall from
> researching the process in the U.S. It may differ in other countries.
>
>

Re: GitHub discussions

[Ruben Di Battista]

I agree with Ryan. Centralization on a less than optimal system is better
than fragmenting the communication on "cool systems".

My way of finding things in the list: using Google with the modifier `site:
lists.macports.org`. (I guess I'm not the only one)

On Sun, May 2, 2021 at 12:57 AM Ryan Schmidt 
wrote:

>
>
> On May 1, 2021, at 17:46, Gregory Anders wrote:
>
> > One potential solution might be something like public-inbox.org [1].
> This would provide an easy-to-access archive without fragmenting discussion
> further.
>
> Why would an archive created with public inbox be easier to use than the
> archives we already maintain at:
>
> https://lists.macports.org
>
> and the archives third parties already maintain at:
>
> https://trac.macports.org/wiki/MailingLists#archives
>
>

-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is
Book a meeting with me: https://calendly.com/rdbisme

Re: Desolate Condition

[Ruben Di Battista]

Since now we're starting to have stats collected, it might be maybe worth
it to provide binaries instead of standard variants, more for the most
requested ones?

On Sun, 4 Apr 2021, 04:07 Joshua Root,  wrote:

> On 2021-4-4 11:35 , Craig Treleaven wrote:
> >> On Apr 3, 2021, at 8:21 PM, wowfunha...@gmail.com
> >>   >> > wrote:
> >>
> >> I see this misconception /all over the place/, that Homebrew is fast
> >> because it uses prebuilt binaries, whereas MacPorts makes you wait
> >> while software is compiled. It can't /just/ be due to outdated
> >> information, if we're more than a decade out from when the buildbot
> >> went live.
> >>
> >> I know it's just one data point, but I thought the replies I got on
> >> this Hacker News comment today were interesting. I can understand why
> >> he/she got confused, and I wonder if there's anything MacPorts could
> >> do to make it clearer. https://news.ycombinator.com/item?id=26678498
> >> 
> >
> > It happens that I just did a self update and upgraded 20 ports on 10.15.
> >   6 or the 20 were built from source.  I believe this is higher than
> > usual due to the backlog on the 10.15 builbot.  Even in the best case,
> > however, a fair number of ports will be built from source for the
> > well-known reasons.  It would be interesting to know, say, how many of
> > our most-requested ports are always built from source.
> >
> >
> https://ports.macports.org/statistics/ports/?days=30=-req_count=-total_count=port
> > <
> https://ports.macports.org/statistics/ports/?days=30=-req_count=-total_count=port
> >
> >
> > Eg, git is our second-most requested port and it is always built from
> > source AFAIK.
> >
> > Almost any reasonably complex package will have some of its dependencies
> > that must be built from source.
> >
> > To the average user, I would suggest that we should emphasize that
> > MacPorts installs binaries whenever allowed by licensing but makes a
> > serious effort to avoid contravening the various open source licenses.
> >   Plus MacPorts offers many more options (“variants”) to customize
> > installations and offers a wide breadth of packages.
>
> I wrote a new FAQ and slightly reworded the one about universal
> binaries. The latter was originally written before the buildbot existed,
> so it was saying "build" where "install" is now more accurate. However
> +universal is still a non-default variant and so very often won't be
> available as a binary.
>
> - Josh
>

Re: Running macOS inside a Docker container

[Ruben Di Battista]

Thanks Mojca!

It's something I definitely want to do, but at the moment I'm busy with my
PhD manuscript. Hopefully it will be the end soon, and I'll dedicate a bit
of time to it.

On Sun, Mar 14, 2021 at 1:28 PM Mojca Miklavec  wrote:

> There's an interesting piece of news on slashdot:
>
> Open-Source App Lets Anyone Create a Virtual Army of Hackintoshes
>
>
> https://news.slashdot.org/story/21/03/11/2148210/open-source-app-lets-anyone-create-a-virtual-army-of-hackintoshes
>
> https://github.com/sickcodes/Docker-OSX
>
> This might potentially simplify doing CI on pull request on local
> infrastructure, the major disadvantage for us is that nobody did the
> work yet to make the older versions of Mac OS X work (according to the
> author of OSX-KVM that should be feasible). Here's a cool tutorial
> that might help understand the needs:
> https://dortania.github.io/OpenCore-Install-Guide/
> but it still needs quite some work to be done.
>
> Mojca
>


-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜   |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is

Help with old macOS on KVM?

[Ruben Di Battista]

Hello, I was exploring a bit how to build the CI system for old platforms
and the first step was to virtualize old macOS version. I'd like to do it
using KVM. I was following this: https://github.com/kholia/OSX-KVM, but
trying to install something like OSX 10.7, I can't go pass the OpenCore
screen because apparently it can't find the installation media I tried to
recover from a OSX 10.7 iso. So I guess that somehow I'm missing something
on how to retrieve the right iso, dmg or img from the installation DVD.

Does any of you ever virtualized old OSX systems on KVM?

-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜   |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is

Re: "cask" ports just keep on rolling in...

[Ruben Di Battista]

If I can express my opinion, I agree with Clemens.

In my opinion binary only ports should be allowed only for a very
restricted subset, where the effort is justified by the extreme complexity
of the build (and I'm also I'm not sure about that even, if someone managed
to build it, we should be able too ☺) or the port bering binary only (e.g.
osxfuse).



On Sun, 7 Feb 2021, 12:17 Clemens Lang,  wrote:

> Hi Ken,
>
> On Sat, Feb 06, 2021 at 11:35:58PM -0800, Ken Cunningham wrote:
> > although I was concerned about getting this pattern right before we
> > had too many of these to fix, it does seem the admins feel there's
> > really no issue to worry about here.
>
> I don't like this tone, Ken. "The admins" have as much obligation to
> provide infrastructure as anybody else in this project, which is none.
>
> If you feel repackaging binary archives is a thing MacPorts should
> support better, please invest the time to come up with patches that do
> this, or find somebody that will.
>
>
> > So I guess we just open the gate and let them in. There is no
> > recommendation for a requirement for a naming convention or other
> > identifier.
>
> Personally, I don't like this trend at all. It always used to be
> MacPorts' policy to compile from source except in cases where Apple's
> limitations made this impossible (e.g. because valid signatures with a
> developer certificate were required and an ad-hoc signature would not
> work).
>
> Now, we're apparently shipping binaries compiled by other people with
> other people's toolchains. When I previously installed things from
> MacPorts, I knew that I'd either compile those with my own toolchain
> locally, or that they had been compiled on MacPorts' buildbots.
> Repackaging binaries breaks that assumption and adds additional trusted
> third parties. If such parties were infiltrated by supply chain attacks
> such as Xcode Ghost, we'd now ship malware via 'port install'.
>
> I do know that we have recently started making more and more exceptions
> to this rule, e.g. for Java and Haskell, and I'm guilty of preferring
> these approaches to a broken build of a very outdated version, but I'd
> like to argue that we should keep asking ourselves the question "should
> we really trust this person's toolchain" before merging such ports and
> keep pushing for builds from source where those are feasible.
>
> Also, keep in mind that some licenses (GPL, LGPL) require us to ship the
> source code that was used to compile a certain binary. Our distfiles
> server does that automatically for everything that's compiled from
> source, but repackaging a binary that contains compiled GPL or LGPL code
> puts us in legal muddy water very quickly.
>
> --
> Clemens
>

Re: [MacPorts] #62174: cmake @3.19.3 tries to use sphinx-build-3.6 (was: cmake 3.19.3 tries to use sphinx-build-3.6)

[Ruben Di Battista]

Sorry, I probably tried to be too smart and I introduced a bug. I'll try to
fix it asap.

On Fri, 29 Jan 2021, 04:40 MacPorts,  wrote:

> #62174: cmake @3.19.3 tries to use sphinx-build-3.6
> -+---
>   Reporter:  EJFielding  |  Owner:  michaelld
>   Type:  defect  | Status:  assigned
>   Priority:  Normal  |  Milestone:
>  Component:  ports   |Version:  2.6.4
> Resolution:  |   Keywords:
>   Port:  cmake   |
> -+---
> Changes (by ryandesign):
>
>  * status:  new => assigned
>  * owner:  (none) => michaelld
>  * cc: michaelld (removed)
>  * cc: rubendibattista (added)
>
>
> Comment:
>
>  Replying to [ticket:62174 EJFielding]:
>  > I see in the log file that it is using `--sphinx-build=/opt/local/bin
>  /sphinx-build-3.6` but I don't have that installed.
>
>  The code was [changeset:7caeafd874efdc8030ad48de7c5c3614ca6ffc82/macports-
>  ports just refactored] a few days ago. Maybe this introduced a bug. Ruben,
>  can you have a look?
>
>  I notice some odd behavior myself, such as:
>
>  {{{
>  $ port info cmake +docs
>  Error: cmake: Error executing docs: can't read "PYTHON_VERSION_WITH_DOT":
>  no such variable
>  Error: Unable to open port: Error evaluating variants
>  }}}
>  {{{
>  $ port info cmake +python27
>  Error: Unable to open port: can't read "python_branch": no such variable
>  }}}
>
>
>  > I tried explicitly selecting the 3.7 Sphinx with `port select --set
>  sphinx py37-sphinx`, cleaning cmake, and building again, but it still
>  looks for the wrong version.
>
>  Ports should not be affected by what you `select`.
>
> --
> Ticket URL: 
> MacPorts 
> Ports system for macOS
>

Re: Can we enable CI for legacy systems?

[Ruben Di Battista]

I don't know Ryan. I find BuildBot pretty involved in the configuration.
The interface of Gitlab CI, the one I'm more familiar with, is way easier.
To configure a runner it's basically adding a repository on your favorite
distro, installing the gitlab-runner package, configuring it with few TOML
lines, and that's it. It will happily get your CI/CD jobs. And can be used
across multiple projects that might need access to old systems.

In any case I'll try to hack a fast solution at the beginning with that,
then we might discuss to use BuildBots.

PS: Gitlab CI can be used also on Github:
https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html

On Wed, Jan 27, 2021 at 7:17 PM Ryan Schmidt 
wrote:

> On Jan 27, 2021, at 06:32, Mojca Miklavec wrote:
>
> > Maybe GitLab runner isn't able to run on the oldest macOS that we
> > support, but if you run it on the host just to fire up a VM, that
> > might be ok.
> >
> > I see that GitLab supports CI on top of GitHub repository:
> >
> https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html
> >
> > Maybe that's not as straightforward as if the repo was stored on
> > GitLab directly, but it still sounds perfectly fine if you get it
> > working.
> >
> > Even if you just start with your own clone of the GitHub repo inside
> > GitLab and get it working, this would still represent some 90 % of the
> > job (majority of [a] and complete [c]).
> >
> >> PS: Does Github Action support custom "executors" to eventually run
> libvirt?
> >
> > I'm not so familiar with GitHub Actions, but we are currently using
> > buildbot for the official builds. That one certainly offers native
> > libvirt support:
> >
> https://docs.buildbot.net/latest/manual/configuration/workers-libvirt.html
>
> If it is helpful to do so during development, GitLab and/or GitHub Actions
> could be involved, but I see no reason why either of them would be relevant
> to what we end up deploying. Our repositories are hosted on GitHub, and it
> should be completely sufficient to have GitHub deliver web notifications
> about pull requests to whatever CI system we develop. As far as I know,
> Buildbot supports integration with GitHub PRs, and we already use Buildbot
> for the final builds, so it would make sense to me to use it for CI builds
> as well, if we're going to spend time developing our own system.
>
>
>

-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜   |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is

Re: Can we enable CI for legacy systems?

[Ruben Di Battista]

Ok, thanks Ryan. I'll think about it.

I'd do it on Gitlab, since they allow custom executors for their CI and I'm
familiar with it. Reading about Github Actions, that does not seem possible
and I'm not extremely familiar with Github APIs. If someone has ideas, feel
free to send them my way.

I'll update you when (and if) I'll have something useful.

On Mon, Jan 25, 2021 at 5:10 PM Ryan Schmidt 
wrote:

>
>
> On Jan 25, 2021, at 10:02, Ruben Di Battista wrote:
>
> > If I configured a server I own to run CI jobs for old systems (I was
> thinking about using a custom Gitlab runner libvirt
> https://docs.gitlab.com/runner/executors/custom_examples/libvirt.html for
> that and maybe), it's gonna be something useful that Macports could
> potentially use?
>
> I'm not sure how comfortable we would be with running builds on other
> users' hardware, but if you can develop the software process for cloning a
> template VM, getting buildbot or whatever running on it, accepting a job
> from a GitHub PR notification, and so forth, then we could possibly deploy
> it on our hardware. We currently use VMware ESXi on our Intel hardware. We
> do not have a plan yet for what we would do with Apple Silicon hardware.
>
> > PS: Does Github Action support custom "executors" to eventually run
> libvirt?
>
> I can't answer that. I haven't looked into how the CI systems we use work.
>
>

-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜   |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is

Re: Can we enable CI for legacy systems?

[Ruben Di Battista]

Hi Ryan, thanks for your answer.

If I configured a server I own to run CI jobs for old systems (I was
thinking about using a custom Gitlab runner libvirt
https://docs.gitlab.com/runner/executors/custom_examples/libvirt.html for
that and maybe), it's gonna be something useful that Macports could
potentially use?

PS: Does Github Action support custom "executors" to eventually run
libvirt?

On Mon, Jan 25, 2021 at 3:55 AM Ryan Schmidt 
wrote:

>
>
> On Jan 24, 2021, at 17:52, Ruben Di Battista wrote:
>
> > I think that one of the selling points of Macports, at least for me, is
> providing ports for legacy systems. So on the ports I maintain, I try to
> fix build issues on old systems. The problem is that it’s very difficult to
> do it since I need to merge blindly something and wait for the buildbots.
> >
> > Is there a way to use the buildbots as CI for legacy systems? That would
> really help... I could try to hack something out if you are interested,
> provided you can give me a bit of guidance on understanding how they work…
> They look pretty misterious to me. :)
>
> The short answer is no, we cannot "enable" CI for legacy systems. We can
> "spend a lot of time reimplementing the CI system on our own
> infrastructure" but nobody has done that yet.
>
> Our existing buildbot infrastructure stays running all the time, more or
> less. The VMs aren't rebooted except for maintenance reasons. This relies
> on the fact that the commits that are built there have already been vetted
> by MacPorts developers. There is some degree of assurance that the commits
> are "good" and won't trash the system.
>
> There is no such assurance when building code submitted in a pull request,
> since anyone with a GitHub account can submit a PR. It could contain "bad"
> or even malicious code. This is why our existing CI infrastructure
> (formerly using Travis CI and now using Azure Pipelines and GitHub Actions)
> starts up a clean VM for each pull request, installs MacPorts and the
> port's dependencies, tries to build the port, reports the results, then
> throws the VM away. These third party CI systems do not offer older
> versions of macOS, so to offer that, we would have to recreate their
> infrastructure on our own hardware. There has been talk of doing this, but
> nothing concrete has emerged.
>
> We also don't have much spare server capacity. With all of the different
> OS versions for which we build on the four Xserves that run the buildbot,
> the SSDs and RAM are just about full. Running additional VMs on the
> existing hardware would also slow down the other VMs since they're all
> competing for the same CPUs. We could buy more RAM and bigger SSDs or even
> additional servers, but MacPorts doesn't have a revenue stream so the
> existing buildbot hardware purchases have been paid for by me, and I don't
> want to commit to buying endless additional hardware. However, money is the
> least of the problem right now. If we had the software created and all that
> we needed was money to buy hardware, I'm sure it could be found.
>
> So with what we have now, it is fine to commit changes to ports that you
> *think* will fix a problem, even if you haven't verified the fix because
> you don't have access to the particular system where the problem occurs.
> This is relevant for Apple Silicon systems as well, since we don't have
> Apple Silicon build machines on our CI system yet. And this is what we did
> years ago before we had moved to GitHub, before we had pull requests,
> before we had CI systems.
>
> If you're interested in supporting older systems, you can install older OS
> versions on your Mac, either in separate volumes or partitions if your
> hardware supports booting to older OS versions, or in virtual machines with
> VMware Fusion, Parallels Desktop, or Oracle VirtualBox.
>
>
>

-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜   |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is

Can we enable CI for legacy systems?

[Ruben Di Battista]

Hello,

I think that one of the selling points of Macports, at least for me, is
providing ports for legacy systems. So on the ports I maintain, I try to
fix build issues on old systems. The problem is that it’s very difficult to
do it since I need to merge blindly something and wait for the buildbots.

Is there a way to use the buildbots as CI for legacy systems? That would
really help... I could try to hack something out if you are interested,
provided you can give me a bit of guidance on understanding how they work…
They look pretty misterious to me. :)



  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’
https://rdb.is

Re: openmpi and libevent use

[Ruben Di Battista]

I personally would prefer to have a direct dependency on the Macports
libevent, if there are not compatibility issues. That's what we also do
with VTK, where all the compatible dependencies that can be externalized
are externalized. That helps avoiding rebuilding libraries → less disk
space in case two ports share the same dep.

On Mon, Jan 11, 2021 at 6:51 PM Christopher Nielsen <
masc...@rochester.rr.com> wrote:

> There’s an open ticket for OpenMPI, related to opportunistic use of
> libevent:
>
> https://trac.macports.org/ticket/59626
>
> It turns out that, as of OpenMPI v4.0, the cmake scripts now prefer the
> use of an external libevent, when available. Which means we end up with
> inconsistent behavior, depending on whether the user already has libevent
> installed.
>
> This obviously needs to be fixed. The question is, do we want OpenMPI to
> build and use its own private libevent, or add a formal dependency on ours?
>
> The developer docs don’t provide a strong recommendation either way:
>
>
> https://www.open-mpi.org/faq/?category=building#libevent-or-hwloc-errors-when-linking-fortran
>
> Given that the internal version was always built and used prior to v4.0,
> using that one might be a good choice. But I don’t have an opinion.
>
> So I was hoping that you folks can help me make this call. Thoughts?



-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜   |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is

uboot-tools MR

[Ruben Di Battista]

Hello,
this MR https://github.com/macports/macports-ports/pull/7996 has been
existing for a while now. Is there someone with a bit of free time to
merge it? Thanks in advance and happy new year!

-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜   |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is

Re: [MacPorts] #60381: vtk @8.2.0_0 +python38 +qt5 +openmpi: failure to build

[Ruben Di Battista]

Yeah, I probably forgot to put the ticket link in order to close it after
applying the patch.

If I remember correctly, it was building with Python 3.7. Probably the
patch is needed with 3.8+.

On Fri, 25 Dec 2020, 03:31 MacPorts,  wrote:

> #60381: vtk @8.2.0_0 +python38 +qt5 +openmpi: failure to build
> -+--
>   Reporter:  majoc-at-astro  |  Owner:  stromnov
>   Type:  defect  | Status:  assigned
>   Priority:  Normal  |  Milestone:
>  Component:  ports   |Version:  2.6.2
> Resolution:  |   Keywords:
>   Port:  vtk |
> -+--
>
> Comment (by mascguy):
>
>  After looking at the `vtk` portfile, it looks like the patch is already in
>  place for Python 3.8.
>
>  I'll test building against Python 3.9 with the patch, along with Python
>  3.7 without (to see if needed there too).
>
> --
> Ticket URL: 
> MacPorts 
> Ports system for macOS
>

Review PR?

[Ruben Di Battista]

 Hello,  Can any of you please review this: https://github.com/macports/macports-ports/pull/8836 and merge it? The VTK port’s been broken for a while. I think it might be worth it to land this for the new port and wait for possible tickets on `vtk5` if someone gets the same problem. Thanks, 

Re: Time to remove Travis support?

[Ruben Di Battista]

As an alternative strategy I wanted to try to configure a Gitlab
Runner with libvirt. Is it something you might be interested in?

On Mon, Nov 2, 2020 at 8:14 PM Mojca Miklavec  wrote:
>
> Hi,
>
> If I understand correctly, we'll soon be unable to run any builds on
> Travis unless we pay for it (they are gradually moving existing
> customers to the new billing plan, so it's just a matter of time):
> https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
>
> We cannot say that this wasn't expected, so maybe it's time to put the
> last nail in that coffin? I don't know if we can expand the OS version
> list in any of the other services (GitHub Actions or Azure), but it's
> ok even if we don't.
>
> Mojca



-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜   |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is

Re: Thanks for the poppler / gobject-introspection fixes

[Ruben Di Battista]



On Thu, 29 Oct 2020, 05:22 Joshua Root,  wrote:

> Thanks so much Michael for fixing the gobject-introspection bugs that
> were preventing poppler from building while an older version of itself
> was installed. That has been the cause of a lot of grief for a long time.
>
> - Josh
>

Re: the state of osxfuse

[Ruben Di Battista]

Hi Dan,

there's another discussion in the mailing list discussing how Macports
should handle this kind of binary-only
(https://www.mail-archive.com/macports-dev@lists.macports.org/msg07704.html).

The consensus seem to provide it as binary-only, if I'm not mistaken.

On Tue, Oct 13, 2020 at 12:33 AM Dan Ports  wrote:
>
> Hi everyone,
>
> The osxfuse ports and its dependents are in a pretty sad state right
> now. I don't know what to do with them -- and I don't have the time to
> fix it anyway (I've dropped maintainership). But I thought I'd post
> about it here in hopes that someone else can take it up.
>
> There are three serious problems:
>  1) the port's version is outdated and doesn't build on that latest
> macOS
>  2) the upstream developer has taken the project closed-source, so
> later versions aren't available except in binary format
>  3) building a working kernel module is increasingly hard given
> code-signing and notarization requirement.
>
> The answer to these presumably involves building a new portfile to
> install the binary package rather than building from source - given
> (3), we have already been doing this with the kernel module for a
> while.
>
> Dan
>
> --
> Dan R. K. Ports  https://drkp.net/



-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜   |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is

Re: Supporting installing arbitrary port versions

[Ruben Di Battista]

On Sun, Oct 4, 2020 at 9:15 PM Ryan Schmidt  wrote:
>
>
>
> 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 wouldn't it be maybe easier to write a TCL
> > Lexer/Parser that allows to translate the TCL files to input files for
> > the other package managers and then tweak the `port` command to use
> > those package managers under the hoods? I'm a bit closer to spack
> > development, and they developed a concretizer
> > (https://archive.fosdem.org/2020/schedule/event/dependency_solving_not_just_sat/)
> > for the spec of the packages that took multiple years of work to be
> > finalized.
>
> So now you want MacPorts to become a wrapper around another system? That 
> would be another colossal task, I don't know what the benefit of it would be, 
> and it doesn't get us any closer to solving the previous colossal tasks I 
> mentioned that stand in the way of being able to offer arbitrary versions and 
> variants of all ports simultaneously, if that were something we wanted.
>
>
> > Personally I don't like the idea of shipping all package versions,
> > because there are already pieces of software developed for the same
> > reason and that, possibly, will do a better job than whatever Macports
> > will ever be able to do.
>
> ...then why are you suggesting the above?

I was just suggesting it since that was the discussion flow. Then, I
expressed my own 2¢ opinion. :)

>
> > For me the Macports scope must be kept
> > focused and small: installing (possibly latest versions of)
> > open-source stacks from source keeping compatibility with old systems
> > in the best way possible. There are already improvements that can be
> > done  UX-wise keeping this same scope: two that come to (my) mind are:
> > - Using another DSL/Language for Portfile that is easier, more
> > flexible, and modern (e.g. Python)
>
> https://trac.macports.org/wiki/FAQ#whytcl explains why Tcl was chosen.

I read these. I understand the choices made at that time, but I think
~20 years later maybe they will be less applicable. For example, maybe
one of the aspects to take into account would be "newcomer
contributors friendliness", since I don't think most of the people
that want to contribute to Macports are proficient in TCL. I did not
run numbers, so I might be wrong. It's more likely they would be in
Python (just to say one), or Node.js, or whatever.


> For example, one benefit is the avoidance of a preponderance of symbols 
> needed for basic tasks.
>
> In its most pure form, a portfile sets variables to values. In Tcl with the 
> way that MacPorts has enhanced it, that can be accomplished in the simplest 
> possible way:
>
> name zlib
>
> sets the variable "name" to the string "zlib". Can you do it that concisely 
> in Python? Don't you instead have to write:
>
> name='zlib'
>
> Isn't that going to get old really quickly when you have to set a dozen or 
> more variables in each portfile?

Well, it's three character strings difference. But I find this
(https://github.com/spack/spack/blob/977117b502589886fb5833340ab6cf1c15b3b26e/var/spack/repos/builtin/packages/paraview/package.py#L139):

```
if version < Version('5.1.0'):
[...]
```

way more readable than this
(https://github.com/macports/macports-ports/blob/d2acce23fbd523073731b27505a879385674f290/php/php-swoole/Portfile#L16)

```
if {[vercmp ${php.branch} 7.1] >= 0} {
[...]
}
```


Or also proper, expressive, readable OOP. Like:

```
class Paraview(CMakePackage, CudaPackage):
"""ParaView is an open-source, multi-platform data analysis and
visualization application."""`


compared to the TCL version (that I don't even know if it would be
supported by Macports or not).

Or also a proper interactive debugger that could allow to step in
directly in the code and check the package manager status in that
right moment and speed up debugging instead of printing out things
around or reading the log after stopping the build in a specific
phase.


> Tcl is already as easy and flexible as anything, isn't it? What could you do 
> in another language, that you would want to do in a portfile, that you can't 
> do in Tcl?

Well, you can do lots of stuff also in x86_64 assembly too, probably
more than TCL, that does not mean it's an especially good fit for this
particular job or that it might exists better solutions w.r.t. certain
aspects today than TCL.

>
> > - Installing binary-only software.
>
> MacPorts already suppor

Re: Supporting installing arbitrary port versions

[Ruben Di Battista]

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 wouldn't it be maybe easier to write a TCL
Lexer/Parser that allows to translate the TCL files to input files for
the other package managers and then tweak the `port` command to use
those package managers under the hoods? I'm a bit closer to spack
development, and they developed a concretizer
(https://archive.fosdem.org/2020/schedule/event/dependency_solving_not_just_sat/)
for the spec of the packages that took multiple years of work to be
finalized.

Personally I don't like the idea of shipping all package versions,
because there are already pieces of software developed for the same
reason and that, possibly, will do a better job than whatever Macports
will ever be able to do. For me the Macports scope must be kept
focused and small: installing (possibly latest versions of)
open-source stacks from source keeping compatibility with old systems
in the best way possible. There are already improvements that can be
done  UX-wise keeping this same scope: two that come to (my) mind are:
- Using another DSL/Language for Portfile that is easier, more
flexible, and modern (e.g. Python)
- Installing binary-only software.

just my 2¢

On Sun, Oct 4, 2020 at 7:58 AM Joshua Root  wrote:
>
> On 2020-10-4 16:36 , Ryan Schmidt wrote:
> > 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 PortSystem? i.e. PortSystem 1.3, 1.4, 
> >> 2.0, etc. Similar to how the HTML standard specification's version number 
> >> has changed over time, from HTML 2 all the way to the current HTML 5.
> >
> > Yes, we could do that starting now, but since we haven't up to now, the 
> > problem exists. The portsystem version concept was part of the original 
> > MacPorts design, predating the involvement of everyone here, so we would 
> > have to figure out how it works, whether it was ever fully implemented, 
> > what the implications would be of increasing the version, etc.
>
> It is implemented to the extent that "PortSystem $version" is a proc
> call that runs "package require port $version". Keeping support for old
> Portfiles would require keeping around old versions of the port package
> and the other packages it requires, with the old code that the old
> Portfiles rely upon (including problematic code; this would need to be
> "bug for bug" compatibility.)
>
> Linux distros don't support building their old packages from source in
> arbitrary newer environments, they just let you install the package.
> Given compatible versions of all the dependencies, that usually works,
> because they are an entire OS and so they're targeting the Linux kernel
> ABI which is quite stable.
>
> - Josh



-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜   |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is

Re: Apple ARM binary codesign issue

[Ruben Di Battista]

Ok, that's what I didn't know. I thought It was mandatory for Apple Store
software and not everything... 

On Thu, 24 Sep 2020, 13:35 Ryan Schmidt,  wrote:

> 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: Apple ARM binary codesign issue

[Ruben Di Battista]

Can't be an easier choice to push globally  a linker switch, if it exists,
to disable codesigning altogether for MP software?

On Wed, 23 Sep 2020, 03:09 Saagar Jha,  wrote:

> As far as I understand, ad-hoc codesigning is not actually really meant to
> protect a file on disk because you can just ad-hoc sign again when you
> modify the file; instead it simplifies some of Apple’s own code because it
> removes the special case of a binary that doesn’t have a signature (which
> until now has had a number of quirks and extra checks throughout the
> operating system). A more cynical interpretation would be that Apple would
> like to flip the switch to “paid developer account-signed software only” at
> some point in the future, but every engineer has denied that this is the
> goal when asked so I guess that if this will happen it hopefully won’t be
> anytime soon.
>
> I am still unsure why ld adds a signature but strip and install_name_tool
> don’t reapply an ad-hoc signature to a signed binary that they modify. This
> might be worth filing a feedback for.
>
> > On Sep 22, 2020, at 15:24, Ken Cunningham <
> ken.cunningham.web...@gmail.com> 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 now add code to their build systems to codesign things on macOS.
> Apple made a point of stating during WWDC that they love open source
> software; imposing busy work on the open source community is not a good way
> to show that love.
> >
> > As I read it, the linker automatically codesigns the binary when you
> link, which is usually the final step in the process. So nobody has to
> change anything there.
> >
> > But if you later modify that final linked binary by stripping it (I
> guess ) or changing the libraries around with install_name_tool (which I
> believe MESON does to every single install :>)  then you invalidate the
> signature, as you should IMHO.
> >
> > I'm trying to imagine how Jeremy might prevent hackers from
> surreptitiously modifying signed binaries with strip or install_name_tool
> (which is good) while letting people modify signed binaries with strip or
> install_name_tool without invalidating the signature  -- I don't
> immediately see how you can have it both ways. But maybe Jeremy has some
> trick that works for this I can't think of.
> >
> > I won't be surprised if the solution is that you have to resign them
> after doing that, though.
> >
> > Ken
> >
>
>

Re: [MacPorts] #61203: gtk3 @3.24.23_0: Can't update because of broken llvm

[Ruben Di Battista]

Can't the dependency on cctools be conditionally imposed?

On Sun, 20 Sep 2020, 07:38 MacPorts,  wrote:

> #61203: gtk3 @3.24.23_0: Can't update because of broken llvm
> --+
>   Reporter:  rubendibattista  |  Owner:  (none)
>   Type:  defect   | Status:  closed
>   Priority:  Normal   |  Milestone:
>  Component:  ports|Version:
> Resolution:  wontfix  |   Keywords:
>   Port:  gtk3 |
> --+
> Changes (by ryandesign):
>
>  * keywords:  gtk3, llvm, build =>
>  * status:  new => closed
>  * resolution:   => wontfix
>
>
> Comment:
>
>  Such problems exist from time to time, but I can't suggest a good way that
>  we could prevent it.
>
>  We offer newer versions of Apple's toolchain in the cctools port. If you
>  have it installed, many ports will opportunistically use the programs it
>  provides. If they're broken in some way, for example because one of their
>  dependencies like libffi was updated and you haven't updated cctools yet,
>  then that will cause those many other ports to fail to build. We do not
>  want to "fix" it by adding a cctools dependency to those many ports,
>  because that would normally be unnecessary; those ports would build fine
>  with Xcode's copy of those tools.
>
>  So when you encounter these kinds of problems you have to do a little
>  investigation and fix it yourself. For example, when you see:
>  {{{
>  dyld: Library not loaded: /opt/local/lib/libffi.6.dylib
>Referenced from: /opt/local/libexec/llvm-8.0/lib/libLLVM.dylib
>Reason: image not found
>  }}}
>  use `port provides /opt/local/libexec/llvm-8.0/lib/libLLVM.dylib` to
>  figure out what port provides it, check if it's outdated, and if so,
>  upgrade it. Then try again.
>
> --
> Ticket URL: 
> MacPorts 
> Ports system for macOS
>

Re: Travis CI timeouts for MacPorts builds

[Ruben Di Battista]

I was wondering... Would à Linux machine with some virtualization method
(libvirt?) be acceptable as CI runner? Any of you has experience in terms
of performance?

Also, Gitlab CI allows to attach personal runners to project very easily
(just a package to install from the os package manager) . How does it work
for Github?

On Mon, 7 Sep 2020, 15: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 wander what I can do to increase my
> > chances?
>
> By far the best thing would be to implement the functionality that
> would allow firing up a clean VM, do the build, close the VM & destroy
> it, and run this on our own buildbot workers.
>
> This requires both manpower to implement the functionality as well as
> additional hardware resources to run the builds.
> If we solve the first part, I guess we should be able to solve the
> second one as well.
> If you volunteer to do some research / work in this area ... that
> would likely be the most significant step in "increasing your chances"
> ... probably up to 100% for the ports that have no chance in building
> in < 50 minutes on a super slow hardware owned by Travis :)
>
> Mojca
>

Re: promote older systems support

[Ruben Di Battista]

+1

On Sun, 6 Sep 2020, 22:41 Ken Cunningham, 
wrote:

> there is considerable grousing on the homebrew forums about their ruthless
> policy for dropping support for systems more or less right after apple
> does, and some of those forum posts about this topic have many thousands of
> views.
>
> as you folks have put such effort into older systems support over the
> years, it might not be a waste of time to mention that support on the
> MacPorts main page .
>
> It is a primary differentiating feature.
>
> Ken
>

Re: port "cask" -- installing prebuilt binaries

[Ruben Di Battista]

I mean, you can maybe describe the “feature set” of the prebuilt binary in
the variant description and forbid all the other variants… Can’t you?

PS: Maybe “prebuilt_binary” is not the right wording since most of the
ports can already be installed as “prebuilt_binary”. Maybe it should be
something like “bin_only” ?

PPS: As I already said, ports that are open source should be fixed at least
on the buildbot  machines in order to be able to build them from sources
(as the upstream developer did) allowing few, highly selected, exceptions
(as the java stuff that was already mentioned).

  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’
https://rdb.is


On 15 August 2020 at 01:11:23, Ken Cunningham (
ken.cunningham.web...@gmail.com) wrote:

consider:

$ port variants macvim
Warning: port definitions are more than two weeks old, consider updating
them by running 'port selfupdate'.
MacVim has the variants:
   big: Build big feature set
 * conflicts with huge
   cscope: Enable source code browsing with cscope
[+]huge: Build huge feature set
 * conflicts with big
   lua: Enable Lua scripting
   perl: Enable Perl scripting
   python27: Enable Python scripting
   python36: Enable Python scripting
 * conflicts with python37
   python37: Enable Python scripting
 * conflicts with python36
   ruby: Compatibility variant, requires +ruby18
 * requires ruby18
   ruby18: Enable Ruby scripting
 * conflicts with ruby19 ruby20 ruby21 ruby22 ruby23 ruby24 ruby25
   ruby19: Enable Ruby scripting
 * conflicts with ruby18 ruby20 ruby21 ruby22 ruby23 ruby24 ruby25
   ruby20: Enable Ruby scripting
 * conflicts with ruby18 ruby19 ruby21 ruby22 ruby23 ruby24 ruby25
   ruby21: Enable Ruby scripting
 * conflicts with ruby18 ruby19 ruby20 ruby22 ruby23 ruby24 ruby25
   ruby22: Enable Ruby scripting
 * conflicts with ruby18 ruby19 ruby20 ruby21 ruby23 ruby24 ruby25
   ruby23: Enable Ruby scripting
 * conflicts with ruby18 ruby19 ruby20 ruby21 ruby22 ruby24 ruby25
   ruby24: Enable Ruby scripting
 * conflicts with ruby18 ruby19 ruby20 ruby21 ruby22 ruby23 ruby25
   ruby25: Enable Ruby scripting
 * conflicts with ruby18 ruby19 ruby20 ruby21 ruby22 ruby23 ruby24
   tcl: Enable Tcl scripting
   xim: Build with support for X Input Method



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. Variants for this are not
workable.  So let's move on to a plan that might actually work. Or not.
I think, as has been stated, that the whole idea is possibly too flawed
to be considered.


K

Re: port "cask" -- installing prebuilt binaries

[Ruben Di Battista]

I also believe we should apply this strategy to "binary only" non-open
source software.

I have a question tho, probably addressed mostly to @Ken and those that
manage the ports builds on old systems, in facts, about hybrid ports (as
defined by @Herby: open source software that we are unable to build on some
systems and then we ship it as binary only).

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 hard is to fix the build environment on old systems...


On Fri, 7 Aug 2020, 03:56 Herby G,  wrote:

> I certainly see your points. Here are my thoughts:
>
> On the subject of binary-only ports, you'll have two kinds:
>
>- binary ports that are *entirely* binary _only_, and were *never*
>source-built, no matter the platforms or macOS version (like Zoom for
>example)
>- "hybrid" ports that are source-compiled under certain conditions,
>and fetching a binary in other cases
>
> The first thing to consider is what's the ratio of pure-binary to "hybrid"
> binary ports? I feel like "hybrid" ones would be in the minority.
> Homebrew's "casks" are mostly pure binary-only.
>
> One thing that can be done to simplify things is have the condition that
> only "purely" binary ports can be in the "binary" category (for
> simplicity's sake).
>
> Hybrid ports are going to be a hassle no matter what, and that would be
> true for any port that has conditional logic that changes the port's
> behavior depending on macOS version and other factors (besides
> architecture).
>
> When someone is filing a ticket, we'd want to know their macOS version +
> environmental details anyway, and that tells you what you need to know as a
> maintainer to troubleshoot a hybrid port that you are maintaining.
>
> Now the headaches you illustrate have a lot to do with how a hybrid port
> would be implemented.
>
> Two ways that immediately come to mind are:
>
>- sub-ports: your main port installs a source-built or binary-only
>sub-port depending on macOS version
>- same port but using conditional logic internally
>
> In the first case, each sub-port would have to have a different name, so
> that's that.
> In the case of the second, yes, that can lead to the scenario you
> illustrated, but as I mentioned above, once we know the user's environment,
> we can know what's installed.
>
> I am not against having different names for a binary-only vs source-built
> version of a port.  But that only matters in the case where the same piece
> of software is source-based in one place and binary-only elsewhere.
>
> I think using a category to mark binary-only ports is far more optimal
> than packing that meaning into the port's name, especially when ports can
> choose almost any name they want.
>
> Additionally, as I've mentioned previously, it's much easier for tooling
> like the MacPorts website, the port command and more to tell based off a
> category than a list of blessed regexes for determining whether a port
> _might be_ binary only (as it's possible some other port may have "binary"
> in its name even though it may not be).
>
>
> On Thu, Aug 6, 2020 at 7:13 PM Ken Cunningham <
> ken.cunningham.web...@gmail.com> wrote:
>
>>
>>
>> > On Aug 6, 2020, at 2:34 PM, Herby G  wrote:
>> >
>> > > If we decide to go ahead with this, and if we decide to primarily use
>> a category to mark these, we will need a plan for how to manage a name
>> collision conflict when there are two ports that install the same software,
>> one by building from source (on newer systems) and one by installing a
>> binary (on older systems).
>>
>> > This does not introduce any new mechanism or concept that does not
>> already currently exist in MacPorts.
>> >
>>
>> yes it does. An example: let’s take the port MacVIM, which is ripe for
>> this treatment.
>>
>> We can build and install the current macvim on some newer systems - let’s
>> say 10.12 to current.
>>
>> port -v install macvim gets you that.
>>
>> We will all know what that port represents, without trouble, if there is
>> a ticket.
>>
>> Now say on 10.7 to 10.11, we want to install a binary version of macvim.
>> macvim won't build on those systems, but there is a binary that works.
>>
>> We need a clear, identifiable port name to install the macvim binary. It
>> should not be called macvim, that is just a *crazy* recipe for trouble.
>> You’d never be able to keep up with what was what. We need the port to
>> clearly be recognizable as the macvim binary.
>>
>> We need a new name. No trickery with categories is acceptable here.
>>
>> The “macvim” port might (or might not) point a user to the macvim_binary
>> port if needed, but it can’t be the same port with the same name, and it
>> most definitely should not install the binary instead. If we go down that
>> road, we’ll never know what is going on, and this whole idea 

Re: port "cask" -- installing prebuilt binaries

[Ruben Di Battista]

Ehi, sorry I was not clear enough. Sometimes I’m very bad at expressing
what I have in mind, I’m sorry.

Hmm, I hadn't heard about that, but I don't run 10.14+ other than for
testing.

https://github.com/osxfuse/osxfuse/issues/590

Huh? Are you suggesting *disallowing* the use of precompiled binaries?
That would be crazy.

No, no. What I meant was to limit “cask behavior”, that for what I
understand is “binary-only” distribution, to only the ports that really
really are needed (like, for my use case, osxfuse).

The current approach seems reasonable and philosophically closer to the
FOSS movement (i.e. shipping default variants distributable ports as
binaries…). Maybe expanding the matrix of builds to more variants would be
also cool, but I imagine that this would require an insane amount of space
on the servers...

  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’
https://rdb.is


On 4 August 2020 at 22:35:47, Fred Wright (f...@fwright.net) wrote:


On Wed, 29 Jul 2020, Daniel J. Luke wrote:
> On Jul 29, 2020, at 9:30 PM, Fred Wright  wrote:
[...]
>> Personally, I'd prefer the MacPorts approach if it were less stingy
>> with the binary archives. Ideally, one should be *able* to build from
>> source, but not be *required* to do so.
>
> How is it stingy? We have binary archives for everything that the
> buildbots can build that the licenses allow us to distribute, right?

Aside from the usual issues with non-default variants and certain old OS
versions, the main problem seems to be what appears to be an overly strict
interpretation of "distributable".

As a random example, consider ffmpeg. The license for ffmpeg shows as
GPL-2+. Although GPL prohibits binary-only distributions at the "meta
level", it does *not* demand that sources be bundled with the binaries.
It simply says that if they're not, there has to be clear information
available to the user on how to obtain the sources. It doesn't even
demand a working build procedure, just the sources. It might get a bit
fuzzy in cases where the sources are patched, in which case it's not 100%
clear that providing the original source plus the patches is adequate, or
whether it's necessary to provide the actual patched sources (though the
two are certainly morally equivalent), but in any case, MacPorts clearly
does both. Anyone can get the upstream source archive(s) via "port
fetch", get the sources in tree form via "port extract", and get the
patched sources via "port patch". I don't see how this fails to meet the
GPL requirements for any MacPorts user.

Now if one were to be really paranoid, one might consider that providing
binaries on servers that are accessible by means other than MacPorts could
constitute a GPL violation, due to not having the "clear path to sources"
that MacPorts provides. But if that's a concern, it could be easily
addressed by including a README.sources file in every directory on the
archive servers, either pointing to the corresponding source on a distfile
mirror (or directly upstream if necessary), or perhaps just pointing to
the MacPorts homepage.

And to pick a random sub-example, Debian offers ffmpeg as a binary
package.

> port, by default, will use the binary archives unless you tell it to
> build from source instead.

BTW, on an only mildly related note, I've seen a number of cases lately
where it successfully fetches a binary archive and than fails to fetch the
corresponding checksum file. It seems that it gets only one chance to do
this, and only from the same mirror where it fetched the archive. It's
become common for me to need a "cleanup pass" after doing "upgrade
outdated" across my VMs, where I manually retry the failed upgrades.

On Tue, 4 Aug 2020, Ruben Di Battista wrote:

> There's is one compelling need for having "binary only" install, and that
> is for the port "osxfuse", that is currently broken for 10.14+.
>
> There was a discussion about it on the Github project about the choice of
> making it close closed source... Nonetheless it would be useful to have
it
> in order to provide things like fuse file systems and so on.

Hmm, I hadn't heard about that, but I don't run 10.14+ other than for
testing.

I was involved in fixing some osxfuse bugs right around the time that
10.10 came out, making kext signature checking mandatory. On 10.9, it
warns you about an unsigned kext, but you can tell it to proceed. The fix
at the time (for the relevant OS versions) was to have MacPorts fetch the
binary distribution and extract the signed prebuilt kext from it, while
building the rest from sources. This is done starting with 10.9, to avoid
the dialog box, even though it's not strictly necessary until 10.10+.

It sounds like some more tightening of the security noose has caused
additional problems for o

Re: port "cask" -- installing prebuilt binaries

[Ruben Di Battista]

So my take here is to not provide pre-built binaries packages if not
strictly unavoidable, like for the osxfuse project (since it was open
source before).

One of the reasons I chose Macports for is the fact it builds its own tree
from source and it ships basically open source only software.

Otherwise there would be no difference with homebrew and it would make
little sense to prefer Macports UX, that is arguably worse than Homebrew's
IMHO (especially Ruby DSL formula vs TCL Portfile).

On Tue, 4 Aug 2020, 19:47 Ruben Di Battista, 
wrote:

> There's is one compelling need for having "binary only" install, and that
> is for the port "osxfuse", that is currently broken for 10.14+.
>
> There was a discussion about it on the Github project about the choice of
> making it close closed source... Nonetheless it would be useful to have it
> in order to provide things like fuse file systems and so on.
>
>
>
> On Tue, 4 Aug 2020, 15:38 Lothar Haeger,  wrote:
>
>>
>>
>> Am 30.07.2020 um 08:03 schrieb Ken Cunningham <
>> ken.cunningham.web...@gmail.com>:
>>
>> I only raise the idea as people are already doing this, and submitting such 
>> ports, and before we have too many, there is an opportunity to say how it 
>> should best be done (custom category, naming convention, etc).
>>
>> Reminds me of an earlier conversation at
>> https://github.com/macports/macports-ports/pull/6767#discussion_r402584006
>>
>>
>> I do see some benefits is formalizing binary-only ports and to adapt the
>> build and distribution scheme for it. Could save resources and development
>> time and make those ports easily recognizable for those who care about the
>> different way it was built.
>>
>>
>>

Re: port "cask" -- installing prebuilt binaries

[Ruben Di Battista]

There's is one compelling need for having "binary only" install, and that
is for the port "osxfuse", that is currently broken for 10.14+.

There was a discussion about it on the Github project about the choice of
making it close closed source... Nonetheless it would be useful to have it
in order to provide things like fuse file systems and so on.



On Tue, 4 Aug 2020, 15:38 Lothar Haeger,  wrote:

>
>
> Am 30.07.2020 um 08:03 schrieb Ken Cunningham <
> ken.cunningham.web...@gmail.com>:
>
> I only raise the idea as people are already doing this, and submitting such 
> ports, and before we have too many, there is an opportunity to say how it 
> should best be done (custom category, naming convention, etc).
>
> Reminds me of an earlier conversation at
> https://github.com/macports/macports-ports/pull/6767#discussion_r402584006
>
>
> I do see some benefits is formalizing binary-only ports and to adapt the
> build and distribution scheme for it. Could save resources and development
> time and make those ports easily recognizable for those who care about the
> different way it was built.
>
>
>

Re: Unable to authorize MacPorts Trac for GitHub auth

[Ruben Di Battista]

Maybe as a first trial, try to delete the browser cookies?

On Fri, Jul 24, 2020 at 6:53 PM Jason Liu  wrote:
>
> Hi all,
>
> I'd like to create a new Trac ticket (my first one), and when I want to log 
> in, I'm getting redirected to a GitHub page asking me to Authorize MacPorts 
> Trac. However, on this page, the "Authorize macports" button is greyed out. 
> I'm already logged into my GitHub account, at least according to my other 
> browser window. Has anyone else encountered this?
>
> --
> Jason Liu



-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜   |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is

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

[Ruben Di Battista]

Ping! :)

On Thu, Jul 2, 2020 at 8:34 PM Ruben Di Battista
 wrote:
>
> https://github.com/macports/macports-ports/pull/6924
>
>   _
> -. .´  |
>   ',  ;|∞∞
> ˜˜ |∞ RdB
> ,.,|∞∞
>   .'   '.  |
> -'   `’
>
> https://rdb.is



-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜   |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is

Re: MacPorts webapp project updates

[Ruben Di Battista]

Ok, I just checked. That’s exactly what I needed. Good job and sorry again!

  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’
https://rdb.is


On 20 July 2020 at 15:20:33, Ruben Di Battista (rubendibatti...@gmail.com)
wrote:

Ok, probably my bad. I lazily looked for this functionality and I did not
see it. At the moment the page looks down, but as soon as it comes back
I’ll check back the link you provided me to see if it’s what I needed.

Sorry if I asked something that was already in place.

  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’
https://rdb.is


On 20 July 2020 at 15:06:21, Arjun Salyan (ar...@macports.org) wrote:

Hello,

On Mon, Jul 20, 2020 at 6:10 PM Ruben Di Battista 
wrote:

> Hello,
>
> That’s a nice job! Thanks!
>
> I have just one request, if possible: on the home page, would it be
> possible to add another search bar to search which package contains a
> specific file? More or less like the ubuntu packages webpage. Sometimes I
> find it useful when writing CI scripts not on my macOS.
>

We do have the ability to search for ports that install a particular file
http://macports.silentfox.tech/search/ . Or do you specifically suggest
adding this to the homepage?

Thank You

>

Re: MacPorts webapp project updates

[Ruben Di Battista]

Ok, probably my bad. I lazily looked for this functionality and I did not
see it. At the moment the page looks down, but as soon as it comes back
I’ll check back the link you provided me to see if it’s what I needed.

Sorry if I asked something that was already in place.

  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’
https://rdb.is


On 20 July 2020 at 15:06:21, Arjun Salyan (ar...@macports.org) wrote:

Hello,

On Mon, Jul 20, 2020 at 6:10 PM Ruben Di Battista 
wrote:

> Hello,
>
> That’s a nice job! Thanks!
>
> I have just one request, if possible: on the home page, would it be
> possible to add another search bar to search which package contains a
> specific file? More or less like the ubuntu packages webpage. Sometimes I
> find it useful when writing CI scripts not on my macOS.
>

We do have the ability to search for ports that install a particular file
http://macports.silentfox.tech/search/ . Or do you specifically suggest
adding this to the homepage?

Thank You

>

Re: MacPorts webapp project updates

[Ruben Di Battista]

Hello,

That’s a nice job! Thanks!

I have just one request, if possible: on the home page, would it be
possible to add another search bar to search which package contains a
specific file? More or less like the ubuntu packages webpage. Sometimes I
find it useful when writing CI scripts not on my macOS.

Thanks in advance,

  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’
https://rdb.is


On 18 July 2020 at 20:20:26, Mojca Miklavec (mo...@macports.org) wrote:

Hi,

This is just a reminder that we would be extremely happy for further
feedback about the new page.

Arjun has added some pretty awesome new features. (Dark mode has been
supported since yesterday etc.)

It would be great to hear what you think while Arjun is still actively
working on the project :)

Mojca

PS: Also, we are still looking for some talented designer to join the
effort and make the page even more awesome than it already is.

On Sun, 12 Jul 2020 at 20:56, 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/
>
> *New features:*
>
> *Accounts:*
> Users can now create accounts on the webapp using email/password or login
> with their GitHub handles.
>
> *Watchlist and notifications:*
> Logged-in users can add ports to the watchlist. Notifications are
> displayed whenever a port gets updated. An overview of the followed ports
> is displayed with filters for "broken builds", "outdated livecheck" etc.
>
> *"Followed by me" ports*
> Logged-in users can get an overview of the ports that they maintain (this
> is done by matching their emails and GitHub handles with those supplied in
> the Portfiles).
>
> *"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 be useful for the general user. This reduces
> the odds of user acquisition. So, we plan to add a page with a focus on the
> software version and installation instructions. It will have a link to the
> existing page under "Details". Maintainers and advanced users will be able
> to by-pass this page (setting a cookie with the preferred page) and reach
> the details page directly. Existing links will be maintained in this
> process.
>
> Feedback and suggestions would be very constructive.
>
> Thank You
>
>

Could someone please give a look to this PR?

[Ruben Di Battista]

https://github.com/macports/macports-ports/pull/6924

  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’
https://rdb.is

Re: [MacPorts] #60590: Macports mirrors are down?

[Ruben Di Battista]

I'm probably saying something completely wrong, but can't you leverage the
CI system and buildbots to create a Github release that includes the
PortIndex and whatsoever and then download it from Github servers via http?
What am I missing here?



On Sat, 6 Jun 2020, 02:49 Clemens Lang,  wrote:

> Hi,
>
> On Fri, Jun 05, 2020 at 06:05:41PM -0500, Christopher Chavez wrote:
> > As a user, I've thought it would be great if MacPorts used git syncing
> > by default. I have used git-over-https since 2016 when I was
> > constrained to ports 80/443 by a university campus network. I had
> > found it also avoided needlessly writing hundreds of MB to the SSD
> > when updating the ports tree. If GitHub outages are a concern, then I
> > would think falling back to a mirror hosted by
> > GitLab/SourceForge/Bitbucket/etc. should be possible.
>
> The reason why we haven't done this is that you would no longer get a
> prebuilt PortIndex. You would have to generate the PortIndex locally,
> which costs CPU time and is noticeably slower than downloading a
> matching PortIndex from rsync.
>
> We might eventually figure out a way to provide prebuilt portindexes via
> http when syncing from Git, but that needs to be set up on the server
> side, implemented on the client side and thoroughly tested.
>
> --
> Clemens
>

Re: One large pull request vs. several small ones?

[Ruben Di Battista]

I think the best approach is to isolate “atomic” changes, and open a PR for 
each of them. This way problems with dependencies can be isolated and decoupled 
from those for Blender. 

If they are really too many, maybe try to provide PRs for semantically related 
libraries or somehow related in some other way (like, “python” dependencies). I 
would say a maximum of 3 - 4 ports per PR? 

I’ll leave the word to more expert members of the community, that’s my general 
approach when I need to merge upstream complex trees of ports...

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 12 May 2020 at 19:45:30, Jason Liu (jason...@umich.edu) wrote:

I would like to contribute a portfile for the newest version of Blender. I 
already have a local portfile that is compiling successfully, and I am doing 
some cleanup before submitting a pull request on GitHub. In addition to Blender 
itself, I have also packaged several of Blender's dependent libraries, which 
would also be new ports. My question is: Would it be better for me to submit 
all of the portfiles for Blender and the libraries in one single pull request? 
Or should I submit one pull request for each new package individually?

The reason why I ask is that the dependency tree is a bit complex, with some of 
the libraries dependent on other libraries which I packaged as well. And if I 
were to submit each of the libraries individually, there's no telling how long 
it would take to get each one of them accepted and merged before I would be 
able to submit the Blender portfile.

-- 
Jason Liu

signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: installing MacPorts 2.6.2 on Ubuntu Linux 20.04

[Ruben Di Battista]

Sure, sure, 

I just took your email as a stimulus to express what I had in mind about the 
project. Hope I did not bother any of you too much… :). It’s always cool to 
investigate something and I think it’s interesting to know that Macports, 
actually works on Linux! 

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 1 May 2020 at 04:55:14, Kenneth F. Cunningham 
(ken.cunningham.web...@gmail.com) wrote:

You could be correct.

For some years, Portfile authours have been asked to always account for the 
fact that MacPorts was designed to be cross-platform, and to take steps to make 
sure the Portfiles remain so.

That's all the "platform darwin" stuff in all the Portfiles and in base.

I was just curious if MacPorts actually did work on Linux, and -- it turns out 
-- it does, with minor surgery.

So we're not really "making" it cross-platform; it always has been. 

I was just more seeing if it truly worked.

K



On 2020-04-30, at 7:07 PM, Ruben Di Battista wrote:

Can I express a thought about this? :) I hope I won’t result too naive. 

I think the effort of making Macports cross-platform could be destined to 
something else. On Linux there's a wide plethora of package managers that 
fulfill basically all the needs Macports would fulfill. Just to take something 
as an example: 

* Pacman on Arch provides pre-compiled binaries plus the AUR repository of 
packages that can be compiled at will (variants are missing, tho)

* Nix, that I think it's probably the most "correct" package manager currently 
available over there. 

* Spack, something like Nix, but optimized for HPC (so cross-compiling, 
architecture optimization and so on).

but I'm surely missing other cool projects. 

IMHO Macports should focus exclusively on macOS. As a contributor to Spack, 
Macports (and EasyBuild in the past), I found the TCL based system very hard to 
grasp w.r.t. Python-class based packages. That's probably because I'm more 
proficient in Python, but I think it's undeniable that Python is an easier 
language to pick and gradually learn, and with could also argue on the fact 
that an Object-Oriented approach to package description is easier to maintain 
(I don't know, I find it easier than the scripts we use in Macports). 

IMHO Macports should focus into potentiating the major selling points it has, 
again I pick something I have in mind myself:
 
* Native build of libraries and its dependencies
* Compatibility with old macOS versions
* Vast Linux and Unix selection of packages

and improve some aspects that could be improved:

* Abandon (not abruptly…) TCL for a more modern language, possibly more 
mainstream, that could enlarge the audience of possible contributors for 
packages
* Is the core written in C? I even don't know, but if it is, is it needed for 
performance reasons?
* Improve compatibility and performances of "Linux-polarized" libraries (e.g. 
Inkscape and GTK stuff)
* Provide pre-compiled binaries also for variants to speedup installation for 
non-dev users
* Improve community engagement (e.g. switching mailing list to Discourse [it 
ships mailing list mode if you prefer to communicate this way, but it would 
improve indexing and searchability], IRC --> Matrix, and so on. Just 
suggesting...)

Is there a Roadmap for the development of Macports? Is there somewhere where I 
can see what was discussed and which direction Macports has been thought to 
take? I would really like to participate, also as a way to learn something from 
most of you that are way more skilled then me. I prefer Macports approach 
w.r.t. Homebrew, and I'd like that people would be able to evaluate more fairly 
the two solutions, maybe avoiding the difficult initial slope associated to TCL 
and C-Core.

Tell me what you think, and sorry if I'm being too naive on some points. I'm a 
fairly recent member and reader of the mailing list, I could have missed some 
important discussions.


  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 1 May 2020 at 03:37:28, Ken Cunningham (ken.cunningham.web...@gmail.com) 
wrote:

I thought I would start up a short thread on progress with this -- 
MacPorts on Linux. We've long written the Portfiles with this in mind. 
This was done on an Intel system, with the current Ubuntu 20.04. Ubuntu 
19.10 can be installed in a VM in parallels, and no doubt in other VM 
systems. 

Some quick notes: 

apt is the built-in package manager, similar to "port". 

"sudo apt install" is the same as "sudo port install". 

"apt info" is "port info" 

"apt-file show" does something similar to "port contents", but the 
software does not have to be installed. 


After downloading the MacPorts source tarball, and prior to build

Re: installing MacPorts 2.6.2 on Ubuntu Linux 20.04

[Ruben Di Battista]

Can I express a thought about this? :) I hope I won’t result too naive. 

I think the effort of making Macports cross-platform could be destined to 
something else. On Linux there's a wide plethora of package managers that 
fulfill basically all the needs Macports would fulfill. Just to take something 
as an example: 

* Pacman on Arch provides pre-compiled binaries plus the AUR repository of 
packages that can be compiled at will (variants are missing, tho)

* Nix, that I think it's probably the most "correct" package manager currently 
available over there. 

* Spack, something like Nix, but optimized for HPC (so cross-compiling, 
architecture optimization and so on).

but I'm surely missing other cool projects. 

IMHO Macports should focus exclusively on macOS. As a contributor to Spack, 
Macports (and EasyBuild in the past), I found the TCL based system very hard to 
grasp w.r.t. Python-class based packages. That's probably because I'm more 
proficient in Python, but I think it's undeniable that Python is an easier 
language to pick and gradually learn, and with could also argue on the fact 
that an Object-Oriented approach to package description is easier to maintain 
(I don't know, I find it easier than the scripts we use in Macports). 

IMHO Macports should focus into potentiating the major selling points it has, 
again I pick something I have in mind myself:
 
* Native build of libraries and its dependencies
* Compatibility with old macOS versions
* Vast Linux and Unix selection of packages

and improve some aspects that could be improved:

* Abandon (not abruptly…) TCL for a more modern language, possibly more 
mainstream, that could enlarge the audience of possible contributors for 
packages
* Is the core written in C? I even don't know, but if it is, is it needed for 
performance reasons?
* Improve compatibility and performances of "Linux-polarized" libraries (e.g. 
Inkscape and GTK stuff)
* Provide pre-compiled binaries also for variants to speedup installation for 
non-dev users
* Improve community engagement (e.g. switching mailing list to Discourse [it 
ships mailing list mode if you prefer to communicate this way, but it would 
improve indexing and searchability], IRC --> Matrix, and so on. Just 
suggesting...)

Is there a Roadmap for the development of Macports? Is there somewhere where I 
can see what was discussed and which direction Macports has been thought to 
take? I would really like to participate, also as a way to learn something from 
most of you that are way more skilled then me. I prefer Macports approach 
w.r.t. Homebrew, and I'd like that people would be able to evaluate more fairly 
the two solutions, maybe avoiding the difficult initial slope associated to TCL 
and C-Core.

Tell me what you think, and sorry if I'm being too naive on some points. I'm a 
fairly recent member and reader of the mailing list, I could have missed some 
important discussions.


  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 1 May 2020 at 03:37:28, Ken Cunningham (ken.cunningham.web...@gmail.com) 
wrote:

I thought I would start up a short thread on progress with this --  
MacPorts on Linux. We've long written the Portfiles with this in mind.  
This was done on an Intel system, with the current Ubuntu 20.04. Ubuntu  
19.10 can be installed in a VM in parallels, and no doubt in other VM  
systems.  

Some quick notes:  

apt is the built-in package manager, similar to "port".  

"sudo apt install" is the same as "sudo port install".  

"apt info" is "port info"  

"apt-file show" does something similar to "port contents", but the  
software does not have to be installed.  


After downloading the MacPorts source tarball, and prior to building  
MacPorts, you must install the supporting software that comes already on  
Macs that MacPorts expects to find.  

These were installed as:  

sudo apt install mtree-netbsd  
sudo apt install tcl8.6  
sudo apt install curl  
sudo apt install sqlite3  
sudo apt install gnustep  
sudo apt install libcurl4-gnutls-dev  
sudo apt install libsqlite3-dev  


my system already had llvm-10 and clang-10 installed, and there was  
already a symlink "port" linking /usr/bin/clang to the selected clang  
binary, in this case clang-10.  

Then build and install MacPorts as usual, into /opt/local  

./configure && make && sudo make install  


Add to your PATH as usual, but on Ubuntu, by editing ".bashrc", adding:  

export PATH=/opt/local/bin:/opt/local/sbin:$PATH  


Adding that PATH to the sudo command is harder -- it doesn't pick it up  
from the above ".bashrc". You have add it to the sudoers command with:  

sudo visudo  

and then add it to the secure_path  

Defaults  
secure_path="/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
  

There are some differences between Darwin and Ubuntu, and to work around  
some of 

Compiler blacklist propagation from a dependency to its dependents

[Ruben Di Battista]

I’m working on a version bump of vtk. Vtk depends on jsoncpp, which needs a 
compiler blacklist fix. Now, that compiler fix needs to be propagated also to 
vtk, since it’s including jsoncpp headers.

For what I understand, that is not done. So, I need to blacklist the same 
compiler also on vtk Portfile? Shouldn’t that blacklist get propagated 
downstream to all the dependents of jsoncpp, in this case? 



  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Different environment (apparently) calling make from python subprocess

[Ruben Di Battista]

I just discovered this anomaly: https://bugs.python.org/issue40261. TL, DR: if 
I run a `make` command from within a subprocess, the build of Python from 
source behaves differently and breaks.

Could any of you try the step to reproduce and see if he/she is getting the 
same weird behavior I’m getting? 

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: GSoC Proposal: Rewrite key parts of MacPorts in Python

[Ruben Di Battista]

I have no experience to gave you any valuable help on this Alex, just wanted to 
drop some ideas I have in mind. 

I work in the frame of HPC computing and I’m a heavy user of spack 
(https://spack.readthedocs.io/en/latest/). It’s a package manager tailored for 
HPC that shares more than few features and design approach with Macports.
 
- It compiles for Unixes on different architectures (Including Power) and on 
Mac.
- has lots of optimized packages for specific architectures 
- Isolated spack environments and filesystem views

I would argue is a bit less stable for daily use as we do with Macports, but I 
find the packages very pleasant to write and the community is vibrant. So I 
would like to tell you to consider, maybe, to base your eventual work on that. 
Maybe making Macports packages compatible with their API or also using their 
infrastructure and strip most of the HPC-related features replacing them with 
the few, unique, feature Macports provides. Maybe discussing with them on the 
best approach to use their work in order to avoid to reinvent the wheel could 
be beneficial. I think the approach would be probably based on their spack 
environments/view (https://spack.readthedocs.io/en/latest/environments.html).

One of the proposed issues over there is to turn the actual spack “binary” into 
a library that other projects can leverage. Could it be feasible way to 
integrate a mature ecosystem with Macports? Maybe other people from the 
community could give it a look and express their opinion on that. 

Good luck! 

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 31 March 2020 at 23:15:02, Alex Ionkov (aion...@gmail.com) wrote:

Dear MacPorts community, 

I submitted a proposal this year for rewriting parts of MacPorts in Python. The 
eventual goal is to rewrite all of MacPorts in Python to increase modularity 
and make integration of other APIs with MacPorts easier. 

I've attached my proposal. As for some edits that have already been recommended 
to me for more measurable goals, by each evaluation I would want to have 
rewritten an X amount of functions or functionality. 

What I would request from the community is advice on which functions would be 
the most valuable and useful and how to split them among the evaluation 
periods. Some recommendations that I have received already include getting 
information from the webapp to implement functionality that is not yet 
available and also rewriting functions such as fetch, dependency calculation, 
livecheck and install.

I'm currently working on integrating a small Python script which tells you the 
latest successful build of a port with the Tcl source as a proof of concept.

Thank you very much for your time,
Alex Ionkov

signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: How do I install a package with a specific extra_requires?

[Ruben Di Battista]

I just provide the dependency. Sorry I’m dumb.

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 13 February 2020 at 17:30:17, Ruben Di Battista (rubendibatti...@gmail.com) 
wrote:

Currently python packages are built using `python setup.py`. I need 
py-setuptools_scm[toml] as a dependency for `py-virtualenv` (I’m trying to 
update the port). How do I ask for a specific “extra_require” in a Portfile? 

  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

signature.asc
Description: Message signed with OpenPGP using AMPGpg

How do I install a package with a specific extra_requires?

[Ruben Di Battista]

Currently python packages are built using `python setup.py`. I need 
py-setuptools_scm[toml] as a dependency for `py-virtualenv` (I’m trying to 
update the port). How do I ask for a specific “extra_require” in a Portfile? 

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

signature.asc
Description: Message signed with OpenPGP using AMPGpg

Strange behaviour of subprocess_check_output with Macports Python in virtualenv

[Ruben Di Battista]

Hello, 
I’m experiencing a problem (https://github.com/davidhalter/jedi/issues/1375). 

Running this on a Python installed with Macports: 
```
Python 3.8.1 (default, Feb  8 2020, 01:33:23)
[Clang 11.0.0 (clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.check_output('/Users/rubendibattista/.envs/josiepy-B4k-0ZyT/bin/python
>>>  -c "import sys; print(sys.executable)"', shell=True)
b'/opt/local/bin/python\n'
```

I get as result the system python executable and not the one from the 
virtualenv (created using pew). 
While on Linux: 

```
Python 3.7.3 (default, Jun  7 2019, 17:57:55)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.check_output('/home/ruben.di-battista/.envs/josiepy/bin/python 
>>> -c "import sys; print(sys.executable)"', shell=True)
b'/home/ruben.di-battista/.envs/josiepy/bin/python\n'
```

Does it work for you? Is it a bug from Macports, from my particular 
configuration, from macOs or from Python build on macOs? (Or isn’t a bug?)
  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Is it possible to use cmake and python portgroup together?

[Ruben Di Battista]

I’m revamping the ports of PySide2 and FreeCad with all the dependencies, and 
I’d like to build Shiboken2 with cmake (in order to provide the config file), 
but still I need the creation of the various python ports etc… Can I use both? 
Or do I need to replicate the stub port management done in the python port 
group manually? 

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: gcc7/libgcc7 problems

[Ruben Di Battista]

Isn't something similar to what patchelf does possible on macOs? Editing
the RPATH?

On Sun, 15 Dec 2019, 19:06 Ken Cunningham, 
wrote:

> This issue is a classic c++ standard lib mixup, exactly what we have
> always feared and tried our best to avoid on MacPorts.
>
> Objects are being created using /usr/lib/libstdc++.dylib and then (in
> this case) attempt to be deleted by /opt/local/lib/libstdc++.dylib and
> they are not matching up, so errors are happening.
>
> We've discussed this exact situation for years, but until now, it has not
> happened.
>
> Solutions are tricky. Upstream is trying to see if they can tweak libgcc7
> 7.5.0 to not error out, like libgcc7 7.4.x did not error out. Maybe that
> might work. Dunno.
>
> We can set the DYLD_LIBRARY_PATH to point to /opt/local/lib/libgcc/ and
> so software will look there first. That works. Getting it to always apply
> to all software is a bit tricky...
>
> You can set up a chroot environment, and run your software there -- good
> luck -- if you know how to do that, you're probably not trying to run
> libgcc7 on a 15 year old PowerMac.
>
> Or -- get ready for it -- we can update the libgcc in /usr/lib to a
> current one, like the one from libgcc7 with some kind of installer that
> we supply (and maintain, and and and). I can hear the groans now.
>
> We could, perhaps, get libc++ working on PowerMac, and use that -- it
> would, naturally, have no such interaction with /usr/lib/libstdc++.dylib and
> therefore problem solved.
>
> So -- working on it. For now, libgcc7 7.4.x is magically immune, it
> appears, at least so far as we know, for now.
> K
>
>
> On Dec 11, 2019, at 12:58, Ken Cunningham 
> wrote:
>
> Iain has asked for a minimal reproducer and a bisected commit that
> generated the error. Then it's worth opening the bug report.
>
> I tried a few different iostream with locale test files, but so far
> couldn't repro the error.
>
> Best,
>
> Ken
>
> On Wed, Dec 11, 2019 at 12:11 PM Eric Gallager 
> wrote:
>
>> On 12/11/19, Ken Cunningham  wrote:
>> > We're having troubles with the recent gcc7 upgrade to 7.5.0 on i386
>> > (bootstrapping with non-system assembler) and on 10.5 PPC (bus errors in
>> > memory handling, possibly related to locale support, maybe some other
>> thing
>> > TBA).
>> >
>> > We may have to bump epoch and roll back to last 7.4.x unless we can get
>> > this sorted out soon, as tickets are starting up...
>> >
>> > Ken
>> >
>>
>> Is there an upstream bug filed in the GCC Bugzilla about this? I
>> realize the branch for 7 is closed now, but it could be due to a
>> change backported from a different branch where it's also relevant...
>>
>

Re: [MacPorts] #59153: dbus @1.12.16_0: Startup items not started correctly

[Ruben Di Battista]

The only dbus folder I had is .dbus-keyring. I removed it, but if I do the 
`port load dbus` I still get only the system session: 

60388 ??         0:00.02 /opt/local/bin/dbus-daemon --system --nofork

On 22 November 2019 at 20:40:20, MacPorts (nore...@macports.org) wrote:

#59153: dbus @1.12.16_0: Startup items not started correctly  
--+-  
Reporter: rubendibattista | Owner: MarcusCalhoun-Lopez  
Type: defect | Status: assigned  
Priority: Normal | Milestone:  
Component: ports | Version: 2.6.0  
Resolution: | Keywords:  
Port: dbus |  
--+-  

Comment (by kencu):  

I went through my HOME folder, and cleaned out several years worth of .XYZ  
directories, some of which seemed to be `dbus` related.  

Since I did that, I'm no longer seeing these dbus errors!  

Oh, could it be so easy  

--  
Ticket URL:   
MacPorts   
Ports system for macOS  


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: Updating the epubcheck port

[Ruben Di Battista]

I’ll probably go depending on openjdk… 

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 21 November 2019 at 00:16:52, Randolph M. Fritz (rmfri...@gmail.com) wrote:

I took a shot at this, and what I found is that the current version of 
epubcheck is not supported by the JRE available from Apple.

There are several different ways I can make this work:
I can require the Oracle JRE, located (when installed) at /Library/Internet 
Plug-Ins/JavaAppletPlugin.plugin
I can require one or another of the openjdk ports available in MacPorts.
… something else?
What do the experts here suggest?
--
Randolph M. Fritz || rmfri...@gmail.com

signature.asc
Description: Message signed with OpenPGP using AMPGpg

Help for this PR

[Ruben Di Battista]

Can anyone help me getting this PR through? :)

https://github.com/macports/macports-ports/pull/5016

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Can’t see Azure pipelines logs anymore

[Ruben Di Battista]

Hello, 

I’ve been able to see the pipelines logs (at least for a while after the end of 
the execution) for a long time. Now it’s been 3 - 4 weeks that I always get the 
message reported in the attached screen and I cannot see them anymore. Does 
anyone know why? I have a non-reproducible error on the pipelines and I’d like 
to use the log to see what’s wrong… :)



  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: 10.7 buildbot disk space issues

[Ruben Di Battista]

+1 for ncdu

On Thu, 15 Aug 2019, 11:00 Nils Breunese,  wrote:

> > Christopher Jones  wrote:
>
> >> I've previously used Grand Perspective to examine the disk space usage
> of the build machines and didn't see anything big, but it turns out Grand
> Perspective doesn't include items whose names begin with a period, and
> that's where the problem was: the .Spotlight-V100 directory on the 10.7
> builder was 36GiB the first time I looked and 26GiB the second time I
> looked, and on the 10.8 builder it was 16GiB. I've deleted the Spotlight
> indexes on all the builders and hopefully when they're done rebuilding
> they'll be smaller.
> >
> > I wouldn’t use applications like that for this sort of thing, for that
> very reason. Then tend to try and be just a bit too clever for my tastes.
> >
> > In the end, I tend to just rely on good old dumb ‘df -h’ …
>
> I’d recommend using ncdu for this. It’s a brilliant CLI tool to drill down
> when looking for what is using a lot of space and MacPorts has a port for
> it. ;o)
>
> Nils.
>

Re: Is the buildbots filesystem case-sensitive?

[Ruben Di Battista]

Oops, sorry. My email client address book decided to use the old address. I 
removed it now from the address book. Sorry!

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 14 August 2019 at 21:19:13, Ryan Schmidt (ryandes...@macports.org) wrote:



On Aug 14, 2019, at 13:04, Ruben Di Battista wrote:  

> I’m hitting strange file not found errors on the paraview build on the 
> buildbots, but not locally nor on Azure; so I was wondering: do they run on a 
> case sensitive filesystem?  

Yes.  


P.S: Please make sure you write to our new list addresses at 
lists.macports.org, not the older hostname that was deprecated in 2016.  



signature.asc
Description: Message signed with OpenPGP using AMPGpg

Is the buildbots filesystem case-sensitive?

[Ruben Di Battista]

Hello, 
I’m hitting strange file not found errors on the paraview build on the 
buildbots, but not locally nor on Azure; so I was wondering: do they run on a 
case sensitive filesystem?

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

CMake Default Prefixes are wrong?

[Ruben Di Battista]

Hello, 

I’m still struggling with the build of Paraview :/. I have a problem with cmake 
not finding the Config.cmake file for the port:icet. So I watched the debug 
builds on Azure, and the CMAKE_PREFIX_PATH is set to: 
-DCMAKE_PREFIX_PATH=/opt/local/share/cmake/modules. So I went checking the 
cmake1.1 port Group and in facts:

```
proc cmake::module_path {} {
    if {[llength [option cmake.module_path]]} {
        set modpath "[join [concat [option cmake_share_module_dir] [option 
cmake.module_path]] \;]"
    } else {
        set modpath [option cmake_share_module_dir]
    }
    return [list \
        -DCMAKE_MODULE_PATH="${modpath}" \
        -DCMAKE_PREFIX_PATH="${modpath}"
    ]
}

```

But I think that CMAKE_PREFIX_PATH should instead be (or at least should 
contain) /opt/local/lib/cmake. Shouldn’t it?


  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: Setting up port builds on Azure using master branch of macports

[Ruben Di Battista]

What are the longest ports to build?

In my experience paraview and mame, also probably the compilers. And they
should fit the 360 minutes, right?

On Fri, 9 Aug 2019, 07:35 Zero King,  wrote:

> On Thu, Aug 08, 2019 at 08:59:46PM +0200, Rainer Müller wrote:
> >On 04/08/2019 17.34, Ryan Schmidt wrote:
> >> On Aug 1, 2019, at 10:50, Blair Zajac wrote:
> >>
> >>> Why Azure?
> >>
> >> We already use Azure to test pull requests, but we test against the
> released version of MacPorts base, currently 2.5.4. I guess Mojca is
> suggesting we add another builder that uses the newer MacPorts base master,
> to discover if some ports are not compatible with that.
> >>
> >> We also already use Travis CI for pull requests, but Travis was
> purchased by another company known for allowing its services to languish
> and die, hence our desire to find alternatives.
> >>
> >> It would need to be free and support building on macOS with root access
> and not have such a low time limit that our builds would time out. Travis
> for example has a time limit of 50 minutes which has already been
> problematic for some ports. If you know of other services that offer that,
> let us know.
> >
> >GitHub announced GitHub Actions today, which is a CI system provided for
> free on
> >public repositories. It even supports macOS.
> >
> >https://github.blog/2019-08-08-github-actions-now-supports-ci-cd/
> >
> >However, the announcement does not mention any limits such as the maximum
> >per-job execution time, which has been our main problem with other
> services so
> >far. I guess this might be something they will still try to figure out
> during
> >the beta.
>
> The default limit is 360 minutes. Not sure if it could be extended.
>
>
> https://help.github.com/en/articles/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes
>
> >In any case, it might be worth a try. It will be available in November for
> >everyone. Just in case anyone wants to experiment with it earlier, I
> signed up
> >the @macports organization for the GitHub Actions Beta and we are now on
> the
> >waitlist.
> >
> >Rainer
>
> --
> Zero
>

Re: Python3 library path, no symlink in /opt/local/lib?

[Ruben Di Battista]

In any case I think that the `python27` and the `python3` ports need to behave 
at the same way (that means also removing the symlink of the library into 
/opt/local/lib from the `python27` or adding it in the `python3` ports). 
Symmetry is good. :)

Or is there any other reason why they behave differently?

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 2 August 2019 at 00:21:34, Ruben Di Battista (rubendibatti...@gmail.com) 
wrote:

Ok, 
I fixed the cmake invocation that before was looking for the python library in 
/opt/local/lib. It was hardcoded in the cmake invocation. Now it looks into 
/opt/local/Library/Frameworks/Python.framework/Versions/{version}/lib as 
expected.

Thanks Joshua for putting me on the right path! :)
  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 1 August 2019 at 01:11:26, Joshua Root (j...@macports.org) wrote:

On 2019-8-1 08:45 , Ruben Di Battista wrote:
> :info:configure -- Looking for feenableexcept - not found
> :info:configure -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
> :info:configure -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
> :info:configure -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
> :info:configure -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
> - Success
> :info:configure -- Performing Test COMPILER_HAS_DEPRECATED_ATTR
> :info:configure -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
> :info:configure -- Found PythonLibs: /opt/local/lib/libpython3.7.dylib
>
> ```
>
> So it finds Python 3.7, but the library path is wrong. How is this
> possible? Anyone can give me an hint?

No idea, you'd have to look at what its CmakeLists is doing. It's
clearly not using any of the recommended ways to find out how to link
against python though:

% python3.7-config --ldflags
-L/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/config-3.7m-darwin
-lpython3.7m -ldl -framework CoreFoundation

% pkg-config --libs python-3.7
-L/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib
-lpython3.7m

Hopefully there is a cmake variable that can be set to influence where
it looks.

- Josh


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: Python3 library path, no symlink in /opt/local/lib?

[Ruben Di Battista]

Ok, 
I fixed the cmake invocation that before was looking for the python library in 
/opt/local/lib. It was hardcoded in the cmake invocation. Now it looks into 
/opt/local/Library/Frameworks/Python.framework/Versions/{version}/lib as 
expected.

Thanks Joshua for putting me on the right path! :)
  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 1 August 2019 at 01:11:26, Joshua Root (j...@macports.org) wrote:

On 2019-8-1 08:45 , Ruben Di Battista wrote:  
> :info:configure -- Looking for feenableexcept - not found  
> :info:configure -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY  
> :info:configure -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success  
> :info:configure -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY  
> :info:configure -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY  
> - Success  
> :info:configure -- Performing Test COMPILER_HAS_DEPRECATED_ATTR  
> :info:configure -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success  
> :info:configure -- Found PythonLibs: /opt/local/lib/libpython3.7.dylib  
>  
> ```  
>  
> So it finds Python 3.7, but the library path is wrong. How is this  
> possible? Anyone can give me an hint?  

No idea, you'd have to look at what its CmakeLists is doing. It's  
clearly not using any of the recommended ways to find out how to link  
against python though:  

% python3.7-config --ldflags  
-L/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/config-3.7m-darwin
  
-lpython3.7m -ldl -framework CoreFoundation  

% pkg-config --libs python-3.7  
-L/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib  
-lpython3.7m  

Hopefully there is a cmake variable that can be set to influence where  
it looks.  

- Josh  


signature.asc
Description: Message signed with OpenPGP using AMPGpg

inkscape-gtk3-devel and D-Bus errors

[Ruben Di Battista]

Hello, 
I’m working on Inkscape-gtk3-devel in order to build it on Mojave (since the 
standard port doesn’t work). So far I managed to make it build correctly and 
the app also starts… But I’m getting some errors related to D-Bus that are a 
bit weird:

```
inkscape
dbus[1696]: Dynamic session lookup supported but failed: launchd did not 
provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
Failed to get connection
** (:1696): CRITICAL **: 16:11:24.836: dbus_g_proxy_new_for_name: 
assertion 'connection != NULL' failed

** (:1696): CRITICAL **: 16:11:24.837: dbus_g_proxy_call: assertion 
'DBUS_IS_G_PROXY (proxy)' failed

** (:1696): CRITICAL **: 16:11:24.837: 
dbus_g_connection_register_g_object: assertion 'connection != NULL' failed
Pango version: 1.42.4

** (:1696): WARNING **: 16:11:25.228: Fonts dir 
'/Users/rubendibattista/.config/inkscape/fonts' does not exist and will be 
ignored.

(:1696): Gtk-CRITICAL **: 16:11:25.810: gtk_combo_box_set_active: 
assertion 'index_ >= -1' failed

(:1696): Gtk-CRITICAL **: 16:11:25.884: gtk_combo_box_set_active: 
assertion 'index_ >= -1' failed
dbus[1696]: Dynamic session lookup supported but failed: launchd did not 
provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
Failed to get connection
** (:1696): CRITICAL **: 16:11:27.329: dbus_g_proxy_new_for_name: 
assertion 'connection != NULL' failed

** (:1696): CRITICAL **: 16:11:27.329: 
dbus_g_connection_register_g_object: assertion 'connection != NULL' failed
*** BUG ***
In void pixman_region32_init_rect(region_type_t *, int, int, unsigned int, 
unsigned int): Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug
```
Inkscape seems to run despite the errors. The problem is that dbus-daemon is 
running: 

```
ps -A | grep bus
83 ??         0:00.02 /opt/local/bin/dbus-daemon --system --nofork
```

I also tried to `port unload/load` dbus, but no change. I also tried manually 
to start the dbus login session:
```
launchctl start org.freedesktop.dbus-session
```

```
ps -A | grep bus
83 ??         0:00.02 /opt/local/bin/dbus-daemon --system —nofork
83 ??         0:00.02 /opt/local/bin/dbus-daemon --system --nofork
 1159 ??         0:00.01 /opt/local/bin/dbus-daemon --nofork --session
```

Any idea?

PS: Shouldn’t the session also be running after the `port load`? Why do I need 
to start it manually?
  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: Slack-like chat (also for GSOC)

[Ruben Di Battista]

If you want I can try to setup the Community and the IRC bridge...

On Thu, 16 May 2019, 08:31 Ruben Di Battista, 
wrote:

> I would like to stress once again about Matrix.
>
> If we setup Matrix, we can bridge the channels with whatever service you
> might need. First of all IRC, so people that like to keep hanging out there
> can still do it with the additional benefits of having more people to talk
> with.
>
> These other people would access the same chat stream from whatever client
> they want to (we might need to setup self hosted bridges for them...). That
> means potentially you can have bridges from Gitter, Rocket.Chat, Slack or
> even WhatsApp if you like so, altogether working bijectively.
>
> I would strongly consider it since this way we are not stuck with a
> specific service but you can merge them together if you wish so...
>
> I would propose to setup a Matrix community for Macports and bridge its
> channels with the IRC ones. This does not need any self hosting capability.
>
> As a step two we might also want to experiment with the Gitter bridge
> since someone else already configured a channel there...
>
> What do you think?
>
>
>
>
> On Thu, 16 May 2019, 08:21 Rainer Müller,  wrote:
>
>> On 2019-05-14 18:11, Rainer Müller wrote:
>> > For the self-hosted options, Rocket Chat would be an option. However,
>> > when we used it at work, after a while I started to miss some kind of
>> > threading for longer conversations. Although we also usually do not
>> > have
>> > long conversations or that much activity on IRC, so maybe this is not
>> > that important here.
>>
>> Turns out the newest version of Rocket Chat already has
>> "sub-discussions" for this, so my point above is not fully valid. I have
>> not worked with the latest version, so my experience with Rocket Chat
>> might be more limited than I thought.
>>
>> Rainer
>>
>

Re: Slack-like chat (also for GSOC)

[Ruben Di Battista]

I would like to stress once again about Matrix.

If we setup Matrix, we can bridge the channels with whatever service you
might need. First of all IRC, so people that like to keep hanging out there
can still do it with the additional benefits of having more people to talk
with.

These other people would access the same chat stream from whatever client
they want to (we might need to setup self hosted bridges for them...). That
means potentially you can have bridges from Gitter, Rocket.Chat, Slack or
even WhatsApp if you like so, altogether working bijectively.

I would strongly consider it since this way we are not stuck with a
specific service but you can merge them together if you wish so...

I would propose to setup a Matrix community for Macports and bridge its
channels with the IRC ones. This does not need any self hosting capability.

As a step two we might also want to experiment with the Gitter bridge since
someone else already configured a channel there...

What do you think?




On Thu, 16 May 2019, 08:21 Rainer Müller,  wrote:

> On 2019-05-14 18:11, Rainer Müller wrote:
> > For the self-hosted options, Rocket Chat would be an option. However,
> > when we used it at work, after a while I started to miss some kind of
> > threading for longer conversations. Although we also usually do not
> > have
> > long conversations or that much activity on IRC, so maybe this is not
> > that important here.
>
> Turns out the newest version of Rocket Chat already has
> "sub-discussions" for this, so my point above is not fully valid. I have
> not worked with the latest version, so my experience with Rocket Chat
> might be more limited than I thought.
>
> Rainer
>

Re: Blackist mirrors.shu.edu.cn from CI?

[Ruben Di Battista]

Well, I get the same error sometimes on my local laptop… In any case thanks for 
the explanation. :)

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 11 May 2019 at 02:17:45, Ryan Schmidt (ryandes...@macports.org) wrote:

On May 10, 2019, at 17:58, Clemens Lang wrote:

On Fri, May 10, 2019 at 06:49:56PM +0200, Ruben Di Battista wrote:
That mirror is making some of the builds fail because it is
unreachable.

Inability to reach or resolve any one mirror will not cause a build to fail. 
MacPorts will try other mirrors until it finds one that works. 


Would it be possible to blacklist it from the build
machines?

https://paste.macports.org/7b1151ac389f

This build failed because Travis was unable to resolve any hostname. This is a 
defect in the Travis infrastructure that surfaces from time to time. I don't 
know of anything we can do about it, short of reporting it to Travis again and 
asking them to fix it. 


Is anybody able to reach that mirror? It didn't seem to work for me
either last time I tried. Maybe we should remove it for good then?

The mirror has been down for almost a month. I've attempted to reach the 
administrator by email and by filing an issue in their issue tracker. There has 
been no response. I guess we should remove the mirror. 

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



signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: Slack-like chat (also for GSOC)

[Ruben Di Battista]

I suggest to get a look to Matrix.org. They perfectly integrate with IRC,
but they have bridges for everything. No need to self host (but you can and
it's federated with the rest of the fédération)

It's a pretty cool technology IMHO.


On Thu, 9 May 2019, 23:38 Mojca Miklavec,  wrote:

> Hi,
>
> I know that our official channels only include mailing lists, IRC and
> PR/ticket discussion so far, but I'm curious about your stand with
> respect to setting up a service like Zulip Chat / Rocket Chat / ...
> for aiding the GSOC communication when higher frequency of potentially
> simple questions would be needed. I know IRC could fulfill such a
> task, but it doesn't work too well for me. (I'm offline when at work,
> cannot really use phone efficiently for communication etc..)
>
> Would it be realistic to install such a service on breaburn if needed?
> (Or is it too complex / too much work?)
>
> I strongly suspect that one of those services also integrates pretty
> well with IRC. I've been using Slack, Zulip, Discord, Gitter at
> various occasions and I like the way they work.
>
> Thank you,
> Mojca
>

Programmatically set variants from a list

[Ruben Di Battista]

Hello, 
I’m trying to set paraview python variants programmatically (each of them 
conflicts with the others). I’m not a TCL ninja so I came out with the code 
below, but I’m getting error of the type: "Warning: Variant python27 conflicts 
with non-existing variant python35 python36 python37” for all the variant 
combinations. How do I set variants programmatically?
 

```
# Supported pythons
set python_versions {27 35 36 37}

foreach pyver ${python_versions} {
    # Conflicting python versions
    set other_python_versions {}
    foreach other_pyver ${python_versions} {
        if {${other_pyver} ne ${pyver}} {
            if {${other_pyver} ni ${other_python_versions}} {
                lappend other_python_versions python${other_pyver}
                }
            }
    }

    # Get python branch
    set python_branch {[string range ${pyver} 0 end-1].[string index ${pyver} 
end]}

    variant python${pyver} conflicts [join ${other_python_versions} " "] 
description {Add Python ${python_branch} support.} {
            depends_lib-append port:py${pyver}-matplotlib
            configure.args-append \
                -DPARAVIEW_ENABLE_PYTHON:BOOL=ON \
                -DPYTHON_EXECUTABLE=${prefix}/bin/python${python_branch} \
                
-DPYTHON_INCLUDE_DIR=${frameworks_dir}/Python.framework/Versions/${python_branch}/Headers/
 \
                -DPYTHON_LIBRARY=${prefix}/lib/libpython${python_branch}.dylib

            if {[mpi_variant_isset]} {
                depends_lib-append port:py${pyver}-mpi4py
                configure.args-append \
                    -DVTK_USE_SYSTEM_MPI4PY:BOOL=ON
            }
    }
    
}

foreach pyver ${python_versions} {
    if {[variant_isset python${pyver}]} {
        notes-append\
            "\n Currently Paraview installs as an app, including the Python 
modules. To use with MacPorts Python, add 
${applications_dir}/paraview.app/Contents/Python/:${applications_dir}/paraview.app/Contents/Libraries/
 to PYTHONPATH and ${applications_dir}/paraview.app/Contents/Libraries/ to 
DYLD_LIBRARY_PATH. Also, simultaneous use of independent vtk libraries, e.g. 
with Mayavi, may result in segfault."
    }

}
```

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Interesting discussion about Chocolatey and Homebrew build from source deprecation

[Ruben Di Battista]

I think it's an interesting discussion. Hope you don't mind the little
spam.

For me it's one of the reason I stick to Macports.


Mike McQuaid (@MikeMcQuaid) tweeted at 4:09 PM on Wed, May 01, 2019:
A discussion between @gep13 (@chocolateynuget Maintainer) and I
(@MacHomebrew Project Leader) about user requests to build from source in
Chocolatey and Homebrew's recent deprecation of building from source:
https://t.co/5VUr0cRWu5
(https://twitter.com/MikeMcQuaid/status/1123590383517224961?s=03)

Re: mirrors.shu.edu.cn Down?

[Ruben Di Battista]

I’m sorry, the port is a port I’m writing to comply to a recent PR I’m trying 
to get done (for the port py-pew). I generally redact the username in my logs. 
Don’t know if it’s effectively a good practice. I’m sorry if made your effort 
to help me harder… 

Here’s the port I’m writing (https://gitlab.com/snippets/1851912).

Actually the transcript ends at the line I posted… There’s no attempt to 
download from GitHub as you correctly highlight. 

Thank you all for the help, 


  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 28 April 2019 at 14:49:18, Ryan Schmidt (ryandes...@macports.org) wrote:

On Apr 28, 2019, at 07:33, Ruben Di Battista wrote:  

> Here it is the log. Thanks for the fast answer...  
>  
> :debug:fetch Fetching distfile failed: The requested URL returned error: 404 
> Not Found  
> :notice:fetch ---> Attempting to fetch resumable-urlretrieve-0.1.6.tar.gz 
> from 
> http://jog.id.distfiles.macports.org/macports/distfiles/py-resumable-urlretrieve
>   
> :debug:fetch Fetching distfile failed: Connection timed out after 30001 
> milliseconds  
> :notice:fetch ---> Attempting to fetch resumable-urlretrieve-0.1.6.tar.gz 
> from http://kmq.jp.distfiles.macports.org/py-resumable-urlretrieve  
> :debug:fetch Fetching distfile failed: The requested URL returned error: 404 
> Not Found  
> :notice:fetch ---> Attempting to fetch resumable-urlretrieve-0.1.6.tar.gz 
> from http://cjj.kr.distfiles.macports.org/py-resumable-urlretrieve  
> :debug:fetch Fetching distfile failed: The requested URL returned error: 404 
> Not Found  
> :notice:fetch ---> Attempting to fetch resumable-urlretrieve-0.1.6.tar.gz 
> from 
> http://aarnet.au.distfiles.macports.org/pub/macports/distfiles/py-resumable-urlretrieve
>   
> :debug:fetch Fetching distfile failed: The requested URL returned error: 404 
> Not Found  
> :notice:fetch ---> Attempting to fetch resumable-urlretrieve-0.1.6.tar.gz 
> from 
> https://pek.cn.distfiles.macports.org/macports/distfiles/py-resumable-urlretrieve
>   
> :debug:fetch Fetching distfile failed: The requested URL returned error: 404 
> Not Found  
> :notice:fetch ---> Attempting to fetch resumable-urlretrieve-0.1.6.tar.gz 
> from 
> http://nou.nc.distfiles.macports.org/pub/macports/distfiles.macports.org/py-resumable-urlretrieve
>   
> :debug:fetch Fetching distfile failed: The requested URL returned error: 404 
> Not Found  
> :notice:fetch ---> Attempting to fetch resumable-urlretrieve-0.1.6.tar.gz 
> from https://mirrors.shu.edu.cn/macports/distfiles/py-resumable-urlretrieve  
> :debug:fetch Fetching distfile failed: Failed to connect to 
> mirrors.shu.edu.cn port 443: Connection refused  
> :error:fetch Failed to fetch py37-resumable-urlretrieve: Failed to connect to 
> mirrors.shu.edu.cn port 443: Connection refused  
> :debug:fetch Error code: NONE  
> :debug:fetch Backtrace: Failed to connect to mirrors.shu.edu.cn port 443: 
> Connection refused  
> :debug:fetch while executing  
> :debug:fetch "error $lastError"  
> :debug:fetch (procedure "portfetch::fetchfiles" line 62)  
> :debug:fetch invoked from within  
> :debug:fetch "portfetch::fetchfiles"  
> :debug:fetch (procedure "portfetch::fetch_main" line 17)  
> :debug:fetch invoked from within  
> :debug:fetch "$procedure $targetname"  
> :error:fetch See 
> /opt/local/var/macports/logs/-ports_python_py-resumable-urlretrieve/py37-resumable-urlretrieve/main.log
>  for details  

This transcript only shows downloads attempted from our mirrors. It does not 
show the attempt to download from the original server, whatever that might be.  

This port does not appear to exist in our collection (and that's why its files 
are not on our mirrors). Where did you get this Portfile? You edited the 
transcript to replace the path to the ports tree with "" so I don't know 
where this port came from or where it's supposed to be downloading from.  

If this is a Portfile you're writing, you could attach it here and then we can 
help you debug why it's not fetching from the intended server.  



signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: mirrors.shu.edu.cn Down?

[Ruben Di Battista]

Here it is the log. Thanks for the fast answer...

:debug:fetch Fetching distfile failed: The requested URL returned error: 404 
Not Found
:notice:fetch --->  Attempting to fetch resumable-urlretrieve-0.1.6.tar.gz from 
http://jog.id.distfiles.macports.org/macports/distfiles/py-resumable-urlretrieve
:debug:fetch Fetching distfile failed: Connection timed out after 30001 
milliseconds
:notice:fetch --->  Attempting to fetch resumable-urlretrieve-0.1.6.tar.gz from 
http://kmq.jp.distfiles.macports.org/py-resumable-urlretrieve
:debug:fetch Fetching distfile failed: The requested URL returned error: 404 
Not Found
:notice:fetch --->  Attempting to fetch resumable-urlretrieve-0.1.6.tar.gz from 
http://cjj.kr.distfiles.macports.org/py-resumable-urlretrieve
:debug:fetch Fetching distfile failed: The requested URL returned error: 404 
Not Found
:notice:fetch --->  Attempting to fetch resumable-urlretrieve-0.1.6.tar.gz from 
http://aarnet.au.distfiles.macports.org/pub/macports/distfiles/py-resumable-urlretrieve
:debug:fetch Fetching distfile failed: The requested URL returned error: 404 
Not Found
:notice:fetch --->  Attempting to fetch resumable-urlretrieve-0.1.6.tar.gz from 
https://pek.cn.distfiles.macports.org/macports/distfiles/py-resumable-urlretrieve
:debug:fetch Fetching distfile failed: The requested URL returned error: 404 
Not Found
:notice:fetch --->  Attempting to fetch resumable-urlretrieve-0.1.6.tar.gz from 
http://nou.nc.distfiles.macports.org/pub/macports/distfiles.macports.org/py-resumable-urlretrieve
:debug:fetch Fetching distfile failed: The requested URL returned error: 404 
Not Found
:notice:fetch --->  Attempting to fetch resumable-urlretrieve-0.1.6.tar.gz from 
https://mirrors.shu.edu.cn/macports/distfiles/py-resumable-urlretrieve
:debug:fetch Fetching distfile failed: Failed to connect to mirrors.shu.edu.cn 
port 443: Connection refused
:error:fetch Failed to fetch py37-resumable-urlretrieve: Failed to connect to 
mirrors.shu.edu.cn port 443: Connection refused
:debug:fetch Error code: NONE
:debug:fetch Backtrace: Failed to connect to mirrors.shu.edu.cn port 443: 
Connection refused
:debug:fetch     while executing
:debug:fetch "error $lastError"
:debug:fetch     (procedure "portfetch::fetchfiles" line 62)
:debug:fetch     invoked from within
:debug:fetch "portfetch::fetchfiles"
:debug:fetch     (procedure "portfetch::fetch_main" line 17)
:debug:fetch     invoked from within
:debug:fetch "$procedure $targetname"
:error:fetch See 
/opt/local/var/macports/logs/-ports_python_py-resumable-urlretrieve/py37-resumable-urlretrieve/main.log
 for details

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 28 April 2019 at 14:29:50, Ryan Schmidt (ryandes...@macports.org) wrote:

On Apr 28, 2019, at 05:59, Ruben Di Battista wrote:  

> `Error: Failed to fetch py37-resumable-urlretrieve: Failed to connect to 
> mirrors.shu.edu.cn port 443: Connection refused`  

I agree, the server isn't responding to https requests or pings. I've reported 
the problem to the server's administrator.  


> PS: How do I workaround this and force port to download the tarball from the 
> GitHub URL?  

You shouldn't need to do anything. If MacPorts can't download from one URL, it 
will try others until it succeeds or until it fails downloading from all 
servers.  

If that's not what's happening for you, show us your complete terminal output.  



signature.asc
Description: Message signed with OpenPGP using AMPGpg

mirrors.shu.edu Down?

[Ruben Di Battista]

`Error: Failed to fetch py37-resumable-urlretrieve: Failed to connect to 
mirrors.shu.edu.cn port 443: Connection refused`

PS: How do I workaround this and force port to download the tarball from the 
GitHub URL?

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: Update Qt5

[Ruben Di Battista]

Mmmh. I’m officially dumb :).

Sorry for bothering, I did not see it was already up to date. 

Sorry!!

On 21 March 2019 at 01:20:32, Marcus Calhoun-Lopez (mcalh...@macports.org) 
wrote:

Qt 5 should already be at version 5.12.2.  

-Marcus  

> On Mar 20, 2019, at 5:19 PM, Ruben Di Battista  
> wrote:  
>  
> Hello,  
>  
> 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 Qt 
> version so I’ll try to build with the latest commit of ParaView and see if 
> the problem is really solved?  
>  
> Thanks,  
>  
> _  
> -. .´ |  
> ', ; |∞∞  
> ˜˜ |∞ RdB  
> ,., |∞∞  
> .' '. |  
> -' `’  
>  
>  
> https://rdb.is  



signature.asc
Description: Message signed with OpenPGP using AMPGpg

Update Qt5

[Ruben Di Battista]

Hello, 

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 Qt 
version so I’ll try to build with the latest commit of ParaView and see if the 
problem is really solved?

Thanks, 

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: How to check for generic python variant?

[Ruben Di Battista]

Thank you Chris for the response, 

I was probably not clear enough. 

I’m trying to overhaul the Portfile because I’m hitting a problem with the 
compilation of the mpi4py package that currently in the Portfile is compiled 
from VTK itself, but it should instead be provided by the system. In the 
current VTK portfile there are already all the python variants, but I would 
like to check if one of them was selected by the user, and then apply some 
configuration options related to whatever python variant was chosen.

To be clear, what I would like to achieve is:

If {[variant_isset python{27,35,36,37}]}
    Do something

I’m not a ninja with TCL, so I’m asking what is the right way of doing this. Do 
I need to have an if condition for each variant? Because I could also write the 
configuration option in all the variant bodies, but it would be a bit ugly 
since a will be duplicating the same code… 

I don’t know if it’s clearer now… I need to check for a python variant to be 
selected by the user, whatever version it is, and applying some configuration 
options if it is set. 

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 17 March 2019 at 17:35:19, Chris Jones (jon...@hep.phy.cam.ac.uk) wrote:

Hi,

On 17 Mar 2019, at 4:14 pm, Ruben Di Battista  wrote:

Hello, 

I’m trying to improve VTK portfile. I would like to be able to check for a 
python variant to be enabled, whatever it is, whatever version of python. How 
do I do that? 

There is no such thing as a generic python variant. You should provide variants 
that use the various different python versions that macports supports, whatever 
VTK can support, and leave it to the user to decide which they wish to use, if 
need be picking one as a default variant (python 3.7 would be the obvious 
choice).

Chris


  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

How to check for generic python variant?

[Ruben Di Battista]

Hello, 

I’m trying to improve VTK portfile. I would like to be able to check for a 
python variant to be enabled, whatever it is, whatever version of python. How 
do I do that? 

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: Online meeting today at 15:00 UTC (in 4 hours)

[Ruben Di Battista]

Just as suggestion, there's a package manager named Spack that is quite similar 
to Macports (and Brew) that is made for HPC deployment on clusters, but I'm 
also using it for installing software on Linux in my $HOME when I don't have 
admin rights. It works already for Mac and it basically has all the pieces 
needed for replicating Macports functionalities...

I'm not a great fan or replicating work so if you're really thinking about 
rewriting the base in Python looking at Spack could be a great way. 
Spack at the moment does even “more” than Macports because it’s meant to 
install different toolchains baselines one next to each other (e.g. GCC 8 + 
MPICH + FFTW next to Intel Compiled stuff), but with configuration tweaks and 
Spack Views you can probably replicate Macports functionalities. I already 
contributed few packages and the class-based package system is really easy to 
tackle for writing new packages. Moreover the tool is backed by LLNL 
Computation Department. 

Just my two cents to a suggestion, it would be great to have the base written 
in Python … TCL is really obscure to me :)

On Sat, 12 Jan 2019, 20:26 Mojca Miklavec  wrote:
>
> Hi,
>
> I think I first messed up the addition and subtraction in time zones
> (last time it was apparently at 13:00 UTC), and then with sending out
> the email yesterday under the wrong address. I wanted to ask if there
> were any participants from the far east or west who wanted to
> participate, in that case we could shift the hour, but since we only
> had people from UTC+1 and UTC+5.5 who raised their hands, we'll stick
> with 15:00 UTC for now.
>
> This is the calendar:
>
> https://calendar.google.com/calendar/embed?src=9unkhredr302jroorlhusav0ko%40group.calendar.google.commode=AGENDA
>
> And this is for hangouts (last time we had a much shorter link, I'm
> unable to come up with that shorter one this time, but if anyone knows
> how, feel free to post something better):
>
> https://calendar.google.com/event?action=TEMPLATEtmeid=N2ZxcWFsbnFmcmtvcmxpYWVrMGxoc2s4MGQgOXVua2hyZWRyMzAyanJvb3JsaHVzYXYwa29AZwtmsrc=9unkhredr302jroorlhusav0ko%40group.calendar.google.com
>
> Meeting notes will be collected here:
>     https://trac.macports.org/wiki/Meetings/2019-01-12
>
> Topics:
> - Google Summer of Code 18 & 19
> - MacPorts Meeting in 2019
> - Software Freedom Conservancy
> - Review open pull requests and roadmap for base
> - ... any other topics open for proposal?
>
> Looking forward to see you soon,
>     Mojca


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: macports challenges

[Ruben Di Battista]

I wanted to provide my feedback w.r.t. this topic. 

I also contribute to other “package manager”, a bit more tailored to HPC 
(EasyBuild and Spack) and in my opinion, more than the actual advertisement, 
the real hindering factor for Macports is TCL. TCL is hard, at least compared 
to Ruby or Python. It has a soul that is more oriented towards scripting than 
programming, and it makes hard to dive into port development. 

Another aspect that in my opinion is lacking at Macports side is a deep 
documentation on Portfile development. For example I still don’t know how most 
of the PortGroups work and often my workflow is to identify a well known port 
that makes use of a specific PortGroup and replicate most of the behavior (or 
otherwise looking directly in the source of the PortGroup). If we compare with 
Spack package.py development docs or EasyBuild easyconfigs/easyblocks I think 
we can easily highlight a documentation debt. 

Another aspect I would like to highlight, and this is more personal maybe, is 
related to the communication interaction w/ the community. I find myself the 
mailing list sort of obsolete. Moreover, very often, there’s an overlap between 
the subjects in macports-users and the ones of macports-dev. Again, both Spack 
and EB communities are on Slack.  I’m not here endorsing a proprietary, 
non-free, platform (there are FOSS alternatives), but I find the “ChatOps” 
movement and communication strategy very effective to promote community 
interaction.

Just my 2¢ :)

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 6 dicembre 2018 a 15:28:37, Jonathan Stickel (jjstic...@gmail.com) scritto:

I'm glad to see some constructive discussion. After I sent the email, I  
was quite worried of the negative tone, and that it might be perceived  
as trolling. Sorry if that is true; it was not my attention.  

On 12/6/18 01:13, Nils Breunese wrote:  
> Rainer Müller wrote:  
>  
>> Somehow the Homebrew community managed to get their ubiquitous marketing  
>> on almost every software project website. Compare this with the MacPorts  
>> website, which has not seen any redesign in more than 10 years...  
>>  
>> Although a good package management system should not need to advertise  
>> itself, as every software would be available without users being told  
>> where to look – the package manager should be their first choice.  
>  
> But you need to know about this package manager first then. And be  
> convinced into installing and using it. I found out about the existence  
> of package managers on Mac (I guess it was Fink for me at the time)  
> through installation instructions for some tool I wanted to install.  
>  
> When I started to maintain some packages for MacPorts I also made an  
> effort to do pull requests for the install docs to add instructions for  
> installing via MacPorts (for instance [0]). I think this is very  
> important PR for a package manager, apart from its own website.  
>  
> For instance, yesterday I wanted to try out Hugo. It’s available in  
> MacPorts, but the Hugo site only mentions Homebrew, binary download and  
> building from source as installation options [1]. I think it might pay  
> off if maintainers would pay more attention to this.  
>  

This is a great idea. When a new port is added, the maintainer (or  
requester) should be encouraged to facilitate docs/instructions/notes  
upstream that the software is available in macports. (I wouldn't make it  
a requirement -- requirements can be perceived as draconian and keep  
people away.) Is there a place in the guide or wiki to say this? Maybe  
chapter 4 of the guide, "Portfile Development"?  

I'll work on retroactively doing this for the ports for which I am  
maintainer.  


> Nils.  
>  
> [0]  
> https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#getting-started-macports-cli-installation
>   
> [1] https://gohugo.io/getting-started/installing#pick-your-method  


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: xdmf I/O HDF5 linking error on MacOS: libhdf5.101.dylib not found

[Ruben Di Battista]

I updated to Mojave and the error vanished. :)

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 22 novembre 2018 a 11:37:11, Ryan Schmidt (ryandes...@macports.org) scritto:



On Nov 17, 2018, at 16:25, Ruben Di Battista wrote:  

> On 17 novembre 2018 a 03:24:40, Ryan Schmidt scritto:  
>  
>> On Nov 16, 2018, at 18:00, Ruben Di Battista wrote:  
>>  
>> > I tested again the build (with also rev-upgrade). No luck, same error. 
>> > Does anyone here can try to install: vtk +hdf5 +python27 +mpich to see if 
>> > it’s just a misconfiguration for me or it’s a general problem?  
>>  
>> Some file on your system that is being used by the vtk build is linked with 
>> /opt/local/lib/libhdf5.101.dylib. We need to identify that file and rebuild 
>> it so that it is linked with /opt/local/lib/libhdf5.103.dylib instead.  
>>  
>> That's what running "sudo port rev-upgrade" does, so I'm surprised that 
>> didn't fix the problem for you.  
>>  
>> Maybe rev-upgrade is failing, but isn't printing an error message. You could 
>> run it with debug output: "sudo port -d rev-upgrade".  
>>  
>> If the output doesn't look like an error is happening, then maybe the 
>> problem is that the file that is linked with 
>> /opt/local/lib/libhdf5.101.dylib is not in MacPorts, but the vtk build is 
>> finding it for some reason. (For example, maybe it is in /usr/local.) If so, 
>> you could use trace mode, which tells MacPorts to ignore any files not 
>> explicitly listed as dependencies: "sudo port clean vtk && sudo port -t 
>> install vtk +hdf5 +python27 +mpich".  
>  
> Thank you. I looked in all the computer and there is not any 
> libhdf5.101.dylib.  

Exactly. But some library or program on your computer is linked with that 
nonexistent file, which is what's causing the error message we're trying to 
solve. We need to identify what that file is. Did you try running "sudo port -d 
rev-upgrade"? Did any of its output mention libhdf5.101.dylib?  

> I also tried with the trace mode, but I got an error like “bin/ps operation 
> not permitted” before it reached the actual point where the previous error 
> was given.  

It's difficult to offer any recommendations for this without seeing more lines 
of the output.  

> Can I somehow overcome the sandboxing?  

I'm not sure. What makes you think the sandboxing is implicated in the problem? 
 



signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: xdmf I/O HDF5 linking error on MacOS: libhdf5.101.dylib not found

[Ruben Di Battista]

Ehi Ryan, 

Thank you. I looked in all the computer and there is not any libhdf5.101.dylib. 
I also tried with the trace mode, but I got an error like “bin/ps operation not 
permitted” before it reached the actual point where the previous error was 
given. Can I somehow overcome the sandboxing? 

Thanks!

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 17 novembre 2018 a 03:24:40, Ryan Schmidt (ryandes...@macports.org) scritto:



On Nov 16, 2018, at 18:00, Ruben Di Battista wrote:  

> I tested again the build (with also rev-upgrade). No luck, same error. Does 
> anyone here can try to install: vtk +hdf5 +python27 +mpich to see if it’s 
> just a misconfiguration for me or it’s a general problem?  

Some file on your system that is being used by the vtk build is linked with 
/opt/local/lib/libhdf5.101.dylib. We need to identify that file and rebuild it 
so that it is linked with /opt/local/lib/libhdf5.103.dylib instead.  

That's what running "sudo port rev-upgrade" does, so I'm surprised that didn't 
fix the problem for you.  

Maybe rev-upgrade is failing, but isn't printing an error message. You could 
run it with debug output: "sudo port -d rev-upgrade".  

If the output doesn't look like an error is happening, then maybe the problem 
is that the file that is linked with /opt/local/lib/libhdf5.101.dylib is not in 
MacPorts, but the vtk build is finding it for some reason. (For example, maybe 
it is in /usr/local.) If so, you could use trace mode, which tells MacPorts to 
ignore any files not explicitly listed as dependencies: "sudo port clean vtk && 
sudo port -t install vtk +hdf5 +python27 +mpich".  




signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: xdmf I/O HDF5 linking error on MacOS: libhdf5.101.dylib not found

[Ruben Di Battista]

Mmmmh, 

I tested again the build (with also rev-upgrade). No luck, same error. Does 
anyone here can try to install: vtk +hdf5 +python27 +mpich to see if it’s just 
a misconfiguration for me or it’s a general problem?

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 17 novembre 2018 a 00:58:27, Ryan Schmidt (ryandes...@macports.org) scritto:



On Nov 16, 2018, at 14:41, Ruben Di Battista wrote:  

> In any case I removed the local source, and re-did the selfupdate just to 
> check (but I had the branch of the local git repo rebased on upstream 
> master). No outdated ports. I’m quite sure it is not a problem of my local 
> misconfiguration...  
>  
> However I see that a patch was stripped off recently from hdf5… Could that be 
> related?  

It looks like the patch was removed at the same time that the port was updated 
to version 1.10.4, presumably because it is no longer needed with that version. 
 



signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: xdmf I/O HDF5 linking error on MacOS: libhdf5.101.dylib not found

[Ruben Di Battista]

Sorry, I replied fastly and did not see I was replying just to yourself :)

In any case I removed the local source, and re-did the selfupdate just to check 
(but I had the branch of the local git repo rebased on upstream master). No 
outdated ports.  I’m quite sure it is not a problem of my local 
misconfiguration...

However I see that a patch was stripped off recently from hdf5… Could that be 
related?

  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 16 novembre 2018 a 13:20:47, Ryan Schmidt (ryandes...@macports.org) scritto:

Let's keep the discussion on the mailing list.

On Nov 15, 2018, at 09:53, Ruben Di Battista wrote:

> Hello Ryan,
>
> I do not have any outdated port at the moment. I’m attaching the output of 
> the selfupdate verbose command.
>
> I do not generally switch ports around… It was just to see if with previous 
> version it was still compiling :)

The log showed you have two sources configured: one, a git clone of 
macports-ports on a branch called "vtk", and the other, our main rsync server. 
I'm not sure what order these are listed in in your sources.conf. The git clone 
was synced first, so maybe that means it's listed first in sources.conf. If so, 
that means anything in that git clone will supersede anything from the rsync 
server. Depending on what changes are on your "vtk" branch or how out of date 
it is, this may adversely affect how your ports build.

If you removed the git repo from your sources.conf, then you could check "port 
outdated" again.

You could also check if "sudo port rev-upgrade" fixes any problems.



signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: xdmf I/O HDF5 linking error on MacOS: libhdf5.101.dylib not found

[Ruben Di Battista]

I reswitched back to the new versions of hdf5. I manually upgraded netcdf and 
netcdf-cxx and recompiled vtk, but I get the same error at the same point. 

I do not understand if it’s a problem with vtk or with macports… o.O 

I also tried with the new netcdf-cxx4 port, but I get the same error 
unfortunately. 

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 15 novembre 2018 a 09:14:37, Ruben Di Battista (rubendibatti...@gmail.com) 
scritto:

Hello Ryan, 

Thanks for replying. I think I did my self update (when having a file:// local 
ports repository on the sources.conf, is there something to take care in 
addition to standard `sudo port self update`? Because I had the impression that 
sometimes I was not getting the updates properly…).

Indeed, however, I activated the old versions of hdf5 and netcdf-cxx, and the 
build proceeds correctly as expected. To me this looks related to 
hdf5/netcdf-cxx port… :/

I’ll try to investigate a bit more. 

  _
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 15 novembre 2018 a 04:33:19, Ryan Schmidt (ryandes...@macports.org) scritto:



On Nov 14, 2018, at 20:28, Ruben Di Battista wrote:

> Hello,
>
> Recently on Macports hdf5 (4.3.0) and netcdf packages were updated. 
> Recompiling vtk with xdmf support (and python27 bindings) returns me this 
> error:
>
> :info:build [ 78%] Python Wrapping - generating vtkFillHolesFilterPython.cxx
> :info:build cd 
> /opt/local/var/macports/build/_Users_***_git_macports-ports_graphics_vtk/vtk/work/build/Wrapping/Python
>  && ../../bin/vtkWrapPython-8.1 
> @/opt/local/var/macports/build/_Users_***_git_macports-ports_graphics_vtk/vtk/work/build/Wrapping/Python/vtkFiltersModelingPython.Release.args
>  -o 
> /opt/local/var/macports/build/_Users_***_git_macports-ports_graphics_vtk/vtk/work/build/Wrapping/Python/vtkFillHolesFilterPython.cxx
>  
> /opt/local/var/macports/build/_Users_***_git_macports-ports_graphics_vtk/vtk/work/VTK-8.1.1/Filters/Modeling/vtkFillHolesFilter.h
> :info:build ld: file not found: /opt/local/lib/libhdf5.101.dylib for 
> architecture x86_64
>
> Checking in the library folder (/opt/local/lib) I have not 
> `libhdf5.101.dylib`, but `libhdf5.103.dylib`. Where in the VTK’s 
> CMakeFiles.txt the actual HDF5 library version gets computed?
>
> Can you give me an hint on how I can try to fix this linking error? Seems to 
> be related to some “leftover” of the previous installation maybe… I tried a 
> port clean on vtk and hdf5 but I keep getting this error…

Make sure you have run "sudo port selfupdate" and "sudo port upgrade outdated" 
first.

When I tried to reproduce this problem on my system, I did get the same "file 
not found: /opt/local/lib/libhdf5.101.dylib" error, but when building 
netcdf-cxx. The problem was that MacPorts did not automatically upgrade netcdf 
first; the solution was upgrading netcdf manually. I don't know why MacPorts 
didn't do that; it should have, since it is listed as a dependency of 
netcdf-cxx.



signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: xdmf I/O HDF5 linking error on MacOS: libhdf5.101.dylib not found

[Ruben Di Battista]

Hello Ryan, 

Thanks for replying. I think I did my self update (when having a file:// local 
ports repository on the sources.conf, is there something to take care in 
addition to standard `sudo port self update`? Because I had the impression that 
sometimes I was not getting the updates properly…).

Indeed, however, I activated the old versions of hdf5 and netcdf-cxx, and the 
build proceeds correctly as expected. To me this looks related to 
hdf5/netcdf-cxx port… :/

I’ll try to investigate a bit more. 

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 15 novembre 2018 a 04:33:19, Ryan Schmidt (ryandes...@macports.org) scritto:



On Nov 14, 2018, at 20:28, Ruben Di Battista wrote:  

> Hello,  
>  
> Recently on Macports hdf5 (4.3.0) and netcdf packages were updated. 
> Recompiling vtk with xdmf support (and python27 bindings) returns me this 
> error:  
>  
> :info:build [ 78%] Python Wrapping - generating vtkFillHolesFilterPython.cxx  
> :info:build cd 
> /opt/local/var/macports/build/_Users_***_git_macports-ports_graphics_vtk/vtk/work/build/Wrapping/Python
>  && ../../bin/vtkWrapPython-8.1 
> @/opt/local/var/macports/build/_Users_***_git_macports-ports_graphics_vtk/vtk/work/build/Wrapping/Python/vtkFiltersModelingPython.Release.args
>  -o 
> /opt/local/var/macports/build/_Users_***_git_macports-ports_graphics_vtk/vtk/work/build/Wrapping/Python/vtkFillHolesFilterPython.cxx
>  
> /opt/local/var/macports/build/_Users_***_git_macports-ports_graphics_vtk/vtk/work/VTK-8.1.1/Filters/Modeling/vtkFillHolesFilter.h
>   
> :info:build ld: file not found: /opt/local/lib/libhdf5.101.dylib for 
> architecture x86_64  
>  
> Checking in the library folder (/opt/local/lib) I have not 
> `libhdf5.101.dylib`, but `libhdf5.103.dylib`. Where in the VTK’s 
> CMakeFiles.txt the actual HDF5 library version gets computed?  
>  
> Can you give me an hint on how I can try to fix this linking error? Seems to 
> be related to some “leftover” of the previous installation maybe… I tried a 
> port clean on vtk and hdf5 but I keep getting this error…  

Make sure you have run "sudo port selfupdate" and "sudo port upgrade outdated" 
first.  

When I tried to reproduce this problem on my system, I did get the same "file 
not found: /opt/local/lib/libhdf5.101.dylib" error, but when building 
netcdf-cxx. The problem was that MacPorts did not automatically upgrade netcdf 
first; the solution was upgrading netcdf manually. I don't know why MacPorts 
didn't do that; it should have, since it is listed as a dependency of 
netcdf-cxx.  



signature.asc
Description: Message signed with OpenPGP using AMPGpg

xdmf I/O HDF5 linking error on MacOS: libhdf5.101.dylib not found

[Ruben Di Battista]

Hello, 

Recently on Macports hdf5 (4.3.0) and netcdf packages were updated. Recompiling 
vtk with xdmf support  (and python27 bindings) returns me this error: 

:info:build [ 78%] Python Wrapping - generating vtkFillHolesFilterPython.cxx
:info:build cd 
/opt/local/var/macports/build/_Users_***_git_macports-ports_graphics_vtk/vtk/work/build/Wrapping/Python
 && ../../bin/vtkWrapPython-8.1 
@/opt/local/var/macports/build/_Users_***_git_macports-ports_graphics_vtk/vtk/work/build/Wrapping/Python/vtkFiltersModelingPython.Release.args
 -o 
/opt/local/var/macports/build/_Users_***_git_macports-ports_graphics_vtk/vtk/work/build/Wrapping/Python/vtkFillHolesFilterPython.cxx
 
/opt/local/var/macports/build/_Users_***_git_macports-ports_graphics_vtk/vtk/work/VTK-8.1.1/Filters/Modeling/vtkFillHolesFilter.h
:info:build ld: file not found: /opt/local/lib/libhdf5.101.dylib for 
architecture x86_64

Checking in the library folder (/opt/local/lib) I have not `libhdf5.101.dylib`, 
but `libhdf5.103.dylib`. Where in the VTK’s CMakeFiles.txt the actual HDF5 
library version gets computed? 

Can you give me an hint on how I can try to fix this linking error? Seems to be 
related to some “leftover” of the previous installation maybe… I tried a port 
clean on vtk and hdf5 but I keep getting this error… 


  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg