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

[Raphael Geissert]

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?

Cheers,
Raphael Geissert


-- 
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

[Raphael Geissert]

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.

At the moment I'm not filling reports for packages shipping /bin/sh scripts
for which checkbashisms only complains about trap/kill with signal number.

Cheers,
Raphael


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

Re: Bug#464901: ITP: pcre-light -- a lightweight GHC library for Perl 5 compatible regular expressions

[Christian Perrier]

Quoting Steve Langasek ([EMAIL PROTECTED]):

> > >   Description : a lightweight GHC library for Perl 5 compatible 
> > > regular expressions
> 
> > Being lecc cryptic would help, here.
> 
> > I suggest expanding "GHC" if possible, at the expense of "Perl 5"
> > "lightweight" and/or "compatible".
> 
> Perhaps:
> 
> Description: a Haskell library for Perl 5-compatible regular expressions


s/a // would of course be my next suggestion..

(Steve, no need to repeat that you disagree with DevRef 6.2.2 on that
matter..:-))



signature.asc
Description: Digital signature

Re: Bug#464863: ITP: qca2-plugin-cyrus-sasl -- SASL support for the Qt Cryptographic Architecture

[Christian Perrier]

Quoting Christian Perrier ([EMAIL PROTECTED]):

> > Description: SASL support for the Qt Cryptographic Architecture
> 
> I suggest removing the extra capitalization for "cryptographic" and 
> "architecture".
> 

Hmmm, yes. I missed the relation with the "QCA" acronym.

I suggest reintroducing that acronym somewhere in the description,
then, if this is something that's often used.

Something like "QCA (Qt Cryptographic Architecture)" but rather in the
long description.

-- 




signature.asc
Description: Digital signature

Re: Bug#464901: ITP: pcre-light -- a lightweight GHC library for Perl 5 compatible regular expressions

[Steve Langasek]

On Sun, Feb 10, 2008 at 06:43:59AM +0100, Christian Perrier wrote:
> Quoting Recai Oktaş ([EMAIL PROTECTED]):
> > Package: wnpp
> > Severity: wishlist
> > Owner: "Recai Oktaş" <[EMAIL PROTECTED]>
> > 
> > * Package name: pcre-light
> >   Version : 0.3.1
> >   Upstream Author : Don Stewart <[EMAIL PROTECTED]>
> > * URL : http://www.example.org/
> > * License : BSD
> >   Programming Lang: Haskell
> >   Description : a lightweight GHC library for Perl 5 compatible regular 
> > expressions

> Being lecc cryptic would help, here.

> I suggest expanding "GHC" if possible, at the expense of "Perl 5"
> "lightweight" and/or "compatible".

Perhaps:

Description: a Haskell library for Perl 5-compatible regular expressions


-- 
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]

Re: Bug#464863: ITP: qca2-plugin-cyrus-sasl -- SASL support for the Qt Cryptographic Architecture

[Steve Langasek]

On Sun, Feb 10, 2008 at 06:42:13AM +0100, Christian Perrier wrote:
> Quoting Matthew Rosewarne ([EMAIL PROTECTED]):
> > Package: wnpp
> > Severity: wishlist
> > X-Debbugs-CC: debian-devel@lists.debian.org

> >Package name: qca2-plugin-cyrus-sasl
> > Version: 2.0.0~beta3
> > Upstream Author: Justin Karneges <[EMAIL PROTECTED]>
> > URL: http://delta.affinix.com/qca/
> > License: LGPL
> > Description: SASL support for the Qt Cryptographic Architecture

> I suggest removing the extra capitalization for "cryptographic" and
> "architecture".

"Qt Cryptographic Architecture" appears to be a proper name for an API.

-- 
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]

Re: Bug#464957: ITP: html-xml-utils -- manipulate HTML and XML files

[Christian Perrier]

Quoting Daniel Leidert ([EMAIL PROTECTED]):
> Package: wnpp
> Severity: wishlist
> Owner: Daniel Leidert <[EMAIL PROTECTED]>
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> * Package name: html-xml-utils
>   Version : 4.4
>   Upstream Author : Bert Bos <[EMAIL PROTECTED]>
> * URL : http://www.w3.org/Tools/HTML-XML-utils/
> * License : W3C Software License (v20021231)
>   Programming Lang: C
>   Description : manipulate HTML and XML files


The general style recommended by the Developers Reference is avoiding
verb sentences in synopsis.

May I suggest:

"HTML and XML manipulation utilities"




signature.asc
Description: Digital signature

Re: Bug#464954: ITP: ixp4xx-microcode -- non-free firmware for the ixp4xx ethernet

[Christian Perrier]

Quoting Joey Hess ([EMAIL PROTECTED]):


> The nslu2 needs non-free firmware for its ethernet. This is currently
> distributed in the d-i installation images on slug-firmware.net.

s/ethernet/Ethernet?




signature.asc
Description: Digital signature

Re: Bug#464901: ITP: pcre-light -- a lightweight GHC library for Perl 5 compatible regular expressions

[Christian Perrier]

