Bug#1006009: fixed in libwebp 1.2.2-1

Yes, I made a mistake with respect to 1.2.2. Upstream's official patch is here. I am going to attempt a high urgency upload during the next houw with 1.2.2 + this patch. If that fails for any reason, NMU welcome without delay.

Bug#949638: tesseract: uses -march=native

BCC: Stefan Weil since I don't know if he wants his email posted in bugs.debian.org Regarding: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949638 Thank you, Peter. 1. The URL for the patch is 404. 2. There may be some subtlety with -march=native, specifically related to detection of

Bug#895761: jhove: FTBFS with java 9

I think the right thing is to update to the latest jhove release (1.20) but looks like the build system has changed dramatically. Would love to get a little help from someone who works with Java packages on a more regular basis.

Bug#895761: jhove: FTBFS with java 9

Taking a look

Bug#890548: Stack buffer overflows

This is just about strings, right? So something like this will fix the problem and resolve this bug? Or am I missing something? char buf[L_BUF_SIZE]; - fscanf(fp, "Rootname: %s\n", buf); + fscanf(fp, "Rootname: %L_BUF_SIZE_MINUS_ONEs%\n", buf);

Bug#889610: tesseract-ocr-srp-latn: uninstallable in sid: Depends: tesseract-srp (>= 3.99) which is unknown

Thanks will fix ASAP. On Sun, Feb 4, 2018 at 3:08 PM, Andreas Beckmann wrote: > Package: tesseract-ocr-srp-latn > Version: 4.00~git15-45ed289-5 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your

Bug#884967: opencv: FTBFS on various architectures

I've just uploaded a fix attempt for bug 884903 with Tesseract 4.00~git2188-cdc35338-2. I think it will fix this problem.

Bug#884903: libtesseract-dev: headers broken: missing std::; headers missing

We'll get this fixed upstream, and in the meantime I'll try patch enough into the Debian package to get the dependencies to build. For gimagereader, that's a single string -> std::string

Bug#884903: libtesseract-dev: headers broken: missing std::; headers missing

Taking a look.

Bug#857385: jablicator: should it be removed from the archive?

If you know who to ask and are willing, I appreciate it. Otherwise, I'll figure it out eventually.

Bug#857385: jablicator: should it be removed from the archive?

Yes, I concur. I also checked with upstream (myself) and he agrees too. On Fri, Mar 10, 2017 at 9:28 AM, Mattia Rizzolo wrote: > Source: jablicator > Version: 1.0.1 > Severity: serious > > Dear maintainer, > > The package doesn't seem to have much popularity these days, with

Bug#845749: libwebp FTBFS on armhf: inlining failed in call to always_inline 'vtrnq_s32': target specific option mismatch

Ubuntu may have the patch for this. If so, okay to NMU. https://patches.ubuntu.com/libw/libwebp/libwebp_0.5.1-2ubuntu1.patch

Bug#816857: gimagereader: fails to launch with "symbol lookup error"

IRC people tell me that a transition bug will fix everything. There is an existing transition bug #815919.

Bug#816857: gimagereader: fails to launch with "symbol lookup error"

jbreiden: Just report a transition bug for release.debian.org to +transition back So they rebuild the stuff against the old ABI again

Bug#816857: gimagereader: fails to launch with "symbol lookup error"

Thanks for working with me and sorry about the trouble. I don't know what you mean by not closing bug #815056 properly. The bug tracker says it is closed. https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=tesseract If I look at the package tracking system, it seems to be claiming

Bug#816857: gimagereader: fails to launch with "symbol lookup error"

It must be mad that there is no libtesseract4 anymore. I'm going to try to get help for that on IRC.

Bug#816638: mhonarc: fails to run with perl5.22

Yikes. I wasn't expecting this for mhonarc 2.6.19. Patches from a perl programmer appreciated. Will also check with upstream.

Bug#816857: gimagereader: fails to launch with "symbol lookup error"

