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#1003548: transition: libwebp

libwebp 1.2.1-7 has been successfully uploaded to unstable. Anthony and Iustin, help is very strongly appreciated for the NMUs.

Bug#1003548: transition: libwebp

# remove the moreinfo tag tags 1003548 - moreinfo thanks Sebastian, may we move forward with ibwebp?

Bug#1003548: transition: libwebp

To make it super clear, here is the updated formal request with updated Ben file. === Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello Release Team, We would like to transition libwebp to a new upstream version 1.2.1-6

Bug#1003548: transition: libwebp

The package has been corrected with version 1.2.1-6 which has been uploaded to experimental. Please let us know if we can proceed with the upload to unstable. Also a binNMU rebuild of reverse dependencies would be required afterwards.

Bug#914315: libwebp-dev: New versions fix disclosed heap use-after-free

Maintainer is "less active" but still in good contact with upstream. I was going to package the latest version several months ago, but there was a soname bump and transitions were not allowed due to Debian's release cycle. Happy to work with anyone on updating webp.

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#942062: liblept5: Please add Multi-Arch support

leptonica-progs also?

Bug#913951: tesseract-ocr: Legacy engine not directly usable because of missing files

Hi Janusz, Tesseract 4 uses tesseract-ocr-deu and tesseract-ocr-script-frak. Tesseract 3 uses tesseract-ocr-deu-frak I am worried about confusing users. If we include both sets of language data in Debian, there will a huge number of choices, and some users might feel overwhelmed. However,

Bug#904433: tesseract-ocr: please mark as Multi-Arch: foreign

> tesseract-ocr package provides arch-independent service (cli) The command line interface (cli) application 'tesseract' in the tesseract-ocr package is written in C++. It is not architecture independent. Therefore I don't think it should be marked as Multi-Arch: foreign.

Bug#898439: leptonlib: CVE-2018-7442

Believed fixed in Debian package 1.76.0-1 Status of various vulnerabilities, as per upstream: * CVE-2018-7442: potential injection attack because '/' is allowed in gplot rootdir. Functions using this command have been disabled by default in the

Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

Tesseract in Debian just added a build time smoke test AND Stefan fixed the big-endian problem. Should be live tomorrow in Sid. Assuming that works well, Graham should be able to re-activate the disabled OCRMyPDF tests. Note that this is Debian only; Ubuntu 18.04 is out the door so no longer

Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

Given the date, it sounds like we have an emergency situation. I'm really stuck here. My only known access to a big endian is an emulator with Wheezy. http://create.stephan-brumme.com/big-endian/ That's good enough for checking suspicious parts of Leptonica. I tried and found nothing. But

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#895864: leptonlib: needs config.guess/sub update for riscv64

Okay, uploading now. Thanks for all the help! On Mon, Apr 23, 2018 at 4:06 PM, Manuel A. Fernandez Montecelo < manuel.montez...@gmail.com> wrote: > 2018-04-23 23:22 GMT+02:00 Manuel A. Fernandez Montecelo > : > > > > This additionally runs the tests, > > can be

Bug#895864: leptonlib: needs config.guess/sub update for riscv64

Is it sufficient to put Build-Depends: debhelper (>= 11.0.0) in debian/control and 11 in debian/compat ?

Bug#895761: jhove: FTBFS with java 9

Taking a look

Bug#885704: liblept5 negatively plays with paths in /tmp when opening TIFFs

It is possible that older versions are not vulnerable. $ sudo apt-get install leptonica-progs $ TMPDIR=/var/tmp fileinfo /tmp/foo.jpg Error in fopenReadStream: file not found Error in pixReadHeader: image file not found Error in writeImageFileInfo: failure to read header of /tmp/foo.jpg $

Bug#885704: liblept5 negatively plays with paths in /tmp when opening TIFFs

This is the patch I used for Leptonica 1.74. It should work fine for earlier versions. Upstream used a different approach for addressing the problem in version 1.75. do-not-mess-with-paths.diff.gz Description: GNU Zip compressed data

