Re: debian/copyright verbosity

[Adeodato Simó]

+ 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
> false dichotomy of “have you solved all the problems yet”?

In my opinion, it makes no sense to discuss the purpose of
debian/copyright in the abstract, that is, without having prominently in
mind what is that *we* can *sensibly* achieve. Anything else is mental
masturbation, and hopefully we’re not here for that.

I realize this may not fit your view of how things should be done, and I
understand such position, but at some point you’re going to need to
realize that sometimes a project can use one following suit better than
one’s own rightfulness. I know this by experience.

-- 
- Are you sure we're good?
- Always.
-- Rory and Lorelai


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Bjørn Mork]

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 install 3 by
>> > default [1]), i.e. I'd support in phasing out acpi-support and would gladly
>> > accept patches for hal and pm-utils which add (if there are) any missing 
>> > bits
>> > from acpi-support.
>> 
>> Not sure whether most users agree after reading #515214.
>
> 515214 isn't most users.  most users just want things to work.

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.

But I think you're on to the problem: It's true that hal makes most
things work.  The rest can't be made to work if you use hal.  Or at
least require you to configure a new, non-intuitive, complex system.

#515214 is about the rest, the way I read it.

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.  It provides no new (visible) funcionality, but adds complexity
and lots of bugs by making auto-configuration override previous local
configuration.   That's got to be wrong.

hal breaks existing working configurations without warnings.  The simple
test case is using a non-US keyboard properly configured as such in
xorg.conf.  Introduce evdev/hal and watch users get frustrated.  The
problem of course:  keyboard layout cannot be auto-configured.  But why
ignore existing configuration?

I still haven't got a clue how to really fix this, but have resorted to
this for now:



  

  pc105
  no

  


IMHO, this is an ugly hack.  I never wanted to configure hal.  I wanted
to configure X.  In fact, I already had a working X configuration so I
didn't expect to configure anything at all...

Yes, I expected things to "just work", given that it did prior to using
evdev/hal.  hal broke that expectation.

The same goes for the suspend/resume support.  I have an existing
working configuration, using acpi-support and pm-utils.  There is
absolutely no upside to me moving this to hal and some power-daemon.  It
just obfuscates the configuration, making GUI configuration utilities
mandatory and leaving me reading c++ bloat instead of some simple shell
script to find out why things didn't work as expected.

Just my .02 € as an ordinary user.



Bjørn


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#523093: undetermined copyright/license violation

[Robert Millan]

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.  Then again, see what I said in:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523093#38

> but I think:
> 1- the old code is still "2 or later"

It is.  Though, it is impractical to split it off the file that contains
mixed licenses.  But there's no need to either, people wanting the old code
can take it from Tomboy (assuming patent liability is not a problem for
them).

> 2- it is better not to mix licenses in one file, so it is better
>to add new code or with the same license or in an extra file
>(no problem removing part of old file)
> 3- Debian should allow the more liberal license as possible,
>thus maintaining the option to use the "old" license terms.

We already discussed about whether it's "good" or not to upgrade licenses or
to mix different GPL versions in the same file, in a separate thread in
-legal.  I gave my personal opinion there.  Btw the license change comes from
upstream, not Debian.  It's obvious Hubert has his own reasons for doing it,
but whichever they are they're off-topic here.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debian/copyright verbosity

[Josselin Mouette]

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 to understand that.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée

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

[Josselin Mouette]

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 of
the /bin/sh implementation.

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.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée

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

[Adam Borowski]

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 too well. the 'kill -9' axe is the only way to get 
> rid
> of svn processes in time, unfortunately.

All you did was preventing SVN from releasing locks.  As a long-time user, I
have yet to see an apparent lockup due to something else.  SVN uses a
brain-dead way of locking that takes age to clean up, but leaving them stale
is asking for trouble.  With that in mind, SVN's decision to always clean up
after a Ctrl-C rather than exit immediately is a sound one.

On the other hand, indeed, taking several minutes to abort an operation on a
project with 64k dirs 250k files in trunk is bad.  That's why most of us
have migrated to git.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debian/copyright verbosity

