library version equals to project version ?
Hi fellow developpers, I maintain iiwusynth, which until now shipped unversioned libraries. I have been discussing with upstream author for the past days and he agreed that versioning libraries is certainly a good thing. He's in the process of versioning his libraries but asked me details about the versioning scheme, and I'm not sure what the correct answer his... In two words, his question is: should a binary and the library it depends on have the same version number ? Say foo is version M.m.p and depends on foo dynamic library. Should the library necesarily be called libfooM of could it be libfooX ? On one hand I have the example of avifile-player version 0.7.12.20020719-1.2, which depends on libavifile0 version 0.7. OTOH, we have aspell version 0.33.7.1 which depends on libaspell10 version 0.33.7 What is the Very True Way ? I paste below the details of his question: Please CC me on reply. Thanks for your help. - Forwarded message from Peter Hanappe [EMAIL PROTECTED] - From: Peter Hanappe [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: bug in iiwusynth: dubious FPE logging implementation X-Virus-Scanned: by AMaViS new-20020517 X-Razor-id: 44bb8d5d94b139efb3297b797e4e382641ab7d54 X-Spam-Status: No, hits=1.6 tests=MAY_BE_FORGED Eric Van Buggenhaut wrote: [...] You said in a previous mail: Binary executables should be compatible with one major version, all across its succesive minor numbers. Just to make sure I get this right, do you mind I write down a little scenario: - I install iiwusynth-M.m.p that is linked against libiiwusynth.so.X. The ABI version of libiiwusynth is X. - Later, I update to iiwusynth-M.m+1.p that is also linked against libiiwusynth.so.X. There should be no problems since they are ABI compatible. I don't necessarily have to update libiiwusynth. - I update libiiwusynth to a newer version, however that is still ABI version X (i.e. libiiwusynth.so.X), everything continues to work. - However, if I update iiwusynth to version M.m+2.p that is linked against libiiwusynth.so.X+1 there is a conflict and I'll need to install libiiwusynth.so.X+1 as well. Is this about correct? Yes, that's exactly how it works. One detail though, in the scenario above X always = M so I rewrite it: This I don't understand. I have been searching on the web a little and I thought I understood that the library version isn't necessarily equal to the project version. For example, I checked on the debian web site, libaspell version 0.33.7.1-8 (package libaspell10) installs libaspell.so.10, and not libaspell.so.0 (M=0, X=10). I don't want to update iiwusynth to version 1.x.y because somehow (psychologically) version 1.x is the first stable release. If X always = M than *all* libraries before iiwusynth 1.0 have major number 0. It's impossible to keep all those 0 library version ABI compatible, especially in the beginning of a project. Let me know what your thoughts on this are. We'd better straighten this all out before making new packages to avoid future confusion. Sorry to annoy you with all these questions but I want to make sure I understand it correctly. - End forwarded message - -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for sponsor, SML/NJ
On Sun, Oct 27, 2002 at 08:35:24PM -0800, Aaron Matthew Read wrote: Hi, I used to use the SML/NJ package when I was in college for doing projects, so I know it is a useful package to have around. Also, it is one of my favorate languages, so I would like to see it around in Debian. I see that someone is already working on the SML/NJ (97 days preparation), but the link: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=153880 confuses me to who has actually volunteered to take this task on. The RFP was filed by Walter Tautz [EMAIL PROTECTED] Then Søren decided to package it Søren Boll Overgaard [EMAIL PROTECTED] (you can see the last entry on the bug page, Changed Bug title, where he changed it from RFP to ITP. I'd contact him if I were you, since you already did a lot of work. Florian -- E-Mail: [EMAIL PROTECTED] (private) [EMAIL PROTECTED] (Debian-related) Jabber: [EMAIL PROTECTED] ICQ: 167919139 GPG Key ID: B34A0F1D GPG Fingerprint: 6FFC 6751 BBB8 0F60 C39D AB72 4A77 581C B34A 0F1D msg07635/pgp0.pgp Description: PGP signature
debconf template not included in package ???
Hello, ... I tried adding a little debconf question to one of my packages, and followed the instructions found in the debconf-devel man pages as well as under /usr/share/doc/debconf-doc/tutorial.txt.gz. I created a templates file, put it in the debian directory, created a config file and a postinst file, like was adviced. Now, the package builds fine, i tried running the postinst by hand, and it asked me the question in the template. When i installed the built package, it did not ask me the question, since it had already. Not thinking much (it was late at night), i uploaded the package to unstable. Now, when others try installing the packages, it fails in pre-configure, since there is no mention of the debconf template file in the package, and no mention of my debconf question in /var/cache/debconf/templates.dat. I am a bit at a loss here, how do you make debconf understand it should add the debconf template in the distributed package ? Note that it is a multi-binary package. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fixed some RC bugs, need sponsor
On Sun, Oct 27, 2002 at 07:01:01PM -0800, David Kimdon wrote: [snip] Put another way, the orig directory you used was the 1.51-5 debianized source dir, it should have been the pristine upstream source. right, i was missing the point (stupid error btw). new packages on http://debian.esaurito.net should work. anyway fortunes-it is fixed [1] by [EMAIL PROTECTED] so this is quite useless work but your tips help me anyway, thanks. and a diff. For doc-linux-sv the souce package started out wrong, so that isn't your fault, you can leave it as it is. ok, i've fixed also doc-linux-sv with NMU changelog and correct version. Same problem with this one, the orig should not be the previous debian version, but should be the pristine upstream tarball. doc-linux-sv had an incorrect source package to start out with (the version number indicates it is not a debian native package, but the absence of a diff indicates that it is debian-native, this is likely the source of our confusion). If I were you I would leave that source package broken and just fix the RC bug. (perhaps report a bug on the broken source package as well) ok, RC bug #140137 is open, should I open a new one against doc-linux-sv with (trivial) patch attached? when trying to fix #161852 on http-analyze i encountered the same problem (no .orig file only .dsc and debianized .tar.gz) cheers, filippo. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=147018repeatmerged=yes -- Filippo Giunchedi GNU/PG key id: 1024D/6B79D401 Random signature follows: Linux IS user friendly, it is just selective who his friends are. msg07637/pgp0.pgp Description: PGP signature
Re: fixed some RC bugs, need sponsor
On Mon, Oct 28, 2002 at 03:16:38PM +0100, Filippo Giunchedi wrote: On Sun, Oct 27, 2002 at 07:01:01PM -0800, David Kimdon wrote: [snip] Put another way, the orig directory you used was the 1.51-5 debianized source dir, it should have been the pristine upstream source. right, i was missing the point (stupid error btw). new packages on http://debian.esaurito.net should work. anyway fortunes-it is fixed [1] by [EMAIL PROTECTED] so this is quite useless work but your tips help me anyway, thanks. Sorry guys, I missed this thread before NMUing... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debconf template not included in package ???
Sven Luther wrote: I created a templates file, put it in the debian directory, created a config file and a postinst file, like was adviced. Now, the package builds fine, i tried running the postinst by hand, and it asked me the question in the template. When i installed the built package, it did not ask me the question, since it had already. Not thinking much (it was late at night), i uploaded the package to unstable. Now, when others try installing the packages, it fails in pre-configure, since there is no mention of the debconf template file in the package, and no mention of my debconf question in /var/cache/debconf/templates.dat. I am a bit at a loss here, how do you make debconf understand it should add the debconf template in the distributed package ? Put the templates file in debian/package.templates. dh_installdebconf will install it from there into debian/package/DEBIAN. -- see shy jo msg07639/pgp0.pgp Description: PGP signature
Re: debconf template not included in package ???
On Mon, Oct 28, 2002 at 10:39:03AM -0500, Joey Hess wrote: Sven Luther wrote: I created a templates file, put it in the debian directory, created a config file and a postinst file, like was adviced. Now, the package builds fine, i tried running the postinst by hand, and it asked me the question in the template. When i installed the built package, it did not ask me the question, since it had already. Not thinking much (it was late at night), i uploaded the package to unstable. Now, when others try installing the packages, it fails in pre-configure, since there is no mention of the debconf template file in the package, and no mention of my debconf question in /var/cache/debconf/templates.dat. I am a bit at a loss here, how do you make debconf understand it should add the debconf template in the distributed package ? Put the templates file in debian/package.templates. dh_installdebconf will install it from there into debian/package/DEBIAN. Ok, thanks. Maybe this should be more proeminently said in /usr/share/doc/debconf-doc/tutorial.txt.gz, no, there is only a quick mention about installing in debian/tmp/DEBIAN/, which i missed, and the fact that the newline cut this path in two did not help. Also maybe the note about debhelper should be expanded a bit, there is no mention of dh_installdebconf at all, and it was commented out in my debian/rules (maybe even by default in debhelper ?). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debconf template not included in package ???
Sven Luther wrote: Maybe this should be more proeminently said in /usr/share/doc/debconf-doc/tutorial.txt.gz, no, there is only a quick mention about installing in debian/tmp/DEBIAN/, which i missed, and the fact that the newline cut this path in two did not help. Also maybe the note about debhelper should be expanded a bit, there is no mention of dh_installdebconf at all, and it was commented out in my debian/rules (maybe even by default in debhelper ?). The tutorial is a bit outdated (though still useful for the few packages that need to be converted to debconf from ad-hoc prompting, perhaps). The debconf-devel(7) man page has a lot more information. -- see shy jo msg07641/pgp0.pgp Description: PGP signature
Re: debconf template not included in package ???
On Mon, Oct 28, 2002 at 11:05:59AM -0500, Joey Hess wrote: Sven Luther wrote: Maybe this should be more proeminently said in /usr/share/doc/debconf-doc/tutorial.txt.gz, no, there is only a quick mention about installing in debian/tmp/DEBIAN/, which i missed, and the fact that the newline cut this path in two did not help. Also maybe the note about debhelper should be expanded a bit, there is no mention of dh_installdebconf at all, and it was commented out in my debian/rules (maybe even by default in debhelper ?). The tutorial is a bit outdated (though still useful for the few packages that need to be converted to debconf from ad-hoc prompting, perhaps). The debconf-devel(7) man page has a lot more information. Mmm, yes, i see it now, too bad i missed it. Thanks for your help. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: library version equals to project version ?
On Mon, Oct 28, 2002 at 02:17:52PM +0100, Eric Van Buggenhaut wrote: I maintain iiwusynth, which until now shipped unversioned libraries. I have been discussing with upstream author for the past days and he agreed that versioning libraries is certainly a good thing. He's in the process of versioning his libraries but asked me details about the versioning scheme, and I'm not sure what the correct answer his... In two words, his question is: should a binary and the library it depends on have the same version number ? They should only have the same version number if his versioning of the binary is going to *follow* the versioning of the library. The library major version *must* be incremented every time the ABI changes incompatibly, and should not be changed when the ABI has not changed. Since ABI changes don't necessarily correspond to major milestones in an application's development, most people prefer to not use this approach to versioning their application. On one hand I have the example of avifile-player version 0.7.12.20020719-1.2, which depends on libavifile0 version 0.7. OTOH, we have aspell version 0.33.7.1 which depends on libaspell10 version 0.33.7 In both cases, the number that's part of the package name should indicate how many times the ABI has changed. Steve Langasek postmodern programmer msg07643/pgp0.pgp Description: PGP signature
Re: library version equals to project version ?
Eric Van Buggenhaut [EMAIL PROTECTED] immo vero scripsit: On one hand I have the example of avifile-player version 0.7.12.20020719-1.2, which depends on libavifile0 version 0.7. OTOH, we have aspell version 0.33.7.1 which depends on libaspell10 version 0.33.7 The interface number of a shared library should usually be distinct from the version number of the package itself, since interface usually does not correspond to package versions. Interface do change with minor version upgrades, in which case interface number should be updated, and even with major version upgrades, interface compatibility can be kept, which means interface number does not need to change. avifile-player probably ignores that part, or changes the library version number on every release, or whatever. -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to be sure, that /dev/cdrom exists?
On Sun, Oct 27, 2002 at 11:33:31PM +0100, Jan-Hendrik Palic wrote: I'm maintaining pbbuttonsd for PPC-Notebooks. I'm preparing the new upstream version and I stuck at this point, that the pbbuttonsd wants to have a link /dev/cdrom. How can I satisfy the dependency on the easiest way? Can the software not function without /dev/cdrom? Unless I'm mistaken, this software has plenty of uses even if there's no cdrom installed in the machine. The best way to make sure the /dev/cdrom link is present is to check for it, use debconf to prompt the user if it's absent, and then create the link (possibly with some /proc autodetection) if the user agrees to let you create the link. Steve Langasek postmodern programmer msg07645/pgp0.pgp Description: PGP signature
orig.tar.gz
I'm currently working to package pieces of the NetBSD source tree (little things like libc12, for instance). Because the full source tree is vast, unwieldly, and by and large much of it is not actually useful or needed for the Debian GNU/NetBSD port (for example, the entire gnu/ tree is replaced by Debian packaged software), these packages are generally built based on a partial copy of the relevant parts of the NetBSD CVS tree (currently from the tagged release point release-1-6). It's easy enough to create an orig.tar.gz: tar -czvf libc12_1.6.orig.tar.gz libc12-1.6/*.bz2 produces one. However, I run into a problem at this point; future releases of the package (-2 and above) might well need to pull in different files or parts of the source tree. This would result in a different orig.tar.gz file, which seems like it wouldn't work - however, it also seems silly (and probably confusing) to version it as Debian-native, since there is a clear versioning point in the upstream sources. Certainly, it would be possible to tar up the entire tree, 'just to be safe', but the *compressed* tarball (bzip2 -9 or gzip -9) is close to half a gig, of which the vast majority is useless. Please tell me there's a better solution... -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ msg07646/pgp0.pgp Description: PGP signature
Re: how to be sure, that /dev/cdrom exists?
On Mon, 28 Oct 2002 18:07, Steve Langasek wrote: The best way to make sure the /dev/cdrom link is present is to check for it, use debconf to prompt the user if it's absent, and then create the link (possibly with some /proc autodetection) if the user agrees to let you create the link. Except if /dev/.devfsd exists which indicates the presence of devfs. When running devfs you should never create anything under /dev. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: orig.tar.gz
It's easy enough to create an orig.tar.gz: tar -czvf libc12_1.6.orig.tar.gz libc12-1.6/*.bz2 produces one. Actually, this should be tar -czvf libc12_1.6.orig.tar.gz libc12-1.6.orig/ However, I run into a problem at this point; future releases of the package (-2 and above) might well need to pull in different files or parts of the source tree. This would result in a different orig.tar.gz file, which seems like it wouldn't work The additional files will be represented in the .diff.gz files... Is that not enough? -- .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than to fix a system msg07648/pgp0.pgp Description: PGP signature
Packet Writing kernel patch packaged (at half)
hi all, I've packaged a dirty but working deb of the Packet Writing kernel patch(2.4 kernels), which let to write on cdrw with an udf fs, the deb is here, even if it's not yet apt-gettable: http://ketavet.dyndns.org/debian/kernel-patch-packet-2.4.deb Now before claim a sponsor I'm trying to understand something about dh-kpatches, which are not so clear to me, and I've to decide what policy about this patch versions to include in the packet, because they are for many kenel prereleases from 2.4.9 to 2.4.20pre11 nowadays, for now I thought that the patches for the kernel sources that I find apt-gettable within sid. At least this mail is to shut up my todo list for what concerns the deb made with dpkg-deb. Luca Pasquali -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 07:41:23PM +0100, martin f krafft wrote: It's easy enough to create an orig.tar.gz: tar -czvf libc12_1.6.orig.tar.gz libc12-1.6/*.bz2 produces one. Actually, this should be tar -czvf libc12_1.6.orig.tar.gz libc12-1.6.orig/ Why? -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: orig.tar.gz
also sprach Matt Zimmerman [EMAIL PROTECTED] [2002.10.28.2008 +0100]: Actually, this should be tar -czvf libc12_1.6.orig.tar.gz libc12-1.6.orig/ Why? .orig.tar.gz files unpack .orig directories, that's why. I don't know why this is so, but I know that it is so. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than to fix a system msg07651/pgp0.pgp Description: PGP signature
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 07:41:23PM +0100, martin f krafft wrote: It's easy enough to create an orig.tar.gz: tar -czvf libc12_1.6.orig.tar.gz libc12-1.6/*.bz2 produces one. Actually, this should be tar -czvf libc12_1.6.orig.tar.gz libc12-1.6.orig/ There is no spoon. Er. There is no libc12-1.6.orig/ I'm packaging the bz2 tarball because I'm using DBS with multiple separate tarballs being unpacked to form the build-tree. However, I run into a problem at this point; future releases of the package (-2 and above) might well need to pull in different files or parts of the source tree. This would result in a different orig.tar.gz file, which seems like it wouldn't work The additional files will be represented in the .diff.gz files... Is that not enough? Given that they're not Debian differences from the source, but rather, files from the origional source tree that I screwed up and forgot to add or remove properly, no, that isn't enough. Further commentary on IRC indicates that this whole thing is tilting at windmills, and I should just throw in the towel and forget orig.tar.gz and go with a Debian native version (1.6+debian+1 or the like), because it is Not Kosher to mess with the orig.tar.gz in any way, once it's been uploaded, unless you're doing a new version (not just new revision) of the package. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ msg07652/pgp0.pgp Description: PGP signature
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 10:56:02AM -0700, Joel Baker wrote: I'm currently working to package pieces of the NetBSD source tree (little things like libc12, for instance). Because the full source tree is vast, unwieldly, and by and large much of it is not actually useful or needed for the Debian GNU/NetBSD port (for example, the entire gnu/ tree is replaced by Debian packaged software), these packages are generally built based on a partial copy of the relevant parts of the NetBSD CVS tree (currently from the tagged release point release-1-6). It's easy enough to create an orig.tar.gz: tar -czvf libc12_1.6.orig.tar.gz libc12-1.6/*.bz2 produces one. However, I run into a problem at this point; future releases of the package (-2 and above) might well need to pull in different files or parts of the source tree. This would result in a different orig.tar.gz file, which seems like it wouldn't work - however, it also seems silly (and probably confusing) to version it as Debian-native, since there is a clear versioning point in the upstream sources. You can either modify the upstream version number every time you have to make changes to the tarball (e.g., libc12_1.6, libc12_1.6+debian.0, libc12_1.6+debian.1), or you can include any subsequent modifications in your Debian diff. Your choice. If you expect to be making frequent changes to how much of upstream's code you're including, option 1 might easily reduce to a native package. Steve Langasek postmodern programmer msg07654/pgp0.pgp Description: PGP signature
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 10:56:02AM -0700, Joel Baker wrote: However, I run into a problem at this point; future releases of the package (-2 and above) might well need to pull in different files or parts of the source tree. This would result in a different orig.tar.gz file, which seems like it wouldn't work - however, it also seems silly (and probably confusing) to version it as Debian-native, since there is a clear versioning point in the upstream sources. Given that I expect you might frequently find yourself doing either of changing the tarball in this way and making Debian-specific changes, I'd go for having the upstream version as 1.6-date, where date is the date on which you constructed the tarball (or some other similar strictly increasing scheme). Then you keep the upstream version and still get to make Debian-specific changes with reasonable efficiency. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: orig.tar.gz
Joel Baker [EMAIL PROTECTED] writes: It's easy enough to create an orig.tar.gz: tar -czvf libc12_1.6.orig.tar.gz libc12-1.6/*.bz2 produces one. However, I run into a problem at this point; future releases of the package (-2 and above) might well need to pull in different files or parts of the source tree. This would result in a different orig.tar.gz file, which seems like it wouldn't work - however, it also seems silly (and probably confusing) to version it as Debian-native, since there is a clear versioning point in the upstream sources. Disclaimer: I'm not in the keyring, and have therefore never uploaded a package myself, so I don't know if my suggestion is worthless, but nobody else seems to mention what appears to me as the obvious, so here goes.. You could try running dpkg-buildpackage with the -sa option for each upload you want to regenerate the fake upstream tarball? -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to be sure, that /dev/cdrom exists?
Hi .. thnx for your answer .. On Mon, Oct 28, 2002 at 11:07:07AM -0600, Steve Langasek wrote: I'm maintaining pbbuttonsd for PPC-Notebooks. I'm preparing the new upstream version and I stuck at this point, that the pbbuttonsd wants to have a link /dev/cdrom. Can the software not function without /dev/cdrom? Unless I'm mistaken, this software has plenty of uses even if there's no cdrom installed in the machine. The softwares behavior on missing devices is cruel ;( If the /dev/cdrom does not exists, it will stop starting ... To solve this, I see two ways, set the link /dev/cdrom or put the right device into the the configfile .. The best way to make sure the /dev/cdrom link is present is to check for it, use debconf to prompt the user if it's absent, and then create the link (possibly with some /proc autodetection) if the user agrees to let you create the link. yes I think this, too ... thnx Jan -- .''`.Jan-Hendrik Palic | : :' : ** Debian GNU/ Linux ** | ** OpenOffice.org ** ,.. ,.. `. `' http://www.debian.org | http://www.openoffice.org ,: ..` ` `- [EMAIL PROTECTED] | ' ` ` msg07657/pgp0.pgp Description: PGP signature
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 09:34:28PM +0100, Tore Anderson wrote: Disclaimer: I'm not in the keyring, and have therefore never uploaded a package myself, so I don't know if my suggestion is worthless, but nobody else seems to mention what appears to me as the obvious, so here goes.. You could try running dpkg-buildpackage with the -sa option for each upload you want to regenerate the fake upstream tarball? It is not permitted to replace an existing source tarball in the archive with a different one having the same version number. This rule exists to preserve the sanity of developers and users. :-) -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 01:51:01PM -0600, Steve Langasek wrote: On Mon, Oct 28, 2002 at 10:56:02AM -0700, Joel Baker wrote: I'm currently working to package pieces of the NetBSD source tree (little things like libc12, for instance). Because the full source tree is vast, unwieldly, and by and large much of it is not actually useful or needed for the Debian GNU/NetBSD port (for example, the entire gnu/ tree is replaced by Debian packaged software), these packages are generally built based on a partial copy of the relevant parts of the NetBSD CVS tree (currently from the tagged release point release-1-6). It's easy enough to create an orig.tar.gz: tar -czvf libc12_1.6.orig.tar.gz libc12-1.6/*.bz2 produces one. However, I run into a problem at this point; future releases of the package (-2 and above) might well need to pull in different files or parts of the source tree. This would result in a different orig.tar.gz file, which seems like it wouldn't work - however, it also seems silly (and probably confusing) to version it as Debian-native, since there is a clear versioning point in the upstream sources. You can either modify the upstream version number every time you have to make changes to the tarball (e.g., libc12_1.6, libc12_1.6+debian.0, libc12_1.6+debian.1), or you can include any subsequent modifications in your Debian diff. Your choice. If you expect to be making frequent changes to how much of upstream's code you're including, option 1 might easily reduce to a native package. Indeed. This seems to be the cleanest way, really - specifically, to devolve it into a Debian-native package, with the version mapped from upstream's versioning plus what would otherwise be a -rev value. I'd say it was unfortunate to lose the diff.gz summarizing Debian changes, but you don't, really - just unpack the entire thing and rm the source tarball, if you really care. I do think I'll put information on the include/exclude lists used to build the tarball from a pristine CVS tree into debian/README, though - if for no other reason than to not forget, myself, when I accidentally delete some files (oh, come on, you KNOW it'll happen...) -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ msg07659/pgp0.pgp Description: PGP signature
Re: how to be sure, that /dev/cdrom exists?
On Mon, Oct 28, 2002 at 10:14:50PM +0100, Jan-Hendrik Palic wrote: On Mon, Oct 28, 2002 at 11:07:07AM -0600, Steve Langasek wrote: I'm maintaining pbbuttonsd for PPC-Notebooks. I'm preparing the new upstream version and I stuck at this point, that the pbbuttonsd wants to have a link /dev/cdrom. Can the software not function without /dev/cdrom? Unless I'm mistaken, this software has plenty of uses even if there's no cdrom installed in the machine. The softwares behavior on missing devices is cruel ;( If the /dev/cdrom does not exists, it will stop starting ... To solve this, I see two ways, set the link /dev/cdrom or put the right device into the the configfile .. Is it possible to get a fix for this into the upstream sources? Especially in light of the devfs issue pointed out, it would be ideal if the software would deal more gracefully with the absence of this device file. I can also see it being useful to continue running pbbuttonsd when the cdrom drive is physically absent, perhaps due to a hardware failure. Steve Langasek postmodern programmer msg07660/pgp0.pgp Description: PGP signature
Re: orig.tar.gz
also sprach Matt Zimmerman [EMAIL PROTECTED] [2002.10.28.2041 +0100]: If you don't know why it is so, then why are you instructing others to do this? why does dh_make do it? -- .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than to fix a system msg07661/pgp0.pgp Description: PGP signature
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 11:30:15PM +0100, martin f krafft wrote: also sprach Matt Zimmerman [EMAIL PROTECTED] [2002.10.28.2041 +0100]: If you don't know why it is so, then why are you instructing others to do this? why does dh_make do it? dh_make doesn't build .orig.tar.gz files. It makes a copy of the source tree names blah.orig, and it only does that if you don't tell it that you already have a source tarball using the --file/-f option. I see no reason why it should not detect the existence of a file with the proper name and use it, so I have filed a wishlist bug to that effect. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: orig.tar.gz
also sprach Matt Zimmerman [EMAIL PROTECTED] [2002.10.28.2343 +0100]: dh_make doesn't build .orig.tar.gz files. It makes a copy of the source tree names blah.orig, and it only does that if you don't tell it that you already have a source tarball using the --file/-f option. okay. and i still believe that it even makes sense to have .orig stored in the .orig.tar.gz file. it lets you unpack the file as is without having to worry about overwriting the debianized version. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than to fix a system msg07663/pgp0.pgp Description: PGP signature
Re: how to be sure, that /dev/cdrom exists?
On Mon, Oct 28, 2002 at 04:13:20PM -0600, Steve Langasek wrote: On Mon, Oct 28, 2002 at 10:14:50PM +0100, Jan-Hendrik Palic wrote: The softwares behavior on missing devices is cruel ;( If the /dev/cdrom does not exists, it will stop starting ... To solve this, I see two ways, set the link /dev/cdrom or put the right device into the the configfile .. Is it possible to get a fix for this into the upstream sources? Especially in light of the devfs issue pointed out, it would be ideal if the software would deal more gracefully with the absence of this device file. I can also see it being useful to continue running pbbuttonsd when the cdrom drive is physically absent, perhaps due to a hardware failure. there is a already reported bug about this and forwarded to upstream. It seems, that I have poke upstream again .. :) Jan -- .''`.Jan-Hendrik Palic | : :' : ** Debian GNU/ Linux ** | ** OpenOffice.org ** ,.. ,.. `. `' http://www.debian.org | http://www.openoffice.org ,: ..` ` `- [EMAIL PROTECTED] | ' ` ` msg07664/pgp0.pgp Description: PGP signature
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 11:46:51PM +0100, martin f krafft wrote: also sprach Matt Zimmerman [EMAIL PROTECTED] [2002.10.28.2343 +0100]: dh_make doesn't build .orig.tar.gz files. It makes a copy of the source tree names blah.orig, and it only does that if you don't tell it that you already have a source tarball using the --file/-f option. okay. and i still believe that it even makes sense to have .orig stored in the .orig.tar.gz file. No. Pristine source helps users trying to see if you're distributing the same thing upstream is. it lets you unpack the file as is without having to worry about overwriting the debianized version. Use a temporary directory. You should get into the habit of doing this when unpacking random tarballs anyway. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 02:52:56PM -0700, Joel Baker wrote: I do think I'll put information on the include/exclude lists used to build the tarball from a pristine CVS tree into debian/README, though - if for no other reason than to not forget, myself, when I accidentally delete some files (oh, come on, you KNOW it'll happen...) When I have to build my own .orig.tar.gz archives (only when there's no real upstream .tar.gz, in my case), I always have an 'orig' target in debian/rules. It's then a matter of 'fakeroot debian/rules orig' - fakeroot because orig tends to depend on clean. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: orig.tar.gz
On Tue, Oct 29, 2002 at 12:54:28AM +, Colin Watson wrote: On Mon, Oct 28, 2002 at 11:46:51PM +0100, martin f krafft wrote: also sprach Matt Zimmerman [EMAIL PROTECTED] [2002.10.28.2343 +0100]: dh_make doesn't build .orig.tar.gz files. It makes a copy of the source tree names blah.orig, and it only does that if you don't tell it that you already have a source tarball using the --file/-f option. okay. and i still believe that it even makes sense to have .orig stored in the .orig.tar.gz file. No. Pristine source helps users trying to see if you're distributing the same thing upstream is. Well, very often upstream distributes package foo as dir foo only, not as foo-1.2.3, so you have to repackage it anyway, or am i missing something ? it lets you unpack the file as is without having to worry about overwriting the debianized version. Use a temporary directory. You should get into the habit of doing this when unpacking random tarballs anyway. Especially since some random tarballs don't install in a subdirectory. Maybe there is even tar option that helps you do it directly, read the manpage. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
library version equals to project version ?
Hi fellow developpers, I maintain iiwusynth, which until now shipped unversioned libraries. I have been discussing with upstream author for the past days and he agreed that versioning libraries is certainly a good thing. He's in the process of versioning his libraries but asked me details about the versioning scheme, and I'm not sure what the correct answer his... In two words, his question is: should a binary and the library it depends on have the same version number ? Say foo is version M.m.p and depends on foo dynamic library. Should the library necesarily be called libfooM of could it be libfooX ? On one hand I have the example of avifile-player version 0.7.12.20020719-1.2, which depends on libavifile0 version 0.7. OTOH, we have aspell version 0.33.7.1 which depends on libaspell10 version 0.33.7 What is the Very True Way ? I paste below the details of his question: Please CC me on reply. Thanks for your help. - Forwarded message from Peter Hanappe [EMAIL PROTECTED] - From: Peter Hanappe [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: bug in iiwusynth: dubious FPE logging implementation X-Virus-Scanned: by AMaViS new-20020517 X-Razor-id: 44bb8d5d94b139efb3297b797e4e382641ab7d54 X-Spam-Status: No, hits=1.6 tests=MAY_BE_FORGED Eric Van Buggenhaut wrote: [...] You said in a previous mail: Binary executables should be compatible with one major version, all across its succesive minor numbers. Just to make sure I get this right, do you mind I write down a little scenario: - I install iiwusynth-M.m.p that is linked against libiiwusynth.so.X. The ABI version of libiiwusynth is X. - Later, I update to iiwusynth-M.m+1.p that is also linked against libiiwusynth.so.X. There should be no problems since they are ABI compatible. I don't necessarily have to update libiiwusynth. - I update libiiwusynth to a newer version, however that is still ABI version X (i.e. libiiwusynth.so.X), everything continues to work. - However, if I update iiwusynth to version M.m+2.p that is linked against libiiwusynth.so.X+1 there is a conflict and I'll need to install libiiwusynth.so.X+1 as well. Is this about correct? Yes, that's exactly how it works. One detail though, in the scenario above X always = M so I rewrite it: This I don't understand. I have been searching on the web a little and I thought I understood that the library version isn't necessarily equal to the project version. For example, I checked on the debian web site, libaspell version 0.33.7.1-8 (package libaspell10) installs libaspell.so.10, and not libaspell.so.0 (M=0, X=10). I don't want to update iiwusynth to version 1.x.y because somehow (psychologically) version 1.x is the first stable release. If X always = M than *all* libraries before iiwusynth 1.0 have major number 0. It's impossible to keep all those 0 library version ABI compatible, especially in the beginning of a project. Let me know what your thoughts on this are. We'd better straighten this all out before making new packages to avoid future confusion. Sorry to annoy you with all these questions but I want to make sure I understand it correctly. - End forwarded message - -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
Re: Request for sponsor, SML/NJ
On Sun, Oct 27, 2002 at 08:35:24PM -0800, Aaron Matthew Read wrote: Hi, I used to use the SML/NJ package when I was in college for doing projects, so I know it is a useful package to have around. Also, it is one of my favorate languages, so I would like to see it around in Debian. I see that someone is already working on the SML/NJ (97 days preparation), but the link: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=153880 confuses me to who has actually volunteered to take this task on. The RFP was filed by Walter Tautz [EMAIL PROTECTED] Then Søren decided to package it Søren Boll Overgaard [EMAIL PROTECTED] (you can see the last entry on the bug page, Changed Bug title, where he changed it from RFP to ITP. I'd contact him if I were you, since you already did a lot of work. Florian -- E-Mail: [EMAIL PROTECTED] (private) [EMAIL PROTECTED] (Debian-related) Jabber: [EMAIL PROTECTED] ICQ: 167919139 GPG Key ID: B34A0F1D GPG Fingerprint: 6FFC 6751 BBB8 0F60 C39D AB72 4A77 581C B34A 0F1D pgpcvuH7PyNd7.pgp Description: PGP signature
debconf template not included in package ???
Hello, ... I tried adding a little debconf question to one of my packages, and followed the instructions found in the debconf-devel man pages as well as under /usr/share/doc/debconf-doc/tutorial.txt.gz. I created a templates file, put it in the debian directory, created a config file and a postinst file, like was adviced. Now, the package builds fine, i tried running the postinst by hand, and it asked me the question in the template. When i installed the built package, it did not ask me the question, since it had already. Not thinking much (it was late at night), i uploaded the package to unstable. Now, when others try installing the packages, it fails in pre-configure, since there is no mention of the debconf template file in the package, and no mention of my debconf question in /var/cache/debconf/templates.dat. I am a bit at a loss here, how do you make debconf understand it should add the debconf template in the distributed package ? Note that it is a multi-binary package. Friendly, Sven Luther
Re: fixed some RC bugs, need sponsor
On Sun, Oct 27, 2002 at 07:01:01PM -0800, David Kimdon wrote: [snip] Put another way, the orig directory you used was the 1.51-5 debianized source dir, it should have been the pristine upstream source. right, i was missing the point (stupid error btw). new packages on http://debian.esaurito.net should work. anyway fortunes-it is fixed [1] by [EMAIL PROTECTED] so this is quite useless work but your tips help me anyway, thanks. and a diff. For doc-linux-sv the souce package started out wrong, so that isn't your fault, you can leave it as it is. ok, i've fixed also doc-linux-sv with NMU changelog and correct version. Same problem with this one, the orig should not be the previous debian version, but should be the pristine upstream tarball. doc-linux-sv had an incorrect source package to start out with (the version number indicates it is not a debian native package, but the absence of a diff indicates that it is debian-native, this is likely the source of our confusion). If I were you I would leave that source package broken and just fix the RC bug. (perhaps report a bug on the broken source package as well) ok, RC bug #140137 is open, should I open a new one against doc-linux-sv with (trivial) patch attached? when trying to fix #161852 on http-analyze i encountered the same problem (no .orig file only .dsc and debianized .tar.gz) cheers, filippo. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=147018repeatmerged=yes -- Filippo Giunchedi GNU/PG key id: 1024D/6B79D401 Random signature follows: Linux IS user friendly, it is just selective who his friends are. pgp2QqQH2fmcj.pgp Description: PGP signature
Re: fixed some RC bugs, need sponsor
On Mon, Oct 28, 2002 at 03:16:38PM +0100, Filippo Giunchedi wrote: On Sun, Oct 27, 2002 at 07:01:01PM -0800, David Kimdon wrote: [snip] Put another way, the orig directory you used was the 1.51-5 debianized source dir, it should have been the pristine upstream source. right, i was missing the point (stupid error btw). new packages on http://debian.esaurito.net should work. anyway fortunes-it is fixed [1] by [EMAIL PROTECTED] so this is quite useless work but your tips help me anyway, thanks. Sorry guys, I missed this thread before NMUing... -- Francesco P. Lovergine
Re: debconf template not included in package ???
Sven Luther wrote: I created a templates file, put it in the debian directory, created a config file and a postinst file, like was adviced. Now, the package builds fine, i tried running the postinst by hand, and it asked me the question in the template. When i installed the built package, it did not ask me the question, since it had already. Not thinking much (it was late at night), i uploaded the package to unstable. Now, when others try installing the packages, it fails in pre-configure, since there is no mention of the debconf template file in the package, and no mention of my debconf question in /var/cache/debconf/templates.dat. I am a bit at a loss here, how do you make debconf understand it should add the debconf template in the distributed package ? Put the templates file in debian/package.templates. dh_installdebconf will install it from there into debian/package/DEBIAN. -- see shy jo pgpgQQhz8dTXh.pgp Description: PGP signature
Re: debconf template not included in package ???
On Mon, Oct 28, 2002 at 10:39:03AM -0500, Joey Hess wrote: Sven Luther wrote: I created a templates file, put it in the debian directory, created a config file and a postinst file, like was adviced. Now, the package builds fine, i tried running the postinst by hand, and it asked me the question in the template. When i installed the built package, it did not ask me the question, since it had already. Not thinking much (it was late at night), i uploaded the package to unstable. Now, when others try installing the packages, it fails in pre-configure, since there is no mention of the debconf template file in the package, and no mention of my debconf question in /var/cache/debconf/templates.dat. I am a bit at a loss here, how do you make debconf understand it should add the debconf template in the distributed package ? Put the templates file in debian/package.templates. dh_installdebconf will install it from there into debian/package/DEBIAN. Ok, thanks. Maybe this should be more proeminently said in /usr/share/doc/debconf-doc/tutorial.txt.gz, no, there is only a quick mention about installing in debian/tmp/DEBIAN/, which i missed, and the fact that the newline cut this path in two did not help. Also maybe the note about debhelper should be expanded a bit, there is no mention of dh_installdebconf at all, and it was commented out in my debian/rules (maybe even by default in debhelper ?). Friendly, Sven Luther
Re: debconf template not included in package ???
Sven Luther wrote: Maybe this should be more proeminently said in /usr/share/doc/debconf-doc/tutorial.txt.gz, no, there is only a quick mention about installing in debian/tmp/DEBIAN/, which i missed, and the fact that the newline cut this path in two did not help. Also maybe the note about debhelper should be expanded a bit, there is no mention of dh_installdebconf at all, and it was commented out in my debian/rules (maybe even by default in debhelper ?). The tutorial is a bit outdated (though still useful for the few packages that need to be converted to debconf from ad-hoc prompting, perhaps). The debconf-devel(7) man page has a lot more information. -- see shy jo pgpDJtVPsaBfT.pgp Description: PGP signature
Re: debconf template not included in package ???
On Mon, Oct 28, 2002 at 11:05:59AM -0500, Joey Hess wrote: Sven Luther wrote: Maybe this should be more proeminently said in /usr/share/doc/debconf-doc/tutorial.txt.gz, no, there is only a quick mention about installing in debian/tmp/DEBIAN/, which i missed, and the fact that the newline cut this path in two did not help. Also maybe the note about debhelper should be expanded a bit, there is no mention of dh_installdebconf at all, and it was commented out in my debian/rules (maybe even by default in debhelper ?). The tutorial is a bit outdated (though still useful for the few packages that need to be converted to debconf from ad-hoc prompting, perhaps). The debconf-devel(7) man page has a lot more information. Mmm, yes, i see it now, too bad i missed it. Thanks for your help. Friendly, Sven Luther
Re: library version equals to project version ?
On Mon, Oct 28, 2002 at 02:17:52PM +0100, Eric Van Buggenhaut wrote: I maintain iiwusynth, which until now shipped unversioned libraries. I have been discussing with upstream author for the past days and he agreed that versioning libraries is certainly a good thing. He's in the process of versioning his libraries but asked me details about the versioning scheme, and I'm not sure what the correct answer his... In two words, his question is: should a binary and the library it depends on have the same version number ? They should only have the same version number if his versioning of the binary is going to *follow* the versioning of the library. The library major version *must* be incremented every time the ABI changes incompatibly, and should not be changed when the ABI has not changed. Since ABI changes don't necessarily correspond to major milestones in an application's development, most people prefer to not use this approach to versioning their application. On one hand I have the example of avifile-player version 0.7.12.20020719-1.2, which depends on libavifile0 version 0.7. OTOH, we have aspell version 0.33.7.1 which depends on libaspell10 version 0.33.7 In both cases, the number that's part of the package name should indicate how many times the ABI has changed. Steve Langasek postmodern programmer pgpi5CThlQGd4.pgp Description: PGP signature
Re: library version equals to project version ?
Eric Van Buggenhaut [EMAIL PROTECTED] immo vero scripsit: On one hand I have the example of avifile-player version 0.7.12.20020719-1.2, which depends on libavifile0 version 0.7. OTOH, we have aspell version 0.33.7.1 which depends on libaspell10 version 0.33.7 The interface number of a shared library should usually be distinct from the version number of the package itself, since interface usually does not correspond to package versions. Interface do change with minor version upgrades, in which case interface number should be updated, and even with major version upgrades, interface compatibility can be kept, which means interface number does not need to change. avifile-player probably ignores that part, or changes the library version number on every release, or whatever. -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
Re: how to be sure, that /dev/cdrom exists?
On Sun, Oct 27, 2002 at 11:33:31PM +0100, Jan-Hendrik Palic wrote: I'm maintaining pbbuttonsd for PPC-Notebooks. I'm preparing the new upstream version and I stuck at this point, that the pbbuttonsd wants to have a link /dev/cdrom. How can I satisfy the dependency on the easiest way? Can the software not function without /dev/cdrom? Unless I'm mistaken, this software has plenty of uses even if there's no cdrom installed in the machine. The best way to make sure the /dev/cdrom link is present is to check for it, use debconf to prompt the user if it's absent, and then create the link (possibly with some /proc autodetection) if the user agrees to let you create the link. Steve Langasek postmodern programmer pgpV5W1YsbQ2u.pgp Description: PGP signature
orig.tar.gz
I'm currently working to package pieces of the NetBSD source tree (little things like libc12, for instance). Because the full source tree is vast, unwieldly, and by and large much of it is not actually useful or needed for the Debian GNU/NetBSD port (for example, the entire gnu/ tree is replaced by Debian packaged software), these packages are generally built based on a partial copy of the relevant parts of the NetBSD CVS tree (currently from the tagged release point release-1-6). It's easy enough to create an orig.tar.gz: tar -czvf libc12_1.6.orig.tar.gz libc12-1.6/*.bz2 produces one. However, I run into a problem at this point; future releases of the package (-2 and above) might well need to pull in different files or parts of the source tree. This would result in a different orig.tar.gz file, which seems like it wouldn't work - however, it also seems silly (and probably confusing) to version it as Debian-native, since there is a clear versioning point in the upstream sources. Certainly, it would be possible to tar up the entire tree, 'just to be safe', but the *compressed* tarball (bzip2 -9 or gzip -9) is close to half a gig, of which the vast majority is useless. Please tell me there's a better solution... -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpKPV1F3kizK.pgp Description: PGP signature
Re: how to be sure, that /dev/cdrom exists?
On Mon, 28 Oct 2002 18:07, Steve Langasek wrote: The best way to make sure the /dev/cdrom link is present is to check for it, use debconf to prompt the user if it's absent, and then create the link (possibly with some /proc autodetection) if the user agrees to let you create the link. Except if /dev/.devfsd exists which indicates the presence of devfs. When running devfs you should never create anything under /dev. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: orig.tar.gz
It's easy enough to create an orig.tar.gz: tar -czvf libc12_1.6.orig.tar.gz libc12-1.6/*.bz2 produces one. Actually, this should be tar -czvf libc12_1.6.orig.tar.gz libc12-1.6.orig/ However, I run into a problem at this point; future releases of the package (-2 and above) might well need to pull in different files or parts of the source tree. This would result in a different orig.tar.gz file, which seems like it wouldn't work The additional files will be represented in the .diff.gz files... Is that not enough? -- .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than to fix a system pgpTV3Odh36ei.pgp Description: PGP signature
Packet Writing kernel patch packaged (at half)
hi all, I've packaged a dirty but working deb of the Packet Writing kernel patch(2.4 kernels), which let to write on cdrw with an udf fs, the deb is here, even if it's not yet apt-gettable: http://ketavet.dyndns.org/debian/kernel-patch-packet-2.4.deb Now before claim a sponsor I'm trying to understand something about dh-kpatches, which are not so clear to me, and I've to decide what policy about this patch versions to include in the packet, because they are for many kenel prereleases from 2.4.9 to 2.4.20pre11 nowadays, for now I thought that the patches for the kernel sources that I find apt-gettable within sid. At least this mail is to shut up my todo list for what concerns the deb made with dpkg-deb. Luca Pasquali
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 07:41:23PM +0100, martin f krafft wrote: It's easy enough to create an orig.tar.gz: tar -czvf libc12_1.6.orig.tar.gz libc12-1.6/*.bz2 produces one. Actually, this should be tar -czvf libc12_1.6.orig.tar.gz libc12-1.6.orig/ Why? -- - mdz
Re: orig.tar.gz
also sprach Matt Zimmerman [EMAIL PROTECTED] [2002.10.28.2008 +0100]: Actually, this should be tar -czvf libc12_1.6.orig.tar.gz libc12-1.6.orig/ Why? .orig.tar.gz files unpack .orig directories, that's why. I don't know why this is so, but I know that it is so. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than to fix a system pgp0uFJhTSHPL.pgp Description: PGP signature
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 07:41:23PM +0100, martin f krafft wrote: It's easy enough to create an orig.tar.gz: tar -czvf libc12_1.6.orig.tar.gz libc12-1.6/*.bz2 produces one. Actually, this should be tar -czvf libc12_1.6.orig.tar.gz libc12-1.6.orig/ There is no spoon. Er. There is no libc12-1.6.orig/ I'm packaging the bz2 tarball because I'm using DBS with multiple separate tarballs being unpacked to form the build-tree. However, I run into a problem at this point; future releases of the package (-2 and above) might well need to pull in different files or parts of the source tree. This would result in a different orig.tar.gz file, which seems like it wouldn't work The additional files will be represented in the .diff.gz files... Is that not enough? Given that they're not Debian differences from the source, but rather, files from the origional source tree that I screwed up and forgot to add or remove properly, no, that isn't enough. Further commentary on IRC indicates that this whole thing is tilting at windmills, and I should just throw in the towel and forget orig.tar.gz and go with a Debian native version (1.6+debian+1 or the like), because it is Not Kosher to mess with the orig.tar.gz in any way, once it's been uploaded, unless you're doing a new version (not just new revision) of the package. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpK3SQyWuqts.pgp Description: PGP signature
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 08:32:36PM +0100, martin f krafft wrote: also sprach Matt Zimmerman [EMAIL PROTECTED] [2002.10.28.2008 +0100]: Actually, this should be tar -czvf libc12_1.6.orig.tar.gz libc12-1.6.orig/ Why? .orig.tar.gz files unpack .orig directories, that's why. I don't know why this is so, but I know that it is so. If you don't know why it is so, then why are you instructing others to do this? In fact, it is not so. Pristine .orig.tar.gz files do not generally unpack .orig directories, and source archives should be pristine whenever possible. -- - mdz
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 10:56:02AM -0700, Joel Baker wrote: I'm currently working to package pieces of the NetBSD source tree (little things like libc12, for instance). Because the full source tree is vast, unwieldly, and by and large much of it is not actually useful or needed for the Debian GNU/NetBSD port (for example, the entire gnu/ tree is replaced by Debian packaged software), these packages are generally built based on a partial copy of the relevant parts of the NetBSD CVS tree (currently from the tagged release point release-1-6). It's easy enough to create an orig.tar.gz: tar -czvf libc12_1.6.orig.tar.gz libc12-1.6/*.bz2 produces one. However, I run into a problem at this point; future releases of the package (-2 and above) might well need to pull in different files or parts of the source tree. This would result in a different orig.tar.gz file, which seems like it wouldn't work - however, it also seems silly (and probably confusing) to version it as Debian-native, since there is a clear versioning point in the upstream sources. You can either modify the upstream version number every time you have to make changes to the tarball (e.g., libc12_1.6, libc12_1.6+debian.0, libc12_1.6+debian.1), or you can include any subsequent modifications in your Debian diff. Your choice. If you expect to be making frequent changes to how much of upstream's code you're including, option 1 might easily reduce to a native package. Steve Langasek postmodern programmer pgpbIHtf4wV52.pgp Description: PGP signature
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 10:56:02AM -0700, Joel Baker wrote: However, I run into a problem at this point; future releases of the package (-2 and above) might well need to pull in different files or parts of the source tree. This would result in a different orig.tar.gz file, which seems like it wouldn't work - however, it also seems silly (and probably confusing) to version it as Debian-native, since there is a clear versioning point in the upstream sources. Given that I expect you might frequently find yourself doing either of changing the tarball in this way and making Debian-specific changes, I'd go for having the upstream version as 1.6-date, where date is the date on which you constructed the tarball (or some other similar strictly increasing scheme). Then you keep the upstream version and still get to make Debian-specific changes with reasonable efficiency. -- Colin Watson [EMAIL PROTECTED]
Re: orig.tar.gz
Joel Baker [EMAIL PROTECTED] writes: It's easy enough to create an orig.tar.gz: tar -czvf libc12_1.6.orig.tar.gz libc12-1.6/*.bz2 produces one. However, I run into a problem at this point; future releases of the package (-2 and above) might well need to pull in different files or parts of the source tree. This would result in a different orig.tar.gz file, which seems like it wouldn't work - however, it also seems silly (and probably confusing) to version it as Debian-native, since there is a clear versioning point in the upstream sources. Disclaimer: I'm not in the keyring, and have therefore never uploaded a package myself, so I don't know if my suggestion is worthless, but nobody else seems to mention what appears to me as the obvious, so here goes.. You could try running dpkg-buildpackage with the -sa option for each upload you want to regenerate the fake upstream tarball? -- Tore Anderson
Re: how to be sure, that /dev/cdrom exists?
Hi .. thnx for your answer .. On Mon, Oct 28, 2002 at 11:07:07AM -0600, Steve Langasek wrote: I'm maintaining pbbuttonsd for PPC-Notebooks. I'm preparing the new upstream version and I stuck at this point, that the pbbuttonsd wants to have a link /dev/cdrom. Can the software not function without /dev/cdrom? Unless I'm mistaken, this software has plenty of uses even if there's no cdrom installed in the machine. The softwares behavior on missing devices is cruel ;( If the /dev/cdrom does not exists, it will stop starting ... To solve this, I see two ways, set the link /dev/cdrom or put the right device into the the configfile .. The best way to make sure the /dev/cdrom link is present is to check for it, use debconf to prompt the user if it's absent, and then create the link (possibly with some /proc autodetection) if the user agrees to let you create the link. yes I think this, too ... thnx Jan -- .''`.Jan-Hendrik Palic | : :' : ** Debian GNU/ Linux ** | ** OpenOffice.org ** ,.. ,.. `. `' http://www.debian.org | http://www.openoffice.org ,: ..` ` `- [EMAIL PROTECTED] | ' ` ` pgpn3zhOI8mqh.pgp Description: PGP signature
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 09:34:28PM +0100, Tore Anderson wrote: Disclaimer: I'm not in the keyring, and have therefore never uploaded a package myself, so I don't know if my suggestion is worthless, but nobody else seems to mention what appears to me as the obvious, so here goes.. You could try running dpkg-buildpackage with the -sa option for each upload you want to regenerate the fake upstream tarball? It is not permitted to replace an existing source tarball in the archive with a different one having the same version number. This rule exists to preserve the sanity of developers and users. :-) -- - mdz
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 01:51:01PM -0600, Steve Langasek wrote: On Mon, Oct 28, 2002 at 10:56:02AM -0700, Joel Baker wrote: I'm currently working to package pieces of the NetBSD source tree (little things like libc12, for instance). Because the full source tree is vast, unwieldly, and by and large much of it is not actually useful or needed for the Debian GNU/NetBSD port (for example, the entire gnu/ tree is replaced by Debian packaged software), these packages are generally built based on a partial copy of the relevant parts of the NetBSD CVS tree (currently from the tagged release point release-1-6). It's easy enough to create an orig.tar.gz: tar -czvf libc12_1.6.orig.tar.gz libc12-1.6/*.bz2 produces one. However, I run into a problem at this point; future releases of the package (-2 and above) might well need to pull in different files or parts of the source tree. This would result in a different orig.tar.gz file, which seems like it wouldn't work - however, it also seems silly (and probably confusing) to version it as Debian-native, since there is a clear versioning point in the upstream sources. You can either modify the upstream version number every time you have to make changes to the tarball (e.g., libc12_1.6, libc12_1.6+debian.0, libc12_1.6+debian.1), or you can include any subsequent modifications in your Debian diff. Your choice. If you expect to be making frequent changes to how much of upstream's code you're including, option 1 might easily reduce to a native package. Indeed. This seems to be the cleanest way, really - specifically, to devolve it into a Debian-native package, with the version mapped from upstream's versioning plus what would otherwise be a -rev value. I'd say it was unfortunate to lose the diff.gz summarizing Debian changes, but you don't, really - just unpack the entire thing and rm the source tarball, if you really care. I do think I'll put information on the include/exclude lists used to build the tarball from a pristine CVS tree into debian/README, though - if for no other reason than to not forget, myself, when I accidentally delete some files (oh, come on, you KNOW it'll happen...) -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpPRC2DuIBQz.pgp Description: PGP signature
Re: how to be sure, that /dev/cdrom exists?
On Mon, Oct 28, 2002 at 10:14:50PM +0100, Jan-Hendrik Palic wrote: On Mon, Oct 28, 2002 at 11:07:07AM -0600, Steve Langasek wrote: I'm maintaining pbbuttonsd for PPC-Notebooks. I'm preparing the new upstream version and I stuck at this point, that the pbbuttonsd wants to have a link /dev/cdrom. Can the software not function without /dev/cdrom? Unless I'm mistaken, this software has plenty of uses even if there's no cdrom installed in the machine. The softwares behavior on missing devices is cruel ;( If the /dev/cdrom does not exists, it will stop starting ... To solve this, I see two ways, set the link /dev/cdrom or put the right device into the the configfile .. Is it possible to get a fix for this into the upstream sources? Especially in light of the devfs issue pointed out, it would be ideal if the software would deal more gracefully with the absence of this device file. I can also see it being useful to continue running pbbuttonsd when the cdrom drive is physically absent, perhaps due to a hardware failure. Steve Langasek postmodern programmer pgpIKVF2tEzNL.pgp Description: PGP signature
Re: orig.tar.gz
also sprach Matt Zimmerman [EMAIL PROTECTED] [2002.10.28.2041 +0100]: If you don't know why it is so, then why are you instructing others to do this? why does dh_make do it? -- .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than to fix a system pgpmtw5b87mNm.pgp Description: PGP signature
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 11:30:15PM +0100, martin f krafft wrote: also sprach Matt Zimmerman [EMAIL PROTECTED] [2002.10.28.2041 +0100]: If you don't know why it is so, then why are you instructing others to do this? why does dh_make do it? dh_make doesn't build .orig.tar.gz files. It makes a copy of the source tree names blah.orig, and it only does that if you don't tell it that you already have a source tarball using the --file/-f option. I see no reason why it should not detect the existence of a file with the proper name and use it, so I have filed a wishlist bug to that effect. -- - mdz
Re: orig.tar.gz
also sprach Matt Zimmerman [EMAIL PROTECTED] [2002.10.28.2343 +0100]: dh_make doesn't build .orig.tar.gz files. It makes a copy of the source tree names blah.orig, and it only does that if you don't tell it that you already have a source tarball using the --file/-f option. okay. and i still believe that it even makes sense to have .orig stored in the .orig.tar.gz file. it lets you unpack the file as is without having to worry about overwriting the debianized version. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than to fix a system pgpI439JIR3V2.pgp Description: PGP signature
Re: how to be sure, that /dev/cdrom exists?
On Mon, Oct 28, 2002 at 04:13:20PM -0600, Steve Langasek wrote: On Mon, Oct 28, 2002 at 10:14:50PM +0100, Jan-Hendrik Palic wrote: The softwares behavior on missing devices is cruel ;( If the /dev/cdrom does not exists, it will stop starting ... To solve this, I see two ways, set the link /dev/cdrom or put the right device into the the configfile .. Is it possible to get a fix for this into the upstream sources? Especially in light of the devfs issue pointed out, it would be ideal if the software would deal more gracefully with the absence of this device file. I can also see it being useful to continue running pbbuttonsd when the cdrom drive is physically absent, perhaps due to a hardware failure. there is a already reported bug about this and forwarded to upstream. It seems, that I have poke upstream again .. :) Jan -- .''`.Jan-Hendrik Palic | : :' : ** Debian GNU/ Linux ** | ** OpenOffice.org ** ,.. ,.. `. `' http://www.debian.org | http://www.openoffice.org ,: ..` ` `- [EMAIL PROTECTED] | ' ` ` pgpvcES03yk6L.pgp Description: PGP signature
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 11:46:51PM +0100, martin f krafft wrote: also sprach Matt Zimmerman [EMAIL PROTECTED] [2002.10.28.2343 +0100]: dh_make doesn't build .orig.tar.gz files. It makes a copy of the source tree names blah.orig, and it only does that if you don't tell it that you already have a source tarball using the --file/-f option. okay. and i still believe that it even makes sense to have .orig stored in the .orig.tar.gz file. No. Pristine source helps users trying to see if you're distributing the same thing upstream is. it lets you unpack the file as is without having to worry about overwriting the debianized version. Use a temporary directory. You should get into the habit of doing this when unpacking random tarballs anyway. -- Colin Watson [EMAIL PROTECTED]
Re: orig.tar.gz
On Mon, Oct 28, 2002 at 02:52:56PM -0700, Joel Baker wrote: I do think I'll put information on the include/exclude lists used to build the tarball from a pristine CVS tree into debian/README, though - if for no other reason than to not forget, myself, when I accidentally delete some files (oh, come on, you KNOW it'll happen...) When I have to build my own .orig.tar.gz archives (only when there's no real upstream .tar.gz, in my case), I always have an 'orig' target in debian/rules. It's then a matter of 'fakeroot debian/rules orig' - fakeroot because orig tends to depend on clean. -- Colin Watson [EMAIL PROTECTED]
