Bug#552576: live-installer: no-standards-version-field
Package: live-installer Version: 13 Severity: serious User: lintian-ma...@debian.org Usertags: no-standards-version-field The source package does not have a Standards-Version control field. Please update your package to latest Policy and set this control field appropriately. Refer to Debian Policy Manual section 5.6.11 (Standards-Version) for details. ,[ 4.1. Standards conformance ] | Source packages should specify the most recent version number of this | policy document with which your package complied when it was last | updated. | | This information may be used to file bug reports automatically if your | package becomes too much out of date. | | The version is specified in the `Standards-Version' control field. | The format of the `Standards-Version' field is described in Section | 5.6.11, ``Standards-Version''. | | You should regularly, and especially if your package has become out of | date, check for the newest Policy Manual available and update your | package, if necessary. When your package complies with the new | standards you should update the `Standards-Version' source package | field and release it. ` ,[ 5.6.11. `Standards-Version' ] | The most recent version of the standards (the policy manual and | associated texts) with which the package complies. ` A missing standards version is a violation of a Should directive in policy, and normally would be filed as important. Filed as serious, since a package with these files will currently get this package rejected. See http://lists.debian.org/debian-devel-announce/2009/10/msg4.html for details. This means the package has been deemed too buggy to be in Debian. manoj -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.4-anzu-2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552576: live-installer: no-standards-version-field
severity 552576 important thanks On Sun, Nov 01, 2009 at 01:15:01AM -0600, Manoj Srivastava wrote: A missing standards version is a violation of a Should directive in policy, and normally would be filed as important. Filed as serious, since a package with these files will currently get this package rejected. See http://lists.debian.org/debian-devel-announce/2009/10/msg4.html for details. This means the package has been deemed too buggy to be in Debian. It has been deemed too buggy to be in Debian by the ftp team, who don't have the authority to make such determinations on their own. Downgrading this bug; I have requested that the ftp team remove these overreaching archive checks that have no basis in Policy's requirements, and intend to follow up with a GR if necessary. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Processed: Re: Bug#552576: live-installer: no-standards-version-field
Processing commands for cont...@bugs.debian.org: severity 552576 important Bug #552576 [live-installer] live-installer: should have a Standards-Version field Severity set to 'important' from 'serious' thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#552576: live-installer: no-standards-version-field
Processing commands for cont...@bugs.debian.org: # was fixed before bug was filled; # so wasn't marked pending automatically tag 552576 pending Bug #552576 [live-installer] live-installer: should have a Standards-Version field Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552576: live-installer: no-standards-version-field
# was fixed before bug was filled; # so wasn't marked pending automatically tag 552576 pending thanks gosh.. why do you guys waste so much time for something that has already been fixed in svn anyway... (even before the first bug was filled) nevermind, i guess i don't have to understand that. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
The clean out spam from archives effort is lagging
As one can see on http://wiki.debian.org/DebianInstaller/SpamClean, this effort initiated by Frans back in April is lagging. Last 3 months of debian-boot archives have been reviewed by 3 persons only (Frans, Giacomo Catenazzi and me) and are thus missing at least two more people to review them so that spams are nominated...and can later be processed in the cleaning second step. Old archives are also missing reviews, particularly a few from 2005 and nearly all from 2004, not to mention older archives. Please take some time to do this work. This is not that time consuming: one month can be reviewed in about 10-15 minuteseven less when you're used to methods for spotting spams. -- signature.asc Description: Digital signature
Re: Bug#552576: live-installer: no-standards-version-field
On Sun, Nov 01 2009, Steve Langasek wrote: severity 552576 important thanks On Sun, Nov 01, 2009 at 01:15:01AM -0600, Manoj Srivastava wrote: A missing standards version is a violation of a Should directive in policy, and normally would be filed as important. Filed as serious, since a package with these files will currently get this package rejected. See http://lists.debian.org/debian-devel-announce/2009/10/msg4.html for details. This means the package has been deemed too buggy to be in Debian. It has been deemed too buggy to be in Debian by the ftp team, who don't have the authority to make such determinations on their own. Doesn't the ftp team have authority over determining what goes into the archive? I would have thought so, given that they bear the (legal) brunt of any fallout from mistakes made there. Downgrading this bug; I have requested that the ftp team remove these overreaching archive checks that have no basis in Policy's requirements, and intend to follow up with a GR if necessary. I think this degrades the quality of implementation, and given that only three packages have this, it should be easy enough to fix. Less time would be spent fixing these issues than draging on a fight in a GR, and while I applaud rules lawyering as much as the next guy, I think it would be simpler, and better for Debian, to just get the frakking thing fixed. manoj -- Many people are unenthusiastic about their work. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#315937: installation-reports: wrong keyboard settings after first reboot after dvd/cd install
I may have a clue. After the 1st reboot, the keyboard is in qwerty whereas I submit my password in azerty during install... Very annoying, still in Lenny. The keyboard is in US in both gdm and Gnome. I suspect HAL to not have rules to follow the keyboard map used during installand use an US keyboard map by default.
[RFC] localechooser: template changes
The existing templates for the four main questions in localechooser all
have problems: they cause Lintian warnings and don't really help the
user with what he's doing.
Below a proposed patch to improve them. The patch also includes the changes
needed because of #552560 (locale selection incomplete).
Test images (i386) this time that use the new templates and include the
change for #552560 (use expert mode!) are available at:
http://people.debian.org/~fjp/tmp/d-i/madduck/
Cheers,
FJP
commit 330cff17ef17481bc98d8b80656f12984017e10a
Author: Frans Pop f...@debian.org
Date: Sun Nov 1 17:19:40 2009 +0100
Update templates
diff --git a/packages/localechooser/debian/localechooser.templates-in
b/packages/localechooser/debian/localechooser.templates-in
index c8203fb..75a8353 100644
--- a/packages/localechooser/debian/localechooser.templates-in
+++ b/packages/localechooser/debian/localechooser.templates-in
@@ -11,9 +11,8 @@ Template: debian-installer/locale
Type: select
Choices: ${LOCALELIST}
# :sl2:
-_Description: Choose a locale:
- Based on your language and country choices, the following locale
- parameters are supported.
+_Description: System locale:
+ Select the default locale for the installed system.
Template: debian-installer/fallbacklocale
Type: select
@@ -49,9 +48,9 @@ Choices-C: ${CODES}
Choices: ${NAMES_EN}
Choices-en.UTF-8: ${NAMES_BOTH}
Default: en
-Description: Choose a language:
- Please choose the language used for the installation process. This
- language will be the default language for the final system.
+Description: Language:
+ Choose the language to be used for the installation process. The selected
+ language will also be the default language for the installed system.
Template: localechooser/translation/none-yet
Type: note
@@ -141,16 +140,25 @@ Type: select
# :sl1:
__Choices: ${SHORTLIST}, other
# :sl1:
-_Description: Choose a country, territory or area:
- Based on your language, you are probably located in one of these countries
- or regions.
+_Description: Country, territory or area:
+ Select the country where you live. The selection will be used for example to
+ select a default locale and time zone.
+ .
+ Choose other if your country is not listed.
Template: localechooser/supported-locales
Type: multiselect
Choices: ${LOCALELIST}
# :sl2:
-_Description: Choose other locales to be supported:
- You may choose additional locales to be installed from this list.
+_Description: Additional locales:
+ A locale determines character encoding and contains information on e.g.
+ currency, date format and alphabetical sort order. Based on the selected
+ language and country, the default locale selected for the installed system
+ is '${LOCALE}'.
+ .
+ If you wish to use a different default or to also have other locales
available,
+ you may choose additional locales to be installed. If you are unsure it is
+ best to simply stick with the default.
# This template does not really belong in localechooser, but it is probably
# the best place for it. It is used to display the language currently being
diff --git a/packages/localechooser/mktemplates.continents
b/packages/localechooser/mktemplates.continents
index 4023f58..992b019 100755
--- a/packages/localechooser/mktemplates.continents
+++ b/packages/localechooser/mktemplates.continents
@@ -100,6 +100,9 @@ foreach my $region (@known_regions) {
print TOUT #flag:partial\n;
print TOUT __Choices: , join(, , @countries), \n;
print TOUT _Description: , gettext(Choose a country,
territory or area:), \n;
+ print TOUT , gettext(Select the country where you live. The
selection will be used for example to select a default locale and time zone.),
\n;
+ print TOUT .\n;
+ print TOUT , gettext(Choose \other\ if your country is
not listed.), \n;
print TOUT \n;
} else {
print STDERR I: skipping region $region: no associated
countries in $regionmap\n;
@@ -111,8 +114,8 @@ print TOUT Template: localechooser/continentlist\n;
print TOUT Type: select\n;
print TOUT #flag:partial\n;
print TOUT __Choices: , join(, , @regions), \n;
-print TOUT _Description: , gettext(Choose a continent or region:), \n;
-print TOUT , gettext(The continent or region in which the desired country
is located.), \n;
+print TOUT _Description: , gettext(Continent or region:), \n;
+print TOUT , gettext(Select the continent or region in which the country
where you live is located.), \n;
close(TOUT) || warn;
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FTBFS of netcfg on s390 after debhelper v7 conversion
On Wednesday 28 October 2009, Frans Pop wrote: I've just tried building netcfg on s390, but that fails with: dpkg-gencontrol: error: current host architecture 's390' does not appear in package's architecture list (i386 sparc alpha m68k arm armel armeb powerpc mips mipsel hppa ia64 amd64 lpia kfreebsd-i386 kfreebsd-amd64) dh_gencontrol: dpkg-gencontrol returned exit code 255 AFAICT the reason is that the binary netcfg is !s390 (while netcfg-static is arch any). Before the conversion to debhelper v7, we called most dh_command with the '-s' option. If I add an overrides in d/rules for dh_gencontrol *and* dh_builddeb to pass the -s option, netcfg builds correctly again. As there have not yet been any replies, I've committed this solution. I'm still unsure if it's the best solution. I wonder why this is needed? Shouldn't this just work? Is there a better solution than adding the overrides? Maybe 'dh -s $@', but I'd expect that will cause an error where we copy templates in override_dh_installdebconf... I also wonder if other converted packages could have the same issue. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548828: Same problem
I am using a Dell D630, nvidia graphics, and am having the same problem. I am using the oct 29 build.
Bug#552067: marked as done (Install process forgets the CD if left alone for long time)
Your message dated Mon, 2 Nov 2009 00:16:27 +0100 with message-id 200911020016.28413.elen...@planet.nl and subject line Re: Bug#552067: Install process forgets the CD if left alone for long time has caused the Debian Bug report #552067, regarding Install process forgets the CD if left alone for long time to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 552067: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552067 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: debian-installer Version: 20090123lenny4 Hello. I've been with Debian for many,many years. Now I am trying to install 5.03 on a number of computers using cd image http://cdimage.debian.org/debian-cd/5.0.3/i386/iso-cd/debian-503-i386-netinst.iso If install goes quickly, then it appears to be OK. However, if there is large file system is being created (e.g. took 1/2 hour to create encrypted one), or I just leave install unattended for some time, then install process forgets that CD is in the drive. Error message can be cannot figure out how to install base system or please insert the disk labeled - asking for the very same disk that is IN THE CDdrive at the moment. One more detail is that CDdrive is external, connected via USB. When I got those messages, I switched consoles and made sure that /cdrom/ is still readable and mounted properly. ---End Message--- ---BeginMessage--- On Sunday 25 October 2009, Frans Pop wrote: The most likely explanation looks to me that the system (temporarily?) loses connection with the device and has some problem identifying it again when you resume the installation and the connection to the device is reactivated. Closing as there has been no reply from submitter to the questions asked to further narrow down this issue. ---End Message---
Re: Bug#552576: live-installer: no-standards-version-field
On Sun, Nov 01, 2009 at 10:21:34AM -0600, Manoj Srivastava wrote: It has been deemed too buggy to be in Debian by the ftp team, who don't have the authority to make such determinations on their own. Doesn't the ftp team have authority over determining what goes into the archive? I would have thought so, given that they bear the (legal) brunt of any fallout from mistakes made there. This bug is not about a legal issue. Downgrading this bug; I have requested that the ftp team remove these overreaching archive checks that have no basis in Policy's requirements, and intend to follow up with a GR if necessary. I think this degrades the quality of implementation, and given that only three packages have this, it should be easy enough to fix. Less time would be spent fixing these issues than draging on a fight in a GR No, the damage to the project of letting the ftp team dictate Policy would be permanent. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#552576: live-installer: no-standards-version-field
On Sun, Nov 01 2009, Steve Langasek wrote: On Sun, Nov 01, 2009 at 10:21:34AM -0600, Manoj Srivastava wrote: It has been deemed too buggy to be in Debian by the ftp team, who don't have the authority to make such determinations on their own. Doesn't the ftp team have authority over determining what goes into the archive? I would have thought so, given that they bear the (legal) brunt of any fallout from mistakes made there. This bug is not about a legal issue. The bug is about the contents of the archive, and the ftp masters are a gating agency for that, as much as the release team is a gating agency for what gets into a release. Downgrading this bug; I have requested that the ftp team remove these overreaching archive checks that have no basis in Policy's requirements, and intend to follow up with a GR if necessary. I think this degrades the quality of implementation, and given that only three packages have this, it should be easy enough to fix. Less time would be spent fixing these issues than draging on a fight in a GR No, the damage to the project of letting the ftp team dictate Policy would be permanent. This is a reach; the ftp team has not changed policy. It just changed how I set the severity of the bug, this is no different than the release team taking a violation of a MUST directive and downgrading the bug to less than serious. I'll be happy to stop letting either team set the policy levels without going through the policy process, but each team is responsible for aspects of Debian: the ftp team manages the archive, and decides what goes in there, the release team decides what goes into a release just like the installer folk decide what is or is not part of the default install, If you think we should all stop letting each team influence the other teams, Debian shall be poorer for that. manoj -- It's hard to get ivory in Africa, but in Alabama the Tuscaloosa. Groucho Marx Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The clean out spam from archives effort is lagging
On Sun, Nov 1, 2009 at 10:02 AM, Christian Perrier bubu...@debian.org wrote: As one can see on http://wiki.debian.org/DebianInstaller/SpamClean, this effort initiated by Frans back in April is lagging. Last 3 months of debian-boot archives have been reviewed by 3 persons only (Frans, Giacomo Catenazzi and me) and are thus missing at least two more people to review them so that spams are nominated...and can later be processed in the cleaning second step. I did the most recent three months of 2009, but the density was pretty low. Old archives are also missing reviews, particularly a few from 2005 and nearly all from 2004, not to mention older archives. So I started at the beginning (part of 1998) and went to the end of 2002. If I have time this week I will look at 2003-2005. Please take some time to do this work. This is not that time consuming: one month can be reviewed in about 10-15 minuteseven less when you're used to methods for spotting spams. The work is pretty tedious and reviewing non-spam emails five time is extremely inefficient. Consider a solution that would allow one person to scan the archive to generate a list of spam targets. If the other four reviewers only had to review the listed spam candidates they would not have to waste their time reviewing non-spam. -- Lee -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#553678: locales: Language soup in Nowegian locale
Processing commands for cont...@bugs.debian.org: reassign 553678 localechooser Bug #553678 [locales] locales: Language soup in Nowegian locale Bug reassigned from package 'locales' to 'localechooser'. Bug No longer marked as found in versions glibc/2.7-18. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The clean out spam from archives effort is lagging
Quoting Lee Winter (lee.j.i.win...@gmail.com): I did the most recent three months of 2009, but the density was pretty low. I haven't checked the wiki and I'm not online right now, but please take care to register this in the page. Old archives are also missing reviews, particularly a few from 2005 and nearly all from 2004, not to mention older archives. So I started at the beginning (part of 1998) and went to the end of 2002. If I have time this week I will look at 2003-2005. Ditto. Please take some time to do this work. This is not that time consuming: one month can be reviewed in about 10-15 minuteseven less when you're used to methods for spotting spams. The work is pretty tedious and reviewing non-spam emails five time is extremely inefficient. Consider a solution that would allow one person to scan the archive to generate a list of spam targets. If the other four reviewers only had to review the listed spam candidates they would not have to waste their time reviewing non-spam. I'm sure the listmasters would welcome such improvements but, well, we already have a very good tool. Also, restricting the list to what the first person has identified would increase the risk of missing some spams. When I worked on the entire archive, I finally dropped the web interface and used an alternative method: - download the list archives as mailboxes - pass them through my CRM114 spam filter - open them in my MUA (mutt) - tag spam messages (being processed by CRM114, most spams are already identified by CRM114 markers) - bounce them to the spam report mail addresse (report-lists...@lists.debian.org) with the following key macro: macro index \eL breport-lists...@lists.debian.org\no\nq report as spam to Debian lists I found this much more efficient. Downloading list archives as mailboxes is only accessible to Debian developers but I can provide them to people who might need them. signature.asc Description: Digital signature
Re: [RFC] localechooser: template changes
Quoting Frans Pop (elen...@planet.nl):
The existing templates for the four main questions in localechooser all
have problems: they cause Lintian warnings and don't really help the
user with what he's doing.
Thanks for working on this. It was on my TODO list for a while as I
found quite strange to enfore some style improvements in many packages
through Smith reviews...and omit to correct thos I use in D-I..:)
--- a/packages/localechooser/debian/localechooser.templates-in
+++ b/packages/localechooser/debian/localechooser.templates-in
@@ -11,9 +11,8 @@ Template: debian-installer/locale
Type: select
Choices: ${LOCALELIST}
# :sl2:
-_Description: Choose a locale:
- Based on your language and country choices, the following locale
- parameters are supported.
+_Description: System locale:
+ Select the default locale for the installed system.
I'd just recommend Please select which is the style we generally
push in dle reviews (avoid imperative form).
Apart from that, fine by me.
Template: debian-installer/fallbacklocale
Type: select
@@ -49,9 +48,9 @@ Choices-C: ${CODES}
Choices: ${NAMES_EN}
Choices-en.UTF-8: ${NAMES_BOTH}
Default: en
-Description: Choose a language:
- Please choose the language used for the installation process. This
- language will be the default language for the final system.
+Description: Language:
+ Choose the language to be used for the installation process. The selected
+ language will also be the default language for the installed system.
Ditto
Template: localechooser/translation/none-yet
Type: note
@@ -141,16 +140,25 @@ Type: select
# :sl1:
__Choices: ${SHORTLIST}, other
# :sl1:
-_Description: Choose a country, territory or area:
- Based on your language, you are probably located in one of these countries
- or regions.
+_Description: Country, territory or area:
+ Select the country where you live. The selection will be used for example to
+ select a default locale and time zone.
+ .
+ Choose other if your country is not listed.
That one is more tricky. Using where you live implicitely assumes
that the user installing the system is the one owning the machine,
which is not well suited in all cases. Also, the user might be living
somewhere but installing the machine elsewhere. Of course, what
matters here is probably more the place where the machine is
living..:-)
The former template had the same problem of course.
Please select the country where the installed system is used. The
selection will set the default locale and time zone.
Choose other to get the full list of countries.
Template: localechooser/supported-locales
Type: multiselect
Choices: ${LOCALELIST}
# :sl2:
-_Description: Choose other locales to be supported:
- You may choose additional locales to be installed from this list.
+_Description: Additional locales:
+ A locale determines character encoding and contains information on e.g.
+ currency, date format and alphabetical sort order. Based on the selected
+ language and country, the default locale selected for the installed system
+ is '${LOCALE}'.
+ .
+ If you wish to use a different default or to also have other locales
available,
+ you may choose additional locales to be installed. If you are unsure it is
+ best to simply stick with the default.
After discussions in dle, we concluded (mostly others than me as I'm
of course polluted by Latin) that latin abbreviations such as e.g.
are not highly wished in English. such as would then be recommended.
Apart from that, everything is fine, except maybe the length of the
two paragrpahs, that takes a lot of spaces and leaves few romm for the
list on 80x25 systems.
--- a/packages/localechooser/mktemplates.continents
+++ b/packages/localechooser/mktemplates.continents
@@ -100,6 +100,9 @@ foreach my $region (@known_regions) {
print TOUT #flag:partial\n;
print TOUT __Choices: , join(, , @countries), \n;
print TOUT _Description: , gettext(Choose a country,
territory or area:), \n;
+ print TOUT , gettext(Select the country where you live. The
selection will be used for example to select a default locale and time
zone.), \n;
+ print TOUT .\n;
+ print TOUT , gettext(Choose \other\ if your country is
not listed.), \n;
print TOUT \n;
} else {
print STDERR I: skipping region $region: no associated
countries in $regionmap\n;
Of course, sams suggestions than those I made for the regular template.
@@ -111,8 +114,8 @@ print TOUT Template: localechooser/continentlist\n;
print TOUT Type: select\n;
print TOUT #flag:partial\n;
print TOUT __Choices: , join(, , @regions), \n;
-print TOUT _Description: , gettext(Choose a continent or region:), \n;
-print TOUT , gettext(The continent or region in which the desired
country is located.), \n;
+print TOUT _Description: , gettext(Continent or region:), \n;
+print
Re: The clean out spam from archives effort is lagging
On Mon, Nov 2, 2009 at 1:01 AM, Christian Perrier bubu...@debian.org wrote: Quoting Lee Winter (lee.j.i.win...@gmail.com): I did the most recent three months of 2009, but the density was pretty low. I haven't checked the wiki and I'm not online right now, but please take care to register this in the page. I am a little hesitant to edit the page because I don't understand the process and found no doc or howto. Old archives are also missing reviews, particularly a few from 2005 and nearly all from 2004, not to mention older archives. So I started at the beginning (part of 1998) and went to the end of 2002. If I have time this week I will look at 2003-2005. Ditto. Please take some time to do this work. This is not that time consuming: one month can be reviewed in about 10-15 minuteseven less when you're used to methods for spotting spams. The work is pretty tedious and reviewing non-spam emails five time is extremely inefficient. Consider a solution that would allow one person to scan the archive to generate a list of spam targets. If the other four reviewers only had to review the listed spam candidates they would not have to waste their time reviewing non-spam. I'm sure the listmasters would welcome such improvements but, well, we already have a very good tool. Also, restricting the list to what the first person has identified would increase the risk of missing some spams. When I worked on the entire archive, I finally dropped the web interface and used an alternative method: - download the list archives as mailboxes - pass them through my CRM114 spam filter - open them in my MUA (mutt) - tag spam messages (being processed by CRM114, most spams are already identified by CRM114 markers) - bounce them to the spam report mail addresse (report-lists...@lists.debian.org) with the following key macro: macro index \eL breport-lists...@lists.debian.org\no\nq report as spam to Debian lists I found this much more efficient. Sounds like the beginning/foundation of an automation script. If the candidates can be found mechanically, then there is a potential tradeoff available. We have 11 years = 132 months; times 5 reviewers = 660 reviewer-months. At 10-15 min each that is 110-165 man-hours. That's a lot of manual effort. Just how important are the last few messages that would make it through a (purposfully loose) mechanical filter? If the whole mess could be 98% cleaned up with say, 5 man-hours then it would be a tremendous efficiency improvement. Downloading list archives as mailboxes is only accessible to Debian developers but I can provide them to people who might need them. In the '80s I spent a lot of time doing natural language processing software, so I may be more tuned up than the typical reviewer. But I find it more efficient to review the author/subject/thread indicies and inspect message content only to confirm the presence of spam in a suspect message. So offline access to the archive would not help me. -- Lee -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
