Re: DEP 5 proposal omits original Debianization information

[Deng Xiyue]

On Sun, Jun 07, 2009 at 11:51:25PM -0700, Russ Allbery wrote:
> 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.

Would it merit a BTS entry against debian-policy as a reminder?  Or
maybe waiting for more comments, and act after consensus is reached?

Regards,
Deng Xiyue 


-- 
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 20:07 -0700, Steve Langasek kirjoitti:
> 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.*

url-encoded:

Files: a%2Cb c d%2Ce%2Cf g.*
Files: a%20b c d%20e%20f g.*

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

I rather think they're all unreadable. URL encoding at least makes it
easy to see each pattern separately from the others.


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

Re: DEP 5 proposal omits original Debianization information

[Russ Allbery]

Deng Xiyue  writes:
> On Sun, Jun 07, 2009 at 11:51:25PM -0700, Russ Allbery wrote:

>> Removing that part from Policy would be my preference.  It's
>> duplication of information that's already in the changelog.
>
> Would it merit a BTS entry against debian-policy as a reminder?

Sure.  Although we're way behind on processing bugs at the moment.  :/

-- 
Russ Allbery (r...@debian.org)   


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

Re: DEP 5 proposal omits original Debianization information

[Ben Finney]

Deng Xiyue  writes:

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

Recording in the ‘debian/copyright’ the URL where the original source
was obtained makes sense.

I don't see why ‘debian/copyright’ needs to “name the Debian
maintainer(s) who were involved with its creation”; surely the best
location for that is the already-mandatory package maintainer data on
entries in ‘debian/changelog’.

> The current DEP 5 proposal doesn't provide a standard field dedicated
> for the information of original Debianizer

(Side point: Can we please drop this awful neologism, and just refer to
the process of packaging a work as “packaging”?)

> According to section 1.1, [exact copy of Debian Policy §12.5 paragraph
> 2]

Section 1.1 of what?

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

I think it's a bug in policy; it should not require a redundant record
of historical information (the maintainers of the original versions of
the Debian package) already mandated in the ‘debian/changelog’ file.

