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
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 renaming
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/arch/. In the majority of
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 build
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/arch/.
Nothing
Thibaut Paumard thib...@debian.org 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
Andrey Rahmatullin w...@wrar.name 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
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
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/arch/.
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 overdo
-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.
My
Andrey Rahmatullin w...@wrar.name 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
+++ 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 would work
+++ Оlе Ѕtrеісhеr [2014-03-10 11:39 +0100]:
Andrey Rahmatullin w...@wrar.name 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 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,
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 mara...@gmail.com
* URL
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
/usr/lib/arch/.
Andrey Rahmatullin w...@wrar.name 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 split
* Andrey Rahmatullin w...@wrar.name, 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
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.1.1
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)
On Fri, Mar 7, 2014 at 11:44 PM, Vern Sun s5u...@gmail.com wrote:
Dear mentors,
I am looking for a sponsor for ranger:
* Package name: ranger
* Version : 1.6.1-1
* Upstream Author : Roman Zimbelmann h...@lavabit.com
David Barnett davidbarne...@gmail.com
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 pa...@netfilter.org
* URL :
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
Hi
I'm getting the Lintian error
apache2-module-does-not-depend-on-apache2-api
http://lintian.debian.org/tags/apache2-module-does-not-depend-on-apache2-api.html
on my package http://mentors.debian.net/package/pstar .
I apparently have to make the package depend on a virtual package called
Jakub Wilk jw...@debian.org writes:
* Andrey Rahmatullin w...@wrar.name, 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
Atle Solbakken a...@goliathdns.no writes:
I'm getting the Lintian error
apache2-module-does-not-depend-on-apache2-api
http://lintian.debian.org/tags/apache2-module-does-not-depend-on-apache2-api.html
on my package http://mentors.debian.net/package/pstar .
I apparently have to make the
On Mon, Mar 10, 2014 at 1:44 PM, Russ Allbery r...@debian.org wrote:
Jakub Wilk jw...@debian.org writes:
* Andrey Rahmatullin w...@wrar.name, 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
Your message dated Mon, 10 Mar 2014 17:01:00 -0700
with message-id
CACZd_tAq=N27EGDx1CLfVHqSKA6A2553fEdVn+=tbywnt0f...@mail.gmail.com
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
Your message dated Tue, 11 Mar 2014 04:25:29 +
with message-id e1wneft-0007no...@quantz.debian.org
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:
30 matches
Mail list logo
