Bug#1031565: ITP: nvidia-nccl -- Optimized primitives for collective multi-GPU communication
On 18/02/2023 19.33, M. Zhou wrote: * License : BSD-3-Clause but has to enter non-free. Why not contrib? A B-D: nvidia-cuda-toolkit does not require the package to be in non-free. BTW, please B-D: nvidia-cuda-toolkit-gcc instead. Andreas
Bug#976707: O: kopanocore - Complete and feature rich groupware solution
On Mon, 07 Dec 2020 10:04:14 +0100 Carsten Schoenert wrote: I (as part of the pkg-giraffe team) intent to orphan src:kopanocore. The pkg-giraffe-team is happy to offer help and guidance for interested people which want to work on kopanocore (and also on related packages) within Debian. Can you move the git repository to the /debian space on salsa.d.o? That would help anyone picking up the package. I might do a QA upload applying the FTBFS patches sitting in the BTS, nothing more ;-) Thanks. Andreas
Bug#1001712: [Pkg-opencl-devel] ROCm RFP
On 14/12/2021 20.10, maxzor wrote: For your information, I just opened this RFP : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001712 . If anybody is already on the job that's great, Not that I'd know. if not I might gather the > energy to withstand the maintainer trial :) I might spend some time reviewing and sponsoring ... Would it be useful to place these packages under the umbrella of Maintainer: Debian OpenCL Maintainers There is more in ROCm than just OpenCL, but I don't know a better fitting team ... Given that there are third-party Debian packages out in the wild, we should ensure that upgrades from third-party packages to official Debian packages (and maybe vice versa) work smoothly. Which means packaging updates probably need to be propagated back to the third-party packaging. (An *no* use of epochs to be newer than the third-party packages!) (I had used the third-party ROCm packages on a Debian system in the past, and IIRC it worked surprisingly well after I figured out that we already had a recent enough kernel to not need the out-of-tree kernel module bits.) Andreas
Bug#985233: O: lmbench -- Utilities to benchmark UNIX systems
Hi Al, On Sun, 14 Mar 2021 15:17:52 -0600 Al Stone wrote: I intend to orphan the lmbench package. I no longer use it, Can you push the changes and tag from the -5 upload, please? And could you try to move the package on salsa from your personal namespace to the 'debian' or 'hpc-team' namespace? (I think that should be Settings -> General -> Advanced -> Transfer project, but I have never used it.) There is no need to do an upload to update the Vcs URLs. Thanks, Andreas, who might adopt it for the HPC team
Bug#940631: ITP: primus-vk -- Vulkan layer for GPU offloading
On 03/10/2019 21.02, Luca Boccassi wrote: > This can be useful for older cards that will not get native support for > optimus in the 435 series and up, so I intend to sponsor it. > > Is it OK for you if I put this in the nvidia-team section on Salsa and > so on? This seems to be the right place for it! Andreas
Bug#812530: ITP: libglvnd -- Vendor-neutral OpenGL dispatch layer
On 2016-12-08 13:31, Timo Aaltonen wrote: > It's there now, but we're still uncertain if mesa will switch to use it > in stretch, and I don't know how nvidia driver migrating to it without > mesa would work? I don't plan to switch to the packaged libglvnd without mesa adopting it as well. Also in the current form (everything in a single package) I cannot use it as a drop-in replacement for the glvnd libraries from nvidia (where I follow a strict one library per package scheme). For the mesa side the question will be: will it be a complete switch over or will there be the possibility to switch between non-glvnd and glvnd based libGL etc.? NVIDIA currently provides both variants for libGL and libEGL, since the glvnd variants have shown some regressions (but I don't know in which applications). For the nvidia driver I provide both variants with the glvnd variant being the preferred alternative. Please keep the Debian NVIDIA Maintainers in the loop if there is progress being made on the MESA side. Andreas
Bug#837731: ITP: otf2 -- Open Trace Format 2
Package: wnpp Severity: wishlist Owner: Andreas Beckmann Control: block 789050 with -1 * Package name: otf2 Version : 2.0 Upstream Author : Copyright (c) 2009-2012, RWTH Aachen University, Germany Copyright (c) 2009-2012, Gesellschaft fuer numerische Simulation mbH Braunschweig, Germany Copyright (c) 2009-2014, Technische Universitaet Dresden, Germany Copyright (c) 2009-2012, University of Oregon, Eugene, USA Copyright (c) 2009-2014, Forschungszentrum Juelich GmbH, Germany Copyright (c) 2009-2014, German Research School for Simulation Sciences GmbH, Juelich/Aachen, Germany Copyright (c) 2009-2013, Technische Universitaet Muenchen, Germany All rights reserved. * URL : http://www.vi-hps.org/projects/score-p/ * License : BSD-3-Clause Programming Lang: (C, C++) Description : Open Trace Format 2 OTF2 is a standard trace format used by several high-performance tools, which supports multiple streams. OTF2 is the successor to the Open Trace Format (OTF), which is packaged as src:otf I need OTF2 as a dependency for packaging Score-P. Andreas
Bug#837729: ITP: cube -- generic tool for displaying a multi-dimensional performance space
Package: wnpp Severity: wishlist Owner: Andreas Beckmann Control: block 789050 with -1 * Package name: cube Version : 4.3.4 Upstream Author : Forschungszentrum Juelich GmbH, Germany German Research School for Simulation Sciences GmbH, Juelich/Aachen, Germany * URL : http://www.scalasca.org/software/cube-4.x/download.html * License : BSD-3-Clause Programming Lang: (C, C++) Description : generic tool for displaying a multi-dimensional performance space Cube, which is used as performance report explorer for Scalasca and Score-P, is a generic tool for displaying a multi-dimensional performance space consisting of the dimensions (i) performance metric, (ii) call path, and (iii) system resource. Each dimension can be represented as a tree, where non-leaf nodes of the tree can be collapsed or expanded to achieve the desired level of granularity. In addition, Cube can display multi-dimensional Cartesian process topologies. The Cube 4.x series report explorer and the associated Cube4 data format is provided for Cube files produced with the Score-P performance instrumentation and measurement infrastructure or the Scalasca version 2.x trace analyzer (and other compatible tools). However, for backwards compatibility, Cube 4.x can also read and display Cube 3.x data. I need Cube as a dependency for packaging Score-P. Andreas
Bug#794643: ITA: sparse -- semantic parser of source files
Hi Uwe, On Wed, 5 Aug 2015 12:38:41 +0200 Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= wrote: > I already worked on packaging a new upstream version of sparse and > fixing a few bugs that are reported in the BTS. > > I'm not a DD yet (but trying to become one) so for now I'm in need for a > sponsor. Having done some QA uploads for sparse, I could sponsor your adoption of the package. One thing I noticed but didn't fix is the non-verbose build, please fix this for 0.5 s.t. the full compile commands are printed. Andreas
Bug#789050: ITP: scorep -- Scalable Performance Measurement Infrastructure for Parallel Codes
Package: wnpp Severity: wishlist Owner: Andreas Beckmann * Package name: scorep Version : 1.4.2 Upstream Author : many ... * URL : http://www.vi-hps.org/projects/score-p/ * License : BSD Programming Lang: C, C++, Python Description : Scalable Performance Measurement Infrastructure for Parallel Codes The Score-P measurement infrastructure is a highly scalable and easy-to-use tool suite for profiling, event tracing, and online analysis of HPC applications. There are a few dependencies that may need to be packaged first: OTF2 1.5.x Cube 4.3 OPARI2 1.1.4 Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150617121429.16974.55634.report...@zam581.zam.kfa-juelich.de
Bug#746352: ITP: nvidia-modprobe -- utility to load nvidia kernel modules and create device nodes
Package: wnpp Severity: wishlist Owner: Andreas Beckmann * Package name: nvidia-modprobe Version : 334.16 Upstream Author : NVIDIA Corporation * URL : ftp://download.nvidia.com/XFree86/nvidia-modprobe/ https://github.com/NVIDIA/nvidia-modprobe * License : GPL2 Programming Lang: C Description : utility to load nvidia kernel modules and create device nodes Nvidia recently introduced a setuid:root tool to ease loading the nvidia kernel modules and create corresponding device nodes. Using this tool now seems mandatory: #745715 Instead of shipping the prebuilt binary (included in the driver blob) we will re-compile it from source (like nvidia-settings and -xconfig). Package will be maintained by the Debian NVIDIA Maintainers and placed in contrib. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140429093119.12554.45913.reportbug@calzone.localnet
Bug#729754: RFP: povray -- persistence of vision raytracer (3D renderer)
Control: retitle -1 ITP: povray -- persistence of vision raytracer (3D renderer) Control: owner -1 ! On Saturday, 16. November 2013 21:13:37 Logan Rosen wrote: > * Package name: povray > Version : 3.7.00 Looks like I (or rather a colleague of mine) will need this, so I'm resurrecting povray. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201401161507.41312.a...@debian.org
Bug#730492: RFH: hdf5
Hi Sylvestre, On 2013-11-25 18:17, Sylvestre Ledru wrote: > If someone wants to step in to help on HDF5, he/she is more than welcome. > > I am planning to maintain it but help is welcome. > For example, some tasks which should be done: > * fix the git repository (git import-orig ../hdf5_1.8.12.orig.tar.gz fails > with conflicts) > * package the new upstream release (1.8.12) /!\ in the release 11, the SONAME > was wrongly changed > to 8 for no real reason. We should check if the 8 is deserved or not. > * backport the arm64 ubuntu changes I don't really know what hdf5 is ... :-) but I remember working on fixing upgrade issues for wheezy (got this into wheezy after all?) and having some ideas how this could be improved in general ... Looking at the git repository, this seems to miss a lot of tags. If you have some unpushed tags lying around, please push them. Otherwise they need to be reconstructed ... I don't want to maintain HDF5, but I could help fixing some issues. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52979062.80...@debian.org
Bug#729660: ITP: xemacs21 -- highly customizable text editor
There was a nice bunch of (5-digit) bugs being closed with the removal, they should be unarchived, reopened and handled properly if xemacs comes back. from https://ftp-master.debian.org/removals.txt: = [Date: Sun, 13 Oct 2013 09:51:22 +] [ftpmaster: Ansgar Burchardt] Removed the following packages from unstable: [...] xemacs21-packages | 2009.02.17.dfsg.1-1 | source Closed bugs: 726023 --- Reason --- RoQA; RC-buggy, unmaintained, dead upstream, not in stable -- Also closing bug(s): 46985 54387 56180 62287 63340 64290 64723 65469 74787 76139 76938 79127 82417 87623 87723 92073 95825 113489 113598 113599 116355 120985 123882 132544 133894 134426 137251 143163 143363 145279 146844 153113 154971 160740 162587 163957 163958 163961 163962 171150 183004 231059 236070 246638 248545 277451 281891 318020 320339 326783 327259 399483 403611 403771 440460 513574 522670 527389 609603 665253 683700 695799 699543 709501 712316 Also closing WNPP bug(s): = = [Date: Sun, 13 Oct 2013 09:52:05 +] [ftpmaster: Ansgar Burchardt] Removed the following packages from unstable: xemacs21 | 21.4.22-4 | source, all [...] Closed bugs: 725883 --- Reason --- RoQA; RC-buggy, unmaintained, dead upstream, not in stable -- Also closing bug(s): 39667 40202 40203 42457 47287 47515 49056 50712 51542 54069 54857 55892 56542 57468 60974 61132 61355 61665 62005 63285 63476 63697 63707 63744 64058 64513 64835 65494 66408 67045 67386 68017 72210 74084 74104 75456 75920 75998 76992 77372 77558 78446 78447 79144 80280 81915 83610 85817 88953 90542 92310 94623 98489 98501 99501 100956 101759 102513 104211 104213 104758 105928 106146 107168 107472 107776 108633 109032 109187 109738 110584 110646 110778 110976 112894 113368 113491 113585 114693 114797 117731 118828 122992 126074 126298 126773 128065 133822 134172 134689 135362 135805 142197 142555 143039 143107 143231 143915 144096 144413 145799 145847 146542 14 147171 147426 147556 147830 148750 150692 152878 153224 153778 154725 155424 155740 156144 156513 156515 156874 157858 158314 158573 160377 163219 164734 165503 167335 169016 171263 171433 171824 171830 173557 174489 175050 175234 177269 179649 180895 181129 182062 183119 183866 184197 186294 187609 187999 190163 192072 192075 194161 196524 196870 197301 198485 200717 200781 203879 204817 204852 206118 206381 206530 209157 209594 214638 216775 217341 219098 219809 224373 226734 229822 230792 234193 234204 234392 243683 245389 250314 254734 258572 268832 268833 268835 269244 272243 272452 273817 282275 282610 283159 283415 283569 285990 292438 296339 297916 301750 301752 304800 307617 309747 310799 312919 317725 331315 333845 334830 336445 338066 341005 343083 343330 343663 350003 350081 353077 355026 355348 355349 356584 357045 364433 365927 374198 374808 377962 382427 382434 395209 398756 399269 400859 403425 403877 410482 419922 422731 431252 431910 434468 438513 442428 444614 446137 446889 449294 463684 477623 485736 497262 507866 527966 528900 529607 539834 542492 563714 576747 580611 586785 589138 598320 608691 619367 634666 649686 650581 662557 681407 696146 712355 Also closing WNPP bug(s): = Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5286cb0c.9010...@debian.org
Bug#719909: ITP: libclc -- Implementation of OpenCL 1.1
On 2013-08-16 18:59, Julian Wollrath wrote: > * Package name: libclc Please join the OpenCL team: pkg-opencl-de...@lists.alioth.debian.org to coordinate that all packaging of OpenCL stuff in Debian is compatible. > libclc is an open source, BSD/MIT dual licensed implementation of the library > requirements of the OpenCL C programming language, as specified by the > OpenCL 1.1 Specification. Is this an ICD? An implementation of libOpenCL.so.1? > [0] http://git.debian.org/?p=users/jw-guest/libclc.git Do you have upstream and pristine-tar branches you could push to the repository, too? Thanks Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/520e67de.20...@debian.org
Bug#702243: ITP: papi: --> papi-examples
Hi Vincent, the papi-examples package contains the prebuilt binaries, but they are not really useful: * statically linked (=> huge Installed-Size: 39582 [amd64]) * missing executable bit * gzip compressed I'd suggest shipping them dynamically linked, executabel and uncompressed - or not at all, just ship the source and let the user build them. The source code is missing some parts to be useful (i.e. you can't compile the examples without these): * Makefile * papi_test.h (which is being searched in ../testlib) * the testlib content: Makefile clockcore.c do_loops.c dummy.c papi_test.h test_utils.c test_utils.h Andreas PS: more packing bugs will be found as I do more tests with papi :-) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51601447.4070...@debian.org
Bug#702243: ITP: papi: --> FTBFS: test failure
Hi Vincent, I just tried your papi package from git, but came across the following build failure: make[2]: Leaving directory `/tmp/buildd/papi-5.1.0.2/src/ctests' export LD_LIBRARY_PATH=/tmp/buildd/papi-5.1.0.2/src:/tmp/buildd/papi-5.1.0.2/src/libpfm-3.y/lib:/tmp/buildd/papi-5.1.0.2/src/libpfm4/lib;export LIBPATH=.:./libpfm-3.y/lib:./libpfm4/lib; ctests/zero Test case 0: start, stop. --- Default domain is: 1 (PAPI_DOM_USER) Default granularity is: 1 (PAPI_GRN_THR) Using 2000 iterations of c += a*b - Test type: 1 PAPI_TOT_INS : 14188 PAPI_TOT_CYC : 80261026 Real usec: 23610 Real cycles : 80510468 Virt usec: 23563 Virt cycles : 80137763 - Verification: PAPI_TOT_CYC should be roughly real_cycles NOTE: Not true if dynamic frequency scaling is enabled. Verification: PAPI_FP_INS should be roughly 4000 PAPI_TOT_INS Error of 250.00% zero.c FAILED Line # 130 Error: FLOPS validation make[1]: *** [test] Error 1 CPU is an x86_64 Intel Ivy Bridge model name : Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz with TurboBoost disabled and I fully loaded the CPU to avoid any frequency up-scaling while building/testing papi. Building with DEB_BUILD_OPTIONS=nocheck succeeds. The error message is not helpful, there is no PAPI_FP_INS in the above output and no figures the are somehow 250.00% "off". Andreas Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130325200914.21260.86247.report...@zam904.zam.kfa-juelich.de
Bug#703060: ITP: i7z -- a better reporting tool for i7, i5, i3 CPUs
Package: wnpp Severity: wishlist Owner: Andreas Beckmann * Package name: i7z Version : 0.27.1 Upstream Author : Abhishek Jaiantilal (abhishek.jaiantilal (@@) colorado.edu) * URL : http://code.google.com/p/i7z/ * License : GPL2, GPL3 Programming Lang: C, Ruby Description : a better reporting tool for i7, i5, i3 CPUs i7z is a tool to report CPU information about TurboBoost, frequencies, multipliers, ... and a top-like display for the current frequency, temperature and time spent in the C0/C1/C3/C6/C7 states. There is also a i7z_rw_registers script that allows toggling Turbo mode or set multipliers. It comes wiht a GUI (written in QT), but that has not been updated for SandyBridge/IviBridge CPUs. I plan to put the packaging into collab-maint. Or is there a team that would like to include that package under its umbrella? Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130314191233.22735.53241.report...@cake.ae.cs.uni-frankfurt.de
Bug#698656: ITP: adequate -- Debian package quality testing tool
On 2013-01-21 21:07, Jakub Wilk wrote: > adequate checks quality of installed packages. can it be used on chroots without being installed in the chroot? like adequate --root=/some/chroot mypkg > The following checks are currently implemented: > * broken symlinks; > * missing copyright file; > * obsolete conffiles; > * Python modules not byte-compiled; ahh, a patch for #635139 :-) > * /bin and /sbin binaries requiring /usr/lib libraries; > * underlinked binaries or libraries. Sounds intersting. A few of them are already reported by piuparts, but I could consider replacing them by an adequate test run there, too (with a --root option, like we do with debsums). Having a "lightweight" tool (compared to running piuparts locally) to check for these issues sounds like a good idea. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50fda7f7.3070...@abeckmann.de
Bug#659440: bumblebee packaging
On 2013-01-21 10:12, Vincent Cheng wrote: > On Sat, Jan 19, 2013 at 9:24 AM, Aron Xu wrote: >> I've made some progress on bumblebee and pushed to pkg-nvidia repo: > I've made a number of small changes to take into account certain > differences between Debian and Ubuntu's packaging of nvidia's > proprietary drivers [1][2] and added an udev rule to fix a bug [3]. Nice too see some progress :-) Are there any problems you encounter with the nvidia driver packaging in Debian? Please also test with nvidia-kernel-common and glx-alternative-* from experimental (they change the kernel module blacklist handling to be controlled with the glx alternatives, a update-initramfs call may be needed in addition to update-alternatives, but therefore you can disable the blacklist without manually doing rm or dpkg --purge). One of the goals of the current packaging is usability in live systems - having all the proprietary drivers co-installable and allow them to be installed but deactivated, so that some (yet to be written) utility could detect hardware, switch alternatives, and create X config. It would be nice if bumblebee would somehow integrate in this. (Disclaimer: I don't do anything -live myself.) Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50fd0f88.6080...@abeckmann.de
Bug#659440: ITP: primus -- Low-overhead client-side GPU offloading
On 2013-01-07 07:29, Vincent Cheng wrote: > think anyone who's currently in the pkg-nvidia team (Russ/Andreas?) > has commented on whether or not they'd like to have primus maintained > within the team. I don't really care - optimus, primus, bumblebee, ... is stuff I'm (currently) not being interested in - but I appreciate your work on these things. I welcome everyone working on something related to (proprietary) Nvidia stuff to join the team, and publish packages either under the team umbrella or separately. Time will show whether some piece of contrib software will find more general use (e.g. src:khronos-opencl-headers moved to main, but that does not mean we need to kick out of the team - but if a more suitable team comes around we could hand it over ...) Being a member of a team does not mean you have to care about every package managed by the team ... but it may simplify discussion and sponsoring. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50eabe69.2090...@abeckmann.de
Bug#680654: news
On 2012-07-25 13:36, Michał wrote: > Download server is available. > Have you any news about progress? that was the fglrx legacy bug? I'm just waiting for fglrx-driver to clear NEW due to a package rename needed for cooperation with -legacy. Thereafter I'll take care for an upload to experimental. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5010019c.5010...@abeckmann.de
Bug#680654: ITP: fglrx-driver-legacy -- non-free legacy ATI/AMD RadeonHD display driver
Package: wnpp Severity: wishlist Owner: Andreas Beckmann * Package name: fglrx-driver-legacy Version : 12.6~beta Upstream Author : AMD/ATI * URL : http://support.amd.com/us/kbarticles/Pages/catalyst126legacyproducts.aspx * License : proprietary Programming Lang: precompiled binaries Description : non-free legacy ATI/AMD RadeonHD display driver Re-adds support for the AMD Radeon HD 4000, AMD Radeon HD 3000, and AMD Radeon HD 2000 Series which was dropped in fglrx-driver 12-6. According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675940#77 this supports Xorg Xserver 1.12 Unfortunately the download server is currently unreachable (missing DNS records). Package will be handled by the Fglrx packaging team. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120707182608.1756.65534.report...@cake.ae.cs.uni-frankfurt.de
Bug#675528: ITP: ocl-icd -- Generic OpenCL ICD Loader
On 2012-06-02 00:38, Vincent Danjean wrote: > So, is it possible to upload opencl-headers to main instead of > contrib? Package updated and upload requested ... > This source package will provide two binary pakages: > Package: ocl-icd-libopencl1 > Description: Generic OpenCL ICD Loader > OpenCL (Open Computing Language) is a multivendor open standard for > general-purpose parallel programming of heterogeneous systems that include > CPUs, GPUs and other processors. > . > This package contains an installable client driver loader (ICD Loader) > library that can be used to load any (free or non-free) installable client > driver (ICD) for OpenCL. It acts as a demultiplexer so several ICD can > be installed and used together. If that is compatible with all the implementations, couldn't we just call it libopencl1? (+Conflicts/Replaces: libopencl1) And there should be a corresponding libopencl1-dev package, too. As that's probably what users need for their OpenCL applications. > Package: ocl-icd-dev > Description: Development files to build a ICD Loader > OpenCL (Open Computing Language) is a multivendor open standard for > general-purpose parallel programming of heterogeneous systems that include > CPUs, GPUs and other processors. > . > This package provides a header file that allows a OpenCL implementation > to build a installable client driver (ICD). With a ICD, an OpenCL > implementation can be used by any OpenCL program without the need > to link the program to the specific OpenCL implementation. Add something like: . For building OpenCL applications install the libopencl1-dev package instead. > A few word about the context. There exist lots of OpenCL implementations. > A OpenCL program can either link to a specific OpenCL implementation IIRC there is non of these packaged in Debian > or it can link to a standardized libOpenCL library that allows the > program to dynamically choose the OpenCL implementation or even to > use several OpenCL implementations in the same program. In fact > libOpenCL is only a wrapper (more exactly a dispatcher) to > OpenCL implementations provided as ICD. currently nvidia-libopencl1 [non-free] and amd-libopencl1 [non-free] available - eventually these could be phased out in favor of a free one Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fcb61ee.5070...@abeckmann.de
Bug#649514: nvidia-cg-toolkit: should this package be orphaned?
On 2012-05-24 14:57, Mathieu Malaterre wrote: > git clone git://github.com/anbe42/nvidia-cg-toolkit.git > cd nvidia-cg-toolkit > git checkout prepare-3.1v2 > make -f ./debian/rules get-orig-source > mv nvidia-cg-toolkit_3.1.0013.orig-amd64.tar.gz > nvidia-cg-toolkit_3.1.0013.orig-i386.tar.gz .. > dpkg-buildpackage -rfakeroot -us -uc > make[1]: Entering directory `/tmp/nn/nvidia-cg-toolkit' > /usr/bin/make -C amd64/local/Cg/examples/Tools/cginfo/ \ > CG_INC_PATH=/tmp/nn/nvidia-cg-toolkit/amd64/include > make: Entering an unknown directory > make: *** amd64/local/Cg/examples/Tools/cginfo/: No such file or > directory. Stop. That's not a proper unpacked source directory. But yes, we should probably add something to README.source explaining how to build from git. We could also add override_dh_autobuild: test -d i386 && test -d amd64 || \ ( echo source not unpackaged ; exit 1 ) I don't know a good replacement for the mergwithupstream mode from svn-buildpackage. How can something similar be done with git? I don't really want to add the unpacked blobs to git (at least as long as pristine-tar does not cope well with multiple source tarballs). As I only tested the build process with pbuilder (pdebuild) this was working fine for me because it first creates a source package (warning about a lot of ignored deletions) and thereafter has a complete source tree ... > trailing comma is not well handled by BTS, see extra '(u)' for instance at: > http://packages.qa.debian.org/k/khronos-opencl-headers.html I'd consider this a bug in the PTS. dch had similar problems but should have been fixed recently. Andreas PS: Miguel and Mathieu, are you subscribed to pkg-nvidia-devel@ ? So we could drop a few Cc:s -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fbe3be9.5070...@abeckmann.de
Bug#649514: nvidia-cg-toolkit: should this package be orphaned?
Hi Miguel, a heavily shuffled, merged, rebased and cleaned up branch can be found here: git://github.com/anbe42/nvidia-cg-toolkit.git prepare-3.1v2 History is arranged to continuously build working packages as commits fly by and changelog was rewritten to match. I'm going to do some upgrade tests before I push this to git.d.o Please test if this still works as expected. I also fixed the hardening, --as-needed, and lintian issues. I removed the Replaces as there were no file conflicts dpkg would have to handle. Breaks is sufficient to get rid of the old package. Please don't drop DMUA or trailing comma on Uploaders. If this package is fine fou you, dch -r && git commit && push to github somewhere && update mentors Nvidia also offers a .deb package 'nvidia-cg-toolkit' that would conflict with our split up package if a user would upgrade from our new packaging to this package. (It also comes with some insanities like /usr/lib64.) Do we want to handle this somehow? Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fbe2dca.2030...@abeckmann.de
Bug#649514: nvidia-cg-toolkit: should this package be orphaned?
On 2012-05-16 19:24, Miguel A. Colón Vélez wrote: >> Let me know if you need me to upload the package. > > Well there was a reply 10 days ago from the team after a few months of > silence: > http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/2012-May/007273.html > http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/2012-May/007275.html > > Although "next week" is over, I remember some drivers got uploaded to > experimental/sid on the 9th so hopefully it will get reviewed, fixed > if needed and uploaded soon :). Nvidia had released a lot of updates ... that got priority :-) Thereafter I've been offline for a good week and now I need to catch up with stuff that happened inbetween. Like 3 driver upgrades including the 173.xx legacy one :-) I'd like to give nvidia-cg-toolkit a review, but probably only at the end of this week. Mathieu, can you delay the upload you did a bit further? Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fba38be.4050...@abeckmann.de
Bug#662840: ITP: wims-java-applets -- applets for modules used by the WIMS server
On 2012-03-06 19:43, Georges Khaznadar wrote: > Programming Lang: Java > Description : applets for modules used by the WIMS server > This package was formerly made from the source package for wims. > However, wims cannot be built completely on architectures which have > no JVM available, so it could not enter testing. Hence the separation of the > source packages. Why can't these java package(s) just be not built on "non-java" architectures? I just looked around a bit around with build-rdeps openjdk-6-jdk and then ran rmadison on randomly selected resulting packages to find some that have Arch: any packages in addition to the java ones ... First hit was swi-prolog You may want to take a look at their approach to combine building both Arch: any and *-java packages from one source. It seems to boil down to make the java package(s) Arch: some instead of Arch: all. IIRC splitting source packages to create multiple source packages (or reintroducing copies of the same source in the archive) is not recommended. I'm pretty sure the problem of Arch: all packages being not buildable on all architectures (because some build-deps(-indep) are not available on all architectures) has been discussed before. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f577fbf.3010...@abeckmann.de
Bug#642198: Bug#648286: ITP: r8168 -- Realtek r8168 device driver for Linux (DKMS version)
On 2011-11-13 16:59, Patrick Matthäi wrote: > Am 13.11.2011 15:08, schrieb Andreas Beckmann: >> I just revived my old ITP http://bugs.debian.org/642198 Updated packaging is available at git://github.com/anbe42/r8168.git Patrick, you may want to test it. Also testing to switch back from r8168 to r8169 would be interesting. > But btw isn't http://code.google.com/p/r8168/ the better homepage for it? That's an unofficial mirror, so I wouldn't take it for the Homepage. But at least we can use it for the watch file. > [...] and I am still available to sponsor the upload :) I still offer to maintain the package (or co-maintain it with Dmitry). But I don't have any NIC that requires r8168 (on a quick glance I didn't even find anything using r8169), so I can't test beyond module compilation. If you want to see it rather in non-free than in main, please say so. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ec10d96.4040...@abeckmann.de
Bug#648286: ITP: r8168 -- Realtek r8168 device driver for Linux (DKMS version)
On 2011-11-12 19:04, Patrick Matthäi wrote: > @Andreas and Dmitry: > You may cooperate on packaging or decide, who wants to maintain it in > the future. I just revived my old ITP http://bugs.debian.org/642198 and tried to put my things in a git repository: Only git://git.debian.org/~anbe-guest/r8168.git seems to work so far. > @Ben: > I still think this driver should be added as alternative driver to the > archive, until r8169 will do its job for the promoted PCIIDs correctly. One possible solution I see would be to upload r8168 to sid (or experimental) and add a severity=serious bug "r8168 should not enter testing - let's fix r8169 in the kernel instead" to prevent migration. Documentation should include detailed instructions how to properly report bugs for the in-kernel r8169 if it does not work (but r8168 does). Do I see it correctly that this driver is to be classified as non-free? The source code says "GPL2+", but 50% of the source lines is something like mdio_write(tp, 0x1E, 0x0078); making this look very 'blobby'. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ebfcf49.5070...@abeckmann.de
Bug#642198: ITP: r8168 -- dkms source for the r8168 network driver
On 2011-09-20 14:30, Ben Hutchings wrote: > On Tue, 2011-09-20 at 14:23 +0200, Stefan Lippers-Hollmann wrote: >> Personally speaking I'd assume this package would create much more >> problems than it would solve, due to the PCI ID overlap with r8169.ko >> shipped by the kernel packages themselves. This driver claims >> 10ec:8168, which is also taken by the in-kernel r8169.ko module. > [...] > > Agree, this should not be added to the archive. OK, that's fine. I don't really care. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e7901d4.40...@abeckmann.de
Bug#642198: Acknowledgement (ITP: r8168 -- dkms source for the r8168 network driver)
Uploaded to mentors, needs a sponsor: http://mentors.debian.net/package/r8168 Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e785a8f.6080...@abeckmann.de
Bug#642198: ITP: r8168 -- dkms source for the r8168 network driver
Package: wnpp Severity: wishlist Owner: Andreas Beckmann * Package name: r8168 Version : 8.025.00 Upstream Author : Realtek NIC software team * URL : http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false#2 * License : GPL2+ Programming Lang: C Description : dkms source for the r8168 network driver r8168 is the Linux device driver released for RealTek RTL8168B/8111B, RTL8168C/8111C, RTL8168CP/8111CP, RTL8168D/8111D, and RTL8168DP/8111DP, and RTK8168E/8111E Gigabit Ethernet controllers with PCI-Express interface. . This driver should only used for devices not yet supported by the in-kernel driver r8169. . This package provides the dkms source code for the r8168 kernel modules. Kernel source or headers are required to compile these modules. I just came along this in #debian last week, helping someone to get this module built and installed (upstream build system does not work properly on kernel 3.x) because the in-kernel module r8169 did not support his NIC. I did this package just as a first experiment with dkms, the module builds fine with squeeze and sid kernels. I don't have the hardware to actually test it. So if someone who actually needs it wants to take over maintainership, he is welcome. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110920084647.2061.97568.reportbug@calzone.localnet
Bug#631661: ITP: vdpauinfo -- Video Decode and Presentation API for Unix (vdpauinfo utility)
Package: wnpp Severity: wishlist Owner: Andreas Beckmann * Package name: vdpauinfo Version : 0.0.6 Upstream Author : Wladimir J. van der Laan * URL : http://cgit.freedesktop.org/~aplattner/vdpauinfo * License : Expat Programming Lang: C++ Description : Video Decode and Presentation API for Unix (vdpauinfo utility) VDPAU (Video Decode and Presentation API for Unix) is an open source library (libvdpau) and API designed by NVIDIA originally for its GeForce 8 series and later GPU hardware, targeted at the X Window System on Unix operating-systems (including Linux, FreeBSD, and Solaris). This VDPAU API allows video programs to offload portions of the video decoding process and video post-processing to the GPU video-hardware. . This package contains the vdpauinfo utility. Preliminary packaging is available here: svn://svn.debian.org/svn/pkg-nvidia/packages/vdpauinfo/trunk Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110625204143.19381.27965.reportbug@calzone.localnet
Bug#629518: Preliminary AMD APP SDK Packaging
On 2011-06-16 10:05, Tomasz Rybak wrote: > 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? I'm not yet sure what to put into this package ... > lintian complains about: > W: amd-libopencl1: package-name-doesnt-match-sonames libOpenCL1 I hope some vendor would release a free version of these libraries - like nvidia did with libvdpau1. It's just a generic wrapper, not an implentation. > At the same time I was not able to install amd-libopencl1: > Translation - both nvidia-libopencl1 and amd-libopencl1 provide > libopencl1 and as nvidia-libopencl1 is properly installed > dpkg will not install amd-libopencl1. libopencl1 is just a generic loader and can use any implementation (the icd packages). > 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. Unfortunately nvidia and amd implementations are not identical (symbol versioning etc.) and the amd one seems to work a bit better with amd than nvidia-libopencl1. nvidia icd seems to work the same with both implemntations. (the oclinfo program from amd crashed at some point with nvidia-libopencl1) > 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. That was the idea behind OpenCL and my packaging. > 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. May be a good idea. But finally we would need some shlibs magic to map the dependency on -libopencl1 to libopencl1. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df9fbc4.10...@abeckmann.de
Bug#629518: Preliminary AMD APP SDK Packaging
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. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df801f1.4080...@abeckmann.de
Bug#628195: ITP: libthrust -- C++ template library for CUDA
Package: wnpp Severity: wishlist Owner: Andreas Beckmann * Package name: libthrust Version : 1.4.0 Upstream Author : Jared Hoberock and Nathan Bell (both from NVIDIA research) * URL : http://thrust.googlecode.com/ * License : Apache-2.0, some files also Boost-1.0 Programming Lang: C++/CUDA Description : Thrust - C++ template library for CUDA Thrust is a CUDA library of parallel algorithms with an interface resembling the C++ Standard Template Library (STL). Thrust provides a flexible high-level interface for GPU programming that greatly enhances developer productivity. Develop high-performance applications rapidly with Thrust! . The Compute Unified Device Architecture (CUDA) enables NVIDIA graphics processing units (GPUs) to be used for massively parallel general purpose computation. Package can be found here: svn://svn.debian.org/svn/pkg-nvidia/packages/libthrust/trunk Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110528072112.23903.81975.report...@cake.ae.cs.uni-frankfurt.de
Bug#598477: preliminary khronos-opencl-headers packages uploaded to mentors.d.o
Preliminary packages (for contrib, not main) can be found here: http://mentors.debian.net/debian/pool/contrib/k/khronos-opencl-headers/ Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cabce2d.9040...@abeckmann.de
Bug#598477: ITP: opencl-headers -- OpenCL (Open Computing Language) header files
Package: wnpp Severity: wishlist Owner: Andreas Beckmann * Package name: opencl-headers Version : 1.0 Upstream Author : The Khronos Group Inc. * URL : http://www.khronos.org/registry/cl/ * License : other Programming Lang: Header files for C, C++ Description : OpenCL (Open Computing Language) header files OpenCL (Open Computing Language) is a multi-vendor open standard for general-purpose parallel programming of heterogeneous systems that include CPUs, GPUs and other processors. . This package provides the development header files for the OpenCL API 1.0 as published by The Khronos Group Inc. The corresponding specification and documentation can be found on the Khronos website. Copyright/License: * Copyright (c) 2008-2010 The Khronos Group Inc. * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and/or associated documentation files (the * "Materials"), to deal in the Materials without restriction, including * without limitation the rights to use, copy, modify, merge, publish, * distribute, sublicense, and/or sell copies of the Materials, and to * permit persons to whom the Materials are furnished to do so, subject to * the following conditions: * * The above copyright notice and this permission notice shall be included * in all copies or substantial portions of the Materials. * * THE MATERIALS ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. * IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY * CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE * MATERIALS OR THE USE OR OTHER DEALINGS IN THE MATERIALS. I plan to put this header package into main (because the headers are free) and not contrib (even if currently only non-free vendor implementations of OpenCL are available). The hope is there will be a free version of the "wrapper library" libOpenCL.so.1 some day. The same happened recently for libvdpau1. A subset of these headers is currently distributed with nvidia-libopencl1-dev in non-free but NVIDIA will stop shipping them in the next driver release (because they are also shipped in the NVIDIA CUDA Toolkit - which I ITPed as nvidia-cuda-toolkit, #581184 and is currently waiting in NEW). So I think moving to a free source for the headers now is a good idea :-) There is currently one package (python-pyopencl/contrib) that can use OpenCL without requiring nvidia-cuda-toolkit (just needs the headers and some libOpenCL.so.1). I'll start providing the headers for API 1.0 and switch to 1.1 once nvidia-graphics-drivers (>= 260) (which implements 1.1) is in unstable/non-free (or experimental/non-free). Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100929103425.19752.90420.report...@calzone.localnet
Bug#581184: preliminary packages of nvidia-cuda-toolkit 3.1 available
Preliminary packages of nvidia-cuda-toolkit 3.1 are available at: http://stxxl.ae.cs.uni-frankfurt.de/tmp/582ce36a-592b-4677-9c3b-86ed21603fd9/ The package was uploaded to mentors.d.net and I asked my sponsor to upload it to Debian. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c273427.4070...@abeckmann.de
Bug#581184: preliminary packages of nvidia-cuda-toolkit 3.0 available
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. Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c0f7164.1080...@abeckmann.de
Bug#581184: ITP: nvidia-cuda-toolkit -- NVIDIA CUDA toolkit
Package: wnpp
Severity: wishlist
Owner: Andreas Beckmann
Owner: Andreas Beckmann
* Package name: nvidia-cuda-toolkit
Version : 2.3 / 3.0
Upstream Author : NVIDIA Corporation
* URL : http://www.nvidia.com/CUDA
* License : non-free, NVIDIA
Programming Lang: binaries only
Description : NVIDIA CUDA toolkit
The Compute Unified Device Architecture (CUDA) enables NVIDIA
graphics processing units (GPUs) to be used for massively parallel
general purpose computation.
Preliminary packages can be found here:
http://stxxl.ae.cs.uni-frankfurt.de/tmp/582ce36a-592b-4677-9c3b-86ed21603fd9/
The following binary packages are created by the packaging I have done
so far:
Package: nvidia-cuda-toolkit
Description: NVIDIA CUDA toolkit
Package: nvidia-cuda-doc
Description: NVIDIA CUDA documentation
Package: nvidia-cuda-gdb
Description: NVIDIA CUDA GDB
Package: nvidia-cuda-profiler
Description: NVIDIA CUDA Visual Profiler
Package: nvidia-cuda-dev
Description: NVIDIA CUDA development files
Package: libcudart2
Description: NVIDIA CUDA runtime library
Package: lib32cudart2
Description: NVIDIA CUDA runtime library (32-bit)
Package: libcublas2
Description: NVIDIA CUDA blas runtime library
Package: lib32cublas2
Description: NVIDIA CUDA blas runtime library (32-bit)
Package: libcublasemu2
Description: NVIDIA CUDA blas runtime library (device emulation)
Package: lib32cublasemu2
Description: NVIDIA CUDA blas runtime library (32-bit, device emulation)
Package: libcufft2
Description: NVIDIA CUDA fft runtime library
Package: lib32cufft2
Description: NVIDIA CUDA fft runtime library (32-bit)
Package: libcufftemu2
Description: NVIDIA CUDA fft runtime library (device emulation)
Package: lib32cufftemu2
Description: NVIDIA CUDA fft runtime library (32-bit, device emulation)
Suggestions welcome!
My intent is to offer this package to the Debian NVIDIA team once it is
finished and to remain as active uploader afterwards.
Russ Allbery from the Debian NVIDIA team has already
agreed to sponsor the upload.
I'll update to toolkit 3.0 once the new nvidia-graphics-drivers 195.xx
release has passed NEW, as this is a dependancy of the newer toolkit release.
The copyright file from my local package follows,
it includes the NVIDIA License, also available at
http://developer.download.nvidia.com/compute/cuda/2_3/toolkit/docs/cudatoolkit_eula.txt
Please note 2.1.3: Linux/FreeBSD Exception - that gives permission to
redistribute unmodified binaries (like for nvidia-graphics-drivers).
This package was debianized by Andreas Beckmann on
Sat, 29 Nov 2008 17:00:44 +0100.
It was downloaded from
http://developer.download.nvidia.com/compute/cuda/2_3/toolkit/docs/cudatoolkit_eula.txt
http://developer.download.nvidia.com/compute/cuda/2_3/toolkit/cudatoolkit_2.3_linux_32_ubuntu9.04.run
http://developer.download.nvidia.com/compute/cuda/2_3/toolkit/cudatoolkit_2.3_linux_64_ubuntu9.04.run
Upstream Author:
NVIDIA Corporation
Copyright:
Copyright (C) 1993-2009 NVIDIA Corporation. All rights reserved.
License:
License Agreement for NVIDIA CUDA Toolkit
IMPORTANT NOTICE -- READ CAREFULLY: This License Agreement ("License")
for NVIDIA CUDA Toolkit, including computer software and associated
documentation ("Software"), is the LICENSE which governs use of
the SOFTWARE of NVIDIA Corporation and its subsidiaries ("NVIDIA")
downloadable herefrom. By downloading, installing, copying, or otherwise
using the SOFTWARE, You (as defined below) agree to be bound by the
terms of this LICENSE. If You do not agree to the terms of this LICENSE,
do not download the SOFTWARE.
RECITALS
Use of NVIDIA's products requires three elements: the SOFTWARE,
the NVIDIA GPU, and a computer system. The SOFTWARE is protected by
copyright laws and international copyright treaties, as well as other
intellectual property laws and treaties. The SOFTWARE is not sold, and
instead is only licensed for Your use, strictly in accordance with this
document. The hardware is protected by various patents, and is sold, but
this LICENSE does not cover that sale, since it may not necessarily be
sold as a package with the SOFTWARE. This LICENSE sets forth the terms
and conditions of the SOFTWARE LICENSE only.
1. DEFINITIONS
1.1 Licensee. "Licensee," "You," or "Your" shall mean the entity or
individual that downloads and uses the SOFTWARE.
2. GRANT OF LICENSE
2.1 Rights and Limitations of Grant. NVIDIA hereby grants Licensee the
following non-exclusive, non-transferable, non-sublicensable (except as
stated otherwise below) right to use the SOFTWARE, with the following
limitations:
2.1.1 Usage Rights. Licensee may install and use multiple copies of the
SOFTWARE on a shared computer or concurrently on different computers,
and make multiple back-up copies of th
Bug#496220: libapache2-mod-xsendfile_0.9-0.0anbe1.diff.gz
Hi Marco, here is my mod_xsendfile .diff.gz to be used with http://tn123.ath.cx/mod_xsendfile/mod_xsendfile-0.9.tar.gz Packaging was updated today for latest debhelper, Standards-Version, Maintainer. Andreas libapache2-mod-xsendfile_0.9-0.0anbe1.diff.gz Description: GNU Zip compressed data
Bug#496220: changing to ITP
Marco Nenciarini wrote: > Andreas, are you still interested to help in maintaining it? Yes, I'm still here to help! Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549626: [pkg-nvidia-devel] Bug#547248: ITP: libvdpau -- Video Decode and Presentation API for Unix
Andres Mejia wrote:
> One concern I have is with the trace library, libvdpau_trace.so. If this
> library is not going to supply any versioning, than this library should reside
> in a subdirectory in /usr/lib. For example, we could follow the same scheme
> adopted by pulseaudio, have the trace library installed in
> /usr/lib/vdpau-0.2/modules.
As I understand it, both libvdpau_trace.so and libvdpau_$VENDOR.so (with
$VENDOR = nvidia for now) are "plugins", dlopen()ed from libvdpau.so.1
(and have no proper versioning like most plugins).
So if the wrapper can be patched to search in a subdirectory of /usr/lib
(and /usr/lib32 or /usr/lib64 where appropriate) both the trace library
and the vendor implementation can be moved out of /usr/lib{,32,64}
For the subdirectory something like just /usr/lib/vdpau or
/usr/lib/vdpau-$PLUGINABI might be a better choice, as the interface
(version number) of the vdpau wrapper might evolve while staying "plugin
compatible" (using some kind of capability interface).
Or /usr/lib/vdpau for the vendor implementation, /usr/lib/libvdpau1 for
the trace library/plugin (which will always match the wrapper library
because they are supplied by the same package, so no ABI issues at all
involving the trace library)
> If the library is to be ABI compatible across different revisions, than
> versioning info should be added to the library instead.
BTW, what about building a lib32vdpau1 package on amd64, too? This will
be needed by libvdpau*-nvidia-ia32. Or are there chances to get
libvdpau1 into ia32-libs(-whatever) in time?
Andreas
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#419746: current websites releated to Debian packaging efforts of zfs-fuse
Looking into zfs-fuse and after seeing several outdated websites and packages I came across some more current information: First the zfs-fuse discussion group: http://groups.google.com/group/zfs-fuse/about There is also a Debian git repository (0.5.0): http://git.debian.org/?p=users/glandium/zfs-fuse.git;a=summary and Ubuntu Packages (0.5.1): https://launchpad.net/~brcha/+archive/ppa rebuilding the source package on unstable worked flawlessly Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#496220: libapache2-mod-xsendfile Debian package
Based on the package for Ubuntu hardy [1] I built a Debian package. This will be tested in a development environment in the next days. If anyone is interested, I can make the packages publically available. I also offer to take this RFP, turn it into an ITP and become (co-)maintainer of the package. But I'll need a sponsor to upload it. Andreas [1] https://bugs.launchpad.net/ubuntu/+bug/194122 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#481858: packaging App::SVN::Bisect with dh-make-perl
Hi, building a App::SVN::Bisect package is quite easy using dh-make-perl (from the dh-make-perl package). Just run dh-make-perl --cpan App::SVN::Bisect and change to the newly created folder App-SVN-Bisect-0.4 Now edit the debian/control file (created by dh-make-perl) and add the following to Build-Depends-Indep: libio-all-perl, libyaml-perl, subversion and to Depends: subversion Now you can build the package with debuild. Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#452750: icedtea-java7: building the Ubuntu package on Debian while it's not yet in the Debian archive
Hi, since icedtea ist still in NEW, but a coworker wants to test a 64bit java plugin (actually just any java plugin that works in his 64bit browser) I just rebuilt the Ubuntu package (7~b24-1.5+20080118-1) in a testing/unstable pbuilder environment (regenerated debian/control first) and will let him test tomorrow. While building, I made the following observations (and fixes): * Build-Depends: I had to switch to 'libungif4-dev | libgif-dev', otherwise I end up with a package that conflicts with a lot of packages due to libgif4. * section assignment: icedtea-java7-plugin probably should be in 'web', not 'devel' Everything else seemed to work fine, besides that * It uses a huge amount of space while building ... (and now I have a 15 GB ramdisk on /tmp) Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406992: virtualbox FTBFS
Hi all, after several more tries, I finally could compile virtualbox (in a pbuilder sid i386 environment). The following changes were neccessary * drop Build-Depends: gcc-3.4, g++-3.4 * drop 01-compiler.dpatch, 02-kernel.dpatch * add a Depends: kbuild to virtualbox-source Concerning the kernel headers: It looks like the kernel headers of the currently running kernel is needed. Using a different set, e.g. 2.6.18-4-686 or 2.6.21-2-k7 instead of the running 2.6.21-2-k7-686 results in some undefined symbols (sorry, can't tell which, didn't save a log). So I did the following: * add Build-Depends: linux-header-2.6-all and in debian/rules I set * ./configure --with-linux=/usr/src/linux-headers-`uname -r` Unfortunetly, the requires the buildds to run the latest sid kernel in order to be able to compile virtualbox. I also tried to compile virtualbox from the svn trunk: 03-configure.dpatch needed to be rediffed, but afterwards everything went without problems. And now: I'm gonna try it :-) Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406992: virtualbox FTBFS
Hi, since virtualbox is still stuck in the NEW queue, I tried to build it myself for i386 from the pkg-virtualbox subversion repository with a tarball repackaged according to the instructions in debian/README.rebuild and found the following problems (using a sid pbuilder environment): * it lacks a Build-Depends: libhal-dev * somewhere a hard coded yasm path pointing to tools/linux.x86/bin/yasm is used, i fixed this by creating this directory and a symlink there to /usr/bin/yasm in debian/rules * it seems to look for kernel headers in /usr/src/linux after several tries to use the ones in /usr/include I still got missing headers and finally gave up. The configure option --with-linux=... seemed not to work. The following patch helped a bit: in Config.kmk set export VBOX_LINUX_SRC := /usr The buildds probably will fail with the same errors. Is there a pkg-virtualbox developer mailinglist? Since I couldn't find one I attach this information to the ITP. Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#150124: Gridengine Status?
reopen 150124 thanks Is anyone still working on packaging the Grid Engine? I'm planning to install it on a new machine during the next weeks and of course it would be nice to have Debian packages :-) If noone is working on it, I'll try to package it myself. If you have some preliminary packages or other information of your own attempt around somewhere that could be helpful, please let me know. Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
