Re: DEP 5 and directory/file names with spaces

[Ben Finney]

Andres Mejia  writes:

> On Sunday 07 June 2009 01:47:04 Ben Finney wrote:
> > Thanks for raising this problem with the current draft. I agree that
> > it needs to be changed to allow spaces in the patterns.
[…]

> > I would prefer to have a specification that allows the above field
> > to be parsed as the patterns ‘foo’, ‘wibble wobble’, ‘bar’, and
> > ‘baz’. But that of course requires a more complex specification for
> > stripping leading and trailing space from each pattern, and allowing
> > leading and trailing space if those actually are *intended* as part
> > of the pattern, and so on.
> >
> > I'm not sure how to resolve this without making the specification
> > more hairy. Is there prior art we can refer to?
> 
> You may refer to Debian Policy 7.1.

Policy §7.1 contains, in part:

Whitespace may appear at any point in the version specification
subject to the rules in Section 5.1, `Syntax of control files', and
must appear where it's necessary to disambiguate; it is not
otherwise significant.

That's contrary to what you're saying: we need a specification for file
names where whitespace *is* significant. How is Policy §7.1 helpful for
this purpose?

-- 
 \   “Corporation, n. An ingenious device for obtaining individual |
  `\   profit without individual responsibility.” —Ambrose Bierce, |
_o__)   _The Devil's Dictionary_, 1906 |
Ben Finney


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

Bug#532156: ITP: ibus-table-quick -- quick input method based on ibus-table

[LI Daobing]

Package: wnpp
Severity: wishlist
Owner: LI Daobing 

* Package name: ibus-table-quick
  Version : 1.1.0.20090601
  Upstream Author : Yu Yuwei (acevery) , 
Caius "kaio" Chance 
* URL : http://code.google.com/p/ibus
* License : Public Domain & GPLv2+
  Programming Lang: N/A
  Description : quick input method based on ibus-table

 IBus-Table is the IM Engine framework for table-based input methods, such as
 WuBi, ErBi, Cangjie and so on.
 .
 This package provide two input methods: Quick3 and Quick5.
 .
 Quick3 and Quick5 are Traditional Chinese input methods.



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

Bug#532155: ITP: ibus-table-xinhua -- Xin Hua input method on IBus Table under IBus

[LI Daobing]

Package: wnpp
Severity: wishlist
Owner: LI Daobing 

* Package name: ibus-table-xinhua
  Version : 1.1.0.20090605
  Upstream Author : dgod DOT osa AT gmail DOT com
* URL : http://code.google.com/p/ibus
* License : GPLv3+
  Programming Lang: N/A
  Description : Xin Hua input method on IBus Table under IBus framework

 IBus-Table is the IM Engine framework for table-based input methods, such as
 WuBi, ErBi, Cangjie and so on.
 .
 This package provide one input method:
   * xinhua: Xin Hua input method.
 .
 xinhua is a Chinese input method.



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

Re: DEP 5 and directory/file names with spaces

[Ben Finney]

Robert Collins  writes:

> On Sun, 2009-06-07 at 00:44 -0400, Andres Mejia wrote:
> > I suggest that the Files field use a comma-separated list of
> > globbing pathnames instead, else something ugly like 'path/with some
> > spaces/'* would have to be used.
> 
> That just trades ' ' for ',' as the path not usable.
> 
> I suggest just shell unescaping before globbing.
> 
> foo\ bar baz
> ->
> 'foo bar' and 'baz'.

This has merit, as being consistent both with shell word lexing and
shell globbing rules.

-- 
 \Hercules Grytpype-Thynne: “Well, Neddie, I'm going to be |
  `\  frank.”  Ned Seagoon: “Right, I'll be Tom.”  Count Moriarty: |
_o__)   “I'll be Gladys.” *slap* —The Goon Show, _World War I_ |
Ben Finney


pgpV5vRNa8VSZ.pgp
Description: PGP signature

Bug#532157: ITP: ibus-table-translit -- translit input method based on ibus-table

[LI Daobing]

Package: wnpp
Severity: wishlist
Owner: LI Daobing 

* Package name: ibus-table-translit
  Version : 1.1.0.20090603
  Upstream Author : Caius 'kaio' Chance < k AT kaio DOT me >
* URL : http://code.google.com/p/ibus
* License : GPLv2+
  Programming Lang: N/A
  Description : translit input method based on ibus-table
 IBus-Table is the IM Engine framework for table-based input methods, such as
 WuBi, ErBi, Cangjie and so on.
 .
 This package provide one input method: Translit
 .
 Tanslit is a russian input method.



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

Re: DEP 5 and directory/file names with spaces

[Andres Mejia]

On Sunday 07 June 2009 02:16:41 you wrote:
> On Sun, 2009-06-07 at 00:44 -0400, Andres Mejia wrote:
> > The current proposal for DEP 5 has this snippet for the 'Files' field.
> >
> > "List of space-separated globbing pathnames (see man 7 glob for more
> > details) indicating files that have the same licence and share copyright
> > holders."
> >
> > This doesn't take into account files or directories that may be named
> > with spaces.
> >
> > I suggest that the Files field use a comma-separated list of globbing
> > pathnames instead, else something ugly like 'path/with some spaces/'*
> > would have to be used.
>
> That just trades ' ' for ',' as the path not usable.
>
> I suggest just shell unescaping before globbing.
>
> foo\ bar baz
> ->
> 'foo bar' and 'baz'.
>
> -Rob

I would still prefer to use a comma-seperated list instead of a space-seperated 
list as using spaces in directories/files is more common (and AFAIK, using 
commas 
is less common). The shell escaping could instead be used for the commas if 
necessary.

-- 
Regards,
Andres


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

Bug#532161: ITP: ibus-table-zhuyin -- the zhuyin input method based on ibus-table

[LI Daobing]

Package: wnpp
Severity: wishlist
Owner: LI Daobing 

* Package name: ibus-table-zhuyin
  Version : 1.1.0.20090602
  Upstream Author : Ding-Yi Chen 
* URL : http://code.google.com/p/ibus
* License : GPLv2+
  Programming Lang: N/A
  Description : the zhuyin input method based on ibus-table
 IBus-Table is the IM Engine framework for table-based input methods, such as
 WuBi, ErBi, Cangjie and so on.
 .
 This package provide one input method: zhuyin.
 .
 zhuyin is an input method for traditional Chinese.



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

Re: DEP 5 and directory/file names with spaces

[Andres Mejia]

On Sunday 07 June 2009 03:02:32 Ben Finney wrote:
> Andres Mejia  writes:
> > On Sunday 07 June 2009 01:47:04 Ben Finney wrote:
> > > Thanks for raising this problem with the current draft. I agree that
> > > it needs to be changed to allow spaces in the patterns.
>
> […]
>
> > > I would prefer to have a specification that allows the above field
> > > to be parsed as the patterns ‘foo’, ‘wibble wobble’, ‘bar’, and
> > > ‘baz’. But that of course requires a more complex specification for
> > > stripping leading and trailing space from each pattern, and allowing
> > > leading and trailing space if those actually are *intended* as part
> > > of the pattern, and so on.
> > >
> > > I'm not sure how to resolve this without making the specification
> > > more hairy. Is there prior art we can refer to?
> >
> > You may refer to Debian Policy 7.1.
>
> Policy §7.1 contains, in part:
>
> Whitespace may appear at any point in the version specification
> subject to the rules in Section 5.1, `Syntax of control files', and
> must appear where it's necessary to disambiguate; it is not
> otherwise significant.
>
> That's contrary to what you're saying: we need a specification for file
> names where whitespace *is* significant. How is Policy §7.1 helpful for
> this purpose?

