Hello,
With help from upstream we've got versions of llvmlite and numba that
build with dependencies currently in Debian.
Numba built and passed tests for amd64 and arm64. It build but the
build time tests failed for mips64el, ppc64el, and s390x. Numba
couldn't build on armel, armhf, i386, and r
On Wed, 2025-04-09 at 21:00 -0400, M. Zhou wrote:
> Hi Diane,
>
> Thank you for working on this.
>
> Do you have LLVM team write access? If so please help your self and
> directly push the commits there. If not, please open a merge request
> and I'll process it quickly.
>
I don't have llvm team
On Wed, 2025-04-09 at 20:58 -0400, Nicholas D Steeves wrote:
Hello,
>
> Has a bug been filed against llvmlite? If not, shouldn't there be
> one?
So it's not clear if there is a bug here.
The problem is the llvmlite upstream is currently release is targeting
llvm-15, which debian removed for b
Hi,
I have a version of llvmlite that builds against llvm-19 with 2 test
failures that don't look to important. One of them is definitely just
the layout of the object file changed from what was expected.
I got most of the help in the comments in here:
https://github.com/numba/llvmlite/pull/1092
On Tue, 2025-03-18 at 14:08 +0100, PICCA Frederic-Emmanuel wrote:
> >
>
> some news ?
>
> friendly ping :))
I was waiting to see if I could get some advice from upstream.
I added a bit more to the upstream bug about what's different between
llvm 15 and 19 for one of the failing test.
https:/
On Tue, 2025-02-18 at 13:41 -0500, M. Zhou wrote:
> On Tue, 2025-02-18 at 09:50 -0800, Diane Trout wrote:
> >
> > Do you have any ideas of what could be done to help get a version
> > of
> > llvmlite that works with numba into Debian?
>
> No idea. I'm keep
Hello,
llvmlite barely managed to be updated to llvm-15, and then llvm-15 was
removed from Debian.
There's a bit of work on llvmlite to support llvm19
https://github.com/numba/llvmlite/pull/1092
but it looks like it doesn't work yet.
Unfortunately for a number of python tools, numba can't be ins
On Fri, 2024-06-14 at 23:16 +0200, Étienne Mollier wrote:
> Hi Diane, Hi Julian
>
> I'm wrapping up that email as it seems to me there could be some
> activity on the dask package from several people at once.
Yeah I saw that and decided I was overloaded and stopped doing
anything.
Historically
Hi Julian,
On Sat, 2024-03-30 at 20:22 +, Julian Gilbey wrote:
> Lovely to hear from you, and oh wow, that's amazing, thank you!
>
> I can't speak for anyone else, but I suggest that pushing your
> updates
> to the science-team package would be very sensible; it would be silly
> for someone e
On Mon, 2024-03-25 at 18:17 +, Julian Gilbey wrote:
>
>
> So this is a plea for anyone looking for something really helpful to
> do: it would be great to have a group of developers finally package
> this! There was some initial work done (see the RFP bug report for
> details: https://bugs.de
> >
>
> Thanks so much! I see you've already started on dask :)
>
> I took at quick look at arrow - yikes! There is potentially work
> afoot on this though:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021
>
Dask & dask.distributed 2023.8.0 was easier to update than some of the
oth
On Fri, 2023-02-24 at 19:33 +0100, Paul Gevers wrote:
> Hi Diane,
>
> On 23-02-2023 08:12, Diane Trout wrote:
> > the version of python3-xlrd 1.2.0-3 in unstable/testing is too old
> > to
> > be used with pandas 1.5.3. (See Bug #1031701).
>
> Do I understand c
Hi,
the version of python3-xlrd 1.2.0-3 in unstable/testing is too old to
be used with pandas 1.5.3. (See Bug #1031701). As it is a really common
workflow to use pandas to read excel files, it'd be nice if the version
of xlrd in bookworm was compatible.
Because of the freeze I wanted to check if
On Mon, 2023-02-06 at 21:39 +, Rebecca N. Palmer wrote:
> I agree that xfailing the tests *may* be a reasonable solution. I'm
> only saying that it should be done by someone with more idea than me
> of
> whether these particular tests are important, because blindly
> xfailing
> everything t
On Mon, 2023-02-06 at 11:13 +0100, Andreas Tille wrote:
> Hi Rebecca,
>
> Am Mon, Feb 06, 2023 at 07:59:17AM + schrieb Rebecca N. Palmer:
> > (Background: the pandas + dask transition broke dask.distributed
> > and it was
> > hence removed from testing; I didn't notice at the time that if we
>
Package: wnpp
Owner: Diane Trout
Severity: wishlist
* Package name: python3-sphinx-autosummary-accessors
Version : 2022.4.0-1
Upstream Author : Justus Magin
* URL or Web page :
https://github.com/xarray-contrib/sphinx-autosummary-accessors
* License : MIT
Description
On Wed, 2021-02-10 at 18:35 -0500, Sandro Tosi wrote:
> +Steffen explicitly, given the team is not in Maintainer nor
> Uploaders
>
> > How about renaming the current python3-louvain package to
> > python3-community-louvain using a normal transition package.
>
> that's incorrect: src:python-louvai
>
> In the short term I recommend fixing this by adding a file to the
> Debian python-louvain package named "debian/tests/autopkgtest-pkg-
> python.conf" with the contents "import_name = community"
>
How about renaming the current python3-louvain package to
python3-community-louvain using a nor
On Wed, 2021-02-10 at 10:29 +0100, Michael R. Crusoe wrote:
>
> In the short term I recommend fixing this by adding a file to the
> Debian python-louvain package named "debian/tests/autopkgtest-pkg-
> python.conf" with the contents "import_name = community"
>
Thank you!
I had a hunch there was
On Wed, 2021-02-10 at 01:49 +, Paul Wise wrote:
> On Tue, Feb 9, 2021 at 10:21 PM Diane Trout wrote:
>
> > The fairly popular (in the world of bioinformatics) ScanPy package
> > uses
> > a Python version of the louvain clustering algorithm implemented
> > by:
Hello,
The fairly popular (in the world of bioinformatics) ScanPy package uses
a Python version of the louvain clustering algorithm implemented by:
https://github.com/vtraag/louvain-igraph
https://pypi.org/project/louvain/
which installs into the "louvain" dist-packages directory.
(from debc)
./
Hello,
On Fri, 2021-01-22 at 14:06 -0300, Antonio Terceiro wrote:
> Does anybody have an insight on cases like this? Are there any
> details
> that I'm missing?
I occasionally have tests behave differently between the buildd and
autopkgtest runner.
Things that I have encountered.
The pybuild te
,
and med teams)
I was guessing the most likely path would be to make an experimental
release of numba 0.52.0 with the compatibility patch and then see how
pandas, astro team packages do with it.
But it's a complicated package capable of strange side effects and I
thought we should talk it over first
On Thu, 2020-03-19 at 15:22 +0900, Sao I Kuan wrote:
> Hi,
>
> I'm newcomer to Debian packaging, and trying to add the autopkgtest
> test script into python-tinyalign[1].
>
> [1] https://salsa.debian.org/med-team/python-tinyalign
>
> And now I'm facing a (maybe simple) problem.
>
> The upst
On Tue, 2019-09-17 at 22:46 +0100, Rebecca N. Palmer wrote:
> grep-dctrl -w -F Depends,Recommends -s Source "python-$module"
> /var/lib/apt/lists/*_debian_dists_sid_main_binary-amd64_Packages ;
> grep-dctrl -w -s Package "python-$module"
> /var/lib/apt/lists/*_debian_dists_sid_main_source_Sou
On Thu, 2019-09-05 at 20:14 +0200, Matthias Klose wrote:
>
> you are asking about the least preferred option, without telling why
> you can't
> convert to python3, or why you can't remove the affected
> packages. If you have
> both spyder and spyder3 (Python3?), then why not drop spyder? I
> d
Hi,
The py2removal bug says to discuss the py2keep tag first.
src:cloudpickle is a dependency of src:spyder and src:skimage.
python-skimage has a popcon inst score of 469
spyder has a popcon inst score of 1385
spyder3 has a popcon inst score of 1069
The removal bug says the popcon threshold for
Hi,
Reading about all this talk about removing leaf python2 packages left
me wondering.
Could we change py2dsc's default python interpreter to python3?
And that led me to check tracker there's 15 open bugs, and the last
release was in 2015
Does anyone else use py2dsc?
I was wondering if I sho
> But the other files... it's about changing the exporters and
> templates
> during document generation ; and the resulting files might then get
> used
> on non-Debian systems. In short : if I tamper with them to use
> Debian
> local packages, that basically means nbconvert in Debian will
> pro
> I think the general rule-of-thumb is to wait around 2 weeks for a
> reply.
> However, this package is team-maintained, so I would get in touch
> with
> the team first and ask them to sponsor the upload. This way, you
> won't
> need to wait that much and can do a team upload.
>
Ah good idea.
Hi,
I was trying to do something with home-assistant and needed a Python 3
version of pybluez.
Unfortunately I found this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839100
python-bluez: debian pybluez package version 0.22-1 uses upstream
source code version 0.18
Which also blocks #78
On Fri, 2018-06-08 at 10:05 +0800, Paul Wise wrote:
> On Fri, Jun 8, 2018 at 5:59 AM, Diane Trout wrote:
>
> > How do I replace the .orig.tar.gz that I already uploaded?
>
> You will need a new upstream version, typically people use
> 0.1.2+dfsg1
> (for DFSG issues)
> > I would suggest talking to upstream about fixing this properly (no
> > prebuilt files or embedded code copies in the VCS and tarballs).
>
> And in the meantime repacking the existing tarball to remove the
> sourceless files.
>
I was suspecting that was going to be the answer...
How do I re
Hi,
I discovered a mistake I made with packaging dask.
There's two static html files which embed some bokeh generated
javascript plot code that's in dask 0.17.5 and I uploaded that to the
Debian.
There doesn't appear to be source to build the files.
Bokeh is free software (BSD-3-Clause), but de
Package: src:python3-stdlib-extensions
Version: 3.6.4-4
Severity: serious
X-Debbugs-CC: debian-python@lists.debian.org
Hello,
python3-distutils is currently unavailable in unstable, it appears that
python3-stdlib-extensions was intended to provided it, but the all
architecture package is failing
Hi,
I was trying to rebuild dask, and discovered that several dependencies
aren't installable because python3-distutils appears to have been
merged into python3-stdlib-extensions.
For example in an unstable chroot
python3-sphinx : Depends: python3-lib2to3 but it is not installable
> > I wasn't sure this should go into Debian python modules, or Debian
> > python applications?
>
> Since it has a public module, DPMT is a better bet.
>
Ok, thank you.
Also that also has the advantage that I already have permissions to
create repositories in DPMT
Diane
signature.asc
Descrip
Hi,
I'd packaged a hangouts client called hangups for myself a while ago,
and I thought I'd upload it to Debian.
https://hangups.readthedocs.io/en/latest/
I built the package so most of the python code is in a python3-hangups
module but the executable is in its own package.
(one could use the A
Can you trigger test on dependencies changing?
Does CI run on architectures other than amd64?
(I was thinking of complex packages with many dependencies like dask,
or with fiddly bit manipulation like pandas)
So this would get tests on each commit instead of the current
autopkgtests which run on
Hi,
I was looking for copyrighted files and found
jupyter-notebook/docs/sphinxext/ which lists an "All rights reserved"
copyright.
Adapted from bitbucket example here:
https://bitbucket.org/birkenfeld/sphinx-contrib/src/tip/bitbucket/sphin
xcontrib/bitbucket.py
"""
#
# Original Copyright (c) 20
Could you update the timestamp on jupyter-console as well?
That one also has a time-warp-standards
Thanks,
Diane
signature.asc
Description: This is a digitally signed message part
Hi,
I just reviewed ipython from git.
I found a file was added that had a different copyright from the rest
of ipython. I went ahead and updated d/copyright & d/changelog and
pushed that change to git.
Do you want to update d/changelog with "unstable" and todays date? (or
I cloud prepare a team
On Wed, 2017-10-25 at 22:15 +0200, Gordon Ball wrote:
>
> I would normally not update the timestamp while the suite is
> UNRELEASED,
> and expect whoever ultimately makes the upload to `dch -r` and tag
> the
> release, but maybe it would be less ambiguous to update it each time
> d/changelog gets
> I have just uploaded the current RFS packages (ipython,
> jupyter-notebook, jupyter-console, nbconvert) to mentors.d.n
I just reviewed nbconvert
I got one lintian warning
nbconvert source: timewarp-standards-version (2017-09-03 < 2017-09-27)
The source package refers to a Standards-Version
On Fri, 2017-10-13 at 08:41 +0100, Simon McVittie wrote:
> On Fri, 13 Oct 2017 at 08:13:08 +0800, Paul Wise wrote:
> > On Fri, Oct 13, 2017 at 3:27 AM, Diane Trout wrote:
> >
> > > Being able to find all your documentation in one place would
> > > really be
&
On Thu, 2017-10-12 at 20:10 +1100, Stuart Prescott wrote:
> BTW when doc-central was first orphaned, there was a little
> discussion about
> bringing it under the debian-doc umbrella (but there is no reason not
> to use
That does seem reasonable. I joined the -doc list and emailed them
> d-pyth
Hi,
I wanted to be able to browse documentation locally, and the Python
viewer doc-central is abandoned.
What I have so far is a Python 3 version using CGI scripts. What I'd
like is something uses wsgi and can run with Python's built-in wsgiref
server instead of requiring a full web server. (mayb
Hi,
It's pretty difficult to run just one pandas unittest.
I managed to extract a couple examples from the build logs and
replicate the failures on a arm64 porterbox.
Debian Bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877754
Forwarded to https://github.com/pandas-dev/pandas/issues/1
On Wed, 2017-10-04 at 22:47 +0100, Simon McVittie wrote:
> On Wed, 04 Oct 2017 at 14:11:02 -0700, Diane Trout wrote:
> > I do wish that these third party app systems like conda, snappy or
> > flatpak would include metadata like AppStream or DOAP.
>
> Flatpak already does
> > who says that a "lagging behind" package doesn't have any security
> > issues? If
> > the package is lagging behind, how do you know that security
> > updates aren't
> > lagging behind either...
>
> As this is Debian, I do expect that at least, I can read the security
> tracker to see the cur
On Sat, 2017-09-30 at 12:26 +0300, Dmitry Shachnev wrote:
>
>
> > I wonder if it's better to filter sphinxdoc out of the dh line,
> > install
> > sphinx-common, or just always install python3-sphinx?
>
> Adding sphinx-common to B-D and keeping python3-sphinx in B-D-Indep
> is
> probably the easi
On Fri, 2017-09-29 at 22:05 +0100, Rebecca N. Palmer wrote:
> statsmodels passed NEW...and FTBFS with
>
> dh: unable to load addon sphinxdoc: Can't locate
> Debian/Debhelper/Sequence/sphinxdoc.pm in @INC
> That file is in the sphinx-common package, which suggests that at
> least
> some of the sp
On Wed, 2017-09-27 at 08:34 +0200, Andreas Tille wrote:
>
> >
> > https://ghic.org/~diane/debian/statsmodels.datasets.README.txt
>
> I think regarding formatting and context its perfectly fine.
>
> > Does it go in README.source? or in upstream/metadata? or something
> > else?
>
> I think ther
> Since it is accepted for the R packages and the data are refering
> to R data I do not see any reason why this should not be accepted.
I traced back from Rdatasets to the original R packages.
Every one of the packages are licensed as some combination of GPL-2 and
GPL-3
However it's likely tha
> While I have not tried to build the current status I wonder what you
> think about #873512. I'm perfectly fine with your solution to
> exclude
> some tests - I just wanted to give a hint that there is a potential
> upstream patch.
I think I looked at the upstream commits that fixed it,
https:
> > Below is what I've found so far, (before getting tired of licensing
> > issues)
> >
> > Any thoughts about how to handle this?
>
> I wonder how this was dealt with before? If that much data sets were
> needed to build the docs, how did the doc generation process worked
> before?
Perhaps th
On Mon, 2017-09-25 at 09:44 +0200, Andreas Tille wrote:
> Hi Diane,
>
> On Sun, Sep 24, 2017 at 11:45:43PM -0700, Diane Trout wrote:
> > The remaining issues are:
> >
> > * Some of the doc pages call get_rdataset, and there's no network
> > access in the
On Mon, 2017-09-25 at 09:44 +0200, Andreas Tille wrote:
>
> > * Some of the doc pages call get_rdataset, and there's no network
> > access in the builder so those calls fail. (ugliest error)
>
> Can you pre-fetch the data and provide it in debian/datasets?
Looks like it'll take a bit of patching
On Sun, 2017-09-24 at 11:24 -0700, Diane Trout wrote:
> Status with statsmodels almost done
>
> Trying to deal with jquery.
>
> leaving command
>
> -rm ./build/html/_static/jquery.js
>
> causes a build failure now.
> leaving it in causes a lintain privacy
2017 at 11:24:10AM -0700, Diane Trout wrote:
>> > Status with statsmodels almost done
>
>> > Trying to deal with jquery.
>
>> > leaving command
>
>> >-rm ./build/html/_static/jquery.js
>
>> > causes a build failure now.
>
>&
Status with statsmodels almost done
Trying to deal with jquery.
leaving command
-rm ./build/html/_static/jquery.js
causes a build failure now.
leaving it in causes a lintain privacy error.
there's also lintain warnings about a missing hardening flag, and no
doc-base registration.
At s
Hi,
I was updating the intersphinx inventory files for statsmodels and one
was a link to:
'pydagogue' : ('http://matthew-brett.github.io/pydagogue/', None),
Source: https://github.com/matthew-brett/pydagogue
In theory we could have a documentation only package which would let
whatever statsmodel
On Thu, 2017-09-14 at 18:35 -0300, drebs wrote:
> Hi, I am interested in updating the subliminal[2] package[1]. Is
> there
> someone else already working on that? If not, what would be the
> process
> for having it uploaded? (i am not a dm or dd) Should i send the
> source
> package to this list? W
On Fri, 2017-09-22 at 10:57 +0200, Piotr Ożarowski wrote:
> [Diane Trout, 2017-09-21]
> > I made larger changes to statsmodels, by using pybuild instead of
> > the
> > previous multiple targets in debian/rules.
>
> you can simplify it even further by using pybuild&#x
I managed to merge the more important doc changes.
I have a patch to switch doc building to using Python 3 components, as
there's a goal of removing the Python 2 components at some point.
The there's the patch for the nodoc/nocheck build profile, as well as
adding a bunch of other dependencies fo
On Thu, 2017-09-21 at 17:56 -0400, Yaroslav Halchenko wrote:
> If you could allow to review would be great.
> Thanks for all the work.
> I was btw also trying to build with the patch you shared yesterday
Once I have all the changes for pandas would you like me to put them on
a branch on alioth? Or
> If my poor opinion counts: For the moment we should run those tests
> in
> the build process than can be easily be run. Everything else should
> probably be sorted out later (in autopkgtest or another later upload
> if
> somebody has a clue how we can solve the circular depenendecies).
>
> We
> the biggest downside with this approach is that you *completely* skip
> any
> testing on other architectures than amd64. Is that what you really
> want? Dear
> porters, have fun where to search for bugs in packages without
> testsuites!
Ok you convinced me. dh_auto_tests stay.
Is there anythi
> On Saturday, 16 September 2017 14:18:10 AEST Diane Trout wrote:
> > My solution was to use build-profiles to flag the test dependency
> > with
> > !nocheck
>
> this is, of course, a very elegant solution and exactly what build
> profiles
> are for...
&
On Sat, 2017-09-16 at 22:59 +0200, Yuri D'Elia wrote:
> On Sat, Sep 16 2017, Diane Trout wrote:
> > python3-pandas: Pandas is not installable
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875723
>
> I would have expected the rebuild of python packages affected
Hi,
Just wanted to give a progress report
I was able to build a python 3 version of statsmodels, however I wasn't
able to build it against the version of pandas in sid because pandas
can't be installed.
python3-pandas: Pandas is not installable
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=8
Hi
I pushed my work to alioth on the branch detrout-python3
I modified the statsmodels build recipe to at least partially use
pybuild, and the documentation build uses python 3 components instead
of python 2.
I skipped the 4 tests that failed for me, that had an upstream bug
report, when a new v
On Thu, 2017-09-07 at 06:20 +0200, Andreas Tille wrote:
> Hi Diane,
>
> On Wed, Sep 06, 2017 at 02:45:14PM -0700, Diane Trout wrote:
> >
> > > but the build failed (for other reasons). I'd willing to work on
> > > this
> > > but I definitel
> but the build failed (for other reasons). I'd willing to work on
> this
> but I definitely need help since I'm lacking the needed Python
> knowledge.
Hi,
I saw your debian-python3 branch for statsmodels.
The dependencies added in the package should probably be added as
build-dependencies. an
I just wanted to say thank you for all you've done for Debian & Python.
Diane
signature.asc
Description: This is a digitally signed message part
On Mon, 2017-08-14 at 19:22 -0400, Nicholas D Steeves wrote:
> Package: wnpp
> Severity: wishlist
>
> * Package name: importmagic
> Version : 0.1.7
> Upstream Author : Alec Thomas
> * URL : https://github.com/alecthomas/importmagic
> * License : BSD-2-Clause
>
On Tue, 2017-08-08 at 13:24 +1000, Ben Finney wrote:
>
> Those people, not party ot this conversation, have reasonable
> expectation that such breakage will not happen without very good
> reason.
> Good reason would entail, as an example, that there is no better
> alternative.
>
Why not ask?
I
> What I am opposing is the suggestion to install, in the near to
> medium
> term, a command of exactly the same name that has subtly similar but
> incompatible behaviour, when that behaviour *already* has a command –
> ‘python3’ – that is widely used by those who need it.
>
my problem with that
> What tearing need is there to change what the command ‘python’ does,
> in
> a backward-incompatible way?
Personally, I'm ready for python to point to python3 now.
I'm tired of writing python 2/3 compatible code because someone _might_
launch a script with "python my_python3_script.py instead o
> I disagree, it's a bad idea to actively take steps to make the same
> command invoke *incompatible* programs depending on the time and
> host.
My suggestion was "the startup banner should print what command to run
to get Python 2."
I was thinking of the case of the end-user trying to follow a
>
> Why would you need to repack a tarball just because it contains
> prebuilt docs (non-DFSG-free licensed documentation aside)? I'm all
I've occasionally repacked a tarball because upstream included minified
jquery or mathjax.
Diane
signature.asc
Description: This is a digitally signed messa
> * Plan for a date at which /usr/bin/python will point to Python 3. I
> know that’s the most controversial bit, but I do think that as time
> goes on and we’re past 2020, it will be the choice that gives our
> users the best experience.
I agree the default should change.
Perhaps when launching
On Saturday, September 05, 2015 09:28:48 Diane Trout wrote:
> > > The most proper packaging would require grunt to be able to rebuild
> > > bokeh.js. I was wondering if releasing the pypi version would be good
> > > enough. (The package does at least contain
> > The most proper packaging would require grunt to be able to rebuild
> > bokeh.js. I was wondering if releasing the pypi version would be good
> > enough. (The package does at least contain a non-minimized version of
> > bokeh.js)
> I'm not sure about this, but it looks like the Bokeh source is
Hi,
I've made some limited progress trying to package Bokeh (BSD-3-Clause)
upstream: http://bokeh.pydata.org/en/latest/
my packaging: https://github.com/detrout/python-bokeh
I managed to get the version 0.9.1 from pypi installable. (Though since it was
my own experiments I didn't remove the jqu
> > I'm pretty sure a recompile will fix it, the question I have is how often
> > does numpy break binary compatibility?
> >
> > Should set your numpy dependencies to something like:
> >
> > python-numpy (>= 1.8, < 1.9)
>
> do not "hard code" -- add calls to dh_numpy (dh_numpy3) to your
> rules
Hi,
I have a small package the depends on numpy and it recently stopped working.
> Traceback (most recent call last):
> File "/usr/local/lib/R/site-
library/DEXSeq/python_scripts/dexseq_prepare_annotation.py",
> line 33, in
> import HTSeq
> File "/usr/lib/python2.7/dist-packages/HTSeq/__
> Instead, I mean, what would it take for the basic Debian system to install
> Python 3 only by default, and have any system scripts that depend on Python
> be Python 3.
Nothing.
I just did a default no-tasks selected debian wheezy system and no version of
python was installed.
Using a cowbui
So there is a list of things that need doing for ipython.
I'd built my own not-redistributable version of 1.1.0, (progress at
https://github.com/detrout/debian-ipython)
I'll see if I can help with some of the work listed below.
Diane
On Thursday, October 03, 2013 22:29:41 Jean-Christophe Jas
Hi,
I wanted to help maintain python-lightblue which was currently up for
adoption. I also submitted python-htseq a little while ago through the debian-
med team.
My day job is as a python programmer/systems administrator at a university,
I'm pretty sure I will find more things that need updati
90 matches
Mail list logo