Quoting Recai Oktaş ([EMAIL PROTECTED]):
> Package: wnpp
> Severity: wishlist
> Owner: "Recai Oktaş" <[EMAIL PROTECTED]>
> 
> * Package name: pcre-light
>   Version : 0.3.1
>   Upstream Author : Don Stewart <[EMAIL PROTECTED]>
> * URL : http://www.example.org/
> * License : BSD
>   Programming Lang: Haskell
>   Description : a lightweight GHC library for Perl 5 compatible regular 
> expressions


Being lecc cryptic would help, here.

I suggest expanding "GHC" if possible, at the expense of "Perl 5"
"lightweight" and/or "compatible".



signature.asc
Description: Digital signature

Re: Bug#464863: ITP: qca2-plugin-cyrus-sasl -- SASL support for the Qt Cryptographic Architecture

[Christian Perrier]

Quoting Matthew Rosewarne ([EMAIL PROTECTED]):
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org
> 
>Package name: qca2-plugin-cyrus-sasl
> Version: 2.0.0~beta3
> Upstream Author: Justin Karneges <[EMAIL PROTECTED]>
> URL: http://delta.affinix.com/qca/
> License: LGPL
> Description: SASL support for the Qt Cryptographic Architecture

I suggest removing the extra capitalization for "cryptographic" and 
"architecture".



signature.asc
Description: Digital signature

Re: Bug#464857: ITP: prima -- is an extensible Perl toolkit for multi-platform GUI development

[Christian Perrier]

Quoting Bas Zoetekouw ([EMAIL PROTECTED]):
> Package: wnpp
> Severity: wishlist
> Owner: Bas Zoetekouw <[EMAIL PROTECTED]>
> 
> * Package name: prima
>   Version : 1.24
>   Upstream Author : Dmitry Karasik <[EMAIL PROTECTED]>, 
> Anton Berezin <[EMAIL PROTECTED]>, Vadim Belman <[EMAIL 
> PROTECTED]>
> * URL : http://www.prima.eu.org/, 
> http://search.cpan.org/~karasik/Prima/
> * License : BSDish
>   Programming Lang: perl
>   Description : an extensible Perl toolkit for multi-platform GUI 
> development


"multi-platform GUI development Perl toolkit" seems to better fit the
Developers Reference recommendations.




signature.asc
Description: Digital signature

New version of refpolicy headed towards incoming

[Manoj Srivastava]

Hi,

With this version of the (surprisingly lintian clean) reference
 policy uploaded, all the SELinux packages, apart from setools, are now
 at the latest released versions (in Sid, that is). I have not yet
 packaged SVN HEAD for these packages, since I'd like to lurk for a bit
 on the selinux mailing lists before I package them.

I am also toying with the idea of breaking out the reference
 policy packages into smaller chunks; so that we have a base policy
 (which is all that would be in standard); and rest can be broken out
 into smaller chunks (at one extreme is having a per package
 granularity, so apache policy would be one package, postfix policy
 another, and one may make use of the Enhances relationship :-)

The ideal solution would lie somewhere in between one giant
 targeted/strict policy and each module in a separate package.  Figuring
 out which set of modules to carve out into a Debian package is going to
 be an interesting challenge.

In the meanwhile, I have added a few  Debian specific bug fixes
 to the reference policy; I'll look at SVN head and see if they need to
 be pushed upstream.  In the meanwhile, please do send in AVC denial
 logs for the new policy in bug reports, we need to start cleaning up
 the reference policy now if we are to meet Lenny release deadlines.

If people have private versions of refpolicy with fixes, I would
 appreciate it if you could diff your policy against the  version
 uploaded and send me the diffs.

manoj
-- 
Check it out, send me comments, and dance joyously in the streets, Linus
Torvalds announcing 2.0.27
Manoj Srivastava <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug#464957: ITP: html-xml-utils -- manipulate HTML and XML files

[Frans Pop]

Daniel Leidert wrote:
> A number of simple utilities for manipulating HTML and XML files.

Are all these intended to be command line utilities?
If so, some of them seem to have names that are extremely generic and
could therefore easily lead to confusion.

The following I find most problematic in that regard:
> cite   - replace bibliographic references by hyperlinks
> count  - count elements and attributes in HTML or XML files files
> extract- extract selected elements
> incl   - expand included HTML or XML files
> index  - create an alphabetically sorted index
> normalize  - pretty-print an HTML file
> num- number section headings in an HTML file
> pipe   - convert XML to a format easier to parse with Perl or AWK
> toc- insert a table of contents in an HTML file
> unpipe - convert output of pipe back to XML format
> wls- list links in an HTML file
> xref   - generate cross-references
> xselect- extract elements that match a(CSS) selector

I would suggest renaming them by adding a suitable prefix.

Cheers,
FJP


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

Re: Intent to hijack xfonts-wqy

[Cai Qian]

Hi Deng Xiyue,

On Feb 9, 2008 3:11 AM, Deng Xiyue
<[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > As the original maintainer Carlos Z.F. Liu have been MIA for several
> > months (we have pinged him several times recently, and his latest
> > upload was 2006-07). xfonts-wqy is a quite important package for
> > people who use Chinese fonts in Debian. In addition, as per discussion
> > before seems nobody is willing to take over this package right now. My
> > first action will be to fix the RC bug as soon as possible.
> >
>
> Some work has been done on the Chinese SVN[1] to deal with the RC bug
> together with several other problems and waiting for review from DD,
> which you might be interested in looking at :)
>

Thanks for pointing out. I'll look at it as soon as possible.

