Re: Fix a bug located in a dependency
On Thu, May 24, 2007 at 11:41:49PM +0300, Damyan Ivanov [EMAIL PROTECTED] wrote: -=| Mike Hommey, Thu, 24 May 2007 19:39:20 +0200 |=- A standard example of this are bugs in applications that are due to bugs in libraries they depend on. Users would report bugs on the application, but it would be reassigned to the library. Next users reporting the bug would not see it in the list of bugs for the application with reportbug. How about cloning the bug, reassigning the clone to the library and making the original bug be blocked by the clone? Sadly, the block stuff doesn't even notify the blocked bug when the blocker bug is closed... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fix a bug located in a dependency
-=| Mike Hommey, Fri, 25 May 2007 08:12:15 +0200 |=- On Thu, May 24, 2007 at 11:41:49PM +0300, Damyan Ivanov [EMAIL PROTECTED] wrote: -=| Mike Hommey, Thu, 24 May 2007 19:39:20 +0200 |=- A standard example of this are bugs in applications that are due to bugs in libraries they depend on. Users would report bugs on the application, but it would be reassigned to the library. Next users reporting the bug would not see it in the list of bugs for the application with reportbug. How about cloning the bug, reassigning the clone to the library and making the original bug be blocked by the clone? Sadly, the block stuff doesn't even notify the blocked bug when the blocker bug is closed... This is #323663, I guess. Is the other solution (proposed by Don) - reassign #n A,B going to work in your case? -- damJabberID: [EMAIL PROTECTED] signature.asc Description: PGP signature
Re: Fix a bug located in a dependency
On Fri, May 25, 2007 at 09:18:19AM +0300, Damyan Ivanov [EMAIL PROTECTED] wrote: -=| Mike Hommey, Fri, 25 May 2007 08:12:15 +0200 |=- On Thu, May 24, 2007 at 11:41:49PM +0300, Damyan Ivanov [EMAIL PROTECTED] wrote: -=| Mike Hommey, Thu, 24 May 2007 19:39:20 +0200 |=- A standard example of this are bugs in applications that are due to bugs in libraries they depend on. Users would report bugs on the application, but it would be reassigned to the library. Next users reporting the bug would not see it in the list of bugs for the application with reportbug. How about cloning the bug, reassigning the clone to the library and making the original bug be blocked by the clone? Sadly, the block stuff doesn't even notify the blocked bug when the blocker bug is closed... This is #323663, I guess. Is the other solution (proposed by Don) - reassign #n A,B going to work in your case? Doesn't that fuck up versioning tracking of the BTS ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITA or ITP, for former Debian packages?
On 24 May 2007 16:38:58 -0700 Robert J. Clay [EMAIL PROTECTED] wrote: But what about closed ones? The package I've started on (Fidogate) had 9 bugs against it; 8 of them closed by it being removed from the Debian archive.If they were still open, then most if not all would be closable by the new package I'll be working on. IMHO, if one or more of those bugs were release-critical, you should fix those in the very first upload or your upload could be rejected. Just put a note in the debian/changelog. Less serious bugs that have not been fixed can be re-opened after the upload has been accepted. It may also be worth commenting on which bugs have been fixed in the ITA, prior to your upload. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpWTZi18GjZG.pgp Description: PGP signature
RFS: lj2mail - livejournal friendlist update tracker
Dear mentors, I am looking for a sponsor for my package lj2mail. * Package name : lj2mail Version : 0.0.145 Upstream Author : Alexey Alexandrov * URL : http://code.google.com/p/lj2mail/ * License : GPL Section : net It builds these binary packages: lj2mail - livejournal friendlist update tracker The package is lintian clean. The package can be found at http://deb.swd.pp.ru/pool/ I would be glad if someone uploaded this package for me. Kind regards Alexey Alexandrov
Request for Review: emboss-explorer
Dear Mentors, I've created a package, emboss-explorer, part of the Debian-Med and Pkg-Emboss projects. It works, but I'd like a review to be sure it will work on an out-of-the-box Debian installation. You can get the package at: http://mentors.debian.net/debian/pool/main/e/emboss-explorer/emboss-explorer_2.2.0-1.dsc Thank you for your attention, David -- . ''`. Debian packager! | http://snipurl.com/gofoxygo/ : :' : User #334216 | http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://www.debianizzati.org/ `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fix a bug located in a dependency
On Fri, May 25, 2007 at 12:04:16AM -0700, Don Armstrong wrote: Doesn't that fuck up versioning tracking of the BTS ? No, because the bug should only be found in B, not A. So how would it help users with reportbug if the bug is now on B and not A, when they report on A ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fix a bug located in a dependency
On Fri, 25 May 2007, Mike Hommey wrote: On Fri, May 25, 2007 at 12:04:16AM -0700, Don Armstrong wrote: Doesn't that fuck up versioning tracking of the BTS ? No, because the bug should only be found in B, not A. So how would it help users with reportbug if the bug is now on B and not A, when they report on A ? I'm apparently not being clear enough. The bug in this case would be assigned to A,B. The versions in which the bug is found are B/1.2-3 or similar. Because no version of A is listed, as soon as the bug is -done it will be fixed as far as A is concerned, but present in appropriate versions of B. Found is refering to versions in which the bug is found, not the package to which a bug is assigned. Don Armstrong -- Information wants to be free to kill again. -- Red Robot http://www.dieselsweeties.com/archive.php?s=1372 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: peless -- dh_helper
On Thu, May 24, 2007 at 11:59:31PM +0300, Damyan Ivanov wrote: [added the list again] -=| Giorgio Pioda, Thu, 24 May 2007 21:11:19 +0200 |=- If I were you, I'd try to make make install not strip anything, patching if necessary[1]. The problem with dh_install approach is that you have to check carefully if there is something new to install every now and then, which leads to problems (as already seen). The world is nice because it is possible to find many different opinions... I see your confusion and I understand it. It is not so good feeling to try to satisfy contradicting requirements. I, personally, will not sponsor a package that replaces a perfectly working make install with broken dh_install usage. Even if dh_install usage is fixed, I still don't like it. This, of course, does not mean that nobody else will want to sponsor it. Gentlemen, I am by no means an expert on debian, but as the upstream developer of peless, I have to agree with Mr. Damyan Ivanov on this technical issue. The history of Computers shows that whenever the same piece of data is stored/maintained in more than one place, they inevitably get out of sync, resulting in bugs and problems. As the developer of peless, I must insure that make and make install work properly. I do this indirectly by making sure that configure.ac and Makefile.am are correct. make and make install control the way peless is built and the way files are copied to their ultimate destinations. make and make install definitely must be used for distributions other than debian. Now I glean from the discussions you have been having, that if dh_install is used, then essentially the same information must be maintained somewhere else. History shows that this can not be good. For example, one of the next things I want to do with peless is to make sure peless properly publishes its .pot file as the first step toward making peless multi-lingual. When I do this, I will adjust the auto* control files to make sure that make and make install do the RIGHT THINGS(tm). But you seem to be telling me that if dh_install is used, that files relevant to dh_install must also be adjusted. This has to be bad. The same data being managed in 2 places, by 2 different people. I am by no means a debian expert, but it seems to me from what I have been able to glean from this discussion that dh_install is associated with a fundamental software management design error. This could be important with packages more critical than peless. -- Paul Elliott 1(512)837-1096 [EMAIL PROTECTED]PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117 pgpgT3F4tNXEz.pgp Description: PGP signature
Re: RFS: peless -- dh_helper
Hello Paul and Damyan On Thu, May 24, 2007 at 11:59:31PM +0300, Damyan Ivanov wrote: [added the list again] -=| Giorgio Pioda, Thu, 24 May 2007 21:11:19 +0200 |=- If I were you, I'd try to make make install not strip anything, patching if necessary[1]. The problem with dh_install approach is that you have to check carefully if there is something new to install every now and then, which leads to problems (as already seen). The world is nice because it is possible to find many different opinions... I see your confusion and I understand it. It is not so good feeling to try to satisfy contradicting requirements. I, personally, will not sponsor a package that replaces a perfectly working make install with broken dh_install usage. Even if dh_install usage is fixed, I still don't like it. This, of course, does not mean that nobody else will want to sponsor it. Gentlemen, I am by no means an expert on debian, but as the upstream developer of peless, I have to agree with Mr. Damyan Ivanov on this technical issue. The history of Computers shows that whenever the same piece of data is stored/maintained in more than one place, they inevitably get out of sync, resulting in bugs and problems. As the developer of peless, I must insure that make and make install work properly. I do this indirectly by making sure that configure.ac and Makefile.am are correct. make and make install control the way peless is built and the way files are copied to their ultimate destinations. make and make install definitely must be used for distributions other than debian. Now I glean from the discussions you have been having, that if dh_install is used, then essentially the same information must be maintained somewhere else. History shows that this can not be good. Ok, then in that case the configure and make could be improved to have a clean nostrip option which normally is called with make install -s and can be set up in debian/rules together with the noopt option For example, one of the next things I want to do with peless is to make sure peless properly publishes its .pot file as the first step toward making peless multi-lingual. When I do this, I will adjust the auto* control files to make sure that make and make install do the RIGHT THINGS(tm). But you seem to be telling me that if dh_install is used, that files relevant to dh_install must also be adjusted. This has to be bad. The same data being managed in 2 places, by 2 different people. I am by no means a debian expert, but it seems to me from what I have been able to glean from this discussion that dh_install is associated with a fundamental software management design error. This could be important with packages more critical than peless. I've already set back to make install the install mechanism, and the first test was OK. I'll upload to my web space the recompiled package as soon as I'll get half an hour of time in front of my sid-workstation, probably during the week-end. At this time I expect the package to be mature. For multilingual support, as far as the make install will be used, I don't expect big problems. cheers Giorgio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: peless -- dh_helper
On Fri, May 25, 2007 at 05:36:34PM +0200, Giorgio Pioda wrote: Hello Paul and Damyan On Thu, May 24, 2007 at 11:59:31PM +0300, Damyan Ivanov wrote: [added the list again] -=| Giorgio Pioda, Thu, 24 May 2007 21:11:19 +0200 |=- If I were you, I'd try to make make install not strip anything, patching if necessary[1]. The problem with dh_install approach is that you have to check carefully if there is something new to install every now and then, which leads to problems (as already seen). The world is nice because it is possible to find many different opinions... I see your confusion and I understand it. It is not so good feeling to try to satisfy contradicting requirements. I, personally, will not sponsor a package that replaces a perfectly working make install with broken dh_install usage. Even if dh_install usage is fixed, I still don't like it. This, of course, does not mean that nobody else will want to sponsor it. Gentlemen, I am by no means an expert on debian, but as the upstream developer of peless, I have to agree with Mr. Damyan Ivanov on this technical issue. The history of Computers shows that whenever the same piece of data is stored/maintained in more than one place, they inevitably get out of sync, resulting in bugs and problems. As the developer of peless, I must insure that make and make install work properly. I do this indirectly by making sure that configure.ac and Makefile.am are correct. make and make install control the way peless is built and the way files are copied to their ultimate destinations. make and make install definitely must be used for distributions other than debian. Now I glean from the discussions you have been having, that if dh_install is used, then essentially the same information must be maintained somewhere else. History shows that this can not be good. Ok, then in that case the configure and make could be improved to have a clean nostrip option which normally is called with make install -s and can be set up in debian/rules together with the noopt option OK, but first let me understand what I am fixing. What is wrong with make install as it is? There is also a make install-strip. I did not do anything special to create these targets; auto* tools created them. What exactly is wrong with make install? Thank you. -- Paul Elliott 1(512)837-1096 [EMAIL PROTECTED]PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117 pgpHV5OByPqAt.pgp Description: PGP signature
Re: Fix a bug located in a dependency
Hello Don, Don Armstrong [EMAIL PROTECTED] wrote: On Thu, 24 May 2007, Jörg Sommer wrote: I really would like to hear you oppinion about the following matter: Package A depends on libB. There's a bug in libB. A bug report was files to package A, because the submitter spotted the bug in package A. What would you, as maintainer of package A, do? Either 1) reassign the bug to libB itself, or 2) reassign the bug to both libB,A or 3) clone the bug and reassign the clone. Thanks for your and the others advice. I will reassign the bug to libB. Bye, Jörg. -- Der kommt den Göttern am nächsten, der auch dann schweigen kann, wenn er im Recht ist. (Cato; 234–149 v. Chr.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for Review: emboss-explorer
* David Paleino [EMAIL PROTECTED] [2007-05-25 10:25:12 +0200]: Dear Mentors, I've created a package, emboss-explorer, part of the Debian-Med and Pkg-Emboss projects. It works, but I'd like a review to be sure it will work on an out-of-the-box Debian installation. You can get the package at: http://mentors.debian.net/debian/pool/main/e/emboss-explorer/emboss-explorer_2.2.0-1.dsc Well, for starters the build-depends don't seem to be complete as the build fails: touch patch-stamp # the VENDORARCHEXP and INSTALLVENDORARCH # variables are set to avoid the creation # of /usr/lib/perl5 perl Makefile.PL \ INSTALLDIRS=vendor \ VENDORARCHEXP=/usr/share/perl5 \ INSTALLVENDORARCH=/usr/share/perl5 MakeMaker FATAL: prerequisites not found (Mail::Send not installed) Please install these modules first and rerun 'perl Makefile.PL'. Checking if your kit is complete... Looks good make: *** [build] Error 29 debuild: fatal error at line 1228: debian/rules build failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for Review: emboss-explorer
Oleksandr Moskalenko ha scritto: Well, for starters the build-depends don't seem to be complete as the build fails: ... MakeMaker FATAL: prerequisites not found (Mail::Send not installed) ... I've fixed it, thanks. Bad habit of not using pdebuild -.-' Any other issue? Thanks, David -- . ''`. Debian packager! | http://snipurl.com/gofoxygo/ : :' : User #334216 | http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://www.debianizzati.org/ `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Build package first, or change to ITA first?
Thanks to Piotr and Matthew for replying. I'll change the bug to ITA now. Richard Fearn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
LBAdmin package
Dear Mentors, I've created a 'deb' package called 'lbadmin', an administration tool for load balancing and high availability clusters. All problems solved, except the following when running lintian: E: lbadmin: package-contains-xvpics-dir var/www/lbadmin-1.0/images/.xvpics/ I've searched the mailing list and no answer. How can I solve this ? Two other questions: 1) How could I put the lbadmin package in http://mentors.debian.net/debian/pool/mainhttp://mentors.debian.net/debian/pool/main/e/emboss-explorer/emboss-explorer_2.2.0-1.dsc? 2) And, I would like to properly package this software for inclusion into Debian. What should I do ? Thanks, John.
Re: RFS: peless -- dh_helper
Hi Damyan I probably right now have understood what is going on... Damyan Ivanov ha scritto: -=| Paul Elliott, Fri, 25 May 2007 11:32:02 -0500 |=- OK, but first let me understand what I am fixing. What is wrong with make install as it is? There is also a make install-strip. I did not do anything special to create these targets; auto* tools created them. What exactly is wrong with make install? Thank you. As far as I understand, Giorgio's concerns were that a plain make install strips the debug information from the binaries installed. However, I can't confirm this: $ file debian/peless/usr/bin/peless debian/peless/usr/bin/peless: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.1, dynamically linked (uses shared libs), not stripped (this is after changing debian/rules to use make install and break right after it) So, Giorgio, it seems perfectly safe to use make install, no? Effectively is not stripping by default (as often happens) and the option present in the makefile called install-strip is also not stripping as compiling and then installing with make install-strip gives a package that has exactly the same dimension as the package with the normal make install. So you are right, it is safe to leave it as is since is not stripped at all and I can set up the original make install. BTW: I uploaded the improved package right now if you want to take a look at: http://web.ticino.com/gfwp/debian/peless-1.108/peless_1.108-1.dsc Feel free to tell me your opinion about it! cheers Giorgio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adoption of a package that doesn't need work (yet)
Hello, On 5/24/07, Don Armstrong [EMAIL PROTECTED] wrote: There's no reason to upload unless there's a change to the package needed OK, that's what I thought. That said, you should be subscribed to the PTS for the package, and should make an upload as soon as there is something to fix, even if it's minor. I fear it might take some time, since the BTS doesn't contain many entries. You probably should also occasionally email the ITA indicating that you're still going to adopt the package, and subscribe to the ITA bug as well, so you'll receive updates to the bug. Yes, I will definitely do that. Thanks, François
Re: RFS: peless -- dh_helper
-=| Paul Elliott, Fri, 25 May 2007 11:32:02 -0500 |=- OK, but first let me understand what I am fixing. What is wrong with make install as it is? There is also a make install-strip. I did not do anything special to create these targets; auto* tools created them. What exactly is wrong with make install? Thank you. As far as I understand, Giorgio's concerns were that a plain make install strips the debug information from the binaries installed. However, I can't confirm this: $ file debian/peless/usr/bin/peless debian/peless/usr/bin/peless: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.1, dynamically linked (uses shared libs), not stripped (this is after changing debian/rules to use make install and break right after it) So, Giorgio, it seems perfectly safe to use make install, no? -- damJabberID: [EMAIL PROTECTED] signature.asc Description: PGP signature
Re: RFS: peless -- dh_helper
-=| Giorgio Pioda, Fri, 25 May 2007 21:29:40 +0200 |=- http://web.ticino.com/gfwp/debian/peless-1.108/peless_1.108-1.dsc Ouch. It seems I've missed something in my previous review :/ In debian/copyright it is written that peless is under GPLv2-or-later and this is in COPYING as well. However, gmore.cc, peless.cc, internat.hh, search.cc and search.hh state something different in their headers. This is something that has to be sorted out with upstream author (Hi, Paul :) ) Ah, and while there, can I gen distribution-neutral location for the source tarball? Just a wish, but I hope it would not be a problem. The copyright year is also different. And something from before: * debian/rules still contains commented rows that are never going to be enabled. Why keep them there? -- damJabberID: [EMAIL PROTECTED] signature.asc Description: PGP signature
Re: Symbol-versioning a C++ library
* Bas Wijnen: This is slightly off-topic, for which I apologise. It's just that I learned about symbol versioning during my NM process, and nobody outside Debian seems to understand what it is. :-( *sigh* It's a bit sad that this is still being used in the NM process. I have a library, which I want to package for Debian. I felt it would be a good idea to use symbol versioning, since most of my programs (and in some cases other libraries) use it. The library is written in C++, which seems to be a slight problem. AFAIU the linker should be able to handle it, but I don't see how. Let's start with the problem in more detail: Before you do this, you should check if symbol versioning buys you anything in your case. If an application uses libA and libB which both depend on libC, but in two different versions libC1 and libC2, and you want to pass a libC-implemented object from libA to libB or vice versa, this still does not work. If libA and libB completely hide their dependency on libC, you won't run into such problems. And there's also problem which is rather C++-specific: When an object is created, the size of the object is typically compiled into the creator, unversioned. This means that unless the API is very carefully designed, you end up with non-versioned dependencies anyway. The poster child for symbol versioning, GNU libc, uses one source version to provide multiple, versioned entry points. This offers complete control over the interplay of versions, and works best for C code. Symbol versioning is no magic bullet that lets you escape DLL hell. In general, what saves us is the ability to recompile large parts of our software archive against new library versions, not symbol versioning. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: peless -- dh_helper
On Fri, May 25, 2007 at 10:55:11PM +0300, Damyan Ivanov wrote: -=| Giorgio Pioda, Fri, 25 May 2007 21:29:40 +0200 |=- http://web.ticino.com/gfwp/debian/peless-1.108/peless_1.108-1.dsc Ouch. It seems I've missed something in my previous review :/ In debian/copyright it is written that peless is under GPLv2-or-later and this is in COPYING as well. However, gmore.cc, peless.cc, internat.hh, search.cc and search.hh state something different in their headers. This is something that has to be sorted out with upstream author (Hi, Paul :) ) Ah, and while there, can I gen distribution-neutral location for the source tarball? Just a wish, but I hope it would not be a problem. The copyright year is also different. And something from before: * debian/rules still contains commented rows that are never going to be enabled. Why keep them there? -- damJabberID: [EMAIL PROTECTED] OK I will, be comming out with a new version, shortly which will have the following features. 1) .cc .h source code the same except for copyright messages 2) configure.ac and Makefile.am changed to use ax_boost_base.m4 instead of my home brew system. 3) copyright problems fixed, will say gplv2 or later. 4) remove obsolete spec files, but leaving the ones for current distros. I will probably make a release probably Sat or Sun. It will take this long because I still have to verify that the system still builds on Fedora, opensuse, mandrake and ubuntu 7.04. I still do not have a debian sid system for testing, but if ubuntu works other debian based systems will probably work possibly with minor changes. When all this is done I will put a new release on berlios and send you guys an email. -- Paul Elliott 1(512)837-1096 [EMAIL PROTECTED]PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117 pgpblHsep1qBJ.pgp Description: PGP signature
Re: Symbol-versioning a C++ library
On 2007-05-25, Florian Weimer [EMAIL PROTECTED] wrote: * Bas Wijnen: This is slightly off-topic, for which I apologise. It's just that I learned about symbol versioning during my NM process, and nobody outside Debian seems to understand what it is. :-( *sigh* It's a bit sad that this is still being used in the NM process. Why? I have just been thru that part about symbol versioning and -Bsymbolic. And it was indeed very hard to get right. And I did swear several times during my answering. I am - now - very glad that my AM actually took me thru those parts. I disliked it while it was going on, but I really learned a lot. I have not yet used that specific part of my knowledge about neither -Bsymbolic nor symbol versioning, but I have already ended up in using the stuff I learned on the way. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: peless -- dh_helper
On Fri, 25 May 2007 15:28:17 -0500 Paul Elliott [EMAIL PROTECTED] wrote: I will probably make a release probably Sat or Sun. It will take this long because I still have to verify that the system still builds on Fedora, opensuse, mandrake and ubuntu 7.04. I still do not have a debian sid system for testing, but if ubuntu works other debian based systems will probably work possibly with minor changes. That seems a lot of work for a single (small?) program. Personally, I wouldn't say it was worth it. I used to do all this multi-distro testing for my own upstream projects - I still have a laptop somewhere with FC5 on it for this reason. Guess what happened - yes, I wasted days and days on retests using distributions I rarely used myself only to find that the maintainers of the code for those distributions were ignoring my .spec files and using their own - and with FAR better results. Eventually, I learnt that it is all pointless. Upstream cannot be a packaging expert for all distributions and should not seek to become one. Even if you test on FC, OpenSuse, Mandriva, Ubuntu and Debian, does that help people who want to use gentoo or slackware? - let alone installations like fink or cygwin (or OpenEmbedded and Emdebian for that matter). All I do now is test on two *architectures*, not multiple distributions. I have an amd64 workstation and a powerpc laptop and as these are very dissimilar platforms, I test on each - yet both are running Debian unstable. (I do have i386 but those boxes are not usually powered up.) I have 7 upstream projects using autotools in this way. I also cross-build some packages for arm but that's just me, I'm not recommending that as a build test! Leave the distribution specific stuff to those who are specialists in that distribution (another reason why no upstream package should contain a debian directory). By all means make a test package for whatever is your preferred distribution but it is hardly ever worth packaging those - 99 times out of 100 the actual package will use a different spec file and there is nothing wrong with that. Upstream should be completely distribution-neutral, except in very unusual circumstances. You're using autotools! Make use of them. The only thing upstream ever needs to do, IMHO, with an autotools source build is ensure that the source code completes 'make distcheck' successfully before every release - that's it. It doesn't matter what distribution is used to run 'make distcheck' because it tries quite hard to be distro-agnostic. Then, if the package fails to build on FC or Debian or gentoo, the likelihood is that people very familiar with those distributions will be able to determine why 'make distcheck' works on one and not on theirs because the failure is likely to be something quite obvious due to the number of packages running 'make distcheck'. A package that completes 'make distcheck' will usually build correctly on Debian and elsewhere and will install the required files where Debian packaging tools would normally expect to find them without upstream needing to know anything about debhelper. Packages that fail 'make distcheck' will usually fail to build on most, if not all, other distributions. I usually try to ensure that every upstream package completes 'make distcheck' after each work session in CVS/SVN but it's not really necessary unless you are making any changes to configure.ac, any Makefile.am or adding or removing files from the build (like translations). Please don't reinvent the wheel. If you have sensible test programs setup to run via 'make check' and you are already running 'make distcheck' successfully, I'd recommend releasing immediately. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp9Npa6f6GCh.pgp Description: PGP signature
Re: Symbol-versioning a C++ library
On Fri, May 25, 2007 at 09:57:41PM +0200, Florian Weimer wrote: This is slightly off-topic, for which I apologise. It's just that I learned about symbol versioning during my NM process, and nobody outside Debian seems to understand what it is. :-( *sigh* It's a bit sad that this is still being used in the NM process. No, it's only sad that so many people maintain libraries without understanding the consequences of ABI changes. I have a library, which I want to package for Debian. I felt it would be a good idea to use symbol versioning, since most of my programs (and in some cases other libraries) use it. The library is written in C++, which seems to be a slight problem. AFAIU the linker should be able to handle it, but I don't see how. Let's start with the problem in more detail: Before you do this, you should check if symbol versioning buys you anything in your case. If an application uses libA and libB which both depend on libC, but in two different versions libC1 and libC2, and you want to pass a libC-implemented object from libA to libB or vice versa, this still does not work. If libA and libB completely hide their dependency on libC, you won't run into such problems. In my experience, exposing objects in APIs like this remains an exception rather than a rule. Regardless, using symbol versioning still limits the problem to cases where objects are being passed around between multiple versions of a library *and* the definition of that particular object has changed. Without symbol versioning, loading multiple versions of a library frequently leads to segfaults in library *internals*, regardless of whether the library has a clean API. And there's also problem which is rather C++-specific: When an object is created, the size of the object is typically compiled into the creator, unversioned. This means that unless the API is very carefully designed, you end up with non-versioned dependencies anyway. True. But again, this only shows that symbol versioning is not a panacea -- not that it isn't worth doing. The poster child for symbol versioning, GNU libc, uses one source version to provide multiple, versioned entry points. This offers complete control over the interplay of versions, and works best for C code. Symbol versioning is no magic bullet that lets you escape DLL hell. In general, what saves us is the ability to recompile large parts of our software archive against new library versions, not symbol versioning. In addition to the special case of glibc, symbol versioning (of one sort or another) has been used for the following libraries to good effect where it was not practical to just recompile everything against new library versions; in many of these cases, the impetus for symbol versioning originated with Debian: BDB cyrus-sasl libkrb5 (MIT and Heimdal) libpng gnutls openssl wxwidgets For *any* library with other libraries as reverse-dependencies, where the maintainer has considered shipping two upstream versions of the lib in parallel, unless it's *known* that the API is not safe under symbol versioning, using symbol versioning should be the default policy. Even if only packages linking against the new version of the lib pick up the symbol versioning, it can still make a *huge* difference in the quality of the user's experience. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Handling of configuration files not shipped with a newer package version
Hi, The docbook-xml package 4.4 shipped a really old version 3.1.7, that was dropped with package version 4.5. The package itself ships a configuration file for every released version: [..] /etc /etc/sgml /etc/sgml/docbook-xml /etc/sgml/docbook-xml/3.1.7 /etc/sgml/docbook-xml/3.1.7/dbgenent.ent [..] Now what is the best/recommended way to handle the removal of the 3.1.7 version? A normal upgrade tries to remove the directory /etc/sgml/docbook-xml/3.1.7, which is impossible, because /etc/sgml/docbook-xml/3.1.7/dbgenent.ent still exists. Although dpkg still knows, that the file belongs to docbook-xml, purging docbook-xml will not purge all configuration directories anymore: dpkg - warning: while removing docbook-xml, directory `/etc/xml' not empty so not removed. dpkg - warning: while removing docbook-xml, directory `/etc/sgml/docbook-xml' not empty so not removed. dpkg - warning: while removing docbook-xml, directory `/etc/sgml' not empty so not removed. because it doesn't try to remove /etc/sgml/docbook-xml/3.1.7 anymore. How is such a situation handled best? I guess, I must add at least some code to postrm to make sure these directories are removed too, if /etc/sgml/docbook-xml/3.1.7 still exists. But should I try to remove this obsolete directory already during upgrade? Should I ask the user via debconf? Then I could avoid the need of the postrm-removal of still existing directories. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Symbol-versioning a C++ library
On Thu, May 24, 2007 at 05:03:42PM +0200, Bas Wijnen wrote:
I have a library, which I want to package for Debian. I felt it would
be a good idea to use symbol versioning, since most of my programs (and
in some cases other libraries) use it. The library is written in C++,
which seems to be a slight problem. AFAIU the linker should be able to
handle it, but I don't see how.
I am very interested in this topic as well, as a package I maintain,
scim, is also written in C++ and suffers from un-versioned symbol
collisions (bug #323216).
Then I tried to give the whole shevek::fd class a different version by
adding:
SHEVEK_2 {
global:
shevek::fd::*;
};
(and some variations.) That didn't work at all: it defines the version:
gDO *ABS* SHEVEK_2SHEVEK_2
But no symbol actually uses it.
Steve already said it's not possible to use un-mangled names, and he
definitely knows much more than I do. But I have a piece of information
you may be interested.
The upstream author of scim worked for SUSE, and had to solve the save
symbol collision problem. So he played with versioned symbols and had
the following snippet in the version script in the upstream source (the
src/libscim.version-script file in scim source package):
LIBSCIM_1.0 {
global:
extern C++ {
*scim::*;
};
local:
*;
};
So what is new is the 'extern C++ { ... }' part. The upstream author
said it solved the symbol collision in some cases, but not every case.
This versioned symbol configuration is disabled by default in the
upstream releases, and Debian doesn't use it, so I have no idea how well
it works. But you may want to give it a try and see.
Ming
2007.05.25
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Handling of configuration files not shipped with a newer package version
On Sat, May 26, 2007 at 04:08:32AM +0200, Daniel Leidert wrote: Hi, The docbook-xml package 4.4 shipped a really old version 3.1.7, that was dropped with package version 4.5. The package itself ships a configuration file for every released version: [ Note: Is it a conffile. ] [..] /etc /etc/sgml /etc/sgml/docbook-xml /etc/sgml/docbook-xml/3.1.7 /etc/sgml/docbook-xml/3.1.7/dbgenent.ent [..] Now what is the best/recommended way to handle the removal of the 3.1.7 version? A normal upgrade tries to remove the directory /etc/sgml/docbook-xml/3.1.7, which is impossible, because /etc/sgml/docbook-xml/3.1.7/dbgenent.ent still exists. Although dpkg still knows, that the file belongs to docbook-xml You can check the page that used to be at dpkg.org regarding removal of an obsolete conffile. Basically you check: [ -e $f ] dpkg --compare-version [ `md5sum $f |sed -e 's/ .*//` = $oldmd5 ] rm -iv $f or such. http://wiki.debian.org/DpkgConffileHandling , purging docbook-xml will not purge all configuration directories anymore: dpkg - warning: while removing docbook-xml, directory `/etc/xml' not empty so not removed. I think this should work with etch dpkg? because it doesn't try to remove /etc/sgml/docbook-xml/3.1.7 anymore. How is such a situation handled best? I guess, I must add at least some code to postrm to make sure these directories are removed too, if /etc/sgml/docbook-xml/3.1.7 still exists. But should I try to remove this obsolete directory already during upgrade? Conditional on the above .. conditions, yes. Should I ask the user via debconf? This would be considered an overuse of debconf. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
