Bug#847923: marked as done (RFS: ltrace/0.7.3-6.1)

[Debian Bug Tracking System]

Your message dated Fri, 05 May 2017 04:32:51 +
with message-id 
and subject line closing RFS: ltrace/0.7.3-6.1
has caused the Debian Bug report #847923,
regarding RFS: ltrace/0.7.3-6.1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
847923: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847923
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal

 Dear mentors,

 I am looking for a sponsor for the package "ltrace".
 This is a packaging update :

 paflib (0.7.3-6.1) unstable; urgency=medium

 

This is a package update to support ppc64le arch.

Since there is no real release update, it contains patches as well as
packaging updates to fit debian current packaging rues.


  Package name: ltrace
  Version : 0.7.3-6.1
  Maintainer: Juan Cespedes 
  Homepage: http://ltrace.alioth.debian.org
  Section: utils

 To access further information about this package, please visit the
following URL:

 https://mentors.debian.net/package/ltrace


 Alternatively, one can download the package with dget using this command:

   dget -x
https://mentors.debian.net/debian/pool/main/l/ltrace/ltrace_0.7.3-6.1.dsc

 More information about ltrace can be obtained from
http://ltrace.alioth.debian.org



 Regards,
  Thierry Fauck


-- 

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/
--- End Message ---
--- Begin Message ---
Package ltrace has been removed from mentors.--- End Message ---

Bug#833193: RFS: chapel/1.15-1 [ITP]

[Sean Whitton]

Dear Lumin,

On Thu, May 04, 2017 at 02:06:10PM +, Lumin wrote:
> I quickly went through the packaging, and had some comments about it:

Thank you for your input.  I agree with all of it except:

> * debian/changelog:
>   currently Debian is still in the deep freeze stage, I'd recommend
> you upload to experimental
>   first. Besides, experimental is more fault-tolerant.

This is not needed for completely NEW packages.  We should upload this
to unstable.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849754: RFS: guerillabackup/0.0.0-1

[halfdog]

Hi Andreas,

It took me quite a while to address all your remarks...

Andreas Henriksson wrote:
> Hello halfdog,
> 
> Thanks for your interest in debian packaging
> 
> On Fri, Dec 30, 2016 at 03:16:55PM +, halfdog wrote:
> > Package: sponsorship-requests
> > Severity: normal
> > 
> > Dear mentors,
> > 
> > I am looking for a sponsor for my package "guerillabackup"
> [...]
> >   dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guer
> illabackup_0.0.0-1.dsc
> [...]
> > 
> > As also stated in comment to https://mentors.debian.net/package/guerillabac
> kup
> > to avoid reviewers wasting time searching for dirty little package
> > secrets, here are some pointers to things, I had problems with,
> > when creating the package. Reviewers might disagree with my proposed
> > solution, any feedback is very welcome!
> > 
> > * Upstream Debian file templates: to support building of native
> >   packages using only the upstream source, Debian package files
> >   and build instructions are included already in upstream. To
> >   avoid duplication of them when not (yet) needed, they are copied
> >   within "rules" in target "override_dh_auto_configure"
> 
> Not a fan here. :P
> From a Debian(-only) perspective this complicates things for no
> real gain. If you package things in Debian it's probably very
> unlikely people will get their packages from elsewhere, specially
> if they need to both build it themselves and follow a procedure
> for doing so that's completely alien.. (but what do I know
> about the actual problem you're trying to solve.)

I only hoped to perform some dedup, but ...

> I'm hoping DEP14 can instead be a replacement solution
> for handling this (and also other reasons).

