Re: List of packages shipping shell scripts with bashisms + MBF proposal

[Ben Pfaff]

Raphael Geissert <[EMAIL PROTECTED]> writes:

> Russ Allbery wrote:
>
>> Clint Adams <[EMAIL PROTECTED]> writes:
>> 
>>> Since 0.5.6, it does not; the only number it understands is the
>>> pseudo-signal 0, mandated by POSIX.
>> 
>> Oh, sorry, you're of course correct.  I missed the 0 == n test in
>> gettrap().  Sorry about the confusion.
>> 
>>> The reason POSIX doesn't allow numbers is that they are inconsistent
>>> from platform to platform.  People who learn signals on a commercial OS
>>> of yore sometimes assume that signal 5 means something other than
>>> SIGTRAP on Debian, and script traps and kills that end up not doing what
>>> is intended.
>> 
>> This is a good point.  However, it's worth noting that the XSI extension
>> to POSIX doesn't allow you to use just any numbers.  It specifically lets
>> you use numbers for HUP, INT, QUIT, ABRT, KILL, ALRM, and TERM and nothing
>> else.  I think that's fairly portable.
>> 
>
> So should I only ignore those specifying a signal number in the 1-15 range?

I'd suggest complaining about those that specify numbers other
than 0, 1, 2, 3, 6, 9, 14, or 15.  See
http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html

-- 
Ben Pfaff 
http://benpfaff.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Periodic automake cleanup: removal of automake1.8

[Eric Dorland]

As has become custom, it's time for removal of another old automake
version. This time I've picked automake1.8. Why not automake1.7?
Mostly because only 27 packages build depend on automake1.8 versus 72
on automake1.7.

Attached is a list of packages that build depend on
automake1.8. Please fix them by:

1. Not build depending on automake in the first place. It may be
completely unnecessary, or you can ship the generated Makefile.in's in
the diff.gz. You will never have to deal with these transition
problems again.

2. Upgrade to the latest version of automake, automake1.10, to stave
off obsolescence.

In a couple of weeks I will be filing wishlist bugs with patches to
remove the automake1.8. Probably about a month after that I will start
NMUing any packages who haven't acted on the bugs. Then I will ask for
automake1.8's removal. Thanks in advance for your help.

Anibal Avelar (Fixxxer) <[EMAIL PROTECTED]>
   gsetroot

Stefan Hornburg (Racke) <[EMAIL PROTECTED]>
   courier

Kęstutis Biliūnas <[EMAIL PROTECTED]>
   liblingoteach
   lingoteach-ui

Rudi Cilibrasi <[EMAIL PROTECTED]>
   libcomplearn-mod-lzmax
   libcomplearn-mod-ppmd
   libcomplearn-mod-ppmdx
   libcomplearn-ruby

Debian FDT tools team <[EMAIL PROTECTED]>
   asn1c

Debian KDE Extras Team <[EMAIL PROTECTED]>
   kasablanca

Debian Maemo Maintainers
<[EMAIL PROTECTED]>
   sapwood

Debian QA Group <[EMAIL PROTECTED]>
   lineakd

Carlos Alberto Silombria Ibarra <[EMAIL PROTECTED]>
   libpam-blue

Robert Jordens <[EMAIL PROTECTED]>
   dvbackup
   liblrdf

Kilian Krause <[EMAIL PROTECTED]>
   ekiga

Anand Kumria <[EMAIL PROTECTED]>
   sweep

Mad Maintainers <[EMAIL PROTECTED]>
   madplay

Marcelo E. Magallon <[EMAIL PROTECTED]>
   devil

Bart Martens <[EMAIL PROTECTED]>
   par2cmdline

Parted Maintainer Team <[EMAIL PROTECTED]>
   parted

Steve M. Robbins <[EMAIL PROTECTED]>
   gmp

Emanuele Rocca <[EMAIL PROTECTED]>
   urlview

Benjamin Seidenberg <[EMAIL PROTECTED]>
   pork

Paul Slootman <[EMAIL PROTECTED]>
   isdnutils

Jörg Sommer <[EMAIL PROTECTED]>
   slrn

Jamie Wilkinson <[EMAIL PROTECTED]>
   freeglut

 

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]



signature.asc
Description: Digital signature

Re: Binaries with the same name

[David Paleino]

Il giorno Sun, 10 Feb 2008 12:16:17 +0200
Lars Wirzenius <[EMAIL PROTECTED]> ha scritto:

