Bug#947399: ITP: yuzu -- Nintendo Switch Emulator

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: yuzu
  Version : git HEAD
* URL : https://yuzu-emu.org/
* License : GPL
  Programming Lang: C++
  Description : Nintendo Switch Emulator

will be maintained under the games team.

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Tomas Pospisek]

On 26.12.19 06:42, Norbert Preining wrote:

> (please Cc)
> 
> are there any requirements or restriction what a program packaged in
> Debian is allowed to do when starting up? Calibre is normally doing the
> following checks:
> - check for updates of itself
> - check for updates of plugins
> - send UID, OS, program version, and the icon theme selected in the
>   program to the statistic site [1]
> 
> Which of the above actions are acceptable for Debian/main?
> 
> [1] https://calibre-ebook.com/dynamic/calibre-usage

The last point seems inacceptable to me if the user hasn't explicitly
consented to it. Checking for updates might be annoying but is "OK" to me.
*t

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Mattia Rizzolo]

On Thu, Dec 26, 2019 at 11:26:26AM +0100, Tomas Pospisek wrote:
> > are there any requirements or restriction what a program packaged in
> > Debian is allowed to do when starting up? Calibre is normally doing the
> > following checks:
> > - check for updates of itself
> > - check for updates of plugins
> > - send UID, OS, program version, and the icon theme selected in the
> >   program to the statistic site [1]
> > 
> > Which of the above actions are acceptable for Debian/main?
> > 
> > [1] https://calibre-ebook.com/dynamic/calibre-usage
> 
> The last point seems inacceptable to me if the user hasn't explicitly
> consented to it. Checking for updates might be annoying but is "OK" to me.

Considering this is debian, I'd probably say that none of those are
acceptable without a proper consent for the user.  Opt-in flags in the
preference windows about "automatically checks for (plugins|program)
updates at startup" would do it….

Silently sending out details like UID, OS, etc is a no-go in my mind
though.

See also the history of chromium that had to patch away similar
features.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Geert Stappers]

On Thu, Dec 26, 2019 at 11:26:26AM +0100, Tomas Pospisek wrote:
> On 26.12.19 06:42, Norbert Preining wrote:
> 
> > (please Cc)
> > 
> > are there any requirements or restriction what a program packaged in
> > Debian is allowed to do when starting up? Calibre is normally doing the
> > following checks:
> > - check for updates of itself
> > - check for updates of plugins
> > - send UID, OS, program version, and the icon theme selected in the
> >   program to the statistic site [1]
> > 
> > Which of the above actions are acceptable for Debian/main?
> > 
> > [1] https://calibre-ebook.com/dynamic/calibre-usage
> 
> The last point seems inacceptable to me if the user hasn't explicitly
> consented to it.

That does bring back memory of  kobo e-reader which did
a "phone home" on each page of the user license agreement.
I did bring back the device to the shop, got refund
and spend my money on another e-reader.

In other words: sending out user information is unacceptable.


> Checking for updates might be annoying but is "OK" to me.

Debian user did choose the Debian version, there is no need 
for a check on an update outside Debian.


Groeten
Geert Stappers
-- 
Leven en laten leven

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Norbert Preining]

Hi Mattia,

On Thu, 26 Dec 2019, Mattia Rizzolo wrote:
> Considering this is debian, I'd probably say that none of those are
> acceptable without a proper consent for the user.  Opt-in flags in the

Yeah, agreed with you feeling, but I searched today the policy and
social contract etc etc, and I didn't find any regulation concerning it.

I mean, the UID sent is the one of the calibre installation, not the
device or anything else, it is purely an accumulation of how many
installations of calibre there are, and on which OS.

Pushing the numbers of Linux users a bit up would definitely help, so I
don't necessarily see it bad by default, but then ...

Do you have any pointer to some statement, policy, GR or so that forbids
it?

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Holger Levsen]

On Thu, Dec 26, 2019 at 08:48:44PM +0900, Norbert Preining wrote:
> Do you have any pointer to some statement, policy, GR or so that forbids
> it?

Debian packages should behave as 'good citizens' and that includes not
spying on the user.

it's probably written down in some preamble or so.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Jonas Smedegaard]

Quoting Tomas Pospisek (2019-12-26 11:26:26)
> On 26.12.19 06:42, Norbert Preining wrote:
> 
> > (please Cc)
> > 
> > are there any requirements or restriction what a program packaged in
> > Debian is allowed to do when starting up? Calibre is normally doing the
> > following checks:
> > - check for updates of itself
> > - check for updates of plugins
> > - send UID, OS, program version, and the icon theme selected in the
> >   program to the statistic site [1]
> > 
> > Which of the above actions are acceptable for Debian/main?
> > 
> > [1] https://calibre-ebook.com/dynamic/calibre-usage
> 
> The last point seems inacceptable to me if the user hasn't explicitly
> consented to it. Checking for updates might be annoying but is "OK" to me.

All of those activities are problematic, because they leak privacy.

First point is useless for packaged software and the code should be 
patched to skip it.

Second point is ideally useless as well, because plugins should be 
packaged as well.