[Lars Wirzenius]

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 keep explaining that your suggestions are not
> applicable, maybe you should try to understand that.

As far as I can see, Ben is honestly trying to figure out what the
consensus is, while expressing his opinions as well. Although that has
led to some misunderstandings, it's unfortunate that some of those have
resulted in unnecessary harshness.

I, for one, have learned new things about how debian/copyright files are
currently used by the project.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

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 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 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 in dash.

-- 
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

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

[Josselin Mouette]

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 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 in dash.

Policy documents practice. When that new /bin/sh exists, you can change
the policy to require packages to comply with this new implementation.
It doesn’t change anything from the maintainers’ point of view, but it
avoids a useless work of formalization.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée

Now Add Your Site ( Send Me Your Info )

[expertinseo.com]

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: *SEO Packages

*Link :* http://www.expertinseo.com/seo-packages.htm

*Description :*Expert In SEO is Affordable SEO Company India, We offers
Professional SEO Services, Top SEO Company, SEO Expert, SEO Consultant, SEO
Specialist, SEO Companies, SEO Packages UK, USA, Australia, India & Canada.

Back Link : *http://www.expertinseo.com/link-exchange-seo-sem.htm


* Please do get back to us with your page URL where we can find our website
link.

are you interested OR not Inform Me First, I am waiting for your response.

Note : Please add this Community  : *
http://www.orkut.co.in/Community.aspx?cmm=58242374&mt=7*

Thank You,
Expert In SEO TEAM,
Link Builder,
www.expertinseo.com

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

[Julien Cristau]

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 simple
> test case is using a non-US keyboard properly configured as such in
> xorg.conf.  Introduce evdev/hal and watch users get frustrated.  The
> problem of course:  keyboard layout cannot be auto-configured.  But why
> ignore existing configuration?
> 
we don't ignore existing keymap configuration, and you get the same
layout after the upgrade as was configured in xorg.conf.

> I still haven't got a clue how to really fix this, but have resorted to
> this for now:
> 
> 
> 
>   
> 
>   pc105
>   no
> 
>   
> 
> 
> IMHO, this is an ugly hack.  I never wanted to configure hal.

that's fine, you don't have to.

>   I wanted
> to configure X.  In fact, I already had a working X configuration so I
> didn't expect to configure anything at all...
> 
> Yes, I expected things to "just work", given that it did prior to using
> evdev/hal.  hal broke that expectation.

no, it didn't.  you're just spreading nonsense.

Cheers,
Julien


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Josselin Mouette]

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 whole time
tweaking their computers. Remember, there are also people who use them
as tools.

> hal breaks existing working configurations without warnings.  The simple
> test case is using a non-US keyboard properly configured as such in
> xorg.conf.  Introduce evdev/hal and watch users get frustrated.  The
> problem of course:  keyboard layout cannot be auto-configured.  But why
> ignore existing configuration?

Existing configuration is not ignored. If you encounter a problem during
the upgrade, you can just send a bug report to console-setup; the bug
that occurred on my system was fixed in two days by the maintainers, so
you can’t say they ignore issues.

> The same goes for the suspend/resume support.  I have an existing
> working configuration, using acpi-support and pm-utils.  There is
> absolutely no upside to me moving this to hal and some power-daemon.  It
> just obfuscates the configuration, making GUI configuration utilities
> mandatory and leaving me reading c++ bloat instead of some simple shell
> script to find out why things didn't work as expected.

If the only thing you want is suspend/resume, you can replace the power
daemon with a simple script that talks to HAL using D-Bus. You would
also be disappointed at reading what the “C++ bloat” does on this
matter.

> Just my .02 € as an ordinary user.

Ordinary users don’t read shell scripts to find out why things don’t
work as expected.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée

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

