* 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: #19009)
-- Dirk Eddelbuettel [EMAIL PROTECTED] Sat, 10 Nov 2001 20:18:38 -0600
Thanks, Dirk
--
Better to have
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,
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 have perused
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-dev?
Quite
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
I see. But why not simply Depends: python (= 1.5)
I think this is wrong
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 [EMAIL
(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 against python-all
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.
|
|Can you help
, 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
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 wrote:
|
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:
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
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.
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
15 matches
Mail list logo
