Re: New lintian pages available for testing

[tim hall]

tim hall wrote:
I'm not offering to re-invent the wheel at this stage. Having just 
looked at how simple the templates are, I'd be more than happy to do 
some work on the HTML and add some suitable CSS as and when appropriate.


I'm not really sure what passes for good Debian web page design either. 
Any pointers to appropriate pages would be useful.

Something along these lines?

---
/* lintian.css -- Style sheet for lintian.debian.org pages. */

html, body {
background: url('http://lintian.debian.org/bg.gif');
border: 0;
padding: 0;
}

#upperheader {
background: none;
margin: 0;
}

#logo {
background: none;
margin: 0 1em 0 0;
}

.linthead {
color: #00;
font-size: large;
font-weight: normal;
}   

.note {
font-size: small;
}

dt {
font-weight: bolder
}

div.footer {
font-size: smaller;
}
---
[index.tmpl]
---

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>

http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
  

Lintian
mailto:[EMAIL PROTECTED]" />

http://www.debian.org/debian.css"; rel="stylesheet" 
type="text/css" />


  

  

  

  http://lintian.debian.org/";>src="http://lintian.debian.org/logo.gif"; alt="Lintian" width="300" 
height="200" />

 
Lintian
	Lintian dissects http://www.debian.org/";>Debian href="http://packages.debian.org/";>packages and tries to find bugs 
and policy violations. It contains automated checks for many aspects of 
http://www.debian.org/doc/debian-policy/";>Debian policy as 
well as some checks for common errors. 


	 For more information, see the User 
Manual. 


	 Lintian is available in the Debian href="http://packages.debian.org/lintian";>lintian package. 

   
   
  Lintian report indices available: 
	href="reports/maintainers.html">Maintainers

Tag types
Packages: 
  
0-9, A-F
G-L
M-R
S-Z
  

  
   
 


Statistics:

  
Last updated: {$timestamp}
Archive timestamp:{$mirror}
Distribution: {$dist}
Section:  {$section}
Architecture: {$architecture}
Maintainers:  {$delta{maintainers}}
Source packages: 
{$delta{'source-packages'}}
Binary packages: 
{$delta{'binary-packages'}}
Udeb packages: 
{$delta{'udeb-packages'}}

Warnings: {$delta{warnings}}
Errors:   {$delta{errors}}
Info tags:{$delta{info}}
Overridden tags:  {$delta{overridden}}
Experimental tags:{$delta{experimental}}
Lintian version:  {$version}
  

  

 (The numbers in parentheses describe the changes 
since the last Lintian

report, published on {$previous}.) 



Please send all comments about these web pages to the
  mailto:[EMAIL PROTECTED]">Lintian 
maintainers.

  Page last updated: {$timestamp} using Lintian {$version}
 
  

---
cheers,

tim


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New lintian pages available for testing

[tim hall]

Russ Allbery wrote:

tim hall <[EMAIL PROTECTED]> writes:

Russ Allbery wrote:



http://svn.wolffelaar.nl/lintian/trunk/reporting/templates/

will also work.


Thanks. :)


My current forward thinking on the presentation of reports like this is
to have the script deliver pure XML and do all the formatting with
XSL+CSS. That way the formatter wouldn't need to care what the Perl
script was doing.


I'm certainly happy to accept someone else's work in that area, and the
restructuring of html_reports should make it much easier to do this.  I
probably won't have time for this significant of a rearchitecture myself,
though.



Well, in order to start with an XML tree to do transforms, someone is
going to need to write the Perl to generate that from Lintian's log.  I
personally don't have time to do that work.  For better or for worse,
Lintian is written in Perl (which does have a rich set of XML libraries).
Another option would be to rewrite the whole reporting infrastructure in
Python, but that's a much bigger project and you'd have to duplicate some
of Lintian's core libraries to get at things like tag descriptions and
package list parsing.


OK, understood.