I'm in over my head, so I asked for help. The folks on debian-devel IRC channel advised me to not bump soname and instead attempt an ABI repair. It was supposed to be harmless to gimagereader. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815056 I'm really not sure what to do at this point.

Bug#815056: libtesseract4: fails to upgrade from libtesseract3

> There was an accidental ABI breakage a while ago > And I thought that bumping to libtesseract4 was the right thing to do ... The important question is: How did this ABI break happen? Upstream change or only an effect of the C++ transition? > I had been assuming upstream change > But actually

Bug#815056: libtesseract4: fails to upgrade from libtesseract3

Why? I was asked strongly by a Debian Developer in 794489 to bump the libtesseract version. I suspect 742027 was related. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794489 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742027 I historically have a lot of trouble with transitions, and

Bug#796179: tesseract-ocr: tesseract fails to generate output

I'd like to think if this were widespread, I'd be hearing about it from multiple sources. So any sort of confirmation (or refutation) from others is appreciated.

Bug#796179: tesseract-ocr: tesseract fails to generate output

That's unexpected. Can you please tell me if you also have trouble with English using the attached image? tesseract phototest.tif -

Bug#794489: Re: Bug#795219: nmu: gimagereader_3.1-1

could you please comment on Juliens mail? Do you plan to do the proposed changes? Depends how many packages are affected. Transitions are a bunch of work, and I think we are also in some special situation due to the GCC transition. So if it is just one binMNU then I think that might be the way to

Bug#794489: Re: Bug#795219: nmu: gimagereader_3.1-1

Using apt-rdepends -r libtesseract3, I think the affected packages are gimagereader and libsikuli-script-jni.

Bug#794489: gimagereader fails to open

Sounds right to me. My bad.

Bug#792659: tesseract-ocr-dev: fails to install, trying to overwrite other packages files: /usr/share/tesseract-ocr/language-specific.sh

Thanks, I'll investigate today.

Bug#785000: libwebp: FTBFS on mips: Error: opcode not supported on this processor: mips2...

Sorry, I was under the impression upsteam had integrated the patch. NMU acceptable, or I can do it when I find time.

Bug#783693: libwebp: no symbols; loose shlibs dependency

Thank you for the investigation, and please NMU. I'm not literally underwater right now, but I'm also not that far off from it.

Bug#736036: upgrading to serious: libtiff4-dev is being removed

Thanks for escalating, I will attempt fix well before autoremoval deadline. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#742027: tesseract-ocr: tesseract doesn't start

Package: tesseract-ocr Version: 3.03.02-3 I can't reproduce this. Please run ldd and md5sum on /usr/bin/tesseract and report the results. === $ curl http://ftp.us.debian.org/debian/pool/main/t/tesseract/tesseract-ocr_3.03.02-3_i386.deb foo.deb $ ar x foo.deb $ tar xJvf data.tar.xz $ ldd

Bug#742027: tesseract-ocr: tesseract doesn't start

Package: tesseract-ocr Version: 3.03.02-3 This is unexpected. The build dependency is on libleptonica-dev (= 1.70~) which is leptonlib4. I don't see how or where a leptonlib3 could be sneaking in.

Bug#737481: tesseract: undefined symbol: _Z16tprintf_internalPKcz

Thank you for the problem report. I will adjust the dependency.

Bug#664176: libleptonica: package name doesn't vary with soname

Leptonica upload commencing now. Tesseract coming. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#664176: libleptonica: package name doesn't vary with soname

Tesseract uploading now. We'll see how this goes. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#664176: libleptonica: package name doesn't vary with soname

Just for background information, Leptonica has a big hulking API, something on the order of a thousand calls. Upstream is constantly making tweaks around the periphery, often just adding more stuff. In retrospect, it was possibly a mistake for upstream to bump the soname up to 3 in one of the

Bug#664176: libleptonica: package name doesn't vary with soname

I am also okay with you doing an NMU on Leptonica/Tesseract. Note that Jakub Wilk was fantastically helpful during the great Tesseract renaming a few months ago, although I probably drove him crazy in the process. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a