[Luca Niccoli]

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 don't know if the fact that hal has 65 (sixty-five) outstanding bugs
(many of which lay unanswered, some since YEARS), plus 10 forwarded
bugs, qualifies as technical.
But it's a fact. And not of the most pleasing kind.
An other fact is that there is quite a big effort in the linux
community to achieve fast start up, since this will strongly push
linux spread on small devices like palmtops or netbooks.
Hal is often horribly slow to start, spending several seconds in
no-ops, just waiting for things to happen.
A third fact is: if there's something new to learn, ok, it takes time
but it's always good.
But I'll need documentation. Basically the only documentation in the
hal package are these lines:

HAL is a hardware abstraction layer


See http://www.freedesktop.org/Software/hal for lots of documentation,
mailing lists, etc.


Please note that at that address there are NOT lots of documentation.
There is something, mostly aimed at programmers.
(The hal-doc package, as well, contains documentation for the APIs)
I'm a user, pleased when things just work.
I'm less pleased when I have to configure things to make then work,
but I still feel it's ok.
When I have to depend on a piece of software that either works on it's
own, or it's impossible to configure, I start looking for that
well-known coloured window logo.
And I don't feel it's ok.

This is just my personal experience with hal; an experience that makes
me nostalgic of linux a couple of years ago. But I kind of feel I'm
not alone.
Cheers,

Luca


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Mike Hommey]

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 serious criticism based on technical
> > facts in the bug report you showed.
> 
> I don't know if the fact that hal has 65 (sixty-five) outstanding bugs
> (many of which lay unanswered, some since YEARS), plus 10 forwarded
> bugs, qualifies as technical.

Bug count is not a good metric. Take a look at the bug count for linux-2.6,
glibc, iceweasel...

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Luca Niccoli]