I'm not offering to re-invent the wheel at this stage. Having just 
looked at how simple the templates are, I'd be more than happy to do 
some work on the HTML and add some suitable CSS as and when appropriate.


cheers,

tim







--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New lintian pages available for testing

[Russ Allbery]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
> On Wed, Jan 02, 2008 at 04:16:22PM -0800, Russ Allbery wrote:

>> * There are two reports for each maintainer.  The one under maintainer,

> What did you decide for the lists related to the two kind of reports we
> discussed in #458329 ? If you have stable URLs for them (of course
> modulo the fact that the current base URL is there only for testing
> purposes) and, more important, stable format for them we can start
> adding support for them on the PTS side.

I haven't done anything with this yet; qa-list.txt is still just errors
and warnings.  I'm leaning towards adding info, experimental, and override
counts to the same file, since the only thing I knew for sure was using it
isn't running.  However, it looks like qa-list.txt has been unchanged
since before 2004, so I'm still a bit nervous that I might break something.

>> * Multiple maintainers with the same e-mail address will have all their

> Not related, but out of curiosity: will support for Uploaders be part of
> this round of lintian.d.o updates or not?
> /me blatantly trying to mob Russ in order to see it implemented ASAP :-)

Supporting Uploaders isn't too difficult, but it requires changing the
file format of lintian's package lists, which makes it tricky to test on
lintian.d.o.  I may get to it anyway, though.  If it doesn't make this
release, it will be in the next one.

I don't think we've resolved the issue around parsing the Uploaders list
given the presence of Adam C. Powell, IV.  I plan on splitting on comma,
which is going to break for him.  Ah, but I see that the one package for
which he's an Uploader, he dropped the comma.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New lintian pages available for testing

[Russ Allbery]

tim hall <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:

>> If you want to take a look at how good (or bad) the templates look, the
>> ones that generated those pages are in:
>>
>> /org/lintian.debian.org/lintian-test/reporting/templates
>>
>> on gluck.d.o.

> Not being a DD, I probably can't access this.

http://svn.wolffelaar.nl/lintian/trunk/reporting/templates/

will also work.

> My current forward thinking on the presentation of reports like this is
> to have the script deliver pure XML and do all the formatting with
> XSL+CSS. That way the formatter wouldn't need to care what the Perl
> script was doing.

I'm certainly happy to accept someone else's work in that area, and the
restructuring of html_reports should make it much easier to do this.  I
probably won't have time for this significant of a rearchitecture myself,
though.

When making major changes like this, please do be aware that lintian.d.o
is still running on an oldstable system, so cutting-edge Perl modules
probably won't work.

> I don't think my HTML-fu is any better than yours, Russ. In fact I could
> learn a thing or two. I don't understand why [dt id=package-name] when
> #package-name isn't referenced in the .css, but that's probably because
> I'm only looking at this from a formatting POV. Otherwise this looks
> like sensible HTML.

This is for cross-links from other systems, such as the PTS, and within
the lintian.d.o pages (such as from the tags page).

> I'd be happy to put some energy into formatting the output, but I don't
> want to have to even read any Perl. XSL basically turns an XML tree into
> (X)HTML and could easily wrap different tag severities in different
> HTML-tags so each could get their own CSS class. I may be being horribly
> naive here, in which case, a gentle & brief explanation why would help
> me understand better if anyone feels moved. ;)

Well, in order to start with an XML tree to do transforms, someone is
going to need to write the Perl to generate that from Lintian's log.  I
personally don't have time to do that work.  For better or for worse,
Lintian is written in Perl (which does have a rich set of XML libraries).
Another option would be to rewrite the whole reporting infrastructure in
Python, but that's a much bigger project and you'd have to duplicate some
of Lintian's core libraries to get at things like tag descriptions and
package list parsing.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New lintian pages available for testing

[Stefano Zacchiroli]

On Wed, Jan 02, 2008 at 04:16:22PM -0800, Russ Allbery wrote:
> http://lintian.debian.org/reports-testing/