> On la, 2008-02-09 at 19:48 +0100, David Paleino wrote:
> > The problem is that "translate" by  does only de<->en translations,
> > while "my" translate offers a wider range of options and conversions (and
> > it's expandable, through a XML configuration file). Thus I don't believe
> > that using the alternatives system (which, I admit, I cannot use, since I
> > never needed it for my packages) would be a suitable solution. This is way
> > I suggested him to rename his binary to something less generic than
> > "translate".
> 
> In general, the problem with renaming in these kinds of situations is
> that the older package has users and some of those users are used to the
> old name of the binary in the old package. If it's just a matter of
> training users, it's not a huge deal, but there might be programmatic
> uses, which would have to be tracked down. Thus, it is generally
> speaking better to let the old package keep the binary name and pick a
> new name for the binary in the new package.

In fact, the Ubuntu package renames it to "translate-bin". But that's awkward
to me: what's the difference between "translate" and "translate-bin"? One
should have to read both manpages to understand. But if we have, for example,
"translate-de-en" and "translate", the differences are clear. However, I don't
believe I'll ever use translate-bin.

Looking at the package information of translate, it already depends on a
"trans-de-en", which is clearer to me. (trans-de-en is the dictionary,
translate is the tool using it)

> This is an example of why it's best to avoid introducing generic names
> into the name space: in a distribution as large as Debian, sooner or
> later there will be a clash. Thus, in an ideal world, neither of these
> two packages would contain a binary called translate.

Agreed on that; educating upstream is sometimes difficult though (i.e. I
haven't contacted upstream yet -- I'd like to see if the thing is solvable
inside Debian)

> In the real world, in my opinion, we stick to "first come, first
> served", meaning that you, David, should rename the binary in your
> package. This is suboptimal, but as far as I can see, the best
> situation.

As already stated, I'll do that only if really necessary / if the clash is
unsolvable. Please read further in the next paragraph.

> ...
>
> Alternatives are an option if both commands do the same thing, and have
> more or less the same command line interface. Is that the situation
> here?

I think not.

(from libtranslate-bin)
$ translate -h
Synopsis:
  translate {-? | -v | --list-services}
  translate [-s SERVICES] [-f LANG] [-t LANG] -l
  translate [-s SERVICES] [-f LANG] [-t LANG] {HTTP_URL | HTTPS_URL}
  translate [-s SERVICES] [-f LANG] [-t LANG] [--max-threads=N]
[--max-retries=N] [FILE]
...
  -l, --list-pairs List the available language pairs
$ translate -l | wc -l
948
$ 

(from translate)
$ translate -h
...
USAGE: 
translate [-niwvh] [-l languages] [words to translate]
...
$

where currently -l look for files in /usr/share/trans/. And there's just a
package providing files in the whole Debian distribution: trans-de-en:

$ apt-file search /usr/share/trans/
trans-de-en: usr/share/trans/de-en
$


I believe I can claim the use of the generic name "translate". 

Using alternatives would be the best solution to me, since they provide
"more-or-less" the same functionality. Yet, translate covers only de-en, while
libtranslate-bin covers more pairs.

(and the main difference is that translate uses a local dictionary, while
libtranslate-bin needs an Internet connection to lookup translations)

> Conflicts would be the wrong solution, as you pointed in a later mail.
> Since the only reason for the conflict is the clash in binary names,
> preventing users to have the two packages installed at the same time is
> unnecessary.

True.

I won't post an RFS before solving this situation.

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Binaries with the same name

[Lars Wirzenius]

On la, 2008-02-09 at 19:48 +0100, David Paleino wrote:
> The problem is that "translate" by  does only de<->en translations,
> while "my" translate offers a wider range of options and conversions (and it's
> expandable, through a XML configuration file). Thus I don't believe that using
> the alternatives system (which, I admit, I cannot use, since I never needed it
> for my packages) would be a suitable solution. This is way I suggested him to
> rename his binary to something less generic than "translate".

In general, the problem with renaming in these kinds of situations is
that the older package has users and some of those users are used to the
old name of the binary in the old package. If it's just a matter of
training users, it's not a huge deal, but there might be programmatic
uses, which would have to be tracked down. Thus, it is generally
speaking better to let the old package keep the binary name and pick a
new name for the binary in the new package.

This is an example of why it's best to avoid introducing generic names
into the name space: in a distribution as large as Debian, sooner or
later there will be a clash. Thus, in an ideal world, neither of these
two packages would contain a binary called translate.

In the real world, in my opinion, we stick to "first come, first
served", meaning that you, David, should rename the binary in your
package. This is suboptimal, but as far as I can see, the best
situation.

(We should also stick to shaking a finger at anibal, for introducing a
generic name. And at me for being verbose and for putting entire
paragraphs in parentheses. (It's an afflication I got from implementing
my own Lisp. (Although, actually, I did it even beforehand. (So perhaps
it's really that I implemented my own Lisp to be able to use parentheses
without making an ass of myself.

Alternatives are an option if both commands do the same thing, and have
more or less the same command line interface. Is that the situation
here?

Conflicts would be the wrong solution, as you pointed in a later mail.
Since the only reason for the conflict is the clash in binary names,
preventing users to have the two packages installed at the same time is
unnecessary.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: List of packages shipping shell scripts with bashisms + MBF proposal

[Ralf Wildenhues]

[ Please Cc: me, I don't read the list ]

* Raphael Geissert wrote:
> > I should further note that the Libtool version in experimental makes
> > use of some bashisms as optimization.  These are put in place iff, at
> > the time the Libtool package is configured, the chosen shell is deemed
> > capable enough.  This setup can break /usr/bin/libtool, for example, if
> > /bin/sh is later switched from bash to dash.
> 
> Why not just check if the shell is bash at run time? 

Well, we check for two different things, some XSI extensions, and +=
support.  We replace shell functions based on the result.

This could probably be done at run time, but then, typically, care must
be taken to do the check in a subshell, and the resulting shell function
definition in an eval expression.  This is needed because libtool also
supports very ancient and otherwise borked shells, like the Solaris one.
Both of these actions are relatively slow operations, esp. the two extra
forks would probably increase build time of some projects using libtool
by a few percent.  (CVS HEAD libtool compile mode uses typically 10
forks or less and 3 execs with a capable shell.)

Since this is so far the only issue I know with this, I'll wait for a
bug report before doing anything about it (and even then, I'll probably
consider just making /usr/bin/libtool more flexible, but not libtool
scripts generated inside user packages).

> I've seen some scripts testing for $BASH which works as expected:

We don't want to delimit ourselves to bash; the XSI extensions work fine
with several other shells; however, += only works with recent bash (>=
3.2), so testing for $BASH is not useful.

Cheers,
Ralf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: List of packages shipping shell scripts with bashisms + MBF proposal

[Ralf Wildenhues]

* Ben Pfaff wrote:
> I'd suggest complaining about those that specify numbers other
> than 0, 1, 2, 3, 6, 9, 14, or 15.  See
> http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html

Is there any system where 13 is not SIGPIPE?  I don't know of one, it's
documented in the Autoconf manual as portable, it's used by all
autoconf-generated configure scripts out there, I've never heard any
problems with it.  It would be hilarious if Debian were the only system
not to support this usage.

BTW, no matter what POSIX says, named signals are not portable to
pre-POSIX shells, which is why Autoconf and Libtool do not use them.

Cheers,
Ralf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Binaries with the same name

[David Paleino]

Il giorno Sun, 10 Feb 2008 13:23:47 +0200
Lars Wirzenius <[EMAIL PROTECTED]> ha scritto:

> On su, 2008-02-10 at 11:52 +0100, David Paleino wrote:
> > I believe I can claim the use of the generic name "translate". 
> 
> I think I wasn't clear enough in my previous mail: I don't think anyone
> should use the generic name "translate", and the fact that it is already
> being used is unfortunately. I definitely think you should pick another
> name.

Ok, then. Is translate-bin a right choice? Or is that too generic?

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Binaries with the same name

[Lars Wirzenius]

On su, 2008-02-10 at 11:52 +0100, David Paleino wrote:
> I believe I can claim the use of the generic name "translate". 

I think I wasn't clear enough in my previous mail: I don't think anyone
should use the generic name "translate", and the fact that it is already
being used is unfortunately. I definitely think you should pick another
name.

Speaking as a bystander, without decision-making power.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: List of packages shipping shell scripts with bashisms + MBF proposal

[Hendrik Sattler]

Am Sonntag 10 Februar 2008 schrieb Ralf Wildenhues:
> BTW, no matter what POSIX says, named signals are not portable to
> pre-POSIX shells, which is why Autoconf and Libtool do not use them.

POSIX may not apply to pre-POSIX shells. So what?

Creating a standard is not always a method to documenting the current way of 
doing things. Thus, implementations before the standard can differ from it.
At one point you have to go on and ignore ancient systems.

HS


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Binaries with the same name

[Frank Lichtenheld]

On Sun, Feb 10, 2008 at 12:51:46PM +0100, David Paleino wrote:
> Il giorno Sun, 10 Feb 2008 13:23:47 +0200
> Lars Wirzenius <[EMAIL PROTECTED]> ha scritto:
> 
> > On su, 2008-02-10 at 11:52 +0100, David Paleino wrote:
> > > I believe I can claim the use of the generic name "translate". 
> > 
> > I think I wasn't clear enough in my previous mail: I don't think anyone
> > should use the generic name "translate", and the fact that it is already
> > being used is unfortunately. I definitely think you should pick another
> > name.
> 
> Ok, then. Is translate-bin a right choice? Or is that too generic?

Since -bin in itself is generic, too (after all, it could probably be
appended to all programs), the result is as generic as the both parts ;)

Making a name less generic requires either qualifying it with some kind
of detail (e.g. gnome-, k, g, qt for the desktop environments and
toolkits) or better yet choose a name that has nothing to do with its
use (e.g. iceweasel).

If you want to keep the name close to the library name, you could
probably choose something like libtranslate-bin, although I personaly
find that ugly.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Binaries with the same name

[David Paleino]

(please do _not_ CC me :)

Il giorno Sun, 10 Feb 2008 13:17:30 +0100
Frank Lichtenheld <[EMAIL PROTECTED]> ha scritto:

> On Sun, Feb 10, 2008 at 12:51:46PM +0100, David Paleino wrote:
> 
> > Ok, then. Is translate-bin a right choice? Or is that too generic?
> 
> Since -bin in itself is generic, too (after all, it could probably be
> appended to all programs), the result is as generic as the both parts ;)

I suspected that :)

(it was just for uniformity -- *buntu users have that program named
translate-bin)

> Making a name less generic requires either qualifying it with some kind
> of detail (e.g. gnome-, k, g, qt for the desktop environments and
> toolkits) or better yet choose a name that has nothing to do with its
> use (e.g. iceweasel).

Well, this tool is used from CLI, thus has nothing to do with GNOME, KDE, Xfce,
*. I might think of another name, but... isn't this upstream's job? :)

> If you want to keep the name close to the library name, you could
> probably choose something like libtranslate-bin, although I personaly
> find that ugly.

Me too, that's awful.

I'll contact upstream, let's see what he thinks.

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Binaries with the same name

[Frans Pop]

David Paleino wrote:
> "My" program is not GNOME-specific. You're confusing it with
> gnome-translate, which is a GUI to libtranslate, which is the package
> we're talking about (yes, libtranslate provides a CLI command, which is
> "translate") ;)

