Bug#1061954: frog: NMU diff for 64-bit time_t transition
Hi Joost, Lukas, On second thought, I read https://wiki.debian.org/ReleaseGoals/64bit-time and checked the updated Frog sources, there is no time_t exposed at all anymore in the new version I'm packaging. So if I understand things correctly, the new libfrog3 library does not need the t64 transition and I can revert https://salsa.debian.org/science-team/frog/-/commit/2bbda8d92d40b96a216e8d8db972a9589f8df02f ? > Afaik the plan is to keep the binary packages named libt64 (reading > https://wiki.debian.org/ReleaseGoals/64bit-time ); this helps executing the > transition. I'll rebase so the libfrog2t64 patch is included, but it'll be immediately superseded by libfrog3. Regards, -- Maarten van Gompel (proycon) web: https://proycon.anaproy.nl gpg: 0x39FE11201A31555C signature.asc Description: PGP signature
Bug#1061954: frog: NMU diff for 64-bit time_t transition
Hi Lukas,
On Tue Jan 30, 2024 at 2:31 PM CET, Lukas Märdian wrote:
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> frog as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
>
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
>
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time. Therefore I have prepared a 0-day NMU for frog
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
>
> Please find the patch for this NMU attached.
>
> If you have any concerns about this patch, please reach out ASAP. Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.
Thanks for your patch. I am currently in the progress of upgrading these
packages to the new upstream sources after a long hiatus. This would
involve a library transition anyway (libfrog2 -> libfrog3). Is it
sufficient if I include 'Provides: ${t64:Provides}' for the new
libfrog3 package to accomodate this transition? I just did this in
commit 2bbda8d92d40b96a216e8d8db972a9589f8df02f:
https://salsa.debian.org/science-team/frog/-/commit/2bbda8d92d40b96a216e8d8db972a9589f8df02f
Perhaps that also removes the need for the oddly named frog2t64 package?
If not, I'll apply your patch and rebase my changes on top of it.
Regards,
--
Maarten van Gompel (proycon)
web: https://proycon.anaproy.nl
gpg: 0x39FE11201A31555C
signature.asc
Description: PGP signature
Bug#993123: frog FTCBFS: hard codes the build architecture pkg-config
Hi Helmut, On 21-08-27 04:23, Helmut Grohne wrote: > Source: frog > Version: 0.20-2 > Tags: patch upstream > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > > frog fails to cross build from source, because configure.ac hard codes > the build architecture pkg-config in one place (after correctly > detecting the host architecture one). Simply using the correct > substitution variable makes frog cross buildable. Please consider > applying the attached patch. > > Helmut Thanks for the patch! I have applied it upstream and will try to soon prepare a new debian release for Frog that includes it. Regards, -- Maarten van Gompel Digital Infrastructure Humanities Cluster Koninklijke Nederlandse Akademie van Wetenschappen (KNAW) proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x39FE11201A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:matrix.anaproy.nl Telegram: proycon IRC: proycon (libera.chat + oftc) Mastodon: https://social.anaproy.nl/@proycon (@proy...@social.anaproy.nl) Twitter:https://twitter.com/proycon ORCID: https://orcid.org/-0002-1046-0006
Bug#917700: dimbl: FTBFS: build-dependency not installable: libtimbl4-dev
Hi Lucas, We're going to let this package get autoremoved, it's hardly used anyway and not worth the effort to maintain. Regards, -- Maarten van Gompel Language Machines research group Centre for Language and Speech Technology Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x39FE11201A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:matrix.org Telegram: proycon IRC: proycon (freenode) Discord:proycon#8272 Mastodon: https://mastodon.social/@proycon (@proycon@mastodon.social) Twitter:https://twitter.com/proycon ORCID: https://orcid.org/-0002-1046-0006 Keybase:https://keybase.io/proycon Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd signature.asc Description: PGP signature
Bug#915264: libfolia: Please upgrade to version 1.15
Hi Hugh, On 18-12-07 08:43, Hugh McMaster wrote: > Hi Maarten, > > On Sunday, 2 December 2018 10:40 PM, Maarten van Gompel wrote: > > Thanks, I'm aware of it and am currently working to update the debian > > packages. > > Many thanks for your work on libfolia, ucto and frog. > > I saw you had updated the Salsa repositories for these packages. > When do you plan to release them to unstable? Everything is indeed ready and I in fact already attempted the upload, but I received REJECTED from FTP master because various source packages introduce NEW binaries and I seem to lack permission for that, I'm still having some trouble securing the necessary help to get things going again, which causes some delay unfortunately. Regards, -- Maarten van Gompel Language Machines research group Centre for Language and Speech Technology Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x39FE11201A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:matrix.org Telegram: proycon IRC: proycon (freenode) Discord:proycon#8272 Mastodon: https://mastodon.social/@proycon (@proycon@mastodon.social) Twitter:https://twitter.com/proycon ORCID: https://orcid.org/-0002-1046-0006 Keybase:https://keybase.io/proycon Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd signature.asc Description: PGP signature
Bug#913514: libfolia FTBFS with ICU 63.1
On 18-11-11 08:18, László Böszörményi wrote: > Source: libfolia > Source-Version: 1.6-2 > Severity: important > Tags: patch > Usertags: icu63 > > Dear Maintainer, > > ICU 63.1 recently released, packaged and uploaded to experimental. > Its transition is going to start soon. However your package fails to > build with this version. I attach a patch which fixes the problem. > Please check if it works with the version in Sid and upload the > package when it's feasible for you. > > Thanks, > Laszlo/GCS Thanks for the heads up and the patch! This problem had already been addressed upstream as well and I just prepared new updated debian packages that should fix it, still pending upload. Kind egards, -- Maarten van Gompel Language Machines research group Centre for Language and Speech Technology Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x39FE11201A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:matrix.org Telegram: proycon IRC: proycon (freenode) Discord:proycon#8272 Mastodon: https://mastodon.social/@proycon (@proycon@mastodon.social) Twitter:https://twitter.com/proycon ORCID: https://orcid.org/-0002-1046-0006 Keybase:https://keybase.io/proycon Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#915264: libfolia: Please upgrade to version 1.15
On 18-12-02 09:51, Hugh McMaster wrote: > Package: libfolia6 > Version: 1.6-2+b1 > Severity: wishlist > > Dear Maintainer, > > The current version of libfolia is almost two years old and is missing several > bug fixes and enhancements. > > It also does not work with icu 63.1. > > Please upgrade to the latest upstream version - 1.15. Thanks, I'm aware of it and am currently working to update the debian packages. Regards, -- Maarten van Gompel Language Machines research group Centre for Language and Speech Technology Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x39FE11201A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:matrix.org Telegram: proycon IRC: proycon (freenode) Discord:proycon#8272 Mastodon: https://mastodon.social/@proycon (@proycon@mastodon.social) Twitter:https://twitter.com/proycon ORCID: https://orcid.org/-0002-1046-0006 Keybase:https://keybase.io/proycon Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
old directory '/etc/ucto': Directory > not empty > Setting up libgomp1:amd64 (6.3.0-4) ... > Setting up libxml2:amd64 (2.9.4+dfsg1-2.2) ... > Processing triggers for libc-bin (2.24-9) ... > Setting up libucto2:amd64 (0.9.6-1) ... > Removing obsolete conffile /etc/ucto/e-mail.rule ... > Removing obsolete conffile /etc/ucto/smiley.rule ... > Removing obsolete conffile /etc/ucto/url.rule ... > Removing obsolete conffile /etc/ucto/standard-eos.eos ... > Removing obsolete conffile /etc/ucto/standard-quotes.quote ... > Removing obsolete conffile /etc/ucto/tokconfig-generic ... > Processing triggers for libc-bin (2.24-9) ... > > > libucto2.maintscript is missing this line: > > rm_conffile /etc/ucto/tokconfig-generic 0.9.6-2~ Really? There's a line "rm_conffile /etc/ucto/tokconfig-generic 0.9.6~" since the first commit. And it does say "Removing obsolete conffile /etc/ucto/tokconfig-generic" above. Ciao, -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon ORCIRD: https://orcid.org/-0002-1046-0006 Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
Quoting Andreas Beckmann (2017-01-24 02:54:36)
> On 2017-01-24 02:51, Andreas Beckmann wrote:
> > spotted a typo (trailing "a") in frogdata.maintscript
> >
> > echo "rm_conffile /etc/frog/${subdir}Frog.mbt.1.0.known.dddwfWaw.wgt
> > 0.13.7~"a
>
> but that's harmless, its still a valid version to achieve your goal
Oops... Well spotted, I just fixed it in git, but it is probably overkill to
prepare/upload a new release just
for that now I guess?
--
Maarten van Gompel
Centre for Language Studies
Radboud Universiteit Nijmegen
proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon
GnuPG key: 0x1A31555C
XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl
Telegram: proycon IRC: proycon (freenode)
Twitter:https://twitter.com/proycon
ORCIRD: https://orcid.org/-0002-1046-0006
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
Hi Mattia, Andreas, @Mattia: Thanks! I'm trying to finalize the packages but still running into something: > use debian/$package.maintscript instead of doing it directly in maintscripts > > put in there lines like > > rm_conffile /etc/ucto/tokconfig-es 0.4-1~ > > no dpkg-maintscript-helper prefix, no default arguments, no trailing > comments! > use $VERSION_TO_BE_UPLOADED + "~" as prior-version argument > > this will generate appropriate pre/post/inst/rm scripts with the same > content This is what I was looking for yes, I knew something must exist to take care of this but didn't know what it was. I now followed Andreas' instructions, but on but upon gbp buildpackage I now get errors like: /home/proycon/debian_packaging/uctodata/debian/uctodata.maintscript: 1: /home/proycon/debian_packaging/uctodata/debian/uctodata.maintscript: rm_conffile: not found So I'm still doing something wrong. Any idea what I am missing? You said no dpkg-maintscript-helper prefix.. Ciao, -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon ORCIRD: https://orcid.org/-0002-1046-0006 Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
Hi Andreas et al, Short follow up: we discussed it internally and think it's indeed best to just move the 'configuration' files to /usr/share, as you pointed out; simplifying the package and resolving the conflicts. We're currently working on new upstream releases for ucto, uctodata, frogdata, and frog (the latter two have the same division and make the same mistake, and depends on ucto/uctodata too) that implement this. I hope releasing four new packages so close to the freeze is not going to be a problem. At least it should fix this bug for good. Regards, -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon ORCIRD: https://orcid.org/-0002-1046-0006 Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd Quoting Maarten van Gompel (2017-01-23 11:10:18) > Hi Andreas, > > Thanks for your elaborate response! It seems this has indeed opened quite a > can > of worms.. Here we go: > > Quoting Andreas Beckmann (2017-01-22 22:27:08) > > TL;DR: You have an ambitious task before you. > > So I see... > > > Let me see if I understand what's going on. > > > > Renaming conffiles and changing the owning package at the same time is a > > PITA. > > You add an extra point by making the old name a symlink to the new one, > > owned by the new package > > > > In jessie, everything in /etc/ucto was owned by ucto. > > In sid, a lot more stuff is in /etc/ucto, and either owned by uctodata > > or libucto2, a m-a:same library package. These come from 2 different > > source packages. > > Indeed.. > > > Yuck. While putting conffiles in m-a:same packages is allowed, I highly > > discourage this. Even if I haven't seen this fail once, yet. I'm just > > afraid, someone has to clean up a mess caused by this at some point in > > the future. and I'm afraid, I won't keep my fingers out of then :-( > > Ok, we'll come back to this in your later suggestion to move the conffiles to > a > new package. > > > Before we start: Are these really conffiles? Supposed to be modified by > > the local admin? Or are these rather data files that are not supposed to > > be updated locally? And would better live in /usr/share in that case? > > You have a point there; the user MAY add a new configuration or modify an > existing one, but it is indeed not something that NEEDS to be modified to > run. You may be right that > /usr/share might be better here. I'd have to discuss with the main upstream > developer, but I think we're not opposed to such 'radical' solutions if that > solves the packaging problems and makes more semantic sense anyway. > What do you think is best for the short term to get this fixed before the > freeze? > > > And nearly everything from jessie's /etc/ucto content is now renamed and > > a symlink. > > > Can't you just fork the project? I'd suggest 'hpgb' and then use > > /etc/hpgb for the conffiles. Oh, I forgot: we are in freeze, so no new > > source packages ... > > > > Oh yeah, it well be a mess. But we will do it right. Including making > > dpkg forget about the old conffiles. > > > > Right now, all upgrade attempts from jessie to stretch should always > > have failed, so there is no further messed up state inbetween that > > should be supported for clean upgrades. > > Right > > > can we move the conffiles from libucto2 to a new package, e.g. > > ucto-common (which would be either m-a:foreign or m-a:allowed, but I > > always mess up these two, I need to look up what's right? > > Okay, that sounds good to me, if there's no objection to having yet another > package. > > > * Which version introduced the new layout? > > * can you give me a list of > > + removed conffiles > > + renamed conffiles (old name, new name, new owning package, whether > > they have a compat symlink, did the content change between jessie and sid) > > ucto 0.9.2 introduced the split into uctodata. The jessie version is very > old: 0.5.3-3.1 > The following files moved out of ucto 0.9.2 (libucto2) into the new uctodata > package: > > config/es.abr > config/exotic-eos.eos > config/exotic-quotes.quote > config/ligatures.filter > config/nl_afk.abr > config/pt.abr (not in jessie version) > config/tokconfig-de > config/tokconfig-en > config/tokconfig-es > config/tokconfig-fr > config/tokconfig-fy > config/tokconfig-it > config/
Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
(not in jessie version) -> config/tokconfig-tur config/tokconfig-sv -> config/tokconfig-swe At that point we decided to symlink from the old two-letter versions to the new three-letter versions, for backward compatibility "to make things easy".. but apparantly this didn't play out as anticipated :) > Do you *really* need the compat symlinks? No, it's just a courtesy for the user that we don't mind dropping at all if it complicates matters like this. > OK, packaging is in git. Need to check whether I have write permissions > there ... > > rough plan: > > ucto uses d-m-h move-conffile (but provides no new version, so the old > conffile should "disappear" and dpkg should forget about it. > Maybe it's better to rm_conffile it instead. Okay, I'll read up on all that today then because I have to prior experience with those. > uctodata will probably need a Conflicts against ucto (<< current+fixed~) Right, Thanks for your help! -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon ORCIRD: https://orcid.org/-0002-1046-0006 Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
Quoting Andreas Beckmann (2017-01-16 17:24:19) > Followup-For: Bug #838112 > Control: found -1 0.3.1-1 > Control: affects -1 + ucto > > that bug has just reappered: > > Preparing to unpack .../ucto_0.9.5-1_amd64.deb ... > Unpacking ucto (0.9.5-1) over (0.5.3-3.1+b1) ... > dpkg: warning: unable to delete old directory '/etc/ucto': Directory not > empty > Selecting previously unselected package uctodata. > Preparing to unpack .../uctodata_0.3.1-1_all.deb ... > Unpacking uctodata (0.3.1-1) ... > dpkg: error processing archive > /var/cache/apt/archives/uctodata_0.3.1-1_all.deb (--unpack): >trying to overwrite '/etc/ucto/es.abr', which is also in package ucto > 0.9.5-1 > > > Andreas Hi, Thanks for the notification. It seems this bug is a persistent one and I don't really get why it's resurfacing; I'm probably missing something so CC'ing the debian-science list for help. Ucto 0.9.5 no longer has the mentioned file /etc/ucto/es.abr, is was part of ucto until 0.8.0-1 and then moved to a separate uctodata package. To prevent this issue, ucto 0.9.5 (package libucto2 actually), states: Replaces: ucto (<< 0.5.5-1) Breaks: ucto (<< 0.5.5-1) Uctodata also states: Replaces: ucto (<< 0.9.2-1) Breaks: ucto (<< 0.9.2-1 But as this resurfaced, it's apparently not enough, What am I missing here? Regards, -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon ORCIRD: https://orcid.org/-0002-1046-0006 Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#837611: ITP: uctodata -- Data for ucto tokeniser
Package: wnpp Severity: wishlist Owner: Maarten van Gompel <proy...@anaproy.nl> * Package name: uctodata Upstream Author : Centre for Language and Speech Technology, Radboud University Nijmegen * URL : https://languagemachines.github.io/ucto * License : GPL-3 Programming Lang: C++ Description : Data for Unicode Tokenizer Ucto can tokenize UTF-8 encoded text files (i.e. separate words from punctuation, split sentences, generate n-grams), and offers several other basic preprocessing steps that make your text suited for further processing such as indexing, part-of-speech tagging, or machine translation. This package provides necessary language-specific datafiles for running Ucto. Ucto was written by Maarten van Gompel and Ko van der Sloot. Work on Ucto was funded by NWO, the Netherlands Organisation for Scientific Research, under the Implicit Linguistics project, the CLARIN-NL program, and the CLARIAH project. Ucto is a product of the Centre of Language and Speech Technology (Radboud University Nijmegen), and previously the ILK Research Group (Tilburg University, The Netherlands). This is a split from package ucto, which previously contained the data as well. -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl http://proycon.anaproy.nl http://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#814250: ITP: colibri-core -- Colibri Core is a Natural Language Processing tool to quickly and efficiently count and extract patterns from large corpus data.
Package: wnpp Severity: wishlist Owner: proycon <proy...@anaproy.nl> * Package name: colibri-core Version : 2.1.3 Upstream Author : Maarten van Gompel <proy...@anaproy.nl> * URL : https://proycon.github.io/colibri-core/ * License : GPL-3 Programming Lang: C++, Python Description : Colibri Core is a Natural Language Processing tool and library to quickly and efficiently count and extract patterns from large corpus data. Colibri Core is software consisting of command line tools as well as programming libraries for C++ and Python to quickly and efficiently count and extract patterns from large corpus data, to extract various statistics on the extracted patterns, and to compute relations between the extracted patterns. The employed notion of pattern or construction encompasses ngrams, skipgrams, and flexgrams. Though, n-gram extraction may seem fairly trivial at first, simple approachs place an unnecessarily high demand on memory resources, this often becomes prohibitive if unleashed on large corpora. Colibri Core tries to minimise these time & space requirements in several ways, and provides a foundation for other tools to build on. The package is to be maintained in the Debian Science packaging team. Hopefully sponsored by Joost van Baal-Ilić? Extra help always welcome. -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl http://proycon.anaproy.nl http://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd signature.asc Description: signature
Bug#805720: ITP: python-clam - CLAM: Quickly turn command-line tools into RESTful webservices
Package: wnpp Severity: wishlist * Package name: python-clam Version: 0.99 Upstream Author: Maarten van Gompel <proy...@anaproy.nl> * URL: https://proycon.github.io/clam License: GPL-3 Description: Quickly turn command-line tools into RESTful webservices with an auto-generated web interface for human end-users. CLAM allows you to quickly and transparently transform your command line application into a RESTful webservice, with which both human end-users as well as automated clients can interact. CLAM takes a description of your system and wraps itself around the system, allowing end-users or automated clients to upload input files to your application, start your application with specific parameters of their choice, and download and view the output of the application once it is completed. CLAM is set up in a universal fashion, requiring minimal effort on the part of the service developer. Your actual application is treated as a black box, of which only the parameters, input formats and output formats need to be described. Your application itself needs not be network aware in any way, nor aware of CLAM, and the handling and validation of input can be taken care of by CLAM. CLAM is entirely written in Python, runs on UNIX-derived systems, and is available as open source under the GNU Public License (v3). It is set up in a modular fashion, and offers an API, and as such is easily extendable. CLAM communicates in a transparent XML format, and using XSL transformation offers a full web 2.0 web-interface for human end users. It is used frequently for Natural Language Processing applications. -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl http://proycon.anaproy.nl http://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#771592: ITP: python-pynlpl -- Python Natural Language Processing Library
Package: wnpp Severity: wishlist * Package name: python-pynlpl Version: 0.7.6.11 Upstream Author: Maarten van Gompel <proy...@anaproy.nl> * URL: https://github.com/proycon/pynlpl License: GPL-3 Description: PyNLPl, pronounced as ‘pineapple’, is a Python library for Natural Language Processing. It contains various modules useful for common, and less common, NLP tasks. PyNLPl can be used for basic tasks such as the extraction of n-grams and frequency lists, and to build simple language model. There are also more complex data types and algorithms. Moreover, there are parsers for file formats common in NLP (e.g. FoLiA/Giza/Moses/ARPA/Timbl/CQL). There are also clients to interface with various NLP specific servers. PyNLPl most notably features a very extensive library for working with FoLiA XML (Format for Linguistic Annotation). -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl http://proycon.anaproy.nl http://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#705129: Python bindings for the Tilburg Memory Based Learner (Timbl)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: wnpp Severity: wishlist Owner: proycon proy...@anaproy.nl * Package name: python-timbl Version : 2013.03.29 Upstream Author : Maarten van Gompel proy...@anaproy.nl * URL : http://github.com/proycon/python-timbl/ * License : GPL Programming Lang: C++, Python Description : Python bindings for the Tilburg Memory Based Learner (Timbl) python-timbl is a Python extension module wrapping the full TiMBL C++ programming interface. With this module, all functionality exposed through the C++ interface is also available to Python scripts. Being able to access the API from Python greatly facilitates prototyping TiMBL-based applications. TiMBL is an open source software package implementing several memory-based learning algorithms, among which IB1-IG, an implementation of k-nearest neighbor classification with feature weighting suitable for symbolic feature spaces, and IGTree, a decision-tree approximation of IB1-IG. All implemented algorithms have in common that they store some representation of the training set explicitly in memory. During testing, new cases are classified by extrapolation from the most similar stored cases. The Python module offers both a high-level as well as a low-level interface, the former is very Pythonic and easy to use while the latter offers the full API. - -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl http://proycon.anaproy.nl http://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRZWjFAAoJEDn+ESAaMVVc/y4H/jDcgwQtRjLMhizVy1o4RKu0 Zrsut6NuolCa9KdFYn6xHDYme0AHNBg1oPuq3AltRVXHeNX/xd+ByfyEFYstu09K QLb7oyNVRDlNS6gDjjpkLhQVSUET9e/jQzwus9HbJEU4CbhYl2JCENDogHOU0ioD Rdf7v4q9armqDPt5ZhaLyuMo2cRQpRTr/T0k35wvgWlz2o8q2gMXC1IAtDOkqNGm shBgIkrPmrmGpo6M00y4Rb5ah+t2MvDExjN1HaQE0xYsJguc6h464yUZvDbIseM8 BejMBYiGWy/LuR2rWXKzOhck6YBDSMpIQ22c/ENvn/OjjDDmyXFQStDzSu9Oiq0= =Wors -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
