Bug#1032997: ITP: pylsl -- Python bindings for liblsl
Package: wnpp Severity: wishlist Owner: Enrico Zini X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org * Package name: pylsl Version : 1.16.1 Upstream Contact: Christian A. Kothe * URL : https://github.com/labstreaminglayer/pylsl * License : MIT Programming Lang: Python Description : Python bindings for liblsl This is the Python interface to the Lab Streaming Layer (LSL). LSL is an overlay network for real-time exchange of time series between applications, most often used in research environments. LSL has clients for many other languages and platforms that are compatible with each other. - - - LSL seems to be a standard for taking data from devices like EEG sensors and making them availale to software that analyses them. I've packaged this for a personal project, and it would be straightforward to upload it to Debian. I can't take responsibility for supporting people with more professional needs besides trying to deal with FTBFS kind of issues, but after asking in the Debian Science Team mailing list, it can be maintained under the Science Team umbrella.
Bug#1032996: ITP: liblsl -- lsl library for multi-modal time-synched data transmission over the local network
Package: wnpp Severity: wishlist Owner: Enrico Zini X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org * Package name: liblsl Version : 4.6.0 Upstream Contact: Christian A. Kothe * URL : https://github.com/sccn/liblsl * License : MIT Programming Lang: C++ Description : lsl library for multi-modal time-synched data transmission over the local network The lab streaming layer is a simple all-in-one approach to streaming experiment data between applications in a lab, e.g. instrument time series, event markers, audio, and so on LSL seems to be a standard for taking data from devices like EEG sensors and making them availale to software that analyses them. I've packaged this for a personal project, and it would be straightforward to upload it to Debian. I can't take responsibility for supporting people with more professional needs besides trying to deal with FTBFS kind of issues, but after asking in the Debian Science Team mailing list, it can be maintained under the Science Team umbrella.
Bug#1024764: ITP: python-hdf5plugin -- Python library to make HDF5 compression filters usable from h5py
Package: wnpp Severity: wishlist Owner: Enrico Zini X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-hdf5plugin Version : 3.3.1 Upstream Author : "ESRF - Data Analysis Unit" * URL : https://github.com/silx-kit/hdf5plugin * License : MIT Programming Lang: C/Python Description : Python library to make HDF5 compression filters usable from h5py hdf5plugin provides HDF5 compression filters (namely: blosc, bitshuffle, lz4, FCIDECOMP, ZFP, zstd) and makes them usable from h5py. I am going to maintain this in the Debian Science Team group.
Bug#1024358: ITP: h5z-zfp -- Compression plugin for the HDF5 library using ZFP compression
Package: wnpp Severity: wishlist Owner: Enrico Zini X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: h5z-zfp Version : 1.1.0 Upstream Author : Mark C. Miller * URL : https://github.com/LLNL/H5Z-ZFP * License : BSD Programming Lang: C Description : Compression plugin for the HDF5 library using ZFP compression H5Z-ZFP is a compression filter for HDF5 using the ZFP compression library, supporting lossy and lossless compression of floating point and integer data to meet bitrate, accuracy, and/or precision targets. I'm going to maintain this package in the Debian Science Team salsa namespace.
Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Thu, Jul 14, 2022 at 12:43:16PM +0100, Edward Betts wrote: > I've been writing some code to work out the gender balance of speakers at a > conference. It parses the pentabarf XML of the schedule and feeds the speaker > names to this module. > > Here's the results for Debconf 22. > > 72 speakers > > male 48 66.7% > unknown 16 22.2% > female 45.6% > mostly_male22.8% > andy 11.4% > mostly_female 11.4% If the library works as the author intended, it will identify "Enrico" as male, which is a gender *I* don't identify with. This kind of extends to anything related to a person's identity: any software trying to determine an aspect of a person's identity is bound to eventually conflict with how a person lives their own identity. That conflict can be quite painful, so it's not surprising you get strong reactions when intending to package something that pretends to tell people what a person is, without asking them first. This external determination of identity will then extend to the library to any software or research using it. I totally understand the good intentions, but the result honestly amplifies the pain. I think the right way to get the statistics you're looking for would be to ask speakers to state their own identity on pentabarf, so that statistics are based on self-determination, rather than external overrides of it. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#1006958: RFP: pytype -- Pytype checks and infers types for your Python code
Package: wnpp
Severity: wishlist
* Package name: pytype
Version : 2022.3.8
Upstream Author : Google
* URL : https://google.github.io/pytype/
* License : Apache, with some code with BSD and MIT
Programming Lang: Python
Description : Pytype checks and infers types for your Python code
Pytype checks and infers types for your Python code - without
requiring type annotations. Pytype can:
* Lint plain Python code, flagging common mistakes such as misspelled
attribute names, incorrect function calls, and much more, even
across file boundaries.
* Enforce user-provided type annotations. While annotations are
optional for pytype, it will check and apply them where present.
* Generate type annotations in standalone files ("pyi files"), which
can be merged back into the Python source with a provided merge-pyi
tool.
Pytype is a static analyzer; it does not execute the code it runs on.
It seems like a great help in Python development. It has a different
approach than mypy, and would complement it quite nicely.
Bug#1006470: RFP: dduper -- Fast block-level out-of-band BTRFS deduplication tool.
Package: wnpp Severity: wishlist * Package name: dduper Version : 0.04 Upstream Author : Lakshmipathi * URL : https://github.com/lakshmipathi/dduper * License : GPL-2+ Programming Lang: Python Description : Fast block-level out-of-band BTRFS deduplication tool. dduper is a block-level out-of-band BTRFS dedupe tool. This works by fetching built-in checksum from BTRFS csum-tree, instead of reading file blocks and computing checksum itself. This hugely improves the performance. This seems the fastest and most lightweight deduplication tool for BTRFS made so far.
Bug#1004388: RFP: python3-inotify -- An adapter to Linux kernel support for inotify directory-watching
Package: wnpp Severity: wishlist * Package name: python3-inotify Version : 0.2.10 Upstream Author : Dustin Oprea * URL : https://github.com/dsoprea/PyInotify * License : GPL-2 Programming Lang: Python Description : An adapter to Linux kernel support for inotify directory-watching inotify functionality is available from the Linux kernel and allows you to register one or more directories for watching, and to simply block and wait for notification events. This is obviously far more efficient than polling one or more directories to determine if anything has changed. This is available in the Linux kernel as of version 2.6 . . We've designed this library to act as a generator. All you have to do is loop, and you'll see one event at a time and block in-between. After each cycle (all notified events were processed, or no events were received), you'll get a None. You may use this as an opportunity to perform other tasks, if your application is being primarily driven by inotify events. By default, we'll only block for one-second on queries to the kernel. This may be set to something else by passing a seconds-value into the constructor as block_duration_s. There exist two upstream inotify libraries significant here: https://github.com/dsoprea/PyInotify Subject of this RFP: note that it contains a module called 'inotify', not 'pyinotify' https://github.com/seb-m/pyinotify Currently ppackaged as python3-pyinotify Looking at https://github.com/dsoprea/PyInotify it says: This project is unrelated to the *PyInotify* project that existed prior to this one (this project began in 2015). That project is defunct and no longer available. and indeed, https://github.com/seb-m/pyinotify which is listed as upstream of python3-pyinotify, seems to be stuck in 2015. To the best that I could see, https://github.com/dsoprea/PyInotify is not currently packaged in Debian. If I understand correctly, the only way to access inotify functionality in Python with libraries in Debian at the moment is via the old pyinotify, and at least gunicorn is requiring the newer one for inotify-based reloading to work: https://docs.gunicorn.org/en/stable/settings.html#reload "In order to use the inotify reloader, you must have the inotify package installed." I reported an issue to python3-pyinotify to track the upstream abandonment, and I'm filing this RFP for a replacement that would also fulfill gunicorn requirements to activate inotify-based features Enrico
Bug#961726: OK ! here are the tarballs
On Thu, May 28, 2020 at 02:49:38PM +0200, Paolo Greppi wrote: > This certainly makes sense and will be easier to digest by ftp-master > (although you'll have two packages in NEW). > > For the tarballs, they are here: > https://gitlab.eumetsat.int/open-source/PublicDecompWT/-/tags > (click on the Download icon at the right). Thanks! I don't see the sense of autogenerating a tarball from git in order to build a non-native package, though. Given that I'm also adding a CMakeLists.txt and a pkg-config template on top of it, I find that using a native package regularly rebase on upstream's git simplifies my work significantly. > gitlab works well with uscan, see for example: > https://codesearch.debian.net/search?q=gitlab+path%3Adebian%2Fwatch=0 Thanks, good tip! I've added a watchfile looking for new tags. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#961726: ITP: publicdecompwt -- Wavelet decompression tool for xRIT files from MeteoSat Second Generation
Package: wnpp Severity: wishlist Owner: Enrico Zini * Package name: publicdecompwt Version : 2.7.2 Upstream Author : EUMETSAT http://www.eumetsat.int/ * URL : https://gitlab.eumetsat.int/open-source/PublicDecompWT * License : Apache Programming Lang: C++ Description : Wavelet decompression tool for xRIT files from MeteoSat Second Generation This is a development-only library with the decompression code for MeteoSat Second Generation (MSG) images, provided by EUMETSAT. . It can be used to build software that can read MSG images. EUMETSAT has finally freed the source code of this library, and I need to package it as a build-dependency for meteosatlib: https://github.com/ARPA-SIMC/meteosatlib/ To the best of my understanding, upstream does not distribute tarballs, does not support shlibs, and provides only a rudimentary Makefile, so I've added a simple CMakeLists.txt to make it build as Debian tools expect it, and packaged it as a `-dev`-only native package. Enrico
Bug#954277: RFP: aiohttp-csrf -- The library provides csrf (xsrf) protection for aiohttp.web
Package: wnpp Severity: wishlist * Package name: aiohttp-csrf Version : 0.0.2 Upstream Author : Tom A. TensorTom https://github.com/TensorTom * URL : https://github.com/TensorTom/aiohttp-csrf * License : MIT Programming Lang: Python Description : The library provides csrf (xsrf) protection for aiohttp.web This package seems to be a basic requirement for developing aiohttp applications exposed to the web, since as far as I could see, aiohttp does not come with XSRF protection by default.
Bug#894551: ITP: fascism -- Exhaustive exploration of Fascist theory and practice
Package: wnpp Severity: wishlist Owner: Enrico Zini <enr...@debian.org> * Package name: fascism Version : 19190323 Upstream Author : Too many forks to list * URL : https://en.wikipedia.org/wiki/Fascism * License : All rights revoked Section : non-free Description : Exhaustive exploration of Fascist theory and practice Fascism is a form of radical authoritarian nationalism, characterized by dictatorial power, forcible suppression of opposition and control of industry and commerce, which came to prominence in early 20th-century Europe. The first fascist movements emerged in Italy during World War I before it spread to other European countries. > - why is this package useful/relevant? I believe this is the development trend most of the world is currently aiming for, and that, like with other recent questionable development practices, Debian should at least acknowledge its existance, but not embrace it. > - is it a dependency for another package? No. Historically, once fascism has been launched, there has been little space for anything else. > - do you use it? I do all I can to avoid it.
Bug#830582: ITP: staticsite -- Static site generator
Package: wnpp Severity: wishlist Owner: Enrico Zini <enr...@debian.org> * Package name: staticsite Version : 0.4 Upstream Author : Enrico Zini <enr...@debian.org> * URL : https://github.com/spanezz/staticsite * License : GPL Programming Lang: Python Description : Static site generator Static site generator based on markdown and jinja2. . Features: - themable - free content structure - hugo-style archetypes and front matter - live preview server I wrote this, have been using it for some months, so far I'm very happy with it, and I'd like to see what happens if I try and share it with the world. The reason I ended up writing yet another static site generator is here: http://www.enricozini.org/blog/2016/static-site-generators/ and more information about it is here: http://www.enricozini.org/tags/ssite/ and here: https://github.com/spanezz/staticsite#staticsite Some people have expressed interest in it, but were put off by it not being in Debian. Since now, thanks to Hugo Lefeuvre[1], all its dependencies are in Debian, I'm giving it a try. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816727 Enrico
Bug#745027: Quick debianize and local install procedure
Hello, I wanted to try vdirsyncer, this is what I did to quickly package it locally: * Built the dependencies that are currently not in debian testing: git clone https://github.com/click-contrib/click-log.git (got d153c41698768e80f1569e81d540f1cd9937567d) python3 setup.py sdist py2dsc-deb --with-python3=true dist/click-log-0.1.3.tar.gz sudo dpkg -i deb_dist/python3-click-log_0.1.3-1_all.deb git clone https://github.com/click-contrib/click-threading.git (got cdc1dbda7e8a565017d6fb2c2acc33a4c5705ead) python3 setup.py sdist py2dsc-deb --with-python3=true dist/click-threading-0.1.2.tar.gz sudo dpkg -i deb_dist/python3-click-threading_0.1.2-1_all.deb git clone https://github.com/untitaker/python-atomicwrites.git (got 349e14c2eb30cb7c10d7bd8244f67d2451fe30e5) python3 setup.py sdist py2dsc-deb --with-python3=true dist/atomicwrites-1.0.0.tar.gz sudo dpkg -i deb_dist/python3-atomicwrites_1.0.0-1_all.deb * Built vdirsyncer git clone https://github.com/pimutils/vdirsyncer.git (got d034c6b67fac1eaeecd7b7914d663be56aa4) python3 setup.py sdist py2dsc --with-python3=true dist/vdirsyncer-0.9.4.dev19+ngd034c6b.tar.gz # edited debian/rules to add an empty "override_dh_auto_test:" target # to disable tests while building. # bult and installed. François, how's the situation with the packaging? Do you need help? Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Bug#745027: Missing dependencies
On Tue, Feb 02, 2016 at 06:07:56PM +0100, Markus Unterwaditzer wrote: > Sorry to insist, but I'd really like to have a definitive answer on this > before > vdirsyncer is packaged. > > I suspect that if vdirsyncer makes its way into stable before 1.0, it > essentially means I'm forced into long-term support of whichever release is in > stable. However, ideally I'd like to only support the latest release of > vdirsyncer. > > If being in stable would really hinder timely updates, I'd prefer vdirsyncer > to > stay in testing/unstable forever. I am very happy to see your concerns about support of your software, I wish more developers cared like you did. It is possible to keep the package only in unstable, except for versions that you decided to officially support long-term, if any. There can be a bug in the Debian BTS with a "serious" severity saying "Not intended to be included on a stable Debian system". If you wish, the bug can document that if one is interested in having vdirsyncer in Debian stable, they can offer to coordinate with you helping upstream development and doing the work of providing long term support for specific releases. Would that be acceptable? Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Bug#816727: RFP: python-slugify -- A Python slugify application that handles unicode
Package: wnpp Severity: wishlist * Package name: python-slugify Version : 0.1 Upstream Author : Val Neekman * URL : https://github.com/un33k/python-slugify * License : BSD Programming Lang: Python Description : A Python slugify application that handles unicode A python module with a function that takes a string and returns a slug for it that can be use in URLs and file names. Slug generation is configurable and also support trasliteration of unicode. I would like to have this package in Debian because it is currently the dependency of staticsite (https://github.com/spanezz/staticsite) that is not yet in Debian. I am not aware of any other slug-generating library for Python available in the archive. The package already works with Python3.
Bug#813212: O: polygen -- generator of random sentences from grammar definitions
Package: wnpp Severity: normal I intend to orphan the polygen package. The package description is: PolyGen is a program for generating random sentences according to a grammar definition, that is following custom syntactical and lexical rules. . Formally, it is an interpreter of a language itself designed to define languages, where to interpret means executing a source program in real time and eventually outputting its result. . Here a source program is a grammar definition, the execution consists in the exploration of such grammar by selecting a random path and the result is the sentence built on the way. . Though PolyGen is quite a serious piece of software then, what else would be more noble for it than being used as a parody tool for linguistical habits, stereotypes and trends of this foolish era? . Principles of parody are focusing a ridiculous topic and eventually abstracting its rules and schemes (here in terms of a grammar definition) by which reproducing it through the variatio device. And randomization is perfect at this purpose thanks to its purely asemantic behaviour =:) Rationale is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813213: O: tagcoll2
Package: wnpp Severity: normal Hello, I'm orphaning tagcoll2. Rationale is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813211: O: omhacks
Package: wnpp Severity: normal Hello, I'm orphaning omhacks. Rationale is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813214: O: xcowsay -- Graphical configurable talking cow
Package: wnpp Severity: normal I intend to orphan the xcowsay package. The package description is: A graphical configurable talking cow. It's a GTK+ version of the classic cowsay Perl script. It displays a cute pop-up cow on your desktop with a speech bubble and some customizable text. There's also a dream mode where the cow can display images. It comes with a fortune(6) wrapper script, xcowfortune, which you can cron to deliver periodic fortune cookies via the cow. Rationale is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813236: O: debiancontributors -- Manage submissions to contributors.debian.org
Package: wnpp Severity: normal I intend to orphan the debiancontributors package. The package description is: This module contains the code to submit and parse contributions to contributors.debian.org. . It can be used to prepare submissions and submit them to the site, and it is used by the site to parse and validate them. Rationale: https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813235: O: grib-api -- GRIB decoding/encoding software library (development)
Package: wnpp Severity: normal I intend to orphan the grib-api package. The package description is: The ECMWF GRIB API is an application program interface accessible from C and FORTRAN programs developed for encoding and decoding WMO FM-92 GRIB edition 1 and edition 2 messages. . ECMWF is the European Centre for Medium-Range Weather Forecasts. Rationale: https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813201: O: apt-xapian-index -- maintenance and search tools for a Xapian index of Debian packages
Package: wnpp Severity: normal I intend to orphan the apt-xapian-index package. The package description is: This package provides update-apt-xapian-index, a tool to maintain a Xapian index of Debian package information in /var/lib/apt-xapian-index, and axi-cache, a command line search tool that uses the index. . axi-cache allows one to search packages very quickly, and it also interfaces with the shell command line completion in a smart way, providing context-sensitive keyword and tag suggestions even before the search command is actually run. . update-apt-xapian-index allows plugins to be installed in /usr/share/apt-xapian-index to index all sorts of extra information, such as Debtags tags, popcon information, package ratings and anything else that would fit. . The index generated by update-apt-xapian-index is self-documenting, as it contains an autogenerated README file with information on the index layout and all the data that can be found in it. Rationale is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813203: O: debdry
Package: wnpp Severity: normal I intend to orphan debdry. Rationale is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813200: O: buffy -- Heavy duty browser for mail folders
Package: wnpp Severity: normal I intend to orphan the buffy package. The package description is: Buffy is a program that displays a compact summary of your mail folders, and allows to invoke a command (usually a mail reader) on them. It is written with the intent of being a handy everyday tool for people handling large volumes of mail. For mutt users, this can be a nice front-end to supplement the simple built-in folder browser when one has many folders to keep track of. . Buffy tries hard to work out of the box: it looks for mail folders in sensible places and comes with reasonable defaults. . The program is functional but still very young, and only Maildir and Mailbox format are supported at the moment. Rationale for the orphaning is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813204: O: debtags -- Enables support for package tags
Package: wnpp Severity: normal I intend to orphan the debtags package. The package description is: debtags provides a system to download a database of package tags and keep it up to date. A package tag is a small label that gets attached to a Debian package to represent one of its qualities. . A package tag database in the system can enable advanced package search techniques, and advanced package browsing functions in programs that support it. . This package has been made as a way to deploy and test package tags support until it gets integrated in the normal Debian workflow. Rationale is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813202: O: cfget -- featureful tool to read values from config files
Package: wnpp Severity: normal I intend to orphan the cfget package. The package description is: cfget is a simple yet featureful tool to read values from configuration files. It is useful, for example, to create configurable shellscripts or makefiles. . Besides retrieving values, it can dump the information in several convenient ways, like a set of sh exports commands that can be conveniently passed to eval. It can also use the configuration values to expand template files. . It can also be configured to support virtual configuration values that, if not present in the config file, are automatically computed from the existing values. This makes it convenient, for example, to get a "duration" value from a configuration file that only contains a "start date" and an "end date". . It is also easy to create plugins to provide custom templating systems, export styles, dynamic values and even custom configuration file parsers. Rationale is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813206: O: libbuffy-bindings -- Perl wrapper for the libbuffy library
Package: wnpp Severity: normal I intend to orphan the libbuffy-bindings package. The package description is: Buffy wants to be the ultimate mail folder summary system. . This library provides efficient mailfolder checking routines, packaged in a library with a simple API and with wrappers for many languages, so that everyone can create mail folder summary systems in the language they prefer without having to care about the actual mailbox checking. . Libbuffy currently supports detection and summarizing of folders in Maildir and Mailbox format. . This package provides a Perl wrapper for libbuffy. Rationale is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813205: O: libbuffy -- Base functions for building mailbox summary applications
Package: wnpp Severity: normal I intend to orphan the libbuffy package. The package description is: Buffy wants to be the ultimate mail folder summary system. . This library provides efficient mailfolder checking routines, packaged in a library with a simple API and with wrappers for many languages, so that everyone can create mail folder summary systems in the language they prefer without having to care about the actual mailbox checking. . Libbuffy currently supports detection and summarizing of folders in Maildir and Mailbox format. . This package provides the development headers and library for libbuffy. No shared library is packaged until the API is stabilized. Rationale is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813210: O: nodm
Package: wnpp Severity: normal I'm orphaning nodm. Rationale is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813208: O: libwibble
Package: wnpp Severity: normal I'm orphaning libwibble. Rationale is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813207: O: libept -- High-level library for managing Debian package information
Package: wnpp Severity: normal I intend to orphan the libept package. The package description is: The library defines a very minimal framework in which many sources of data about Debian packages can be implemented and queried together. . The library includes four data sources: . * APT: access the APT database * Debtags: access the Debtags tag information * Popcon: access Popcon package scores * The Xapian index built by apt-xapian-index . This is the development library. Rationale is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#813209: O: mythes-it -- Italian Thesaurus for OpenOffice.org 2
Package: wnpp Severity: normal I intend to orphan the mythes-it package. The package description is: This package contains an Italian thesaurus for use with the OpenOffice.org 2 office suite. . The thesaurus data in this package has been created from scratch and reviewed by a network of Italian high school students, teachers and volunteers. Rationale is at https://lists.debian.org/debian-devel/2016/01/msg00729.html
Bug#789145: RFA: mythes-it -- Italian Thesaurus for OpenOffice.org 2
Package: wnpp Severity: normal I request an adopter for the mythes-it package. I am emotionally attached to it, however I do not have the motivation and the energy to stay on top of the libreoffice/mythes packaging ecosystem, and my emotional attachment should not mean that the library should stay badly maintained. I wish this could be maintained by people who do a good job. I'm happy to stay around as a liaison to upstream. Thank you, Enrico The package description is: This package contains an Italian thesaurus for use with the OpenOffice.org 2 office suite. . The thesaurus data in this package has been created from scratch and reviewed by a network of Italian high school students, teachers and volunteers. -- 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/20150618092757.21405.19997.report...@viaza.enricozini.org
Bug#789146: RFA: libept -- Obsolete commandline tool to search the package archive
Package: wnpp Severity: normal I request an adopter for the libept package. The package description is: ept-cache has been superseded by axi-cache, provided by apt-xapian-index. . This package provides a dummy ept-cache script that just call axi-cache. I am upstream, but when it comes to Debian packaging I miss the energy and motivation to stay on top of rather important things like the apt-pkg ABI system. I am not even able to understand all of the cmake packaging, which was not done by me. I'd like to keep being upstream and chopping away bits of libept's code until the library becomes trivial or disappears entirely (see #540218), but I wish somebody else could take care of the packaging, and do a proper job at it. Thank you, Enrico -- 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/20150618093204.21543.24655.report...@viaza.enricozini.org
Bug#750576: ITP: debdry -- Semi-assisted automatic Debian packaging
Package: wnpp Severity: wishlist Owner: Enrico Zini enr...@debian.org * Package name: debdry Version : 0.1 Upstream Author : Enrico Zini enr...@enricozini.org * URL : http://anonscm.debian.org/gitweb/?p=collab-maint/debdry.git * License : GPL3 Programming Lang: Python 3 Description : Semi-assisted automatic Debian packaging debdry is for debian/ directories what debhelper7 is for debian/rules. It applies the Don't Repeat Yourself idea to packaging, attempting to reuse as much as possible of upstream's metadata and standard packaging practices. debdry runs an appropriate auto-debianisation tool for a given source directory, then applies manual overrides from a debian.in directory. - - - I'm generally fond of the DRY principle (http://c2.com/cgi/wiki?DontRepeatYourself) but every time I package software for Debian I feel WET (Write Everything Twice) instead. Many upstream ecosystems have started including enough metadata in their upstream packaging to significantly overlap with debian/. Think short/long descriptions, upstream URLs, licenses, dependencies. When the upstream packaging is well made, there is usually not much else to add to a dh-make-equivalent initial boilerplate code, besides testing and taking responsibility for it. Maintaining software in Debian should be about testing and taking responsibility for it, not about retyping things that upstream has already typed. What if upstream got it wrong? It often happens. In that case, we can patch their sources, and send them the patch. That way, instead of having our own private work-arounds, we make the packaging better for everyone, even those who do not use Debian. The idea of debdry is to regenerate the debian/ directory every time a new version of the software is packaged, using the dh-make-equivalent for the given package type. It then takes manually maintained data from the debian.in/ directory and uses it to complete the packaging. At each new version there is a chance for the debianisation to be updated: the Python team switches from dh_pysupport to dh_python2? Your package will automatically follow (provided python-stdeb is updated accordingly, but that is another story). I like how with debhelper7 we are writing debian/rules files that only describe how the package diverges from a standard. I want to do exactly the same for the whole debian/ directory. Ideally, the debian.in/ directory used by debdry should only describe how the upstream packaging diverges from a standard in a way that cannot be fixed by patching it. I have no intention of having debdry replace hand-writing debian/ directories, nor have it handle all possible corner cases. I aim at it being useful in the general case. I want to address the ordinary, routine, boring work, and leave the rest as it is. This is also a proof of concept for an idea. We can discuss it in more detail here, or at DebConf. In the meantime I'd like to use it for my packages, because frankly, I'm bored of writing everything twice. Ciao, Enrico -- 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/20140604171801.12659.37731.report...@viaza.enricozini.org
Bug#733566: RFP: python-django-ratelimit -- Cache-based rate-limiting for Django
Package: wnpp Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi. I'd like this to be in Debian because I've started using it for nm.debian.org, but I don't think I'd do a good job maintaining it, time-wise. * Package name: python-django-ratelimit Version : 0.4.0 Upstream Author : James Socol m...@jamessocol.com * URL : https://github.com/jsocol/django-ratelimit * License : BSD Programming Lang: Python Description : Cache-based rate-limiting for Django Django Ratelimit provides a decorator to rate-limit views. Limiting can be based on IP address or a field in the request--either a GET or POST variable. - - - Since I do not trust random stuff pulled via github, I performed a code review of commit d58c489797405db348b30dec6103dcfff73160ec and it looks safe to me. Ciao, Enrico -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSwK0DAAoJEB5qw/OH8O2sza8QAL6Vh4b49QSGeLYa00Tw0AOa PU8s7ojXbaC1HNf6OrDoLbEOzoWx6GlFx31lJf9B4gDOctzXt9HEdJL4pVcNW1GB zuP7xARyckElwyMsGntsBzvUbyMXziFeCpZ+Lffz63nLf46SXOCmlh0/+2qHE6Dd ZyJWBtO/fBS3/sHeP8hwgumZoDOB/xkQUgu28cEACG8Za9KVU6CJq13hXOnf1ppe P0a7GkcJ6OLFNG5S3Gr6fvFTVTPVBgGHEmS4Gt92SYs9jETgHqPhbEYpfZfo+oVg ZQYM/PC21ElNzIP+3AgEINoMGRxLFJpv96Tmq5Zw1DKgEd+AjnUv31UR7AopnMYy CZxvPyfKtNXtj4kfHofbVhJyVZxjojz3FIWPaqQDntZ6hb/cJIa2cym0PCsasBmt EsRLGEWp5sQ+cxx8M1NP5ta2ROVInl6oWRWodl3dbpjLc35UFMenSdI185yz8REN iWyfKiVwZ1TZbgVT/Nr6jR/QOGZ+FGxjpQSZT4SbIhO87LZiRH4iG/QiSbJNewXM 4zpHRsi6QkC1lkpzVU4mdDf0enEIn/hkoFNPRAJ63YYdvS1mbodHABsSijEea8Gf nVa8l05NBkMKNl0X0ZNjsZab9znrHzk2Vm+voXxG6HTpf7w15WeGun/SLoefGZ7x ZdWVCVZchOFVAKlWFov2 =Bp4/ -END PGP SIGNATURE- -- 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/20131229231527.11368.37558.report...@viaza.enricozini.org
Bug#732991: ITP: python-debiancontributors -- Manage submissions to contributors.debian.org
Package: wnpp Severity: wishlist Owner: Enrico Zini enr...@debian.org * Package name: python-debiancontributors Version : 0.1 Upstream Author : Enrico Zini enr...@debian.org * URL : http://anonscm.debian.org/gitweb/?p=nm/python-debiancontributors.git * License : LGPL-3+ Programming Lang: Python Description : Manage submissions to contributors.debian.org This module contains the code to submit and parse contributions to contributors.debian.org. It can be used to prepare submissions and submit them to the site, and it is used by the site to parse and validate them. - - - In preparation for a contributors.debian.org announcement, I'm doing some QA and packaging on code that people can use to send submissions. Ciao, Enrico -- 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/20131223161644.8074.2266.report...@viaza.enricozini.org
Bug#678382: RFH: libept -- High-level library for managing Debian package information
Package: wnpp Severity: normal I request assistance with maintaining the libept package. The package description is: The library defines a very minimal framework in which many sources of data about Debian packages can be implemented and queried together. . The library includes four data sources: . * APT: access the APT database * Debtags: access the Debtags tag information * Popcon: access Popcon package scores * The Xapian index built by apt-xapian-index I do not have the energy to maintain libept anymore. #540218 has a plan for gradually replacing it with better options. #677551 has specific details wrt dropping aptitude's dependency on libept, so that it can become a far less critical piece of infrastructure. I'll try to keep libept afloat until it's gone, but I won't be able to do much besides dealing with the occasional FTBFS on toolchain changes, or helping to port client code to use libapt-pkg/libxapian. Help is very welcome to keep on top of the former. Ciao, Enrico -- 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/20120621104300.2234.94639.report...@viaza.enricozini.org
Bug#646804: ITP: cheermeup -- Send affirmative messages to the user via the notification library
On Thu, Oct 27, 2011 at 04:07:57PM +, Thomas Thurman wrote: In case it helps anyone's decision, I think the list of affirmative messages is short enough to include here: It is okay to express your needs and feelings. [...] You've made people happy. WHAT? You mean it doesn't have polygen integration? How dare they make something like this without using polygen! Ciao, Enrico who's SO going to file a bug about it as soon as there is a bug-reportable package. -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Bug#612897: ITP: wreport -- C++ library for working with weather reports
Package: wnpp Severity: wishlist Owner: Enrico Zini enr...@debian.org * Package name: wreport Version : 1.5 Upstream Author : Enrico Zini enr...@enricozini.org * URL : http://www.arpa.emr.it/dettaglio_documento.asp?id=2927idlivello=64 * License : GPL Programming Lang: C++ Description : library for working with weather reports libwreport is a C++ library for working with weather reports. . The main feature of libwreport is a powerful decoder and encoder for the BUFR and CREX formats. . It also provides a useful abstraction to handle values found in weather reports, with awareness of significant digits, measurement units, variable descriptions, unit conversion and attributes on variables. . Features provided: . * Read and write BUFR version 2, 3, and 4 * Read and write CREX * Unit conversion * Handling of physical variables Besides being a proper, powerful, tested, free codec for BUFR and CREX, this is going to be a dependency for the new upstream version of the dballe package. Ciao, Enrico -- 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/20110211122344.1593.83249.reportbug@localhost
Bug#548817: Orphaning guessnet
Hello, the RFA bug has been open for one year. There has been no adoption, and I'm guilty of not even having managed to get back to the two I'm new, where do I start? offers. Jonathan and Brad, I'm very sorry :( It's time to orphan it. I would also like to close the Alioth project and mailing lists, which was a completely exagerated setup for guessnet. I've moved the code to collab-maint, converting from svn to git, and updated debian/control to point to http://git.debian.org/?p=collab-maint/guessnet.git Maybe this is not an end for guessnet, but a new beginning. Time will tell. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Bug#602197: O: launchtool
Package: wnpp Severity: normal Hello, I'm not doing any work on launchtool, and I'm not using it, so it's time to orphan it. I had a plan to dismember launchtool and merge the various parts in start-stop-daemon and in a simpler non-daemon, supervisor tool. However, I also don't see myself having time or need to do that anytime soon. For reference, I post here the plan I had for launchtool to transcend to something better. Most of the work should be rather straightforward, as it's based on the existing code. Most of the code in common/ is now maintained in the wibble library (libwibble-dev) and can just be dropped. It can all be a fun programming excercise for people who have more time than I do. * The plan for transcendency Launchtool is a bit like start-stop-daemon. The differences are: - launchtool is more featureful; - start-stop-daemon is more tested. Ideally, features should be ported from launchtool to start-stop-daemon. The best way to do so, is to remove daemonisation and pidfile features from launchtool and just turn it into an application wrapper that handles restart policies and logging. Features that are already in start-stop-daemon: -k, --kill[=signal] --check -d, --daemon, “daemon” -n, --no-daemon --pidfile, “pidfile” --no-pidfile --piddir=dir, “piddir” --chroot=dir, “root dir” --chdir=dir, “start dir” -u, --user=user, “user” -g, --group=group, “group” --umask=mask, “umask” Features that can be implemented in a simple wrapper/supervisor command: -L, --infinite-runs, “infinite runs” --no-infinite-runs --wait-times=t1,t2,... , “wait times” --good-running-time=seconds, “good running time” --forwarded-signals=sig1,sig2,... , “forwarded signals” --blocked-signals=sig1,sig2,... , “blocked signals” --limit-cpu=seconds, “cpu limit” --limit-file-size=1024b-blocks, “file size limit” --limit-data-memory=1024b-blocks, “data memory limit” --limit-process-count=count, “process count limit” --limit-open-files=count, “open files limit” --limit-core-size=1024b-blocks, “core size limit” --restrict-environment, “restrict environment” --no-restrict-environment --allowed-env-vars=var1,var2,... , “allowed env vars” --log-launchtool-output=target, “launchtool output” --log-launchtool-errors=target, “launchtool errors” --log-child-output=target, “command output” --log-child-errors=target, “command errors” --silent-restart-status=value, “silent restart status” --silent-restart-time=seconds, “silent restart time” --stats, “stats” --no-stats Other TODO items: - Port to wibble. - Improve commandline help: give a summary of the kind of options and implement --help-something subpages to avoid cluttering the screen presenting them all in a single run - Improve environment management; see if there's a proper way to create a clean environment - Add an option to directly execute command and arguments instead of passing them to sh -c Ciao, Enrico -- 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/20101102125342.28440.49586.report...@localhost
Bug#594099: ITP: pm-utils-light -- pm-utils replacement for embedded hardware
On Tue, Aug 24, 2010 at 09:53:14AM +0200, Josselin Mouette wrote: It looks like an interesting piece software, but having to choose between one implementation that is slow and one that doesn’t support quirks looks like a lose-lose situation to me. Are there any efforts underway to merge the two projects, or at least their functionality? Not as far as I know, and I'm not sure it would be possible. We talked about it in the pm-utils list, but it does not sound feasible. pm-utils achieves lots of flexibility by using rather complex shellscripts that source a large library of useful functions. Running those shellscripts on the freerunner takes seconds of real time: http://www.mail-archive.com/pm-ut...@lists.freedesktop.org/msg01952.html It also implements a cancel resume exit code from hooks, that is currently used to resuspend right away if the phone ususpended just because you unplugged your USB cable. Normal pm-utils won't be able to support that anytime soon, but they agreed to standardise the exit code (see the whole thread linked earlier). The lack of quirks support is not as bad as it sounds, as you'd use pm-utils-light on embedded hardware where you generally have an intimate relationship with the hardware and are either in a position to fix the drivers getting rid of the quirks, or in a need to handle quirks with hardware-specific custom code. I'd say that the systems that need quirk support are more than fast enough to handle standard pm-utils without issues. I wouldn't suggest people to install pm-utils-light unless they really know what they are doing. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Bug#594099: ITP: pm-utils-light -- pm-utils replacement for embedded hardware
Package: wnpp Severity: wishlist Owner: Enrico Zini enr...@debian.org * Package name: pm-utils-light Version : 0.6 Upstream Author : Enrico Zini enr...@enricozini.org * URL : http://pkg-fso.nomeata.de/sid/pm-utils-light * License : GPL Programming Lang: C Description : pm-utils replacement for embedded hardware Pros: * It tries its best to run hooks in exactly the same way as pm-utils. * It's faster * It can load hooks from a .so file, which is much faster, avoids context switches and allows to keep state conveniently in memory. * .so files will be loaded also if they are not executable. Install a non-executable .so file to have it loaded by pm-utils light but ignored by pm-utils. * It allows to cancel a resume, for example in order to go back to sleep in case of a resume for usb disconnect. . Cons: * No support for quirks * It does not ship the functions and pm-functions shell libraries, so plugins cannot make use of them This is currently available in the pkg-fso repository. It gained a few users, and I've been asked to upload it to sid. Some more details in this announcement: http://lists.alioth.debian.org/pipermail/pkg-fso-maint/2009-November/002223.html Ciao, Enrico -- 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/20100823171210.20301.2926.report...@localhost
Bug#567954: RFH: debtags -- Enables support for package tags
Package: wnpp Severity: normal I request assistance with maintaining the debtags package. What I would like is a comaintainer who takes care of the everday packaging chores (for example, redoing the fetch script to fix #481634 and #478590, or fixing the manpage in #542525). I am looking for someone who already has packaging experience. The package description is: debtags provides a system to download a database of package tags and keep it up to date. A package tag is a small label that gets attached to a Debian package to represent one of its qualities. . A package tag database in the system can enable advanced package search techniques, and advanced package browsing functions in programs that support it. . This package has been made as a way to deploy and test package tags support until it gets integrated in the normal Debian workflow. Ciao, Enrico -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553065: ITP: cfget -- too to read values from config files
Package: wnpp Severity: wishlist Owner: Enrico Zini enr...@debian.org * Package name: cfget Version : 0.7 Upstream Author : Enrico enr...@enricozini.org * URL : http://www.enricozini.org/sw/cfget/ * License : GPL Programming Lang: Python Description : featureful tool to read values from config files cfget is a simple yet featureful tool to read values from configuration files. It is useful, for example, to create configurable shellscripts or makefiles. . Besides retrieving values, it can dump the information in several convenient ways, like a set of sh exports commands that can be conveniently passed to eval. It can also use the configuration values to expand template files. . It can also be configured to support virtual configuration values that, if not present in the config file, are automatically computed from the existing values. This makes it convenient, for example, to get a duration value from a configuration file that only contains a start date and an end date. . It is also easy to create plugins to provide custom templating systems, export styles, dynamic values and even custom configuration file parsers. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551864: ITP: xcowsay -- Graphical configurable talking cow
Package: wnpp Severity: wishlist Owner: Enrico Zini enr...@debian.org * Package name: xcowsay Version : 1.1 Upstream Author : Nick Gasson n...@nickg.me.uk * URL : http://www.doof.me.uk/xcowsay/ * License : GPL 3 or later Programming Lang: C Description : Graphical configurable talking cow A graphical configurable talking cow. It's a GTK+ version of the classic cowsay Perl script. It displays a cute pop-up cow on your desktop with a speech bubble and some customizable text. There's also a dream mode where the cow can display images. It comes with a fortune(6) wrapper script, xcowfortune, which you can cron to deliver periodic fortune cookies via the cow. It even has a daemon mode which lets you send the cow messages over DBus! -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548817: RFA: guessnet
Package: wnpp Severity: normal Hello, it's been more than a year that I have stopped using guessnet. On top of that, I almost never use wireless networking, and I am not normally in range of a wireless network. Nor I own an access point. This means that I cannot do a good job maintaning it: I don't normally use it on wired to spot obvious problems myself (like a recent issue with pcap, see #529882), and I have trouble testing its new wireless scanning code which is something a lot of people seem to use. Therefore, I would like someone else to take over maintaning it. I can help with the code, explaining it, reviewing and improving patches and so on, but the main maintainer needs to be someone who uses guessnet, who can try and reproduce bugs, and test new releases. So here's the RFA. Let's see if someone steps up. Ciao, Enrico -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523937: Any news with this ITP?
Hello, I would like to see mongoDB in Debian, and this ITP has already been open for a bit. Are there any news? Especially, is there a reason it has not been uploaded yet? Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Bug#523937: Any news with this ITP?
On Mon, Jul 27, 2009 at 10:24:55AM -0400, Kristina Chodorow wrote: There are a couple reasons... I need a sponsor (are you a Debian developer/know one?) and we'd like to update the database's SpiderMonkey interface to work with SpiderMonkey 1.8 before we release the package. We'd really like to see MongoDB in Debian, too! Feel free to help out if you know any Debian developers who might be interested or if you know about SpiderMonkey. Sure, I can upload for you. I don't know anything at all about SpiderMonkey, though, so I can't help on that side. As soon as you have a package that you're ready to upload, please feel free to get in touch. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Bug#536223: O: thescoder -- compiler for OpenOffice 1.x thesaurus files
Package: wnpp Severity: normal Hello, we do not have OpenOffice.org 1.x around the archive anymore, and I'm not aware of any other packages that build-depend on it. I guess it's time to orphan it. Ciao, Enrico -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536238: O: debtags-edit -- GUI browser and editor for Debian Package Tags
Package: wnpp Severity: normal Hello, I have fixed all serious or trivial bugs in debtags-edit and then orphaned it. The web editor is much better than debtags-edit in almost every respect, except it cannot be used offline; however, I myself do not use debtags-edit, and I do not enjoy maintaining it that much. GTK-- is not that fun to use (at least, for me); compiling takes ages, and I am not sure about a python rewrite because there are a few performance-critical bits in the code. Or maybe a python rewrite could be made that is based on apt-xapian-index for speed, but then changes in the tagging are not reflected in real time in the interface unless the index is rebuilt, or unless debtags-edit is run as root. Both of which are not ideal. Anyway, dealing with all of this would be so low in my TODO list that it's not reasonably going to happen in at least a couple of years, so it's sensible to orphan debtags-edit so that anyone interested in an GUI offline tagging interface can pick it up if they wish. Ciao, Enrico -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520955: [pkg-fso-maint] Bug#520955: ITP: xserver-xorg-video-glamo -- X.Org X server --, SMedia Glamo display driver
On Mon, May 04, 2009 at 04:37:48PM +0200, Luca Capello wrote: I named it 0.1.0 due to the fact that there are no tags yet in the upstream git repository. This is wrong, sorry, because it will conflict if upstream will release a 0.1.0 version. I would prefer something similar to the linux-2.6-openmoko package and indeed the Debian Git repository has an upstream tag, 20090302.git451398a2: [...] the Debian package version should be 20090503.gitb5eb5f79-1. How about 0~20090503.gitb5eb5f79-1, so it can go to 0.1 if upstream eventually decides to start making releases? Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini enr...@debian.org signature.asc Description: Digital signature
Bug#519184: Choosing the library version
Hello, I forgot to Cc this bug when I asked on -devel how to version the shared object, so I'm now adding a pointer to the thread. The discussion Packaging a library when upstream does not build a .so can be found at http://lists.debian.org/debian-devel/2009/03/msg00927.html Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini enr...@debian.org signature.asc Description: Digital signature
Bug#519184: ITP: gribapi -- GRIB decoding/encoding software library
Package: wnpp Severity: wishlist Owner: Enrico Zini enr...@debian.org * Package name: gribapi Version : 1.7.0 Upstream Author : Enrico Fucile enrico.fuc...@ecmwf.int * URL : http://www.ecmwf.int/products/data/software/grib_api.html * License : LGPLv3 Programming Lang: C Description : GRIB decoding/encoding software library The ECMWF GRIB API is an application program interface accessible from C and FORTRAN programs developed for encoding and decoding WMO FM-92 GRIB edition 1 and edition 2 messages. . ECMWF is the European Centre for Medium-Range Weather Forecasts. I have already done most of the packaging at: http://git.debian.org/?p=collab-maint/gribapi.git;a=summary I have one thing of which I am unsure: upstream does not yet build shared libraries, but the interface is rather stable and I patch the sources so that the Debian package does provide them. The issue is about the libtool versioning: at the moment I picked 0:0:0 so that anything upstream may choose in the future will likely be higher; however, are there better ways to address this? Other issues left to solve are nothing more than maybe writing a manpage or two with help2man. Ciao, Enrico -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505529: ITP: openmoocow -- Moo box simulator
Package: wnpp Severity: wishlist Owner: Enrico Zini [EMAIL PROTECTED] * Package name: openmoocow Version : 0.1.0 Upstream Author : Thomas White [EMAIL PROTECTED] * URL : http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/ * License : GPL v3 Programming Lang: C Description : Moo box simulator openmoocow simulates one of those little boxes that make a moo sound when turned upside down. . It works better on systems equipped with accelerometers, so that it can sense when it gets turned upside down. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465369: GoLearn
On Wed, Feb 13, 2008 at 05:46:36AM +0100, Jonas Smedegaard wrote: I suggest now a different approach that fulfills our needs without multiple applications: 4. Implement an --ftags option similar to that in ept-tags Done and committed: give it a try. For kicks, I also implemented --secondary=facet to choose the facet to use instead of 'interface'. Note: --ftags can be a comma-separated list of tags, that will be ANDed: this means that you can do this, which is probably what you want: goplay --go=field --ftags=use::learning, role::program I've just run that: the result is really nice! Your idea seems to nicely hit the spot. I believe it would then also make sense to either use a more generic facet than gaming by default or make the --facet option required, and rename the tool and the dependent games-thumbnails package. But that is just cosmetics. Note that goplay is written by the gnome game team, so not having gaming as a default would be a bit of a shame :) Also, if you require --facet, you can't just click and run the program, which takes half of the ease away. However, anyone's welcome to make a godebian program that shows like 6 big stilish icons one with every direction you'd like to go, and by clicking on an icon goplay is launched with the right options. The idea we discussed with Miriam, though, was something like to store a number of preset defaults inside the program, and choose them based on the program name. That way you can, for example, run it as 'golearn' and it will choose a different set of defaults. Turns out that this was rather easy to implement as well, so I did it. I took advantage of the opportunity for, in case of golearn, use as --ftags something like: use::learning (role::program || role::documentation). I've looked around at the available facets, and I implemented this list of possible alternate names, all of which are implemented: goadmin golearn gonet gooffice goplay gosafe goweb Please try it out: does it do what you want? btw, should we reassign this bug to goplay, for filing purpose? Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#465369: GoLearn
On Tue, Feb 12, 2008 at 04:56:14PM +0100, Miriam Ruiz wrote: I'm a bit concerned that if people start to fork the whole project for different kind of searches, it can get a bit out of hand. In fact, it might turn into a nightmare for the security team. If the idea is to have different GoSomething's available, maybe we could just take the common part into a shared library and a common base package, or maybe implement a tiny scripting thingie over GoPlay! to personalize it on different kind of stuff. Don't worry about not being able to code, I'm more concerned about the overall design of the program right now. Coding itself, once you have clear ideas about what you want to do, is quite straightforward. Wow, interesting. A few things come into my mind: 1. We take the Engine class, allow to configure another facet instead of game, and move it into libept. That allows others to build the interface they like on top of it, but this means that the interface code needs to be rewritten every time. 2. We change the Engine class to allow to configure another facet instead of game, and implement skins on top of goplay. The skin would customise the interface, and also specify the facet to use instead of 'game'. I don't know what this'd mean in terms of fltk interface code. 3. We implement goplay --learn, automatically enabled if argv[0] ends in 'learn', and we install both binaries. In the meantime, just because it was easy to do, I changed the engine to allow to customise the main facet used for navigation. I've also implemented a new commandline option, --go=facet, to try it out. I've committed the changes to svn at svn+ssh://svn.debian.org/svn/pkg-games/software/ui Get a list of facets using: grep Facet /var/lib/debtags/vocabulary Then decide where you want to go and run: goplay --go=facet For example: goplay --go=admin goplay --go=devel goplay --go=office goplay --go=security goplay --go=sound goplay --go=use goplay --go=web Of course one can install an extra tag source with tag data to go in any other direction. Oh, and by the way, THIS IS SO COOL! Ciao, Enrico ...Debian, where do you want to go tod--ehrm, never mind. -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#431715: RFA: gdome2
Package: wnpp Severity: normal Hello, I am not using this library anymore, and I start having many packages to maintain and little time. I'd be glad if someone else could take over maintenance. Actually, there's action needed on the package that I've neglected since quite a bit. Ciao, Enrico -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.21-1-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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#429514: ITP: openoffice.org-ctl-he -- Turns on OO.org CTL support, and sets Hebrew as the default CTL locale
On Mon, Jun 18, 2007 at 03:43:45PM +0100, Lior Kaplan wrote: Description : Turns on CTL support sets Hebrew as the default CTL locale This package installs an OO.org extention which turns on CTL support, and sets Hebrew as the default language. The user can overright these setting by changning them in the tools - options - language settings menu. It sounds like a useful package, but please add to the description an expansion of the CTL acronym. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#426874: ITP: pkg -- High-level library for managing Debian package information
On Tue, Jun 05, 2007 at 11:08:17AM +0200, Stefano Zacchiroli wrote: After some discussion in #debian-devel, I went for 'upt'. Wow ... cool ... a TLA! ... except that I've no idea what does it mean :-) But I guess I can wait to read the long description ... You're late: it's ept now :) http://lists.debian.org/debian-devel/2007/06/msg00103.html Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#426874: ITP: pkg -- High-level library for managing Debian package information
On Fri, Jun 01, 2007 at 03:34:22AM +0100, Ben Hutchings wrote: I'm about to port 'debtags-edit', after that I'll do the upload of libpkg-dev and libpkg0. This name seems overly generic to me. There are already libpkg libraries for the FreeBSD and RiscPkg (RISCOS) package managers, and Debian's library packaging guide is referred to as libpkg-guide. Uhm, no, pkginfo isn't appropriate because ideally one would also do install and uninstall, so it's not just about information. *sigh*, I hate finding names. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#426874: ITP: pkg -- High-level library for managing Debian package information
On Fri, Jun 01, 2007 at 11:41:45AM +0200, Stefano Zacchiroli wrote: Great to see this!, but I'm rather scared about its name: isn't pkg too generic? Wouldn't debpkg be a better (since more specific and describing) name? After some discussion in #debian-devel, I went for 'upt'. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#426874: ITP: pkg -- High-level library for managing Debian package information
On Fri, Jun 01, 2007 at 03:34:22AM +0100, Ben Hutchings wrote: I'm about to port 'debtags-edit', after that I'll do the upload of libpkg-dev and libpkg0. This name seems overly generic to me. There are already libpkg libraries for the FreeBSD and RiscPkg (RISCOS) package managers, and Debian's library packaging guide is referred to as libpkg-guide. Point. I'm now looking at libpkginfo: do you see any problems with that? Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#426874: ITP: pkg -- High-level library for managing Debian package information
Package: wnpp Severity: wishlist Owner: Enrico Zini [EMAIL PROTECTED] * Package name: pkg Version : 0.1 Upstream Author : Enrico Zini [EMAIL PROTECTED] * URL : hg clone http://hg.debian.org/hg/private/enrico/libpkg * License : LGPL Programming Lang: C++ Description : High-level library for managing Debian package information The library defines a very minimal framework in which many sources of data about Debian packages can be implemented and queried together. . The library includes two data sources: . * APT: access the APT database * Debtags: access the Debtags tag information libept is proving too hard to maintain and I've created a slicker replacement. I've ported the 'debtags' package to this new library with success. I'm about to port 'debtags-edit', after that I'll do the upload of libpkg-dev and libpkg0. This new library makes it very simple to add new data sources. I have plans laid out for a popcon data source, for example, and more could come. It should also be straightforward to swig-bind it to the usual plethora of scripting languages. If anyone is interested in a debconf BoF about it, do let me know. Ciao, Enrico -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.21-1-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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#389773: ITP: cnf -- library for C and Fortran mixed programming
Package: wnpp Severity: wishlist Owner: Enrico Zini [EMAIL PROTECTED] * Package name: cnf Version : 4.0 Upstream Author : Various from Council for the Central Laboratory of the Research Councils (CCLRC) and stated at the beginning of every source file. * URL : http://www.starlink.ac.uk/cgi-store/ftpform1?cnf * License : GPL version 2 (see http://www.starlink.rl.ac.uk/store/conditions.html) Programming Lang: C Description : library for C and Fortran mixed programming The CNF package comprises two sets of software which ease the task of writing portable programs in a mixture of FORTRAN and C. F77 is a set of C macros for handling the FORTRAN/C subroutine linkage in a portable way, and CNF is a set of functions to handle the difference between FORTRAN and C character strings, logical values and pointers to dynamically allocated memory. The original distribution features an own packaging system, which was good when it was made, but now it's a bit tricky to work with. To make it easy package CNF for Debian and Fedora, I skipped part of the original packaging and created a new makefile which wraps the old one providing a more usual behaviour. The package can be inspected at http://people.debian.org/~enrico/2006-09/cnf/ and I intend to proceed with the upload during the week-end. Ciao, Enrico -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389776: ITP: dballe -- Database for punctual meteorological data
Package: wnpp Severity: wishlist Owner: Enrico Zini [EMAIL PROTECTED] * Package name: dballe Version : 2.5 Upstream Author : Enrico Zini [EMAIL PROTECTED] for ARPA SIM * URL : http://www.smr.arpa.emr.it/software/DBalle.html * License : GPL Programming Lang: C Description : Database for punctual meteorological data DB-All.e is a fast on-disk database where meteorological observed and forecast data can be stored, searched, retrieved and updated. This framework allows to manage large amounts of data using its simple Application Program Interface, and provides tools to visualise, import and export in the standard formats BUFR, AOF and CREX. These are the main characteristics of DB-ALL.e: * Fortran, C, C++ and Python APIs are provided. * To make computation easier, data is stored as physical quantities, that is, as measures of a variable in a specific point of space and time, rather than as a sequence of report. * Internal representation is similar to BUFR and CREX WMO standard (table code driven) and utility for import and export are included (generic and ECMWF template). * Representation is in 7 dimensions: latitude and longitude geographic coordinates, table driven vertical coordinate, reference time, table driven observation and forecast specification, table driven data type. * It allows to store extra information linked to the data, such as confidence intervals for quality control. * It allows to store extra information linked to the stations. * Variables can be represented as real, integer and characters, with appropriate precision for the type of measured value. * It is based on physical principles, that is, the data it contains are defined in terms of homogeneous and consistent physical data. For example, it is impossible for two incompatible values to exist in the same point in space and time. * It can manage fixed stations and moving stations such as airplanes or ships. * It can manage both observational and forecast data. * It can manage data along all three dimensions in space, such as data from soundings and airplanes. * Report information is preserved. It can work based on physical parameters or on report types. Ciao, Enrico -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389773: ITP: cnf -- library for C and Fortran mixed programming
On Wed, Sep 27, 2006 at 06:09:03PM +0200, Enrico Zini wrote: The original distribution features an own packaging system, which was good when it was made, but now it's a bit tricky to work with. To make it easy package CNF for Debian and Fedora, I skipped part of the original packaging and created a new makefile which wraps the old one providing a more usual behaviour. I now reread this mail [1] from Nick Barkas and realised that some autotools packaging effort was started. However, browsing at the website I get the impression that those are nightly builds from CVS, and the stable versions are still packaged with the old system. And, still as I understand it, the project was terminated before the autotools-based code was released, and that work has been frozen as a nightly build. I can now do one of three things: 1) go on with my package, which has the stable version with a somehow fixed build system; 2) backport their autotools-based build system to the stable version; 3) package the CVS nightly build. At the moment my preferred option would be to go with my package, for two reasons: 1. because it's already done and ready to be uploaded and I'm lazy :) and 2. because it's a way to package the stable version with as little changes as possible. Someone with more insight on starlink's situation can still easily change my mind, though :) Ciao, Enrico [1] http://lists.debian.org/debian-science/2006/02/msg00020.html [2] http://dev.starlink.ac.uk/build/DEBIAN-3.0r3_i386/dist/ -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#387612: RFP: python-debtags -- Access Debtags information from python
[Hi Dato!] On Fri, Sep 15, 2006 at 03:15:05PM +0100, James Westby wrote: I have a basic package at http://jameswestby.net/scratch/python-debtags_0.1-1.dsc I am willing to finish the package off if you do not want to take it from here, but only if you add a license and copyright information. There are also a few other things that would be good, but I'll leave that for now. Let me know if you want me to continue, Thanks a lot, I've imported your changes in the debtags svn repo and added the missing license information. Now I'm wondering how to proceed: there are two options: one is I give you access to the svn repo on Alioth and you continue with the packaging. The other is that we merge Debtags.py into the work of the pkg-python-debian project. I've noticed from the list archives that you're involved there, too. I've Cc-ed Adeodato to ask if he would like this work to be part of pkg-python-debian. Besides sorting out the place where this module belongs, I'd really like you to continue: that'd be of great help to me. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#387612: RFP: python-debtags -- Access Debtags information from python
Package: wnpp Severity: wishlist * Package name: python-debtags Version : 0.1 Upstream Author : Enrico Zini [EMAIL PROTECTED] * URL : http://svn.debian.org/wsvn/debtags/python * License : LGPL Programming Lang: Python Description : Access Debtags information from python Python module to access Debtags information. The package also provide some tools and a wxpython-based prototype for a Debian package smart search interface. I'm looking for someone to package svn://svn.debian.org/debtags/python for me: it's simple enough python stuff (one Debian.py and a few runnable scripts, but they use set() and so they require at least python 2.4), but I don't want to learn the python policy just for it. Thanks, Enrico -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387612: RFP: python-debtags -- Access Debtags information from python
On Fri, Sep 15, 2006 at 02:53:46PM +0200, Josselin Mouette wrote: 2.4), but I don't want to learn the python policy just for it. You don't have to learn the python policy. Your fear is only the result of stupid people trying to make python packaging look too complex. The truth is, it is *not* complex. I don't care how complex the python policy is: I just don't want to learn it just for this package. I prefer to spend my time doing upstream development. If you instead want to talk about stupid people involved in the recent python policy changes, you better don't. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#381599: Bug#387612: RFP: python-debtags -- Access Debtags information from python
On Fri, Sep 15, 2006 at 03:36:48PM +0200, Stefano Zacchiroli wrote: On Fri, Sep 15, 2006 at 01:43:30PM +0200, Enrico Zini wrote: Python module to access Debtags information. I think you should merge this package (maybe not the wxwindow GUI, but still ...) with the efforts of the pkg-python-debian project (ML on Alioth Cc-ed and ITP bug report Cc-ed). Part of the effort is developing python libraries to access Debian information about packages and stuff. It seems to me the right place for python-debtags as well. Oh, yes! I'd love to. I didn't know of pkg-python-debian. Hi guys, I have a module for you :) Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#368275: ITP: overgod -- bi-directional scrolling arcade game
On Sat, May 20, 2006 at 11:06:06PM -0500, Sam Hocevar (Debian packages) wrote: * Package name: overgod Version : 1.0 Upstream Author : Linley Henzell [EMAIL PROTECTED] * URL : https://sourceforge.net/projects/overgod/ * License : GPL Programming Lang: C Description : bi-directional scrolling arcade game Hi! When I've seen the game at Debconf it was cool... when will I get to play it? :) Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#262927: Debian Bug report logs - #262927
On Tue, Mar 07, 2006 at 02:04:21PM +0100, Wolfgang Lonien wrote: However, if you pick that up to get you started with Debian maintainance, consider finding yourself some friend DD to help you along. I could do that, but then since the original problem was dealing with the workload, it wouldn't make much sense. Hmmm ok. Any volunteers around here who could help me to help Enrico with debtags-edit and/or tagcolledit? I'm still reading and learning lots of stuff, so as Enrico said, I'm a newbie... Best way is usually to ask a fellow DD who's a friend of yours. Hopefully, since we've met at FOSDEM, I won't turn out to be the only one :) Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#351069: ITP: knetworkmanager -- system tray applet for controlling NetworkManager
On Thu, Feb 02, 2006 at 04:31:35PM +0100, Michael Biebl wrote: KNetworkManager is a system tray applet for controlling network connections on systems that use the NetworkManager daemon. Do we have the NetworkManager daemon in Debian yet? I did apt-cache search network manager and apt-cache search networkmanager but could not find it. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#351069: ITP: knetworkmanager -- system tray applet for controlling NetworkManager
On Sun, Feb 05, 2006 at 04:59:14PM +0100, Michael Biebl wrote: Enrico Zini wrote: Do we have the NetworkManager daemon in Debian yet? No, not yet. But I'm working together with the maintainer of NM and you will see packages of NM as soon as 0.6 is released. There is a project repo at [1] already, but this is for 0.5.1 only. 0.6 of NM (and the corresponding version of knetworkmanager) will be released soon. So stay tuned. Oh, good. I can't wait to see it, and possibly find a way to plug guessnet into it. Thanks! Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#335185: ITP: newmat -- manipulate matrices using standard operations
On Sun, Oct 23, 2005 at 11:14:06AM +0200, Willi Mann wrote: * License : Custom license (looks like public domain to me) I think this is wrong. The readme file states: This library is freeware and may be freely used and distributed. This fails DFSG, paragraph 3. I think the readme is just unclear. In http://www.robertnz.net/nm10.htm#use I read: There are no restrictions on the use of newmat except that I take no liability for any problems that may arise from this use. I welcome its distribution as part of low cost CD-ROM collections. You can use it in your commercial projects. However, if you distribute the source, please make it clear which parts are mine and that they are available essentially for free over the Internet. So it appears that the author is happy about modifications and redistribution, and probably has it in his own interpretation of freeware. Maybe he can be talked into removing the ambiguity and formalizing it in a clearer existing license? Looks like he's wanting a BSD one. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#321654: New packages uploaded to experimental
Hello, after a big code frenzy with Peter Mornfall Rockai I've uploaded to experimental a new version of the entire debtags chain, plus the new addition *libapt-front*! libapt-front brings together libapt and libdebtags into a base library for package managers. It is very well done, nice to use, sane interface, incredibly stable given its very young age. During the work, I discovered I was doing a very silly use of overloaded virtual methods and that triggered a heavy refactoring of tagcoll and debtags as well. Benjamin, I'd be happy to assist you in porting packagesearch over. Notes worth mentioning: Tagcoll::Tagcoll* became Tagcoll::* TagSet - OpSetTag FacetSet - OpSetFacet All the functions related to Debtags::Package have now gone. libapt-front should be used instead, with the added feature that it doesn't crash like the old Debtags::Package code used to do. I repeat, I'd be happy to assist. The good news is that the new interface tends to make so, so, so much sense! Now both debtags and debtags-edit use libapt-front. Unfortunately I had to split libdebtags1 and debtags again to avoid a circular dependency. That's unfortunate both for the time we spent with the merge and because now again I have one extra package to maintain. However, it was the only option. We really need some extra debian maintainers for Debtags. All of this is in experimental only. I'm planning to upload everything to unstable as soon as: 1) bug #321799 has been closed. This prevents libapt-front from building unless one patches its /usr/include/apt-pkg/policy.h with the trivial patch I posted in the BTS 2) packagesearch is ported and uploading to unstable I don't break it. Expect big news from this new libapt-front! Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#321654: RFA: debtags: Enables support for package tags -- optional
On Wed, Aug 17, 2005 at 05:13:54PM +0200, Simon Richter wrote: I think I can do that; while the amount of free time I have is certainly limited, triggering a recompile is certainly doable, and I also have access to a lot of obscure architectures. Oh, nice! Would you prefer comaintainership? Can start to do team maintenance and leave the RFA open. What version tracking do you use? Subversion, at: svn+ssh://svn.debian.org/svn/debtags/debtags Activity on debtags is pretty quiet these days, as I'm mainly working on libapt-front and debtags-edit. You may take advantage of this to give a look around and fix what you think is broken. Some notes about the package: - libraries are intended to be static-only, as the ABI is not stabilised yet. This is why no shared library is built. - however, the package generates language bindings, which need to be shared objects, which need to be compiled with -fPIC. That's the reason of the double compile run, and that's the reason of the -pic library package. Note: I'd like to find a better way (that is, handled automatically by libtool) to do this. - the devel library install the headers in /usr/include/debtags-1.0/debtags, so that headers for multiple versions of the devel library can coexist - to ease the work of developers using the library, pkg-config and automake files are provided and installed by the -dev package. There is also doxygen-generated documentation. - debtags's postinst rationale: - if it's being run for the first time, copy the database and vocabulary files shipped with the package into the location where apt's downloader expects to find the previously downloaded files. - debtags update is run. If we're offline, apt will fallback to the previously downloaded files, possibly the ones shipped with the package if we're offline on the first update run. Some notes about the bugs: #246678: mkbrowser script shows warnings, invoke debtags with bad syntax and segfault mkbrowser hasn't been in my target for a while. It needs to be rewritten, or dropped. The existance of debtags-based GUIs are making it less useful, although no GUI still exist that experiments with the smart hierarchy algorithm like mkbrowser does. #304832: doesn't support arch-specific packages This needs to be fixed in the central database. This bug is left open on debtags because there's no package for the central database. #320791: confused on amd64 I still haven't managed to work on this. #144046: general: Sections are not finely grained Old, historical bug. I intend to close it pretty soon. Namely, once me and aj have done some more rounds of tag updates on the Packages file and I see that the procedure is working. #277626: debtags: should support running as non-root user I'm keeping this bug open because there are some ideas in my comment to it. #290457: debtags: add a non-free/crontrib group of tags? We still haven't given this thinking on debtags-devel. I/we should brobably bring it up for discussion one day the list is dead. #322954: debtags: Implement --dry-run functionality The patches for the manpage mentioned in the log are already in subversion. Thanks! Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#321654: RFA: debtags: Enables support for package tags -- optional
Package: wnpp Severity: normal Hello, I've recently been making a new debtags version at least once a day: either some chunk of the gcc migration, or yet another APT ABI change, or who knows what's going to happen tomorrow. I'm tired, and I haven't been writing any line of code for it anymore since I can't remember how much time. I want someone to do the Debian maintenance for it; someone who knows what he or she is doing, and who can do uploads by him/herself. I want to be upstream for debtags, to do 'make dist' and to have someone that picks it up from there. Debtags is not a trivial package: it should be someone comfortable with automake/autoconf and with packaging C++ libraries. Since the goal is to save my time to do coding, this time I'll have to turn down offers from people who need sponsoring, or people who lack experience. Ciao, Enrico -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#272264: Tomboy
On Thu, Feb 24, 2005 at 06:06:16PM +, Ben Hill wrote: I know Alex wasn't too enthused about the actual icon, but he's happy for it to change. I'll change it, and upload the packages. There seems to be at least 3 people interested in maintaining this: Ben, Guido and Eric. I suggest to create a tomboy project on Alioth, and then comaintain with it. svn-buildpackage is a really nice tool I suggest to look into for the task. If you need help with Alioth, I can show you how to setup svn commit notification e-mails and an upload queue for a separate repository. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#295258: RFP: festvox-itsomething -- Italian voice for Festival
Package: wnpp Severity: wishlist * Package name: festvox-itsomething Version : unknown Upstream Author : ISTC-SPFD CNR [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] * URL : http://www.csrf.pd.cnr.it/TTS/It-FESTIVAL-license.htm * License : GPL (Finally!!) Description : Italian voice for Festival This is a major event in the Italian Free Software world: after years of waiting, the authors finally released the Italian voice for Festival under the GPL! We can now, in Italy as well, think about building things that speak. I'd like someone to package this in Debian; I'd like to see this in Sarge, even. However I'm clueless about packaging festival voices. I can't even make up a name for the package. I'm happy to offer to comaintain it, though. Ciao, Enrico P.S. I NEED to plug polygen unieuro into it! -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686-smp Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#272264: How are things going?
Hello! I'd love to see tomboy packaged in Debian! Is there some work going on? Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#283994: ITP: glastree -- builds live backup trees, with branches for each day
On Fri, Dec 03, 2004 at 01:49:44PM +1100, Matthew Palmer wrote: The advantage of using glastree over pdumpfs is that it is implemented in Perl rather than Ruby (this is in fact the reason that I encountered it in the first place). How is that an advantage of use? One may want to use tools written in a language they know, so that if something breaks, it may be easier to fix it. I, for one, do this kind of reasoning, and don't feel much comfortable in running things written in languages I don't know (yet). Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#271804: ITP: polygen -- Generate random sentences according to a grammar definition
On Thu, Sep 16, 2004 at 03:00:02PM +0200, Filippo Giunchedi wrote: I've already filed this ITP some time ago but closed it since I'm not interested anymore in polygen (who gave me hours of laughs, though). Here are my preliminary packages (polygen and polygen-data) but I can remember there was some problem with the compiled grammars (easy to fix bug anyhow) perhaps you can find them useful! http://giunched.web.cs.unibo.it/debian/polygen_1.0pre-2.dsc http://giunched.web.cs.unibo.it/debian/polygen_1.0pre-2.tar.gz I already create a package for polygen, but I'll have a look at yours too to see if there are things I can improve. Also, I still haven't packaged the grammars, so I'll probably take that from you. Please let me know if you're interested in comaintaining. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#271804: ITP: polygen -- Generate random sentences according to a grammar definition
Package: wnpp Severity: wishlist * Package name: polygen Version : 1.0.6 Upstream Author : Alvise Spanò [EMAIL PROTECTED] * URL : http://www.example.org/ * License : GPL Description : Generate random sentences according to a grammar definition PolyGen is a program for generating random sentences according to a grammar definition, that is following custom syntactical and lexical rules. Formally, it is an interpreter of a language itself designed to define languages, where to interpret means executing a source program in real time and eventually outputting its result. Here a source program is a grammar definition, the execution consists in the exploration of such grammar by selecting a random path and the result is the sentence built on the way. Though PolyGen is quite a seriuos piece of software then, what else would be more noble for it than being used as a parody tool for linguistical habits, stereotypes and trends of this foolish era? Principles of parody are focusing a ridiculous topic and eventually abstracting its rules and schemes (here in terms of a grammar definition) by which reproducing it through the variatio device. And randomization is perfect at this purpose thanks to its purely asemantic behaviour =:) Please see: http://polygen.org/web/Home.444.0.html Ciao, Enrico -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686-smp Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Bug#262706: Status of log2mail got back to orphaned
Hello, It seems that we have had a failed adoption attempt. I'm resetting log2mail to orphaned status and hoping for better luck in the future. Frederik and Giskard, you're welcome to try again any time you feel like you can be a bit more involved. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#262706: Are you still interested?
Hello, Having received no replies to my inquiries from you for more than a week, I had to upload a fixed log2mail package myself, in order to at least have a fixed version for sarge. If in two days I won't see any message convincing me that you're still and really interested in maintaining the package, I'll retitle this bug in O: log2mail again. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#262927: RFH: Debtags - Evolution of package metadata
Package: wnpp Severity: normal X-debbugs-cc: debian-devel@lists.debian.org, [EMAIL PROTECTED] The size of Debian increases, and the Sections: system has proven unable to scale to keep pace with it. There has been much consensus around a multiple tags per package solution: the Debian Package Tags system is a working implementation. Debtags is one of the most interesting prospective expansions of the Debian package metadata, it contains promosing prototypes and has received very good feedback so far. The problem is, there are only three people actively working on it: Erich Schubert takes care of the central tag archive at http://debian.vitavonni.de/packagebrowser/ and part of the tag vocabulary. Thaddeus H. Black takes care of debram, which is another independent effort to improve package metadata and is intended to eventually merge into debtags. Enrico Zini (me) takes care of all the implementation and Debian packaging of the system components, and the other part of the tag vocabulary. I find myself responsible for too many things, and as the system evolves I can't keep up with it. Currently, it already consists of 6 source packages: libtagcoll Functions for handling collections of tagged items. tagcoll Commandline wrapper around libtagcoll, and generic manipulation tool for tagged collections. tagcolledit GUI interface for mass-editing of tagged collections. libdebtags Function for handling the Debian package metadata, extended with tag informations debtags Commandline wrapper around libdebtags, and administration tool for the Debian Package Tags debtags-edit GUI interface for searching packages and updating their categorization This is their dependency interrelationship: libtagcoll tagcoll Depends on libtagcoll tagcolledit Depends on libtagcoll libdebtags Depends on libtagcoll debtagsDepends on libdebtags debtags-edit Depends on libdebtags To keep up with the expansion and evolution of the project, we need more people. The main, extremely sought help is to have someone taking care of the Debian packaging, so that I can focus on being a productive upstream: I'm a better software designer/developer than Debian maintainer, and I'm spending too much time in figuring out how to setup library versions that I could better spend in implementing some long-awaited feature. Other job openings could be: - Creating library bindings to languages different than C++ - Gtk-- developers to help on the GUI tools - C++ developers writing test cases - People taking care of part of the the facet/tag structure, providing new know-how for categorizing things we don't know much about, writing descriptions, reorganizing the taxonomy - People using debtags and its libraries in their applications, or making sample applications that make use of the libraries - C++ and i18n/l10n experts to help in taking things away from the C locale - People taking care of the web space of the project Please consider joining the team: working on the Debian Package Tags is extremely interesting, rewarding and overall a big lot of fun! Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#262706: O: log2mail
Package: wnpp Severity: normal log2mail is a daemon watching logfiles and mailing lines matching patterns. It server a purpose similar to logcheck but does it in realtime, so it can be used as a nice way to implement alerts: programs log things, and you can get a mail (or a sms via a mail-to-sms gateway) as soon as bad things are spotted. It's been a very useful tool for me in my past job, and I took over maintenance from the previous maintainer. log2mail has been quite a critical application for us there. More than a year ago I quit that job, and I'm not using log2mail anymore. The package is in a pretty good shape and does not usually need much care: I did around one upload per year, and I just made one upload fixing all bugs, bringing the whole build system up to date and in line with the last standards-version, porting to cdbs. At the time I took over the package, upstream was happy to hand also upstream maintenance to me. The code is simple, linear and quite well written. At that time, upstream told me if I couldn't maintain log2mail anymore, he would take it back. Time has passed from there, and I sent him a mail asking him what he intends to do. I'm orphaning the package not because it's a burden, but because my other Debian activities are occupying most of my time already and I feel I can't commit to being a good maintainer for it anymore. Ciao, Enrico -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686-smp Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Bug#262706: O: log2mail
On Sun, Aug 01, 2004 at 07:10:35PM +0200, Frederik Schueler wrote: I would like to adopt log2mail. Thanks! log2mail is a nice and useful tool, and I was sorry for leaving it alone. You can retitle in ITA at any time, and please contact me for any problems you might have. In the meantime, I discovered that the previous upstream has changed e-mail address. I sent a mail to the previous DD asking if he still has a path to him, which he should have. [EMAIL PROTECTED] may be interested in helping with the maintenance: he should jump in the discussion anytime soon, if he hasn't done it already. Ciao, Enrico
Bug#170677: ITP: launchtool -- Run a command supervising its execution
Package: wnpp Version: unavailable; reported 2002-11-25 Severity: wishlist * Package name: launchtool Version : 0.6 Upstream Author : Enrico Zini [EMAIL PROTECTED] * URL : http://people.debian.org/~enrico/launchtool.html * License : GPL Description : Run a command supervising its execution Run a user-supplied command supervising its execution in many ways, such as controlling its environment, blocking signals, logging its output, changing user and group permissions, limiting resource usage, restarting it if it fails, running it continuously, turning it into a daemon and more. Bye, Enrico
Bug#118996: ITP: guessnet -- Guess what network is connected
On Sat, Nov 10, 2001 at 08:21:57AM -0800, Sean 'Shaleh' Perry wrote: * Package name: guessnet Version : 0.9 Upstream Author : Enrico Zini [EMAIL PROTECTED] * URL : http://www.students.cs.unibo.it/~zinie/en/guessnet * License : GPL Description : Guess what network is connected to an ethernet device (can be used as a script for ifupdown) Based on the network detecting code of laptop-netconf, guessnet tries to guess what network an ethernet device is currently connected to, using fake ARP requests. It has been written to be coupled with the debian ifupdown package to achieve automatic network detection and configuration, but it can be used stand-alone to implement smart network scripts. You realize we already have THREE (maybe four) different packages which do this in Debian right now. Of course I do, but this is the only one that integrates with the existing Debian network configuration. You have a way in /etc/network/interfaces to specify different configurations for a network interface, and to use an external command to choose the right one. Then you have THREE (maybe four) packages with a wonderful network detection routine, but NONE OF THEM can be used as that external command. For this reason, having a laptop and wanting to stay as close to the debian way as possible, I've just insulated their detection code and put it in a simple and small command that does the job, following the Unix tradition of doing things. Given guessnet, you could reimplement all the other similar packages with simple shell scripts (it could be an interesting idea for an examples directory, now that I think about it), but it would be a mess to use the other packages to provide a shell script that does for ifupdown what guessnet does. Bye, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED]
Bug#118996: ITP: guessnet -- Guess what network is connected to an ethernet device (can be used as a script for ifupdown)
Package: wnpp Version: N/A; reported 2001-11-10 Severity: wishlist * Package name: guessnet Version : 0.9 Upstream Author : Enrico Zini [EMAIL PROTECTED] * URL : http://www.students.cs.unibo.it/~zinie/en/guessnet * License : GPL Description : Guess what network is connected to an ethernet device (can be used as a script for ifupdown) Based on the network detecting code of laptop-netconf, guessnet tries to guess what network an ethernet device is currently connected to, using fake ARP requests. It has been written to be coupled with the debian ifupdown package to achieve automatic network detection and configuration, but it can be used stand-alone to implement smart network scripts. Bye, Enrico -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux marvin 2.4.14 #1 SMP Tue Nov 6 18:19:03 CET 2001 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
