Obsolete PTX is NOT completely removed in 3.2 release

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?

  Thanks.

Regards,
chenwj

Removed from trunk. Pawel can decide if its necessary to update the tarballs.

Thanks for the report! Apparently git-svn does not delete removed directories.

Removed from trunk. Pawel can decide if its necessary to update the
tarballs.

Thanks for the report! Apparently git-svn does not delete removed
directories.

PTX directories still exists in release_32 branch and RELEASE_32/final.
But they are all empty so PTX can not be build.

> Removed from trunk. Pawel can decide if its necessary to update the
> tarballs.
>
> Thanks for the report! Apparently git-svn does not delete removed
> directories.

PTX directories still exists in release_32 branch and RELEASE_32/final.
But they are all empty so PTX can not be build.

Right, I only deleted them on 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.

- Ben

> 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

- Ben

>
>
> > 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

Huh... that was a bit premature.

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.

-- Brooks

>
>
> >
> >
> > > 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.

Yeah, that's bad news. What concerns me is that I don't remember seeing
any official notification of a new release, not that there is cause to in
this case anyway.

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?

-- Brooks

Paweł

There are two valid tarballs with different hashes. If you use a single expected hash to verify validity of a tarball you can flag a false-positive error.

-Krzysztof

>>
>>
>>>
>>>
>>>> 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?

Many of these environments rely on checking against a known-good checksum.
If a tarball is replaced at the source, that checksum changes. Once a
release is cut, that particular release should never change. If a change
is necessary, some sort of point release (3.2.1) is preferable, so anyone
wanting 3.2 still gets the old binary with the old checksum.

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?

Many of these environments rely on checking against a known-good checksum.
If a tarball is replaced at the source, that checksum changes. Once a
release is cut, that particular release should never change. If a change
is necessary, some sort of point release (3.2.1) is preferable, so anyone
wanting 3.2 still gets the old binary with the old checksum.

Current process does not have any provision for any more releases
beyond 3.2.

Frankly, anybody who depends on the release should have been
involved in it during RC1,RC2 or RC3 at the latest.

Paweł

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.

-- Brooks

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ł

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.

Replacing an existing tarball is inexcusable. Period. Use a different
name or directory if you want to role a new tarball, but don't just
replace the existing one.

Joerg

Pawel,

We all understand that you're pretty new to release process, etc., but
I think you should understand the implications of your actions.

You just created a lot of harm for really huge pile of users - the
ones who downloads the tarball via some automated build system and
rely on the known good checksum. This includes, but not limited to to
the users of FreeBSD, Gentoo, etc.

Even worse, you did this silently. Without any announcement, with any
e-mail to llvm-dev, etc. And all this at the same time when people do
wide announcement for e.g. 30 mins of restart of buildbot master ro 10
minute restart of web server.

What you did it definitely inacceptable for release manager of such
big project as LLVM. So, may I kindly ask you to revert the tarball
back within next 24 hours an write and entry to New section on the
website. If you want to include the changes name them 3.2.1 or 3.2a
and write an entry on the website. This is the only way how you can
fix all the weird stuff you done in a moment.

All: If anyone has the old taball + sig please let me know where I can
download them to replace the current ones if Pawel will fail to do so.

Pawel,

We all understand that you're pretty new to release process, etc., but
I think you should understand the implications of your actions.

You just created a lot of harm for really huge pile of users - the
ones who downloads the tarball via some automated build system and
rely on the known good checksum. This includes, but not limited to to
the users of FreeBSD, Gentoo, etc.

Even worse, you did this silently. Without any announcement, with any
e-mail to llvm-dev, etc. And all this at the same time when people do
wide announcement for e.g. 30 mins of restart of buildbot master ro 10
minute restart of web server.

What you did it definitely inacceptable for release manager of such
big project as LLVM. So, may I kindly ask you to revert the tarball
back within next 24 hours an write and entry to New section on the
website. If you want to include the changes name them 3.2.1 or 3.2a
and write an entry on the website. This is the only way how you can
fix all the weird stuff you done in a moment.

All: If anyone has the old taball + sig please let me know where I can
download them to replace the current ones if Pawel will fail to do so.

Aren't they available on svn?

http://llvm.org/svn/llvm-project/www-releases/trunk/3.2