Re: Bug#572733: support for mounting other kernel filesystems

On Sat, Mar 06, 2010 at 05:03:05AM +0100, Marco d'Itri wrote: > Do we agree to mount these filesystems on /dev/ subdirectories? > Fedora[1] uses /dev/hugepages/ for hugetlbfs, and while we had a > discussion on debian-devel@ about where cgroups should be mounted there > was no clear winner. > The u

Bug#572733: support for mounting other kernel filesystems

Package: initscripts Version: 2.87dsf-8.1 Severity: normal I am tentatively opening this bug on initscripts to start a discussion, but I am unsure about the best way to solve the problem. Still, I believe it is important to solve it in time for the next release because it is a prerequisite of some

Re: opinions on NEWS file within a Debian release

I should probably also mention that I'm assuming most people use apt-listchanges, which may not be accurate. :) -- Mike Markley -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists

Re: opinions on NEWS file within a Debian release

On Fri, 2010-03-05 at 12:32 -0800, Mike Markley wrote: > A package I maintain (opendkim) has released a new major version which > removes support for a commonly-used conf file setting in the previous > version. Although that setting is common, it is not set by default in > the Debian package. > >

Re: Removing the manpage requirement for GUI programs?

Charles Plessy writes: > for the record, I have sumbitted to the Debian fork of the man system > the idea of tapping into the desktop menu entries when a program has no > manpage. > https://savannah.nongnu.org/bugs/index.php?29083 This seems like an unnecessarily complex way of implementing the

Re: Removing the manpage requirement for GUI programs?

Hello everybody, for the record, I have sumbitted to the Debian fork of the man system the idea of tapping into the desktop menu entries when a program has no manpage. https://savannah.nongnu.org/bugs/index.php?29083 “For those who care about manpages”, I would like to point out that the origina

Re: Removing the manpage requirement for GUI programs?

On 2010-03-05 10:56:21 +0100, Daniel Leidert wrote: > Of course it does not happen, that evolution crashes for specific > mails and then keeps crashing on every new start, because it opens the > same mail. The only way to fix this, is to start with a different > component. Do you need the bug repor

Re: Removing the manpage requirement for GUI programs?

On 2010-03-05 11:04:48 +0100, Josselin Mouette wrote: > Command-line switches are documented where you expect them to be > documented: in command-line switches, with the standard --help option. This is nonsense. Not all commands understand --help. -- Vincent Lefèvre - Web:

Re: Removing the manpage requirement for GUI programs?

On 2010-03-05 17:41:25 +, brian m. carlson wrote: > Allowing "any format viewable in Debian" potentially requires the > average user to install lots of random packages just to view basic > documentation on invoking a program. Also, providing, for example, PDF > documentation as the sole form f

opinions on NEWS file within a Debian release

A package I maintain (opendkim) has released a new major version which removes support for a commonly-used conf file setting in the previous version. Although that setting is common, it is not set by default in the Debian package. However, this package has yet to see a Debian release. As such, it

Re: Removing the manpage requirement for GUI programs?

On Thu, Mar 04, 2010 at 04:32:45PM +0100, Josselin Mouette wrote: > Le jeudi 04 mars 2010 à 15:20 +0100, Bill Allombert a écrit : > > On Thu, Mar 04, 2010 at 10:26:06AM +0100, Josselin Mouette wrote: > > > No. It’s just that they ship with HTML documentation, which is much more > > > suitable for d

Re: md5sums files

> > On Wed, Mar 3, 2010 at 10:05:11 -0600, Peter Samuelson wrote: > >> fundamentally, shipping a md5sums file is really just a tradeoff in > >> download size vs. installation speed, not unlike gzip vs. bzip2. One > Julien Cristau writes: > > Only if you assume that disks never fail and thus fi

Re: md5sums files

[Russ Allbery] > Figuring out a better solution for why the files in /var/lib/ispell > and /var/lib/aspell are excluded from the md5sums generation because > they change after installation is probably needed if we're going to > remove creation of those files from control of the packager. It seems

Re: md5sums files

Don Armstrong writes: > On Wed, 03 Mar 2010, Wouter Verhelst wrote: >> In this day and age of completely and utterly broken MD5[0], I think we >> should stop providing these files, and maybe provide something else >> instead. Like, I dunno, shasums? Or perhaps gpgsigs? But stop >> providing md5s

