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 hea
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 i
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 build
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 I
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
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, and
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++" {
>
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, not
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 && .
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 more-than-the-usual-
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
gen memory allocation/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/M
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 big
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:
http://bugs.debian.org
> 2013/11/8 Dima Kogan :
>> Hi all.
>>
>> I packaged VLFeat (http://vlfeat.org), and am looking for sponsorship.
>
> Anton Gladky writes:
>
> Hi Dima, I will be glad to review/upload this package.
> But i can do it only on weekends.
Thank you very much, Ant
Andreas Tille writes:
> Hi Dima,
>
> On Thu, Nov 07, 2013 at 11:10:54PM -0800, Dima Kogan wrote:
>> > 2013/11/8 Dima Kogan :
>> >> Hi all.
>> >>
>> >> I packaged VLFeat (http://vlfeat.org), and am looking for sponsorship.
>> >
Hi
Andreas Tille 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) specify Fi
Yaroslav Halchenko 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
system as possible,
Dima Kogan writes:
> Yaroslav Halchenko 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
Yaroslav Halchenko 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.debia
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'
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 debian-science-requ.
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
o
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 sundials, and have added pk
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.
>
> I've pushed the
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.
OK. Thanks for running
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 willin
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:
https://lists.debian.org/debi
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) and
>
> If this would ha
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 seemed to deal with it fi
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.
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 ?
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 sense.
The branch in
Andreas Tille writes:
> commit 26038269fc23ecf26abb85cd78fced63a3799a87
> Author: Dima Kogan
> Date: Fri Feb 10 19:26:13 2017 -0800
>
> I don't build the static libraries
>
> Usually we provide *.a files inside -dev packages. Do you have any
> reason not do
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: libpetsc3.7-dev should
Dima Kogan writes:
> 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&#x
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 is called
"origin/or
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 that I'm
> now again
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 here. I think
> I
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 don't get to it by
Dima Kogan writes:
> 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
&g
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 version released to Debia
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 haven't gotten
around to it yet
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 p
Drew Parsons 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't break any
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 symbols files, and pu
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-upload, but haven't
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 licensecheck script flagged a f
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 problem?
Hmmm. I see no rp
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.
Thanks for looking. Appar
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 update in
PETSc? I.e.
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 uninte
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 worked out, but it LOOK
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 not be upstreamable.
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 analyzers etc.
>
> Some time ago I've pu
Martin Lund writes:
> On Sat, Dec 16, 2017 at 9:13 PM, Dima Kogan 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?
>>
>
> Sure, no problem - I'll be gla
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 some
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 patch is instantiation
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
actually says that the p
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 ../bcolz_1.1.2+ds1.orig.tar.xz
> What is the upstream v
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 to help, let me take a
Dima Kogan writes:
> 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.
Just looked at it, and there's still a lot
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 project
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 "public"? Or do I ne
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/
Hi. Yes, that's the
Mattia Rizzolo 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
>>
>> Instead of ca
Andreas Tille writes:
> On Fri, Apr 27, 2018 at 06:36:51PM +0200, S�bastien Villemot wrote:
>
>> There is also a licensing issue: using GPL'd software (e.g. GNU
>> Octave) with MKL is not allowed.
>
> I think that's a pretty strong reason to rate non-free software lowest
> in the alternatives. Pa
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 is the only reason.
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
li
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 doing that in the next
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!
Drew Parsons 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
>> multi-threaded
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 handl
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 th
Hi. Does anybody have experience debugging MPI lockups? I can use some
pointers. The symptom is that the sundials test suite now hangs on some
arches. For instance on armhf:
abel% mpirun -n 4
examples/sunlinsol/spgmr/parallel/test_sunlinsol_spgmr_parallel 100 1 1 50 1e-3 0
SPGMR linear s
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 mi
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
packages
Hi.
I'm looking for sponsorship for this package. Somebody commented on the
ITP bug saying that this package possibly belongs in Debian Science, so
I'm forwarding the RFS here.
Thanks
Begin forwarded message:
Date: Sat, 01 Sep 2012 01:50:37 -0700
From: Dima Kogan
To: Debian Bu
> > 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 a
> On Tue, 11 Sep 2012 07:29:02 +0200
> Anton Gladky 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)
>
> - Line 8 in c
> On Sat, 3 Nov 2012 18:38:05 +0100
> Andreas Tille 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
>
>
> On Sun, 4 Nov 2012 23:03:29 +0100
> Andreas Tille 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:
ll help you.
>
> On Sun, 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/packag
> On Sun, 11 Nov 2012 22:57:41 +0100
> Andreas Tille 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.
> On Mon, 12 Nov 2012 08:36:46 +0100
> S__bastien Villemot wrote:
>
> Dima Kogan writes:
>
> >> On Sun, 11 Nov 2012 22:57:41 +0100
> >> Andreas Tille wrote:
> >>
> >> On Sun, Nov 11, 2012 at 01:29:17PM -0800, Dima Kogan wrote:
> >> &g
> On Mon, 12 Nov 2012 14:01:58 +0100
> Andreas Tille wrote:
>
> Now I was able to build libdogleg without any problem. The only issue
> in the packaging is that there is no explicite license statement for the
> debian/* files. I realise that you are maintainer and upstream at the
> same time, bu
> On Tue, 13 Nov 2012 09:26:22 +0100
> Andreas Tille 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 comme
> On Mon, 17 Dec 2012 09:40:49 +0900
> Nobuhiro Iwamatsu 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 sponsorship for hi
88 matches
Mail list logo
