date:20110630

Etienne,

On Thu, Jun 30, 2011 at 08:30:54AM +0200, Etienne Millon wrote:
 - The dependency against lebiniou-data is not versioned. That means
   that lebiniou is meant to be usable with any version of
   lebiniou-data. In such a case I think you need to specify exactly
   one version. With a single source package, you could depend on
   lebinou-data (= ${source:Version}).
  
  ${binary:Version} sounds even better to me for this usecase.
 
 If I understand it correctly, ${source:Version} will allow binNMUs of
 the Arch:any package without having to provide a binNMU of the
 Arch:all package (which is impossible).
 
 Or am I missing something ?

No, you got it exactly right. I just had them two mixed up. Sorry.

-- 
Cheers,
Kilian


signature.asc
Description: Digital signature

Re: RFS: tnat64 -- IPv4 to NAT64 redirector

Hello,

On Wed, 29 Jun 2011 23:39:31 +0200
Jakub Wilk jw...@debian.org wrote:

 * Andrew O. Shadoura bugzi...@tut.by, 2011-06-30, 00:30:
  5. Lintian issues (lintian -iI --pedantic):
 W: tnat64: package-name-doesnt-match-sonames libtnat64-0.1
 W: tnat64: non-dev-pkg-with-shlib-symlink
  usr/lib/libtnat64.so.0.1 usr/lib/libtnat64.so
 I: tnat64: no-symbols-control-file usr/lib/libtnat64.so.0.1

 Isn't really relevant, as this is a LD_PRELOAD-able library.

 Then there's no reason to install the library into /usr/lib. Install
 it to a private directory instead. And you don't need any symlinks
 either.

