Bug#373218:

[Raphael]

I'm not wholly adverse to this approach, but there's a lot of stuff that

links to lintian maintainer pages and I'm not particularly thrilled with
the idea of changing those URLs.

I also made the changes to the other pages I could find linking to the
lintian pages.


Why not just fix the qa code to match what lintian does?  It's pretty

clearly currently different, which is probably the root of the problem.
because as far as I could see there have already been many changes on
the naming schema and there are dead links everywhere (try the links
to lintian.debian.org posted by Michal Čihař).


That's the definition of a corner case.  We should still deal with it.
Just because you haven't seen someone use such characters in e-mail

addresses doesn't mean that they're not used, or that they may not be used
in the future.

I have a friend who uses the e-mail address ^*&[EMAIL PROTECTED], which is

entirely valid under RFC 2822.
All that can be handled if all the characters that should be replaced
are listed somewhere.

--
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Bug#389775: please change "experimental" buildd link with something more descriptive

[Raphael Hertzog]

On Wed, 27 Sep 2006, Bernhard R. Link wrote:
> Package: qa.debian.org
> Severity: wishlist
> 
> The "experimental" Buildd Logs link does not only list experimental
> package versions but also non-release archs, thus confusing people
> into thinking there is nothing interesting when there are no
> experimental packages. Please consider changing the text to something
> like "additional"  or "experimental/additional" or "experimental and
> non-release architectures".

What about "unofficial" ? It's buildd logs of unofficial buildd... or does
that sound too pejorative for the people running them ?

Otherwise "more" looks like another neutral solution that is nicer than
"additional" IMO.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Re: Bug#391023: XS-Vcs-field splitting into XS-Vcs-source & XS-Vcs-dpkg

[Raphael Hertzog]

On Sun, 12 Nov 2006, Geert Stappers wrote:
> The text tells about the (upstream) source by using the generic name
> "package", the example tells about the Debian directory.

So fix the wording... and don't change everything when there has been some
serious discussion on -devel and when lots of packages have started using
this convention already.

> So I propose to split into XS-Vcs-source-* & XS-Vcs-dpkg-*

Please, no. The Debian source package is not meant as a source of generic
meta-information of the upstream project.

If you really want to make this kind of information available, you'd
rather work on something useful for this like the collaborative repository
of meta-information:
http://wiki.debian.org/CRMI

(which might be implemented within mole http://wiki.debian.org/mole)

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Automated mails to maintainers to inform them of their pkg status

[Raphael Hertzog]

On Mon, 13 Nov 2006, Lucas Nussbaum wrote:
> Hi,
> 
> With the release getting closer, I have the impression that some (a lot
> of?) maintainers are unaware of the "buginess" status of their packages.
> Of course, there's the weekly mail on d-d-a, but it doesn't really
> answer the question of "are my packages OK ?".
> 
> Ideally, this would reuse a lot of informations from the DDPO,
> mentionning:
> - when a package is not in testing
> - when versions between unstable and testing differ
> - if the package has RC bugs
> - if the package has important or normal bugs
> All of this for maintained and co-maintained packages.
> 
> I don't know if enough code already exist to make this easy and quick to
> write, but it might be something to keep it mind, even if it's only
> executed once a month during normal development.

Full ACK. I would also like to send such reminder mails to the PTS with
statistics concerning the evolution of the package.

I think we should discuss and implement something like this during the QA
meeting in December.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Bug#412033: PTS: extremely noisy when new package closes many bugs

[Raphael Hertzog]

On Fri, 23 Feb 2007, era eriksson wrote:
> Guess twice how many copies of the following message I have received?
> 
> From: Debian Bug Tracking System <[EMAIL PROTECTED]>
> To: Christian Perrier <[EMAIL PROTECTED]>
> Subject: Bug#xx: marked as done (bug title)
> 
> I can understand the motivation for detailed reporting to the package
> owner and the bug submitter, but I think for the majority of PTS
> subscribers just the upload notice would suffice.
> 
> (Tangentially, see also #340863)
> 
> If
> 
> tries to explain how to fix this if you don't like the defaults, then I
> don't understand it, and in any event, does the current default really
> make sense?

Yes the current default makes sense. Sort the messages in another folder
if the volume bothers you. And yes that page explains how to selectively
decide what you want to receive.

> (Opting out from bts-control sounds like it might work, but then do you
> lose other less predictable messages, too?)

bts-control is only messages which follow commands like changing severity,
reassigning, changing subject, etc.

The message that a bug got closed is sent via the "bts" keyword. But if
you're only interested in the upload notice then you should deactivate
everything except "upload-source". Of course, if you deactive the "bts"
keyword you won't receive discussions concerning bug reports.

I don't think there's anything to fix here.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Re: PTS subscriptions unclear

[Raphael Hertzog]

Hello,

On Fri, 23 Feb 2007, Lucas Nussbaum wrote:
> Let's take package feed2imap, for which I'm the maintainer. I think I
> receive a mail when the testing status changes (new version gets into
> testing).
>
> But why I am receiving it ? I'm not subscribed to feed2imap in the PTS.

That's because that mail is sent by someone who mails
feed2imap _AT_ packages.debian.org AND feed2imap _AT_ packages.qa.debian.org

The former goes to the maintainer, the latter to the PTS.

> Are Maintainers automatically subscribed to some of the info ?

Not yet, although there have been plans to merge @packages.d.o and
@packages.qa.d.o, see some notes on http://wiki.debian.org/qa.debian.org/pts

> Now, I'd like to subscribe to other kinds of info (upload-binary and
> derivatives, for example).
> 
> If I subscribe to feed2imap, I'll receive duplicate mails for bts,
> bts-control, upload-source, katie-other, summary.
> 
> So I would have to subscribe to feed2imap, and use "keyword" to remove
> those keywords ? But that sucks, since I would have to do the same for
> all packages I maintain.

Indeed. You can use the advanced subscription feature on each PTS web page to
help you a bit but it just spares you to know the right command.

> Either I'm missing something obvious, or we should work on making PTS
> subscriptions more maintainer-friendly. :)

Ack. Patches are welcome as usual.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Bug#412033: PTS: extremely noisy when new package closes many bugs

[Raphael Hertzog]

On Fri, 23 Feb 2007, Christoph Berg wrote:
> > keyword you won't receive discussions concerning bug reports.
> 
> I agree that the "done" mails from the BTS are quite boring as they
> only repeat the initial mail.

That's because most of the -done mails are generated by dak. But there are
also manual -done mails which have valuable information in that case. We
could special case based on some dak headers but I don't think it's worth
the pain.

> What could maybe changed is the "Advanced mode" for pts subscription
> on the web. It is quite opaque.

Sure, it lacks some description and it only handles one subscription at a
time. We need some authenticated stuff where one can handle all his
subscriptions at the same time.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#412033: PTS: extremely noisy when new package closes many bugs

[Raphael Hertzog]

On Fri, 23 Feb 2007, era eriksson wrote:
> Any chance then you could call that category "bts-dak" or something, and
> at least make it something one could opt out from separately from the
> other stuff? Perhaps the dak maintainer could cooperate to make this
> less painful to code? I don't want to unsubscribe from the current
> "bts", I just want to avoid getting large amounts of completely
> predictable messages.
> 
> I know how to filter my mail, but I'm troubled by the approach to defer
> the issue to the users instead of adapting an existing mechanism (the
> pts keywords) to make it go away entirely.

Sorry, the PTS is not the source of the problem. If something needs
fixing, it's probably the BTS who could be smarter and send a single mail
for all bugs closed instead of forwarding one copy per bug.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Re: [idea] DDPO by mail

[Raphael Hertzog]

Hi,

On Wed, 07 Mar 2007, Lucas Nussbaum wrote:
> > A server side implementation is going to be pretty easy to ignore too:
> > even if one doesn't killfile them automated e-mails often end up being
> > things that are deleted unread based on the subject.  If it doesn't do
> > opt in it's also likely to wind some people up, especially people who
> > keep on top of these things already.
> 
> Of course, but if those mails:
> - stay useful
> - provide an unsubscription mechanism
> 
> I think the win outweights the loss, don't you ?

FWIW, I agree with you. I like the idea that you inform the maintainer of
problems concerning his packages and that he can ack the presence of the
problem in some way.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: XS-Vcs-field

[Raphael Hertzog]

Hello,

On Wed, 09 May 2007, Felipe Sateler wrote:
> Doesn't the PTS also use this information to inform of vcs commits to the
> suscribed users?

No. The PTS forward VCS notifications that it receives, but it doesn't
generate them on its own. Each package/project has to setup its VCS
to send the notifications to [EMAIL PROTECTED]

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Bug#427467: qa.debian.org: possible patch

[Raphael Geissert]

Package: qa.debian.org
Followup-For: Bug #427467

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The first patch (attachment graph.txt.diff.gz) could possibly help with this.
Otherwise the memory limit should be increased (but the more packages are added 
to the repository, the 
higher the memory usage will be).

The second patch (graph.txt.slower.diff.gz) might work a little slower, but 
it's memory usage will be 
low. So 
there won't be any problem when more packages are added to the repository.


- -- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGeXHhYy49rUbZzloRAutRAJ40pnAoQnpm7vhy1lJHMzq4dyGmMgCgn98O
/B5B/0DBBle79vLT1sQ7b7I=
=Bd7A
-END PGP SIGNATURE-


graph.txt.diff.gz
Description: GNU Zip compressed data


graph.txt.slower.diff.gz
Description: GNU Zip compressed data

Bug#373218: qa.debian.org: Patch

[Raphael Geissert]

Package: qa.debian.org
Tags: patch
Followup-For: Bug #373218

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I just wrote a patch for this problem.
The best solution I found it to drop the current naming convention of the 
lintian reports and use the 
maintainer login (the same way most of the other pages do).
So the attachment is the patch against:
http://svn.wolffelaar.nl/lintian/trunk/reporting/html_reports
svn://svn.debian.org/qa/trunk/pts/www/xsl/pts.xsl
svn://svn.debian.org/qa/trunk/wml/developer.wml

I'm not very familiar with XSL but I think it should work just fine.

- -- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGg/ZTYy49rUbZzloRAnaPAKCFxz3Zc/LnetpLUi+1U6uflJg9hwCfTDz0
uxwKw8MA4NakSxoKpjEPPSw=
=d3fF
-END PGP SIGNATURE-
diff -urN orig/developer.wml new/developer.wml
--- orig/developer.wml  2007-05-16 07:33:26.0 -0500
+++ new/developer.wml   2007-06-28 12:19:50.0 -0500
@@ -192,15 +192,11 @@
 html_a("submitted", 
"http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=$ulogin";) . " - " .
 html_a("WNPP", "wnpp.php?login=$ulogin") . " - " .
 html_a("statistics", "http://io.debian.net/~tar/bugstats/?$ulogin";) . 
html_br();
-
-$lintian = preg_replace('/%../', "_", urlencode($name));
-$lintian = preg_replace('/\+/', "_", $lintian);
-$lintian = preg_replace('/-/', "_", $lintian);
 $initial = strtoupper(substr($login, 0, 1));
 $maintainer_data .= "Reports: " .
 html_a("Buildd", "http://buildd.debian.org/pkg.cgi?maint=$ulogin";) . " 
- " .
 html_a("Igloo", 
"http://people.debian.org/~igloo/status.php?email=$ulogin";) . " - " .
-html_a("Lintian", "http://lintian.debian.org/reports/m$lintian.html";) 
. " - " .
+html_a("Lintian", "http://lintian.debian.org/reports/m$ulogin.html";) . 
" - " .
 html_a("Checklib", 
"http://rerun.lefant.net/checklib/maintainers.$initial.html#$ulogin";) . " - " .
 html_a("Debtags", 
"http://debtags.alioth.debian.org/todo.html?maint=$ulogin";);
 static $nm_db;
diff -urN orig/html_reports new/html_reports
--- orig/html_reports   2007-06-28 12:33:42.0 -0500
+++ new/html_reports2007-06-28 12:14:58.0 -0500
@@ -480,11 +480,7 @@
 
 my $file = $maint;
 if ($file) {
-   $file =~ s/^(.+)\<.*$/$1/;
-   $file =~ tr/A-Za-z0-9_.,/_/c;
-   $file =~ s/^_+//g;
-   $file =~ s/_+$//g;
-
+   $file =~ s/^[^<]+\<([^>]+)$/$1/;
$file = "m$file.html";
 } else {
$file = "munsorted.html";
diff -urN orig/pts.xsl new/pts.xsl
--- orig/pts.xsl2007-04-20 12:02:57.0 -0500
+++ new/pts.xsl 2007-06-28 12:32:49.0 -0500
@@ -722,10 +722,10 @@
   
 
   
-  
-  
-  
-http://lintian.debian.org/reports/m{$_name}.html#{$package}";>Lintian 
report
+  
+
+  
+  http://lintian.debian.org/reports/m{$_email}.html#{$package}";>Lintian 
report
   
 
   

Re: Bug#373218: qa.debian.org: Patch

[Raphael Hertzog]

On Thu, 28 Jun 2007, Russ Allbery wrote:
> > --- orig/html_reports   2007-06-28 12:33:42.0 -0500
> > +++ new/html_reports2007-06-28 12:14:58.0 -0500
> > @@ -480,11 +480,7 @@
>  
> >  my $file = $maint;
> >  if ($file) {
> > -   $file =~ s/^(.+)\<.*$/$1/;
> > -   $file =~ tr/A-Za-z0-9_.,/_/c;
> > -   $file =~ s/^_+//g;
> > -   $file =~ s/_+$//g;
> > -
> > +   $file =~ s/^[^<]+\<([^>]+)$/$1/;
> > $file = "m$file.html";
> >  } else {
> > $file = "munsorted.html";
> 
> You can't drop that tr///.  It's what takes care of all the special
> characters that otherwise need escaping.

Since he extracts the email part, it's less of a problem.

> Why not just fix the qa code to match what lintian does?  It's pretty
> clearly currently different, which is probably the root of the problem.

There's no tr///c in XSLT ... it's difficult for me to generate the
proper link to the lintian page because of this. 

Thus I agree (in principle, not necessarily with this patch) with changing
the naming of the lintian pages.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Bug#373218: qa.debian.org: Patch

[Raphael Hertzog]

On Thu, 28 Jun 2007, Russ Allbery wrote:
> Well, he extracts everything between <>, but I believe we still lose if,
> for instance, there's a # in the e-mail address (which is an entirely
> valid RFC 2822 character).  I'm a little worried about +, which is a very
> common character and sometimes has special interpretations in URLs.

So fix the # case (I can do a fixed list of character translation).
Email address can contain almost anything but in practice they don't
contain much fancy stuff compared to real names.  The "+" has a special
meaning only in CGI (GET) parameters AFAIK.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Bug#373218: qa.debian.org: Patch

[Raphael Hertzog]

On Fri, 29 Jun 2007, Russ Allbery wrote:
> According to RFC 2396, the list of characters reserved, banned, or
> disrecommended for URIs are:
> 
> ; / ? : @ & = + $ , < > # % " { } | \ ^ [ ] `
> 
> and space.  The safest thing to do would be to map all of those characters
> to _.  (Some of them we could get away with not mapping, but I prefer to
> appeal to a clear authority for things like this rather than generating a
> custom list.)

I fail to see why / would be banned from an URI. :-)

