Accepted apertium 3.5.1-1 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 26 Mar 2018 16:07:23 +0200 Source: apertium Binary: apertium libapertium3-3.5-1 apertium-dev apertium-all-dev Architecture: source all amd64 Version: 3.5.1-1 Distribution: unstable Urgency: low Maintainer: Debian Science Team <debian-science-maintainers@lists.alioth.debian.org> Changed-By: Tino Didriksen <t...@didriksen.cc> Description: apertium - Shallow-transfer machine translation engine apertium-all-dev - Metapackage for all tools required for Apertium development apertium-dev - Development tools and library for Apertium libapertium3-3.5-1 - Shared library for Apertium Closes: 886361 Changes: apertium (3.5.1-1) unstable; urgency=low . * Update to latest upstream (Closes: #886361) Checksums-Sha1: 95dab9db524f8db9cd3037efe4dc9813027a4040 2376 apertium_3.5.1-1.dsc 1858bcb06bfbfa0d346ec9a4bb957610778e95d1 327522 apertium_3.5.1.orig.tar.bz2 dd6e9a41462c2c24907f17f98d2de26290271f41 6376 apertium_3.5.1-1.debian.tar.xz 93800ba692699255263c8a21bc2a2a62c2a203dc 5880 apertium-all-dev_3.5.1-1_all.deb c4538f016b0cd6c25a83df84953566ebb7bb6e65 3615156 apertium-dbgsym_3.5.1-1_amd64.deb a03869e1a4223c13a1946d92987ae66fe89518d8 366360 apertium-dev-dbgsym_3.5.1-1_amd64.deb 54111490343e78bc29446bfcc99d0d29677da93b 77056 apertium-dev_3.5.1-1_amd64.deb 170e469078d5f2a0059ea8e97415cc7a12835bcb 8148 apertium_3.5.1-1_amd64.buildinfo 7b4856873b48822b671fd9c0203295aecf49ed19 305696 apertium_3.5.1-1_amd64.deb c49d1ebffc947e6a0388e3f9cf8c7b57cb871326 7030216 libapertium3-3.5-1-dbgsym_3.5.1-1_amd64.deb dbaab95c6ec924ccf7d2e10efcf6681c0ea35e1c 386884 libapertium3-3.5-1_3.5.1-1_amd64.deb Checksums-Sha256: 19eb6e8c23fa58408f4c8446753f67a8c704e17c8f2e996f68f27b5bea9e6810 2376 apertium_3.5.1-1.dsc beca316b0ffa1b8b9606d5c3504bba8dbc95a070533ddb837a20e7699ea42450 327522 apertium_3.5.1.orig.tar.bz2 456f16f7b42bdf2fc8a20d5182384a8eb26a118429c7e932839f0c6abb87a926 6376 apertium_3.5.1-1.debian.tar.xz ce046377c977fd1431e02c39f9736d49fe049fa64e97c7ebd840d366a9c24bcf 5880 apertium-all-dev_3.5.1-1_all.deb 00796c61640ab87da2ac57894e07b5cfaca7760031ff7f8b22e4f1e1057a 3615156 apertium-dbgsym_3.5.1-1_amd64.deb 576ddd9b484accb3705cf298fdd795c2020a64d69e5641dcc1552705ac062117 366360 apertium-dev-dbgsym_3.5.1-1_amd64.deb 28b03f5c2c331464c31ce27db435d34c25fb4517251ccc29bb4d06a039815e0a 77056 apertium-dev_3.5.1-1_amd64.deb 6d880c1b2cee8b39e6ef89530462baabb0e2b5c2cfd80306042bf3909ab9028c 8148 apertium_3.5.1-1_amd64.buildinfo 389d980b3b541bfb62a101acca31553e2e8275eb9c227dd4f7cdd1825ec72099 305696 apertium_3.5.1-1_amd64.deb 4fc4929c1339b772e793dd51c9c4b95ce995e80a5d8691db8aafc2fc0a759976 7030216 libapertium3-3.5-1-dbgsym_3.5.1-1_amd64.deb 920cb2f17710870a9f5b4f4ae8ac7649120daf695a84ef546d70a8810839e73d 386884 libapertium3-3.5-1_3.5.1-1_amd64.deb Files: 1ce6a528c8b642bde6291a806676f32d 2376 science optional apertium_3.5.1-1.dsc c27f6ac9ace67bab2da2ca04e96ac9ae 327522 science optional apertium_3.5.1.orig.tar.bz2 4219788653f064b328144b46fb8129da 6376 science optional apertium_3.5.1-1.debian.tar.xz 935e82bae387bf216f4dcd26b9af6b77 5880 science optional apertium-all-dev_3.5.1-1_all.deb 2571bf71dfe57fc04303b038583b6be7 3615156 debug optional apertium-dbgsym_3.5.1-1_amd64.deb b164268ee3c5cb7ba1cca8f382952a7f 366360 debug optional apertium-dev-dbgsym_3.5.1-1_amd64.deb a497d408d23e04caeded628e46bf5801 77056 science optional apertium-dev_3.5.1-1_amd64.deb 904c94d2f2fff744d6e4bcaa597ad547 8148 science optional apertium_3.5.1-1_amd64.buildinfo bbff272050e6f9bb2cb4a0a175dac71c 305696 science optional apertium_3.5.1-1_amd64.deb b7c36aa13249e9696b8bcd5253dfd926 7030216 debug optional libapertium3-3.5-1-dbgsym_3.5.1-1_amd64.deb c06aae1e103f878743c283e89bfe82f3 386884 libs optional libapertium3-3.5-1_3.5.1-1_amd64.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEa2MbXvVUr2sRlmKSAsHT8ng6pN4FAlq5IOwACgkQAsHT8ng6 pN7ZcBAArG1eDYOLbIPa6bP0MpWyk8MuChxLnepFR3cmEY/GGtvnX3N7b+W1acTj uA5KWPEeO1/mp45bGKN9X3enIN4O5yHGdwEk2+rQiuWQPNCCUGo79uCmOpZMk2jd SRkJ3gUdg2yNgOMWAZQcUEK1ogTNnonTf8awscE6HI56InMNg0KmQH1GsOTsSp41 Jxq9FKren2BCoKuX3hRrUSxInL4E9S1n959aVaVWdsHN2FSiE92RhsZhBHvAGQh6 4nNcaC5pkrZBH/qAHIa7I7Kv1DYMPbZ9Dk3SVCxSCVw67pCxPaqsKje7HA09uWqI IRd3/UdUvuVJatMUo5U+IIw6TbESf7jA3MqF2prFXbPktHEGqqQ8UBrZLiwJQ0RE stj8d2ihfFHoOWXFjMAa0FHH0l8ciw4dEcU7OBa/3ILUc5YR3JZjvJ7kHHSvamvf Jp8qYfwSFn4mw1v/L8tvtQapiklqMTlkj86NQgyEP+CPA0dasspAHI6EAK17KSHQ T9+bAaSZHZz4BihzPziRFfAC5wBqdrKc1hrhAtQT7DKpQ4E9S0SVSGzPUVqM3TPy yYsk9LELBizued/QxnruSIc6WfNj52zOV+EboK0AVCbeqOCpb1PuziH4A20u7yqb tSrV54vI/QMLMrHY12z23MEYL8DMQG/oL6OQZF60xQsrN/04ymw= =VcQC -END PGP SIGNATURE- -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#893092: apertium-spa-ita: apertium ita-spa: lrx-proc: not found
2018-03-16 13:50 GMT+01:00 Daniel Kahn Gillmor <d...@fifthhorseman.net>: > 1 dkg@alice:~$ apertium ita-spa << /usr/share/apertium/modes/ita-spa.mode: 3: > /usr/share/apertium/modes/ita-spa.mode: > lrx-proc: not found > > > perhaps there is some missing dependency? Yup, missing dependency on apertium-lex-tools. Will fix. -- Tino Didriksen -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#893075: liblttoolbox3-3.3-0v5 must be dropped since it now depends on the wrong soversion
This will fix itself when apertium is updated, which is next. Just needed lttoolbox through first. -- Tino Didriksen On 16 March 2018 at 08:21, Adrian Bunk <b...@debian.org> wrote: > $ apertium-preprocess-transfer > apertium-preprocess-transfer: error while loading shared libraries: > liblttoolbox3-3.3.so.0: cannot open shared object file: No such file or > directory -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#874563: apertium-all-dev: please switch dependency from libhfst45-dev to libhfst-dev (or libhfst49-dev)
On 7 September 2017 at 12:29, Andreas Beckmann <a...@debian.org> wrote: > src:hfst does no longer build libhfst45-dev, but there is libhfst49-dev > now. Please consider whether you can just depend on the virtual > libhfst-dev package provided by libhfst49-dev, that should ease future > upgrades by not requiring any further changes in apertium-all-dev. I've pushed a tiny fix for this (Kartik, could you upload?). And I agree the explicit 49 is annoying, but virtual packages can't have version requirements which is even more annoying. I have a plan for splitting HFST further by adding a hfst-dev package, which I'll do for next major HFST release. -- Tino Didriksen -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#873008: hfst FTBFS on big endian: FAIL: test
On 7 September 2017 at 03:15, Paul Wise <p...@debian.org> wrote: > Why do the tests for hfst need to be disabled? > > I think it would be better to keep them enabled so that we can ensure > that hfst works correctly. Broken binaries are worse than FTBFS. You > can ask for removal of the existing binaries from the architectures > where the FTBFS happens by using `reportbug ftp.debian.org`. The binaries are not broken, though. It's one out of a hundred tests that fails. It's more that some of the file formats are not endian-neutral (e.g. OpenFST). For the purpose of working with HFST locally and exchanging the neutral files, it works fine. -- Tino Didriksen -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#873008: hfst FTBFS on big endian: FAIL: test
That's my bad. In the confusion of bugs #824119 and #827199 , I forgot to re-disable tests for hfst. -- Tino Didriksen On 23 August 2017 at 18:38, Adrian Bunk <b...@debian.org> wrote: > Source: hfst > Version: 3.12.2~r3289-1 > Severity: serious > > https://buildd.debian.org/status/package.php?p=hfst=sid > -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#869825: hfst-ospell FTCBFS: fails running tests despite DEB_BUILD_OPTIONS=nocheck
On 26 July 2017 at 21:45, Helmut Grohne <hel...@subdivi.de> wrote: > hfst-ospell fails to cross build from source. It runs the test suite > despite being asked not to do so (DEB_BUILD_OPTIONS=nocheck) and fails > doing so (as host architecture code fails to execute). After honouring > that flag, it cross builds successfully. Please consider applying the > attached patch. Patch applied - just needs uploading. I wish this wasn't necessary. I don't see any good reason that each package needs to separately honor nocheck, but a central solution was discussed and rejected in https://bugs.debian.org/568897 -- Tino Didriksen -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#865029: apertium-spa-cat FTBFS: No rule to make target '/usr/share/apertium/apertium-cat/cat_valencia.autogen.bin'
At least I know exactly why. Versioned releases that weren't checked against existing packages. We're looking at it upstream: https://sourceforge.net/p/apertium/mailman/apertium-stuff/thread/CABnmVq6kba5DjbFL8Kt9U_NFPrdZdO0-WVrLo6KSMdsgHkVrig%40mail.gmail.com/ -- Tino Didriksen On 18 June 2017 at 21:29, Adrian Bunk <b...@debian.org> wrote: > Something recently broke the build of apertium-spa-cat: > > https://tests.reproducible-builds.org/debian/history/apertium-spa-cat.html > https://tests.reproducible-builds.org/debian/rb-pkg/ > unstable/amd64/apertium-spa-cat.html > > make[1]: *** No rule to make target > '/usr/share/apertium/apertium-cat/cat_valencia.autogen.bin', > needed by 'spa-cat_valencia.autogen.bin'. Stop. > -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#859032: hfst-ospell: Incomplete debian/copyright?
On 29 March 2017 at 19:43, Chris Lamb <la...@debian.org> wrote: > I just ACCEPTed hfst-ospell from NEW but noticed it was missing > attribution in debian/copyright for at least: > > office.cc:4: Copyright 2015 Tino Didriksen <m...@tinodidriksen.com> > > (This is not exhaustive so please check over the entire package > carefully and address these on your next upload.) As the author of both office.cc and debian/*, I'd say it's fine. I mostly put myself in office.cc so people would know who to direct bug reports to, but the file is copyright-assigned to the HFST project, as the first line says. I did however miss attribution for a file in m4/ - will fix for next time. -- Tino Didriksen -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#827199: hfst: FTBFS: twolc test fails on big-endian systems
On 13 June 2016 at 18:00, Aaron M. Ucko <a...@alum.mit.edu> wrote: > Justification: fails to build from source (but built successfully in the > past) > > Thanks for taking care of the twolc errors I reported in #826659. The > twolc test now succeeds on little-endian systems, and no longer hangs > anywhere, but still fails on big-endian architectures (mips, powerpc, > s390x, and several non-release architectures). I don't have further > details, but perhaps you can reproduce the problem on a porterbox. > Could you please take a look? Can reproduce. Looking into it upstream: https://github.com/hfst/hfst/issues/328 While it did successfully build in the past, that was only because the test suite was disabled until recently. The tests revealed the unsigned char issue which was easy to fix, and now the endian issue which will not be as easy. -- Tino Didriksen -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#791195: fixed in lttoolbox 3.3.2~r61000-3.1
On 3 February 2016 at 02:57, Andreas Beckmann <a...@debian.org> wrote: > On Thu, 20 Aug 2015 16:00:44 + Julien Cristau <jcris...@debian.org> > wrote: > > lttoolbox (3.3.2~r61000-3.1) unstable; urgency=medium > > . > >* Non-maintainer upload. > >* Rename library packages for g++5 ABI transition (closes: 791195). > > This change was recently reverted and I'm not convinced that this was a > good idea. That was my doing, on the basis that the transition should never have happened. Because I wasn't properly subscribed to this bug (due to using my mail@ address which procmail can't handle), I never knew the transition was pushed through against my wishes, until I went to update lttoolbox to a newer release. There are only 2 other packages that depend on lttoolbox: apertium and apertium-lex-tools, and I maintain those as well. All 3 are part of the same upstream project, and are updated together if there are breaking changes. And because lttoolbox 3.3 was not even in testing at the time, nothing outside my control could have built up dependencies on it, and indeed nothing has. The v5 transition was entirely unnecessary for this package, and I very strongly want it gone. -- Tino Didriksen -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#791195: lttoolbox: library transition may be needed when GCC 5 is the default
On 3 July 2015 at 15:12, Matthias Klose d...@debian.org wrote: - Decide if the symbols matching __cxx11 or B5cxx11 are part of the library API, and are used by the reverse dependencies of the library. - If there are no reverse dependencies, it should be the package maintainers decision if a transition is needed. However this might break software which is not in the Debian archive, and built against these packages. No transition is needed, and as upstream I would really prefer no transition is forced. The symbols are part of the public API, but the only reverse dependencies are apertium and apertium-lex-tools which are part of the same software suite and almost always updated together. Besides, the packages are new in unstable, so no other dependencies could have built up in previous releases. -- Tino Didriksen -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#791195: lttoolbox: library transition may be needed when GCC 5 is the default
On 11 August 2015 at 21:22, Julien Cristau jcris...@debian.org wrote: On Tue, Aug 11, 2015 at 09:38:30 +0200, Tino Didriksen wrote: No transition is needed, and as upstream I would really prefer no transition is forced. As upstream why does the binary package name for the library matter to you? Good point. I am also one of the package maintainers/uploaders, in addition to being upstream developer. We keep the various distro packaging scripts in our own repo and sync them to Debian as needed. I prefer having the same package names across all distros, barring wider policies (e.g. -dev vs -devel). Adding a v5 for just one platform would complicate our scripts and setup instructions. -- Tino Didriksen -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Apertium language pairs
Replied inline... Original Message Data: 2014-12-27 22:19 Remitent: Riley Baird bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch I've noticed that Debian has individual packages for each of the apertium language pairs. However, many of the language pairs have not yet been packaged for Debian. All released pairs have been packaged for Debian Experimental, and are making their way through the various pipes. The pairs in Stable are so old they're not really usable. Would it make more sense to have something like an apertium-data package that contains all of the language pairs from upstream? It seems like it would be easier to maintain, and would ensure that all of the languages are present. That would be considerably harder to maintain from my point of view. Right now, Apertium has an automated nightly build service ( http://apertium.projectjj.com/apt/ ) with all usable single language packages and all language pairs. I use the same scripts that power that service to make the stable Debian packages. In either case, for any new pair release, the work would be the same: Update changelog, run the update script, git-import-dsc, git push, notify uploader. But for the end user, a single apertium-data would mean they'd have to download many times more data than they actually want. What we could do is make a metapackage apertium-data that depends on all languages and pairs. That'd accomplish the same, but be more manageable...I'll put that on ToDo. If you want newer Apertium packages, either wait for the Debian process, or use our nightly service. -- Tino Didriksen -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
