Hi all,
I've been using numpy without problems - version .1.4.1-5 - until this
morning, when I upgraded my Debian sid system to numpy 1.5.1-2. A
function that was working that uses np.power
def get_far_field(self, chi, n):
return np.sum(self.an[n,1:self.j] * np.power(chi,-np.arange(1,self.
On Fri, 2022-04-01 at 02:32 +0100, Wookey wrote:
>
> RuntimeError: Cannot find the files.
> List of candidates:
> /home/wookey/bin/libtvm.so
> /usr/local/bin/libtvm.so
> /usr/bin/libtvm.so
> /bin/libtvm.so
> /usr/local/games/libtvm.so
> /usr/games/libtvm.so
> /usr/lib/python3/dist-packages/tvm/lib
There is not yet an accurate estimate of time required to fix the
python packages during the transition -- and I still remember the
transition from python3.9 -> python3.10 took a very long period
that does not seem short enough to be covered by the freeze schedule.
Apart from that, package maintai
I'm the regular uploader of python3-llvmlite.
Please give up with numba. Its core dependency llvmlite is not even
ready for llvm != 11, while Sid had already get llvm-11 removed.
I have tried to cherry-pick an upstream fix to bump llvmlite's
llvm dependency to 12/14, but the autopkgtest shows numb
It seems I was a little bit out of date. Diane Trout has tried
with an unreleased snapshot which looks good with llvm-14
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024795
Will work on it soon.
On Thu, 2022-12-22 at 18:04 -0500, M. Zhou wrote:
> I'm the regular uploader of python3-
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 keeping an eye on upstream release but the only option
I can see to make it work is to depend on the LLVM versi
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.
On Tue, 2025-04-08 at 22:59 -0700, Diane Trout wrote:
> Hi,
>
> I have a version of llvm
bother with this one; BitPim actually builds its
extensions only for whichever Python version is currently default, as
they're private and the app needs wxPython anyway.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/
ral actually supports that case
AFAICT. :-/ As such, I'll leave the (binNMU-friendly) packaging as is.
BTW, do you have an ETA for the transition?
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]
-
itely also an issue.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
"José Fonseca" <[EMAIL PROTECTED]> writes:
> Or find someway to override dpkg-shlibdeps behavior so that it
> produces the right dependency list.
Supplying a suitable shlibs.local should achieve this.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
h
Hi,
I'm part of the Debian Boost packaging team, seeking some guidance on
how to build and install Boost.Python so that it is usable with all
Python versions shipped in Debian. Debian currently ships Python 2.4
and 2.5.
When reading the following, keep in mind that Boost.Python is not a
Python e
a serious restriction? Given that
Debian likes to package extensions for all python versions, I tend to
think it will become a problem.
On Mon, Feb 25, 2008 at 01:15:31PM +0100, Josselin Mouette wrote:
> Hi,
>
> Le samedi 23 février 2008 à 22:45 -0600, Steve M. Robbins a écrit :
> >
On Tue, Feb 26, 2008 at 11:15:24PM -0500, Stefan Seefeld wrote:
> Steve M. Robbins wrote:
> > Hi,
> >
> > Thanks to Steve, Bernd, and Josselin for ideas.
> >
> >
> > On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:
> >
> >>
On Wed, Feb 27, 2008 at 08:43:43AM -0500, Stefan Seefeld wrote:
> (I still don't see the problem: Source packages don't depend on binary
> packages, only binary packages do.
Source packages *do*, in fact, depend on binary packages. Each source
package describes exactly the packages required t
On Wed, Mar 12, 2008 at 09:11:25PM -0400, David Abrahams wrote:
>
> on Sat Feb 23 2008, "Steve M. Robbins" wrote:
[...]
> > This produces pairs of library files such as
> >
> > bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a
> &g
g/debian-python/2008/03/msg00033.html
(yes, really message 33 in both months!)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "u
Hello,
I wrote about three weeks ago [1] that I'm trying to get Boost's
Python extension helper library building with multiple Python
versions. Several very helpful suggestions were made, for which I am
grateful.
I have been plugging away, very slowly, ever since. I'm hoping to
upload it later
"Steve M. Robbins" <[EMAIL PROTECTED]> writes:
> This allows extension builders to select either the default Python
> version, or a specific version, without knowing the Boost
> and GCC versions [2].
Yep; so far so good.
> I'd like to ask about intended beha
On Fri, Mar 21, 2008 at 03:59:30PM -0400, Aaron M. Ucko wrote:
> I do, however, see a couple of concrete issues with your script:
>
> > if [ "$1" = "-d" ]; then
> > debug=-d
> > shift
> > fi
>
> Shouldn't you fix that a
"Steve M. Robbins" <[EMAIL PROTECTED]> writes:
> libraries, including the Boost.Python libraries. The only difference
> in names is that the debug libraries have "-d" in them. So I was
> avoiding two scripts by this parameterization.
Ah, thanks for clarify
On Mon, Mar 24, 2008 at 05:52:47PM +, Dominic Hargreaves wrote:
> However, it looks to be like the shlibs file needs updating.
Yes, and thanks for the bug report. Upload is being prepared now.
-Steve
signature.asc
Description: Digital signature
For the debian-python readers just joining in: the recent modification
of Boost to support multiple Python runtimes has some unintended
consequences; see bug #473973. Below are some questions for your
consideration.
On Wed, Apr 02, 2008 at 06:11:34PM +0200, Sune Vuorela wrote:
> If I ask specif
On Thu, Apr 03, 2008 at 03:03:11PM +0200, Josselin Mouette wrote:
> On mer, 2008-04-02 at 12:04 -0500, Steve M. Robbins wrote:
> > So here are some questions, and I'd like to throw then out to the
> > wisdom of debian-python, too.
> >
> > 1. When does the rtupda
On Fri, Apr 04, 2008 at 10:29:37PM +0200, Josselin Mouette wrote:
> On ven, 2008-04-04 at 10:48 -0500, Steve M. Robbins wrote:
> > I was hoping is that if python is subsequently installed, that python
> > itself would run the rtupdate scripts. This doesn't seem to be the
>
On Sat, Apr 05, 2008 at 02:23:21AM +0200, Josselin Mouette wrote:
> On ven, 2008-04-04 at 19:08 -0500, Steve M. Robbins wrote:
> > > On the other hand, I???m not sure such symbolic links are necessary for
> > > debugging libraries; at least they are not for usual librarie
On Thu, May 01, 2008 at 10:30:32AM -0400, David Abrahams wrote:
>
> on Thu Mar 13 2008, "Steve M. Robbins" wrote:
>
> > Actually, the only thing about Boost that causes grief to packagers is
> > that the toolset name (e.g. "gcc42") is embedded in
ions as long
as you arrange for inter-package dependencies to be bin-NMU safe (no
strict all -> any dependencies).
> P.S.: Please CC me in replies, I'm not subscribed.
Done; thanks for warning us.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~am
On Mon, Feb 23, 2009 at 04:16:50PM +0100, Josselin Mouette wrote:
> the insighttoolkit rules file contains the following:
>
> PYMODDIR = usr/share/python-support/$(pkg_python)
> PYEXTDIR = usr/lib/python-support/$(pkg_python)/$(PYVERS)
> ...
> install/$(pkg_python)::
> dh_install -p$(pkg_p
On Sun, Mar 08, 2009 at 05:27:33AM +0100, Josselin Mouette wrote:
> Le samedi 07 mars 2009 ? 22:17 -0600, Steve M. Robbins a ?crit :
> > OK. I'm certainly in favour of avoiding complexity. However, I
> > thought I was following the python policy [1] where B.1 says:
&
thon-dsv) but
Debian's fltk1.1 maintainer, I'm probably the natural choice of
sponsor, and will proceed to upload the package within the next few
days unless somebody else chooses to step in.
Thanks for putting the package together.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, u
et it. ;-)
Thanks for your contribution to Debian!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubsc
Hi,
Recently, Mathieu Malaterre wrote to say that having a SOVERSION on a
python module is wrong, with reference to an oblique comment from
Josselin Mouette [1].
Is this true? What is the rationale for not versioning these shared
objects?
Is there any "more official" document that mandates this
Hi,
A cc is appreciated as I don't subscribe to debian-python.
On Fri, Jul 24, 2009 at 03:49:16PM +0200, Mathieu Malaterre wrote:
> On Wed, Jul 22, 2009 at 8:47 AM, Steve M. Robbins wrote:
> > Hi,
> >
> > Recently, Mathieu Malaterre wrote to say that having a SOVERSION
On Fri, Jul 24, 2009 at 07:13:19PM +0100, Max Bowsher wrote:
> IMO it's potentially misleading clutter, but it doesn't harm anything,
> so I'd consider it something that ought to be fixed, but very much low
> priority.
Agreed.
Thanks,
-Steve
signature.asc
Description: Digital signature
;numpyconfig.h".
- Per pyconfig.h, take advantage of the fact that GCC predefines
__BIG_ENDIAN__ or __LITTLE_ENDIAN__ as appropriate. (Numpy's
headers shouldn't actually #include , of course, just
learn from it.)
- Fall back on trying rather than #error-ing out, on the
gro
91015-0ubuntu1
--
Ville M. Vainio
http://tinyurl.com/vainio
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
x: debian/control
===
--- debian/control (revision 14598)
+++ debian/control (working copy)
@@ -4,9 +4,10 @@
Priority: optional
Maintainer: Debian Boost Team
Uploaders: Steve M. Robbins , Domenico Andreoli
-Build-Depends: debhelper (>= 7), bison, flex, docbook-to-man, xsltproc,
Hi,
Boost 1.46.1 fails to build with Python 3.2 on linux (Debian). The
build fails with:
error: cannot convert -F?PyObject*? to ?PyUnicodeObject*? for argument ?1? to
?Py_ssize_t PyUnicodeUCS4_AsWideChar(PyUnicodeObject*, wchar_t*, Py_ssize_t)?-A
at this code:
static std::wstring extr
Adam wrote:
> Paul Wise wrote:
>
>> On Thu, Sep 15, 2011 at 3:41 AM, Yaroslav Halchenko wrote:
>>> Do we have a logo for our Python-In-Debian effort(s) (was needing one
>>> for a recent talk but failed to deliver in time)? What about
>>> having one? I am not a designer and possibly lacking any t
Interesting, the LibraryStyleGuide [1] suggests a plain `=` and the
AppStyleGuide [2] suggests `:=`. (The difference of course is that `=`
does delayed evaluation meaning the command is run once for every time the
variable is needed, and `:=` does immediate evaluation meaning the command
is run on
On Wed, Jul 10, 2013 at 12:54 PM, Thomas Goirand wrote:
> On 07/10/2013 10:30 PM, Stuart Prescott wrote:
>> Thomas Goirand wrote:
>>> On 07/08/2013 10:10 PM, Scott Kitterman wrote:
There is no policy on this either way, so there's no "mistake".
>>>
>>> Well, the mistake is precisely to have n
Hello,
The Debian Python Policy documents [1] the rtupdate script for dealing with
default runtime changes. Is this documentation still valid? Will rtupdate be
used when the default runtime changes to python 3 or later?
Thanks,
-Steve
[1]
http://www.debian.org/doc/packaging-manuals/python-
Hi,
On October 29, 2013 09:49:53 AM Dmitrijs Ledkovs wrote:
> python3.X series and python2.X series are two distinct languages
> (incompatible API and ABI changes), and it has been decided to keep
> both alive as independent implementations.
> thus "/usr/bin/python" will always point to a python2
On 07/05/2015 09:51 PM, Piotr Ożarowski wrote:
>
> PPS hint to others: my favourite join requests are signed, include
> "I've read
> https://python-modules.alioth.debian.org/python-modules-policy.html and I
> accept it"
> and mention previous Pyton/Debian work (package names? patches? bug
> repo
On 07/06/2015 10:30 PM, Sandro Tosi wrote:
>> another problem is a spurious complaint about "Invalid revision range
>> 00..".
>> i haven't been able to track that down yet, but will report back if i
>> find something.
>
> this is probably the first push you made, and it says it cant compare
>
On Wed, May 20, 2015 at 06:36:33PM +0200, dktrkr...@debian.org wrote:
> Source: pyvtk
> Version: 0.4.74-3
I haven't uploaded pyvtk since 2011. So while looking to fix this
bug, I went looking for the most recent sources and found out that you
can easily get pyvtk via pip.
Since I don't use pyvtk
On August 8, 2015 10:13:04 AM Piotr Ożarowski wrote:
> [Steve M. Robbins, 2015-08-08]
>
> > I went looking for the most recent sources and found out that you
> >
> > can easily get pyvtk via pip.
>
> `sudo pip install ...` is the same as `rm -rf /` to me.
I s
On 10/10/2015 12:16 AM, Brian May wrote:
> On Sat, 3 Oct 2015 at 00:24 Barry Warsaw wrote:
>
>> 5-Oct - Do one last test run with an updated svn dump. Put the results in
>> a
>> public place for folks to play with and comment on.
>>
>> 8-Oct - Assuming no objections or showstoppers, turn off wri
75719
[4] https://github.com/sampsyo/beets/commits/master?author=diego-plan9
[5] https://mentors.debian.net/package/python-jellyfish
[6] http://python-modules.alioth.debian.org/policy.html
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
signature.asc
Description: Digital signature
n.org/cgi-bin/bugreport.cgi?bug=806716#42
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
signature.asc
Description: Digital signature
//qa.debian.org/popcon.php?package=beets
>
> On Tue, Dec 29, 2015 at 1:24 PM, Diego M. Rodriguez
> wrote:
>
> > On Tue, Dec 29, 2015 at 12:56:20PM -0500, Scott Kitterman wrote:
> > > I think the respective maintainers should talk and then discuss with
> > their
y apologies if it came too strong!
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
signature.asc
Description: Digital signature
> Welcome to the team.
>
> Scott K
Thank you - looking forward to a fruitful collaboration!
Best regards,
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
signature.asc
Description: Digital signature
n mind, I'm wondering if this would be a good time to rename
this ITP and the RFS (and the mentors package, etc) to the hopefully
final Debian package name ("python-jellyfishstr"?)?
Best regards,
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
signature.asc
Description: Digital signature
worries at all - I really apreciate your guidance and efforts on helping
move this issue forward.
Best regards,
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
signature.asc
Description: Digital signature
Package: wnpp
Severity: wishlist
Owner: IOhannes m zmölnig (Debian/GNU)
* Package name: python-can
Version : 1.5.2
Upstream Author : Brian Thorne
* URL : https://bitbucket.org/hardbyte/python-can
* License : LGPL v3
Programming Lang: Python
Description
Package: wnpp
Severity: wishlist
Owner: IOhannes m zmölnig (Debian/GNU)
* Package name: python-canmatrix
Version : 0.4
Upstream Author : Eduard Broecker
* URL : http://github.com/ebroecker/canmatrix
* License : BSD
Programming Lang: Python
Description
On 1/24/20 8:00 PM, Scott Kitterman wrote:
> I would suggest that people who decide to work on one of the above reply to
> this message so we don't end up with people doing duplicate works.
I can work on bumping "progress".
Best,
--
Diego M. Rodriguez
signature.asc
ght not provide too
much relevant info for end users anyway (and the inheritance from
"tuple" might be related to the original error).
[1]
https://case.readthedocs.io/en/latest/reference/case.mock.html#case.mock.call
[2] https://github.com/python/cpython/blob/3.8/Lib/unittest/mock.py#L23
Package: wnpp
X-Debbugs-Cc: debian-python@lists.debian.org, debian-scie...@lists.debian.org
Owner: "Diego M. Rodriguez"
Severity: wishlist
* Package name: python-beniget
Version : 0.4.1
Upstream Author : Serge Guelton
* URL : https://github.com/serge-s
Package: wnpp
X-Debbugs-Cc: debian-python@lists.debian.org
Owner: "Diego M. Rodriguez"
Severity: wishlist
* Package name: python-gast
Version : 0.5.2
Upstream Author : Serge Guelton
* URL : https://github.com/serge-sans-paille/gast
* License
I'd like to join the Python team. I intend to package the
browser_cookie3 module (https://github.com/borisbabic/browser_cookie3),
ITP #1056159.
My salsa login is ekalin.
I've read and accept the Python Python policy.
Thanks,
--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br
the tests are not being run. Thanks,
--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br
my personal salsa area:
https://salsa.debian.org/ekalin/browser-cookie3
--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br
On 14/12/2023 10:38, Eduardo M KALINOWSKI wrote:
I am looking for a sponsor for my package "browser-cookie3":
* Package name : browser-cookie3
Version : 0.19.1-1
Upstream contact : Boris Babic https://github.com/borisbabic/browser_cookie3/
* License
On 07/02/2024 12:15, Salvo Tomaselli wrote:
In data venerdì 19 gennaio 2024 20:55:45 CET, Eduardo M KALINOWSKI ha scritto:
On 14/12/2023 10:38, Eduardo M KALINOWSKI wrote:
I am looking for a sponsor for my package "browser-cookie3":
* Package name : browser-cookie3
tool for
downloading Instragram data) will likely depend on it. (Or at least
recommend it.)
--
Some men are all right in their place -- if they only the knew the right
places!
-- Mae West
Eduardo M KALINOWSKI
edua...@kalinowski.com.br
On Thu, 17 Sep 1998, Gregor Hoffleit >
> > An interested user told me that CNRI/NIST decided to leave the code
> > alone, after having used it as a testbed for network research and
> > might lighten the license.
[...]
>
> I wonder if we are the only ones reading this list. Is it possible t
I told to stay tuned... And now here I am, still waiting for your upcoming
Debian Python Policy... But I see some part of it, at least...
On Tue, 15 Sep 1998, Gregor Hoffleit wrote:
> Hi,
>
> - removal of python-net and python-misc
> - instead, a new package python-lib
>
Nice, I think it was ab
On Tue, 13 Oct 1998, Gregor Hoffleit wrote:
>
> 1.) Play safe. Stick with the current scheme for slink. I'll upload a
> new revision 1.5.1-5 with minor fixes only (all official patches
> applied).
>
This is how I think we should go...
>
> 2.) Play risk. Adopt a new scheme similar to my proposa
On Tue, 13 Apr 1999, Gregor Hoffleit wrote:
> I have put together a set of experimental Python 1.5.2c1 packages. To use
> them with apt, try the following line:
>
[...]
>
> * Python 1.5.2 release candidate 1.
>
> * libpython1.5.so reworked. Please report any anomalities! If I don't
>
On Wed, 14 Apr 1999, Gregor Hoffleit wrote:
>
> > I do. Please do include info docs.
>
> I will.
>
> The docs are quite big (700k resp. 450k for html and info
> gzipped). Is there support for splitting them in separate packages ?
> Then, is there also a need for postscript resp. pdf packages ?
t depend on python-base that would have to be checked for
compatibility with Python 2.1.
I think it's safe to say that wholesale use of 'python -W ignore'
would be unwarranted, because a lot of other stuff has to checked
any way ;-)
--
|>|\/|<
/--\
|David M. Cooke
|[EMAIL PROTECTED]
ou could split the argument on spaces -- although I'm not sure if
other Unices (the Hurd, anyone?) pass the rest of the line or just the first
argument.
Another alternative would be
#!/usr/bin/deb_py_ver 1.5.2-
and
#!/usr/bin/deb_py_ver 1.5.2-2.1.1
That's one argument.
--
|>|\
h like the 'gcc' package, whose only
purpose is to set what is the default python interpreter for Debian?
It would depend on python2.1-base.
--
|>|\/|<
/--\
|David M. Cooke
|[EMAIL PROTECTED]
Gregor Hoffleit wrote:
>
> If somebody could give me a legal advice that the Python license is in fact
> compatible with the GPL, and if this was accepted by the guys at
> debian-legal@lists.debian.org, I would happily adopt this opinion and that
> would make (b) go away as well.
>
> Until this h
Gregor Hoffleit wrote:
>
> On Fri, Feb 16, 2001 at 01:51:14PM +0100, M.-A. Lemburg wrote:
> > Gregor Hoffleit wrote:
> > >
> > > If somebody could give me a legal advice that the Python license is in
> > > fact
> > > compatible with the GPL, and
Gregor Hoffleit wrote:
>
> On Fri, Feb 16, 2001 at 03:34:07PM +0100, M.-A. Lemburg wrote:
> > Here's the "problem" I have: I want to put my code under a license
> > similar to the Python 2 license (that is including the choice of
> > law clause which cause
fficult to fix when upgrading a package to depend on
2.1 instead of 2.0? (I can't)
--
|>|\/|<
/--\
|David M. Cooke
|[EMAIL PROTECTED]
s are essential base programs in Debian -- it would
be stupid to fiddle with them, unless you know what you're doing]
I see it as: this package I installed worked, and I don't care whether
it's written in python or perl or tcl... Now, I've compiled my own
python, and the package doe
Tim Peters wrote:
>
> [M.-A. Lemburg]
> > Say, what kind of clause is needed in licenses to make them explicitly
> > GPL-compatible without harming the license conditions in all other
> > cases where the GPL is not involved ?
>
> You can dual-license (see, e.g., Pe
Howdy,
I've just finished my first attempt at packaging a python module.
This module (people.debian.org/~smr/pyvtk) is purely python.
I followed the "python policy" outlined in /usr/share/doc/python, and
also looked at a couple of example packages.
One thing I noticed in the packages (that isn't
severity 170711 critical
thanks
Hi,
I ran into coredumps when using python-vtk, see bug #170498.
I believe the coredumps are due to python moving from tcl/tk 8.3 to
tcl/tk 8.4. Other python extenion modules are still built with the
older tcl/tk, so you end up with both 8.3 and 8.4 loaded.
I th
On Wed, Apr 02, 2003 at 09:20:22AM +1000, Donovan Baarda wrote:
> G'day,
>
> just going through my old inbox messages that didn't seem to be replied
> to;
>
> On Mon, 2002-11-18 at 13:11, Steve M. Robbins wrote:
Well, thanks! I had forgotten about this. I'
What's the word on making the default version of python to be 2.3
instead of 2.2, now that 2.3 is released?
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
Hallo Mailinglist,
I never used Python before (just perl) :-( .
I got problems to get the python Programm "archmage" [1] runnig under woody.
I'm not sure, but I think the os.path "library" is missing or not correctly
installed
(Point 3. says it is installed).
Were is the error, which additional (d
Hallo Mailinglist,
I never used Python before (just perl) :-( .
I got problems to get the python Programm "archmage" [1] runnig under woody.
I'm not sure, but I think the os.path "library" is missing or not correctly
installed
(Point 3. says it is installed).
Were is the error, which additional (d
Hi Mailinglist,
> it looks like os.path.realpath was introduced in python2.2.
How do I install python2.2 the debian way ?
On my PC I got the deb's: python (dummy), python2.1 and python2.2 installed
[EMAIL PROTECTED]:~$ ls -l /usr/bin/python*
lrwxrwxrwx1 root root9 2002-12-17 14:
Oops... :)A college education should equip one to entertain three things: a friend, an idea and oneself.Wherever the fates lead us let us follow.
Debian, need cheap medication?
http://parabiotic.nnaew1.com/d13/index.php?id=d13 spasmed
It is all one to me if a man comes from Sing Sing Prison or H
es the layout of PyObject, so non-debug
C extensions access the fields of that wrong.
[This of course makes a debug build pretty hard to use...]
--
|>|\/|<
/------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
--
You go slow, be gentle. It's no one-way street -- you know how you
feel and that's all. It's how the girl feels too. Don't press. If
the girl feels anything for you at all, you'll know.
-- Kirk, "Charlie X", stardate 1535.8
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Hi:
I'm looking for a sponsor for a new package, webQuery.
I'd appreciate any and all feedback. I've posted this RFS on
debian-mentors several times without response. If posting it here is NOT
an acceptable alternative please let me know and I won't bother this
list again.
Test drive it at: http:
Phillip J. Eby wrote:
> At 01:04 AM 11/22/2005 -0600, Bob Tanner wrote:
>
>>On Tuesday 22 November 2005 12:15 am, Martin v. Löwis wrote:
>>
>>>I don't think Debian should use the egg structure. It apparently relies
>>>on building a long sys.path (even though through only a single .pth
>>>file);
>>
Ian Bicking wrote:
> M.-A. Lemburg wrote:
>
>>> Finally, I think it's important to note that what Debian should or
>>> should not use isn't really relevant to Debian's users, who will
>>> quite simply need eggs for many packages. If Debian doesn
Ian Bicking wrote:
> M.-A. Lemburg wrote:
>
>>> Eggs give room for package metadata that doesn't exist otherwise.
>>> Putting dependencies aside, this is functionality that simply doesn't
>>> exist with the standard distutils installation. In the cas
Phillip J. Eby wrote:
> At 06:33 PM 11/22/2005 +0100, M.-A. Lemburg wrote:
>
>>Phillip J. Eby wrote:
>>
>>>Yes, it's true, zipfile import processing is faster than normal import
>>>processing;
>>
>>Only after *all* ZIP files on sys.path have b
Phillip J. Eby wrote:
> Setuptools in SVN now provides preliminary support for installing eggs in
> .egg-info directory style, so that setuptools-based projects can be wrapped
> by system packagers who wish to avoid using .egg files or directories. In
> addition, you can now use setuptools to i
M.-A. Lemburg wrote:
> Phillip J. Eby wrote:
>> Setuptools in SVN now provides preliminary support for installing eggs in
>> .egg-info directory style, so that setuptools-based projects can be wrapped
>> by system packagers who wish to avoid using .egg files or directories.
1 - 100 of 105 matches
Mail list logo
