the configure scripts that
*don't* have bashisms in them run at dash's speed on Debian, and the fallback
code for when $LINENO isn't available at all is a monstrosity that I would like
to scrap.
zw
Quoting Richard Laager (2021-11-10 20:16:31)
> Can we just enable LINENO in dash then, let the other packages FTBFS, and
> people who care about the packages that FTBFS can either:
in the best case, a package will FTBFS but it can also happen that the
configure script will just do something
"Andrej Shadura" writes:
> Well, we might make bash non-essential at one point. OTOH development
> systems are likely to have it anyway.
A compromise could be to make it build-essential instead.
- ilmari
On 11/10/21 12:50 PM, Andrej Shadura wrote:
On Wed, 10 Nov 2021, at 19:18, Sam Hartman wrote:
I understand that it's generally better to fix bashisms in configure
scripts.
Is it possible to force autoconf to prefer bash for a given configure
script if it's difficult or undesirable to fix
>>>>> "Andrej" == Andrej Shadura writes:
Andrej> Hi all, Yesterday I uploaded dash with LINENO feature
Andrej> switched on again, which has the side effect of exposing
Andrej> bashisms in configure scripts. Previously, they were
Andrej> obscur
On 2010-05-26 00:18:23 +0200, David Weinehall wrote:
You're getting things the wrong way around. The version of dash that
will be put in experimental will be the correct one, the one in unstable
will be the crippled one. The reason things fails isn't because of
dash, but because of sloppy
Stefan Fritsch wrote:
On Tuesday 25 May 2010, Raphael Geissert wrote:
1. If your name is on the list at [2] please check at [3] the .dsc
file that corresponds to the source packages you co-/maintain,
review and fix. The .dsc files contain checkbashisms' output.
Do you want to start a
On Wed, May 26, 2010 at 08:05:32AM +0200, Lucas Nussbaum wrote:
I'm still feeling uneasy about this whole bash-dash thing. We sacrified
a lot of usability in the name of POSIX compliance (only a minority of
users care) and a few seconds spared during boot (who cares? I only boot
my laptop for
On Tuesday 25 May 2010, Raphael Geissert wrote:
1. If your name is on the list at [2] please check at [3] the .dsc
file that corresponds to the source packages you co-/maintain,
review and fix. The .dsc files contain checkbashisms' output.
Do you want to start a list with errors that can be
Hi,
I'm still feeling uneasy about this whole bash-dash thing. We sacrified
a lot of usability in the name of POSIX compliance (only a minority of
users care) and a few seconds spared during boot (who cares? I only boot
my laptop for kernel upgrades).
Was is really the right path to follow?
On 25/05/10 at 23:10 +0100, Neil Williams wrote:
On Tue, 25 May 2010 16:13:36 -0500
Raphael Geissert geiss...@debian.org wrote:
A much more sane list is in the bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=failed-dash.txt;att=1;bug=582952
124 source packages.
On Tue, 25 May 2010, Peter Samuelson wrote:
And more false positives:
possible bashism in ./configure line 44 ($BASH_SOMETHING):
if test -z $BASH_VERSION$ZSH_VERSION \
(test X`print -r -- $as_echo` = X$as_echo) 2/dev/null; then
possible bashism in ./configure line 367 (should be word
On 05/26/2010 08:05 AM, Lucas Nussbaum wrote:
Hi,
I'm still feeling uneasy about this whole bash-dash thing. We sacrified
a lot of usability in the name of POSIX compliance (only a minority of
users care) and a few seconds spared during boot (who cares? I only boot
my laptop for kernel
./configure from configure.ac, all this would be a waste
of effort anyway.
It is not about whether dash can handle it or not. The bashisms don't come
from autoconf, the come from what the author's added to configure.in{,.in}.
I beg to differ, at least some of them don't come from configure
On mer., 2010-05-26 at 08:29 +0200, Yves-Alexis Perez wrote:
It is not about whether dash can handle it or not. The bashisms
don't come
from autoconf, the come from what the author's added to
configure.in{,.in}.
I beg to differ, at least some of them don't come from configure.*.
One
This doesn't necessarily mean that we are drowned by bashisms, as some of
those may already be fixed by Debian- provided packages or might affect
unused code
s/packages/patches/
Don't you think we should run the test *after* the patches got applied?
Michael
--
Michael Meskes
Michael
On Tue, May 25, 2010 at 11:55:58PM +0200, Frans Pop wrote:
For example, almost all udebs are listed. Why? Because udebs execute
busybox shell as /bin/sh, which happens to be fairly compatible with bash.
The busybox /bin/sh is also a dash, but a different version than the
dash package.
Bastian
On 26/05/10 08:07, Lucas Nussbaum wrote:
On 25/05/10 at 23:10 +0100, Neil Williams wrote:
124 source packages. Bad, but not as crazy as 1,540.
(I've heard of off-by-one errors but off-by-one-order-of-magnitude is a
stretch.)
No. 124 is the number of packages that failed to build. Not the
On 26/05/10 at 11:55 +0200, Emilio Pozuelo Monfort wrote:
On 26/05/10 08:07, Lucas Nussbaum wrote:
On 25/05/10 at 23:10 +0100, Neil Williams wrote:
124 source packages. Bad, but not as crazy as 1,540.
(I've heard of off-by-one errors but off-by-one-order-of-magnitude is a
stretch.)
On 26/05/10 13:14, Lucas Nussbaum wrote:
On 26/05/10 at 11:55 +0200, Emilio Pozuelo Monfort wrote:
Right. That's exactly why I suggested debdiffing the resulting binary
packages
from a new and an old dash.
Are you volunteering? :-)
No. I'm not volunteering on adding LINENO support back to
On mercredi 26 mai 2010 02:39:52 Raphael Geissert wrote:
[SNIP]
Yes, $BASH_SOMETHING is just used to make it easier to see that the
following code (probably a bashism) is only executed after checking the
shell is actually bash. That and the other FP are the most common ones, yet
not that
On Wednesday 26 May 2010 03:00:58 Michael Meskes wrote:
Don't you think we should run the test *after* the patches got applied?
That's done if the package uses format 3.0 (quilt).
Regards,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
--
To UNSUBSCRIBE, email to
automatically.
With this behaviour change, bashisms in configure scripts are now making
packages FTBFS[1]. Due to some bugs in checkbashisms, most of the code in
configure scripts was skipped, making those bashisms invisible.
An archive-wide check of the source packages gives an estimate of over
[Raphael Geissert]
Hi everyone,
dash recently added support for the magic variable $LINENO, which
was the last piece to make it POSIX compliant. However, this change
made the autoconf- generated configure scripts use dash to execute
the script's code. Without support for LINENO, configure
On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
[1] http://bugs.debian.org/582952
[2] http://people.debian.org/~geissert/source-bashisms/dd-list.txt
That is just a list of all packages per person? It's listing
packages that have no shell script in it at all, and also
don't
.
Isn't it a bit late in the release cycle for a change with such a major
impact?
An archive-wide check of the source packages gives an estimate of over
3425 source packages with bashisms in *any file*.
This and the file under [2] must contain a *huge* amount of false
positives.
For example
On Tue, May 25, 2010 at 23:45:56 +0200, Petter Reinholdtsen wrote:
What about reverting this change in dash until after Squeeze is
released? Now seem like a bad time to make thousand of packages in
Debian fail to build from source. :)
That's the plan, see #582952.
Cheers,
Julien
3425
source packages with bashisms in *any file*. This doesn't necessarily mean
that
we are drowned by bashisms, as some of those may already be fixed by Debian-
provided packages or might affect unused code (either at the build process or
code not included in the final binary package
On Tue, May 25, 2010 at 11:51:30PM +0200, Kurt Roeckx wrote:
On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
[1] http://bugs.debian.org/582952
[2] http://people.debian.org/~geissert/source-bashisms/dd-list.txt
That is just a list of all packages per person? It's listing
On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
1. If your name is on the list at [2] please check at [3] the .dsc file that
corresponds to the source packages you co-/maintain, review and fix. The
.dsc
files contain checkbashisms' output.
I get alot of them that have:
On 25/05/10 23:45, Petter Reinholdtsen wrote:
What about reverting this change in dash until after Squeeze is
released? Now seem like a bad time to make thousand of packages in
Debian fail to build from source. :)
See bug #582952.
Emilio
--
To UNSUBSCRIBE, email to
On Tue, 25 May 2010 16:13:36 -0500
Raphael Geissert geiss...@debian.org wrote:
A much more sane list is in the bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=failed-dash.txt;att=1;bug=582952
124 source packages. Bad, but not as crazy as 1,540.
(I've heard of
On Tue, May 25, 2010 at 11:10:10PM +0100, Neil Williams wrote:
On Tue, 25 May 2010 16:13:36 -0500
Raphael Geissert geiss...@debian.org wrote:
A much more sane list is in the bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=failed-dash.txt;att=1;bug=582952
124
On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
1. If your name is on the list at [2] please check at [3] the .dsc file that
corresponds to the source packages you co-/maintain, review and fix. The
.dsc
files contain checkbashisms' output.
Is there some kind of
I demand that Kurt Roeckx may or may not have written...
On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
1. If your name is on the list at [2] please check at [3] the .dsc file
that corresponds to the source packages you co-/maintain, review and fix.
The .dsc files contain
This one time, at band camp, Kurt Roeckx said:
On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
1. If your name is on the list at [2] please check at [3] the .dsc file
that
corresponds to the source packages you co-/maintain, review and fix. The
.dsc
files
On 25/05/10 23:13, Raphael Geissert wrote:
Normally I would process the results and file the bug reports myself but I
don't have and won't have time to do it any time soon. I've already tried to
find some time yesterday and today to work on checkbashisms to come up with
bug
fixes[4], and
[Kurt Roeckx]
I get alot of them that have:
possible bashism in ./configure line 22 ($BASH_SOMETHING):
elif test -n ${BASH_VERSION+set} (set -o posix) /dev/null 21; then
possible bashism in ./configure line 147 ($BASH_SOMETHING):
$as_unset BASH_ENV || test ${BASH_ENV+set} !=
Kurt Roeckx wrote:
On Tue, May 25, 2010 at 11:51:30PM +0200, Kurt Roeckx wrote:
On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
[1] http://bugs.debian.org/582952
[2] http://people.debian.org/~geissert/source-bashisms/dd-list.txt
That is just a list of all packages per
this work for ONE VARIABLE???!?!?!
POSIX compliance too.
An archive-wide check of the source packages gives an estimate of over
3425 source packages with bashisms in *any file*. This doesn't
necessarily mean that we are drowned by bashisms, as some of those may
already be fixed by Debian- provided
Darren Salt wrote:
I demand that Kurt Roeckx may or may not have written...
On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
1. If your name is on the list at [2] please check at [3] the .dsc file
that corresponds to the source packages you co-/maintain, review and
fix.
Kurt Roeckx wrote:
On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
1. If your name is on the list at [2] please check at [3] the .dsc file
that
corresponds to the source packages you co-/maintain, review and fix. The
.dsc files contain checkbashisms' output.
Is there
Emilio Pozuelo Monfort wrote:
It would also be good to build all the archive (or all the affected
packages) with and without LINENO support in dash, and then debdiff'ing
them and check if they are equal or not.
A full archive rebuild was already done by Lucas (see the br against dash
for
Hi,
Given the recent responses I'm providing some more info, updates, and hints.
Raphael Geissert wrote:
This doesn't necessarily mean that we are drowned by bashisms, as some of
those may already be fixed by Debian- provided packages or might affect
unused code
s/packages/patches/
(before
Le mercredi 15 avril 2009 à 23:05 -0500, Manoj Srivastava a écrit :
So, no, policy does not just document current practice. Policy
tries to document what is right.
I think it should be both. When we do things right, they should be
specified in the Policy, and there’s no point
Le mercredi 15 avril 2009 à 17:12 -0500, Raphael Geissert a écrit :
Then there must be some sort of missunderstanding. My intention was not to
troll, but to demonstrate the implications of what you said. I would like
to apologise for my previous message as I had understood something
completely
On Thu, Apr 16 2009, Josselin Mouette wrote:
Le mercredi 15 avril 2009 à 23:05 -0500, Manoj Srivastava a écrit :
So, no, policy does not just document current practice. Policy
tries to document what is right.
I think it should be both. When we do things right, they should be
Le mardi 14 avril 2009 à 18:45 -0500, Raphael Geissert a écrit :
what feature provided by dash is being deprecated?
Like Russ said, if there's any feature not covered by policy that is
reasonable to be required please say so.
It is not the role of the policy to specify the exact requirements
Josselin Mouette j...@debian.org writes:
It is not the role of the policy to specify the exact requirements of
the /bin/sh implementation.
It is, however, the role of Policy to specify the minimum required feature
set that all scripts can assume.
Actually it would be better to specify that
Le mercredi 15 avril 2009 à 02:16 -0700, Russ Allbery a écrit :
Actually it would be better to specify that scripts must work with both
sh implementations available in Debian, being bash and dash, rather than
making nothing more than a fork of the POSIX spec.
The advantage of the current
Josselin Mouette wrote:
Le mercredi 15 avril 2009 à 02:16 -0700, Russ Allbery a écrit :
Actually it would be better to specify that scripts must work with both
sh implementations available in Debian, being bash and dash, rather
than making nothing more than a fork of the POSIX spec.
The
Le mercredi 15 avril 2009 à 11:44 -0500, Raphael Geissert a écrit :
Policy documents practice. When that new /bin/sh exists, you can change
bash is the current /bin/sh, from your statements I could imply that we
should require all /bin/sh's to support: b0rken bash arrrays, shell
regexes!,
Josselin Mouette j...@debian.org writes:
Le mercredi 15 avril 2009 à 02:16 -0700, Russ Allbery a écrit :
The advantage of the current Policy approach is that we have some hope
of introducing a new /bin/sh down the road, and we don't require that
packages comply with bugs in dash that should
Josselin Mouette wrote:
Le mercredi 15 avril 2009 à 11:44 -0500, Raphael Geissert a écrit :
[...]
And taking your statement to the extreme, it means that if zsh was used
as /bin/sh then no other shell interpreter could ever be used as /bin/sh
ever again but a fork of zsh.
I’m proposing
On Wed, Apr 15 2009, Josselin Mouette wrote:
Policy documents practice.
I wish people would not say that. It is not true; and hasn't
been. And, moreover, we would not _want_ that to be true; there should
be no excuse to justify wanting to enshrine broken or bad practices
into policy.
On Sun, Apr 12, 2009 at 09:35:37PM +0200, Marco d'Itri wrote:
* Bashisms-free archive
This is useless. You are basically proposing to remove every usage of
local and a few other directives for no good reason but at a huge cost.
Beside local per se, what is exactly the problem? If you badly
On Apr 14, Stefano Zacchiroli z...@debian.org wrote:
Beside local per se, what is exactly the problem? If you badly need
bash-specific features you can use /bin/bash as the interpreter.
Every deviation from upstream has a cost, which needs to be justified
by a cost-benefits analisys.
The point
Marco d'Itri wrote:
[...]
The point is not to eliminate bashism but dashism, and so far there are
no demonstrated benefits to deprecating features available in dash but
not in posh.
what feature provided by dash is being deprecated?
Like Russ said, if there's any feature not covered by policy
On Apr 15, Raphael Geissert atomo64+deb...@gmail.com wrote:
what feature provided by dash is being deprecated?
You are the one who started the thread. Please come back when you will
actually know what you are proposing exactly.
Like Russ said, if there's any feature not covered by policy that
Hello everyone,
I would like to propose the following Release Goals for squeeze:
* Dash as default /bin/sh
A lot of work was done on this RG already for lenny but, sadly, it didn't make
it. Further improvements to checkbashisms as well as support for checking for
bashisms in all /bin/sh
On Apr 12, Raphael Geissert atom...@gmail.com wrote:
* Dash as default /bin/sh
This is good.
* Bashisms-free archive
This is useless. You are basically proposing to remove every usage of
local and a few other directives for no good reason but at a huge cost.
needed to support dash as /bin/sh
m...@linux.it (Marco d'Itri) writes:
On Apr 12, Raphael Geissert atom...@gmail.com wrote:
* Bashisms-free archive
This is useless. You are basically proposing to remove every usage of
local and a few other directives for no good reason but at a huge
cost.
No, he's not -- look
On Sun, Apr 12, 2009 at 09:35:37PM +0200, Marco d'Itri wrote:
* Bashisms-free archive
This is useless. You are basically proposing to remove every usage of
local and a few other directives for no good reason but at a huge cost.
Policy specifically states that use of local is permitted [0
On Apr 12, Roberto C. Sánchez robe...@connexer.com wrote:
Policy specifically states that use of local is permitted [0]:
So exactly what do you want to disallow which is supported by dash but
not by policy, and for which purpose?
--
ciao,
Marco
signature.asc
Description: Digital signature
Marco d'Itri wrote:
On Apr 12, Roberto C. Sánchez robe...@connexer.com wrote:
Policy specifically states that use of local is permitted [0]:
So exactly what do you want to disallow which is supported by dash but
not by policy, and for which purpose?
I don't have a list at hand (I do have
On Apr 12, Raphael Geissert atomo64+deb...@gmail.com wrote:
I don't have a list at hand (I do have a sort of list in another machine
which is unreachable atm); but the first one that comes to my mind is the
use of 'type', it's output is unreliable and in some shell interpreters it
is not
Marco d'Itri wrote:
On Apr 12, Raphael Geissert atomo64+deb...@gmail.com wrote:
I don't have a list at hand (I do have a sort of list in another machine
which is unreachable atm); but the first one that comes to my mind is the
use of 'type', it's output is unreliable and in some shell
On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote:
Roberto C. Sanchez [EMAIL PROTECTED]
sasl2-bin (U)
This will be handled by the Cyrus-SASL team.
shorewall-common
shorewall-lite
These two are false positives.
webcpp
This one I am investigating and hope to
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
[ 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
* 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
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
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
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
checkbashisms and,
hopefully, those false positives are gone.
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
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
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
Russ Allbery [EMAIL PROTECTED] writes:
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.
Is there a
Ben Pfaff [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] writes:
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
On Sat, Feb 09, 2008 at 04:39:11PM -0800, Russ Allbery wrote:
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
Clint Adams [EMAIL PROTECTED] writes:
On Sat, Feb 09, 2008 at 04:39:11PM -0800, Russ Allbery wrote:
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,
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
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
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
Kurt Roeckx [EMAIL PROTECTED]
libtool
Libtool is a false positive. The script /usr/bin/libtool contains some
C program text embedded in a here document.
I should further note that the Libtool version in experimental makes
use of some bashisms as optimization. These are put in place iff
[Raphael Geissert]
Debian sysvinit maintainers [EMAIL PROTECTED]
sysv-rc
Probably false alarm, as it has been successfully used on systems with
dash as /bin/sh. Please report a bug with the details if it still got
bashism.
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email
bashisms I
now ask if there are any objections on starting to MBF based on the test
results. Of course any other kind of feedback is more than welcome.
No objections to start MBF then?
Cheers,
Raphael Geissert
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe
[Raphael Geissert]
No objections to start MBF then?
Not from me, at least. Make sure to usertag the bugs properly,
though, as a release goal bug. (tag goal-dash, user debian-release@).
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
should not list this as a problem. If a script is not a sh
script, there's no reason to check for bashisms imho, especially if you
have scripts for psh, ksh, csh or other weird shells.
Best regards,
Bernd
--
Bernd Zeimetz
[EMAIL PROTECTED] http://bzed.de
On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote:
[Please only reply to -devel]
Reply-To?
I just completed an archive wide check on amd64/all packages by searching
for shell scripts in /bin:/usr/bin:/sbin:/usr/sbin:/etc/init.d:/usr/share
and checking them with checkbashisms
On Jan 30, 2008 11:31 AM, Cyril Brulebois
[EMAIL PROTECTED] wrote:
On 30/01/2008, Paul Wise wrote:
Has there been any bashisms checks on maintainer scripts (postinst/etc)?
There's already:
http://lintian.debian.org/reports/Tpossible-bashism-in-maintainer-script.html
Ah, so
On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote:
Stefano Zacchiroli [EMAIL PROTECTED]
camlp5 (U)
This is a false positive:
$ checkbashisms /usr/bin/mkcamlp5
possible bashism in /usr/bin/mkcamlp5 line 43 (let ...):
echo let _ = Dynlink.add_available_units crc_unit_list
Steffen Grunewald [EMAIL PROTECTED] writes:
On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote:
[Please only reply to -devel]
Reply-To?
That's a field defined (in RFC 2822) as specifying where posts
intended individually to the author (replies) should be sent. It
would not
On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote:
Hamish Moffatt [EMAIL PROTECTED]
ax25-tools (U)
hf (U)
Thanks, fixed these two.
libguilegtk-1.2-dev
False alarm: the /usr/bin/build-gtk-guile script is actually in guile,
but has a quick shell wrapper at the top.
Paul Wise wrote:
There doesn't seem to be a lintian check for what Raphael has checked
for though.
Raphael, perhaps you could submit a bug+patch to lintian if you haven't
already?
If there's any chance to get it in lintian it'd be great.
I haven't sent any bug/patch for it, hope Russ (or
On mar, 2008-01-29 at 19:58 -0600, Raphael Geissert wrote:
Rene Mayorga [EMAIL PROTECTED]
afbackup
afbackup-client
False positive
Both one have csh scripts.
Cheers
--
Rene Mauricio Mayorga
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
Ben Finney wrote:
Steffen Grunewald [EMAIL PROTECTED] writes:
On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote:
[Please only reply to -devel]
Reply-To?
I sent the email via KNode/gmane, AFAIR there's no way to set a Reply-To.
That's a field defined (in RFC 2822) as
On Wed, Jan 30, 2008 at 11:49:23PM +1100, Hamish Moffatt wrote:
On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote:
libguilegtk-1.2-dev
False alarm: the /usr/bin/build-gtk-guile script is actually in guile,
but has a quick shell wrapper at the top. checkbashisms is fooled.
Package: devscripts
Version: 2.10.13
User: [EMAIL PROTECTED]
Usertags: checkbashisms
Luis Rodrigo Gallardo Cruz wrote:
On Wed, Jan 30, 2008 at 11:49:23PM +1100, Hamish Moffatt wrote:
On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote:
libguilegtk-1.2-dev
False alarm: the
Stefano Zacchiroli [EMAIL PROTECTED] writes:
This is a false positive:
$ checkbashisms /usr/bin/mkcamlp5
possible bashism in /usr/bin/mkcamlp5 line 43 (let ...):
echo let _ = Dynlink.add_available_units crc_unit_list $CRC.ml
checkbashisms is complaining about the let, which is part
1 - 100 of 123 matches
Mail list logo
