Re: Oops

[Vincent Habchi]

Hi Nicklas,

Thanks for your answer. Will definitely do during the upcoming weekend.

Cheers,
Vincent

Oops

[Vincent Habchi]

Folks,

I should definitely chime in, shouldn’t I.

I’ve been through thick and thin lately, but I’m going to find time and update 
the ports I’m responsible for. Pinkie promise.

Can just someone let me know what’s on my slate?

Thanks a bunch

Vincent

Re: Oops, apologies :/

[Vincent Habchi]

Thanks Frank,

For the time being I’m rebuilding my tree so as to be up to date.
I’ll resume update ports as soon as I’m on top of things.

Have a great weekend,
Vincent

Oops, apologies :/

[Vincent Habchi]

Folks,

I’d like to apologise for being totally absent of late. I’ve had a pretty rough 
year 2022, but fortunately things are quieting a little now so I’ll be able to 
snatch some time back to look after my ports.

Once again, I’m deeply sorry for the inconvenience I’ve caused.

Happy new year to all,
Vincent

Re: perl 5.34 branch

[Vincent Habchi]

Hi Ryan,

> Since perl has so many small modules that depend upon one another, it strikes 
> me as exceedingly difficult to manually come up with small batches of modules 
> that could be updated together.

This is true, of course. However, in the case of ffmpeg, for example, I was 
able to identify a subset of p5 ports that constitute a sort of closed subgroup 
of the whole family. Maybe that strategy might help.

Cheers,
Vincent

perl 5.34 branch

[Vincent Habchi]

Folks,

while trying to install ‘ffmpeg’ using perl5.34 as my base version, I stumbled 
on a slew of p5 ports which have not been updated to the 5.34 branch yet.

I did that manually, and now I’m left in my private tree with more than a score 
of modified p5 ports. Shall I commit them?

Thanks,
Vincent

Re: Detecting Apple Silicon (vs. legacy Intel)

[Vincent Habchi]

Hi Ryan,

> If you were asking how to do this within a Portfile, yes, that's how you 
> would do it. However, note that we don't want any Portfile to use -march 
> flags, no matter what architecture, unless within a variant called "native", 
> since -march flags enable features specific to some processor whereas we want 
> to produce binaries that could run on any processor.

That’s the case (in the ‘qhull’ and ‘gdal’ ports).

Also seizing the opportunity to wish you a terrific year 2022, to you and all 
the Macports wizards around!

Cheerio,
Vincent

Re: Detecting Apple Silicon (vs. legacy Intel)

[Vincent Habchi]

> On 31 Dec 2021, at 18:36, Chris Jones  wrote:
> 
>> I was wondering if there is a simple scheme to detect on which type of 
>> architecture MacPorts is running. My problem here is that clang on M1 does 
>> not honour the -march flag and exits with an error.
> 
> if {${os.arch} eq "arm"} {
> …
> }

Thanks Chris!
Have a great evening and a wonderful 2022 (let’s hope that this sentence still 
makes sense…)

Vincent

Detecting Apple Silicon (vs. legacy Intel)

[Vincent Habchi]

Folks,

finally put my hands on my brand new MacBook Pro 14”! (Well, not really mine, 
rather my company’s, but let’s pretend…)

I was wondering if there is a simple scheme to detect on which type of 
architecture MacPorts is running. My problem here is that clang on M1 does not 
honour the -march flag and exits with an error.

Thanks and early happy new year to all!

Vincent

Re: GitHub Sponsors

[Vincent Habchi]

> 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

Re: GitHub Sponsors

[Vincent Habchi]

My lords,

> On 10 Nov 2021, at 21:33, Perry E. Metzger  wrote:

[…]

You can also consider registering the MacPorts association outside the US, e.g. 
(I don’t toot my own horn, it’s just an example I’m familiar with) in France, 
associations are tax-exempt, and, barring the need of one local person to 
handle all the bootstrap paperwork (like opening an account, registering the 
association and so on), members can live anywhere in the world.

The sole condition is to be non-for-profit™.

That maybe also the case in other, nearer countries to you Yankee folks :p, 
like, say, Canada.

Vincent

perl 5.34 branch

[Vincent Habchi]

My lords,

is there any plan to add the 5.34 branch to all p5- ports? I’ve done it locally 
in order to install ffmpeg on my legacy MacBook, but I think it would be nice 
to generalise it.

Have a great weekend,

Vincent

Re: New project member: judaew

[Vincent Habchi]

> Thank you, I am pleased to see these words. I'm pleased to be here.
> It's my first message on the Mailing List. I hope I did everything right to 
> send the message.

No worries.
Welcome on board and lots of fun to come, I hope!

Vincent

Re: upgrade to openssl 3.0.0

[Vincent Habchi]

> On 5 Oct 2021, at 20:10, Daniel J. Luke  wrote:
> 
> I suspect if we wait, we'll just end up doing this same thing later - so 
> might as well get it over with now. The sooner we get to a state where 
> (mostly) things all work with the latest openssl, the better.

Just my tuppence:

While I usually agree with that politics (don’t defer until tomorrow that which 
you can do today), please don’t forget that the official release of MacOS 12 
‘Monterey’ is about to be announced, so both would more or less clash. It might 
be wise to delay the upgrade to 3.0.0 once everyone has upgraded to the new 
version (or at least, a couple of weeks after).

