[PROJ] PROJ 9.4.0RC1 & PROJ-data 1.17RC1

[Kristian Evers]

> 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 <proj at lists.osgeo.org> 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 <proj at lists.osgeo.org <mailto:proj at lists.osgeo.org>> 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
>> PROJ at lists.osgeo.org <mailto:PROJ at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/proj
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20240229/8570c5e7/attachment.htm>