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

[Lars Wirzenius]

to, 2009-04-16 kello 08:42 +0200, Christian Perrier kirjoitti:
> 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?

I'm not an expert, but I have the 14th edition of the CMS. It says both
bullets and dashes are acceptable (8.77, page 314, for reference).

(I am not expressing an opinion for or against the normalization of long
description markup.)


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

As the economy struggles, you can thrive

[Power Marketing Team]

By reserving a top spot in our global home business, you will be above 
thousands of others soon joining.

As the economy struggles, you can thrive:  
http://alive7.myintensivesuccess.in/?b=ZGViaWFuLWRldmVsQGxpc3RzLmRlYmlhbi5vcmc
 

Thank you,
M. Gold


 
 
 
 
 
 
 
 
 
 
 
 
 
The quality of your work, in the long run, is the deciding factor on how much 
your services are valued by the world [Orison Swett Marden]




This message was sent by user: alive7 on our system.
To be removed or report abuse click below.


Power Marketing Team
#1776 PO Box 13240,Johnsonville,Wellington NZ 6440

http://alive7.myintensivesuccess.in/rm/?b=ZGViaWFuLWRldmVsQGxpc3RzLmRlYmlhbi5vcmc



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

Re: Item lists bulletting

[Manoj Srivastava]

On Thu, Apr 16 2009, Christian Perrier wrote:

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

Perhaps such rigidity is the reason the Lingua Franca around the
 world has come to be English? :-)

I really do not think that needless consistency is something we
 should pursue. Indeed, I'll go and scable the bullet symbols I use for
 unsorted lists to get away from the mind numbingly boring consistency,
 and provide some variety for my readers.

manoj
-- 
A well-known friend is a treasure.
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, Manoj Srivastava wrote:


   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?


The user can tell, but scripts can't reliably.  Long descriptions are
used in several places and some of these could render a better layout.
A good layout is pleasing for users.  So it is not stupid bureaucracy
but making our descriptions better readable (for instance on packages.d.o
and other places).

Kind regards

Andreas.

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

Re: RFC: Better formatting for long descriptions

[Manoj Srivastava]

On Thu, Apr 16 2009, Andreas Tille wrote:

> On Thu, 16 Apr 2009, Manoj Srivastava wrote:
>
>>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?
>
> The user can tell, but scripts can't reliably.


Any script should be able to take the top 4 symbols currently
 used, and be able to detect them. I think *, +, - and o  cover most
 packages, and the scripts in question can be readily expanded. All
 kinds of markup languages already do something similar. (markdown,
 Emacs org-mode, mediawiki, etc)

> Long descriptions are used in several places and some of these could
> render a better layout.

Functionally, just rendering the description as written would
 suffice; the rest is aesthetics.

>  A good layout is pleasing for users.  So it

Pleasing is in the eye of the beholder, no?

> is not stupid bureaucracy but making our descriptions better readable
> (for instance on packages.d.o and other places).

I find the descriptions on packages.d.o just fine right now.

Having sad that, I would not be averse to specifying that leading
 white space and  *, +, and -  would be acceptable as bullet marks (I
 thought specifying which mark at which level was overspecification).

manoj
-- 
A man convinced against his will is of the same opinion still.  --
Butler
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, Manoj Srivastava wrote:


   Any script should be able to take the top 4 symbols currently
used, and be able to detect them. I think *, +, - and o  cover most
packages, and the scripts in question can be readily expanded. All
kinds of markup languages already do something similar. (markdown,
Emacs org-mode, mediawiki, etc)


Perhaps you missed the point that it is not only the very character
which is used but also the broken spacing which prevents scripts from
detecting levels of itemizing list.

