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 hop
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
> > num
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
> > number
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 documentin
* 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
[ 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
> > capab
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
>
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 reaso
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
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 tha
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 exten
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 e
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
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 the
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
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
[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 l
> 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
> 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 sh
[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 "
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 t
[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, ema
Raphael Geissert wrote:
> Kevin B. McCarty <[EMAIL PROTECTED]>
>paw-demos
This is a false positive:
% checkbashisms bin/paw-demos.in
possible bashism in bin/paw-demos.in line 54 ('select' is not POSIX):
echo "(Or use the --dir option to the script to select a different"
best regards
"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'l
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
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 th
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
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
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",
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 ala
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 foo
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
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
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
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
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_
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 checkbash
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
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 w
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
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 b
41 matches
Mail list logo