Cai Qian

> [1] svn://svn.debian.org/svn/chinese/packages/xfonts-wqy
>
> > Thanks,
> > Cai Qian
>


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

Bug#464957: ITP: html-xml-utils -- manipulate HTML and XML files

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: html-xml-utils
  Version : 4.4
  Upstream Author : Bert Bos <[EMAIL PROTECTED]>
* URL : http://www.w3.org/Tools/HTML-XML-utils/
* License : W3C Software License (v20021231)
  Programming Lang: C
  Description : manipulate HTML and XML files

A number of simple utilities for manipulating HTML and XML files.
.
cexport- create headerfile of exported declarations from a C file
addid  - add ID's to selected elements
cite   - replace bibliographic references by hyperlinks
cite-mkbib - expand references and create bibliography
count  - count elements and attributes in HTML or XML files files
extract- extract selected elements
htmlclean  - apply heuristics to correct an HTML file
htmlprune  - remove marked elements from an HTML file
incl   - expand included HTML or XML files
index  - create an alphabetically sorted index
mkbib  - create bibliography from a template
multitoc   - create a table of contents for a set of HTML files
name2id- move some ID= or NAME= from A elements to their parents
normalize  - pretty-print an HTML file
num- number section headings in an HTML file
pipe   - convert XML to a format easier to parse with Perl or AWK
printlinks - number links & add table of URLs at end of an HTML file
toc- insert a table of contents in an HTML file
uncdata- replace CDATA sections by character entities
unent  - replace HTML predefined character entities to UTF-8
unpipe - convert output of pipe back to XML format
unxmlns- replace "global names" by XML Namespace prefixes
wls- list links in an HTML file
xmlns  - replace XML Namespace prefixes by "global names"
xmlrecode  - convert between UTF-8 and &#nnn; entities
asc2xml- convert from UTF-8 to &#nnn; entities
xml2asc- convert from &#nnn; entities to UTF-8
xref   - generate cross-references
xselect- extract elements that match a(CSS) selector


- -- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (850, 'unstable'), (700, 'testing'), (550, 'stable'), (110, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-k7 (SMP w/1 CPU core)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHrlyzm0bx+wiPa4wRAoo+AKC1WL9uZlXXMTLDNd9EoiJSRnZtdQCgxTxs
XgVm+ms2G7NuxPZcKNc/Hgs=
=HuPr
-END PGP SIGNATURE-



-- 
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

[Russ Allbery]

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.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
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

[Ben Pfaff]

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, but it's hard to argue
>> strongly for excluding a feature that even posh supports.
>
> Since 0.5.6, it does not; the only number it understands is the
> pseudo-signal 0, mandated by POSIX.
>
> 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.

The XSI option to SUSv3 does not say that numeric signal numbers
are interpreted in a system-specific way.  It is very specific
that numeric 1 is SIGHUP, 2 is SIGINT, 3 is SIGQUIT, 6 is
SIGABRT, 9 is SIGKILL, 14 is SIGALRM, and 15 is SIGTERM:
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]

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

[Clint Adams]

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 excluding a feature that even posh supports.

Since 0.5.6, it does not; the only number it understands is the
pseudo-signal 0, mandated by POSIX.

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.

When the names are used, this confusion is avoided.


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

Bug#464954: ITP: ixp4xx-microcode -- non-free firmware for the ixp4xx ethernet

[Joey Hess]

Package: wnpp
Severity: wishlist
Owner: Joey Hess <[EMAIL PROTECTED]>

The nslu2 needs non-free firmware for its ethernet. This is currently
distributed in the d-i installation images on slug-firmware.net.

The firmware can be downloaded from 


A change in the license means it's free enough for er, non-free.

  INTEL(R) SOFTWARE LICENSE AGREEMENT
   
  Copyright (c) 2007, Intel Corporation.
  All rights reserved.
  
  Redistribution. Redistribution and use in binary form, without modification, 
are permitted
  provided that the following conditions are met:
  o Redistributions must reproduce the above copyright notice and the following 
disclaimer in the
  documentation and/or other materials provided with the distribution. 
  o Neither the name of Intel Corporation nor the names of its suppliers may be 
used to endorse
  or promote products derived from this software without specific prior written 
permission. 
  o No reverse engineering, decompilation, or disassembly of this software is 
permitted.
  
  Limited patent license. Intel Corporation grants a world-wide, royalty-free, 
non-exclusive
  license under patents it now or hereafter owns or controls to make, have 
made, use, import,
  offer to sell and sell (.Utilize.) this software, but solely to the extent 
that any such patent is
  necessary to Utilize the software alone. The patent license shall not apply 
to any combinations
  which include this software. No hardware per se is licensed hereunder.
  DISCLAIMER. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 
CONTRIBUTORS "AS IS" AND
  ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
WARRANTIES OF
  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 
EVENT SHALL THE
  COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 
INCIDENTAL, SPECIAL,
  EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 
PROCUREMENT OF SUBSTITUTE
  GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 
HOWEVER CAUSED AND
  ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
