Packages "confirmed" and ready for DD review/possible upload - Debian Mentors - 2024-11-04
Dear all DDs, Below is a package list of the currently "confirmed", as being in good order packages that are awaiting a DD review and possible upload to Debian. If DDs could spare the time to pick up a package or two and finish off the package mentor process it would be greatly appreciated. Outstanding bugs -- Important bugs; Confirmed (1 bug) #1084901 RFS: qstardict/2.0.2-1 [ITA] [RC] -- International dictionary written using Qt https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084901 Outstanding bugs -- Normal bugs; Confirmed (4 bugs) #1072910 RFS: lsp-treemacs/0.5-1 -- treemacs integration for Emacs LSP https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072910 #1077968 RFS: scrcpy/2.6.1-1 -- Display and control your Android device https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077968 #1084101 RFS: golang-golang-x-oauth2/0.23.0-1 [Team] -- Google APIs support for OAuth2 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084101 #1084847 RFS: elpa-subed/1.2.16-1 -- Emacs mode for editing subtitles while playing the corresponding video https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084847 Outstanding bugs -- Wishlist items; Confirmed (24 bugs) #988010 RFS: td-system-tools/2.0.1-1 [ITP] -- System https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988010 #1022747 RFS: prismlauncher/8.4+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022747 #1037098 RFS: serious-engine/0~git20230724+dfsg-1 [ITP] -- game engine developed for the classic Serious Sam games https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037098 #1064485 RFS: samplebrain/0.18.5-1 [ITP] -- Custom sample smashing app designed by Aphex Twin https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064485 #1072518 RFS: debpic/1.0.0 [ITP] -- build Debian packages in an isolated Docker environment https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072518 #1073153 RFS: emacs-lsp-docker/0.0~git20240507.16a0cfb-1 [ITP] -- LSP Docker integration for lsp-mode https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073153 #1074622 RFS: emacs-dape/0.15.0-1 [ITP] -- Debug Adapter Protocol for Emacs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074622 #1076146 RFS: feenox/1.0.83-1 [RFP] -- cloud-first free no-X uniX-like finite-element(ish) tool https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076146 #1077618 RFS: libjs-jush/2.0.2+git20210206+1-1 [ITP] -- JavaScript Syntax Highlighter https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077618 #1078341 RFS: gpgmngr/1.0.2-1 [ITP] -- GPG assistant for the Linux terminal https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078341 #1079664 RFS: saf/1.013-1 [ITP] -- Minimal abstract interface for simple games https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079664 #1079902 RFS: descent3/1.5.0+ds-1 [ITP] -- port of the 1999 classic game Descent 3 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079902 #1080242 RFS: electrum-nmc/4.0.6-2 [ITP] -- Easy to use Namecoin client https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080242 #1080305 RFS: apt-mirror2/9-1 [ITP] -- Python/asyncio reimplementation of the apt-mirror https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080305 #1081042 RFS: aiolimiter/1.1.0-1 [ITP] -- asyncio rate limiter, a leaky bucket implementation https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081042 #1081131 RFS: emacs-oauth2/0.17-1 [ITP] -- OAuth 2.0 Authorization Protocol https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081131 #1081455 RFS: keyd/2.5.0-1 [ITP] -- keyboard key remapping daemon https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081455 #1081586 RFS: log2ram/1.7.2+ds-1 [ITP] -- Write log files to RAM https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081586 #1084022 RFS: buffybox/3.2.0+dfsg-1 [ITP] -- Touch-enabled framebuffer keyboard (not only) for vampire slayers https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084022 #1084795 RFS: openmohaa/0.70.0+dfsg-1 [ITP] -- military WWII first-person shooter game https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084795 #1084869 RFS: keepass2-plugin-keepassrpc/2.0.2+dfsg-1 [RFP] -- RPC plugin for KeePass 2 Password manager https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084869 #1084884 RFS: golang-github-regclient-regclient/0.7.1-1 [ITP] -- Docker and OCI Registry Client (tooling) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084884 #1084885 RFS: golang-github-olareg-olareg/0.1.1-1 [ITP] -- Minimal container registry (program) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084885 #1085585 RFS: mcds/1.7-1 [ITP] -- Mutt CardDAV search utility https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085585 Please check that another DD is not already involved with the package. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- D
Re: Most optimal way to import NMU into existing git-builpackage repository?
Hello, On Tue 29 Oct 2024 at 02:48pm +01, Helmut Grohne wrote: > Andrey has already said much of what I could add to the thread, but I > think I can slightly clarify the needs of NMUers. > > On Fri, Oct 25, 2024 at 08:45:16AM +0200, Andreas Henriksson wrote: >> I would very much prefer if it was possible in Debian to not allow >> the archive to get out of sync with packaging git repo (for example >> when it lives under salsa.debian.org/debian which uploaders should have >> access to already). > > There are three quite fundamental pieces missing to achieve this. > > There needs to be simple way to turn a git commit into a source package. > If the source of truth ever is to become git, the .dsc becomes an export > format and then this becomes a hard requirement. We can turn git commits > into source packages. The problem is that there is not one way to do > this, but about a hundred and you need to know which package uses which. > That does not scale. > > There needs to be a simple way to figure out the commit that corresponds > to an upload. This problem has been approached in two ways. For one > thing, there is DEP14 recommending a particular tag layout, but I think > this is backwards. It assumes that the git repository is trusted, but in > reality git repositories allow for much wider access than Debian > uploads. What we really needs is a source package to know the commit id > it was generated from. > > These operations need to round-trip. If you take a source package, > identify the git commit and export it to .dsc, it must be functionality > equivalent to what you started with. Timestamps may differ, but file > content or contained files very much not. > > To me, these are hard requirements for using maintainer git > repositories for performing NMUs. > > Now the dgit users among us will be grinning already as what I have > written here, very much reads like a specification of (parts of) dgit. > Once again, I question whether salsa as we use it now is the solution or > the problem. I note that it is practically possible to push your dgit > history to salsa and then NMUers can easily do meaningful MRs for their > uploads even when your maintainer git has changes that have not yet been > uploaded. Well, quite, this is dgit indeed. -- Sean Whitton signature.asc Description: PGP signature
Re: Most optimal way to import NMU into existing git-builpackage repository?
Hello, On Sat 26 Oct 2024 at 09:31am GMT, Holger Levsen wrote: > On Fri, Oct 25, 2024 at 03:03:53PM +, Holger Levsen wrote: >> the current expectation is that an NMU bug is opened, which contains >> the debdiff. >> >> https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#when-and-how-to-do-an-nmu >> >> "... Then, you must send a patch with the differences between the current >> package and your proposed NMU to the BTS. The nmudiff script in the >> devscripts package might be helpful" > > FWIW, I think this should stay the default when doing NMUs but I also think > it should be (spelled out that it's) equally fine to open a MR on salsa > *if* the specific package somehow specifies this is ok. > > I also think that currently no package should be able to opt-out from > getting NMUdiffs via the BTS, because it's good to have one workflow which > works for *all* packages. I think so to. -- Sean Whitton signature.asc Description: PGP signature
Bug#1086660: ITP: qt6-graphs -- Qt Graphs for data visualization
Package: wnpp Severity: wishlist Owner: Patrick Franz X-Debbugs-Cc: debian-devel@lists.debian.org, delta...@debian.org, debian-qt-...@lists.debian.org * Package name: qt6-graphs Version : 6.7.2 Upstream Contact: The Qt Company * URL : https://www.qt.io/developers/ * License : GPL, BSD Programming Lang: C++ Description : Qt Graphs for data visualization The Qt Graphs module enables one to visualize data in 2D and 3D graphs. Package will be maintained by the Debian Qt/KDE team.
Bug#1086664: ITP: klevernotes -- Note taking and management application
Package: wnpp Severity: wishlist Owner: Patrick Franz X-Debbugs-Cc: debian-devel@lists.debian.org, delta...@debian.org, debian-qt-...@lists.debian.org * Package name: klevernotes Version : 1.1.0 Upstream Contact: KDE * URL : https://invent.kde.org/office/klevernotes * License : GPL, LGPL Programming Lang: C++ Description : Note taking and management application KleverNotes is a note taking and management application. It uses markdown and allow you to preview your content. Package will be maintained in the Debian Qt/KDE team.
Bug#1086691: ITP: python-quart-trio -- Extension for Quart to support the Trio event loop
Package: wnpp Severity: wishlist Owner: Colin Watson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-quart-trio Version : 0.11.1 Upstream Contact: pgjones * URL : https://github.com/pgjones/quart-trio * License : Expat Programming Lang: Python Description : Extension for Quart to support the Trio event loop Quart-Trio is an extension for Quart (an async Python web microframework) to support the Trio event loop. This is an alternative to using the asyncio event loop present in the Python standard library and supported by default in Quart. I'm packaging this because it's a test dependency of new upstream versions of python-urllib3. I plan to maintain it within the Debian Python Team. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Most optimal way to import NMU into existing git-builpackage repository?
Hello, On Wed 30 Oct 2024 at 01:24pm GMT, Otto Kekäläinen wrote: > I can (and I did test already) do a merge with --allow-unrelated > histories, but dgit history always has patches applied as separate > commits that get rebased and thus there is no quilt/gbp pq -compatible > git history to merge from. If I later do a 'dgit --gbp push' to > upload, how do I push a development version to Salsa for review and CI > testing? If the NMU was done with dgit, then dgit only appends commits to apply the patches. Thus if you look a few commits back in history, you'll find something you can merge. > Based on docs and your previous replies it isn't possible, thus `gbp > import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid` still > seems to stand as the optimal way to import NMUs onto a Debian > packaging git repo? If the upload was not done with dgit, then probably, yes. > The man pages of dgit are extensive and explains well how to interact > with the Debian repository as if it was a git repository, but I am > unable to find descriptions of how to use dgit in team maintained > packages with testing and reviews prior to uploads. The idea is that dgit is only needed when dealing with source packages. When collaborating with team members prior to upload, you don't really need any source packages -- you just build straight out of git. If you can identify a place in the docs where some reference to this could be added that would have been helpful to you, a patch would be very welcome. -- Sean Whitton signature.asc Description: PGP signature
Re: Binary uploads into the archive
Hello Dennis, Am 29.10.24 um 14:56 schrieb Dennis van Dok: On 28-10-2024 22:09, Daniel Leidert wrote: Hi, by accident, I uploaded a binary package today (ruby-rouge) instead of its source-package into the archive. I expected the binary package being rejected once I discovered my mistake. But it was accepted instead, and it was also not being rebuilt. Didn't we turn off binary package uploads? Shouldn't this be rejected? Coincidentally did the exact same thing (with igtf-policy-bundle); but this is now stuck as it cannot migrate to testing (unless somebody manually intervenes). I think what I should do is update the release number and do another (source only) upload. You can do a new upload by increasing the revision number and an entry in changelog that this is an source only upload. Dennis Regards -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F OpenPGP_signature.asc Description: OpenPGP digital signature