Yeah, I had a look at the upstream website later and saw that. You did not
really make that clear in your original mail though.

Frank Lichtenheld wrote:
> Making a name less generic requires either qualifying it with some kind
> of detail (e.g. gnome-, k, g, qt for the desktop environments and
> toolkits) or better yet choose a name that has nothing to do with its
> use (e.g. iceweasel).

Agreed.
As the program requires internet access, maybe web-translate or
net-translate.

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Standardisation of the name of the patching targets included in debian/rules.

[Ben Hutchings]

On Wed, 2008-02-06 at 16:27 +0100, Stefano Zacchiroli wrote:
> On Wed, Feb 06, 2008 at 02:34:58PM +, Gerrit Pape wrote:
> > > So please go for patch/unpatch.
> > 
> > An unpatch target might be problematic.  There're packages with patches
> > that touch the upstream Makefile, and calling 'make unpatch' before
> > 'make clean' can break things; of course the clean target can depend on
> 
> Then just make unpatch depends on clean.
> 
> Anyhow, we were discussing naming here, that is the API for the package
> maintainer to implement, while you seem to dig into details on how the
> proposed target names should be internally implemented ...

"debian/rules clean" should remove patches so that dpkg-buildpackage
doesn't include the patches in the diff.gz twice.  (It might also have
to apply a patch to fix upstream's build system.  Well, so be it.)

Ben.

-- 
Ben Hutchings
I'm not a reverse psychological virus.  Please don't copy me into your sig.


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

news from mips?

[Charles Plessy]

Le Sat, Feb 09, 2008 at 08:10:20PM -0500, Philippe Cloutier a écrit :
> 
> it would be much more efficient to work on buildd 
> redundancy (or other improvements to the buildd network).

By the way, is there a plan to solve the problem of mips not keeping up
apart waiting for a miracle to happen?

Sorry to be rude, but I am just so surprised that there is a such big
problem and that apparently nothing is done. If people are working on
the issue, just let us know, they will get many kudos and everybody will
be happy. In the absence of any communication, you know, there is the
usual frustration...

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Binaries with the same name

[David Paleino]

On Sun, 10 Feb 2008 14:00:41 +0100
Frans Pop <[EMAIL PROTECTED]> wrote:

> As the program requires internet access, maybe web-translate or
> net-translate.

After talking with upstream, he noticed that "my" translate does not
necessarily need Internet access, it can use also GNU Talkfilters offline. I'm
packaging them (they're not available in Debian), and I've agreed with the
author to rename the binary to "ntranslate" (i.e. "natural translate"):

On Sun, 10 Feb 2008 16:35:00 +0100
Jean-Yves Lefort <[EMAIL PROTECTED]> wrote:

>   - net/web translate is not a good idea since services does not
> necessarily use the network. For instance the talkfilters
> service does not. Since the distinguishing feature of
> translate is that it translates between natural languages, you
> could rename it to "ntranslate" or something like that.

He was also kind of upset when I proposed him to rename the project:

On Sun, 10 Feb 2008 14:45:36 +0100
Jean-Yves Lefort <[EMAIL PROTECTED]> wrote:

> My project seems to be the most generic one, so I suggest to rename
> the other project de-translate or something.

On Sun, 10 Feb 2008 16:35:00 +0100
Jean-Yves Lefort <[EMAIL PROTECTED]> wrote:

> There is no reason to rename it. I know that my license allows it, but
> I discourage it. There are tons of generic names in /usr/bin that just
> sit there without bothering anybody.


I believe that renaming it to "ntranslate" is a good choice, I'll also update
all the references to it (the manpage, ...).


Regards,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Periodic automake cleanup: removal of automake1.8

[Frank Lichtenheld]

On Sun, Feb 10, 2008 at 03:28:18AM -0500, Eric Dorland wrote:
> Debian QA Group <[EMAIL PROTECTED]>
>lineakd

Fixed version uploaded.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Binaries with the same name

[Frank Küster]

sean finney  debian.org> writes:

> while i don't have any specific knowledge or interest in the details of this 
> particular problem, i'd just add since you haven't mentioned it as an 
> alternative that you could always Conflict with the package in question while 
> waiting for a resolution.

This is not possible; it would be a RC bug:

/--- Policy 10.1
| Two different packages must not install programs with different functionality
|  but with the same filenames. (The case of two programs having the same
| functionality but different implementations is handled via "alternatives" or
| the "Conflicts" mechanism.
\---

Regards, Frank


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Binaries with the same name

[David Paleino]

On Sun, 10 Feb 2008 17:40:28 + (UTC)
Frank Küster <[EMAIL PROTECTED]> wrote:

> sean finney  debian.org> writes:
> 
> > while i don't have any specific knowledge or interest in the details of
> > this particular problem, i'd just add since you haven't mentioned it as an 
> > alternative that you could always Conflict with the package in question
> > while waiting for a resolution.
> 
> This is not possible; it would be a RC bug:
> 
> /--- Policy 10.1
> | Two different packages must not install programs with different
> | functionality but with the same filenames. (The case of two programs
> | having the same functionality but different implementations is handled via
> | "alternatives" or the "Conflicts" mechanism.
> \---

(sorry for rearranging your statement)

Both programs provide the same basic functionality indeed (i.e. translations),
and the implementation is different. Why not using alternatives|Conflicts then?
(read as: I can't understand your Policy citation, since it seems you're
contradicting yourself).

However, as already stated, I'll rename the binary "ntranslate".

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Binaries with the same name

[Russ Allbery]

David Paleino <[EMAIL PROTECTED]> writes:
> Frank Küster <[EMAIL PROTECTED]> wrote:

>> This is not possible; it would be a RC bug:

>> /--- Policy 10.1
>> | Two different packages must not install programs with different
>> | functionality but with the same filenames. (The case of two programs
>> | having the same functionality but different implementations is handled via
>> | "alternatives" or the "Conflicts" mechanism.
>> \---

> (sorry for rearranging your statement)

> Both programs provide the same basic functionality indeed
> (i.e. translations), and the implementation is different. Why not using
> alternatives|Conflicts then?  (read as: I can't understand your Policy
> citation, since it seems you're contradicting yourself).

I've always read functionality in this context as meaning the API, not the
general task the program does.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: news from mips?

[Russ Allbery]

Charles Plessy <[EMAIL PROTECTED]> writes:

> Sorry to be rude, but I am just so surprised that there is a such big
> problem and that apparently nothing is done. If people are working on
> the issue, just let us know, they will get many kudos and everybody will
> be happy. In the absence of any communication, you know, there is the
> usual frustration...

This happens with at least one platform at some point during every release
cycle, which is probably why you're not seeing more reaction.  We're all
used to it.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

dash bug which is affecting release goal

[Thomas Bushnell BSG]

Dash has a serious bug which is causing grief.

The problem is that it overrides the system's "test" command (in
Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
inconsistent with the Debian versions.

Nothing in Posix permits this behavior, but it is tolerated by the
standard *provided* the shell does not change the syntax of the command.
Alas, dash does change the syntax of the command.

Now bug reports are being filed claiming that failure to conform to
dash's non-Posixism is a bug.  Programs which expect the behavior of
Debian's "test" command are not buggy.  What is buggy is a shell which
overrides the test command in an inconsistent way.

There is nothing bash-specific about expecting the "test" command to be
implemented in the normal way that Debian's "test" program is
implemented.  There is no reliance on a non-Posix *shell* feature when
one expects *other programs* to work normally.

Shells can override commands, but only if they don't play games with the
syntax.

Thomas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Periodic automake cleanup: removal of automake1.8

[Adeodato Simó]

* Eric Dorland [Sun, 10 Feb 2008 03:28:18 -0500]:

> 2. Upgrade to the latest version of automake, automake1.10, to stave
> off obsolescence.

For those not finding automake1.10, it's in the "automake" binary
package.

HTH,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
 Listening to: Andrés Calamaro - Elvis está vivo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Russ Allbery]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> Dash has a serious bug which is causing grief.
>
> The problem is that it overrides the system's "test" command (in
> Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
> inconsistent with the Debian versions.

Onlookers should see http://bugs.debian.org/267142 for the long history of
the previous discussions of this.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Pierre Habouzit]

On Sun, Feb 10, 2008 at 06:16:44PM +, Thomas Bushnell BSG wrote:
> Dash has a serious bug which is causing grief.
> 
> [ strip whining ]

> Alas, dash does change the syntax of the command.
> 
> [ whine whine whine ]

  What is that change please ? Last time I checked dash supported the
proper POSIX required options, so I'm surprised. Instead of whining,
actually giving a bug's reference and an example of package that is
hindert by this issue would've helped.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpyM9abNOZSx.pgp
Description: PGP signature

Re: dash bug which is affecting release goal

[Thomas Bushnell BSG]

On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote:
> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> 
> > Dash has a serious bug which is causing grief.
> >
> > The problem is that it overrides the system's "test" command (in
> > Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
> > inconsistent with the Debian versions.
> 
> Onlookers should see http://bugs.debian.org/267142 for the long history of
> the previous discussions of this.

Thank you for adding that Russ; I looked and couldn't find it right
away.

I think we need to address this before we change /bin/sh as default.
Merely papering it over is not suitable, because it means we must deal
with a changing target; every new "Posix shell" that implements slightly
different builtins will cause yet more problems.

Thomas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Thomas Bushnell BSG]

On Sun, 2008-02-10 at 19:58 +0100, Pierre Habouzit wrote:
> On Sun, Feb 10, 2008 at 06:16:44PM +, Thomas Bushnell BSG wrote:
> > Dash has a serious bug which is causing grief.
> > 
> > [ strip whining ]
> 
> > Alas, dash does change the syntax of the command.
> > 
> > [ whine whine whine ]
> 
>   What is that change please ? Last time I checked dash supported the
> proper POSIX required options, so I'm surprised. Instead of whining,
> actually giving a bug's reference and an example of package that is
> hindert by this issue would've helped.

Dash does not implement the features of Debian /bin/test.  It is not
sufficient to implement only the features of Posix /bin/test.

The policy requires that I adapt to other Posix shells, not other Posix
implementations of test, ls, and other things.

Or are you saying that it's ok for dash to override random Debian
commands in incompatible ways?

Thomas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Periodic automake cleanup: removal of automake1.8

[Eric Dorland]

* Adeodato Sim? ([EMAIL PROTECTED]) wrote:
> * Eric Dorland [Sun, 10 Feb 2008 03:28:18 -0500]:
> 
> > 2. Upgrade to the latest version of automake, automake1.10, to stave
> > off obsolescence.
> 
> For those not finding automake1.10, it's in the "automake" binary
> package.

automake currently provides automake1.10. The automake package is
meant to track the latest upstream release of automake, so directly
build depending on it is probably not a good idea, unless your
Makefile.am's are very simple.

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]



signature.asc
Description: Digital signature

Re: pre-building NEW packages, when they only introduce new binary packages

[Evgeni Golov]

On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote:

> > That probably won't make much time difference on "fast" archs (i386,
> > amd64 etc), but on slower ones like mips, mipsel etc (those sometimes
> > hold up testing transition :().
> A missing build will only slow testing migration if the package wasn't 
> built when the unstable testing delay is over. Since almost all uploads 
> to NEW are low urgency, the build would need to take over 10 days to 
> affect the time to testing migration.

pokerth 0.6-1-2 needed 13 days (uploaded on 28.01, built [but not yet
uploaded] today), so it *can* make a difference (not a really big one
though in this case)

> To speed up testing migration due 
> to missing builds, it would be much more efficient to work on buildd 
> redundancy (or other improvements to the buildd network).

More/faster buildds, nicer dependencies etc, sure. But why not this one
too? ;)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Raphael Geissert]

