Re: RFC: Better formatting for long descriptions

On Wed, Apr 15 2009, Guillem Jover wrote: > Tag \* was used 9277 times (68.0900%) > Tag - was used 3837 times (28.1600%) > Tag + was used 120 times (.8800%) > Tag o was used 390 times (2.8600%) > > Regardless of the numbers though (which have moved lately slightly in > favour of '-' due to the re

Item lists bulletting (was: Re: RFC: Better formatting for long descriptions)

Andreas Tille a écrit : > I have not found any recommendation regarding this at the SRP Wiki page > [1]. > I vaguely remember that this Smith project was initially driven by a French > guy who might try to push a French habit into the English world. ;-) Of course. Because, contrary to the world

Re: RFC: Better formatting for long descriptions

On Thu, 16 Apr 2009, Guillem Jover wrote: ,-- count-bullet-chars.sh -- #!/bin/sh lists=/var/lib/apt/lists/*_sid_main_*_Packages total=`grep "^ *[-+\*o] " $lists | wc -l` for tag in "\*" "-" "+" "o"; do items=`grep "^ *$tag " $lists | wc -l` percent=`echo "scale=4; $items / $total * 100" | bc`

Re: dash as default /bin/sh and bashisms-free archive RGs

On Wed, Apr 15 2009, Josselin Mouette wrote: > Policy documents practice. I wish people would not say that. It is not true; and hasn't been. And, moreover, we would not _want_ that to be true; there should be no excuse to justify wanting to enshrine broken or bad practices into policy.

Re: RFC: Better formatting for long descriptions

Hi! On Mon, 2009-03-23 at 13:26:36 +0100, Andreas Tille wrote: > On Mon, 23 Mar 2009, Michael Banck wrote: > > So it would be great if some numbers could be brought up first (maybe > > Andreas has a rough overview now, because he looked at the different > > kinds of itemizations). > > Well, I had

Re: [Debian-med-packaging] Bug#285398: muscle: package name conflicts with existing M.U.S.C.L.E. project

Hi Andreas, Le Tue, Apr 14, 2009 at 03:07:56PM +0200, Andreas Tille a écrit : > > once we are at renaming issues: IMHO we should simply close this bug report. > I fail to se a real problem here. There is only one binary /usr/bin/muscle > so there is no conflict regarding policy and the fact that

Bug#524286: general: kernel modules does not automatically load

