Bug#557495: Force sub-directories for both
On Wed, 8 Dec 2010 08:46:40 +0100 Andreas Tille ti...@debian.org wrote: Consequently libctapimkt0-dev was removed from testing (since a long time) and this is correct for this package. A wishlist for a common interface doesn't seem to me to be sufficient to stop the library getting into Squeeze - it is usable alone. An apropriate thing to do would have been to reassign bug #557495 only against libctapimkt0-dev which would enable libtowitoko-dev to stay in testing (because there is no chance to install both packages together in testing any more). Any reason why this had not already been done? It is possible to install both in unstable and that problem alone isn't sufficient, IMHO, to prevent both going into Squeeze. It was just a hint, no detail, no proof or way for others to test. This bug isn't enough to prevent either package being in Squeeze - The package libctapimkt0-dev is *not* in Squeeze! Feel free to cancel the delayed upload. However, from your description I still don't see why it should not be in Squeeze. I have not expected that people will spend their time on fixing bugs in packages which are not in Squeeze. The bug was filed against both packages without resolution. I could have just fixed one side of it but as the fix was trivial fro both, it seemed to make sense to do it for both. You could have saved your time if you would have pinged me about your intend. Equally if the bug report had been cloned / commented / updated with more than the content I've been able to see so far, I would have just done one side of it. At this stage of the freeze, RC bug reports which have been open as long as this one are worth fixing. It seems such a trivial reason to have to remove the package from Squeeze. You have spended time to clean up a package with very low popcon which is not intended for Squeeze. Actually, I've spent more time discussing the lack of content in the replies to the original bug report than in preparing the upload. This is brave and I welcome your work but at least for me there are currently more burning issues to do. If you want me to discuss the issue further instead of trusting me that I'm in contact with upstream and will handle things with upstream *after* the Squeeze release I prefer removing the package for now and adding it later again. OK - it's in delayed, so feel free to cancel it. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpbSu5hNgXNJ.pgp Description: PGP signature
Bug#606265: Bug#557495: Force sub-directories for both
On Wed, Dec 08, 2010 at 09:08:02AM +, Neil Williams wrote: Feel free to cancel the delayed upload. I do not see a reason to make your work on this really wasted. However, from your description I still don't see why it should not be in Squeeze. Because it is not in Squeeze any more and we are in deep freeze. I have not expected that people will spend their time on fixing bugs in packages which are not in Squeeze. The bug was filed against both packages without resolution. I could have just fixed one side of it but as the fix was trivial fro both, it seemed to make sense to do it for both. Originally I agreed with Simon Richter that both packages will use ctapi-dev. I had only ctapimkt in mind and communication with upstream was slow. I'm sorry for beeing not more verbose in the bug log. You could have saved your time if you would have pinged me about your intend. Equally if the bug report had been cloned / commented / updated with more than the content I've been able to see so far, I would have just done one side of it. I'm sorry for this and confirm that the issue was not apropriately handled by me. The fact that the package has currently quite low priority is no real excuse. Actually, I've spent more time discussing the lack of content in the replies to the original bug report than in preparing the upload. So please lets stop wasting more time and leave it as it is for the moment. OK - it's in delayed, so feel free to cancel it. Thanks for your work Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557495: Force sub-directories for both
clone 557495 -1 reassign 557495 towitoko found 557495 2.0.7-8.1 reassign -1 libctapimkt found -1 1.0.1-1 quit As no other solution has actually been uploaded, I propose that the two packages involved should both be changed to use sub-directories just like the one other library containing the relevant file. Hence, splitting this bug report into two to allow two uploads. It's fairly trivial to adapt relevant code to use a subdirectory, with surrounding #ifdef where appropriate. As with other situations where there's no agreed solution for two packages, I propose that both be changed: -rw-r--r-- root/root 2022 2010-12-07 21:32 ./usr/include/towitoko/ctapi.h -rw-r--r-- root/root 5347 2010-12-07 21:32 ./usr/include/towitoko/ctbcs.h changelog |8 libtowitoko-dev.install |2 +- 2 files changed, 9 insertions(+), 1 deletion(-) -rw-r--r-- root/root 2217 2008-04-03 21:55 ./usr/include/ctapimkt/ctapi.h -rw-r--r-- root/root 1905 2010-12-07 21:38 ./usr/include/ctapimkt/config.h debian/libctapimkt0-dev.dirs |1 + libctapimkt-1.0.1/debian/changelog |8 libctapimkt-1.0.1/debian/rules |2 +- 3 files changed, 10 insertions(+), 1 deletion(-) I'll make the upload to delayed/2 tonight. (This bug has been hanging around without a resolution for long enough.) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpoFRgxF1fGj.pgp Description: PGP signature
Bug#557495: Force sub-directories for both
Hi Neil, thanks for your effort in solving this. On Tue, Dec 07, 2010 at 09:44:17PM +, Neil Williams wrote: As no other solution has actually been uploaded, I propose that the two packages involved should both be changed to use sub-directories just like the one other library containing the relevant file. Hence, splitting this bug report into two to allow two uploads. It's fairly trivial to adapt relevant code to use a subdirectory, with surrounding #ifdef where appropriate. ... I'll make the upload to delayed/2 tonight. (This bug has been hanging around without a resolution for long enough.) Probably you missed my remark when I deleted the pending tag [1]. While in principle no real harm is done by your solution it would have been IMHO perfectly correct to not fix the bug until both projects really issued a reasonable common header file which would be technically the best solution. The fact that there is now a workaround seems to decrease the presure onto this clean solution. I wonder whether you simply was hunting for open bugs or whether you really need one of those libraries. If it would be libctapimkt I hope you did not missed my hint that there are other issues which bring the package into a state which makes it unfit for release. Kind regards Andreas. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=81;bug=557495 -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557495: Force sub-directories for both
On Tue, 7 Dec 2010 23:47:47 +0100 Andreas Tille ti...@debian.org wrote: Hi Neil, thanks for your effort in solving this. On Tue, Dec 07, 2010 at 09:44:17PM +, Neil Williams wrote: As no other solution has actually been uploaded, I propose that the two packages involved should both be changed to use sub-directories just like the one other library containing the relevant file. Hence, splitting this bug report into two to allow two uploads. It's fairly trivial to adapt relevant code to use a subdirectory, with surrounding #ifdef where appropriate. ... I'll make the upload to delayed/2 tonight. (This bug has been hanging around without a resolution for long enough.) Probably you missed my remark when I deleted the pending tag [1]. No, I saw that. The two files *are* different, albeit still similar, hence every reason to have *both* files in different locations. There isn't necessarily a need for a common interface within the packages - just as long as any code including these headers can uniquely identify the *right* header consistently and reproducibly. While in principle no real harm is done by your solution it would have been IMHO perfectly correct to not fix the bug until both projects really issued a reasonable common header file which would be technically the best solution. Really? If the files are different but can be used in similar ways that argues for separation, not integration IMHO. The fact that there is now a workaround seems to decrease the presure onto this clean solution. I'm not at all sure why the solution has to be in one or other library as if code including the header (none of which is in Debian currently) cannot be trivially modified with an #ifdef or two. I wonder whether you simply was hunting for open bugs or whether you really need one of those libraries. If it would be libctapimkt I hope you did not missed my hint that there are other issues which bring the package into a state which makes it unfit for release. It was just a hint, no detail, no proof or way for others to test. This bug isn't enough to prevent either package being in Squeeze - if there are other issues, please file appropriate bugs and give people a chance to verify and possibly fix. If you believe this to be the case, please file the appropriate RM bug with the reasoning. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpPIZQ0argdl.pgp Description: PGP signature
Bug#557495: Force sub-directories for both
On Tue, Dec 07, 2010 at 11:12:23PM +, Neil Williams wrote: The fact that there is now a workaround seems to decrease the presure onto this clean solution. I'm not at all sure why the solution has to be in one or other library as if code including the header (none of which is in Debian currently) cannot be trivially modified with an #ifdef or two. Both libraries are interfacing with a Card Terminal (CT) and we have a package in Debian which intends to provide this API (ctapi-dev). This package was created to fix the bug in question you simply worked around now. We just have another package libopenct1-dev which provides another ctapi.h file and which probably has the same purpose to provide a CT interface. The package *I* have dealt with (libctapimkt0-dev) has such a low priority that I would rather remove it from Debian than allowing to add even more confusion and I agreed with upstream to find a better solution than providing its own interface. Upstream agreed, to this in principle but there were other issues which were not (yet) solved and thus I removed the pending tag because it is not clear how long it might take. Consequently libctapimkt0-dev was removed from testing (since a long time) and this is correct for this package. An apropriate thing to do would have been to reassign bug #557495 only against libctapimkt0-dev which would enable libtowitoko-dev to stay in testing (because there is no chance to install both packages together in testing any more). It was just a hint, no detail, no proof or way for others to test. This bug isn't enough to prevent either package being in Squeeze - The package libctapimkt0-dev is *not* in Squeeze! if there are other issues, please file appropriate bugs and give people a chance to verify and possibly fix. If you believe this to be the case, please file the appropriate RM bug with the reasoning. I have not expected that people will spend their time on fixing bugs in packages which are not in Squeeze. You could have saved your time if you would have pinged me about your intend. You have spended time to clean up a package with very low popcon which is not intended for Squeeze. This is brave and I welcome your work but at least for me there are currently more burning issues to do. If you want me to discuss the issue further instead of trusting me that I'm in contact with upstream and will handle things with upstream *after* the Squeeze release I prefer removing the package for now and adding it later again. This would keep ftpmaster busy for two times which I also feel unapropriate. Kind regards and thanks for your work in any case Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org