Re: Any input for some talk about usage of Debian in HPC
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 documentation https://computing.docs.ligo.org/guide/software/debian/ mentions a server for their custom apt repository, and I thought I'd look around which gives this information page about their cluster. https://hypatia.aei.mpg.de/cgi-bin/hypatia-index.cgi?p=main Which looks like a fairly large HPC cluster running Debian, and using Debian tool FAI. Diane
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
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 architectures", "-med team packages (CAN or SHOULD) try to support all current Debian architectures." Many packages do work fine, but some make no sense without being able to access much more than 4G of memory or have picky CPU architecture dependencies. I don't think the team should automatically turn off all more obscure architectures, but it seems very reasonable to be quite willing disable builds for things that cause problems outside of x86_64/arm64. Diane signature.asc Description: This is a digitally signed message part
Re: Bug#982417: Python louvain packages naming confusion.
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-louvain builds a module called > `community` (that includes also a cli tool), so the resulting binary > package should either be `python3-community` or `community` where the > cli is the main product and the module is installed in /usr/share/ to > support it. > It is bending policy, but I liked python3-community-louvain because the package name "python3-community" is just an exceptionally vague name. I think it's clearer if the name of the algorithm is in the package name. Also while looking through scanpy's louvain function I learned of yet more implementations of louvain. (Look through this function for different "flavors") https://github.com/theislab/scanpy/blob/550b82fdb53f35890e60343b826dd19454600bdb/scanpy/tools/_louvain.py#L23 Apparently what I'd previously called "igraph", scanpy calls "vtraag" because the vtraag version builds on the louvain implementation in python-igraph. There's also yet another version in nvidia's rapids library. > > Then I can submit the other louvain package using a binary package > > name > > of python3-louvain-igraph. > > this is incorrect too: (perspective) src:louvain (or > src:louvain-igraph, as the upstream called their repo) builds a > module > called `louvain` so the resulting binary package should be > `python3-louvain` eventually conflicting with the existing package > (<< > current-version-in-sid) > > src:python-louvain is in a pretty bad shape: it received a single > upload in late 2018, it has an RC bug since a *day* after that > upload, > and it has never been in testing: tbh i dont consider this package to > be maintained/targeting any stable release, so i believe you can > "take > over" the namespace given you seem to show interest in maintaining > https://github.com/vtraag/louvain-igraph I wasn't sure how much effort to put into saving the previous Debian louvain package since it didn't look like it was really usable by anyone. Libraries.io makes it look like the python-louvain "import community" version is a bit more popular and more actively developed. The "vtraag" version has a comment in it's REAME saying the developer deprecated it in favor of leidenalg (an improved method). On the other hand scanpy thinks the vtraag version is the most feature full implementation of louvain and uses it as their default. Diane
Re: Python louvain packages naming confusion.
> > 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 normal transition package. (I got the new name from wRAR pointing out that upstream even suggests "import community as community_louvain") Then I can submit the other louvain package using a binary package name of python3-louvain-igraph. Eventually we can just drop the python3-louvain package in favor of the more specific names. Diane
Re: Bug#982417: Python louvain packages naming confusion.
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 an override option, but I couldn't find it. Diane
Re: Python louvain packages naming confusion.
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: > ... > > However currently in the Debian archive there's a different louvain > > package > > I think this is something that the two upstream projects should > discuss and come to an agreement on the right outcome, since the > current set of names is confusing and overlapping. Perhaps the two > projects will end up getting merged into one project, or one of them > deprecated or one or both of them renamed. >From the perspective of pypi. One is "louvain" (which installs into "louvain" and one is "python- louvain", which installs into "community". If you're using pip you can easily install both of them if you want. > > > I was wondering if the python3-louvain's binary package should be > > renamed to python3-community to match the python package name, and > > then > > the other louvain-igraph package could provide a bin package named > > python3-louvain which would match the package name. > > There are no reverse dependencies in Debian, but this is going to be > tricky for users who previously installed python3-louvain.deb from > python-louvain upstream and then after upgrading they suddenly get > python3-louvain.deb from louvain-igraph with presumably an > incompatible API etc. > Cleaning it up seemed hard. Currently the version python3-louvain in unstable based on python- louvain is 0.0+20181013git3fc1f575 and the current upstream version is 0.15. For the louvain igraph package their current version is 0.7.0. At the very least, the current python3-louvain package needs to be renamed to python3-community to meet python policy and to make the CI autodep8 import test work. So that seems like make a new release of python-louvain using the 0.0git convention with a transition package that depends on a new python3-community package. And then leave that alone for "a while". At some point then the new python3-louvain package based on the louvain igraph module could have a check in the maintainer script to tell the user to switch to python3-community if it's the older python-louvain version. Once the packages are renamed then the python-louvain version could switch from the 0.0git convetion to the pypi version. (Upstream didn't bother to put tags on github, so the only version numbers come from pypi). I have no idea how long the transition package should sit around for though. Diane
Python louvain packages naming confusion.
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) ./usr/lib/python3/dist-packages/louvain/ I have it mostly packaged However currently in the Debian archive there's a different louvain package https://github.com/taynaud/python-louvain https://pypi.org/project/python-louvain/ https://salsa.debian.org/python-team/packages/python-louvain It installs into (according to debc) ./usr/lib/python3/dist-packages/community/ Unfortunately for this package we now automatically run autodep8 which fails because the import name is community and not louvain. autopkgtest [13:29:03]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import louvain; print(louvain)" ; done autopkgtest [13:29:03]: test autodep8-python3: [--- Testing with python3.9: Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'louvain' autopkgtest [13:29:03]: test autodep8-python3: ---] autopkgtest [13:29:03]: test autodep8-python3: - - - - - - - - - - results - - I think having a python3-louvain-igraph package which installs into louvain, while there is a separate python3-louvain package which installs into community is really confusing. I was wondering if the python3-louvain's binary package should be renamed to python3-community to match the python package name, and then the other louvain-igraph package could provide a bin package named python3-louvain which would match the package name. But this is clearly a thing that needs to be discussed. Diane
Re: Bugs "fails to migrate to testing for too long" (Was: cluster3 dropped out of testing)
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 yield the reason why it's stuck quite quickly. > (note that the thread Andreas started on -devel@ is about the how > people > seems to notice first the "failed to migrate to testing" bugs, not > about > why cluster3 is not migrating). After learning of the issue I went with asking the debian-med team since I thought I was missing something, I hadn't thought asking debian-mentors. I do think it would've saved everyone's time if excuses included a suggestion to go read 5.10.5 https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable for non-free packages in that state. It is not uncommon to forget a detail that one doesn't use frequently. Thank you for explaining the problem though. Diane signature.asc Description: This is a digitally signed message part
Re: Bugs "fails to migrate to testing for too long" (Was: cluster3 dropped out of testing)
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 the source, britney refuses to migrate it. Indeed, > one > could just do a binary-only build of it, upload it, and it would > migrate > stright the next day. > > Or one could ask for an exception to the non-free buildds as > docuemnted > on > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable > > As you can see, nothing relating to that bug. > Could we add a note to tracker or excuses for non-free packages on what the developer needs to do to get it to migrate? My understanding of your explanation is that we need to do a binary upload for non-free because it's not auto-built. It's a difference from how main is handled and and it seems like putting documentation for the difference would help prevent confusion in the future. Diane signature.asc Description: This is a digitally signed message part
cluster3 dropped out of testing
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 source package for 1.59+ds-2 or the current main branch from salsa and try building, I get a package with binaries. The only mildly annoying thing is when I build in unstable, it ends up with a dependency on python3 (<< 3.10), python3 (>= 3.9~) which doesn't install on testing. But the package seems to be fine, so any thoughts why it was held back? Diane
Re: Bug#954170: Help: Test suite failures (Was: ITP: anndata -- Annotated gene by sample numpy matrix)
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 upstream I pushed the patches... Is there anything else anyone wants to do to the package or should I submit to NEW?
Re: Bug#954170: Help: Test suite failures (Was: ITP: anndata -- Annotated gene by sample numpy matrix)
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 > > > > a) the Build-time test is run > > b) shows the same errors as the autopkgtest > > I went ahead and filed an upstream bug asking for any advice about > the > unexpected warning. > > https://github.com/theislab/anndata/issues/443 I discovered anndata is having trouble with the version of pandas we're shipping. This patch fixes the test failure, though I thought I'd ask upstream if they want to do this, or be more accepting of warnings. (I'm not sure which versions of pandas they want to support). Should we wait for upstream or just go ahead and add the patches to our packaging? Diane --- anndata/_core/anndata.py2020-11-05 12:23:54.976471806 -0800 +++ /run/schroot/mount/unstable-amd64-sbuild-6f63c09f-36e0-4302-9409- 6689c5b05354/build/python-anndata-exfcES/python-anndata- 0.7.4+ds/anndata/_core/anndata.py 2020-11-05 15:28:33.517496264 -0800 @@ -19,5 +19,5 @@ from numpy import ma import pandas as pd -from pandas.api.types import is_string_dtype, is_categorical +from pandas.api.types import is_string_dtype, is_categorical_dtype from scipy import sparse from scipy.sparse import issparse @@ -1089,8 +1089,8 @@ def _remove_unused_categories(self, df_full, df_sub, uns): -from pandas.api.types import is_categorical +from pandas.api.types import is_categorical_dtype for k in df_full: -if not is_categorical(df_full[k]): +if not is_categorical_dtype(df_full[k]): continue all_categories = df_full[k].cat.categories @@ -1190,5 +1190,5 @@ key for key in df.columns -if is_string_dtype(df[key]) and not is_categorical(df[key]) +if is_string_dtype(df[key]) and not is_categorical_dtype(df[key]) ] for key in string_cols:
Re: Bug#954170: Help: Test suite failures (Was: ITP: anndata -- Annotated gene by sample numpy matrix)
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 upstream bug asking for any advice about the unexpected warning. https://github.com/theislab/anndata/issues/443
Re: Help: Test suite failures (Was: ITP: anndata -- Annotated gene by sample numpy matrix)
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 xlsx file included.
This is probably the easiest solution, though I though I remember
Debian policy discouraging putting data into the dist-packages
directory.
I'm not sure about the last test failure though
--- setup.py2020-03-02 16:10:44.668936082 -0800
+++ /run/schroot/mount/unstable-amd64-sbuild-6f63c09f-36e0-4302-9409-
6689c5b05354/build/python-anndata-exfcES/python-anndata-
0.7.4+ds/setup.py 2020-11-05 13:51:59.763629317 -0800
@@ -28,4 +28,5 @@
packages=find_namespace_packages(include=["anndata",
"anndata.*"]),
include_package_data=True,
+package_data={"": ["*.csv", "*.tsv", "*.xlsx"]},
zip_safe=False,
classifiers=[
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
>
>
> ...
> anndata/tests/test_deprecations.py::test_get_uns_neighbors_deprecated
> FAILED [ 36%]
> ...
> anndata/tests/test_readwrite.py::test_read_csv
> FAILED[ 51%]
> anndata/tests/test_readwrite.py::test_read_tsv_strpath
> FAILED[ 51%]
> anndata/tests/test_readwrite.py::test_read_tsv_iter
> FAILED [ 51%]
> ...
> anndata/tests/test_readwrite.py::test_read_excel
> FAILED [ 51%]
> ...
> === FAILURES
> ===
> __ test_get_uns_neighbors_deprecated
> ___
>
> adata = AnnData object with n_obs × n_vars = 2 × 3
> obs: 'anno1'
> var: 'anno2'
> uns: 'neighbors'
> layers: 'x2'
> obsp: 'connectivities'
>
> def test_get_uns_neighbors_deprecated(adata):
> n = adata.shape[0]
> mtx = sparse.random(n, n, density=0.3, format="csr")
> adata.obsp["connectivities"] = mtx
> adata.uns["neighbors"] = {}
>
> with pytest.warns(FutureWarning):
> from_uns = adata.uns["neighbors"]["connectivities"]
>
> assert_equal(from_uns, mtx)
>
> with pytest.warns(None) as rec:
> v = adata[: n // 2]
> > assert not rec
> E assert not WarningsChecker(record=True)
>
> anndata/tests/test_deprecations.py:113: AssertionError
> test_read_csv
> _
>
> def test_read_csv():
> > adata = ad.read_csv(HERE / "adata.csv")
>
> anndata/tests/test_readwrite.py:308:.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _.
> anndata/_io/read.py:48: in read_csv
> return read_text(filename, delimiter, first_column_names, dtype)
> anndata/_io/read.py:321: in read_text
> with filename.open() as f:
> /usr/lib/python3.9/pathlib.py:1241: in open
> return io.open(self, mode, buffering, encoding, errors, newline,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _.
>
> self = PosixPath('/build/python-anndata-
> 0.7.4+ds/.pybuild/cpython3_3.9_anndata/build/anndata/tests/adata.csv'
> )
> name = '/build/python-anndata-
> 0.7.4+ds/.pybuild/cpython3_3.9_anndata/build/anndata/tests/adata.csv'
> flags = 524288, mode = 438
>
> def _opener(self, name, flags, mode=0o666):
> # A stub for the opener argument to built-in open()
> > return self._accessor.open(self, flags, mode)
> E FileNotFoundError: [Errno 2] No such file or directory:
> '/build/python-anndata-
> 0.7.4+ds/.pybuild/cpython3_3.9_anndata/build/anndata/tests/adata.csv'
>
> /usr/lib/python3.9/pathlib.py:1109: FileNotFoundError
> test_read_tsv_strpath
> _
>
> def test_read_tsv_strpath():
> > adata = ad.read_text(str(HERE / "adata-comments.tsv"), "\t")
>
> anndata/tests/test_readwrite.py:315:.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _.
> anndata/_io/read.py:321: in read_text
> with filename.open() as f:
> /usr/lib/python3.9/pathlib.py:1241: in open
> return io.open(self, mode, buffering, encoding, errors, newline,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _.
>
> self = PosixPath('/build/python-anndata-
> 0.7.4+ds/.pybuild/cpython3_3.9_anndata/build/anndata/tests/adata-
> comments.tsv')
> name = '/build/python-anndata-
> 0.7.4+ds/.pybuild/cpython3_3.9_anndata/build/anndata/tests/adata-
> comments.tsv'
> flags = 524288, mode = 438
>
> def _opener(self, name, flags, mode=0o666):
> # A stub for the opener argument to built-in open()
> > return self._accessor.open(s
igraph incomplete copyright #953941
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 wondering if we can make this easier by Files-Excluding things that are not relevant for Debian, like the msvc/ directory and a number of embedded convenience copies. Diane
Re: https://github.com/nf-core/covid19 - nextflow pipeline
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 this was for - some dependency > for FYI numpy-groupies is a dependency for loompy pypi doesn't know of any other dependencies using numpy-groupies right now https://libraries.io/pypi/numpy-groupies/dependents
Re: Scanpy
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://salsa.debian.org/med-team/multicore-tsne > > Build time tests are failing but it might be a start. Oh, Thank you. I'll try to get to it in the next day or two. (I am technically supposed to be answering some final questions from the journal about our upcoming paper right now.) Diane
Re: Scanpy
> 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_debian_dir > > to create an ITP. > Ooh. Those look useful! Thank you.
monocle3?
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
Scanpy
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 collaborators were also using it. Scanpy takes advantage of a bunch of tools of various difficulties to package. anndata https://github.com/theislab/anndata (packaged, need to create salsa project and file ITP) umap-learn https://github.com/lmcinnes/umap (packaged, need to create salsa project and file ITP) MulticoreTSNE https://github.com/DmitryUlyanov/Multicore-TSNE (Lacks release tags, haven't tried to package yet) leidenalg https://github.com/vtraag/leidenalg (partially packaged, need to fix boilerplate and add copyright) louvain https://github.com/vtraag/louvain-igraph (partially packaged, need to fix boilerplate and add copyright also upstream deprecated in favor of leidenalg, though scanpy & monocle3 still use) Cellbrowser https://github.com/maximilianh/cellBrowser/blob/master/LICENSE (Partially packaged, but so much embedded javascript :( ) Diane
Re: loompy
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://tracker.debian.org/ expired. I had this happen to me once. It may be your client authentication certificate that expired, the client side expiration error message is quite confusing. Diane
Re: loompy
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 and upload > to > new. Will do!
loompy
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 what the status of the packaging is? I could pretty easily finish my earlier tests and submit if appropriate. I found it was a test dependency for anndata https://pypi.org/project/anndata/ Which is a dependency for scanpy https://pypi.org/project/scanpy/ Which is a single-cell RNA seq analysis package. signature.asc Description: This is a digitally signed message part
Re: including upstream history when upstream uses git
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 "team's position" on it, except that it's > not > usual at all. > Personally, I find it more confusing then anything else, in all the > packages where this schema is used. I've tried it and feel like I'm more likely to mistakes when updating. I felt like packages intended for teams it's probably better to stay with the simpler workflow for now. But I wanted to check. Diane signature.asc Description: This is a digitally signed message part
including upstream history when upstream uses git
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 yet. I have some prototype packaging I've done using that method for anndata and scanpy, but I could easily generate a fresh history using gbp import-dsc. Diane
cromwell
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 Broad Institute, Inc. nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. The build requirements include sbt (scala build tool). Debian has an older version, but it looks like the package was abandoned. https://tracker.debian.org/pkg/sbt
Re: Bug#879886: libhts2: libhts2 needs to handle ABI changes
> 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 > not > so tight versions. Done. I dug out the previous symbols files, which appeared to have been built up to 1.3.1, then I applied changes from 1.4.1 and then finally 1.5. There were a few symbols changes that were not clear cut and so they're currently removed but were done in a separate commit. There from 1.3.1 to 1.4.1 three symbols ks_destroy, ks_getuntil2, ks_init that disappeared from the library, but are in the headers as macros. The header macros look like they haven't changed much from even the 1.0 release, so I don't know why they were removed. From 1.4.1 to 1.5 there was a block of zf* functions that were removed. However those are from the "private" cram headers and so 1.5 is likely to cause issues for the programs that are using the cram support. Anyone want to review? or should I go ahead and release? Diane signature.asc Description: This is a digitally signed message part
Re: [Debian-med-packaging] Bug#879886: libhts2: libhts2 needs to handle ABI changes
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 the problem and is odd nevertheless. The no convenience copies of libraries is a pretty strong rule of Debian, and there are good maintenance reasons for it. Although I'm not opposed to it I'd like several people to agree that its the best option first. On the plus side overriding it would allow us to drop the patch that is making the cram symbols public, on the downside we'd have to remember that bugs involving htslib also impact libseqlib. I think we'd need to use the Built-Using tag? I haven't used that before. On the other hand upstream did suggest that the private-dev library was a viable temporary solution. (Though doing that would push htslib into NEW). > > And there is another action item-- > TODO update the htslib package to the latest release. Very true I did try building 1.6 and there was a problem with running tests that I haven't investigated yet. Diane
Re: [Debian-med-packaging] Bug#879886: libhts2: libhts2 needs to handle ABI changes
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 headers off into a new libhts-private-dev package - WAITING Try to talk htslib & SeqLib developers to agree on a public cram api so we can drop the private-dev package. > > Symbols file are strange to work with because their update usually > goes > through a build failure that outputs a patch, which is not very > intuitive. And then the patched symbols file has to be edited to > remove > the Debian minor version, otherwise it complicates backports etc. > Perhaps it can be simplified, better explained and streamlined. In > any > case, I think that for the htslib it is worth the effort. The KDE team had some nice utilities that downloaded the symbols files for all the architectures and could do batch patches. Unfortunately I think they're KDE specific. I'll commit my rebuilt symbols files the next time I'm not spending my day writing emails to everyone else. I need a chance to look more carefully if the missing symbols were actually not part of the private api. > > > I was wondering if we should split the cram headers into a > > libhts-private-dev so we can at least track what is depending on > > the > > non-public api. > > An ideal solution, and I understand that it may not be easy, would be > to > make the upstream users of htslib talk with the htslib developers, so > that they can implement what they want to without needing to access > private functions. I think that it would fit the aims of both sides. I wonder if I can forward one Debian bug to multiple upstreams But I tried to get SeqLb & htslib to talk to each other. SeqLib issue: https://github.com/walaj/SeqLib/issues/21 htslib issue: https://github.com/samtools/htslib/issues/619 > > > I did realize that my thought about updating the SOVERSION might be > > wrong because I was just looking in the source tree for the removed > > functions but I should have been checking the public header files. > > Indeed, packages using private functions need to have a tight > dependency > on the htslib (unless we are very confident that there are regression > tests that cover this area of the code). Packages that are more > well-behaved can infer their dependency through the (to be re-added) > symbols file. So that implies packaging that uses -private-dev that implies they have an == dependency on a specific binary version of libhts? That should probably probably be documented in a README.Debian for the private-dev package. Should I push these proposed changes to a clone of the htslib packaging repository? A branch of the alioth repository, or just push it to the alioth master? Diane >
Re: Bug#879886: [Debian-med-packaging] libhts2: libhts2 needs to handle ABI changes
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 embed htslib and directly use the private headers. I do think we should bring back the symbols file, but I was wondering if we should split the cram headers into a libhts-private-dev so we can at least track what is depending on the non-public api. I did realize that my thought about updating the SOVERSION might be wrong because I was just looking in the source tree for the removed functions but I should have been checking the public header files. Diane [1] https://anonscm.debian.org/cgit/debian-med/htslib.git/tree/debian/p atches/htslib-add-cram_to_bam.patch
pysam is broken in testing right now
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
Re: [Outreachy] Hi all!
> 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 environment for > running test in another package i will have to change these > commands accordingly? I suspect apt-cacher-ng is in there as a performance enhancement. apt-cacher-ng can help speed frequent rebuilding of packages because it can download and store locally packages. When you're first starting to test build an application you'd do: apt source apt build-dep cd dpkg-buildpackage (with the stretch release they added apt as an improvement to apt-get) Debian maintianers will usually build packages in a temporary environment using tools like pbuilder or sbuild. Those tools automate extracting the package, installing the dependencies, building, and running tests. It's just a bit of work to get them setup. And it looks like autopkgtest expects to be running in a temporary build environment so it can install things and change the system configuration. Hope that helps Diane
Re: pyBigWig
> 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 > policies. That was perhaps an awkward phrase. But what I meant was I used to doing git buildpackage style packages, but I was trying to make this package's repository git-dpm compatible. The Python Modules team is currently recommending git-dpm, and there's some extra configuration they suggested. https://wiki.debian.org/Python/GitPackaging#Tag_style Diane
Re: pyBigWig
> 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 out. As its a python module I followed python team conventions for organizing the source tree. But it seems like the package really should be under debian-med? Is that OK? Diane
pyBigWig
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 prototype package for us. http://woldlab.caltech.edu/woldlab-apt/pool/main/p/pybigwig/pybigwig_0. 3.2-0.dsc But the pyBigWig package includes the source of the authors libBigWig library: https://github.com/dpryan79/pyBigWig/tree/master/libBigWig And instead of building a shared library, they just add the C files to the python C extension. See: https://github.com/dpryan79/pyBigWig/blob/master/setup.py#L14 I believe this is a violation of Debian packaging policy, but this seems useful, what should one do in this case? Diane
Re: python-bx, upload ok? Re: galaxy dependency - current state
> 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 better. You should release it and I'll see if I can find who was using it here so they can try running their code with your package. Diane
Re: Future of TreeView X in Debian.
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, printing and exporting > phylogenetic trees. > > Unfortunately its author has no time anymore for it, and it does not work > with wxWidgets 3.0. It is therefore at risk of being removed from Debian. > > Still, its popcon records show a loyal user base and I do not know a full > drop-in replacement for it. NJplot would be the closest equivalent, and is > actually superior in some aspects, but its interface shows its age and it > can only export the trees in PostScript format, while TreeView X can export > in SVG. TreeView X also offers more choices for the shape of the cladogram. > > Would there be somebody interested in taking over the TreeView X upstream ? > If you can't but are interested to keep it in Debian, please pass the > message ! > > Alternatively, if you know a good replacement, please let us know ! > > Have a nice day, -- 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/1802512.rN3bbkhilv@myrada
Re: [MoM] Minified JS and other things
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 some quite strong > arguments to remove the files right in the *source* (using > Files-Excluded) and not at package build time. There is no written > policy yet but I understood this as a rough consensus. It's sufficiently consensus that lintian is reporting that case (of finding minified jquery) as an error. In case that's warning isn't the default my lintian command line is: lintian -Ii --pedantic --color auto Diane -- 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/1762095.zu7JeLET3n@myrada
Re: [MoM] Minified JS and other things
> 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 far as I understand it that's the correct interpretation. If you're lucky, you can try symlinking and depending on versions provided by a libjs- package. Diane -- 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/3367179.tdkxzqdG1U@myrada
get-orig-source
Hi, I noticed trimmomatic has a really nice way of filtering out non-dfsg compliant files from the upstream tarball. However when trying to use it in another project, I can't get uscan to tag the resulting .orig.tar.gz as $(PACKAGE)_$(UVERSION)+dfsg.orig.tar.gz. Is it supposed to rewrite 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.uaQAeb59Em@myrada
HTSeq test case failures
Hello,
I had time to make more progress on improving the debian HTSeq package, and
have updated it to run your test code.
Unfortunately I had some test case failures. I was wondering if the tests are
failing for you, or if its something about my configuration. Below is the
relevant error 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:
**
File "../doc/tss.rst", line 52, in tss.rst
Failed example:
for feature in itertools.islice( gtffile, 100):
if feature.type == "exon" and feature.attr["exon_number"] == "1":
print feature.attr["gene_id"], feature.attr["transcript_id"],
feature.iv.start_d_as_pos
Expected:
ENSG0223972 ENST0456328 1:11873/+
ENSG0223972 ENST0450305 1:12009/+
ENSG0227232 ENST0423562 1:29368/-
ENSG0227232 ENST0438504 1:29368/-
ENSG0227232 ENST0488147 1:29568/-
ENSG0227232 ENST0430492 1:29341/-
ENSG0243485 ENST0473358 1:29553/+
ENSG0243485 ENST0469289 1:30266/+
ENSG0221311 ENST0408384 1:30365/+
ENSG0237613 ENST0417324 1:36079/-
ENSG0237613 ENST0461467 1:36071/-
ENSG0233004 ENST0421949 1:53048/+
ENSG0240361 ENST0492842 1:62947/+
ENSG0177693 ENST0326183 1:69054/+
Got:
ENSG0223972 ENST0456328 1:11873/+
ENSG0223972 ENST0450305 1:12009/+
ENSG0227232 ENST0423562 1:29369/-
ENSG0227232 ENST0438504 1:29369/-
ENSG0227232 ENST0488147 1:29569/-
ENSG0227232 ENST0430492 1:29342/-
ENSG0243485 ENST0473358 1:29553/+
ENSG0243485 ENST0469289 1:30266/+
ENSG0221311 ENST0408384 1:30365/+
ENSG0237613 ENST0417324 1:36080/-
ENSG0237613 ENST0461467 1:36072/-
ENSG0233004 ENST0421949 1:53048/+
ENSG0240361 ENST0492842 1:62947/+
ENSG0177693 ENST0326183 1:69054/+
**
File "../doc/tss.rst", line 313, in tss.rst
Failed example:
len( list( tssarray.chrom_vectors["1"]["."].steps() ) )
Expected:
30089
Got:
30085
**
File "../doc/tss.rst", line 338, in tss.rst
Failed example:
for step_iv, step_set in tssarray[ almnt.iv ].steps():
print "Step", step_iv, ", contained by these windows:"
for p in step_set:
print " Window around TSS at", p
Expected:
Step 1:[169677680,169677837)/. , contained by these windows:
Window around TSS at 1:169679671/-
Window around TSS at 1:16969/-
Step 1:[169677837,169677880)/. , contained by these windows:
Window around TSS at 1:169680837/-
Window around TSS at 1:169679671/-
Window around TSS at 1:16969/-
Got:
Step 1:[169677680,169677838)/. , contained by these windows:
Window around TSS at 1:169677780/-
Window around TSS at 1:169679672/-
Step 1:[169677838,169677880)/. , contained by these windows:
Window around TSS at 1:169680838/-
Window around TSS at 1:169679672/-
Window around TSS at 1:169677780/-
**
File "../doc/tss.rst", line 359, in tss.rst
Failed example:
s ##doctest:+NORMALIZE_WHITESPACE
Expected:
set([,
,
])
Got:
set([, , ])
**
--
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/1932046.HMZbWiuJuv@myrada
HTSeq
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 shipping the source files for the swig and cython components) I'm wondering if I should include the test data in the repack so I can run the tests during build, or if that's too much file bloat? Diane -- 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/13602879.UBIjcoJs6d@myrada
Re: help needed for #733352
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 one of the compile errors. I don't know if just hiding the const modifier is better than pushing const-ness further into tophat. Unfortunately the next const error I get is even worse. Const-ness seems to get flipped between appendValue and trying to create a seqan::Gaps... Diane diff --git a/src/segment_juncs.cpp b/src/segment_juncs.cpp index e3acc46..d73e0d6 100644 --- a/src/segment_juncs.cpp +++ b/src/segment_juncs.cpp @@ -2056,8 +2056,8 @@ void juncs_from_ref_segs(RefSequenceTable& rt, MotifMap ims; -seqan::DnaStringReverseComplement rev_donor_dinuc(donor_dinuc); -seqan::DnaStringReverseComplement rev_acceptor_dinuc(acceptor_dinuc); +seqan::DnaStringReverseComplement rev_donor_dinuc(const_cast(donor_dinuc)); +seqan::DnaStringReverseComplement rev_acceptor_dinuc(const_cast(acceptor_dinuc)); if (talkative) fprintf(stderr, "Collecting potential splice sites in islands\n"); -- 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/4410632.gnG6kW7Kcc@myrada
Re: HTSeq released incomplete tarball.
> 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-source scripts in SVN which could serve as an example. Helping upstream improve their python packaging would be my preferred solution too. Though as upstream seems busy I'm not sure how long it will take for them to review my proposed patches. [1] Using get-orig-source to retrieve the from their subversion repository looks like a good path as well. (Upstream had said that they were viewing the pypi repository as "partially compiled" so they're more focused on including the auto-generated code than the cython .pyx and swig .i files.) Thank you for the recommendation. Diane [1] https://github.com/detrout/htseq/commits/master my proposed patches to upstreams repository -- still looking for a way to make it build with out swig installed. -- 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/2580008.6F64KpB6Ze@myrada
HTSeq released incomplete tarball.
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 HTSeq's more recent releases don't include the documentation tree. Upstream pointed me at their subversion repository[1], but it doesn't have release tags. I've tried to help upstream by trying to make some suggestions to improve their packaging. But I'm not sure what I should do now while waiting for them to decide if they want to use my changes. (And I was still missing some parts). My first attempt was to make a quilt patch that included the missing .i and .pyx files but then I discovered that the doc tree was missing and I'm not sure I want to add in a patch that is half of their release. (Upstream tarballs dropped from 52k to 22k because of the missing docs and source files.) I could make my own tarball from their subversion archive, or I could keep trying to engage upstream to make a new release with the missing files. Do you have any recommendations? Diane [1] svn://svn.code.sf.net/p/htseq/code/ -- 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/3079601.WVRP0oEis8@myrada
Re: Aw: Re: Presentation of Debian Med on local Next Generation Sequencing workshop (April)
> 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 > to mind. And, we need some way to reference such contribution. What just > jumped at me are a concept I learned about at last NETTAB in Venice: > Nano Publications (http://nanopub.org/). Those were meant for something > very different, but the concept should be adaptable, and I have not seen > them discussed in this social-scientific-security context. What do you > think? The people I know of who are working on encouraging better scientific software practices (version control, testing, and automation) are operating as http://software-carpentry.org/ Apparently they're now associated with http://mozillascience.org/ whose goal is "to make science more open, collaborative and efficent". Also the IPython developers are really interested in trying to create "executable papers" https://plus.google.com/+FernandoPerez/posts/gwxhuwgJRED Diane -- 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/3610479.dC0fYHk8oI@myrada
Re: Presentation of Debian Med on local Next Generation Sequencing workshop (April)
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 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. As a result the scientists our group tend to want to have consistent versions installed. I'm not sure if there's a good way of having multiple versions of a debian package available on a single system. Diane -- 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/13957649.Dslhpk2Qua@myrada
Re: Any volunteer to finish libcofoja-java (Was: Bug#741052: [igv] Unhandled exception java.lang.NoClassDefFoundError: com/google/java/contract/util/Objects)
> 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 fro > potential future fixes. An override is fine if there is really no point > that it would be fixed in the future. Ok. So it actually makes sense to leave the no upstream changelog and reminder to use gpg signatures as either of those could be added at any time. And both would be useful to have. Thank you for reviewing and sponsoring. Diane -- 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/2644921.nXmgP0SEq3@myrada
Re: Any volunteer to finish libcofoja-java (Was: Bug#741052: [igv] Unhandled exception java.lang.NoClassDefFoundError: com/google/java/contract/util/Objects)
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 more adjustments to the package, fixing up the copyright file, and adding a build-dependency. I ran lintian on my built package and just have warnings for no gpg signature in the watch file and no upstream changelog. (Should one make lintian overrides for those?) I haven't committed the release changelog to git yet. I'm not quite sure when to push that to make sure the dates and release tags are most correct. Diane ---mentors links--- Your upload of the package 'libcofoja-java' to mentors.debian.net was successful. Others can now see it. The URL of your package is: http://mentors.debian.net/package/libcofoja-java The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/libc/libcofoja-java/libcofoja-java_1.1-r150-1.dsc If you do not yet have a sponsor for your package you may want to go to http://mentors.debian.net/sponsors/rfs-howto/libcofoja-java and set the "Seeking a sponsor" option to highlight your package on the welcome page. -- 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/6908191.y4ZN0LvlUP@myrada
Re: Any volunteer to finish libcofoja-java (Was: Bug#741052: [igv] Unhandled exception java.lang.NoClassDefFoundError: com/google/java/contract/util/Objects)
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 change was to alter the patch that was changing the defaults.property file to not build a snapshot build. I then made a few changes to the debian/rules file to help build the bootstrap version of the cofoja library and run some of the tests. To get it to work with igv I've been manually editing /usr/bin/igv and adding /usr/share/java/cofoja.jar to the classpath. If that looks good should I file an ITP for libcofoja? We'll also need to update igv to list libcofoja as a dependency. Diane -- 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/5912265.OyzKCcjj3K@myrada
Re: Any volunteer to finish libcofoja-java (Was: Bug#741052: [igv] Unhandled exception java.lang.NoClassDefFoundError: com/google/java/contract/util/Objects)
> > 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 might do the trick. > > Any volunteer? > > Kind regards > >Andreas. I'll start working on it. Diane -- 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/2403331.nWHeoHGvBi@myrada
Re: About pysam
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't think they took advantage of it. I then discovered a worse code duplication problem in pysam & samtools with the attractivechaos/klib "library" [2] as far as I can tell a number of bioinformatics packages just periodically copy the source from that repository into their own projects. At that point I gave up, and just built a package for my lab. I recall seeing something about an improved libbam or samtools? (I can't quickly find Charles' posts on the list about it though) I could try cleaning the package up a bit for Debian, but I don't think I could resolve the code duplication issues. (I could at least get the copyright / README.Debian to acknowledge and point to where all the code is being duplicated from). Diane [1] my patch https://github.com/detrout/tabix/tree/dynamic-makefile [2] https://github.com/attractivechaos/klib On Tuesday, February 11, 2014 09:08:14 Andreas Tille wrote: > Hi Charles, > > thanks for your comments. Just an explanation for my engagement. I'd like > to package > >http://blends.debian.org/med/tasks/bio#gasic >http://blends.debian.org/med/tasks/bio#fitgpc > > and my reasons are given in the according remarks there. > > On Tue, Feb 11, 2014 at 01:43:16PM +0900, Charles Plessy wrote: > > Hi Andreas, > > > > I see that you are working on pysam, thank you for this ! > > > > If you are wondering why it was never uploaded, it is because of the > > extensive code duplications with the samtools and tabix packages, which I > > could not try to resolve because of my lack of understanding on how the C > > code is used in python (in particular the relation between original code > > and the pxd or pyx files). > > This became obvious in the according remarks you have given in debian/DRAFT. > > See also https://lists.debian.org/debian-med/2012/12/msg00112.html, it > > looks like Diane prepared a patch. > > I can confirm that I checked out Diane's repository (Diane in CC) but I > do not see any patch for dealing with the code duplication. Diane, am I > missing something? > > > Maybe I was overzealous, so if you feel like uploading, I definitely do > > not > > mind ! I am using Debian and pysam in one of my tutorials for > > transcriptome analysis > > (https://github.com/charles-plessy/tutorial/search?q=pysam&ref=cmdform). > My main goal was to get all tests working first. Once the tests are > properly working I could try to get rid of code copies and if I manage > to reproduce the tests this could be considered successful. I will keep > you updated about the progress. > > Thanks for your input > > Andreas. -- 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/2910761.drh1LTaiLj@myrada
Re: ITP: HTSeq
> 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? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4104635.aD459FiERa@myrada
Re: ITP: HTSeq
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 > ftpmaster. There is no point in documenting changes against ... nothing. > So you finally can safe some time of ftpmaster by not letting them read > useless text. That's why I'm proposing the following change: > I think dropping the current changelog in favor of of the one line Initial Packaging is a good idea. Go ahead and commit that change. Diane -- 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/6003642.UHfn1N5OzQ@myrada
Re: ITP: HTSeq
> > 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 fine with trying to upload a package to new without an > according ITP bug and by doing so find out whether what I said in this > paragraph is not true any more. I asked Scott Kitterman whose on the FTP team and he described that having the ITP is useful for them for working with NEW. I've gone ahead and submitted it, and added a Closes: #718664 to the changelog. One question is who should be on the X-Debbugs-CC list? I left the default debian-devel and added this list, was that the right choice? > > In several cases you find more than one section a package would fit > into. I'd just leave it like it is - speccifically because of the > reasoning you have given why you decided to call the package > python-htseq (and not only htseq when I asked you about the name). For > instance have python-biopython, python-csb and others in section python > - this is just fine and we are using the Debian Med tasks to do a better > categorisation. > > BTW, do you think the package fits into bio, bio-dev or even into both? I would think its more aimed at bio-dev. Diane -- 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/7664686.8UyhRBrmib@myrada
Bug#718664: ITP: htseq -- high-throughput genome sequencing analysis.
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 License: GPL-3+ Programming Lang: Python Description: HTSeq can be used for a number of common high-throughput genomics analysis tasks. . * Getting statistical summaries about the base-call quality scores to study the data quality. * Calculating a coverage vector and exporting it for visualization in a genome browser. * Reading in annotation data from a GFF file. * Assigning aligned reads from an RNA-Seq experiments to exons and genes. Remark: This package is maintained in the Debian Med team and available in VCS at: git://git.debian.org/debian-med/python-htseq.git -- 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/2311425.jqM50mftGK@myrada
Re: ITP: HTSeq
> > > 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 review first. > > +1 So I spoke a bit with #debian-devel and they suggested that there's not huge reason to file an ITP if the packaging is already done. The ITP is more to cut down on duplication of effort. > I usually append the text in a separate paragraph: > > The package is maintained in Debian Med team and prepared for upload in > Git at git://git.debian.org/git/debian-med/python-htseq.git . That however reminded me I should set Maintainer, Uploader, VCS-Git, and VCS- Browser control file metadata. (Which I did and pushed). My last question is its currently Section: python, I was wondering if it should be Section: science instead. However that might require a lintian override. Diane -- 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/2058512.xaOH5g58AQ@myrada
Re: ITP: HTSeq
Hello Andres, > So the only way to properly build is using `gbp-clone --git-ignore-new` > which is a bit nasty. The reason for this is that the clean target does > something else but restoring the original. I could imagine that the > Debian Python team might have some experience with things like this and > knows a good way to work around. IMHO git-buildpackage is terribly > picky about things like this and autobuilders (or (p)debuild) are more > tollerant. But I'd be happy if this could be solved before we do a final > upload if time permits. I git rm'ed the files that get generated by the build process and added a debian/gbp.conf file to filter them out of master next time someone does a gbp import-orig. I think the entries in debian/source/options will keep debuild's orig diff from complaining about those build-generated files as well. > > Two additional remarks: If you have *really* good contacts to upstream > you can start nitpicking and might give them a hint about the lintian > info (which you get via lintian -I) about I saw the couple of spelling errors, but as they haven't gotten back to me yet for the fixes to the setup.py, I thought I should wait before sending more patches. > The other thing is that I noticed you have implemented means to rename > original upstream version 0.5.4p3 to 0.5.4.3 per uversionmangle in > d/watch. I just want to mention that leaving the 'p' inside the version > string would be perfectly OK. There is no rule that enforces numbers > and '.' exclusively. Feel free to leave it as it is currently if you > have your reasons to do so - I just want to mention that it is not > needed and in some case it could lead to confusions. I undid the mangling, I looked at the debian policy and as long as the version number sort correctly letters are ok. > > 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 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 -- high-throughput genome sequencing analysis. Package: wnpp Severity: wishlist Owner: Diane Trout X-Debbugs-CC: debian-med@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 License: GPL-3+ Programming Lang: Python Description: HTSeq can be used for a number of common high-throughput genomics analysis tasks. . * Getting statistical summaries about the base-call quality scores to study the data quality. * Calculating a coverage vector and exporting it for visualization in a genome browser. * Reading in annotation data from a GFF file. * Assigning aligned reads from an RNA-Seq experiments to exons and genes. --[ITP]-- -- 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/6650327.03uDjOpfFS@myrada
Re: 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.org/debian-med/python-htseq.git -- 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/1519679.TJdj3qAuXO@myrada
Re: ITP: HTSeq
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. so I think the name python-htseq makes sense. * Lintian is only complaining about spelling errors and I'd like to wait to fix those by working with upstream. I replaced the previous bare-packaging git repository with the gbp style one at https://github.com/detrout/python-htseq. If that looks decent I can push to alioth. Diane On Friday, July 26, 2013 10:48:38 Andreas Tille wrote: > Hi again, > > (sorry for the full quote below but my mail below did not reached the > list for whatever reason ...) > > I had another thing to consider: The soure tarball of python-htseq > contains two scripts in scripts/ directory. If I'm not totally > misleaded these are the user interface to the Python code end should be > installed to /usr/bin ... or at least to /usr/share/doc//examples. > In the first case please use help2man to create some simple manpage > (we have examples for instance in packaging of last-align). > > Moreover if you consider these scripts as the main interface for the > package which makes it kind of a user application rather than a Python > module there is no real point in naming the package python-htseq. > Finally it does not matter for the user in what language some software > is written in and thus a simpla htseq would perfectly do. > > 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: http://lists.debian.org/3847860.rL4gihJAFj@myrada
Re: ITP: HTSeq
Hello, I tried to help debian-med with samtools a while ago. So I already have an alioth account and even already have a debian-med membership: diane-guest@wagner:/git/debian-med$ groups diane-guest debian-med pkg-kde scm_debian-med scm_pkg-kde And I've been contributing some to the KDE & Python teams over IRC. Looking at your repository guide, it looks like you prefer git-buildpackage style packages? I had one problem where upstream includes the .egg-info directory in their source release, and I had trouble resetting the build sufficiently for gbp to work because the *.egg-info/SOURCES.txt kept changing. Do you have any suggestions for getting around that? (Is there a way to tell git-import-orig to ignore the egg-info directory for instance?) Diane On Thursday, July 25, 2013 23:26:21 Andreas Tille wrote: > Hi Diane, > > many thanks for your interest 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 reasonable target for us. > > > 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? > > Yes. > > > Does the packaging look correct? > > I'm a bit tired to look right now in more detail. > > > If yes, would anyone be interested in sponsoring the package? > > Sure we will sponsor your work! However, we would really prefer if you > could use Debian Med repository as it is described in our group policy > >http://debian-med.alioth.debian.org/docs/policy.html > > If you like this idea would you consider creating an Alioth account > as described there and we could work out together the details? > > I'm really happy to see some nearly finished work done for an > interesting package. Thanks for your work on this. > > 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: http://lists.debian.org/1659180.9R2v1HP9DK@myrada
ITP: HTSeq
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 packaging look correct? If yes, would anyone be interested in sponsoring the package? Diane -- 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/1563726.IgLm8uskQR@myrada
Re: Python package review
> > 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 installed. -- 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/2469719.64tocoEGjf@myrada
Re: Flexbar source code? (Was: feature request)
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/13 14:43, Andreas Tille wrote:
> [...]
> Could you please contact the authors / those who asked you for the
> packaging to care for a versioned source code tarball besides their
> binary download files. (And yes, we could checkout from SVN but
> it is better to avoid this to safe us from extra hassle.)
Hi, Andreas.
Can we not just export a snapshot of their SVN version?
For example:
> #!/bin/bash
> # @(#)SVN 2013-01-18 A.J.Travis
>
> #
> # Checkout current SVN version and export a clean source snapshot
> #
> VERSION=$(svn info svn://svn.code.sf.net/p/flexbar/code | awk
> '/Revision/{print $2}')
>
> svn checkout svn://svn.code.sf.net/p/flexbar/code/trunk flexbar-code
> svn export svn://svn.code.sf.net/p/flexbar/code/trunk flexbar_src_v2.$VERSION
> tar jcf flexbar_src_v2.$VERSION.tgz flexbar_src_v2.$VERSION
This is how I got the sources I'm using on our Bio-Linux server in
Edinburgh.
> This would be a precondition for our packaging work and we should
> make sure that we will be able to start smoothly without spending
> time into things like this.
Well, since it's me who wants to package their software for Debian-Med
and Bio-Linux I think I should make the effort to smooth things along!
> See you in Kiel
Indeed, I'm looking forward to the meeting!
Bye,
Tony.
--
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/50f96fa4.9090...@minke.ukfsn.org
--
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/x7cqhq.mgu2yh.63smka-...@chaos.caltech.edu
Re: pysam dependencies
> > 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 question about my libtool patch which is what should the default rpath be? and what should the variable names to override it be? I'm wondering if I should go join debian-mentors as well. Diane pgpOuQhsUF1J8.pgp Description: PGP signature
Introduction.
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 submitting the high-throughput sequence. My background is in CS and not biology, most of my coding experience is in python, although I can code in C++ and C. I first started using Debian a bit before 1998. I have been using Ubuntu for the past few years. (Though I am bothered by their decision to monitize their users though in-OS advertisements). Diane pgpeUraeac1VM.pgp Description: PGP signature
pysam dependencies
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 discovered that tabix & samtools include slightly different versions of klib[2]. It looks like klib doesn't believe in don't-repeat-yourself as they don't provide a makefile and their readme encourages people to just copy klib files into their own software. Since pysam includes both of samtools and tabix it ends up with duplicates of files: bgzf.[ch], knetfile.[ch], kseq.h, ksort.h, and kstring.[ch] A quick diff between the pysam samtools and tabix directories shows bgzf.c has a different api. I'd like to avoid cleaning up the klib mess, would it be reasonable to have the header files for samtools in something like "/usr/include/bam" and tabix as "/usr/include/tabix"? Also just to check, can does the dynamic linker treat the same symbol name in two different shared libraries as different? Diane [1] http://woldlab.caltech.edu/gitweb/?p=tabix.git;a=blob;f=debian/patches/use-libtool;h=58cde517e8e4c6a1c48c5c188399642abe726b7f;hb=build-so [2] https://github.com/attractivechaos/klib pgpatwogPjDVd.pgp Description: PGP signature
Re: Help from Git-buildpackage experts wanted (Was: New upstream version of python-csb)
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 to the git repository. Diane > + > + git-buildpackage can > be set to a directory layout > + similar to the one we use with > svn-buildpackage. > + This setting should use an user-wide or > a system-wide > + gbp.conf (not the > one committed in the Git > + repository. > pgpmeQs0lb6p6.pgp Description: PGP signature
Re: Help from Git-buildpackage experts wanted (Was: New upstream version of python-csb)
> 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 not crucial at > all. > I do like the functionality provided by pristine-tar, as it is nice to help keep your package's parent directory a bit cleaner. I suspect that settings like export-dir or tarball-dir really shouldn't be in a repository. They seem specific to how you want to lay out your work directories. Diane pgp57CvXSbtKL.pgp Description: PGP signature
Re: New upstream version of python-csb
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 below you might try. > for py in python2.7 python2.6 python3.2; do \ > -$py -B setup.py clean -a; \ > done with that it should keep going even if there's nothing to clean. Diane > $ git-buildpackage > dh clean --with python2,python3 >dh_testdir >debian/rules override_dh_auto_clean > make[1]: Entering directory > `/home/tillea/debian-maintain/alioth/debian-med_git/python-csb' > set -e; \ > for py in python2.7 python2.6 python3.2; do \ > $py -B setup.py clean -a; \ > done > running clean > 'build/lib.linux-x86_64-2.7' does not exist -- can't clean it > 'build/bdist.linux-x86_64' does not exist -- can't clean it > 'build/scripts-2.7' does not exist -- can't clean it > running clean > 'build/lib.linux-x86_64-2.6' does not exist -- can't clean it > 'build/bdist.linux-x86_64' does not exist -- can't clean it > 'build/scripts-2.6' does not exist -- can't clean it > running clean > 'build/lib' does not exist -- can't clean it > 'build/bdist.linux-x86_64' does not exist -- can't clean it > 'build/scripts-3.2' does not exist -- can't clean it > make[1]: Leaving directory > `/home/tillea/debian-maintain/alioth/debian-med_git/python-csb' >dh_clean > gbp:info: Orig tarball 'python-csb_1.1.1+dfsg.orig.tar.gz' not found at > '../tarballs/' > fatal: Path 'python-csb_1.1.1+dfsg.orig.tar.gz.delta' does not exist in > 'refs/heads/pristine-tar' > pristine-tar: git show > refs/heads/pristine-tar:python-csb_1.1.1+dfsg.orig.tar.gz.delta failed > gbp:error: Couldn't checkout "python-csb_1.1.1+dfsg.orig.tar.gz": > /usr/bin/pristine-tar returned 128 > > > When I try to build the package. (I'm using pristine-tar version 1.26 - > just in case because I have learned that with older pristine-tar versions > there could be some problems when imported with the latest version.) > > Kind regards > >Andreas. > > > [1] http://debian-med.alioth.debian.org/docs/policy.html#git-tips > > -- > http://fam-tille.de > > > -- > 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/20121220104321.ga11...@an3as.eu > pgpXoslKC9gzW.pgp Description: PGP signature
Re: pysam package
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 be a reasonable solution to the pysam code copying problem? Methods: I only tried changing pysam to link to my samtools shared library, I didn't bother trying to fix the wholesale import of tabix. (I was curious if the shared object strategy would work). To make it work I needed add the following object files to the libbam so. bam_plcmd.o sam_view.o bam_rmdup.o bam_rmdupse.o bam_mate.o bam_stat.o bam2bcf.o bam2bcf_indel.o errmod.o sample.o cut_target.o phase.o bam2depth.o bcftools/bcf.o bcftools/bcfutils.o bcftools/fet.o quilt patch file: http://woldlab.caltech.edu/gitweb/?p=samtools.git;a=blob;f=debian/patches/phase-in-so;h=64f44beebe4120c2c2c6ae792442a75d5bb256b3;hb=woldlab On the pysam side I told it to use my include/bam and library and pulled out the wholesale importing of samptools/*.pysam.c It ran well enough to run the tests, though there may still be some undefined symbols, as I didn't add all the *.o's that the pysam setup.py was using. --- setup.orig.py 2012-12-19 12:27:21.019867664 -0800 +++ setup.py2012-12-19 15:20:29.191500964 -0800 @@ -138,22 +138,20 @@ if platform.system()=='Windows': include_os = ['win32'] os_c_files = ['win32/getopt.c'] else: -include_os = [] +include_os = ['/usr/include/bam'] os_c_files = [] samtools = Extension( "csamtools", # name of extension [ "pysam/csamtools.pyx" ] +\ [ "pysam/%s" % x for x in ( "pysam_util.c", )] +\ -glob.glob( os.path.join( "samtools", "*.pysam.c" )) +\ -os_c_files + \ -glob.glob( os.path.join( "samtools", "*", "*.pysam.c" ) ), +os_c_files , library_dirs=[], -include_dirs=[ "samtools", "pysam" ] + include_os, -libraries=[ "z", ], +include_dirs=["pysam" ] + include_os, +libraries=[ "z", "bam"], language="c", Diane pgp5Oo9p94QZ8.pgp Description: PGP signature
Re: pysam package
I haven't been running pysam's tests, I just noticed while updating to 0.7 that there was a tests directory, and thought I should figure out how to run those. Actually since you mentioned samtools. We've made a couple of modifications to the samtools package. My coworker Henry Amrhein had a patch to return an error message instead of crashing when razip ran out of memory. Also I modified the samtools build scripts to build libbam as a shared library. http://woldlab.caltech.edu/gitweb/?p=samtools.git;a=tree;f=debian/patches;h=3d1ac7a0ee286d21f92316c5c5b8a2302fa3b22a;hb=woldlab Fixing the oom segfault is at that git-repository in 'razip-oom-check'. The modifications to the makefile were build-so. Along with corresponding debian package changes for the extra .deb. Though I'm probably not understanding how to name shared libraries properly as there was an error message about the soname. Also the realization that I had a shared library for samtools, and the packaging team wanted a pysam without the embedded samtools source led me to try something I'll talk about in my next email. Diane On Wed, Dec 19, 2012 at 12:25:18PM -0500, Dominique Belhachemi wrote: > Hi Diane, > > Running pysam tests during buildtime would be very helpful. I just run the > tests manually and stumbled upon a bug in samtools. > ( http://code.google.com/p/pysam/issues/detail?id=71 ) I wonder why this > hasn't been fixed upstream, anyway, I am going to patch Debian's samtools > package with the proposed fix. > > You can find Debian's pysam package here: > >http://anonscm.debian.org/gitweb/?p=debian-med/pysam.git > > Howe are you running the tests right now? Is there a way to specify a > 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 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 could be making. (For instance I need to > > figure out how to run pysam's tests in debian/rules.) > > > > Would it be worthwhile to work toward making an official package? (And if > > so a pointer for what to do next would be appreciated). > > > > Diane > > > > [1] https://code.google.com/p/pysam/ > > [2] http://woldlab.caltech.edu/gitweb/?p=pysam.git;a=summary > > pgpbotOdJ2ElQ.pgp Description: PGP signature
pysam package
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 could be making. (For instance I need to figure out how to run pysam's tests in debian/rules.) Would it be worthwhile to work toward making an official package? (And if so a pointer for what to do next would be appreciated). Diane [1] https://code.google.com/p/pysam/ [2] http://woldlab.caltech.edu/gitweb/?p=pysam.git;a=summary pgpJyNzw3xHsk.pgp Description: PGP signature
