Bug#965018: RFS: freetype-py/2.2.0-1 -- Freetype Python bindings for Python 3
On 2020-08-11 20:07, Drew Parsons wrote: On 2020-08-11 19:48, Bastian Germann wrote: Am 11.08.20 um 12:38 schrieb Drew Parsons:> The diff reports that the [egg_info] section got removed from setup.cfg. ... The uploaded orig file also changed, so be sure to have the current one. That will make a difference, thanks for clarifying. Builds cleanly now, I've uploaded. You'll want to reset the debian/2.2.0-1 tag in the salsa repo I think. Drew
Bug#965018: RFS: freetype-py/2.2.0-1 -- Freetype Python bindings for Python 3
On 2020-08-11 19:48, Bastian Germann wrote: Am 11.08.20 um 12:38 schrieb Drew Parsons:> The diff reports that the [egg_info] section got removed from setup.cfg. ... The uploaded orig file also changed, so be sure to have the current one. That will make a difference, thanks for clarifying. Drew
Bug#965018: RFS: freetype-py/2.2.0-1 -- Freetype Python bindings for Python 3
On 2020-07-29 17:09, Bastian Germann wrote: Am 29.07.20 um 06:10 schrieb Drew Parsons: The python3-setuptools-scm build dependency could not be installed in your environment which causes setuptools to try download this package. That obviously fails. Shouldn't pdebuild make sure that all the build dependencies are installed? Hi Bastian, looks like with the changes fixing the other things, setup.cfg has gotten changed in source dir and so the build tools can't proceed. Now affecting dpkg-buildpackage, not just pdebuild. The diff reports that the [egg_info] section got removed from setup.cfg.
Bug#965018: RFS: freetype-py/2.2.0-1 -- Freetype Python bindings for Python 3
On 2020-08-02 23:10, Drew Parsons wrote: On 2020-07-29 23:45, mat...@debian.org wrote: On Wed, Jul 29, 2020 at 11:09:37AM +0200, Bastian Germann wrote: Shouldn't pdebuild make sure that all the build dependencies are installed? I certainly would have expected it to check build dependencies, just as dpkg-buildpackage does. You are both confusing pdebuild with pbuilder here. That's the `clean` step that is failing, which is done outside of the chroot. That's responsability of whoever is calling `pdebuild` to satisfy. ... It certainly is true that I didn't have python3-setuptools-scm installed. Installing it enables pdebuild to proceed normally. ... I'll file a bug against pbuilder about the pdebuild problem. Actually pdebuild already has the --use-pdebuild-internal option which runs clean inside the chroot. So the freetype-py build can be done with pdebuild this way, without needing to install python3-setuptools-scm on the local host system. A little non-intuitive, but it will do the job for me. Drew
Bug#965018: RFS: freetype-py/2.2.0-1 -- Freetype Python bindings for Python 3
On 2020-07-29 23:45, mat...@debian.org wrote: On Wed, Jul 29, 2020 at 11:09:37AM +0200, Bastian Germann wrote: The python3-setuptools-scm build dependency could not be installed in your environment which causes setuptools to try download this package. That obviously fails. Shouldn't pdebuild make sure that all the build dependencies are installed? I certainly would have expected it to check build dependencies, just as dpkg-buildpackage does. You are both confusing pdebuild with pbuilder here. That's the `clean` step that is failing, which is done outside of the chroot. That's responsability of whoever is calling `pdebuild` to satisfy. If you are sure your source is clean you may as well just skip cleaning and not use pdebuild: dpkg-source -b . dpkg-source --after-build . pbuilder b ../freetype-py_2.2.0-1.dsc the above sequence should prove that nothing is at fault here. But it's more convenient to have the single command pdebuild to use. It certainly is true that I didn't have python3-setuptools-scm installed. Installing it enables pdebuild to proceed normally. As you point out, the problem here is in a clean step performed prior to activating the pbuilder chroot. (I presume python3-setuptools-scm would get installed into the chroot, but pdebuild never reaches that step). It looks to me this is a design flaw in pdebuild itself. It requires build dependencies to be available outside the chroot, which a) somewhat contradicts the entire point of chroot building, and b) doesn't check that those build dependencies are installed anyway. The problem is not in freetype-py. It's already declared python3-setuptools-scm as a Build-Dependency. Bastian, the build proceeds (even with pdebuild) if I have python3-setuptools-scm installed on my normal system (i.e. outside the chroot). That's good enough for a pdebuild build. I notice you've made some edits in the meantime. I think you've fixed lintian warning redundant-globbing-patterns for debian/changelog in commit 4422b3b. But current git no longer builds (even with dpkg-buildpackage) from changes in freetype-py/setup.cfg (removing [egg_info]). Not sure if it's a consequence of 40db38e. Since we've got a workaround for the pdebuild problem, I can upload once you've got it back in action. I'll file a bug against pbuilder about the pdebuild problem. Drew
Bug#965018: RFS: freetype-py/2.2.0-1 -- Freetype Python bindings for Python 3
Hi Bastian, freetype-py builds fine with dpkg-buildpackage, but fails in
chroot (pdebuild pbuilder):
$ pdebuild
dpkg-checkbuilddeps: error: Unmet build dependencies:
python3-setuptools-scm
W: Unmet build-dependency in source
dh clean --with python3 --buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
install -d
/projects/freetype-py/debian/.debhelper/generated/_source/home
pybuild --clean --test-pytest -i python{version} -p 3.8
I: pybuild base:217: python3.8 setup.py clean
# Will use the system-provided FreeType.
Traceback (most recent call last):
File "setup.py", line 103, in
setup(
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line
143, in setup
_install_setup_requires(attrs)
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line
138, in _install_setup_requires
dist.fetch_build_eggs(dist.setup_requires)
File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 695, in
fetch_build_eggs
resolved_dists = pkg_resources.working_set.resolve(
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
781, in resolve
dist = best[req.key] = env.best_match(
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
1066, in best_match
return self.obtain(req, installer)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
1078, in obtain
return installer(requirement)
File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 754, in
fetch_build_egg
return fetch_build_egg(self, req)
File "/usr/lib/python3/dist-packages/setuptools/installer.py", line
83, in fetch_build_egg
raise DistutilsError('the `allow-hosts` option is not supported '
distutils.errors.DistutilsError: the `allow-hosts` option is not
supported when using pip to install requirements.
E: pybuild pybuild:352: clean: plugin distutils failed with: exit
code=1: python3.8 setup.py clean
dh_auto_clean: error: pybuild --clean --test-pytest -i python{version}
-p 3.8 returned exit code 13
make: *** [debian/rules:8: clean] Error 25
Are you able to interpret that error, or do you have a clean chroot to
inspect?
Drew
Re: vtk8
On 2019-10-10 17:21, Nico Schlömer wrote: Hi everyone, I've worked on VTK8 [1] and I think it's about ready to be included into Debian. (More than two years after its release, unfortunately.) There's a PPA with the latest build [2] if you want to try it out. Could anyone take a look? What would be the steps to get it into Debian? Cheers, Nico [1] https://salsa.debian.org/science-team/vtk8 [2] https://launchpad.net/~nschloe/+archive/ubuntu/vtk8/ Hi Nico, Alistair McKinstry has an interest in paraview [3], so cc:ing him to let him know you're interested in VTK. [3] https://lists.debian.org/debian-science/2019/08/msg7.html Drew
Bug#897238: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
On Sat, 2018-05-19 at 10:55 +, Lumin wrote: > On Fri, May 18, 2018 at 11:49:05PM +0800, Drew Parsons wrote: > > > > I wonder if the simplest solution is to just have > > intel-mkl Depends: libblas. i.e. use policy to simply prevent a > > sole > > mkl installation. > > > > That way, the mkl alternative will always have a free BLAS to press > > it's preference against. > > That's exactly a part of the present implementation. > > It depends on libblas3 | libblas.so.3, and enhances libblas.so.3, but > never provides libblas.so.3 . Similar for lapack. It's come together well then. Thanks for your efforts on it, Lumin.
Bug#897238: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
On Sat, 2018-05-12 at 03:22 +, Lumin wrote: > Hi Sébastien, > > > But IMO it's acceptable to not perfectly deal with the > > corner case > > where only MKL is installed, as long as some warning is displayed. > > I insist on removing the Provides, even if it looks weird. For sake > of > debconf correctness, I can't find a better way other than removing > it. ... > As a compromise, let's regard MKL as a "non-free" enhancement to free > BLAS/LAPACK implementations. An Enhances: field should be nice for > us, > which alleviates the discomfort of leaving Provides: blank. I wonder if the simplest solution is to just have intel-mkl Depends: libblas. i.e. use policy to simply prevent a sole mkl installation. That way, the mkl alternative will always have a free BLAS to press it's preference against. Drew
Bug#897238: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
On Sun, 2018-05-06 at 10:13 +0200, Sébastien Villemot wrote: > > Yes, but it’s the GPL that forbids distribution of a binary linking > together > GPL code and non-free code. But we're not distributing GPL binaries for use with nonfree MKL, we're distributing them to use with OpenBLAS or ATLAS. If the user then installs MKL and GPL software on it, then that's their responsibility. And they're allowed to, so long as they don't distribute it that way. Drew
Re: OpenMPI-bin missing on some arches (Was: mrbayes-mpi: uninstallable on mipsen and s390)
On Wed, 2011-06-29 at 15:01 +0200, Andreas Tille wrote:
> Hi,
>
> > Your package is uninstallable on some archs:
> >
> >mrbayes-mpi/mips unsatisfiable Depends: openmpi-bin
> >mrbayes-mpi/mipsel unsatisfiable Depends: openmpi-bin
> >mrbayes-mpi/s390 unsatisfiable Depends: openmpi-bin
>
> I admit I'm not so comfortable with these architectures. Is there any
> drop-in replacement for openmpi on these and if yes, what do I need to
> specify in debian/{control,rules}? Could any other package with the
> same problem serve as an example?
>
Try mpich2, or better still use mpi-defaults (mpi-defaults-dev).
mpi-defaults is a dummy package that pulls in what we deem to be the
most reliable mpi implementation for the architecture, which on those
arches is mpich2 not openmpi. lam4 is an alternate option, it was
previously the mpi-default but is currently being deprecated in favour
of mpich2.
Hope that helps,
Drew
--
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/1309353540.928.48.camel@pug
Re: latex build problem
On Fri, Dec 27, 2002 at 12:23:03AM -0800, Osamu Aoki wrote:
> Hi,
>
> latex source is in my people.debian.org/~osamu/pub/
> Please check reference.it.tex
>
> Osamu
>
> On Wed, Dec 25, 2002 at 05:44:16PM -0800, Osamu Aoki wrote:
> > I encounter errors in latex when building PS file (or PDF file).
> >
> > I do not understand "(\end occurred inside a group at level 31)"
> >
As I understand it, this error message means that a \begin tag (or its
equivalent) has not been correctly closed, or something similar to that.
Compare to the HTML:
with no , , . The "end" () is met while at level 3.
Look carefully at the output for the rest of your file, don't let it compile
automatically, let it run manually so you catch each error message in turn.
The accented character ("è) on l. 3962 and elsewherecauses me trouble,
but I don't have a full italian locale set up. It get processed with the
error message
! Extra \fi.
which would seem to upset the count of your "level".
Likewise there are a lot of
! Missing $ inserted.
$
l.3976 e la shell di root. Siccome, però
\file{ /} è montata in sola
Here the accented character "ò "is getting mixed up with a maths command,
further confusing the level count.
So, I recommend you look at how you're handling the handling of the italian
non-ASCII characters. TeX was originally ASCII based, with accented letters
created with \`{e} or \`{o} etc. You need to be careful with your setup to
handle them directly as non-ASCII characters.
The frontmatter of your file has
\usepackage[latin1]{inputenc}
\usepackage[T1]{fontenc}
which is what I expect needs to be done to handle the letters, but it would
seem something has gone wrong regardless (unless it's just the fact that my
system is not set up properly for an italian locale).
You can also check the syntax of your file in emacs, in LaTeX mode, using
the "validate buffer" function. Sometimes you have to take this test with a
grain of salt, but for what it's worth, it gives:
Mismatches:
7174: \begin{enumerate}
7227: \end{enumerate}
7242: \textemdash{} \textbf{English in Denmark} che è un pò uno scherzo :-)
7287: \begin{itemize}
7422: \end{itemize}
7459: potreste ancora volerlo :-)
7687: come me :) Vedere X client' \vpageref{s-xclnt}.
7731: dare i seguenti comandi:
\texttt{qii\textless{}i\textgreater{}\textasciicircum{}[ea\textless{}/i\textgreater{}\textasciicircum{}[q}
(dove
7799:Marca la posizione del cursore: C-@ m\{a-zA-Z\}
8166:\{add|ad|new\} [-k kflag] [-m 'message'] files...
8234:if [ \$\{n1:0:1\} != "\#" ]; then
8263:BEGIN \{
8313:while (\textless{}STDIN\textgreater{}) \{
8477:int main(int argc, char **argv, char **envp)\{
8533: \begin{itemize}
8544: \end{itemize}
8700:\$ gpg \{--armor|-a\} \{--sign|-s\} file \# firma un file in un
file testo
8732: | awk '\{print \$2\}' | sort -u | xargs gpg --recv-keys \# prende
le chiavi
8766: disposizione :) (Conoscete tutti l'acronimo RTFM, vero?)
8780: \begin{itemize}
8785: \begin{itemize}
8802: \end{itemize}
8807: \begin{itemize}
8827: \end{itemize}
8832: \begin{itemize}
8846: \end{itemize}
8851: \begin{itemize}
8866: \end{itemize}
8871: \begin{itemize}
8885: \end{itemize}
8890: \begin{itemize}
8898: \end{itemize}
8903: \begin{itemize}
8915: \end{itemize}
8920: \begin{itemize}
8931: \end{itemize}
8936: \begin{itemize}
8941: \end{itemize}
8946: \begin{itemize}
8951: \end{itemize}
8956: \begin{itemize}
8961: \end{itemize}
8966: \begin{itemize}
8971: \end{itemize}
8976: \begin{itemize}
8990: \end{itemize}
8995: \begin{itemize}
9003: \end{itemize}
9008: \begin{itemize}
9019: \end{itemize}
9024: \begin{itemize}
9027: Nessuno può contestarlo :-)
9032: \end{itemize}
9034: \end{itemize}
9104: \begin{itemize}
9121: \end{itemize}
9132: \begin{itemize}
9143: \end{itemize}
9147: \begin{itemize}
9182: \end{itemize}
9206: \begin{itemize}
9211: \begin{itemize}
9216: \end{itemize}
9221: \begin{itemize}
9232: \end{itemize}
9237: \begin{itemize}
9253: \end{itemize}
9258: \begin{itemize}
9263: \end{itemize}
9265: \end{itemize}
9273: \begin{itemize}
9298: \end{itemize}
9311: \begin{itemize}
9331: memoria traballante dei suoi autori. :-)
9333: \end{itemize}
9418: \end{document}
Do all those \begin and \end{itemize} match up?
Drew
--
PGP public key available at http://people.debian.org/~dparsons/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
pgpVi95b2GTVo.pgp
Description: PGP signature
Re: latex build problem
On Fri, Dec 27, 2002 at 12:23:03AM -0800, Osamu Aoki wrote:
> Hi,
>
> latex source is in my people.debian.org/~osamu/pub/
> Please check reference.it.tex
>
> Osamu
>
> On Wed, Dec 25, 2002 at 05:44:16PM -0800, Osamu Aoki wrote:
> > I encounter errors in latex when building PS file (or PDF file).
> >
> > I do not understand "(\end occurred inside a group at level 31)"
> >
As I understand it, this error message means that a \begin tag (or its
equivalent) has not been correctly closed, or something similar to that.
Compare to the HTML:
with no , , . The "end" () is met while at level 3.
Look carefully at the output for the rest of your file, don't let it compile
automatically, let it run manually so you catch each error message in turn.
The accented character ("è) on l. 3962 and elsewherecauses me trouble,
but I don't have a full italian locale set up. It get processed with the
error message
! Extra \fi.
which would seem to upset the count of your "level".
Likewise there are a lot of
! Missing $ inserted.
$
l.3976 e la shell di root. Siccome, però
\file{ /} è montata in sola
Here the accented character "ò "is getting mixed up with a maths command,
further confusing the level count.
So, I recommend you look at how you're handling the handling of the italian
non-ASCII characters. TeX was originally ASCII based, with accented letters
created with \`{e} or \`{o} etc. You need to be careful with your setup to
handle them directly as non-ASCII characters.
The frontmatter of your file has
\usepackage[latin1]{inputenc}
\usepackage[T1]{fontenc}
which is what I expect needs to be done to handle the letters, but it would
seem something has gone wrong regardless (unless it's just the fact that my
system is not set up properly for an italian locale).
You can also check the syntax of your file in emacs, in LaTeX mode, using
the "validate buffer" function. Sometimes you have to take this test with a
grain of salt, but for what it's worth, it gives:
Mismatches:
7174: \begin{enumerate}
7227: \end{enumerate}
7242: \textemdash{} \textbf{English in Denmark} che è un pò uno scherzo :-)
7287: \begin{itemize}
7422: \end{itemize}
7459: potreste ancora volerlo :-)
7687: come me :) Vedere X client' \vpageref{s-xclnt}.
7731: dare i seguenti comandi:
\texttt{qii\textless{}i\textgreater{}\textasciicircum{}[ea\textless{}/i\textgreater{}\textasciicircum{}[q}
(dove
7799:Marca la posizione del cursore: C-@ m\{a-zA-Z\}
8166:\{add|ad|new\} [-k kflag] [-m 'message'] files...
8234:if [ \$\{n1:0:1\} != "\#" ]; then
8263:BEGIN \{
8313:while (\textless{}STDIN\textgreater{}) \{
8477:int main(int argc, char **argv, char **envp)\{
8533: \begin{itemize}
8544: \end{itemize}
8700:\$ gpg \{--armor|-a\} \{--sign|-s\} file \# firma un file in un
file testo
8732: | awk '\{print \$2\}' | sort -u | xargs gpg --recv-keys \# prende
le chiavi
8766: disposizione :) (Conoscete tutti l'acronimo RTFM, vero?)
8780: \begin{itemize}
8785: \begin{itemize}
8802: \end{itemize}
8807: \begin{itemize}
8827: \end{itemize}
8832: \begin{itemize}
8846: \end{itemize}
8851: \begin{itemize}
8866: \end{itemize}
8871: \begin{itemize}
8885: \end{itemize}
8890: \begin{itemize}
8898: \end{itemize}
8903: \begin{itemize}
8915: \end{itemize}
8920: \begin{itemize}
8931: \end{itemize}
8936: \begin{itemize}
8941: \end{itemize}
8946: \begin{itemize}
8951: \end{itemize}
8956: \begin{itemize}
8961: \end{itemize}
8966: \begin{itemize}
8971: \end{itemize}
8976: \begin{itemize}
8990: \end{itemize}
8995: \begin{itemize}
9003: \end{itemize}
9008: \begin{itemize}
9019: \end{itemize}
9024: \begin{itemize}
9027: Nessuno può contestarlo :-)
9032: \end{itemize}
9034: \end{itemize}
9104: \begin{itemize}
9121: \end{itemize}
9132: \begin{itemize}
9143: \end{itemize}
9147: \begin{itemize}
9182: \end{itemize}
9206: \begin{itemize}
9211: \begin{itemize}
9216: \end{itemize}
9221: \begin{itemize}
9232: \end{itemize}
9237: \begin{itemize}
9253: \end{itemize}
9258: \begin{itemize}
9263: \end{itemize}
9265: \end{itemize}
9273: \begin{itemize}
9298: \end{itemize}
9311: \begin{itemize}
9331: memoria traballante dei suoi autori. :-)
9333: \end{itemize}
9418: \end{document}
Do all those \begin and \end{itemize} match up?
Drew
--
PGP public key available at http://people.debian.org/~dparsons/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
msg08182/pgp0.pgp
Description: PGP signature
Re: Which compiler
On Tue, Nov 05, 2002 at 05:03:24PM +0100, Bas Zoetekouw wrote: > Hi Bob! > > You wrote: > > > For the 1386 architecture, sid has gcc 2:2.95.4-17 and gcc-3.0 > > 1:3.0.4-13. Which compiler should be used for an Architecture: any > > package? > > The default one for the architecture in question. > And default compilers for your local architecture are listed in /usr/share/doc/gcc/README.Debian. For i386: cpp - cpp-2.95.4(package cpp-2.95) gcc - gcc-2.95.4(package gcc-2.95) g++ - g++-2.95.4(package g++-2.95) g77 - g77-2.95.4(package g77-2.95) gcj - gcj-3.0.4 (package gcj-3.0) gij - gij-3.0.4 (package gij-3.0) gobjc - gcc-2.95.4(package gobjc-2.95) gpc - gpc-2.95.4(package gpc-2.95) chill - chill-2.95.4 (package chill-2.95) I don't know where the corresponding list for all architectures is. But the plan is to move all architectures to gcc-3.2 for sarge. I don't know why this hasn't happened already. Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: Which compiler
On Tue, Nov 05, 2002 at 05:03:24PM +0100, Bas Zoetekouw wrote: > Hi Bob! > > You wrote: > > > For the 1386 architecture, sid has gcc 2:2.95.4-17 and gcc-3.0 > > 1:3.0.4-13. Which compiler should be used for an Architecture: any > > package? > > The default one for the architecture in question. > And default compilers for your local architecture are listed in /usr/share/doc/gcc/README.Debian. For i386: cpp - cpp-2.95.4(package cpp-2.95) gcc - gcc-2.95.4(package gcc-2.95) g++ - g++-2.95.4(package g++-2.95) g77 - g77-2.95.4(package g77-2.95) gcj - gcj-3.0.4 (package gcj-3.0) gij - gij-3.0.4 (package gij-3.0) gobjc - gcc-2.95.4(package gobjc-2.95) gpc - gpc-2.95.4(package gpc-2.95) chill - chill-2.95.4 (package chill-2.95) I don't know where the corresponding list for all architectures is. But the plan is to move all architectures to gcc-3.2 for sarge. I don't know why this hasn't happened already. Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Some problems with automake/autoconf
On Thu, Oct 24, 2002 at 01:50:29PM -0400, Stephen Gran wrote:
> Hello all,
>
> I am having a problem with one of my packages failing on s390. It
> builds fine on other architectures (except where I messed up with a bad
> build-depends on a build-essential). The problem with s390 is here:
>
> # Add here commands to configure the package.
> ./configure --host=s390-linux --build=s390-linux \
> --prefix=/usr --mandir=\${prefix}/share/man --exec-prefix=/usr\
>
> checking host system type... Invalid configuration `s390-linux': machine
> `s390' not recognized
>
Why do you have to specify host like that? The whole point of using
configure is so you don't have to do that, configure determines it
automatically, not so?
Drew
--
PGP public key available at http://people.debian.org/~dparsons/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
pgp64V2m5LIY7.pgp
Description: PGP signature
Re: Some problems with automake/autoconf
On Thu, Oct 24, 2002 at 01:50:29PM -0400, Stephen Gran wrote:
> Hello all,
>
> I am having a problem with one of my packages failing on s390. It
> builds fine on other architectures (except where I messed up with a bad
> build-depends on a build-essential). The problem with s390 is here:
>
> # Add here commands to configure the package.
> ./configure --host=s390-linux --build=s390-linux \
> --prefix=/usr --mandir=\${prefix}/share/man --exec-prefix=/usr\
>
> checking host system type... Invalid configuration `s390-linux': machine `s390' not
>recognized
>
Why do you have to specify host like that? The whole point of using
configure is so you don't have to do that, configure determines it
automatically, not so?
Drew
--
PGP public key available at http://people.debian.org/~dparsons/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
msg07552/pgp0.pgp
Description: PGP signature
Re: Build-failures
On Sun, Oct 20, 2002 at 09:54:46AM -0400, Stephen Gran wrote: > > This is on alpha and ia64. I vaguely remember seeing some problem with > using libc6 as a Build-Depend (something like libc6 | libc ?) - I just > can't remember, and as I have no access to one of these boxes, I would > appreciate a smack with a cluebat, please. > libc6 is a essential package, so you shouldn't need to mention it Build-Depends unless you depend on one specific version. Get rid of it and see if that helps. Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A pgpVLu4AJxSEl.pgp Description: PGP signature
Re: How to force porters to rebuild a package
On Thu, Oct 17, 2002 at 11:05:59PM +0200, Stefan Schwandter wrote: > Drew Parsons wrote: > > > And more to the point [ ;) ], how do I force the autobuilder maintainers to > > actually upload my package once it has been autobuilt? > > > The s390 version of xprint-xprintorg has been built for a whole week now[1], > > but it still hasn't been uploaded to the archive[2]. All other > > architectures have been uploaded. > > I don't think you will be able to _force_ anybody to anything. Yes I know, hence the smiley ;) But you > could ask the porters (by writing to the mailing list of the particular > port, for example) if too much time has passed (say, some weeks), to > have a look at your problem. > Yep, I've done that now. Thanks, Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: How to force porters to rebuild a package
On Thu, Oct 17, 2002 at 11:05:59PM +0200, Stefan Schwandter wrote: > Drew Parsons wrote: > > > And more to the point [ ;) ], how do I force the autobuilder maintainers to > > actually upload my package once it has been autobuilt? > > > The s390 version of xprint-xprintorg has been built for a whole week now[1], > > but it still hasn't been uploaded to the archive[2]. All other > > architectures have been uploaded. > > I don't think you will be able to _force_ anybody to anything. Yes I know, hence the smiley ;) But you > could ask the porters (by writing to the mailing list of the particular > port, for example) if too much time has passed (say, some weeks), to > have a look at your problem. > Yep, I've done that now. Thanks, Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to force porters to rebuild a package
On Thu, Oct 17, 2002 at 11:44:14AM +0200, Marco Kuhlmann wrote: > > How do I force a rebuild on buildd? And more to the point [ ;) ], how do I force the autobuilder maintainers to actually upload my package once it has been autobuilt? The s390 version of xprint-xprintorg has been built for a whole week now[1], but it still hasn't been uploaded to the archive[2]. All other architectures have been uploaded. Drew [1] http://buildd.debian.org/build.php?pkg=xprint-xprintorg [2] http://ftp.debian.org/debian/pool/main/x/xprint-xprintorg/ -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A pgp3Td8o86npm.pgp Description: PGP signature
Re: How to force porters to rebuild a package
On Thu, Oct 17, 2002 at 11:44:14AM +0200, Marco Kuhlmann wrote: > > How do I force a rebuild on buildd? And more to the point [ ;) ], how do I force the autobuilder maintainers to actually upload my package once it has been autobuilt? The s390 version of xprint-xprintorg has been built for a whole week now[1], but it still hasn't been uploaded to the archive[2]. All other architectures have been uploaded. Drew [1] http://buildd.debian.org/build.php?pkg=xprint-xprintorg [2] http://ftp.debian.org/debian/pool/main/x/xprint-xprintorg/ -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A msg07585/pgp0.pgp Description: PGP signature
Re: stripping binaries...must we?
On Tue, Oct 15, 2002 at 10:24:05AM -0600, Bob Proulx wrote: > Drew Parsons <[EMAIL PROTECTED]> [2002-10-14 00:41:49 +1000]: > > OK, I'll try to remember to restrip for sarge :) > > Perhaps the BTS could be a help in remembering this? > > Bob Good idea :) Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: stripping binaries...must we?
On Tue, Oct 15, 2002 at 10:24:05AM -0600, Bob Proulx wrote: > Drew Parsons <[EMAIL PROTECTED]> [2002-10-14 00:41:49 +1000]: > > OK, I'll try to remember to restrip for sarge :) > > Perhaps the BTS could be a help in remembering this? > > Bob Good idea :) Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: stripping binaries...must we?
On Sun, Oct 13, 2002 at 10:09:00AM -0400, Colin Walters wrote: > > But to answer your specific question, I don't see it as a big deal if > you ship unstripped binaries in a package in unstable for a while. I > think the important part is providing stripped binaries for sarge; so > just be sure to upload a stripped package before sarge releases. > OK, I'll try to remember to restrip for sarge :) Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: stripping binaries...must we?
On Sun, Oct 13, 2002 at 10:30:35AM +0200, Bas Zoetekouw wrote: > > > Could someone please clarify if it's appropriate to respect upstream's > > wishes to leave the symbols in? > > Sure. It's only a "should" in policy, not a "must", so it's ok not to > strip. > OK, I guess I'll pack 'em back in with my next upload then. Jög: yeah, I thought about adding a -dbg version, but the way I see it it'd be more trouble than it's worth, and wouldn't help with the goal of keeping the archive size. I gather upstream only wants the symbols left in the short term, since it's a relatively new piece of software. After we've passed a couple of version, he'll probably be happy to strip again. Thanks, Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A pgp9SCbpwPKfG.pgp Description: PGP signature
Re: stripping binaries...must we?
On Sun, Oct 13, 2002 at 10:09:00AM -0400, Colin Walters wrote: > > But to answer your specific question, I don't see it as a big deal if > you ship unstripped binaries in a package in unstable for a while. I > think the important part is providing stripped binaries for sarge; so > just be sure to upload a stripped package before sarge releases. > OK, I'll try to remember to restrip for sarge :) Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: stripping binaries...must we?
On Sun, Oct 13, 2002 at 10:30:35AM +0200, Bas Zoetekouw wrote: > > > Could someone please clarify if it's appropriate to respect upstream's > > wishes to leave the symbols in? > > Sure. It's only a "should" in policy, not a "must", so it's ok not to > strip. > OK, I guess I'll pack 'em back in with my next upload then. Jög: yeah, I thought about adding a -dbg version, but the way I see it it'd be more trouble than it's worth, and wouldn't help with the goal of keeping the archive size. I gather upstream only wants the symbols left in the short term, since it's a relatively new piece of software. After we've passed a couple of version, he'll probably be happy to strip again. Thanks, Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A msg07474/pgp0.pgp Description: PGP signature
stripping binaries...must we?
Policy says binaries "should" (not "must") be stripped: http://www.debian.org/doc/debian-policy/ch-files.html#s11.1 "Note that by default all installed binaries should be stripped, either by using the -s flag to install, or by calling strip on the binaries after they have been copied into debian/tmp but before the tree is made into a package." The upstream author of my new package xprint-xprintorg (upstream http://xprint.mozdev.org/) has requested (upstream bug http://mozdev.org/bugs/show_bug.cgi?id=2264) that I don't strip the symbols out, a least for the first few releases, so we can get useful bug reports, noting that coredumps are not very useful without them. He comments: Xprt without symbols consumes 1545084 bytes Xprt withsymbols consumes 1744827 bytes so there's not a huge difference in installed size by retaining the symbols, and an even smaller difference in the compressed packages. Why does policy ask us to strip binaries anyway? Is it merely to reduce storage and bandwidth costs? Could someone please clarify if it's appropriate to respect upstream's wishes to leave the symbols in? Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A pgpQfXcGI70zZ.pgp Description: PGP signature
stripping binaries...must we?
Policy says binaries "should" (not "must") be stripped: http://www.debian.org/doc/debian-policy/ch-files.html#s11.1 "Note that by default all installed binaries should be stripped, either by using the -s flag to install, or by calling strip on the binaries after they have been copied into debian/tmp but before the tree is made into a package." The upstream author of my new package xprint-xprintorg (upstream http://xprint.mozdev.org/) has requested (upstream bug http://mozdev.org/bugs/show_bug.cgi?id=2264) that I don't strip the symbols out, a least for the first few releases, so we can get useful bug reports, noting that coredumps are not very useful without them. He comments: Xprt without symbols consumes 1545084 bytes Xprt withsymbols consumes 1744827 bytes so there's not a huge difference in installed size by retaining the symbols, and an even smaller difference in the compressed packages. Why does policy ask us to strip binaries anyway? Is it merely to reduce storage and bandwidth costs? Could someone please clarify if it's appropriate to respect upstream's wishes to leave the symbols in? Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A msg07576/pgp0.pgp Description: PGP signature
Re: dh_builddeb error - why?
On Sun, Sep 08, 2002 at 06:27:05PM -0400, Joey Hess wrote:
>
> > So dh_builddeb just says the command returned an error code, without
> > specifying which command (dpkg-deb?) or which error.
>
> Run dh_buildeb -v to get the command it is running, you should then be
> able to reproduce it manually by running that command and track it down
> from there.
>
Thanks Joey. -v says the problem is with the second binary package
(strange, it just stopped on the first before):
...
dh_builddeb -v
dpkg --build debian/xprt-xprintorg ..
dpkg-deb: building package xprt-xprintorg' in ../xprt-xprintorg_0.0.7.cvs20020
903-1_ia64.deb'.
dpkg --build debian/xprt-common ..
dh_builddeb: command returned error code
make: *** [binary-arch] Error 1
Then, if I run dpkg --build debian/xprt-common from the command line, dpkg
segfaults:
$ fakeroot dpkg --build debian/xprt-common
dpkg-deb: building package xprt-common' in debian/xprt-common.deb'.
/usr/bin/fakeroot: line 84: 19648 Segmentation fault
FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH=$PATHS LD_PRELOAD=$LIB sh -c "$*"
(it seems to run at the moment with xprt-xprintorg, the 1st binary package).
Could this be an ia64-specific bug in dpkg? dpkg on merulo is v1.10.7, so
the problem doesn't seem to be the same as the dpkg de-configuring segfault
fixed recently (bug #115389 etc)
I've attached the strace
(strace -o ../strace.out fakeroot dpkg --build debian/xprt-common)
Drew
--
PGP public key available at http://people.debian.org/~dparsons/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
execve("/usr/bin/fakeroot", ["fakeroot", "dpkg", "--build",
"debian/xprt-common"], [/* 15 vars */]) = 0
uname({sys="Linux", node="merulo", ...}) = 0
brk(0) = 0x6001bc60
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
SYS_1212(0x3, 0x6fffae60, 0, 0, 0, 0, 0, 0) = 0
mmap(NULL, 55637, PROT_READ, MAP_PRIVATE, 3, 0) = 0x20044000
close(3)= 0
open("/lib/libncurses.so.5", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0002\0\1\0\0\0 6\2\0"..., 1024) =
1024
SYS_1212(0x3, 0x6fffae60, 0, 0, 0, 0, 0, 0) = 0
mmap(NULL, 653648, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x20054000
mprotect(0x200d8000, 112976, PROT_NONE) = 0
mmap(0x200e4000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x9) = 0x200e4000
close(3)= 0
open("/lib/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0002\0\1\0\0\0\2404\0"..., 1024) =
1024
SYS_1212(0x3, 0x6fffae30, 0, 0, 0, 0, 0, 0) = 0
mmap(NULL, 83264, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x200f4000
mprotect(0x200f8000, 66880, PROT_NONE) = 0
mmap(0x20104000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0) = 0x20104000
close(3)= 0
open("/lib/libc.so.6.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0002\0\1\0\0\0ph\3\0"..., 1024) =
1024
SYS_1212(0x3, 0x6fffae00, 0, 0, 0, 0, 0, 0) = 0
mmap(NULL, 2508656, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2010c000
mprotect(0x20354000, 116592, PROT_NONE) = 0
mmap(0x2035c000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x24) = 0x2035c000
mmap(0x2036c000, 18288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2036c000
close(3)= 0
mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2003
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x20038000
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x20374000
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x20378000
munmap(0x20044000, 55637) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
open("/dev/tty", O_RDWR|O_NONBLOCK) = 3
close(3)= 0
brk(0) = 0x6001bc60
brk(0x6001c000) = 0x6001c000
brk(0x6002) = 0x6002
getuid()= 2097
getgid()= 800
geteuid() = 2097
getegid() = 800
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
gettimeofday({1031575560, 586756}, NULL) = 0
brk(0x60024000) = 0x60024000
open("/etc/mtab", O_RDONLY) = 3
SYS_1212(0x3, 0x6fff9220, 0x6fffad00, 0, 0x200407b0,
0x2036b054, 0x20041750, 0x20043428) = 0
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x20044000
read(3, "/dev/sda3
Re: dh_builddeb error - why?
On Sun, Sep 08, 2002 at 06:27:05PM -0400, Joey Hess wrote:
>
> > So dh_builddeb just says the command returned an error code, without
> > specifying which command (dpkg-deb?) or which error.
>
> Run dh_buildeb -v to get the command it is running, you should then be
> able to reproduce it manually by running that command and track it down
> from there.
>
Thanks Joey. -v says the problem is with the second binary package
(strange, it just stopped on the first before):
...
dh_builddeb -v
dpkg --build debian/xprt-xprintorg ..
dpkg-deb: building package xprt-xprintorg' in ../xprt-xprintorg_0.0.7.cvs20020
903-1_ia64.deb'.
dpkg --build debian/xprt-common ..
dh_builddeb: command returned error code
make: *** [binary-arch] Error 1
Then, if I run dpkg --build debian/xprt-common from the command line, dpkg
segfaults:
$ fakeroot dpkg --build debian/xprt-common
dpkg-deb: building package xprt-common' in debian/xprt-common.deb'.
/usr/bin/fakeroot: line 84: 19648 Segmentation fault
FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH=$PATHS LD_PRELOAD=$LIB sh -c "$*"
(it seems to run at the moment with xprt-xprintorg, the 1st binary package).
Could this be an ia64-specific bug in dpkg? dpkg on merulo is v1.10.7, so
the problem doesn't seem to be the same as the dpkg de-configuring segfault
fixed recently (bug #115389 etc)
I've attached the strace
(strace -o ../strace.out fakeroot dpkg --build debian/xprt-common)
Drew
--
PGP public key available at http://people.debian.org/~dparsons/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
execve("/usr/bin/fakeroot", ["fakeroot", "dpkg", "--build", "debian/xprt-common"], [/*
15 vars */]) = 0
uname({sys="Linux", node="merulo", ...}) = 0
brk(0) = 0x6001bc60
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
SYS_1212(0x3, 0x6fffae60, 0, 0, 0, 0, 0, 0) = 0
mmap(NULL, 55637, PROT_READ, MAP_PRIVATE, 3, 0) = 0x20044000
close(3)= 0
open("/lib/libncurses.so.5", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0002\0\1\0\0\0 6\2\0"..., 1024) = 1024
SYS_1212(0x3, 0x6fffae60, 0, 0, 0, 0, 0, 0) = 0
mmap(NULL, 653648, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x20054000
mprotect(0x200d8000, 112976, PROT_NONE) = 0
mmap(0x200e4000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x9) = 0x200e4000
close(3)= 0
open("/lib/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0002\0\1\0\0\0\2404\0"..., 1024) = 1024
SYS_1212(0x3, 0x6fffae30, 0, 0, 0, 0, 0, 0) = 0
mmap(NULL, 83264, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x200f4000
mprotect(0x200f8000, 66880, PROT_NONE) = 0
mmap(0x20104000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0x20104000
close(3)= 0
open("/lib/libc.so.6.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0002\0\1\0\0\0ph\3\0"..., 1024) = 1024
SYS_1212(0x3, 0x6fffae00, 0, 0, 0, 0, 0, 0) = 0
mmap(NULL, 2508656, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2010c000
mprotect(0x20354000, 116592, PROT_NONE) = 0
mmap(0x2035c000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x24) = 0x2035c000
mmap(0x2036c000, 18288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2036c000
close(3)= 0
mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2003
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x20038000
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x20374000
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x20378000
munmap(0x20044000, 55637) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
open("/dev/tty", O_RDWR|O_NONBLOCK) = 3
close(3)= 0
brk(0) = 0x6001bc60
brk(0x6001c000) = 0x6001c000
brk(0x6002) = 0x6002
getuid()= 2097
getgid()= 800
geteuid() = 2097
getegid() = 800
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
gettimeofday({1031575560, 586756}, NULL) = 0
brk(0x60024000) = 0x60024000
open("/etc/mtab", O_RDONLY) = 3
SYS_1212(0x3, 0x6fff9220, 0x6fffad00, 0, 0x200407b0,
0x2036b054, 0x20041750, 0x20043428) = 0
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x20044000
read(3, "/dev/sda3
dh_builddeb error - why?
I'm getting an error from dh_builddeb when trying to build a new package.
The build was working previously, but today it started failing, and doesn't
really say why. Are there any known problem with dh_builddeb?
The relevant part of the log (from fakeroot debian/rules binary), building
the deb package after an apparently successful source build, looks like:
dh_testdir
dh_testroot
dh_install
dh_installdocs -p xprt-common
dh_installman
dh_installchangelogs -p xprt-common
dh_link
dh_strip
dh_compress
dh_fixperms
dh_installdeb
dh_shlibdeps
dh_gencontrol
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
dh_md5sums
dh_builddeb
dpkg-deb: building package xprt-xprintorg' in ../xprt-xprintorg_0.0.7.cvs20020
903-1_ia64.deb'.
dh_builddeb: command returned error code
make: *** [binary-arch] Error 1
So dh_builddeb just says the command returned an error code, without
specifying which command (dpkg-deb?) or which error.
Could this be another perl 5.8 problem?
I'm compiling on merulo.debian.org, ia64 running unstable.
Drew
--
PGP public key available at http://people.debian.org/~dparsons/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
pgpeoRB8qUtaQ.pgp
Description: PGP signature
dh_builddeb error - why?
I'm getting an error from dh_builddeb when trying to build a new package.
The build was working previously, but today it started failing, and doesn't
really say why. Are there any known problem with dh_builddeb?
The relevant part of the log (from fakeroot debian/rules binary), building
the deb package after an apparently successful source build, looks like:
dh_testdir
dh_testroot
dh_install
dh_installdocs -p xprt-common
dh_installman
dh_installchangelogs -p xprt-common
dh_link
dh_strip
dh_compress
dh_fixperms
dh_installdeb
dh_shlibdeps
dh_gencontrol
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
dh_md5sums
dh_builddeb
dpkg-deb: building package xprt-xprintorg' in ../xprt-xprintorg_0.0.7.cvs20020
903-1_ia64.deb'.
dh_builddeb: command returned error code
make: *** [binary-arch] Error 1
So dh_builddeb just says the command returned an error code, without
specifying which command (dpkg-deb?) or which error.
Could this be another perl 5.8 problem?
I'm compiling on merulo.debian.org, ia64 running unstable.
Drew
--
PGP public key available at http://people.debian.org/~dparsons/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
msg07102/pgp0.pgp
Description: PGP signature
Re: Looking for sponsor for single upload of zangband
On Wed, Sep 04, 2002 at 08:19:36PM -0700, Zack Weinberg wrote: > Hi, > > I've re-done the zangband package, intending to fix bug #159039 which > makes the game completely unplayable, but in the process I fixed a > bunch more (all but #141684, I believe). > > I do not have the time to become a Debian developer, but if someone > would like to check my work and upload the fixed package for me, that > would be nifty. The source and i386 binary are available at > http://www.panix.com/~zackw/deb/ - hopefully apt-able, but I'm not > sure I did that bit right. > > Eric is listed as the maintainer of zangband, but he has not done > anything with the package since 2000. > > Please cc: me on responses, I am not subscribed to debian-mentors. > Thanks for the hard work, Zack. Have you tried writing to Brian Nelson? [EMAIL PROTECTED] (or maybe [EMAIL PROTECTED]). Since he did the last NMUs, I figure he's the best person to upload the fixed package (he can clean up his own mess, so to speak). If he doesn't respond, then I guess I can upload it. I reported Bug #159039. Thanks again for fixing it. It's a great little game :) Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A pgp2afDcJ5fvT.pgp Description: PGP signature
Re: Looking for sponsor for single upload of zangband
On Wed, Sep 04, 2002 at 08:19:36PM -0700, Zack Weinberg wrote: > Hi, > > I've re-done the zangband package, intending to fix bug #159039 which > makes the game completely unplayable, but in the process I fixed a > bunch more (all but #141684, I believe). > > I do not have the time to become a Debian developer, but if someone > would like to check my work and upload the fixed package for me, that > would be nifty. The source and i386 binary are available at > http://www.panix.com/~zackw/deb/ - hopefully apt-able, but I'm not > sure I did that bit right. > > Eric is listed as the maintainer of zangband, but he has not done > anything with the package since 2000. > > Please cc: me on responses, I am not subscribed to debian-mentors. > Thanks for the hard work, Zack. Have you tried writing to Brian Nelson? [EMAIL PROTECTED] (or maybe [EMAIL PROTECTED]). Since he did the last NMUs, I figure he's the best person to upload the fixed package (he can clean up his own mess, so to speak). If he doesn't respond, then I guess I can upload it. I reported Bug #159039. Thanks again for fixing it. It's a great little game :) Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A msg07096/pgp0.pgp Description: PGP signature
Re: Installing documentation from an upstream Makefile
On Wed, Aug 07, 2002 at 05:04:54PM +0100, Steve Kemp wrote: > > I've almost finished creating a package for htmlpp a html preprocessor > which has lots of example files. > > There's a makefile target 'install-docs' which I've modified to install > things into /usr/share/docs/htmlpp/. That's /usr/share/doc/... > > Is this sufficient - or should I setup a link from /usr/doc as well? > If you use the debhelper tools (dh_installdocs in this case I think), they'll set up the /usr/doc for you automatically. Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: ldconfig in postinst
On Tue, Sep 04, 2001 at 01:53:31PM +0200, Domenico Andreoli wrote: > On Mon, Sep 03, 2001 at 01:22:01PM -0500, Steve Langasek wrote: > > On Mon, 3 Sep 2001, Drew Parsons wrote: > > > [...] > > > > Check the contents of the postinst script in the binary package. The > > #DEBHELPER# line gets replaced with debhelper hints based on the various > > dh_* > > commands you've called, and if you call dh_makeshlibs, this will include a > > call to ldconfig in the postinst and the postrm. > > > this happens only if you set DH_COMPAT=3 somewhere in your debian/rules and if > you are using debhelper, of course > Yes. dh_makeshlibs doesn't put ldconfig in the debhelper script. I'm running at DH_COMPAT=2. It's a bit of an old package I've adopted, so I'm a bit worried about getting too carried away modernising it... Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: ldconfig in postinst
On Tue, Sep 04, 2001 at 01:53:31PM +0200, Domenico Andreoli wrote: > On Mon, Sep 03, 2001 at 01:22:01PM -0500, Steve Langasek wrote: > > On Mon, 3 Sep 2001, Drew Parsons wrote: > > > [...] > > > > Check the contents of the postinst script in the binary package. The > > #DEBHELPER# line gets replaced with debhelper hints based on the various dh_* > > commands you've called, and if you call dh_makeshlibs, this will include a > > call to ldconfig in the postinst and the postrm. > > > this happens only if you set DH_COMPAT=3 somewhere in your debian/rules and if > you are using debhelper, of course > Yes. dh_makeshlibs doesn't put ldconfig in the debhelper script. I'm running at DH_COMPAT=2. It's a bit of an old package I've adopted, so I'm a bit worried about getting too carried away modernising it... Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ldconfig in postinst
On Mon, Sep 03, 2001 at 02:08:00PM +0200, Domenico Andreoli wrote: > > > > But I've noticed just now as I prepare a new upload that lintain complains, > > saying, > > > > W: meschach: postinst-has-useless-call-to-ldconfig > > > > anyway there was a bug (#109721) and lintian reported this warning even if you > were effectively installing libraries in ldconfig path. this bugs has been > solved > and upgrading to newer versions of lintian should make you less confused :(( > Yes, that seems to be the problem. The warning has gone away with the latest version of lintian. > remember also to call ldconfig in postrm only with "remove" argument (see > policy > chapter 9) > Oh, I didn't realise I needed to do that too. Thanks for the tip. > > (and do I need to put dpkg-shlibdeps in debian/rules somewhere? It seems > > fine without it) > > > yes you should always call it if you are building any sort of binaries which > may > depends on other binaries (ie. executables and shared libraries). please > remember > that any library that uses libc must be compiled against but not have a > dependency > on it since libc is essential package (exception is required if you need a > particular > version of it). > OK I'll try it :) Thanks again, Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: ldconfig in postinst
On Mon, Sep 03, 2001 at 02:08:00PM +0200, Domenico Andreoli wrote: > > > > But I've noticed just now as I prepare a new upload that lintain complains, > > saying, > > > > W: meschach: postinst-has-useless-call-to-ldconfig > > > > anyway there was a bug (#109721) and lintian reported this warning even if you > were effectively installing libraries in ldconfig path. this bugs has been solved > and upgrading to newer versions of lintian should make you less confused :(( > Yes, that seems to be the problem. The warning has gone away with the latest version of lintian. > remember also to call ldconfig in postrm only with "remove" argument (see policy > chapter 9) > Oh, I didn't realise I needed to do that too. Thanks for the tip. > > (and do I need to put dpkg-shlibdeps in debian/rules somewhere? It seems > > fine without it) > > > yes you should always call it if you are building any sort of binaries which may > depends on other binaries (ie. executables and shared libraries). please remember > that any library that uses libc must be compiled against but not have a dependency > on it since libc is essential package (exception is required if you need a particular > version of it). > OK I'll try it :) Thanks again, Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ldconfig in postinst
My package meschach has a shared library. Previously, I called ldconfig in the postinst to get the library registered (it was made mandatory in Policy 2.4.1.0). But I've noticed just now as I prepare a new upload that lintain complains, saying, W: meschach: postinst-has-useless-call-to-ldconfig So I'm a bit confused about what the problem is, especially since the directive in Policy 2.4.1.0 doesn't appear to have been annulled. (and do I need to put dpkg-shlibdeps in debian/rules somewhere? It seems fine without it) My postinst is: #!/bin/sh # meschach.postinst, runs ldconfig set -e case "$1" in configure) ldconfig ;; abort-upgrade|abort-remove|abort-deconfigure) ;; esac #DEBHELPER# ## Thanks for any clues or explanations, Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
ldconfig in postinst
My package meschach has a shared library. Previously, I called ldconfig in the postinst to get the library registered (it was made mandatory in Policy 2.4.1.0). But I've noticed just now as I prepare a new upload that lintain complains, saying, W: meschach: postinst-has-useless-call-to-ldconfig So I'm a bit confused about what the problem is, especially since the directive in Policy 2.4.1.0 doesn't appear to have been annulled. (and do I need to put dpkg-shlibdeps in debian/rules somewhere? It seems fine without it) My postinst is: #!/bin/sh # meschach.postinst, runs ldconfig set -e case "$1" in configure) ldconfig ;; abort-upgrade|abort-remove|abort-deconfigure) ;; esac #DEBHELPER# ## Thanks for any clues or explanations, Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error: depends-on-essential-package-without-using-ve
On Sat, Aug 25, 2001 at 11:06:41AM -0700, Sean 'Shaleh' Perry wrote: > > my @bashism_regexs = ( .. > ); > > This is the array of regexes I test Debian scripts against in lintian. it is > not all encompassing but it catches most of the egregious ones that bash > allows > and which the manpage does not clearly define as bash extras. > This looks useful. How can I apply it as a stand-alone tool? It'd be useful to be able to run it directly against the script rather than having to the create the deb file for lintian to test against. I would imagine it would be useful to add to the bash package, too. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: Lintian error: depends-on-essential-package-without-using-ve
On Sat, Aug 25, 2001 at 11:06:41AM -0700, Sean 'Shaleh' Perry wrote: > > my @bashism_regexs = ( .. > ); > > This is the array of regexes I test Debian scripts against in lintian. it is > not all encompassing but it catches most of the egregious ones that bash allows > and which the manpage does not clearly define as bash extras. > This looks useful. How can I apply it as a stand-alone tool? It'd be useful to be able to run it directly against the script rather than having to the create the deb file for lintian to test against. I would imagine it would be useful to add to the bash package, too. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error: depends-on-essential-package-without-using-version bash
On Sat, Aug 25, 2001 at 03:20:28AM +1000, Drew Parsons wrote: > > But doing this, lintian gives the warning: > > E: tzwatch: depends-on-essential-package-without-using-version bash > > I can't find much in Debian policy about this, so I'd like to ask, what > does this error mean, and why is it an error? Thanks for your replies. We don't need to depend on essential packages, unless there's a particular version where a new feature was added. I'll be able to leave out the dependency on bash, then. > > Lastly, is there a reliable way of confirming that I do not in fact have any > bashisms, so that #!/bin/sh would be sufficient? sh is linked to bash, so > simply writing #!/bin/sh in the script is not sufficient. > I tried ash, it gave the error: [: ==: unexpected operator ./tzwatch: 64: Syntax error: "do" unexpected (expecting "done") coming from a select do...done...statement. That's a bit strange, since the bash info pages seem to be saying the select construct is a basic shell command. Nevermind, I won't lose too much sleep over it, I'll just leave it as "bash" :) Thanks, Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: Lintian error: depends-on-essential-package-without-using-version bash
On Sat, Aug 25, 2001 at 03:20:28AM +1000, Drew Parsons wrote: > > But doing this, lintian gives the warning: > > E: tzwatch: depends-on-essential-package-without-using-version bash > > I can't find much in Debian policy about this, so I'd like to ask, what > does this error mean, and why is it an error? Thanks for your replies. We don't need to depend on essential packages, unless there's a particular version where a new feature was added. I'll be able to leave out the dependency on bash, then. > > Lastly, is there a reliable way of confirming that I do not in fact have any > bashisms, so that #!/bin/sh would be sufficient? sh is linked to bash, so > simply writing #!/bin/sh in the script is not sufficient. > I tried ash, it gave the error: [: ==: unexpected operator ./tzwatch: 64: Syntax error: "do" unexpected (expecting "done") coming from a select do...done...statement. That's a bit strange, since the bash info pages seem to be saying the select construct is a basic shell command. Nevermind, I won't lose too much sleep over it, I'll just leave it as "bash" :) Thanks, Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Lintian error: depends-on-essential-package-without-using-version bash
I'm packaging up a shell script called tzwatch which displays the time from different timezones. It's actually a bash script since I thought it had some bashisms (while getopts case select), although reading through the info pages for bash, it seems these are standard sh commands after all. I marked it as a bash script by comparison with tzselect, on which the script is based, which is also #!/bin/bash. Thinking it was truly a bash shell, I added a dependency on the bash package in debian/control: Depends: bash But doing this, lintian gives the warning: E: tzwatch: depends-on-essential-package-without-using-version bash I can't find much in Debian policy about this, so I'd like to ask, what does this error mean, and why is it an error? Is it correct that I do not in fact have to declare the dependency on bash, since it is an "Essential" package? Even if that's the case, why do I get this error? Lastly, is there a reliable way of confirming that I do not in fact have any bashisms, so that #!/bin/sh would be sufficient? sh is linked to bash, so simply writing #!/bin/sh in the script is not sufficient. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Lintian error: depends-on-essential-package-without-using-version bash
I'm packaging up a shell script called tzwatch which displays the time from different timezones. It's actually a bash script since I thought it had some bashisms (while getopts case select), although reading through the info pages for bash, it seems these are standard sh commands after all. I marked it as a bash script by comparison with tzselect, on which the script is based, which is also #!/bin/bash. Thinking it was truly a bash shell, I added a dependency on the bash package in debian/control: Depends: bash But doing this, lintian gives the warning: E: tzwatch: depends-on-essential-package-without-using-version bash I can't find much in Debian policy about this, so I'd like to ask, what does this error mean, and why is it an error? Is it correct that I do not in fact have to declare the dependency on bash, since it is an "Essential" package? Even if that's the case, why do I get this error? Lastly, is there a reliable way of confirming that I do not in fact have any bashisms, so that #!/bin/sh would be sufficient? sh is linked to bash, so simply writing #!/bin/sh in the script is not sufficient. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: characters in X-application replaced with boxes :(
On Fri, Aug 10, 2001 at 07:47:07PM +0200, Radovan Garabik wrote: > On Fri, Aug 10, 2001 at 05:48:49PM +1000, Drew Parsons wrote: > > I've just had a fresh look at my package viewmol. > > I compiled it in April under X 4.0.1-11, it worked fine then. > > > > But looking at it now, none of the text in buttons and menus gets displayed > > anymore. Instead, the letters are replaced with a "box". > > I saw the same with netscape. I just commented away path to xfs server > in my XFree86-4 file (I do not use xfs anyway) and the problem > went away - I did not investigate it further > No, didn't help, sorry. The boxes are still there even after commenting out the xfs lines and restarting X :( Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: characters in X-application replaced with boxes :(
On Fri, Aug 10, 2001 at 09:53:32AM +0200, Bart Warmerdam wrote: > On Fri, Aug 10, 2001 at 05:48:49PM +1000, Drew Parsons wrote: > > [ characters show as boxes in X ] > > > Can anyone suggest how to best determine the cause of the problem? > > Restart X. Helped for me numerous times for the same problem. BTW, does anyone > know why this is happening anyhow? > No, it won't be as simple as that. To be sure, I've restart and rebooted many many times since I last tested the program four months ago. I think it might be related to default fonts the program uses, there might be some mismatch in font names or in the encoding. X now supports UTF8 well, and I've started using it. Some fonts are named in init.c and fallback.h. I'm not completely sure how to manipulate them though. And even when I specify a normal 8bit locale, the fonts are still screwed up. Where an XFontStruct structure is found, is there any way to find the full name of the corresponding font? It's not obvious from the structure of the struct. If I could know what font it thinks it's using, that'd at least be a start. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
characters in X-application replaced with boxes :(
I've just had a fresh look at my package viewmol. I compiled it in April under X 4.0.1-11, it worked fine then. But looking at it now, none of the text in buttons and menus gets displayed anymore. Instead, the letters are replaced with a "box". The behaviour appears to be independent of locale - I tried several. I guess it's most likely related to the recent upgrade of X to 4.1.0. Can anyone suggest how to best determine the cause of the problem? Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: characters in X-application replaced with boxes :(
On Fri, Aug 10, 2001 at 09:53:32AM +0200, Bart Warmerdam wrote: > On Fri, Aug 10, 2001 at 05:48:49PM +1000, Drew Parsons wrote: > > [ characters show as boxes in X ] > > > Can anyone suggest how to best determine the cause of the problem? > > Restart X. Helped for me numerous times for the same problem. BTW, does anyone > know why this is happening anyhow? > No, it won't be as simple as that. To be sure, I've restart and rebooted many many times since I last tested the program four months ago. I think it might be related to default fonts the program uses, there might be some mismatch in font names or in the encoding. X now supports UTF8 well, and I've started using it. Some fonts are named in init.c and fallback.h. I'm not completely sure how to manipulate them though. And even when I specify a normal 8bit locale, the fonts are still screwed up. Where an XFontStruct structure is found, is there any way to find the full name of the corresponding font? It's not obvious from the structure of the struct. If I could know what font it thinks it's using, that'd at least be a start. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
characters in X-application replaced with boxes :(
I've just had a fresh look at my package viewmol. I compiled it in April under X 4.0.1-11, it worked fine then. But looking at it now, none of the text in buttons and menus gets displayed anymore. Instead, the letters are replaced with a "box". The behaviour appears to be independent of locale - I tried several. I guess it's most likely related to the recent upgrade of X to 4.1.0. Can anyone suggest how to best determine the cause of the problem? Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upstream maintainer disagree with the package name
On Sun, May 27, 2001 at 10:50:18AM +1000, Daniel Stone wrote: > On Sat, May 26, 2001 at 11:44:46PM +0200, R?mi Perrot wrote: > > Hi, (Remi? Rimi? mutt doesn't display the second character, as you can see). Yes it does. You probably haven't set your locale to see it. [The '?' in R?mi, above, is because of my editor, jed, not because of mutt] Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: Upstream maintainer disagree with the package name
On Sun, May 27, 2001 at 10:50:18AM +1000, Daniel Stone wrote: > On Sat, May 26, 2001 at 11:44:46PM +0200, R?mi Perrot wrote: > > Hi, (Remi? Rimi? mutt doesn't display the second character, as you can see). Yes it does. You probably haven't set your locale to see it. [The '?' in R?mi, above, is because of my editor, jed, not because of mutt] Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My First Package. Wheee.
On Fri, May 11, 2001 at 07:06:05PM +0530, Viral wrote: > > Do the autobuilders build packages for all the architectures, or is > the maintainer supposed to do that ? > The autobuilders do that. You only compile on your own system, generally. I was even surprised to find that viewmol managed to get itself compiled on ia64 :) I must tell the upstream author, he'd be pleased to know... Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: My First Package. Wheee.
On Thu, May 10, 2001 at 12:56:49PM -0500, Michael Janssen (CS/MATH stud.) wrote: > In Warren Anthony Stramiello's email, 10-05-2001: > > > > It's XDrawChem, a linux version of ChemDraw, a fairly necessary app for > > chemistry folks (at least so my girlfriend tells me, and she's a chemistry > > major here at Tech). > > Congratulations! If only it had been around when I was writing my thesis.. ;) > > I read through the docs and such (NMU docs, packaging-manual, and so > > forth), and I was wondering how I should handle: > > > > a) inclusion in the testing distribution, if still possible > > b) inclusion in the unstable distribution, if still possible To give a bit more detail from Tog's reply: you upload to unstable (this means you need to be running unstable yourself, unless you know how to do one of those chroot thingies). After a standard period of time (10 days for normal packages I think), the package gets copied (symlink) to testing if the following conditions are met: - binaries are available for main architectures (i386, alpha, sparc, but the others are lagging behind, so they won't hold up the package from testing) - no serious errors (normal errors don't hold it up) - the packages it depends on are also in testing The third one can be the tricky one to follow, since there might dependencies on dependencies and they have to be fulfilled all the way down. > > c) uploading using dupload and scp I think someone mentioned the New Maintainer's guide. Section 6.3 (I copy and paste from there, hence I don't know about dput either ;) ) > > Ohh.. cool - I've been looking for a software program to do something > like this for a while for our labs.. > If you need 3-D modelling, I've recently uploaded viewmol (lets you edit new molecules as well as view them). And something else was uploaded even more recently still (I forget the name). Chemistry in Debian is having it's day... ;) Section Science was recently opened on the Debian website (it had been forgotten), maybe that's attracting all these chem packages? Regards, Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: My First Package. Wheee.
On Fri, May 11, 2001 at 07:06:05PM +0530, Viral wrote: > > Do the autobuilders build packages for all the architectures, or is > the maintainer supposed to do that ? > The autobuilders do that. You only compile on your own system, generally. I was even surprised to find that viewmol managed to get itself compiled on ia64 :) I must tell the upstream author, he'd be pleased to know... Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My First Package. Wheee.
On Thu, May 10, 2001 at 12:56:49PM -0500, Michael Janssen (CS/MATH stud.) wrote: > In Warren Anthony Stramiello's email, 10-05-2001: > > > > It's XDrawChem, a linux version of ChemDraw, a fairly necessary app for > > chemistry folks (at least so my girlfriend tells me, and she's a chemistry > > major here at Tech). > > Congratulations! If only it had been around when I was writing my thesis.. ;) > > I read through the docs and such (NMU docs, packaging-manual, and so > > forth), and I was wondering how I should handle: > > > > a) inclusion in the testing distribution, if still possible > > b) inclusion in the unstable distribution, if still possible To give a bit more detail from Tog's reply: you upload to unstable (this means you need to be running unstable yourself, unless you know how to do one of those chroot thingies). After a standard period of time (10 days for normal packages I think), the package gets copied (symlink) to testing if the following conditions are met: - binaries are available for main architectures (i386, alpha, sparc, but the others are lagging behind, so they won't hold up the package from testing) - no serious errors (normal errors don't hold it up) - the packages it depends on are also in testing The third one can be the tricky one to follow, since there might dependencies on dependencies and they have to be fulfilled all the way down. > > c) uploading using dupload and scp I think someone mentioned the New Maintainer's guide. Section 6.3 (I copy and paste from there, hence I don't know about dput either ;) ) > > Ohh.. cool - I've been looking for a software program to do something > like this for a while for our labs.. > If you need 3-D modelling, I've recently uploaded viewmol (lets you edit new molecules as well as view them). And something else was uploaded even more recently still (I forget the name). Chemistry in Debian is having it's day... ;) Section Science was recently opened on the Debian website (it had been forgotten), maybe that's attracting all these chem packages? Regards, Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_testroot ?
Thanks for your responses, all :) Setting the file permissions properly seems to be the main need for the root build environment. Regards, Drew
Re: dh_testroot ?
Thanks for your responses, all :) Setting the file permissions properly seems to be the main need for the root build environment. Regards, Drew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dh_testroot ?
I just noticed the debian/rules file for mirrormagic which I inherited from Joey Hess uses dh_testroot to check that the build is run as root (or fakeroot). I'm wondering what the justification for doing this is. It prevents, for instance, a home user compiling his own deb before installing unless he specifically compiles it under root or fakeroot. I'm fairly certain this is a Stupid Question, but one way of learning is to ask the stupid questions... ;) Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
dh_testroot ?
I just noticed the debian/rules file for mirrormagic which I inherited from Joey Hess uses dh_testroot to check that the build is run as root (or fakeroot). I'm wondering what the justification for doing this is. It prevents, for instance, a home user compiling his own deb before installing unless he specifically compiles it under root or fakeroot. I'm fairly certain this is a Stupid Question, but one way of learning is to ask the stupid questions... ;) Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice needed on changing upstream source.
On Tue, Apr 10, 2001 at 12:38:39PM -0700, Sean 'Shaleh' Perry wrote: > > > > 3. add updates to the debianized source but not the orig.tar.gz > > > > I would handle it this way personally. Mucking with upstream source is never > a > good idea. > libc6 does does something like this, doesn't it? It's been tracking the 2.2 series, but each Debian revision has been updating to the latest CVS. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: Advice needed on changing upstream source.
On Tue, Apr 10, 2001 at 12:38:39PM -0700, Sean 'Shaleh' Perry wrote: > > > > 3. add updates to the debianized source but not the orig.tar.gz > > > > I would handle it this way personally. Mucking with upstream source is never a > good idea. > libc6 does does something like this, doesn't it? It's been tracking the 2.2 series, but each Debian revision has been updating to the latest CVS. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libdb-dev - I don't get it!
On Mon, Mar 26, 2001 at 03:07:45PM -0500, Ben Collins wrote: > > Now, with db3, I want to be sure that everyone realizes that they are > compiling against libdb3, since the binary on-disk format of the .db's > is different. So, you have to explicitly tell your builds that you want > -ldb3, so there is no cause for surprises. > OK, that sounds fair enough. > Note, you may want to be sure that upgrades from you db2 compile to db3 > support will not cause anything to break. The libdb3-util package comes > with a db3_upgrade program which will upgrade existing db2 databases in > place. Or you can read db3-doc and find the db_upgrade function where > this can be done automatically in your program. > I'll think I'll try sticking with db2 for the time being in that case. The funny thing is, I'm not even sure if viewmol actually uses libdb. -ldb just happens to be sitting there in the makefile. I can't find any "db_*" entries in the source. Is there any more sophisticated manner of checking actual usage of a library than removing -ldb from the makefile and seeing what breaks? And could anyone tell me which command displays the functions contained in a library? I know there's something, but I can't remember it. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: libXmu: found automatically on i386, not on vore
On Mon, Mar 26, 2001 at 12:31:30PM -0500, Chris Gray wrote: > On Tue, 27 Mar 2001, Drew Parsons wrote: > > I've got Bug #90459, which says libXmu was not identified when > > compiling on vore (that's sparc, isn't it? not that it's real > > important). > > > > (cgray4 ~)-> ldd /usr/lib/libGL.so > libggi.so.2 => /usr/lib/libggi.so.2 (0x4025d000) > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40268000) > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40272000) > libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40288000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4029d000) > libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x402ab000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x402b3000) > libpthread.so.0 => /lib/libpthread.so.0 (0x4038d000) > libc.so.6 => /lib/libc.so.6 (0x403a3000) > libgii.so.0 => /usr/lib/libgii.so.0 (0x404b2000) > libgg.so.0 => /usr/lib/libgg.so.0 (0x404ba000) > libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x404c) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2000) > libdl.so.2 => /lib/libdl.so.2 (0x4050a000) > > This is on i386. I would guess that libXmu doesn't show up on vore. > In any case, it's better to link explicitly with all the libraries > that you need. > Yes, that looks like it. vore sez: (base)[EMAIL PROTECTED]:~$ ldd /usr/lib/libGL.so libpthread.so.0 => /lib/libpthread.so.0 (0x7007) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x70094000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x700b6000) libdl.so.2 => /lib/libdl.so.2 (0x701b2000) libc.so.6 => /lib/libc.so.6 (0x701c6000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0800) Thanks for the clue. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: libdb-dev - I don't get it!
On Mon, Mar 26, 2001 at 03:07:45PM -0500, Ben Collins wrote: > > Now, with db3, I want to be sure that everyone realizes that they are > compiling against libdb3, since the binary on-disk format of the .db's > is different. So, you have to explicitly tell your builds that you want > -ldb3, so there is no cause for surprises. > OK, that sounds fair enough. > Note, you may want to be sure that upgrades from you db2 compile to db3 > support will not cause anything to break. The libdb3-util package comes > with a db3_upgrade program which will upgrade existing db2 databases in > place. Or you can read db3-doc and find the db_upgrade function where > this can be done automatically in your program. > I'll think I'll try sticking with db2 for the time being in that case. The funny thing is, I'm not even sure if viewmol actually uses libdb. -ldb just happens to be sitting there in the makefile. I can't find any "db_*" entries in the source. Is there any more sophisticated manner of checking actual usage of a library than removing -ldb from the makefile and seeing what breaks? And could anyone tell me which command displays the functions contained in a library? I know there's something, but I can't remember it. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libXmu: found automatically on i386, not on vore
On Mon, Mar 26, 2001 at 12:31:30PM -0500, Chris Gray wrote: > On Tue, 27 Mar 2001, Drew Parsons wrote: > > I've got Bug #90459, which says libXmu was not identified when > > compiling on vore (that's sparc, isn't it? not that it's real > > important). > > > > (cgray4 ~)-> ldd /usr/lib/libGL.so > libggi.so.2 => /usr/lib/libggi.so.2 (0x4025d000) > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40268000) > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40272000) > libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40288000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4029d000) > libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x402ab000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x402b3000) > libpthread.so.0 => /lib/libpthread.so.0 (0x4038d000) > libc.so.6 => /lib/libc.so.6 (0x403a3000) > libgii.so.0 => /usr/lib/libgii.so.0 (0x404b2000) > libgg.so.0 => /usr/lib/libgg.so.0 (0x404ba000) > libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x404c) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2000) > libdl.so.2 => /lib/libdl.so.2 (0x4050a000) > > This is on i386. I would guess that libXmu doesn't show up on vore. > In any case, it's better to link explicitly with all the libraries > that you need. > Yes, that looks like it. vore sez: (base)dparsons@vore:~$ ldd /usr/lib/libGL.so libpthread.so.0 => /lib/libpthread.so.0 (0x7007) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x70094000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x700b6000) libdl.so.2 => /lib/libdl.so.2 (0x701b2000) libc.so.6 => /lib/libc.so.6 (0x701c6000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0800) Thanks for the clue. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libXmu: found automatically on i386, not on vore
I've got Bug #90459, which says libXmu was not identified when compiling on vore (that's sparc, isn't it? not that it's real important). The autobuild log at http://vore.debian.org/buildlogs/viewmol says: ... cc -c -Wall -I/usr/X11R6/include -DLINUX -I/usr/include -I/usr/include/python1.5 -O6 -fomit-frame-pointer -ffast-math ../coledit.c ... cc -o viewmol ... coledit.o ... -L/usr/lib/python1.5/config -L/usr/local/lib -lpython1.5 -ltiff -lGLU -lGL -L/usr/X11R6/lib -lXm -lXp -lXi -lXext -lXt -lX11 -lpthread -ldb -lutil -ldl -lm input.o: In function findFileType': input.o(.text+0x6d8): the use of tmpnam' is dangerous, better use mkstemp' coledit.o: In function getRGBcolormap': coledit.o(.text+0x2700): undefined reference to XmuLookupStandardColormap' collect2: ld returned 1 exit status make[2]: *** [viewmol_] Error 1 XmuLookupStandardColormap is undefined, and comes from libXmu (supplied by xlibs). Sure enough, there is no -lXmu entry on the linking line. The appropriate solution would, would it not?, be to add -lXmu. But the bit I don't understand is that this same line compiles perfectly fine on my i386 system: ... cc -o viewmol ... coledit.o ... -L/usr/lib/python1.5/config -L/usr/local/lib -lpython1.5 -ltiff -lGLU -lGL -L/usr/X11R6/lib -lXm -lXp -lXi -lXext -lXt -lX11 -lpthread -ldb -lutil -ldl -lm input.o: In function `findFileType': input.o(.text+0x6c7): the use of `tmpnam' is dangerous, better use `mkstemp' make[2]: Leaving directory `/home/drew/projects/viewmol-2.3/source/Linux' ... No complaints about XmuLookupStandardColormap, though the code and the compile line (no -lXmu) are the same. This is weird. It makes sense why it fails on vore. But why does it work on i386? Drew ps Build depends are: debhelper (>> 2.0.0), libtiff3g-dev, mesag-dev, lesstif-dev, libdb3-dev, python-dev, xlibs-dev, docbook-to-man. -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
libdb-dev - I don't get it!
My latest package viewmol has a -ldb entry in the makefile. I asked on this list where on earth I'd find libdb.so to compile against, and you helpfully pointed me to libdb2-dev. However, since then, libdb3[-dev] has come out, so I figured I would dutifully compile against it. But to my surprise, I discovered that libdb3-dev does not provide /usr/lib/libdb.[so,a] at all! It only has libdb3.so. I don't understand. Is this a bug? Or is libdb.so forever to be fated identical to libdb2.so ? libdb3[-dev] docs are empty and therefore of no help. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
libXmu: found automatically on i386, not on vore
I've got Bug #90459, which says libXmu was not identified when compiling on vore (that's sparc, isn't it? not that it's real important). The autobuild log at http://vore.debian.org/buildlogs/viewmol says: ... cc -c -Wall -I/usr/X11R6/include -DLINUX -I/usr/include -I/usr/include/python1.5 -O6 -fomit-frame-pointer -ffast-math ../coledit.c ... cc -o viewmol ... coledit.o ... -L/usr/lib/python1.5/config -L/usr/local/lib -lpython1.5 -ltiff -lGLU -lGL -L/usr/X11R6/lib -lXm -lXp -lXi -lXext -lXt -lX11 -lpthread -ldb -lutil -ldl -lm input.o: In function findFileType': input.o(.text+0x6d8): the use of tmpnam' is dangerous, better use mkstemp' coledit.o: In function getRGBcolormap': coledit.o(.text+0x2700): undefined reference to XmuLookupStandardColormap' collect2: ld returned 1 exit status make[2]: *** [viewmol_] Error 1 XmuLookupStandardColormap is undefined, and comes from libXmu (supplied by xlibs). Sure enough, there is no -lXmu entry on the linking line. The appropriate solution would, would it not?, be to add -lXmu. But the bit I don't understand is that this same line compiles perfectly fine on my i386 system: ... cc -o viewmol ... coledit.o ... -L/usr/lib/python1.5/config -L/usr/local/lib -lpython1.5 -ltiff -lGLU -lGL -L/usr/X11R6/lib -lXm -lXp -lXi -lXext -lXt -lX11 -lpthread -ldb -lutil -ldl -lm input.o: In function `findFileType': input.o(.text+0x6c7): the use of `tmpnam' is dangerous, better use `mkstemp' make[2]: Leaving directory `/home/drew/projects/viewmol-2.3/source/Linux' ... No complaints about XmuLookupStandardColormap, though the code and the compile line (no -lXmu) are the same. This is weird. It makes sense why it fails on vore. But why does it work on i386? Drew ps Build depends are: debhelper (>> 2.0.0), libtiff3g-dev, mesag-dev, lesstif-dev, libdb3-dev, python-dev, xlibs-dev, docbook-to-man. -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libdb-dev - I don't get it!
My latest package viewmol has a -ldb entry in the makefile. I asked on this list where on earth I'd find libdb.so to compile against, and you helpfully pointed me to libdb2-dev. However, since then, libdb3[-dev] has come out, so I figured I would dutifully compile against it. But to my surprise, I discovered that libdb3-dev does not provide /usr/lib/libdb.[so,a] at all! It only has libdb3.so. I don't understand. Is this a bug? Or is libdb.so forever to be fated identical to libdb2.so ? libdb3[-dev] docs are empty and therefore of no help. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: placing supplementary binaries
On Sun, Mar 11, 2001 at 05:25:27AM -1000, Brian Russo wrote: > > given that upstream has decided to put them in /usr/lib, its > probably reasonable that you follow suit. > That argument convinces me, I'll keep them under a viewmol directory. I'll have to split the scripts from the C binaries into /usr/share and /usr/lib, as Matt said. Kind of messy, but not too bad. Thanks, Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: placing supplementary binaries
On Sun, Mar 11, 2001 at 05:25:27AM -1000, Brian Russo wrote: > > given that upstream has decided to put them in /usr/lib, its > probably reasonable that you follow suit. > That argument convinces me, I'll keep them under a viewmol directory. I'll have to split the scripts from the C binaries into /usr/share and /usr/lib, as Matt said. Kind of messy, but not too bad. Thanks, Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: placing supplementary binaries
On Sun, Mar 11, 2001 at 04:18:09AM -1000, Brian Russo wrote: > > > > Should I therefore keep these supplementary utilities in the viewmol > > directory, or should they instead be moved to /usr/bin? > > if they're binaries that are typically wrapped or otherwise not > typically invoked directly by the user, /usr/lib is probably fine > otherwise they should probably be in /usr/bin. > Hmm, that's a hard one to judge. I guess they *could* be used independently, but they just transform coordinates to viewmol's own internal system, which would arguably be a bit useless for general use. But maybe someone could find a use for it. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
placing supplementary binaries
viewmol, a molecular modelling program I'm packaging, makes use of a number of supplementary binary files and scripts to read atomic coordinates from a range of different file formats. By default these utilities are kept in a viewmol-specific directory (/usr/local/lib/viewmol, which I'll change to /usr/share/viewmol), where viewmol knows to find them, their position being defined by the config file viewmolrc. Should I therefore keep these supplementary utilities in the viewmol directory, or should they instead be moved to /usr/bin? Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: placing supplementary binaries
On Sun, Mar 11, 2001 at 04:18:09AM -1000, Brian Russo wrote: > > > > Should I therefore keep these supplementary utilities in the viewmol > > directory, or should they instead be moved to /usr/bin? > > if they're binaries that are typically wrapped or otherwise not > typically invoked directly by the user, /usr/lib is probably fine > otherwise they should probably be in /usr/bin. > Hmm, that's a hard one to judge. I guess they *could* be used independently, but they just transform coordinates to viewmol's own internal system, which would arguably be a bit useless for general use. But maybe someone could find a use for it. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
placing supplementary binaries
viewmol, a molecular modelling program I'm packaging, makes use of a number of supplementary binary files and scripts to read atomic coordinates from a range of different file formats. By default these utilities are kept in a viewmol-specific directory (/usr/local/lib/viewmol, which I'll change to /usr/share/viewmol), where viewmol knows to find them, their position being defined by the config file viewmolrc. Should I therefore keep these supplementary utilities in the viewmol directory, or should they instead be moved to /usr/bin? Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libdb ??
On Fri, Mar 09, 2001 at 10:42:35PM -0500, [EMAIL PROTECTED] wrote: > > /usr/bin/ld: cannot find -ldb > > collect2: ld returned 1 exit status > > make[1]: *** [viewmol_] Error 1 > > > [] > > > > Is the absence of libdb.so in /usr/lib a bug in libc6-dev? > > No. > > > What is the proper way to solve this question? > > apt-get install libdb2-dev > Perfectly right, that fixes it. Funny, I don't even know why it wants libdb in the first place. Oh well, at least it's working. Thanks for the clue! Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
libdb ??
A program (viewmol) I'm trying to package has some problems finding some db library. It doesn't specify this library explicitly, the makefile just says viewmol_: $(OBJ) ; cc -o viewmol $(LDFLAGS) $(OBJ) $(LIBRARY) $(LIBS) LIBS is not defined in the makefile, it just has the default values for make. When make is run, this line gets translated to: cc -o viewmol annotate.o [..snip..] zoom.o -L/usr/lib/python1.5/config -L/usr/local/lib -lpython1.5 -ltiff -lGLU -lGL -L/usr/X11R6/lib -lXm -lXp -lXi -lXext -lXt -lX11 -lpthread -ldb -lutil -ldl -lm and then the following error appears: /usr/bin/ld: cannot find -ldb collect2: ld returned 1 exit status make[1]: *** [viewmol_] Error 1 Now /usr/lib has a libdb1.so and a libdb2.so, but no libdb.so. There is, however, a libdb.so in /lib (/lib/libdb-2.2.2.so to be precise). libdb1 and libdb are both provided by libc6[-dev]. If I make a symlink at /usr/lib/libdb.so to this library file in /lib, then compilation is successful and the program runs fine. But I shouldn't have to make my own symlinks like that. I could put /lib into /etc/ld.so.config, but is that really the "correct" solution? That won't work for general Debian building of the package. Is the absence of libdb.so in /usr/lib a bug in libc6-dev? What is the proper way to solve this question? Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: libdb ??
On Fri, Mar 09, 2001 at 10:42:35PM -0500, [EMAIL PROTECTED] wrote: > > /usr/bin/ld: cannot find -ldb > > collect2: ld returned 1 exit status > > make[1]: *** [viewmol_] Error 1 > > > [] > > > > Is the absence of libdb.so in /usr/lib a bug in libc6-dev? > > No. > > > What is the proper way to solve this question? > > apt-get install libdb2-dev > Perfectly right, that fixes it. Funny, I don't even know why it wants libdb in the first place. Oh well, at least it's working. Thanks for the clue! Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libdb ??
A program (viewmol) I'm trying to package has some problems finding some db library. It doesn't specify this library explicitly, the makefile just says viewmol_: $(OBJ) ; cc -o viewmol $(LDFLAGS) $(OBJ) $(LIBRARY) $(LIBS) LIBS is not defined in the makefile, it just has the default values for make. When make is run, this line gets translated to: cc -o viewmol annotate.o [..snip..] zoom.o -L/usr/lib/python1.5/config -L/usr/local/lib -lpython1.5 -ltiff -lGLU -lGL -L/usr/X11R6/lib -lXm -lXp -lXi -lXext -lXt -lX11 -lpthread -ldb -lutil -ldl -lm and then the following error appears: /usr/bin/ld: cannot find -ldb collect2: ld returned 1 exit status make[1]: *** [viewmol_] Error 1 Now /usr/lib has a libdb1.so and a libdb2.so, but no libdb.so. There is, however, a libdb.so in /lib (/lib/libdb-2.2.2.so to be precise). libdb1 and libdb are both provided by libc6[-dev]. If I make a symlink at /usr/lib/libdb.so to this library file in /lib, then compilation is successful and the program runs fine. But I shouldn't have to make my own symlinks like that. I could put /lib into /etc/ld.so.config, but is that really the "correct" solution? That won't work for general Debian building of the package. Is the absence of libdb.so in /usr/lib a bug in libc6-dev? What is the proper way to solve this question? Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_installdeb & postrm
On Sun, Feb 25, 2001 at 01:14:57PM +, Julian Gilbey wrote:
> On Sun, Feb 25, 2001 at 11:27:32PM +1100, Drew Parsons wrote:
> > Nice theory. But when I create meschach.postinst and meschach-dev.postint,
> > I find that meschach.postinst finds its way into the meschach-dev deb file!
> > This in spite of the fact that the ./debian directory has a meschach-dev
> > subdirectory containing meschach-dev.postint!
>
> debian/ shouldn't have any subdirectories. Here's how it should go,
> assuming that your source package is called meschach:
>
My apologies, I think I didn't explain myself properly. I have
meschach{-dev}.postinst and other files in ./debian. The meschach-dev
subdirectory I referred to is what gets creates by the build process (rather
then debian/tmp, which is created when there is only one package). Does that
sound right? meschach supplies the shared library, meschach-dev supplies
the developer files.
Drew
--
PGP public key available at http://dparsons.webjump.com/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: dh_installdeb & postrm
On Sat, Feb 24, 2001 at 01:22:03PM -0600, Gordon Sadler wrote:
>
> Create files named debian/post{rm,inst} and debian/pre{rm,inst} if you
> need to add specific code for one package. For multiple debs from same
> source create debian/$package.post{rm,inst} debian/$package.pre{rm,inst}
>
Nice theory. But when I create meschach.postinst and meschach-dev.postint,
I find that meschach.postinst finds its way into the meschach-dev deb file!
This in spite of the fact that the ./debian directory has a meschach-dev
subdirectory containing meschach-dev.postint!
Weird, eh? And I'd really appreciate it if someone could help me understand
what the problem is likely to be.
Drew
--
PGP public key available at http://dparsons.webjump.com/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: dh_installdeb & postrm
On Sun, Feb 25, 2001 at 01:14:57PM +, Julian Gilbey wrote:
> On Sun, Feb 25, 2001 at 11:27:32PM +1100, Drew Parsons wrote:
> > Nice theory. But when I create meschach.postinst and meschach-dev.postint,
> > I find that meschach.postinst finds its way into the meschach-dev deb file!
> > This in spite of the fact that the ./debian directory has a meschach-dev
> > subdirectory containing meschach-dev.postint!
>
> debian/ shouldn't have any subdirectories. Here's how it should go,
> assuming that your source package is called meschach:
>
My apologies, I think I didn't explain myself properly. I have
meschach{-dev}.postinst and other files in ./debian. The meschach-dev
subdirectory I referred to is what gets creates by the build process (rather
then debian/tmp, which is created when there is only one package). Does that
sound right? meschach supplies the shared library, meschach-dev supplies
the developer files.
Drew
--
PGP public key available at http://dparsons.webjump.com/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_installdeb & postrm
On Sat, Feb 24, 2001 at 01:22:03PM -0600, Gordon Sadler wrote:
>
> Create files named debian/post{rm,inst} and debian/pre{rm,inst} if you
> need to add specific code for one package. For multiple debs from same
> source create debian/$package.post{rm,inst} debian/$package.pre{rm,inst}
>
Nice theory. But when I create meschach.postinst and meschach-dev.postint,
I find that meschach.postinst finds its way into the meschach-dev deb file!
This in spite of the fact that the ./debian directory has a meschach-dev
subdirectory containing meschach-dev.postint!
Weird, eh? And I'd really appreciate it if someone could help me understand
what the problem is likely to be.
Drew
--
PGP public key available at http://dparsons.webjump.com/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: quitting from install scripts
On Thu, Feb 22, 2001 at 11:01:15PM -0500, Matt Zimmerman wrote: > > > > > > I asked a variation on the same question on -devel a few weeks ago, and > > > got > > > zero responses. Aborting in the preinst is the only way to do anything > > > even close, but it makes a bit of a mess. > > If you want to quit a script, use exit. exit 0 means everything ok, any > > other > > value means error. normally the exit value of the script is the value of > > the > > last command which was run, but to be sure to exit cleany you can add exit 0 > > at the end of the script. Nothing more should you do to 'Error unwind' > > something, the rest is done by dpkg. > > Yes. The question was not one of shell programming syntax, it was one of > Debian packaging. If a preinst script exits with nonzero status, other > packages can be left unpacked and unconfigured, and other such unpleasantness. > That's right. If preinst exits with nonzero, then dpkg unwinds by running postrm abort-upgrade or abort-install. I guess you'd have to handle those cases carefully to wind back the upgrade properly. Sounds messy to me. I asked at debian-devel this week and got a response which convinced me not too provide a "quit" option in the install scripts. At least in my case, I don't really need it. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: quitting from install scripts
On Thu, Feb 22, 2001 at 11:01:15PM -0500, Matt Zimmerman wrote: > > > > > > I asked a variation on the same question on -devel a few weeks ago, and got > > > zero responses. Aborting in the preinst is the only way to do anything > > > even close, but it makes a bit of a mess. > > If you want to quit a script, use exit. exit 0 means everything ok, any other > > value means error. normally the exit value of the script is the value of the > > last command which was run, but to be sure to exit cleany you can add exit 0 > > at the end of the script. Nothing more should you do to 'Error unwind' > > something, the rest is done by dpkg. > > Yes. The question was not one of shell programming syntax, it was one of > Debian packaging. If a preinst script exits with nonzero status, other > packages can be left unpacked and unconfigured, and other such unpleasantness. > That's right. If preinst exits with nonzero, then dpkg unwinds by running postrm abort-upgrade or abort-install. I guess you'd have to handle those cases carefully to wind back the upgrade properly. Sounds messy to me. I asked at debian-devel this week and got a response which convinced me not too provide a "quit" option in the install scripts. At least in my case, I don't really need it. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: quitting from install scripts
Sorry to nag. Has anyone got an answer to this question? On Sat, Feb 17, 2001 at 01:12:27AM +1100, Drew Parsons wrote: > I'm planning to have mirrormagic use debconf to ask the user if they want to > delete the highscore files from the older version (which are incompatible > from the new). > > Having a choice of Yes/No is clear, but it seemed to me it might be > appropriate to provide a third alternative, "Quit", which aborts the upgrade > of mirrormagic. > > What is the usual approach to handling the aborting of a package > installation? Is it appropriate to "exit 1" in preinst if the user chooses > "Quit", halting the installation of the package? > > Or is this simply a Bad Idea, and the user should be expected to use Ctrl-C > if he really wants to quit the installation? > > Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: quitting from install scripts
Sorry to nag. Has anyone got an answer to this question? On Sat, Feb 17, 2001 at 01:12:27AM +1100, Drew Parsons wrote: > I'm planning to have mirrormagic use debconf to ask the user if they want to > delete the highscore files from the older version (which are incompatible > from the new). > > Having a choice of Yes/No is clear, but it seemed to me it might be > appropriate to provide a third alternative, "Quit", which aborts the upgrade > of mirrormagic. > > What is the usual approach to handling the aborting of a package > installation? Is it appropriate to "exit 1" in preinst if the user chooses > "Quit", halting the installation of the package? > > Or is this simply a Bad Idea, and the user should be expected to use Ctrl-C > if he really wants to quit the installation? > > Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
quitting from install scripts
I'm planning to have mirrormagic use debconf to ask the user if they want to delete the highscore files from the older version (which are incompatible from the new). Having a choice of Yes/No is clear, but it seemed to me it might be appropriate to provide a third alternative, "Quit", which aborts the upgrade of mirrormagic. What is the usual approach to handling the aborting of a package installation? Is it appropriate to "exit 1" in preinst if the user chooses "Quit", halting the installation of the package? Or is this simply a Bad Idea, and the user should be expected to use Ctrl-C if he really wants to quit the installation? Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
lintian + standards version?
I've been setting the Standards-Version of my packages to 3.5.0.0, but lintian (v 1.20.6) complains: W: gworldclock source: newer-standards-version 3.5.0.0 Indeed, /usr/share/lintian/checks/standards-version doesn't contain any references to 3.5, despite a recent version (1.20.4) closing bugs #84088 and #83969, saying Standards-Version 3.5.0 was accounted for. What's up? Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: spurious INSTALL file in docs
Ooh, I already found it. debian/docs was the culprit. On Fri, Feb 16, 2001 at 11:24:58PM +1100, Drew Parsons wrote: > I'm trying to tidy up my package gworldclock. > There's an INSTALL file in the package root directory (from the upstream > edition), but it's not referred to in the build process. It's just a > standard informative file for autoconf. > > Now debian/rules simply handles docs by invoking dh_installdocs. > However, on installing the package, for some reason I find that INSTALL.gz > gets itself installed into /usr/share/doc/gworldclock. > > Can anyone hazard a guess why? It really shouldn't be there, and I can't see > how it got there either. > > Drew > -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
spurious INSTALL file in docs
I'm trying to tidy up my package gworldclock. There's an INSTALL file in the package root directory (from the upstream edition), but it's not referred to in the build process. It's just a standard informative file for autoconf. Now debian/rules simply handles docs by invoking dh_installdocs. However, on installing the package, for some reason I find that INSTALL.gz gets itself installed into /usr/share/doc/gworldclock. Can anyone hazard a guess why? It really shouldn't be there, and I can't see how it got there either. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
quitting from install scripts
I'm planning to have mirrormagic use debconf to ask the user if they want to delete the highscore files from the older version (which are incompatible from the new). Having a choice of Yes/No is clear, but it seemed to me it might be appropriate to provide a third alternative, "Quit", which aborts the upgrade of mirrormagic. What is the usual approach to handling the aborting of a package installation? Is it appropriate to "exit 1" in preinst if the user chooses "Quit", halting the installation of the package? Or is this simply a Bad Idea, and the user should be expected to use Ctrl-C if he really wants to quit the installation? Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
lintian + standards version?
I've been setting the Standards-Version of my packages to 3.5.0.0, but lintian (v 1.20.6) complains: W: gworldclock source: newer-standards-version 3.5.0.0 Indeed, /usr/share/lintian/checks/standards-version doesn't contain any references to 3.5, despite a recent version (1.20.4) closing bugs #84088 and #83969, saying Standards-Version 3.5.0 was accounted for. What's up? Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: spurious INSTALL file in docs
Ooh, I already found it. debian/docs was the culprit. On Fri, Feb 16, 2001 at 11:24:58PM +1100, Drew Parsons wrote: > I'm trying to tidy up my package gworldclock. > There's an INSTALL file in the package root directory (from the upstream > edition), but it's not referred to in the build process. It's just a > standard informative file for autoconf. > > Now debian/rules simply handles docs by invoking dh_installdocs. > However, on installing the package, for some reason I find that INSTALL.gz > gets itself installed into /usr/share/doc/gworldclock. > > Can anyone hazard a guess why? It really shouldn't be there, and I can't see > how it got there either. > > Drew > -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
spurious INSTALL file in docs
I'm trying to tidy up my package gworldclock. There's an INSTALL file in the package root directory (from the upstream edition), but it's not referred to in the build process. It's just a standard informative file for autoconf. Now debian/rules simply handles docs by invoking dh_installdocs. However, on installing the package, for some reason I find that INSTALL.gz gets itself installed into /usr/share/doc/gworldclock. Can anyone hazard a guess why? It really shouldn't be there, and I can't see how it got there either. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