Re: md5sums files

On Wed, 03 Mar 2010, Wouter Verhelst wrote: > In this day and age of completely and utterly broken MD5[0], I think we > should stop providing these files, and maybe provide something else > instead. Like, I dunno, shasums? Or perhaps gpgsigs? But stop providing > md5sums. Is there any reason why

Re: md5sums files

Julien Cristau writes: > On Wed, Mar 3, 2010 at 10:05:11 -0600, Peter Samuelson wrote: > >> fundamentally, shipping a md5sums file is really just a tradeoff in >> download size vs. installation speed, not unlike gzip vs. bzip2. One > > Only if you assume that disks never fail and thus files nev

Bug#572694: ITP: librb-inotify-ruby -- simple linux kernel inotify wrapper for monitoring file and directory changes

Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: librb-inotify-ruby Version : 0.7.0 Upstream Author : Nathan Weizenbaum * URL : http://github.com/nex3/rb-inotify * License : MIT Programming Lang: Ruby Description : simple linux ke

Re: md5sums files

Bernd Zeimetz writes: > Philipp Kern wrote: >> On 2010-03-03, Wouter Verhelst wrote: >>> This is where I disagree. When a checksum algorithm is compromised (and >>> MD5 *is* compromised), things only ever get worse, not better. Indeed, >>> MD5 preimage attacks are pretty hard *today*. But switch

Re: linux-image-*-dbg for squeeze?

On Fri, Mar 05, 2010 at 09:07:50AM +0100, Lucas Nussbaum wrote: > I wonder what we (as Debian) could do about it. Would it make sense to > sponsor a very fast machine that the kernel team could use to build the > kernels and upload from, replacing kernel-archive.buildserver.net ? The easiest fix i

Re: Removing the manpage requirement for GUI programs?

On Fri, Mar 05, 2010 at 04:09:05PM +0800, Paul Wise wrote: > 2010/2/28 Josselin Mouette : > > > currently policy §12.1 mandates that “each program, utility, and > > function should have an associated manual page”. However, the more I > > stomp on bug reports about manual pages, the less I am convi

Re: Removing the manpage requirement for GUI programs?

On 5 March 2010 17:46, Yves-Alexis Perez wrote: > Le 27/02/2010 22:11, markus schnalke a écrit : > >> Man pages have one more important advantage: Every command has one. > > Which is not true, and the point of the discussion. I think it should have read: They (should) provide a uniform way to ac

Re: sensible-mailer

On Fri, Mar 05, 2010 at 04:46:40PM +0100, Yves-Alexis Perez wrote: > Le 05/03/2010 15:43, Harald Braumann a écrit : > > On Fri, Mar 05, 2010 at 03:30:45PM +0100, Giacomo A. Catenazzi wrote: > >> On 05.03.2010 15:18, Josselin Mouette wrote: > >>> Le vendredi 05 mars 2010 à 15:06 +0100, Harald Brauma

Re: Removing the manpage requirement for GUI programs?

Le 27/02/2010 22:11, markus schnalke a écrit : > [2010-02-27 20:06] Josselin Mouette >> >> I think it is a waste of time to write manual pages that won't be >> maintained upstream, and that won't contain more useful information than >> --help. The purpose of a manual page is to document precisely

Bug#572665: ITP: liblog-dispatchouli-perl -- simple wrapper around Log::Dispatch

Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: liblog-dispatchouli-perl Version : 1.100630 Upstream Author : Ricardo SIGNES * URL : http://search.cpan.org/dist/Log-Dispat

Re: Removing the manpage requirement for GUI programs?