Third point is, for the user, useless as well.

I recommend to patch to disable all three mechanisms.

...but that's not what you asked about.

I don't think Debian forbid privacy-leaky behaviours.

If you choose to not voluntarily disable these mechanisms for the Debian 
packaging, then at least consider mention explicitly these behaviours in 
long description, and list them at https://wiki.debian.org/PrivacyIssues

Thanks for bringing it up!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Norbert Preining]

Hi Jonas,

thanks for the insightful comments!

On Thu, 26 Dec 2019, Jonas Smedegaard wrote:
> First point is useless for packaged software and the code should be 
> patched to skip it.

Agreed, and that is my plan.

> Second point is ideally useless as well, because plugins should be 
> packaged as well.

Well, they aren't, and will never be packaged (unless someone steps in).
So getting notified of updates - possible of security issues - is in
principle a good point.

> Third point is, for the user, useless as well.

Jein (as we say). Indirect it might be useful to increase the number of
linux users in the statistics, and thus also the valuation and support
of the linux platform. So there is a - I agree rather diffuse - use.


> ...but that's not what you asked about.

Good point.

> If you choose to not voluntarily disable these mechanisms for the Debian 
> packaging, then at least consider mention explicitly these behaviours in 
> long description, and list them at https://wiki.debian.org/PrivacyIssues

Sounds like a good plan. I looked into this page and saw basex, which
does exactly one of the above checking for upstream versions. That is in
fact the most useless point IMNSHO, as it does not help the user to get
a newer version.

Thanks for for your comments

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Andrey Rahmatullin]

On Thu, Dec 26, 2019 at 08:48:44PM +0900, Norbert Preining wrote:
> Yeah, agreed with you feeling, but I searched today the policy and
> social contract etc etc, and I didn't find any regulation concerning it.
There are lintian checks and I think that's all.
Maybe it's time to document it in the Policy.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#947404: ITP: metamath -- Language for mathematical proofs

[Giovanni Mascellani]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: metamath
Version: 0.180
Upstream Author: Norman Megill and others
URL: http://us.metamath.org
License: GPL-2+
Description: Language for mathematical proofs

Metamath is a tiny language for expressing theorems in abstract
mathematics, accompanied by proofs that can be verified by a computer
program.

This program is the reference implementation of the language. It
provides a proof checker, a proof editor and tools to automatically
render theorems and proofs to HTML and LaTeX files.

This package does not contain proof databases, but the tools to deal
with them. The user can create their own databases, use those available
on the Internet or provided by the metamath-databases package.

Regards, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#947405: ITP: metamath-databases -- Sample databases for Metamath

[Giovanni Mascellani]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: metamath-databases
Version: no versioning scheme used by upstream
Upstream Author: Norman Megill and others
URL: http://us.metamath.org
License: Mostly PD
Description: Sample databases for Metamath

Metamath is a tiny language for expressing theorems in abstract
mathematics, accompanied by proofs that can be verified by a computer
program.

This package contains a number of Metamath databases developed
collectively by people from the Metamath project, including set.mm
(Metamath Proof Explorer) and others available at http://us.metamath.org/.

You can edit and verify these databases with any tool implementing the
Metamath language, including the reference implementation available in
the package metamath.

Regards, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles





signature.asc
Description: OpenPGP digital signature

Bug#947406: ITP: qwertone -- simple music synthesizer

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

* Package name: qwertone
  Version : 0.2.0
  Upstream Author : Andrii Zymohliad
* URL : https://gitlab.com/azymohliad/qwertone
* License : GPL-3
  Programming Lang: Rust
  Description : simple music synthesizer

Qwertone is a simple music synthesizer app.

It is basically a toy piano, but using a QWERTY keyboard for the input.

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Jonas Smedegaard]

Quoting Norbert Preining (2019-12-26 13:36:28)
> On Thu, 26 Dec 2019, Jonas Smedegaard wrote:
> > Second point is ideally useless as well, because plugins should be 
> > packaged as well.
> 
> Well, they aren't, and will never be packaged (unless someone steps in).
> So getting notified of updates - possible of security issues - is in
> principle a good point.

Let me dare paraphrase:

"Well, we will never have global peace (unless God or aliens step in). 
So monitoring our citizens - potential terrorists - is in principle a 
good point."

I agree there is a point in letting software phone home about updates to 
infections inflicted by those same tools, but it is a *bad* point.  
Better point is to not let the tool infect the system!

Yes: To me a tool which injects rogue and potentially insecure code into 
a Debian system is essentially infecting the system.

I disagree that it is a good point for packaged software to phone home 
about updates to infections inflicted by those same tools, and to me a 
tool which injects rogue and potentially insecure code into a Debian 
system is essentially infecting the system.

Makes sense for a system _without_ the governance of a distribution to 
let its tools self-govern, but such mechanisms are unsuitable in a 
system with governance - and potentially outright dangerous, because the 
user _expect_ the system-wide governance to work (not for the governance 
to knowingly let things go rogue).

It is bad that a system installed purely from Debian - with all security 
updates carefully applied and all security announcements carefully 
followed - can be insecure due to tools bypassing Debian and doing its 
own update mechanisms.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Andrey Rahmatullin]

