Bug#1098705: ITP: nginx-snippets -- Useful, commonly used nginx configuration snippets
Package: wnpp Severity: wishlist Owner: Thomas Ward X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : nginx-snippets Version : 1.0 Upstream Contact: Thomas Ward * URL : https://salsa.debian.org/teward/nginx-snippets * License : GPL-3.0+ Programming Lang: None (static files) Description : Useful, commonly used nginx configuration snippets The nginx-snippets package contains a set of useful configuration snippets for commonly used configuration snippets that can be included in any nginx configuration file with an `include` statement but are not included in the nginx configuration files by default. --- Why is this package useful / relevant? Currently, the NGINX team maintains a bare minimum number of snippets, such as the ssl-cert package's 'snakeoil' certificate configurations. However, the team has been hesitant to include extra snippets because of 'support' for changes, etc. over time. As such, useful things like commonly-observed TLS/SSL cipher and session handling settings are not made into snippets and commonly overlooked. Additionally, there are common things used for reverse proxies in headers which are not included in the default settings. Having separate snippets that can be updated without a full re-roll of the src:nginx package are useful and can allow for independent rapid changes to the snippets. -- How do I plan to maintain this? The package is a Debian-native package and is on Salsa. I plan to be the primary maintainer for this, however anyone with DD privileges is allowed to adjust or maintain the package and make PRs to the repository for inclusion. I expect to be updating the package at least quarterly as SSL ciphers, etc. change and security protocols for TLS adapt, but also as needed for additional contributions which can be made to the repository (read the repository's README.md).
Bug#1098695: ITP: chordv -- ChordV is a software that allows you to annotate a list of songs with chords in a Qt6 editor.
Package: wnpp Severity: wishlist Owner: Gilles Maire X-Debbugs-Cc: debian-devel@lists.debian.org, gilles.maire.i...@gmail.com Package name: chordv Version : 1.4.0 Upstream Contact: URL : https://sourceforge.net/projects/chordv/ License : GPL3 Programming Lang: C++ Description : ChordV allows to annotate a list of songs with chords and produce several kind of PDF ChordV allows to annotate a list of songs with chords using either a simplified or extended notation, such as D7 or D7(V) for a barre chord on the fifth fret. It can generate a PDF with 1) a songbook without chords 2)a songbook with chords displayed as gridd 3) a chord book for the musicians. It allows by a graphical guitar fretboard to design your chords and to store them in a database to use them in your songbook. It allow to transpose the chords ann amany other features. It run with Qt in graphical mode. It depends of libpodofo 0.98 libjack libhunspell-1.7 libQt6 It run in french and in english I will continue to maintain it ChordV was developped during 20 years of concerts from Qt4 to Qt6 release. No bug was found since 2023 I will continue to use it and some people use it from sourceforge but it is not well known. I made installer for debian, Windows and MacOsX
Re: Bug#1098695: ITP: chordv -- ChordV is a software that allows you to annotate a list of songs with chords in a Qt6 editor.
Hello, are you aware of ultimateultimateguitar? It's from shell but it seems similar. Perhaps you could look at it and integrate the functionality into chordv? I'd like to use this but I'm lazy to annotate them myself :D -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei https://ltworf.codeberg.page/
Re: Packages with a history of security issues and whose packaged version is not up to date
> So provided that we don't spam maintainers with "new upstream release" > bug reports hours after the upstream release, and that we don't open new > bug reports for as long as the former one has not been closed (but instead > update the existing bug with the new information), then I would be > pretty much in favor of automating the creation of such bug reports. I don't think that would be very useful. Not for me at least. There's my QA page https://qa.debian.org/developer.php?login=ltworf where all the packages with a newer version upstream have a red version in the "watch" column. So I know exactly which packages have new versions. As to why I haven't done anything about it, depends on the specific package. Usually lack of time. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei https://ltworf.codeberg.page/ signature.asc Description: This is a digitally signed message part.
Re: Packages with a history of security issues and whose packaged version is not up to date
On Sat, Feb 22, 2025 at 09:41:54AM +0100, Salvo Tomaselli wrote: > > So provided that we don't spam maintainers with "new upstream release" > > bug reports hours after the upstream release, and that we don't open new > > bug reports for as long as the former one has not been closed (but instead > > update the existing bug with the new information), then I would be > > pretty much in favor of automating the creation of such bug reports. > > I don't think that would be very useful. Not for me at least. > > There's my QA page https://qa.debian.org/developer.php?login=ltworf where all > the packages with a newer version upstream have a red version in the "watch" > column. So I know exactly which packages have new versions. > > As to why I haven't done anything about it, depends on the specific package. > Usually lack of time. > The question is really whether you would be open to someone packaging a new upstream release for one of your packages and then whether you would prefer to review the package before it is uploaded or not (clearly, this depends much on the reputation of the person doing the packaging). And then, would filing a bug report help to make this process smoother? I.e., right now, if someone were interested in helping you by updating one of your packages to a new upstream release, it would be necessary to look at your QA page, perhaps email you privately, etc. By going the route of filing a bug, it makes it easier (I think) for those who might be looking to contribute in this way (getting new upstream versions in Debian), and it makes the communication much easier. For example, if you know you want to skip a particular version, you could notate that in the bug report. So, then someone wouldn't have to ask, it would already be stated that you are waiting for some specific reason. Perhaps the way to look at it is that in the case where isn't directly helpful to the maintainer (as in your specific case), it can be helpful to those with a desire to collaborate in some way. Regards, -Roberto -- Roberto C. Sánchez
Bug#1098669: ITP: nvim-gruvbox -- gruvbox colorscheme for nvim
Package: wnpp Severity: wishlist Owner: Matthias Geiger X-Debbugs-Cc: debian-devel@lists.debian.org, werdah...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: nvim-gruvbox Version : 2.0.0 Upstream Contact: Ellison Leao * URL : https://github.com/ellisonleao/gruvbox.nvim * License : MIT Programming Lang: lua Description : gruvbox colorscheme for nvim gruvbox.nvim is a neovim port of the classic gruvbox colorscheme. It features improved syntax highlighting and treesitter support. Individual colors can also be overridden. This will be maintained with the Debian vim team. best, werdahias -BEGIN PGP SIGNATURE- iIsEARYIADMWIQQUWTv/Sl6/b+DpcW7svtu2B7myvgUCZ7nUHBUcd2VyZGFoaWFz QGRlYmlhbi5vcmcACgkQ7L7btge5sr4GSwEAjrPSsaYsDj4/EgzLG7A8yFOtOziP PWIMko8qkubEtisBAJ2GfxOxb8ijvQWg3+C0Zh3tCR/YSK1Wmeyy697D8jYA =7ZTN -END PGP SIGNATURE-
