Bug#479882: ITP: clp -- Coin-or linear programming solver
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg <[EMAIL PROTECTED]> * Package name: clp Version : 1.7.4 Upstream Author : John J. Forrest <[EMAIL PROTECTED]> * URL : https://projects.coin-or.org/Clp * License : CPL 1.0 Programming Lang: C++ Description : Coin-or linear programming solver Clp (Coin-or linear programming) is an open-source linear programming solver written in C++. It is primarily meant to be used as a callable library, but a basic, stand-alone executable version is also available. It is designed to find solutions of constrained linear mathematical optimization problems. -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25-sonne (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485858: ITP: coinutils -- Coin-or collection of utility classes
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg <[EMAIL PROTECTED]> * Package name: coinutils Version : 2.2.5 Upstream Author : J.P Fasano, John J. Forrest, Lou Hafer, Laszlo Ladanyi, Francois Margot, Matt Saltzman, Ted Ralphs * URL : https://projects.coin-or.org/CoinUtils * License : Common Public License 1.0 Programming Lang: C++ Description : Coin-or collection of utility classes CoinUtils (Coin-or Utilities) is a collection of classes that are generally useful to more than one COIN-OR project. These include vector, matrix, mps file reading classes. COIN-OR (COmputational INfrastructure for Operations Research project) is an initiative to spur the development of open source software in operational research - mathematical optimization algorithms. -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-rc5-sonne (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#487361: ITP: seqan -- A C++ template library for the analysis of sequences.
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg <[EMAIL PROTECTED]> * Package name: seqan Version : 1.1 Upstream Author : Andreas Döring <[EMAIL PROTECTED]> * URL : http://www.seqan.de/ * License : LGPL Programming Lang: C++ Description : A C++ template library for the analysis of sequences. SeqAn is a C++ template library of efficient algorithms and data structures for the analysis of sequences with the focus on biological data. This library applies a unique generic design that guarantees high performance, generality, extensibility, and integration with other libraries. SeqAn is easy to use and simplifies the development of new software tools with a minimal loss of performance. -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-rc7-sonne (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#543766: ITP: h5py is a general-purpose Python interface to hdf5
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg * Package name: python-h5py Version : 1.2.0 Upstream Author : Andrew Collette * URL : http://code.google.com/p/h5py/ * License : BSD Programming Lang: C, Python Description : h5py is a general-purpose Python interface to hdf5 HDF5 for Python (h5py) is a general-purpose Python interface to the Hierarchical Data Format library, version 5. HDF5 is a versatile, mature scientific software library designed for the fast, flexible storage of enormous amounts of data. >From a Python programmer's perspective, HDF5 provides a robust way to store data, organized by name in a tree-like fashion. You can create datasets (arrays on disk) hundreds of gigabytes in size, and perform random-access I/O on desired sections. Datasets are organized in a filesystem-like hierarchy using containers called "groups", and accessed using the tradional POSIX /path/to/resource syntax. A generic NumPy interface to HDF5 data H5py provides a simple, robust read/write interface to HDF5 data from Python. Existing Python and Numpy concepts are used for the interface; for example, datasets on disk are represented by a proxy class that supports slicing, and has dtype and shape attributes. HDF5 groups are presented using a dictionary metaphor, indexed by name. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549409: ITP: coinor-coinmp -- a lightweight API and library for coinor-clp, coinor-cbc, and coinor-cgl
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg * Package name: coinor-coinmp Version : 1.4 Upstream Author : Bjarni Kristjansson, bjarni at maximalsoftware dot com * URL : http://www.coin-or.org/projects/CoinMP.xml * License : Common Public License 1.0 Programming Lang: C++ Description : a lightweight API and library for coinor-clp, coinor-cbc, and coinor-cgl CoinMP is a C-API interface library that supports most of the functionality of the CLP (Coin LP), CBC (Coin Branch-and-Cut), and CGL (Cut Generation Library) projects. CoinMP is part of the larger COIN-OR initiative (Computational Infrastructure for Operations Research). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549410: ITP: coinor-flopc++ -- an algebraic modeling language embedded in C++
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg * Package name: coinor-flopc++ Version : 1.0.6 Upstream Author : Tim Hultberg, tim dot hultberg at eumetsat dot int * URL : http://www.coin-or.org/projects/FlopC++.xml * License : Common Public License 1.0 Programming Lang: C++ Description : an algebraic modeling language embedded in C++ An open source algebraic modelling language implemented as a C++ class library. Coinor-flopc++ is part of the larger COIN-OR initiative (Computational Infrastructure for Operations Research). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549411: ITP: coinor-smi -- Stochastic Modeling Interface, for optimization under uncertainty
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg * Package name: coinor-smi Version : 0.92.1 Upstream Author : Alan King, kingaj at us dot ibm dot com * URL : http://www.coin-or.org/projects/Smi.xml * License : Common Public License 1.0 Programming Lang: C++ Description : Stochastic Modeling Interface, for optimization under uncertainty Smi is an open-source interface for modeling stochastic linear programming problems. Currently it supports: a scenario tree structure for multiperiod stochastic data, an implementation of a Stochastic MPS (SMPS) reader, direct interfaces for generating scenario trees from paths and from discrete random variables, generating the deterministic equivalent problem for OSI compatible solvers, and parsing the solutions by stage and scenario. Smi is part of the larger COIN-OR initiative (Computational Infrastructure for Operations Research). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549413: ITP: coinor-ipopt -- Interior-Point Optimizer, for general large-scale nonlinear optimization
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg * Package name: coinor-ipopt Version : 3.7.0 Upstream Author : andreasw at watson dot ibm dot com * URL : http://www.coin-or.org/projects/Ipopt.xml * License : Common Public License 1.0 Programming Lang: C++ Description : Interior-Point Optimizer, for general large-scale nonlinear optimization Ipopt is an open-source solver for large-scale nonlinear continuous optimization. It can be used from modeling environments, such as AMPL, GAMS, or Matlab, and it is also available as callable library with interfaces to C++, C, and Fortran. Ipopt uses an interior point method, together with a filter linear search procedure. Ipopt is part of the larger COIN-OR initiative (Computational Infrastructure for Operations Research). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549414: ITP: coinor-symphony -- a callable library for solving mixed-integer linear programs
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg * Package name: coinor-symphony Version : 5.2.0 Upstream Author : Ted Ralphs, tkralphs at lehigh dot edu * URL : https://projects.coin-or.org/SYMPHONY * License : Common Public License 1.0 Programming Lang: C++ Description : a callable library for solving mixed-integer linear programs SYMPHONY is an open-source generic MILP solver, callable library, and extensible framework for implementing customized solvers for mixed-integer linear programs (MILPs). SYMPHONY can be built in various sequential and parallel configurations for either distributed or shared memory architectures and can be used "out of the box" as a solver for generic mixed-integer linear programs or customized through a wide variety of user callback functions and control parameters. SYMPHONY has a number of advanced capabilities stemming from the research projects discussed above, including the ability to solve multi-objective MILPs, the ability to warm start its solution procedure, and the ability to perform basic sensitivity analyses. SYMPHONY has has been deployed in a variety of application areas, including computational biology, wireless telecommunications, supply chain management, transportation services, and air transportation. SYMPHONY is part of the larger COIN-OR initiative (Computational Infrastructure for Operations Research). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549418: ITP: coinor-oboe -- Oracle Based Optimization Engine
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg * Package name: coinor-oboe Version : 1.0.2 Upstream Author : nsawhney at gmail.com * URL : https://projects.coin-or.org/OBOE/ * License : Common Public License 1.0 Programming Lang: C++ Description : Oracle Based Optimization Engine OBOE (Oracle Based Optimization Engine) is an open source software for general convex optimization. It assumes that a user-made code, thereafter named oracle, is capable of delivering first order information on the key elements of the problem (support the feasible set, support to the objective function). The engine exploits this information to construct the so-called localization set which is a polyhedral approximation of the set of optimal solutions. OBOE is part of the larger COIN-OR initiative (Computational Infrastructure for Operations Research). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549415: ITP: coinor-chipps -- a framework for constructing parallel tree search algorithms
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg * Package name: coinor-chipps Version : 1.0.0 Upstream Author : Ted Ralphs, tkralphs at lehigh dot edu * URL : https://projects.coin-or.org/CHiPPS * License : Common Public License 1.0 Programming Lang: C++ Description : a framework for constructing parallel tree search algorithms CHiPPS is the COIN-OR Open Parallel Search Framework, a framework for implementing parallel algorithms based on tree search. The current CHiPPS architecture consists of three layers. The Abstract Library for Parallel Search (ALPS) is the base layer of a hierarchy consisting of implementations of various tree search algorithms for specific problem types. The Branch, Constrain, and Price Software (BiCePS) is a data management layer built on top of ALPS for implementing relaxation-based branch and bound algorithms. The BiCePS Linear Integer Solver (BLIS) is a concretization of the BiCePS layer for solving mixed-integer linear programs. ALPS, BiCePS, and BLIS are sub-repostories of the CHiPPS Subversion repository. CHiPPS is part of the larger COIN-OR initiative (Computational Infrastructure for Operations Research). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549417: ITP: coinor-bcp -- a framework for constructing parallel branch-cut-price algorithms for mixed-integer linear programs
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg * Package name: coinor-bcp Version : 1.2.2 Upstream Author : Common Public License 1.0 * URL : https://projects.coin-or.org/Bcp * License : Common Public License 1.0 Programming Lang: C++ Description : a framework for constructing parallel branch-cut-price algorithms for mixed-integer linear programs BCP is a parallel framework for implementing branch, cut, and price algorithms for solving mixed integer programs (MIPs). BCP provides the user with an object-oriented framework that can be used to develop an efficient problem class specific MIP solver without all the implementational effort. involved with implementing a branch and bound framework from scratch. BCP is part of the larger COIN-OR initiative (Computational Infrastructure for Operations Research) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#549417: ITP: coinor-bcp -- a framework for constructing parallel branch-cut-price algorithms for mixed-integer linear programs
On Sat, 2009-10-03 at 08:16 -0300, David Bremner wrote: > Soeren Sonnenburg wrote: > > >* Package name: coinor-bcp > > Version : 1.2.2 > > Upstream Author : Common Public License 1.0 > > I guess that is not right :) What is not? At least http://www.coin-or.org/projects/Bcp.xml states exactly this. > > Description : a framework for constructing parallel > branch-cut-price algorithms for mixed-integer linear programs > > Are you aware that BCP is in maintenance only mode? Lazlo Ladanyi, the > actual upstream author, told me that he will look at bug reports, but > there won't be any new feature releases. That is perfectly fine for me. Scientific software often is like this. When an algorithm works it is final :) > I'm not sure that means it should not be packaged for Debian, but I > thought you should know. As long as bugreports are dealt with it is fine for me. Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 signature.asc Description: This is a digitally signed message part
Bug#552246: ITP: dmg2img -- Tool for converting compress dmg files to hfsplus images
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg * Package name: dmg2img Version : 1.6.1 Upstream Author : Jean-Pierre Demailly * URL : http://vu1tur.eu.org/tools/ * License : GPL Programming Lang: C Description : Tool for converting compress dmg files to hfsplus images DMG2IMG is a tool which allows converting Apple compressed dmg archives to standard (hfsplus) image disk files. This tool handles zlib and bzip2 compressed dmg images. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#431233: ITP: python-cvxopt -- CVXOPT -- A Python Package for Convex Optimization
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg <[EMAIL PROTECTED]> * Package name: python-cvxopt Version : 0.8.2 Upstream Author : Joachim Dahl <[EMAIL PROTECTED]> and Lieven Vandenberghe <[EMAIL PROTECTED]> * URL : http://abel.ee.ucla.edu/cvxopt * License : GPL Programming Lang: C, Python Description : CVXOPT -- A Python Package for Convex Optimization CVXOPT is a Python package for convex optimization. It includes * Python classes for storing and manipulating dense and sparse matrices * an interface to most of the double-precision real and complex BLAS * an interface to the dense linear equation solvers and eigenvalue routines from LAPACK * interfaces to the sparse LU and Cholesky solvers from UMFPACK and CHOLMOD. * routines for solving convex optimization problems, an interface to the linear programming solver in GLPK, and interfaces to the linear and quadratic programming solvers in MOSEK * a modeling tool for specifying convex piecewise-linear optimization problems. -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-rc6-sonne (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#490204: ITP: torch5 -- A matlab-like environment for state-of-the-art machine learning algorithms.
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg <[EMAIL PROTECTED]> * Package name: torch5 Version : 5.1 Upstream Author : Ronan Collobert <[EMAIL PROTECTED]> et.al. * URL : http://torch5.sourceforge.net * License : BSD Programming Lang: C, Lua Description : A matlab-like environment for state-of-the-art machine learning algorithms. Torch5 provides a Matlab-like environment for state-of-the-art machine learning algorithms. It is easy to use and provides a very efficient implementation, thanks to an easy and fast scripting language (Lua) and a underlying C implementation. -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-rc9-sonne (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501267: ITP: coinor-cbc -- Coin-or branch-and-cut mixed integer programming solver
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg <[EMAIL PROTECTED]> * Package name: coinor-cbc Version : 2.2.1 Upstream Author : John J. Forrest <[EMAIL PROTECTED]> * URL : https://projects.coin-or.org/Cbc * License : CPL Programming Lang: C++ Description : Coin-or branch-and-cut mixed integer programming solver Cbc (Coin-or branch and cut) is an open-source mixed integer programming solver written in C++. It is primarily meant to be used as a callable library, but a basic, stand-alone executable version is also available. Mixed integer programming (MIP) is a generalization of linear programming (LP) and allows to find the minimum solution of objective functions depending linearly on variables, which are linearly constrained and additionally may have integrality constraints. Cbc is part of the larger COIN-OR initiative (Computational Infrastructure for Operations Research) and depends on the COIN-OR Clp linear programming solver for solving subproblems. Cbc works well as independent solver (reading files in the MPS format) and as a solver backend for AMPL. Project homepage: https://projects.coin-or.org/Cbc -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501277: ITP: coinor-dylp -- Linear programming solver using of the dynamic simplex algorithm
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg <[EMAIL PROTECTED]> * Package name: coinor-dylp Version : 1.4.4 Upstream Author : Lou Hafer <[EMAIL PROTECTED]> * URL : https://projects.coin-or.org/DyLP * License : CPL Programming Lang: C Description : Linear programming solver using of the dynamic simplex algorithm DyLp is designed to find solutions of constrained linear mathematical optimization problems. To this end, it is using a full implementation of the so called dynamic simplex algorithm for linear programming. DyLP is part of the larger COIN-OR initiative (Computational Infrastructure for Operations Research) and integrates well in the COIN Open Solver Interface (OSI), OsiDylp, which takes advantage of capabilities provided by COIN (e.g., enhanced input/output and constraint system preprocessing) and is recommended if you're working in a C++ environment. -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#509871: ITP: coinor-cgl -- Cut Generator Library, a library of cutting-plane generators
Package: wnpp
Severity: wishlist
Owner: Soeren Sonnenburg
* Package name: coinor-cgl
Version : 0.53.1
Upstream Author : Robin Lougee-Heimer and Francois
Margot
* URL : http://www.coin-or.org/projects/Cgl.xml
* License : CPL
Programming Lang: C++
Description : Cut Generator Library, a library of cutting-plane generators
The Cut Generation Library (Cgl) is an open collection of
cutting plane implementations ("cut generators") for use in teaching,
research, and applications.
Cgl is part of the larger COIN-OR initiative (Computational
Infrastructure for Operations Research) and can be used with other
COIN-OR packages that make use of cuts, such as the mixed-integer linear
programming solver Cbc.
-- System Information:
Debian Release: 5.0
APT prefers stable
APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (1,
'experimental')
Architecture: i386 (i686)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510969: ITP: makebootfat -- This utility creates a bootable FAT filesystem and populates it with files and boot tools.
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg * Package name: makebootfat Version : 1.4.0 Upstream Author : Andrea Mazzoleni * URL : http://advancemame.sourceforge.net/boot-readme.html * License : GPL version 2 or (at your option) any later version Programming Lang: C Description : Utility to creates a bootable FAT filesystem. makebootfat is a command line utility able to create bootable USB disks using the FAT filesystem and syslinux. makebootfat is the most advanced tool available able to make bootable USB disks. It's able to autodetect/partition/format/populate the USB disk in a single step without any user interaction. It's also able to create disk images which are compatibles with all the three standards USB-FDD, USB-HDD and USB-ZIP at the same time. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511899: ITP: coinor-csdp -- A software package for semidefinite programming
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg * Package name: coinor-csdp Version : 6.0.1 Upstream Author : Brian Borchers * URL : https://projects.coin-or.org/Csdp * License : CPL Programming Lang: C Description : A software package for semidefinite programming CSDP is a library of routines that implements a predictor corrector variant of the semidefinite programming algorithm of Helmberg, Rendl, Vanderbei, and Wolkowicz. The code runs in parallel on shared memory multi-processor systems, and it makes effective use of sparsity in the constraint matrices. . CSDP is part of the larger COIN-OR initiative (Computational Infrastructure for Operations Research). . This package contains the binaries and libraries. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#436069: ITP: dsdp -- DSDP implements an interior-point method for semidefinite programming.
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg <[EMAIL PROTECTED]> * Package name: dsdp Version : 5.8 Upstream Author : Steven J. Benson <[EMAIL PROTECTED]> and Yinyu Ye <[EMAIL PROTECTED]> * URL : http://www-unix.mcs.anl.gov/DSDP/ * License : BSD Programming Lang: C Description : DSDP implements an interior-point method for semidefinite programming. The DSDP software is a free open source implementation of an interior-point method for semidefinite programming. It provides primal and dual solutions, exploits low-rank structure and sparsity in the data, and has relatively low memory requirements for an interior-point method. It allows feasible and infeasible starting points and provides approximate certificates of infeasibility when no feasible solution exists. The dual-scaling algorithm implemented in this package has a convergence proof and worst-case polynomial complexity under mild assumptions on the data.Furthermore, the solver offers scalable parallel performance for large problems and a well documented interface. Some of the most popular applications of semidefinite programming and linear matrix inequalities (LMI) are model control, truss topology design, and semidefinite relaxations of combinatorial and global optimization problems. -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23-rc2-sonne (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Short report on Debian at UseR! 2007 conference at Iowa State Univ.
On Tue, 2007-08-14 at 21:26 -0500, Dirk Eddelbuettel wrote: Hi Dirk, > UseR! 2007 at Iowa State University, Ames, IA, August 8-10, 2007 [...] > II. Paper / presentation on 2000 new Debian packages -- > "Would you like 2000 new Debian packages with that?" > > > Something we hadn't really reported back to Debian is the relative success > and current status of the 'pkg-bioc' project at Alioth. [...] > The big news is that we can now build most of the around two thousand source > packages [ around 900 from CRAN and 1100 from BioC, I concentrate more on > CRAN; Steffen focusses more on BioC, and David does everything ] for R from > the CRAN and BioConductor archives. That's what our paper that I presented > was about, as well as an earlier presentation / paper Steffen gave two months > ago in Italy [1]. [...] > The big question is what to do with these 2000 packages. The process is > still too manual and fragile to be called 'production class'. Eventually > this should move somewhere -- either CRAN itself, or, less likely, be part of > Debian. I do say less likely here because I don't hink that two-thousand > machine-generated packages could reach the Debian QA standards. They are > also, as a large class, too esoteric. CRAN, on the other hand, builds > binaries for Windows, so this could be a better fit. Someone suggested > R-Forge -- which is a rather recent 'SF / Alioth for R' based on Debian's > gforge packages. Also, one question had to do with how to avoid 'waits' for > new packages -- people wouldn't want to wait for packages to reach testing > when this can take months. So a distinct backport service may be the best > option. Manpower and mirrors may be the crux. First of all I really like your efforts of debianizing R packages. I think debian is currently well suited to be used in ``science'' but yes there is a lot more one can do. I was indeed missing the nowadays quite standard bioconductor packages when I had to do some microarray analysis. Regarding machine generated debian packages it is a first step and probably the only way given this amount of R-packages. I also don't think they could be in debian. This especially holds for the more esoteric/brand new research/unstable R-packes. However I would want to see the more mature bioconductor packages in debian... Thinking about it, *I* think it would be best to proceed in a similar way as the texlive people, i.e. have debian packages for all major categories which include the major mature R-packages of that category r-bioc-base r-bioc-microarray r-bioc-annotation r-bioc-statistics r-bioc-graphs r-bioc-technology The remaining R-packages could be packaged as single debian-packages as you proposed to do it and maybe even hosted a bioconductor.org? In case a package seems more mature it can enter any of the categories and one could add proper conflicts/replaces as an upgrade path. BTW, this also solves the `not-up-to-date issue', as more mature packages don't require weekly/monthly updates. Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 signature.asc Description: This is a digitally signed message part
Re: Short report on Debian at UseR! 2007 conference at Iowa State Univ.
On Sat, 2007-08-18 at 14:44 +0200, Steffen Moeller wrote: > On Saturday 18 August 2007 12:36:41 Soeren Sonnenburg wrote: > > On Tue, 2007-08-14 at 21:26 -0500, Dirk Eddelbuettel wrote: [...] > > esoteric/brand new research/unstable R-packes. However I would want to > > see the more mature bioconductor packages in debian... > > Again, I think we can agree on this, OK great. > > Thinking about it, *I* think it would be best to proceed in a similar > > way as the texlive people, i.e. have debian packages for all major > > categories which include the major mature R-packages of that category > > > > r-bioc-base > > r-bioc-microarray > > r-bioc-annotation > > r-bioc-statistics > > r-bioc-graphs > > r-bioc-technology > > Hm. I kind of like it, though I rather see this implemented as virtual > packages that come rather naturally from the Biotags that BioConductor > assigns to itself. Well I don't know how much should be split up. But I guess this depends also on the number of debian ready packages we are talking about? The next problem is I don't really know how to judge whether a package is 'ready for debian' or not. One could of course start with the core/essential packages and then slowly increase the package number. Robert Gentlemen suggested to start with the packages in BioCLite, which is affy affydata affyPLM annaffy annotate Biobase Biostrings DynDoc gcrma genefilter geneplotter hgu95av2 limma marray matchprobes multtest reposTools ROC vsn xtable. What do yo think? > > The remaining R-packages could be packaged as single debian-packages as > > you proposed to do it and maybe even hosted a bioconductor.org? In case > > a package seems more mature it can enter any of the categories and one > > could add proper conflicts/replaces as an upgrade path. BTW, this also > > solves the `not-up-to-date issue', as more mature packages don't require > > weekly/monthly updates. > > Hm. I am not sure. The problem with hiding it all is that we also do not use > apt-cache search to find the proper BioC packages in the first place. We hide > this information away in the superpackages. It also impedes the communication > of Debian users with R developers and the assignment of Bugs. Yes you are right, that may be problematic. If we don't talk about hundreds of packages it is probably also OK... > Btw, wouldn't you be interested to join our effort? I'd offer sponsoring > SHOGUN for Debian as a compensation :-) Indeed I am interested, but I don't have any experience with debian+R other than from packaging shogun-r. So I wonder whether for there exist general cdbs helpers for r & bioc. Also I am still confused that r-base-dev contains no header files (they are all in r-base-core) and that all the libR.so has no SO name (at least objdump -p /usr/lib/R/lib/libR.so | grep SO does not report anything). So from my understanding the only build dependency is r-base-core, but how does one ensure smooth upgrades when switching to new (potentially incompatible) R releases? Regarding shogun, Torsten Werner is already sponsoring the uploads - so don't worry :-) > Many greetings from the fairly sunny Baltic Sea to my former home Berlin Actually I am planning to be at the baltic sea next weekend to take part in the 'vilmschwimmen'! Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 signature.asc Description: This is a digitally signed message part
Re: Short report on Debian at UseR! 2007 conference at Iowa State Univ.
On Sun, 2007-08-19 at 02:10 +0200, Steffen Moeller wrote:
> On Saturday 18 August 2007 22:45:56 Soeren Sonnenburg wrote:
> > On Sat, 2007-08-18 at 14:44 +0200, Steffen Moeller wrote:
> > > On Saturday 18 August 2007 12:36:41 Soeren Sonnenburg wrote:
> [...]
> > Well I don't know how much should be split up. But I guess this depends
> > also on the number of debian ready packages we are talking about? The
> > next problem is I don't really know how to judge whether a package is
> > 'ready for debian' or not.
> >
> > One could of course start with the core/essential packages and then
> > slowly increase the package number. Robert Gentlemen suggested to start
> > with the packages in BioCLite, which is
> >
> > affy affydata affyPLM annaffy annotate Biobase Biostrings DynDoc gcrma
> > genefilter geneplotter hgu95av2 limma marray matchprobes multtest
> > reposTools ROC vsn xtable.
> >
> > What do yo think?
>
> For the packages you listed above you do not really need our Debian gimmicks
> for. It is easily installed with a few commands of R. But yes, except that I
> would rather go for hgu133 they should all be in, ok the example data needs
> the hgu95. I think I am aiming at affylmGUI and RBGL and such that are
> standard but do not compile too easily for novices since they require to
> install some extra bits. This way we (I include you here :-) ) can show off
> with how cool Debian is a bit more.
Well having the core packages in (no matter how difficult it is to
install them manually) is always a good idea... it would be great if you
(or someone else with svn write access) could create a file that
contains the packages one could consider base and maybe start with the
highlights of the other
(microarray,annotation,statistics,graphs,technology) packages.
Something like debian-main/{base,microarray,...} etc.
> > > > The remaining R-packages could be packaged as single debian-packages as
> > > > you proposed to do it and maybe even hosted a bioconductor.org? In case
> > > > a package seems more mature it can enter any of the categories and one
> > > > could add proper conflicts/replaces as an upgrade path. BTW, this also
> > > > solves the `not-up-to-date issue', as more mature packages don't
> > > > require weekly/monthly updates.
> > >
> > > Hm. I am not sure. The problem with hiding it all is that we also do not
> > > use apt-cache search to find the proper BioC packages in the first place.
> > > We hide this information away in the superpackages. It also impedes the
> > > communication of Debian users with R developers and the assignment of
> > > Bugs.
> >
> > Yes you are right, that may be problematic. If we don't talk about
> > hundreds of packages it is probably also OK...
>
> Fine. I personally think we are at about 25 packages in BioC that I'd
> consider
> part of core use cases. We did not have discussed this yet. The packaging is
> automated. Some more pretty printing should probably be done before we
> move bits into Debian main. Technically the packages are functional. Updates
> are happening more frequently than you may think, actually, I would not want
> to do it manually.
If one can create high quality packages in a automated way - fine why
not. However I think in the end it will be semi-automatic (as some final
checking is needed...)...
> > > Btw, wouldn't you be interested to join our effort? I'd offer sponsoring
> > > SHOGUN for Debian as a compensation :-)
> >
> > Indeed I am interested, but I don't have any experience with debian+R
> > other than from packaging shogun-r. So I wonder whether for there exist
> > general cdbs helpers for r & bioc.
>
> Well, check out http://wiki.debian.org/AliothPkgBioc. For more detailed
> R-packaging related issues Dirk <[EMAIL PROTECTED]> is your man.
OK.
Soeren.
--
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.
signature.asc
Description: This is a digitally signed message part
Re: Short report on Debian at UseR! 2007 conference at Iowa State Univ.
On Sun, 2007-08-19 at 20:15 -0500, Dirk Eddelbuettel wrote: > Hi Soeren, Hi Steffen Hi Dirk, [lots of agreement that would want to have more high quality R packages] > | > Btw, wouldn't you be interested to join our effort? I'd offer sponsoring > | > SHOGUN for Debian as a compensation :-) > | > | Indeed I am interested, but I don't have any experience with debian+R > | other than from packaging shogun-r. So I wonder whether for there exist > > Look at any of my existing r-cran-* packages, and you see that they use a > _very_ formulaic approach which is even distilled into a one-line > debian/rules files, thanks to a) the standardization at the R package level > (that, interestingly enough, is inspired by Debian) and b) the magic powers > of cdbs which we use in the file /usr/share/R/debian/r-cran.mk --- which does > all the actual package building and installing and provides the code for the > one-liner calling it. So the key really is that Debian Policy is embedded in > the is r-cran.mk file. The other debian/* files are standard. OK, I just had a look at r-cran-fseries, it is indeed a one-liner as you said. So creating debian packages from cran-r-packages seems easy. What I still don't understand is how you make sure that a package remains compatible with future r-versions (I could not find any indication that this is done via dependencies/conflicts). Taking the r-cran-fseries package as an example: $ dpkg -L r-cran-fseries | grep .so$ /usr/lib/R/site-library/fSeries/libs/fSeries.so $ ldd /usr/lib/R/site-library/fSeries/libs/fSeries.so linux-gate.so.1 => (0xb7f07000) libRlapack.so => /usr/lib/R/lib/libRlapack.so (0xb7873000) libblas.so.3 => /usr/lib/atlas/sse2/libblas.so.3 (0xb7295000) libgfortran.so.2 => /usr/lib/libgfortran.so.2 (0xb71fe000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb71d9000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb71ce000) libR.so => /usr/lib/R/lib/libR.so (0xb6ef3000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6dab000) libg2c.so.0 => /usr/lib/libg2c.so.0 (0xb6d83000) /lib/ld-linux.so.2 (0x8000) libreadline.so.5 => /lib/libreadline.so.5 (0xb6d51000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb6d2c000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb6d1c000) libz.so.1 => /usr/lib/libz.so.1 (0xb6d07000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6d03000) libncurses.so.5 => /usr/lib/libncurses.so.5 (0xb6cc2000) From that one can see that fSeries.so is dynamically linked to /usr/lib/R/lib/libR.so ... However libR.so has no SO name and if incompatible changes happen in R, that package will just not work until it is recompiled... I think the solution other people are using is to explicitly encode the version in the .so file, e.g. libR-2.5.so (setting the sonmae to libR-2.5.so) and including the version name in the package name, i.e. r-base-core version 2.5 => package r-base-core2.5... > | general cdbs helpers for r & bioc. Also I am still confused that > | r-base-dev contains no header files (they are all in r-base-core) and > > Well, Doug chose the name years ago; r-base-dev is meant to provide all > dependencies so that R users can do call install.packages() from R and not > fall over because headers and libs such as readline or curses are missing; it > is not a -dev package in the normal sense (which doesn't work for R as R is > not a library you compile against). I don't understand... A R user that just wants to use R as is (i.e. not compile/install new packages) should not need to install header files, but all the header files are in r-base-core. So I still don't see why the files necessary to build R extensions (like header files) are not in r-base-dev? > | that all the libR.so has no SO name (at least > | objdump -p /usr/lib/R/lib/libR.so | grep SO does not report anything). > > Because ld.so does not see /usr/lib/R/lib as it doesn't need to know about it > (as one typically does not compile against it). [ You have a harder job with You are right for many cran packages that are written in vanilla R (contain only .R files...), but for cran-packages containing C-extensions that is a problem (I remember having installed bioC locally and having it to recompile when a newer R version entered debian...). > shogun and a better example for you would be Ggobi and r-cran-rggobi so look > there instead of comparing with random CRAN package that are called into R -- > I believe you call R into Shogun so the flow is different requiring a > different setup. ] r-cran-ggobi only depends on r-base-core (>= 2.5.0) ... so I don't see anything providing a smooth upgrade path... > | So from my understanding the only build dependency is r-base-core, but > | how does one ensure smooth upgrades when switching to new (potentially > | incompatible) R releases? > > I don't follow exactly what the questions is. Maybe take this to private > mail? Yes I am sorry, we
Re: Building packages three times in a row
On Mon, 2007-09-10 at 22:34 +0200, Patrick Winnertz wrote: > Hi, [...] > Furthermore we detect some issues with different package content (compared > to the first build) after the second and third build. This bugs will have > Severity: Serious. Hmmhh, what do you do about programs etc that encode the build-time in the binary? I mean they obviously will change between builds? Soeren -- Sometimes, there's a moment as you're waking, when you become aware of the real world around you, but you're still dreaming. signature.asc Description: This is a digitally signed message part
Re: About dpkg-shlibdeps checks
On Fri, 2007-11-23 at 10:39 +0100, Raphael Hertzog wrote: > Hello, Hello, > as announced in > http://lists.debian.org/debian-devel-announce/2007/09/msg4.html the > new dpkg-shlibdeps is stricter in what it accepts and will fail when it > can't find dependency information for a library that is used by an > executable or a public library (a public library is defined as a library > which has a SONAME, see the output of "objdump -p"). > > Failures look like this: > dpkg-shlibdeps: failure: No dependency information found for > libkdeinit4_kfmclient.so (used by debian/konqueror/usr/bin/kfmclient). > > It might also look like this: > dpkg-shlibdeps: failure: couldn't find library libhpip.so.0 (note: only > packages with 'shlibs' files are looked into). I am exactly seeing this for 'shogun-octave' and I ask for your advise how to fix things. octave2.9 contains a couple of .so files in /usr/lib/octave-2.9.17, when building extensions to octave (as with shogun-octave), the resulting 'sg.oct' file is linked to some of the .so files in that directory, which of course is not available in ld.so.conf or the like, so dpkg-shlibdeps fails to find the libraries, e.g. liboctinterp.so. Also according to objdump also only has SONAME liboctinterp.so. As octave handles loading extensions itself, --rpath or the like are not normally needed. But what is the intended way of fixing things with the newer dpkg-shlibdeps ? Adding --rpath ? $ dpkg-shlibdeps build-octave/sg.oct dpkg-shlibdeps: failure: couldn't find library liboctinterp.so (note: only packages with 'shlibs' files are looked into). $ LD_LIBRARY_PATH=/usr/lib/octave-2.9.17/ dpkg-shlibdeps -v build-octave/sg.oct Scanning build-octave/sg.oct (for Depends field) Library liboctinterp.so found in /usr/lib/octave-2.9.17/liboctinterp.so Library libcruft.so found in /usr/lib/octave-2.9.17/libcruft.so Library liboctave.so found in /usr/lib/octave-2.9.17/liboctave.so Library liblapack.so.3 found in /usr/lib/liblapack.so.3 Library libblas.so.3 found in /usr/lib/libblas.so.3 Library libstdc++.so.6 found in /usr/lib/libstdc++.so.6 Library libm.so.6 found in /lib/libm.so.6 Library libgcc_s.so.1 found in /lib/libgcc_s.so.1 Library libpthread.so.0 found in /lib/libpthread.so.0 Library libc.so.6 found in /lib/libc.so.6 Looking up shlibs dependency of libstdc++.so.6 provided by 'libstdc++6' Found libstdc++6 (>= 4.2.1) in /var/lib/dpkg/info/libstdc++6.shlibs Looking up shlibs dependency of libc.so.6 provided by 'libc6' Found libc6 (>= 2.6.1-1) in /var/lib/dpkg/info/libc6.shlibs Looking up shlibs dependency of liblapack.so.3 provided by 'lapack3' Found atlas3-base | lapack3 | liblapack.so.3 in /var/lib/dpkg/info/lapack3.shlibs Looking up shlibs dependency of libblas.so.3 provided by 'refblas3' Found atlas3-base | refblas3 | libblas.so.3 in /var/lib/dpkg/info/refblas3.shlibs Looking up shlibs dependency of libpthread.so.0 provided by 'libc6' Found libc6 (>= 2.6.1-1) in /var/lib/dpkg/info/libc6.shlibs Looking up shlibs dependency of libm.so.6 provided by 'libc6' Found libc6 (>= 2.6.1-1) in /var/lib/dpkg/info/libc6.shlibs Looking up shlibs dependency of liboctinterp.so provided by 'octave2.9' dpkg-shlibdeps: warning: Can't extract name and version from library name `liboctinterp.so' dpkg-shlibdeps: warning: Can't extract name and version from library name `liboctinterp.so' Found nothing dpkg-shlibdeps: failure: No dependency information found for liboctinterp.so (used by build-octave/sg.oct). I am expecting similar problems with R extensions ... where libR.so is in /usr/lib/R/lib/libR.so and not even has a SONAME ... Any ideas? Thanks, Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 signature.asc Description: This is a digitally signed message part
Re: About dpkg-shlibdeps checks
On Sat, 2007-11-24 at 10:07 +0100, Raphael Hertzog wrote: > On Sat, 24 Nov 2007, Soeren Sonnenburg wrote: > > But what is the intended way of fixing things with the newer > > dpkg-shlibdeps ? Adding --rpath ? > > Helping dpkg-shlibdeps with LD_LIBRARY_PATH is the right thing as you did > below... (option -l for dh_shlibdeps) [...] > > I am expecting similar problems with R extensions ... where libR.so is > > in /usr/lib/R/lib/libR.so and not even has a SONAME ... > > Wihtout SONAME for a private library is the right thing... no reason to > expect more problems. :-) Thank you very much for your help. Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 signature.asc Description: This is a digitally signed message part
Bug#522017: ITP: jblas -- jblas is a fast linear algebra library for Java
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg * Package name: jblas Version : 0.1 Upstream Author : Mikio Braun mikiocs.tu-berlin.de * URL : https://ml01.zrz.tu-berlin.de/trac/jblas/ * License : BSD Programming Lang: Java Description : jblas is a fast linear algebra library for Java jblas is a fast linear algebra library for Java. jblas is based on BLAS and LAPACK, the de-facto industry standard for matrix computations, and uses state-of-the-art implementations like ATLAS for all its computational routines, making jBLAS very fast. jblas can is essentially a light-wight wrapper around the BLAS and LAPACK routines. These packages have originated in the Fortran community which explains their archaic API. On the other hand modern implementations are hard to beat performance wise. jblas aims to make this functionality available to Java programmers such that they do not have to worry about writing JNI interfaces and calling conventions of Fortran code. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