On Thu, Dec 26, 2019 at 05:48:17PM +0500, Andrey Rahmatullin wrote:
> On Thu, Dec 26, 2019 at 08:48:44PM +0900, Norbert Preining wrote:
> > Yeah, agreed with you feeling, but I searched today the policy and
> > social contract etc etc, and I didn't find any regulation concerning it.
> There are lintian checks and I think that's all.
> Maybe it's time to document it in the Policy.
I've found only https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726998
but only the last message there is relevant.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#947407: ITP: vulkan-caps-viewer -- Vulkan Hardware Capability Viewer

[Giovanni Mascellani]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: vulkan-caps-viewer
Version: 2.02
Upstream Author: Sascha Willems
URL: https://github.com/SaschaWillems/VulkanCapsViewer
License: LGPL-3
Description: Vulkan Hardware Capability Viewer

This application displays hardware implementation details for GPUs
supporting the Vulkan API published by Khronos. It shows available
features, limits, extensions and capabilities.

The report can optionally be submitted to the public online database
available at https://vulkan.gpuinfo.org/, where different devices and
driver versions can be browsed and compared.

Version 2.03 of the application was released, but for the moment I will
package version 2.02, as 2.03 depends on Vulkan headers that are not yet
available in Debian (and I don't want to embed a copy of them). I will
update to newer versions as soon as Debian packages for Vulkan will
catch on.

Regards, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles







signature.asc
Description: OpenPGP digital signature

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Adam Borowski]

On Thu, Dec 26, 2019 at 12:41:34PM +0100, Jonas Smedegaard wrote:
> All of those activities are problematic, because they leak privacy.
> 
> First point is useless for packaged software and the code should be 
> patched to skip it.
> 
> Second point is ideally useless as well, because plugins should be 
> packaged as well.
> 
> Third point is, for the user, useless as well.

A good part of plugins won't ever be packaged.  I have a strong opinion
about privacy, but security is also a concern.

Thus, I'd suggest a policy like:

A program may auto-update its plugins/etc only if a given origin has
been enabled; installing something from an origin may be considered by
default to be a consent to check for further updates from that origin.

For example, this is the behaviour of Apt: it enables by default
origin=Debian (or Ubuntu, Devuan, Mint...) if you install from that
distribution's media, plus any explicitly added apt sources.

For Firefox, it'd mean that polling for updates from mozilla.org should
(absent a non-default configuration to the contrary) be done if there's
at least one non-packaged extension installed.

> I recommend to patch to disable all three mechanisms.
> 
> ...but that's not what you asked about.
> 
> I don't think Debian forbid privacy-leaky behaviours.

Aye, I say we should add this at least to the Policy -- if not the Social
Contract.  I believe the Dissident's Test should apply to not just licenses,
but also to building and running packaged software.

> If you choose to not voluntarily disable these mechanisms for the Debian 
> packaging, then at least consider mention explicitly these behaviours in 
> long description, and list them at https://wiki.debian.org/PrivacyIssues

+1


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Re: General Resolution: Init systems and systemd: Last call for votes

[Dirk Eddelbuettel]

-BEGIN PGP MESSAGE-

jA0ECQMC+vR93/THh2j/0sEcAdxV3lOzN7OrqPBVT6sfCMHfx3NJ3AzYHLeMsvn/
3RvYw/bzKhEgcvOAr8QA6aL0LWJwQpdKh/bhzoXRFtkhNHyjKl+LcsWY4Ldc/3oX
TdbNcVQdcNuXTGev5ZhM3hPpABF3VSyAY1DysLcdnEmC/57afMUNRu3MEcXJZMJr
dyDhaEQPsjABAoIAK0GtnjvRUXk+qeJjJVsoTib+LRojml2tODKvMUk+GO9RvvXo
1rD3qkTL8MnXRmDPEIZaCRNqA3XyBb68oBuhfwu7GqJULacgL3gZ6fIVhbxOpkWz
wuXLWqhNgjghlDEjN5IkjIAyzMfOfVaaTPpNoE/t3mWq6mh743anuoO7dbVjXJ5V
GHqaulBxsdaeEKw1Z8EtrDFKMgx7IbqZfqCyBz3n6F8AAAhRyNrnblTzwRzdYzXp
dCYDaJCvp/6cL3PCe2PYxtlk9eaWEVco+AfK9oGiA2NkN4Fo+9yKy7NbYt7tgZyz
w/m4kQuKElrMJjWlY3McTugOwbVW6gXTDfHZh42izP0JMYk1Pf1IPeVZ2RCqHxBO
z9zQdjuO0/5WXV11+dwsguRalHttl7/RXTIn5IGqCnbqAK4QWUmXADKev8LkRkLQ
avgpF5hlPx1N3f1RRLM=
=oWGf
-END PGP MESSAGE-

Re: General Resolution: Init systems and systemd: Last call for votes