http://bugs.debian.org/[EMAIL PROTECTED] is a working URL for example.

The "#" clearly has a special meaning in URL... but I haven't seen an
email with that character, the same goes for the rest of your special
characters.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Bug#431305: PTS: Testing version in "Available versions" not uptodate

[Raphael Hertzog]

On Sun, 01 Jul 2007, Rainer Dorsch wrote:
> Package: qa.debian.org
> Severity: normal
> 
> I find for kdelibs at http://packages.qa.debian.org/k/kdelibs.html
> 
> -> in the latest news section
>[2007-06-26] kdelibs 4:3.5.7.dfsg.1-1 MIGRATED to testing (Britney)
> 
> -> in the Available versions section
>Testing  4:3.5.5a.dfsg.1-8

This is related to this ticket:
https://rt.debian.org/Ticket/Display.html?id=130

ftp.debian.org is current desynchronized from Debian's main mirror
(frp-master).

I switched to ftp.us.debian.org for the time being.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#377282: mail to [EMAIL PROTECTED] not delivered to maintainer by default

[Raphael Hertzog]

Hi,

On Mon, 16 Jul 2007, martin f krafft wrote:
> also sprach Raphael Hertzog <[EMAIL PROTECTED]> [2006.07.08.1426 +0200]:
> > The right way to fix this bug is to follow the plan described there:
> > http://wiki.debian.org/qa.debian.org/pts
> > (under the paragraph "Integrate better with
> > @packages.debian.org")
> > 
> > I can easily create the "contact" keyword but someone needs to write a
> > script which does the auto-subscription of maintainers to the PTS. And of
> > course afterwards the [EMAIL PROTECTED] alias need to be changed to always 
> > point to
> > [EMAIL PROTECTED]
> 
> Have you ever been able to do this? I'll look into writing that
> script as soon as the keyword exists.

Feel free to start that script first. :-) Adding the keyword is a matter
of minutes. 

Take care to handle properly the case if the maintainer is already
subscribed. In that case, you have to add the contact keyword only.

Funny thing that you come back to this a few minutes after Joachim
Breitner also discussed the bad integration between the PTS and the BTS
for maintainers (who get BTS mail twice if they don't pay attention to
the list of keywords).

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#377282: mail to [EMAIL PROTECTED] not delivered to maintainer by default

[Raphael Hertzog]

Hi,

On Mon, 16 Jul 2007, martin f krafft wrote:
> also sprach Raphael Hertzog <[EMAIL PROTECTED]> [2007.07.16.2026 +0200]:
> > Feel free to start that script first. :-) Adding the keyword is
> > a matter of minutes. 
> 
> The point was that I wanted to verify the operation of the script on
> my own packages first.

The script needs to run with write access to the database so you're not
going to run it by yourself on the real installation anyway. :)

I can give you a copy of the "live database" for more realistic tests if
you want.

> But I'll get on this, probably during my vacation in August.

Cool.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#433095: DDPO: does not show all my sponsored packages

[Raphael Hertzog]

On Mon, 16 Jul 2007, Christoph Berg wrote:
> > The "Uploader:" tooltip shows only a key ID, but that key id is in fact (a 
> > subkey of) my key. Maybe it doesn't handle subkeys correctly?
> 
> Hi,
> 
> this is another instance of "the projectb doesn't know your keyid
> yet" that happens to every new maintainer (key):
> 
>   id  |  uid   |  name   
> --++-
>  1319 | thijs  | Thijs Kinkhorst
> 
>   id  |   fingerprint| uid  
> --+--+--
>  5823 | F7867D1E8EEB8DE7EBBE05BF25D28CC5957D58CF | 1319
>  5900 | 86CB46D209591D06AE9C2A666CF485B3DCBA43DF | 
> 
> You will have to wait for (or poke) the ftp-masters to do a "dak
> import-ldap-fingerprints" run.

Is this true? Fingerprints of subkeys are never imported in the LDAP.
In userdir-ldap at least, authentication with subkeys is always first
resolved to the main key with the the help of the keyring and then the
fingerprint of the main key is looked for in the LDAP database.

Maybe you could do something similar.  You need a recent copy of the
keyring (that you can get by public rsync on keyring.debian.org).

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#377282: mail to [EMAIL PROTECTED] not delivered to maintainer by default

[Raphael Hertzog]

On Tue, 17 Jul 2007, martin f krafft wrote:
> also sprach Raphael Hertzog <[EMAIL PROTECTED]> [2007.07.17.0058 +0200]:
> > The script needs to run with write access to the database so you're not
> > going to run it by yourself on the real installation anyway. :)
> 
> I was going to simply use the mail interface, but I guess that
> requires confirmation emails...

I supposed so, that's why I headed you explicitely in the good direction.

You can't easily use the mail interface to:
- verify if the maintainer subscribed
- find out the tags he's subscribed to
- adjust accordingly

It would require several rounds of mail exchanges which isn't desirable.

> > I can give you a copy of the "live database" for more realistic
> > tests if you want.
> 
> Please do. Just put it somewhere on alioth, e.g. ~madduck/pts

