Re: macports localinstall github tries to download from macports
On Apr 29, 2020, at 08:12, macpo...@parvis.nl wrote: > On 2020-04-29, at 13:11, Ryan Schmidt wrote: > >> On Apr 28, 2020, at 06:58, macpo...@parvis.nl wrote: >> >>> Ryan Schmidt said: >>> You want: github.setupsnabb downtimed 1.0 version- github.tarball_from archive >>> >>> but that results in >>> https://github.com/snabb/downtimed/archive/version-1.0/downtimed-1.0.tar.gz >>> (the version number in 2 places). >> >> That's correct. It works. Use it. > > indeed it works,but can you explain why it works? > > we want: > https://github.com/snabb/downtimed/archive/version-1.0.tar.gz > > port distfiles says: > https://github.com/snabb/downtimed/archive/version-1.0/downtimed-1.0.tar.gz The GitHub web site / web server is programmed to allow both forms to work. In fact you can specify any filename with a .tar.gz extension after the tag name, so this also works: https://github.com/snabb/downtimed/archive/version-1.0/anything.tar.gz When I wrote the github 1.0 portgroup I decided to program it to use the distfile naming scheme that we most commonly see with other projects outside of GitHub, namely ${name}-${version}${extract.suffix}. I dislike distfile names that do not contain the project name, so since it was possible for us to avoid that problem, I chose to have the portgroup do so.
Re: macports localinstall github tries to download from macports
> On 2020-04-29, at 13:11, Ryan Schmidt wrote: > > > > On Apr 28, 2020, at 06:58, macpo...@parvis.nl wrote: > >> Ryan Schmidt said: >> >>> You want: >>> >>> github.setupsnabb downtimed 1.0 version- >>> github.tarball_from archive >> >> but that results in >> https://github.com/snabb/downtimed/archive/version-1.0/downtimed-1.0.tar.gz >> (the version number in 2 places). > > That's correct. It works. Use it. > > >> i tried some variants of distname and tried >> >> github.setupsnabb downtimed 1.0 >> distnameversion-${version} >> master_sites${homepage}/archive >> >> and that works. it this acceptable? > > Don't do that. Use the values that the github portgroup sets for you. indeed it works,but can you explain why it works? we want: https://github.com/snabb/downtimed/archive/version-1.0.tar.gz port distfiles says: https://github.com/snabb/downtimed/archive/version-1.0/downtimed-1.0.tar.gz port fetch says: Attempting to fetch downtimed-1.0.tar.gz from htps://github.com/snabb/downtimed/archive/version-1.0 ---> Fetching distfiles for downtimed ---> downtimed-1.0.tar.gz does not exist in /opt/local/var/macports/distfiles/downtimed ---> Attempting to fetch downtimed-1.0.tar.gz from https://distfiles.macports.org/downtimed % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0---> Attempting to fetch downtimed-1.0.tar.gz from http://lil.fr.distfiles.macports.org/downtimed % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0---> Attempting to fetch downtimed-1.0.tar.gz from http://nue.de.distfiles.macports.org/downtimed % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0---> Attempting to fetch downtimed-1.0.tar.gz from http://cph.dk.distfiles.macports.org/downtimed % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0---> Attempting to fetch downtimed-1.0.tar.gz from https://github.com/snabb/downtimed/archive/version-1.0 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 128 100 1280 0156 0 --:--:-- --:--:-- --:--:-- 156 100 720330 720330 0 31214 0 --:--:-- 0:00:02 --:--:-- 105k
Re: Github macportsbot not running
We ran into a similar issue at work: when the cluster starts it spends some time doing bookkeeping like replaying the logs if the server crashed before. In our case we were starting up completely empty new PostgreSQL containers and they were still taking 15+ seconds to start on occasion because the cloud hosted disks were so slow. Our solution was a bash script that just called psql in a loop until it succeeded. You could shoehorn that into a new systemd unit and have the prbot depend on it. On Wed, Apr 29, 2020 at 4:56 AM Rainer Müller wrote: > > On 29/04/2020 04.07, Chris Jones wrote: > > Looks like the macportsbot has stopped running again , as The latest MRs > > are no longer being labelled. Could someone kick it back into life ;) > > Thank you for the notification! I started it now. prbot had failed to start > after a reboot of the host system: > > prbot-current[1453]: 2020/04/28 09:02:54 pq: the database system is starting > up > > This happened before, but I don't know how we can make this more robust. We > already use After=postgresql.service in the corresponding systemd unit, but > apparently that is not enough. Either there is some other indicator when > postgres has finished its startup, or prbot should retry if it encounters this > error message, or as a last resort we have to add some arbitrary delay. > > Rainer -- David Gilman :DG<
Re: macports localinstall github tries to download from macports
On Apr 28, 2020, at 06:58, macpo...@parvis.nl wrote: > Ryan Schmidt said: > >> You want: >> >> github.setupsnabb downtimed 1.0 version- >> github.tarball_from archive > > but that results in > https://github.com/snabb/downtimed/archive/version-1.0/downtimed-1.0.tar.gz > (the version number in 2 places). That's correct. It works. Use it. > i tried some variants of distname and tried > > github.setupsnabb downtimed 1.0 > distnameversion-${version} > master_sites${homepage}/archive > > and that works. it this acceptable? Don't do that. Use the values that the github portgroup sets for you.
Re: Github macportsbot not running
On 29/04/2020 04.07, Chris Jones wrote: > Looks like the macportsbot has stopped running again , as The latest MRs are > no longer being labelled. Could someone kick it back into life ;) Thank you for the notification! I started it now. prbot had failed to start after a reboot of the host system: prbot-current[1453]: 2020/04/28 09:02:54 pq: the database system is starting up This happened before, but I don't know how we can make this more robust. We already use After=postgresql.service in the corresponding systemd unit, but apparently that is not enough. Either there is some other indicator when postgres has finished its startup, or prbot should retry if it encounters this error message, or as a last resort we have to add some arbitrary delay. Rainer