Re: Fwd: heudiconv FTBFS on i386
Hi Alexandre, Do we know any details on how much memory we have on that i386 box? meanwhile I made a record against nibabel https://github.com/nipy/nibabel/issues/1307 on this. Here -- we could potentially just skip (announce xfail) that particular test (test_reproin_largely_smoke) on i386? could even do upstream if would be of any help (to not mess around with patches etc) On Fri, 15 Mar 2024, Alexandre Detiste wrote: > Whoops I sent to the wrong list. > -- Forwarded message - > Date: mer. 13 mars 2024 à 11:07 > To: Debian Med Packaging Team > Hi, > I'm refreshing heudiconv. > It fails to build on i386. > https://salsa.debian.org/med-team/heudiconv/-/pipelines/651879 > The lazy solution is to drop more & more 32 bit support. > ... but maybe this package can still be fixed. > I'll have a look again later. > Greetings -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: Bug#1065841: Taking over datalad to either Debian Med or Debian Science team
Hi Andreas, Let's keep DataLad under our (NeuroDebian) umbrella for now, since we are also upstream there and project is active. We are also working with Vasyl (CCed) to experiment with some semi-automation for package updates/backports (for neurodebian) and datalad (and some of its ecosystem) packages are the target. Packaging will be on salsa. We might move them under larger Med or Science teams, but not just yet. Re #1065841 specifically -- while trying to build updated package I experienced some odd side-effect (pip started to try to install tqdm) and didn't see immediate reason.I will see how well it goes on debian infra after source only upload (did now). Cheers, -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: Do we need pynwb - if yes please care for its new dependency
Hi Andreas, Thank you for taking care about upgrades of pynwb and hdmf! FWIW popcon is likely small because we never packaged downstream packages which use pynwb and usually just instructed people to "pip install" them. And as a developer, I usually had to do the same anyways. The reason for current packaging hurdle is a switch from pypi to github in debian/watch: pynwb uses git submodule for src/pynwb/nwb-schema/ which they package within pynwb pypi releases. I double checked it that they still do as they did before: ❯ for f in pynwb-2.*; do echo $f; tar -tzvf $f | grep src/pynwb/nwb-schema/ | wc -l; done pynwb-2.1.0.tar.gz 15 pynwb-2.2.0.tar.gz 15 pynwb-2.3.0.tar.gz 15 pynwb-2.4.0.tar.gz 15 pynwb-2.5.0.tar.gz 15 So a solution would be to revert going to monitor github and then reimport source. I do not think it is worthwhile packaging nwb-schema at this point since small and unlikely we would bother packaging any other package which would use it directly. Do you agree to such changes -- then I could do the needed dance with git repo , just let me know. Cheers! On Thu, 21 Dec 2023, Andreas Tille wrote: > Hi Yaroslav, > I bumped pynwb to its latest upstream version a couple of times. It was > not release in any stable release since o-o-stable since the package was > always in a bad state. Popcon is pretty low[1] - but we do not see any > Ubuntu users here so may be that's a weak metric. > My recent update in Git to latest upstream has uncovered that it needs > a new predepends[2]. If you consider this package a good citizen inside > Debian it would be great if you would care for this new package. Other > bugs should be fixed in Salsa, thought. > Kind regards > Andreas. > [1] https://qa.debian.org/popcon.php?package=pynwb > [2] https://github.com/NeurodataWithoutBorders/nwb-schema -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: included git submodules
On Fri, 21 Oct 2022, Maarten L. Hekkelman wrote: > Suggestions, opinions? What is done with other packages that rely on > submodules? those feel like worth their own packages or you could establish your own "mhekkel-toolkit" library "upstream" to contain those two and any other similar one if you want to maintain 1 instead of 2 (and may be later more) packages ;) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: Heudiconv moved to Debian Med repository
On Wed, 17 Nov 2021, Nilesh Patra wrote: > > Argh, that was what I intended to mention: I just uploaded heudiconv > > 0.9.0-3. I checked 0.10.0 but there were build time issues thus I did > > not bumped the version to be able to upload. > I fixed the tests an uploaded. coolio, thanks! will check the fixes out if anything to upstream > However, I noticed that the binary heudiconv_monitor, which had always > been there is unusable (ever since again) due to inotify not being in > the archive, so if someone has free cycles > (and no, it is not compatible with pyinotify) FWIW I don't think it is use by anyone, should be safe to strip away if really not usable -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik signature.asc Description: PGP signature
Re: Heudiconv moved to Debian Med repository
On Wed, 17 Nov 2021, Andreas Tille wrote: > > I thought we were up to date with connectome-workbench ... yeap - we > > are. Upstream is "involved" with uploads so we keep it uptodate afaik. > > Also upstream (in both cases, we are the upstream of heudiconv) is > > interested in neurodebian backports, at least for the most recent debian > > stable -- so ideally those packages should not jump onto bleeding edge > > packaging changes which would make them incompatible with debhelper etc > > in debian stable. > Nilesh asked me to move this one and I guess he has some reason to pick > this. Current Debian stable has debhelper 13 so this should be no > issue. Debhelper 13 is also backported for old-stable - so I do not see > any potential breaks here. if need comes (e.g. upstream wants backports on older debian/ubuntu), I just would like to reserve the right to provide "dsc" patches under debian/patches -- they would not be listed in debian/patches/series, so will not interfere but would simplify building backports for neurodebian -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik signature.asc Description: PGP signature
Re: Heudiconv moved to Debian Med repository
thank you very much Andreas! May be worth uploading new version (even if only to announce the move) so if we forget about the move we have a better chance to detect it? I thought we were up to date with connectome-workbench ... yeap - we are. Upstream is "involved" with uploads so we keep it uptodate afaik. Also upstream (in both cases, we are the upstream of heudiconv) is interested in neurodebian backports, at least for the most recent debian stable -- so ideally those packages should not jump onto bleeding edge packaging changes which would make them incompatible with debhelper etc in debian stable. On Wed, 17 Nov 2021, Andreas Tille wrote: > Hi, > just to let you know: I've imported heudiconv to Debian Med team > repository[1]. Please make sure you pull from there in case you > intend to commit further to this package. > I also imported connectome-workbench[2] and Nilesh wants to > upload a next package version soon. > Kind regards > Andreas. > [1] https://salsa.debian.org/med-team/heudiconv > [2] https://salsa.debian.org/med-team/connectome-workbench -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: Progress in merging neurodebian team?
On Sat, 13 Nov 2021, Andreas Tille wrote: > > Do we have a, sort of ETA to do this? > I do it >A) if I have time _and_ >B) I find some specific issue on a package > Issues can be RC bugs, package not in testing, broken watch file etc. > There are packages I gave up. For instance I have some mental note on > fsl saying: non-free, outdated (upstream has version 6.0) and terribly > complex. yeah, don't bother with FSL! Even though still popular, non-free license, and no longer fully open source AFAIK. If any other alternative in purpose -- pick up AFNI please. Major (if not all) licensing issues were resolved, we never uploaded to debian proper though. Upstream is very receptive and friendly. Problems: - age (in how long it has been out there, but it is still active) - original build infrastructure was "suboptimal",Michael redid in cmake, upstream worked on establishing their own cmake build infra but they are not actively use it our aged, not updated in awhile packaging: https://github.com/neurodebian/afni/tree/debian upstream: https://afni.nimh.nih.gov/ https://github.com/afni/afni -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik signature.asc Description: PGP signature
Re: Introduction
Hi Enric, thank you for reaching out! I just want to follow up on one aspect: even without any coding/packaging, everyone can contribute to the big long lasting positive effect for Debian and "Open" science/software/health/... by promoting open practices, software and licenses to apply and legal safeguards (e.g. participant consent forms etc). Quite often in Debian (and elsewhere) we encounter interested in open sharing researchers who have not thought about open sharing whenever they initiated study or the project. That often makes it hard or impossible for THEM later to either share the products of their work, or even at times to USE their own work (e.g. if they change employers, or decide to reuse materials they have surrended their copyright for). Shameless plug: have a look at our very brief publication https://academic.oup.com/gigascience/article/4/1/s13742-015-0072-7/2707572 principles of which apply also to improve reproducibility of research. For that we promote thinking ahead while developing any (neuroimaging in our case) study and provide this "short HOWTO" with more pointers http://5steps.repronim.org/ . So, altogether -- promoting healthy open practices from the beginning of any study design/plan etc would be of great help to Debian and beyond. Cheers, On Sat, 02 Oct 2021, Enric Garcia Torrents wrote: >Hello! >I am Enric, new to the project. I am a medical anthropologist with very >limited coding experience. My current research involves designing and >developing an open source decision making support system, specifically for >those cases regarded as severe by the current main psychiatric >understanding. I hold the hope such system could be adapted for other >uses, but that's the scope of what I am working on, fortunately with funds >to carry on the work for five more years. >My interest in Debian pure blends started ten years ago when I was >fortunate to get involved in ArbyX, a Stanford Law School Codex' project >on decision making in international arbitration courts. Unfortunately my >involvement on that stalled for several reasons, but always kept in mind >how important it is for people to have an access as easy as possible to >free suits to do their job without worrying about very often unaffordable >expenses, the burden of learning how to run the system at least as much as >to install all packages and make them work without an issue, and so on. >The arbitration project had a higher scope than the decision making one, >but basically it's the same idea with a medical twist. That involved power >maps of the players involved, and so do medicine. Involved adding data, >and medicine -specially research and the development of treatments for new >communities- also requires that. My experience, as I have been taught, is >that software alone is not enough. Hopefully we can package it all, and >create a tool set ready for those that need it. >At the moment I really don't know how I can contribute other than maybe >doing my best to help fire up other communities, help you spread the word >about Debian Med, and help others join in the effort, on top of doing my >very best to get to speed quickly on the Debian development part of it -as >I mentioned to Andreas and the rest of the crew present on today's >videocall (my apologies the connection was horrible and ran into other >issues), I have next to zero idea on how to package and maintain-. >No idea how long it take, because I am a medicine fresher too and that >will take a massive amount of time. But I will, because I feel it's >essential. Really admire what you have achieved developing Debian, it's >impressive. Thanks. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: Should we offer Debian Med workflow-containers?
On Mon, 18 Jan 2021, Andreas Tille wrote: > Hi Yaroslav, > thanks a lot for the valuable information. > On Mon, Jan 18, 2021 at 09:15:16AM -0500, Yaroslav Halchenko wrote: > > May be would be of some help/information > You could join our Debian Med sprint and than we talk about this. added Feb 18-21 to my calendar... I will try to keep an eye on the perspective schedule to see when container relevant discussion would happen to join. Insofar I have only Fri Feb 19 12:00-14:00 of ET reserved Cheers, -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: Should we offer Debian Med workflow-containers?
On Mon, 18 Jan 2021, Alex Mestiashvili wrote: > But we have a great success with singularity definition files. Forgot also to mention a project, which is despite "neuro" in its name, is not that much "neuro": https://github.com/ReproNim/neurodocker/ Neurodocker is a command-line program that generates custom Dockerfiles and Singularity recipes for neuroimaging and minifies existing containers. which we contribute to/use to streamline production of singularity (and docker) recipes. it also comes with support for our nd_freeze to use debian (and neurodebian) snapshots archives to make containers themselves reproducible. Cheers, -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: Should we offer Debian Med workflow-containers?
On Sun, 17 Jan 2021, Steffen Möller wrote: > Hello, > Our HPC environment does not offer Docker, but Singularity > (https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0177459) > is supported. I thought I should give it a shot. Is anybody using this > already on this list? FWIW, we have been early adopters and promoters of singularity (largely within neuroimaging field), using it "daily". - using https://singularity-hub.org/ as a public builder/archive for some images - keeping all images under VCS using datalad (git-annex), with help of https://github.com/datalad/datalad-container - to facilitate archival, and reproducible execution (only recently singularity came up with -e) established https://github.com/ReproNim/containers/ which is a collection of singularity images for neuroimaging + a helper https://github.com/ReproNim/containers/blob/master/scripts/singularity_cmd to ensure absent leakage of the outside env inside the containerized (without using -e) + where possible/needed (OSX) execute it via docker (there are some gotchas to resolve with some containers but generally should work) May be would be of some help/information -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: Ants taken over from Neurodebian team but it does not build - any volunteer?
On Mon, 07 Dec 2020, Andreas Tille wrote: > Hi, > since we take over packages in our tasks files from Neurodebian step by > step I did so with ants[1] which is unmaintained since a long time[2]. > I upgraded the packaging to Debian Med standards and injected the latest > upstream version. Unfortunately this fails with: THANK YOU! FWIW, - I have pushed some changes I had committed locally toward 2.3.2 but not pushed since it was FTBFS: http://github.com/neurodebian/ANTs happen you find them useful - ants is a "tricky" one since developers work tightly with ITK, so most often a bleeding edge ITK release is needed to get ants build properly, so any FTBFS first should assess how far back ITK is Cheers, -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: mrtrix3
On Thu, 26 Nov 2020, Andreas Tille wrote: > /usr/bin/env: 'python': No such file or directory > make[1]: *** [debian/rules:68: override_dh_clean] Error 127 > make[1]: Leaving directory > '/home/andreas/debian-maintain/salsa/med-team/build-area/mrtrix3-3.0.2' > I think its just because I deinstalled python on my box. > > I have pushed added new 3.0.2 release and completely disabled tests > > since seems to require data now which is not shipped along AFAIK (but > > may be I overreacted). Might just need tune up for python3 though > Any reason why you do not upload if you are able to build at your side? patches etc still need tune up, as you somewhat discovered as well. > What should be checked? You are the expert of this package - no idea > what you expect me to do. "expert" is a stretch ;) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
mrtrix3
Could someone takes a look for final step to cross the line for mrtrix3. I have pushed added new 3.0.2 release and completely disabled tests since seems to require data now which is not shipped along AFAIK (but may be I overreacted). Might just need tune up for python3 though https://salsa.debian.org/med-team/mrtrix3.git Cheers and thanks in advance! -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: getData&DataLad - could it be heaven? Was: Sepp : including a dataset?
On Fri, 09 Oct 2020, Steffen Möller wrote: > > On Fri, 09 Oct 2020, Steffen Möller wrote: > >> I added datalad-crawler to > >> https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit#gid=401910682 > >> . > > thanks! requested write access to contribute (no worries -- I will not > > be as vocal there ;)) > Jun has proven to be exceptionally fast. yeap, I already fixed the typo ;) > >> * redistribution of the such prepared files and folders with datalad. > > sure -- could be done from "generic" to specific ("datalad"). But as > > for Debian users, they do not want to learn any generic or > > specific. They know and want "apt install" so it is the question of > > "what would be the best". (I also like apt-file command to often find a > > file which might be in some package but I do not know which...) > Yip. Using that, too. For the moment I do not see how to mix a > getData-installed setup and a datalad-provided one. That may be trivial > but I don't see it, not knowing enough. If "getData" (sorry, didn't look) can output just a list of URLs to download and any metadata to decide on filenames (besides the ones from the URLs, and as contained in the archives, if desired) it could be as easy as datalad create blah && cd blah && getData --url-records blah | datalad addurls - '{url}' '{_url_basename}' to get yourself a datalad dataset with all the files. If there are tarballs , subsequent call to datalad add-archive-content would add extracted files. At some point we should "merry" datalad-crawler and "datalad addurls" to make it even easier to crawl/update. Actually if `getData` returns such records, should be easy to just create getData specific crawler pipeline which would do all needed, and be efficient for updates. > > If getData could account for aforementioned possible gotchas and provide > > resilient solution, sure -- why not? ;) > Well. We should talk to diverse upstreams if they would offer their > (raw) data via git-annex in some way. that is the beauty of git-annex which sparked the whole datalad effort: git-annex can access data from a wide range of sources, including plain urls , and allow for custom "external special remotes". This way we added support for getting files from tarballs (we first add tarball to git annex, and individual files are obtained via datalad-archives git-annex special remote), or from portals with odd authentication schemes (we have datalad special remote), so we would first ask user credentials, and authenticate on their behalf. E.g. in case of some it would be interaction with their auth server to first get a token to then use for access to S3. The point is -- no need to talk to any human/upstream! Just alert them whenever their data is actually not accessible or broken -- I ran into a good number of cases of broken archives etc. They post data, nobody cares to download and thus they do not even know that it is junk they host. > You discuss transport-reliability. I don't care too > much, will just manually (?) reinitiate what has failed and check into what > datalad then redisitributes only after getData was successful. I am talking more about upstream changing or moving the data, portals going offline (I had a use case for https://github.com/datalad/nih--videocast whenever government shutdown and their original portal went down, but videos still were accessible from original urls which otherwise nobody could get to ;)). > Maybe that got lost a bit. We have talked a lot about the complexity of > workflows. But maintaining the reference datasets has some complexity to > it, too. I lack immediate examples, but it is not unthinkable that the > same search tool is used from different tools but each downstream tool > uses it with different parameters which may need to prepare different > indexes for. yes. that is what Michael Hanke (with whom we started DataLad) had in mind while developing python3-whoosh based search -- ability to establish individual index depending on the purpose... in my simple human life, I am looking more for 'google-like' approach -- simple query, if desired -- more specialized, and internal implementation should take care about optimizing (well - current default search backend in datalad is not dumb simple and not optimizing -- a very simple loop through the records ;)) > Or - different genome sizes may be suggestive for different hash > sizes/min index lengths whatever and possibly downstream tools need to > know about these parameters? sorry, I have little to no clue in bioinformatics, so might misinterpret what has sizes we are talking about ;) > I really like all the meta information that datalad can pass with its > data, but we fall short of everything if we only discuss redistribution. EXACTLY! that is why datalad is not just for re-distribution, although born to fill that niche. > > And datalad is also in debian already. git format of debian source > > packages have been s
getData&DataLad - could it be heaven? Was: Sepp : including a dataset?
Please pardon me in advance -- came out long again. TL;DR summary: - would be great to merry getData and datalad to benefit from knowledge getData possess ATM on data sources, but then gain (many) benefits from git/git-annex/datalad, especially while thinking about "research process", data management, reproducibility etc - I shared some initial prototype for the "dh-annex" helper I started years back but might be over-complicated/under-engineered, and definitely not yet complete NB BTW https://wiki.debian.org/getData still points to SVN which is gone? "and here we go..." On Fri, 09 Oct 2020, Steffen Möller wrote: > I added datalad-crawler to > https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit#gid=401910682 > . thanks! requested write access to contribute (no worries -- I will not be as vocal there ;)) > The problem I still have with a datalad-only solution is that it > alienates the folks that have always done it by themselves, i.e. > fetching the databases from upstream, unpacking and indexing it all for > all the tools that possibly ask for it. What I see is > * some automated routine that prepares all the downloads/indexes somewhere > * whoever wants to redo/improve that process themselves please copy > that automated routine > * redistribution of the such prepared files and folders with datalad. sure -- could be done from "generic" to specific ("datalad"). But as for Debian users, they do not want to learn any generic or specific. They know and want "apt install" so it is the question of "what would be the best". (I also like apt-file command to often find a file which might be in some package but I do not know which...) Sure it could be also accomplished with non-datalad "backend" to actually fetch the data BUT you would need to re-implement what git-annex does for us already (checksumming, redundant access urls, etc), and might quickly get into trouble of unfetchable data so you would need to keep copies, but become efficient in how you manage them to not duplicate across versions of the same dataset when those start to appear, so you would arrive to annex'es .git/annex/objects keystore... so - yes, could be done, but might be actually more work in the long run IMHO and AFAIK from experience of working with more "live" (not just a dump at the end of the project, but being cooked as more data comes in, analyzed/reanalyzed etc) > Somewhere somehow we need to link this to the packages that are > installed/installable. I don't think we should have any redistribution > with datalad without that automated processing. For me, strongly biased, > the automation comes via getData. If getData could account for aforementioned possible gotchas and provide resilient solution, sure -- why not? ;) What is great about having getData is it is a great resource to indeed feed datalad (there is also datalad addurls which is an "alternative" to datalad-crawler extension; we will merry them eventually) to establish datalad datasets and thus possibly provide redundant availability to that data if hosting it somewhere (or nowhere and just keeping it until original host disappears or changes data) and then publish ;) (I do the same... see also note about containers below and take it along with the news that docker hub soon will start pruning elderly images). And datalad is also in debian already. git format of debian source packages have been supported for a while. so in principle you could just wrap pre-created "generic" git/git-annex (datalad) datasets to become debian source packages and just provide debhelpers for post-install/uninstall and be done, gain resilience through redundant availability and exact versioning, etc. but damn me -- why I haven't done it already if it all so "easy"? ;) I think I was over-engineering starting with a too complex project to start with, and thus not finishing at all :-/ And then just started to use datalad directly too much. But I found that thing I started to work on https://github.com/yarikoptic/dh-annex which has the script https://github.com/yarikoptic/dh-annex/blob/master/tools/generate_sample_repo which I believe was my CI for the https://github.com/yarikoptic/dh-annex/blob/master/tools/dh_annex ;) Back to the topic of "why may be datalad": And then there is the whole question of empowering 'git knowledgeable' users... any installed datalad dataset then could become a subdataset within "study" dataset; throw some containers inside (could also be a debian package -- have a look at my collection of singularity containers for neuroimaging which is also datalad dataset: https://github.com/ReproNim/containers/), use datalad container-run (datalad-container and singularity-container are in debian), and make the whole "research" project if not fully auto-reproducible but with a thorough history and exact versioning of all ingredients. Have a look e.g. at http://handbook.datalad.org/en/latest/basics/basic
Re: Sepp : including a dataset?
On Wed, 07 Oct 2020, Andreas Tille wrote: > On Wed, Oct 07, 2020 at 10:30:34PM +0200, Pierre Gruet wrote: > > I have almost finished the initial packaging of sepp [0]. Beside the > > sepp program, upstream also provides the tipp program in the same > > tarball. Basically, tipp classifies sequences using sepp and a > > collection of alignments and placements data and statistical methods. > > People installing tipp are invited to download a dataset (approx. 240Mo) > > [1] which does not belong to the same Github repository and has no > > license information inside it. > > Technically, I guess we might consider creating a sepp-data package with > > those data, but I also imagine this is not really feasible if we don't > > have much information about where those data come from, who collected > > them, ... > > Based on your experience, would you have some advice on this? My > > proposal is to let tipp aside and only focus on sepp, which is ready. > If the data are not part of the source tarball it might be an option > to provide both executables and add the documentation you are quoting > above. Continuing the thread of "what about datalad'ing it" I started in "How to package human, mouse and viral genomes?" here is a quick demonstration on `datalad-crawl` extension (a bit old but still works, it is what started datalad years back). Some notes before cut/pasted dumps from terminal: - anyone can now datalad install -g https://github.com/yarikoptic/tipp-reference-datalad which will take care about downloading the tarball and extracting it - we could provide access to "extracted" files in a clone somewhere on debian infrastructure (and also mirror e.g. on http://datasets.datalad.org) -- all for redundant availability etc - note that .zip contains also .tgz with the data besides the extracted - datalad install above would not remove downloaded archive or even its extracted "to local cache" copy. so if to be "packaged" postinstall hook needs to take care about dropping downloaded archives and running "datalad clean" - Since I said to crawl for all .zip (not just release etc) - I also got a copy of master with the README.md extracted ;) - Similar procedures (or via `datalad addurls`) could be done to instantiate datalad datasets (which are git/git-annex repositories) for any dataset - I did approach "minting" debian packages from datalad dataset hierarchies but never got it finished. Just FTR original elderly issue in datalad: https://github.com/datalad/datalad/issues/156 Will be happy to collaborate etc - pardon the typo in the name in the dump below Ok, demo (datalad is in debian, but datalad-crawler extension not yet :-/ please help to package/maintain -- it is on pypi) /tmp > datalad create tipp-refernece [INFO ] Creating a new annex repo at /tmp/tipp-refernece [INFO ] Scanning for unlocked files (this may take some time) create(ok): /tmp/tipp-refernece (dataset) /tmp > cd tipp-refernece /tmp/tipp-refernece > datalad crawl-init --save --template=simple_with_archives url=https://github.com/tandyw/tipp-reference/ a_href_match_=.*\.zip [INFO ] Creating a pipeline to crawl data files from https://github.com/tandyw/tipp-reference/ [INFO ] Initiating special remote datalad-archives /tmp/tipp-refernece > datalad crawl [INFO ] Loading pipeline specification from ./.datalad/crawl/crawl.cfg [INFO ] Creating a pipeline to crawl data files from https://github.com/tandyw/tipp-reference/ [INFO ] Running pipeline [.switch_branch at 0x7f69058ade50>, [[, a_href_match(query='.*.zip'), , ]], .switch_branch at 0x7f6901c038b0>, [.merge_branch at 0x7f6901c039d0>, [find_files(dirs=False, fail_if_none=True, regex='\\.(zip|tgz|tar(\\..+)?)$', topdir='.'), ._add_archive_content at 0x7f6901c03940>]], .switch_branch at 0x7f6901c03a60>, .merge_branch at 0x7f6901c03af0>, ._finalize at 0x7f6901c03b80>] [INFO ] Found branch non-dirty -- nothing was committed [INFO ] Checking out master into a new branch incoming [INFO ] Fetching 'https://github.com/tandyw/tipp-reference/' [INFO ] Need to download 607 Bytes from https://github.com/tandyw/tipp-reference/archive/master.zip. No progress indication will be reported [INFO ] Need to download 246.5 MB from https://github.com/tandyw/tipp-reference/releases/download/v2.0.0/tipp.zip. No progress indication will be reported [INFO ] Repository found dirty -- adding and committing [INFO ] Checking out master into a new branch incoming-processed [INFO ] Initiating 1 merge of incoming using strategy theirs [INFO ] Adding content of the archive ./tipp.zip into annex AnnexRepo(/tmp/tipp-refernece) [INFO ] Finished adding ./tipp.zip: Files processed: 725, renamed: 725, +annex: 725 [INFO ]
Re: mCaller - Unicode error - anybody who has encountered this before/having an instant idea?
On Fri, 04 Sep 2020, Steffen Möller wrote: > File "./mCaller.py", line 59, in distribute_threads > > extract_features(tsvname,refname,read2qual,nvariables,skip_thresh,qual_thresh,modelfile,classifier,0,endline=bytesize,train=train,pos_label=training_pos_dict,base=base,motif=motif,positions_list=positions_list) > File > "/home/moeller/git/med-team/mcaller/mcaller-0.0/extract_contexts.py", > line 123, in extract_features > model = pickle.load(modfi) > UnicodeDecodeError: 'ascii' codec can't decode byte 0xb9 in position 1: > ordinal not in range(128) I guess pickle produced with python2 ... have a look around e.g. https://rebeccabilbro.github.io/convert-py2-pickles-to-py3/ -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: Datalad (Was: How to package human, mouse and viral genomes?)
On Fri, 04 Sep 2020, Andreas Tille wrote: > On Thu, Sep 03, 2020 at 05:25:51PM -0400, Yaroslav Halchenko wrote: > > > PS: Yaroslav, I have not seen yet any commit of yours to add datalad > > > to the science tasks. > > guilty as charged! > :-) > > Where are they now? > > https://salsa.debian.org/science-team?utf8=%E2%9C%93&filter=hpc > > https://salsa.debian.org/search?utf8=%E2%9C%93&snippets=false&scope=&repository_ref=&search=science+tasks > > all no good > $ apt-cache showsrc debian-science | grep ^Vcs > Vcs-Browser: https://salsa.debian.org/blends-team/science > Vcs-Git: https://salsa.debian.org/blends-team/science.git > I've added you to the Blends-team to enable commit permissions. thanks, pushed https://salsa.debian.org/blends-team/science/-/blob/master/tasks/datamanagement -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik signature.asc Description: PGP signature
Re: How to package human, mouse and viral genomes?
On Fri, 04 Sep 2020, Steffen Möller wrote: > * sharing data between colleagues - can you have two different versions > at the same time? sure, similar to git... well -- it is git ;) so multiple versions across collaborators, multiple versions on your own box etc -- all possible. When you get into it really, you might even like to start using BTRFS as your filesystem -- provides awesome CoW feature so you could breed your huge datasets without wasting too much space. Re versions: especially mind blowing is the ability to quickly switch between versions -- "large" files are just symlinks. The only gotcha remaining -- switching between dataset with subdatasets versions is not yet "convenienced", but it is possible to have multiple dataset hierarchy clones of different versions. > * I see this mostly orthogonal to the question how we organize our data > relative to whatever "dataRoot" we define well -- you could have disjoint datasets, it is not required to bring them all up into a superdataset, although that could have benefits. > * we still have a community-effort to collect the data from somewhere > (which likely is not a git repository) and post-process it (like some > indexing for a variety of tools) and to finally prepare the data somewhere for "processing" checkout "datalad run" and datalad-container extension providing "datalad container-run". Then you could you have your preprocessing entirely reproducible and simple provenance recorded within git commits. handbook on that: http://handbook.datalad.org/en/latest/basics/basics-run.html And Michael ATM is actively looking into making snakemake to tollerate datalad (well, git-annex), so you might like to define your snakemake workflows > * with some agreement between us on how to formulate the metadata in a > machine-readable manner so we know what tool needs to check out what > files for which workflows unfortunately cannot recommend anything specific ATM since not familiar with bioinformatics metadata and its use within workflows. > I should now read a bit in your handbook. And think a bit more about it > over the weekend. I hope you like it. Adina and Michael did (well -- still doing) awesome job with it. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: Datalad (Was: How to package human, mouse and viral genomes?)
On Thu, 03 Sep 2020, Andreas Tille wrote: > On Thu, Sep 03, 2020 at 08:30:54PM +0200, Steffen M�ller wrote: > > I looked at datasets.datalad.org. > I'd strongly recommend the very entertaining talk from DebConf > > https://saimei.ftp.acc.umu.se/pub/debian-meetings/2020/DebConf20/52-datalad-decentralized-management-of-digital-objects-for-open-science.webm > Kind regards > Andreas. > PS: Yaroslav, I have not seen yet any commit of yours to add datalad > to the science tasks. guilty as charged! Where are they now? https://salsa.debian.org/science-team?utf8=%E2%9C%93&filter=hpc https://salsa.debian.org/search?utf8=%E2%9C%93&snippets=false&scope=&repository_ref=&search=science+tasks all no good -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: How to package human, mouse and viral genomes?
On Thu, 03 Sep 2020, Steffen Möller wrote: > The name "datalad" (https://www.thesaurus.com/browse/lad) I definitely like. ;-) The history goes: it was called datagit, but naive Yarik decided to asks FSF for a permission... so we had to come up with a new name, I flew into Germany, we drank (khe khe -- discussed not yet taken names) for the entire weekend. One of the requirements was: the mascot for the project must be capable of wearing the orange fury coat (and that name should be short and still available across social media etc). The best we came up with was FTF (Faster than Floppy, forget about mascot), and I flew back... when I landed, Michael sent me "he got it" and it was "DataLad" which made total sense if you think about what "git" is ;) Some kick back though we were told about: https://en.wikipedia.org/wiki/Lad_culture > I suggest to collect more input/use cases over the weekend and then see > how this goes. My immediate thought is that we describe our alternatives > and try them all on a machine that we share. We have a public matrix board, welcome to join https://app.element.io/#/room/#datalad:matrix.org if you have quick questions to address -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik signature.asc Description: PGP signature
Re: How to package human, mouse and viral genomes?
On Thu, 03 Sep 2020, Steffen Möller wrote: > I looked at datasets.datalad.org. I could well imagine to use your > technology for other (larger) databases like Pfam or UniProt or PDB. For > cute little genomes my initial reaction was that I felt overwhelmed. > Your pointer will certainly help to define what we want. Many thanks! FWIW, a few more notes since you seems to be interested ;): we do have an elderly https://github.com/datalad/datalad-crawler/ "origin of it all" but now just an extension to datalad which allows for efficient "updates" and crawling of external resources. See e.g. this asciinema/script: https://www.datalad.org/for/data-consumers But in many use cases a straight "datalad addurls" command (http://docs.datalad.org/en/stable/generated/man/datalad-addurls.html part of handbook with an example: http://handbook.datalad.org/en/latest/usecases/HCP_dataset.html?highlight=addurls#dataset-creation-with-datalad-addurls) could be sufficient to "quickly" (depending on bandwidth and/or either you use --fast option) populate a datalad dataset with files specified in a spreadsheet/structured records. So if you have some kind of .json or .csv/.tsv with records -- you could try it quickly. addurls also automagically adds columns as git-annex metadata per each file so someone could "toy around" (so far I underused the feature) with "git annex views": https://git-annex.branchable.com/git-annex-view/ or later to facilitate metadata extraction/aggregation/search. A sample dataset (original cause for addurls to be written) is available from http://datasets.datalad.org/?dir=/labs/openneurolab/metasearch if you decide to explore (that data is open so no authorization for access would be needed). The problem you might encounter in your cases is (not that great) scalability of git/git-annex to contain hundreds of files in a single repo. So you might like splitting them into subdatasets (git submodules) or providing custom views as I had mentioned before. addurls makes it easy by establishing a subdataset whenever it encounters // (instead of /) for path separation in the provided filename. PS I shut up now ;) Sorry for the flood of info. We are just very excited for DataLad even though we had been working on it for over 6 years and should be sick of it and git-annex by now ;-) but we do not! -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: How to package human, mouse and viral genomes?
You might like to listen to debconf20 talk on DataLad ;-) At some point I have started even to establish some kind of dh-datalad helper so that .deb package would contain a datalad dataset (git/git-annex repo), and would just `get` data files upon installation... So -- yes, they would not be "self contained" but it is infeasible for any sizeable data packages on debian. But they could be versioned, point to specific git state of corresponding datasets, provide lightweight and efficient upgrades (only changed/new files would need to be fetched), etc. They could be partitioned into smaller subdatasets or custom views to be provided, like we have https://github.com/datalad-datasets/hcp-structural-preprocessed which is a selection from a larger https://github.com/datalad-datasets/human-connectome-project-openaccess Never finished that helper though -- we just (develop and) use datalad directly and had no debian packages which would need strict dependency on the datasets. More of sample datasets could be found on https://datasets.datalad.org/ -- data primarily comes from original repositories, and covers now > 200TB We had started to collect resources someone might like to datalad'ify relevant to bioinformatics: https://github.com/datalad/datalad/milestone/14?closed=1 but since we are not in bioinformatics field, never actually addressed them. I also know that https://github.com/notestaff is actively using git-annex (not sure if datalad -- but he did submit some issues, so he might) for bioinformatics. Might be worth checking with him if git-annex/datalad would be decided to be used. On Thu, 03 Sep 2020, Steffen Möller wrote: > Hello, > We are closing in on the workflows. What is kind of missing are the > mostly invariant inputs like the genomes of pathogens and very much so > the reference genomes of the human, mouse, rat, worm, fly, you name > them. > Other than a few years ago, hard drives are now big enough to > accommodate the one or other genome and derivative indexes. Just - I > don't think we want to organize in our regular Debian infrastructure > something as variant as public genome (yes, they are still regularly > updated, very much so) and that is so very security-irrelevant (just > some data). Also, different sites will vary a lot in where this data > shall be organized and all those scripts should likely be > executed/initiated as/by non-root. There are public sites for this from > where this data can be downloaded. Any redundancy to these sites imho > mostly hurts us. The other side is that to just get something up quickly > and for reproducibility tests, our infrastructure is difficult to beat. > Please kindly throw your ideas at me how you would like whole genomes to > be presented by Debian to the average user and to professionals. Just > reply to this thread and/or send me "+1"s a PM and I summarize this up > in a document which I suggest we then talk about in a jitsi meeting. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: dcm2niix -- I have an intent to take over (still under Debian Med team), objections?
On Tue, 04 Dec 2018, Andreas Tille wrote: > On Tue, Dec 04, 2018 at 06:39:15AM +0100, Ghislain Vaillant wrote: > > > I would be happy to move it to salsa. I just pointed to it as the one > > > we currently use > > > I guess I would then move it to dcm2niix-epoch1 smth like that (on salsa > > > i.e.) so previous versions could be found from the original > > > dcm2niix repo (to which I would also add a commit obliterating > > > everything and stating to look into that -epoch1 repo) > > Please use the original packaging work on salsa and keep the history intact. > > I don't see what would prevent you from rebasing the work done on > > Neurodebian on top of mine. Epoch bumps don't justify history rewrites or > > new repositories, imo. > I agree with Ghislain. Feel free to simply rebase your packaging but > please keep the same repository name. We have the policy that the > package resides in a repository with the same name as the source package > (and some of our tools are relying on this) and I do not see any reason > to diverge from it. There is also no point in keeping an unused > repository of the old packaging around. I am still wondering what I should do about dcm_qa* submodules. I keep thinking about making a dedicated package (dcm2niix-qa) shipping them. Without that, I could of cause bring (merge) upstream git tree into your packaging repo, with all the submodules, but that would "ruin" the clean history it has now. I would not be able just to "rebase" my packaging on top without a merge if I am to bring submodules. Meanwhile, pushed my adjusted neurodebian packaging to http://github.com/neurodebian/dcm2niix debian branch, which AFAIK should be good to go as long as we figure out dcm_qa* situation. Will do a full sweep of builds and if all is good, upload to NeuroDebian interim -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: dcm2niix -- I have an intent to take over (still under Debian Med team), objections?
On Mon, 03 Dec 2018, Andreas Tille wrote: > Hi Yaroslav, > On Mon, Dec 03, 2018 at 03:36:19PM -0500, Yaroslav Halchenko wrote: > > Chris asked me to take over maintenance in Debian as well, and Ghislain > > blessed me as well. > Fine for me. > > To minimize amount of work for myself, I would like > > to continue with NeuroDebian packaging, just polishing it up (copyright > > file and may be some cleanup). How NeuroDebian packaging is > > different (dropping historical perspective) ATM it is at > > http://github.com/neurodebian/dcm2niix > Please do not do this. The development platform for Debian packages is > salsa.debian.org and *lots* of QA tools are relying to find the packaging > code here. I do not mind about the team but I mind a lot about the host > any Blends package can be found. I would be happy to move it to salsa. I just pointed to it as the one we currently use I guess I would then move it to dcm2niix-epoch1 smth like that (on salsa i.e.) so previous versions could be found from the original dcm2niix repo (to which I would also add a commit obliterating everything and stating to look into that -epoch1 repo) > > - main difference is our git repo sitting on top of the upstream so we > > also can produce an .orig. tarball with dcm_qa submodule which > > provides data for testing of correct operation. That increases the > > tarball size but IMHO it is worth it! > I do not mind about the tarball size. I also didn't but current one (280MB) made me think... not sure yet what thoughts it would give ;) > > ... removed all agreeed upon ... > > Please let me know what you think > All those packaging details sound sensible but please, pretty > please stick to salsa.d.o. sure > Thank you for your work on this package Cheers! -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
dcm2niix -- I have an intent to take over (still under Debian Med team), objections?
Dear Team Comrades, Upon blessing from Ghislain Antony Vaillant (previous team maintainer) and Chris Rorden (upstream, CCed) I would like to take over the maintenance of dcm2niix. And I would like to do it largely by taking the dcm2niix packaging setup we have in NeuroDebian. bits of history - we have initially packaged dcm2niix long ago (Sep 2015) but forgot to file an ITP because there were a number of outstanding license issues to be resolved before considering for "Debian proper". - Rightfully so, without seeing an ITP, Ghislain provided separate packaging in Dec 2016. - I don't remember at which stage licensing issues got resolved ;) and that is when I realized that there is already a package in Debian. so we started to talk with Ghislain in Jan 2017 about possibly merging the effort, but never converged. Chris asked me to take over maintenance in Debian as well, and Ghislain blessed me as well. To minimize amount of work for myself, I would like to continue with NeuroDebian packaging, just polishing it up (copyright file and may be some cleanup). How NeuroDebian packaging is different (dropping historical perspective) ATM it is at http://github.com/neurodebian/dcm2niix - main difference is our git repo sitting on top of the upstream so we also can produce an .orig. tarball with dcm_qa submodule which provides data for testing of correct operation. That increases the tarball size but IMHO it is worth it! - we run (build-time only ATM) tests using that dcm_qa/ data. That already allowed to iron out differences in behavior between i386 and amd64. I expect though that testing for all the other platforms would open a huge can of worms. But I think it would be beneficial in the long run to name them all ;) I bet Chris (the upstream) would be "thrilled" to help nailing them down any objections on relying on gbp to produce orig source tarballs? - in a rush toward "let's converge packaging" I have added needed then epoch 1: to the versioning.It would need to "propagate" into Debian. I hope that is ok - we still use debhelper 9 for maximal ease of backportability. any objections? - we do carry a few patches https://github.com/neurodebian/dcm2niix/tree/debian/debian/patches including patches for the packaging backports on elderly jessie (and equally old ubuntus) https://github.com/neurodebian/dcm2niix/blob/debian/debian/patches/jessie-dsc-patch probably some symlinks for really old /EOLed ubuntus could be removed, will do now But any objections against carrying backport patches? Please let me know what you think -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: mrtrix3 is "coming". Howto tests?
On Fri, 07 Sep 2018, Andreas Tille wrote: > > to recreate it from git tree. Without awareness of submodules, it would > > need > > to keep the delta for the entire submodule tree. Not sure if that is worth > > to > > breed across commits, since it would just keep adding those 16MB with every > > pristine-tar commit > Well, if you have good reasons to derive from policy (I think you gave > somehow good reasons considering your workflow ... ) please at least mention > this in debian/README.source to inform other team members. Done, Sir! > Kind regards and thanks for working on this Regards, Sir! ;) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: mrtrix3 is "coming". Howto tests?
On Thu, 06 Sep 2018, Andreas Tille wrote: > On Wed, Sep 05, 2018 at 04:12:55PM -0400, Yaroslav Halchenko wrote: > > > I know there is some way to create pristine-tar from plain Git packaging. > > > I'd be really happy if you would consider this since it enables other > > > team members to rebuild the package with the workflow described in team > > > policy. > > I do not think pristine-tar would work with git submodules, thus > > requiring a delta of the size of the testing/data . > Pristine-tar has nothing to do with the structure of the git repository. $> grep ls-tree /usr/bin/pristine-tar "git ls-tree -r --full-name $branch | git update-index --index-info"); open(LIST, "git ls-tree $b --name-only | sort -Vr |"); ... (git)hopa:~exppsy/mrtrix3[debian]git $> du -scm .git/objects 26 .git/objects 26 total $> pristine-tar commit ../build-area/mrtrix3_3.0\~rc3+git86-g4b523b413.orig.tar.gz master warning: pristine-gz cannot reproduce build of ../build-area/mrtrix3_3.0~rc3+git86-g4b523b413.orig.tar.gz; storing 96% size diff in delta (16653927 bytes) (Please consider filing a bug report so the delta size can be improved.) pristine-tar: committed mrtrix3_3.0~rc3+git86-g4b523b413.orig.tar.gz.delta to branch pristine-tar pristine-tar commit master 59.63s user 1.09s system 102% cpu 59.043 total $> du -scm .git/objects 56 .git/objects 56 total > It just stores metainformation of the orig.tar.gz you produced in a > separate branch to enable gbp recreating a byte-identical tarball as you > used to upload. to recreate it from git tree. Without awareness of submodules, it would need to keep the delta for the entire submodule tree. Not sure if that is worth to breed across commits, since it would just keep adding those 16MB with every pristine-tar commit -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: mrtrix3 is "coming". Howto tests?
On Wed, 05 Sep 2018, Andreas Tille wrote: > Hi Yaroslav, > On Tue, Sep 04, 2018 at 07:51:52PM -0400, Yaroslav Halchenko wrote: > > The interesting aspect is that upstream repo provides git submodule > > testing/data . It is not that large - just 15 MB compressed but it > > doesn't change frequently. There is two ways to handle it: > > - "Lazy" me would love just to wrap it in the mrtrix3 source > > package (not yet sure what will be "upstream source releases", I > > am packaging straight from git). It would be super easy thanks to gbp > > ability to include submodules (I do it for dcm2niix neurodebian pkg) > > - Debian soul in me says "spend more time and generate one more > > source/binary package which would be useless of the mrtrix3 context. > > What do you think? > I know there is some way to create pristine-tar from plain Git packaging. > I'd be really happy if you would consider this since it enables other > team members to rebuild the package with the workflow described in team > policy. I do not think pristine-tar would work with git submodules, thus requiring a delta of the size of the testing/data . gbp can be used to produce .orig.tar.gz and I have added https://salsa.debian.org/med-team/mrtrix3/blob/debian/debian/gbp.conf which instructs to package submodules as well, so anyone could generate a new .orig.tgz for the new upload, and fetch from packages.d.o for an existing version. Is there a better way? -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
mrtrix3 is "coming". Howto tests?
Hello Team, We have mrtrix 0.2.x series in Debian which is still used by some. Upstream worked hard and soon (hopefully) will push out 3.0 release as mrtrix3. I've migrated and tuned up packaging for it (for 3.0~rc3+git86-g4b523b413) which is now at https://salsa.debian.org/med-team/mrtrix3 The interesting aspect is that upstream repo provides git submodule testing/data . It is not that large - just 15 MB compressed but it doesn't change frequently. There is two ways to handle it: - "Lazy" me would love just to wrap it in the mrtrix3 source package (not yet sure what will be "upstream source releases", I am packaging straight from git). It would be super easy thanks to gbp ability to include submodules (I do it for dcm2niix neurodebian pkg) - Debian soul in me says "spend more time and generate one more source/binary package which would be useless of the mrtrix3 context. What do you think? -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Using recent packages on stable systems (Was: Depends available in other PPA's)
On Fri, 09 Mar 2018, Andreas Tille wrote: > > > > - a lot of people are going to show up running ubuntu.� What might you > > > > all > > > > recommend?� In theory ubuntu people could add debian testing to > > > > `apt/sources.list.d`. > > > I do not think that it is a good idea to mix Debian testing with Ubuntu > > > randomversion. IMHO the most sensible way to go would be to use the > > > backporting system the NeuroDebian team has developed. They are doing > > > automatic backports to Debian stable / oldstable and several Ubuntu > > > versions. Its a real pitty that this nifty system is only used by > > > NeuroDebian and nobody took the time to make this a bit more generic to > > > make it useful for all Blends (NeuroDebian team are basically two very > > > kind and helpful but totally overworked people who will not spent their > > > time to port their scripting system for any other use - so we are on our > > > own if we want to use it). > > Hmm... the 'Get NeuroDebian' section at neuro.debian.net does look nice. > +1 > > I don't suppose the code for the backporting system is hosted at a > > particular place that I could take a look at?� Since I am new I probably > > couldn't/shouldn't do much, but I would be interested in taking a look. > NeuroDebian members usually are reading this list but I'm CCing their > list explicitly hereby. I guess it will be in some public Git repository > which you can clone and enhance. moreover it is just an apt-get install neurodebian-dev away from you :-) Also in git at: http://git.debian.org/?p=pkg-exppsy/neurodebian.git http://github.com/neurodebian/neurodebian so choose your poison A few bullet points relating to it - our distributed and still used by me system is aged but still works. Michael has/is using a newer version he came up with for scheduling builds using condor etc. - the core backporting helper (backport-dsc) is aged but still working. It was "offered" to be included to devscripts https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660208 but it never happened. That one allows to automate creating backport source package, possibly while also applying distro specific patches (quite often that is what keeps me remaining benevolent maintainer for some packages since others prefer to not have any additional non-debian patches within Debian source package) - nd_backport is just a wrapper around backport-dsc to provide neurodebian specifics - nd_build is to build a (backported) source package on any cowbuilder - nd_build4allnd wrapper/looper around nd_backport and nd_build to build on all "supported" Debian/Ubuntus given an original .dsc file here is an elderly howto which might still work 90%-100% of the way http://neuro.debian.net/blog/2012/2012-04-14_ndtools.html hope this helps -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Sprint-derived paper now out:
On Fri, 17 Nov 2017, Steffen Möller wrote: > Dear all, > this paper has now surfaced > Möller, Steffen; Prescott, Stuart W.; Wirzenius, Lars; Reinholdtsen, > Petter; Chapman, Brad; Prins, Pjotr; Soiland-Reyes, Stian; Klötzl, > Fabian; Bagnacani, Andrea; Kalaš, Matúš; Tille, Andreas; Crusoe, Michael > R. (2017): Robust cross-platform workflows: how technical and scientific > communities collaborate to develop, test and share best practices for > data analysis. Data Science and Engineering. > https://doi.org/10.1007/s41019-017-0050-4 Wow -- it is a really nice one, very informative and integrative. Congrats! Thanks for sharing the link as well! To give a little bit of food for thought for the next sprints etc. In the paper you already make a good accent on standards, as the driving force for more efficient and reliable work and resultant environments. But as data are actually the primary object of operation on, and the artifact produced are typically data files, it might be nice to also give additional special attention to data (and meta-data) standardization. Even though Debian etc projects are working on software/tools integration, and are agnostic of the data formats used by those, we are in a good position to promote through demonstration the benefits of data standardization. As for the background -- in neuroimaging we are pushing toward data files standardization at the level of the entire experiments now (not just per file): http://bids.neuroimaging.io . Adherence to the standard allows for more efficient collaboration, meta-data manipulation (integration, querying etc), cross-tools integration etc. CWL, as far as I see it (I have no working experience with it), seems to provide some level of data description, if not standardizing types/layout of input, just again emphasizing on the benefit from such standardizations. Once again, congrats! Cheers, -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Auto creation of docker images from Debian (Med) packages?
On Thu, 12 Oct 2017, Andreas Tille wrote: > > we auto generate docker images using their stock utility (stockbrew or what > > it became), see https://github.com/neurodebian/dockerfiles > > For singularity, we auto generate just one "ultimate one" - > > https://github.com/neurodebian/neurodebian/blob/master/Singularity on > > singularity hub > thanks for your always helpful hints. > I'd like to repeat myself again: We definitely should think wider and > try to generalise what those NeuroDebian guys are doing for Blend *in* > general. The effort to adapt it specifically to Debian Med is most > probably close to the same but we open the chance to attract developers > of other Blends to contribute to this idea. > Again: Please think widely. This will finally help also NeuroDebian > once they might realise that all their stuff will be provided by a > common Blends framework. ;-) If I think just a bit wider might thought will become transparent... meanwhile -- might be a good time to realize the blend-wide thoughts into action -- new singularity (I will look into updating the package for experimental for now) is out with new "toys": checkout http://singularity.lbl.gov/release-2-4 in particular: Singularity Registry If you want to host your own Registry, we listened and you are in luck! Singularity Registry is ready for your use, along with a portal for you to “register your registry” to make it easier to share your images. Singularity Hub, along with improved building and updated builders, will follow this release. and it is still lonely there in the sregistry: https://singularityhub.github.io/containers/ so blends could shine there! -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Bug#862361: RFS: dcm2niix/1.0.20170429-1 [experimental]
On Thu, 11 May 2017, Ghislain Vaillant wrote: > Package: sponsorship-requests > Severity: normal > Dear mentors, > I am looking for a sponsor for the following package: > * Package name: dcm2niix > Version : 1.0.20170429-1 > Upstream Author : Chris Rorden > * URL : https://github.com/rordenlab/dcm2niix > * License : BSD > Section: science > One can check out the package by visiting the following URL > (debian/experimental branch): > https://anonscm.debian.org/git/debian-med/dcm2niix.git > Changes since the last upload: > * New upstream version 1.0.20170429 > * Update copyright information > * Drop the patch queue, no longer required > * Specify the source directory and build system > * Use the system zlib and openjpeg2 libraries > * Build and install the manpages with Sphinx > Best regards, uploaded, thanks! -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: [Neurodebian-devel] Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?
On Tue, 28 Mar 2017, Andreas Tille wrote: > > - I have already stated many times that if you want to move any of the > > core packages under bigger (-med, -science, etc) maintenance -- I > > don't mind. But it shouldn't complicate my own work on those > > packages. Someone's "mess" might as well be my "consistency" and I > > often can't afford spending time figuring out how this are now. And > > even worse time "fixing" up packaging (e.g. re-enabling testing, > > re-introducing dropped patches, etc) to make it as "messy" as it > > was before ;) > It might be interesting to know what part of the "mess" is important to > you. itemize "mess"y aspects (I was not the one to provide this qualification) and I will let you know. Could as well happen that the answer will be "none" > For instance it might help to know in advance if you are fine with > the gbp layout specified by the packaging policy of the target team. :-) yes -- it is fine. I use gbp as well > I fully agree that a migration of packaging to a team VCS should not > include changing / dropping any patches in the first place. good > > - so far I still see only myself as the one who took care about pandas > > even after I cried out loud for help. So helping instead of > > complaining (again) would be more helpful (I started reading > > this with an idea that we are talking about tzdata issue, but > > apparently we are just making water harder) > While I know that you always was cooperating when we started discussing > about some issue this discussion used to start only after rdepends of > one of the Neurodebian packages were affected by removal from testing > warnings. When checking the bug log no response to those RC bugs was > logged. This is simply frustrating since this means a time delay of at > least 10 days until somebody starts reacting while beeing totally > unclear whether some work was done or not. I fully understand if you > are swamped with more important things but responding to an RC bug by > tagging it help and forwarding the mail to interested parties - in this > case Debian Science for instance - would help a lot. would be great indeed > May be you consider all this making water harder, but I consider not > responding to RC bugs (without an appropriate VAC message) in times of > freeze not responsible maintenance. yeah, agree. In the long run, I may indeed need to shorten the list of packages I maintain. I am NOT on VAC virtually ever but indeed seems getting short of time to provide adequate oversight at times. Again -- actual help is welcome. > I'd like to repeat here that I > would not say so if there would be *any* message crying for help. Since > I also personally have no idea about Pandas and this issue I simply took > some action and involved tzdata maintainers. This could have happened > 10 days ago and this is my main point. (And sorry if I'm to German > here. :-P ) it is ok -- I like Germans in general ;-) > > - regarding original tzdata issue -- since we are just expressing > > sentiments here -- it would have been cool if maintainers of > > core packages would do 'reverse depends testing' before uploading (as > > I am trying to do in such cases) so we stop running after a gone train > > [see e.g. our ad-hoc messy helper > > > > https://github.com/neurodebian/neurodebian/blob/master/tools/nd_build_testrdepends > > which I usually use successfully when preparing next uploads for > > cython, nibabel, etc] > Perfectly valid argument, yes. This again shows that you are doing > really cool stuff in NeuroDebian which I totally appreciate. > Unfortunately this does not make its way where it IMHO belongs like for > instance at debian...@lists.debian.org. Well, you wrote some helpful > tool and have hidden it nicely out of reach for those people who are > obviously in need of this. apt-get install neurodebian-dev I have pointed to it multiple times. I think there is a (possibly better) alternative now $> apt-cache show ratt Package: ratt ... Description-en: Rebuild All The Things! ratt (“Rebuild All The Things!”) operates on a Debian .changes file of a just-built package, identifies all reverse-build-dependencies and rebuilds them with the .debs from the .changes file. . The intended use-case is, for example, to package a new snapshot of a Go library and verify that the new version does not break any other Go libraries/binaries. but I haven't tried it so YMMV. You can help leading the initiative to promote it/them to debian-qa@ or -devel@ or any other appropriate in your opinion channel. I would really appreciate! > > - outdated (not pushed) git on github or alioth is all the same -- just > > me forgetting to push. "Fixed now" (thanks) - and present on > > both github and alioth git://git.debian.org/git/pkg-exppsy/pandas.git > Thanks. > > Thanks i
Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?
On Tue, 28 Mar 2017, Ghislain Vaillant wrote: > On 28/03/17 10:37, Andreas Tille wrote: > > PS: Yaroslav, you know my opinion about using Vcs outside of debian.org and > > deriving from policies that are widely established. Currently > > git://github.com/neurodebian/pandas.git > > is not even featuring the latest uploads - last changelog entry is > > pandas (0.19.2-2) unstable; urgency=medium > > * Exclude a number of tests while running on non-amd64 platforms > > due to bugs in numpy/pandas > > -- Yaroslav Halchenko Wed, 11 Jan 2017 12:13:05 > > -0500 > > I'm sorry to repeat myself but you are not creating a welcoming > > environment for people who intend to help. > This sentiment is shared on my side too. > It was very disappointing to discover that nipype will not be part of > Stretch due to an RC, which looks like many of those the team fixed during > the Numpy 1.12 migration [1]. Besides, the packaging repository is quite > frankly a mess [2] and is outdated. > Looking at the other packages maintained by NeuroDebian and affected by RCs > [3] (which include nipy, dipy and pandas), the repository layout is > inconsistent from one package to the next [4, 5, 6]. IMO, as an experienced > packager who has contributed to many different teams, this completely > cancels out the benefits of having packages team-maintained in the first > place. > I am wondering whether NeuroDebian should instead be focusing on maintaining > high-quality backports of neuroimaging software for supported Debian and > Ubuntu releases (a goal it currently fulfills very well), and leave the main > packaging effort to other Debian packaging teams (Science, Med, Python...). I will try to be short - I have already stated many times that if you want to move any of the core packages under bigger (-med, -science, etc) maintenance -- I don't mind. But it shouldn't complicate my own work on those packages. Someone's "mess" might as well be my "consistency" and I often can't afford spending time figuring out how this are now. And even worse time "fixing" up packaging (e.g. re-enabling testing, re-introducing dropped patches, etc) to make it as "messy" as it was before ;) - so far I still see only myself as the one who took care about pandas even after I cried out loud for help. So helping instead of complaining (again) would be more helpful (I started reading this with an idea that we are talking about tzdata issue, but apparently we are just making water harder) - regarding original tzdata issue -- since we are just expressing sentiments here -- it would have been cool if maintainers of core packages would do 'reverse depends testing' before uploading (as I am trying to do in such cases) so we stop running after a gone train [see e.g. our ad-hoc messy helper https://github.com/neurodebian/neurodebian/blob/master/tools/nd_build_testrdepends which I usually use successfully when preparing next uploads for cython, nibabel, etc] - outdated (not pushed) git on github or alioth is all the same -- just me forgetting to push. "Fixed now" (thanks) - and present on both github and alioth git://git.debian.org/git/pkg-exppsy/pandas.git Thanks in advance for your help! -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: dcm2niix
On Wed, 11 Jan 2017, Ghislain Vaillant wrote: > On Wed, 2017-01-11 at 11:22 -0500, Yaroslav Halchenko wrote: > > Hi Ghislain, > > Thanks for packaging and uploading to dcm2niix! > You're welcome. > > It is a pity though that we duplicated the effort somewhat since > > we maintained dcm2niix within NeuroDebian for a while and didn't upload > > primarily due to some licensing issues we brought up with upstream and > > which were later resolved (e.g. of console/ujpeg.*) > Before packaging a piece of software for Debian, I systematically check > whether an ITP has already been filed for it on the Debian BTS. There > was none, so I went for it. The duplication is a pity, but I can't be > blamed for following the standard procedure for contributing a new > package to the archive. ;) oh -- it wasn't my intend to blame anyone. Indeed, if to blame we could blame us (NeuroDebian) since indeed I don't think we ever filed an ITP for this one > > It would be nice to converge and co-maintain a single package, may be > > under some team, e.g our pkg-exppsy (neurodebian) team or debian-med -- > > whatever you would prefer > I believe the package should be maintained by the Debian Med Team, and > subsequently backported to Debian Stable and Ubuntu LTS by NeuroDebian, > if desirable. The primary source for derivative projects should remain > Debian. sure > > our packaging is present on alioth and github: > > git://git.debian.org/git/pkg-exppsy/dcm2niix.git > > https://github.com/neurodebian/dcm2niix > Ack. > > unfortunately there is a stumbling stone on our end also -- versioning > > since upstream was inconsistent and I was naive to switch from our > > custom 0.0.date to their 'date' scheme they took for earlier > > releases, and now they have switched to 1.0.date ... heh > Ack. > You are referring to the following issue [1], right? > [1] https://github.com/rordenlab/dcm2niix/issues/28 I guess ;) > > correct resolution, to account for poor us NeuroDebianoids would be to > > introduce an epoch making it 1:1.0.20161101 so currently present > > version in neurodebian (20160921+git16-g0339407-1~nd+1) would upgrade to > > it. > > What do you think? ;) > Well, do I really have a choice? ;) now that you are the authority over the Debian's dcm2niix package -- more than ever ;) > An alternative solution could be to convince Chris to revert to the old > MMDD versioning scheme. This way both the Debian and NeuroDebian > packages can be upgraded without such hack. He is about to make a new > release so we should act fast. indeed! I will gently follow up on the https://github.com/rordenlab/dcm2niix/issues/28 now -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: upload aghermann-1.1.0, fix #824574 and #828008
uploaded but note that it fails to build on anything but recent debians aghermann_1.1.2-1_amd64.build OK 4:59.08 real, 194.54 user, 37.90 sys, 2278480 out aghermann_1.1.2-1~nd70+1_i386.build FAILED 0:38.75 real, 6.05 user, 6.84 sys, 82376 out aghermann_1.1.2-1~nd70+1_amd64.buildFAILED 0:49.63 real, 6.35 user, 8.34 sys, 87336 out aghermann_1.1.2-1~nd80+1_i386.build FAILED 0:52.50 real, 8.14 user, 8.94 sys, 96672 out aghermann_1.1.2-1~nd80+1_amd64.buildFAILED 0:51.23 real, 7.49 user, 8.68 sys, 102624 out aghermann_1.1.2-1~nd90+1_i386.build OK 5:17.99 real, 216.12 user, 33.92 sys, 2133400 out aghermann_1.1.2-1~nd90+1_amd64.buildOK 5:01.61 real, 196.50 user, 39.55 sys, 2225304 out aghermann_1.1.2-1~nd+1_i386.build OK 5:14.28 real, 215.76 user, 34.07 sys, 2131576 out aghermann_1.1.2-1~nd+1_amd64.build OK 4:55.06 real, 193.71 user, 37.91 sys, 2235328 out aghermann_1.1.2-1~nd12.04+1_i386.build FAILED 0:41.61 real, 5.88 user, 7.11 sys, 83944 out aghermann_1.1.2-1~nd12.04+1_amd64.build FAILED 0:40.71 real, 7.69 user, 6.76 sys, 139376 out aghermann_1.1.2-1~nd14.04+1_i386.build FAILED 0:27.23 real, 5.44 user, 4.94 sys, 97296 out aghermann_1.1.2-1~nd14.04+1_amd64.build FAILED 0:34.88 real, 5.45 user, 5.63 sys, 103488 out aghermann_1.1.2-1~nd15.04+1_i386.build FAILED 0:41.47 real, 6.92 user, 6.92 sys, 105496 out aghermann_1.1.2-1~nd15.04+1_amd64.build FAILED 0:41.93 real, 6.72 user, 7.00 sys, 112208 out aghermann_1.1.2-1~nd15.10+1_i386.build FAILED 0:41.57 real, 6.78 user, 6.95 sys, 109416 out aghermann_1.1.2-1~nd15.10+1_amd64.build FAILED 0:41.99 real, 6.50 user, 7.20 sys, 116392 out aghermann_1.1.2-1~nd16.04+1_i386.build FAILED 2:46.26 real, 97.94 user, 23.00 sys, 1269032 out aghermann_1.1.2-1~nd16.04+1_amd64.build FAILED 2:48.69 real, 93.90 user, 26.01 sys, 1289888 out aghermann_1.1.2-1~nd16.10+1_i386.build FAILED 2:46.31 real, 103.70 user, 19.59 sys, 1476272 out aghermann_1.1.2-1~nd16.10+1_amd64.build FAILED 2:50.67 real, 98.16 user, 24.29 sys, 1546360 out http://neuro.debian.net/_files/_buildlogs/aghermann/1.1.2 On Tue, 03 Jan 2017, andrei zavada wrote: > Hi Yaroslav, > Here's > http://alfinston.dlinkddns.com/johnhommer.com/code/aghermann/source/deb/aghermann_1.1.2-1.dsc > for a new upstream version of aghermann, mostly with bugfixes but also > with a more cme-compliant debian/control. > Cheers, > Andrei > On 26 August 2016 at 01:29, andrei zavada wrote: > > Thanks muchly! > > On 26 August 2016 at 01:26, Yaroslav Halchenko > > wrote: > >> they were built and just waiting upload > >> On Fri, 26 Aug 2016, andrei zavada wrote: > >>> That was quick! > >>> On 26 August 2016 at 01:15, Yaroslav Halchenko > >>> wrote: > >>> > thanks ... built but then there was power outage.. my screen was "reset" > >>> > so forgot the "TODOs" for uploads -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Shall we develop a Debian Med Tutorial? Fwd: [BC2-conference] Call for workshop and tutorial proposals open now.
On Wed, 30 Nov 2016, Steffen Möller wrote: > Hello, > much like many of you I just received this invitation to come up with a > tutorial and/or workshop for the Basel (Switzerland) conference. The > ISMB (next time in Prague (CZ) if I recall correctly) I expect to send > the same around any minute or I already missed it as they typically have > deadlines in December. > Question: Shall we? I am not so much after explaining how to prepare a > Debian package but we should demonstrate the amazing wealth of software > packages that are readily available to be installed and workflows that > can be addressed with them. A key message could be that the principles > explained in this tutorial one would be platform independent as > VirtualBox does a decent job and also ready for clouds with Amazon and > others. With respect to workflows I would then go and explain just any > that is also covered by the Common Workflow Language development. > Just ping me whoever is up for it. It is quite a bit of work and not so > very rewarding, scientifically. We shall expect to be offered to write a > book, which I would very much like to be something towards a > "bioinformatics recipies" book. This kind of avoids the term "workflow". YES! you can also note that anyone using Debian, Ubuntu or any other derivative, directly or in the cloud or via virtualbox/docker/whatnot pretty much already uses "Debian Med" ;) to accent on that you could link to other educational materials you could find online which talk about installing anything Debian Med related, e.g. like our http://neuro.debian.net/vm.html which includes pointers to few youtube videos on how to get started using it. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: RRID: a namespace for research software
Related (although we yet to "support" RRIDs) - have a look at http://duecredit.org , might be of interest if you are looking into sitting surviving methods and contributions, not only entire package On June 28, 2016 5:57:00 PM GMT+02:00, Michael Crusoe wrote: >On Tue, Jun 28, 2016 at 9:10 AM, Steffen Möller > >wrote: > >> >> On 27/06/16 16:22, Andreas Tille wrote: >> > On Mon, Jun 27, 2016 at 10:04:40AM -0400, Michael Crusoe wrote: >> >> http://identifiers.org/rrid/ >> >> >> >> Example: http://identifiers.org/rrid/RRID:SCR_001156 >> >> >> >> Where would be the best place to incorporate this into Debian? We >are >> >> adding support for this into the CWL spec so it would be nice to >have a >> >> resolver that give a Debian package name for a given RRID. >> > Add a new field to debian/upstream/metadata ? >> > >> This is also what came to my mind. As it happens, we just proposed >> >> Registrations: >> - Registry: bio.tools >> Entry: http://bio.tools/tool/DebianMed/bowtie/1.1.1 >> - Registry: SEQwiki >> Entry: http://seqanswers.com/wiki/Bowtie >> >> so you may want to add >> >> - Registry: RRID >> Entry: MIR:0558 >> >> Well, actually, there does not seem to be an entry for Bowtie, yet >> > >Search is at https://scicrunch.org/resolver?query=bowtie&filter= > >Bowtie is http://identifiers.org/rrid/RRID:SCR_005476 > > >> I am uncertain if one wants to have a complete URL or just the ID. >Matúš >> preferred the complete URL but I do not see any such for MIRIAM. >> > >Complete URL please. For khmer it is >http://identifiers.org/rrid/RRID:SCR_001156 > > >> >> For the resolver that you mentioned, this can at some point be >implemented >> via the unified Debian database. >> > >Great! > > >> >> Best, >> >> Steffen >> >> > > >-- >Michael R. Crusoe >Community Engineer & Co-founder >Common Workflow Language project >https://impactstory.org/u/-0002-2961-9670 >michael.cru...@gmail.com >+32 (0) 2 808 25 58 >+1 480 627 9108 -- Sent from a phone which beats iPhone.
Re: Open-source MRI hardware initiative project
I just want to complement (inlined with original email below) to already good responses, and hope that you Broche would continue the discussion by providing your feedback to our feedback ;) On Sat, 09 Apr 2016, Broche, Lionel wrote: > Hello Debian-Med team, > I am a researcher in MRI hardware at the University of Aberdeen, > Scotland. I am currently working on the development of a completely new > type of MRI system (see ffc-mri.org), but I would like to avoid the > traditional route of commercialisation as I see many problems with it. > Instead, I have been thinking for a while of preparing an initiative for > the development of open-source hardware in MRI. > The aim of this initiative would be, in a first stage, to pool the > technical solutions already in the public domain together so as to help > small research labs like mine and, in a second stage, to create a rally > point for these labs to share knowledge, resources and to organise > collective work. If this proves successful, it may expand into a > complete open source MRI hardware platform but that would be in the far > future. I already approached several research groups who expressed their > enthusiasm about this idea so there would be several academic > participants to start with (at least 3, probably 5 to 8), and some of > them are already willing to provide some designs. > I would like to get some advices from the Debian Med community regarding > several aspects: > - What solution would you think is the most appropriate to organise a > community portal? I do not have any IT help from my University on this > project but I am willing to put a bit of my own money to get a server > somewhere if necessary. Bear in mind that I have little training on how > to maintain a website, though I can take some time to learn. since no IT/$ support ATM, the best way IMHO would be to effectively use available "Free" infrastructure: - github.com -- create project organization, push your code there, provide source downloads for releases (so don't forget to tag them etc), use bug tracker system, ... - travis-ci.org -- to the degree applicable, enable automatic testing/building/upload of your content (code, docs, ...) - http://readthedocs.org -- if you develop documentation in rest/sphinx or even markdown -- could provide you automatic docs builds etc Very easy and efficient way to bootstrap documentation-oriented website - if you need mailing list or forum, you could create a project on http://nitrc.org/, which is although specific to neuroinformatics, could still be useful. > - I know there is an active part of Debian Med that works on MRI > software (and make great things, actually!), would any of them be > interested in this initiative? If yes, what would you expect from it, or > what would you be willing to provide at this stage? Also, would you have > some recommendations so that open-sourced MRI hardware would easily > interface with the already existing open-source software? other recommendations were already expressed, but I guess - you might still want it to interface with existing PAC system be it open-source (orthanc, xnat, ...) or proprietary - depending on your target "consumer" you might want to provide "out of box" options for export of data in data formats which neuroimaging analysis toolkits can consume, e.g. nifti - in the long run, providing some kind of programmable interface to control the beast and obtain the data "online" for real-time acquisition "closed loop" systems could be a neat feature - would be nice if there was a simulator... have you looked at http://od1n.sourceforge.net Then interested folks could assess some kind of "applicability" I guess. > - Would you have any suggestions regarding the conduct of such a > project? I have no experience in the management of open source projects > and I am actively looking for documentation about it. In particular, how > can I organise this project so as to avoid bottlenecks in the future? shameless ad: as per http://www.gigasciencejournal.com/content/4/1/31 make sure you asap clear out copyright/license for your work and choose a DFSG-compatible free and open source license for your code, data, documentation. That could help to guarantee that you yourself would have access to your work in the future, happen you change your employer ;) > - Can you see any funding bodies that could be interested in this > initiative, in the short to medium term? may be https://www.incf.org/resources/funding-support, depending on what kind of support you are looking for... But according to http://www.ffc-mri.org/funding.html you have already gotten various grants in the past... so pursuing with the same agencies could be an option. So it all again depends I guess on what funds you are looking for? > - Do you know of organisations that would be interested to know of this > project or to provide guidance? I already plan to contact OSHWA and the > CERN Ope
Re: Bug#814000: ITP: cwltool -- Common workflow language reference implementation
On Wed, 20 Apr 2016, Andreas Tille wrote: > Hi Afif, > On Tue, Apr 19, 2016 at 10:12:40PM -0700, Afif Elghraoui wrote: > > > and the reason is given in the description of the task: > > >Note that there is no according metapackage created since the packages > > >might be to different to make sense to install all on one machine. > > > I think this reason has a point - so we come back to the discussion how > > > to get a sensible dependency between cwltool and our tasks ... > > With the current setup, it seems like the answer should be to create > > another metapackage for workflow management systems. Of the entries > > currently in science-tools, at least pegasus-wms, snakemake, and cwltool > > could go directly in there. Then both our tasks and science-tools can > > refer to this new metapackage. > I like this idea. Feel free to do exactly this. :-) FWIW +1 on that additional candidates for inclusion if it would be a generic umbrella for all workflow management systems: python-nipype coop-computing-tools -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: [MoM] Fwd: Outreachy project (CI for all biological applications inside Debian)
Fwiw, for all packages I maintain, wherever upstream provides tests, I am executing them at build time (scikit-learn, stats models, pymvpa2 are few random ones for eg). For many, I (or contributors) also started to enable autopkgtests, see eg pandas. Depending on where to draw the line for bio, those might be good examples. On March 21, 2016 5:31:13 PM GMT+01:00, merlettaia wrote: >Hi Andreas, >I've decided to start with Concavity. >Is there a sample of a well-test-covered package? > >Tanya > >2016-03-21 10:27 GMT+03:00 Andreas Tille : > >> Hi Tanya, >> >> On Mon, Mar 21, 2016 at 08:26:17AM +0300, merlettaia wrote: >> > My name is Tatiana Malygina, I'm another girl from Russia, who >wants to >> > help with writing tests for biological applications in Debian =) >> >> I admit I'm really happy to get several competent students for this >> project since when I was registering it I was afraid that nobody >would >> sign on. >> >> > For Andreas: me and Ann were in the same study group in university, >and >> > actually we are friends. But out experience in bioinformatics and >our >> > primary research areas differ - that's why I want something >structural >> > bioinformatics-related as starting packaging project. >> > For example, project from this list would be great: dssp, >Concavity, >> > bio3d, ncols, norsnet, visualization (PyMol, garlic, ...) or >> >> Regarding PyMol: We also need to get the new upstream version of >PyMol >> (1.8) build for Debian. I remember there were some issues in >building >> it. >> >> > docking-related (autodock, autodock-vina, racoon, etc.). If I'm not >a >> > perfect candidate for outreachy internship, I would like to help >with >> > packaging for these tools as a volunteer - with some of them (I >mean >> > docking software) I had no prior experience, and for me it is a >great >> > chance to obtain it (and a motivation to finally read >docking-related >> > articles). >> >> I have the hope that we might get even two students since there is >> outreachy program and Google summer of code. No idea whether this >works >> - but from my perspective we have tasks even for two students. ;-) >> >> For sure any volunteer is welcome as well and the Mentoring of Month >> project is open for anybody. So getting some packaging training >should >> be granted. >> >> > I've created account on alioth (username - latticetower-guest), I >also >> like >> > git. >> >> latticetower-guest is now member of the Debian Med team and has >commit >> permissions. I'm also busy to migrate those packages from SVN to Git >> which I consider sensible candidates for creating a test suite >(recently >> I moved stacks and exonerate - feel free to ask me for moving >others). >> >> If you are interested in Garlic I noticed that the packaging is in a >> quite old fashioned state. We could negotiate with DebiChem team >what >> might be the best way to enhance the packaging (either you will get >> commit permission to their VCS and we move it into their Git or we >take >> it over into Debian Med team. Its also lacking a test suite. Just >let >> us know where you would like to start. >> >> Kind regards >> >> Andreas. >> >> -- >> http://fam-tille.de >> -- Sent from a phone which beats iPhone.
Re: bart - tools for computational magnetic resonance imaging
On Tue, 01 Dec 2015, Ghislain Vaillant wrote: > >>I can set the packaging repository up on d-med and push your initial > >>work to it if you like. That would make collaborative work with members > >>of d-med much easier, myself included. > >So I tried to do it myself. See my mail to Andreas. > Perfect. Don't hesitate to ping me once you are happy with the > current state of your packaging work. I am happy to help you on the > final touch before review. > Good luck and thanks for your contribution to Debian. Indeed thanks in advance Martin. And thanks Ghislain -- since of relevance, I have uploaded backports of ismrmrd to NeuroDebian, happen you need them on some older debian/ubuntu. Whenever bart package gets into Debian -- can do the same to it ;) Cheers! -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Debian Med usage or download stats
On Tue, 17 Nov 2015, ti...@debian.org wrote: >http://blends.debian.org/med/tasks/bio#emboss > Emboss seems to be the most frequently used package maintained by the > Debian Med team. We have no number of those users who are disabling > popcon and also no numbers who are using derivatives like Ubuntu or > BioLinux. So the numbers listed at the tasks page are *minimum* numbers > that might be significantly higher but we can not know. On a related topic, since might be of interest. For NeuroDebian we are providing neurodebian-popularity-contest package (which evil us made all packages in neurodebian archive dependent on, so would not fly as is for debian proper), which installs $> cat /etc/popularity-contest.d/neurodebian.conf KEYRING="$KEYRING --keyring /usr/share/popularity-contest/neurodebian-popcon.gpg" POPCONKEY="$POPCONKEY -r 0x544665CB8B48DE1D" SUBMITURLS="$SUBMITURLS http://neuro.debian.net/cgi-bin/popcon-submit.cgi"; making popcon (if enabled on that box) report also to our popcon server so we can collect stats from both (recent) debian and ubuntus: http://neuro.debian.net/popularity.html#popularity-contest so, similar setup I guess could be achieved for debian-med so you could possibly get stats from biolinux and other derivatives if they encourage installation of debian-med-popularity-contest or alike. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: debian-med (possibly + -science) hackathon 2016 dates?
On Fri, 16 Oct 2015, Steffen Möller wrote: > Hello, > On 15.10.2015 23:52, Yaroslav Halchenko wrote: > > Hi Andreas, > > Sorry for me forgetting, when will it happen? May be time to start > > planing ... ;) > Indeed. I put up > https://wiki.debian.org/Sprints/2015/DebianMed2016 > so we can all start dumping our thoughts/expectations. shouldn't it be https://wiki.debian.org/Sprints/2016/DebianMed2016 ? -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
debian-med (possibly + -science) hackathon 2016 dates?
Hi Andreas, Sorry for me forgetting, when will it happen? May be time to start planing ... ;) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: About backports.
On Mon, 10 Aug 2015, Charles Plessy wrote: > > Like you indicated, that's not the only concern. On behalf of stable > > release users, I think making a recent version of samtools available in > > stable-backports is important-- I think the backports repository is a > > huge reason why Debian stable is usable for everyday purposes (and it's > > the main reason why I switched to Debian from Ubuntu for my own machines). > Backports are definitely great, and the requirement that a backported package > must have been in Testing is both an asset for the quality and a limitation > for > the logistics. In some cases, Testing migration is completely out of our > control, for instance with the GCC5 migrations currently. > I sometimes wonder if it would be better to have a separate repository for > providing Debian Med packages to Stable users. Ideally it would be a Debian > PPA, but these are not developed yet. > The big advantage that a separate repository would have over the traditional > backports, is that it would allow us to also distribute some packages for > Stable without rebuidling them, when they pass their regression tests on > Stable. This would make such a backport archive much more comprehensive. FWIW, this is our approach in NeuroDebian: whenever possible enable build-time testing, then build and upload at the same time to both main Debian archive sid, and NeuroDebian -- backports for anything supported (Debians and Ubuntus). Everything is streamlined with some elderly scripts (now in neurodebian-dev package) around cowbuilder: sudo nd_build4debianmain *dsc --hookdir=$HOME/neurodebian/tools/hooks && { sudo nd_updateall; sudo nd_build4allnd *dsc; } So if it FTBFS for debian sid, I fall into that environment to troubleshoot it etc. If passes -- all build envs get updated, and I build backports for all of them. Above generates summary.build which tells which builds succeeded, and where failed I look into corresponding .build file to see what needs to be fixed. This is of cause straightforward for leaf packages... if package is used by other packages, and I suspect that it might cause various FTBFS and/or tests failures, I usually also run "downstream" regression testing by rebuilding all its dependees against old and new versions of the package [1] on Debian sid and stable if I aim to upload backports. [1] http://anonscm.debian.org/cgit/pkg-exppsy/neurodebian.git/tree/tools/nd_build_testrdepends -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150810013519.gh28...@onerussian.com
Re: Copenhagen offered to host upcoming Debian Med Sprint - alternative suggestions?
On Sun, 26 Jul 2015, Andreas Tille wrote: > > The next ISMB is in Orlando, Florida. I cannot tell if I am going at the > > very moment. But after a look at the not so ultimately impressive booths > > on at the ISMB this year, I had thought, and actually folks suggested it > > to me, that a Debian Med booth (as in a Debian + Bio-Linux joint > > demonstration > > of what wealth of packages is available at one's fingertips) may > > be rather neat, indeed. The exact planning of such an event should possibly > > be a topic of the Sprint. > I think having a booth like NeuroDebian people at this kind of events > would be a great idea (even if I personally will not join this booth). +1 Having a booth is fun and effective! Let me know if you need any help (in a sense of ideas/advices - unlikely to make it to Orladno that time) with it. E.g. with custom "budget setups" (rental prices on those shows could be a killer) like: https://lh3.googleusercontent.com/-3w4NpfZ83oI/VGaZA0j_cvI/Bzw/w46DFq3Khnc/w506-h675/14%2B-%2B1 https://lh3.googleusercontent.com/-UJcFXVTAzI4/Un7UO-GMwwI/AFE/Bk6ynql7bpw/w506-h840/13%2B-%2B1 ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150726140129.gt28...@onerussian.com
Re: gbp buildpackage and sponsor upload aghermann-1.0.5 please?
That is great. I would still prefer sponsor requests with dsc on mentors and touch git only for minor changes On June 15, 2015 3:41:53 PM HST, andrei zavada wrote: >Hey Yaroslav and Andreas, > >It appears I can learn things yet: for aghermann-1.0.5 (which >incidentally >includes a fix for #788025) I have created a new repo >git.debian.org/~hmmr-guest/public_git/aghermann-deb.git, >with pristine-tar and upstream branches following the guidelines from >https://wiki.debian.org/PackagingWithGit, and verified that `gbp >buildpackage` works. So I assume Yaroslav can pull from it and do the >same, >and proceed with package uploading as usual. > >Hope I didn't miss anything, >Andrei > >On Wed, 13 May 2015 21:04:08 +0200 >Andreas Tille wrote: > >> Hi Andrei, >> >> On Wed, May 13, 2015 at 09:00:11PM +0300, andrei zavada wrote: >> > >> > That's my own bike, and as long as Yaroslav was fine with the >> > package I would post for him to do dget from, it worked. Truth be >told, >> > he duly encouraged me to throw away my bike and go with the >official >> > policy, but somehow I kept putting the learning hour off. Now it's >time >> > to do just that, it seems. >> >> :-) >> >> > > Ahhh, and BTW, I do *not* sponsor "examples": >> > > >> > > # Sample debian/rules that uses debhelper. >> > > ... >> > >> > That one is trivial to fix. >> >> Yes. I'mm just allergic against it. ;-) >> >> > So Andreas, please don't bother, I'll read up on the policy and fix >my >> > repo and ping you again. >> >> I'm sure you'll find it simple - if not you know where to ask. >> >> Kind regards >> >> Andreas. >> -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a997f2ce-970b-4f3b-ab6e-bc007201e...@email.android.com
Re: sponsor upload aghermann-1.0.4 please?
On Tue, 12 May 2015, Andreas Tille wrote: > Hi, > On Tue, May 12, 2015 at 12:17:21AM +0100, Yaroslav Halchenko wrote: > > I am traveling but I believe it was build and I just forgot about uploading > > it.. unfortunately laptop refuses to connect atm so if not uploaded by > > tomorrow I will do that in the morning > Since I just cloned the Git repository you would have lost in uploading. :-) "would" indeed ;) in particular because I also build for all neurodebian supported debian/ubuntu releases -- so takes longer ;) apparently I didn't build 1.0.4 yet anyways -- you won! ;) > However, I have a question: Is there any reason to keep on uploading > to experimental? Unstable should be fine, IMHO. yeah -- Andrei, please adjust for upload to unstable and we will upload. Cheers, -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150512081803.gg17...@onerussian.com
Re: sponsor upload aghermann-1.0.4 please?
I am traveling but I believe it was build and I just forgot about uploading it.. unfortunately laptop refuses to connect atm so if not uploaded by tomorrow I will do that in the morning Cheers On May 11, 2015 10:50:02 PM GMT+01:00, andrei zavada wrote: >Hi Andreas, > >As my trusty sponsor Yaroslav seems to have been preoccupied by other >matters since some weeks ago, could you please stand in his stead and >push >the button for my package? There's a fix for some unfortunate >regression on >GTK3's part which screws the font sizes (they were rendered at <1pt), >and it >makes me feel for those 20-ish users who did install it. The link to >the .dsc file is below: > >> Using this opportunity, I would like to ever so slightly poke >Yaroslav to >> push the upload button on my own package, aghermann, where I fix a >FTBFS >> with gcc-5 to close #69 >> >(http://johnhommer.com/academic/code/aghermann/source/deb/aghermann_1.0.4-1.dsc). > >Cheers, >Andrei -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87725925-8350-4d6b-b021-27819ab8b...@email.android.com
Re: Debian Med Sprint in Montreal @ PyCon 2015?
On Thu, 12 Feb 2015, Michael Crusoe wrote: >Is there interest in having a Debian Med Sprint at PyCon 2015? The dates >are Monday, April 13th 2015 - Thursday, April 16th 2015. >I'll be there running a Sprint for the khmer project but I would be happy >to have Debian folk (both experienced and new contributors) there as well. >Is this a good idea? Who would be interested in co-hosting with me? THAT WOULD BE GREAT! My problem though is that I will be there only for the duration of the conference, so wouldn't be able to stay longer for the sprint. But is there anything I could help with -- let me know. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150212165858.gc7...@onerussian.com
Re: aghermann-1.0.3, reproducible builds
On Tue, 03 Feb 2015, andrei zavada wrote: > Hi Yaroslav, > I see some red ink appearing on my QA page, this time suggesting to avoid > using __DATE__ and __TIME__ macros in order to ensure reproducible builds: > https://wiki.debian.org/ReproducibleBuilds/TimestampsFromCPPMacros. > To address this, I have made appropriate changes to aghermann, resulting in > version 1.0.3-1, which is right here for you to kindly sponsor upload: > http://johnhommer.com/academic/code/aghermann/source/deb/aghermann_1.0.3-1.dsc. well -- if you want to upload to unstable with purpose of propagating to jessie -- clarify with debian-release if they would allow this change in. Otherwise change changelog release to experimental > (The other package, cnrun, in the current version (2.0.1-1) awaiting admission > to unstable, is good wrt this issue, so there's nothing to be done there.) neurodebian package has been awaiting in NEW queue already for nearly a record -- 6 months, and that is after addressing ftpmaster's concerns... but what kind of admission are you talking about for cnrun? I see nothing in NEW and for new upload -- should go to experimental as well -- -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150204000158.gv7...@onerussian.com
Re: preparing insighttookit 4.7
On Tue, 27 Jan 2015, Steve M. Robbins wrote: > Ha! Good point. > That reminds me: some years ago I considered creating a new source package > for > the ITK docs. Never got further than considering it, but that would solve > the > builder problem, anyway. > > BTW, the i386 pbuilder build also went fine, so hopefully you shouldn't > > have any problems. > Great! I'm building now for the upload. THANK YOU guys for the update and the upload! Would you mind sharing the source package somehow (while it is stuck in the NEW queue) -- I might try build backports for NeuroDebian ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150130180410.gw7...@onerussian.com
Re: Task for MRI (Magnetic Resonance Imaging) development
On Mon, 08 Dec 2014, Ghislain Vaillant wrote: >Dear all, >I originally started to contribute to the Debian ecosystem to help make >available some of the development library, such as [1], necessary to work >with MRI data. In the field of MRI processing, we are currently witnessing >a growing interest towards the release of opensource tools / framework >specific to MRI [2, 3]. Since most reconstruction clusters I know run on >Linux, I can see Debian playing a great part in providing a centralized >repository for distributing and releasing MRI related software. Before >that, It would be nice to have a centralized place to discuss and >coordinate packaging jobs for MRI software, which I thought the creation >of dedicated task [4] would officially acknowledge. Hi Ghislain, >First of, does it sound silly ? not all >Is that enough to justify the creation of a new task ? in addition to http://blends.debian.org/med/tasks/imaging and http://blends.debian.org/med/tasks/imaging-devel ? There is already a bulk of MRI related software packages contributed to listings in those two tasks What would you call the task? what software would you like to list there? If to make just MRI specific task -- not sure. >Would there be any interest from other people besides me ? >How much work would it represent to organize such task ? not much ;) >Just testing the waters. FWIW you might like also to know about the NeuroDebian project: http://neuro.debian.net/ , which while concentrating on brains also is quite MRI-centric ;) We do package/maintain some software under debian-med and debian-science blends umbrellas and list them in those tasks pages. As for the packaging discussion place -- debian-med mailing list would indeed be a good venue ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141208173652.gr14...@onerussian.com
Re: Big data needed for unit test
On Mon, 01 Dec 2014, Corentin Desfarges wrote: >I'm still working on the packaging of fw4spl, and I'm faced with a new >problematic : One of the unit tests needs to load an important data file, >which has a big size (~200 Mo). such large data arrays are worth their own packages... then you could have build-depend on it... before that -- indeed just disable that test >Should I simply remove this test, or can I include the data file in the >package ? IMHO too big/too static (I bet) to be included and then shipped again and again and again with any new upstream software release. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201143935.gw32...@onerussian.com
Re: please upload cnrun2
On Tue, 25 Nov 2014, andrei zavada wrote: > On Mon, 24 Nov 2014 15:23:20 -0500 > Yaroslav Halchenko wrote: > > On Mon, 24 Nov 2014, andrei zavada wrote: > > > On Mon, 24 Nov 2014 14:59:24 -0500 > > > Yaroslav Halchenko wrote: > > > > On Sun, 23 Nov 2014, andrei zavada wrote: > > > > > I am investigating this, and hopefully I'll find a fix soon. > > > > > Supporting ancient distributions is always full of surprises like > > > > > this. > > > > so finally my upload was processed properly and cnrun is in the NEW ( I > > > > guess you got the note) > > > Indeed, I was notified in due course, earlier today. It came right in the > > > middle of my fidgeting with ax_lua.m4, which eventually helped. > > > I think I can nail down any outstanding issues and... Now that 2.0.0 gets > > > accepted, I suppose I could release a 2.0.1, then? > > yeah -- sure ;) > There indeed were issues with ax_lua.m4 a couple of years ago, it seems; I > have incorporated a recent, working version of that aclocal file into the > distribution tarball, and now cnrun builds on all nd-supported arches > (barring really old ones where g++ is pre-4.7). > One notable exception is raring: nd_buildall reports the following: > $ grep -C5 404 cnrun_2.0.1-1~nd13.04+1_i386.build > man-db{a} pkg-config{a} po-debconf{a} texinfo{a} > 0 packages upgraded, 40 newly installed, 0 to remove and 0 not upgraded. > Need to get 1842 kB/12.3 MB of archives. After unpacking 41.4 MB will be used. > Writing extended state information... > Err http://ubuntu.media.mit.edu/ubuntu/ raring/main liblua5.1-0 i386 5.1.5-4 > 404 Not Found > Err http://ubuntu.media.mit.edu/ubuntu/ raring/main liblua5.1-0-dev i386 > 5.1.5-4 > 404 Not Found > Err http://ubuntu.media.mit.edu/ubuntu/ raring-updates/main libxml2-dev i386 > 2.9.0+dfsg1-4ubuntu4.3 > 404 Not Found > Err http://ubuntu.media.mit.edu/ubuntu/ raring/main lua5.1 i386 5.1.5-4 > 404 Not Found > Err http://ubuntu.media.mit.edu/ubuntu/ raring/main texinfo i386 > 4.13a.dfsg.1-10ubuntu4 > 404 Not Found > E: Failed to fetch > http://ubuntu.media.mit.edu/ubuntu/pool/main/l/lua5.1/liblua5.1-0_5.1.5-4_i386.deb: > 404 Not Found > E: Unable to correct for unavailable packages this one (raring) has EOL'ed already , so just remove from listing in /etc/neurodebian/cmdsettings.sh > Of which I tend to think it is down to some temporary problem only appearing > on ubuntu.medi.mit.edu. > Kindly push the button again? The .dsc URL is > http://johnhommer.com/academic/code/cnrun/source/deb/cnrun_2.0.1-1.dsc building -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141125140945.ga32...@onerussian.com
upstream metadata bib
I remember seeing somewhere a compiled bibtex from the upstream metadata we have been feeding our packages with... could someone remind me a url? do we have already a tool to collate a .bib file given a list of software in question? Thank in advance! -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141031025059.gq30...@onerussian.com
Re: sponsor upload aghermann-1.0.2 fixing #764820
On Wed, 15 Oct 2014, andrei zavada wrote: > Hi Yaroslav, Laurent, > There was a bug (#764820) reported last week for aghermann-1.0.1, about menu > entries missing icons. So here's 1.0.2 with a fix (also for some lesser > issues raised by current lintian), which I am humbly asking you to sponsor > upload. > The dsc link is > http://johnhommer.com/academic/code/aghermann/source/deb/aghermann_1.0.2-1.dsc. looks good building now upload -- tomorrow cheers -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141015004405.gd18...@onerussian.com
Re: Compiling binaries on package installation
On Tue, 14 Oct 2014, Michael Banck wrote: > > > If you bundle a "please rebuild my packages with optimization" script > > > with a local .deb archive, you'd only need to do it once on a frontend > > > box. > > and initially expose those as an apt repository, adjust apt configuration on > > every node... Then have 2 stage upgrade procedure (in first wave it > > would rebuild locally build beasts, and place them into APT repo, then > > apt-get update and {dist-,}upgrade to pick them up). > Sure, "Einen Tod muss man sterben", as the germans say. > I think it might be a potential GSoC project to come up with a > mostly-integrated solution (at least on the build host). The +100! and not only on the build host ;) meanwhile it would be nice even to collect use-cases/examples when we would need such a beast > configuration-management side of the APT repos on the client are of > course an issue and cumbersome, but maybe out-of-scope. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141014132528.go18...@onerussian.com
Re: Compiling binaries on package installation
On Tue, 14 Oct 2014, Michael Banck wrote: > > > > Or should I point out how to "compile your own", like it is done in the > > > > "Building an optimized OpenBLAS packages on your architecture" in the > > > > README.Debian file of openblas-base? > > > Not sure what's in those files, but I suggest to support > > > DEB_BUILD_OPTIONS=custom in your Debian packaging, which would build an > > > optimized package for a the user. That's what the ATLAS package are > > > (were?) doing, and if we have enough packages like that, doing the m-a > > > like tool as mentioned above would be a matter of knowing which packages > > > do support it. > > +1 BUT from a user perspective it would have been much more > > convenient if there was e.g. 'atlas-custom-installer' package which > > would do that automagically at the package installation time. > Well, one downside of that would be that you'd need a development > environment on every compute node you install it on, no? yeap -- but Debian makes it so easy to get any kind of such an environment, that for me use of a few more megs of disk space is not really a cost to even worth mentioning ;) > If you bundle a "please rebuild my packages with optimization" script > with a local .deb archive, you'd only need to do it once on a frontend > box. and initially expose those as an apt repository, adjust apt configuration on every node... Then have 2 stage upgrade procedure (in first wave it would rebuild locally build beasts, and place them into APT repo, then apt-get update and {dist-,}upgrade to pick them up). I am not saying that it all couldn't be done, I am just saying that for a user it is not available out of the box without manual configuration etc. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141014130016.gn18...@onerussian.com
Re: Compiling binaries on package installation
On Tue, 14 Oct 2014, Michael Banck wrote: > > Or should I point out how to "compile your own", like it is done in the > > "Building an optimized OpenBLAS packages on your architecture" in the > > README.Debian file of openblas-base? > Not sure what's in those files, but I suggest to support > DEB_BUILD_OPTIONS=custom in your Debian packaging, which would build an > optimized package for a the user. That's what the ATLAS package are > (were?) doing, and if we have enough packages like that, doing the m-a > like tool as mentioned above would be a matter of knowing which packages > do support it. +1 BUT from a user perspective it would have been much more convenient if there was e.g. 'atlas-custom-installer' package which would do that automagically at the package installation time. With 'build yourself' approach necessary manual interaction is also inferior for delivering urgent functionality or security updates, since there would be no automatic update. You might also look at matlab-support-dev package and its rdepends -- since Matlab is not distributable, with this package we help to automate building of the Matlab extensions at the installation time, using "registered" within matlab-support alternatives instance of user-installed Matlab. So far seemed to work quite neat. Cheers, -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141014124033.gk18...@onerussian.com
Re: insighttoolkit4 backport on wheezy 32bit -- 2 tests failures
On Fri, 30 May 2014, Gert Wollny wrote: > On Fri, 2014-05-30 at 08:57 -0400, Yaroslav Halchenko wrote: > > > Considering this, one could indeed disable this test but then one should > > > probably also disable the corresponding functionality. > > indeed. What would be a preferable way to disable it? > > a. throw exception when trying to access it? > > b. just remove from the API? > I've dug a bit deeper and what comes out is the following: > The test image is a four channel image, and now I assume, that the old > version of libtiff doesn't support the alpha channel when writing to > JPEG, because COMPRESSION_JPEG is already defined in the according > tiff.h header file. > I'd suggest to fallback to "COMPRESSION_PACKBITS" in itkTIFFImageIO.cxx > for case TIFFImageIO::JPEG, old libtiff and more than three color > components. (Patch attached) This way calling code doesn't break, and I > doubt that the compression type is crucial for storing an image. cool -- thanks -- I will try it out (lazy me just running now sudo nd_build nd+debian wheezy i386 *~nd70*dsc --hookdir=$HOME/neurodebian/tools/hooks) and will wait for it to fail ;) > > > > > would you mind adding a direct dependency to insighttoolkit4 > > > > > package's control? > > > Actually, it is currently not possible - libvtk5-dev is required > > > depends on libtiff4-dev. > > I must be too slow on Friday -- could you elaborate? even if > > libvtk5-dev bdepends on libtiff4-dev, that doesn't forbid itk4 bdepend > > on it... > libvtk5-dev does not bdepend on libtiff4-dev, it *depends* on it, i.e. > when you install libtiff5-dev on wheezy, libtiff4-dev and libvtk5-dev > will be removed (that's how I realized that there is a problem). gotcha > The other question is of course, when tk is linked against libtiff4 and > itk against libtiff5 and both are loaded by program X then you can not > be sure what code is actually called when a TIFF function is invoked > that is available in both libraries. indeed -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530143319.gk19...@onerussian.com
Re: insighttoolkit4 backport on wheezy 32bit -- 2 tests failures
On Fri, 30 May 2014, Gert Wollny wrote: > About the failing tests: The test >itkTIFFImageIOCompression_RGBTestImageJPEG_JPEG > also fails on wheezy amd64. The error > "TIFFImageIO: error out of disk space" > is nonsense though, this is the default ITK response to a failing > TIFFWriteScanline. The real error message is sent to TIFFError and is > printed out to stderr. I guess the relevant output is > "JPEGLib: Bogus input colorspace." > which would support the assumption that this is a problem with the > libtiff version. > Considering this, one could indeed disable this test but then one should > probably also disable the corresponding functionality. indeed. What would be a preferable way to disable it? a. throw exception when trying to access it? b. just remove from the API? seems indeed to happen for me too on amd64, this test was not there in 4.5.0-3 so that one built fine on wheezy > The other error message I didn't see on amd64, and I will see if I can > do a recompile on i386. > > > would you mind adding a direct dependency to insighttoolkit4 package's > > > control? > Actually, it is currently not possible - libvtk5-dev is required > depends on libtiff4-dev. I must be too slow on Friday -- could you elaborate? even if libvtk5-dev bdepends on libtiff4-dev, that doesn't forbid itk4 bdepend on it... > Considering that the transition to libvtk6-dev is pending in sid, it > might become necessary to also backport this one, and since libvtk6-dev > also depends on libtiff-dev, it should be possible to forced it to use > libtiff5-dev on wheezy. I'm not sure whether itk is already vtk6 ready > though. For now I would prefer to not care about vtk6 as for backport of current itk4 to wheezy goes -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530125741.gg19...@onerussian.com
Re: insighttoolkit4 backport on wheezy 32bit -- 2 tests failures
On Thu, 29 May 2014, Gert Wollny wrote: > Hello Yaroslav, > On Thu, 2014-05-29 at 10:33 -0400, Yaroslav Halchenko wrote: > > I have (again) tried to provide a backport build of itk4 for wheezy (to > > be shipped from NeuroDebian) and got those 2 tests to fail. > > 926 - itkTIFFImageIOCompression_RGBTestImageJPEG_JPEG (Failed) > > 2168 - itkOtsuThresholdImageFilterTestShort (Failed) > > Would you be so kind to share your expertise on > > 1. either I could consider such a failure "minor" thus probably just > > excluding those tests from being run > I don't think we should disable tests without also disabling the > according functionality. > > 2. or may be you see how I could easily mitigate/fix underlying problem? > I will try to compile it myself to debug the errors (if I can reproduce > them). Actually, I already tried a > nd_build nd+debian wheezy i386 ... > but the dependencies could not be resolved. Could it be that you > backported a gccxml but didn't upload it to the neurodebian repo yet? That is strange since if you used that command, it should have resulted in identical environment (given that you nd_updatedist recently): regarding the gccxml: ~/deb/builds/insighttoolkit4/4.5.2-1$ grep gccxml insighttoolkit4_4.5.2-1~nd70+1_i386.build | head Depends: debhelper (>= 9), cmake, swig (>= 2.0), gccxml (>= 0.9.0+cvs20120420), zlib1g-dev (>= 1.2.2), libpng12-dev, libtiff-dev, libfftw3-dev, libdcmtk2-dev, libgdcm2-dev, libdouble-conversion-dev, uuid-dev, libminc-dev, libhdf5-dev, python-all-dev, libvtk5-dev, python-vtk pbuilder-satisfydepends-dummy depends on gccxml (>= 0.9.0+cvs20120420); however: Package gccxml is not installed. gccxml{a} gettext{a} gettext-base{a} groff-base{a} hdf5-helpers{a} Selecting previously unselected package gccxml. Unpacking gccxml (from .../gccxml_0.9.0+cvs20120420-4_i386.deb) ... Setting up gccxml (0.9.0+cvs20120420-4) ... so it comes from the stock wheezy: https://packages.debian.org/search?keywords=gccxml wheezy (stable) (devel): XML output extension to GCC 0.9.0+cvs20120420-4: amd64 armel armhf i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc Just in case -- uploaded my currently completed logs to http://neuro.debian.net/_files/_buildlogs/insighttoolkit4/4.5.2 from NeuroDebian it just gets Unpacking neurodebian-popularity-contest (from .../neurodebian-popularity-contest_0.32~nd70+1_all.deb) ... Unpacking libdouble-conversion1:i386 (from .../libdouble-conversion1_2.0.1-1~nd70+1_i386.deb) ... Unpacking libdouble-conversion-dev (from .../libdouble-conversion-dev_2.0.1-1~nd70+1_i386.deb) ... > > Details: actually looking at 926 -- it complains "out of disk space" but I > > consider it VERY unlikely since that box has it in abundance :-/ > That smells like a integer conversion gone wrong. ah -- could well be... I had somewhat similar symptoms from apt while trying to update some very elderly 32bit ubuntu chroot on this box... > It could be that for > the backport one has to enforce libtiff5-dev. rright -- that one was not pulled in, while in sid it does it $> wget -q -O- 'https://buildd.debian.org/status/fetch.php?pkg=insighttoolkit4&arch=i386&ver=4.5.2-2&stamp=1401264590' | grep libtiff5-dev libtiff5 libtiff5-dev libtiffxx5 libtk8.5 libtorque2 libudev1 libunistring0 libtiff5-dev libtiffxx5 libtk8.5 libtorque2 libudev1 libunistring0 libva1 Get:257 http://mirror.bm.debian.org/debian/ unstable/main libtiff5-dev i386 4.0.3-8 [335 kB] Selecting previously unselected package libtiff5-dev:i386. Preparing to unpack .../libtiff5-dev_4.0.3-8_i386.deb ... Unpacking libtiff5-dev:i386 (4.0.3-8) ... Setting up libtiff5-dev:i386 (4.0.3-8) ... would you mind adding a direct dependency to insighttoolkit4 package's control? -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140529205536.gd19...@onerussian.com
insighttoolkit4 backport on wheezy 32bit -- 2 tests failures
Hi Guys, I have (again) tried to provide a backport build of itk4 for wheezy (to be shipped from NeuroDebian) and got those 2 tests to fail. 926 - itkTIFFImageIOCompression_RGBTestImageJPEG_JPEG (Failed) 2168 - itkOtsuThresholdImageFilterTestShort (Failed) Would you be so kind to share your expertise on 1. either I could consider such a failure "minor" thus probably just excluding those tests from being run 2. or may be you see how I could easily mitigate/fix underlying problem? Details: actually looking at 926 -- it complains "out of disk space" but I consider it VERY unlikely since that box has it in abundance :-/ 926/2518 Test #926: itkTIFFImageIOCompression_RGBTestImageJPEG_JPEG ...***Failed0.10 sec Input Filename: /tmp/buildd/insighttoolkit4-4.5.2/BUILD/ExternalData/Testing/Data/Input/RGBTestImageJPEG.tif Output Filename: /tmp/buildd/insighttoolkit4-4.5.2/BUILD/Testing/Temporary/TestTIFFCompression_RGBTestImageJPEG_JPEG.tif Compression: JPEG Pixel type (string): rgba Component Type is unsigned_char Component size: 1 Number of dimensions: 2 JPEGLib: Bogus input colorspace. Unexpected exception in ImageFileWriter itk::ExceptionObject (0x87da1b8) Location: "unknown" File: /tmp/buildd/insighttoolkit4-4.5.2/Modules/IO/TIFF/src/itkTIFFImageIO.cxx Line: 1947 Description: itk::ERROR: TIFFImageIO(0x87d49f8): TIFFImageIO: error out of disk space Exception detected while reading /tmp/buildd/insighttoolkit4-4.5.2/BUILD/Testing/Temporary/TestTIFFCompression_RGBTestImageJPEG_JPEG.tif : Could not create IO object for file /tmp/buildd/insighttoolkit4-4.5.2/BUILD/Testing/Temporary/TestTIFFCompression_RGBTestImageJPEG_JPEG.tif Tried to create one of the following: MetaImageIO GDCMImageIO JPEGImageIO VTKImageIO PNGImageIO TIFFImageIO BMPImageIO NrrdImageIO GiplImageIO NiftiImageIO You probably failed to set a file suffix, or set the suffix to an unsupported type. INVALID_BASELINE_GIVEN 2168/2518 Test #2168: itkOtsuThresholdImageFilterTestShort ..***Failed0.13 sec Start OtsuThresholdImageFilter "" OtsuThresholdImageFilter (0x93c27b0) RTTI typeinfo: itk::OtsuThresholdImageFilter, itk::Image, itk::Image > Reference Count: 3 Modified Time: 66 Debug: Off Object Name: Observers: StartEvent(SimpleMemberCommand) EndEvent(SimpleMemberCommand) ProgressEvent(SimpleMemberCommand) IterationEvent(SimpleMemberCommand) AbortEvent(SimpleMemberCommand) Inputs: Primary: (0x93c2578) * Indexed Inputs: 0: Primary (0x93c2578) Required Input Names: Primary NumberOfRequiredInputs: 1 Outputs: Primary: (0x93c4f50) Indexed Outputs: 0: Primary (0x93c4f50) NumberOfRequiredOutputs: 1 Number Of Threads: 8 ReleaseDataFlag: Off ReleaseDataBeforeUpdateFlag: Off AbortGenerateData: Off Progress: 0 Multithreader: RTTI typeinfo: itk::MultiThreader Reference Count: 1 Modified Time: 35 Debug: Off Object Name: Observers: none Thread Count: 8 Global Maximum Number Of Threads: 128 Global Default Number Of Threads: 8 CoordinateTolerance: 1e-06 DirectionTolerance: 1e-06 OutsideValue: 0 InsideValue: 255 Calculator: OtsuThresholdCalculator (0x93c5098) RTTI typeinfo: itk::OtsuThresholdCalculator, short> Reference Count: 1 Modified Time: 51 Debug: Off Object Name: Observers: none Inputs: Primary: (0) Indexed Inputs: 0: Primary (0) No Required Input Names NumberOfRequiredInputs: 0 Outputs: Primary: (0x93c77f8) Indexed Outputs: 0: Primary (0x93c77f8) NumberOfRequiredOutputs: 1 Number Of Threads: 8 ReleaseDataFlag: Off ReleaseDataBeforeUpdateFlag: On AbortGenerateData: Off Progress: 0 Multithreader: RTTI typeinfo: itk::MultiThreader Reference Count: 1 Modified Time: 46 Debug: Off Object Name: Observers: none Thread Count: 8 Global Maximum Number Of Threads: 128 Global Default Number Of Threads: 8 Threshold (computed): 0 Mask image in use: 0 Masking of output: 1 Progress | 0 | 0.00390625 | 0.0078125 | 0.0117188 | 0.015625 | 0.0195312 | 0.0234375 | 0.0273438 | 0.03125 | 0.0351562 | 0.0390625 | 0.0429688 | 0.046875 | 0.0507812 | 0.0546875 | 0.0585938 | 0.0625 | 0.0664062 | 0.0703125 | 0.0742188 | 0.078125 | 0.0820312 | 0.0859375 | 0.0898438 | 0.09375 | 0.0976562 | 0.101562 | 0.105469 | 0.109375 | 0.113281 | 0.117188 | 0.121094 | 0.125 | 0.128906 | 0.132812 | 0.136719 | 0.140625 | 0.144531 | 0.148438 | 0.152344 | 0.15625 | 0.160156 | 0.164062 | 0.167969 | 0.171875 | 0.175781 | 0.179688 | 0.183594 | 0.1875 | 0.191406 | 0.195312 | 0.199219 | 0.203125 | 0.207031 | 0.210938 | 0.214844 | 0.2
Re: Fwd: paper: Custom software development for use in a clinical laboratory
very interesting -- thanks for sharing. I wondered though, if such an in-lab software releases under FOSS license could then it be re-used or better built-upon in another lab without violating FDA/etc regulations? In-house developments resting on the work of FOSS projects are nice but is there a way those could contribute back to the ecosystem? What if such are exposed as 'services' and not 'software/devices' -- could then they be re-used within current legal framework(s)? On Tue, 20 May 2014, Andreas Tille wrote: > Hi, > I think this paper might also be of interest for readers of Debian Med > list ... > Kind regards >Andreas. > - Forwarded message from Ian Malone - > Date: Tue, 20 May 2014 12:22:21 +0100 > From: Ian Malone > To: FedoraMedical > Subject: paper: Custom software development for use in a clinical laboratory > Hi, been a bit quiet here of late. > Anyway, was reading this this morning and thought it might be of > interest to some: > J Pathol Inform. 2012; 3: 44. > Published online Dec 20, 2012. doi: 10.4103/2153-3539.104906 > PMCID: PMC3551490 > Custom software development for use in a clinical laboratory > John H. Sinard* and Peter Gershkovich > http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3551490/ > (Open Access) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140520164623.gg19...@onerussian.com
Re: Q-Leap Networks contributes to Debian Med
On Thu, 24 Apr 2014, r...@q-leap.de wrote: > You're right. How about the added note on: > https://www.qlustar.com/download much better -- thanks! -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014042411.gg8...@onerussian.com
Re: Q-Leap Networks contributes to Debian Med
On Thu, 24 Apr 2014, r...@q-leap.de wrote: > >>>>> "Yaroslav" == Yaroslav Halchenko writes: > Yaroslav> On Thu, 24 Apr 2014, r...@q-leap.de wrote: > >> >>>>> "Yaroslav" == Yaroslav Halchenko > >> >>>>> writes: > Yaroslav> On Thu, 24 Apr 2014, r...@q-leap.de wrote: > Tony> We appreciated the pizza, of course, but your interest in > Tony> supporting Debian Med is very welcome indeed. I've just moved > Tony> house, and I don't yet have a broadband connection. However, > Tony> when I get reconnected, I'll build a new Qlustar Beowulf and > Tony> try to get Bio-Linux running on it. > >> >> Sounds good. Feedback appreciated. We're just finishing up > >> >> release 8.1.1 which will already have a small sign of Debian > >> >> Med support. In the QluMan GUI, we've added "chroot > >> >> management" in which you will be able to > Yaroslav> oh that sounds interesting ;) is any part of Qlustar, such > Yaroslav> as QluMan GUI open-sourced? > >> Everything in Qlustar is open-sourced apart from QluMan ( = > >> cluster management framework including GUI). > Yaroslav> would you be so kind to point to the sources? > Yaroslav> https://www.google.com/search?q=open+source+site%3Aqlustar.com > Yaroslav> returns empty and there is no obvious link on the website > Yaroslav> (or those are only available as .dsc source packages from > Yaroslav> the repository?) > Exactly. Like Debian/Ubuntu everything is packaged as debs. .debs are binary packages, I am inquiring about source packages (i.e. dsc). Would you be so kind to point me to the Debian repository containing those? NB https://qlustar.com/download provides a binary download, which is probably containing some GPL-licensed software, for which you should "inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d." (GPL v3). So you might like to add a note/instructions on that page. > Yaroslav> Pity that QluMan is not FOSS -- it is the one which got me > Yaroslav> intrigued ;) > Oh well. Maybe one day ... :) today is a nice day for doing great things -- and it might be better than tomorrow ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140424143726.gy8...@onerussian.com
Re: Q-Leap Networks contributes to Debian Med
On Thu, 24 Apr 2014, r...@q-leap.de wrote: > >>>>> "Yaroslav" == Yaroslav Halchenko writes: > Yaroslav> On Thu, 24 Apr 2014, r...@q-leap.de wrote: > Tony> We appreciated the pizza, of course, but your interest in > Tony> supporting Debian Med is very welcome indeed. I've just moved > Tony> house, and I don't yet have a broadband connection. However, > Tony> when I get reconnected, I'll build a new Qlustar Beowulf and > Tony> try to get Bio-Linux running on it. > >> Sounds good. Feedback appreciated. We're just finishing up > >> release 8.1.1 which will already have a small sign of Debian Med > >> support. In the QluMan GUI, we've added "chroot management" in > >> which you will be able to > Yaroslav> oh that sounds interesting ;) is any part of Qlustar, such > Yaroslav> as QluMan GUI open-sourced? > Everything in Qlustar is open-sourced apart from QluMan ( = cluster > management framework including GUI). would you be so kind to point to the sources? https://www.google.com/search?q=open+source+site%3Aqlustar.com returns empty and there is no obvious link on the website (or those are only available as .dsc source packages from the repository?) Pity that QluMan is not FOSS -- it is the one which got me intrigued ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140424141103.gw8...@onerussian.com
Re: Q-Leap Networks contributes to Debian Med
On Thu, 24 Apr 2014, r...@q-leap.de wrote: > Tony> We appreciated the pizza, of course, but your interest in > Tony> supporting Debian Med is very welcome indeed. I've just moved > Tony> house, and I don't yet have a broadband connection. However, > Tony> when I get reconnected, I'll build a new Qlustar Beowulf and > Tony> try to get Bio-Linux running on it. > Sounds good. Feedback appreciated. We're just finishing up release 8.1.1 > which will already have a small sign of Debian Med support. In the > QluMan GUI, we've added "chroot management" in which you will be able to oh that sounds interesting ;) is any part of Qlustar, such as QluMan GUI open-sourced? -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140424125834.gs8...@onerussian.com
Re: Presentation of Debian Med on local Next Generation Sequencing workshop (April)
On Fri, 21 Mar 2014, Charles Plessy wrote: > For packages without upstream tests, in the meantime, even the most simple > tests like running the command with the --help option, are potentially useful. +10 ;) I also try to run some Demo or Example script if such is provided (often via xvfb) to indeed catch the most broken beasts > My favorite example is T-COFFEE, where we were distributing a 100 % broken > package on arm for years. With autopkgtest, we will have a better overview on > what package works where (just a successful build is not enough), and this > will > help people to evaluate the feasiblity of projects based on Debian on amd64, > and also on more rarely used platforms (such as the Raspberry Pi as we read on > this list). well -- the best one IMHO here is the s390x -- big-endian 64bit. It helped to detect/iron out bugs for cases where unit-tests were not developed to test those corner cases, but which naturally appear when e.g. bytes get swapped ;) armel is my favorite to detect race conditions, since it is somewhat slower than regular x86, thus those race conditions do not come that obvious ;) > Slightly more complex tests can often be built from the examples in the > program's README. On my side, I am still on a learning phase with > autopkgtest, > but I hope that collectively we will have a clear vision on what to recommend > Upstream so that they can write or accept user-contributed tests are trivially > run by autopkgtest. well -- autopkgtest is indeed nice BUT for basic QA I do prefer build-time testing, since that guarantees that package with known issues doesn't even get to the users before issues get resolved. And it goes through testing on all supported architectures (if not architecture all of cause). My main reluctance with autopkgtest was the need to duplicate definition of 'running tests' twice in debian/rules and then under debian/tests... sadt seems might be of help to avoid this duplication now -- I will look later to see if that would be possible to just call it (with corresponding tune up of PATH/PYTHONPATH) with debian/rules... > I also like a lot the “litteral programming” side of the “reproducible > research” trend. I am developing some tutorials based on real data analyses > from my work, which are currently implemented in knitr > (http://yihui.name/knitr/), and which I hope to iron out so that they can be > used to test a Debian image in an integrated way. However, they currently > still use programs that are not yet packaged. ha -- being not R user much -- haven't heard about knitr. Looks interesting indeed. Python folks were blessed "recently" with IPython which now goes even stronger forward (thanks to support from Sloan foundation and others). If you managed to not hear about that: have a look at sample ipython notebooks at http://nbviewer.ipython.org/ . > Work in progress but comments welcome ! > https://github.com/charles-plessy/tutorial it is pity there is no some kind of 'knitrviewer.org' ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140324144419.gb28...@onerussian.com
Re: Presentation of Debian Med on local Next Generation Sequencing workshop (April)
On Wed, 19 Mar 2014, Diane Trout wrote: > > I think the more effort we spent in autopkgtest suites the more we will > > be able to come closer to reproducibility. I hope that this effort will > > be rewarded by such projects who for whatever reason do not (yet) trust > > our work. > There's also the issue of upgrades changing your environment. > We've had issues with newer versions of cufflinks and tophat introducing new > bugs. upon brief look: I have apt-get sourced cufflinks -- found no unittests available the same for tophat I really hope that upstream does have some established procedures to make sure their code works correctly. Myself: I would have thought twice (or at least checked with upstream on details of above aspect) before using any of those tools. As somewhat involved in scientific software development, I can say that testing (unit-, regression- -- separate or in combination) is of paramount importance for any project unless it is already 10 years old, got tested by hundreds of users to verify "manually" its correct operation, and no longer developed (thus no new bugs could possibly be introduced). And this aspect -- testing -- might be the one where anyone could contribute. But unfortunately it is rarely fun and definitely would not be anyhow acknowledged in someone's CV/portfolio. That is why testing contributions are probably of the least number :-/ But may be someone bright would come up with idea on how to improve our situation on this front. But also testing contributions might be the easiest ones to contribute ;) -- I call such tests "functional" tests: - take your use-case code/pipeline - take some miniature simulated or real data (may be upstream project already has some for internal testing) - run your code, get the results, add assertions - contribute back "upstream". In my case I am doing smth like that with bug-reports users report against PyMVPA: http://github.com/PyMVPA/PyMVPA/blob/HEAD/mvpa2/tests/test_usecases.py which serves us two ways: replicate original bug, and then assure that not only it doesn't appear back (which could and often is verified by a dedicated unit-test), but also that user-constructed pipelines are not broken throughout our development. P.S. on this note will try to introduce .travis.yml into one of the projects on our radar for inclusion into Debian ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140320022033.gd28...@onerussian.com
Re: Presentation of Debian Med on local Next Generation Sequencing workshop (April)
On Wed, 19 Mar 2014, Carlos Borroto wrote: > > I lost some of my initial excitement about contributing to Debian Med. > > If I cannot use the results of my effort in the system where I > > actually do my job > quick side question: which are running ? >Are you asking about systems using a lot of software already packaged by >Debian but not using APT(at least not with the oficial repository) to >install such software? ;-) something like that. I just was aiming at more specific pointer, e.g. distribution/release, since that would also add to the picture. E.g. using some stable but old(er) release of Debian or Ubuntu might indeed demand users to get fresh versions installed manually (or from non-official repositories, such as the ones you use or neuro.debian.net) >Beside the two big ones I already mentioned, Galaxy and CloudBioLinux, I >don't know any other good example of a popular system for computational >biology not using official packages. I also don't know of an example of a >system that does. BioLinux, from where CloudBioLinux comes, is a close, >but my experience is that the collaboration is not as close as you would >expected. >I have also used several institutional HPC clusters, some that are mainly >used for computational biology and run on Debian or Ubuntu. None relied on >oficial packages or even APT. "run on Debian or Ubuntu" but not using packages or APT... oh well -- at least it keeps some useful admins on a payroll ;) joking aside though, situation with "institutional" HPC clusters is indeed peculiar, since they need to address many users from different disciplines, and even if all the software would be provided by stock distribution, some users would still demand custom versions and/or builds. But when we would look at smaller deployments (labs/departments), starting off with stock distribution/packages could save lots of human power in the short and long run. Then custom installations could still be done, using the same 'environment modules' system as they use across many HPCs. >Finally, let me repeat myself. I think Debian Med is doing a great job. I >hope more people could see the benefits of using the official packages. My >limited involvement allowed me to see how much you can get by following >good practices for packaging free software. My point was it seems there is >a need to highlight the importance of these benefits in a meeting like the >one mentioned in this thread. +1 ;) >Also a need for information on how to get >reproducibility but still use the official packages. actually that could be the easiest form to achieve kind of reproducibility: e.g. if someone uses stock release of Debian, as I have demonstrated, it is very easy to recreate very similar (if not identical) environment in 1 (or few) commands (such as debootstrap). -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140320020204.gb28...@onerussian.com
Re: Presentation of Debian Med on local Next Generation Sequencing workshop (April)
On Wed, 19 Mar 2014, Diane Trout wrote: > > I think the more effort we spent in autopkgtest suites the more we will > > be able to come closer to reproducibility. I hope that this effort will > > be rewarded by such projects who for whatever reason do not (yet) trust > > our work. > There's also the issue of upgrades changing your environment. > We've had issues with newer versions of cufflinks and tophat introducing new > bugs. and possibly fixing some of the existing ones ;) > As a result the scientists our group tend to want to have consistent > versions installed. this project of Michael Hanke could be of interest for you if you are keen to join: https://testkraut.readthedocs.org The idea is to make it easy to create regression tests of arbitrary (user) processing pipelines. I bet he would welcome contributions! > I'm not sure if there's a good way of having multiple versions of a debian > package available on a single system. Theoretically it is possible and done for some packages. But in general it is too much burden and all boils down to man power. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140319232435.gy28...@onerussian.com
Re: Presentation of Debian Med on local Next Generation Sequencing workshop (April)
On Wed, 19 Mar 2014, Carlos Borroto wrote: > I lost some of my initial excitement about contributing to Debian Med. > If I cannot use the results of my effort in the system where I > actually do my job quick side question: which are running ? -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140319165030.gv28...@onerussian.com
Re: Presentation of Debian Med on local Next Generation Sequencing workshop (April)
Hi Steffen, On Tue, 18 Mar 2014, "Steffen Möller" wrote: > I was invited to a local (Northern Germany) workshop on next generation > sequencing > https://sites.google.com/site/nexgenseqmv/home/workshop > to give a quick overview on what Debian/Ubuntu/BioLinux can do for them. > This is a very friendly environment and besides > * explaining how community-run Linux distros work > * that Linux not necessarily means desktop, >- but may mean virtual >- or server and that >- all major cloud services feature Debian images Do not be shy here: by working "in Debian" we are pretty much automagically benefiting from the work of more 'cloudy' people cooking up all the appliances etc. Thus there is a huge benefit from sharing expertise/responsibilities across different teams. That is why work of Debian Med is automagically omni-present through-out all possible deployment scenarios -- from cell phones (may be not by Debian itself, but by its derivative(s)), to servers, clusters, "mainframe" architectures which might not even be generally available (s390x, sparc) to regular mortals, and all possible clouds. > * what Blends are > * what packages are available for Next Generation Sequencing > I am very eager to learn about what the audience expects from our distro(s). I would also emphasize on unique "features" of Debian such as - clear open standards (thus packaging is done "the right way" which contributes to packages longevity) - licensing "clearing house": helps with wider adoption and longevity of software itself - QA, such as build time testing: cannot be stressed enough on its importance for anyone at least whispering about 'reproducibility'. > Please kindly mention whatever issue is close to your heart that should > be presented. I was very happy about the recent advent of the IGV. > To have something tangible, I asked Roland from Qlustar.com to > demonstrate over the coffee breaks how to set up a distributed work > environment with Debian. Tony had found and introduced their > technology for the Debian Med Sprint. He kindly agreed, so we will > jointly learn about how NGS-savvy wet-lab biologists are approaching > us. heh -- never heard about qlustar... interesting to hear what you learn from the coffee break but also do not forget that Debian itself comes with many open HPC related projects such as batch systems etc: http://blends.debian.org/science/tasks/distributedcomputing > Any suggestions on something fancy to display would be helpful. Fancy... hm... I some times like to amuse "reproducibility-eager" folks with commands such as debootstrap --arch=i386 --include=python potato /tmp/potato http://archive.debian.org/debian which in tandem with schroot could be used to bring Debian release from decade(s) back with novo(potato):~ $> python Python 1.5.2 (#0, Dec 27 2000, 13:59:38) [GCC 2.95.2 2220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam if you want to impress them even a bit more -- you could use apt-cacher-ng and then debootstrap right there in matter of seconds (depending on your harddrive/cpu speed) + pre-cooked schroot and you can really get them back into the past ;) JUST MAKE SURE YOU HAVE ENOUGH DISK SPACE (do not ask why it is in capitals) > I would otherwise just dig into the data we are producing locally > and show something. So overall -- press not as much on flashiness (on-a-knee projects might be flashier) but rather on long standing standards, quality, pervasiveness, shared responsibility, impact. if really bored, you can even watch my talk a year back, although I think I have done much better ;-): http://sea.ucar.edu/event/open-not-enough-benefits-debian-integrated-community-driven-computing-platform My 1c ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140319021212.gn28...@onerussian.com
Re: ANTs & Data file license in http://slicer.kitware.com/midas3/
On Fri, 28 Feb 2014, Gert Wollny wrote: > On 02/27/14 05:58, Yaroslav Halchenko wrote: > >>@Hans, could a license notice be placed in the Info tab? Something > >>like Creative Commons Attribution [2]? > >FWIW -- I would advise to use data(set)-appropriate license. generic > >CC licenses were devised for "creative/copyrightable" content. > >As for datasets/bases there is CC0 and those like PDDL etc on > >http://opendatacommons.org/licenses/ > Since I know that mails tend to vanish I added an issue [1] to the > ANTS bug tracker so that the reason for which I started this thread > doesn't get lost :) thanks! btw -- I have uploaded the beast (and pushed the tag) to Debian. Noted my (I guess) screw up with environment-modules file -- will fix later. Also built needed build-depend for ITK and now rebuilding 4.5 backports... then would build/upload to NeuroDebian Brian -- is fresh release coming? ;) Cheers, -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140301173419.gd19...@novo.onerussian.com
Re: ANTs & Data file license in http://slicer.kitware.com/midas3/
On Thu, 27 Feb 2014, brian avants wrote: >i havent followed the whole discussion but agree that it would be nice to >separate our testing data entirely from the source, as yarik suggests, at >least for ANTs. >i have been struggling a bit with testing lately, specifically, testing >combinations of parameters on combinations of data. � is there any >new/better approach to this? do you mean like a good/fancy testDriver which would be given a routine, data, expected output to compare? indeed it would be nice to have some easy/standardized way. I am only familiar somewhat with Torsten's cmtk way http://anonscm.debian.org/gitweb/?p=pkg-exppsy/cmtk.git;a=blob;hb=HEAD;f=testing/apps/appsTestDriver.sh.in where the driver is the actual collection of tests to be ran. In Python world there is more or less now standardized way to run parametric tests (the same test used on a set of input parameters), and in PyMVPA we still use our home-brewed @sweepargs decorator [1] which allows to explore the combinations of the parameters for the test [1] http://github.com/PyMVPA/PyMVPA/blob/HEAD/mvpa2/testing/sweep.py Also, although may be a bit early to relate, Michael Hanke initiated testkraut https://testkraut.readthedocs.org/en/latest/ validation platform, which although targeting fingerprinting (state/versions of libraries etc)/validation of complete analysis pipelines, could be brought in for parametric testing of specific tools. Its runtime fingerprinting feature could actually become very beneficial for bisecting sporadic failures across different environments and/or upgrades. > � if i am going to put effort into this, then >would like to improve the testing situation, in general, if possible. I would also be interested to hear about a good approach for testing, especially in neuroimaging projects relying on cmake. We are (very) slowly working on introducing some public testing for AFNI so we could QA it at build-time. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140227140133.gi5...@onerussian.com
Re: ANTs & Data file license in http://slicer.kitware.com/midas3/
On Thu, 27 Feb 2014, Matthew McCormick wrote: > >> @Yaroslav, the script we use for creating the ITK tarballs [3] may be > >> a useful reference for creating an ANTS data tarball. > > Thank you Matthew, we might make use of its parts... but while at it I > > would like to raise a concern actually about shipping those relatively > > large data volumes used for testing WITHIN the source tarballs... Do > > you expect those to get modified (grow/change) with each ITK release? > > ATM those data samples occupy big (if not majority) of the > > compressed tarball IIRC. > > May be that data could get a life of its own? ;) i.e. may be we could > > better package "working set" of test images used by ITK/ANTs (else?) and > > distribute a dedicated package with only data? I eventually see it > > possible that data(set) stabilizes more than code which keeps developing > > reusing those data files > > P.S. That is what Michael (of NeuroDebian) has done to other big > > projects such as AFNI, FSL etc -- we barely ever update the data > > packages but code packages get updated quite often now without incurring > > any major penalty of dragging the same data around > The testing data is included with the source tarballs so that the > source tarball can be downloaded and the tests can be readily run > without any extra effort and without a network connection. > The testing data will vary with releases. Most of the data are not > input images but baseline, i.e. ground truth, images used when > verifying the output of a test. Fair enough if data is to change with releases and tarballs remain the ultimate form of "sources" -- thank you Matthew. Brian -- is that to be the case with ANTs? then would you be so kind to provide similar tarball distribution bundled with data? Cheers! -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140227053022.gh5...@onerussian.com
Re: ANTs & Data file license in http://slicer.kitware.com/midas3/
On Wed, 26 Feb 2014, Matthew McCormick wrote: > >From what I can see (find ANTS -name '*.md5'), most if not all of the > data is located in the slicer.kitware.com/BRAINSTools Midas Community > [1]. > @Hans, could a license notice be placed in the Info tab? Something > like Creative Commons Attribution [2]? FWIW -- I would advise to use data(set)-appropriate license. generic CC licenses were devised for "creative/copyrightable" content. As for datasets/bases there is CC0 and those like PDDL etc on http://opendatacommons.org/licenses/ > @Yaroslav, the script we use for creating the ITK tarballs [3] may be > a useful reference for creating an ANTS data tarball. Thank you Matthew, we might make use of its parts... but while at it I would like to raise a concern actually about shipping those relatively large data volumes used for testing WITHIN the source tarballs... Do you expect those to get modified (grow/change) with each ITK release? ATM those data samples occupy big (if not majority) of the compressed tarball IIRC. May be that data could get a life of its own? ;) i.e. may be we could better package "working set" of test images used by ITK/ANTs (else?) and distribute a dedicated package with only data? I eventually see it possible that data(set) stabilizes more than code which keeps developing reusing those data files P.S. That is what Michael (of NeuroDebian) has done to other big projects such as AFNI, FSL etc -- we barely ever update the data packages but code packages get updated quite often now without incurring any major penalty of dragging the same data around -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140227045842.gg5...@onerussian.com
Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)
ah -- info is there (missed it among numerous) CCs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736760 citing: Since 2.14.1, uscan now uses debian/upstream/signing-key.* for the upstream signatures. This seems to conflict with the debian/upstream file, as decribed in https://wiki.debian.org/UpstreamMetadata http://dep.debian.net/deps/dep12/ In general I would not mind collecting all the upstream information under debian/upstream/ But it would have made much more sense if e.g. debian/watch should have been renamed into e.g. debian/upstream/origin -- then I would have seen point of uscan using now debian/upstream/signing-key.*. Now such a rename in uscan is IMHO only brings even more confusion among "debian/" files (debian/watch which uses debian/upstream/signing-key.*). On Sat, 22 Feb 2014, Yaroslav Halchenko wrote: > Have I missed the background? > is debian/watch getting renamed to debian/upstream -- where is the > "conflict"? -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140222154807.gg5...@onerussian.com
Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)
Have I missed the background? is debian/watch getting renamed to debian/upstream -- where is the "conflict"? On Wed, 12 Feb 2014, Andreas Tille wrote: > Hi, > On Wed, Feb 12, 2014 at 04:11:41PM +0900, Charles Plessy wrote: > > Le Wed, Feb 12, 2014 at 12:06:42AM -0500, James McCoy a écrit : > > > That being said, I don't have access to most of the packages. Even if I > > > did, it feels "dirty" to go and commit to a couple hundred packages I > > > have no involvement with instead of adapting two pieces of software to > > > deal with both path names. > > Hi James, > > you already have commit access to the Debian Med packages, like all other > > Debian developers. Please go ahead ! > I take this "go ahead" for "yes, I accept the move". While I would have > no problems with this I wonder if it is appropriate to simply go on here > without at least informing Debian Science and DebiChem who also maintain > some d/upstream files. If I might have sounded against the move in the > past my main problem was that the affected parties were not included into > the decision making process. > So I have put the relevant mailing lists in CC to at least give people > lurking there some heads up and a slight chance to insist. > I would say: If nobody will insist until after the weekend we might go > ahead. And for the actual action I agree with Charles that I see no > problem if James would simply commit a change to Debian Med repositories > (SVN and Git). That's fine and would save us (me or Charles) some work > and is perfectly possible permission-wise. > Kind regards > Andreas. > PS: I think I did not got any answer to my question about further plans > for the debian/upstream/ dir. I would be really happy to understand > the big picture to make sure we will not again invent something which > needs to be changed later on. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140222154310.gf5...@onerussian.com
Re: should google-glog be ok with libunwind7-dev? [Was: Orthanc 0.7.2 backport of wheezy]
On Thu, 13 Feb 2014, Sebastien Jodogne wrote: > Hi, > >Thanks to Daigo's -2 of glog with suggested tune up of build-depends, > >I have uploaded backport build of orthanc for wheezy straight into > >NeuroDebian wheezy just to give it a try... > Fine! Could you give the link to the repository containing your backport? d'oh -- I thought that we are that famous by now that I would not need to type url all the time ;-) neuro.debian.net and here is orthanc's page now http://neuro.debian.net/pkgs/orthanc.html > Would it be possible for you to integrate this backport into the > main Debian Med repository? that was my point of tune ups in google-glog and now request for you to avoid any "backport" patches altogether. Then I could simply rebuild the package for any Debian/Ubuntu release (with a new changelog entry, added automagically ...) > >initial catch was the re-located *.dic files provided by libdcmtk2 > >(under /usr/share/dcmtk in wheezy and /usr/share/libdcmtk2/ in sid now): > >orthanc silently failed to start. log msgs just finished with log lines > >stating that it was "Loading the external DICOM dictionary" without any > >failure/error msg following. > This is very strange. Here is what I get when I use a bad path to > the dictionaries, with Orthanc 0.7.2: > jodogne@rth-l-0065:~/Subversion/Orthanc/Build$ ./Orthanc that was in the logs orthanc produced while being started from init.d script... may be the last ones you see here are no longer logged to file but just dumped to console in case you just start in console? > W0213 09:51:43.822284 10679 OrthancInitialization.cpp:82] Using the > configuration from: > /home/jodogne/Subversion/Orthanc/Resources/Configuration.json > W0213 09:51:43.825232 10679 DicomServer.cpp:87] Loading the external > DICOM dictionary "/usr/share/dcmtkeec/dicom.dic" > E: DcmDataDictionary: Cannot open file: /usr/share/dcmtkeec/dicom.dic > E0213 09:51:43.825423 10679 main.cpp:446] EXCEPTION [Internal error] > W0213 09:51:43.825594 10679 main.cpp:457] Orthanc has stopped > So, in my case, there is no silent failure. > >Sebastien, do you think could you make discovery of the path 'automagic' > >thus avoiding necessity to patch for the path? probably the best it > >could be achieved through cmake's find_file looking under common > >suspect paths (/usr/share/dcmtk /usr/share/libdcmtk2) if > >DCMTK_DICTIONARY_DIR was not specified (and thus avoiding its hard-coded > >specification in debian/rules)? > Yes, certainly, this is an interesting suggestion! I have just added > it to the roadmap [1]. cool -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140213124038.gd5...@onerussian.com
Re: should google-glog be ok with libunwind7-dev? [Was: Orthanc 0.7.2 backport of wheezy]
Thanks to Daigo's -2 of glog with suggested tune up of build-depends, I have uploaded backport build of orthanc for wheezy straight into NeuroDebian wheezy just to give it a try... initial catch was the re-located *.dic files provided by libdcmtk2 (under /usr/share/dcmtk in wheezy and /usr/share/libdcmtk2/ in sid now): orthanc silently failed to start. log msgs just finished with log lines stating that it was "Loading the external DICOM dictionary" without any failure/error msg following. Sebastien, do you think could you make discovery of the path 'automagic' thus avoiding necessity to patch for the path? probably the best it could be achieved through cmake's find_file looking under common suspect paths (/usr/share/dcmtk /usr/share/libdcmtk2) if DCMTK_DICTIONARY_DIR was not specified (and thus avoiding its hard-coded specification in debian/rules)? Cheers! On Tue, 14 Jan 2014, Yaroslav Halchenko wrote: > Hi Daigo, > I have looked at the packporting of orthanc for Wheezy. orthanc uses > google-glog and that one currently build-depends on libunwind8-dev. It > seems to build (including the build-time testing -- thanks for enabling > those!) fine using libunwind7-dev, so I thought to check with you > - if you have any information that unwind7 in wheezy would be > insufficient/too buggy for google-glog? > - would you mind adjusting debian/control to Build-depend on > libunwind8-dev [i386 amd64] | libunwind7-dev [i386 amd64] > to ease its future backporting? > Thank you in advance > On Mon, 13 Jan 2014, Sebastien Jodogne wrote: > > Hi Andreas and Yaroslav, > > >>I was not able either to find a complete "backporting handbook" for > > >>Debian Med packages: Andreas, is there such a guide available > > >>somewhere? > > >I admit I'm quite lazy with backports and while I definitely think this > > >is a reasonable task I somehow consider it "Somebody Else's Problem". > > >I simply need to restrict my field of work. > > Yes, you are perfectly right. > > Yaroslav, I have just expanded the build instructions for Debian Wheezy [1]. > > The only third-party package that should be backported to get an > > Orthanc package for Wheezy is libgoogle-glog-dev [2] (only available > > for Squeeze and Sid). I will not personally do this backporting > > task, but if someone does it, I could then backport Orthanc to > > Wheezy. > > Cheers, > > Sébastien- > > [1] http://goo.gl/t7XVqe > > [2] http://packages.debian.org/en/sid/libgoogle-glog-dev -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140211032618.gl5...@onerussian.com
Re: Python-mne uploaded
FWIW I have realized that I haven't uploaded 0.7.3 backport builds of mne-python to NeuroDebian -- done now Cheers, On Sun, 19 Jan 2014, Andreas Tille wrote: > Hi Alexandre, > I uploaded your preparation in Git with some changes: > 1. You said it would be upstream version 0.7.3 but you had set > the package version to 0.7.1-3. I fixed this > 2. The package should always start to unstable not to neurodebian. > (fixed) > 3. THe changelog entry should close the bug (fixed) > KInd regards > Andreas. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140124143954.gp...@onerussian.com
Re: modulefiles for fis-gtm may be?
On Wed, 22 Jan 2014, Luis Ibanez wrote: > Sounds good. > Yes, This looks great. >We will appreciate anything that will reduce the barrier >of entry for learning M/MUMPS. >Certainly the need for setting those environment variables >(although not particularly difficult) is just one more opportunity >for typos, mistakes and things going wrong, which can lead to >a first visitor to M / MUMPS to have a frustrating experience. >I know that I have run in trouble many times due to simple errors >in those environment variables. >It is great that they considered the case of having multiple version >installed of the same tools. Which is one of the scenarios that >Bhaskar has been very keen to make sure that are supported. >This will also be very useful for the VistA package. Since it will >also enable to have multiple installations running side by side. > So, how do we start using the environment-modules ? Recommends: environment-modules + add a Modulesfile under whatever that versioned path I have was blurbing about. then theoretically modules should be enabled upon login and people would need just 'load' a corresponding module > (I apologize, if I missed it from your link to the email thread). > Could you suggest an example that we could follow ? I wish I could give you an example in the archive, but I haven't got chance to start using it myself. for ants meanwhile I did following (do not remember if tested 100% working ;) ), not sure if that is an ideal setup either. I have backport builds of modules for NeuroDebian but didn't upload yet -- wanted first to make at least package use them... got short on time... I will CC Alastair -- may be he could guide us a bit: --- a/debian/control +++ b/debian/control @@ -20,6 +20,7 @@ Vcs-Browser: http://git.debian.org/?p=pkg-exppsy/ants.git;a=summary Package: ants Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends} +Recommends: environment-modules Suggests: fsl, gridengine-client Description: advanced normalization tools for brain and image analysis Advanced Normalization Tools (ANTS) is an ITK-based suite of diff --git a/debian/dirs b/debian/dirs index a707198..be88593 100644 --- a/debian/dirs +++ b/debian/dirs @@ -1,2 +1,3 @@ usr/lib/ants usr/bin +usr/share/modules/modulefiles/ants diff --git a/debian/rules b/debian/rules index c3d8357..678f9cc 100755 --- a/debian/rules +++ b/debian/rules @@ -5,6 +5,8 @@ srcpkg = $(shell LC_ALL=C dpkg-parsechangelog | grep '^Source:' | cut -d ' ' -f debver = $(shell LC_ALL=C dpkg-parsechangelog | grep '^Version:' | cut -d ' ' -f 2,2 ) uver = $(shell echo $(debver) | cut -d '-' -f 1,1 ) +modulesfile = debian/ants.environment-modules + export http_proxy=http://127.0.0.1:9/ export https_proxy=http://127.0.0.1:9/ @@ -44,7 +46,10 @@ override_dh_auto_configure: -DEXECUTABLE_OUTPUT_PATH:PATH=$(DESTBINDIR) \ --debug-output -override_dh_auto_build: +%modules: %modules.in + sed -e 's,$$UVERSION,$(uver),g' $< >| $@ + +override_dh_auto_build: $(modulesfile) dh_auto_build : Build manpages cd `/bin/ls -d obj-*/bin` && mkdir -p ../man && \ @@ -71,6 +76,8 @@ override_dh_auto_install: done : Install shell scripts install -t debian/ants/usr/lib/ants Scripts/* + : Install modules file + install -t debian/ants/usr/share/modules/modulefiles/ants $(modulesfile) : Adjust ANTSPATH cd debian/ants/usr/lib/ants && sed -ie 's,\([^"=]*\(/bin/ants\|ANTS/release/bin\)\),/usr/lib/ants,g' *.sh *.pl : Install manpages @@ -78,7 +85,7 @@ override_dh_auto_install: override_dh_auto_clean: dh_auto_clean - rm -rf $(BUILDDIR) + rm -rf $(BUILDDIR) debian/ants.environment-modules # upstream tests use some tiny dataset for tests, which # they deposited online instead of keeping under the GIT --- /dev/null +++ b/debian/ants.environment-modules.in @@ -0,0 +1,20 @@ +#%Module1.0# +## +## ants modulefile +## +proc ModulesHelp { } { +global version + +puts stderr "\tLoads the ANTs (advanced normalization tools) environment.\n" +puts stderr "\tIt will adjust PATH and set ANTSPATH so that all ANTs " +puts stderr "\tbecome available in your environment.\n" +puts stderr "\tVersion $version\n" +} + +module-whatis "enable ANTs binaries" + +# for Tcl script use only +set version "$UVERSION" + +setenv ANTSPATH "/usr/lib/ants/" +prepend-path PATH /usr/lib/ants -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin
modulefiles for fis-gtm may be?
I have ran into Luis's recent blog post http://www.osehra.org/blog/backporting-fis-gtm-ubuntu-linux-distribution Environment Set Up Setting up the usual environment variables in the bash shell: export gtm_dist='/usr/lib/fis-gtm/V6.0-003-2~nd12.10_x86_64' # backported from NeuroDebian export gtmgbldir=$HOME/data/gtm/database export gtmroutines="$HOME/data/gtm/o($HOME/data/gtm/r) $gtm_dist/libgtmutil.so $gtm_dist" Now that Alastair has packaged environment-modules we could start using them I think, and then in your case it should then be just a matter of module load fis-gtm which would set all those environments. They are usually used in HPC deployments to switch between custom builds of different versions of software etc. In our case we could unify all this environment madness as well I guess. I have once posted to our very low volume mailing list my brief analysis but haven't heard back/nor have done myself yet proper a 'modulefile'. (althgouh I think for ants package it will be the first to come whenever I find time to figure out what to do with its tests data). http://lists.alioth.debian.org/pipermail/neurodebian-devel/2013-December/000397.html your input is welcome (I believe you should be able to post without subscription), or we could continue discussion here ;) Cheers, -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140122043953.gz...@onerussian.com
Re: Thank you Luis!
On Sun, 19 Jan 2014, Luis Ibanez wrote: > This is great ! >Thanks for uploading the package to the NeuroDebian repository. >It shows now at: > [2]http://neuro.debian.net/pkgs/fis-gtm.html#binary-pkg-fis-gtm >Following the instructions in > [3]http://neuro.debian.net/install_pkg.html?p=fis-gtm >It installed smoothly on an Ubuntu 12.10. Very Nice ! >Just for the record, >Following the NeuroDebian page instructions, I essentially did: >wget -O- [4]http://neuro.debian.net/lists/quantal.us-nh.full | sudo tee >/etc/apt/sources.list.d/neurodebian.sources.list >sudo apt-key adv --recv-keys --keyserver [5]pgp.mit.edu 2649A5A9 >sudo apt-get update >sudo apt-get install fis-gtm >And then was able to run the MUMPS interpreter as: > $gtm_dist/mumps -dir > Many Thanks for this backport ! Many Welcomes Luis -- great to see if in use and thanks for the feedback! -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140120002342.gl18...@onerussian.com
should google-glog be ok with libunwind7-dev? [Was: Orthanc 0.7.2 backport of wheezy]
Hi Daigo, I have looked at the packporting of orthanc for Wheezy. orthanc uses google-glog and that one currently build-depends on libunwind8-dev. It seems to build (including the build-time testing -- thanks for enabling those!) fine using libunwind7-dev, so I thought to check with you - if you have any information that unwind7 in wheezy would be insufficient/too buggy for google-glog? - would you mind adjusting debian/control to Build-depend on libunwind8-dev [i386 amd64] | libunwind7-dev [i386 amd64] to ease its future backporting? Thank you in advance On Mon, 13 Jan 2014, Sebastien Jodogne wrote: > Hi Andreas and Yaroslav, > >>I was not able either to find a complete "backporting handbook" for > >>Debian Med packages: Andreas, is there such a guide available > >>somewhere? > >I admit I'm quite lazy with backports and while I definitely think this > >is a reasonable task I somehow consider it "Somebody Else's Problem". > >I simply need to restrict my field of work. > Yes, you are perfectly right. > Yaroslav, I have just expanded the build instructions for Debian Wheezy [1]. > The only third-party package that should be backported to get an > Orthanc package for Wheezy is libgoogle-glog-dev [2] (only available > for Squeeze and Sid). I will not personally do this backporting > task, but if someone does it, I could then backport Orthanc to > Wheezy. > Cheers, > Sébastien- > [1] http://goo.gl/t7XVqe > [2] http://packages.debian.org/en/sid/libgoogle-glog-dev -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140114183855.gz18...@onerussian.com
Re: Thank you Luis!
On Tue, 14 Jan 2014, Andreas Tille wrote: > > >BTW, > > >we are now making progress > > >on the "vista-foia" package. > > > Luis > > BTW since fis-gtm backport builds nicely for wheezy and ubuntus >= > > 12.04, would it be of any value for you guys if we provided backports > > for it from NeuroDebian? > I have commited my backports ignorance here but how does this work > exactly? Are you providing a separate backports archive for NeuroDebian > or are you uploading to backports.debian.org and link somehow to this > from NeuroDebian? not quite... I must confess that we have also committed our ignorance toward backports.debian whenever it was yet to become official, and initial "pipeline" for backporting was a bit too cumbersome. So we just initiated NeuroDebian repository with backports not only for Debian but also for Ubuntus. It has no relation/connection to now official backports.debian.org, although the script Michael has developed [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660208] could easily be used to formalize automated backport builds for the official Debian as well. So whenever time comes we might just do backports to official Debian -- just needs time and motivation to do that. > I'd consider the later approach sensible and helpful > but it might create more work for you (exactly the work I'm personally > afraid of). yeap ;) moreover there is a temporal gap effect -- now we upload to NeuroDebian virtually always in sync with upload to Debian unstable. For official backports we would need to wait for propagation to testing, and by then we would simply forget, thus those backport uploads would always be on per-request basis as an afterthought ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140114142235.gl18...@onerussian.com
Re: Thank you Luis!
On Tue, 14 Jan 2014, Luis Ibanez wrote: > > Thank You All ! :-) > > BTW, > > we are now making progress > > on the "vista-foia" package. > > Luis > BTW since fis-gtm backport builds nicely for wheezy and ubuntus >= > 12.04, would it be of any value for you guys if we provided backports > for it from NeuroDebian? >Yes, having backports from NeuroDebian (or from [2]backports.debian.org >as Andreas suggested) will be very valuable for our efforts of >disseminating >fis-gtm (and hence M/MUMPS). >We will be happy to help, if anything needs to be done, >but we will certainly need guidance from you. :-) nothing to be done ;) fis-gtm backports now uploaded for Debian wheezy and Ubuntu >= 12.04 to NeuroDebian repository. portal's website should pick it up within a day upon regeneration and fis-gtm will get its own page overviewing available versions in stock debian/ubuntu and neurodebian. If upon next uploads to Debian you feel that the release/package is ready to replace current backport build version in NeuroDebian -- please buzz me and I will build/upload it. Cheers! -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140114141709.gk18...@onerussian.com
Re: Thank you Luis!
On Mon, 13 Jan 2014, Luis Ibanez wrote: > Thank You All ! :-) >BTW, >we are now making progress >on the "vista-foia" package. > Luis BTW since fis-gtm backport builds nicely for wheezy and ubuntus >= 12.04, would it be of any value for you guys if we provided backports for it from NeuroDebian? -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140114061544.gg18...@onerussian.com
Re: Orthanc 0.7.2 backport of wheezy
On Mon, 13 Jan 2014, Sebastien Jodogne wrote: > >I admit I'm quite lazy with backports and while I definitely think this > >is a reasonable task I somehow consider it "Somebody Else's Problem". > >I simply need to restrict my field of work. > Yes, you are perfectly right. > Yaroslav, I have just expanded the build instructions for Debian Wheezy [1]. > The only third-party package that should be backported to get an > Orthanc package for Wheezy is libgoogle-glog-dev [2] (only available > for Squeeze and Sid). I will not personally do this backporting > task, but if someone does it, I could then backport Orthanc to > Wheezy. cool! I will check it out Thanks! > [1] http://goo.gl/t7XVqe > [2] http://packages.debian.org/en/sid/libgoogle-glog-dev -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140113184220.gg18...@onerussian.com
Thank you Luis!
For a very nice post http://www.osehra.org/blog/packaging-fis-gtm-debian-linux-distribution-0 ;-) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140113031859.gz18...@onerussian.com
Orthanc 0.7.2 backport of wheezy
Hi Sebastien, Thank you for packaging orthanc -- it looks very interesting! I wonder -- are there big showstoppers which would forbid its backport for wheezy? At some point (0.4.0 iirc) I have tried to build it for wheezy but then got stuck while backporting also some of the dependencies... Cheers! -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140113031434.gy18...@onerussian.com
Re: Bug#728797: ITP: python-mne -- Python modules for MEG and EEG data analysis
ok - done, 0.7.1-2 went into neurodebian, wheezy users should become happier ;) cheers On Sun, 12 Jan 2014, Alexandre Gramfort wrote: > all good for me. > I'll let you know when we merge the PR with the py 2.6 fixes. > I'll then backport and tag 0.7.2 > thanks > Alex > On Sun, Jan 12, 2014 at 7:39 PM, Yaroslav Halchenko > wrote: > > ok -- while "support 2.6" actions are cooking I thought it would be > > worthwhile to reupload to NeuroDebian a build without 2.6. > > Would there be objections if I push to git the following commit and upload > > generated packages to NeuroDebian. Marked changelog as 'neurodebian' since > > that is where it is intended to go and makes no sense for unstable i.e. > > proper > > Debian upload > > $> git show > > commit e1d70152267aedf2ba7f4f5be167d53854d5b2c2 > > Author: Yaroslav Halchenko > > Date: Sun Jan 12 10:03:16 2014 -0500 > > Boost X-Python-Version to >= 2.7 to provide installable builds for > > wheezy > > diff --git a/debian/changelog b/debian/changelog > > index b23aa17..c7f2b36 100644 > > --- a/debian/changelog > > +++ b/debian/changelog > > @@ -1,3 +1,10 @@ > > +python-mne (0.7.1-2) neurodebian; urgency=low > > + > > + * Boost X-Python-Version to >= 2.7 to provide installable > > +builds for wheezy > > + > > + -- Yaroslav Halchenko Sun, 12 Jan 2014 10:02:56 > > -0500 > > + > > python-mne (0.7.1-1) unstable; urgency=low > >[ Alexandre Gramfort ] > > diff --git a/debian/control b/debian/control > > index b85808a..5ab70eb 100644 > > --- a/debian/control > > +++ b/debian/control > > @@ -25,7 +25,7 @@ Standards-Version: 3.9.5 > > Vcs-Browser: http://anonscm.debian.org/gitweb/?p=debian-med/python-mne.git > > Vcs-Git: git://anonscm.debian.org/debian-med/python-mne.git > > Homepage: http://martinos.org/mne > > -X-Python-Version: >= 2.6 > > +X-Python-Version: >= 2.7 > > Package: python-mne > > Architecture: all > > On Sat, 11 Jan 2014, Alexandre Gramfort wrote: > >> or may be you would prefer to adjust that one to stay 2.6 compatible? > >>I guess that would be better as it should stay compatible with 2.6 ... � > >>it's a mistake on our side... I'll setup a jenkins on 2.6 to avoid this > >>issue > >>in the future. > >>� > >> also for testing, I am usually trying to test with all supported > >> versions, which could help point out other possible 2.7 dependencies. > >> ATM you are testing only for current version... (in Debian sid it is > >> 2.7 > >> only but in older ones ,multiple) > >> ok -- let me cook up testing first, see if there is anything else TODO > >> for 2,6 support, if not much then I would wait on your thoughts first > >>thanks for your help > >>Alex > >>� > > -- > > Yaroslav O. Halchenko, Ph.D. > > http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org > > Senior Research Associate, Psychological and Brain Sciences Dept. > > Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 > > Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 > > WWW: http://www.linkedin.com/in/yarik -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140112192200.gq18...@onerussian.com