Bug#908150: ITP: gnucap-python -- Python bindings for the GNU circuit analysis package
Package: wnpp Severity: wishlist Owner: Felix Salfelder * Package name: gnucap-python Version : 0.0.0 Upstream Authors: Felix Salfelder , Henrik Johansson (-2009?) * URL : http://gnucap.org/dokuwiki/doku.php/gnucap:user:gnucap_python * License : GPLv3 Programming Lang: C++, Python, Swig Description : Python bindings and command plugin for the GNU circuit analysis package This package implements Python bindings for the Gnucap library. It provides a Gnucap command plugin that runs Python scripts and loads extensions written in the Python language. . 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. > [..] also include as much relevant information as possible. > - why is this package useful/relevant? >is it a dependency for another package? do you use it? This package provides glue between a circuit simulator (Gnucap) and a general purpose command interpreter (Python). I use it for teaching, plotting and optimisation. > - if there are other packages, how does it compare? There are other cicuit simulators, but they are all limited in their own ways, essentially ngspice. None of them provides python bindings. > - How do you plan to maintain it? [..] do you need a sponsor? Will be team-maintained within the electronics team. Ruben Undheim (DD) has offered sponsorship. > Reasons why a new package might get rejected nevertheless > Especially if the archive already contains analogous packages, > following reasons might be presented >The software is very immature (version 0.1-alpha or something like that). This is the first release with a low version number, not 100% complete but usable. The implementation aligns to Gnucap architecture, which is has evolved within the last 30 years, aiming at high quality and stability. Further development of this package will mostly add things, not change much of it. > It's a simple script or very small program, and should be merged > (either upstream or downstream) with another package. Gnucap will always be modular. There are no plans to merge any of the parts, especially not those with third party dependencies (such as Python). thanks
Bug#714836: qucsator release
Dear all. We have released qucsator-0.0.20 [1]. It has been part of qucs, but it is also being used without qucs. It will also work in combination with any statically linked (qt3, non-debian) build of qucs or some of its forks. I think it will be good to have qucsator in Debian. Please consider packageing it e.g. within the electronics team [2]. The qucs qt5 implementation is progressing, and it will still support qucsator as a simulator backend. cheers felix [1] https://sourceforge.net/projects/qucs/files/qucs/0.0.20/qucsator-0.0.20.tar.gz [2] https://salsa.debian.org/electronics-team
Bug#950198: RFH: ring -- Secure and distributed voice, video and chat platform
On Wed, Jan 29, 2020 at 08:36:07PM -0500, Alexandre Viau wrote: > I would love to update Jami[1] (https://jami.net) in Debian. I have prepared some preliminary packages [0,1,2,3]. It seems to run without a lot of patching, but pjp. I'm afraid there is more work to do... cheers/hth felix [0] https://salsa.debian.org/felixs-guest/restinio(0.6.4) [1] https://salsa.debian.org/felixs-guest/opendht (2.0.0rc2) [2] https://salsa.debian.org/felixs-guest/http-parser (2.9.3) [3] https://salsa.debian.org/felixs-guest/ring(20200316) signature.asc Description: PGP signature
Bug#950198: RFH: ring -- Secure and distributed voice, video and chat platform
Dear Alexandre. > It looks like you are trying to do many things at once. > > Instead of trying to fix everything in one go, I would suggest that we > pick one problem and move from there. Thanks for your feedback. I tried to update my Jami installation, when connections to newer Jami clients broke down, unfortunately. The fresh version is working for me. > How about we start by packaging restinio in Debian? I'd gladly sponsor > such an upload. I can see an upper bound to the efforts required to update Jami. The restinio package is not my primary interest. But will try to allocate some time for it [1]. Afaiu, the bottleneck will be opendht. opendht is already packaged, but too old. The required version is unreleased (2.0.0rc2). What does it take to have a release candidate in Debian? best regards felix [1] https://salsa.debian.org/felixs-guest/restinio
Bug#950198: RFH: ring -- Secure and distributed voice, video and chat platform
On Mon, Mar 23, 2020 at 11:27:25AM -0400, Alexandre Viau wrote: > No, it won't. Why would it be a bottleneck? Well. If it's not, that is only better. > We need to package restinio. This is the first step. Nothing else. I pushed the package to mentors (using dput). I was expecting it to show up [1] at some point. Either way, feel free to grab it from salsa. It's ready to upload as I can get right now. cheers felix [1] https://mentors.debian.net/packages/index
Bug#950198: RFH: ring -- Secure and distributed voice, video and chat platform
> restinio [..] some progress [1]. thanks felix [1] https://mentors.debian.net/package/restinio
Bug#950198: RFH: ring -- Secure and distributed voice, video and chat platform
On Sat, Apr 04, 2020 at 04:25:05PM -0400, Alexandre Viau wrote: > If you feel like you have a working package, would you please link me > to a git repository on salsa that I can review? Dear Alexandre. It's working afaict. Not fully complete -- minor details i would hope. See my namespace on salsa [1], please move it to a more appropriate place, if it makes sense to you. > As a reviewer, I don't find mentors.d.o very useful but feel free to > use it if you think its appropriate for you. I only meant put the package on display there, I prefer plain git for anything else. cheers felix [1] https://salsa.debian.org/felixs-guest/restinio/
Bug#950198: restinio
On Mon, Apr 27, 2020 at 09:07:36AM +0200, Sébastien Delafond wrote:
> I've pushed my version of restinio's packaging to
> [..]
> Let me know if you want me to upload what I've got now to NEW.
amazing. thank you.
> So we don't forget, here are a couple of items we'll want to fix later
> on:
>
> - salsa-ci
>
> - open an issue upstream to integrate my two cmake patches for the
> scenario "build a release without shipping binaries, yet
> insist on running the tests during our build"
I will see what I can do about these.
Something else that might need work.
The freshly imported tarball (0.6.6) contains an embedded dev/asio
directory, which does not exist in the upstream repository, nor was it
in the 0.6.4 tarball. I understand that this copy is unnecessary. But
some test is compiled with -I${top_srcdir}/dev/asio/include.
The embedded asio does not coincide with libasio-dev in sid, 1:1.12.2-1.
Imo (and I am certainly clueless here) this may lead to questionable
test results. Technically, We may need to depend on a specific
libasio-dev.
cheers
felix
Bug#950198: restinio
Please apologise the flood, I missed something obvious.
On Mon, Apr 27, 2020 at 11:02:23AM +0200, Felix Salfelder wrote:
> The freshly imported tarball (0.6.6) contains an embedded dev/asio
> directory, which does not exist in the upstream repository, nor was it
> in the 0.6.4 tarball. I understand that this copy is unnecessary. But
> some test is compiled with -I${top_srcdir}/dev/asio/include.
The source of this is, upstream is offering multiple tarballs, one with
third party packages included. This also explains some of Sébastiens
additions to the copyright file.
As of version 0.6.4, none of the additional headers were required for
either for building opendht or jami. I have imported the smaller
tarball and rebased Sébastiens commits. It's in my master branch now
[1].
I'm afraid the package does no longer build, and I am unsure how to
proceed. My gut feeling is that the small tarball is the correct one,
(although I can see the other one listed in d/watch), and that the tests
should be compiled against installed packages, if at all.
thanks
felix
[1] https://salsa.debian.org/felixs-guest/restinio/master
Bug#950198: restinio
Thanks Sébastien for your analysis. On Mon, Apr 27, 2020 at 12:10:35PM +0200, Sébastien Delafond wrote: > Before you go ahead on any of this, please let's wait for Alexandre's > input. I agree. > I am unsure where your gut feeling comes from: the smaller package is OK > to simply use as an include in a development project. OTOH when building > the Debian package, we're definitely interested in running the > upstream-provided unit tests during a regular build. My gut feeling.. let me try and explain. First of all, there is no technical requirement for release tarballs of different sizes. The friction is most obvious in the copyright file. But also distributing stuff that is packaged elsewhere is against the packaging guidelines [1] in a similar context (repacking). """ 6.7.8.2.2 [the package] should not contain any file that does not come from the upstream author(s). """ Then, I do not believe that source files "come from upstream" authors just because they inadvertendly bundle third party work into some kind of "convenience" tarball. Beyond belief, the package (as I did it) is in fact based on the upstream git repo, so this is where "upstream" comes from. And I am in good society doing it that way [2]. """ There is absolutely no technical reason to not use the upstream git repository as the basis for the git repository used in Debian packaging. I would never package software maintained in a git repository upstream and not do so. """ I hope it is more clear now, how I prefer to use the small tarball over running the tests, as a matter of principle. The tests can be added later, once it will be practical, e.g. with a patch, and maybe some other dependencies packaged. regards felix [1] https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html [2] http://joeyh.name/blog/entry/upstream_git_repositories/
Bug#950198: restinio
On Mon, Apr 27, 2020 at 01:22:29PM +0200, Sébastien Delafond wrote: > It was perfectly clear the first time, and this is where we can agree to > disagree. Dear Sébastien. Yes, lets agree. > Starting on this project I had a couple of goals. Towards the original goal (getting Jami into Debian), I have reworded the cmake patch description and improved the package based on your proposed changes. - cleanup rules, add the MULTIARCH bit - more on d/copyright - cmake dependency - d/watch > As I don't intend to maintain restinio in the long run, I don't feel the > need to argue this any further, and will happily defer to Alexandre's > opinion. I acknowledge that running the tests is of importance to you. I will certainly take that into consideration. To proceed, we need restinio in NEW. If you (or anybody else follwing this conversation) wishes to help, please review and/or sponsor [1]. Looking at Alexandre's Jami package, I infer that small(er) tarballs are in his interest. I do not actually know, and if it helps, I am not going to decide how the 0.6.6 package will look like. best regards felix [1] https://salsa.debian.org/felixs-guest/restinio/-/tree/master-0.6.4
Bug#950198: restinio
On Fri, May 15, 2020 at 11:30:03AM +0200, Petter Reinholdtsen wrote: > [Alexandre Viau] > > The next step would now be to update OpenDHT, which should be quick > > once restinio passes new. > > The restinio package was just accepted into unstable. I am half way through opendht [1]. My package lacks testing (just imported new upstream 2.1.1). I will continue as time permits, but feel free to help. cheers felix [1] https://salsa.debian.org/felixs-guest/opendht
Bug#1036739: ITP: gnucap-modelgen-verilog -- Verilog-AMS behavioural modelling for Gnucap
Package: wnpp Severity: wishlist Owner: Felix Salfelder X-Debbugs-Cc: debian-de...@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.
Bug#920449: ITP: gnucap-custom -- gnucap-custom provides a basis for customisation of the GNU circuit analysis package
Package: wnpp Severity: wishlist Owner: Felix Salfelder * Package name: gnucap-custom Version : 0.0.1 Upstream Author : Felix Salfelder * URL : https://gitlab.com/gnucap/gnucap-custom * License : GPLv3+ Programming Lang: C++ Description : A basis for Gnucap customisation Gnucap-custom provides a customisable executable for Gnucap, the GNU circuit analysis package. It includes plugins improving readline support, input processing, module loading and some tweaks. The package provides the makefiles and loader used by gnucap-adms, which aids compiling behavioural models. I intend to maintain the package inside the pkg-electronics packageing team.