Vincent

And I apologise dearly if someone has already raised this point, I simply don’t 
feel like reading the thread from the get-go :p :S 

Re: Why does Texinfo explicitly depend on perl 5.30?

[Vincent Habchi]

Hey Mojca,

> My personal guess: no special reason other than trying to use a newer
> version given that it was available.
> It's a bit unfortunate if some ports use one version and others
> another, but in particular 5.30 is already obsolete.

Couldn’t the Portfile be modified in order to comply with the version the user 
has given in the perl5 metaport?

Vincent

Why does Texinfo explicitly depend on perl 5.30?

[Vincent Habchi]

Well, all is said in the subject :)

Cheers,
Vincent

Shutting down the Atlas port

[Vincent Habchi]

Guys,

Atlas, the software meant to provide scientific computing tools with a 
high-performance assembly-based library has, IMHO, reached its end of life. 

My case is this:

• Last developer (unstable) release is more than two years old;
• Last stable release is twice older (2016);
• Consequently, ASM snippets Atlas relies on might not be up to date with the 
latest Intel processors;
• Atlas will prolly never be ported to the new ARM-based architecture Apple is 
about to unveil;
• The method used by Atlas to select the best assembly snippet (a.k.a “kernel”) 
for a given computation task is defeated by the power saving steps included in 
recent versions of MacOS, namely a gradual lowering of the priority of any 
power consuming task. This can lead to erratic, non-reproducible, and 
sub-optimal choices, rendering Atlas pointless;
• Atlas build time from sources varies around 3 to 4 hours, regardless of the 
number of cores available (the selection process is mono-threaded), which makes 
Atlas cumbersome to build, and still more cumbersome to debug, barring on the 
quickest machines;
• Since Atlas is CPU-based, no precompiled binaries should be available: at 
best, they will be suboptimal; at worse, they could contain unknown 
instructions old CPUs would crash on.

For all these reasons, I’m convinced that pulling the plug on Atlas is a good 
idea. Any thoughts?

Thanks,
Vincent

Re: Thoughts on switching our archive compression method

[Vincent Habchi]

Ryan,

> Maybe, but if we could use something built into macOS, like xz on 10.9 and 
> later, then we wouldn't need to bundle yet another third-party project (the 
> decompression program) into MacPorts base.

Sure, but if the ultimate goal is to reduce disk size and bandwidth, then it 
can be worth bundling a decompression utility with the base, given it yields 
better compression ratios. Also, if that utility compiles on MacOS < 10.9, that 
means we could have a single compression process for all the OS versions we 
package for.

Vincent

Re: Thoughts on switching our archive compression method

[Vincent Habchi]

> (xz is 85% of bz2 size)
> (xz is 70% of bz2 size)
> (xz is 57% of bz2 size)
> 
> So I think we could save ourselves and our mirror providers, CDN, and users 
> some disk space and bandwidth by switching to xz. bz2 was the best available 
> built-in compression on Mac OS X 10.6 when we started doing binary archives 
> but there are better options now.

I agree wholeheartedly, but since you mention modern compression algorithms, 
isn’t there another one (or more) which would be yet more efficient than xz?

Vincent

Re: macOS 11 and Apple Silicon

[Vincent Habchi]

> On 22 Jun 2020, at 22:19, Jeremy Huddleston Sequoia  
> wrote:
> 
> I just pushed some changes to base/master and dports/master to better support 
> macOS 11 and Apple Silicon, but there's quite a bit of work ahead of us.

[…]

>  Please reach out if you have any questions or concerns.

We’re undoubtedly heading into a turbulence zone. Because not all of us will 
have early access to the new hardware (I won’t personally, and happen to have 
ordered the latest MacBook Air with an i7 CPU a few days ago…), it means that 
those who will will probably have to bear the burden of testing a lot of ports 
and reporting errors, while the maintainers won’t have the ability to test the 
fixes.

Wouldn’t it be possible to somehow set up a new hardware machine with MacPorts 
installed and give all maintainers the possibility to log into it and test 
their ports?

V.

Re: Proper value for os.arch on Apple Silicon

[Vincent Habchi]

Ryan,

> Now that Apple has announced that Macs will have ARM processors [1], what is 
> the proper value for ${os.arch} on such systems?

It should be noted that, apparently (I didn’t follow the keynote), the Apple 
staff never referred to the new arch as “ARM”, but used “Apple silicon”.

So why not simply adopt the name “apple”?

Vincent

OpenCL and sqlite3 incompatibilities

[Vincent Habchi]

Folks,

Just to inform you, after digging into this, that the legacy OpenCL framework 
some ports may use and Macport’s sqlite3 are incompatible. The OpenCL 
framework, as farfetched as it seems, pulls in the system provided 
/usr/lib/libsqlite3.dylib, which causes, if Macport’s sqlite3 is also required, 
a duplication of symbols leading to unpredictable behaviour and mostly crashes.

So if you’re stuck on a bug that happens within sqlite3, it’s worth having a 
look at this.

Cheers,
Vincent

Re: trying to understand the --no-exec activate option (on by default?)

[Vincent Habchi]

