Re: Notes & warning after update.
On Oct 11, 2021, at 15:54, Sriranga Veeraraghavan wrote: > I am by no means a macports expert, but based on my experience, I think you > can ignore the warnings. AFAIK, the warnings are telling you the following: > > 1. The first message you received regarding ffmpeg indicates that ffmpeg was > built with modules that are licensed under the GNU Public License (GPL). As > the message states, these modules are: > > postproc - video postprocessing > libx264 - library for handling H.264/MPEG-4 AVC format video > libx265 - library for handling H.265/HEVC format video > libxvid - library for handling Xvid MPEG-4 Part 2 video > > The message about ffmpeg next tells you that if you want to include libraries > that are not considered freely distributable for the purposes of the GPL (I > think that this is currently only the Fraunhofer AAC code: > https://trac.ffmpeg.org/wiki/Encode/AAC), then you should rebuild the ffmpeg > port with the +nonfree option, which I think you could do as follows: > > sudo port deactivate ffmpeg && sudo port install ffmpeg +nonfree > > Finally, the message about ffmpeg tells you that if you don’t want the GPL > libraries mentioned above, you should rebuild the ffmpeg port without the > +gpl2 option (which appears to the be default, and which I normally prefer to > install because my camera captures video in H.264/H.265). I think you could > do this as follows: > > sudo port deactivate ffmpeg && sudo port install ffmpeg -gpl2 > > 2. The second message you received regarding python27 tells you how to make > python 2.7 the default version of python and/or python2, in other words, the > version that would get run if you typed python and/or python2 (assuming that > /opt/local/bin comes before /usr/bin in your $PATH). > > Unless you are using python 2.7 regularly or have a specific reason not to > use the Apple provided version of python/python2, I am not sure if you really > need to do either of these things (I never have, and I’ve been using macports > for years). > > 3. The third message you received regarding python39 is similar to the > message you received about python27 and tells you how to make python 3.9 the > default version of python and/or python3. If you are working with python3, > you may want to do this. The above are not warnings; they're notes -- informational messages that the designer of the port thought people might like to know. They do not indicate that anything is wrong. > 4. The message you received from ’sudo port upgrade outdated’ tells you that > when the links port, which is installed on your system, was built, the > '-Wimplicit-function-declaration’ option was supplied to the compiler and > that the compiler found three functions that were implicitly declared. The > warning is telling you that it is possible that links may not function > properly in some situations because of this. > > [If you are familiar with C, apologies in advance for the following > paragraph, including inaccuracies due to oversimplification] > > These days, well-formed C requires a description of a function (called a > prototype) to be provided before a function is used for the first time. If a > function is used without providing a prototype, when the > '-Wimplicit-function-declaration’ option is supplied to the computer, the > compiler tells you that you that there may be something wrong with your > program. In this case, my guess is that somewhere in the links source code > the standard C header file string.h should have been included but wasn’t > (either due to oversight or because of a configuration error), and the > compiler is highlighting this. This is probably something that should be > fixed in the links source code, but could possibly be fixed by macports as > well. The version of clang included with Xcode 12 and later (so, on Big Sur and later and sometime on Catalina) defaults to behavior equivalent to -Werror=implicit-function-declaration which is why these problems are being seen more lately. For a lot more on the implications of this, see my previous write-up: https://lists.macports.org/pipermail/macports-dev/2020-November/042648.html
Re: clang config issue
Thanks for the feedback. I subsequently ran into the update bug after I sent the note. Did a clean reinstall of the command line tools (13.1) and things are working nicely. Cheers b > On Oct 27, 2021, at 11:58 AM, Ryan Schmidt wrote: > > This is the real problem. It means that your command line tools are too old > for macOS 11. Install a compatible version of the command line tools. There > is a bug in recent macOS which does not present updates of the command line > tools to you in Software Update, so you must seek out and install those > updates manually when they're available. >
Re: Youtube-dl install failure
On Oct 27, 2021, at 11:11, dan d. wrote: > If I had to guess the install routine is not fetching the youtube-dl > distribution files to install. > > I get this error message > > Error: Failed to install youtube-dl: no destroot found at: > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_youtube-dl/youtube-dl/work/destroot-- > Any help appreciated. The port installs fine. To resolve the issue you're encountering, see https://trac.macports.org/wiki/ProblemHotlist#nodestrootfound
Re: clang config issue
On Oct 27, 2021, at 13:23, William Parducci wrote: > I’m tried to install nmap on a clean install of macports in Big Sur. When it > got to configuring clang it is threw this error: > > > configure:2838: /usr/bin/clang -qversion >&5 > clang: error: unknown argument '-qversion', did you mean '--version’? This error is not a problem. A configure script's purpose is, among other things, to run various commands with various arguments to determine which of them work on your system. Here, it has determined that -qversion is not a valid flag for your compiler. That's fine and normal on macOS. > clang: error: invalid version number in 'MACOSX_DEPLOYMENT_TARGET=11.0’ > […] > configure:2940: error: C compiler cannot create executables This is the real problem. It means that your command line tools are too old for macOS 11. Install a compatible version of the command line tools. There is a bug in recent macOS which does not present updates of the command line tools to you in Software Update, so you must seek out and install those updates manually when they're available.
Re: clang config issue
On Oct 27, 2021, at 2:23 PM, William Parducci wrote: > I’m tried to install nmap on a clean install of macports in Big Sur. When it > got to configuring clang it is threw this error: > > configure:2838: /usr/bin/clang -qversion >&5 > clang: error: unknown argument '-qversion', did you mean '--version’? > […] > clang: error: invalid version number in 'MACOSX_DEPLOYMENT_TARGET=11.0’ > […] > configure:2940: error: C compiler cannot create executables > > I see that the nmap configure file is asking for “qversion” > > $ grep qversion > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nmap/nmap/work/nmap-7.92/configure > for ac_option in --version -v -V -qversion; do > for ac_option in --version -v -V -qversion; do > for ac_option in --version -v -V -qversion; do > > I edited the configure file to read --version and it worked > > Full log attached. Can you attach the Macports main.log instead? From your config.log it looks like it actually fails when trying to create a simple executable (after it complains about -qversion) Note that the port seems to build find on Big Sur (https://ports.macports.org/port/nmap/builds/) -- Daniel J. Luke
clang config issue
Hi,I’m tried to install nmap on a clean install of macports in Big Sur. When it got to configuring clang it is threw this error:configure:2838: /usr/bin/clang -qversion >&5clang: error: unknown argument '-qversion', did you mean '--version’?[…]clang: error: invalid version number in 'MACOSX_DEPLOYMENT_TARGET=11.0’[…]configure:2940: error: C compiler cannot create executablesI see that the nmap configure file is asking for “qversion”$ grep qversion /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nmap/nmap/work/nmap-7.92/configurefor ac_option in --version -v -V -qversion; dofor ac_option in --version -v -V -qversion; dofor ac_option in --version -v -V -qversion; doI edited the configure file to read --version and it workedFull log attached. config.log Description: Binary data
Re: Youtube-dl install failure
create a trac ticket, with a *complete* build log. > On 27 Oct 2021, at 5:11 pm, dan d. wrote: > > > If I had to guess the install routine is not fetching the youtube-dl > distribution files to install. > > I get this error message > > Error: Failed to install youtube-dl: no destroot found at: > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_youtube-dl/youtube-dl/work/destroot-- > Any help appreciated. > > ent- > XR smime.p7s Description: S/MIME cryptographic signature
Youtube-dl install failure
If I had to guess the install routine is not fetching the youtube-dl distribution files to install. I get this error message Error: Failed to install youtube-dl: no destroot found at: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_youtube-dl/youtube-dl/work/destroot-- Any help appreciated. ent- XR
Re: Add M1 Hypervisor Support for QEMU Port?
Staging would probably mean it is pre-release, so they’ll be wanting to do some testing on it, before then next numbered release. Not knowing their release cycle, I’d just say give them a month or so. In the meantime, you can always build yourself, outside of a MacPorts install, if you want it now. Sent from my iPad > On Oct 27, 2021, at 02:24, Mojca Miklavec > wrote: > > On Wed, 27 Oct 2021 at 06:02, Ryan Schmidt wrote: >>> On Oct 20, 2021, at 22:06, Sriranga Veeraraghavan wrote: >>> >>> Is there a way to add an optional variant to the QEMU Portfile that would >>> apply this patch? >> >> Yes, it is technically possible to do that. However, we prefer not to >> include and forever maintain unofficial patches. Instead, we would prefer >> for such patches to be submitted to the upstream developers of the software. >> If they include it, then MacPorts will automatically get that and any other >> changes when we update to the next version of the software. If upstream >> elects not to include a patch, then we would have to seriously consider >> whether it would be appropriate for us to second-guess their decision and >> include it in MacPorts anyway. > > I checked their patch procedure which looks pretty involved ... > > ... but according to >https://github.com/Homebrew/homebrew-core/pull/85173 > it looks like upstream has already merged the changes. > > It's hard to follow exactly because commits don't exactly match the > contents of that patch, but by looking at and blaming individual files > (touched by that patch) in the master branch, the first three randomly > chosen changes seem to be included, some of them in the "staging" > branch, whatever that means. > > Given that HB has started this and seems to be actively involved in > maintaining the patches, I would say that it's probably perfectly safe > to include the patches on any arm machine at least. Most likely the > patches will either no longer be needed with the next release, or in > the worst case we can copy them over from HB once again. > > Ranga, if you are willing to prepare a pull request, I would support > that. I don't think we need a variant for that, I would just > unconditionally apply the patch, at least on any arm-based CPU. > > Mojca
Re: Add M1 Hypervisor Support for QEMU Port?
On Wed, 27 Oct 2021 at 06:02, Ryan Schmidt wrote: > On Oct 20, 2021, at 22:06, Sriranga Veeraraghavan wrote: > > > Is there a way to add an optional variant to the QEMU Portfile that would > > apply this patch? > > Yes, it is technically possible to do that. However, we prefer not to include > and forever maintain unofficial patches. Instead, we would prefer for such > patches to be submitted to the upstream developers of the software. If they > include it, then MacPorts will automatically get that and any other changes > when we update to the next version of the software. If upstream elects not to > include a patch, then we would have to seriously consider whether it would be > appropriate for us to second-guess their decision and include it in MacPorts > anyway. I checked their patch procedure which looks pretty involved ... ... but according to https://github.com/Homebrew/homebrew-core/pull/85173 it looks like upstream has already merged the changes. It's hard to follow exactly because commits don't exactly match the contents of that patch, but by looking at and blaming individual files (touched by that patch) in the master branch, the first three randomly chosen changes seem to be included, some of them in the "staging" branch, whatever that means. Given that HB has started this and seems to be actively involved in maintaining the patches, I would say that it's probably perfectly safe to include the patches on any arm machine at least. Most likely the patches will either no longer be needed with the next release, or in the worst case we can copy them over from HB once again. Ranga, if you are willing to prepare a pull request, I would support that. I don't think we need a variant for that, I would just unconditionally apply the patch, at least on any arm-based CPU. Mojca