... if I understand http://dep.debian.net/deps/dep14/ correctly,
building for different vendors in future should follow another
scheme anyway, where deduplication is not an option. So I removed
that stuff and duplicated all relevant upstream debian/* files
to the non-native Debian quilt files also.

> > * (Re)starting units on upgrade: As stated in documentation, two
> >   services can be used also from commandline (on demand) or as
> >   non-root user, depending on end user use cases. Thus it is intended,
> >   that the two systemd units are not enabled by default. Also
> >   a user may start them manually without enabling them. With upgrade
> >   following problem may arise: with standard debhelper means it
> >   was not possible to
> >   1) stop all running units and
> >   2) after update start only those, that were running beforehand.
> >   Solution:
> >   1) do not use debhelper for stopping/starting of units,
> >   2) find out in "prerm" which units are currently running, stop them and
> >   3) in "postinst" start only those, that were running in step 1)
> 
> Pretty please do not try to reinvent systemd integration on your own.
> This is just way to easy to get wrong. If the current helpers does
> not work for you it's either likely because you're using them wrong
> and/or because they should be improved. Anything else is likely just
> causing extra work and pain.
> 
> Please swing by either the irc channel or contact the mailing list
> for the Debian systemd maintainers. They're very skilled and usually
> happy to help (time permitting). They are likely also the people
> you need to get to review your package anyway if you invent your
> own maintainer script scheme.

I tried to get response from the mailing list, see
http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2017-March/014551.html
Also got to the IRC channel "#debian-systemd" with same result.

As there are no responses proposing better solutions and the conditional
service restarting code works as expected, I would propose keeping
the current solution until bugreports are received. If insufficient,
I would try to contact them again.

> > * Use of .pyc files: As I do not fully understand the consequences
> >   of using .pyc files, especially in conditions where backup might
> >   be more important, e.g. when disks start already failing and
> >   py/pyc files might fall out of sync, I decided not to use them
> >   until I understand the possible risks. As codebase is very small
> >   and program is long-running, overhead from JIT-compiling should
> >   be not an issue.
> 
> Not an expert on python packaging myself, but I think Debian python
> packaging helpers should generate postinst code to automatically
> generate the .pyc files on install. I guess the reason you can't
> ship them is because then you need to build them with the lowest
> supported capability set of the architecture (which itself is
> likely hard to do). In short, the debian way is to just rm *.pyc *.pyo
> and trust the helpers to do the right thing.

Same argument as with security considerations below: availability,
stability in those bordercases might not be a relevant issue for
the first version of the package. So .pyc objects are now generated
the same 

Bug#861832: RFS: golang-github-serenize-snaker/0.0~git20170425.0.1c7f653-1 [ITP]

[Diego M . Rodriguez]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "golang-github-serenize-snaker"

 * Package name: golang-github-serenize-snaker
   Version : 0.0~git20170425.0.1c7f653-1
   Upstream Author : Serenize UG 
 * URL : https://github.com/serenize/snaker
 * License : Expat
   Section : devel

  It builds those binary packages:

golang-github-serenize-snaker-dev - Convert camel cased strings to snake 
case and back

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/golang-github-serenize-snaker


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-serenize-snaker/golang-github-serenize-snaker_0.0~git20170425.0.1c7f653-1.dsc

  Changes since the last upload:

  * Initial release (Closes: #861827)


  Regards,
   Diego M. Rodriguez

Bug#861831: RFS: golang-github-viki-org-dnscache/0.0~git20130720.0.c70c1f2-1 [ITP]

[Diego M . Rodriguez]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "golang-github-viki-org-dnscache"

 * Package name: golang-github-viki-org-dnscache
   Version : 0.0~git20130720.0.c70c1f2-1
   Upstream Author : Viki Inc. 
 * URL : https://github.com/viki-org/dnscache
 * License : Expat
   Section : devel

  It builds those binary packages:

golang-github-viki-org-dnscache-dev - DNS cache for Go

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/golang-github-viki-org-dnscache


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-viki-org-dnscache/golang-github-viki-org-dnscache_0.0~git20130720.0.c70c1f2-1.dsc

  Or on the following repository:

https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-viki-org-dnscache.git

  Changes since the last upload:

* Initial release (Closes: #861825)

  Regards,
   Diego M. Rodriguez

Bug#833193: RFS: chapel/1.15-1 [ITP]

[Lumin]

Hello guys,

I quickly went through the packaging, and had some comments about it:
(I didn't carefully read your previous discussion and I have no
permission to upload)

* debian/changelog:
  currently Debian is still in the deep freeze stage, I'd recommend
you upload to experimental
  first. Besides, experimental is more fault-tolerant.

* chapel-doc.install:
  you may want to provide some room for users to install several
versions of chapel at the
  same time, but I'd recommend the way similar to gcc/llvm packaging does.
  you may want to install stuff like this:
/usr/share/doc/chapel/1.15/stuff
/usr/share/doc/chapel/1.16/stuff
  but this should be better:
/usr/share/doc/chapel-1.15/stuff
/usr/share/doc/chapel-1.16/stuff
  for example:
/usr/share/doc/gcc-{5,6}

* control:
  * Vcs-* fields are your *packaging repo* instead of upstream git repo.
  * python2.7: since python policy recommends python3 for new
packages, could you please
also provide a python3 version if upstream supports it?

* rules:
  * dh compat 10 has parallel build as default, you can optionally
bump compat to 10. Before
you are really about to do that, check debhelper(7) first for the
checklist from v9->v10.
  * it seems that util/quickstart/setchplenv.bash is just exporting
some environt variables
for the use of buildsystem. exporting these variables in rules
instead of sourcing with
bash should be better, and in this way you can gain more control
from rules, including
the CHPL_LLVM flag which seems to be a key of one of your TODO.

This chapel 1.15 package was succesfully built on my laptop and a
simple helloworld
example is working.

-- 
Best,
Lumin

Bug#861289: RFS: highwayhash/0~20170419-g1f4a24f-2

[Lumin]

Hi,

Thank you for sponsoring!

Initially I don't like to spend too much human time on C++ symbols file
although a bunch of symbols file seems not elegant.


On 27 April 2017 at 13:02, Gianfranco Costamagna
 wrote:
> hello,
>
>>  I am looking for a sponsor for my package "highwayhash"
>
>
> sponsored but please try to have less different symbol files, and more human 
> readable
> e.g.
> cat debian/libhighwayhash0.symbols |c++filt
> gives you a better readable file, and marking
> symbols as optional can reduce even more the number of different symbol files
>
> one single file should be enough for every arch.
>
> G.



-- 
Best,
Lumin

Bug#861291: Fwd: RFS: luajit/2.1.0~beta2+dfsg-3.1 -- [NMU,RC/experimental]

[Lumin]

Hi,
(rolling another luajit maintainer in)

Thank you for reviewing this RFS. I made some further change to this package
according to you feedback:

* change vcs-* to secure one
* drop Pre-Depends stuff.

dget:
https://mentors.debian.net/debian/pool/main/l/luajit/luajit_2.1.0~beta2+dfsg-3.1.dsc

dom-amd64:
http://debomatic-amd64.debian.net/distribution#experimental/luajit/2.1.0~beta2+dfsg-3.1/buildlog

dom-arm64 (still building):
http://debomatic-arm64.debian.net/distribution#experimental/luajit/2.1.0~beta2+dfsg-3.1/buildlog

all changes from -3 to -3.1 in the patch attached.

On 27 April 2017 at 13:35, Gianfranco Costamagna
 wrote:
> control: owner -1 !
> control: tags -1 moreinfo
>
> ^^ this is to let Enrico review it, and I'll NMU in case he is ok
>
>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861291
>
>
> the packaging seems fine, the patch differs from the upstream one for some 
> bits
> https://github.com/LuaJIT/LuaJIT/commit/0c6fdc1039a3a4450d366fba7af4b29de73f0dc6.patch
> but I guess this is ok, since the upstream patch doesn't apply.
>
> Anyway, I would like to see VCS fields in secure mode
> Vcs-Git: https://anonscm.debian.org/git/pkg-lua/luajit.git
> Vcs-Browser: https://anonscm.debian.org/cgit/pkg-lua/luajit.git
>
>
> and maybe drop the
>
> Pre-Depends: ${misc:Pre-Depends}
> keywords (something already fixed before jessie and the multiarch handling).
>
> Reducing changes to a single patch should be more suitable even for a 0 day 
> NMU,
> while changing std-version and that above stuff will probably mean:
> 1) 15 days delay for the upload
> 2) a maintainer ack.
>
> Your call :)
>
> cheers and thanks for the RFS!
>
> G.



-- 
Best,
Lumin
diff --git a/debian/changelog b/debian/changelog
index 9c053c9..279770c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,19 @@
+luajit (2.1.0~beta2+dfsg-3.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch Rewrite-memory-block-allocator.patch to fix arm64 segfault.
+(Thanks to dann frazier  for verifying the patch)
+(Closes: #818616)
+  * Bump debhelper compat to 10.
+  * Bump Standards Version to 3.9.8 .
+  * Fix misspelled-closes-bug #789321 in previous changelog.
+  * Fix not-binnmuable-any-depends-any: source:Version -> binary:Version .
+  * Build-Depends on debhelper (>= 10~).
+  * Update Vcs-* links.
+  * Remove Pre-Depends: ${misc:Pre-Depends} from control file.
+
+ -- Zhou Mo   Thu, 27 Apr 2017 02:51:26 +
+
 luajit (2.1.0~beta2+dfsg-3) experimental; urgency=medium
 
   * Add ppc64el to Architecture: field in the packages, so ppc64el
@@ -60,7 +76,7 @@ luajit (2.1.0~beta1+dfsg-1) experimental; urgency=medium
 
 luajit (2.0.4+dfsg-1) unstable; urgency=medium
 
-  * New upstream release (Close: #789321)
+  * New upstream release (Closes: #789321)
   * Build on Hurd (Close: #712975)
 
  -- Enrico Tassi   Fri, 14 Aug 2015 16:40:52 +0200
diff --git a/debian/compat b/debian/compat
index ec63514..f599e28 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-9
+10
diff --git a/debian/control b/debian/control
index 75b9298..22e6b8f 100644
--- a/debian/control
+++ b/debian/control
@@ -3,18 +3,17 @@ Section: interpreters
 Priority: optional
 Maintainer: Enrico Tassi 
 Uploaders: Ondřej Surý 
-Build-Depends: debhelper (>= 9~)
-Standards-Version: 3.9.7
-Vcs-Git: git://anonscm.debian.org/pkg-lua/luajit.git
-Vcs-Browser: https://anonscm.debian.org/gitweb/?p=pkg-lua/luajit.git
+Build-Depends: debhelper (>= 10~)
+Standards-Version: 3.9.8
+Vcs-Git: https://anonscm.debian.org/git/pkg-lua/luajit.git
+Vcs-Browser: https://anonscm.debian.org/cgit/pkg-lua/luajit.git
 Homepage: http://luajit.org
 
 Package: luajit
 Architecture: any
 Multi-Arch: foreign
-Pre-Depends: ${misc:Pre-Depends}
 Depends: libluajit-5.1-2 (= ${binary:Version}),
- libluajit-5.1-common (= ${source:Version}),
+ libluajit-5.1-common (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
 Description: Just in time compiler for Lua programming language version 5.1
@@ -37,8 +36,7 @@ Description: Just in time compiler for Lua - common files
 Package: libluajit-5.1-2
 Architecture: any-i386 any-amd64 arm64 armel armhf mips mipsel powerpc ppc64el
 Multi-Arch: same
-Pre-Depends: ${misc:Pre-Depends}
-Depends: libluajit-5.1-common (= ${source:Version}),
+Depends: libluajit-5.1-common (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
 Description: Just in time compiler for Lua - library version
@@ -52,7 +50,6 @@ Description: Just in time compiler for Lua - library version
 Package: libluajit-5.1-dev
 Section: libdevel
 Multi-Arch: same
-Pre-Depends: ${misc:Pre-Depends}
 Architecture: any-i386 any-amd64 arm64 armel armhf mips mipsel powerpc ppc64el
 Depends: libluajit-5.1-2 (= ${binary:Version}),
  ${misc:Depends},
diff --git 

Bug#860206: RFS: sysbench

[JCF Ploemen]

Control: tags -1 - moreinfo
Control: retitle -1 RFS: sysbench/1.0.6+ds-1 [ITA] -- multi-threaded benchmark 
tool for database systems

Updated the packaging to upstream v1.0.6 and tackled some minor issues.
Git branch for use with dgit-maint-gbp workflow is available at:
 https://github.com/jcfp/debpkg-sysbench/tree/master/ (HEAD commit id 5a5d084)

As requested in dgit-sponsorship(7), some sample commands:
To generate the orig tarball:
 origtargz
or using pristine-tar directly:
 pristine-tar checkout ../sysbench_1.0.6+ds.orig.tar.gz

To build the source package:
 dgit --gbp build-source

To Upload:
 dgit --gbp push


pgpnx7ZQkot_C.pgp
Description: OpenPGP digital signature

Bug#861823: RFS: golang-github-manyminds-api2go/1.0-RC2+git20161229.31.dc368bb-1 [ITP]

[Diego M . Rodriguez]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "golang-github-manyminds-api2go"

 * Package name: golang-github-manyminds-api2go
   Version : 1.0-RC2+git20161229.31.dc368bb-1
   Upstream Author : Manyminds 
 * URL : https://github.com/manyminds/api2go
 * License : Expat
   Section : devel

  It builds those binary packages:

golang-github-manyminds-api2go-dev - JSONAPI.org implementation for Go

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/golang-github-manyminds-api2go


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-manyminds-api2go/golang-github-manyminds-api2go_1.0-RC2+git20161229.31.dc368bb-1.dsc

  Or on the following repository:

https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-manyminds-api2go.git

  Changes since the last upload:

* Initial release (Closes: #858354)

  Regards,
   Diego M. Rodriguez

Bug#861811: RFS: golang-github-dop251-goja/0.0~git20170430.0.d382686-1 [ITP]

[Diego M . Rodriguez]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "golang-github-dop251-goja"

 * Package name: golang-github-dop251-goja
   Version : 0.0~git20170430.0.d382686-1
   Upstream Author : Dmitry Panov 
 * URL : https://github.com/dop251/goja
 * License : Expat
   Section : devel

  It builds those binary packages:

golang-github-dop251-goja-dev - ECMAScript 5.1(+) implementation written in 
Go

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/golang-github-dop251-goja


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-dop251-goja/golang-github-dop251-goja_0.0~git20170430.0.d382686-1.dsc

  Or on the following repository:

https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-dop251-goja.git

  Changes since the last upload:

  * Initial release (Closes: #858357)

  Regards,
   Diego M. Rodriguez

Bug#861757: RFS: fonts-fandol/0.3-1 [ITP]

[Boyuan Yang]

在 2017年5月4日星期四 CST 上午8:09:13，Paul Wise 写道：
> On Thu, 4 May 2017 00:38:24 +0200 Adam Borowski wrote:
> > I'm not entirely sure .otf are the real sources, despite the upstream
> > providing only otf.  For now, let's assume they are, unless there's
> > evidence to the contrary (not sure what the README means).
> 
> The README is pretty clear that the fonts are compile to OpenType using
> AFDKO from FontForge and or Inkscape source. AFDKO is not in Debian
> main so this font should go to contrib. In addition, no FontForge
> source format or SVG files were released and the font is under the
> GPL so I don't think we can distribute this at all. Please ask the
> ftp-masters to reject this package from NEW.

In the email from upstream, he seems unwilling to solve this so-called 
"problem" in his POV. OTF fonts and so-called "source" (CID postscript fonts) 
only differs on font encapsulation, which means they can convert to each other 
without losing information. That is different from typical compilation process. 
AFDKO is only a convert tool, not a compiler. Upstream said he is releasing 
.otf fonts under GPL and that should not bother with AFDKO or other tools, 
which is used in font development.

As a result, upstream (and I) are in doubt whether this would cause rejection 
in Debian.

There are lots of fonts in Debian with only .ttf or .otf fonts as source. Is 
there a convincing policy that regulates sources of fonts in Debian? (e.g.
what is "source" and what is "binary"?)

P.S. AFDKO packaging is being worked on packaging.
 (http://anonscm.debian.org/cgit/pkg-fonts/afdko.git)

--
Boyuan Yang

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

Bug#861805: RFS: golang-github-puerkitobio-goquery/1.1.0+git20170324.3.ed7d758-1 [ITP]

[Diego M . Rodriguez]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "golang-github-puerkitobio-goquery"

 * Package name: golang-github-puerkitobio-goquery
   Version : 1.1.0+git20170324.3.ed7d758-1
   Upstream Author : Martin Angers 
 * URL : https://github.com/PuerkitoBio/goquery
 * License : BSD-3-clause
   Section : devel

  It builds those binary packages:

golang-github-puerkitobio-goquery-dev - jQuery-style HTML manipulation in Go

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/golang-github-puerkitobio-goquery


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-puerkitobio-goquery/golang-github-puerkitobio-goquery_1.1.0+git20170324.3.ed7d758-1.dsc

  Or on the following repository:

https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-puerkitobio-goquery.git


  Changes since the last upload:

  * Initial release (Closes: #858359)

  Regards,
   Diego M. Rodriguez

Re: How to deal with arch-specific paths in .install files

[phil]

On 2017-05-03 20:36, Shawn Sörbom wrote:

Hi
I have a package .install file where a library expects to go into 
/usr/lib/
x86_64-gnu/[subdirectory] on amd64 systems. I realize this is not 
portable.
What regex can I use to substitute for the arch directory in my 
.install file?

Thanks,
shawn


I didn't manage to use the install file for this. Globbing is too 
restrictive an there are various subdirs in /usr/lib. I update the rules 
file as below:


---8<---
export DEB_TARGET_GNU_CPU = $(shell dpkg-architecture 
-qDEB_TARGET_GNU_CPU)
export DEB_TARGET_GNU_SYSTEM = $(shell dpkg-architecture 
-qDEB_TARGET_GNU_SYSTEM)


override_dh_install:
dh_install
	dh_install -p  
/usr/lib/$(DEB_TARGET_GNU_CPU)-$(DEB_TARGET_GNU_SYSTEM)/

---8<---

The source_file should not be in the .install file. dh_install will 
install all others files using (among others) the install files content.
Then this very file will be installed using the tuples given by 
dpkg-architecture.


--
Philippe THIERRY.