Pierre Habouzit wrote:

> On Sun, Feb 10, 2008 at 06:16:44PM +, Thomas Bushnell BSG wrote:
>> Dash has a serious bug which is causing grief.
>> 
>> [ strip whining ]
> 
>> Alas, dash does change the syntax of the command.
>> 
>> [ whine whine whine ]
> 
>   What is that change please ? Last time I checked dash supported the
> proper POSIX required options, so I'm surprised. Instead of whining,
> actually giving a bug's reference and an example of package that is
> hindert by this issue would've helped.
> 

I just replied to Thomas on the bug report including some information that
demonstrates that his arguments on dash not implementing some (at least the
one mentioned on the report) /usr/bin/test features is not valid.
For further reference please see #464995, which is the bug report Thomas is
talking about.

Sincerely,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

toolchain issue makes qt3 drop symbols ?

[Sune Vuorela]

Dear Debian-Devel, we need your advices.

Yesterday, we (the qt-kde packagers) uploaded qt3 version 3.3.8b. The biggest 
differences over 3.3.7 is that it is now also gplv3 licensed.

And then this bug report came:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465028 - libqt3-mt: Missing 
weak symbols for stat64 functions

basically, in qt3 3:3.3.7-9 and earlier, libqt3-mt seems to provide some 
symbols:

$ objdump -T libqt-mt.so.3 | grep stat64
004d2d9e  w   DF .text  0032  Basestat64
002f19de  w   DF .text  0032  Basefstat64
005dcba0  w   DF .text  0032  Baselstat64

These symbols are also provided by the etch package of libqt3-mt.

With this newly built qt3 3.3.8b, these symbols is no longer provided.  A 
newly rebuilt version of 3:3.3.7-9 is also not providing these symbols, which 
kind of makes it looks like a toolchain issue.

Some packages expects these symbols (gwenview, ktorrent, virtualbox-ose and 
probably many others)

The question is simply:  How to proceed?  
Do it like ubuntu did and just binNMU the packages expecting these symbols? 
Locate the packages expecting these symbols and have a gigantic Conflicts: 
line?
Kick in a major transition and rename libqt3-mt and rebuild all rdpendencies
Isolate the toolchain change and revert it?
something else?

I am not in favour of just binNMUing everything, as we breaks partial upgrades
I am also not in favour of the big mess it would be to package-namechange qt3

And I don't know if other packages are affected by the same toolchain change ?

Any advice is most appreciated.

/Sune
-- 
I cannot cancel a GPU, how does it work?

You must ping a connection on the fan of the Ultra 3D tower for inserting in 
the controller on the forward.


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

Re: dash bug which is affecting release goal

[Pierre Habouzit]

On Sun, Feb 10, 2008 at 06:57:51PM +, Russ Allbery wrote:
> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> 
> > Dash has a serious bug which is causing grief.
> >
> > The problem is that it overrides the system's "test" command (in
> > Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
> > inconsistent with the Debian versions.
> 
> Onlookers should see http://bugs.debian.org/267142 for the long history of
> the previous discussions of this.

