Bug#557495: Force sub-directories for both

2010-12-08 Thread Neil Williams
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

2010-12-08 Thread Andreas Tille
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

2010-12-07 Thread Neil Williams
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

2010-12-07 Thread Andreas Tille
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

2010-12-07 Thread Neil Williams
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

2010-12-07 Thread Andreas Tille
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