Re: Still interested to maintain seaborn package?
Hey, On Sun, Mar 24, 2024, 16:13 Nilesh Patra wrote: > > If not, in order to reflect the uploaders realistically, is it OK if > I drop you from the uploaders field in d/control? > Yes, please drop me. Thanks for taking care of seaborn! Best, Michael
Re: Bug#887598: ITP: jasp -- Offers standard analysis procedures in both their classical and Bayesian form
Hi, just FYI there is/was a PR on JASP's GitHub with a semi complete packaging. It had quite a few TODOs, but they should be detailed in the PR. Maybe that is a useful starting point. Cheers, Michael On Jan 21, 2018 21:35, "Andreas Tille" wrote: > Hi Joris, > > thanks for this ITP. Please consider maintaining the package in Debian > Science team. > > Kind regards > > Andreas. > > On Thu, Jan 18, 2018 at 11:02:34AM +0100, jo...@jorisgoosen.nl wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Joris Goosen > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: jasp > > Version : 0.8.5 > > Upstream Author : JASP-team > > * URL : http://www.jasp-stats.org/ > > * License : GPL > > Programming Lang: C++, R > > Description : Offers standard analysis procedures in both their > > classical and Bayesian form > > > > JASP is a cross platform statistical software program with a > > state-of-the-art > > graphical user interface. It offers standard analysis procedures in both > > their classical and Bayesian form. > > . > > It was designed with the user in mind: APA-formatted tables can be > > copy-pasted in your word processor, output can be extensively annotated, > > adjustment of input options dynamically changes the output, and > selecting > > old output revives the associated input choices for inspection and > > adjustment. > > . > > JASP is also statistically inclusive, > > as it offers both frequentist and Bayesian analysis methods. > > Indeed, the primary motivation for JASP is to make it easier for > > statistical > > practitioners to conduct Bayesian analyses. > > . > > For more information and tutorials see: https://jasp-stats.org/ > > > > > > This package is useful as it allows scientist, especially in the social > > sciences, a friendly interface to state-of-the-art statistics techniques > > and is under active development. > > I plan to maintain as part of my work as one of the upstream-developers > and > > aim to make it fully debian compatible from the get-go. > > > > As far as i've understood the information on the debian-wiki we will > need a > > sponsor to be able to upload to the debian repositories. > > -- > http://fam-tille.de > >
Re: [Neurodebian-devel] Neurodebian tasks (and Debian Science)
Hey, On Wed, Apr 6, 2016 at 3:29 PM, Ole Streicher wrote: > Hi Michael, > > On 06.04.2016 14:36, Michael Hanke wrote: > >> Some Fields in neurodebian seem not to have 1:1 tasks in > >> debian-science: [...] > > Any discrepancy should be in favor of the non-neurodebian tasks, > > everything else is an ommision/bug in our side. > > >> The debian-science task "science-neuroscience-congnitive" has no > >> corresponding "field" in neurodebian, but seems to belong there. > > Again, a core debian target is preferred, hence this is a non-issue > > from my PoV. > > I must say that I didn't fully understand that. From your point of view, > Who actually shall feel responsible) for these tasks? NeuroDebian? Do > you say that these Debian tasks are the reference, and if NeuroDebian > does not match it is a bug in NeuroDebian but not in Debian? This is at > least how I did understand you; please correct me if I am wrong. > Yes, you got it right. Debian science is the reference. Anybody who cares should rightfully feel responsible. >> Wouldn't it make sense to move out the specific tasks > >> (science-electrophysiology. science-neuroscience-modelling, > >> science-neuroscience-datasets, science-psychophysics, and > >> science-neuroscience-congnitive) into the "neurodebian" package > >> (and remove it from debian-science)? > > > If somebody does that and it doesn't imply a future increase in > > perceived responsibility of "NeuroDebian" to maintain this former > > debian-science task -- I am all for it. > > The question here is (also) about responsibility. I guess you already > feel responsible for them, since you maintain, or "tag" them on your web > site already? Then it would IMO make perfect sense to extract them to a > separate package (resp. to the existing "neurodebian" package), > maintained by NeuroDebian. > > > I am not convinced that the "install all at once" approach is an > > actual selling point for a real user (NeuroDebian users that is). > > You already do this for your VMs, right? If you were not convinced, you > would not offer those ;-) > No we don't. Our VM is a very minimal image that allows people to quickly install things, but does nothing else. > I personally consider the task association as a "tag", no more. And > > I do mostly care about the second part of > > "science-neuroscience-cognitive" (neuroscience-cognitive), and much > > less about the prefix -- unless it is obscene ;-) > > So, let's omit the prefix completely :-) > > > But again, if this leads to the collateral damage that people are > > less likely to touch the task file because of this change of the > > umbrella from science (general) to neurodebian (less general), this > > would be a cost that I'd hate to pay. > > Browsing the logs, these tasks are mainly unchanged in the last years. > There were some changes 2 years ago by Andreas Tille and by Yaroslav, > but after then they are unchanged. Therefore, I would rate the risk > higher that these tasks become unmaintained. A move to the neurodebian > package would IMO a step forward. If you generate them from tags, that's > perfect, it would keep them synchronous to your web site. > No we don't generate the tasks from tags, the tags a generated from the tasks. Michael -- Michael Hanke http://mih.voxindeserto.de
Re: [Neurodebian-devel] Neurodebian tasks (and Debian Science)
Hi, advance sorry for a terse reply ... resource issues... On Tue, Apr 5, 2016 at 10:12 AM, Ole Streicher wrote: > Dear Yaroslav, and all, > > I am currently looking on how we get the Debian Blends into the > installer for the next release. This is connected to Bug #758116 [1] > > One of the points there is the inclusion of NeuroDebian, which does not > follow the usual Pure Blends scheme. Since you gave a "+100" in the bug, > I however suspect that there is some interest in having NeuroDebian > visible in the installer. > > Looking into your repository content [2], the "by field" selection is > quite close to a number of Debian Science tasks: > > * Packages for Electrophysiology > --> science-electrophysiology > * Packages for Modeling of neural systems > --> science-neuroscience-modelling > * Packages for Neuroscience Datasets > --> science-neuroscience-datasets > * Packages for Psychophysics > --> science-psychophysics > > Some Fields in neurodebian seem not to have 1:1 tasks in debian-science: > > * Packages for Distributed Computing > --> science-distributedcomputing (your selection is a bit smaller?) > * Packages for Magnetic Reasonance Imaging > * Packages for Neuroscience Education > Any discrepancy should be in favor of the non-neurodebian tasks, everything else is an ommision/bug in our side. > The debian-science task "science-neuroscience-congnitive" has no > corresponding "field" in neurodebian, but seems to belong there. > Again, a core debian target is preferred, hence this is a non-issue from my PoV. > The Debian-Science blend is quite filled with tasks: there are currently > 47 tasks in it. Wouldn't it make sense to move out the specific tasks > (science-electrophysiology. science-neuroscience-modelling, > science-neuroscience-datasets, science-psychophysics, and > science-neuroscience-congnitive) into the "neurodebian" package (and > remove it from debian-science)? > If somebody does that and it doesn't imply a future increase in perceived responsibility of "NeuroDebian" to maintain this former debian-science task -- I am all for it. > We then would just need a metapackage that includes (recommends) all > neurodebian tasks that should be installed on a default NeuroDebian > blend. A "neurodebian-tasks" package would be useful as well so that > people could use tasksel to install additonal NeuroDebian tasks (or to > remove them if not needed). > I am not convinced that the "install all at once" approach is an actual selling point for a real user (NeuroDebian users that is). But again, if the goal of splitting up debian-science is worthwhile enough for somebody to make it happen, please go ahead. I personally consider the task association as a "tag", no more. And I do mostly care about the second part of "science-neuroscience-cognitive" (neuroscience-cognitive), and much less about the prefix -- unless it is obscene ;-) But again, if this leads to the collateral damage that people are less likely to touch the task file because of this change of the umbrella from science (general) to neurodebian (less general), this would be a cost that I'd hate to pay. Cheers, Michael -- Michael Hanke http://mih.voxindeserto.de
Re: [RFC] debian/upstream -- add "Funding:" field
On Mar 13, 2013 2:08 PM, "Yaroslav Halchenko" wrote: > > Many projects are often (fully or partially) supported by different > governmental agencies and/or private funds. Those in turn often request > (or at least ask) to acknowledge such sources of funding on projects > pages and corresponding products. ATM there is quite a few of such > projects maintained in Debian but it is nearly impossible to > identify them, that is why I think it would be great to add a new field, > which would describe those, e.g. > > Funding: NSF XX-123456, NIH 123456, ... Great idea. Michael
Re: [OT - or may be not] The case for open computer programs
On Tue, May 29, 2012 at 08:00:57AM +0200, Andreas Tille wrote: > http://www.nature.com/nature/journal/v482/n7386/full/nature10836.html In case you don't want to pay Nature to read about this, you can alternatively pay Science... http://www.sciencemag.org/content/336/6078/159 -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120529182921.GA15178@meiner
Re: Debconf10: Batch Queuing Systems BoF -- revisited
On Thu, May 10, 2012 at 12:38:57PM +0200, Michael Banck wrote: > So having Condor certainly makes sense, but I think we have several > mature (from a upstream POV) batch queueing systems in Debian now, but > might lack maintenance personell. For Condor the situation is very nice in the respect. They have a fairly large group of developers, a couple of Red Hat-paid developers that are also working on distribution integration. The Debian-specific bits are quite minimalistic. Eventually, the Condor group wants to take over the helm of Debian packaging themselves -- once the have acquired the necessary skills. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120510113440.GB8506@meiner
Debconf10: Batch Queuing Systems BoF -- revisited
Hi, some of you might still remember the Batch Queuing Systems BoF at Debconf10, where we briefly discussed the past/present/future of this software in Debian. We talked about the lack of maintainers, and possible strategies to consolidate our efforts. During this meeting I've learned about Condor [0], and my personal conclusion was that it could be the one solution covering most variety of use cases we could think of at this point. Unfortunately, it wasn't available in Debian at all, and upstream had only recently moved to a proper FOSS licensing scheme. In the meantime, however, things have improved a lot. Red Hat is investing into the project (its Grid-computing infrastructure is based on it [1]). I have attended their project conference "CondorWeek" in 2011 and gave a talk proposing a collaboration to integrate Condor into Debian [2] -- which was well perceived. And as of very very recently we have an official package in Debian unstable [3]. Upstream has promised long-term commitment to help Debian ship a high-quality package. The experience of the past year has shown that problems, once reported, are addressed quickly by upstream, making the current official package ship with almost no necessary patches. Right now the Condor package only builds a fraction of the built-in functionality (although what is built is already quite comprehensive for the task of a batch queuing system). I'm working on enabling build-time testing and the kFreeBSD port needs some love. But overall it looks like we are going to have Debian wheezy ship Condor. Unfortunately, I can't attend Debconf this year, but maybe there are enough people interested in the topic to have a follow-up BoF to revisit the issue. What is the status of similar software in Debian (GridEngine, Slurm, ...)? Michael [0] http://research.cs.wisc.edu/condor/ [1] http://redhat.com/products/mrg/grid/ [2] http://research.cs.wisc.edu/condor/CondorWeek2011/presentations/hanke-condor-debian.pdf [3] http://packages.debian.org/sid/condor -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120510074911.GD26197@meiner
Re: New Debian Science metapackages (Was: debian-science_0.16_amd64.changes ACCEPTED into unstable)
On Tue, Apr 17, 2012 at 10:03:19PM -0400, Yaroslav Halchenko wrote: > So, here are few activities I think worth pursuing > > - catchy release notes statement highlighting well-covered fields of > science, computing platforms (distributed, MPI, ...),... +1e+127 We did it last time (squeeze) for the neuroscience-related bits and got substantial press echo -- ranging from: "WTF...who needs that" to "This is simply amazing". > - some short high-level tech-review paper to be submitted to some > relatively well known journal (not sure if we could aim at Science ;-) > but who knows...) which provides a tasty introduction into such an > ideal platform for a scientist, and then brief glance overview how it > addresses those topics everyone in scientific communities > drooling about: reproducibility (e.g. snapshoting with cpack, VMs), > sharing (obvious for anyone in FOSS, but might be worth making it > explicit), methodologies rapid dissemination and adoption, > community-driven (once again -- obvious, but making explicit lack of > commercial company baby sitting etc, would imho be beneficial), etc. I agree -- this is what we should aim for eventually. It is relatively easy to convince tech-folk that Debian has its benefits, it is a totally different thing to get the message out to non-geek scientists. A publication in a journal with good visibility would be very beneficial. It should not be difficult to collect enough superlatives to justify a publication. However, I think, we also have to present a couple of actual scientific endeavours that rely on Debian where we can get some stats on how many lab/people use it for what. Two things I can think of immediately are: - LIGO (http://www.ligo.org; gravitational waves observatory consortium) - and due to personal involvement: NeuroDebian (http://neuro.debian.net) There where numerous others that popped up on this list over the last couple of years. I think that the focus of a manuscript should be on the breadth of scientific fields that Debian supports. We should identify the ones were it excels and emphasize those, but mention all of them. Maybe the respective maintainers could give an opinion how many non-Debian bits are necessary to do research in medicine, physics, biology, Main theme of the paper could be that only via collaborative work we can support such a universal tool. The more specialized a particular application is, the more it relies on software that is written by other and maintained by other from other fields of research (or even outside science). No individual field of research has enough manpower to support such an endeavour on its own. It would not be hard to argue that interdisciplinary collaborations are the major source/driver of innovation in pretty much any context. Debian is just that -- an interdisciplinary collaboration we vast practical benefits that are readily available to anyone who wants them (and knows about them). This paper should have a looong list of authors, with a list of affiliations that the world hasn't seen before! I'd be happy to help writing it. If we start soonish, it should give us enough time to get it published with wheezy's release. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120418074546.GB2898@meiner
Re: Bug#659641: ITP: python-quantities -- Support for physical quantities with units, based on numpy
Hi, I'm attaching my packaging draft (as requested in your other email). See my inline comments below: On Wed, Feb 15, 2012 at 08:57:46AM +, Andrea Palazzi wrote: > the package is already done, it was pretty easy with py2dsc; what i want to > do now is: > - check the created package > - create a git repository > > - add a copyright file: there's no copyright in the original .tar.gz, > the only copyright claim that I've found is at > http://pypi.python.org/pypi/quantities; I've asked upstream to add an > explicit copyright file, but had no answer up to today. BTW, can I > write the copyright file only based on the page on python.org Yes you can, there is also one in the attached tarball. Upstream should add an explicit statement nevertheless. > I would also appreciate some help on creating the git repository, I'm > reading http://wiki.debian.org/Alioth/Git but some things aren't > completely clear to me - e.g. will this be a "collab maint project" ? > the project is debian-science ? Or what ? collab-maint should be fine. I'd advise you to use git-buildpackage to handle source import, etc.. If you like, I can also upload the repo that I already have with my packaging draft and you clone it and add yourself as package maintainer. > I think that by the end of this week I could upload a first and > reasonabily good version of the package to alioth. That sounds perfect! If you need a sponsor for the upload I'd be available for that -- just let me know. Michael -- Michael Hanke http://mih.voxindeserto.de quantitites_packaging.tar.gz Description: Binary data
Re: Bug#659641: ITP: python-quantities -- Support for physical quantities with units, based on numpy
Hi, On Sun, Feb 12, 2012 at 07:49:04PM +0100, Andrea Palazzi wrote: > Package: wnpp > Severity: wishlist > Owner: Andrea Palazzi > Version : 0.10.1 > Upstream Author : Darren Dale > * URL : http://pypi.python.org/pypi/quantities > * License : BSD > Programming Lang: Python > Description : Support for physical quantities with units, based on numpy I have a packaging draft for this one, which I'm happy to contribute -- in case you haven't done it yourself yet (it is fairly straightforward). The reaon I haven't pushed this package yet is that the unittests do not pass and upstream didn't work on this code for a while. I filed some bug reports, but nothing happened yet. In any case, this package is needed as a dependency for a core pyton library for electrophysiology data handling. Therefore I appreciate that you are taking care of quantities. Do you have an anticipated timeframe for an initial upload? Are you aiming at team-maintenance within Debian Science? Thanks, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120213082207.GC22771@meiner
Bug#654750: O: kbibtex -- BibTeX editor for KDE
Package: wnpp Severity: normal I intend to orphan the kbibtex package. I do not have enough time to take care of this package properly. It is in pretty good shape (3.0, quilt, 1 open bug, minimal patches), popcon >1800. The packaging is in Git (pkg-exppsy on git.debian.org). The primary task right now would be to investigate some spurious FTBFS and get this latest upstream release to migrate into testing. I'm willing to sponsor any non-DD taking over this package. The package description is: An application to manage bibliography databases in the BibTeX format. KBibTeX can be used as a standalone program, but can also be embedded into other KDE applications (e.g. as bibliography editor into Kile). . KBibTeX can query online ressources (e.g. Google scholar) via customizable search URLs. It is also able to import complete datasets from NCBI Pubmed. It also supports tagging references with keywords and manages references to local files. . BibTeX files can be exported into HTML, XML, PDF, PS and RTF format using a number of citation styles. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120105144226.6311.45507.reportbug@meiner
Re: Debian Science Psychophysics packages
On Tue, Jun 28, 2011 at 11:41:36AM +0200, Andreas Tille wrote: > If you are interested in an official > Debian package you might consider trying your luck in packaging yourself > and ask for help here on this list. My guess is that the NeuroDebian > team might be specifically interested / helpful. We would indeed be interested in this software. From a quick glance at the website I see some potential problems for a packaging attempt (i.e. Qt3 dependency, which is on the way out of Debian, what is the license, where is the source code). But in general we would be glad to help getting nrec into Debian. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110628114830.GC18880@meiner
Re: Fwd: [atlas-devel] tenure letters
On Wed, Apr 20, 2011 at 09:24:19PM -0400, Yaroslav Halchenko wrote: > > Ack, but I'd prefer something simpler than Google Docs. How about > > Debian Whiteboard (http://whiteboard.debian.net/) > thanks, indeed! > > initiated... I am not in shape to put words in atm, so feel free to > extend Maybe signatures to that letter should include academic titles and/or relevant affiliations -- the letter will finally end up in a dean's office... Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110421140614.GA31213@meiner
Re: Packaging scientific datasets for Debian
On Sat, May 08, 2010 at 12:57:17PM -0500, Steve M. Robbins wrote: > On Sat, May 08, 2010 at 10:05:45AM -0400, Michael Hanke wrote: > > - some grouping by purpose (although many datasets can be used for > > different things) or type of data (MRI, pictures, sound > > databases, genome, ...) > > I like all these suggestions. I don't have a strong position on how > to arrange the data, but my gut feeling is to use a single root under > which it is grouped by purpose as you suggest, leading to > /usr/share/data/, for example. I'm a little unsure about the level of sophistication that the grouping should reflect. Consider this data: http://data.pymvpa.org/datasets/haxby2001/ It is an fMRI experiment that also comes with anatomical MRI images. Where should it go? /usr/share/data/mri/fmri/haxby2001/ It is all MRI data, but its primary purpose is fMRI. But what happens if the dataset also has behavioral data (e.g. recorded reaction time). Would it be split into: /usr/share/data/mri/fmri/haxby2001 /usr/share/data/behavioral/reactiontimes/haxby2001 Sounds complicated and not very useful, because one typically wants to have all related data in one location. What if the data comes with the actual stimulus images (simple JPEGs)? it would still be an MRI dataset, but people looking for a database of images would probably never look into /usr/share/data/mri... Maybe we should try to prevent grouping datasets. People working with MRI data probably tend to have MRI datasets installed, hence the /usr/share/data will be all MRI-related. Maybe the above dataset could be installed under: /usr/share/data/haxby2001-objectcategorization The contained fileformats would be encoded using debtags, and the rest of useful categorization information goes into the package description. What do you think? Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100513182525.ga4...@meiner
Re: Packaging scientific datasets for Debian
On Mon, May 10, 2010 at 11:05:33PM +0900, Charles Plessy wrote: > Le Mon, May 10, 2010 at 06:05:04AM +0200, Joerg Jaspert a écrit : > > On 12109 March 1977, Steve M. Robbins wrote: > > >> http://ftp-master.debian.org/wiki/projects/data/> > > >> Although it makes the impression that everything is already done, I > > >> don't know if that is actually true. Does anyone know about the current > > >> state of this effort? > > > I don't know. But given that data.debian.org doesn't resolve, I'd > > > guess that nothing is set up. The wiki page you reference suggests it > > > is an ftpmaster team consensus position, so I cc them now. Maybe > > > someone there can chime in. > > > > We are waiting for hardware with enouggh diskspace. This is aboout there > > (ftpmaster.d.o replacement). > > Hello Jörg, > > I read in http://ftp-master.debian.org/wiki/projects/data/ that the data > archive will require full source uploads. But if the source package is not a > simple downloader, this will duplicate the data and double the size of the > upload and the archive. Would it be possible to accept binary-only uploads? I > ask the question in particular because with one of our tools, getData, I am > considering to produce binary pakcages from scratch (or with a helper tool > like > equivs, for instance). That way, the data package can originate from a signed > official package distributed in the main archive, but does not need a Debian > source package. For unoffical packages I have used a similar approach: an almost empty source package that build-depends on the binary packages (with exact version) that it is supposed to build. This was once suggested by Anthony Towns: http://lists.debian.org/debian-devel/2007/06/msg00298.html However, FTP master previously expressed dislike of this approach. So I'd rather ask whether source-only uploads would be possible? Packages in question are in the GB range, so the difference is 1 vs 2 GB to be uploaded. Since data.d.o is maintained by the project I'm now less concerned about archive size -- although I still consider it wasteful to duplicate identical data in two different formats (tar.gz, deb). Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100510145614.gb11...@meiner
NeuroDebian is this weeks featured project on NITRC.org
Dear Debian-scientists, on behalf of all the people making it possible to have neuroimaging research software in Debian I'd like to announce that NeuroDebian is this week's featured project on http://nitrc.org NeuroDebian (http://neuro.debian.net) is a project that Yaroslav Halchenko and I created to promote the use of Debian as the ultimate research environment for this field. NITRC is the major resource portal of the neuroimaging research community. To see Debian being advertized on their frontpage is pure delight. Since NeuroDebian is merely the face of Debian in this community, I want to use this opportunity to thank everybody that helps to make this effort possible. This includes all people working on the Debian Pure Blends and their infrastructure -- which does a great job in presenting scientific software packages in a way that helps both potential users as well as acknowledges upstream's requirements (e.g. citations, usage statistics, user registrations). Special thanks goes to all maintainers of special-special-interest packages that often happen to be essential dependencies for the software we are dealing with. It is your work that makes Debian the only platform that is truely universal. Thanks! -- Neuroimaging? NeuroDebian! http://neuro.debian.net -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100508184548.ga27...@meiner
Packaging scientific datasets for Debian
Dear Debian scientists, I want to resurrect the discussion about dataset packaging in Debian. I believe the latest state is reflected by this document: http://ftp-master.debian.org/wiki/projects/data/ Although it makes the impression that everything is already done, I don't know if that is actually true. Does anyone know about the current state of this effort? Anyway, I want to discuss a different aspect of dataset packaging. In neuroimaging research we have a number of 'standard datasets' that are used by many tools (brain atlases, ...). With an increasing number of neuroimaging packages, we see these datasets appearing in multiple packages. I was wondering what could be a good approach to standardize packaging of this kind of data. So far I have included them in application-specific places, i.e. /usr/share//data. But that would obviously duplicate data without necessity. Moreover, it would be nice to have data of some type (e.g. brain-atlases, MRI data, ...) grouped together in a common place that could be used as default data path for relevant applications. I would appreciate your comments on a good approach to this problem -- that scales well to other fields of science too. I'm sure that this type of integration of many packages into a common environment has been approached multiple time before, and maybe one of the solutions can be adapted in this case too. Ideally, we could come up with a mini-policy for dataset packages. It should not be overengineered, but it might cover things like: - package naming, e.g. 'dataset-' - predictable and common location in the filesystem (maybe it should make it easy for an admin to relocate all packaged datasets to a dedicated storage device) - some grouping by purpose (although many datasets can be used for different things) or type of data (MRI, pictures, sound databases, genome, ...) A related long-term goal is to have a supply of datasets that can be used for regression testing of scientific applications. It should make it easier to come up with a dedicated package that implements the regression test and declares dependencies on the necessary data package(s). Thanks in advance for your input, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100508140545.ga19...@meiner
Re: Reproducibility
On Fri, Apr 30, 2010 at 03:23:42PM +0200, Andreas Tille wrote: > On Fri, Apr 30, 2010 at 09:30:16AM -0300, David Bremner wrote: > > > Yes, that's the problem. > > > > For stable releases though, we have the time, and we can (I suspect) get > > the compute cycles to run heavy regression tests. Would that be a > > worthwhile project? > > Well, it is not me who raised this problem and so I do not feel realy > able to give a definite answer. But as I understood the people at > Sanger scientist do not really care about stable Debian. They care > about a really specific version of a specific software. Perhaps the > version in stable is to old - or it might even be to new (if they want > to reproduce old results). I really dobt that these people who are > used to stick to such a version will care about Debians regression > tests if they have the chance to simply install their own version. Right. Usually we have some version in stable and some people will use it. In general, however, people want the stable 'operating system' and _in addition_ a multitude of versions of their critical applications. In Debian we have the universal operating system that incorporates all software and 'stable' is a snapshot of everything at the time of release -- and this is not what scientists want. That is why we have backports.org and neuro.debian.net that offer at least the latest and greatest for 'stable'. But this is still not enough. Ideally, I would keep maintaining each an every package version for an indefinite period of time -- that should make everybody happy, but I'm clearly not going to do this unless my day gets additional 24 hours ;-) BUT: I believe people would be a lot more happy to keep upgrading to latest versions, IF there would be a standardized, upstream-supported method to perform some reasonable tests. This is a topic that Yarik stripped from his talk, but is still very interesting to talk about: We, as Debian, could to a lot to help upstream projects to deploy their software in a more sane way, by offering concrete guidelines and facilities to do what is necessary to ensure proper behavior. IMHO, sticking to old versions is a reality in the science community -- but it is a problem that should be solved and not supported. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100430142954.ga2...@meiner
Re: Reproducibility
Hi, On Fri, Apr 30, 2010 at 10:01:23AM +0200, Teemu Ikonen wrote: > On Fri, Apr 30, 2010 at 2:08 AM, Michael Hanke > wrote: > > Debian: The ultimate platform for neuroimaging research > [...] > > However, it is hard to blame the respective developers, because the > > sheer number of existing combinations of operating systems, hardware, > > and library versions makes it almost impossible to verify that a > > particular software is working as intended. Restricting the > > ``supported'' runtime environment is one approach of making > > verification efforts feasible. > > Dear list, > > This nice abstract inspired me to think about reproducibility of > program runs. If one runs e.g. Debian unstable the OS code which can > potentially affect the results of calculations can change almost > daily. Reproducing results later can be close to impossible unless > versions of all the related libraries etc. are written down somewhere. This is not just a potential problem -- we have seen it happen already. Part of the problem is that in Debian we prefer dynamic linking to up-to-date shared libs from separate packages -- instead of statically linking to ancient versions with known behavior (for good reasons of course). > Does anyone here have good ideas on how to ensure reproducibility in > the long term? The only thing that comes to my mind is to run all > important calculations in a virtual machine image which is then signed > and stored in case the results need verification. But, maybe there are > other options? IMHO better than relying on a snapshot of OS and a particular software state to get constant results, projects should have comprehensive regression tests that ensure proper behavior. The problem is, however, that we cannot run then during package build time, since they tend to require large datasets and run for many hours. Therefore users need to do that, but nobody does it. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100430110721.ga26...@meiner
And one more (Re: yet another talk submitted)
Hi,
On Thu, Apr 29, 2010 at 02:24:23PM -0400, Yaroslav Halchenko wrote:
> On Wed, 28 Apr 2010, Kumar Appaiah wrote:
> > In addition, if folks here have a request for a talk on a particular
> > topic, which they would not be able to present themselves, it would
> > still be nice to convey the suggestions to the list and/or Michael,
> > so that others who might like the idea could take it up, and
> > potentially talk about that subject.
>
> Although not requested, I've decided to share the abstract I've just
> submitted. I wanted to get your feedback (does it sound worth
> "lecturing" or may be some kind of "discussion" would be more
> appropriate).
Here is my own submission -- related to Yarik's in that it is a
concrete example of (successfully) promoting Debian in a particular
field of science -- neuroimaging research.
Debian: The ultimate platform for neuroimaging research
Over the past decade the neuroimaging research community has
fortunately converged on the open source software development model,
with the vast majority of all widely used applications and libraries
being available as source code, and a substantial proportion covered
by free software licenses. Today, there exists a large code base for
data collection (e.g. behavioral psychological experiments), data
analysis (e.g. of functional magnetic resonance imaging; fMRI), and
data visualization that is productively used in everyday research
activities. A representative list of available tools is provided on
the NITRC portal [0].
Initially, most of these tools were mere by-products of actual
neuroscience research projects, developed by students, and scholars
who are, in general, not trained software engineers. As a result,
software development in this field still differs significantly from
established good practices in the free and open source software
(FOSS) community. Many projects start without a clear deployment or
management concept, and due to lack of man-power are later on forced
into an \textit{ivory tower development} model -- restricting the
``supported'' environment as an attempt to reduce the required
maintenance effort. They try to decouple themselves from ongoing
developments and include specific versions of all external
dependencies into their source distributions. The result is too often
a fork that is no longer updated with bugfixes or enhancements. Many
useful projects die because it becomes too expensive to update them.
However, it is hard to blame the respective developers, because the
sheer number of existing combinations of operating systems, hardware,
and library versions makes it almost impossible to verify that a
particular software is working as intended. Restricting the
``supported'' runtime environment is one approach of making
verification efforts feasible. On the other hand, development in the
free software community sometimes proceeds at an enormous pace,
and many projects do frequent releases with sometimes
backward-incompatible changes. Forcing a dependency on an outdated
release shifts the burden of maintenance and deployment onto users, as
it gets increasingly difficult to have older releases available. On
the other hand, continuously updating software to the latest
developments is a time-consuming task for which there is no immediate
scientific benefit.
I will argue that Debian is the ideal solution to this problem. This
talk will provide an overview of current projects and individual
efforts within Debian that help researchers to maintain a
fully-functional Debian-based environment for neuroscience research
with minimal effort (e.g. Debian Med, Debian Science). Moreover, it
introduces NeuroDebian [1] -- a platform specifically targeting the
neuroscience community. I'm going to show several case examples of
packaging efforts that illustrate typical problems, such as
non-commercial/non-standard licenses, non-existing upstream bugtracker
and unavailable version control systems. Furthermore, I will offer
some evidence that a substantial migration towards Debian is already
under way. Popularity statistics and personal communication indicates
that a growing number of researchers see it as 1) making neuroscience
software (e.g. for medical imaging) accessible to a larger user-base,
and reducing the required maintenance effort on the user side, 2)
improving software quality, and 3) enabling developers to spend more
time on developing new scientifically relevant features. The talk will
conclude with thoughts on what Debian could do to further facilitate
its adoption as the ultimate platform for scientific research, such
as tailored guidelines for deployment and project management,
possibility to run complete regression test suites, as well as
reliable usage statistics to justify funding project funding.
[0] http://www.nitrc.org
[1] http://neuro.
Re: Math/Science track for Debconf10: Presentations/Talks and coordinator needed
Hi, On Mon, Apr 26, 2010 at 12:05:22AM +0200, Sylvestre Ledru wrote: > Hello, > > > Le dimanche 25 avril 2010 à 15:24 -0500, Kumar Appaiah a écrit : > > > > Would anyone like to volunteer to coordinate a track on Science and > > Mathematics > > in Debian for DebConf 10, or nominate someone who would do this well? > > > This would be my first DebConf but it is not a problem, I could help (or > manage) on the coordination of the Science track. > > I am also planning to present Debian Science to the DebConf. It will also be my first Debconf, so I'm not sure whether I can be of any help organizing. But I would like to participate in the track and present a little success story about Debian in neuroimaging research. Should I wait submitting an abstract until a track has been formally organized? Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100426004559.ga31...@meiner
Re: Publication information for tasks pages
On Wed, Sep 02, 2009 at 03:41:43PM +0200, Andreas Tille wrote: > On Wed, Sep 02, 2009 at 09:13:59AM -0400, Michael Hanke wrote: > > The vast majority of all scientific (if not all) publications receive a > > DOI (Digital Object Identifier). Those can be resolved by appending them > > to this base URL: > > > > http://dx.doi.org/ > Ahh, OK. So a "Publication-DOI" field makes perfectly sense. > Could you please send me a layout snippet how this should be > rendered on the tasks pages? Publication-URL will be used as > > Publication-Title > > Should we just use Publication-DOI to put a link on the title > and only override this if an explicit Publication-URL is given? > Or should a different field (Publication-In ??) be used to link > to DOI. Or should we use IMHO the DOI should be the default URL provider. If there is need for a special URL (e.g. in case there is a freely available preprint floating around somewhere, whereas the DOI points to a pay-per-view source) it could be added in addition to the DOI link. Maybe like this: Only DOI available Publication-Title Only URL available Publication-Title Both available Publication-Title (DOI) The DOI itself could be made visible too, but it can get lengthy and might clutter the package item. > Feel free to add plain > > Publication-DOI > > fields (without 'X-') in the tasks files which has the effect of > warning about unknown fields in the logs so I will not forget this > definitely useful feature. Will do! Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke > Feel free to add plain > > Publication-DOI > > fields (without 'X-') in the tasks files which has the effect of > warning about unknown fields in the logs so I will not forget this > definitely useful feature. > > Kind regards > > Andreas. > > -- > http://fam-tille.de > Klarmachen zum Ändern! > > > -- > To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Publication information for tasks pages
Hi, On Wed, Sep 02, 2009 at 02:55:42PM +0200, Andreas Tille wrote: > On Wed, Sep 02, 2009 at 08:37:26AM -0400, Michael Hanke wrote: > > One question comes to my mind: 'X-Published-doi' is used in med-bio. > > Does it have any effect, i.e. an auto-generated URL whenever there is no > > 'Published-URL' available? > > Any field name starting with 'X-' is just ignored. So X-Published-doi > does just nothing but is a placeholder for others to fix the publication > information. (I have no idea what doi means ...) > > If there is any *robust* way to auto generate URLs just tell me to let > me consider implementing this. There is: http://www.doi.org/ The vast majority of all scientific (if not all) publications receive a DOI (Digital Object Identifier). Those can be resolved by appending them to this base URL: http://dx.doi.org/ i.e. http://dx.doi.org/10.3389/neuro.11.003.2009 That will redirect you to the publication. Moreover also the KDE konqueror also understands the 'doi:' protocol... Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Publication information for tasks pages
Hi, On Wed, Sep 02, 2009 at 08:43:10AM +0200, Andreas Tille wrote: > in Debian Med we have started to add publication information to the > tasks files. I guess there is also some interest in Debian Science. > Just see the doc[1] and look for "Registration" and "Published-*" fields > you might like to add to some packages. Examples for use are in the > med-bio tasks file[2] and here you can see how it is rendered on the > tasks page[3]. > > I hope you like this and might use it for other packages until we found > a more general approach to add this information directly to package meta > information inside Debian. Thanks for implementing this. I'm going to add this info to the med-imaging packages I know references for. One question comes to my mind: 'X-Published-doi' is used in med-bio. Does it have any effect, i.e. an auto-generated URL whenever there is no 'Published-URL' available? Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#426581: RFS: Meshlab
Hi, On Sun, Jun 14, 2009 at 09:30:00AM +0200, Andreas Tille wrote: > On Fri, Jun 12, 2009 at 10:54:17AM +0200, Teemu Ikonen wrote: > > > > Your wish is (hopefully) soon fulfilled. Yaroslav Halchenko sponsored > > this package last week and it is currently waiting for final checks at > > the NEW queue (http://ftp-master.debian.org/new.html) > > If you want to monitor our prospective packages in new queue, you > might look at the respective tasks page. Meshlab is now mentioned > here: > > http://blends.debian.net/science/tasks/physics#new-debs > > This is one of the new features the UDD based code for the tasks > pages. Please note that this is not yet implemented at the > official alioth pages[1] because the new queue content is not > (yet) moved to official UDD (but will probably quite soon). > > Comments are welcome This page has a section 'Unofficial packages builded by somebody else' should probably be 'Unofficial packages built by somebody else' ^ Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: note-taking and PDF annotation: jarnal
On Wed, Apr 08, 2009 at 02:55:49PM +0200, Jan Beyer wrote: > David Bremner wrote am 4/8/2009 12:30 PM: > > Michael Hanke wrote: > > > >> On Tue, Apr 07, 2009 at 05:16:00PM -0300, David Bremner wrote: > >>> > >>> Xournal is in debian, and seems to work OK. Is jarnal superior to > >>> xournal in some way? > > > >> Okular also has annotation capabilities and is in Debian. > > > > My experience with okular annotation has not been too positive so far. > > Some of it is just bugs because the features are new, but also I find > > the current okular model of storing the annotations in ~/.kde not very > > useful. On the other hand, okular deals with PDF as PDF, rather than > > rasterizing it, as I believe xournal does. So these two at least have > > different niches. > >From my quick look at the xournal homepage, I also had the impression > that xournal uses pdftoppm or something like this. And keeping > modifications in your local home-directory is only fine as long as you > only use the file from this one account... Hmm, I have used xournal before and it can both store anotations as an overlay, as well as producing a PDF with the original content and the annotations overlayed. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: note-taking and PDF annotation: jarnal
On Tue, Apr 07, 2009 at 05:16:00PM -0300, David Bremner wrote: > > At Tue, 07 Apr 2009 22:11:29 +0200, > Jan Beyer wrote: > > > > Hi debian-science, > > > > I just stumbled upon jarnal [1], a free Java program to take notes using a > > stylus or mouse or keyboard with the additional ability to make annotations > > and markings in PDF-files. It's exactly what I was looking for for a long > > time. In case, somebody wants to reduce the amount of printed out scientific > > papers just to be able to make some annotations, that's probably one > > interesting thing to check out! ;-) > > > > Xournal is in debian, and seems to work OK. Is jarnal superior to > xournal in some way? Okular also has annotation capabilities and is in Debian. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Additional task: science-neuroscience
On Wed, Mar 11, 2009 at 09:15:43AM +0100, Andreas Tille wrote: > On Wed, 11 Mar 2009, Michael Hanke wrote: > >> I think that it would be useful to have such a package, as the >> interesting candidate packages are a bit scattered around. Neuroscience >> research includes conducting psycho(logical,physical) experiments >> (pyepl), brain-imaging related work (med-imaging, although not >> necessarily targeting medical topics), including analysis and >> visualization (science-imageanalysis, -numericalcomputation), but also >> the statistical analysis of behavioral data (science-statistics). As >> large parts of the neurosciences are closely-related to psychology it >> could also absorb packages not even listed in any task right now (e.g. >> praat). >> ... >> I'd volunteer to take care of such a meta-package, if that is necessary >> at all, or helps to establish such. > > I'm in favour of this idea. As I explained here several times in the past > I see Debian Science as a pool of potentialy separate Blends dealing with > and specific science which might sit here until there is enough interest > and man power to form a stand-alone team. In some fields this might happen > in others this might never happen and they might sit under the Debian > Science umbrella for ever - that's fine and that's definitely better than > if there would be no support of the scientists in this field at all. > > So finally the idea is to provide a structured access to people working > in a specific field and your users in the field of neuroscience will be > very happy if you assemble a set of packages that will be useful for > their day to day work. Is there anything against making users happy? > > There might be an arguing that there are other specific applied sciences > which might "deserve" their own task which ends up in a metapackage. > Well, yes, there definitely are - but the question is always: Who is > willing to do the work to assemble a reasonable list of packages (if > there are such packages inside Debian at all). IMHO this is the cruxial > point here. So if you are willing to do this - just go for it. > (To enable you injecting the tasks file I just added you to the > Debian Pure Blends project on alioth.) Thanks a lot! I'll dig myself through the docs to see how it works. Cheers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Additional task: science-neuroscience
Hi, while parsing the task listings of debian-science and -med I started to wonder whether it would be useful to add another one. I'd like to hear your oppinions about establishing a 'science-neuroscience' meta-package. The justification would be to provide a single point of entry for a neuroscience workstation (what else). I think that it would be useful to have such a package, as the interesting candidate packages are a bit scattered around. Neuroscience research includes conducting psycho(logical,physical) experiments (pyepl), brain-imaging related work (med-imaging, although not necessarily targeting medical topics), including analysis and visualization (science-imageanalysis, -numericalcomputation), but also the statistical analysis of behavioral data (science-statistics). As large parts of the neurosciences are closely-related to psychology it could also absorb packages not even listed in any task right now (e.g. praat). And finally there are not-yet-created packages I have no clue where to put in the current set of meta-packages, e.g. http://topographica.org/Home/index.html (clearly neuroscience, but not imaging per se, yet not a general purpose simulator, ...) I'd volunteer to take care of such a meta-package, if that is necessary at all, or helps to establish such. What do you think? Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
More info and interest
Hi, [cross posting to debian-science and debian-python] I want to draw you attention to an RFP that might deserve more attention: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515319 It is concerned with a Matlab-to-Python "converter". The project aims to aid the conversion of Matlab code to Python. While this software seems to be in a rather early stage of development it has nevertheless the potential to become a mighty tool to facilitate the migration of an unestimable amount of Matlab code to a free language/computing environment and hence a global migration toward the use of free software. These guys published a paper about their compiler in the journal 'Frontier in Neuroinformatics' (open-access as it should be ;) http://www.frontiersin.org/neuroinformatics/paper/10.3389/neuro.11/005.2009/ According to the journals access statistics it receives an impressive amount of attention. It would really cool to have that beast in the flagship of free software (which is Debian for those who wonder ;). Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Software for poster presentations
Hi, On Sun, May 18, 2008 at 11:13:03PM +0100, Stuart Prescott wrote: > > Hi All, > > As a brief respite from packaging discussions, here's a user question: > > What software would you use or recommend for preparing a poster for > presentation at a conference? [0] > > A few things come to mind straight off -- perhaps existing users can make > comments on these things: > > * openoffice impress or draw: I guess these would be the same as doing a > poster in powerpoint, with the same limitations. Does it work OK? > > * inkscape: can it handle flowing and editing text nicely? I've only ever > used > it for drawing. I see it's debtagged as "works-with-format::tex" which I find > intriguing but don't know what that means in practice. I know it has > bugs/limitations in being able to compress jpeg images which could result in > an obscenely large PDF export when it comes to producing the final product. > > * scribus: I've never used it but by its description it sounds like a good > tool for the job; I've heard it's a bit quirky but that it's a good program > for this sort of thing. Over the last years I have tried to use all of the above to prepare posters. I have to say that inkscape is by far the best. It is true that it is quite bad with text editing, but usually you do not want much text on a poster and inkscape indirectly helps with it ;) However, for the last poster I needed syntax highlighted code (which would be a PITA to do with inkscape), but since 0.46 you can import PDF files. So I used the PDF of some latex-beamer slides and imported the Latex-rendered code (which obviously also works for plain text). Moreover, working with SVG as the base format it is quite easy to put the poster in version control and work together with several people. Additonally inkscape can import almost all reasonable formats, so you are free to use dia or xfig for plot. However, since I do most data analysis in Python I can really recommend matplotlib for plot which is able to export directly to SVG. HTH, 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: PyGPU
Hi, On Mon, Oct 15, 2007 at 09:43:02AM -0500, Dirk Eddelbuettel wrote: > > GPU programming from Python: > http://www.cs.lth.se/home/Calle_Lejdfors/pygpu/ > > Looks promising, but I still don't really speak Python. Anybody with more > skills and some free time interested in packaging this? Looks like this is already happening: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446687 Cheers, Michael -- 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]
Re: Thoughts on distributing virtual machine images to promote Debian
Hi, [ Daniel: sorry, I initially only replied to you ] 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
Re: Bug#387183: marked as done (ctn: Cannot open ANY dicom file on AMD64)
> Date: Tue, 12 Sep 2006 21:37:08 +0200 > From: Michael Hanke <[EMAIL PROTECTED]> > To: Debian Bug Tracking System <[EMAIL PROTECTED]> > Subject: ctn: Cannot open ANY dicom file on AMD64 > X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_PACKAGE, > RCVD_IN_SBLXBL,RCVD_IN_SBLXBL_CBL autolearn=no > version=2.60-bugs.debian.org_2005_01_02 > > Package: ctn > Version: 3.0.6-8 > Severity: serious > > > Hi, > > I'm packaging a DICOM -> NIfTI converter which uses the CTN library. I had to > discover that the converter does not work on AMD64 machine, while everything > is > ok on i386. > > I tracked the bug down to the DCM_OpenFile() call. Originally I wanted > to create a minimal demo that shows the bug and ask for help concerning > a bug in the converter. But when I was about to prepare a demo dicom file I > discovered that the whole ctn package is unusable on AMD64. > > I tried several dicom files and CTN commands. I always get something similar > to this on AMD64: > > > [EMAIL PROTECTED]:~/hacking$ dcm_dump_file test.dicom > DICOM File: test.dicom > 190092 DCM Data Element ( ) longer (140733193388032) than remaining > length (580448) of data in stream or file in readFile >20092 DCM failed to open file: test.dicom in DCM_OpenFile > Could not open test.dicom as expected. Trying Part 10 format. > 190092 DCM Data Element (0002 0001) longer (140733193388034) than remaining > length (580300) of data in stream or file in readFile >20092 DCM failed to open file: test.dicom in DCM_OpenFile > > > While the same command on i386 works as expected: > > [EMAIL PROTECTED]:~/hacking$ dcm_dump_file test.dicom > DICOM File: test.dicom >c0092 DCM group/element out of order ( ) in checkAttributeOrder >20092 DCM failed to open file: test.dicom in DCM_OpenFile > Could not open test.dicom as expected. Trying Part 10 format. > > DCM Dump Elements > Object type: ELEMENT LIST > Object size: 580456 > Group: 0002, Length: 196 > 0002 4 // META Group Length// c4 196 > > > > > So effectively no command works, because no dicom file can be opened. > > I only have access to a single AMD64 machine running etch/sid, so I was > not able to confirm this bug on another machine. > > I was a bit unsure about the bug severity, but I think this is not just a > normal bug, because it renders the package completely unsusable on this arch > (given this bug is not limited to my machine). > > > > Thanks, > > Michael > > > > -- System Information: > Debian Release: testing/unstable > APT prefers testing > APT policy: (600, 'testing'), (200, 'unstable') > Architecture: amd64 (x86_64) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.16-2-amd64-k8-smp > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) > > Versions of packages ctn depends on: > ii libc62.3.6.ds1-4 GNU C Library: Shared libraries > ii libmysqlclient15off 5.0.24-3mysql database client library > ii libx11-6 2:1.0.0-8 X11 client-side library > ii libxaw7 1:1.0.1-5 X11 Athena Widget library > ii libxext6 1:1.0.0-4 X11 miscellaneous extension > librar > ii libxmu6 1:1.0.1-3 X11 miscellaneous utility library > ii libxt6 1:1.0.0-5 X11 toolkit intrinsics library > ii zlib1g 1:1.2.3-13 compression library - runtime > > ctn recommends no packages. > > -- no debconf information > > -- > GPG key: 1024D/3144BE0F Michael Hanke > http://apsy.gse.uni-magdeburg.de/hanke > ICQ: 48230050 > Date: Thu, 21 Sep 2006 16:09:34 +0200 > From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Fixed in NMU of ctn 3.0.6-8.1 > X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no > version=2.60-bugs.debian.org_2005_01_02 > > Version: 3.0.6-8.1 > > I've NMUed for this bug (fixing the bug to use versioning instead of the > "fixed" tag, to ease tracking through testing); here's the changelog: > > > ctn (3.0.6-8.1) unstable; urgency=medium > > . > >* Non-maintainer upload. > >* In the LONG_WORD structure, always use unsigned int since we want a > > 32-bit > > variable, and int is 32 bits on all platforms supported by Debian (it > > used > > to be unsigned long for all platforms except alpha, which broke on > > platforms such as ppc64 and amd64). (Closes: #387183) > >* Build-depend on lesstif2-dev instead of lesstif-dev, since the latter > > is > > obsolete. Awesome. Thanks a lot! Best, 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: How much interest in a "debian-science.org" repository?
On Wed, Jul 19, 2006 at 12:07:40PM -0400, Kevin B. McCarty wrote: > Dear list, > > Currently there are a fair number of repositories of science-related > unofficial Debian packages out there. I've been thinking that it might > make sense to consolidate them into a single site. This would have > several advantages: - snip - I think this is a great idea and Debian-science community could gain a lot with this central repository. But IMHO its success might depend on the details: 1. What Debian versions will be supported (or what Debian derivatives)? I maintain some unofficial packages related to experimental psychology and MRI data analysis. From user feedback and the download stats I know that people seem use my packages with sarge, etch and Ubuntu breezy and dapper more or less equally often. Moreover, a single lab often uses a mixture of the above. Therefore I try to provide binary packages for all those distributions. Perhaps this is just a special case, but it might be similar with other packages. I know that some people simply do not care about Ubuntu, but there is obviously a demand and most of the time porting a package to an Ubuntu release is just recompiling it. What I want to say is, that I would prefer a repository that provides packages for every distribution and platform that people (maintainers) are willing to support. 2. What are the requirements a package has to meet to be included in the repository (e.g. license)? If a package is perfect in any sense it could obviously go directly into the Debian archive. Therefore the repository will contain imperfect packages and the question is what kind of imperfection is tolerated (lintian error, minor/major licensing issues, ...)? 3. Who will be able to upload packages? If only DDs are able to upload packages the number of contributors is (unecessarily?) limited. But if the Debian-science repository aims to provide the same quality and security as the main archive, there is no way around it. If the repository is intended to be more open than the Debian archive, and I think it should be, then I see two possibilities: 1. Everybody gets upload rights. This is simple, but might be the source of serious trouble. 2. Perhaps a procedure similar to Alioth would be a reasonable way to deal with upload rights: Potential contributers explain what they want to provide and get upload rights if they provide a solid explanation. From that point on they have the right to upload new packages, but not to upload new versions of packages already in the archive where they are not (co-)maintainers. DDs might be an exception of the rule. This should not limit the number of contributors and introduces a minimal protection against bad guys. The main disadvantage is that somebody has to implement this. I hope we can get this done somehow and I would really like to contribute my packages. Cheers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
ITP: python-visionegg -- Python library for 2D/3D visual stimulus generation
Package: wnpp Owner: Michael Hanke <[EMAIL PROTECTED]> Severity: wishlist *** Please type your report below this line *** * Package name: python-visionegg Version : 1.0 Upstream Author : Andrew D. Straw <[EMAIL PROTECTED]> * URL : http://www.visionegg.org * License : LGPL Programming Lang: Python Description : Python library for 2D/3D visual stimulus generation The Vision Egg is a programming library that uses standard, inexpensive computer graphics cards to produce visual stimuli for vision research experiments. This is my first python package. I tried to follow the Debian Python Policy, but I would very much appreciate comments on the packaging. The package is available from mentors.d.n Please note that the ITP is still missing in debian/changelog. Anyway, linitan is happy (and quiet) and the package builds with pbuilder as expected. There is at least one open issue. I could not build the docs in HTML format, because I would need to build-depend on latex2html (which is in non-free). I read about this issue, but could not find an alternative. Could anyone please point me to some solution. In the future this package will be maintained by the Debian Experimental Psychology project on alioth. http://alioth.debian.org/projects/pkg-exppsy/ Cheers, Michael -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (600, 'testing'), (200, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-1-amd64-k8-smp Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 signature.asc Description: Digital signature
Re: PSIGNIFIT package for fitting psychometric functions
2005/8/31, Andreas Tille <[EMAIL PROTECTED]>: > On Tue, 30 Aug 2005, Rafael Laboissiere wrote: > > > Michael might also include a script with a regression test in the > > package, something like: > > > > #!/bin/sh > > > > prog=/usr/bin/psignifit > > exdir=/usr/share/doc/psignifit/examples > > > > if test -x $prog ; then > > $prog $exdir/dat $exdir/prefs > > else > > echo 1>&2 "$prog not found" > > exit 1 > > fi > This would be a nice enhancement. > Where am I supposed to include such script. Should it be run in the postinst script (probably not) or should I just include it somewhere like in /usr/share/doc/psignifit/tests. Another remaining question for me is: When I'm going to repackage the source tarball, should I then also fix the permissions of the files. Or should I touch as less as possible? Ciao, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050
Re: PSIGNIFIT package for fitting psychometric functions
Am Dienstag, 30. August 2005 15:29 schrieben Sie: > On Tue, 30 Aug 2005, Michael Hanke wrote: > > As Rafael pointed out, I used the standalone tarball > > (psignifit-2-5-6-bin.tar.gz) which included all additional documentation > > files. > > Please specify the exact URL of this file in the copyright file to avoid > confusion. > Done. > > Hmmm, I'm not sure what Rafaels thought, but I understand him that way that > removing the binary is fine. At least I would definitely vote for using a > stripped down tarball and mention the exact reasons in the README.Debian. > This will not lead to confusion and does not waste disk space with useless > stuff. > > I would like to hear what Rafael thinks about the package you provided > there now. If he says it is fine he could go for an upload (or just ask me > to upload if he thinks it is better that I will sponsor this). If he > thinks that the binaries should be stripped we agree for this point. > Raphael, in any case let me here how we want to proceed. > I would remove the binaries from the source tarball too. Since they are completely useless to the user. But I'll wait for Rafaels oppinion. Ciao, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 pgpatYX0VEmlN.pgp Description: PGP signature
Re: PSIGNIFIT package for fitting psychometric functions
Hi again! As Rafael pointed out, I used the standalone tarball (psignifit-2-5-6-bin.tar.gz) which included all additional documentation files. To reduce the confusion I followed Rafaels advice and modified the package in that way, that it now uses the original tarball (without any modification -- even the binary files included)). For the same reasons the permissions of the files in the original tarball are now (again) as the upstream author (wrongly) set them. The package is here: http://apsy.gse.uni-magdeburg.de/~hanke/debian/psignifit/ Ciao, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 pgpbHD9fcRXXj.pgp Description: PGP signature
Re: PSIGNIFIT package for fitting psychometric functions
Hi! Thank you, Rafael Laboissiere and Andreas Tille for your comments on my packaging-attempt. I have now filed an ITP bug (Bug#325671) and changed the changelog so that it closes it on upload. I cleaned up the rules file and fixed the permissions in the upstream tarball. The textfiles where already in the upstream sources. That's why I saw no reason to write a README.Debian file. Regarding the integration into Debian-Med I think PSIGNIFIT is a research related program. Therefore I suggest classifying it like that. You can find the updated version of the package here http://apsy.gse.uni-magdeburg.de/~hanke/debian/psignifit/ Greetings, Michael PS: There is another package I made, but no one seems to be interested in. It is an iptables firewall configuration script which is extremly easy to use (almost idiot proof). See http://rocky.eld.leidenuniv.nl/ What do you suggest, where I should ask for a sponsor for this package? I did send a request to debian-mentors but got no reply. -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 pgppoeSJLoyu7.pgp Description: PGP signature
PSIGNIFIT package for fitting psychometric functions
Hi! I wonder if anyone on this list is involved in psychophysical experiments? I often need to fit psychometric functions to data from such experiment. But as far as I know, there is no program in Debian that does this properly. Some time ago I discovered PSIGNIFIT (http://www.bootstrap-software.org/psignifit/) and have used it almost exclusively since then. Now I tried to package it for Debian and uploaded the result to mentors.debian.net. If some DD is reading this -- please upload it to Debian, if it is done right (or tell me if not). I know, I should ask this on debian-mentors. But if anyone is interested in that kind of software, he/she will be more likely on this list. Regards, Michael Hanke -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 pgpDt6HjLcsf6.pgp Description: PGP signature
