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

Pawel Wodnicki root at 32bitmicro.com
Fri Jan 11 15:19:55 PST 2013

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


More information about the llvm-dev mailing list