In fact it's not needed. The database files are readable on
master.d.o:/org/packages.qa.debian.org/db/*.db

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#377282: mail to [EMAIL PROTECTED] not delivered to maintainer by default

[Raphael Hertzog]

On Mon, 16 Jul 2007, martin f krafft wrote:
> also sprach Raphael Hertzog <[EMAIL PROTECTED]> [2006.07.08.1426 +0200]:
> > I can easily create the "contact" keyword but someone needs to write a
> > script which does the auto-subscription of maintainers to the PTS. And of
> > course afterwards the [EMAIL PROTECTED] alias need to be changed to always 
> > point to
> > [EMAIL PROTECTED]
> 
> Have you ever been able to do this? I'll look into writing that
> script as soon as the keyword exists.

For the record, I created the contact keyword and everybody who had the
"default" keyword already has the new "contact" keyword. The new keyword
is also activated by default (if you don't customize the set of keywords
that you accept).

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#391816: qa: links to buildd logs should point to build.cgi or pkg.cgi

[Raphael Hertzog]

user debian-qa@lists.debian.org
usertag 391816 - pts
thanks

On Sun, 08 Oct 2006, Eugeniy Meshcheryakov wrote:
> Please replace links to buildd logs on 
> http://qa.debian.org/developer.php?login=
> and http://packages.qa.debian.org/ with links to
> http://buildd.debian.org/build.cgi?pkg= or, even better, to
> http://buildd.debian.org/pkg.cgi?pkg=. Those pages have better
> design IMHO and are easier to read than
> http://buildd.debian.org/build.php?pkg= .

The links are updated in the PTS for a very long time already.

It shouldn't be hard to update it on ddpo as well. Christoph?

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#380631: closed by Raphael Hertzog <[EMAIL PROTECTED]> (Re: Bug#380631: Fwd: Undelivered Mail Returned to Sender)

[Raphael Hertzog]

On Tue, 17 Jul 2007, martin f krafft wrote:
> also sprach Debian Bug Tracking System <[EMAIL PROTECTED]> [2007.07.17.1642 
> +0200]:
> > The configuration has been lifted for the bounce handler. The
> > special header is still required for any non d.o machine. But it's
> > going to stay that way, so there's no point in keeping that bug
> > open. Closing it now.
> 
> Isn't this exactly what wontfix is for? Not trying to play bug ping
> pong, so if you disagree, just close it again and I won't spring to
> action anymore.

Yes, wontfix is there for that, but its usage is not mandatory. It's
interesting when people tend to request the same thing over and over.
In our case, I doubt anyone else will request it again.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#377282: mail to [EMAIL PROTECTED] not delivered to maintainer by default

[Raphael Hertzog]

On Tue, 17 Jul 2007, martin f krafft wrote:
>   1. iterates all packages and extracts sourcepkg:maintainer pairs

The "Sources" files are already downloaded regularly as part of the web
interface. You might be able to simply read the data in
www/incoming/Sources_unstable_{main,contrib,non-free}.

>   2. checks whether maintainer is subscribed to [EMAIL PROTECTED]
>  a. if no, subscribe the maintainer, thereby getting contact on
> by default.

Yes.

>  b. if yes, checks whether the contact keyword is present for
> the sourcepkg:maintainer pair
> i) if no, adds the contact keyword to the pair.
> 
> From what I understand, the PTS works in two stages for this: if
> mail is received at [EMAIL PROTECTED], it obtains the list of
> subscribers (bin/dump.pl) and for each subscriber then checks
> whether 'contact' is in the tag set returned by bin/dump-tags.pl
> for [EMAIL PROTECTED] or [EMAIL PROTECTED]

Yes except that if "[EMAIL PROTECTED]" is present, then only
this set of tags is used and the set associated to the email only is not
used. If none of the two tag entries exist, then it uses the hardcoded
default set of tags.

Just use the get_tags($email, $package) function provided by
perl/common.pl and you'll have the current list of keywords. 

> If the tag is present in either set, then I need not do anything.

If the tag is returned by get_tags, then do nothing.

> If the tag is not present in either set, and
> [EMAIL PROTECTED] does not yet exist, copy
> [EMAIL PROTECTED] to [EMAIL PROTECTED] and add the
> tag.

If the tag is not returned by get_tags, then you add the tag in the first
entry that exists:
- [EMAIL PROTECTED]
- [EMAIL PROTECTED]

If none of the entry exist, then you're in serious trouble as the tag is
in the hardcoded default tag list ... and thus you shouldn't be in the "if
tag is not returned". :-)

> Does this sound like a reasonable strategy?

Yes.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#433511: Fwd: Overview of ddd have dead links

[Raphael Hertzog]

reassign 433511 www.debian.org
thanks

On Tue, 17 Jul 2007, Daniel Schepler wrote:
> I got this message from a user and verified it.  The only thing unusual about 
> ddd which might be causing this is that ddd-doc 
> symlinks /usr/share/doc/ddd-doc -> /usr/share/doc/ddd (and depends on an 
> equal version of ddd as required by policy in this case).

This is a problem in "packages.debian.org" and is not handled by the QA
team but by the web team. Reassigning where needed.

It looks like the "current" symlink is invalid for that package.
http://packages.debian.org/changelogs/pool/main/d/ddd/

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#377282: mail to [EMAIL PROTECTED] not delivered to maintainer by default

[Raphael Hertzog]

On Tue, 17 Jul 2007, Raphael Hertzog wrote:
> >   2. checks whether maintainer is subscribed to [EMAIL PROTECTED]
> >  a. if no, subscribe the maintainer, thereby getting contact on
> > by default.
> 
> Yes.

I spoke too fast, in fact not as simple as that. The default set of
keywords includes the BTS mails. You need to disable that if you subscribe
a maintainer by yourself. So you should subscribe him, do a get_tags(),
remove the bts and bts-control tags, and then do a set_tags().

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#377282: mail to [EMAIL PROTECTED] not delivered to maintainer by default

[Raphael Hertzog]

On Tue, 17 Jul 2007, Adeodato Simó wrote:
> * martin f krafft [Tue, 17 Jul 2007 16:17:18 +0200]:
> 
> > Great, so I'll try to "clean up" the database then with a script,
> > which:
> 
> >   1. iterates all packages and extracts sourcepkg:maintainer pairs
> >   2. checks whether maintainer is subscribed to [EMAIL PROTECTED]
> >  a. if no, subscribe the maintainer, thereby getting contact on
> > by default.
> >  b. if yes, checks whether the contact keyword is present for
> > the sourcepkg:maintainer pair
> > i) if no, adds the contact keyword to the pair.
> 
> So this is a script to be run periodically?

Yes.

> What happens when a package changes maintainer, who unsubscribes the
> prior maintainer from the contact address? What if they were previously
> subscribed?

Right, this will need some special-casing. The same script should also
handle unsubscriptions. Automatic subscriptions and unsubscriptions should
probably generate a mail to inform the maintainer. The subscription mail
should indicate him the set of keywords that he's subscribed to and what
additional information he can subscribe to by activating other keywords.
Providing a link like this will let him adjust his keywords easily:
http://packages.qa.debian.org/cgi-bin/pts.cgi?package=dpkg&[EMAIL 
PROTECTED]&what=advanced

The automatic unsubscription should require a confirmation email. In that
way, if he was already subscribed, he can decide to stay subscribed by not
replying to the confirmation mail.

> I haven't read the Wiki page (at least not this year), but I think it's
> more reasonable to do what I had in my TODO list last year: have
> packages.debian.org deliver mail both to the Maintainer: address, and to
> the PTS via _default (or _contact, if so wished by the PTS maintainers).

We still have the problem that people mailing the PTS directly won't reach
the maintainer. And the PTS provides some information that the maintainer
doesn't get if he doesn't explicitely subscribe to it (information about
changes made in derivatives distribution for example).

So in the long term, I think it makes more sense to have the PTS channel
everything and handling properly the package maintainer even if we
have to special case him somewhat.
 
> You save writing a messy script, and there're no issues with subscription
> and unsubscription. Then you can concentrate on the other half of the
> task (which is of course also necessary with the script approach), that
> is: giving packages.debian.org a binary -> source map in an useable
> form.

This part shouldn't be too difficult. The build-maintainerdb script
is apparently used to create the alias file currently.
http://cvs.debian.org/packages/bin/?root=webwml
packages.d.o already has a DB with all the informations
including the source -> binary map.

Frank, would you be ready to change that script so that it generates an
alias file systematically pointing to
[EMAIL PROTECTED] ?

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#377282: mail to [EMAIL PROTECTED] not delivered to maintainer by default

[Raphael Hertzog]

On Tue, 17 Jul 2007, martin f krafft wrote:
> so get_tags() - bts - bts-control + contact --> set_tags().
> 
> (just jotting it down for posterity)
> 
> Now if we do it this way, then the changes to @packages.debian.org
> need to happen at the same time as the pts changes, or else some BTS
> mail will not be delivered.

Huh ? The BTS doesn't rely on [EMAIL PROTECTED] AFAIK. The BTS has its own
pkg->maintainer mapping (provided by the ftpmasters IIRC).

> And then the bts and bts-control tags need to be removed from the
> default set of tags.

Why ? I still expect most users of the PTS to be non-maintainers.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#433095: DDPO: does not show all my sponsored packages

[Raphael Hertzog]

On Tue, 17 Jul 2007, Christoph Berg wrote:
> > >   id  |   fingerprint| uid  
> > > --+--+--
> > >  5823 | F7867D1E8EEB8DE7EBBE05BF25D28CC5957D58CF | 1319
> > >  5900 | 86CB46D209591D06AE9C2A666CF485B3DCBA43DF | 
> > > 
> > > You will have to wait for (or poke) the ftp-masters to do a "dak
> > > import-ldap-fingerprints" run.
> > 
> > Is this true? Fingerprints of subkeys are never imported in the LDAP.
> > In userdir-ldap at least, authentication with subkeys is always first
> > resolved to the main key with the the help of the keyring and then the
> > fingerprint of the main key is looked for in the LDAP database.
> > 
> > Maybe you could do something similar.  You need a recent copy of the
> > keyring (that you can get by public rsync on keyring.debian.org).
> 
> I don't know how that's handled in LDAP, but the above is what the
> projectb knows about that keyid. The uid column will have to be filled
> for ddpo to be able to know that "86CB46D209591D06AE9C2A666CF485B3DCBA43DF"
> is actually "thijs". You can try reopening the bug and reassigning it
> to ftp.debian.org if there is a general problem with subkeys and the
> problen doesn't resolve itself with then next import-ldap-fingerprints
> run (which happens every few weeks).

The last run happened 6 weeks ago:
https://rt.debian.org/Ticket/Display.html?id=102

Thijs, did you create your subkey recently ?

> PS 1: I know that the mail gateway at [EMAIL PROTECTED] does not support
> subkeys, but dak apparently does.

It does support subkeys since 2 months.
https://rt.debian.org/Ticket/Display.html?id=70

> PS 2: Note that the projectb doesn't correlate a (source) packages's
> maintainer and the uid/key used to sign it in any way, that's two
> different text fields.

The fact that the upload is accepted even if the key is not associated to
a uid proves either that projectb doesn't properly identify subkeys or
that you can't rely on projectb to do this for you.

I don't know what interpretation is the right one. :-)

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#430143: closed by Raphael Hertzog <[EMAIL PROTECTED]> (Re: Bug#430143: pts.cgi: use tooltips to explain what the different checkboxes mean.)

[Raphael Hertzog]

Hi,

On Wed, 18 Jul 2007, Ivan Baldo wrote:
>Wow thanks!!! Its wonderful now! :-)
>Just a tought: summary could tell that ATM is used for notifications of 
> progression from unstable to testing, I find that particular option 
> interesting exactly because of that.
>Thanks again!!!

Done, you're welcome.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Re: Bug#377282: mail to [EMAIL PROTECTED] not delivered to maintainer by default

[Raphael Hertzog]

On Wed, 18 Jul 2007, martin f krafft wrote:
> also sprach Raphael Hertzog <[EMAIL PROTECTED]> [2007.07.17.2113 +0200]:
> > > So this is a script to be run periodically?
> > 
> > Yes.
> 
> I am beginning to like the idea less, though I understand the cause.
> 
> Since the PTS knows about maintainers and co-maintainers already,
> anyway, and updates this information, wouldn't it make more sense to
> simply have it send mail to @pts to the subscribers and all
> (co-)maintainers, making sure each address is only ever used once?
> I see no excuse why a (co-)maintainer would not want to get PTS mail
> and expecting co-maintainers to sign up on the PTS was always
> a hassle anyway.

There are dozens of reasons for not wanting to do that. The first one is
that in many cases mailing lists are subscribed to the PTS. If the
Uploader are following the ML, it's enough. 

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Bug#433894: qa.debian.org: "Updating foo introduces new bugs:" links only to the first link

[Raphael Hertzog]

Hi,

On Fri, 20 Jul 2007, Paul Wise wrote:
> Package: qa.debian.org
> Severity: minor
> Tags: patch
> 
> When a package introduces new bugs to testing, the "Updating foo
> introduces new bugs:" links only link to one bug of the whole lot.
> 
> An example is here:
> 
> http://packages.qa.debian.org/p/php4-ps.html
> 
> I've attached a quick and dirty and _untested_ patch that may work. 

I'm almost sure it won't work:

  

  

The XSL only consider the content of  and you try to provide
raw text and items mixed.

> I'm > not sure it is the right approach, making all lines with links in them
> do something similar might be a better way to go so that all links in
> the update_excuses.html file are preserved on the PTS page. If that is
> wanted I can rework it.

That looks sensible. It will probably require rework of the template 
"outputitem"
however.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#435794: packages.qa.debian.org: please add reverse depends

[Raphael Hertzog]

On Fri, 03 Aug 2007, Thijs Kinkhorst wrote:
> On Friday 3 August 2007 10:30, Adriaan Peeters wrote:
> > It would be nice to be able to check reverse depends without an up to
> > date distribution installation. So please add reverse depends to the
> > packages.qa.d.o and/or packages.d.o sites.
> 
> I've been thinking about this before and I definately think it would be 
> useful 
> if one could easily access a package's reverse dependencies from the PTS.

Adding reverse build-dependencies should be easy as everything is
generated based on the "Sources" files. 

However, reverse dependencies on binaries is going to be a lot more
complicated... as it depends on the architecture, and you'll have to
download and parse the "Packages" files (which is currently not done).

And selecting a single arch and hoping that the rest is in sync will at
least create problems on some arch-specific packages.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Re: proposal: upload to the collab-maint repo orphaned packages

[Raphael Hertzog]

On Fri, 17 Aug 2007, Stefano Zacchiroli wrote:
> But ... it happened to me in the past that I was willing to fix a couple
> of bugs in an orphaned package but not to take over its maintenance. I
> guess it's a pretty common scenario. In those cases having it already in
> collab-maint would have eased my work. What's harmful in that?

The typical QA scenario is "apt-get source", hack, debuild, dput.
Precisely because the usual QA worker doesn't care enough about the
package, it's a one-shot work. So the reference is the archive itself and
the SVN in the middle is of very few help.

I already proposed what your describe 2 years ago at the QA meeting (with
adn and sukria):
Slide:
http://meetings-archive.debian.net/pub/debian-meetings/2005/qa-meeting-darmstadt/slides/2005-09-11_Collaborative-maintenance-by-external-contributors_Alexis-Sukrieh+Raphael-Hertzog+Mohammed-Adnene-Trojette/collab-maint.pdf
Video:
http://meetings-archive.debian.net/pub/debian-meetings/2005/qa-meeting-darmstadt/good-quality/ogg_theora/2005-09-11_Collaborative-maintenance-by-external-contributors_Alexis-Sukrieh+Raphael-Hertzog+Mohammed-Adnene-Trojette.ogg

You can see by yourself the discussions. :)

> - if we don't, we can request the package removal, in such a case would
>   it be a big deal to have package sources left over in collab-maint? I
>   don't think so

I'd rather not pollute the collab-maint repo too much with old crap. If we
really want this, we can have a dedicated qa-packages repository.

> Well, no. I'm just proposing a technical solution to ease working on
> orphaned packages, I'm not affecting (or at least it's not my intention,
> nor the foreseeable future I imagine) in any way how long a package
> would remain in the orphaned status, not what are the consequences of
> being in that status.

Using a SCM is not easing our QA work because precisely there's very few
coordination to do... I don't remember any conflict of work on orphaned
packages.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: proposal: upload to the collab-maint repo orphaned packages

[Raphael Hertzog]

On Fri, 17 Aug 2007, Stefano Zacchiroli wrote:
> For the moment I've only had the time to read the slide, I'll postpone
> the .ogg. But indeed my proposal is exactly the same as yours ... and
> actually your slides contradict what you're claiming above. I guess
> that's because the discussion after the talk made you change your mind,
> right?

Yes.

> Anyhow, before following the past live discussion I'm still convinced
> it's a good idea for precisely the reasons you mentioned (playground for
> contributors, ability to commit for non-DDs, VCS support [e.g.
> history]) and also for others like the ability to easily work in a batch
> manner on a set of orphaned packages.

But where are the non-DD contributors that work on orphaned packages?
There are very few of them and in the case when we have someone, I'd
rather make them DM of those packages over time instead of using such an
infrastructure.

> > I'd rather not pollute the collab-maint repo too much with old crap. If we
> > really want this, we can have a dedicated qa-packages repository.
> 
> Regarding this. It seems to me that the 2 subdirs in collab-maint
> orphaned/ and ext-maint/ actually contain packages, so I deduce that the
> idea is being used in practice. Or is it just old stuff no longer used
> nor encouraged? Can I check in there orphaned packages I want to work on
> or is this discouraged?

ext-maint is used by non-DD packagers right. But those packages are not
orphaned. For those in the oprhaned directory I have no idea what they
are. I haven't checked.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

freshmeat.php: a sf.php-like script for watch files

[Raphael Geissert]

d on the project name and the 
project version, it is possible to use it for such cases.


I think this is it. Any kind of feedback is very welcomed :-)

[1] see the attached freshmeat.php file
[2] http://deb.atomo64.puffinhost.com/freshmeat.php/
[3] see the attached uscan.patch file


Kind regards,
Raphael Geissert
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


freshmeat.php
Description: application/php
Index: uscan.pl
===
--- uscan.pl	(revision 841)
+++ uscan.pl	(working copy)
@@ -745,6 +745,8 @@
 
 	# Handle sf.net addresses specially
 	$base =~ s%^http://sf\.net/%http://qa.debian.org/watch/sf.php/%;
+	# Handle debian.freshmeat.net addresses specially
+	$base =~ s%^http://debian\.freshmeat\.net/%http://qa.debian.org/watch/freshmeat.php/%;
 	if ($base =~ m%^(\w+://[^/]+)%) {
 	$site = $1;
 	} else {


signature.asc
Description: This is a digitally signed message part.

Re: Mole web interface?

[Raphael Hertzog]

Hi Cyril,

On Thu, 22 Nov 2007, Cyril Brulebois wrote:
> I'm currently having a look at mole so as to prepare a bit some ideas before
> the meeting, and it looks like there should be a web interface hosted on 
> merkel
> ([1,2]). Is there any reason why it has been disabled?

It's not disabled: http://qa.debian.org/cgi-bin/mole

I have been advertising the URL for downloading "symbols" files lately:
http://qa.debian.org/cgi-bin/mole/seedsymbols

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: URL convention to point to per-package lintian checks

[Raphael Geissert]

Hello Stefano,

Stefano Zacchiroli wrote:
> 
> This does not correspond to what lintian.debian.org is doing, partly for
> the PTS bug, partly for (I guess, though I'm not sure) a lintian bug
> which does not replace with "__" for the last character of maintainer
> name.  For example, at [2], if you look for "Adeodato Simó" you will
> notice that the resulting link is
> http://lintian.debian.org/reports/mAdeodato_Sim.html (and indeed PTS
> pages for packages maintained by dato have 404 lintian links!).
> 
> So, question, what is the actual algorithm used by lintian.d.o to patch
> maintainer names?

The script used to generate the html pages is available at:
http://svn.wolffelaar.nl/lintian/trunk/reporting/html_reports

There you will find this code:
$file =~ s/^(.+)\<.*$/$1/;
$file =~ tr/A-Za-z0-9_.,/_/c;
$file =~ s/^_+//g;
$file =~ s/_+$//g;

> 
> Beside that, should I really need to implement that in the PTS as well?
> The alternative is that lintian.d.o is willing to implement a simpler
> naming scheme, for example using maintainer email and creating URLs like
> http://lintian.debian.org/reports/mEMAIL. In email you can patch "@"
> with the usual URL escape and be done with that. What about it? I think
> the resulting URL would even be easier to guess out of the blue.

I've already tried once to fix this problem and even submitted a patch, but
I recommend you to read the whole bug report[1].
It would be great if you could finish my work on that.

> 
> Many thanks in advance, Cheers.
> 

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373218

Sincerely,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: URL convention to point to per-package lintian checks

[Raphael Geissert]

Stefano Zacchiroli wrote:
> On Sun, Dec 02, 2007 at 01:27:41PM -0600, Raphael Geissert wrote:
> 
> I surely can, but before doing so I would prefer to fix the URL naming
> scheme in the right place, see my reply to Russ.

What my patches actually do is switch to an email address-based naming (in
everywhere: lintian reports generator, developer.php and PTS).
As for what I understood that's what you want to do, am I mistaken?

> 
> Cheers.
> 

Sincerely,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: freshmeat.php: a sf.php-like script for watch files

[Raphael Geissert]

Hi all,

Raphael Geissert wrote:
> 
> I think this is it. Any kind of feedback is very welcomed :-)
> 

So, any feedback? :)

Sincerely,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: Membership of qa group and access to qa user

[Raphael Hertzog]

On Thu, 06 Dec 2007, Luk Claes wrote:
> Stefano Zacchiroli wrote:
> > On Thu, Dec 06, 2007 at 08:39:24PM +0100, Luk Claes wrote:
> >> Currently it seems that tbm,weasel,igenibel,aba,jeroen,myon,herzog have
> >> sudo access to the qa user.
> > 
> > I have access to the sudo qa user as well; where did you get this list?
> 
> Note that I didn't state it as a fact... I may very well have missed
> users with/without access as I got this list on IRC :-)

Furthermore this list is for merkel, there's also a separate set of users
with access to the qa user and master (for the PTS). I think only me and
Jeroen have access there.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: Making Debian QA sexier / moving away from http://qa.debian.org/

[Raphael Geissert]

Hi,

Lucas Nussbaum wrote:
...
> 
> The result can be seen on http://qa.debian.org/~lucas/wml/ . Of course,
> it's work in progress, and comments are totally welcomed.

>From the page:
> If you are interested, don't hesitate to join us
"join us" is a link to
http://wiki.debian.org/qa.debian.org/join
the real page is
http://wiki.debian.org/qa.debian.org/Join

(Note the capitalised j)


> 
> Does someone have good web designing skills? We should also rework the
> template a bit...

The first thing I would do is switch to a non tables-based layout and then
use www.d.o's stylesheet. That will probably fix the one or two glitches.
I'll see what I can do for it this weekend.

Sincerely,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Bug#437675: Seems, the watch handler is not able to handle mangles in wath files

[Raphael Geissert]

tag 437675 pending
severity 437675 wishlist
retitle 437675 Compare versions using the mangled Debian version string
thanks

The code on developer.php/.wml has been updated so this feature can be 
integrated.
What is left is update the DEHS backend including the database structure, 
afterwards an update of the status of the package will do the rest.

Sincerely,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html



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

Bug#457190: qa.debian.org: selecting default CSS layout for PTS

[Raphael Hertzog]

On Thu, 20 Dec 2007, Thomas Viehmann wrote:
> How about cookie + let mod_rewrite rewrite a default.css URI based on the
> ocokie? That would eliminate the need for JavaScript. (Needs apache2, though,
> AFAICT.)

That's a nice idea, but how do you use a cookie in a mod_rewrite
configuration?

It might have to wait until master is upgraded to etch and apache2, but
that's not a big deal. We still need to have a way to set the cookie but
that could be done with a simple "preferences" page.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Re: Coordinate time for the lintian URL updates

[Raphael Hertzog]

On Thu, 20 Dec 2007, Russ Allbery wrote:
> lintian has migrated to testing, so I'm now ready to update lintian.d.o.
> An update will mean a full-archive run, which takes a little more than a
> day, after which the old maintainer URLs will be no more and the new
> format with the e-mail address must be used.
> 
> I want to minimize the breakage in links from the PTS and developer pages,
> so I want to coordinate with you a good time to do this.  Could you let me
> know when would be a good time to do the switch, assuming that the archive
> run needs to start about a day and a half in advance of when the new URLs
> will be live?

For me you can go ahead right now if you want, I should be able to find
some time tomorrow (or on sunday) for the PTS if zack is not faster.

In any case, broken links are not the end of the world and it's doesn't
require an up-to-the minute synchronization ;-)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: Coordinate time for the lintian URL updates

[Raphael Hertzog]

On Fri, 21 Dec 2007, Russ Allbery wrote:
> Okay, lintian is finishing its daily run for today right now, and as soon
> as that finishes, I'll kick off the full archive run.  It should be done
> sometime on Saturday afternoon (US Pacific time), judging from past
> experience.

Ok. I updated the link and reran an update of the PTS.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: Please take down junk QA pages

[Raphael Hertzog]

Hi,

On Mon, 31 Dec 2007, Thomas Viehmann wrote:
> please take down the abandoned QA pages at
> 
> http://wagner-xen1.debian.org/~thuriaux-guest/qa/
> 
> apparently they are regenerated daily from old data, creating the false
> impression of containing recent information.
> 
> The last message containing a prod[1] to the maintainer's address (taken from
> qa.d.o/developer.php) was unanswered, so I would like ask you as the alioth
> admins to disable the cron job (?) and move the public_html to deactivate the
> pages as a QA measure of this QA attempt.

According to Christian Perrier, Thomas is not completely MIA although less
active than he used to be.

Thomas, would you like to reply and either fix your pages and/or
disable them?

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

List of packages which should probably be Architecture: all

[Raphael Geissert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello all,

I've written a script which tries to detect packages which should be
architecture all based on the fact that they don't contain a Depends field.
This is usually bug either because of a missing Depends or because the
package should be Architecture: all.

I'm not going to attempt to do a MBF for these because the results may
contain many false positives so I encourage people to take a look at this
list, review and fix or fill bug reports accordingly.
The attachment is the list of packages including uploaders (output of
dd-list -u).

As usually any kind of feedback is very welcomed.

Cheers,
Raphael Geissert

Anibal Avelar (Fixxxer) <[EMAIL PROTECTED]>
   centerim

Loic Dachary (OuoU) <[EMAIL PROTECTED]>
   unittest++ (U)

Peter De Schrijver (p2) <[EMAIL PROTECTED]>
   openwince-include

Johan Euphrosine (proppy) <[EMAIL PROTECTED]>
   unittest++

Clint Adams <[EMAIL PROTECTED]>
   db (U)
   zsh

Martin Albisetti <[EMAIL PROTECTED]>
   2vcard

Russ Allbery <[EMAIL PROTECTED]>
   gss (U)
   shishi (U)

Stuart R. Anderson <[EMAIL PROTECTED]>
   lsb-build-base2
   lsb-build-base3

Domenico Andreoli <[EMAIL PROTECTED]>
   curl

Kumar Appaiah <[EMAIL PROTECTED]>
   vala (U)

maximilian attems <[EMAIL PROTECTED]>
   klibc
   linux-2.6 (U)

Jeff Bailey <[EMAIL PROTECTED]>
   klibc (U)

Michael Banck <[EMAIL PROTECTED]>
   libopensync-plugin-palm

Andreas Barth <[EMAIL PROTECTED]>
   iproute (U)

Douglas Bates <[EMAIL PROTECTED]>
   r-base (U)

Bradley Bell <[EMAIL PROTECTED]>
   bakery2.3

Christoph Berg <[EMAIL PROTECTED]>
   dds

CJ van den Berg <[EMAIL PROTECTED]>
   pulseaudio

Michael Biebl <[EMAIL PROTECTED]>
   tracker

Bastian Blank <[EMAIL PROTECTED]>
   busybox (U)
   linux-2.6 (U)

Eduard Bloch <[EMAIL PROTECTED]>
   icewm

W. Borgert <[EMAIL PROTECTED]>
   omnievents

Fathi Boudra <[EMAIL PROTECTED]>
   icecc (U)

Joachim Breitner <[EMAIL PROTECTED]>
   xaralx

Ludovic Brenta <[EMAIL PROTECTED]>
   gnat-4.1 (U)
   gnat-4.2 (U)

Marc 'HE' Brockschmidt <[EMAIL PROTECTED]>
   libgnomecanvas (U)

Rob Browning <[EMAIL PROTECTED]>
   guile-1.6

Cyril Brulebois <[EMAIL PROTECTED]>
   etl (U)

Ross Burton <[EMAIL PROTECTED]>
   xnee

Petr Cech <[EMAIL PROTECTED]>
   lde

Hubert Chathi <[EMAIL PROTECTED]>
   gnustep-make (U)

Kanru Chen <[EMAIL PROTECTED]>
   libchewing

Patryk Cisek <[EMAIL PROTECTED]>
   kadu

Robert Collins <[EMAIL PROTECTED]>
   libopensync-plugin-palm (U)

Arnaud Cornet <[EMAIL PROTECTED]>
   ratbox-services

Nigel Croxon <[EMAIL PROTECTED]>
   gnu-efi

Marco d'Itri <[EMAIL PROTECTED]>
   inn2

Joost Yervante Damad <[EMAIL PROTECTED]>
   flake (U)

Terry Dawson <[EMAIL PROTECTED]>
   hamlib (U)

Debian Berkeley DB Maintainers <[EMAIL PROTECTED]>
   db

Debian EMBOSS Packaging Team <[EMAIL PROTECTED]>
   emboss

Debian GCC Maintainers <[EMAIL PROTECTED]>
   gcc-3.3
   gcc-3.4
   gcc-4.1
   gcc-4.2
   gcc-defaults
   gcj-4.1
   gcj-4.2
   gnat-4.1
   gnat-4.2

Debian GNOME Maintainers <[EMAIL PROTECTED]>
   libgnomecanvas (U)
   system-tools-backends (U)

Debian GNUstep maintainers <[EMAIL PROTECTED]>
   gnustep-make

Debian Install System Team <[EMAIL PROTECTED]>
   busybox
   debian-installer
   discover1
   os-prober

Debian Java Maintainers <[EMAIL PROTECTED]>
   antlr

Debian JED Group <[EMAIL PROTECTED]>
   tess

Debian KDE Extras Team <[EMAIL PROTECTED]>
   icecc

Debian Kernel Team <[EMAIL PROTECTED]>
   linux-2.6

Debian multimedia packages maintainers
<[EMAIL PROTECTED]>
   libdts
   libdvb
   liblivemedia

Debian Multimedia Team <[EMAIL PROTECTED]>
   flake

Debian OpenOffice Team <[EMAIL PROTECTED]>
   openoffice.org

Debian Qt/KDE Maintainers <[EMAIL PROTECTED]>
   qt-x11-free

Debian Ruby Extras Maintainers
<[EMAIL PROTECTED]>
   libdaemons-ruby (U)

Debian Scientific Computing Team <[EMAIL PROTECTED]>
   netgen

Debian Synfig Maintainers <[EMAIL PROTECTED]>
   etl

Debian TeX Maintainers <[EMAIL PROTECTED]>
   texlive-bin

Debian VDR Team <[EMAIL PROTECTED]>
   libmdsp

Debian VoIP Team <[EMAIL PROTECTED]>
   srtp

Debian Xfce Maintainers <[EMAIL PROTECTED]>
   xfce4-dev-tools

XCB Developers <[EMAIL PROTECTED]>
   libpthread-stubs

Scott M. Dier <[EMAIL PROTECTED]>
   bitcollider

Yann Dirson <[EMAIL PROTECTED]>
   memtest86
   memtest86+

Sebastian Dröge <[EMAIL PROTECTED]>
   avahi (U)
   libgnomecanvas (U)
   vala (U)

Paul Dwerryhouse <[EMAIL PROTECTED]>
   kannel

Dirk Eddelbuettel <[EMAIL PROTECTED]>
   r-base
   tclap

Free Ekanayaka <[EMAIL PROTECTED]>
   flake (U)

Rene Engelhard <[E

Re: List of packages which should probably be Architecture: all

[Raphael Geissert]

Hello Kurt,

Kurt Roeckx wrote:
> On Wed, Jan 02, 2008 at 01:17:24PM -0600, Raphael Geissert wrote:
>> Hello all,
>> 
>> I've written a script which tries to detect packages which should be
>> architecture all based on the fact that they don't contain a Depends
>> field.
> 
> Your list seems to contain alot of packages that do have a Depends
> field.

Like which one? I used a lot of grepping so maybe something was left in.

> 
> 
> Kurt

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: List of packages which should probably be Architecture: all

[Raphael Geissert]

Hello Cyril,

Cyril Brulebois wrote:
> Hm, what about checking their *content*? What about listing *binary*
> packages?

Forgot to mention that, based on the binary-amd64 Packages file of the main,
contrib and non-free sections.
I didn't check the content of the packages because that's something
linda/lintian should do, this is just a simple/quick list of packages and
as I said it may contain some false positives (although there's usually a
reason/bug causing the package to be listed).

> 
> Cheers,
> 

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: List of packages which should probably be Architecture: all

[Raphael Geissert]

D]>
   libajax5-dev (U)
   libnucleus5-dev (U)

Masahito Omote <[EMAIL PROTECTED]>
   libuim-data

Patrick Ouellette <[EMAIL PROTECTED]>
   opt

Sam Hocevar (Debian packages) <[EMAIL PROTECTED]>
   libdts-dev (U)
   libdvb-dev (U)
   liblivemedia-dev (U)

Goedson Teixeira Paixao <[EMAIL PROTECTED]>
   libgfccore-doc

Gerrit Pape <[EMAIL PROTECTED]>
   cvm-dev
   dietlibc-dev
   fgetty
   fnord
   integrit
   runit
   skalibs-dev

Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]>
   clips-common

Yves-Alexis Perez <[EMAIL PROTECTED]>
   xfce4-dev-tools (U)

Thomas Perl <[EMAIL PROTECTED]>
   libflake-dev (U)

Charles Plessy <[EMAIL PROTECTED]>
   libajax5-dev (U)
   libnucleus5-dev (U)

Gregory Pomerantz <[EMAIL PROTECTED]>
   libxkbsel-dev

Frans Pop <[EMAIL PROTECTED]>
   debian-installer (U)
   os-prober (U)

Norbert Preining <[EMAIL PROTECTED]>
   texlive-base-bin-doc (U)
   texlive-metapost-doc (U)

Christophe Prud'homme <[EMAIL PROTECTED]>
   libnetgen-dev (U)

Mark Purcell <[EMAIL PROTECTED]>
   libicecc-dev (U)

Petter Reinholdtsen <[EMAIL PROTECTED]>
   libdiscover1-pic (U)

Steve M. Robbins <[EMAIL PROTECTED]>
   libgeomview-dev

Emanuele Rocca <[EMAIL PROTECTED]>
   xfce4-dev-tools (U)

Herve Rousseau <[EMAIL PROTECTED]>
   minit

Anibal Monsalve Salazar <[EMAIL PROTECTED]>
   libgii1-target-x
   liblpsolve55-dev (U)

Otavio Salvador <[EMAIL PROTECTED]>
   grub (U)
   libdiscover1-pic (U)
   system-tools-backends-dev (U)

Niv Sardi <[EMAIL PROTECTED]>
   system-tools-backends-dev (U)

Thomas Schmidt <[EMAIL PROTECTED]>
   libmdsp-dev (U)

Andreas Schuldei <[EMAIL PROTECTED]>
   libcurl3-dbg (U)

Martin Schulze <[EMAIL PROTECTED]>
   cgilib

Frederik Schüler <[EMAIL PROTECTED]>
   linux-headers-2.6.23-1-common (U)
   linux-libc-dev (U)

Jamey Sharp <[EMAIL PROTECTED]>
   libpthread-stubs0 (U)

Sjoerd Simons <[EMAIL PROTECTED]>
   libavahi-common-data (U)
   libpulse-browse0-dbg (U)

Jonas Smedegaard <[EMAIL PROTECTED]>
   libsrtp1-dev (U)

Jose Carlos Garcia Sogo <[EMAIL PROTECTED]>
   system-tools-backends-dev

Joop Stakenborg <[EMAIL PROTECTED]>
   libhamlib-doc
   libhamlib-doc (U)

Gaudenz Steinlin <[EMAIL PROTECTED]>
   libdiscover1-pic (U)

Al Stone <[EMAIL PROTECTED]>
   libacovea-dev
   libatomic-ops-dev (U)
   llvm-libs

Michael Stone <[EMAIL PROTECTED]>
   libopie-dev

Ondřej Surý <[EMAIL PROTECTED]>
   libgnomecanvas2-0
   libldns-dev

NOKUBI Takatsugu <[EMAIL PROTECTED]>
   chasen-cannadic

Reinhard Tartler <[EMAIL PROTECTED]>
   xine-dbg

Debian GSS Team <[EMAIL PROTECTED]>
   libgss-dbg

Debian Shishi Team <[EMAIL PROTECTED]>
   shishi-dbg

Jason Thomas <[EMAIL PROTECTED]>
   grub (U)

Paul van Tilburg <[EMAIL PROTECTED]>
   libdaemons-ruby1.8 (U)

Marcela Tiznado <[EMAIL PROTECTED]>
   when

Juan Esteban Monsalve Tobon <[EMAIL PROTECTED]>
   libgii1-target-x (U)
   liblpsolve55-dev

Gerhard Tonn <[EMAIL PROTECTED]>
   gcc-3.3-base (U)
   gcc-3.4-base (U)

Josh Triplett <[EMAIL PROTECTED]>
   libpthread-stubs0 (U)

Theodore Y. Ts'o <[EMAIL PROTECTED]>
   e2fsck-static

Utopia Maintenance Team <[EMAIL PROTECTED]>
   libavahi-common-data

Arnaud Vandyck <[EMAIL PROTECTED]>
   libantlr-dev (U)

Andrea Veri <[EMAIL PROTECTED]>
   libagg-dev

Sune Vuorela <[EMAIL PROTECTED]>
   libqt3-headers (U)
   mga-vid-source

Colin Watson <[EMAIL PROTECTED]>
   os-prober (U)

Torsten Werner <[EMAIL PROTECTED]>
   libmrss0-dbg (U)
   libnxml0-dbg (U)
   paintlib2c2a-dbg (U)

Ian Wienand <[EMAIL PROTECTED]>
   libatomic-ops-dev

Patrick Winnertz <[EMAIL PROTECTED]>
   libitalc

Alexander Wirt <[EMAIL PROTECTED]>
   iproute-dev
   iproute-doc

Paul Wise <[EMAIL PROTECTED]>
   etl-dev (U)

Enrico Zini <[EMAIL PROTECTED]>
   dballe-common
   libcnf-dev
   libdballe-bufrex-doc
   libdballe-core-doc
   libdballe-db-doc
   libdballe-msg-doc

Michal Čihař <[EMAIL PROTECTED]>
   libgammu3

- -- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHe+zmYy49rUbZzloRArajAJ9z9NfM3o8DVHfaI5CkIVJjj+WDVgCgh3GL
0PKRtgX7FWMU8wMYNOlcrEA=
=vRug
-END PGP SIGNATURE-
Anibal Avelar (Fixxxer) <[EMAIL PROTECTED]>
   centerim-common

Loic Dachary (OuoU) <[EMAIL PROTECTED]>
   libunittest++0 (U)

Peter De Schrijver (p2) <[EMAIL PROTECTED]>
   openwince-include

Johan Euphrosine (proppy) <[EMAIL PROTECTED]>
   libunittest++0

Clint Adams <[EMAIL PROTECTED]>
   libdb4.6-dbg (U)
   zsh-dev

Martin Albisetti <[EMAIL PROTECTED]>
   2vcard

Russ Allbery <[EMAIL PROTECTED]>
   li

Re: List of packages which should probably be Architecture: all

[Raphael Geissert]

Hello Joey,

Joey Hess wrote:
> Interesting idea, though so few packages lack dependencies that it won't
> catch much. Perhaps grepping for package that don't depend on any shared
> libraries would catch more?
> 

Nice idea, though I'll first wait for everybody to read my last message
(Message-ID: <[EMAIL PROTECTED]>) which contains the 'good' list
(I wonder why dd-list goes the source packages way when the ones provided
in the input are nothing but binary packages).

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: List of packages which should probably be Architecture: all

[Raphael Geissert]

Pierre Habouzit wrote:

> On Wed, Jan 02, 2008 at 07:58:24PM +0000, Raphael Geissert wrote:
>> Russ Allbery <[EMAIL PROTECTED]>
>>libgss-dbg (U)
>>shishi-dbg (U)
> 
> rrght...
> 

-dbg package without a Depends? that sounds like a bug (please read my first
message).

Depends: sishi
Depends: libgss0
?

-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: List of packages which should probably be Architecture: all

[Raphael Geissert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


I'll consider your message as sent (won't verify timestamps) before I
clarified the situation both by mail and on IRC.

Cyril Brulebois wrote:
> 
> Maybe there's rather a bug in your process. Instead of speaking of
> “plenty of greps”, you might want to expose the code / algorithm you
> used.
> 

Parts of it are pretty ugly (and the Packages-fetching part isn't there),
but I'm attaching it anyway.

Cheers,
- -- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHe/FJYy49rUbZzloRAnsOAJ9vsqqQ3tVJW6mant4W4vNOn0R/IACePp+z
gd3VgRJ0FeUZEqDPbZl2ohI=
=va4z
-END PGP SIGNATURE-


should-be-arch-all.sh
Description: application/shellscript

Re: List of packages which should probably be Architecture: all

[Raphael Geissert]

Cyril Brulebois wrote:

> On 02/01/2008, Pierre Habouzit wrote:
>>   Though after a second thought, -dbg should probably not have empty
>> Depends line.
> 
> After a third thought, I still fail to see what that has to do with
> being Architecture: all or any.
> 

Quoting my self (first message):
> This is usually bug either because of a missing Depends or because the
> package should be Architecture: all.

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: List of packages which should probably be Architecture: all

[Raphael Geissert]

Aurelien Jarno wrote:
> 
> I fail to see why. Imagine for example a -dev package providing only .h
> files, but depending on the architecture. It has to be Architecture: any
>  and does not need to Depends on a package.

I know I'm hidding behind my 'the results may contain many false positives'
statement but I'm really aware there are some exceptions (like the one you
mentioned or others like kdepim-dbg, as stated by Sune Vuorela, which
contain the symbols of several binaries which are distributed in several
binary packages).

> 
> You really have to look at the contents of the package and verify it
> does not change between architecture.
> 

I'll try to do it when I have time and after the archive wide lintian check
(on amd64 binary packages only) I talked about in #-qa

Cheers,
Raphael Geissert



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

Re: List of packages which should probably be Architecture: all

[Raphael Geissert]

James Vega wrote:
> grep-dctrl ! -FDepends -e '.' -a ! -FPre-Depends -e '.' \
> -a ! -FArchitecture all -n -sPackage binary-i386_Packages

This approach is better and far faster than mine, diff'ing the results of
both methods show four less binaries (which all of them are false positives
using my method).

I just added a weekly cronjob in my alioth account to regenerate the lists
(based on the sid/{main,contrib,non-free}/binary-i386/Packages) which are
available at:

http://alioth.debian.org/~atomo64-guest/should-be-arch-all.txt
Containing only the package names

http://alioth.debian.org/~atomo64-guest/should-be-arch-all.by-maint.txt
Same as above but ordered by maintainer (no Uploaders available because
Packages doesn't provide it).

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: List of packages which should probably be Architecture: all

[Raphael Geissert]

Marc 'HE' Brockschmidt wrote:
> Raphael Geissert <[EMAIL PROTECTED]> writes:
>> Brendan O'Dea <[EMAIL PROTECTED]>
>>perl-base
> 
> That's a false positive. Please also take a look at Pre-Depends. Or
> simply let off of this effort, the number of false positives is
> enormous.

The automated listings already use grep-ctrl also checking for Pre-Depends,
both actions reducing the number of false positives.

I'm posting again the links:
http://alioth.debian.org/~atomo64-guest/should-be-arch-all.txt
http://alioth.debian.org/~atomo64-guest/should-be-arch-all.by-maint.txt

As I already said on one of my messages I'll do further analysis, but
meanwhile there's a preview of the packages that will probably be listed
even after a deeper/better check.

> 
> Marc

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: List of packages which should probably be Architecture: all

[Raphael Geissert]

-dev: Files amd64/md5sums and i386/md5sums differ
libgfccore-doc: Files amd64/md5sums and i386/md5sums differ
libgii1-target-x: Files amd64/md5sums and i386/md5sums differ
libgss-dbg: Files amd64/md5sums and i386/md5sums differ
Processing libhamlib-doc...
libicecc-dev: Files amd64/md5sums and i386/md5sums differ
libinotifytools0-dev: Files amd64/md5sums and i386/md5sums differ
libipod-doc: Files amd64/md5sums and i386/md5sums differ
libitalc: Files amd64/md5sums and i386/md5sums differ
libklibc: Files amd64/md5sums and i386/md5sums differ
libkwnn-dev: Files amd64/md5sums and i386/md5sums differ
libldns-dev: Files amd64/md5sums and i386/md5sums differ
liblivemedia-dev: Files amd64/md5sums and i386/md5sums differ
liblpsolve55-dev: Files amd64/md5sums and i386/md5sums differ
libmdsp-dev: Files amd64/md5sums and i386/md5sums differ
libmrss0-dbg: Files amd64/md5sums and i386/md5sums differ
libmythes-dev: Files amd64/md5sums and i386/md5sums differ
libnetgen-dev: Files amd64/md5sums and i386/md5sums differ
libnucleus5-dev: Files amd64/md5sums and i386/md5sums differ
libnxml0-dbg: Files amd64/md5sums and i386/md5sums differ
libomnievents-dev: Files amd64/md5sums and i386/md5sums differ
libopie-dev: Files amd64/md5sums and i386/md5sums differ
libotpw-dev: Files amd64/md5sums and i386/md5sums differ
libpthread-stubs0: Files amd64/md5sums and i386/md5sums differ
libpulse-browse0-dbg: Files amd64/md5sums and i386/md5sums differ
libqcad0-dev: Files amd64/md5sums and i386/md5sums differ
libqt3-headers: Files amd64/md5sums and i386/md5sums differ
libqthreads-12: Files amd64/md5sums and i386/md5sums differ
libsrtp1-dev: Files amd64/md5sums and i386/md5sums differ
libsyck0-dev: Files amd64/md5sums and i386/md5sums differ
libtclap-dev: Files amd64/md5sums and i386/md5sums differ
libuim-data _MUST_ be Architecture: all! identical files: amd64/md5sums
i386/md5sums
Processing libunittest++0...

(those which only have a "Processing ..." line means that wget failed to
fetch EXACTLY the same package version of amd64 or i386).

And here's the list of packages which after comparing the md5sum files show
no reason why they aren't arch all:

Grub Maintainers <[EMAIL PROTECTED]>
   grub

Camm Maguire <[EMAIL PROTECTED]>
   hol88-library

Robert Millan <[EMAIL PROTECTED]>
   grub (U)

Masahito Omote <[EMAIL PROTECTED]>
   libuim-data

Otavio Salvador <[EMAIL PROTECTED]>
   grub (U)

Jason Thomas <[EMAIL PROTECTED]>
   grub (U)


As usually, feedback is welcome.

Kind regards,
Raphael Geissert


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHhsPsYy49rUbZzloRAsolAJwLJf7mboJHkPdi3189Se1hqeDqDQCgmA6K
3QMYoeXt3/oPumUktBa6wkY=
=bJ5l
-END PGP SIGNATURE-


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

Re: List of packages which should probably be Architecture: all

[Raphael Geissert]

Cyril Brulebois wrote:
> On 11/01/2008, Raphael Geissert wrote:
>> Note that this is the raw output of the script, packages which MUST be
>> arch all (debian-installer is excluded, because of technical reasons)
>> are listed below the list.
> 
> *MUST*, ahah.

Sorry, that is more like a "s/MUST/REALLY SHOULD" (strong should? :) 

> 
>> And here's the list of packages which after comparing the md5sum files
>> show no reason why they aren't arch all:
>> 
>> Grub Maintainers <[EMAIL PROTECTED]>
>>grub
> 
> Again, there is a very good reason:
> | /usr/sbin/grub: ELF 32-bit LSB executable, Intel 80386, version 1
> | (SYSV), for GNU/Linux 2.6.1, dynamically linked (uses shared libs),
> | stripped
> 
>> Camm Maguire <[EMAIL PROTECTED]>
>>hol88-library
> 
> So, again, *how* do you find it possible to list this package as MUST be
> Architecture: all, while it has things like that inside?
> | … cut …
> | /usr/lib/hol88-2.02.19940316/Library/pair/basic_ml.o: ELF 32-bit LSB
> | relocatable, Intel 80386, version 1 (SYSV), not stripped
> | /usr/lib/hol88-2.02.19940316/Library/pair/both1_ml.o: ELF 32-bit LSB
> | relocatable, Intel 80386, version 1 (SYSV), not stripped
> | usr/lib/hol88-2.02.19940316/Library/pair/both2_ml.o: ELF 32-bit LSB
> | relocatable, Intel 80386, version 1 (SYSV), not stripped … cut …
> 

There "MUST" be something wrong with the package then, how is that i386's
and amd64's md5sum are exactly the same?

>> Robert Millan <[EMAIL PROTECTED]>
>>grub (U)
> 
> Again…

Did you notice the "(U)"? ;)

> 
>> Masahito Omote <[EMAIL PROTECTED]>
>>libuim-data
> 
> Sounds reasonable.
> 
>> Otavio Salvador <[EMAIL PROTECTED]>
>>grub (U)
>> Jason Thomas <[EMAIL PROTECTED]>
>>grub (U)
> 
> Again…
> 
>> As usually, feedback is welcome.
> 
> Reiterating…
> 

Should probably compare i386 and something like armel next time.

I'm, again, sorry for those false positives (didn't expect them by comparing
md5sums of two different architectures).

Cheers,
Raphael Geissert



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

Bug#460983: PTS: Please link to Security Tracker

[Raphael Hertzog]

Hi,

On Wed, 16 Jan 2008, Moritz Muehlenhoff wrote:
> It would be good if the PTS would link to the Debian Security Tracker.
> 
> The URL format is
> http://security-tracker.debian.net/tracker/source-package/SRCPKGNAME

Can you provide a (regularly updated) file which list sources packages for
which there are open issues? Maybe with a count of open issues and a list
of CVE?

  CVE-XXX ...

The PTS usually only provides some link when there's something
intesresting to watch behind the link.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#461000: packages.qa.debian.org: Status report bug list only links to one bug

[Raphael Hertzog]

On Wed, 16 Jan 2008, Kapil Hari Paranjape wrote:
> Package: qa.debian.org
> Severity: normal
> 
> Hello,
> 
> The entry "Testing status" refers to the list of bugs that are
> holding back a package. This entry is a hyperlink but links to only
> one of the bugs even when there is more than one bug that is
> holding back the package.

Indeed: http://packages.qa.debian.org/c/cron.html

Anyone who want to look at the issue can check www/bin/excuses_to_xml.py.
The XML conversion has not been designed to handle mutiple URL per lines.
Maybe it should just copy over raw HTML in that particular case. (It's
just parsing update_excuses.html.gz)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#460983: PTS: Please link to Security Tracker

[Raphael Hertzog]

On Wed, 16 Jan 2008, Florian Weimer wrote:
> Yes, this should be possible.  I will think a bit abot it end try to
> write some code to implement this.  It will be easier if we also include
> resolved security issues in the count (otherwise, it's hard to express
> the state in a single number).

I'd like to see it implemented in the following way:
- if there are open issues, then add an entry in the TODO part of the page
- if there are issues (whatever their status), add a link in a sidebar somewhere
- if there's nothing in the tracker, then there should be no link at all

Thus it's important to have a count of open issues (and closed issues if
you want a link on the sidebar and not only a link in the TODO part).

> > The PTS usually only provides some link when there's something
> > intesresting to watch behind the link.
> 
> The drawback is that the link only appears after the next PTS update.
> (We could AJAX to create the link. 8-P)

It's not a drawback it's a feature. A link which is always displayed is
far less likely to be checked by the maintainer than a link that's
displayed only when there's something relevant to see.

Then of course we could make the PTS 100% dynamic and refresh the content
more often. But that's a task that I won't pursure in the near future. :)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#460821: color wrong in watch column of xsel

[Raphael Geissert]

tag 460821 moreinfo unreproducible
thanks

Hello Joe,

Based on the information you provided I'm unable to reproduce that behaviour:
Original: 0.9.6-3 | DEHS: 0.9.6
('DEHS' refers to the un-debianised version produced by DEHS' code)

So:
% upstream=1.0.0; debian=0.9.6; if dpkg --compare-versions $upstream gt 
$debian; then echo magenta; elif dpkg --compare-versions $upstream lt 
$debian; then echo AA; else echo green; fi
magenta

That is more or less the shell-code version of the PHP code used  by the DDPO.

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html



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

Bug#356826: PTS: could e-mail when DEHS detects new upstream release

[Raphael Geissert]

Hello,

On Tuesday 14 March 2006, Martin-Éric Racine wrote:
> Package: qa.debian.org
> Severity: wishlist
>
> PTS could e-mail whenever DEHS detects a new upstream release of the
> package being monitored by a watch file.  This would be particularly
> usefull in case where upstream packages don't have a mailing list to
> notify interested parties of new releases.

This has been partially implemented in the DEHS backend, what's left now is to 
make the backend store a list of upstream versions for which a notification 
was sent and to make the PTS deliver the messages.

I'm explicitly CC'ing [EMAIL PROTECTED] to see how this can be done 
(adding the 'newversion' tag/keyword to the PTS and making a default:off).

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Re: List of packages which should probably be Architecture: all

[Raphael Geissert]

d64/md5sums and i386/md5sums differ
gnustep-make-ogo: Files amd64/md5sums and i386/md5sums differ
gstreamer0.10-gnonlin-dev: Files amd64/md5sums and i386/md5sums differ
hol88-library *MUST* be Architecture: all! identical files: amd64/md5sums
i386/md5sums powerpc/md5sums
icewm-common: Files amd64/md5sums and i386/md5sums differ
inn2-dev: Files amd64/md5sums and i386/md5sums differ
integrit: Files amd64/md5sums and i386/md5sums differ
iproute-dev: Files amd64/md5sums and i386/md5sums differ
iptables-dev: Files amd64/md5sums and i386/md5sums differ
kadu-dev: Files amd64/md5sums and i386/md5sums differ
kannel-dev: Files amd64/md5sums and i386/md5sums differ
laptop-detect *MUST* be Architecture: all! identical files: amd64/md5sums
i386/md5sums powerpc/md5sums
Processing lde...
libacovea-dev: Files amd64/md5sums and i386/md5sums differ
libagg-dev: Files amd64/md5sums and i386/md5sums differ
libaio1: Files amd64/md5sums and i386/md5sums differ
libantlr-dev: Files amd64/md5sums and i386/md5sums differ
libatomic-ops-dev: Files amd64/md5sums and i386/md5sums differ
libavahi-common-data: Files amd64/md5sums and i386/md5sums differ
libbakery-2.3-common *MUST* be Architecture: all! identical files:
amd64/md5sums i386/md5sums  powerpc/md5sums
libbitcollider-dev: Files amd64/md5sums and i386/md5sums differ
libcegui-mk2-doc *MUST* be Architecture: all! identical files: amd64/md5sums
i386/md5sums  powerpc/md5sums
libchewing3-data *MUST* be Architecture: all! identical files: amd64/md5sums
i386/md5sums  powerpc/md5sums
libcnf-dev: Files amd64/md5sums and i386/md5sums differ
libcurl3-dbg: Files amd64/md5sums and i386/md5sums differ
libcwnn-dev: Files amd64/md5sums and i386/md5sums differ
libdaemons-ruby1.8: Files amd64/md5sums and i386/md5sums differ
libdballe-bufrex-doc *MUST* be Architecture: all! identical files:
amd64/md5sums i386/md5sums  powerpc/md5sums
libdballe-core-doc *MUST* be Architecture: all! identical files:
amd64/md5sums i386/md5sums  powerpc/md5sums
libdballe-db-doc *MUST* be Architecture: all! identical files: amd64/md5sums
i386/md5sums  powerpc/md5sums
libdballe-msg-doc *MUST* be Architecture: all! identical files:
amd64/md5sums i386/md5sums  powerpc/md5sums
libdds-dev: Files amd64/md5sums and i386/md5sums differ
libdiscover1-pic: Files amd64/md5sums and i386/md5sums differ
libdts-dev: Files amd64/md5sums and i386/md5sums differ
libdvb-dev: Files amd64/md5sums and i386/md5sums differ
libflake-dev: Files amd64/md5sums and i386/md5sums differ
libgcj-common: Files amd64/md5sums and i386/md5sums differ
libgdb-dev: Files amd64/md5sums and i386/md5sums differ
libgeomview-dev: Files amd64/md5sums and i386/md5sums differ
libgfccore-doc *MUST* be Architecture: all! identical files: amd64/md5sums
i386/md5sums powerpc/md5sums
libgii1-target-x: Files amd64/md5sums and i386/md5sums differ
libicecc-dev: Files amd64/md5sums and i386/md5sums differ
libinotifytools0-dev: Files amd64/md5sums and i386/md5sums differ
libipod-doc *MUST* be Architecture: all! identical files: amd64/md5sums
i386/md5sums powerpc/md5sums
libitalc *MUST* be Architecture: all! identical files: amd64/md5sums
i386/md5sums powerpc/md5sums
libklibc: Files amd64/md5sums and i386/md5sums differ
libkwnn-dev: Files amd64/md5sums and i386/md5sums differ
libldns-dev: Files amd64/md5sums and i386/md5sums differ
liblivemedia-dev: Files amd64/md5sums and i386/md5sums differ
liblpsolve55-dev: Files amd64/md5sums and i386/md5sums differ
libmdsp-dev: Files amd64/md5sums and i386/md5sums differ
libmrss0-dbg: Files amd64/md5sums and i386/md5sums differ
Processing libmythes-dev...
libnetgen-dev: Files amd64/md5sums and i386/md5sums differ
libnxml0-dbg: Files amd64/md5sums and i386/md5sums differ
libopie-dev: Files amd64/md5sums and i386/md5sums differ
libotpw-dev: Files amd64/md5sums and i386/md5sums differ
libpthread-stubs0 *MUST* be Architecture: all! identical files:
amd64/md5sums i386/md5sums powerpc/md5sums
libpulse-browse0-dbg: Files amd64/md5sums and i386/md5sums differ
libqcad0-dev: Files amd64/md5sums and i386/md5sums differ
libqt3-headers: Files amd64/md5sums and i386/md5sums differ
libqthreads-12: Files amd64/md5sums and i386/md5sums differ
Processing libsrtp1-dev...
libsyck0-dev: Files amd64/md5sums and i386/md5sums differ
libtclap-dev: Files amd64/md5sums and i386/md5sums differ
Processing libuclibc0...
libuim-data has same files: amd64/md5sums i386/md5sums  but differ from
powerpc/md5sums
Processing libunittest++0...


Cheers,
Raphael Geissert


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

Bug#356826: PTS: could e-mail when DEHS detects new upstream release

[Raphael Hertzog]

On Mon, 21 Jan 2008, Raphael Geissert wrote:
> > PTS could e-mail whenever DEHS detects a new upstream release of the
> > package being monitored by a watch file.  This would be particularly
> > usefull in case where upstream packages don't have a mailing list to
> > notify interested parties of new releases.
> 
> This has been partially implemented in the DEHS backend, what's left now is 
> to 
> make the backend store a list of upstream versions for which a notification 
> was sent and to make the PTS deliver the messages.
> 
> I'm explicitly CC'ing [EMAIL PROTECTED] to see how this can be done 
> (adding the 'newversion' tag/keyword to the PTS and making a default:off).

I'm not sure it's really worth a new tag but on the other hand I'm not
sure which actual tag to use. summary could probably be used.

But for me, ideally this should be filing bugs about new upstream versions
not sending mails to the PTS because we really want to inform the
maintainer and not only the followers. I'm sure using a usertag to track
them and combining this with some regexp to detect bugs manually filed
with some common subject ("New upstream version") would work quite well.
And if the code runs often enough, it will probably be the first to submit
a bug about a new upstream version in most cases.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#356826: PTS: could e-mail when DEHS detects new upstream release

[Raphael Hertzog]

On Tue, 22 Jan 2008, [EMAIL PROTECTED] wrote:
> I asked about adding a new tag because summary is by default sent to
> the maintainer unless I've never really payed too much attention and
> the testing migration email is sent to both, the maintainer and the
> PTS.

That's the case: the testing mail is sent both the the maintainer and to
the PTS.

> When discussing about this topic with several people some have asked
> me not to make the PTS send the notifications by default. And for the
> sake of simplicity I think it is far easier to use the PTS'
> subscription system with a new tag and let then decide whether to make
> it the default or not.

Well, the tag mechanism is nice but I definitely don't want to add many
very-specific keywords until it gets unmanageable. So I won't create a new
keyword... if you want to send a mail to the PTS send it to the summary
keyword (you send a mail to
[EMAIL PROTECTED] but in the To: field you only put
@packages.debian.org to hide the keyword specific email address).

> > But for me, ideally this should be filing bugs about new upstream versions
> > not sending mails to the PTS because we really want to inform the
> > maintainer and not only the followers. I'm sure using a usertag to track
> > them and combining this with some regexp to detect bugs manually filed
> > with some common subject ("New upstream version") would work quite well.
> > And if the code runs often enough, it will probably be the first to submit
> > a bug about a new upstream version in most cases.
> 
> With the current design DEHS would email the PTS immediately after it
> finds a new upstream version.
> As others have expressed their concern, I don't think auto bug filing
> is the best way to do this.

Well, maybe the right way is to let some time pass as suggested by Lucas
and others. Provide the real-time information on the web page, but only
open a bug when two weeks have elapsed and when the new version is
neither in unstable nor in experimental.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#461891: qa.debian.org: DDPO testing migration excuses changes

[Raphael Hertzog]

On Wed, 23 Jan 2008, Martin Zobel-Helas wrote:
> On Mon Jan 21, 2008 at 20:36:19 +0900, Paul Wise wrote:
> > Please use release.debian.org/migration/testing.pl instead of
> > bjorn.haxx.se/debian/testing.pl, since the former is more "official" and
> > more likely to be maintained since the release team are responsible for
> > it.
> 
> i second this proposal. We (the release team) took that tool under our
> domain, as we are happy with it maintaining and also we have more or
> less live data available directly on ftp-master, though the data is
> still pre-generated and cached, so we do not put to much load on the
> machine.

I have changed the link on the PTS side. I'll let other handle DDPO and
removal of excuses.php.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#356826: PTS: could e-mail when DEHS detects new upstream release

[Raphael Geissert]

tag 356826 pending
thanks

On 23/01/2008, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> On Tue, 22 Jan 2008, [EMAIL PROTECTED] wrote:
> > I asked about adding a new tag because summary is by default sent to
> > the maintainer unless I've never really payed too much attention and
> > the testing migration email is sent to both, the maintainer and the
> > PTS.
>
> That's the case: the testing mail is sent both the the maintainer and to
> the PTS.
>
> > When discussing about this topic with several people some have asked
> > me not to make the PTS send the notifications by default. And for the
> > sake of simplicity I think it is far easier to use the PTS'
> > subscription system with a new tag and let then decide whether to make
> > it the default or not.
>
> Well, the tag mechanism is nice but I definitely don't want to add many
> very-specific keywords until it gets unmanageable. So I won't create a new
> keyword... if you want to send a mail to the PTS send it to the summary
> keyword (you send a mail to
> [EMAIL PROTECTED] but in the To: field you only put
> @packages.debian.org to hide the keyword specific email address).

Ok, I'll change it in my next commit.

>
> > > But for me, ideally this should be filing bugs about new upstream versions
> > > not sending mails to the PTS because we really want to inform the
> > > maintainer and not only the followers. I'm sure using a usertag to track
> > > them and combining this with some regexp to detect bugs manually filed
> > > with some common subject ("New upstream version") would work quite well.
> > > And if the code runs often enough, it will probably be the first to submit
> > > a bug about a new upstream version in most cases.
> >
> > With the current design DEHS would email the PTS immediately after it
> > finds a new upstream version.
> > As others have expressed their concern, I don't think auto bug filing
> > is the best way to do this.
>
> Well, maybe the right way is to let some time pass as suggested by Lucas
> and others. Provide the real-time information on the web page, but only
> open a bug when two weeks have elapsed and when the new version is
> neither in unstable nor in experimental.

I will go the "notifying via the PTS" way for now.
I'll also provide the required information for Lucas to also notify
about new upstream releases on his monthly mail.

>
> Cheers,
> --
> Raphaël Hertzog
>
> Le best-seller français mis à jour pour Debian Etch :
> http://www.ouaza.com/livre/admin-debian/
>

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Say NO to Microsoft Office broken standard.
See http://www.noooxml.org/petition

Bug#462470: PTS: don't show changelog-only ubuntu patches

[Raphael Hertzog]

Hi,

On Fri, 25 Jan 2008, Paul Wise wrote:
> Package: qa.debian.org
> Severity: wishlist
> 
> I would like it if the PTS didn't link to changelog-only Ubuntu patches.
> Here is an example:
> 
> http://packages.qa.debian.org/s/synfig.html
> http://patches.ubuntu.com/s/synfig/synfig_0.61.07-1build1.patch

By changelog-only, one must understand "binnmu" in the Ubuntu world.

Scott, could you exclude those from the PATCH file that you generate?
(http://patches.ubuntu.com/PATCHES)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Re: empty Packages.qa.debian.org pages gone

[Raphael Hertzog]

On Fri, 25 Jan 2008, Stefano Zacchiroli wrote:
> On Wed, 14 Apr 2004 10:31:55 +0200, Jeroen van Wolffelaar wrote:
> > Caused due to space problems, it's fixed now. Converting this bug into a
> > minor one about better error handling, but importance is really
> > very minor IMHO (shouldn't happen, if it happens you get outdated rather
> > than no info... still not good).
> > 
> > Alternatively, a mail being sent if the update somehow fails is also a
> > step in the right direction I think.
> 
> This is now implemented: bin/generate_html.sh will echo on standard
> output issues if xsltproc does not return exit code 0. Since the PTS
> update is run via cron, someone should receive an email related to the
> output.
> 
> Don't know who is listening to cron output for the qa user though ...,

In master's crontab:
MAILTO=hertzog,jeroen

If you want to be added there, I can add you.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Bug#354307: packages.qa.debian.org/m/mydsn.html has weird sorted news

[Raphael Hertzog]

On Sat, 26 Jan 2008, Stefano Zacchiroli wrote:
> On Fri, Jan 25, 2008 at 08:05:01PM +0100, Stefano Zacchiroli wrote:
> > Moreover, and that's the main point of this report, it seems that the
> > last time the clash happened was January 2006, no other clashes in 2007
> > nor 2008. Is it possible that the issue has been solved elsewhere and
> > the clash no longer happens?
> 
> And indeed this diff explains the reason:
> 
>   [EMAIL PROTECTED]:/srv/debian/pts/www/bin$ svn diff -r1281:1282 
> common.py|grep -C 2 raise
>   +targetfile = "%s/%s.txt" % (dir, info['timestamp'])
>   +if os.path.isfile(targetfile):
>   +raise("Aiee, already such message %s" % targetfile)
>   +f = open(targetfile, "w")
>f.write(msg.as_string())
> 
> it is dated February 2006. So, starting from there on, duplicate news
> are refused on the basis of its timestamp alone.
> 
> I will then get rid of duplicates and see what to do with the other
> strange files ...

Note that this behaviour should be fixed. It happens that dak send several
Accepted mails during the same second for example when the package gets
out of NEW and when several upload happened while the package was sitting
in NEW.

I remember neuro complaining about getting bounces on those cases. Jeroen
never got around to fix that.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#457759: PTS: bug summary counts bugs that are assigned to two or more packages more than once

[Raphael Hertzog]

On Sat, 26 Jan 2008, Stefano Zacchiroli wrote:
> On Tue, 25 Dec 2007 13:13:56 +0100, "Frank S. Thomas" wrote:
> > If one bug is assigned to two or more binary packages of the same
> > source package, the PTS' "Bugs count" summary counts this bug more
> > than once. This summary should only count bugs in the source package.
> > The DDPO does this right, compare for example:
> 
> The fix for this is trickier than what it might seem.
> Apparently, the PTS has only bug stats about binary packages. Here is
> the relevant snippet from www/bin/update_incoming.sh:
> 
>   # Download bugs summary
>   nice_wget http://merkel.debian.org/~hertzog/pts/bugs.txt bugs.txt
> 
> and the downloaded file is binary package oriented (for example, "boinc"
> itself does not appear).
> 
> Raphael, how is that file generated? Can we add the generation of an
> extra incoming source containing source oriented bug stats?

[EMAIL PROTECTED]:~$ crontab -l
# List of bugs for PTS
20 15,7,23 * * *($HOME/bin/process-index.pl 
/org/bugs.debian.org/spool/index.db >$HOME/public_html/pts/bugs.txt)
*/10 * * * * (cp -fp /org/bugs.debian.org/etc/indices/sources 
$HOME/public_html/pts/sources)