Sorry, didn't take note of that part.

Maybe this is more helpful.
http://en.wikipedia.org/wiki/Comma-separated_values

-- 
Regards,
Andres


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

Re: DEP 5 and directory/file names with spaces

[Felipe Sateler]

Andres Mejia wrote:

> On Sunday 07 June 2009 02:16:41 you wrote:
>> On Sun, 2009-06-07 at 00:44 -0400, Andres Mejia wrote:
>> > The current proposal for DEP 5 has this snippet for the 'Files' field.
>> >
>> > "List of space-separated globbing pathnames (see man 7 glob for more
>> > details) indicating files that have the same licence and share
>> > copyright holders."
>> >
>> > This doesn't take into account files or directories that may be named
>> > with spaces.
>> >
>> > I suggest that the Files field use a comma-separated list of globbing
>> > pathnames instead, else something ugly like 'path/with some spaces/'*
>> > would have to be used.
>>
>> That just trades ' ' for ',' as the path not usable.
>>
>> I suggest just shell unescaping before globbing.
>>
>> foo\ bar baz
>> ->
>> 'foo bar' and 'baz'.
>>
>> -Rob
> 
> I would still prefer to use a comma-seperated list instead of a
> space-seperated list as using spaces in directories/files is more common
> (and AFAIK, using commas is less common). The shell escaping could instead
> be used for the commas if necessary.

The space-separated list has the advantage that you can list files on their 
own physical line.

-- 
Felipe Sateler



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

Re: Bug#531581: Critical problems on hppa and ia64 buildds

[Josselin Mouette]

Le vendredi 05 juin 2009 à 21:15 +0200, Frank Küster a écrit :
> texlive-base's postrm, upon REMOVE, uses a command from tex-common, on
> which it already DEPENDS. This is allowed by policy.

I’m not sure about the policy, but I’m certain that with the current
dpkg version this will fail miserably in many cases. The only packages
that are guaranteed to be available in the postrm are the essential
packages.

> It seems it is a bug of policy, or dpkg.

Fixing the policy is probably easier than fixing dpkg…

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

InaTux's "Author's Choice of Terminology License"

[oohay moc.]

Hello,

I have sent an email to Richard Stallman asking a similar question, no response.

So! I was wondering what the community at large, and hopefully the main Debian 
developers, think about InaTux's "Author's Choice of Terminology License"? You 
can find it here: http://www.inatux.com/actl/

It has been discontinued, but, I am wondering if the community and the Debian 
developers would think about licensing the Debian operating system under such a 
license? I know it conflicts with the GNU GPL, but putting that aside.

Had the license been completed. Would they've/you've considered it?



  

Re: fstrcmp

[Peter Miller]

On Tue, 2009-06-02 at 10:28 -0400, Michael Poole wrote:
> I have some relevant experience that makes me skeptical about needing
> sophisticated structures to achieve acceptable performance

Some concrete numbers:

- naive fstrcmp comparisons (using edit distance, lifted from GNU
Gettext)
- list of names obtained from apt-cache dumpavail
- 2.1GHz x86

- looking for "dnsutl"

0.08008 = 0.215 sec / 26866 pair
that's 8.0us per fstrcmp call

- looking for "dns-server-utilities"

0.15816 = 0.425 sec / 26866 pair
that's 15us per fstrcmp call

For me, adding ~0.3 second to the error case in order to provide a far
better error message would appear to be worth it, especially as this is
less than the existing 0.532s reported by "time sudo apt-get install
dnsutl" (not including I/O time) on the same system.

I/O time when none of the package data is in cache is > 9 seconds,
confirming what Martin has been saying... and ~30 times longer than the
fstrcmp overhead.


I will have version 0.1 ready shortly.


Regards
Peter Miller 
/\/\*http://miller.emu.id.au/pmiller/

PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://www.keyserver.net or any PGP keyserver for public key.

"A computer is like air conditioning: it becomes useless when you open
windows." -- Linus Torvalds


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

Re: DEP 5 and directory/file names with spaces

[Lars Wirzenius]

su, 2009-06-07 kello 00:44 -0400, Andres Mejia kirjoitti:
> The current proposal for DEP 5 has this snippet for the 'Files' field.
> 
> "List of space-separated globbing pathnames (see man 7 glob for more details) 
> indicating files that have the same licence and share copyright holders."
> 
> This doesn't take into account files or directories that may be named with 
> spaces.

That is a very good point. Thanks for bringing it up!

> I suggest that the Files field use a comma-separated list of globbing 
> pathnames 
> instead, else something ugly like 'path/with some spaces/'* would have to be 
> used.

I'm afraid I'm opposed to comma-separated values (CSV). That format is
pretty much unused by Debian packaging related tools currently, and we
really don't need more complexity in this area. It also makes it harder
to extract the filename patterns using simple tools. Also, to quote the
Wikipedia page: "No general standard specification for CSV
exists" (regardless of RFC 4180), meaning we'd have to fix on a
particular specification and make sure all libraries used implement that
format.