Bug#849094: emulator

I've been running a PowerPC emulator to track down a different bug. Not so hard. But it is not fast. Anything specific (and small) that we want to test for this bug? http://create.stephan-brumme.com/big-endian/

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#889590: tesseract-ocr-aze has circular Depends on tesseract-ocr-aze-cyrl

Hi Bill, Thanks for the bug report. This is a little tricky, because if you only install one of the Azerbaijan language packages, the user will see error messages. I guess we just don't have a mechanism in Debian for "if you install one, you need the other as well". That's unfortunate because it

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#886594: RM: tesseract- -- ROM obsolete source packages

Package: ftp.debian.org Severity: normal We have completed a major consolidation of Tesseract packaging with the 4.0 release. Previously I used a separate source package for each language. Now a single source package provides everything. Please retain the following source packages: tesseract

Bug#885704: liblept5 negatively plays with paths in /tmp when opening TIFFs

Most likely we'll have a fix into Debian within 48 hours.

Bug#885704: liblept5 negatively plays with paths in /tmp when opening TIFFs

I've reproduced by setting TMPDIR to /var/tmp. Talking to Leptonica author.

Bug#885704: liblept5 negatively plays with paths in /tmp when opening TIFFs

Peter, what do you have set for TMPDIR environment variable? (You can check this with "env")

Bug#885704: liblept5 negatively plays with paths in /tmp when opening TIFFs

I cannot reproduce this problem on Debian Unstable. We have a mystery. $ tesseract /tmp/ANY/PATH/phototest.tif - - Page 1 This is a lot of 12 point text to test the ocr code and see if it works on all types of file format. The quick brown dog jumped over the lazy fox. The quick brown dog jumped

Bug#885704: liblept5 negatively plays with paths in /tmp when opening TIFFs

Will investigate.

Bug#884504: transition: gdal

Attempted fix for Tesseract fix uploaded just now.

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#882279: RM: tesseract-ocr-dev -- ROM Transitional package no longer needed

Package: ftp.debian.org Severity: normal https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878986

Bug#881859: Updating the libwebp Uploaders list

okay.

Bug#878986: please drop transitional package tesseract-ocr-dev

Sure, I can do that. In a related question, do you have any idea how move tesseract-lang from NEW to Experimental? It has been languising there since August 23.

Bug#862305: transition: libwebp

Beginning transition. Uploaded to unstable.

Bug#862305: transition: libwebp

>Do the packages in https://release.debian.org/transitions/html/auto-libwebp.html >build fine against the new libwebpmux ? There was a bug the libwep control file. I fixed that and uploaded 0.6.0-2 to experimental just now. Then I did some testing on AMD64 to answer your question. Everything on

Bug#862305: transition: libwebp

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition This is a clean ABI bump. I've updated the symbols file appropriately. New package has been uploaded to experimental. Please be aware that the primary binary library package (libwebp6)

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#848178: gimagereader fails to start

What action do people want for this bug beyond the ABI repair in 3.04.01-3?

Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

Sorry, I wasn't aware of the guest account thing. Probably my fault for not reading email carefully enough. I am a Debian Developer and will sponsor this request. Fill out the information "Information guest needs to supply to sponsoring DD" and I will sign it.

Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

I've just uploaded 1.74.1-1 to Debian, which contains something similar to Sean's patch.

Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

Tesseract 4 is known to not work on big endian. Stefan (on CC) is excited to take a look if someone can give him access to a big endian machine. There are no known endian problems with Tesseract 3 or Leptonica, but if any are definitively found they will get immediate attention. I am not going

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#844098: mhonarc: should use libmagic instead of hardcoded magic MIME types

Mhonarc development is not particularly active, and I'm hesitant to mess with this. On Sat, Nov 12, 2016 at 5:04 AM, rpnpif wrote: > Package: mhonarc > Version: 2.6.19-1 > Severity: wishlist > > Dear Maintainer, > > The MIME types are hardcoded in mhmimetypes.pl. > A link with

