Re: script-with-language-extension

2014-03-10 Thread Thomas Goirand
On 03/10/2014 04:49 AM, Salvo Tomaselli wrote: > Not sure if fixing it by renaming the files is what you want to do. > > I have such a warning in xinetd and honestly I just ignore it because I don't > think that renaming scripts after they have been there for many years is a > good idea. Besides

Re: script-with-language-extension

2014-03-10 Thread Charles Plessy
Le Mon, Mar 10, 2014 at 03:19:51PM +0800, Thomas Goirand a écrit : > On 03/10/2014 04:49 AM, Salvo Tomaselli wrote: > > Not sure if fixing it by renaming the files is what you want to do. > > > > I have such a warning in xinetd and honestly I just ignore it because I > > don't > > think that ren

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Thibaut Paumard
Le 08/03/2014 14:02, Оlе Ѕtrеісhеr a écrit : > Hi, > > I am packaging some older software (eso-midas, [1]) that installs > everything into a common directory (f.e. /usr/lib/eso-midas/). However, > the FHS requires that this should be split between /usr/share/ and > /usr/lib//. In the majority of c

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Andrey Rahmatullin
On Mon, Mar 10, 2014 at 10:19:29AM +0100, Thibaut Paumard wrote: > What I would try is to compile the package on two distinct architectures > (or more) and compare the result. That would work unless the build for > these files is non-deterministic or includes timestamps or information > on the buil

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Andrey Rahmatullin
On Sat, Mar 08, 2014 at 02:02:48PM +0100, Оlе Ѕtrеісhеr wrote: > I am packaging some older software (eso-midas, [1]) that installs > everything into a common directory (f.e. /usr/lib/eso-midas/). However, > the FHS requires that this should be split between /usr/share/ and > /usr/lib//. Nothing fo

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Оlе Ѕtrеісhеr
Thibaut Paumard writes: > Le 08/03/2014 14:02, Оlе Ѕtrеісhеr a écrit : >> Hi, >> >> I am packaging some older software (eso-midas, [1]) that installs >> everything into a common directory (f.e. /usr/lib/eso-midas/). However, >> the FHS requires that this should be split between /usr/share/ and >>

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Оlе Ѕtrеісhеr
Andrey Rahmatullin writes: > On Sat, Mar 08, 2014 at 02:02:48PM +0100, Оlе Ѕtrеісhеr wrote: >> I am packaging some older software (eso-midas, [1]) that installs >> everything into a common directory (f.e. /usr/lib/eso-midas/). However, >> the FHS requires that this should be split between /usr/sha

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Thibaut Paumard
Hi, Le 10/03/2014 10:45, Andrey Rahmatullin a écrit : > On Mon, Mar 10, 2014 at 10:19:29AM +0100, Thibaut Paumard wrote: >> What I would try is to compile the package on two distinct architectures >> (or more) and compare the result. That would work unless the build for >> these files is non-deter

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Andrey Rahmatullin
On Mon, Mar 10, 2014 at 10:54:44AM +0100, Оlе Ѕtrеісhеr wrote: > >> I am packaging some older software (eso-midas, [1]) that installs > >> everything into a common directory (f.e. /usr/lib/eso-midas/). However, > >> the FHS requires that this should be split between /usr/share/ and > >> /usr/lib//.

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Thibaut Paumard
Hi, Le 10/03/2014 10:50, Оlе Ѕtrеісhеr a écrit : > [packaging ESO MIDAS] > Let's see how far I come. BTW, Since I do not use it myself: Is it worth > to split it into core, applic, stdred, and contrib packages? Is there > any use for keeping the source? It's already great to package it, don't ove

Re: script-with-language-extension

2014-03-10 Thread Daniel Lintott
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/03/14 00:26, gregor herrmann wrote: > On Sun, 09 Mar 2014 21:39:01 +, Dave Walker wrote: > >>> Net::Frame::Device includes two scripts that are installed to >>> /usr/bin, but both have .pl extensions therefore giving me a >>> Lintian warning

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Оlе Ѕtrеісhеr
Andrey Rahmatullin writes: > On Mon, Mar 10, 2014 at 10:54:44AM +0100, Оlе Ѕtrеісhеr wrote: >> >> I am packaging some older software (eso-midas, [1]) that installs >> >> everything into a common directory (f.e. /usr/lib/eso-midas/). However, >> >> the FHS requires that this should be split betwee

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Wookey
+++ Thibaut Paumard [2014-03-10 10:59 +0100]: > Hi, > > Le 10/03/2014 10:45, Andrey Rahmatullin a écrit : > > On Mon, Mar 10, 2014 at 10:19:29AM +0100, Thibaut Paumard wrote: > >> What I would try is to compile the package on two distinct architectures > >> (or more) and compare the result. That w

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Wookey
+++ Оlе Ѕtrеісhеr [2014-03-10 11:39 +0100]: > Andrey Rahmatullin writes: > > > On Mon, Mar 10, 2014 at 10:54:44AM +0100, Оlе Ѕtrеісhеr wrote: > >> >> I am packaging some older software (eso-midas, [1]) that installs > >> >> everything into a common directory (f.e. /usr/lib/eso-midas/). However, >

Re: script-with-language-extension

2014-03-10 Thread Salvo Tomaselli
> > The Debian policy manual don't agree with you, AFAIR. I know it doesn't, that's why lintian complains. But what should I do? I think renaming a command would cause more disruption. Best -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso,

