Bug#1076362: ITP: python-proton-core -- Proton Technologies API wrapper

[Simon McVittie]

On Sun, 14 Jul 2024 at 23:24:27 -0300, Josenilson Ferreira da Silva wrote:
>   used by the other Proton components

I think it would be worthwhile for the description to say "ProtonVPN"
or similar, rather than just "Proton", to distinguish ProtonVPN from
(for example) Valve's Proton framework as described in
.

smcv

Bug#1064457: RFP: composefs -- file system for mounting container images

[Simon McVittie]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: ost...@packages.debian.org

* Package name: composefs
  Version : 1.0.3
  Upstream Contact: Alexander Larsson, Colin Walters
* URL : https://github.com/containers/composefs
* License : GPL-3.0-or-later AND LGPL-2.0-or-later AND Apache-2.0
  Programming Lang: C
  Description : file system for mounting container images

The composefs project combines several underlying Linux features to
provide a very flexible mechanism to support read-only mountable
filesystem trees, stacking on top of an underlying "lower" Linux
filesystem.

The key technologies composefs uses are:

  * overlayfs as the kernel interface
  * EROFS for a mountable metadata tree
  * fs-verity (optional) from the lower filesystem

---

libostree optionally uses composefs to mount OS images. At the moment it
uses a vendored copy of composefs, but there is movement upstream towards
using composefs as an external shared library and de-vendoring it. When
this happens, I will have to disable the composefs feature in src:ostree
until/unless composefs is packaged separately.

My interest in libostree is mainly for Flatpak, which doesn't use
composefs anyway, so I am not able to take responsibility for composefs as
a separate package; but I'd be fine with linking to an external composefs
maintained by someone else, if that's useful for a different use-case.

Bug#1060319: ITP: sdl2-compat -- SDL 2 binary compatibility library wrapping SDL 3

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
debian-devel-ga...@lists.debian.org, pkg-sdl-maintain...@lists.alioth.debian.org

* Package name: sdl2-compat
  Version : currently 2.28.50~git20240108
  Upstream Contact: https://github.com/libsdl-org/sdl2-compat/issues
* URL : https://github.com/libsdl-org/sdl2-compat
* License : mainly Zlib, with various other permissive licenses
  Programming Lang: C
  Description : SDL 2 binary compatibility library wrapping SDL 3

 sdl2-compat provides a binary compatible API for programs built
 against SDL 2, but using SDL 3.
 .
 If you are writing new code, please target SDL 3 directly (when it
 becomes stable) instead of using this layer. Debian packages should not
 depend or build-depend on this package: please use libsdl2-2.0-0
 and libsdl2-dev instead.

---

ITP on behalf of the SDL team, with much of the packaging and testing
being done as part of my work at Collabora Ltd. A prerelease version
is here: https://salsa.debian.org/sdl-team/sdl2-compat

SDL 3 (in experimental) is not yet API- or ABI-stable, so "real" SDL 2
(src:libsdl2) continues to be the recommended runtime library for
SDL games and other applications for now.

When SDL 3 and sdl2-compat become stable, we will want to replace "real"
SDL 2 with sdl2-compat (it's a drop-in replacement), the same way "real"
SDL 1.2 was replaced with sdl12-compat after the Debian 12 release. I
expect that SDL upstream will eventually stop producing new releases
of "real" SDL 2 at all, and expect all SDL 2 users to replace it with
sdl2-compat, the same way they already discontinued "real" SDL 1.2.

Until we're ready for that transition, the sdl2-compat packaging will
be very similar to the way sdl12-compat was packaged in Debian 12, with
the main package being a non-default library that can be substituted
via the SDL_DYNAMIC_API or LD_LIBRARY_PATH environment variables.

As with SDL3, I want to get this into experimental well before it is
ready for production use, so that it isn't too late to feed back test
results and structural change suggestions to upstream.

Bug#1057088: RFA: ikiwiki-hosting -- ikiwiki hosting: common files

[Simon McVittie]

Package: wnpp
Severity: normal
X-Debbugs-Cc: ikiwiki-host...@packages.debian.org, ikiw...@packages.debian.org, 
anar...@debian.org, intrig...@debian.org, j...@freedesktop.org
Control: affects -1 + src:ikiwiki-hosting

As with ikiwiki, I have not been active in ikiwiki-hosting for a while
and I would like to hand over primary responsibility for it in Debian
to someone else.

It would probably make sense for ikiwiki and ikiwiki-hosting to have
the same maintainer. The main thing I have been looking into in recent
years in ikiwiki-hosting is trying to migrate from LSB init scripts and
cron jobs to native systemd services and timers.

The package description is:
 A hosting interface for ikiwiki. Facilitates management of many separate
 ikiwiki sites, with capabilities including web-based signup to create new
 sites, easy support for branching sites, deleting sites, and transferring
 sites between servers. Ikiwiki-hosting was developed for Branchable.com.

Thanks,
smcv

Bug#1057087: RFA: ikiwiki -- wiki compiler

[Simon McVittie]

Package: wnpp
Severity: normal
X-Debbugs-Cc: ikiw...@packages.debian.org, anar...@debian.org, 
intrig...@debian.org, j...@freedesktop.org
Control: affects -1 + src:ikiwiki

I have not been actively developing ikiwiki for quite a while and I have
too many other responsibilities in Debian, so I would like to hand over
maintenance of ikiwiki to someone else.

The project is not particularly active upstream, so any significant changes
will likely require getting involved upstream if you are not already.

The package description is:
 Ikiwiki converts a directory full of wiki pages into HTML pages suitable
 for publishing on a website. Unlike many wikis, ikiwiki does not have its
 own ad-hoc means of storing page history, and instead uses a revision
 control system such as Subversion or Git.
 .
 Ikiwiki implements all of the other standard features of a wiki, including
 web-based page editing, user registration and logins, a RecentChanges
 page, BackLinks, search, Discussion pages, tags, smart merging and conflict
 resolution, and page locking.
 .
 Ikiwiki also supports generating news feeds (RSS and Atom) and blogging.
 Ikiwiki provides a plugin system which allows many other features to be
 added. Some of the plugins have additional dependencies, found among the
 Recommends and Suggests of this package.

Thanks,
smcv

Bug#1057086: RFA: bmap-tools -- tool to flash image files to block devices using the block map

[Simon McVittie]

Package: wnpp
Severity: normal
X-Debbugs-Cc: bmap-to...@packages.debian.org, sjo...@debian.org, 
andre...@debian.org
Control: affects -1 + src:bmap-tools

I'm responsible for too many things and I'd like to hand over bmap-tools
to someone else.

Upstream has basically no time for this particular package, so maintaining
bmap-tools is likely to involve becoming an upstream contributor or even
co-maintainer in order to fix bugs, particularly if there are
incompatibilities with newer Python or other dependencies.

Thanks,
smcv

Bug#1040005: ITP:magpie - window manager for the budgie desktop

[Simon McVittie]

On Fri, 30 Jun 2023 at 21:59:48 +0100, David Mohammed wrote:
> Package name : magpie
...
>  Magpie is a soft-fork of GNOME mutter v43.x tailored for the requirements
>  of the budgie-desktop.

I saw that this was in the NEW queue for a while, but then disappeared.
Did the ftp team have concerns about it?

Because budgie-desktop-environment currently depends on libmutter 43/44,
and future versions want to move to libmagpie rather than mutter 45,
getting this package into unstable is a blocker for being able to
finish getting GNOME 45 into unstable.

smcv

Bug#1038946: ITP: xdg-desktop-portal-xapp -- Xapp's Cinnamon, MATE and Xfce backends for xdg-desktop-portal

[Simon McVittie]

On Fri, 23 Jun 2023 at 16:50:01 +0200, Fabio Fantoni wrote:
> * Package name    : xdg-desktop-portal-xapp

Please make sure to apply
https://github.com/linuxmint/xdg-desktop-portal-xapp/commit/86a1cb27eff487f6245319e850c1c560a8ba33ed
via debian/patches (unless it has got into an upstream release before
your upload), so that it won't break other desktop environments.

Thanks,
smcv

Bug#1038830: RFP: haskell-sdl2-mixer -- Haskell bindings for SDL2_mixer

[Simon McVittie]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-hask...@lists.debian.org
Control: block 1038088 by -1

* Package name: haskell-sdl2-mixer
  Version : 1.2.0.0
  Upstream Contact: Siniša Biđin, Daniel Firth
* URL : https://hackage.haskell.org/package/sdl2-mixer
* License : MIT
  Programming Lang: Haskell
  Description : Haskell bindings for SDL2_mixer

A new upstream release of raincat has been ported to SDL2, but will
presumably need updated dependencies.

Bug#1038828: RFP: haskell-sdl2-image -- Haskell bindings for SDL2_image

[Simon McVittie]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-hask...@lists.debian.org
Control: block 1038088 by -1

* Package name: haskell-sdl2-image
  Version : 2.1.0.0
  Upstream Contact: Siniša Biđin, Daniel Firth
* URL : https://hackage.haskell.org/package/sdl2-image
* License : MIT
  Programming Lang: Haskell
  Description : Haskell bindings for SDL2_image

A new upstream release of raincat has been ported to SDL2, but will
presumably need updated dependencies.

(It would probably also be useful if someone who knows Haskell can have
a look at updating raincat and other Haskell games.)

Bug#1029907: ITP: xdg-terminal-exec -- user default terminal execution utility

[Simon McVittie]

On Sat, 28 Jan 2023 at 16:41:28 -0500, Jeremy Bicha wrote:
> This solves a problem: currently you can use update-alternatives to
> choose a default terminal for a Debian system, but what happens when
> you have multiple users on the same Debian system with different
> preferences?

Another problem that it solves is that when there has been no sysadmin
configuration, the ideal default terminal is desktop-dependent, in order
to coordinate with the desktop environment's design and conventions.
If a GNOME user and a KDE/Plasma user share a desktop computer, and they
both launch a terminal app like mutt, the expected result in the absence
of any other configuration is that the GNOME user gets mutt displayed in
a gnome-terminal or maybe gnome-console window, while the KDE user gets
mutt displayed in a Konsole window. There is currently no possible target
for the x-terminal-emulator symlink that will give both users the expected
behaviour: one of them has to get the "wrong" terminal by default.

(I know Jeremy knows this, but other -devel readers might not be aware.)

If xdg-terminal-exec becomes the de facto standard in future, then we
can probably make it a high-priority alternative for x-terminal-emulator
(directly if it's command-line compatible, or via a script if it isn't).

> I don't think the "proposed specification" has been fully drafted yet.
> There is some discussion at
> https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54
> and over the years in the xdg mailing list.

I haven't reviewed xdg-terminal-exec in detail, but at a high level it
seems a lot more promising than making terminals a special case of a
generic "intents" mechanism (which is a broad and vague topic which will
likely take a correspondingly long time to standardize), or standardizing
a D-Bus interface for terminals (which, as much as I like D-Bus as an
implementation for things like o.fd.Application, is not something that
the likes of xterm are ever likely to implement).

However, the fact that the spec hasn't been standardized or even
fully drafted makes me want to avoid adding xdg-terminal-exec to
unstable/bookworm at this late stage of the release cycle: if it gets
through NEW fast enough to be in bookworm and then the spec changes
incompatibly, we'll be stuck with an implementation of the old version
of the spec in Debian 12 for 3 years (+ LTS), which would be really
annoying for cross-distro compatibility, both for us and for upstream.

I think a better route might be to get it into experimental for now, then
when it seems like it has stabilized more, put it into unstable/trixie
and potentially also bookworm-backports.

> More recently, the alpha for glib 2.76 (part of GNOME 44 Alpha) now
> supports xdg-terminal-exec
...
> We might backport the glib feature to Debian
> Bookworm, but it is quite late in Bookworm's release process.

I would be more positive about backporting this change before bookworm
than I am about adding xdg-terminal-exec, because the GLib change is just
that *if* xdg-terminal-exec is found in PATH, then GLib checks for it
in preference to all the other terminals it knows about. If x-t-e is not
found in PATH, then the GLib change has no benefit but also does no harm.

(It also reshuffles the code around terminal selection in a way that
allows more terminals to be added to the list as a 1-line change, which
is a nice side benefit, and in particular would let us fall back to
x-terminal-emulator without causing a huge diffstat and semi-frequent
patch conflicts.)

> and GNOME Terminal 3.46.7 includes the necessary metadata file
...
> The metadata would also need to be added to other terminal emulator
> apps

This part is just the addition of X-ExecArg to the .desktop file, and
a symlink to it in /usr/share/xdg-terminals/, yes? If that's the case
then having this metadata in gnome-terminal and other terminal emulators
seems uncontroversial - it's potentially helpful and unlikely to cause
regressions or incompatibilities.

A summary for those who have not looked into this: X-ExecArg tells
xdg-terminal-exec how to invoke a terminal to run a specific command,
like the "-e" of "xterm -e vi ~/myfile". It's -e for any terminal that
can implement the Debian-specific x-terminal-emulator interface directly,
but some terminal implementations need a different argument like "--"
or no argument at all.

The semantics of running a terminal with its X-ExecArg are similar to
Debian Policy's x-terminal-emulator -e (option parsing stops after that
argument, and arguments are placed directly into an argv without word
splitting or a shell), which seems like the right design. The main reason
why X-ExecArg needs to be per-terminal metadata is that some terminal
emulators historically implemented "-e" as behaving more like "sh -c",
which is not compatible with the desired semantics, but cannot be changed
without a compat/API break (which terminal emulator authors are typically
unwilling to do) or a wrapper script. Using "--" as the X