Feel free to improve whatever you want in that script. :)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#354307: packages.qa.debian.org/m/mydsn.html has weird sorted news

[Raphael Hertzog]

On Sat, 26 Jan 2008, Stefano Zacchiroli wrote:
> On Sat, Jan 26, 2008 at 02:17:19PM +0100, Raphael Hertzog wrote:
> > Note that this behaviour should be fixed. It happens that dak send several
> > Accepted mails during the same second for example when the package gets
> > out of NEW and when several upload happened while the package was sitting
> > in NEW.
> > 
> > I remember neuro complaining about getting bounces on those cases. Jeroen
> > never got around to fix that.
> 
> Ok, here is a proposed (yet untested) fix:
> 
>   [EMAIL PROTECTED]:/srv/debian/pts/www/bin$ svn diff common.py
>   Index: common.py
>   ===
>   --- common.py   (revision 1821)
>   +++ common.py   (working copy)
>   @@ -18,8 +18,13 @@
>info = extract_info(msg)
>
>targetfile = "%s/%s.txt" % (dir, info['timestamp'])

targetfile = "%s/%s.0.txt" % (dir, info['timestamp'])

At least it'll fix the sorting order...

>   -if os.path.isfile(targetfile):
>   -raise("Aiee, already such message %s" % targetfile)
>   +nonce = 0
>   +while os.path.isfile(targetfile):
>   +nonce += 1
>   +if nonce > 128: # eventually give up
>   +raise("can't find a free slot to save message, last stried was 
> %s"\

s/stried/tried/

>   +% targetfile)
>   +targetfile = "%s/%s.%d.txt" % (dir, info['timestamp'], nonce)
>f = open(targetfile, "w")
>f.write(msg.as_string())
>f.close()
> 
> It assumes however that all mails received in the very same second are
> to be kept, is it a correct assumption?

