Bug#511303: not that easy to fix
[ CCing debian-dak. ]
Hi,
On Sat, 2009-01-10 at 15:52:47 +0100, Jan Dittberner wrote:
> data/ddpo/extract_incoming.pl extracts it's data from
> http://ftp-master.debian.org/new.822 which contains the following
> entry for xlwt:
>
> Source: xlwt
> Version: 0.7.0-2 0.7.0-1
> Architectures: source, all
> Age: 2 days
> Last-Modified: 1231361226
> Queue: new
> Maintainer: Jan Dittberner
> Changed-By: Jan Dittberner
> Sponsored-By: s...@debian.org
> Distribution: unstable
> Fingerprint: EB1F4A7B02539A1A56174C3FF426E1B2BE9BF8DA
> Changes-File: xlwt_0.7.0-1_amd64.changes
>
> it uses
>
> next unless my $source = $reader->get("Source"); chomp $source;
> next unless my $version = $reader->get("Version"); chomp $version;
>
> in lines 143-144 to parse the the Source and Version fields, resulting
> in "xlwt" as source and "0.7.0-2 0.7.0-1" as version string.
>
> Later (lines 167-172) the URL is built:
>
> } elsif ($queue =~ /^(new|byhand)$/) {
>$db{"n${d}:$source"} = "$queue: $version";
>$db{"n${d}-title:$source"} = mouseover_date($date, $changedby, $uploader);
>my $url = "http://ftp-master.debian.org/new/"; . uri_escape
> ("${source}_$version.html");
>$db{"n${d}-url:$source"} = $url;
> }
>
> only one URL is supported here. If I understand it correctly the
> stored data is used in developer.wml to produce the output of the DDPO
> page.
>
> To fix this issue we have to (a) change the parsing of the new queue
> to store multiple NEW URLs or to take only the latest one and (b) fix
> the output of the URLs to support multiple NEW URLs (or leave it as it
> is if only the latest version is used).
I think it would be better to fix the new.822 file generator to
produce one instance per .changes file so to not overload the meaning
of the Version field with several values, or at least show only one
instance for the latest version and its matching file in Changes-File.
It would also be nice to change the Architectures field to Architecture,
and split its values with space instead of comma+space, to match the
standard field.
regards,
guillem
--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: For those who care about bts-link: call for adoption
Sandro Tosi wrote: > On Fri, Jan 9, 2009 at 10:52, Don Armstrong wrote: >> Actually, if you're interested in maintaining it, I'd be happy to see >> it deployed on the master BTS server. I suppose it can live on merkel >> for the time being until you're ready to migrate it, but having it >> under the debbugs umbrella would be good. [Not that I'd be actually >> touching it much, because my python-fu[1] is almost non-existant.] > > For me makes little difference: I see it more as a QA "thingy" but I > have no problem in deploying on other servers. > > Other opinions? I can understand Don's request as it's the BTS link, so having it in the BTS server may make more sense. But I don't care as long as you run it ;) Thanks for taking care of this! Cheers, Emilio -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511303: not that easy to fix
>> To fix this issue we have to (a) change the parsing of the new queue >> to store multiple NEW URLs or to take only the latest one and (b) fix >> the output of the URLs to support multiple NEW URLs (or leave it as it >> is if only the latest version is used). > I think it would be better to fix the new.822 file generator to > produce one instance per .changes file so to not overload the meaning > of the Version field with several values, or at least show only one > instance for the latest version and its matching file in Changes-File. > It would also be nice to change the Architectures field to Architecture, > and split its values with space instead of comma+space, to match the > standard field. I personally do *not* care how this file looks. Do coordinate changes with those people that use it, which is the QA group and Lamby for the BTS bot. Whatever fits them is what can be done. Well, and whatever fits into the code. It is dak/queue_report.py in which you want to look. I will happily merge patches (git trees preferred :) ) when the above is true, ie. the readers of the file all agreed on one format that fits them. -- bye, Joerg asking an engineer at hp for part numbers is like asking Ganneff for the right mixture of fuel for a 747 - i might happen to know (like if i'd just ordered one) or might know someone who knows, but its a crapshoot :) ) -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511303: not that easy to fix
Joerg Jaspert wrote: > > I think it would be better to fix the new.822 file generator to > > produce one instance per .changes file so to not overload the meaning > > of the Version field If this makes stuff a lot easier for you, then I'm happy to go with it. I have a slight reservation in that this would break the "number of stanzas" == "size of NEW queue" invariant that currently holds, but I can always work around this. > > It would also be nice to change the Architectures field to Architecture, > > and split its values with space instead of comma+space, to match the > > standard field. > > I personally do *not* care how this file looks. Do coordinate changes > with those people that use it, which is the QA group and Lamby for the > BTS bot. ACK the Architecture change, but I don't consume that. In general, the bot's code is pretty flexible and I can pretty much read anything easily, just need to be poked when the format actually changes. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org `- signature.asc Description: PGP signature
qe fotot zemer
Pershendetje !!! Nese doni Te dergoni SMS 100% FALAS Te njoftoheni me miq te rinje Te shkarkoni muziket me te reja Te shkarkoni DVD-te me te reja Atehere klikoni ne dhe hyni ne portalin me te madh rinor WWW.llapi-zone.co.cc kliko me poshte per te shkuar tek LLAPI-ZONE http://www.llapi-zone.co.cc -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
