Bug#404030: ITP: gpe-clock -- alarm clock tray applet for GPE
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-clock Version : 0.25 Upstream Author : Philip Blundell <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/projects/gpe-clock.shtml * License : GPL Programming Lang: C Description : alarm clock tray applet for GPE gpe-clock is an alarm clock dock application for the GPE Palmtop Environment. It displays the time in the system tray and manages simple alarms (single or weekly). It can be configured to display a digital or an analogue clock face. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: restricted sourceless ARM uploads
On Wed, Dec 20, 2006 at 06:40:06PM +0100, Aurelien Jarno wrote: > Wookey a écrit : > > On 2006-12-20 17:39 +0100, Aurelien Jarno wrote: > >> Hi, > >> > >> For those who don't know, I have setup 8 emulated ARM build daemons and > >> started to upload packages. To know why and for more information, see > >> [1]. > > > > Very impressive piece of work aurelien! We ought to discuss if there > > is any significant reason not to use qemu 'machines' instead of actual > > hardware for slower arches. > > > > BTW, I don't think ARM needs emulated build machines. It's just that > it's the fastest ARM machine I found. My two NSLU2 won't have been enough. > > Also it seems the current ARM build machines altogether are fast enough > to build all the packages (except for building big packages like the > kernel). But a faster machine would mean that the Vancouver requirements > are satisfied, and also less machines to handle, so less work for the > ARM build daemon maintainer. Hi *, that brings up an interesting issue wrt the vancouver memorandum: it didn't address software emulation or virtualization. Can qemu and xen be shown to be reliable for buildd purposes? Does the aforementioned document need to be modified for these? cheers, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Bug#404042: ITP: libgpeschedule -- scheduling library for GPE
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: libgpeschedule Version : 0.16 Upstream Author : Florian Boor <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/projects/ * License : GPL Programming Lang: C Description : scheduling library for GPE The Debian packages have been renamed from the upstream libschedule to prevent possible conflicts and to highlight the use of the library within GPE. There exist other scheduling packages for other environments, this one is linked to libgpewidget1 and is designed for the GPE Palmtop Environment to make it small enough for embedded devices. This source package builds two binary packages: libgpeschedule0 scheduling library for GPE Scheduling library that is used by the GPE Palmtop Environment to schedule events and warn applications of their occurence. . This package contains the shared libraries. libgpeschedule-dev GPE scheduling library development files Scheduling library that is used by the GPE Palmtop Environment to schedule events and warn applications of their occurence. . This package contains the development files. . Homepage: http://www.kernelconcepts.de/~fuchs/gpe/doc/libschedule/ -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED]
最新發信程式下載，免費完整教學，都在 http://home.kimo.com.tw/edmschool002
Bug#404059: ITP: gpe-conf -- configuration toolset for GPE
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-conf Version : 0.2.2 Upstream Author : Florian Boor <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/projects/gpe-conf.shtml * License : GPL Programming Lang: C Description : configuration toolset for GPE GPE-Conf is a set of configuration tools for the GPE Palmtop Environment to perform the basic configuration tasks on a mobile device. It is designed to expose all necessary settings in an easy to use and unintrusive way. It is also able to set up some tasks that are the subject of more advanced use of a device such as serial port usage and multi user setups. . The GPE-Conf package contains another small tool - GPE-Info to provide information about the device and current status as well. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 debian/gpe-conf.1 usr/share/man/man1/ Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404069: ITP: otf2bdf -- command line utility to generate BDF bitmap fonts from OpenType outline fonts
Package: wnpp Severity: wishlist Owner: Miriam Ruiz <[EMAIL PROTECTED]> * Package name: otf2bdf Version : 3.0 Upstream Author : Mark Leisher <[EMAIL PROTECTED]> * URL : http://crl.nmsu.edu/~mleisher/ttf2bdf.html * License : BSD Programming Lang: C Description : command line utility to generate BDF bitmap fonts from OpenType outline fonts otf2bdf is a command line utility that uses the FreeType 2 font rendering library to generate BDF bitmap fonts from OpenType outline fonts at different sizes and resolutions. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404073: RFA: autofs
Package: wnpp Severity: normal Hi, I cannot anymore give autofs the proper care it needs -- for one, I do not have any places where I run autofs anymore, and as I'm not taking proper care of the non-RC bugs, I'm trying to find a new maintainer. The package is not especially big or complex; it has no RC-bugs, and upstream is usually quite easy to work with. The diff against upstream is also of a reasonable size; most patches come directly from upstream (most custom patches have long since been fed back). It should be in OK shape for etch; for lenny, we should probably switch to autofs 5 (currently in beta). As a personal request, I'd like the new maintainer to not have a lot of packages already, as the package is going to require a bit of constant care. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19 Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402650: ITP: mozilla-foxyproxy -- advanced proxy management tool for iceweasel
I've decided to go with no prefix, since mozilla- prefix is a trademark and point of having it nowadays is quite absent. So now the package is simply "foxyproxy". I will tag it accordingly: implemented-in::TODO (JavaScript is a missing tag although present in devel::lang) role::plugin suite::mozilla interface::x11 uitoolkit::gtk (or should I may be request uitoolkit::xul?) use::proxying Preliminary package is available from http://itanix.rutgers.edu/rumba/dists/sid/perspect/binary-all/web/foxyproxy_2.2.1-1_all.deb and sources http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/foxyproxy_2.2.1-1.dsc I would appreciate any comments -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpkZvfgLDfvy.pgp Description: PGP signature
Re: restricted sourceless ARM uploads
On Wed, Dec 20, 2006 at 06:50:12PM +0100, Sam Hocevar wrote: > On Wed, Dec 20, 2006, Bill Gatliff wrote: > > > For the faster arches, i.e. the ARM9 machines and above, I'm thinking > > that we should stick with real hardware so there's no question that the > > binaries will run properly. > >Pardon me sir, but can that claim that binaries built on so-called > "real hardware" will unquestionably run (as opposed to, if I understand > correcly, binaries built on an emulated platform) be backed up by any > facts, examples, experimentation results or scientific publication? Binaries built on real hardware are built on a machine that uses the binaries built on same real hardware. I.e., if it works, at least you're sure it doesn't work because the compiler and the emulator are bug-compatible. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: restricted sourceless ARM uploads
On Thu, Dec 21, 2006, Wouter Verhelst wrote: > >Pardon me sir, but can that claim that binaries built on so-called > > "real hardware" will unquestionably run (as opposed to, if I understand > > correcly, binaries built on an emulated platform) be backed up by any > > facts, examples, experimentation results or scientific publication? > > Binaries built on real hardware are built on a machine that uses the > binaries built on same real hardware. This is not true. We have different ARM machines that use different CPUs and hardware. Given the versatility of the ARM platform, if the argument "building the binaries on the same machine that uses the binaries" was valid whatsoever, it would in fact be an argument in favour of only using a standardised emulated platform. > I.e., if it works, at least you're sure it doesn't work because the > compiler and the emulator are bug-compatible. But you're sure that it's not because the compiler and the CPU are bug-compatible? Regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Downgrading the priority of nfs-utils
Am 2006-11-07 04:40:21, schrieb Goswin von Brederlow: > But wouldn't you be surprised if "mount -tnfs server:/path > /local/path" suddenly wouldn't work anymore in a fresh install? No, it works, but since "portmap" is not more (since Sarge) installed by default it need arround 60-300 seconds to mount but after this time, it is there. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Bug#404080: ITP: eu-es-myspell -- Basque dictionary for myspell/aspell spellcheckers
Package: wnpp Severity: wishlist Owner: Agustin Martin Domingo <[EMAIL PROTECTED]> * Package name: eu-es-myspell Version : 2006/10/06 Upstream Author : Eleka Ingeniaritza Linguistikoa S.L. // www.eleka.net * URL : http://www.euskara.euskadi.net/r59-738/eu/contenidos/informacion/euskarazko_softwarea/eu_9567/adjuntos/xuxen/eu-ES-myspell.tar.gz * License : CC BY-NC-SA (that is, *non-free*) Description : Basque dictionary for myspell/aspell spellcheckers This source package provides binaries for use of Basque in myspell and aspell spellcheckers. Aspell package is derived from the myspell one. Unfortunately, license is non-free (NC: non-commercial), but still distributable. Preliminary packages are at http://dict-common.alioth.debian.org/aspell-autobuildhash/ together with other dict-common stuff. Signed sources under the sources dir. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404083: ITP: gpe-appmgr -- application manager for GPE desktop
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-appmgr Version : 2.8 Upstream Author : Robert Mibus <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/projects/GPE-appmgr.shtml * License : GPL Programming Lang: C Description : application manager for GPE desktop The application manager is the main window of an embedded device running the GPE Palmtop Environment. It allows users to start-up applications and offers a main menu. Any application that a user should be able to access should also be available through the application manager. . GPE-Appmgr uses freedesktop.org-style desktop files like known from Gnome and KDE. It is able to deal with single- and multi instance applications as well as different screen sizes. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cpufire-applet_1.2-2_arm.changes REJECTED
Hi Aurelien, On 12/20/06, Aurelien Jarno <[EMAIL PROTECTED]> wrote: Yes, this package builds fine on arm. The problem you observed on the build log are due to recurrent problem of the build daemon on which this package as been built. I don't have the right to upload binary arm packages anymore [1], so I am sorry, but I can't help you. thanks for your work. The package has been built now 'officially'. Regards, Torsten -- blog: http://twerner.blogspot.com/ homepage: http://www.twerner42.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: localisation in system wide daemons
On Wed, Nov 29, 2006 at 07:33:20PM +0100, Nico Golde wrote: > Hi, > Adam Cécile reported #400719[0] to the fetchmail package. > > The question is wheter a system wide daemon should care > about the system wide locale configurations or not. I'd say yes, since if the daemon spits out messages (either error or logs) the admin will want it to use the system's locale. BTW, IIRC currently the system's wide locale is set only by the locales package and introduced in either /etc/default/locale (glibc 2.3.6-5 and later, which means etch or later) or /etc/environment (woody or earlier) by it's postinst. Only a few (in my system) init.d scripts read this one in. > Fetchmail currently does, we are not calling it with > LC_MESSAGES=C or something similar. But are you sourcing the system's locale or are you depending on the locale of the user *starting* fetchmail? > I can't find anything about this in the policy but to me it > doesnt make sense to use a locale if you dont want it for > some programs. Why would you *not* want a locale? If the program has l10n support and it provides messages (even in a non-interactive way) there's chances some users will benefit from the translated messages. > Since it would be also possible to adjust the settings with > LC_ALL=C in /etc/default/fetchmail I just closed the bug but > reopened it now cause I want to hear some other opinions. > What do you think what is the best way here? I suggest you introduce a variable in /etc/default/fetchmail named "USE_SYSTEM_LOCALE" and do that (source the system locale if it exists) if set to 'Y'. That's better than forcing users to introduce the system locale in every /etc/default/XXX file and it also makes it easier to switch a system's locale (no need to touch in many different /etc/default/ files, just the 'locale' itself). Set the default to whatever you feel comfortable with. Just my few cents. Regards Javier signature.asc Description: Digital signature
Re: Downgrading the priority of nfs-utils
On Thu, Dec 21, 2006 at 06:51:58PM +0100, Michelle Konzack wrote: > Am 2006-11-07 04:40:21, schrieb Goswin von Brederlow: > > But wouldn't you be surprised if "mount -tnfs server:/path > > /local/path" suddenly wouldn't work anymore in a fresh install? > > No, it works, but since "portmap" is not more (since Sarge) > installed by default it need arround 60-300 seconds to mount > but after this time, it is there. Are you sure it's not installed? It's Priority: standard so if the user (in tasksel) selects 'standard' he *will* get the portmapper. Not sure right now what happens if he selects another task but, at least in Sarge, since fam (installed because of dependencies in the GNOME task [1]) depended on the portmapper it would get installed in that case too. From what I see in tasksel's sources, the same should be true for Etch too. Right? Regards Javier [1] More precisely the dependency of gnome-desktop-environment which is part of the 'gnome-desktop' task signature.asc Description: Digital signature
Re: python 2.3
Thomas Bushnell BSG writes: > On Wed, 2006-12-20 at 19:51 -0800, Steve Langasek wrote: > > On Tue, Dec 19, 2006 at 11:17:03AM -0800, Thomas Bushnell BSG wrote: > > > The python team has apparently decreed that python 2.3 will not be in > > > etch. This forces every package to use the new version. Surely it is > > > too late in the release cycle to be risking regressions in this way? > > > > The python team has expressed concern about the security supportability of > > python2.3 in etch. Extension packages built with the current version of > > python-all-dev and friends already have no support for python2.3; shipping > > python2.3 in stable for the benefit of a handful of reverse dependencies is > > a genuine concern, particularly when those reverse-deps work just fine with > > python 2.4. > > And yet, this isn't the only case. Users actually use the programs in > Debian, not just other parts of Debian. Why is python 2.3 some sort of > security nightmare? And what suddenly happened to make it one? python2.3 doesn't get attention by upstream anymore. there was a 2.3.6 release to address a security related issue (which is addressed for sarge and current testing), but even for the 2.4 series no new upstream bug fix releases are announced for the future. If you ask why 2.5 isn't the default for etch: by the time upstream versions were frozen for etch we didn't have new upstream releases for packages depending on 2.5. it's still difficult at this point of time (Dec 2006) to make 2.5 the default and rely on upstream releases for depending packages. An explicitely stated goal of the release team was to reduce the number of supported python versions for the next stable release. We did include three python versions for sarge (2.[123]). To reduce that count we do have to drop 2.3 (prefering 2.5 over 2.3). > What about users who are depending on Python 2.3? Do they just lose? yes. and even if the transition to the new default version was late, you do loose. > It seems to me that for things like this, our releases should always > have the next-oldest version as an option for those users. No. there is no reason to do so. The two reasons we did come up with the support of more than one python version are: - some applications are very late to adopt a new python upstream version (the last version to provide compatibility with 2.4 was zope2.x). Debian currently doesn't have a process of freezing packages for a release besides the toolchain. - the inability to manage the transition of packages from unstable to testing. If you do want to work around the current migration process from unstable to testing you have to support the python version in testing and unstable. Every proposal to just support one python version in Debian bares any sense of Debian reality. To conclude, the support of multiple python versions is not meant at all as an excuse for lazy debian maintainers depending on python for not following upstream python development. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python 2.3
On Fri, Dec 22, 2006 at 12:38:05AM +0100, Matthias Klose wrote: > An explicitely stated goal of the release team was to reduce the > number of supported python versions for the next stable release. We > did include three python versions for sarge (2.[123]). Actually, four: 2.4 is also in sarge (maintained by you). > To reduce that count we do have to drop 2.3 (prefering 2.5 over 2.3). The count is already reduced by one, but I agree it'd be nice to drop one more version from etch when the opportunity is there. At the moment though, that'd still require python-defaults to migrate, along with packages like abiword and gnucash. I'm disinclined to remove python2.3 from unstable just yet, because that might block a new revision of (for example) abiword coming into etch via unstable. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python 2.3
On Fri, 2006-12-22 at 00:38 +0100, Matthias Klose wrote: > To conclude, the support of multiple python versions is not meant at > all as an excuse for lazy debian maintainers depending on python for > not following upstream python development. Are you calling me lazy for not fixing a bug that you never bothered to report before you uploaded an illegal NMU? signature.asc Description: This is a digitally signed message part
Re: python 2.3
On Fri, 2006-12-22 at 00:38 +0100, Matthias Klose wrote: > An explicitely stated goal of the release team was to reduce the > number of supported python versions for the next stable release. We > did include three python versions for sarge (2.[123]). To reduce that > count we do have to drop 2.3 (prefering 2.5 over 2.3). I've got no complaint against reducing the number of versions, but I think that there should be at least one version of overlap. Thomas signature.asc Description: This is a digitally signed message part
Re: Two questions on package quality
Nikita V. Youshchenko dijo [Sun, Dec 17, 2006 at 09:48:02AM +0300]: > Hello people. > > I was asked to sponsor a package upload. > I am in doubt on tho following issues, so I/m asking debian-devel for > comments. > > > 1. Upstream does not provide a manual page for the binary. Packager decided > to add binary-without-manpage to lintian override file, and Tag: > no-manual-for-binary to linda override file. > > My questions are: > > - Is having a manual page for each binary inside package a mandatory > requirement these days? It's not mandatory, but strongly prefered. Think about this: How complex is this binary's user interface? Is it easy enough so that a user can understand its working without a manpage? Great, then writing a manpage should prove trivial. Is it so complicated that writing a manpage is too much work? Well, then how do you expect your users to understand and use it? :) > 2. Upstream tarball contains ttf-dejavu font. Linda found that and > complained. I've asked packager to remove font both from binary package > and upstream tarball, and to make binary package to depend on ttf-dejavu > instead. > > So .orig.tar.gz got repackaged, and now it differs from upstream. > > Should then 'upstream' version string be changed from x.y.z to > x.y.z.debian? Or not? Or it does not matter? Yes, it should be changed. Not because of the policy, but for clearness. Of course, document prominently that you are not building from upstream sources. And, if possible, add a check in debian/rules so you (or someone else) don't forget to repackage the orig.tar.gz for the next upstream version. Make the build fail if it has ttf-dejavu. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Two questions on package quality
Russ Allbery dijo [Sun, Dec 17, 2006 at 11:20:37AM -0800]: > > 2. Upstream tarball contains ttf-dejavu font. Linda found that and > > complained. > > Why? > > Sure, duplication of code is a bit annoying, but ttf-dejavu appears to be > a free font, so it doesn't hurt anything that the upstream tarball > contains it. The installed *package* shouldn't duplicate the font and > should instead just depend on the font package it needs (or possibly not > even depend -- if it's only accessing the font via X, it should only > recommend and allow for the possibility that there's an X font server > providing the font). But there's no harm that I can see in leaving the > font in the upstream tarball unless it's under some other non-DFSG-free > license, and you want to avoid repackaging the upstream tarball when you > can help it. Oh! I have to agree with Russ: If the font is free, then just delete it from the target directory after building. Ship pristine sources. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Work-needing packages report for Dec 22, 2006
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 335 (new: 0) Total number of packages offered up for adoption: 88 (new: 3) Total number of packages requested help for: 38 (new: 1) Please refer to http://www.debian.org/devel/wnpp/ for more information. No new packages have been orphaned, but a total of 335 packages are orphaned. See http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: autofs (#404073), offered today Description: kernel-based automounter for Linux Reverse Depends: autofs-hesiod autofs-ldap jukebox-mercury Installations reported by Popcon: 1698 toshset (#403683), offered 3 days ago Description: Access much of the Toshiba laptop hardware interface Reverse Depends: acpi-support Installations reported by Popcon: 3107 toshutils (#403685), offered 3 days ago Description: Toshiba laptop utilities Installations reported by Popcon: 86 85 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: [NEW] apt-cacher (#403584), requested 3 days ago Description: caching proxy system for Debian package and source files Installations reported by Popcon: 214 aboot (#315592), requested 546 days ago Description: Alpha bootloader: Looking for co-maintainers Reverse Depends: aboot aboot-cross dfsbuild ltsp-client Installations reported by Popcon: 53 apt-build (#365427), requested 236 days ago Description: Need new developer(s) Installations reported by Popcon: 494 apt-show-versions (#382026), requested 135 days ago Description: lists available package versions with distribution Installations reported by Popcon: 2015 athcool (#278442), requested 786 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 223 audacity (#397166), requested 46 days ago Description: looking for co-maintainer Installations reported by Popcon: 2110 cdw (#398252), requested 39 days ago Description: Tool for burning CD's - console version Reverse Depends: cdw gcdw Installations reported by Popcon: 244 cvs (#354176), requested 301 days ago Description: Concurrent Versions System Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (16 more omitted) Installations reported by Popcon: 9426 docbook (#358522), requested 274 days ago Description: standard SGML representation system for technical documents Reverse Depends: alcovebook-sgml docbook-dsssl docbook-to-man sgmltools-lite Installations reported by Popcon: 3529 docbook-xml (#358520), requested 274 days ago Description: standard XML documentation system, for software and systems Reverse Depends: dblatex docbook-dsssl docbook-ebnf docbook-html-forms docbook-jrefentry docbook-mathml docbook-simple docbook-slides docbook-website docbook-xsl-stylesheets-ko (6 more omitted) Installations reported by Popcon: 13125 dpkg (#282283), requested 761 days ago Description: dselect: a user tool to manage Debian packages Reverse Depends: alien alsa-source apt-build apt-cross apt-src backuppc build-essential clamsmtp crosshurd cvs-autoreleasedeb (83 more omitted) Installations reported by Popcon: 20985 grub (#248397), requested 955 days ago Description: GRand Unified Bootloader Reverse Depends: dfsbuild grub-splashimages grubconf replicator Installations reported by Popcon: 17392 gtkpod (#319711), requested 515 days ago Description: manage songs and playlists on an Apple iPod Installations reported by Popcon: 467 ispell-et (#391105), requested 78 days ago Description: Estonian dictionary for Aspell/Ispell/MySpell Installations reported by Popcon: 16 lighttpd (#401575), requested 17 days ago Description: A fast webserver with minimal memory footprint Reverse Depends: lighttpd-mod-cml lighttpd-mod-magnet lighttpd-mod-mysql-vhost lighttpd-mod-trigger-b4-dl lighttpd-mod-webdav Installations reported by Popcon: 320 loop-aes-modules (#385615), requested 112 days ago Description: loop-AES modules Reverse Depends: loop-aes-2.6-486 loop-aes-2.6-686 loop-aes-2.6-686-bigmem loop-aes-2.6-alpha-generic loop-aes-2.6-alpha-legacy loop-aes-2.6-alph
Re: localisation in system wide daemons
Hi! On Fri, 2006-12-22 at 03:27 +0100, Javier Fernández-Sanguino Peña wrote: > On Wed, Nov 29, 2006 at 07:33:20PM +0100, Nico Golde wrote: > > > > I can't find anything about this in the policy but to me it > > doesnt make sense to use a locale if you dont want it for > > some programs. > > Why would you *not* want a locale? If the program has l10n support and it > provides messages (even in a non-interactive way) there's chances some users > will benefit from the translated messages. In log files, localized messages may hurt more, than what gain with it. For example some (semi)automatic log analyzing programs couldn't (and I think don't want to) handle localized log messages.