[Dirk Eddelbuettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 26 December 2019 at 14:15, Debian Project Secretary - Kurt Roeckx wrote:
| - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
| 7b77e0f2-4ff9-4adb-85e4-af249191f27a
| [ 3 ] Choice 1: F: Focus on systemd
| [ 2 ] Choice 2: B: Systemd but we support exploring alternatives
| [ 1 ] Choice 3: A: Support for multiple init systems is Important
| [ 1 ] Choice 4: D: Support non-systemd systems, without blocking progress
| [ 1 ] Choice 5: H: Support portability, without blocking progress
| [ 2 ] Choice 6: E: Support for multiple init systems is Required
| [ 1 ] Choice 7: G: Support portability and multiple implementations
| [ 4 ] Choice 8: Further Discussion
| - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEronbDuEOYMARAKjyoUif4quZohoFAl4EzK8ACgkQoUif4quZ
ohqy0Q//Vk3Bu7PFprXhsiYySe28OoCkOhqBzekUFunoUeO7yI+sUtpkGSayJ+ZN
4Pmg58tHmBu+fAxzREWgCcDuvdoCikMd0dfcu5IoGg7su29QxTCOICbeVRMRj0J/
0IV58iivrIwVxwbYoPSNylfvRoLjfCen9mCNf82j82IREcFQ+JOi6jn5OrA+lEN9
hPNpid+qzOKD7eKJYGkVBtlA3SnQqQZZVbdO+o0BSWo8NNE5HkYgWjFINtaU6KJb
jv3ycofb9DVmDChlx0xGZ/Lje9h+/5QALIdWGDXjDamtfppjXFr2EPopx+CSqCQl
2sBbF2KmzYdQxAcas2MXzgv1BOL51uNlnfIIB1DePtnQkAcRCdI42eW05H561qcd
kVsaS7hIVyEzXP9PYVbx+KlEwu+bbcD9+yMXbkI4Tny5PDAvVWQtWiyjPBbQwJcd
HBowE7kWzh5hnD3hPDQwz5ALSmGTVcM/vDrgrEezb0UAf5w8dPqR7oaKQWTesoZ/
9mDI/nlf4dV59VkC1O007UK8iyHeD3Drf+G0iTMNUooK78XQniVCHaemloe9iQqv
z5wjka65N8K4DOStAR4YBbZShajpP2LkY35DHZPkBdVrGg0ghnD7/bgAA7/+tVN6
SClSLKNdIk9mB4AFfo4Wyt98sG2osl6WX0VLPeisXdh4vK80ip8=
=5ihA
-END PGP SIGNATURE-

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#947411: ITP: mopidy-mpd -- Mopidy extension for controlling Mopidy from MPD clients

[Stein Magnus Jodal]

Package: wnpp
Severity: wishlist
Owner: Stein Magnus Jodal 

* Package name: mopidy-mpd
  Version : 3.0.0
  Upstream Author : Stein Magnus Jodal 
* URL : https://mopidy.com/
* License : Apache-2.0
  Programming Lang: Python
  Description : Mopidy extension for controlling Mopidy from MPD clients

Mopidy plays music from local disk, Spotify, SoundCloud, Google Play Music,
and more. You can edit the playlist from any phone, tablet, or computer using
a variety of MPD and web clients.

This package provides a Mopidy extension for controlling Mopidy from MPD 
clients.


This extension used to be part of the mopidy package, but was extracted
to its own extension in Mopidy 3.0.

The package will be maintained in the mopidy-team group on Salsa.


signature.asc
Description: PGP signature

Bug#947412: ITP: mopidy-local -- Mopidy extension for playing music from your local music archive

[Stein Magnus Jodal]

Package: wnpp
Severity: wishlist
Owner: Stein Magnus Jodal 

* Package name: mopidy-local
  Version : 3.0.0
  Upstream Author : Stein Magnus Jodal 
* URL : https://mopidy.com/
* License : Apache-2.0
  Programming Lang: Python
  Description : Mopidy extension for playing music from your local music 
archive

Mopidy plays music from local disk, Spotify, SoundCloud, Google Play Music,
and more. You can edit the playlist from any phone, tablet, or computer using
a variety of MPD and web clients.

This package provides a Mopidy extension extension for playing music from your
local music archive. Mopidy-Local builds an index of your archive's metadata
ahead of time, and can thus provide features like search.


This extension used to be part of the mopidy package, but was extracted
to its own extension in Mopidy 3.0.

The package will be maintained in the mopidy-team group on Salsa.


signature.asc
Description: PGP signature

Bug#947414: ITP: ruby-marginalia -- Attach comments to your ActiveRecord queries

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: ruby-marginalia
  Version : 1.8.0
  Upstream Author : 37signals, LLC
* URL : https://github.com/basecamp/marginalia
* License : Expat
  Description : Attach comments to your ActiveRecord queries
 By default, it adds the application, controller, and action names as a
comment at the end of each query.
 .
 This helps when searching log files for queries, and seeing where slow
queries came from.



signature.asc
Description: OpenPGP digital signature

Bug#947415: ITP: libtest-nicedump-perl -- module for nice and human readable dumps of objects in tests

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtest-nicedump-perl
  Version : 1.0.1
  Upstream Author : Gianni Ceccarelli 
* URL : https://metacpan.org/release/Test-NiceDump
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for nice and human readable dumps of objects in tests

Test::NiceDump uses Data::Dump::Filtered and a set of sensible filters to
dump test data in a more readable way.

For example, DateTime objects get printed in the full ISO 8601 format, and
DBIx::Class::Row objects get printed as hashes of their inflated columns.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Russ Allbery]