> That warning only prints during an install or upgrade (when the runtime dep 
> is not active).
> 
> The default for this option should be OFF IMHO; there are also ports which do 
> important things in the post-activate; the lldb ports remind the user that an 
> executable needs to be code-signed for instance. Evidently this has to be 
> done each time the port is (re)activated.

Why not use the “note” keyword for that? Just wondering (hoping that makes 
sense)

Vincent

Re: Xcode configuration woes

[Vincent Habchi]

Chris,

> On 21 Nov 2018, at 10:12, Chris Jones  wrote:
> Do as you like, but I suspect /usr/include being missing is not a bug but 
> intentional.

I didn’t mean that. I mean the fact that when /usr/include exists, it is filled 
with outdated include files.

Vincent

Re: Xcode configuration woes

[Vincent Habchi]

Oops, also:

>> Ok, I set configure.sdkroot and it worked fine now. Should I commit it with:
>> 
>> if {${os.platform} eq "darwin" && ${os.major} == 18} {
>>  configure.sdkroot …
>> }
>> 
>> ?
> 
> 
> If this code only gets compiled on 10.14, then that would work. But do you 
> think (or have you tested if) this code will compile on 10.13 or earlier 
> without the 10.14 SDK?

I don’t have a clue. All my boxes run 10.14, so I have no other way to tell 
than submitting it and finding out how it compiles on the various buildbots. 
Talk about shooting in the dark… :P 

Vincent

Re: Xcode configuration woes

[Vincent Habchi]

Ryan,

Did you file a bug report with Apple w/r to that, or do you want me to go ahead?

> I've updated the buildbot machine, and it also still doesn't have 
> /usr/include. But I also haven't installed the command line tools there. 
> Maybe if I did that, /usr/include would now show up.

Vincent

Re: Xcode configuration woes

[Vincent Habchi]

Ryan,

> Unless you do have /usr/include on your system. Do you? For users who have 
> installed /usr/include using the hidden installer package, you might need to 
> have the port set configure.sdkroot to the path of the SDK, even when 
> MacPorts wouldn't otherwise have done so.

Ok, I set configure.sdkroot and it worked fine now. Should I commit it with:

if {${os.platform} eq "darwin" && ${os.major} == 18} {
configure.sdkroot …
}

?

Thanks,
Vincent

Re: Xcode configuration woes

[Vincent Habchi]

Ryan,

> I don't know why Apple is doing this to us. This contradicts what we 
> previously knew about how SDKs were meant to function. The SDKs are supposed 
> to be the same as the system headers of a particular version. We may want to 
> file a bug report with Apple about this. Maybe then they will fix it in a 
> future version of Mojave.

Do you want to proceed as a member of the Apple team, or do you prefer me to do 
so?

> Unless you do have /usr/include on your system. Do you? For users who have 
> installed /usr/include using the hidden installer package, you might need to 
> have the port set configure.sdkroot to the path of the SDK, even when 
> MacPorts wouldn't otherwise have done so.

Yes, I do. I was not even aware I shouldn’t. TBH, I don’t even remember using a 
“hidden” installer package. 
I will follow your advice and set configure.sdkroot in macports.conf

Thanks for your help, Ryan, as always!

Vincent

Re: Xcode configuration woes

[Vincent Habchi]

Chris,

> On 9 Nov 2018, at 21:12, Chris Jones  wrote:
> 
>> I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1, 
>> the production release. 
>> Also that doesn’t explain why the headers in /System/Library/Frameworks are 
>> one version behind…
> 
> I disagree. You are running a beta OS. Anything is possible.

That’s a bit of a blanket statement, no? :P 

Cheers,
Vincent

Re: Xcode configuration woes

[Vincent Habchi]

Chris,

> 
> Isn't it obvious ? Beta releases are more likely to have problems…

I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1, 
the production release. 
Also that doesn’t explain why the headers in /System/Library/Frameworks are one 
version behind…

V.

Re: Xcode configuration woes

[Vincent Habchi]

>> Weird, no?
> 
> Not necessarily. You are running beta versions. Anything is possible.
> 
> Do you really need do this ? Wouldn't switching to the production version not 
> make sense now ?

How do you mean?

V.

Re: Xcode configuration woes

[Vincent Habchi]

Ryan,

> Yup, NSAppearanceNameDarkAqua is new in macOS 10.14.
[…]

> So you must be on macOS 10.13 with Xcode 10.

Unfortunately not : 
> uname -a
Darwin Air.local 18.2.0 Darwin Kernel Version 18.2.0: Sat Nov  3 12:30:49 PDT 
2018; root:xnu-4903.231.1~11/RELEASE_X86_64 x86_64

As you can see, I even run a beta of 10.14.2.

Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/
total 43720
-rwxr-xr-x1 root  wheel  47503104  4 Nov 09:31 AppKit
-rw-r--r--1 root  wheel309176 25 Jul 18:33 AppKit.tbd
drwxr-xr-x  259 root  wheel  8288 25 Jul 18:33 Headers
drwxr-xr-x3 root  wheel96 25 Jul 18:33 Modules
drwxr-xr-x   77 root  wheel  2464  7 Nov 22:57 Resources
drwxr-xr-x8 root  wheel   256 21 Sep 05:59 XPCServices
drwxr-xr-x3 root  wheel96  7 Nov 22:57 _CodeSignature

