Closed PaulWessel closed 8 months ago
A couple options:
Yes, that works. Instead of removing (because the signing worked on my M1) I will add another option, e.g., -s, that is needed to do signing. Thanks @maxrjones for reminding me where that happened.
Remind me, your UH account is maxjones or mjones?
admin/bulid-release
[-s] now works. I signed it on arm64 and not on X68_64.
@seisman, I think we are good to release 6.5. no? I would feel better if you handled the release stuff (git, GitHub, and set tag etc) as I tend to foul that up.. Once released I can do the release of new oceania data (or @Esteban82 could if he is able to).
OK. I'll let you know when I finish the git release.
@PaulWessel Could you please upload the tarballs and installers to the GMT FTP first?
SUre, forgot. I put them on my pub release page but will do this now.
Done, I hope, even with correct permission I think.
The file permissions are incorrect.
Win installer and portable
https://fct-gmt.ualg.pt/tmp/GMT5/gmt-6.5.0-win64.exe 0B4D47058E0B00F20A467DBA260AAB6238B705E8C6C6FA5B0D7FB237410532E2
https://fct-gmt.ualg.pt/tmp/GMT5/gmt-6.5.0-win64.zip DE7E05F87896FFB87E73F24EFB2FE21BE608CDED02AE0C3569652866E1448658
Quick question: we no longer provide the win32 installer?
No, those are deprecated I think, per @joa-quim .
Win installer and portable https://fct-gmt.ualg.pt/tmp/GMT5/gmt-6.5.0-win64.exe 0B4D47058E0B00F20A467DBA260AAB6238B705E8C6C6FA5B0D7FB237410532E2 https://fct-gmt.ualg.pt/tmp/GMT5/gmt-6.5.0-win64.zip DE7E05F87896FFB87E73F24EFB2FE21BE608CDED02AE0C3569652866E1448658
Quick question: we no longer provide the win32 installer?
OK, we dropped the win32 support in https://github.com/GenericMappingTools/gmt/issues/6857.
@PaulWessel The file permissions on the FTP are still incorrect.
You mean the binary files. Yes. just added r t to group and other.
The win64 installer is likely incorrect.
Win installer and portable
https://fct-gmt.ualg.pt/tmp/GMT5/gmt-6.5.0-win64.exe 0B4D47058E0B00F20A467DBA260AAB6238B705E8C6C6FA5B0D7FB237410532E2
https://fct-gmt.ualg.pt/tmp/GMT5/gmt-6.5.0-win64.zip DE7E05F87896FFB87E73F24EFB2FE21BE608CDED02AE0C3569652866E1448658
This is the sha256sum from @joa-quim, but the one on the GMT FTP has:
e2253092cea91ce72adf994fdbbb51b2703b3406c2feb36410e79f9e0aac8990 gmt-6.5.0-win64.exe
Not sure how that happened but use @joa-quim's numbers (and even file if in doubt).
I've made the 6.5.0 release at https://github.com/GenericMappingTools/gmt/releases/tag/6.5.0, using @joa-quim's files and sha256sums in https://github.com/GenericMappingTools/gmt/issues/8017#issuecomment-1874444352.
Apprarently, @joa-quim edited the sha256sum numbers yesterday:
e2253092cea91ce72adf994fdbbb51b2703b3406c2feb36410e79f9e0aac8990
is the old sha256sum number. It means the one on the GMT FTP is the old one.
@PaulWessel Please download the latest win64 installers (both the exe and the zip) from https://github.com/GenericMappingTools/gmt/issues/8017#issuecomment-1874444352 and upload them to the FTP server again.
The two Win binary files have been placed in the gmt ftp on SOEST ftp server and should have correct permissions.
I guess next steps are
FYI, I've uploaded the tarball to Zenodo. The new record is at https://zenodo.org/records/10119499.
I added a news item on the forum under Announcement. Feel free to edit if my links are off...
Paul, do you want me to do this?
Sure. Forst do a git pull as I have made two changes:
Since you did test-release.sh earlier and this is very similar except using server we should be good to go, and if anything goes wrong we have all the files we need still in candidate. Please go ahead.
So should just be
make server-release
which runs the right script.
@PaulWessel I am affraid I can't do it
-bash-4.2$ pwd
/tmp
-bash-4.2$ ls -la release.sh
-rwx--x--x 1 pwessel gmt 602 ene 7 03:14 release.sh
-bash-4.2$ bash release.sh
bash: release.sh: Permission denied
Sorry, I need to delete that first. Hold a few seconds.
OK, gone , should work now.
Now I could run it.
I am getting a lot of messages like this: I would say that for every directory.
rsync: failed to set times on "/export/gmtserver/gmt/data/server/.": Operation not permitted (1)
rsync: failed to set times on "/export/gmtserver/gmt/data/server/earth": Operation not permitted (1)
rsync: failed to set times on "/export/gmtserver/gmt/data/server/earth/earth_day": Operation not permitted (1)
Yes, I think they are harmless. This is what Ross told me I think: If I (or you) create some files then the other person cannot change permissions etc and get these types of messages. Probably rsync info that gets messed up.
I expect the solution is to have a single user (e.g., gmtdata@soest.hawaii.edu) that we both use when doing server work. In fact, it would be inserted into the various scripts.
I also need to but EarthScope Consortium about taking over the hosting of these data since at some point teh SOEST server will get old and die (and me too!) so then we need to have bus-factor protection for this part of GMT. I will look into who I should contact.
Please check if you see anything funky regarding to permissions on oceania now, and if you can run plots from oceania and not set candidate server first.
It finished. This was the last message.
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1179) [sender=3.1.2]
I test the oceania server and it is working fine.
I am struggling a bit with making a USA map:
gmt grdimage @earth_relief_02m -B -RUS -png map
gmt [WARNING]: gmt_get_dataset_tiles: No earth_relief_02m_p tiles available for your region.
grdimage [ERROR]: Grid x range <= 0.0
grdimage [ERROR]: Make sure west < east for geographic coordinates
grdimage (gmt_api.c:2126(gmtapi_init_grdheader)): Please select compatible -R and -I values
grdimage [WARNING]: Your grid x's or longitudes appear to be outside the map region and will be skipped.
grdimage [WARNING]: No grid or image inside plot domain
but works fine for Argentina, for example.
I am struggling a bit with making a USA map:
I can't either. I could with 06m.
gmt grdimage @earth_relief_06m -B -RUS -png map
I just made the annoucement on instagram (https://www.instagram.com/p/C10k8Q9MN-m/).
BTW, I think that we should announce also the new remote data sets available. I am thinking that I figure similar to this would be good. Could you do it @PaulWessel ?
https://www.instagram.com/p/CaFJFieLJ2y/?utm_source=ig_web_copy_link&igsh=MzRlODBiNWFlZA==
I check it on windows and looks fine.
- Remko and I could setup a zoom or async work on debugging the dvc issues
Thanks @maxrjones . I just installed the latest dvc with Python 3.12 and it suddenly works. I was not able to get any downloads in the past, despite getting no error message from dvc pull
. But as said: this suddenly seems to have repaired itself.
- make announcements on the GMT twitter
Do we still want to do this? I think so, we have more than 1000 followers on Twitter.
Close it if no one cares about Twitter.
Any one care about Must and X? @leouieda, @maxrjones , or @Esteban82 ?
Any one care about Must and X? @leouieda, @maxrjones , or @Esteban82 ?
I don't have interest in X
Me neither.
OK, whoever wants to can remove the Twitter reminder from our checklist.
OK, whoever wants to can remove the Twitter reminder from our checklist.
Done and pushed directly to the master branch.
Version: 6.5
Scheduled date: Jan, 5, 2024
Before release:
src/gmt_make_*.sh
to update some .c and .h filesadmin/gs_check.sh
to test if latest ghostscript version worksdoc/rst/_static/version_switch.js
if it's a minor releasecmake/ConfigDefault.cmake
GMT_VERSION_YEAR
is current yearGMT_PACKAGE_VERSION_*
is correctly setGMT_LIB_SOVERSION
is correctly setGMT_PUBLIC_RELEASE
toTRUE
GMT_VERSION_DOI
Release:
After release:
GMT_PACKAGE_VERSION_*
incmake/ConfigDefault.cmake
#8263set (GMT_PUBLIC_RELEASE TRUE)
line #82633rd-party update
Volunteers needed! Please let us know if you volunteer to help to maintain GMT in these 3rd-party tools.