-- 
 \ “We are no more free to believe whatever we want about God than |
  `\ we are free to adopt unjustified beliefs about science or |
_o__)  history […].” —Sam Harris, _The End of Faith_, 2004 |
Ben Finney


pgpvoFZvI5CZO.pgp
Description: PGP signature

Re: DEP 5 proposal omits original Debianization information

[Deng Xiyue]

On Mon, Jun 08, 2009 at 05:27:04PM +1000, Ben Finney wrote:
> Deng Xiyue  writes:
> 
> > 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.*
> 
> Recording in the ‘debian/copyright’ the URL where the original source
> was obtained makes sense.
> 
> I don't see why ‘debian/copyright’ needs to “name the Debian
> maintainer(s) who were involved with its creation”; surely the best
> location for that is the already-mandatory package maintainer data on
> entries in ‘debian/changelog’.
> 
> > The current DEP 5 proposal doesn't provide a standard field dedicated
> > for the information of original Debianizer
> 
> (Side point: Can we please drop this awful neologism, and just refer to
> the process of packaging a work as “packaging”?)
> 

OK, so I was referring to the original Debian packager, though
"Debianize" was used when machine-readable format proposal was hold
on wiki.debian.org.  But this is irrelevant now :)

> > According to section 1.1, [exact copy of Debian Policy §12.5 paragraph
> > 2]
> 
> Section 1.1 of what?
> 

Bah, my bad.  I was trying to refer to the following wording from
section 1.1 of debian-policy:

Non-conformance with guidelines denoted by should (or recommended)
will generally be considered a bug, but will not necessarily render
a package unsuitable for distribution.

and now with:

These classifications are roughly equivalent to the bug severities
serious (for must or required directive violations), [..snip..]

Hence my concern on omitting that information may lead to bug reports.

> > 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.
> 
> I think it's a bug in policy; it should not require a redundant record
> of historical information (the maintainers of the original versions of
> the Debian package) already mandated in the ‘debian/changelog’ file.

So I guess this is another vote for removing this requirement from
Debian Policy :)

Regards,
Deng Xiyue


signature.asc
Description: Digital signature

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

[Norbert Preining]

On So, 07 Jun 2009, Steve Langasek wrote:
> 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.

Ah ok thanks.

Anyway I have added code to protect this problem and next upload of
tex-common will fix that.

Thanks for the explanations

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
---
FOINDLE (vb.)
To queue-jump very discreetly by working one's way up the line without
being spotted doing so.
--- 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: New "libc" project libposix

[Giacomo A. Catenazzi]

Henrique Almeida wrote:


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


I don't like the name of the project. I think POSIX is a trademark
and reserved for certified systems, with some extra requirement
(implementors must correct bugs).

ciao
cate


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

Bug#532291: ITP: libnet-inet6glue-perl -- Make common modules IPv6 ready by hotpatching

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg 

* Package name: libnet-inet6glue-perl
  Version : 0.3-1
  Upstream Author : Steffen Ullrich 
* URL : http://search.cpan.org/dist/Net-INET6Glue/
* License : Perl
  Programming Lang: Perl
  Description : Make common modules IPv6 ready by hotpatching
 Net::INET6Glue is a collection of modules to make common modules IPv6 ready
 by hotpatching them.
 .
 Unfortunatly the current state of IPv6 support in perl is that no IPv6
 support is in the core and that a lot of important modules (like Net::FTP,
 Net::SMTP, LWP,...) do not support IPv6 even if the modules for IPv6 sockets
 Socket6, IO::Socket::INET6 are available.



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

Re: DEP 5 proposal omits original Debianization information

[Xavier Oswald]

On 17:27 Mon 08 Jun , Ben Finney wrote:
> Deng Xiyue  writes:
> 
> > 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.*
> 
> Recording in the ‘debian/copyright’ the URL where the original source
> was obtained makes sense.
> 
> I don't see why ‘debian/copyright’ needs to “name the Debian
> maintainer(s) who were involved with its creation”; surely the best
> location for that is the already-mandatory package maintainer data on
> entries in ‘debian/changelog’.

Agreed.

debian/control already list the names of maintainer and uploaders.
debian/changelog entries tell us who was involved and who did the first uploads.

So I see no needs in having the debian maintainer(s) name who were involved in
the creation in debian/copyright too. It's an information duplication.

Greetings,
-- 
  ,''`.  Xavier Oswald
 : :' :  GNU/LINUX Debian Developer
 `. `'   GnuPG Key ID 0x88BBB51E
   `-938D D715 6915 8860 9679  4A0C A430 C6AA 88BB B51E 


signature.asc
Description: Digital signature

anyone using interactive bugscripts

[Bastian Venthur]

Hi all,

is anyone using interactive bugscripts? I mean scripts in
/usr/share/bug/ which interactively demand answers from the user.

I made a quick search on my system and I only found the texlive packages
using "getkey" to force a user to read a text before the script is
executed. In that case the interactive mode is superfluous since one can
use the presubj file to show such texts to the user.

The problem is, that non-console applications like reportbug-ng have to
call a terminal to start interactive bugscripts. Unfortunately some
terminals (if not all) fork upon startup so the calling command just
returns. An example:

If I call:

  os.system("/usr/share/bug/foo")

the command returns when foo has finished. But if I call

  os.system("/usr/bin/x-terminal-emulator -e '/usr/share/bug/foo'")

the command returns intermediately, while foo is still running in the
background. This makes it quite tricky to get the output of the script.

I want to evaluate who is using this feature, if it turns out that no
one does, maybe I can talk with the reportbug guys to depreciate it.


Cheers,

Bastian

-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


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

Re: DEP 5 proposal omits original Debianization information

[Steve Langasek]

On Mon, Jun 08, 2009 at 12:51:39PM +0200, Xavier Oswald wrote:
> So I see no needs in having the debian maintainer(s) name who were involved in
> the creation in debian/copyright too. It's an information duplication.

The one reason to include this information in debian/copyright is that the
packagers may be copyright holders for contents under Debian.  However, this
a) is not limited to the original packagers, b) may not be true in many
cases today, where the debian/ directory for many packages is trivial
boilerplate.

-- 
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: anyone using interactive bugscripts

[Frans Pop]

Bastian Venthur wrote:
> is anyone using interactive bugscripts? I mean scripts in
> /usr/share/bug/ which interactively demand answers from the user.

The installation-reports script is quite interactive.

Why do you continue to want to cripple bug reporting because of 
reportbug-ng? I appreciate there can be difficulties, but the solution is 
not to remove existing functionality.

Cheers,
FJP


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

Re: anyone using interactive bugscripts

[Adam D. Barratt]

Bastian Venthur wrote:

is anyone using interactive bugscripts? I mean scripts in
/usr/share/bug/ which interactively demand answers from the user.

I made a quick search on my system and I only found the texlive
packages using "getkey" to force a user to read a text before the
script is executed.


I'd suggest adding "yesno" to your search terms.

Regards,

Adam


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

Re: DEP 5 proposal omits original Debianization information

[Xavier Oswald]

On 04:17 Mon 08 Jun , Steve Langasek wrote:
> On Mon, Jun 08, 2009 at 12:51:39PM +0200, Xavier Oswald wrote:
> > So I see no needs in having the debian maintainer(s) name who were involved 
> > in
> > the creation in debian/copyright too. It's an information duplication.
> 
> The one reason to include this information in debian/copyright is that the
> packagers may be copyright holders for contents under Debian.  However, this
> a) is not limited to the original packagers, b) may not be true in many
> cases today, where the debian/ directory for many packages is trivial
> boilerplate.

Im not speaking about debian copyright holder in debian/changelog.
We sure need to keep copyright holder of debian modifications.

I was thinking about this:
"This package was debianized by ... <@...> on $Date$."

Since the name of the of the original packagers is listed too as described in
the new format specification [1]. It's only a proposal but I think it has been
well studied and is now applicable.

We know the original packager and date by watching in the debian/changelog first
entry.

[1] http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=196

Greetings,
-- 
  ,''`.  Xavier Oswald
 : :' :  GNU/LINUX Debian Developer
 `. `'   GnuPG Key ID 0x88BBB51E
   `-938D D715 6915 8860 9679  4A0C A430 C6AA 88BB B51E 


signature.asc
Description: Digital signature

Re: anyone using interactive bugscripts

[Bastian Venthur]

Frans Pop schrieb:
> Bastian Venthur wrote:
>> is anyone using interactive bugscripts? I mean scripts in
>> /usr/share/bug/ which interactively demand answers from the user.
> 
> The installation-reports script is quite interactive.

Ok.

> 
> Why do you continue to want to cripple bug reporting because of 
> reportbug-ng? I appreciate there can be difficulties, but the solution is 
> not to remove existing functionality.

If no packages (or only a handfull) used this feature than asking to
depreciate this feature would have been an option, but in this case I
have to see how I can handle the problem with the terminal.


Cheers,

Bastian



-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


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

Re: anyone using interactive bugscripts

[Josselin Mouette]

Le lundi 08 juin 2009 à 14:06 +0200, Bastian Venthur a écrit :
> > The installation-reports script is quite interactive.
> 
> Ok.

> If no packages (or only a handfull) used this feature than asking to
> depreciate this feature would have been an option, but in this case I
> have to see how I can handle the problem with the terminal.

Frankly, there’s a limit to what can be done for the sake of backwards
compatibility. Such scripts will be an issue for the GTK+ frontend to
reportbug as well, and there is really not much point in asking
questions interactively.

From now on, I’d say we can either:
  * force such scripts to use an abstraction layer to prompt the
user;
  * forbid explicit user interaction in the bug script, and use
special cases for things like installation-reports.

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

Re: anyone using interactive bugscripts

[Alexander Reichle-Schmehl]

Hi!

Josselin Mouette schrieb:

> From now on, I’d say we can either:
>   * force such scripts to use an abstraction layer to prompt the
> user;

Wouldn't it be possible to use debconf for that? It already has interfaces
for different user interfaces (TTBOMK including KDE, GNOME, Dialog and
simple readline) and was designed to ask the user questions, wasn't it?

Still doesn't solve the terminal Problem for GUI bug reporting
applications, though.


Best regards,
  Alexander


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

Re: anyone using interactive bugscripts

[Bastian Venthur]

Josselin Mouette schrieb:
> Le lundi 08 juin 2009 à 14:06 +0200, Bastian Venthur a écrit :
>>> The installation-reports script is quite interactive.
>> Ok.
> 
>> If no packages (or only a handfull) used this feature than asking to
>> depreciate this feature would have been an option, but in this case I
>> have to see how I can handle the problem with the terminal.
> 
> Frankly, there’s a limit to what can be done for the sake of backwards
> compatibility. Such scripts will be an issue for the GTK+ frontend to
> reportbug as well, and there is really not much point in asking
> questions interactively.
> 
> From now on, I’d say we can either:
>   * force such scripts to use an abstraction layer to prompt the
> user;
>   * forbid explicit user interaction in the bug script, and use
> special cases for things like installation-reports.
> 

My medium term solution is to make rng depend on xterm and use that
instead of x-terminal-emulator. "xterm -e cmd" seems to return only if
the cmd returned.

I agree that reportbu'gs GTK+ frontend will have similar issues like rng
since it does not run i a shell anymore so reportbug's current approach
to just start the script in it's own shell context will not work anymore.


Cheers,

Bastian
-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


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

Re: anyone using interactive bugscripts

[Josselin Mouette]

Le lundi 08 juin 2009 à 14:31 +0200, Bastian Venthur a écrit :
> My medium term solution is to make rng depend on xterm and use that
> instead of x-terminal-emulator. "xterm -e cmd" seems to return only if
> the cmd returned.

Why not use vte (or whatever is the Qt equivalent) instead?

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

Re: anyone using interactive bugscripts

[Bastian Venthur]

Josselin Mouette schrieb:
> Le lundi 08 juin 2009 à 14:31 +0200, Bastian Venthur a écrit :
>> My medium term solution is to make rng depend on xterm and use that
>> instead of x-terminal-emulator. "xterm -e cmd" seems to return only if
>> the cmd returned.
> 
> Why not use vte (or whatever is the Qt equivalent) instead?

Because xterm works and my time is currently very limited. Patches are
welcome though.


-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


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

Hi all,

I also think that to get the best human-readability, it is important to avoid
escape and quoting characters. Using one comma plus one space as a separator,
this goal is acheived in a very large number of cases. Moreover, this is the
way things are delimited in most debian/control fields. If needed, such lists
can easily be turned into something shell-friendly through a trivial regular
expression. For the very unlikely cases where the file names contain this
separator, I propose to use wildcards (same for file names that would contain
characters that are displayed as line breaks).


So to summarise, for the following file names (one per line), we would have:

a
list of
files,that
contain
commas, or
spaces.

space-separated : a list\ of files,that contain commas,\ or spaces.
comma-separated : a,list of,files\,that,contain,commas\, or,spaces.
url-encoded : a list%20of files%2cthat contain commas%2c%20or spaces.
space-and-commas: a, list of, files,that, contain, commas??or, spaces.


To finish, here is again the example from Lars:

space-separated : foo.c README* user\ manual/*
comma-separated : foo.c,README*,user manual/*
url-encoded : foo.c README* user%20manual/*
space-and-commas: foo.c, README*, user manual/*

If users and developers are expected to sometimes cut-and-paste from
debian/copyright to the command line, then the space-separated version is of
course more useful. Otherwise, it is probably a matter of taste… Personnaly, I
dislike the comma-separated format, which I find too compact.


By the way, I found funny files with OpenGrok:

http://walrus.rave.org/source/search?q=&defs=&refs=&path='*
http://walrus.rave.org/source/search?q=&defs=&refs=&path=%2C*

Unfortunately I could not dig deeper, as “'*' or '?' not allowed as first
character in WildcardQuery”.


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: DEP 5 and directory/file names with spaces

[Jonathan Yu]

You know, this is probably a stupid question, but what's wrong with
separating file patterns with newlines, as continuations?

Files: a b
 c
 d e f
 g.*

To me it looks more readable, no escaping or quotes are necessary, at
the expense of being a bit more difficult to type than quoting (though
definitely not as difficult as escaping every space). We know that
newlines can't be part of a filename (right?!) so it seems appropriate
to do it this way.

In most cases, the Files: field will only be one or two lines per
paragraph, so it doesn't make sense *not* to do it this way.

Further, how often are masks like these really used in practice? In my
experience working on Debian Perl packages, most of the time we just
use simple masks like:

Files: inc/*

And often it's just different sets of files (ie, Module::Install or
ppport.h files) that have different copyright information that we'd
need to represent in the file anyway.

Are there examples of packages with really complicated copyright
patterns we can use, so we have a real-world example we can base our
work on? After all, the intent of this format is to be useful with
what we already have, and what we think we might have, rather than
some contrived examples that aren't likely to be encountered much, if
at all...

Cheers,

Jonathan

On Mon, Jun 8, 2009 at 3:14 AM, Lars Wirzenius wrote:
> su, 2009-06-07 kello 20:07 -0700, Steve Langasek kirjoitti:
>> 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.*
>
> url-encoded:
>
>        Files: a%2Cb c d%2Ce%2Cf g.*
>        Files: a%20b c d%20e%20f g.*
>
>> For my part I'm actually inclined to say that the latter is more readable,
>> but let's get the rationale right. :)
>
> I rather think they're all unreadable. URL encoding at least makes it
> easy to see each pattern separately from the others.
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>


--
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 Mon, Jun 08, 2009 at 11:14:04PM +0900, Charles Plessy wrote:
> space-and-commas: a, list of, files,that, contain, commas??or, spaces.

What if I have "commas, or" and "commas,,or" as two separate files?

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

[Giacomo A. Catenazzi]

Charles Plessy wrote:

I also think that to get the best human-readability, it is important to avoid
escape and quoting characters.


I don't agree, we use wild cards (or glob as written in PEP5), which are
not so human readable (if developer use non standard globs).
Additionally rules are complex, if we want to handle all possible filenames
(windows filename with space, csv and older system with comma, ...).

So IMHO we must prefer understandable rules, like shell quotes, instead
of new rules.
PS: on POSIX you can expect all characters but NULL in filename
('/' is a very special beast: you cannot create a file containing the
'/' in current locale, but if it was created in other locales there
are not (theoretically) problems.

The shell quotes reules are also more user friendly: a simple copy and
paste to more/less/... allow me to check the files, instead of requiring
me to translate proposed PEP5 rules in shell.

OTOH PEP5 allow all globs, which are too much, but I don't think people
will use strange features, i.e. I expect only '*'.

ciao
cate


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

[Philipp Kern]

On 2009-06-08, Giacomo A. Catenazzi  wrote:
> PS: on POSIX you can expect all characters but NULL in filename
> ('/' is a very special beast: you cannot create a file containing the
> '/' in current locale, but if it was created in other locales there
> are not (theoretically) problems.

Wrong: The characters composing the name may be selected from the set of all
character values excluding the slash character and the null byte.

[http://www.opengroup.org/onlinepubs/95399/basedefs/xbd_chap03.html 3.169]

Kind regards,
Philipp Kern


-- 
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 Mon, Jun 08, 2009 at 04:41:40PM +0200, Giacomo A. Catenazzi wrote:
> So IMHO we must prefer understandable rules, like shell quotes, instead
> of new rules.

+1

-- 
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: How to hack on DDTSS code ? (Re: DDTSS usage configuration for Japanese)

[Junichi Uekawa]

Hi,

At Wed, 3 Jun 2009 07:58:06 +0200,
Jens Seidel wrote:
> 
> On Wed, Jun 03, 2009 at 06:42:12AM +0900, Junichi Uekawa wrote:
> > At Fri, 29 May 2009 23:15:02 +0900,
> > Junichi Uekawa wrote:
> > > I'm looking for where to direct DDTSS related questions.
> > > 
> > > I have the following request:
> > > 
> > > 1. Japanese translation team would like to do review with
> > > debian-...@debiam.or.jp, is it possible to send mail to that list when
> > > DDTSS transaction (new translation / review) happens?
> 
> You could fetch Translation-ja.bz2 files and create a diff against the 
> previous
> file. Since the entries are sorted the diff will be readable. You should
> have no problem creating a small cron job.

I've looked at the diff, and the diff doesn't look that good.
Is there a good option for that?

There are two things missing from plain diff output

1. per-package output.

2. there's some churn in original English too, so some notion of
explaining why a translation goes away.


regards,
junichi
-- 
dan...@{netfort.gr.jp,debian.org}



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

[Giacomo A. Catenazzi]

Philipp Kern wrote:

On 2009-06-08, Giacomo A. Catenazzi  wrote:

PS: on POSIX you can expect all characters but NULL in filename
('/' is a very special beast: you cannot create a file containing the
'/' in current locale, but if it was created in other locales there
are not (theoretically) problems.


Wrong: The characters composing the name may be selected from the set of all
character values excluding the slash character and the null byte.


The  is locale dependent. Thus a file created in an other locales
could contain the character that in current locale is interpreted as
.
BTW with pathname resolution rules, the file could not be acceded, but
AFAIK the non pathname resolution system call permit 
(like readdir).

> [http://www.opengroup.org/onlinepubs/95399/basedefs/xbd_chap03.html 3.169]

You are linking the old posix specification. On the new, point 3.170, you
see that now  is written between angle parenthesis, to emphasize
that  is to be interpreted as locale dependent character.

ciao
cate


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

Naming convention for Java gluelib ?

[Mathieu Malaterre]

Hi there,

  I could find the naming convention for C# binding:

http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-gac-naming-versioning

  I am now looking for a similar page for a library that would be
wrapped in Java. What would be the convention for a foo.jar requiring
a gluelib lib.so ?

Thanks,
-- 
Mathieu


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

[Bernd Eckenfels]

In article <20090608030732.gc15...@dario.dodds.net> you wrote:
> 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. :)

Given the fact that most files will not contain spaces, it is more like:

Files: ab c de f g.*
Files: ab,c,de,f,g.*

(and the problem that people tend to use blanks after comma and you need to
account for linebreaks and indention).

Maybe it is best to use a "one-file-by-line" policy instead.

Gruss
Bernd


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

Re: Naming convention for Java gluelib ?

[Matthew Johnson]

On Mon Jun 08 18:12, Mathieu Malaterre wrote:
> Hi there,
> 
>   I could find the naming convention for C# binding:
> 
> http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-gac-naming-versioning
> 
>   I am now looking for a similar page for a library that would be
> wrapped in Java. What would be the convention for a foo.jar requiring
> a gluelib lib.so ?

Hi, this is one of the things I'd like to review at debconf this year
since I think this whole area needs reviewing.
http://www.debian.org/doc/packaging-manuals/java-policy/ exists, which
says:

   "If a Java library relies on native code, the dynamic libraries
   containing this compiled native code should be installed into the
   directory /usr/lib/jni. These dynamic libraries should be shipped in
   a separate architecture-specific package named libXXX[version]-jni.
   The package containing the Java bytecode (generally
   libXXX[version]-java) should depend on this package."

which doesn't say much about file naming. A quick sample of the archive
shows at least:

   libfoo-java.so, libjfoo.so, libfoojni-fullversion.so

so, at the moment there's not really a standard. I've CC'd debian-java
in case anyone there isn't reading debian-devel.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: anyone using interactive bugscripts

[Michael Banck]

On Mon, Jun 08, 2009 at 01:24:15PM +0200, Frans Pop wrote:
> Bastian Venthur wrote:
> > is anyone using interactive bugscripts? I mean scripts in
> > /usr/share/bug/ which interactively demand answers from the user.
> 
> The installation-reports script is quite interactive.

Maybe that is a special case, though.  We would certainly like feedback
for installations.  However, if that is the only thing standing in the
line of proper r-ng bug script support, maybe somebody can code up a
small python-gtk or python-qt (or debconf or whatever) that can be run
by the user to give feedback (advertised by the install or otherwise, of
course).


Michael


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

Re: DEP 5 proposal omits original Debianization information

[Gunnar Wolf]

Ben Finney dijo [Mon, Jun 08, 2009 at 05:27:04PM +1000]:
> > 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.*
> 
> Recording in the ‘debian/copyright’ the URL where the original source
> was obtained makes sense.
> 
> I don't see why ‘debian/copyright’ needs to “name the Debian
> maintainer(s) who were involved with its creation”; surely the best
> location for that is the already-mandatory package maintainer data on
> entries in ‘debian/changelog’.

However, having the maintainer name in debian/copyright does not only
serve the identification purpose - It also says under which licensing
scheme are the modifications licensed.

And yes, this _is_ taken into account with the proposed format - By
using the «Files: debian/*» section.

Greetings,

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

[Gunnar Wolf]

Charles Plessy dijo [Sun, Jun 07, 2009 at 11:07:15PM +0900]:
> 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?

Well, out of convenience, I'd go for escaping spaces - You can just
get the Files: field into your favorite variable and glob it. You can
just stick it in a shell variable and iterate over its values. You
don't need explicit parsing, as you would need if it were comma-separated.

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

[Gunnar Wolf]

Giacomo A. Catenazzi dijo [Mon, Jun 08, 2009 at 05:09:02PM +0200]:
> >>PS: on POSIX you can expect all characters but NULL in filename
> >>('/' is a very special beast: you cannot create a file containing the
> >>'/' in current locale, but if it was created in other locales there
> >>are not (theoretically) problems.
> >Wrong: The characters composing the name may be selected from the set of all
> >character values excluding the slash character and the null byte.
> 
> The  is locale dependent. Thus a file created in an other locales
> could contain the character that in current locale is interpreted as
> .
> BTW with pathname resolution rules, the file could not be acceded, but
> AFAIK the non pathname resolution system call permit 
> (like readdir).

Uff... I cannot help but to share this link:

http://blogs.msdn.com/michkap/archive/2005/09/17/469941.aspx

So, just for ugliness and irony sake, we could employ ₩ or ¥ as a
separator? Maybe Đ, as it bears more relation to Debian?

No?

Ok, nevermind.

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

[Jonathan Yu]

Since nobody seems to have noticed, I'd like to re-propose my idea for
consideration:

Files: a b
 c d
 e
 f

(ie, using continuation lines to specify lists of files, rather than
commas or anything else. No escaping necessary.)

On Mon, Jun 8, 2009 at 7:04 PM, Gunnar Wolf wrote:
> Giacomo A. Catenazzi dijo [Mon, Jun 08, 2009 at 05:09:02PM +0200]:
>> >>PS: on POSIX you can expect all characters but NULL in filename
>> >>('/' is a very special beast: you cannot create a file containing the
>> >>'/' in current locale, but if it was created in other locales there
>> >>are not (theoretically) problems.
>> >Wrong: The characters composing the name may be selected from the set of all
>> >character values excluding the slash character and the null byte.
>>
>> The  is locale dependent. Thus a file created in an other locales
>> could contain the character that in current locale is interpreted as
>> .
>> BTW with pathname resolution rules, the file could not be acceded, but
>> AFAIK the non pathname resolution system call permit 
>> (like readdir).
>
> Uff... I cannot help but to share this link:
>
>    http://blogs.msdn.com/michkap/archive/2005/09/17/469941.aspx
>
> So, just for ugliness and irony sake, we could employ ₩ or ¥ as a
> separator? Maybe Đ, as it bears more relation to Debian?
>
> No?
>
> Ok, nevermind.
>
> --
> Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
> PGP key 1024D/8BB527AF 2001-10-23
> Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>


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

[Xavier Oswald]

On 18:28 Mon 08 Jun , Bernd Eckenfels wrote:
> In article <20090608030732.gc15...@dario.dodds.net> you wrote:
> > 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. :)
> 
> Given the fact that most files will not contain spaces, it is more like:
> 
> Files: ab c de f g.*
> Files: ab,c,de,f,g.*
> 
> (and the problem that people tend to use blanks after comma and you need to
> account for linebreaks and indention).

That's only a parsing issue. Removing a blank or a tab at the end or the start
of a line is easy. What is relevant is after the first character and before the
last character of a line.

Greetings,
-- 
  ,''`.  ** Xavier Oswald 
 : :' :  ** Research Engineer   
 `. `'   ** GNU/LINUX Debian Developer (http://debian.org)  
   `-** Isaac Project Developer (http://isaacproject.u-strasbg.fr/) 


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

[Gunnar Wolf]

Jonathan Yu dijo [Mon, Jun 08, 2009 at 07:35:56PM -0400]:
> Since nobody seems to have noticed, I'd like to re-propose my idea for
> consideration:
> 
> Files: a b
>  c d
>  e
>  f
> 
> (ie, using continuation lines to specify lists of files, rather than
> commas or anything else. No escaping necessary.)

Yup - But the newline is also a valid (altough, yes, very uncommon)
part of a filename.

Now, this proposal keeps the field RFC822-ish — We could extrapolate
this a bit, and accept basically any non-whitespace strings delimited
by whitespace. Newlines are just one form of whitespace. And, of
course, you can escape any whitespace character to prevent it from
being treated as whitespace.

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: DEP 5 proposal omits original Debianization information

[Ben Finney]

Steve Langasek  writes:

> The one reason to include this information in debian/copyright is that
> the packagers may be copyright holders for contents under Debian.
[…]


Gunnar Wolf  writes:

> Ben Finney dijo [Mon, Jun 08, 2009 at 05:27:04PM +1000]:
> > I don't see why ‘debian/copyright’ needs to “name the Debian
> > maintainer(s) who were involved with its creation”; surely the best
> > location for that is the already-mandatory package maintainer data
> > on entries in ‘debian/changelog’.
> 
> However, having the maintainer name in debian/copyright does not only
> serve the identification purpose - It also says under which licensing
> scheme are the modifications licensed.

Yes, of course. The license terms for all parts of the work, including
the contributions from Debian maintainers, need to be written in
‘debian/copyright’.

My point was that there is no *special* need for listing “the Debian
maintainer(s) who were involved with its creation” having already
satisfied the general list-all-copyright-license-terms and the needs of
‘debian/changelog’.

-- 
 \“My theory of evolution is that Darwin was adopted.” —Steven |
  `\Wright |
