[LLVMdev] Obsolete PTX is NOT completely removed in 3.2 release

[Pawel Wodnicki]

On 1/11/2013 3:59 PM, Brooks Davis wrote:
> On Fri, Jan 11, 2013 at 02:47:01PM -0600, Pawel Wodnicki wrote:
>> On 1/11/2013 2:40 PM, Brooks Davis wrote:
>>> On Fri, Jan 11, 2013 at 09:33:17PM +0100, Benjamin Kramer
>>> wrote:
>>>> 
>>>> On 11.01.2013, at 21:31, Justin Holewinski 
>>>> <justin.holewinski at gmail.com> wrote:
>>>> 
>>>>> On Fri, Jan 11, 2013 at 3:26 PM, Benjamin Kramer 
>>>>> <benny.kra at gmail.com> wrote:
>>>>> 
>>>>> On 11.01.2013, at 07:36, ????????? (Wei-Ren Chen) 
>>>>> <chenwj at iis.sinica.edu.tw> wrote:
>>>>> 
>>>>>> Hi Pawel,
>>>>>> 
>>>>>> PTX already be replaced with NVPTX. However, PTX
>>>>>> subdirectory still sit in lib/Target in 3.2 release. Do
>>>>>> you think update the release tarball is a good idea? Also
>>>>>> could you remove it from the trunk?
>>>>> 
>>>>> Please do not, under no circumstances, change the 3.2
>>>>> release tarballs at this point. They are mirrored around
>>>>> the world now with cryptographic hashes and signatures.
>>>>> Changing them will break things for many people, especially
>>>>> for an extremely minor thing like an empty directory.
>>>>> 
>>>>> I'm not sure if Pawel's tarball change should be reverted
>>>>> now as it already caused uproar, so changing it back might
>>>>> only make matters worse.
>>>>> 
>>>>> The tarballs were changed?
>>>> 
>>>> r172208
>>> 
>>> I finally updated the FreeBSD ports yesterday and today a user
>>>  complained about distfile changes.  IMO, this revision should
>>> be reverted or all the other BSDs will have to chase checksums
>>> as well.
>>> 
>>> If you really want to remove the directory, ship a 3.2.1
>>> tarball rather than screwing all the downstream consumers who's
>>>  infrastructure exists to detect trojan'd tarballs.
>> 
>> Tarball is signed, it is not trjoan. Your infrastructure should
>> be able to deal with it?
> 
> The FreeBSD ports collection maintains a set of sha256 hashes for 
> each distfile.  The system can deal with them changing, but it's
> an inconvenience to port maintainers and users.  Even if we did
> have infrastructure to verify the signatures we'd still have to
> check the contents and would not just trust the signature since
> there's always a risk of keys being compromised.

 Since you do not use llvm.org security features (signatures) I think
understanding your process will be useful to whoever is doing the next
release. I would suggest communicating it early in the release cycle.

 As for the inconvenience with the 3.2, I really do not have a choice
under current release process. Changes have been made in the SVN
branches and tarball has to reflect that.

> 
> -- Brooks
> 

Paweł