I think so.

> Also, it sort strangely news received in the very same second, here is
> an example of what I mean (ipython session):
> 
>   In [18]: a=['1236.txt', '1235.txt', '1234.txt', '1235.1.txt', '1235.2.txt']
>   In [19]: a.sort()
>   In [20]: a.reverse()
>   In [21]: a
>   Out[21]: ['1236.txt', '1235.txt', '1235.2.txt', '1235.1.txt', '1234.txt']
> 
> This can be fixed in update_news.py using an ad-hoc sorting function,
> but I don't think it's worth, after all those mail have all been
> received in the very same second, whatever order would do IMO.

You can also simply fix the default filename. :)

> Let me know if you want me to commit this fix or not ...

Go ahead with the little changes above.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#354307: packages.qa.debian.org/m/mydsn.html has weird sorted news

[Raphael Hertzog]

On Sun, 27 Jan 2008, Stefano Zacchiroli wrote:
> On Sat, Jan 26, 2008 at 06:21:16PM +0100, Raphael Hertzog wrote:
> > targetfile = "%s/%s.0.txt" % (dir, info['timestamp'])
> > At least it'll fix the sorting order...
> 
> Yes, but it will add the ".0" to all files. While not using it we will
> have the extra digit only when needed, which I hope are exception rather
> than rules.  If you really want to have the sorting fixed (which, let me
> insist, should be not that relevant, given that all the mails we are
> talking about have been sent in the very same second) I prefer to use a
> custom sorting function.