Bug#741249: RFS: maradns/2.0.09-2 [RC]

2014-03-10 Thread Dariusz Dwornikowski
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "maradns". As always I checked with cowbuilder and piuparts. * Package name: maradns Version : 2.0.09-2 Upstream Author : Sam Trenholme * URL : http://

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Andrey Rahmatullin
On Mon, Mar 10, 2014 at 11:39:22AM +0100, Оlе Ѕtrеісhеr wrote: > >> >> I am packaging some older software (eso-midas, [1]) that installs > >> >> everything into a common directory (f.e. /usr/lib/eso-midas/). However, > >> >> the FHS requires that this should be split between /usr/share/ and > >> >>

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Оlе Ѕtrеісhеr
Andrey Rahmatullin writes: > On Mon, Mar 10, 2014 at 11:39:22AM +0100, Оlе Ѕtrеісhеr wrote: >> >> >> I am packaging some older software (eso-midas, [1]) that installs >> >> >> everything into a common directory (f.e. /usr/lib/eso-midas/). However, >> >> >> the FHS requires that this should be spl

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Jakub Wilk
* Andrey Rahmatullin , 2014-03-10, 20:24: FHS does: "Miscellaneous architecture-independent application-specific static files and subdirectories must be placed in /usr/share." [1] Do we enforce this? Not really. "9.1.1 File System Structure The location of all files and directories must co

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Andrey Rahmatullin
On Mon, Mar 10, 2014 at 03:51:01PM +0100, Jakub Wilk wrote: > >I also wonder if finding an arch-indep file in /usr/lib should > >result in an RC bug. > No. We should relax the policy to match the current practice. On Mon, Mar 10, 2014 at 03:40:33PM +0100, Оlе Ѕtrеісhеr wrote: > Since the Policy 9

Re: The debug package best practice?

2014-03-10 Thread Osamu Aoki
Hi, On Sun, Mar 09, 2014 at 11:01:18PM +0800, Paul Wise wrote: > The most useful thing you could do is help out with the plan for > automatic debug packages for every binary package with debug symbols. > > https://wiki.debian.org/AutomaticDebugPackages I see. It is interesting. (but not for me)

Re: RFS: ranger/1.6.1-1 (new upstream release)

2014-03-10 Thread Aron Xu
On Fri, Mar 7, 2014 at 11:44 PM, Vern Sun wrote: > Dear mentors, > > I am looking for a sponsor for "ranger": > > * Package name: ranger > * Version : 1.6.1-1 > * Upstream Author : Roman Zimbelmann > David Barnett > Abdó Roig-Maranges >

Bug#741271: RFS: libnftnl/1.0.0+git20140122-1 [ITP] (repackaged, resend)

2014-03-10 Thread Arturo Borrero Gonzalez
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libnftnl" * Package name: libnftnl Version : 1.0.0+git20140122-1 Upstream Author : Pablo Neira Ayuso * URL : http://netfilter.org/projects/libnftnl/index.htm

Bug#741287: RFS: zmap/1.2.0-1

2014-03-10 Thread Dariusz Dwornikowski
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "zmap". As always checked with cowbuilder and puiparts. Vincent, Clint please sponsor if you can. * Package name: zmap Version : 1.2.0-1 Upstream Author : Zakir Du

Lintian error for package with Apache2 module

2014-03-10 Thread Atle Solbakken
Hi I'm getting the Lintian error apache2-module-does-not-depend-on-apache2-api on my package http://mentors.debian.net/package/pstar . I apparently have to make the package depend on a virtual package called

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Russ Allbery
Jakub Wilk writes: > * Andrey Rahmatullin , 2014-03-10, 20:24: >> I also wonder if finding an arch-indep file in /usr/lib should result >> in an RC bug. > No. We should relax the policy to match the current practice. I concur -- I really doubt this is important enough these days for most packag

Re: Lintian error for package with Apache2 module

2014-03-10 Thread Russ Allbery
Atle Solbakken writes: > I'm getting the Lintian error > apache2-module-does-not-depend-on-apache2-api > > on my package http://mentors.debian.net/package/pstar . > I apparently have to make the package depend on

Re: Splitting in /usr/lib/ and /usr/share

2014-03-10 Thread Vincent Cheng
On Mon, Mar 10, 2014 at 1:44 PM, Russ Allbery wrote: > Jakub Wilk writes: >> * Andrey Rahmatullin , 2014-03-10, 20:24: > >>> I also wonder if finding an arch-indep file in /usr/lib should result >>> in an RC bug. > >> No. We should relax the policy to match the current practice. > > I concur -- I

Bug#741287: marked as done (RFS: zmap/1.2.0-1)

2014-03-10 Thread Debian Bug Tracking System
Your message dated Mon, 10 Mar 2014 17:01:00 -0700 with message-id and subject line Re: Bug#741287: RFS: zmap/1.2.0-1 has caused the Debian Bug report #741287, regarding RFS: zmap/1.2.0-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the cas

Bug#726993: marked as done (RFS: django-celery-transactions/0.1.3-1 [ITP] -- Django transaction support for Celery tasks)

2014-03-10 Thread Debian Bug Tracking System
Your message dated Tue, 11 Mar 2014 04:25:29 + with message-id and subject line closing RFS: django-celery-transactions/0.1.3-1 [ITP] -- Django transaction support for Celery tasks has caused the Debian Bug report #726993, regarding RFS: django-celery-transactions/0.1.3-1 [ITP] -- Django tran