Air > ls -l 
/System/Library/Frameworks/AppKit.framework/Versions/Current/Headers/
total 1328
-rw-r--r--  1 root  wheel  301352 15 Mar  2018 AppKit.apinotes
-rw-r--r--  1 root  wheel8613 15 Mar  2018 AppKit.h
-rw-r--r--  1 root  wheel1920 15 Mar  2018 AppKitDefines.h
[…]

All headers here are dated 15 Mars 2018, and are obviously 10.13 versions.

I have Xcode 10.1 installed, and:

Air > xcode-select --install
xcode-select: error: command line tools are already installed, use "Software 
Update" to install updates

Weird, no?

Vincent

Xcode configuration woe

[Vincent Habchi]

Folks,

I try to update QGis to 3.4.1, and stumble on that compilation error:

—
/opt/local/var/macports/build/_macports-ports_gis_qgis3/qgis3/work/QGIS-3_4_1/src/native/mac/qgsmacnative.mm:125:18:
 error: property 'effectiveAppearance' not found on object of type '__kindof 
NSApplication *'
  return ( NSApp.effectiveAppearance.name == NSAppearanceNameDarkAqua );
 ^
/opt/local/var/macports/build/_macports-ports_gis_qgis3/qgis3/work/QGIS-3_4_1/src/native/mac/qgsmacnative.mm:125:46:
 error: use of undeclared identifier 'NSAppearanceNameDarkAqua'; did you mean 
'NSAppearanceNameAqua'?
  return ( NSApp.effectiveAppearance.name == NSAppearanceNameDarkAqua );
 ^~~~
 NSAppearanceNameAqua
/System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h:56:38: note: 
'NSAppearanceNameAqua' declared here
APPKIT_EXTERN NSAppearanceName const NSAppearanceNameAqua 
NS_AVAILABLE_MAC(10_9);
 ^
—
Alright, when I look at the file 
/System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h, I get:

-rw-r--r--  1 root  wheel  2699 15 Mar  2018 
/System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h

Which means that file is one release behind (10.13 instead of 10.14). However

-rw-r--r--  1 root  wheel  3721 16 Oct 07:20 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h

Is correct. Question: how to make clang use that header instead of the one 
installed in /System? Also, did I miss something?

Thanks,
Vincent

Re: Merging pull requests before 72 hours

[Vincent Habchi]

> That's one of things our existing 72-hour timeout period is for. It's not 
> specific to patchfiles; it's for any issue that the maintainer hasn't 
> responded to.

Okay, thanks Ryan :)

Re: Merging pull requests before 72 hours

[Vincent Habchi]

> On 22 Oct 2018, at 06:32, Ryan Schmidt  wrote:
>> And yes, we have a huge number of people assigned as maintainers who
>> no longer maintain the ports. We really need to clean up the list in
>> order to reflect the reality.
> 
> It is indeed a problem that we have many ports which claim to be maintained 
> by someone who does not do so. We should clarify for contributors, maybe by 
> rewriting the section of the guide, what being a maintainer means. We should 
> not pressure people into maintaining a port, just because they submitted it. 
> They should enter into the maintenance commitment voluntarily and with full 
> knowledge of what we expect from them in return. We should also do a better 
> job of pointing out that if someone is no longer able to maintain a port, 
> they should let us know as soon as possible, so that we can remove them; too 
> many people leave without telling us they're doing so.

I’m not sure I’ve anything meaningful to add here, but there should also be an 
official timeout guideline for tickets which include a patch. If, say, the 
maintainer doesn’t react within a “reasonable amount of time”, by which I mean 
a couple of days, a week at most, then anyone else should be allowed to go 
ahead and commit rather than let the process stall. That would probably ease 
the flow rather than clog it. 

Just my tuppence, and, as usual, I’m not sure it’s even worth it.

Cheers, Vincent

Launchctl script

[Vincent Habchi]

Folks,

I’m currently writing a Portfile for Strongswan, the IKEv2 VPN client/server.

I’d like the demons ipsec and charon to be launched through launchctl. Is there 
a way to automatically write the required script, or must I do that by hand?

Thanks a bunch, have fun everyone

Vincent

Re: Adding a Code of Conduct to MacPorts

[Vincent Habchi]

> On 28 Sep 2018, at 03:52, George Plymale II  
> wrote:
> 
> Linux is arguably "capsizing" right now, to some extent. The drama
> that's going on, between threats of lawsuits, possible forks, and
> kicking out longtime leaders in the project... well, I'd say that
> "capsizing" is perhaps an appropriate term. They're certainly facing
> some turmoil that they haven't seen for a long time, if ever.
> 
> There was also Opal, of whom I was a member in the community. I

I was also referring to Python, from which Guido Van Rossum, its creator, 
recently withdraw over bitter fights about what was to be committed or not. 
Guido explicitly mentioned insults and other rudenesses being exchanged between 
developers, which, he said, “was the last straw”.

Vincent

Re: Adding a Code of Conduct to MacPorts

[Vincent Habchi]

> In my experience, we in MacPorts-land don't have the obvious Linux issue. I 
> hope others don't experience the MacPorts project (developers, users, 
> commenters) as abusive in any medium (email lists, tickets / issues, PR's, in 
> person, whatever). - MLD