Do you really find the URL nice enough to worry for a .0 ? I believe the
sorting to be important because even if it's the same second, I think they
are sent in order of increasing versions. And it wouldn't be nice to see:

Accepted 1.0-1
Accepted 1.0-3
Accepted 1.0-2

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#463186: PTS: should not list the same architecture more than once

[Raphael Geissert]

Package: qa.debian.org
User: [EMAIL PROTECTED]
Usertags: pts
Severity: minor

The PTS in pages for packages such as 'gambas'[1] should only list 'i386' once 
and not 20 times.

[1]http://packages.qa.debian.org/g/gambas.html

Kind regards,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html



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

Re: DEHS error for gpe-soundserver mangling

[Raphael Geissert]

Hello Neil,

Neil Williams wrote:
> However, the PTS gets the wrong data from
> http://dehs.alioth.debian.org/maintainer.php?name=gpe-soundserver
> and wrongly indicates that 0.4-1 is new.
> 
> I know the mangling is a pain and upstream will probably sort it out at
> the next release but that isn't a good enough reason to make a release
> and no release is pending.
> 
> Can the DEHS website be brought into line with uscan ?
> 

The problem was caused by DEHS performing some mangling on the Debian
version besides using the debian-mangled-uversion value provided by uscan.

I have fixed this problem about two days ago but there are some packages
that are still affected by this bug and their status will be fixed next
time DEHS process their watch file.
I've manually made DEHS check the above mentioned package so the message
will disspear from the PTS on its next pulse.