Bug#1026277: ITP: quadrilateralcowboy -- first-person cyberpunk adventure game

[Simon McVittie]

On Mon, 19 Dec 2022 at 01:16:58 +, James Addison wrote:
> The package won't contain any game data -- only the game engine --
> and so I'd also welcome best practices around how to make it easy for
> players to get the game up-and-running after the package is installed.

If it's a DFSG engine with non-redistributable data, then it will
need to go in the contrib archive area, and please look into teaching
game-data-packager to make an accompanying non-redistributable -data
package on users' systems. Quake 1/2/3, Return to Castle Wolfenstein
and Tyrian are some good examples of games in this situation.

game-data-packager has a declarative language for how to unpack common
archive file types and which data files need to be extracted from them.
If the game data is free to download and there is a convenient download
URL (like Tyrian and the shareware/demo versions of Quake 1 and 2),
then it can do the download and repackaging automatically. If the
game data costs money (like RTCW, Quake 3, and full versions of Quake
1 and 2), g-d-p can extract it from a Steam installation or download
from GOG with lgogdownloader, if applicable. Either way, if the user
has a pre-downloaded copy, they can pass that into g-d-p as a command
line argument.

I see QC is on Steam (should be straightforward) and itch.io (I don't
think we have built-in support for that the way we do for Steam and GOG,
but if someone wants to contribute it...)



The other good way to handle proprietary game data is for the game
to be able to load it from a designated place in the user's home
directory, ideally taking into account freedesktop.org $XDG_DATA_HOME
and $XDG_DATA_DIRS. If the engine has the concept of a search path for
data (like the Quake series do) then the same engine can support both
"install for just me" and "install into /usr" transparently.

smcv

Bug#1023014: ITP: securestring -- Clearing the contents of strings containing cryptographic material

[Simon McVittie]

On Sat, 29 Oct 2022 at 10:34:07 +0200, Joost van Baal-Ilić wrote:
>   Python wrapper around OPENSSL_cleanse() which fills a pointer with a string
>   of 0's, typically used to clear the contents of strings containing
>   cryptographic material.

Does this actually need OpenSSL, or would explicit_bzero() be enough on
platforms that have it? (glibc >= 2.25 is an example of a platform that
has it.)

See also the NOTES in explicit_bzero(3), most or all of which probably
apply equally to OPENSSL_cleanse().

smcv

Bug#1017959: RFP: meson-python -- Meson PEP 517 Python build backend

[Simon McVittie]

Control: retitle -1 ITP: meson-python -- Meson PEP 517 Python build backend
Control: owner -1 !

On Tue, 23 Aug 2022 at 01:25:49 +0200, Drew Parsons wrote:
> * Package name: meson-python
>   Description : Meson PEP 517 Python build backend

I started looking at this because I've wondered whether to use it for
dbus-python. Work in progress:
https://salsa.debian.org/python-team/packages/meson-python
(not really tested yet, I don't yet have an upstream project that
needs it).

Co-maintainers welcome; Drew, would you be interested?

smcv

Bug#1013177: ITP: mate-user-admin -- MATE User Manager

[Simon McVittie]

On Sat, 18 Jun 2022 at 15:18:02 +0200, Mike Gabriel wrote:
>  User and group management utility suitable as an alternative
>  for gnome-system-tools on more lightweight desktop environments
>  such as MATE or Xfce.

gnome-system-tools has been dead upstream since 2012 (#888670), so please
avoid implying that it's what GNOME uses. For GNOME, the replacement is
gnome-control-center, but g-c-c is not designed for non-GNOME desktops
(it's a "system settings" utility for GNOME as an integrated environment,
so for example it assumes you're using GNOME Shell).

I would suggest:

 User and group management utility suitable as an alternative
 for gnome-control-center on more lightweight desktop environments
 such as MATE or Xfce.

or just

 User and group management utility suitable for lightweight desktop
 environments such as MATE or Xfce.

If this is intended to replace current uses of gnome-system-tools in
MATE, Xfce and other GTK-based environments, describing it as a
replacement rather than an alternative might be appropriate, something
like this:

 User and group management utility suitable for lightweight desktop
 environments such as MATE or Xfce.
 .
 This utility is intended to replace the user-management functionality
 of the old gnome-system-tools package.

Thanks,
smcv

Bug#1000468: ITP: mdnsd -- embeddable Multicast DNS Daemon

[Simon McVittie]

On Tue, 23 Nov 2021 at 19:47:44 +0100, Gürkan Myczko wrote:
>  This is a standalone mDNS-SD daemon for small systems. Although still
>  limited in functionality it can announce services like FTP, HTTP, and
>  SSH and respond to scanning (enumeration) requests from tools like
>  mdns-scan.
> 
> This is similar like avahi-daemon but different.

Since Avahi is the "market leader" for this functionality, perhaps it
would be useful to expand the description to mention why you would want
to use this implementation over Avahi, and why you would want to use
Avahi over this implementation?

If I understand correctly, mdnsd can announce services listed in
a configuration file to be seen by other machines on the LAN (the
service side of mDNS), and it does that with lower resource cost
(memory? installed size?) than a basic installation of Avahi.

Does it have functionality to help other processes on the local machine
to browse services elsewhere on the LAN? There are two ways the client
side of mDNS can work: clients can either do all the UDP themselves from
first principles, like python3-zeroconf does, or they can communicate
with a centralized daemon that can multiplex requests from multiple clients
on the same machine, like Avahi clients do. In general the first way is
simpler if you have a single long-running client on a very small embedded
system, but the second way reduces network load if you have multiple
clients on a general-purpose system like a laptop or a larger/more
modular embedded system.

Does it have IPC functionality for processes on the local machine to
announce additional services dynamically (Avahi uses D-Bus for this),
or is it limited to a relatively static configuration?

smcv

Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland

[Simon McVittie]

On Thu, 14 Oct 2021 at 00:33:44 +0100, Christian Rauch wrote:
> I am not familiar with the processes and timelines in Debian. It appears
> that "libdecor-0" is stuck in this queue for 2 months and other packages
> are waiting for far longer.

Yes, it's waiting for legal checks from the archive administrators.

> Is there a timeline for when packages are scheduled for upload to the
> respective package archives (e.g. experimental in this case)

There is no fixed timeline, we just have to wait for someone with the
right permissions to get round to reviewing it.

smcv

Bug#994773: ITP: xdg-desktop-portal-gnome -- GNOME portal backend for xdg-desktop-portal

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: xdg-desktop-portal-gnome
  Version : 41.0
  Upstream Author : Georges Basile Stavracas Neto, Matthias Clasen et al
* URL : https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome
* License : LGPL
  Programming Lang: C
  Description : GNOME portal backend for xdg-desktop-portal

xdg-desktop-portal-gnome provides a GNOME implementation for the
desktop-agnostic xdg-desktop-portal service. This allows sandboxed
applications to request services from outside the sandbox using
GNOME services such as the session manager and Shell.

---

This is fully GNOME-specific, like a GNOME equivalent of
xdg-desktop-portal-kde (and unlike the x-d-p-gtk backend available in
Debian 11, which is somewhat desktop-neutral and has been treated as
part of the Flatpak family of packages). It will be maintained in the
GNOME team.

The code in this package used to be part of xdg-desktop-portal-gtk, but
that backend was a mixture of general GTK things (which can work equally
well on other GTK desktops like XFCE or MATE, and are broadly suitable as
an implementation of last resort on any system that happens to have GTK
installed) and GNOME-specific things (most of which genuinely do need
core GNOME components). Those two classes of interface had conflicting
requirements, which can be resolved by separating them.

The GNOME-specific parts of xdg-desktop-portal-gtk are still available
for now as a transitional stage, but they will be disabled after this
package has got through NEW, and are likely to be deleted upstream in
the relatively near future.

This package is likely to depend on the x-d-p-gtk backend, which will
continue to provide its non-GNOME-specific interfaces. xdg-desktop-portal
can take individual interfaces from different backends, with the one
for the $XDG_CURRENT_DESKTOP "winning" and others being used as fallbacks.

Other GTK desktops (MATE, Cinnamon, XFCE, etc.) should either use the -gtk
backend if it is sufficient for their requirements, or implement their own
portal backend similar to this one to provide things that x-d-p-gtk can't do
in a desktop-agnostic way, such as screen sharing and wallpaper-setting.

smcv

Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland

[Simon McVittie]

Control: tags -1 + pending
Control: forwarded -1 https://ftp-master.debian.org/new.html

On Thu, 06 May 2021 at 00:11:37 +0100, Christian Rauch wrote:
> "libdecor" is a library that can be used by Wayland clients to implement
> client-side window decorations.

Initial package uploaded to NEW, now waiting for ftp team processing.

I made some more packaging improvements before uploading:
https://salsa.debian.org/sdl-team/libdecor-0/-/commits/debian/latest/

smcv

Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland

[Simon McVittie]

On Fri, 23 Jul 2021 at 19:00:02 +0100, Christian Rauch wrote:
> Am 23.07.21 um 11:35 schrieb Simon McVittie:
> > Is the packaging you used in that Ubuntu PPA already available as a
> > git tree?
> 
> Yes. The ppa is using my "libdecor-packaging" repo [1] for the packaging
> information. The ppa is merging the source tree and the packaging tree
> to generate the packages daily.

Thanks, I've pulled from there as a basis for an initial packaging repo:
https://salsa.debian.org/sdl-team/libdecor-0

I would strongly prefer the git repo to be "source included", like the
one for libsdl2 - that fits the policies of both the SDL and GNOME teams.

> How should I update the package information according to your
> suggestions? Shall I just update my packaging repo and you pull from it?
> Or do you have to create a repo at salsa.debian.org and take pull
> requests from me?

Some of the changes I suggested will make it incompatible with the
packages currently in your PPA (i.e. break upgrades), so it might be
best to have a "clean break" between the PPA and the official Debian
packaging, by forking https://salsa.debian.org/sdl-team/libdecor-0 on
salsa.debian.org and doing new packaging work there.

I can give you commit access to that packaging repo when we've got a bit
further, but you'll need an account on salsa.debian.org first, and it
might be best to do at least the first few changes as merge requests.

smcv

Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland

[Simon McVittie]

On Thu, 06 May 2021 at 00:11:37 +0100, Christian Rauch wrote:
> I am already maintaining an Ubuntu ppa at:
> https://launchpad.net/~christianrauch/+archive/ubuntu/libdecoration
> but would like to upstream the package into Debian.

Is the packaging you used in that Ubuntu PPA already available as a
git tree?

> Since this is my first time packaging a library for Debian, I could use
> support from a co-maintainer who is familiar with Wayland

More important would be to have a co-maintainer who is familiar with
packaging shared libraries, I think. There are some subtleties that are
important to get right.

It would probably make sense for the SDL team and/or the GNOME team to
be in Maintainer and/or Uploaders for this package - SDL wants to use it,
and it comes from GNOME infrastructure and uses GNOME-adjacent libraries
and coding conventions. I'm in both teams and would be willing to
co-maintain. I can help to implement the suggestions below, or you
could do them, whichever you'd prefer.

I haven't yet reviewed the upstream code at all (except for the build
system MR), but a Debian Developer will need to do that before upload,
to check for legality/licensing issues and make sure the code isn't
malicious or obviously broken (I'm sure it isn't, but someone should check).

Some quick review of the version from the PPA:

Package naming:
- Source package name should be libdecor-0 now that upstream has
  co-installable naming conventions
- libdecor binary package should be renamed libdecor-0-0 to match the
  SONAME libdecor-0.so.0, with Conflicts: libdecor, Replaces: libdecor
  to avoid conflicts with the unofficial PPA package
- libdecor-dev binary package should be renamed libdecor-0-dev to match
  the .pc file, with Conflicts: libdecor-dev, Replaces: libdecor-dev
- libdecor-plugin-cairo should maybe be renamed libdecor-plugin-1-cairo
  or something, to reflect plugin_api_version

d/control:
- libdecor dependency on libwayland-client0 should be unnecessary, you
  should find that ${shlibs:Depends} adds a suitable dependency
- Similarly libdecor-plugin-cairo dependency on libcairo2 and
  libpangocairo-1.0-0 should come from ${shlibs:Depends}
- libdecor-plugin-cairo should probably have Provides: libdecor-plugin-1
- libdecor-0-0 should probably have
  Recommends: libdecor-plugin-1-cairo | libdecor-plugin-1
  so that third-party plugins (if any) can Provides: libdecor-plugin-1
- The Standards-Version is very out of date, please check that the package
  follows current Debian Policy and then set it to the current Policy
  version (4.5.1 at time of writing)
- libdecor-plugin-cairo needs a long Description

d/compat:
- Please use the recommended debhelper compat level (13) for new packages,
  unless there is a very good reason to require an older compat level.
  The preferred way to do this is to add
  Build-Depends: debhelper-compat (= 13) and delete d/compat.

d/copyright:
- The version of the MIT/X11 license quoted here is called "Expat" in
  d/copyright files, to distinguish it from the many other licenses
  used by MIT and X11.
- You can probably use

  Files: *
  Copyright: (the same as you have now)
  License: Expat

  on the assumption that .gitignore, README, meson.build, etc. have the
  same copyright holders and licensing as the rest of the package.
- Please declare a copyright holder (you or your employer) and a license
  (probably Expat) for the debian directory.
- The copyright file isn't following copyright-format 1.0 syntax yet.
  Please see the python3-vdf package (which I maintain) for an example of
  a copyright file for a package with the same license as this one.

d/README.Debian:
- If you don't have anything to say here, please delete it

d/rules:
- Probably best to remove the commented-out stuff
- I would suggest enabling the demos and installing them in a new
  libdecor-tests package - otherwise it'll be hard to do manual testing
  on this package without having the patched SDL available. This will
  need some extra build-dependencies.

  If this package later gains automated tests, the libdecor-tests package
  could contain those too.

  Ideally the libdecor-tests package would have Build-Profiles: 
  (I can help with this).

d/source/format:
- Should be 3.0 (quilt) instead of 3.0 (native) for a package with an
  upstream developer outside Debian

d/git-build-recipe.manifest:
- This should be removed for an official Debian package.

Other:
- There should be a debian/watch to download the latest official upstream
  release. If upstream doesn't release tarballs then use something similar
  to 
https://salsa.debian.org/gnome-team/gnome-desktop-testing/-/blob/debian/2018.1+git20210629-1/debian/watch
  to download it directly from git.
- I think all shared library packages should have at least a superficial
  autopkgtest, for example similar to the ones in
  

  or 

Bug#990713: RFP: cargo-c -- cargo applet to build and install C-ABI-compatible dynamic and static libraries

[Simon McVittie]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net, 
libr...@packages.debian.org

* Package name: cargo-c
  Version : 0.9.1
  Upstream Author : Luca Barbato
* URL : https://github.com/lu-zero/cargo-c
* License : MIT/X11 (Expat)
  Programming Lang: Rust
  Description : cargo applet to build and install C-ABI-compatible dynamic 
and static libraries

Future versions of librsvg are likely to require cargo-c >= 0.9 as
a build-dependency. I don't know Rust, so I am not able to package or
maintain this myself.

smcv

Bug#987000: ITP: gi-docgen -- source code documentation tool using GObject-Introspection

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-gtk-gn...@lists.debian.org

* Package name: gi-docgen
  Version : 2021.2 or git snapshot
  Upstream Author : Emmanuele Bassi
* URL : https://gitlab.gnome.org/GNOME/gi-docgen
* License : Apache-2.0 OR GPL-3.0-or-later
  Programming Lang: Python
  Description : source code documentation tool using GObject-Introspection

GI-DocGen is a document generator for GObject-based libraries. GObject
is the base type system of the GNOME project. GI-Docgen reuses the
introspection data generated by GObject-based libraries to generate
the API reference of these libraries, as well as other ancillary
documentation.

GI-DocGen is not a general purpose documentation tool for C libraries:
while GI-DocGen can be used to generate API references for most GObject/C
libraries that expose introspection data, its main goal is to generate
the reference for GTK and its immediate dependencies.

GI-DocGen is still in development. The upstream-recommended use of
GI-DocGen is to add it as a sub-project to a Meson build system, and
vendor it when releasing dist archives. Until GI-DocGen becomes stable,
Debian packages that use it for their documentation should use a vendored
copy (as allowed by Policy §4.13), and should not have a Build-Depends
on gi-docgen.

---

We should probably package this in experimental even though
build-depending on it isn't useful yet, so that updates to to GTK-related
packages don't get stalled by the NEW queue or unforeseen packaging issues
when it's declared stable and stops being vendored by dependent packages.

Bug#986999: RFP: fonts-red-hat -- Red Hat type family

[Simon McVittie]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-fo...@lists.debian.org, debian-gtk-gn...@lists.debian.org

* Package name: fonts-red-hat
  Version : 4.0.0
  Upstream Author : Jeremy Mickel
* URL : https://github.com/RedHatOfficial/RedHatFont
* License : SIL OFL 1.1, with Reserved Font Name Red Hat
  Programming Lang: n/a
  Description : Red Hat type family

The font family used in Red Hat branding.

This font is used in the default template for the gi-docgen tool, which
some of the lower-level GNOME-related libraries such as GTK and Pango
are starting to adopt as a replacement for gtk-doc.

At the moment I'm intending to patch out the font selection and exclude
the fonts themselves in the interests of having less to review for the
d/copyright of the packages that bundle gi-docgen (it is not yet stable,
so the intended use is for individual projects to bundle a known-good
copy rather than it being packaged distro-wide), but it would be nice
if someone with more font knowledge could package this properly.

smcv

Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0

[Simon McVittie]

On Sat, 13 Mar 2021 at 23:47:30 +0100, Guillem Jover wrote:
> I've recently retried switching to Wayland and I think I'm sticking
> with it. But while checking for toolkits support, noticed that SDL 1.2
> does not have native Wayland support, but SDL 2.0 does.

Note that SDL 2.0 currently defaults to using X11 if available, and will
currently only use Wayland if X11 is unavailable, so in environments where
Xwayland is either always run (such as GNOME 3.38) or started automatically
on-demand (such as GNOME 40), SDL 2.0 games will normally be using X11.
I think typical desktop environments like GNOME and KDE Plasma are
likely to want Xwayland available by default for quite a long time,
even if it's only started on-demand.

You can override this with with environment variable
SDL_VIDEODRIVER=wayland.

On Sun, 14 Mar 2021 at 02:07:34 +0100, Haelwenn (lanodan) Monnier wrote:
> As seen in [1] regarding the headers, sdl12-compat isn't a full replacement 
> yet.
> 
> It could work for pure binary-compatibility but you can't build anything
> against it yet so it should be a Provide+Replace rather than something
> like a newer version.
> 
> 1: https://github.com/libsdl-org/sdl12-compat/issues/34

Yes, I'd come to that conclusion too.

If we get to a point where we want to eliminate the original SDL 1.2 from
the archive before sdl12-compat has headers, we could probably make some
sort of hybrid package that builds SDL 1.2, keeps the headers, discards
the actual shared library and uses the shared library from sdl12-compat
instead - but I think it would probably work best to package sdl12-compat
as a separate binary-compatibility-only library first.

It would probably be best to have the sdl12-compat shared library installed
in a directory outside the default search path so that it can be
co-installed with the real SDL 1.2, and then insert it into the default
search path in a separate package that Provides/Conflicts/Replaces the
real SDL 1.2. That way, individual games have the option to use sdl12-compat
via DT_RUNPATH or LD_LIBRARY_PATH without preventing co-installation of
the real SDL 1.2.

In particular, sdl12-compat has a few extra symbols not present in the
real SDL 1.2, which are meant to make it binary-compatible with the
modified SDL 1.2 build "libSDL-1.2.id.so.0" in some id Software games,
such as the quake4-bin:i386 package built by game-data-packager. If
it works well as a replacement for that modified library, then
game-data-packager could prefer to use sdl12-compat.

On Thu, 18 Mar 2021 at 21:30:47 +0100, Stephen Kitt wrote:
> I’m interested in maintaining this, I’ll ask to join the SDL team.

I've added you.

I briefly started looking at this before seeing this message, so I've
created an empty 
(no content yet though).

smcv

Bug#977374: ITP: vdf -- package for working with Valve's text and binary KeyValue format

[Simon McVittie]

On Tue, 23 Feb 2021 at 17:06:58 +, Simon McVittie wrote:
> On Tue, 23 Feb 2021 at 16:50:41 +, Stephan Lachnit wrote:
> > If you already have stuff, send me the link to the salsa repo once uploaded
> 
> Will do!

https://salsa.debian.org/games-team/python-vdf

(The upstream name seemed really ambiguous, so I gave the source package
name a python- prefix.)

smcv

Bug#977374: ITP: vdf -- package for working with Valve's text and binary KeyValue format

[Simon McVittie]

On Tue, 23 Feb 2021 at 16:50:41 +, Stephan Lachnit wrote:
> It lost a bit track of this due to Proton 5.13 not working with protontricks
> (at least when I checked last time), so I haven't done anything yet.

Proton 5.13+ runs in a container, using a container tool currently
maintained by, er, me :-)