In my experience :), when a project feels the necessity to adopt a code of 
conduct, that means it is on the verge of capsizing. Between people of good 
will, there is no need for such a thing: good behavior is just common sense.

Vincent

Re: 2.5 and cxx_stdlib

[Vincent Habchi]

Josh,

> Not sure how you ran into that. Installing the new version of base must
> be done as root as well, and it runs scripts that open the registry and
> should trigger that upgrade.

Transcript from my terminal:

Air > sudo port selfupdate
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.4.1 installed,
MacPorts base version 2.5.0 downloaded.
--->  Updating the ports tree
--->  MacPorts base is outdated, installing new version 2.5.0
Installing new MacPorts release in /opt/local as root:admin; permissions 0755

Air > port outdated
sqlite error: attempt to write a readonly database (8) while executing query: 
ALTER TABLE registry.ports ADD COLUMN cxx_stdlib TEXT
 while executing
"registry::open $db_path"
 (procedure "mportinit" line 664)
 invoked from within
"mportinit ui_options global_options global_variations"
Error: /opt/local/bin/port: Failed to initialize MacPorts, sqlite error: 
attempt to write a readonly database (8) while executing query: ALTER TABLE 
registry.ports ADD COLUMN cxx_stdlib TEXT


Vincent

Re: 2.5 and cxx_stdlib

[Vincent Habchi]

> Just a reminder that MacPorts 2.5 will check whether ports are built
> against the right C++ standard library as part of rev-upgrade. The

Also, as part of this new check, a column is added to the registry, so please 
be sure to run a first ‘port outdated’ or whatever using sudo, otherwise you 
get an error message telling you the registry is read only and cannot be 
altered.

Vincent

Re: [MacPorts] #55764: geoexpress-sdk @9.0.0.3864: upgrade to 9.5.4.4709

[Vincent Habchi]

Hi,

> On 25 May 2018, at 16:47, Ryan Schmidt  wrote:
> On May 25, 2018, at 08:54, Rainer Müller wrote:
>> 
>> We already have ports with other restrictive licenses in the tree, even
>> closed-source software. Set the license option accordingly and make sure
>> we are allowed to mirror and redistribute files (otherwise also add the
>> "NoMirror" license).
> 
> It already does set license Restrictive NoMirror.
> 
>> 
>> One possible way to handle download restrictions could be a pre-fetch {}
>> phase that checks for the existence of the distfile and prints an
>> explanation how to obtain it if it does not exist yet.
> 
> It already does that too.

That’s right. My question was mainly rhetoric. Sorry for the noise and thanks 
for answering.

Vincent

Re: [macports-ports] branch master updated: gdal: more cleaning up

[Vincent Habchi]

Ryan,

> This should be:
> 
> if {[string match *clang* ${configure.cxx}]} {
>   configure.ldflags-append -stdlib=${configure.cxx_stdlib}
> }
> 
> Only clang understands the -stdlib flag, but you always want to use it, 
> regardless of what the C++ stdlib is.

I’ve changed that in the newest revision of the port file. Thanks.

Re: [macports-ports] branch master updated: qgis3: bump to 3.0.3

[Vincent Habchi]

> Yeah, apparently there’s only one version of QT installable at a time. It was 
> part of an experiment, and I forgot to remove it. I’ll do it straight away. 
> Thanks.

Done. Anyway, the purpose of this variant was to explore if the recurrent 
crashes were caused by using Qt 5.10 as opposed to 5.9. Turns out it wasn’t the 
case, so the variant is pointless anyway.

Re: [macports-ports] branch master updated: qgis3: bump to 3.0.3

[Vincent Habchi]

On 22 May 2018, at 13:42, Ryan Schmidt  wrote:
> 
> 
> On May 22, 2018, at 04:40, Vincent wrote:
>> +variant qt59 description "Build with qt59" {
>> +depends_lib-delete  port:qt5-qtwebkit \
>> +port:qt5-qtscript \
>> +port:qt5-sqlite-plugin \
>> +port:qt5-qtscxml \
>> +port:qt5-qtxmlpatterns
>> +
>> +depends_lib-append  port:qt59-qtwebkit \
>> +port:qt59-qtscript \
>> +port:qt59-sqlite-plugin \
>> +port:qt59-qtscxml \
>> +port:qt59-qtxmlpatterns
>> +}
> 
> I don't think this variant can work. I note the dependencies on qwt-qt5 and 
> qjson-qt5 and other ports above, which each depend on qt5-* ports, and the 
> qt5-* and qt59-* ports conflict.

Yeah, apparently there’s only one version of QT installable at a time. It was 
part of an experiment, and I forgot to remove it. I’ll do it straight away. 
Thanks.

Re: [macports-ports] branch master updated: charls: initial commit

[Vincent Habchi]

> Ah, it's because you specified the GitHub project name as "charLS" but the 
> project name is actually "charls". Fix this in the github.setup line, and 
> then you can remove the unnecessary name and worksrcdir lines.

Right. Changed it and committed again. Thanks a bunch.

Yeah, the message is pretty obscure. I will dig into this later when I have 
five minutes.

Thanks again,
Vincent

Re: fltk-devel has non-numeric revision

[Vincent Habchi]