Agree. In that case this is also relevant to tsocks package (Cc'ed).

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: RFS: winefish

2011-06-30 Thread Daniel Leidert

CC to bluefish-dev list, BCC to winefish authors

Elías Alejandro wrote:
 On Tue, Jun 28, 2011 at 07:51:14PM -0500, Ruben Molina wrote:
  I'm not a DD, but I had done a short review of your package... 
 Also me, here my fast review about your package only to add:

As someone who already packaged winefish (Ubuntu ships my old package)
and as one of the authors of bluefish, on which winefish is based: Please
do not upload winefish to Debian. It is longtime dead. There hasn't been
any development activity since 2007. Further the features it provides can
probably easily provided by bluefish 2.0 too. This would be a much better
way to provide winefish features and functionality but with support and
active development.

Regards, Daniel
-- 
NEU: FreePhone - kostenlos mobil telefonieren!  
Jetzt informieren: http://www.gmx.net/de/go/freephone


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110630080743.4...@gmx.net

Re: RFS: phing (another try)

2011-06-30 Thread Federico Giménez Nieto

Hi Nicolas, here are my comments about your work (i'm not a DD):

  -debian/control: since you specify '3.0 (quilt)' in debian/source/fomat, 
there is no need for a
quilt dependency

  -debian/copyright:
  -Executing from the sources directory:

$ grep -r copyright .

  you get, among others:
./classes/phing/parser/AbstractHandler.php: * @copyright 2001,2002 
THYRELL. All rights reserved
./classes/phing/tasks/ext/jsmin/JsMin.php: * @copyright 2002 Douglas 
Crockford
doug...@crockford.com (jsmin.c)
./classes/phing/tasks/ext/jsmin/JsMin.php: * @copyright 2008 Ryan Grove 
r...@wonko.com
(PHP port)
./classes/phing/filters/TailFilter.php: * @copyright 2003 seasonfive. 
All rights reserved

  All the copyright holders must be included in the copyright file. You 
could also try executing
'grep -r apache .'

  -You could specify the copyright notice of the packaging itself (set by 
you for your work)

  -debian/rules: as above, you should remove all quilt-related commands, the 
simplest rules file
should work in this case

  -lintian reports duplicated files in /usr/share/doc/phing, you should check 
it (i've noticed it
running 'lintian -iIEvXcF --pedantic phing_2.4.5-1_i386.changes')

Thanks,
Federico


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e0c3b3e.5060...@gmail.com

Re: RFS: lebiniou, lebiniou-data

2011-06-30 Thread David Banks

Hi Olivier,

[CCing my response to the list, hope you don't mind]

On 30 June 2011 03:43, Olivier Girondel olivier.giron...@gmail.com wrote:
[wrt fonts]
Yes, I already got a remark from Paul Wise about this, but I'm not sure
what to do, regarding the source of FreeMono.ttf

FreeMono.ttf comes from http://savannah.gnu.org/projects/freefont/
but I'm not sure about what the source files are, any hints would be
welcomed

At a quick glance, the source would appear to be the SFD files. Here's
one from the CVS:
http://cvs.savannah.gnu.org/viewvc/*checkout*/freefont/sfd/FreeMono.sfd?revision=1.226root=freefont

* In lebiniou-data, I'm loving the images! Many of them are homemade,
but some of them look like they might be copyrighted. All these images
need license statements in debian/copyright. I'm guessing it won't be
practical to dig up these for some of them, so if I were you I would
just strip out the potentially problematic ones and only leave the ones
you are sure about.

Would you please tell me which images could be, in your opinion,
copyrighted ?
I tried my best to remove those that would be problematic;
all the rest is eather home-made or under a Creative Commons license

Cool - The CC licensed images need to be stated in debian/copyright.
If you're sure they are homemade or CC, that's fine.
The ones which immediately stuck as being potentially non-free were:
* UNIX live free or die plate
* Eye in the pyramid logo
* Possibly the Cthulhu hazard sign (which I love)
* Matrix code (this could be generated, though)
If these have attributions, though, that's no problem.

As far as I was tought, section 6 was for games, and everything related,
that does not fit within sections 1..3. lebiniou, IMHO, is not a
general command
one would include, for example, in a shell script

Back to the origins, yes, it was a .1, but I decided to go to .6 since
this is
not a (usefull) command. Arguments on this are welcomed :)

FHS says,
man1: Most program documentation that a user will need to use is
located here.
man6: This chapter documents games, demos, and generally trivial
programs. Different people have various notions about how essential this
is.

Personally I'd leave it in section 1 unless the package's section is
also set to 'games'. Which I wouldn't recommend ;)

* I would prefer to have sequences.tar.gz installed unpacked, as it's
very small. No big deal though.

Do you mean, shipping it as a plain .tar ? Doable.

Ah, when I wrote that I meant to have the entire tree unpacked under
/usr/share/doc/lebinou/examples/sequences or similar. However, after
posting my message I looked at the manual and you describe unpacking
that tarball to your home directory, so I figured your motivation was
that unpacking a tarball is easier for users than 'cp -a' or whatever.
So leave it as it is.

* The program didn't seem to detect audio from Rhythmbox out of the box,
presumably as it was trying to use the alsa plugin where rhythmbox uses
pulseaudio. Maybe consider adding a note to the manual about how to
switch the audio plugin, for new users.

This is one of the main problems regarding linux distros[1], I chose to
make ALSA a default, since some people are reluctant using PulseAudio,
I'll try my best finding a way to document this, (if you have any hint
on this,
I'd be happy to get it)

[1] Not to mention that lebiniou is also supposed to run under *BSDs ;)

I think just an instruction Pulseaudio users: use -i pulseaudio should
be OK, plus instructions on how to set that more permanently.

Cheers,
--
David Banks amoe...@gmail.com

--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e0c3fb3.7050...@gmail.com

Re: RFS: lebiniou, lebiniou-data

2011-06-30 Thread Paul Wise

On Thu, Jun 30, 2011 at 10:19 AM, David Banks amoe...@gmail.com wrote:
 On 30 June 2011 03:43, Olivier Girondel olivier.giron...@gmail.com wrote:
 [wrt fonts]
 Yes, I already got a remark from Paul Wise about this, but I'm not sure
 what to do, regarding the source of FreeMono.ttf

 FreeMono.ttf comes from http://savannah.gnu.org/projects/freefont/
 but I'm not sure about what the source files are, any hints would be
 welcomed

 At a quick glance, the source would appear to be the SFD files.  Here's
 one from the CVS:
 http://cvs.savannah.gnu.org/viewvc/*checkout*/freefont/sfd/FreeMono.sfd?revision=1.226root=freefont

The best way to deal with this is to not ship any fonts in the source
package and use the default system font for rendering text. Unless you
forked FreeMono, this should be acceptable to you. If you are also
targeting platforms without robust repository and dependency systems,
you can embed a copy of the font in the binary package for those
systems and place a copy of the FreeFont source tarball alongside your
binary packages. You can find source tarballs and pre-compiled TTF
files for FreeFont here:

http://ftp.gnu.org/gnu/freefont/

If you need to use a specific font, then depend on it.

If you need to find the filename of a specific font, then use
fontconfig. If you don't want to do that then add a build-time
configuration parameter, in Debian for example that could point at the
path to FreeMono.ttf in ttf-freefont. If you don't want to do that
then add a symlink to  the path to FreeMono.ttf in ttf-freefont from
the path the program expects FreeMono.ttf to be at.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTi=3qo55r814j-kzaesj37z3ne3...@mail.gmail.com

Re: RFS: tnat64 -- IPv4 to NAT64 redirector

2011-06-30 Thread SZERB, Tamas

Could you provide the bug #number to see the whole?

On Thu, Jun 30, 2011 at 9:09 AM, Andrew O. Shadoura bugzi...@tut.by wrote:
 Hello,

 On Wed, 29 Jun 2011 23:39:31 +0200
 Jakub Wilk jw...@debian.org wrote:

 * Andrew O. Shadoura bugzi...@tut.by, 2011-06-30, 00:30:
  5. Lintian issues (lintian -iI --pedantic):
     W: tnat64: package-name-doesnt-match-sonames libtnat64-0.1
     W: tnat64: non-dev-pkg-with-shlib-symlink
  usr/lib/libtnat64.so.0.1 usr/lib/libtnat64.so
     I: tnat64: no-symbols-control-file usr/lib/libtnat64.so.0.1

 Isn't really relevant, as this is a LD_PRELOAD-able library.

 Then there's no reason to install the library into /usr/lib. Install
 it to a private directory instead. And you don't need any symlinks
 either.

 Agree. In that case this is also relevant to tsocks package (Cc'ed).

 --
 WBR, Andrew




-- 
VWOL
Tamas SZERB t...@rulez.org


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktikjqve0gy6u0utzlczaft9ussd...@mail.gmail.com

Re: RFS: tnat64 -- IPv4 to NAT64 redirector

Hello,

On Thu, 30 Jun 2011 13:07:12 +0200
SZERB, Tamas t...@rulez.org wrote:

  * Andrew O. Shadoura bugzi...@tut.by, 2011-06-30, 00:30:
   5. Lintian issues (lintian -iI --pedantic):
      W: tnat64: package-name-doesnt-match-sonames libtnat64-0.1
      W: tnat64: non-dev-pkg-with-shlib-symlink
   usr/lib/libtnat64.so.0.1 usr/lib/libtnat64.so
      I: tnat64: no-symbols-control-file usr/lib/libtnat64.so.0.1

  Isn't really relevant, as this is a LD_PRELOAD-able library.

  Then there's no reason to install the library into /usr/lib.
  Install it to a private directory instead. And you don't need any
  symlinks either.

  Agree. In that case this is also relevant to tsocks package (Cc'ed).

 Could you provide the bug #number to see the whole?

There isn't a bug filed, but as my tnat64 is actually a fork of tsocks
(he-he), this bug must present in tsocks too (as it
has /usr/lib/tsocks.so).

-- 
WBR, Andrew


signature.asc
Description: PGP signature

RFS: minidlna (updated package)

Dear mentors,

I am looking for a sponsor for the new version 1.0.20+dfsg-1
of my package minidlna.

It builds these binary packages:
minidlna   - lightweight DLNA/UPnP-AV server targeted at embedded systems

The package appears to be lintian clean.

The upload would fix these bugs: 626835, 628952, 629140

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/m/minidlna
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/m/minidlna/minidlna_1.0.20+dfsg-1.dsc

I would be glad if someone uploaded this package for me.

Cheers,

-- 
Benoît Knecht


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110630112517.ge5...@marvin.lan

Re: RFS: qasmixer

Hi Sebastian,

Sebastian H. wrote:
 I am looking for a sponsor for my package qasmixer.
 
 * Package name: qasmixer
   Version : 0.12.0-3
   Upstream Author : Sebastian Holtermann sebh...@xwmw.org
 * URL : http://xwmw.org/qasmixer/
 * License : GPL V3
   Section : multimedia
 
 It builds these binary packages:
 qasmixer   - A mixer for the Linux sound system ALSA powered by a QT GUI

I had a look at your package, and here's a few things you could improve:

  - lintian -I --pedantic qasmixer_0.12.0-3.dsc gives the following
output:

  W: qasmixer source: native-package-with-dash-version
  I: qasmixer source: missing-debian-source-format
  W: qasmixer source: out-of-date-standards-version 3.8.4 (current is 3.9.2)

(run it with -i to get a full explanation of their meaning).

  - You're using compat level 7; you should use 8 (in debian/compat and
the version of debhelper in debian/control).

  - Please consider using DEP-5 [1] for your debian/copyright file (not
a requirement, but highly recommended).

[1] http://dep.debian.net/deps/dep5/

  - debian/docs: why are you installing CMakeLists.txt?

  - debian/control: there's no 'multimedia' section in unstable [2].

[2] http://packages.debian.org/unstable/

  - debian/changelog: your entries should be much more descriptive; see
[3] for details.

[3] 
http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-debian-changelog

I hope this helps.

Cheers,

-- 
Benoît Knecht


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110630115137.gf5...@marvin.lan

Re: RFS: s3ql (new python application)

Nikolaus,

On Wed, 2011-06-29 at 21:09 -0400, Nikolaus Rath wrote:
 On 06/29/2011 09:37 AM, Kilian Krause wrote:
  2. You symlink your contrib scripts from /usr/share/doc (!)
  into /usr/bin which is not really the best solution out there. Please
  decide whether these shall either go as examples (and not symlinked
  to /usr/bin/) or whether they are official applications - in which case
  they don't belong into /usr/share/doc.
 
  Well, I think they are certainly not examples. I would be fine to put
  expire_backups and pcp into /usr/bin, but I think that benchmark.py and
  make_dummy.py are relatively unlikely to be called in day to day use, so
  I am hesitant to put them there.
 
  How about putting the former into /usr/bin and symlinking them from
  /usr/share/doc/s3ql/contrib (i.e., to the links the other way around)?
  
  If it's not share/doc/s3ql but share/s3ql I'm perfectly agreed with your
  proposal. ;-)
 
 Ok, new package is on mentors:
 dget http://mentors.debian.net/debian/pool/main/s/s3ql/s3ql_1.0.1-2.dsc

thanks!
Built, signed, uploaded.

-- 
Cheers,
Kilian


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

Re: RFS: tsung (2nd try)

Hi Ignace,

Ignace Mouzannar wrote:
 * Package name: tsung
  Version : 1.3.3-1
  Upstream Author : Nicolas Niclausse nico...@niclux.org
 * URL : http://tsung.erlang-projects.org/
 * License : GPL-2
  ^
Parts of the code use the Erlang Public License v1.1 (based on the
Mozilla Public License v1.0); is this license compatible with the GPL-2
(I know the MPL isn't)?

Cheers,

-- 
Benoît Knecht


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110630122257.gg5...@marvin.lan

Re: RFS: qasmixer

Benoît Knecht wrote:
 Hi Sebastian,
 
 Sebastian H. wrote:
  I am looking for a sponsor for my package qasmixer.
  
  * Package name: qasmixer
Version : 0.12.0-3
Upstream Author : Sebastian Holtermann sebh...@xwmw.org
  * URL : http://xwmw.org/qasmixer/
  * License : GPL V3
Section : multimedia
  
  It builds these binary packages:
  qasmixer   - A mixer for the Linux sound system ALSA powered by a QT GUI
 
 I had a look at your package, and here's a few things you could improve:
 
 [...]

Just a few additional comments, now that I've finished building your
package:

  - lintian -I --pedantic qasmixer_0.12.0-3_amd64.changes reports:

  W: qasmixer source: empty-debian-diff
  I: qasmixer source: missing-debian-source-format
  W: qasmixer source: out-of-date-standards-version 3.8.4 (current is 3.9.2)
  I: qasmixer source: debian-watch-file-is-missing
  I: qasmixer: spelling-error-in-binary usr/bin/qasmixer informations 
information
  E: qasmixer: helper-templates-in-copyright
  E: qasmixer: copyright-contains-dh_make-todo-boilerplate
  W: qasmixer: description-synopsis-starts-with-article
  W: qasmixer: extended-description-line-too-long
  I: qasmixer: extended-description-is-probably-too-short
  W: qasmixer: unknown-section multimedia
  W: qasmixer: extra-license-file usr/share/qasmixer/COPYING

  - There's also a warning from dpkg-shlibdeps at the end of the build
process:

  dpkg-shlibdeps: warning: dependency on libQtXml.so.4 could be avoided if 
debian/qasmixer/usr/bin/qasmixer were not uselessly linked against it (they 
use none of its symbols).

You should check whether you can fix it.

Cheers,

-- 
Benoît Knecht


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110630125832.gh5...@marvin.lan

Re: RFS: qasmixer

2011-06-30 Thread Sebastian H.

Hello Benoît

Thank you for reviewing!
I'll have a look at the issues you mentioned.

 Just a few additional comments, now that I've finished building your
 package:
 
   - lintian -I --pedantic qasmixer_0.12.0-3_amd64.changes reports:
 
   W: qasmixer source: empty-debian-diff
   I: qasmixer source: missing-debian-source-format
   W: qasmixer source: out-of-date-standards-version 3.8.4 (current is 
 3.9.2)
   I: qasmixer source: debian-watch-file-is-missing
   I: qasmixer: spelling-error-in-binary usr/bin/qasmixer informations 
 information
   E: qasmixer: helper-templates-in-copyright
   E: qasmixer: copyright-contains-dh_make-todo-boilerplate
   W: qasmixer: description-synopsis-starts-with-article
   W: qasmixer: extended-description-line-too-long
   I: qasmixer: extended-description-is-probably-too-short
   W: qasmixer: unknown-section multimedia
   W: qasmixer: extra-license-file usr/share/qasmixer/COPYING
 
   - There's also a warning from dpkg-shlibdeps at the end of the build
 process:
 
   dpkg-shlibdeps: warning: dependency on libQtXml.so.4 could be avoided 
 if debian/qasmixer/usr/bin/qasmixer were not uselessly linked against it 
 (they use none of its symbols).
 
 You should check whether you can fix it.


Sebastian


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e0c79bc.9010...@gmx.de

RFS: [QA upload] snowdrop

2011-06-30 Thread Arno Töll

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I'm seeking a sponsor for a QA upload of the package snowdrop. Snowdrop
is orphaned since over two years but in rather good shape and still
usable. I updated it to more recent Debian improvements (dh 8, quilt 3.0
package, ...), fixed some minor bugs and brought it up to date in general.

Upstream development stopped long time ago, but as it is still useful
I'd love to see this package well-kept.

I did:

* Switch to 3.0 (quilt) format, moved all changes to the upstream source
to a quilt patch
* Pushed debhelper to v8
* Switched debian/copyright to DEP-5
* Fixed some minor bugs (see changelog)
* Moved (Debian) man page out of the upstream source to debian/
* Made Lintian (mostly) happy, I didn't bother about a watch file, since
this makes no sense.

The full list of changes is attached in diff below. Joey, if you care
enough I can push you my changes to your git repository (or rather
export it somehow to you, since I have no write permissions to your
repository)

Finally I hope I didn't bother debian-qa@ too much with this request,
but last time I was told I shall CC you for QA-RFS mails.

The package can be found on mentors.debian.net:
- - URL: http://mentors.debian.net/debian/pool/main/s/snowdrop
- - Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- - dget
http://mentors.debian.net/debian/pool/main/s/snowdrop/snowdrop_0.02b-9.dsc

I'd be glad if someone could sponsor this QA upload.

- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJODIKIAAoJEMcrUe6dgPNtigsP/jSX4v6RuHGM9DcRyjs8mMZM
4GTGA/V4aVXSGGY05nNvRsPEdYtlakbNEExCgnXF75iYdszlIoMG+e13DKz5pck5
q1afVCPthGF/W4pAn3+FTBdiRjI/xLwodxijmqE3SSIb8BRsb83+QUYXj+F+jbcK
lmLKX9BXLqA40b6PU7Yi9/k2DhhW94RsljT7cTu7WIChEskdYp/2ZwmW3gZA4STU
3Hdoo+ZUiWhldH++hxEQD6Ta9wBbE53+HR43EBmrNG0e/gTjYFInA1KKqthZGB54
RWv8UGEbKKOCIQ7cd/wPDjexG7ihrH6CYhC0ppHZcdl9ATxFpIuci1foGZATvZcA
W7BvsqyWLhXK5N/Pkq1JHczSAlvf1eBxgMQ1qbEHAuFrdve8gb6KEOgMTK9YEJGM
EaHooNLcpfYqFnGN4x6JCY2/jPxYFXCSUOHXLc3oKYhBhQxgH4dRSN+bdq2pCAhM
UaulUI9cKzaJR6bNPlqHpiNnTPDAMFY37lUrvmMDyWBfDTLp796bD/NC98GturQG
9V54q4yw/ZepHCINEkaE6Hw9V0beASThD3QAuJMVItjfX2DK57DGFew8LEtUpurg
LKnWFNFiWL1qjH1PUFehVeLgVuykwvOhTDeoDR5NHk9iZENTGMdTNvSsz09j+LHc
t7RKAhZvVDu08BL2GTjX
=rCO1
-END PGP SIGNATURE-
diff --git a/Makefile b/Makefile
index 9492a23..dfb0ed3 100644
--- a/Makefile
+++ b/Makefile
@@ -26,10 +26,9 @@ VER	= 0.02b
 LANG= eng engf c
 
 BINROOT = /usr/bin/
-DESTDIR = /
 
-CFLAGS  = -ggdb -O2 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations \
-  -ffast-math -Wall -g
+CFLAGS  = -ggdb -O9 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations \
+  -ffast-math -Wall 
 
 
 all: modules snowdrop toinstall
@@ -37,25 +36,25 @@ all: modules snowdrop toinstall
 modules: language.h
 	@echo ; \
 	echo [*] Compiling language modules: ; \
-	test -f /usr/include/gnutls/openssl.h  USEOPENSSL=1; \
-	test -f /usr/local/include/gnutls/openssl.h  USEOPENSSL=1; \
-	test $$USEOPENSSL =  || echo [+] Using GNU TLS MD5 modules. ; \
+	test -d /usr/include/openssl  USEOPENSSL=1; \
+	test -d /usr/local/include/openssl  USEOPENSSL=1; \
+	test $$USEOPENSSL =  || echo [+] Using OpenSSL MD5 modules. ; \
 	test $$USEOPENSSL =   echo [+] Trying to use RSA MD5 modules. ; \
 	for i in $(LANG); do \
 	  echo [+] Building language module for '$$i'...; \
-	  test $$USEOPENSSL =  || ADDME=-DUSE_OPENSSL -DUSE_GNUTLS ; \
+	  test $$USEOPENSSL =  || ADDME=-DUSE_OPENSSL ; \
 	  $(CC) $$ADDME $(CFLAGS) -c lang-$$i.c -o lang-$$i.o || exit 1; \
 	done; \
 	echo [*] Language modules compiled.
 
 snowdrop: snowdrop.c language.h 
 	@echo [*] Compiling main code:; \
-	test -f /usr/include/gnutls/openssl.h  USEOPENSSL=1; \
-	test -f /usr/local/include/gnutls/openssl.h  USEOPENSSL=1; \
+	test -d /usr/include/openssl  USEOPENSSL=1; \
+	test -d /usr/local/include/openssl  USEOPENSSL=1; \
 	for i in $(LANG); do \
 	  echo [+] Building 'sd-$$i'... ; \
 	  ADDME=-lmd5; \
-	  test $$USEOPENSSL =  || ADDME=-DUSE_OPENSSL -DUSE_GNUTLS -lgnutls-extra -lgnutls-openssl $(shell libgnutls-config --cflags --libs) ; \
+	  test $$USEOPENSSL =  || ADDME=-DUSE_OPENSSL -lcrypto ; \
 	  $(CC)  -DVER=\$(VER)\ $(CFLAGS) -DTARGETLANG=\$$i\ snowdrop.c lang-$$i.o -o sd-$$i $$ADDME || exit 1; \
 	done; \
 	echo [*] Main code compiled.
@@ -68,12 +67,12 @@ toinstall:
 clean:
 	rm -f sd-* *.o core core.* a.out
 
-install:
-	@echo [*] Installing binaries in $(DESTDIR)$(BINROOT)...
-	cp -f sd-* $(DESTDIR)$(BINROOT)
+install: modules snowdrop
+	@echo [*] Installing binaries in $(BINROOT)...
+	cp -f sd-* $(BINROOT)
 	@echo [*] Installing synonyms database...
-	@mkdir $(DESTDIR)/usr/share/snowdrop || true
-	cp synonyms $(DESTDIR)/usr/share/snowdrop/
+	@mkdir /usr/share/snowdrop || true
+	cp

Re: RFS: tnat64 -- IPv4 to NAT64 redirector

Hi,

On Thu, 2011-06-30 at 14:26 +0300, Andrew O. Shadoura wrote:
 Hello,
 
 On Thu, 30 Jun 2011 13:07:12 +0200
 SZERB, Tamas t...@rulez.org wrote:
 
   * Andrew O. Shadoura bugzi...@tut.by, 2011-06-30, 00:30:
5. Lintian issues (lintian -iI --pedantic):
   W: tnat64: package-name-doesnt-match-sonames libtnat64-0.1
   W: tnat64: non-dev-pkg-with-shlib-symlink
usr/lib/libtnat64.so.0.1 usr/lib/libtnat64.so
   I: tnat64: no-symbols-control-file usr/lib/libtnat64.so.0.1
 
   Isn't really relevant, as this is a LD_PRELOAD-able library.
 
   Then there's no reason to install the library into /usr/lib.
   Install it to a private directory instead. And you don't need any
   symlinks either.
 
   Agree. In that case this is also relevant to tsocks package (Cc'ed).
 
  Could you provide the bug #number to see the whole?
 
 There isn't a bug filed, but as my tnat64 is actually a fork of tsocks
 (he-he), this bug must present in tsocks too (as it
 has /usr/lib/tsocks.so).

this discussion about moving a shared lib into private namespace is
somewhat puzzling me. If the code it provides is only used internally -
why not link it in statically and don't ship it?

And if it can provide a useful ABI for others - why not make it a real
shared lib and ship it as such from the same source?

-- 
Best regards,
Kilian



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

Re: RFS: tnat64 -- IPv4 to NAT64 redirector

Hi Andrew,

On Thu, 2011-06-30 at 00:30 +0300, Andrew O. Shadoura wrote:
 On Wed, 29 Jun 2011 16:11:56 -0500
 Elías Alejandro eal...@gmail.com wrote:
 
  I am not a DD, so I can't sponsor your contribution. I'm sorry. But
  here my fast review about your package:
 
  1. Bump Standards-Version to 3.9.2
 
 Yes, I know.
 
  2. Maybe you can use debhelper version 8 under: debian/compat,
  debian/control
 
 Possibly.
 
  3. debian/copyright: please use DEP-5 format[0]
 
 I don't think it's a good idea.

Why not?


  4. Newest version on remote site is 0.03
 
 I know, I'm the upstream.
 
  5. Lintian issues (lintian -iI --pedantic):
 W: tnat64: package-name-doesnt-match-sonames libtnat64-0.1
 W: tnat64: non-dev-pkg-with-shlib-symlink usr/lib/libtnat64.so.0.1
  usr/lib/libtnat64.so I: tnat64: no-symbols-control-file
  usr/lib/libtnat64.so.0.1 
 
 Isn't really relevant, as this is a LD_PRELOAD-able library.

What's the one to do with the other here? If it's a real shared library
it can and even should be split out to a lib package. The possibility to
preload it doesn't really make more sense to me than linking it in
statically I guess. But maybe I just missed your point.

-- 
Best regards,
Kilian



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

Re: RFS: tnat64 -- IPv4 to NAT64 redirector

Hello,

On Thu, 30 Jun 2011 17:18:50 +0200
Kilian Krause kil...@debian.org wrote:

Isn't really relevant, as this is a LD_PRELOAD-able library.

 this discussion about moving a shared lib into private namespace is
 somewhat puzzling me. If the code it provides is only used internally
 - why not link it in statically and don't ship it?

Because it has to be dynamic --- it gets LD_PRELOADed into the process.
If it was static, that'd not be possible.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: RFS: tnat64 -- IPv4 to NAT64 redirector

Hello,

On Thu, 30 Jun 2011 17:21:05 +0200
Kilian Krause kil...@debian.org wrote:

   5. Lintian issues (lintian -iI --pedantic):
  W: tnat64: package-name-doesnt-match-sonames libtnat64-0.1
  W: tnat64: non-dev-pkg-with-shlib-symlink
   usr/lib/libtnat64.so.0.1 usr/lib/libtnat64.so I: tnat64:
   no-symbols-control-file usr/lib/libtnat64.so.0.1 

  Isn't really relevant, as this is a LD_PRELOAD-able library.

 What's the one to do with the other here? If it's a real shared
 library it can and even should be split out to a lib package. The
 possibility to preload it doesn't really make more sense to me than
 linking it in statically I guess. But maybe I just missed your point.

This package doesn't make any sense without LD_PRELOAD, it's all about
the library which gets preloaded to hook into some Berkeley sockets
functions.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: RFS: latex-mk (updated package)

Hi Wences,

On Thu, 2011-06-30 at 00:05 -0600, Wences René Arana Fuentes wrote:
 I am looking for a sponsor for the new version 2.1-1
 of my package latex-mk.
 
 It builds these binary packages:
 latex-mk   - tool for managing LaTeX projects
 
 The package appears to be lintian clean.
 
 The package can be found on mentors.debian.net:
 - URL: http://mentors.debian.net/debian/pool/main/l/latex-mk
 - Source repository: deb-src http://mentors.debian.net/debian unstable
 main contrib non-free
 - dget 
 http://mentors.debian.net/debian/pool/main/l/latex-mk/latex-mk_2.1-1.dsc
 
 I would be glad if someone uploaded this package for me.

Thanks for taking care of updating this package.

Some questions and comments are though:

- Your debian/copyright link points to
http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=filerev=135 which
is no longer accessible

- you may want to tell upstream there is a CVS dir still left under
testsuite/texfiles/CVS

- you may further want to tell your upstream that their tarball
ships .pc

- Your debian/changelog doesn't tell that you've updated your email
address in the maintainers field

- Just for the record: It's upstream not upstreamer ;-)

- Your package still uses debhelper 7. You may want to bump that to 8


Anyway, built, signed, uploaded.

-- 
Cheers,
Kilian


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

Re: RFS: [QA upload] snowdrop

2011-06-30 Thread Jan Hauke Rahm

On Thu, Jun 30, 2011 at 04:04:57PM +0200, Arno Töll wrote:
 I'm seeking a sponsor for a QA upload of the package snowdrop. Snowdrop
 is orphaned since over two years but in rather good shape and still
 usable. I updated it to more recent Debian improvements (dh 8, quilt 3.0
 package, ...), fixed some minor bugs and brought it up to date in general.
 
 Upstream development stopped long time ago, but as it is still useful
 I'd love to see this package well-kept.

I'll sponsor it. Thanks, Arno!

 The full list of changes is attached in diff below. Joey, if you care
 enough I can push you my changes to your git repository (or rather
 export it somehow to you, since I have no write permissions to your
 repository)

We should have a policy about all QA packages being in collab-maint or
something...

Hauke

-- 
 .''`.   Jan Hauke Rahm j...@debian.org   www.jhr-online.de
: :'  :  Debian Developer www.debian.org
`. `'`   Member of the Linux Foundationwww.linux.com
  `- Fellow of the Free Software Foundation Europe  www.fsfe.org


signature.asc
Description: Digital signature

Re: Bug#625120: clonalframe: FTBFS: src/move_hidden.cpp:169:62: error: taking address of temporary [-fpermissive]

2011-06-30 Thread Sebastian Ramacher

On 06/29/2011 09:17 AM, Andreas Tille wrote:
 sorry for the late reply to this bug.  I can reproduce the problem on my
 side but I'm not finally sure that this is really a problem of clonalframe
 or whether it is a bad coincidence with libgsl0-dev.  The line in question
 where the problem occures is:
 
  src/move_hidden.cpp:423:59: error: taking address of temporary 
 [-fpermissive]
  
 
  423:Util::normalize((gsl_matrix_row(e,i+1).vector));
 
 So I suspect that there are temporary variables used where they should
 not but these are not declared in Move_hidden::makee().  My c++
 knowledge ist too limited to track down the problem in a reasonable time
 frame and thus I CC debian-mentors and upstream (Xavier please find the
 full log of this bug below or at http://bugs.debian.org/625120).

The attached patch should fix this issue. The problem here is that the return
value of gsl_matrix_row is a non-lvalue and thus one cannot take its address.

Kind regards,
-- 
Sebastian Ramacher
--- clonalframe-1.2.orig/src/move_hidden.cpp
+++ clonalframe-1.2/src/move_hidden.cpp
@@ -166,7 +166,8 @@ namespace wb
 sum+=gsl_matrix_get(f,j,i)*q[j][state][site-siteprev-1];
 gsl_matrix_set(f,state,i+1,sum*gsl_matrix_get(e,state,msgs[site]));
 }
-Util::normalize((gsl_matrix_column(f,i+1).vector));
+gsl_vector_view view = gsl_matrix_column(f,i+1);
+Util::normalize(view.vector);
 }
 return f;
 }
@@ -420,7 +421,8 @@ namespace wb
 gsl_matrix_set(e,i+1,2,(1.0-m2)*m3+(1.0-m3)*m2);
 }
 
-Util::normalize((gsl_matrix_row(e,i+1).vector));
+gsl_vector_view view = gsl_matrix_row(e,i+1);
+Util::normalize(view.vector);
 }
 }
 


signature.asc
Description: OpenPGP digital signature

Re: RFS: qasmixer

Sebastian H. wrote:
 Thank you for reviewing!
 I'll have a look at the issues you mentioned.

Great! Don't hesitate to ask if anything is unclear.

Oh and I forgot to mention, you should open an ITP bug against the wnpp
pseudo-pacakge and add the proper instruction to close it in your
debian/changelog [1].

[1] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage

Cheers,

-- 
Benoît Knecht


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110630192918.ga2...@marvin.lan

Re: RFS: vim-subtitles, vim-srt, vim-sub, vim-mpsub