I think future development is likely to need a way to inject arbitrary
commands into a running container, at which point protontricks will
probably be able to use that to make things happen inside the container -
but this hasn't been a priority so far.

> If you already have stuff, send me the link to the salsa repo once uploaded

Will do!

smcv

Bug#977374: ITP: vdf -- package for working with Valve's text and binary KeyValue format

[Simon McVittie]

On Mon, 14 Dec 2020 at 14:23:11 +, Stephan Lachnit wrote:
>   Description : package for working with Valve's text and binary KeyValue
> format
> 
> Required for Protontricks. Will go into contrib. Will maintain in the Games
> team.

Did you get anywhere with this? I think the steam package is likely to
benefit from having this in the archive: the upstream steam-launcher
package, as repackaged in Debian as steam, already makes use of this code
for some maintenance tools, although the shipped package doesn't use it
at runtime.

I already maintain some Python libraries, and this one looks straightforward
to package. May I co-maintain? I actually already have nearly-working
packaging, although if you already have packaging I'm happy to take a look
at that instead.

I don't think this needs to be in contrib, I think it would be fine
in main: the VDF format is associated with non-free Valve products,
but there's nothing inherently non-free about it. It's a file format
that anyone could use, like JSON.

smcv

Bug#980312: RFP: gnome-notes — A note taking editor, designed for simplicity

[Simon McVittie]

On Sun, 17 Jan 2021 at 23:18:57 +0200, Andrei POPESCU wrote:
> On Du, 17 ian 21, 17:42:48, Marek Ľach wrote:
> > Package: gnome-notes
...
> > - formerly was known as ''Bijiben''.

https://tracker.debian.org/pkg/bijiben already exists. Is that the package
you wanted?

smcv

Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker

[Simon McVittie]

On Fri, 08 Jan 2021 at 16:30:08 +, Luca Boccassi wrote:
> Gentle ping reg.
> https://salsa.debian.org/utopia-team/dbus/-/merge_requests/8 as
> deadlines are fast approaching - dbus-broker has cleared NEW, so I'd
> like to sort out the details regarding repository and team
> maintainership and make it available in unstable/testing.

Reviewing, testing and uploading that is on my list, but it isn't a
short list and contains other things that are time-sensitive, so dbus
has had to wait. I had hoped to have a dbus 1.14.x stable-branch by now,
but at this point bullseye is going to be on 1.12.x.

What deadlines did you have in mind? Are you intending to offer this as a
"first-class citizen" option in bullseye? When dbus-broker has only been
in the archive for two days, that doesn't seem like very much testing
to have confidence that it will be suitable to provide important system
services through the 3 year lifetime of bullseye.

smcv

Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker

[Simon McVittie]

On Sun, 13 Dec 2020 at 22:33:28 +, Luca Boccassi wrote:
> CC'ing Simon for the src:dbus bits.

Have you reviewed dbus-broker for its compatibility with the reference
dbus-daemon? I still haven't been able to review it in detail myself
(when I get some time to work on dbus, maintaining the reference
implementation takes it all!) but one point I'm concerned about is whether
its systemd-based implementation of traditional activation works correctly
for services that (unnecessarily) double-fork/daemonize.

smcv

Bug#961238: RFP: python3-gi -- python3-gi for GTK+4 in experimental

[Simon McVittie]

Control: retitle -1 python3-gi: update to a version with better GTK 4 support
Control: reassign -1 python3-gi

On Thu, 21 May 2020 at 22:07:36 +0100, Sam Bull wrote:
> I'd like to see a python3-gi version that supports GTK+4 in experimental.

This would have to be a new version of the python3-gi package, not a new,
separate package, so I'm reassigning this bug.

> There is already a gir1.2-gtk-4.0 package, but it errors in Python as the
> python3-gi package has not been updated.

GTK 4 is not finished and its API is constantly changing, so this could
be caused by either PyGI being too old and GTK 4 in experimental being
too new, or PyGI being too *new* and GTK 4 in experimental being too *old*.
Our priority in packaging PyGI is to have the version that works best
with GTK 3 applications from GNOME 3.38 in testing/unstable.

I seem to be the only developer to have uploaded GTK 4 to Debian
since 2017, but there are a lot of packages that are higher-priority
for me. The GTK 4 API continues to change, so this is not going to be
fast. I'm currently building a new version of Pango for experimental so
that I can update GTK 4 again.

GTK 4 isn't likely to get into Debian 11, which freezes at the end
of this year, and will release with GNOME 3.38. I hope that it will
be sufficiently stable to include in Debian 12, which should freeze
approximately 2 years later.

If you are having problems with PyGI's overrides being incompatible with
GTK 4, I would recommend using the versions from upstream git, and
contributing changes back to upstream where necessary; we'll pick those
up as they're released (but perhaps only after the Debian 11 freeze is
over).

smcv

Bug#969134: ITP: deepin-metacity -- lightweight GTK+ window manager

[Simon McVittie]

On Fri, 28 Aug 2020 at 01:53:59 +, stan clay wrote:
> * Package name    : deepin-metacity
>   Description     : lightweight GTK+ window manager

Does Deepin really need both a version of Mutter *and* a version of
Metacity?

If deepin-metacity and deepin-mutter are both uploaded, they'd be the 6th
and 7th libraries derived from Metacity in the archive:

* src:metacity, GNOME 2's original Metacity window manager and window
  management library, no longer used in GNOME but still used in GNOME
  Flashback (a GNOME 2.x-like environment) and Sugar

* src:mutter, GNOME 3's Clutter-based window management and compositing
  library derived from Mutter, used in GNOME Shell, Budgie and Gala

* src:muffin, derived from Mutter and used in Cinnamon

* src:marco, derived from Mutter and used in MATE and compiz-gnome (Hypra)

* src:ukwm, derived from Mutter and used in Kylin