Andrey Rahmatullin  writes:

> Maybe it's time to document it in the Policy.

I think it would be a good idea, but it's some work because of the edge
cases.  Some of the things found by the Lintian check are tedious to fix
(unless maybe we can write a tool?) and make it more annoying to package
some software for Debian, so we should be clear on the project consensus
on how much work we want people to do.  For example, documentation HTML
pages that load styles or JavaScript (for mobile support for instance)
from a CDN are a privacy leak, as are web applications whose web pages
similarly include CDN links.

To be clear, I think we probably do care about those things and do want to
ask people to change them and use JavaScript packaged in Debian, but it's
also important to not underestimate how much work that is, since the norm
in the web page world is to pin to specific versions of these JavaScript
libraries and common style files.

There are some other edge cases that are closer to Norbert's question.
For example, gnubg (which I package) uses www.random.org as a random
number source by default (the upstream default, for various reasons that
involve fewer arguments with people who are absolutely convinced gnubg
wins against human players because it cheats on dice).  I've not changed
that, but one could make an argument that's a privacy leak as well (and
feel free to convince me that I should change it).

-- 
Russ Allbery (r...@debian.org)  

Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Otto Kekäläinen]

Hello!

I've seen many times before statements like these so I'd like to raise
some discussion around the topic:

pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > The Salsa CA pipeline is recommended.
>
> For this I need to use my veto as Salsa admin.  With the CI people we
> have to work through too much problems first.

There seems to be a conflict between the Salsa admins and users of
Salsa: the more Salsa is used, the bigger becomes the maintenance
burden and the more computing resources Salsa needs. There is however
no inherent growth feedback loop in the system that would increase
maintenance commitments as usage commitments grow. In economic terms
one could say that the Salsa admins don't profit from maintaining
Salsa and as demand grows there is nothing that grows the supply at
the moment.

The reason for Salsa popularity to grow all the time is simply because
it is such a brilliant service and many Debian Developers and aspiring
new contributors love to use it. Personally I've had all my packages
on Salsa since early 2018 and I would never want to go back to the mix
of Github and Alioth I used before. Using Gitlab-CI is nowadays an
inherent part of my packaging workflow to test contributions before
merging them and to do QA before uploads. Any disruptions to Salsa
basically grinds by packaging work to a halt[1], it is so central for
me nowadays.

Since Salsa was officially launched in 2018 there has not been any [2]
new members to the Salsa admins group [3]. Alexander, Joerg and
Bastian have done a great job maintaining our Gitlab installation. The
software suite is a beast and keeping it running well is a major
effort in itself.

They need help going forward. The sentiment of restricting vital use
of Salsa is a sign of them trying to keep things under control. But
Salsa usage needs to grow, as that is good for Debian as a project.
For the Debian project I think it would be a priority to find more
resources to the Salsa admin team. I think that would be the ultimate
solution to the current conflict.

Personally I cannot commit to maintain Salsa, unfortunately. If Salsa
is out of computing resources I can however help find more sponsors
for public runners. But I have the understanding that Google has
donated plenty of cloud computing time and the root cause is not in
lack of computing resources, but in the human scalability aspects of
Salsa operations.

I hope somebody else on the debian-devel list would respond to this
call for help.

I am sure there are many ways to help the team and it is not just
about Salsa/Gitlab admin stuff, but also about creating structure in
the team, triaging issues, spreading best practices for users and
helping the most advanced users to grow into admins of Salsa etc.
Right now we don't even have any kind of salsa-related discussion list
on lists.debian.org. Thus I wanted to raise discussion on
debian-devel. In my opinion Salsa is becoming a very central piece of
the Debian infrastructure and it should have more attention on
debian-devel and from the project leader.

Thanks again for current Salsa admins for the work you've done! Salsa
is amazing and I hope it will get broader attention and help so it
scales to support our packaging work far into the future.

[1] https://salsa.debian.org/salsa/support/issues/184
[2] https://wiki.debian.org/Salsa?action=diff&rev2=37&rev1=17
[3] https://wiki.debian.org/Salsa#Maintenance

Bug#947445: ITP: libsharp -- libsharp is a fast spherical harmonic transform library.

[Leo Singer]

Package: wnpp
Severity: wishlist
Owner: Leo Singer 

* Package name: libsharp
  Version : 1.0.0
  Upstream Author : Martin Reinecke 
* URL : https://healpix.sourceforge.io
* License : GPL
  Programming Lang: C++
  Description : fast spherical harmonic transform library

libsharp is a fast spherical harmonic transform library in C++.
It used to be a part of healpix-cxx, but in the latest upstream
release of healpix-cxx, has been moved to a separate package.