This looks great!, many thanks for it.

> * There are two reports for each maintainer.  The one under maintainer,

What did you decide for the lists related to the two kind of reports we
discussed in #458329 ? If you have stable URLs for them (of course
modulo the fact that the current base URL is there only for testing
purposes) and, more important, stable format for them we can start
adding support for them on the PTS side.

> * Multiple maintainers with the same e-mail address will have all their

Not related, but out of curiosity: will support for Uploaders be part of
this round of lintian.d.o updates or not?
/me blatantly trying to mob Russ in order to see it implemented ASAP :-)

Cheers and thanks again.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: New lintian pages available for testing

[tim hall]

Russ Allbery wrote:

Thijs Kinkhorst <[EMAIL PROTECTED]> writes:

On Thursday 3 January 2008 01:16, Russ Allbery wrote:



http://lintian.debian.org/reports-testing/

This looks good in general, it's a clear improvement over what we have.


Thanks!


* The HTML pages are now templatized (using Text::Template).  The core of
  many of the pages is still generated by some not-horribly-pleasant Perl
  embedded in the templates, but all of the transformation from data to
  HTML should now be in the templates so that someone can modify them
  independent of the main script.

Great. Would this include the capability to wrap different tag
severities in different HTML-tags so each could get their own CSS class?


Yes, that should be fairly straightforward.  That sort of modification
will require changing the Perl, but hopefully it's not too hideous to
read.  (I admit that I made the Perl a bit ugly to make the HTML pretty, a
long-standing habit of mine from writing other generator software but
possibly not the right choice.)

The HTML output from inside the templates would have probably benefitted
from using some nice module that turns trees into HTML or something, but
given that lintian.d.o's host is still running oldstable, I decided not to
test my luck with fancy Perl modules.

If you want to take a look at how good (or bad) the templates look, the
ones that generated those pages are in:

/org/lintian.debian.org/lintian-test/reporting/templates

on gluck.d.o.


Not being a DD, I probably can't access this.

My current forward thinking on the presentation of reports like this is 
to have the script deliver pure XML and do all the formatting with 
XSL+CSS. That way the formatter wouldn't need to care what the Perl 
script was doing.


I don't think my HTML-fu is any better than yours, Russ. In fact I could 
learn a thing or two. I don't understand why [dt id=package-name] when 
#package-name isn't referenced in the .css, but that's probably because 
I'm only looking at this from a formatting POV. Otherwise this looks 
like sensible HTML.


I'd be happy to put some energy into formatting the output, but I don't 
want to have to even read any Perl. XSL basically turns an XML tree into 
(X)HTML and could easily wrap different tag severities in different 
HTML-tags so each could get their own CSS class. I may be being horribly 
naive here, in which case, a gentle & brief explanation why would help 
me understand better if anyone feels moved. ;)


My primary interest in this is as one of the Debian derivatives who 
might ultimately want to put up their own themed (or further filtered) 
pages.


cheers,

tim



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New lintian pages available for testing

[Thijs Kinkhorst]

On Thu, January 3, 2008 10:00, Lars Wirzenius wrote:
> That would mean that it gets harder to get one or the other version of
> the page: it's no longer enough to just go to the page, you also have to go
> click on something else as well. For something that is a simple report
> page, I don't think that's warranted. For DDPO it's more warranted, given
> that DDPO is more of an "application", and also seems to be able to
> remember your state. For lintian, I don't think it's worth the
> complication.

You could make it start out with the full output if you request it with a
?full=1 URL parameter. That could satisfy both wishes.


Thijs


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New lintian pages available for testing

[Lars Wirzenius]

On to, 2008-01-03 at 08:48 +0100, Thijs Kinkhorst wrote:
> I was thinking that this could be better implemented by generating one page 
> per maintainer with all tags, and that I and O are hidden elements by 
> default. A link on the page would then just toggle the visibility of that CSS 
> class (just like the legend at the top of the DDPO).