On Thu, 2009-04-16 at 01:04 +0200, Luca Boncompagni wrote: > Package: general > Severity: normal > > Hi, > I try to open this as and udev bug (#524276) but Marco closed it because he > think that this is not an udev bug. > > Yesterday, after upgarding my system (aptitude update && aptitude > sa

Bug#524286: general: kernel modules does not automatically load

Package: general Severity: normal Hi, I try to open this as and udev bug (#524276) but Marco closed it because he think that this is not an udev bug. Yesterday, after upgarding my system (aptitude update && aptitude safe-upgrade && aptitude clean), when I restarted the system I was not able to

Re: Yes, we have bugs

2009/4/15 David Nusinow : > This is absurd. You agree that Hal fills an important need, yet you don't > like it because it's currently buggy? What the hell are you doing running I wrote that **an** abstraction layer is the way to go. I deem hal flawed by design, sorry about that, all my skills (n

Bug#524285: ITP: lv2dynparam1-2 -- lv2dynparam is a LV2 plugin interface extension

Package: wnpp Severity: wishlist Owner: "Jaromír Mikeš" * Package name: lv2dynparam1-2 Version : 2.0.0 Upstream Author : Nedko Arnaudov * URL : http://download.gna.org/lv2dynparam/ * License : GPL Programming Lang: C Description : lv2dynparam is a LV2

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

Julien Cristau writes: > On Wed, 2009-04-15 at 10:25 +0200, Bjørn Mork wrote: >> Well, you can always argue that the rest can be fixed. Provide patches >> etc. But the point is that hal implies a regression for many (most?) >> users. > > please stop the FUD. Sorry. You're right. That was unca

Re: dash as default /bin/sh and bashisms-free archive RGs

Josselin Mouette wrote: > Le mercredi 15 avril 2009 à 11:44 -0500, Raphael Geissert a écrit : [...] > >> And taking your statement to the extreme, it means that if zsh was used >> as /bin/sh then no other shell interpreter could ever be used as /bin/sh >> ever again but a fork of zsh. > > I’m pr

Re: Yes, we have bugs

Luca Niccoli wrote: 2009/4/15 David Nusinow : Please see the reply I just posted to the bug for a partial explanation of why using hal is important for more than just hotplugging. I'll be writing up a more complete explanation soon. I understand that hal fills an important gap in linu

Re: Yes, we have bugs

On Wed, Apr 15, 2009 at 11:02:16PM +0200, Luca Niccoli wrote: > 2009/4/15 David Nusinow : > > > Please see the reply I just posted to the bug for a partial explanation of > > why using hal is important for more than just hotplugging. I'll be writing > > up a more complete explanation soon. > > I

Re: Yes, we have bugs

2009/4/15 David Nusinow : > Please see the reply I just posted to the bug for a partial explanation of > why using hal is important for more than just hotplugging. I'll be writing > up a more complete explanation soon. I understand that hal fills an important gap in linux; I think that from an ar

Re: Yes, we have bugs

Le mercredi 15 avril 2009 à 22:26 +0200, Iustin Pop a écrit : > hal, AFAIK, is useful for users who don't want to customize systems; once you > start customizing, hal and similar tools more get in the way than help. HAL is merely an intermediate layer to help access underlying layers like udev usi

Re: Yes, we have bugs

Luca Niccoli wrote: But what if I don't need hotplugging? Why should I bear hal flaws if I don't need its features? Please see the reply I just posted to the bug for a partial explanation of why using hal is important for more than just hotplugging. I'll be writing up a more complete expla

Re: Yes, we have bugs

On Wed, Apr 15, 2009 at 09:57:25PM +0200, Tollef Fog Heen wrote: > ]] Luca Niccoli > > | But what if I don't need hotplugging? Why should I bear hal flaws if I > | don't need its features? > > A machine without USB or PCI is not a particularly common sight those > days. Heck, even machines with

Re: dash as default /bin/sh and bashisms-free archive RGs

Josselin Mouette writes: > Le mercredi 15 avril 2009 à 02:16 -0700, Russ Allbery a écrit : >> The advantage of the current Policy approach is that we have some hope >> of introducing a new /bin/sh down the road, and we don't require that >> packages comply with bugs in dash that should be fixed i

Re: dash as default /bin/sh and bashisms-free archive RGs

Le mercredi 15 avril 2009 à 11:44 -0500, Raphael Geissert a écrit : > > Policy documents practice. When that new /bin/sh exists, you can change > > bash is the current /bin/sh, from your statements I could imply that we > should require all /bin/sh's to support: b0rken bash arrrays, shell > regexe

Re: Yes, we have bugs

]] Luca Niccoli | But what if I don't need hotplugging? Why should I bear hal flaws if I | don't need its features? A machine without USB or PCI is not a particularly common sight those days. Heck, even machines without SATA are becoming uncommon. -- Tollef Fog Heen UNIX is user friendly, it'

Re: debian/copyright verbosity

Manoj Srivastava writes: > Tracking the potentially hundreds of files with © notices that > make up the binary or the libraries is not something I am likely to > do. People looking for that information can inspect the sources, or ask > upstream, directly. Or use fossology HTH -- To

Bug#524232: ITP: swordfish - High level key-value database with a RESTful HTTP interface

Package: wnpp Severity: wishlist Owner: Chris Lamb X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: swordfish Version : 0.1 Upstream Author : Chris Lamb * URL : http://chris-lamb.co.uk/projects/swordfish * License : GPL-3+ (server), BSD (client

Re: Yes, we have bugs

2009/4/15 Josselin Mouette : > Or maybe it is just that the Utopia maintainers, just like those of > Linux, KDE, GNOME, Mozilla or X.org, receive too many bug reports > compared to the amount they can handle. Bugs assigned to HAL are often > caused by buggy drivers or other kernel bugs, or they ne

Re: dash as default /bin/sh and bashisms-free archive RGs

Josselin Mouette wrote: > Le mercredi 15 avril 2009 à 02:16 -0700, Russ Allbery a écrit : >> > Actually it would be better to specify that scripts must work with both >> > sh implementations available in Debian, being bash and dash, rather >> > than making nothing more than a fork of the POSIX spe

Yes, we have bugs