> Version can contain non-numeric characters, but revision must be an
> integer. The qt59 portfile is extremely complicated, but qt59-qtwebkit
> seems to have a revision of 1 for me, so check for local changes perhaps?

Ok, gotcha. I had introduced an extra line in the qtwebkit subpart before the 
revision line. It seems the portfile takes the 9th line after the opening brace 
to be the revision line, whatever this line holds. Not really intuitive.

Thanks Josh!
Vincent

Re: fltk-devel has non-numeric revision

[Vincent Habchi]

In fact, the culprit is this:

Air > port installed | grep qt59-qtwebkit
  qt59-qtwebkit @5.9.1_1
  qt59-qtwebkit @5.9.1_overrides: (active)

Any idea what can cause this?

V.

fltk-devel has non-numeric revision

[Vincent Habchi]

Hi there,

the latest version of ftlk-devel is “1.4.x-r12914”. The “x” here causes the 
following error in “port outdated”: “process_cmd failed: can't use non-numeric 
string as operand of "-"”. Somehow base compares versions using a subtraction, 
and of course it can’t do that if there are non-numeric chars.

Vincent

Re: Qt5 port group

[Vincent Habchi]

Sorry to chime in back so late, I had several hiccups with my mail lately, and 
most (if not all) of your messages simply remained in transit until today.

As far as I have experimented, a single version of Qt is allowed to be 
installed. Fair enough.

I’ve rewritten the Qgis3 port introducing a +qt59 variant. I think what can be 
done could be something like:

Variant qt59 conflicts … {
depends-lib-append  qt59- (list of libraries)
}

using explicit qtXX- dependencies.

Or, if we want to spare space:

Variant qtXX conflicts qtYY … {
set qt_version XX
}
…
Depends-lib_append qt${qt_version}-… 

The port group could be modified to check variants are compatible with MacOS X 
versions, so e.g. requesting Qt 5.9 on Snow Leopard would result in an error.

Vincent

Qt5 port group

[Vincent Habchi]

Hi there,

I was in the process of modifying the Qt5 Port group to allow for choosing the 
Qt version one wants to link an application against using variants. However, 
before I go further, I’d like to know if concurrent installations of different 
Qt5 versions are supported in MacPorts. If not, what I do is just futile.

Thanks a bunch,
Vincent

Re: Using qt59 instead of qt5 (latest release)

[Vincent Habchi]

Hey Craig,

> I am considering a similar move for mythtv.28.  

[…]

Thanks for that useful info. French has a saying which goes like this (more or 
less, it’s difficult to translate): “The best is oftentimes the good’s enemy”.
In any case, yeah, I suppose this will mean at least writing variants. What I 
am more weary of is py-qt5. I hope the latest version is backwards compatible 
with earlier releases of Qt5.

Probably going to do that later in the week.

Once again, thanks for chiming in.

Have a great day!
Vincent

Using qt59 instead of qt5 (latest release)

[Vincent Habchi]

Hi there,

I recently wanted to experiment with linking one of the ports I maintain 
(Qgis3) with QT 5.9, if only to find out if 5.10 wasn’t the source of all the 
glitches and crashes everyone experiences with that application. 

However, in order to do so, I’d have to rebuild several dependents such as 
py36-qt5 or qwt-qt5 (inter alia). Are those able to deal with a Qt5 version 
other than the last one?

TIA,
Vincent

Heads-up: PROJ

[Vincent Habchi]

Hey there,

I’m going to commit a major overhaul to the “proj” port. Currently, “proj” is 
split between proj47 and proj, the latter corresponding to proj 5.0.0 recently 
released.

The problem is this:

• Proj 5.0.0 is buggy, unusable at least with QGis until a bugfix version is 
out;
• Proj and proj47 can be installed together, but since proj installs its files 
in ${prefix} whereas proj47 does in ${prefix}/lib/proj${version}/…, even if 
proj47 location is specified in the Portfile, because of the order in which -I… 
include paths are emitted at compile time, the compiler ends up seeing always 
proj include files instead of proj47;
• Proj47 is obsolete, latest proj4 version is 4.9.3.

What I am going to do:

• Rename proj47 port into proj4 and update it to proj 4.9.3;
• Change the proj Portfile so that it installs files in ${prefix}/lib/proj5, in 
such a way that both proj4 and proj(5) can be used simultaneously without 
conflicting;
• Update all portfiles that currently depend on proj → proj4, until a suitable 
proj 5 bug fix version is released.

What I could do:

• Rename proj into proj5. Does anyone objects to this?

Cheers
Vincent

Re: 10.13 builder on our BuildBot is failing

[Vincent Habchi]

Ryan,

> as suggested in the thread. Thanks for pointing me toward it!

Glad to know it worked.

Have a great day!

Re: 10.13 builder on our BuildBot is failing

[Vincent Habchi]

Ryan,

so what was the problem?

Vincent

Re: 10.13 builder on our BuildBot is failing

[Vincent Habchi]

Ryan,

> Granted we're running VMware ESXi on it and the VMs are seeing VMware's 
> emulated graphics card, but everything was working before it unaccountably 
> blew up.

I’d say that before you stumble on a problem generally everything works fine. 
:P That being said, there was a hack listed somewhere in the messages that 
consisted of booting single user and touching a driver. Did you try that? It 
can’t do any harm to try and test.

