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
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:
Fil
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
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 c
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 t
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
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 implementation
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 :
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 t
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 th
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
packag
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
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.
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
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 be
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 h
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
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 ca
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 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 Q
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. I
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
defi
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-req
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
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
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 "u
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:
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) proble
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
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 fac
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. W
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
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.*
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, esca
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 (theor
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. Catena
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
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 neces
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 t
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) wou
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
We
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 (standa
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 (
[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 t
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
45 matches
Mail list logo
