Re: New project member: ra1nb0w

[g5pw]

Benvenuto Davide! :)

Glad to have you onboard!

> On 4 Feb 2020, at 02:00, Rainer Müller  wrote:
> 
> Please join us in welcoming the following new MacPorts project member:
> 
> - Davide Gerhard (ra1nb0w@, @ra1nb0w)
> 
> We look forward to continued excellent contributions from these new team
> members.
> 
> - Joshua, Ryan, and Rainer
> 
> 
> Do you want to join the MacPorts team? If you would like to be
> considered for team membership and commit access, please read this
> section of the Guide:
> 
> http://guide.macports.org/chunked/project.membership.html

--
Aljaž Srebrnič a.k.a g5pw
My public key:  https://g5pw.me/key
Key fingerprint = 2109 8131 60CA 01AF 75EC  01BF E140 E1EE A54E E677

question about build failures from buildbot

[John Duksta]

Hey other macports-devs

I got a bunch of builtbot failures yesterday across all macos releases.

I want to be a good maintainer, but I only maintain one package (rtl_433),
so I'm not familiar with debugging build bot issues. This is the first time
I've seen these problems. From the stdio for rtl_433[1], it looks to me
like there's a general problem with the build environment being able to
fetch upstream deps. Is there anything for me to do here, or is there just
a general CI problem?

Thanks,
-j

[1]
https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/23353/steps/install-port/logs/stdio



-- Forwarded message -
From: 
Date: Mon, Feb 3, 2020 at 2:15 PM
Subject: Build Failure on ports-10.15_x86_64: pymol, rtl_433, solid, vbs,
weka
To: , 
Cc: 


Status:   Failure
Build slave:  ports-10.15_x86_64
Full logs:
https://build.macports.org/builders/ports-10.15_x86_64-watcher/builds/2777
Build reason: A build was forced by 'jmr ': force build
Port list:vbs sbsat psfex raxml solid pymol source-extractor rtl_433
root5 weka sextractor
Subport list:
- psfex
- pymol
- root5
- rtl_433
- sbsat
- solid
- source-extractor
- vbs
- weka
Variants: None
Revision:
Build time:   1:41:44
Author:

Log from failed builds:
Building 'pymol' ... [ERROR]
> maintainers: howarth.at.macpo...@gmail.com.
Fetching 'root5' ... [ERROR]
> maintainers: jon...@macports.org.
Building 'rtl_433' ... [ERROR]
> maintainers: j...@duksta.org.
Fetching 'sbsat' ... [ERROR]
> maintainers: s...@macports.org.
Building 'solid' ... [ERROR] (failed to fetch dependency 'gcc49')
> maintainers: .
Building 'vbs' ... [ERROR]
> maintainers: .
Building 'weka' ... [ERROR]
> maintainers: .

Broken ports:
- pymol
- rtl_433
- solid
- vbs
- weka

Responsible maintainers:
- howarth.at.macpo...@gmail.com
- j...@duksta.org

Links to individual build jobs:
- ports-10.15_x86_64-builder #23350

https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/23350
- ports-10.15_x86_64-builder #23351

https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/23351
- ports-10.15_x86_64-builder #23352

https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/23352
- ports-10.15_x86_64-builder #23353

https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/23353
- ports-10.15_x86_64-builder #23354

https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/23354
- ports-10.15_x86_64-builder #23355

https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/23355
- ports-10.15_x86_64-builder #23356

https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/23356
- ports-10.15_x86_64-builder #23357

https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/23357
- ports-10.15_x86_64-builder #23358

https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/23358

-- 
Best regards,
MacPorts Buildbot
https://build.macports.org/

Re: question about build failures from buildbot

[Ryan Schmidt]

On Feb 4, 2020, at 13:32, John Duksta wrote:

