Re: How to build compatible packages that use Eigen?

Ryo IGARASHI writes: > Looking at your patch, why do you delete all the #ifndef block in the > first place? Adding just "#define EIGEN_MALLOC_ALREADY_ALIGNED 0" line > on top of the #ifndef block should do the job. That would work, but I don't think it makes a huge difference either way. The

Re: How to build compatible packages that use Eigen?

ation/free are implemented the same way REGARDLESS of build flags. This ensures that an application using Eigen (possibly indirectly, through libraries) will not crash due to non-identical build flags Author: Dima Kogan diff --git a/Eigen/src/Core/util/Memory.h b/Eigen/src/Core/util/Memory.h index 875318

Re: Using videos in presentations

Hi Leopold. I use beamer regularly, but have never wanted to put videos into the slides. I would like to know more about the tools, though. Is the issue that existing pdf viewers can't play embedded video (i.e. do other people's video presentation work)? Or is it that pdflatex cannot produce pdfs

Re: How to build compatible packages that use Eigen?

Hi Anton. Thanks for replying. Anton Gladky writes: > I have been maintaining the Eigen library in Debian for over 12 years, > and I cannot recall the specific bug ticket related to this topic. I believe it. I suspect the reason is that you get mystery crashes that require

Re: How to build compatible packages that use Eigen?

Hi. Apologies for taking so long to look at this again; I've been busy. I just looked into it, and my conclusion is that there's no way to ensure that Eigen won't crash without us patching our package. So we should patch our package. I'm attaching a tiny demo program. Extract it and make &&

Re: How to build compatible packages that use Eigen?

Thank you very much for the notes. The Eigen code I see does everything with the preprocessor. Which is fine, and doesn't mean that it must crash. For the specific package I'm building (libg2o) Eigen is the only option, but this sounds like a generic problem that affects all sorts of packages,

Re: How to build compatible packages that use Eigen?

Thanks for replying u...@debian.org (Aaron M. Ucko) writes: > It might help to make Eigen's symbols local to your shared library; to > that end, I think it would work to feed the linker a version script > reading something along the lines of > > { > local: > extern "C++" { >

How to build compatible packages that use Eigen?

Hi. I'm packaging something that uses Eigen, and I'm running into a persistent compatibility issue I don't currently know how to solve. Help appreciated. Here's the problem. Eigen is a C++ header-only library that's heavy into templating. So all the functions inside Eigen produce weak symbols,

Re: MRs on salsa and letting janitor automate things

Hi. Andreas Tille writes: > IMHO its sensible to follow the latest toolset version sooner or > later. There are several sensible features and if your packages are > vanilla and simple there is no good reason to stick to any specific > debhelper compat version. The reason is that a package that

Re: MRs on salsa and letting janitor automate things

Hi Nilesh and Stuart. That email on debian-devel describes my use case well. My packages are vanilla-enough that there's little value in doing anything more than Build-Depends: debhelper (>=11) and sticking "11" in debian/compat or something like that. Let me know if this has some major downsides

Re: MRs on salsa and letting janitor automate things

Hi. I've been manually checking the merge requests, and have been accepting most of them. There is one thing the janitor does that I don't agree with, and I'd be against any automated merging of those patches. This is adding Build-Depends: debhelper-compat (=WHATEVER). Such dependencies break

Re: Bug#984497: weasels and doves

Albert van der Horst writes: > I don't see the problem here. If there is a bug in an old version > supplied with Debian, the bug report lands with Debian. Then Debian > can solve the bug report by renewing upstream. Sot that bug report is > not against the package, but against the packaging. If

Re: [OT] How to plot time series over weekly / monthly data