$ dash -c 'test a = a -a b = b ; echo $?; [ a != a -o a = b ]; echo $?'
0
1

  WTF is going on please ? -a and -o are prefectly supported (at least
in the unstable's dash)

  And FWIW in the last POSIX copy I own, in the shell and utilities
document:
  * test -a
  * test -o
  * test ( )
are XSI (X/Open System Interfaces) optional features, that unlike what
Thomas pretend are properly documented.

  I agree we would like those XSI extensions to be implemented in our
/bin/sh shells. But AFAICT dash complies, even for the () grouping:

  $ dash -c 'test \( a = a -o b = 1 \) -a c = c ; echo $?'
  0

  How come no-one even *bothered* to check. I have my plate full with
whiners.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpK1WQLyBXsG.pgp
Description: PGP signature

Re: dash bug which is affecting release goal

[Pierre Habouzit]

On Sun, Feb 10, 2008 at 07:17:58PM +, Thomas Bushnell BSG wrote:
> 
> On Sun, 2008-02-10 at 19:58 +0100, Pierre Habouzit wrote:
> > On Sun, Feb 10, 2008 at 06:16:44PM +, Thomas Bushnell BSG wrote:
> > > Dash has a serious bug which is causing grief.
> > > 
> > > [ strip whining ]
> > 
> > > Alas, dash does change the syntax of the command.
> > > 
> > > [ whine whine whine ]
> > 
> >   What is that change please ? Last time I checked dash supported the
> > proper POSIX required options, so I'm surprised. Instead of whining,
> > actually giving a bug's reference and an example of package that is
> > hindert by this issue would've helped.
> 
> Dash does not implement the features of Debian /bin/test.  It is not
> sufficient to implement only the features of Posix /bin/test.
> 
> The policy requires that I adapt to other Posix shells, not other Posix
> implementations of test, ls, and other things.
> 
> Or are you saying that it's ok for dash to override random Debian
> commands in incompatible ways?

  Well, let's drop bash right away then !

$ bash -c 'type test'; zsh -c 'type test'; posh -c 'type test'; dash -c 'type 
test'
test is a shell builtin
test is a shell builtin
posh: type: not found
test is a shell builtin

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpJU8C4ScAQB.pgp
Description: PGP signature

Re: dash bug which is affecting release goal

[Thomas Bushnell BSG]

On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote:
> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> 
> > Dash has a serious bug which is causing grief.
> >
> > The problem is that it overrides the system's "test" command (in
> > Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
> > inconsistent with the Debian versions.
> 
> Onlookers should see http://bugs.debian.org/267142 for the long history of
> the previous discussions of this.

Indeed, I had forgotten that we had actually reached consensus and then
stalled at the point of getting the list of allowed-to-deviate builtins
settled.  Colin had proposed the winning solution, IIRC.

The only builtin which we identified needed to be on that list was test
itself, and the problem here was that the deviations in posh's
implementation of test would pose serious problems.

That could be solved by saying something like "test may be builtin in
inconsistent ways, provided that X, Y, and Z features still are
supported."  That could be written (by careful choice of X, Y, and Z) to
enable bash and dash to pass muster and still avoid the problems that
supposedly are raised with posh.  

The other solution--which may be an acceptible short-term one, is to
specify explicitly that shell scripts must work with Debian bash and
Debian dash.  I have no objection to that, and continue to think it is
the simplest approach.

As always, I am happy with just about any of these solutions, but the
charge-blindly-ahead method is not good.

Thomas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Pierre Habouzit]

On Sun, Feb 10, 2008 at 07:29:28PM +, Pierre Habouzit wrote:
>   How come no-one even *bothered* to check.

For the google impaired, you can find the specification here:
  http://www.opengroup.org/onlinepubs/95399/utilities/test.html

  And yes, I think it'd be a reasonable thing to ask our shells to
support the X/OPEN specification when they divert tools, and afaict they
do. Can we move on now ?


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp1NjV2OR3ul.pgp
Description: PGP signature

Re: dash bug which is affecting release goal

[Mike Bird]

On Sun February 10 2008 10:16:44 Thomas Bushnell BSG wrote:
> Shells can override commands, but only if they don't play games with the
> syntax.

Agreed. Within the Debian world, dash has redefined test rather
than building in test.  Therefore, within the Debian world, dash
is not Posix compliant.  Within the Debian world, this is a dash
bug.  Possible solutions include Debian-specific patches to either
make dash's test compatible or to disable dash's incompatible test.

--Mike Bird


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Local root exploid

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I have no debian kernel running on my machines (I better use the stable
kernel tree than the unstable 2.6). Also I am a bit confused about the
kernels and which is the current 2.6 kernel in debian. So I use this
mail instead of bugreport. Please excuse.

I just wanted to bring your attention to
http://lkml.org/lkml/2008/2/10/8 and http://lkml.org/lkml/2008/2/10/131
as well as to
http://downloads.securityfocus.com/vulnerabilities/exploits/27704.c

This might also apply to the current kernel.

Regards
   Klaus Ethgen
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBR69TO5+OKpjRpO3lAQLoYAf/T+WIX/ILU2oC18GlfQJQxh9bv03oEZjo
LDqwB/Bq8kExfNmZPwOdyhj1Yv2EU0cFPq/Z7V/v7wFKoTBniTQlO7BB9yrvntYQ
+ET3FIb7q2GKcqNiQFlJuBY8t4s4arkfSCsrd9gybIOCt5zCTog863gy7k1gtV1x
jWt/8NVsMANEDDC1HoDQ2/Pq6/gDrpG3KoiHjm0+eooqxXuV27euQBheUbs4dIM+
Tg2uK5utb+z1RQp2LJ0xp5EPqAsGMsupxsVuXMM/uNkq66l6U2lokjutC4sBpDqx
vVY47Bj0EuFJO4hvA3d2mXjpUOHoE79tCGTAiSSA2kELeXAI3q+64w==
=Cyyo
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Local root exploid

[Nico Golde]

Hi Klaus,
* Klaus Ethgen <[EMAIL PROTECTED]> [2008-02-10 21:07]:
> I have no debian kernel running on my machines (I better use the stable
> kernel tree than the unstable 2.6). Also I am a bit confused about the
> kernels and which is the current 2.6 kernel in debian. So I use this
> mail instead of bugreport. Please excuse.
> 
> I just wanted to bring your attention to
> http://lkml.org/lkml/2008/2/10/8 and http://lkml.org/lkml/2008/2/10/131
> as well as to
> http://downloads.securityfocus.com/vulnerabilities/exploits/27704.c
> 
> This might also apply to the current kernel.

Thanks for reporting this to us. Fortunately we are already 
aware of this, see bugs #464953 and #464945 in the BTS.
Kind regards
Nico
-- 
Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpqR3MRZjeox.pgp
Description: PGP signature

Bug#465124: ITP: luarocks -- deployment and management system for Lua modules

[Enrico Tassi]

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

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

   Package name: luarocks
Version: 0.4.1
Upstream Author: Hisham <[EMAIL PROTECTED]>
URL: luarocks.org
License: MIT/X
Description: 

 This package contains luarocks, a tool for managing rocks.  A lua rock is a
 bundle containing a module and some metadata like compilation instructions and
 copyright. The command line utility luarocks can download, build, install
 and remove rocks, properly handling dependencies among them and allowing
 multiple versions of the same rock to coexist. 
 .
 The tool installs system-wide rocks in /usr/local when run by the
 superuser, but a regular user can easily tune it to install rocks in his
 home directory.
 .
 This package also provides the luarocks-admin tool, needed to create a rocks
 repository, and the documentation for luarocks, describing the command line
 tools as well as the library to manipulate rocks.

The package is already almost-in-shape at

Vcs-Svn: svn://svn.debian.org/pkg-lua/packages/luarocks
Vcs-Browser: http://svn.debian.org/viewsvn/pkg-lua/packages/luarocks

Cheers
-- 
Enrico Tassi



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: List of packages shipping shell scripts with bashisms + MBF proposal

[Adam D. Barratt]

On Sat, 2008-02-09 at 16:39 -0800, Russ Allbery wrote:
> Raphael Geissert <[EMAIL PROTECTED]> writes:
> 
> > Atm, checkbashisms only complains with this:
> >
> >> _From_: bashisms-amd64-2.10.15/libtool_1.5.26-1_amd64.deb
> >> possible bashism in ./usr/bin/libtool line 1218 (trap with signal
> > numbers):
> >> trap "$run $rm $removelist; exit $EXIT_FAILURE" 1 2 15
> 
> This one is somewhat arguable.  Pure POSIX doesn't allow signal numbers,
> but the XSI extension to POSIX does and dash and posh both support them.
> We do not, in general, accept XSI extensions, but it's hard to argue
> strongly for excluding a feature that even posh supports.