> Hey other macports-devs
> 
> I got a bunch of builtbot failures yesterday across all macos releases.
> 
> I want to be a good maintainer, but I only maintain one package (rtl_433), so 
> I'm not familiar with debugging build bot issues. This is the first time I've 
> seen these problems. From the stdio for rtl_433[1], it looks to me like 
> there's a general problem with the build environment being able to fetch 
> upstream deps.
> 

> Is there anything for me to do here,

I'm not sure what you mean... If you are referring to this output:

> --->  Attempting to fetch rtl_433-19.08_0.darwin_19.x86_64.tbz2 from 
> http://packages-private.internal.macports.net/rtl_433
> 
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
> 
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
> DEBUG: Fetching archive failed: The requested URL returned error: 404 Not 
> Found
> 
> --->  Attempting to fetch rtl_433-19.08_0.darwin_19.x86_64.tbz2 from 
> http://packages-private.internal.macports.net/rtl_433
> 
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
> 
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
> DEBUG: Fetching archive failed: The requested URL returned error: 404 Not 
> Found
> 
> --->  Attempting to fetch rtl_433-19.08_0.darwin_19.x86_64.tbz2 from 
> http://packages.internal.macports.net/rtl_433
> 
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
> 
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
> DEBUG: Fetching archive failed: The requested URL returned error: 404 Not 
> Found

then that is the completely normal output that MacPorts will display when it is 
unable to find a precompiled binary of the port on our server. If a build has 
been scheduled on the buildbot, this will almost certainly be the case. (We 
check whether there is a binary before scheduling a build; if there is, we 
don't schedule it.) Lacking a binary, MacPorts then tries to build from source.

rtl_443 failed to build from source, and it looks like the relevant errors are:

-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE) 
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE) 
-- Found LibRTLSDR: /opt/local/lib/librtlsdr.dylib  
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE) 
-- Could NOT find LibUSB (missing: LIBUSB_INCLUDE_DIR) 
CMake Error at CMakeLists.txt:105 (message):
  RTL-SDR development files not found.

Perhaps the port is just missing a build dependency on port:pkgconfig and/or a 
library dependency on port:libusb.

You can try building the port in trace mode (the "-t" flag) to reproduce the 
issue locally, then add dependencies as needed to resolve the issue, and submit 
a PR with whatever fix you come up with.


> or is there just a general CI problem?

There is in fact also a general problem with the buildbot, which is that the 
SQLite database it uses to keep track of pending build requests became 
corrupted a couple days ago and I just noticed. Until I figure out what to do 
about that, the buildbot won't be able to build anything.

Re: ld64 circular dependency and bootstrapping thoughts

[Ken Cunningham]

the ld64 update is looking quite ready to commit. Jeremy has approved it. I’ve 
been over it on all the systems I have, 10.4 up, and it looks OK to me 
everywhere I have used it. The ld64 test suite has been enabled, and anyone is 
welcome to test it out. 

Anyone with comments or concerns, please speak up now. 

In my review, it appears that all systems will have an ld64 at least as recent 
as what they have now after the upgrade.

Xcode 9 and 10  users will move (by default) to the new ld64-latest for new 
installs. Existing installs remain on the +ld64_xcode variant, as forcing 
variants is (AFAIK) not possible, otherwise we’d have done it these past years 
for ld64 already.

Xcode 11 will still default to ld64 +ld64_xcode as that ld64 will still be 
newer than the one in MacPorts.


In the process of going through this, I’ve learned that 10.4 PPC (and Tiger) 
can likely upgrade to at least ld64-127, which will be nice for them. Leopard 
Intel can probably go up to ld64-236 and likely ld64-274 is possible too. Maybe 
newer, who knows? 10.6.8 and up will be all on the newest ld64-450, which is 
perhaps something of a miracle, really.

the bootstrapping issue, where there is a manual step to get to ld64-latest on 
all systems < 10.12, will have to remain for now. Nobody will be set back.

I remain interested in an automatic bootstrapping method whereby a bootstrap 
version of a port can be replaced by a newer version once the bootstrap version 
is installed.