_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: DEP 5 and directory/file names with spaces

[Jonathan Yu]

I'd suggest for readability/maintainability (especially for those with
editors that might mask characters like these) to have some of the
characters as part of filenames escaped in the usual form--

TAB becomes \t
CR becomes \r
LF becomes \n

etc.

I think perhaps too many escapes (backslashes) would add a great deal
of noise to strings, so something that avoids it and is more human
readable (while not sacrificing machine readability) is a great
feature to me.

Another thing is that diffs will work as expected, because there is
only one filename/file mask per line. If there are more, then it is a
slightly (very slight) cognitive load for us to determine which file
has changed, given a line of changes.

So if you replace one file with another using my idea, the diff would
look like this:
--- a   2009-06-08 19:58:16.0 -0400
+++ b   2009-06-08 19:58:36.0 -0400
@@ -1,6 +1,6 @@
 Files: a
  b c d
- e f.txt
+ i j k
  g h.cfg
  i
  k

And if you use the escape-spaces and use commas format as before, then
it would look like this:
--- a   2009-06-08 20:00:03.0 -0400
+++ b   2009-06-08 20:00:17.0 -0400
@@ -1 +1 @@
-Files: a b\ c\ d e\ f.txt g\ h.cfg i k lj
+Files: a b\ c\ d i\ j\ k g\ h.cfg i k lj