Bug#947447: ITP: python3-socketio -- python3 implementation of the Socket.IO realtime client and server

[Paulo Henrique de Lima Santana (phls)]

Package: wnpp
Severity: wishlist
Owner: "Paulo Henrique de Lima Santana (phls)" 

* Package name: python3-socketio
  Version : 4.4.0
  Upstream Author : Miguel Grinberg 
* URL : https://github.com/miguelgrinberg/python-socketio
* License : MIT/X
  Programming Lang: Python
  Description : python3 implementation of the Socket.IO realtime client and 
server

 Socket.IO is a transport protocol that enables real-time bidirectional
 event-based communication between clients (typically, though not always,
 web browsers) and a server. The official implementations of the client and
 server components are written in JavaScript. This package provides Python
 implementations of both, each with standard and asyncio variants.
 .
 Client Features:
 .
 Can connect to other Socket.IO compliant servers besides the one in this
 package.
 Compatible with Python 3.5+.
 Two versions of the client, one for standard Python and another for asyncio.
 Uses an event-based architecture implemented with decorators that hides the
 details of the protocol.
 Implements HTTP long-polling and WebSocket transports.
 Automatically reconnects to the server if the connection is dropped.
 .
 Server Features:
 .
 Can connect to servers running other compliant Socket.IO clients besides the
 one in this package.
 Compatible with Python 3.5+.
 Two versions of the server, one for standard Python and another for asyncio.
 Supports large number of clients even on modest hardware due to being
 asynchronous.
 Can be hosted on any WSGI and ASGI web servers includind Gunicorn, Uvicorn,
 eventlet and gevent.
 Can be integrated with WSGI applications written in frameworks such as
 Flask, Django, etc.
 Can be integrated with aiohttp, sanic and tornado asyncio applications.
 Broadcasting of messages to all connected clients, or to subsets of them
 assigned to rooms.
 Optional support for multiple servers, connected through a messaging queue
 such as Redis or RabbitMQ.
 Send messages to clients from external processes, such as Celery workers or
 auxiliary scripts.
 Event-based architecture implemented with decorators that hides the details
 of the protocol.
 Support for HTTP long-polling and WebSocket transports.
 Support for XHR2 and XHR browsers.
 Support for text and binary messages.
 Support for gzip and deflate HTTP compression.
 Configurable CORS responses, to avoid cross-origin problems with browsers.

Work-needing packages report for Dec 27, 2019

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1238 (new: 3)
Total number of packages offered up for adoption: 238 (new: 0)
Total number of packages requested help for: 60 (new: 0)

