Bug#598616: cuneiform: development package is needed

2010-09-30 Thread Dmitry Katsubo 
Package: cuneiform
Version: 0.7.0+dfsg.1-1
Severity: wishlist

It would be nice to have also a development package for this project
(e.g. cuneiform-dev) that includes:

- Static library(-ies) (*.a)
- Necessary headers (*.h)

Thanks in advance!



-- 
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ca48c9c.1060...@mail.ru

Bug#598616: cuneiform: development package is needed

2010-10-01 Thread Dmitry Katsubo 
On 30.09.2010 21:14, Jakub Wilk wrote:
> Fixing this bug is non-trivial and I don't currently have time to work
> on it. However, I will be happy to accept a patch if you provide one.

As it uses cmake, it is not trivial for me.
At least one can include  which is installed.

I have fired a request at cuneiform bugtracker:
https://bugs.launchpad.net/cuneiform-linux/+bug/652883

I hope .a will be available as well (usually it is not a big deal).



-- 
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ca5bc30.8010...@mail.ru

Bug#598616: cuneiform: development package is needed

2010-10-02 Thread Dmitry Katsubo 
Jakub Wilk wrote on 01.10.2010 13:11:
> Why do you need a static library in the first place?

There is an intention to reduce the number of 3-rd party dependencies
(e.g. use static linking is possible) to:
* make the results of recognition robust to changes in these libraries,
so the results are reproducible and predictable
* target Win32 platform, where it is easier to have one executable (no
dll hell)



-- 
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ca725fa.60...@mail.ru

Bug#598616: cuneiform: development package is needed

2011-01-21 Thread Dmitry Katsubo 
Version: 1.0.0+dfsg-1

I attach the trivial solution for the bug: the library header
cuneiform.h is packaged as libcuneiform-dev.deb

Please consider for inclusion.

Perhaps it also makes sense to split "cuneiform" package into
"cuneiform" (binary only) and "libcuneiform" (.so only) and update the
dependencies.
diff -du -ruN debian.orig/control debian/control
--- debian.orig/control 2010-09-10 16:34:51.0 +0200
+++ debian/control  2011-01-21 11:13:21.0 +0100
@@ -33,3 +33,19 @@
  Swedish, Turkish and Ukrainian.
  .
  This package contains the common files.
+
+Package: libcuneiform-dev
+Architecture: any
+Section: libdevel
+Depends: ${misc:Depends}, cuneiform
+Description: multi-language OCR system (headers)
+ Cuneiform is an OCR system. In addition to text recognition it also does 
layout
+ analysis and text format recognition.
+ . 
+ The following languages are supported: Bulgarian, Croatian, Czech, Danish,
+ Dutch, English, Estonian, French, German, Hungarian, Italian, Latvian,
+ Lithuanian, Polish, Portuguese, Romanian, Russian, Serbian, Slovak, Spanish,
+ Swedish, Turkish and Ukrainian.
+ .
+ This package contains the development header files.
+
diff -du -ruN debian.orig/libcuneiform-dev.install 
debian/libcuneiform-dev.install
--- debian.orig/libcuneiform-dev.install1970-01-01 01:00:00.0 
+0100
+++ debian/libcuneiform-dev.install 2011-01-21 10:56:38.0 +0100
@@ -0,0 +1 @@
+/usr/include/cuneiform.h

Bug#774164: libocrad-dev: libocrad.a contains non-reallocatable code

2016-12-16 Thread Dmitry Katsubo 
On 2016-12-16 10:16, Alexander Alemayhu wrote:
> On Thu, Dec 15, 2016 at 09:42:08PM +0100, Petter Reinholdtsen wrote:
>>
>> Personally I use tesseract these days for my OCR work, and do not need ocrad.
> 
> I have unfortunately stopped using ocrad in favour of proprietary
> solutions.
> 
> Thanks for adding me to the recipient list, but I don't have the
> motivation to help here.
> 
> Added Jakub Wilk to copy, IIRC he made the package.

I see from the build log [1] that the build policy for .a had changed... I think
that is for good. Relocatable code makes object a bit bigger, but on current
systems that does not matter at all. Briefly:

1. One solution would be to make .a code reallocatable, so that .so library
that refers libocrad.a can compile.

2. Another solution is to provide libocrad.so within libocrad package.

[1] 
https://ci.debian.net/data/packages/unstable/amd64/o/ocrad/20161215_073147.autopkgtest.log.gz

-- 
With best regards,
Dmitry

Bug#647053: Reverse dependencies of virtual package not handled correctly

2019-04-14 Thread Dmitry Katsubo 
I've hit the same problem when listing dependencies for package tomcat8, which 
depends on tomcat8-common, which depends on "default-jre-headless | 
java8-runtime-headless | java8-runtime,
libtomcat8-java" but java8-runtime-headless is not shown:

# apt-rdepends --state-follow=Installed --state-show=Installed tomcat8

tomcat8
  Depends: tomcat8-common (>= 8.5.38-2)
...
tomcat8-common
  Depends: libtomcat8-java (>= 8.5.38-2)


# apt-cache showpkg java8-runtime-headless
...
Reverse Provides:
openjdk-8-jre-headless 8u212-b01-1~deb9u1 (= )
openjdk-11-jre-headless 11.0.3+1-1~bpo9+1 (= )
openjdk-8-jre-headless 8u181-b13-2~deb9u1 (= )
default-jre-headless 2:1.8-58 (= )
openjdk-11-jre-headless 11.0.3+1-1 (= )
default-jre-headless 2:1.11-71 (= )

-- 
With best regards,
Dmitry