Bug#664176: libleptonica: package name doesn't vary with soname

Yes, I can sponsor. My goal is to not get in the way of your energy, but also be careful to keep the level of chaos under control. The inclusion of Leptonica and Tesseract must not be jeopardized. Jakub, you are welcome to weigh in on this bug if you wish. -- To UNSUBSCRIBE, email to

Bug#632240: pylucene status

Dmitry, Pylucene is an incredibly useful package. The very best thing is for me to no longer be involved as a maintainer for pylucene. But in the short term, if you want or need me to sponsor an upload, I can do so as early as tomorrow. Let me know.

Bug#632240: pylucene status

You can package a modern pylucene and take over as the maintainer. Nothing would make me happier. On Apr 20, 2012 6:21 AM, Dmitry Nezhevenko d...@dion.org.ua wrote: Hi, I'm looking to pylucene package that I need as a dependency for other pkg. Unfortunately currently it still depends on

Bug#664176: libleptonica: package name doesn't vary with soname

This report is valid. Having gone through a package rename with Tesseract, I am a little bit scared to tackle this - it took me a half dozen attempts to get it right. Fortunately, users are not be suffering - bug #664175 was addressed through another mechanism. Bottom line, it may take some

Bug#658476: libtesseract3: undeclared file conflict with tesseract-ocr

Doing this Package: libtesseract3 Breaks: tesseract-ocr ( 3.01~) Replaces: tesseract-ocr ( 3.01~) ... Because of this 7.6.1 Overwriting files in other packages It is usually an error for a package to contain files which are on the system in another package. However, if the

Bug#658095: tesseract-ocr-eng: breaks tesseract-ocr ( 3) and ocropus (without actually declaring Breaks)

Very sorry, did not mean to close this bug prematurely. [tesseract-ocr-eng] does break ocropus directly (too?). ocropus is statically linked to Tesseract libraries. If ocropus is depending on tesseract-ocr-eng, shoudn't the ocropus package declare a dependency? Are you sure the right fix isn't

Bug#658095: tesseract-ocr-eng: breaks tesseract-ocr ( 3) and ocropus (without actually declaring Breaks)

I double checked - lintian doesn't complain. Ocropus unsurprising fails to build from source in its current state. $ apt-get source -b ocropus checking for err_exit in -ltesseract_full... no configure: error: Could not find tesseract! Choose --without-tesseract if you do not want to use it.

Bug#658095: tesseract-ocr-eng: breaks tesseract-ocr ( 3) and ocropus (without actually declaring Breaks)

Bug report is slightly mistaken. Ocropus does not depend on tesseract-eng. Tesseract-eng broke the older tesseract-ocr, and then tesseract-ocr broke ocropus. Fundamentally, new language data doesn't work with older binaries. I'll try this in the language packs: Breaks: tesseract-ocr (  

Bug#649786: thanks!

Julien, thanks for the education, Mehdi, thanks for the NMU. Luk thanks for being helpful. And yes, I ... oddly enough ... knew about the SONAME bump in libwebp. I'll see what I can improve during my next Leptonica upload, maybe at end of year or early January. NMUs are always welcome for my

Bug#607693: mhonarc: cross-site scripting when converting HTML mails

After extensive discussion, upstream is preparing a new release of mhonarc (the security and related bug fixes are more extensive than the patch supplied to Debian). I prefer to ship the new release as the security update, rather than attempt a backport. Happy to discuss if security team has any

Bug#607693: mhonarc: cross-site scripting when converting HTML mails

Based on discussion with Earl so far, I think the correct fix is disabling HTML mail support by default.

Bug#497131: [jcc] Please add ${python:Depends} to Depends field

Thanks! NMU uploads are fine, or I'll get to this when I can. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#496332: [pylucene] still FTBFS

Thanks! NMU uploads are fine, or I'll get to this when I can. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)

What library is that? libjvm.so Specifically /usr/lib/jvm/java-6-openjdk/jre/lib/i386/client/libjvm.so As found here: http://packages.debian.org/sid/i386/openjdk-6-jre-headless/filelist I'm surprised you got PyLucene to build; I wonder if it runs (there is a simple test in the PyLucene

Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)

