Hi Emmanuel, (and also Hi! to Julian whom I owe a follow-up too),
On 25 February 2025 at 13:55, Emmanuel Arias wrote:
| On Tue, Feb 18, 2025 at 03:37:37PM -0600, Dirk Eddelbuettel wrote:
| > I may have been unclear in what I was looking for. If I read this
correctly,
| > then it "
Hi Emanuel,
Thanks for the prompt reply!
On 18 February 2025 at 18:18, Emmanuel Arias wrote:
| Hi!
| On Tue, Feb 18, 2025 at 01:54:19PM -0600, Dirk Eddelbuettel wrote:
| >
| > Hi all,
| >
| > I have long maintained rpy2 (and rpy before) which provides a bridge from
| > Pytho
Hi all,
I have long maintained rpy2 (and rpy before) which provides a bridge from
Python to R (which I tend to care more for), and am on friendly terms with
its author. You can see my repo at salsa [1], it is pretty vanilla.
The upcoming upstream release will split into three packages, all in t
Julian,
Arrow is a complicated and large package. We use it at work (where there is a
fair amount of Python, also to Conda etc) and do have issues with more
complex builds especially because it is 'data infrastructure' and can come in
from different parts. I would recommend against packaging at
I have now orphaned the package [1] as this one needs more attention that I
can currently give it due to 180+ other packages I have, and other work and
open source commitments.
Dirk
[1] https://bugs.debian.org/1010953
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Hi all,
I look after the 'tiledb' (a C++ library) package and the 'tiledb-r' package.
I also effectively maintain 'tiledb-python' but I am running into some issues
there. I do know a little bit of Python and have (co-)maintained two or
three packages there for decades but this one stumps me.
L
On 18 February 2022 at 21:41, Nilesh Patra wrote:
| On 2/18/22 9:33 PM, Dirk Eddelbuettel wrote:
| >
| > Hi debian-python,
| > [...]
| > I cannot write to https://salsa.debian.org/python-team/packages/tiledb-py so
| > I created a (temporary ?) copy at https://salsa.debian.or
Hi debian-python,
Recently I had packaged tiledb for Debian, based on earlier work by Adam
(CC'ed), and we now followed up with tiledb-py which I just sent to NEW
following up on an older ITP/WNPP from almost two years ago.
(TileDB is a 'universal' data storage engine: https://github.com/TileDB
p -ri Python
inst/doc/tutorial.sgml:bindings for many other languages including C, C++,
Guile, Perl, Python,
edd@rob:~/deb/rgtk2(master)$
Dirk
| On 8/4/20 2:49 PM, Dirk Eddelbuettel wrote:
| >
| > Hi doko and Python folks,
| >
| > On 4 August 2020 at 09:29, Matthias Klose wro
, python2-dev,
| python2-dbg, python2-doc).
|
| Please check for dependencies, build dependencies AND autopkg tests.
I am lost.
Build-Depends:
Source: rgtk2
Section: gnu-r
Priority: optional
Maintainer: Dirk Eddelbuettel
Build-Depends: debhelper (>= 10), dh-r (>= 20180615), r-ba
On 14 November 2009 at 12:57, Kumar Appaiah wrote:
| On Sat, Nov 14, 2009 at 11:25:02AM -0600, Dirk Eddelbuettel wrote:
| > I am swamped.
| >
| > I will not be able to get it soon.
| >
| > You guys have working 'experimental' pbuilders.
| >
| >
(Resending with _corrected_ 7-bit mail headers)
On 14 November 2009 at 17:48, Bernd Zeimetz wrote:
| Dirk Eddelbuettel wrote:
|
| > | Starting from Python 2.6, the installation paths for distutils have
| > | changed. /usr/local is now used by default.
| > |
| > | When rebuilt agains
On 13 November 2009 at 22:54, Piotr Ożarowski wrote:
| Package: nwsclient
| Version: 1.6.4-1
| Severity: important
| User: debian-python@lists.debian.org
| Usertags: python2.6 usr-local
|
| Hi,
|
| Starting from Python 2.6, the installation paths for distutils have
| changed. /usr/local is now us
go back into my cave
and continue coding in Perl as a punishment?
CCs encouraged as I am not a debian-python subscriber.
Cheers, and thanks in advance for any hints, Dirk
#!/bin/sh
#
# prerinst script for the Debian GNU/Linux python-rpy package
#
# Copyright 2006 by Dirk Eddelbuettel <[EM
> On Thu, Sep 05, 2002 at 07:48:38AM -0500, Dirk Eddelbuettel wrote:
> >
> >
> > > You should depend on exactly the Python versions you support, not on
> > > "python". For example
> > > Depends: python1.5 | python2.1 | python2.2
> >
> You should depend on exactly the Python versions you support, not on
> "python". For example
> Depends: python1.5 | python2.1 | python2.2
I see. But why not simply "Depends: python (>= 1.5)"
> And if you dont compile any Python packages, why do you still have to
> build-depend on python-de
ly on python-dev
-- Dirk Eddelbuettel <[EMAIL PROTECTED]> Thu, 5 Sep 2002 06:41:10 -0500
Is that ok with you Python Meisters? Wajig will only ever ship interpreted
Python files and does run with all recent Python versions.
Lintian and Linda are fine with it, but these robots might not h
madison and buildd.debian.org show that my quantlib-python package builds
only on a few architectures (i386, powerpc, s390, sparc) and fails on others
that could be expected to build (alpha, m68k, ...).
This is C++ code, and a lot of it. I would like to try less optimisation as
per the default,
"Matthias" == Matthias Klose <[EMAIL PROTECTED]> writes:
>> * Adapted Python Policy (as of version 0.3.7) * debian/control: Depends
>> python (>= 2.1), python (<< 2.2) (Closes: #118916) * debian/control:
>> Added Build-Depends on python
restrictive for this case.
My current changelog draft is:
wajig (0.2.8-2) unstable; urgency=low
* Adapted Python Policy (as of version 0.3.7)
* debian/control: Depends python (>= 2.1), python (<< 2.2) (Closes: #118916)
* debian/control: Added Build-Depends on python2.1-dev (Closes
20 matches
Mail list logo
