Bug#451561: Current status
The .c and .h files of navit have an unclear license at the moment. Upstream is working on this and will fix it before the next release (mid-february). -- Jan Lübbe <[EMAIL PROTECTED]>http://sicherheitsschwankung.de gpg-key 1024D/D8480F2E 2002-03-20 fingerprint 1B25 F91F 9E7B 5D4F 1282 02D6 8A83 8BE4 D848 0F2E
Bug#469912: ITP: python-ecore -- Python bindings for the Enlightenment core library (ecore)
Package: wnpp Severity: wishlist Owner: "Jan Lübbe" <[EMAIL PROTECTED]> * Package name: python-ecore Version : 0.2.1 Upstream Author : Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> * URL : http://www.enlightenment.org * License : BSD Programming Lang: Python Description : Python bindings for the Enlightenment core library (ecore) Ecore is the core event abstraction layer and X abstraction layer that makes doing selections, Xdnd, general X stuff, and event loops, timeouts and idle handlers fast, optimized, and convenient. It's a separate library so anyone can make use of the work put into Ecore to make this job easy for applications. This package contains modules that allow you to use ecore from Python. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (900, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-x60s (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469911: ITP: python-evas -- Python bindings for the Enlightenment canvas library (evas)
Package: wnpp Severity: wishlist Owner: "Jan Lübbe" <[EMAIL PROTECTED]> * Package name: python-evas Version : 0.2.1 Upstream Author : Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> * URL : http://www.enlightenment.org * License : BSD Programming Lang: Python Description : Python bindings for the Enlightenment canvas library (evas) Evas is an advanced canvas library, providing six engines for rendering: X11, OpenGL (hardware accelerated), DirectFB, the framebuffer, Microsoft Windows and Qtopia. This package contains modules that allow you to use evas from Python. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (900, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-x60s (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470236: RFP: flam3 -- Programs to generate and render cosmic recursive fractal flames (fwd)
On Sun, 2008-03-09 at 23:52 -0500, Ian Weller wrote: > Package name: flam3 > Upstream author: Scott Draves > Description: Flam3, or Fractal Flames, are algorithmically generated images > and > animations. This is free software to render fractal flames as described on > http://flam3.com. Flam3-animate makes animations, and flam3-render makes > still > images. Flam3-genome creates and manipulates genomes (parameter sets). > > I've already packaged this for Fedora and Scott is asking me to look for a > maintainer for Debian. The specfile and patches used by Fedora are available > at http://cvs.fedoraproject.org/viewcvs/rpms/flam3/ . It seems that flam3 is already in debian as a part of electricsheep: $ dpkg -L electricsheep | grep flam /usr/lib/pkgconfig/flam3.pc /usr/lib/libflam3.a /usr/bin/flam3-render /usr/bin/flam3-convert /usr/bin/flam3-genome /usr/bin/flam3-animate /usr/share/man/man1/flam3-render.1.gz /usr/share/man/man1/flam3-animate.1.gz /usr/share/man/man1/flam3-genome.1.gz /usr/share/man/man1/flam3-convert.1.gz Is this something different? -- Jan Lübbe <[EMAIL PROTECTED]>http://sicherheitsschwankung.de gpg-key 1024D/D8480F2E 2002-03-20 fingerprint 1B25 F91F 9E7B 5D4F 1282 02D6 8A83 8BE4 D848 0F2E
Bug#471235: ITP: python-pysnmp4-apps -- Applications for the Python SNMP library
Package: wnpp Severity: wishlist Owner: "Jan Lübbe" <[EMAIL PROTECTED]> * Package name: python-pysnmp4-apps Version : 0.2.6a Upstream Author : Ilya Etingof * URL : http://pysnmp.sourceforge.net/ * License : BSD-style Programming Lang: Python Description : Applications for the Python SNMP library This package contains a set of SNMP applications written on top of the PYSNMP v4 package, which is written entirely in Python and is self-sufficient in terms that it does not rely on any third party tool. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (900, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-x60s (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474034: ITP: gpxe -- PXE network bootloader for x86 PCs
Package: wnpp Severity: wishlist Owner: "Jan Lübbe" <[EMAIL PROTECTED]> * Package name: gpxe Version : 0.9.3 Upstream Author : Michael Brown <[EMAIL PROTECTED]> and the Etherboot Project * URL : http://www.etherboot.org * License : GPL Programming Lang: C Description : PXE network bootloader for x86 PCs gPXE provides a direct replacement for proprietary PXE ROMs, with many extra features such as DNS, HTTP, iSCSI. It can be stored in a number of places, including BIOS Flash, EPROMs, floppy, CD, HD, or other bootable media. gPXE evolved from Etherboot and is maintained by the Etherboot project. It will supersede Etherboot eventually. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (900, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-x60s (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475928: ITP: python-edje -- Python bindings for the Enlightenment layout and animation library (edje)
Package: wnpp Severity: wishlist Owner: "Jan Lübbe" <[EMAIL PROTECTED]> * Package name: python-edje Version : 0.2.1 Upstream Author : Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> * URL : http://www.enlightenment.org * License : BSD Programming Lang: Python Description : Python bindings for the Enlightenment layout and animation library (edje) Edje is a graphical layout and animation library for animated resizable, compressed and scalable themes. It is the theming engine behind Enlightenment DR 0.17. This package contains modules that allow you to use evas from Python. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (900, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-x60s (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479951: RFH: kvm -- Full virtualization on x86 hardware
Package: wnpp Severity: normal KVM has gained support for ia64, ppc and s390 in addition to i386 and amd64. I currently have no machines based on the new architectures. Before enabling these, i'm seeking some help with testing the arch specific features. If you'd like to help beyond testing and be a comaintainer, i'll move the git repository to git.debian.org. You can also reach me on IRC, my nick is shoragan. Thanks, Jan Lübbbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
On Sat, 2006-04-22 at 17:24 +0200, Arnaud Fontaine wrote: > >>>>> "Morten" == Morten Werner Olsen <[EMAIL PROTECTED]> writes: > > Morten> Doesn't the pysnmp 3.x-series have a very unstable API? And > Morten> is the 3.x-series still under development? I guess the right > Morten> thing to do is to make sure pykota uses the stable pysnmp > Morten> 2.x-series until a new stable 4.x-series is ready? > > Hello, > > 3.x-serie and 4.x-serie are unstable releases. Pykota doesn't use the > 2.x-serie, only the 3.x-serie. But i think there are many examples of > such python applications that use pysnmp2 or pysnmp3 or also pysnmp4, so > i thnk that packaging all these branches could be great. I have already packaged version 3 and 4, but they were rejected by the ftp-masters because i did not explain why several versions are needed. > Morten> I'm not involved in the packaging of pysnmp, but I guess > Morten> packaging the 3.x- 4.x-series as separate packages sounds > Morten> like a good idea if we really want the version 3 and 4 in > Morten> Debian before upstream freezes their API. > > I think so too. I have python-pysnmp4 ready, available on the svn > repository of debian-python team. I can package pysnmp3 too, but i would > like to wait for Jan Luebbe answer about these mails ;). All versions use the pysnmp package name (and therfore the packages conflict against each other), so it would impossible to one package with depends on v2 together with one which depends on v4. v4 contains a mechanism to select the required version before importing pysnmp. So it should be possible to port this mechanism to v2 and v3 and create a pysnmp-common package which contains this module. Of course that would require all users of pysnmp to specifiy the required version. The (imho) cleaner solution would be to use pysnmp[234] as the package names. This sould be coordinated with upstream. -- Jan Lübbe <[EMAIL PROTECTED]>http://sicherheitsschwankung.de gpg-key 1024D/D8480F2E 2002-03-20 fingerprint 1B25 F91F 9E7B 5D4F 1282 02D6 8A83 8BE4 D848 0F2E signature.asc Description: This is a digitally signed message part
Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
On Mon, 2006-04-24 at 11:37 +0400, Ilya Etingof wrote: > > v4 contains a mechanism to select the required version before importing > > pysnmp. So it should be possible to port this mechanism to v2 and v3 and > > create a pysnmp-common package which contains this module. > > If anyone wants to backport this code into pysnmp[23], I'd happily commit > this into the distros or create a stand-alone package. Otherwise, I can do > that by myself. Just let me know. > > > Of course that would require all users of pysnmp to specifiy the > > required version. > > > > The (imho) cleaner solution would be to use pysnmp[234] as the package > > names. This sould be coordinated with upstream. > > I'm a bit reluctant about this approach because: > > 1) It would still require a modification to existing packages (rename >pysnmp into pysnmp[234]) > 2) Looks like pysnmp4 is going to be final in terms of functionality and >API (hopefully, oh) so all other versions will be gradually phased out. >I'd like the final version to be called just "pysnmp" for the sake >of simplicity and aestetics. ;-) We could do it like this: - pysnmp2 is patched to install to pysnmp/v2 - pysnmp3 is patched to install to pysnmp/v3 - pysnmp4 already installs to pysnmp/v4 - the version switch-module from v4 is packaged as pysnmp-common and the other version depend on it - Programs need to specify what the need via os.envrion Perhaps it would be possible to use something like "import pysnmp.v2 as pysnmp"? Ilya, the debian-python-team meets in #debian-python on OFTC. -- Jan Lübbe <[EMAIL PROTECTED]>http://sicherheitsschwankung.de gpg-key 1024D/D8480F2E 2002-03-20 fingerprint 1B25 F91F 9E7B 5D4F 1282 02D6 8A83 8BE4 D848 0F2E
Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
On Mon, 2006-04-24 at 14:06 +0200, Morten Werner Olsen wrote: > On Mon, Apr 24, 2006 at 02:00:20PM +0200, Jan Lübbe wrote: > > > We could do it like this: > > > > - pysnmp2 is patched to install to pysnmp/v2 > > - pysnmp3 is patched to install to pysnmp/v3 > > - pysnmp4 already installs to pysnmp/v4 > > - the version switch-module from v4 is packaged as pysnmp-common and the > > other version depend on it > > - Programs need to specify what the need via os.envrion > > > > Perhaps it would be possible to use something like "import pysnmp.v2 as > > pysnmp"? > > That would mean that software packaged for Debian which uses pysnmp > will have to be patched to be able to use pysnmp, and do we really > want that? Its now good, but i dont see any other good way :/ The default (if you don't change os.environ) would be the most recent installed version. But if we don't have a way to select one of the installed version, it would be impossible to install programs that depend on different versions. That would be a severe restriction. What do you think about using the module names pysnmp for pysnmp4 and pysnmp[23] for the older versions? -- Jan Lübbe <[EMAIL PROTECTED]>http://sicherheitsschwankung.de gpg-key 1024D/D8480F2E 2002-03-20 fingerprint 1B25 F91F 9E7B 5D4F 1282 02D6 8A83 8BE4 D848 0F2E
Bug#247961: Preliminary packages for projectm
Hello! I have made some preliminary packages for projectm which can be downloaded from http://d072.apm.etc.tu-bs.de/~jluebbe/debian/unstable/ I'm not sure if the package is completely DFSG-Free, because there are some fonts called arial1.glf, courier1.glf and times_new1.glf. They are included in the OpenGL font library 'GLF' by Roman Podobedov. The license of the library states: You can use this library in any program (commercial, educational or individual), but in each program, where You use this library, You should to keep this header (author name and coordinates)! But i'm not sure if that applies to the fonts as well. Some presets from http://milkdrop.co.uk come in the projectm tarball, but there is no license for them. So i'm not sure what to do about them (although projectm could be distributed without them). If the legal problems can be worked out, i think it would be no problem to include it in Debian. -- Jan Lübbe <[EMAIL PROTECTED]>
