The PTS should link to clang.debian.net for packages that fail to build
with LLVM/Clang. More information about clang.d.n is here:

http://sylvestre.ledru.info/blog/sylvestre/2013/02/06/rebuild_of_debian_using_clang_3_2

Requirements from the clang.d.n site:

Per-source-package pages with predictable URLs and links to build logs.

A list of source packages which the PTS should link to. This can just be
a new-line separated list of packages.

If more than just a link is needed, machine-readable info about what
should be presented will be needed.

I can do that this week end.  :)

We had this discussion a while ago:
http://lists.debian.org/debian-qa/2012/02/msg00089.html
At this time, you didn't had any preference on the format. Is it still
the case ? I write some various formats if you want.

Thanks again,
Sylvestre

Great :)

Woops!

Lets start with a newline separated list of source packages that the
PTS should link to. It will link to the clang source package URLs with
the text "clang build issues".

If you want to add TODO items we can switch to something else later.

It is was you expect ?
http://clang.debian.net/pts.php

It is basically
$1 = package name
$2 = version
$3 = url to the log
$4=>end = the detected error

Not sure you need the last item.

Sylvestre

Thanks, I've added a link to the build logs, you can see examples here
until the next full build:

http://packages.qa.debian.org/0/0ad.html
http://packages.qa.debian.org/w/warzone2100.html

For now the code only uses the package names and log URLs.

Further thoughts:

Instead of linking directly to the build log, it would be nice to link
to a page on clang.d.n for each source package, listing just the
errors and warnings for the current package with links to the current
and past build logs.

Could you set the page MIME type to text/plain? It clearly should not
be text/html.

Do you want anything more than a link in the links section on the PTS?

* Sylvestre Ledru <sylvestre.ledru@scilab-enterprises.com> [130208 17:37]:

Is there a way to have a whitelist for issues the package maintainer
can actually fix? When showing issues in PTS that can only be fixed
by extending clang you only train maintainers to ignore the warning
so they might miss it once this finds an actual issue.

        Bernhard R. Link

I think this bug was fixed and am closing it. If something still needs
to be done, please reopen and state it.

Gio.

Control: reopen -1

Currently the PTS links to the clang build logs all the time, even when
the package is in Needs-Build state. I think it would be more useful to
link only when the package has been built or failed to build. Sylvestre,
could we get a text file with a list of packages not at Needs-Build?

Hi Paul.

Il 17/08/2013 11:05, Paul Wise ha scritto:

Personally I'd prefer to have the link for all packages rebuilt with
clang, but do as you wish.

Gio.

Could you explain why knowing that a package is Needs-Build for clang
based builds is useful to you? Needs-Build is useful for the official
gcc based buildds because this state has other effects on the package,
like not being able to transition to testing. For the clang based
builds, clicking on the clang link just to find out that the clang-based
buildds haven't yet built it is basically a waste of maintainer time as
far as I can tell. The PTS has traditionally tried to avoid doing that.

Any opinions from other folks?

Hi.

Il 17/08/2013 14:14, Paul Wise ha scritto:

Mostly I don't like PTS links to be too volatile; for me, the presence
of a "clang" link just says that the clang service is meaningful with
respect to this (source) package. It is reasonable to add another small
piece of information to avoid wasting the users' time, but just loosing
the link to clang is (in my opinion) not very friendly.

Anyway, I think it is not the first time I have a different opinion from
the design principles of PTS. I can live with it, my opinion is not
really strong.

Gio.

With the PTS rewrite to be more dynamic, there is the possibility that
we could add logins or cookie-based ways for you to have what you want
while leaving the PTS showing as minimal info as possible by default.

So, the design principle at stake here is slightly different. The point
of it has always been to avoid having visitor click on a link just to
discover whether there is something for them there or not.

Such a principle has often been implemented by making links "volatile",
as you say, but that's not the only way to do it.  In this specific case
one can for instance have a link and decorate it with a trailing "(X)"
where X is the number of "things" to be seen there.

This way, the visitor can learn that they do not need to click if the
annotation is not there, and everyone else who want the link to be
always present can be happy too.

OTOH, if it really there is *nothing to see* in the "(0)" case, it is
indeed probably pointless to have the link in the first place. YMMV.

Cheers.

Hi,

There is hyperlink "old" there, which gives fast access to logs of old builds.
It may be useful for someone.

Best wishes,
Boris

Hmm, good point. For the current static PTS it would probably be best if
the link were to stay in all cases then. For the new dynamic PTS,
perhaps a preference for when to show the clang link could be added:

      * always
      * when the current version failed
      * when a previous version failed
      * when the current version has been tried
      * when a previous version has been tried