The current version of leptonica (1.74.1) available on portage is from January, 2016. There have been newer versions up through 1.74.4. Particularly, I have noticed a PR on github for tesseract: https://github.com/tesseract-ocr/tesseract/pull/1014 where it detailed that version 1.74.2 was no longer available on leptonica's main site. 1.74.4 is the newest version, and the latest available on portage is 1.74.1. Reproducible: Always Steps to Reproduce: N/A Package not in portage. Actual Results: Versions of media-libs/leptonica are not available past 1.74.1 Expected Results: I would like to see an option for ** (unstable) builds if possible. It'd be great if portage could manage packages I manage myself. Apologies if I filed this incorrectly. I attempted to Google around for the link that told me (somewhere on Gentoo's most recent wiki) to file package update requests on Gentoo's bug tracker. If this is the wrong place, could you tell me where I should go instead? My go-to is to just install the package from source, which is what I've done. I started using Gentoo fairly recently, specifically because I was managing building _many_ packages from source myself. I was so happy to see an OS (and package manager!) that not only defaulted to building packages from source, but to also be able to handle doing it all from git. Anyway, this is the first time I've unexpectedly found a package that doesn't have a ** to git. I have another system I use for testing (the latest -rc kernels, like 4.12-rc(x), and gcc version 8.0.0 (experimental) (GCC)) which I agree should not be in a package manager even as experimental since they are still in development, but it'd be nice to get leptonica updated. I've compiled 1.74.4 on my systems (all x86_64) with no problems. Also, would anyone be able to point me towards something for ebuilds that can help me with them? Source code is always best (unless it uses boost). I've read the top results for ebuilds, but all of them seem to be missing a lot? The 'most helpful' I've seen is: https://devmanual.gentoo.org/quickstart/ but it's still missing a lot. What'd be helpful is a link to source or good documentation. Good documentation happens almost never, but if there's source somewhere, I can maybe read it? I haven't been able to quickly find anything, after a short period of time googling, and I figure it's probably a good time to see if someone has something. If you do, please link! It feels weird to submit one of these for something that I've already solved for my system and systems like it (I just built it from source?) but it'd be cool to see where the info for the ebuilds are located. My last job used to have someone who taught me a lot about things with Gentoo, and was happy to make an ebuild if I made a patch for a package, but I never learned how to do that part myself, and he left... I'd also be able to then just submit updates to ebuilds and the like once I know what options available and the like.
Justin, please use our support channels, to discuss things [4] I do not fully understand your very long report. The situation seems to be a bit more complicate and requires some analysis. We can not help you efficiently via bug tracker. The bug tracker aims rather on specific problems in .ebuilds and less on individual systems. I have had very good experience on the gentoo IRC [1] with questions like this. Of course there are also forums and mailing lists [2,3]. If you see my nick on IRC, you may ask me on #gentoo, everyone else can help you too. I hope you understand, that I will close the bug here therefore and wish you good luck on one of the mentioned channels [4]. Please reopen the ticket in order to provide an indication for an error in the ebuild [5]. [1] https://www.gentoo.org/get-involved/irc-channels/ [2] https://forums.gentoo.org/ [3] https://www.gentoo.org/get-involved/mailing-lists/all-lists.html [4] https://www.gentoo.org/support/ [5] https://wiki.gentoo.org/wiki/Bugzilla/Bug_report_guide
Yes, a poke on IRC or email would have been preferable to a bug report. I'm quite easy to get hold of. Please also stick to the point. I was surprised to learn of these new releases as upstream has had me personally review every earlier release going back several years. These minor releases are a new thing and now that development is on GitHub and no longer behind closed doors, I guess Dan didn't feel the need to contact me about these ones. I gave 1.74.4 a try but two of the tests fail. baseline_reg does not declare its dependency on gnuplot and I have filed a pull request about this. pngio_reg is also failing in some 32-bit cases, possibly on recent GCC versions but I'm not sure yet. I have filed a bug report about that too. I found that the test even fails on 1.74.1 where it passed before, making GCC a likely culprit, but I will still refrain from bumping the package. It is likely that users on recent GCC versions still have Leptonica built against an older GCC so bumping would make the situation worse. Live ebuilds (e.g. git) are actually not that common and are generally only provided where they are considered a real benefit. Leptonica doesn't change that much and I have always bumped it quickly in the past. I will keep a closer eye out for those minor releases now.
And the current SRC_URI points to upstream "downloads" but those packages are incomplete, ie, 1.7.4.1 was replaced with 1.7.4.4 source tarball, however, all available versions/tags are available via github/blah/leptonica/archive/$PV.tar.gz So either change the SRC_URI to pull from github or update the ebuild to keep up with upstream changes/deletions/updates on the main domain's download site. Personally I prefer the former to chasing disappearing source tarballs. Note that 1.7.4.1 is currently broken if you don't already have the source.
Also note I wasn't suggesting a live ebuild, just a github SRC_URI using the upstream tagged source tarballs.
1.74.4 is now in the tree. The issue I had earlier was a bug in GCC 7.1. It seems to be fixed in 7.2.
