Debian Policy "10.7.4 Sharing configuration files" question

[Alexander GQ Gerasiov]

Hello there.

I found, that package rtpg-www modifies /etc/hosts on installation/purge

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608451

I thing this violate 10.7.4

"The maintainer scripts must not alter a conffile of any package,
including the one the scripts belong to."


But maintainer disagrees with me arguing that preinst asks user, and
that's user who modify /etc/hosts (using preinst, eah).

Please comment this issue. Here or in #608451


-- 
Best regards,
 Alexander GQ Gerasiov

 Contacts:
 e-mail:g...@cs.msu.su Jabber:  g...@jabber.ru
 Homepage:  http://gq.net.ru ICQ: 7272757
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2011011557.2f8d8...@desktopvm.lvknet

Re: Debian Policy "10.7.4 Sharing configuration files" question

[Russ Allbery]

Alexander GQ Gerasiov  writes:

> I found, that package rtpg-www modifies /etc/hosts on installation/purge

> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608451

> I thing this violate 10.7.4

> "The maintainer scripts must not alter a conffile of any package,
> including the one the scripts belong to."

> But maintainer disagrees with me arguing that preinst asks user, and
> that's user who modify /etc/hosts (using preinst, eah).

Well, that part of 10.7.4 doesn't apply in this case because /etc/hosts is
not a conffile.

However, it remains the case that two different packages may not manage
the same configuration file.  This is particularly important for
/etc/hosts, which is intentionally left entirely under the control of the
local system administrator after initial installation and is particularly
sensitive in that regard.

Policy lays out what has to be done if a configuration file is meant to be
shared, but I don't think it's at all useful to consider /etc/hosts to be
a shared configuration file.  I think a package that requires manipulating
/etc/hosts is doing something fundamentally wrong, and needs to be fixed
to not have that requirement.  Host naming and resolution is about as
firmly the exclusive business of the local system administrator as
anything about a system's configuration can be, and should not be messed
with by packages.

For reference for others reading this, the postinst of the relevant
package follows.  Note that it adds an unqualified hostname, potentially
shadowing a system in the local domain, if the user agrees to update
/etc/hosts.  The debconf question is priority: high and defaults to true.
It looks like the purpose of the alias is because the package configures
an Apache virtual host named rtpg, which I think is also questionable and,
IIRC, contrary to the draft webapp policy.

I get the impression that the intent of this package is to set up a local
web interface as essentially a cheap form of GUI to control a local daemon
on the system, which is an interesting problem for which Debian does not
currently have good infrastructure support.

#!/bin/sh

set -e
umask 022
. /usr/share/debconf/confmodule

db_get rtpg-www/change_host

update_hosts()
{
echo 127.0.0.1 rtpg-scgi.localhost rtpg >> /etc/hosts
}

if test "$RET" = true; then
if test -f /etc/hosts; then
if ! grep -q rtpg-scgi /etc/hosts; then
update_hosts
fi
else
update_hosts
fi
fi

#DEBHELPER#

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hbdfg74k@windlord.stanford.edu

Re: Debian Policy "10.7.4 Sharing configuration files" question

[Julien Cristau]

On Tue, Jan 11, 2011 at 11:15:57 +0300, Alexander GQ Gerasiov wrote:

> Hello there.
> 
> I found, that package rtpg-www modifies /etc/hosts on installation/purge
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608451
> 
> I thing this violate 10.7.4
> 
> "The maintainer scripts must not alter a conffile of any package,
> including the one the scripts belong to."
> 
/etc/hosts is not a conffile, so it doesn't violate that part.

However, the squeeze RC policy says [1]

Packages must not modify other packages' configuration files
except by an agreed upon APIs (eg, a /usr/sbin/update-foo command).

which might well apply.

[1] http://release.debian.org/squeeze/rc_policy.txt

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Debian Policy "10.7.4 Sharing configuration files" question

[Bjørn Mork]

Russ Allbery  writes:

> For reference for others reading this, the postinst of the relevant
> package follows.  Note that it adds an unqualified hostname, potentially
> shadowing a system in the local domain, if the user agrees to update
> /etc/hosts.  The debconf question is priority: high and defaults to true.
> It looks like the purpose of the alias is because the package configures
> an Apache virtual host named rtpg, which I think is also questionable and,
> IIRC, contrary to the draft webapp policy.
>
> I get the impression that the intent of this package is to set up a local
> web interface as essentially a cheap form of GUI to control a local daemon
> on the system, which is an interesting problem for which Debian does not
> currently have good infrastructure support.

well, you could always add a name pointing to 127.0.0.1 in some DNS zone
you control, and then use this name for the package virtual host.  No
need to edit the local /etc/hosts then as long as the system can access
the DNS (which of course may be a false assumption, but at least not
violating any policy requirements).


Bjørn


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vyrx0vk@nemi.mork.no

Re: Debian Policy "10.7.4 Sharing configuration files" question

[Dmitry E. Oboukhov]

AGG> But maintainer disagrees with me arguing that preinst asks user, and
AGG> that's user who modify /etc/hosts (using preinst, eah).

This action is done only if user afrees.
There are a lot packages which do this.

Policy says:

The maintainer scripts must not alter a conffile of *any* package,
including the one the scripts belong to.


any == any

so for example samba must have RC by Alexander's logic, because samba
asks user to change its config.
exim must have RC, too, etc.
And all the other packages which have wizards inside maintainer
scripts.

-- 
... mpd playing: WASP - My Tortured Eyes

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: Debian Policy "10.7.4 Sharing configuration files" question

[Dmitry E. Oboukhov]

TAGG> so for example samba 

smb.conf isn't conffile, too,

sorry for mistake

-- 
... mpd playing: WASP - The Horror

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

debconf translations broken in multiple packages

[Julien Cristau]

Hi,

