Bug#1055342: RFA: kas -- Setup tool for bitbake based projects
Hi Bastian, yesterday kas 4.3 was released. I just adapted the packaging and uploaded it to mentors [1]. Please check: [1] https://mentors.debian.net/package/kas/ Best regards, Felix -- Siemens AG, Technology Linux Expert Center
Bug#1055342: RFA: kas -- Setup tool for bitbake based projects
Hi, I would be willing to continue the maintenance of this package, together with the debian python team. I'm quite familiar with this component, as I contributed a lot to the upstream project. Currently I have to maintain this via a sponsor, but once I get advocated to a DM, I can also maintain it directly. Best regards, Felix Moessbauer -- Siemens AG, Technology Linux Expert Center
Bug#1063327: ITP: librtpi -- realtime capable pthread locking primitives
Package: wnpp Severity: wishlist Owner: Felix Moessbauer X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: librtpi Version : 1.0.0 Upstream Contact: Gratian Crisan * URL : https://gitlab.com/linux-rt/librtpi/ * License : LGPL Programming Lang: C, C++ Description : realtime capable pthread locking primitives The Real-Time Priority Inheritance Library (librtpi) is intended to bridge the gap between the glibc pthread implementation and a functionally correct priority inheritance for pthread locking primitives, such as pthread_mutex and pthread_condvar. Specifically, priority based wakeup is required for correct operation, in contrast to the more time-based ordered wakeup groups in the glibc pthread condvar implementation. Why is this needed: This library is needed to implement realtime capable waiting on condition variables, due to glibc bug 11588 [1] which will not be fixed. Who will maintain it: I'm not yet a Debian maintainer, so a co-maintainer / sponsor will be needed anyways. In general, it would be good if this package could be maintained by a team. The expected effort is pretty low, as the library is easy to package. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=11588 Best regards, Felix Moessbauer Siemens AG
Bug#1058962: O: speedcrunch -- High precision calculator
Package: wnpp Severity: normal For personal reasons I am orphaning the speedcrunch package. The broken package that caused speedcrunch's removal from testing, python3-quark-sphinx-theme, is currently broken because of a Sphinx update. I was also maintaining the upstream of that package and packaged it as a build dependency for speedcrunch, but won't be maintaining it any more either. I have proposed to add the relevant bits directly into the speedcrunch repo so they can be maintained there at least: https://bitbucket.org/heldercorreia/speedcrunch/pull-requests/125 FWIW I'm sorry to leave speedcrunch broken like that, but evidently not sorry enough to do something about it at this point. Description: High precision calculator SpeedCrunch is a high precision and high speed calculator. . It's optimized for keyboard use and has advanced features: use of functions, use of variables, result history, and syntax highlighting. It also shows the result as you type. . SpeedCrunch has a very simple interface, so you can start to use it very quickly.
Bug#1041509: ITP: gitui -- blazing fast terminal-ui for git
Package: wnpp Severity: wishlist Owner: Johann Felix Soden X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : gitui Version : 0.23.0 Upstream Contact: extrawurst * URL : https://github.com/extrawurst/gitui * License : MIT Programming Lang: Rust Description : blazing fast terminal-ui for git gitui is a blazing fast terminal-ui for git with following features: - Fast and intuitive keyboard only control - Context based help (no need to memorize tons of hot-keys) - Inspect, commit, and amend changes - Stage, unstage, revert and reset files, hunks and lines - Stashing (save, pop, apply, drop, and inspect) - Push/Fetch to/from remote - Branch List (create, rename, delete, checkout, remotes) - Browse commit log, diff committed changes - Scalable terminal UI layout - Async git API for fluid control - Submodule support
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#1026318: O: freeplane -- Java program for working with Mind Maps
Package: wnpp Severity: normal Control: affects -1 src:freeplane Since I couldn't find a co-maintainer since 2021 [1], I intend to orphan the freeplane package. Freeplane is a popular and powerful mindmapping tool written in java. There are quite many users, but also some challenges for the packaging of newer versions. I offer mentorship to any new freeplane maintainer in the onboarding phase :-) If you have any questions, let me know. [1] https://lists.debian.org/debian-java/2021/08/msg6.html The package description is: Freeplane is a free and open source software application that supports thinking, sharing information and getting things done at work, in school and at home. The core of the software is tools for mind mapping (also known as concept mapping or information mapping) and using mapped information. . Occupying the middle ground between an editor and a diagramming tool, Freeplane allows the user to add content as quickly and naturally as they would in a text editor, yet producing structured content that can be manipulated as easily as a diagram. . Features include ordering ideas in nodes and freely positionable nodes, connecting nodes, automatic/conditional styles, scripting, add-ons, LaTeX, search/filtering, different export features, printing, password protection of nodes/maps and more. . See http://freeplane.sourceforge.net/wiki/index.php/Main_Page for a full list of applications and features. Best Regards, -- Felix Natter
Bug#1012761: ITP: shtab -- generator for shell tab completion files for python projects
Hi Stephan, Thanks for the review. I changed the name of the package, renamed the project on salsa and cut the release. This one should be ready to be uploaded. PS: Looks like the repology site currently has some TLS issues. Happy Coding! Felix From: Stephan Lachnit Sent: Sunday, July 3, 2022 11:35 AM To: Moessbauer, Felix (T CED SES-DE) Cc: 1012...@bugs.debian.org Subject: Re: ITP: shtab -- generator for shell tab completion files for python projects Hi Felix, The package is looking good so far, I only request one change, namely renaming the source package from shtab to python-shtab. The reason for this prefix is that else repology.org<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frepology.org%2F=05%7C01%7Cfelix.moessbauer%40siemens.com%7C4fc331a448bf41d9ddef08da5cd74b31%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637924377004473576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=LzOv7h88VjrbLZ6L%2B32Jc0CL8PIM4xCNU68LQAWJeC8%3D=0> won't be able to map the package automatically. Cheers, Stephan On Wed, Jun 22, 2022 at 9:25 PM Stephan Lachnit mailto:stephanlach...@debian.org>> wrote: Hi Felix, I will take a look at the package sometime next week. I'm currently packing my stuff to move to Geneva, so I don't really have that much time right now. Feel free to ping though in case I forget :) Cheers, Stephan On Tue, Jun 21, 2022 at 4:30 PM Moessbauer, Felix mailto:felix.moessba...@siemens.com>> wrote: Dear maintainers, the initial packaging of shtab is implemented in [1] and should be ready for a review. @stephan It would be great if you could sponsor this package. We talked about that at Debian Reunion Hamburg. [1] https://salsa.debian.org/python-team/packages/shtab<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fpython-team%2Fpackages%2Fshtab=05%7C01%7Cfelix.moessbauer%40siemens.com%7C4fc331a448bf41d9ddef08da5cd74b31%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637924377004473576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=IJNiSmE%2BPaFs4RfhI9SftWKZkaL2lD4StdeaDTXO6iE%3D=0> Best regards, Felix Moessbauer Siemens AG
Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
Hi Stephan, Thanks for the review. I changed the name of the package, renamed the project on salsa and cut the release. This one should be ready to be uploaded. Happy Coding! Felix From: Stephan Lachnit Sent: Sunday, July 3, 2022 11:43 AM To: Moessbauer, Felix (T CED SES-DE) Cc: 1013...@bugs.debian.org Subject: Re: Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java Hi Felix, Looking good as well. Please also rename the source to python-airspeed and do a dch -r, then I'll upload. Cheers, Stephan On Thu, Jun 30, 2022 at 9:19 AM Stephan Lachnit mailto:stephanlach...@debian.org>> wrote: Hi Felix, If there is nobody else, I can sponsor this as well. Will try to find some time on Sunday to review your work :) Cheers, Stephan On Wed, Jun 29, 2022 at 4:53 PM Moessbauer, Felix mailto:felix.moessba...@siemens.com>> wrote: Dear maintainers, the initial packaging for python3-airspeed is now ready at [1] and has a green salsa CI. It should be ready for a review. @Stephan: Would you like to sponsor this package as well? [1] https://salsa.debian.org/python-team/packages/airspeed<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fpython-team%2Fpackages%2Fairspeed=05%7C01%7Cfelix.moessbauer%40siemens.com%7C12c8e91803f2425eac3408da5cd8728d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637924381944910507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=hIHf6BGVN6PYFT%2FBhgmHAl5ksLaKuKxjMC%2BPTfYIOoA%3D=0> Best regards, Felix Moessbauer Siemens AG
Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
Dear maintainers, the initial packaging for python3-airspeed is now ready at [1] and has a green salsa CI. It should be ready for a review. @Stephan: Would you like to sponsor this package as well? [1] https://salsa.debian.org/python-team/packages/airspeed Best regards, Felix Moessbauer Siemens AG
Bug#1013425: ITP: airspeed -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
Of course the ITP is for the python airspeed package, not for wnpp. Sorry for the noise. * Package name: airspeed Version : 0.5.19 Upstream Author : Steve Purcell mailto:st...@pythonconsulting.com>> * URL : https://github.com/purcell/airspeed * License : BSD-2-Clause Programming Lang: Python Description : Airspeed is a powerful and easy-to-use templating engine for Python that aims for a high level of compatibility with the popular Velocity library for Java. Best regards, Felix
Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
Package: wnpp Severity: wishlist Owner: Felix Moessbauer X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: wnpp Version : 0.5.19 Upstream Author : Steve Purcell * URL : https://github.com/purcell/airspeed * License : BSD-2-Clause Programming Lang: Python Description : Airspeed is a powerful and easy-to-use templating engine for Python that aims for a high level of compatibility with the popular Velocity library for Java. According to my knowledge this project is currently the only that supports velocity templates and especially version velocity version 1.7. My intent is to package this software under the umbrealla of the Debian Python team. Felix Moessbauer Siemens AG
Bug#1012761: ITP: shtab -- generator for shell tab completion files for python projects
Dear maintainers, the initial packaging of shtab is implemented in [1] and should be ready for a review. @stephan It would be great if you could sponsor this package. We talked about that at Debian Reunion Hamburg. [1] https://salsa.debian.org/python-team/packages/shtab Best regards, Felix Moessbauer Siemens AG
Bug#1012761: ITP: shtab -- generator for shell tab completion files for python projects
Package: wnpp Severity: wishlist Owner: Felix Moessbauer X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: shtab Version : 1.5.4 Upstream Author : Casper da Costa-Luis * URL : https://github.com/iterative/shtab * License : Apache-2.0 Programming Lang: Python Description : generator for shell tab completion files for python projects CLI tool and library to auto-generate tab completion files for bash, zsh and tcsh from python argparse definitions. This package should replace the custom packaging of shtab as part of the CIP project [1]. My intent is to package this software under the umbrella of the Debian Python team. [1] https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tree/master/recipes-python/shtab
Bug#1009988: O: postgresql-semver -- Semantic version number type for PostgreSQL
Package: wnpp Severity: normal Hi, This Postgres data type was used for the most recent Lintian website. Kind regards, Felix Lechner
Bug#1009983: O: mdadm -- Tool to administer Linux MD arrays (software RAID)
Package: wnpp Severity: normal Hi, This is an exciting opportunity to assume maintenance of an important package. It is now available for your adoption! Kind regards, Felix Lechner
Bug#1009982: O: pius -- Tools to help before and after key-signing parties
Package: wnpp Severity: normal Hi, This package is low maintenance and now available for your adoption! Kind regards, Felix Lechner
Bug#1009980: O: wxedid -- Graphical editor for monitor resolution and timing data (EDID)
Package: wnpp Severity: normal Hi, This package is low maintenance and now available for your adoption! You can use this software when repairing your monitor's EDID. [1] Kind regards, Felix Lechner [1] https://wiki.debian.org/RepairEDID
Bug#1009978: O: gammastep -- Adjust display hue to outside lighting conditions
Package: wnpp Severity: normal Hi, This package is low maintenance and now available for your adoption! Kind regards, Felix Lechner
Bug#1009975: O: libgsm -- Shared libraries for GSM speech compressor
Package: wnpp Severity: normal Hi, This package is low maintenance and now available for your adoption! Kind regards, Felix Lechner
Bug#1006866: ITP: hackage-tracker -- Haskell package version tracker
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-hask...@lists.debian.org X-Debbugs-Cc: Joachim Breitner * Package name: hackage-tracker Version : 0.1.0 Upstream Author : Felix Lechner * URL : https://salsa.debian.org/haskell-team/hackage-tracker * License : AGPL-3.0-or-later Programming Lang: Haskell2010 Description : Haskell package version tracker Generates a file with information that can be used to update the Debian versions on Hackage for each package available there. Those versions appear in the Distribution field on Hackage. Furthermore produces an HTML page that compares the Haskell package versions available in Debian with those available on Hackage and elsewhere. The data is currently displayed at https://hackage-tracker.debian.net. This software falls under the Haskell team's umbrella and will be updated, managed and serviced going forward by members of the Haskell team.
Bug#1003751: In NEW queue
The sources were uploaded and are now in the NEW queue.
Bug#1003751: ITP: kickoff -- Generalized job scheduler (with runners) for the Debian archive
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-lint-ma...@lists.debian.org * Package name: kickoff Version : 0.1.0 Upstream Author : Felix Lechner * URL : https://salsa.debian.org/lintian/kickoff * License : GPL-3.0-or-later Programming Lang: Haskell2010 Description : Generalized job scheduler (with runners) for the Debian archive This package provides a generalized job scheduler. It supports fully configurable processing actions on local copies of the Debian archive. The programs herein generate the contents of the Lintian website. This software falls under Lintian's umbrella and will be updated, managed and serviced by the Lintian maintainers.
Bug#1003582: ITP: detagtive -- Lintian web application
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-lint-ma...@lists.debian.org * Package name: detagtive Version : 0.1.0.0 Upstream Author : Felix Lechner * URL : https://salsa.debian.org/lintian/detagtive * License : AGPL-3.0-or-later Programming Lang: Haskell2010 Description : Lintian web application This package is for the Haskell rewrite of the Lintian website. The code will be transferred gradually as the site is migrated. Also ships an executable to generate the special file 'qa-list.txt', on which several important Debian services rely (tracker.d.o among them). This software falls under Lintian's umbrella and will be updated, managed and serviced by the Lintian maintainers.
Bug#1002590: ITP: wayvnc -- VNC server for wlroots-based Wayland compositors
On Fri, 24 Dec 2021 22:00:47 +0100 Johannes Schauer Marin Rodrigues wrote: > Package: wnpp > Severity: wishlist > Owner: Johannes Schauer Marin Rodrigues > X-Debbugs-Cc: debian-de...@lists.debian.org, jo...@debian.org > > * Package name : wayvnc > Version : 0.4.1 > Upstream Author : Andri Yngvason > * URL : https://github.com/any1/wayvnc > * License : ISC > Programming Lang: C > Description : VNC server for wlroots-based Wayland compositors > > This is a VNC server for wlroots-based Wayland compositors. It attaches > to a running Wayland session, creates virtual input devices, and exposes > a single display via the RFB protocol. The Wayland session may be a > headless one, so it is also possible to run wayvnc without a physical > display attached. > > Hi, there is already a PR on the wayvnc project with a working debianzation [1]. The author of [1] also added debianizations for aml [2] and neatvnc [3] which are dependencies. Don't know if we need dedicated ITPs for them as well. Felix! [1] https://github.com/any1/wayvnc/pull/116 [2] https://github.com/any1/aml/pull/7 [3] https://github.com/any1/neatvnc/pull/61
Bug#1002466: emacs-lintian: Renamed the source package
Hi, Pursuant to a suggestion from the Emacs maintainers (thank you!) the source package was renamed to emacs-lintian and resubmitted to the FTP Masters. The path on Salsa also changed: https://salsa.debian.org/lintian/emacs-lintian Kind regards Felix Lechner
Bug#1002466: ITP: elpa-lintian -- Examine Lintian packaging hints in Emacs
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-emac...@lists.debian.org * Package name: elpa-lintian Version : 0.1 Upstream Author : Felix Lechner * URL : https://salsa.debian.org/lintian/elpa-lintian * License : GPL-3+ Programming Lang: Lisp Description : Examine Lintian packaging hints in Emacs This package provides a command to run Lintian in Emacs. The purpose is to provide extra functionality when examining the resulting packaging hints. A preliminary version may be found in the Lintian source tree. [1] Going forward, I hope to maintain the software jointly as a member of the Lintian Maintainers Team. [1] https://salsa.debian.org/lintian/lintian/-/blob/master/integration/emacs/lintian.el
Bug#1002296: dh-haskell: Version 0.5 is now in NEW
Control: tags -1 + pending Hi, Version 0.5 of dh-haskell was uploaded to the NEW queue. [1] Kind regards Felix Lechner [1] https://ftp-master.debian.org/new/dh-haskell_0.5.html
Bug#1002296: ITP: dh-haskell -- Debhelper build system for cabal-based Haskell packages
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-hask...@lists.debian.org * Package name: dh-haskell Version : 0.5 Upstream Author : Felix Lechner * URL : https://salsa.debian.org/lechner/dh-haskell * License : GPL-3+ Programming Lang: Perl Description : Debhelper build system for cabal-based Haskell packages Version 0.4 was dropped from unstable on 2018-11-04 at the author's request in #912000. While the software seemed not useful then, the dh sequencer is now the dominant build system. [1] This version is a simple, but complete rewrite based on /usr/share/cdbs/1/class/hlibrary.mk. It was tested with a Haskell executable that is not in the archive, but not yet with any libraries or documentation. Further adaptation may be required. Going forward, I would like to maintain the software, potentially jointly, as a prospective member of the Haskell Group! [1] https://trends.debian.net/#build-systems
Bug#998697: ITP: bees -- a btrfs deduplication agent
Am Samstag, dem 06.11.2021 um 21:32 +0300 schrieb Alexander GQ Gerasiov: > Package: wnpp > Severity: wishlist > Owner: Alexander GQ Gerasiov > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name : bees > Version : 0.7 > Upstream Author : Zygo Blaxell b...@furryterror.org > * URL : https://github.com/Zygo/bees > * License : GPL-3+ > Programming Lang: C++ > Description : a btrfs deduplication agent > > Best-Effort Extent-Same, a btrfs deduplication agent. > > bees is a block-oriented userspace deduplication agent designed for > large > btrfs filesystems. It is an offline dedupe combined with an > incremental data > scan capability to minimize time data spends on disk from write to > dedupe. > Hi Alexander, I totally forgot to look if there's already an ITP filed when I did my one #1002036. How far are you with packaging? And do you want a Co-Maintainer? Though I'm only a DM not DD. I just did a first version of a Debian package avaible at: https://salsa.debian.org/fzielcke/bees/ Feel free to use anything of it. Regards, Felix
Bug#1002036: ITP: bees -- Best-Effort Extent-Same, a btrfs deduplication agent.
Package: wnpp Severity: wishlist Owner: Felix Zielcke X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: bees Version : 0.7 Upstream Author : Zygo Blaxell b...@furryterror.org * URL : https://github.com/Zygo/bees * License : GPL-3+ Programming Lang: C++ Description : Best-Effort Extent-Same, a btrfs deduplication agent. bees is a block-oriented userspace deduplication agent designed for large btrfs filesystems. It is an offline dedupe combined with an incremental data scan capability to minimize time data spends on disk from write to dedupe. I'm happy to maintain it inside a team or with co-maintainer(s). I'm only DM so if someone has interest in sponsoring this, feel free to contact me. First debianized version avaible at https://salsa.debian.org/fzielcke/bees I guess it's a problem for ftp-masters that copyright and license is only mentioned inside README.md, but not directly at the source files? Then it can't yet be uploaded.
Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements
Hi, On Mon, Dec 6, 2021 at 12:44 PM gregor herrmann wrote: > > It's already in NEW (and the other requested package as well). Thank you for your prompt assistance! Lintian provides backports to stable (and some users run it in even more adventurous ways). Is it acceptable for the Lintian maintainers to upload backports of the new packages, or would the Perl team rather handle them via bug reports? I would prefer if the Perl team handled backports as well, but it would be an extra burden. Please just let me know one way or the other. Thanks! Kind regards Felix Lechner
Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements
Hi, On Mon, Dec 6, 2021 at 10:48 AM gregor herrmann wrote: > > I have no good idea how to handle it right now. Thank you for having a look! For Lintian, the functionality of Sub::StrictDecl is probably enough. I requested it separately (and you already assumed ownership). [1] Thank you! Kind regards, Felix Lechner [1] https://bugs.debian.org/1001175
Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements
Hi, On Sun, Dec 5, 2021 at 12:08 PM gregor herrmann wrote: > > (Just as a note, and that means I won't upload this tonight :)) Thank you for looking into it! Kind regards, Felix Lechner
Bug#1001178: RFP: liblib-relative-perl -- In Perl scripts, Add paths relative to the current file to @INC
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-p...@lists.debian.org * Package name: liblib-relative-perl Version : 1.000 Upstream Author : Dan Book * URL : https://metacpan.org/pod/lib::relative * License : Artistic-2.0 Programming Lang: Perl Description : In Perl scripts, Add paths relative to the current file to @INC Adding a path to @INC to load modules from a local directory may seem simple, but has a few common pitfalls to be aware of: Directly adding a relative path to @INC means that any later code that changes the current working directory will change where modules are loaded from. This applies to the . path that used to be in @INC by default until perl 5.26.0, or a relative path added in code like use lib 'path/to/lib', and may be a vulnerability if such a location is not supposed to be writable. Additionally, the commonly used FindBin module relies on interpreter state and the path to the original script invoked by the perl interpreter, sometimes requiring workarounds in uncommon cases like generated or embedded code. This module proposes a more straightforward method: take a path relative to the current file, absolutize it, and add it to @INC. The more straightforward name librelative-perl was already taken. [1] Perhaps the name proposed here is better for consistency, even though it looks awkward. Lintian presently uses a series of tedious work-arounds to get the same functionality. [2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17] Thanks! Kind regards, Felix Lechner [1] https://tracker.debian.org/pkg/librelative-perl [2] https://salsa.debian.org/lintian/lintian/-/blob/master/bin/lintian#L30-38 [3] https://salsa.debian.org/lintian/lintian/-/blob/master/bin/lintian-annotate-hints#L30-38 [4] https://salsa.debian.org/lintian/lintian/-/blob/master/bin/lintian-explain-tags#L30-38 [5] https://salsa.debian.org/lintian/lintian/-/blob/master/bin/spellintian#L28-37 [6] https://salsa.debian.org/lintian/lintian/-/blob/master/private/generate-tag-summary#L9-18 [7] https://salsa.debian.org/lintian/lintian/-/blob/master/private/hintadjust#L31-40 [8] https://salsa.debian.org/lintian/lintian/-/blob/master/private/hintdiff#L31-40 [9] https://salsa.debian.org/lintian/lintian/-/blob/master/private/hintextract#L31-39 [10] https://salsa.debian.org/lintian/lintian/-/blob/master/private/hintsort#L31-40 [11] https://salsa.debian.org/lintian/lintian/-/blob/master/private/latest-policy-version#L31-40 [12] https://salsa.debian.org/lintian/lintian/-/blob/master/private/refresh-data#L27-35 [13] https://salsa.debian.org/lintian/lintian/-/blob/master/private/refresh-locale-codes#L26-35 [14] https://salsa.debian.org/lintian/lintian/-/blob/master/private/refresh-manual-refs#L32-41 [15] https://salsa.debian.org/lintian/lintian/-/blob/master/private/runtests#L36-44 [16] https://salsa.debian.org/lintian/lintian/-/blob/master/private/tag-stats#L17-26 [17] https://salsa.debian.org/lintian/lintian/-/blob/master/private/generate-profiles#L10-18
Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-p...@lists.debian.org * Package name: perlimports Version : 0.27 Upstream Author : Olaf Alders * URL : https://metacpan.org/pod/App::perlimports * License : Artistic Programming Lang: Perl Description : Automate maintenance of Perl import statements This distribution provides the perlimports command line interface (CLI), which automates the cleanup and maintenance of Perl use and require statements. Loosely inspired by goimports, this tool aims to be part of your linting and tidying workflow, in much the same way you might use perltidy or perlcritic. For a detailed discussion of the problems this tool attempts to solve, see this "Conference in the Cloud" talk from June 2021: Where did that Symbol Come From? [1] Lintian would like to use the functionality to protect against missing imports in rarely used code paths during parallel execution. [2] Thanks! Kind regards, Felix Lechner [1] https://www.youtube.com/watch?v=fKqxdTbGxYY [2] https://lists.debian.org/debian-perl/2021/11/msg00011.html
Bug#1001175: RFP: libsub-strictdecl-perl -- Detect undeclared subroutines in Perl compilation
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-p...@lists.debian.org * Package name: libsub-strictdecl-perl Version : 0.005 Upstream Author : Andrew Main (Zefram) * URL : https://metacpan.org/pod/Sub::StrictDecl * License : Artistic Programming Lang: Perl Description : Detect undeclared subroutines in Perl compilation This module provides optional checking of subroutine existence at compile time. This checking detects mistyped subroutine names and subroutines that the programmer forgot to import. Traditionally Perl does not detect these errors until runtime, so it is easy for errors to lurk in rarely-executed or untested code. Lintian would like to use the functionality to protect against missing imports in rarely used code paths during parallel execution. [1] Thanks! Kind regards, Felix Lechner [1] https://lists.debian.org/debian-perl/2021/11/msg00011.html
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Am Freitag, dem 26.11.2021 um 15:34 +0100 schrieb Stephan Lachnit: > Hi Felix, > > I was a bit more stressed this week than I hoped, I'll try to look at > it > saturday or sunday. If you don't get a reply by monday morning, feel > free > to ping me again. Hi Stephan, here's your friendly ping. Did you have time to look at pcmemtest? Regards, Felix
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Am Samstag, dem 20.11.2021 um 18:47 +0100 schrieb Stephan Lachnit: > Sounds interesting. > > On Fri, Nov 19, 2021 at 8:03 PM wrote: > > > > I'm happy to maintain it inside a team or with co-maintainer(s). > > I'm only DM so if someone has interest in sponsoring this, feel > > free to > > contact me. > > If you need me as sponsor, ping me when the package is ready for > upload. Hi Stephan, do you have time to review it? I think it's ready to upload. > Regards > Stephan
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Am Samstag, dem 20.11.2021 um 10:00 -0500 schrieb Antoine Beaupré: > Do let me know if you need a sponsor. Hi Antoine, as talked on IRC: I would be happy if you do the review (audit) of pcmemtest. Since you didn't reply back if you actually do this now: Would be good to have a clear answer here on the ITP so others know I have you as a sponsor. TIA Felix
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Hi Adam, thanks for all your comments. Am Montag, dem 22.11.2021 um 09:27 +0100 schrieb Adam Borowski: > On Sun, Nov 21, 2021 at 04:46:50PM +0100, Felix Zielcke wrote: > > Am Sonntag, dem 21.11.2021 um 10:15 -0500 schrieb Antoine Beaupré: > > > i would suggest not blocking on the grub deployment. you can > > > probably > > > just deploy whatever architecture the package was built from, in > > > any > > > case. > > > I just added now the GRUB 2 integration and a README.Debian. > > The integration isn't triggered on the package's install, but it is > picked > up the next time something else bumps grub. I forgot that grub2 isn't using triggers. Added now a postinst based on the one from memtest86+. Except that I removed the lilo parts. > > > > Note that I mention in README.Debian one nasty bug/issue: > > > > In EFI mode the keyboard only works if you have the CSM aka legacy > > boot > > also enabled: > > > > https://github.com/martinwhitaker/pcmemtest/issues/2 > > This is a nasty one. It seems most new machines lack CSM; no one wants > to > support and validate 16-bit stuff -- it's effectively expending > resources > to have two BIOSes instead of one, and the 8086 one has no practical > usage. > I opened now upstream a new issue about this: https://github.com/martinwhitaker/pcmemtest/issues/13 But in the closed one he said, it takes a while to write a usb keyboard driver for EFI. > > Upstream doestn't say anything there that this will change. Issue was > > closed with the hint it's documented. And it will just run with > > default > > settings. > > It does, but using just a single thread. There's not exactly many x86 > machines with only a single hardware thread that are still in use. > > What about defaulting to SMP when there's no user input? The UP mode > has little purpose for existing -- if concurrent accesses to memory > break, they'll also break when running the actual productive task the > machine is supposed to do. > I also made an issue for this: https://github.com/martinwhitaker/pcmemtest/issues/14 I don't know the reasons why it's not enabled by default. So I woudn't change that for the first upload to Debian on my own. > Meow! Cheers! Felix
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Am Sonntag, dem 21.11.2021 um 10:15 -0500 schrieb Antoine Beaupré: > > i would suggest not blocking on the grub deployment. you can probably > just deploy whatever architecture the package was built from, in any > case. > > a. > Hi Antoine and Stephan, I just added now the GRUB 2 integration and a README.Debian. You can now review it. And I think it would be better to first upload this to experimental? So a bit more experienced Debian users can test it first. Note that I mention in README.Debian one nasty bug/issue: In EFI mode the keyboard only works if you have the CSM aka legacy boot also enabled: https://github.com/martinwhitaker/pcmemtest/issues/2 Upstream doestn't say anything there that this will change. Issue was closed with the hint it's documented. And it will just run with default settings. Is for you my salsa repo enough or just I also upload to mentors? Git repo is in git-buildpackage format: https://salsa.debian.org/fzielcke/pcmemtest TIA Felix
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Am Samstag, dem 20.11.2021 um 10:00 -0500 schrieb Antoine Beaupré: > On 2021-11-19 19:50:45, fziel...@z-51.de wrote: > [...] > > > PCMemTest is a fork and rewrite of Memtest86+, which in turn was a > > fork of > > Memtest86. > > > > > > I'm happy to maintain it inside a team or with co-maintainer(s). > > I'm only DM so if someone has interest in sponsoring this, feel free > > to > > contact me. > > Great find! I was disappointed to find out that memtest86* is basically > unusable these days in Debian, and find this ITP to be very > interesting! > Do let me know if you need a sponsor. > > Did you test the program at all? Does it behave better than the > existing > memtest86 packages currently in Debian? > > a. Thanks for your interest :) I pushed now my first work to my personal salsa profile: https://salsa.debian.org/fzielcke/pcmemtest The files are for now in /usr/lib/pcmemtest There are 32bit and 64bit legacy BIOS + EFI files Not sure if there's actually a different between the 2 legacy BIOS versions. I haven't yet tried it myself but will do soon. The suggestion came from #btrfs IRC channel. So it can't be that bad. And I'm not sure how I want to do the GRUB integration. Due to the differences with 32bit and 64bit EFI. Is there actually a way to find out with what EFI version the system booted? Regards Felix
Bug#993076: ITP: tilemaker -- Generates vector tiles from OpenStreetMap data
Package: wnpp Severity: wishlist Owner: Felix Delattre * Package name: tilemaker Version : 2.0.0 Upstream Author : Richard Fairhurst * URL : https://github.com/systemed/tilemaker * License : FTWPL Programming Lang: C++ Description : Generates vector tiles from OpenStreetMap data tilemaker generates vector tiles without from OpenStreetMap planet and diff files without any complex stack or need for database. It uses the schema of OpenMapTiles by default, but other configuration can be provided. The package will be maintained in the Debian GIS team.
Bug#990388: ITP: jiten-nonfree-data -- non-free pitch & audio data for Jiten Japanese Dictionary
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-de...@lists.debian.org, f...@obfusk.net * Package name: jiten-nonfree-data Version : 1.1.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/jiten * License : CC-BY-NC (audio) + Wadoku.de-Daten-Lizenz (pitch) Description : non-free pitch & audio data for Jiten Japanese Dictionary Non-free data files for Jiten Japanese Dictionary. These files are optional, so the jiten and jiten-data packages should be able to go into main, whereas the jiten-audio and jiten-pitch packages go into non-free. I've already packaged it for Debian [1], but I need a sponsor and could use some advice on how best to deal with some of the remaining complaints from lintian :) Dependencies not yet in Debian: jiten [2], (transitively) kanjidraw [3]. The pitch data is licensed under the Wadoku.de-Daten-Lizenz [4]. - Felix [1] https://salsa.debian.org/obfusk/jiten-nonfree-data/-/tree/debian/sid [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990387 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988516 [4] https://www.wadoku.de/wiki/display/WAD/Wadoku.de-Daten+Lizenz
Bug#990387: ITP: jiten -- Jiten Japanese Dictionary
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-de...@lists.debian.org, f...@obfusk.net * Package name: jiten Version : 1.1.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/jiten * License : AGPLv3+ (code) + various other licenses (data) Programming Lang: Python Description : Jiten Japanese Dictionary Jiten is a Japanese dictionary based on JMDict/Kanjidic . Features: . Fine-grained search using regexes (regular expressions) * simple searches don't require knowledge of regexes * quick reference available in the web interface and android app . JMDict multilingual japanese dictionary * kanji, readings (romaji optional), meanings & more * meanings in english, dutch, german, french and/or spanish * pitch accent (from Wadoku, non-free) * browse by frequency/jlpt . Kanji dictionary * readings (romaji optional), meanings (english), jmdict entries, radicals & more * search using SKIP codes * search by radical * handwritten kanji recognition * browse by frequency/level/jlpt/SKIP . Example sentences (from Tatoeba) * with english, dutch, german, french and/or spanish translation * some with audio (non-free) . Stroke order * input a word or sentence and see how it's written . Interfaces: . Android app * wraps the web interface (running locally on your device) in a webview * completely offline, no internet access required * easily share and open jiten.obfusk.dev links * not included in this Debian package . Web interface * available online at https://jiten.obfusk.dev * light/dark mode * search history (stored locally) * tooltips to quickly see meanings and readings for kanji and words * use long press for tooltips on mobile * converts romaji to hiragana and between hiragana and katakana * can be run on your own computer . Command-line interface . WebView GUI * wraps the web interface (running locally on your computer) * requires python3-webview I'm the developer of Jiten Japanese Dictionary. I also maintain the NixOS package. The Android version is available on F-Droid. I've already packaged it for Debian [1], but I need a sponsor and could use some advice on how best to deal with some of the remaining complaints from lintian :) I'll upload a source package to mentors.debian.net after I release v1.1.0 in a few days. Dependencies not yet in Debian: kanjidraw [2]. - Felix [1] https://salsa.debian.org/obfusk/jiten/-/tree/debian/sid [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988516
Bug#988516: ITP: kanjidraw -- handwritten kanji recognition library + gui
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-de...@lists.debian.org, f...@obfusk.net * Package name: kanjidraw Version : 0.2.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/kanjidraw * License : AGPLv3+ (code) + CC-BY-SA-3.0 (data) Programming Lang: Python Description : handwritten kanji recognition library + gui kanjidraw is a simple Python library + GUI for matching (the strokes of a) handwritten kanji against its database. You can use the GUI to draw and subsequently select a kanji from the list of probable matches, which will then be copied to the clipboard. The database is based on KanjiVG and the algorithms are based on the Kanji draw Android app. I both develop and use kanjidraw. It's also a dependency for Jiten Japanese Dictionary [1], which I also want to package for Debian soon. I've already packaged it for Debian [2], but I need a sponsor :) I'll upload a source package to mentors.debian.net soon. - Felix [1] https://github.com/obfusk/jiten [2] https://salsa.debian.org/obfusk/kanjidraw/-/tree/debian/sid
Bug#986221: ITP: postgresql-semver -- Semantic version type for PostgreSQL
Package: wnpp Severity: wishlist Owner: Felix Lechner X-Debbugs-CC: Debian PostgreSQL Maintainers * Package name: postgresql-semver Version : 0.31.0 Upstream Author : David E. Wheeler * URL : https://github.com/theory/pg-semver * License : PostgreSQL / Apache-2.0 Programming Lang: SQL, C Description : Semantic version type for PostgreSQL This library contains a single PostgreSQL extension for a data type called 'semver'. It implements the version number format described in the Semantic Versioning 2.0.0 Specification. [1] The Debian packaging is based on the Apache-2.0 license because I adapted packaging from an existing repository. [2] I hope to convince the PostgreSQL Maintainers to adopt this package, otherwise I will maintain it. Kind regards Felix Lechner [1] https://semver.org/spec/v2.0.0.html [2] https://github.com/mgit-at/pg-semver-debian
Bug#986179: ITP: apksigcopier -- copy/extract/patch apk signatures
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-de...@lists.debian.org, f...@obfusk.net * Package name: apksigcopier Version : 0.3.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/apksigcopier * License : GPLv3+ Programming Lang: Python Description : copy/extract/patch apk signatures apksigcopier is a tool for copying APK signatures from a signed APK to an unsigned one (in order to verify reproducible builds). Its command-line tool offers three operations: * copy signatures directly from a signed to an unsigned APK * extract signatures from a signed APK to a directory * patch previously extracted signatures onto an unsigned APK The F-Droid reproducible builds & verification effort recently led [1] to the development of apksigcopier. I've started packaging it for Debian [2] and I have an offer from Holger Levsen to sponsor my uploads [3]. - Felix [1] https://lists.reproducible-builds.org/pipermail/rb-general/2021-March/002214.html [2] https://salsa.debian.org/obfusk/apksigcopier/-/commits/debian/sid [3] https://lists.reproducible-builds.org/pipermail/rb-general/2021-March/002215.html
Bug#983467: ITP: wolftpm -- Portable TPM 2.0 Library
Package: wnpp Severity: wishlist Owner: Felix Lechner X-Debbugs-CC: debian-de...@lists.debian.org * Package name: wolftpm Version : 2.0.0 Upstream Author : David Garske * URL : https://www.wolfssl.com/products/wolftpm/ * License : GPL-2+ Programming Lang: C Description : Portable TPM 2.0 Library wolfTPM is a portable, open-source TPM 2.0 stack with backward API compatibility, designed for embedded use. It is highly portable, and has native support for Linux. RTOS and bare metal environments can take advantage of a single IO callback for SPI hardware interface, no external dependencies, and compact code size with low resource usage. wolfTPM offers API wrappers to help with complex TPM operations like attestation and examples to help with complex cryptographic processes like the generation of Certificate Signing Request (CSR) using a TPM. - Provides all TPM 2.0 API’s in compliance with the specification. - Backward API compatibility. - Includes wrappers for the most common use cases, like Key Generation, NV memory, RSA encrypt/decrypt, ECC sign/verify, ECDH, and others. - Provides examples for the advanced use cases, like Attestation (TPM 2.0 Quote), Certificate Signing Request (CSR), generation of signed timestamp (TPM 2.0 GetTime), and others. wolfSSL has support for chipsets including ARM, Intel, Motorola, mbed, NXP/Freescale, Microchip (PIC32)/Atmel, STMicroelectronics (STM32F2/F4), Analog Devices, Texas Instruments, and more. I will maintain this package going forward. Kind regards Felix Lechner
Bug#983450: ITP: wolfmqtt -- Lightweight client library for the MQTT protocol
Package: wnpp Severity: wishlist Owner: Felix Lechner X-Debbugs-CC: debian-de...@lists.debian.org * Package name: wolfmqtt Version : 1.8.0 Upstream Author : David Garske * URL : https://www.wolfssl.com/products/wolfmqtt/ * License : GPL-2+ Programming Lang: C Description : Lightweight client library for the MQTT protocol MQTT (Message Queuing Telemetry Transport) is a lightweight open messaging protocol that was developed for constrained environments such as M2M (Machine to Machine) and IoT (Internet of Things), where a small code footprint is required. MQTT is based on the Pub/Sub messaging principle of publishing messages and subscribing to topics. The protocol efficiently packs messages to minimize overhead. The wolfMQTT library is a client implementation of the MQTT written in C. It supports all Packet Types, all Quality of Service (QoS) levels 0-2 and supports SSL/TLS. This implementation provides support for MQTT v5.0 and is based on MQTT v3.1.1. Additionally, there is also client support for MQTT-SN (Sensor Network). - Supports MQTT specifications v3.1.1 and v5.0 - Support for MQTT-SN - Supports all client side packet types and protocol options - QoS Levels 0-2 (guaranteed delivery) - Message integrity, security are still available - Single threaded model and single message callback - Written in Native C89 with portability/compatibility in mind - Space conscience design (Compiled size is about 3.6kB) - User manual with build instructions, example overview, and API documentation - Example MQTT client implementations - Network interface is abstracted via callbacks for extensibility - Packet parsing encoding/decoding structured for custom use - Minimal external dependencies (strlen, memcpy, memset) - Detailed error checking/handling - Doxygen style inline documentation - Fewer than 1200 lines of well structured C code - Tested on multiple variants of MQTT broker servers, QoS levels 0-2 with/without TLS - FreeRTOS+TCP support wolfSSL has support for chipsets including ARM, Intel, Motorola, mbed, NXP/Freescale, Microchip (PIC32)/Atmel, STMicroelectronics (STM32F2/F4), Analog Devices, Texas Instruments, and more. I will maintain this package going forward. Kind regards Felix Lechner
Bug#983449: ITP: wolfssh -- Lightweight SSH Library
Package: wnpp Severity: wishlist Owner: Felix Lechner X-Debbugs-CC: debian-de...@lists.debian.org * Package name: wolfssh Version : 1.4.6 Upstream Author : John Safranek * URL : https://www.wolfssl.com/products/wolfssh/ * License : GPL-3+ Programming Lang: C Description : Lightweight SSH Library The wolfSSH library is a lightweight SSHv2 client and server library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments—primarily because of its small size, speed, and feature set. It is also often used in standard operating environments. Features: - SSH v2.0 (client and server) - Minimum footprint size of 33kB - Runtime memory usage between 1.4 and 2kB, not including a configurable receive buffer - Multiple Hashing Functions: SHA-1, SHA-2 (SHA-256, SHA-384, SHA-512), BLAKE2b - Block, Stream, and Authenticated Ciphers: AES (CBC, CTR, GCM, CCM), Camellia - Public Key Options: RSA, DH, EDH, NTRU - ECC Support (ECDH and ECDSA with curves: NISTP256, NISTP384, NISTP521 - Curve25519 and Ed25519 - Client authentication support (RSA key, password) - SCP support - SFTP support - Port forwarding support (client-side) - Simple API - PEM and DER certificate support - Hardware Cryptography Support: Intel AES-NI support, Intel AVX1/2, RDRAND, RDSEED, Cavium NITROX support, STM32F2/F4 hardware crypto support, Freescale CAU / mmCAU / SEC, Microchip PIC32MZ, support for MPLAB Harmony on PIC32 - Echoserver functionality - Interop Tested Against: OpenSSH, Tera term, PuTTY, Dropbear, Firezilla, BitVise wolfSSH is built for maximum portability and is generally very easy to compile on new platforms. wolfSSH has support for chipsets including ARM, Intel, Motorola, mbed, NXP/Freescale, Microchip (PIC32)/Atmel, STMicroelectronics (STM32F2/F4), Analog Devices, Texas Instruments, and more. I will maintain this package going forward. Kind regards Felix Lechner
Bug#878875: [Pkg-javascript-devel] Bug#878875: Packaging twemoji
hello Jonas, Jonas Smedegaard writes: > Quoting Felix Natter (2021-01-24 16:12:39) >> >> Control: retitle -1 RFP: twemoji -- Open-sourced Twitter emoji images >> >> hello Debian developers, >> >> twemoji contains SVGs for twitter emojis as well as javascript >> code to generate this in web/node.js apps. >> >> Unfortunately, I cannot package all of twemoji, because it has a >> generated file without source: >> https://github.com/twitter/twemoji-parser/blob/master/src/lib/regex.js >> >> I contacted a twitter developer (2020) [1] and she said that it could >> take a while until they publish the relevant library. >> >> [1] Justine De Caires jdecai...@twitter.com > > please consider raising the question at their issue tracker > https://github.com/twitter/twemoji-parser/issues - and then share a > reference to that public conversation here. Here is the ticket: https://github.com/twitter/twemoji-parser/issues/14 Best Regards, -- Felix Natter
Bug#981217: ITP: golang-github-phpdave11-gofpdf -- A PDF document generator with high level support for text, drawing and images
Package: wnpp Severity: wishlist Owner: Felix Yan * Package name: golang-github-phpdave11-gofpdf Version : 1.4.2-1 Upstream Author : Dave Barnes * URL : https://github.com/phpdave11/gofpdf * License : Expat Programming Lang: Go Description : A PDF document generator with high level support for text, drawing and images Package gofpdf implements a PDF document generator with high level support for text, drawing and images. Features: UTF-8 support; Choice of measurement unit, page format and margins• Page header and footer management; Automatic page breaks, line breaks, and text justification; Inclusion of JPEG, PNG, GIF, TIFF and basic path-only SVG images; Colors, gradients and alpha channel transparency; Outline bookmarks; Internal and external links; TrueType, Type1 and encoding support; Page compression; Lines, Bézier curves, arcs, and ellipses; Rotation, scaling, skewing, translation, and mirroring; Clipping; Document protection; Layers; Templates; Barcodes; Charting facility; Import PDFs as templates gofpdf has no dependencies other than the Go standard library. Adding as a new dependency for golang-github-ruudk-golang-pdf417
Bug#878875: [Pkg-javascript-devel] Packaging twemoji
Control: retitle -1 RFP: twemoji -- Open-sourced Twitter emoji images hello Debian developers, twemoji contains SVGs for twitter emojis as well as javascript code to generate this in web/node.js apps. Unfortunately, I cannot package all of twemoji, because it has a generated file without source: https://github.com/twitter/twemoji-parser/blob/master/src/lib/regex.js I contacted a twitter developer (2020) [1] and she said that it could take a while until they publish the relevant library. [1] Justine De Caires jdecai...@twitter.com It is not possible to have a mixture of main/non-free binary packages, so it not possible to put the SVGs in main, and debian-js/debian-fonts have expressed no interest in just a package with the SVGs. https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2020-October/045115.html I might still package this (the SVGs only) later if I get to upgrade freeplane>=1.8 (which is blocked by gradle). Cheers and Best Regards, -- Felix Natter
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#972343: ITP: wxedid -- Graphical editor for monitor resolution and timing data (EDID)
Package: wnpp Severity: wishlist Owner: Felix Lechner X-Debbugs-CC: debian-de...@lists.debian.org X-Debbugs-CC: Tomasz Pawlak * Package name: wxedid Version : 0.0.21 Upstream Author : Tomasz Pawlak * URL : https://sourceforge.net/projects/wxedid/ * License : GPL-3+ Programming Lang: C++ Description : Graphical editor for monitor resolution and timing data (EDID) wxEDID is a wxWidgets based editor for Extended Display Identification Data (EDID). It operates on offline files that can be flashed to a monitor using the technique described here: https://wiki.debian.org/RepairEDID. This tool can modify the base EDID v1.3+ structure and the CEA/CTA-861-G, as the first extension block. The program also provides a DTD constructor to aid with the selection of suitable timings. The tool can import and export EDID data in binary blob and in hexadecimal formats. As a small package with few prerequisites and two releases per year, maintenance should be moderate. There was discussion if the software should be packaged at all. It is available in Suse and Archlinux, presumably because it is helpful when fixing your monitor's EDID. Kind regards Felix Lechner
Bug#972131: ITP: gammastep -- Adjust display hue to outside lighting conditions on Wayland
Package: wnpp Severity: wishlist Owner: Felix Lechner X-Debbugs-CC: debian-de...@lists.debian.org X-Debbugs-CC: team+swa...@tracker.debian.org X-Debbugs-CC: r...@debian.org X-Debbugs-CC: rhal...@old-forest.org * Package name: gammastep Version : 2.0.2 Upstream Author : Jon Lund Steffensen * URL : https://gitlab.com/chinstrap/gammastep * License : GPL-3+ Programming Lang: C, and Python for an applet Description : Adjust display hue to outside lighting conditions Gammastep automatically adjusts the color temperature of computer displays to help reduce the eye strain that comes with working in low-light conditions. Based on the geographical location of the computer system, Gammastep will keep the screen at the default bluish hue during daytime but adjust to an orange or reddish color in the evening hours and nighttime. Gammastep is similar to the redshift package but works with some Wayland compositors. (I am not sure about GNOME or KDE there.). The maintainers of the redshift package were copied on this message, in case they are interested. Going forward, I would prefer if the Sway team (or another Wayland team) assumed maintenance of this package. As a happy Sway user I would also consider joining a team, if needed. Thanks! Kind regards Felix Lechner
Bug#878875: [Pkg-javascript-devel] Packaging twemoji
Jonas Smedegaard writes: > Hi Felix, hi Jonas, hi Debian-js, > Quoting Felix Natter (2020-08-08 10:41:53) >> hello Debian-js, >> >> I would like to package twemoji (SVGs for unicode emojis) [1], and I >> think debian-js is the right team for this. >> >> However, I consider packaging only the SVGs and not the javascript code, >> because that's all I need for the freeplane package, and the RFP author >> Dominik (CC:) did not reply to my query (see #878875). >> >> What do you think, is Debian-js the right place for this, and do you >> need the javascript code? > > You are most welcome to maintain twemoji in the JavaScript team and I > agree that seems a good place to do it, given that upstream build > framework seem tied to Node.js. Other options you might consider are > the fonts team and DebianArt (if the latter is a team, not sure about > that: Maybe ask Valessio Brito directly). > > When packaging it, then yes, please package it reusable for other > projects as well - that's an important attitude of Debian packaging. > This (from a quick look) indeed seems to mean include the javascript, > not only SVGs. But maybe consult the fonts teams on that - they > maintain several fonts where upstream ship Javascript stuff as well. > > Speaking of SVGs, are you sure this is the real source of those SVG > files? It seems amchine-generated to me, and I suspect there is real > concern as to freedom aspects of distributing only as provided here. > Even if you choose to use the JavaScript team as platform for your > package maintenance, I recommend that you discuss the issue of source of > fonts with the font team, as there is collected quite some knowledge and > experience in that team. Finally I got a response from twitter (Justine De Caires ): "The original sources are indeed the SVG files. When we update the package with new emojis, I'm given SVG files by the designers, so there aren't any AI files to be had anymore." Now that this is resolved, can someone add me to Debian-js [1] (I am part of Debian-java already), create a salsa repository for twemoji and maybe suggest a similar package? [1] I couldn't find a way to apply here: https://salsa.debian.org/groups/js-team/-/group_members > Hmm, maybe the fonts team would be a better place after all. Not > sure... I'll let you decide. > Good luck with the project - seems a great resource to have in Debian! Many Thanks and Best Regards, Felix -- Felix Natter
Bug#950904: (no subject)
Expressing my Intent To Package this. * Package name : libapache2-mod-tile Version : 0.4+git20170108-e25bfdb Upstream Author : OSMF Operations Working Group * URL : https://github.com/openstreetmap/mod_tile * License : GPL-2+ Programming Lang: C, C++ Description : Serves raster map tiles using apache libapache2-mod-tile is an Apache2 module is designed to serve raster tiles on the web, for example for use within a slippy map. It offers a dynamic combination of efficient caching and on-the-fly rendering. Because of its dynamic rendering, only a small portion of the total tiles need to be stored on disk, reducing the resources required. At the same time, its caching strategy enables high-performance serving and can support several thousand requests per second. libapache2-mod-tile was originally written to serve the tiles of the main layer in OSM carto style, but has since been used on a variety of different services that provide maps on OpenStreetMap data.
Bug#968677: ITP: renderd -- Renders raster map tiles using mapnik
Package: wnpp Severity: wishlist * Package name : renderd Version : 0.4+git20170108-e25bfdb Upstream Author : OSMF Operations Working Group * URL : https://github.com/openstreetmap/mod_tile * License : GPL-2+ Programming Lang: C, C++ Description : Renders raster map tiles using mapnik renderd is a render engine and queue management system to connect a webserver with the Mapnik mapserver. It is a daemon that creates "metatiles" fo map tile requests issued by libapache2-mod-tile and the mapnik library. The package will be maintained in the Debian GIS team.
Bug#968676: ITP: tirex -- Renders raster map tiles using mapnik or other backends
Package: wnpp Severity: wishlist Version: 0.6.3 Upstream Author: Frederick Ramm URL: https://github.com/openstreetmap/tirex License: GPL-2+ Programming Lang: Perl Tirex is a render engine and queue management system to connect a webserver with different kinds of mapserver. It is a suite containing a master daemon, rendering manager, test backend, and assorted utility programs. The package will be maintained in the Debian GIS team.
Bug#878875: Packaging twemoji
hello Debian-js, I would like to package twemoji (SVGs for unicode emojis) [1], and I think debian-js is the right team for this. However, I consider packaging only the SVGs and not the javascript code, because that's all I need for the freeplane package, and the RFP author Dominik (CC:) did not reply to my query (see #878875). What do you think, is Debian-js the right place for this, and do you need the javascript code? [1] https://github.com/twitter/twemoji Cheers and Best Regards, -- Felix Natter
Bug#878875: RFP: twemoji -- Open-sourced Twitter emoji images
Control: retitle -1 ITP: twemoji -- Open-sourced Twitter emoji images Control: owner -1 Felix Natter hi Dominik, I intend to maintain this package. I think only the SVG icons, since you don't seem to need more (do you need the javascript code?) and I need the SVGs for freeplane 1.8. @mentors: Could you suggest a team where this could be maintained (where is the js-team mailing list?) Cheers and Best Regards, -- Felix Natter
Bug#959838: Can you help? (ITP: opencensus-java -- Stats collection and distributed tracing framework)
Andreas Tille writes:
> Hi Felix,
hello Andreas,
> since you recently provided some help with another Java package: This
> one is a predependency for bazel which would be really great to have
> torch (the machine learning framework) which in turn is needed by lots
> of COVID-19 relevant packages. So if you have a clue how to build this
> it would be another interesting step forward.
>
> Kind regards
>
> Andreas.
>
> PS: Feel free to answer on list
>
> https://lists.debian.org/debian-java/2020/05/msg00019.html
>
>
> I've started packaging in
>
>https://salsa.debian.org/java-team/opencensus-java
>
> to support bazel packaging. Unfortunately I have no idea how to fix all
> the (Build-)Depends of the gradle build. I was following a hint given
> on debian-java list to find out some dependency relations via
>
>gradle build --info
Wow, what a huge project (and, as usual in Java, with a huge number of
dependencies)...
There are toplevel dependencies (/build.gradle), which are "only" gradle
plugins, so IMHO some of these are candidates for patching out:
classpath 'ru.vyarus:gradle-animalsniffer-plugin:1.4.6'
classpath("org.springframework.boot:spring-boot-gradle-plugin:2.0.5.RELEASE")
classpath 'net.ltgt.gradle:gradle-errorprone-plugin:0.0.16'
classpath "net.ltgt.gradle:gradle-apt-plugin:0.18"
classpath 'com.github.ben-manes:gradle-versions-plugin:0.20.0'
classpath
"gradle.plugin.com.github.sherter.google-java-format:google-java-format-gradle-plugin:0.8"
classpath "me.champeau.gradle:jmh-gradle-plugin:0.4.8"
classpath "gradle.plugin.io.morethan.jmhreport:gradle-jmh-report:0.9.0"
Then there are ~50 dependencies in the 'libraries' map (most probably
all referenced in subdirectory build.gradle's, like "compile
libraries.grpc_context" in /api/build.gradle):
libraries = [
appengine_api:
"com.google.appengine:appengine-api-1.0-sdk:${appengineVersion}",
aspectj: "org.aspectj:aspectjrt:${aspectjVersion}",
auto_value:
"com.google.auto.value:auto-value:${autoValueVersion}",
auto_service: 'com.google.auto.service:auto-service:1.0-rc3',
byte_buddy: 'net.bytebuddy:byte-buddy:1.8.22',
config: 'com.typesafe:config:1.2.1',
disruptor: 'com.lmax:disruptor:3.4.2',
errorprone:
"com.google.errorprone:error_prone_annotations:${errorProneVersion}",
findbugs_annotations:
"com.google.code.findbugs:annotations:${findBugsAnnotationsVersion}",
google_auth:
"com.google.auth:google-auth-library-credentials:${googleAuthVersion}",
google_cloud_logging:
"com.google.cloud:google-cloud-logging:${googleCloudGaVersion}",
google_cloud_trace:
"com.google.cloud:google-cloud-trace:${googleCloudBetaVersion}",
log4j2: "org.apache.logging.log4j:log4j-core:${log4j2Version}",
zipkin_reporter:
"io.zipkin.reporter2:zipkin-reporter:${zipkinReporterVersion}",
zipkin_urlconnection:
"io.zipkin.reporter2:zipkin-sender-urlconnection:${zipkinReporterVersion}",
jaeger_reporter:
"io.jaegertracing:jaeger-client:${jaegerReporterVersion}",
google_cloud_monitoring:
"com.google.cloud:google-cloud-monitoring:${googleCloudGaVersion}",
grpc_auth: "io.grpc:grpc-auth:${grpcVersion}",
grpc_context: "io.grpc:grpc-context:${grpcVersion}",
grpc_core: "io.grpc:grpc-core:${grpcVersion}",
grpc_netty: "io.grpc:grpc-netty:${grpcVersion}",
grpc_netty_shaded: "io.grpc:grpc-netty-shaded:${grpcVersion}",
grpc_stub: "io.grpc:grpc-stub:${grpcVersion}",
guava: "com.google.guava:guava:${guavaVersion}",
jsr305:
"com.google.code.findbugs:jsr305:${findBugsJsr305Version}",
signalfx_java:
"com.signalfx.public:signalfx-java:${signalfxVersion}",
spring_aspects:
"org.springframework:spring-aspects:${springVersion}",
spring_boot_starter_web:
"org.springframework.boot:spring-boot-starter-web:${springBootVersion}",
spring_boot_starter_web2:
"org.springframework.boot:spring-boot-starter-web:${springBoot2Version}",
spring_cloud_build:
"org.springframework.cloud:spring-cloud-build:${springCloudVersion}",
spring_cloud_starter_sleuth:
"org.springframework.cloud:spring-cloud-starter-sleuth:${springCloudV
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#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
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
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
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: 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: 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 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
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 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#898246: git-lab requires golang-github-xanzy-go-gitlab
Hi Julian, On Fri, Jan 24, 2020 at 3:39 AM Julian Gilbey wrote: > > The version of xanzy in debian/sid on salsa is very out of date - the > upstream version is now 0.22, but debian/sid is lagging on 0.15. State of package on Mentors (based on upstream's version 0.22) was pushed to the golang team repo. Kind regards Felix Lechner
Bug#898246: git-lab requires golang-github-xanzy-go-gitlab
Hi, On Sun, Dec 15, 2019 at 7:46 AM Dominique Dumont wrote: > > Felix, could you resume packaging this software ? Do you know anyone with upload privileges? :) Please feel free to upload the required prerequisite golang-github-xanzy-go-gitlab in #947304. My RFS had no takers for a month. I will package git-lab for you afterwards. Kind regards Felix
Bug#900774: Patch for opendkim-tools and adoption status
Hi, On Sat, Dec 14, 2019 at 3:35 AM David Bürgin wrote: > > May I take ownership of the wnpp bug with intent to adopt? Yes, please. It is in better hands with you. Good luck! Kind regards Felix Lechner
Bug#900774: Patch for opendkim-tools and adoption status
Hi David, I worked on this package before the buster freeze, but don't actually use it anymore. (Exim has built-in support for DKIM.) Are you interested in taking over maintenance? Kind regards Felix Lechner On Mon, Dec 9, 2019 at 2:35 AM David Bürgin wrote: > > Hello Felix, > > I have opened Debian bug #946386 with a patch that I would like to get > into Debian. > > You are the prospective maintainer of opendkim, is that right? How can I > help you with integrating the patch? It would be good to have a status > update on your adoption and maintenance plans for opendkim. > > Thank you. > > > -- > David
Bug#945407: ITP: golang-github-sabhiram-go-gitignore -- A gitignore parser for go
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-sabhiram-go-gitignore Version : 1.0.2-1 Upstream Author : Shaba Abhiram * URL : https://github.com/sabhiram/go-gitignore * License : MIT Programming Lang: Go Description : A gitignore parser for go go-gitignore Build Status (https://travis-ci.org/sabhiram/go-gitignore) Coverage Status (https://coveralls.io/github/sabhiram/go-gitignore?branch=master) . A gitignore parser for Go Install shell go get github.com/sabhiram/go-gitignore . Usage For a quick sample of how to use this library, check out the tests under ignore_test.go. Required prerequisite for Gocryptfs starting with version 1.7.1, which is currently unpackaged.
Bug#924367: ITA?
Hi Jonatha, Yes, I worked on it, but then came the buster freeze, plus I got sidetracked with Lintian. I hope to make an upload soon. I'll let you know if my plans change. I assume you are also interested? Thank you for your initiative! Kind regards, Felix On Mon, Nov 18, 2019 at 12:51 AM Jonathan Carter wrote: > Hi Felix, a while back you expressed interest in adopting mdadm > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924367), are you > still interested in doing so? > > thanks, > > -Jonathan > > -- > ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) > ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage > ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org > ⠈⠳⣄ Be Bold. Be brave. Debian has got your back. >
Bug#941916: ITP: libdata-url-java -- Support for the data protocol as specified in RFC 2397.
Package: wnpp Severity: wishlist Owner: Felix Natter * Package name: libdata-url-java Version : 1.0.1 Upstream Author : Rob Spoor * URL : https://github.com/robtimus/data-url/ * License : Apache-2.0 Programming Lang: Java Description : Support for the data protocol as specified in RFC 2397. The data-url library adds support for the data protocol as specified in RFC 2397. This is a dependency of freeplane-1.7.10. It will be maintained within the java team. Felix Natter
Bug#940867: ITP: libiconloader-java -- Smart Java Icon Loader with support of HiDPI (Retina) images
Package: wnpp Severity: wishlist Owner: Felix Natter * Package name: libiconloader-java Version : git? Upstream Author : Konstantin Bulenkov * URL : https://github.com/bulenkov/iconloader * License : Apache-2.0 Programming Lang: Java Description : Smart Java Icon Loader with support of HiDPI (Retina) images Dependency for darcula-theme-java (also ITP'd) which in turn is a dependency of freeplane-1.7.10. Will be maintained within the debian-java team. I will contact the author regarding releases (there seem to be releases on maven). Cheers and Best Regards, -- Felix Natter
Bug#940868: ITP: darcula-theme-java -- The official Darcula Look and Feel for programming environments by Konstantin Bulenkov.
Package: wnpp Severity: wishlist Owner: Felix Natter * Package name: darcula-theme-java (darcula-lookandfeel-java?) Version : git? Upstream Author : Konstantin Bulenkov * URL : https://github.com/bulenkov/Darcula * License : Apache-2.0 Programming Lang: Java Description : The official Darcula Look and Feel for programming environments by Konstantin Bulenkov. Darcula is a Look-n-Feel for Java desktop application and a theme for code editors. Dependency of freeplane-1.7.10. Will be maintained within the debian-java team. I will contact the author regarding releases (there seem to be releases on maven). Cheers and Best Regards, -- Felix Natter
Bug#940631: ITP: primus-vk -- Vulkan layer for GPU offloading
Package: wnpp Severity: wishlist Owner: Felix Dörre * Package name: primus-vk Version : 1.2.z Upstream Author : Felix Dörre * URL : https://github.com/felixdoerre/primus_vk * License : BSD-2-clause Programming Lang: C++ Description : Vulkan layer for GPU offloading Typically you want to display an image rendered on a more powerful GPU on a display managed by an internal GPU. The layer in this package will direct rendering commands to a dedicated, more powerful GPU an when such an image is displayed it will be copied to the integrated CPU for displaying. This software seems already fit for several people's needs and handles most games/applications perfectly.
Bug#931638: RFP: qupil -- Qupil is a music teacher management software to quickly and easily organize student and lesson data.
Package: wnpp Severity: wishlist * Package name: qupil Version : 1.4.1 Upstream Author : Felix Hammer * URL : http://www.qupil.de/ * License : (GPL) Programming Lang: (C++) Description : Qupil is a music teacher management software to quickly and easily organize student and lesson data. Qupil is a music teacher management software to quickly and easily organize student and lesson data. The program helps to complete the repetitive tasks in the music school business. The lesson preparation is done quickly, as you get the entire lesson history to a student displayed with a single click. Just as easy is the overview of the currently played pieces of music. When preparing a concert program, the concert manager helps to export extensive concert programs into corresponding overview documents with just a few clicks. An inventory overview for the rental instruments is also available. In the daily work, the reminder tool proves to be a great help to create individually coordinated reminder messages on various topics. With the music library, the music teacher keeps track of the grades he has temporarily given to his students. Many small automation functions between the main functions help to make the use in the everyday lesson even more efficient. The functionality of Qupil is rounded off by an automatic display of the current birthdays of the last week and a metronome-tuner combination. The software is a special solution for music teachers daily business. There is currenty no other open source software available for these professional groups. That's why i suggest the software for getting into debian package repository. Unfortunately i'm not able to build the package by myself.
Bug#924270: O: keepassx -- Cross Platform Password Manager
Hi, On 11.03.19 04:29, Shengjing Zhu wrote: > Hi, > > On Mon, Mar 11, 2019 at 3:15 AM Reinhard Tartler wrote: >> >> Package: wnpp >> Severity: normal >> >> Keepassx is a graphical password manager, using the Qt4 toolkit. I'm no >> longer using this package and have personally switched to >> 'password-store'. Unfortunately, I've also failed to get a response >> from upstream from >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920616 - which >> recommends to replace keepassx with keepassxc, a community fork, >> possibly because of unresponsive upstream. >> >> I am undecided whether or not this package should be included in Debian >> 10 (aka buster). It clearly is useful to many people, but its long-term >> maintenance is unclear. >> >> I'd encourage people interested in picking up this package to coordinate >> with Julian Klode (CC'ed), the Debian keepassxc maintainer. I've replied to you but unfortunately your mail provider / filter seems to discard my mails. I will continue maintaining KeePassX for the time being but likely only do important bugfixes and other necessary changes (like the port to Qt5). > I'm also long-time user of keepassx. > > I checked the upstream. In surprise, I found the master version has > switched to Qt-5. And the upstream author is Felix Geyer, who is DD as > well. > > Felix, could you have some inputs here? > > In person, I hope keepassx is in buster. I can help uploading the > master version(with Qt-5) if Qt-4 is really needed to be removed from > buster. However I'm unsure if RT is fine with this big change(I assume > it's not ok). Qt 4 won't be removed from buster. There are still lots of packages using it in the archive. Switching keepassx to Qt5 this late (essentially after the freeze) seems inappropriate to me. I don't see the release team unblocking this. Cheers, Felix
Bug#923187: ITP: golang-github-golang-freetype -- The Freetype font rasterizer in the Go programming language.
Package: wnpp Severity: wishlist Owner: Felix Yan * Package name: golang-github-golang-freetype Version : release+git20170609.e2365df-1 Upstream Author : The Freetype-Go Authors * URL : https://github.com/golang/freetype * License : GPL-2+ or FTL Programming Lang: Go Description : The Freetype font rasterizer in the Go programming language. See the reference (https://github.com/golang/freetype) for more info. This package is in the dependency tree of Deepin Desktop Environment's go backend.
Bug#923183: ITP: golang-github-ruudk-golang-pdf417 -- Port of pdf417-php by ihabunek in Golang
Package: wnpp Severity: wishlist Owner: Felix Yan * Package name: golang-github-ruudk-golang-pdf417 Version : 0.0~git20181029.1af4ab5-1 Upstream Author : Ruud Kamphuis * URL : https://github.com/ruudk/golang-pdf417 * License : Expat Programming Lang: Go Description : Port of pdf417-php by ihabunek in Golang PDF417 barcodes in Golang . This library encodes data to a PixelGrid that can be used to display the barcode. You can use the PixelGrid to draw the barcode on anything. This package is in the dependency tree of Deepin Desktop Environment's go backend.
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.
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#907705: ITP: mmm -- minimalistic media manager
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" * Package name: mmm Version : 0.4.1 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/m * License : GPLv3+ Programming Lang: Python Description : minimalistic media manager m keeps track of which files you've played (or are still playing) and thus allows you to easily continue playing the next file (using vlc or mpv). I'm the upstream author and I use it a lot myself (instead of kodi); some of my friends do as well. As a Debian user I wanted to be able to install it as a Debian package, so I turned it into a native Debian package. It builds (reproducibly) using dpkg-buildpackage. I'm hoping to eventually become a Debian Developer/Maintainer, but for now I'd need a sponsor to get this into Debian. Thanks. - Felix
Bug#906986: ITP: golang-github-xanzy-go-gitlab -- Simple and uniform GitLab API for Go
Package: wnpp Severity: wishlist Owner: Felix Lechner * Package name: golang-github-xanzy-go-gitlab Version : 0.10.8 Upstream Author : Sander van Harmelen * URL : https://github.com/xanzy/go-github/ * License : Apache-2.0 Programming Lang: Go Description : Simple and uniform GitLab API for Go This package provides a GitLab API that enables Go programs to interact with GitLab in a simple and uniform way. It covers most of the existing Gitlab API calls and is updated regularly to add new or missing endpoints. A golang library, it is a prerequisite for git-lab (#898246). The package will be maintained as part of the go-team on Salsa. Thank you!
Bug#903261: ITA: libapache2-mod-fcgid
Hi Xavier, On 18.08.2018 13:56, Xavier wrote: Hello Felix, I'm going to adopt libapache2-mod-fcgid. That's great! I'm DM for now but approved for DD (https://nm.debian.org/process/495). Package is ready with the following changes: * Taken (Closes: #903261) * debian/copyright: - update format using packaging-manuals/copyright-format/1.0/ - add Debian files copyright * Add myself to maintainer * Bump debhelper compatibility to 10 * Remove --parallel option for dh * Add upstream/metadata file * Drop --dbgsym-migration (stable is > 2.3.9) I've only added it in the last upload so it needs to be kept for buster. * Add doc-base entry * debian/rules: remove useless options * Declare compliance with policy 4.2.0 * Add NOTICE-FCGID and STATUS-FCGID in docs * autopkgtest: - don't use systemd to start apache2 - add "allow-stderr" to ignore apache2 warnings Could you give me some rights on https://salsa.debian.org/debian/libapache2-mod-fcgid to push this on git ? So you could review my changes before adoption. Sure, done. Cheers, Felix
Bug#887809: RFP: borgmatic -- A wrapper script for Borg backup software that creates and prunes backups
Hi, On Tue, 31 Jul 2018 11:17:46 +0200 Andrej Shadura wrote: > Hi Olivier, > > On Mon, 30 Jul 2018, 13:03 Olivier Berger, > wrote: > > Out of curiosity, have you made any progress towards packaging borgmatic ?> > > Unfortunately, I have not. I figured I don’t really need it myself, > since I’m just running a one-liner from a systemd timer. I may package > it one day though, but feel free to take it over. FWIW the borgmatic dependency pykwalify is considered non-free by Debian because its license contains the "The Software shall be used for Good, not Evil." clause. https://github.com/Grokzen/pykwalify/blob/master/LICENSE https://wiki.debian.org/qa.debian.org/jsonevil Felix
Bug#903261: O: libapache2-mod-fcgid -- FastCGI interface module for Apache 2
Package: wnpp I'm orphaning libapache2-mod-fcgid because I haven't used it for a long time and for most use cases better alternatives exist. The package is in a reasonable shape however upstream has been mostly inactive for the last couple of years. Felix
Bug#901370: ITP: pdftk-java -- port of pdftk to java - a tool for manipulating PDF documents
Am 12.06.2018 um 09:30 schrieb Emilio Pozuelo Monfort: > Hi, > > On 12/06/18 09:21, Johann Felix Soden wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Johann Felix Soden >> >> * Package name: pdftk-java > > I prepared a pdftk update based on that fork, see > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892539#33 > > Feel free to reuse that if you find it useful. > > Cheers, > Emilio > Hi Emilio, indeed, I have used it as the base for the hopefully soon ready pdftk-java package. Thanks! Best regards, Johann Felix -- Johann Felix Soden, joh...@debian.org, DD
Bug#901370: ITP: pdftk-java -- port of pdftk to java - a tool for manipulating PDF documents
Package: wnpp Severity: wishlist Owner: Johann Felix Soden * Package name: pdftk-java Version : tba Upstream Author : Marc Vinyals * URL : https://gitlab.com/marcvinyals/pdftk * License : GPL v2+ Programming Lang: Java Description : port of pdftk to java - a tool for manipulating PDF documents This package should be an alternative/replacement to the pdftk package which is FTBFS and removed from testing as its depends on gcj (also removed, as no longer available in GCC)
Bug#895241: ITP: snapcast -- multi-room client-server audio player
Package: wnpp Severity: wishlist Owner: Felix Geyer <fge...@debian.org> * Package name: snapcast Version : 0.13.0 Upstream Author : Johannes Pohl * URL : https://github.com/badaix/snapcast * License : GPL Description : multi-room client-server audio player Snapcast is a multi-room client-server audio player, where all clients are time synchronized with the server to play perfectly synced audio. It's not a standalone player, but an extension that turns your existing audio player into a Sonos-like multi-room solution.
Bug#887151: Teamwork
Hi Tobias, I would be happy to work with you on this package. Find me on IRC some time and we can discuss my qualifications. Thank you! Best regards, Felix
