> So don't worry Kristian, it is not you, it is Mac ;) I’m glad it’s not just me. Was thinking I was going insane for a minute there. I’m a bit puzzled as to what has changed though. It could possibly be that I upgraded to a newer MacOS version over Christmas. That usually means an upgrade to Xcode as well and that might have done… something.
Commenting on a few other things: > To share the burden, I've just manually created a RC4 from a repackaged RC3 > on the download server Thanks, Even. For the final release I’ll simply rename this file and upload it again. I believe that is the safest thing I can do this time around. > `tar tzvf proj-data-1.17RC2.tar.gz` does work on Mac, but it ignores the ._ > files, they are also not present after unpacking the archive. That explains why I couldn’t see the same files as you guys. I did run that exact command, as well as unpacking the files using two separate tools. Based on that I felt quite comfortable no bad files were in RC2 and RC3. Sneaky stuff. Thanks for helping clear this up. I am not sure how to avoid this in the future. For now I think the best thing I can do is to delete my local copy of the PROJ-data repo and make a new clone. Hopefully that leaves me with a set of files without any extra MacOS attributes. That method doesn’t feel particularly foolproof though, so I think it is time to look into automating the release process. For another project I am working on, I have been looking into saving artifacts from GitHub Action runs and publishing them as releases on GitHub. I don’t think that would be too difficult to setup for PROJ-data. /Kristian > On 28 Feb 2024, at 19.13, Javier Jimenez Shaw via PROJ <[email protected]> > wrote: > > > > For the next time we should use a different prefix, now that we know that Mac > is doing something special. > > On Wed, 28 Feb 2024 at 19:04, Sebastiaan Couwenberg via PROJ > <[email protected] <mailto:[email protected]>> wrote: >> On 2/28/24 6:28 PM, Kristian Evers via PROJ wrote: >> > I’m on a Mac and they don’t always behave as you would expect coming from >> > a Linux system. For instance, Bas’ tar command doesn’t fly with my >> > particular brand of tar: >> > >> > $ tar tavf proj-data-1.17RC2.tar.gz | grep '\._' >> > tar: Option -a is not permitted in mode -t >> >> -a is likely a GNU tar specific option. I'm remember cursing grep on >> Solaris not supporting -A/-B/-C back in the day. >> >> `tar tzvf proj-data-1.17RC2.tar.gz` does work on Mac, but it ignores the >> ._ files, they are also not present after unpacking the archive. >> >> > Unpacking the file surprisingly doesn’t reveal anything either. You’d >> > think this sort of thing was easy to figure out but here we are. I am not >> > the release manager you deserve but the one you got. Sorry. >> >> Apparently the ._ files are an Mac thing for extended attributes: >> >> >> https://unix.stackexchange.com/questions/282055/a-lot-of-files-inside-a-tar >> >> Kind Regards, >> >> Bas >> >> -- >> GPG Key ID: 4096R/6750F10AE88D4AF1 >> Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 >> >> _______________________________________________ >> PROJ mailing list >> [email protected] <mailto:[email protected]> >> https://lists.osgeo.org/mailman/listinfo/proj > _______________________________________________ > PROJ mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
