Bug#1013345: ITP: west -- Description: meta tool for Zephyr RTOS
I forgot about this entirely, having changed jobs. Let me share what I made once I'm home. W dniu 17.03.2023 o 14:29 Jakob Haufe pisze: > Hi Zygmunt, > > I would be interested in having west packaged in Debian as well. > > Feel free to contact me for review or sponsorship either by mail or > (preferably for more interactive work) via IRC (#debian-mentors on OFTC). > > Cheers, > sur5r > > -- > ceterum censeo microsoftem esse delendam.
Bug#1013345: ITP: west -- Description: meta tool for Zephyr RTOS
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki X-Debbugs-Cc: debian-de...@lists.debian.org, m...@zygoon.pl * Package name: west Version : 0.13.1 Upstream Author : Marti Bolivar * URL : https://github.com/zephyrproject-rtos/west * License : Apache-2.0 Programming Lang: Python Description : meta tool for Zephyr RTOS West lets you manage multiple Git repositories under a single directory using a single file, called the west manifest file, or manifest for short. By default the manifest file is named west.yml. You use "west init" to set up this directory, then "west update"to fetch and/or update the repositories named in the manifest. West is relevant to the Zephyr community. Having a proper Debian package would simplify initial setup and avoid some of the "install everything from pip" workflows that are harder to control. I would like to team-maintain the package inside the Python apps or modules team, as appropriate. The package has few dependencies and should be relatively hassle-free. I need a sponsor to review and upload the package.
Bug#991261: ITP: adr-tools -- tools for working with Architecture Decision Records (ADRs)
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki X-Debbugs-Cc: debian-de...@lists.debian.org, m...@zygoon.pl * Package name: adr-tools Version : 3.0.0 Upstream Author : Nat Pryce * URL : https://github.com/npryce/adr-tools * License : GPL-3 Programming Lang: Shell Description : tools for working with Architecture Decision Records (ADRs) Architecture Decision Records or ADRs for short encode architectural decisions through the lifetime of a project. They are meant to help future maintainers to understand how the project came do be the way it is. ADRs can help understand past decisions, supersede them with new decisions and list currently effective decisions. This package is useful for working with ADR documents. It has very little upstream activity at this time so I don't expect it to be a maintenance burden. I plan to use the package myself and I wanted to share it with others. I plan to maintain it myself, with sponsor supporting the upload process. Co-maintainers are welcome if more people are interested.
Bug#959105: ITP: zmk -- collection of reusable Makefiles
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki Package: wnpp Owner: Zygmunt Krynicki Severity: wishlist * Package name: zmk Version : 0.1 Upstream Author : Zygmunt Krynicki * URL : https://github.com/zyga/zmk/ * License : LGPL-3 Programming Lang: Make, Shell Description : collection of reusable Makefiles Collection of makefiles implementing a system similar to autotools, but without the generated files that make understanding system behaviour harder. . Highlights include: . - Describe programs, test programs, static libraries, shared libraries, development headers, manual pages and more - Use familiar targets like "all", "check", "install" and "clean" - Works out of the box on popular distributions of Linux and MacOS - Friendly to distribution packaging expecting autotools - Compile natively with gcc, clang, tcc or the open-watcom compilers - Cross compile with gcc and open-watcom - Efficient and incremental, including the install target This package is probably only useful to me and several of my colleagues that follow my work. I'm working on documenting it extensively, so that others can benefit from it as well. A version of this package is bundled as a build system of the library libzt. Similar to how autoconf, automake and libtool are often used to assist in compiling C programs. With the release of libzt 0.3-1 this build system handles nearly all of the Debian requirements for configuration, cross-compiling, reproducible builds, building with clang instead of gcc. As it matures it could be considered as a viable alternative to the classic build toolchain. I plan to maintain it myself but I welcome experience and advice from all Debian Developers and Debian Maintainers. I need a sponsor for the package.
Bug#951547: Initial packaging
I’ve prepared initial packaging here https://github.com/zyga/libzt/tree/pkg/debian/packaging/debian It builds and passes lintian checks although my packaging memory may be a little rusty.
Bug#951547: ITP: libzt -- libzt is a simple and robust unit test library for C
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki * Package name: libzt Version : 0.1 Upstream Author : Zygmunt Krynicki * URL : http://github.com/zyga/libz/ * License : LGPL Programming Lang: C Description : libzt is a simple and robust unit test library for C The library provides functions for common checks and assertions, which produce readable diagnostic messages that integrate well with "make check" and programming editors, such as vi. - Robust, allowing you to focus on your code. - Simple and small, making it quick to learn and use. - Doesn't use dynamic memory allocation, reducing error handling. - Equipped with useful helpers for writing test cases. - Portable and supported on Linux, MacOS and Windows. - Documented and fully coverage and integration tested. This package may be useful to projects that want to write C unit tests but don't want to depend on glib or roll their own solution I would like to maintain it myself or in a team. The package needs to be sponsored.
Bug#800144: python-requests-toolbelt -- Useful classes and functions to be used with python-requests
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki * Package name: python-requests-toolbelt Version : 0.4.0 Upstream Author : Ian Cordasco * URL : http://toolbelt.readthedocs.org * License : Apache Programming Lang: Python Description : Useful classes and functions to be used with python-requests Requests Toolbelt is a collection of utilities that some users of python-requests might need but do not belong in requests proper. The library is actively maintained by members of the requests core development team, and so reflects the functionality most requested by users of the requests library. - This package is a new dependency of twine - I intend to maintain it the same way as all the other python packages I'm working on, as a part of DPMT + PAPT (here DPMT).
Bug#783065: ITP: python-guacamole -- library for command line applications for Python
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki * Package name: python-guacamole Version : 0.8 Upstream Author : Zygmunt Krynicki * URL : https://github.com/zyga/guacamole * License : LGPL, BSD Programming Lang: Python Description : library for command line applications for Python Guacamole is a flexible, modular system for creating command line applications. Guacamole comes with built-in support for writing command line applications that integrate well with the running system. A short list of supported features (ingredients) includes: .. - handling flat and hierarchical commands - hassle-free crash detection - hassle-free logging - internationalization and localization .. The guacamole ingredient system allows for third party add-ons. I want to maintain this library in DPMT, along with my other work. The package will be adopted as a new dependency of the plainbox and checkbox-ng packages in the next few releases. -- 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/20150421130601.7.66207.reportbug@fx
Bug#781590: ITP: plainbox-provider-piglit -- Piglit (OpenGL/OpenCL) Test Provider for Plainbox
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki * Package name: plainbox-provider-piglit Version : 0.1 Upstream Author : Zygmynt Krynicki * URL : https://launchpad.net/plainbox-provider-piglit * License : GPL3 Programming Lang: Python Description : Piglit (OpenGL/OpenCL) Test Provider for Plainbox This package contains a plainbox provider, a set of tests (called jobs) that can be executed with the plainbox toolkit or applications based on plainbox. .. This providers wraps several of piglit tests and exposes them as plainbox jobs. There are also jobs for creating a piglit-made HTML report and packaging it as a tarball. .. The full list of units contained in this provider is: .. 2013.com.canonical.certification::piglit/test/fbo 2013.com.canonical.certification::piglit/test/gl-2.1 2013.com.canonical.certification::piglit/test/vbo 2013.com.canonical.certification::piglit/test/glsl-fragment-shader 2013.com.canonical.certification::piglit/test/glsl-vertex-shader 2013.com.canonical.certification::piglit/test/glx-tfp 2013.com.canonical.certification::piglit/test/stencil_buffer 2013.com.canonical.certification::piglit/support/combine_results 2013.com.canonical.certification::piglit/support/summarize_results 2013.com.canonical.certification::piglit/support/tarball .. They can be executed together using this test plan: .. 2013.com.canonical.certification::piglit This package is a new project coming out of the plainbox / checkbox ecosystem. It depends on piglit (waiting in NEW) and more recent version of plainbox (I'm working on packaging it) and plainbox-provider-resource. I'm filing the ITP bug so that packaging can be ready when all the other things land and unblock this. This package is relevant for testing OpenGL / OpenCL implementation. Piglit is used by several hardware manufacturers during their development process and having access to piglit via the unified plainbox interface (specifically through the Canonical Driver Test Suite) benefits all users in the long term. I'd like to maintain it as all the other providers, under PAPT, with checkbox developers as the main maintainer but PAPT and mysefl as uploaders (this is a team effort though I don't think this package will require many changes). -- 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/20150331105439.12071.96060.reportbug@fx
Bug#780126: ITP: python-padme -- mostly transparent proxy class for Python
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki * Package name: python-padme Version : 1.1.1 Upstream Author : Zygmunt Krynicki * URL : https://github.com/zyga/padme/ * License : LGPL3 Programming Lang: Python Description : mostly transparent proxy class for Python Padme, named after the Star Wars (tm) character, is a library for creating proxy objects out of any other Python object. The resulting object is as close to mimicking the original as possible. Some things are impossible to fake in CPython so those are highlighted below. All other operations are silently forwarded to the original. Padme is a vendorized dependency of plainbox and I want to create a standalone package. Padme will be team-maintained though I will obviously release each update myself if nobody else beats me to it. Since Padme is small in scope and well-defined it should require little maintenance. -- 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/20150309144632.3337.99075.reportbug@fx
Bug#762405: ITP: morris
Package: wnpp Severity: wishlist * Package name: morris Version : 1.0 Upstream Author : Zygmunt Krynicki * URL : https://github.com/zyga/morris * License : LGLP Programming Lang: Python Description : an announcement (signal/event) system for Python Morris is named after Gabriel Morris, the inventor of Colonne Morris aka the advertisement column. Morris is a simple and proven Python event/signaling library (not for watching sockets or for doing IO but for generic, in-process broadcast messages). Morris works on python 2.7+, pypy and python 3.2+. It comes with tests, examples and extensive docstrings. -- 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/20140921231838.25440.62838.reportbug@pi
Bug#745342: Bug#745347: Bug#745342: Status of twine in Debian
On Mon, Sep 1, 2014 at 9:55 PM, Gaudenz Steinlin wrote: > > [ As this is in large parts about python-releases I'm CCing the relevant > ITP bug report. ] > > Hi Zygmunt > > Sorry, I haven't been able to catch you on IRC. Just ping me, I'm > gaudenz on oftc. I've just pinged you. I'm sorry my network was unreliable today and I closed IRC > Zygmunt Krynicki writes: > >> Hi Gaudenz >> >> I've packaged twine and python-releases (a build dependency). >> Python releases was rejected and thus I was unable to upload twine. > > You still don't mention why it was rejected. In bug #745347 there was It was apparently rejected because the orig tarball didn't have the LICENSE file > some discussion about the package name. Was that the reason? What does > hold you from renaming it to python-sphinx-releases or even better first > discussing this on the debian-python list as proposed in the bug. > > Looking at what's currently in the archive there does not seem to be a > universal naming scheme for sphinx extensions. The following are > possible names for releases with some precedent: > > - python-sphinx-releases I think we can pick that one ^ > - python-sphinxcontrib-releases > - python-sphinxcontrib.releases > > >> >> Twine and releases (not request!) are both in DPMT's SVN tree. Please >> ping me on #debian-python (zyga) as I'd like someone to help me to >> finish those and perhaps convert them to the new git world. > > I found the releases repository, but was unable to find the one for > twine. Do you have an URL? Sorry, I'm too used to DPMT, it's actually in PAPT svn+ssh://svn.debian.org/svn/python-apps/packages/twine/trunk >> I haven't uploaded them to mentors. as I was working with Piotr >> Ożarowski and it seems that DPMT is not using mentors. > > That's fine, if the packages are in a source control repository there is > not much point in uploading to mentors. Let's talk on IRC : -) Thanks ZK -- 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/cajn_i4_61n1dhjfsf2724zpi5bwwrcxtum3ish-ru80pmvi...@mail.gmail.com
Bug#745342: Status of twine in Debian
Hi Gaudenz I've packaged twine and python-releases (a build dependency). Python releases was rejected and thus I was unable to upload twine. Twine and releases (not request!) are both in DPMT's SVN tree. Please ping me on #debian-python (zyga) as I'd like someone to help me to finish those and perhaps convert them to the new git world. I haven't uploaded them to mentors. as I was working with Piotr Ożarowski and it seems that DPMT is not using mentors. Best regards Zymunt Krynicki On Sun, Aug 31, 2014 at 5:59 PM, Gaudenz Steinlin wrote: > > Hi Zygmunt > > I just stumbled over this bug report when I wondered why there is no > twine package in Debian. > > The last response from you indicates that the requests package was > rejected. Why did you package that? There is already a python-reqeusts > package in Debian since a long time. Is this not the same or is it just > outdated? > > I could not find any traces of the twine package. Where did you upload > that or where is it under review? Did you mean it was in the NEW queue > or did you upload it to mentors.debian.net? > > If you need any help I'm happy to assist. I can also sponsor your > package if you are not a DD and need a sponsor. > > Gaudenz -- 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/CAJN_i49zMnwC2ivhDRpp=t_m_xz0wwh3ncfxjtsnmjdquvo...@mail.gmail.com
Bug#745342: ITP: twine -- Collection of utilities for interacting with PyPI
Hi I've packaged twine and its dependency 'requests' but they are stuck in review. Requests was recently rejected and twine cannot be uploaded without that first. Thanks ZK On Mon, Aug 18, 2014 at 2:06 AM, Julian Gilbey wrote: > On Sun, Apr 20, 2014 at 07:52:56PM +0200, Zygmunt Krynicki wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Zygmunt Krynicki >> >> * Package name: twine >> Version : 1.3.1 >> Upstream Author : Donald Stufft >> * URL : https://github.com/dstufft/twine >> * License : Apache 2.0 >> Programming Lang: Python >> Description : Collection of utilities for interacting with PyPI >> >> Twine is a utility for interacting with PyPI. >> [...] >> >> I'd like to maintain twine inside PAPT > > Hi Zygmunt, > > This sounds like a great idea. Are you planning to go ahead with > this? > >Julian -- 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/cajn_i48vvxwcpk9sc4kudzzyf0ddzjkhrb6xbnqg-xldb01...@mail.gmail.com
Bug#745347: ITP: releases -- A Sphinx extension for changelog manipulation
I'll gladly rename the package and try again. Since I got no official rejection AFAIR from any ftp-master, should I just do the rename and seek another sponsorship upload? Thanks ZK On Wed, Jun 11, 2014 at 12:42 PM, Guillem Jover wrote: > Hi! > > On Mon, 2014-04-21 at 15:19:38 +0100, Steve Cotton wrote: > > On Mon, Apr 21, 2014 at 14:05 +0200, Zygmunt Krynicki wrote: > > > I saw the package being uploaded to NEW just a moment ago. I could > rename > > > it to python-releases (I don't think there's a standard naming scheme > for > > > sphinx extensions yet). What do you think? > > > > I find "python-releases" confusing in the same way. If I saw > > > > "Bug #xx is in stable python-releases but fixed in unstable > python-releases." > > > > then I'd understand that it was a bug in the python2.7 & python3.2 > > packages, not a bug in a package called "python-releases". > > > > I prefer a name that doesn't look like the name of another package > > followed by the word "releases". Maybe "python-releaseslog". > > Or python-sphinx-releases, python-sphinx.releases or something like that, > there's few precedents for the former on the archive already. I think it > would be nice to discuss this on the debian-python list to try to come > to an agreement on the namespace, because simply using the non-namespaced > upstream module name is really not good for the overall distribution. > > Please make sure to rename both binary and *source* packages. > > > Note: I'm not a DD, if no DD is complaining then maybe it's not > confusing. > > I just saw it in NEW and I've to agree it is very confusing. I think > people might usually notice when it's already in the archive which > implies going through NEW again, package removal requests, possibly > transitional packages, etc, which might deter them from mentioning it > or filing bug reports. > > IMO the ftp-masters are not rejecting enough packages when it comes > to namespace problems. > > Thanks, > Guillem >
Bug#748677: ITP: arrowhead -- micro-framework for flowchart-like computing
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki Package name: arrowhead Version : 1.0 Upstream Author : Zygmunt Krynicki URL : https://github.com/zyga/arrowhead/ License : BSD-3-clause Programming Lang: python Description : micro-framework for flowchart-like computing Arrowhead is a framework for constructing flow charts composed of steps connected by (possibly) conditional branches. Such flows can be executed, inspected (at runtime) and visualized (for documentation and verification) . The idea of flowchart computing is designed in a way that mimics a hand-made drawing, typically on a white-board or a piece of paper, that describes some process as a graph of interconnected steps. . Traditionally, once designed, the process is implemented as a collection of functions and classes. Very often the original idea of the process was supposed to work lost, especially after making changes over time. Usually it is impossible to easily reconstruct the initial idea from a complex implementation of that idea. . As an added issue, it is non-trivial to create derivative processes that somehow override, change, replace or remove parts of the process. This can affect one step or a particular group of steps. . The arrowhead framework aims to address both problems. . This package contains the python3 version of this library. This package is an upcoming dependency of the plainbox package. Is also useful to the re-emerging field of dataflow-driven computing and all kinds of flow computing in general. There are no similar packages in Debian that I could find (this is why I also created arrowhead in the first place). I will gladly co-maintain it in DPMT, along with my other packages. -- 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/20140519150859.10542.3906.reportbug@iffy
Bug#746294: ITP: pyotherside -- Asynchronous Python 3 Bindings for Qt 5
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki * Package name: pyotherside Version : 1.2.0 Upstream Author : Thomas Perl * URL : http://thp.io/2011/pyotherside/ * License : BSD Programming Lang: C++ Description : Asynchronous Python 3 Bindings for Qt 5 A Qt 5 QML Plugin that provides access to a Python 3 interpreter from QML. . PyOtherSide is a Qt 5 QML Plugin that provides access to a Python 3 interpreter from QML. It was designed with mobile devices in mind, where high-framerate touch interfaces are common, and where the user usually interfaces only with one application at a time via a touchscreen. As such, it is important to never block the UI thread, so that the user can always continue to use the interface, even when the backend is processing, downloading or calculating something in the background. . At its core, PyOtherSide is basically a simple layer that converts Qt (QML) objects to Python objects and vice versa, with focus on asynchronous events and continuation-passing style function calls. . While legacy versions of PyOtherSide worked with Qt 4.x and Python 2.x, its focus now lies on Python 3.x and Qt 5. Python 3 has been out for several years, and offers some nice language features and clean-ups, while Qt 5 supports most mobile platforms well, and has an improved QML engine and a faster renderer (Qt Scene Graph) compared to Qt 4. I'd like to co-maintain the package (not sure where yet, perhaps DPMT?) -- 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/20140428192610.31578.14549.reportbug@silverblade
Bug#745347: ITP: releases -- A Sphinx extension for changelog manipulation
On Mon, Apr 21, 2014 at 1:50 PM, Steve Cotton wrote: > On Sun, Apr 20, 2014 at 20:35 +0200, Zygmunt Krynicki wrote: > > * Package name: releases > > IMHO, that package name is confusing. For example: > > Bug #xx is in stable releases but fixed in unstable releases. > Bug #xx is in stable sphinx-releases but fixed in unstable > sphinx-releases. > > In the first of those, I don't see which package is being discussed. > > In the second I see the package "sphinx" being discussed, so that > name doesn't work for me either. > > Hi Steve I saw the package being uploaded to NEW just a moment ago. I could rename it to python-releases (I don't think there's a standard naming scheme for sphinx extensions yet). What do you think? Thanks Zygmunt
Bug#745347: ITP: releases -- A Sphinx extension for changelog manipulation
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki * Package name: releases Version : 0.6.1 Upstream Author : Jeff Forcier * URL : https://github.com/bitprophet/releases * License : BDS Programming Lang: Python Description : A Sphinx extension for changelog manipulation Releases is a Sphinx extension designed to help you keep a source control friendly, merge friendly changelog file & turn it into useful, human readable HTML output. Specifically: * The source format (kept in your Sphinx tree as changelog.rst) is a stream-like timeline that plays well with source control & only requires one entry per change (even for changes that exist in multiple release lines). * The output (when you have the extension installed and run your Sphinx build command) is a traditional looking changelog page with a section for every release; multi-release issues are copied automatically into each release. * By default, feature and support issues are only displayed under feature releases, and bugs are only displayed under bugfix releases. This can be overridden on a per-issue basis. This package is a build dependency of 'twine' I intend to maintain it as a part of DPMT -- 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/20140420183545.16309.64287.reportbug@silverblade
Bug#745342: ITP: twine -- Collection of utilities for interacting with PyPI
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki * Package name: twine Version : 1.3.1 Upstream Author : Donald Stufft * URL : https://github.com/dstufft/twine * License : Apache 2.0 Programming Lang: Python Description : Collection of utilities for interacting with PyPI Twine is a utility for interacting with PyPI. The biggest reason to use twine is that python setup.py upload uploads files over plaintext. This means anytime you use it you expose your username and password to a MITM attack. Twine uses only verified TLS to upload to PyPI protecting your credentials from theft. Secondly it allows you to precreate your distribution files. python setup.py upload only allows you to upload something that you’ve created in the same command invocation. This means that you cannot test the exact file you’re going to upload to PyPI to ensure that it works before uploading it. Finally it allows you to pre-sign your files and pass the .asc files into the command line invocation (twine upload twine-1.0.1.tar.gz twine-1.0.1.tar.gz.asc). This enables you to be assured that you’re typing your gpg passphrase into gpg itself and not anything else since you will be the one directly executing gpg --detach-sign -a . I'd like to maintain twine inside PAPT -- 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/20140420175256.11180.89862.reportbug@silverblade
Bug#730568: ITP: plainbox -- toolkit for software and hardware integration testing
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki * Package name: plainbox Version : 0.4 Upstream Author : Zygmunt Krynicki * URL : https://launchpad.net/checkbox/ * License : GLP Programming Lang: Python Description : toolkit for software and hardware integration testing PlainBox is a toolkit consisting of python3 library, development tools, documentation and examples. It is targeted at developers working on testing or certification applications and authors creating tests for such applications. .. PlainBox can be used to both create simple and comprehensive test tools as well as to develop and execute test jobs and test scenarios. It was created as a refined and rewritten core of the Checkbox project. It has a well tested and documented core, small but active development community and a collection of associated projects that use it as a lower-level engine/back-end library. .. PlainBox has a novel approach to discovering (and probing) hardware and software that is extensible and not hardwired into the system. It allows test developers to express association between a particular test and the hardware, software and configuration constraints that must be met for the test to execute meaningfully. This feature, along with pluggable test definitions, makes plainbox flexible and applicable to many diverse testing situations, ranging from mobile phones, traditional desktop computers, servers and up to testing "cloud" installations. -- 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/20131126173107.14680.13021.report...@hackbox.es.suxx.pl
Bug#720969: ITP: lm4tools -- Tools for flashing and debugging the Stellaris Launchpad board.
Package: wnpp Owner: Zygmunt Krynicki Severity: wishlist * Package name : lm4tools Version : 0.0.0 Upstream Author : Fabio Utzig * URL : https://github.com/utzig/lm4tools * License : GPL2+ Programming Lang: C Description : Tools for flashing and debugging the Stellaris Launchpad board. Tools for flashing and debugging the Stellaris Launchpad board. The lm4flash tool is a command-line firmware flashing tool using libusb-1.0 to communicate with the Stellaris Launchpad ICDI. The lmicdi tool is a TCP/USB bridge created by TI, letting GDB communicate with the Stellaris Launchpad ICDI. -- 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/521b9119.27d0b40a.48b9.7...@mx.google.com
Bug#418613: RFP: command-not-found -- suggest installation packages in interactive sessions
On Apr 15, 2007, at 15:38 , Philippe Coval wrote: Carlos Galisteo de Cabo wrote: Quoting Philippe Coval <[EMAIL PROTECTED]>: * URL : http://ubuntu.suxx.pl/command-not-found--main Could you check the url and forward the good one to [EMAIL PROTECTED], please? Maybe : http://ubuntu.suxx.pl/2006--1/bzr-archive/command-not-found--main/ I am not sure it is the official upstream repository , else check ubuntu repository The official upstream is located at http://suxx.pl/~zyga/command-not- found. To check the status of various branches check out https:// code.launchpad.net/command-not-found/ Regards Zygmunt Krynicki -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
