Re: libressl-devel: fix livecheck (#1263)
Hi Jeremy, what is the intended distinction between security/libressl and security/libressl-devel? Is it simply 2.x.* and 2.(x+1).* ? LibreSSL itself make no such distinction. Jan
Re: livecheck timeout
On Nov 22 23:42:58, ryandes...@macports.org wrote: > > On Nov 21, 2017, at 11:31, db wrote: > > > Is it possible to set this? I checked man pages for both port-livecheck and > > port but couldn't find a way. I have a shell function for a list of ports > > that stucks on gnutls too long, for some reason. > > I'm not aware of a way for a use to set the livecheck timeout. > > How long is too long? 15 seconds
Re: livecheck timeout
On Nov 23, 2017, at 11:53, Rainer Müller wrote: > On 2017-11-23 18:13, db wrote: >> >> Before the change, it should have timed out in 30", not in 30'. Why didn't >> it? > > I still have no idea what these units are, please communicate clearly. https://en.wikipedia.org/wiki/Prime_(symbol)#Designation_of_units
Re: livecheck timeout
On 2017-11-23 18:13, db wrote: > On 23 Nov 2017, at 17:06, Ryan Schmidt wrote: >> ftp connections fail in many circumstances, due to either the use or non-use >> of passive mode, or for other reasons. I'm certainly tired of attempting to >> debug them, which is why it's great when we can remove the use of ftp from a >> portfile and replace it with http(s). > > Before the change, it should have timed out in 30", not in 30'. Why didn't it? I still have no idea what these units are, please communicate clearly. Always provide debug logs as that would have helped to identify FTP much earlier. I can confirm that the previous Portfile version that used ftp:// for livecheck also hangs longer than 30 seconds for me. It hangs the same way with curl(1) on command line, after EPSV. The timeout we configure is only for the initial connection, but the transfer itself may take as long as it takes. I am not sure why the configured speed limit does not cause the transfer to be aborted after a while, though... We could provide an additional flag for our 'curl fetch' API in Pextlib to set an overall timeout with CURLOPT_TIMEOUT that is only used for livecheck. However, I do not think it is worth to invest effort into that. Hosts or protocols that fail for some users are a bad option value anyway. It is better not to use FTP at all. Rainer
Re: livecheck timeout
On 23 Nov 2017, at 17:06, Ryan Schmidt wrote: > ftp connections fail in many circumstances, due to either the use or non-use > of passive mode, or for other reasons. I'm certainly tired of attempting to > debug them, which is why it's great when we can remove the use of ftp from a > portfile and replace it with http(s). Before the change, it should have timed out in 30", not in 30'. Why didn't it?
Re: livecheck timeout
I updated master_sites for gnutls, as the old ftp server was off line for over a month. It seems to have been restored a couple weeks ago. > On Nov 23, 2017, at 10:06 AM, Ryan Schmidt wrote: > > > On Nov 23, 2017, at 10:04, db wrote: >> On 23 Nov 2017, at 16:52, Ryan Schmidt wrote: >>> $ time port livecheck gnutls >>> real0m1.252s >>> user0m0.196s >>> sys 0m0.079s >> >> Hmm…master_sites was updated, >> https://github.com/macports/macports-ports/commit/1ca7e7e669f82b834b993270053c0b9331caf526#diff-7672b36dcb72869ed4708bfef213e57d. >> >> Is there a timeout for ftp? > > ftp connections fail in many circumstances, due to either the use or non-use > of passive mode, or for other reasons. I'm certainly tired of attempting to > debug them, which is why it's great when we can remove the use of ftp from a > portfile and replace it with http(s). > > Marius -- Marius Schamschula
Re: livecheck timeout
On Nov 23, 2017, at 10:04, db wrote: > On 23 Nov 2017, at 16:52, Ryan Schmidt wrote: >> $ time port livecheck gnutls >> real 0m1.252s >> user 0m0.196s >> sys 0m0.079s > > Hmm…master_sites was updated, > https://github.com/macports/macports-ports/commit/1ca7e7e669f82b834b993270053c0b9331caf526#diff-7672b36dcb72869ed4708bfef213e57d. > > Is there a timeout for ftp? ftp connections fail in many circumstances, due to either the use or non-use of passive mode, or for other reasons. I'm certainly tired of attempting to debug them, which is why it's great when we can remove the use of ftp from a portfile and replace it with http(s).
Re: livecheck timeout
On 23 Nov 2017, at 16:52, Ryan Schmidt wrote: > $ time port livecheck gnutls > real 0m1.252s > user 0m0.196s > sys 0m0.079s Hmm…master_sites was updated, https://github.com/macports/macports-ports/commit/1ca7e7e669f82b834b993270053c0b9331caf526#diff-7672b36dcb72869ed4708bfef213e57d. Is there a timeout for ftp?
Re: livecheck timeout
On Nov 23, 2017, at 09:05, db wrote: > On 23 Nov 2017, at 15:14, Rainer Müller wrote: >> The connect timeout of 30 seconds for downloads using libcurl is hardcoded >> in base [1] and cannot be configured. >> [1] >> https://github.com/macports/macports-base/blob/a1e0b3bd5c062ff4d6eb1fd23badd395bdd39c7f/src/pextlib1.0/curl.c#L57 > > Can you tell then why is gnutls timing out after 30 minutes? $ time port livecheck gnutls real0m1.252s user0m0.196s sys 0m0.079s
Re: livecheck timeout
On 23 Nov 2017, at 15:14, Rainer Müller wrote: > The connect timeout of 30 seconds for downloads using libcurl is hardcoded in > base [1] and cannot be configured. > [1] > https://github.com/macports/macports-base/blob/a1e0b3bd5c062ff4d6eb1fd23badd395bdd39c7f/src/pextlib1.0/curl.c#L57 Can you tell then why is gnutls timing out after 30 minutes?
Re: livecheck timeout
But he said 30 minutes, not 30 seconds… or is it a typo ? Laurent > Le 23 nov. 2017 à 15:14, Rainer Müller a écrit : > > On 2017-11-23 11:09, db wrote: >> On 23 Nov 2017, at 06:42, Ryan Schmidt wrote: >>> How long is too long? >> >> 30' > > The connect timeout of 30 seconds for downloads using libcurl is > hardcoded in base [1] and cannot be configured. > > Rainer > > [1] > https://github.com/macports/macports-base/blob/a1e0b3bd5c062ff4d6eb1fd23badd395bdd39c7f/src/pextlib1.0/curl.c#L57 "S'il n'y a pas de solution, c'est qu'il n'y a pas de problème" (devise Shadok)
Re: livecheck timeout
On 2017-11-23 11:09, db wrote: > On 23 Nov 2017, at 06:42, Ryan Schmidt wrote: >> How long is too long? > > 30' The connect timeout of 30 seconds for downloads using libcurl is hardcoded in base [1] and cannot be configured. Rainer [1] https://github.com/macports/macports-base/blob/a1e0b3bd5c062ff4d6eb1fd23badd395bdd39c7f/src/pextlib1.0/curl.c#L57
Re: livecheck timeout
On 23 Nov 2017, at 06:42, Ryan Schmidt wrote: > How long is too long? 30'
Re: livecheck timeout
On Nov 21, 2017, at 11:31, db wrote: > Is it possible to set this? I checked man pages for both port-livecheck and > port but couldn't find a way. I have a shell function for a list of ports > that stucks on gnutls too long, for some reason. I'm not aware of a way for a use to set the livecheck timeout. How long is too long? I use a script that runs livecheck on all my ports, and does many checks simultaneously, to reduce the impact of timeouts and slow servers. https://github.com/ryandesign/macports-user-ryandesign/blob/master/scripts/portmylivecheck
livecheck timeout
Is it possible to set this? I checked man pages for both port-livecheck and port but couldn't find a way. I have a shell function for a list of ports that stucks on gnutls too long, for some reason.
Re: livecheck
There are a few options laid out: https://guide.macports.org/#reference.livecheck One is `livecheck.regex` to set the pattern to consider for eventual comparison. If you keep it to solely numbers you can ignore the rc matches: `[0-9]+(\.[0-9]+)+` On 08/08/2017 11:16 AM, Jan Stary wrote: > $ port livecheck sox > sox seems to have been updated (port version: 14.4.2, new version: 14.4.2rc2) > > Of course, 'rc2' is the release candidate before 14.4.2. > SoX does not specify any specific livecheck rules; what is > the right place where the default could possibly be tweaked? > > Jan >
livecheck
$ port livecheck sox sox seems to have been updated (port version: 14.4.2, new version: 14.4.2rc2) Of course, 'rc2' is the release candidate before 14.4.2. SoX does not specify any specific livecheck rules; what is the right place where the default could possibly be tweaked? Jan
Re: livecheck - extracted version is older
On Mar 30 18:12:07, allber...@gmail.com wrote: > On Thu, Mar 30, 2017 at 6:09 PM, Jan Stary wrote: > > > This is 2.4.99 on 10.6.8 > > > > $ sudo port clean --all opencore-amr > > ---> Cleaning opencore-amr > > $ port livecheck opencore-amr > > Error: livecheck failed for opencore-amr: extracted version '0.1.2' is > > older than livecheck.version '0.1.3' > > > > "Extracted version" should be the version that livecheck extracted from the > web page it checks for the latest version information. So the message is > saying that it's being told the latest version is older than the current > version. This may mean the page changed format and the livecheck regex > needs to be updated, or it's checking the wrong page and needs to be > updated to look at a page that has the actual current version. Thanks. I need to get into port -d :-) The new opencore is not mentioned in the /rss feed (and the new libsndfile is not mentioned in the Changelog). There are even newer versions I need to come up with. However, "extracted version" sounds a bit confusing here, given that "extract" is one of the port phases - nothing's being "extracted" here, in that sense. Could we make it "detected version" or something not coliding with "extract"? Jan
Re: livecheck - extracted version is older
On Thu, Mar 30, 2017 at 6:09 PM, Jan Stary wrote: > This is 2.4.99 on 10.6.8 > > $ sudo port clean --all opencore-amr > ---> Cleaning opencore-amr > $ port livecheck opencore-amr > Error: livecheck failed for opencore-amr: extracted version '0.1.2' is > older than livecheck.version '0.1.3' > "Extracted version" should be the version that livecheck extracted from the web page it checks for the latest version information. So the message is saying that it's being told the latest version is older than the current version. This may mean the page changed format and the livecheck regex needs to be updated, or it's checking the wrong page and needs to be updated to look at a page that has the actual current version. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
livecheck - extracted version is older
This is 2.4.99 on 10.6.8 $ sudo port clean --all opencore-amr ---> Cleaning opencore-amr $ port livecheck opencore-amr Error: livecheck failed for opencore-amr: extracted version '0.1.2' is older than livecheck.version '0.1.3' $ find /opt/local/var/macports/ -name \*opencore\* /opt/local/var/macports//registry/portfiles/opencore-amr-0.1.3_0 /opt/local/var/macports//software/opencore-amr /opt/local/var/macports//software/opencore-amr/opencore-amr-0.1.3_0.darwin_10.i386.tbz2 What "extracted version 0.1.2"? Jan
