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
[Please just send messages to the ML, I read the list]
Ralf Wildenhues wrote:
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.
Detection of that kind of stuff is already in latest
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
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
Raphael Geissert wrote:
Since there's a release goal which is to default /bin/sh to dash I'd like
to do a MBF on the packages. It would be a manual MBF because there are
many false positives which I wouldn't want to be reported.
Besides providing this list so people can start fixing those
[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
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 from devscripts 2.10.13.
script ./usr/bin/foo does not appear to be a /bin/sh script; skipping
you
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 there is.
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
Raphael Geissert [EMAIL PROTECTED] writes:
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?
It's been a wishlist bug in lintian for eons. What needs to happen
Raphael Geissert [EMAIL PROTECTED] writes:
It'd be nice if lintian could provide an interface to perform an
specific check on a specific file (not on a .deb directly). That's out
of lintian's pourpose but it would be nice anyway.
One of my long-term goals for lintian is to move more of the
Thanks Russ for your input.
Russ Allbery wrote:
Raphael Geissert [EMAIL PROTECTED] writes:
The script basically uses find on those directories (under /usr/share it
only searches for '*.sh') and then uses file on those to get a new list
of those file being shell scripts which are then checked
On Wed, 2008-01-30 at 10:29 -0800, Russ Allbery wrote:
Raphael Geissert [EMAIL PROTECTED] writes:
[...]
The script basically uses find on those directories (under /usr/share it
only searches for '*.sh') and then uses file on those to get a new list
of those file being shell scripts which
Adam D. Barratt [EMAIL PROTECTED] writes:
lintian's parsing code certainly sounds better (mainly because
checkbashisms is based on an old version of the lintian code) but, from
a quick look, checkbashisms flags more issues than lintian does. We do
appear to be missing a few though; I'll have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello everybody,
[Please only reply to -devel]
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 from devscripts
On Jan 30, 2008 10:58 AM, Raphael Geissert [EMAIL PROTECTED] wrote:
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 from devscripts 2.10.13.
Has there been
Cyril Brulebois 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
And as for debian/rules Lucas Nussbaum rebuilt the archive with
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
Cheers,
--
Cyril Brulebois
pgpu6gpae1W7J.pgp
Description: PGP signature
Paul Wise wrote:
I really really think we need a way to integrate these myriad QA
checks into the PTS and DDPO and the page I proposed in #461898.
I'm going to generate a BDB with the information from the lintian test on
amd64 as soon as I find some time for it and somewhere to place it :)
43 matches
Mail list logo
