Bug#1061687: u-boot-menu: Prevents kernel installation/removal when removed without purging
Package: u-boot-menu Version: 4.2.3 Severity: normal X-Debbugs-Cc: serp...@debian.org I'm running MNT Reform, so using non-Debian kernel. The rest of packages are from Debian. When u-boot-menu is removed from system, but not purged (i.e. "apt remove u-boot-menu" is run), any subsequent installation or removal of kernel fails because of /etc/kernel/postinst.d/zz-u-boot-menu: /etc/kernel/postinst.d/zz-u-boot-menu: 5: .: cannot open /usr/share/u-boot-menu/read-config: No such file run-parts: /etc/kernel/postinst.d/zz-u-boot-menu exited with return code 2 dpkg: error processing package linux-image-6.6.13-reform2-arm64 (--configure): installed linux-image-6.6.13-reform2-arm64 package post-installation script subprocess returned error exit status 1 Basically apt remove leaves configuration files: /etc /etc/default /etc/default/u-boot /etc/kernel /etc/kernel/postinst.d /etc/kernel/postinst.d/zz-u-boot-menu /etc/kernel/postrm.d /etc/kernel/postrm.d/zz-u-boot-menu but zz-u-boot-menu at the very beginning wants to read /usr/share/u-boot-menu/read-config which is not in /etc - so deleted on removal. Purging u-boot-menu fixes problem. I'm not sure which solution would be better: a) Move required file from /usr/share to /etc (e.g. /etc/default?) b) leave it in /usr/share but mark as conffile. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 6.6.13-reform2-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages u-boot-menu depends on: ii linux-base 4.9 Versions of packages u-boot-menu recommends: ii rsync 3.2.7-1+b1 Versions of packages u-boot-menu suggests: ii flash-kernel 3.107+reform1
Bug#1052410: psycopg3: should maintainer/uploader be turned?
According to Python Team Policy https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst both forms are allowed: """ A package maintained within the team should have the name of the team either in the Maintainer field or in the Uploaders field. """ Please read full section "Maintainership" for deeper explanation. For now psycopg is still Work-In-Progress, e.g. binary module is not built because Debian does not contain Cython 3.0.0. Therefore I prefer to keep closer eye on package and chosen second option. Best regards. -- Tomasz Rybak, Debian Developer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C signature.asc Description: This is a digitally signed message part
Bug#1029182: Uploaded to DELAYED/3
I just fixed package (git diff in attachment) and uploaded pgcli 3.5.0-4.1 to DELAYED/3. Feel free to provide your own fix, or just we can just wait for a bit :-). Best regards. -- Tomasz Rybak, Debian Developer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C diff --git a/debian/changelog b/debian/changelog index e23fada..0c93a07 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +pgcli (3.5.0-4.1) sid; urgency=medium + + * Non-maintainer upload. + * Fix psycopg depends (Closes: #1029182). + + -- Tomasz Rybak Sat, 21 Jan 2023 01:24:45 +0100 + pgcli (3.5.0-4) sid; urgency=medium * Uploading to sid. diff --git a/debian/control b/debian/control index c414842..9cc1f84 100644 --- a/debian/control +++ b/debian/control @@ -25,7 +25,7 @@ Depends: python3-pgspecial (>= 2), python3-pkg-resources, python3-prompt-toolkit (>= 3.0), - python3-psycopg | python3-psycopg3 (>= 3.0.14), + python3-psycopg, python3-sqlparse (>= 0.3), python3-tabulate, python3-terminaltables, signature.asc Description: This is a digitally signed message part
Bug#1029182: Just rebuild with psycopg 3.1.7-4
I noticed this bug, and similar for python-pgspecial. You can fix it by rebuilding with python3-psycopg 3.1.7-4, like I've just done with python-pgspecial. Long story short - dh_python3 has hardcoded mapping of psycopg to python3-psycopg3, and this is added to binary dependencies via python3:Depends; you can find details in https://lists.debian.org/debian-python/2023/01/msg00051.html I added pydist override to psycopg 3.1.7-4. I also experimented a bit with rebuilding pgcli; you could replace line 28 of debian/control python3-psycopg | python3-psycopg3 (>= 3.0.14) with python3-psycopg, (see attached diff file) and it'll generate proper dependency on python3-psycopg (>= 3.0.14). Full dependency after this change looks like: Depends: python3-cli-helpers, python3-pendulum, python3-pgspecial (>= 2), python3-pkg-resources, python3-prompt-toolkit (>= 3.0), python3- psycopg (>= 3.0.14), python3-sqlparse (>= 0.3), python3-tabulate, python3-terminaltables, python3-click, python3-configobj, python3- pygments, python3-setproctitle, python3:any Best regards. -- Tomasz Rybak, Debian Developer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C diff --git a/debian/control b/debian/control index c414842..9cc1f84 100644 --- a/debian/control +++ b/debian/control @@ -25,7 +25,7 @@ Depends: python3-pgspecial (>= 2), python3-pkg-resources, python3-prompt-toolkit (>= 3.0), - python3-psycopg | python3-psycopg3 (>= 3.0.14), + python3-psycopg, python3-sqlparse (>= 0.3), python3-tabulate, python3-terminaltables, signature.asc Description: This is a digitally signed message part
Bug#1021249: new upstream version required
Thanks for working on package. At the same time I have few doubts related to your changes: 1. It looks like you took package as it is currently in archive (i.e. 3.0.1) and brough it up to new version. Is this correct? I haven't noticed neither new commits nor merge requests. Package is maitained inside Python Team (the same as for psycopg2) under https://salsa.debian.org/python-team/packages/psycopg3 and therefore should follow Team's Policy https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst , including usage of git-buildpackageworkflow. Repository contains yet-unreleased changes, including update to 3.0.14 (yeah, currently quite old), updates to debian/copyright (especially for new modules and files), other fixes to metadata (05f60589535f3bc6ccb479c832500b24a4280b7c and 35559675c2d2225041faacf3f7c922a65858c91d), and ones proposed by Janitor. While I don't mind other DDs working on package and uploading new versions and even welcome that (that's why it's team-maintained), please do it taking already-existing changes into consideration, and following Team's policy. 2. Have you fully built package, including binary documentation *.deb? I had problems with that after upgrading to 3.0.14; building documentation required network access - therefore my patches and this is the main reason of delay with uploading 3.0.14. If you succeeded, this might mean that older version had some problems which were fixed in 3.1.2. Best regards On Wed, 2022-10-05 at 15:19 +0200, Daniel Baumann wrote: > > Hi, > > > > I've took the liberty to upload a NMU to delayed 5, diff is attached: > > > > * If you're ok with the diff, I would be happy to cancel it and upload > > directly to unstable. > > * If you're not ok with the diff, I'm happy to cancel the upload and > > let you do it. > > > > Regards, > > Daniel -- Tomasz Rybak, Debian Developer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C -- Tomasz Rybak, Debian Developer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C signature.asc Description: This is a digitally signed message part
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#914804: Should we close it?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello. Should we close this bug? CUDA 9.2.148-5 is in unstable and testing - with proper libcuda1 dependency (if I understood changelog and control correctly). BTW - PyCUDA (built for CUDA 9.1) migrated to testing. Should I rebuild it with CUDA 9.2 and upload? Best regards. - -- Tomasz Rybak, Debian Developer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE1bhtbqZEgXjcK9cyggqgxGY3jWkFAlxHki0ACgkQggqgxGY3 jWnI0xAAgJV8BgKGLOCF/2SnTfu/BVmje09ntxaJE0EbzSvQCpHY1U823J6qBWHF qsOwJyNYCbR4rPXQ5zm/UNhW1J8SN8eJRFFRFUEF9Pv5dR/ktaYcJrPCuT+B3Z22 YYI0QZRol4o4BMeDxB3wq1MzRW/U8/evkaqr9D98DgQ3rv7q42f6wHmHrG+4TG09 treKyxV1MLeETB8vttcA2QWuvNL+JDCiaIWP07vlPHVGM0WjXvUYrCJ6PosiY1RR jXsVeLnK/LcicjWLqIqmourTwwxdSynapgv/FjT2KONTfRcY962mCAhPEJqclL71 bPeMTyQXVldjzl98HN6Yn7bcKWjHWShU74mFZggTDLiMYQWJQAkhq5XF1eOKO0vQ puF87A9IEuSr0FXV1cZCxZRwxCSAAUMxM6ss2JE9MQDlgBDaaYTQFL4+Xtv/mI79 /W4fUCBTo1DmJOvEG9HLEhBWsSTN/5C2dVeCuArz+W3GKKmY0SCuvsXGG5eh6Utb eInd/VSKXB62zYP5Ikuu9k+m/jqOrhYnVhNmBLJn+n1UDBJdpjDLAJL5QFbWGwTD xZt1xeBwoCY3X1S1jBLwNgLMFzH8fbUBLyyY/uOCVYnUBWWxbgjSYs8E3sTEOW5N NvoOQ0G0j+Lh987BSSCtZRIWoUvH9y28Gz6zgzHiQNKtngj03jE= =XKOF -END PGP SIGNATURE-
Bug#909497: CUDA 10 available now
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2019-01-09 at 00:27 +0100, Andreas Beckmann wrote: [ cut ] > I'll do binNMUs tomorrow (but I'll wait for pycuda to migrate to > testing > first). According to https://tracker.debian.org/pkg/pycuda PyCUDA is stuck behind numpy, which is stuck because of autopkgtest failures: https://tracker.debian.org/pkg/python-numpy There is thread on debian-python@ ML https://lists.debian.org/debian-python/2019/01/msg5.html but no definite solution has been found yet. So don't wait for PyCUDA migration with binNMUs. Best regards. - -- Tomasz Rybak, Debian Developer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE1bhtbqZEgXjcK9cyggqgxGY3jWkFAlw29Y8ACgkQggqgxGY3 jWnDMQ//eikSo/XCBh+VSql67QqmsWMg2jXk+ZlvTqmGjqJ+iuEdzA/NWm5LMQNY N6Dvr9X3dbg/lf9a6bz6/9IADDGJYjZzXm9d4/2CmKiZE91tIOAzYowxCnd5WyEu whwXviFXAudWaD1KEFMW4xmI9/1K8QNoXtvxaAcbUZVq9IytrJL/0qPBM65yOafk +b8oe3mZNlosc2wccwpKipkDdubW+jJz/hxSXerUeXq7ojpAIdXhinXEx+j3xafU 3t/IvId4Oa+KwI3gEiNYOjvc12AbVyUXQYLrc0CEtmIDxigb52QP2TTDs85wMykZ 4dlNXAnjB3s4Qa0ith3XD96pEK68vOfrCnaoKLDelMTQEPrxepsf7n2AwQmtIjmR HVUID57h3uxk4RX+bpZ5zDCmhkuvDDCDY9tRNk8ZERTnr/VKrhoGSWZYrhkQFm8j WTsvsUPeRAXA0kBST+ytemIDHy7ntQ9wmTZLf7eXf2f18pj9kGs08N5B8zy+Vyn3 NzWRRjOHwF6yau9PE7q6zfVE5JRWIgxiJ/CCgz+GOALRQ72icr1+i5t/TlxBTIa+ GibfDqF9AxRuDGTR8L5fZ+BvrX3tNxSVwEdhYFmoTpx1pjeDEqxPlSHGGBL/Mhqu xSA8BRQf5mS+GULB06B2AMNoH5pznzjVPD+YswcwlgOT2Z1nwPU= =jJnn -END PGP SIGNATURE-
Bug#909379: Debug is broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I've checked it a bit more and there is new problem with debug packages: $ python3.6-dbg -c 'import pyopencl' Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/pyopencl/__init__.py", line 37, in import pyopencl._cl as _cl ImportError: /usr/lib/python3/dist-packages/pyopencl/_cl.cpython-36dm- x86_64-linux-gnu.so: undefined symbol: PyModule_Create2 $ python3.7-dbg -c 'import pyopencl' Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/pyopencl/__init__.py", line 37, in import pyopencl._cl as _cl ImportError: /usr/lib/python3/dist-packages/pyopencl/_cl.cpython-37dm- x86_64-linux-gnu.so: undefined symbol: PyModule_Create2 $ python3.7 -c 'import pyopencl' $ python-dbg -c 'import pyopencl' Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/pyopencl/__init__.py", line 37, in import pyopencl._cl as _cl ImportError: /usr/lib/python2.7/dist-packages/pyopencl/_cl.x86_64-linux- gnu_d.so: undefined symbol: Py_InitModule4_64 So PyOpenCL works with Python3.7 right now, but debug symbols do not work at all (neither for Python 3, nor for Python 2.7). It might be related to move to pybind. At the same time I found some information suggesting that debug packages need to be compiled differently. It's either deliberate Python behavior https://bugs.python.org/issue5735 "Python compiled with --with-pydebug throws an ImportError when trying to import modules compiled without --with-pydebug, as it should" or some strange gcc error https://riverbankcomputing.com/pipermail/pyqt/2014-July/034561.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755767 I'll need to investigate. If somebody has any idea, please let me know. - -- Tomasz Rybak, Debian Developer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE1bhtbqZEgXjcK9cyggqgxGY3jWkFAlwFs5UACgkQggqgxGY3 jWlShBAAtQRtwQ+6xgf1ZfUudV/DFe5xrdYy8LtvpO9BKs8rlzx71npB661QLm05 RMvjIiZkfdvO/52ENxt6O73NHyEWmaI+L43PZNdI2lIopVKObV86oLQVRmCAr4Id M4alfawHnLWTX8T7pXwOjPSwClxZ6aUOrwSdAPRFlQqEuS9A4A83z99hH8QCB8hC JlDVwwnM29N5WRmSt6VFhkUQ1Df/SmxEnfGOL4xLdRA4bYOyE92TC7BGstxW0dyJ evO/AXd4SytvvRnax08LgisfXKsyu5x24baiNKFcyuzFdGM4YdTQXfXKBSZRiiuO pt7uZvyx7dlcMlZeQ3dmFUiYQaS5Q9NM/bi15eBdOXQ7L0jhR1aq3vA9isMM9MXS q3O1OWCJqUOr7ojyGj2grj2iXwaNZgVSKN3RZlk2YeV3XybMnw89T7oxbhf0Dyk3 0TDPtWcCKWOl6SOPK4q5crxDIDE0nl1VHzSmy3j97Jt9sYgjPrY0ad7tdJ4OxOfF GlcoRlK4kJq3KZKSGwcK1DUKq20RPs/d7Uik8aj7ONw40z48OVerON8gNi+ZvicJ DjJCPevGFB4Fh3tLSp5tCZGfLxhrGf8LAKaqTiO5HjtfgN5M1fL5//LvJnLRziaz qpc4BAIpydyc32p6wIk80SrdDXVLyaE9QIWPKfIpKlajAXT6rsA= =EOfv -END PGP SIGNATURE-
Bug#909379: Does is still occur?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Does this error still occur with PyOpenCL 2018.2.1-1? It was rebuilt with Python 3.7 interpreter and has correct debugging symbols for both Python 3.6 and 3.7. If it cannot be reproduced, please close it. - -- Tomasz Rybak, Debian Developer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE1bhtbqZEgXjcK9cyggqgxGY3jWkFAlwFomsACgkQggqgxGY3 jWksdg/8DZDJeiI8AjSExnwbZSqSNOVX5yY3JFK8+S+IvLZhXm3vliiA3Et4XTR6 ITj2iHc+tlfd1k9ymBEeNIVnBd6qVzpvpZoUCsvkNRZujjGM1aSaxNScQ7NGWwsv ZNrFjjD0j8u0fzeDuS4/efwI7q+QvCvBhLfOnBZNXeX5vJYQfEx3roeDYJbBtEcg PK/b9XCuVoHUsUl+4gSKws1ybUeNjVJFmgNmNbPYPF7G0J5iKGNdC+2LOgxwuSHP Bzgmph3pIIVGZexPlqwnTkkwPhsC0yRYJ/bDzDv4bruWL54ALPAuQufYiN01+S13 /mgiKlulpD3bXTzN/sGJMbN/ZssaGca0OLA9Lm8I8QSMWgn64hlQ6kg05Xbtux67 57bKb80oitEDW1KHdmI6gy6+V7t1x5Hl6jOLtwcoDvUJsqdfvdzk8bxR4JghJ9hR CQ/VBgQPmwwn75PIelzKfam2hW/iw3cdIglWNQszdI0wbT0XUKCCkKGfddhgM3zb 7V0KsK35/y2H1+reAVoJQLzhiSnfuJPSx0LvPKDwlp9fOVBt716GYXylKk5FVRMM i1PgcBCXdxH2Q0Msmr2V7mGru4lILjju8MXS3wKCtWu2ECpsiK8ON/6Vk4fdK9/q 098F5uFl8NPTHVWL1pqTLaTUkuUJ/5RSh+2euJtdvZp5sGG1U04= =p8WY -END PGP SIGNATURE-
Bug#909379: [Pkg-opencl-devel] Bug#909379: Bug#909379: Info received (Bug#909379: segfault when leaving the python3-dbg interpreter)
IFAIR PyOpenCL was never built against Python3.7. dpkg -L python3-pyopecl and dpkg -L python3-pyopencl-dbg show only files related to Python3.6. I started working on update of package (and pushed changes to git repository) but haven't yet uploaded new version. compat 11 scripts mess a bit with -doc package and naming of .so files for Python3.6 and 3.7. Besides - upstream changed Python/C binding from cffi to pybind11; I haven't looked into it yet. Feel free to do NMU, but be careful with current git version (-3). As my subkeys expired at the end of August and debian-keyring hasn't been uploaded since end of July, I cannot upload packages myself. -- Tomasz Rybak, Debian Developer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C signature.asc Description: This is a digitally signed message part
Bug#880581: Information received
Hello. I received this report. I'm travelling and away from my main machine right now so the next weekend (2017-11-11) will be the earliest I'll be able to look into it - but most probably it'll be the week after. Best regards. -- Tomasz Rybak, Debian Maintainer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C signature.asc Description: This is a digitally signed message part
Bug#880559: Information received
Hello. I received this report. I'm travelling and away from my main machine right now so the next weekend (2017-11-11) will be the earliest I'll be able to look into it - but most probably it'll be the week after. Best regards. -- Tomasz Rybak, Debian Maintainer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C signature.asc Description: This is a digitally signed message part
Bug#880583: Information received
Hello. I received this report. I'm travelling and away from my main machine right now so the next weekend (2017-11-11) will be the earliest I'll be able to look into it - but most probably it'll be the week after. Best regards. -- Tomasz Rybak, Debian Maintainer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C signature.asc Description: This is a digitally signed message part
Bug#846195: RM: pyopencl [mips64el] -- NVIU; Missing dependencies
Package: ftp.debian.org Severity: normal Please remove pyopencl 2016.1+git20161003-1 for architecture mips64el. I uploaded 2016.1+git20161003-1 build for many architectures to close #800634, but mips64el does not have Required OpenCL ICD as a result of recent upload of pocl. Not PyOpenCL cannot migrate from unstable to testing. I uploaded 2016.1+git20161003-2 without mips64el, but package still cannot migrate - now because of missing architecture. Thanks.
Bug#819448: Is this still relevant?
Some time ago I've uploaded new version of PyOpenCL. Does this problem still occur with the version currently in unstable and testing? If it is fixed, please close this issue. If not, please also let me know. Best regards. -- Tomasz Rybak, Debian Maintainer <tomasz.ry...@post.pl> GPG: A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak
Bug#800634: New architectures in experimental
Some time ago I uploaded into experimental PyOpenCL with many architectures enabled. Is this version working for you? If so, I'd gladly upload such PyOpenCL into unstable. Best regards. -- Tomasz Rybak, Debian Maintainer <tomasz.ry...@post.pl> GPG: A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak
Bug#819448: Is this fixed by new version?
Hello. I've just uploaded new version of PyOpenCL to unstable. Can you check whether this issue is still present with new version? Thanks in advance. -- Tomasz Rybak, Debian Maintainer <tomasz.ry...@post.pl> GPG: A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak
Bug#800634: [Pkg-opencl-devel] OpenCL architectures
On Mon, 2016-07-04 at 10:16 +0200, Tomasz Rybak wrote: > This is repost - I've sent this mail last week, but it seems to > disappear. > > There is bug against PyOpenCL to build it for more architectures (in > CC): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800634 > Thanks for all the comments. It tooks some time but I resumed work on PyOpenCL package and uploaded new version with many architectures to experimental. Please test it. BTW - I also intend to upload PyCUDA with armhf to experimental, but need to work on cross-compilation of it. Best regards. -- Tomasz Rybak, Debian Maintainer <tomasz.ry...@post.pl> GPG: A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak
Bug#819448: Steps to reproduce
Hello. Have you found any code that would allow to reproduce this issue? I was not able to get such behavior. Your trace would suggest that this is related to some OpenCL objects keeping references to other objects - or not checking when those objects are None. I intend to upload new PyOpenCL version soon (hopefully next week). It'd be great if you could check this issue with new version. There is already one issue fixed in upstream repository (#826025), maybe this one is also fixed. Best regards. -- Tomasz Rybak, Debian Maintainer <tomasz.ry...@post.pl> GPG: A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak
Bug#800634: [Pkg-opencl-devel] OpenCL architectures
Dnia 2016-07-05 08:08 Andreas Beckmann napisał(a): >On 2016-07-04 10:16, Tomasz Rybak wrote: >> I've checked status of available ICD providers, and: >> * PyOpenCL is built for amd64 and i386 >> * Pocl is built for amd64, i386, kfreebsd-amd64, mips64el, powerpcspe >with the last upload (and the switch to llvm 3.8) this list is down to >amd64, i386 :-( >and powerpcspe was probably only "succcessful" due to using >DEB_BUILD_OPTIONS=nocheck > >> * Beignet is built for amd64, i386, kfreebsd-amd64, and kfreebsd-i386 >> * Mesa is built for amd64, i386, and armhf >> * NVIDIA is built for amd64 and ppc64el >and i386 Sorry - I was assuming that dropping support for i386 in CUDA meant that also OpenCL is dropped - but it's not the case. > >> ocl-icd-libopencl1 is available for all architectures but I assume >> this is done to allof for experimenting with new OpenCL providers. >> >> I'd like to deal with this bug. I could change architecture to "any" >> but this would mean that PyOpenCL is build for architectures for which >> there is no ICD available. I can also put union of all mentioned >> architectures: >> Architecture: amd64 i386 kfreebsd-amd64 kfreebsd-i386 armhf ppc64el mips64el >> powerpcspe >> It seems a bit overkill, but doable. >> >> Which should I choose? I'm leaning towards second option, i.e. listing >> all architectures by hand. > >depends a bit on the role of pyopencl - if it is similar to libopencl1, >the "any" might do. Otherwise it would be nice to have tests run at >build time ... and since that wont work in many cases due to hardware >requirements, before adding a new architecture pyopencl should have been >veryfied to work correctly against the available (proprietary) ICDs. > I see PyOpenCL as library to run OpenCL programs - so just "any" wont fit it. Both PyCUDA and PyOpenCL contain tests - I just don't run them automatically during build time to prevent building on buildd from failing. How do you (members of this group) test OpenCL packages? Do you have special hardware, or is there something available that I could use? I mean - I'd like to enable armhf and pps64el (from NVIDIA ICD) but don't want to upload package without at least running test on this architecture. Best regards. -- Tomasz Rybak, Debian Maintainer
Bug#769293: Kernel caching by PyOpenCL
When this bug was reported, PyOpenCL was caching compiled kernels in /tmp/pyopencl-*. Now it is caching them in ~/.cache/pyopencl/ - so reset might not help. At the same time it should be possible to check whether value of OCL_STRICT_CONFORMANCE changed and do not use cached kernel. Is OCL_STRICT_CONFORMANCE the only variable influencing kernels, or are there other similar settings? Also - what do you mean by "... or load a newly-installed beignet version"? If new version creates new (different) kernels, they should not be in the cache. If it uses old kernels - they are cached, but their behaviour should be the same. Or am I missing something here? Best regards Tomasz Rybak
Bug#800634: OpenCL architectures
This is repost - I've sent this mail last week, but it seems to disappear. There is bug against PyOpenCL to build it for more architectures (in CC): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800634 I've checked status of available ICD providers, and: * PyOpenCL is built for amd64 and i386 * Pocl is built for amd64, i386, kfreebsd-amd64, mips64el, powerpcspe * Beignet is built for amd64, i386, kfreebsd-amd64, and kfreebsd-i386 * Mesa is built for amd64, i386, and armhf * NVIDIA is built for amd64 and ppc64el ocl-icd-libopencl1 is available for all architectures but I assume this is done to allof for experimenting with new OpenCL providers. I'd like to deal with this bug. I could change architecture to "any" but this would mean that PyOpenCL is build for architectures for which there is no ICD available. I can also put union of all mentioned architectures: Architecture: amd64 i386 kfreebsd-amd64 kfreebsd-i386 armhf ppc64el mips64el powerpcspe It seems a bit overkill, but doable. Which should I choose? I'm leaning towards second option, i.e. listing all architectures by hand. Best regards. Tomasz Rybak
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 <ales...@debian.org> > > * 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ý" <n...@ondrej.org> > > * 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#798999: transition: python3.5 supported
Dnia 2015-10-02, pią o godzinie 00:55 -0400, Scott Kitterman pisze: > > On September 29, 2015 3:59:01 PM EDT, Tomasz Rybak < > tomasz.ry...@post.pl> wrote: > > Dnia 2015-09-27, nie o godzinie 10:28 -0400, Scott Kitterman pisze: > > [ cut ] > > > Yes. They have started. I think we're about a third of the way > > > through Dependency level 1. Numpy is in Dependency level 5, so > > > this > > > is not unexpected for now. You can follow the progress in the > > > transition tracker [1]. > > > > > > > Can I ask to not automatically rebuild PyOpenCL? > > I'll rebuild and upload it myself, with few fixes. > > > Now would be a good time for you to go ahead. Sorry for the mess. I have problems with building new upstream version with additional changes, and I will not be able to put enough time to fix it till at least this weekend. If that's to long, can you put current PyOpenCL version for rebuild? It works on Python 3.5 without problems. I'll resume working on new PyOpenCL as soon as I have time. 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#798999: transition: python3.5 supported
Dnia 2015-09-27, nie o godzinie 10:28 -0400, Scott Kitterman pisze: [ cut ] > Yes. They have started. I think we're about a third of the way > through Dependency level 1. Numpy is in Dependency level 5, so this > is not unexpected for now. You can follow the progress in the > transition tracker [1]. > Can I ask to not automatically rebuild PyOpenCL? I'll rebuild and upload it myself, with few fixes. 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#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 ba...@debian.org * 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#771439: unblock: pyopencl/2014.1-3
Subject: unblock: pyopencl/2014.1-3
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Please unblock package pyopencl
2014.1-3 fixes security bug #770698, improper handling of
cache directory,
diff -Nru pyopencl-2014.1/debian/changelog
pyopencl-2014.1/debian/changelog
--- pyopencl-2014.1/debian/changelog2014-10-04 20:43:13.0 +0200
+++ pyopencl-2014.1/debian/changelog2014-11-29 13:27:07.0 +0100
@@ -1,3 +1,11 @@
+pyopencl (2014.1-3) unstable; urgency=medium
+
+ * Add dependency to appdirs and use it to create cache directories
+(Closes: #770692).
+ * Update Standards-Version to 3.9.6; no changes necessary.
+
+ -- Tomasz Rybak tomasz.ry...@post.pl Sat, 29 Nov 2014 11:43:47
+0100
+
pyopencl (2014.1-2) unstable; urgency=medium
* Add build-time dependency on ocl-icd-opencl-dev (Closes: #761566).
diff -Nru pyopencl-2014.1/debian/control pyopencl-2014.1/debian/control
--- pyopencl-2014.1/debian/control 2014-10-04 20:43:13.0 +0200
+++ pyopencl-2014.1/debian/control 2014-11-29 13:27:07.0 +0100
@@ -19,7 +19,7 @@
python3-sphinx (= 1.0.7+dfsg),
python-pytools (= 2014.2),
python3-pytools
-Standards-Version: 3.9.5
+Standards-Version: 3.9.6
X-Python-Version: = 2.5
X-Python3-Version: = 3.3
Homepage: http://mathema.tician.de/software/pyopencl
@@ -32,6 +32,7 @@
ocl-icd-libopencl1 | libopencl1,
mesa-opencl-icd | beignet | opencl-icd,
python-pkg-resources,
+ python-appdirs,
python-numpy,
python-pytools (= 2014.2)
Recommends: python-pyopencl-doc,
@@ -92,6 +93,7 @@
ocl-icd-libopencl1 | libopencl1,
mesa-opencl-icd | beignet | opencl-icd,
python3-pkg-resources,
+ python3-appdirs,
python3-numpy,
python3-pytools (= 2014.2)
Recommends: python-pyopencl-doc,
diff -Nru pyopencl-2014.1/debian/patches/series
pyopencl-2014.1/debian/patches/series
--- pyopencl-2014.1/debian/patches/series 2014-10-04 20:43:13.0
+0200
+++ pyopencl-2014.1/debian/patches/series 2014-11-29 13:27:07.0
+0100
@@ -1,3 +1,4 @@
hardening.patch
python-versions.patch
fix-setup.patch
+use-appdirs.patch
diff -Nru pyopencl-2014.1/debian/patches/use-appdirs.patch
pyopencl-2014.1/debian/patches/use-appdirs.patch
--- pyopencl-2014.1/debian/patches/use-appdirs.patch1970-01-01
01:00:00.0 +0100
+++ pyopencl-2014.1/debian/patches/use-appdirs.patch2014-11-29
13:27:07.0 +0100
@@ -0,0 +1,43 @@
+Description: Change cache directory is created
+Origin: https://github.com/pyopencl/pyopencl/pull/68
+Forwarded: https://github.com/pyopencl/pyopencl/pull/68
+Appied-Upstream: https://github.com/pyopencl/pyopencl/pull/68
+Last-Update: 2014-11-29
+Index: pyopencl-2014.1/pyopencl/cache.py
+===
+--- pyopencl-2014.1.orig/pyopencl/cache.py
pyopencl-2014.1/pyopencl/cache.py
+@@ -337,16 +337,15 @@ def _create_built_program_from_source_ca
+ option_idx += 1
+
+ if cache_dir is None:
+-from tempfile import gettempdir
+-import getpass
+-cache_dir = join(gettempdir(),
+-pyopencl-compiler-cache-v2-uid%s-py%s % (
+-getpass.getuser(), ..join(str(i) for i in
sys.version_info)))
++import appdirs
++cache_dir = join(appdirs.user_cache_dir(pyopencl,
pyopencl),
++pyopencl-compiler-cache-v2-py%s % (
++..join(str(i) for i in sys.version_info),))
+
+ # {{{ ensure cache directory exists
+
+ try:
+-os.mkdir(cache_dir)
++os.makedirs(cache_dir)
+ except OSError, e:
+ from errno import EEXIST
+ if e.errno != EEXIST:
+Index: pyopencl-2014.1/setup.py
+===
+--- pyopencl-2014.1.orig/setup.py
pyopencl-2014.1/setup.py
+@@ -184,6 +184,7 @@ def main():
+ install_requires=[
+ pytools=2014.2,
+ decorator=3.2.0,
++appdirs=1.4.0,
+ # Mako=0.3.6,
+ ],
+
unblock pyopencl/2014.1-3
thanks
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
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#771459: unblock: pytools/2014.3-2
Subject: unblock: pytools/2014.3-2
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Please unblock package pytools
2014.3-2 contains fix for security bug similar to one
in PyOpenCL (#770692) and PyCUDA (#770689).
diff -Nru pytools-2014.3/debian/changelog
pytools-2014.3/debian/changelog
--- pytools-2014.3/debian/changelog 2014-08-24 16:21:26.0 +0200
+++ pytools-2014.3/debian/changelog 2014-11-29 20:18:34.0 +0100
@@ -1,3 +1,11 @@
+pytools (2014.3-2) unstable; urgency=medium
+
+ * Add dependency to appdirs and use it to create cache directories,
+similarly to fix in PyOpenCL and PyCUDA.
+ * Update Standards-Version to 3.9.6; no changes necessary.
+
+ -- Tomasz Rybak tomasz.ry...@post.pl Sat, 29 Nov 2014 20:06:12
+0100
+
pytools (2014.3-1) unstable; urgency=medium
* New upstream release.
diff -Nru pytools-2014.3/debian/control pytools-2014.3/debian/control
--- pytools-2014.3/debian/control 2014-08-24 16:21:26.0 +0200
+++ pytools-2014.3/debian/control 2014-11-29 20:18:34.0 +0100
@@ -11,7 +11,7 @@
python3-numpy,
python-decorator,
python3-decorator
-Standards-Version: 3.9.5
+Standards-Version: 3.9.6
X-Python-Version: = 2.5
X-Python3-Version: = 3.2
Homepage: http://mathema.tician.de/software/pytools
@@ -21,6 +21,7 @@
Package: python-pytools
Architecture: all
Depends: ${misc:Depends}, ${python:Depends},
+ python-appdirs,
python-numpy,
python-decorator
Description: big bag of things supplementing Python standard library
@@ -37,6 +38,7 @@
Package: python3-pytools
Architecture: all
Depends: ${misc:Depends}, ${python3:Depends},
+ python3-appdirs,
python3-numpy,
python3-decorator
Description: big bag of things supplementing Python 3 standard library
diff -Nru pytools-2014.3/debian/patches/series
pytools-2014.3/debian/patches/series
--- pytools-2014.3/debian/patches/series2014-08-24 16:21:26.0
+0200
+++ pytools-2014.3/debian/patches/series2014-11-29 20:18:34.0
+0100
@@ -1 +1,2 @@
remove-decorator.patch
+use-appdirs.patch
diff -Nru pytools-2014.3/debian/patches/use-appdirs.patch
pytools-2014.3/debian/patches/use-appdirs.patch
--- pytools-2014.3/debian/patches/use-appdirs.patch 1970-01-01
01:00:00.0 +0100
+++ pytools-2014.3/debian/patches/use-appdirs.patch 2014-11-29
20:18:34.0 +0100
@@ -0,0 +1,51 @@
+Description: Change cache directory is created
+Origin:
https://github.com/inducer/pytools/commit/eefea8e6012c3d94794f244a245d64bb69169331
+Forwarded:
https://github.com/inducer/pytools/commit/eefea8e6012c3d94794f244a245d64bb69169331
+Applied-Upstream:
https://github.com/inducer/pytools/commit/eefea8e6012c3d94794f244a245d64bb69169331
+Last-Update: 2014-11-29
+Index: pytools-2014.3/pytools/persistent_dict.py
+===
+--- pytools-2014.3.orig/pytools/persistent_dict.py
pytools-2014.3/pytools/persistent_dict.py
+@@ -238,13 +238,12 @@ class PersistentDict(object):
+
+ from os.path import join
+ if container_dir is None:
+-from tempfile import gettempdir
+-import getpass
+-container_dir = join(gettempdir(),
+-pytools-pdict-%s-uid%s-py%s % (
++import appdirs
++container_dir = join(
++appdirs.user_cache_dir(pytools, pytools),
++pdict-v2-%s-py%s % (
+ identifier,
+-getpass.getuser(),
+-..join(str(i) for i in sys.version_info)))
++..join(str(i) for i in sys.version_info),))
+
+ self.container_dir = container_dir
+
+@@ -254,7 +253,7 @@ class PersistentDict(object):
+ # {{{ ensure container directory exists
+
+ try:
+-os.mkdir(self.container_dir)
++os.makedirs(self.container_dir)
+ except OSError, e:
+ from errno import EEXIST
+ if e.errno != EEXIST:
+Index: pytools-2014.3/setup.py
+===
+--- pytools-2014.3.orig/setup.py
pytools-2014.3/setup.py
+@@ -43,7 +43,8 @@ setup(name=pytools,
+ ],
+
+ install_requires=[
+- decorator=3.2.0
++ decorator=3.2.0,
++ appdirs=1.4.0,
+ ],
+
+ author=Andreas Kloeckner,
unblock pytools/2014.3-2
thanks
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
Tomasz Rybak GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
Bug#757961: Does not work with GCC 4.9, default GCC in Jessie
Dnia 2014-08-21, czw o godzinie 15:13 +0200, Graham Inggs pisze: Just for reference, nvidia-cuda-toolkit 6.0.37 also prevents the use of gcc 4.8 in /usr/include/host_config.h and therefore needs the same patch. In fact, the only difference between /usr/include/host_config.h in 5.5.22 and 6.0.37 is that the version in 6.0.37 now allows ICC 13.1 instead of ICC 12.1. Tomasz: do you need this uploaded before you can upload pycuda 2014.1? Not necessarily. I'll build (and test) PyCUDA on my machine, then build amd64 and i386 packages in pbuilder. As building does not require running any kernels, but only presence of CUDA headers, it'll work without any problems. BTW - do you plan to upload 6.0, or 6.5 before Jessie freeze? If so, I'll need to rebuild PyCUDA with new CUDA. 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#757961: Does not work with GCC 4.9, default GCC in Jessie
Dnia 2014-08-14, czw o godzinie 12:01 +0200, Graham Inggs pisze: Hi Thomas I tried editing /usr/include/host_config.h as below to bypass the GCC version check. After this change, I was able to build all of the CUDA 5.5 SDK samples without error. Let me know if this works for you too and I will prepare a patch. Thanks. After this change PyCUDA works like a charm - all tests pass, both for Python 2 and Python 3. 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#757961: Does not work with GCC 4.9, default GCC in Jessie
Package: nvidia-cuda-toolkit Version: 5.5.22-4 Severity: important It looks like the CUDA 5.5 does not work with GCC 4.9: $ nvcc tmpTfIlUk.cu In file included from /usr/lib/nvidia-cuda-toolkit/include/cuda_runtime.h:59:0, from command-line:0: /usr/include/host_config.h:82:2: error: #error -- unsupported GNU version! gcc 4.9 and up are not supported! #error -- unsupported GNU version! gcc 4.9 and up are not supported! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/3 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nvidia-cuda-toolkit depends on: ii g++ 4:4.9.0-4 ii gcc 4:4.9.0-4 ii libc62.19-7 ii libgcc1 1:4.9.0-10 ii libnvvm2 5.5.22-4 ii libstdc++6 4.9.0-10 ii nvidia-cuda-dev 5.5.22-4 ii nvidia-profiler 5.5.22-4 ii ocl-icd-opencl-dev [opencl-dev] 2.1.3-4 Versions of packages nvidia-cuda-toolkit recommends: ii nvidia-cuda-doc 5.5.22-4 ii nvidia-cuda-gdb 5.5.22-4 ii nvidia-visual-profiler 5.5.22-4 Versions of packages nvidia-cuda-toolkit suggests: ii libcupti-dev 5.5.22-4 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755513: nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1
Why did nvidia-cuda-toolkit tried to install nvidia-opencl-dev when you had ocl-icd-libopencl1 installed? $ apt-cache show nvidia-cuda-toolkit Package: nvidia-cuda-toolkit Version: 5.5.22-4 Installed-Size: 44180 Maintainer: Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org Architecture: amd64 Depends: nvidia-profiler (= 5.5.22-4), nvidia-cuda-dev (= 5.5.22-4), nvidia-opencl-dev (= 5.5.22-4) | opencl-dev, gcc, g++, libc6 (= 2.3.4), libgcc1 (= 1:4.1.1), libnvvm2 (= 5.5), libstdc++6 (= 4.1.1) ocl-icd-opencl-dev depends on ocl-icd-libopencl1, and ocl-icd-libopencl1 conflicts with libopencl1, preventing other packages with libOpenCL.so from being installed. Can you provide what you were doing? I have situation similar to described by you (ocl-icd-opencl-dev and ocl-icd-libopencl1 and nvidia-cuda-toolkit) and did not have any troubles - I even prepare and test PyCUDA and PyOpenCL packages on such a setup. Best regards. Tomasz Rybak -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749428: pycuda: allow automatic sync into Ubuntu
Dnia 2014-06-08, nie o godzinie 14:20 +0200, Graham Inggs pisze: Thanks for the report. Where did you find dependency on libcuda1 in nvidia-cuda-toolkit? I was only able to find that nvidia-cuda-toolkit depends on nvidia-cuda-dev, which in turn recommends libcuda1, not depends on it. Sorry, I only saw your reply now when I received a notification about #749489 being closed. No problem. nvidia-cuda-toolkit - nvidia-cuda-dev - libcuinj64-5.5 - libcuda1 nvidia-cuda-toolkit - nvidia-profiler - libcuda1 Thanks for information. I've tagged this bug as pending; I'll probably upload fix for it when uploading PyCUDA 2014.1. I have also suggested to the maintainer of nvidia-cuda-toolkit to upgrade the recommends on libcuda1 to a depends, so in future you can rely on it being there, no matter what happens to libcuinj64-5.5 and nvidia-profiler. I've checked and libcudart5.5 also depends on libcuda. libcudart is rather basic package so it should not go away... -- 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#749428: pycuda: allow automatic sync into Ubuntu
Thanks for the report. Where did you find dependency on libcuda1 in nvidia-cuda-toolkit? I was only able to find that nvidia-cuda-toolkit depends on nvidia-cuda-dev, which in turn recommends libcuda1, not depends on 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#745456: create_some_context() can fail if multiple ICDs installed
Thanks for the patch. I'll first upload fixed PyOpenCL to main, and then work on it. Probably I'll first want to have some discussion on mailing list - as I do not use GPGPUs now, I'd like to have opinion of users of PyOpenCL before introducing such a change. 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#743374: Clarification about libopencl dependencies
PyOpenCL formally depends on libopencl1 and opencl-icd. The former is responsible for managing OpenCL providers, the latter is particular OpenCL implementation. As I wrote in README for PyOpenCL, you can have as many opencl-icd-providing packages as you want, and only one libopencl1. While I would recommend installib ocl-icd-libopencl1 (free package), I do not want to force its installation in case someone wants to install other OpenCL-managing library. As for versions - NVIDIA currently seems hostile to OpenCL. They do not provide OpenCL 1.2 implementation. Not wanting to punish users of other OpenCL providers by forcing them to use OpenCL 1.1 I build PyOpenCL with ocl-icd-libopencl1, thus requiring usage of ocl-icd-libopencl1 or amd-icd-libopencl1. As this is not a bug, I intend to close it in a week, if noone objects. At the same time, if there is something I, as the packager, can do to tell users about this situation (besides providing README.Debian), please let me know. -- 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#743374: #743374: not a bug (libopencl1 isn't hardware specific)
Dnia 2014-04-21, pon o godzinie 10:24 +0100, Russel Winder pisze: Rebecca, Thanks for this, most helpful. On Sat, 2014-04-19 at 20:34 +0100, Rebecca N. Palmer wrote: nvidia-libopencl1 is OpenCL 1.1, not 1.2, and pyopencl hence doesn't work with it: https://bugs.launchpad.net/ubuntu/+source/pyopencl/+bug/1174205 OK, I purged this package and various others went with it. (But some came back…) You can still use pyopencl with Nvidia hardware, as the hardware-specific part is opencl-icd not libopencl1. The choices for this are: nvidia-opencl-icd (Nvidia GPUs) mesa-opencl-icd (Radeon GPUs; plans to support more in the future) amd-opencl-icd (Radeon GPUs, and CPUs) amd-opencl-icd-legacy (older Radeon GPUs) beignet (Intel GPUs) At present it is necessary to choose the correct opencl-icd manually, as the package management system doesn't know what GPU you have, and installing them all doesn't work as beignet crashes if its hardware is not present. If I try to install python3-pyopencl Aptitude tries to install the AMD package. But as you hint, by installing the nvidia-opencl-icd package manually first it pulls in various NVIDIA bits that were purged a few moments earlier, but then allows python3-pyopencl to install fine. nvidia-opencl-icd depends on other NVIDIA-related libraries, e.g. for compiling OpenCL code. -- 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#723132: please prioritise...
Dnia 2014-02-18, wto o godzinie 11:36 +1100, Dmitry Smirnov pisze: On Mon, 17 Feb 2014 21:18:47 Tomasz Rybak wrote: Would it be OK to upload to main without running tests from package (from test/*) on Beignet? IMHO yes, it should be OK since Beignet declared OpenCL support. If it doesn't work it would qualify for bug report wouldn't it? ;) When Mesa/OpenCL will become available it will provide additional justification for main disregarding of whether it is production ready or not. I'll update package during the weekend, and fix #739173 and #739176. As package will need to go through NEW queue, will you sponsor it? I'm DM so I need DD to sponsor large changes in packaging. 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#723132: please prioritise...
Dnia 2014-02-16, nie o godzinie 12:01 +1100, Dmitry Smirnov pisze: Could this be prioritised please? The reason is #739078 where another package from main got serious bug for Recommending python-pyopencl because the latter is in contrib... Thanks. I do not have access to Ivy Bridge GPU to test PyOpenCL on it. I run test on both NVIDIA and AMD hardware before each upload. Would it be OK to upload to main without running tests from package (from test/*) on Beignet? 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#730263: pycuda: needs to be rebuilt against nvidia-cuda-toolkit 5.5
I have tested PyCUDA with CUDA 5.5 and it worked without problems. I'll look into whether to add some newer stuff from upstream git repository or not during upload, as there were some fixes in upstream. The new version should be in unstable before the next weekend. 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#725649: nvcc fatal : Path to libdevice library not specified
Dnia 2013-10-10, czw o godzinie 23:30 +0200, Andreas Beckmann pisze: On 2013-10-08 19:11, Tomasz Rybak wrote: It seems error lies with nvidia-cuda-toolkit. I've downloaded and tried to compile NVIDIA examples and got: $ make make[1]: Wejście do katalogu to get English output use LC_ALL=C make in the future, no need to rerun it this time so PyCUDA is just victim of this error. PyOpenCL works without problems so it seems that fault lies with nvcc, not with libraries responsible for compilation of kernels. There is probably some setting missing in /etc/nvcc.* (has the upstream config file some new entries in 5.5 that I forgot to add to the Debian customized one?) You were right. There is new entry NVVMIR_LIBRARY_DIR = $(TOP)/nvvm/libdevice after adding line NVVMIR_LIBRARY_DIR = /usr/lib/nvidia-cuda-toolkit/libdevice to nvcc.profile PyCUDA works without any problems. How can I easily reproduce the problem? BTW - please add Conflicts: libcuinj64-5.0 to libcuinj64-5.5, as both provide the same file which file? probably the .so link, so needs to have Breaks+Replaces libcuinj64.so: Selecting previously unselected package libcuinj64-5.0:amd64. (Reading database ... 720002 files and directories currently installed.) Unpacking libcuinj64-5.0:amd64 (from .../libcuinj64-5.0_5.0.35-7_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/libcuinj64-5.0_5.0.35-7_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libcuinj64.so', which is also in package libcuinj64-5.5:amd64 5.5.22-1 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#723793: Bug#723587: release.debian.org: Non-free file in PyOpenCL - new version upload to stable and oldstable
Dnia 2013-10-09, śro o godzinie 21:49 +0100, Adam D. Barratt pisze: Control: tags -1 + confirmed On Fri, 2013-10-04 at 18:10 +0200, Tomasz Rybak wrote: Dnia 2013-10-02, śro o godzinie 01:12 +0200, Cyril Brulebois pisze: Cyril Brulebois k...@debian.org (2013-09-23): The squeeze.diff one seems to have unrelated noise in patches, presumably because something refreshed them while you were preparing the diff? Having a targeted patched like the first one would be nice, so please follow up to 723...@bugs.debian.org with a cleaner debdiff. kind reminder: o-p-u NEW freeze is less than 2 weeks from now. Fixing this issue in a later point release is of course perfectly OK, I just thought I'd give you a heads-up. [...] I attach new patch with proposed changes. It only changes changelog, debian/rules (removal of offending file) and mentioned file. Please go ahead. Thanks, I've uploaded fixed package. I have one remaining question. After closing #723793 and #723587 the only remaining copies of offending file will be in snapshot.debian.org (for which I've filled appropriate bug) and in diffs attached to those bugs. Should I do something to remove those diffs, to avoid distributing parts of offending file as a bug report attachment? 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#725649: nvcc fatal : Path to libdevice library not specified
It seems error lies with nvidia-cuda-toolkit. I've downloaded and tried to compile NVIDIA examples and got: $ make make[1]: Wejście do katalogu `/home/tomus/Programs/CUDA/0_Simple/simpleCubemapTexture' /usr/bin/nvcc -ccbin g++ -I../../common/inc -m64-gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=\sm_35,compute_35\ -o simpleCubemapTexture.o -c simpleCubemapTexture.cu nvcc fatal : Path to libdevice library not specified make[1]: *** [simpleCubemapTexture.o] Błąd 255 make[1]: Opuszczenie katalogu `/home/tomus/Programs/CUDA/0_Simple/simpleCubemapTexture' make: *** [0_Simple/simpleCubemapTexture/Makefile.ph_build] Błąd 2 so PyCUDA is just victim of this error. PyOpenCL works without problems so it seems that fault lies with nvcc, not with libraries responsible for compilation of kernels. BTW - please add Conflicts: libcuinj64-5.0 to libcuinj64-5.5, as both provide the same file and I had to manually remove the former and unpack the latter during installation of CUDA 5.5 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#723793: Bug#723587: release.debian.org: Non-free file in PyOpenCL - new version upload to stable and oldstable
Dnia 2013-10-02, śro o godzinie 01:12 +0200, Cyril Brulebois pisze:
Hi again Tomasz,
Cyril Brulebois k...@debian.org (2013-09-23):
The squeeze.diff one seems to have unrelated noise in patches,
presumably because something refreshed them while you were preparing
the diff? Having a targeted patched like the first one would be nice,
so please follow up to 723...@bugs.debian.org with a cleaner debdiff.
kind reminder: o-p-u NEW freeze is less than 2 weeks from now. Fixing
this issue in a later point release is of course perfectly OK, I just
thought I'd give you a heads-up.
Thanks for the reminder.
I was aware of this, but other things, completely unrelated
to software worlds, took my time and energy.
I attach new patch with proposed changes. It only changes
changelog, debian/rules (removal of offending file)
and mentioned file.
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
diff -Nru pyopencl-0.92/debian/changelog pyopencl-0.92.dfsg/debian/changelog
--- pyopencl-0.92/debian/changelog 2010-11-11 23:10:57.0 +0100
+++ pyopencl-0.92.dfsg/debian/changelog 2013-10-04 18:00:49.0 +0200
@@ -1,3 +1,9 @@
+pyopencl (0.92.dfsg-1) oldstable; urgency=low
+
+ * Remove non-free file from examples (#722014, #723793).
+
+ -- Tomasz Rybak tomasz.ry...@post.pl Fri, 04 Oct 2013 17:54:19 +0200
+
pyopencl (0.92-1) unstable; urgency=high
* New upstream release
diff -Nru pyopencl-0.92/debian/rules pyopencl-0.92.dfsg/debian/rules
--- pyopencl-0.92/debian/rules 2010-11-11 13:30:27.0 +0100
+++ pyopencl-0.92.dfsg/debian/rules 2013-10-04 18:00:49.0 +0200
@@ -36,6 +36,7 @@
git clone $(GIT_URL) $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION)
cd $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION) git checkout $(GIT_REVISION)
rm -rf $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION)/.git $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION)/.gitignore $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION)/.gitmodules
+ rm -rf $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION)/examples/matrix-multiply.py
tar czf $(MODULE_NAME)_$(DEB_UPSTREAM_VERSION).orig.tar.gz $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION)
rm -rf $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION)
diff -Nru pyopencl-0.92/examples/matrix-multiply.py pyopencl-0.92.dfsg/examples/matrix-multiply.py
--- pyopencl-0.92/examples/matrix-multiply.py 2010-10-21 19:10:19.0 +0200
+++ pyopencl-0.92.dfsg/examples/matrix-multiply.py 1970-01-01 01:00:00.0 +0100
@@ -1,241 +0,0 @@
-# example provided by Eilif Muller
-
-from __future__ import division
-
-KERNEL_CODE =
-
-// Thread block size
-#define BLOCK_SIZE %(block_size)d
-
-// Matrix dimensions
-// (chosen as multiples of the thread block size for simplicity)
-#define WA %(w_a)d // Matrix A width
-#define HA %(h_a)d // Matrix A height
-#define WB %(w_b)d // Matrix B width
-#define HB WA // Matrix B height
-#define WC WB // Matrix C width
-#define HC HA // Matrix C height
-
-
-/*
- * Copyright 1993-2009 NVIDIA Corporation. All rights reserved.
- *
- * NVIDIA Corporation and its licensors retain all intellectual property and
- * proprietary rights in and to this software and related documentation.
- * Any use, reproduction, disclosure, or distribution of this software
- * and related documentation without an express license agreement from
- * NVIDIA Corporation is strictly prohibited.
- *
- * Please refer to the applicable NVIDIA end user license agreement (EULA)
- * associated with this source code for terms and conditions that govern
- * your use of this NVIDIA software.
- *
- */
-
-/* Matrix multiplication: C = A * B.
- * Device code.
- */
-
-#define AS(j, i) As[i + j * BLOCK_SIZE]
-#define BS(j, i) Bs[i + j * BLOCK_SIZE]
-
-
-//! Matrix multiplication on the device: C = A * B
-//! WA is A's width and WB is B's width
-
-__kernel __attribute__((reqd_work_group_size(BLOCK_SIZE,BLOCK_SIZE,1)))
-void
-matrixMul( __global float* C, __global float* A, __global float* B)
-{
-__local float As[BLOCK_SIZE*BLOCK_SIZE];
-__local float Bs[BLOCK_SIZE*BLOCK_SIZE];
-
-// Block index
-int bx = get_group_id(0);
-int by = get_group_id(1);
-
-// Thread index
-int tx = get_local_id(0);
-int ty = get_local_id(1);
-
-// Index of the first sub-matrix of A processed by the block
-int aBegin = WA * BLOCK_SIZE * by;
-
-// Index of the last sub-matrix of A processed by the block
-int aEnd = aBegin + WA - 1;
-
-// Step size used to iterate through the sub-matrices of A
-int aStep = BLOCK_SIZE;
-
-// Index of the first sub-matrix of B processed by the block
-int bBegin = BLOCK_SIZE * bx;
-
-// Step size used to iterate through the sub-matrices of B
-int bStep = BLOCK_SIZE * WB;
-
-// Csub is used to store the element
Bug#723587: release.debian.org: Non-free file in PyOpenCL - new version upload to stable and oldstable
Dnia 2013-09-24, wto o godzinie 23:34 +0100, Adam D. Barratt pisze: Control: tags -1 + pending On Mon, 2013-09-23 at 05:26 +0200, Cyril Brulebois wrote: Tomasz Rybak tomasz.ry...@post.pl (2013-09-17): After asking on debian-mentors I was advised that I should also upload DFSG-free versions of packages to stable and oldstable: http://lists.debian.org/debian-mentors/2013/09/msg00104.html I attach debdiffs of proposed changes - please review those. The wheezy.diff one seems OK, feel free to get that one sponsored. It was, and I've just flagged it for acceptance. Thank you very much. The changelog contains a reference to #722014 but does not close it for some reason; please ensure that the BTS metadata is fixed to indicate that the bug is fixed in this upload. I still have to upload fixed package to Squeeze - that's why I haven't closed #722014. At the same time I've sent information about fixing it in Wheezy. Best regards. Regards, Adam -- 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#723785: snapshot.debian.org: Non-free file in PyOpenCL doc packages
Package: snapshot.debian.org Severity: normal Hello. I received bug report #722014 pointing to non-free file in examples distributed with PyOpenCL. Licence for part of the code says: Copyright 1993-2009 NVIDIA Corporation. All rights reserved. NVIDIA Corporation and its licensors retain all intellectual property and proprietary rights in and to this software and related documentation. Any use, reproduction, disclosure, or distribution of this software and related documentation without an express license agreement from NVIDIA Corporation is strictly prohibited. . I've asked for advice on debian-mentors and got reply that I should report bug against snapshot and archive. I have filled bug asking release team to allow for upload of fixed versions into stable and oldstable (#723587) All versions up to and including 2013.1-1 contain this file. 0.92* contain this file in main package; versions 2012* and 2013* contain this file in python-pyopencl-doc package. Version from unstable is fixed and does not contain non-free file. I've updated informations about affected versions in #722014. Best regards. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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#723787: ftp.debian.org: Non-free file in PyOpenCL doc packages
Package: ftp.debian.org Severity: normal Hello. I received bug report #722014 pointing to non-free file in examples distributed with PyOpenCL. Licence for part of the code says: Copyright 1993-2009 NVIDIA Corporation. All rights reserved. NVIDIA Corporation and its licensors retain all intellectual property and proprietary rights in and to this software and related documentation. Any use, reproduction, disclosure, or distribution of this software and related documentation without an express license agreement from NVIDIA Corporation is strictly prohibited. . I've asked for advice on debian-mentors and got reply that I should report bug against snapshot and archive. I have filled bug asking release team to allow for upload of fixed versions into stable and oldstable (#723587) All versions up to and including 2013.1-1 contain this file. 0.92* contain this file in main package; versions 2012* and 2013* contain this file in python-pyopencl-doc package. Version from unstable is fixed and does not contain non-free file. I've updated informations about affected versions in #722014. 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#723587: release.debian.org: Non-free file in PyOpenCL - new version upload to stable and oldstable
Package: release.debian.org Severity: important Hello. I received bug report that my package python-pyopencl-doc contains non-free file in examples (#722014). Licence reads: Copyright NVIDIA. ALl rights reserved. NVIDIA Corporation and its licensors retain all intellectual property and proprietary rights in and to this software and related documentation. Any use, reproduction, disclosure, or distribution of this software and related documentation without an express license agreement from NVIDIA Corporation is strictly prohibited. I have checked and non-free file examples/matrix-multiply.py exists in all versions of PyOpenCL - in oldstable, stable, testing, and unstable. Upstream has been notified and removed this file from archive, and I'll soon upload fixed version to unstable. After asking on debian-mentors I was advised that I should also upload DFSG-free versions of packages to stable and oldstable: http://lists.debian.org/debian-mentors/2013/09/msg00104.html I attach debdiffs of proposed changes - please review those. I am DM, not DD, so I will need sponsor for those uploads. Best regards. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak diff -Nru pyopencl-0.92/debian/changelog pyopencl-0.92.dfsg/debian/changelog --- pyopencl-0.92/debian/changelog 2010-11-11 23:10:57.0 +0100 +++ pyopencl-0.92.dfsg/debian/changelog 2013-09-17 17:12:20.0 +0200 @@ -1,3 +1,9 @@ +pyopencl (0.92.dfsg-1) oldstable; urgency=low + + * Remove non-free file from examples (#722014). + + -- Tomasz Rybak tomasz.ry...@post.pl Tue, 17 Sep 2013 17:03:46 +0200 + pyopencl (0.92-1) unstable; urgency=high * New upstream release diff -Nru pyopencl-0.92/debian/patches/python-versions.patch pyopencl-0.92.dfsg/debian/patches/python-versions.patch --- pyopencl-0.92/debian/patches/python-versions.patch 2010-11-11 13:30:27.0 +0100 +++ pyopencl-0.92.dfsg/debian/patches/python-versions.patch 2013-09-17 17:12:20.0 +0200 @@ -4,11 +4,11 @@ Python version and include it into name of linked library. Forwarded: not-needed Author: Tomasz Rybak bogom...@post.pl -Last-Update: 2010-11-11 -Index: pyopencl-0.92/setup.py +Last-Update: 2010-06-19 +Index: pyopencl-0.92~beta+git20100618/setup.py === pyopencl-0.92.orig/setup.py 2010-11-11 13:22:42.0 +0100 -+++ pyopencl-0.92/setup.py 2010-11-11 13:22:55.0 +0100 +--- pyopencl-0.92~beta+git20100618.orig/setup.py 2010-06-19 20:30:40.0 +0200 pyopencl-0.92~beta+git20100618/setup.py 2010-06-19 20:31:07.0 +0200 @@ -42,6 +42,7 @@ def main(): @@ -17,7 +17,7 @@ from aksetup_helper import (hack_distutils, get_config, setup, NumpyExtension, set_up_shipped_boost_if_requested) -@@ -51,6 +52,7 @@ +@@ -53,6 +54,7 @@ EXTRA_OBJECTS, EXTRA_DEFINES = set_up_shipped_boost_if_requested(conf) LIBRARY_DIRS = conf[BOOST_LIB_DIR] diff -Nru pyopencl-0.92/debian/patches/replace-setuptools.patch pyopencl-0.92.dfsg/debian/patches/replace-setuptools.patch --- pyopencl-0.92/debian/patches/replace-setuptools.patch 2010-11-11 13:30:27.0 +0100 +++ pyopencl-0.92.dfsg/debian/patches/replace-setuptools.patch 2013-09-17 17:12:20.0 +0200 @@ -3,11 +3,11 @@ contains all necessary files and we avoid network traffic from build machine. Forwarded: not-needed Author: Tomasz Rybak bogom...@post.pl -Last-Update: 2010-11-11 -Index: pyopencl-0.92/MANIFEST.in +Last-Update: 2010-06-02 +Index: pyopencl-0.92~beta+git20100806/MANIFEST.in === pyopencl-0.92.orig/MANIFEST.in 2010-11-11 13:24:53.0 +0100 -+++ pyopencl-0.92/MANIFEST.in 2010-11-11 13:25:37.0 +0100 +--- pyopencl-0.92~beta+git20100806.orig/MANIFEST.in 2010-08-07 13:49:58.0 +0200 pyopencl-0.92~beta+git20100806/MANIFEST.in 2010-08-07 15:13:27.0 +0200 @@ -7,7 +7,6 @@ include doc/*.py include doc/source/conf.py @@ -16,10 +16,10 @@ include configure.py include Makefile.in include aksetup_helper.py -Index: pyopencl-0.92/aksetup_helper.py +Index: pyopencl-0.92~beta+git20100806/aksetup_helper.py === pyopencl-0.92.orig/aksetup_helper.py 2010-11-11 13:25:02.0 +0100 -+++ pyopencl-0.92/aksetup_helper.py 2010-11-11 13:25:37.0 +0100 +--- pyopencl-0.92~beta+git20100806.orig/aksetup_helper.py 2010-08-07 13:49:58.0 +0200 pyopencl-0.92~beta+git20100806
Bug#723132: Move OpenCL-using packages to main?
Dnia 2013-09-16, pon o godzinie 19:42 +0100, Rebecca N. Palmer pisze: Package: python-pyopencl Severity: wishlist Given that we now have a DFSG-free opencl-icd (beignet), should its reverse dependencies (pyopencl and libviennacl) now move to main? I've been thinking about it, but first I want to work a bit on PyOpenCL (e.g. add DEB_BUILD_OPTIONS, move it to pybuild). Besides, I have not been able to force beignet to work on any of my machines - I do not have Intel GPU so I was not able to test it. But moving PyOpenCL to main is definitely on my list of things to do. 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#722014: Non-FLOSS example
Hello everyone. This is not a coding email - more legal/license related one. I received bug report regarding PyOpenCL Debian package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722014 examples/matrix-multiply.py contains code marked Copyright NVIDIA, All rights reserved. As all packages in Debian main and contrib should contain only FLOSS (Debian Policy 2.2.2) I intend (as advised in mentioned bug report) to repackage PyOpenCL source tree removing this file. The question remains - does PyOpenCL have the right to discribute such a file? Mentioned license reads: * NVIDIA Corporation and its licensors retain all intellectual property and * proprietary rights in and to this software and related documentation. * Any use, reproduction, disclosure, or distribution of this software * and related documentation without an express license agreement from * NVIDIA Corporation is strictly prohibited. If not - maybe it would be better to remove this example from source tree? What about leaving it on the wiki? 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#717606: nvidia-libopencl1: symbol clRetainDevice, version OPENCL_1.2 not defined in file libOpenCL.so.1 with link time reference
Dnia 2013-07-24, śro o godzinie 22:32 +0200, Andreas Beckmann pisze: Control: affects -1 + pyopencl python-pyopencl python3-pyopencl On 2013-07-24 22:19, Tomasz Rybak wrote: Should this bug belong to PyOpenCL (this will also allow me to close it when I update PyOpenCL with Breaks: fix you proposed) or can it stay attached to nvidia-libopencl1? Don't add the Breaks right now, we are working on a better solution (that would probably just need a binNMU at the end) ... I'm going on vacations now so I'll not be able to work on this or upload new package. I'll be at DebConf though, so I should be able to work on this there. 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#717606: nvidia-libopencl1: symbol clRetainDevice, version OPENCL_1.2 not defined in file libOpenCL.so.1 with link time reference
Dnia 2013-07-24, śro o godzinie 14:00 +0200, Andreas Beckmann pisze: On 2013-07-23 21:51, Tomasz Rybak wrote: The problem is that nvidia-libopencl1 supports OpenCL 1.1, while all other support OpenCL 1.2. I could rebuild PyOpenCL for OpenCL 1.1 but it would prevent all users from using features present in OpenCL 1.2. Is there an easy way to switch PyOpenCl source between using 1.2 and 1.1 (even if 1.2 is available) to test Vincent's proposed .symbols modifications ? Yes, you can use CL_PRETEND_VERSION=1.1 option during building. Should this bug belong to PyOpenCL (this will also allow me to close it when I update PyOpenCL with Breaks: fix you proposed) or can it stay attached to nvidia-libopencl1? 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#717606: nvidia-libopencl1: symbol clRetainDevice, version OPENCL_1.2 not defined in file libOpenCL.so.1 with link time reference
Dnia 2013-07-23, wto o godzinie 01:51 +0100, Noel David Torres Taño pisze: On Martes, 23 de julio de 2013 00:13:55 Andreas Beckmann wrote: On 2013-07-23 00:03, Noel David Torres Taño wrote: ImportError: /usr/lib/python2.7/dist-packages/pyopencl/_cl.so: symbol clRetainDevice, version OPENCL_1.2 not defined in file libOpenCL.so.1 with link time reference Please install icl-icd-libopencl1 instead of nvidia-libopencl1 while I think how we can sanitize these dependencies ... The problem is that nvidia-libopencl1 supports OpenCL 1.1, while all other support OpenCL 1.2. I could rebuild PyOpenCL for OpenCL 1.1 but it would prevent all users from using features present in OpenCL 1.2. I do not see easy solution here. Hi Andreas Will icl-icd-libopencl1 be able to make my nVidia card useable with poclbm ? Yes. libopencl1 just manages ICDs - nvidia-opencl-icd is responsible for running code on GPU. 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#711926: pyopencl: FTBFS during binNMU
I assume binNMU was part of the Python3.3 transition, unrelated to Boost 1.53 transition? Does it mean that I do not need to add python3.3 to Build-dependencies? I've added it to all my packages (pytools - #707310, pycuda, pyopencl) but have not yet uploaded anything. Dnia 2013-06-11, wto o godzinie 00:11 -0400, Scott Kitterman pisze: Package: pyopencl Version: 2012.1-1 Severity: serious Justification: fails to build from source (but built successfully in the past) [ cut ] dh_sphinxdoc -a dh_sphinxdoc: Sphinx documentation not found make: *** [binary-arch] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit status 2 PyOpenCL needs binary module (pyopencl) to be present when building Sphinx documentation because it imports some OpenCL constants into documentation. I've added make -C docs (with PYTHONPATH pointing to newly-build module) to override_dh_auto_build to deal with it. As it seems to be a problem now, is there a better way to do it? -- 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#682435: Can I close this bug?
Dnia 2012-10-29, pon o godzinie 19:57 +, Russel Winder pisze: Tomasz, Do you still have problems with PyOpenCL? Yes, but nothing to do with Debian packaging as far as I can tell. Based on your message from 2012-07-27 it looks like following advice from README.Debian has helped. I think that is a correct assessment. There is the issue of using the NVIDIA package versus not, but I don't think this is an issue for this bug report. I intend to close this bug by the end of November if I do not get any comments by then. I think it is entirely reasonable to close this bug report. To continue with my problem I need to do more work to find out where the issues are. Even then I think they are not Debian packaging issues. Thanks for your earlier help with this. I have not been able to work on this in the last weeks due to other commitments :-( Thanks for the feedback. As someone on PyOpenCL mentioned similar problem I'll try to get their feedback and then decide whether their problem is similar and whether I can close this bug. I've started working on solving problems with different OpenCL versions, but this is on hold now because of lack of time. 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#682435: Can I close this bug?
Hello. Do you still have problems with PyOpenCL? Based on your message from 2012-07-27 it looks like following advice from README.Debian has helped. I intend to close this bug by the end of November if I do not get any comments by then. 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#682435: python-pyopencl: pyopencl package incompatible with libOpenCL
Dnia 2012-07-27, pią o godzinie 19:14 +0100, Russel Winder pisze: On Fri, 2012-07-27 at 14:53 +0200, Tomasz Rybak wrote: […] Is there any way I could make it more obvious to PyOpenCL users? There is not many places I can put information about important changes in package besides README.Debian and NEWS. Sadly, I suspect there is not. As a person new to this, I just installed using aptitude those packages that seems most appropriate, and in an NVIDIA card situation nvidia-libopencl1 seems the most specific. As with most people, reading the README files in the documentation is the last thing one thinks of doing. I think the best way of avoiding hassle is to find some way of getting a link to the file high up the first page of a Google search for nvidia-libopencl1 1.2 (or some such query) I have wrote blog post describing this situation (and adding some history and background): http://tomaszrybak.wordpress.com/2012/07/31/pyopencl-and-pycuda-in-debian-wheezy/ Indeed. I think your thoughts are well on track to indicating the problem, but it is not Debian package related so I will definitely take the problem to a more appropriate place. Do you still have problems with PyOpenCL packages? I would like to close this bug; on the other hand it would be even better if you would close it yourself if you feel your problems have been fixed. 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#682435: python-pyopencl: pyopencl package incompatible with libOpenCL
Dnia 2012-07-26, czw o godzinie 18:08 +0100, Russel Winder pisze: Tomasz, On Tue, 2012-07-24 at 21:28 +0200, Tomasz Rybak wrote: […] Can you: 1. Test programs with ocl-icd-libopencl1 (instead of nvidia-libopencl1)? ocl-icd-libopencl1 will want to remove nvidia-libopencl1 but do not worry, you will still be able to run OpenCL programs. Making the replacement certainly allows for things to progress better. I think the errors I am now getting are to do with kernel compilation, which is likely nothing to do with this earlier problem. 2. Read /usr/share/doc/python-pyopencl/NEWS.Debian.gz? I have to admit, no I didn't. I have now :-) Now I understand why the original error. Is there any way I could make it more obvious to PyOpenCL users? There is not many places I can put information about important changes in package besides README.Debian and NEWS. OpenCL (and PyOpenCL) is still young and there are quite radical changes, especially with regards to management of ICDs, free software, etc. Lenny does not contain any OpenCL libraries, Squeeze contains only one OpenCL implementation (NVIDIA one), Wheezy contains 2 ICDs (AMD and NVIDIA) and 3 libopencl1 libraries (AMD, NVIDIA, and free ocl-icd). It looks like Wheezy+1 will have at least one free ICD. Having many OpenCL implementations, including free ones, is good situation, but at the same time might cause some problems like those you have experienced. At the same time I do not want to force users to install only one OpenCL implementation to use with PyOpenCL - this would be against spirit of free software, could cause problems if/when new OpenCL implementation is uploaded to Debian, would disallow experimentation and so on. After 1. works, I am open to proposals how to allow for installation PyOpenCL with different libopencl1 implementations. The error I am now getting is: | pi_python2_opencl.py Traceback (most recent call last): File ./pi_python2_opencl.py, line 34, in module execute ( 1 ) File ./pi_python2_opencl.py, line 26, in execute kernel.processSlice ( queue , results.shape , None , sliceSize , delta , results) File /usr/lib/python2.7/dist-packages/pyopencl/__init__.py, line 457, in kernel_call self.set_args(*args) File /usr/lib/python2.7/dist-packages/pyopencl/__init__.py, line 509, in kernel_set_args % (i+1, str(e), advice)) pyopencl.LogicError: when processing argument #1 (1-based): Kernel.set_arg failed: invalid value - invalid kernel argument Without seeing kernel and PyOpenCL code calling it I cannot be sure, but it looks like your code is passing some integer argument while OpenCL kernel expects buffer. PyOpenCL checks if kernel receives proper buffer and raises exception (which you got) if not. This looks like error unrelated to PyOpenCL packaging - consider asking more detailed questions on PyOpenCL mailing list: http://lists.tiker.net/listinfo/pyopencl Best regards. -- Tomasz Rybak tomasz.ry...@post.pl 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#682435: python-pyopencl: pyopencl package incompatible with libOpenCL
Dnia 2012-07-22, nie o godzinie 19:06 +0100, Russel Winder pisze: Package: python-pyopencl Version: 2012.1-1 Severity: important Dear Maintainer, For any script with the line: import pyopencl I get the message: File /usr/lib/python2.7/dist-packages/pyopencl/__init__.py, line 4, in module import pyopencl._cl as _cl ImportError: /usr/lib/python2.7/dist-packages/pyopencl/_cl.so: symbol clRetainDevice, version OPENCL_1.2 not defined in file libOpenCL.so.1 with link time reference which makes PyOpenCL a bit unusable :-( This is Debian Unstable. Can you: 1. Test programs with ocl-icd-libopencl1 (instead of nvidia-libopencl1)? ocl-icd-libopencl1 will want to remove nvidia-libopencl1 but do not worry, you will still be able to run OpenCL programs. 2. Read /usr/share/doc/python-pyopencl/NEWS.Debian.gz? After 1. works, I am open to proposals how to allow for installation PyOpenCL with different libopencl1 implementations. Best regards. -- Tomasz Rybak tomasz.ry...@post.pl 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#681419: tech-ctte help needed: main dependencies on non-free/contrib
Dnia 2012-07-17, wto o godzinie 10:35 -0700, Russ Allbery pisze: Hello all, Could someone who has the time and the tools available do a check on all the dependencies in main for dependencies on non-free/contrib? This information would be very helpful in evaluating tech-ctte bug #681419. In particular: I'm maintaining PyOpenCL which is currently in contrib, but I hope to move it to main in Wheezy+1. PyOpenCL builds cleanly with main-only packages, and can run with packages from main, but will not be usable then. It depends on ICD loader (free) and on opencl-icd (currently only non-free implementations are available). For more detailed description of OpenCL packaging in Debian see Vincent Danjean vdanj...@debian.org mail OpenCL in Debian from 2012-07-01 http://lists.debian.org/debian-devel/2012/06/msg01108.html * How many total dependencies are there? (We're only interested in Depends or Recommends for this purpose, not Suggests.) * Are all of those dependencies alternative dependencies of the form: Depends: foo | foo-nonfree In PyOpenCL it'll always be: Depends: ocl-icd-libopencl1 | libopencl1 where the ocl-icd-libopencl1 is free package, while other packages providing libopencl1 (currently amd-libopencl1 and nvidia-libopencl1) are non-free. I want to allow for users to be able to use non-free ICD loaders to allow for experiments and having different OpenCL versions (see bug #673992). As for opencl-icd, now PyOpenCL has: Depends: opencl-icd As soon as Debian has a free OpenCL implementation I'll change it to Depends: free-opencl-icd | opencl-icd but I intend to keep dependency on non-free OpenCL implementations (currently amd-opencl-icd and nvidia-opencl-icd) to allow to use GPGPU hardware if users are using non-free drivers. or are there other cases? A list of the other cases would be very interesting. (Some may just be bugs, but we may not have thought of some other possible pattern.) I am not sure if PyOpenCL fits general case or is special case. It requires two OpenCL-related packages (ICD loader and ICD) to work and those can be any mixture of free and non-free packages. * Are any of these dependencies versioned? One of the things we're evaluating is whether it would always be possible to replace those dependencies with a straight dependency on foo, with foo-nonfree Providing foo. Currently not (ICD loader takes care of proper managing of ICD versions) but I am wondering whether to add versioned dependency on ocl-libopencl1 (see my mail from 2012-07-10 OpenCL in Debian http://lists.debian.org/debian-devel/2012/07/msg00240.html ). From experience it seems that PyOpenCL works well with opencl-headers and ocl-icd-libopencl1, while there are some problems with different versions of non-free libopencl1 (most notably NVIDIA). Best regards. -- Tomasz Rybak tomasz.ry...@post.pl 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 glaub...@physik.fu-berlin.de * Package name: radeontop Version : 0.5.4 Upstream Author : Lauri Kasanen cur...@operamail.com * 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 tomasz.ry...@post.pl 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 froth...@ari.uni-heidelberg.de * Package name: pgsphere Version : 1.1.1 Upstream Author : Janko Richter jankorich...@yahoo.de * 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 tomasz.ry...@post.pl 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#679157: debian-maintainers: Please add Tomasz Rybak as Debian Maintainer
Package: debian-maintainers Severity: normal Please add Tomasz Rybak key to Debian Maintainer keyring. Thanks. Tomasz Rybak add-C654FB332AD59860 Description: Binary data
Bug#673992: closed by Tomasz Rybak bogom...@post.pl (Bug#673992: fixed in pyopencl 2011.2+git20120517-1)
Dnia 2012-06-11, pon o godzinie 08:56 +0200, Vedran Miletić pisze: Hi Tomasz, thanks for the fixes you made. ocl-icd has entered sid. Does this mean python-pyopencl will start to depend on it instead of amd-opencl-icd? Yes, the next version (either 2011.2+git20120604 or 2012.2 if upstream releases it before Wheezy freeze) will Build-Depend on ocl-icd-libopencl1. Although it will Build-Depends: on only free software, the package will not be in main in Wheezy, as it will not be usable without non-free OpenCL libraries (either nvidia-opencl-icd or amd-opencl-icd). I am not yet sure whether to Depends: on ocl-icd-libopencl1 or just libopencl1; the latter will allow for users to keep any OpenCL management library but at the same time might mean that there are problems with NVIDIA OpenCL which does not support OpenCL 1.2. I have already build and tested locally python-pyopencl with ocl-icd. If you want to I can send you URL to those packages so you can test them. If new package version works for you I propose to move discussion to private as it starts touching future package releases, not the bug itself. Best regards. -- Tomasz Rybak tomasz.ry...@post.pl 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 tomasz.ry...@post.pl:
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 bogom...@post.pl 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 bogom...@post.pl 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#674000: python-pyopencl-headers: fails to upgrade from 'testing' - trying to overwrite /usr/include/pyopencl/pyopencl-ranluxcl.cl
Dnia 2012-05-29, wto o godzinie 11:33 +0200, Andreas Beckmann pisze:
On 2012-05-27 21:06, Tomasz Rybak wrote:
Should I put
Breaks/Replaces: python-pyopencl ( 2011.2.2+git20120508-1)
or
Breaks/Replaces: python-pyopencl ( ${source:Version})?
Policy 7.6 uses hard-coded version, but many packages put
${source:Version} into debian/control. What is advised?
A hardcoded version would be advised because there was a change once in
the past, but any version afterwards is not affected by this.
source:Version is used for other purposes (usually for Relationships
with arch:all packages that don't have a matching binary:Version (at
least after an NMU).
Thanks for the explanation.
I have decided to put:
Replaces: python-pyopencl ( 2011.2+git20120508-1)
Breaks: python-pyopencl ( ${source:Version}),
python-pyopencl ( ${source:Version}),
python3-pyopencl ( ${source:Version}),
python3-pyopencl ( ${source:Version})
for python-pyopencl-headers and
Depends: python-pyopencl-headers (= ${source:Version})
for both python-pyopencl and python3-pyopencl
*-headers Replaces hard-coded version (because *-headers was introduced
in that version) and Breaks Python modules in all versions not equal
to itself because those modules include headers during compilation,
which might mean that compiler needs headers from its version.
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#674000: python-pyopencl-headers: fails to upgrade from 'testing' - trying to overwrite /usr/include/pyopencl/pyopencl-ranluxcl.cl
Dnia 2012-05-22, wto o godzinie 14:10 +0200, Andreas Beckmann pisze:
Package: python-pyopencl-headers
Version: 2011.2+git20120508-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Hi,
during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'unstable' fails
because it tries to overwrite files that are owned by other packages
without declaring a Breaks/Replaces relation.
See policy 7.6 at
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
From the attached log (scroll to the bottom...):
Selecting previously unselected package python-pyopencl-headers.
Unpacking python-pyopencl-headers (from
.../python-pyopencl-headers_2011.2+git20120508-1_all.deb) ...
dpkg: error processing
/var/cache/apt/archives/python-pyopencl-headers_2011.2+git20120508-1_all.deb
(--unpack):
trying to overwrite '/usr/include/pyopencl/pyopencl-ranluxcl.cl', which is
also in package python-pyopencl 2011.2-1
Should I put
Breaks/Replaces: python-pyopencl ( 2011.2.2+git20120508-1)
or
Breaks/Replaces: python-pyopencl ( ${source:Version})?
Policy 7.6 uses hard-coded version, but many packages put
${source:Version} into debian/control. What is advised?
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#673992: python-pyopencl: explicitely requires installation of amd-libopencl1
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 signature.asc Description: This is a digitally signed message part
Bug#672745: pycuda: needs rebuild against boost 1.49
Dnia 2012-05-13, nie o godzinie 13:38 +0200, Julien Cristau pisze: Source: pycuda Version: 2011.2.2-1 Severity: important pycuda was linked against boost 1.46. boost-defaults is now 1.49, so your package should be rebuilt. Filing a bug since it's not autobuilt. I am working on it. I am trying to provide Python3 package and I am working with upstream on it. I should be able to ask for sponsorship on new PyCUDA in a week. Thanks for patience. 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#661253: Trying 295.33
Dnia 2012-03-29, czw o godzinie 15:12 +0100, Russel Winder pisze: Thanks to Julian for setting up trying to do a backport to an earlier NVIDIA driver using Debian packages. I haven't tried that yet but I hope to do so next week. In the interim I tried cleaning out all the nvidia and related packages and installing from the NVIDIA distribution file. I tried 290.10. It seemed to install correctly. On reboot GDM3 starts fine. Logging in to GNOME 3 fails, I just get the Oh no page. Logging in with GNOME 2 works fine. I then put back all the 295.33 package including the remove the NVIDIA installer package. Exactly the same behaviour. This would seem to imply a problem with GNOME 3. Whether there is still a problem with spontaneous X terminations I now cannot tell as I cannot actually use the systems at all now :-(( Your problem might be related with Network Manager: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665973 I have similar problem - after I upgraded the system and rebooted, I could not start GNOME. Ironically (and unlike you) in my case it was AMD machine (using fglrx). My laptop with NVIDIA ION came up without problems after upgrade to 295.33. Downgrading Network Manager related packages to versions from testing helped - my AMD-based system cames up without problems. Packages I had to downgrade (from 0.9.4 in unstable to 0.9.2 in testing) to have working system: * gir1.2-networkmanager-1.0 * libnm-glib4 * libnm-glib-vpn1 * libnm-gtk0 * libnm-gtk-common * libnm-util2 Hope that helps. -- 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#643762: OpenCL with NVIDIA drivers
I have not noticed problems with PyOpenCL. Now I am using 290.06, but for some time I was using 275.x, and PyOpenCL was working. I can install 275.36 and check it with PyOpenCL, but not now - rather in the second half of the next week. Please let me know if I should do it. Best regards. -- Tomasz Rybak bogom...@post.pl 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#645735: hadoop: status inconsistent between archive and website
Package: ftp.debian.org Severity: normal Hello My system shows that hadoop packages are not in archive: $ LANG=C apt-cache policy hadoop-bin hadoop-bin: Installed: 0.20.2+dfsg1-2 Candidate: 0.20.2+dfsg1-2 Version table: *** 0.20.2+dfsg1-2 0 100 /var/lib/dpkg/status According to http://ftp-master.debian.org/removals.txt it was removed on 2011-06-18: = [Date: Sat, 18 Jun 2011 09:19:50 +] [ftpmaster: Luca Falavigna] Removed the following packages from unstable: hbase | 0.20.4+dfsg1-1 | source hbase-bin | 0.20.4+dfsg1-1 | all hbase-daemons-common | 0.20.4+dfsg1-1 | all hbase-masterd | 0.20.4+dfsg1-1 | all hbase-regionserverd | 0.20.4+dfsg1-1 | all libhbase-java | 0.20.4+dfsg1-1 | all libhbase-java-doc | 0.20.4+dfsg1-1 | all Closed bugs: 630821 --- Reason --- NPOASR; orphaning all hadoop related packages -- Also closing bug(s): 581495 587120 591772 Also closing WNPP bug(s): = = [Date: Sat, 18 Jun 2011 09:20:58 +] [ftpmaster: Luca Falavigna] Removed the following packages from unstable: hadoop | 0.20.2+dfsg1-2 | source hadoop-bin | 0.20.2+dfsg1-2 | all hadoop-daemons-common | 0.20.2+dfsg1-2 | all hadoop-datanoded | 0.20.2+dfsg1-2 | all hadoop-jobtrackerd | 0.20.2+dfsg1-2 | all hadoop-namenoded | 0.20.2+dfsg1-2 | all hadoop-secondarynamenoded | 0.20.2+dfsg1-2 | all hadoop-tasktrackerd | 0.20.2+dfsg1-2 | all libhadoop-index-java | 0.20.2+dfsg1-2 | all libhadoop-java | 0.20.2+dfsg1-2 | all libhadoop-java-doc | 0.20.2+dfsg1-2 | all Closed bugs: 630820 --- Reason --- NPOASR; orphaning all hadoop related packages -- Also closing bug(s): 569987 575478 587153 592450 593670 593809 598347 613611 629387 Also closing WNPP bug(s): 579787 = On the other hand packages.debian.org lists hadoop as present in Debian Sid: http://packages.debian.org/sid/hadoop-bin Package: hadoop-bin (0.20.2+dfsg1-2) data-intensive clustering framework - tools Download hadoop-bin ArchitecturePackage SizeInstalled Size Files all 8.2 kB 56.0 kB [list of files] While all the mirrors return HTTP 404 when trying to retrieve package: Not Found The requested URL /debian/pool/main/h/hadoop/hadoop-bin_0.20.2+dfsg1-2_all.deb was not found on this server. Apache/2.2.21 (Unix) Server at ftp.jp.debian.org Port 80 Please update packages.debian.org (or regenerate it?) so it does not give incorrect information about package status. Regards. Tomasz Rybak -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628702: New release changes ICD dependencies
Hello. New PyOpenCL version (2011.1.2) is in Debian. I have changed OpenCL-related dependencies. Now, instead of requiring NVIDIA libopencl, package depends on virtual opencl-icd, and different packages can provide it. Package still contains build-dependency on NVIDIA's libopencl-dev. Please test whether this is the correct run-time solution for this bug, and if so, whether this bug can be closed or should I wait for non-NVIDIA OpenCL libraries to also fix build-dependencies. Best regards. -- Tomasz Rybak bogom...@post.pl 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 bogom...@post.pl 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 bogom...@post.pl 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 bogom...@post.pl 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 upgrades shall be considered part of the Software, and shall
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 bogom...@post.pl 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#629808: Should depend on, not recommend, libnvidia-compiler
Package: nvidia-opencl-icd Version: 270.41.19-1 Severity: important When trying to come with solution to #628702 I played with dependencies of python-pycuda. I build it depending on libopencl1 and opencl-icd, which IMO should be sufficient to get OpenCL implementation to work. I have removed libnvidia-comipler from system, installed new version of python-pyopencl, and some of programs do not work. Programs that provide kernels as source and require compilation by OpenCL provider require presence of libnvidia-compiler in case of NVIDIA OpenCL implementation. OpenCL assumes that most programs will provide kernels as source (just like shaders for OpenGL), so now any program using NVIDIA OpenCL need to depend on libnvidia-compiler making it unusable for people using different hardware (see #628702). Please fix this dependency. I am not sure whether nvidia-opencl-icd or nvidia-libopencl1 should depend on libnvidia-compiler, but IMO one of them should. Please introduce this change for all driver versions that provide OpenCL, i.e. 195.x, 270.x, 275.x. Thanks. -- Package-specific info: uname -a: Linux saruman 2.6.39-1-amd64 #1 SMP Tue May 24 14:34:19 UTC 2011 x86_64 GNU/Linux /proc/version: Linux version 2.6.39-1-amd64 (Debian 2.6.39-1) (buildd_amd64-bra...@buildd.debian.org) (gcc version 4.4.6 (Debian 4.4.6-3) ) #1 SMP Tue May 24 14:34:19 UTC 2011 /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 270.41.19 Mon May 16 23:32:08 PDT 2011 GCC version: gcc version 4.4.6 (Debian 4.4.6-3) lspci 'VGA compatible controller [0300]': 05:00.0 VGA compatible controller [0300]: nVidia Corporation ION VGA [GeForce 9400M] [10de:0876] (rev b1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device [1043:8402] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 23 Region 0: Memory at fa00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at e000 (64-bit, prefetchable) [size=256M] Region 3: Memory at f600 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at cc00 [size=128] [virtual] Expansion ROM at fbde [disabled] [size=128K] Capabilities: access denied Kernel driver in use: nvidia OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 35 Aug 30 2010 /etc/alternatives/libGL.so - /usr/lib/nvidia/diversions/libGL.so lrwxrwxrwx 1 root root 26 Aug 30 2010 /etc/alternatives/libGL.so.1 - /usr/lib/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 26 Aug 30 2010 /usr/lib/libGL.so - /etc/alternatives/libGL.so lrwxrwxrwx 1 root root 28 Aug 30 2010 /usr/lib/libGL.so.1 - /etc/alternatives/libGL.so.1 lrwxrwxrwx 1 root root 26 May 25 08:52 /usr/lib/libnvidia-cfg.so.1 - libnvidia-cfg.so.270.41.19 -rw-r--r-- 1 root root 133064 May 17 08:52 /usr/lib/libnvidia-cfg.so.270.41.19 -rw-r--r-- 1 root root 20498976 May 17 09:39 /usr/lib/libnvidia-compiler.so.270.41.19 -rw-r--r-- 1 root root 27484752 May 17 08:47 /usr/lib/libnvidia-glcore.so.270.41.19 lrwxrwxrwx 1 root root 17 May 25 08:52 /usr/lib/libnvidia-ml.so - libnvidia-ml.so.1 lrwxrwxrwx 1 root root 25 May 25 08:52 /usr/lib/libnvidia-ml.so.1 - libnvidia-ml.so.270.41.19 -rw-r--r-- 1 root root85464 May 17 09:40 /usr/lib/libnvidia-ml.so.270.41.19 -rw-r--r-- 1 root root 6008 May 17 08:51 /usr/lib/libnvidia-tls.so.270.41.19 /usr/lib/nvidia: total 7336 drwxr-xr-x 3 root root4096 May 27 11:00 . drwxr-xr-x 266 root root 135168 Jun 8 14:18 .. -rwxr-xr-x 1 root root1338 May 16 03:01 check-for-conflicting-opengl-libraries drwxr-xr-x 2 root root4096 Jun 1 17:05 diversions lrwxrwxrwx 1 root root 18 May 25 08:52 libGL.so.1 - libGL.so.270.41.19 -rw-r--r-- 1 root root 1008272 May 17 08:48 libGL.so.270.41.19 lrwxrwxrwx 1 root root 19 May 25 08:52 libglx.so - libglx.so.270.41.19 -rw-r--r-- 1 root root 6327720 May 17 08:51 libglx.so.270.41.19 -rwxr-xr-x 1 root root 441 May 16 03:01 pre-install /usr/lib/nvidia/diversions: total 784 drwxr-xr-x 2 root root 4096 Jun 1 17:05 . drwxr-xr-x 3 root root 4096 May 27 11:00 .. -rw-r--r-- 1 root root189 Mar 22 07:38 dummy.txt lrwxrwxrwx 1 root root 10 May 31 17:57 libGL.so - libGL.so.1 lrwxrwxrwx 1 root root 12 May 31 17:57 libGL.so.1 - libGL.so.1.2 -rw-r--r-- 1 root root 474024 May 31 17:57 libGL.so.1.2 -rw-r--r-- 1 root root 305800 May 30 12:25 libglx.so Files from nvidia-installer: -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-1-amd64 (SMP w/4 CPU cores) Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) Shell: /bin/sh
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628702: nvidia dependencies and AMD cards
Dnia 2011-06-03, pią o godzinie 18:44 +0200, Ed Lin pisze: On Fri, Jun 3, 2011 at 6:04 PM, Tomasz Rybak wrote: So you have installed something from outside distribution (Debian/Ubuntu) which provides OpenCL support for AMD cards? Yes. Do you know whether someone intends to package APP? That's the only thing I have seen: http://forums.amd.com/forum/messageview.cfm?catid=390threadid=125792 I have opened bug #629518 and set this bug as blocked by #629518. As soon as someone provides package with OpenCL implementation for AMD hardware I will change PyOpenCL package dependencies. Till then this bug stays open. Best regards. -- Tomasz Rybak bogom...@post.pl 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#628702: nvidia dependencies and AMD cards
Dnia 2011-06-02, czw o godzinie 23:07 +0200, Ed Lin pisze: On Wed, Jun 1, 2011 at 4:55 PM, Tomasz Rybak wrote: Can you describe how you are using OpenCL with fglrx? I have tried to find packages providing OpenCL, but was able to only find NVIDIA-related packages. I'm using Ubuntu, hope that's not a problem. I could of course test Debian too if that's required. I had to install fglrx (jockey/distro package) and download the AMD APP SDK [1], as far as I can tell no further opencl related packages were needed. [1] http://developer.amd.com/sdks/AMDAPPSDK/downloads/Pages/default.aspx So you have installed something from outside distribution (Debian/Ubuntu) which provides OpenCL support for AMD cards? Do you know whether someone intends to package APP? -- Tomasz Rybak bogom...@post.pl 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#628702: nvidia dependencies and AMD cards
Dnia 2011-05-31, wto o godzinie 16:13 +0200, Ed Lin pisze: Package: python-pyopencl Version: 0.92-1 python-pyopencl has nvidia dependencies but it actually also works on AMD/ATI hardware as well. These wrong dependencies make it harder to use with fglrx. Can you describe how you are using OpenCL with fglrx? I have tried to find packages providing OpenCL, but was able to only find NVIDIA-related packages. I do not own ATI/AMD GPU, so I do not know how people on Debian are using it with OpenCL. I'm not sure about the solution, I guess there are two ways: Remove the nvidia decencies and somehow notify the user that he needs to be running a (non-free for now) graphic driver with opencl support. Or: Properly handle the dependencies so that installing the package either fetches fglrx or nvidia* depending on the detected hardware. Currently package depends on: libnvidia-compiler1 | libnvidia-compiler, nvidia-libopencl1, nvidia-opencl-common, Second dependency pulls OpenCL library, and third ICD file (telling OpenCL where to find available OpenCL libraries). I think it could be possible to change them to: libopencl1 opencl-icd I am not sure about first dependency (libnvidia-compiler1); I will need to experiment a bit. Then, if fglrx provides those packages, it would work without any problems. I have checked PyOpenCL with APP OpenCL on CPU and it works without any problems, so I believe dependencies are the only problem. Related ubuntu bug: pyopencl falsely depends on nvidia-current https://bugs.launchpad.net/ubuntu/+source/pyopencl/+bug/763457 Thanks for providing link to this bug - I do not know why I have not received mail from launchpad about this bug. -- Tomasz Rybak bogom...@post.pl 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#599874: intent to NMU
Thanks, but I have all fixes ready. Here is repository with new version of packaging files: http://git.debian.org/?p=collab-maint/python-pyopencl.git Now release maintainers are thinking whether to allow for upload of new version (full 0,92 instead of 0.92 beta which is in Squeeze) or only to accept fixes: http://lists.debian.org/debian-release/2010/10/msg00669.html Should I tag somehow bugs related to pyopencl to let everybody know that I have fixes waiting for decision? Should it be patch or pending, knowing that release managers have not taken decision yet? -- Tomasz Rybak bogom...@post.pl 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#599782: #599782 - pyopencl: FTBFS: ImportError: No module named pyopencl
Dnia 2010-10-12, wto o godzinie 01:00 +0200, Jakub Wilk pisze: * Evgeni Golov evg...@debian.org, 2010-10-11, 18:54: this one is funny. setuptools uses python's os.uname() to check which arch it is running on, and where the temp-build-path is. This fails nicely on machines with 64bit-kernel and 32bit-userland (at least amd64, as it has x86_86 in uname, as the kernel is for x86_64). In this particular bug, it's not 64 vs 32 bit, but i686 vs i486, quoting the build-log: g++ -pthread -shared -Wl,-Bsymbolic-functions -g -O2 build/temp.linux-i686-2.6/src/wrapper/wrap_cl.o build/temp.linux-i686-2.6/src/wrapper/wrap_cl_part_1.o build/temp.linux-i686-2.6/src/wrapper/wrap_cl_part_2.o build/temp.linux-i686-2.6/src/wrapper/wrap_constants.o -lboost_python-py26 -lOpenCL -o build/lib.linux-i686-2.6/pyopencl/_cl.so PYTHONPATH=../build/lib.linux-i486-2.6/ /usr/bin/make -C doc html the stuff is built in build/lib.linux-i686-2.6/, but PYTHONPATH is set to build/lib.linux-i486-2.6/. This is done in debian/rules: PYTHONPATH=../build/lib.$(DEB_BUILD_ARCH_OS)-$(DEB_BUILD_GNU_CPU)-$(firstword $(PYVERS)) There's another problem here: DEB_BUILD_* variables are used, but they are not defined anywhere. The code in question works only thanks to dpkg-buildpackage exporting these variables. It will fail (on any architecture) if debian/rules is run by hand. $(DEB_BUILD_GNU_CPU) is wrong here, as is expands correctly to i486 (even on amd64 kernel with a i386 chroot). I fear we have to parse `uname -m` here, to fix that issue and match setuptools' algorithm. The idiomatic approach to this problem is to use wildcards. I used PYTHONPATH=../build/lib.$(DEB_BUILD_ARCH_OS)-$(DEB_BUILD_GNU_CPU)-$(firstword$(PYVERS)) because I build library for all python versions (here 2.5 and 2.6) Using wildcard would mean that I do not have control over which library will be given to python - risking that python2.6 will get library 2.5. I have changed this to PYTHONPATH=../build/lib.*-*-$(firstword $(PYVERS)) and it works on my machine. Please test whether it work on i386. Version with fixes for all opened bugs: #599785, #599873, #599874, #599875 is on: http://www.bogomips.w.tkb.pl/cuda/pyopencl_0.92-1.dsc I am waiting for decision of release team whether to put new upstream version (with packaging fixes) or fix existing one. After decision is made I will ask for sponsorship. -- Tomasz Rybak bogom...@post.pl 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#599782: pyopencl: FTBFS: ImportError: No module named pyopencl
Dnia 2010-10-12, wto o godzinie 15:38 +0200, Evgeni Golov pisze: Jakub Wilk jw...@debian.org wrote: * Tomasz Rybak bogom...@post.pl, 2010-10-12, 12:06: I have changed this to PYTHONPATH=../build/lib.*-*-$(firstword $(PYVERS)) and it works on my machine. This would set PYTHONPATH to PYTHONPATH=../build/lib.*-*-2.6/ (literally). Doesn't look good. You probably want something like: PYTHONPATH=../$(wildcard build/lib.*-*-$(firstword $(PYVERS)))/ or PYTHONPATH=../$$(ls -d build/lib.*-*-$(firstword $(PYVERS)))/ wildcard seems not to work, no idea why (it does when I call make -f debian/rules build, but not when invoked via dpkg-buildpackage). the ls version works fine for me on amd64 with i386 chroot (failed before). @Thomasz: If you need a sponsor, I'm willing to help (either the existing or the 0.92 version if you get the OK from RT) :) Sorry for mess - I keep forgetting that debian/rules is Makefile, not ordinary shell script. Thanks for suggestions, and testing changes. I played a little bit with $(wildcard) but was not able to make it working; each time I got PYTHONPATH=..//. I have changed debian/rules to $$(ls ...), tested in after purging old version of pyopencl, tested using pbuilder on i386 and amd64, and it builds every time. New version is, as previously, at http://www.bogomips.w.tkb.pl/cuda/pyopencl_0.92-1.dsc Now we need to wait for release team decision. -- Tomasz Rybak bogom...@post.pl 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#595598: Fails to start - cannot find dconf-service
Package: gnome-shell Version: 2.31.5-2 Severity: grave Tags: experimental When trying to start gnome-shell: $ gnome-shell Starting dconf-service... Failed to start /usr/lib/d-conf/dconf-service: [Errno 2] No such file or directory $ I keep all required packages up-to-date (including glib from experimental) but cannot run gnome-shell. It does not start even when variable WINDOW_MANAGER=gnome-shell is set. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii gconf2 2.31.5-1 GNOME configuration database syste ii gir1.0-clutter-1.0 1.2.12-3 GObject introspection data for the ii gir1.0-freedesktop 0.6.14-1+b1 Introspection data for some FreeDe ii gir1.0-gconf-2.02.31.5-1 GNOME configuration database syste ii gir1.0-glib-2.0 0.6.15~git20100713-1 Introspection data for GLib, GObje ii gir1.0-gtk-2.0 0.6.5-6+b1 GObject introspection data for the ii gir1.0-json-glib-1. 0.10.2-2 GLib JSON manipulation library (do ii gir1.0-mutter-2.31 2.31.5-1 GObject introspection data for Mut ii gjs 0.7.1-1 Mozilla-based javascript bindings ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-5 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-5 The Cairo 2D vector graphics libra ii libclutter-1.0-01.2.12-3 Open GL based interactive canvas l ii libcroco3 0.6.2-1 a generic Cascading Style Sheet (C ii libdbus-1-3 1.2.24-3 simple interprocess messaging syst ii libdbus-glib-1-20.88-2 simple interprocess messaging syst ii libffi5 3.0.9-2 Foreign Function Interface library ii libfontconfig1 2.8.0-2.1generic font configuration library ii libfreetype62.4.2-2 FreeType 2 font engine, shared lib ii libgconf2-4 2.31.5-1 GNOME configuration database syste ii libgirepository1.0- 0.6.14-1+b1 Library for handling GObject intro ii libgjs0a0.7.1-1 Mozilla-based javascript bindings ii libgl1-mesa-glx [li 7.7.1-4 A free implementation of the OpenG ii libglib2.0-02.25.15-1The GLib library of C routines ii libgnome-desktop-2- 2.30.2-1 Utility library for loading .deskt ii libgnome-menu2 2.30.2-1 an implementation of the freedeskt ii libgstreamer0.10-0 0.10.30-1Core GStreamer libraries and eleme ii libgtk2.0-0 2.21.7-1 The GTK+ graphical user interface ii libjson-glib-1.0-0 0.10.2-2 GLib JSON manipulation library ii libmozjs2d 1.9.1.11-2 The Mozilla SpiderMonkey JavaScrip ii libnspr4-0d 4.8.6-1 NetScape Portable Runtime Library ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio ii libstartup-notifica 0.10-1 library for program launch feedbac ii libx11-62:1.3.3-3X11 client-side library ii libxcomposite1 1:0.4.2-1X11 Composite extension library ii libxdamage1 1:1.1.3-1X11 damaged region extension libra ii libxext62:1.1.2-1X11 miscellaneous extension librar ii libxfixes3 1:4.0.5-1X11 miscellaneous 'fixes' extensio ii libxml2 2.7.7.dfsg-4 GNOME XML library ii mesa-utils 7.7.1-4 Miscellaneous Mesa GL utilities ii mutter 2.31.5-1 lightweight GTK+ window manager ii pkg-config 0.25-1 manage compile and link flags for ii python 2.6.6-1 interactive high-level object-orie ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gnome-shell recommends: ii xserver-xephyr2:1.7.7-5 nested X server gnome-shell suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595677: Uninstallable because of conflict with llvm-2.7-dev: /usr/share/vm/vimcurrent
Package: vim-common Version: 2:7.2.445+hg~cb94c42c0e1a-1 Severity: grave Tags: sid During upgrade: # LANG=C apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: vim-common 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/160kB of archives. After this operation, 0B of additional disk space will be used. Do you want to continue [Y/n]? (Reading database ... 521378 files and directories currently installed.) Preparing to replace vim-common 2:7.2.445+hg~cb94c42c0e1a-1 (using .../vim-common_2%3a7.3.000+hg~ee53a39d5896-1_amd64.deb) ... Unpacking replacement vim-common ... dpkg: error processing /var/cache/apt/archives/vim-common_2%3a7.3.000+hg~ee53a39d5896-1_amd64.deb (--unpack): trying to overwrite '/usr/share/vim/vimcurrent', which is also in package llvm-2.7-dev 2.7-5 configured to not write apport reports Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/vim-common_2%3a7.3.000+hg~ee53a39d5896-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) # Thanks. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vim-common depends on: ii libc6 2.11.2-5 Embedded GNU C Library: Shared lib Versions of packages vim-common recommends: pn vim | vim-gnome | vim-gtk | v none (no description available) vim-common suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590322: Experimental version uninstallable because of dependency on libgjs0a
Package: gnome-shell Version: 2.31.2-1 Severity: grave Tags: experimental I am unable to install new version of gnome-shell: # LANG=C apt-get -t experimental install gnome-shell Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: gnome-shell: Depends: libgjs0a (= 0.7.1) but 0.7-1 is to be installed E: Broken packages and after upgrade gir packages old gnome-shell is not usable: $ gnome-shell (mutter:2310): mutter-WARNING **: Could not load library [/usr/lib/mutter/plugins/libgnome-shell.so (/usr/lib/mutter/plugins/libgnome-shell.so: undefined symbol: mutter_plugin_effect_completed)] -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii gconf2 2.28.1-3 GNOME configuration database syste ii gir1.0-clutter-1.0 1.2.12-2 GObject introspection data for the ii gir1.0-freedesktop 0.6.14-1+b1 Introspection data for some FreeDe ii gir1.0-glib-2.0 0.6.14-1+b1 Introspection data for GLib, GObje ii gir1.0-gtk-2.0 0.6.5-6+b1 GObject introspection data for the ii gir1.0-json-glib-1.00.10.2-2 GLib JSON manipulation library (do ii gir1.0-mutter-2.31 2.31.5-1 GObject introspection data for Mut ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra ii libclutter-1.0-01.2.12-2 Open GL based interactive canvas l ii libcroco3 0.6.2-1 a generic Cascading Style Sheet (C ii libdbus-1-3 1.2.24-2 simple interprocess messaging syst ii libdbus-glib-1-20.86-1 simple interprocess messaging syst ii libffi5 3.0.9-2 Foreign Function Interface library ii libfontconfig1 2.8.0-2.1generic font configuration library ii libfreetype62.4.0-2 FreeType 2 font engine, shared lib ii libgconf2-4 2.28.1-3 GNOME configuration database syste ii libgirepository1.0-00.6.14-1+b1 Library for handling GObject intro ii libgjs0a0.7-1Mozilla-based javascript bindings ii libgl1-mesa-glx [libgl1 7.7.1-4 A free implementation of the OpenG ii libglib2.0-02.24.1-1 The GLib library of C routines ii libgnome-desktop-2-17 2.30.2-1 Utility library for loading .deskt ii libgnome-menu2 2.30.2-1 an implementation of the freedeskt ii libgstreamer0.10-0 0.10.30-1Core GStreamer libraries and eleme ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface ii libjson-glib-1.0-0 0.10.2-2 GLib JSON manipulation library ii libmozjs2d 1.9.1.11-1 The Mozilla SpiderMonkey JavaScrip ii libnspr4-0d 4.8.4-2 NetScape Portable Runtime Library ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio ii libstartup-notification 0.10-1 library for program launch feedbac ii libx11-62:1.3.3-3X11 client-side library ii libxcomposite1 1:0.4.2-1X11 Composite extension library ii libxdamage1 1:1.1.3-1X11 damaged region extension libra ii libxext62:1.1.2-1X11 miscellaneous extension librar ii libxfixes3 1:4.0.5-1X11 miscellaneous 'fixes' extensio ii libxml2 2.7.7.dfsg-4 GNOME XML library ii mesa-utils 7.7.1-4 Miscellaneous Mesa GL utilities ii mutter 2.31.5-1 lightweight GTK+ window manager ii pkg-config 0.25-1 manage compile and link flags for ii python 2.6.5-9 interactive high-level object-orie ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gnome-shell recommends: ii xserver-xephyr2:1.7.7-3 nested X server gnome-shell suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 bogom...@post.pl 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 bogom...@post.pl 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#582564: [Evolution] Bug#582564: evolution segfaults when closing email window after upgrade to 2.30
Dnia 2010-05-22, sob o godzinie 11:28 +0200, Yves-Alexis Perez pisze: On ven., 2010-05-21 at 22:28 +0200, Tomasz Rybak wrote: Package: evolution Version: 2.30.1.2-2 Severity: important Tags: sid In the beginning of this week I updated my system, including updating Evolution to 2.30. Before updating I run `evolution --force-shutdown', packages were updated without problems, but after running Evolution I noticed few problems, some of which could be related: 1. Mail folders' settings were missing - in 2.28 I had threaded view without window showing email content - after update all folders had non-threaded view with email subwindow. 2. I think connected to the above - when reading email and pressing ] the next email shown is based on time, not on thread. 3. Tags for emails are duplicated. One set is in polish language (independent of LC_* settings) and one is localised (depending on LANG shown in appropriate language). 4. When closing email window, Evolution sometimes crashes. From my observations it crashes when I open one email and then close it. If I open two emails in different windows, and then close those windows Evolution tends to stay running, at least until I move to another folder. Then, if I forget to open two emails it crashes again. Below I attach backtrace of one of such crashes. Hey, for upstream issues, please report directly upstream (one bug report per issue), adding forwards tag when needed. Thanks, I have searched bugs.gnome.org and it seems that it is related to a11y - disabling accessibility support solves problem with crashes. For another problems I have filled upstream bugs. -- Tomasz Rybak bogom...@post.pl 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#582564: evolution segfaults when closing email window after upgrade to 2.30
Package: evolution Version: 2.30.1.2-2 Severity: important Tags: sid In the beginning of this week I updated my system, including updating Evolution to 2.30. Before updating I run `evolution --force-shutdown', packages were updated without problems, but after running Evolution I noticed few problems, some of which could be related: 1. Mail folders' settings were missing - in 2.28 I had threaded view without window showing email content - after update all folders had non-threaded view with email subwindow. 2. I think connected to the above - when reading email and pressing ] the next email shown is based on time, not on thread. 3. Tags for emails are duplicated. One set is in polish language (independent of LC_* settings) and one is localised (depending on LANG shown in appropriate language). 4. When closing email window, Evolution sometimes crashes. From my observations it crashes when I open one email and then close it. If I open two emails in different windows, and then close those windows Evolution tends to stay running, at least until I move to another folder. Then, if I forget to open two emails it crashes again. Below I attach backtrace of one of such crashes. #0 0x7f7cd9d49a78 in ect_check (a11y=value optimized out) at gal-a11y-e-cell-text.c:83 #1 0x7f7cd9d4aa6e in ect_get_name (a11y=0x7f7cd9f6b878) at gal-a11y-e-cell-text.c:95 #2 0x7f7cca65cc41 in spi_atk_bridge_init_base (any=value optimized out, obj=0x1231120, app=0x7f7cc7844b40, role=0x0, name=0x7fff41daefa8) at bridge.c:1367 #3 0x7f7cca65cd3d in spi_atk_bridge_init_nil (any=0x7f7cd9f6b878, obj=0x1231120) at bridge.c:1379 #4 0x7f7cca65d494 in spi_atk_bridge_focus_tracker (object=0x13f4be0) at bridge.c:726 #5 0x7f7cd3e46819 in atk_focus_tracker_notify (object=0x13f4be0) at atkutil.c:200 #6 0x7f7cca872d5b in gail_focus_notify (data=value optimized out) at /tmp/buildd/gtk+2.0-2.20.1/modules/other/gail/gail.c:589 #7 gail_focus_idle_handler (data=value optimized out) at /tmp/buildd/gtk+2.0-2.20.1/modules/other/gail/gail.c:542 #8 0x7f7cd4070d26 in gdk_threads_dispatch (data=0x7f7cb4210160) at /tmp/buildd/gtk+2.0-2.20.1/gdk/gdk.c:512 #9 0x7f7cd1c1c6c2 in g_main_dispatch (context=0x87f620) at /tmp/buildd/glib2.0-2.24.1/glib/gmain.c:1960 #10 IA__g_main_context_dispatch (context=0x87f620) at /tmp/buildd/glib2.0-2.24.1/glib/gmain.c:2513 ---Type return to continue, or q return to quit--- #11 0x7f7cd1c20538 in g_main_context_iterate (context=0x87f620, block=value optimized out, dispatch=value optimized out, self=value optimized out) at /tmp/buildd/glib2.0-2.24.1/glib/gmain.c:2591 #12 0x7f7cd1c20a45 in IA__g_main_loop_run (loop=0xd5aee0) at /tmp/buildd/glib2.0-2.24.1/glib/gmain.c:2799 #13 0x7f7cd443a647 in IA__gtk_main () at /tmp/buildd/gtk+2.0-2.20.1/gtk/gtkmain.c:1219 #14 0x004027d4 in main (argc=1, argv=0x7fff41daf3e8) at main.c:578 Best regards and thanks for work on packaging Evolution. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages evolution depends on: ii dbus1.2.24-1 simple interprocess messaging syst ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy ii evolution-common2.30.1.2-2 architecture independent files for ii evolution-data-server 2.30.1-4 evolution database backend server ii gconf2 2.28.1-3 GNOME configuration database syste ii gnome-icon-theme2.30.2.1-1 GNOME Desktop icon theme ii libart-2.0-22.3.21-1 Library of functions for 2D graphi ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra ii libcamel1.2-14 2.30.1-4 The Evolution MIME message handlin ii libcanberra-gtk00.24-1 Gtk+ helper for playing widget eve ii libcanberra00.24-1 a simple abstract interface for pl ii libdbus-1-3 1.2.24-1 simple interprocess messaging syst ii libdbus-glib-1-20.86-1 simple interprocess messaging syst ii libebackend1.2-0
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 bogom...@post.pl 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 bogom...@post.pl 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 bogom...@post.pl 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#521492: Acknowledgement (linux-image-2.6.29-1-686: Panics when DVD is inserted)
Just installed 2.6.30 from unstable and copying from DVD works, although is very slow. I think bug can be closed - but #485704 still applies (copying files from DVD takes about 25 minutes under 2.6.30, instead of about 6 which it took under 2.6.23). Regards. -- Tomasz Rybak bogom...@post.pl GPG key ID: F22C D870 Fingerprint 93BC FEEC A426 3765 799F 10EE FAC1 9A2C F22C D870 http://member.acm.org/~tomaszrybak signature.asc Description: To jest część wiadomości podpisana cyfrowo
Bug#521492: linux-image-2.6.29-1-686: Panics when DVD is inserted
Package: linux-image-2.6.29-1-686 Version: 2.6.29-1 Severity: important Today I upgraded my Debian unstable. I installed new kernel 2.6.29 and udev 9.140. After that during boot ATI framebuffer is enabled (I am not sure if it is related - I have ATI Radeon). Now, when I put DVD into my burnen (I have only one DVD drive) entire system hangs, and kernel panics. It blinks scroll and caps lock, but not num-lock. Panic occurs both when in X or in text mode. It occurs about five seconds after CD-tray closes. I haven't tested whether kernel would panic when I put blank CD or DVD. -- Package-specific info: ** Version: Linux version 2.6.29-1-686 (Debian 2.6.29-1) (wa...@debian.org) (gcc version 4.3.3 (Debian 4.3.3-5) ) #1 SMP Tue Mar 24 23:05:52 UTC 2009 ** Command line: root=/dev/hda1 ro selinux=1 audit=0 enforcing=0 ** Not tainted ** Kernel log: [5.280494] libata version 3.00 loaded. [5.314660] ide-gd driver 1.18 [5.314806] hda: max request size: 512KiB [5.329671] hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63 [5.329916] hda: cache flushes supported [5.330082] hda:6ide-cd driver 5.00 [5.332565] hda1 hda2 hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12 [5.419022] ide-cd: hdc: ATAPI 48X DVD-ROM DVD-R/RAM CD-R/RW drive, 2048kB Cache [5.419292] Uniform CD-ROM driver Revision: 3.20 [6.073304] PM: Starting manual resume from disk [6.118573] EXT3-fs: INFO: recovery required on readonly filesystem. [6.119272] EXT3-fs: write access will be enabled during recovery. [6.192524] kjournald starting. Commit interval 5 seconds [6.192615] EXT3-fs: recovery complete. [6.193033] EXT3-fs: mounted filesystem with ordered data mode. [7.611938] udev: starting version 140 [7.954658] input: Power Button (FF) as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 [7.954741] ACPI: Power Button (FF) [PWRF] [7.954903] input: Power Button (CM) as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input3 [7.954970] ACPI: Power Button (CM) [PWRB] [7.975760] Linux agpgart interface v0.103 [7.988430] agpgart: Detected VIA KT400/KT400A/KT600 chipset [7.999233] agpgart-via :00:00.0: AGP aperture is 128M @ 0xd000 [8.023621] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [8.082462] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [8.271515] NET: Registered protocol family 23 [8.308588] usblp0: USB Bidirectional printer dev 2 if 0 alt 1 proto 2 vid 0x03F0 pid 0x0C17 [8.308699] usbcore: registered new interface driver usblp [8.400303] radeonfb :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [8.401812] radeonfb: Found Intel x86 BIOS ROM Image [8.401868] radeonfb: Retrieved PLL infos from BIOS [8.401920] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=250.00 Mhz, System=200.00 MHz [8.401983] radeonfb: PLL min 2 max 4 [8.540282] input: PC Speaker as /devices/platform/pcspkr/input/input4 [8.689168] i2c-adapter i2c-2: unable to read EDID block. [8.841162] i2c-adapter i2c-2: unable to read EDID block. [8.993166] i2c-adapter i2c-2: unable to read EDID block. [9.145141] i2c-adapter i2c-3: unable to read EDID block. [9.297129] i2c-adapter i2c-3: unable to read EDID block. [9.449127] i2c-adapter i2c-3: unable to read EDID block. [9.505082] radeonfb: Monitor 1 type DFP found [9.505145] radeonfb: EDID probed [9.505192] radeonfb: Monitor 2 type no found [9.516130] Console: switching to colour frame buffer device 210x65 [9.578952] radeonfb (:01:00.0): ATI Radeon 4966 If [ 10.041933] ACPI: PCI Interrupt Link [ALKC] BIOS reported IRQ 0, using IRQ 22 [ 10.042047] ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22 [ 10.042139] VIA 82xx Audio :00:11.5: PCI INT C - Link[ALKC] - GSI 22 (level, low) - IRQ 22 [ 10.042625] VIA 82xx Audio :00:11.5: setting latency timer to 64 [ 11.104657] Adding 2008084k swap on /dev/hda9. Priority:-1 extents:1 across:2008084k [ 11.318104] EXT3 FS on hda1, internal journal [ 12.268128] fuse init (API version 7.11) [ 12.360134] device-mapper: uevent: version 1.0.3 [ 12.360463] device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-de...@redhat.com [ 19.557582] kjournald starting. Commit interval 5 seconds [ 19.559201] EXT3 FS on hda5, internal journal [ 19.560545] EXT3-fs: mounted filesystem with ordered data mode. [ 19.579007] kjournald starting. Commit interval 5 seconds [ 19.580646] EXT3 FS on hda6, internal journal [ 19.581939] EXT3-fs: mounted filesystem with ordered data mode. [ 19.595383] kjournald starting. Commit interval 5 seconds [ 19.597036] EXT3 FS on hda7, internal journal [ 19.598323] EXT3-fs: mounted filesystem with ordered data mode. [ 19.632368] kjournald starting. Commit interval 5 seconds [ 19.633956] EXT3 FS on hda8, internal journal [ 19.635234] EXT3-fs: mounted filesystem with ordered data mode. [ 19.716243]
Bug#485704: Burining is still slow
I confirm this behaviour on 2.6.28 (unstable). Haven't tested on 2.6.29 - other error (#521492) occurs. This error occurs on my AMD Duron 32-bit, but burning on AMD 64-bit at work occurs without problem. So far for burning I use 2.6.23, but I wonder how long I will be able to boot with this kernel. I do not know how to debug where problem is - I can do some test if you tell me what to to. Regards. -- Tomasz Rybak bogom...@post.pl GPG key ID: F22C D870 Fingerprint 93BC FEEC A426 3765 799F 10EE FAC1 9A2C F22C D870 http://member.acm.org/~tomaszrybak signature.asc Description: To jest część wiadomości podpisana cyfrowo
