Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Thu, May 28, 2020 at 6:33 PM Roland Plüss wrote: > What path do you think should I choose to be best conform with Debian? I would package the games into Debian packages so that the source data/code is available and built by the Debian packaging, using paths something like /usr/share/dlauncher/games/. For games that don't have Debian packages (I guess you plan to have a central store or something), install the games to the ~/.local/share/dlauncher/games/ dir since different users will want different sets of games installed. You could also add a directory in /usr/local that the sysadmin could install games to for all users if they want. -- bye, pabs https://wiki.debian.org/PaulWise
Re: mentor
On Thu, May 28, 2020 at 3:27 PM Joachim Bauernberger wrote: > I've created an ITP[1] and am looking for some guidance on putting this > package[2] into sid. Check out our guide and especially the RFS (request for sponsor) howto: https://mentors.debian.net/intro-maintainers https://mentors.debian.net/sponsors/rfs-howto > Since I have time I'd also be very interested in helping out on various > activities There are lots of different ways to help Debian, some are listed here: https://www.debian.org/intro/help -- bye, pabs https://wiki.debian.org/PaulWise
Bug#960162: marked as done (RFS: mgba/0.8.1+dfsg-1 -- Game Boy Advance emulator)
Your message dated Thu, 28 May 2020 18:19:40 -0700
with message-id <20200529011940.gb...@t570.nardis.ca>
and subject line Re: RFS: mgba/0.8.1+dfsg-1 -- Game Boy Advance emulator
has caused the Debian Bug report #960162,
regarding RFS: mgba/0.8.1+dfsg-1 -- Game Boy Advance emulator
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
960162: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960162
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal
Dear mentors and games team,
I have packaged the new upstream version of mgba and am looking for a
sponsor to upload it.
This is a package hijack as I have not been able to contact Sérgio (also
including him in X-D-CC here). I am interested in (co-)maintaining mgba
going forward. I'm not a member of the Games Team but I'm willing to
join if needed. I took the liberty of adding myself to Uploaders here.
There are a couple of lintian warnings about libmgba. The warnings are
not new; I think it has always been packaged this way. It's a private
library used only by mgba-{sdl,qt} and I don't think versioning the
package name is useful. I can look into patching the build system to
install it somewhere more private (i.e. /usr/lib/${D_H_M}/mgba) but it
would be great if that didn't have to block this upload.
The package is on mentors.d.n:
https://mentors.debian.net/package/mgba
https://mentors.debian.net/debian/pool/main/m/mgba/mgba_0.8.1+dfsg-1.dsc
I don't have access to the games-team git repo, therefore I forked the
repo under my own namespace. The changes are here:
https://salsa.debian.org/rtandy/mgba (master, upstream, pristine-tar)
The package builds successfully in Salsa-CI and I tested all three
frontends (sdl, qt, and retroarch).
Changes since the last upload:
* New upstream release. (Closes: #950820)
* Exclude vendored rapidjson; add Build-Depends: rapidjson-dev.
- CMakeLists.txt: don't install excluded res/licenses/rapidjson.txt.
* Exclude vendored inih; add Build-Depends: libinih-dev. (Closes: #958247)
- CMakeLists.txt: don't install excluded res/licenses/inih.txt.
* Update debian/copyright with newly added third-party licenses.
* Update Build-Depends: cmake >= 3.1 (since 0.7.0).
* Add Build-Depends: libavfilter-dev to re-enable GIF/Video recording
feature.
* Update Standards-Version to 4.5.0. No changes needed.
* Drop -Wl,--as-needed as this is now the default.
* Update to debhelper compat level 13.
- libretro-mgba.install: Use built-in substitution instead of dh-exec.
- Update *.install and *.manpages to install from debian/tmp.
- Add debian/not-installed.
* Drop patch 01_fix-about-strings. The patch was out of date and the git
revision info is not required since we build from a release tarball.
* Add debian/gitlab-ci.yaml for CI build.
* Add myself to Uploaders.
Thank you,
Ryan
--- End Message ---
--- Begin Message ---
I have been granted membership in the games team and the upload has been
sponsored inside the team.--- End Message ---
Assist in maintaining a package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, The Drawing package needs attention today, the 28th, completes three months without updates, and Buster does not have an alternative to MyPaint and I needed one that could be present in Backports and I can attest that it is 100% compatible. With that in mind, I offer to help maintain the package in Debian and follow the upstream. The maintainer maintains several packages and I intend only to help maintain it, which is Andrej Shadura who is Debian Developer. I dedicated time and tested a packing for this package with NMU (non maintainer update). I did this by following the Debian developers reference for assistance. It was presented as novelty for version of Mint 19.3 release in finish of 2019. I even drew attention to Mailing List debian-devel about bug report in open, asking to update with date of 29th of February. Grateful for a help. Links of reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952788 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952117 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961482 https://gitlab.com/leandrocunha123/drawing/ https://tracker.debian.org/pkg/drawing https://lists.debian.org/debian-devel/2020/05/msg00273.html https://github.com/maoschanz/drawing https://salsa.debian.org/debian/drawing https://wiki.debian.org/NonMaintainerUpload https://www.debian.org/doc/manuals/developers-reference/pkgs.html https://wiki.debian.org/Packaging https://www.linuxmint.com/rel_tricia_cinnamon_whatsnew.php https://mentors.debian.net/ https://lists.debian.org/debian-mentors/ https://lists.debian.org/debian-devel/ https://www.debian.org/devel/ Leandro Cunha GPG ID: 9cf7f2c8d1b25c57 IRC: leandrocunha -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEysaC+eNLfZD4qp+5nPfyyNGyXFcFAl7QVOEACgkQnPfyyNGy XFc1eg/+LHj855lLu2P7srRFCU/sR1A6WmuIvuX4O0alubhn8McMXuV5QsxBJ2NK JUs+UC2me3HbaZqAj87B8H7KOBtlYdERj9XDk2q5gQ8Q75fkmtOonUQjvqGag0Ud qCLlTRomT0gOj9/ldIT4pgQeKig9PFGV2IChdPx+pCaguw0iWCBizPQpidQDm0qc kRGGF9TefDj/2S0uxgjpHanZdwHe9YUtQe6zeYlCkEqNk4RGnSwwRUYw59cc9cmZ 8sqKRtFU4EKfQ0Sgf6/hssdb4IjSptHDOrjV+PvYrbLo7C98Llqn9vyjkQN6PTh8 hq3qNt//Xa1zO04qkwmXCbww1zomAw/vUkK50lGcmyS2SfFawDWXEUpo9qJZF+BC IIJPGfowZ+0vMYSeCLaDKGAS64HAcMT4uhYD5Z9CX5osEjrmtPbEa/p2wRHA1C/5 yjeF4vDxs2qjQ9L8B6yAoZvY0T7TT+ybXb9fRBglKZk8oIIIFV8Eossv7lbJLxzE U0IllsghhXIEe2WKYD5yyQFvUfAnv0HMnPUs4/9CyVW8YzeJYcqeiFFZ8ezMmhBG GF0m1UGllW/C9XRipPeH3YUS2G01OfguZBeEUDhhCX+u18xYlsyBKVqsGlvXEOqt MQx3TrxJGF07TmZyk9kd1Ozx1DR0Wz/nZV1A3NZAa8VC8YysIgM= =HdF1 -END PGP SIGNATURE-
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
Hi, > Hi, > > Long story short, this hasn't reached a satisfactory quality. I will > point out issues > I found but there are more to fix. > * Please make sure the debian/files file does not exist in your packaging added "rm" to the clean step. > * Your debian/postinst script is missing the #DEBHELPER# placeholder. fixed > * Your debian/postinst file has to recognize whether it is being called during installation, upgrade or removal. modified the postinst to operate only on "configure" > * Official Debian packages in "main" section should not manipulate files under /opt/ directory at any time. this one will be interesting. the /opt/delauncher/games is where the user installs to the games he wants to play. in my opinion these are optional packages the user manually installs and uninstalls. That said this path can be configured at compile time. According to a page on the internet about FHS+Games (http://www.roguebasin.com/index.php?title=Filesystem_hierarchy_standard_for_game_developers) these possible locations are named (terms I used from that page): - /usr/games/: standard installation - /usr/share/games/: architecture-independent static game data "*.delga" files contain by definition no binary code, only data and script code (depending on what the developer chooses) and thus are never executable. From this point of view the "architecture-independent static game data" directory seems a suitable choice. This directory would then be /usr/share/games/delauncher/games . But the user (I choose group "games" to be part of) has to have write access to this directory so he can install/uninstall *.delga files. In this situation the "standard installation" seems better. This would then be /usr/games/delauncher/games . What path do you think should I choose to be best conform with Debian? > * You are using "3.0 (native)" format, which is not suitable for a non-Debian-specific project. modified file. > * Your "Build-Depends" field is missing way too many build dependencies. Looks like the changes to debian/control did not commit correctly. Pardon me for having overlooked this. I'll fix it right away. > * Your package bundles way too many external libraries under /extern/ directories. These are used for the "live-mode" build. Only three of them are actually used because the respective debian package is not existing or failing configure. I've added now "debian/source/options" with "tar-ignore" lines for each not used external file. I hope this helps. I'll re-upload with these changes. I would then appreciate more reviewing to iron out the remaining problems as good as i can. -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Re: cmake help needed for metabat
Hi,
Le 28/05/2020 à 20:33, Andreas Tille a écrit :
> Hi,
>
> I'm trying to package metabat[1] in the COVID-19 effort of the Debian
> Med team. I went forward with tweaking cmake but I'm now struck with:
>
> [...]
> CMake Error at src/CMakeLists.txt:39 (add_dependencies):
> The dependency target "zlib" of target "metabat1" does not exist.
>
> ...
>
> This is strange since in the beginning zlib and htslib were found
> due to the means I did. Any hint would be welcome.
>
> Kind regards
>
>Andreas.
>
> [1] https://salsa.debian.org/med-team/metabat
>
There is a Debian patch that replace cmake/htslib.cmake with a
pkg_check_modules call, which doesn't create targets, so that why it fails.
There is the same issue with zlib, and a missing header
"metabat_version.h" created by cmake/git-watcher.cmake.
About HTSlib issue
--
With pkgconfig, you instead get just variables (no target), including
these interesting ones:
- HTSlib_LIBRARIES
- HTSlib_INCLUDE_DIRS
(The HTSlib comes from the first argument of pkg_check_modules)
In cmake version 3.6 and later, an argument to pkg_check_modules can
create a target to be used with target_link_libraries that will take
care of the libraries and include dirs.
This is the IMPORTED_TARGET option, it will create a target named
PkgConfig::.
So you can have:
```
pkg_check_modules(HTSlib REQUIRED IMPORTED_TARGET htslib)
```
and then use it:
```
target_link_libraries(target [...] PkgConfig::HTSlib)
```
But metabat seems to require only cmake 3.5, so it might not be allowed
for upstream to do that.
Instead you can just do the same as done for Boost and add:
```
include_directories(${HTSlib_INCLUDE_DIRS})
```
and
```
target_link_libraries(target [...] ${HTSlib_INCLUDE_DIRS})
```
About zlib issue
FindPackage(ZLIB) don't create any "zlib" target, but a "ZLIB::ZLIB"
target instead, which can be used with target_link_libraries.
So you can just replace the add_dependencies(target zlib) with a new
item there:
```
target_link_libraries(target [...] ZLIB::ZLIB)
```
About the metabat_version.h header issue
cmake/git-watcher.cmake generate metabat_version.h from
metabat_version.h.in.
So as with the patch, git-watcher.cmake is not used anymore, you still
need to handle that.
Either put fake stuff like this:
```
set(PRE_CONFIGURE_FILE "metabat_version.h.in")
set(POST_CONFIGURE_FILE "metabat_version.h")
# include(cmake/git-watcher.cmake)
# Add this:
set(GIT_RETRIEVED_STATE "")
set(GIT_HEAD_SHA1 "nosha")
set(GIT_IS_DIRTY 0)
set(BUILD_TIMESTAMP 0)
configure_file("${PRE_CONFIGURE_FILE}" "${POST_CONFIGURE_FILE}" @ONLY)
include_directories("${CMAKE_CURRENT_BINARY_DIR}")
```
Or you change directly the code that use these defines to use different
data (like Debian version instead).
Conclusion
--
I'm attaching a patch with what I've said here.
The build still doesn't work because of tests failure.
The tests require data files like "contigs_depth.txt" but can't find them.
In test/CMakeLists.txt, there is a reference to them as
"${CMAKE_BINARY_DIR}/contigs_depth.txt", but it should be
"${CMAKE_CURRENT_SOURCE_DIR}/contigs_depth.txt", unless the text files
should be copied while building, but that doesn't seem the case.
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
diff --git a/debian/patches/use_debian_packaged_libs.patch
b/debian/patches/use_debian_packaged_libs.patch
index 05c4a0e..b532dc9 100644
--- a/debian/patches/use_debian_packaged_libs.patch
+++ b/debian/patches/use_debian_packaged_libs.patch
@@ -1,7 +1,15 @@
-Author: Andreas Tille
+From: Andreas Tille
+Date: Thu, 28 May 2020 21:21:02 +0200
+Subject: Use Debian packaged libraries
+
Last-Update: Thu, 28 May 2020 17:21:42 +0200
-Description: Use Debian packaged libraries
+---
+ CMakeLists.txt | 15 ---
+ src/CMakeLists.txt | 8
+ 2 files changed, 16 insertions(+), 7 deletions(-)
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 638c27c..6166143 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -8,8 +8,10 @@ endif()
@@ -17,32 +25,52 @@ Description: Use Debian packaged libraries
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
-@@ -23,7 +25,7 @@ add_definitions(-D_XOPEN_SOURCE=700)
+@@ -23,7 +25,14 @@ add_definitions(-D_XOPEN_SOURCE=700)
set(PRE_CONFIGURE_FILE "metabat_version.h.in")
set(POST_CONFIGURE_FILE "metabat_version.h")
-include(cmake/git-watcher.cmake)
+# include(cmake/git-watcher.cmake)
++set(GIT_RETRIEVED_STATE "")
++set(GIT_HEAD_SHA1 "nosha")
++set(GIT_IS_DIRTY 0)
++set(BUILD_TIMESTAMP 0)
++configure_file("${PRE_CONFIGURE_FILE}" "${POST_CONFIGURE_FILE}" @ONLY)
++include_directories("${CMAKE_CURRENT_BINARY_DIR}")
++
if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
# using Clang
+diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
+index d47843e..b8dc3b9 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
-@@ -36,7 +36,7
Bug#961527: RFS: vnstat/2.6-2 -- console-based network traffic monitor
Am Mo., 25. Mai 2020 um 23:09 Uhr schrieb Adam Borowski : > > This will make the package likely to FTBFS whenever the default compiler is > upgraded, someone tries to build with clang, etc. It's usually a bad idea > but somewhat manageable if you're looking carefully. In Debian proper, that > is -- derivatives will be pretty unhappy. > > ... but you also have -Wextra which makes the above FTBFS guaranteed. > > I'd say uploads with this combo belong in experimental -- a worthy > development check -- but not in in a suite that's going to be released (and > most derivatives have a different cadence than Debian). > I thought as upstream is quite wide checked [1], this might help to detect possible issue on uncommon architectures (as the build-warnings helper on PTS is somewhat unreliable). Uploaded a new version without enabling -Werror. [1]: https://github.com/vergoh/vnstat/blob/master/.travis.yml
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dragengine" * Package name : dragengine Version : 1.1 Upstream Author : rol...@rptd.ch * URL : https://dragondreams.ch * License : LGPL-3.0+ * Vcs : upstream debianization branch: https://github.com/LordOfDragons/dragengine/tree/debian Section : x11 It builds those binary packages: dragengine - Drag[en]gine Game Engine dragengine-dev - Drag[en]gine Game Engine Development deigde - Drag[en]gine Game Development Environment deigde-dev - Drag[en]gine IGDE Development To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dragengine Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dragengine/dragengine_1.1.dsc Changes since the last upload: * Initial debianization. Regards, -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
cmake help needed for metabat
Hi, I'm trying to package metabat[1] in the COVID-19 effort of the Debian Med team. I went forward with tweaking cmake but I'm now struck with: Installing None MetaBAT into /usr -- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11"). -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2"). -- Checking for module 'htslib' -- Found htslib, version 1.10.2-3 -- Found Boost: /usr/include (found suitable version "1.67.0", minimum required is "1.55.0") found components: program_options filesystem system graph serialization iostreams regex. ... -- Configuring done CMake Error at src/CMakeLists.txt:51 (add_dependencies): The dependency target "htslib" of target "contigOverlaps" does not exist. CMake Error at src/CMakeLists.txt:51 (add_dependencies): The dependency target "zlib" of target "contigOverlaps" does not exist. CMake Error at src/CMakeLists.txt:51 (add_dependencies): The dependency target "htslib" of target "jgi_summarize_bam_contig_depths" does not exist. CMake Error at src/CMakeLists.txt:51 (add_dependencies): The dependency target "zlib" of target "jgi_summarize_bam_contig_depths" does not exist. CMake Error at src/CMakeLists.txt:39 (add_dependencies): The dependency target "htslib" of target "metabat2" does not exist. CMake Error at src/CMakeLists.txt:39 (add_dependencies): The dependency target "zlib" of target "metabat2" does not exist. CMake Error at src/CMakeLists.txt:39 (add_dependencies): The dependency target "htslib" of target "metabat1" does not exist. CMake Error at src/CMakeLists.txt:39 (add_dependencies): The dependency target "zlib" of target "metabat1" does not exist. ... This is strange since in the beginning zlib and htslib were found due to the means I did. Any hint would be welcome. Kind regards Andreas. [1] https://salsa.debian.org/med-team/metabat -- http://fam-tille.de
mentor
dear list, I've created an ITP[1] and am looking for some guidance on putting this package[2] into sid. Since I have time I'd also be very interested in helping out on various activities and maybe eventually even become a maintainer one day. thanks in advance & warm regards, Joachim [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961200 [2] https://gitlab.com/jbauernberger/nfq/
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
Hi, (see bottom) Roland Plüss 于2020年5月28日周四 上午10:45写道： > > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "dragengine" > > * Package name : dragengine > Version : 1.1 > Upstream Author : rol...@rptd.ch > * URL : https://dragondreams.ch > * License : LGPL-3.0+ > * Vcs : upstream debianization branch: > https://github.com/LordOfDragons/dragengine/tree/debian > Section : x11 > > It builds those binary packages: > > dragengine - Drag[en]gine Game Engine > dragengine-dev - Drag[en]gine Game Engine Development > deigde - Drag[en]gine Game Development Environment > deigde-dev - Drag[en]gine IGDE Development > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/dragengine Long story short, this hasn't reached a satisfactory quality. I will point out issues I found but there are more to fix. * Please make sure the debian/files file does not exist in your packaging. This file is automatically created and should not be created manually. * Your debian/postinst script is missing the #DEBHELPER# placeholder. * Your debian/postinst file has to recognize whether it is being called during installation, upgrade or removal. See https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html for details. I guess the best way is to take a look at existing postinst scripts written by others. * Official Debian packages in "main" section should not manipulate files under /opt/ directory at any time. Your package will be part of the system, not some so called "Optional application software packages". Please place files following the File Hierarchy Standard (FHS) using directories under /usr/. * You are using "3.0 (native)" format, which is not suitable for a non-Debian-specific project. See https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#native-dh-make for details. Please use "3.0 (quilt)" format. * Your "Build-Depends" field is missing way too many build dependencies. An easy example is that if scons is not installed on your system, your package surely cannot build. Please list all non-trivial build-dependencies required to build your package. See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydeps for details. * Your package bundles way too many external libraries under /extern/ directories. You must either document license information for those project or exclude those files from your source code. If building your package needs those libraries, please use existing libraries in current Debian archive. There are other issues but I'd rather stop here. Since you yourself is also the upstream, it could be possible for you to actually review the software buildsystem (scons scripts) since it seems to have diverted from traditional software installation procedures on UNIX-like platforms. In any case, the source repository and packaging scripts your provided need improvement. -- Regards, Boyuan Yang
Bug#948262: who can sponsor for special keyboard input
Got it, thanks! I am fix and update. Could you please check for me. On Thu, May 28, 2020, 2:54 PM Kyle Robbertze wrote: > Control: tags -1 moreinfo > > Hi, > > After reviewing the package, there are a couple things I noticed: > > - Missing copyright info for the following files: > * ./m4/* > * ./INSTALL > * ./aclocal.m4 > * ./config.rpath > * ./install-sh > - The watch file is broken - it points to your packaging repo. It should > use the upstream launchpad repo > - The changelog should only have 'Initial packaging (Closes: #933071)' > as the change list. The other change lines are not needed. > - The package builds a lot of binary packages with 1 file each. Is this > necessary? Consider combining everything into one or two packages > > Cheers > Kyle > -- > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze > ⢿⡄⠘⠷⠚⠋⠀ Debian Developer > ⠈⠳⣄ https://wiki.debian.org/KyleRobbertze >
Bug#948262: who can sponsor for special keyboard input
Control: tags -1 moreinfo Hi, After reviewing the package, there are a couple things I noticed: - Missing copyright info for the following files: * ./m4/* * ./INSTALL * ./aclocal.m4 * ./config.rpath * ./install-sh - The watch file is broken - it points to your packaging repo. It should use the upstream launchpad repo - The changelog should only have 'Initial packaging (Closes: #933071)' as the change list. The other change lines are not needed. - The package builds a lot of binary packages with 1 file each. Is this necessary? Consider combining everything into one or two packages Cheers Kyle -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze ⢿⡄⠘⠷⠚⠋⠀ Debian Developer ⠈⠳⣄ https://wiki.debian.org/KyleRobbertze