Le 05/03/2010 11:04, Josselin Mouette a écrit : > Furthermore, for a few releases now, evolution has stopped displaying a > message that triggered a crash on startup. If it still happens for you, > you might consider filing a bug (in addition to the one where you submit > the backtrace for your cra

Bug#572663: ITP: liblog-dispatch-array-perl -- module to log events to an array (reference)

Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: liblog-dispatch-array-perl Version : 1.001 Upstream Author : Ricardo Signes, * URL : http://search.cpan.org/dist/Log-Dispat

Re: Removing the manpage requirement for GUI programs?

Le 05/03/2010 08:41, Daniel Leidert a écrit : > You need a dozen GROFF macros and 2 or 3 escapes. And this is a > burden to you guys? Really? Yes. But if you volunteer to do that upstream, I'm sure it'll be really appreciated. I have stuff way more interesting and/or urgent to do on Debian (and as

Re: sensible-mailer

Le 05/03/2010 15:43, Harald Braumann a écrit : > On Fri, Mar 05, 2010 at 03:30:45PM +0100, Giacomo A. Catenazzi wrote: >> On 05.03.2010 15:18, Josselin Mouette wrote: >>> Le vendredi 05 mars 2010 à 15:06 +0100, Harald Braumann a écrit : I'd like to propose a `sensible-mailer' command. The main

Re: sensible-mailer

Harald Braumann, le Fri 05 Mar 2010 15:47:02 +0100, a écrit : > On Fri, Mar 05, 2010 at 03:10:26PM +0100, Samuel Thibault wrote: > > Harald Braumann, le Fri 05 Mar 2010 15:06:28 +0100, a écrit : > > > I'd like to propose a `sensible-mailer' command. > > > > Well, there is /etc/alternatives/mailx >

Re: sensible-mailer

On Fri, Mar 05, 2010 at 03:10:26PM +0100, Samuel Thibault wrote: > Harald Braumann, le Fri 05 Mar 2010 15:06:28 +0100, a écrit : > > I'd like to propose a `sensible-mailer' command. > > Well, there is /etc/alternatives/mailx You can't set, e.g., mutt as an alternative. Also the problem with the a

Re: sensible-mailer

On Fri, Mar 05, 2010 at 03:30:45PM +0100, Giacomo A. Catenazzi wrote: > On 05.03.2010 15:18, Josselin Mouette wrote: > >Le vendredi 05 mars 2010 à 15:06 +0100, Harald Braumann a écrit : > >>I'd like to propose a `sensible-mailer' command. The main usage would > >>be to handle `mailto' links. But ma

Re: sensible-mailer

On 05.03.2010 15:18, Josselin Mouette wrote: > Le vendredi 05 mars 2010 à 15:06 +0100, Harald Braumann a écrit : >> I'd like to propose a `sensible-mailer' command. The main usage would >> be to handle `mailto' links. But maybe such functionality already exists >> and I'm just not aware of it, or t

Re: sensible-mailer

On 05.03.2010 15:18, Josselin Mouette wrote: Le vendredi 05 mars 2010 à 15:06 +0100, Harald Braumann a écrit : I'd like to propose a `sensible-mailer' command. The main usage would be to handle `mailto' links. But maybe such functionality already exists and I'm just not aware of it, or there are

Re: sensible-mailer

On 05.03.2010 15:10, Samuel Thibault wrote: Harald Braumann, le Fri 05 Mar 2010 15:06:28 +0100, a écrit : I'd like to propose a `sensible-mailer' command. Well, there is /etc/alternatives/mailx It is a different things (IMHO). mailx is used to send mail (POSIX way), mailto: means to open a

Re: sensible-mailer

Le vendredi 05 mars 2010 à 15:06 +0100, Harald Braumann a écrit : > I'd like to propose a `sensible-mailer' command. The main usage would > be to handle `mailto' links. But maybe such functionality already exists > and I'm just not aware of it, or there are specific reasons for not > implementing t

Re: sensible-mailer

On Mar 05, Harald Braumann wrote: > I'd like to propose a `sensible-mailer' command. The main usage would > be to handle `mailto' links. But maybe such functionality already exists > and I'm just not aware of it, or there are specific reasons for not > implementing this. http://portland.freedeskt

Re: sensible-mailer

Harald Braumann, le Fri 05 Mar 2010 15:06:28 +0100, a écrit : > I'd like to propose a `sensible-mailer' command. Well, there is /etc/alternatives/mailx Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.de

sensible-mailer

Hi, I'd like to propose a `sensible-mailer' command. The main usage would be to handle `mailto' links. But maybe such functionality already exists and I'm just not aware of it, or there are specific reasons for not implementing this. The script should accept a `mailto' link as its parameter and t

Bug#572637: ITP: haskell-non-negative -- Non-negative numbers for Haskell

Package: wnpp Severity: wishlist Owner: "Ernesto Hernández-Novich (USB)" * Package name: haskell-non-negative Version : 0.0.5.1 Upstream Author : Henning Thielemann * URL : http://hackage.haskell.org/package/non-negative * License : GPL Programming Lang: Ha

Bug#572633: ITP: gnubatch -- A network-based batch scheduler

Package: wnpp Severity: wishlist Owner: Philip Hands * Package name: gnubatch Version : 1.2 Upstream Author : John M Collins * URL : http://www.gnu.org/software/gnubatch * License : GPL 3 or later Programming Lang: C, Perl Description : A network-base

Re: linux-image-*-dbg for squeeze?

Hi Lucas, On Fri, Mar 05, 2010 at 09:07:50AM +0100, Lucas Nussbaum wrote: > On 04/03/10 at 16:40 -0700, John Wright wrote: > > Hi kernel team, > > > > (Cc-ing -devel to get more eyes on the subject, since I'm soliciting > > ideas here... See [1] for some context.) > > > > What would it take to

Re: Removing the manpage requirement for GUI programs?

Le vendredi 05 mars 2010 à 10:56 +0100, Daniel Leidert a écrit : > Of course it does not happen, that evolution crashes for specific > mails and then keeps crashing on every new start, because it opens the > same mail. The only way to fix this, is to start with a different > component. Do you need

Re: Removing the manpage requirement for GUI programs?

Josselin Mouette wrote: > Le vendredi 05 mars 2010 à 09:30 +0100, Vincent Lefevre a écrit : > > > Because the users have not yet decided if they want to start the > > > application > > > and they look to the manpage for guidance. > > > > Yes, and for various reasons, it may happen that the applic

Re: Removing the manpage requirement for GUI programs?

Le vendredi 05 mars 2010 à 08:41 +0100, Daniel Leidert a écrit : > You need a dozen GROFF macros and 2 or 3 escapes. And this is a > burden to you guys? Really? Given the benefit, which is close to zero? Yes. -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same

Re: Removing the manpage requirement for GUI programs?

Le vendredi 05 mars 2010 à 09:30 +0100, Vincent Lefevre a écrit : > > Because the users have not yet decided if they want to start the application > > and they look to the manpage for guidance. > > Yes, and for various reasons, it may happen that the application > doesn't start (e.g. due to incorr

Re: Removing the manpage requirement for GUI programs?

On 2010-03-05, Daniel Leidert wrote: > You need a dozen GROFF macros and 2 or 3 escapes. And this is a > burden to you guys? Really? Patches welcome. I think we have the need of a couple of hundred in KDE. Probably something similar in gnome land. and also quite many in xfce. /Sune -- To UNSU

Re: Removing the manpage requirement for GUI programs?

On 2010-03-04 17:12:15 +0100, Bill Allombert wrote: > On Thu, Mar 04, 2010 at 04:32:45PM +0100, Josselin Mouette wrote: > > Because, of course, the user is too stupid to click the “Help” menu > > inside the application. > > Because the users have not yet decided if they want to start the applicati

Re: Removing the manpage requirement for GUI programs?

On Fri, 2010-03-05 at 15:53 +0800, Paul Wise wrote: > On Fri, Mar 5, 2010 at 3:41 PM, Daniel Leidert > wrote: > > > What's the problem, to write a short manual page, that points to the > > --help switch? All the maintainer would have to do is to provide the > > intention of the command, point to

Re: Removing the manpage requirement for GUI programs?

2010/2/28 Josselin Mouette : > currently policy §12.1 mandates that “each program, utility, and > function should have an associated manual page”. However, the more I > stomp on bug reports about manual pages, the less I am convinced of > their usefulness for GUI programs. How about replacing "an

Re: linux-image-*-dbg for squeeze?

On 04/03/10 at 16:40 -0700, John Wright wrote: > Hi kernel team, > > (Cc-ing -devel to get more eyes on the subject, since I'm soliciting > ideas here... See [1] for some context.) > > What would it take to get kernel debuginfo into squeeze? As I > understand it, the main blockers were [2]: Hi