Re: Why is binary avoided for Xcode MPI wrappers?
On May 21, 2021, at 09:00, Eric Borisch wrote: > > On Thu, May 20, 2021 at 10:56 PM Ryan Schmidt wrote: > >> rev-upgrade only checks library linkage. If you're saying that this software >> links with a library inside Xcode, and that the install name of that library >> varies by Xcode version such that the software linked with the library in >> one version of Xcode fails with a library file not found error when Xcode is >> upgraded to a new version, then yes rev-upgrade would detect that. >> Otherwise, no it would not. > > If someone installs MacPorts without following the directions (installing > xcode / command line tools), they might (don't know, I haven't tried doing > that) end up downloading a package that tries (via mpicc / mpicxx) to run a > compiler that isn't there. (Since running mpicc requires the wrapped cc to be > present.) But looking at the binaries and libraries in mpich-default, I don't > think rev-upgrade would catch anything. A compiler is a program, not a library, so you're correct that rev-upgrade would not notice anything about that. The list of compilers provided by Xcode hasn't changed in a long time, as it? It's been only clang since Xcode 5, hasn't it?
Re: Protobuf3-cpp update woes; strategy to avoid broken dependent ports?
On May 21, 2021, at 06:59, Christopher Nielsen wrote: > We need to figure out a better way to deal with updates to ‘protobuf3-cpp’, > as every time this port is updated, all dependent ports are broken. (Apart > from a handful that folks manually rev-bump along with it.) > > The problem is that every update results in the name of the dylib being > incremented by one, breaking everything linked to it. > > Does anyone know an easy fix? Whoever updates protobuf3-cpp (or any other port that provides a library) is responsible for noticing whether the install_name has changed. If it has, that person is responsible for revbumping all ports that link with that library.
Re: Protobuf3-cpp update woes; strategy to avoid broken dependent ports?
On May 21, 2021, at 8:38 AM, Joshua Root wrote: > If it's not actually doing anything that should break binary compatibility > (removing symbols or changing their semantics), the fix is to stop increasing > the library major version for binary compatible updates. If it is, there's no > getting around rev bumping all dependents. This is something that would be nice to expand macports base to handle more easily (although the details of the implementation might be annoying to deal with) - but we've managed for a /long/ time with rev-bumping all dependent ports. -- Daniel J. Luke
Re: bash and bashdb ports
On 21/05/2021 14.48, Giuseppe 'ferdy' Miceli wrote: > could someone be so kind to enlighten me about the bash port? > > if i am not mistaken the bash50 sub-port is obsolete and could be removed. > > i stumbled on it while installing bashdb which depends on bash50 which > conflicts with bash. > > i worked around changing in my local repository the dependency from bash50 to > bash and was about to PR the modified bash and bashdb ports, but frankly > speaking i do not know if that would be the right think to do. > > thank you very much in advance, bashdb is not compatible with bash >= 5.0 and fails to build. This is the only reason the bash50 subport still exists. The situation has often been like this in the past and it took some time until bashdb caught up to the latest bash release. Rainer
Re: Why is binary avoided for Xcode MPI wrappers?
On Thu, May 20, 2021 at 10:56 PM Ryan Schmidt wrote: > We have no tickets about the previous problem to study? > My cursory looks for them or mailing list discussions have failed. I would tear it out for now. > rev-upgrade only checks library linkage. If you're saying that this software links with a library inside Xcode, and that the install name of that library varies by Xcode version such that the software linked with the library in one version of Xcode fails with a library file not found error when Xcode is upgraded to a new version, then yes rev-upgrade would detect that. Otherwise, no it would not. If someone installs MacPorts without following the directions (installing xcode / command line tools), they might (don't know, I haven't tried doing that) end up downloading a package that tries (via mpicc / mpicxx) to run a compiler that isn't there. (Since running mpicc requires the wrapped cc to be present.) But looking at the binaries and libraries in mpich-default, I don't think rev-upgrade would catch anything. Thanks, - Eric
bash and bashdb ports
Ciao, could someone be so kind to enlighten me about the bash port? if i am not mistaken the bash50 sub-port is obsolete and could be removed. i stumbled on it while installing bashdb which depends on bash50 which conflicts with bash. i worked around changing in my local repository the dependency from bash50 to bash and was about to PR the modified bash and bashdb ports, but frankly speaking i do not know if that would be the right think to do. thank you very much in advance, —
Re: Protobuf3-cpp update woes; strategy to avoid broken dependent ports?
On 2021-5-21 21:59 , Christopher Nielsen wrote: We need to figure out a better way to deal with updates to ‘protobuf3-cpp’, as every time this port is updated, all dependent ports are broken. (Apart from a handful that folks manually rev-bump along with it.) The problem is that every update results in the name of the dylib being incremented by one, breaking everything linked to it. Does anyone know an easy fix? If it's not actually doing anything that should break binary compatibility (removing symbols or changing their semantics), the fix is to stop increasing the library major version for binary compatible updates. If it is, there's no getting around rev bumping all dependents. - Josh
Re: Buildbot hardware (was: Re: Framing the MacPorts discussion)
Hi, Thanks Ryan. My answer is very similar to Ben’s: * I’d be happy to provide you exclusive access to the resources (encrypted VMs, your own users, network and machine are UPS-protected, firewalled, etc.) * I completely agree with you about the safety concerns: those should not be relaxed. * I volunteered because I thought they were needed: I love MacPorts, and I want it to thrive. Bye, Enrico From: Ben Greenfield Date: Friday, 21 May 2021 at 13:26 To: Ryan Schmidt Cc: Andrew Janke , Enrico Maria Crisostomo , MacPorts Developers Subject: Re: Buildbot hardware (was: Re: Framing the MacPorts discussion) Hey All, Thanks for the direction Ryan. > On May 21, 2021, at 12:46 AM, Ryan Schmidt wrote: > > On May 19, 2021, at 12:38, Andrew Janke wrote: > >> I have a small stack of Mac Minis I got to use as a buildbot farm for >> Octave.app; I might be able to have them pull double duty for MacPorts >> depending on your change volume. > > > On May 20, 2021, at 08:10, Enrico Maria Crisostomo wrote: > >> I've got an iMac Pro in my LAN with 16 vCores and 64GB or RAM which is quite >> often idle. >> I'm not privy with how our build system work, but if we could get to a point >> where agents can be added, stopped, throttled, trusted members of our >> community could volunteer the computational power they have at their >> disposal without fully dedicating a machine. >> In my specific case: I'm happy to offer VMs on that machine to volunteer >> computational resources. > > > On May 20, 2021, at 08:20, Ben Greenfield wrote: > >> I can definitely donate the facilities if not the talent. >> >> I have a symmetrical fiber connection and a static ip. I also have battery >> backup. >> I’m in the final weeks of making the building legal and I haven’t configured >> the final network set-up for the building. I was going to set-up a vlan on >> my hp procurve switch. >> I’m still shopping for a router to run OPNsense I think. >> >> I have been a mac sysadmin long time. > > > There seem to be a lot of people suddenly volunteering hardware for our build > system. First, thank you; I didn't know we had people interested in that. > > Our build system has never been designed to accommodate external hardware. It > has always been designed as a centralized system controlled by one > administrator. When it was first set up in 2011-12 it was under the control > of our Apple administrator at macOS forge. I became the macOS forge > administrator temporarily in late 2015, and MacPorts left macOS forge in late > 2016 as that service shut down, and I recreated the buildbot system on my own > hardware and have run it since then. > > We now have one external Apple Silicon build machine hosted at another data > center, but it's still under my exclusive control so that I can keep > everything working together. > I would be happy to provide the same service. I don’t need a log-in and I can probably provide out of band power reset. The system could be on it’s own vlan. > There are currently many situations where the build system gets into a state > that requires manual intervention. Because I control all the machines, I'm > able to make those fixes and get things back up and running quickly. > > We currently have all the builders we need: one for each OS version / arch > combination. The system was never designed to have more than that. If for > example we added a second macOS 11 / x86_64 builder, there could be confusion > and problems if the two machines have different OS / Xcode / command line > tools / java versions installed. > > There are security issues to consider. The binaries produced by our buildbot > workers are signed on the master with our private key. This is our "seal of > approval" that says we believe these binaries to be good and safe. Users > trust that. If we start allowing other people to run build machines, then we > have the problem that we do not know for certain whether those other build > machines are free of malware or other problems. We would be signing binaries > for distribution to users without being certain of their safety or > correctness. I'm not very comfortable with that. Yes, that safety should be maintained. > > Why is this discussion happening? Why do people think we need more hardware? > If we need more or faster CPUs or more memory, I can make those changes to > the hardware I already manage. I volunteered because it sounded like resources might be needed:). Let me know if the free-hosting is needed. Ben >
Protobuf3-cpp update woes; strategy to avoid broken dependent ports?
We need to figure out a better way to deal with updates to ‘protobuf3-cpp’, as every time this port is updated, all dependent ports are broken. (Apart from a handful that folks manually rev-bump along with it.) The problem is that every update results in the name of the dylib being incremented by one, breaking everything linked to it. Does anyone know an easy fix?
Re: Buildbot hardware (was: Re: Framing the MacPorts discussion)
Hey All, Thanks for the direction Ryan. > On May 21, 2021, at 12:46 AM, Ryan Schmidt wrote: > > On May 19, 2021, at 12:38, Andrew Janke wrote: > >> I have a small stack of Mac Minis I got to use as a buildbot farm for >> Octave.app; I might be able to have them pull double duty for MacPorts >> depending on your change volume. > > > On May 20, 2021, at 08:10, Enrico Maria Crisostomo wrote: > >> I've got an iMac Pro in my LAN with 16 vCores and 64GB or RAM which is quite >> often idle. >> I'm not privy with how our build system work, but if we could get to a point >> where agents can be added, stopped, throttled, trusted members of our >> community could volunteer the computational power they have at their >> disposal without fully dedicating a machine. >> In my specific case: I'm happy to offer VMs on that machine to volunteer >> computational resources. > > > On May 20, 2021, at 08:20, Ben Greenfield wrote: > >> I can definitely donate the facilities if not the talent. >> >> I have a symmetrical fiber connection and a static ip. I also have battery >> backup. >> I’m in the final weeks of making the building legal and I haven’t configured >> the final network set-up for the building. I was going to set-up a vlan on >> my hp procurve switch. >> I’m still shopping for a router to run OPNsense I think. >> >> I have been a mac sysadmin long time. > > > There seem to be a lot of people suddenly volunteering hardware for our build > system. First, thank you; I didn't know we had people interested in that. > > Our build system has never been designed to accommodate external hardware. It > has always been designed as a centralized system controlled by one > administrator. When it was first set up in 2011-12 it was under the control > of our Apple administrator at macOS forge. I became the macOS forge > administrator temporarily in late 2015, and MacPorts left macOS forge in late > 2016 as that service shut down, and I recreated the buildbot system on my own > hardware and have run it since then. > > We now have one external Apple Silicon build machine hosted at another data > center, but it's still under my exclusive control so that I can keep > everything working together. > I would be happy to provide the same service. I don’t need a log-in and I can probably provide out of band power reset. The system could be on it’s own vlan. > There are currently many situations where the build system gets into a state > that requires manual intervention. Because I control all the machines, I'm > able to make those fixes and get things back up and running quickly. > > We currently have all the builders we need: one for each OS version / arch > combination. The system was never designed to have more than that. If for > example we added a second macOS 11 / x86_64 builder, there could be confusion > and problems if the two machines have different OS / Xcode / command line > tools / java versions installed. > > There are security issues to consider. The binaries produced by our buildbot > workers are signed on the master with our private key. This is our "seal of > approval" that says we believe these binaries to be good and safe. Users > trust that. If we start allowing other people to run build machines, then we > have the problem that we do not know for certain whether those other build > machines are free of malware or other problems. We would be signing binaries > for distribution to users without being certain of their safety or > correctness. I'm not very comfortable with that. Yes, that safety should be maintained. > > Why is this discussion happening? Why do people think we need more hardware? > If we need more or faster CPUs or more memory, I can make those changes to > the hardware I already manage. I volunteered because it sounded like resources might be needed:). Let me know if the free-hosting is needed. Ben >
