Bug#963593: ITP: annexremote -- abstraction for git-annex special remote implementations
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: annexremote Version : 1.4.3 Upstream Author : Silvio Ankermann * URL : https://github.com/Lykos153/AnnexRemote * License : GPL3 Programming Lang: Python Description : abstraction for git-annex special remote implementations This package is needed for packaging the 0.13 release of the datalad package. Moreover, it is also used for other special remote implementations, such as - https://github.com/Lykos153/git-annex-remote-googledrive - https://github.com/CONP-PCNO/git-annex-remote-globus It is a simple package with no dependencies other than Python. I am not aware of an alternative. I am using it regularly. I plan to produce a package that is compliant with the Debian Python Modules Team and have it be team maintained on salsa.
Bug#861327: ITP: fsleyes -- feature-rich viewer for volumetric images
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: fsleyes Version : 0.10.1 Upstream Author : Paul McCarthy * URL : https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/ * License : Apache-2 Programming Lang: Python Description : feature-rich viewer for volumetric images This is the successor of 'fslview' (currently in Debian, but stuck with Qt4, and needs to be removed). This new viewer is a full replacement, written in pure Python, using wx. It requires a number of dependencies to become available in Debian first. Namely, Python packages: fslpy, props (to be renamed to fsleyes-props), and indexed_gzip. The latter is presently in NEW. The rest will follow suit.
Bug#860084: ITP: libxdf -- static C++ library for loading XDF (multi-channel stream format) files
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: libxdf Version : 0.93 Upstream Author : Yida Lin (?) * URL : https://github.com/Yida-Lin/libxdf * License : GPL3 Programming Lang: C++ Description : static C++ library for loading XDF (multi-channel stream format) files Libxdf is a cross-platform C++ library for loading multimodal, multi-rate signals stored in XDF files. Libxdf is a core component of bio-signal viewing application SigViewer. It can also be integrated into other C++ applications. The last release is just a few days old. This is a new dependency of the sigviewer package that needs an update to version 0.6 (#860083) This package will be maintained by the NeuroDebian team. At the moment upstream does not support building a shared library.
Bug#835493: ITP: indexed-gzip -- fast random access of gzip files in Python
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: indexed-gzip Version : 0.1 Upstream Author : Paul D McCarthy * URL : https://github.com/pauldmccarthy/indexed_gzip * License : BSDish https://opensource.org/licenses/zlib-license.php Programming Lang: Python Description : fast random access of gzip files in Python [from the README] The indexed_gzip project is a Python extension which aims to provide a drop-in replacement for the built-in Python gzip.GzipFile class, the IndexedGzipFile. The standard gzip.GzipFile class exposes a random access-like interface (via its seek and read methods), but every time you seek to a new point in the uncompressed data stream, the GzipFile instance has to start decompressing from the beginning of the file, until it reaches the requested location. An IndexedGzipFile instance gets around this performance limitation by building an index, which contains seek points, mappings between corresponding locations in the compressed and uncompressed data streams. Each seek point is accompanied by a chunk (32KB) of uncompressed data which is used to initialise the decompression algorithm, allowing us to start reading from any seek point. If the index is built with a seek point spacing of 1MB, we only have to decompress (on average) 512KB of data to read from any location in the file. Performance comparison: https://github.com/pauldmccarthy/indexed_gzip#performance This needs to be packaged as a dependency of a replacement of the `fslview` (https://packages.debian.org/sid/fslview) package, which will not make it into the next release due to its dependencies on obsolete code (Qt4, ...). This will be maintained by the NeuroDebian team.
Bug#798040: ITP: dcmstack -- DICOM to Nifti conversion
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: dcmstack Version : 0.6.2 Upstream Author : Brendan Moloney * URL : https://github.com/moloney/dcmstack * License : MIT Programming Lang: Python Description : DICOM to Nifti conversion DICOM to Nifti conversion with the added ability to extract and summarize meta data from the source DICOMs. The meta data can be injected into a Nifti header extension or written out as a JSON formatted text file. . This package provides the Python package, command line tools (dcmstack, and nitool), as well as the documentation in HTML format. This package is necessary for creating datsasets that are fully compliant with and utilize all features of the BRAIN IMAGING DATA STRUCTURE standard: http://bids.neuroimaging.io This is a new community norm for open-data in neuroimaging research. This package will be maintained by the NeuroDebian team.
Bug#792279: ITP: nilearn -- fast and easy statistical learning on neuroimaging data
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: nilearn Version : 0.1.3 Upstream Author : Gael Varoquaux * URL : https://github.com/nilearn/nilearn * License : BSD Programming Lang: Python Description : fast and easy statistical learning on neuroimaging data This Python module leverages the scikit-learn toolbox for multivariate statistics with applications such as predictive modelling, classification, decoding, or connectivity analysis. As such, it extends the reach of sklearn (python-sklearn) into the neuroimaging domain. The package will be maintained by the NeuroDebian team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150713140914.21534.76015.reportbug@meiner
Re: so long and thanks for all the fish
On Fri, Nov 7, 2014 at 10:04 PM, Joey Hess wrote: > If I have one regret from my 18 years in Debian, it's that when the > Debian constitution was originally proposed, despite seeing it as > dubious, I neglected to speak out against it. It's clear to me > now that it's a toxic document, that has slowly but surely led Debian > in very unhealthy directions. > We're fucked! (in my perception of this language there is no better way to say this). I know that no person is irreplaceable, but for as long as I know Debian, I have experienced Joey as a voice of reason -- seemingly indistractable from technical matters, and one of the giants whose proverbial shoulders are carrying this project. If the trajectory towards a more inclusive project does not have enough room to accommodate people like him, I doubt that the price we need to pay for the achieving this goal is worth it. Michael
Bug#703946: general: OS freezes, but mouse and ping keeps working
On Mon, Mar 25, 2013 at 11:34:57PM -0600, Gunnar Wolf wrote: > Felipe dijo [Tue, Mar 26, 2013 at 12:26:59AM -0300]: > > Another important thing: when freezed, the notebook keeps responding to > > pings. There's no packages lost. > > This can be related to an unstability problem I saw using the non-free > nvidia drivers. We have three hardware-identical machines (Lenovo Think Centre) at work, all three running a more or less up-to-date wheezy -- all three Intel graphics.. Two of them running GNOME-shell, one KDE -- only the GNOME machines show this kind of behavior. Whenever I had a chance to get on the console (only the X-session froze) I wasn't able to figure out what component was responsible: no signififcant CPU-load, no obvious problems -- hard to figure out who is is at fault. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130326184214.GA13071@meiner
Re: Debian not suitable for SSD due to apt/dpkg?
On Mon, Oct 01, 2012 at 10:23:32AM +0800, Chow Loong Jin wrote: > On 30/09/2012 18:49, Frank Bauer wrote: > > Why not, my computer upgrade cycles are about 6-8 years and the > > computer won't be idling all the time - especially considering modern > > desktop environments running whole database engines to store > > config/meta data. > > > > Is writing of 160GB/day realistic? Hopefuly not, but see my apt > > measurements below. > > > > There is also something called SSD write amplification - the erase > > blocks on the device are often larger than your normal filesystem > > blocks, which might lead to up to 10x data actually writen to SSD, > > i.e. down to 1.3years of overwrites in the extreme case. > > Have you done any actual calculation on this? A quick Google search on SSD > write > cycles shows more articles debunking this theory than supporting it. Just a data point: I'm on an Intel SSD (120GB) since Aug 2009 -- running Debian testing all the time. I do not upgrade daily, but often. I have _not_ done any of the optimizations mentioned on the wiki. I have on average approx 15GB free on the drive. Obviously, I ran a kernel <3.2 for most of the time. I do lots of compiling on this SSD. So far, I have nothing to complain about and consider this drive as fairly reliable. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121001131246.GD11280@meiner
Re: Improving our response to "duplicate" packages in Debian
On Fri, Jun 29, 2012 at 09:24:25AM +0200, Josselin Mouette wrote: > Le jeudi 28 juin 2012 à 16:42 +0200, Guus Sliepen a écrit : > > - Don't immediately start complaining to the submitter of the ITP. Just let > > the submitter devote his/her energy to packaging. > > I don’t think it is worthwile to let people devote their energy to > packaging pet applications that will disappear in 2 years time when they > find another one. I think this is approaching the problem from the wrong end. Instead of preserving the status quo and asking oracles to predict the future we should have better means of _removing_ software that has proven to be inferior of an equivalent alternative in Debian. The advantage is that we have objective criteria to be able to make an informed decision -- not a guess based on heuristics and opinion. The disadvantage is that it imposes work on other volunteers -- but see below... > We really need to find better ways to involve new users in core teams, > and that means removing from our collective consciousness the idea that > you come in Debian to package your new favorite piece of software. I have to disagree -- and I would even make the bold claim that "packaging your favorite piece of software" is a very common (if not the most common) entry point for _people_ into Debian. One could see the "pet projects" as the price we need to pay to make participation in Debian very attractive (not even talking about the role that "pet projects" play in the context of perceived universality of Debian) . Getting people to participate in Debian, make them become confident and experienced is IMHO a requirement for increasing the chance of anyone joining core teams. If it would work otherwise, we could just post a job-ad on LinkedIn: "Debian security team is looking for skilled developers". Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120630064107.GA20814@meiner
Re: bitbucket is lock in? (was: Re: Packaging on GitHub ?)
On Tue, May 29, 2012 at 09:01:24PM +0200, Martin Bagge / brother wrote: > On Tue, 29 May 2012, Brian May wrote: > > >I don't see the problem, github is just a hosting provider. Unlike, > >say Bitkeeper, you are free to make git clones anywhere, entirely with > >open source software, and are in no way locked down to using github. > > Can you elaborate on the bitbucket case there? How am I not allowed > to do a git clone from my git repo on bitbucket account? Where the > same just works in github? He was talking about BitKEEPER not BitBUCKET. Cheers, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120529192603.GA17658@meiner
Re: Plans to (re-)include cgroups in wheezy?
On Thu, Apr 26, 2012 at 04:28:03PM -0400, Jon Bernard wrote: > If Condor is still reasonably usable without support for cgroups via > libcgroup, > I would go that route -- at least in the short term. Several of libcgroup's > problems are fairly complex, I'm doing all that I can given the time that I > have > to get things sorted. If anyone has input or would like to contribute, please > do so. I'm more that willing to collaborate. Yes, Condor is functional without cgroups. It just can't use cgroups anymore. I'll drop this dependency temporarily, and reenable it whenever the dust has settled. If you can offer a list of things that need to be done in order to get cgroups back into wheezy, I might be able to identify some aspects that I could help with -- even without any practical cgroups experience so far. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120427103047.GB8529@meiner
Plans to (re-)include cgroups in wheezy?
Hi, I'm trying to get Condor [0] included into wheezy. I just now realized that the cgroups package [1] which condor currently depends on is in a rather bad shape (numerous bugs, only little maintainer response, last upload a year ago, one upstream release behind). Looking at HOWTOs like [2] it seems that the overall setup of cgroups in Debian is suboptimal -- but I'm not really in the position to judge, as I have no personal experience with cgroups. However, I'd like to know if there is anybody (maintainer CC'ed) working on getting cgroups in shape and have it in wheezy (Squeeze came with cgroups support BTW). If there is not such effort, I'll probably disable Condor's cgroups features for now, as it would take me too long to get up to speed with cgroups before the upcoming freeze. Cheers, Michael [0] http://packages.debian.org.condor [1] http://packages.qa.debian.org/libc/libcgroup.html [2] http://hydra.geht.net/tino/english/faq/debian/squeeze/cgroups/ -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120426130054.GA25082@meiner
Bug#664022: ITP: lazyarray -- Python module providing a NumPy-compatible lazily-evaluated array
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: lazyarray Version : 0.1 Upstream Author : Andrew P. Davison * URL : http://bitbucket.org/apdavison/lazyarray/ * License : 3-clause-BSD Programming Lang: Python Description : Python module providing a NumPy-compatible lazily-evaluated array The 'larray' class is a NumPy-compatible numerical array where operations on the array (potentially including array construction) are not performed immediately, but are delayed until evaluation is specifically requested. Evaluation of only parts of the array is also possible. Consequently, use of an 'larray' can potentially save considerable computation time and memory in cases where arrays are used conditionally, or only parts of an array are used (for example in distributed computation, in which each MPI node operates on a subset of the elements of the array). This is basically a single file package with a number of tests (98% coverage). This package will be needed for a new release of python-pynn. Debian has 0.7.0 right now, latest upstream is 0.7.2 http://packages.debian.org/sid/python-pynn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120314222451.25560.86118.reportbug@meiner
Re: Quilt patch for patching things in the debian folder
On Thu, Mar 08, 2012 at 07:52:11AM +0100, Reinhard Tartler wrote: > On Wed, Mar 7, 2012 at 2:32 PM, Michael Hanke wrote: > > On Wed, Mar 07, 2012 at 12:52:53PM +0100, Andreas Tille wrote: > >> Was you aware about dpkg-vendor at the time of writing this script? > > > > Yes, but AFAIK it was neither available in the Debian stable release at > > that time, nor in the respective Ubuntu LTS -- which are our primary > > backporting targets. > > You know, such things tend to change. FYI, dpkg-vendor is included in > both lucid and squeeze. Fortunately that is true -- back then the names where lenny and hardy though ;-) Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120308071259.GB19878@meiner
Re: Quilt patch for patching things in the debian folder
On Wed, Mar 07, 2012 at 12:52:53PM +0100, Andreas Tille wrote: > On Wed, Mar 07, 2012 at 11:17:44AM +0100, Michael Hanke wrote: > > > > Not exactly the same thing, but for backporting for various releases we > > (NeuroDebian) quite often have to adjust the Debian packaging itself, > > but still want to have everything stored in a single source package. > > And we do store these patches in debian/patches. However, they are not > > applied at build-time. Instead we have a backporting script that > > generates a new source package with the changes applied (using dedicated > > per-release series files). I submitted that script as a potential > > addition to the devscripts package some time ago. > > Was you aware about dpkg-vendor at the time of writing this script? Yes, but AFAIK it was neither available in the Debian stable release at that time, nor in the respective Ubuntu LTS -- which are our primary backporting targets. Anyway, I think that most of the stuff backport-dsc does could be done with dpkg-vendor. However, I still somewhat like the idea of having a fairly simple, static source package as a result of a backporting run, instead of implementing the switching logic with build-time control/changelog manipulation inside a once-and-for-all packaging. But we are clearly targeting the backporting business and not so much a derivative workflow. Needless to mention that both approaches could be combined easily. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120307133252.GA15298@meiner
Re: Quilt patch for patching things in the debian folder
On Wed, Mar 07, 2012 at 10:52:57AM +0100, Raphael Hertzog wrote: > It's already caught by lintian as an error: > http://lintian.debian.org/tags/patch-modifying-debian-files.html > > In any case it's definitely not a good idea and it breaks when you use 3.0 > (quilt). > > I don't know of any valid usage of such a feature. Even when derivatives > want different packaging rules, we have a proper interface for this > and it's dpkg-vendor. Not exactly the same thing, but for backporting for various releases we (NeuroDebian) quite often have to adjust the Debian packaging itself, but still want to have everything stored in a single source package. And we do store these patches in debian/patches. However, they are not applied at build-time. Instead we have a backporting script that generates a new source package with the changes applied (using dedicated per-release series files). I submitted that script as a potential addition to the devscripts package some time ago. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120307101744.GB1649@meiner
Bug#659691: ITP: neo -- IO library for electrophysiological data formats in Python
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: neo Version : 0.2 Upstream Author : Samuel Garcia, Pierre Yger, Luc Estabanez, Andrew Davison, Yury V. Zaytsev * URL : http://neuralensemble.org/trac/neo * License : BSD Programming Lang: Python Description : IO library for electrophysiological data formats in Python NEO stands for Neural Ensemble Objects and is a project to provide common class names and concepts for dealing with electro-physiological (in vivo and/or simulated) data with the aim of getting OpenElectrophy, NeuroTools, G-node and maybe other projects with similar goals more close together. . In particular Neo provides: . * a set a classes with precise definitions * an IO module that offer a simple API that fit many formats * documentation. * a set of examples like a format convertor -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120213092356.25026.20287.reportbug@meiner
Bug#659282: ITP: eeglab -- electrophysiological data analysis
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: eeglab Version : 11.0.0.0 Upstream Author : Scott Makeig, Arnaud Delorme and others * URL : http://sccn.ucsd.edu/eeglab * License : GPL-2+ Programming Lang: Matlab (Octave) Description : electrophysiological data analysis This is sofwware for processing continuous or event-related EEG or other physiological data. It is designed for use by both novice and expert users. In normal use, the EEGLAB graphic interface calls graphic functions via pop-up function windows. The EEGLAB history mechanism can save the resulting calls to disk for later incorporation into scripts. . This package provides EEGLAB to be used with Matlab. Note that this package depends on Matlab -- a commercial software that needs to be obtained and installed separately. Notes - At this point this package basically only works with Matlab (hence aiming at contrib). However, there is hope to enable an interesting subset of non-GUI functionality to work with Octave. Upstream provides a substantial unittest suite to help such an effort. Until this can be achieved, this package, at least, strengthens Debian's utility for electrophysiological data analysis, as eeglab is one of the most popular tools in this field. A number of source-less extensions from 3rd parties have been stripped for DFSG-compliance. -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120209192003.GA3323@meiner
Re: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries
On Jan 13, 2012 3:59 PM, "Thomas Goirand" wrote: > > On 01/13/2012 10:03 PM, Josselin Mouette wrote: > > I am surprised NX is even considered for WAN usage. Our in-house tests > > showed that NX has a noticeable usability impact as soon as the latency > > reaches 10ms, while the figure goes up to 30ms for VNC - which is > > currently the only serious solution for WAN links. > > > Then maybe you should get out of your house! :) > > Seriously, have you ever tried using VNC across continents, with a > *very* slow link? It's simply too slow, it takes ages to display a simple > window. > > I really don't understand why you wrote that VNC is more usable > than NX. To me, it's simply never the case. Hmm, I cannot claim much professional experience, but I am using tigervnc from europe to access interactive 3d rendering apps on a maschine in the US and I am quite happy. In fact the display delay is only little more than the connection latency (about 120ms for me). Michael
Bug#641345: ITP: pysurfer -- visualize Freesurfer's data in Python
Package: wnpp Severity: wishlist Owner: NeuroDebian team * Package name: pysurfer Version : 0.1+git Upstream Author : Michael Waskom, Alexandre Gramfort, Scott Burns, Satrajit Gosh * URL : http://pysurfer.github.com/ * License : BSD-3 Programming Lang: Python Description : visualize Freesurfer's data in Python This is a Python package for visualization and interaction with cortical surface representations of neuroimaging data from Freesurfer. It extends Mayavi’s powerful visualization engine with a high-level interface for working with MRI and MEG data. . PySurfer offers both a command-line interface designed to broadly replicate Freesurfer’s Tksurfer program as well as a Python library for writing scripts to efficiently explore complex datasets. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110912182737.4065.31776.reportbug@meiner
Bug#633677: ITP: isis -- I/O framework for neuroimaging data
Package: wnpp Severity: wishlist Owner: NeuroDebian Team * Package name: isis Version : 0.3.3 Upstream Author : Lydia Hellrung (hellr...@cbs.mpg.de) et al. * URL : http://isis-group.github.com/isis/ * License : GPL-2+ Programming Lang: C++ Description : I/O framework for neuroimaging data This framework aids access of and conversion between various established neuro-imaging data formats, like Nifti, Analyze, DICOM and VISTA. ISIS is extensible with plugins to add support for additional data formats. This IO framework is the base of the lipsia package and may also become adopted by odin (both in Debian main). The completion of this packaging effort is a prerequisite for updating the lipsia package to the latest upstream release. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110712194652.10476.91193.reportbug@meiner
Bug#618774: ITP: cctools -- cooperative computing tools
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: cctools Version : 3.3.0 Upstream Author : Douglas Thain * URL : http://nd.edu/~ccl/software/ * License : GPL-2 Programming Lang: C, Python Description : cooperative computing tools This is a collection of software that help users to share resources in a complex, heterogeneous, and unreliable computing environment. This includes: . Chirp - A personal filesystem and I/O protocol that allows unprivileged users to share space securely, efficiently, and conveniently. When combined with Parrot, Chirp allows users to create custom wide-area distributed filesystems. Parrot - A transparent user-level virtual filesystem that allows any ordinary program to be attached to a remote storage device such as an FTP server or a Chirp server. Makeflow - A workflow system for parallel and distributed computing that uses a language very similar to Make. Work Queue - A system and API for building master-worker style programs that scale up to thousands of processors. All Pairs - A computational abstraction for running very large Cartesian products. Wavefront - A computational asbtraction for running very large dynamic programming problems. The Fault Tolerant Shell - A high-level programming language that allows users to combine the ease of shell scripting, the power of distributed programming, and the precision of compiled languages. Basically, parallel programming and exception handling for scripts. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110318123632.24994.96798.reportbug@meiner
Re: package testing, autopkgtest, and all that
On Wed, Feb 02, 2011 at 05:13:21PM +, Ian Jackson wrote:
> Michael Hanke writes ("Re: package testing, autopkgtest, and all that"):
> > I see the point in having less by better-quality input to package
> > maintainers, but again, the test results do not have to go one-by-one to
> > a human to inspect.
>
> We don't have any infrastructure for dealing with this kind of
> information in bulk. I think that what you are proposing is a
> different kind of thing to autopkgtest and it would be best for us to
> deploy autopkgtest now as it already exists.
This being the second missing piece of infrastructure that is mentioned in this
thread, and IMHO worth thinking about.
> > There are various labs that are very interested in verifying that
> > "random" library updates don't break their systems, which can happen
> > with any update.
>
> This is easily done with autopkgtest; the only difference from your
> proposal is that the source package needs to be downloaded. Doing so
> is not difficult or troublesome, and can be done automatically.
Fair enough.
In the context of a DEP the question remains whether we want to hammer
it in stone that separately distributed upstream testsuites need to be
source packaged and build dummy binary packages?
Moreover, I'm begining to wonder what the scope of this DEP would be:
any type of testing done in Debian, or a limited subset like per-package
unit/regression tests?
Michael
--
Michael Hanke
http://mih.voxindeserto.de
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110202174726.GA6607@meiner
Re: package testing, autopkgtest, and all that
On Wed, Feb 02, 2011 at 04:13:37PM +, Ian Jackson wrote:
> Yaroslav Halchenko writes ("Re: package testing, autopkgtest, and all that"):
> > in the core -- users usually do not deal with source packages; many of
> > them do not even have deb-src lines for apt. They do not care how
> > things are built, but if we want them to contribute by testing their
> > systems, the simplest approach is exposing test batteries as binary
> > packages. Of cause, user-friendly front-end might overcome those
> > difficulties even if tests are provided in source packages.
>
> I don't understand what your usage model is. Are you expecting random
> users to execute the tests ? Why would they do that ? What kind of
> useful outcome is this likely to produce ?
We expect any person that is interested or asked to run test to do it
and be able to do it. They would do that because they need to be sure
that things work as intended and already do that in many cases. A common
use case are scientific analysis toolkits: We have seen them break due
to a change in a shared lib in Debian -- a change that upstream doesn't
see, because they link statically against ancient and "approved"
versions.
There are various labs that are very interested in verifying that
"random" library updates don't break their systems, which can happen
with any update.
If "random user" clicks the TestMyDebianSystem "button" the outcome
might be a passed test and everybody is happy, or a failure with a log.
> I think that someone who doesn't have a "deb-src" line in their
> sources.list, and has no knowledge of the existence of source
> packages, is very unlikely to produce a useful bug report which leads
> to an improvement to the software.
Think about a dashboard that collects failures and passes. Even if a
single user cannot produce a good report, you'll know that something is
wrong if suddenly many machines report trouble.
But to get many machines, we need to make it dead-simple to participate
in this type of croud-testing. We can have GUI frontends to let people
do specific tests, or offer "backfill" job configurations for compute
clusters.
> Making test suites highly end-user-visible is simply likely to result
> in a lot of noise.
Higher noise, but more samples -- I'm not sure what offers the best
estimate of the actual status.
I see the point in having less by better-quality input to package
maintainers, but again, the test results do not have to go one-by-one to
a human to inspect.
> > for the goal of testing current system setup, installing the single,
> > most recent battery, sounds sufficient. To complement there are
> > snapshot.debian.org and backports.debian.org, so any previous or
> > backported version could be made available
>
> Our mechanisms for downloading and installing specific binary packages
> from different source are not very well-developed.
Maybe that is something we should work on in this context.
Michael
--
Michael Hanke
http://mih.voxindeserto.de
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110202170156.GA4928@meiner
Re: package testing, autopkgtest, and all that
On Wed, Feb 02, 2011 at 10:08:32AM -0500, Michael Hanke wrote: > > I don't think going back the drawing board now is a very good idea. > > What we are lacking is deployment (and, sorry for my part in the lack > > of that). > > I don't necessarily take the point of being 5 years too late. If > everything was optimal and decided 5 years ago, why is nobody using this > system? Having all the other testing approaches around clearly indicates > that there is demand... Just in case: I didn't mean to sound too negative. I see the rational in having things the way they are in autopkgtest, but maybe we can also think about autopkgtest as one essential core component and a general approach to distribution-wide single- and cross-package testing. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110202151604.GB2014@meiner
Re: package testing, autopkgtest, and all that
On Wed, Feb 02, 2011 at 02:28:14PM +, Ian Jackson wrote: > As for "also" running tests which are "not part of a source package", > it is very easy to wrap up some tests in a dedicated source package if > that's desirable. The source package is then just a convenient > container format. There is no requirement in autopkgtest that the > source package containing tests generates any binary packages at all, > let alone that it generates the particular things being tested. I wonder how that would look in detail. For software in "our" field we also need to deal with test suites that upstream intents to be ran by users, that comes as a separate download with substantial size. Would I have to wrap them into a source package that builds no binary packages? Is that possible with the current infrastructure at all? > > Let's see first if we have all the arguments on the table already, > > thanks to this thread. I'm willing to co-drive a DEP to finalize the > > spec, although I definitely need helping hands (hint, hint!). > > One point I would like to make is that people who are now raising > objections to fundamental design decisions are, I think, five and a > half years too late. > > The design, both in principle and detail, was discussed in November > 2005 on various Debian lists. Amongst other people, you, Stefano, > participated. In February 2006 I reported that I had an initial > implementation. > > I don't think going back the drawing board now is a very good idea. > What we are lacking is deployment (and, sorry for my part in the lack > of that). I don't necessarily take the point of being 5 years too late. If everything was optimal and decided 5 years ago, why is nobody using this system? Having all the other testing approaches around clearly indicates that there is demand... Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110202150832.GA2014@meiner
Re: package testing, autopkgtest, and all that
On Wed, Feb 02, 2011 at 08:55:07AM +0100, Stefano Zacchiroli wrote: > > So, where do we start/continue sharing the thoughts on a tentative > > DEP? ;) > > Let's see first if we have all the arguments on the table already, > thanks to this thread. I'm willing to co-drive a DEP to finalize the > spec, although I definitely need helping hands (hint, hint!). I'm very interested in this and willing to help pushing it forward. I sense a similar interest for Yarik. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110202130656.GB30281@meiner
Re: Bits from the Security Team (for those that care about bits)
On Mon, Jan 24, 2011 at 07:48:18AM +0100, Iustin Pop wrote: > IMHO what would be a sufficient first step would be much simpler: > - being able to know if a package does offer build & post-install tests > - how to run such tests > - for post-install tests, what are the depedencies (Test-Depends? ;-) True. However, we are trying to think this somewhat trough so we have a better picture what will be typical use cases for testing within Debian. One thing we need to deal with in our field are tests that require substantial amounts of additional data (not part of any package right now) and sometimes also the test suite is not part of a source package, but shipped separately (due to size, ...). > This would allow a maintainer to implement an automatic test of his > packages whenever doing a new upload (which is my personal issue :). A > framework like your proposed DebTest can then build upon such basic > functionality to provide coordinated, archive-wide or package-set-wide > running of tests. Yes, that was the idea. > A few comments on your proposal: > > - “Metainformation: duration”: how do you standardise CPU/disk/etc. > performance to get a useful metric here? > > - assess resources/performance: in general, across > architectures/platforms and varied CPU speeds, I think it will be hard > to quantify the performance and even resources needed for a test suite All these are just meant to be things to consider while planning. I personally don't believe it is possible to give an accurate 'in-advance' estimate of test-runtime (given the large variety in performance). However, it might still be valuable to indicate whether a test is relatively resource hungry. Maybe it turns out that anything but a tag 'slow' is impossible to achieve. But we also thought about a Debian-dashboard for test results. That could gather information about the typical resource demands (per architecture) and give more accurate estimates. > - some structured output: given the variety of test suites, this might > be very hard to achieve; in my experience, the best that can be hoped > for across heterogeneous software is a count of pass/fail, and log > files should be left for human investigation in case of failures True. Although not being able to be smart in some cases doesn't imply that we don't try to be clever when we can. We want to aim for a system that has a very low entry threshold. In the simplest case the package maintainer only places a symlink/script/binary with the package name implementing the test suite into a certain directory. When called and exiting normally the test will count is passed or failed otherwise. the "structured" output in this case is stderr and stdout. However, there are subsystems of Debian with more standardized approaches to testing (e.g. Python). DebTest should have the ability to add plugins for specific test environments to allow people to make it more clever. We only need to make sure that more structured information about test results have a place to go to and being handled in this framework. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124133435.GA12160@meiner
Re: Bits from the Security Team (for those that care about bits)
On Mon, Jan 24, 2011 at 12:19:32AM +0100, Iustin Pop wrote: > First, tests run during a package build are good, but they do not > ensure, for example, that the package as installed is working OK. I've > been thinking that (also) providing tests to be run after the package is > installed (and not on the build results) would be most useful in > ensuring that both the build process and the packaging is correct. > > Second, README.test are designed for human consumption, whereas a > standardisation of how to invoke the tests would allow for much more > automation. E.g. piuparts would not only be able to test that the > install succeeds, but the automated tests also work. Exactly. In the NeuroDebian team we started playing around with more comprehensive testing -- both regarding single packages, but also integration tests involving multiple packages. We started composing a SPEC for a testing framework, but we haven't gotten very far, yet. What we have is here http://neuro.debian.net/proj_debtest.html and here http://git.debian.org/?p=pkg-exppsy/neurodebian.git;a=blob_plain;f=sandbox/proposal_regressiontestframwork.moin If somebody is interested in working on this topic, we'd be glad to join forces. Originally, we wanted to develop the SPEC a little further, but since the topic came up, I figured it might be better to add these pointers now. Michael -- Michael Hanke http://mih.voxindeserto.de signature.asc Description: Digital signature
Re: Bug#608922: ITP: matlab -- integrate local Matlab installations into the Debian system
On Tue, Jan 04, 2011 at 05:57:44PM +0100, Stefano Zacchiroli wrote: > On Tue, Jan 04, 2011 at 11:49:55AM -0500, Michael Hanke wrote: > > What name do you suggest? Maybe 'matlab-package'? > > 'matlab-integration' would be nice, but in the specific context of > matlab might be misleading (cfr. 'octave-integration'). As a second > choice, how about 'matlab-support'? 'matlab-support' it shall be. Thanks for the feedback. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104175857.ga13...@meiner
Re: Bug#608922: ITP: matlab -- integrate local Matlab installations into the Debian system
On Tue, Jan 04, 2011 at 05:43:04PM +0100, Cyril Brulebois wrote: > > This package does NOT provide Matlab (TM). > > It really shouldn't be called “matlab” then. The likelihood of Debian having a package that actually provides matlab seems to be rather low. If it ever happens this package would be obsolete and could be removed. I assume you want to point to the problem of some people having matlab packages that actually contain the binaries, right? How does Debian deal with this issue? Could we have a 'skype' package? What name do you suggest? Maybe 'matlab-package'? Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104164955.ga12...@meiner
Bug#608922: ITP: matlab -- integrate local Matlab installations into the Debian system
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: matlab Version : 0.0.13 Upstream Author : Michael Hanke * URL : http://neuro.debian.net/pkgs/matlab.html * License : GPL Programming Lang: POSIX shell Description : integrate local Matlab installations into the Debian system This package does NOT provide Matlab (TM). It merely helps sysadmins integrate local installations in the Debian system to handle this proprietary software in a more coherent way. Moreover, this package can be used as a runtime dependency for packages that install Matlab code and, for example, need to compile MEX extensions. . One or more Matlab installations can be registered with Debian's alternatives system, and a helper utility to build MEX extensions is provided. All configuration is conveniently done via debconf. Moreover: Analogous to Octave a Makefile snippet is provided that configures the locations for architecture independent M-files, binary MEX-extensions, and there corresponding sources. This package can be used as a build-dependency by other packages shipping Matlab toolboxes. Rational: There is already at least one package in Debian that installs MATLAB MEX extensions (http://packages.debian.org/sid/dynare-matlab, #608919). This package is inspired by the handling of MEX building implemented in this package, but aims at generalizing it and providing a helper for other packages. The NeuroDebian project currently deals with a number of packages that _could_ ship MATLAB code. Moreover, we are working on making it easier for users and developers of formerly Matlab-only software to transition to Octave. For this purpose it would be very useful to have both Octave and Matlab extensions available on a system, so that users can switch back and forth between them until full compatibility is reached (only going back to Matlab as long as still necessary) -- see http://neuro.debian.net/proj_matlab.html >From README.source: Although this whole package is pointless without Matlab (a large non-free something) the source package has been placed into 'main' for the following reason: It builds a 'matlab-dev' package that other source packages can build depend on to figure out where to install MEX sources and M-files (analogous to the way Octave packages provide this information via a Makefile snippet). This -dev package has nothing to do with Matlab and should go into 'main', as otherwise no source package that build-depends on it could go into 'main'. That would be suboptimal for otherwise DFSG-compliant package that simply also _can_ build MEX extensions (e.g. see the dynare-matlab package in the archive). The actual Matlab adaptor package is placed into 'contrib'. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104163529.11435.88298.report...@meiner
Bug#605492: ITP: fieldtrip -- toolbox for MEG and EEG analysis
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: fieldtrip Version : 0.20101101 Upstream Author : Donders Institute for Brain, Cognition and Behaviour * URL : http://fieldtrip.fcdonders.nl * License : GPL-2+ Programming Lang: Matlab/Octave Description : toolbox for MEG and EEG analysis The software includes algorithms for simple and advanced analysis of MEG and EEG data, such as time-frequency analysis, source reconstruction using dipoles, distributed sources and beamformers and non-parametric statistical testing. It supports the data formats of all major MEG systems (CTF, Neuromag, BTi) and of the most popular EEG systems, and new formats can be added easily. FieldTrip contains high-level functions that you can use to construct your own analysis protocols in Matlab. Furthermore, it easily allows developers to incorporate low-level algorithms for new EEG/MEG analysis methods. This software is distributed as a Matlab toolbox. However, the NIMH distributes a “port” of fieldtrip to Octave (at http://kurage.nimh.nih.gov/meglab/Meg/Software). It needs to be figured out who did that, whether this port can be incorporated into the official version, and to what degree it is complete. Packaging fieldtrip is required to complete the packaging of SPM8 (#592390). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101130162700.27581.69786.report...@meiner
Bug#603336: ITP: classads -- library for Condor's classads expression language
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: classads Version : 1.0.9 Upstream Author : Condor Team * URL : http://www.cs.wisc.edu/condor/classad * License : Apache Programming Lang: C++, Description : library for Condor's classads expression language A classad (classified ad) is a mapping from attribute names to expressions. In the simplest cases, the expressions are simple constants (integer, floating point, or string), thus a form of property list. Attribute expressions can also be more complicated. There is a protocol for evaluating an attribute expression of a classad vis a vis another ad. Two classads match if each ad has attribute requirements that evaluate to true in the context of the other ad. Classad matching is used by the Condor central manager to determine the compatibility of jobs and workstations where they may be run. This package is necessary for packaging Condor itself (#602842). Ubuntu has a classads package that served as starting point of this effort. Here is the current list of changes on top of that: * Shorten and slightly improve package descriptions. * Raise debhelper compat to 7 (already build-depended on >7). * Add another binary package 'classads' to install the command line utilities. Keeping them in the runtime library package would have made it impossible to co-install a future libclassad1 package, due to file conflicts. * Move to an unversioned -dev package. There is no intention to maintain multiple library versions in parallel. * No longer install unneeded .la files (squeeze release goal). * No longer install duplicate license files as docs. * Add VCS information to debian/control. * Move to a DEP-5 compliant debian/copyright. * Improve clean target in debian/rules to remove all temporary files. The packaging is available at: http://git.debian.org/?p=pkg-exppsy/classads.git -- GPG key: 4096R/7FFB9E9B Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101113080343.ga6...@meiner
Bug#602842: ITP: condor -- workload management system
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: condor Version : 7.4.4 Upstream Author : Condor Team, Computer Sciences Department, University of Wisconsin-Madison URL : http://www.cs.wisc.edu/condor * License : Apache License, Version 2 Programming Lang: C++, Java Description : workload management system Description --- [from webpage] Condor is a specialized workload management system for compute-intensive jobs. Like other full-featured batch systems, Condor provides a job queueing mechanism, scheduling policy, priority scheme, resource monitoring, and resource management. Users submit their serial or parallel jobs to Condor, Condor places them into a queue, chooses when and where to run the jobs based upon a policy, carefully monitors their progress, and ultimately informs the user upon completion. While providing functionality similar to that of a more traditional batch queueing system, Condor's novel architecture allows it to succeed in areas where traditional scheduling systems fail. Condor can be used to manage a cluster of dedicated compute nodes (such as a "Beowulf" cluster). In addition, unique mechanisms enable Condor to effectively harness wasted CPU power from otherwise idle desktop workstations. For instance, Condor can be configured to only use desktop machines where the keyboard and mouse are idle. Should Condor detect that a machine is no longer available (such as a key press detected), in many circumstances Condor is able to transparently produce a checkpoint and migrate a job to a different machine which would otherwise be idle. Condor does not require a shared file system across machines - if no shared file system is available, Condor can transfer the job's data files on behalf of the user, or Condor may be able to transparently redirect all the job's I/O requests back to the submit machine. As a result, Condor can be used to seamlessly combine all of an organization's computational power into one resource. Plan At the batch queueing systems BoF at DebConf10 this software has been discussed as a potential addition to Debian. I plan to start tracking the 'stable' series -- maybe adding a dedicated package for the 'development' series sometime in the future (if there is enough manpower). Upstream already has some Debian packages, but uses external software that is downloaded and built from source instead of exclusively relying on Debian packages. I want to start from upstream packaging and improve integration into the Debian system. If you are interested in co-maintaining this package, please drop me a note. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101108190650.30305.33663.report...@meiner
Bug#600275: ITP: nibabel -- Python bindings to various neuroimaging data formats
Package: wnpp Severity: wishlist Owner: NeuroDebian team * Package name: nibabel Version : 1.0.0 Upstream Author : NiBabel developers * URL : http://nipy.sourceforge.net/nibabel * License : Expat Programming Lang: Python Description : Python bindings to various neuroimaging data formats This package provides read and write access to some common medical and neuroimaging file formats, including: ANALYZE (plain, SPM99, SPM2), GIFTI, NIfTI1, MINC, as well as PAR/REC. The various image format classes give full or selective access to header (meta) information and access to the image data is made available via NumPy arrays. NiBabel is the successor of PyNIfTI. . This package also provides a commandline tool for conversion of PAR/REC to NIfTI images. This package will eventually replace the python-nifti package in Debian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101015121138.5113.28932.report...@meiner
Re: Search for a file in all Debian source packages
On Thu, Sep 30, 2010 at 02:21:45PM -0500, Raphael Geissert wrote: > Michael Hanke wrote: > > Is there any way to accomplish this, without having to create a > > complete mirror of the archive and parse all tarballs? > > As of a few minutes ago: > http://lintian.debian.org/~geissert/Contents-sources.gz Thank you Raphael! Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100930200547.gb3...@meiner
Re: Search for a file in all Debian source packages
On Thu, Sep 30, 2010 at 08:33:54PM +0200, Benjamin Drung wrote: > Am Donnerstag, den 30.09.2010, 14:31 -0400 schrieb Michael Hanke: > > Hi, > > > > I want to determine in what Debian _source_ packages a file with a > > particular name exists. There used to be a webservice that had all? > > source packages indexed and allowed for this type of query, but I cannot > > remember what it was -- maybe it doesn't exist anymore. > > http://www.debian.org/distrib/packages > > There you can search the contents of packages. _Binary_ packages. This is not what I was looking for. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100930183800.ga28...@meiner
Search for a file in all Debian source packages
Hi, I want to determine in what Debian _source_ packages a file with a particular name exists. There used to be a webservice that had all? source packages indexed and allowed for this type of query, but I cannot remember what it was -- maybe it doesn't exist anymore. Is there any way to accomplish this, without having to create a complete mirror of the archive and parse all tarballs? Thanks in advance, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100930183103.ga28...@meiner
Re: data.debian.org -- requirements for packages
On Thu, Sep 30, 2010 at 06:01:38PM +0100, Simon McVittie wrote: > On Wed, 29 Sep 2010 at 13:09:03 -0400, Michael Hanke wrote: > > * compression of content > > > > Any policy to enforce compressed file formats regarding the stuff > > installed > > by a data package? > > I think this ought to be case-by-case: some users of large data blobs > (e.g. Quake 3/Openarena PK3 files) already support compression, but if the > application that uses the data will be mmap()ing it, compression isn't > really feasible. > > .deb files are compressed anyway, unless you go to some effort to turn > that off, so space consumption on mirrors should be about the same either way. That is correct, but I was more aiming at rules we have to compress some portions of installed files (e.g. dh_compress). Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100930170823.ga24...@meiner
data.debian.org -- requirements for packages
Hi, I know that data.debian.org is not yet there, but I wonder whether there is already a concept, i.e. a set of requirements that packages have to fulfil to qualify for this archive? I assume packages would have to be architecture 'all', but other than that I wonder whether there will be any significant differences from regular packaging? In particular: * size constraints: lower and upper limit When does a data package need to move data.d.o and when would it be too much for that one too? * relation to other Debian packages Does data.d.o accept any data "standalone" package, or is it only meant for packages that serves as dependencies for other Debian packages? * compression of content Any policy to enforce compressed file formats regarding the stuff installed by a data package? * approach to avoid wasting archive space If a data package simply installs the content of a tarball, it would have the tarball content two times (one in source package and the identical content in the binary package). Is that taken as a fact, or is there an approach to handle this case more efficiently? Thanks in advance, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100929170903.ga14...@meiner
Re: RFC: Policy 10.1 and appropriateness of package conflicts
On Fri, Aug 13, 2010 at 03:38:39PM +0100, Ian Jackson wrote: > So the only purpose of "fsl" is to provide these namespace-eating > convenience symlinks ? If so I'm not sure that this is a good purpose > for a a package. Well, it has been 'invented' to address a frequent user-problem that people can readily use the GUI parts of that package (because they are avialable via wrappers in /usr/bin and visible in the desktop menu), but once they switch to the console they cannot "see" the rest of the suite. Of course they should read the documentation to learn how they should set up their $PATH correctly (and it is as simple as `man fsl`), but instead they flood the upstream mailing list with things like "Debian package broken...". I was trying to address this issue with a package that specifically addresses these things _in addition_ to the actual package that installs the suite into a private namespace. > Rather, unconditionally install the convenience symlinks but in a > dedicated directory which users can put on their PATH. Amongst other > benefits, that will mean that the namespace clash can be resolved on a > per-user basis. This is already done that way for the 'fsl-4.1' that actually contains the suite. Still the question remains whether this setup is forbidden by policy 10.1? Would it help to move the package from optional to extra? Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100813163006.ga...@meiner
RFC: Policy 10.1 and appropriateness of package conflicts
Hi, I'm trying to figure out a solution for RC bug #592242. The short summary of this bug is a package A that conflicts with a package B due to a name clash in /usr/bin. The programs in question do not provide the same functionality, hence the alternatives systems cannot be used. Debian policy 10.1 states: Two different packages _must not_ install programs with different functionality but with the same filenames. (The case of two programs having the same functionality but different implementations is handled via "alternatives" or the "Conflicts" mechanism...) Since renaming is not an option due to large side-effects in the packages in question, I declared a package conflict between A and B and uploaded a new version. However, various parties expressed their concerns with this "solution". http://lists.debian.org/debian-release/2010/08/msg00304.html http://bugs.debian.org/592242 (reopened with reason: "conflicts are not appropriate for conflicts between executable names") IMHO this aspect of policy 10.1 tries to prevent the situation of a user needing the functionality of both packages A and B, but being unable to install them on the same system, solely due to a filename clash. However, the situation of #592242 is different. The package (fsl) that conflicts with other packages (e.g. cyrus-clients-2.2) only installs a number of symlinks to tools of a large analysis suite into /usr/bin. The actual suite is installed by another package (fsl-4.1) that does not conflict with other packages. Hence users will always be able to install this suite in combination with any other package. The only purpose of the conflicting package is to allow for a more convenient out-of-the-box setup for people who run this analysis suite as the primary software in their research labs. If, for some reason, they happen to run any of the conflicting packages they can still use the suite with no drawbacks other than reduced initial setup convenience. Is there something that is intended by policy 10.1 that I am missing? Thanks for your comments, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100813132017.ga31...@meiner
Bug#592390: ITP: spm8 -- analysis of brain imaging data sequences
Package: wnpp Severity: wishlist Owner: NeuroDebian team * Package name: spm8 Version : 8.4010 Upstream Author : Wellcome Trust Centre for Neuroimaging * URL : http://www.fil.ion.ucl.ac.uk/spm/software/spm8/ * License : GPL-2+ Programming Lang: Matlab/Octave Description : analysis of brain imaging data sequences Statistical Parametric Mapping (SPM) refers to the construction and assessment of spatially extended statistical processes used to test hypotheses about functional brain imaging data. These ideas have been instantiated in software that is called SPM. It is designed for the analysis of fMRI, PET, SPECT, EEG and MEG. This software is written to be used with Matlab and probably to most widely used piece of software in neuroimaging research. The authors state that Scilab and Octave are free clones of MATLAB, but SPM does not currently run on either. Porting SPM to these environments should be feasible but would require an important investment. It looks like a port is indeed feasible: MEX extensions already build fine with Octave, there are no dependencies to Mathworks toolboxes. For few API incompatibilities workarounds have already been identified. We plan to enable all non-GUI functionality that can be utilized within the NiPyPE framework (http://packages.debian.org/sid/python-nipype), which will also allow us to appropriately test the package. If you have some experience with Octave and/or SPM you're welcome to join this packaging effort. A git repository will appear on Alioth shortly. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100809181829.30914.43170.report...@head1.hydra.dartmouth.edu
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
On Thu, Jul 22, 2010 at 03:10:16PM -0400, Joey Hess wrote: > I've noticed that linking to this page seems to kill threads, which is > not my intent, but: http://kitenet.net/~joey/code/debian/cut/ > > The idea still seems reasonable to me, and the work required, beyond > what is already done, not too much. Shame that nobody has tried to do it > yet. A list of the things that have to be done would probably help people to assess if there is anything they can do to help. Personally, I (almost) always use testing. I'm very happy with the stability, whenever I attempted an install it was successful. The only things that makes me (temporarily) avoid testing in favor of unstable is when a pre-release freeze causes updates to pile up in unstable. A constantly available "running stable" release (what testing basically is most of the time) would be lovely. Would be good to know if there is anything that can be done by people like me to make it happen. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2010070522.ga6...@meiner
Bug#587047: ITP: gifticlib -- IO library for the GIFTI cortical surface data format
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: gifticlib Version : 1.0.8 Upstream Author : Richard Reynolds * URL : http://www.nitrc.org/projects/gifti/ * License : Public domain Programming Lang: C Description : IO library for the GIFTI cortical surface data format GIFTI is an XML-based file format for cortical surface data. This reference IO implementation is developed by the Neuroimaging Informatics Technology Initiative (NIfTI). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100624185920.12328.52366.report...@meiner
Bug#584920: ITP: invesalius -- 3D medical imaging reconstruction toolkit
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: invesalius Version : 3.0.0 Upstream Author : Thiago Franco de Moraes and many more * URL : http://svn.softwarepublico.gov.br/trac/invesalius * License : GPL Programming Lang: Python Description : 3D medical imaging reconstruction toolkit 3D medical imaging reconstruction based on a sequence of 2D DICOM files acquired with CT or MRI equipments, providing several visualization tools. More information is available on the webpage. The package will probably be team-maintained by Debian Med and/or the upstream authors themselves. A packaging effort is already on-going since a while. I'm finally filing this ITP to properly document this and add proper tags which open bugs block this effort. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100607151000.321.7471.report...@meiner
Bug#584436: ITP: drmaa -- Python interface to DRMAA-compliant distributed resource management systems
Package: wnpp Severity: wishlist Owner: Michael Hanke Owner: Michael Hanke * Package name: drmaa Version : 0.4beta3 Upstream Author : Enrico Sirola * URL : http://code.google.com/p/drmaa-python * License : BSD Programming Lang: Python Description : Python interface to DRMAA-compliant distributed resource management systems This is a Python implementation of the Distributed Resource Management (DRM) Application API (DRMAA). It provides all high-level functionality necessary to consign a job to a DRM system (e.g. Sun Gridengine), including common operations on jobs, such as termination or suspension. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100603151531.14035.28667.report...@meiner
Bug#580662: ITP: pyoptical -- python interface to the CRS 'OptiCAL' photometer
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: pyoptical Version : 0.2 Upstream Author : Valentin Haenel * URL : http://github.com/esc/pyoptical * License : MIT/X Programming Lang: Python Description : python interface to the CRS 'OptiCAL' photometer The 'OptiCAL' is a photometer that is produced by Cambridge Research Systems (CRS). This device is a standard tool for gamma-calibration of display devices in vision research. This package provides a free-software replacement for the Windows-software distributed by the manufacturer that allows querying an OptiCAL via a serial connection. pyoptical can be used as a library in third-party applications or as a standalone command line tool. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100507145554.29196.50164.report...@meiner
Bug#580499: ITP: psignifit3 -- fitting and testing hypotheses about psychometric functions
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: psignifit3 Version : 3.0.0~beta1 Upstream Author : Ingo Fruend, Valentin Haenel * URL : http://psignifit.sourceforge.net/ * License : MIT Programming Lang: C++, Python Description : fitting and testing hypotheses about psychometric functions This package allows fitting of psychometric functions to datasets while maintaining full control over a large number of parameters. Psignifit performs the calculation of confidence intervals as well as goodness-of-fit tests. This is the successor of 'psignifit' a commandline-based toolbox. The new version is primarily a python module, but other bindings will be added eventually. Please note that there is already a package for the old psignifit in the archive. I'm discussing with upstream if the new version can possibly provide some simple wrappers to emulate the old commandline tools, in which case the current source package could be removed. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100506121728.19900.94466.report...@meiner
Re: Bug#579284: ITP: voxbo -- processing, statistical analysis, and display of brain imaging data
On Tue, May 04, 2010 at 12:43:35AM +0200, Frank Lin PIAT wrote: > On Mon, 2010-04-26 at 15:05 -0400, Michael Hanke wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Michael Hanke > > > > * Package name: voxbo > > Version : 1.8.5 > > Upstream Author : Daniel Kimberg > > * URL : http://www.voxbo.org > > * License : GPL-3 > > Programming Lang: C++ > > Description : processing, statistical analysis, and display of brain > > imaging data > > This is a pretty long short-description, I suggest: > "analysis, and display of brain imaging data" Yes, will do so. > > This is a toolkit for analysis of functional neuroimaging (chiefly > > fMRI) experiments and voxel-based lesion-behavior mapping. VoxBo > > supports the modified GLM (for autocorrelated data), as well as the > > standard GLM for non-autocorrelated data. The toolkit is designed to be > > interoperable with AFNI, FSL, SPM and others. > > The package description could mention that it is targeted for medical > field. Do you have any specific phrase in mind. Voxbo is not limited to medical usecases, but first and foremost neuroimaging/cognitive neuroscience research. Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100503231110.ga25...@meiner
Bug#579588: ITP: itksnap -- semi-automatic segmentation of structures in 3D images
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: itksnap Version : 2.0.0 Upstream Author : Paul A. Yushkevich et al. * URL : http://www.itksnap.org * License : GPL Programming Lang: C++ Description : semi-automatic segmentation of structures in 3D images SNAP provides semi-automatic segmentation of structures in medical images (e.g. magnetic resonance images of the brain) using active contour methods, as well as manual delineation and image navigation. Noteworthy features are: . * Linked cursor for seamless 3D navigation * Manual segmentation in three orthogonal planes at once * Support for many different 3D image formats, including NIfTI * Support for concurrent, linked viewing and segmentation of multiple images * Limited support for color images (e.g., diffusion tensor maps) * 3D cut-plane tool for fast post-processing of segmentation results -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100428201358.8890.31694.report...@meiner
Bug#579470: ITP: mrtrix -- diffusion-weighted MRI white matter tractography
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: mrtrix Version : 0.2.8 Upstream Author : J-D Tournier * URL : http://www.brain.org.au/software/mrtrix * License : GPL-3 Programming Lang: C++ Description : diffusion-weighted MRI white matter tractography Set of tools to perform diffusion-weighted MRI white matter tractography of the brain in the presence of crossing fibres, using Constrained Spherical Deconvolution, and a probabilisitic streamlines algorithm. Magenetic resonance images in DICOM or ANALYZE format are supported. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100427212555.5400.80652.report...@meiner
Bug#579284: ITP: voxbo -- processing, statistical analysis, and display of brain imaging data
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: voxbo Version : 1.8.5 Upstream Author : Daniel Kimberg * URL : http://www.voxbo.org * License : GPL-3 Programming Lang: C++ Description : processing, statistical analysis, and display of brain imaging data This is a toolkit for analysis of functional neuroimaging (chiefly fMRI) experiments and voxel-based lesion-behavior mapping. VoxBo supports the modified GLM (for autocorrelated data), as well as the standard GLM for non-autocorrelated data. The toolkit is designed to be interoperable with AFNI, FSL, SPM and others. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100426190547.2782.68556.report...@meiner
Bug#579231: ITP: mricron -- magnetic resonance image conversion, viewing and analysis
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: mricron Version : 0.20100422.1 Upstream Author : Chris Rorden * URL : http://www.cabiatl.com/mricro/mricron/index.html * License : BSD Programming Lang: Pascal Description : magnetic resonance image conversion, viewing and analysis GUI-based visualization and analysis tool for (functional) magnetic reasonance imaging. MRIcron can be used to create 2D or 3D renderings of statistical overlay maps on brain anatomy images. Moreover, it aids drawing anatomical regions-of-interest (ROI), or lesion mapping, as well as basic analysis of functional timeseries (e.g. creating plots of peristimulus signal-change). . This package also provides 'dcm2nii' that supports converting DICOM and PAR/REC images into the NIfTI format. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100426115441.16504.66274.report...@meiner
Re: Who is running non-free autobuilders
On Tue, Mar 23, 2010 at 11:20:07AM +0100, Marc 'HE' Brockschmidt wrote: > Michael Hanke writes: > > since a while I try to figure out why a package is not being auto-built. > > I was suggested to contact the "team that runs the non-free > > autobuilders". However, I have trouble finding that team. Whom could I > > contact -- neither google nor the wiki seems to know about them. > > Currently, noone is running the non-free autobuilder because we have > none. In the long run, this will be integrated into the usual Debian > infrastructure, but this hasn't happened yet. Thanks for this information. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100323110941.ga17...@meiner
Who is running non-free autobuilders
Hi, since a while I try to figure out why a package is not being auto-built. I was suggested to contact the "team that runs the non-free autobuilders". However, I have trouble finding that team. Whom could I contact -- neither google nor the wiki seems to know about them. Thanks for pointers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100323013039.ga15...@meiner
Changes in non-free autobuilder?
Hi, I'm the maintainer of 'fsl'. I uploaded a new version of the package about 10 days ago. Since that only an ia64 binary package has been built. http://packages.debian.org/sid/fsl Did I miss any change to the non-free auto-building procedure, or is there some other condition that slows down/prevents this package from being built? Thanks in advance, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100318004226.ga25...@meiner
Re: Conflicting information about buildd status and testing migration
Hi, On Fri, Jan 15, 2010 at 04:04:49PM +, Philipp Kern wrote: > I agree that the page could be more informative, but it's due to the fact > that it looks at the source package and does not get the information that > it should build it. In the database you can query on cimarosa.debian.org > (if you're a DD) you will see that it says Installed-Version correctly: That makes sense -- unfortunately I'm not a DD. > This suggests that it was tried on hppa tried long ago and failed. (Building > does only switch to something different depending on the buildd/sbuild version > in use.) > > On mipsel it seems that there is currently no unofficial autobuilder, so > what I'd recommend you is to request a partial binary removal through > ftp.debian.org's bug list to get it dropped for hppa and mipsel. Ah, I see. Thanks a lot -- that made it clear. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Conflicting information about buildd status and testing migration
On Fri, Jan 15, 2010 at 02:14:18PM +0100, Cyril Brulebois wrote: > Michael Hanke (15/01/2010): > > out of date on hppa: fsl (from 4.1.1-1) > > out of date on mipsel: fsl (from 4.0.4-1) > > > > > > and that is supported by the arch listing on > > > > http://packages.debian.org/sid/fsl > > “rmadison fsl” is usually how one checks for this. Thanks. What I get from there is the same that I get from the website. > > Unfortunately, the buildd logs for this non-free package that used > > to be here: > > > > http://experimental.debian.net/fetch.php?&pkg=fsl&ver=4.1.4-2&arch=hppa > > > > are currently (or no longer) available. > > > > I'd be glad for some hints what is happening here. > > http://lists.debian.org/debian-wb-team/2010/01/msg00012.html Hmm, so the buildds are working just the website is not available. That puts me exactly where I started: Information from the buildds suggests the package is built for all archs, the website and rmadison say "no". I have no logs to check, hence I still have no clue. What information is the output of https://buildd.debian.org/pkg.cgi?pkg=fsl based on? I guess it doesn't assume that packages are built properly be default. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Conflicting information about buildd status and testing migration
Hi, I'm a little confused about a problem wrt testing migration of one of my packages (fsl). http://qa.debian.org/excuses.php?package=fsl says: out of date on hppa: fsl (from 4.1.1-1) out of date on mipsel: fsl (from 4.0.4-1) and that is supported by the arch listing on http://packages.debian.org/sid/fsl However, looking at https://buildd.debian.org/~luk/status/package.php?p=fsl and https://buildd.debian.org/pkg.cgi?pkg=fsl I get the impression that the package was built fine for hppa and mipsel too. But looking in the pool http://ftp.us.debian.org/debian/pool/non-free/f/fsl/ I cannot see hppa and mipsel packages for the latest version. Unfortunately, the buildd logs for this non-free package that used to be here: http://experimental.debian.net/fetch.php?&pkg=fsl&ver=4.1.4-2&arch=hppa are currently (or no longer) available. I'd be glad for some hints what is happening here. Thanks in advance, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#556552: ITP: python-openelectrophy -- data analysis framework for intra- and extra-cellular recordings
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: python-openelectrophy Version : 0.0.svn145 Upstream Author : Samuel Garcia, Nicolas Fourcaud-Trocmé * URL : http://neuralensemble.org/trac/OpenElectrophy * License : Cecill v2 Programming Lang: Python Description : data analysis framework for intra- and extra-cellular recordings This package provide a library und GUI for analyzing electrophysiological data. (imagine the rest of a long description) There has been some debate whether the Cecill v2 license can be considered DFSG-compatible [0]. Wikipedia says '?' [1]. It claims to be GPL-compatible and might allow relicensing under the GPL. If it turns out to be incompatible, I'll try to talk with upstream about it -- otherwise the package would target 'non-free'. The software essentially exposes a 'pyssdh' package, hence the Debian package might be named python-pyssdh. However, the package also serves as the 'OpenElectrophy' GUI-application (via python-qt4) and I guess this is what users would look for. It might be reasonable to add an additional arch:all binary package 'openelectrophy' that merely contains the short wrapper script distributed by upstream and a link in /usr/bin and otherwise depend on python-pyssdh -- not sure yet whether this is the way to go. The main (and only) form of distribution is via SVN. It has never been released the tarball way, hence the made up version. I am about to add this project to the relevant task pages of the Debian-Med and -Science pure blends. [0] http://lists.debian.org/debian-legal/2008/12/msg00045.html [1] http://en.wikipedia.org/wiki/CeCILL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#513272: Availability of roundl() on armel?
Hi,
[ I already posted this to debian-armel already [0], but got no response
so far -- maybe someone on this list can provide a hint ]
I am trying to fix #513272, a FTBFS on armel. The problem basically
boils down to the following snippet failing to compile on armel (tested
with a Debian lenny on a qemu-emulated armel system):
-
#include
using namespace std;
int main ()
{
double val = 3.4;
int res;
res = roundl(val);
}
-
yields
-
debian-armel:~# g++ -Wall test.cpp
test.cpp: In function ‘int main()’:
test.cpp:9: error: ‘roundl’ was not declared in this scope
-
On i386 and amd64 this works fine. The solution is probably simple, but
I could not determine it. Suggestions are very much appreciated.
Thanks in advance,
Michael
--
GPG key: 1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532619: ITP: garmindev -- qlandkartegt plugins to acces Garmin devices
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: garmindev Version : 0.2.0 Upstream Author : Oliver Eichler * URL : http://www.qlandkarte.org * License : GPL Programming Lang: C++ Description : qlandkartegt plugins to acces Garmin devices This packages provides the access plugins for Garmin hardware that had previously been part of qlandkarte and are now distributed separately. This package is needed to make qlandkarteGT (ITP #507352) a full replacement of the older qlandkarte http://packages.debian.org/sid/qlandkarte so that it can be removed from the archive. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#528616: RFA: dares - rescue files from damaged CDs and DVDs
Package: wnpp Severity: normal Hi, I am offering 'dares' for adoption, since I am already ignoring it for too long. The package does: Dares scans a CD/DVD image or a CD/DVD for files. This also works when the filesystem (ISO-9660 or UDF) on the disc is damaged and cannot be mounted anymore. This tool has never seen any upstream release since I packaged it for Debian and is getting old. Both the software itself as well as the packaging are really simple. There are currently two open bugs. The popcon count is 230 -- not too low, so maybe someone wants to take care of this package in the future. Otherwise I would orphan it in a couple of weeks. Since it seems to be upstream dead, completely removing it from the archive might the most viable option. If you want to take over just take what is currently in the archive and upload a new version. Since there was no upstream release there is also no history, hence no VCS. Cheers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
Re: Possible mass bug filing: non-doc packages recommending doc packages
On Fri, May 08, 2009 at 08:58:51AM +0200, Andreas Tille wrote: > On Fri, 8 May 2009, Christian Perrier wrote: > >> I bringed the discussion in out maintenance list but dropping >> Recommends to Suggests is likely to make us provide a "broken" home page >> for SWAT by default. We could of course patch SWAT so that the page >> explicitely says that adding samba-doc is needed but that would be >> glightly ugly. >> >> So, that could be seen as a quite calid use case, indeed..:) > > As a raw estimation about 50% of the packages I maintain / sponsor use > the doc package not only as pure standalone doc but the doc might be > used by the help system of the native program / web application. You > might argue that in this case the program should be called *-data, but > I'd call this nitpicking because the packages in itself are perfectly > valid doc packages and make sense on their own. So I do not think that > this issue is really atarget for mass bug filing because chances for > false positives are to high. I'm fine with a lintian warning which > can be overriden by the maintainer in case he decides recommending the > doc package is the reight way to go. +1 and this is what I will do for 'fsl' and 'fslview', since the corresponding doc packages provide the online-help of the respective applications -- even though these are plain html files that perfectly fit into a separate doc package. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#521412: ITP: lipsia -- analysis suite for MRI and fMRI data
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: lipsia Version : 1.5.0 Upstream Author : LIPSIA developers * URL : http://www.cbs.mpg.de/institute/software/lipsia * License : GPL Programming Lang: C, C++ Description : analysis suite for MRI and fMRI data Leipzig Image Processing and Statistical Inference Algorithms (LIPSIA) . This is a software package for the data processing and evaluation of functional magnetic resonance images. The analysis of fMRI data comprises various aspects including filtering, spatial transformation, statistical evaluation as well as segmentation and visualization. All these aspects are covered by LIPSIA. For the statistical evaluation, a number of well established and peer-reviewed algorithms were implemented in LIPSIA that allow an effcient and user-friendly processing of fMRI data sets. As the amount of data that must be handled is enormous, an important aspect in the development LIPSIA was the efficiency of the software implementation. . LIPSIA operates exclusively on data in the VISTA data format. However, the package contains converters for medical image data in iBruker, ANALYZE and NIfTI format -- converting VISTA images into NIfTI files is also supported. -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#521328: ITP: via -- library and tools for volumetric image analysis
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: via Version : 1.5.2 Upstream Author : LIPSIA developers * URL : http://www.cbs.mpg.de/institute/software/lipsia * License : GPL Programming Lang: C Description : library and tools for volumetric image analysis This package provides a toolkit for functional and structural (medical) image data processing. It consists of a library of about 50 different programs ranging from simple data handling routines and viewers to complex image transformation algorithms. . All tools operate on data in VISTA format. The package contains several converters from e.g. PNG, PGM or PNM to this data format and back. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (600, 'testing') Architecture: i386 (i686) -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the Debian Pure Blends Team
On Fri, Mar 20, 2009 at 12:20:39PM -0400, Daniel Dickinson wrote: > On Fri, 20 Mar 2009 14:40:24 +0100 (CET) > Andreas Tille wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Hello, > > > > as you might have noticed the effort formerly known as Custom > > Debian Distributions was renamed to Debian Pure Blends (see > > [1] for the reasons). This process is now regarded as finished. > > > > The Alioth project was moved to > > > > http://alioth.debian.org/projects/debian-blends > > This link reports 'Invalid Project' The correct one is http://alioth.debian.org/projects/blends Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Re: Please Improve Debian for Multimedia Production
Hi, On Fri, Mar 20, 2009 at 04:29:35PM +0100, Fabian Greffrath wrote: >> As an additional hint the multimedia team might consider using the Debian >> Pure >> Blends framework which enables them to show quite simply what is just there >> and >> what they are working on (for instance see just issued bits [1]). So if you >> are interested in those tasks and bugs pages or in multimedia related >> metapackages >> just ask me in case there might be some technical questions about Blends. >> You can read more here [2]. > > Speaking for the pkg-multimedia-maintainers, i.e. the actual Debian > Multimedia Team, we don't see ourself as a Debian Blend. We are just a > bunch of maintainers maintaining a bunch of packages *in* Debian: Right, and that is what blends are about -- maintaining packages *in* Debian. You just get some additional magic that helps you to make your work a bit more visible and guides users like the starter of this thread, as well as potential contributers Overly simplifying, you get something like this: http://debian-med.alioth.debian.org/tasks/imaging.html instead of: > http://qa.debian.org/developer.php?login=pkg-multimedia-maintainers%40lists.alioth.debian.org ;-) Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Debian -- the best
t when using the OS. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
Re: Bug#508901: ITP: dicom3tools -- Tools for handling DICOM files, with conversion from proprietary formats.
On Tue, Dec 16, 2008 at 02:06:40PM +0100, Yves-Alexis Perez wrote: > On mar, 2008-12-16 at 13:57 +0100, Mathieu Malaterre wrote: > > Description : Tools for handling DICOM files, with conversion > > from proprietary formats. > > > > Unix, Mac and Windows (Cygwin) command line utilities for creating, > > modifying, dumping and validating files of DICOM attributes, and > > conversion of proprietary image formats to DICOM. Can handle older > > ACR/NEMA format data, and some proprietary versions of that such as > > SPI. > What are DICOM, ACR, NEMA, SPI? Medical image data formats. Given that the description should be appropriate for a potential user those names should be ok -- but Mac and Windows are surely not meaningful in this context. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#507352: ITP: qlandkartegt -- GPS mapping (GeoTIFF and vector) and Garmin GPSr management
Package: wnpp Severity: wishlist Owner: Michael Hanke <[EMAIL PROTECTED]> * Package name: qlandkartegt Version : 0.9.0 Upstream Author : Oliver Eichler <[EMAIL PROTECTED]> * URL : http://www.qlandkarte.org/ * License : GPL-2 Programming Lang: C++ Description : GPS mapping (GeoTiff and vector) and GPSr management This package provides a versatile tool for GPS maps in GeoTiff format as well as Garmin's img vector map format. QLandkarteGT is the successor of QLandkarte. Among various improvements (e.g. 2D/3D map rendering and reduced ressource demands) the major difference is its device-independent architecture, which is not limited to Garmin devices anymore. Therefore, the package also does not include device drivers. Drivers for a number of Garmin devices are available from the package. Additionally, QLandkarteGT serves as a frontend to the GDAL tools, to make georeferencing of scanned maps feasible for users. In contrast to similar tools (e.g. QGis) its straightforward interface is especially suited for non-scientific users. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497448: ITP: python-griddata -- Python function to interpolate irregularly spaced data to a grid
Package: wnpp Severity: wishlist Owner: Michael Hanke <[EMAIL PROTECTED]> * Package name: python-griddata Version : 0.1.2 Upstream Author : Jeffrey Whitaker <[EMAIL PROTECTED]> * URL : http://code.google.com/p/griddata-python/ * License : MITish Programming Lang: Python Description : Python function to interpolate irregularly spaced data to a grid This module provides a single function, 'griddata', that fits a surface to nonuniformly spaced data points. It behaves basically like its equivalent in Matlab. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495093: ITP: hcluster -- Python functions for agglomerative clustering
Package: wnpp Severity: wishlist Owner: Michael Hanke <[EMAIL PROTECTED]> * Package name: hcluster Version : 0.1.8 Upstream Author : Damian Eads <[EMAIL PROTECTED]> * URL : http://code.google.com/p/scipy-cluster/ * License : BSD Programming Lang: Python Description : Python functions for agglomerative clustering The module's features include: . * computing distance matrices from observation vectors * generating hierarchical clusters from distance matrices * computing statistics on clusters * cutting linkages to generate flat clusters * visualizing clusters with dendrograms . The interface is very similar to MATLAB's Statistics Toolbox API. The core implementation of this library is in C for efficiency. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (600, 'testing') Architecture: i386 (i686) -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Large data packages in the archive
Hi, On Sun, May 25, 2008 at 08:18:01PM +0200, Joerg Jaspert wrote: > So assume we go for solution c. (which is what happens unless someone > has a *very* strong reason not to, which I currently can't imagine) we > will setup a seperate archive for this. This will work the same way as > our main archive does, with a few notable points: > > - It will be solely arch:all, not splitted per architecture. Or, if >someone presents *good* reasons why a data archive needs to be >architecture-aware, we will also offer this, but *NO* autobuilder >support will be provided. >This is meant as a place for large datasets, and those should be >arch independent. And would kill many autobuilders (think of binary >packages having 500, 800 or more megabytes!) > > - It is an own archive, so it needs full source uploads to work, >every data package you create will be a full source package and you >have to split the source between this archive and the rest that goes >into the normal Debian one. > > Any comments? First, thanks a lot for taking care of this issue. As you mentioned there had been several discussions about this before. I'd be curious what you think about a scenario for data source packages that has been outlined by Anthony Towns before: http://lists.debian.org/debian-devel/2007/06/msg00298.html Basically it is a virtually empty source package that build-depends on the binary package that it builds. I made a draft of such a source package that I use to build a 1GB data package that I host myself (currently). It is initially built by forcing dpkg-buildpackage to ignore the build-dep. When the necessary data is not detected during build-time a small script downloads it from upstream and puts it in the build-tree. This scenario has the advantage that it prevents doubling the size of the archive when the data in source and binary packages is identical. An example package is here (source is just a few kB, but binary is approx. 1GB) http://apsy.gse.uni-magdeburg.de/debian/pool/non-free/f/fsldata/fsldata_4.0.4-1.dsc Would you support/accept such a package? What about licenses? Is data.debian.org just for stuff that could go in main or also non-free stuff (above has a non-commerical license)? > Timeframe for this? I expect it to be ready within 2 weeks. Great! BTW, what would be the new maximum size of a package for data.debian.org -- 10 GB? ;-) Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466556: ITP: python-mvpa -- multivariate pattern recognition with Python
Package: wnpp Severity: wishlist Owner: Michael Hanke <[EMAIL PROTECTED]> * Package name: python-mvpa Version : 0.1.0 Upstream Author : Michael Hanke <[EMAIL PROTECTED]>, Yaroslav Halchenko <[EMAIL PROTECTED]> * URL : http://pkg-exppsy.alioth.debian.org/pymvpa/ * License : MIT Programming Lang: Python Description : multivariate pattern recognition with Python This package provides a Python module to ease pattern classification analyses of large datasets. It provides high-level abstraction of typical processing steps and a number of implementations of some popular algorithms. . While it is not limited to neuroimaging data it is eminently suited for such datasets. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (600, 'testing'), (200, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-k7 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
Bug#459729: ITP: pyglet -- a cross-platform windowing and multimedia library for Python
Package: wnpp Severity: wishlist Owner: Michael Hanke <[EMAIL PROTECTED]> * Package name: pyglet Version : 1.0~beta3 Upstream Author : Alex Holkner <[EMAIL PROTECTED]> * URL : http://www.pyglet.org * License : BSD Programming Lang: Python Description : a cross-platform windowing and multimedia library for Python Description stolen from webpage (not a proper long descr. yet): pyglet provides an object-oriented programming interface for developing games and other visually-rich applications for Windows, Mac OS X and Linux. Some of the features of pyglet are: - No external dependencies or installation requirements. For most application and game requirements, pyglet needs nothing else besides Python, simplifying distribution and installation. - Take advantage of multiple windows and multi-monitor desktops. pyglet allows you to use as many windows as you need, and is fully aware of multi-monitor setups for use with fullscreen games. - Load images, sound, music and video in almost any format. pyglet can optionally use AVbin to play back audio formats At the moment pyglet is included in the python-sympy package. As it can be viewed as a pygame replacement sympy maintainers agree that it should be packaged separately. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=459716 The final package will be maintained by the pkg-exppsy project on alioth. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (600, 'testing'), (200, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-k7 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
Unmet dependencies on Sparc when building wordnet and fslview
Hi, On Tue, Dec 11, 2007 at 07:40:52AM +0100, Andreas Tille wrote: > Hi, > > if you look at the buildd report for latest wordnet on sparc at > > > http://buildd.debian.org/fetch.cgi?&pkg=wordnet&ver=1%3A3.0-6&arch=sparc&stamp=1194923732&file=log > > you see: > > The following packages have unmet dependencies: > man-db: Depends: bsdmainutils but it is not going to be installed > E: Broken packages > apt-get failed. I'm having a similar problem with the 'fslview' package. If you look at http://buildd.debian.org/fetch.cgi?&pkg=fslview&ver=3.0%2B4.0.2-2&arch=sparc&stamp=1195437172&file=log it says: The following packages have unmet dependencies: libqwt-dev: Depends: libqwt4c2 (= 4.2.0-4) but it is not going to be installed Depends: libqt3-mt-dev but it is not going to be installed libvtk5-qt3-dev: Depends: libvtk5-qt3 but it is not going to be installed qt3-apps-dev: Depends: libqt3-mt-dev but it is not going to be installed E: Broken packages Sparc is the only architecture that fails to build and I cannot easily see the reason. All packages mentioned above seem to be available for sparc. This bug? also seems to prevent libniftiio to enter testing and this (if that is correct) in turn also blocks: dicomnifti fslview libmdc2 libmdc2-dev medcon python-nifti xmedcon I'd be glad if somebody could confirm that this is actually the problem and what caused it in the first place. Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455068: ITP: qlandkarte -- manage and visualize GPS data and upload/download to GPSr
Package: wnpp Severity: wishlist Owner: Michael Hanke <[EMAIL PROTECTED]> * Package name: qlandkarte Version : 0.5.3 Upstream Author : Oliver Eichler <[EMAIL PROTECTED]> * URL : http://qlandkarte.sourceforge.net/ * License : GPL Programming Lang: C++ Description : manage and visualize GPS data and upload/download to GPSr This package provides a free-software replacement of the commercial Garmin MapSource program. It supports download and upload of GPS maps, waypoints and tracks to a number Garmin GPS devices (e.g. eTrex Legend, Venture and GPSmap60/76). . QLandkarte does and will not support unlocking of commercial maps. Due to the lack of free routable maps, there is also no routing support. There is already an inofficial Debian package around, but only in binary form and not policy compliant. This package might be a candidate for the DebianGis team, although it is not listed on the 'wanted' page in the wiki. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Watching mentors and nifticlib
Hi, [ not sure whether the original post should have been posted to debian-med instead of debian-devel. CC'ing it for now, but I guess we should move there... ] On Sun, Nov 11, 2007 at 02:10:35PM +0100, Andreas Tille wrote: > Hello, > > as you know we have several people who maintain Debian-Med relevant > packages but are no official DDs and thus needs sponsoring. Today > I stumpled over a new version of nifticlib that would close the > show stopper bug which keeps the current version out of testing - > so we might be interested to get this uploaded soon. This fact > brought up several issues to discuss: > > 1. Would it be interesting to get mentors included into our > web-sentinel David is continuousely busy to enhance. We > could parse mentors whether there are packages hanging around > that are mentioned in our tasks packages. I like the idea, but it would only help solving the problem, if there are actually some DDs reading it and acting accordingly. > 2. What is the general procedure for sponsoring those packages? > I was not able to find any information whether Michael has > "his favourite sponsor". Well I guess Michael is basically > interested in getting his stuff uploaded soon and thus he will > probably not really care who is just uploading but the fact > that he did not announced a request for sponsoring here is > a sign that he is not really seeking a sponsor and my guess > is that the delay in the upload is just caused by the problems > of ftp-master. Indeed, I have a very reliable sponsor. In fact he is more than a sponsor and (at least to some degree) we group-maintain all of 'my' packages. In general I think that packages should not be uploaded without a formal request. Some people (including me) use mentors.d.n. to provide unfinished packages for sponsors and beta-tester. Having such a package uploaded could introduce unecessary, because already known, bugs to Debian unstable. > But besides these assumptions I wonder how we could keep track > of the sponsoring procedure. I would love if we would have some > control who sponsored a package to cause some action in case > this sponsor is say on vacation or what else. What do you > think about this. > > BTW, Michael, what do you think about pushing your packaging stuff > of nifticlib into our Debian-Med SVN? We switched to Git some time ago and all my packages are available from git.debian.org. The control files should list the corresponding repository. If one package is not there (yet), it is because no upload/update was necessary since I started moving. The next upload will make the package repository available as well. Because I use Git + git-buildpackage and a repository layout different from the debian-med SVN I don't want to push things to it. But given the distributed nature of Git, it should be equally easy to get the package sources and provide patches for it. Cheers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
Draft: empty source package (was: Re: Reasonable maximum package size ?)
Hi, On Tue, Jul 24, 2007 at 06:01:38PM -0400, Yaroslav Halchenko wrote: > > I guess an evil solution to *** that doesn't cause problems with ### > > would be to create a dummy source package that Build-Depends: on the > > exact version of the package it builds, so that uploads include a > > >...< > here is where I got stuck with such approach: conventionally I just > dgetted sources and tried to build the package with dpkg-buildpackage. > Of cause I failed to accomplish the mission since Build-Depends weren't > satisfied... so indeed it seems to be confusing or my brain is not > working now... > > My suggestion (I might be duplicating someone else' idea, please pardon > me) -- for arch 'all': automatically download (copy) data during > build of the package. I know that somewhere now I will hit the roof in > debian policy, but for whatever it is worth. I tried to implement Anthony Towns idea of the 'empty' source packages. I attached a tarball with my current draft. It contains a source package and the two binary packages it builds. If you want to try it, extract the source package (and do not install the binary packages). Try building it -- it fails because the binary packages with the required data is missing. Override the dependency-check with e.g. debuild -d Now the package builds the two binary packages that are also in the tarball. This is achieved by invoking an included script that gets the data from 'upstream'. The source package makes use of CDBS and debhelper. The core parts are the rules file with two special targets: - orig-src: build the orig.tar.gz (what else) - populate-src-package: import the required datasets from available sources. + a special clean target. The core of the populate-src-package target is a call to a script called dh_datapkg. It checks whether the binary packages (it builds) are installed and copies the required datasets from the installed packages using dh_install configuration. When no binary packages are availabe it invokes a custom script that can download the data from somewhere (or whatever). The 'special' clean target takes care of adding the build-dependencies to all arch indep packages that are build by the source package and also cleans the datasets from the source package -- again by using dh_install configuriation. I applied this idea to two different 'in-house' data packages with each 1GB we use here and it seems to be a flexible and convenient approach. However, one currently cannot use everything that debhelper allows you to do (dh_installexamples, dh_installdocs). But I think this 'empty' source package concept should be limited to real dataset packages, so this should not be a major problem. Any comments? If such package with 800 MB of brain data would hit the NEW queue, what would happen? Is it still to big? Should the upstream license be part of the orig.tar.gz or is the debian/copyright sufficient? Anything else missing? Cheers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 datapkdemo.tar.gz Description: Binary data signature.asc Description: Digital signature
Re: Mass bug filing: Dependency/file list predictability
Hi, On Thu, Jul 19, 2007 at 02:13:26AM +0200, Steinar H. Gunderson wrote: > Michael Hanke <[EMAIL PROTECTED]> >kbibtex Maybe I did not get the point, but to me the diff in the dependencies just reflects the time between the two compared builds: === START OF kbibtex_0.1.5-5_amd64.deb INFORMATION DIFF === --- /tmp/1183823494-21518.archive 2007-07-07 15:54:53.0 + +++ /tmp/1183823494-21518.built 2007-07-07 15:54:54.0 + @@ -1,3 +1,3 @@ -Depends: kdelibs4c2a (>= 4:3.5.5-1), libacl1 (>= 2.2.11-1), libart-2.0-2 (>= 2.3.16), libattr1 (>= 2.4.4-1), libaudio2, libc6 (>= 2.3.5-1), libfam0, libfontconfig1 (>= 2.4.0), libfreetype6 (>= 2.2), libgcc1 (>= 1:4.1.1-12), libice6 (>= 1:1.0.0), libidn11 (>= 0.5.18), libjpeg62, libpng12-0 (>= 1.2.13-4), libqt3-mt (>= 3:3.3.7), libsm6, libstdc++6 (>= 4.1.1-12), libx11-6, libxcursor1 (>> 1.1.2), libxext6, libxft2 (>> 2.1.1), libxi6, libxinerama1, libxml2 (>= 2.6.27), libxrandr2, libxrender1, libxslt1.1 (>= 1.1.18), libxt6, zlib1g (>= 1:1.2.1) +Depends: kdelibs4c2a (>= 4:3.5.7-1), libacl1 (>= 2.2.11-1), libart-2.0-2 (>= 2.3.18), libattr1 (>= 2.4.4-1), libaudio2, libc6 (>= 2.5-5), libfam0, libfontconfig1 (>= 2.4.0), libfreetype6 (>= 2.2), libgcc1 (>= 1:4.2-20070516), libice6 (>= 1:1.0.0), libidn11 (>= 0.5.18), libjpeg62, libpng12-0 (>= 1.2.13-4), libqt3-mt (>= 3:3.3.7), libsm6, libstdc++6 (>= 4.2-20070516), libx11-6, libxcursor1 (>> 1.1.2), libxext6, libxft2 (>> 2.1.1), libxi6, libxinerama1, libxml2 (>= 2.6.29), libxrandr2 (>= 2:1.2.0), libxrender1, libxslt1.1 (>= 1.1.18), libxt6, zlib1g (>= 1:1.2.1) There is no additional dependency or left out deps, just increased versions in the latter (kdelibs4, libart-2, libc6, libgcc1, libstdc++6, libxml2, libxrandr2). Same for: === START OF kbibtex_0.1.5-5_amd64.deb PBUILDER INFORMATION DIFF === --- /tmp/1183823494-21518.pbuilt2007-07-07 16:04:20.0 + +++ /tmp/1183823494-21518.built 2007-07-07 16:04:20.0 + @@ -1,3 +1,3 @@ -Depends: kdelibs4c2a (>= 4:3.5.7-1), libacl1 (>= 2.2.11-1), libart-2.0-2 (>= 2.3.18), libattr1 (>= 2.4.4-1), libaudio2, libc6 (>= 2.5-5), libfam0, libfontconfig1 (>= 2.4.0), libfreetype6 (>= 2.2), libgcc1 (>= 1:4.2-20070516), libice6 (>= 1:1.0.0), libidn11 (>= 0.5.18), libjpeg62, libpng12-0 (>= 1.2.13-4), libqt3-mt (>= 3:3.3.7), libsm6, libstdc++6 (>= 4.2-20070516), libx11-6, libxcursor1 (>> 1.1.2), libxext6, libxft2 (>> 2.1.1), libxi6, libxinerama1, libxml2 (>= 2.6.29), libxrandr2 (>= 2:1.2.0), libxrender1, libxslt1.1 (>= 1.1.18), libxt6, zlib1g (>= 1:1.2.3.3.dfsg-1) +Depends: kdelibs4c2a (>= 4:3.5.7-1), libacl1 (>= 2.2.11-1), libart-2.0-2 (>= 2.3.18), libattr1 (>= 2.4.4-1), libaudio2, libc6 (>= 2.5-5), libfam0, libfontconfig1 (>= 2.4.0), libfreetype6 (>= 2.2), libgcc1 (>= 1:4.2-20070516), libice6 (>= 1:1.0.0), libidn11 (>= 0.5.18), libjpeg62, libpng12-0 (>= 1.2.13-4), libqt3-mt (>= 3:3.3.7), libsm6, libstdc++6 (>= 4.2-20070516), libx11-6, libxcursor1 (>> 1.1.2), libxext6, libxft2 (>> 2.1.1), libxi6, libxinerama1, libxml2 (>= 2.6.29), libxrandr2 (>= 2:1.2.0), libxrender1, libxslt1.1 (>= 1.1.18), libxt6, zlib1g (>= 1:1.2.1) This time higher version in the pbuilder build (zlib1g). Therefore I think that this is not a bug. Please tell me if I'm missing something. Cheers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
Re: Reasonable maximum package size ?
On Wed, Jun 06, 2007 at 01:58:33AM +1000, Anthony Towns wrote: > On Tue, Jun 05, 2007 at 06:28:53PM +0900, Charles Plessy wrote: > > Le Tue, Jun 05, 2007 at 10:09:07AM +0200, Michael Hanke a ?crit : > > > My question is now: Is it reasonable to provide this rather huge amount > > > of data in a package in the archive? > > many thanks for bringing this crucial question on -devel. In my field, I > > wish that it would be possible to apt-get install the human genome for > > instance. > > Are either of you going to debconf, or able to point out some example > large (free?) data sets that should be packaged like this as a test case > for playing with over debconf? No, I'm not going to Debconf, but here is an example package (arch:all) to play with (approx. 150MB): http://apsy.gse.uni-magdeburg.de/~hanke/bigpack/caret-data_5.5~dfsg.1-1.dsc or if you prefer the (repackaged) orig tarball only http://apsy.gse.uni-magdeburg.de/~hanke/bigpack/caret-data_5.5~dfsg.1.orig.tar.gz FYI: this is among other stuff a stereotaxic brain atlas. The data is GPL licensed, but for some reason (I guess user-tracking) upstream requires everyone to register prior to download. It is a little strange, but this is the current situation. Therefore uscan doesn't work -- the watch file doesn't list the login/password. I'm trying to convince upstream to get rid of the registration requirement rather than impolitely bypassing it by putting it in the watchfile. Anyway, that should not matter for this purpose. Thanks for working on this problem, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
Re: Reasonable maximum package size ?
Hi, On Tue, Jun 05, 2007 at 10:27:26AM +0200, Marco d'Itri wrote: > On Jun 05, Michael Hanke <[EMAIL PROTECTED]> wrote: > > - much easier to handle for users (thinking of offline machines) > I could not care less, since the number of users affected is with very > good approximation zero. Agreed. > > - if upstream goes offline, the relevant software package in the archive > > are > >basically useless as the required datasets are not distributed anymore > Create your own distribution site if you really believe this to be a > problem. I believe this is a valid problem. I think that is exactly the reason why the Debian archive also provides the sources of each package (orig.tar.gz) and does not simply point to the upstream sites while keeping only the diffs in the archive. > > > - diskspace is rather cheap and bandwith should be no problem as the > >number of downloads will remain relatively low. > Diskspace *is* a problem for mirrors, as is bandwidth in many countries. Right. > Also, you should think about this issue not just in the context of the > single package you are interested in but as a general policy. I was hoping to give that impression... Cheers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
Reasonable maximum package size ?
Hi, I'm packaging some neuroimaging tools that come with datasets that are required for those tools to work properly. The size of these datasets is up to 400 MB (some others at least well over 100 MB). My question is now: Is it reasonable to provide this rather huge amount of data in a package in the archive? An alternative to a dedicated package would be to provide a download/install script for the data (like the msttcorefonts package) that is called at package postinst. Another alternative would be to provide a package like the (googleearth-package)-package. This would have the advantage that the users could easily build packages, that they can distribute themselves. Arguments for download wrappers/package-maker would be: - only the datasets fill yet another CD - only very few people actually benefit from this package (it is a rather very-special-interest-package) - datasets change infrequently - saves a lot of diskspace in archive and mirrors Arguments for a package: - much easier to handle for users (thinking of offline machines) - if upstream goes offline, the relevant software package in the archive are basically useless as the required datasets are not distributed anymore - diskspace is rather cheap and bandwith should be no problem as the number of downloads will remain relatively low. There was already a little discussion about this, starting from here: http://lists.debian.org/debian-devel/2007/05/msg00207.html I'd like to hear you comments about this. Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
Re: Wrapper to download databases (was: Sharing a subdirectory of /usr/share between multiple packages ?)
Hi, On Tue, May 08, 2007 at 10:05:05AM +0200, Gabor Gombas wrote: > On Tue, May 08, 2007 at 09:39:23AM +0200, Michael Hanke wrote: > > > This has the advantage that the datasets are only downloaded if it is > > really necessary (there are modifications checked by md5sum). The is > > especially usefull as the datasets tend to be the same across releases. > > And this is a real PITA when you want to install on a machine that does > not have a network connection. Don't do that! Anything that bypasses the > normal package management is a pain to handle. > > Instead how about splitting the package to two source packages: one for > code and one for the data? That way you can upload the data package much > less frequently. I'm aware of the disadvantages. But still, the machines were such packages will be installed most likely have a VERY fast connection. Additionally, the scripts offer the ability to use local archives or mirrors (on disk or LAN). Even when I split the package into data and binaries. As soon as a single file gets updated I have to bump the version and everyone has to download the whole package again. And we are talking about a lot of data. I'm currently testing it with a little 6MB package (mainly because it is only 6MB), but the canditates are 130 MB, 250 MB and 400 MB. And as I understand it Charles talks about a lot more data. But you are of course right, that having it all properly packaged in the archive is by far the best way to do it (from the user perspective). I'm just not sure whether it is useful to put this very, very special interested data in there? Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Wrapper to download databases (was: Sharing a subdirectory of /usr/share between multiple packages ?)
Hi, On Tue, May 08, 2007 at 09:08:36AM +0900, Charles Plessy wrote: > Dear all, > > In the Debian-Med project, we started to package a bioinformatic > analysis suite - EMBOSS - which exploits local or remote sequence > databases (read-only). When they are small (a few megaoctets), we are > considering pacakging them. But in the case of much bigger ones > (gigabytes), we will use wrappers. I'm curious: What kind of wrappers are you using? I'm currently packaging some neuro-imaging tools which have source tarballs of several 100 MBs, but the actual code is only a few kilobytes, the rest is datasets. To me it seems to be a waste of space (in the archive) to upload theses huge binary datablobs. I'm currently testing the possibility to download these datasets from the package postinst script. I adapted the scripts from the msttcorefonts package (in a simpler form). This has the advantage that the datasets are only downloaded if it is really necessary (there are modifications checked by md5sum). The is especially usefull as the datasets tend to be the same across releases. Are you using a different approach? Cheers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Are popcon stats per package and arch possible?
On Sat, May 05, 2007 at 11:23:54AM -0700, Steve Langasek wrote: > On Sat, May 05, 2007 at 06:23:36PM +0200, Petter Reinholdtsen wrote: > > > [Michael Hanke] > > > To me it looks like stats for the major architectures up to (and > > > including) powerpc are ok wrt privacy concerns. Do you agree? > > > I'm not sure if that would be the correct cutoff point, or if only > > amd64 and i386 have enough submissions to ignore the privacy issue. > > Well, at that point what use is a per-arch stat anyway? When I first contact some upstream authors of a software I want to package, I often faced the argument: 'We already provide binaries that should run on Linux systems and therefore we do not see why we should support your packaging attempt.' My usual answer is to describe all the nice features a Debian package provides. After a lengthy discussion they normally agree that from the user perspective a Debian package offers a much higher convenience level. But sometimes upstream does not agree. Nevertheless, when they say, 'we provide binaries for Linux', they always mean i386 Linux with everything linked statically to a huge binary blob. I'd really like to be able to provide some hard numbers about users of similar packages (same field or a direct competitor) running it on arches different from i386. So far, I only know the general fraction of non-i386 users. But this fraction is most likely very different for particular fields (e.g. office suite on ARM machines or embedded sutff on AMD64). Cheers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Are popcon stats per package and arch possible?
On Sat, May 05, 2007 at 10:40:34AM +0200, Petter Reinholdtsen wrote: > [Michael Hanke] > > I wonder whether it is possible to get information about which > > package is installed/used on a particular architecture. > > It is possible, but it isn't done at the moment. We do not store the > data needed to generate such reports, but it could be done with the > data set we have at every given point in time. > > But I would be reluctant to do it for the less used architectures, for > privacy reasons. The information we get from such analysis would be > too easy to associate with individual users (like the kfreebsd-amd64 > porters for that arch. :). Right, thanks for pointing this out. > And for those interested, here are the latest numbers: > > 2 0.00% i486 > 2 0.00% kfreebsd-amd64 > 3 0.01% hurd-i386 > 3 0.01% ppc64 > 8 0.02% armel > 9 0.02% armeb > 9 0.02% s390 >11 0.02% m68k >11 0.02% kfreebsd-i386 >20 0.04% mips >42 0.09% ia64 >57 0.12% hppa >65 0.14% mipsel >68 0.14% alpha > 223 0.47% sparc > 598 1.25% powerpc > 676 1.42% arm > 5625 11.79% amd64 > 40283 84.42% i386 > 47715 100.00% total (ignored 229 without arch info) To me it looks like stats for the major architectures up to (and including) powerpc are ok wrt privacy concerns. Do you agree? I'd be very interested in this information and would be glad if it could be made available. Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Are popcon stats per package and arch possible? (was: The number of etch installations is rocketing...)
Hi, On Thu, Apr 12, 2007 at 11:14:32AM +0200, Petter Reinholdtsen wrote: > This is the current architecture distribution. > > 2 0.01% i486 > 2 0.01% kfreebsd-amd64 > 3 0.01% hurd-i386 > 3 0.01% ppc64 > 7 0.02% armel > 9 0.03% armeb > 9 0.03% s390 > 9 0.03% kfreebsd-i386 >11 0.03% m68k >22 0.06% mips >41 0.12% ia64 >44 0.13% hppa >52 0.15% alpha >53 0.15% mipsel > 171 0.49% sparc > 448 1.27% powerpc > 615 1.75% arm > 4279 12.16% amd64 > 29417 83.58% i386 > 35197 100.00% total (ignored 223 without arch info) I wonder whether it is possible to get information about which package is installed/used on a particular architecture. Is there something like http://popcon.debian.org/source/by_inst for every arch individually? Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421703: ITP: caret -- Computerized Anatomical Reconstruction and Editing Toolkit
Package: wnpp Severity: wishlist Owner: Michael Hanke <[EMAIL PROTECTED]> * Package name: caret Version : 5.5 Upstream Author : Washington University School of Medicine * URL : http://brainmap.wustl.edu/caret * License : GPL Programming Lang: C++ Description : Computerized Anatomical Reconstruction and Editing Toolkit This software allows for viewing and manipulating surface reconstructions of the cerebral and cerebellar cortex, viewing volumes and for displaying experimental data on the surfaces and volumes. Caret can download and use stereotaxic atlases (human, monkey, mouse and rat) from an open online database. I already started packaging and discovered some issues which should be solved before the package is suitable for Debian. - Upstream requires registration prior to source download. However this registration is free and provides the users immediately with a password to the password-protected download area. It looks like upstream uses this procedure to maintain some user statistics. I'm going to point them the Debians popcon and ask whether I can include username and password in debian/watch to get uscan working properly. - Two source files contain statements about patented code. It looks like the relevant files were derived from VTK4. The corresponding files in the current VTK5 release do not contain the patent statement anymore, so I guess it has expired. This needs to be clarified. - caret supports MPEG2 export via libvtkMPEG2Encode. While being part of etch this lib has been removed in lenny+ for patent reasons (http://bugs.debian.org/408552). Hence MPEG2 support in caret has to be disabled as well. Additionally caret sources contain MPEG2 headers (e.g. mpeg2enc.h) that have to be removed from the source tarball. A prospective will soon be available. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (600, 'testing'), (500, 'stable'), (200, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-k7 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
Re: Thoughts on distributing virtual machine images to promote Debian
On Mon, Apr 16, 2007 at 01:10:59PM +0200, Daniel Baumann wrote: > Michael Hanke wrote: > > I think VMs are superior to Live-CDs for this task as the VMs can be > > used as a living Debian system that can be further customized. In > > contrast Live-CDs always feel like a snapshot of a certain system that > > one has to live with. > > just for the records: live-cds can be persistent too. > > > If a user discovers any problem with a Live-CD image, the best he/she > > can do is report it and wait for it to get fixed, redownload and try > > again. But most likely it won't happen. Why should one replace one set > > of installation/maintainance problems with another. > > with persistency, you can modify it as if it would be a 'non-live' > system; and once you reboot it, your previous changes are still there. > > > A VM image can be easily modified/fixed/customized. Additionally > > IMHO it demonstrates much better the real advantages of Debian: the > > wealth of high quality free software only one 'apt-get' away. > > apt-get can be used on our livecds just as on every 'non-live' Debian > system, regardless if persistency is enabled or not. I guess I do not know enough about Live-CDs, but obviously others have this problem as well. Is it true that it is as easy as a VM to setup a Live-CD for daily productive work? And I'm talking about the user-perspective. To my understanding the VM would require installing the virtualization software (click through) and choosing a folder you want to mount within the VM. What would be necessary to achieve the same with a Live-CD? Cheers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on distributing virtual machine images to promote Debian
Hi, [ I failed to use my mail client properly. Sorry. This message should make it to -devel AND -science now - hopefully ] On Mon, Apr 16, 2007 at 01:05:45PM +0200, Daniel Baumann wrote: > Michael Hanke wrote: > > Therefore I'd like to ask whether you think that it would be > > reasonable for Debian to provide a virtual machine image with the > > most recent stable release that can be customized to perform a specific > > task on a win32 machine? > > I completely fail to see why a VM image /inside/ debian (as in a debian > package) could be of any benefit to a win32 user. Windows does not > support to install debian packages out of an apt repositories as of now. True, but it wasn't my intention to put it into a package as it would be obviously useless for the target audience. I thought about distributing it along other media (installation CDs/DVDs, Live-CDs). > Assumed, it would be usefull for win32 users, I see two problems: > > * space: a reasonable VM images would be way beyond 100mb, that's to > big. I reasonable selection of neuroimaging tools in a Debian etch VM is approx. 600 MB. That is big, but not too big as this is even less than the size of a CD image. > So, I think this is not so a good idea. > > However, if I were you, I would try to get that image of yours either > into the vmware markedplace[0] or to oszoo[1]. Right, but I can always do this on my own. My intention was to ask whether anyone already did that (and how) or to find interested collaborators. I thought instead of making a Neuroimaging VM only, it might be useful to have one common base where others can make DebianMolekular, DebianPhysics, ... VMs. Perhaps I wasn't precise enough, I'm not looking for a cheap place to distribute a VM. In fact if the whole thing ends up as a wiki page there is little to distribute at all. I still think this could be a way to gain more users, especially in the many science-related area Debian already provides software in its archive. Cheers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Thoughts on distributing virtual machine images to promote Debian
ntages of Debian: the wealth of high quality free software only one 'apt-get' away. How could the virtual machine image be maintained? At the moment I see four possiblities: 1) Integrating its installation setup in tasksel. Although it might be overkill as only relatively few people would use it. 2) Maintaining a configuration that can be used to pre-seed the installer. 3) Maintaining a full master copy of a VM image. 4) Maintaing a wiki page with a detailed installation description tailored for this purpose ATM I don't know what is best. 4) has to advantage that it has the lowest threshold to start working. I apologize for this rather long message, but I wanted to provide something we can hopefully talk about. I'd be glad to hear if anyone already did a similiar thing, or anyone is interested in doing it now and of course any technical advise. Additionally I'm interested in comments about how we could ensure the educational aspect of this project. I'd love if we could transport the message that whatever problem one has, in whatever environment Debian is the universal solution (I read that somewhere ;). Cheers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
Bug#413049: ITP: pynifti -- Python interface to the NIfTI I/O libraries
Package: wnpp Severity: wishlist Owner: Michael Hanke <[EMAIL PROTECTED]> * Package name: pynifti Version : 0.20070301.1 Upstream Author : Michael Hanke <[EMAIL PROTECTED]> (that is me) * URL : http://www.example.org/ * License : LGPL Programming Lang: Python Description : Python interface to the NIfTI I/O libraries Using PyNIfTI one can easily read and write NIfTI and ANALYZE images from within Python. The NiftiImage class provides Python-style access to the full header information. Image data is made available via NumPy arrays. http://apsy.gse.uni-magdeburg.de/main/index.psp?page=hanke/pynifti&lang=en Cheers, Michael -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (600, 'testing'), (200, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409849: ITP: afni -- toolkit for analyzing and visualizing functional MRI data
Package: wnpp Severity: wishlist Owner: Michael Hanke <[EMAIL PROTECTED]> * Package name: afni Version : 2006.12.22.0933 Upstream Author : Robert Cox et al. <[EMAIL PROTECTED]> * URL : http://afni.nimh.nih.gov/ * License : GPL (sources might contain some OCL licensed docs) Programming Lang: C Description : toolkit for analyzing and visualizing functional MRI data AFNI is an environment for processing and displaying functional MRI data. It provides a complete analysis toolchain, including 3D cortical surface models, and mapping of volumetric data (SUMA). In addition to its own format AFNI understands the NIfTI format and is therefore easily usable in combination with FSL and Freesurfer. The package will be maintained by Yaroslav Halchenko <[EMAIL PROTECTED]> and me. Cheers, Michael -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (600, 'testing'), (200, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please upload NMU of tix package to close #360920
I forgot to mention the NMU in the changelog explicitely. I uploaded another package with a complete changelog entry. Cheers, Michael On Sat, Oct 21, 2006 at 09:16:50PM +0200, Michael Hanke wrote: > tags 360920 patch > > thanks > > > Hi, > > I found out that the tix-dev does not install the essential tix.h. This > is extremly inconvenient, if you need tix. There is a bugreport about this > that is > almost 200 days old, without a response by the maintainer. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360920 > > I'm not sure why this bug has severity 'normal'. A significant part of > the package is pretty useless without the header. > > I fixed the bug and uploaded the NMU to mentors.d.n. Because this is > already the third NMU in a row this message is send to debian-devel > directly (maintainer is CC'ed). > > I'd be glad if someone could upload the package (I'm not a DD). I have > to admit that the fix is not the most beautiful. However, it is fairly > simple and should work. Please see the attached diff. > > And yes, the package is anything else than lintian clean! > > The package is here: > > http://mentors.debian.net/debian/pool/main/t/tix/tix_8.4.0-4.3.dsc > > or > > http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=tix > > > Thanks in advance, > > > Michael > > > > -- > GPG key: 1024D/3144BE0F Michael Hanke > http://apsy.gse.uni-magdeburg.de/hanke > ICQ: 48230050 > diff -rNu tix-8.4.0.old/debian/changelog tix-8.4.0/debian/changelog > --- tix-8.4.0.old/debian/changelog2006-10-21 21:02:15.0 +0200 > +++ tix-8.4.0/debian/changelog2006-10-21 21:02:27.00000 +0200 > @@ -1,3 +1,9 @@ > +tix (8.4.0-4.3) unstable; urgency=low > + > + * Modified debian/rules to manually install missing tix.h (Closes: > #360920). > + > + -- Michael Hanke <[EMAIL PROTECTED]> Sat, 21 Oct 2006 20:57:25 +0200 > + > tix (8.4.0-4.2) unstable; urgency=low > >* Non-maintainer upload. > diff -rNu tix-8.4.0.old/debian/rules tix-8.4.0/debian/rules > --- tix-8.4.0.old/debian/rules2006-10-21 21:02:15.0 +0200 > +++ tix-8.4.0/debian/rules2006-10-21 21:02:27.0 +0200 > @@ -108,7 +108,10 @@ > pkglibdir=/usr/lib/tix$(tix_version) \ > PKG_LIB_FILE=libTix$(tix_version).so.1 \ > > - # Move things around > + : # install missing tix.h > + cp $(CURDIR)/generic/tix.h $(d_dev)/usr/include > + > + : # Move things around > > mv $(d_run)/usr/lib/tix$(tix_version)/*.so* $(d_run)/usr/lib/ > mv $(d_run)/usr/lib/tix$(tix_version)/*.a $(d_dev)/usr/lib/ -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
Please upload NMU of tix package to close #360920
tags 360920 patch thanks Hi, I found out that the tix-dev does not install the essential tix.h. This is extremly inconvenient, if you need tix. There is a bugreport about this that is almost 200 days old, without a response by the maintainer. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360920 I'm not sure why this bug has severity 'normal'. A significant part of the package is pretty useless without the header. I fixed the bug and uploaded the NMU to mentors.d.n. Because this is already the third NMU in a row this message is send to debian-devel directly (maintainer is CC'ed). I'd be glad if someone could upload the package (I'm not a DD). I have to admit that the fix is not the most beautiful. However, it is fairly simple and should work. Please see the attached diff. And yes, the package is anything else than lintian clean! The package is here: http://mentors.debian.net/debian/pool/main/t/tix/tix_8.4.0-4.3.dsc or http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=tix Thanks in advance, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 diff -rNu tix-8.4.0.old/debian/changelog tix-8.4.0/debian/changelog --- tix-8.4.0.old/debian/changelog 2006-10-21 21:02:15.0 +0200 +++ tix-8.4.0/debian/changelog 2006-10-21 21:02:27.0 +0200 @@ -1,3 +1,9 @@ +tix (8.4.0-4.3) unstable; urgency=low + + * Modified debian/rules to manually install missing tix.h (Closes: #360920). + + -- Michael Hanke <[EMAIL PROTECTED]> Sat, 21 Oct 2006 20:57:25 +0200 + tix (8.4.0-4.2) unstable; urgency=low * Non-maintainer upload. diff -rNu tix-8.4.0.old/debian/rules tix-8.4.0/debian/rules --- tix-8.4.0.old/debian/rules 2006-10-21 21:02:15.0 +0200 +++ tix-8.4.0/debian/rules 2006-10-21 21:02:27.0 +0200 @@ -108,7 +108,10 @@ pkglibdir=/usr/lib/tix$(tix_version) \ PKG_LIB_FILE=libTix$(tix_version).so.1 \ - # Move things around + : # install missing tix.h + cp $(CURDIR)/generic/tix.h $(d_dev)/usr/include + + : # Move things around mv $(d_run)/usr/lib/tix$(tix_version)/*.so* $(d_run)/usr/lib/ mv $(d_run)/usr/lib/tix$(tix_version)/*.a $(d_dev)/usr/lib/ signature.asc Description: Digital signature