(INCLUDING NEGLIGENCE
  OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF 
ADVISED OF THE POSSIBILITY
  OF SUCH DAMAGE.

The firmware is distributed by intel in the form of some C files containing a
lot of binary dataa. (Which is why the license refers to "in binary form".)
This is compiled into /lib/firmware/NPE-B using IxNpeMicrocode.h and a
Makefile, which can be downloaded from the openwrt svn repo at:
https://svn.openwrt.org/openwrt/trunk/package/ixp4xx-microcode/

IxNpeMicrocode.h is licensed under the GPL. Which seems problimatic,
since it is #included by IxNpeMicrocode.c, which has the above license.
Is this license GPL compatible? The prohibition on reverse engineering does
not seem GPL compatible. I've mailed Christian Hohnstaedt, author of
IxNpeMicrocode.h, to see if I can get that cleared up.

-- 
see shy jo


signature.asc
Description: Digital signature

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

[Russ Allbery]

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 that even posh supports.

> Is there a good reason that we do not in general accept XSI extensions?
> The ones that I've noticed while reading SUSv3 are features that I
> expect a normal Unix system to have.

I don't remember exactly which ones there were, but when I did some more
comprehensive research a while back, there were several major ones that
weren't supported by dash.  Since one of the practical points for this
whole exercise is to let people use dash as /bin/sh, since it can be much
faster, that seemed like a good argument against it.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

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

[Philippe Cloutier]

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. 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).



--
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

[Ben Pfaff]

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 good reason that we do not in general accept XSI
extensions?  The ones that I've noticed while reading SUSv3 are
features that I expect a normal Unix system to have.
-- 
Ben Pfaff 
http://benpfaff.org


-- 
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

[Ben Pfaff]

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.
-- 
Ben Pfaff 
http://benpfaff.org


-- 
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

[Russ Allbery]

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.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
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

[Raphael Geissert]