That check was recently added during the lintian <-> checkbashisms sync.
If the feeling is that its incorrect, it should probably be removed from
lintian as well.

Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Binaries with the same name

[Ben Finney]

Russ Allbery <[EMAIL PROTECTED]> writes:

> David Paleino <[EMAIL PROTECTED]> writes:
> > Frank Küster <[EMAIL PROTECTED]> wrote:
> 
> >> /--- Policy 10.1
> >> | Two different packages must not install programs with different
> >> | functionality but with the same filenames. (The case of two
> >> | programs having the same functionality but different
> >> | implementations is handled via "alternatives" or the
> >> | "Conflicts" mechanism.
> >> \---
> 
> > Both programs provide the same basic functionality indeed (i.e.
> > translations), and the implementation is different. Why not using
> > alternatives|Conflicts then? (read as: I can't understand your
> > Policy citation, since it seems you're contradicting yourself).
> 
> I've always read functionality in this context as meaning the API,
> not the general task the program does.

Agreed, but I can certainly see how that confusion arises from the
policy text as it is.

Perhaps a bug report against policy to specify "API" instead of
"implementations"?

-- 
 \   “Know what I hate most? Rhetorical questions.” —Henry N. Camp |
  `\   |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: List of packages shipping shell scripts with bashisms + MBF proposal

[Adam D. Barratt]

On Sat, 2008-02-09 at 16:59 -0800, Ben Pfaff wrote:
> Raphael Geissert <[EMAIL PROTECTED]> writes:
> 
> > Atm, checkbashisms only complains with this:
> >
> >> _From_: bashisms-amd64-2.10.15/libtool_1.5.26-1_amd64.deb
> >> possible bashism in ./usr/bin/libtool line 1218 (trap with signal
> > numbers):
> 
> It's weird that it calls this a "possible bashism".  It's not a
> bashism (at most, it's an XSI-ism) and it's so pervasively
> supported that even Autoconf uses it.

In hindsight, checkbashisms may not have been the best name for the
script, but checkscriptcompliestosus isn't quite as catchy. :-)

I'm debating adding an option to ignore XSI-isms when checking scripts.
However, I will add that a) the check is also in lintian, albeit only
for maintainer scripts and b) so far as I can see, using it in scripts
with a /bin/sh shebang is technically a policy violation, even if not
one that people care about.

Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[brian m. carlson]

On Sun, Feb 10, 2008 at 02:34:37PM -0500, Thomas Bushnell BSG wrote:

On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote:

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> Dash has a serious bug which is causing grief.
>
> The problem is that it overrides the system's "test" command (in
> Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
> inconsistent with the Debian versions.


As far as I can tell, /usr/bin/test and /usr/bin/[ are completely 
useless, because none of bash, dash, posh, or zsh use them.  Maybe pdksh 
does, but that's pretty much the list of shells that could be coerced 
into being /bin/sh.  I propose we remove those executables from 
coreutils if it turns out that they are never executed.



The only builtin which we identified needed to be on that list was test
itself, and the problem here was that the deviations in posh's
implementation of test would pose serious problems.


The standard posh follows is Debian Policy.  If you change Policy, I am 
pretty sure that posh will follow[0].  Policy currently specifies a set 
of features that are required above and beyond minimal POSIX standards 
(echo -n).


Note that people often like to use local, so if that's something that 
people think should be implemented[1], then you might want to add that 
to the list as well.  IMHO, all five of the shells listed above should 
be able to be used successfully as /bin/sh.



That could be solved by saying something like "test may be builtin in
inconsistent ways, provided that X, Y, and Z features still are
supported."  That could be written (by careful choice of X, Y, and Z) to
enable bash and dash to pass muster and still avoid the problems that
supposedly are raised with posh.  


If you do not like posh's behavior, then please propose an amendment to 
policy to add additional features required by shells implementing 
/bin/sh.  I am certain posh will implement those features.



The other solution--which may be an acceptible short-term one, is to
specify explicitly that shell scripts must work with Debian bash and
Debian dash.  I have no objection to that, and continue to think it is
the simplest approach.


I think this is ridiculous.  One of the benefits of Debian is the huge 
amount of choice.  We provide at least 10 window managers, 6 desktop 
environments, and some insanely large amount of music players.  People 
should be free to choose the shell that best fits their needs, and 
providing an API (a list of required features) is far superior to 
mandating an implementation.


I don't see what your problem is with posh.  It serves a legitimate 
purpose: providing the bare minimum required by Policy.  It's useful as 
a test of Policy-compliance, and not much more, which is fine.


[0] I believe that Clint Adams said as much himself.
[1] I have no opinion on this, other than that I want udev to work with 
posh.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Binaries with the same name

[David Paleino]

On Mon, 11 Feb 2008 08:48:50 +1100
Ben Finney <[EMAIL PROTECTED]> wrote:

> Perhaps a bug report against policy to specify "API" instead of
> "implementations"?

Done. But the problem is not "implementation", it is "same functionalities". At
least, IMHO.

However, we can have further discussion on the bug report, as I've just filed
it.

Cheers,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Periodic automake cleanup: removal of automake1.8

[Jörg Sommer]

Hallo Eric,

Eric Dorland <[EMAIL PROTECTED]> wrote:
> Jörg Sommer <[EMAIL PROTECTED]>
>slrn

Fixed in experimental. I will soon provide a new version for unstable.

Bye, Jörg.
-- 
[dpkg] We are the apt. Resistance is futile. You will be packaged.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Thomas Bushnell BSG]

On Sun, 2008-02-10 at 20:34 +0100, Pierre Habouzit wrote:
> On Sun, Feb 10, 2008 at 07:17:58PM +, Thomas Bushnell BSG wrote:
> > 
> > Or are you saying that it's ok for dash to override random Debian
> > commands in incompatible ways?
> 
>   Well, let's drop bash right away then !
> 
> $ bash -c 'type test'; zsh -c 'type test'; posh -c 'type test'; dash -c 'type 
> test'
> test is a shell builtin
> test is a shell builtin
> posh: type: not found
> test is a shell builtin

Right.  The problem is that Debian policy on the question is incoherent.

It was wrong of me to describe it as a dash bug.

Thomas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Thomas Bushnell BSG]

On Sun, 2008-02-10 at 22:11 +, brian m. carlson wrote:
> On Sun, Feb 10, 2008 at 02:34:37PM -0500, Thomas Bushnell BSG wrote:
> >On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote:
> >> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> >> 
> >> > Dash has a serious bug which is causing grief.
> >> >
> >> > The problem is that it overrides the system's "test" command (in
> >> > Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
> >> > inconsistent with the Debian versions.
> 
> As far as I can tell, /usr/bin/test and /usr/bin/[ are completely 
> useless, because none of bash, dash, posh, or zsh use them.  Maybe pdksh 
> does, but that's pretty much the list of shells that could be coerced 
> into being /bin/sh.  I propose we remove those executables from 
> coreutils if it turns out that they are never executed.

There are many cases where one may well want the test program.  We need
them regardless.

> >The only builtin which we identified needed to be on that list was test
> >itself, and the problem here was that the deviations in posh's
> >implementation of test would pose serious problems.
> 
> The standard posh follows is Debian Policy.  If you change Policy, I am 
> pretty sure that posh will follow[0].  Policy currently specifies a set 
> of features that are required above and beyond minimal POSIX standards 
> (echo -n).

I don't know what the particular issue is with posh.  It was brought up
as an example in the policy discussion a while ago.

> I don't see what your problem is with posh.  It serves a legitimate 
> purpose: providing the bare minimum required by Policy.  It's useful as 
> a test of Policy-compliance, and not much more, which is fine.

I don't have a problem with posh.  It was brought up in the policy discussion 
the last time.

Thomas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Russ Allbery]

"brian m. carlson" <[EMAIL PROTECTED]> writes:

> The standard posh follows is Debian Policy.  If you change Policy, I am
> pretty sure that posh will follow[0].  Policy currently specifies a set
> of features that are required above and beyond minimal POSIX standards
> (echo -n).
>
> Note that people often like to use local, so if that's something that
> people think should be implemented[1], then you might want to add that
> to the list as well.  IMHO, all five of the shells listed above should
> be able to be used successfully as /bin/sh.

Policy already says that any shell interpretor installed as /bin/sh may be
assumed to support local and test -a/-o.  See Policy 10.4.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Thomas Bushnell BSG]

On Sun, 2008-02-10 at 11:26 -0800, Mike Bird wrote:
> On Sun February 10 2008 10:16:44 Thomas Bushnell BSG wrote:
> > Shells can override commands, but only if they don't play games with the
> > syntax.
> 
> Agreed. Within the Debian world, dash has redefined test rather
> than building in test.  Therefore, within the Debian world, dash
> is not Posix compliant.  Within the Debian world, this is a dash
> bug.  Possible solutions include Debian-specific patches to either
> make dash's test compatible or to disable dash's incompatible test.

Or to follow Colin's suggestion from the policy discussion a few years
ago, and grant a special exception, carefully crafted, for particular
shell builtins.  I have no objection to that solution.

Thomas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Pierre Habouzit]

On Sun, Feb 10, 2008 at 11:53:35PM +, Thomas Bushnell BSG wrote:
> 
> On Sun, 2008-02-10 at 20:34 +0100, Pierre Habouzit wrote:
> > On Sun, Feb 10, 2008 at 07:17:58PM +, Thomas Bushnell BSG wrote:
> > > 
> > > Or are you saying that it's ok for dash to override random Debian
> > > commands in incompatible ways?
> > 
> >   Well, let's drop bash right away then !
> > 
> > $ bash -c 'type test'; zsh -c 'type test'; posh -c 'type test'; dash -c 
> > 'type test'
> > test is a shell builtin
> > test is a shell builtin
> > posh: type: not found
> > test is a shell builtin
> 
> Right.  The problem is that Debian policy on the question is incoherent.

  Well, policy describes usage, and usage (I think) is to assume that
/bin/sh gives you a decently recent POSIX environment (I said POSIX not
GNU) and that if you rely on GNU extensions of tools (like echo -e) you
should call those commands using their full path wich can be done using
really simple tricks like:

  echo() { /bin/echo "$@" }

  Policy has absolutely no valid reasons to dictate to shells how they
are implemented, and it's a perfectly sane thing for an efficient enough
shell to implement echo, test, [, true, false and probably which as
shell builtins given their pervasive use in shell idioms.

  If the policy mandates anything else, then the policy is definitely
bogus and should be fixed, and there is nothing like "a dash bug
affecting a release goal". There are two "test" related dash bugs, one
is completely cornercase: `test \( ! -e \)` and the other is a bit more
serious though unlikely to generate an issue in the general case (the
problem with "[ '!' != ' ' ]". And after all, there is still some months
before we release to fix them instead of talking endlessly.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpSYmTnUA9BV.pgp
Description: PGP signature

Re: dash bug which is affecting release goal

[Thomas Bushnell BSG]

On Mon, 2008-02-11 at 01:54 +0100, Pierre Habouzit wrote:
>   Well, policy describes usage, and usage (I think) is to assume that
> /bin/sh gives you a decently recent POSIX environment (I said POSIX not
> GNU) and that if you rely on GNU extensions of tools (like echo -e) you
> should call those commands using their full path wich can be done using
> really simple tricks like:
> 
>   echo() { /bin/echo "$@" }

I believe Policy prohibits the use of full paths to specify programs in
the standard PATH.

>   Policy has absolutely no valid reasons to dictate to shells how they
> are implemented, and it's a perfectly sane thing for an efficient enough
> shell to implement echo, test, [, true, false and probably which as
> shell builtins given their pervasive use in shell idioms.

Policy requires that programs which provide the same names as each other
provide equivalent functionality.  No exception (currently) is made for
test.  I am not at all opposed a carefully written exception for test;
that is the substance of Colin's proposal.

Thomas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Mike Bird]

On Sun February 10 2008 15:54:36 Thomas Bushnell BSG wrote:
> Or to follow Colin's suggestion from the policy discussion a few years
> ago, and grant a special exception, carefully crafted, for particular
> shell builtins.  I have no objection to that solution.

As a Debian user rather than a DD I hope that Debian will ensure that
this solution has absolutely no effect on non-Debian scripts which
use #!/bin/sh and (perhaps unconsciously) expect test to work as in bash.

This applies to everything from tarballs of packages which are not yet
in Debian to the dozens of tiny custom scripts that everyone has for
backups or nagios extensions or adding users or emptying cameras etc etc.

Not everyone writes scripts to the same high standards as Debian but it
would still be very unfortunate if a Debian update broke them.

--Mike Bird


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[William Pitcock]

On Sun, 2008-02-10 at 22:11 +, brian m. carlson wrote:
> As far as I can tell, /usr/bin/test and /usr/bin/[ are completely 
> useless, because none of bash, dash, posh, or zsh use them.  Maybe
> pdksh 
> does, but that's pretty much the list of shells that could be coerced 
> into being /bin/sh.  I propose we remove those executables from 
> coreutils if it turns out that they are never executed.

As far as I know, test and [ are infact required to be executables.
POSIX says so. I'm .. beyond words right now at this paragraph.


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

Re: dash bug which is affecting release goal

[Thomas Bushnell BSG]

On Sun, 2008-02-10 at 18:12 -0800, Mike Bird wrote:
> On Sun February 10 2008 15:54:36 Thomas Bushnell BSG wrote:
> > Or to follow Colin's suggestion from the policy discussion a few years
> > ago, and grant a special exception, carefully crafted, for particular
> > shell builtins.  I have no objection to that solution.
> 
> As a Debian user rather than a DD I hope that Debian will ensure that
> this solution has absolutely no effect on non-Debian scripts which
> use #!/bin/sh and (perhaps unconsciously) expect test to work as in bash.

I'm afraid, that the problem here is just that.  Debian doesn't promise
that /bin/sh is bash.  Scripts which need bash are supposed to specify
bash.  At least, that's the theory.

> This applies to everything from tarballs of packages which are not yet
> in Debian to the dozens of tiny custom scripts that everyone has for
> backups or nagios extensions or adding users or emptying cameras etc etc.

Yes, that's right.

I think the idea of making dash the default /bin/sh is sure to be a
disaster.  But I have no power in that regard.  I can only hope I'm
wrong.

Thomas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Raphael Geissert]

Thomas Bushnell BSG wrote:
> 
> On Sun, 2008-02-10 at 18:12 -0800, Mike Bird wrote:
> 
>> This applies to everything from tarballs of packages which are not yet
>> in Debian to the dozens of tiny custom scripts that everyone has for
>> backups or nagios extensions or adding users or emptying cameras etc etc.
> 
> Yes, that's right.
> 
> I think the idea of making dash the default /bin/sh is sure to be a
> disaster.  But I have no power in that regard.  I can only hope I'm
> wrong.

FYI Ubuntu already made the switch some time ago and they have all of the
packages from unstable + some more. 
By filling bug reports I try to reduce the impact of making the move that in
theory should be more than safe (except for two or three known bugs on
dash).

> 
> Thomas

Cheers,
Raphael Geissert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Thomas Bushnell BSG]

On Sun, 2008-02-10 at 21:10 -0600, Raphael Geissert wrote:
> > On Sun, 2008-02-10 at 18:12 -0800, Mike Bird wrote:
> > 
> >> This applies to everything from tarballs of packages which are not yet
> >> in Debian to the dozens of tiny custom scripts that everyone has for
> >> backups or nagios extensions or adding users or emptying cameras etc etc.
> > 
> > Yes, that's right.
> > 
> > I think the idea of making dash the default /bin/sh is sure to be a
> > disaster.  But I have no power in that regard.  I can only hope I'm
> > wrong.
> 
> FYI Ubuntu already made the switch some time ago and they have all of the
> packages from unstable + some more. 
> By filling bug reports I try to reduce the impact of making the move that in
> theory should be more than safe (except for two or three known bugs on
> dash).

I think you're ignoring Mike Bird's concern.  What about custom scripts,
non-Debian things, user-written scripts, etc.?

Thomas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Russ Allbery]

Raphael Geissert <[EMAIL PROTECTED]> writes:

> I just replied to Thomas on the bug report including some information
> that demonstrates that his arguments on dash not implementing some (at
> least the one mentioned on the report) /usr/bin/test features is not
> valid.  For further reference please see #464995, which is the bug
> report Thomas is talking about.

So, to sum up the results of that bug, Thomas was specifically using a
bash feature and this entire business of the behavior of /usr/bin/test is
a red herring for the problem that started this whole discussion.

The original problem would have occurred with any /bin/sh that isn't bash
(or at least any /bin/sh that didn't implement bash's == extension).  If
we're going to have an argument about how /bin/sh should be bash, let's at
least actually have that argument rather than confusing it with an
argument over shell built-ins overriding binaries.  If bash didn't
override the /usr/bin/test binary to *add* non-standard features that the
binary doesn't support, Thomas's program would never have worked in the
first place.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Raphael Geissert]

[Please do _only_ reply to the ML, I read it]

Thomas Bushnell BSG wrote:
> 
> On Sun, 2008-02-10 at 21:10 -0600, Raphael Geissert wrote:
>> 
>> FYI Ubuntu already made the switch some time ago and they have all of the
>> packages from unstable + some more.
>> By filling bug reports I try to reduce the impact of making the move that
>> in theory should be more than safe (except for two or three known bugs on
>> dash).
> 
> I think you're ignoring Mike Bird's concern.  What about custom scripts,
> non-Debian things, user-written scripts, etc.?

They should be fixed as well, remember that as long as we continue using
bash as the default /bin/sh people who make the move will suffer the
consequences of people writing /bin/sh scripts which should really
be /bin/bash ones.
By the way, don't forget you have the choice of making bash the
default /bin/sh.

I've already changed my /bin/sh and I've found very very few
broken/missbehaving scripts.
And as a great pro my boot time is more than 50% faster now, not to mention
that the overall /bin/sh scripts run faster now.

> 
> Thomas

Cheers,
Raphael Geissert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Where to put idesk in Menu Structure?

[Anibal Avelar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi there,

Looking over the lintian reports for idesk, I've noticed that the
Apps/System section seems to be a root section now.

I can't see a suitable alternative for idesk, I think would be a good
idea a new section called inside Screen called Toys or Hacks. For now
the option more related could be Games/Toys but I think it isn't a
good option because it isn't a game.

any ideas?

Idesk, show icons on the desktop using X11 libs

- --
Anibal Avelar (FixXxeR) http://fixxxer.cc
GPG: 83B64656 - C143 4AD8 B017 53FA B742  D6AA CEEA F9F3 83B6 4656

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org

iD8DBQFHr3Ldzur584O2RlYRAoRmAJ4tpgcOews3vKo8AdsfREmR3Zd+QgCfYvWh
ph6SR11elKgosU98E0XGNEQ=
=WaZ3
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Thomas Bushnell BSG]

On Sun, 2008-02-10 at 20:39 -0800, Steve Langasek wrote:
> So we should also never upgrade /usr/bin/python, /usr/bin/perl, or
> /usr/bin/gcc to point at a new upstream version because users may have local
> programs that assume particular non-standard behavior from these programs,
> right?

I think that's a different case.  There is a big difference between a
newer version of the same program and a totally different program with
fewer features.

Still, I understand the motivation for the change and I am in support of
it.  I'm just worried also.  Perhaps I'm a needless worrywort.  But all
the attention does seem to have been focused on one specific
case--Debian packages--and not the others.

Thomas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[William Pitcock]

Hi,

On Sun, 2008-02-10 at 23:48 -0500, Thomas Bushnell BSG wrote:
> On Sun, 2008-02-10 at 20:39 -0800, Steve Langasek wrote:
> > So we should also never upgrade /usr/bin/python, /usr/bin/perl, or
> > /usr/bin/gcc to point at a new upstream version because users may
> have local
> > programs that assume particular non-standard behavior from these
> programs,
> > right?
> 
> I think that's a different case.  There is a big difference between a
> newer version of the same program and a totally different program with
> fewer features.
> 

It's possible for programs to completely change between versions. There
really is no difference in reality between switching from program A to
program B and switching from program A 1.1 to 1.2. The risk of problems
is exactly the same.

William


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

Re: dash bug which is affecting release goal

[Thomas Bushnell BSG]

On Sun, 2008-02-10 at 19:36 -0800, Russ Allbery wrote:
> Raphael Geissert <[EMAIL PROTECTED]> writes:
> 
> > I just replied to Thomas on the bug report including some information
> > that demonstrates that his arguments on dash not implementing some (at
> > least the one mentioned on the report) /usr/bin/test features is not
> > valid.  For further reference please see #464995, which is the bug
> > report Thomas is talking about.
> 
> So, to sum up the results of that bug, Thomas was specifically using a
> bash feature and this entire business of the behavior of /usr/bin/test is
> a red herring for the problem that started this whole discussion.

Actually, it's upstream's script, a genuine shell program, not just a
Debian maintainer script (the more usual case), so the right fix was to
specify /bin/bash since that is obviously what upstream was expecting
all along.

Thomas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Steve Langasek]

On Sun, Feb 10, 2008 at 10:19:15PM -0500, Thomas Bushnell BSG wrote:
> On Sun, 2008-02-10 at 21:10 -0600, Raphael Geissert wrote:
> > > On Sun, 2008-02-10 at 18:12 -0800, Mike Bird wrote:

> > >> This applies to everything from tarballs of packages which are not yet
> > >> in Debian to the dozens of tiny custom scripts that everyone has for
> > >> backups or nagios extensions or adding users or emptying cameras etc etc.

> > > Yes, that's right.

> > > I think the idea of making dash the default /bin/sh is sure to be a
> > > disaster.  But I have no power in that regard.  I can only hope I'm
> > > wrong.

> > FYI Ubuntu already made the switch some time ago and they have all of the
> > packages from unstable + some more. 
> > By filling bug reports I try to reduce the impact of making the move that in
> > theory should be more than safe (except for two or three known bugs on
> > dash).

> I think you're ignoring Mike Bird's concern.  What about custom scripts,
> non-Debian things, user-written scripts, etc.?

So we should also never upgrade /usr/bin/python, /usr/bin/perl, or
/usr/bin/gcc to point at a new upstream version because users may have local
programs that assume particular non-standard behavior from these programs,
right?

Otherwise, why should we be fretting over users who assume that /bin/sh ==
/bin/bash, when we've never promised anything of the sort?

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#465179: ITP: php-codesniffer -- tokenises PHP code and detects violations of a defined set of coding standards

[Jack Bates]

Package: wnpp
Severity: wishlist
Owner: Jack Bates <[EMAIL PROTECTED]>

* Package name: php-codesniffer
* URL : http://pear.php.net/package/PHP_CodeSniffer/
* License : BSD
  Programming Lang: PHP
  Description : tokenises PHP code and detects violations of a defined set 
of coding standards

 PHP_CodeSniffer is a PHP5 script that tokenises and "sniffs" PHP code
 to detect violations of a defined set of coding standards. It is an
 essential development tool that ensures that your code remains clean
 and consistent. It can even help prevent some common semantic errors
 made by developers.

http://cgi.sfu.ca/~jdbates/debian/pool/php-codesniffer/

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

Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]