Best,

Ken



> On Feb 2, 2020, at 3:39 PM, Ken Cunningham  
> wrote:
> 
> Touch complicated, hope I explained it clearly. Probably best not to read at 
> half-time today :> Watch J-Lo instead...
> 
> 
> After a number of years at @274,  ld6 @450 can now build with MacPorts. It 
> matches Xcode 10.2.  ld64 @450 supports the latest TAPI-requiring SDKs, new 
> features, etc, and all our Intel systems (10.6+ at least) would do well to 
> move to that version.
> 
> The WIP is here, and seems pretty close to done, and does pretty well on the 
> test suite, other than a bootstrapping issue I'm outlining with this question:
> 
> 
> 
> I would appreciate any potential testers to exercise this port prior to us 
> committing it, if there are any interested users out there.
> 
> 
> There has been a bootstrapping issue with ld64 for years, but until now it 
> only involved 10.6.8, and so was not fixed to date. Now it will involve < 
> 10.12, so we should look at it. The essence is:
> 
> 
> 1. ld64 > 274 requires libtapi. 
> 2. libtapi uses c++17 features, so only builds with Xcode clangs > 802 ( ie 
> Xcode 9) and macports-clang > 5.0. This does not appear immediately simple to 
> downgrade.
> 3. This means all systems < 10.12 will have to build libtapi with a 
> macports-clang version. 
> 4. But macports-clang-* requires ld64 as a runtime dependency (it's hardcoded 
> into the compiler to search for it in ${prefix}/bin/ld ). (NB this does not 
> have to be ld64-latest.)
> 5. Ergo circular dependency.
> 
> 
> ld64 uses variants to select the last version your toolchain can build   
> (10.4=97, 10.5 and 10.6=127, 10.7 to 10.11 will be =274 due to libtapi, 10.12 
> and up=450). -- and the "ld64-latest" version is the one you get with no 
> variants enabled. This works, but doesn't lend itself easily to an automated 
> bootstrap, and requires a manual step.
> 
> ie to get the latest ld64 on a given system, you would need to do what 10.6.8 
> does now (NB adding in the new ld64_274 variant).
> 
> sudo port -v install ld64
> sudo port -v -n upgrade --enforce-variants ld64 -ld64_97 -ld64_127  -ld64_236 
> -ld64_274 -ld64_xcode
> 
> So, not bootstrap-friendly... if we want to automate getting all systems onto 
> ld64-latest, we'll need to come up with something.
> 
> 
> Possible Solution:
> 
> We could make a new port, ld64-bootstrap, that symlinks in the last ld64 that 
> the users Xcode toolchain can build.
> 
> Then change the runtime ld64 dependency in the clang ports (and the gcc ports 
> as well, I guess) to a path dependency so that ld64-bootstrap would satisfy 
> it:
> 
> depends_run-append path:bin/ld:ld64
> 
> the ld64 port would depend on ld64-bootstrap.
> 
> That's all pretty easy.
> 
> 
> The issue seems to be getting ld64-bootstrap to be preferentially installed 
> if "${prefix}/bin/ld"  does not exist, and then getting ld64 to replace it if 
> "${prefix}/bin/ld" does exist.
> 
> I am not sure how to go about doing that at present.
> 
> Ideas welcome.
> 
> Ken
> 
> 
> 
> PS - anticipating the libtapi issue, I have left it possible to build libtapi 
> with gcc against ${prefix}/lib/libgcc which avoids this, but this has 
> potential stdlib issues of course. And still doesn't fix 10.6.8.
> 
> 
> 
> 
> 
> 

Re: ld64 circular dependency and bootstrapping thoughts

[Ken Cunningham]

> On Feb 4, 2020, at 8:26 PM, Ken Cunningham  
> wrote:
> 
> 10.4 PPC (and Tiger) can likely upgrade to at least ld64-127

10.4 PPC (and Intel) I meant.

K