[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 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 packages, but it could be
just a feeling of course.
Anyway, I take back that point; I stand with the others:
I do think hal is an obscure, user unfriendly, hardly configurable system.
I see it is where a part of the community is heading, so we'll have to
live with that, until something better pops up; but users shouldn't be
forced to use it, when it isn't necessary.
I don't want my X server to wai 30 seconds to start, because it has to
wait for hal, when the rest of the system is ready in less then 10
seconds.
I feel xorg.conf it's a neat way to configure it, because I can do it
with a text editor, and I don't have all those XML tags in the way. If
I'll need sophisticated hot-plugging, I'll switch; but as long as I
don't need the feature, I don't want to pay the price, as Arjan van de
Ven put it.
Cheers,

Luca


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Yes, we have bugs

[Josselin Mouette]

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 packages, but it could be
> just a feeling of course.

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 need workarounds
specific to the hardware. They are clearly not the easiest to deal with.

We know there are a lot of unhandled reports. This is just a symptom of
our global lack of maintainers - that is, of maintainers willing to deal
with large packages, not only with their pet applet of 1kloc.

> I do think hal is an obscure, user unfriendly, hardly configurable system.
> I see it is where a part of the community is heading, so we'll have to
> live with that, until something better pops up; but users shouldn't be
> forced to use it, when it isn't necessary.

HAL is flawed for various reasons, and people have started to write a
much lighter replacement (devicekit). Nevertheless, it still does the
job correctly, and I’m happy that the last piece of the desktop that did
not correctly support hotplugging now does.

> I don't want my X server to wai 30 seconds to start, because it has to
> wait for hal, when the rest of the system is ready in less then 10
> seconds.

You must be joking. HAL is much faster to start than X, furthermore it
allows for asynchronous device detection, which means both can be
started in parallel. 

> I feel xorg.conf it's a neat way to configure it, because I can do it
> with a text editor, and I don't have all those XML tags in the way.

I agree the HAL FDI files’ syntax sucks, but they allow to directly ship
in packages a number of configuration snippets relevant to specific
hardware – this is how we can really improve out-of-the-box hardware
support.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée

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

[Raphael Geissert]

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 spec.
>> 
>> 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 in dash.
> 
> 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
regexes!, ${RANDOM,HOSTNAME,{E,}UID}, pushd, popd, let, exec -c/-l/-a, ...?

lots of those features are used in the wild, thus "practice."

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.

Policy is here, in part, to avoid such a mess and require/provide a sane
environment. And actually going in the opposite way you propose, I filed
#490604 a while ago to avoid such misconceptions.

> the policy to require packages to comply with this new implementation.
> It doesn’t change anything from the maintainers’ point of view, but it
> avoids a useless work of formalization.
> 

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Yes, we have bugs

[Luca Niccoli]

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 need workarounds
> specific to the hardware. They are clearly not the easiest to deal with.

Joss, I was explicitly asking if there is a better metric, and I
stated, both a line before your quote, and a line after, that the bug
count is not a fair way to measure the quality of a package.
Just to prevent a possible flame over the quality of hal maintainers'
work, which was not my aim at all.
I see that I could have been less aggressive in my mail, and that a
rant against hal maintainers can be read in it.
That was unintended, I'm sorry.
My point is different: hal is a pain for a lot of users. I don't blame
you nor anyone else.
But please, pretty please, don't force it on every one if it's avoidable.
[The rest of the mail is just more ranting on how hal sucks, skip it
if you like]

> HAL is flawed for various reasons, and people have started to write a
> much lighter replacement (devicekit). Nevertheless, it still does the
> job correctly, and I’m happy that the last piece of the desktop that did
> not correctly support hotplugging now does.

But what if I don't need hotplugging? Why should I bear hal flaws if I
don't need its features?

> You must be joking. HAL is much faster to start than X, furthermore it
> allows for asynchronous device detection, which means both can be
> started in parallel.

Maybe for your systems.
In on of mine, it waits several second for my empty cd drive to tell
it what it has inside.
On my netbook, it takes more than one second out of eleven in the boot
process: that makes 10%.
Gdm probably takes more, but it forks after ~0.2s, so the process can go on.
Anyway, with hal I have to wait for hal to start, and then for X to
start, and I can't start them in parallel.

> I agree the HAL FDI files’ syntax sucks, but they allow to directly ship
> in packages a number of configuration snippets relevant to specific
> hardware – this is how we can really improve out-of-the-box hardware
> support.

I'm not saying that this shouldn't be possible, just that users
shouldn't be forced to use it.
Cheers,

Luca


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Chris Lamb]

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)
   Programming Lang: C / Python
   Description : High level key-value database with a RESTful HTTP
 interface

 Swordfish is a persistent database which uses JavaScript Object Notation
 (JSON) over HTTP. It was designed to complement a relational database
 used in modern web applications by providing a means to denormalise
 (and thus avoid) computationally expensive JOIN operations.

 To this end, Swordfish's primary data structure is a dictionary with
 ordered keys and provides functionality for atomically manipulating and
 querying these structures, including set-based operations such as
 intersection and difference.

 Swordfish also provides a QuerySet-like API for projects using the
 Django web development framework.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org
   `-


signature.asc
Description: PGP signature

Re: debian/copyright verbosity

[Dominique Dumont]

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 UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Yes, we have bugs

[Tollef Fog Heen]

]] 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's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Josselin Mouette]

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
> regexes!, ${RANDOM,HOSTNAME,{E,}UID}, pushd, popd, let, exec -c/-l/-a, ...?

> lots of those features are used in the wild, thus "practice."

> 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 proposing to do the exact opposite. But I see you are only
interested in trolling, not in discussing options.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée

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

[Russ Allbery]

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 in dash.

> Policy documents practice. When that new /bin/sh exists, you can change
> the policy to require packages to comply with this new implementation.
> It doesn’t change anything from the maintainers’ point of view, but it
> avoids a useless work of formalization.

I think the current approach is better, and the formalization hasn't been
that much work.  The current approach has the significant advantage of
letting one write checking programs, such as lintian, against a standard
instead of against ad hoc practices.

-- 
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

Re: Yes, we have bugs

[Iustin Pop]

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 without SATA are becoming uncommon.

My desktop machine with USB, PCI, SATA, eSATA, PCIe and Firewire. And it runs
happily, supports hotplugging devices, *without* hal.

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.

Just my oppinion. Everyone is of course entitled to disagree.

regards,
iustin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Yes, we have bugs

[David Nusinow]

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 explanation soon.


- David Nusinow


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Yes, we have bugs

[Josselin Mouette]

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 using D-Bus. It is unrelated to the level of customization you
want to apply. I don’t know what you’d expect it to do, but it is
probably more related to the frontends (like gnome-power-manager and
nautilus, or their KDE equivalents).

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Yes, we have bugs

[Luca Niccoli]

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 architectural point of view, an abstraction layer is the way
to go.
The problem is that, in my experience, hal is a horrible piece of
software. It makes my (computing) life worse. Its obscure, erratic
behaviour and the lack of documentation make me feel like when I was
using windows 98. (ok, not *that* bad, but kind of)
I am willing to pay the price to avoid it as long as possible
(hopefully it will get better, or replaced, in the future), and since
it looks like it's possible ATM, I would really be happy if X did not
depend on that.
(I see you've written that probably X dependency on hal will be
demoted, I appreciate.)

2009/4/15 Tollef Fog Heen :

> A machine without USB or PCI is not a particularly common sight those
> days.  Heck, even machines without SATA are becoming uncommon.

I should have stated more clearly that I meant hot plugging for X.
I hotplug my USB disks since when hal didn't exist.
I never hot plugged a SATA disk, but I don't think you need hal to do that.
Anyway, you are being PC-centric. Debian is getting on many low power
devices that often don't have USB, nor PCI, nor SATA, though they have
a graphical interface (e.g. mobile phones).
And a bloat like hal hurts even more there.

Cheers,

Luca


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Yes, we have bugs

[Mike Hommey]

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 understand that hal fills an important gap in linux; I think that
> from an architectural point of view, an abstraction layer is the way
> to go.
> The problem is that, in my experience, hal is a horrible piece of
> software. It makes my (computing) life worse. Its obscure, erratic
> behaviour and the lack of documentation make me feel like when I was
> using windows 98. (ok, not *that* bad, but kind of)
> I am willing to pay the price to avoid it as long as possible
> (hopefully it will get better, or replaced, in the future), and since
> it looks like it's possible ATM, I would really be happy if X did not
> depend on that.
> (I see you've written that probably X dependency on hal will be
> demoted, I appreciate.)
> 
> 2009/4/15 Tollef Fog Heen :
> 
> > A machine without USB or PCI is not a particularly common sight those
> > days.  Heck, even machines without SATA are becoming uncommon.
> 
> I should have stated more clearly that I meant hot plugging for X.
> I hotplug my USB disks since when hal didn't exist.
> I never hot plugged a SATA disk, but I don't think you need hal to do that.
> Anyway, you are being PC-centric. Debian is getting on many low power
> devices that often don't have USB, nor PCI, nor SATA, though they have
> a graphical interface (e.g. mobile phones).
> And a bloat like hal hurts even more there.

Maybe you missed the part where X without hal is actually the bloat.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=91;bug=515214

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Yes, we have bugs

[David Nusinow]

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 linux; I think that
from an architectural point of view, an abstraction layer is the way
to go.
The problem is that, in my experience, hal is a horrible piece of
software. It makes my (computing) life worse. Its obscure, erratic
behaviour and the lack of documentation make me feel like when I was
using windows 98. (ok, not *that* bad, but kind of)
I am willing to pay the price to avoid it as long as possible
(hopefully it will get better, or replaced, in the future), and since
it looks like it's possible ATM, I would really be happy if X did not
depend on that.

  


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 unstable if not helping to develop the operating system? If 
there's bugs then we need to find and fix them. If there's a lack of 
docs, that's a bug and they need to be written. But by saying you don't 
want us to fulfill a major need in the OS is basically saying that you 
don't want Debian to develop any more. If that's the way you feel, then 
I don't think you should be running unstable and posting to debian-devel.


- David Nusinow


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Raphael Geissert]

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 proposing to do the exact opposite. But I see you are only
> interested in trolling, not in discussing options.
> 

Then there must be some sort of missunderstanding. My intention was not to
troll, but to demonstrate the implications of what you said. I would like
to apologise for my previous message as I had understood something
completely from what you really said, sorry.

But I anyway don't think it is the appropriate way to do it.
You are assuming that only bash and dash are suitable as /bin/sh, while IIRC
zsh, mksh, pdksh, posh, and probably some other shell interpeter out there
are all policy compliant and thus suitable for /bin/sh (ksh isn't since it
doesn't support local variables).
So, may I ask why would requiring scripts to work with bash and dash and not
the others is fair?
I'd prefer to stick with the standards.

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Bjørn Mork]

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 uncalled for.  The introduction of hal
has caused a few new problems for me, but I don't know anything about
most users.

My list of hal related regressions are
a) laptop keys remapped or disappearing (might be caused by the driver -
   I don't know)
b) unwanted auto-mounting
c) the keyboard problem described below



>> hal breaks existing working configurations without warnings.  The simple
>> test case is using a non-US keyboard properly configured as such in
>> xorg.conf.  Introduce evdev/hal and watch users get frustrated.  The
>> problem of course:  keyboard layout cannot be auto-configured.  But why
>> ignore existing configuration?
>> 
> we don't ignore existing keymap configuration, and you get the same
> layout after the upgrade as was configured in xorg.conf.

OK.  I did not.  But I guess that's something that's changed with recent
console-setup changes?  Some testing now reveals that you're right: I
now get a Norwegian keyboard layout for every keyboard like device no
matter what I write in xorg.conf.

That's still confusing to me.  I did manage to locate the settings in
/etc/default/console-setup.  But it's still unclear how to handle
multiple input devices using this facility.

Not that it matters much, but I find it a bit strange that the
"ThinkPad Extra Buttons" and "Video Bus" devices are configured as 105
keys keyboards with Norwegian layout:


(**) ThinkPad Extra Buttons: always reports core events
(**) ThinkPad Extra Buttons: Device: "/dev/input/event8"
(II) ThinkPad Extra Buttons: Found keys
(II) ThinkPad Extra Buttons: Configuring as keyboard
(II) XINPUT: Adding extended input device "ThinkPad Extra Buttons" (type: 
KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105"
(**) Option "xkb_layout" "no"
(**) Option "xkb_options" "lv3:ralt_switch"
(II) config/hal: Adding input device AT Translated Set 2 keyboard
(**) AT Translated Set 2 keyboard: always reports core events
(**) AT Translated Set 2 keyboard: Device: "/dev/input/event1"
(II) AT Translated Set 2 keyboard: Found keys
(II) AT Translated Set 2 keyboard: Configuring as keyboard
(II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: 
KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105"
(**) Option "xkb_layout" "no"
(**) Option "xkb_options" "lv3:ralt_switch"
(II) config/hal: Adding input device Video Bus
(**) Video Bus: always reports core events
(**) Video Bus: Device: "/dev/input/event5"
(II) Video Bus: Found keys
(II) Video Bus: Configuring as keyboard
(II) XINPUT: Adding extended input device "Video Bus" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105"
(**) Option "xkb_layout" "no"
(**) Option "xkb_options" "lv3:ralt_switch"


>> I still haven't got a clue how to really fix this, but have resorted to
>> this for now:
>> 
>> 
>> 
>>   
>> 
>>   pc105
>>   no
>> 
>>   
>> 
>> 
>> IMHO, this is an ugly hack.  I never wanted to configure hal.
>
> that's fine, you don't have to.

You're right.  This seems to be taken care of by console-setup now.  It
was not when I created this file (which I did not do just for fun,
although writing XML config files is my idea of a fun night :-)

>>   I wanted
>> to configure X.  In fact, I already had a working X configuration so I
>> didn't expect to configure anything at all...
>> 
>> Yes, I expected things to "just work", given that it did prior to using
>> evdev/hal.  hal broke that expectation.
>
> no, it didn't.  you're just spreading nonsense.

I think we might have different interpretations of "work".  

Suddenly ignoring xorg.conf changes in favour of a new config file
without any clear (to me at least) indication how to restore previous
behaviour is
 1) unexpected
 2) broken


IMHO.  You are of course free to have a different opinion.  I just
wanted to register mine.


Bjørn


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Jaromír Mikeš]

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 plugin interface extension

enables plugin
parameters to appear and disappear (i.e. number of voices). It also
allows nested grouping of parameters. Groups can be used for things
like ADSR abstraction, i.e. group of 4 float parameters.
The extension consists of a header describing the extension interface
and libraries, one for plugins and one for hosts, to expose
functionality in more usable, from programmer point of view,
interface.

-- System Information:
Debian Release: lenny/sid
  APT prefers hardy
  APT policy: (500, 'hardy')
Architecture: i386 (i686)

Kernel: Linux 2.6.29-1-multimedia-686 (SMP w/1 CPU core; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Yes, we have bugs

[Luca Niccoli]

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 (not that
impressive indeed) and will wouldn't help a scrap.

> unstable if not helping to develop the operating system? If there's bugs
> then we need to find them and fix them.

I don't think the lack of bug reports is the one problem affecting hal.
That said, I report bugs when I find them and they're not already in the BTS.
I send patches when I like the software enough, and I'm good enough
(neither of these is the case with hal).

> and they need to be written. But by saying you don't want us to fulfill a
> major need in the OS is basically saying that you don't want Debian to
> develop any more. If that's the way you feel, then I don't think you should
> be running unstable and posting to debian-devel.

I think I (and the other people who are against X dependency on hal)
have been pretty clear on the fact that we would just like an
alternative, not to kick hal away (we're not stupid nor crazy). I
think this would be good for debian.
I see you want to drag this in a flame, so I step back, I can live
with equivs as long as possible instead of wasting my time writing
emails.
So long,

Luca

P.S.
Check your line wrap.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Luca Boncompagni]

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 use the mouse.
If I load the psmouse manually it works.

I have the same problem with all the other devices of my system (wlan, 
soundcard and webcam)

Thanks,
Luca

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.29-1-686 (SMP w/1 CPU core)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Ben Hutchings]

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 
> safe-upgrade && aptitude clean), when I restarted the system I was not able 
> to use the mouse.
> If I load the psmouse manually it works.
> 
> I have the same problem with all the other devices of my system (wlan, 
> soundcard and webcam)

It sounds as if depmod may have failed.  What files are there in the
/lib/modules/2.6.29-1-686/ directory?  Are any of them zero-length?

Ben.



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

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

[Charles Plessy]

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 package names
> are quite similar is not really nice but they are definitely distinguishable
> via short description and so I would like to close this bug.

Agreed. Although I would name the package muscle-align if it were new, I do not
think that a renaming is worth the effort.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: Better formatting for long descriptions

[Guillem Jover]

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 not but you can get it somehow by
>
> for tag in "\*" "-" "+" "o" ; do
> echo "Tag $tag was used `grep "^  $tag " /var/lib/dpkg/available | wc -l` 
> times"
> done
>
> Tag \* was used 5647 times
> Tag - was used 2710 times
> Tag + was used 85 times
> Tag o was used 282 times
>
> which only counts those who have proper spacing - but for a rough estimation
> '*' wins definitely.

Even if we'd have to fix all the entries with wrong spacing anyway to
reach correctness, I was curious to see numbers for all spacing variants
for a wider representation of the characters used:


,-- 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`
  echo "Tag $tag was used $items times ($percent%)"