That would mean that it gets harder to get one or the other version of
the page: it's no longer enough to just go to the page, you also have to
go click on something else as well. For something that is a simple
report page, I don't think that's warranted. For DDPO it's more
warranted, given that DDPO is more of an "application", and also seems
to be able to remember your state. For lintian, I don't think it's worth
the complication.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New lintian pages available for testing

[Russ Allbery]

Thijs Kinkhorst <[EMAIL PROTECTED]> writes:
> On Thursday 3 January 2008 01:16, Russ Allbery wrote:

>> http://lintian.debian.org/reports-testing/
>
> This looks good in general, it's a clear improvement over what we have.

Thanks!

>> * The HTML pages are now templatized (using Text::Template).  The core of
>>   many of the pages is still generated by some not-horribly-pleasant Perl
>>   embedded in the templates, but all of the transformation from data to
>>   HTML should now be in the templates so that someone can modify them
>>   independent of the main script.
>
> Great. Would this include the capability to wrap different tag
> severities in different HTML-tags so each could get their own CSS class?

Yes, that should be fairly straightforward.  That sort of modification
will require changing the Perl, but hopefully it's not too hideous to
read.  (I admit that I made the Perl a bit ugly to make the HTML pretty, a
long-standing habit of mine from writing other generator software but
possibly not the right choice.)

The HTML output from inside the templates would have probably benefitted
from using some nice module that turns trees into HTML or something, but
given that lintian.d.o's host is still running oldstable, I decided not to
test my luck with fancy Perl modules.

If you want to take a look at how good (or bad) the templates look, the
ones that generated those pages are in:

/org/lintian.debian.org/lintian-test/reporting/templates

on gluck.d.o.

> I was thinking that this could be better implemented by generating one
> page per maintainer with all tags, and that I and O are hidden elements
> by default. A link on the page would then just toggle the visibility of
> that CSS class (just like the legend at the top of the DDPO).

This sounds like a great idea to me; it's just beyond my personal HTML
foo.  However, the new generation system creates a style sheet, which is
currently almost empty, and the idea was that anyone who knows how to do
things like this could centralize all the necessary CSS there.

> The advantage is less output to generate and no need to reload a page
> between toggles. A possible drawback could be that the E/W pages get a
> larger filesize. Are there significantly more I+O tags so that the
> 'full' pages are getting very large?

gluck:/org/lintian.debian.org/www/reports-testing> du -sh full maintainer
30M full
20M maintainer

Nah.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New lintian pages available for testing

[Thijs Kinkhorst]

Hi Russ,

On Thursday 3 January 2008 01:16, Russ Allbery wrote:
> http://lintian.debian.org/reports-testing/

This looks good in general, it's a clear improvement over what we have.

> * The HTML pages are now templatized (using Text::Template).  The core of
>   many of the pages is still generated by some not-horribly-pleasant Perl
>   embedded in the templates, but all of the transformation from data to
>   HTML should now be in the templates so that someone can modify them
>   independent of the main script.

Great. Would this include the capability to wrap different tag severities in 
different HTML-tags so each could get their own CSS class?

> * There are two reports for each maintainer.  The one under maintainer,
>   matching the existing URL scheme, shows errors and warnings as before.
>   The one under full shows all tags, including info and overridden tags.
>   The tag index links to the full page, and the maintainer index links to
>   both.

I was thinking that this could be better implemented by generating one page 
per maintainer with all tags, and that I and O are hidden elements by 
default. A link on the page would then just toggle the visibility of that CSS 
class (just like the legend at the top of the DDPO).

The advantage is less output to generate and no need to reload a page between 
toggles. A possible drawback could be that the E/W pages get a larger 
filesize. Are there significantly more I+O tags so that the 'full' pages are 
getting very large?

thanks,
Thijs


pgplwf7Rbsi9J.pgp
Description: PGP signature