[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 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
> possible bashism in ./usr/bin/libtool line 1237 (trap with signal
numbers):
>   trap "$run $rm $removelist; exit $EXIT_FAILURE" 1 2 15
> possible bashism in ./usr/bin/libtool line 5323 (trap with signal
numbers):
> trap "$rm $cwrappersource $cwrapper; exit $EXIT_FAILURE" 1 2
15
> possible bashism in ./usr/bin/libtool line 5676 (trap with signal
numbers):
> trap "$rm $output; exit $EXIT_FAILURE" 1 2 15

> 
> 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? 
I've seen some scripts testing for $BASH which works as expected:

> $ bash <<< 'echo $BASH'
> /bin/bash
> $ dash <<< 'echo $BASH'
> 

> 
> Cheers,
> Ralf

Cheers,
Raphael Geissert


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

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

[Evgeni Golov]

Hi *,

at the moment I am preparing the next release of pokerth, which will
contain the pokerth-server package. As this one is new, the whole
pokerth will have to go through NEW again.
However, there is already pokerth 0.6-1-2 in the archive and I do not
change the source tarball, so the chances I made something really bad I
would get a REJECT for are low.

I thought it would be a (time) improvement, when a package which already
has an orig.tar.gz in the archive, but introduces a new binary package,
hits NEW the buildds could start building it (at a low priority)
without uploading to the archive and then wait for the ftp-masters to
approve the package, after what the buildds would upload the already
finished packages.
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 :().

Regards
Evgeni


pgpByLRPjX2YM.pgp
Description: PGP signature

Bug#464926: ITP: freepbx -- web-based management interface for the Asterisk PBX

[Tzafrir Cohen]

Package: wnpp
Version: N/A
Severity: wishlist

* Package name : freepbx
Version : 2.3.1
Upstream Author : Astrogen LLC 
* URL : http://freepbx.org/
* License : GPL
Description : web-based management interface for the Asterisk PBX
 FreePBX (formally AMP) is a web-based GUI for the Asterisk PBX. 
 It provides the ability to:
  * create/modify SIP/IAX extensions & voicemail boxes
  * modify handling of incoming calls based on time-of-day
  * create interactive IVR menus
  * create sophisticated call groups
  * upload custom MOH
  * change company directory behavior
  * set directions for detected incoming faxes
  * view extension and trunk status with Flash Operator Panel (www.asternic.org)
  * read voicemail via the browser with ARI

With Debian we already have a package of the Flash Operator Panel, and the 
package has been patched accrdingly to use that copy. 

FreePBX also uses jgraph, which has been removed from the package. 

The package is currently available from:
Vcs-Svn: svn://svn.debian.org/pkg-voip/freepbx/trunk/
Vcs-Browser: http://svn.debian.org/wsvn/pkg-voip/freepbx/?op=log

Part of the package is available in modules that upstream allows updating 
separately. We currently repackage them in the separate package 
freepbx-modules .

-- 
Tzafrir Cohen | [EMAIL PROTECTED] | VIM is
http://tzafrir.org.il || a Mutt's
[EMAIL PROTECTED] ||  best
ICQ# 16849754 || friend


signature.asc
Description: Digital signature

Bug#464927: ITP: freepbx-modules -- modules for FreePBX - a web-based GUI for Asterisk

[Tzafrir Cohen]

Package: wnpp
Version: N/A
Severity: wishlist

* Package name : freepbx-modules
Version : 2.3.1
Upstream Author : Astrogen LLC 
* URL : http://freepbx.org/
* License : GPL
Description : modules for FreePBX - a web-based GUI for Asterisk
 FreePBX (formally AMP) is a web-based GUI for the Asterisk PBX. 
 It provides the ability to:
  * create/modify SIP/IAX extensions & voicemail boxes
  * modify handling of incoming calls based on time-of-day
  * create interactive IVR menus
  * create sophisticated call groups
  * upload custom MOH
  * change company directory behavior
  * set directions for detected incoming faxes
  * view extension and trunk status with Flash Operator Panel (www.asternic.org)
  * read voicemail via the browser with ARI
 .
 Most of the functionlity of FreePBX is available in separate modules that 
 are available for download separately from freepbx.org. This package is a 
 compilation of those modules, to save the need for manual installation.

This package has been repackaged semi-automatically from the upstream 
modules to a native Debian package that includes all the modules.

The package is currently available from:
Vcs-Svn: svn://svn.debian.org/pkg-voip/freepbx-modules/trunk/
Vcs-Browser: http://svn.debian.org/wsvn/pkg-voip/freepbx-modules/trunk/?op=log



-- 
Tzafrir Cohen | [EMAIL PROTECTED] | VIM is
http://tzafrir.org.il || a Mutt's
[EMAIL PROTECTED] ||  best
ICQ# 16849754 || friend


signature.asc
Description: Digital signature

Bug#464920: ITP: highlighting-kate -- syntax highlighting library based on Kate syntax descriptions

[Recai Oktaş]

Package: wnpp
Severity: wishlist
Owner: "Recai Oktaş" <[EMAIL PROTECTED]>

* Package name: highlighting-kate
  Version : 0.1
  Upstream Author : John MacFarlane <[EMAIL PROTECTED]>
* URL : http://johnmacfarlane.net/highlighting-kate/
* License : GPL
  Programming Lang: Haskell
  Description : syntax highlighting library based on Kate syntax 
descriptions
highlighting-kate is a syntax highlighting library
with support for over 50 languages. The syntax
parsers are automatically generated from Kate syntax
descriptions, so any syntax supported by Kate can
be added.  An (optional) command-line program is
provided, along with a utility for generating
new parsers from Kate XML syntax descriptions.
.
Currently the following languages are supported:
Ada, Asp, Awk, Bash, Bibtex, C, Cmake, Coldfusion,
Commonlisp, Cpp, Css, D, Djangotemplate, Doxygen,
Dtd, Eiffel, Erlang, Fortran, Haskell, Html,
Java, Javadoc, Javascript, Json, Latex, Lex,
LiterateHaskell, Lua, Makefile, Matlab, Mediawiki,
Modula3, Nasm, Objectivec, Ocaml, Pascal, Perl,
Php, Postscript, Prolog, Python, Rhtml, Ruby,
Scala, Scheme, Sgml, Sql, SqlMysql, SqlPostgresql,
Tcl, Texinfo, Xml, Xslt, Yacc.

  P.S. This library is needed for the syntax highlighting support of
   pandoc.

-- 
roktas

Re: ITP: libjs-scriptaculous -- is a user interface JavaScript libraries

[Martín Ferrari]

On Feb 7, 2008 1:03 PM, Marcelo Jorge Vieira (metal)
<[EMAIL PROTECTED]> wrote:

>   Description: is a user interface JavaScript libraries

I think that you should drop the "is a", as the Dev Ref recommends.


-- 
Martín Ferrari

Re: Binaries with the same name

[David Paleino]

Il giorno Sat, 9 Feb 2008 20:28:23 +0100
sean finney <[EMAIL PROTECTED]> ha scritto:

> hi,

Hi,

> On Saturday 09 February 2008 07:48:08 pm David Paleino wrote:
> > Is this the Right Way to behave? And what if  doesn't reply to that
> > bug? Should I file my RFS nevertheless, thus expecting a RC bug filed?
> > Should I rename my binary (and to what? "translate-generic"?!)?
> 
> 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.

That seems like a last-resort to me. I believe that both packages could
cohexist -- yet they might have kinda the same functionalities for
german-speaking users. But I don't want to force people to choose, if there's
no valid reason. Again, I'll wait, but if Anibal doesn't show up I believe I'll
add a Conflicts:.

Thank you for this pointer :)

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

[David Paleino]

Il giorno Sat, 09 Feb 2008 20:20:43 +0100
Frans Pop <[EMAIL PROTECTED]> ha scritto:

