Bug#995447: ITP: psycopg3 -- PostgreSQL database adapter for Python 3
Package: wnpp
Severity: wishlist
Owner: Tomasz Rybak
X-Debbugs-Cc: debian-de...@lists.debian.org, serp...@debian.org
* Package name: psycopg3
Version : 3.0.0~beta{1,2}
Upstream Author : Daniele Varrazzo
* URL : https://www.psycopg.org/psycopg3/
* License : LGPL-3
Programming Lang: Python
Description : PostgreSQL database adapter for Python 3
Psycopg 3 is a newly designed PostgreSQL database adapter for the Python
programming language.
Psycopg 3 is a complete rewrite of Psycopg 2, maintaining the same
fundamental libpq wrapper architecture and DB-API interface design, but
exposing new features to better work with the newer versions of Python
and PostgreSQL.
On the Python side, Psycopg 3 allows the use of asyncio-based
concurrency and static typing. Many improvement to the Python interface
make the library much simpler and more idiomatic to use,
On the PostgreSQL side, Psycopg 3 makes use of server-side parameters,
prepared statements, binary parameters, and great support for COPY
operations.
Psycopg 3 presents a familiar interface for everyone who has used
Psycopg 2 or any other `DB-API 2.0` database adapter, but allows one
to use more modern PostgreSQL and Python features, such as:
- Strict Strong Typing
- asynchronous support
- server-side parameters binding
- binary communication
- a great integration of the COPY support
- direct access to the libpq functionalities
I'll be maintaining this package inside Python team (just like
psycopg2 is). To be able to fully built it, I might need to
update Cython and psycopg2 versions first.
Bug#812533: ITP: plugn -- hook system for shell programs
W dniu 24.01.2016, nie o godzinie 18∶49 +, użytkownik Alessio Treglia napisał: > Package: wnpp > Severity: wishlist > Owner: Alessio Treglia > > * Package name: plugn > Such name might be a little to generic - I'd suggest adding some prefix lub suffix mentioning Go language. Best regards. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#812367: ITP: swift-bench -- benchmarking tool for Swift
W dniu 22.01.2016, pią o godzinie 15∶09 -0500, użytkownik Ondřej Nový napisał: > Package: wnpp > Severity: wishlist > Owner: "Ondřej Nový" > > * Package name: swift-bench > Version : 1.0 > * URL : https://github.com/openstack/swift-bench > * License : Apache-2 > Programming Lang: Python > Description : benchmarking tool for Swift > > Swift Bench is simple tool for benchmarking OpenStack Swift cluster > > As part of the pkg-openstack team, I am planning to package it. I'd suggest adding openstack to the name - otherwise this package might suggest that it has something to do with Swift language: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788327 > -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#782250: ITP: python-future -- use a single, clean Python 3.x-compatible codebase to support both Python 2 and Python 3 with minimal overhead
Hello dacoex. Some time ago (on 2015-03-05) you asked aboyt python-future. Barry Warsaw is starting work on packaging it. Best regards. Dnia 2015-04-09, czw o godzinie 09:54 -0400, Barry Warsaw pisze: > Package: wnpp > Severity: wishlist > Owner: Barry Warsaw > > * Package name: python-future > Version : 0.14.3 > Upstream Author : Ed Schofield > * URL : https://python-future.org/ > * License : MIT/X > Programming Lang: Python > Description : use a single, clean Python 3.x-compatible codebase to > support both Python 2 and Python 3 with minimal overhead > > Easy, clean, reliable Python 2/3 compatibility, this is the missing > compatibility layer between Python 2 and Python 3. > > This package will be maintained within the DPMT. > > -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#680188: ITP: pgsphere -- extension for PostgreSQL adding spherical data types
Dnia 2012-07-04, śro o godzinie 12:34 +0200, Florian Rothmaier pisze: > Package: wnpp > Severity: wishlist > Owner: Florian Rothmaier > > > * Package name: pgsphere > Version : 1.1.1 > Upstream Author : Janko Richter > * URL : http://pgfoundry.org/projects/pgsphere/ > * License : BSD-3-clause > Programming Lang: C > Description : extension for PostgreSQL adding spherical data types > > PgSphere, an extension for PostgreSQL, aims at providing uniform > access to spherical data. It allows for a fast search and analysis for > objects with spherical attributes in geographical, astronomical, or > other applications using PostgreSQL. > . > By using an SQL interface, PgSphere's users can conveniently manage > data of geographical objects around the world and astronomical data > collections like star and other catalogues. > How it related to PostGIS? I mean - can I use both PostGIS and pgsphere, do I need to chose only one, can I use pgsphere for one thing and PostGIS to another? Regards. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#680892: ITP: radeontop -- radeontop: Utility to show Radeon GPU utilization
Dnia 2012-07-09, pon o godzinie 00:21 +0200, John Paul Adrian Glaubitz pisze: > Package: wnpp > Severity: wishlist > Owner: John Paul Adrian Glaubitz > > * Package name: radeontop > Version : 0.5.4 > Upstream Author : Lauri Kasanen > * URL : https://github.com/clbr/radeontop > * License : GPLv3 > Programming Lang: C > Description : radeontop: Utility to show Radeon GPU utilization > > radeontop is a small utility which allows to monitor the utilization of > Radeon GPUs starting from the R600 series and newer using using undocumented > performance counters in the hardware. The utility works with the free > drivers. > > It displays the utilization of the graphics pipe, event engine, vertex cache, > vertex group and tesselator, texture addresser and cache, the shader units > and more both with a relative percent value as well as a colorful bar diagram. > > It comes with a manpage. > > > Package seems interesting. Will it work with non-free driver? Also, can it show OpenCL related data, like allocated memory, threads running, etc.? Regards. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#675528: Compiling PyOpenCL with ocl-icd-libopencl1
Hello. Thanks for working on free OpenCL library - I hope it'll help me solve #673992. Is there possibility that ocl-icd will land in Wheezy? I have tried to built PyOpenCL package with ocl-icd-libopencl1 1.0-beta but it looks like it does not provide all functions: import pyopencl._cl as _cl ImportError: /usr/src/cuda/pyopencl/pyopencl-2011.2 +git20120602/build/lib.linux-x86_64-2.7/pyopencl/_cl.so: undefined symbol: clUnloadCompiler Should I fill bug report with upstream, or provide more details? Best regards. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#675528: Bug#673992: python-pyopencl: explicitely requires installation of amd-libopencl1
Dnia 2012-06-01, pią o godzinie 12:59 +0200, Vedran Miletić pisze:
> 2012/5/22 Tomasz Rybak :
> > Dnia 2012-05-22, wto o godzinie 14:14 +0200, Vedran Miletic pisze:
> >> Package: python-pyopencl
> >> Version: 2011.2+git20120508-1
> >> Severity: important
> >>
> >> Dear Maintainer,
> >>
> >> since 2011.2+git20120508-1, python-pyopencl depends on amd-libopencl1,
> >> which
> >> conflicts with nvidia-libopencl1. This effectively makes it unusable for
> >> people using it on NVIDIA cards.
> >>
> >> I'm sure there is a good reason for the requirement, but could it be
> >> relaxed
> >> somehow? It already requires one or the other by virtual dependancy.
> >
> > For more detailed explanation see NEWS from python-pyopencl.
> > In summary - Debian now contains opencl-headers 1.2.
> > NVIDIA's OpenCL supports only OpenCL 1.1 - which means that package was
> > being built successfully but failed to run any code, failing to find
> > OpenCL 1.2 functions.
> > OTOH AMD library provides OpenCL 1.2 and works well with NVIDIA GPUs.
> > AMD deals with managing OpenCL, and forwards all calls to NVIDIA
> > implementation - hence hard dependency on amd-libopencl1.
> >
> > I shall add another entry in NEWS file to describe this situation and
> > relieve worries of users of PyOpenCL. Any insight what would be
> > the best description from user point of view? I do not want to go
> > into details and bore with my description.
> >
> > Of course if you experience some crashes with PyOpenCL running on Debian
> > please let me know. I have tested this combination (NVIDIA+AMD OpenCL
> > libraries) on both unstable and experimental drivers and have not had
> > any troubles, but maybe I just got lucky ;-)
> >
> > Andreas - I know this is my bug, but maybe it would be good idea to add
> > some description to OpenCL-related packages? I can write some draft
> > (but no earlier than middle of next week - I am busy with fixing
> > PyCUDA) to describe situation with libOpenCL and ICD stuff?
> >
> > Best regards.
> >
> > --
> > Tomasz Rybak GPG/PGP key ID: 2AD5 9860
> > Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
> > http://member.acm.org/~tomaszrybak
> >
>
> Hi Tomasz,
>
> I followed your instructions, and I'm experiencing Segmentation fault
> with pyopencl on
> http://enja.org/2011/02/22/adventures-in-pyopencl-part-1-getting-started-with-python/index.html
>
> $ python main.py
> __kernel void part1(__global float* a, __global float* b, __global float* c)
> {
> unsigned int i = get_global_id(0);
>
> c[i] = a[i] + b[i];
> }
>
> Segmentation fault
>
> Any suggestions?
>
I have done some testing and I also get segmentation fault on some
OpenCL kernels. I haven't got segfault on your sample program.
I have been running PyOpenCL unit tests and:
1. test_clmath.py runs without any segfault
2. test_array.py runs without any segfault
3. test_wrapper.py segfaults in test_get_info (in cl.Image) and test_image2d (in
cl.image_from_array).
Initially I have suspected older amd-libopencl1 version (fglrx 12-4
does not work with X.org 12), but problem remains after updating
to 12-6-beta and rebuilding PyOpenCL. I have tested on 295.53
on NVIDIA ION. It looks like in some cases (not all) NVIDIA OpenCL
segfaults when run using AMD OpenCL management library.
I have tested with ocl-icd, which it ITPd by Vincent Danjean,
but there are some problems with compilation.
I do not know yet how to solve it, but shall let you know
when there is some solution.
Regards.
--
Tomasz Rybak GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
signature.asc
Description: This is a digitally signed message part
Bug#629518: AMD APP licence for distribution in Debian
Sorry for writing to you - I was not able to find email of person responsible for managing AMD Accelerated Parallel Processing SDK. Feel free to forward this email to AMD APP team. Hello. I am involved in development and packaging PyOpenCL (http://mathema.tician.de/software/pyopencl), Python wrapper for OpenCL. I am maintainer of Debian python-pyopencl package. Currently Debian (and Ubuntu) only provides NVIDIA OpenCL implementation. Recently I have received bug report demanding support for AMD OpenCL implementation: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628702 https://bugs.launchpad.net/ubuntu/+source/pyopencl/+bug/763457 . I have checked that python-pyopencl works correctly with AMD APP. I have opened bug asking for Debian Developer to package AMD APP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629518 Andreas Beckmann (CC'd) started working on packaging but current license prevents AMD APP SDK from being distributed by Debian, even in non-free section. Would it be possible to change license to DFSG-free (Debian Free Software Guidelines) one? This way AMD APP could be distributed in by Debian without any restrictions. According to http://www.debian.org/legal/licenses/ DFSG-free licenses include GPL, LGPL, BSD, Apache, MIT, Perl artistic license, and others. If changing license to the free one is not possible, debian-legal team claims that: "something like this would be better [than current license]: http://intellinuxwireless.org/LICENSE.iwlwifi-ucode " Best regards. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#629518: Preliminary AMD APP SDK Packaging
Dnia 2011-06-15, śro o godzinie 02:50 +0200, Andreas Beckmann pisze: > On 2011-06-10 16:21, Tomasz Rybak wrote: > > Dnia 2011-06-08, śro o godzinie 18:15 +0200, Andreas Beckmann pisze: > >> I have prepared and use local packages for the AMD APP SDK and offer to > >> package this for Debian once someone confirmed that it can be put into > >> non-free. > > > > Can you put packaging information (i.e. debian/ directory) on some > > repository? I would like to try to build packages myself and test > > building PyOpenCL with them. > > Vcs-Svn: svn://svn.debian.org/svn/pkg-nvidia/packages/amd-app-sdk/trunk > Vcs-Browser: > http://anonscm.debian.org/viewvc/pkg-nvidia/packages/amd-app-sdk/ > > Have fun! Comments welcome. Thanks. I was able to build it offline (only 64-bit versions, as I did not have 32-bit libraries installed). Currently amd-app-sdk-dev does not build. Will it be just meta-package depending on all AMD APP-related packages? lintian complains about: W: amd-libopencl1: package-name-doesnt-match-sonames libOpenCL1 At the same time I was not able to install amd-libopencl1: Zaznaczenie poprzednio niezaznaczonego pakietu amd-libopencl1. dpkg: w odniesieniu do amd-libopencl1_2.4-0_amd64.deb zawierającego amd-libopencl1: amd-libopencl1 w konflikcie z libopencl1 nvidia-libopencl1 dostarcza libopencl1 i jest obecny oraz zainstalowany. dpkg: błąd przetwarzania amd-libopencl1_2.4-0_amd64.deb (--install): konflikt pakietów - nie będzie instalowany amd-libopencl1 Translation - both nvidia-libopencl1 and amd-libopencl1 provide libopencl1 and as nvidia-libopencl1 is properly installed dpkg will not install amd-libopencl1. But thanks to having /usr/lib/libamdocl64.so in amd-opencl-icd python-pyopencl was able to detect and use OpenCL implementations from both NVIDIA and AMD. So current situation makes sense and works for my packages. By current situation I mean nvidia-opencl-icd providing opencl-icd and depending on nvidia-libopencl1, and amd-opencl-icd providing opencl-icd and containing AMD OpenCL implementation. As long as I can install more than one ICD and all of them work I am content. Would it make sense to have similar meta-package for opencl-dev? This way if I have NVIDIA hardware I install nvidia-opencl-dev (providing, say, opencl-dev), and if I have AMD/ATI hardware I install amd-opencl-dev (or amd-app-sdk) which also can provide opencl-dev meta-package. If not I guess I can build-depend python-pyopencl on "nvidia-opencl-dev | amd-app-sdk-dev". In summary: package works, thanks for providing it. Best regards. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#629518: AMD APP licence
Hello.
I have recently opened bug requesting packaging of AMD
(#629518). Andreas Beckmann pointed out that there might be
problems with license preventing software from being
distributable in non-free. I attach license file.
Here is my quick analysis, also sent as comment to bug #629518.
I am not sure whether Debian would be considered Organization as
meant by clause 1 c (make and distribute copies of the Software
within your organization). Another problem would be with point 2 c)
(electronically transmit the Software from one computer to another
or over a network). Point 6 (US government) and 7 (export restrictions)
could be problematic, but I am not sure about Debian policy
in that regard.
IMO the additional licenses (Elf Tool Chain Project,
src/sys/sys/elf32.h, src/sys/sys/elf64.h and src/sys/sys/elf_common.h,
src/sys/sys/queue.h) resemble BSD license, but I am not a specialist.
Best regards.
--
Tomasz Rybak GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
IMPORTANT -- READ CAREFULLY: Do not load this Software until you have
carefully read and agreed to the following terms and conditions. This is a
legal agreement ("Agreement") between you (either an individual or an entity)
(you or "Licensee") and Advanced Micro Devices, Inc. ("AMD"). If Licensee
does not agree to the terms of this Agreement, do not install or use this
Software or any portion thereof. By loading or using this software that may
include associated media, printed Software, and online or electronic
documentation or any portion thereof that is made available to install
("Software"), Licensee agrees to all of the terms of this Agreement.
1. License. The software accompanying this License (hereinafter "Software"),
regardless of the form in which it is distributed, is licensed to you by
Advanced Micro Devices, Inc. You own the medium on which the Software is
recorded, but Advanced Micro Devices, Inc. and, if applicable, its Licensors
(referred to collectively as "AMD") retain title to the Software and
related documentation. You may:
a) make a copy of the Software in machine-readable form for backup purposes.
You must reproduce on such copy AMD's copyright notice and any other
proprietary legends that were on the original copy of the Software;
b) transfer all your license rights in the Software to a third party
provided you must also transfer a copy of this License, the backup copy of
the Software and the related documentation and provided the other party reads
and agrees to accept the terms and conditions of this License. Upon such
transfer your license is then terminated; and
c) make and distribute copies of the Software within your organization,
provided that you agree to include all copyright legends and other legal
notices that may appear in the Software, as well as this Software License
Agreement in its entirety, in each copy of the Software that is made or
distributed.
2. Restrictions. The Software contains copyrighted and patented material,
trade secrets and other proprietary material. In order to protect them, and
except as permitted by applicable legislation, you may not:
a) decompile, reverse engineer, disassemble or otherwise reduce the Software
to a human-perceivable form;
b) modify, network, rent, lend, loan, distribute or create derivative works
based upon the Software in whole or in part; or
c) electronically transmit the Software from one computer to another or over
a network or otherwise transfer the Software except as permitted by this
License.
3 OWNERSHIP AND COPYRIGHT OF SOFTWARE: The Software is owned by AMD and is
protected by United States and foreign intellectual property laws (e.g. patent
and copyright laws) and international treaty provisions. Licensee will not
remove the copyright notice from the Software. Licensee agrees to prevent
any unauthorized copying of the Software. All title and copyrights in and
to the Software, all copies thereof (in whole or in part, and in any form),
and all rights therein shall remain vested in AMD. Except as expressly
provided herein, AMD does not grant any express or implied right to Licensee
under AMD patents, copyrights, trademarks, or trade secret information. All
rights in and to the Software not expressly granted to Licensee in this
Agreement are reserved to AMD.
4. SUPPORT: Under this Agreement, AMD is under no obligation to assist in
the use of this Software, to provide support to licensees of the Software, or
to provide maintenance, correction, modification, enhancement, or upgrades to
the Software. AMD may provide such support, maintenance, correction,
modification, enhancement or upgrades in a media determined by AMD and AMD
shall have no obligation to notify Licensee thereof. Additionally, such
support, maintenance, correction, modification, enhancement, or
Bug#629518: AMD APP SDK License
Dnia 2011-06-08, śro o godzinie 18:15 +0200, Andreas Beckmann pisze: > Attached is the AMD APP SDK 2.4 License. I'm not sure whether this is > redistributable in non-free. Who could clarify this? Maybe debian-legal? I am not sure whether Debian would be considered Organization as meant by clause 1 c (make and distribute copies of the Software within your organization). Another problem would be with point 2 c) (electronically transmit the Software from one computer to another or over a network). Point 6 (US government) and 7 (export restrictions) could be problematic, but I am not sure about Debian policy in that regard. IMO the additional licenses (Elf Tool Chain Project, src/sys/sys/elf32.h, src/sys/sys/elf64.h and src/sys/sys/elf_common.h, src/sys/sys/queue.h) resemble BSD license, but I am not a specialist. > I have prepared and use local packages for the AMD APP SDK and offer to > package this for Debian once someone confirmed that it can be put into > non-free. Can you put packaging information (i.e. debian/ directory) on some repository? I would like to try to build packages myself and test building PyOpenCL with them. Best regards. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#629518: RFP: amd-opencl -- Library providing support for OpenCL on AMD/ATI graphics cards
Package: wnpp Severity: wishlist * Package name: amd-opencl Version : 2.4 Upstream Author : AMD * URL : http://developer.amd.com/sdks/AMDAPPSDK/Pages/default.aspx * License : other, non-free Programming Lang: C, C++ Description : Library providing support for OpenCL on AMD/ATI graphics cards AMD APP (Accelerated Parallel Processing) provides ability to run OpenCL code on AMD/ATI graphics cards and processors. Currently Debian contains OpenCL implementation for NVIDIA hardware, which leaves users of different graphics cards unable to run OpenCL programs (see bug #628702). -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110607110727.2836.28458.reportbug@localhost.localdomain
Bug#581184: [pkg-nvidia-devel] Bug#582315: preliminary packages of nvidia-cuda-toolkit 3.0 available
Dnia 2010-06-10, czw o godzinie 12:15 +0200, Christian Kastner pisze: > On 06/09/2010 12:48 PM, Andreas Beckmann wrote: > > Preliminary packages of nvidia-cuda-toolkit 3.0 (now supports OpenCL, > > too) are available at: > > > > http://stxxl.ae.cs.uni-frankfurt.de/tmp/582ce36a-592b-4677-9c3b-86ed21603fd9/ > > > > OpenCL support needs packages from nvidia-graphics-drivers 195.36.24-2 > > and will be fully functional with 195.36.24-3 (not yet uploaded). > > > > Please give it a try and see if you can build your dependent packages now. > > The CUDA extension package[1] for pyrit[2] builds and (in initial tests) > runs fine against this. > > Great work! > > [1]http://www.kvr.at/debian/pool/contrib/p/pyrit-cuda/pyrit-cuda_0.3.0-1.dsc > [2]http://www.kvr.at/debian/pool/main/p/pyrit/pyrit_0.3.0-1.dsc > Thanks for work on packaging toolkit. I have build PyCUDA against packaged 3.0 toolkit and it works OK. I have one question however - why does nvidia-cuda-toolkit depends on libcudart3 (>= 2.0) while it also depends on nvidia-cuda-dev which also depends on libcudart3 (=3.0-0a)? -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#546919: New versions of packages
As pointed by Yaroslaw Halczenko I have run lintian and removed all warnings. In my opinion packages are ready for consideration - the only block is #581184. I have also managed to create private repository. Now anyone using architecture amd64 can add following lines to /etc/apt/sources.list deb http://www.bogomips.w.tkb.pl . . deb-src http://www.bogomips.w.tkb.pl . . (there are two dots separated by space) then `apt-get update && apt-get install python-pycuda` and PyCUDA should be installed. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#546919: New version of python-pycuda packages
Dnia 2010-05-20, czw o godzinie 09:10 +0200, Sandro Tosi pisze: > Hi > > On Wed, May 19, 2010 at 23:57, Tomasz Rybak wrote: > > I have put new version of PyCUDA (and pytools) pacages: > > http://www.bogomips.w.tkb.pl/cuda.html#Debian > > http://www.bogomips.w.tkb.pl/cuda/ > > > > Now python-pycuda depends on python-pytools. > > python-pycuda still does not depend on nVidia CUDA toolkit > > - as soon as there is semi-final version of those packages > > I will add dependencies. > > Packages are signed with my GPG key. > > > > I tried to create private repository (so one could add > > appropriate lines to sources.list and use apt-get to install > > pycuda in Debian) but messed something with directories, > > so for now there is no repository with pycuda. > > Did you consider joining Python modules team [1] and maintainer these > packages there? > > [1] http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin > > Regards, Thanks for suggestion. I was wondering whether I should ask for sponsorship someone from nVidia packaging team or Python team. I think that my packages still need some work (e.g. lintian can find some issues to complain) but as soon as they are ready I will as at IRC for review. Best regards and thanks for helpful remark -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#546919: New version of python-pycuda packages
I have put new version of PyCUDA (and pytools) pacages: http://www.bogomips.w.tkb.pl/cuda.html#Debian http://www.bogomips.w.tkb.pl/cuda/ Now python-pycuda depends on python-pytools. python-pycuda still does not depend on nVidia CUDA toolkit - as soon as there is semi-final version of those packages I will add dependencies. Packages are signed with my GPG key. I tried to create private repository (so one could add appropriate lines to sources.list and use apt-get to install pycuda in Debian) but messed something with directories, so for now there is no repository with pycuda. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
