Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
Hi, Am 25.03.24 um 19:17 schrieb Julian Gilbey: * Reading and writing file formats (like CSV, Apache ORC, and Apache Parquet) liborcus supports this (Apache Parquet) if built with Apache Arrow. And thus makes LibreOffice being able to handle it. I didn't invest any time in Apache Arrow since I am already too low on time anyway and I deemed it too a "low popularity" thing anyway. 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! Indeed. There was some initial work done (see the RFP bug report for details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), but that is fairly old now. As Apache Arrow supports numerous languages, it may well benefit from having a group of developers with different areas of expertise to build it. (Or perhaps it would make more sense to split the upstream source into a collection of different Debian source packages for the different supported languages. I don't know.) Would definitely make transitions easier. Unfortunately I don't have the capacity to devote any time to it myself. Dito. Regards, Rene
Re: The python command in Debian
Hi, Am 14.07.20 um 11:00 schrieb Piotr Ożarowski: > FTR: I didn't change my mind. /usr/bin/python is still used outside > Debian packages, in /usr/local/bin scripts and applications and I > strongly disagree to touch it. Unfortunately (at least if I remember correctly I came up with an example of this lately...) also new stuff does #!/usr/bin/python and assumes it is python3... Do some distros set /usr/bin/python to python 3? Honestly, I think /usr/local/bin scripts then should simply be fixed by the admin. It's not as if they had years to do so. Regards, Rene
Re: Bug#949187: transition: python3.8
On Wed, Feb 05, 2020 at 01:26:31PM +, Simon McVittie wrote: > On Wed, 05 Feb 2020 at 08:18:41 +0100, rene.engelh...@mailbox.org wrote: > > Thanks, yes, that prevents the install of the "old" > > gobject-introspection with the new python3 from experimental. > > Sorry, I wasn't thinking straight (I blame post-FOSDEM illness). That > isn't actually what you need if you want to port to python3.8 Actually, no, I just wanted to prevent it FTBFSing when the default changes and gobject-introspection wasn't yet rebuilt. LibreOffice also only builds dor the default. (With a shitload of hackery it is possible to build pyuno twice/thrice etc. but given there*s a LO part of it this will not be coinstallable, defeating the purpose.) Regards, Rene
Re: Bug#949187: transition: python3.8
Hi, Am 4. Februar 2020 23:27:13 MEZ schrieb Simon McVittie : >On Tue, 04 Feb 2020 at 21:20:07 +0100, Rene Engelhard wrote: >> root@frodo:/# g-ir-scanner >... >> ModuleNotFoundError: No module named 'giscanner._giscanner' > >This is fixed in 1.62.0-5 (#950267). Thanks, yes, that prevents the install of the "old" gobject-introspection with the new python3 from experimental. Regards, René -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Bug#949187: transition: python3.8
Hi, On Mon, Feb 03, 2020 at 08:24:50PM +0100, Matthias Klose wrote: > On 2/3/20 8:22 PM, Simon McVittie wrote: > > On Sun, 02 Feb 2020 at 09:35:04 +0100, Matthias Klose wrote: > >> I think this is now in shape to be started. > > > > Please can this wait until the remaining bits of the libffi7 transition > > and the restructuring of the libgcc_s packaging have settled down? > > > > I'm still trying to sort out the missing Breaks around > > gobject-introspection, as highlighted by autopkgtest failures: this has > > been delayed by needing coordinated action between multiple packages, > > some of them quite big (glib2.0), and by Paul and I being at FOSDEM. > > This is entangled with python3.8 via pygobject (which will fail tests > > with python3.8 as default - an upload is pending to fix that). > > fine. I'm happy to see that fixed. Yeah, gobject-introspection was actually what I meant when I wrote "fontforge". My bad, bad memory in a sid chroot with python 3.8 as default: root@frodo:/# python3 --version Python 3.8.1 root@frodo:/# g-ir-scanner Traceback (most recent call last): File "/usr/bin/g-ir-scanner", line 99, in from giscanner.scannermain import scanner_main File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/scannermain.py", line 35, in from giscanner.ast import Include, Namespace File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/ast.py", line 29, in from .sourcescanner import CTYPE_TYPEDEF, CSYMBOL_TYPE_TYPEDEF File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/sourcescanner.py", line 33, in from giscanner._giscanner import SourceScanner as CSourceScanner ModuleNotFoundError: No module named 'giscanner._giscanner' and thus stuff building introspection will FTBFS (right now) (Thus I needed to disable it in my testbuild and thus libreoffice (1:6.4.0~beta1-4) experimental; urgency=medium * re-enable introspection which was accidentially kept disabled after a python3.8 test rebuild... * re-enable building of the "test packages" (-smoketest-data, -subsequentcheckbase) -- Rene Engelhard Sun, 15 Dec 2019 10:29:19 + happened.) Regards, Rene
Re: Bug#949187: transition: python3.8
On Sun, Feb 02, 2020 at 06:12:08PM +0100, Rene Engelhard wrote: > Hi, > > On Sun, Feb 02, 2020 at 06:07:29PM +0100, Matthias Klose wrote: > > > e.g. fontforge is still red in > > > https://release.debian.org/transitions/html/python3.8.html. > > > > > > That means that a rebuild of stuff using fontforge in the build will > > > just FTBFS since it will be called with python3.8 and that has no module > > > for 3.8 (yet). > > > > > > (Seen in a python-3.8-as-default testbuild for libreoffice some time > > > ago.) > > > > you are wrong. fontforge just builds for the default python version. > > OK, maybe. But that also means that when python3.8 is default and > fontforge isn't yet rebuilt for python3.8-as-default but some package > from my list is rebuilt the same problem happens. OK; inded it seems to just work. Maybe I even misremembered an it was graphite2 and python3-fonttools. (Reused the chroot for multiple tests.) But I *had* a module import failure when I tried some months ago. Regards, Rene
Re: Bug#949187: transition: python3.8
Hi, On Sun, Feb 02, 2020 at 06:07:29PM +0100, Matthias Klose wrote: > > e.g. fontforge is still red in > > https://release.debian.org/transitions/html/python3.8.html. > > > > That means that a rebuild of stuff using fontforge in the build will > > just FTBFS since it will be called with python3.8 and that has no module > > for 3.8 (yet). > > > > (Seen in a python-3.8-as-default testbuild for libreoffice some time > > ago.) > > you are wrong. fontforge just builds for the default python version. OK, maybe. But that also means that when python3.8 is default and fontforge isn't yet rebuilt for python3.8-as-default but some package from my list is rebuilt the same problem happens. Then fontforge (which is not in the list below!) needs to be rebuilt before https://release.debian.org/transitions/html/python3.8-default.html is worked on. Didn't see it there so wanted to go sure. Regards, Rene
Re: Bug#949187: transition: python3.8
On Sun, Feb 02, 2020 at 05:53:37PM +0100, Rene Engelhard wrote: > On Sun, Feb 02, 2020 at 09:35:04AM +0100, Matthias Klose wrote: > > > On 17-01-2020 23:28, Matthias Klose wrote: > > >> Please add a transition tracker to switch the python3 default to 3.8. > > >> It's not > > >> yet ready, however it would be good to see affected packages. Please > > >> copy it > > >> from the 3.7 defaults change if possible. > > > > > > Tracker is in place. Please remove the moreinfo tag when you're ready. > > > > I think this is now in shape to be started. bug reports have been filed for > > I don't think so. > > e.g. fontforge is still red in > https://release.debian.org/transitions/html/python3.8.html. > > That means that a rebuild of stuff using fontforge in the build will > just FTBFS since it will be called with python3.8 and that has no module > for 3.8 (yet). $ grep-dctrl fontforge -FBuild-Depends /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources | grep-dctrl python3 -FBuild-Depends -sPackage Package: diffoscope Package: fonts-allerta Package: fonts-courier-prime Package: fonts-gotico-antiqua Package: fonts-junicode Package: fonts-karmilla Package: fonts-le-murmure Package: fonts-rit-sundar Package: fonts-smc-anjalioldlipi Package: fonts-smc-dyuthi Package: fonts-smc-karumbi Package: fonts-smc-keraleeyam Package: fonts-smc-meera Package: fonts-smc-rachana Package: fonts-smc-raghumalayalamsans Package: fonts-smc-uroob Package: fonts-solide-mirage Package: libreoffice Package: mftrace Package: searx Regards, Rene
Re: Bug#949187: transition: python3.8
On Sun, Feb 02, 2020 at 09:35:04AM +0100, Matthias Klose wrote: > > On 17-01-2020 23:28, Matthias Klose wrote: > >> Please add a transition tracker to switch the python3 default to 3.8. > >> It's not > >> yet ready, however it would be good to see affected packages. Please copy > >> it > >> from the 3.7 defaults change if possible. > > > > Tracker is in place. Please remove the moreinfo tag when you're ready. > > I think this is now in shape to be started. bug reports have been filed for I don't think so. e.g. fontforge is still red in https://release.debian.org/transitions/html/python3.8.html. That means that a rebuild of stuff using fontforge in the build will just FTBFS since it will be called with python3.8 and that has no module for 3.8 (yet). (Seen in a python-3.8-as-default testbuild for libreoffice some time ago.) Regards, Rene
Re: Status Update For Bug#798999: transition: python3.5 supported
Hi, On Mon, Oct 12, 2015 at 10:24:02AM -0400, Scott Kitterman wrote: > Additionally, looking ahead to the next transition that makes python3.5 the > default python3, it would be good to look at the packages that build-dep on > python3-dev and see if it's reasonable to have them build-dep on python3-all- > dev and build for all supported python3 versions. > > Packages that only build for the default version will break until rebuilt as > soon as the default changes, whereas extensions that are built for all > supported python3 versions continue to work just fine. The fewer default > only > packages we have, the less breakage goes with changing the default [2]. I > have not investigated these at all. [...] And then > [2] > https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=python3-dev.list;bug=798999;msg=84;att=1 which says: Reverse-Build-Depends = [...] * libreoffice [...] Please, not this discussion again. :) (jessie)rene@frodo:/usr/lib/libreoffice/program$ dpkg -L python3-uno /. /usr /usr/share /usr/share/python3 /usr/share/python3/runtime.d /usr/share/python3/runtime.d/python3-uno.rtupdate /usr/share/bug /usr/share/bug/python3-uno /usr/share/bug/python3-uno/presubj /usr/share/doc /usr/share/doc/python3-uno /usr/share/doc/python3-uno/modes.sxd /usr/share/doc/python3-uno/changelog.Debian.gz /usr/share/doc/python3-uno/NEWS.Debian.gz /usr/share/doc/python3-uno/README.gz /usr/share/doc/python3-uno/copyright /usr/share/doc/python3-uno/demo /usr/share/doc/python3-uno/demo/swritercomp.py /usr/share/doc/python3-uno/demo/swriter.py /usr/share/doc/python3-uno/demo/pyunoenv.bat /usr/share/doc/python3-uno/demo/ooextract.py /usr/share/doc/python3-uno/demo/Addons.xcu /usr/share/doc/python3-uno/demo/hello_world_comp.py /usr/share/doc/python3-uno/demo/pyunoenv.tcsh /usr/share/doc/python3-uno/demo/biblioaccess.py /usr/share/doc/python3-uno/demo/swritercompclient.py /usr/share/doc/python3-uno/demo/makefile.mk /usr/lib /usr/lib/libreoffice /usr/lib/libreoffice/program /usr/lib/libreoffice/program/pythonloader.unorc /usr/lib/libreoffice/program/pythonloader.py /usr/lib/libreoffice/program/officehelper.py /usr/lib/libreoffice/program/libpyuno.so /usr/lib/libreoffice/program/libpythonloaderlo.so /usr/lib/libreoffice/program/pyuno.so /usr/lib/libreoffice/program/services /usr/lib/libreoffice/program/services/pyuno.rdb /usr/lib/libreoffice/share /usr/lib/libreoffice/share/Scripts /usr/lib/libreoffice/share/Scripts/python /usr/lib/libreoffice/share/Scripts/python/pythonSamples /usr/lib/libreoffice/share/Scripts/python/pythonSamples/TableSample.py /usr/lib/libreoffice/share/Scripts/python/HelloWorld.py /usr/lib/libreoffice/share/Scripts/python/Capitalise.py /usr/lib/libreoffice/share/registry /usr/lib/libreoffice/share/registry/pyuno.xcd /usr/lib/python3 /usr/lib/python3/dist-packages /usr/lib/python3/dist-packages/unohelper.py /usr/lib/python3/dist-packages/uno.py While the last two *.py are public modulesthe other ones are - in a LO Path because they are not public modules (but accessed by uno*.py[1]) - also linked to libpython for embedding the python interpreter to be able to run python scripts inside LO. Of the .sos above: (jessie)rene@frodo:/usr/lib/libreoffice/program$ for i in *py*so; do objdump -p $i | grep NEEDED; done NEEDED libpython3.4m.so.1.0 ^^^ NEEDED libpthread.so.0 NEEDED libdl.so.2 NEEDED libutil.so.1 NEEDED libuno_cppu.so.3 NEEDED libuno_cppuhelpergcc3.so.3 NEEDED libpyuno.so NEEDED libuno_sal.so.3 NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libgcc_s.so.1 NEEDED libc.so.6 NEEDED libpython3.4m.so.1.0 ^^^ NEEDED libpthread.so.0 NEEDED libdl.so.2 NEEDED libutil.so.1 NEEDED libuno_cppu.so.3 NEEDED libuno_cppuhelpergcc3.so.3 NEEDED libuno_sal.so.3 NEEDED libuno_salhelpergcc3.so.3 NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libgcc_s.so.1 NEEDED libc.so.6 NEEDED libdl.so.2 NEEDED libc.so.6 (jessie)rene@frodo:/usr/lib/libreoffice/program$ The build system of LO also only supports one python (and no, a hack like we had for python2/python3[2] doesn't scale.) Even if we did this python3.4-uno would conflict with python3.5-uno because of the common files above and moving the .sos above to a common package (libreoffice-core? python3-uno-core?) is a recipe for disaster (libpython3.4 vs. libpython3.5. OK, might not as bad as 3.3->3.4, but...) Note that python3-uno isn't really optional anymore, core functionality like wizards use python (for people who don't want it it's only
Re: Q: Python 2 vs Python 3 and wxgtk2.8 vs wxgtk3.0
[ I filed the bug against GNUmed to migrate to python3. Dropping that bug in my reply since it has NOTHING to do with the real bug. At least a new bug wxwidgets should provide a python3 package then blocks the gnumed bug, but it's not something one should handle there ] Hi, On Mon, Jul 07, 2014 at 10:47:28PM +0200, Karsten Hilbert wrote: GNUmed (an Electronic Medical Record System) runs under Python 2 with wxPython 2.8 and it Depends: on python-uno. thankfully the package only Recommends: python-uno.. Recently a bug was filed against GNUmed because python-uno is If Recently means 1 year ago, yeah... (But yeah, I added a comment there recently.) That said: # apt-cache show python-wxgtk2.8 Package: python-wxgtk2.8 Source: wxwidgets2.8 Version: 2.8.12.1+dfsg2-1 Installed-Size: 21974 Maintainer: wxWidgets Maintainers freewx-ma...@lists.alioth.debian.org Architecture: amd64 Replaces: libwxgtk2.6-0-python, wxpython2.6-0 Provides: python2.7-wxgtk2.8 Depends: python-wxversion (= 2.6.3.2.2-2), python (= 2.7), python ( 2.8), libc6 (= 2.14), libgcc1 (= 1:4.1.1), libstdc++6 (= 4.1.1), libwxbase2.8-0 (= 2.8.12.1+dfsg2), libwxgtk2.8-0 (= 2.8.12.1+dfsg2) Suggests: wx2.8-doc, wx2.8-examples, editra Conflicts: libwxgtk2.6-0-python, python-wxaddons, wxpython2.6-0 Description-en: wxWidgets Cross-platform C++ GUI toolkit (wxPython binding) wxWidgets (formerly known as wxWindows) is a class library for C++ providing GUI components and other facilities on several popular platforms (and some unpopular ones as well). . This package provides a Python binding to the wxGTK library and the wxPython runtime support libraries. Description-md5: 512d862ab885e743c6f3b61ad713b1a9 Homepage: http://www.wxpython.org/ Tag: role::shared-lib, uitoolkit::wxwidgets Section: python Priority: optional Filename: pool/main/w/wxwidgets2.8/python-wxgtk2.8_2.8.12.1+dfsg2-1_amd64.deb Size: 3836166 MD5sum: 7acf5366ff44f48d9327ace59936a97a SHA1: 4c5cf86ffb162025420c1124f0a0543fc2242bb4 SHA256: 82d02fcb40b153ef1b64722bcd6344f255426ee72d2ea1d74a71ba748d5100de debian-python doesn't maintain wxwidgets, you probably have more luck asking the wxwidgets maintainers why there's no python3 variant. (CC'ed) What's the current Debian position ? TTBOMK the position is build a python3 variant if your package supports python3 and try to port it. But given how many upstreams did not react on python3 in any way even though that is the ONLY supported python version in stock LO 4.x. since 1 year (python-uno is a debian-specific hack) I don't have much hope that it supports python3 now... Regards, Rene -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140707215515.gk23...@rene-engelhard.de
Re: (again) Why default python is not 2.6 yet?
Hi, On Wed, Feb 17, 2010 at 04:18:28PM +0100, Sandro Tosi wrote: That holds true any time we do the switch. So when should we change the default? the moment we freeze? From my personal POV you csn do now, I think the release team would not agree, though ;-) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100301131601.gb14...@rene-engelhard.de
Re: (again) Why default python is not 2.6 yet?
Hi, On Wed, Feb 17, 2010 at 12:05:56AM +0100, Sandro Tosi wrote: If there is a valid, technical reason, please let us know, but as of now I can't see any. Loads of RC bugfixes (partly on obsolete versions) waiting to enter testing which would more blocked that it already is with the mips* buildd backlog. So, let's just change the default to 2.6, kindly ask Lucas to do an archive-wide rebuild (I'm pretty sure he'll be happy to support us, but not certan, hey we still have to ask him ;) ), and deal with the fallback. For months. At which time we'll still have the completely obsolete OOo 3.1.1 (or whatever else example you find) in squeeze. No. Keep waiting and waiting is pointless, and does only harm for the target to support a stable release (there are very few people actively That's true, though. But python's not alone in the world and if you did it far earlier Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100217144957.ga16...@rene-engelhard.de
Re: (again) Why default python is not 2.6 yet?
Hi, On Wed, Feb 17, 2010 at 04:18:28PM +0100, Sandro Tosi wrote: On Wed, Feb 17, 2010 at 15:49, Rene Engelhard r...@debian.org wrote: On Wed, Feb 17, 2010 at 12:05:56AM +0100, Sandro Tosi wrote: If there is a valid, technical reason, please let us know, but as of now I can't see any. Loads of RC bugfixes (partly on obsolete versions) waiting to enter testing which would more blocked that it already is with the mips* buildd backlog. Those RC are still RC even in a month or 2, only that knowing them, they can be fixed. You misinterpreted my sentence. I already have *7* RC bugs on OOo fixed in sid. They wait for entering testing. Since weeks. And I don't want 3.1.1 in squeeze. 3.2.0 is (indepently from what I think) far better. So, let's just change the default to 2.6, kindly ask Lucas to do an archive-wide rebuild (I'm pretty sure he'll be happy to support us, but not certan, hey we still have to ask him ;) ), and deal with the fallback. For months. At which time we'll still have the completely obsolete OOo 3.1.1 (or whatever else example you find) in squeeze. No. That holds true any time we do the switch. So when should we change the default? the moment we freeze? In a sane moment. You mentioned OOo, we have also libjpeg mess going on, and soon we'll have php5 probably. Obviously those are sifferent, and php5 *is* the uptodate version, not a 1 year old one. Keep waiting and waiting is pointless, and does only harm for the target to support a stable release (there are very few people actively That's true, though. But python's not alone in the world and if you did it far earlier I understand, when you touch core/big packages, there are always consequences; but I don't get what you're suggesting to actually switch: at freeze time, when there are no other transition on sight (i.e. never), release squeeze with 2.5 as default, else? When should packages enter testing? Shortly before the freeze without proper testing? It was not done before, that's a fact. It should be done now, and deal with the damage it generates (of course, with the help of RT, if they agree to start the transition). Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8b2d7b4d1002170718s39d7a65cy22eb6c6ee571a...@mail.gmail.com Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100217153247.gb16...@rene-engelhard.de
Re: Bug#520944: [python-uno] Python support in OpenOffice is completely broken
tag 520944 + confirmed
tag 520944 + help
thanks
{ CC'ing debian-python }
Hi,
Adrià Cereto Massagué wrote:
the problem seems to be specifically in the module pyuno. Here's the
traceback
in an interactive python shell:
Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47)
[GCC 4.3.3] on linux2
Type help, copyright, credits or license for more information.
import pyuno
Traceback (most recent call last):
File stdin, line 1, in module
SystemError: dynamic module not initialized properly
Known. I uploaded it nevertheless to get the other parts tested.
It's experimental after all :)
I've tried a fix i've found for a very older version of openoffice in ubuntu,
which was:
ldconfig -v /usr/lib/openoffice/program
But it hasn't take any effect.
That once was a cause, but this can't be here, I already rules that out. The
RPATH
points to the correct location.
Also the uno.py (that was the other error scenario) so far is correct and has
URE_BOOTSTRAP
correctly set.
Third there's no new files in 3.1s python-uno, so it cannot be some wrong path
for
the new files either.
To conclude: I need some python-knowledgeable person to help here.
Also, maybe it isn't directly related, maybe it is, but in OpenOffice the
Macros
manager won't find any python macros, despite they're actually installed (the
default ones) as in previous versions.
It is.
I think it's a serious issue because it breaks all python-based macros and
uno-dependant python scripts, as well as some openoffice extensions.
Yes, but you use experimentals packages, so
Grüße/Regards,
René
--
.''`. René Engelhard -- Debian GNU/Linux Developer
: :' : http://www.debian.org | http://people.debian.org/~rene/
`. `' r...@debian.org | GnuPG-Key ID: 248AEB73
`- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python 2.1/2.2 removal; Python 2.4 as default
Matthias Klose wrote: Jeroen van Wolffelaar writes: The first freezes are already closing in fast, did I miss something? There's no update since http://lists.debian.org/debian-devel-announce/2005/10/msg4.html Yes. At least the January, 3rd one (http://lists.debian.org/debian-devel-announce/2006/01/msg1.html) --- snip --- [...] Our time line still is: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] The good news is that we are on track to reach this goal. [...] --- snip --- Regards, Rene signature.asc Description: Digital signature
Re: PyUno availability
[ -python is the wrong list. pxuno is an OOo component and built from OOo so -openoffice would be appropriate ] Hi, Encolpe DEGOUTE wrote: the extension PyUno of the openoffice debian package has been compiled with system python. That's a good thing, but I can't import the « uno » module. Does anybody here have a tips for this before i put a bug that's because it is not packaged. If it was it wold be in an own package anyway. There is some outstanding problems - not everything works although it builds... against openoffice package ? There a) is no openoffice package :-P and b) there already are two bugs filed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=220226 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=232905 Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 signature.asc Description: Digital signature
