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
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:
>
> 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
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
> > b
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
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
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
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
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
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
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
>
>https:
> 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
>
>
>
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
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
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
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 there is a &quo
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
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
> 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
>
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
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
> 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
> 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
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
> 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
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,
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@l.d.o had
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 gulp it's long.
As
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.debian.org/1473636
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
Doctest of tss.rst
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
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
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
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 comes
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
be able
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 reminder
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
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 jars
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.git repository.
One
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
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
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. Trouble?
Package: wnpp
Severity: wishlist
Owner: Diane Trout di...@ghic.org
X-Debbugs-CC: debian-med@lists.debian.org, debian-de...@lists.debian.org
Package name: htseq
Version: 0.5.4p3
Upstream Author: Simon Anders sand...@fs.tum.de
URL: http://www-huber.embl.de/users/anders
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 be
.
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 -- high-throughput genome sequencing analysis.
Package: wnpp
Severity: wishlist
Owner: Diane Trout di...@ghic.org
X-Debbugs-CC: debian-med@lists.debian.org
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.
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
, 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 reasonable target for us.
I've pushed the debian/* control files to
https
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 actually
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
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 another
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
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
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
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
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
(python 2.6+2.7+3.0 etc..)
Cheers
-Dominique
On Tue, Dec 18, 2012 at 10:02 PM, Diane Trout di...@ghic.org wrote:
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
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
66 matches
Mail list logo
