Bug#590045: ITP: ant-contrib-cpptasks -- C/C++ compilation tasks for Ant.
Package: wnpp Severity: wishlist Owner: Christopher Baines * Package name: ant-contrib-cpptasks Version : 1.0~b5 Upstream Author : Unknown * URL : http://ant-contrib.sourceforge.net/cpptasks/index.html * License : Apache (v2.0) Programming Lang: Java Description : C/C++ compilation tasks for Ant. The cc task can compile various source languages and produce executables, shared libraries (aka DLL's) and static libraries. Compiler adaptors are currently available for C/C++, FORTRAN, MIDL and Windows Resource compilers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100723090529.2967.62328.report...@chris-debian-desktop
Bug#590049: ITP: lejos-nxj -- LeJOS NXJ is a replacement firmware and java api for the Lego Mindstorms NXT and RCX robotics platforms.
Package: wnpp Severity: wishlist Owner: Christopher Baines * Package name: lejos-nxj Version : 0.8.5 Upstream Author : Many * URL : http://lejos.sourceforge.net/ * License : MPL (v1.0) Programming Lang: Java Description : LeJOS NXJ is a replacement firmware and java api for the Lego Mindstorms NXT and RCX robotics platforms. It contains a VM for Java bytecodes and additional software to load and run Java programs. These are some of the features offered: - Object oriented language (Java) - Preemptive threads (tasks) - Arrays, including multi-dimensional ones - Recursion - Synchronization - Exceptions - Java types including float, double, long and String - Math class - Well-documented Robotics API -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100723094038.3863.18215.report...@chris-debian-desktop
Bug#590182: ITP: fgrun -- FGRun is a graphical frontend for running FlightGear
Package: wnpp Severity: wishlist Owner: Christopher Baines * Package name: fgrun Version : 1.5.2 Upstream Author : Frederic Bouvier (Project admin) * URL : http://fgrun.sourceforge.net/ * License : GPL Programming Lang: C++ Description : FGRun is a graphical frontend for running FlightGear FlightGear Launch Control (FGRun) is a graphical frontend for running the FlightGear Flight Simulator. It allows you to select a airport and aircraft, and includes advanced options like launching from an aircraft carrier or, changing the screen resoluton. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100724160026.3261.7295.report...@chris-debian-desktop
Bug#593554: ITP: fgo -- A simple GUI launcher for FlightGear
Package: wnpp Severity: wishlist Owner: Christopher Baines * Package name: fgo Version : 1.3.0 Upstream Author : Robert Leda * URL : http://sites.google.com/site/erobosprojects/flightgear/add-ons/fgo * License : GPL Programming Lang: Python Description : simple GUI launcher for FlightGear FGo! is a small program allowing you to launch FlightGear from a GUI (Graphical User Interface). It allows you to select an airport to fly from, an aircraft to use, scenarios you want to enable, if you want to enable terrasync and shows you a picture of the aircraft you have chosen. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100819082614.5065.6367.report...@chris-debian-desktop
Bug#602830: ITP: bluecove -- Java library for Bluetooth (JSR-82 implementation)
Package: wnpp Severity: wishlist Owner: Christopher Baines Package name: bluecove Version : 2.1.0 Upstream Author : Many URL : http://bluecove.org/ License : LGPL Programming Lang: Java Description : Java library for Bluetooth (JSR-82 implementation) BlueCove is a JSR-82 (Java Micro Edition specfication for bluetooth) implementation on J2SE (Java 2 Standard Edition) that currently interfaces with the Mac OS X, WIDCOMM, BlueSoleil and Microsoft Bluetooth stack. Originally developed by Intel Research and currently maintained by volunteers. Support for Linux BlueZ is added in BlueCove version 2.0.3 as additional GNU General Public License module bluecove-gpl. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101108161128.5687.33479.report...@chris-desktop
Bug#602834: ITP: bluecove-gpl -- BlueCove-gpl is additional module for BlueCove to support bluecove on Linux.
Package: wnpp Severity: wishlist Owner: Christopher Baines Package name: bluecove-gpl Version : 2.1.0 Upstream Author : Mina Shokry and Vlad Skarzhevskyy URL : http://bluecove.org/ License : GPL Programming Lang: Java and C Description : BlueCove-gpl is additional module for BlueCove to support bluecove on Linux. BlueCove is a JSR-82 (Java Micro Edition specfication for bluetooth) implementation on J2SE (Java 2 Standard Edition) that currently interfaces with the Mac OS X, WIDCOMM, BlueSoleil and Microsoft Bluetooth stack. Originally developed by Intel Research and currently maintained by volunteers. Support for Linux BlueZ is added in BlueCove version 2.0.3 as additional GNU General Public License module bluecove-gpl. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101108165309.28939.65540.report...@chris-desktop
Bug#609495: ITP: gridwars2 -- simple arcade style 2D shooter
Package: wnpp Severity: wishlist Owner: Christopher Baines * Package name: gridwars2 Version : 9.3.2006-1 Upstream Author : Marco Incitti * URL : http://gridwars.marune.de/ * License : None Programming Lang: No Source Code Provided Description : simple arcade style 2D shooter GridWars 2 is the second release of a clone of the Geometry Wars game. You play as a ship on a two dimensional plane, where you fire at other geometrical shapes, of various behaviour and colour. It gets exponentially harder as you play. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110109222106.9400.8599.report...@chris-desktop
Bug#702161: ITP: ruby-dbf -- small fast Ruby library for reading database files
Package: wnpp Severity: wishlist Owner: Christopher Baines * Package name: ruby-dbf Version : 2.0.3 Upstream Author : Keith Morrison * URL : http://github.com/infused/dbf * License : Expat Programming Lang: Ruby Description : small fast Ruby library for reading database files -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130303104546.5568.6892.report...@chris-desktop.home
Bug#702165: ITP: ruby-georuby -- Ruby data holder for OGC Simple Features
Package: wnpp Severity: wishlist Owner: Christopher Baines * Package name: ruby-georuby Version : 2.0.0-1 Upstream Author : Guilhem Vellut * URL : http://georuby.rubyforge.org/ * License : Expat Programming Lang: Ruby Description : Ruby data holder for OGC Simple Features -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130303114313.16112.26199.report...@chris-desktop.home
How Debian Deals with Data
Hello All, I currently have two packages in the archive, one small ant related package (ant-contrib-cpptasks) and a FlightGear related package (fgrun). But its the FlightGear packaging I want to talk about. For those of you that have yet to enjoy playing with FlightGear, its a very flexible and powerful flight simulator. As a program, its not that big, but it has lots of data. The real world scenery FlightGear uses is massive ~10GB (I think), this can either be fetched in archives, or by svn (using a program called terrasync). Then there is also the aircraft, numbering in there hundreds (~3GB). Now as far as I know, this amount of data cannot be included in the Debian archives? While there may be perfectly reasonable practical reasons why this cant happen, it is probably inconvenient for those that can install a tiny portion of the scenery and a few of the aircraft through the package system, but then have to struggle fetching the rest by some other less convenient method. Now I was thinking about this, and came up with a few ideas, I will explain probably the best one. If any of you use flash, you might use the flashplugin-nonfree package, now because cant be included in the Debian archives, this package actually downloads the adobe installer and then runs it. Now while this is of cause not a perfect situation. It did get me thinking, what about doing this for the FlightGear data? So, imagine. The user wants to install a portion of the scenery, so they use whatever package manager and install the relevant package. Now behind the scenes, the package has picked out a default fetch method (probably terrasync), and then fetched the data to the correct directory (could ever find the best mirror). Now what about a different user that wants the data in archive form, they could use a debconf interface to select the correct fetch method. Now imagine that a user has the scenery on dvd (as the project sells to raise funds for charity), the package could check for this, and if possible install from there. The actual package would just contain the rules and checksums for the files it tries to fetch, but not the data itself, I think of this as a symbolic package. This approach in my opinion, would make packaging applications like FlightGear much easier, and improve the user experience. Any thoughts, or have I found a non-existent problem? Thanks, Chris signature.asc Description: This is a digitally signed message part
Re: How Debian Deals with Data
On Sat, 2011-07-16 at 01:31 +0200, Arno Töll wrote: > Hi Christopher, > > On 16.07.2011 00:20, Christopher Baines wrote: > > The actual package would just contain the rules and checksums for the > > files it tries to fetch, but not the data itself, I think of this as a > > symbolic package. This approach in my opinion, would make packaging > > applications like FlightGear much easier, and improve the user > > experience. > > just as a random alternative idea (where other people may judge whether > it is a good idea or not): There might still be benefits of letting dpkg > handle the installation stuff, even if you don't want to have such a > large amount of data in the archives. > > This eases maintenance, updates and clean removal of packages. For your > purpose it might be worth to consider a half baked solution. For example > you could provide a meta package [*] which builds a new binary package > on the installation site. Without knowing anything about FlightGear this > potentially seems a good solution to me. Your meta package could > download your stuff, apply some checksumming and then produce a new > binary package with the actual game data. > > Take a look into the google-earth package for an example what I'm > thinking about. Their use case is of course different than yours, but > the idea is the same. > > This binary package may ease installation, transportation and copying of > your game's data. By using some nifty dependencies along with > "Provides"/"Replaces" relationships you could even do some interesting > dependency magic there, although the direct usage of "dpkg" makes it a > bit tricky to benefit from it. > > [*] please don't confuse my usage of "meta package" with its > archive-wide meaning for Debian here. I would consider the best solution to be a mixture of the two, so the symbolic package handles fetching the data, but then tells dpkg what files its putting where. I definitely think that it would be useful to be able to take a symbolic package, and turn it in to a normal package, but if you don’t want the package, just the stuff on your system, there should just be a way skip out the package (this is mainly for space, because if someone has just enough room for the actual installation, you don’t want to waste space giving them a package as well. Chris signature.asc Description: This is a digitally signed message part
Re: How Debian Deals with Data
On Fri, 2011-07-15 at 22:32 +, The Fungi wrote: > On Fri, Jul 15, 2011 at 11:20:09PM +0100, Christopher Baines wrote: > [...] > > Any thoughts, or have I found a non-existent problem? > > A very-existent problem (the scientific package maintainers deal > with this at least as much as the games package maintainers from > what I gather). It's come up a lot over the years, but the most > recent productive thread I remember was this one about a > data.debian.org archive proposal for extremely large, > architecture-independent data packages: > >http://lists.debian.org/debian-devel/2010/09/msg00692.html > > I'm not sure what became of that, but I'm curious to find out since > I'll be staring down the barrel of a similar problem soon enough. A specific package repository for data packages would help the situation, but its not very flexible? Most of this data is already available on the internet, why not allow the user to either fetch it from there, or from other installation media they might have? Chris signature.asc Description: This is a digitally signed message part
Re: "register" files in dpkg database programmatically? (was Re: How Debian Deals with Data)
On Sat, 2011-07-16 at 17:12 +0200, Paul Wise wrote: > On Sat, Jul 16, 2011 at 4:48 PM, Peter Samuelson wrote: > > > It would be useful in any number of situations to be able > > to "register" a file with dpkg: tell dpkg that a given package owns a > > given file, so that it is automatically removed when the package is > > removed or upgraded. I can see this being used in many postinst > > scripts, so as to simplify or eliminate the corresponding postrm. > > I have wanted this for a long time and would use it in > clamav-unofficial-sigs if it were available. I'd want both registering > and unregistering, since clamav-unofficial-sigs might need to remove > some files. It would be used at both runtime and in maintainer > scripts. So a control file would do for this, I think packages should only be able to register/unregister files from there own package, packages they Replace, or files that are do not belong to any package. Otherwise this feature could be abused. Chris signature.asc Description: This is a digitally signed message part
Re: "register" files in dpkg database programmatically? (was Re: How Debian Deals with Data)
On Mon, 2011-07-18 at 14:19 +0200, Paul Wise wrote:
> On Sun, Jul 17, 2011 at 1:04 AM, Peter Samuelson wrote:
>
> > - Treat the file as though it were shipped in the package directly.
> > This means it is removed on package upgrade, as well as on package
> > removal. This is very straightforward (append the filename to
> > /var/lib/dpkg/info/{foo}.list), but perhaps not too useful.
>
> Do you have a use-case for this? I guess such files would need to be
> re-created on package upgrade and I'm not sure how useful this is.
This could be used for the original suggestion of fetching data and
placing it on the system, if the data came in any format that allowed
updates of existing data, then the other way would be used (data
persistent when upgraded). This functionality would be very useful for
the above use case.
Chris
signature.asc
Description: This is a digitally signed message part
Bug#780203: general: Cannot have more than 2 desktops
Just for completeness, here is how you would get 8 workspaces (desktops) in Gnome. Firstly, and the easiest way, is to have at least 7 windows open, one per workspace. An 8th workspace will be automatically available, and will be empty. If you wish to have a static number of workspaces, change the setting in the Tweak Tool [1]. On the left hand side of the window, select the Workspaces button. Then change workspace creation to static. Input the number of workspaces in to the box below. 1: If you cannot find it, you may need to install it, the package name is gnome-tweak-tool (sudo apt-get install gnome-tweak-tool) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54ff583d.4090...@cbaines.net
Bug#805816: ITP: sklearn-pandas -- Pandas integration with sklearn
Package: wnpp Severity: wishlist Owner: Christopher Baines * Package name: sklearn-pandas Version : 0.0.12 Upstream Author : Israel Saeta Pérez * URL : https://github.com/paulgb/sklearn-pandas * License : Zlib Programming Lang: Python Description : Pandas integration with sklearn sklearn-pandas provides a bridge between scikit-learn's machine learning methods and pandas data frames. In particular, it provides: - a way to map DataFrame columns to transformations, which are later recombined into features - a way to cross-validate a pipeline that takes a pandas DataFrame as input. My plan is to maintain this within the Debian Python Modules Team.
Bug#808818: ITP: python-prometheus-client -- Python client for the Prometheus monitoring system
Package: wnpp Severity: wishlist Owner: Christopher Baines * Package name: python-prometheus-client Version : 0.0.13 Upstream Author : Brian Brazil * URL : https://github.com/prometheus/client_python * License : Apache-2.0 Programming Lang: Python Description : Python client for the Prometheus monitoring system This library provides an API for exporting metrics from a Python application. It provides classes for the metric types, and a http server to expose the metrics to Prometheus. When using Linux, the process CPU, RAM, file descriptor usage and start time will also be exported. Along with the http server to expose metrics, you can also write the metrics to a text file to be exported by the prometheus-node-exporter, or push them to the prometheus-pushgateway. This library also includes support for re-exporting Graphite metrics to Prometheus, custom collectors to proxy metrics for other systems and a parser for the Prometheus text format. My plan is to maintain this as part of the Python Modules team, although I am not currently a member.
Bug#814045: ITP: fake-factory -- Faker is a Python library that generates fake data
Package: wnpp Severity: wishlist Owner: Christopher Baines * Package name: fake-factory Version : 0.5.3 Upstream Author : Daniele Faraglia * URL : http://github.com/joke2k/faker * License : Expat Programming Lang: Python Description : Faker is a Python library that generates fake data The fake data can be used to bootstrap a database, create XML documents, or anonymize data taken from a production service. This is a dependency of python-factory-boy, which I intend to work on getting back in to Debian. I intend to maintain this as part of the Python Modules Team.
Bug#814823: ITP: prometheus-pgbouncer-exporter -- Export metrics from pgbouncer to Prometheus
Package: wnpp Severity: wishlist Owner: Christopher Baines * Package name: prometheus-pgbouncer-exporter Version : 1.3 Upstream Author : Christopher Baines * URL : http://git.cbaines.net/prometheus-pgbouncer-exporter/ * License : AGPL-3+ Programming Lang: Python Description : Export metrics from pgbouncer to Prometheus This is a simple exporter for PgBouncer that makes several metrics available to Prometheus. Metrics are exported from the SHOW LISTS, STATS, POOLS and DATABASES command output. For the full list, see the prometheus_pgbouncer_exporter/collectors.py file. Not sure quite how to handle this package, as I am the upstream author as well.
Re: Bug#814823: ITP: prometheus-pgbouncer-exporter -- Export metrics from pgbouncer to Prometheus
On 16/02/16 17:45, Martín Ferrari wrote: > Hi Christopher, > > On 15/02/16 17:40, Christopher Baines wrote: > >> Not sure quite how to handle this package, as I am the upstream author as >> well. > > Ideally, keep the debian packaging separate from the upstream > development. I'd recommend creating a repository on alioth (maybe in > collab-maint?) where you can add your main repo as a remote, but only > push debian-related commits to the alioth remote. I am still not quite sure where I stand on this, currently I have all the stuff related to getting the package in to a proper state for inclusion in to Debian in a separate branch (which changes the source format to quilt, adds a watch file and updates the changelog). Keeping a fully working package in master has the benefit of allowing me (as the upstream developer) to use all the useful Debian tooling (e.g. autopkgtest). > I am the maintainer for a few prometheus packages, so if you need help > or sponsored uploads, feel free to reach to me (I am also Tincho in > oftc/freenode) Thank you so much for packaging Proemtheus! Your work on it enabled me to use it, and I use it literally every day :) Which has led on to writing exporters to make it even more useful. I am looking for a sponsor for the prometheus-pgbouncer-exporter package, you can find the package on the Debian mentors site [1], or in the debian branch of this Git repository [2]. 1: https://mentors.debian.net/package/prometheus-pgbouncer-exporter 2: http://git.cbaines.net/prometheus-pgbouncer-exporter/
Bug#816147: ITP: django-prometheus -- Django middlewares to enable monitoring with Prometheus
Package: wnpp Severity: wishlist Owner: Christopher Baines * Package name: django-prometheus Version : 1.0.6 Upstream Author : Uriel Corfa * URL : https://github.com/korfuri/django-prometheus * License : Apache Programming Lang: Python Description : Django middlewares to enable monitoring with Prometheus The django-prometheus library provides integrations to monitor database interaction, usage of models, and HTTP requests. Any custom metrics are also handled directly by the Python Prometheus client library. This library just facilitates gathering and exporting the data. A separate service (or set of services) must be used to gather, store and process this data. I plan to maintain this as part of the Debian Python Modules Team.
