Re: Unable to fetch sources from GitLab instance
Indeed, I was downloading the tarball and manually putting it into the distfiles directory, so that I could get the rest of the Portfile written. I guess I'll just have to take it on faith that one of the newer buildbots will manage to save the distfile into distfiles.macports.org before the older builders attempt their builds. I'm aware of the curl issues on older Macs, since this topic was recently discussed on this mailing list as well... which is why I tried manually running /usr/bin/curl on the tarball, which downloaded fine on both my 10.13 High Sierra and 10.11 El Capitan machines. That's why I was confused when MacPorts couldn't seem to download the file. I was under the impression that MacPorts uses the Apple/system libcurl, which... is the same as what /usr/bin/curl uses? Or am I mistaken about that? In any case, thanks Dave, for trying it out and letting me know that I'm not slowly losing my mind writing these Portfiles. (Or maybe I am anyway, haha) -- Jason Liu On Sat, Jul 29, 2023 at 10:26 PM Dave Allured - NOAA Affiliate via macports-dev wrote: > Jason, port fetch with your unmodified portfile works fine for me. > Monterey x86_64, Macports 2.81, freshly updated. I think your portfile > recipe for this gitlab instance is good. There have been several recent > reports of Macports fetch problems. These often relate to down level Apple > native versions of curl on older Macs, improper certificate updates on > servers, etc. > > There is a shortcut if it is only a single tar file. Instead of spending > time diagnosing, just manually download the distfile, which you already > have. Then manually insert that into > (prefix)/var/macports/distfiles/librist, then re-run port install, as > described in https://trac.macports.org/wiki/ProblemHotlist#fetch-failures. > Port install will then skip the problematic download and be happy with the > local copy. When your portfile is later merged into Macports, the distfile > will be propagated to various mirrors, which will then serve anyone having > problems with the original server. > > Also see: https://trac.macports.org/wiki/ProblemHotlist#letsencrypt > > > On Sat, Jul 29, 2023 at 9:14 AM Jason Liu wrote: > >> By the way, here is my Portfile for librist, in case anyone wants to try >> and see whether fetching from VideoLAN's GitLab instance works for them. >> -- >> Jason Liu >> >> >> On Fri, Jul 28, 2023 at 11:47 PM Jason Liu wrote: >> >>> Hi all, >>> >>> I suppose I should be directing this question to René Bertin, since he's >>> the maintainer of the VLC port, but I'm sending this to the entire dev >>> mailing list, in case anyone else has any ideas. >>> >>> I'm trying to create a Portfile for librist, which is one of the >>> projects that's being hosted on https://code.videolan.org. My question >>> to René (and everyone else) is: Have you had any luck trying to fetch >>> sources from code.videolan.org? When I try to use the gitlab PortGroup, >>> MacPorts doesn't seem to find a tarball at the URL that is generated by the >>> PortGroup. However, I'm able to download the file using a web browser, and >>> even curl downloads the file just fine: >>> >>> /usr/bin/curl -LROJk >>> https://code.videolan.org/rist/librist/-/archive/v0.2.7/librist-v0.2.7.tar.bz2 >>> >>> Does anyone have any explanation for the behavior that I'm seeing? >>> -- >>> Jason Liu >>> >>
Re: Unable to fetch sources from GitLab instance
Jason, port fetch with your unmodified portfile works fine for me. Monterey x86_64, Macports 2.81, freshly updated. I think your portfile recipe for this gitlab instance is good. There have been several recent reports of Macports fetch problems. These often relate to down level Apple native versions of curl on older Macs, improper certificate updates on servers, etc. There is a shortcut if it is only a single tar file. Instead of spending time diagnosing, just manually download the distfile, which you already have. Then manually insert that into (prefix)/var/macports/distfiles/librist, then re-run port install, as described in https://trac.macports.org/wiki/ProblemHotlist#fetch-failures. Port install will then skip the problematic download and be happy with the local copy. When your portfile is later merged into Macports, the distfile will be propagated to various mirrors, which will then serve anyone having problems with the original server. Also see: https://trac.macports.org/wiki/ProblemHotlist#letsencrypt On Sat, Jul 29, 2023 at 9:14 AM Jason Liu wrote: > By the way, here is my Portfile for librist, in case anyone wants to try > and see whether fetching from VideoLAN's GitLab instance works for them. > -- > Jason Liu > > > On Fri, Jul 28, 2023 at 11:47 PM Jason Liu wrote: > >> Hi all, >> >> I suppose I should be directing this question to René Bertin, since he's >> the maintainer of the VLC port, but I'm sending this to the entire dev >> mailing list, in case anyone else has any ideas. >> >> I'm trying to create a Portfile for librist, which is one of the projects >> that's being hosted on https://code.videolan.org. My question to René >> (and everyone else) is: Have you had any luck trying to fetch sources from >> code.videolan.org? When I try to use the gitlab PortGroup, MacPorts >> doesn't seem to find a tarball at the URL that is generated by the >> PortGroup. However, I'm able to download the file using a web browser, and >> even curl downloads the file just fine: >> >> /usr/bin/curl -LROJk >> https://code.videolan.org/rist/librist/-/archive/v0.2.7/librist-v0.2.7.tar.bz2 >> >> Does anyone have any explanation for the behavior that I'm seeing? >> -- >> Jason Liu >> >
Re: Qt5 on <= 10.6
On Sat, 29 Jul 2023, Sergio Had wrote: Does Qt5 work on 10.5–10.6 Intel? It looks that at least earlier 5.x versions installed on 10.6: https://ports.macports.org/port/qt53/stats Presumably that should be fixable for 10.5 and PPC. (I am not sure if 5.3 is of much use though – do developers of ports depending on Qt5 support it still?) P. S. Given how much efforts it takes every time to fix something for Qt4, even if it means just digging out a right version and reverting some commits, I start asking a question if it is easier just to fix some early 5.x version. There should not be anything arch-specific, it should be just C++, I guess. Just find fallbacks for whatever misses in SDK, but if it works on 10.6 Intel, it might be pretty feasible. One shouldn't assume that Qt5 is a drop-in replacement for Qt4. At one point, I'd added an option to gpsd to allow building with Qt5, and it worked at the time I created it. But later on, something changed to break the build with Qt5, and I never tracked it down, so for now it's stuck on Qt4. This is unfortunate, since Qt4 seems to think that any processor that's not x86 must be ppc, so building against Qt4 on the M1 falls on its face trying to include ppc-specific code. The Qt4 build itself works, just not building gpsd against it. Fred Wright
Re: Unable to fetch sources from GitLab instance
By the way, here is my Portfile for librist, in case anyone wants to try and see whether fetching from VideoLAN's GitLab instance works for them. -- Jason Liu On Fri, Jul 28, 2023 at 11:47 PM Jason Liu wrote: > Hi all, > > I suppose I should be directing this question to René Bertin, since he's > the maintainer of the VLC port, but I'm sending this to the entire dev > mailing list, in case anyone else has any ideas. > > I'm trying to create a Portfile for librist, which is one of the projects > that's being hosted on https://code.videolan.org. My question to René > (and everyone else) is: Have you had any luck trying to fetch sources from > code.videolan.org? When I try to use the gitlab PortGroup, MacPorts > doesn't seem to find a tarball at the URL that is generated by the > PortGroup. However, I'm able to download the file using a web browser, and > even curl downloads the file just fine: > > /usr/bin/curl -LROJk > https://code.videolan.org/rist/librist/-/archive/v0.2.7/librist-v0.2.7.tar.bz2 > > Does anyone have any explanation for the behavior that I'm seeing? > > -- > Jason Liu > Portfile Description: Binary data
Re: Qt5 on <= 10.6
On 7/29/23 at 6:51 AM, Sergio Had wrote: > Does Qt5 work on 10.5–10.6 Intel? > > It looks that at least earlier 5.x versions installed on 10.6: > https://ports.macports.org/port/qt53/stats > Presumably that should be fixable for 10.5 and PPC. > (I am not sure if 5.3 is of much use though – do developers of ports > depending on Qt5 support it still?) > > P. S. Given how much efforts it takes every time to fix something for Qt4, > even if it means just digging out a right version and reverting some commits, > I start asking a question if it is easier just to fix some early 5.x version. > There should not be anything arch-specific, it should be just C++, I guess. > Just find fallbacks for whatever misses in SDK, but if it works on 10.6 > Intel, it might be pretty feasible. https://trac.macports.org/ticket/64570 https://trac.macports.org/ticket/64932#comment:10
Qt5 on <= 10.6
Does Qt5 work on 10.5–10.6 Intel? It looks that at least earlier 5.x versions installed on 10.6: https://ports.macports.org/port/qt53/stats Presumably that should be fixable for 10.5 and PPC. (I am not sure if 5.3 is of much use though – do developers of ports depending on Qt5 support it still?) P. S. Given how much efforts it takes every time to fix something for Qt4, even if it means just digging out a right version and reverting some commits, I start asking a question if it is easier just to fix some early 5.x version. There should not be anything arch-specific, it should be just C++, I guess. Just find fallbacks for whatever misses in SDK, but if it works on 10.6 Intel, it might be pretty feasible.