Please refer to https://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   coco-doc (#947218), orphaned 3 days ago
 Description: Documentation for the Coco/R Compiler Generator
 Installations reported by Popcon: 13
 Bug Report URL: https://bugs.debian.org/947218

   opensvc (#947071), orphaned 6 days ago
 Description: Tools to drive OpenSVC services
 Installations reported by Popcon: 1
 Bug Report URL: https://bugs.debian.org/947071

   sgml-spell-checker (#947175), orphaned 4 days ago
 Description: spell checker for SGML documents
 Installations reported by Popcon: 18
 Bug Report URL: https://bugs.debian.org/947175

1235 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 238 packages
are awaiting adoption.  See https://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   autopkgtest (#846328), requested 1121 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker
 Installations reported by Popcon: 1179
 Bug Report URL: https://bugs.debian.org/846328

   balsa (#642906), requested 3014 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 705
 Bug Report URL: https://bugs.debian.org/642906

   broadcom-sta (#886599), requested 717 days ago (non-free)
 Description: Broadcom STA Wireless driver (non-free)
 Installations reported by Popcon: 1753
 Bug Report URL: https://bugs.debian.org/886599

   cargo (#860116), requested 989 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 1363
 Bug Report URL: https://bugs.debian.org/860116

   cyrus-imapd (#921717), requested 321 days ago
 Description: Cyrus mail system - IMAP support
 Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev
   cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication
 Installations reported by Popcon: 406
 Bug Report URL: https://bugs.debian.org/921717

   cyrus-sasl2 (#799864), requested 1555 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base adcli autofs-ldap cyrus-caldav
   cyrus-clients cyrus-common cyrus-dev cyrus-imapd cyrus-imspd
   cyrus-murder (78 more omitted)
 Installations reported by Popcon: 199228
 Bug Report URL: https://bugs.debian.org/799864

   dee (#831388), requested 1259 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-dev zeitgeist-core
 Installations reported by Popcon: 38446
 Bug Report URL: https://bugs.debian.org/831388

   developers-reference (#759995), requested 1944 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 7658
 Bug Report URL: https://bugs.debian.org/759995

   devscripts (#800413), requested 1549 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   brz-debian customdeb debci debian-builder debmake debpear (31 more
   omitted)
 Installations reported by Popcon: 11972
 Bug Report URL: https://bugs.debian.org/800413

   docker.io (#908868), requested 467 days ago
 Description: Linux container runtime
 Reverse Depends: golang-github-containers-buildah-dev
   golang-github-containers-image-dev
   golang-github-fsouza-go-dockerclient-dev
   golang-github-google-cadvisor-dev
   golang-github-openshift-imagebuilder-dev
   golang-github-samalba-dockerclient-dev kubernetes-node subuser
   whalebuilder
 Installations reported by Popcon: 2714
 Bug Report URL: https://bugs.debian.org/908868

   ed (#886643), requested 717 days ago
 Description: classic UNIX line editor
 Reverse Depends: apt-cacher libdebbugs-perl opensmtpd sn
 Installations reported by Popcon: 15830
 Bug Report URL: https://bugs.debian.org/886643

   ejabberd (#767874), requested 1879 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-c

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Norbert Preining]

Hi Jonas,

thanks for your -- interesting and funny - email ;-) I am not so much
for political discussions, but just for clarification:

> It is bad that a system installed purely from Debian - with all security 
> updates carefully applied and all security announcements carefully 
> followed - can be insecure due to tools bypassing Debian and doing its 
> own update mechanisms.

That would **not** happen automatically. No updates are pulled
automatically. The user **must** install plugins by himself to "infect"
his computer, and **must** update to increase the infection.

The only thing that happens is an information to the user that updates
are available.

So I hope you have one less worry, right? In case you never ever install
any infectious disease^Wplugin, you are free from governmental spying
and all the evil Satan send us!

Enjoy, and thanks for you comments!

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Idea: frontend tool for more efficient license reviewing based on tree-structured IR

[Mo Zhou]

Hi fellow devs,

I created an amount of NEW packages as a DD, and reviewed an amount of NEW
packages in the NEW queue as FTP trainee. Both of the two kinds of work
involves an important part -- sometimes annoying -- license checking. People
keeps complaining about it, and recently there were some related
discussions[1][2] on -project, talking about possible ways to improve -- some
in the workflow aspect, the other in the tooling aspect. In this mail I have an
idea about tooling.

This is a long mail. I've alreay organized it in a structured format so
you can apply more fast reading tricks.

The problem we are trying to solve
--

Given a arbitrary source tree, we shall examine the copyright & license
information for each file node, make sure each node complies with DFSG, and
make an overall assessment to the whole tree: ACCEPT/REJECT. Subsequently, the
tree will be flattened (the tree structure being removed) and written into
debian/copyright in machine-readable format.

Note that, automatically parsing a machine-UNreadable debian/copyright requires
a delicate recurrent neural network. That machine-UNreadable case is too
complex, so let's ignore it for now.

Existing tools, workflows; And limitations
--

## Tools

https://wiki.debian.org/CopyrightReviewTools

I'm unfamiliar with most of them. I'm only describing the two I'm familiar
with.  Both licensecheck (Jonas) and debmake (Osamu) do template/regex
matching.

## workflows

uploader: ??? there doesn't seem to be a standard process to generate
debian/copyright for all uploaders.

  I personally do `licensecheck -r --deb-machine . > debian/copyright`
  and manually tweak the content.

ftp-master: possibly manually reviewing with MC + custom plugin

  I didn't follow the recommended way. I use `ranger` (vim keybinding,
  fluent file browsing with preview panel) for reviewing packages on
  ftp-master.d.o.

## Limitations

* Tree structure is always missing (and actually not possible to present)
  in debian/copyright. When reviewing other's NEW package  as trainee, I
  feel torturous to locate the license information for a single file in
  debian/copyright.
* Tree structure is always missing. after importing a new upstream release
  with significant directory layout change, it will be inconvenient to
  locate the parts of debian/copyright should be updated. Things will become
  more complex when new licenses/copyrights emerged.
* licensecheck dumps garbage when it encounters a binary file, e.g. PNG image.
  This is not a BUG, as ftp-masters indeed checks the possible metadata in
  a binary file to make sure whether there is extra copyright/license info.
  But this is something needs to be improved...
* Generic file browsers are not designed for our special purpose, neither does
  the commercial tools.
* etc.

My idea
---

## Motivations

License reviewing is certainly inevitable. Even if we can improve the
efficiency of this process a tiny bit, it will greatly improve the efficiency
of the community on the specific task we are talking about.

I have a couple of other motivations but the above one is already strong enough.

## Core

The core of my idea is a tree-structured intermediate representation (IR) for
the "license reviewing tree". The IR is basically a directory tree with
annotations on the file nodes. The IR can be stored as a, say, JSON file.

To build such an tree-shaped IR, we need a couple of "backend" tools for
checking the copyright & license info for a SINGLE file. Such "backend" includes
but not limited to:

 * `licensecheck`. Given a file FILE, `licensecheck FILE` produces the license
name.
 * `grep` or `ripgrep`. For example, `rg -i copyright FILE` always works well.
 * "neighbor". For example, given a source file "F/I/L/E" without any copyright
& license info, looking for F/I/L/LICENSE, F/I/LICENSE, ..., etc like git
does for the ".git" directory will help.

The formated+filtered output of any combination of these backends can be
attached to the corresponding IR.

In contrast, a "frontend" tool is also needed for dealing with such IR
in a higher level. My imagined "frontend" tool is a `ranger`-like file
browser with specific designs.

 * the user can choose what backend(s) to use. If none is chosen, the frontend
   tool falls back into a general file browser with a preview panel.
 * the frontend invokes various backend to generate a template IR, and
   store it to debian/copyright.json. No wildcard or regex in file path
   is allowed in this file.
 * when viewing files, the suggestions from various backends are shown.
   the user could choose to accept of override the suggestion. These choices
   will also be recorded in the json file. Of course, when various backends
   do not agree with each other, the user has to override the suggestion,
   and manually annotate the node.
 * when finished reviewing/annotating the whole directory tree, 

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Paul Wise]

On Thu, Dec 26, 2019 at 5:52 AM Norbert Preining wrote:

> Calibre is normally doing the following checks:

I am wondering how you discovered these, was it just reading the
upstream code/website or are you monitoring traffic on your machine?

Personally, I think we need much more systematic auditing of these
sort of issues as more and more upstreams are adding update checks and
usage reporting and other statistics and telemetry. We also need
better tooling for discovering the issues, unfortunately nsntrace was
removed from Debian and opensnitch/unoon aren't packaged yet.

https://github.com/jonasdn/nsntrace/
https://github.com/kushaldas/unoon/
https://github.com/evilsocket/opensnitch/

> Which of the above actions are acceptable for Debian/main?

Personally, I don't like any of them enabled by default but with
informed consent and correct behaviour the plugin update checks could
be reasonable for the Debian package. The general update check isn't
useful on Debian but could be for some of the upstream platforms that
don't have system-wide package update checks.

In case you want to convince upstream to correct the behaviour, here
is an example of somewhere that upstream was (eventually) convinced to
make their telemetry much more reasonable, but IIRC their change of
heart about that was mainly due to the GDPR and not driven by their
developers being convinced by folks suggesting the change in the issue
tracker.

https://github.com/Ultimaker/Cura/issues/2810

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Norbert Preining]

Hi Paul,

On Fri, 27 Dec 2019, Paul Wise wrote:
> I am wondering how you discovered these, was it just reading the
> upstream code/website or are you monitoring traffic on your machine?

Upstream states clearly what he is collecting, and the rest is obvious
because displayed on start. No magic necessary.
Also no hidden stuff, all is clearly stated and open.

> Personally, I don't like any of them enabled by default but with
> informed consent and correct behaviour the plugin update checks could
> be reasonable for the Debian package. The general update check isn't

What do you mean with "informed consent and correct behaviour"? Would a
clear statement in the NEWS file be enough?

> useful on Debian but could be for some of the upstream platforms that
> don't have system-wide package update checks.

Yes, I think this is something everyone agrees upon.

> In case you want to convince upstream to correct the behaviour, here
> is an example of somewhere that upstream was (eventually) convinced to

I read through that case and I consider it quite different. In the Cura
case quite a lot of information where sent, while in the Calibre case
there is only a random ID, the OS (no specifics, just
Linux/Windows/Mac), and the iconset selected (if any) which has
influence only on the order of selectable iconsets in the menu ;-)

No information about the library (not even the number of books).

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Paul Wise]

On Fri, Dec 27, 2019 at 6:01 AM Norbert Preining wrote:

> Upstream states clearly what he is collecting, and the rest is obvious
> because displayed on start. No magic necessary.
> Also no hidden stuff, all is clearly stated and open.

That sounds reasonable then.

> What do you mean with "informed consent and correct behaviour"?

I would expect something like this: in the user interface (help menu
perhaps, or on first start), have a button "send usage feedback" (or
similar) that when pressed displays a page containing the exact data
set that is proposed to be sent, what other information is captured
(or expressly not captured) by the server (IP address etc if anything)
in the sending process, list information about what all that
information is used for (with a link to the stats etc) and buttons for
confirming sending the data and for cancelling sending.

> Would a clear statement in the NEWS file be enough?

That is unlikely to reach all users of the package, but would be
helpful if the data collection is opt-out rather than opt-in.

> I read through that case and I consider it quite different. In the Cura
> case quite a lot of information where sent, while in the Calibre case
> there is only a random ID, the OS (no specifics, just
> Linux/Windows/Mac), and the iconset selected (if any) which has
> influence only on the order of selectable iconsets in the menu ;-)
>
> No information about the library (not even the number of books).

Indeed, sounds fairly different. Is there any information about what
the random ID is, how it is generated and if it gets copied around in
sync scenarios?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#947456: ITP: golang-github-robdimsdale-sanitizer -- Keeps your (logging) sinks clean

[Bradford Boyle]

Package: wnpp
Severity: wishlist
Owner: Bradford Boyle 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-robdimsdale-sanitizer
  Version : 0.0~git20160522.ab2334c-1
  Upstream Author : Rob Dimsdale-Zucker
* URL : https://github.com/robdimsdale/sanitizer
* License : MIT
  Programming Lang: Go
  Description : Keeps your (logging) sinks clean

 sanitizer Keeps your (logging) sinks clean

This is a build-dependency for github.com/pivotal-cf/go-pivnet which in turn is
a build-dependency for github.com/pivotal-cf/pivnet-cli.