On Mon, Sep 19, 2022 at 5:07 PM Aaron Boxer wrote:
>
>
> On Mon, Sep 19, 2022 at 3:10 PM Jeremy Sowden wrote:
>
>> On 2022-09-18, at 20:35:37 -0400, Aaron Boxer wrote:
>> > https://qa.debian.org/bls/packages/l/libgrokj2k.html
>> >
>> > >From the build logs, I am unable to find which compiler fla
On Mon, Sep 19, 2022 at 3:10 PM Jeremy Sowden wrote:
> On 2022-09-18, at 20:35:37 -0400, Aaron Boxer wrote:
> > https://qa.debian.org/bls/packages/l/libgrokj2k.html
> >
> > >From the build logs, I am unable to find which compiler flags are
> hidden.
> > What's the best way of getting more informa
On 2022-09-18, at 20:35:37 -0400, Aaron Boxer wrote:
> https://qa.debian.org/bls/packages/l/libgrokj2k.html
>
> >From the build logs, I am unable to find which compiler flags are hidden.
> What's the best way of getting more information about the warning ?
Running blhc on a couple of the build-lo
https://qa.debian.org/bls/packages/l/libgrokj2k.html
>From the build logs, I am unable to find which compiler flags are hidden.
What's the best way of getting more information about the warning ?
Thanks!
On Mon, Sep 12, 2022 at 8:59 AM Andrey Rahmatullin wrote:
> On Mon, Sep 12, 2022 at 08:49:53AM -0400, Aaron Boxer wrote:
> > mips66el is not a target platform
> What do you mean?
>
by that, I mean I don't have access to this platform for my own testing,
and I doubt there are any users currently
On Mon, Sep 12, 2022 at 08:49:53AM -0400, Aaron Boxer wrote:
> mips66el is not a target platform
What do you mean?
--
WBR, wRAR
signature.asc
Description: PGP signature
Thanks, not a big deal then :)
On Mon, Sep 12, 2022 at 8:50 AM David Bürgin wrote:
> Aaron Boxer:
> > Here is the warning report
> >
> > https://udd.debian.org/lintian/?packages=libgrokj2k
> >
> > and explanation of the warning
> >
> > https://lintian.debian.org/tags/executable-stack-in-shared-l
a, I missed that. mips66el is not a target platform, so I suppose I can
ignore this warning.
On Mon, Sep 12, 2022 at 8:47 AM Andrey Rahmatullin wrote:
> On Mon, Sep 12, 2022 at 08:37:34AM -0400, Aaron Boxer wrote:
> > Here is the warning report
> >
> > https://udd.debian.org/lintian/?package
Aaron Boxer:
> Here is the warning report
>
> https://udd.debian.org/lintian/?packages=libgrokj2k
>
> and explanation of the warning
>
> https://lintian.debian.org/tags/executable-stack-in-shared-library
>
> I ran `readelf -l` on the .so, and I noticed that there is no E flag
> on the GNU_STACK
On Mon, Sep 12, 2022 at 08:37:34AM -0400, Aaron Boxer wrote:
> Here is the warning report
>
> https://udd.debian.org/lintian/?packages=libgrokj2k
It happens on mips* in other packages too.
> I ran `readelf -l` on the .so, and I noticed that there is no E flag
> on the GNU_STACK entry. So, it look
Here is the warning report
https://udd.debian.org/lintian/?packages=libgrokj2k
and explanation of the warning
https://lintian.debian.org/tags/executable-stack-in-shared-library
I ran `readelf -l` on the .so, and I noticed that there is no E flag
on the GNU_STACK entry. So, it looks like this is
Hi Dimitry,
On 22 July 2016 at 17:05, Dmitry Bogatov wrote:
> `apt-get install dh-linktree`. Usage is simple, documentation is good,
> but you can take a look as example at cdist_4.2.1-1.
Thank you. That did the trick[1].
> Unfortunately, dh-linktree is not magic, and you have manually
> specif
* Tiago Ilieve , 2016-07-22, 15:49:
W: grip: duplicate-font-file
usr/share/grip/grip/static/octicons/octicons.ttf also in fonts-octicons
Is there a helper to deal with this kind of issue? Like the
"sphinxdoc"[2] one, which automatically replaces embedded JS files to
their respective links?
> I'm updating the "grip" package (bug #832000[1]), which resulted in
> the following lintian warning:
>
> W: grip: duplicate-font-file
> usr/share/grip/grip/static/octicons/octicons.ttf also in
> fonts-octicons
>
> Is there a helper to deal with this kind
Hi,
I'm updating the "grip" package (bug #832000[1]), which resulted in
the following lintian warning:
W: grip: duplicate-font-file
usr/share/grip/grip/static/octicons/octicons.ttf also in
fonts-octicons
Is there a helper to deal with this kind of issue? Like the
"sphi
On 11-10-15 22:22, Jakub Wilk wrote:
> * Sebastiaan Couwenberg , 2015-10-08, 21:01:
>> To deal with the external usage of liblwgeom built from the postgis
>> sources, the upstream developers now use the -release libtool option
>> along with -version-info to better support installation of multiple
>
* Sebastiaan Couwenberg , 2015-10-08, 21:01:
To deal with the external usage of liblwgeom built from the postgis
sources, the upstream developers now use the -release libtool option
along with -version-info to better support installation of multiple
postgis versions.
The -release option was a
To deal with the external usage of liblwgeom built from the postgis
sources, the upstream developers now use the -release libtool option
along with -version-info to better support installation of multiple
postgis versions.
The -release option was added to support the multiple version use case
on W
On Thu, Sep 11, 2014 at 09:45:07PM +0100, Daniel Lintott wrote:
> On 11/09/14 21:31, Andreas Tille wrote:
> > Hi,
> >
> > I would like to upload libsbml5 but despite the fact that
> > ${perl:Depends} is specified and dh calls dh_perl automatically this
> > lintian error occures. To enable easy in
Hi Gregor,
gregor herrmann schrieb :
> Control: tag -1 + patch
[...]
> That's usually caused by a build system which uses INSTALLDIRS=site,
> which should be vendor ... And in practice left out in Debian since
> our toolery sets it.
>
> Here we are:
>
> % grep -ir installdirs *
> [..]
> src/bi
Hi,
Eriberto schrieb :
> Hi Andreas,
>
> I didn't see the package. However, it can be a false positive from new
> Lintian. I already had three false positives from new checks.
>
> Please, see the bugs of the Lintian in BTS to identify if it is or not
> a false positive.
If I look into the pac
Jakub Wilk schrieb :
> * Andreas Tille , 2014-09-11, 22:31:
> >I would like to upload libsbml5 but despite the fact that
> >${perl:Depends} is specified and dh calls dh_perl automatically this
> >lintian error occures. To enable easy inspection I have uploaded
> >the preliminary packages to
>
* Andreas Tille , 2014-09-11, 22:31:
I would like to upload libsbml5 but despite the fact that
${perl:Depends} is specified and dh calls dh_perl automatically this
lintian error occures. To enable easy inspection I have uploaded the
preliminary packages to
https://people.debian.org/~tille/
Hi,
On Thu, Sep 11, 2014 at 05:45:21PM -0300, Eriberto wrote:
> Hi Andreas,
>
> I didn't see the package.
As I said all files are at
https://people.debian.org/~tille/packages/libsmbl5/
> However, it can be a false positive from new
> Lintian. I already had three false positives from new che
Hi Andreas,
I didn't see the package. However, it can be a false positive from new
Lintian. I already had three false positives from new checks.
Please, see the bugs of the Lintian in BTS to identify if it is or not
a false positive.
I hope this help.
Cheers,
Eriberto
2014-09-11 17:31 GMT-03
Hi Andreas,
I don't know the reason why, but I'll add the Debian Perl guys into the
loop... as they may well have more of an idea as I know they have doing
a lot of work in relation to the perl 5.20 transition
Regards
Daniel
On 11/09/14 21:31, Andreas Tille wrote:
> Hi,
>
> I would like to upl
Hi,
I would like to upload libsbml5 but despite the fact that
${perl:Depends} is specified and dh calls dh_perl automatically this
lintian error occures. To enable easy inspection I have uploaded the
preliminary packages to
https://people.debian.org/~tille/packages/libsmbl5/
Any help to fix
Hi Jakub,
> You have this:
>
> override_dh_makeshlibs:
> dh_makeshlibs -V "libnxml0, libnxml-abi-$(DEB_UPSTREAM_VERSION)"
>
> But here is nothing in debian/rules that would define the
> DEB_UPSTREAM_VERSION variable.
>
You completely made my day! :-)
That's right, DEB_UPSTREAM_VERSION is
* Joseph Herlant , 2014-03-18, 21:51:
W: libnxml0: shlibs-declares-dependency-on-other-package libnxml0, libnxml-abi-
You have this:
override_dh_makeshlibs:
dh_makeshlibs -V "libnxml0, libnxml-abi-$(DEB_UPSTREAM_VERSION)"
But here is nothing in debian/rules that would define the
DEB_
On 2014-03-18, Joseph Herlant wrote:
> The complete version of the packages are currently available on
> mentors (for those who would like to have a look a little deeper about
> what's wrong):
> https://mentors.debian.net/package/libnxml
> and
> https://mentors.debian.net/package/libmrss
>
> The w
Dear mentors,
I'm currently moving 2 packages (libnxml and libmrss) to debhelper 9,
multiarch and from cdbs to classic dh.
I'm almost done, but I still have lintian complaining about
"shlibs-declares-dependency-on-other-package" on both packages.
I read the debian sharedlibs policy and googled th
On Mon, Dec 24, 2012 at 09:40:54PM +0300, Alexander Busorguin wrote:
> It was caused by calls to Festival functions, for example: void
> festival_tidy_up();
(because -lFestival is static-only)
--
WBR, wRAR
signature.asc
Description: Digital signature
On 22/05/12 09:57, Niels Thykier wrote:
> On 2012-05-21 17:38, Daniel Pocock wrote:
>> On 21/05/12 10:02, Andrey Rahmatullin wrote:
>>> [...]
- - make a lintian override to suppress the warning, with a comment to
explain I am using -release deliberately for resiprocate?
>>> I'm not sure y
On 2012-05-21 17:38, Daniel Pocock wrote:
> On 21/05/12 10:02, Andrey Rahmatullin wrote:
>> [...]
>>> - - make a lintian override to suppress the warning, with a comment to
>>> explain I am using -release deliberately for resiprocate?
>> I'm not sure you want to keep the current names for the lib a
On 21/05/12 10:02, Andrey Rahmatullin wrote:
> On Mon, May 21, 2012 at 09:03:09AM +, Daniel Pocock wrote:
b) I notice the verbose output (on the mentors summary page)
shows an SONAME in a slightly different format:
usr/lib/librutil-1.8.so.0.0.0 usr/lib/librutil-1.8.so
>
On Mon, May 21, 2012 at 09:03:09AM +, Daniel Pocock wrote:
> >> b) I notice the verbose output (on the mentors summary page)
> >> shows an SONAME in a slightly different format:
> >>
> >> usr/lib/librutil-1.8.so.0.0.0 usr/lib/librutil-1.8.so
> >>
> >> Notice: librutil-1.8.so, while the -dev p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 21/05/12 06:57, Andrey Rahmatullin wrote:
> On Sun, May 20, 2012 at 08:59:02PM +, Daniel Pocock wrote:
>>
>> My package: http://mentors.debian.net/package/resiprocate
>>
>> The warning:
>> http://lintian.debian.org/tags/dev-pkg-without-shli
On Sun, May 20, 2012 at 08:59:02PM +, Daniel Pocock wrote:
>
> My package:
> http://mentors.debian.net/package/resiprocate
>
> The warning:
> http://lintian.debian.org/tags/dev-pkg-without-shlib-symlink.html
>
> a) I notice the warning is appearing for the lib package and NOT the
> -dev pack
My package:
http://mentors.debian.net/package/resiprocate
The warning:
http://lintian.debian.org/tags/dev-pkg-without-shlib-symlink.html
a) I notice the warning is appearing for the lib package and NOT the
-dev package itself
b) I notice the verbose output (on the mentors summary page) shows an
Thijs Kinkhorst <[EMAIL PROTECTED]> writes:
> On Tuesday 5 August 2008 14:02, Richard Hurt wrote:
> > W: : script-non-executable -- Since this is a scripted
> > web application (RoR) there are quite a few "scripts" that are not
> > executable directly in the shell. Can I turn this warning off for
On Aug 5, 2008, at 6:34 PM| Aug 5, 2008, Eduardo M KALINOWSKI wrote:
Except, perhaps, from scripts which end up installed in the
directories
in the path. For scripts that are not in the path (and even if the
execute bit set can only be executed with extra measures from the
user)
it should
On Wednesday 06 August 2008 01:56:59 Eduardo M KALINOWSKI wrote:
> Joey Hess wrote:
> > Eduardo M KALINOWSKI wrote:
> >> If the policy suggestion that leads to that lintian warning is so
> >> unreasonable, it might as well be taken off the policy.
> >
> > I&
Eduardo M KALINOWSKI <[EMAIL PROTECTED]> writes:
> Joey Hess wrote:
>> Eduardo M KALINOWSKI wrote:
>>> If the policy suggestion that leads to that lintian warning is so
>>> unreasonable, it might as well be taken off the policy.
>> I'm not aware o
Joey Hess wrote:
> Eduardo M KALINOWSKI wrote:
>
>> If the policy suggestion that leads to that lintian warning is so
>> unreasonable, it might as well be taken off the policy.
>>
>
> I'm not aware of any such thing in policy
Then maybe the lintian
Eduardo M KALINOWSKI wrote:
> If the policy suggestion that leads to that lintian warning is so
> unreasonable, it might as well be taken off the policy.
I'm not aware of any such thing in policy.
--
see shy jo
signature.asc
Description: Digital signature
omplaining about it, I'd be hard pressed to not laugh in their
> face.
>
If the policy suggestion that leads to that lintian warning is so
unreasonable, it might as well be taken off the policy.
> Lintian has overrides so that you can turn off this type of warning,
> which
Michal Čihař <[EMAIL PROTECTED]> writes:
> Richard Hurt <[EMAIL PROTECTED]> napsal(a):
>> W: : package-contains-empty-directory -- Some of these are
>> necessary (cache, assets, etc.) and some aren't (test). Can I turn
>> these off?
> Yes, add override for these.
Lintian does not warn abou
Eduardo M KALINOWSKI wrote:
> If the scripts are not directly executable, you can remove the
> #! line from them. That should make the warning go away.
> It would be better to talk with upstream so he does that.
If I were upstream and was pestered by a distribution to remove the
hashbang lines t
Hi
Dne Tue, 5 Aug 2008 08:02:28 -0400
Richard Hurt <[EMAIL PROTECTED]> napsal(a):
> I am getting quite a few lintian warnings that I would like to quell.
> Do we have any best practices on how to deal with these messages?
>
> W: : debian-copyright-line-too-long -- As I understand it
> long
Hi Richard,
On Tuesday 5 August 2008 14:02, Richard Hurt wrote:
> I am getting quite a few lintian warnings that I would like to quell.
> Do we have any best practices on how to deal with these messages?
>
> W: : debian-copyright-line-too-long -- As I understand it
> long lines are now OK. I am
Richard Hurt escreveu:
W: : script-non-executable -- Since this is a scripted web
application (RoR) there are quite a few "scripts" that are not
executable directly in the shell. Can I turn this warning off for
these files?
If the scripts are not directly executable, you can remove the
#!
I am getting quite a few lintian warnings that I would like to quell.
Do we have any best practices on how to deal with these messages?
W: : debian-copyright-line-too-long -- As I understand it
long lines are now OK. I am following the new, proposed guidelines
for the copyright file (htt
Hello.
On Fri, Feb 29, 2008 at 02:22:42PM +0800, LI Daobing wrote:
> when I package glusterfs, I meet a lintian warning:
> shlib-with-executable-stack, more information as follows[1].
>
> how can I deal with this warning?
Is this a trick question? Because the obvious answer seem
Hello,
when I package glusterfs, I meet a lintian warning:
shlib-with-executable-stack, more information as follows[1].
how can I deal with this warning?
you can download the source package by 'dget
http://mentors.debian.net/debian/pool/main/g/glusterfs/glusterfs_1.3.8~pre1-1.dsc'
T
Daniel Leidert wrote:
> The menu sections have been changed. There is no Tools sub-section
> anymore. See file:///usr/share/doc/menu/html/ch3.html#s3.5. Maybe your
> program fits "Data Management".
>
> Regards, Daniel
Thanks.
Someone should update
http://www.debian.org/doc/packaging-manua
On Wed, 05 Sep 2007 18:05:25 +0200
schoenfeld / in-medias-res <[EMAIL PROTECTED]> wrote:
> I am trying to add a menu item for my package password-gorilla. And
> because the best place is in Applications\Tools i do wanna place it there:
Tools has disappeared. You need to find a new location.
http
Am Mittwoch, den 05.09.2007, 18:05 +0200 schrieb schoenfeld /
in-medias-res:
> I am trying to add a menu item for my package password-gorilla. And
> because the best place is in Applications\Tools i do wanna place it there:
>
> ?package(password-gorilla):needs="X11" section="Applications/Tools"\
Hi,
I am trying to add a menu item for my package password-gorilla. And
because the best place is in Applications\Tools i do wanna place it there:
?package(password-gorilla):needs="X11" section="Applications/Tools"\
title="password-gorilla" command="/usr/bin/password-gorilla"
Now i get the lin
Hi,
I've contacted the upstream author, I'm waiting for a new tarball
fixed...
thanks for the help.
cheers,
francesco
Il giorno mer, 05/09/2007 alle 10.44 +1000, Paul Wise ha scritto:
> On 9/5/07, Raphael Geissert <[EMAIL PROTECTED]> wrote:
>
> > > What is the best method to solve this problem
On 9/5/07, Raphael Geissert <[EMAIL PROTECTED]> wrote:
> > What is the best method to solve this problem? it's a good solution to
> > repackage the tar.gz? and in this case I have to add a suffix like
> > foo-0.1+dsfg.orig.tar.gz?
>
> I would first try to contact upstream and ask him to reupload t
Hello,
On 04/09/07, Francesco Namuri <[EMAIL PROTECTED]> wrote:
> Hi,
> I'm trying to make the package of gtkol-ldap nice ldap administration
> utility for gnome, the problem is that the orginal tarball contains
> config.status and config.log, I think that the upstream has forgetted to
> do a make
Hi,
I'm trying to make the package of gtkol-ldap nice ldap administration
utility for gnome, the problem is that the orginal tarball contains
config.status and config.log, I think that the upstream has forgetted to
do a make distclean before creating the tar.gz (i think so because doing
make distcl
Russ Allbery ([EMAIL PROTECTED]):
> Do you have CDPATH set? If so, this is a bug in lintian that's already
> fixed in Subversion.
Yes I have, after removing this variable all warnings disappeared :)
Thanks.
My gaupol package is lintian clean again :)
Can anyone upload it?
--
-=[ Piotr Ozaro
Piotr Ozarowski <[EMAIL PROTECTED]> writes:
> What does "manpage-has-errors-from-man" warning mean?
> After upgrading my lintian from 1.23.15 to 1.23.16
> I'm getting this warning _every_ _time_ I check a package that has a
> manpage.
> Is this a lintian bug? Should I report it on BTS?
Do you ha
Eduardo M KALINOWSKI ([EMAIL PROTECTED]):
> Do you perchance have the -v flag in the GZIP environment variable, or
> are passing it to gzip (and gunzip) by default somehow? Because if this
> is the case, then lintian will consider the output of gzip (something
> like "file: 80.2% -- etc, etc") as a
Piotr Ozarowski wrote:
>Andrea Bolognani ([EMAIL PROTECTED]):
>
>
>>It means the man page is not correct.
>>See http://lintian.debian.org/reports/Tmanpage-has-errors-from-man.html
>>
>>
>
>But I'm not getting "cannot adjust", "can't break" or "can't find
>numbered character". All I get is:
>
On Sun, 2 Apr 2006 23:54:01 +0200
Piotr Ozarowski <[EMAIL PROTECTED]> wrote:
> KiyuKo ([EMAIL PROTECTED]):
> > My version of lintian (1.23.8) doesn't give any error while checking
> > lintian_1.23.16_all.deb, so if you have an up-to-date version of lintian
> > it's very likely the bug is in lintia
KiyuKo ([EMAIL PROTECTED]):
> My version of lintian (1.23.8) doesn't give any error while checking
> lintian_1.23.16_all.deb, so if you have an up-to-date version of lintian it's
> very likely the bug is in lintian itself.
>
> Have you tried checking the package with linda instead?
Linda (lintian
On Sun, 2 Apr 2006 23:32:49 +0200
Piotr Ozarowski <[EMAIL PROTECTED]> wrote:
> Andrea Bolognani ([EMAIL PROTECTED]):
> > It means the man page is not correct.
> > See http://lintian.debian.org/reports/Tmanpage-has-errors-from-man.html
>
> But I'm not getting "cannot adjust", "can't break" or "can
Andrea Bolognani ([EMAIL PROTECTED]):
> It means the man page is not correct.
> See http://lintian.debian.org/reports/Tmanpage-has-errors-from-man.html
But I'm not getting "cannot adjust", "can't break" or "can't find
numbered character". All I get is:
$ lintian ./gaupol_0.4.0-1_all.deb
/tmp/eOvx
On Sun, 2 Apr 2006 22:59:04 +0200
Piotr Ozarowski <[EMAIL PROTECTED]> wrote:
> What does "manpage-has-errors-from-man" warning mean?
> After upgrading my lintian from 1.23.15 to 1.23.16
> I'm getting this warning _every_ _time_ I check a package that has a
> manpage.
>
> Is this a lintian bug? Sh
What does "manpage-has-errors-from-man" warning mean?
After upgrading my lintian from 1.23.15 to 1.23.16
I'm getting this warning _every_ _time_ I check a package that has a
manpage.
Is this a lintian bug? Should I report it on BTS?
BTW: I'm still looking for sponsor for gaupol (ITP bug #358189)
> automatically remove the shebang depending on who opens it?)
>
> You are right, but this makes me doubt even more whether having a
> non-executable file with a shebang line is a bug, because this
> information is also interesting for human beings.
>
> Regards, Frank
The lintian
;> problem of a "permission denied"?
>
> The confusion I refer to is not "how do I fix this?" but rather "why
> is there a mismatch, and what is the intended behaviour?" That there
> is a mismatch at all is the confusion.
Okay, so the rationale for the
"cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> wrote:
> On Friday 23 December 2005 10:24, Frank Küster wrote:
>
>> The fact that the script is not in the path isn't enough for you here?
>> And don't you think that anyone who knows that a shebang lines indicates
>> executability from the command
On Friday 23 December 2005 10:24, Frank Küster wrote:
> The fact that the script is not in the path isn't enough for you here?
> And don't you think that anyone who knows that a shebang lines indicates
> executability from the command line
shebang line does _not_ indicate executability, it's the
On 23-Dec-2005, Frank Küster wrote:
> Ben Finney <[EMAIL PROTECTED]> wrote:
> > A shebang line is more than documentation: it is a strong
> > indication that the script will be executable from the command
> > line. To have that expectation not be matched by the file's
> > permission mode is a recip
Ben Finney <[EMAIL PROTECTED]> wrote:
> On 22-Dec-2005, cobaco (aka Bart Cornelis) wrote:
>> On Wednesday 21 December 2005 18:41, Bas Wijnen wrote:
>> > If it is meant to be executed, it should be executable.
>> > If it is not, it should not have the shebang line.
>>
>> I disagree, there's not
On 22-Dec-2005, cobaco (aka Bart Cornelis) wrote:
> On Wednesday 21 December 2005 18:41, Bas Wijnen wrote:
> > If it is meant to be executed, it should be executable.
> > If it is not, it should not have the shebang line.
>
> I disagree, there's nothing wrong with clearly documenting what
> she
Hi lintian maintainers,
Thijs Kinkhorst <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-12-22 at 12:25 +0100, Bas Wijnen wrote:
>> Then it seems logical to me that an override would be in order. However, I
>> don't understand what the check is for, if not for cases like these. So my
>> logic may very
On Thu, 2005-12-22 at 12:25 +0100, Bas Wijnen wrote:
> Then it seems logical to me that an override would be in order. However, I
> don't understand what the check is for, if not for cases like these. So my
> logic may very well be incorrect.
Many tests document a short rationale in their descri
On Thu, Dec 22, 2005 at 10:21:46AM +0100, cobaco (aka Bart Cornelis) wrote:
> On Wednesday 21 December 2005 18:41, Bas Wijnen wrote:
> > If it is meant to be executed, it should be executable.
> agreed
>
> > If it is not, it should not have the shebang line.
>
> I disagree, there's nothing wro
On Wednesday 21 December 2005 18:41, Bas Wijnen wrote:
> On Wed, Dec 21, 2005 at 05:45:43PM +0100, Frank K?ster wrote:
> > It's of course clear that any script in the path should be executable.
> > But if a script is in /usr/share/somewhere, and meant to be used as a
> > "library", it could be that
o allow both to source and to execute it, then it
> is meant to be executed and thus should be executable IMO, even if the script
> is never executed from the Debian package (but only sourced).
If I make it executable, I would get the "executable-not-in-path"
lintian warning (or howeve
Re: Bas Wijnen in <[EMAIL PROTECTED]>
> I haven't seen anything in policy either, but I can't see any use for having a
> shebang line without execute permissions. Can you give an example?
Sometimes that's the easiest way to trick $EDITOR to get the syntax
hilighting right (and it's portable betwe
erefore I'd rather keep things as they are, but there must be a reason
> for the lintian warning. In the Policy section on permissions I
> couldn't find anything specific.
I haven't seen anything in policy either, but I can't see any use for having a
shebang line w
r keep things as they are, but there must be a reason
for the lintian warning. In the Policy section on permissions I
couldn't find anything specific.
TIA, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
libptp2-SONAMEVERSION
> >> as the library policy would suggest. May I override the lintian
> >> warning about this issue?
>> sonames go in the library package name so that different versions of
>> the library with the same name but different soversions are parallel-
>
gt;
> > but libptp2 is not intended to be the second version of libptp, it
> > is a different thing and so I (and the upstream author) think that
> > the package should be named libptp2 and not libptp2-SONAMEVERSION
> > as the library policy would suggest. May I override the li
o I (and the upstream author) think that the
> package should be named libptp2 and not libptp2-SONAMEVERSION as the
> library policy would suggest. May I override the lintian warning about
> this issue?
sonames go in the library package name so that different versions of the
library with the sa
named libptp2 and not libptp2-SONAMEVERSION as the
library policy would suggest. May I override the lintian warning about
this issue?
Here the source package details.
Package: libptp2
Description: a library to communicate with PTP devices (digicams or MP3
players) libptp2 is a library used to
Justin Pryzby <[EMAIL PROTECTED]> writes:
> On Thu, Sep 29, 2005 at 11:00:47PM -0400, kamaraju kusumanchi wrote:
>> Marc 'HE' Brockschmidt wrote:
You might consider using the -v 0.2.2.1 option in dh_make to
convert this to a compliant version number. The second -1 will still be
th
On Thu, Sep 29, 2005 at 10:42:44PM -0500, Carlo Segre wrote:
> On Thu, 29 Sep 2005, Justin Pryzby wrote:
>
> >On Thu, Sep 29, 2005 at 11:00:47PM -0400, kamaraju kusumanchi wrote:
> >>Marc 'HE' Brockschmidt wrote:
> You might consider using the -v 0.2.2.1 option in dh_make to
> convert this
On Thu, 29 Sep 2005, Justin Pryzby wrote:
On Thu, Sep 29, 2005 at 11:00:47PM -0400, kamaraju kusumanchi wrote:
Marc 'HE' Brockschmidt wrote:
You might consider using the -v 0.2.2.1 option in dh_make to
convert this to a compliant version number. The second -1 will still be
there in the final
On Thu, Sep 29, 2005 at 11:00:47PM -0400, kamaraju kusumanchi wrote:
> Marc 'HE' Brockschmidt wrote:
> >>You might consider using the -v 0.2.2.1 option in dh_make to
> >>convert this to a compliant version number. The second -1 will still be
> >>there in the final package because that is the deb
Marc 'HE' Brockschmidt wrote:
You might consider using the -v 0.2.2.1 option in dh_make to
convert this to a compliant version number. The second -1 will still be
there in the final package because that is the debian revision. The cause
that lintian has suggested does not seem to be your cas
Carlo Segre <[EMAIL PROTECTED]> writes:
> On Thu, 29 Sep 2005, kamaraju kusumanchi wrote:
>> Q1) Where am I doing wrong? How can I get rid of this error?
>
> I think that this has to do with the -1 in the name of the original
> tarball.
No. Please read the Debian Policy: Only the part of the vers
On Wed, Sep 28, 2005 at 11:33:45PM -0500, Carlo Segre wrote:
> On Thu, 29 Sep 2005, kamaraju kusumanchi wrote:
> >Q2) should I create a symbolic link gnuplotfortran-0.2.2-1.orig.tar.gz
> >which points to gnuplotfortran-0.2.2-1.tar.gz before proceeding with
> >dpkg-buildpackage? I see that it is a
On Thu, 29 Sep 2005, kamaraju kusumanchi wrote:
Hi
I am new to packaging and I am trying to package gnuplotfortran whose
upstream is located at http://sourceforge.net/projects/gnuplotfortran . The
upstream source is called gnuplotfortran-0.2.2-1.tar.bz2 . I downloaded this
to /tmp .
Then I
On Thu, Sep 29, 2005 at 12:17:28AM -0400, kamaraju kusumanchi wrote:
> Hi
> I am new to packaging and I am trying to package gnuplotfortran whose
> upstream is located at http://sourceforge.net/projects/gnuplotfortran .
> The upstream source is called gnuplotfortran-0.2.2-1.tar.bz2 . I
> downl
1 - 100 of 176 matches
Mail list logo