Le mercredi 15 avril 2009 à 18:25 +0200, Luca Niccoli a écrit : > Is there a convenient way to measure how long a bug stays unanswered? > Or could someone suggest a better metric? > Because I have the feeling that many hal bugs are just kept undealt > (upstream as well), way more than with other pa

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[not CC-ing the RFA, I did it by mistake before and I don't think this is so relevant to that specific matter] 2009/4/15 Mike Hommey : > Bug count is not a good metric. Take a look at the bug count for linux-2.6, > glibc, iceweasel... Fair enough. Is there a convenient way to measure how long a

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

On Wed, Apr 15, 2009 at 05:58:49PM +0200, Luca Niccoli wrote: > 2009/4/12 Raphael Hertzog : > > > Expect grumpy people every time that you add something new that they have > > to learn. I also had troubles with hal and X when I tried the X servers in > > experimental. But I have not read any ser

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

2009/4/12 Raphael Hertzog : > Expect grumpy people every time that you add something new that they have > to learn. I also had troubles with hal and X when I tried the X servers in > experimental. But I have not read any serious criticism based on technical > facts in the bug report you showed. I

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

Le mercredi 15 avril 2009 à 10:25 +0200, Bjørn Mork a écrit : > False. All users want all things to work. The "just" is nice to have, > but not important. It's infinitely better to have to configure things > than not being able to. Bullshit. This is just true for nerds who want to spend their w

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

On Wed, 2009-04-15 at 10:25 +0200, Bjørn Mork wrote: > Well, you can always argue that the rest can be fixed. Provide patches > etc. But the point is that hal implies a regression for many (most?) > users. please stop the FUD. > hal breaks existing working configurations without warnings. The

Now Add Your Site ( Send Me Your Info )

Thank You Sir, We have added your website link here: * http://www.expertinseo.com/seo-packages.htm* Please edit our Link info and past this info : Please add the following details to your website. The details of our site are given below: *Title: *

Re: dash as default /bin/sh and bashisms-free archive RGs

Le mercredi 15 avril 2009 à 02:16 -0700, Russ Allbery a écrit : > > Actually it would be better to specify that scripts must work with both > > sh implementations available in Debian, being bash and dash, rather than > > making nothing more than a fork of the POSIX spec. > > The advantage of the c

Re: dash as default /bin/sh and bashisms-free archive RGs

Josselin Mouette writes: > It is not the role of the policy to specify the exact requirements of > the /bin/sh implementation. It is, however, the role of Policy to specify the minimum required feature set that all scripts can assume. > Actually it would be better to specify that scripts must w

Re: debian/copyright verbosity

ke, 2009-04-15 kello 10:33 +0200, Josselin Mouette kirjoitti: > Le mercredi 15 avril 2009 à 09:32 +1000, Ben Finney a écrit : > > Sune Vuorela writes: > > > > > I do wish that you would once try to look into the problems at hand > > > > That *is* what I'm doing. > > Obviously not. Maintainers k

Re: Bug#523794: ITP: php-version-control-svn -- wrapper interface for the Subversion command-line client

On Mon, Apr 13, 2009 at 05:00:57PM +0200, Bernd Zeimetz wrote: > Philipp Kern wrote: > > I also found svn to be not Ctrl-C-able at time. I don't know if that > > applies > > to other signals too but if so I can imagine quite some hanging processes > > on a server. > > Ack - I know this problem t

Re: dash as default /bin/sh and bashisms-free archive RGs

Le mardi 14 avril 2009 à 18:45 -0500, Raphael Geissert a écrit : > what feature provided by dash is being deprecated? > Like Russ said, if there's any feature not covered by policy that is > reasonable to be required please say so. It is not the role of the policy to specify the exact requirements

Re: debian/copyright verbosity

Le mercredi 15 avril 2009 à 09:32 +1000, Ben Finney a écrit : > Sune Vuorela writes: > > > I do wish that you would once try to look into the problems at hand > > That *is* what I'm doing. Obviously not. Maintainers keep explaining that your suggestions are not applicable, maybe you should try

Re: Bug#523093: undetermined copyright/license violation

On Wed, Apr 15, 2009 at 08:41:08AM +0200, Giacomo Catenazzi wrote: > Maybe taking derived code (e.g. including new code), one could write only > the license of aggregate work (thus one "later" license), I think so. I agree it could be better to list them explicitly, but upstream doesn't want that

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

Julien Cristau writes: > On Sun, 2009-04-12 at 14:04 +0200, Michael Meskes wrote: >> On Mon, Apr 06, 2009 at 09:55:39PM +0200, Michael Biebl wrote: >> > As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards >> > standardizing on one power management stack in Debian (and not i

Re: debian/copyright verbosity

+ Ben Finney (Wed, 15 Apr 2009 08:44:48 +1000): > Sune Vuorela writes: > > How is your work on a useful summary of kdebase-workspace going ? > I do wish this tiresome rhetorical non-argument would stop cropping up. > Are we not able to discuss the purpose of ‘debian/copyright’ without the > fal