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?
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
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.
At first your reaction has puzzled me, but despite a few fire
breathing dragons getting loose and after carefully re-reading
these posts over the weekend I think I understand the underlying
Simply put we both take this release seriously.
The problem is the release process is not entirely
defined. Which is reflected in question from David Blaikie
(the other post I am quoting here).
Which release process document are you referring to that indicates
Simple answer is the one on the llvm.org website.
But the real answer is, it all depends on how you read it.
Apparently, we read it differently which is not that
surprising as even our well defined compilers have
a bit of a problem with undefined behavior.
So what can we expect from a release process document?
My hope is that we have reached a sort of sequence
point and the ambiguity of the release process
can be resolved despite all the side effects.
David also stated this:
Generally, so far as I know, this kind of post-release change is
I agree with this conclusion but even more unprecedented
is to a expect timely and problem free release with zero and
I'll repeat again zero involvement from the wider community that
depends on the clang+llvm!
This is how the 3.2 release has happened, just compare
the list of 3.2 to 3.1 binaries and BTW not a single
3.2 binary has been produced with the help of a respective
project, distribution or who ever.
I hear the cries of your wounded infrastructures
and I understand that in the days of forged root certificates
my signature on the tarballs may not guarantee much of a
But why didn't you get involved in the 3.2 release?
We could have resolved all this in the 2 months since
the 3.2 release got rolling. Everybody knew about the
changes for the 3.2 release, simple e-mail to the new
LLVMRM would go a long way to resolve any security or
other release related issues not to mention a bit
of a courtesy.
I am doing this as service to the LLVM community
but frankly I'd rather be chasing my dragons of