recent versions of mutt convert attachments to their declared charset
when saving them to disk (bug#537061).  In particular, this means that a
file with non-ascii characters, but wrongly sent with charset=us-ascii,
would be converted to ascii on saving, replacing all non-ascii
characters with question marks.

This has interesting consequences, like bug#609624
(http://ikibiki.org/~kibi/greek.png).

I ran a quick grep in the lintian lab for all debian/po/*.po files,
which are the most obvious victims of this bug for debian packages.

Affected source package / version / po file are:
astk 1.8.3-2 sv.po
bandwidthd 2.0.1+cvs20090917-4 da.po
bind9 1:9.7.2.dfsg.P3-1 da.po
bindgraph 0.2a-5.1 fr.po
boxbackup 0.11~rc8~r2714-1 da.po
bugzilla 3.6.3.0-2 nl.po
chemical-structures 2.1.dfsg.1-10 sv.po
clamav 0.96.5+dfsg-1 it.po
console-data 2:1.10-9 he.po
console-setup 1.67 el.po
console-setup 1.67 fa.po
console-setup 1.67 he.po
console-setup 1.67 pa.po
console-setup 1.67 zh_TW.po
ddclient 3.8.0-11.2 ja.po
debconf 1.5.37 he.po
elmerfem 5.5.0.svn.4716.dfsg-5 cs.po
halevt 0.1.6.2-1.3 pt_BR.po
iog 1.03-3.4 de.po
jspwiki 2.8.0-4 da.po
kde4libs 4:4.4.5-2 cs.po
lire 2:2.1-1.1 nl.po
masqmail 0.2.27-1.1 cs.po
media-retriever 1.23 ta.po
mini-buildd 0.8.16 da.po
moodle 1.9.9.dfsg2-2 sv.po
nbd 1:2.9.16-7 de.po
nvidia-cg-toolkit 2.1.0017.deb1+nmu2 da.po
ocsinventory-agent 2:1.1.1-2.2 da.po
poker-network 1.7.7-3.1 da.po
postgrey 1.32-6 cs.po
rinputd 1.0.4-1 da.po
setserial 2.17-45.2 da.po
slbackup-php 0.3-2.1 da.po
typo3-dummy 4.3.0-4 sv.po
tzdata 2010o-1 pt_BR.po
update-inetd 4.38 da.po
vpb-driver 4.2.52-1 cs.po
xmail 1.27-1 da.po

dd-list gives:

"Adam C. Powell, IV" 
   astk (U)
   elmerfem (U)

Loic Dachary (OuoU) 
   poker-network

Clint Adams 
   tzdata (U)

Joost van Baal 
   lire
   lire (U)

Armin Berres 
   kde4libs (U)

Raphael Bossek 
   bugzilla

Gonéri Le Bouder 
   ocsinventory-agent (U)

Fathi Boudra 
   kde4libs (U)

Pierre Chifflier 
   ocsinventory-agent

ClamAV Team 
   clamav

Jon Daley 
   postgrey (U)

Debconf Developers 
   debconf

Debian Install System Team 
   console-setup
   media-retriever

Debian Java Maintainers 
   jspwiki

Debian Qt/KDE Maintainers 
   kde4libs

Debian Science Maintainers 
   elmerfem

Debian Science Team 
   astk

Debian Webapps Team 
   bugzilla (U)

Chase Douglas 
   rinputd

Bdale Garbee 
   bind9 (U)

Jonas Genannt 
   setserial

GNU Libc Maintainers 
   tzdata

Stephen Gran 
   clamav (U)

Federico Di Gregorio 
   nvidia-cg-toolkit

Andreas Henriksson 
   bandwidthd

Joey Hess 
   debconf (U)

Adnan Hodzic 
   jspwiki (U)

Aurelien Jarno 
   tzdata (U)

Finn-Arne Johansen 
   slbackup-php (U)

LaMont Jones 
   bind9

Georges Khaznadar 
   chemical-structures

George Kiagiadakis 
   kde4libs (U)

Torsten Landschoff 
   ddclient

Penny Leach 
   moodle (U)

Ron Lee 
   vpb-driver

Ola Lundqvist 
   setserial (U)

Alastair McKinstry 
   console-data

Andres Mejia 
   nvidia-cg-toolkit (U)

Michael Meskes 
   clamav (U)

Moodle Packaging Team 
   moodle

Tomasz Muras 
   moodle (U)

Morten Werner Olsen 
   slbackup-php (U)

Xavier Oswald 
   moodle (U)

Christian Perrier 
   console-data (U)
   console-setup (U)
   media-retriever (U)

Rémi Perrot 
   bugzilla (U)

Dan Poltawski 
   moodle (U)

Mark Purcell 
   iog

Antonio Radici 
   postgrey

Marco Rodrigues 
   ddclient (U)

markus schnalke 
   masqmail

Radu Spineanu 
   xmail

Alexis Sukrieh 
   bugzilla (U)

Stephan Sürken 
   mini-buildd

Marcos Talau 
   halevt

Jose Luis Tallon 
   bindgraph

Reinhard Tartler 
   boxbackup

Michael Tautschnig 
   clamav (U)

Christophe Trophime 
   astk (U)

Modestas Vainius 
   kde4libs (U)

Wouter Verhelst 
   nbd

Sune Vuorela 
   kde4libs (U)

Colin Watson 
   debconf (U)

Christian Welzel 
   typo3-dummy

Patrick Winnertz 
   slbackup-php

Serafeim Zanikolas 
   update-inetd

Anton Zinoviev 
   console-setup (U)

Anton Zinoviev 
   console-data (U)

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#609662: ITP: useragent-switcher -- extension to switch the user agent of Iceweasel/Firefox

[Fladischer Michael]

Package: wnpp
Severity: wishlist
Owner: Fladischer Michael 

* Package name: useragent-switcher
  Version : 0.7.3
  Upstream Author : Chris Pederick
* URL : http://chrispederick.com/work/user-agent-switcher/
* License : GPL
  Programming Lang: JavaScript, XUL
  Description : extension to switch the user agent of Iceweasel/Firefox

The User Agent Switcher extension adds a menu and a toolbar button to
switch the user agent of a Iceweasel/Firefox browser. It comes with a set
of predefined useragent strings from popular browsers and custom strings
can be added manually or imported through XML files.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2011010414.8205.28036.report...@fladi-1-pt.tunnel.tserv6.fra1.ipv6.he.net

Bug#609667: ITP: server-spy -- display brand of web servers in Firefox/Iceweasel

[Fladischer Michael]

Package: wnpp
Severity: wishlist
Owner: Fladischer Michael 

* Package name: server-spy
  Version : 0.2.1
  Upstream Author : Christophe Jacquet 
* URL : http://www.jacquet80.eu/mozilla/exts/ServerSpy/
* License : MPL-1.1 or GPL-2 or LGPL-2.1
  Programming Lang: JavaScript, XUL
  Description : display brand of web servers in Firefox/Iceweasel

Server Spy is a small Firefox/Iceweasel extension that displays the brand 
of web servers (e.g. Apache, IIS, etc.) in the right-hand side of the 
browser window's status bar. 
When a tab is selected, Server Spy shows the name of the server that has 
served up the corresponding page. 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2011013601.13374.82963.report...@fladi-1-pt.tunnel.tserv6.fra1.ipv6.he.net

Your pdf-presenter-console upload

[Adam D. Barratt]

Hi,

I was just having a look at the diff for your upload of
pdf-presenter-console 1.1.1+git.02dfcf-3, fixing #609608, to check if it
was suitable for unblocking for squeeze.

Firstly, thanks for fixing the bug so quickly.  Unfortunately, the upload
included a couple of other changes which aren't really appropriate at this
point of the freeze, specifically

+  * dh --parallel
+  * dh 8

One of the other changes means that the package is currently unbuildable
in unstable:

+  * bump valac build-depends to 0.9.7+ per README.rst (debian/control)

I've reported this as #609676.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/db7c866dcc3fe5258571e8afa2cfbbbf.squir...@adsl.funky-badger.org

Re: Your pdf-presenter-console upload

[Adam D. Barratt]

Gah, that was intended for debian-release, not debian-devel; please direct
follow-ups to -release.


On Tue, January 11, 2011 13:18, Adam D. Barratt wrote:
> Hi,
>
> I was just having a look at the diff for your upload of
> pdf-presenter-console 1.1.1+git.02dfcf-3, fixing #609608, to check if it
> was suitable for unblocking for squeeze.
>
> Firstly, thanks for fixing the bug so quickly.  Unfortunately, the upload
> included a couple of other changes which aren't really appropriate at this
> point of the freeze, specifically
>
> +  * dh --parallel
> +  * dh 8
>
> One of the other changes means that the package is currently unbuildable
> in unstable:
>
> +  * bump valac build-depends to 0.9.7+ per README.rst (debian/control)
>
> I've reported this as #609676.
>
> Regards,
>
> Adam
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/db7c866dcc3fe5258571e8afa2cfbbbf.squir...@adsl.funky-badger.org
>
>
>



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/52862eb945a9ea3a838e47639dc46b09.squir...@adsl.funky-badger.org

Re: Directories named after packages

[Osamu Aoki]

Hi,

On Tue, Jan 11, 2011 at 12:44:43AM +0100, Vincent Danjean wrote:
> On 10/01/2011 22:52, Frank Küster wrote:
> > Osamu Aoki  wrote:
> > 
> >> 3. Historic/Upstream choice (?): /usr/share/doc/texmf
> >>(Several TeX packages uses this.)
> > 
> > That's old-fashioned (or, well, obsolete).
> > 
> > I think (without looking at code or our sub-policy) this should be a
> > symlink to /usr/share/texmf/doc - and TeX packages should make sure
> > their documentation is findable both in /usr/share/doc/package (for
> > Debian Policy) and /usr/share/texmf/doc (for the TeX tools).  
> > 
> > If one package installs it as a directory, might files from other
> > packages also be installed there?
> 
> On my system:
> vdanj...@eyak:~$ ls -ld /usr/share/texmf/doc
> lrwxrwxrwx 1 root root 12 15 déc.   2009 /usr/share/texmf/doc -> ../doc/texmf

Same here.
$ ls -ld /usr/share/texmf/doc
lrwxrwxrwx 1 root root 12 Oct  2 11:03 /usr/share/texmf/doc -> ../doc/texmf
$ ls -ld /usr/share/doc/texmf
drwxr-xr-x 8 root root 4096 Oct  3 21:44 /usr/share/doc/texmf

> This symlink should have been created by a Debian package, probably
> tex-common:
> vdanj...@eyak:~$ dlocate /usr/share/texmf/doc
> tex-common: /usr/share/texmf/doc
> vdanj...@eyak:~$ dlocate /usr/share/doc/texmf
> [lots of packages]

$ dpkg -S /usr/share/doc/texmf
tex-common, luatex, feynmf, latex-xcolor, pgf, lmodern, preview-latex-style, 
latex-cjk-common, thailatex: /usr/share/doc/texmf
$ dpkg -S /usr/share/texmf/doc
tex-common: /usr/share/texmf/doc

So at least 8 tex packages using it and symlink is the other way.

Osamu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2011034304.ge8...@debian.org

Re: Debian Policy "10.7.4 Sharing configuration files" question

[Josselin Mouette]

Le mardi 11 janvier 2011 à 09:49 +0100, Julien Cristau a écrit : 
> > "The maintainer scripts must not alter a conffile of any package,
> > including the one the scripts belong to."
> > 
> /etc/hosts is not a conffile, so it doesn't violate that part.
> 
> However, the squeeze RC policy says [1]
> 
> Packages must not modify other packages' configuration files
> except by an agreed upon APIs (eg, a /usr/sbin/update-foo command).
> 
> which might well apply.

On a different, although similar issue, how would a change
of /etc/inittab in a maintainer script be regarded?
(I’m considering it for gdm3 in wheezy.)

-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1294762529.20609.11.ca...@meh

Re: Bug#609662: ITP: useragent-switcher -- extension to switch the user agent of Iceweasel/Firefox

[Jonathan Wiltshire]

On Tue, Jan 11, 2011 at 12:04:15PM +0100, Fladischer Michael wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Fladischer Michael 
> 
> * Package name: useragent-switcher

Please see the existing bug #522243 for this package, and also #569961
where Daniel Baumann seems to have prepared packages already (though for
some reason, they never reached the archive).


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2011070141.gn15...@lupin.powdarrmonkey.net

Re: Debian Policy "10.7.4 Sharing configuration files" question

[Bjørn Mork]

Josselin Mouette  writes:

> On a different, although similar issue, how would a change
> of /etc/inittab in a maintainer script be regarded?
> (I’m considering it for gdm3 in wheezy.)

If I wanted some random package maintainer to mess with my configuration
files, then I would probably just have used Fedora or whatever.


Bjørn


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874o9ftkpk@nemi.mork.no

Re: Debian Policy "10.7.4 Sharing configuration files" question

[Josselin Mouette]

Le mardi 11 janvier 2011 à 18:27 +0100, Bjørn Mork a écrit :
> If I wanted some random package maintainer to mess with my configuration
> files, then I would probably just have used Fedora or whatever.

I am not seeking the opinion of other random developers - I’m sure there
are people who won’t agree. I am asking whether this would be considered
a release-critical bug.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1294770603.2714.3.ca...@tomoe

Re: Debian Policy "10.7.4 Sharing configuration files" question

[Holger Levsen]

Hi Joss,

what change do you have in mind for /etc/inittab?


cheers,
Holger


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

Re: Debian Policy "10.7.4 Sharing configuration files" question

[Russ Allbery]

Josselin Mouette  writes:

> On a different, although similar issue, how would a change of
> /etc/inittab in a maintainer script be regarded?  (I’m considering it
> for gdm3 in wheezy.)

Policy indicates that if other packages should be able to modify
/etc/inittab, sysvinit should provide a script that does those
modifications.  Such a script should, at least on first glance, be
reasonably straightforward for the sorts of modifications I suspect people
will want to make (just adding or removing lines).  That would help the
runit situation as well.

When doing this sort of thing, though, please don't assume that there will
be an /etc/inittab or that sysvinit will necessarily be installed, since
we want to enable sysadmins to choose upstart or systemd or some other
init system in the future.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrmbclpt@windlord.stanford.edu

Re: debconf translations broken in multiple packages

[Christian PERRIER]

Quoting Julien Cristau (jcris...@debian.org):
> Hi,
> 
> recent versions of mutt convert attachments to their declared charset
> when saving them to disk (bug#537061).  In particular, this means that a
> file with non-ascii characters, but wrongly sent with charset=us-ascii,
> would be converted to ascii on saving, replacing all non-ascii
> characters with question marks.
> 
> This has interesting consequences, like bug#609624
> (http://ikibiki.org/~kibi/greek.png).
> 
> I ran a quick grep in the lintian lab for all debian/po/*.po files,
> which are the most obvious victims of this bug for debian packages.
> 
> Affected source package / version / po file are:

Many of these packages errors are direct or indirect consequences of
my l10n work during the lenny-squeeze release cycle.

Direct when the last uploaded version is an NMU of mine..

Indirect when a maintainer uploaded after I prodded him|her and sent a
patch

Would it be OK for the release team if packages fixing these encoding
errors are uploaded? I may try to at least correct some of them (those
I NMU'ed).




signature.asc
Description: Digital signature

Re: debconf translations broken in multiple packages

[Christian PERRIER]

Quoting Julien Cristau (jcris...@debian.org):

> bindgraph 0.2a-5.1 fr.po

> 
> Jose Luis Tallon 
>bindgraph

This one is a false positive: the French translation has a double
question mark, which is "only" a typo of the translator and therefore
doesn't deserve a fixed upload.

(guess who is the translator?)




signature.asc
Description: Digital signature

Re: Debian Policy "10.7.4 Sharing configuration files" question

[Bjørn Mork]

Josselin Mouette  writes:

> Le mardi 11 janvier 2011 à 18:27 +0100, Bjørn Mork a écrit :
>> If I wanted some random package maintainer to mess with my configuration
>> files, then I would probably just have used Fedora or whatever.
>
> I am not seeking the opinion of other random developers - I’m sure there
> are people who won’t agree. I am asking whether this would be considered
> a release-critical bug.

Then maybe you could describe what you mean by "change of /etc/inittab
in a maintainer script"?  

Doing sed -i /etc/inittab in a gdm3 maintainer script would definitely
be a RC bug.  Doing update-inittab in a gdm3 maintainer script, after
making sysvinit provide such a program, would not.

Maybe you could tell us which parts of Debian Policy 10.7.4 you find
unclear instead of asking the exact question 10.7.4 answers?


Bjørn


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwszs0i2@nemi.mork.no

Bug#609712: ITP: drupal6-mod-statistics-advanced -- statistics_advanced modules for Drupal 6

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 


* Package name: drupal6-mod-statistics-advanced
  Version : 2.3
  Upstream Author : Rodrigo Severo (http://drupal.org/user/496564)
* URL : http://drupal.org/project/statistics_advanced
* License : GPL
  Programming Lang: PHP
  Description : statistics_advanced modules for Drupal 6

 The Statistics Pro module creates statistics with aggregated data. The
 data is stored in a new table, which will be updated with a cron run.
 This statistic module provides statistical results of nodes, comments
 and users. Aggregated statistical data from nodes, comments and users
 are stored even if the access log table or the watchdog table have
 been deleted. For presenting the data the Views is used. When
 Statistics Pro detects the core Statistics module, the Charts and
 Graphs module or the Views Charts module it enables specific features
 dependent on each one of these modules like page visualization reports
 and graphs. This module is not a replacement for the core Statistics
 module but an useful enhancement.
 .
 Features
 .
  * Customizable views
  * Aggregated values for nodes, changed nodes, nodes of a term,
comments, new users, users online, page impressions, warnings and errors
  * Views 2 support
  * Drush support: implements the statspro command which provides
command line access the values above
  * Localization: English and Brazilian Portuguese
  * Advanced Help documentation
  * statistics about all watchdog levels.
  * "custom X days" period for extra flexibility.
  * support for path aggregated reports.
  * period definition support through URL for 'Overview' and 'Path
aggregated' reports.
  * drush support for path aggregated reports with configurable periods.
  * period support in the following drush statspro command options: alert,
comments, critical, emergency, error, nodes, path_aggregated, pi,
sessions, ualert, ucritical, uemergency, uerror, upi, users, uwarning
and warning.
  * exclusive Statistics Pro permissions.
  * core Statistics module optional.
  * graphs for overview page and path aggregated reports dependent on
optional Charts and Graphs module.
  * graphs for comment, log, node, pi and user reports.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110111200035.29362.60949.report...@a88-114-154-20.elisa-laajakaista.fi

Bug#609713: ITP: drupal6-mod-browscap -- browscap modules for Drupal 6

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 


* Package name: drupal6-mod-browscap
  Version : 1.1
  Upstream Author : Mike Ryan (http://drupal.org/user/4420)
* URL : http://drupal.org/project/browscap
* License : GPL
  Programming Lang: PHP
  Description : browscap modules for Drupal 6

The Browscap module provides a replacement for PHP's get_browser() 
function. get_browser() is difficult (or impossible) to configure for 
most users in shared webhosting situations, and requires attention to 
keep the underlying data (browscap.ini) up-to-date. This module avoids 
the configuration issue by storing the data in a database table, and 
the freshness issue by automatically retrieving the latest data on a 
weekly basis (if cron.php is run regularly).

Also, statistics on browsers visiting the site may be captured by 
enabling monitoring in the browscap settings.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110111201356.30697.85302.report...@a88-114-154-20.elisa-laajakaista.fi

Bug#609715: ITP: drupal6-mod-mobile-tools -- mobile_tools modules for Drupal 6

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 


* Package name: drupal6-mod-mobile-tools
  Version : 2.1
  Upstream Author : Tom Deryckere (http://drupal.org/user/25564)
* URL : http://drupal.org/project/mobile_tools
* License : GPL
  Programming Lang: PHP
  Description : mobile_tools modules for Drupal 6

 The Mobile Tools module provides Drupal developers with some tools to
 assist in making a site mobile.
 .
 This functionality of the module contains:
  * Detection of the user agent
  * Automatic redirection to the mobile site
  * Automatic theme switching, based on device type
  * Integration with Panels through a Ctools plugin and for Node Displays
  * Notification for mobile users that a mobile site is available when
they are looking at the desktop site
  * Adding a mobile context to the permission system
  * Change the number of nodes that will be displayed on the front page



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110111202308.31027.31933.report...@a88-114-154-20.elisa-laajakaista.fi

Bug#609719: ITP: repmgr -- PostgreSQL 9.0 replication manager

[Marco Nenciarini]

Package: wnpp
Severity: wishlist
Owner: Marco Nenciarini 

* Package name: repmgr
  Version : 1.0.0
  Upstream Author : 2ndQuadrant 
* URL : http://projects.2ndquadrant.com/repmgr
* License : GPL-3
  Programming Lang: C
  Description : PostgreSQL replication manager

Since version 9.0, PostgreSQL allow you to have replicated hot standby
servers which you can query and/or use for high availability.  While
the main components of the feature are included with PostgreSQL, the
user is expected to manage the high availability parts.  

repmgr allows you to monitor and manage your replicated PostgreSQL
databases as a single cluster.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110111210209.3177.27544.report...@combobulator.laptop

List of override disparities

[Luca Falavigna]

Policy § 2.5 [0] states packages must not depend on other packages with
lower priority values. In order to better adhere to it, FTP Team
recently implemented a new tool that generates a list of override
disparities[1] daily.

We export a yaml-formatted list, limited to the affected packages only,
with this group of attributes:
* package name
* maintainer
* priority
* dependencies with their overrides

Feel free to look at the list and eventually report a bug against
ftp.debian.org pseudo-package to ask for override adjustments or adjust
your package. Please adjust this template as your subject string to ease
the FTP Team's job:

 override: packagename:section/priority

Please keep in mind that override disparities are neither RC bugs to
flood squeeze with nor do they need a mass bug filing for all the
packages (or flooding ftp.debian.org with). Instead, simply adjust your
package when you agree that your package is wrong, or file a bug on
ftp.debian.org having us change the overrides for your package, when you
think our overrides are wrong.

[0] http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities
[1] http://ftp-master.debian.org/override-disparity.gz

-- 
  .''`.
 :  :' :   Luca Falavigna 
 `.  `'
   `-



signature.asc
Description: OpenPGP digital signature

Forwarding bugs upstream

[brian m. carlson]

I've noticed a trend lately that I am often asked to forward the bugs I
report to the Debian BTS upstream, either by the maintainers or
automatically by a bug script.  I believe, and I continue to believe,
that maintainers should forward bugs upstream instead of requiring (or
strongly encouraging) users to do so.

I understand that maintainers' time is limited and that forwarding bugs
is not an enjoyable task.  But I also understand that having a BTS
account for the upstream BTS of each of the 2405 packages I have
installed on my laptop (not to mention my other machines) is simply not
practical.  I also don't have the benefit of the rapport that a
maintainer has with upstream and knowledge of upstream practices.

I try very hard to make my bug reports simple, clear, and well-defined
(often with testcases) to make it easier for them to be forwarded and
fixed, and if they're not, I'm happy to clarify or test so that they can
be.  And I try to submit patches as my time and abilities permit.  If it
happens that I need to be added to the CC list of the upstream bug
report to assist in fixing it, I'm usually fine with that if asked.

To clarify, this is not in reference to any particular package or
maintainer; it's just something I've noticed and wanted to bring up.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Forwarding bugs upstream

[Ben Hutchings]

On Tue, 2011-01-11 at 23:54 +, brian m. carlson wrote:
> I've noticed a trend lately that I am often asked to forward the bugs I
> report to the Debian BTS upstream, either by the maintainers or
> automatically by a bug script.  I believe, and I continue to believe,
> that maintainers should forward bugs upstream instead of requiring (or
> strongly encouraging) users to do so.

If a bug is not readily reproducible or isolatable, it may be necessary
to pass it over to an upstream maintainer who will know what further
questions to ask.  But they need to send those questions to the user,
not to the Debian maintainer.  In the kernel team, we often ask users to
report bugs upstream for that reason.

> I understand that maintainers' time is limited and that forwarding bugs
> is not an enjoyable task.  But I also understand that having a BTS
> account for the upstream BTS of each of the 2405 packages I have
> installed on my laptop (not to mention my other machines) is simply not
> practical.

Surely you don't find bugs in all of those packages?

> I also don't have the benefit of the rapport that a
> maintainer has with upstream and knowledge of upstream practices.
> 
> I try very hard to make my bug reports simple, clear, and well-defined
> (often with testcases) to make it easier for them to be forwarded and
> fixed,
[...]

In that sort of case, yes, it is hard to see a justification for a
maintainer requiring you to report again upstream.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: Forwarding bugs upstream

[Cyril Brulebois]

Ben Hutchings  (12/01/2011):
> If a bug is not readily reproducible or isolatable, it may be
> necessary to pass it over to an upstream maintainer who will know
> what further questions to ask.  But they need to send those
> questions to the user, not to the Debian maintainer.  In the kernel
> team, we often ask users to report bugs upstream for that reason.

Ditto on the X side. Having a low-power proxy between developers and
users is quite a bad idea (induces delays and higher load).

KiBi.


signature.asc
Description: Digital signature

Re: Forwarding bugs upstream

[Ben Finney]

"brian m. carlson"  writes:

> I've noticed a trend lately that I am often asked to forward the bugs
> I report to the Debian BTS upstream, either by the maintainers or
> automatically by a bug script. I believe, and I continue to believe,
> that maintainers should forward bugs upstream instead of requiring (or
> strongly encouraging) users to do so.

+1

> I understand that maintainers' time is limited and that forwarding
> bugs is not an enjoyable task. But I also understand that having a BTS
> account for the upstream BTS of each of the 2405 packages I have
> installed on my laptop (not to mention my other machines) is simply
> not practical. I also don't have the benefit of the rapport that a
> maintainer has with upstream and knowledge of upstream practices.

Yes, I agree with that position. It is even more reasonable when one
considers that the person who has chosen to be a maintainer for Debian
package ‘foo’ has some amount of obligation to have an account with the
upstream BTS for ‘foo’, whereas an arbitrary user of ‘foo’ does not.

> I try very hard to make my bug reports simple, clear, and well-defined
> (often with testcases) to make it easier for them to be forwarded and
> fixed, and if they're not, I'm happy to clarify or test so that they
> can be. And I try to submit patches as my time and abilities permit.
> If it happens that I need to be added to the CC list of the upstream
> bug report to assist in fixing it, I'm usually fine with that if
> asked.

Yes, this is all a fair expectation of the user by the maintainer, in
exchange for being the contact point for the package in Debian.

-- 
 \ “To stay young requires unceasing cultivation of the ability to |
  `\   unlearn old falsehoods.” —Robert Anson Heinlein |
_o__)  |
Ben Finney


pgpKH2bcp3YnB.pgp
Description: PGP signature

Re: Forwarding bugs upstream

[Drake Wilson]

Quoth Cyril Brulebois , on 2011-01-12 01:59:03 +0100:
> > If a bug is not readily reproducible or isolatable, it may be
> > necessary to pass it over to an upstream maintainer who will know
> > what further questions to ask.  But they need to send those
> > questions to the user, not to the Debian maintainer.  In the kernel
> > team, we often ask users to report bugs upstream for that reason.
> 
> Ditto on the X side. Having a low-power proxy between developers and
> users is quite a bad idea (induces delays and higher load).

I tend to think what would be ideal in such cases is for the package
maintainer to go through the overhead motions of forwarding that
require a heavy context switch (i.e., setting the ball rolling) and
then subscribe the user to the relevant bug by email or some other
similar communication mechanism.

Which upstream bug trackers, if any, would make the above not work?
Here I'm ignoring things like maintainer time to do the forwarding,
assuming that that can be analyzed separately.  Mainly I'm wondering
about cases where the user essentially _can't_ communicate about the
bug directly without going through rigamarole to "create an account"
first or thereabouts; is this common?  If so, and assuming it's much
more expensive for the user to switch into "bug reporting" context, I
find it likely that many users would give up at that point rather than
having to report the bug a second time after having already expended
the context switch effort to report it once.

   ---> Drake Wilson


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110112012933.ga3...@drache.begriffli.ch

Re: Forwarding bugs upstream

[Ben Hutchings]

On Tue, 2011-01-11 at 18:29 -0700, Drake Wilson wrote:
> Quoth Cyril Brulebois , on 2011-01-12 01:59:03 +0100:
> > > If a bug is not readily reproducible or isolatable, it may be
> > > necessary to pass it over to an upstream maintainer who will know
> > > what further questions to ask.  But they need to send those
> > > questions to the user, not to the Debian maintainer.  In the kernel
> > > team, we often ask users to report bugs upstream for that reason.
> > 
> > Ditto on the X side. Having a low-power proxy between developers and
> > users is quite a bad idea (induces delays and higher load).
> 
> I tend to think what would be ideal in such cases is for the package
> maintainer to go through the overhead motions of forwarding that
> require a heavy context switch (i.e., setting the ball rolling) and
> then subscribe the user to the relevant bug by email or some other
> similar communication mechanism.
> 
> Which upstream bug trackers, if any, would make the above not work?
[...]

Bugzilla requires that each subscribed email address has an account.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: what are Debian emacs (24) users supposed to do now?

[jidanni]

Regarding
W: Failed to fetch 
http://emacs.orebokech.com/dists/sid/main/binary-i386/Packages.gz  404  Not 
Found
> "RF" == Romain Francoise  writes:
RF> Either build from source yourself, or go back to Emacs 23.

Holy moly. My .emacs file has evolved greatly since emacs 23 using your
emacs 24 snapshots -- I can't go back. And I can't build from source
myself because, well, if it is too frustrating for you developer guys,
it would be 1000 times more frustrating for us user guys.
So I guess there I am, stuck holding on to my precious copy of
emacs-snapshot-bin-common_1%3a20101204-1_i386.deb
emacs-snapshot_1%3a20101204-1_i386.deb
emacs-snapshot-common_1%3a20101204-1_all.deb
emacs-snapshot-el_1%3a20101204-1_all.deb
unless some other developer will step forward...


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4ia50ie.fsf...@jidanni.org

Re: Forwarding bugs upstream

[Paul Wise]

On Wed, Jan 12, 2011 at 9:29 AM, Drake Wilson  wrote:

> Which upstream bug trackers, if any, would make the above not work?

Sourceforge and probably Gforge/FusionForge trackers.

The only tracker I'm aware of which would work is Trac, some instances
of which allow anyone to put in anyone else's email address as the
author of the bug.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinlhylwoagoer0znglsld5xb5qeumh3vmdet...@mail.gmail.com

Re: Forwarding bugs upstream

[Drake Wilson]

(Woopsy, forgot to send to the list the first time.)

Quoth Paul Wise , on 2011-01-12 10:55:34 +0800:
[among other responses]
> Sourceforge and probably Gforge/FusionForge trackers.
> 
> The only tracker I'm aware of which would work is Trac, some instances
> of which allow anyone to put in anyone else's email address as the
> author of the bug.

So basically "most or all of them", then.  Right.

This doesn't leave much in the way of good options:

  - Having the user report bugs twice, with the second one being after
a delay, creates choppy context switches that can require a pile
of extra mental energy (at least in my estimation; I wouldn't mind
being shown to be wrong).  The "create an account" process is
especially choppy because it requires multiple internal context
switches to handle email verification and so forth.  This results
in giving up.

At the least, as a data point, when I've reported bugs for which I
didn't intend to be strongly active in helping develop a fix, it's
taken more than double the total energy output when I've had to
forward the bug myself: the choppy switching overwhelms everything
else, and much of the time I never get around to doing it at all,
whereas replying to another email would have happened quickly.

  - Having the maintainer be the reporter of record for upstream can
result in forwarding hassle per unit time for the maintainer which
is O(N) in the number of bugs.  It shifts the annoyance from the
previous option onto the maintainer, and condenses it in the
process (the maintainer doesn't have to establish an association
with the tracker multiple times, &c.) but the condensation is only
large for high loads for the forwarding part, and there's lots of
communication delays.  It also means the maintainer has to spend
continuous work on things that are not necessarily useful to the
package directly.

  - Having the maintainer forward the bug report but make the user the
reporter of record doesn't work because they don't have the
authority to do that, nor to override the hassle of initial
association between the user and the upstream bugtracker.

I wonder whether there's an optimization possible here, at least:
perhaps the maintainer could forward first, but then _if_ at least N
messages need to be forwarded between upstream and user, request that
the user take control of the upstream bug to streamline the rest of
the flow.  N could be 1 or 2, for instance.

   ---> Drake Wilson


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110112031934.ga6...@drache.begriffli.ch

Re: Forwarding bugs upstream

[John Goerzen]

On 01/11/2011 05:54 PM, brian m. carlson wrote:

I've noticed a trend lately that I am often asked to forward the bugs I
report to the Debian BTS upstream, either by the maintainers or
automatically by a bug script.  I believe, and I continue to believe,
that maintainers should forward bugs upstream instead of requiring (or
strongly encouraging) users to do so.


Hi Brian,

I'm going to have a slightly different viewpoint on this.

I think it is perfectly fine for a user to submit a bug report to the 
Debian BTS first.  They may not always be equipped to know what is a 
Debian and what is an upstream bug.  And I also think it ought to be 
perfectly valid for the Debian developer to close the bug saying it's an 
upstream issue, together with a pointer to the upstream BTS and promise 
to get involved should there be any question about the Debian packaging, 
environment, etc.


Now, here's how it proceeds if I have to forward a bug upstream for 
Bacula, which uses Mantis.  Creating a Mantis account takes 30 seconds, 
but Mantis won't email reports to people without accounts, and the only 
way to add stuff to it is on the web.


So, here's how it goes:

1) User submits bug report to Debian.

2) I decide if it is clearly an upstream issue.

3) I go to Mantis and fill out the fields by copying data from the 
user's bug report.


4) I mark the bug forwarded and email the user that it's happened.

5) Upstream inevitably has questions or other things for user to try.

6) I forward that email to Debian BTS and user.  Maybe I download an 
attachment from the Mantis report and attach it to the email.


7) User replies, possibly while I'm sleeping.  I log in to Mantis and 
copy and paste the answer.  I also save off attachments from the email 
and then go and attach them to the Mantis report.


8) This continues.

I'm adding zero value here.  Zero.  It is a huge and frustrating waste 
of my time.  It is also frustrating for upstream, who would rather just 
talk with the user directly and involve me if they think there's a 
Debian-specific question.  I don't understand why some users want it to 
go this way, but many clearly do despite the fact that they get worse 
service.


I'm going to be brutally honest and admit here that being a copy and 
paste monkey between emails and web forms is something I really dislike 
doing.  It is something that makes Debian the opposite of enjoyable, and 
I think I let those tasks sit longer than I should, and work on things 
instead where I can actually contribute (such as fixing Debian bugs).


I have a sense that I'm not alone.  I've noticed that there are certain 
major packages for which upstream bugs tend to get ignored for a year, 
then get a big sweep asking if they're still issues, then get ignored 
for a year again.  I won't mention names here, but I don't think it's 
necessarily entirely blame to be laid at maintainers' feet.  I just go 
and submit upstream bugs upstream on those and go on my merry way.


Maintainers in Debian do undertake certain responsibilities.  But I 
think that being copy and paste monkeys shouldn't be one of them.  If I 
were getting paid to work a helpdesk, sure.  But really, I think it is 
nonsensical for an end user to expect me to do this because the user 
doesn't want to spend 30 seconds creating an account on an upstream BTS. 
 That's not what Free Software is all about.  And it has Debian 
maintainers wasting time.


I think that promising that Debian maintainers will always shepherd bugs 
upstream is promising something we don't actually deliver on very well, 
and probably never have.  Perhaps we should stop promising it.


This is not to criticize Brian here; he has been perfectly courteous and 
up-front in his presentation.


-- John


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d2d1cdd.2010...@complete.org

Re: Forwarding bugs upstream

[Ben Finney]

John Goerzen  writes:

> Now, here's how it proceeds if I have to forward a bug upstream for
> Bacula, which uses Mantis.  Creating a Mantis account takes 30
> seconds

I don't know Brian's position on this, but “time to create an account
with arbitrary upstream BTS” isn't the issue.

“Having an account on a new service which in all likelihood will be
unused by me after very few messages” is the main concern; growing
numbers of unused site accounts are either a management hassle, or a
foolish security hole, or both.

> but Mantis won't email reports to people without accounts, and the
> only way to add stuff to it is on the web.

That sucks. It seems like a problem that is best addressed upstream, by
using a better BTS that can communicate via email.

I don't necessarily think that advocating for a better BTS needs to be
solely the job of the Debian package maintainer though; I'm merely
identifying explicitly where I see the cause of the hassle in that case.

> I'm adding zero value here. Zero. It is a huge and frustrating waste
> of my time.

Not in my view. I appreciate the Debian package maintainer acting in the
interest of “lower the barrier for each Debian user of this package to
report useful bug information”.

To be clear: Thank you for the time you spend doing this, and the same
to any other Debian maintainer who does unromantic work to keep the
good information flowing.

> It is also frustrating for upstream, who would rather just talk with
> the user directly and involve me if they think there's a
> Debian-specific question.

Hopefully that motivation can, in some cases if not all, be used to help
the upstream see that their chosen BTS is an impediment (as described
above).

> I don't understand why some users want it to go this way, but many
> clearly do despite the fact that they get worse service.

Quite the opposite, from my position. A great feature of the Debian BTS
is that any user can interact with it through a standard interface
without maintaining multiple separate identities; heck, without having
to create a single new identity at all.

Having to create and maintain (or fail to maintain) identities with
balkanised upstream BTSen is bad enough as a package maintainer. As a
mere user of all the other packages on my computers, I consider it too
high a barrier.

> I'm going to be brutally honest and admit here that being a copy and
> paste monkey between emails and web forms is something I really
> dislike doing. It is something that makes Debian the opposite of
> enjoyable, and I think I let those tasks sit longer than I should, and
> work on things instead where I can actually contribute (such as fixing
> Debian bugs).

I can appreciate that, and I feel the same way when I'm in that position
as a maintainer. You're certainly not alone.

> I think that promising that Debian maintainers will always shepherd
> bugs upstream is promising something we don't actually deliver on very
> well, and probably never have. Perhaps we should stop promising it.

I think the situation is certainly sub-optimal. But surely the solution
is not to expect Debian users to take on the work; that seems worse in
every way. At the least, the increased barrier that would result can't
help but dramatically reduce the number of upstream bug reports that get
useful information from Debian users.

Rather, we should be using the discomfort of all parties described to
press actively for a better solution to the problem for everyone.

It's not a problem that can reasonably be expected to be solved once and
for all, at least not while upstream developers are free to pick
arbitrary bad BTS software. But that doesn't mean efforts to improve the
situation at its source are futile.

-- 
 \  “If we have to give up either religion or education, we should |
  `\  give up education.” —William Jennings Bryan, 1923-01 |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87oc7md8at@benfinney.id.au

Re: Forwarding bugs upstream

[Brian May]

On 12 January 2011 14:15, John Goerzen  wrote:
> 8) This continues.

For what it is worth, I generally will ask the submitter to use the
upstream bug tracking system if there is any dispute or problems with
the bug report. Sure, this isn't ideal, but seems to me to be a
compromise between getting the user to file the report upstream and
having the Debian maintainer act as the relay for all messages.
-- 
Brian May 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinyabb5jggz6whajvndta62cc8maefpnueiy...@mail.gmail.com

Re: Forwarding bugs upstream

[Nikita V. Youshchenko]

> I understand that maintainers' time is limited and that forwarding bugs
> is not an enjoyable task.  But I also understand that having a BTS
> account for the upstream BTS of each of the 2405 packages I have
> installed on my laptop (not to mention my other machines) is simply not
> practical.  I also don't have the benefit of the rapport that a
> maintainer has with upstream and knowledge of upstream practices.

Upstream tend to request users to install latest and greatest versions, 
often for source or using other unsafe methods. Not only for package in 
question but also for explicit and implicit dependences. Non-technical 
follow these broken advices and break their systems. And then complain 
that Debian is problematic for them.

I think that forwarding user upstream is acceptable only for deeply 
technical users. But but not as a default policy.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201101120952.53...@zigzag.lvk.cs.msu.su

Re: debconf translations broken in multiple packages

[Christian PERRIER]

Quoting Christian PERRIER (bubu...@debian.org):

> Many of these packages errors are direct or indirect consequences of
> my l10n work during the lenny-squeeze release cycle.
> 
> Direct when the last uploaded version is an NMU of mine..
> 
> Indirect when a maintainer uploaded after I prodded him|her and sent a
> patch
> 
> Would it be OK for the release team if packages fixing these encoding
> errors are uploaded? I may try to at least correct some of them (those
> I NMU'ed).
> 
> 

I have ready NMUs for most of the affeted packages. I can upload them
soon.

I'm aware that, as of now, these problems haven't been reported as
bugs (not has it been discussed that these bugs are RC or not), so the
various maintainers might be surprised to be NMU'ed without warning
(though several of these packages are not very actively maitnained)

The only changes in all these packages are the fixed
debian/po/.po file and the relevant changelog entry.

Waiting for a GO from the release team for these uploads.

-- 




signature.asc
Description: Digital signature

Software Penyadap Handphone GSM & BlackBerry Messenger

[Fantastic Spy]

Dear Customer,


Curiga pasangan anda selingkuh ?
Ingin mengawasi anak dari pergaulan bebas ?
Ingin mengawasi karyawan anda dari praktik KKN ?
Ingin melacak keberadaan HP anda yg hilang ?

Kami dapat memberikan solusi nya.

Jual Software Penyadap Handphone GSM dengan berbagai macam fitur, antara lain :
- Menyadap seluruh percakapan secara live / langsung dari handphone anda
- Menyadap seluruh isi SMS yang masuk atau keluar
- Menyadap seluruh isi percakapan BlackBerry Messenger (BBM)
- Menyadap suara sekitar handphone target dari handphone anda
- Menyadap seluruh Phone Logs di handphone target
- Menyadap lokasi keberadaan target dengan menggunakan fitur GPS tracking
- Menyadap seluruh E-mail yang dikirim atau diterima oleh handphone target
- Mendeteksi terjadinya penggantian sim card di handphone yang kita sadap

Support untuk berbagai tipe HP , diantaranya :
- Nokia
- iPhone
- BlackBerry
- Samsung
- LG
- Windows Mobile
- Maemo

Anda di daerah Jakarta / Surabaya / Bali ? Ragu untuk bertransaksi online ? 
Ataukah takut tertipu ? Tenang saja... Kami punya solusinya , sebab kami 
memiliki agen yang selalu standby untuk wilayah Jakarta , Surabaya , &dan Bali 
(dan sekitarnya).
Agen kami siap menemui anda , dan membantu proses instalasi anda... Pembayaran 
pun bisa di lakukan secara COD , setelah Agen kami datang , installkan software 
di handphone anda , dan anda test seluruh fiturnya apakah sudah berjalan dengan 
sempurna...


DIJAMIN 100% Berhasil , Aman , Mudah dan Praktis.
Terbukti dan Terpercaya. Buktikan sendiri !

Berminat ? Untuk info lebih lanjut , silahkan :
kunjungi official website kami di : http://www.fantasticspy.com
Contact Person : 08785366 (Jeffry Setiawan)

Dicari agen resmi untuk seluruh wilayah Indonesia...

Jadi , siapa bilang BlackBerry Messenger tidak bisa di lacak ?
Dengan software kami ini , semua nya akan menjadi mungkin...
Kekawatiran Bangsa Indonesia dapat di atasi dengan Software ini...



Regards,


FantasticSpy.com


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/02aeb6f1-40555-08515699201...@lucas-pc