Note that the change made to DEHS also needs to be applied to the DDPO code
so the correct versions comparison is also performed there.
I'll send an appropriate patch to Myon during this weekend.

Sincerely,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Bug#462470: PTS: don't show changelog-only ubuntu patches

[Raphael Hertzog]

On Mon, 04 Feb 2008, Scott James Remnant wrote:
> On Fri, 2008-01-25 at 19:24 +0100, Raphael Hertzog wrote:
> > Scott, could you exclude those from the PATCH file that you generate?
> > (http://patches.ubuntu.com/PATCHES)
> > 
> Please file it as a wishlist bug:
> 
> http://launchpad.net/merge-o-matic/+bugs

Done: https://bugs.launchpad.net/merge-o-matic/+bug/188955

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#464021: PTS: please notify when a package is orphaned/ITAed

[Raphael Hertzog]

Hi,

On Thu, 07 Feb 2008, Lucas Nussbaum wrote:
> On 04/02/08 at 20:24 +0100, Lucas Nussbaum wrote:
> > Package: qa.debian.org
> > User: [EMAIL PROTECTED]
> > Usertags: pts
> > Severity: wishlist
> > 
> > Hi,
> > 
> > This was raised in the discussion of #453467, about the orphaning, then
> > removal, of phpgroupware.
> > 
> > It would be great if the PTS sent a notification to people subscribed to
> > the package when a package is orphaned or ITAed (like for the testing
> > migration emails).
> > 
> > Does somebody object? Is somebody working on that already? If not, I'll
> > try to work on that (or find someone to work on that ;)
> 
> I wrote a script that sends such notifications to the PTS "summary" keyword.
> I tested it. It's now in production.

Where is that script ? How does it work ?

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Re: What to do if Homepage seems to have vanished

[Raphael Geissert]

Andreas Tille wrote:

> On Sun, 17 Feb 2008, Jack T Mudge III wrote:
> 
>> AFAICT, it would seem that didiwiki is in this group as well. I found
>> plenty of links to it's nonexistant homepage. It's a frusterating
>> situation, since most users (myself included) expect to be able to go to
>> the homepage and find out more about the package.
> 
> Well, we have more links than homepage references and thus we might run
> a link checker periodically onto the descriptions.  The question is, what
> finally is the best thing to do if there is a broken link.

On that subject please refer to #459012

> 
> Kind regards
> 
>Andreas.
> 

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: the new style "mass tirage" of bugs

[Raphael Hertzog]

On Sat, 23 Feb 2008, Stefano Zacchiroli wrote:
> On Fri, Feb 22, 2008 at 02:59:46PM +0100, Raphael Hertzog wrote:
> > http://packages.qa.debian.org/d/dpkg.html
> > http://people.debian.org/~glandium/bts/d/dpkg.png
> 
> Technical question: why are the graphs on people.d.o instead of
> master.d.o as the rest? Space problems or what?

I didn't setup those graphs as you probably noticed and I simply added the
link. In the long term, it's probably best to take the maintenance of the
graph generation within the QA team. Anyone should be free to work with
Mike Hommey and do that. Maybe Mike can say a word on this topic, I
haven't checked but I expect the code to be easy to find on its accont on
gluck.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Bug#468798: PTS: add Debian favicon to web interface

[Raphael Hertzog]

On Sat, 01 Mar 2008, Stefano Zacchiroli wrote:
> user [EMAIL PROTECTED]
> usertag 468798 + pts
> thanks
> 
> On Sat, Mar 01, 2008 at 03:54:43PM +0100, Giovanni Mascellani wrote:
> > Lower-than-low priority bug, but I like to see the nice Debian swirl
> > also in the favicon of packages.qa.debian.org, which now doesn't have
> > anything.
> 
> Can you please attach the favicon.ico file you are actually proposing?
> Out of memory it should be somewhere available in the default apache
> conf in Debian, but after a quick look I haven't found it ...

wget http://www.debian.org/favicon.ico

Note that the BTS apparently redirects http://bugs.debian.org/favicon.ico
to the URL above while wiki.debian.org has its own copy apparently.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Re: co-mentor wanted for a QA GSOC project

[Raphael Geissert]

Hi,

Lucas Nussbaum wrote:
> 
> I'd like to propose this GSOC project:
> http://wiki.debian.org/SummerOfCode2008/UltimateDebianDatabase

That'd be a great tool to have around.

> 
> Also, is someone reading this list interested in being the student?

I am, though I can't apply because I'm minor aged :(.

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Bug#469258: PTS/DDPO should include bugs tagged as release-goals in statistics

[Raphael Hertzog]

Package: qa.debian.org
Severity: wishlist
User: [EMAIL PROTECTED]
Usertags: pts ddpo

Hi,

I discovered that the DDPO mails promoted the release-goals bugs that
affect one's packages. I find this great.

We need the same information in the PTS and in the DDPO web page. One idea
might be to integrate them in the "Release critical" bug count (I know
release goals are not release critical but we still want maintainers to
fix them... :-)).

For the PTS, it might be best to create a dedicated TODO item when the
packages has open release-goal bugs.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Re: Sourceforge redirector proxy thing broken?

[Raphael Geissert]

Paul Wise wrote:
> On Thu, Mar 20, 2008 at 3:37 PM, Andrew Pollock <[EMAIL PROTECTED]>
> wrote:
> 
>>  I was just trying to fix up a watch file for simpleproxy, which is
>>  hosted on SourceForge, and I used the format the man page for uscan said
>>  to use, which uses the qa.debian.org proxy. The thing is, that seems to
>>  be broken, possibly because it's trying to talk to a down SourceForge
>>  mirror.
> 
> The redirector should be changed to point to downloads.sf.net instead
> of a specific mirror, because you can wget individual files from
> downloads.sf.net these days; it uses HTTP redirects to send you to the
> right mirror, and each one redirects back if they don't have the file.
> 

The problem is that the syntax required to use downloads.sf.net is not that
works with the redirector.
ftp://upload.sourceforge.net isn't an option either because the http->ftp
redirection isn't correctly handled by uscan, resulting in a "no matching
hrefs for watch line".

The only one that seems to support directory listing and has most, if not
all, the files around is garr.

So, could somebody please make the redirector use
header("Location: http://garr.dl.sourceforge.net/sourceforge/$project";);


Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: Bug#453487: Severity of "should this package be orphaned/removed" bugs

[Raphael Geissert]

Lucas Nussbaum wrote:
> 
> Luk, what are the reasons why you think that severity: important is more
> suitable than severity: serious? If it's only because it blocks testing
> transitions, we could mark the bugs as found in the testing version
> where needed, so testing transitions can still happen.

I don't think it's because of that, those packages usually have the same
version in sid, lenny and etch (or sarge, if it didn't make it for etch).


Other than that, IMHO we should not be cloning the bug reports when
orphaning before removing a package. Since yesterday I began reassign the
reports to package,wnpp and retitling them without dropping the severity of
the report.

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

RFC: bapase changes

[Raphael Geissert]

Hi all,

After a short talk with Lucas I made some changes to bapase (not yet in the 
repository) which I'd like to get some feedback before committing them.

The first set of changes (bapase_orphaned++.diff) is to score higher orphaned 
packages not in oldstable nor stable. With this score bump I'd like to catch 
some packages that are being uploaded and orphaned before a release is made.

The second set of changes (bapase_dehs.diff) is making bapase DEHS-aware, 
changing the scores on the next basis:

When scoring useless packages:
score += (CURDATE - $dehs[pkg][last_in_sync_with_upstream]) * 2

When scoring orphaned packages:
score += (CURDATE - $dehs[pkg][last_in_sync_with_upstream])


Comments, suggestions, all welcome.

P.D. please review the code because I haven't, really, programmed in ruby so I 
can't say for sure that the code I wrote is ok.

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
Index: datafiles.rb
===
--- datafiles.rb	(revision 748)
+++ datafiles.rb	(working copy)
@@ -22,6 +22,30 @@
   return [srcpkg, pkgs]
 end
 
+# same as above but for stable and oldstable (we don't want to mix them with unstable & testing)
+def read_oldsources
+  srcpkg = {}
+  pkgs = {}
+  Dir::glob('{,old}stable-*-Sources') do |s|
+src = nil
+IO::read(s).each_line do |l|
+  if l =~ /^Package:/
+src = l.split(' ')[1].chomp
+pkgs[src] = [] if pkgs[src].nil?
+  elsif l =~ /^Binary:/
+l.split(' ',2)[1].split(', ').each do |b|
+  b.chomp!
+  if srcpkg[b].nil? # else, we already know that binary pkg
+srcpkg[b] = src
+pkgs[src] << b
+  end
+end
+  end
+end
+  end
+  return [srcpkg, pkgs]
+end
+
 def read_nmus
   nmus = {}
   Dir::glob('unstable-*-Sources') do |s|
Index: gen_html.rb
===
--- gen_html.rb	(revision 748)
+++ gen_html.rb	(working copy)
@@ -14,6 +14,7 @@
 
 $testing = read_testing
 $srcpkg, $pkgs = read_sources
+$old_srcpkg, $old_pkgs = read_sources
 $nmus = read_nmus
 $popcon = read_popcon
 $rcbugs, $bugs = read_bugs
@@ -168,6 +169,9 @@
   else
 score += 100
   end
+  if !$old_pkgs.has_key?(pkg)
+score += 100
+  end
   if $actions[pkg] and $actions[pkg].act_todo
 score += 10 # bump score if action needed
   end
Index: datafiles.rb
===
--- datafiles.rb	(revision 748)
+++ datafiles.rb	(working copy)
@@ -42,6 +42,17 @@
   return nmus
 end
 
+# from collab-qa/ddpo-by-mail/dehs.rb with some minor changes
+def read_dehs
+  dehs = {}
+  IO::read('dehs.txt').each_line do |l|
+pkg, unstable, upstream, date = l.chomp.split('|')
+next if date == "1970-01-01 00:00:00"
+d = Date::parse(date)
+dehs[pkg] = [ unstable, upstream, d ]
+  end
+  return dehs
+end
 
 class TestingStatus
   attr_accessor :testingversion, :unstableversion, :firstinunstable, :testingdays, :intesting, :syncdays, :sync, :syncversion
Index: gen_html.rb
===
--- gen_html.rb	(revision 748)
+++ gen_html.rb	(working copy)
@@ -19,6 +19,7 @@
 $rcbugs, $bugs = read_bugs
 $wnpp = read_wnpp
 $removals = read_removals
+$dehs = read_dehs
 $actions = Actions::read('package-actions.txt')
 $orph = OrphanedPackage::readfile
 $uploadhistory = LastUpload::readfile
@@ -138,6 +139,9 @@
   if $popcon[pkg] < 200
 score += (200 - $popcon[pkg]) * 8
   end
+  if $dehs.has_key?(pkg)
+score += (CURDATE - $dehs[pkg][2]) * 2
+  end
   if $uploadhistory.has_key?(pkg)
 uh = $uploadhistory[pkg]
 if CURDATE - uh.date > 30
@@ -174,6 +178,9 @@
   if $popcon[pkg] < 500
 score += (500 - $popcon[pkg]) * 2
   end
+  if $dehs.has_key?(pkg)
+score += (CURDATE - $dehs[pkg][2])
+  end
   if $rcbugs[pkg] > 0
 if $rcbugs[pkg] > 4
   score += 5 * 300
Index: Makefile
===
--- Makefile	(revision 748)
+++ Makefile	(working copy)
@@ -2,7 +2,7 @@
 
 all: scores-html
 	
-scores-html: Sources_ok testing-status.txt popcon_sources.txt package-actions.txt bugsummary wnppsummary orphaned_packages.txt upload-history.txt removals.txt
+scores-html: Sources_ok testing-status.txt popcon_sources.txt package-actions.txt bugsummary wnppsummary orphaned_packages.txt upload-history.txt removals.txt dehs.txt
 	./gen_html.rb
 
 Sources_ok: testing-main-Sources testing-contrib-Sources testing-non-free-Sources unstable-main-Sources unstable-contrib-Sources unstable-non-free-Sources stable-main-Sources stable-contrib-Sources stable-non-free-Sources oldstable-main-Sources oldstable-con

Re: RFC: bapase changes

[Raphael Geissert]

Lucas Nussbaum wrote:
> 
> Sounds good, please commit.

Done :).

> 
> Also note that in packages-actions.txt, you must use REQ_RM(), not
> RM(), or just don't complain when the automatically-generated pages are
> not generated anymore :P

Oops, I got tricked by O(), sorry.

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: RFH: bapase

[Raphael Geissert]

Hi,

Lucas Nussbaum wrote:
> 
> Are some people interested? (I don't see any reason why they would need
> to be DDs)

As expected, I'm in (though I've already been working on it ;)

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: RFH: piuparts testing of the archive