In my completely unbiased opinion, you should use my tools! feedgnuplot (http://github.com/dkogan/feedgnuplot) to plot stdin in various flexible ways vnlog (http://github.com/dkogan/vnlog) to manipulate textual tables in various flexible ways Starting with Carsten's modified example to add a

Re: making lib HYPRE monolithic, splitting is unmanageable

Drew Parsons writes: > Speak up if you have arguments for retaining the current split-library > structure (and take over maintenance to make it happen). My feeling is that we should be editorializing on upstream's decisions as little as possible. So I definitely support un-splitting the

Re: MPI debugging workflows

Answering some of my own questions inline... Dima Kogan writes: > 2. Is the MPI implementation significant? Would mpich behave > potentially differently here from openmpi? I rebuilt sundials with mpich instead of openmpi, and those tests now work just fine: nothing locks up. There

Re: Sundials lagging behind upstream

Sébastien Villemot writes: > On Sat, Jun 16, 2018 at 10:16:18PM -0700, Dima Kogan wrote: > >> These packages are not perfect, but I think they're good-enough to push. >> So I just pushed them to the archive. They still need to clear NEW, so >> don't expect them to

Re: Sundials lagging behind upstream

James Tocknell writes: > 2. The new matrix/solver libs refer to a (which one isn't specified) > LICENSE file, but appear to not match any one. I've currently put them > under the top level LICENSE (LLNL/LLNS), but that's doesn't match the top > of the files (LLNS/SMU). Suggestions of how to

Re: SuperLU-mt

Drew Parsons <dpars...@debian.org> writes: > On Sun, 2018-05-20 at 16:12 -0700, Dima Kogan wrote: >> I'm working on Sundials right now, and I noticed that Debian ships >> the >> non-parallelized SuperLU (in "libsuperlu..." packages) but not the &

vnlog permissions on salsa

Hi. Can a science-team admin on salsa please change the permissions of this project: https://salsa.debian.org/science-team/vnlog to be publically viewable? I can't do it myself. Thanks!

Re: Sundials lagging behind upstream

James Tocknell writes: > Upstream has at the very least moved files around, and based on the > changelog that upstream posted, there are definitely ABI breaks. I did go > through the files and update d/copyright, but I need to do one final pass > before I push it. I plan on

SuperLU-mt

Hi all. I'm working on Sundials right now, and I noticed that Debian ships the non-parallelized SuperLU (in "libsuperlu..." packages) but not the multi-threaded superlu-mt. Upstream: http://crd-legacy.lbl.gov/~xiaoye/SuperLU/ Does anybody know if there's some specific reason for this (funny

Re: Sundials lagging behind upstream

Andreas Tille writes: > I need to package the R interface to sundials[1] which contains a code > copy of some more recent version than the Debian package. I wonder > whether there is some reason to stick to version 2.7.0 while upstream > has released 3.1.1. Hi. Lack of time

Re: Project permissions on salsa

Mattia Rizzolo <mat...@debian.org> writes: > On Sun, Apr 01, 2018 at 05:56:38PM -0700, Dima Kogan wrote: >> Hi. Yes, that's the document I'm reading, and it does say to use the web >> interface. I think it'll be more helpful if it said something like >> >>

Re: Project permissions on salsa

James Clarke writes: > I don't know what copy of the document you're reading, but it has > already been updated, and the Alioth page redirects to its new > location on Salsa[0] which also contains a link to the repository. > > [0] https://science-team.pages.debian.net/policy/

Re: Project permissions on salsa

Anton Gladky writes: > you should not ssh into the git.debian.org to create the project on > salsa. Please use the web interface from salsa to create a new repo. OK, I'll do that in the future. But this repository exists already. Can somebody please change its permissions to

Project permissions on salsa

Hi all. I have a new project in debian-science: https://salsa.debian.org/science-team/vnlog I THINK I created it the normal way: 1. ssh git.debian.org 2. cd /git/debian-science 3. ./setup-repository .. I did this a little while ago, so maybe I'm misremembering. In any case, the

Re: New sundials upstream release

Dima Kogan <d...@secretsauce.net> writes: > S�bastien Villemot <sebast...@debian.org> writes: > >> Any update on this? I see that the git upstream branch has been >> updated to 3.1. Is there any blocker, other than lack of time? I'm >> willing to help if nee

Re: New sundials upstream release

Sébastien Villemot writes: > Any update on this? I see that the git upstream branch has been > updated to 3.1. Is there any blocker, other than lack of time? I'm > willing to help if needed. Lack of time. I was going to return to this in a few weeks, but if you have cycles

Re: gbp import-orig failure on bcolz

Daniel Stender writes: > I've problems with importing the upstream tarball into the repo of Bcolz: > > > $ uscan --no-conf --verbose --download --force-download --destdir ../ > --rename --repack --compression xz > {...} > $ gbp import-orig

Re: Help with Qwt and PyQt-Qwt, C++ symbols

Gudjon I. Gudjonsson writes: >> This generates the attached report. I guess the proposed patch changes >> the layout of the vtable, so calls to virtual functions past the vtable >> changes would break. I just looked at the report again, and I'm no longer entirely sure it

Re: Help with Qwt and PyQt-Qwt, C++ symbols

Gudjon I. Gudjonsson writes: > I have been trying to make a python wrapper to the library: > https://github.com/GauiStori/PyQt-Qwt > So far it works ok for me even if it doesn't support all Qwt functionality > but it > only builds if I add the attached patch. > Most of the

New sundials upstream release

Hi all. Sid currently has sundials 2.7. There's a new major release from upstream: 3.1.0: https://computation.llnl.gov/projects/sundials/sundials-software I haven't started to look at the update yet. Does anybody know of a reason to NOT update our packages yet? I.e. is anybody maintaining

Re: RFP: lxi-tools and liblxi

Martin Lund <martin.l...@keep-it-simple.com> writes: > On Sat, Dec 16, 2017 at 9:13 PM, Dima Kogan <dko...@debian.org> wrote: > >> I can probably take a look at it at some point. I don't have any of the >> relevant hardware, however. You'd test the packages, yes?

Re: RFP: lxi-tools and liblxi

Martin Lund writes: > I'm the author and maintainer of https://lxi-tools.github.io - an open > source project trying to create good and simple tools to manage and control > LXI compatible instruments such as modern oscilloscopes, power supplies, > spectrum

Re: OpenCV C-API support

Mattia Rizzolo writes: > Did anybody ever tried sending a PR upstream? In your first message > you linked to bug reports, not PRs. I'd first start there, if such a > patch is so simple as you claim it would be, and it is techinically > correct, I don't see a reason for it to

Re: OpenCV C-API support

Ghislain Vaillant writes: >> 2. Patch our build of OpenCV3 that works with the older API. Right now, >> this actually is simple (I think). We'd just need to move the >> definition of cvRound() to C header instead of a C++ one. I'm sure >> there're details to be

OpenCV C-API support

Hi all. So it looks like the OpenCV people have pretty much abandoned their C API, to the point where trivial applications no longer build: https://github.com/opencv/opencv/issues/6221 https://github.com/opencv/opencv/issues/8658 https://github.com/opencv/opencv/issues/10246 They're

Re: libsundials-dev

Drew Parsons writes: > Heads up on sundials, PETSc 3.8 has just been released. I'll upload to > experimental soon, and to unstable as soon as practicable. Hopefully > sundials won't have trouble with the new petsc. I'll try it out when you make the upload. Was there an ABI

Re: libsundials-dev

James Tocknell writes: > Using CMAKE_SKIP_INSTALL_PATH or CMAKE_SKIP_RPATH instead of > CMAKE_SKIP_BUILD_PATH appear to produce the same result as > CMAKE_SKIP_BUILD_PATH with respect to RPATHs, so unless there was a bug in > cmake, I'm not sure what I tried previously.

Re: libsundials-dev

James Tocknell writes: > I looked at the RPATH change, lintian doesn't show any RPATH warnings > for me, I also ran readelf on the shared libraries, no RPATH or > RUNPATH. I'm building via gbp and cowbuilder on amd64 (with sid as the > target distro), could that be the

Re: libsundials-dev

S�bastien Villemot writes: > On Wed, Jul 26, 2017 at 11:28:22AM +1000, James Tocknell wrote: >> I've updated debian/copyright on master (on sundials.git) with some of the >> changes (which I did via grepping the files), but I probably haven't got >> everything (the

Re: libsundials-dev

S�bastien Villemot writes: > So I am willing to help with the upcoming transition (once the package > is in experimental), and in general with any specific difficulty that > you may have encountered. Don't hesitate to ask me. Thanks! I need to fix the debian/copyright and

Re: libsundials-dev

Andreas Tille writes: > I can confirm that the package builds at my side and has only lintian > issues that are acceptable for me. If you ask me I would not mind to > upload without ths symbols files in this specific case but I'll leave > the decision to you. I updated the

Re: libsundials-dev

Drew Parsons <dpars...@debian.org> writes: > On Sat, 2017-05-27 at 23:52 -0700, Dima Kogan wrote: >> I'm looking at the sundials packaging again. > ... >> What about the -dev package? I THINK putting everything into a single >> libsundials-dev is OK, and shouldn

libsundials-dev

Science people: I'm looking at the sundials packaging again. This is an umbrella library that has several different sub-libraries for - different ODE solvers - linear algebra backends used by these solvers The granularity question came up earlier, and some of you pointed me to a section in the

Re: Sigrok RFSs

Zoltan Gyarmati writes: > @Andreas, i've set the corresponding bugs to ITA, and i think we can > start the review process at your convenience. I'm starting a separated > thread about that here at debian-mentors. Hi. It's on my list to look at your packages, I just

Re: Sigrok RFSs

Andreas Tille writes: > On Sat, Mar 11, 2017 at 03:32:42AM +0100, Zoltan Gyarmati wrote: >> Dear Mentors, >> >> at the beggining of the last week i submitted a couple of RFSs[1] >> regarding to the packages related to the sigrok[2] suite and its updates >> since the last

Re: Sundials status update: ABout to upload to experimental (Was: Sundials is way outdated)

Dima Kogan <d...@secretsauce.net> writes: > Andreas Tille <andr...@an3as.eu> writes: > >> OK. But please do not hesitate to long. We are talking about an upload >> to *experimental*. I see no point in delaying an upload to do some >> sophisticated engineeri

Re: Sundials status update: ABout to upload to experimental (Was: Sundials is way outdated)

Andreas Tille writes: > OK. But please do not hesitate to long. We are talking about an upload > to *experimental*. I see no point in delaying an upload to do some > sophisticated engineering while people are waiting to build other code > against latest sundials. OK. If you

Re: Sundials status update: ABout to upload to experimental (Was: Sundials is way outdated)

Andreas Tille writes: > I fixed some lintian info grade issues (duplicated descriptions, > hardening=+bindnow) and I'm about to upload to experimental. The > debian/changelog entries from Dima and James are a bit sparse / > non-existant and we should establish a better culture

Re: Sundials is way outdated

Just pushed some patches. Notes inline. Andreas Tille writes: > While I keep on wondering why you are not pushing to master your commit > 26d465d9dff18866d0fe5a4ffa942e49771ef7e5 (or what you are refering to > with "Fix pushed" does not address the problem). I can confirm

Re: Sundials is way outdated

Andreas Tille writes: > While I keep on wondering why you are not pushing to master I haven't been intentionally pushing to something other than master for a little while. Apparently I've been pushing to a branch called "origin/master". You read that right. The remote branch

Re: Sundials is way outdated

Dima Kogan <d...@secretsauce.net> writes: > Andreas Tille <ti...@debian.org> writes: > >> I tried to merge master_optional_stuff_enabled branch into master >> but this does not build since >> >> Package PETSc was not found in the pkg-config search pa

Re: Sundials is way outdated

Andreas Tille writes: > I tried to merge master_optional_stuff_enabled branch into master > but this does not build since > > Package PETSc was not found in the pkg-config search path. This should work in general, and I don't know where you see this error. The Build-dep:

Re: Sundials is way outdated

Andreas Tille <ti...@debian.org> writes: > commit 26038269fc23ecf26abb85cd78fced63a3799a87 > Author: Dima Kogan <d...@secretsauce.net> > Date: Fri Feb 10 19:26:13 2017 -0800 > > I don't build the static libraries > > Usually we provide *.a files insid

Re: Sundials is way outdated

Andreas Tille writes: > So could anybody please, pretty please commit something that really > results in installable packages? I guess if you insist! I worked on this, and I claim the branch in master should build. Please look through the commits to make sure it all makes

Re: Sundials is way outdated

Andreas Tille writes: > /usr/bin/ld: cannot find -lpthreads > > I'm using a just updated pbuilder chroot. Any hints? Did you add Build-Depends: python ?

Re: Sundials is way outdated

James Clarke writes: >> dh_install: Cannot find (any matches for) "bin/sundials-config" (tried in >> "." and "debian/tmp") bin/sundials-config isn't something that upstream builds anymore, I don't think. Removing this from the appropriate install makes it go much further.

Re: Sundials is way outdated

James Clarke writes: > Looking at your error message again, that seems to be coming from CMake > searching for pthread_create, which it does by first searching for a > libpthreads (which doesn't exist on Linux), then a libpthread, which is > the one that exists. My build

Re: Sundials is way outdated

Andreas Tille writes: > On Wed, Feb 01, 2017 at 11:48:08PM +, Ghislain Vaillant wrote: >> > I admit I would have prefered if you would have left you as owner and >> > would take over the lead here. >> >> I thought I was stepping on someone else's work (Dima or James)

Re: Sundials is way outdated

Andreas Tille writes: > Hi folks, > > I just realised that our packaged sundials is lagging two releases > behind upstream. Its a bit bad to learn this right now - some days > after changes can make it into Stretch. :-( Hi. We talked about this a few months ago:

Re: looking for a maintainer (pcb-rnd)

pcb-...@igor2.repo.hu writes: > I got redirected from pkg-electronics-devel to debian-science with the > request below. I already have a working binary package lintian finds > good, the source package still has some lintian warnings. I'm the upstream > developer/maintainer; if someone is

Re: Packaging new upstream for sundials

James Tocknell writes: > I looked at 2.7.0, there's another ABI break: it looks like Sls* symbols > were moved to Sparse*. I've nearly finished cleaning up what I did, the > main problem is the soversions, it looks like upstream is assuming > soversion == release version.

Re: Packaging new upstream for sundials

James Tocknell writes: > I do plan on finishing it, but was going to wait till after the freeze > to push it to the archive, as it involved dropping octave-sundials, > which now seems like a moot point given upstream's decision to drop > the matlab interface from the release.

Re: Packaging new upstream for sundials

James Tocknell writes: > How much of the packaging have you done? I've almost done 2.6-2.6.2, the > main problem was trying to make octave-sundials multiarch (given the build > system used upstream is a hacky matlab script). I've got multiarch working > for the rest of

Packaging new upstream for sundials

Hi. I'm packaging the new 2.7.0 release of sundials to update our very old 2.5.0 packages. Upstream has removed (possibly temporarily) the matlab toolbox: http://computation.llnl.gov/projects/sundials/sundials-software Thus a packaging of 2.7.0 would remove the octave-sundials package. Any

Upload of vlfeat requested

Hi. I have a new version of vlfeat ready for upload. I have DM rights to push it myself, but upstream changed their ABI, so there's a new package. The tree is at http://anonscm.debian.org/cgit/debian-science/packages/vlfeat.git Thanks much dima -- To UNSUBSCRIBE, email to

Re: Looking for a sponsor for some robotics related packages

gladky.an...@gmail.com writes: Why do you have this line in all debian/rules? .PHONY: override_dh_auto_clean override_dh_strip debian/rules is a Makefile. override_dh_auto_clean is declared as a target with no prerequisites, so normally if there exists a file called 'override_dh_auto_clean',

Re: RFS: VLFeat computer vision library

Hi Andreas Tille andr...@an3as.eu writes: I checked this out and have noticed in debian/README.source: The SIFT implementation was removed from the source ... That's OK, but if you change the upstream source you should either provide a) get-orig-source target in d/rules b)

Re: RFS: VLFeat computer vision library

Yaroslav Halchenko deb...@onerussian.com writes: FWIW -- I have tried to build backports using our neurodebian setup... it seem that all 32bit userland builds (while system is running on 64bit kernel) fail with ... I'll take a look. I was trying to keep as much of the upstream build

Re: RFS: VLFeat computer vision library

Dima Kogan d...@secretsauce.net writes: Yaroslav Halchenko deb...@onerussian.com writes: FWIW -- I have tried to build backports using our neurodebian setup... it seem that all 32bit userland builds (while system is running on 64bit kernel) fail with ... I'll take a look. I was trying

Re: RFS: VLFeat computer vision library

Yaroslav Halchenko deb...@onerussian.com writes: On Fri, 22 Nov 2013, Dima Kogan wrote: faith in it now. Yaroslav, can you pleaase try it again on your 32-bit install? I can set one up in emulation, but hopefully it just works now. The tree is here: http://anonscm.debian.org/gitweb/?p

Re: RFS: VLFeat computer vision library

Andreas Tille andr...@an3as.eu writes: Hi Dima, On Thu, Nov 07, 2013 at 11:10:54PM -0800, Dima Kogan wrote: 2013/11/8 Dima Kogan d...@secretsauce.net: Hi all. I packaged VLFeat (http://vlfeat.org), and am looking for sponsorship. Anton Gladky gladky.an...@gmail.com writes: Hi

RFS: VLFeat computer vision library

Hi all. I packaged VLFeat (http://vlfeat.org), and am looking for sponsorship. This is a computer vision library that implements a number of useful algorithms. The completed packages were uploaded to mentors: http://mentors.debian.net/package/vlfeat The ITP lives here:

Re: RFS: VLFeat computer vision library

2013/11/8 Dima Kogan d...@secretsauce.net: Hi all. I packaged VLFeat (http://vlfeat.org), and am looking for sponsorship. Anton Gladky gladky.an...@gmail.com writes: Hi Dima, I will be glad to review/upload this package. But i can do it only on weekends. Thank you very much, Anton

Re: Looking for a sponsor for the ViSP package

On Mon, 17 Dec 2012 09:40:49 +0900 Nobuhiro Iwamatsu iwama...@nigauri.org wrote: And I can not check your GPG key I have noticed that your key is signed by nobody. If possible, please do key signing with other people. Probably, it is better if it is Debian Developer. He's looking for

Re: Bug#692000: ITP: liblbfgs -- L-BFGS solver for dense nonlinear optimization problems

On Tue, 13 Nov 2012 09:26:22 +0100 Andreas Tille andr...@an3as.eu wrote: Hi Dima, On Mon, Nov 12, 2012 at 10:26:13PM -0800, Dima Kogan wrote: The missing copyright status of debian/* was an oversight on my part. I just added it. Thanks for the comments. Uploaded. BTW, I'm afraid

Re: Bug#692000: ITP: liblbfgs -- L-BFGS solver for dense nonlinear optimization problems

On Mon, 12 Nov 2012 08:36:46 +0100 S__bastien Villemot sebast...@debian.org wrote: Dima Kogan d...@secretsauce.net writes: On Sun, 11 Nov 2012 22:57:41 +0100 Andreas Tille ti...@debian.org wrote: On Sun, Nov 11, 2012 at 01:29:17PM -0800, Dima Kogan wrote: dpkg-source: error

Re: Bug#692000: ITP: liblbfgs -- L-BFGS solver for dense nonlinear optimization problems

, Nov 04, 2012 at 10:50:15PM -0800, Dima Kogan wrote: OK. Thanks, Andreas. I just finished the packaging of those two libraries. Their gitwebs are http://anonscm.debian.org/gitweb/?p=debian-science/packages/libdogleg.git http://anonscm.debian.org/gitweb/?p=debian-science/packages

Re: Bug#692000: ITP: liblbfgs -- L-BFGS solver for dense nonlinear optimization problems

On Sun, 11 Nov 2012 22:57:41 +0100 Andreas Tille ti...@debian.org wrote: On Sun, Nov 11, 2012 at 01:29:17PM -0800, Dima Kogan wrote: dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../libdogleg_0.08.orig.tar.{bz2,gz,lzma,xz} Any

Re: Bug#692000: ITP: liblbfgs -- L-BFGS solver for dense nonlinear optimization problems

On Sun, 4 Nov 2012 23:03:29 +0100 Andreas Tille andr...@fam-tille.de wrote: Hi, Debian Med was a simple typo - I intended to write Debian Science. Kind regards Andreas. On Sat, Nov 03, 2012 at 04:23:49PM -0700, Dima Kogan wrote: On Sat, 3 Nov 2012 18:38:05 +0100

Re: Bug#692000: ITP: liblbfgs -- L-BFGS solver for dense nonlinear optimization problems

On Sat, 3 Nov 2012 18:38:05 +0100 Andreas Tille andr...@an3as.eu wrote: Hi Dima, you have submitted a series of ITPs which are all quite interesting for Debian Science. Are you considering to maintain these package in the Debian Med team (and its repositories on Alioth)? Kind regards

Re: RFS: feedgnuplot/1.20 [ITP]

On Tue, 11 Sep 2012 07:29:02 +0200 Anton Gladky gladky.an...@gmail.com wrote: Hi, it seems, your package looks fine. Some minor suggestions: - New upload should close ITP bug. Just add Close at the end of changelog-line: * debian packaging cleanup. (Closes: #686413) -

Re: RFS: feedgnuplot/1.20 [ITP]

Hi all. I am looking for a sponsor for my package feedgnuplot. This is a general-purpose tool to construct plots from standard input. It can be used to plot both realtime and stored data. A trivial example: $ seq 5 | feedgnuplot will plot a line. Fancy things are possible. For