done
`--

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 recommendations from the Smith reviewing
project), I've always found the asterisk the obvious character to use
for bulleted lists, as it's the one ressembling the most a bullet, and
it's the one we use in changelog entries and similar.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Manoj Srivastava]

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.

Policy should document what is right.

Now, having said that, it is often not clear what is right, or
 what is the best practice, or what might work a priori. Often policy is
 where we decide to take one of several technically feasible approaches,
 and we do so to make integration feasible.

Which is why, often we would not like to do Design work in
 policy, since usually design is modified during implementation and by
 feedback from early adopters; so adding things to policy, polishing up
 the language, handling the corner cases, is lost labour if we need to
 change the design later on.

While this means that policy is conservative, and would rather
 wait until a design/practice has passed the test of time; it does not
 mean policy documents current practice willy-nilly. 

If current practice is broken, or suboptimal, policy should not
 document that. If doing something different it the right approach,
 policy should document that instead. *of course* care should be taken
 to put in a transition plan, and not make lots of packages insta-buggy,
 but we in -policy have some experience doing just that.

So, no, policy does not just document current practice. Policy
 tries to document what is right.  The correlation with our best guess at
 what is right and current practice is high, which is to be expected of
 a distribution we are trying to make the best in the world.

manoj
-- 
news: gotcha
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: Better formatting for long descriptions

[Andreas Tille]

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`
 echo "Tag $tag was used $items times ($percent%)"