Yes, we have more than one level itemizings in our descriptions (see
my initial posting.  Detecting these would need either a defined
character or a defined spacing (IMHO an 'and' would be better than
a non-exclusive 'or' here).


   I find the descriptions on packages.d.o just fine right now.


IMHO it is no argument that a specific person is happy with the layout
everybody else is.  If a text has a certain logic it should to be supported
by the means a certain output style has.  HTML can express a list and
so it should if we want to express lists.


   Having sad that, I would not be averse to specifying that leading
white space and  *, +, and -  would be acceptable as bullet marks (I
thought specifying which mark at which level was overspecification).


So you would be in favour of specifying only the amount of white space
to define a level?  If this might be accepted as a rough consensus it
is at least helpful to enable tools detecting what they need to detect.
Even if my esthetical feeling goes beyond this I can accept this.  But
you also specified three characters (*, +, and -) so do you want to
restrict the acceptable set yourself (for instance not accept 'o')?

Kind regards

Andreas.

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

Re: RFC: Better formatting for long descriptions

[Michael Banck]

On Thu, Apr 16, 2009 at 02:34:52AM -0500, Manoj Srivastava wrote:
> Having sad that, I would not be averse to specifying that leading
>  white space and  *, +, and -  would be acceptable as bullet marks (I
>  thought specifying which mark at which level was overspecification).

Why don't we say binaries are fine in /usr/bin, /usr/local/bin and /opt
while we are at it, to provide some refreshing alternatives to our
users?


Michael


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

[Gabor Gombas]

On Wed, Apr 15, 2009 at 10:25:36AM +0200, Bjørn Mork wrote:

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

...except with latest hal/X.org/whatever it also stopped working. Latest
X.org pulled in console-setup, and now the settings under
/etc/hal/fdi/policy get ignored. What a mess.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
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 Thu, Apr 16 2009, Andreas Tille wrote:

> On Thu, 16 Apr 2009, Manoj Srivastava wrote:
>
>>Any script should be able to take the top 4 symbols currently
>> used, and be able to detect them. I think *, +, - and o  cover most
>> packages, and the scripts in question can be readily expanded. All
>> kinds of markup languages already do something similar. (markdown,
>> Emacs org-mode, mediawiki, etc)
>
> Perhaps you missed the point that it is not only the very character
> which is used but also the broken spacing which prevents scripts from
> detecting levels of itemizing list.
>
> Yes, we have more than one level itemizings in our descriptions (see
> my initial posting.  Detecting these would need either a defined
> character or a defined spacing (IMHO an 'and' would be better than
> a non-exclusive 'or' here).

Umm. I am not sure that follows. I am also not convinced we need
 to invent our own rules. Text::Markdown or Text::MultiMarkdown could
 help. And they do not seem to have issues with recognizing
 indentation/different characters as denoting levels of lists.

>
>>I find the descriptions on packages.d.o just fine right now.
>
> IMHO it is no argument that a specific person is happy with the layout
> everybody else is.

Just like it  is no argument that someone think something is ugly
 that means everyone thinks so too.

>  If a text has a certain logic it should to be
> supported by the means a certain output style has.  HTML can express a
> list and so it should if we want to express lists.

And we do not need to specify any more rigid rules than
 established systems like markdown do in order to achieve that. Indeed,
 we can just pipe the description though markdown, and use the html

>
>>Having sad that, I would not be averse to specifying that leading
>> white space and  *, +, and -  would be acceptable as bullet marks (I
>> thought specifying which mark at which level was overspecification).
>
> So you would be in favour of specifying only the amount of white space
> to define a level?

You do not have to specify the level. Just that the indentation
 be sufficient for the user or markdown to be able to differentiate what
 level the item is at. 

> If this might be accepted as a rough consensus it is at least helpful
> to enable tools detecting what they need to detect.  Even if my
> esthetical feeling goes beyond this I can accept this.  But you also
> specified three characters (*, +, and -) so do you want to restrict
> the acceptable set yourself (for instance not accept 'o')?

I suggest we follow a convention and tool set already in place,
 with multiple language bindings, if you must insist on adding rules to
 the long description.

There are alternatives (Text::Textile comes to mind), but
 Markdown has better language support, so long description parsers might
 have an easier time.

I suggest, for readability, to use a subset of markdown; the
 link and image tags are not that human readable.

manoj

 http://en.wikipedia.org/wiki/Markdown
 http://markdown.infogami.com/
 http://daringfireball.net/projects/markdown/syntax

-- 
Man's horizons are bounded by his vision.
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

[Ben Finney]

(following up on IRC discussion)

Manoj Srivastava  writes:

> I suggest we follow a convention and tool set already in place,
>  with multiple language bindings, if you must insist on adding rules to
>  the long description.
> 
> There are alternatives (Text::Textile comes to mind), but
>  Markdown has better language support, so long description parsers might
>  have an easier time.
> 
> I suggest, for readability, to use a subset of markdown; the
>  link and image tags are not that human readable.

reStructuredText http://docutils.sourceforge.net/rst.html> (reST)
is, I argue, a superior choice to Markdown for our existing format.

Markdown explicitly assumes the writer is going to punt to HTML for
anything not covered by Markdown, which severely limits its future
flexibility in contexts where we don't want to put HTML in the source.

reST, on the other hand, makes no such assumptions about enclosing
context; it was initially designed for documentation in program source
code, which is much closer to our needs for text in a control field.

It also helps that the simple bullet lists that are the most common case
are perfectly valid in reST too.

-- 
 \   “Never express yourself more clearly than you are able to |
  `\   think.” —Niels Bohr |
_o__)  |
Ben Finney


-- 
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, Manoj Srivastava wrote:


my initial posting.  Detecting these would need either a defined
character or a defined spacing (IMHO an 'and' would be better than
a non-exclusive 'or' here).


   Umm. I am not sure that follows. I am also not convinced we need
to invent our own rules.


I tried to suggest *any* rule which works.  I'm not in favour of invanting
new rules.  But the rules should be simple enough to not break any existing
tool.


Text::Markdown or Text::MultiMarkdown could
help. And they do not seem to have issues with recognizing
indentation/different characters as denoting levels of lists.


If I interpret your first link [1] right this are even *more* rules as
I suggested.


   I find the descriptions on packages.d.o just fine right now.


IMHO it is no argument that a specific person is happy with the layout
everybody else is.


   Just like it  is no argument that someone think something is ugly
that means everyone thinks so too.


 If a text has a certain logic it should to be
supported by the means a certain output style has.  HTML can express a
list and so it should if we want to express lists.


Please do not split my paragraphs to blur my arguing.  Thanks.


   And we do not need to specify any more rigid rules than
established systems like markdown do in order to achieve that. Indeed,
we can just pipe the description though markdown, and use the html


Have you tested this suggestion whether the current long descriptions will
render correctly?


So you would be in favour of specifying only the amount of white space
to define a level?


   You do not have to specify the level. Just that the indentation
be sufficient for the user or markdown to be able to differentiate what
level the item is at.


I'm sorry - I do not know markdown whether it is clever enough to render
the lists in all long descriptions.  But as long as the hint "please
make sure that your long description renders with markdown" is not
written in any of our documents I really doubt that.  May I draw the
conclusion that you are also in favour of some rules but not really
happy with the rules I suggested?  That's really fine for me.  I just
want *any* rule which *works* and is written down somewhere to enable
us filing bug reports against packages which do not follow this rule.
I think I mentioned this in my postings of this thread.


   I suggest we follow a convention and tool set already in place,
with multiple language bindings, if you must insist on adding rules to
the long description.

   There are alternatives (Text::Textile comes to mind), but
Markdown has better language support, so long description parsers might
have an easier time.


I do not want any complicated tool to parse our long descriptions.
In principle they are really easy to parse.  I want to have the
simplest possible rule set which enables us to reliable parse the
logic of our long descriptions.  While you claim to be against rules
you propose even harder to apply rules.  At least for me your suggestions
are confusing and just bluring the issue.


   I suggest, for readability, to use a subset of markdown; the
link and image tags are not that human readable.


Yes - that's perfectly fine.  We are just using a subset of markdown
actually - a much simpler one than the suggested, without features like
italics and strong, headings etc.  And we do not really need it - we
just should keep it simple to not break any existing tool.  If there
is a library which reliably can detect the logic of the current long
descriptions probably nothing has to be changed.  But I doubt there is
one and I really wonder why anybody who is happy with the current rendering
is suggesting even more complex things.

Kind regards

Andreas.

[1] http://en.wikipedia.org/wiki/Markdown

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

Re: Yes, we have bugs

[Josselin Mouette]

Le jeudi 16 avril 2009 à 01:25 +0200, Luca Niccoli a écrit :
> 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.

If you want an alternative with a better design, you should seriously
consider porting X.org to use DeviceKit instead of HAL. This will
probably require vast improvements to DK, but it would benefit to
everyone.

Of course, this is harder to do than whining on mailing lists.

-- 
 .''`.  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 mercredi 15 avril 2009 à 23:05 -0500, Manoj Srivastava a écrit :
> So, no, policy does not just document current practice. Policy
>  tries to document what is right.

I think it should be both. When we do things right, they should be
specified in the Policy, and there’s no point specifying what is right
if nothing implements it.

-- 
 .''`.  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: RFC: Better formatting for long descriptions

[Tzafrir Cohen]

On Thu, Apr 16, 2009 at 04:01:20AM -0500, Manoj Srivastava wrote:

> Umm. I am not sure that follows. I am also not convinced we need
>  to invent our own rules. Text::Markdown or Text::MultiMarkdown could
>  help. And they do not seem to have issues with recognizing
>  indentation/different characters as denoting levels of lists.

Character-level formatting of markdown as well?

Two examples:

* From abcmidi:

 This package contains the programs `abc2midi' and `midi2abc',  which

* From alltray:

 KDE, XFCE 4*, Fluxbox* and WindowMaker*.
 (*) No drag 'n drop support. Enable with "-nm" option.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend


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

[Ben Finney]

Ben Finney  writes:

> (following up on IRC discussion)
> 
> Manoj Srivastava  writes:
> 
> > I suggest, for readability, to use a subset of markdown; the
> >  link and image tags are not that human readable.
> 
> reStructuredText http://docutils.sourceforge.net/rst.html> (reST)
> is, I argue, a superior choice to Markdown for our existing format.

Note that, like Manoj, I'm suggesting only a *subset*, not the full
specification.

-- 
 \“Like the creators of sitcoms or junk food or package tours, |
  `\ Java's designers were consciously designing a product for |
_o__)   people not as smart as them.” —Paul Graham |
Ben Finney


-- 
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 jeudi 16 avril 2009 à 00:34 +0200, Bjørn Mork a écrit :
> My list of hal related regressions are
> a) laptop keys remapped or disappearing (might be caused by the driver -
>I don't know)

Yes, they are remapped to the standard XF86* names, so that applications
configuring shortcuts can have sensible defaults.

> b) unwanted auto-mounting

HAL will not do auto-mounting by itself. Some user-level daemon must be
listening for events and requesting the actual mount.

-- 
 .''`.  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 mercredi 15 avril 2009 à 17:12 -0500, Raphael Geissert a écrit :
> 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.

I said:

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.

What you seemed to have understood is very unclear, but since it implies
supporting forever the whole bash feature set in the /bin/sh
interpreter, I don’t really want to know what it is.

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

No, they are not suitable. We can’t decently support gazillions of
implementations, and there is absolutely zero need to do so.

> So, may I ask why would requiring scripts to work with bash and dash and not
> the others is fair?

There’s no point being fair. Shell interpreters are not humans, we don’t
have to treat them all equally. We need one /bin/sh interpreter, we need
to ensure that it is good, and that all /bin/sh scripts we ship will
work with it. Everything else is pure masturbation.

> I'd prefer to stick with the standards.

It’s the role of the dash maintainers to ensure the implementation
follow standards. Not the role of the policy.

What would you think if the policy started to specify which constructs
exactly scripts with a /usr/bin/perl shebang are allowed to use, and
what the perl implementation needs to implement? 

-- 
 .''`.  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: RFC: Better formatting for long descriptions

[Andreas Tille]

On Thu, 16 Apr 2009, Ben Finney wrote:


Note that, like Manoj, I'm suggesting only a *subset*, not the full
specification.


Well, in this thread we had several suggestions reaching from complete
change to different format up to "not in detail specified" subsets of
other formats.  IMHO this does not bring us foreward a single step.
If we want to move foreward we have to make sure that we will not be
forced to touch every single package because such an intend will be
bound to fail and every minute spended in discussion here is simply
wasted.  So if you suggest a subset of a specification please state
clearly which subset and whether it works with currently existing
descriptions.  I'd volunteer to set up a doodle poll with suggestions.

If you make a suggestion please answer the following question:

  A. Does the suggestion enable parsing logical structures like
 two level itemize lists?
 (This is what I want to approach and what is IMHO needed)
  B. Does the suggestion enable keeping the majority of description
 untouched and enables keeping the currently existing tools?
 (This is important to gain any acceptance)

If one of the question above is answered with "no" please mention
whether you are volunteering to do the work which is needed to
port the existing stuff to match your suggestion.

Currently I would feed the poll with 4 suggestions:

  0. Keep anything as unstructured as it is.
 Answer to A: no
 Answer to B: yes

  1. Use '*' for first order item lists, '-' for second order
 item lists and use '  ' (exactly two spaces) before the
 '*' and '' (exactly four spaces) before the '-'. After
 '*' and '-' exactly one space should be used and continued
 lines should start in the same column as the text starts
 above.
 Answer to A: yes
 Answer to B: yes

  2. Use '*' for first order item lists, '-' for second order
 item lists.  Spacing does not matter as long as continued
 lines will start in the same column as the text above.
 Answer to A: yes
 Answer to B: yes

  3. Use any character of ('*', '-', '+') to start a list and
 mark the level of the list by strictly following spacing
 rules and use '  ' (exactly two spaces) before the selected
 character for starting first order list and '' (exactly
 four spaces) before the character for starting second order
 list. After the marker symbold exactly one space should be
 used and continued lines should start in the same column as
 the text starts above.
 Answer to A: yes
 Answer to B: yes

If you want to make further suggestions just append this list.
I'll start a doodle poll next Monday.  Depending from the outcome
of this poll I will submit a patch for "6.2. Best practices for
debian/control".

Does this sound reasonable?

Kind regards

Andreas.

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

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

[Bjørn Mork]

Josselin Mouette  writes:
> Le jeudi 16 avril 2009 à 00:34 +0200, Bjørn Mork a écrit :
>> My list of hal related regressions are
>> a) laptop keys remapped or disappearing (might be caused by the driver -
>>I don't know)
>
> Yes, they are remapped to the standard XF86* names, so that applications
> configuring shortcuts can have sensible defaults.

So you justify breaking existing setups by claiming the new
configuration is more "sensible".  How many times?  How often?

Every breakage is still a regression in my eyes.

>> b) unwanted auto-mounting
>
> HAL will not do auto-mounting by itself. Some user-level daemon must be
> listening for events and requesting the actual mount.

The auto-mount support in hal is unwanted even without such daemons.
Continously polling all removable storage is a very bad default IMHO.
And why do it if there's no daemon listening for the events anyway?

Yes, I know it can be disabled.  Having to disable such things to
avoid power consumption, noise and wear regressions is still annoying. 

An the design sucks.  Daemons wanting events from a polling source
should register with the poller, and polling should be disabled by
default until such a daemon registered itself.


Bjørn


-- 
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 jeudi 16 avril 2009 à 15:06 +0200, Bjørn Mork a écrit :
> >> a) laptop keys remapped or disappearing (might be caused by the driver -
> >>I don't know)
> >
> > Yes, they are remapped to the standard XF86* names, so that applications
> > configuring shortcuts can have sensible defaults.
> 
> So you justify breaking existing setups by claiming the new
> configuration is more "sensible".  How many times?  How often?

If you know how to homogenize keycodes between different keyboard models
without actually changing the keycodes, good for you, but I don’t. 

Also, do you prefer configuring a keycode named “0xae” or
“XF86AudioLowerVolume”?

> >> b) unwanted auto-mounting
> >
> > HAL will not do auto-mounting by itself. Some user-level daemon must be
> > listening for events and requesting the actual mount.
> 
> The auto-mount support in hal is unwanted even without such daemons.
> Continously polling all removable storage is a very bad default IMHO.
> And why do it if there's no daemon listening for the events anyway?

You’re mixing apples and oranges.

-- 
 .''`.  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

[Julien Cristau]

On Thu, 2009-04-16 at 10:18 +0200, Gabor Gombas wrote:
> ...except with latest hal/X.org/whatever it also stopped working. Latest
> X.org pulled in console-setup, and now the settings under
> /etc/hal/fdi/policy get ignored. What a mess.

that's called a bug.  ranting on mailing lists doesn't do anything to
fix it.

Cheers,
Julien


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

[Neil McGovern]

On Wed, Apr 15, 2009 at 12:53:58PM +1000, Ben Finney wrote:
> That would be premature. As I understand it, we're waiting on (and I'm
> actively soliciting) input for other purposes of the information in the
> ‘debian/copyright’ file; not least from the legal counsel at SPI.
> 

I could be wrong, but I'm not aware that counsel has been asked. Have
you got a messageid?

Thanks,
Neil
-- 
No matter whether you use charcoal or pine-cones, you've got to ignite the fuel
somehow. The traditional way is to use pieces of bark from a birch-tree. In the
soviet era, we used Pravda, the newspaper of the Communist Party. Proprietary
software licenses work just as well.  http://tinyurl.com/yqnm58


signature.asc
Description: Digital signature

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

[Holger Levsen]

reassign 524286 udev
thanks

On Donnerstag, 16. April 2009, Luca Boncompagni wrote:
> Package: general

> I try to open this as and udev bug (#524276) but Marco closed it because he
> think that this is not an udev bug.

I'm speechless. (About users filing bugs against the wrong package because the 
maintainer is not maintaining his package properly.)

Marco, if this is not a udev bug, please reassign it to the proper package, 
but dont make users workaround you. Also note that 524276 is about udev in 
stable, which is not etch anymore.


regards,
Holger


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

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

[Marco d'Itri]

On Apr 16, Holger Levsen  wrote:

> Marco, if this is not a udev bug, please reassign it to the proper package, 
> but dont make users workaround you. Also note that 524276 is about udev in 
> stable, which is not etch anymore.
I have no reason to believe that there is a bug (hint: "my computer is
not working as expected" is not a bug).
The user should ask for support on debian-user or a similar forum.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: Better formatting for long descriptions

[Manoj Srivastava]

On Thu, Apr 16 2009, Ben Finney wrote:

> (following up on IRC discussion)
>
> Manoj Srivastava  writes:
>
>> I suggest we follow a convention and tool set already in place,
>>  with multiple language bindings, if you must insist on adding rules to
>>  the long description.
>> 
>> There are alternatives (Text::Textile comes to mind), but
>>  Markdown has better language support, so long description parsers might
>>  have an easier time.
>> 
>> I suggest, for readability, to use a subset of markdown; the
>>  link and image tags are not that human readable.
>
> reStructuredText http://docutils.sourceforge.net/rst.html> (reST)
> is, I argue, a superior choice to Markdown for our existing format.

I can live with restructured text. I would like to point out,
 though, that the language support is more mature in markdown, and the
 subset of features we care about are identical in markdown and rest.

> It also helps that the simple bullet lists that are the most common case
> are perfectly valid in reST too.

Right.

manoj

-- 
Patageometry, n.: The study of those mathematical properties that are
invariant under brain transplants.
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

Bug#524286: marked as done (general: kernel modules does not automatically load)

[Debian Bug Tracking System]

Your message dated Thu, 16 Apr 2009 17:11:58 +0200
with message-id <20090416151158.ga13...@bongo.bofh.it>
and subject line Re: Bug#524286: general: kernel modules does not automatically 
load
has caused the Debian Bug report #524286,
regarding general: kernel modules does not automatically load
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
524286: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524286
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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


--- End Message ---
--- Begin Message ---
On Apr 16, Holger Levsen  wrote:

> Marco, if this is not a udev bug, please reassign it to the proper package, 
> but dont make users workaround you. Also note that 524276 is about udev in 
> stable, which is not etch anymore.
I have no reason to believe that there is a bug (hint: "my computer is
not working as expected" is not a bug).
The user should ask for support on debian-user or a similar forum.

-- 
ciao,
Marco


signature.asc
Description: Digital signature
--- End Message ---

Re: RFC: Better formatting for long descriptions

[Manoj Srivastava]

On Thu, Apr 16 2009, Andreas Tille wrote:

> On Thu, 16 Apr 2009, Ben Finney wrote:
>
>> Note that, like Manoj, I'm suggesting only a *subset*, not the full
>> specification.
>
> Well, in this thread we had several suggestions reaching from complete
> change to different format up to "not in detail specified" subsets of
> other formats.  IMHO this does not bring us foreward a single step.
> If we want to move foreward we have to make sure that we will not be
> forced to touch every single package because such an intend will be

This is exactly why I like markdown or restructured text, most
 packages conform already.

> bound to fail and every minute spended in discussion here is simply
> wasted.  So if you suggest a subset of a specification please state
> clearly which subset and whether it works with currently existing
> descriptions.  I'd volunteer to set up a doodle poll with suggestions.


Voting is a piss poor means of making a technical decision.

At this point, I would say rules for lists, and bold/italics
 should not be any more restrictive than markdown/ReST, and not impose
 any more burdens on the description writer.

> If you make a suggestion please answer the following question:
>
>   A. Does the suggestion enable parsing logical structures like
>  two level itemize lists?
>  (This is what I want to approach and what is IMHO needed)

Markdown and ReST, trivially.

>   B. Does the suggestion enable keeping the majority of description
>  untouched and enables keeping the currently existing tools?
>  (This is important to gain any acceptance)

Yes, for both.


The one issue I have seen raised is that of using *italics* and
 **bold** text; there are package descriptions where italics will
 suddenly appear. Me, I like org mode, where we have /italics/, *bold*
 +strikethrough+, _underline_; bug I doubt that org-mode will be popular
 as an interpreter.

manoj
-- 
It is better to have loved and lost -- much better.
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

[Manoj Srivastava]

On Thu, Apr 16 2009, Tzafrir Cohen wrote:

> On Thu, Apr 16, 2009 at 04:01:20AM -0500, Manoj Srivastava wrote:
>
>> Umm. I am not sure that follows. I am also not convinced we need
>>  to invent our own rules. Text::Markdown or Text::MultiMarkdown could
>>  help. And they do not seem to have issues with recognizing
>>  indentation/different characters as denoting levels of lists.
>
> Character-level formatting of markdown as well?
>
> Two examples:
>
> * From abcmidi:
>
>  This package contains the programs `abc2midi' and `midi2abc',  which

Yup, this one is a problem.
This package contains the programs abc2midi\' andmidi2abc\',  
which

So using ` as a quote seems to be an issue.
__> egrep '`' /var/lib/dpkg/available | wc -l 
149
Less than 150 instances.

> * From alltray:
>
>  KDE, XFCE 4*, Fluxbox* and WindowMaker*.
>  (*) No drag 'n drop support. Enable with "-nm" option.
__> echo "KDE, XFCE 4*, Fluxbox* and WindowMaker*.
 (*) No drag 'n drop support. Enable with "-nm" option." | markdown
KDE, XFCE 4*, Fluxbox* and WindowMaker*.
 (*) No drag 'n drop support. Enable with -nm option.

Hmm. Looks fine to me.

manoj
-- 
"If Diet Coke did not exist it would have been necessary to invent it."
Karl Lehenbauer
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

[Manoj Srivastava]

On Thu, Apr 16 2009, Andreas Tille wrote:

> On Thu, 16 Apr 2009, Manoj Srivastava wrote:
>
>>> my initial posting.  Detecting these would need either a defined
>>> character or a defined spacing (IMHO an 'and' would be better than
>>> a non-exclusive 'or' here).
>>
>>Umm. I am not sure that follows. I am also not convinced we need
>> to invent our own rules.
>
> I tried to suggest *any* rule which works.  I'm not in favour of invanting
> new rules.  But the rules should be simple enough to not break any existing
> tool.

Which is good, since Markdown/ReST rules for lists will only
 make the lists using o as the bullet out of whack.

>
>> Text::Markdown or Text::MultiMarkdown could
>> help. And they do not seem to have issues with recognizing
>> indentation/different characters as denoting levels of lists.
>
> If I interpret your first link [1] right this are even *more* rules as
> I suggested.

None of which are mandatory. All the package descriptions I read
 in /var/lib/dpkg/available seems to pass, though a couple had italics
 in strange places. This is not a fatal flaw.

>
I find the descriptions on packages.d.o just fine right now.
>>>
>>> IMHO it is no argument that a specific person is happy with the layout
>>> everybody else is.
>>
>>Just like it  is no argument that someone think something is ugly
>> that means everyone thinks so too.
>>
>>>  If a text has a certain logic it should to be
>>> supported by the means a certain output style has.  HTML can express a
>>> list and so it should if we want to express lists.
>
> Please do not split my paragraphs to blur my arguing.  Thanks.

Heh. Ever heard of inline answers?  

>>And we do not need to specify any more rigid rules than
>> established systems like markdown do in order to achieve that. Indeed,
>> we can just pipe the description though markdown, and use the html
>
> Have you tested this suggestion whether the current long descriptions will
> render correctly?

Yup.

>>> So you would be in favour of specifying only the amount of white space
>>> to define a level?
>>
>>You do not have to specify the level. Just that the indentation
>> be sufficient for the user or markdown to be able to differentiate what
>> level the item is at.
>
> I'm sorry - I do not know markdown whether it is clever enough to
> render the lists in all long descriptions.  But as long as the hint
> "please make sure that your long description renders with markdown" is
> not written in any of our documents I really doubt that.  May I draw

  Doubt is fine. Actually reading the package descriptions would
 have been better. 

> Tag \* was used 9277 times (68.0900%)
> Tag - was used 3837 times (28.1600%)
> Tag + was used 120 times (.8800%)

These work.

> Tag o was used 390 times (2.8600%)

These do not.

Now, using *italic* had a few issues. There are 99 lines in
 available where * is not used as a list item tag.

Of these 99 lines, 27  places the *word* is used for emphasis,
 meaning that 72 places in the available file * is used as a
 wildcard. But not all of these are an issue:

--8<---cut here---start->8---
__> echo ' bsd* and others.' | markdown
bsd* and others.
--8<---cut here---end--->8---


In those 72 places, only 24 descriptions did we have a second *
 show up, to anchor the other end of the mistaken emphasis.

> the conclusion that you are also in favour of some rules but not
> really happy with the rules I suggested?  That's really fine for me.
> I just want *any* rule which *works* and is written down somewhere to
> enable us filing bug reports against packages which do not follow this
> rule.  I think I mentioned this in my postings of this thread.

I suggest you try it out, before handwaving vague FUD
 around. Even tnftp description works fine with either. There are very
 few descriptions (about 24 or so) where we might have unwanted
 emphasis.  I think we can have that fixed. 


>>I suggest we follow a convention and tool set already in place,
>> with multiple language bindings, if you must insist on adding rules to
>> the long description.
>>
>>There are alternatives (Text::Textile comes to mind), but
>> Markdown has better language support, so long description parsers might
>> have an easier time.
>
> I do not want any complicated tool to parse our long descriptions.  In
> principle they are really easy to parse.  I want to have the simplest
> possible rule set which enables us to reliable parse the logic of our
> long descriptions.  While you claim to be against rules you propose
> even harder to apply rules.  At least for me your suggestions are
> confusing and just bluring the issue.

I would simplify the rule, as opposed to having a trivial
 library call in the tool. Indeed, reusing the libraries provided is
 *less* wor

Re: RFC: Better formatting for long descriptions

[Manoj Srivastava]

Hi,

Oh, markdown is only confused when you have `two' `words'
 quoted like this, wqhen there is only one such quote in the package, we
 are fine.

This package contains the programs `abc2midi'  which

So, less than 149 instances of the  tag where we want none.

manoj
 finding fewer problems in the descriptions than expected
-- 
"Slime is the agony of water." Jean-Paul Sartre
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: dash as default /bin/sh and bashisms-free archive RGs

[Manoj Srivastava]

On Thu, Apr 16 2009, Josselin Mouette wrote:

> Le mercredi 15 avril 2009 à 23:05 -0500, Manoj Srivastava a écrit :
>> So, no, policy does not just document current practice. Policy
>>  tries to document what is right.
>
> I think it should be both. When we do things right, they should be
> specified in the Policy,

Thisis covered under "Policy tries to document what is right"

> and there’s no point specifying what is right if nothing implements
> it.

Huh? Seems like if we know what is right and desirable, policy
 documents it (perhaps only as a recommendation), so there is clear
 guidance for how things should be implemented in the future, and so no
 conflicting set of inferior implementations appear.

manoj
-- 
You are an insult to my intelligence!  I demand that you log off
immediately.
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: Item lists bulletting (was: Re: RFC: Better formatting for long descriptions)

[Christian Perrier]

Quoting Lars Wirzenius (l...@liw.fi):
> to, 2009-04-16 kello 08:42 +0200, Christian Perrier kirjoitti:
> > 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?
> 
> I'm not an expert, but I have the 14th edition of the CMS. It says both
> bullets and dashes are acceptable (8.77, page 314, for reference).


Well, based on that discussion, these facts and the current practice,
I think that, in Smith reviews, we will, from now, recommend the use
of asterisks for 1st level items in item lists, in package
descriptions and debconf templates (these are the texts we review).

Please note that this is not *enforcing* things on maintainers. All
Smith reviews are suggestions made to maintainers and they are
associated to the whole discussion/review. When maintainers insist on
some practice (or even spelling|wording) we always follow their advice
at the endeven for mainainers who insist on using first person
sentences (hint hint).

The same will happen for item lists.




signature.asc
Description: Digital signature

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

[B. L. Jilek]

On Thu, Apr 16, 2009 at 5:11 PM, Marco d'Itri  wrote:

> On Apr 16, Holger Levsen  wrote:
>
> > Marco, if this is not a udev bug, please reassign it to the proper
> package,
> > but dont make users workaround you. Also note that 524276 is about udev
> in
> > stable, which is not etch anymore.
> I have no reason to believe that there is a bug (hint: "my computer is
> not working as expected" is not a bug).
> The user should ask for support on debian-user or a similar forum.
>
> --
> ciao,
> Marco
>

I'm having the exact same problem. I have to load modules manually.


-- 
B. L. Jilek   |  Debian Linux!
blji...@yahoo.com  |  GPG key: 11A5D1A4

Re: RFC: Better formatting for long descriptions

[Manoj Srivastava]

Hi,

I think we need to enumerate some goals for this proposed
 change. Here is a start:

 - Minimal disruption for current packages. The impact should be
   measured by numbers of packages impacted
   + Any specification of which of *, +, - to use as th first level item
 will impact more packages than not specifying it, by several
 hundred
   + The same is true for specifying the mark used for second level list
 items
   + Specifying exact number of spaces will also hit current packages,
 and will be a source of errors in the future. 
 - Ability to recognize and render the following logical entities, in
   decreasing order of importance:
   + unordered lists
   + ordered lists
   + emphasis
   + strong emphasis
   + definition lists
   + hypertext links
   + underlines, and strike throughs
 - Readability for people looking at non-enhanced renditions, i.e.,
   using less on the Packages file. Sticking to widely known
   conventions, using the same conventions that peple are used to using
   in email, and Wikis, is a plus.
 - Ease of use for description writers.
   Again, sticking with standards that people already know and use is
   better than making our own, more restrictive standards
 - Not adding hugely to bloat for the Packages file
   This kinda excludes verbose markup like XML (which would have failed
   the readability test too)

At this point, I would say that Markdown/Resstructued text meets
 most of the goals above, as long as we restrict the markup to the list
 above:
   * unordered lists
   * ordered lists
   * emphasis
   * strong emphasis
   * definition lists
   * hypertext links
   * underlines, and strike throughs


manoj
-- 
"If we can't fix it -- we'll fix it so nobody can." Gibbons
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

[Giacomo Catenazzi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Manoj Srivastava wrote:
>  - Ability to recognize and render the following logical entities, in
>decreasing order of importance:
>+ unordered lists
>+ ordered lists

really needed?

>+ emphasis
>+ strong emphasis
>+ definition lists
>+ hypertext links
>+ underlines, and strike throughs

I don't think they are needed. Underlines is generally bad,
strike throughs are worse ;-)

Ev. also monospace, e.g. for commands, but I really prefer to have
a simpler language as possible.

> At this point, I would say that Markdown/Resstructued text meets
>  most of the goals above, as long as we restrict the markup to the list
>  above:

Could provide us an example of Resstructued for the basic constructs?

>* unordered lists
>* ordered lists
>* emphasis
>* strong emphasis
>* definition lists
>* hypertext links
>* underlines, and strike throughs

I like also creole (standardized wiki language, moinmoin support it), but no 
definition lists,
underline, strike throughs.

So for creole:

* unordered lists   \n *  \n **
* ordered lists \n #  \n ##
* emphasis  //foo//
* strong emphasis   **bar**
* definition lists  missing  ev. \n **spam** is spam
* hypertext links   normal url
* underlines, and strike throughs   missing, missing

ciao
cate
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknnhU8ACgkQ+ZNUJLHfmlfJigCfR/Jpn96l7FxHb9INlJlHkd+S
z+MAn2eM+rOOHN9n8LJTYXi/gT7cWuMa
=3a5+
-END PGP SIGNATURE-


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

reassign 524276 to general, forcibly merging 524286 524276, tagging 524276

[Don Armstrong]

reassign 524276 general 
forcemerge 524286 524276
tags 524276 moreinfo


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

Processed: reassign 524276 to general, forcibly merging 524286 524276, tagging 524276

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 524276 general
Bug#524276: udev not loading hardware modules
Bug reassigned from package `udev' to `general'.

> forcemerge 524286 524276
Bug#524286: general: kernel modules does not automatically load
Bug#524276: udev not loading hardware modules
Forcibly Merged 524276 524286.

> tags 524276 moreinfo
Bug#524276: udev not loading hardware modules
There were no tags set.
Bug#524286: general: kernel modules does not automatically load
Tags added: moreinfo

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

[Don Armstrong]

On Thu, 16 Apr 2009, Marco d'Itri wrote:
> On Apr 16, Holger Levsen  wrote:
> > Marco, if this is not a udev bug, please reassign it to the proper
> > package, but dont make users workaround you. Also note that 524276
> > is about udev in stable, which is not etch anymore.
>
> I have no reason to believe that there is a bug (hint: "my computer
> is not working as expected" is not a bug).

Clearly something is wrong. At the time that this bug was closed you
haven't even identified what the actual problem is or at the very
least pointed the user at the type of information required so that the
actual problem can be identified.

> The user should ask for support on debian-user or a similar forum.

If you want to delegate the initial triaging of your bugs to
debian-user or some random forum, that's your business, but you still
need to inform the user that they should ask
debian-u...@lists.debian.org for assistance because you don't want to
deal with what is likely a user configuration issue.

Even a simple template response pointing people at the right resources
would be useful.


Don Armstrong

-- 
Miracles had become relative common-places since the advent of
entheogens; it now took very unusual circumstances to attract public
attention to sightings of supernatural entities. The latest miracle
had raised the ante on the supernatural: the Virgin Mary had
manifested herself to two children, a dog, and a Public Telepresence
Point.
 -- Bruce Sterling, _Holy Fire_ p228

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
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 Thu, Apr 16 2009, Giacomo Catenazzi wrote:

> Manoj Srivastava wrote:
>>  - Ability to recognize and render the following logical entities, in
>>decreasing order of importance:
>>+ unordered lists
>>+ ordered lists
>
> really needed?

I would think these are the guts of this proposal. Or else what
 are we discussing here?

>
>>+ emphasis
>>+ strong emphasis
>>+ definition lists
>>+ hypertext links
>>+ underlines, and strike throughs
>
> I don't think they are needed.

Why not? If rendering a description in a manner that makes it
 easier to read is the goal, I fail to see why emphasis and strong
 emphasis is a bad idea (think of text-to-speech mechanisms). This is
 not just opinions we are discussing here, we should be looking at use
 cases for marking up a textual description.

> Underlines is generally bad, strike throughs are worse ;-)

So you say. Don't use them, then. There are cases where either
 one of these constructs have value; and you should not impose your
 personal aesthetics on a general policy discussion.

> Ev. also monospace, e.g. for commands, but I really prefer to have
> a simpler language as possible.
>
>> At this point, I would say that Markdown/Resstructued text meets
>>  most of the goals above, as long as we restrict the markup to the list
>>  above:
>
> Could provide us an example of Resstructued for the basic constructs?



>>* unordered lists
>>* ordered lists
>>* emphasis
>>* strong emphasis
>>* definition lists
>>* hypertext links
>>* underlines, and strike throughs
>
> I like also creole (standardized wiki language, moinmoin support it),
> but no definition lists, underline, strike throughs.

What kind of language bindings are present for creole libraries?
 markdown has a shell interpreter, has python, perl, ruby, C, c++, lisp,
 and is widely supported and used by wikis et al.

> So for creole:
>
> * unordered lists \n *  \n **

This fails the "Do not impact large numbers of packages" test,
 since we have lots of packages using + and -. for list items.

> * ordered lists   \n #  \n ##
> * emphasis//foo//

This also fails the test above -- lots of people are using
 *emphasis*.

> * strong emphasis **bar**
> * definition listsmissing  ev. \n **spam** is spam

Hmm

> * hypertext links normal url
> * underlines, and strike throughs missing, missing

ok.

manoj

-- 
There's just something I don't like about Virginia; the state.
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

Bug#524394: ITP: wakeupmanager -- System to boot and shutdown hosts on demand

[Maximilian Wilhelm]

Package: wnpp
Severity: wishlist
Owner: Maximilian Wilhelm 


* Package name: wakeupmanager
  Version : 0.9.4
  Upstream Author : Maximilian Wilhelm 
* URL : http://wum.rfc2324.org / 
https://rfc2324.org/redmine/projects/show/wum
* License : GPL
  Programming Lang: Perl
  Description : System to boot and shutdown hosts on demand


The WakeUpManager - or in short wum - is an Open Source software project aimed
to boot and shutdown hosts on demand to reduce power consumption and the amount
of money spent for energy.

Considering a daily working time of 8 hours and 220 workdays a year
(~ 365 days - weekends - holidays) there is a theoretical saving of around 80%
compared to machines running 24/7 like many PCs in universities and companies 
do.
Realisticaly (standby energy usage, maintainance hours, ...) 50% to 60%
energy-saving should be achieveable.

Wum can boot hosts based on a user defined timetable or on demand if a user 
wants
to access his/her computer remotely or outside the defined (up)times.
The Wake-on-LAN technology is used to boot hosts over the network.



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

[Stefano Zacchiroli]

On Thu, Apr 16, 2009 at 12:50:12PM -0500, Manoj Srivastava wrote:
> I think we need to enumerate some goals for this proposed
> change. Here is a start:
> 
>  - Minimal disruption for current packages. The impact should be
>measured by numbers of packages impacted

> At this point, I would say that Markdown/Resstructued text meets
> most of the goals above, as long as we restrict the markup to the
> list above:

I agree with the goals and thanks for "resetting" the discussion on
their grounds.

According to the goals you pointed out, it looks like that Markdown
would be a more than suitable choice in terms of availability of
implementations, matching of "mail-like" markup (which is actually one
of the design goal of the language), and minimal disruption.

[ Markdown would also be my choice in term of personal tastes. Not
  that it matters, but I mention it to it make clear which is my
  "church" in this respect :) ]

However, markdown would not be directly applicable to the content of
the long description field, as a RFC822 parser would give you, due to
'.'s used as paragraph separators. Sure the needed pre-processing to
fix that would be trivial, but it is *some kind* of
pre-processing. One can then wonder to which extent we would allow
pre-processing before the markup processor without considering that
need a "disruption" of current long descriptions.

I just felt like pointing that out, because it can put back into play
some other language which can be considered "non disrupting" by
allowing some extra pre-processing bits. ... nevertheless I completely
agree that something like Markdown + the minimal paragraph separator
pre-processing looks like a completely reasonable implementation
plan. Out of curiosity, would restructured text be immune to this
problem?

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Bug#524286: closed by m...@linux.it (Marco d'Itri) (Re: Bug#524286: general: kernel modules does not automatically load)

[luca boncompagni]

Hi all,

I think that the bug #523187 is the real problem. I solved my problem
unistalling splashy.

Thanks,
Luca

On Thu, Apr 16, 2009 at 5:15 PM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

>
> This is an automatic notification regarding your Bug report
> which was filed against the general package:
>
> #524286: general: kernel modules does not automatically load
>
> It has been closed by m...@linux.it (Marco d'Itri).
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact m...@linux.it (Marco
> d'Itri) by
> replying to this email.
>
>
> --
> 524286: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524286
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: m...@linux.it (Marco d'Itri)
> To: Holger Levsen 
> Date: Thu, 16 Apr 2009 17:11:58 +0200
> Subject: Re: Bug#524286: general: kernel modules does not automatically
> load
> On Apr 16, Holger Levsen  wrote:
>
> > Marco, if this is not a udev bug, please reassign it to the proper
> package,
> > but dont make users workaround you. Also note that 524276 is about udev
> in
> > stable, which is not etch anymore.
> I have no reason to believe that there is a bug (hint: "my computer is
> not working as expected" is not a bug).
> The user should ask for support on debian-user or a similar forum.
>
> --
> ciao,
> Marco
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAknnSr4ACgkQFGfw2OHuP7GCtACfVSvtnrGc7kq0f153fM6j+7hL
> uXsAnjVyQij2zG2Gnxz6lKqBdzyCczRZ
> =A/KS
> -END PGP SIGNATURE-
>
>
> -- Forwarded message --
> From: Luca Boncompagni 
> To: Debian Bug Tracking System 
> Date: Thu, 16 Apr 2009 01:04:55 +0200
> Subject: 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 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
>
>
>
>

Re: debian/copyright verbosity

[Ben Finney]

Neil McGovern  writes:

> On Wed, Apr 15, 2009 at 12:53:58PM +1000, Ben Finney wrote:
> > That would be premature. As I understand it, we're waiting on (and I'm
> > actively soliciting) input for other purposes of the information in the
> > ‘debian/copyright’ file; not least from the legal counsel at SPI.
> 
> I could be wrong, but I'm not aware that counsel has been asked. Have
> you got a messageid?

So close, not yet. Message-id: <20090322005653.ga14...@hymers.org.uk>.
Proposed to the DPL, clarification requested, and that's as far as it
went AFAICT.

-- 
 \“I was once walking through the forest alone and a tree fell |
  `\   right in front of me, and I didn't hear it.” —Steven Wright |
_o__)  |
Ben Finney


pgpGR3hLl76UT.pgp
Description: PGP signature

Re: reassign 524276 to general, forcibly merging 524286 524276, tagging 524276

[Holger Levsen]

Hi Don,

On Donnerstag, 16. April 2009, Don Armstrong wrote:
> reassign 524276 general
> forcemerge 524286 524276
> tags 524276 moreinfo

why did you reassign them to general? why are these bugs a general problem in 
Debian which is not related to any particular package?

(you probably wanted to reopen them too.)


regards,
Holger





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

Re: reassign 524276 to general, forcibly merging 524286 524276, tagging 524276

[Don Armstrong]

On Fri, 17 Apr 2009, Holger Levsen wrote:
> On Donnerstag, 16. April 2009, Don Armstrong wrote:
> > reassign 524276 general
> > forcemerge 524286 524276
> > tags 524276 moreinfo
> 
> why did you reassign them to general?

524276 and 524286 have to be in the same package to be merged. If you
think they should be in some other package, reassign them.

> (you probably wanted to reopen them too.)

Nope.


Don Armstrong

-- 
I now know how retro SCOs OSes are. Riotous, riotous stuff. How they
had the ya-yas to declare Linux an infant OS in need of their IP is
beyond me. Upcoming features? PAM. files larger than 2 gigs. NFS over
TCP. The 80's called, they want their features back.
 -- Compactable Dave http://www3.sympatico.ca/dcarpeneto/sco.html

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Bug#524421: ITP: katimon -- KDE ATI Graphics Card Monitor

[Stefanos Harhalakis]

Package: wnpp
Severity: wishlist
Owner: Stefanos Harhalakis 


* Package name: katimon
  Version : 1.0.2
  Upstream Author : Stefanos Harhalakis 
* URL : http://www.v13.gr/proj/katimon/
* License : GPLv2
  Programming Lang: Python
  Description : KDE ATI Graphics Card Monitor

A KDE program for monitoring ATI graphics cards.
This program can:
* Display graphics card temperature
* Display and modify graphics card fans
* Automatically adjust fan speed
* Display GPU usage
* Display core GPU speed and memory speed
* Overclock the graphics card

It is written in Python and uses the aticonfig tool.



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

Work-needing packages report for Apr 17, 2009

[wnpp]

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: 402 (new: 1)
Total number of packages offered up for adoption: 119 (new: 0)
Total number of packages requested help for: 53 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   tcpstat (#523886), orphaned 3 days ago
 Description: network interface statistics reporting tool
 Installations reported by Popcon: 340

401 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 119 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#470795), requested 399 days ago
 Description: Co-maintainer wanted
 Reverse Depends: ampache apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (158 more
   omitted)
 Installations reported by Popcon: 43569

   ara (#450876), requested 522 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 119

   asymptote (#517342), requested 48 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 342

   athcool (#278442), requested 1633 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 212

   boinc (#511243), requested 98 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1579

   cvs (#354176), requested 1148 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta cvsps (12 more
   omitted)
 Installations reported by Popcon: 22627

   dctrl-tools (#448284), requested 537 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies dlocate haskell-devscripts
   hg-buildpackage ia32-archive ia32-libs-tools mlmmj sbuild simple-cdd
 Installations reported by Popcon: 11276

   dpkg (#282283), requested 1607 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc biblatex-dw build-essential bzr-builddeb cacao-oj6-dbg (214
   more omitted)
 Installations reported by Popcon: 84368

   drscheme (#402589), requested 857 days ago
 Description: PLT scheme programming environment
 Reverse Depends: drscheme minlog proofgeneral-minlog
 Installations reported by Popcon: 311

   elvis (#432298), requested 647 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 404

   fglrx-driver (#454993), requested 495 days ago (non-free)
 Description: non-free AMD/ATI r5xx, r6xx display driver
 Reverse Depends: fglrx-amdcccle fglrx-atieventsd fglrx-control
   fglrx-driver fglrx-glx fglrx-glx-ia32 fglrx-kernel-src
 Installations reported by Popcon: 2111

   flightgear (#487388), requested 299 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 973

   gentoo (#422498), requested 711 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 257

   gnat-4.3 (#475374), requested 371 days ago
 Description: help needed to execute test cases
 Reverse Depends: adabrowse adacontrol asis-programs ghdl gnade-bin
   gnat gnat-4.3 gnat-gps libadasockets-dev libahven16 (46 more
   omitted)
 Installations reported by Popcon: 821

   gnat-gps (#496905), requested 231 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 144

   grub (#248397), requested 1802 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: brdesktop-artwork-grub dfsbuild grub-choose-default
   grub-doc replicator startupmanager
 Installations reported by Popcon: 76795

   hotkey-setup (#483107), requested 324 days ago
 Description: auto-configures laptop hotkeys
 Installations reported by Popcon: 23859

   imagemagick (#452314), re

Re: About the current state of the Yum package in Lenny

[Luk Claes]

Thomas Goirand wrote:
> Hi,
> 
> I'm sorry that it took us so much time to make a working yum package,
> but we were quite overloaded with our work, taking over all the
> customers of another web hosting company (taking all our time doing
> support). Anyway, I could today take the time to upload a working
> version of yum. Here it is:
> 
> ftp://ftp.gplhost.com/debian/dists/lenny/main/source/yum_3.2.21-1~gplhost1.dsc
> 
> I guess you could notice that this is a newer upstream version. Please
> let me know if you think this would be an acceptable replacement to be
> sent in lenny proposed updates. At least, I'd be happy if somebody could
> NMU it to SID or experimental, so there's at least something working
> available in the archive.

I'm afraid it's too invasive to be included, though I would propose to
upload it to backports.org.

Cheers

Luk


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