Bug#760544: ITP: fyba -- FYBA library to read and write norwegian geodata standard format SOSI
Package: wnpp Severity: wishlist Owner: ruben.undh...@gmail.com * Package name: fyba Version : 4.1.1 Upstream Author : Statens Kartverk * URL : https://github.com/kartverket/fyba * License : MIT Programming Lang: C++ Description : FYBA library to read and write norwegian geodata standard format SOSI OpenFYBA is the source code release of the FYBA library, distributed by the National Mapping Authority of Norway (Statens kartverk) to read and write files in the National geodata standard format SOSI. -- 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/20140905053739.11052.73601.reportbug@miniserver.granittvegen
Bug#760597: ITP: sosi2osm -- SOSI to OSM converter
Package: wnpp Severity: wishlist Owner: ruben.undh...@gmail.com * Package name: sosi2osm Version : 1.0.0 Upstream Author : Knut Karevoll * URL : https://github.com/Gnonthgol/sosi2osm * License : GPL-2.0+ Programming Lang: C++ Description : SOSI to OSM converter . This little utility converts .sosi files into .osm files which are used by OpenStreetMap. It relies on the FYBA library released by the Norwegian Mapping Authority (Statens kartverk). -- 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/20140905180955.3238.83339.reportbug@miniserver.granittvegen
Bug#760629: ITP: qrouter -- Multi-level, over-the-cell maze router
Package: wnpp Severity: wishlist Owner: ruben.undh...@gmail.com * Package name: qrouter Version : 1.1.55 Upstream Author : Tim Edwards * URL : http://opencircuitdesign.com/qrouter/ * License : GPL-2 Programming Lang: C Description : Multi-level, over-the-cell maze router Qrouter is a tool to generate metal layers and vias to physically connect together a netlist in a VLSI fabrication technology. It is a maze router, otherwise known as an "over-the-cell" router or "sea-of-gates" router. That is, unlike a channel router, it begins with a description of placed standard cells, usually packed together at minimum spacing, and places metal routes over the standard cells. . Qrouter uses the open standard LEF and DEF formats as file input and output. It takes the cell definitions from a LEF file, and analyzes the geometry for each cell to determine contact points and route obstructions. It then reads the cell placement, pin placement, and netlist from a DEF file, performs the detailed route, and writes an annotated DEF file as output. -- 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/20140906082539.8398.97462.reportbug@miniserver.granittvegen
Bug#761364: ITP: abc -- A System for Sequential Synthesis and Verification
Package: wnpp Severity: wishlist Owner: ruben.undh...@gmail.com * Package name: abc Version : 1.01-20140822hg4d547a5e065b Upstream Author : Berkeley Logic Synthesis and Verification Group * URL : http://www.eecs.berkeley.edu/~alanmi/abc/ * License : MIT-similar (The Regents of the University of California) Programming Lang: C Description : A System for Sequential Synthesis and Verification ABC is a growing software system for synthesis and verification of binary sequential logic circuits appearing in synchronous hardware designs. ABC combines scalable logic optimization based on And-Inverter Graphs (AIGs), optimal-delay DAG-based technology mapping for look-up tables and standard cells, and innovative algorithms for sequential synthesis and verification. Please provide feedback on the naming of the package! Perhaps the name "abc" is a bad name to use in debian although it's the correct upstream name. -- 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/20140913093848.19326.25574.reportbug@miniserver.granittvegen
Bug#761365: ITP: yosys -- A framework for Verilog RTL synthesis
Package: wnpp Severity: wishlist Owner: ruben.undh...@gmail.com * Package name: yosys Version : 0.3.0+20140904git01ef34c Upstream Author : Clifford Wolf * URL : http://www.clifford.at/yosys/ * License : ISC License Programming Lang: C++ Description : A framework for Verilog RTL synthesis Yosys is a framework for Verilog RTL synthesis. It currently has extensive Verilog-2005 support and provides a basic set of synthesis algorithms for various application domains. Yosys can be adapted to perform any synthesis job by combining the existing passes (algorithms) using synthesis scripts and adding additional passes as needed by extending the yosys C++ code base. Yosys is free software licensed under the ISC license (a GPL compatible license that is similar in terms to the MIT license or the 2-clause BSD license). -- 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/20140913094516.21087.56435.reportbug@miniserver.granittvegen
Bug#761368: ITP: qflow -- An Open-Source Digital Synthesis Flow
Package: wnpp Severity: wishlist Owner: ruben.undh...@gmail.com * Package name: qflow Version : 1.0.85 Upstream Author : Tim Edwards * URL : http://opencircuitdesign.com/qflow/ * License : GPL Programming Lang: C, Tcl, sh Description : A Digital Synthesis Flow using Open Source EDA Tools Qflow is a complete tool chain for synthesizing digital circuits starting from verilog source and ending in physical layout for a specific target fabrication process. In the world of commercial electronics, digital synthesis with a target application of a chip design is usually bundled into large EDA software systems. As commercial electronics designers need to maintain cutting-edge performance, these commercial toolchains get more and more expensive, and have largely priced themselves out of all but the established integrated circuit manufacturers. This leaves an unfortunate gap where startup companies and small businesses cannot afford to do any sort of integrated circuit design. -- 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/2014091312.22360.41098.reportbug@miniserver.granittvegen
Bug#761369: ITP: timberwolf -- Placement for digital VLSI design
Package: wnpp Severity: wishlist Owner: ruben.undh...@gmail.com * Package name: timberwolf Version : 6.3.5 Upstream Author : Yale University * URL : http://opencircuitdesign.com/magic/archive/ (folder for upstream tar-ball - no known web-page) * License : Yale University license (similar to BSD) Programming Lang: C Description : Placement for digital VLSI design A placement tool known as TimberWolf was developed at Yale University, and was distributed as open source for a time until it was taken commercial. The last open-source version of this tool does not perform detail routing, but is a professional-grade placement tool. This is a Linux port of the last open source version. It is part of the qflow digital VLSI design flow. -- 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/20140913102603.25312.38602.reportbug@miniserver.granittvegen
Bug#768169: ITP: sfarklib -- Library for decompressing sfArk soundfonts
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: sfarklib Version : 0.20131219gitee08d0c Upstream Author : Andy Inman * URL : http://melodymachine.com/sfark-linux-mac * License : GPL-3 Programming Lang: C++ Description : Library for decompressing sfArk soundfonts sfArk is a lossless audio compression format optimized for SoundFont files. This library can decompress such files into .sf SoundFont files. I intend to maintain it as part of the Debian Science team. -- 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/20141105164354.12096.21351.report...@miniserver.beebeetle.com
Bug#768173: ITP: sfarkxtc -- Converts soundfonts in the legacy sfArk v2 file format to sf2
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: sfarkxtc Version : 0.20130812git80b1da3 Upstream Author : Andy Inman * URL : http://melodymachine.com/sfark-linux-mac * License : GPL-3 Programming Lang: C++ Description : Converts soundfonts in the legacy sfArk v2 file format to sf2 This is a very small command line tool to convert legacy sfArk files into the SoundFont 2 format. It uses the library sfarklib. I intend to maintain it as part of the Debian Science team. -- 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/20141105164756.12162.60711.report...@miniserver.beebeetle.com
Bug#744790: ITP: gnuais - Automatic Identification System Receiver
Package: wnpp Severity: wishlist Owner: ruben.undh...@gmail.com * Package name: gnuais Version : 0.3.0 Upstream Author : Ruben Undheim http://gnuais.sourceforge.net * License : GPL-2.0+ Programming Lang: C Description : A tool for demodulating and decoding AIS messages using the line input of the sound card. gnuais is a tool for demodulating and decoding AIS messages using the line input of the sound card. AIS messages are transmitted by marine vessels and contain their position, velocity and other interesting information. The messages may be saved to an mysql-database, forwarded as NMEA packets or uploaded to an AIS web service. There is also a GUI distributed as a separate package which is capable of displaying the vessels in an openstreetmaps GUI using the libosmgpsmap2 library. -- 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/20140414192130.17228.23742.reportbug@miniserver.granittvegen
Bug#771708: ITP: mrtdreader -- Machine-readable travel document library and example program
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: mrtdreader Version : 0.1.0 Upstream Author : Ruben Undheim * URL : https://github.com/rubund/mrtdreader * License : GPL-3+ Programming Lang: C Description : Machine-readable travel document library and example program This package contains the library libmrtd and the command line tool mrtdreader. Machine-readable travel documents such as passports nowadays usually contain an RFID chip for storing various data. This library provides useful functions for reading out the data from these documents. This version of the library supports the Basic Access Control (BAC). It uses several cryptographic functions from either libgcrypt or libtomcrypt (depending on compile-time options - for debian currently libgcrypt) in order to do the necessary decryption of the content of the MRTDs. The key for the BAC-scheme is derived from the Machine-readable zone (MRZ) which is printed on the MRTD. The library depends on libnfc for the hardware interaction and only devices supported by libnfc will therefore work. I think such a library is a useful addition to the debian package repository. It is a good example for using the libnfc library on which there are still rather few packages that depend. -- 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/20141201200252.2223.87389.report...@miniserver.beebeetle.com
Bug#772509: ITP: ubertooth -- Open source wireless development platform suitable for Bluetooth experimentation
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: ubertooth Version : 201404R1-1 Upstream Author : Mike Ossmann * URL : http://ubertooth.sourceforge.net/ * License : GPL-2+ Programming Lang: C Description : Open source wireless development platform suitable for Bluetooth experimentation Project Ubertooth is an open source wireless development platform suitable for Bluetooth experimentation. Ubertooth ships with a capable BLE (Bluetooth Smart) sniffer and can sniff some data from Basic Rate (BR) Bluetooth Classic connections. -- 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/20141207232019.9328.57881.report...@miniserver.beebeetle.com
Bug#772575: ITP: libbtbb -- Libbtbb is the Bluetooth baseband library used by the Ubertooth and gr-bluetooth projects
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: libbtbb Version : 20141208 Upstream Author : Dominic Spill * URL : http://libbtbb.sourceforge.net/ * License : GPL-2+ Programming Lang: C Description : Bluetooth baseband library used by the Ubertooth and gr-bluetooth projects This is the Bluetooth baseband decoding library, forked from the GR-Bluetooth project. It can be used to extract Bluetooth packet and piconet information from Ubertooth devices as well as GR-Bluetooth/USRP. The main motivation for packaging this for debian is that it is a dependency for ubertooth. -- 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/20141208175013.13282.82840.report...@miniserver.beebeetle.com
Bug#775764: ITP: pyvisa-py -- A PyVISA backend implemented in pure Python
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: pyvisa-py Version : 0.1~20150106gitd86fb71 Upstream Author : Hernan E. Grecco * URL : https://github.com/hgrecco/pyvisa-py * License : MIT Programming Lang: Python Description : A PyVISA backend implemented in pure Python PyVISA started as wrapper for the NI-VISA library and therefore you need to install National Instruments VISA library in your system. This works most of the time, for most people. But NI-VISA is a proprietary library that only works on certain systems. That is when PyVISA-py jumps in. Starting form version 1.6, PyVISA allows to use different backends. These backends can be dynamically loaded. PyVISA-py is one of such backends. It implements most of the methods for Message Based communication (Serial/USB/GPIB/Ethernet) using Python and some well developed, easy to deploy and cross platform libraries This package is useful in Debian since it replaces a huge proprietary library needed in many instrumentation facilities. I plan to maintain it as part of the Python Modules team. -- 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/20150119182052.31251.63497.report...@miniserver.beebeetle.com
Bug#777303: ITP: osmotrx -- A software-defined radio transceiver that implements the Layer 1 physical layer of a BTS
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: osmotrx Version : 0~20150119git722d4f7 Upstream Author : Thomas Tsou * URL : http://openbsc.osmocom.org/trac/wiki/OsmoTRX * License : AGPL Programming Lang: C++ Description : A software-defined radio transceiver that implements the Layer 1 physical layer of a GSM BTS OsmoTRX is a software-defined radio transceiver that implements the Layer 1 physical layer of a BTS comprising the following 3GPP specifications: TS 05.01 "Physical layer on the radio path" TS 05.02 "Multiplexing and Multiple Access on the Radio Path" TS 05.04 "Modulation" TS 05.10 "Radio subsystem synchronization" OsmoTRX is a dependency for the open source base station by osmocom. -- 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/20150207113355.20942.29833.report...@miniserver.beebeetle.com
Bug#784026: ITP: python-spur -- Run commands and manipulate files locally or over SSH using the same interface
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: python-spur Version : 0.3.13 Upstream Author : Michael Williamson * URL : https://github.com/mwilliamson/spur.py * License : BSD 2-clause Programming Lang: Python Description : Run commands and manipulate files locally or over SSH using the same interface This Python module makes it simple to remotely run commands over an SSH connection. -- 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/20150502104356.14549.13645.report...@miniserver.beebeetle.com
Bug#786729: ITP: python-zeroconf -- Pure Python Multicast DNS Service Discovery Library (Bonjour/Avahi compatible)
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: python-zeroconf Version : 0.17.1 Upstream Author : Jakub Stasiak * URL : https://github.com/jstasiak/python-zeroconf * License : LGPL Programming Lang: Python Description : Pure Python Multicast DNS Service Discovery Library (Bonjour/Avahi compatible) This is an implementation of the multicast DNS Service Discover Library zeroconf in pure Python. It is a dependency of pychromecast which I also intend to package. Compared to some other Zeroconf/Bonjour/Avahi Python packages, python-zeroconf: - isn't tied to Bonjour or Avahi - doesn't use D-Bus - doesn't force you to use particular event loop or Twisted (- is pip-installable) (- has PyPI distribution) I plan to maintain the package as part of the Python Modules team. -- 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/20150524235543.21835.42564.report...@miniserver.beebeetle.com
Bug#786730: ITP: python-pychromecast -- Python library for communicating with Google Chromecast
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: python-pychromecast Version : 0.6 Upstream Author : Paulus Schoutsen * URL : https://github.com/balloob/pychromecast * License : MIT Programming Lang: Python Description : Python library for communicating with Google Chromecast This library makes it easy to communicate with a Chromecast device using Python. It currently supports: - Auto discovering connected Chromecasts on the network - Start the default media receiver and play any online media - Control playback of current playing media - Implement Google Chromecast api v2 - Communicate with apps via channels - Easily extendable to add support for unsupported namespaces -- 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/20150524235953.22083.71855.report...@miniserver.beebeetle.com
Bug#916949: ITP: netatmo-api-python -- Simple API to access Netatmo weather station data from any python script
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: netatmo-api-python Version : 1.3 Upstream Author : jabesq (Github) - forked version * URL : https://github.com/jabesq/netatmo-api-python * License : MIT Programming Lang: Python Description : Simple API to access Netatmo weather station data from any python script This makes it easy to interact with Netatmo weather station data from Python scripts. It is a dependency for home-assistant for interfacing with the weather station.
Bug#916950: ITP: python3-netdisco -- Library to discover local devices and services
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: python3-netdisco Version : 2.2.0 Upstream Author : (home-assistant) * URL : https://github.com/home-assistant/netdisco * License : Apache 2.0 Programming Lang: Python3 Description : Library to discover local devices and services NetDisco is a Python 3 library to discover local devices and services. It allows to scan on demand or offer a service that will scan the network in the background in a set interval. Current methods of scanning: - mDNS (includes Chromecast, Homekit) - uPnP - Plex Media Server using Good Day Mate protocol - Logitech Media Server discovery protocol - Daikin discovery protocol - Web OS discovery protocol It is the library that powers the device discovery within Home Assistant.
Bug#916951: ITP: python3-phue -- Python library for Philips Hue
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: python3-phue Version : 0.9 Upstream Author : Nathanaël Lécaudé (studioimaginaire) * URL : https://github.com/studioimaginaire/phue * License : MIT Programming Lang: Python Description : Python library for Philips Hue Full featured Python library to control the Philips Hue lighting system. Features: - Compliant with the Philips Hue API 1.0 - Support for Lights - Support for Groups - Support for Schedules - Support for Scenes - Support for Sensors - Compatible with Python 2.6.x and upwards - Compatible with Python 3 - No dependencies - Simple structure, single phue.py file - Work in a procedural way or object oriented way
Bug#916955: ITP: python-voluptuous-serialize -- Code for converting Python voluptuous schemas to Python dictionaries
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: python-voluptuous-serialize Version : 2.0.0 Upstream Author : Paulus Schoutsen * URL : https://github.com/balloob/voluptuous-serialize * License : Apache-2.0 Programming Lang: Python Description : Code for converting Python voluptuous schemas to Python dictionaries Convert Voluptuous schemas to dictionaries so they can be serialized. This is a core dependency for home-assistant. I plan to maintain it in the python modules team
Bug#916956: ITP: python3-enocean -- Python library for controlling and reading from EnOcean devices
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: python3-enocean Version : 0.41.0 Upstream Author : Kimmo Huoman (github user 'kipe') * URL : https://github.com/kipe/enocean * License : MIT Programming Lang: Python Description : Python library for controlling and reading from EnOcean devices This is a Python library for controlling and reading from EnOcean devices EnOcean is a radio control protocol in the 868 MHz band using many energy harvesting devices. I plan to maintain it in the python modules team.
Bug#917037: ITP: python3-zeroconf -- Pure Python implementation of multicast DNS service discovery (Python3)
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: python3-zeroconf Version : 0.21.3 Upstream Author : Jakub Stasiak * URL : https://github.com/jstasiak/python-zeroconf * License : LGPL-2.1+ Programming Lang: Python-3 Description : Pure Python implementation of multicast DNS service discovery (Python3) python-zeroconf already exists in the Debian archive. However, upstream has dropped support for Python 2, and there are reverse dependencies in Debian which depend on the Python 2 package. This makes it necessary with a separate source package for the Python 3 version. See https://tracker.debian.org/pkg/python-zeroconf for more infor about python-zeroconf.
Bug#917040: ITP: python-ifaddr -- Pure Python implementation for detecting IP addresses
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: python-ifaddr Version : 0.1.6 Upstream Author : Stefan C. Mueller * URL : https://pypi.org/project/ifaddr/ * License : MIT Programming Lang: Python Description : Pure Python implementation for detecting IP addresses ifaddr is a small Python library that allows you to find all the IP addresses of the computer. The library python-netifaces provides similar functionality but is harder to install since it has C-components which must be built. python-ifaddr is required in Debian since the newer versions of python-zeroconf depends on it. It will be maintained in the Python modules team.
Bug#917076: ITP: python-envs -- Easy access of environment variables from Python
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: python-envs Version : 1.2.6 Upstream Author : Brian Jinwright * URL : https://pypi.org/project/envs/ * License : Apache-2.0 Programming Lang: Python Description : Easy access of environment variables from Python You can use python-envs if you need environment variables for your settings but need an easy way of using Python objects instead of just strings. For example, if you need a list of strings. Features: - CLI to convert settings - CLI to list and check environment variables - Use strings, lists, tuples, integers, floats or dicts. IMPORTANT: When setting the variables in your environmenet (ex. in .env file) wrap them in single or double quotes (ex. "['some','list']") It is a dependency for home-assistant. I plan to maintain it in the Python modules team.
Bug#917077: ITP: python-user-agents -- Detect phone/tablet etc. from user agent string with Python
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: python-user-agents Version : 1.1.0 Upstream Author : Selwin Ong * URL : https://pypi.org/project/user-agents/1.1.0/ * License : Expat Programming Lang: Python Description : Detect phone/tablet etc. from user agent string with Python This is a Python library that provides an easy way to identify/detect devices like mobile phones, tablets and their capabilities by parsing (browser/HTTP) user agent strings. The goal is to reliably detect whether: - User agent is a mobile, tablet or PC based device - User agent has touch capabilities (has touch screen) It relies on the excellent ua-parser to do the actual parsing of the raw user agent string. I plan to maintain it in the Python modules team.
Bug#917079: ITP: python-aiohue -- Async Python library to control Philips Hue
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: python-aiohue Version : 1.7.0 Upstream Author : Paulus Schoutsen and "home-assistant" * URL : https://github.com/balloob/aiohue * License : Apache-2.0 Programming Lang: Python Description : Async Python library to control Philips Hue Full featured Python library to control the Philips Hue lighting system implemented using Python asyncio via aiohttp. It provides more or less the same functionality as python-phue (https://bugs.debian.org/916951), but it is implemented using asyncio. It is a dependency for home-assistant if home-assistant should be able to control Philips Hue devices. I plan to maintain it in the Python modules team.
Bug#926099: ITP: opensta -- Gate-level Static Timing Analyzer
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: opensta Version : 0.0 - GIT HEAD Upstream Author : Parallax Software, Inc. * URL : https://github.com/abk-openroad/OpenSTA * License : GPL-3+ Programming Lang: C++ Description : Gate-level Static Timing Analyzer After synthesis, place and route of a digital circuit, it is necessary to verify the timing of the design. OpenSTA is a tool for doing exactly that. It has a TCL interface for entering commands for analysing designs. It typically takes as input a verilog netlist, a liberty file, and other parasitics information from the placed and routed design. There is one similar, but more basic, tool called 'vesta' inside the qflow package already in Debian, but OpenSTA is a more complete solution. I plan to maintain it in the Debian Electronics team.
Bug#926100: ITP: klayout -- High Performance Layout Viewer and Editor
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: klayout Version : 0.25.8 Upstream Author : Matthias Köfferlein * URL : https://www.klayout.de/ * License : GPL-3+ Programming Lang: C++ Description : High Performance Layout Viewer and Editor This is very good viewer for GDSII and other layout files used in the semiconductor industry. It is similar to 'magic', but has a much more modern GUI and is more robust handling all kinds of GDSII files created by various other tools. Its focus is more on viewing than on editing, but it also has limited, but expanding, support for DRC and extraction for LVS. I plan to maintain it in the Debian Electronics team.
Bug#972325: ITP: scikit-rf -- Python toolkit for RF/Microwave engineering
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: scikit-rf Version : 0.15.4 Upstream Author : scikit-rf development team (Alex Arsenovic, ..) * URL : http://scikit-rf.org/ * License : BSD-3-clause Programming Lang: Python Description : Python toolkit for RF/Microwave engineering It provides a modern, object-oriented library for network analysis (VNA) and calibration which is both flexible and scalable. The toolkit is superb for analyzing S parameter files (touchstone) from vector network analyzers. Plotting of Smith charts is easy with this library. I plan to maintain it in the Debian Electronics team.
Why is 'yosys' still marked for autoremoval?
Hi, Can anyone tell me why 'yosys' is marked for autoremoval from testing because of a bug which has already been fixed? See here: https://tracker.debian.org/pkg/yosys The bug #835678 was fixed in (and is marked as such) in 0.6-7 which is currently in testing. Have I been able to hit some kind of buggy corner case in the packaging infrastructure or am I missing something? Best regards, Ruben
Bug#905950: ITP: python-gdsii -- Library to handle GDSII files
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: python-gdsii Version : 0.2.1 Upstream Author : Eugeniy Meshcheryakov * URL : https://pythonhosted.org/python-gdsii/ * License : LGPL-3+ Programming Lang: Python Description : Library to handle GDSII files python-gdsii is a library that can be used to read, create, modify and save GDSII files. It supports both low-level record I/O and high level interface to GDSII libraries (databases), structures, and elements. I plan to maintain it in the Debian Python Modules team.
Bug#905952: ITP: netgen-lvs -- Netlist comparison - Layout vs Schematic (LVS)
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: netgen-lvs Version : 1.5.105 Upstream Author : Tim Edwards * URL : http://opencircuitdesign.com/netgen/ * License : GPL Programming Lang: C Description : Netlist comparison - Layout vs Schematic (LVS) Netgen is a tool for comparing netlists, a process known as LVS, which stands for "Layout vs. Schematic". This is an important step in the integrated circuit design flow, ensuring that the geometry that has been laid out matches the expected circuit. Very small circuits can bypass this step by confirming circuit operation through extraction and simulation. Very large digital circuits are usually generated by tools from high-level descriptions, using compilers that ensure the correct layout geometry. The greatest need for LVS is in large analog or mixed-signal circuits that cannot be simulated in reasonable time. Even for small circuits, LVS can be done much faster than simulation, and provides feedback that makes it easier to find an error than does a simulation. The source package name "netgen" is reserved by another package, so reserving "netgen-lvs" for this program. I plan to maintain it in the Debian Electronics team.
Bug#906024: ITP: libgdsii -- C++ library for working with GDSII binary data files
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: libgdsii Version : GIT HEAD Upstream Author : M. T. Homer Reid * URL : https://github.com/HomerReid/libGDSII * License : GPL-3+ Programming Lang: C++ Description : C++ library for working with GDSII binary data files libGDSII is a C++ library for working with GDSII binary data files, intended primarily for use with the computational electromagnetism codes scuff-em and meep but sufficiently general-purpose to allow other uses as well. It is a recommended dependency for the newest version of meep. The plan is to maintain it in the Electronics team.
Bug#906983: ITP: gr-dab -- Gnuradio blocks and tools for receiving DAB and DAB+ radio
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: gr-dab Version : 0.1? (to be released) Upstream Author : Andreas Müller, Moritz Luca Schmid etc. * URL : https://github.com/andrmuel/gr-dab * License : GPL-3+ Programming Lang: C++, Python Description : Gnuradio blocks and tools for receiving DAB and DAB+ radio gr-dab contains necessary DSP blocks for receiving DAB and DAB+ transmissions using a software defined radio such as hackrf, rtl-sdr, USRP etc. Currently, I plan to maintain it myself, but it may also fit in the Hamradio Maintainers Team with other GNU radio packages.
Bug#907240: ITP: nextpnr -- Portable FPGA place and route tool
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: nextpnr Version : GIT HEAD Upstream Author : YosysHQ * URL : https://github.com/YosysHQ/nextpnr * License : ISC Programming Lang: C++ Description : Portable FPGA place and route tool This is a place and route tool with GUI for FPGAs. It is closely related to fpga-icestorm and provides similiar functionality as arachne-pnr, but intended to be more general. Upstream is quite active with a number of developers, and it is possible that it may more or less "replace" arachne-pnr in the future. I intend to maintain it in the Debian Electronics team.
New package netgen-lvs with binary /usr/bin/netgen - already taken
Hi, I am planning to upload the package "netgen-lvs" soon (upstream name is "netgen"). (https://bugs.debian.org/905952) The Debian package "netgen" is something entirely different.. (https://tracker.debian.org/pkg/netgen) But both of them have the binary "/usr/bin/netgen". My question is, what is the recommended way forward in this case. I have seen what was earlier done for "nodejs", and I see this as a similar case. Since "netgen" may be referred to from scripts, it would be nice to have a compatibility layer which adds a /usr/bin/netgen executable also for "netgen-lvs". That would then go into a separate package which conflicts with "netgen". What should in that case be the name of this package? The other extreme is of course to just let "netgen-lvs" completely conflict with "netgen". But that is not very nice to people who happen to be interested in both ASIC development and 3D tetrahedral mesh generators.. What is the recommendation? Any links to previous discussions / documents about this subject? Thanks in advance! Best regards, Ruben
Re: New package netgen-lvs with binary /usr/bin/netgen - already taken
>> What is the recommendation? Any links to previous discussions / documents >> about >> this subject? > Policy 10.1. Thanks Andrey for pointing out the relevant policy chapter. I should have mentioned it in my first post since exactly that section in a way brought me to this list. However, I think the policy gives us a lot of freedom to choose (it is not very strict in this case). The alternatives system is supposed to be used for packages which provide similar functionality (as far as I have understood), and that is absolutely not the case here. Let me do it this way then: I will propose what I intend to do with netgen-lvs (what i think may be best), and then we will see if anyone has better ideas. :) 1. The new source package netgen-lvs will contain two binary packages: - netgen-lvs - netgen-lvs-base 2. netgen-lvs will have a Conflict: netgen (existing unrelated package). 3. The netgen-lvs-base binary package comes with all the (main) files for netgen-lvs. The executable will be called /usr/bin/netgen-lvs It will NOT conflict with "netgen". 4. the netgen-lvs source package will be patched such that it works with the executable called /usr/bin/netgen-lvs (there are some tcl scripts and python scripts) 5. The netgen-lvs binary package provides basically just a symlink from /usr/bin/netgen to /usr/bin/netgen-lvs 6. The netgen-lvs binary package depends on netgen-lvs-base 7. A paragraph is added to the long description for netgen-lvs which explains that it conflicts with netgen (3d tetrahedral mesh generator), and if both are supposed to be installed at the same time, the package netgen-lvs-base must be installed instead of netgen-lvs. Also: i. A similar paragraph in the long description can later be added to netgen's long description. ii. A "Conflict: netgen-lvs" should be added to netgen later. iii. Maybe in the future, the "netgen" package can provide a similar "alternative binary package" for people who would like to have both netgen and netgen-lvs installed, but /usr/bin/netgen representing netgen-lvs This will allow people to run "apt install netgen-lvs" and they will get a netgen install which behaves exactly as the upstream version. (usr/bin/netgen is what they think it is) This still allows people to have both netgen and netgen-lvs(source) installed, but then netgen-lvs will be found as /usr/bin/netgen-lvs. I know that the alternatives system can technically be used to achieve similar functionality, but it feels like it is meant only for cases where the various programs provide similar functionality, and therefore not for this case. Best regards Ruben
Re: New package netgen-lvs with binary /usr/bin/netgen - already taken
Hi Sean, > > However, I think the policy gives us a lot of freedom to choose (it is not > > very > > strict in this case). > > I don't understand. This seems pretty strict: > > Two different packages must not install programs with different > functionality but with the same filenames. Yes, you are right, when I read it again. What I have been "reading" before is. "Two different packages must not install programs with different functionality but with the same filenames if they do not declare that they "Conflict:" with each other." But it doesn't say that.. So this means there is no way to provide the upstream executable name without violating the policy? :( - even when using "Conflict:" wisely. > > The alternatives system is supposed to be used for packages which > > provide similar functionality (as far as I have understood), and that > > is absolutely not the case here. > > Right, alternatives is not for this. > > > 5. The netgen-lvs binary package provides basically just a symlink from > >/usr/bin/netgen to /usr/bin/netgen-lvs > > To my mind, this straightforwardly violates the sentence from Policy > quoted above, and would thus be RC-buggy. And it also means that the package pair "nodejs-legacy" and "node" was RC buggy when the packages were present (jessie I guess) Does anyone know about other packages this applies for? Any easy way to search the archive for packages that provide files with the same name? Cheers Ruben
Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
Hi, > > Renaming binaries is a big pain, it is confusing for the user, making the > > life of the maintainer > > harder, the documentations won't reflect the Debian-reality. > > > > The wording should be changed from "must" to "should": > > --- > > Two different packages should not install programs with different > > functionality but with the same filenames. > > --- > > and give more flexibility to maintainers. > > > > Or am I missing a key reason for this? > > The current policy protects maintainers and users of less popular > packages from feeling that their package is less important in Debian, > just because something else that is more popular comes along and happens > to use the same name. In this discussion, I would like to distinguish between package names and file names for files in a package. For package names, it makes completely sense that the first package to enter the archive is entitled to have exclusive rights to the name, even though a more popular package which appears later would have the same upstream name. That helps users of less popular packages to not feel that their package is less important in Debian. If the later and more popular package will need a "name compatibility package" such as nodejs-legacy to provide the correct upstream executable name, the users of the less popular package will still not feel (I assume) that their package is less important in Debian. > The current policy means that the discussion about which package should > use the name begins on neutral ground, without prejudice against the > less popular package. By requiring that they both change their names if > agreement cannot be reached, the maintainers put on equal footing. > To my mind, this is part of our attempt to be "the universal operating > system". My take on it is that having no way to provide the executable name which users expect (with name compatibilty packages such as nodejs-legacy was) makes the operating system less "universal" in a way. Cheers, Ruben
Re: New package netgen-lvs with binary /usr/bin/netgen - already taken
Hi David, > I may have missed it, but it looks like you didn’t ask directly the > netgen maintainers (or explicitly CC them during this discussion). Maybe > a first good step is to communicate with them and ask what is their take > on that matter If there is no way to actually share a file name without breaking the policy, there is not anything we alone can agree on without involving the whole community. I have absolutely no intention of stealing the /usr/bin/netgen from them ;) I have not asked the netgen maintainers directly, because the proposed package upload of netgen-lvs would not have a direct impact on that package. Also, I also consider debian-devel an open forum, assuming they also read here if interested (probably too naive of me). :) > (trying to find a consensus without half of the involved > party may be considered as rude, that’s probably not your intention). Absolutely not my intention. Thanks for pointing it out. You are probably right, but if I were the netgen maintainer, I could probably just as well think it would be rude to be contacted to be asked to "share" a file name, when it can be solved without involving me - and it does not directly impact my package. :) Thanks again! Best regards, Ruben
Re: New package netgen-lvs with binary /usr/bin/netgen - already taken
> stupid idea: > > do these scripts (and other consumers of the netgen binaries) actually > use the fully qualified "/usr/bin/netgen" or just an unqualified "netgen"? > > if the latter, you might just put the unchanged names into something > like /usr/share/netgen/bin/ and tell users to add to that to their PATH > when running their scripts. > that provides a simple compat layer for out-of-distro scripts. > rdeps in Debian should be patched to use debianized script-names. Thanks, IOhannes This may actually turn out to be the best idea if the policy is not changed as a result of the discussion that has started. :) Ruben
Re: New package netgen-lvs with binary /usr/bin/netgen - already taken
Hi, After now having seen many arguments (this thread became longer than anticipated) for both changing the policy and for keeping it the way it is, I am now quite convinced that the policy should be the way it is! > > stupid idea: > > > > do these scripts (and other consumers of the netgen binaries) actually > > use the fully qualified "/usr/bin/netgen" or just an unqualified "netgen"? > > > > if the latter, you might just put the unchanged names into something > > like /usr/share/netgen/bin/ and tell users to add to that to their PATH > > when running their scripts. > > that provides a simple compat layer for out-of-distro scripts. > > rdeps in Debian should be patched to use debianized script-names. For netgen-lvs, I will just put the binary using the upstream name in /usr/lib/netgen-lvs/bin There will be a symlink in /usr/bin/netgen-lvs pointing to /usr/lib/netgen-lvs/bin/netgen Actually just putting a note in README.Debian saying something like this... If you would like to use netgen-lvs with the upstream name "netgen", set the PATH environment variable to PATH=/usr/lib/netgen-lvs/bin:$PATH To permanently enable the upstream binary name "netgen" for a user, you can for example add the following to the shell startup source file (~/.bashrc, ~/.zshrc ..): export PATH=/usr/lib/netgen-lvs/bin:$PATH ... should solve the problem. This way, we do not globally mess up the namespace for the system. It will only apply for specific users (root is not affected if not explicitly touched, and hence not system scripts). It makes it easy to see exceptions (echo $PATH), and we do not have to waste time making "ugly" compatibility packages. At the same time, the user will be encouraged to use the Debian name for the executable if possible. I guess the "long description" for the package can also refer to README.Debian for how to handle the "issue", to make the user aware of it even before installing it. This may even be good enough for more complicated cases such as nodejs (was)? Thanks IOhannes for the suggestion.. Best regards, Ruben
Re: Limiting the size of installed changelogs
> Yes, this would be very sensible IMHO. > > Having debhelper cut off the changelogs from 4 or 6 years before (and > inserting a pointer to the source package for the rest) sounds like > a good idea to me. It would be nice if X number of the oldest entries are kept - particularly the "initial release" one. "X" can be 1 also. It is useful to know when the package entered Debian initially. Between the newer versions and the very old one(s), there can be a comment (with some nice dots and lines) pointing to where to find the missing ones. I remember I have been annoyed on Ubuntu machines when just seeing the "head" of the changelog file.. I also really hope that the full changelog always remains in the source package, and that all cutting is handled automatically by dh_installchangelogs. Regards Ruben
Bug#909429: ITP: osmo-sgsn -- Serving GPRS Support Node for Mobile Networks
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: osmo-sgsn Version : 1.3.0 Upstream Author : Osmocom * URL : https://osmocom.org/projects/osmosgsn/wiki/OsmoSGSN * License : AGPL-3 Programming Lang: C Description : Serving GPRS Support Node for Mobile Networks OsmoSGSN is the Serving GPRS Support Node: it handles signalling, i.e. attach/detach of subscribers and PDP contexts for data services. OsmoSGSN needs to reach the GGSN to establish GTP tunnels for subscribers. It must have a separate GTP IP address from OsmoGGSN, as mentioned before. It is needed for data support in the Osmocom mobile network infrastructure, and will be maintained in the Debian Mobcom team.
Bug#909823: ITP: getthermal -- USB thermal camera viewer
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: getthermal Version : 0.1.3 Upstream Author : GroupGets LLC * URL : https://github.com/groupgets/GetThermal * License : MIT Programming Lang: C++ Description : USB thermal camera viewer GetThermal allows viewing the radiometric temperature readings with cameras used with the PureThermal 1 and PureThermal 2 I/O boards (various FLIR Lepton variants). It supports changing the color mapping. It is a single QT application.
Bug#801229: ITP: icestorm -- Tools to handle the bitstream format of Lattice iCE40 FPGAs
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: icestorm Version : 0~20151006git103e6fd Upstream Author : Clifford Wolf * URL : http://www.clifford.at/icestorm/ * License : ISC Programming Lang: Python Description : Tools to handle the bitstream format of Lattice iCE40 FPGAs Project IceStorm aims at documenting the bitstream format of Lattice iCE40 FPGAs and providing simple tools for analyzing and creating bitstream files. At the moment the focus of the project is on the HX1K-TQ144 and HX8K-CT256 devices, but most of the information is device-independent. This package contains multiple tools needed to handle the bitstream. The package is useful for providing a full flow for FPGA development in Debiani together with tools such as yosys. I plan to maintain the package in the Debian Science team just as I do with the qflow packages that are somewhat related. Cheers
Bug#801230: ITP: arachne-pnr -- Place and route tool for FGPAs
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: arachne-pnr Version : 0~20150927gitefdb026 Upstream Author : Cotton Seed * URL : https://github.com/cseed/arachne-pnr * License : GPL Programming Lang: C++ Description : Place and route tool for FGPAs Arachne-pnr implements the place and route step of the hardware compilation process for FPGAs. It accepts as input a technology-mapped netlist in BLIF format, as output by the Yosys synthesis suite for example. It currently targets the Lattice Semiconductor iCE40 family of FPGAs. Its output is a textual bitstream representation for assembly by the IceStorm icepack command. The output of icepack is a binary bitstream which can be uploaded to a harware device. Together, Yosys, arachne-pnr and IceStorm provide an fully open-source Verilog-to-bistream tool chain for iCE40 1K and 8K FPGA development. I plan to maintain the package in the Debian Science just as the qflow packages (yosys etc.) Cheers
Bug#803988: ITP: osm-tile-server -- OpenStreetMap tile server
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: osm-tile-server Version : 0.1 Upstream Author : native package * URL : https://github.com/rubund/osm-tile-server * License : GPL-2+ Programming Lang: C, bash Description : OpebStreetMap tile server osm-tile-server is a native Debian package that aims to help people setting up a tile server for OpenStreetMap in Debian. It takes advantage of packages already in Debian and adds the necessary "glue" to make a tile server work sort of "out-of-the-box". The intention is to support different rendering engines such as tilelite and mod_tile, but since mod_tile is not yet in Debian, only support for tilelite is there yet. This functionality is given by the package 'osm-tile-server-tilelite'. The binary package 'osm-tile-server' is a metapackage that pulls in "osm-tile-server-tilelite | osm-tile-server-mod-tile", but where osm-tile-server-mod-tile doesn't exist yet. The binary package 'osm-tile-server-base' provides the scripts necessary to setup a postgis database, download OSM data and import it. Everything can be accomplished with debconf selections. With this package, it is possible to have a fully functional OpenStreetMap tile server using only one command: sudo apt install osm-tile-server or: sudo apt install osm-tile-server-tilelite I plan to maintain it as part of the Debian GIS team. Ruben
Bug#806582: ITP: libosmo-abis -- Library containing shared code regarding the A-bis interface between GSM BTS and GSM BSC
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: libosmo-abis Version : 0.3.2 Upstream Author : Osmocom * URL : http://openbsc.osmocom.org/trac/wiki/libosmo-abis * License : AGPL-3 Programming Lang: C Description : Library containing shared code regarding the A-bis interface between GSM BTS and GSM BSC This is a library containing common/shared code regarding the A-bis interface between BTS and BSC. It is needed for OpenBSC and OsmoBTS which are open source implementations of parts of the GSM network. It also implements drivers for mISDN and DAHDI based E1 cards, as well as some A-bis/IP dialects. I plan to maintain it as part of the Debian Science team just as the related library libosmocore.
Bug#806583: ITP: openbsc -- GSM Base Station Controller (BSC) and minimalistic GSM network implementation
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: openbsc Version : 0.15.0 Upstream Author : Osmocom * URL : http://openbsc.osmocom.org/trac/wiki/OpenBSC * License : AGPL-3 Programming Lang: C Description : GSM Base Station Controller (BSC) and minimalistic GSM network implementation It started as a BSC (Base Station Controller) side implementation of the A-bis protocol, as implemented in the GSM Technical Specification 08.5x and 12.21. It can run either - as a classic BSC, exposing an A interface towards an external MSC, or - as NITB (Network In The Box), whert implements a minimal subset of the BSC, MSC. SMSC? and HLR. The goal of the project is to - provide a basis for experimentation and security research with GSM from the network side - provide a zero-cost alternative for hands-on experience with GSM systems in education and training - learn more about GSM networks on a lower level, particularly the practical aspects with real-world equipment - provide a stable/reliable network-side GSM implementation for small networks that don't need millions of subscribers or 99.9% availability I plan to maintain it as part of the Debian Science team together with libosmocore and related packages.
Bug#806584: ITP: osmo-bts -- Layer2/3 of a GSM Base Transceiver Station (BTS)
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: osmo-bts Version : 0.4.0 Upstream Author : Osmocom * URL : http://openbsc.osmocom.org/trac/wiki/OsmoBTS * License : AGPL-3 Programming Lang: C Description : Layer2/3 of a GSM Base Transceiver Station (BTS) OsmoBTS is a software implementation of Layer2/3 of a GSM Base Transceiver Station (BTS). It implements the follwing protocols/interfaces: - LAPDm (GSM 04.06) - RTP - A-bis/IP in IPA multiplex - OML (GSM TS 12.21) - RSL (GSM TS 08.58) OsmoBTS is modular and has support for multiple back-ends. A back-end talks to a specific L1/PHY implementation of the respective BTS hardware. Based on this architecture, it should be relatively easy to add a new back-end to support so-far unsupported GSM PHY/L1 and associated hardware. So far OsmoBTS has been integrated with several different L1/PHY and hardware systems. The backends are: - osmo-bts-sysmo Multiple indoor and outdoor BTS products called sysmoBTS - osmo-bts-trx Wideband SDR transceiver hardware supported by OpenBTS transceiver or [OsmoTRX] PHY layer software - osmo-bts-bb A pretty crazy experimental BTS hardware based on two OsmocomBB phones had originally been supported, but needs to be re-integrated with core code changes. I plan to maintain it as part of the Debian Science team just as other OpenBSC related packages.
Bug#806585: ITP: libosmo-netif -- Shared code regarding network interfaces for OpenBSC
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: libosmo-netif Version : 0.0.6 Upstream Author : Osmocom * URL : http://openbsc.osmocom.org/trac/ * License : GPL-2 Programming Lang: C Description : Shared code regarding network interfaces for OpenBSC This library is a dependency of OpenBSC. I plan to maintain it in the Debian Science team just as the other OpenBSC related packages.
Bug#813293: ITP: openggsn -- OpenSource Gateway GPRS Support Node (GGSN)
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: openggsn Version : 0.92 Upstream Author : Osmocom * URL : http://sourceforge.net/projects/ggsn/ * License : GPL-2 Programming Lang: C Description : OpenSource Gateway GPRS Support Node (GGSN) OpenGGSN has previously been part of Debian, but was removed in 2007, since back then it was a dead project, and "nobody" was using it. Now it is alive again and a dependency for the OpenBSC GSM base station infrastructure from Osmocom. OpenGGSN is a Gateway GPRS Support Node (GGSN). It is used by mobile operators as the interface between the Internet and the rest of the mobile network infrastructure.
Bug#813295: ITP: libsmpp34 -- Open PDU SMPP packaging and unpackaging tool
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: libsmpp34 Version : 1.10 Upstream Author : Raul Tremsal * URL : http://c-open-smpp-34.sourceforge.net/ * License : LGPL Programming Lang: C Description : Open PDU SMPP packaging and unpackaging tool libsmpp34 is a an implementation for providing the PDU handling of the SMPP-3.4 protocol. SMPP (Short Message Peer-to-Peer) is an open industry standard protocol designed to provide a flexible data communication interface for the transfer of short message data between External Short Messaging Entities, Routing Entitites and Message Centres. libsmpp34 is a dependency for the OpenBSC GSM base station infrastructure and should therefore be included in Debian.
Bug#813294: ITP: libosmo-sccp -- Osmocom library for SCCP
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: libosmo-sccp Version : 0.7.0 Upstream Author : Osmocom * URL : https://github.com/osmocom/libosmo-sccp * License : GPL Programming Lang: C Description : Osmocom library for SCCP This is a library for handling SCCP (Signaling Connection Control Part) which is used extensively in cellular networks such as GSM. It is a dependency for the OpenBSC GSM base station infrastructure, and should therefore be included in Debian.
Bug#815224: ITP: osmo-pcu -- Packet Control Unit for GPRS
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: osmo-pcu Version : 0.2 Upstream Author : Jacob Erlbeck (Sysmocom) * URL : http://openbsc.osmocom.org/trac/wiki/osmo-pcu * License : GPL-2+ Programming Lang: C++ Description : Packet Control Unit for GPRS osmo-pcu is the Packet Control Unit (PCU) in the Osmocom GSM infrastructure. A PCU is one of the two GPRS elements in the BSS. It implements the RLC and MAC layers of the GPRS Um (radio) interface on the MS-facing side, as well as the Gb Interface (NS,BSSGP) on the SGSN-facing side. osmo-pcu should be in Debian in order to complete the inclusion of all the Osmocom software related to GSM base stations. I plan to maintain it as part of the Debian Science team.
Bug#830109: ITP: openems -- Electromagnetic field solver using the FDTD method
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: openems Version : 0.0.34 Upstream Author : Thorsten Liebig * URL : http://openems.de * License : GPL-3+ Programming Lang: C++ Description : Electromagnetic field solver using the FDTD method OpenEMS is a free and open electromagnetic field solver using the FDTD method. Matlab or Octave are used as an easy and flexible scripting interface. It features: - fully 3D Cartesian and cylindrical coordinates graded mesh. - Multi-threading, SIMD (SSE) and MPI support for high speed FDTD. There are already two packages in Debian which offer similar functionality (meep and tessa), but openEMS has an easier interface via Octave/Matlab and is much more actively being developed. I plan to maintain it as part of the Debian Science team.
