Bug#984811: ITP: openbgpd -- Free, functional, and secure implementation of the BGP-4 protocol.
On Mon, Mar 08, 2021 at 05:13:35PM +0100, Job Snijders wrote: > Dear Julien, > > > > Description : Free, functional, and secure implementation of the > BGP-4 protocol. > > the above short description has 3 useless words in it, I suggest you drop > them. > > If it wasn't free it wouldn't be in Debian; if it wasn't functional why > would anyone release or package it; same with "secure", plus it's a > rather meaningless descriptor that'll be wrong the day somebody finds a > bug (especially combined with "implemented in C"...). > > > Thank you for your feedback. > > I'll change the short description to "OpenBSD BGP-4 daemon" > Sounds good, thanks! Cheers, Julien
Bug#984811: ITP: openbgpd -- Free, functional, and secure implementation of the BGP-4 protocol.
On Mon, Mar 08, 2021 at 04:51:14PM +0100, Job Snijders wrote: > Package: wnpp > Severity: wishlist > Owner: Job Snijders > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: openbgpd > Version : 6.8p1 > Upstream Author : OpenBSD tech mailing list > * URL : http://www.openbgpd.org/ > * License : ISC > Programming Lang: C > Description : Free, functional, and secure implementation of the BGP-4 > protocol. > Hi, the above short description has 3 useless words in it, I suggest you drop them. If it wasn't free it wouldn't be in Debian; if it wasn't functional why would anyone release or package it; same with "secure", plus it's a rather meaningless descriptor that'll be wrong the day somebody finds a bug (especially combined with "implemented in C"...). Cheers, Julien
Bug#981994: ITP: xserver-xorg-input-aiptek -- X.Org X server -- Aiptek input driver
On Fri, Feb 05, 2021 at 06:03:57PM +0200, Adrian Bunk wrote: > Package: wnpp > Severity: wishlist > Owner: Adrian Bunk > > Package name: xserver-xorg-input-aiptek > Description : X.Org X server -- Aiptek input driver > > Adopting X drivers that were removed in #955603 despite many objects. > These hardware drivers belong in the kernel. Do aiptek USB devices not show up as regular input devices that generic userspace drivers can handle? Cheers, Julien
Bug#981113: ITP: root -- open-source data analysis framework
On Tue, Jan 26, 2021 at 04:34:14PM +0100, Stephan Lachnit wrote: > Package: wnpp > Severity: wishlist > Owner: Stephan Lachnit > X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@protonmail.com, > debian-scie...@lists.debian.org > > * Package name: root [...] > > I want to maintain ROOT in the science team. ROOT was already in Debian as > `root-system` [1], but hasn't been updated since 2015. > I will probably go with a more easy maintainable route like I did with Geant4 > for the start and do package splitting later. > > [1] https://tracker.debian.org/pkg/root-system > Please re-use the old name. "root" is a terrible choice of package name. Thanks, Julien
Bug#913976: ITP: python-hgapi -- module providing a pure-Python API to Mercurial
On 11/17/18 9:23 PM, Nick Morrott wrote: > Package: wnpp > Owner: Nick Morrott > Severity: wishlist > X-Debbugs-CC: debian-de...@lists.debian.org > > * Package name: python-hgapi > Version : 1.7.3 > Upstream Author : Fredrik Håård > * URL : https://github.com/haard/hgapi > * License : Expat > Programming Lang: Python > Description : module providing a pure-Python API to Mercurial > > hgapi is a pure-Python API to the Mercurial command-line, instead of the > internal Mercurial API. > > hgapi works for all versions of Mercurial, and will instantly reflect any > changes to the repository (including hgrc). > > hgapi is a dependency of yotta [1] > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908781 > Is there a particular reason yotta needs to use this instead of hglib, which: - is already in debian - is maintained by mercurial upstream - has pretty much the exact same package description as the above ? This seems like useless duplication. Thanks, Julien
Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0
On 08/16/2018 02:45 PM, Ian Jackson wrote:
> Mo Zhou writes ("Bug#906265: RFH: julia -- ppc64el port of Julia language and
> LLVM-6.0"):
>> I tried to think of applying for the access to debian's ppc64el porterbox
>> but it appears to be impossible for a normal user to install the resulting
>> package and build another package. Although maybe I can do some hacks on
>> PATH and LD_LIBRARY_PATH but that's dirty.
>
> This looks quite annoying. The basic pattern here is that the porter
> may need to install modified build-deps. This seems like it must come
> up all the time. DSA, do you have any suggestions ?
>
I believe tricks with env vars are indeed the usual way to play with
something like that. Porter boxes don't lend themselves well to
installing untrusted packages.
Cheers,
Julien
Bug#906056: ITP: xserver-xorg-video-sunffb -- X.Org X server -- Sun FFB display driver
On 08/14/2018 02:03 PM, John Paul Adrian Glaubitz wrote: > Hi Julien! > >> What purpose would building/shipping it anywhere else serve? > > It's a workaround to be able to upload the package to unstable. > I don't understand why that is a requirement. The package could just as well live in debian-ports, like other sparc-specific packages (I assume e.g. silo lives there). That all sounds backwards to me. Cheers, Julien
Bug#906056: ITP: xserver-xorg-video-sunffb -- X.Org X server -- Sun FFB display driver
On Mon, Aug 13, 2018 at 19:05:14 +0200, Gregor Riepl wrote: > This driver was previously removed from Debian along with sparc support. > With the sparc64 Debian port, it has become useful again. > > I'd like to re-introduce it into Debian to provide support for the > aforementioned video adapters, found in certain Sun Microsystems > graphical workstations. > > For the time being, I'd like to maintain it together with the Debian > sparc/sparc64 port team, and if possible, with the X Strike Force at > a later point of time. > > Despite being useful only on Sun graphical workstations, the package > builds fine on any architecture, so I think it would be acceptable to > include it on the Debian package servers. > I disagree. The package should only build on sparc/sparc64 so doesn't need to be in Debian at this time. What purpose would building/shipping it anywhere else serve? Cheers, Julien
Bug#902976: ITP: netcdf-parallel -- Parallel build of NetCDF library
On 07/04/2018 12:37 PM, Alastair McKinstry wrote: > This package is necessary because it is not possible currently to enable all > functionality > in any single build of NetCDF - use of Compression, etc. in netcdf-4 requires > a serial build. > It is hoped that upstream work will make this package unnecessary in the long > term (post-Buster) > Why does this require a separate source package though rather than a second build from the netcdf source with different options? Cheers, Julien
Bug#863605: ITP: python-pyserial -- serial port access library in Python
On 05/29/2017 10:22 AM, Ghislain Antony Vaillant wrote: > Package: wnpp > Severity: wishlist > Owner: Ghislain Antony Vaillant > > * Package name: python-pyserial > Version : 3.3 > Upstream Author : Chris Liechti > * URL : https://github.com/pyserial/pyserial > * License : BSD > Programming Lang: Python > Description : serial port access library in Python > > Long-Description: > This module encapsulates the access for the serial port. It provides > backends for Python running on Windows, OSX, Linux, BSD (possibly any > POSIX compliant system) and IronPython. The module named "serial" > automatically selects the appropriate backend. > > This package is a dependency to src:python-pymeasure. It will be > co-maintained by the Debian Science Team. > Sounds like this duplicates the existing python-serial package. Cheers, Julien
Bug#861455: ITP: xf86-input-tslib -- X.org input driver for tslib
On Sat, Apr 29, 2017 at 12:47:29 +0200, Martin Kepplinger wrote: > Package: wnpp > Severity: wishlist > Owner: Martin Kepplinger > > * Package name: xf86-input-tslib > Version : 0.0.7 > Upstream Author : Martin Kepplinger > * URL : https://github.com/merge/xf86-input-tslib > * License : MIT > Programming Lang: C > Description : X.org input driver for tslib > > xf86-input-tslib had been in Debian before, see > https://tracker.debian.org/pkg/xf86-input-tslib and I'm rewriting the > packaging completely due to it's age. I only intend to build upon the > old changelog file. > > Former upstream site: > http://public.pengutronix.de/software/xf86-input-tslib/ > > Packaging is done here now: > https://github.com/merge/xf86-input-tslib-debian > > - why is this package useful/relevant? > > tslib is still quite widely used in embedded at least. It saw much > improvements recently and this package would make tslib available to > X servers. xf86-input-tslib 0.0.7 was recently released and makes it > usable on recent systems. There are plans for multitouch too. > > - how do you plan to maintain it? > > I reached out to the people from the old packaging repo at > http://git.debian.org/?p=collab-maint/xf86-input-tslib.git;a=summary > but haven't heard anything. It shouldn't be an issue though, to just > maintain this little packaging code on github. > I don't think we should revive this package in Debian. There has been much effort upstream in the last years to reduce the amount of device-specific code in userspace drivers, with things stabilizing around the evdev and now libinput drivers. Why does libinput not satisfy your needs, and why can't it be made to? Cheers, Julien
Bug#820052: RFP: uefi-shim -- UEFI shim boot loader to support Secure Boot
On Mon, Apr 4, 2016 at 20:06:44 -0700, Steve Langasek wrote: > I have previously committed to maintaining this package in Debian; this is > only blocked on the availability of a Debian master key to embed in it (no > point in building binaries until this is done). > Hi Steve, do you have an estimate for when a new shim upload might happen? Thanks, Julien
Bug#813325: ITP: xf86-video-ast -- X.Org X server -- ASpeed Technologies display driver
On Sun, Jan 31, 2016 at 17:34:38 +0100, Hilko Bengen wrote: > I have the package ready for upload and would like to put it under > collaborative maintenance with the X Strike Force. > Sounds good to me, please feel free to apply to pkg-xorg on alioth, we'll get you added. Thanks, Julien
Bug#793057: ITP: godot -- open source MIT licensed game engine
On Mon, Jul 20, 2015 at 23:29:14 +0200, Bruno Ramos wrote: > Description : open source MIT licensed game engine > That's not a terribly useful short description. Only the last two words belong there, IMO. The "open source" bit is kind of implied by it being in Debian, and the exact license is what debian/copyright is for. Cheers, Julien signature.asc Description: Digital signature
Bug#784114: ITP: xserver-xorg-input-libinput -- X.Org X server -- libinput input driver
Package: wnpp Severity: wishlist Owner: Debian X Strike Force X-Debbugs-Cc: libin...@package.debian.org * Package name: xserver-xorg-input-libinput Version : 0.9.0 Upstream Author : Peter Hutterer * URL : http://www.x.org/ * License : MIT/X Programming Lang: C Description : X.Org X server -- libinput input driver This package provides the driver for input devices using libinput library. . More information about X.Org can be found at: http://www.X.org> . This package is built from the X.org xf86-input-libinput driver module. This driver will combine the functionality of the evdev, synaptics and wacom X drivers. We'll need libinput 0.11 before we can upload this. Cheers, Julien signature.asc Description: Digital signature
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, Jul 28, 2014 at 03:39:29 +0200, Andreas Cadhalpun wrote: > Hi Reinhard, > > On 28.07.2014 02:05, Reinhard Tartler wrote: > >On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun > > wrote: > > > >> * Does it make sense for me to switch my package? > >>The rule of thumb is, if your upstream uses FFmpeg for development > >>you probably want to switch to using it, too. > > > >In [1], Moritz from the security team clearly stated that he is more > >than uncomfortable with having more than one copy of libavcodec in > >debian/testing. > > I discussed this with Moritz in the ITP bug. Moritz ended this discussion > [a], and as I wasn't convinced by his arguments, I continued my work. If in > the end really only one copy is allowed in the next stable release, I think > it should be FFmpeg. > > >In consequence this means that any package that builds > >against the ffmpeg packages currently in NEW won't make it into > >testing either. I am therefore surprised about the given answer to the > >question above. > > It remains to be seen, what the release team prefers: frustrated users and > developers or both forks in jessie. > The release team is likely to let the people involved in multimedia foo fight it out among themselves and pick a winner. We're not going to ship both and hand that mess over to the security team. Cheers, Julien signature.asc Description: Digital signature
Bug#750638: ITP: ndg-httpsclient -- enhanced HTTPS support for httplib and urllib2 using PyOpenSSL
On Thu, Jun 5, 2014 at 10:24:48 -0400, Donald Stufft wrote: > > On Jun 5, 2014, at 7:09 AM, Daniele Tricoli wrote: > > > Hello Julien, > > thanks for packaging ndg-httpsclient! > > > > On Thursday 05 June 2014 12:26:22 Julien Cristau wrote: > >> My main interest is to be able to talk to websites using SNI with > >> scripts using python-requests. > > > > Once in the archive I will also add ndg-httpsclient into python-requests' > > Suggests. > > > > Kind regards, > > > > P.S. I'll do the same for python-urllib3: > > https://github.com/shazow/urllib3/pull/156 > > > > -- > > Daniele Tricoli 'Eriol' > > http://mornie.org > > You need pyasn1, pyopenssl, and ndg-httpsclient in order for the > requests/urllib3 stuff to kick in. > > It’d probably be a sane idea to use recommends, at least on Python 2.x since > using that also > prevents CRIME and the like which Python 2.x is vulnerable to else wise IIRC. > My plan is for the ndg-httpsclient package to depend on pyopenssl and recommend pyasn1. Cheers, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances -- 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/20140605143302.ga2...@crater1.logilab.fr
Bug#750638: ITP: ndg-httpsclient -- enhanced HTTPS support for httplib and urllib2 using PyOpenSSL
Package: wnpp Severity: wishlist Owner: Julien Cristau * Package name: ndg-httpsclient Version : 0.3.2 Upstream Author : Science & Technology Facilities Council (STFC) * URL : https://pypi.python.org/pypi/ndg-httpsclient * License : BSD Programming Lang: Python Description : enhanced HTTPS support for httplib and urllib2 using PyOpenSSL ndg-httpsclient is a HTTPS client implementation for httplib and urllib2 based on PyOpenSSL. PyOpenSSL provides a more fully featured SSL implementation over the default provided with Python and importantly enables full verification of the SSL peer. My main interest is to be able to talk to websites using SNI with scripts using python-requests. Cheers, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances -- 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/20140605102621.ga17...@crater1.logilab.fr
Bug#750396: ITP: python-ldap3 -- A strictly RFC 4511 conforming LDAP V3 pure Python client
On Tue, Jun 3, 2014 at 16:04:05 +1000, Brian May wrote: > This library has the advantage that it is pure Python code, I believe > this means it doesn't require the C ldap library. > Whether that's an advantage is kind of disputable. > I am considering naming the source python-ldap3, which is different from > the upstream name, as it works with both python 2 and python 3, and it > supplies the ldap3 module, not the ldap module. So it shouldn't conflict > with the existing python-ldap package. If I know what I am doing, it > will provide the python-ldap3 and python3-ldap binary packages. > Shouldn't that be python3-ldap3? Cheers, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances -- 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/20140604150228.ga11...@crater2.logilab.fr
Bug#720202: ITP: qreator -- utility for creating QR codes
On Mon, Aug 19, 2013 at 22:16:11 +0200, Thomas Preud'homme wrote: > Le lundi 19 août 2013 23:24:48 Chow Loong Jin a écrit : > > Package: wnpp > > Severity: wishlist > > Owner: Chow Loong Jin > > > > * Package name: qreator > > Version : 13.05.3 > > Upstream Author : David Planella > > * URL : https://launchpad.net/qreator > > * License : GPL-3 > > Programming Lang: Python > > Description : utility for creating QR codes > > > > Qreator enables you to easily create your own QR codes to encode different > > types of information in an efficient, compact and cool way. > > Greetings Loong Jin, > > Since it seems there is already a qr generator in Debian (qrencode), I > suppose > qreator has some feature that are lacking in qrencode. Could you develop > those? That would be especially useful in the long description so that a user > looking for a tool creating a qr code have enough information to choose > between these two packages. > What would be even more useful is to just ship one. Cheers, Julien signature.asc Description: Digital signature
Bug#565308: Will we see MariaDB in Jessie?
On Mon, May 6, 2013 at 19:17:47 +0200, Patrick Matthäi wrote: > But why should it _replace_ MySQL, why not providing it as an > alternative MySQL'ish server? > Because Oracle. Cheers, Julien signature.asc Description: Digital signature
Bug#698772: RFA: salt - remote manager to administer servers
On Mon, Jan 28, 2013 at 16:42:59 -0430, Franklin G. Mendoza wrote: > retitle 698772 ITA: salt - remote manager to administer servers > owner Michael Prokop ! > thanks On Fri, Feb 22, 2013 at 18:04:23 +0100, Arno Töll wrote: > > Hi, > > I'm not using salt yet, but it looks really awesome. So, in case nobody > steps in or someone wants a co-maintainer I might be interested. > > I'm short of time for the upcoming weeks but at some point during the > Jessie development cycle things are hopefully changing again. > I'm planning on taking over this ITA in the next week or so, considering nothing seems to have happened since the retitling by Franklin two months ago. Cheers, Julien signature.asc Description: Digital signature
Bug#700210: ITP: kmscon -- Linux KMS/DRM based virtual Console Emulator
On Sat, Feb 9, 2013 at 23:36:07 +0100, Jakub Wilk wrote: > Package: wnpp > Severity: wishlist > Owner: Jakub Wilk > Control: block -1 with 691699 > > * Package name: kmscon Hi Jakub, if you need it, feel free to review and upload libxkbcommon 0.2.0 to experimental, Timo updated the packaging in git but I haven't had a chance to look yet. (git://anonscm.debian.org/git/pkg-xorg/lib/libxkbcommon debian-unstable) Cheers, Julien signature.asc Description: Digital signature
Bug#693879: ITP: python-hglib -- Python library for interfacing with Mercurial's command server
Package: wnpp Severity: wishlist Owner: Julien Cristau * Package name: python-hglib Version : 0.3 Upstream Author : Idan Kamara, Matt Mackall * URL : http://pypi.python.org/pypi/python-hglib/ * License : MIT/X Programming Lang: Python Description : Python library for interfacing with Mercurial's command server python-hglib is a library with a fast, convenient interface to Mercurial. It uses Mercurial's command server for communication with hg. This approach avoids relying on Mercurial's (unstable) internal Python API, and avoids licensing issues for non-GPL code. -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances -- 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/20121121124529.ga22...@crater1.logilab.fr
Bug#690544: ITP: xts -- GNU R package for time series analysis
On Mon, Oct 15, 2012 at 20:49:31 +0800, Lifeng Sun wrote: > retitle 690544 ITP: r-cran-xts -- GNU R package for time series analysis > thanks > > On 14:37 Mon 10/15/12 Oct , Julien Cristau wrote: > > Any chance you could choose a better package name? Something that hints > > at this being related to R. xts to me is the X Test Suite, which has > > nothing to do with this. > > hmmm, rename it to r-cran-xts. > Thank you. Cheers, Julien signature.asc Description: Digital signature
Bug#690544: ITP: xts -- GNU R package for time series analysis
On Mon, Oct 15, 2012 at 20:13:33 +0800, Lifeng Sun wrote: > Package: wnpp > Severity: wishlist > Owner: Lifeng Sun > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org > > * Package name: xts > Version : 0.8-6 > Upstream Author : Jeffrey A. Ryan > Josh M. Ulrich > * URL : http://r-forge.r-project.org/projects/xts/ > * License : GPL-2 > Description : GNU R package for time series analysis -- xts > > This package provide uniform handling of R's different time-based data > classes by extending r-cran-zoo, maximizing native format information > preservation and allowing for user level customization and extension, > while simplifying cross-class interoperability. > Any chance you could choose a better package name? Something that hints at this being related to R. xts to me is the X Test Suite, which has nothing to do with this. Thanks, Julien signature.asc Description: Digital signature
Bug#678100: ITP: salome-{kernel,gui,med,geom,paravis,..} -- integration platform for numerical simulation
On Thu, Jun 21, 2012 at 02:13:47 +0100, Dmitrijs Ledkovs wrote: > On 19/06/12 10:00, Julien Cristau wrote: > > On Tue, Jun 19, 2012 at 09:40:32 +0100, Dmitrijs Ledkovs wrote: > > > >> Good luck! It's a beast =) > >> > > Thanks :) > > > >> Did you see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657433 ? > >> > > Yep. I'll start with a smaller set of modules, and get things in > > experimental at first to get a feel for the pain involved. > > > > One thing I can recommend is using cdbs, due to native flavours support > I'm afraid there's no way I'm getting anywhere near cdbs. Cheers, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances -- 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/20120621081553.ga9...@crater1.logilab.fr
Bug#678100: ITP: salome-{kernel,gui,med,geom,paravis,..} -- integration platform for numerical simulation
On Tue, Jun 19, 2012 at 09:40:32 +0100, Dmitrijs Ledkovs wrote: > Good luck! It's a beast =) > Thanks :) > Did you see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657433 ? > Yep. I'll start with a smaller set of modules, and get things in experimental at first to get a feel for the pain involved. Cheers, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances -- 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/20120619090052.ga13...@crater2.logilab.fr
Bug#678100: ITP: salome-{kernel,gui,med,geom,paravis,..} -- integration platform for numerical simulation
Package: wnpp
Severity: wishlist
Owner: Julien Cristau
* Package name: salome-{kernel,gui,med,geom,paravis,..}
Version : 6.5.0
Upstream Author : CEA, EDF R&D, Open CASCADE
* URL : http://www.salome-platform.org/
* License : mostly LGPL
Programming Lang: C++, Python
Description : integration platform for numerical simulation
Salomé is a pre- and post-processor for numerical simulations. It can
import CAD files in IGES and STEP formats, facilitates component
integration in heterogeneous systems, and has a user-friendly GUI as
well as a Python console with all of the platform functionality.
An earlier version used to be in sid as the 'salome' source package, but
was removed early this year. I'm planning on reintroducing it in
smaller pieces in the hope it'll be more manageable.
Cheers,
Julien
--
Julien Cristau
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances
--
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/20120619082917.ga16...@crater2.logilab.fr
Bug#672507: ITP: ruby-posix-spawn -- Ruby Implementation of posix_spawn(2) for faster process spawning
On Sat, May 12, 2012 at 01:12:37 +0900, Youhei SASAKI wrote: > Package: wnpp > Owner: Youhei SASAKI > Severity: wishlist > > * Package name: ruby-posix-spawn Do you really need a whole package for a single syscall wrapper? Cheers, Julien signature.asc Description: Digital signature
Bug#633677: Bug#613337: libvia transition
On Mon, Mar 5, 2012 at 09:49:16 +0100, Michael Hanke wrote: > Hi, > > On Sun, Mar 04, 2012 at 11:17:56PM +0100, Julien Cristau wrote: > > On Thu, Feb 9, 2012 at 09:38:51 +0100, Michael Hanke wrote: > > > I will upload a new SO version of LIBVIA shortly. Right now only ODIN > > > and LIPSIA use this library. The LIBVIA dependency of ODIN will be > > > dropped by the next upload (few more days). > > > > how many is "few"? :) > > Thanks for moving this upwards on my TODO list. Of course things turned > out to be more complicated. New upstream version had some issues, > upstream needs more time, now libpng transition needs to be dealt with > for ODIN. If am lucky I can do all this sometime today. If not, I will > need few more days (TM) ;-) > I don't think you need to do anything for libpng just yet FWIW. But thanks for the update. Cheers, Julien -- 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/20120305085318.ga16...@coloquinte.cristau.org
Bug#633677: libvia transition
Hi Michael, On Thu, Feb 9, 2012 at 09:38:51 +0100, Michael Hanke wrote: > Dear Release Team, > > I will upload a new SO version of LIBVIA shortly. Right now only ODIN > and LIPSIA use this library. The LIBVIA dependency of ODIN will be > dropped by the next upload (few more days). how many is "few"? :) Cheers, Julien signature.asc Description: Digital signature
Bug#636733: Adopting libnss-db
Hi Adam, On Sat, Aug 6, 2011 at 19:21:31 +, Adam Conrad wrote: > retitle 636733 ITA: libnss-db -- NSS module for using Berkeley Databases > kthxbye > > I intend to adopt libnss-db and upload a version with a new Maintainer > soonish. > How soonish? :) Cheers, Julien signature.asc Description: Digital signature
Bug#629278: ITP: python-sphinx-aafig -- Embedded ASCII art figures in Sphinx documentations
On Fri, Nov 18, 2011 at 10:31:17 +0100, Julien Cristau wrote: > On Sun, Jun 5, 2011 at 12:06:40 +0200, Nicolas CANIART wrote: > > > Package: wnpp > > Severity: wishlist > > Owner: Nicolas CANIART > > > > * Package name: python-sphinx-aafig > > Version : 1.0 > > Upstream Author : Leandro Lucarella > > * URL : http://pypi.python.org/sphinxcontrib-aafig/ > > * License : BOLA > > Programming Lang: Python > > Description : Embedded ASCII art figures in Sphinx documentations > > > Hi Nicolas, > > what's the status of this ITP? Do you have a preliminary package > somewhere? > Nevermind, found it in the python-modules svn. One question though: is there a particular reason you put the packaging under GPL-3, as opposed to a permissive license similar to the one used by upstream? Cheers, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances -- 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/2018095705.ga12...@crater1.logilab.fr
Bug#629278: ITP: python-sphinx-aafig -- Embedded ASCII art figures in Sphinx documentations
On Sun, Jun 5, 2011 at 12:06:40 +0200, Nicolas CANIART wrote: > Package: wnpp > Severity: wishlist > Owner: Nicolas CANIART > > * Package name: python-sphinx-aafig > Version : 1.0 > Upstream Author : Leandro Lucarella > * URL : http://pypi.python.org/sphinxcontrib-aafig/ > * License : BOLA > Programming Lang: Python > Description : Embedded ASCII art figures in Sphinx documentations > Hi Nicolas, what's the status of this ITP? Do you have a preliminary package somewhere? Thanks, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances -- 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/2018093115.ga3...@crater1.logilab.fr
Bug#630977: ITP: raccoon -- preparation for ligand screening projects
On Sun, Jun 19, 2011 at 14:02:13 +0200, Steffen Moeller wrote: > The package is ready for upload in the svn repository of > debian-med.alioth.debian.org. > Is this the package's long description? Cheers, Julien -- 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/20110619160811.gp2...@radis.liafa.jussieu.fr
Bug#624402: ITP: xen-qemu-dm-4.1 -- Xen Qemu Device Model virtual machine hardware emulator
On Thu, Apr 28, 2011 at 15:20:00 +0800, Thomas Goirand wrote: > This is an updated package for version 4.1 of Xen. > Updated packages don't need ITPs. Cheers, Julien -- 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/20110428074305.gg2...@radis.liafa.jussieu.fr
Bug#620943: ITP: evtest -- utility to monitor input device events
On Tue, Apr 5, 2011 at 09:41:13 +0200, Stephen Kitt wrote: > * Package name: evtest > Version : 1.27 > Upstream Author : Peter Hutterer > * URL : http://cgit.freedesktop.org/evtest/ > * License : GPLv2 > Programming Lang: C > Description : utility to monitor input device events > > evtest monitors an input device, displaying all the events it generates. a Linux input device maybe... > . > It can be used to determine mice button bindings, keymaps for exotic > keyboards... It is commonly used to debug issues with input devices > in X.Org. > Thanks for picking this up! Cheers, Julien -- 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/20110405111401.gr3...@radis.liafa.jussieu.fr
Bug#613788: ITP: dropbox -- secure backup, sync and sharing util
On Thu, Feb 17, 2011 at 14:52:49 +, brian m. carlson wrote: > On Thu, Feb 17, 2011 at 12:35:26AM -0800, Vincent Cheng wrote: > > * Package name: dropbox > > Version : 1.0.20-1 > > Upstream Author : Dropbox, Inc. > > * URL : http://www.dropbox.com > > * License : Proprietary > > Section : non-free/net > > Description : secure backup, sync and sharing util > > It looks like you're still missing the source for librsync.so.1 in your > packages. Also, I *strongly* recommend that you not include binary-only > shared libraries that are already available in Debian. The security > team will not be very happy with you. As an example, your package > ships libz.so.1, which has been the target of a DSA previously. > The security team doesn't support the non-free section in any way, so not really. Still a bad idea though. Cheers, Julien -- 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/20110217154133.gw12...@radis.liafa.jussieu.fr
Bug#612460: O: xresprobe
Package: wnpp Severity: normal Orphaning the xresprobe package. Petter Reinholdtsen showed some interest recently, so I'm not filing this as a RM request right away in case he wants to adopt the package. Cheers, Julien signature.asc Description: Digital signature
Bug#603534: ITP: xf86-input-multitouch -- Multitouch X input driver
On Thu, Nov 18, 2010 at 14:29:30 +0900, Nobuhiro Iwamatsu wrote: > Hi, > > 2010/11/15 Julien Cristau : > > My understanding is that MT support will be added to the regular evdev > > and synaptics drivers (and the X protocol). > > I didn't know this. Thank you. > ( maybe this ? http://cgit.freedesktop.org/~cndougla/xf86-input-evdev/ ) > Yeah, IIRC there are various proposals floating around. > > Does this driver have any sort of future at all? > > > This driver is necessary in new Macbook / Macbook pro. > This will not be necessary if xorg 1.8 or 1.9 is in unstable, and the > evdev driver who > supported MT comes to be usable. > > Do you know whether multitouch in latest xf86-input-evde is already usable ? > multitouch in XI2 will probably have to wait at least for xserver 1.11. Driver support likely at the same time. Apps/toolkits, OTOH, I have no idea. I'm not sure what sort of kludge xf86-input-multitouch is using to get MT data to clients. Maybe it doesn't, and just handles gesture recognition in the driver? Cheers, Julien signature.asc Description: Digital signature
Bug#603534: ITP: xf86-input-multitouch -- Multitouch X input driver
On Mon, Nov 15, 2010 at 11:12:52 +0900, Nobuhiro Iwamatsu wrote: > Package: wnpp > Owner: Nobuhiro Iwamatsu > Severity: wishlist > > *** Please type your report below this line *** > > * Package name: xf86-input-multitouch > Version : 1.0~rc2 > Upstream Author : Henrik Rydberg > * URL : http://bitmath.org/code/multitouch/ > * License : GPL v2 or any later version > Programming Lang: C > Description : Multitouch X input driver > > This X input driver provides gestures support for multitouch touchpads, > in particular those with integrated button. > My understanding is that MT support will be added to the regular evdev and synaptics drivers (and the X protocol). Does this driver have any sort of future at all? Cheers, Julien signature.asc Description: Digital signature
Bug#602358: ITP: rtl8192ce-dkms -- Realtek RTL8192CE driver in DKMS format.
On Thu, Nov 4, 2010 at 10:59:41 +0800, Keng-Yu Lin wrote: > Package: wnpp > Severity: wishlist > Owner: "Keng-Yu Lin" > > * Package name: rtl8192ce-dkms > Version : 2.6.0003.0628.2010+dfsg > Upstream Author : Realtek Semiconductor Corporation > * URL : http://www.realtek.com > * License : GPLv2 > Programming Lang: C > Description : Realtek RTL8192CE driver in DKMS format. > > This package contains Realtek 802.11 Linux wireless driver > for use with Realtek RTL8192CE-based hardware. Why is that driver not in the standard kernel package? Cheers, Julien signature.asc Description: Digital signature
Bug#508495: RFA: paw -- Physics Analysis Workstation - a graphical analysis program
On Thu, Dec 11, 2008 at 12:19:34 -0800, Kevin B. McCarty wrote: > Package: wnpp > Severity: normal > > RFA'ing paw along with Cernlib, please see #508413 for details. > On Fri, Oct 30, 2009 at 11:05:32 +0100, Francois Niedercorn wrote: > retitle 508495 ITA: paw > thanks > > Hi, > > I intend to adopt paw package, and plan to set debian science as > comaintainers. > Has anything happened with this? paw has an FTBFS bug open for a while, and the cernlib-related packages appear to still be orphaned? If people want this in squeeze now's high time to step up, otherwise I'll have to get these packages out of testing. Cheers, Julien signature.asc Description: Digital signature
Bug#594808: ITP: xvba-video -- XvBA-based backend for VA API
On Sun, Aug 29, 2010 at 19:30:47 +0200, Patrick Matthäi wrote: > Package: wnpp > Severity: wishlist > Owner: "Patrick Matthäi" > > * Package name: xvba-video > Version : 0.7.3 > Upstream Author : Gwenole Beauchesne > * URL : http://www.splitted-desktop.com/~gbeauchesne/ > * License : non-free/prop. > Programming Lang: something which is compileable ;) > Description : XvBA-based backend for VA API > > Video decode driver for ATI/AMD chipsets (XvBA implementation). > . > This VA driver provides GPU video decoding for ATI/AMD chipsets. > The package name should somehow include fglrx, IMO. Cheers, Julien signature.asc Description: Digital signature
Bug#594808: ITP: xvba-video -- XvBA-based backend for VA API
On Sun, Aug 29, 2010 at 21:13:11 +0200, Patrick Matthäi wrote: > Already uploaded to NEW. > That means either you uploaded too soon or ITPed too late. Nothing I can do about that. > xvba-video is the right source package name, the binary package is > named xvba-va-driver (same way as the nvidia VA driver: > vdpau-va-driver). vdpau-va-driver has Provides: nvidia-va-driver, s3g-va-driver, va-driver, vdpau-video and is in main. That doesn't sound nvidia-specific to me. > The package description already mentions, that it is ATI/AMD > specific. Users who want to activate this feature also know, that > the AMD implementation of VA is named xvba :) > "ATI/AMD specific" doesn't say anything about it requiring the use of the fglrx X driver. So yeah, the description needs to be improved as well. > I don't see any problems with that name. > I do. Cheers, Julien signature.asc Description: Digital signature
Bug#594672: ITP: dhcpcd5 -- a DHCP client
On Sat, Aug 28, 2010 at 09:35:29 +0100, Roy Marples wrote: > * Package name: dhcpcd5 > Version : 5.2.7 > Upstream Author : Roy Marples > * URL : http://roy.marples.name/projects/dhcpcd > * License : BSD-2 > Programming Lang: C, Shell > Description : dhcpcd5 - a DHCP client > What's the difference with the existing dhcpcd package? Cheers, Julien signature.asc Description: Digital signature
Bug#583501: ITA: xserver-xorg-video-openchrome -- display driver for VIA Unichrome video chipsets
On Thu, Aug 19, 2010 at 20:30:14 +0200, Julien Viard de Galbert wrote: > I have working hardware and some time to give to debian. > > I already did some bug triage, but some are related to the more recent > Chrome9 family of chipset. I think a more recent package using upstream > trunk can help sorting those bugs (if ever the submitters dare to try a > new package). > > Also as squeeze is frozen, an experimental package is probably > preferred. > This sounds great. > I've setup a git working place including debian's git and upstream svn. > It looks like the experimental branches have not been updated for long. > The upstream-experimental will merge nicely, but the debian-experimental > branch has kind of diverged... > Should I merge it (using some git revert if needed first), or can I just > restart it from the debian-unstable branch ? The current debian-experimental branch appears to be obsolete, so you should feel free to forget about it and restart from the -unstable branch, IMO. > This does not look like good git practice, except if you look at > experimental like a wip branch. How are other doing ? > > Finally I'm not DD (nor DM) so I will need help, review and sponsoring, > I hope some of you will have time for that. > Feel free to ask any questions that come up on debia...@ldo or #debian-x on irc.debian.org. Let me know if you want access to the pkg-xorg group on git.d.o. Cheers, Julien signature.asc Description: Digital signature
Bug#588946: ITP: wacom-source -- Wacom kernel driver in DKMS format
On Tue, Jul 13, 2010 at 11:36:01 -0500, Taylor LeMasurier-Wren wrote: > Package: wnpp > Severity: wishlist > Owner: "Taylor LeMasurier-Wren" > > > Package name: wacom-source > Version : 0.8.8 > Upstream Author : Ping Cheng > URL : http://www.example.org/ > License : GPL-2 > Programming Lang: C > Description : Wacom kernel driver in DKMS format > > This package builds an updated Wacom Kernel Module using > DKMS. This replaces the out-of-date module included with the > Kernel and rebuilds it whenever a new kernel is installed. > If the driver included in mainline is "out-of-date" then it should be updated, not worked around by a separate package, IMO. Cheers, Julien signature.asc Description: Digital signature
Bug#588946: ITP: wacom-source -- Wacom kernel driver in DKMS format
On Tue, Jul 13, 2010 at 13:00:33 -0500, Taylor LeMasurier-Wren wrote: > I use Ubuntu, but have been having trouble getting any MOTU's or Ubuntu Devs > to listen to me, so I made this package. If I can get this package into > debian, than I can get it into Ubuntu, and than hopefully backported to > Lucid. So you're not only working around the kernel development process, you're also working around the Ubuntu development process? Way to go... Cheers, Julien signature.asc Description: Digital signature
Bug#580814: Parallellizing the boot in Debian Squeeze - ready for wider testing
On Tue, May 11, 2010 at 12:37:56 +0200, Julian Andres Klode wrote: > On Sun, May 09, 2010 at 05:25:16PM +0200, Tollef Fog Heen wrote: > > I am so far just testing on a singe machine, but it's my firm belief > > that it's possible to have a fully functional systemd in squeeze. > > Only if #579755 is solved. While testing systemd on Debian, I found > out that the option CONFIG_CGROUP_DEBUG is disabled in our kernel, > but it is needed for systemd to work. > config CGROUP_DEBUG bool "Example debug cgroup subsystem" depends on CGROUPS default n help This option enables a simple cgroup subsystem that exports useful debugging information about the cgroups framework. Say N if unsure. Is it really a good idea to have init depend on such an option? (It's also disabled in all defconfigs.) Cheers, Julien signature.asc Description: Digital signature
Bug#580888: ITP: gnome-media-player -- GNOME Media Player is a simple media player for GNOME that supports playing media using the vlc, xine and gstreamer engines.
On Sun, May 9, 2010 at 18:25:15 +0300, Bilal Akhtar wrote: > Description : GNOME Media Player is a simple media player for > GNOME that supports playing media using the vlc, xine and gstreamer > engines. This is not a short description. Try to make it fit in a line. > > GNOME Media Player is a simple media player for GNOME that supports > playing media using the vlc, xine and gstreamer engines. It has the > ability to switch between the engines in the GUI, and features an engine > Auto-select mode, which automatically selects the best engine for > playing the selected file. > And this makes it sounds like a pretty pointless piece of software... Cheers, Julien signature.asc Description: Digital signature
Bug#535045: O: gnomoradio
retitle 535045 RM: gnomoradio -- RoQA: orphaned, RC buggy reassign 535045 ftp.debian.org kthxbye On Mon, Jun 29, 2009 at 10:45:17 +0200, Riccardo Setti wrote: > Package: wnpp > Severity: normal > > I'm no more interested in gnomoradio. I'm going to orphan it. Feel > free to take it over. > gnomoradio is now broken by the libao4 transition, and nobody stepped up to maintain it since last June, so reassigning to ftp.d.o for removal. Cheers, Julien signature.asc Description: Digital signature
Bug#533450: maintaining poulsbo in Debian
On Tue, Nov 17, 2009 at 21:44:23 +0100, Holger Levsen wrote: > Packagingtools-technically you could put a "Conflicts: libdrm2" into > libdrm-poulsbo1's > debian/control file, but I'm not sure this is the right solution here... It's not an acceptable solution. Why do you need this? If psb needs its own libdrm it can call it libdrm_poulsbo.so or whatever, it doesn't have to steal the name of the standard one. [...] > Xorg.0.log ends with: > > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenByBusid: Searching for BusID PCI:0:2:0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card1 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card2 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card3 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card4 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card5 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card6 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card7 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card8 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card9 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card10 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card11 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card12 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card13 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card14 > drmOpenByBusid: drmOpenMinor returns -1 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: node name is /dev/dri/card1 > drmOpenDevice: node name is /dev/dri/card2 > drmOpenDevice: node name is /dev/dri/card3 > drmOpenDevice: node name is /dev/dri/card4 > drmOpenDevice: node name is /dev/dri/card5 > drmOpenDevice: node name is /dev/dri/card6 > drmOpenDevice: node name is /dev/dri/card7 > drmOpenDevice: node name is /dev/dri/card8 > drmOpenDevice: node name is /dev/dri/card9 > drmOpenDevice: node name is /dev/dri/card10 > drmOpenDevice: node name is /dev/dri/card11 > drmOpenDevice: node name is /dev/dri/card12 > drmOpenDevice: node name is /dev/dri/card13 > drmOpenDevice: node name is /dev/dri/card14 > (EE) [drm] drmOpen failed. > (EE) PSB(0): [dri] DRIScreenInit failed. Disabling DRI. > (EE) [drm] Could not uninstall irq handler. > (EE) PSB(0): This driver currently needs DRM to operate. > Start by getting the kernel part working. You won't get X up before then. Cheers, Julien -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540362: O: xfs -- X font server
Package: wnpp Severity: normal Hi, The X Strike Force would like to get rid of xfs; it's not needed in most (all?) use cases, since most X clients now use Xft and/or pango to render text, not core X fonts (even emacs, these days! :)) So xfs wants to either get removed or get a new maintainer. Maybe LTSP people, if they still use this? Description: X font server xfs is a daemon that listens on a network port and serves X fonts to X servers (and thus to X clients). All X servers have the ability to serve locally installed fonts for themselves, but xfs makes it possible to offload that job from the X server, and/or have a central repository of fonts on a networked machine running xfs so that all the machines running X servers on a network do not require their own set of fonts. xfs may also be invoked by users to, for instance, make available X fonts in user accounts that are not available to the X server or to an already running system xfs. Current packaging is at git://git.debian.org/git/pkg-xorg/app/xfs Cheers, Julien -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537623: ITP: busybox-syslogd -- Provides syslogd and klogd using busybox' implementation
On Sun, Jul 19, 2009 at 23:41:24 +0200, Axel Beckert wrote: > Debian's busybox package has the syslogd and klogd functionalities > already compiled in, but to use them, a little bit more than a few > symbolic links is needed. > > This package provides the appropriate dependencies, the symbolic links > for syslogd and klogd, man pages (also symlinks), and init.d scripts. > why does this need a separate source package? Cheers, Julien -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522683: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Sun, 2009-04-12 at 15:01 +0200, Michael Meskes wrote: > On Sun, Apr 12, 2009 at 01:11:26PM +0100, Julien Cristau wrote: > > 515214 isn't most users. most users just want things to work. > > But then 515214 appears to be at least a significant amount of users. Anyway, no, it doesn't. > having things "just work" and being able to run a system without hal do not > contradict each other. in this case, yes they do. Cheers, Julien -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522683: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Sun, 2009-04-12 at 14:04 +0200, Michael Meskes wrote: > On Mon, Apr 06, 2009 at 09:55:39PM +0200, Michael Biebl wrote: > > As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards > > standardizing on one power management stack in Debian (and not install 3 by > > default [1]), i.e. I'd support in phasing out acpi-support and would gladly > > accept patches for hal and pm-utils which add (if there are) any missing > > bits > > from acpi-support. > > Not sure whether most users agree after reading #515214. 515214 isn't most users. most users just want things to work. Cheers, Julien -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520955: ITP: xserver-xorg-video-glamo -- X.Org X server -- SMedia Glamo display driver
Hi Luca, On Mon, 2009-03-23 at 22:35 +0100, Luca Capello wrote: > Package: wnpp > Owner: Luca Capello > Severity: wishlist > User: pkg-fso-ma...@lists.alioth.debian.org > Usertags: package-creation > > * Package name: xserver-xorg-video-glamo > Version : MMDD.gitCOMMIT (read below) > Upstream Author : mainly Lars-Peter Clausen > * URL or Web page : http://git.openmoko.org/?p=xf86-video-glamo.git;a=summary > * License : multiple, mostly XFree86 (full texts below) > Description : X.Org X server -- SMedia Glamo display driver > This package provides the driver for the SMedia Glamo 3362 chipset, > mostly found on the Openmoko Neo FreeRunner (GTA02). > . > More information about X.Org can be found at: > http://www.X.org> > http://xorg.freedesktop.org> > http://lists.freedesktop.org/mailman/listinfo/xorg> > . > This package is built from the X.Org xf86-video-glamo driver module. ^ the driver doesn't come from X.Org, so this (and the links above) is probably unnecessary. Also probably s/X.Org/Xorg/ in the short description, since that is referring to a particular DDX. > = > > NB, I cc:ed a lot of lists: please refrain to discuss non-Debian issues > on all of them. Except for general issues, pkg-fso-maint@ is the most > relevant one, which should always be cc:ed, TIA. > > This driver is based on the XFree86 fbdev driver, then adapted to the > SMedia Glamo chipset, more information are available at > > http://wiki.openmoko.org/wiki/Smedia_Glamo_3362 > > In my plan, this supersedes the Xglamo kdrive X11 server, which AFAIK is > not update anymore, ATM available in the pkg-fso repository at > > http://pkg-fso.alioth.debian.org > > The xserver-xorg-video-glamo package as well will be maintained under > the pkg-fso umbrella, but I would like to work as close as possible with > the X Strike Force, to be sure the package conforms their standards. If > the X Strike Force would like to take care of the package, I would more > than glad to "offer" it to them... I think it's better if the driver is maintained by people who use it, so I'm happy to see the pkg-fso team take care of it :) Feel free to ask on debian-x@ or #debian-x for any questions you have though, or if you want us to look over the package before upload. Cheers, Julien -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519510: ITP: polipo -- a caching web proxy
On Fri, 2009-03-13 at 09:26 +0100, Christoph Thielecke wrote: >Package name: polipo > Version: 1.0.4 > Upstream Author: [Christoph Thielecke ] Besides what Michal said, you're not the upstream author... Cheers, Julien -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515134: ITP: ircservices -- IRC Services for IRC networks providing services like Nick- and ChanServ
On Sat, Feb 14, 2009 at 19:38:16 +0100, Rondal wrote: > >> there are currently no other IRC Services packages in the > >> repositories > > [...] > > > > Unless I misunderstand your assertion or am taking it out of > > context, I would hold up at least the dancer-services package as a > > counterexample (though I expect there are others, this is one I > > actively use). > > Sorry, my search didn't turn up the dancer-services, as I searched for > packages containing the term irc. > hybserv would be another one. Cheers, Julien -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#513575: ITP: fswebcam -- Tiny and flexible webcam program
On Fri, 2009-01-30 at 15:23 +0100, Luca Niccoli wrote:
> 2009/1/30 Julien Cristau :
>
> > how many of those do we need? why this one in particular?
>
> I've been looking in Debian for a command line tool that takes
> pictures from a USB video capture device that doesn't support MJPEG,
> and couldn't find one (besides mplayer - but in a really hackish way);
> fswebcam does (it accepts input in a number of formats).
[snip list of fswebcam features]
Thanks, that replies to my question :)
Maybe that this kind of things ("why is this not already addressed by an
existing package?") should be part of most ITPs...
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#513575: ITP: fswebcam -- Tiny and flexible webcam program
On Fri, 2009-01-30 at 12:54 +0100, Luca Niccoli wrote: > * Package name: fswebcam > Version : 20070108 > Upstream Author : Philip Heron > * URL : http://www.firestorm.cx/fswebcam/ > * License : GPLv2 > Programming Lang: C > Description : Tiny and flexible webcam program how many of those do we need? why this one in particular? Cheers, Julien -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
reassign 316594 to wnpp, retitle 316594 to RFP: opengl-manpages -- OpenGL documentation
reassign 316594 wnpp retitle 316594 RFP: opengl-manpages -- OpenGL documentation -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496326: ITP: gwibber -- open source microblogging client for GNOME
On Sun, Aug 24, 2008 at 14:39:08 +0100, Daniel Watkins wrote: > Description : open source microblogging client for GNOME > Please remove 'open source' from the short description, that's not adding any information. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#418889: Nouveau packaging
On Sat, May 31, 2008 at 21:19:55 +0100, Matthew Johnson wrote: > Dear X maintainers, > > I'm considering uploading packages for the Nouveau drivers to > experimental. The summary of the discussion is attached to bug #418889. > The packages were adapted by Chris Lamb from Christopher Rogers' Ubuntu > PPA packages. > Thanks for this work. I haven't looked into the packages at all, so here are just quick comments. > The current packages are at: > > > http://chris-lamb.co.uk/debian/libdrm-snapshot_2.3.1~git%2b20080530%2b6e8a2cf-1.dsc > > http://chris-lamb.co.uk/debian/xserver-xorg-video-nouveau_0.0.10~git%2b20080526%2be034616-1.dsc > I'd rename the drm package to just 'drm-snapshot', since you provide the kernel modules as well as the lib. It seems there's a problem with libdrm, though, if you provide libdrm.so.2 you'll have to conflict with the libdrm2 package from unstable, and then the driver won't be installable together with the x server? If someone can check that the only symbols missing from the snapshot version of the lib are TTM-related, maybe it'd be better to just call it libdrm2? (I know I've said the opposite before, but I thought the removed symbols were being used.) The nouveau package description needs to be fixed to not refer to it as an X.Org driver, too, and point to nouveau.freedesktop.org instead of xorg.freedesktop.org. > They need Replaces/Conflits/Provides fixing. > > Would you like this maintained as part of the XSF and do you have any > other comments before I upload them? > Whatever you prefer is fine by me. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#418889: Packaging nouveau
On Sun, May 11, 2008 at 17:20:56 +0200, Vincent Bernat wrote: > To summarize, to push xserver-xorg-video-nouveau into experimental, we > need: > - libdrm git snapshot drm. not just libdrm. > - mesa git snapshot > > Moreover, libdrm git snapshot will generate a module source package that > will generate nouveau.ko and drm.ko. The latest one is incompatible with > the one in current Debian kernel (2.6.25) and will override it. > > At least, they need to be kept in sync as long as nouveau is not > releasing. This seems a bit too much even for experimental. Maybe things > will get settled when a new libdrm will be released. I think it's fine for experimental, as long as the packager is aware that it'll need quite some work to keep all the bits together, not just the initial packaging. I don't expect things to settle down this year, FWIW. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469080: RFA: atitvout -- ATI TV Out Support Program
On Mon, Apr 28, 2008 at 01:32:24 +0200, Evgeni Golov wrote: > On Mon, 28 Apr 2008 01:17:48 +0200 Julien Cristau wrote: > > > > I'm just wondering, shouldn't we remove atitvout at all? AFAIK the > > > TVout on Radeons is supported by xserver-xorg-video-ati through the > > > XRandR1.2 interface. > > > My Radeon does not have a TVout, so I cannot test it, but I'm CC'ing > > > [EMAIL PROTECTED], they should be able to give a short comment on that :) > > > > > the atitvout package description talks about ati rage mobility, not > > radeon, though? > > Uhm, /me has his ATI-filter on :) > Sorry for that. > But isn't the rage series supported by -ati (<= 6.8.0) and -r128? It is, but only radeon has randr 1.2. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469080: RFA: atitvout -- ATI TV Out Support Program
On Mon, Apr 28, 2008 at 01:11:33 +0200, Evgeni Golov wrote: > Hi, > > I'm just wondering, shouldn't we remove atitvout at all? AFAIK the > TVout on Radeons is supported by xserver-xorg-video-ati through the > XRandR1.2 interface. > My Radeon does not have a TVout, so I cannot test it, but I'm CC'ing > [EMAIL PROTECTED], they should be able to give a short comment on that :) > the atitvout package description talks about ati rage mobility, not radeon, though? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#473354: ITP: winhardware -- hardware summary report from a Win32 host
On Sun, Mar 30, 2008 at 14:26:48 -0300, Joel Franco wrote: > I would to hear others opinions about your opinion. > I don't think adding a package for a simple shell script makes any sense. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457473: ITP: extended_threading -- Extension of the python threading api
On Sat, Dec 22, 2007 at 18:36:16 +0100, Sandro Tosi wrote: > > Shouldn't the package name be something like python-extendable-threading > > then? i.e. have python- in it? > > the binary package will have the python- prefix, but that is the > intended source package name > Why not use the same name for both? I think it'd be clearer, and has no drawbacks afaics. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428777: ITP: xserver-xorg-video-avivo -- X.Org X server -- Avivo display driver
On Sat, Jun 16, 2007 at 13:52:54 +0200, Ludovic Rousseau wrote: > I compiled and tried the avivo driver. It does not work for me and I > reported bug 11281 [1] to bugs.freedesktop.org. > > Is there a mailing list to follow & discuss the development of the avivo > driver? > Probably [EMAIL PROTECTED] > How can I help? > See for example http://www.fooishbar.org/blog/tech/x/donations-2007-06-15-00-09.html and feel free to ask the developers on the mailing list or on IRC if you have further questions. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428776: ITP: libpciaccess -- Generic PCI access library for X
On Fri, Jun 15, 2007 at 15:04:33 +0200, Ludovic Rousseau wrote: > Sorry, I am a total git newbie :-) > > I did: > $ git clone git://git.debian.org/git/pkg-xorg/lib/libpciaccess.git > Initialized empty Git repository in > /home/rousseau/macbook/avivo/a/libpciaccess/.git/ > remote: Generating pack... > Done counting 269 objects. > Deltifying 269 objects... > remote: 100% (269/269) done > Indexing 269 objects... > remote: Total 269 (delta 166), reused 234 (delta 156) > 100% (269/269) done > Resolving 166 deltas... > 100% (166/166) done > $ ls > libpciaccess > $ cd libpciaccess/ > libpciaccess$ ls > [nothing except a .git directory] > With git >= 1.5, use this to check out the right branch: $ git-checkout -b debian-experimental origin/debian-experimental (by default, I think you get the debian-unstable branch, which doesn't exist yet in this repo) > The same command worked (at least I have some files) to get > xserver-xorg-video-avivo > Yeah, I made debian-experimental the default branch in the avivo repo. I've done so now for libpciaccess as well, and will try to remember to change it back when it gets a debian-unstable branch. HTH, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428777: ITP: xserver-xorg-video-avivo -- X.Org X server -- Avivo display driver
On Thu, Jun 14, 2007 at 21:38:39 +0200, Ludovic Rousseau wrote: > Great. Do you have .deb packages somewhere so I can test it easily? > > I have a Macbook pro with a ATI X1600. I think it has a R500 inside. > Not yet. But it's fairly easy to clone the git tree and run dpkg-buildpackage. You'll have to build libpciaccess first, and possibly add your card's pciid in the driver if it isn't there already. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428777: ITP: xserver-xorg-video-avivo -- X.Org X server -- Avivo display driver
Package: wnpp Severity: wishlist Owner: Debian X Strike Force <[EMAIL PROTECTED]> * Package name: xserver-xorg-video-avivo Version : 0.0.1 Upstream Authors: Daniel Stone <[EMAIL PROTECTED]> Matthew Garrett <[EMAIL PROTECTED]> Jerome Glisse <[EMAIL PROTECTED]> * URL : git://anongit.freedesktop.org/git/avivo/xf86-video-avivo * License : GPL Programming Lang: C Description : X.Org X server -- Avivo display driver This driver for the X.Org X server (see xserver-xorg for a further description) provides support for ATI R500 cards. . Note that this driver is currently experimental and works in 2D only. Anybody interested in helping out with the avivo package is welcome to contact debian-x (I don't think any of the current XSF members have the hardware). Preliminary packaging at http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-avivo.git signature.asc Description: Digital signature
Bug#428776: ITP: libpciaccess -- Generic PCI access library for X
Package: wnpp Severity: wishlist Owner: Debian X Strike Force <[EMAIL PROTECTED]> * Package name: libpciaccess Version : 0.8.0 Upstream Authors: Ian Romanick <[EMAIL PROTECTED]> Eric Anholt <[EMAIL PROTECTED]> edward shu <[EMAIL PROTECTED]> * URL : git://anongit.freedesktop.org/git/xorg/lib/libpciaccess * License : MIT/X Programming Lang: C Description : Generic PCI access library for X Provides functionality for X to access the PCI bus and devices in a platform-independant way. This is a dependency of the new avivo driver (for r500-based AMD cards), and will be used by future releases of the X.Org X server. Preliminary packaging at http://git.debian.org/?p=pkg-xorg/lib/libpciaccess.git signature.asc Description: Digital signature
Bug#428774: ITP: pixman -- pixel-manipulation library for X and cairo
Package: wnpp Severity: wishlist Owner: Debian X Strike Force <[EMAIL PROTECTED]> * Package name: pixman Version : 0.9.3 Upstream Author : Søren Sandmann <[EMAIL PROTECTED]> * URL : git://anongit.freedesktop.org/git/pixman * License : MIT/X Programming Lang: C Description : pixel-manipulation library for X and cairo A library for manipulating pixel regions -- a set of Y-X banded rectangles, image compositing using the Porter/Duff model and implicit mask generation for geometric primitives including trapezoids, triangles, and rectangles. Future releases of the X.Org X server and of cairo will link against pixman instead of duplicating this code, so packaging this is necessary before we can consider uploading recent git snapshots of the X server to experimental. Preliminary packaging at http://git.debian.org/?p=pkg-xorg/lib/pixman.git signature.asc Description: Digital signature
Bug#427248: ITP: promethee -- a productive numeric working space
On Sat, Jun 2, 2007 at 11:50:45 -0700, Ben Pfaff wrote: > "lambda (sbrice)" <[EMAIL PROTECTED]> writes: > > > Description : A productive numeric working space > > > > promethee is an all-inclusive education project (called numeric > > working space) which support school managing and > > is exclusively built with free software (need apache2 > > mysql-server-4.1 apache2-doc libapache2-mod-php4 php4-mysql > > php4-gd php4-cli phpmyadmin dependencies) > > This seems redundant. There's a Dependencies field in the > packaging system for listing dependencies. There's no need to > mention that a program in Debian is free software and built only > with free software--that's the only kind of program we accept > anyway. Also, since php4 is going away, stating that your package works with it seems kind of useless. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407468: ITP: cwiid -- Linux interface to the Wiimote
Hi, On Thu, Jan 18, 2007 at 18:57:41 +0100, Romain Beauxis wrote: > CWiid is a Linux interface to the Wiimote written in C. is there any reason this needs to be mentioned in the package description? I'd think most users don't care, and those who do can use debtags to find out. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405122: ITP: ocamlwc -- count the lines of code and comments in OCaml sources
On Mon, Jan 1, 2007 at 23:26:30 +0100, Daniel Baumann wrote: > > Why? dpatch.make(7) says: > > Using dpatch.make is rather straightforward: one has to include > > the file in debian/rules, change the appropriate targets to depend on > > patch and unpatch, and that is all it takes. > > In fact, in /usr/share/dpatch/dpatch.make, the patch target depends on > > patch-stamp. > > excately. patch depends on patch-stamp, so why not call patch-stamp > directly? ;) > I think I disagree with this, patch-stamp is an implementation detail. > > Another question. The Debian OCaml Policy (section 2.2) says: > > > > A bytecode package must build-depend-indep on ocaml-nox-3.09.2 (or > > ocaml-3.09.2 if the program either uses the Graphics or the LablTk > > module). The current version number of OCaml should not be hardcoded > > into the build-dependency (this is a deviation from a practice which > > used be recommended but is depreciated now). Of course, if it is > > necessary to ensure that the version of OCaml has a certain value then > > version constraints can be used. However, this should be justified by > > the requirements of the compilation of the program. > > > > This is not clear to me. It says I should build-depend-indep on > > ocaml-nox-3.09.2. However, wouldn't this mean "hardcoding the current > > version number of OCaml into the build-dependency"? > > Currently, I just have "Build-Depends-Indep: ocaml-nox". > > some packages do have a versioned depends, such as "ocaml-nox (>= > 3.09.2)", but the ocaml policy says to have a "ocaml-nox-3.09.2" > depends. ocaml-nox-3.09.2 is a virtual package provided by the current > ocaml-nox package. > I think this might be a bug in the ocaml packaging policy. A build-dep on ocaml-nox is fine, I think, but if this is a bytecode program (which I don't know, I haven't looked at the package yet) it needs to have a runtime dependency on the current ocaml-base (or ocaml-base-nox) package (ocaml-base-nox-3.09.2 at the moment). I don't think there is a reason to hardcode the ocaml version number in the build dependencies. Cheers, Julien signature.asc Description: Digital signature
Bug#251622: RFP: libfishsound -- Simple programming interface for decoding and encoding audio data using Vorbis and Speex
Package: wnpp Severity: wishlist * Package name: libfishsound Version : 0.6.2 Upstream Author : Conrad Parker <[EMAIL PROTECTED]> * URL : http://www.annodex.net/software/libfishsound/ * License : BSD Description : Simple programming interface for decoding and encoding audio data using Vorbis and Speex libfishsound is a wrapper around the existing codec libraries and provides a consistent, higher-level programming interface. It has been designed for use in a wide variety of applications; it has no direct dependencies on Annodex or Ogg encapsulation, though it is most commonly used in conjunction with liboggz to decode or encode Ogg encapsulated Vorbis or Speex files. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.6 Locale: LANG=C, LC_CTYPE=C