Sounds good to me. Will apply and upload your patch today. Thanks for the hard work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)

Uploaded. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)

Peter, Thank you very much for the patch. It is almost right. Open JDK 1.6 has this really weird setup where one of the shared libraries is under the server subdirectory on AMD64 and under the client subdirectory under i386. (Not sure what the story is on other architectures). The PyLucene

Bug#488895:

But that said, openjdk entered Debian now (yay!). Good. Lucene2 can be moved to main with a build-depends on OpenJDK. Who's got the energy to do it? :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#488895: please move to main

When we went through this for Lucene 1.4.3, the trick was to compile under main, and then make sure the regression tests passed if Sun Java was installed. That way we knew the package was ok to ship and the problems were all in the runtime. But seriously, what's the ETA for Sun Java to enter

Bug#424471:

Rmic has apparently drifted in and out of kaffe/GNU classpath over time. I say we just wait for GPL Sun Java and fix it then. Or punt the Lucene package for Lucene2 if dependencies allow it, and Lucene2 gets into main (again, depending on GPL Sun Java) -- To UNSUBSCRIBE, email to [EMAIL

Bug#400109: Can we downgrade severity to important on #400109?

This bug does not have a major effect on the usability of the package so I am therefore resetting severity to normal. It will not be ignored. After the Sun JDK enters main (post etch), we will rebuild the package with it. Hopefully that will resolve the intermittent build failure. Jeff -- To

Bug#400109: lucene: FTBFS: random, different build failures

While trying to autobuild lucene, I ran into several different failures. Over 16 builds, it failed 3 times and timeouted once. And succeeded 12 times? Sounds good enough to me. Let's leave this alone until etch is released, then can look into switching to a Sun JDK build (once the Sun JDK gets

Bug#388535: Patch for NMU 1.4.3.dfsg-1.2

Thank you, Thijs! --Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#380136: lucene: FTBFS: can not find stubs for class: class org.apache.lucene.search.RemoteSearchable

It took forever and a day to get RMI support in kaffe - looks like other java environments are still lagging. --Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#359862: oops

Testing now on my pbuilder chroot. Worked, but I could not get the deb out. On the other hand, pdebuild failed for me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#359862: lucene: FTBFS: Tries to use jikes without Build-Depends

No need to test. Daniel is right. We'll revise the package. --Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#359862: oops

I now see the compiler is overridden to jikes. I'm going to switch that to javac so we can hopefully happily build on both sid and etch. Testing now on my pbuilder chroot. -Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#359862: lucene: FTBFS: Tries to use jikes without Build-Depends

I temporarily do not have access to a suitable Debian build environment to reproduce; can someone please confirm the problem? On Wed, 29 Mar 2006 2:31 am, Daniel Schepler wrote: Package: lucene Version: 1.4.3-9 Severity: serious From my pbuilder build log: ... [javac] Compiling 160

Bug#312014: acknowledged by developer (Re: Bug#312014: fop missing dependencies.)

Look at the package java-package On 6/5/05, Mohammed Sameer [EMAIL PROTECTED] wrote: On Sat, Jun 04, 2005 at 03:03:14PM -0700, Debian Bug Tracking System wrote: Hi, * Mohammed Sameer ([EMAIL PROTECTED]) [050604 23:08]: Package: fop Severity: grave apt-get install fop

Bug#300209: tomcat4: tomcat dies with Parse error in default web.xml after upgrade

Hi Sarge release team, The java packing team just got blindsided by bug #300209, which appears to have knocked tomcat4 out of Sarge. Heads up that you may hear some begging for re-inclusion in the near future. Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe.

Bug#300780: Swatting a very visible bug - # 300780

Now that I think about it, lucene-demo-1.4.3.jar has some very useful programs. It's arguably in a better place now than before. How about we leave it in the liblucene-java package, and follow the reporter's suggestion? It seems like this should simply require the appropriate versioned