> David Paleino wrote:
> > Any suggestion/idea/* is very welcome.
> 
> As your program is gnome-only I don't think you can even claim to be
> more "generic" than the current translate.
> 
> How about using gtranslate for your binary?

"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") ;)

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: Binaries with the same name

[Frans Pop]

David Paleino wrote:
> Any suggestion/idea/* is very welcome.

As your program is gnome-only I don't think you can even claim to be
more "generic" than the current translate.

How about using gtranslate for your binary?

Cheers,
FJP


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

Re: Binaries with the same name

[sean finney]

hi,

On Saturday 09 February 2008 07:48:08 pm David Paleino wrote:
> Is this the Right Way to behave? And what if  doesn't reply to that
> bug? Should I file my RFS nevertheless, thus expecting a RC bug filed?
> Should I rename my binary (and to what? "translate-generic"?!)?

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.


sean


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

Binaries with the same name

[David Paleino]

Hi *,
some time ago I've made an ITP for gnome-translate [1], which depends on
libtranslate, who already had two ITPs which I took over [2].
This latter package provides some binary packages, among which there is
"libtranslate-bin", which installs a "translate" executable
in /usr/bin/. But there already exist a /usr/bin/translate, and it's provided
by the "translate" package, maintained by Anibal Monsalve Salazar .
I've already filed a bug against his package to see what to do [3].

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".

Is this the Right Way to behave? And what if  doesn't reply to that
bug? Should I file my RFS nevertheless, thus expecting a RC bug filed? Should I
rename my binary (and to what? "translate-generic"?!)?

Any suggestion/idea/* is very welcome.

Kindly,
David

[1] #462936
[2] #292907 and #418329
[3] #464034

-- 
 . ''`.  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: Copyright question (BSD with advertisement clause)

[Joey Hess]

Riku Voipio wrote:
> I think the short term solution to this dilemma is to compile a list
> of attributions needed to be included in advertizment material.
> Also a list should be compiled attributions needed n documentation
> (such as libjpeg's). Obviously most distributors/boob writers will
> not notice such lists, but that's a different problem...

Most writers don't have to worry about it, it's not as if we advertise
Debian as "Debian.. now with Thomas G. Lane's JPEG support and OpenSSL".
The advertisement clause tries to not allow those specific attributions
to be used in advertisements; it does NOT require that advertisements
contain any specific list of citations.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#464901: ITP: pcre-light -- a lightweight GHC library for Perl 5 compatible regular expressions

[Recai Oktaş]

Package: wnpp
Severity: wishlist
Owner: "Recai Oktaş" <[EMAIL PROTECTED]>

* Package name: pcre-light
  Version : 0.3.1
  Upstream Author : Don Stewart <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : BSD
  Programming Lang: Haskell
  Description : a lightweight GHC library for Perl 5 compatible regular 
expressions

  The PCRE library is a set of functions that implement regular expression
  pattern matching using the same syntax and semantics as Perl 5.

  P.S.  This package is required for the syntax highlighting support of pandoc.

-- 
roktas


signature.asc
Description: Digital signature

Bug#464551: Here is the information

[Rafael Belmonte]

Before plugging in devices:

$ find /proc/bus/usb
/proc/bus/usb
/proc/bus/usb/004
/proc/bus/usb/004/001
/proc/bus/usb/003
/proc/bus/usb/003/002
/proc/bus/usb/003/001
/proc/bus/usb/002
/proc/bus/usb/002/001
/proc/bus/usb/001
/proc/bus/usb/001/005
/proc/bus/usb/001/004
/proc/bus/usb/001/001
/proc/bus/usb/devices


$ find /dev/bus/usb
/dev/bus/usb
/dev/bus/usb/004
/dev/bus/usb/004/001
/dev/bus/usb/002
/dev/bus/usb/002/001
/dev/bus/usb/003
/dev/bus/usb/003/002
/dev/bus/usb/003/001
/dev/bus/usb/001
/dev/bus/usb/001/005
/dev/bus/usb/001/004
/dev/bus/usb/001/001


After plugging in devices:

$ find /proc/bus/usb
/proc/bus/usb
/proc/bus/usb/004
/proc/bus/usb/004/005
/proc/bus/usb/004/001
/proc/bus/usb/003
/proc/bus/usb/003/002
/proc/bus/usb/003/001
/proc/bus/usb/002
/proc/bus/usb/002/002
/proc/bus/usb/002/001
/proc/bus/usb/001
/proc/bus/usb/001/005
/proc/bus/usb/001/004
/proc/bus/usb/001/001
/proc/bus/usb/devices


$ find /dev/bus/usb
/dev/bus/usb
/dev/bus/usb/004
/dev/bus/usb/004/005
/dev/bus/usb/004/001
/dev/bus/usb/002
/dev/bus/usb/002/002
/dev/bus/usb/002/001
/dev/bus/usb/003
/dev/bus/usb/003/002
/dev/bus/usb/003/001
/dev/bus/usb/001
/dev/bus/usb/001/005
/dev/bus/usb/001/004
/dev/bus/usb/001/001



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

Bug#464864: RFP: qca2-plugin-pkcs11 -- PKCS#11 smart card support for the Qt Cryptographic Architecture

[Matthew Rosewarne]

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

   Package name: qca2-plugin-pkcs11
Version: 2.0.0~beta2
Upstream Author: Alon Bar-Lev <[EMAIL PROTECTED]>
URL: http://delta.affinix.com/qca/
License: LGPL
Description: PKCS#11 smart card support for the Qt Cryptographic 
Architecture
 The Qt Cryptographic Architecture provides a straightforward and cross-
 platform API for a range of cryptographic features, including SSL/TLS,
 X.509 certificates, SASL, OpenPGP, S/MIME CMS, and smart cards.
 .
 This plugin provides support for PKCS#11 "Cryptoki" smart cards using the
 OpenSC pkcs11-helper library.


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

Bug#464863: ITP: qca2-plugin-cyrus-sasl -- SASL support for the Qt Cryptographic Architecture

[Matthew Rosewarne]

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

   Package name: qca2-plugin-cyrus-sasl
Version: 2.0.0~beta3
Upstream Author: Justin Karneges <[EMAIL PROTECTED]>
URL: http://delta.affinix.com/qca/
License: LGPL
Description: SASL support for the Qt Cryptographic Architecture
 The Qt Cryptographic Architecture provides a straightforward and cross-
 platform API for a range of cryptographic features, including SSL/TLS,
 X.509 certificates, SASL, OpenPGP, S/MIME CMS, and smart cards.
 .
 This plugin provides support for SASL using the Cyrus SASL library.


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

Bug#464857: ITP: prima -- is an extensible Perl toolkit for multi-platform GUI development

[Bas Zoetekouw]

Package: wnpp
Severity: wishlist
Owner: Bas Zoetekouw <[EMAIL PROTECTED]>

* Package name: prima
  Version : 1.24
  Upstream Author : Dmitry Karasik <[EMAIL PROTECTED]>, 
Anton Berezin <[EMAIL PROTECTED]>, Vadim Belman <[EMAIL 
PROTECTED]>
* URL : http://www.prima.eu.org/, 
http://search.cpan.org/~karasik/Prima/
* License : BSDish
  Programming Lang: perl
  Description : an extensible Perl toolkit for multi-platform GUI 
development

Prima is an extensible Perl toolkit for multi-platform GUI development.
Platforms supported include Linux, Windows NT/9x/2K, OS/2 and UNIX/X11
workstations (FreeBSD, IRIX, SunOS, Solaris and others).

The toolkit contains a rich set of standard widgets and has emphasis on 2D
image processing tasks. A Perl program using PRIMA looks and behaves
identically on X, Win32 and OS/2 PM.

The toolkit includes a visual builder and a graphic POD viewer.



-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.23.12 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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]

Re: Copyright question (BSD with advertisement clause)

[Riku Voipio]

On Thu, Feb 07, 2008 at 01:34:53PM +0900, Charles Plessy wrote:
> I think that it is a bit frivolous to distribute software with
> advertisment clause in main and not properly warning the redistributors,

I think the short term solution to this dilemma is to compile a list
of attributions needed to be included in advertizment material.
Also a list should be compiled attributions needed n documentation
(such as libjpeg's). Obviously most distributors/boob writers will
not notice such lists, but that's a different problem...

> Anyway, I really think that there are good chances to obtain a
> relicencing, that is by far the best way to find a solution that
> pleases everybody.

This is even better, but it can pontially take a very long time.
I believe it has bee requested from OpenSSL people years ago..

-- 
"rm -rf" only sounds scary if you don't have backups


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

Re: Intend to hijack rrdtool

[Amaya]

Bernd Zeimetz wrote:
> [EMAIL PROTECTED] was pinged several times about updating the package

He is just dead busy, go ahead.

-- 
  ·''`.Moi je voudrais bien, un beau matin, qu'il y est
 : :' :   une fleur dans mon jardin
 `. `' -- Manu Chao 
   `-  Proudly running (unstable) Debian GNU/Linux


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

Re: Bug#464766: ITP: squirrelmail-compatibility -- Squirrelmail plugin used by other plugins to work with older SM versions

[Jan Hauke Rahm]

Hey Christian and William,

first of all thanks for your thoughts!

On Sat, Feb 09, 2008 at 03:01:48AM -0600, William Pitcock wrote:
> On Sat, 2008-02-09 at 07:54 +0100, Christian Perrier wrote:
> > I suggest something like "compatibility plugin for old SquirrelMail
> > versions"
> > 
> > ...and develop more in the long description, maybe.

I'll consider that. In fact the plugin is also useful for future
versions of SM. I don't know how to describe that...

> > What is the proper capitalization of SM?
> > SquirrelMail or Squirrelmail?

SquirrelMail (seen on squirrelmail.org)

> Also from reading the documentation of this plugin, it seems some
> plugins explicitly need version 1.x. As such, shouldn't this be
> squirrelmail-compatibility2 or something?

Can't those plugins use
  Depends: squirrelmail-compatibility (<= 2.0)
to solve that?

Hauke


signature.asc
Description: Digital signature

Re: Bug#464766: ITP: squirrelmail-compatibility -- Squirrelmail plugin used by other plugins to work with older SM versions

[William Pitcock]

On Sat, 2008-02-09 at 12:10 +0100, Jan Hauke Rahm wrote:
> Can't those plugins use
>   Depends: squirrelmail-compatibility (<= 2.0)
> to solve that?

No, because both dpkg and apt generally assume only one version of
something is installable at the same time. This is why we have gcc4.2-*,
gcc4.3-* etcetera instead of just multiple versions of the same package.

On another note: it sure would be nice if dpkg and apt supported the
notion of slotting somehow, but I don't expect that to ever happen.

As such, you need to distinguish between the different API versions. If
they can't co-exist, then use Conflicts: appropriately.

William


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

Re: Bug#464766: ITP: squirrelmail-compatibility -- Squirrelmail plugin used by other plugins to work with older SM versions

[Thijs Kinkhorst]

On Saturday 9 February 2008 07:54, Christian Perrier wrote:
> What is the proper capitalization of SM?
> SquirrelMail or Squirrelmail?

It's "SquirrelMail", unfortunately.


Thijs


pgpnvzRx32V13.pgp
Description: PGP signature

Bug#464840: svn-buildpackage: svn-do for ./debian-only dirs is very useful; please move into $PATH

[sean finney]

Package: svn-buildpackage
Version: 0.6.23
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Eduard et al,

note i'm cc'ing debian-devel, as i see the same question recurring over
and over and over again about how nice it would be if there were some
way to merge the ./debian changes of an svn-export back into the
tree of a ./debian-only project.  most specifically this has come up a
few times in the patch-management thread as a "limitation" of quilt wrt
dpatch, to which i emphatically disagree.

the thing is, there already is a way to do this, using the extremely
useful svn-do script provided in /usr/share/svn-buildpackage.
furthermore, i would say this is the "correct" way of solving this
problem, as it shouldn't be the patch management systems' responsibility
to know the details of how $developer is keeping source in $vcs.

so, is there any reason svn-do can't be dropped into /usr/bin?


thanks!
sean

- -- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages svn-buildpackage depends on:
ii  devscripts 2.10.14   scripts to make the life of a Debi
ii  file   4.23-1Determines file type using "magic"
ii  libsvn-perl1.4.4dfsg1-1  Perl bindings for Subversion
ii  liburi-perl1.35.dfsg.1-1 Manipulates and accesses URI strin
ii  perl   5.8.8-12  Larry Wall's Practical Extraction 
ii  subversion 1.4.4dfsg1-1  Advanced version control system
ii  unp1.0.14unpack (almost) everything with on
ii  wget   1.10.2-3  retrieves files from the web

svn-buildpackage recommends no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHrX9FynjLPm522B0RAk4vAJ9ZfBh6ZOkj9Iq30ez3PDWZD4ynhgCaAmEa
FmPi2DqJUMK4fsrmkVRw/U4=
=LusN
-END PGP SIGNATURE-



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

Re: dpatch -> quilt

[Damyan Ivanov]

[please CC me on replies]

-=| Damyan Ivanov, Fri, Feb 08, 2008 at 01:35:52PM +0200 |=-
> -=| Sven Mueller, Thu, Feb 07, 2008 at 11:07:00PM +0100 |=-
> > gregor herrmann schrieb:
> > > On Mon, 28 Jan 2008 09:09:28 +0100, Andreas Tille wrote:
> > > 
> > >> Is there any easy conversion from dpatch to quilt for a given package
> > >> that is using dpatch?
> > >   
> > > http://svn.debian.org/wsvn/pkg-perl/scripts/dpatch2quilt?op=file&rev=0&sc=0
> > >  
> > 
> > The script should (IMHO) make sure QUILT_PATCHES is set correctly.
> > (Cc'ing dmn because of this)
> 
> It simply assumes that the user has already configured quilt either via
> QUILT_PATCHES environment variable, or via ~/.quiltrc.
> 
> Forcing QUILT_PATCHES=debian/patches may be not what everybody wants.

On the other hand, the script above was created for the needs of the
Debian perl Group, where we certainly want to use debian/patches, so
forcing that would do no harm. Moreover, the script itself uses that
hardcoded path in several places.

Gregor was kind enough to implement that.

-- 
damJabberID: [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: How to cope with patches sanely --> Debian New Maintainers'

[Patrick Schoenfeld]

Hi Pierre,

(BTW. there is no need to CC me with your answers, I did not ask for
that as I am subscribed to the list :-)

On Sat, Feb 09, 2008 at 12:50:46AM +0100, Pierre Habouzit wrote:
>   quilt is way more powerful to refresh patches when a new upstream
> occurs. It does what it can do best without having mergeing features,
> that only an advanced SCM can provide anyways.

That does mean quilt is able to refresh patches on upstream changes, so
that with luck the maintainer does not have to refresh the patches for
changes sources himself? That would be quiet nice, however I still fail
to see why this is a reason to prefer quilts *format* as an *exchange
format* if quilt itself is not to be used, which is what you say.

>   And while being powerful, it remains simple, which dpatch is not.

dpatch is not simple? When refreshing patches or overall? As a dpatch
user I cannot really confirm this. Different to that I tried to work
into quilt these days and it seems to be way more complicated (and needs
some setup before working for debian packaging at all, which dpatch does
not need).

Best Regards,
Patrick


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

Re: Bug#464766: ITP: squirrelmail-compatibility -- Squirrelmail plugin used by other plugins to work with older SM versions

[William Pitcock]

On Sat, 2008-02-09 at 07:54 +0100, Christian Perrier wrote:
> Quoting Jan Hauke Rahm ([EMAIL PROTECTED]):
> > Package: wnpp
> > Severity: wishlist
> > Owner: Jan Hauke Rahm <[EMAIL PROTECTED]>
> > 
> > * Package name: squirrelmail-compatibility
> >   Version : 2.0.9
> >   Upstream Author : Paul Lesniewski <[EMAIL PROTECTED]>
> > * URL : http://www.squirrelmail.org/plugin_view.php?id=152
> > * License : GPL
> >   Programming Lang: PHP
> >   Description : Squirrelmail plugin used by other plugins to work with 
> > older SM versions
> 
> I suggest something like "compatibility plugin for old SquirrelMail
> versions"
> 
> ...and develop more in the long description, maybe.
> 
> What is the proper capitalization of SM?
> SquirrelMail or Squirrelmail?
> 
> 

Also from reading the documentation of this plugin, it seems some
plugins explicitly need version 1.x. As such, shouldn't this be
squirrelmail-compatibility2 or something?

William


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