Re: DH_COMPAT 2 or 3 ?
On Tue, Apr 03, 2001 at 09:40:43PM +0200, Ivo Timmermans wrote: > Sven LUTHER wrote: > > > or build dependencies on debhelper (>>3.0) > > > > Yes, but since i want ot build the package on both potato and unstable, this > > will not help. > > Why exactly? It's not a crime to create two separate packages; one > for stable and one for unstable. You can change the build > dependencies to match the distribution. Well, the idea is to have only one package for both, this make things simpler, create less work for me, and should be more error proof in general. Anyway, forking a package for 2 lines difference in the debian/rules file, and different build-depends don't seem worth it for me. Friendly, Sven Luther
directory in .deb
Hello, I'm not sure if I'm welcome her, because I'm not maintaining a official debian-package but trying to make .deb's out of my tools. I have a tool that needs a directory /var/log/ppplog. It is contained in data.tar.gz, but tar does not set the required right on the directory (right?). So I set the right in the postinst script. Is this the correct way to handle directories, or should I leave the creation of the directory to postinst too. The package also puts a executable in /etc/ppp/ip-down.d. Building the binary leads to a complain about an executable in unusual place (or so). Can I prevent this? Are there naming-conventions for script in /etc/ppp/ip-down.d? MfG bmg -- "Des is völlig wurscht, was heut beschlos- | M G Berberich sen wird: I bin sowieso dagegn!" | [EMAIL PROTECTED] (SPD-Stadtrat Kurt Schindler; Regensburg) | www.fmi.uni-passau.de/~berberic pgplE4CObBg0g.pgp Description: PGP signature
Re: directory in .deb
* M G Berberich | I'm not sure if I'm welcome her, because I'm not maintaining a | official debian-package but trying to make .deb's out of my tools. No problem. We are including here. :) | I have a tool that needs a directory /var/log/ppplog. It is contained | in data.tar.gz, but tar does not set the required right on the | directory (right?). So I set the right in the postinst script. It's usually better to set it in the package building script. Less messy, IMHO. | The package also puts a executable in /etc/ppp/ip-down.d. Building the | binary leads to a complain about an executable in unusual place (or | so). Can I prevent this? Are there naming-conventions for script in | /etc/ppp/ip-down.d? I don't know. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: DH_COMPAT 2 or 3 ?
On Wed, Apr 04, 2001 at 07:44:34AM +0200, Sven LUTHER wrote: > > Why exactly? It's not a crime to create two separate packages; one > > for stable and one for unstable. You can change the build > > dependencies to match the distribution. > > Well, the idea is to have only one package for both, this make things simpler, > create less work for me, and should be more error proof in general. > > Anyway, forking a package for 2 lines difference in the debian/rules file, and > different build-depends don't seem worth it for me. So it'll potentially create different binaries with the same version number on the different platforms. Hmm. Why not just go with the potato version? It should work fine on unstable. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: directory in .deb
On Wed, Apr 04, 2001 at 11:50:25AM +0200, M G Berberich wrote: > Hello, > > I'm not sure if I'm welcome her, because I'm not maintaining a > official debian-package but trying to make .deb's out of my tools. > > I have a tool that needs a directory /var/log/ppplog. It is contained > in data.tar.gz, but tar does not set the required right on the > directory (right?). So I set the right in the postinst script. Why is it not correct? Did you build the package as root or under fakeroot, or as a normal user? Have you read the various packaging guides found on http://www.debian.org/devel/? > The package also puts a executable in /etc/ppp/ip-down.d. Building the > binary leads to a complain about an executable in unusual place (or > so). Can I prevent this? Are there naming-conventions for script in > /etc/ppp/ip-down.d? What complains? If it's lintian and what you're doing is correct, don't worry about it. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: DH_COMPAT 2 or 3 ?
On Wed, Apr 04, 2001 at 01:17:06PM +0100, Julian Gilbey wrote: > On Wed, Apr 04, 2001 at 07:44:34AM +0200, Sven LUTHER wrote: > > > Why exactly? It's not a crime to create two separate packages; one > > > for stable and one for unstable. You can change the build > > > dependencies to match the distribution. > > > > Well, the idea is to have only one package for both, this make things > > simpler, > > create less work for me, and should be more error proof in general. > > > > Anyway, forking a package for 2 lines difference in the debian/rules file, > > and > > different build-depends don't seem worth it for me. > > So it'll potentially create different binaries with the same version > number on the different platforms. Hmm. Why not just go with the > potato version? It should work fine on unstable. I don't package for potato, only for unstable. The version in potato is very old, and upstream did 2 releases since then (1 major and 1 minor). The reason for this question, was that someone wanted to build unofficial potato packages out of my source package for unstable. It caused some problems because i was depending on tcl/tk 8.3, while potato only has tcl/tk 8.2. Also, the package configure script did check for tcl.h to determine the version of tcl/tk installed on the system, and this file got moved from the potato version of tcl/tk (both all 8.0 forks and 8.2) (/usr/include/tcl.h) and the newer versions of tcl/tk for unstable (well 8.2 and 8.3, not 8.0, which conserve the old location). (/usr/include/tcl8.[23]/tcl.h). Now i solved this by fixing the upstream configure script and providing upstream with my patch, but it could have been nice also to provide a way to tell the package that you are under a potato system, or unstable/woody system, for this, and to build-depend on the correct tcl/tk. Notice that this is not so much a problem for potato, since apt in potato don't support build depends, but in the forthcoming woody release, apt will be able to support build depends, so this could cause problems. Friendly, Sven Luther
Re: DH_COMPAT 2 or 3 ?
On Wed, Apr 04, 2001 at 02:31:23PM +0200, Sven LUTHER wrote: > > So it'll potentially create different binaries with the same version > > number on the different platforms. Hmm. Why not just go with the > > potato version? It should work fine on unstable. > > I don't package for potato, only for unstable. The version in potato is very > old, and upstream did 2 releases since then (1 major and 1 minor). The reason > for this question, was that someone wanted to build unofficial potato packages > out of my source package for unstable. It caused some problems because i was > depending on tcl/tk 8.3, while potato only has tcl/tk 8.2. Yeesh. Sounds yucky. If that's the need, I would be tempted to make a variant .diff.gz just for potato. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: directory in .deb
Hello, Am Mittwoch, den 04. April 2001 13:19:09 schrieb Julian Gilbey: > On Wed, Apr 04, 2001 at 11:50:25AM +0200, M G Berberich wrote: > > I have a tool that needs a directory /var/log/ppplog. It is contained > > in data.tar.gz, but tar does not set the required right on the > > directory (right?). So I set the right in the postinst script. > > Why is it not correct? Don't know. I wanted to make sure it really is. > Did you build the package as root or under fakeroot, or as a normal > user? Have you read the various packaging guides found on > http://www.debian.org/devel/? fakeroot. And I have read various documentation. > > The package also puts a executable in /etc/ppp/ip-down.d. Building the > > binary leads to a complain about an executable in unusual place (or > > so). Can I prevent this? Are there naming-conventions for script in > > /etc/ppp/ip-down.d? > > What complains? If it's lintian and what you're doing is correct, > don't worry about it. debstd says: Warning: Unusual executable location etc/ppp/ip-down.d/accounting MfG bmg -- "Des is völlig wurscht, was heut beschlos- | M G Berberich sen wird: I bin sowieso dagegn!" | [EMAIL PROTECTED] (SPD-Stadtrat Kurt Schindler; Regensburg) | www.fmi.uni-passau.de/~berberic pgpW5jPXKzYEu.pgp Description: PGP signature
Re: directory in .deb
On Wed, Apr 04, 2001 at 04:28:47PM +0200, M G Berberich wrote: > fakeroot. And I have read various documentation. Great. > > > The package also puts a executable in /etc/ppp/ip-down.d. Building the > > > binary leads to a complain about an executable in unusual place (or > > > so). Can I prevent this? Are there naming-conventions for script in > > > /etc/ppp/ip-down.d? > > > > What complains? If it's lintian and what you're doing is correct, > > don't worry about it. > > debstd says: > > Warning: Unusual executable location etc/ppp/ip-down.d/accounting I would recommend using (dh-make/dh_make and) debhelper rather than debstd. It's much easier to use and more easily fine-tuneable than debstd. Incidentally, this bug has been fixed in unstable and testing. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Compiled pyton files for all arch?
Hi, I'm the maintainer of plucker, a python module for web scooping for the PalmOS. The package contains pyton files, .py, .pyc and .pyo, but no other executables, but for the moment I have a setup that produces one deb for each arch. The python tutorial says .pyc are arch independent, but when I compared the .pyc from the i386 and powerpc debs, there were some small differences. E.g. there is a string with the arch, and then a few differing bits in the end and beginning. Are these just som note about the compilation environment/time etc.? I think I ought to produce an architecture:any package instead, am I right? Anyone want to confirm, or test it? TIA, Micce -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22]
Python script
Questions which arise for me in creating an unofficial Debian package for a Python based script: - the upstream Python script is called 'script.py'. Should I keep the .py extension or drop it? - should this script be installed in /usr/bin like any other regular program? - the upstream tarball has no man-page, so I'd created one and am not sure how to name it: 'script.py.1', 'script.1'? Michael -- [EMAIL PROTECTED] http://www.miwie.org [EMAIL PROTECTED]
RE: Python script
On 04-Apr-2001 Michael Wiedmann wrote: > Questions which arise for me in creating an unofficial Debian > package for a Python based script: > > - the upstream Python script is called 'script.py'. Should I keep > the .py extension or drop it? > Either is fine. > - should this script be installed in /usr/bin like any other > regular program? > as a package, yes. > - the upstream tarball has no man-page, so I'd created one > and am not sure how to name it: 'script.py.1', 'script.1'? > if it is foo.py, you get foo.py.1, if it is foo you get foo.1. BTW there is a program which takes --help output and makes a manpage. I think it is called help2man.
Re: Compiled pyton files for all arch?
Mikael, > I think I ought to produce an architecture:any package instead, am I > right? Anyone want to confirm, or test it? Use 'all' if you - have only .py files - use only platform independent Python modules - have no C extension modules Use 'any' if you - use only platform independent Python modules (this allows that you have some C extension modules, but they must be platform independent) Use the appropriate arch if you are not platform independent. You should compile the Python modules in your postinst script, because .pyc or .pyo files are not version-compatible. Look at python-base postinst (and prerm) scripts for an example! Bastian pgpcd33WwX9IW.pgp Description: PGP signature
Re: Compiled pyton files for all arch?
Mikael Hedin <[EMAIL PROTECTED]> writes: > The python tutorial says .pyc are arch independent, but when I > compared the .pyc from the i386 and powerpc debs, there were some > small differences. E.g. there is a string with the arch, and then a > few differing bits in the end and beginning. Are these just som > note about the compilation environment/time etc.? In practice, I think (but have no actual proof) that the interpreter will try to recompile them if they were made on a different architecture... but if it does, you won't notice anything but slower loading times. As far as I am aware, pyc/pyo objects are not guaranteed to be compatible with anything in particular -- they are really just a cache for the Python interpreter's private use, and their format has changed on at least one occasion. Thus, it probably isn't a good idea to distribute them as long as we actually have the original source files they are made from. Most (all?) other packages with Python code in them include only the source, and will compile the pyc/pyo files in the postinst script. I would suggest that you look at some of them to see how this is done; you can just copy the appropriate snippet from the postinst and prerm of one of them. If your package contains only Python code, you can then safely make it Architecture: any. --Rob -- Rob Tillotson N9MTB <[EMAIL PROTECTED]>
uupdate and .rej files
As some of you told me, I try to use uupdate with new upstream release. I know that uupdate try to apply the diff.gz patches to the new upstream versione and when I can't do it cleanly creates a .rej file. I can't understand what the .rej files really are. It seems to me that the corrisponding file (without .rej extensione) is not the origianl upstream version of the file nor the previous version one. And also, more important, what I have to do with a .rej file ? I guess that I have to integrate this file with the corrisponding file but I can't understand exactly what I have to look for ... Moreover, the package seems to work correctly even if I ignore the existence of .rej file, is it possible ? Help needed TIA -- - Zack - Stefano Zacchiroli <[EMAIL PROTECTED]> ICQ# 33538863 Home Page: http://www.students.cs.unibo.it/~zacchiro Undergraduate Student of Computer Science at University of Bologna, Italy SysAdm of verdicchio.students.cs.unibo.it (130.136.3.134) "Information wants to be Open" pgpKFPfUuYgVT.pgp Description: PGP signature
Re: Compiled pyton files for all arch?
Rob Tillotson <[EMAIL PROTECTED]> writes: > If your package contains only Python code, you can then safely make it > Architecture: any. Er, I meant "all". Sorry. :) --Rob -- Rob Tillotson N9MTB <[EMAIL PROTECTED]>
Re: Undocumented binary
On Tue, 3 Apr 2001, peter karlsson wrote: > Steve M. Robbins: > > > The undocumented page provides no more information than "No manual > > entry for foo" (but the former is much longer to read). What is the > > point? > > Personally, I reason that if I get "No manual entry", it is a program > that probably shouldn't have entered myself, but if I get undocumented, > it's something that I can use, but no-one has ever bothered informing > me of it. I have a different point of view. If I get "No manual entry for foo" I know at once that nobody has written a man page. (I know the program is there because I have run it already but had some problems). When there is an "undocumented" manpage instead, man tells me "Reformatting foo(1), please wait..." and I think "Aah lets see how ... f*<$! Another lazy maintainer again!" It really is annoying! And back to the first post. If you don't want to write 100 manpages for your 100 programs in the package you can at least write one and symlink it to the other 99 names. -- Manfred Wassmann PGP and GnuPG public keys available at http://germany.keyserver.net PGP: 24B81049 Fingerprint: D7 10 EE 2B 74 16 C0 64 B4 5F BA B2 90 29 3D AF GPG: 6B299971 Fingerprint: A598 A41F 57A3 5D69 83D2 8027 1274 F8CD 6B29 9971 +++ I18N ? For international language set LANG=POSIX +++
directory in .deb
Hello, I'm not sure if I'm welcome her, because I'm not maintaining a official debian-package but trying to make .deb's out of my tools. I have a tool that needs a directory /var/log/ppplog. It is contained in data.tar.gz, but tar does not set the required right on the directory (right?). So I set the right in the postinst script. Is this the correct way to handle directories, or should I leave the creation of the directory to postinst too. The package also puts a executable in /etc/ppp/ip-down.d. Building the binary leads to a complain about an executable in unusual place (or so). Can I prevent this? Are there naming-conventions for script in /etc/ppp/ip-down.d? MfG bmg -- "Des is völlig wurscht, was heut beschlos- | M G Berberich sen wird: I bin sowieso dagegn!" | [EMAIL PROTECTED] (SPD-Stadtrat Kurt Schindler; Regensburg) | www.fmi.uni-passau.de/~berberic PGP signature
Re: directory in .deb
* M G Berberich | I'm not sure if I'm welcome her, because I'm not maintaining a | official debian-package but trying to make .deb's out of my tools. No problem. We are including here. :) | I have a tool that needs a directory /var/log/ppplog. It is contained | in data.tar.gz, but tar does not set the required right on the | directory (right?). So I set the right in the postinst script. It's usually better to set it in the package building script. Less messy, IMHO. | The package also puts a executable in /etc/ppp/ip-down.d. Building the | binary leads to a complain about an executable in unusual place (or | so). Can I prevent this? Are there naming-conventions for script in | /etc/ppp/ip-down.d? I don't know. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DH_COMPAT 2 or 3 ?
On Wed, Apr 04, 2001 at 07:44:34AM +0200, Sven LUTHER wrote: > > Why exactly? It's not a crime to create two separate packages; one > > for stable and one for unstable. You can change the build > > dependencies to match the distribution. > > Well, the idea is to have only one package for both, this make things simpler, > create less work for me, and should be more error proof in general. > > Anyway, forking a package for 2 lines difference in the debian/rules file, and > different build-depends don't seem worth it for me. So it'll potentially create different binaries with the same version number on the different platforms. Hmm. Why not just go with the potato version? It should work fine on unstable. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: directory in .deb
On Wed, Apr 04, 2001 at 11:50:25AM +0200, M G Berberich wrote: > Hello, > > I'm not sure if I'm welcome her, because I'm not maintaining a > official debian-package but trying to make .deb's out of my tools. > > I have a tool that needs a directory /var/log/ppplog. It is contained > in data.tar.gz, but tar does not set the required right on the > directory (right?). So I set the right in the postinst script. Why is it not correct? Did you build the package as root or under fakeroot, or as a normal user? Have you read the various packaging guides found on http://www.debian.org/devel/? > The package also puts a executable in /etc/ppp/ip-down.d. Building the > binary leads to a complain about an executable in unusual place (or > so). Can I prevent this? Are there naming-conventions for script in > /etc/ppp/ip-down.d? What complains? If it's lintian and what you're doing is correct, don't worry about it. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DH_COMPAT 2 or 3 ?
On Wed, Apr 04, 2001 at 01:17:06PM +0100, Julian Gilbey wrote: > On Wed, Apr 04, 2001 at 07:44:34AM +0200, Sven LUTHER wrote: > > > Why exactly? It's not a crime to create two separate packages; one > > > for stable and one for unstable. You can change the build > > > dependencies to match the distribution. > > > > Well, the idea is to have only one package for both, this make things simpler, > > create less work for me, and should be more error proof in general. > > > > Anyway, forking a package for 2 lines difference in the debian/rules file, and > > different build-depends don't seem worth it for me. > > So it'll potentially create different binaries with the same version > number on the different platforms. Hmm. Why not just go with the > potato version? It should work fine on unstable. I don't package for potato, only for unstable. The version in potato is very old, and upstream did 2 releases since then (1 major and 1 minor). The reason for this question, was that someone wanted to build unofficial potato packages out of my source package for unstable. It caused some problems because i was depending on tcl/tk 8.3, while potato only has tcl/tk 8.2. Also, the package configure script did check for tcl.h to determine the version of tcl/tk installed on the system, and this file got moved from the potato version of tcl/tk (both all 8.0 forks and 8.2) (/usr/include/tcl.h) and the newer versions of tcl/tk for unstable (well 8.2 and 8.3, not 8.0, which conserve the old location). (/usr/include/tcl8.[23]/tcl.h). Now i solved this by fixing the upstream configure script and providing upstream with my patch, but it could have been nice also to provide a way to tell the package that you are under a potato system, or unstable/woody system, for this, and to build-depend on the correct tcl/tk. Notice that this is not so much a problem for potato, since apt in potato don't support build depends, but in the forthcoming woody release, apt will be able to support build depends, so this could cause problems. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DH_COMPAT 2 or 3 ?
On Wed, Apr 04, 2001 at 02:31:23PM +0200, Sven LUTHER wrote: > > So it'll potentially create different binaries with the same version > > number on the different platforms. Hmm. Why not just go with the > > potato version? It should work fine on unstable. > > I don't package for potato, only for unstable. The version in potato is very > old, and upstream did 2 releases since then (1 major and 1 minor). The reason > for this question, was that someone wanted to build unofficial potato packages > out of my source package for unstable. It caused some problems because i was > depending on tcl/tk 8.3, while potato only has tcl/tk 8.2. Yeesh. Sounds yucky. If that's the need, I would be tempted to make a variant .diff.gz just for potato. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: directory in .deb
Hello, Am Mittwoch, den 04. April 2001 13:19:09 schrieb Julian Gilbey: > On Wed, Apr 04, 2001 at 11:50:25AM +0200, M G Berberich wrote: > > I have a tool that needs a directory /var/log/ppplog. It is contained > > in data.tar.gz, but tar does not set the required right on the > > directory (right?). So I set the right in the postinst script. > > Why is it not correct? Don't know. I wanted to make sure it really is. > Did you build the package as root or under fakeroot, or as a normal > user? Have you read the various packaging guides found on > http://www.debian.org/devel/? fakeroot. And I have read various documentation. > > The package also puts a executable in /etc/ppp/ip-down.d. Building the > > binary leads to a complain about an executable in unusual place (or > > so). Can I prevent this? Are there naming-conventions for script in > > /etc/ppp/ip-down.d? > > What complains? If it's lintian and what you're doing is correct, > don't worry about it. debstd says: Warning: Unusual executable location etc/ppp/ip-down.d/accounting MfG bmg -- "Des is völlig wurscht, was heut beschlos- | M G Berberich sen wird: I bin sowieso dagegn!" | [EMAIL PROTECTED] (SPD-Stadtrat Kurt Schindler; Regensburg) | www.fmi.uni-passau.de/~berberic PGP signature
Re: directory in .deb
On Wed, Apr 04, 2001 at 04:28:47PM +0200, M G Berberich wrote: > fakeroot. And I have read various documentation. Great. > > > The package also puts a executable in /etc/ppp/ip-down.d. Building the > > > binary leads to a complain about an executable in unusual place (or > > > so). Can I prevent this? Are there naming-conventions for script in > > > /etc/ppp/ip-down.d? > > > > What complains? If it's lintian and what you're doing is correct, > > don't worry about it. > > debstd says: > > Warning: Unusual executable location etc/ppp/ip-down.d/accounting I would recommend using (dh-make/dh_make and) debhelper rather than debstd. It's much easier to use and more easily fine-tuneable than debstd. Incidentally, this bug has been fixed in unstable and testing. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Compiled pyton files for all arch?
Hi, I'm the maintainer of plucker, a python module for web scooping for the PalmOS. The package contains pyton files, .py, .pyc and .pyo, but no other executables, but for the moment I have a setup that produces one deb for each arch. The python tutorial says .pyc are arch independent, but when I compared the .pyc from the i386 and powerpc debs, there were some small differences. E.g. there is a string with the arch, and then a few differing bits in the end and beginning. Are these just som note about the compilation environment/time etc.? I think I ought to produce an architecture:any package instead, am I right? Anyone want to confirm, or test it? TIA, Micce -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Python script
Questions which arise for me in creating an unofficial Debian package for a Python based script: - the upstream Python script is called 'script.py'. Should I keep the .py extension or drop it? - should this script be installed in /usr/bin like any other regular program? - the upstream tarball has no man-page, so I'd created one and am not sure how to name it: 'script.py.1', 'script.1'? Michael -- [EMAIL PROTECTED] http://www.miwie.org [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Python script
On 04-Apr-2001 Michael Wiedmann wrote: > Questions which arise for me in creating an unofficial Debian > package for a Python based script: > > - the upstream Python script is called 'script.py'. Should I keep > the .py extension or drop it? > Either is fine. > - should this script be installed in /usr/bin like any other > regular program? > as a package, yes. > - the upstream tarball has no man-page, so I'd created one > and am not sure how to name it: 'script.py.1', 'script.1'? > if it is foo.py, you get foo.py.1, if it is foo you get foo.1. BTW there is a program which takes --help output and makes a manpage. I think it is called help2man. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compiled pyton files for all arch?
Mikael, > I think I ought to produce an architecture:any package instead, am I > right? Anyone want to confirm, or test it? Use 'all' if you - have only .py files - use only platform independent Python modules - have no C extension modules Use 'any' if you - use only platform independent Python modules (this allows that you have some C extension modules, but they must be platform independent) Use the appropriate arch if you are not platform independent. You should compile the Python modules in your postinst script, because .pyc or .pyo files are not version-compatible. Look at python-base postinst (and prerm) scripts for an example! Bastian PGP signature
Re: Compiled pyton files for all arch?
Mikael Hedin <[EMAIL PROTECTED]> writes: > The python tutorial says .pyc are arch independent, but when I > compared the .pyc from the i386 and powerpc debs, there were some > small differences. E.g. there is a string with the arch, and then a > few differing bits in the end and beginning. Are these just som > note about the compilation environment/time etc.? In practice, I think (but have no actual proof) that the interpreter will try to recompile them if they were made on a different architecture... but if it does, you won't notice anything but slower loading times. As far as I am aware, pyc/pyo objects are not guaranteed to be compatible with anything in particular -- they are really just a cache for the Python interpreter's private use, and their format has changed on at least one occasion. Thus, it probably isn't a good idea to distribute them as long as we actually have the original source files they are made from. Most (all?) other packages with Python code in them include only the source, and will compile the pyc/pyo files in the postinst script. I would suggest that you look at some of them to see how this is done; you can just copy the appropriate snippet from the postinst and prerm of one of them. If your package contains only Python code, you can then safely make it Architecture: any. --Rob -- Rob Tillotson N9MTB <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
uupdate and .rej files
As some of you told me, I try to use uupdate with new upstream release. I know that uupdate try to apply the diff.gz patches to the new upstream versione and when I can't do it cleanly creates a .rej file. I can't understand what the .rej files really are. It seems to me that the corrisponding file (without .rej extensione) is not the origianl upstream version of the file nor the previous version one. And also, more important, what I have to do with a .rej file ? I guess that I have to integrate this file with the corrisponding file but I can't understand exactly what I have to look for ... Moreover, the package seems to work correctly even if I ignore the existence of .rej file, is it possible ? Help needed TIA -- - Zack - Stefano Zacchiroli <[EMAIL PROTECTED]> ICQ# 33538863 Home Page: http://www.students.cs.unibo.it/~zacchiro Undergraduate Student of Computer Science at University of Bologna, Italy SysAdm of verdicchio.students.cs.unibo.it (130.136.3.134) "Information wants to be Open" PGP signature
Re: Compiled pyton files for all arch?
Rob Tillotson <[EMAIL PROTECTED]> writes: > If your package contains only Python code, you can then safely make it > Architecture: any. Er, I meant "all". Sorry. :) --Rob -- Rob Tillotson N9MTB <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Undocumented binary
On Tue, 3 Apr 2001, peter karlsson wrote: > Steve M. Robbins: > > > The undocumented page provides no more information than "No manual > > entry for foo" (but the former is much longer to read). What is the > > point? > > Personally, I reason that if I get "No manual entry", it is a program > that probably shouldn't have entered myself, but if I get undocumented, > it's something that I can use, but no-one has ever bothered informing > me of it. I have a different point of view. If I get "No manual entry for foo" I know at once that nobody has written a man page. (I know the program is there because I have run it already but had some problems). When there is an "undocumented" manpage instead, man tells me "Reformatting foo(1), please wait..." and I think "Aah lets see how ... f*<$! Another lazy maintainer again!" It really is annoying! And back to the first post. If you don't want to write 100 manpages for your 100 programs in the package you can at least write one and symlink it to the other 99 names. -- Manfred Wassmann PGP and GnuPG public keys available at http://germany.keyserver.net PGP: 24B81049 Fingerprint: D7 10 EE 2B 74 16 C0 64 B4 5F BA B2 90 29 3D AF GPG: 6B299971 Fingerprint: A598 A41F 57A3 5D69 83D2 8027 1274 F8CD 6B29 9971 +++ I18N ? For international language set LANG=POSIX +++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
