Bug#965102: ITP: pup -- command-line HTML processor

[Arnaud Rebillout]

Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout 

* Package name: pup
  Version : 0.4.0+git20190919.681d7bb-1
  Upstream Author : Eric Chiang
* URL : https://github.com/ericchiang/pup
* License : Expat
  Programming Lang: Go
  Description : command-line HTML processor

 Pup is a command-line tool for processing HTML. It
 reads from stdin, prints to stdout, and allows the
 user to filter parts of the page using CSS selectors.
 .
 Inspired by jq (http://stedolan.github.io/jq/), pup aims to be
 a fast and flexible way of exploring HTML from the terminal.
 


I intend to maintain this package with the Go team.

Bug#965108: ITP: goldplate -- cute and simple opaque golden test runner for CLI applications

[Félix Sipma]

Package: wnpp
Severity: wishlist
Owner: Félix Sipma 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: goldplate
  Version : 0.1.1
  Upstream Author : Jasper Van der Jeugt 
* URL : https://github.com/fugue/goldplate.git
* License : Apache-2.0
  Programming Lang: Haskell
  Description : Cute and simple opaque golden test runner for CLI 
applications

Place your test cases in a directory, annotate them with .goldplate 
files, and that's it. Completely language agnostic. Perhaps its best 
feature is that it can automatically fix your tests outputs.
.
Give goldplate a try if:
.
- You are testing a CLI application
- The application produces deterministic output (e.g. compilers, 
  prettifiers, convertors)
- The application is quick to start (a process is created for every 
  test)
- Your output is text-based and not huge in size

This package is needed by the newer version of patat.

I will need a sponsor.

-- 
Félix


signature.asc
Description: PGP signature

Re: Preferred form of modification for binary data used in unit testing?

[Christian Kastner]

On 2020-07-15 09:45, Philipp Hahn wrote:
> if a *previous* version of a software generated a *buggy* binary
> database, that bug got fixed in a *newer* version and also some
> *recovery* mechanism was added to allow reading that broken format
> *once*, but there is no code the write the *broken* file again. For
> *unit testing* the upstream developers added an *example* of such a
> broken database to their test data.
> What's the preferred form of modification for that data set?
> 
> * Should I include a copy of the *broken code* to generate that data?
> * Declare that there in no preferred form for modification, as a
> "open-save"-cycle with the current code will not re-create the bit
> idencial file again.
> * Remove the test data because it is not DFSG conformant and hope the
> Debian build will never break the recovery code.> * Include instructions on 
> how to re-build the broken version and give
> instructions on how to maybe rebuild a similar broken file.

Personally, I would do nothing at all. At most, I would choose the last
of the above options (include instructions).

This is about the payload to a particular decoding unit test. It's a
common pattern to generate such payloads without storing the original
source or even intermediate steps -- which, unless I'm mistaken, would
imply that the final result has become the preferred form for
modification. The expectation is simply for a particular chunk of data
to produce a particular output.

I think it is reasonable to assume that upstream generated the broken
file with the old code, implemented the unit test, and discarded the
broken code. So given the current (shipped) version of the software,
even upstream couldn't recreate the broken file.

Generally speaking, I think it's a mistake to apply the question of
"preferred form for modification" to unit test payloads. Unit tests are
purely about functionality. The original source to a payload is an
arbitrary choice (possibly even randomly generated), and could be
replaced with any other appropriate arbitrary choice at no detriment to
the software or the user.

Re: Preferred form of modification for binary data used in unit testing?

[Pirate Praveen]

On Thu, Jul 16, 2020 at 12:28, Christian Kastner  wrote:

On 2020-07-15 09:45, Philipp Hahn wrote:

 if a *previous* version of a software generated a *buggy* binary
 database, that bug got fixed in a *newer* version and also some
 *recovery* mechanism was added to allow reading that broken format
 *once*, but there is no code the write the *broken* file again. For
 *unit testing* the upstream developers added an *example* of such a
 broken database to their test data.
 What's the preferred form of modification for that data set?

 * Should I include a copy of the *broken code* to generate that 
data?

 * Declare that there in no preferred form for modification, as a
 "open-save"-cycle with the current code will not re-create the bit
 idencial file again.
 * Remove the test data because it is not DFSG conformant and hope 
the
 Debian build will never break the recovery code.> * Include 
instructions on how to re-build the broken version and give

 instructions on how to maybe rebuild a similar broken file.


Personally, I would do nothing at all. At most, I would choose the 
last

of the above options (include instructions).

This is about the payload to a particular decoding unit test. It's a
common pattern to generate such payloads without storing the original
source or even intermediate steps -- which, unless I'm mistaken, would
imply that the final result has become the preferred form for
modification. The expectation is simply for a particular chunk of data
to produce a particular output.

I think it is reasonable to assume that upstream generated the broken
file with the old code, implemented the unit test, and discarded the
broken code. So given the current (shipped) version of the software,
even upstream couldn't recreate the broken file.

Generally speaking, I think it's a mistake to apply the question of
"preferred form for modification" to unit test payloads. Unit tests 
are

purely about functionality. The original source to a payload is an
arbitrary choice (possibly even randomly generated), and could be
replaced with any other appropriate arbitrary choice at no detriment 
to

the software or the user.



I think this needs to be clearly documented in policy. I don't think 
this interpretation is generally accepted. I have seen many cases where 
tests are disabled for this reason.

Bug#965118: ITP: colorcet -- A set of useful perceptually uniform colormaps for plotting scientific data

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 

* Package name: colorcet
  Version : 2.0.2
  Upstream Author : James A. Bednar 
* URL : https://github.com/holoviz/colorcet
* License : CC-BY-4.0
  Programming Lang: Python
  Description : A set of useful perceptually uniform colormaps for plotting 
scientific data

Colorcet is a collection of perceptually uniform colormaps for use with
Python plotting programs like bokeh, matplotlib, holoviews, and
datashader based on the set of perceptually uniform colormaps created by
Peter Kovesi at the Center for Exploration Targeting.

Re: Preferred form of modification for binary data used in unit testing?

[Christian Kastner]

On 2020-07-16 12:53, Pirate Praveen wrote:
>> Generally speaking, I think it's a mistake to apply the question of
>> "preferred form for modification" to unit test payloads. Unit tests are
>> purely about functionality. The original source to a payload is an
>> arbitrary choice (possibly even randomly generated), and could be
>> replaced with any other appropriate arbitrary choice at no detriment to
>> the software or the user.
>>
> 
> I think this needs to be clearly documented in policy. I don't think
> this interpretation is generally accepted. I have seen many cases where
> tests are disabled for this reason.

Perhaps I spoke too generally. For example, I can see, as one of
probably many counter-examples, the case where the input is not
completely arbitrary (eg: input is a captured stream).

But to take the other extreme, using completely arbitrary data, as an
example: say my code implements a ROT13 function and I create a test for
it using a blob of random data as well as the expected output.

That random data was generated somehow, eg: using Python's random
module, and could therefore be regenerated given the correct program and
seed. However, I did not include the code to generate that data.

Would we really reasonably expect anyone to act upon that random blob in
any way?

Re: Preferred form of modification for binary data used in unit testing?

[Johannes Schauer]

Hi,

Quoting Christian Kastner (2020-07-16 14:08:34)
> On 2020-07-16 12:53, Pirate Praveen wrote:
> >> Generally speaking, I think it's a mistake to apply the question of
> >> "preferred form for modification" to unit test payloads. Unit tests are
> >> purely about functionality. The original source to a payload is an
> >> arbitrary choice (possibly even randomly generated), and could be
> >> replaced with any other appropriate arbitrary choice at no detriment to
> >> the software or the user.
> > I think this needs to be clearly documented in policy. I don't think
> > this interpretation is generally accepted. I have seen many cases where
> > tests are disabled for this reason.
> Perhaps I spoke too generally. For example, I can see, as one of
> probably many counter-examples, the case where the input is not
> completely arbitrary (eg: input is a captured stream).
> 
> But to take the other extreme, using completely arbitrary data, as an
> example: say my code implements a ROT13 function and I create a test for
> it using a blob of random data as well as the expected output.
> 
> That random data was generated somehow, eg: using Python's random
> module, and could therefore be regenerated given the correct program and
> seed. However, I did not include the code to generate that data.
> 
> Would we really reasonably expect anyone to act upon that random blob in
> any way?

I have another data point with one of my packages (genext2fs) where I made a
contribution to upstream. Their unit tests execute the program with some input
and a given set of parameters and then check that the md5sum of the created
ext2 filesystem image matches the expected value. Without thinking, I added the
following into their test script:

H4sIA+3WTW6DMBAF4Fn3FD6B8fj3PKAqahQSSwSk9vY1uKssGiJliFretzECJAYeY1s3JM4UKYRlLG7H5ZhdTIHZGevK+ZTYkgrypRFN17EdlKIh5/G3++5d/6N004qbA47er8/fWVduV2aLD7D7/A85C88Ba/ufA/sQIhk25VdA/2+h5t+1gx4/pd7vfv+Hm/ytmfNH/8vr+ql7e3UR8DK6uUx9L/uMtev/3P8p+KX/oyHlZMuqntX/9T34Z9yk9Gco8//xkGWf8Uj+Mbpl/Y+JVJQtq9r5/K+bj3Z474+Xk9wG4JH86/rvyzxAirfYnOw+/+vXWTb+uv9PaV3+JfiSv/WOlJVPf/f5AwAAAMD/9A0cPbO/ACgAAA==

This is a base64 encoded gzipped tarball with a few test files in it. I
generated it using GNU tar but since I found it likely that a GNU tar version
in the future (or the past) will produce a slightly different tarball and
because I needed some fixed input without different output on systems without
GNU tar (like BSD or MacOS) or on older systems or on future systems, I just
dumped that binary blob into the upstream software. In the meantime, that
binary blob is even in the Debian package:

https://sources.debian.org/src/genext2fs/1.5.0-1/test.sh/#L89

The curious thing for me personally is, that I didn't feel bad about this at
all and at no point from writing the code up to me packaging and uploading the
Debian package containing the blob, I thought even twice about whether this is
DFSG compliant or not. Only now after having read this thread I start wondering
whether I have actually created an RC bug myself. Did I? I love the principles
of the DFSG and it really surprises me that despite my love for these freedoms
I didn't think twice about including that binary blob instead of generating it
on the fly. Was my mind fooled by how short the blob is? A perl script
generating the tarball such that it's bit-by-bit identical across all platforms
would be longer than this blob.

What do you guys think? Should I put work into writing a script which produces
above binary blob as part of the test suite to avoid having my package be RC
buggy? I would love to get some guidance.

Thanks!

cheers, josch

signature.asc
Description: signature

Packaging minetest mods

[Julien Puydt]

Hi,

I have packaged a few mods for the minetest game these last years. 
Recent minetest versions have a feature where you can download mods
directly online.

So the questions are :

(1) should I go on updating the existing packages? or ask for their
removal? orphan them? whatever?

(2) should I go on packaging new things for minetest?

Do we have a policy for such situations?

Wesnoth has the same kind of feature, for example, and doesn't look
like it comes with much in the way of in-Debian add-ons...

Cheers,

JP

Re: Preferred form of modification for binary data used in unit testing?

[Sean Whitton]

Hello Philipp,

On Wed 15 Jul 2020 at 09:45AM +02, Philipp Hahn wrote:

> Hi,
>
> if a *previous* version of a software generated a *buggy* binary
> database, that bug got fixed in a *newer* version and also some
> *recovery* mechanism was added to allow reading that broken format
> *once*, but there is no code the write the *broken* file again. For
> *unit testing* the upstream developers added an *example* of such a
> broken database to their test data.
> What's the preferred form of modification for that data set?
>
> * Should I include a copy of the *broken code* to generate that data?
> * Declare that there in no preferred form for modification, as a
> "open-save"-cycle with the current code will not re-create the bit
> idencial file again.
> * Remove the test data because it is not DFSG conformant and hope the
> Debian build will never break the recovery code.
> * Include instructions on how to re-build the broken version and give
> instructions on how to maybe rebuild a similar broken file.

I would remove the test data because it does not seem DFSG-conformant.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Packaging minetest mods

[Sean Whitton]

Hello,

On Thu 16 Jul 2020 at 05:17PM +02, Julien Puydt wrote:

> Hi,
>
> I have packaged a few mods for the minetest game these last years.
> Recent minetest versions have a feature where you can download mods
> directly online.
>
> So the questions are :
>
> (1) should I go on updating the existing packages? or ask for their
> removal? orphan them? whatever?
>
> (2) should I go on packaging new things for minetest?

This is pretty much the same situation with Emacs addons -- it can
download them itself now, but we still package plenty of them in the
archive.

It depends on whether you think it is still valuable to have them in
Debian.  Are there reasons why someone might prefer to install the
version from Debian, or will they always want the latest and greatest
upstream version?

In the case of Emacs addons, clearly there is value in having a stable
set of addon versions available from the archive.  Perhaps not with
Minetest?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Packaging minetest mods

[Wolfgang Silbermayr]

On 7/16/20 5:44 PM, Sean Whitton wrote:
> Hello,
> 
> On Thu 16 Jul 2020 at 05:17PM +02, Julien Puydt wrote:
>>
>> I have packaged a few mods for the minetest game these last years.
>> Recent minetest versions have a feature where you can download mods
>> directly online.
>>
>> So the questions are :
>>
>> (1) should I go on updating the existing packages? or ask for their
>> removal? orphan them? whatever?
>>
>> (2) should I go on packaging new things for minetest?
> 
> This is pretty much the same situation with Emacs addons -- it can
> download them itself now, but we still package plenty of them in the
> archive.
> 
> It depends on whether you think it is still valuable to have them in
> Debian.  Are there reasons why someone might prefer to install the
> version from Debian, or will they always want the latest and greatest
> upstream version?

I really appreciate having the mods packaged in Debian packages. In the
specific case of Minetest, there is at least some extra value in having
them packaged, because in contrast to the client, the minetest-server
doesn't have any kind of integration or tooling to interact with the
contentdb service that is used for the distribution of these mods [0]. I
perceive installing the mods by hand inconvenient.

I think this would also be an opportunity to think about creating some
tooling that supports the initial generation and updating of the
packages by fetching the version information and archives from the
contentdb API [1]. Might be useful for watching new releases. It also
allows for extracting some metadata automatically, such as dependencies
or compatible Minetest versions, and use these for generating parts of
the control file. That would probably facilitate the maintenance of
these packages.

--

[0] https://github.com/minetest/minetest/issues/7358
[1] https://content.minetest.net/help/api/

Re: Preferred form of modification for binary data used in unit testing?

[Bastian Blank]

On Thu, Jul 16, 2020 at 08:42:24AM -0700, Sean Whitton wrote:
> I would remove the test data because it does not seem DFSG-conformant.

Care to explain?  You can't claim DFSG violation without showing which
part.

Also please explain how you would make sure the code is tested.

Bastian

-- 
Killing is wrong.
-- Losira, "That Which Survives", stardate unknown

Re: Preferred form of modification for binary data used in unit testing?

[Russ Allbery]

Philipp Hahn  writes:

> * Declare that there in no preferred form for modification, as a
> "open-save"-cycle with the current code will not re-create the bit
> idencial file again.

This is my gut reaction.  Modifying this piece of testing data is mostly
pointless.  It's kind of like asking what the preferred form of
modification of a PGP public key is.

One might want to generate *more* testing data, I guess, but is that worth
keeping the old code around forever?  I'm dubious the benefit is worth it.

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

Re: Preferred form of modification for binary data used in unit testing?

[Steve McIntyre]

Hey Philipp,

Philipp Hahn wrote:
>
>if a *previous* version of a software generated a *buggy* binary
>database, that bug got fixed in a *newer* version and also some
>*recovery* mechanism was added to allow reading that broken format
>*once*, but there is no code the write the *broken* file again. For
>*unit testing* the upstream developers added an *example* of such a
>broken database to their test data.
>What's the preferred form of modification for that data set?
>
>* Should I include a copy of the *broken code* to generate that data?
>* Declare that there in no preferred form for modification, as a
>"open-save"-cycle with the current code will not re-create the bit
>idencial file again.
>* Remove the test data because it is not DFSG conformant and hope the
>Debian build will never break the recovery code.
>* Include instructions on how to re-build the broken version and give
>instructions on how to maybe rebuild a similar broken file.

Firstly, removing the test data would be absurd - less-tested code
does not serve us or our users well. If it happens to be a binary
artifact that cannot be easily recreated, then explain that. The
binary artifact has become the preferred form for modification once
you have it.

In some cases you won't be able to sensibly reproduce the artifact
that causes a problem, but you keep it around to ensure test
coverage. IMHO there is no issue here.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

Videoconference Friday 2020-07-17 18:00 UTC (Was: For those who want to keep on contributing (Was: Debian @ COVID-19 Biohackathon (April 5-11, 2020))

[Andreas Tille]

Hi,
   
for those who would like to join our next videomeeting it will happen at
   
 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Debian+CoViD-19+Biohackathon+Video+Conference&iso=20200717T20&p1=37&ah=1

The meeting is on the Debian Social channel

 https://jitsi.debian.social/DebianMedCovid19

These weekly video meetings were started in the Debian Med
Biohackathon[1].  The topic is what contributors have done in the past
week and to coordinate the work for next week.  Despite the one week of
hackathon is over Covid-19 is not and there is a lot of remaining work
to do.  Newcomers are always welcome.

Have fun
   
   Andreas.

PS: I personally most probably cannot attend this meeting.

[1] https://lists.debian.org/debian-devel-announce/2020/03/msg00010.html

-- 
http://fam-tille.de

Bug#965161: ITP: php-oscarotero-gettext -- PHP gettext manager

[James Valleroy]

Package: wnpp
Severity: wishlist
Owner: James Valleroy 
X-Debbugs-Cc: debian-devel@lists.debian.org, jvalle...@mailbox.org

* Package name: php-oscarotero-gettext
  Version : 4.8.2
  Upstream Author : Oscar Otero 
* URL : https://github.com/php-gettext/Gettext
* License : Expat
  Programming Lang: PHP
  Description : PHP gettext manager

PHP library to collect and manipulate gettext. It supports several
file formats including .po, .mo, .php, and .json.

This package is a dependency for Shaarli (ITP #864559). I plan to
maintain this package within PHP team.

The package name was chosen to avoid a conflict with php-gettext,
which is a transitional package for php-php-gettext, which is not
related to this package.

Re: Preferred form of modification for binary data used in unit testing?

[Sean Whitton]

Hello,

On Thu 16 Jul 2020 at 07:42PM +02, Bastian Blank wrote:

> On Thu, Jul 16, 2020 at 08:42:24AM -0700, Sean Whitton wrote:
>> I would remove the test data because it does not seem DFSG-conformant.
>
> Care to explain?  You can't claim DFSG violation without showing which
> part.

That was a bit unclear -- I meant that it seems like a DFSG violation to
include the binary data but not the source code for the program that
generates that data, not that the binary data is inherently unfree.

You would need the buggy version of the software if you wanted to
make modified versions of the binary data to test for closely related
bugs, for example.

> Also please explain how you would make sure the code is tested.

I don't have a good answer for you, but whether or not something is
DFSG-free is not dependent on what purposes it serves.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Preferred form of modification for binary data used in unit testing?

[Sean Whitton]

Hello,

On Thu 16 Jul 2020 at 05:19PM -07, Sean Whitton wrote:

> You would need the buggy version of the software if you wanted to
> make modified versions of the binary data to test for closely related
> bugs, for example.

Hmm, perhaps this is not true.  Perhaps for making closely related
broken data, you would instead want to directly modify the binary blob.

It seems that there is not a general answer to the question.  The binary
test data may or may not be in its preferred form for modification,
depending on how one would want to go about preparing other pieces of
test data.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Work-needing packages report for Jul 17, 2020

[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: 1170 (new: 5)
Total number of packages offered up for adoption: 209 (new: 1)
Total number of packages requested help for: 63 (new: 0)

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



The following packages have been orphaned:

   debian-builder (#965017), orphaned 2 days ago
 Description: Rebuild Debian packages from source code
 Installations reported by Popcon: 129
 Bug Report URL: https://bugs.debian.org/965017

   kytos-sphinx-theme (#964900), orphaned 5 days ago
 Description: Theme used by kytos with sphinx -- Python
 Reverse Depends: python3-kytos-sphinx-theme
 Installations reported by Popcon: 13
 Bug Report URL: https://bugs.debian.org/964900

   kytos-utils (#964896), orphaned 5 days ago
 Description: command line utilities to use with Kytos
 Bug Report URL: https://bugs.debian.org/964896

   python-openflow (#964897), orphaned 5 days ago
 Description: low level library to parse OpenFlow messages
 Installations reported by Popcon: 3
 Bug Report URL: https://bugs.debian.org/964897

   zatacka (#964789), orphaned 6 days ago
 Description: arcade multiplayer game like nibbles
 Installations reported by Popcon: 108
 Bug Report URL: https://bugs.debian.org/964789

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



The following packages have been given up for adoption:

   srt (#964904), offered 5 days ago
 Description: Secure Reliable Transport UDP streaming library
 Reverse Depends: gstreamer1.0-plugins-bad libavformat58 libsrt-dev
   libsrt-gnutls-dev libsrt-openssl-dev nageru srt-tools
 Installations reported by Popcon: 7147
 Bug Report URL: https://bugs.debian.org/964904

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



For the following packages help is requested:

   album-data (#964105), requested 15 days ago (non-free)
 Description: themes, plugins and translations for album
 Installations reported by Popcon: 86
 Bug Report URL: https://bugs.debian.org/964105

   apache2 (#910917), requested 642 days ago
 Description: Apache HTTP Server
 Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom
   apache2-suexec-pristine backuppc courier-webadmin cvsweb debbugs-web
   dms-wsgi doc-central (135 more omitted)
 Installations reported by Popcon: 92525
 Bug Report URL: https://bugs.debian.org/910917

   aufs (#963191), requested 26 days ago
 Description: driver for a union mount for Linux filesystems
 Reverse Depends: fsprotect
 Installations reported by Popcon: 14180
 Bug Report URL: https://bugs.debian.org/963191

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

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

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

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

   cyrus-imapd (#921717), requested 524 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: 438
 Bug Report URL: https://bugs.debian.org/921717

   cyrus-sasl2 (#799864), requested 1758 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: 195019
 Bug Report URL: https://bugs.debian.org/799864

   debtags (#962579), requested 36 days ago
 Description: Debian Package Tags support tools
 Reverse Depends: packagesearch
 Installations reported by Popcon: 1635
 Bug Report URL: https://bugs.debian.org/96

Re: Preferred form of modification for binary data used in unit testing?

[Holger Levsen]

hi,

doesn't the subject already tell that we are not talking about software
and it's freeness, but rather...

something else, something...  important?

(not that I'd know more, here & now.)

my point is: i do think this is out of scope for policy as it is. and
rightfully 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: Packaging minetest mods

[Paul Wise]

On Thu, Jul 16, 2020 at 3:17 PM Julien Puydt wrote:

> I have packaged a few mods for the minetest game these last years.
> Recent minetest versions have a feature where you can download mods
> directly online.

Where/how are the downloadable mods maintained?

> (1) should I go on updating the existing packages? or ask for their
> removal? orphan them? whatever?

I would prefer they stay in Debian, because of the DFSG, apt
signatures, package management, source packages etc. Caveat: I'm only
an occasional user of minetest.

> (2) should I go on packaging new things for minetest?

As above, if you feel like it.

> Do we have a policy for such situations?

Not that I know of. In theory we could remove every package from
Debian that is available in Flatpak, Snap, CPAN and other per-language
package managers, guix/nix/etc, per-app downloaders and so on, but
there are advantages to Debian's model of package management and
development that I think we should preserve.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise