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

David Blaikie dblaikie at gmail.com
Fri Jan 11 15:24:21 PST 2013

On Fri, Jan 11, 2013 at 3:19 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote:
> 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.

Which release process document are you referring to that indicates that?

Generally, so far as I know, this kind of post-release change is unprecedented.

>> -- Brooks
> PaweĊ‚
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list