Bug#1064178: RFS: xwayland-run/0.0.2-1 [ITP] -- Set of utilities to run headless X/Wayland clients
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "xwayland-run": * Package name : xwayland-run Version : 0.0.2-1 Upstream contact : Olivier Fourdan * URL : https://gitlab.freedesktop.org/ofourdan/xwayland-run * License : GPL-2.0+ * Vcs : https://salsa.debian.org/vimerbf-guest/xwayland-run Section : x11 The source builds the following binary packages: xwayland-run - Set of utilities to run headless X/Wayland clients To access further information about this package, please visit the following URL: https://mentors.debian.net/package/xwayland-run/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/x/xwayland-run/xwayland-run_0.0.2-1.dsc Changes for the initial release: xwayland-run (0.0.2-1) UNRELEASED; urgency=low . * Initial release. (Closes: #1061513) -- Regards, -- Bo YU signature.asc Description: PGP signature
Bug#1064087: RFS: asn/0.75.3-1 [ITP] -- network OSINT CLI ASN, RPKI, BGP, Geo, Recon, Trace
On Friday, February 16 2024, Marcos Rodrigues de Carvalho wrote: > Dear mentors, > > I am looking for a sponsor for my package "asn": Thanks, Marcos. Here's my review. * d/copyright: The full name of the package author is available in the LICENSE file. You need to use it when writing the d/copyright entry. * d/control: I've never seen X-Lintian-Overrides before, and I don't think it's recognized by Lintian. Please remove it (and add a proper lintian-overrides file if necessary). * d/watch: Minor nitpick, but the file doesn't end with a newline. * d/manpage/asn.1 Thanks for writing a manpage! Did you write it manually, or did you use some software to generate it? If the latter, then I'd suggest adding the original source for the manpage and generating it during build time. I have a few comments about its style: - I believe the "TARGET" section needs be better organized. I think you should itemize each possible target and separate them with a newline or something. - Same comment for "SERVER OPTIONS". In fact, according to the README file, there are a few more server options than what you're listing. - You forgot to edit the "AUTHOR" section :-). * General comments: You're using gbp, and you chose a non-standard branch name for the master (Debian) branch. Therefore, you need to provide a d/gbp.conf which teaches gbp how to find your Debian branch. Also, unless you have a very good reason not to, this package should be placed under the "debian" namespace on Salsa. I can create a repository there and give you permissions if you want. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
How to handle submodules that are not packaged
Dear Mentors, I have been looking for information on how to handle the submodule of a project that is not or cannot be packaged for Debian. Say a project I want to package has the submodule registered at externals/foo/bar. For whatever reason Bar doesn't exist in the repositories. How do I handle this as a packager? To give an actual example of what I mean, the upstream yuzu repository (https://github.com/yuzu-emu/yuzu) has a submodule at externals/sirit. The yuzu package moves this into the top directory with a rule in debian/rules that creates a symbolic link in externals/. As yuzu is the only real example I can find of this situation, I was wondering if there are any other ways to handle this. More importantly, if there are other ways how would they be handled on the Salsa side i.e. a package repository with upstream/ and debian/ branches? Any insight would be greatly appreciated. Regards, David James