My own preference would be to encode each pattern using URL encoding:
each pattern shall contain no unencoded spaces. URL encoding would also
allow full generality of encoding, and is well defined and well
supported by all relevant programming languages. Also, in most cases, a
simplistic glob (no spaces, no percent characters) will be identical to
the encoded value. This would keep things much simpler for people who
write the files.

Example:

Files: foo.c README* user%20manual/*



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

Bug#532167: ITP: records -- Save and index notes in Emacs environment

[Xavier MAILLARD]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: records
Version: 1.5.2
Upstream Author: Xavier Maillard 
URL: http://launchpad.net/records
License: GPL
Description: Records-mode is a major mode for editing and indexing
 notes. Notes are per-day files containing one or more
 subjects, subjects from different days are indexed and
 can be traversed, etc.

 This package contains files common to GNU Emacs and
 XEmacs. You probably want to install either
 records-gnuemacs or records-xemacs.


The package was already in Debian till 2006 then it got dropped (no
reason given).

1.5.2 is planned for today and will include a debian/ directory with
updated control/changelog/rule files. For the future release, I plan to
keep the debian/ directory up-to-date with debian.

Regards,

Xavier





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

Re: Bug#532167: ITP: records -- Save and index notes in Emacs environment

[Neil Williams]

On Sun, 7 Jun 2009 10:46:51 +0200
Xavier MAILLARD  wrote:

> The package was already in Debian till 2006 then it got dropped (no
> reason given).

The reasons are accessible via the PTS:

http://packages.qa.debian.org/r/records.html
[2008-12-04] Removed 1.4.9-4.1 from unstable (Thomas Viehmann)

http://packages.qa.debian.org/r/records/news/20081204T190628Z.html

which refers to bug 507598:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507598

Please see the following reasons for the removal request:

* Package is out of date.
* Upstream appears inactive since 2003.
* Low popcon (< 100).
* Package is orphaned. (Orphaned in Dec 2007).
* Package is buggy.

Packages are not removed from Debian without reason.
 
> 1.5.2 is planned for today and will include a debian/ directory with
> updated control/changelog/rule files. For the future release, I plan
> to keep the debian/ directory up-to-date with debian.

That is generally considered as a very bad idea. The upstream release
should *NOT* include a debian/ directory - by all means keep the
debian/ directory in the same VCS but it should not be in the upstream
tarball.

The package needs a maintainer in Debian and it is the Debian
maintainer who prepares, maintains and updates all files in the debian/
directory, not upstream. Even if upstream and the maintainer are the
same person, the debian/ directory needs to be separate from the
upstream package. There should be no reason why a new debian revision
would need a new upstream release every single time.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgp2zSIit5kwN.pgp
Description: PGP signature

Re: Bug#532167: ITP: records -- Save and index notes in Emacs environment

[Cyril Brulebois]

Xavier MAILLARD  (07/06/2009):
> The package was already in Debian till 2006 then it got dropped (no
> reason given).

You could look at:
http://packages.qa.debian.org/r/records.html

Removed 1.4.9-4.1 from unstable →
http://packages.qa.debian.org/r/records/news/20081204T190628Z.html

# 507598 →
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507598

(No need to Cc me if you keep debian-devel@ in the loop.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: InaTux's "Author's Choice of Terminology License"

[Ben Finney]

"oohay moc."  writes:

> So! I was wondering what the community at large, and hopefully the
> main Debian developers, think about InaTux's "Author's Choice of
> Terminology License"? You can find it here:
> http://www.inatux.com/actl/

It's much more practical to look at how *works* are licensed, since
often the details of the license are best considered in light of the
specific work.

What specific existing works is this license currently applied to? What
specific works is it proposed for application to?

> It has been discontinued, but, I am wondering if the community and the
> Debian developers would think about licensing the Debian operating
> system under such a license?

There is no single license for the Debian operating system. It is
distributed under the combined terms of all its thousands of component
parts. The copyright license terms for each part should be documented in
‘/usr/share/doc/$PACKAGENAME/copyright’.

If you want to discuss further in the context of specific works, I
suggest you take it to the ‘debian-legal’ list (Cc set). If you *don't*
want to discuss in the context of specific works, I'm not understanding
what the point is.

> I know it conflicts with the GNU GPL, but putting that aside.

It only conflicts with the GNU GPL if one attempts to apply its terms
simultaneously with the GPL to the same work.

> I have sent an email to Richard Stallman asking a similar question, no
> response.

What is it you are hoping to get from such a conversation, either with
Richard Stallman or with the Debian project? I'm having difficulty
seeing what the subject is.

-- 
 \ “I must say that I find television very educational. The minute |
  `\   somebody turns it on, I go to the library and read a book.” |
_o__)—Groucho Marx |
Ben Finney


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

Bug#532185: ITP: glpk-java -- Java binding to the GNU Linear Programming Kit

[Rafael Laboissiere]

Package: wnpp
Severity: wishlist
Owner: Rafael Laboissiere 


* Package name: glpk-java
  Version : 1.0.1
  Upstream Author : Heinrich Schuchardt 
* URL : http://glpk-java.sourceforge.net
* License : GPL-3+
  Programming Lang: Java
  Description : Java binding to the GNU Linear Programming Kit

  GLPK (GNU Linear Programming Kit) is intended for solving large-scale
  linear programming (LP), mixed integer programming (MIP), and other
  related problems. It is a set of routines written in ANSI C and
  organized in the form of a callable library.
  .
  GLPK supports the GNU MathProg language, which is a subset of the
  AMPL language. GLPK also supports the standard MPS and LP formats.
  .
  This package contains the Java binding to GLPK.

This package will be collectively maintained by the Debian Scientific
Computing Group (pkg-scicomp at alioth.d.o).  The preliminary version of the
Debian package is available at:
http://git.debian.org/?p=pkg-scicomp/glpk-java.git

-- 
Rafael Laboissiere



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

Bug#532186: ITP: snmpscan -- A simple yet powerful (and fast) SNMP scanner.

[Deepak Tripathi]

Package: wnpp
Severity: wishlist
Owner: Deepak Tripathi 


* Package name: snmpscan
  Version : 0.1 
  Upstream Author : Marco Ceresa 
* URL : http://rubyforge.org/projects/snmpscan/ 
* License : Ruby 
  Programming Lang: Ruby 
  Description : A simple yet powerful (and fast) SNMP scanner.


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

Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core)
Locale: LANG=en_IN, LC_CTYPE=en_IN (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

Re: DEP 5 and directory/file names with spaces

[Stephen Gran]

This one time, at band camp, Ben Finney said:
> I'm not sure how to resolve this without making the specification more
> hairy. Is there prior art we can refer to?

Why not just use standard csv rules for this sort of thing, ie add
quotes where necessary?
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Re: InaTux's "Author's Choice of Terminology License"

[oohay moc.]

Did you read the license?

The majority of the software in Debian is licensed under the GPL, that is why 
Debian is referred to as licensed under the GNU GPL.

I would think the license would be applied to the act of final distribution of 
Debian, to the source LiveCD, or other ways. So that when one receives the 
operating system they have to follow the same terminology in modifications.

The license aims to ensure the that operating systems be called "GNU/Linux" in 
any derivative works, like Ubuntu. It also aims to ensure that any software 
licensed under it has to be call "Free Software." But, one could use the 
license to ensure that the OS be call "Linux" and the software be called "Open 
Source." That is my paraphrased summary of the ACT License.

I didn't write the license so I don't fully understand myself. The only 
information I have is the link to the license at inatux.com that I already 
posted.

--- On Sun, 6/7/09, Ben Finney  wrote:

From: Ben Finney 
Subject: Re: InaTux's "Author's Choice of Terminology License"
To: debian-devel@lists.debian.org
Cc: debian-le...@lists.debian.org
Date: Sunday, June 7, 2009, 2:34 AM

"oohay moc."  writes:

> So! I was wondering what the community at large, and hopefully the
> main Debian developers, think about InaTux's "Author's Choice of
> Terminology License"? You can find it here:
> http://www.inatux.com/actl/

It's much more practical to look at how *works* are licensed, since
often the details of the license are best considered in light of the
specific work.

What specific existing works is this license currently applied to? What
specific works is it proposed for application to?

> It has been discontinued, but, I am wondering if the community and the
> Debian developers would think about licensing the Debian operating
> system under such a license?

There is no single license for the Debian operating system. It is
distributed under the combined terms of all its thousands of component
parts. The copyright license terms for each part should be documented in
‘/usr/share/doc/$PACKAGENAME/copyright’.

If you want to discuss further in the context of specific works, I
suggest you take it to the ‘debian-legal’ list (Cc set). If you *don't*
want to discuss in the context of specific works, I'm not understanding
what the point is.

> I know it conflicts with the GNU GPL, but putting that aside.

It only conflicts with the GNU GPL if one attempts to apply its terms
simultaneously with the GPL to the same work.

> I have sent an email to Richard Stallman asking a similar question, no
> response.

What is it you are hoping to get from such a conversation, either with
Richard Stallman or with the Debian project? I'm having difficulty
seeing what the subject is.

-- 
 \     “I must say that I find television very educational. The minute |
  `\       somebody turns it on, I go to the library and read a book.” |
_o__)                                                    —Groucho Marx |
Ben Finney


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




  

"Gänseblümchen" and the startup process

[Eike Sauer]

Hi!

I wanted to set the background image of kdm's login screen to 
a file called "Gänseblümchen.jpeg" (Gänseblümchen is German 
for daisy flower), but I had to find out that l10n isn't set up that early.
The bug (#528937) is closed now, but I feel it should not be the
responsibility of kdm (gdm, xdm, ... who else?) to pull in localization.

Shouldn't this be done earlier in the startup process? Like in an init
script? I couldn't say for which packages it is reasonable to expect
localized environment. But then, if we're using dependency based init, 
the packages even could decide themselves...

Ciao,
Eike



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

Re: DEP 5 and directory/file names with spaces

[Henrique de Moraes Holschuh]

On Sun, 07 Jun 2009, Andres Mejia wrote:
> "List of space-separated globbing pathnames (see man 7 glob for more details) 
> indicating files that have the same licence and share copyright holders."
> 
> This doesn't take into account files or directories that may be named with 
> spaces.

Principle of least surprise is important, so it is probably best if
either single quotes, or shell escaping is used.  Using commas with
initial and trailing spaces removed would work, but wouldn't allow
you to represent all files.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

New "libc" project libposix

[Henrique Almeida]

(this message will be posted to debian-glib and debian-devel)

Hello,

 I know debian has just switched it's libc implementation, but I've
created a project that will hopefully lead core Unix functionality
into a new direction. The goal is unifying all Unix implementations
with a small, clean and portable core library. Everybody is welcome,
specially current eglibc developers.

 http://libposix.sourceforge.net/

-- 
Henrique Dante de Almeida
hda...@gmail.com

Re: DEP 5 and directory/file names with spaces

[Ben Finney]

Stephen Gran  writes:

> This one time, at band camp, Ben Finney said:
> > I'm not sure how to resolve this without making the specification
> > more hairy. Is there prior art we can refer to?
> 
> Why not just use standard csv rules for this sort of thing, ie add
> quotes where necessary?

I can see two reasons against that. One is that there *is* no single set
of “standard CSV rules”, instead there are many implementations
incompatible to differing degrees. Another is that such rules become
rather more complex than the use of whitespace to separate values.

For the prior art, I'm in favour of applying standard POSIX shell
argument lexing: whitespace separates values, except when that
whitespace is escaped. I think that the fact this *is* standardised
already makes it significantly better than trying to use CSV.

-- 
 \“Quote me as saying I was mis-quoted.” —Groucho Marx |
  `\   |
_o__)  |
Ben Finney


pgpHxGu1rVHuW.pgp
Description: PGP signature

Re: New "libc" project libposix

[Samuel Thibault]

Henrique Almeida, le Sun 07 Jun 2009 10:33:28 -0300, a écrit :
>  I know debian has just switched it's libc implementation, but I've
> created a project that will hopefully lead core Unix functionality
> into a new direction.

What's the difference with newlib's libc?

Samuel


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

Re: debian and lilypond 2.12

[Gilles Filippini]

Hi,

Paul Wise a écrit :
> It looks like lilypond is unmaintained in Debian, so that is unlikely
> to happen until it gets a new maintainer or newly active maintainer.
> CCing the maintainer, hopefully they will respond.

It appears that lilypond is actively maintained in ubuntu[1].
I'd like to take over this package in Debian but I don't know about the
practices when a package is already maintained in Ubuntu:
* should I start from the Ubuntu source package?
* the Ubuntu lilypond release is now 2.12.1-0ubuntu1; what should be the
debian release then? 2.12.1-1?
* or simply persuade the ubuntu maintainer to package it for Debian ;)
(cc-ing him)?

Thanks in advance,

_Gilles.

[1] 


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

Re: DEP 5 and directory/file names with spaces

[Charles Plessy]

Le Sun, Jun 07, 2009 at 12:44:23AM -0400, Andres Mejia a écrit :
> The current proposal for DEP 5 has this snippet for the 'Files' field.
> 
> "List of space-separated globbing pathnames (see man 7 glob for more details) 
> indicating files that have the same licence and share copyright holders."

Hi all,

I think that how to specifiy a list of files is in the end in the hands of the
people writing parsers. It the files are separated by space, then spaces are an
issue, and if they are separated by commas, then commas are an issues. I can
not tell the difference, as in the ~50 packages I maintain whichever did not
cause any problem at all.

With the current definition, the specification is a one-liner, but for sure we
can replace it either by another one-limer (suggestions ?) or the previous
format, that was splitting the specification for the file name and the
directory name. (‘find -name’ plus ‘find -path’)

The current advantage of space-delimited listing is that is matches the
command-line experience. For intance we do not write ‘ls src, debian’, but ‘ls
src debian’.


So, from a parser point of view, what would be preferable, escaping spaces or
commas?


Have a nice day,

-- 
Charles Plessy
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: debian and lilypond 2.12

[Vincent Bernat]

OoO En ce  début d'après-midi ensoleillé du dimanche  07 juin 2009, vers
15:59, Gilles Filippini  disait :

> It appears that lilypond is actively maintained in ubuntu[1].
> I'd like to take over this package in Debian but I don't know about the
> practices when a package is already maintained in Ubuntu:
> * should I start from the Ubuntu source package?
> * the Ubuntu lilypond release is now 2.12.1-0ubuntu1; what should be the
> debian release then? 2.12.1-1?
> * or simply persuade the ubuntu maintainer to package it for Debian ;)
> (cc-ing him)?

You could also propose to package it as a team.

For the  version number,  yes, Debian version  should be  2.12.1-1.
-- 
BOFH excuse #335:
the AA battery in the wallclock sends magnetic interference


pgpDfesKa8HRO.pgp
Description: PGP signature

Re: debian and lilypond 2.12

[Luca Falavigna]

Il giorno Sun, 07 Jun 2009 15:59:55 +0200
Gilles Filippini  ha scritto:

> It appears that lilypond is actively maintained in ubuntu[1].
> I'd like to take over this package in Debian but I don't know about
> the practices when a package is already maintained in Ubuntu:
> * should I start from the Ubuntu source package?

You could do it if you plan to include Ubuntu changes in Debian. If you
decide to package it from scratch, Ubuntu will merge your package
applying Ubuntu adjustments on top of it until there is need to.

> * the Ubuntu lilypond release is now 2.12.1-0ubuntu1; what should be
> the debian release then? 2.12.1-1?

Yes.

> * or simply persuade the ubuntu maintainer to package it for Debian ;)
> (cc-ing him)?

Ubuntu usually haven't designed maintainers, think of it as a global QA
effort to have package in shape. If you want, you can contact the last
person who touched it to see if he has interest in maintaining it, but
it is usually not the case.

-- 
 . ''`.  Luca Falavigna
 : :'  :  Ubuntu MOTU Developer
 `. `'` Debian Maintainer
   `-  GPG Key: 0x86BC2A50


signature.asc
Description: PGP signature

Re: DEP 5 and directory/file names with spaces

[Noah Slater]

On Sun, Jun 07, 2009 at 11:07:15PM +0900, Charles Plessy wrote:
> I think that how to specifiy a list of files is in the end in the hands of the
> people writing parsers.

I think that this optimises for the wrong thing. The parsing code will be wrote
once, or only a few times at most. The file format will be authored hundreds, if
not thousands of time. All other things being equal, it makes more sense for us
to make it easy for packagers.

> So, from a parser point of view, what would be preferable

If I was implementing this in Python, it would be easier for me to parse comma
separated values because the "csv" module already handles this. Unfortunately,
if I specified " " as the separator, I would have to quote filenames instead of
escaping any spaces with a reverse solidus.

Best,

-- 
Noah Slater, http://tumbolia.org/nslater


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

Re: New "libc" project libposix

[Henrique Almeida]

 A comparison between libposix and other "libc" implementations is available
at:

 http://libposix.sourceforge.net/COMPARE

 Newlib would be equivalent to eglibc and uclibc in the table. More
specifically, newlib has embedded systems as main targets, while libposix
targets general purpose computers. This has certain architecture
implications, for example, libposix won't run on (restricted) embedded
systems if they can't fully support the POSIX standard (this is regarded as
a good thing because the users of libposix will have permanent guarantees
about the system functionality). Also, libposix aims to strictly conform to
exactly one standard (POSIX 2008). Newlib supports multiple standards (also,
standards are supported on a per function basis, not as a goal for the
project as a whole) and extensions. Finally, we hope to have exactly one GPL
compatible non-copyleft license for the whole project, since the goal is the
adoption by every Unix vendor (including commercial companies which may
worry about licensing). That's also different from newlib, which has
multiple licenses and some LGPL parts.

2009/6/7 Samuel Thibault 

> Henrique Almeida, le Sun 07 Jun 2009 10:33:28 -0300, a écrit :
> >  I know debian has just switched it's libc implementation, but I've
> > created a project that will hopefully lead core Unix functionality
> > into a new direction.
>
> What's the difference with newlib's libc?
>
> Samuel
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
>
>


-- 
Henrique Dante de Almeida
hda...@gmail.com

Re: debian and lilypond 2.12

[Grammostola Rosea]

Gauvain Pocentek wrote:

Hi all,

On 06/07/2009 03:59 PM, Gilles Filippini wrote:
  
really don't want to take over the package without interaction with Thomas.

But I'm definitly interesting in helping out with this package, maybe in a team
as Vincent Bernat suggested in an other mail.

  
Maybe you can put the package in the Debian Multimedia Team and help 
maintaining it?


\r

http://wiki.debian.org/DebianMultimedia


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

Invalid master alternatives, please tell us

[Raphael Hertzog]

Hello,

since dpkg 1.15, update-alternatives is more strict and forbids lots of
silly operations that were previously accepted. Unfortunately improper
usage of u-a in the past could lead to cruft files that cause bugs on
upgrade. You have examples in #530633 and #531611.

| Setting up gnome-session (2.26.1-6) ...
| Installing new version of config file /etc/gnome/defaults.list ...
| update-alternatives: error: alternative x-session-manager.1.gz can't be slave 
of  x-session-manager: it is a master alternative.

Since alternatives are shared among numerous packages, it makes sense
sometimes to do the corresponding cleanup directly in dpkg to avoid
having to duplicate it in all the packages implementing the alternatives.
I've done so for the two cases listed above but if you encounter other
case where it makes sense to fix it in dpkg, please let us know.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: New "libc" project libposix

[Michael Banck]

On Sun, Jun 07, 2009 at 01:06:20PM -0300, Henrique Almeida wrote:
>  http://libposix.sourceforge.net/COMPARE

That page is unreadable with a proportional font; if you put text files
with tables on your webpage, I suggest to HTML-ify it for the web.


Michael


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

Re: New "libc" project libposix

[Samuel Thibault]

Henrique Almeida, le Sun 07 Jun 2009 13:06:20 -0300, a écrit :
> newlib has embedded systems as main targets,

Err, not necessarily, as cygwin's usage shows.

> while libposix targets general purpose computers.

And thus will _have_ to support the old standard and the extensions, do
not dream.

> the goal is the adoption by every Unix vendor

Again, do not dream.

Sorry,
Samuel


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

Linux Plumbers Conference CFP and Inter Distribution Co-Operation track

[James Bottomley]

Hi All,

Just a reminder, the plumbers conference (Portland, OR, USA) CFP closes
on 15 June 2009:

http://linuxplumbersconf.org/2009/2009/04/lpc-2009-call-for-proposals/

One of the tracks we thought we'd try this year is inter distribution
co-operation, so we're looking for any topics you think might be useful
to stimulate discussion and co-operation between distributions, and to
that end, I thought I'd send an open begging letter for contributions
(I'm looking after the track this year, so if you don't want it to be
all about Novell distributions, now's your chance to submit something).

James



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

Re: Bug#530832: Bug#531581: Critical problems on hppa and ia64 buildds

[Norbert Preining]

On So, 07 Jun 2009, Josselin Mouette wrote:
> Le vendredi 05 juin 2009 à 21:15 +0200, Frank Küster a écrit :
> > texlive-base's postrm, upon REMOVE, uses a command from tex-common, on
> > which it already DEPENDS. This is allowed by policy.
> 
> I’m not sure about the policy, but I’m certain that with the current
> dpkg version this will fail miserably in many cases. The only packages

Many cases? I disagree. Only in the case that someone removes a package
with --force, right? All other variants should be handled (hopefully!).

> that are guaranteed to be available in the postrm are the essential
> packages.

Not according to the policy.

> > It seems it is a bug of policy, or dpkg.
> 
> Fixing the policy is probably easier than fixing dpkg…

Agreed on that, but OTOH, that is *really* a problematic system, because
we might leave things hanging around in a completely malconfigured way,
and reinstallations do not allow to overwrite stuff (maybe). I don't
have a szenario at hand, but I guess that changing policy in this
respect is not a piece of cake, either.

Best wishes

Norbert

---
Dr. Norbert Preining Vienna University of Technology
Debian Developer  Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
AYNHO (vb.)
Of waiters, never to have a pen.
--- Douglas Adams, The Meaning of Liff


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

Re: Bug#530832: Bug#531581: Critical problems on hppa and ia64 buildds

[Steve Langasek]

On Sun, Jun 07, 2009 at 11:36:25PM +0200, Norbert Preining wrote:
> On So, 07 Jun 2009, Josselin Mouette wrote:
> > Le vendredi 05 juin 2009 à 21:15 +0200, Frank Küster a écrit :
> > > texlive-base's postrm, upon REMOVE, uses a command from tex-common, on
> > > which it already DEPENDS. This is allowed by policy.

> > I’m not sure about the policy, but I’m certain that with the current
> > dpkg version this will fail miserably in many cases. The only packages

> Many cases? I disagree. Only in the case that someone removes a package
> with --force, right? All other variants should be handled (hopefully!).

Er, no, as has already been addressed in this thread, there are cases in
which dpkg will legitimately leave a package in a state where its "postrm
remove" is called after its dependencies have been removed, without any use
of --force options.

One is the case of a package being unpacked, then removed, without ever
being configured.

Another is the case of a package being deconfigured automatically by dpkg
(dpkg --auto-deconfigure, aka dpkg -B, which is standard in upgrades), then
having its dependencies removed from the system, then having the package
removed.  The higher-level package managers try to minimize the chance of
this occuring, but it's still a legitimate case (from dpkg's POV) where the
package's deps will not be satisfied when 'postrm remove' is called.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: New "libc" project libposix

[Henrique Almeida]

 Thanks for the suggestions, but libposix already has well defined goals. We
in the project believe that libposix may be useful for a lot of people,
including people who are not the target audience. Again, we welcome anyone
who wants to join in.

2009/6/7 Samuel Thibault 

> Henrique Almeida, le Sun 07 Jun 2009 13:06:20 -0300, a écrit :
> > newlib has embedded systems as main targets,
>
> Err, not necessarily, as cygwin's usage shows.
>
> > while libposix targets general purpose computers.
>
> And thus will _have_ to support the old standard and the extensions, do
> not dream.
>
> > the goal is the adoption by every Unix vendor
>
> Again, do not dream.
>
> Sorry,
> Samuel
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
>
>


-- 
Henrique Dante de Almeida
hda...@gmail.com

Bug#532261: ITP: fim -- Fbi IMproved - a scriptable image viewer for the framebuffer, ascii art library, and X

[Michele Martone]

Package: wnpp
Severity: wishlist
Owner: Michele Martone 


* Package name: fim
  Version : 0.3-beta
  Upstream Author : Michele Martone 
* URL : http://savannah.nongnu.org/projects/fbi-improved/
* License : GPL
  Programming Lang: C++
  Description : Fbi IMproved - a scriptable image viewer for the Linux 
framebuffer, ascii art library, and X

 FIM is a highly customizable and scriptable image viewer targeted at the
 users who are confortable with software like the Vim text editor or the Mutt
 mail user agent (it aims to be a swiss army knife for viewing images).
 It is based on the Fbi image viewer (by Gerd Hoffmann), and works primarily in
 the Linux framebuffer console.
 It is multidevice : it has X support, too (via the SDL library) and it supports
 ascii art output (via the aalib library).
 It is capable of regular expressions based (on filename) image viewing,vim-like
 autocommands, it offers GNU readline command line autocompletion and history,
 completely customizable key bindings, external/internal (if-while based)
 scriptability (through return codes, standard input/output, and commands given
 at invocation time, initialization file), internal filename-based image search,
 and much more features.

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



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

Re: InaTux's "Author's Choice of Terminology License"

[Robert Collins]

On Sun, 2009-06-07 at 01:10 -0700, oohay moc. wrote:
> Hello,
> ...
> Had the license been completed. Would they've/you've considered it?

Seems non-free to me.

-Rob


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

Re: DEP 5 and directory/file names with spaces

[Andres Mejia]

On Sunday 07 June 2009 10:20:59 Noah Slater wrote:
> On Sun, Jun 07, 2009 at 11:07:15PM +0900, Charles Plessy wrote:
> > I think that how to specifiy a list of files is in the end in the hands
> > of the people writing parsers.
>
> I think that this optimises for the wrong thing. The parsing code will be
> wrote once, or only a few times at most. The file format will be authored
> hundreds, if not thousands of time. All other things being equal, it makes
> more sense for us to make it easy for packagers.
>
> > So, from a parser point of view, what would be preferable
>
> If I was implementing this in Python, it would be easier for me to parse
> comma separated values because the "csv" module already handles this.
> Unfortunately, if I specified " " as the separator, I would have to quote
> filenames instead of escaping any spaces with a reverse solidus.

Some other things to consider.

There is Policy 7.1 that defines how to write proper relationship fields. We 
know 
that relationship fields are comma-separated, so there are parsers already in 
programs such as sbuild that read these comma-separated values, and it 
shouldn't 
be too hard to modify these parsers to read a 'Files' field (if it were
comma-separated).

Also, the copyright file should be something that is as simple as possible to 
read, by a machine but most importantly, by any person. That includes people 
that are not familiar with shell escaping.

I am more inclined to use a comma-separated list as spaces in files and 
directories are frequently used, as opposed to commas in files and directories, 
which are quite rare.

Consider two examples of a Files field, one space-separated, and one
comma-separated.

space-separated
  Files: a\ b c d\ e\ f g.*

comma-separated
  Files: a b, c, d e f, g.*

Which implementation could we reasonably expect most people to understand (to 
include people not knowledgeable with shell escaping)? For example, consider 
what the two fields may mean to a Windows user.

-- 
Regards,
Andres


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

Re: DEP 5 and directory/file names with spaces

[Noah Slater]

On Sun, Jun 07, 2009 at 10:44:41PM -0400, Andres Mejia wrote:
> Which implementation could we reasonably expect most people to understand (to
> include people not knowledgeable with shell escaping)? For example, consider
> what the two fields may mean to a Windows user.

To a Windows user?

Heh, I think this demonstrates the one weakness of your argument. The kind of
person who would be reading the source format of these files is not your average
Windows user, nor your average Debian user.

One of the ultimate goal is to parse this file and present via a GUI.

Best,

-- 
Noah Slater, http://tumbolia.org/nslater


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

Re: DEP 5 and directory/file names with spaces

[Robert Collins]

On Sun, 2009-06-07 at 22:44 -0400, Andres Mejia wrote:


> Which implementation could we reasonably expect most people to understand (to 
> include people not knowledgeable with shell escaping)? For example, consider 
> what the two fields may mean to a Windows user.

I think the style I proposed is most easily read because it is precisely
the same style used when giving a list of files via your shell.
$ ls a\ b c d\ e\ f g.*

People who haven't used a unix shell will encounter many issues
packaging for Debian, as shell quoting and escaping are common through
the packaging system.

-Rob


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

Re: DEP 5 and directory/file names with spaces

[Steve Langasek]

On Sun, Jun 07, 2009 at 10:44:41PM -0400, Andres Mejia wrote:
> Consider two examples of a Files field, one space-separated, and one
> comma-separated.

> space-separated
>   Files: a\ b c d\ e\ f g.*

> comma-separated
>   Files: a b, c, d e f, g.*

> Which implementation could we reasonably expect most people to understand (to 
> include people not knowledgeable with shell escaping)? For example, consider 
> what the two fields may mean to a Windows user.

However, this is a contrived example.  Spaces are allowed in filenames, but
are rare in source packages.  Commas are also rare in source packages, but
are also allowed.  So a machine-parseable rendering of a list of files needs
to account for some kind of escaping, regardless of whether you use a comma
or a space as your delimiter.  (The existing parsers for debian/control
files are not a germane precedent; those fields contain lists of package
names, which use a restricted character set which includes neither spaces
nor commas.)

In other words, the real question is: which of these is easier for your
hypothetical user to read?:

 space-separated
   Files: a\ b c d\ e\ f g.*

 comma-separated
   Files: a\,b, c, d\,e\,f, g.*


For my part I'm actually inclined to say that the latter is more readable,
but let's get the rationale right. :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: DEP 5 and directory/file names with spaces

[Andres Mejia]

On Sunday 07 June 2009 22:51:10 Noah Slater wrote:
> On Sun, Jun 07, 2009 at 10:44:41PM -0400, Andres Mejia wrote:
> > Which implementation could we reasonably expect most people to understand
> > (to include people not knowledgeable with shell escaping)? For example,
> > consider what the two fields may mean to a Windows user.
>
> To a Windows user?
>
> Heh, I think this demonstrates the one weakness of your argument. The kind
> of person who would be reading the source format of these files is not your
> average Windows user, nor your average Debian user.
>
> One of the ultimate goal is to parse this file and present via a GUI.

Oh. I didn't know of such a goal and the DEP draft doesn't mention this. I've 
always thought the copyright file was meant to be most readable by people.

So ultimately it's going to be expected that people read these copyright files 
through a GUI, correct?

-- 
Regards,
Andres


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

Re: DEP 5 and directory/file names with spaces

[Steve Langasek]

On Mon, Jun 08, 2009 at 12:03:00AM -0400, Andres Mejia wrote:
> On Sunday 07 June 2009 22:51:10 Noah Slater wrote:
> > On Sun, Jun 07, 2009 at 10:44:41PM -0400, Andres Mejia wrote:
> > > Which implementation could we reasonably expect most people to understand
> > > (to include people not knowledgeable with shell escaping)? For example,
> > > consider what the two fields may mean to a Windows user.

> > To a Windows user?

> > Heh, I think this demonstrates the one weakness of your argument. The kind
> > of person who would be reading the source format of these files is not your
> > average Windows user, nor your average Debian user.

> > One of the ultimate goal is to parse this file and present via a GUI.

> Oh. I didn't know of such a goal and the DEP draft doesn't mention this. I've 
> always thought the copyright file was meant to be most readable by people.

The DEP draft doesn't mention this because it's not a goal *of* the DEP.  I
don't think I've ever heard of this intended use case before, and I
certainly don't consider it key.  I guess this happens to be one of Noah's
personal goals.

> So ultimately it's going to be expected that people read these copyright 
> files 
> through a GUI, correct?

That sounds like an uninteresting corner case to me.  People certainly
aren't going to be *writing* them through a GUI, and I think that's at least
as relevant.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: DEP 5 and directory/file names with spaces

[Ben Finney]

Andres Mejia  writes:

> Oh. I didn't know of such a goal and the DEP draft doesn't mention
> this. I've always thought the copyright file was meant to be most
> readable by people.

Yes, and that's certainly a goal that should not be lost. As I
understand it, the goal is to make it *also* easily parseable by
programs, so that its structured information can be shown in other ways.

> So ultimately it's going to be expected that people read these
> copyright files through a GUI, correct?

That makes it sound like you're describing the expected *primary*
interface for viewing these files, which I don't think is correct.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, but |
  `\  where will we find an open tattoo parlor at this time of |
_o__)   night?” —_Pinky and The Brain_ |
Ben Finney


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

Bug#532268: ITP: yapet -- Yet Another Password Encryption Tool

[Salvatore Bonaccorso]

Package: wnpp
Severity: wishlist
Owner: Salvatore Bonaccorso 

* Package name: yapet
  Version : 0.3
  Upstream Author : Rafael Ostertag 
* URL : http://www.guengel.ch/myapps/yapet/
* License : GPL-3+
  Programming Lang: C++
  Description : Yet Another Password Encryption Tool

Yapet is a curses based password encryption tool using the Blowfish
encryption algorithm to store password records encrypted on disk. Its
primary aim is to provide a safe way to store passwords in a file on
disk while having a small footprint.



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

Bug#532269: ITP: mono-uiautomationwinforms -- Implementation of UIA providers

[Ray Wang]

Package: wnpp
Severity: wishlist
Owner: Ray Wang 


* Package name: mono-uiautomationwinforms
  Version : 1.0
  Upstream Author : Mono Accessibility 
* URL : http://www.mono-project.com/Accessibility
* License : MIT
  Programming Lang: C#
  Description : Implementation of UIA providers

Implementation of UIA providers for Mono's Winforms controls.

-- System Information:
Debian Release: 5.0
  APT prefers lenny-security
  APT policy: (500, 'lenny-security'), (500, 'lenny')
Architecture: i386 (i686)



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

Bug#532270: ITP: mono-uiaatkbridge -- Bridge between UIA providers and ATK

[Ray Wang]

Package: wnpp
Severity: wishlist
Owner: Ray Wang 


* Package name: mono-uiaatkbridge
  Version : 1.0
  Upstream Author : Mono Accessibility 
* URL : http://www.mono-project.com/Accessibility
* License : MIT
  Programming Lang: C#
  Description : Bridge between UIA providers and ATK

The bridge contains adapter Atk.Objects that wrap UIA providers.  Adapter
behavior is determined by provider ControlType and supported pattern interfaces.
The bridge implements interfaces from UIAutomationBridge which allow the UI
Automation core to send it automation events and provider information.

-- System Information:
Debian Release: 5.0
  APT prefers lenny-security
  APT policy: (500, 'lenny-security'), (500, 'lenny')
Architecture: i386 (i686)



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

DEP 5 proposal omits original Debianization information

[Deng Xiyue]

[Don't know whether this has been asked.  If so, pointers are welcomed.]

According to Debian Policy Manual section 12.5:

In addition, the copyright file must say where the upstream sources
(if any) were obtained. *It should name the original authors of the
package and the Debian maintainer(s) who were involved with its
creation.*

The current DEP 5 proposal doesn't provide a standard field dedicated
for the information of original Debianizer, while the old format
generated by dh-make does.  According to section 1.1,

In addition, the copyright file must say where the upstream sources
(if any) were obtained. It should name the original authors of the
package and the Debian maintainer(s) who were involved with its
creation. 

So this is not strictly required, but it is considered a bug, which AIUI
needs fixing.  Hence I wonder how this was and will be handled.

Regards,
Deng Xiyue


signature.asc
Description: Digital signature

Re: DEP 5 proposal omits original Debianization information

[Russ Allbery]

Deng Xiyue  writes:

> [Don't know whether this has been asked.  If so, pointers are welcomed.]
>
> According to Debian Policy Manual section 12.5:
>
> In addition, the copyright file must say where the upstream sources
> (if any) were obtained. *It should name the original authors of the
> package and the Debian maintainer(s) who were involved with its
> creation.*
>
> The current DEP 5 proposal doesn't provide a standard field dedicated
> for the information of original Debianizer, while the old format
> generated by dh-make does.  According to section 1.1,
>
> In addition, the copyright file must say where the upstream sources
> (if any) were obtained. It should name the original authors of the
> package and the Debian maintainer(s) who were involved with its
> creation. 
>
> So this is not strictly required, but it is considered a bug, which AIUI
> needs fixing.  Hence I wonder how this was and will be handled.

Removing that part from Policy would be my preference.  It's duplication
of information that's already in the changelog.

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