Have X11/app-defaults moved in unstable?
Hi! May I have missed something and in unstable /usr/lib/X11/app-defaults moved to /etc/X11/app-defaults? My package actually doesn't use app-defaults. I noticed this when I compiled a package from unstable on my stable box and got error messages on a missing file in app-defaults. Christoph -- * Christoph Baumann * * [EMAIL PROTECTED] * * www.rzuser.uni-heidelberg.de/~cbauman1/welcome.html* * External Error : INTELLIGENCE not found !* -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Integration of debian/ scripts in packages
On Tue, Jun 05, 2001 at 04:01:20AM +0100, Mich?l Alexandre Salim wrote: Rather a neat idea. And certainly I have seen it implemented - for Enlightenment 0.17 CVS for instance. It is still the duty of the Debian maintainer to make sure the Debian version of the scripts conform to Debian specifications, but if something major changes in the package the author(s) would know best what has changes. So it is a two-way process: if Debian policy changes the maintainer informs the author, if the packaging changes the author-maintained debian scripts will still allow building of the package seamlessly while the Debian maintainer work on integrating the changes. The reason why I integrated the debian directory into e2fsprogs was an attempt to minimize the size of the .diff file so I could see what changes the Debian maintainer might make to my package in the future. I've always considered it a serious defect that .diff file contains both Debian packaging changes as well as changes to the upstream source. RPM's are much friendlier to the upstream maintainer because the changes are separated into separate patch files. When maintainers make a large number of changes to the package (sometimes with or without informing the upstream author), the single .diff file can get quite unmangeable. It certainly makes it difficult for someone who is looking at the sources to get a good idea of what has been done to the package in the process of Debianizing it. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Integration of debian/ scripts in packages
On Tue, Jun 05, 2001 at 04:01:20AM +0100, Mich?l Alexandre Salim wrote: Rather a neat idea. And certainly I have seen it implemented - for Enlightenment 0.17 CVS for instance. It is still the duty of the Debian maintainer to make sure the Debian version of the scripts conform to Debian specifications, but if something major changes in the package the author(s) would know best what has changes. So it is a two-way process: if Debian policy changes the maintainer informs the author, if the packaging changes the author-maintained debian scripts will still allow building of the package seamlessly while the Debian maintainer work on integrating the changes. The reason why I integrated the debian directory into e2fsprogs was an attempt to minimize the size of the .diff file so I could see what changes the Debian maintainer might make to my package in the future. I've always considered it a serious defect that .diff file contains both Debian packaging changes as well as changes to the upstream source. RPM's are much friendlier to the upstream maintainer because the changes are separated into separate patch files. When maintainers make a large number of changes to the package (sometimes with or without informing the upstream author), the single .diff file can get quite unmangeable. It certainly makes it difficult for someone who is looking at the sources to get a good idea of what has been done to the package in the process of Debianizing it. - Ted
Re: Have X11/app-defaults moved in unstable?
Christoph Baumann [EMAIL PROTECTED] wrote: May I have missed something and in unstable /usr/lib/X11/app-defaults moved to /etc/X11/app-defaults? My package actually doesn't use app-defaults. I noticed this when I compiled a package from unstable on my stable box and got error messages on a missing file in app-defaults. Yes. [rummages] See current policy, section 12.8.6. -- Colin Watson [EMAIL PROTECTED]
Re: Fwd: ITP: glib2, gtk2, inti
On Wed, 6 Jun 2001, Paolo Molaro wrote: On 06/05/01 Michèl Alexandre Salim wrote: Please LART upstream heavily and give the packages a proper name. That tradition has done it wrong is no reason to continue doing it the wrong way. The version numbering used upstream is completely reasonable: check the archives for the discussions, non need to replay them again. It is not reasonable. The major number of a library should change IFF there is a backwards-incompatible change in the library's binary interface; and the Debian package name should reflect the major number of the library. Any other arrangement, though it may seem 'reasonable' to the library authors, is a disaster for people in the real world who have to work with such libraries from the outside. Well this is a bit late :) Following the current Debian package names I am calling them libglib1.3, libgtk+1.3 since they are not backward-compatible with the 1.2 series yet might change prior to version 2.0 Note that probably all the gtk 1.3.x releases will be incompatible, so the package names should include also the micro number. If they want to call the upstream package 'gtk 1.3.x' to indicate where in the development cycle they are, that's fine; but the library soname should not be governed by marketing, and upstream /should/ be LARTed for this. Steve Langasek postmodern programmer
Re: ITP: gphoto2 -- digital camera library (conflict with libusb0)
I put it in contrib, since the licensing is a bit unclear. It probably belongs in main. The LGPL core do dynamically loading of GPL drivers - without explicit notice that that is allowed. There's no license conflict there. The GPL only allows linking with other code under the GPL, but the LGPL allows an automatic upgrade to GPL status, so the two can be linked with no problem. If an LGPL core loads GPL and non-GPL drivers at the same time, then that could be a problem, but if all of your drivers are (L)GPL, you're ok. Eric
Re: porting problem and how to request help
On Tue, Jun 05, 2001 at 07:51:08PM +0200, Stefano Zacchiroli wrote: Some weeks ago I received Bug#96254 on one of my package: ocaml-xstr, the problem is a build failure on a m68k machine. The reason is that a package needed in ocaml-xstr compilation named ocaml-findlib, does not work well on a m68k architecture. I forwarded the problem to the upstream author and I told me that he does not like to solve architecture specific problem, OTOH I do not have time and knowledge to debug problems on m68k arch. How can I solve the problem? May I ask for help on debian-devel or on debian-m68k ML? Cause the problem is related to another package, may I close the bug on ocaml-xstr and fill a new one against ocaml-findlib? I would say the best idea would be to write to debian-m68k, or maybe to some of the proters directly. Who did make the bugreport to you ? what does he have to say about this ? Friendl,y, Sven Luther
Re: Fwd: ITP: glib2, gtk2, inti
On 06/05/01 Michèl Alexandre Salim wrote: Please LART upstream heavily and give the packages a proper name. That tradition has done it wrong is no reason to continue doing it the wrong way. The version numbering used upstream is completely reasonable: check the archives for the discussions, non need to replay them again. Well this is a bit late :) Following the current Debian package names I am calling them libglib1.3, libgtk+1.3 since they are not backward-compatible with the 1.2 series yet might change prior to version 2.0 Note that probably all the gtk 1.3.x releases will be incompatible, so the package names should include also the micro number. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
Re: porting problem and how to request help
On Tue, 5 Jun 2001, Stefano Zacchiroli wrote: Some weeks ago I received Bug#96254 on one of my package: ocaml-xstr, the problem is a build failure on a m68k machine. The reason is that a package needed in ocaml-xstr compilation named ocaml-findlib, does not work well on a m68k architecture. I forwarded the problem to the upstream author and I told me that he does not like to solve architecture specific problem, OTOH I do not have time and knowledge to debug problems on m68k arch. How can I solve the problem? The quick and ugly way is of course to build a new debian package that excludes m68k from the supported architectures. *t Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: OK to use /etc/default for non-init script default data?
On Tue, Jun 05, 2001 at 04:40:06PM +0200, Marc Haber wrote: On Tue, Jun 05, 2001 at 11:01:22AM +0200, Marc Haber wrote: And if it's a wrapper script, wouldn't it be a lot better to have the wrapper in /usr/bin, with the real program called something like foo.real, and just the variable settings in /etc? Everything else would be a policy violation. Please explain how my suggest would violate policy. It wouldn't. Good, so maybe that's a good way to consider doing things. If it's the Right Thing to do, and it violates policy, we should modify policy. Having non-conffile executeable code in /etc would violate policy, and this is what we both try to avoid. Gosh, yes. That would be horrid. 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: Integration of debian/ scripts in packages
Michèl == Michèl Alexandre Salim [EMAIL PROTECTED] writes: Michèl Hello, A general observation of Unix programs in general - Michèl a lot more of them come with RPM spec files, even Michèl generates them automatically from a spec.in file, than Michèl with debian scripts. A lot of this has to do with the relative value of doing so. An RPM outside of the Redhat archive is more common than a deb outside of the Debian archive. Debian is willing to accept most DFSG free packages into its archive, so users can get a good approximation of all the Debian software available by looking at what is in unstable. RPM-based distributions tend to be more selective about what they accept. Thus, a user is going to be just as likely to go to the original author as to their distribution to find software. As a Debian user, I will tend to go to Debian before the original author. If there is a debian directory, I am likely to find it already in Debian and never get to the original author's site. Note that Debian directories outside of Debian have dubious utility. Really only the maintainer should be editing debian/changelog, but yet if debian/changelog doesn't match the version of software, then siginifacnt problems may result..
Re: How to handle ´/etc/ld.so.preload library packages?
Marc Haber [EMAIL PROTECTED] writes: (2) Ask the user if I should add the lib to /etc/ld.so.preload in the postinst and automatically remove the entry in prerm? Does order in /etc/ld.so.preload matter? I'd guess that order is significant if more than one preloaded lib defines the same symbol. I'm not sure whether deterministic behavious is guaranteed at all in this case ... better to avoid this. My solution would be to show the proposed new ld.so.preload (with the lib added in postinst, with it removed in the prerm), or perhaps a unidiff to the admin, and ask for her approval. (3) Do everything fully automatic? I would feel a bit uncomfortable with this ... one error in your package and its pretty much rescue disk time[1]. Perhaps a nice feature would be to first set LD_PRELOAD at the top of your postinst, so that it automatically fails before installing your library into ld.so.preload, whenever something is wrong with the lib. I don't know how this would fare on upgrades, though. [1] Unless a standalone shell is handy, or a suitably powerful program running. -- Robbe signature.ng Description: PGP signature
Re: OK to use /etc/default for non-init script default data?
Marc Haber wrote: This is the way to do it for an init script. Is it OK to have a file in /etc/default that does not provider defaults for an init script but for an executeable called by users? I don't know. I don't see a lot of advantage over just putting the conffile in /etc. There is something to be said for leaving /etc/default/ only for init scripts. Of course, default is perhaps not the best name for it if it only holds init script configs. -- see shy jo
Re: Integration of debian/ scripts in packages
Michèl == Michèl Alexandre Salim [EMAIL PROTECTED] writes: Michèl The reason I raise this issue in the first place is Michèl actually a notion that it would be nice for users wanting Michèl bleeding-edge software to update from CVS and just run Michèl debian/rules binary or dpkg-buildpackage, the same way Michèl they can rpm -tb package.tar.gz currently (granted, most Michèl of the time one thing or another is broken. Especially the Michèl changelog - rather incredible). And if you come up with a clean solution for the changelog issue, I agree this is worth doing. If you do that, please let me know what your solution is.
Re: OK to use /etc/default for non-init script default data?
On Mon, Jun 04, 2001 at 10:31:18AM +0200, Marc Haber wrote: Hi, let's say I have a package foo with a binary foo. The author suggests the one should have a shell script wrapper to be able to call the foo binary with the appropriate options. I want to do so in my package. - Have the foo-Binary in /usr/lib/foo/foo - Have a foo shell script wrapper in /usr/bin/foo - /usr/bin/foo sources /etc/default/foo so that the admin can change the default values without interfering with the wrapper itself. This is the way to do it for an init script. Is it OK to have a file in /etc/default that does not provider defaults for an init script but for an executeable called by users? Why not just /etc/foorc or /etc/foo.conf or something like that? I don't know if it's such a great idea to pollute the /etc/default namespace, and it's not intuitive. 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: OK to use /etc/default for non-init script default data?
On Tue, Jun 05, 2001 at 08:43:56AM +0200, Marc Haber wrote: On Mon, 4 Jun 2001 10:12:19 +0100, Julian Gilbey [EMAIL PROTECTED] wrote: Why not just /etc/foorc or /etc/foo.conf or something like that? Because the conffile is not a real conffile, but rather a shell script being sourced in, and /etc/foo.conf will probably suggest that this conffile is an upstream feature. When you say shell script, do you mean that it's a wrapper script, or just a list of settings of the form VAR=value? If you want to make it clear that it's a Debian-specific thing, surely you can put a note to that effect at the top of the file? And if it's a wrapper script, wouldn't it be a lot better to have the wrapper in /usr/bin, with the real program called something like foo.real, and just the variable settings in /etc? It's just that /etc is where people are likely to look 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: Fwd: ITP: glib2, gtk2, inti
* Christian Marillat | MAS Indeed, but for package naming purpose I guess calling | MAS them libglib2 and libgtk2 would work. | | I disagree. The API may change between 1.3.5 and 2.0 GTK has a very, very broken versioning. There is no connection between the soname of a library and the version of it. Take a library like slang. The package name is slang1, which means that the soname has a major version number which is 1. The version number of the package is 1.4.4-1 (in testing). This is the right way to do it - if you make backwards-incompatible changes, bump the soname's version number. Else, don't. Take another package - xlibs6g. It conforms to version 6 of the Xlib specification, while the package's version number is 4.0.3-3. Please LART upstream heavily and give the packages a proper name. That tradition has done it wrong is no reason to continue doing it the wrong way. *sigh* /rant-of-the-week -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: OK to use /etc/default for non-init script default data?
On Tue, Jun 05, 2001 at 11:01:22AM +0200, Marc Haber wrote: If you want to make it clear that it's a Debian-specific thing, surely you can put a note to that effect at the top of the file? Never underestimate the user's stupidity. I don't, but how will the location and user's (sysadmin's) stupidity interact? And if it's a wrapper script, wouldn't it be a lot better to have the wrapper in /usr/bin, with the real program called something like foo.real, and just the variable settings in /etc? Everything else would be a policy violation. Please explain how my suggest would violate policy. If it's the Right Thing to do, and it violates policy, we should modify policy. 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: OK to use /etc/default for non-init script default data?
On Tue, 5 Jun 2001 09:34:37 +0100, Julian Gilbey [EMAIL PROTECTED] wrote: Because the conffile is not a real conffile, but rather a shell script being sourced in, and /etc/foo.conf will probably suggest that this conffile is an upstream feature. When you say shell script, do you mean that it's a wrapper script, or just a list of settings of the form VAR=value? Just a list of settings as it would be appropriate for init script defaults. The entire code was ripped from an init script. If you want to make it clear that it's a Debian-specific thing, surely you can put a note to that effect at the top of the file? Never underestimate the user's stupidity. And if it's a wrapper script, wouldn't it be a lot better to have the wrapper in /usr/bin, with the real program called something like foo.real, and just the variable settings in /etc? Everything else would be a policy violation. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
ITP: gphoto2 -- digital camera library (conflict with libusb0)
I am not a Debian maintainer yet. I signed up to become a Debian maintainer in order to maintain gphoto2, and started the process of becoming one around January, but I could not complete the skill tests due to lack of time and a publicly available version of gphoto2, at that time. So my application was rejected and removed from the applicant web page. I have created Debian packages of gphoto2 2.0 beta1 (+ libusb 0.1.3.b). deb http://www.ping.uio.no/~oka/debian unstable contrib I put it in contrib, since the licensing is a bit unclear. It probably belongs in main. The LGPL core do dynamically loading of GPL drivers - without explicit notice that that is allowed. There is already an older version of libusb (bundled in usbtools) in Debian unstable, but it doesn't provide /usr/bin/libusb-config What should I do next? -- Ole
Re: How to handle ´/etc/ld.so.preload library packages ?
On Tue, 5 Jun 2001 15:32:25 +0200 (CEST), Simon Richter [EMAIL PROTECTED] wrote: On Tue, 5 Jun 2001, Marc Haber wrote: I have a package with a library that needs to be entered to /etc/ld.so.preload. It is clear that this library needs to go in /lib rather than /usr/lib because there are systems that have /usr on a dedicated partition. Are you sure that *every* program needs this library preloaded? Could you tell us some more about the lib? The package in question is an internal package for snoopy (http://www.citi.umich.edu/u/marius/snoopy/), where I am currently experimenting how to optimize the ld.so.preload entry to give a patch to the debian maintainer. But there are other libs (for example libsafe) that need to be loaded this way. But libsafe has its own package ld.so.preload-manager which seems to be a good thing to use here. (2) Ask the user if I should add the lib to /etc/ld.so.preload in the postinst and automatically remove the entry in prerm? Does order in /etc/ld.so.preload matter? I'd go for this solution, however I'd ask in the config script rather than in the postinst. :-) My mistake. You're right. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Adding device file to /dev.
Russell Coker [EMAIL PROTECTED] writes: On Monday 04 June 2001 00:59, Julian Gilbey wrote: On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote: Another thing any package that depends on the creation of nodes under /dev MUST depend on makedev | devfsd. People who run devfsd do not need to have makedev installed. Should this stuff go into policy? I think so. In this case, please also add consideration for the Hurd. hurd package provides makedev so the above would work. makedev ( 1.2.3) | devfsd is a problem, though. -- Robbe signature.ng Description: PGP signature
Re: How to handle ´/etc/ld.so.preload library packages?
On Tue, 5 Jun 2001, Marc Haber wrote: I have a package with a library that needs to be entered to /etc/ld.so.preload. It is clear that this library needs to go in /lib rather than /usr/lib because there are systems that have /usr on a dedicated partition. Are you sure that *every* program needs this library preloaded? Could you tell us some more about the lib? (2) Ask the user if I should add the lib to /etc/ld.so.preload in the postinst and automatically remove the entry in prerm? Does order in /etc/ld.so.preload matter? I'd go for this solution, however I'd ask in the config script rather than in the postinst. :-) Simon -- GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! NP: Distain! - Confession
Re: OK to use /etc/default for non-init script default data?
On Mon, 4 Jun 2001 10:12:19 +0100, Julian Gilbey [EMAIL PROTECTED] wrote: Why not just /etc/foorc or /etc/foo.conf or something like that? Because the conffile is not a real conffile, but rather a shell script being sourced in, and /etc/foo.conf will probably suggest that this conffile is an upstream feature. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Status update: GLib/GTK+ 1.3 CVS
Hello, A brief follow-up to my post last weekend. The current status of my test packages are as follows: GLib - packages created. RFC - I am not a seasoned developer (yet!), any advice more than welcome. Gtk-doc - needed if you want to recompile GNOME CVS modules (including GLib). I have packaged the CVS version, should be stable as I just applied the debian scripts from gtk-doc-package in sid Pango - stuck, problem with shlibs:Depends not being accepted by dpkg-gencontrol as a result of which package has no dependencies. See post to debian-mentors, any help very appreciated Atk GTK+ both waiting for Pango Packages downloadable from sourceforge.net/projects/alterdeb Any new (and would-be) maintainers wanting to put up Debian packages for review more than welcome to put it there as well, just shout :) TIA, Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
Re: ITP: glib2, gtk2, inti
Michèl Alexandre Salim [EMAIL PROTECTED] writes:
Have another problem though, when building libpango0 dpkg-gencontrol
complained thus:
dpkg-gencontrol: warning: unknown substitution
variable ${shlibs:Depends}
The line
dh_shlibdeps -plibpango$(version)
should generate either substvars or libpango0.substvars. If it does,
dh_gencontrol is for some reason not picking that up. If it doesn't it
is either broken, or libpango0 does not depend on any library. You
check the latter case by using ldd on the shared library. It should
usually return at least the C library.
dh_* commands can be run by hand and with -v to get more information.
Or set DH_VERBOSE=1 for running debian/rules.
Attached are the debian/control and debian/rules
files.
Seem ok in looking over. One problem I saw is that you can't safely
run any of the binary targets twice (for example, because you just
fixed an error): install will not be re-run, because install-stamp is
up-to-date, but debian/tmp may not be intact due to rm -rf or
dh_movefiles in the binary targets. I'd remove install-stamp after
altering debian/tmp. Or do all moving around of files from debian/tmp
to pkg-dirs in the install target.
--
Robbe
signature.ng
Description: PGP signature
How to handle ´/etc/ld.so.preload library packages?
I have a package with a library that needs to be entered to /etc/ld.so.preload. It is clear that this library needs to go in /lib rather than /usr/lib because there are systems that have /usr on a dedicated partition. But how do I handle the entry to /etc/ld.so.preload? There are packages that leave the ld.so.preload entry to the user, but they probably make the system fail when they are uninstalled and the user forgets to manually remove the ld.so.preload entry. So, how am I to deal with this in the packaging? (1) Don't add the lib to /etc/ld.so.preload, display a hint for the user to do so, but remove the entry in the prerm if the package is to be removed? (2) Ask the user if I should add the lib to /etc/ld.so.preload in the postinst and automatically remove the entry in prerm? Does order in /etc/ld.so.preload matter? (3) Do everything fully automatic? Any comments will be appreciated. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Integration of debian/ scripts in packages
--- Josip Rodin [EMAIL PROTECTED] wrote: On Sun, Jun 03, 2001 at 11:40:26PM -0300, Henrique de Moraes Holschuh wrote: files there. Even if upstream keeps its debian/ up-to-date, it will still cause you trouble if you have to remove a file, as you'll need to either use dirty tricks, or Adding 'rm -f debian/foo' in debian/rules clean rule is not a dirty trick. The reason I raise this issue in the first place is actually a notion that it would be nice for users wanting bleeding-edge software to update from CVS and just run debian/rules binary or dpkg-buildpackage, the same way they can rpm -tb package.tar.gz currently (granted, most of the time one thing or another is broken. Especially the changelog - rather incredible). Then again, most of the time the diff.gz from packages.debian.org can be applied cleanly so it is not much of a problem - just when the software has radically changed (like Glib 1.2 - Glib 1.3). Regards, Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
Looking for Advocate, Sponsor
Debian Mentors: I am looking for a sponsor/advocate for becoming a debian developer. I am packaging misterhouse, a home automation package written in perl. I have signed up at http://www.internatif.org/bortzmeyer/debian/sponsor/. The misterhouse debian package can be found at http://www.runningland.com/debian/. Lintian gives some perl warnings that I believe can be safely ignored after reading the Debian Perl Policy. Any help or feedback would be appreciated. Thanks! Dave Mabe
Re: Fwd: ITP: glib2, gtk2, inti
--- Tollef Fog Heen [EMAIL PROTECTED] wrote: * Christian Marillat | MAS Indeed, but for package naming purpose I guess calling | MAS them libglib2 and libgtk2 would work. | | I disagree. The API may change between 1.3.5 and 2.0 Please LART upstream heavily and give the packages a proper name. That tradition has done it wrong is no reason to continue doing it the wrong way. *sigh* /rant-of-the-week Well this is a bit late :) Following the current Debian package names I am calling them libglib1.3, libgtk+1.3 since they are not backward-compatible with the 1.2 series yet might change prior to version 2.0 Thanks anyway, that post was careless of me. Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
Re: OK to use /etc/default for non-init script default data?
On Tue, 5 Jun 2001 10:17:01 +0100, Julian Gilbey [EMAIL PROTECTED] wrote: On Tue, Jun 05, 2001 at 11:01:22AM +0200, Marc Haber wrote: And if it's a wrapper script, wouldn't it be a lot better to have the wrapper in /usr/bin, with the real program called something like foo.real, and just the variable settings in /etc? Everything else would be a policy violation. Please explain how my suggest would violate policy. It wouldn't. If it's the Right Thing to do, and it violates policy, we should modify policy. Having non-conffile executeable code in /etc would violate policy, and this is what we both try to avoid. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Integration of debian/ scripts in packages
On Mon, Jun 04, 2001 at 06:31:54PM +0100, Michèl Alexandre Salim wrote: [debian/ in upstream makes maintaining package difficult] The reason I raise this issue in the first place is actually a notion that it would be nice for users wanting bleeding-edge software to update from CVS and just run debian/rules binary or dpkg-buildpackage, the same way they can rpm -tb package.tar.gz currently (granted, most of the time one thing or another is broken. Especially the changelog - rather incredible). I've been thinking about this as well - it /would/ be nice for a user to just run dpkg-buildpackage after unpacking the tarball... Maybe a simple and straightforward solution would be to provide a debian.upstream directory in the upstream sources, and a rule in the upstream Makefile which soft-links this to debian before running dpkg-buildpackage. Then the user would only have to make deb. Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯
Re: Integration of debian/ scripts in packages
--- Sam Hartman [EMAIL PROTECTED] wrote: Michèl == Michèl Alexandre Salim [EMAIL PROTECTED] writes: And if you come up with a clean solution for the changelog issue, I agree this is worth doing. If you do that, please let me know what your solution is. As Richard Atterer said there should probably be another set of debian scripts provided by the upstream author (if possible) and maintained independently from the Debian-maintained scripts. Rather a neat idea. And certainly I have seen it implemented - for Enlightenment 0.17 CVS for instance. It is still the duty of the Debian maintainer to make sure the Debian version of the scripts conform to Debian specifications, but if something major changes in the package the author(s) would know best what has changes. So it is a two-way process: if Debian policy changes the maintainer informs the author, if the packaging changes the author-maintained debian scripts will still allow building of the package seamlessly while the Debian maintainer work on integrating the changes. There could probably be a naming scheme enforced, with say package version x.y.z having an upstream deb at version x.y.z.hack.n while the Debian version at x.y.z.official.n - the names are just example, I presume official will be seen by dpkg as being a higher version than hack? Just my penny's worth.. Regards, Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
Re: ITP: glib2, gtk2, inti
--- Robert Bihlmeyer [EMAIL PROTECTED] wrote:
Michèl Alexandre Salim [EMAIL PROTECTED]
writes:
Have not managed to package Pango - can anyone
assist me in finding
out what is going wrong? Basically the package
failed the install
stage of the rules script if installed using an
alternate path
(specified using prefix or DESTDIR).
Exactly how does it break? Copy the exact error
message if feasable.
--
Robbe
Funny, could not replicate the error now, guess I was
sloppy and did not clean up and rebuild the source
before attempting it again. Have another problem
though, when building libpango0 dpkg-gencontrol
complained thus:
dpkg-gencontrol: warning: unknown substitution
variable ${shlibs:Depends}
Attached are the debian/control and debian/rules
files.
If this is fixed I can finish packaing libatk0 and
then libgtk+1.3, currently a bit wary having a package
that does not depend on anything.
TIA,
Michel
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
control
Description: control
rules
Description: rules
porting problem and how to request help
Some weeks ago I received Bug#96254 on one of my package: ocaml-xstr, the problem is a build failure on a m68k machine. The reason is that a package needed in ocaml-xstr compilation named ocaml-findlib, does not work well on a m68k architecture. I forwarded the problem to the upstream author and I told me that he does not like to solve architecture specific problem, OTOH I do not have time and knowledge to debug problems on m68k arch. How can I solve the problem? May I ask for help on debian-devel or on debian-m68k ML? Cause the problem is related to another package, may I close the bug on ocaml-xstr and fill a new one against ocaml-findlib? TIA, cheers. -- - 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 pgp6uWyJSiDdK.pgp Description: PGP signature
Re: porting problem and how to request help
On Wed, Jun 06, 2001 at 02:04:33PM +0200, T.Pospisek's MailLists wrote: The quick and ugly way is of course to build a new debian package that excludes m68k from the supported architectures. That's not very nice. ocaml-findlib is genuinely broken on m68k. I verified it myself. However since I have no idea what any of these tools do I didn't get very far. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: ITP: glib2, gtk2, inti
--- Robert Bihlmeyer [EMAIL PROTECTED] wrote: The line dh_shlibdeps -plibpango$(version) should generate either substvars or libpango0.substvars. If it does, dh_gencontrol is for some reason not picking that up. If it doesn't it is either broken, or libpango0 does not depend on any library. You check the latter case by using ldd on the shared library. It should usually return at least the C library. dh_* commands can be run by hand and with -v to get more information. Or set DH_VERBOSE=1 for running debian/rules. Attached are the debian/control and debian/rules files. Seem ok in looking over. One problem I saw is that you can't safely run any of the binary targets twice (for example, because you just fixed an error): install will not be re-run, because install-stamp is up-to-date, but debian/tmp may not be intact due to rm -rf or dh_movefiles in the binary targets. I'd remove install-stamp after altering debian/tmp. Or do all moving around of files from debian/tmp to pkg-dirs in the install target. Good idea, thanks. My previous problems seem to be related, in that an unclean build directory brings up various problems. Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
Re: Fwd: ITP: glib2, gtk2, inti
--- Paolo Molaro [EMAIL PROTECTED] wrote: Note that probably all the gtk 1.3.x releases will be incompatible, so the package names should include also the micro number. Makes sense, I'll do just that. Thanks, Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
Sponsoring, signing, etc.
Hi, I'm going to sponsor a guy who has already completed a package which seems to be in good shape. It is my first sponsorship, and I'd like to upload his package. Now the questions: - Should he register somewhere as a sponsored guy? (some time ago, when I was sponsored before entering Debian, I remember registering in some web page with a list of sponsors and sponsored people). - What should I include in control, his name or my name? - What should I include in changelog, his name or my name? I saw a discussion in this list some time ago about all this, but I do not find an answer to these questions. I saw nothing in w.d.o/devel either, although maybe I did'n look at the correct places... I assume that, once these questions are answered, I can just rebuild the package with: dpkg-buildpackage [EMAIL PROTECTED] -rfakeroot -sgpg -tc And dput it to incoming. Am I missing something? In particular, are the bugs against this package going to be assigned to somebody? Saludos, Jesus. -- Jesus M. Gonzalez Barahona| Grupo de Sistemas y Comunicaciones [EMAIL PROTECTED] / [EMAIL PROTECTED] | ESCET, Universidad Rey Juan Carlos tel: +34 91 664 74 67 | c/ Tulipan s/n fax: +34 91 664 74 90 | 28933 Mostoles, Spain
Re: Sponsoring, signing, etc.
On Wed, Jun 06, 2001 at 05:48:46PM +0200, Jesus M. Gonzalez-Barahona wrote: I'm going to sponsor a guy who has already completed a package which seems to be in good shape. It is my first sponsorship, and I'd like to upload his package. Now the questions: - Should he register somewhere as a sponsored guy? (some time ago, when I was sponsored before entering Debian, I remember registering in some web page with a list of sponsors and sponsored people). I know of a page where folks register to FIND a sponsor. (Look at the list of projects in the Debian Developer's Corner.) Since he already has one, the value of registering is lost on me. - What should I include in control, his name or my name? - What should I include in changelog, his name or my name? It would be the package maintainer creating those files. You should not touch them. Your job is only to take the .orig and .diff files, build the package, and upload it. I saw a discussion in this list some time ago about all this, but I do not find an answer to these questions. I saw nothing in w.d.o/devel either, although maybe I did'n look at the correct places... Indeed, it has been discussed. Look harder! I assume that, once these questions are answered, I can just rebuild the package with: dpkg-buildpackage [EMAIL PROTECTED] -rfakeroot -sgpg -tc The last time this came up, I saved the following two suggestions. Rick Younie suggested: dpkg-buildpackage -rfakeroot -kyour key where your key identifies the key the sponsor wants to sign with and Adrian Bunk responded that he prefers to use dpkg-buildpackage -us -uc -rfakeroot debsign -m'Adrian Bunk' package.changes I use Rick's procedure and have not had problems. And dput it to incoming. Am I missing something? In particular, are the bugs against this package going to be assigned to somebody? The bugs will be sent to the Maintainer: listed in the control file, I believe. That's why you should leave it to the real maintainer ... Cheers, -Steve -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants
Re: porting problem and how to request help
On Wed, 6 Jun 2001, Hamish Moffatt wrote: On Wed, Jun 06, 2001 at 02:04:33PM +0200, T.Pospisek's MailLists wrote: The quick and ugly way is of course to build a new debian package that excludes m68k from the supported architectures. That's not very nice. ocaml-findlib is genuinely broken on m68k. I verified it myself. However since I have no idea what any of these tools do I didn't get very far. I agree with you that it's not nice. That's why I described the method as ugly. *t Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: first questions
Andreas Bombe [EMAIL PROTECTED] writes: It's just that making the package non-native makes it easier to handle unless it's really a native package (i.e. written specifically for Debian). YMMV, obviously. I find it easier to maintain quintuple-agent without Debian subversions; native if you will. For a native package, a small bug in packaging requires a whole new release. If it's not a Debian-specific package, you inflict a new version number on all the users outside of Debian who feel compelled to download the new release to stay on the edge. You're not forced to put the new version up for download outside of Debian. Or you can point out in the release notes that the changes are only relevant if you use the Debian package. quintuple-agent in Debian is at 1.0.3 while the upstream distribution point still has 1.0.0. Now, who said that Debian has only outdated versions, huh? -- Robbe signature.ng Description: PGP signature
Re: Should libfile-temp-perl be removed ?
On Thu, May 31, 2001 at 10:31:03AM +0100, Jon Middleton wrote: [ I'm CC'ing debian-perl in-case the Perl Maintainer's have any views, I guess any other discussion should happen there ] OK, I'll file a bug against ftp.debian.org acessing for libfile-temp-perl's removal after perl-modules 5.6.1-3 has reached testing. Thanks, please do that. Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
Have X11/app-defaults moved in unstable?
Hi! May I have missed something and in unstable /usr/lib/X11/app-defaults moved to /etc/X11/app-defaults? My package actually doesn't use app-defaults. I noticed this when I compiled a package from unstable on my stable box and got error messages on a missing file in app-defaults. Christoph -- * Christoph Baumann * * [EMAIL PROTECTED] * * www.rzuser.uni-heidelberg.de/~cbauman1/welcome.html* * External Error : INTELLIGENCE not found !*
Re: Have X11/app-defaults moved in unstable?
On Thu, 7 Jun 2001, Christoph Baumann wrote: [..] have [..] /usr/lib/X11/app-defaults [..] moved to /etc/X11/app-defaults? yes. *t Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: porting problem and how to request help
* Stefano Zacchiroli | How can I solve the problem? May I ask for help on debian-devel or on | debian-m68k ML? That is one of the ways of doing it, yes. m68k would probably be best. | Cause the problem is related to another package, may I close the bug on | ocaml-xstr and fill a new one against ocaml-findlib? No, you'd have to reassign it, not close and open a new one. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