* src:deepin-mutter, derived from Mutter and used in Deepin

* src:deepin-metacity, derived from Metacity and used in Deepin

(Did I miss any?)

I can understand desktop environments wanting to fork metacity or mutter,
because those libraries are the core of the desktop environment's window
manager or compositor, and developing them tightly integrated with
the window manager or compositor itself can speed up development a lot
(for example it means the window manager or compositor developers are
free to refactor the library, removing functionality that their desktop
environment doesn't need).

However, for the ones that are only intended to be used by a single
desktop environment, it might make sense to package the window management
library in the same source package as the window manager/compositor
itself, either statically linked or in a private shared library directory,
without providing development files usable by third-party packages.

> As the author says, metacity is a "Boring window manager for the adult in
> you. Many window managers are like Marshmallow Froot Loops; Metacity is
> like Cheerios."

Similar to deepin-mutter, this is not really a particularly useful part
of the description to quote. See the package descriptions for libmuffin0,
libmutter-6-0 and libmarco-private2 for better examples to follow.

smcv

Bug#969132: ITP: deepin-mutter -- lightweight GTK+ window manager for Deepin

[Simon McVittie]

On Fri, 28 Aug 2020 at 01:32:02 +, stan clay wrote:
>   Description     : lightweight GTK+ window manager for Deepin

Presumably this is a fork of src:mutter, similar to Cinnamon's src:muffin.

> https://github.com/linuxdeepin/deepin-mutter

I notice this Github repository is marked as archived. Is this package
still maintained upstream?

> Mutter is a small window manager, using GTK+ and Clutter to do
> everything.
> .
> Mutter is the clutter-based evolution of Metacity, which, as the
> author says, is a "Boring window manager for the adult in you. Many
> window managers are like Marshmallow Froot Loops; Metacity is like
> Cheerios."

This description doesn't really describe what deepin-mutter does, or
what its relationship to the original (GNOME) mutter is.

The way it works in GNOME is that mutter.deb provides a simple window
manager, but is not very useful on its own, and is not something
that people are actually meant to use as their daily window manager
or compositor - it's mostly only there as a way to debug the mutter
library. The window manager or compositor that GNOME users *actually*
use is GNOME Shell, which implements the low-level bits by linking to
libmutter. Budgie-Desktop and Gala are non-GNOME desktop enviroments
that do the same thing, and Cinnamon has a similar relationship with
Muffin, its fork of Mutter.

>From https://github.com/linuxdeepin/deepin-wm it looks as though the
situation in Deepin is similar to GNOME, with deepin-wm providing the
main executable and loading (Deepin's version of) libmutter as a shared
library.

This description adapted from mutter.doap might be a better starting point:

Deepin-Mutter is a window and compositing manager that displays and
manages your desktop via OpenGL. It combines a sophisticated display
engine using the Clutter toolkit with solid window-management logic
inherited from the Metacity window manager, and is derived from the
original Mutter library that is part of GNOME, with modifications for
the Deepin desktop environment.

While Deepin-Mutter can be used stand-alone, it is primarily
intended to be used as the display core of a larger system such
as deepin-wm. For this reason, it is very extensible via plugins,
which are used both to add fancy visual effects and to rework the
window management behaviors to meet the needs of the environment.

I'd recommend using something like that instead of analogies about
breakfast cereals.

(See also the src:mutter package's Description fields, which I rewrote
in 3.34.0-1.)

Thanks,
smcv

Bug#968331: ITP: systemd-genie -- quick way into a systemd "bottle" under Windows Subsystem for Linux

[Simon McVittie]

On Thu, 13 Aug 2020 at 01:16:46 -0500, Alistair Young wrote:
> I developed this myself to solve the problem of running systemd-dependent 
> programs
> using Debian under WSL, since WSL itself currently does not support systemd.

If I understand correctly, this is a problem with WSL 1 that will go away
with WSL 2, because WSL 1 is a compatibility layer in which the Windows
kernel pretends to be Linux (like Wine in reverse), but WSL 2 is a virtual
machine running a real Linux kernel (suitable for e.g. systemd)?

If that's the case, then the useful lifetime of this package might
be limited. (That doesn't *necessarily* mean it shouldn't be in Debian,
depending on availability and adoption of WSL 2.)

smcv

Bug#960310: ITP: rgain3 -- Replay Gain volume normalization Python tools

[Simon McVittie]

Control: retitle -1 ITP: rgain3 -- Replay Gain volume normalization Python tools
Control: owner -1 !

On Mon, 11 May 2020 at 14:58:05 -0300, Rogério Brito wrote:
> We already had a package called python-rgain in our past releases which was
> Python 2 only and, unfortunately, removed.
> 
> This new (renamed) fork is, apparently, the official successor of rgain and
> is actively maintained.

I'm not sure about official, but it seems close enough.

It is now called (python3-)rgain3: the top-level module to be imported was
renamed.

I suspect most people want it for replaygain(1) rather than for the Python
module anyway - I know I do. While it's already going through the NEW
queue, I'm intending to separate the CLI tools from the library into a new
replaygain binary package in Section: sound, for better discoverability.

> I really, really miss this package and the useful utilities
> that it provides.

Between my own packages, helping the GNOME team, and my actual job,
I'm finding that I often don't have a lot of time/energy left for
lower-priority packages. Would you be able to co-maintain this one?

In particular, I don't use collectiongain(1), only replaygain(1) - so if
collectiongain is important to you, please help.

smcv

Bug#941657: name change: python-lark-parser -> python-lark

[Simon McVittie]

On Mon, 30 Dec 2019 at 17:15:54 +0100, Peter Wienemann wrote:
> https://bugs.debian.org/945823
> 
> which says:
> 
> "use the name you import in preference to the name from the PKG-INFO".
> 
> That is why I decided to change the name to python-lark. But given the
> PyPI name clash this is certainly not optimal either. So this seems to
> be a particular unfortunate case.

If there are two modules on PyPI, both of which you use via
"import lark", then they cannot both be installed correctly into the
system-wide module search path on the same Debian system - if they
were, even if they happen to avoid having directly conflicting files
(because one is /usr/lib/python3/dist-packages/lark.py and the other is
/usr/lib/python3/dist-packages/lark/__init__.py, or similar), installing
both and using "import lark" would not consistently import the one you
intended to use, leading to broken programs.

So the rule has served its purpose: it has detected a conflict that needs
to be avoided somehow.

For users of virtualenv there is perhaps no problem, because you can
install the lark you wanted in a particular virtualenv and avoid installing
the other lark, but Debian packages are a flat global namespace of modules.

There are two options:

* If "lark" on PyPI is a dead project, or otherwise something that is never
  going to be useful to package in Debian for some reason, then perhaps it's
  safe for the lark parser to claim the python3-lark name.

* Otherwise, if its PyPI name is lark-parser, then I would personally
  recommend asking the upstream developer to rename the module you import
  to lark_parser (or maybe larkparser if that's preferred), and packaging
  it as python3-lark-parser (or python3-larkparser), optionally with
  compatibility glue to make "import lark" continue to work (which might not
  get packaged in Debian).

(I'm talking about binary package names python3-foo because those are the
most important thing for avoiding conflicts, but if the binary package
name is python3-foo then it probably makes most sense for the source
package to be python-foo.)

smcv

Bug#947401: RFP: openra -- engine remake for Command & Conquer series of games

[Simon McVittie]

Package: wnpp
Severity: wishlist

Passing on an informal RFP from #debian-devel:

* Package name: openra
  Version : 20191117
  Upstream Author : multiple, see 
https://github.com/OpenRA/OpenRA/blob/bleed/AUTHORS
* URL : https://www.openra.net/
* License : GPL-3+ code, proprietary (non-distributable?) data files
  Programming Lang: C#
  Description : engine remake for Command & Conquer-related RTS games

OpenRA is an open-source engine remake for early Westwood real-time
strategy games including Command & Conquer: Red Alert, Command & Conquer:
Tiberian Dawn and Dune 2000.

Anyone wishing to maintain this engine in Debian might also need
to contribute support for the required proprietary data files in
game-data-packager. I and other game-data-packager maintainers can
help with this; please open a wishlist bug or a merge request.

See also #801513 (OpenRedAlert, a different remake in C++).

Bug#946605: ITP: libportal -- Flatpak portal library

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: libportal
  Version : 0.1.0
  Upstream Author : Matthias Clasen
* URL : https://github.com/flatpak/libportal
* License : LGPL-2.0+
  Programming Lang: C
  Description : Flatpak portal library

libportal provides GIO-style C APIs for most Flatpak portals' D-Bus
interfaces. It is primarily intended for installation in Flatpak runtimes,
where applications can use it to interact with portals; it can also be
used to test the portal services.

See the xdg-desktop-portal package's description for more information
about portals.



This is useful to package in Debian so that it can be included
in Flatpak runtimes that are based on Debian packages, similar to
flatpak-xdg-utils. It is also used in the automated tests of newer
versions of xdg-desktop-portal.

In addition to the library, this source package will build
org.gnome.PortalTest, a simple GTK application that interacts with
portals and can be used to test them.

Bug#931595: mutest package

[Simon McVittie]

On Thu, 21 Nov 2019 at 09:04:33 +0700, Arnaud Rebillout wrote:
> remote: GitLab: You are not allowed to push code to protected branches on
> this project.

Try now? I've copied the Protected Branches settings from gnome-team/glib.

smcv

Bug#931595: mutest package

[Simon McVittie]

On Tue, 19 Nov 2019 at 18:15:30 +0700, Arnaud Rebillout wrote:
> remote: A default branch (e.g. master) does not yet exist for
> gnome-team/mutest
> remote: Ask a project Owner or Maintainer to create a default branch

I pushed the branches from https://salsa.debian.org/arnaudr-guest/mutest,
with debian/master as the default.

smcv

Bug#931595: mutest package

[Simon McVittie]

On Fri, 02 Aug 2019 at 12:29:12 +0100, Simon McVittie wrote:
> On Mon, 08 Jul 2019 at 11:48:17 +0700, Arnaud Rebillout wrote:
> > - I asked for access to the gnome team on salsa, my user is `arnaudr-guest`
> 
> Someone on the Owners list will have to do this; but if nobody gets round
> to it, I can create an empty mutest project and give you access to it,
> and you can work that way?

I've created an empty repository https://salsa.debian.org/gnome-team/mutest
and given you access. You should be able to push your WIP packaging there.

A gnome-team Owner (ah, biebl, bigon, jbicha, laney, mitya57, pochu or
seb128) will still need to give you access if you want to push directly
to other GNOME packages (I don't have enough access to do this), or you
can fork the package in your own namespace and send merge requests.

smcv

Bug#942166: RFP: malcontent -- library for parental control of applications

[Simon McVittie]

Package: wnpp
Severity: wishlist

* Package name: malcontent
  Version : 0.4.0
  Upstream Author : Philip Withnall / Endless
* URL : https://gitlab.freedesktop.org/pwithnall/malcontent
* License : LGPL-2.1+
  Programming Lang: C with GObject
  Description : library for parental control of applications

malcontent implements support for restricting the type of content
accessible to non-administrator accounts on a Linux system. Typically,
when this is used, a non-administrator account will be for a child using
the system; and the administrator accounts will be for the parents;
and the content being filtered will be apps which are not suitable for
the child to use, due to (for example) being too violent.

This is not a security boundary, and a sufficiently technically advanced
user may always work around these parental controls. malcontent is not a
mandatory access control (MAC) system like AppArmor or SELinux. However,
its correct use by applications should provide enough of an obstacle
to prevent users easily or accidentally having access to content which
they shouldn’t.



Flatpak 1.5.1+ will optionally use this library to check for permission
to install and run apps. I don't intend to package or maintain it myself,
but if someone else maintains it, I'm willing to enable the dependency
in Flatpak.

Presumably other projects, such as GNOME Shell, will gain a similar
optional dependency.

Bug#935395: RFP: python3-anytree -- Tree data library

[Simon McVittie]

Package: wnpp
Severity: wishlist

* Package name: python3-anytree
  Version : 2.6.0
  Upstream Author : "c0fec0de"
* URL : https://github.com/c0fec0de/anytree
https://pypi.org/project/anytree/
* License : Apache 2.0
  Programming Lang: Python
  Description : Tree data library

Newer versions of gtk-doc-tools require anytree for gtkdoc-mkhtml2, an
experimental replacement for gtkdoc-mkhtml and gtkdoc-fixxref which speeds
up processing by transforming Docbook into HTML in Python code instead of
using XSLT.

For now I've replaced its use in gtk-doc-tools with a simple
reimplementation (it's a tree data structure, it isn't rocket science),
but in the long term either someone should package anytree, or someone
needs to ask the upstream maintainer of gtk-doc to use a different tree
implementation instead of depending on anytree (in which case this bug
can be closed as wontfix).

Bug#931595: mutest package

[Simon McVittie]

On Mon, 08 Jul 2019 at 11:48:17 +0700, Arnaud Rebillout wrote:
> I'd like to package mutest for Debian. Is the GNOME packaging team
> interested in this package, can I maintain it with the team?

graphene already uses a bundled copy of mutest, so it would seem
appropriate to maintain the unbundled version in the GNOME team too.

However, at the moment mutest is explicitly not stable:

**WARNING**: µTest's API is still in flux!

so I don't think it would be appropriate for packages like Graphene
to use a system copy at this stage. The documentation says:

The preferred way to use µTest is to include it in your own projects
using a Git sub-module, and then building µTest as a static library.

which I think meets the "unless the included package is explicitly
intended to be used in this way" criterion in Policy §4.13.

> I already have the packaging files ready (not pushed anywhere yet), I'd
> need someone to review it. And I need a sponsor as I'm DM not DD.

I'll try to review this at some point. Hopefully it'll be very similar
to the copy bundled in graphene.

I don't think this should be in unstable at the moment, but it could
go to experimental, alongside other specifically-not-stable projects
like gtk+4.0.

> What's the preferred way, should I go through the Debian mentors page,
> or simply using Salsa is enough?

I would personally prefer Salsa.

> - I asked for access to the gnome team on salsa, my user is `arnaudr-guest`

Someone on the Owners list will have to do this; but if nobody gets round
to it, I can create an empty mutest project and give you access to it,
and you can work that way?

smcv

Bug#925288: ITP: diff-so-fancy -- Good-lookin' diffs. Actually… nah… The best-lookin' diffs.

[Simon McVittie]

On Sat, 23 Mar 2019 at 07:41:06 +, Mo Zhou wrote:
> In fact the diff-highlight (denoted
> as 'DH' below, not your favorite debhelper) shipped in the git package
> is able to produce similar result compared to diff-so-fancy (denoted as 'DSF'
> below), except for
> 
> * DH doesn't mangle standard notations of the patch format; while
>   DSF mangles them. See example below.

It sounds as though a binary package for diff-highlight might be a more
useful thing to do than packaging diff-so-fancy...

smcv

Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Simon McVittie]

On Thu, 28 Feb 2019 at 17:53:37 -0500, Reinhard Tartler wrote:
> Upstream doesn't appear to be willing to upgrade to a new version (quote from
> the bug above "[...] I really don't want to [...]". Looking at how this 
> package
> is using the vendored library, it seems openshift/imagebuilder is using a
> rather specific subset of the docker code, some of which possibly shouldn't
> have been exposed in the first place. Therefore, I'm inclined to follow
> upstream and vendor this library.

I agree that this sounds like a de facto fork of the vendored library,
more than a convenience code copy.

> I wonder whether it wouldn't be actually be more
> appropriate to create a tarbal with the vendored library and ship it in the
> debian/ subdirectory.

You could consider using a multiple-.orig-tarball package in 3.0
(quilt) format? See for example yquake2 (a relatively simple
example which bundles together https://github.com/yquake2/yquake2 and
https://github.com/yquake2/ctf) or llvm-toolchain-7 (a more elaborate
example with multiple subprojects).

smcv

Bug#923267: ITP: gnome-shell-extension-bluetooth-quick-connect -- GNOME Shell extension to connect paired Bluetooth devices

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: gnome-shell-extension-bluetooth-quick-connect
  Version : (none, git snapshot)
  Upstream Author : Bartosz Jaroszewski
* URL : 
https://extensions.gnome.org/extension/1401/bluetooth-quick-connect/
* License : GPL-2.0-or-later
  Programming Lang: JavaScript
  Description : GNOME Shell extension to connect paired Bluetooth devices

 This GNOME Shell extension adds entries to the shell's System menu
 to provide a quick way to connect and disconnect Bluetooth devices that
 were previously paired with the computer.
 .
 Please note that each user will need to enable the extension manually, for
 example using the gnome-tweaks application.

---

Preliminary packaging at
https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-bluetooth-quick-connect
to be maintained with the GNOME team.

Bug#919299: ITP: flatpak-xdg-utils -- xdg-open and xdg-email reimplementation for containerized apps

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: flatpak-xdg-utils
  Version : 0.1+ (git snapshot)
  Upstream Author : Florian Müllner, Matthias Clasen, Alex Larsson
* URL : https://github.com/flatpak/flatpak-xdg-utils
* License : LGPL-2+
  Programming Lang: C
  Description : xdg-open and xdg-email reimplementation for containerized 
apps

Applications running in a Flatpak sandbox cannot normally launch arbitrary
subprocesses outside the container to open files and URLs. This
package provides reimplementations of the standard xdg-open(1) and
xdg-email(1) command-line tools intended to be run inside the container.
They use the D-Bus session bus to communicate with the xdg-desktop-portal
service outside the container.

These tools are developed alongside Flatpak, but they are not completely
Flatpak-specific, and might also be useful for other app-container
technologies.

This package is normally only useful if you are using Debian packages
to construct a Flatpak runtime, and should not be installed on a normal
Debian desktop system. On desktop systems please install the reference
implementation of the xdg-open and xdg-email tools, which can be found
in the xdg-utils package.

If this package is installed in a non-Flatpak environment for testing,
it will not work without the dbus-session-bus and xdg-desktop-portal
packages.

[X-Debbugs-Cc to xdg-utils maintainers for information: this will
probably have Conflicts/Replaces, and possibly Provides, on the reference
implementation of xdg-utils.]

---

This will probably also produce a second binary package, flatpak-spawn
or similar, with the parts that are completely Flatpak-specific:

Package: flatpak-spawn
Description: tool to run programs outside a Flatpak sandbox
 Applications running in a Flatpak sandbox cannot normally run arbitrary
 commands outside the container, and cannot create nested containers.
 The flatpak-spawn tool uses the D-Bus session bus to communicate with
 a portal service provided by Flatpak outside the container, which can run
 commands on behalf of the sandboxed application, subject to Flatpak
 permissions checks.
 .
 Applications that contain a helper tool such as a thumbnailer can use
 flatpak-spawn to launch that tool in a new instance of their own
 sandbox, with more restrictive permissions. For example, this can be
 used to mitigate possible security vulnerabilities in thumbnailers by
 granting fewer privileges to the thumbnailer.
 .
 Trusted applications with the 'devel' privilege flag, such as the GNOME
 Builder integrated development environment, can also use flatpak-spawn
 to run arbitrary commands on the host system, bypassing the sandbox.
 .
 This package is only useful if you are using Debian packages to construct
 a Flatpak runtime, and should not be installed on a normal Debian desktop
 system.

Bug#917037: ITP: python3-zeroconf -- Pure Python implementation of multicast DNS service discovery (Python3)

[Simon McVittie]

On Fri, 21 Dec 2018 at 21:59:46 +0100, Ruben Undheim wrote:
> python-zeroconf already exists in the Debian archive. However, upstream has
> dropped support for Python 2, and there are reverse dependencies in Debian
> which depend on the Python 2 package. This makes it necessary with a separate
> source package for the Python 3 version.

See also #894809 (which you could close in the upload of python3-zeroconf,
or mark as a duplicate of this ITP).

I had assumed that you'd want to close #894809 without a new
source package, since the only remaining rdep of python-zeroconf is
pulseaudio-dlna (#894806); but a new source package also seems fine as
a solution, and you have to go through the NEW queue either way.

smcv

Bug#915579: ITP: xdg-dbus-proxy -- filtering D-Bus proxy

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: xdg-dbus-proxy
  Version : 0.1.0
  Upstream Author : Alexander Larsson
* URL : https://github.com/flatpak/xdg-dbus-proxy
* License : LGPL-2.1+
  Programming Lang: C with GLib
  Description : filtering D-Bus proxy

xdg-dbus-proxy is a filtering proxy for D-Bus connections. It was
originally part of the Flatpak project, but it has been broken out as
a standalone module to facilitate using it in other contexts.

For this proxy to be useful, restricted D-Bus clients must be denied
access to the normal D-Bus socket (for example by using containers or
AppArmor rules), and instead given access to the listening Unix socket
created by the proxy (typically by bind-mounting it into a Linux
container).

---

Flatpak currently uses a bundled copy of xdg-dbus-proxy 0.1.0 as
a git submodule, but I expect to switch it to use this package when
available. Development versions of WebKitGTK+ apparently use it for
process sandboxing (presumably alongside bubblewrap) or will do so soon.

Bug#912305: ITP: unrardll -- Python wrapper for the unrar shared library

[Simon McVittie]

On Tue, 30 Oct 2018 at 10:26:53 +0900, Norbert Preining wrote:
> going to nonfree because it depends on libunrar4 which is from nonfree.

If unrardll is itself free software, then it should go in contrib, not
non-free. contrib is the archive area for free software with dependencies
that are non-free (or are not in Debian main for some other reason).

smcv

Bug#904643: RFP: amtk -- Actions, Menus and Toolbars Kit library for GTK+ applications

[Simon McVittie]

On Wed, 10 Oct 2018 at 10:24:09 +0200, Tanguy Ortolo wrote:
> Being interested as this is a new indirect dependency of my package
> latexila, I have prepared that package.

Thanks for doing this!

> I have yet to determine whether or not
> to make this package part of the GNOME Team packaging

I think the GNOME team would prefer to have new GNOME libraries in the
gnome-team group on Salsa, so that we can update all the packages for a
new GNOME version as a batch. I can create an empty repository for amtk
and make you a Maintainer or Owner there if that would be helpful?

smcv

Bug#904643: RFP: amtk -- Actions, Menus and Toolbars Kit library for GTK+ applications

[Simon McVittie]

Package: wnpp
Severity: wishlist

* Package name: amtk
  Version : 5.0.0
  Upstream Author : Sébastien Wilmet
* URL : https://wiki.gnome.org/Projects/Amtk
* License : LGPL-2.1+
  Programming Lang: C
  Description : Actions, Menus and Toolbars Kit library for GTK+ 
applications

amtk is a basic replacement for GTK+'s deprecated GtkUIManager class,
based on GAction. It is suitable for either a traditional UI with
a GtkMenuBar, GtkToolbar and GtkStatusbar, or a modern UI with a
GtkHeaderBar and a "hamburger menu".

---

Updating devhelp to version 3.30 requires amtk. It should probably be
maintained by the GNOME team.

I might package this myself if time permits, but I'm filing this as RFP
rather than ITP for now, to have a bug number for the reason we can't
update devhelp yet.

smcv

Bug#903815: ITP: pw -- A simple command-line password manager

[Simon McVittie]

On Sun, 15 Jul 2018 at 12:07:30 +0200, Dashamir Hoxha wrote:
> Either you did not look close enough to the code, or you are not
> an expert on bash scripting (bash is a bit cryptic and difficult
> to understand even for experts).

You are right to say that shell scripting (for bash or for Bourne shells
in general) is cryptic and difficult to understand. I've found that many
of the people who understand shell well enough to write correct shell
scripts prefer to avoid writing non-trivial shell scripts, because they
know they will be more productive in a language with fewer sharp edges.

In my experience, writing a robust shell script requires a lot of
defensive programming (this is not just my personal opinion, Debian
Policy also touches on this [1]).

> Instead of basing your judgment on general opinions, why don't you
> try to find any particular situation that will break the script in some
> interesting way ;) This is called proof by counter-example.
> If you cannot do this, and if nobody else can do this, then you cannot
> claim that it is not safe to use this script.

You can use proof by counter-example to demonstrate that a particular
shell script is not correct: if your assertion is "this shell script
behaves as documented", finding an input that will make the script
behave not-as-documented disproves that assertion. The converse is
not true. If nobody finds an input that breaks the shell script, that
does not mean that no such input exists: it could equally well mean
that nobody has looked for long enough yet, for instance because they
consider auditing a shell script that doesn't start with set -e [1]
to be an inefficient use of their time.

smcv

[1] https://www.debian.org/doc/debian-policy/#scripts

Bug#722309: ITP: minetest-mod-itemdrop -- Minetest mod - Item Drop

[Simon McVittie]

On Tue, 10 Sep 2013 at 08:36:10 +0200, Dominik George wrote:
> * Package name: minetest-mod-itemdrop

In response to the imminent closure of alioth.debian.org I
have moved the packaging git repository for this module to:
https://salsa.debian.org/games-team/unfinished/minetest-mod-itemdrop

Please move it from unfinished/ to the main games-team/ namespace if/when
it is uploaded to the NEW queue.

Thanks,
smcv

Bug#873296: ITP: minetest-mod-xdecor -- Lightweight decoration module for minetest

[Simon McVittie]

On Sat, 26 Aug 2017 at 11:41:16 +0200, Julien Puydt wrote:
> * Package name: minetest-mod-xdecor

I have moved the packaging git repository for this module to:
https://salsa.debian.org/games-team/unfinished/minetest-mod-xdecor

Please move it from unfinished/ to the main games-team/ namespace if/when
it is uploaded to the NEW queue.

Thanks,
smcv

Bug#721200: ITP: minetest-mod-moretrees -- Minetest mod - more trees

[Simon McVittie]

On Thu, 29 Aug 2013 at 01:58:51 +0200, Dominik George wrote:
> * Package name: minetest-mod-moretrees

In response to the imminent closure of alioth.debian.org I
have moved the packaging git repository for this module to:
https://salsa.debian.org/games-team/unfinished/minetest-mod-moretrees

Please move it from unfinished/ to the main games-team/ namespace if/when
it is uploaded to the NEW queue.

Thanks,
smcv

Bug#721086: ITP: minetest-mod-plantlife -- Minetest mod - Plantlife

[Simon McVittie]

On Tue, 27 Aug 2013 at 22:49:31 +0200, Dominik George wrote:
> * Package name: minetest-mod-plantlife
>   Description : Minetest mod - Plantlife

I have moved the packaging git repository for this module to:
https://salsa.debian.org/games-team/unfinished/minetest-mod-plantlife

Please move it from unfinished/ to the main games-team/ namespace if/when
it is uploaded to the NEW queue.

Thanks,
smcv

Bug#898301: ITP: openjazz -- a free, open-source version of the classic Jazz Jackrabbitâ?¢ games

[Simon McVittie]

On Thu, 17 May 2018 at 11:25:53 +0200, Fabian Greffrath wrote:
> Simon McVittie wrote:
> > g-d-p patches welcome! Hopefully this should be a relatively simple game
> > to package due to its age.
> 
> Probably a stupid question, but since GOG provides a package for Windows
> and one for Linux (in general), which one do we use for g-d-p?

No strong preference. Assuming they contain the same data files, plus
different executables/wrappers/emulators that you will discard anyway:

If one of the packages is smaller, prefer that one.

If one of the packages is more straightforward to unpack, prefer that one.
(g-d-p has built-in support for unpacking tar and zip archives which is
lighter-weight than needing innoextract.)

If you're feeling particularly thorough, tell g-d-p how to unpack both.

smcv

Bug#898301: ITP: openjazz -- a free, open-source version of the classic Jazz Jackrabbit™ games

[Simon McVittie]

On Wed, 09 May 2018 at 22:48:58 +0200, Fabian Greffrath wrote:
> I have put g-d-p in CC, because (a) proprietary game data will be
> necessary to actually play the game. There is a shareware version
> available for free (beer) download and GOG has just re-released all
> available versions in a single package.

g-d-p patches welcome! Hopefully this should be a relatively simple game
to package due to its age.

> Furthermore, (b) we will have to
> decide on a file system location for the game data that both g-d-p use
> to install the data files and that openjazz uses to search for these
> files.

For non-free games with a free engine, our convention is to use the
name of the game in the data location, not the name of the engine,
for a few reasons:

- in principle there might be a second engine that would share the data,
  like the various engines for Doom and Quake 1
- in principle there might be a second game that would be playable by
  the engine, like the way ioquake3 can play either Quake III Arena,
  OpenArena or Urban Terror, and ScummVM can play all sorts of things
- the game is what users actually want, and the engine is an
  implementation detail

So /usr/share/games/jazz-jackrabbit?

This isn't a requirement, just a convention; the less likely it is for
there to be a second engine for the game or a second game playable in
this engine, the more willing we are to use an engine-based directory
name like /usr/share/games/corsix-th or /usr/share/games/lgeneral.

smcv

Bug#646377: Packaging Xonotic

[Simon McVittie]

On Mon, 10 Nov 2014 at 17:22:04 +0100, Markus Koschany wrote:
> I have pushed the initial packaging for xonotic and xonotic-data to Git.
> 
> http://anonscm.debian.org/cgit/pkg-games/xonotic.git
> 
> http://anonscm.debian.org/cgit/pkg-games/xonotic-data.git

Due to the imminent shutdown of Alioth I've moved these to:

https://salsa.debian.org/games-team/unfinished/xonotic
https://salsa.debian.org/games-team/unfinished/xonotic-data

(If someone picks these up, please move them to the main games-team
namespace when they're ready for NEW.)

> http://anonscm.debian.org/cgit/pkg-games/gmqcc.git
> http://anonscm.debian.org/cgit/pkg-games/d0-blind-id.git

Also moved, to:

https://salsa.debian.org/games-team/unfinished/d0-blind-id
https://salsa.debian.org/games-team/unfinished/gmqcc

smcv

Bug#606931: RFP: enemy-territory-data -- Game data downloader for the id software game Enemy Territory

[Simon McVittie]

On Tue, 01 Mar 2016 at 12:29:54 +0100, Markus Koschany wrote:
> I have packaged the initial version of ET:Legacy a while ago. My Debian
> files can be found here:
> 
> https://anonscm.debian.org/cgit/pkg-games/etlegacy.git

Due to the imminent shutdown of Alioth I've moved this to

https://salsa.debian.org/games-team/unfinished/etlegacy

(I'm using the "unfinished" sub-group for packages that never made it
into the archive for whatever reason.)

smcv

Bug#728193: O: assaultcube, assaultcube-data

[Simon McVittie]

On Sun, 01 Dec 2013 at 22:27:47 -0600, Jordan Metzmeier wrote:
> The source packages have been moved to git under pkg-games.

On Sat, 03 Sep 2016 at 17:17:55 +0200, Nicolás Ortega wrote:
> I've been looking at this package for a while and wish to package it

In preparation for the shutdown of alioth.debian.org I've
moved the packaging git repositories for these packages from
https://anonscm.debian.org/cgit/pkg-games/ to new infrastructure:

https://salsa.debian.org/games-team/assaultcube
https://salsa.debian.org/games-team/assaultcube-data

Please send any packaging contributions there.

(Sorry, I don't intend to work on these packages myself.)

smcv

Bug#891458: RFH: gnome-shell-extension-top-icons-plus -- GNOME Shell extension to move system tray icons to top bar

[Simon McVittie]

Package: wnpp
Severity: normal

I request assistance with maintaining the
gnome-shell-extension-top-icons-plus package. It's currently unmaintained
upstream, so if it stops working in a future version of GNOME Shell
and I'm not able to fix it, it'll have to be removed. I can't commit to
being able to take over upstream maintenance myself.

The package description is:
 This GNOME Shell extension alters how the Shell displays freedesktop.org
 system tray icons (status icons, notification-area icons). In the upstream
 GNOME Shell code, these icons appear in a small pop-out panel in the
 bottom left corner of the screen; this extension moves them to the
 top bar, between the clock and system menu.
 .
 Please note that each user will need to enable the extension manually, for
 example using the gnome-tweaks application.

Bug#891457: RFH: gnome-shell-extension-caffeine -- GNOME Shell extension to keep your computer awake

[Simon McVittie]

Package: wnpp
Severity: normal

I request assistance with maintaining the gnome-shell-extension-caffeine
package. It's currently unmaintained upstream, so if it stops working
in a future version of GNOME Shell and I'm not able to fix it, it'll
have to be removed. I can't commit to being able to take over upstream
maintenance myself.

The package description is:
 This GNOME Shell extension provides an icon which can be toggled to
 inhibit the actions that would normally be taken when the system is idle,
 including screen locking, screensaver and automatic suspend. By default
 it also inhibits idle actions while any window is full-screen, and it can
 be configured to inhibit idle actions while user-specified applications
 have any window open.
 .
 Please note that each user will need to enable the extension manually, for
 example using the gnome-tweaks application.
 This GNOME Shell extension provides an icon which can be toggled to
 inhibit the actions that would normally be taken when the system is idle,
 including screen locking, screensaver and automatic suspend. By default
 it also inhibits idle actions while any window is full-screen, and it can
 be configured to inhibit idle actions while user-specified applications
 have any window open.
 .
 Please note that each user will need to enable the extension manually, for
 example using gnome-tweak-tool.

Bug#889744: ITP: mallard-ducktype -- Parser for Ducktype, a lightweight documentation syntax

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: mallard-ducktype (binaries: ducktype, 
python3-mallard.ducktype)
  Version : 0.3
  Upstream Author : Shaun McCance
* URL : http://projectmallard.org/
https://github.com/projectmallard/mallard-ducktype
* License : Expat (MIT/X11)
  Programming Lang: Python
  Description : Parser for Ducktype, a lightweight documentation syntax

 Ducktype is a lightweight non-XML syntax for Mallard, a topic-oriented
 markup language for help files. Mallard is primarily used in GNOME help.

 The ducktype package contains the ducktype command-line tool, which
 can be used to convert Ducktype documents into the Mallard XML format
 for further processing by the tools and stylesheets in the yelp-tools
 and yelp-xsl packages.

 The python3-mallard.ducktype package contains the Python 3 library.

Ducktype is used for a document in dbus providing D-Bus API design advice,
which we don't yet ship in Debian. It might be used for help files in
GNOME in future, but as far as I know all GNOME apps use the XML variant
of Mallard at the moment.

I intend to maintain this in the GNOME team, or possibly the Python
Modules team when they switch to gbp-pq and salsa.debian.org.
Co-maintainers welcome (indeed, sole maintainers welcome if someone
wants to take this away from me).

Bug#777089: Next python-mote pre-condition - issue with pybuild: python-backports.tempfile conflicting python-backports.weakref

[Simon McVittie]

On Thu, 25 Jan 2018 at 17:45:33 +, peter green wrote:
> > However, in Debian case, I do not know how this can be handled as
> > 2 packages cannot hold the same file (even if __init__ is only an empty
> > file), and at least one must be present (if you install only one).

The Python jargon is that the "backports" shared by backports.tempfile
and backports.weakref is a "namespace package".

For Python 2, dh_python2 handles this: python-lazr.restfulclient and
python-lazr.uri are an example of cooperating packages that share a
namespace package.

For Python >= 3.3, the __init__.py is unnecessary due to
.

> I'm not a python expert but I expect the least-horrible way to do this
> would be to ship a package that only contained the __init__. Then have
> all the python-backports.* packages depend on it.

This is not necessary, and would probably (hopefully?) lead to rejection
from the NEW queue.

smcv

Bug#777089: Please help with test suite error and installation problem of python-aws-xray-sdk (Was: If there is no response in debian-python then debian-science might be the right team)

[Simon McVittie]

On Mon, 15 Jan 2018 at 12:59:29 +0100, Andreas Tille wrote:
> E File 
> "/build/python-aws-xray-sdk-0.95/.pybuild/pythonX.Y_2.7/build/tests/test_async_local_storage.py",
>  line 10
> E   async def _test():
> E   ^
> E   SyntaxError: invalid syntax

Looks like it needs python3 >= 3.5. https://www.google.com/search?q=async%20def

> python-aws-xray-sdk (0.95-1) wird eingerichtet ...
>   File "/usr/lib/python2.7/dist-packages/aws_xray_sdk/core/async_context.py", 
> line 14
> def __init__(self, *args, loop=None, use_task_factory=True, **kwargs):
>  ^
> SyntaxError: invalid syntax

That's Python 3 syntax too. https://www.python.org/dev/peps/pep-3102/

smcv

Bug#883246: ITP: python-enum-compat -- Python enum/enum34 compatibility package

[Simon McVittie]

On Fri, 01 Dec 2017 at 12:13:26 +0100, Ondrej Novy wrote:
> 2017-12-01 11:25 GMT+01:00 Simon McVittie <[1]s...@debian.org>:
> Within Debian, wouldn't this be better achieved by having Python 2 
> packages
> that require enum34 depend on python-enum34 directly, as they already do?
> 
> I already tried this solution.

That's unfortunate - the solution you tried first does seem better.

Would it perhaps work to bundle enum_compat's egg-info with
python-enum34? It doesn't seem great to be introducing a whole new
source package just to express a conditional dependency (that will itself
become obsolete when Python 2 does), and it's not as if enum_compat has
any actual code, so hopefully it will never have bugs or new versions.
dpkg-source and gbp can do multi-tarball upstreams these days (yquake2
is one example).

That doesn't work either if a Python 3 package depends on enum_compat,
but it would seem a little absurd to have a python3-enum-compat package,
given that we no longer support any version of Python 3 that doesn't
have enum. (And in the worst case, python3-dev could provide egg-info
for enum_compat, if dependencies on it become widespread.)

I can't help wondering whether it would be a better solution for
upstreams that need enum to depend on
(['enum34'] if sys.version < (3, 4) else []), or on Python 3.4
(either way, short-term it's still a Debian patch, but long-term it's
hopefully upstreamable).

smcv

Bug#883246: ITP: python-enum-compat -- Python enum/enum34 compatibility package

[Simon McVittie]

On Fri, 01 Dec 2017 at 10:48:37 +0100, Ondřej Nový wrote:
> * Package name: python-enum-compat
>   Version : 0.0.2
>   Upstream Author : Jakub Stasiak 
> * URL : https://pypi.python.org/pypi/enum-compat
> * License : Expat
>   Programming Lang: Python
>   Description : Python enum/enum34 compatibility package
> 
> This is a "virtual" package, its whole purpose is to install enum34 on Python 
> older than 3.4. On Python 3.4+ it’s a no-op.

Within Debian, wouldn't this be better achieved by having Python 2 packages
that require enum34 depend on python-enum34 directly, as they already do?
python-enum34 could have a Provides on some other name if that helped.

Even oldstable has python3 >= 3.4, so Python 2 (and pypy, which implements
the Python 2 language) is the only reason that enum34 itself has any
value.

The proposed name also isn't really compatible with Debian Python
policies: you can't `import enum_compat` after installing it.

smcv

Bug#877684: RFP: gnome-software-plugin-snap -- Snap support for GNOME Software

[Simon McVittie]

Control: reassign 877684 gnome-software
Control: block 877684 by 876862

On Wed, 04 Oct 2017 at 10:22:19 -, David Seaward wrote:
> Source code (for plugin):
> https://git.gnome.org/browse/gnome-software/tree/plugins/snap

This is part of the gnome-software package upstream, so this is a feature
request for Debian's existing gnome-software source package (adding a
new binary package to it) rather than a request for an entirely new
source package to be packaged. Reassigning accordingly.

The GNOME maintainers are unlikely to want to enable this while snapd
is in danger of being autoremoved from testing, so I'm setting this
as blocked by #876862.

I'm also not sure that this would be such a good idea to enable while
snap relies on Ubuntu-specific AppArmor features for sandboxing: without
AppArmor, it lacks a security boundary, as far as I'm aware. Those kernel
patches seem to be finally going upstream, so perhaps that objection
can go away soon.

The GNOME maintainers would probably also want someone who regularly
uses snap (perhaps someone from Ubuntu/Canonical?) to commit to doing
any necessary testing and debugging for this plugin on Debian.

Regards,
smcv

Bug#873594: ITP: flatpak-builder -- Flatpak application building helper

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: flatpak-builder
  Version : 0.9.8+$n_commits (until a release is made)
  Upstream Author : Alexander Larsson and others
* URL : https://github.com/flatpak/flatpak-builder
* License : LGPL
  Programming Lang: C
  Description : Flatpak application building helper

 Flatpak installs, manages and runs sandboxed desktop application bundles.
 See the flatpak package for a more comprehensive description.
 .
 flatpak-builder is a tool that makes it easy to build applications and their
 dependencies by automating the configure && make && make install steps.

flatpak 0.9.8 includes flatpak-builder in the same source package
(although we package it as a separate binary package in Debian). It has
been separated out upstream since 0.9.8, and will have a parallel
release schedule in future.

Bug#862954: ITP: mvdsv -- a modern QuakeWorld server

[Simon McVittie]

On Fri, 19 May 2017 at 11:50:51 +0200, Lee Garrett wrote:
> I will be maintaining it alone.
[...]
> I'm open to co-maintaining this package if any individual or team is 
> interested.
> I will need a sponsor for this package.

Please consider joining the Games Team. We have Quake enthusiasts who
can probably help with this package and/or sponsor your uploads.
(We also maintain all the other Quake engines packaged so far.)
In particular, Michael Gilbert maintains ezquake in the Games Team.

I try not to maintain heavily multiplayer-focused games, so I'm unlikely
to want to co-maintain mvdsv myself; but I do co-maintain the more
single-player-focused Quake engines, the game-data-packager tool that
packages the required game data, the quake-server package that wraps
systemd units and sysvinit scripts around the various Quake engines,
and the Debian Quake mini-policy.

The debian-devel-games mailing list is an appropriate place for discussion
of these packages.

S

Bug#862698: ITP: minecraft -- blocks to build anything you can imagine

[Simon McVittie]

On Tue, 16 May 2017 at 09:58:11 -0700, Russ Allbery wrote:
> Another thing that would be a really neat addition to a wrapper around
> Minecraft would be to run it inside a restrictive namespace by default.

Yes, that's why I suggested Flatpak. It would also be possible to use
a long bwrap command-line - that's what Flatpak does internally.
One day I should try making game-data-packager's games (mostly the quake
family) use bwrap like that. This would be easier if we had and could
rely on "the /usr merge" - Flatpak runtimes always use merged-/usr
for that reason.

However, as long as Minecraft and other proprietary software requires
X11[1], it's going to be hard to put it in a sandbox that actually
protects you very much - and that's equally true with or without
Flatpak. Using a separate games-playing uid, together
with the support for "fast user switching" (Ctrl+Alt+Fx with a nice
GUI) in desktop environments like GNOME[2], and systemd-logind's
ability to grant and revoke hardware access as this switching occurs,
seems a lot safer for the medium term.

This is of course a trade-off: banishing all untrusted software to
separate hardware would be safer (resistant to kernel vulnerabilities
and permissions misconfiguration) but less convenient, whereas assuming
X11 isn't being abused is more convenient but less safe. Choose your
preferred safety/convenience balance.

S

[1] Also, as long as it requires networking and X11 uses abstract Unix
sockets, since abstract Unix sockets are mediated by network
namespaces, not filesystem namespaces
[2] I'm sure other desktop environments also do this, I just don't use
them frequently enough to know how

Bug#862698: ITP: minecraft -- blocks to build anything you can imagine

[Simon McVittie]

On Mon, 15 May 2017 at 18:40:34 -0300, Carlos Donizete Froes wrote:
> * Package name: minecraft
>   Version : 0.1
>   Upstream Author : Carlos Donizete Froes 
> * URL : https://minecraft.net
> * License : BSD-2-Clause
>   Programming Lang: Shell

This information does not seem consistent with what I know about
Minecraft, which is that it is proprietary software, available for
purchase (not even free-as-in-free-beer), originally written by Mojang AB,
now owned by Microsoft, written in Java, and currently versioned 1.11.2.

If what you mean is that you will be writing a "launcher" package in contrib
similar to the steam package, please give the package a description (and
perhaps name) that indicates that. The description in this ITP seems
very misleading.

You might find it useful to look at (for example) the quake, freespace2
and game-data-packager packages for examples of dealing with
non-distributable game data. I don't think we have permission to
redistribute anything from Minecraft, not even the small,
infrequently-updated launcher that downloads, updates and runs the
more-frequently-updated game, unless Microsoft has changed the policy
that Mojang AB historically had (analogous to how Valve encourage
redistribution of the stub that downloads and launches Steam, which is
what's actually in our steam package).

If this package downloads proprietary files automatically, here are some
issues that should be considered:

* minimizing amount of code run as root (downloading the Minecraft
  launcher per-user is probably better - the launcher will download
  Minecraft itself once per user anyway, so sharing files between users
  to reduce disk space usage is not straightforward)
* not executing code that was not obtained in a way that can be trusted:
  downloading via https with correct certificate validation, or checking
  the launcher against known-good cryptographic hashes like
  game-data-packager does, or similar
* not preventing offline apt updates in which packages are downloaded
  while online, then installed at a later time without Internet access

game-data-packager/doc/why.mdwn might be interesting reading.

https://github.com/endlessm/flatpak-minecraft is an alternative approach
to making Minecraft more straightforward to install on a Debian derivative,
although it would be nice if we could use a Debian-based runtime that
included the OpenJDK JRE from Debian (building Debian-based Flatpak
runtimes is something I want to work on, but I haven't got there yet).

Regards,
S

Bug#779043: RFA: gtkpod

[Simon McVittie]

On Mon, 23 Feb 2015 at 17:39:34 +0100, Matteo F. Vescovi wrote:
> I'm not using an iPod anymore and I'm not going to buy a new one,
> so I've lost interest in maintaining this package.

Hi,
I notice this package is in principle team-maintained. Is there anyone
else in the gtkpod maintainers team besides mfv@ and hyperair@?

The other packages maintained by the gtkpod maintainers team seem to
have had a lot of NMUs. Should libgpod, libimobiledevice, libplist,
libusbmuxd and usbmuxd also be considered to have RFA status?

If they are effectively unmaintained, it might be better to orphan
them so that QA uploads can be used on them: libgpod, libplist,
libimobiledevice, libusbmuxd and usbmuxd are all considered to be key
packages, because they are part of desktop tasks (GNOME and others) and
have high popcon scores. libimobiledevice is part of the default GNOME
desktop (and others) via gvfs-backends and upower, while libgpod is part
of the default GNOME desktop via rhythmbox-plugins.

libgpod and gtkpod don't look particularly active upstream. If they
are significantly less active than the lower level libraries, then it
might be time to think about disabling libgpod support in
amarok/banshee/clementine/rhythmbox for buster so that it isn't on the
critical path for releases?

(Sorry, I have no interest in taking over these packages or mentoring
a new maintainer: I don't own any iDevices.)

Regards,
S

Bug#854951: ITP: recipes -- Recipe application for GNOME

[Simon McVittie]

On Sun, 12 Feb 2017 at 09:44:53 -0500, Jeremy Bicha wrote:
> On Sun, Feb 12, 2017 at 9:22 AM, Simon McVittie  wrote:
> > I think this is too generic. The upstream name is Recipes, and that name is
> > fine within the context of GNOME
> 
> Thanks. I requested that the developer change the name to gnome-recipes.

That isn't actually what I said. As an upstream name, in context,
Recipes is fine. In an OS distribution that isn't particularly GNOME-centric,
it isn't. Mapping between the two is part of the OS distributor job.

Analogous: we call GNU Make "make" because we're a GNU/Linux
distribution[1], so the assumption should be that things with a GNU
version are the GNU version unless otherwise stated. The BSDs call it
"gmake", short for GNU Make, because they are not primarily GNU
distributions.

Similarly, I wouldn't be surprised if a more GNOME-centric OS distribution
like Fedora was happy to release recipes-*.rpm, but in Debian it should
be gnome-recipes_*.{dsc,deb}.

If upstream don't want to rename it, combining a renamed source
and binary package with ./configure --program-prefix=gnome-
and some trivial patches to desktop files and D-Bus and/or systemd
services should be reasonably straightforward.

S

[1] or a GNU/{Linux,kFreeBSD,Hurd} distribution if you count
non-release ports

Bug#854951: ITP: recipes -- Recipe application for GNOME

[Simon McVittie]

On Sun, 12 Feb 2017 at 07:55:18 -0500, Jeremy Bicha wrote:
> Package Name: recipes

I think this is too generic. The upstream name is Recipes, and that name is
fine within the context of GNOME (particularly when its machine-readable
name is actually org.gnome.Recipes), but within Debian/Ubuntu it would
seem more reasonable to call it gnome-recipes.

(Alternatively, you could consider packaging it as org.gnome.recipes?
But that's probably too unconventional within Debian.)

My usual rule of thumb is that non-indicative "brand names" like Evince,
Nautilus and Leafpad are fine without a prefix, but generic names like
(GNOME) Builder, (GNOME) Terminal and (lx)launcher need a namespace prefix.

S

Bug#853142: O: python-whoosh

[Simon McVittie]

Package: wnpp
Severity: normal

As mentioned in ,
أحمد المحمودي (Ahmed El-Mahmoudy) is no longer maintaining python-whoosh.

It is available in a collab-maint git repository, and currently has a
release-critical bug that needs investigating (another test failure,
#853115, which might be a recent regression in some other package).

My NMU for #812768 is already present in the git repository.

Regards,
S

Bug#843486: ITP: vectis -- build software in a disposable virtual machine

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

Package name: vectis
Version : (unreleased, not ready for wide use yet)
Upstream Author : Simon McVittie
URL : https://git.pseudorandom.co.uk/vectis.git
  https://github.com/smcv/vectis
License : MIT (Expat)
Programming Lang: Python
Description : build software in a disposable virtual machine

vectis compiles software and does other Debian-related tasks in a temporary
environment, using an implementation of the autopkgtest virtualisation
service interface.

To minimize side-effects on the host system by the built code, and
side-effects on the built code by the host system, vectis does all builds
in a newly cloned virtual machine (or in theory a container, but that mode
has not yet been tested).

To avoid the need to back up large VM or container images, vectis can
rebuild its own VM images and sbuild tarballs at any time.

To increase confidence that a package that builds successfully in vectis
will also build successfully in real Debian infrastructure, vectis tries
to be pedantically correct: builds use a sbuild configuration closely
resembling the real buildds, and in particular Architecture:any and
Architecture:all binary packages are built separately by default,

Bug#841852: ITP: use-package -- use-package declaration for simplifying your .emacs

[Simon McVittie]

On Mon, 24 Oct 2016 at 01:31:18 +0500, Lev Lamberov wrote:
> * Package name: use-package

As with your parallel ITP for bind-key, this seems like a very generic
package name, and gives no indication that it is to do with Emacs.

I suggest talking to an Emacs-related packaging team (for example
Debian Emacs addons team 
seems to maintain several packages) about whether there is an Emacs
addon naming convention you can follow. From a quick glance at the packages
already in Debian, it might be conventional to disambiguate the purpose
of these packages by calling them something like use-package-el, or (if
obtained via https://melpa.org/ which appears to be an Emacs equivalent of
CPAN) elpa-use-package.

(Disclaimer: I know nothing about Emacs, other than that it is a highly
extensible text editor. Please talk to someone who knows more than me
before proceeding.)

Bug#841851: ITP: bind-key -- simple way to manage personal keybindings

[Simon McVittie]

On Mon, 24 Oct 2016 at 01:28:27 +0500, Lev Lamberov wrote:
> * Package name: bind-key

This seems like a very generic package name, and gives no indication
that it is to do with Emacs.

I suggest talking to an Emacs-related packaging team (for example
Debian Emacs addons team 
seems to maintain several packages) about whether there is an Emacs
addon naming convention you can follow. From a quick glance at the packages
already in Debian, it might be conventional to disambiguate the purpose
of these packages by calling them something like bind-key-el, or (if obtained
via https://melpa.org/#/bind-key which appears to be an Emacs equivalent of
CPAN) elpa-bind-key.

(Disclaimer: I know nothing about Emacs, other than that it is a highly
extensible text editor. Please talk to someone who knows more than me
before proceeding.)

Bug#831690: ITP: xdg-desktop-portal-gtk -- GTK/GNOME portal backend for xdg-desktop-portal

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: xdg-desktop-portal-gtk
  Version : 0.1
  Upstream Author : Matthias Clasen and others
* URL : https://github.com/flatpak/xdg-desktop-portal-gtk
* License : LGPL-2.1+
  Programming Lang: C
  Description : GTK/GNOME portal backend for xdg-desktop-portal

xdg-desktop-portal-gtk provides a GTK/GNOME implementation for the
desktop-agnostic xdg-desktop-portal service. This allows sandboxed
applications to request services from outside the sandbox using
GTK GUIs (app chooser, file chooser, print dialog) or using GNOME
services (session manager, screenshot provider).

Bug#831689: ITP: xdg-desktop-portal -- desktop integration portal for Flatpak

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: xdg-desktop-portal
  Version : 0.1
  Upstream Author : Matthias Clasen and others
* URL : https://github.com/flatpak/xdg-desktop-portal
* License : LGPL-2.1+
  Programming Lang: C
  Description : desktop integration portal for Flatpak

xdg-desktop-portal provides a portal frontend service for Flatpak, and
possibly other desktop containment/sandboxing frameworks. This service
is made available to the sandboxed application, and provides mediated
D-Bus interfaces for file access, URI opening, printing and similar
desktop integration features.

The implementation of these interfaces is expected to require
user confirmation before responding to the sandboxed application's
requests. For example, when the sandboxed application ask to open a file,
the portal implementation will open an "Open" dialog outside the sandbox,
and will only make the selected file available to the sandboxed app if
that dialog is confirmed.

xdg-desktop-portal is designed to be desktop-agnostic, and uses a
desktop-environment-specific GUI backend such as xdg-desktop-portal-gtk
to provide its functionality.

Bug#825761: ITP: gnome-shell-extension-top-icons-plus -- move system tray icons to top bar

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: gnome-shell-extension-top-icons-plus
  Version : (git snapshot)
  Upstream Author : Jean-Christophe Baptiste, Mohammad Javad Naderi, Adel 
Gadllah
* URL : https://github.com/phocean/TopIcons-plus
* License : GPL-2+
  Programming Lang: JavaScript
  Description : GNOME Shell extension to move system tray icons to top bar

 This GNOME Shell extension alters how the Shell displays freedesktop.org
 system tray icons (status icons, notification-area icons). In the upstream
 GNOME Shell code, these icons appear in a small pop-out panel in the
 bottom left corner of the screen; this extension moves them to the
 top bar, between the clock and system menu.

Bug#823548: linux-user-chroot deprecation

[Simon McVittie]

On Sun, 15 May 2016 at 20:49:28 +0200, László Böszörményi wrote:
> On Mon, May 9, 2016 at 7:10 PM, Simon McVittie  wrote:
> > May I co-maintain, preferably in collab-maint git? xdg-app (now called
> > Flatpak, apparently) is going to depend on it soon; for now it's a git
> > submodule, but when a system copy is supported I suspect I'll need to keep
> > it somewhat in sync with xdg-app.
>
>  Do you think it will be tightly coupled? We may co-maintain the
> packages vica-versa, will talk about it.

Hard to say, neither has had a release since xdg-app's privileged part became
bubblewrap. I'll probably start by leaving it using a private copy of bwrap
(it's a git submodule), and send patches upstream to be able to use a system
copy when it's a bit clearer that that's going to work in practice.

You're welcome to co-maintain xdg-app, just add yourself to Uploaders (it's
in collab-maint git). I'm hoping to put a first version packaged as flatpak
into NEW somewhat soon.

It would be great if you could put the bubblewrap packaging on
git.debian.org or something.

S

Bug#823548: linux-user-chroot deprecation

[Simon McVittie]

On Mon, 09 May 2016 at 19:01:15 +0200, László Böszörményi (GCS) wrote:
> I plan to package bubblewrap, then ask for removal of linux-user-chroot.

May I co-maintain, preferably in collab-maint git? xdg-app (now called
Flatpak, apparently) is going to depend on it soon; for now it's a git
submodule, but when a system copy is supported I suspect I'll need to keep
it somewhat in sync with xdg-app.

S

Bug#823548: linux-user-chroot deprecation

[Simon McVittie]

[added linux-user-chroot maintainer/subscribers to Cc, quoting full text
for their benefit]

On Mon, 09 May 2016 at 09:13:42 -0400, Colin Walters wrote:
> l-u-c post: https://mail.gnome.org/archives/ostree-list/2016-May/msg0.html
> 
> FWIW if any transition scripts are written I'd be happy to have them in l-u-c 
> upstream.
> I'm as yet unsure whether it's worth doing so, or pushing for dependent 
> consumers
> to do a hard port.  I'm doing the latter with my l-u-c consumers 
> (gnome-continuous, my
> bashrc).
> 
> Are there any l-u-c dependencies in the Debian archive?

There don't seem to be any reverse-dependencies, so perhaps linux-user-chroot
should just disappear.

S

Bug#823832: ITP: python-mpd-parser -- MPEG-DASH MPD(Media Presentation Description) Parser

[Simon McVittie]

On Mon, 09 May 2016 at 14:26:23 +0200, Ondrej Koblizek wrote:
> * Package name: python-mpd-parser

Python packages in Debian should always be named after the highest-level
module available for import, which in this case appears to be mpd,
hence python[3]-mpd.

However, there is already a well-established "mpd" top-level Python
module, for the Music Player Daemon. (python-mpd, in Debian since 2008;
python-mpd and python-mpd2 on PyPI. python-mpd is the unmaintained
original. python-mpd2 is a fork which still uses the "import mpd"
namespace, and I'm in the process of switching the Debian package
to it: .)

Please talk to the upstream about a less colliding name, perhaps mpdesc.

S

Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture

[Simon McVittie]

On Sat, 07 May 2016 at 17:15:51 +0200, Adam Borowski wrote:
> Good idea!  The test harness is already templated, so there's no reason to
> make this x86 specific.

Altivec detection on 32-bit powerpc would also be useful, assuming 32-bit
powerpc has a future in Debian at all. ioquake3:powerpc would depend on it.

(If anyone reading this has a non-Altivec PowerPC capable of running a
1999 game engine and thinks ioquake3 needs to support it, there's a request
for testing on #701561.)

S

Bug#823548: ITP: bubblewrap -- setuid wrapper for unprivileged chroot and namespace manipulation

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 
Control: affects -1 xdg-app

* Package name: bubblewrap
  Version : (no releases yet)
  Upstream Author : Colin Walters, Alex Larsson
* URL : https://github.com/projectatomic/bubblewrap/
* License : LGPL-2+
  Programming Lang: C
  Description : setuid wrapper for unprivileged chroot and namespace 
manipulation

bubblewrap is a setuid wrapper tool with which unprivileged users can
launch containers, using chroot and various Linux namespace features,
without giving those users access to the full attack surface of user
namespaces.

---

bubblewrap is derived from xdg-app-helper in src:xdg-app, which is itself
derived from linux-user-chroot. The next upstream version of
xdg-app will replace xdg-app-helper with a private copy of bubblewrap as a
git submodule; later versions are intended to use a system copy of
bubblewrap, at least optionally.

When bubblewrap has matured a bit and had some releases, it might make
sense to treat it as superseding linux-user-chroot, possibly with a
transitional package containing a script for command-line compatibility,
so that the overall number of setuid-root things in the archive can
reduce. (linux-user-chroot maintainer in X-Debbugs-Cc)

I intend to maintain this in collab-maint, with pkg-utopia as
the primary maintainer (unless some other team wants it). Co-maintainers
and security audits welcome.

S

Bug#823200: ITP: python-poyo -- lightweight (subset of) YAML parser for Python

[Simon McVittie]

On Mon, 02 May 2016 at 09:05:33 +0200, Vincent Bernat wrote:
> Poyo is a simple parser for a subset of YAML. The subset is quite
> restricted and doesn't include JSON or any JSON constructs.

Ugh. Restricted "not quite" dialects of well-known languages considered
harmful...

> I need
> this dependency as part of cookiecutter but I could also just patch
> cookie cutter to use ruamel.yaml or PyYAML which are already packaged.

There appear to be versions of python-cookiecutter that depend on both
already, suggesting that its upstream author can't make up their mind?
(python-yaml in stable, python-ruamel.yaml in testing)

python-yaml (PyYAML) appears to be fairly ubiquitous: 150+ packages
have a hard dependency on it, including some quite major ones
like various pieces of OpenStack. python-ruamel.yaml's only reverse
dependency seems to be python-cookiecutter.

I would recommend going with majority opinion on this one. I
use python3-yaml as a "humane"[1] data definition language in
game-data-packager, and it seems fine. It isn't the fastest, but if you
need fast human-readable (de)serialization that doesn't need to be humane
for *writing*, use Python's built-in support for JSON instead.

(game-data-packager actually "compiles" from the uncompressed YAML that
is stored in git to the zipped JSON that is in the binary package,
during its build - it's very much data-driven, so this speeds up its
startup by at least an order of magnitude.)

S

[1] http://bluebones.net/2005/02/humane-text-formats/

Bug#697477: closed by Simon McVittie (Bug#697477: fixed in xdg-app 0.5.0-1)

[Simon McVittie]

Control: reopen 697477

On Mon, 21 Mar 2016 at 08:03:07 +, Debian Bug Tracking System wrote:
>  xdg-app (0.5.0-1) experimental; urgency=medium
>  .
>* Prepare package for Debian (Closes: #697477)

This should of course have closed #813308 instead of this bug. Reopening.

S

Bug#819152: ITP: gnome-shell-extension-caffeine -- disable screensaver and auto-suspend

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: gnome-shell-extension-caffeine
  Version : (git snapshot, would currently be 0~git20160320)
  Upstream Author : Jean-Philippe Braun
* URL : https://github.com/eonpatapon/gnome-shell-extension-caffeine
* License : GPL-2+
  Programming Lang: JavaScript
  Description : disable screensaver and auto-suspend

 This GNOME Shell extension provides an icon which can be toggled to
 inhibit the actions that would normally be taken when the system is idle,
 including screen locking, screensaver and automatic suspend. By default
 it also inhibits idle actions while any window is full-screen, and it can
 be configured to inhibit idle actions while user-specified applications
 have any window open.
 .
 Please note that each user will need to enable the extension manually, for
 example using gnome-tweak-tool.

Bug#819151: ITP: gnome-shell-extension-mediaplayer -- GNOME Shell extension to control media players

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: gnome-shell-extension-mediaplayer
  Version : (git snapshot, would currently be 0~git20160215)
  Upstream Author : Jean-Philippe Braun, Mantas Mikulėnas
* URL : 
https://github.com/eonpatapon/gnome-shell-extensions-mediaplayer
* License : GPL-2+
  Programming Lang: JavaScript
  Description : GNOME Shell extension to control media players

 This GNOME Shell extension monitors D-Bus for media players that implement
 the MPRIS v2.1 specification, and displays an indicator in the Shell's system
 menu which shows current song and can be used to control playback. Suitable
 media players include Rhythmbox, Banshee and Clementine.
 .
 Please note that each user will need to enable the extension manually, for
 example using gnome-tweak-tool.

Bug#813308: ITP: xdg-app -- Application deployment framework for desktop apps

[Simon McVittie]

On Sun, 31 Jan 2016 at 14:17:08 +0100, Simon McVittie wrote:
> xdg-app installs, manages and runs sandboxed desktop application bundles,
> primarily those from a source outside the main distribution.

I've uploaded this to experimental NEW. Packaging repository:
https://anonscm.debian.org/git/collab-maint/xdg-app.git

> I'm currently intending to put this under the pkg-utopia team alongside
> D-Bus and polkit, but if anyone else wants to get involved, co-maintainers
> and other suggestions are welcome.

The maintainer is set to pkg-utopia, but it's in collab-maint so that
any DD (or non-DD with collab-maint access) can commit[1]. I'm happy to
hand it over to any other relevant team.

S

[1] in the spirit of 
https://joeyh.name/blog/entry/ending_the_tyranny_of_unix_permissions/

Bug#697477: ITP: ostree

[Simon McVittie]

On Mon, 01 Feb 2016 at 17:37:58 +0100, Matthias Klumpp wrote:
> I would like to help with it and co-maintain the package. Also talked
> with Alexander Larsson a bit about xdg-app on Debian this FOSDEM.

I've uploaded ostree to experimental NEW, with both of us in Uploaders.
The packaging repository is in collab-maint:
https://anonscm.debian.org/git/collab-maint/ostree.git
Contributions, changes and co-maintainers welcome.

> Regarding packaging teams, I wonder whether it would make sense to
> start a new team and move related software under that umbrella.
> Specificallly, putting xdg-app, Limba, AppStream, appstream-glib and
> ostree together might make sense - right now,I am maintaining most of
> them in the pkg-packagekit Git repo.

For now I've set the maintainer to the Utopia team because I'm a member
of that team and not pkg-packagekit, but I'd be happy to hand it over
to any relevant team, as long as I don't end up made responsible for
software I don't use.

It would be nice if the git repo could stay in collab-maint if another
team takes it, rather than requiring special group membership: I'm trying
out an approach inspired by

for this group of packages.

S

Bug#813306: ITP: libgsystem -- GIO-based library targeted at OS components

[Simon McVittie]

On Sun, 31 Jan 2016 at 13:34:20 +0100, Simon McVittie wrote:
> libgsystem was partly a prototyping area for features that were considered
> for future GLib inclusion, and partly a Linux-specific supplement for
> the mostly-portable functionality in GLib.

This is now in the NEW queue for experimental. Packaging is in collab-maint:
https://anonscm.debian.org/cgit/collab-maint/libgsystem.git

It's currently marked as maintained by the Utopia maintenance team (dbus,
polkit, udisks etc.) but I'd be happy to hand it over to any relevant
team. Co-maintainers would also be very welcome.

S

Bug#697477: ITP: ostree

[Simon McVittie]

[Re-sending because it doesn't seem to have reached the bug, with links
added; sorry if you get this twice.]

Hi,
I've been looking at ostree recently, with the intention of using it in
conjunction with xdg-app. David King and Alexander Larsson have made
some Ubuntu PPA packages, which don't necessarily have all the
integration that you had in mind, but they have the advantage of already
existing. Even if they can only deploy non-Debian distributions, that's
a good start.

Would you mind if I tidy up those packages and get them into experimental?

Would you like to be a co-maintainer?

I had been intending to put them under the pkg-utopia umbrella, but
collab-maint might be more appropriate if people outside that team are
interested.

Here is my work-in-progress and a blog post about it:

https://smcv.pseudorandom.co.uk/2016/xdg-app/
https://anonscm.debian.org/cgit/users/smcv/ostree.git

Regards,
S