Vincent 

Re: 10.13 builder on our BuildBot is failing

[Vincent Habchi]

Maybe that can help? 
https://www.tonymacx86.com/threads/macos-high-sierra-ioconsoleusers-gioscreenlockstate-3-hs-0-bs-0-now-0-sm-0x0.234731/

Re: 10.13 builder on our BuildBot is failing

[Vincent Habchi]

> On 11 Jan 2018, at 16:36, Ryan Schmidt  wrote:
> 
> IOConsoleUsers: time(0) 0->0, lin 0, llk 1, 
> IOConsoleUsers: gIOScreenLockState 3, hs 0, bs 0, now 0, sm 0x0
> 
Looks like a video issue?

Vincent

Re: 10.13 builder on our BuildBot is failing

[Vincent Habchi]

Ryan,

> It does not seem to boot up correctly now. The black startup screen with 
> white Apple logo and progress bar filled all the way in never disappears. I'm 
> not certain if all the usual services have started up correctly.
> 
> I can ssh in. I deactivated all the ports that had been left active. Many 
> ports' files were still present and had to be removed by forcibly activating 
> and then deactivating the ports. I think I got them all.
> 
> I will need to do some further investigating.

Can you do a dmesg?

Vincent

Re: Python 2.7 – allow another db version beside 4.8

[Vincent Habchi]

On 25 Dec 2017, at 20:30, Jan Stary  wrote:

> Generally, I tend to let the port/package use any version,
> unless there is a specific reason for some specific version.
> For example, if a port requires Python, then I consider
> _any_ installed python to satsfy this requirement,
> unless there is a reason it has to be python36 (or whatever).
> 
> What is the right way to state this in a Portfile?

I’m not sure. You could use a file dependency instead of a port one, assuming 
every version installs the same set of files.

Also, you can write a script that uses the TCL instruction glob to find out 
what version of a file is installed, given that the filename is composed of a 
stem and an extension that varies according to the version. If there’s no file, 
then you can decide to install whatever default version you deem fit.

But I’m not 110% sure it’s standard practice though.

Re: Python 2.7 – allow another db version beside 4.8

[Vincent Habchi]

Folks,

happy Xmas to all!

> On 24 Dec 2017, at 11:23, Jan Stary  wrote:
> 
>> On Dec 24 05:19:35, j...@macports.org wrote:
>>> On 2017-12-24 04:28 , Clemens Lang wrote:
>>> Is there a reason to not just always use a newer version?
>> And to turn the question around, what is gained by using the newer version?
> 
> Exactly.
> 
> Insisting on the newest version of everything
> has cost me countless hours of comutation spent on nothing
> except "having the newest version" (with the newest bugs).

Well my initial request was not about using the last version, but being able to 
choose one version and stick to it through multiple ports that depend thereon. 
I have a 128 GB SSD, and I’d rather not squander space with installing 
different versions of the same software for no reason except that the Portfile 
doesn’t offer the possibility to pick the version I want.

That’s all. Peace! :)

Vincent

Python 2.7 – allow another db version beside 4.8

[Vincent Habchi]

Hi there,

I’ve a made a private change to my python27 Portfile to allow it to use DB60 
instead of the default DB48, which was installed only for its needs. I think 
allowing people (through a variant) to build a Python 2.7 version which relies 
on another version of DB would be nice.

Happy Xmas to all!
Vincent

QtKeyChain

[Vincent Habchi]

Hey Mac-mavens,

could someone add the aforementioned software to our plethoric but not enough 
collection of coddled ports? Or shall I proceed on my own?

Thanks and enjoy the weekend!

Vincent

Re: Cmake, Xcode 9, MacOS 10.13 and utimensat

[Vincent Habchi]

Hi Ryan,

> cmake likes to compile using the macOS SDK in Xcode, even when that's not 
> needed. What version of macOS SDK is in Xcode 9? I would not be surprised if 
> it contains a macOS 10.13 version of the SDK, and that utimensat is new in 
> macOS 10.13, and that there is a bug in the SDK that neglects to hide that 
> symbol when the deployment target is less than 10.13. If so, that would be an 
> Apple bug.

Absolutely. Except that I checked in the libraries installed by MacOS 10.13 
beta, and there is no such symbol. At least not in the libraries where the 
symbol is expected to be.

Reason why I was, how to say, flabbergasted? :)

I’ll fill a bug report.

Vincent

Cmake, Xcode 9, MacOS 10.13 and utimensat

[Vincent Habchi]

Guys,

I’ve been installing the new Xcode 9 (beta) and upgrading my ports.
Cmake got bumped to 3.8.2

Then, a couple of ports onwards, I got this error:

> dyld: Symbol not found: _utimensat
>   Referenced from: /opt/local/bin/cmake
>   Expected in: /usr/lib/libSystem.B.dylib

Rolling back to the log of Cmake compilation, I found:

> Checking whether CXX compiler has utimensat - yes

Problem is, I can’t find that routine in libSystem.B.dylib, neither in 10.12 
nor in 10.13.

So I’m a bit at a loss here. Could that be a bug in Xcode?

Thanks for any piece of advice,
Vincent

PS : I’m going to uninstall Cmake and reinstall it from binaries.

Re: Why does libunistring depends on texlive?