Bug#842714: libwebp: CVE-2016-9085: several integer overflows

Working with upstream on this.

Bug#832805: transition: libwebp

Okay, clearly not webp. Sorry for the noise. Makefile:1711: recipe for target 'lua/intf/cli.luac' failed

Bug#832805: transition: libwebp

Bas> and vlc FTBFS on mips* before the libwebp NMUs. Emilio> That needs to be looked at. Do I understand correctly that the FTBFS is unrelated to webp?

Bug#832805: transition: libwebp

webp 0.5.1 is now in unstable, will see if anything explodes

Bug#832805: transition: libwebp

I have build-tested the reverse dependencies against the new libwebp version.

Bug#832805: transition: libwebp

>Have you build-tested the reverse dependencies against the new libwebp version? I've build tested a bunch of them successfully, and the rest are still running.

Bug#832805: transition: libwebp

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition This is a new upstream release and includes a soname bump on all three shared libraries. I've only expressed the primary one in the Ben file; please update as appropraite. Note that

Bug#830660: liblept5: hardcoded predictable paths in /tmp

Thanks. Of course review in conjunction with upstream will do greps and code searches and stuff like that. But it always possible to miss something so reports are appreciated. For the files you mentioned: src/utils.c: will get serious attention in conjunction with upstream src/xtractprotos.c:

Bug#830660: liblept5: hardcoded predictable paths in /tmp

No, I'm not sure. Leptonica is big and requires a thorough review in conjunction with upstream. Thank you for helping identify convertTiffMultipageToPS(), and please report anything else you happen to notice on mainline paths. Highly appreciated.

Bug#830660: liblept5: hardcoded predictable paths in /tmp

I am removing the following programs from the leptonica-progs package due to hardcoded predictable paths in /tmp. Between this and the earlier patch, this solves all reported problems and therefore this particular bug will be closed. There are additional hardcoded paths in the Leptonica library

Bug#830660: liblept5: hardcoded predictable paths in /tmp

I will work with upstream on a permanent improvement. In the meantime, I'm adding a small patch in 1.73-3 that will help with the specific problem being discussed in de.comp.os.unix.linux.misc.

Bug#830660: liblept5: hardcoded predictable paths in /tmp

Acknowledged and taking action.

Bug#768132: Deprecation warnings with perl 5.12+

Believed fixed with 2.6.19-2.

Bug#815919: nmu: tesseract_3.04.01-3 openalpr_2.2.3-1 gimagereader_3.1.2+git368fa8f-1 sikuli_1.0~x~rc3.tesseract3-dfsg1-12

retitle 815919 nmu: tesseract_3.04.01-4 openalpr_2.2.3-1 gimagereader_3.1.2+git368fa8f-2 sikuli_1.0~x~rc3.tesseract3-dfsg1-12 thanks There are some good reasons to do this sooner rather than later.

Bug#817075: transition: tesseract

Subject: transition: tesseract-ocr Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal As described in bug #815056, there was a packaging mistake that led to the brief existance of libtesseract4. This problem has been corrected and we

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#815919: nmu: tesseract_3.04.01-3 openalpr_2.2.3-1 gimagereader_3.1.2+git368fa8f-1 sikuli_1.0~x~rc3.tesseract3-dfsg1-12

I've been advised on Debian Devel IRC mainly by juliank to stick to libtesseract3 and not do libtesseract3a. See bug 815056. Personally, I am in over my head but the IRC folks sound confident that this is the right course of action. P.S. Tersseract 3.04.01-4 has a breaks/replace against the ill

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#815860: libtesseract-dev: conflict with libtesseract4 3.04.01-2+b1

3.04.01-2 was a messy mistake that was live for relatively short time. So far, I've been advised by experts to ignore this particular problem. See bug 815056 for details. Sorry for the trouble.

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#764301: Please provide a backport for Wheezy