While the latter format is significantly more compact, it's also much
less readable and therefore much more prone to errors. Given the
infrequency of newlines in filenames, I think that providing an escape
sequence for them would be appropriate, and easier than dealing with
escaping each space. Anecdotal evidence would seem to suggest that
spaces and commas (which would need to be escaped) are used much more
frequently than newlines in filenames.

Granted, commas are probably less frequently used (except in a few
domain-specific uses, like CVS which uses it to store versioned files
as filename,v).

Of the three (commas, spaces, newlines) -- I think newlines are
probably used least often in filenames, and would therefore be most
appropriate as line separators.

Also, the examples mentioned above are simplistic -- but if you get
fancy with the backslashes then it can get really really confusing to
follow. While it's nice to be able to do 'ls' of those particular
files (or whatever else).. I don't think globbing ability should be
the *primary* goal. After all, we can always write a simple Perl
script to do that sort of thing (read the Files, output a glob list
which we can pass to ls).

Cheers,

Jonathan

On Mon, Jun 8, 2009 at 7:52 PM, Gunnar Wolf wrote:
> Jonathan Yu dijo [Mon, Jun 08, 2009 at 07:35:56PM -0400]:
>> Since nobody seems to have noticed, I'd like to re-propose my idea for
>> consideration:
>>
>> Files: a b
>>  c d
>>  e
>>  f
>>
>> (ie, using continuation lines to specify lists of files, rather than
>> commas or anything else. No escaping necessary.)
>
> Yup - But the newline is also a valid (altough, yes, very uncommon)
> part of a filename.
>
> Now, this proposal keeps the field RFC822-ish — We could extrapolate
> this a bit, and accept basically any non-whitespace strings delimited
> by whitespace. Newlines are just one form of whitespace. And, of
> course, you can escape any whitespace character to prevent it from
> being treated as whitespace.
>
> --
> Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
> PGP key 1024D/8BB527AF 2001-10-23
> Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF
>