done
`--

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 recommendations from the Smith reviewing
project),


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. ;-)
Do you have any link to those recommendation which perhaps should be fixed
in the first place.  IMHO the Smith Review Project would be a first place
were we could start kind of a standardisation of this issue - it seems there
is no "stronger" place to move this suggestion to.


I've always found the asterisk the obvious character to use
for bulleted lists, as it's the one ressembling the most a bullet, and
it's the one we use in changelog entries and similar.


I perfectly agree here.  Even if I tend to a "I do not care about the actual
character we use as long as it is a defined one" opinion the statistics above
shows clearly a preference and we should turn this preference in a
recommendation and ask people to stick to this recommendation.

So could we settle down with the agreement:

  '  * '   for first order lists and
  '- ' for second order lists.

I would like to push this to SRP *and* "6.2. Best practices for debian/control"
of developers reference.  This would finally allow us to file wishlist bug
reports against packages which do not follow this recommendation.

Kind regards

 Andreas.


[1] http://wiki.debian.org/I18n/SmithReviewProject

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Christian Perrier]

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 of English language, we *do*
have written rules for such cases. From the "Lexique des règles
typographiques en usage à l'Imprimerie Nationale" (which is the
reference for all typographic conventions for the French languagethe
reference book of all French TeXnicians) :

Les énumérations

- elles sont introduites par un deux-points ;
- les énumérations de premier rang sont introduites par un tiret et
se terminent par un point-virgule, sauf la dernière par un point final ;
- les énumérations de second rang sont introduites par un tiret
décalé et se terminent par une virgule.


Which (badly) translates to:

Itemizations:
- they're introduced by a colon;
- first degree itemizations are preceeded by a dash and end with a
semi-colon, except the last one that ends up with a sentence dot;
- second degree itemizations are preceeded by a tabbed dash and end
up with a comma.


I have never been able to find any such solid reference for English.
There is probably something in the Chicago Manual of Style, that's
generally accepted as the Right Reference for en_US.

Maybe more input from our experts on debian-l10n-english?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: Better formatting for long descriptions

[Manoj Srivastava]

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 recommendations from the Smith reviewing
> project), I've always found the asterisk the obvious character to use
> for bulleted lists, as it's the one ressembling the most a bullet, and
> it's the one we use in changelog entries and similar.

The primary goal of the description is to convey to the user why
 they should install the package. The maintainer can use an unsorted
 list to help convey the information; and any means that make it clear
 to the user that they are looking at a list is good enough.

Anything beyond that seems like striving for a foolish
 consistency; and the basic assumption being made (which does
 not, in my opinion, hold) is that a rigid monotonic conformity is
 aesthetically pleasing. I think a variety in the symbols used for
 bullets is better, in that it breaks the monotony.

Do we really have nothing better to do than to impose
 bureaucratic rules on what characters to use as bullet symbols in long
 descriptions even if the user can tell that the character is a bullet?

manoj

-- 
Slowly and surely the unix crept up on the Nintendo user ...
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org