Time to admit it, I'm never going to do this. Not opposed to someone else making an attempt. Note that the next webp release is going to break ABI compatibility.

Bug#791300: tesseract: library transition may be needed when GCC 5 is the default

Tesseact does need a soname bump as per bug #794489 irrespective of GCC 5. I haven't done it, partly due to lack of time, and partly because one of the comments in that bug was demotivating.

Bug#805653: liblept4: Wrong file mode in call of fmemopen

Unless this is an emergency, let's wait for the next Leptonica point release rather than patching into the Debian package. Upstream has been notified.

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

I should have bumped the soname with the 3.04 release, this is further evidence of that. Will see if upstream has another point release ready soon, and if so I might combine. Note that I've done the Tesseract packaging for the last couple of years, so this problem (and any others) is entirely my

Bug#517904: tesseract-deu: provide source data

The authoritative Debian bug for this is #699609 and I would merge them if it was just a bit easier to do so. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699609

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#699609: tesseract-ocr: please provide source for language files

More progress. Training scripts now ship with 'tesseract-ocr' package, with some Debian specific instructions in README.debian. We'll probably be in this state for quite a while.

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#705502: tesseract: Individual language packages should depend on tesseract-ocr

careful, these three languages can't have this or we get a circular dependency tesseract-ocr-eng tesseract-ocr-osd tesseract-ocr-equ

Bug#779477: tesseract-ocr: Lines are lost, when tesseract destination is pdf

That's weird. Just to make my life a little easier, can you also attach non-PDF output, and specifically identify one of the lines that was eaten by PDF?

Bug#699609: tesseract-ocr: please provide source for language files

Making some progress; they are on github in the 'langdata' repository. Much packaging work still required, particularly around tesstrain.sh

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#779243: numpy should use OpenBLAS, making it up to 150x faster

Package: python-numpy Version: 1:1.8.2-2 (This problem report was written by Yaroslav Bulatov. I've confirmed it on Debian sid chroot. My computer gave a 30X improvement.) Default numpy install uses inferior BLAS, and is very slow. Matrix multiplication benchmark below gets me 1.26 G

Bug#767462: libwebp: please raise the priority to optional

Sounds good to me. It is amazing how quickly webp has established itself. As always, zero delay NMU for uncontroversial changes are fine with me. Otherwise I will do this when I have a chance.

Bug#764301: Please provide a backport for Wheezy

I don't know how to do a backport. I guess I could build a wheezy package with pbuilder, but no idea what I'd do with it next. Are backports usually done by the package maintainer, or someone else?

Bug#762675: leptonlib: Build leptonlib against openjpeg 2.1

This is terrific, NMU is acceptable without any delay. However, please confirm that the resulting Leptonica package actually has a dependency on libopenjpeg! I mention this because configure.ac in Leptonica upstream mentions libopenjp2 and I think that still needs to be libopenjpeg. So we may

Bug#757785: libwebp FTBFS on arm64, internal compiler errors

Upstream says: GCC 4.9 strikes again. CFLAGS='-O2 -frename-registers' should do [the trick]. I'm generally comfortable with NMU high urgency situations like this one. I prefer to keep the optimizations if possible, because they are substantial. * NEON assembly additions: - ~25% faster

Bug#757785: libwebp FTBFS on arm64, internal compiler errors

I'm quite happy to have NMU, with no delay necessary. It especially makes sense since I'm not set up to test on ARM. Also, upstream has some ideas. I'll see if they are amenable to direct contact. PS. How the heck did webp become bootstrap critical?

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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#750632: (no subject)

Thanks. NMU is acceptable, otherwise I'll get to it as soon as I get a chance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749953: pkg-config file missing

Will add to next release (coming up over the next month or two) -- To UNSUBSCRIBE, email to debian-bugs-dist-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#742029: tesseract-ocr: Trainingtools missing in SID version (3.03.02-3)

Package: tesseract-ocr Version: 3.03.02-3 Problem confirmed, working on fix.

  1   2   3   >