--
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 Mon, 2009-06-08 at 10:15 -0400, Jonathan Yu wrote:
> 
> You know, this is probably a stupid question, but what's wrong with
> separating file patterns with newlines, as continuations?
> 
> Files: a b
>  c
>  d e f
>  g.*
> 
> To me it looks more readable, no escaping or quotes are necessary 

Well, this prohibits filenames with \n in them. Not that I do that
myself, but it is actually something that works :).

Whats so hard about simple escaping?

-Rob


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

Re: DEP 5 and directory/file names with spaces

[Jonathan Yu]

Rob:

As I mentioned, it's not that simple escaping is *hard* -- just that
it can be relatively easy to a) make mistakes; b) not be totally sure
of what the statement really means (short of doing `ls' on those
filenames of course).

Another thing is that it just looks more readable. And the (standard)
diff utility output is nicer (and more helpful). Sure, more helpful
GUI diff programs will show you the exact subsequence which has
changed... But for something so trivial, I can't think of anything
better (hopefully someone else can).

If you have a filename with an \n in it, then you'd need to escape the newline.

In general, the problem is thus:

1. You have to pick some sort of separator, X.
2. No matter what, any uses of X anywhere in a filename needs to be escaped

Now, it's easier if X is as infrequently used as possible. So while it
is indeed possible to have a newline in the middle of your filename;
it is unlikely to be so. As a result, its use as a separator is better
than using spaces or commas -- both of which are believed (by me
anyway) to occur much more frequently than newlines.

Basically, I just think that the less we need to escape, the better in
the end -- because it means less thinking for us, less likely that
we'll make a mistake. And in the end getting accurate data from the
d/copyright file is probably the most important goal.

I'm not saying this is the *most* elegant solution possible. However,
I am saying that it seems like the most elegant solution proposed thus
far (and I'm hoping to hear from others either giving some adjustments
we can make to improve this format, or proposing a much better
alternative).

Hope this helps clarify things.

Cheers,

Jonathan

On Mon, Jun 8, 2009 at 9:28 PM, Robert Collins wrote:
> On Mon, 2009-06-08 at 10:15 -0400, Jonathan Yu wrote:
>>
>> You know, this is probably a stupid question, but what's wrong with
>> separating file patterns with newlines, as continuations?
>>
>> Files: a b
>>  c
>>  d e f
>>  g.*
>>
>> To me it looks more readable, no escaping or quotes are necessary
>
> Well, this prohibits filenames with \n in them. Not that I do that
> myself, but it is actually something that works :).
>
> Whats so hard about simple escaping?
>
> -Rob
>


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

[Peter Samuelson]

First, as I've said elsewhere, this thread is just about the most
impressive bikeshedding session I've ever seen.  So I'll try and stick
to a single post, and I'm only posting because I don't think I've seen
mention of the following problem:

[Gunnar Wolf]
> Yup - But the newline is also a valid (altough, yes, very uncommon)
> part of a filename.

So are non-UTF-8 byte sequences, and I suspect those are a great deal
more common in filenames than newlines.  If you want your copyright
file to be UTF-8, you have to escape those byte sequences somehow.

I propose something very simple: ? to escape any single byte that seems
problematic in any way.  Spaces, tabs, newlines, the ISO-8859-1
registered trademark symbol, etc., etc.  I mean, we don't need this
transform to be reversible, do we?
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


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

[Peter Samuelson]

[Peter Samuelson]
> I propose something very simple: ? to escape any single byte that seems
  ^Wreplace

> problematic in any way.  Spaces, tabs, newlines, the ISO-8859-1
> registered trademark symbol, etc., etc.  I mean, we don't need this
> transform to be reversible, do we?
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
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 11:18:41PM -0400, Jonathan Yu wrote:
> Another thing is that it just looks more readable. And the (standard)
> diff utility output is nicer (and more helpful). Sure, more helpful
> GUI diff programs will show you the exact subsequence which has
> changed... But for something so trivial, I can't think of anything
> better (hopefully someone else can).

I don't see why diffs would be a major concern here.

And to the extent that they are, I think that having the file list on a
single line (with optional wrapping) is *more* useful, because it means the
context for changes will be clearer.

> If you have a filename with an \n in it, then you'd need to escape the 
> newline.

And presumably also ignore whitespace at the beginning of the line, to avoid
having to cope with parsing unindented lines that don't include a field
header.  So then you have to escape both your newline, *and* any whitespace
immediately following the newline, *and* any uses of your escape character.
Which is just downright goofy as a set of rules to try to remember when
*authoring* these files, which remains the predominant use case at this
point.  That, and the rules no longer map at all to any escaping scheme
recognized by standard commandline tools, so everybody gets to implement
their own parser.

> In general, the problem is thus:

> 1. You have to pick some sort of separator, X.
> 2. No matter what, any uses of X anywhere in a filename needs to be escaped

> Now, it's easier if X is as infrequently used as possible.

vor...@gluck> cd /srv/lintian.debian.org/laboratory/source
vor...@gluck> find . -name '*,*' | wc -l
9
vor...@gluck> find . -name '* *' | wc -l
23
vor...@gluck>

That's right, there are a total of *23* files *in all the source packages in
all the Debian archive* that have spaces in their filenames; and chances are
these are all going to be covered by globs anyway.

This is bikeshedding in the extreme.

> I'm not saying this is the *most* elegant solution possible. However,
> I am saying that it seems like the most elegant solution proposed thus
> far (and I'm hoping to hear from others either giving some adjustments
> we can make to improve this format, or proposing a much better
> alternative).

I disagree that it's elegant at all.  I think shell-style escaping would be
much better.

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