Bug#1036742: ITP: libvatek -- Userland library to access USB devices based on VATek chips
Package: wnpp Severity: wishlist Owner: Thierry Lelegard X-Debbugs-Cc: debian-devel@lists.debian.org, thie...@lelegard.fr * Package name: libvatek Version : 3.08 Upstream Author : Richie_Chang * URL : https://github.com/VisionAdvanceTechnologyInc/vatek_sdk_2 * License : BSD Programming Lang: C Description : Userland library to access USB devices based on VATek chips The libvatek library accesses USB devices which are based on VATek chips through libusb. VATek chips are used in digital television systems, in modulator devices. This library is used by applications which need to drive VATek-based modulators. Why is this package useful/relevant? This package is required by TSDuck, the MPEG Transport Stream Toolkit. TSDuck is used in many digital television or video streaming systems (see https://tsduck.io/). TSDuck is currently separately packaged for Debian (as well as other distros and operating systems). The purpose is to propose the integration of TSDuck into Debian. A prerequisite for this is the availability of libvatek (this report). The libvatek library is developed by Vision Advanced Technology Inc (VATek) and is available as open source under the BSD-2-Clause license. The "upstream author" above is the maintainer of the library inside VATek Inc. The library is already integrated in HomeBrew (open source package manager for macOS). A binary installer is provided for Windows but no pre-built package is available for any Linux distro. Package maintenance: I am the author and maintainer of TSDuck. I have no connection with VATek Inc, the author of libvatek. But I can maintain the libvatek packet, as a dependency for TSDuck. I need a Debian sponsor since I am not part of any Debian packaging team. A co-maintainer would be useful, at least at the beginning. Note that libvatek is a very simple package (one shared object and a few C/C++ header files).
Bug#1036739: ITP: gnucap-modelgen-verilog -- Verilog-AMS behavioural modelling for Gnucap
Package: wnpp Severity: wishlist Owner: Felix Salfelder X-Debbugs-Cc: debian-devel@lists.debian.org, fe...@salfelder.org * Package name: gnucap-modelgen-verilog Version : 20230520-dev Upstream Contact: gnucap-devel * URL : http://www.gnucap.org/ * License : GPL Programming Lang: C++, Verilog-AMS Description : Verilog-AMS behavioural modelling for Gnucap This package provides support for Verilog-AMS behavioural models in Gnucap as well as supplementary plugins. Verilog-AMS is a standardised hardware description language suitable for analog and mixed signal system modelling. Gnucap is a general purpose circuit simulator. It performs nonlinear dc and transient analyses, Fourier analysis, and ac analysis linearized at an operating point. It is fully interactive and command driven. It can also be run in batch mode or as a server. > usefulness/relevance This package supplements ADMS, the automatic device model synthesizer. Unlike ADMS, modelgen-verilog uses a programming language for the model generation instead of XML template driven text substitution. ADMS is limited to the analog/SPICE subsection of Verilog-AMS, while modelgen-verilog is designed to support mixed features and post-spice architectures. > maintenance I will maintain this packgage as a pkg-electronics team member.
Re: #932957 Please migrate Release Notes to reStructuredText
[ Sending this to #932957 as well, as it contains valueable info on that topic ]
Jeremy Stanley wrote (Wed, 24 May 2023 18:22:09 +):
> On 2023-05-24 19:40:56 +0200 (+0200), Agathe Porte wrote:
> [...]
> > Maybe the idea was to introduce %OLD_RELEASE_NAME% and to call sed to
> > replace this kind of strings in a build step, and not rely on sphinx
> > substitution at all.
> >
> > I know that I have done this a few times and it works fine as a very
> > simple preprocessor.
>
> Similar things can be done at sphinx-build time with a custom Sphinx
> extension (can be a trivial Python module). We do that for the
> published security advisories list upstream in OpenStack:
>
> https://opendev.org/openstack/ossa/src/commit/136b24c/doc/source/conf.py#L31
>
> https://opendev.org/openstack/ossa/src/commit/136b24c/doc/source/_exts/vmt.py
>
> That's a more complex example because we generate a ton of content
> out of structured data (YAML) files by splatting the relevant fields
> into substitutions in a Jinja2 template, but for basic string
> substitution you could get away with something far simpler, or even
> use a canned one like (this was simply my first web search result):
>
> https://pypi.org/project/Sphinx-Substitution-Extensions/
>
> The examples in its readme look to be along the lines of the Debian
> Release Notes use case anyway. There's also basic substitutions
> support in the reStructuredText specification, which might be useful
> to reduce the amount of actual content you need to swap at build
> time:
>
> https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#substitution-definitions
The above seem related to the issue in question, but the solution pointed
out by James Addison in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932957#90
(use parsed-literal ('.. parsed-literal::') blocks)
seems to be the easier one (at least for this document) and it works fine
here. So I would go for it.
Thanks anyway
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#1036729: ITP: libfuture-xs-perl -- experimental XS implementation of Future
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libfuture-xs-perl Version : 0.10 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Future-XS * License : Artistic or GPL-1+ Programming Lang: Perl Description : experimental XS implementation of Future Future::XS provides an XS-based implementation of the Future class. It is currently experimental and shipped in its own distribution for testing purposes, though once it seems stable the plan is to move it into the main Future distribution and load it automatically in favour of the pureperl implementation on supported systems. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#1036727: ITP: libfuture-queue-perl -- FIFO queue of values that uses Futures
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libfuture-queue-perl Version : 0.51 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Future-Queue * License : Artistic or GPL-1+ Programming Lang: Perl Description : FIFO queue of values that uses Futures Objects in this class provide a simple FIFO queue the stores arbitrary perl values. Values may be added into the queue using the push method, and retrieved from it using the shift method. Values may be stored within the queue object for shift to retrieve later, or if the queue is empty then the future that shift returns will be completed once an item becomes available. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
future of rwhod/rwho/ruptime, and a shell implementation of it called ruptime
hello i've always liked the ruptime command, it was so useful to see your machines up or down, and for long and with what load, but then came multiprocessor machines, and gpus. and it was all clear text sent over the network, and only in one network. so i started to try to do something about and out came: https://github.com/alexmyczko/ruptime/tree/debian (or on salsa: https://salsa.debian.org/debian/ruptime). i have tried to make it useful for where i use it, you can read the why on the webpage or salsa page. (using it on x86_64, and raspberry pies) rwho was not implemented, but it would be easy to do so. and it's also easy to extend it for any sort of data that you want to be easily accessible. since there's that older implementation in C: netkit-rwho is orphaned, https://bugs.debian.org/1020628 build time limit for NUSERS (1000): https://bugs.debian.org/489787 build time option for alarm period: https://bugs.debian.org/360884 these are all much easier in the script, but it is much less efficient. any feedback if this is a good idea, or wishes? according popcon there's some users: https://qa.debian.org/popcon.php?package=netkit-rwho (glad i'm not alone) best tar
Re: #932957 Please migrate Release Notes to reStructuredText
On 2023-05-24 19:40:56 +0200 (+0200), Agathe Porte wrote: [...] > Maybe the idea was to introduce %OLD_RELEASE_NAME% and to call sed to > replace this kind of strings in a build step, and not rely on sphinx > substitution at all. > > I know that I have done this a few times and it works fine as a very > simple preprocessor. Similar things can be done at sphinx-build time with a custom Sphinx extension (can be a trivial Python module). We do that for the published security advisories list upstream in OpenStack: https://opendev.org/openstack/ossa/src/commit/136b24c/doc/source/conf.py#L31 https://opendev.org/openstack/ossa/src/commit/136b24c/doc/source/_exts/vmt.py That's a more complex example because we generate a ton of content out of structured data (YAML) files by splatting the relevant fields into substitutions in a Jinja2 template, but for basic string substitution you could get away with something far simpler, or even use a canned one like (this was simply my first web search result): https://pypi.org/project/Sphinx-Substitution-Extensions/ The examples in its readme look to be along the lines of the Debian Release Notes use case anyway. There's also basic substitutions support in the reStructuredText specification, which might be useful to reduce the amount of actual content you need to swap at build time: https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#substitution-definitions -- Jeremy Stanley signature.asc Description: PGP signature
Re: #932957 Please migrate Release Notes to reStructuredText
Hi, 2023-05-20 23:36 CEST, Holger Wansing: > Hi, > > RL wrote (Sat, 20 May 2023 12:52:25 > +0100): > > Holger Wansing writes: > > > > > However, I may have some objections against the migration at all: > > > as far as I know, sphinx/reStructuredText is still lacking some > > > functionality, > > > which is heavily used in the release-notes. > > > That is the use of substitutions within URLs. > > > In docbook speach these were entities, and you could use them in URLs > > > like this: > > > > > > Please follow the instructions in the > > > > > url="https://www.debian.org/releases/&oldreleasename;/releasenotes";>Release > > > Notes for &debian; &oldrelease; to upgrade to &debian; > > > &oldrelease; first if needed. > > > > > > Please note the &oldreleasename; in the URL! > > > I could not get this working with sphinx (if someone knows better, please > > > contact me!) > > > > No idea about sphinx, but we could we just run a simple sed script to update > > That will not work. > You cannot replace all 'bullseye' by 'bookworm' for example. > There are places, where the 'bullseye' needs to stay. > So that needs to be done selective one-by-one. Maybe the idea was to introduce %OLD_RELEASE_NAME% and to call sed to replace this kind of strings in a build step, and not rely on sphinx substitution at all. I know that I have done this a few times and it works fine as a very simple preprocessor.