[Raphael Geissert]

Lucas Nussbaum wrote:
> 
> What needs to be done is:
> - run installation/removal/purge tests for all packages
> - run upgrade tests for all packages in etch
> - make changes to piuparts to fix false positives or reduce the number
>   of failures by ignoring the less critical ones
> - file all the bugs (many of those are RC)

On log processing, what about doing a dependency-based log processing?
so if package bar depends on foo, and foo fails to upgrade (or doesn't pass
all the piuparts tests) it is very likely that bar will fail too, at least,
because of foo.

I think there was some tool around to build a dependency tree out of a
Packages, so the main part of the log processing tool is already done.

Cheers,
Raphael


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

Bug#481315: PTS could avoid duplicate copies of messages

[Raphael Hertzog]

user [EMAIL PROTECTED]
usertag 481315 + pts
tag 481315 + wontfix
thanks

On Thu, 15 May 2008, Loïc Minier wrote:
>  It would be easier if we could simply subscribe to the PTS of all
>  packages all the time, but the PTS would exclude the Maintainer: from
>  the subscribers when sending emails which are already sent to the
>  Maintainer upstream (debbugs, dak etc.).

There's no way I'm going to implement something as complicated as that.
We don't want more complexity, we need the opposite.

The real fix for this bug is to rework our infrastructure so that
the PTS is the information forwarder for everybody including the
maintainer. This needs to be done some day... but I haven't had the
motivation to take up that challenge yet.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



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

Bug#481477: Same with other packages

[Raphael Hertzog]

Hello,

On Fri, 16 May 2008, Michael Meskes wrote:
> It seems as if the scripts are not able to access the bug tracking
> system anymore (key changes?). There are quite a lot of bugs not
> correctly listed.

No, it's just that the file /org/bugs.debian.org/spool/index.db.realtime
on merkel is no more updated since a few days. Probably a consequence from
some disabled SSH push.

$ ls -al /org/bugs.debian.org/spool/index.db.realtime 
-rw-rw-r-- 1 debbugs debbugs 6553884 2008-05-13 05:51 
/org/bugs.debian.org/spool/index.db.realtime

Can someone from the BTS team fix this please?

(Please close the bug once you fixed it, thanks)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



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

Bug#482102: qa.debian.org: intelligent listing of debian/patches, git/quilt v3 format packages, etc

[Raphael Hertzog]

On Tue, 20 May 2008, sean finney wrote:
> my proposal is that the current "patches" section on a source package's
> qa package is modified so that the following information is somehow
> provided, where appropriate (depending on structure/format of source
> package naturally).
> 
> - - entire "debian patch"
> - - individual quilt/dpatch patches
> - - individual patches from v3 (quilt) format packages
> - - feature-branch patches for v3 (git) format packages, if possible
>   (would require more thinking through and i do not intend to do this 
> initially)
> 
> additionally, for each patch, when possible provide the following
> information:
> 
> - - which version of the package introduced it
> - - any notes at the top of the patch
> - - any relevant vcs metadata
> - - any relevant bts metadata (could be found using heuristics in the
>   previous items)
> - - html markup and standard format versions of each patch for download/review

It really looks like the patches.debian.org discussed on -devel. ;-)

I would suggest you to design it somewhat independently from the PTS and
only plan the PTS to point to it. I don't think that the PTS should be a
source of information, but rather a "portal".

It could possibly be "mole-based" so that it can automatically process any
new source package that gets uploaded to Debian.
http://qa.debian.org/cgi-bin/mole/doc
(The table "devpackages-src" would be your "TodoSource")

Various other considerations that I'd like to add:
- make it cross-distro from the beginning so that it can contain patches
  from multiple distributions (ie each patch is associated with one or
  more distros)
- have a generic way to upload patches to this system so that each
  distribution can extract their patches in the way that they want
  (rsync over ssh + ssh keys is what mole uses, IMO it would fit the bill
  here too, you just have to define the format of what gets uploaded)
- the stuff that extracts Debian patches uploads the required data to the
  system above

In the long term, I would also like a more interactive web portal around
this so that people can comment on patches, etc.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



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

Bug#482102: qa.debian.org: intelligent listing of debian/patches, git/quilt v3 format packages, etc

[Raphael Hertzog]

On Wed, 21 May 2008, sean finney wrote:
> > Various other considerations that I'd like to add:
> > - make it cross-distro from the beginning so that it can contain patches
> >   from multiple distributions (ie each patch is associated with one or
> >   more distros)
> 
> interesting.  i don't see any reason why it couldn't be cross distro, but 
> think i will start small and just try to leave room for expansion later.

Sure, just add the required field now but always put Debian in it. :)

> > - have a generic way to upload patches to this system so that each
> >   distribution can extract their patches in the way that they want
> >   (rsync over ssh + ssh keys is what mole uses, IMO it would fit the bill
> >   here too, you just have to define the format of what gets uploaded)
> 
> > - the stuff that extracts Debian patches uploads the required data to the
> >   system above
> 
> i'm not sure what you mean by "uploading".

Well, you'll have a web page to display the patches and the information,
and you'll have some script that extract the patches and the
meta-information.

Uploading is the process used by the scripts to make patches available on
the web interface. It makes sense to decouple both parts as the extraction
scripts might run on several machines (one for each distro for instance).

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



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

on mass bug reassigning

[Raphael Geissert]

Hi all,

This will be a short message because I have to leave, but wanted to
write this before anyone else "MBR's".
To make things easier I'll use the php4 and php5 packages as an example.

As almost everyone knows, php4 is already gone in unstable and
testing, being replaced by php5. Continuing with the current mass bug
closing "momentum" some people have started to mass bug reassign bugs
in php4 to php5, and one could say it is all right, although it is
*not*. When using the reassign command, all the package versions
information is lost, which makes it a little bit hard to organise and
to use the 'dist' BTS parameter, which is often used to just display
the bugs affecting unstable.

So I'd be delighted if a procedure is written to prevent this kind of
information lose, and to decide _when_ to MBR, or even try to contact
the package maintainers before doing it.


Sincerely,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: on mass bug reassigning

[Raphael Geissert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


After re-reading what I wrote last night I noticed it was probably not the
best way to express my POV, so I'd like to apologise.

To clarify:
 * I have nothing against cleaning up/reassigning bugs, it's just that some
things have to be prevented.
 * It is nothing personal, I just used a real situation which I am aware of.

I currently don't have enough time to write a script that gathers the
versions information from the origin package to use when MBR. But here is
what I believe needs to be done:

 * Encourage package maintainers to keep the old changelog around (e.g.
php5's changelog include php4's changelog). So the BTS knows about old
package versions
 * Write a script that gathers the versions not/affecting a given bug, and
generates the appropriate reassigning bug (in the form of "reassign 
package version", or if more than one affected version: "reassign 
package \n found  version ...").
  * Reach a concensus on whether maintainers should be contacted before MBR
(waiting a specific number of days for their reply before going ahead), or
not.

Any other ideas?

Cheers,
- -- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIObI0Yy49rUbZzloRAnGMAJ9vEtgCv8RX+vFLNATrJVIu2v5GjACcCLCb
iPnS44grOqzl94NWo1sGBOY=
=+Svd
-END PGP SIGNATURE-


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

Re: on mass bug reassigning

[Raphael Geissert]

Luk Claes wrote:

> Raphael Geissert wrote:
> 
>> I currently don't have enough time to write a script that gathers the
>> versions information from the origin package to use when MBR. But here is
>> what I believe needs to be done:
>> 
>>  * Encourage package maintainers to keep the old changelog around (e.g.
>> php5's changelog include php4's changelog). So the BTS knows about old
>> package versions
> 
> This is not practical for packages that are uploaded next to eachother
> and where one is dropped. Including a very long changelog is also not
> practical...

In case of php5, the maintainers at that moment took the php4 packaging and
based the php5 packaging on it. Newer changelog entries are not included in
php5's, for practical reasons.

But now that I think about it, maybe the BTS could detect different source
package names in debian/changelog, and if a package with that given name is
also in the archive, grab its versions for the 'new' package. And if
the 'old' package(s) are no longer known to be in the archive, display
their bugs together with the ones filed against the 'new' package.

That sounds more reasonable IMHO.

> 
>>  * Write a script that gathers the versions not/affecting a given bug,
>>  and
>> generates the appropriate reassigning bug (in the form of "reassign 
>> package version", or if more than one affected version: "reassign 
>> package \n found  version ...").
> 
> What's wrong with the assumption that all versions are affected if no
> versioning information is known?

That when there are many bug reports it clutters the page and you may
accidentally not notice one. Same applies when you want to prepare an
upload for s-p-u fixing important bugs only relevant to stable.

And going over every bug report to see the versions the BTS used to know
about is just impractical and a waste of time, don't you agree? :)

> 
>>   * Reach a concensus on whether maintainers should be contacted before
>>   MBR
>> (waiting a specific number of days for their reply before going ahead),
>> or not.
> 
> I think the best scenario would be that the maintainers reassign and
> close the bugs themselves before needing to contact them.

Of course, but it also depends on the amount of bug reports, the amount of
time required for checking every report, replying, reassigning, forwarding,
checking status at upstream, and so on. One may not notice the progress if
only a couple of bugs are handled every week or so.

> Even if they 
> didn't do it themselves up to the point of decision to contact them I
> think it's best to inform them about the bug triage and give them some
> time to do it themselves as they should know the best what the status of
> the bugs is.

Which is more or less what I was suggesting :)

> 
> Cheers
> 
> Luk

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Bug#483179: PTS: please link to Ubuntu Launchpad bugs page

[Raphael Hertzog]

On Wed, 28 May 2008, Joerg Jaspert wrote:
> On 11399 March 1977, Sandro Tosi wrote:
> 
> >> *I* wouldnt want that, for the simple reason that its an overview about
> >> your package in Debian, not "Debian + any possible derivative where
> >> people would like a link to".
> > Ok, but then why on the PTS I can see the patches applied in Ubuntu? :)
> 
> Maybe because they aren't hidden in some non-free crap software?

This is _ridiculous_ (as is the whole subthread that you started with
Alexander Wirt). 

Should we also drop links pointing to free sofware projects hosted on
sourceforge.net because sourceforge is no more a free software ?

(No need to answer that question)

I expected better from you and Alexander, you have surely already read
several times the reasons that explain how Ubuntu is behaving and the
direction in which they are working.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



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

Bug#484873: packages.qa.debian.org: should it still list oldstable?

[Raphael Hertzog]

Hi,

On Sat, 07 Jun 2008, Christian Perrier wrote:
> As of now, oldstable is no longer supported (security-wise).
> 
> I wonder whether it should still be listed on p.q.d.o pages in such
> situations, which might be misleading to out users.

The PTS is mostly static and it's painful to make stuff appear and
disappear based on a criteria that can't be checked programmatically.

Furthermore I do check the version of packages in oldstable even when
oldstable is no more supported for example to decide if I can drop the
version check in a build-dependency (if it's satisfied in old stable I
remove it, otherwise I keep it).

So my vote goes to keep it. If you solve the problem of detecting if
oldstable is supported or not, we can eventually put it in another color
or put a title attribute over it to mark it's no more supported.

> (side comment: I think that the drop of support for oldstable has not been
> announced widely enough)

My side comment would be that it would be better if we supported oldstable
until stable+1 is released (at least for some subset of the packages).

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



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