[Vincent Habchi]

Josh,

thanks for the pointer. What I’ll do (since texlive seems to be required only 
to build the doc) is to add a doc variant that will pull the dependencies in 
but only when required.

However, I’m not sure how to build the docs :) So I guess I’ll have to dredge a 
bit deeper.

Thanks again,
Vincent

Why does libunistring depends on texlive?

[Vincent Habchi]

Folks,

I was in the process of upgrading ffmpeg when I suddenly jumped out of my 
chair: the build was trying to pull in the bloated texlive source. 

I traced that spurious dependency to libunistring. Commenting out the 
dependency on texlive-basic does not produce any side effect (AFAIK): the 
package compiles and installs fine.

Since libunistring has no official maintainer, I’m going to push my Portfile 
version unless someone objects to it.

Cheers,
Vincent

LLVM/CLANG enable specific targets with varants

[Vincent Habchi]

Folks,

I’ve always wondered what’s the point in letting LLVM/Clang ports build all 
possible CPU targets. Some of them are really obscure, and I don’t think the 
commoner needs them (e.g. Hexagon). So I think, given the extra time needed to 
compile all those superfluous targets, it’d be a nice idea to restrict the 
default targets to X86 and/or PowerPC and to add a variant to let people who 
mind build the other targets too. 

What do you think?

Cheers!
Vincent

Packaging an app

[Vincent Habchi]

Folks,

I’m trying to create a redistributable binary of grass7. I just read the 
relevant webpage on the Macports website. 

Questions:

• How to choose a suitable prefix? Any heuristics? Just a shot in the dark?
• Must I recompile everything from source, or can I use binaries?

Thanks!
Vincent

Re: [macports-ports] branch master updated: grass: jump to 7.2RC2 (dubbed 7.1.99.2)

[Vincent Habchi]

Ryan,

sorry I didn’t see this before:

>>grass: jump to 7.2RC2 (dubbed 7.1.99.2)
> 
> Does upstream also refer to 7.2.0RC2 as 7.1.99.2, or is that something you 
> made up? If the latter, why?

No, upstream’s name is RC2. But 7.1.99.2 would easily upgrade to 7.2.0 when it 
is released, whereas I’m unsure what version number I should use, should I 
decide to keep the RC denomination.

If there’s a definite policy here, please let me know, I’ll be happy to 
implement it.

Happy Christmas Ryan!
Vincent

Re: Apache 24 woes

[Vincent Habchi]

Hi Marius,

thanks for answering.

> He has expressed that he is no longer interested in putting in the effort to 
> make apache 2.4 the default (some work is needed, as apache2.4-devel has a 
> different directory structure than apache2 (2.2)).

Okay.

> Two questions:
> 
> 1) why do you want to use php 5.6, rather than php 7.0?
> 2) why do you want to use apache2handler rather than php-fpm?

Hmmm… I need php5.6 because the webmaster of the sites (not me, I merely 
administrate them) is still running an old Drupal 6 that – IMHO – is not 
compatible with php7.

What is php-fpm?

Yes, I stumbled on several other mishaps while installing, notably PHP 
extensions being named php_XXX.so instead of XXX.so in the httpd.conf

> That having been said, until recently, I was using apache2.4-devel with php56 
> and apache2handler. I patched apr-util to use db48, rather than db46. I think 
> adding Berkeley db variants to apr-util would be a good idea.

Yeah, I did add a script of auto-detection, but I remember someone saying this 
was not authorised in Macports. 

> However, I still use apache 2.4 and php 5.6 with apache2handler under FreeBSD…

And so do I: the master I replicate is configured exactly this way :)

Vincent

Apache 24 woes

[Vincent Habchi]

Folks,

I’ve a problem on a website I look after and I’m trying to replicate the 
configuration locally on my Mac to ease debugging.

So I’ve installed apache24 and stumbled on the following roadblocks or hitches:

1. Why is apache24 still called “apache24-devel”?

2. APR-UTIL should:
a. Be dependant on whatever db version is installed and not db46. I 
wrote this:
—
# DB dependency 
set db_list [lsort [glob ${prefix}/lib/db??]]
set db_most_recent [lindex [split [lindex $db_list 0] /] end]
if {$db_most_recent == ""} { set db_most_recent "db60" }

depends_lib port:apr port:expat port:libiconv port:$db_most_recent 
port:sqlite3
—

b. Have a mariadb10 variant

3. PHP56-APACHE2HANDLER likewise cannot be used as is with Apache24. There 
should be a +apache24 variant or some form of auto-detect. The correct 
configuration for Apache24 is thus:

depends_lib-append port:apache24-devel 
require_active_variants apache24 preforkmpm 
set apxs ${prefix}/bin/apxs 
set confdir ${prefix}/etc/apache2/conf 
set moduledir ${prefix}/lib/apache2/modules 


Here we are. Thanks for listening to my rambling!

Cheers all.

git question (ignoring a private patch)

[Vincent Habchi]

Folks,

I have a private version of the llvm-3.9/Portfile (I just narrowed down the 
targets to PowerPC and X86 rather than build everyone of them which squanders 
time). But now I can’t git pull —rebase, I get an error message.

Of course I have no intention to commit that private patch. How can I make it 
ignored by git?

Thanks a bunch!
Vincent