On Sun, 2024-05-19 at 13:12 +0200, Andreas Tille wrote:
> Hi,
>
> I have an invitation to have some talk with the title
>
> Debian GNU/Linux for Scientific Research
>
>
I learned from some of the LIGO sysadmins at Caltech that some of the
LIGO systems are using Debian.
The LIGO documentati
On Thu, 2024-03-28 at 14:51 +0100, Michael R. Crusoe wrote:
>
> Like all policy proposals, this is not meant to be a hard rule for
> all time. We can and should revisit the issue later!
What do you think of the policy being instead of "-med team packages
MUST support all current Debian architectu
On Wed, 2021-02-10 at 18:35 -0500, Sandro Tosi wrote:
> +Steffen explicitly, given the team is not in Maintainer nor
> Uploaders
>
> > How about renaming the current python3-louvain package to
> > python3-community-louvain using a normal transition package.
>
> that's incorrect: src:python-louvai
>
> In the short term I recommend fixing this by adding a file to the
> Debian python-louvain package named "debian/tests/autopkgtest-pkg-
> python.conf" with the contents "import_name = community"
>
How about renaming the current python3-louvain package to
python3-community-louvain using a nor
On Wed, 2021-02-10 at 10:29 +0100, Michael R. Crusoe wrote:
>
> In the short term I recommend fixing this by adding a file to the
> Debian python-louvain package named "debian/tests/autopkgtest-pkg-
> python.conf" with the contents "import_name = community"
>
Thank you!
I had a hunch there was
On Wed, 2021-02-10 at 01:49 +, Paul Wise wrote:
> On Tue, Feb 9, 2021 at 10:21 PM Diane Trout wrote:
>
> > The fairly popular (in the world of bioinformatics) ScanPy package
> > uses
> > a Python version of the louvain clustering algorithm implemented
> > by:
Hello,
The fairly popular (in the world of bioinformatics) ScanPy package uses
a Python version of the louvain clustering algorithm implemented by:
https://github.com/vtraag/louvain-igraph
https://pypi.org/project/louvain/
which installs into the "louvain" dist-packages directory.
(from debc)
./
On Wed, 2020-12-09 at 19:31 +0100, Mattia Rizzolo wrote:
>
> Even then, the message says that "cluster3 has no binaries on any
> arch"
> - from there why can't one try to figure why there are no binaries?
> I'm
> positive that dumping the tracker link and that message in
> debian-mentors@ would y
On Wed, 2020-12-09 at 18:27 +0100, Mattia Rizzolo wrote:
> Because you seem to not be aware of how non-free works. Non-free is
> not
> autobuilt, so when Andreas uploaded 1.59+ds-2 without any binaries
> then
> "cluster3 has no binaries on any arch". Since there are no binaries
> associated with
Hi,
My coworker noticed cluster3 dropped out of testing and I'm confused
why.
https://tracker.debian.org/pkg/cluster3
says that "cluster3 has no binaries on any arch", and there are no logs
at buildd https://buildd.debian.org/status/package.php?p=cluster3 for
it
However if I grab either the sour
On Fri, 2020-11-06 at 08:23 +0100, Andreas Tille wrote:
> Dear Diane,
>
> would you mind pushing your patch to the Git repository? I mean its
> your ITP and you are Uploader - so I hesitate to push your very own
> patch on behalf of you. ;-)
>
> Thanks a lot for your helpful hints and contacting
On Thu, 2020-11-05 at 14:59 -0800, Diane Trout wrote:
> On Thu, 2020-11-05 at 21:08 +0100, Andreas Tille wrote:
> > Control: tags -1 help
> >
> > Hi Diane and Steffen,
> >
> > I fixed the Build-Depends in this package which leads to the
> > effect that
&
On Thu, 2020-11-05 at 21:08 +0100, Andreas Tille wrote:
> Control: tags -1 help
>
> Hi Diane and Steffen,
>
> I fixed the Build-Depends in this package which leads to the
> effect that
>
> a) the Build-time test is run
> b) shows the same errors as the autopkgtest
I went ahead and filed an
It sure looks like at least some of those failures are from upstreams
tests assuming they'd be run directly in the source tree.
All but one of the test cases can be fixed by including some test files
in the package, though it ends up in anndata/tests/
It's about 9 kilobytes with a csv, tsv, and x
Hi,
I was working on packaging for louvain-igraph and noticed that igraph
dropped out of unstable for two reasons. One was fixed but it appears
the incomplete copyright file isn't fixed.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953941
I'll make a stab at improving it right now.
I'm w
On Tue, 2020-03-24 at 23:07 +0100, Steffen Möller wrote:
> In the new queue is
>
> vienna-rna - and we are talking about a virus with single RNA strand
> as
> a genome, also a dependency of a dependency for bcbio
> dnapi - another RNA-one, dependency for bcbio
> python-numpy-groupies - forgot what
On Tue, 2020-03-17 at 23:13 +0100, Andreas Tille wrote:
> On Tue, Mar 17, 2020 at 10:35:23AM -0700, Diane Trout wrote:
> > MulticoreTSNE https://github.com/DmitryUlyanov/Multicore-TSNE
> > (Lacks release tags, haven't tried to package yet)
>
> I've pushed
>
>
> Would you mind just to fire up this script
>
>
> https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/inject-into-salsa-git
>
> to create the salsa project?
>
> We also have this script
>
>
> https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/scripts/itp_from
I also had a partial packaging of monocle3 while desperatly trying to
finish some work for our paper.
Would it also be useful for others?
https://cole-trapnell-lab.github.io/monocle3/
Diane
Hello,
(edited into a different thread since it's about a different package)
> > Which is a dependency for scanpy
> > https://pypi.org/project/scanpy/
> >
> > Which is a single-cell RNA seq analysis package.
>
> We probably want this!
:) It looked pretty useful and I noticed some of our colla
Hello,
On Tue, 2020-03-17 at 10:55 +0100, Steffen Möller wrote:
>
> license was gone. No idea if I had uploaded that also to New - could
> not
> find it there. If you have the strength, please adopt it from salsa.
Ok I'll try to finish loompy off.
>
> Sidenote: The certificate of https://track
Hello,
On Tue, 2020-03-17 at 08:48 +0100, Andreas Tille wrote:
>
> Please check and merge your stuff to
>
>https://salsa.debian.org/med-team/python-loompy
>
> Steffen is very active but has a lot of stuff on his table. You'll
> do
> the whole team a favour if you add yourself to Uploaders
Hi,
I hadn't filed a ITP for loompy, but had built a package for testing
purposes.
Steffen Moeller did file a ITP back in Aug 2019.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934597
I tried asking them about the status on 02 March, but haven't heard
back. Does anyone know Steffen and know
On Thu, 2020-03-05 at 11:22 +0100, Mattia Rizzolo wrote:
> On Wed, Mar 04, 2020 at 02:34:26PM -0800, Diane Trout wrote:
> > What's the debian-med team's position on whether or not to include
> > the
> > upstream history as described in:
>
> I don't think
Hi,
What's the debian-med team's position on whether or not to include the
upstream history as described in:
https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html
There's supposedly some advantages for handling patches but I
haven't figure out how to do that
Hi,
I've been asked to start trying to use cromwell
https://software.broadinstitute.org/wdl/
Debian doesn't have packaging for it yet, it looks like its BSD
licensed with an extra "no endorsement clause"
https://github.com/broadinstitute/cromwell/blob/develop/LICENSE.txt
* Neither the name Broa
> As a gotcha, remember that this bug was born out of the fact that
> there
> was a package requiring a >= 1.5 dependency. I recommend you compile
> the symbol file with something << 1.5 (i.e. 1.4 or just re-add the
> file
> that was removed) and then update it appropriately so there will be
> no
On Thu, 2017-11-09 at 02:03 -0500, Afif Elghraoui wrote:
> > - TODO Split private cram headers off into a new libhts-private-dev
> > package
>
> I'd rather be in favor of restoring the bundled htslib to seqlib as
> the short term solution. Putting a private package in the archive may
> exacerbate
One of the htslib developers filed a new bug,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881170
asking us to not make their private libraries public. His suggestions
are fairly similar to whats Charles proposed.
What I'm thinking is:
- TODO Recommit symbols file
- TODO Split private cram
Hi everyone,
I talked some with upstream about the symbols issues with htslib2
https://github.com/samtools/htslib/issues/616
They think that cram/*.h are private headers, but because we have a
policy of avoiding convenience copies we made those functions public[1]
because a few applications embe
Hi,
pysam 0.12 just migrated to testing, but it depends on libhts2 1.5
which is currently blocked by 871314 because libhts2 1.5 breaks pysam
0.11
I suspect this needed a transition
Diane
> I have one question : all the examples in the part of the tutorial
> for setting up the development environment (i.e sudo apt-get install
> rerun ruby-foreman apt-cacher-ng |
> moreutils lighttpd rabbitmq-server) are relative to the specific
> package of 'rubby'? So when i want to set up the env
> I am not quite sure what you mean by "organizing the source tree",
> since
> you are supposed to have the unpacked sources from the upstream
> tarball,
> plus an additional debian/ folder containing the Debian specific
> files
> (control, copyright, rules...). This is common to all packaging
> I don't think this is a problem. Policy 4.13 [1] says
>
> ~~~
> Debian packages should not make use of these convenience copies
> unless
> the included package is explicitly intended to be used in this way.
> ~~~
>
> which I think matches the situation here.
Thank you for point that clause ou
Hi,
We needed to use pyBigWig for some of our processing.
https://pypi.python.org/pypi/pyBigWig/0.3.2 or
https://github.com/dpryan79/pyBigWig
Being able to read bigBed or bigWig and to be able to directly write
bigwig files seemed useful to us. The package is MIT/Expat licensed
I made a prototy
> I'll delay any further activities on
> https://anonscm.debian.org/cgit/debian-med/python-bx.git/
> so Diane has an opportunity to comment...If I have not missed that
> already.
>
I had just made a quick and dirty package for my lab.
I looked through my attempt and your version is vastly bette
I didn't know about TreeView X.
Back when I had to render xclust results I used JTreeView.
http://jtreeview.sourceforge.net/
I'm not sure if that meets your needs.
Diane
On Thursday, July 17, 2014 08:40:46 Charles Plessy wrote:
> Dear all,
>
> TreeView X is a neat package for displaying, prin
On Friday, June 20, 2014 15:01:08 Andreas Tille wrote:
> Hi Emilien,
>
> On Fri, Jun 20, 2014 at 02:36:01PM +0200, Emilien Klein wrote:
> > at package build time remove the
> > upstream-provided files and instead use the ones from the Debian
> > package.
>
> The recent discussion at debian-devel@
> In an aside - OpenEMR has a *ton* of minifed JavaScript. I have been
> reading that minified JavaScript is *NOT* considered source and I need to
> either provide the source or strip it from the code -- is that correct? I
> haven't started working down the list of files but it's long.
>
As f
e the version number to include +dfsg? Any hints about
what is required to make that repack method work?
Diane Trout
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.deb
messages.
One change from your code was I changed added
import matplotlib
matplotlib.user('agg')
to the start of test/test.py and test/tss_test.py to avoid an error I was
getting when trying to import _TkAgg.
I'm using HTSeq 0.6.1p1 and pysam 0.7.7.
Diane Trout
Doc
Hello,
I finally had some time to work on figuring out how to write a get-orig-source
target for HTSeq.
The subversion repository includes 69 mbytes of example data, which upstream
uses for test cases. But the official pypi release deletes the test code &
test data. (In addition to not shippin
On Thursday, April 10, 2014 15:30:21 Alex Mestiashvili wrote:
> Dear mentors,
>
> I would greatly appreciate if somebody would help with the #733352, I've
> spent a couple of hours trying to resolve the issue but my cpp skills
> are rather poor.
>
> Thank you,
> Alex
The patch below deals with o
> Without beeing able to evaluate your chances to convince upstream (which
> would my *personal* prefered choice) I think you shoudl decide what from
> your point of view is the solution that might create the least trouble
> with an acceptable result for the user. We have some
> debian/get-orig-s
Hello,
I was wondering what one should do when upstream's source release tarball is
missing important components.
HTSeq's release tarballs after my initial release stopped including the .pyx
and .i source files and only included the C/CXX code generated by SWIG and
Cython.
I also discovered H
> Brainstorming here: we'd need a platform to promote community contributions
> to scientific Open Source software. Something tells me, that this could
> be something like "us" (whatever "us" is), but in some less distribution
> centric way. For Bioinformatics, the Open Bioinformatics Foundation c
On Wednesday, March 19, 2014 23:09:25 Andreas Tille wrote:
> On Wed, Mar 19, 2014 at 12:46:16PM -0400, Carlos Borroto wrote:
> > I would definitely prepare good material talking about
> > 'reproducibility'. More below.
>
> I think the more effort we spent in autopkgtest suites the more we will
> b
> That's fine but I personally do not require this for sponsoring. I
> always fetch the packaging from VCS.
Ok. debian/changelog pushed to alioth. Though I still haven't pushed a release
tag. Should you do that, or should I?
> It depends. Sometimes the lintian issue should remain as a reminde
Hello again,
>
> sounds very sensible) this is the right approach. So if you would
> send an ITP this would be cool. I'm also perfectly fine if you would
> like to be Uploader of the package if you are interested.
>
I have a package built on mentors. (see below for mentors links)
I made a few
On Tuesday, March 11, 2014 13:03:55 Diane Trout wrote:
> I have injected some initial packaging stuff at
>
>git://anonscm.debian.org/debian-med/libcofoja-java.git
>
I built a version that seems to work with igv.
I went ahead and pushed two commits to the libcofoja-java.gi
>
> I have injected some initial packaging stuff at
>
>git://anonscm.debian.org/debian-med/libcofoja-java.git
>
> Unfortunately I have not idea what package might provide a proper
> bootstrap.jar. I think once this is clarified a patch of build.xml to
> point to the Debian locations of the
Hello,
I made an effort to try and clean up the code duplication mess of pysam /
samtools. My first attempt was to provide upstream with a suggestion on how to
build tabix as a shared library.[1] (As a step toward convincing them to make
samtools build libbam as a shared library)
However I don
> Done and uploaded. Congratulations to have this finished.
>
> Kind regards and thanks for your work
>
> Andreas.
And thank you for your help reviewing and sponsoring as well.
Diane
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Troub
Hello,
> So my memory was correct about the additional purpose of ITPs. I have
> seen that you droped the previous changelog entry for a non-Debian
> release. Since now the entry we are atempting to upload is the only one
> I have an additional suggestion for a change which is also in line with
>
> However, the ITP makes some other - you can call it bureaucratic -
> sense. As far as I know ftpmasters are dealing with the ITP bug number
> and it helps following the status of a new package. So for the house
> keeping part of the ITP function I would do it anyway. On the other
> hand I'd
Package: wnpp
Severity: wishlist
Owner: Diane Trout
X-Debbugs-CC: debian-med@lists.debian.org, debian-de...@lists.debian.org
Package name: htseq
Version: 0.5.4p3
Upstream Author: Simon Anders
URL: http://www-huber.embl.de/users/anders/HTSeq/doc/overview.html
> > > The next step would be to file an ITP bug report. Do you want to do
> > > this yourself or do you want me to do this (on behalf of the team - so
> > > the package wil remain yours).
> >
> > I'd like to submit the ITP, though as I'm still learning how to make a
> > correct ITP I'd like a re
e wil remain yours).
I'd like to submit the ITP, though as I'm still learning how to make a correct
ITP I'd like a review first.
Also while I was working on the ITP I changed my previous description a little
bit.
--[ITP]--
To: sub...@bugs.debian.org
Subject: ITP: htseq -
>
> > If that looks decent I can push to alioth.
>
> Just push to alioth and I'll check from there. This enables others from
> the team to commit slight changess - sometimes it is more easy to just
> apply a change than to describe what should be changed.
Packaging pushed to git://git.debian.or
Hi again,
I made some more progress on packaging HTSeq.
* I switched to git-buildpackage style packaging.
* Its now installing the user scripts into /usr/bin
* It now builds (and installs!) man pages for the
* Upstream claims the main purpose of HTSeq is to write your own analysis
scripts.
rest in Debian Med.
>
> On Thu, Jul 25, 2013 at 11:32:20AM -0700, Diane Trout wrote:
> > I've built a debian package for HTSeq.
>
> Cool!
>
> > Upstream description.
> > http://www-huber.embl.de/users/anders/HTSeq/doc/overview.html
>
> Looks like a pretty rea
Hi.
I've built a debian package for HTSeq.
Upstream description.
http://www-huber.embl.de/users/anders/HTSeq/doc/overview.html
I've pushed the debian/* control files to
https://github.com/detrout/python-htseq
Does that look like something that should go in through debian med?
Does the packagin
> > You does the byte compilation yourself in postinst/prerm, but I think it
> > would be better to use provided tools.
>
> +1 (or should I say +2?)
>
Dropping in late to a conversation.
I'm pretty sure debian byte compiles on install because you don't know which
python interpreters are actua
debian in general likes there to be official releases. A lot of the packaging
tools are designed around tracking specific versioned tarballs. to make
releases repeatable there needs to at least be tagged versions. Though tarballs
would be better.
DianeOn 1/18/13 7:52 Tony Travis wrote:
On 18/01
> > Also just to check, can does the dynamic linker treat the same symbol name
> > in two different shared libraries as different?
>
> I have not tried this but we might be able to sort this out on
> debian-mentors list.
>
> Thanks for your investigations into this topic
Also, I realized I have
Hello,
Steffen Möller suggested I introduce myself.
I'm a software developer / system administrator working in the Wold Lab at the
California Institute of Technology. The lab's focus is on genome scale
transcription regulation. My current main job duties are dealing with tracking
and submittin
Hi,
The other pysam dependency is tabix which I tried to convert it to a shared
library.
I put my patch to make tabix use libtool to build static, linux or os x shared
libraries at [1]:
However I haven't modified the debian package to actually build a libtabix1 and
libtabix-dev package.
I di
What do you think of this wording?
git-buildpackage can be set to a directory layout similar to the one we use
with svn-buildpackage by using the export-dir and tarball-dir options. However
those settings should only be in a system-wide and or user-wide gbp.conf file
and not the one committed t
> Lastly, if the pristine-tar branch is causing problems, we can also deprecate
> it completely and rely solely on the Debian archive as the source of pristine
> tarballs. The pristne-tar system provides a service that is not available
> with subversion, and that I find useful, but that service is
Assuming this problem is also happening independently of the --pristine-tar
import issues. It looks to me like python setup.py clean is erroring out when
there's nothing to clean.
many clean targets end up ignoring errors by adding a "-" at the start of the
command. e.g. for the rules file from
Hello,
I had built our own version of samtools so it created a shared library. It then
ocurred to me to try building pysam against this shared library. I was able
make it work well enough to run pysams test cases.
Would modifying the debian samtools and tabix packages to build shared objects
b
t; temporary test output directory? This would be helpful in case we want to
> run the tests multiple times (python 2.6+2.7+3.0 etc..)
>
> Cheers
> -Dominique
>
>
> On Tue, Dec 18, 2012 at 10:02 PM, Diane Trout wrote:
>
> > Hi,
> >
> > I've been ma
Hi,
I've been maintaining a pysam package for my lab, and realized that other
people might find pysam[1] useful.
I used stdeb, git-buildpackage, and pbuilder to make my own package[2].
Unfortunately since I haven't actually talked to experienced packagers I'm sure
there are improvements I cou
73 matches
Mail list logo
