Re: lintian error due to arm64 and aarch64 mismatch on raspberry pi
On 2023-11-11 19:36 +0530, Shriram Ravindranathan wrote: > when I run dpkg --print-architecture it says arm64 but when I run the > command arch it says aarch64. > Am I doing something wrong here? how do I get it to build for aarch64? Just to clarify your confusion: arm64 is the debian (and kernel) name for the architecture aarch64 is the manufacturers/GNU-toolchain name for the architecture They are the same thing, just different nomenclatures. dpkg-architecture -aarm64 will show you the various names/features. amd64 has the same situation with 'amd64' and 'x86_64' None of this has anything to do with your actual lintian error, as you have worked out :-) Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: lintian error due to arm64 and aarch64 mismatch on raspberry pi
Thank you, that seems to have resolved it. I changed it to arch:any and multiarch:same. On 11/11/2023 20:10, Andrey Rakhmatullin wrote: On Sat, Nov 11, 2023 at 07:36:07PM +0530, Shriram Ravindranathan wrote: dpkg-deb: building package 'libmagicenum-dev' in '../libmagicenum-dev_0.9.3-1_all.deb'. [...] E: libmagicenum-dev: triplet-dir-and-architecture-mismatch is for arm64 instead of all [usr/lib/aarch64-linux-gnu/] So you are shipping files in /usr/lib inside an arch:all package. You need to change it to arch:any. OpenPGP_0xFC7E951A7BEF0836.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: lintian error due to arm64 and aarch64 mismatch on raspberry pi
On Sat, Nov 11, 2023 at 07:36:07PM +0530, Shriram Ravindranathan wrote: > dpkg-deb: building package 'libmagicenum-dev' in > '../libmagicenum-dev_0.9.3-1_all.deb'. [...] > E: libmagicenum-dev: triplet-dir-and-architecture-mismatch is for arm64 > instead of all [usr/lib/aarch64-linux-gnu/] So you are shipping files in /usr/lib inside an arch:all package. You need to change it to arch:any.
Re: lintian error due to arm64 and aarch64 mismatch on raspberry pi
Hi Shriram, debian/control file has a field "architecture". By default it's set to "any". Try setting it to "all" On November 11, 2023 7:46:05 PM GMT+05:30, Shriram Ravindranathan wrote: >I just realized that I misread the error message. My apologies. It seems to be >expecting all instead of arm64. So how might I build it for all? > >On 11/11/23 7:36 pm, Shriram Ravindranathan wrote: >> Dear Mentors, >> >> I am trying to build a multiarch package (ITP #1055706) for debian on a >> raspberry pi. The package builds fine, however, there is a lintian error >> like so: >> *Output from *debuild*:* >> dpkg-deb: building package 'libmagicenum-dev' in >> '../libmagicenum-dev_0.9.3-1_all.deb'. >> dpkg-genbuildinfo -O../magic-enum_0.9.3-1_arm64.buildinfo >> dpkg-genchanges -O../magic-enum_0.9.3-1_arm64.changes >> dpkg-genchanges: info: including full source code in upload >> dpkg-source --after-build . >> dpkg-buildpackage: info: full upload (original source is included) >> Now running lintian magic-enum_0.9.3-1_arm64.changes ... >> E: libmagicenum-dev: triplet-dir-and-architecture-mismatch is for arm64 >> instead of all [usr/lib/aarch64-linux-gnu/] >> Finished running lintian. >> >> *Output from *lintian -i -I --show-overrides*:* >> E: libmagicenum-dev: triplet-dir-and-architecture-mismatch is for arm64 >> instead of all [usr/lib/aarch64-linux-gnu/] >> N: >> N: This package contains a directory under /lib or /usr/lib which doesn't >> N: match the proper triplet for the binary package's architecture. This is >> N: very likely to be a mistake when indicating the underlying build system >> N: where the files should be installed. >> N: >> N: Please refer to File System Structure (Section 9.1.1) in the Debian >> Policy >> N: Manual for details. >> N: >> N: Visibility: error >> N: Show-Always: no >> N: Check: files/architecture >> >> when I run dpkg --print-architecture it says arm64 but when I run the >> command arch it says aarch64. >> Am I doing something wrong here? how do I get it to build for aarch64? > >-- >Shriram Ravindranathan >ters > signature.asc Description: PGP signature
Re: lintian error due to arm64 and aarch64 mismatch on raspberry pi
I just realized that I misread the error message. My apologies. It seems to be expecting all instead of arm64. So how might I build it for all? On 11/11/23 7:36 pm, Shriram Ravindranathan wrote: Dear Mentors, I am trying to build a multiarch package (ITP #1055706) for debian on a raspberry pi. The package builds fine, however, there is a lintian error like so: *Output from *debuild*:* dpkg-deb: building package 'libmagicenum-dev' in '../libmagicenum-dev_0.9.3-1_all.deb'. dpkg-genbuildinfo -O../magic-enum_0.9.3-1_arm64.buildinfo dpkg-genchanges -O../magic-enum_0.9.3-1_arm64.changes dpkg-genchanges: info: including full source code in upload dpkg-source --after-build . dpkg-buildpackage: info: full upload (original source is included) Now running lintian magic-enum_0.9.3-1_arm64.changes ... E: libmagicenum-dev: triplet-dir-and-architecture-mismatch is for arm64 instead of all [usr/lib/aarch64-linux-gnu/] Finished running lintian. *Output from *lintian -i -I --show-overrides*:* E: libmagicenum-dev: triplet-dir-and-architecture-mismatch is for arm64 instead of all [usr/lib/aarch64-linux-gnu/] N: N: This package contains a directory under /lib or /usr/lib which doesn't N: match the proper triplet for the binary package's architecture. This is N: very likely to be a mistake when indicating the underlying build system N: where the files should be installed. N: N: Please refer to File System Structure (Section 9.1.1) in the Debian Policy N: Manual for details. N: N: Visibility: error N: Show-Always: no N: Check: files/architecture when I run dpkg --print-architecture it says arm64 but when I run the command arch it says aarch64. Am I doing something wrong here? how do I get it to build for aarch64? -- Shriram Ravindranathan ters OpenPGP_0xFC7E951A7BEF0836.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
lintian error due to arm64 and aarch64 mismatch on raspberry pi
Dear Mentors, I am trying to build a multiarch package (ITP #1055706) for debian on a raspberry pi. The package builds fine, however, there is a lintian error like so: *Output from *debuild*:* dpkg-deb: building package 'libmagicenum-dev' in '../libmagicenum-dev_0.9.3-1_all.deb'. dpkg-genbuildinfo -O../magic-enum_0.9.3-1_arm64.buildinfo dpkg-genchanges -O../magic-enum_0.9.3-1_arm64.changes dpkg-genchanges: info: including full source code in upload dpkg-source --after-build . dpkg-buildpackage: info: full upload (original source is included) Now running lintian magic-enum_0.9.3-1_arm64.changes ... E: libmagicenum-dev: triplet-dir-and-architecture-mismatch is for arm64 instead of all [usr/lib/aarch64-linux-gnu/] Finished running lintian. *Output from *lintian -i -I --show-overrides*:* E: libmagicenum-dev: triplet-dir-and-architecture-mismatch is for arm64 instead of all [usr/lib/aarch64-linux-gnu/] N: N: This package contains a directory under /lib or /usr/lib which doesn't N: match the proper triplet for the binary package's architecture. This is N: very likely to be a mistake when indicating the underlying build system N: where the files should be installed. N: N: Please refer to File System Structure (Section 9.1.1) in the Debian Policy N: Manual for details. N: N: Visibility: error N: Show-Always: no N: Check: files/architecture when I run dpkg --print-architecture it says arm64 but when I run the command arch it says aarch64. Am I doing something wrong here? how do I get it to build for aarch64? OpenPGP_0xFC7E951A7BEF0836.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, Jul 10, 2023 at 05:11:39PM +0200, José Luis Blanco-Claraco wrote: > Thanks a lot, Andrey, for the time analyzing the problems here, and > for the clarifications. I thought libpython was like "libc" for > python... It is, but as extensions are loadable plugins, they are fine with symbols being provided by the executable instead of linking a library. If you check you will see that Py* symbols in the extensions are unresolved and that /usr/bin/python3 exports them. > So the main issue seems to be dh_python3 not recognizing the package > as "python"... > I attach the list of files and directories of the latest package > version just in case it's easy to spot problems from it (the > "__pycache__" are there for a test Ubuntu build, but are not in the > Debian build). TBH I don't think it's about the file list (though it's possible). > Note that I want to ship: > - A cpython .so module + its .pyi stubs. > - The corresponding py.typed file, which I understand is > recommended/mandatory when shipping .pyi stubs. > - Pure python scripts (right now, only "ros_bridge.py"). > > At present, I put everything under > "/usr/lib/python3/dist-packages/mrpt/" so everything is together, not > "polluting" the "dist-packages" directory. I don't think this makes sense. You should put them wherever the upstream puts them so that the module can be imported (and scripts can be run) in the way that is documented and expected by users. > Maybe the package should be named "python3-mrpt" instead? It should always be named for its top-level importable module, see https://www.debian.org/doc/packaging-manuals/python-policy/index.html#module-package-names > Any way to test dh_python3 manually? Perhaps just build the package > locally and run dh_python3 from the pkg root directory? Yes. And you should run it in the verbose mode.
Re: Help with Lintian error in python3 (pybind11-wrapped) package
Thanks a lot, Andrey, for the time analyzing the problems here, and
for the clarifications. I thought libpython was like "libc" for
python...
So the main issue seems to be dh_python3 not recognizing the package
as "python"...
I attach the list of files and directories of the latest package
version just in case it's easy to spot problems from it (the
"__pycache__" are there for a test Ubuntu build, but are not in the
Debian build).
Note that I want to ship:
- A cpython .so module + its .pyi stubs.
- The corresponding py.typed file, which I understand is
recommended/mandatory when shipping .pyi stubs.
- Pure python scripts (right now, only "ros_bridge.py").
At present, I put everything under
"/usr/lib/python3/dist-packages/mrpt/" so everything is together, not
"polluting" the "dist-packages" directory.
Maybe the package should be named "python3-mrpt" instead?
Any way to test dh_python3 manually? Perhaps just build the package
locally and run dh_python3 from the pkg root directory?
Best,
JL
On Mon, Jul 10, 2023 at 2:58 PM Andrey Rakhmatullin wrote:
>
> On Mon, Jul 10, 2023 at 11:22:05AM +0200, José Luis Blanco-Claraco wrote:
> > On Mon, Jul 10, 2023 at 11:09 AM Andrey Rakhmatullin wrote:
> > > No, as it says "phyton3".
> > > (I would also expect that using appropriate substvars here is better than
> > > writing deps manually)
> >
> > I know, and added ${python3:Depends} and ${shlibs:Depends}, but
> > "dh-python" seems not to add any substvars, and "shlibs" does neither.
> shlibs:Depends is indeed irrelevant here.
> python3:Depends being empty is a problem that needs to be fixed. I've
> built the package and it lacks postinst/prerm so I guess dh_python3 didn't
> find any modules in the package. I also see that the package is named
> python3-pymrpt while the top-level module is named myrpt, though I don't
> know if this can cause any problems beside the autopkgtest not working.
>
> > In fact, the "so" module built from the pybind11 wrapper seems not to
> > list any python library in "ldd", which also puzzled me:
> >
> > ldd mrpt/pymrpt.cpython-310-x86_64-linux-gnu.so | grep py
> > libsnappy.so.1 => /lib/x86_64-linux-gnu/libsnappy.so.1
> > (0x7facb732d000)
> Python extensions indeed don't need to link libpython, which is (mostly?)
> for embedding the interpreter, as extensions are loaded into an
> interpreter themselves.
>
> > I checked that other "*cpython.so" modules out there indeed list
> > "libpython3.xxx.so" in their "ldd".
> (I've checked two random extensiopns and they don't)
>
> > I understand this is what is preventing "shlibs" to automatically list
> > python3 as a substvar, but don't know how to fix it.
> It's not, and shlibs:Depends won't list python3 anyway.
>
--
/**
* Jose Luis Blanco-Claraco
* Universidad de Almería - Departamento de Ingeniería
* [Homepage]( https://w3.ual.es/~jlblanco/ )
* [GH profile]( https://github.com/jlblancoc )
*/
python3-pymrpt_2.10.1~20230709-1304-git-1ea114bb~lunar-1_amd64.deb
--
new Debian package, version 2.0.
size 5599708 bytes: control archive=2659 bytes.
2601 bytes,17 lines control
6102 bytes,64 lines md5sums
Package: python3-pymrpt
Source: mrpt
Version: 1:2.10.1~20230709-1304-git-1ea114bb~lunar-1
Architecture: amd64
Maintainer: Jose Luis Blanco Claraco
Installed-Size: 28338
Depends: libc6 (>= 2.34), libgcc-s1 (>= 3.3.1), libmrpt-apps2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-bayes2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-comms2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-config2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-containers2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-core2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-expr2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-graphs2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-gui2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-hwdrivers2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-img2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-io2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-kinematics2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-maps2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-math2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-nanogui2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-nav2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-obs2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-opengl2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-poses2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-random2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-rtti2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-serialization2.9 (>=
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, Jul 10, 2023 at 11:22:05AM +0200, José Luis Blanco-Claraco wrote:
> On Mon, Jul 10, 2023 at 11:09 AM Andrey Rakhmatullin wrote:
> > No, as it says "phyton3".
> > (I would also expect that using appropriate substvars here is better than
> > writing deps manually)
>
> I know, and added ${python3:Depends} and ${shlibs:Depends}, but
> "dh-python" seems not to add any substvars, and "shlibs" does neither.
shlibs:Depends is indeed irrelevant here.
python3:Depends being empty is a problem that needs to be fixed. I've
built the package and it lacks postinst/prerm so I guess dh_python3 didn't
find any modules in the package. I also see that the package is named
python3-pymrpt while the top-level module is named myrpt, though I don't
know if this can cause any problems beside the autopkgtest not working.
> In fact, the "so" module built from the pybind11 wrapper seems not to
> list any python library in "ldd", which also puzzled me:
>
> ldd mrpt/pymrpt.cpython-310-x86_64-linux-gnu.so | grep py
> libsnappy.so.1 => /lib/x86_64-linux-gnu/libsnappy.so.1 (0x7facb732d000)
Python extensions indeed don't need to link libpython, which is (mostly?)
for embedding the interpreter, as extensions are loaded into an
interpreter themselves.
> I checked that other "*cpython.so" modules out there indeed list
> "libpython3.xxx.so" in their "ldd".
(I've checked two random extensiopns and they don't)
> I understand this is what is preventing "shlibs" to automatically list
> python3 as a substvar, but don't know how to fix it.
It's not, and shlibs:Depends won't list python3 anyway.
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, 10 Jul 2023 01:19:38 -0700, JOSE LUIS BLANCO CLARACO wrote: > I attach the output of "dpkg -I" for the final binary package, where > the "Depends: python3" is visible, Copied from the attached file: Depends: phyton3 phyton3 != python3 :) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- BOFH excuse #193: Did you pay the new Support Fee?
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, Jul 10, 2023 at 11:09 AM Andrey Rakhmatullin wrote:
> No, as it says "phyton3".
> (I would also expect that using appropriate substvars here is better than
> writing deps manually)
I know, and added ${python3:Depends} and ${shlibs:Depends}, but
"dh-python" seems not to add any substvars, and "shlibs" does neither.
In fact, the "so" module built from the pybind11 wrapper seems not to
list any python library in "ldd", which also puzzled me:
ldd mrpt/pymrpt.cpython-310-x86_64-linux-gnu.so | grep py
libsnappy.so.1 => /lib/x86_64-linux-gnu/libsnappy.so.1 (0x7facb732d000)
but the module loads perfectly from python3 scripts/interpreter, etc.
I checked that other "*cpython.so" modules out there indeed list
"libpython3.xxx.so" in their "ldd".
I understand this is what is preventing "shlibs" to automatically list
python3 as a substvar, but don't know how to fix it.
This is my first python3 package, so I don't feel confident about how
things should work.
Neither found an equivalent pybind11-based wrapper packaged in Debian
for reference, so any further pointers would be appreciated!.
JL
--
/**
* Jose Luis Blanco-Claraco
* Universidad de Almería - Departamento de Ingeniería
* [Homepage]( https://w3.ual.es/~jlblanco/ )
* [GH profile]( https://github.com/jlblancoc )
*/
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, Jul 10, 2023 at 11:02 AM gregor herrmann wrote: > phyton3 != python3 > :) hahaha, I knew more eyeballs would be helpful! Thanks a lot, Gregor, that solves the mystery :-)
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, Jul 10, 2023 at 01:19:38AM -0700, JOSE LUIS BLANCO CLARACO wrote: > [2]. I attach the output of "dpkg -I" for the final binary package, where > the "Depends: python3" is visible No, as it says "phyton3". (I would also expect that using appropriate substvars here is better than writing deps manually)
Help with Lintian error in python3 (pybind11-wrapped) package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, I'm adding a new python3 package as part of a larger C++ package [1], which builds using a rather standard dh + cmake procedure, then builds a python3 package from a pybind11 wrapper. The problem I have found is that lintian keeps complaining about: E: python3-pymrpt: python-package-missing-depends-on-python Finished running lintian. despite the package has "python3" explicitly written by hand in d/control [2]. I attach the output of "dpkg -I" for the final binary package, where the "Depends: python3" is visible, so I don't know if this is a lintian false positive or I'm missing something... hopefully you can help me out with this! :-) Also, any help looking at the d/control section for the new python3 package in [2] to spot any possible problem would be appreciated! Cheers, JL [1] https://salsa.debian.org/robotics-team/mrpt [2] https://salsa.debian.org/robotics-team/mrpt/-/blob/master/debian/control#L956-964 - -- /** * Jose Luis Blanco-Claraco * Universidad de Almería - Departamento de Ingeniería * [Homepage]( https://w3.ual.es/~jlblanco/ ) * [GH profile]( https://github.com/jlblancoc ) */ -BEGIN PGP SIGNATURE- Version: FlowCrypt Email Encryption 8.4.8 Comment: Seamlessly send and receive encrypted email wsFzBAEBCgAnBYJkq78aCZDUQzBPvXCmQRYhBHf2neQjGKO3Aa2EZNRDME+9 cKZBAACZsQ/+MQw0KdbHGhDWmAe9BG9ecdAtmYZLfWNlmw+WMjlEPpN+cZ7T NcspxH/J3qhmQ8z9V/xPnfU4nfoXJj2ua7kmHJTwye51VF0LGlpDJFldRTVv 8QFK/AcvqOu23/vIhf/y6EyhMk5e0ASNsl02cIcJjpWz72RHjUyA68QHz0fs nlIcyFGoeueIZJduVdzLgQwN4qz8IE+nD8zOMzWujUycFjiQLjq9/fSRD0kw a2VRjth+1auwz0rMu28YU7GEgK1SMi2PNESJVTmfFUMCDCSNHRW7205IcHpb kFAP/n56xPj54nqOive7tHPAzKGF7ihhYAspzTXKF92eR02PuU6EXqAmr6tz P36+PU1b+GCzmrBtb0HN9+rrbA+gL5M8r1xitEq6iIvda+4UonNEbPj3hBQy e2ssa4i/i1NH2ZEHXteQRFBPBZ079f//1/5RhPbGzuKMSjC83gzcfzUZ303R LLh0C5GuqCdBT56OfPfDPGET06MOTdgkAqPqfKK/w+6JN8EBEBtot4veLhQy 4TjxScsCTXo44yQcE13WnC6ZBMRUOee337OTAtmztf1CsvTn5fmLJ0Jkylkc DJZD2YOHS7zVWjSGygoFgEyOPLVtNCRozspQjldElRjOhROweotgWchzFXDT tK0aBovseoa48bVBcfrOSQ+NyLsqyhubcuY= =1opa -END PGP SIGNATURE- dpkg -I python3-pymrpt_2.10.0+ds-1_amd64.deb new Debian package, version 2.0. size 4967520 bytes: control archive=2604 bytes. 1763 bytes,18 lines control 5888 bytes,62 lines md5sums Package: python3-pymrpt Source: mrpt Version: 1:2.10.0+ds-1 Architecture: amd64 Maintainer: Jose Luis Blanco Claraco Installed-Size: 27772 Depends: phyton3, libc6 (>= 2.34), libgcc-s1 (>= 3.3.1), libmrpt-apps2.10 (>= 1:2.10.0+ds), libmrpt-bayes2.10 (>= 1:2.10.0+ds), libmrpt-comms2.10 (>= 1:2.10.0+ds), libmrpt-config2.10 (>= 1:2.10.0+ds), libmrpt-containers2.10 (>= 1:2.10.0+ds), libmrpt-core2.10 (>= 1:2.10.0+ds), libmrpt-expr2.10 (>= 1:2.10.0+ds), libmrpt-graphs2.10 (>= 1:2.10.0+ds), libmrpt-gui2.10 (>= 1:2.10.0+ds), libmrpt-hwdrivers2.10 (>= 1:2.10.0+ds), libmrpt-img2.10 (>= 1:2.10.0+ds), libmrpt-io2.10 (>= 1:2.10.0+ds), libmrpt-kinematics2.10 (>= 1:2.10.0+ds), libmrpt-maps2.10 (>= 1:2.10.0+ds), libmrpt-math2.10 (>= 1:2.10.0+ds), libmrpt-nanogui2.10 (>= 1:2.10.0+ds), libmrpt-nav2.10 (>= 1:2.10.0+ds), libmrpt-obs2.10 (>= 1:2.10.0+ds), libmrpt-opengl2.10 (>= 1:2.10.0+ds), libmrpt-poses2.10 (>= 1:2.10.0+ds), libmrpt-random2.10 (>= 1:2.10.0+ds), libmrpt-rtti2.10 (>= 1:2.10.0+ds), libmrpt-serialization2.10 (>= 1:2.10.0+ds), libmrpt-slam2.10 (>= 1:2.10.0+ds), libmrpt-system2.10 (>= 1:2.10.0+ds), libmrpt-tfest2.10 (>= 1:2.10.0+ds), libmrpt-topography2.10 (>= 1:2.10.0+ds), libmrpt-vision2.10 (>= 1:2.10.0+ds), libstdc++6 (>= 11) Section: python Priority: optional Multi-Arch: same Homepage: https://www.mrpt.org/ Description: Python wrapper for MRPT The Mobile Robot Programming Toolkit (MRPT) is an extensive, cross-platform, and open source C++ library aimed to help robotics researchers to design and implement algorithms in the fields of Simultaneous Localization and Mapping (SLAM), computer vision, and motion planning (obstacle avoidance). . This package contains a Python 3 wrapper for the C++ MRPT libraries. 0xD443304FBD70A641.asc Description: application/pgp-keys
libhx lintian error "no-code-sections"
Hello, I have a problem with the lintian error "no-code-sections" in the package libhx. No matter if I set the parameters export DEB_CFLAGS_MAINT_APPEND = -flto=auto -ffat-lto-objects or not the error message remains. Can someone look over this? The readelf output see at [1][2]. Thanks in advance! CU Jörg [1] https://paste.debian.net/1268873 [2] https://paste.debian.net/1268874 -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype: joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Lintian error about a simple program
L.S. I have a simple program, created by an official Debian tool (fasm). If I put it into a debian archive I get (among others complaints) E: lina: unstripped-binary-or-object usr/bin/lina I'm perfectly willing to strip lina ~/PROJECT/ciforths/ciforth$ strip lina strip: error: the input file 'lina' has no sections ~/PROJECT/ciforths/ciforth$ echo $? 1 So strip refuses to work, moreover it gives an error, possibly indicative of more problems. I can find a flag to give to strip to suppress the error condition it gives back. My personal opinion is that lintian should check on superfluous information, such as debugging symbols. The absence of sections should exonerate a program from containing superfluous information. Groetjes Albert
lintian error "no-code-section"
Hello,on my package libHX[1] I get always the lintian error: E: libhx-dev: no-code-sections [usr/lib/x86_64-linux-gnu/libHX_rtcheck.a] 1. As described in bug #977596 [2], export DEB_CFLAGS_MAINT_APPEND = -flto=auto -ffat-lto-objects was included. This did not result in any change in size. For both versions readelf -W --section-headers libHX.a also showed no differences. (See attachment) Can someone please check if this is a bug or a false positive? Many thanks! CU Jörg [1] https://jff.email/cgit/libhx.git?h=develop[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977596 -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype: joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. # # with export DEB_CFLAGS_MAINT_APPEND = -flto=auto -ffat-lto-objects # # File: libHX.a(deque.o) There are 11 section headers, starting at offset 0xac8: Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 40 0003c9 00 AX 0 0 16 [ 2] .rela.textRELA 000820 000138 18 I 8 1 8 [ 3] .data PROGBITS 000409 00 00 WA 0 0 1 [ 4] .bss NOBITS 000409 00 00 WA 0 0 1 [ 5] .note.GNU-stack PROGBITS 000409 00 00 0 0 1 [ 6] .eh_frame PROGBITS 000410 0001c0 00 A 0 0 8 [ 7] .rela.eh_frameRELA 000958 000120 18 I 8 6 8 [ 8] .symtab SYMTAB 0005d0 000198 18 9 2 8 [ 9] .strtab STRTAB 000768 b3 00 0 0 1 [10] .shstrtab STRTAB 000a78 50 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), D (mbind), l (large), p (processor specific) File: libHX.a(dl.o) There are 11 section headers, starting at offset 0x310: Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 40 35 00 AX 0 0 16 [ 2] .rela.textRELA 000200 60 18 I 8 1 8 [ 3] .data PROGBITS 75 00 00 WA 0 0 1 [ 4] .bss NOBITS 75 00 00 WA 0 0 1 [ 5] .note.GNU-stack PROGBITS 75 00 00 0 0 1 [ 6] .eh_frame PROGBITS 78 68 00 A 0 0 8 [ 7] .rela.eh_frameRELA 000260 60 18 I 8 6 8 [ 8] .symtab SYMTAB e0 f0 18 9 2 8 [ 9] .strtab STRTAB 0001d0 2a 00 0 0 1 [10] .shstrtab STRTAB 0002c0 50 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), D (mbind), l (large), p (processor specific) File: libHX.a(format.o) There are 17 section headers, starting at offset 0x4328: Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 40 0011a3 00 AX 0 0 16 [ 2] .rela.textRELA 0027a8 001248 18 I 14 1 8 [ 3] .data PROGBITS 0011e3 00 00 WA 0 0 1 [ 4] .bss NOBITS 0011e3 01 00 WA 0 0 1 [ 5] .rodata.str1.8PROGBITS 0011e8 ff 01 AMS 0 0 8 [ 6] .rodata.str1.1PROGBITS 0012e7 bc 01 AMS 0 0 1 [ 7] .rodata PROGBITS 0013b0 000115 00 A 0 0 16 [ 8] .rela.rodata RELA 0039f0
Re: How to suppress "source-is-missing" lintian error?
On Thursday, August 13 2020, Ángel wrote: > On 2020-08-13 at 12:47 -0700, A. Lewenberg wrote: >> I am trying to suppress some lintian errors in my package build. I see >> this error when running lintian: >> -- >> E: stanford-spdb source: source-is-missing >> usr/share/spdb/vendor/assets/javascripts/bootstrap-4.4.1.min.js >> (...) >> How do I get lintian to be quiet about this? > > Add a depends on libjs-bootstrap and remove this minified file from your > package? This is the right way to go, except that he will want libjs-bootstrap4 instead, based on the lintian error. If you have other JavaScript dependencies that are not package yet, you need to either (a) package them (this is the preferred way, but not always feasible), or (b) remove any minified JS and regenerate them. For (b), you will need to tweak d/copyright's Excluded-Files directive and remove the *.min.js (note that you may also need to remove the *.min.css files) that are not package in Debian, and then use yui-compressor to generate them from the unminified files that should be present in the source package. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
Re: How to suppress "source-is-missing" lintian error?
On Thu, Aug 13, 2020 at 12:47:16PM -0700, A. Lewenberg wrote: > I am trying to suppress some lintian errors in my package build. I see this > error when running lintian: > -- > E: stanford-spdb source: source-is-missing > usr/share/spdb/vendor/assets/javascripts/bootstrap-4.4.1.min.js > -- This is a valid error, please don't suppress it. -- WBR, wRAR signature.asc Description: PGP signature
Re: How to suppress "source-is-missing" lintian error?
On 2020-08-13 at 12:47 -0700, A. Lewenberg wrote: > I am trying to suppress some lintian errors in my package build. I see > this error when running lintian: > -- > E: stanford-spdb source: source-is-missing > usr/share/spdb/vendor/assets/javascripts/bootstrap-4.4.1.min.js > (...) > How do I get lintian to be quiet about this? Add a depends on libjs-bootstrap and remove this minified file from your package?
Re: How to suppress "source-is-missing" lintian error?
Hi A. Lewenberg, Em qui., 13 de ago. de 2020 às 17:49, A. Lewenberg escreveu: > > I am trying to suppress some lintian errors in my package build. I see > this error when running lintian: > -- > E: stanford-spdb source: source-is-missing > usr/share/spdb/vendor/assets/javascripts/bootstrap-4.4.1.min.js > -- > > I attempt to override this by adding to debian/lintian-overrides the line > -- > stanford-spdb source: source-is-missing > usr/share/spdb/vendor/assets/javascripts/bootstrap-4.4.1.min.js I will consider that you know what you are doing overriding this lintian. This lintian is for a source, not for a binary. See: E: stanford-spdb source: < So you need to create an override at debian/source/lintian-overrides, not in debian/lintian-overrides. Regards, Eriberto
How to suppress "source-is-missing" lintian error?
I am trying to suppress some lintian errors in my package build. I see this error when running lintian: -- E: stanford-spdb source: source-is-missing usr/share/spdb/vendor/assets/javascripts/bootstrap-4.4.1.min.js -- I attempt to override this by adding to debian/lintian-overrides the line -- stanford-spdb source: source-is-missing usr/share/spdb/vendor/assets/javascripts/bootstrap-4.4.1.min.js -- I rebuild and run lintian again, but then I see this error: -- E: stanford-spdb: malformed-override Override of source-is-missing for package type source (expecting binary) -- So I try changing the line in lintian-overrides to -- stanford-spdb binary: source-is-missing usr/share/spdb/vendor/assets/javascripts/bootstrap-4.4.1.min.js -- Rebuilding the pcakge and running lintian now results in the error -- E: stanford-spdb source: source-is-missing usr/share/spdb/vendor/assets/javascripts/bootstrap-4.4.1.min.js -- Also, the line gets flagged as an unused override. How do I get lintian to be quiet about this?
Re: [Debian-med-packaging] Problem with lintian error symbols-file-contains-current-version-with-debian-revision
Hi Andreas, On 05/23/2018 12:11 PM, Andreas Tille wrote: > Hi, > > I've created a symbols file for libseqlib version 1.1.1+dfsg since I > suspected an ABI change by upstream. A test build with this symbols > file went fine without lintian errors. I upgraded to libseqlib version > 1.1.2 which in fact had an ABI change[2]. I have upgraded the symbols > file accordingly[3]. When I build this package I get: > > E: libseqlib1: symbols-file-contains-current-version-with-debian-revision on > symbol > _ZN12aho_corasick10basic_trieIcE10parse_textENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base > and 433 others > I wonder whether I'm missing something but this smeels like a wrong > lintian warning to me since the Debian revision "-1" was stripped from > the diff. To be sure to not create noise for lintian in BTS I'd like > to have a second pair of eyeballs on this symbols file. I guess you also need to bump the library version in the first line of symbols file: s/libseqlib.so.0/libseqlib.so.1/ Best regards, Alex
Problem with lintian error symbols-file-contains-current-version-with-debian-revision
Hi, I've created a symbols file for libseqlib version 1.1.1+dfsg since I suspected an ABI change by upstream. A test build with this symbols file went fine without lintian errors. I upgraded to libseqlib version 1.1.2 which in fact had an ABI change[2]. I have upgraded the symbols file accordingly[3]. When I build this package I get: E: libseqlib1: symbols-file-contains-current-version-with-debian-revision on symbol _ZN12aho_corasick10basic_trieIcE10parse_textENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base and 433 others N: N:Debian revisions should be stripped from versions in symbols files. Not N:doing so leads to dependencies unsatisfiable by backports (1.0-1~bpo << N:1.0-1 while 1.0-1~bpo >= 1.0). If the Debian revision can't be stripped N:because the symbol really appeared between two specific Debian N:revisions, you should postfix the version with a single "~" (example: N:1.0-3~ if the symbol appeared in 1.0-3). N: N:This problem normally means that the symbols were added automatically by N:dpkg-gensymbols. dpkg-gensymbols uses the full version number for the N:dependency associated to any new symbol that it detects. The maintainer N:must update the debian/.symbols file by adding the new symbols N:with the corresponding upstream version. N: N:Severity: important, Certainty: certain N: N:Check: shared-libs, Type: binary, udeb N: I wonder whether I'm missing something but this smeels like a wrong lintian warning to me since the Debian revision "-1" was stripped from the diff. To be sure to not create noise for lintian in BTS I'd like to have a second pair of eyeballs on this symbols file. Kind regards Andreas. [1] https://salsa.debian.org/med-team/libseqlib/blob/23e6ae31d0155b6b5011aabdc3944b695ed79986/debian/libseqlib0.symbols [2] https://github.com/walaj/SeqLib/issues/24 [3] https://salsa.debian.org/med-team/libseqlib/commit/b8991175a61613622bf9776a296967740db74057 -- http://fam-tille.de
Re: useless lintian error?
Hi, >It doesn't look closed to me. Indeed, the bug was pending and then excluded from the list in BTS https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=doona=no=pending-fixed=fixed=done=critical=grave=serious=no this is why I didn't see it. thanks! G.
Re: useless lintian error?
On 28/09/16 10:55, Gianfranco Costamagna wrote: > Hi mentors, > I did a doona upload, with "closes #foo" in changelog, getting > a lintian error: > > E possible-missing-colon-in-closes > closes #838630 > > since the bug is closed It doesn't look closed to me. > because the system closes bugs even without the colon, isn't this time to drop > that error? The uses 'Closes:' with a colon to close bugs is required by Policy (section 4.4). James signature.asc Description: OpenPGP digital signature
useless lintian error?
Hi mentors, I did a doona upload, with "closes #foo" in changelog, getting a lintian error: E possible-missing-colon-in-closes closes #838630 since the bug is closed, because the system closes bugs even without the colon, isn't this time to drop that error? I'm not sure why something that works might need fixing... thanks, G.
Re: Lintian error for package with Apache2 module
Den 10. mars 2014 21:56, skrev Russ Allbery: 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 . Yes, you won't be able to find this in wheezy since it's part of the changes for Apache 2.4 support. You need to look at packages in unstable or testing. wheezy was still Apache 2.2, and the Apache packaging for wheezy is substantially different than Apache packaging for jessie and newer releases. Thanks I think I've done this correctly now by the package depend on apache2-api-20120211 and building it on unstable. Can anyone help me check if its done correctly? Regards Atle. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5322f350.1010...@goliathdns.no
Lintian error for package with Apache2 module
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 apache2-api-* provided by apache2.2-bin (i think). I have been looking in other packages to find out how to do this, but with no luck. I've got apache2.2-bin version 2.2.22-13 installed on the system I build on. I have found this virtual package in other distros, but I can't find it in wheezy. Any ideas on how to solve this? Regards Atle Solbakken
Re: Lintian error for package with Apache2 module
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 package depend on a virtual package called apache2-api-* provided by apache2.2-bin (i think). I have been looking in other packages to find out how to do this, but with no luck. I've got apache2.2-bin version 2.2.22-13 installed on the system I build on. Look at, for example, the webauth source package in unstable or testing. I have found this virtual package in other distros, but I can't find it in wheezy. Yes, you won't be able to find this in wheezy since it's part of the changes for Apache 2.4 support. You need to look at packages in unstable or testing. wheezy was still Apache 2.2, and the Apache packaging for wheezy is substantially different than Apache packaging for jessie and newer releases. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k3c1ydqu@windlord.stanford.edu
RE: FGRun Lintian Error
On Mon, 2010-07-26 at 19:01 +1000, Matthew Palmer wrote: On Mon, Jul 26, 2010 at 09:31:10AM +0100, Chris Baines wrote: Hello mentors, I am getting a package-section-games-but-contains-no-game lintian error on my package fgrun. FGRun is a FLightGear graphical launcher, FlightGear is a flight simulator game. FGRun puts its binary in the /usr/bin directory. FGRun is not a game, however it depends on FlightGear and its only current purpose is to configure and launch FlightGear which is a game. Should I just ignore the error or place the binary in the games /usr/share/games directory or change the section of the package to something else? I would be inclined to move it into /usr/games; whilst it may not be a game itself, per se, it's certainly more game than anything else. - Matt How would you go about doing this? Would you patch the makefile or add something in to the debian/rules file. My rules file is pretty basic at the moment and just consists of: %: dh $@ (Sorry Mat) Chris -- 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/1280231173.19625.0.ca...@chris-debian-desktop
Re: FGRun Lintian Error
On Tue, Jul 27, 2010 at 7:46 AM, Chris Baines cbain...@gmail.com wrote: How would you go about doing this? Would you patch the makefile or add something in to the debian/rules file. My rules file is pretty basic at the moment and just consists of: %: dh $@ chromium-bsu debian/rules: %: dh --with autotools_dev $@ --parallel override_dh_auto_configure: dh_auto_configure -- CXXFLAGS=$(CXXFLAGS) -Wall --bindir=/usr/games --datadir=/usr/share/games If your upstream is not using autotools then this probably won't work. BTW, if you are interested in joining the Debian games team we need more folk. -- 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/aanlktimnj+oxk1auxmujqrgwd5zcg8ogs8hbzv9at...@mail.gmail.com
Re: FGRun Lintian Error
On Tue, 2010-07-27 at 07:53 -0400, Paul Wise wrote: On Tue, Jul 27, 2010 at 7:46 AM, Chris Baines cbain...@gmail.com wrote: How would you go about doing this? Would you patch the makefile or add something in to the debian/rules file. My rules file is pretty basic at the moment and just consists of: %: dh $@ chromium-bsu debian/rules: %: dh --with autotools_dev $@ --parallel override_dh_auto_configure: dh_auto_configure -- CXXFLAGS=$(CXXFLAGS) -Wall --bindir=/usr/games --datadir=/usr/share/games If your upstream is not using autotools then this probably won't work. BTW, if you are interested in joining the Debian games team we need more folk. -- bye, pabs http://wiki.debian.org/PaulWise Thanks Paul, that was the final fix I needed. I have now uploaded my package to the mentors site. However it wont be available in Debian until simgear is upgraded and unfortunately I don't think that will happen until I get around to it! The games team sounds interesting, I have just joined the mailing list. Thanks again, Chris -- 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/1280257694.24766.6.ca...@chris-debian-desktop
FGRun Lintian Error
Hello mentors, I am getting a package-section-games-but-contains-no-game lintian error on my package fgrun. FGRun is a FLightGear graphical launcher, FlightGear is a flight simulator game. FGRun puts its binary in the /usr/bin directory. FGRun is not a game, however it depends on FlightGear and its only current purpose is to configure and launch FlightGear which is a game. Should I just ignore the error or place the binary in the games /usr/share/games directory or change the section of the package to something else? Thanks, Chris -- 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/1280133070.3087.12.ca...@chris-debian-desktop
Re: FGRun Lintian Error
On Mon, Jul 26, 2010 at 09:31:10AM +0100, Chris Baines wrote: Hello mentors, I am getting a package-section-games-but-contains-no-game lintian error on my package fgrun. FGRun is a FLightGear graphical launcher, FlightGear is a flight simulator game. FGRun puts its binary in the /usr/bin directory. FGRun is not a game, however it depends on FlightGear and its only current purpose is to configure and launch FlightGear which is a game. Should I just ignore the error or place the binary in the games /usr/share/games directory or change the section of the package to something else? I would be inclined to move it into /usr/games; whilst it may not be a game itself, per se, it's certainly more game than anything else. - Matt -- 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/20100726090124.gb19...@hezmatt.org
Re: lintian error on my package dhcp-probe
On Mon, 15 Mar 2010 21:06:29 +0100, Patrick Matthäi wrote: Am 15.03.2010 21:04, schrieb Laurent Guignard: Hi mentors, I have this error during a lintian check : I: dhcp-probe: spelling-error-in-manpage usr/share/man/man8/dhcp_probe.8.gz overriden overridden ... I have problem to interpret this message. I think it is a problem on the overridden word but i don't see where the spelling error. lintian lists the first word as the wrong one and the second as the right spelled one. So just search in the manpage for overriden and replace it with overridden. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Thank you for all your answers. I'll patch the manpage and forward the patch to the upstream programmer. Regards. -- Laurent Guignard, Registered as user #301590 with the Linux Counter Site : http://www.famille-guignard.org Blog : http://blog.famille-guignard.org Projet : http://sicontact.sourceforge.net GULL de Villefranche sur Saône : http://www.cagull.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/20100316192756.ga3...@portable.home.famille-guignard.org
lintian error on my package dhcp-probe
Hi mentors, I have this error during a lintian check : I: dhcp-probe: spelling-error-in-manpage usr/share/man/man8/dhcp_probe.8.gz overriden overridden N: N:Lintian found a spelling error in the manpage. Lintian has a list of N:common misspellings that it looks for. It does not have a dictionary N:like a spelling checker does. N: N:If the string containing the spelling error is translated with the help N:of gettext (with the help of po4a, for example) or a similar tool, N:please fix the error in the translations as well as the English text to N:avoid making the translations fuzzy. With gettext, for example, this N:means you should also fix the spelling mistake in the corresponding N:msgids in the *.po files. N: N:Severity: minor, Certainty: possible N: I: dhcp-probe: spelling-error-in-manpage usr/share/man/man8/dhcp_probe.8.gz overriden overridden I have problem to interpret this message. I think it is a problem on the overridden word but i don't see where the spelling error. Thank you for any help. Best regards. -- Laurent Guignard, Registered as user #301590 with the Linux Counter Site : http://www.famille-guignard.org Blog : http://blog.famille-guignard.org Projet : http://sicontact.sourceforge.net GULL de Villefranche sur Saône : http://www.cagull.org signature.asc Description: Digital signature
Re: lintian error on my package dhcp-probe
Am 15.03.2010 21:04, schrieb Laurent Guignard: Hi mentors, I have this error during a lintian check : I: dhcp-probe: spelling-error-in-manpage usr/share/man/man8/dhcp_probe.8.gz overriden overridden ... I have problem to interpret this message. I think it is a problem on the overridden word but i don't see where the spelling error. lintian lists the first word as the wrong one and the second as the right spelled one. So just search in the manpage for overriden and replace it with overridden. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -- 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/4b9e9345.6030...@debian.org
Re: lintian error on my package dhcp-probe
On Mon, Mar 15, 2010 at 09:04:22PM +0100, Laurent Guignard wrote: I: dhcp-probe: spelling-error-in-manpage usr/share/man/man8/dhcp_probe.8.gz overriden overridden I have problem to interpret this message. I think it is a problem on the overridden word but i don't see where the spelling error. Can you please upload the source of the manpage, for example to paste.debian.net? Thanks -- Jonathan Wiltshire 1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -- 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/20100315200637.gh6...@lupin.powdarrmonkey.net
Re: lintian error on my package dhcp-probe
The word overridden was wrote as overriden into dhcp_probe.8.gz file. You must fix it. It is a spelling error. Regards, Eriberto - Brazil 2010/3/15 Laurent Guignard lguignard.deb...@gmail.com: I have this error during a lintian check : I: dhcp-probe: spelling-error-in-manpage usr/share/man/man8/dhcp_probe.8.gz overriden overridden I have problem to interpret this message. I think it is a problem on the overridden word but i don't see where the spelling error. -- 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/4784fdae1003151310v4626687crbac20c546d513...@mail.gmail.com
Re: lintian error on my package dhcp-probe
Hi, On Mon, Mar 15, 2010 at 09:04:22PM +0100, Laurent Guignard wrote: I have this error during a lintian check : I: dhcp-probe: spelling-error-in-manpage usr/share/man/man8/dhcp_probe.8.gz overriden overridden N: N:Lintian found a spelling error in the manpage. Lintian has a list of N:common misspellings that it looks for. It does not have a dictionary N:like a spelling checker does. [..] I have problem to interpret this message. I think it is a problem on the overridden word but i don't see where the spelling error. On top of other replies, note the existence of debian-l10n-english, which can proofread your text. Moreoever, remember that debian-l10n-$lang can be useful even when you are a $lang native. Regards. -- Simon Paillard -- 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/20100315201740.gq8...@dedibox.ebzao.info
Re: lintian error on my package dhcp-probe
Laurent Guignard wrote: Hi mentors, I have this error during a lintian check : I: dhcp-probe: spelling-error-in-manpage usr/share/man/man8/dhcp_probe.8.gz overriden overriden N: N:Lintian found a spelling error in the manpage. Lintian has a list of N:common misspellings that it looks for. It does not have a dictionary N:like a spelling checker does. N: N:If the string containing the spelling error is translated with the help N:of gettext (with the help of po4a, for example) or a similar tool, N:please fix the error in the translations as well as the English text to N:avoid making the translations fuzzy. With gettext, for example, this N:means you should also fix the spelling mistake in the corresponding N:msgids in the *.po files. N: N:Severity: minor, Certainty: possible N: I: dhcp-probe: spelling-error-in-manpage usr/share/man/man8/dhcp_probe.8.gz overriden overridden I have problem to interpret this message. I think it is a problem on the overridden word but i don't see where the spelling error. Thank you for any help. Best regards. Just search the manpage for 'overriden' and replace it with 'overridden'. The first value is the misspelling and the second is the proper spelling. -Chris signature.asc Description: OpenPGP digital signature
Re: lintian error on my package dhcp-probe
Le Mon, Mar 15, 2010 at 05:10:46PM -0300, Eriberto a écrit : The word overridden was wrote as overriden into dhcp_probe.8.gz file. You must fix it. It is a spelling error. Hi all, I would rather recommend to forward the bug upstream instead of increasing the package's complexity with a patch or a build-time modification. This has the double benefit of sharing with the whole communauty, and pinging upstream for activity. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100316002232.gb25...@kunpuu.plessy.org
Re: Man page, the way to avoid lintian error ??
On Wed, 06 Jan 2010 14:04:03 -0800, Russ Allbery wrote: Laurent Guignard lguignard.deb...@gmail.com writes: When i run lintian on my package i have this : W: dhcp-probe: manpage-has-errors-from-man usr/share/man/cf/man5/dhcp_probe.5.gz Invalid or incomplete multibyte or wide character W: dhcp-probe: manpage-has-errors-from-man usr/share/man/man5/dhcp_probe.cf.5.gz Invalid or incomplete multibyte or wide character W: dhcp-probe: manpage-has-errors-from-man usr/share/man/man8/dhcp_probe.8.gz Invalid or incomplete multibyte or wide character The problem is that there are more 80 characters on lines. Well, that may also be the case, but that's not actually what Lintian is warning about. man --warnings thinks that you've got an invalid wide character in your man page. The first thing to double-check is whether you have a UTF-8 locale installed. If you don't, that may be confusing man. Lintian has to force man to use UTF-8 or we run into problems checking man pages in languages that have to use multibyte characters, such as Chinese. If that isn't the problem it may be that your man page is not encoded in the correct character set for where you're installing it. You may be able to correct this by using iconv on the upstream man pages to convert the character set used upstream to what should be used on Debian (generally UTF-8). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ Thanks Russ, I install locales and set to fr_FR.UTF-8 and lintian doesn't warning me about the man page. From several times i have problems with locales on several GNU/Linux distributions (Debian comes with solutions has you gave me ;) ). Thanks a lot, i will be able to upload my package on d.m.n to solve some bugs. Best regards. Laurent. -- Laurent Guignard, Registered as user #301590 with the Linux Counter Site : http://www.famille-guignard.org Blog : http://blog.famille-guignard.org Projet : http://sicontact.sourceforge.net GULL de Villefranche sur Saône : http://www.cagull.org signature.asc Description: Digital signature
Man page, the way to avoid lintian error ??
Hi mentors, When i run lintian on my package i have this : W: dhcp-probe: manpage-has-errors-from-man usr/share/man/cf/man5/dhcp_probe.5.gz Invalid or incomplete multibyte or wide character N: N:This man page provokes warnings or errors from man. N: N:cannot adjust or can't break are trouble with paragraph filling, N:usually related to long lines. Adjustment can be helped by left N:justifying, breaks can be helped with hyphenation, see Manipulating N:Filling and Adjusting and Manipulating Hyphenation in the manual. N: N:can't find numbered character usually means latin1 etc in the input, N:and this warning indicates characters will be missing from the output. N:You can change to escapes like \[:a] described on the groff_char man N:page. [...] N:To test this for yourself you can use the following command: N: LANG=C MANWIDTH=80 man --warnings -E UTF-8 -l manpage-file /dev/null N: N:Severity: normal, Certainty: certain N: W: dhcp-probe: manpage-has-errors-from-man usr/share/man/man5/dhcp_probe.cf.5.gz Invalid or incomplete multibyte or wide character W: dhcp-probe: manpage-has-errors-from-man usr/share/man/man8/dhcp_probe.8.gz Invalid or incomplete multibyte or wide character The problem is that there are more 80 characters on lines. In most cases, this is code sources included in man page or configuration file example and i don't want to cut lines (to keep readable the man page). Is there any means to keep out these warnings ? Thanks in advance. Best regards, Laurent. -- Laurent Guignard, Registered as user #301590 with the Linux Counter Site : http://www.famille-guignard.org Blog : http://blog.famille-guignard.org Projet : http://sicontact.sourceforge.net GULL de Villefranche sur Saône : http://www.cagull.org signature.asc Description: Digital signature
Re: Man page, the way to avoid lintian error ??
Laurent Guignard lguignard.deb...@gmail.com writes: When i run lintian on my package i have this : W: dhcp-probe: manpage-has-errors-from-man usr/share/man/cf/man5/dhcp_probe.5.gz Invalid or incomplete multibyte or wide character W: dhcp-probe: manpage-has-errors-from-man usr/share/man/man5/dhcp_probe.cf.5.gz Invalid or incomplete multibyte or wide character W: dhcp-probe: manpage-has-errors-from-man usr/share/man/man8/dhcp_probe.8.gz Invalid or incomplete multibyte or wide character The problem is that there are more 80 characters on lines. Well, that may also be the case, but that's not actually what Lintian is warning about. man --warnings thinks that you've got an invalid wide character in your man page. The first thing to double-check is whether you have a UTF-8 locale installed. If you don't, that may be confusing man. Lintian has to force man to use UTF-8 or we run into problems checking man pages in languages that have to use multibyte characters, such as Chinese. If that isn't the problem it may be that your man page is not encoded in the correct character set for where you're installing it. You may be able to correct this by using iconv on the upstream man pages to convert the character set used upstream to what should be used on Debian (generally UTF-8). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Man page, the way to avoid lintian error ??
Russ Allbery r...@debian.org writes: The first thing to double-check is whether you have a UTF-8 locale installed. If you don't, that may be confusing man. I'm confused by the related discussion (on ‘debian-devel’, I think) of having a UTF-8 locale installed by default. In a minimal ‘pbuilder’ environment, this is happening all the time for me now. What should users of ‘pbuilder’ be doing to avoid this problem? -- \“We cannot solve our problems with the same thinking we used | `\ when we created them.” —Albert Einstein | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Man page, the way to avoid lintian error ??
Ben Finney ben+deb...@benfinney.id.au writes:
Russ Allbery r...@debian.org writes:
The first thing to double-check is whether you have a UTF-8 locale
installed. If you don't, that may be confusing man.
I'm confused by the related discussion (on ‘debian-devel’, I think) of
having a UTF-8 locale installed by default.
In a minimal ‘pbuilder’ environment, this is happening all the time for
me now. What should users of ‘pbuilder’ be doing to avoid this problem?
Install locales in your chroot, specifically:
echo 'locales locales/locales_to_be_generated multiselect en_US.UTF-8 UTF-8' \
| debconf-set-selections
aptitude install locales
or whatever UTF-8 locale you prefer.
Here's the script that I use to post-process cowbuilder chroots, in case
it's useful. The dpkg-reconfigure of debconf is so that I can change the
front-end to readline and the severity to critical, which can't be done
via a preseed since debconf is installed by debootstrap.
#!/bin/sh
# $Id: cowbuilder-clean,v 1.5 2010-01-07 00:42:11 eagle Exp $
#
# Cleans up a new cowbuilder chroot, stripping out everything other than
# build-essential and some programs that are almost always installed
# (debhelper, fakeroot, etc.) Takes the name of the chroot directory as
# its only argument.
set -e
if [ -z $1 ] ; then
echo 'No chroot directory given' 2
exit 1
fi
if [ ! -d $1 ] ; then
echo chroot directory $1 is not a directory 2
exit 1
fi
chroot $1 apt-get install aptitude
chroot $1 aptitude markauto \
'?not(build-essential|debhelper|aptitude|cowdancer|pbuilder|cdebootstrap-helper-rc.d)'
echo 'locales locales/locales_to_be_generated multiselect en_US.UTF-8 UTF-8' \
| chroot $1 debconf-set-selections
chroot $1 aptitude -R install debhelper fakeroot locales
chroot $1 dpkg-reconfigure debconf
chroot $1 dpkg --get-selections | grep deinstall | awk '{ print $1 }' \
| xargs -r chroot $1 dpkg --purge
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
php lintian error
Hi mentors some time ago i put a RFS for sitebar package, but it had a lintian error, also it is on the package page, please, I was looking for info about php apps the error is about a postinfo script where it ask about the mysqld server running the question is if /usr/sbin/mysqld ... and the lintian error is about 6.1 policy section please could you give a hand thanks -- Carlos Eduardo Sotelo Pinto ( KrLoS ) Free and OpenSource Software Developer GNULinux Registered User #379182 GNULinux Registered Machine #277661 GNULinux Arequipa Users Group||Debian Arequipa Users Group -- pgp.rediris.es 0xF8554F6B GPG FP:697E FAB8 8E83 1D60 BBFB 2264 9E3D 5761 F855 4F6B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error
Ben Finney wrote: Paul Wise [EMAIL PROTECTED] writes: On Wed, Jul 30, 2008 at 3:52 PM, Charliej [EMAIL PROTECTED] wrote: I have contacted upstream about this error, and he states that he would not want to depend on the prototype package in debian because he has made changes to the version of prototype he is currently using. Please ask him to send his changes to the prototype upstream developers so they can be included in the next prototype release. Another option is for the person who wants the library to be different to fork it, maintain that fork, and work with someone to get it into Debian. This option is obviously more ongoing work, but may be preferable if (as sometimes happens) the author of the library won't accept the changes. Once that is in Debian, your package can depend on it. Same here. The main point is that a library that is *not* the same 'prototype' as upstream should either be merged with, or clearly (in name and in code access) differentiated from, the upstream 'prototype' library. Which is what you (Charliej) are already discussing with your upstream, so thank you. First let me apologize for a mistake in my first post. My upstream is actually using what is in the debian repos now. I had accidentally grabbed a later version to do my diff with. So actually there are no differences between upstream prototype and what is in the package now. With that said this is a quote from my upstream: Whee, is this something you could take care of at install, delete and then create a symlink. Or would this still violate this policy Would this be a viable solution? (I told upstream I would ask) I don't think this is a viable solution because the lintian error would still remain. I think one of the reasons he is hesitant is that the removal of prototype from the .tar.gz that he hosts would severely impact his M$ Windows users (he has a rather large M$ Windows community). Actually I could care less about M$ Windows users, but he does. As I see it to comply with Policy 4.13 prototype will have to be removed from upstreams .tar.gz.. Am I correct in this assumption? This brings me to the next point what if upstream refuses to remove prototype from the .tar.gz? Thx Charlie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error
Charliej wrote: With that said this is a quote from my upstream: Whee, is this something you could take care of at install, delete and then create a symlink. Or would this still violate this policy Would this be a viable solution? (I told upstream I would ask) I don't think this is a viable solution because the lintian error would still remain. You should symlink the file provided by the other package, if lintian still complains it is a bug in lintian then. I think one of the reasons he is hesitant is that the removal of prototype from the .tar.gz that he hosts would severely impact his M$ Windows users (he has a rather large M$ Windows community). Actually I could care less about M$ Windows users, but he does. As I see it to comply with Policy 4.13 prototype will have to be removed from upstreams .tar.gz.. Am I correct in this assumption? No, he doesn't need to remove his copy of prototype, it is _you_ who needs to prevent it from being installed in the package you build. This brings me to the next point what if upstream refuses to remove prototype from the .tar.gz? Thx Charlie Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error
Raphael Geissert wrote: Charliej wrote: With that said this is a quote from my upstream: Whee, is this something you could take care of at install, delete and then create a symlink. Or would this still violate this policy Would this be a viable solution? (I told upstream I would ask) I don't think this is a viable solution because the lintian error would still remain. You should symlink the file provided by the other package, if lintian still complains it is a bug in lintian then. I think one of the reasons he is hesitant is that the removal of prototype from the .tar.gz that he hosts would severely impact his M$ Windows users (he has a rather large M$ Windows community). Actually I could care less about M$ Windows users, but he does. As I see it to comply with Policy 4.13 prototype will have to be removed from upstreams .tar.gz.. Am I correct in this assumption? No, he doesn't need to remove his copy of prototype, it is _you_ who needs to prevent it from being installed in the package you build. This I can do, but to clarify your above statement does that mean that I remove it from the .orig.tar.gz or do I adjust the rules and or postinst to insure that it does not get installed? hmm I think I may have answered my own question. Upstreams .tar.gz and the .orig.tar.gz must have the same md5sum correct? if so then that means the rules and or postinst have to be modified. Is my thinking here correct? This brings me to the next point what if upstream refuses to remove prototype from the .tar.gz? Thx Charlie Cheers, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error
[Please respect the CoC[0] and avoid sending me copies of the message] [0]http://www.debian.org/MailingLists/#codeofconduct Charliej wrote: Raphael Geissert wrote: Charliej wrote: With that said this is a quote from my upstream: Whee, is this something you could take care of at install, delete and then create a symlink. Or would this still violate this policy Would this be a viable solution? (I told upstream I would ask) I don't think this is a viable solution because the lintian error would still remain. You should symlink the file provided by the other package, if lintian still complains it is a bug in lintian then. I think one of the reasons he is hesitant is that the removal of prototype from the .tar.gz that he hosts would severely impact his M$ Windows users (he has a rather large M$ Windows community). Actually I could care less about M$ Windows users, but he does. As I see it to comply with Policy 4.13 prototype will have to be removed from upstreams .tar.gz.. Am I correct in this assumption? No, he doesn't need to remove his copy of prototype, it is _you_ who needs to prevent it from being installed in the package you build. This I can do, but to clarify your above statement does that mean that I remove it from the .orig.tar.gz or do I adjust the rules and or postinst to insure that it does not get installed? The latter :) hmm I think I may have answered my own question. Upstreams .tar.gz and the .orig.tar.gz must have the same md5sum correct? if so then that s/must/should, there are situations where one must repackage the tarball, but I don't believe this is the case. means the rules and or postinst have to be modified. Is my thinking here correct? Besides what I just clarified, yes. This brings me to the next point what if upstream refuses to remove prototype from the .tar.gz? Thx Charlie Cheers, Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error
Raphael Geissert wrote: [Please respect the CoC[0] and avoid sending me copies of the message] [0]http://www.debian.org/MailingLists/#codeofconduct Charliej wrote: Raphael Geissert wrote: Charliej wrote: With that said this is a quote from my upstream: Whee, is this something you could take care of at install, delete and then create a symlink. Or would this still violate this policy Would this be a viable solution? (I told upstream I would ask) I don't think this is a viable solution because the lintian error would still remain. You should symlink the file provided by the other package, if lintian still complains it is a bug in lintian then. I think one of the reasons he is hesitant is that the removal of prototype from the .tar.gz that he hosts would severely impact his M$ Windows users (he has a rather large M$ Windows community). Actually I could care less about M$ Windows users, but he does. As I see it to comply with Policy 4.13 prototype will have to be removed from upstreams .tar.gz.. Am I correct in this assumption? No, he doesn't need to remove his copy of prototype, it is _you_ who needs to prevent it from being installed in the package you build. This I can do, but to clarify your above statement does that mean that I remove it from the .orig.tar.gz or do I adjust the rules and or postinst to insure that it does not get installed? The latter :) hmm I think I may have answered my own question. Upstreams .tar.gz and the .orig.tar.gz must have the same md5sum correct? if so then that s/must/should, there are situations where one must repackage the tarball, but I don't believe this is the case. means the rules and or postinst have to be modified. Is my thinking here correct? Besides what I just clarified, yes. This brings me to the next point what if upstream refuses to remove prototype from the .tar.gz? Thx Charlie Cheers, Cheers, To everyone who answered this post Thank You very much for your assistance. Charlie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error
On Fri, Aug 1, 2008 at 12:04 AM, Charliej [EMAIL PROTECTED] wrote: I think one of the reasons he is hesitant is that the removal of prototype from the .tar.gz that he hosts would severely impact his M$ Windows users (he has a rather large M$ Windows community). Actually I could care less about M$ Windows users, but he does. Making an installer for the Windows users (using nsis or similar) and leaving prototype out of the source tarball would be the ideal way for upstream to care about both Debian and Windows users. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Lintian error
I am getting this error from lintian N: This package contains an embedded copy of the JQuery, Prototype, N: Mochikit or Cropper JavaScript libraries that are now available in N: their own packages. Please depend on the appropriate package and N: symlink the library into the appropriate location. N: N: Refer to Policy Manual, section 4.13 for details. N: I have contacted upstream about this error, and he states that he would not want to depend on the prototype package in debian because he has made changes to the version of prototype he is currently using. I have run a diff on prototype which is in the package and the version in debian and there are differences. Would Debian Policy 4.13 still apply? Charlie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error
On Wed, Jul 30, 2008 at 3:52 PM, Charliej [EMAIL PROTECTED] wrote: I have contacted upstream about this error, and he states that he would not want to depend on the prototype package in debian because he has made changes to the version of prototype he is currently using. Please ask him to send his changes to the prototype upstream developers so they can be included in the next prototype release. Once that is in Debian, your package can depend on it. I have run a diff on prototype which is in the package and the version in debian and there are differences. Would Debian Policy 4.13 still apply? Yes, but it is only a 'should', so it is OK to be working with upstream to resolve it. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error
Paul Wise [EMAIL PROTECTED] writes: On Wed, Jul 30, 2008 at 3:52 PM, Charliej [EMAIL PROTECTED] wrote: I have contacted upstream about this error, and he states that he would not want to depend on the prototype package in debian because he has made changes to the version of prototype he is currently using. Please ask him to send his changes to the prototype upstream developers so they can be included in the next prototype release. Another option is for the person who wants the library to be different to fork it, maintain that fork, and work with someone to get it into Debian. This option is obviously more ongoing work, but may be preferable if (as sometimes happens) the author of the library won't accept the changes. Once that is in Debian, your package can depend on it. Same here. The main point is that a library that is *not* the same 'prototype' as upstream should either be merged with, or clearly (in name and in code access) differentiated from, the upstream 'prototype' library. Which is what you (Charliej) are already discussing with your upstream, so thank you. -- \ “We must become the change we want to see.” —Mahatma Gandhi | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451061: wxglade: lintian error, debian-files-list-in-source
Hello Georges, [Note: CC'ing debian-mentors so you get some more help from there] On 13/11/2007, Georges Khaznadar [EMAIL PROTECTED] wrote: Hello Raphael, I did notice this bug, and fought against it. However, even if delete debian/files in the target 'clean' of debian/rules, it is created again and exists when lintian checks the package. This behavior began when I added the usage of dh_python to comply with Python policy. Do you know whether dh_python creates the file debian/rules out of sync with the other debian helper scripts ? I'm not very keen on python so I really have no idea about what packaging python libraries require (it is actually confusing the fact that there are three debhelpers for it: dh_python, dh_pysupport and dh_pycentral). I took a quick look at your package and here are some notes: * Doesn't seem to require python-all-dev: $ dpkg-buildpackage dpkg-buildpackage: source package wxglade dpkg-buildpackage: source version 0.5-1 dpkg-buildpackage: source changed by Georges Khaznadar [EMAIL PROTECTED] dpkg-buildpackage: host architecture i386 dpkg-checkbuilddeps: Unmet build dependencies: python-all-dev (= 2.3.5-11) dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage: warning: (Use -d flag to override.) $ dpkg-buildpackage -d dpkg-buildpackage: source package wxglade dpkg-buildpackage: source version 0.5-1 dpkg-buildpackage: source changed by Georges Khaznadar [EMAIL PROTECTED] dpkg-buildpackage: host architecture i386 ... warning, `debian/python-wxglade/DEBIAN/control' contains user-defined field `Python-Version' dpkg-deb: building package `python-wxglade' in `../python-wxglade_0.5-1_all.deb'. dpkg-deb: ignoring 1 warnings about the control file(s) signfile wxglade_0.5-1.dsc gpg: skipped Georges Khaznadar [EMAIL PROTECTED]: secret key not available gpg: [stdin]: clearsign failed: secret key not available dpkg-genchanges ../wxglade_0.5-1_i386.changes dpkg-genchanges: including full source code in upload dpkg-buildpackage: full upload (original source is included) dpkg-buildpackage: warning: Failed to sign .dsc and .changes file * dh_python isn't used: -- ... dh_fixperms dh_pycentral dh_python dh_python: Doing nothing since dh_pycompat exists; dh_pysupport or dh_pycentral should do the work. You can remove dh_python from your rules file. dh_installdeb ... -- * .orig contains a debian/ directory, please contact upstream and tell them ship the man page as upstream and not ship the debian directory in their tarballs (it is not recommended and it _IS_ the real source of lintian's warning: debian/files is in upstream's tarball). * .orig.tar.gz and upstream's .tar.gz differ (and they shouldn't): $ md5sum *0.5*.tar.gz 345d735076c6dda6a86db604612c6f39 wxglade_0.5.orig.tar.gz 705855ef251053bd6b032bc5667cea19 wxGlade-0.5.tar.gz * there's a new upstream version I personally recommend you to either contact upstream so they don't ship debian/ and make a new package from scratch (preserving the changelog file). If you have any doubt you can always ask on [EMAIL PROTECTED] or even ask your co-maintainer (he's a DD anyway). Best regards, Georges. Raphael Geissert a écrit : Package: wxglade Severity: minor Hello, While checking the list generated by lintian about the debian-files-list-in-source error[1] I've noticed wxglade is listed. Quoting the same page: Leaving debian/files causes problems for the autobuilders, since that file will likely include the list of .deb files for another architecture, which will cause dpkg-buildpackage run by the buildd to fail. The clean rule for the package should remove this file. [1] http://lintian.debian.org/reports/Tdebian-files-list-in-source.html Kind regards, Raphael Geissert -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 Sincerely, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition
Re: Lintian error about missing debconf dependency (which is not missing)
On Thu, Dec 22, 2005 at 09:36:57AM +0100, Michael Hanke wrote: If you depend on newer features than those guaranteed by the debconf-2.0 interface, you will need to depend on the providers of those features explicitly, *without* an or on debconf-2.0. Thanks. I did'nt realize this fact. So if I get you right the solution would be to get rid of the debconf-2.0 dependency. If I do so lintian is fine, but I guess Joey Hess is not: http://lists.debian.org/debian-devel/2005/08/msg00136.html (and follow-ups) This post was the reason why I included this dependency in the first place. As the debconf-2.0 package's purpose is to allow transition to cdebconf, is depending on cdebconf explicitely as an alternative to debconf an option? How compatible are those 'alternatives' currently. Yes, the best solution available today would be to use Depends: debconf (= 1.3.22) | cdebconf (= ??) I don't know what minimum version of cdebconf (if any) you should specify to get support for settitle. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Lintian error about missing debconf dependency (which is not missing)
Op vr 23 dec 2005 om 02:31:16 -0800 schreef Steve Langasek: I don't know what minimum version of cdebconf (if any) you should specify to get support for settitle. From the changelog: cdebconf (0.43) Add new command SETTITLE Bye, Joost signature.asc Description: Digital signature
Re: Lintian error about missing debconf dependency (which is not missing)
Russ Allbery wrote: I hate to say this, since actually implementing it is a lot of work in supporting programs like debhelper, but if the debconf-2.0 pseudopackage was introduced prior to a new feature in the debconf interface there needs to be a debconf-2.1 or debconf-3.0 as well. If cdebconf implements that protocol, it can provide that pseudopackage as well. Any later version 2.x of the debconf protocol is intended to be backwards compatible with 2.0. In practice, new commands such as SETTITLE and the PROGRESS stuff can be added to the protocol without increasing the version number since earlier versions of debconf can skip doing anything for these commands with no undue effects (although if you want this to work, you'll need to || true your db_settitle commands in a shell script). The CAPB interface also allows for larger change to the protocol without increasing the version number. I wouldn't object to a version 2.1 being added to the protocol, but getting anything into the policy manual has become to much of a pain for me to bother with myself. -- see shy jo signature.asc Description: Digital signature
Re: Lintian error about missing debconf dependency (which is not missing)
Hi! On Fri, Dec 23, 2005 at 12:37:20PM +0100, Joost van Baal wrote: Op vr 23 dec 2005 om 02:31:16 -0800 schreef Steve Langasek: I don't know what minimum version of cdebconf (if any) you should specify to get support for settitle. From the changelog: cdebconf (0.43) Add new command SETTITLE Thanks. I added cdebconf (= 0.43) as an alternative to the debconf dependency. Now, all should be fine -- lintian is. Cheers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
Re: Lintian error about missing debconf dependency (which is not missing)
Hi!
On Wed, Dec 21, 2005 at 04:18:13PM -0800, Steve Langasek wrote:
The strange thing is, that I have the following line in the control file:
Depends: ${misc:Depends}, iptables (=1.2.11), gawk, debconf (=1.3.22) |
debconf-2.0
There is clearly a versioned debconf dependency. The above line is
expanded to the following when building the package.
Depends: debconf (= 0.5) | debconf-2.0, iptables (= 1.2.11), gawk,
debconf (= 1.3.22) | debconf-2.0
Does anybody know where the problem is?
It's pretty likely that the lintian check is buggy in this case;
nevertheless, your depends: line is *also* buggy.
Depends: debconf (= 0.5) | debconf-2.0, debconf (= 1.3.22) | debconf-2.0
Reduces to
Depends: debconf (= 1.3.22) | debconf-2.0
*but*, this in turn reduces to
Depends: debconf-2.0
because there are versions of debconf older than 1.3.22 which provide
debconf-2.0 (the Provides: was introduced in debconf 1.2.30), so they
satisfy the second branch of the dependency relationship when they
*shouldn't*.
If you depend on newer features than those guaranteed by the debconf-2.0
interface, you will need to depend on the providers of those features
explicitly, *without* an or on debconf-2.0.
Thanks. I did'nt realize this fact. So if I get you right the solution
would be to get rid of the debconf-2.0 dependency. If I do so lintian is
fine, but I guess Joey Hess is not:
http://lists.debian.org/debian-devel/2005/08/msg00136.html
(and follow-ups)
This post was the reason why I included this dependency in the first
place.
As the debconf-2.0 package's purpose is to allow transition to cdebconf,
is depending on cdebconf explicitely as an alternative to debconf an
option? How compatible are those 'alternatives' currently.
Cheers,
Michael
--
GPG key: 1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050
signature.asc
Description: Digital signature
Re: Lintian error about missing debconf dependency (which is not missing)
Russ Allbery said: I hate to say this, since actually implementing it is a lot of work in supporting programs like debhelper, but if the debconf-2.0 pseudopackage was introduced prior to a new feature in the debconf interface there needs to be a debconf-2.1 or debconf-3.0 as well. If cdebconf implements that protocol, it can provide that pseudopackage as well. Agreed. IANADD, but I would depend on debconf-2.1 and when anybody complains point to russ's message. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Lintian error about missing debconf dependency (which is not missing)
Hi!
I'm preparing a package which uses debconf. When I run lintian on the
package the following error is reported:
E: arno-iptables-firewall: settitle-requires-versioned-depends config
N:
N: Debconf only supports the SETTITLE command as of version 1.3.22. To
N: ensure upgrades work correctly, packages that use this new command
N: should declare a dependency on that version of debconf.
N:
The strange thing is, that I have the following line in the control file:
Depends: ${misc:Depends}, iptables (=1.2.11), gawk, debconf (=1.3.22) |
debconf-2.0
There is clearly a versioned debconf dependency. The above line is
expanded to the following when building the package.
Depends: debconf (= 0.5) | debconf-2.0, iptables (= 1.2.11), gawk, debconf
(= 1.3.22) | debconf-2.0
Does anybody know where the problem is?
Thanks in advance.
Cheers,
Michael
--
GPG key: 1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050
signature.asc
Description: Digital signature
Re: Lintian error about missing debconf dependency (which is not missing)
Michael Hanke [EMAIL PROTECTED] writes:
I'm preparing a package which uses debconf. When I run lintian on the
package the following error is reported:
E: arno-iptables-firewall: settitle-requires-versioned-depends config
N:
N: Debconf only supports the SETTITLE command as of version 1.3.22. To
N: ensure upgrades work correctly, packages that use this new command
N: should declare a dependency on that version of debconf.
N:
The strange thing is, that I have the following line in the control file:
Depends: ${misc:Depends}, iptables (=1.2.11), gawk, debconf (=1.3.22) |
debconf-2.0
There is clearly a versioned debconf dependency. The above line is
expanded to the following when building the package.
Depends: debconf (= 0.5) | debconf-2.0, iptables (= 1.2.11), gawk, debconf
(= 1.3.22) | debconf-2.0
Does anybody know where the problem is?
I wonder if lintian is getting confused by the dependency added by
${misc:Depends} and missing the second dependency that is tighter.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error about missing debconf dependency (which is not missing)
On Wed, Dec 21, 2005 at 08:35:52PM +0100, Michael Hanke wrote:
I'm preparing a package which uses debconf. When I run lintian on the
package the following error is reported:
E: arno-iptables-firewall: settitle-requires-versioned-depends config
N:
N: Debconf only supports the SETTITLE command as of version 1.3.22. To
N: ensure upgrades work correctly, packages that use this new command
N: should declare a dependency on that version of debconf.
N:
The strange thing is, that I have the following line in the control file:
Depends: ${misc:Depends}, iptables (=1.2.11), gawk, debconf (=1.3.22) |
debconf-2.0
There is clearly a versioned debconf dependency. The above line is
expanded to the following when building the package.
Depends: debconf (= 0.5) | debconf-2.0, iptables (= 1.2.11), gawk, debconf
(= 1.3.22) | debconf-2.0
Does anybody know where the problem is?
It's pretty likely that the lintian check is buggy in this case;
nevertheless, your depends: line is *also* buggy.
Depends: debconf (= 0.5) | debconf-2.0, debconf (= 1.3.22) | debconf-2.0
Reduces to
Depends: debconf (= 1.3.22) | debconf-2.0
*but*, this in turn reduces to
Depends: debconf-2.0
because there are versions of debconf older than 1.3.22 which provide
debconf-2.0 (the Provides: was introduced in debconf 1.2.30), so they
satisfy the second branch of the dependency relationship when they
*shouldn't*.
If you depend on newer features than those guaranteed by the debconf-2.0
interface, you will need to depend on the providers of those features
explicitly, *without* an or on debconf-2.0.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: Lintian error binary-or-shlib-defines-rpath
Op di 11 okt 2005 om 10:26:50 +0200 schreef Jan C. Nordholz: snip AFAICT, --disable-rpath is catching all usages of the rpath feature except one: src/Makefile.in, Line 540: 540 $(CXXLINK) -rpath $(kde_moduledir) $(libkbibtexpart_la_LDFLAGS) $(libkbibtexpart_la_OBJECTS) $(libkbibtexpart_la_LIBADD) $(LIBS) Here -rpath is used unconditionally (and the target in question is libkbibtexpart.la, so I think that is the one lintian chokes about). I'd suggest you remove the -rpath $(kde_moduledir) and try again. And, of course, report this ignoring --disable-rpath as a bug to upstream. Bye, Joost signature.asc Description: Digital signature
Re: Lintian error binary-or-shlib-defines-rpath
Hi,
Op wo 12 okt 2005 om 09:32:55 +0200 schreef Michael Hanke:
Joost van Baal schrieb:
Op di 11 okt 2005 om 10:26:50 +0200 schreef Jan C. Nordholz:
snip
AFAICT, --disable-rpath is catching all usages of the rpath feature except
one: src/Makefile.in, Line 540:
540 $(CXXLINK) -rpath $(kde_moduledir)
$(libkbibtexpart_la_LDFLAGS) $(libkbibtexpart_la_OBJECTS)
$(libkbibtexpart_la_LIBADD) $(LIBS)
Here -rpath is used unconditionally (and the target in question is
libkbibtexpart.la, so I think that is the one lintian chokes about).
I'd suggest you remove the -rpath $(kde_moduledir) and try again.
And, of course, report this ignoring --disable-rpath as a bug to
upstream.
Of course. I did this even before posting to this list.
Simply removing -rpath $(kde_moduledir) from the Makefile.in did not
make it. It led to an error about missing libkbibtexpart.lai (sorry, I
don't have the output here ATM).
I don't know the autotools too well, but as Makefile.in is a generated
file, shouldn't the root of the error be somewhere else?
Yes, probably in Makefile.am in the same directory. If it's not there,
it might be in configure.{ac,in} in the toplevel directory.
NB: fixing these kind or problems is very often not trivial,
unfortunately...
Bye,
Joost
signature.asc
Description: Digital signature
Re: Lintian error binary-or-shlib-defines-rpath
On Wed, Oct 12, 2005 at 10:18:56AM +0200, Joost van Baal wrote:
Hi,
Op wo 12 okt 2005 om 09:32:55 +0200 schreef Michael Hanke:
Joost van Baal schrieb:
Op di 11 okt 2005 om 10:26:50 +0200 schreef Jan C. Nordholz:
snip
AFAICT, --disable-rpath is catching all usages of the rpath feature
except
one: src/Makefile.in, Line 540:
540 $(CXXLINK) -rpath $(kde_moduledir)
$(libkbibtexpart_la_LDFLAGS) $(libkbibtexpart_la_OBJECTS)
$(libkbibtexpart_la_LIBADD) $(LIBS)
Here -rpath is used unconditionally (and the target in question is
libkbibtexpart.la, so I think that is the one lintian chokes about).
I'd suggest you remove the -rpath $(kde_moduledir) and try again.
And, of course, report this ignoring --disable-rpath as a bug to
upstream.
Of course. I did this even before posting to this list.
Simply removing -rpath $(kde_moduledir) from the Makefile.in did not
make it. It led to an error about missing libkbibtexpart.lai (sorry, I
don't have the output here ATM).
I suspect _that_ problem occurred because it's trying to link against a
module built from the same source, which is not yet installed. So it
uses -rpath builddir for libtool to find the .lai, and the .lai (which
is the installed version of a .la with all paths fixed to final
destinations) tells it it's going to be in /usr/lib, so it embedds
/usr/lib into your file, but actually gives -L $(kde_moduledir)
-lkbibtexpart -rpath $(destination_according_to_.lai_file) or simiar to gcc.
Or at least I _think_ that's how it goes.
I'd suggest the actual problem is libtool should drop the '-rpath' part
of the gcc call when the value for -rpath is /lib, /usr/lib, or
/usr/local/lib.
Assuming I'm right as to the problem.
I don't know the autotools too well, but as Makefile.in is a generated
file, shouldn't the root of the error be somewhere else?
Makefile.in is only generated if using automake, in whcih case it is
as follows.
Yes, probably in Makefile.am in the same directory. If it's not there,
it might be in configure.{ac,in} in the toplevel directory.
Otherwise, the .in file is not generated, but processed by configure
into a Makefile mainly by variable substitution.
You can tell an automake-generated Makefile.in because it'll make you
cry like a small child if you accidentally view it in a text editor.
^_^
--
---
Paul TBBle Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]
No survivors? Then where do the stories come from I wonder?
-- Capt. Jack Sparrow, Pirates of the Caribbean
License: http://creativecommons.org/licenses/by/2.1/au/
---
pgpWGCT73h8nd.pgp
Description: PGP signature
Lintian error binary-or-shlib-defines-rpath
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
I'm packaging kbibtex which is a KDE bibtex editor. Lintian reports the
following error for the package:
N: Processing 1 packages...
N:
N: Processing binary package kbibtex (version 0.1.2a-2) ...
W: kbibtex: binary-or-shlib-defines-rpath ./usr/bin/kbibtex /usr/lib
N:
N: The binary or shared library defines the `RPATH'. Usually this is a
N: bad thing. Most likely you will find a Makefile with a line like:
N: gcc test.o -o test -Wl,--rpath
N: or
N: gcc test.o -o test -R/usr/local/lib
N: Please contact debian-devel@lists.debian.org if you have questions
N: about this.
N:
W: kbibtex: binary-or-shlib-defines-rpath
./usr/lib/kde3/libkbibtexpart.so /usr/lib
I first thought there might be something wrong with my debian/rules, so
I switched to CDBS to get a second oppinion. That made the rules file
pretty simple
#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/kde.mk
But the error remained. CDBS makes configure get called with the
follwing arguments.
./configure --build=i486-linux-gnu --prefix=/usr
- - --includedir=\${prefix}/include/kde --mandir=\${prefix}/share/man
- - --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
- - --libexecdir=\${prefix}/lib/kbibtex --disable-maintainer-mode
- - --with-qt-dir=/usr/share/qt3 --disable-rpath --with-xinerama
The argument --disable-rpath does not have the promised consequence -
lintian still reports the error.
Does someone have an idea what I'm doing wrong?
The package is available from mentors.debian.net
Thanks in advance,
Michael
- --
GPG key: 1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDTBgT93+NsjFEvg8RAlJAAKC1Eof1yq/lwDORpvtgoTFWGlX8WwCcCUqH
26nRRl9FA1pljVBHgv0LseE=
=vu5r
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error binary-or-shlib-defines-rpath
On Tue, Oct 11, 2005 at 09:52:51PM +0200, Michael Hanke wrote: I'm packaging kbibtex which is a KDE bibtex editor. Lintian reports the following error for the package: W: kbibtex: binary-or-shlib-defines-rpath ./usr/lib/kde3/libkbibtexpart.so /usr/lib That's totally unnecessary, anyway.. why would /usr/lib/ ever need to be in an rpath?? The argument --disable-rpath does not have the promised consequence - lintian still reports the error. Bug.. What is the gcc line that adds rpath? And, what does rpath get used for? Your package creates libraries? Are the libraries to be used for any other program (now or in the future?). See my recent email to -mentors and -devel, the apparent conclusion of which was that rpath is okay for libraries that are private to a given package. Does someone have an idea what I'm doing wrong? You can always call configure yourself; make, too, even. (As a temporary workaround). There's also an rpath hacker program for Debian; as a temporary workaround, you could build-depend on that, too. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error binary-or-shlib-defines-rpath
On Tue, Oct 11, 2005 at 09:52:51PM +0200, Michael Hanke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
I'm packaging kbibtex which is a KDE bibtex editor. Lintian reports the
following error for the package:
N: Processing 1 packages...
N:
N: Processing binary package kbibtex (version 0.1.2a-2) ...
W: kbibtex: binary-or-shlib-defines-rpath ./usr/bin/kbibtex /usr/lib
N:
N: The binary or shared library defines the `RPATH'. Usually this is a
N: bad thing. Most likely you will find a Makefile with a line like:
N: gcc test.o -o test -Wl,--rpath
N: or
N: gcc test.o -o test -R/usr/local/lib
N: Please contact debian-devel@lists.debian.org if you have questions
N: about this.
N:
W: kbibtex: binary-or-shlib-defines-rpath
./usr/lib/kde3/libkbibtexpart.so /usr/lib
I first thought there might be something wrong with my debian/rules, so
I switched to CDBS to get a second oppinion. That made the rules file
pretty simple
#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/kde.mk
But the error remained. CDBS makes configure get called with the
follwing arguments.
./configure --build=i486-linux-gnu --prefix=/usr
- - --includedir=\${prefix}/include/kde --mandir=\${prefix}/share/man
- - --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
- - --libexecdir=\${prefix}/lib/kbibtex --disable-maintainer-mode
- - --with-qt-dir=/usr/share/qt3 --disable-rpath --with-xinerama
The argument --disable-rpath does not have the promised consequence -
lintian still reports the error.
Does someone have an idea what I'm doing wrong?
The package is available from mentors.debian.net
Thanks in advance,
Michael
- --
GPG key: 1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDTBgT93+NsjFEvg8RAlJAAKC1Eof1yq/lwDORpvtgoTFWGlX8WwCcCUqH
26nRRl9FA1pljVBHgv0LseE=
=vu5r
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hi,
AFAICT, --disable-rpath is catching all usages of the rpath feature except
one: src/Makefile.in, Line 540:
540 $(CXXLINK) -rpath $(kde_moduledir) $(libkbibtexpart_la_LDFLAGS)
$(libkbibtexpart_la_OBJECTS) $(libkbibtexpart_la_LIBADD) $(LIBS)
Here -rpath is used unconditionally (and the target in question is
libkbibtexpart.la, so I think that is the one lintian chokes about).
I'd suggest you remove the -rpath $(kde_moduledir) and try again.
I don't want to pull kdelibs4-dev onto my home machine, or I would
have tried myself before suggesting this.
HTH,
Jan
--
Jan C. Nordholz
jckn At gmx net
signature.asc
Description: Digital signature
Re: lintian error file-in-unusual-dir usr/etc/settings/ with Qt3-Application
On Fri, Aug 15, 2003 at 06:42:03PM +0200, Dominik Stadler wrote: I started working on a debian-package. The application uses the Qt-Library as basis (no KDE). During startup, the application looks in a directory /usr/etc/settings/ for system-wide settings for the application. This is not coded inside the application, but a feature of the Qt-Library. Why Qt should look in /usr/etc? Configure your program with --sysconfdir=/etc flag and everything should be OK. Look at http://www.debian.org/doc/packaging-manuals/fhs/fhs-toc.html for more info. Cheers. pgp0.pgp Description: PGP signature
Re: lintian error file-in-unusual-dir usr/etc/settings/ withQt3-Application
Dominik Stadler [EMAIL PROTECTED] writes: Hi, I started working on a debian-package. The application uses the Qt-Library as basis (no KDE). During startup, the application looks in a directory /usr/etc/settings/ for system-wide settings for the application. This is not coded inside the application, but a feature of the Qt-Library. Uh, are you sure? If it's using QSettings, you can modify the search path to be something sane. Or is it getting set through a configure script? Showing us the source would be helpful. If I try to include a configfile in this directory, lintian complains about this with several errors and warnings. Rightly so. I need the configfile there in order to set some system-wide settings that are required to run the application. Without them, every user will need to do manual configuration when starting the application. My question therefore: Is this a case where lintian should allow an exception, because I have no other way of telling the Qt-Library to search in a different directory? Or is it simply not possible? No, this certainly shouldn't be allowable. -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgp0.pgp Description: PGP signature
Re: lintian error file-in-unusual-dir usr/etc/settings/ withQt3-Application
Dominik Stadler [EMAIL PROTECTED] schrieb: [conffile in /usr/etc/settings] My question therefore: Is this a case where lintian should allow an exception, because I have no other way of telling the Qt-Library to search in a different directory? Or is it simply not possible? - How do other programs that rely on the same library solve this? - Why not link /usr/etc/ to /etc/qt or the like? Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian error file-in-unusual-dir usr/etc/settings/ with Qt3-Application
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 15. August 2003 20:26 schrieb Brian Nelson: Dominik Stadler [EMAIL PROTECTED] writes: Nope. You'll need to modify the application source. thanks for all the help, the hint with QSetting was very helpful. I looked at the source and I think I found the place where I can tell the app to look at a different directory also. Dominik. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/PUOXBy2+bgx1H+0RAtAsAJ4+bkEZiG4sXdtt7TEf7MHcCYy8KQCeNwcA BGIzRZcMMd6r0TSvC9lSTMs= =FpK9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian error file-in-unusual-dir usr/etc/settings/ with Qt3-Application
On Fri, Aug 15, 2003 at 09:17:15PM +0200, Frank K?ster [EMAIL PROTECTED] wrote: - Why not link /usr/etc/ to /etc/qt or the like? That still wouldn't conform to policy and is an ugly solution anyway. :) -- Mike Markley [EMAIL PROTECTED] GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lintian error file-in-unusual-dir usr/etc/settings/ with Qt3-Application
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I started working on a debian-package. The application uses the Qt-Library as basis (no KDE). During startup, the application looks in a directory /usr/etc/settings/ for system-wide settings for the application. This is not coded inside the application, but a feature of the Qt-Library. If I try to include a configfile in this directory, lintian complains about this with several errors and warnings. I need the configfile there in order to set some system-wide settings that are required to run the application. Without them, every user will need to do manual configuration when starting the application. My question therefore: Is this a case where lintian should allow an exception, because I have no other way of telling the Qt-Library to search in a different directory? Or is it simply not possible? Dominik. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/PQ1bBy2+bgx1H+0RAlKyAKDcRB2QundIZtg8CRJEmD62YypRbwCggIwv q+OZsFbAPEtIZaDYBPaHgd8= =SMt+ -END PGP SIGNATURE-
Re: lintian error file-in-unusual-dir usr/etc/settings/ with Qt3-Application
On Fri, Aug 15, 2003 at 06:42:03PM +0200, Dominik Stadler wrote: I started working on a debian-package. The application uses the Qt-Library as basis (no KDE). During startup, the application looks in a directory /usr/etc/settings/ for system-wide settings for the application. This is not coded inside the application, but a feature of the Qt-Library. Why Qt should look in /usr/etc? Configure your program with --sysconfdir=/etc flag and everything should be OK. Look at http://www.debian.org/doc/packaging-manuals/fhs/fhs-toc.html for more info. Cheers. pgpH5oXLUqfpG.pgp Description: PGP signature
Re: lintian error file-in-unusual-dir usr/etc/settings/ with Qt3-Application
Dominik Stadler [EMAIL PROTECTED] writes: Hi, I started working on a debian-package. The application uses the Qt-Library as basis (no KDE). During startup, the application looks in a directory /usr/etc/settings/ for system-wide settings for the application. This is not coded inside the application, but a feature of the Qt-Library. Uh, are you sure? If it's using QSettings, you can modify the search path to be something sane. Or is it getting set through a configure script? Showing us the source would be helpful. If I try to include a configfile in this directory, lintian complains about this with several errors and warnings. Rightly so. I need the configfile there in order to set some system-wide settings that are required to run the application. Without them, every user will need to do manual configuration when starting the application. My question therefore: Is this a case where lintian should allow an exception, because I have no other way of telling the Qt-Library to search in a different directory? Or is it simply not possible? No, this certainly shouldn't be allowable. -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgp7n6eAvDNRH.pgp Description: PGP signature
Re: lintian error file-in-unusual-dir usr/etc/settings/ with Qt3-Application
Dominik Stadler [EMAIL PROTECTED] writes: Why Qt should look in /usr/etc? Configure your program with --sysconfdir=/etc flag and everything should be OK. Thanks for the hints, but the problem is that the application does not use autoconf/automake/configure, but the build-tool qmake. Is there any equivalent to --sysconfdir there? I couldn't find one. Nope. You'll need to modify the application source. -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgpgvwFVxiMVc.pgp Description: PGP signature
Re: lintian error file-in-unusual-dir usr/etc/settings/ with Qt3-Application
Dominik Stadler [EMAIL PROTECTED] schrieb: [conffile in /usr/etc/settings] My question therefore: Is this a case where lintian should allow an exception, because I have no other way of telling the Qt-Library to search in a different directory? Or is it simply not possible? - How do other programs that rely on the same library solve this? - Why not link /usr/etc/ to /etc/qt or the like? Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: lintian error file-in-unusual-dir usr/etc/settings/ with Qt3-Application
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 15. August 2003 20:26 schrieb Brian Nelson: Dominik Stadler [EMAIL PROTECTED] writes: Nope. You'll need to modify the application source. thanks for all the help, the hint with QSetting was very helpful. I looked at the source and I think I found the place where I can tell the app to look at a different directory also. Dominik. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/PUOXBy2+bgx1H+0RAtAsAJ4+bkEZiG4sXdtt7TEf7MHcCYy8KQCeNwcA BGIzRZcMMd6r0TSvC9lSTMs= =FpK9 -END PGP SIGNATURE-
Re: lintian error file-in-unusual-dir usr/etc/settings/ with Qt3-Application
On Fri, Aug 15, 2003 at 09:17:15PM +0200, Frank K?ster [EMAIL PROTECTED] wrote: - Why not link /usr/etc/ to /etc/qt or the like? That still wouldn't conform to policy and is an ugly solution anyway. :) -- Mike Markley [EMAIL PROTECTED] GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084
Re: Lintian error when packaging an app.
On Mon, May 05, 2003 at 05:13:54PM +0200, Jaime Robles wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. I am having some problems when packaging an application (KDE app): == E: klog: symlink-should-be-relative usr/share/doc/kde/HTML/en/klog/common /usr/share/doc/kde/HTML/en/common E: klog: package-has-a-duplicate-relation xlibs ( 4.1.0), xlibs ( 4.2.0) == That first error appears to be legitimate. You probably need to make sure that dh_link is being called in the rules script and that you are using a new enough version of debhelper. If I remember correctly that support was added sometime after the 4.0 release. The last time I ran lintian on my packages it didn't show anything about the symlink's being wrong. dh_link manpage dh_link also scans the package build tree for existing symlinks which do not conform to debian policy, and corrects them (v4 only). Chris
Lintian error when packaging an app.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. I am having some problems when packaging an application (KDE app): == E: klog: symlink-should-be-relative usr/share/doc/kde/HTML/en/klog/common /usr/share/doc/kde/HTML/en/common E: klog: package-has-a-duplicate-relation xlibs ( 4.1.0), xlibs ( 4.2.0) == I think i don't have to pay atention to the second error but it is the first time i get the first one... What is to be done to solve that problem? I have seen the lintian reports and MANY kde apps seems to suffer the same error in lintian... http://lintian.debian.org/reports/Tsymlink-should-be-relative.html I am not sure about it but maybe it is related to kdelibs4-dev templates as i had run dh_make -t /usr/share/doc/kdelibs4-dev/dh-make to debianize the sources... I have been surfing in google but i have not found the solution... Thank you very much. - -- Un saludo, Jaime Robles [EMAIL PROTECTED] Coordinador KDE-es - KDE Spanish Translation Team http://www.kde.org/es - http://es.i18n.kde.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+tn+0ER46oL+8yYURAgZ1AJ4laf7H7V0CoWIBLsZnUaz5eq7hkACfcJsI oMIxH0nIIkokjRZM21iBG3E= =NOKK -END PGP SIGNATURE-
Re: Lintian error when packaging an app.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 05 May 2003 16:13, Jaime Robles [EMAIL PROTECTED] wrote: Hello. I am having some problems when packaging an application (KDE app): == E: klog: symlink-should-be-relative usr/share/doc/kde/HTML/en/klog/common /usr/share/doc/kde/HTML/en/common E: klog: package-has-a-duplicate-relation xlibs ( 4.1.0), xlibs ( 4.2.0) == I think i don't have to pay atention to the second error I agree. but it is the first time i get the first one... What is to be done to solve that problem? Well as the error says, you have an absolute symlink from usr/share/doc/kde/HTML/en/klog/common to /usr/share/doc/kde/HTML/en/common, which is not allowed. Two possible solutions: 1. In your install target, after make install, add the following two commands,which will remove the absolute symlink and add a replacement relative symlink: rm debian/klog/usr/share/doc/kde/HTML/en/klog/common ln -s ../common \ debian/klog/usr/share/doc/kde/HTML/en/klog/common 2. Add the appropriate flag to your make install command to tell it where to install the documentation. Now, in the above case it seems that the documentation may actually be being put in the right place, so this may not help, but... $(MAKE) install prefix=$(CURDIR)/debian/klog/usr \ kde_htmldir=$(CURDIR)/debian/klog/usr/share/doc/kde/HTML for example. I have seen the lintian reports and MANY kde apps seems to suffer the same error in lintian... http://lintian.debian.org/reports/Tsymlink-should-be-relative.html Hmm, these should really be fixed at some point. Thank you very much. You are welcome. Paul Cupis - -- [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+tpEgIzuKV+SHX/kRAjH9AKCE02yMfV/x4QlolKkcLvBX9fSPMACfd8qT KsKELpGFcX/R2ftg0AzyZDQ= =uSbb -END PGP SIGNATURE-
Re: Lintian error when packaging an app.
Hi, Jaime Robles wrote: I am having some problems when packaging an application (KDE app): == E: klog: symlink-should-be-relative usr/share/doc/kde/HTML/en/klog/common /usr/share/doc/kde/HTML/en/common E: klog: package-has-a-duplicate-relation xlibs ( 4.1.0), xlibs ( 4.2.0) == I think i don't have to pay atention to the second error but it is the first Right. time i get the first one... What is to be done to solve that problem? I have seen the lintian reports and MANY kde apps seems to suffer the same error in lintian... http://lintian.debian.org/reports/Tsymlink-should-be-relative.html Yes. That's why am ignoring it right now... Regards, Rene -- .''`. Rene Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 pgpeAK2MgEyWZ.pgp Description: PGP signature
lintian error
Hello all, I am sorry to write a question that I think has been answered recently, but I can't find it now. I am getting a lintian error, package-has-a-duplicate-relation xlibs ( 4.1.0), xlibs ( 4.2.0) on one of my packages. I believe this is because of a dependency on both xlibs-dev and kdelibs4, but I'm not sure that removing the dependency on xlibs-dev is the Right Thing to do. I guess I'm just looking for a discussion of the best way to handle this, or a pointer to the previous discussion about it (or did I just imagine it? :) TIA, -- -- | Stephen Gran | If they were so inclined, they could| | [EMAIL PROTECTED] | impeach him because they don't like his | | http://www.lobefin.net/~steve | necktie. -- Attorney General William | || Saxbe | -- msg08630/pgp0.pgp Description: PGP signature
Re: lintian error
Stephen Gran wrote: Hello all, I am sorry to write a question that I think has been answered recently, but I can't find it now. I am getting a lintian error, package-has-a-duplicate-relation xlibs ( 4.1.0), xlibs ( 4.2.0) on one of my packages. I believe this is because of a dependency on both xlibs-dev and kdelibs4, but I'm not sure that removing the dependency on xlibs-dev is the Right Thing to do. I guess I'm just looking for a /var/lib/dpkg/info/xlibs.shlibs: ibICE 6 xlibs ( 4.1.0) libSM 6 xlibs ( 4.1.0) libX11 6 xlibs ( 4.1.0) libXext 6 xlibs ( 4.1.0) libXft 1 xlibs ( 4.1.0) libXi 6 xlibs ( 4.1.0) libXmu 6 xlibs ( 4.1.0) libXmuu 1 xlibs ( 4.1.0) libXp 6 xlibs ( 4.1.0) libXpm 4 xlibs ( 4.1.0) libXrender 1 xlibs ( 4.2.0) libXt 6 xlibs ( 4.1.0) libXtst 6 xlibs ( 4.1.0) libXTrap6 xlibs ( 4.2.0) libXrandr 1 xlibs ( 4.2.0) I just did the following in my rules: [...] dh_shlibdeps # xlibs ( 4.1.0), xlibs ( 4.2.0) is senseless cp debian/kover.substvars debian/kover.substvars.tmp cat debian/kover.substvars.tmp | sed -e s/xlibs ( 4.1.0), // \ debian/kover.substvars rm debian/kover.substvars.tmp dh_gencontrol [...] Regards, Rene -- .''`. Rene Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 msg08631/pgp0.pgp Description: PGP signature
Re: lintian error
This one time, at band camp, Rene Engelhard said: Stephen Gran wrote: Hello all, I am sorry to write a question that I think has been answered recently, but I can't find it now. I am getting a lintian error, package-has-a-duplicate-relation xlibs ( 4.1.0), xlibs ( 4.2.0) on one of my packages. I believe this is because of a dependency on both xlibs-dev and kdelibs4, but I'm not sure that removing the dependency on xlibs-dev is the Right Thing to do. I guess I'm just looking for a /var/lib/dpkg/info/xlibs.shlibs: ibICE 6 xlibs ( 4.1.0) libSM 6 xlibs ( 4.1.0) libX11 6 xlibs ( 4.1.0) libXext 6 xlibs ( 4.1.0) libXft 1 xlibs ( 4.1.0) libXi 6 xlibs ( 4.1.0) libXmu 6 xlibs ( 4.1.0) libXmuu 1 xlibs ( 4.1.0) libXp 6 xlibs ( 4.1.0) libXpm 4 xlibs ( 4.1.0) libXrender 1 xlibs ( 4.2.0) libXt 6 xlibs ( 4.1.0) libXtst 6 xlibs ( 4.1.0) libXTrap6 xlibs ( 4.2.0) libXrandr 1 xlibs ( 4.2.0) I just did the following in my rules: [...] dh_shlibdeps # xlibs ( 4.1.0), xlibs ( 4.2.0) is senseless cp debian/kover.substvars debian/kover.substvars.tmp cat debian/kover.substvars.tmp | sed -e s/xlibs ( 4.1.0), // \ debian/kover.substvars rm debian/kover.substvars.tmp dh_gencontrol [...] Cool. Tht was the kind of thing I was considering doing, but I didn't want to accidentally break something. That'll work for now. Thanks again, -- -- | Stephen Gran | We'll try to cooperate fully with the | | [EMAIL PROTECTED] | IRS, because, as citizens, we feel a| | http://www.lobefin.net/~steve | strong patriotic duty not to go to | || jail. -- Dave Barry | -- msg08632/pgp0.pgp Description: PGP signature
Re: lintian error
On Sun, Feb 16, 2003 at 04:24:39PM +0100, Rene Engelhard wrote: /var/lib/dpkg/info/xlibs.shlibs: ibICE 6 xlibs ( 4.1.0) libSM 6 xlibs ( 4.1.0) libX11 6 xlibs ( 4.1.0) libXext 6 xlibs ( 4.1.0) libXft 1 xlibs ( 4.1.0) libXi 6 xlibs ( 4.1.0) libXmu 6 xlibs ( 4.1.0) libXmuu 1 xlibs ( 4.1.0) libXp 6 xlibs ( 4.1.0) libXpm 4 xlibs ( 4.1.0) libXrender 1 xlibs ( 4.2.0) libXt 6 xlibs ( 4.1.0) libXtst 6 xlibs ( 4.1.0) libXTrap6 xlibs ( 4.2.0) libXrandr 1 xlibs ( 4.2.0) I just did the following in my rules: [...] dh_shlibdeps # xlibs ( 4.1.0), xlibs ( 4.2.0) is senseless cp debian/kover.substvars debian/kover.substvars.tmp cat debian/kover.substvars.tmp | sed -e s/xlibs ( 4.1.0), // \ debian/kover.substvars rm debian/kover.substvars.tmp dh_gencontrol [...] is this a bug in xlibs? -- gram msg08633/pgp0.pgp Description: PGP signature
Re: lintian error
On Sun, Feb 16, 2003 at 10:29:36AM -0600, Graham Wilson wrote: is this a bug in xlibs? No, xlibs speaks the truth. If anything, this is a (minor) bug in dpkg-shlibdeps. To fix this, dpkg-shlibdeps would need to understand when a dependency introduced by one library obsoletes that introduced by another library. At present, I believe it can only tell if they are identical. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lintian error
Hello all, I am sorry to write a question that I think has been answered recently, but I can't find it now. I am getting a lintian error, package-has-a-duplicate-relation xlibs ( 4.1.0), xlibs ( 4.2.0) on one of my packages. I believe this is because of a dependency on both xlibs-dev and kdelibs4, but I'm not sure that removing the dependency on xlibs-dev is the Right Thing to do. I guess I'm just looking for a discussion of the best way to handle this, or a pointer to the previous discussion about it (or did I just imagine it? :) TIA, -- -- | Stephen Gran | If they were so inclined, they could| | [EMAIL PROTECTED] | impeach him because they don't like his | | http://www.lobefin.net/~steve | necktie. -- Attorney General William | || Saxbe | -- pgpstak1Wdtw7.pgp Description: PGP signature
Re: lintian error
Stephen Gran wrote: Hello all, I am sorry to write a question that I think has been answered recently, but I can't find it now. I am getting a lintian error, package-has-a-duplicate-relation xlibs ( 4.1.0), xlibs ( 4.2.0) on one of my packages. I believe this is because of a dependency on both xlibs-dev and kdelibs4, but I'm not sure that removing the dependency on xlibs-dev is the Right Thing to do. I guess I'm just looking for a /var/lib/dpkg/info/xlibs.shlibs: ibICE 6 xlibs ( 4.1.0) libSM 6 xlibs ( 4.1.0) libX11 6 xlibs ( 4.1.0) libXext 6 xlibs ( 4.1.0) libXft 1 xlibs ( 4.1.0) libXi 6 xlibs ( 4.1.0) libXmu 6 xlibs ( 4.1.0) libXmuu 1 xlibs ( 4.1.0) libXp 6 xlibs ( 4.1.0) libXpm 4 xlibs ( 4.1.0) libXrender 1 xlibs ( 4.2.0) libXt 6 xlibs ( 4.1.0) libXtst 6 xlibs ( 4.1.0) libXTrap6 xlibs ( 4.2.0) libXrandr 1 xlibs ( 4.2.0) I just did the following in my rules: [...] dh_shlibdeps # xlibs ( 4.1.0), xlibs ( 4.2.0) is senseless cp debian/kover.substvars debian/kover.substvars.tmp cat debian/kover.substvars.tmp | sed -e s/xlibs ( 4.1.0), // \ debian/kover.substvars rm debian/kover.substvars.tmp dh_gencontrol [...] Regards, Rene -- .''`. Rene Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 pgpdU5TW5mUPF.pgp Description: PGP signature
Re: lintian error
This one time, at band camp, Rene Engelhard said: Stephen Gran wrote: Hello all, I am sorry to write a question that I think has been answered recently, but I can't find it now. I am getting a lintian error, package-has-a-duplicate-relation xlibs ( 4.1.0), xlibs ( 4.2.0) on one of my packages. I believe this is because of a dependency on both xlibs-dev and kdelibs4, but I'm not sure that removing the dependency on xlibs-dev is the Right Thing to do. I guess I'm just looking for a /var/lib/dpkg/info/xlibs.shlibs: ibICE 6 xlibs ( 4.1.0) libSM 6 xlibs ( 4.1.0) libX11 6 xlibs ( 4.1.0) libXext 6 xlibs ( 4.1.0) libXft 1 xlibs ( 4.1.0) libXi 6 xlibs ( 4.1.0) libXmu 6 xlibs ( 4.1.0) libXmuu 1 xlibs ( 4.1.0) libXp 6 xlibs ( 4.1.0) libXpm 4 xlibs ( 4.1.0) libXrender 1 xlibs ( 4.2.0) libXt 6 xlibs ( 4.1.0) libXtst 6 xlibs ( 4.1.0) libXTrap6 xlibs ( 4.2.0) libXrandr 1 xlibs ( 4.2.0) I just did the following in my rules: [...] dh_shlibdeps # xlibs ( 4.1.0), xlibs ( 4.2.0) is senseless cp debian/kover.substvars debian/kover.substvars.tmp cat debian/kover.substvars.tmp | sed -e s/xlibs ( 4.1.0), // \ debian/kover.substvars rm debian/kover.substvars.tmp dh_gencontrol [...] Cool. Tht was the kind of thing I was considering doing, but I didn't want to accidentally break something. That'll work for now. Thanks again, -- -- | Stephen Gran | We'll try to cooperate fully with the | | [EMAIL PROTECTED] | IRS, because, as citizens, we feel a| | http://www.lobefin.net/~steve | strong patriotic duty not to go to | || jail. -- Dave Barry | -- pgpGcQMq9Fy3J.pgp Description: PGP signature
Re: lintian error
On Sun, Feb 16, 2003 at 04:24:39PM +0100, Rene Engelhard wrote: /var/lib/dpkg/info/xlibs.shlibs: ibICE 6 xlibs ( 4.1.0) libSM 6 xlibs ( 4.1.0) libX11 6 xlibs ( 4.1.0) libXext 6 xlibs ( 4.1.0) libXft 1 xlibs ( 4.1.0) libXi 6 xlibs ( 4.1.0) libXmu 6 xlibs ( 4.1.0) libXmuu 1 xlibs ( 4.1.0) libXp 6 xlibs ( 4.1.0) libXpm 4 xlibs ( 4.1.0) libXrender 1 xlibs ( 4.2.0) libXt 6 xlibs ( 4.1.0) libXtst 6 xlibs ( 4.1.0) libXTrap6 xlibs ( 4.2.0) libXrandr 1 xlibs ( 4.2.0) I just did the following in my rules: [...] dh_shlibdeps # xlibs ( 4.1.0), xlibs ( 4.2.0) is senseless cp debian/kover.substvars debian/kover.substvars.tmp cat debian/kover.substvars.tmp | sed -e s/xlibs ( 4.1.0), // \ debian/kover.substvars rm debian/kover.substvars.tmp dh_gencontrol [...] is this a bug in xlibs? -- gram pgpAFTwhJgFea.pgp Description: PGP signature
Re: lintian error
On Sun, Feb 16, 2003 at 10:29:36AM -0600, Graham Wilson wrote: is this a bug in xlibs? No, xlibs speaks the truth. If anything, this is a (minor) bug in dpkg-shlibdeps. To fix this, dpkg-shlibdeps would need to understand when a dependency introduced by one library obsoletes that introduced by another library. At present, I believe it can only tell if they are identical. -- - mdz
