Bug#1029942: ITP: python-lua -- library for using Lua scripts from Python

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 
X-Debbugs-Cc: debian-devel@lists.debian.org, wij...@debian.org

* Package name: python-lua
  Version : 0.4
  Upstream Contact: Bas Wijnen 
* URL : https://github.com/wijnen/python-lua
* License : AGPL3+
  Programming Lang: Python
  Description : library for using Lua scripts from Python

This package has been in Debian before. It was removed in 2017.

It has now been updated to use Lua 5.4, and is fully functional again.

The long description is:
 This module provides an interface for using Lua scripts from Python.
 From Python, it allows complete access to all Lua variables and function. From
 Lua, it allows access to Python variables and functions that were passed to it
 by Python.
 .
 By default, Lua contains several insecure features, such as access to the
 host's file system. This module disables all such features by default. They
 are only enabled if the user passes the corresponding parameters when
 instantiating the Lua class.

Re: Bug#1010013: ITP: python-websocketd -- Python module for creating a http server which uses WebSockets

[Bas Wijnen]

Hi,

On Fri, Apr 22, 2022 at 05:56:08PM +0200, Andrej Shadura wrote:
> I don’t want to discourage you from packaging this, but unless I’m mistaken,
> this will be at least the third Websocket client package for Python, and at
> least the third Websocket server in Python 

Yes, I'm not surprised. I have used my module for years and it has other users
as well, so I think it is valuable to have it in Debian.

End users cannot simply swap out one of them for another, so the argument "we
already have that" doesn't apply for libraries/modules.

Thanks,
Bas


signature.asc
Description: PGP signature

Bug#1010013: ITP: python-websocketd -- Python module for creating a http server which uses WebSockets

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 
X-Debbugs-Cc: debian-devel@lists.debian.org, wij...@debian.org

* Package name: python-websocketd
  Version : 0.2
  Upstream Author : Bas Wijnen 
* URL : https://github.com/wijnen/python-websocketd
* License : AGPL3+
  Programming Lang: Python
  Description : Python module for creating a http server or client which 
uses WebSockets

This module uses the network module to create a server, and implements http(s)
and WebSockets over those connections.  With only 6 lines of code you have a
working system.  You only have to add what you want your server to do.
.
It also provides a client socket, which can be used to communicate with such a
server.

I use this module for many of my networked programs. It requires python-network
(#1010012) and python-fhs (#1010010).

Bug#1010012: ITP: python-network -- Python module for easy networking

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 
X-Debbugs-Cc: debian-devel@lists.debian.org, wij...@debian.org

* Package name: python-network
  Version : 0.2
  Upstream Author : Bas Wijnen 
* URL : https://github.com/wijnen/python-network
* License : AGPL3+
  Programming Lang: Python
  Description : Python module for easy networking

Implementing networking in C is a pain. Unfortunately, much of that pain is
copied to Python. This module instead tries to follow the "batteries included"
approach, like the rest of Python. With this module, networking is a piece of
cake. It can use tcp sockets and unix domain sockets and supports avahi and ssl
connections without hassle.
.
This module provides a Socket class and a Server class.  The Server creates
Sockets when accepting connections; Sockets can be created by the user to
initiate a connection.  All of this is symmetrical: once the connection is
established, the client and server use the same interface.
.
For providing RPC functionality in a language independent way, see
python3-websocketd.

I use this module for many of my programs, usually in combination with
python-websocketd, for which I'll file an ITP after this. It requires
python-fhs, for which I just filed #1010010.

Bug#1010010: ITP: python-fhs -- Python module for using the FHS and XDG basedir paths.

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 
X-Debbugs-Cc: debian-devel@lists.debian.org, wij...@debian.org

* Package name: python-fhs
  Version : 1.0
  Upstream Author : Bas Wijnen 
* URL : https://github.com/wijnen/python-fhs
* License : AGPL3+
  Programming Lang: Python
  Description : Python module for using the FHS and XDG basedir paths.

The FHS and XDG basedir specification defines locations for several files.
This module provides functions for accessing those files without requiring the
program to search the filesystem itself.
It provides a convenient way to use configuration from files, with commandline
override functionality.

I use this for most of my Python programs. It is also depended on by
python-network and python-websocketd, which I will file an ITP for after this.

Accepted openmsx-catapult 0.15.0-2 (source) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 28 Sep 2019 09:48:05 +0200
Source: openmsx-catapult
Architecture: source
Version: 0.15.0-2
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen 
Changed-By: Bas Wijnen 
Closes: 933477
Changes:
 openmsx-catapult (0.15.0-2) unstable; urgency=medium
 .
   * Use gtk3-version of wxwidgets. Closes: #933477
Checksums-Sha1:
 73170aaf558dfe188fe2a1e0b809f7efeaff08b2 1859 openmsx-catapult_0.15.0-2.dsc
 8e53cef5a0bc9b4bbd5f1b04f1c24b98bab76723 7396 
openmsx-catapult_0.15.0-2.debian.tar.xz
 bccfb0ad7d6b3df56e2266c595928d3d106007bc 11833 
openmsx-catapult_0.15.0-2_source.buildinfo
Checksums-Sha256:
 bbf6ec32518a5931afd74e26d7145e225eaad3720bc238c7b2bde30d6eb08d9a 1859 
openmsx-catapult_0.15.0-2.dsc
 41629478b21528aff711b42b212d8e7707ee8f5b5ef330cf38095b4e2c0916f8 7396 
openmsx-catapult_0.15.0-2.debian.tar.xz
 b5405e8f49216fef7e3908c4188ab92b0203bcacb1e6ab4a889b7a8a0a514585 11833 
openmsx-catapult_0.15.0-2_source.buildinfo
Files:
 3db15cd87bc87ef1a4de516c033a5cea 1859 otherosfs optional 
openmsx-catapult_0.15.0-2.dsc
 4e7528ac6629eaec436fcef87c0d46ac 7396 otherosfs optional 
openmsx-catapult_0.15.0-2.debian.tar.xz
 d388959e819a59b6bc3cb5ef94562206 11833 otherosfs optional 
openmsx-catapult_0.15.0-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEKI9JSvHOfJKJyDQanNF9WAfAcToFAl2PEt0SHHdpam5lbkBk
ZWJpYW4ub3JnAAoJEJzRfVgHwHE6XAYP/is5v3Imc5aNuAJYP/ZZrhHdG71/SLH4
cmwPsPpCA7NQVqQKVZWfh+ya0nkGE58mjmt/tcRUN5eewYIOEcaI+ApLJ0OFFKIo
ERLf5Th/4+SgDSb0kbQ+b7IxOmdr9FzsXe2rGPOyw/W48u10X7h+Eq53s2IlVTnY
jgORYTBHJhsu3zYocAs7mE0cnJclNSWSts59bE6L87/nZ9HUYl06/uJyIBnwxc0z
r0rQ0DaHefVL+QGnQb4cbpG3+2/s9z1D+HOgvwTaz97OvUEMmAYYrdqS94RsdVqr
KeOK0vgauFel7fcJ2no5MyP5R+iZ451lKJnJ3CkZIkgdVxL6i2OU/sTgmge1CVIA
aqyg/r/CJpz4akFGDOD7r4i7o7idSSCRucMI545ruoy8yiKe0ercfAKr/CY0j4An
auO8J/z8QOtjLBuOQopNWtzkfj3eHOD/U+Ok+7NrjAfutpsUBvh1q66yfPo/EIBY
Y8FZljjDQ4t42nXWl+J8RtDhhzn0psFKM7nxOz/H8kUKB8+tDg2dJbt7I94pERn8
UhpmKojsdv9uPGNlrZOJ9yoehup7bLImVBpuFXMsk5/b+kNQXrRW6xma2Eh8TSpq
GJYKM0U/YHArCwAfYVxh1cSvlfMVOe6/PnFlIk28grRWJEGXNE0OHWAkkUmpxUGR
j2LjcViuL/fj
=z9lC
-END PGP SIGNATURE-

Bug#930723: ITP: arduino-sanguino -- atmega644 files for use with Arduino

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: 3-D printer team <3dprinter-gene...@alioth-lists.debian.net>

* Package name: arduino-sanguino
  Version : 1.0.0
  Upstream Author : Kristian Sloth Lauszus 
* URL : http://lauszus.github.io/Sanguino/
* License : GPL-3+
  Programming Lang: C++
  Description : Platform files for Arduino to run on ATmega644

This package contains files for compiling programs for the ATmega644
microcontroller.

This is useful for people who want to use the Arduino programming environment
with the atmega644 microcontroller as the target hardware.

I will maintain this within the 3-D printer team.

Accepted openmsx-catapult 0.15.0-1 (source amd64) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 03 Jan 2019 10:26:00 +0100
Source: openmsx-catapult
Binary: openmsx-catapult
Architecture: source amd64
Version: 0.15.0-1
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen 
Changed-By: Bas Wijnen 
Description:
 openmsx-catapult - GUI for openMSX
Changes:
 openmsx-catapult (0.15.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Remove obsolete call to dh_installmenu.
   * Update standards version to 4.2.1. (No changes needed.)
Checksums-Sha1:
 1f50c7e6bdef3cfde9561ab7f8e87b48d6ac3601 1854 openmsx-catapult_0.15.0-1.dsc
 9f6fb8566a294a2ae1b59e901ebe84c0d3bc09dd 1473189 
openmsx-catapult_0.15.0.orig.tar.gz
 f53c5ce70d2fbe3b8703236da555d268c5ddfb91 7360 
openmsx-catapult_0.15.0-1.debian.tar.xz
 096a990e1d32b4c3a301709f14299461765c3492 11792 
openmsx-catapult_0.15.0-1_amd64.buildinfo
 df4ad8b293539b61131efdad9ae4ba8474a4909c 388928 
openmsx-catapult_0.15.0-1_amd64.deb
Checksums-Sha256:
 93715223d804f0367d701c9d669b150dfa5eaa337c6adeaa69a7f8678521a2d8 1854 
openmsx-catapult_0.15.0-1.dsc
 ca923e2a2d996e15e63a444cc059d76f313e3b2bdafb48830b67d992059210f2 1473189 
openmsx-catapult_0.15.0.orig.tar.gz
 f84a2512bb61afb1c3736aed7eb9ee8cc96d4fd5f1761f98557ad0e21e4fe5b8 7360 
openmsx-catapult_0.15.0-1.debian.tar.xz
 f75cd86672cf4db372d008eabdda4be49e12a659ca22830c330e32afc6e7 11792 
openmsx-catapult_0.15.0-1_amd64.buildinfo
 ab536c824e2272204e33b570f62797e34840f053e1ff2f0e327c9eec8b6f28c5 388928 
openmsx-catapult_0.15.0-1_amd64.deb
Files:
 0bb45321f69744e9cb60af1cfa42a2d0 1854 otherosfs optional 
openmsx-catapult_0.15.0-1.dsc
 636938c4e882196f3896e7c6598b74ae 1473189 otherosfs optional 
openmsx-catapult_0.15.0.orig.tar.gz
 b098ce29c5a70a85499d3305678fd45e 7360 otherosfs optional 
openmsx-catapult_0.15.0-1.debian.tar.xz
 2cff3e27c60c8b46e9da6cc636451172 11792 otherosfs optional 
openmsx-catapult_0.15.0-1_amd64.buildinfo
 6d5161a749816e1e3f7dee9bdb355e28 388928 otherosfs optional 
openmsx-catapult_0.15.0-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEKI9JSvHOfJKJyDQanNF9WAfAcToFAlwt1bQSHHdpam5lbkBk
ZWJpYW4ub3JnAAoJEJzRfVgHwHE67OEP/3Rlcgzg5jrYTxzmYP5L1wdzefefUovw
3Aatpu6B4W2LhsnFVGjQVR5R3Siu6uk+LMDzzCO44XtPoHUTY87Dcdb+cgzYTRX3
lAhxZv5LPrroDZ43Yfmay1sFw6wqNNS9cTh8GczKFtfPgKlBi1qZgqTuxQArgC5G
IvOrs2mpOGwG3ZhEChvwrXIkMu8fHJquKAcg759YpvelXpmmI/WVJLjmEeJ/t3MC
7ouJHJUCxNTnP0eYrmP1PcHnWcjdrG4liHWfA+99bXIeY14aVjhYhAqcldaX0Az3
PlO+WkcPJAdCPqFoKuQ84OJ00L+yY72d0exdE59sF562YPun+T0x63UwTmb4fPHw
Uj8lzHVi3enKG4MYgCy/N7MoSJs+M6/qOS1zQx8as66NRrrtMXHxfwJCQ81OF9Kz
RkYfuczdAvHaTyDjHp0CTaDjVkaw0mK3kp1SBW8dX6OVq2LIuHApb/J7R09CQWBm
KIehqF+3mbr+Y8dWeq1oO6ftHbFNnN3l4m1CQHlpDrKtPOUHkqSTeYr1yiX5llwr
k6SpIIFhxchZlJUG0d0rRSj8vd6A5jPIc60gE4TEF4alTpq1qLXSfkc7qfCpwPrf
MJ881SG0F6da4KQr5u3IZfCtvgyjVIyBk7p7sqsdH28e4rMNZJianiiwb0maiwCU
c6dey4mKzX5k
=bnjH
-END PGP SIGNATURE-

Accepted openmsx 0.15.0-2 (source amd64 all) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 20 Dec 2018 19:29:58 +0100
Source: openmsx
Binary: openmsx openmsx-data dmktools
Architecture: source amd64 all
Version: 0.15.0-2
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen 
Changed-By: Bas Wijnen 
Description:
 dmktools   - tools for manipulating floppy disk images in the dmk format
 openmsx- MSX emulator that aims for perfection
 openmsx-data - datafiles for openMSX, an MSX emulator
Changes:
 openmsx (0.15.0-2) unstable; urgency=medium
 .
   * Add svicpm2dmk to dmktools package.
Checksums-Sha1:
 122bf321603e998918d6a420cf1271cc7013fcd1 2084 openmsx_0.15.0-2.dsc
 4869ebb83b376144fcfe036e11c8f0c5213431d3 12004 openmsx_0.15.0-2.debian.tar.xz
 186e9a9fe82d32433addeae1b8ef9d3e27412b50 324156 
dmktools-dbgsym_0.15.0-2_amd64.deb
 bc805b43d4bd93f5abda38837c4114634f700ced 31204 dmktools_0.15.0-2_amd64.deb
 16a34558cc802d841a98362f2d09c8f87dfbed79 1323576 openmsx-data_0.15.0-2_all.deb
 f30f4b305b871937f174473fe24946d0087c47d3 61985592 
openmsx-dbgsym_0.15.0-2_amd64.deb
 c6f5510fbd7deabfe97eaeaa4ab59919443bac6c 12397 openmsx_0.15.0-2_amd64.buildinfo
 9af9e5f486401f228b07fdef3fb23200a4819217 1888592 openmsx_0.15.0-2_amd64.deb
Checksums-Sha256:
 997b3d44b495e8f60d870d0ab4f7c4c63e3a937dda3a05fc1e8898a71c12ecd7 2084 
openmsx_0.15.0-2.dsc
 d6fe992e8eeae1c25d0998f396a4657b58f28e6150f71a04fe115a143198026b 12004 
openmsx_0.15.0-2.debian.tar.xz
 84ce9f8f42054feb60935c428a8cc35d99a10ab264434edf60d35069ba291ea6 324156 
dmktools-dbgsym_0.15.0-2_amd64.deb
 26cdef2e4882f99d7bd36cc0a20665d506e595d58e76702eccacdc2bf3a8e685 31204 
dmktools_0.15.0-2_amd64.deb
 ac6818ba8a54d8164fd8f0df2dae3e5730b58b801a28b60c684c162f42d836c9 1323576 
openmsx-data_0.15.0-2_all.deb
 39209ecd0016cf17c21f5b9e614383ab10553cdfda1722a514585a0cd1f47dfb 61985592 
openmsx-dbgsym_0.15.0-2_amd64.deb
 895e9b49bab459fb217350140f04d027171f88aa54f603fa08146ffd03e7c176 12397 
openmsx_0.15.0-2_amd64.buildinfo
 fde2f9b6fd2a05987b66bd29aab01d3d24fd49b12a904d77c8b5160b2c5b28c6 1888592 
openmsx_0.15.0-2_amd64.deb
Files:
 1472dc4a7901580d6569df2d4e6561b4 2084 otherosfs optional openmsx_0.15.0-2.dsc
 3301d6ab208ea911ff3e528d96b35b79 12004 otherosfs optional 
openmsx_0.15.0-2.debian.tar.xz
 dd15fbe514b4b15883760022fed996a4 324156 debug optional 
dmktools-dbgsym_0.15.0-2_amd64.deb
 96c4088ec2ab194b7b77db6c7069b5b8 31204 otherosfs optional 
dmktools_0.15.0-2_amd64.deb
 80bb50815ccc2cbedc5f0fc6a7079518 1323576 otherosfs optional 
openmsx-data_0.15.0-2_all.deb
 fe8faf86980a074f9d1c83e1fae29c1c 61985592 debug optional 
openmsx-dbgsym_0.15.0-2_amd64.deb
 1a07c7c92485249e3996c5a60e384f72 12397 otherosfs optional 
openmsx_0.15.0-2_amd64.buildinfo
 65e26a48333f9e869ffb4670975d0a3b 1888592 otherosfs optional 
openmsx_0.15.0-2_amd64.deb

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEKI9JSvHOfJKJyDQanNF9WAfAcToFAlwb82ESHHdpam5lbkBk
ZWJpYW4ub3JnAAoJEJzRfVgHwHE6h5kP/0iPUnSRFwkw+To6KiigxjhgNW8Jyh8r
THRTW/PUMpvrL/FV6yYMpQlfyzetYmAJNQBp/ouuyKdoX9Mc9Cm9OYUI/jJoGOAI
kAI1g/wdxu7ehJRfGbMMVSQwLCZiVzvUoMr0rLMjWlWRD2E7EH9BpNTjQO0eC4jA
VpFPlqd6Kj1l+tV7gcaWZpBtf57yY+QW5vHG2uBflhpbnnH/2DpCqO4onZNSBb0Z
skhDTcK4VvffoHcVfk0hjz80x6+CScf1eHObdT7OykgdMqHZmt8faMXEfw1O0L5D
06l8/BgMjE0AjNVY3RE2ccr4N8HBqeDsr6deVFtpIww14MOmPuL/M8hiEjKIJ4YK
CoC+Lz9+71X78aFxEZZCQ017k87IewDai2nUKi7uSC0twBqtEbCm3JlWszalvg7w
HvSFnDe7+RH7vtMDwuC72lhJIS+qL+RFV/Ib5Ht+nWShFfrxPkRYf0ogv6wHCVvt
5fz0VIgkJL+AZhcG9HqACO2KgC62PhHECPQyOSld/la3P+TcaPHBIzKHgXnUcMpA
V1SMc1MGX9oDQmLWX0K2PQ4aUoBG3Ydwl5etkuN7b93qmBnLNhm/poVivsiQ61jq
ANOZJFvOTqBwGoCUkmSCUWZKpeSXDXJoSBRYCDzUUDE4XM6RuY95Stde1ZgpDDdC
jK7DBtVBlmAp
=3iPj
-END PGP SIGNATURE-

Accepted openmsx 0.15.0-1 (source amd64 all) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 20 Dec 2018 14:07:49 +0100
Source: openmsx
Binary: openmsx openmsx-data dmktools
Architecture: source amd64 all
Version: 0.15.0-1
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen 
Changed-By: Bas Wijnen 
Description:
 dmktools   - tools for manipulating floppy disk images in the dmk format
 openmsx- MSX emulator that aims for perfection
 openmsx-data - datafiles for openMSX, an MSX emulator
Closes: 915588
Changes:
 openmsx (0.15.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Add shlibs:Depends to dmktools control section.  Closes: #915588
Checksums-Sha1:
 2a1060cfa4f6c337df4a42a7fb40fcc79450f4a7 2084 openmsx_0.15.0-1.dsc
 fe7f48700fcbdef84d01bb48143bc9befe44ec11 5403503 openmsx_0.15.0.orig.tar.gz
 8867286035637ed03a6dcb1dfd1e2d27d679433a 11956 openmsx_0.15.0-1.debian.tar.xz
 72596922c0336728036d50ebec8c74a43d2f5ee0 279656 
dmktools-dbgsym_0.15.0-1_amd64.deb
 3b8441c346ad771cb868ceb4743c5786442d7e21 29960 dmktools_0.15.0-1_amd64.deb
 bd2b9e79c3853700be39d86f83871c7bef1805fd 1323400 openmsx-data_0.15.0-1_all.deb
 dedace4b1b51e5a0205dfeaeb7be5cf31e27ed22 61985588 
openmsx-dbgsym_0.15.0-1_amd64.deb
 b3afd9fe5c07a0f6bae46ad1fac030db583efcd0 12397 openmsx_0.15.0-1_amd64.buildinfo
 55d94a5a662789af6eda6e00f4c1e8138b51e710 1889904 openmsx_0.15.0-1_amd64.deb
Checksums-Sha256:
 546103cdaa1199bd434d90b8fafd4761c5a85eb7d58474f49f7ebf39e271814f 2084 
openmsx_0.15.0-1.dsc
 452b0189899abd99e921a084ce2800cdb678e09de7584ffabacab1576d66c911 5403503 
openmsx_0.15.0.orig.tar.gz
 712dc6fe522300caea20b90231aab68624bd3747758bba4cf289aa66c9172afb 11956 
openmsx_0.15.0-1.debian.tar.xz
 2c6760ea62c8edcd93f2c90fa4b188fc4d04bd294c6a0d2d5b6279fd0a53e3b7 279656 
dmktools-dbgsym_0.15.0-1_amd64.deb
 191ee2e5efa5e65b7f792b68ddcc84bbde8002f39dc5e78ab77ce2125643bbf7 29960 
dmktools_0.15.0-1_amd64.deb
 d57c432a0d7410065161b50a3ac7e513efb2781ed1f6323d0378047725b599d2 1323400 
openmsx-data_0.15.0-1_all.deb
 3e02fc9e4db450526564ccdd3e5968dbf6bb0497510004110bdb34f761d353fe 61985588 
openmsx-dbgsym_0.15.0-1_amd64.deb
 84bc30cf4e46a15d550ee9f00458b1e2f0a61b986073e02048921f4137bc7ccd 12397 
openmsx_0.15.0-1_amd64.buildinfo
 b0e7c557347415fa6c72069cf0f93066be65aa4279e30943ebcecf5d80197c39 1889904 
openmsx_0.15.0-1_amd64.deb
Files:
 774f5120a15c272a848d9d9a8d679899 2084 otherosfs optional openmsx_0.15.0-1.dsc
 e10d607addc200addce1249c682872a2 5403503 otherosfs optional 
openmsx_0.15.0.orig.tar.gz
 7a0e9d03f115d2616c4d8a16bb31e5c9 11956 otherosfs optional 
openmsx_0.15.0-1.debian.tar.xz
 d7281f781a3444fdfdb26135a1a65371 279656 debug optional 
dmktools-dbgsym_0.15.0-1_amd64.deb
 ad651f6998a0de6c3bad7585f780cbd6 29960 otherosfs optional 
dmktools_0.15.0-1_amd64.deb
 836c36347138c8017c44cd8202173072 1323400 otherosfs optional 
openmsx-data_0.15.0-1_all.deb
 deb978683f623cdb9c15e0f2c4e5e527 61985588 debug optional 
openmsx-dbgsym_0.15.0-1_amd64.deb
 da48c4fd4402a427342c8189bfd61206 12397 otherosfs optional 
openmsx_0.15.0-1_amd64.buildinfo
 dad2911a30111524089b64e5235d12ef 1889904 otherosfs optional 
openmsx_0.15.0-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEKI9JSvHOfJKJyDQanNF9WAfAcToFAlwbqWYSHHdpam5lbkBk
ZWJpYW4ub3JnAAoJEJzRfVgHwHE6TNIQAJwyIYQ8eiicr4qi2pRwUYsUYwXY7lr/
5LVrpKh6aM5RqeOkyxB1yqza9zaAAFAuEvdvVUruvYThsyde2czmUa3FStXecjI7
+Isa2i4+blIeUHKtkDVftwIMurJPvzb3BuLQ5aGMGcwWGokeXQywynaV5pOZbaJI
L1HuxlBN6APjOhKFy94T6ytl3PNjLUjJULpjjItM2ydOXoD1tQfJk0TlIsVrmWq4
sUSzoiHdWQZDwxcv9PqRgtCXUj9wsOnmOdQH7u77eWTFKPs3DvhvQTnqJT0CtVOO
uobyD2gDodjththf/lsGw1mR4auk87b7UN4mXfU5V5HAugV6/E8IYimX2NlN24Re
r0L8YCNpMW/Fg2inV8OXzqhvAQB82gGLJ6O5fSmKRUjjDcbFH3UhldnZHS+WMuIB
dwWakxC03Ty/CSKUFq0/Fv7Hc9K3Nax5AQ8I7sDzdalerlRUQf44JAvnouGogzzm
ta27/IzBO7z22ytfEYVjeE1sYbBJpZm3JnJD1g5Tk4isJiTusJuRuws8TEJDL227
+6XehlRiRdYFsCDJgJ6bOu0Isk0F4f5ecLfjm1co8poSCH/XleY9qZ8j9WmXDFwT
NKGl6wHMGk6Nq9k33xH9dXlh2iTW8WOG+3jup6IqVJpIknNDJHLtudWlENfVxJwD
zXojFwRGVBe1
=7Iyi
-END PGP SIGNATURE-

Accepted openmsx 0.14.0-2 (source amd64 all) into unstable, unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 04 Feb 2018 18:03:29 +0100
Source: openmsx
Binary: openmsx openmsx-data dmktools
Architecture: source amd64 all
Version: 0.14.0-2
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen <wij...@debian.org>
Changed-By: Bas Wijnen <wij...@debian.org>
Description:
 dmktools   - tools for manipulating floppy disk images in the dmk format
 openmsx- MSX emulator that aims for perfection
 openmsx-data - datafiles for openMSX, an MSX emulator
Closes: 889043
Changes:
 openmsx (0.14.0-2) unstable; urgency=medium
 .
   * Split dmk tools into their own binary package.
   * Fix typo in manpage.
   * Use latest tcl version.  Closes: #889043
   * Update standards version to 4.1.3.  (No changes needed.)
Checksums-Sha1:
 db6f025e1ea88ec93eb67675516ec0197216d670 2084 openmsx_0.14.0-2.dsc
 d9bc8522a96240c944d2c6f654fc6a3c999b 11844 openmsx_0.14.0-2.debian.tar.xz
 6c920a443a7524eba8982d8621a4141fb0ff611a 226108 
dmktools-dbgsym_0.14.0-2_amd64.deb
 ce64b37de20120d94c887267223415127b6e04e5 29204 dmktools_0.14.0-2_amd64.deb
 91479b1b9b312e32bf374a8e163820ec013bc3c6 1288860 openmsx-data_0.14.0-2_all.deb
 1e02c23f967a1f127d0b3bc2af311caa44afe291 49761496 
openmsx-dbgsym_0.14.0-2_amd64.deb
 f1e0f867862cba67230ae9b02c728bbca2b50ff5 11945 openmsx_0.14.0-2_amd64.buildinfo
 f4795b5e75ca90a8bc0d50728cee8937948f7d91 1899088 openmsx_0.14.0-2_amd64.deb
Checksums-Sha256:
 402c0244875cf3072ca9838e892e3bcacdf36ae274d2199570088cff16eb7782 2084 
openmsx_0.14.0-2.dsc
 2e0833a5b9938f7ba3c5c844b83ffa3c8e05aea858d39bfcfa7fc45f6cc4c4e9 11844 
openmsx_0.14.0-2.debian.tar.xz
 47d9f4b60e4a12eb505f68447bfa0a928463c4442552176ed34f8387148298d3 226108 
dmktools-dbgsym_0.14.0-2_amd64.deb
 e50aca391e320d63328ca3490674fdeb209bf3718e98389afd42f7d3215f669d 29204 
dmktools_0.14.0-2_amd64.deb
 cd87d1add178d0754cfb5acdced1973f1069f953d7b361e683edce750c150c01 1288860 
openmsx-data_0.14.0-2_all.deb
 fe9f3d536ef78309d11736d744d5391f33129e635d0668b582ea2d72e526cabe 49761496 
openmsx-dbgsym_0.14.0-2_amd64.deb
 66646c54dd90e275933f10c3aaca06348edcdbf0506cf3d0a8bf77709d7eef03 11945 
openmsx_0.14.0-2_amd64.buildinfo
 2a652de3d4d456014f6fb56bd5221cc1109fccff04403a4c0b86380b944299ef 1899088 
openmsx_0.14.0-2_amd64.deb
Files:
 524398828ef1fb09aeed47dcba568aec 2084 otherosfs optional openmsx_0.14.0-2.dsc
 8e0bd034d4ad8506aa4559aa322bc949 11844 otherosfs optional 
openmsx_0.14.0-2.debian.tar.xz
 5eb2cedfcfdbae126c002db4e28bb769 226108 debug optional 
dmktools-dbgsym_0.14.0-2_amd64.deb
 c8a0ba226f61f7e5eca08db78f2e240c 29204 otherosfs optional 
dmktools_0.14.0-2_amd64.deb
 c6977f5a6192f11a83c7d6e0f15f4ff1 1288860 otherosfs optional 
openmsx-data_0.14.0-2_all.deb
 e6aa83e5b244d7aff9ac03ef1ede6a00 49761496 debug optional 
openmsx-dbgsym_0.14.0-2_amd64.deb
 12b3ae70317f928cb4f61fb666bd7653 11945 otherosfs optional 
openmsx_0.14.0-2_amd64.buildinfo
 21baab79cf0fe8d314dd7ce179edb39b 1899088 otherosfs optional 
openmsx_0.14.0-2_amd64.deb

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEKI9JSvHOfJKJyDQanNF9WAfAcToFAlp3XccSHHdpam5lbkBk
ZWJpYW4ub3JnAAoJEJzRfVgHwHE6tZIP/3j4BbOsHf74W49K9ycThBCO0M05H8AG
xQixfAzc4rnkxPxXnPkZimRE/X0g01arR5h91ju2avkE0MkU/LLiAOIrSzF6Jw17
cssd9L1QXs7Q5J318yDKOZKFxSMu4RGEVtpWg2buGrnYfXeIJf7yZy/yWtUvX7EK
/yt5EOwFFc23wTT4aCJkDcrteBi15LkM6TXjO5zFlGrm/qZoO/422tA4ZLEZ4aJQ
kKEBflDqY2v6XeRotrDQ84E8Qu5lF9CFWle+eyiRTBidgIa76adCCdlwWui5byUt
YDWODA+pe1jg3lnY73j9p4IO6H+NmgcoPMFEfwc0OK+0vb7JRVD0zRH7LFa1gLYc
TBxA7rBmErqSHqFyA2/MV1fFjJcCy8LxCN9CJcKQr2Jy6/M3+leHpmKZy7rJkZUP
pbnouEXueRW6iuf/irYiMHOuTMUYQPwu3kOS7cJu/owcGeZhYZDlhgRb23ubRQ/t
9ddspDPH8/DIYsZAQ+51FNpWsclZbSRqEAN7S+vWfj/GrpszahNqoCBc/yHHTu/j
yDMG0Qub9InpEvFFB1ixe2nRoeMITtZtUKe2X2wANBN6/LfHLlBgQV6xAQAE84Gx
6B3gMouTbPCa037HzmuGDFrIObaz+qy9QAjnr2U/I462irHjX1EpRgTcDZpGs72f
inmYBHiiV0Er
=29O+
-END PGP SIGNATURE-

Re: Why do we list individual copyright holders?

[Dr. Bas Wijnen]

On Mon, Jan 01, 2018 at 07:43:06PM +0100, Vincent Bernat wrote:
>  ❦  1 janvier 2018 17:47 +0100, Jonas Smedegaard  :
> 
> >> I have very little time for Debian. Each time I update a package, I have
> >> to bump Standards-Version and fix new Lintian warnings. I would
> >> appreciate if we would assess the time developers will take to update
> >> packages because of a change.
> >
> > Only if you additionally have time to read the updated Debian Policy and 
> > ensure that the package complies with that newer version, should you 
> > bump Standards-Version.
> >
> > (possibly that's what you meant)
> 
> I read d-d-a@ where the policy changes are announced. Most of the time, I
> feel unconcerned as I don't remember anything particular.

If a policy change doesn't affect your package (which is most of the time),
there is no hurry to upload a new version.  Just bumping the standards version
isn't urgent.  In fact, I don't believe it's worth an upload at all.

> > Purpose of the Standards-Version field is *not* to keep you busy 
> > silencing corresponding lintian warning, but to state which version of 
> > Debian Policy the package is verified to comply with.
> 
> And why is it useful to know something like that?

A package may not have been updated for a while, because changes in policy
didn't affect it, but perhaps also because the maintainer was too busy.  Once
you find out that there is a reason for an update, you should check if it
follows the new version of policy.  You don't want to recheck all of policy, so
instead you would use the upgrading-checklist from the debian-policy package.
In order to use that, you need to read all changes between the version that it
complied with and the current version.  For that, you need to know what version
it complied with.  This is recorded in the Standards-Version field.

> If we don't comply with the latest policy, this is considered a serious bug.

Yes.  But a package complying with the previous policy, but not the current one
is unlikely, because policy changes are normally written down once most
packages in the archive have been following the rule.  Such changes are placed
in policy as a SHOULD initially, which is upgraded to a MUST (much) later.
There is usually a mass bug filing which informs you of the change and gives
you enough time to fix the issue.  And if you're lucky, an NMU is already
prepared to fix the issue for you.

In other words, the problem you describe ("my package followed policy, but with
the new version it suddenly doesn't anymore") is extremely rare.  Violating a
SHOULD in Policy is not a serious bug.

> We would spare a lot of developer time by not using this field anymore.

I am surprised by this statement; it makes me think you do not mean what I
understand from your email.  So I'll explain what the result of removing the
field would be, please let me know if I misunderstand you:

If you remove the field, every package must always conform to the newest
version, which means that whenever a change that affects a package happens, a
new upload must be made immediately.  This is exactly what you don't want, and
the Standards-Version field is what you need to prevent it.

What am I missing?

Thanks,
Bas


signature.asc
Description: PGP signature

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Dr. Bas Wijnen]

On Fri, Dec 29, 2017 at 10:43:58PM +0100, Alexander Wirt wrote:
> On Fri, 29 Dec 2017, Philipp Kern wrote:
> > Put a mapping into a git repository that DDs can push to? Make sure that
> > it is fast-forwarded always? Then let people deal with it?
> I am currently working on such a mapping. 

I appreciate your work, but this doesn't seem all that useful to me.  If DDs
can push the mapping, can't they just as well upload a new package with the
fields in the control file updated?

Thanks,
Bas


signature.asc
Description: PGP signature

Re: ISO download difficult (was: Debian Stretch new user report (vs Linux Mint))

[Dr. Bas Wijnen]

On Fri, Dec 29, 2017 at 07:18:57PM +0100, Adam Borowski wrote:
> On Fri, Dec 29, 2017 at 05:57:21PM +, Dr. Bas Wijnen wrote:
> > So we need to decide what we want.  I think there probably is consensus 
> > about:
> > 
> > - We want people with non-free hardware to install Debian if they want to.
> > - We want people with non-free firmware installed to get updates for it.
> > 
> > I'm not entirely sure, but think there is also consensus that:
> > 
> > - We want to recommend people to use as little non-free software as 
> > reasonably
> >   possible.
> > 
> > I am planning to propose a GR that will clarify our position about this, and
> > that should result in enabling contrib and non-free in the default installer
> > image until non-free-firmware is somehow selectable for installation without
> > also enabling other non-free software.
> 
> I got the impression that the idea of having two installers for download,
> side to side, received least hate of what was proposed.

It doesn't get hate from me, but I do think it's suboptimal.  As I explain
below, I think we should recommend the image including non-free firmware to
pretty much everyone.  This means that if we design the website properly, the
image without the firmware is very hard to find.

> Having no purely free installer, or having it play second fiddle to the
> non-free one, would sacrifice too much of our principles in my opinion.

Therefore it should indeed play second fiddle, if it should play at all.  If
the hardware supports firmware updates and those are available in non-free form
only, I think it would be irresponsible of us to withhold them from our users.
So that means that if such hardware is present, we need to enable updates for
non-free firmware.  With the current repository layout, that means enabling all
of non-free.

Especially for new users, having two options where one has limitations (using
it may leave you with an insecure system, depending on your hardware) and the
other one doesn't (they've always used non-free software, continuing to do so
doesn't feel like a problem for them) will lead to many of them choosing the
installer which includes the non-free firmware.  So I don't think it's really
possible to avoid the free installer being almost unused.

Personally I think it doesn't really add any value to have an installer without
the non-free firmware.  As long as the installer doesn't install it on the
system unless it is needed, that is.  The value of having an installer image
that doesn't include the firmware is much lower than the value of users being
able to install a good system.  This is similar to how RMS originally used
non-free Unix systems to work on GNU.  As long as the non-free parts are
required, they can (and should) be used.

I would very much like to not enable all of non-free, but the proper solution
for that is splitting off the firmware parts so they can be selectively enabled
(or some other way to selectively enable part of an apt source) and that
requires work.  I don't have the time to do this work, so while I mention that
it should be done, I'm not proposing that it will be done.  That's not the sort
of thing that a GR or mailing list discussion can do.

However, I believe that the problem of our users being unable to install secure
systems, or being unable to install at all, is serious and deserves to be
solved.  Even if that means enabling all of non-free for every new install.

> Yet having such a "tainted" installer to its right/bottom would also
> satisfy the need of users with bad hardware.

The main issue is that the free image somehow needs to detect that non-free
updates are required to keep the machine secure, and then (request to) enable
non-free if they are.  My guess is that this can easily be done.  Enabling the
non-free repository is technically easy, but I expect disagreement over whether
this should be allowed.

> Would this be acceptable to you without employing all the hassle of a GR?

The reason I think a GR is useful is that this discussion comes up again and
again.  I'd prefer if we had consensus about it, and this may be the case.
However, nobody seems to know, so a GR would clearly record our opinion.  That
seems to be a good thing.

Just to clarify: my purpose of a GR isn't to "win" anything.  It's to clarify
what the project wants, so that people can work on this without too many
protests, and installing Debian can be a better experience for our users.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: ISO download difficult (was: Debian Stretch new user report (vs Linux Mint))

[Dr. Bas Wijnen]

On Thu, Dec 28, 2017 at 10:13:52AM +0500, Andrey Rahmatullin wrote:
> On Wed, Dec 27, 2017 at 11:00:38PM +0100, Toni Mueller wrote:
> > they will most likely simply not understand the point, and what makes
> > free hardware so much better. 
> 
> > massively encourage users to use non-free hardware
> 
> > link to a page suggesting free hardware over similar non-free hardware
> 
> There is no such thing. There is only non-free hardware without updates
> for its software.

I'm not sure what you're trying to say.  Here are the facts:

- There are people who have non-free hardware that they would like to run
  Debian on.
- The current default installer image requires non-free firmware to install on
  those systems.
- The non-default images which include the firmware are hard to find.
- The method that the default image suggests (downloading the non-free firmware
  tarball and installing it in the installation system) is not something that
  all users should be expected to be able to do.

Toni's suggestion seems to be to tell those people that Debian can indeed
install on their hardware, while educating them about the problems of it.  The
result will be that more people run Debian, but as you seem to say the
education will not always work so it will also mean that either people are left
with hardware without updates, or they are pushed to using non-free software.
Neither of those options is nice.

So we need to decide what we want.  I think there probably is consensus about:

- We want people with non-free hardware to install Debian if they want to.
- We want people with non-free firmware installed to get updates for it.

I'm not entirely sure, but think there is also consensus that:

- We want to recommend people to use as little non-free software as reasonably
  possible.

I am planning to propose a GR that will clarify our position about this, and
that should result in enabling contrib and non-free in the default installer
image until non-free-firmware is somehow selectable for installation without
also enabling other non-free software.

Any comments are welcome.  I'll post to -vote when I have a proposed text.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

On Thu, Aug 31, 2017 at 11:16:36AM +0200, Ansgar Burchardt wrote:
> python-digitalocean, ruby-azure*, waagent, twittering-mode,
> probably HBCI clients, python3-googleapi,
> python3-pyicloud, python-yowsup, youtube-dl,
> libgfbgraph-0.2-dev

Thank you for this list.  I removed servers that cannot run on a general
purpose system, because for obvious reasons they cannot be included in main
even if they were free software.  For the others, so far there have been people
popping up with "a free server for this exists" for every example we came up
with, so I'll wait to see if that happens for those as well.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

On Mon, Aug 28, 2017 at 09:15:01AM -0400, The Wanderer wrote:
> On 2017-08-28 at 07:59, Dr. Bas Wijnen wrote:
> > I think if someone wants to write a client with the purpose of
> > interacting with a non-free service, that client should go in contrib
> > and there is nothing wrong with that.  I find the obsession that some
> > people seem to have with getting their software in main startling.
> > Why should software be in main if its purpose is to work with
> > non-free software?  That's exactly what we have contrib for.
> 
> One plausible rationale for this is accessibility to end users, and that
> goes back exactly to your other point about what repository
> configuration should be the default.

Agreed.  Now as far as I know, in Debian we try not to use dirty workarounds,
but fix bugs when we find them.  In this case, the bug is that many users need
software from contrib or non-free (especially now that we have properly put
lots of firmware in there), but it's rather hard to get to it.  Should
maintainers work around that problem by putting packages in main even if they
don't belong there?  Or should we fix the actual problem and make contrib and
non-free more easily accessible?

As long as almost essential firmware is in there, I think they should be
enabled by default.  And once that issue is fixed (by creating a separate
firmware section, for example), I think we should still make it easy to enable
them, both at install time (there should be a question about enabling them in
the installer; I thought there was, but it's been a while since I ran the
installer) and on an installed system (I know Ubuntu has a graphical tool that
allows enabling and disabling sections; doesn't that tool work for us?)

In short: the fact that quite a few maintainers are trying to push their
contrib packages into main should be fixed by making it easier for users to
install packages from contrib.  I am surprised that this is so controversial.

> There's also the fact that it's repeatedly stated that anything not in
> main is not part of Debian; it's easy to see why a maintainer would want
> to have a package in Debian, rather than having it be a second-class
> citizen.

But that's the way it should be.  Debian is a self-contained free software
operating system.  If you install things from main, it will not tell you that
you need stuff that isn't in main in order to use those things.  If you find a
problem with your software, you know that you can get the source code from our
repositories and fix the problem.

If a client requires communication to a non-packaged server, then the bug you
are seeing could be on that server and you cannot get the source for it from
Debian.  That is an experience we tell our users they will not have.

Again, it surprises me that the same people who don't seem to care all that
much about freedom and happily make their package depend on a non-free server,
have such strong opinions on which section of Debian their software should be
in.  The fact that contrib and non-free are not a part of Debian is because we
care about software freedom.  How can you say "this software really needs to be
in main, not contrib", but at the same time say "I'm indifferent to whether or
not the software depends on non-free stuff"?  That like saying "I don't care
what text editor you provide me with, but I hate you if it isn't gedit".  How
is it not obvious to everyone that this is a contradiction?  Obviously those
people care a lot about what section their software is placed in, but they
don't want to follow the rules that come with the section placement.

We should explain to those people that if they want to be part of the
self-contained free system that Debian is, they must follow the rules that we
made for it.  If they think those rules are stupid, then they should ignore the
sections and accept when we sort their package into contrib or non-free.

> Perhaps adding that 'firmware' repository and enabling both it and
> contrib by default, while keeping non-free disabled by default, would be
> the most optimal solution? Although that would seem to imply a change in
> what is considered "part of Debian", which might be controversial.

I think we should do that (and until there is a firmware repository, also
non-free) and I don't think it's a problem.  Having a link to a network service
in our system does not make the target of that link part of the system.
Everyone who claims that requiring a non-free and/or non-packaged server is
acceptable for a package in main should certainly agree with that.  Just having
contrib and/or non-free enabled doesn't mean we are requiring them, so that
isn't a problem either.  And if even people like me agree with that, I think it
is to be expected that there is consensus about it.

On Mon, Aug 28, 2017 at 10:18:02PM +0200, Tollef Fog Heen wrote:
> The value of an ICQ 

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

Thanks Philipp, unlike the mail I responded to a few minutes ago, yours is
constructive and I'm happy to continue discussing this with you.

On Mon, Aug 28, 2017 at 12:31:15PM +0200, Philipp Kern wrote:
> On 08/27/2017 12:20 PM, Dr. Bas Wijnen wrote:
> > On Sat, Aug 19, 2017 at 06:21:23PM +0200, Philipp Kern wrote:
> >> On 08/18/2017 10:36 AM, Dr. Bas Wijnen wrote:
> >>> Consider the following: unrar-nonfree contains some software which is 
> >>> non-free
> >>> and can therefore not be in main.  The reason we don't put it in main is 
> >>> that
> >>> we want users who care about freedom to not even see this software.  
> >>> Agreed?
> >>
> >> Ex falso quodlibet?
> >>
> >> Archive areas serve a purpose of grouping and indeed everything that is
> >> not main is not part of the distribution. But I don't think the purpose
> >> of the separate areas is to hide anything.
> > 
> > Let me put it differently then: for me, one of the major benefits of Debian
> > over (most of) our derivatives is that I can set the system up in a way that
> > allows me to live in a free software bubble.  Is there a non-free 
> > alternative
> > to my free program?  I don't care, and I'm happy that it doesn't show up in 
> > my
> > package list.  Is there a program that is only useful in conjunction with a
> > non-free program?  Same thing.
> > 
> > So I'm not talking about hiding in the sense of "let's make sure people will
> > not find this", but instead in the sense of "let's allow people to not be
> > bothered by those packages".
> 
> I don't think I'm sufficiently convinced of this singular use case. We
> provide one selection of what's free and it's very hard to generalize
> that over many - as opinionated - people. People apply different
> standards on what they consider acceptable. You might take the view that
> what's the status quo in main is acceptable to you and hence that's what
> you want to see. But as it stands, that's not the case.

Of course.  But the point of splitting the packages into those categories is to
allow users to handle them differently.  Keeping non-free related software off
your system is one way to handle them, and it is in fact what we recommend by
making that the default.  Obviously if users disagree with how we sort them
this has no value to them and they should enable everything so they can make
their own choices.  But for those that do agree, we should make it useful.  If
the only sensible way to write a sources.list file is by enabling contrib and
non-free, that should be the default.

I would prefer to solve this by making a "firmware" repository (or similar) so
we can enable that without throwing all the optional non-free stuff in with it.
But as long as that's not done, the situation of "you really need contrib and
non-free, but we disable them by default" seems unacceptable to me.

> The policy expresses that it's about package dependencies.

I disagree.  It gives those as examples, but it does not specify that it is
only about those.  Perhaps they meant it to be only this, but that's not what
is written.  And I think if they meant it that way, it's because they didn't
think about the cloud and they would have wanted it to include network
services.  So if you stick to the letter of the text, it says it shall not
require non-free software and doesn't make an exception for remote non-free
software.  And if you want to go with the spirit, I find it hard to believe
that they meant "unless it's running in the cloud".

> I understand that you - again - don't want to read the letter of the various
> policies, but the spirit. But it does allow client implementations of things
> that interact with non-free services and devices since the beginning, because
> that's what we had to do with to get a usable system.

Yes, and I agree it's good to be pragmatic about such things, which means that
sometimes we should allow them (although contrib is meant for that kind of
thing).

> As Andrey points out the way free software purists went was that a ROM
> with code is fine as long as you don't update that and as long as it's
> essentially initializing the hardware before the main OS starts. I -
> personally - view this as a silly stance, but then to everybody their
> own opinion as long as they don't force theirs over others without a
> vote/say in things.

Agreed.  My position is that we want everything to be free, including firmware
and hardware, but as long as the world around us isn't ready for that, we
shouldn't make our system unusable just to further that goal (also, I don't
think it really helps the goal if it means crippling our system so severely).

> >> I think such a

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

I'm getting tired of this.  You keep avoiding my questions and changing the
subject.  Unless you start answering my questions, I'm going to stop
responding.

On Mon, Aug 28, 2017 at 02:21:01PM +0500, Andrey Rahmatullin wrote:
> On Mon, Aug 28, 2017 at 08:55:43AM +, Dr. Bas Wijnen wrote:
> > > > Are you saying that a Debian system where only main is enabled is 
> > > > unsafe?
> > > [...]
> > > > If that is correct, it is a huge problem that that is the default setup
> > > > we ship, don't you think?
> > > It is, but solving it most likely means actually violating Debian
> > > principles,
> > 
> > You cannot be serious...  You believe that if our rules say we should harm 
> > our
> > users, the rules are more important than the users?  
> No, I believe our users are more important and so you shouldn't set
> arbitrary restrictions on main just so your apt search output could be
> untainted.

Don't change the subject.  You say that non-free is essential for our users to
be safe, but you find it acceptable that it is not enabled by default.  How is
that not hurting our users?

> > Also, I'm interested to hear which rule would be broken
> "Debian will remain 100% free", "non-free is not part of Debian" etc.

Your position is that it is acceptable for a program in main to require a
non-free service, as long as that non-free service doesn't run on the same
computer.  Why is that suddenly no longer true when the non-free service is
hosted on our own servers?  Or do you perhaps agree with me that a program
requiring a non-free service cannot be in main?

> > if we make it the default to provide our users with updates that they
> > need to be safe.
> But then you will be able to see and install non-free software, isn't that
> what you don't want to happen?

It's a sacrifice I'm willing to make for our users.  It would be better if the
essential parts would be in a separate repository so I could enable only those,
but as long as that isn't implemented, of course I think the safety of our
users is more important than the looks of my package list.

Finally, for the third time, please explain your position on my hypothetical
unrar-nonfree scenario.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

On Mon, Aug 28, 2017 at 12:29:07PM +0500, Andrey Rahmatullin wrote:
> On Mon, Aug 28, 2017 at 06:58:50AM +, Dr. Bas Wijnen wrote:
> > Are you saying that a Debian system where only main is enabled is unsafe?
> [...]
> > If that is correct, it is a huge problem that that is the default setup
> > we ship, don't you think?
> It is, but solving it most likely means actually violating Debian
> principles,

You cannot be serious...  You believe that if our rules say we should harm our
users, the rules are more important than the users?  Have you not read the
social contract?

Also, I'm interested to hear which rule would be broken if we make it the
default to provide our users with updates that they need to be safe.  If such a
rule exists, I believe it should be changed (because our users are our
priority, as per SC), but I'm not aware that we would break any of our rules.
Please clarify.

Also, as a reminder, I'm still waiting for anyone to answer the unrar-nonfree
question: if the non-free part is split off and placed in the cloud, would the
other part be allowed into main?  In other words, would this be a way for the
unrar-nonfree maintainer to get the package into Debian?  And if not, why not?

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

On Sun, Aug 27, 2017 at 04:00:54PM +0500, Andrey Rahmatullin wrote:
> On Sun, Aug 27, 2017 at 10:20:27AM +, Dr. Bas Wijnen wrote:
> > Let me put it differently then: for me, one of the major benefits of Debian
> > over (most of) our derivatives is that I can set the system up in a way that
> > allows me to live in a free software bubble.  
> So you don't update the non-free software in your CPU?

I suppose so.  Are you saying that a Debian system where only main is enabled
is unsafe?  If that is correct, it is a huge problem that that is the default
setup we ship, don't you think?

> > No free implementation: That's what this discussion is all about.  For all 
> > the
> > real examples that have been mentioned in this thread (amazon s3, icq), 
> > someone
> > has noted that there actually is a free implementation of the server 
> > software.
> Did anyone realy mention a free implementation of the ICQ server?

Yes, I believe so.  I don't care enough to look it up, as it isn't all that
relevant to the discussion.

> > Which as far as I understand means everybody agrees (I know I do) that that 
> > is
> > enough to allow the package in main.
> No, we happily had s3cmd in main even before someone found a free server
> implementation. 

I did not contradict that.  My statement is that if there is a free
implementation, it is certainly good enough.  The situation without a free
server is obviously not as clear.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

On Sat, Aug 19, 2017 at 06:21:23PM +0200, Philipp Kern wrote:
> On 08/18/2017 10:36 AM, Dr. Bas Wijnen wrote:
> > Consider the following: unrar-nonfree contains some software which is 
> > non-free
> > and can therefore not be in main.  The reason we don't put it in main is 
> > that
> > we want users who care about freedom to not even see this software.  Agreed?
> 
> Ex falso quodlibet?
> 
> Archive areas serve a purpose of grouping and indeed everything that is
> not main is not part of the distribution. But I don't think the purpose
> of the separate areas is to hide anything.

Let me put it differently then: for me, one of the major benefits of Debian
over (most of) our derivatives is that I can set the system up in a way that
allows me to live in a free software bubble.  Is there a non-free alternative
to my free program?  I don't care, and I'm happy that it doesn't show up in my
package list.  Is there a program that is only useful in conjunction with a
non-free program?  Same thing.

So I'm not talking about hiding in the sense of "let's make sure people will
not find this", but instead in the sense of "let's allow people to not be
bothered by those packages".

> > Now what would be the result of moving this non-free part to a network 
> > server?
> > In terms of freedom there are no benefits to this.  The user is still using 
> > the
> > non-free software, but now they can also be tracked by the server admin, and
> > they can't use a debugger to hack it, should they want to.  So it is 100% 
> > bad
> > for them.
> > 
> > However, according to your logic, because it is no longer running on your 
> > own
> > cpu, this change would allow unrar-nonfree to go into main.  You do agree 
> > that
> > this is not a sensible result of making software worse, right?
> 
> I think such a package would fail other sanity checks (the existence of
> a free implementation of the algorithm being one of them - there's no
> right to be included in the distribution).

I'm glad you agree that it fails sanity checks.  However, can you find a rule
that actually forbids it?  If a maintainer were to do this, how would you argue
that their package cannot go in main?

The two arguments you mention don't work:

No free implementation: That's what this discussion is all about.  For all the
real examples that have been mentioned in this thread (amazon s3, icq), someone
has noted that there actually is a free implementation of the server software.
Which as far as I understand means everybody agrees (I know I do) that that is
enough to allow the package in main.  The question is if a package can be in
main if it requires a non-free service.  Even if that requirement cannot be
written as a package dependency because it doesn't run on the same machine.
Because if it does, policy is very clear.  If it doesn't, it seems obvious to
me that the same principle still stands and it must not be in main, but
apparently others disagree.

No right to be included: we're assuming that a maintainer wants to include this
in Debian and they don't need a right, they can just do it if nobody stops
them.  So we still need a reason to stop them.

> In my view a more interesting thought example would be DRM: What about
> an DFSG-compliant module that communicates with a remote license server
> returning encryption keys. There's not an inherent need for a DRM module
> to be Closed Source, given that the Linux platform does not offer any
> security guarantees against Reverse Engineering and leaking the key
> material anyway.
> 
> Would that be acceptable for main?

You seem to think that I want to kick everything out of main that is capable of
interacting with non-free software?  If so, you are mistaken.  I want to kick
things out of main if the _only_ way to use (major parts of) it is by
interacting with non-free software (and I don't care on what machine that is
running).

> Would the existence of a free server implementation change the opinion, even
> though it likely would not help the media files you intend to view?

Yes, of course.  That would mean that it is possible to make use of the
software without interacting with non-free software.  Again, my goal here is
not to stop people from using non-free software; it is to make sure people who
don't want to use it will not have to decide that they don't want to use this
package.  They made that decision when leaving contrib out of their
sources.list and Debian should respect that choice.

> At the same time: As long as programs are talking to an API - even if
> RE'ed - and doing so lets users accomplish their tasks at hand and the
> programs in question are completely DFSG-compliant, I think we should
> carry them in main if they provide a benefit.

How is that not true for my unrar-nonfree

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

On Tue, Aug 15, 2017 at 08:46:43AM +1000, Ben Finney wrote:
> The language is clear that it is talking about dependency in the sense
> of requiring the program installed on the system in order for the
> program to build or execute.

I think the mention of package dependencies is an incomplete list of examples.
But even if it was meant to be complete, thinking for a moment about the
purpose of Debian should make clear that your interpretation cannot be correct:

The reason we have the rules is because we care about freedom.  That doesn't
suddenly end when a program runs on a different server.

Consider the following: unrar-nonfree contains some software which is non-free
and can therefore not be in main.  The reason we don't put it in main is that
we want users who care about freedom to not even see this software.  Agreed?

Now what would be the result of moving this non-free part to a network server?
In terms of freedom there are no benefits to this.  The user is still using the
non-free software, but now they can also be tracked by the server admin, and
they can't use a debugger to hack it, should they want to.  So it is 100% bad
for them.

However, according to your logic, because it is no longer running on your own
cpu, this change would allow unrar-nonfree to go into main.  You do agree that
this is not a sensible result of making software worse, right?

> > I think they are equivalent; server software is still software and I
> > don't see why it running remotely suddenly makes it acceptable to
> > depend on it.
> 
> You appear to be using “depend” here to mean “without this the program
> *is not useful*”.

Most programs in contrib can build and run without non-free software.  They
will just immediately produce an error message.  Our users would describe that
as depending on the non-free software.

> The language in Policy §2.2 does not relate to any program's purpose at
> all.

What do you think the purpose of policy is, if not to ensure that our software
gives freedom to our users?

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

On Mon, Aug 14, 2017 at 08:58:00AM +1000, Ben Finney wrote:
> "Dr. Bas Wijnen" <wij...@debian.org> writes:
> 
> > What seems to be the dispute is whether software that runs on a remote
> > system is still "software" for the purpose of our rules.
> 
> That is not in dispute, it seems to me. The rules of the Debian Project
> can only bind what the Debian Project does.

Yes, I agree of course.

> The Debian Project could moot rules about what the project will do with
> regard to software that runs on a remote system. While there are trends,
> I don't think such rules exist yet, or if they do you haven't shown us
> what rules you're referring to.

I'm referring to policy 2.2, which lists what software belongs in main and what
belongs in contrib.  While this is not voted on and it does not follow directly
from the SC, I thought there was agreement that what's in Policy 2.2 is a good
way to determine where software should go.  In particular, if it is free, but
requires software outside of main to do its job, then it should go in contrib.

People are arguing here that "It requires a network server that is not in main"
is fundamentally different from "it requires local software that is not in
main".  I think they are equivalent; server software is still software and I
don't see why it running remotely suddenly makes it acceptable to depend on it.

> I hope we can agree that the Social Contract's rules about software in
> Debian do not have any power to restrict software running on remote
> systems (unless they also get their software from Debian).

Yes, this is about whether our packages should be in main or contrib.  External
software may influence that, but the result is a rule about our package, not
about the external software.

> > I think [software that runs on a remote system] is [software for the
> > purpose of the Debian Project's rules], especially considering the
> > trend that almost everything is being moved into the cloud.
> 
> Which of the Debian Project's rules are you referring to there? Can you
> show from where in those rules you draw this interpretation?

Policy 2.2.  So again, I'm not saying the rules apply to the external software,
I'm just saying that the external software is indeed software and therefore
depending on it requires a package to be moved to contrib if the external
software is not packaged in Debian (main).

> > I believe Debian's philosophy should be that software running remotely
> > on behalf of the user should be considered part of the system
> 
> By that philosophy, if person Foo connects to a system I am operating on
> the internet, the rules person Foo has chosen to accept are also binding
> on me? Even if I do not accept those rules?

Sorry, that is not what I meant.  What I mean with "part of the system" is that
it should be taken into account when deciding what to do with our software.  So
if Foo has chosen to always wear a hat while running /bin/bash, and that is
their shell on your system, then they must not only wear a hat when running
bash locally, but also when they log in at your system.

You don't need to do anything, and you are obviously not bound by their rules.
But your system does mean that they need to do something (if they want to
follow their own rules).

Similarly, if a client program's purpose is to connect to a server that is not
in main, the server operator doesn't need to do anything, but the fact that it
is not in main means (IMO, but apparently that is disputed) that the client
must be in contrib.

> > It seems clear to me that a program which is intended to interact with
> > server software does indeed require that server software to function.
> > So if there is no free implementation of the server, then the client
> > cannot be in main.
> 
> Maybe so, but that appears to be a different position: that the Debian
> Project's rules apply to software in Debian which interacts with remote
> systems.
> 
> That's very different from stating that the remote system's software is
> also part of Debian and therefore subject to the Debian Project's rules.
> 
> Please help by clarifying which of those positions you hold.

Yes, that was unclear.  I meant "part of the system" in the way that you need
to consider all forces in a system if you want to find the acceleration on an
object.  It was not my intention to imply that we have any say over the
external software.

Thanks for your questions, I hope my answers make my position more clear.

Thanks,
Bas


signature.asc
Description: PGP signature

Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

Note: this post is not about certspotter at all, so I'm not Cc'ing the bug and
changed the Subject line.

On Wed, Aug 09, 2017 at 05:30:19PM -0400, Jonas Smedegaard wrote:
> Stuff like s3cmd are tools connecting to cloud services.  Arguably 
> usable to have tools to free data from the clouds.

Which would be a great example of software that is free interacting with
software that is non-free.  Thus the package with this as its main purpose
should live in contrib.  There's nothing wrong with that.

(Note: I'm not saying s3cmd must be in contrib.  It can work with free servers,
so it can be in main.)

On Thu, Aug 10, 2017 at 12:45:39PM +0200, Philipp Kern wrote:
> On 09.08.2017 23:30, Jonas Smedegaard wrote:
> > ...but bug#856139 is, I believe, about a tool advertising a cloud 
> > service which is *not* used by the tool.  Instead that cloud service is 
> > advertised as an option *instead* of installing and using the Free tool.
> > 
> > Anyone having opinions more narrowly on that kind of advertisements?
> 
> And then you go to the bug and you see that it degenerated into a "if it
> uses a non-free service, it should go into contrib" subdiscussion. Since
> when do we believe that? Neither the DFSG nor the Social Contract would
> imply that you need to have a free server for an API client
> implementation. Now, I understand that this would be desirable and we
> should encourage it but we shouldn't just move goal posts willy-nilly.

What seems to be the dispute is whether software that runs on a remote system
is still "software" for the purpose of our rules.  I think it is, especially
considering the trend that almost everything is being moved into the cloud.  If
this continues, the only thing people will still run locally is their web
browser.  I believe Debian's philosophy should be that software running
remotely on behalf of the user should be considered part of the system and thus
free programs interacting with such software should be in contrib if the remote
software is non-free (and there is no free alternative).

> The only crucial sentence might be this one from §2.2.2 in the policy:
> 
> "The contrib archive area contains supplemental packages intended to
> work with the Debian distribution, but which require software outside of
> the distribution to either build or function."

It seems clear to me that a program which is intended to interact with server
software does indeed require that server software to function.  So if there is
no free implementation of the server, then the client cannot be in main.

> The policy isn't something we voted upon.

We codify existing practice in our policy.  If you think it was a mistake to
put this in there, and it needs to be changed, please explain what you believe
it should say instead.  I don't think this part of policy is controversial at
all.

> Do people really understand that this means tools calling an API on the
> Internet would need to be in contrib?

Let's frame that differently: From the point of view of a user who does not
want to deal with non-free software, what is the best solution?  That user will
not have contrib in their sources.list.  So should they see an ICQ client?  I
don't think they should.  You can say that it limits them to not be able to use
ICQ, and surely they care more about that than about not dealing with non-free
software?  No, they don't.  They specifically asked not to see software that
will take them to non-free software, so we should respect their decision and
not sneak clients to non-free servers (without free alternatives) into main.
Of course there are users who care more about not losing functionality, but
those are not the users this is about.  Those users have contrib and non-free
enabled in their sources.list, and thus they will find this software in
contrib.

> I don't think I agree with this non-free'ization of Debian.
> Stuff like licq never belonged into contrib either, despite its main
> purpose back then being to connect to the ICQ (and MSN?) services.

If you agree that the main purpose of the program is to interact with non-free
software, do you not agree that it requires software outside of main to
function?  If you do, please propose new wording for policy.  Do you want to
make an exception for services on the network?  I don't think such an exception
would serve our users.  Those who ask not to see non-free related software
should not see clients to non-free services.  Does that not make sense to you?

> Someone wrote a Free client implementation, hence we should offer it to
> our users.

Yes, we should.  You imply that software in contrib isn't really free.  It is!
The only difference with software from main is that it cannot properly function
in a world where only Debian main is available.  If a maintainer or upstream
cares about that, they should fix the dependency (by convincing the server
upstream to release their code, or by writing a free alternative).  And if they
don't care about it, they should not 

Accepted openmsx-catapult 0.14.0-1 (source amd64) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 10 Aug 2017 13:09:26 +0200
Source: openmsx-catapult
Binary: openmsx-catapult
Architecture: source amd64
Version: 0.14.0-1
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen <wij...@debian.org>
Changed-By: Bas Wijnen <wij...@debian.org>
Description:
 openmsx-catapult - GUI for openMSX
Changes:
 openmsx-catapult (0.14.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Upgrade standards version to 4.0.0.
   * Upgrade debhelper compatibility level to 10.
Checksums-Sha1:
 3f1ebff661fb46360586343412de4d0120e32d1c 1854 openmsx-catapult_0.14.0-1.dsc
 8a5f0ed3267c22c44e05bb4ac4b28ef8b05a49de 1476407 
openmsx-catapult_0.14.0.orig.tar.gz
 322df60f9db62f96e94eba98cc3359097afddbee 7304 
openmsx-catapult_0.14.0-1.debian.tar.xz
 47ca64c698b97a4a95bd8f050d4fca0f0b817229 10057 
openmsx-catapult_0.14.0-1_amd64.buildinfo
 7117ef7330429077668a32d4e2aa4c9f75e2ed31 381242 
openmsx-catapult_0.14.0-1_amd64.deb
Checksums-Sha256:
 ff43cc9cdd7f1d6d9ec47d3f41efb1732c2aec35c8b751d093d40d70a8889349 1854 
openmsx-catapult_0.14.0-1.dsc
 8a123b2f457920be4974f4d49a55b907c292a445200013f038c1e0d17229477c 1476407 
openmsx-catapult_0.14.0.orig.tar.gz
 d588c6652d111480a159df823c3ba0e6caf9e632acf0d42ff31786ef8b163b96 7304 
openmsx-catapult_0.14.0-1.debian.tar.xz
 8bed559db49e3f160ed8e26714405dd533c9e9b7154feeda23a3edad3774c908 10057 
openmsx-catapult_0.14.0-1_amd64.buildinfo
 538e445eed16592ce6524380f1a8ba5087be212e97ea1ab767ff00afd0b26943 381242 
openmsx-catapult_0.14.0-1_amd64.deb
Files:
 56616b9b745d951d34830018eb0ba3fe 1854 otherosfs optional 
openmsx-catapult_0.14.0-1.dsc
 2a9c00a344eb62fbe05bd7149368268c 1476407 otherosfs optional 
openmsx-catapult_0.14.0.orig.tar.gz
 0958524325aa1c5f6c4c32470ba9f5f9 7304 otherosfs optional 
openmsx-catapult_0.14.0-1.debian.tar.xz
 1e007c8ec168520a42f42b665096b4bb 10057 otherosfs optional 
openmsx-catapult_0.14.0-1_amd64.buildinfo
 45b292d212dfe569e1d03a62828efdbc 381242 otherosfs optional 
openmsx-catapult_0.14.0-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEKI9JSvHOfJKJyDQanNF9WAfAcToFAlmMRI4SHHdpam5lbkBk
ZWJpYW4ub3JnAAoJEJzRfVgHwHE6HEgQAJEa8YdXoe8mUUliSRLRDBYMtRm3NX+f
A53+F6ZRs2gxAxPQmBmCOWV/j/IyZPaojRtGIxJG9AxfYfX66FfnYGMm8oqizEKf
SYsHbXoYqMKbCUSJS3Tv5Gg7YmHj3hWfFb974DLBZTP39pJu9SuiBSeSMWHBnrGD
9XO8/EdrIJchrV7m55J9Dhe7DgkaQ8aQjqHtsokrHSRkJaARZelTrZzDvjw9blaX
BbTSoJFlQhs9h+P0Nds0weDMcVB+qWZOaeCMO+2vWLzDurc02P4lqaofkvVgqyBl
jsxCq+n49Q9Hh0xR8D5+A1r+blQys0r0TsozuSAuQhpxA6afbAHbLUt7QMLcVMeo
Q14jIHCQ7OMce0x3ebfbZDkxeFA4t5KJYVtdgQS0qX+yUIMvez4GJB9WlDn/gVuD
VOzhLP/gKNIgpsaENKfOnrkT51bJAw6YjsuKGEJihLaMsnIEesk6WoGYzB3VqzKr
BmBIMPRY63AMUSaNiJ6uSDPSOEu5UuI1bbUVPb5ztcGnnOeIqh15sUp4zNPVeEuz
4C2IOBmL8k+sftpLabl8qcauQf+SQjRMuJxrkj2bvHR2ESENem+8TPXUF6txQAm2
PhcT6oTyOBy62hjkVFfY+f5oQYtnRENXLSPyi/yCmKE0WCbirY5fcSu4ke4Zctkk
9nmxZSQhbjSy
=ljpJ
-END PGP SIGNATURE-

Accepted openmsx 0.14.0-1 (source all i386) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 06 Aug 2017 14:57:22 +0200
Source: openmsx
Binary: openmsx openmsx-data
Architecture: source all i386
Version: 0.14.0-1
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen <wij...@debian.org>
Changed-By: Bas Wijnen <wij...@debian.org>
Description:
 openmsx- MSX emulator that aims for perfection
 openmsx-data - datafiles for openMSX, an MSX emulator
Changes:
 openmsx (0.14.0-1) unstable; urgency=medium
 .
   * New upstream release
   * Change debhelper compat level to 10.
   * Update standards version to 4.0.0.  (No changes needed.)
   * Include dmk tools.
   * Add manpage for dmk tools.
Checksums-Sha1:
 8c0f63463f659f6310bc98769eb8a1b0099a1dca 2034 openmsx_0.14.0-1.dsc
 ba8944e6e703ea35123d229ddb0998304dc452c6 4995193 openmsx_0.14.0.orig.tar.gz
 694601ab0b6ca0f220bc1a9599700cc3e139a52f 11580 openmsx_0.14.0-1.debian.tar.xz
 b06660866f4fe4de66ceeef527f999d617753c7d 1290584 openmsx-data_0.14.0-1_all.deb
 54fb09f9df2d269e97e99ddc88e9a1855f0ce66a 48628734 
openmsx-dbgsym_0.14.0-1_i386.deb
 d43da6ed6bee0c6eaa28b5952d972e9041f46869 11120 openmsx_0.14.0-1_i386.buildinfo
 71ea49580ee919cac981f31ed3b974054d3ddfb4 1993792 openmsx_0.14.0-1_i386.deb
Checksums-Sha256:
 36ba4a44287f8e5f103c7d412b5ce6a8d7b6cf9e448c069cda09e98bcaf80edc 2034 
openmsx_0.14.0-1.dsc
 05917182bfbc249fec24120c7f2c1935627668770aca28ed5c6daec669713610 4995193 
openmsx_0.14.0.orig.tar.gz
 d5509f7f07c6c54d28c0771bcf9b6a9734cef848e89c46e27d1745e30c73a113 11580 
openmsx_0.14.0-1.debian.tar.xz
 4b4b1229655ed33f5c876e0f995ee32c71e90de3ccc9d6a9c8782fd07b2cc986 1290584 
openmsx-data_0.14.0-1_all.deb
 0244c7af2f30153a67537b3cf50117ea8a1bbc105015b670748c8f8e7fbbb656 48628734 
openmsx-dbgsym_0.14.0-1_i386.deb
 f3ed3882dd30f8ca9e6ffe63fe7568b9c7d566d2cf653a9e61662e61e7f49555 11120 
openmsx_0.14.0-1_i386.buildinfo
 b4bcdab7555379033e7da7763275efcb01570480b5747705a83a9ee38a507c89 1993792 
openmsx_0.14.0-1_i386.deb
Files:
 6b128b0306f8c821633dbba30d2c579e 2034 otherosfs optional openmsx_0.14.0-1.dsc
 2c9779d2c1e9c21132e1c2bae7e81ee9 4995193 otherosfs optional 
openmsx_0.14.0.orig.tar.gz
 0a9dbdfbdadb2ae7bfe463f058e26e24 11580 otherosfs optional 
openmsx_0.14.0-1.debian.tar.xz
 4804e219ac42bf75eb6d7465a33775ae 1290584 otherosfs optional 
openmsx-data_0.14.0-1_all.deb
 62a0003b6768fefcc670627ea836aecd 48628734 debug extra 
openmsx-dbgsym_0.14.0-1_i386.deb
 50e91fcf59022fb44507fdb66fa26b61 11120 otherosfs optional 
openmsx_0.14.0-1_i386.buildinfo
 2202e227d3eaafd48688941bff69f512 1993792 otherosfs optional 
openmsx_0.14.0-1_i386.deb

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEKI9JSvHOfJKJyDQanNF9WAfAcToFAlmLTxcSHHdpam5lbkBk
ZWJpYW4ub3JnAAoJEJzRfVgHwHE6xb0P/0H3vy7Ek4ms1XPANqJOsPVGiCxNfsGx
WwSZx+XrIk/4EPRbHY57Ns7e1vHEna8HCC33mWnCafYIg6fF8OsCPaloGXVHIZfO
i5LdU8PwUNzJhZ0eaVzkEroseINGTSvhhmzXJuPb5NerD5nbHmbPx2ZTma0X5uBQ
tZ7hwV4tOvhY28Jd4l9LkGHGrtVl25845SshT7W8YyajDB8vAd/yNsTgk4cprnvw
j+2iHYlNbjkwCWXRfPc7gILOeL/WoYnYGHH95AAW71n6O/UZPXAhs/tv/7+YQiKG
P+Ne9PHd+6WoMgDNctfb5iiVEvrTuH8NNse29QgvyM1Z+qhUnKI/ngtO7rLodaW+
EtXhwd+CQ7EJB7+flPFMsDNSO6TbKLZSPqDPvvjwzLArPzJDISc+6TdD6v6FBj9q
7lJDXm8cGLXDbUAEc0cymou/HMaQpMx/g/KGui0WwxkZgShIdXMqY60LL4ApZbhI
ZjwhdUry2AJog1xHrviZgahKQ5IJU+yC5NcM6QHVE4aVTy5CW0gbqCAB067CpRp4
mFy/gYsosgEoHsQHFs874QBmH1Vl8gdixfu/wDQKDIPmllJ0teWxPqr2ap2vsFSV
oCk6VhvZC89Dio7JH0L7bI7+CbXrQXPuDDybIQIeuFePm05idT8bUpyl89DXYHP6
16krKXqC+tqv
=Z2rt
-END PGP SIGNATURE-

Accepted openmsx-debugger 0.1~git20170806-1 (source i386) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 06 Aug 2017 07:33:40 +0200
Source: openmsx-debugger
Binary: openmsx-debugger
Architecture: source i386
Version: 0.1~git20170806-1
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen <wij...@debian.org>
Changed-By: Bas Wijnen <wij...@debian.org>
Description:
 openmsx-debugger - Graphical debugger for openMSX
Changes:
 openmsx-debugger (0.1~git20170806-1) unstable; urgency=medium
 .
   * New snapshot.
   * Increase debhelper compat level to 10.
   * Add get-orig-source target.
   * Upgrade standards version to 4.0.0.
   * Convert menu entry to desktop entry.
Checksums-Sha1:
 5e86979dc37a565bff690f74d92e6de23f4f2285 1881 
openmsx-debugger_0.1~git20170806-1.dsc
 a76f6633e4d633af4a22aa4edf734d5ed60307ee 399821 
openmsx-debugger_0.1~git20170806.orig.tar.gz
 6d862873612947085f5dcca3a79175f4b1e62bdb 5140 
openmsx-debugger_0.1~git20170806-1.debian.tar.xz
 e3ca351b291fa76e621ff9ca418cb2e9f13d7ae7 6817354 
openmsx-debugger-dbgsym_0.1~git20170806-1_i386.deb
 4a4657df874dfb70066db5372376a5b83f094046 10648 
openmsx-debugger_0.1~git20170806-1_i386.buildinfo
 f9adcbe60b66336d1afbb4ad81dac307be700fda 336912 
openmsx-debugger_0.1~git20170806-1_i386.deb
Checksums-Sha256:
 297552359a9bf154f31aeedee79a7e5c6de3f85dec250aa1906182ef3db5ef3f 1881 
openmsx-debugger_0.1~git20170806-1.dsc
 50b0729ee115d3b5fa908b5636460b12649f6dfefcde8c41629ee2b4a91c9c94 399821 
openmsx-debugger_0.1~git20170806.orig.tar.gz
 c89df607e0cf1005f3e2fa98964b0bb84eefb5392bfd609ee2925a5cea449299 5140 
openmsx-debugger_0.1~git20170806-1.debian.tar.xz
 f1bf699f3e8284e13c009d5f117d0710c31c25caffb6b6d0f94525249a5a 6817354 
openmsx-debugger-dbgsym_0.1~git20170806-1_i386.deb
 586f4d9b6cd24f49d661806906d27c581da21f13d3bdf1223adc96c308a09222 10648 
openmsx-debugger_0.1~git20170806-1_i386.buildinfo
 9fa8b3db05fae815a521652146410b3a081c9da5ae5dd70e8805560ac4526500 336912 
openmsx-debugger_0.1~git20170806-1_i386.deb
Files:
 b3a78da69c0d27744a8dc267d88b2dcf 1881 otherosfs optional 
openmsx-debugger_0.1~git20170806-1.dsc
 cf1e474102e8fb01f6b76530084b132b 399821 otherosfs optional 
openmsx-debugger_0.1~git20170806.orig.tar.gz
 12c9b34a14f369cac55d43bdf20b734b 5140 otherosfs optional 
openmsx-debugger_0.1~git20170806-1.debian.tar.xz
 1befd1b08251f2d911305cd33497bb59 6817354 debug extra 
openmsx-debugger-dbgsym_0.1~git20170806-1_i386.deb
 63d98c03b626d46a61929e9932170d13 10648 otherosfs optional 
openmsx-debugger_0.1~git20170806-1_i386.buildinfo
 4fe80cda0686a9082f93abaa999661e0 336912 otherosfs optional 
openmsx-debugger_0.1~git20170806-1_i386.deb

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEKI9JSvHOfJKJyDQanNF9WAfAcToFAlmJa6MSHHdpam5lbkBk
ZWJpYW4ub3JnAAoJEJzRfVgHwHE6VnwP/RQ4jZ/9RnEhcsJkO6X2kXRNOYPm6ejG
pvZ7d3JCxL9w//JN+HBvLrwMYLw1zMJJRxVRNnt+GmYcztdmQyEEa970n/9BbSsP
fasr2y26R59qR9rZbbqTROwmQpEOgK+ZLlmqK1o57ZTp3lWqREcvqF2CwP3PChD4
lStSbzq6/5tKYe/mctyy6EK0sYVvgyO81Irhut4Q0y+IT9SzSoAZDH+PFbNFmMGb
9AOHDekFYvrcviWYLeRrtgUpCJIMdP/kM+e24D5D7kg2UqoYeB/A2gOeDtNn5l/H
0dSyPbyZaEeZTf0rwhWIyaMoCjRuGjXo+cPMPwoLjJPdiBaIX355OACLkQbjtkm0
Jwf3bqap7jPJXw60wTMbC+/x1LSE9RgkkUS4ar2cOqb0gdiF94FiZb3sWacpnei8
6rC2LzKgAh+gmiplL4z2zYawOTtLNucJpzusthFAnRRlXUoU24FkJTZlUaVss+cl
84YrudO58amuN1JKeAXDlf/VXYTd4cHoQ6/rHlXYWWGuISyyr5a9WEmLiljDLCUA
6C11tH3OKeui9ejp9BbnKQAqOH5BKn4oq1CGo1qbzEwV2juNrhAvme7APqRCrzSy
qHJbRPoVttJWKpIBHUc/zi2Ot06Bs24DHhV5rZIaR2nFETRI66fBWXw7Ve9PxXWO
Ym+ncPo9/gES
=mRhf
-END PGP SIGNATURE-

Accepted cbios 0.28-1 (source all) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 05 Aug 2017 14:35:56 +0200
Source: cbios
Binary: cbios
Architecture: source all
Version: 0.28-1
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen <wij...@debian.org>
Changed-By: Bas Wijnen <wij...@debian.org>
Description:
 cbios  - open source MSX BIOS roms
Changes:
 cbios (0.28-1) unstable; urgency=medium
 .
   * New upstream version.
   * Update standards version to 4.0.0.
   * Change copyright link to https.
   * Change priority to optional.
Checksums-Sha1:
 1d4ebdab94eebbfc7aec7aa16a6078bd84d2cbe0 1715 cbios_0.28-1.dsc
 530b149fcc57c2b65fb5f43a136504214d71a426 196977 cbios_0.28.orig.tar.gz
 0627c188802d519f25d1c91dfbdfbbc22d300a85 4992 cbios_0.28-1.debian.tar.xz
 f66c804f1bcfd06c37b77c3be291d5358e1201cc 29926 cbios_0.28-1_all.deb
 6b499b6da7759202d98ce9dbe718ea59d423c40d 5766 cbios_0.28-1_i386.buildinfo
Checksums-Sha256:
 bb8cb8c454d0ecb34bcf8af5ed7ff32695617787bf66fc67161a6443118f099d 1715 
cbios_0.28-1.dsc
 1da907edc77002bc56995db9bef6b46972bd3873d602897f1ad4356ef80101b4 196977 
cbios_0.28.orig.tar.gz
 2ec9ee4cb0426c5c3c9c19efdd211793c8b9973ba6b1fcb878dc8c9c556f2c9a 4992 
cbios_0.28-1.debian.tar.xz
 4847ad1ffec902b708ce639e67f6806a090504651415185b2a10cc98a62a0cbe 29926 
cbios_0.28-1_all.deb
 b31f86523c427400f92c9994275aaa173b34c9c9d0ec21537e6465e5e78e52c1 5766 
cbios_0.28-1_i386.buildinfo
Files:
 bfae9a81729a1a542f4190057a603530 1715 misc optional cbios_0.28-1.dsc
 0bab719cac3669774bc0a7062d880b95 196977 misc optional cbios_0.28.orig.tar.gz
 4b3af17eb22f0acacbe6825c7fcbcd45 4992 misc optional cbios_0.28-1.debian.tar.xz
 76fc79b7087dca5f59afdb6286325b1b 29926 misc optional cbios_0.28-1_all.deb
 70eadf42b6524db4fad27b9f19bdd5ae 5766 misc optional cbios_0.28-1_i386.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEKI9JSvHOfJKJyDQanNF9WAfAcToFAlmJa2ISHHdpam5lbkBk
ZWJpYW4ub3JnAAoJEJzRfVgHwHE6L+cP/jboN7/YUfUL0hJjkce8z92aEVoUWad6
6Nes4Qusda08VCkSD8JBSvarlUrMQO9etsJk9pudfvhqkro5DM08nDvq66qox9OX
FpEyyXCNL8LirUoKgmVhc/ixNnkq7he+jdK/xB8HqLZm1BD4+DCpxj+YyCnz0vaR
5skllMALzDTluoVCvDnC2ugzOe++fOPpWy9wfnVE2wbQis5LjX0USZBzifTwkfbw
lsRkbwP2SVIvYeO2yIBjzdxmd0gZcjPNasTRdG6IwnxWM5RCNA9W1qhSHhNuPjMo
kUc5f+EbG4apt6DNsEp7cT79+yG2ko9pn/oqsiiNY/pJtwrjDVQT9m/aupCKqewZ
hJEOCpJWf5k8OCVj3KQYQF4ypGetpnxzSvWqrSXtgL0hXEQopzH+R+Vj5XgD5o6H
nmROuPl06f5mhoCr3AQokGkz5P+57Xnhu8lVK/2ITcweGcYMWBOdH2QbYvkunbXY
/HdpOZVUzGxe1Fils+T7amx6oAceWvTVonYSvxAUuVW6VVMn8NYJAa1GLAI2bvx7
egQ4ht1zFJDO5K/gjiJJC6msQm/hf2mAzv0HN0+MbZgoQHp/emrF1WZ71RMcfsFa
T82vUC7vRNKkQ+cU05gYxfYISR8q2gTBBv/il+w+DJGsJFE6hSuvQhpDdrWgrYMo
PNHTit+xQjfK
=r27w
-END PGP SIGNATURE-

Re: Let's enable AppArmor by default (why not?)

[Dr. Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Aug 05, 2017 at 06:28:20PM +0200, Christoph Biedl wrote:
> intrigeri wrote...
> 
> > tl;dr: I hereby propose we enable AppArmor by default in testing/sid,
> > and decide one year later if we want to keep it this way in the
> > Buster release.
> 
> [...] while adding another security layer is certainly something to
> consider, I'm as well interested in whether this is feasible for a
> generic-purpose distribution like Debian.

Enabling it by default doesn't mean it can't be switched off, right?  I think
it makes a lot of sense to enable something like this by default, and in fact I
can't think of a situation where you would not want it, but indeed users should
be able to set their system up without it if they so wish.

> The worst thing that could happen was people will have to do the counterpart
> of chmod 777. Then it was a bad idea, but we (as in Debian) have
> substantiation for such a claim.

Yes, we should certainly avoid that; if it looks like that is happening, we
should abort the operation.  But from the well written plan, it sounds to me
like this is unlikely to be the case.

So just to be clear: Yes, please enable AppArmor by default.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJZhsUHAAoJEJzRfVgHwHE6/WoP/3NHlHKzWd/DPjBV41Tq6WHT
JwRXT7zqbsLa1UlxeRTBhbH82EAFYpn59s7d882/JQ+0MBvp0bcn9t85i2IYBS7K
LruV569kM0jYYGk4MY9BLmo5WlYlmrE7+B/8wc86oLsvi676SJ33dzQUNczt/fJF
SrXUWix2phMjLtHp9v6+OSdxCDnkMLGQX7VYuv7Zz1n0XenbXeQWBVK/8kJdsuPx
+WsojZ5u72n6IhpRQv4tiP0P28G4Bdi1JN4AwQNSqd44bV1bFl+2Em1DJquly/LO
hCVty9BJVuO/s0KdWeXC7raa4vsaiswKohA0GYkDqT8vBrTZ2chBbJNkQrByR7BF
iXp3o/irlpZIp7A7EUBLPfKKTAVk40gLrw/WYraGJ9zH9y/eNly6y7BcjNbzikMe
euOH+GPr6zvLng+KHC8w0qk3/m8FEWkamAmwPDqZVxuubvid00ECRv4WU9X4bvaf
coLYOumS+T0qmlHrLgUlTq8RtRHg6Nqok3DULQpofTWvtCrNDcWXI21YjDp+kNmW
JzlQ3Ja7baZFDHygmWAvG1fXWCIC3Bl3sLxqy9h5+1m0W8PxqPii/BIZjCSbVMu+
P3VRmryhxdLLL/nzt2zX09VtAJwNAKL42UYfh3nlJN5/4LnT2JpCILvktTtNJoym
V8yP+AuLbIo+TcDrqPLn
=fVTR
-END PGP SIGNATURE-

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Oct 21, 2016 at 07:26:43AM +0200, Vincent Bernat wrote:
> It would be as easy for the security team to modify the unminified version
> than the "upper" upstream version of the source.

The release team has just decided that "browserified" files are not source.
Please stop suggesting that they are just a different kind of source; if you
really want to claim that, start a GR over it to overrule the release team.
(Please don't; it'd be a waste of time because AFAICS it stands no chance of
passing, in fact I'd be surprised if you'd get enough seconds.)

> I suppose that (like me), Ondřej Surý does not want to deal with the
> complexity of building JS from the "upper" source for the benefit of
> people that don't exist.

Aside from the fact that those people don't need to exist, as stated in another
email, they do.  I'm one of them.  The fact that I can retrieve the source of
the software I'm using and it will actually build from that source is one of
the main features that I like Debian for.  And when I make changes, I want to
send them back upstream, so "browserified" files are not good enough for me.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJYDbqYAAoJEJzRfVgHwHE64SIP/RpZOrqwXyvWRKyqE1+2rBiz
GRxe0NLHK5OBGkg64P3jwQyz+FrH44U5OQ3GrJgOzRkaqFCb37guZYy+fhpFa7DX
HwxT/fB+woQwry5dOs0jicmT8xEp+mQqBKRI8jM/BX73LVfInsOb6XVzSFEMkvSj
O8L7+0Q7lmHOHizmPCbM311fNkWYkdVzabSUb4/1vnQZYqZKVp6wr+W0f6mZi040
ULHstz6HhcjWXEKnbxc3Ey6biDZNSF71vP/N3rTN5Kkk/kJ9/dr0NInzF3Uzw2su
8y803eh0uucEE+LXxe1BoD3KOi7FEZX37wC5ogSvWCHvq1mddYZPxIUgf/4lZRdp
JalQ1XvUyNB+nW/p7L/9+Tn6aYSyCQ84Kas9Y9PaymzTuBa2XrCuhY2h2k6/v+SX
t+PmyzX3oeBVscPWq/aP3Ee/uf3g3y6YNuIBjaLD9gFipvz2g/E7mZ58f41LdPWd
V+bYptYtv+essnldA/0Pck+fRA9mpSWrJ8PR98CuAgdZ11n9LkgS/xmYwvXWDOZZ
y7VslGA8LkO8Pn8tWSVMKSBSPjwHqKixWgG41zq7PKqVdT4b37cWAMCGgGwJRIwC
rWInHvmDDtw5RoT7JVFZcUnxw2RWuOcIeRLyHlKmFOZNls0bTlFbre00KYAp7zXP
mkD0wNL6TxTu/HDH4MQf
=p3i7
-END PGP SIGNATURE-

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Oct 19, 2016 at 09:07:26AM +0200, Vincent Bernat wrote:
> gulp is just a glorified make and doesn't compile anything on its own.

If make wouldn't be in main, any program using it in its build process would
also not be allowed in main.  The options would be to package make, or to
change the build system so it works without it.

It doesn't matter if the tool is complex.  If it's used and it isn't in main,
the program cannot be in main.

(And "I don't use it, because upstream did it for me" means you're not building
from source, which is a problem itself.)

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJYCIusAAoJEJzRfVgHwHE68wgP/2zsqzThuWkOCRSnXBrcuk40
jm/dp67lSfVfNuCF/767SyGPknBoEcBlHkM08dbIx6rhG9ZdJ9FmWhl8a6eAQQeB
jo4UQE3rSGhtfw7zxl8K39inQnpv+HyotOEZ6JWXzoUf+997uknAsB5OYHr2obZn
9tlg/oaMoHfCX/oXZU6sqL2yFeDhomO/zOf0rbhdWcBYwRSdTHkU+UtrkronqHjM
afFk0mt8y+c/PNQvs1NVpLSaLTEwoIYJCqxDywlnEkGw3gNXGmthM768bK7sVM/o
fZH9B0f2jDj5+2zyN/GcjxZw6aYD8ckyCZT90jpfA5wcUsPbYxOjo9iyxp9acFSr
D02upguz1tVJn4ksJvzX/hYVecKnO/8VdqPWTh75Kse3Pmsip/17S/+ICoII8rT5
+yzzUJF1NRh6Uuxs2tP5a6QLLBdecZ4l17SYrHNoOAevGFCcLHYNH+Dyn0AAoAxG
TtwTnFxFQx31Is5Gh3KWWO43ooMA42svCDMrcx3N1cOGrPpHS5RfU2BeFa1kkMUx
YR5gU4M+tt1D7HQ73hEm73pu56h23DLdv7QL4FjP+xlHUNF29c5G4dPYyQD8tNcW
7nRZP78n2pxdO7Xbi0HNzTbEyrhPmwT6cj9mCUzPJCQEsRKCM2v/kSLz7RGgSw3H
nHusejCreSzSKL7EL8Mq
=7iSp
-END PGP SIGNATURE-

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Oct 14, 2016 at 10:49:06AM +0200, W. Martin Borgert wrote:
> On 2016-10-13 22:39, Joerg Jaspert wrote:
> > On 14458 March 1977, W. Martin Borgert wrote:
> > > If I package a compiler and put y.tab.c in the package, drop
> > > grammar.y in d/m-s/, would it be OK or not?
> >
> > If you come up with a good reason for it, yes. But I doubt you would
> > find one here.
> 
> Let's say I need a special tool to compile it, e.g.
> bison-priscus, and I don't want to package it for Debian?

Then the build tool is not in Debian, which means that the program can be in
contrib, but not in main.

> > > If I don't even check that bison actually can process the file, would
> > > it still be OK?
> >
> > No.
> > You as the maintainer have to guarantee that the file is buildable with
> > tools available in main. You can't if you don't ever check this.
> 
> IIUC, this is exactly the situation of epoch.js in
> knot-resolver-module-http. I assume, it has not been build from
> its original *.coffee sources, because the make tool (gulp) is
> not in Debian. So the package must go into contrib?

Yes, until the build tool is packaged (or replaced by something that is
packaged, such as cat) that is true.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJYALUsAAoJEJzRfVgHwHE6pPgP+wQQwLEQWvQMYcJt9OmEpss/
JdZ4buIe3TsBipIk1yJh9n6YpkWxsPd8tkwfISbNedW4Cy2AsZe8T7lktI4G6jqr
XeDsGUtu8IIU5V6s3LRQX/0eurN9jKuUVhoY0V4LgHTC4MwPR8mFmZ9a9PicWZNx
C16N453qwiuM7fT5xpsssIzcpF30jrxQj+oNRpyonavu2k0q8n790cvz4pWHjNe0
Kzq1soPOGgcftOR6PXHL+ypPma6KUN2IaXyGkZB6QPXiYsiJWKN/xKom+/UzkiXd
G6B4D1J0jLk3PX2mvTd7nzJY+U5S1Jn8z5s9Z5/5BhOd94ZxjH2RlBHwv8Y/PBTe
tp+ZLpo0obIkkgWh8a6IxkmsHmpYF++Zz6wa21UYx0Rr0emAmfkl22cIlDByLUpp
XhfAuxG6DtDffV686otrSjNagx5PTr8E3aZFqCXMbaeD2zMQFN/auS14HYH/jRDN
IJWl30s2zjIiyVCHgOl6WZXGTwJbGeKYka60lo13RXRaLS3pICYRybJYykY39+Qi
EV78FKBjx+jO9e1exw8A/CTj6mI2zXjnEmIURKIaxS6lUyF8icPK91WBdh4OxV56
P66OriG7s+Lz1TcLFP6LG6y3+hW/8eLJytav0MFQV6Y67aZG/hztJPG56aGYKKGw
7+V7MkoG0YptzSPaW9HH
=C/8Z
-END PGP SIGNATURE-

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Oct 12, 2016 at 10:09:12PM +0200, Martín Ferrari wrote:
> On 12/10/16 21:41, Vincent Bernat wrote:
> >> I don't think that shipping a binary compiled upstream should be
> >> allowed, so where's the line drawn?

Technically it would be allowed, but because it is pretty much impossible to
prove that the binary was indeed compiled with a compiler in Debian and from
the provided source, it is probably rejected unless the packager has a good
reason for doing it this way.

By the way, that isn't impossible: xburst-tools contains a boot loader for a
mips device, which is included as binary in the package.  On everything except
mips a cross compiler would be required to build it.  Those haven't been in
Debian for a long time (but I think they are now), so shipping a binary that
could only be rebuilt on mips is acceptable in such a case.  But note that the
compiler _is_ in Debian; it may just not be usable on every arch.

> > Dunno. It would be great if the line wasn't challenged just to prove a
> > point and eject a lot of packages from main while DFSG#2 is correctly
> > met.
> 
> It is really not in my plans to challenge that line. It is just that I
> would like to understand the rules properly.

It's not about DFSG#2.  Packages in contrib _do_ meet the entire DFSG, but
require or recommend a non-free component for some major functionality.  We
require packages to be buildable from source, so if they require packages
outside of main for that, they cannot be in main themselves.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJX/qM6AAoJEJzRfVgHwHE6mA8P+gNPxycBMWPKCgV7N+hHSB60
2J+HDvLG40d4+YL7japyWIzovY7senVobl5Dz4IfjEqJovbkgprXLRxK3OqTn2EQ
pOk9ca2MM8IpYCvOGPfPVulDt2JYgalcj76kxYIzrIJnTAuylvohrz2R0kFIG4sQ
IkhSJxhOj4MlocRMrS6tWSDnJ6BbvXZRFiLtYdwEax4Hm/EsJHQlFkTZqJemetZ+
sQ/OKOC21Cv9HNC1I9Om4oKJnxX06yb1VGxWLP5qCZk8/skwZurJlG4LqnCzf5/H
cKTQeVnalWFo3HuFmFOAfZPeFMxmfIrK91vCkzynFKapqz3tN7yMilFk0Asr8bfH
Gjvq6q2SBoKUl2HPgm9de33TOUPkDsM9jQJz/JeDUpY2uwUsqqZHphIJvW0VsdfB
UCfaSlRpTgvh8axjVW3hWvKaQ1dgLwctedcIWRDzgdndFm8dYhKQOHimVVyVXji4
C8xZYoCGC32sODhW8slBBypx/3jBMN5XOUSCRN1lPzS6A/PERckFp7XQFG8sp4Qs
VFE80QUBRigW0XXgmzSvWozrUf492FnVXBOb/t1YDNptTNDiGeUJl6d+yn6FVF6m
k/aDJv5Epxi0IIhvXrXUEjTMeQxtMed6xl+jjfVO0dVGpf/y094SkOjSOoQRLRvi
dFNMwAFWlQhfv7SsBVhl
=Lk3u
-END PGP SIGNATURE-

Re: "Browserified" stuff

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Oct 10, 2016 at 03:08:17PM +0200, Martín Ferrari wrote:
> Prometheus being in contrib basically means the work I have done for the
> past year is worthless, as users could as well just grab unofficial
> packages from other places. I am not saying this to justify the mess
> with handlebars, I want to find a solution, but putting this in contrib
> or non-free is not an option for me.

So the decision is that this code in its current form does not belong in main.
If I understand your position correctly, you do not dispute this, but you seem
to advocate that it should be allowed in main anyway, to avoid demoralizing the
developers (in particular, yourself)?

While I understand that sentiment, that is not how Debian works.  And not
working that way means that Debian is of higher quality.  While it may be
uncomfortable to tell people they need to work on their package to keep it in
main, doing so means that the packages in main will follow our guidelines as
much as possible.

If things don't belong in main, there's a reason for it.  If a packager wants
to get their package into main, the solution is to fix the problem that's
preventing it from being there.  In this case, that's a non-packaged build
tool.

So now that the discussion about whether "browserified" files are source has
been settled (they aren't), I see these options:

1. Package the tools that are required for building from source.
2. Accept that the package moves out of main.
3. Fight that decision (with a GR).

If none of these sound good to you, what else do you suggest?

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJX+6dBAAoJEJzRfVgHwHE6UEEP/0FEuS6/Qxlrrqg0m158Qp2S
FSRYe9U2F+xpMchlGkczzVTUVlcznctQ1dvziE9o+jAn0sg5Fd6l07w9TS4Czjx1
x6ZKurxhFv2oT5MGSV177VLPrXe3ivGvHE1LRdxlUvJ7jV1fWbWqx0wqIHQjcPNc
JnQSVrNxdhmoytJVaKiI65o7A/YSpAzQDENDVrDQEDSvz1+wLPl6iWowjNipr7oG
sbwH+l3SFrboatDFo+CgutiK0nSU2KLwB2bV0TUmoprPWKKQtROzNIcBJKKytDUG
0Cj71qsAidOVw18Uy2O/eBjgf6f0buDY30ubHou1+dwU9k+Ewc0ZEdpBt7b5yX0H
NiJKn2URps4rSQfE7lFtFyxxLO+uNaUDHxtKX+azzES1+z5QaNoytkeIGcR+4poM
dSgmIccl90MEU6JWpFGoK5q1uVnVujZ+kkmwnEn65+qF+D85312JhdwSCkgpHBv1
y0XEHDDckql+0IGikQzvOvfEaHCTTUIdHSzl2z7SWE3yy45zlBdKKXDguH5P4/73
/Vsu3Bd5az8Rxo7XVrQ9BTZ3rs6GnVMuxtVeIWGXVQTd9qliYu6MlUX5Zbc0S2Qz
Dv8lnCgIbPBGIk+np73KtHLJf6meH3AgISznuLZBpNMaukRnCBPT4vfMm1ZENc19
6m5JVvL6I79lItT9mtfU
=sXZk
-END PGP SIGNATURE-

Accepted openmsx-catapult 0.13.0-1 (source amd64) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 22 Sep 2016 22:09:06 +0200
Source: openmsx-catapult
Binary: openmsx-catapult
Architecture: source amd64
Version: 0.13.0-1
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen <wij...@debian.org>
Changed-By: Bas Wijnen <wij...@debian.org>
Description:
 openmsx-catapult - GUI for openMSX
Changes:
 openmsx-catapult (0.13.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Remove menu file.
   * Upgrade standards version to 3.9.8.
Checksums-Sha1:
 8d8867921aeabd8f200ca0d634d7c5d2852ebe45 1824 openmsx-catapult_0.13.0-1.dsc
 9576d5544633c901b3c3f12c946d07ef3a571b90 1487596 
openmsx-catapult_0.13.0.orig.tar.gz
 d2ede6874bc6507e1af23a95e182bb6ebbf372a1 7616 
openmsx-catapult_0.13.0-1.debian.tar.xz
 d07d6b2bc3ebe24865ea2c543555c65519dcb76d 382432 
openmsx-catapult_0.13.0-1_amd64.deb
Checksums-Sha256:
 80e11ef7ce826460cff7134383aec784df1122f1e7719cac8d94b5993296247b 1824 
openmsx-catapult_0.13.0-1.dsc
 66c1338eba489b85fc108f6f71858ce56d6664d7013c8b3b4fc76dc2fd7a 1487596 
openmsx-catapult_0.13.0.orig.tar.gz
 fe1fd4286b84fbd96d1c4e03cf7bfbe931a0cf6a7c813b24263d1a7fe5df7385 7616 
openmsx-catapult_0.13.0-1.debian.tar.xz
 c0e8f47c5d17580890944e1b7b4cb06295fda716265b0ba3bf42c609cb83f88c 382432 
openmsx-catapult_0.13.0-1_amd64.deb
Files:
 276de86b1ccdab823ead3a14c15d2ffd 1824 otherosfs optional 
openmsx-catapult_0.13.0-1.dsc
 5ca81291b03e38883f38d965b8745eb8 1487596 otherosfs optional 
openmsx-catapult_0.13.0.orig.tar.gz
 51d95e01315dd7d2693545f1cb39f844 7616 otherosfs optional 
openmsx-catapult_0.13.0-1.debian.tar.xz
 fdbf62b7243e833916e59fd548d1ab51 382432 otherosfs optional 
openmsx-catapult_0.13.0-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQIvBAEBCAAZBQJX5EPsEhx3aWpuZW5AZGViaWFuLm9yZwAKCRCc0X1YB8BxOvCN
D/0YnlLabxpLCnuYlNJs17pxweEmfZhfxdlUqWXqPa5O6DOXxFxE7i+7APWG7392
d/+ma1OPur/2TGYHurb71qgYTQUTdL3zI1qW09CUytFzDd8RyrA+0F1Mf3Sv6jO2
+4qWgapjN6m89gL4TI4UkLyPdEq2pVTtOWwxIPVFzIpToqBJj2bI4sEAQd3e0Ir1
BQM3gan88e9tfp/wl85WBB1557UvHBi6edBIohiTXbmbIVS5pXtwcxScT8K5utvz
8aOTh503vr+xF5GsMkrL5Jaqu0fDYVsPrrQr49sETTeGFCI0BWTh7oFwMgZk2ggV
u/dMJ8AC8sCUS15WTfWIoAQdxLtoW8QmCpK/ZCqKy8lluXF25pPgM2lKlzNCsLUy
w8vDjULW25lDbT/ckzzCX4Hd2JPgGndRt19T26mq1sPAl7UZWx+4ufMZO1WVYCu3
aMDH4YkbqZD5bVP5oorpl8A7fKT5dqHGQjWtMDn14q/Ad2RUX+HAzrFtV2243GpL
pVlBwW287nxHcMdYbXKLEduhF5c6VdbpDzDXmoURGWDVXT/ED8KasgnyQReSBQmZ
T41Pt5sHO9ZdOu0CRL/+yt9SWOAyoqYzOCQuPkjpjo7+JKjl1zlC0o6GBmNXS/eV
jvkKC2XW4l8vXP2zOZ28YXdhzwbxiitlZDiNRt1MpAowGg==
=M2pf
-END PGP SIGNATURE-

Accepted openmsx 0.13.0-1 (source all amd64) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 22 Sep 2016 12:24:35 +0200
Source: openmsx
Binary: openmsx openmsx-data
Architecture: source all amd64
Version: 0.13.0-1
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen <wij...@debian.org>
Changed-By: Bas Wijnen <wij...@debian.org>
Description:
 openmsx- MSX emulator that aims for perfection
 openmsx-data - datafiles for openMSX, an MSX emulator
Changes:
 openmsx (0.13.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Remove patch which has been included upstream.
   * Use new verbosity flag instead of patch.
   * Revert recompression, as upstream now compresses without timestamp.
   * Update font patch.
Checksums-Sha1:
 c6a249022ef8f7581976c28a2c71823229e3c6b3 2004 openmsx_0.13.0-1.dsc
 49fb349a8a88b4dc03d51b1c709cdd7f40c085f8 4956658 openmsx_0.13.0.orig.tar.gz
 fb664c1f27d52328774d9642302aafc6d7e6fb94 10560 openmsx_0.13.0-1.debian.tar.xz
 cb57669e5d79f115e3ae8cf4b14db32393fe4ef5 1280690 openmsx-data_0.13.0-1_all.deb
 a1316876cf51c41a7bedf869a1bf85c3717d4021 47318950 
openmsx-dbgsym_0.13.0-1_amd64.deb
 37f20d75d526da963354c1b6d156cee1ac432ed8 1690700 openmsx_0.13.0-1_amd64.deb
Checksums-Sha256:
 78aa1d99adcada44b68a1a791f49246a9aca3b7d4fbb1742a3f3acb97413e586 2004 
openmsx_0.13.0-1.dsc
 2d5e5ac58d64882fda435376f6b760e8f07988de9d79ec964916683b60c3a07e 4956658 
openmsx_0.13.0.orig.tar.gz
 e6683b1f2f178a26c8ff839f9751eb87a4ac7bb42cc4870c6c205057a7bd30c2 10560 
openmsx_0.13.0-1.debian.tar.xz
 549d876301f85cb9cd9f65881c4244fb721df63f56eaa63df79fe04bee4f7524 1280690 
openmsx-data_0.13.0-1_all.deb
 f5f72a924c8e3a004801e30c08b403b5c55fd08feb95c6e0512b5e647c0d1f70 47318950 
openmsx-dbgsym_0.13.0-1_amd64.deb
 092c87e8b5a1b6b04db76d2e5943519aa8d9ec988c53cfde70b7da70a877bf20 1690700 
openmsx_0.13.0-1_amd64.deb
Files:
 648f6799bd623ee4339a2465fd11676b 2004 otherosfs optional openmsx_0.13.0-1.dsc
 35d58f271d9d9855c4e0fe9a8c1e606c 4956658 otherosfs optional 
openmsx_0.13.0.orig.tar.gz
 18b4768fd6bf3e74eb28a1482453e0ea 10560 otherosfs optional 
openmsx_0.13.0-1.debian.tar.xz
 bf4e06c4b71fe2a09805c98b0fa1d45a 1280690 otherosfs optional 
openmsx-data_0.13.0-1_all.deb
 e29b3314f83f667cc9549af01b1055f8 47318950 debug extra 
openmsx-dbgsym_0.13.0-1_amd64.deb
 f38ea9f2995ebcab6419e18f32ed9a2f 1690700 otherosfs optional 
openmsx_0.13.0-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQIvBAEBCAAZBQJX5EPrEhx3aWpuZW5AZGViaWFuLm9yZwAKCRCc0X1YB8BxOsnU
D/93o1M31B5ITDl7uPx42PwGSk4c7fBiZlNl09esOVMsdmnxiQjYL5GkTnx+WZgI
7USu0icYdr31maSRfUp4CEIkD78VzOl1GzB4hLbaBZPb9EgtId8A26WPKhe9K1mE
jNbY/I8sEGVULMNUNta8oJKIXwDkXH7CWm8Z7pPFvgJyV6dSLuf67bpvDTBJNIpn
uCFkKUAlUPWDoIZ/gwFUUPew71TE1YJ2vHOD/FeMVSorO8rJ5xt2JKYQ+0WI2jVd
yU6u8XbqPHlvX9Z7X3GBCcDbwaTXalH+osWyvNcESc/SzlfioFgkdQdNR4FZOrUE
ePMzKXIVv95lqtwepMqGQ1Hw16IwchZLo4h8x0f/BnOyqykD36/MI2cYYJo7jQZH
zaeBl1l//ozoaJ47neuz3FVoyTTTrB3rQO3Z4CGnLhdEmNtZGo5r9nUVHtj7lR/w
pBHChkSWhisL7FSnDhAm0XIfOo2kmZagFElrcRHy87c2S73VeqjE69PT+Hitd907
qW5QQSOSZS6kyD5FNUTdS25kM4KbXEDb937ZBUxMSt/8wLUdwBolh8LlsL3HrViW
0UG5/Bsth1XBGNjaShlUVO4EwuoKM7sDzAUffNfqBT6KlfNxzY9Cx1BbDN03LenS
57XWf0diHxOPc6NAkSOzCKDiOzZxuYM15lFlV7n8nMrlUg==
=xUUi
-END PGP SIGNATURE-

Re[2]: Browserified files and DFSG

[Bas Wijnen]

July 11 2016 9:57 AM, "Pirate Praveen"  wrote: 
>> Yet it is built with a tool not in Debian, from a different form of the
>> work that upstream actually uses for reading and modifying — the source
>> form of the work. So that compiled form is not the source form of the
>> work.
> 
> There is a reason for that requirement, it is not like a bible or Quran
> or another holy book where we have to follow word by word without
> questioning.
> 
> For me, the reason is to be able to modify the code and with readable
> javascript file that is possible.

The key part of this sentence is "For me".  You say that because you don't care 
about other freedoms that real source gives you, other users must also not 
care.  Then you conclude that a form which is obviously not real source is 
"good enough" to use as a substitute.  For you this is true.  But Debian isn't 
just for you.  Other users use it for different reasons, and we don't want to 
break our promise to them just because one maintainer didn't care about that 
part of the promise.

> Yes, to be able to send patches, you will have to change different files
> (just rearranged), but is that enough reason to remove the package?

Yes.  It's reason to not let it into main, and if it got in by accident, that 
should be fixed.

Note that you seem to misunderstand what "being in main" means.  What it means 
is that the software is free, and that it is built with an entirely free 
toolchain, which is also entirely in main.  Failing one of these requirements 
(in particular the last one, as is the case here) doesn't mean that upstream 
did something wrong, and so it isn't a punishment for them (but it's not 
uncommon that it is perceived as such anyway).

> And why is the people who are so strict about packaging the build tool
> not stepping up to package it?

If someone wants to change the rules, and that requires work, the people who 
want the change should do the work.  But this is not such a case.  Here, you 
don't want to do all the work that is required for packaging the file (in this 
case, the part of making sure the tool chain is also packaged in main).  In 
that case, the answer is not that those who care about our rules must fix your 
package.

> FRP for node-grunt was filed in 21 May
> 2012 and it is still not complete. So removing these packages until
> grunt is packaged makes debian better?

Yes.  Because people (at least you, I'm guessing others as well) want those 
packages in Debian.  If we are strict and say that they cannot be in Debian 
until they satisfy our rules, it is very likely that someone will fix the 
problems.  If we aren't strict and let them be in main even though they violate 
the rules, they aren't ever going to be fixed.  Or are you suggesting that you 
would package the tool chain even if this wasn't a serious bug?

Thanks,
Bas


signature.asc
Description: Binary data

Accepted stx2any 1.56-2.1 (source all) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 20 Jun 2016 03:28:52 -0400
Source: stx2any
Binary: stx2any
Architecture: source all
Version: 1.56-2.1
Distribution: unstable
Urgency: medium
Maintainer: Panu Kalliokoski <ate...@sange.fi>
Changed-By: Bas Wijnen <wij...@debian.org>
Description:
 stx2any- Converter from structured plain text to other formats
Closes: 817681
Changes:
 stx2any (1.56-2.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Use debhelper compat level 9.  (closes: #817681)
Checksums-Sha1:
 95c04ecc503c04208bb3cb02f5137cd4db34de22 1635 stx2any_1.56-2.1.dsc
 60ae20d8f2ffb40e34d298f34c5c8ee5a53e2f13 5743 stx2any_1.56-2.1.diff.gz
 d07419f71756cbb12934b2462a5c55e0c2efaa8e 84950 stx2any_1.56-2.1_all.deb
Checksums-Sha256:
 0eeb2b3f7104e9b339fc31202bc0f1eaae48d95b34c2682ff5c2dcf80c039f09 1635 
stx2any_1.56-2.1.dsc
 3e98e8373d93dc8165fbd2a167ceb0c8cf61a43942fd876906575d8bb330049f 5743 
stx2any_1.56-2.1.diff.gz
 94f2db393f6a37589a51591e0f24f15e83e2543e45f657489eebb5be33812f0d 84950 
stx2any_1.56-2.1_all.deb
Files:
 b43ffa3ec6ffe3759f8ac83d7d9c051b 1635 text extra stx2any_1.56-2.1.dsc
 c0e55f69145c1b3d68fc8d7a260a3fa7 5743 text extra stx2any_1.56-2.1.diff.gz
 2f1b8028a133e094da26bb42ff0dd96f 84950 text extra stx2any_1.56-2.1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXZ5vQAAoJEJzRfVgHwHE6QlgP/RmZvDE3XZFMxITieoGN8FCV
u9iyqcuobFFP421NxUIeiivydvj3j0W8KXTfhQsBaJL/A2DQOG2+/iJ3W2sEBbOY
vDApNEB8VyeEtZGH1A9frlTCPTar3dAndlE/H+ZY5OlDY3UiO5MCgEpybbboIyKe
rFBVZNGcYmwS1iHQHbYjFGlYLwyHmwQU8khPOLN8B2MRqXab3SkbE7fYmieIfcK9
BMlYkRgSLD/em8CJDG8ozgCEtkcKNGhgnsyALEriiCQZjfu+mau09y/aEnagR/vm
nl9QDzFQQ516NroKmYs/P/hFaZNsdFEz5HRFW4Gt1mhrzKMeF5IQly6r1mU2YgXZ
NfGnd7faOOam1TlKkfsyo50NpgZwcgEoO22Oj8Bs6zvserpmIlPPhHkBnyJ4XHlN
V3FQAixDN2cbuEn6/qVzwsyS5sl9tTOPHdy1GwaQHe2OuQOvS40oOqCsPJDHG94m
gmvxxjyBUBRS/V1XMJ71mHaHpM/MPtL/b607Luhn/cmXDNqJpxoMPxOib0f8tyCr
m9+eSD1OGz4nnMrJ+Suo1rczG32d8k9OVbnGNwyQwuS7MATuYFrWyJ7T5xDN3dot
5I1Jk4cbkV2QvQ8dAXUTizTjYPpFk2EynP1IHoO7DDUvFLoPoBqgCxExceC9bPke
KgXPX6qegBbaz3i6pHuH
=UzRD
-END PGP SIGNATURE-

Accepted openmsx 0.12.0-2 (source all amd64) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sun, 01 May 2016 11:54:08 -0400
Source: openmsx
Binary: openmsx openmsx-data
Architecture: source all amd64
Version: 0.12.0-2
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen <wij...@debian.org>
Changed-By: Bas Wijnen <wij...@debian.org>
Description:
 openmsx- MSX emulator that aims for perfection
 openmsx-data - datafiles for openMSX, an MSX emulator
Closes: 822650
Changes:
 openmsx (0.12.0-2) unstable; urgency=medium
 .
   * Fix build failure with libstdc++6.  Closes: #822650
   * Use fonts from ttf-bitstream-vera instead of bundled.
   * Recompress dummy rom to get rid of timestamp.
   * Remove menu file in favor of desktop file.
   * Upgrade standards version to 3.9.8.
Checksums-Sha1:
 9c634e8eb76d7094b9e2468ccbbbf63abaedbd30 1992 openmsx_0.12.0-2.dsc
 9f2c0a3a8c84f41966aca62886b57ccda9249ac6 10536 openmsx_0.12.0-2.debian.tar.xz
 d2b5af51fbdca0f9687141c69fc171bf7d99c1eb 1275682 openmsx-data_0.12.0-2_all.deb
 4f9898fe6cec05cfeeeac96c7f512ca55a3704d1 40796882 
openmsx-dbgsym_0.12.0-2_amd64.deb
 8d81b0efcfa5f2a1756a17bb2d50e1ebb7784fb3 1652636 openmsx_0.12.0-2_amd64.deb
Checksums-Sha256:
 3ab07b01269de5f74cf6856daca2b43f064412d42a349e1ac52c937019131a47 1992 
openmsx_0.12.0-2.dsc
 80cbb9620547e25d593828fe299fc546cae37f823f1c2cb6d586d9a703941fea 10536 
openmsx_0.12.0-2.debian.tar.xz
 d74fef109b70d7a6d5141cc35bfd2bd955a5bc3a45a14e8630b7b67bae1869c6 1275682 
openmsx-data_0.12.0-2_all.deb
 a7dd27814dfc9079a693bfa58bf0d476e5521c2574793703693b35a7794d1fa1 40796882 
openmsx-dbgsym_0.12.0-2_amd64.deb
 c4b2a695d27d8f7425f97112d65cb533072f189c41fc34881137e613e1383037 1652636 
openmsx_0.12.0-2_amd64.deb
Files:
 e0431db90a880061cb091bb3006d7f38 1992 otherosfs optional openmsx_0.12.0-2.dsc
 6902d1d38c61136a503a12070c5c00ee 10536 otherosfs optional 
openmsx_0.12.0-2.debian.tar.xz
 b1f50902b1bcd1d02be16c05550d63ae 1275682 otherosfs optional 
openmsx-data_0.12.0-2_all.deb
 4eb18884953f0207b0368fc269f82387 40796882 debug extra 
openmsx-dbgsym_0.12.0-2_amd64.deb
 81d61e0b18cb368efa0a2f547bc1c161 1652636 otherosfs optional 
openmsx_0.12.0-2_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXJinHAAoJEJzRfVgHwHE6krUP/3QzSmKSU+5pE2Ps93//ABSd
UFkO4hA94nypi/iH/a9/mmRxGvpin4K0xtL79fDEqwYQo/N7d5ru7vgj5J4wg0dk
MvxJ3q6hV2nBp5rpsiHuQOrRWSSGRHkaAY5TMUi87VhWKebv7NrM+pzekA5YZTj2
XxXYBy99E+4nVCCDuri5sKGmFQVX226nqubAronWdFbvgn5YmQT3hWIKAuVFrd4d
1yic7NwKhpmff+UFFwk9uyGfU+tds5D34e8xUMjYpfcvGGufxIFfibRRoHHZ+dP5
tVCM1AVzJTGF+6SQx0fppI2grKGrdjy76sMUsUoi4+lBCSL7YZbrHhIvgRQOLaV6
LUmTyPIp0ExjDokikRpk0QhbDWxUfeLom8FnV+/nl0lbccSRbjK6jPDcfkrenQUr
OiOM/oc60h6AcQ3zR4imhej0bop/+DV7a8g8IIDrAW7dff0+NR5rAOeudLXecvv8
DwpnECQxlHWAXPRiUaBrTRvLhoPCIi9aN9IQ65KnEKgAxvpnHEza1j34meFUApDs
mrZhYkKpVA08PKAni+fY2xGJ5eGwTsQpPXh6yamObQ1oVVOKchLPr/89hw9oU6Fv
GnQ/h91GqiM3sAR/XGS4NNwGj3szw23c2QQsCPpuntSjPXbPdXDkkCuQ0jJJEgUH
ZkoAtQa+3BXhneIi+cU8
=9eU2
-END PGP SIGNATURE-

Re: using whiptail and translated strings from arbitrary scripts

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Apr 27, 2016 at 02:28:22PM +0200, Daniel Pocock wrote:
> If I use this method, can the strings be translated easily by the
> Debian translators just like the strings for po-debconf/maintainer
> scripts?
> 
> Or is there some additional Debian-specific advice about how to do that?

Debian translators just translate packaging texts.  Everything else is done by
upstream (which can be the same people, but it is not organized by Debian
AFAIK).  You could ask on Debian's translator's lists (or other translator's
lists for open source in general) if people are willing to help you.  You seem
to think that Debian has a system where you just submit the text and
translators will work on it, but that is not the case (other than for debconf
translations).

Debconf translations (and pretty much all other translations) are done with
gettext, so if you use that, any translator should be familiar with the
workflow.

Thanks,
Bas

Ps: I'm not an expert on this, so I could be wrong about any of the above.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXIMy9AAoJEJzRfVgHwHE6OkIP/R9TJZWQM8XkoA9lP260QSfO
4p1hsHXT+0rBjlRpeOKq+mYQ7HmyC5IGuf1m8FqiK/NVOZ2MMx36N6Ok6j9f2jSB
vu+UTBtvtTqUgWUzovIr+FzpVX4U610Y++jSKol0IYAdHQegS8ULeZaVROGxO7gb
AMNjfMrLwh3fAdavqjCs0gnSVrJTsApdncU3DVjhjZLaIR9IW0gsB8mzXYIRDELQ
5a/uZFtOonUrKMYxyPYB6i3VC0sgIgYg6rZvjHCRmGjC7pR2vGdDRsa/468HWayD
vJwPKchG82oAv0W7J8fUQZjScAhPFlLOkDIytnb9IqxwUQeiidOtVGGw4J+ohKnE
Gs0Dfi1Kr6l+0JRuRx7z0WohB19DXhOWiS+9T/PPx+p+CYfD66pt5voZPJ3l0OPZ
Us0QQaJ+0DUSlBZjBQYJPMGtLQjDc+jcy4WnFIwMV8IzccpD5L557nvsFpjCeB+q
6Fpue45pA/tMPZXtDPZjhdsdfy9EXY5qV3cGkimkPvfB5ckeJsJoEHXFQ9yb+rQR
Ylo4DRFUCi/+fLpn4jEcVm3QBcYMMaCW8qM/xnfPcv5jZvTx6tmvxMyrBdHdCXsY
oZnbFaFL+AttlSO33r+noghA4xogfvKii6iOt4RvtpzbP14F2GUo//lI+9hDnPFC
ejoJ7LhKYWwIo28hi4Fd
=/5jX
-END PGP SIGNATURE-

Re: Packaging of static libraries

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Apr 19, 2016 at 10:13:28PM +0200, Vincent Danjean wrote:
> The initial argument was:
> > We in Debian are in a good position to defend our users from the
> > fallout from this problem.  We could change our default compiler
> > options to favour safety, and provide more traditional semantics.
> 
>   The safety argument was presented as one that dominate all the
> others.

I disagree.  It just says that there is a safety issue and we could improve
that situation.  This is a public discussion, of course counterarguments about
other things, such as performance and usability, are allowed.

> I just say that other aspects must *also* be evaluated and balanced.
> And an small increase in safety is not always the best thing for the
> Debian project if it leads to severe performance/usability/... issues.

I agree, and I think everyone does.  But at the same time, where we want that
balance to be may change with time.  The quote above suggests that we may want
to shift towards more security.  But nowhere does it imply or suggest that
there is no balance.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXFpfsAAoJEJzRfVgHwHE6NeAP/jm7Z8Mrxkvo2UipoCKShQNe
3ig1WMVcnWV/KIlxmMNdYR4Ey10bcBizqKw+htJ/D2gxSqaQChXrLHmZwqaCEpV5
7XMMLJ8oOwLevZSR18UR7L45ncCXrlzqCUaX72LFa9tHDVNc+V1cTT0WwiMCVGT3
gPbsluUGOsbXRHhdj4+C7CnstCItnVKrp0ogXOyDR2S4QFy7vBPEOf+VnD1asOxO
Y85FBWyA1RMDdOrhKZJneOrUahICBmTnyzdH/vEwB0EOBwweZgQymZecy85PUIFk
za5G2dnQa50DhKua7zH8zSHjfkn6iB4AlO9T8igoXs1ZQuMrfXFto7F+N80TItPW
wZKD8jvkrNs5UnkG6WCrn7aXUYsho3DwHvTFtRu6U4S/Q/63WuIWST3JUp8KJNyr
uzz0FpnsfgXA8dVfGkrj0rl4igC9xUf1K3suHNxARK0k/oag6TO8bOJ8efcgGLUq
kK7Sq+daWpYDMiD/cYjr5dFvC0hQY+AKRPMunhi7pVAoy+ORnCp0jotwCFBa4sWQ
0BdttvTLGDYizwUUW7m97zgdKWNxShMxFjSsGIMkIx7ozq9q3+lsUG/eZODOy/uh
9TOkJiWHAIfHSdg6VtMGZRw1MGe9JtyT5KyCc3j08I56yoSVnv3yYdspe1v9ZnBi
iWvO5HSNETQfgFf9SlnI
=eyKN
-END PGP SIGNATURE-

Re: Packaging of static libraries

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Apr 14, 2016 at 02:57:00PM +0200, Vincent Danjean wrote:
> > If users have such specialized needs, I think it is not only reasonable that
> > they build their own versions of their libraries; I expect them to prefer 
> > that.
> > So we should make that as easy as possible.  I can imagine that Gentoo also
> > seems attractive to them, and it may be a good (or even better) solution.  
> > But
> > as Debian, I think the best we can do to help them is to make it easy to 
> > build
> > our packages from source with custom build flags.  I'm guessing that we're
> > probably talking less than 100 people in the world, maybe less than 10, that
> > need this.  It makes no sense to put a package in the archive just for them.
> 
>   I do not understand where your numbers come from.

I understood that this was a very specialized thing that some people in
research institutions would want.  So I guessed a few people at Cern, for
example.  There aren't that many projects that are running for months.  But
it's still a wild guess, and I'm happy to believe you when you have better
numbers.  How many people do you expect need this?

>   I also know lots of HPC clusters installed with Debian. If Debian
> choose to favor safety wrt to performance (instead of trying to find
> a good compromise as currently), it will probably loose some users.

It's always a compromise, and you were talking about people who don't want
that.  Those people will need to build their own libraries.

>   And no, admins (and most users) do not prefer to recompile software
> instead of using the installed one (some users do not have enough
> computer science skills to do it and some admins are already
> overloaded and will not want to manage a derivative distribution)

It's all about priorities.  If having optimized libraries is very important,
they will train someone to do that.  If it is not worth the training, then
that's fine, but then it obviously isn't so important.

> > And changing the default compiler settings to fit their needs makes even 
> > less
> > sense.
> 
> However, it already occurred : we compile by default with -O2, not
> with the compiler default (no -O options). Until now, the Debian
> project seems to agree that this is a good tradeoff between
> optimization and "code correction".

That's not what I meant.  You seem to suggest that we should compile for
maximum performance, at the cost of security, because some people want that.
Or maybe that we offer both options, I'm not sure what you propose.  My point
is that we should not do that; we decide on the compromise, and if it's too
much towards security and away from performance for some people, they need to
get a different distribution or compile things themselves.  I think we should
make it easy for them to do that.

But I understand that you think the prospect of a small group of people leaving
us over this is unacceptable, and we should try to avoid it even at high cost.
I disagree.  It's nicer if they want to keep using Debian, and as the universal
OS we obviously hope that our system works for everyone.  But it's not the end
of the world if a small group of users doesn't think so.

To clarify that: being the universal OS means to me that we have a good way to
use Debian for every situation.  It doesn't mean that every user thinks Debian
is the best solution for them.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXFnGKAAoJEJzRfVgHwHE6DKQP/22wUdhkis8hV53571xuGtTn
WDpYSKvwK98aodJDUzb70f4ZAncwLSiEdugOq+zmDdNY/ZkT/36qfWxFCakPpa8r
N1dxLI7x7kq0K5fdnYj+lLUgLJI97NiwdJPWVun7NE45fDS9zY/9a4XZ8VDTzoZw
WdIBaEZgfa2liDn4HCjDPI/j9Nll7h/IAeHFx+l0uB49wS0ydmUxTnYde22oOjXN
hQoMBJBENXulCa073XBDJ67O8v7iGFXwR09ZcFixq2lcfvoLzgmAMnuuxhnWL/EQ
I4e8ywXog0Mc9vvzCQ0tAPlUhkuzocpLvBArYVMwiFNXVMzmShNH2bh8iaxruG5P
4NUTKI1d/lK2lNt43n1HDBBwULPpPend51+ywbH/FTOtZKyHz88Y4+nuJPogXr0c
Ejn+k1/SJ/tLHVCUy1TBQ4W25ns24WIwMBAsOog7McgnS02skG9QCAEmPj+I0KJp
BuWsUO806PaU3LmX93l7wgxVOwtNf4JrJsuOB5o3wvhD3asnVeHiiwIaFxGvK3zW
eBMl0Gsrbz+dtRKD8Ni3uVtPztxlAZVNgotA3mXWD+00wFu+TrrO74N0IXXLxXRf
7VnmpuYo4ICNmkLdgPFwE/pdzdAxw3xWGH2YLSogwPZoI6uuOa2UmbnEnyLNy/Dy
0mmHlB5r4qxc3zuwzKub
=TxnM
-END PGP SIGNATURE-

Re: Packaging of static libraries

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Apr 13, 2016 at 05:17:54PM +0200, Marco d'Itri wrote:
> On Apr 13, Ian Jackson  wrote:
> > We in Debian are in a good position to defend our users from the
> > fallout from this problem.  We could change our default compiler
> > options to favour safety, and provide more traditional semantics.
> Which would not solve any problem in this case, because then the HPC 
> users will just not use Debian or use custom optimized builds.

If users have such specialized needs, I think it is not only reasonable that
they build their own versions of their libraries; I expect them to prefer that.
So we should make that as easy as possible.  I can imagine that Gentoo also
seems attractive to them, and it may be a good (or even better) solution.  But
as Debian, I think the best we can do to help them is to make it easy to build
our packages from source with custom build flags.  I'm guessing that we're
probably talking less than 100 people in the world, maybe less than 10, that
need this.  It makes no sense to put a package in the archive just for them.
And changing the default compiler settings to fit their needs makes even less
sense.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXDomkAAoJEJzRfVgHwHE6QfoP/R1gfb7vdZhPmICpevBc5/4O
th5FSmNMb1W65gaVlOZlDhmIjoacL6Rgj0hJQuw7zMa7YUKE2O30/Hce+DPKaNiM
OB7IEI5yywkyUUP5h9wMIXZP8LV+tsr9M77tgon+QBuJ2nURczvPqwtoKP/+/NEI
PkzWnmbzixFaRPeBGQA76Iqn8/4YfhUN2aPTqDnVvZNCQyi9SxNLMbN/K5FYe8bB
/vxx3tEfVDulPNeu0eHhx/n2lULJocCMiRWhkpyfGhMPtV+NkjYPI9hNpdhPIbIn
MIqYP3rF9BIfabL9aLlcY/8FxlH/DmwR5cSzt9PtKLd0hL1mBRZ5+ef/L8QbkK/r
6nZDPh5/AYjnFXfZ5YJIj8+op2MCxQlcKnStvIAsXbC120mgxAOpERfWn+/j4QBQ
g3NSoLqgWb0Eoo15TvtrQGHeHCtuE0o/vRECq4QGVFaD2pgaMfvFsM7ZRU6TR7El
ilBqY4Ri/ct8msxAQ1NQLTsbzm9p2Dc9NnupiugT3or0OPRt4HDg7PO1xEZps4pV
tjA49GKD9dqmHtZUSpV7nsaa+40KQzOQxqNtbi+6fryB3UgTColBjlVp5fcXBzYZ
zD7zy5GN7LZimxYV8NeM92y9zcbS+CHMdTPayqeW2vH6MYUIAv6zDHijxpF67fld
ZTNHMlLur4tFUWTrwtkg
=atJe
-END PGP SIGNATURE-

Re: Packaging of static libraries

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Apr 11, 2016 at 03:25:46PM +0900, Mike Hommey wrote:
> > What uses require PIC static libraries that cannot be satisfied by building
> > -static --whole-archive ?
> 
> https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_PIE_.28gcc.2Fg.2B-.2B-_-fPIE_-pie.29

That sounds convincing.  So given that we want hardening for the entire
archive, shouldn't we make PIC static libraries the default?  And allow
maintainers to provide a non-PIC version if they consider it useful?

At the very least, I think policy should define whether static libaries are
supposed to be PIC or not.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXC1ooAAoJEJzRfVgHwHE600IP/jMkEaYHQPen0pVqET6nExGm
xTABDDSkaDKocAigz5wjICeYE8OJtxvVs5aO/scPPFq0Na/+UfmWm1v23omHIM5E
BrzDyPUjwphFSq2JsAMRFVO9XYIRraEMDMxZuQDMoSZwuExT5HmRNOn4VTs0ceTu
zXgQfTv8KOCLCFSRbkWxLdu8J+NyprAyOm4XCMq08PVeNIXgfXAohVGDRraDVdF+
HQgjROAhKje+ZDUM5aak/fMH7wqxUp0zyjKdb3IJ/solW3N/Ld2vsZdbCgxqlIvS
Z17VkgI6/RFjzQhoj9ew8S31toXuqheNB5aAgON3Ocw5dbhJOuW9GHnrUzYY2oEK
jFMJiDZWxfSMrydI0NVrn+6xks5FjyEhMTuhDF7deX7DMy9Qtlrwgj8GbA8G9o8/
rTUElQ6U9xI4BDSBYZjNzDqqgKHfcX/0bn4SX3QAj2Jps+M6pt+G2LIwHYJ8AJ+s
vEtfbSxbQhbc+t6ZphB7NEcZhoWLlosA/OMASBjnlBxtxVJVR5F+0Q40idl7JBtR
jN2Ex5rV18N4ibjWouBuuZ+Q628AgwGxKFvOkp+oN9J8gXBtt+fhMAf2UkG4NR5U
2mqP5/+QceM94nkoyyUnIohYy8NzEWMt69qsyay2pXeWfJdiavspNG/J7yc6sVVR
Q9FuntLNnAr+dJiWoDwS
=H+ms
-END PGP SIGNATURE-

Re: Packaging of static libraries

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Apr 10, 2016 at 09:06:50PM +0500, Andrey Rahmatullin wrote:
> On Sun, Apr 10, 2016 at 05:57:16PM +0200, Andreas Tille wrote:
> > > > whether it is advisable to try hard to provide static libraries even if
> > > > upstream build system does not easily provide both.
> > > Note that it's only a wishlist severity bug if you don't provide it.
> > I do not mind about the severity of the bug (since IMHO also wishlist
> > bugs should be closed).  My point was that to my understanding people
> > are misunderstanding policy when giving the advise to ignore static
> > library.
> If you want to provide them it's fine, I don't think anybody will stop you
> (and if there are reasons, we should update the policy). You are just not
> obliged to do that work if you don't have enough resources or it's too
> complicated.

I think we all agree here.  Static libraries should be provided if possible,
but it's acceptable if you don't do it.  However, as Andreas points out, if
people are advising in general to not package static libraries (or worse, to
remove them from a package), that is wrong.

In specific cases it can be fine ("it seems to be hard to do it here, I
wouldn't bother"), but not in general ("packages shouldn't contain static
libraries").

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXCnwoAAoJEJzRfVgHwHE6WiIP/21an2YKFamUTAMY9EfAWo+U
L46eEk6zWaMUtUYVwN+lnwiMWxoRLZqBucksh6u2eF62VpZ3XwkyXQLJnVbdEGUS
nCSsJFGm5W/VxD3DsMhdSmEhkI/XajkglC5+RZnOcLt8b+UW/xa5gDmLi9XybS76
N8ep2bx5MLoO8XyaCR3dABKDBqXcgReys9Vr7wps4u+ocXCw34icphQ8mgJxn1kN
XSixGvsV8tDAhnAuzqZLHz+hRMZo0IQ6+UewKr0gYaMgVp5gWRbi70+RP6jj/qkN
UqDE0nLYcaMtvU7xt308Guuln+SEyhy44RXLJUHmf8lwQWG+fg7nXXrGPfMYjRjr
YmeaC329gOzKkggVbu/TdN5tgDLNP10uGMV/4mve0O3HCOzmd9P8qOfdeXIjpjxQ
WXNgQ1qEC9c7qufSDFGAoYSzN8P1DlomxDn6gEhNCl/XQwLuetxdVifkgNcScfxF
PWv1oYUwoEBSb4ULHqToLBOXSr1HTm5ZOeReGwj27zpL9KEtk03wUWSNFRveB1D3
eno90VtbCtWCLi00VxvQDBJKcA4ZlMjXPZA0b9sPgTfgKQ+6jKuYbDIcpUWdjeF4
EgOewNZW3EaAfrbLae4LrX0wwtrBNPte4h1lrpEaJq5Fl3mzmEM3C2qgxOevIrgr
GZTMwySVZlWXHcUVtHfP
=pEit
-END PGP SIGNATURE-

Accepted openmsx-debugger 0.1~git20160326-2 (source amd64) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sat, 26 Mar 2016 13:39:59 -0400
Source: openmsx-debugger
Binary: openmsx-debugger
Architecture: source amd64
Version: 0.1~git20160326-2
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen <wij...@debian.org>
Changed-By: Bas Wijnen <wij...@debian.org>
Description:
 openmsx-debugger - Graphical debugger for openMSX
Changes:
 openmsx-debugger (0.1~git20160326-2) unstable; urgency=medium
 .
   * New snapshot.
   * Adjust version to match repository on github.
   * Upgrade standards version to 3.9.7.  No changes needed.
Checksums-Sha1:
 1c1df4c08c003fcd763286ec6e4f9a51f656e277 1839 
openmsx-debugger_0.1~git20160326-2.dsc
 8e747886f7525e52b5b78fd7593bffc1b7c2784a 326368 
openmsx-debugger_0.1~git20160326.orig.tar.xz
 d9e358b933cae24a2a8a2b2243cecb659ff54dd7 5016 
openmsx-debugger_0.1~git20160326-2.debian.tar.xz
 c248202c504a77bbe62b4840acb515ff79dcc254 6617690 
openmsx-debugger-dbgsym_0.1~git20160326-2_amd64.deb
 f431bdb04c193296f48829998364eda316edda56 323212 
openmsx-debugger_0.1~git20160326-2_amd64.deb
Checksums-Sha256:
 ca3f45f8d4ff19b9413931bb3ec75cfef204b6c30b955b91db3449de387c6916 1839 
openmsx-debugger_0.1~git20160326-2.dsc
 aae34638febdeb403b72ed820d364aab57e823869a354a5a69cf0d357646a647 326368 
openmsx-debugger_0.1~git20160326.orig.tar.xz
 cf596b742873a89499ce6ecdebfe3d366451f6a89b195cd27e7f328b6e5c5905 5016 
openmsx-debugger_0.1~git20160326-2.debian.tar.xz
 26125e119a0935129347c0bca8a86b6cdf09872b14180dd75312eb7461a267bb 6617690 
openmsx-debugger-dbgsym_0.1~git20160326-2_amd64.deb
 e651968c0e9460887ebcf93644ce0d35ffda9b078bb271916d3ae4b87b58642a 323212 
openmsx-debugger_0.1~git20160326-2_amd64.deb
Files:
 a414e4f1a5c6b9118bca61488dc3a368 1839 otherosfs optional 
openmsx-debugger_0.1~git20160326-2.dsc
 5467b397d52c9e885cc42aa275d2f6e0 326368 otherosfs optional 
openmsx-debugger_0.1~git20160326.orig.tar.xz
 a904658b228a5ad155fc15c90b08ed23 5016 otherosfs optional 
openmsx-debugger_0.1~git20160326-2.debian.tar.xz
 5dd2cd49a8185d8a7cc17555b24d504b 6617690 debug extra 
openmsx-debugger-dbgsym_0.1~git20160326-2_amd64.deb
 d3cf5ef2782b206dd0966d58777861e6 323212 otherosfs optional 
openmsx-debugger_0.1~git20160326-2_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW9spFAAoJEJzRfVgHwHE6InsP/3eYKNvMtMV4Gxn9TScYlCyt
VJGOhmyr+HbBV/H8AXn+iqs6o6kDQBAwYYGcMlAwReDnUV3mVNEJ2lPF6jnY/8IL
1tYQlzyLeSIfBXkfJF8ddwu/0vWMFW+M/W2Xq7m9nBaLg7w16UO9G3sa8D080N9t
UwQVisvEEbj8+DyP33MOLQhQ0Gji10BD1ef+iRgydVa3biG5ZesDg3y0fXynQx2B
IscyyAiH7GRxR9Eq2wY/1d9AJjvOewDcsHOjb7b65wgCwy76VDpI1YwOD7/EzyR+
KqWb3xyXsqTWQ2Y5gzThx2PUoj0t+uVDHq+1tGHKNBXZbx2QV9LswsAr4bxTuCdh
NAVwkPGitLkHUFBFvaBsem473GJo+U+SUL/TXWaHxonyP/lzLp3OJgmi2yP9bPVp
yNagPVfz+3+hdtAUpiu7mcNe/yIs6b/tkRC8pRHI3HkFAUzddvMtaV4AlTRHhzob
UxyawW+lctwtKHQHpEKI51rGjH3eNUpkhU661nF5bTonn+3d24sW5n6/YSNTv7MG
tAF9aWjhVoNlrPfDDzvogEaapnpDi45+VSdMCU+KKx/E+rShEL4qDXUGbwDxP8on
mYdex91wfBZ4i3fuf/FCH0EKyEOQLpztHxFagWhPe+qSJ6KNQJvIbHnkwkbLBpcC
YMrE4kg+1cy0taiEpPJK
=dOGY
-END PGP SIGNATURE-

Accepted cbios 0.27-2 (source all) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sat, 26 Mar 2016 12:34:38 -0400
Source: cbios
Binary: cbios
Architecture: source all
Version: 0.27-2
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen <wij...@debian.org>
Changed-By: Bas Wijnen <wij...@debian.org>
Description:
 cbios  - open source MSX BIOS roms
Changes:
 cbios (0.27-2) unstable; urgency=medium
 .
   * New maintainer.
   * Install links in openmsx systemroms directory.
   * Updated standards version to 3.9.7 (no changes needed).
Checksums-Sha1:
 ab49e485abc766db2bfd7a500ea48bc1ac5b2c96 1671 cbios_0.27-2.dsc
 c70fd573e0cd0da92b62e8b2b47809c06ccf61de 4992 cbios_0.27-2.debian.tar.xz
 eea305ba49384b4778f39a8bacc69357fa6500f1 29782 cbios_0.27-2_all.deb
Checksums-Sha256:
 cb16c9fdcd161397065990183de1646aff9e6bb8e7924df5cc5823ed37bfbe35 1671 
cbios_0.27-2.dsc
 6f881f9734d490b0a785f063855684c00569fe2f28acb262c26ad4f8ddc242ee 4992 
cbios_0.27-2.debian.tar.xz
 a347c2d32d3ec3c34bf14a0af261ca6def5a2bf69cab9ddc7d6b08849a56cded 29782 
cbios_0.27-2_all.deb
Files:
 0571b968bbd0c6c69a8434d791feb216 1671 misc extra cbios_0.27-2.dsc
 9d4e3d0a9c6a6af20bb481b772c2b58a 4992 misc extra cbios_0.27-2.debian.tar.xz
 4b0961a06c0bd060397a4122ae0a7bac 29782 misc extra cbios_0.27-2_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW9roxAAoJEJzRfVgHwHE6OiIP/A93FHH4MAhFUvMJBnyW1ARC
FLp5X32r1v7oMPiASRMuOCwDKQbboGU66pGEwZJFtEqxZv/zemR2jMUiMKUHJICg
a/4emgRJVOrZLifLsBh6MIkAZpHGfcGpa47RR9j2iewh6KOFvVRvTRdpSvi4qXH1
xWPNkO4zz0v70NgXk7prkWoAYpavTzBeahic//JAXb5EzS7XKMAO+HWtlwdBCN33
TLUOi3BzwRzIT2nNhhhkLbb7uiCm73c84sFWOTleCGKBn8kV4jN7Fkj8/EMtu878
EjVkdSBVF7jYgf4QcFce9YZRBOd11IZX7Xt7OVIJTbb2+5SxJpxrRdDsqDkOPGVQ
9xxQS1I7sGiIvqD6C+HisKHUIZ4XOHBA8G9c+ZDmtshvkcXmVcF3PmmTcP4zxYVl
WA6zDiUz6xBpw7H8iEYZbm8y5e4ZnKSMJEVcnkV5KdBPGelStHPuzpoJd+cE9jR/
jrTNT8x9/5d7km4p2EhC5HfkHJD53+fYfivnTpHym7ZqqcoefSmuBksgl7ACVpHJ
vZU7wQdo67CXJ8uTf5guaU4aeq6n7G4qZP5yPeS9SrX/HsELMZrRU3rK6gzt63Pf
JIQwLKkhWytzIUr6+JGay0KJGJeXU1BPAdF5f+J27lxVo6YX1vFm7SE4z4Qua5Yn
/NsdhfsAah2P7s5APEAK
=b0Ba
-END PGP SIGNATURE-

Re: Mass Bug Filing: Missing Build-Depends: graphviz

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Mar 22, 2016 at 09:26:45PM +0100, Santiago Vila wrote:
> I think the issue is not really whether HAVE_DOT=yes is good or not
> in general, but whether this is an issue that should be decided on a
> per package basis or not.

I agree, that is what we are discussing.  I'm saying that if a package does not
specify what it should do, we should generate better documentation.  That means
setting HAVE_DOT=yes.  I don't know upstream's reasoning for not making that
the default.  It would be good to ask them; they could have a good reason.
They may also have a reason that is not relevant for Debian (such is "on
Windows dot is hard to install and we want things to work easily everywhere").

> Packages using doxygen usually have a file in which they put options
> like this. From 57 packages I checked, 9 of them deliberately set the
> option to yes. The upstream default is no, so this means the other 48
> (sort of) deliberately decided not to use dot (by not overriding the
> variable from its upstream default).

I disagree with this conclusion.  I have some (private) packages which generate
doxygen documentation (and they depend on graphviz), and I used the defaults as
initial values for my configuration.  I did this on a Debian system, so it uses
Debian's defaults.

Your assumption is that most upstreams use a non-Debian (based) release of
doxygen.  I think it is more likely that that assumption is wrong, than that so
many upstreams think inheritance graphs are useless.

> But we are currently overriding all of them.

Just the ones that don't specify anything, right?  I think it is reasonable
that Debian makes the choice for them, and generating better documentation
seems like a good choice to me.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW8cBmAAoJEJzRfVgHwHE6rHYP/A2jcgLASXeSfJZ9maMoUrke
YNT7Qqh9kCWj8OOXVZnTIAc9sTRzAcpfR4k+myw4UwliivFFzhVMqcPfYnnRLfAs
zixCdPzMtFlNCrjX9AUeqXHu73u9+6B9sJQqer4jv7Aa0xPEC7sI1fMJh8Zvck8J
hRBLspgUl+4nechFieIotkpLrNRQoD0DJlpRByjnZfA5660E71fdEeLxvUR9cHKG
6cEH4QjCw3qHdwxJhxSNsB08oUOL0YjFoFT6tui8YVAO+AvnZJjwF4VNk81ZI8WX
MdAybwQWgERLcbjUZ9Gn6kQwuF5y/e/zaqRmYDWCzFxU+WErNy+p93Qfk1JFGAA8
tpkaMEJBDPK3uNJm9jmFwfzE8z0SNFKrkJcHTidGSFkqRRsvjomxkgmHAJYa4KAK
sYJ65mLwZkrvp5aUTqTJrRoK7ewpus8mCAZHLAKP/kkgqVThNaXEWmkBzSXdiOBx
dkv1zSkmyTY2RjPUmNt8jvKj2rh5YvDNm+0fPBkt+LXGmKp5t/Ux+/omGWHJy/Hj
GXx78nhLGIQP2fnBBM7n1KB5LGszqpMYIs8YhIEYwHSDWrzoPUFvyb9WI+3K+Sdg
+WKAVWgJ/sODjHngzQdpkHYjfORY2NSBMjQQvqEEYCro3YJriubL6AIY9q3QgUvo
Qc26EKLaDUrysP+qqf2s
=6lUh
-END PGP SIGNATURE-

Re: Mass Bug Filing: Missing Build-Depends: graphviz

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Mar 22, 2016 at 05:04:50PM +0100, Santiago Vila wrote:
> So the number of affected packages if the default HAVE_DOT is changed
> to "no" would be quite low.
> 
> If, instead, doxygen is changed to depend on graphviz, there would be
> nothing to report at all.

I think that it is reasonable to use HAVE_DOT as the default (and add it to
Depends in doxygen).  The upside is that generated documentation is better; the
downside is that builder machines need an extra package installed.  Builders
shouldn't be so low on resources that that is an issue for them.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW8XZVAAoJEJzRfVgHwHE6/WYP/AwmgDodFIJqVpr7yA1ETWCB
t0dK+UyEtwpCUcnR9BMUM4K50tMn19EOzEktuogBxCWLfJWyMg8DnAa6cXke9kgQ
lynbVl2T0nDIrSyGnSqx1Kqzy+K4FG6w6Hh/9qjKN3yCnTkNqo5ISlW0+pkRh2Ln
VYHD9WG2Xy0Heu5cruyxX+Bx7ximzfTKNkH3duWD7ixEa1GQS3qaVd0ybSAAxb0R
4YoWK+2bY9n1ExTpU1qtKBxfwfJp30NS144I9TUjnKrR0b684kx75fv+TAI60B4j
uBJtsBQ0YtyWAx+0BGl1uHiszG0PvXsvtmX07aLFUvTNe0jm+n0f8NbxK2wZ0+IR
6IMolkaQMy/tApBWXKKeGPDhF760iaERE/lK3Cfb/cEaS64i7h35loJg8itP87O1
SXee2vVkbByTHtMhM0KxwAAmXLYaLyhrEJWQQyFfstIbBT3yNpvo4r/V+F0kwxM+
s6QFBcZuuJ4MD44bm0Z3duRi9DhIid/oHwOw8akELAtPsKqkoFCzNMMeOMgXMysC
J3UtShQ8iT39gMcJIZq8XSr8O2r3ohAVDfJAt53KRjnLIddZayUKgTwNzD3EMD2w
jmUK0kg2thBlZbu+C1ElXjRTTcTJVmVjqpiyLt9dKYV4l74p7SAgU2wXpEbHuMtw
8DddW4ejVpMWWbBFw90W
=QEB7
-END PGP SIGNATURE-

Re: Bug#818900: [Lua Policy] integrate debian's lua modules into Debian's Luarocks

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Mar 21, 2016 at 02:37:44PM +, lumin wrote:
> When I'm dealing with one of my ITP's I found that this is
> a noticeable problem to Debian's lua packages. And I think
> this may require some changes to our lua policy, or the dh-lua
> scripts.

What you describe should be fixed.  There is a problem with how your scripts
work, though: if some packages are installed before luarocks, they will not be
indexed. Not unless luarocks scans for installed packages on installation
anyway.  If it can do that, it might make more sense to just trigger that
procedure when a new lua module is installed as well.

Making that part of dh-lua seems like the way to go.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW8A3zAAoJEJzRfVgHwHE6Qu8QAIglXrTQ5g3fuMIfAMoUz+Z/
qmtOu18LBZ+c20D1GgXRSz5AC+v9/9qLrEwYxM5smmOOaW7nEtNDfBOBY2Zme4Mm
NcTe1kqzaR/QOQ6zCRANzTD5ZcLsk88DSRxXby0cOBBXrPr+QtDruDESre3Wmu67
BW24kAD79kAp+W/gLxN2IIvRPMkOWF2/Q8ElxujD6Hm1qLanpkIvkJwqoQmrRnrL
eN/EG+LbOOwoJ+sXeH/SXE/Cox6XrECahb2PQQPlxRN3KElMnu+JspV76eOAF53r
sn7hsPl7TfNHHC63ciWOiMv5JfXGGikl3/UMfJSCiqQB29iE3H7/xLkK/euEI0wL
cVUEMeVC6AsgldAGlufiqIgQgXK4pcms+sOt6/AlnwkWL6JtoQuf3cp0dCFtGMtu
0AUcre3I/9DG7lrkHFcI1GITt//kXsDajodhqIfgzK+rfmctfNb79fe3Indb/1OI
t0u7AompBTqTA+adojbjvRgj2XXmcgk/hcUGzTlD6Rfwkbv3dHE4EicUOdM/XL2g
jhSbNmrfnpAWg9Mf5rcGyB9uFjiKIz2pcI7zfl/B9B12zWsgpt4qq8l0Ktl0apcs
OwlQ6Ocp5m/N7vq3x2Ml7i2Rbo6JsinVeQJ9Q4zA+1V0uozR5s2yMYbL92X8AcWp
YDmDAUpOfKl91w6h17+F
=GHup
-END PGP SIGNATURE-

Re: Mass Bug Filing: Missing Build-Depends: graphviz

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Mar 21, 2016 at 11:26:16AM +0100, Santiago Vila wrote:
> > Yes, so that's a bug in those programs, not in doxygen.  It would be 
> > "fixed" by
> > adding graphviz as a Depends to doxygen, but that would be incorrect.
> 
> Please note that it is really doxygen who calls dot while those
> programs are being built, not really those programs. And doxygen calls
> dot because the HAVE_DOT variable is set to yes by doxygen, indicating
> that the dot command is available.

No, it is a configuration option which is set by the calling program.  It
defaults to yes, and for that reason it makes sense that there should be a
Recommends relation.  But the caller is not required to keep the default, so if
it does, it is calling dot through doxygen.

> Do you agree, at least, that it is not doxygen business to claim
> that the dot command is available without a Depends?

I just reread policy, and changed my mind on this.

Policy says: The Depends field should be used if the depended-on package is
required for the depending package to provide a significant amount of
functionality.  The Recommends field should list packages that would be found
together with this one in all but unusual installations.

I wouldn't consider the graphs a "significant amount of functionality", but
that is subjective.  I'd leave it to the package maintainer to decide whether
that is the case.  Given that they chose to make HAVE_DOT the default, it seems
that they do, so then a Depends would be in order.

On the other hand, if they decide that it isn't, then the proper way to use
doxygen with HAVE_DOT enabled (explicitly or as the default) is to depend on
graphviz.

So I agree that if HAVE_DOT defaults to yes, it should be a Depends relation.

> Since we are all Cc:ing the bug address: This bug report is not to ask
> doxygen to depend on graphviz, that would be only one of the two possible
> outcomes.

Agreed.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW8AViAAoJEJzRfVgHwHE6nVAP/Rz/av7mSDWdE2ZbLuhHi53h
rLhES9CKE3YGIY7rXIyrKDIr3o2XiKYQtO4yLEhyBzxRPjMdxta2hnr/xUGyzlaW
icR+/ugj9agt8oN11As/kTdr1HZVxjgyaGWAlbaNu6xrFFoK0EZ8atKmroPXtL6R
jjfVJBDWpssX+G5oI4xWX0toVRCp6r9HYMuJIei33qDoSzyVekx0GUXaG/zSE5Pe
tpKHR+swiYbM6d9s0MB7TyjTDDdN83XX9LnBEwXOtEn6FVeFJ1eBl2VgTXNF1wRu
q01jIQFmdIgrpJey6GImfwA1uqrCg8QNqThvOA7//NY0iBXIb37jLNsi5ir90Ot5
LYakDtJtwpi6bq+AZo+THQ4AKChQX28PCuZHGAVbaDycbM0fhbfriJ6pqAQZ5Ut/
dZhjrP6FaPZ/AxowS14lv+tl5dreP9ZnaQE6yqNvKztPNp8AkQPerne0EPYlNr4I
OFw4/CzOyMjaT7U7Hb0xjzJw5CHsZodjPkdTysgNzBfHsNLKsIzKiL29HtwA7bIR
QNiuP9ANAgPIL/XYidiSpTVwrjj3kKKQ7/niAAwVRq4aPJBACKxYeT7Zy3a9BDDk
mnmU4Ahfnu6Q6RB/wYKxChs/CZgadcGrWWuRUfELP/HEfHIig6PWLR5nFAuTBG9r
YAgQtIkupO2lRRVOBqBM
=5Z8f
-END PGP SIGNATURE-

Re: Mass Bug Filing: Missing Build-Depends: graphviz

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Mar 20, 2016 at 08:07:55PM +0100, Adam Borowski wrote:
> On Sun, Mar 20, 2016 at 06:51:23PM +0000, Bas Wijnen wrote:
> > That also means that programs calling dot will need graphviz in their
> > Build-Depends, no matter what the default is.
> 
> As is, a number of them do call dot without the build-dependency.

Yes, so that's a bug in those programs, not in doxygen.  It would be "fixed" by
adding graphviz as a Depends to doxygen, but that would be incorrect.

> > > The disappoining moral for this is that nobody looks at their build 
> > > logs...
> > 
> > I don't think that's disappointing at all!  It means we have built a system
> > that will let us know when something is wrong.
> 
> That would be the case if doxygen propagated the error, which it does not.

And that _is_ a bug in doxygen, IMO.  If it cannot produce the requested
output, it should abort with an error.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW74DXAAoJEJzRfVgHwHE6jBIP/RbYo/q85gRUI5YIyEwAETF0
RLpIWDvWFvJRhg9TGfVA3VfeAmLrsOG59V6cwuszObY1I1VX1NVpJi1RoUTiZ9O2
d7l3boQ8YRb8ll3e49LLsfHoIWw6Tp30KjbrrvsOWjH/18NDZkEK89uXFzK+/U8/
kDMADNsFvpo6/5MzSp59LSn7+YvKKuOOSypkPR2K1DzYhCL8lPno3lq8lCX6uAz/
oXjwIuFMR1KNJx/pxL9DeM+bP+9qwe0xQlL48C7kuGzvyT0ZF2gofETtlHvAbrQe
Mg3y7EbBKU6hNLi7hs9KqI8G9h+9FuyI5jeyNv0ixQQrtbDWlY8j2LBOQbwBGnNO
PeSQ0e+HmcRQgPCqBcysGxmCfTpJmfS+lAC5Q3ip62sVHIQzot/GnQBUBVZLUi2W
JGBF+JJirQ33cIw8v67Uguy4GO3/ba/I+NZFKug4poPvskmuVhMJHB0gU5Nr3mL0
Sn3dC54mzPtQk6Eq8oace9hZl39v3dHhWG/Oce/dL8sKhwkIUhc19LGk/mc0aHCQ
FC2bTVLMeCM3ZjCso1piXA10WeD5JFK2hg4B4sQCtbePQLfWXTsLsKSkNdEWqpU3
NeEeMtVaQwyMV0WRQD5JKSoClpTSsQf7cF+c+U3IKVOhkZJpwh8TKUQASo9f6Ywe
Rj66EyyM2s72+7qVxS9Z
=fTpp
-END PGP SIGNATURE-

Re: Mass Bug Filing: Missing Build-Depends: graphviz

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I think you are mistaken about a few things.

On Sun, Mar 20, 2016 at 06:04:55PM +0100, Santiago Vila wrote:
> The maintainer points out that the default value for HAVE_DOT is NO,
> so he's reluctant to add the build-dependency.

If the program can be used without it, it should not be a Depends.  That's what
Recommends are for.  Default values have nothing to do with it; Depends are for
things that will make the program unusable if they aren't present, Recommends
are for things that should almost always be installed with the program.

That also means that programs calling dot will need graphviz in their
Build-Depends, no matter what the default is.

> But this is inconsistent with having graphviz in the Suggests line for
> doxygen.

I agree that if it is the default, it should be Recommends, not Suggests.  This
doesn't change anything for the problem you're describing, however.

> The disappoining moral for this is that nobody looks at their build logs...

I don't think that's disappointing at all!  It means we have built a system
that will let us know when something is wrong.  That means we don't need to
poll for errors, because they will be pushed to us.  (I think porters are still
doing this manually at least some of the time; I think FTBFS bugs should be
reported automatically.)

In other words, my solution to this bug would be to make doxygen exit with an
error code when calling dot fails.  Then make will fail, it's an FTBFS, it gets
fixed, and everyone is happy.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW7vEqAAoJEJzRfVgHwHE6Gm4QAKAhBvdYk+2kTZ6SKTjgH/B0
4OIBO8nSOJe+O5yTB3AordZq2zZS1afM0oWB3JiVfa6l6Ka9dfC8f9TOlvW5xGnm
pj0OO7b7jrH5oK5XToqj3DvDphNKpNwWnHKbeBWlJY779SVBa50kdwnbtg77wa5k
ZBl1NWLFlFeRgjbG6BQpn1l50NyRLMzTumLFtF+rpZACAwoiH+bkJVDlu83lfM72
/B4WLl9G7wxnhwhtfs2PcvRaYF8EzGuNDizu2PbwCp31CKUszF4+0q9JiqHtTwmV
VIFxB31fSU/RpmEIxI086wStd/Rax+Cn8HfAyTY6/tIOVBCeHYnNajWZkVEcNsoj
srsaGpPEGJouGr/MLqQIk5n6LLsiERq4aha5WpmccmgkNCxTIUXZlU62J6y5DzlT
lDkG5NXkEuf1qsk9bUJQEAbvdCKfbX6mtlbibxtGlSpeZ6LwfsQ+M9MoX300kH84
UYHMovo6M9CHXLdxt9AJOVBJTbERXbKVysnrov2pVlZSZiPFu7M/haz6Um13Vsku
AlIpYRYpfTRiNZ/dg1Tf0AtnMkSIqhy1441Jj+Egpe9EXAs9GfWaYNOa1yZYm1d8
1Wcbh0NdzakVDNmTWuPg47bGt7IOGUcgM74DQuRLCWxcaOOnErs0nI7+3x3kZ+5/
77few9WmaB+ZHhDWb+Vv
=AU0O
-END PGP SIGNATURE-

Re: How to deal with "assets" packages shadowing real upstream

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Mar 09, 2016 at 11:37:12AM +0100, IOhannes m zmölnig (Debian/GNU) wrote:
> i think that §4.13 does not cover the original issue of jonas at all, as
> it's about something different: using convenience copies instead of the
> system provided packages.
> 
> the case being discussed is (i believe):
> - upstream releases of "foo" contain a component "bar"

Technically this is true, but the important part is that "bar" is not just a
component, but one that is separately released.

If the "real" source of a library is bundled with some binary, they should be
in the same source package as well.  4.13 is about components that upstream
downloaded from somewhere and copied into their source tree.

Since they only have a copy, the real upstream will always be more up to date.
Also, if Debian finds a security problem, we send it back to our upstream and
we want that to be the real upstream, not just a copy which is used by only a
part of the community.

> - "bar" is not an *integral* part of "foo" (it's a dependency)

I think you mean here what I wrote above, correct?

> - nobody has packaged "bar" yet
> 
> - may the packaging of "foo" then rely on the included "bar", or do we
> have first have to package a standalone release of "bar"?
> 
> 
> i don't think that there is anything inherently wrong using the included
> "bar".

Yes, there is.  It doesn't mean it's not allowed.  As 4.13 says, it *shouldn't*
be done.  If there's a good reason (and "getting the software into Debian with
the limited time I have for packaging it" can be a good reason IMO), it is
acceptable to deviate from such a rule.  But it is wrong, should be fixed and
deserves a bug report.

> esp. if the packager actually does split the "bar" component into a
> separate binary package so it's usable by other packages as well.

The main reason that is better is that it makes it easier to transition to the
correct situation.

> actually, i think in some cases it's even the better approach...think of
> all that tiny js packages; wouldn't everybody be happy if they were
> accumulated into a bigger upstream, even if this upstream was just a
> proxy to the "real" upstreams?

No, that wouldn't make me happier.  I think it would be acceptable, but I would
prefer to have one source package per upstream release.  So if an author
bundles several of their libraries in one release, that should be one source
package (but may still be multiple binary packages, if that makes sense).  But
if the libraries are released separately by their authors, they should be
separate source packages.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW4HMRAAoJEJzRfVgHwHE6Q+UQAJTn4Ib9TK3VVfqqNe8z49lC
I8ba3y12luTjGIXzTSCxExo3IDCAmRlG4+/6VOA/js57r27hIi39V1n+QCrbJ0I1
gMQ/qYFrEn9BZnJkkbMgb/5gc3jhMX5wj2xuO6OdecCosKKqU8QwP0pEDl1Lc1BS
0LcRW7vLZbau0oskMroMyQeeslaJ9FZO/mi5bgaVCVSSx9kM4Zb0fpjAHmvjWb2q
EtTAm342kVZwhEg2Yk0GpI9XNVsV+kcUdb+JHvsB0XUHXIPvQLIfaqWMCxYl3I3K
JbHePmHWj0oVyxE3YJ2EL/mlyo3qaeWnnJbHzREN26N9xy39tC1xdhMGqXxSy232
LL0y0cSQw7WJBKq1m3QtzgNmcZMSKfci4h9nXn09/9lGH/c8y41+tkoM//6SQd14
swr4NobTLxIstaGR+jCDYwI58j/sntetqQiPUxKQk9aaKUUd/QmBs1rwVgHH8Gy6
0EDcKkhi7t6C0kN4ZSYqqYyxo2HtamTPubYFlOPq4vP5NgXs6iSHexXSIUL0cfhy
HJsJWLcdkSxUu0XvDcQdhFncZSVjWXx2nPBxOg3PFNXYJUMj0rUBbj4voXQ5Atna
MJvZPPdVWY8beQDGOr+3Q1vwXNsZCYYu34lqcokvolrwXE9M/Ltw4DyoMNzGOlSb
a1SyFqpEkcNux4VIcn0Y
=SXtk
-END PGP SIGNATURE-

Re: How to deal with "assets" packages shadowing real upstream

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Mar 08, 2016 at 02:14:10PM +, Jonathan Dowland wrote:
> On Fri, Feb 26, 2016 at 07:59:29PM +0100, Jonas Smedegaard wrote:
> > I personally feel it is a bug to not track the true upstream of a 
> > project, but that seems not part of our Policy.  Should I respect fellow 
> > package maintainers prioritizing convenience over elegance, or insist 
> > that we should strive towards perfection?
> 
> The former. "Perfection is the enemy of good" (or "shipped")

No, both.  We should respect each other's choices in what we do and don't work
on, but if something is wrong it deserves a bug report.  Bug reports aren't
commands to go fix things; they are helpful notifications that something is in
need of fixing.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW3xk6AAoJEJzRfVgHwHE6khYP/3oXfN2CmcsPpxbeeuZDCrgq
Ycj4JBfzTxOIYrWFBSxbFCOoMlcSqmuhRrc4Tim9GYn1GBl7ljC1so2BfVSGs2Ei
Cg5nREyO8xz5pZ+LZb2+6r94Nf/8PUpFGyYbdbRkyK1rCtiAeSMkGQh1vb6NRdn/
Q8HQ4wzhewMV1+qoEuwLbwuv3KngsGXsSDrETG9UxgOkMlK9EowvZJ5WRV08jJ5w
LROQ9rW0OXtK6Ql+uQgGoS41gTpEmyfhjh3P+CS1+wgvKUzzkP1t3/h/fLNgEREQ
+9wzDd1ggvoCtKbOw77FErY34V/uOEDyrMPlAQI0kRW1dOTeCMMXwy2iEy4oloE6
yHIyhUCSQhCDJoQi6BLeLY76GhIuK9wQG+ZOQyBsiga+0u7gB0h2jQKyGfxu5jCL
zQQLnkY/u6m+/wOEk3ugxNmBQNMJdYkq0me7SW1Tg5zk/jR0KcCUywOQLTnZ+lFO
6h6+KlBFHkmpawZkYcF85V7WodUVuIY/5oowtiz3Vh9zcFlf7QKso0QoqQ2vIVGD
5ENMH1zeMtiBmXcmfz5YJDyU1l/eY/2DaH+9ouJlk6xiYNw+CHWZIikQzO16tITr
3BD4mQUc7t+v71cb+I1NM/WTn7SCAANu4LBnsIHA5Sl1qE0IWA//eOzo7BuiOr0/
eftUsMzjpr95Ix0lOW01
=mpkU
-END PGP SIGNATURE-

Re: How to deal with "assets" packages shadowing real upstream

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Mar 07, 2016 at 03:12:10PM +0100, Jonas Smedegaard wrote:
> Oh - I just discovered that this _is_ covered by Policy §4.13 already.

Reading that again, I see that it says code copies are acceptable if the code
is meant to be used that way (with GNU autotools as an example in the
footnote).  For convenience, I quoted the whole thing below.

I think consensus has changed on this issue: this practically means "run
configure as shipped by upstream".  As far as I know, we now recommend
regenerating everything from source (configure.ac, Makefile.am).  Should this
be changed in policy?

Thanks,
Bas



4.13 Convenience copies of code

Some software packages include in their distribution convenience copies of code
from other software packages, generally so that users compiling from source
don't have to download multiple packages. Debian packages should not make use
of these convenience copies unless the included package is explicitly intended
to be used in this way.[29] If the included code is already in the Debian
archive in the form of a library, the Debian packaging should ensure that
binary packages reference the libraries already in Debian and the convenience
copy is not used. If the included code is not already in Debian, it should be
packaged separately as a prerequisite if possible. [30] 

[29] For example, parts of the GNU build system work like this.
[30] Having multiple copies of the same code in Debian is inefficient, often
 creates either static linking or shared library conflicts, and, most
 importantly, increases the difficulty of handling security vulnerabilities
 in the duplicated code.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW3xiUAAoJEJzRfVgHwHE6WOgP/0D9QUq1YIA35swoccr+NHTF
NR3/JPc2CHhml0g8R90QPKRFnn+bBOtVC+660R9y5dCWinF1+dgSi1PRXwgVN/yi
iMAJyWlOKhu0p5otlWhWL5ikEBQNlNwL4p2+o/mJwTlkmCzXqjiv5oTbcS5ZMsWE
4+GyQNJS77UrIQ5pznBIf5pWcnVElECXp/Ayd1/dW1zr+nftHR1f/4feyd/z2yLv
F+Qyo1RQd2ig8WM++fvXbvjfjMHj56OUNGkZb+9aiKXVXgsaKjVS98jKOZ8140iM
JLjqZEZn3Uw73NozgoAN42OKQQa46G/3XjSsSiiXN/rnRl2DdS8K/Z1tG+QX0z/P
IB8Rs+/FEqg22Az9hmtJ+QhPrgEovv+CMQu0ZTy8Va6ah0n7cAE21fPKMuL/1VW1
izx5kFEQLpiU70po/xmlKpMXPZ4HnwuSZWL8wp2t5ofI2knZC5x52pkJ2kKNxvy1
Agv4S9RviKzf9F4VkvnjSEumX5EQs6vJ6QwvgYGVGVCgwcvfRVa1PotcULDktesb
oik7ZH8E0YQPh3mYYttmnjswuPRZ9YQUpS55bTUv9hi2gnR3+7eBdCL18cOQgFx2
Ta6R4/gPO67sSOTGoIptIPELcquNPpZ2XNSqXmxrDQMjS3/82N2yF7FASZ6Hhe+G
vqNNj9w1JIZ1r/157ROZ
=Ynrt
-END PGP SIGNATURE-

Re: Can "PDB" license be considered free ?

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Mar 07, 2016 at 04:38:55PM -0600, Don Armstrong wrote:
> On Mon, 07 Mar 2016, Peter Rice wrote:
> > The conclusion was that scientific data (SwissProt, PDB, etc.) are
> > scientific facts and it is not reasonable to require permission to
> > change them.
> 
> This isn't true; there are loads of reasons to change sequences and
> structural models of proteins. Protein sequences are just based on
> references which have inaccuracies and do not represent ancestral
> sequences or the true variation present in real populations; in my lab
> we modify UniProt sequences and redistribute those modifications in
> publications all of the time.

Note that this text only says that if you modify things, you're required to
change the name.  In other words, they are protecting the terminology, so when
you use a certain code, everyone is always talking about the same thing.  This
is a very reasonable thing to require; without it, the database would be much
less useful.

> All of that said, because PDB and UniProt files are not works of
> authorship, they likely do not qualify for copyright protection in the
> US, so the licensing terms can largely be ignored. However, that may not
> be true of other jurisdictions.

The text that was quoted doesn't really talk about IP; it just says that it
isn't about that: as a user, you must find the license and abide by it.  This
is annoying (because it means you must find those licenses before you know if
you can use the data), but I don't blame them.

On the other hand, if you are correct (I have no idea about this data) that it
is not copyrightable, then you also don't need a license, so that solves that
problem.

The question would probably have been better asked on -legal though, so I'm
sending it there.  For those reading there without seeing the thread before, it
starts here: https://lists.debian.org/debian-devel/2016/03/msg00091.html

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW3kjSAAoJEJzRfVgHwHE6vUIP/2c9sCzBFH7L2muFotxeDFnB
9A3TRZbTfRX05Ik9FZyFSZr/zE/XEHA/aMogvEu1sB3Z1XpyEEx5Q+kvDiB4lqL7
6h5g5LTXWKIzdPDNciwCMSVqpBtPfuOJ11qEGPRZbsPVfXLjoSh+bjarSmYltun+
TlcpkOwcpSuevJI+BVxDKz5L59DcNqp/0Dh8kj2ek+dzDWmOiyJ1azqx6DptR3KB
uZ0gKi7LRsOjy6f6Q/bKs5Ym0it4CoVIBYuABAxFV6YsoP7qeUQqhd9gWqw9jAuV
6JTxnyLBwEZHJ640PAvTl/Q7W7+LL3aRQvqwCUfLUKtvAVywR5mBzTn5DrY0r8SO
ms0bftWq2DFezqctn8WYMvseIjkq4k2/Bt2e59dIi8d8ytj79dE5+raYl/cYYNUt
71shP7r+41zRb23ZguRVHcpOIBMu5UlhHpXR8PWhUhDF4mhnPDBXZGmvrZTTgVjy
iOHC3g7EtFg5NZTdMeeKs7NyKtT9ZLLDbwqiVmKSTPgIGywSyVLpR2X+5S0pek3C
ybtvSBifRQd8m/nhveQiQFAhNIpJHjFimdzTObKonKVAGAhag4TlvO9dak921CZK
TWii3txJnPmTMAaR/LGY8VjlcJjwN3J1UZTvB/0HTVGnLEUjSxtN0f6BQo1KXVSV
TDvMAD6wYUfdt9Ik9krj
=bzir
-END PGP SIGNATURE-

Re: HTTPS in DEP-5

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Mar 06, 2016 at 08:13:49PM +, Ben Hutchings wrote:
> On Sun, 2016-03-06 at 19:19 +0000, Bas Wijnen wrote:
> > On Sun, Mar 06, 2016 at 07:35:57PM +0100, Jakub Wilk wrote:
> > > 
> > > So, what we're going to do about it? I see the following options:
> > > 
> > > B) Fix the spec to allow the HTTPS URL; fix the HTTP-only consumers.
> > That.  Https is good for our users.  Even if the effect of this change is 
> > very
> > minor, we should show them that it should be the default everywhere.
> 
> The use of the 'http:' scheme in a format identifier has nothing to do
> with the protocol used to find information about the format.

I disagree.  While your statement is correct in terms of the file format, there
is more to it.  DEP-5 files are intended to be human readable.  This magic line
isn't only a token to detect that the format is used; it is also a link to the
format definition.

> You might as well advocate for changing the URLs used to identify XML
> namespaces to use the 'https:' scheme, and with the same effects on
> compatibility (negative) and security (none whatsoever).

When you follow those URLs, you see machine-readable files that may also be
semi-readable for humans.  Not something that is intended for human readers.
Those URLs really are just for defining the standards version; the DEP-5 line
is also a link to documentation.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW3KFfAAoJEJzRfVgHwHE61QAQAJ+TxXVLFUgZc/j7Lmxhkji1
8IQRqyYcRu1LQLN0szxd1uPNFNBxEQjuZs27yg/8GNTUXbGT6xazL0GWPLLz/iVr
XX+iBAz1Y1WnpbcCslr9GOCFK76gI2ogl7R0o5AJA2Lw+PXlAzB9AXdQWfm0Z9f6
GOTwqdox3SLvGhT3RdXtGMzfv4m0+uAiTLvPfWMqV9XlmqQTZM/kAvvGdc8iyz8u
5BEeZOw2bOPWPse3WSS4R+S5YpI2ULxghKS6YX3+7HuXkCKw/o8wtp2D5J1539jz
zAsWm83mTxzC6F9nBeC6cfLKZb7xYa4R6NsNIY74I2HQC4viw3iIwZA6QltaQBli
UGdiQX9wXEfIFLPKOPCiWW0TlAcGqthZHxj2ejykODSIoNP5PKoLc+u36gs2VwnJ
2YrAwzC4cj3neNNv0+fcmfyCBOedc3P9VCA/5C0oOpVNSAPKhYwjy8DQdCSq8uRN
MkgkbM+cJEJXP8aTWRf8ucFfWofk8aunn031ZRPYaGAXV/hKEtVQFOEsXDSj46a3
cu6bZIy2dcv7jPTblOwJYhEUwvux0+/A5nYFPa6WwjUEPR+aanMPS8nMe3nhMc/e
kwSbvZ6Ar0l3qp6s6BQxO9I1kZ9loh9beGzHa2zcoSnxy3efFoKs/546EX6FnWjB
41+9B6NF/Y9Bo2vjQ9V8
=H4vA
-END PGP SIGNATURE-

Re: HTTPS in DEP-5

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Mar 06, 2016 at 07:35:57PM +0100, Jakub Wilk wrote:
> So, what we're going to do about it? I see the following options:
> 
> B) Fix the spec to allow the HTTPS URL; fix the HTTP-only consumers.

That.  Https is good for our users.  Even if the effect of this change is very
minor, we should show them that it should be the default everywhere.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW3ILFAAoJEJzRfVgHwHE6yD4P+gKILYtBUBDGNuWThu73cO3B
bhNHbufa+x5hNVw2TiN2VQuJzlSxMGNBYk4Qnz54NG0+AbQklUmGBJy1sPX9Zx57
PM23D7Z3Mv6yPMobrHShb6sqFK3EJUmcglaTCJmyaA0U46gcb+xfGJ1fp/xCkJ+U
Ib99fejlSke//3gTbf20jBCFfTI6sjE4A6M//knt8SMMhkWBKXx1IardTIMV6jJp
I+87x3Ea5UzI2GotkN6WjJjYsOH3s8U1KTwrMP/IZPnie9HfUuW3QNAUlGC4ELbN
NOc3UQJl+2beGoVg/QrX9UEmsQY7YihwjFf98XSotqDrBkXSE9ZJCDyllNAP792D
/8XtV01wlTOYydt402QEhAb0Xh6JiSZ/CSchnO8H53EJZqtpGTsaxLUY9goSQLV+
big63PdIUM+Hvr2w4ZyhNlFolD8NOpEug/NXhlUh7kjureeFITj8u9qaxqNQIQ4o
J4N6ey7WbWb0MU3/n939Np5QHf5ad5L33DVpcYZU/dDYB6UeQDq1wJpbMp40gOOQ
tTucIWXdlTBSA4A4DRgv786A7yIqNpf03lgCDQ3pJ6E7lC7bwIwRb0J24zD0L6yW
JnD0IOFMdN5ZenvkXHPdOOproEjYe5T5ponYZ99VDMZf/8po8K7nt3RBXM2b4yMf
kRG04Jfv+N9SLoYsR5X0
=onUM
-END PGP SIGNATURE-

Re: Making Debian ports less burdensome

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On Fri, Feb 26, 2016 at 09:02:48PM +, Steven Chamberlain wrote:
> > Removing the package from the breaking port is an option, and it
> > should be easy to trigger, but it should not be automatic.  If we make
> > the process easy and the maintainer doesn't do it (and also doesn't
> > fix the bug), I think it is reasonable to auto-remove the package from
> > testing altogether (as we currently do).
> 
> I think the testing autoremoval thing started out the same way, it
> merely reported long-standing RC bugs, but removal was manual in the
> beginning.

Oh don't get me wrong, I'm all for doing things automatically.  The question is
what is done.  I agree with Ian on this: dropping an arch for a package should
not be automatic.  But I think it should be easy for the maintainer or porter
to trigger (so the release team doesn't have to spend time on it).

In short, when a build fails on an arch that used to work:
- - Auto-file an FTBFS bug to maintainer and porters.
- - With no response, auto-remove from testing.
- - With response, if requested, remove from arch.

That way the release team only needs to step in for core packages (which should
not be auto-removed, of course).

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW0Md9AAoJEJzRfVgHwHE6Vm0P/iaCViA36l3VQbOz9MwhfgxA
xxXgbKe4R91TK1vxAgdLXa3Nv68Q8pRSizDb8B3Jxm/fmZDF07FiCsZ0M3h1RxrF
Lsnh7rc/lHnRLauk+0TBQr8kPSFWAYu/eINPcZK9NWaLHHhBtTNMg6lxF41sbVkf
YBrDjcTAAH9fuxH73xg60+9hyQXSGq4eSxaqB6o8UoWz2DJXA1vhsvtyiWSPlLwc
wRTN0Ebmd+U1ptIBkbkGyKqGOR0IIwMmyzoPPSimnROvr2lZKA4UySuE4lW2MEzb
qjv8uQmfpGqNYZoMRi40fmva8A6h/lRt4GkxHodpsZE2BZnR6DNewYbRQuBPptxj
qbEtZKsQbSEm79KrLvpYV8IeYQcPltv8JHUpmutTiQjDpWP9USA2nZqIs0iL401J
tnZHPAJBvjnzZMJBabAAehkYXE8UdoRlvFbdH9lGLKdd+wv5gHLTyeJ7pxrSxD0J
iQ/7o/48jRiX8li0R93StIa1Vkrx8SiYL1lsepWRV+uifkuH4zynOKOGqU8guxua
H8J00GtI9utdnr0NCTXEl2C1lXNy+oqBcGYOVyDUHfJd3YnXooNT+PEl+nJ/CXLA
FC/VuYem1rczUGh4sHc4y5BIyZTEz8MYEKI6TJ5sorke2O6jwCbA0lwDFWLl7c7V
BH5SgRy97BdkkcEeQT1c
=xzj+
-END PGP SIGNATURE-

Re: How to deal with "assets" packages shadowing real upstream

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On Fri, Feb 26, 2016 at 07:59:29PM +0100, Jonas Smedegaard wrote:
> Do we favor tracking the true upstreams when packaging for Debian?

There was some discussion about this on the list recently, but this is a
question that didn't really come up, AFAIK.

IMO, there are two things that matter here:
1. We require source.  If the "fake" upstream does not provide that, it is
   certainly not adequate.  IIUC, this is your situation (but I didn't check
   your links).  That is: minified js is not source, and a project including it
   in its distribution is equivalent to a compiled project including a static
   library.  In both cases, the code must be packaged from its source, and the
   bundled version must be discarded.  This was discussed, and AFAIK what I
   wrote here is what most (but not all) people agreed with.

2. Needless forking is bad.  There is no consent on what is "needless" though.
   My point is that having multiple copies of a thing that are all treated as
   source leads to problems.  In Debian, we recognize that and one effect of
   that is that we don't want bundled libraries in packages.  In the greater
   free software community, not everyone sees it this way.  Having this opinion
   in Debian, I think we should use our influence to try to push upstreams the
   right way.  That means we should package real upstream if there are multiple
   sources to choose from.  Another reason for doing this is that future code
   duplication in Debian is automatically prevented.  In your example: if
   someone needs the serverside version of the package, they would package
   node-handlebars and then we have two versions of the code in Debian.  If the
   real upstream was used to begin with, that problem would have been avoided.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW0KSPAAoJEJzRfVgHwHE6ZxAQAJnB5S/kKeCJpdIWkyCPAdXe
zy4eiDlP7U4HCejSF991dWV+OD2KKn5wdQA26XpuJfd8v06qOVeEh3d3SQvbYXWP
oxlfpUo3iuWUXWgxuvphmJFEeZxHN/yavqLbu9vOGmfoyqHJq6osTu3/pxQnc9Ps
MU5jyvmbJqAypgB/zzfULz38fuiuyGB7OjDJSB+XkORJMJUVymDr/hrC6QBN2Vxi
l8OtoZcrLxjOuKVEimatnR/UAseMVODJ5LBsQ2Qrw5xSWE7MeGAGnxnikTW/nbuk
ThugoLcyOn2OWwyz8ziOl7mPfTyqxDHtbeA7gzmZO3ZXzctyeeLCbPZLcTRDg6pe
kQxYztIGPxoWABCaUCgkE/nc1L3Jd3zc74L9M71FdyxEx/dzRgWGD8MuWVoGocfN
oW83exDm6+gSkxGwR1b2QOemf8GO00HeKxVoy+p07r5Qbk6Y5bnRZvB9TMJqLHNF
X2x1isBp/Xon/4tWYQTUrHDwB4XoU/9JWFZ/S0b+dB00oaGU74iVsMxUwKqMp0p2
X69I7H99ISLY1pYXpbFtlFWPD33EbYva8pBbctf7XXN93eupQMX9JAl+lfXFh24U
ES4nCiJxMBTzHkAxS48jSTGFrBCh3NzfLjku5aY9LHZ2/DiBgmYpznC1SQIz2Ewe
a4r6eN722Hi6w3hXyjv8
=g6Xz
-END PGP SIGNATURE-

Re: Making Debian ports less burdensome

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I like your suggestions in general, but am a bit worried about the results of
this:

On Thu, Feb 25, 2016 at 05:41:57PM +, Steven Chamberlain wrote:
>   * If left unfixed, the bugs should trigger an auto-removal from
> unstable so that the package can migrate on the other arches.  It
> also means the FTBFS bugs can be downgraded to non-RC, and helps
> packages to get back into a releaseable state.  And it cleans up
> the archive, allowing old source packages to go away after
> transitions complete.

That would lead to ports with many missing packages too easily, I think.
Removing the package from the breaking port is an option, and it should be easy
to trigger, but it should not be automatic.  If we make the process easy and
the maintainer doesn't do it (and also doesn't fix the bug), I think it is
reasonable to auto-remove the package from testing altogether (as we currently
do).

Making it easy to remove a package from one arch can be done in several ways.
Depending on the problem, this information ("don't build this package") may
belong on the buildd or in the package.  If it belongs on the buildd, there
should be a blacklist there.  Maintainers should be able to edit those
blacklists, for example through control@b.d.o.  If it belongs in the package,
we could make it easier to specify Architecture: any-except-a+b+c.  The current
system AFAIK is to list all the architectures that do work, which means that
such a package needs to be modified when a new release arch is added.  That's
not good.  Perhaps a new header can be added, such as "Except-Architecture:
arm, armhf".

While we're at it, perhaps we can define some architecture groups for use in
that header, such as "32-bit", or "big-endian"?  Then the exception can target
architectures based on what breaks instead of just listing them.  Those groups
should also be usable in the Architecture: field.

Anyway, perhaps I'm going too far now.  My point in this discussion is that I
would like to make it easy for maintainers to make their package not build on
an architecture.  If they use that, the package should be auto-removed from
testing on that architecture, so the old version does not prevent migration of
the new version.  If they don't use it, the package should be removed from
testing entirely, just as it is now.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW0IvZAAoJEJzRfVgHwHE61qYP/Re+Dw5LGqd39VCCq/YGiJo7
q83CiJCsNauJWw9V7Y+tizw4h43SZ/CHrZp1Jhi2nU7W4b5dSZEYADpusEQEKfWV
5dqI4Us3fh595NWoRwR8s9UG8HnyvFl6Zt+5CScJLvtUCJXnY6IqNFoQXPz7AO+R
x7ht9SY8otkZ7NQBbvZpbtGnrX4TAwkpenAdYFLKpSxC6goQEbnlfeLxO2R8hDgD
E5g0M6SqGn/ClJ4Lnn10/r/9og3wBRBS+cIK/UsrhDtXrzbncq3ulXPZoznJxy4B
6W4OHjYr4im4QuhGPU2qiZP2VhBGjyi3s+Ds/oVlLZY+s8rtQHwy4PMXF8JjziNl
wdVpYR6H7+7sUHeeM2xH2hKi7Q84dJA0QlSGZdRy4yf5lnw9VH5BNs0NfeVltW0i
TmANygltxafQ4Z4wyiW+lx1R/JuuT9/0Q+5sFyczux+y/nJMKQf4LCSDV+TBXlbf
m+AcO4sLrBF7uOsVTwElw+n4+4rQ06RDzT8IP4sYW6MwOCNsjNzchbkEL5w1Y+KS
pcaI77LrqwwmQjC1MF/aCaeAXQNghRqfTpUkzmemnnjFm5KGSa6SyHI8DXYY+ox4
io7kEyBx6nAWgtQ8MUQ8S07DKvoSDKR/MSESeGqyfTEB4Ox1XFJT/hEX/eVrsCO9
MM4IhlyO5BkwSzE/lGWm
=VlPQ
-END PGP SIGNATURE-

Re: chromium disabling use of shared libs, BoringSSL

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks for pursuing this, Daniel, and for being civil while doing so.

On Tue, Feb 09, 2016 at 05:47:46PM +0100, Daniel Pocock wrote:
> Chromium upstream are keen to discourage use of shared libraries on the
> system and encourage packagers to bundle their own versions.

This looks bad.  But let me understand it: the sandbox they're talking about is
a restricted part of the program that refuses to use any shared libraries?
Would it work to statically link against the system library (as opposed to the
bundled one)?  As I understand it, they claim that what they bundle is
identical to upstream, so that should work?

Static linking isn't nice, but it's much better than using bundled libraries.
A statically linked package just needs to be binNMUd to get an update.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWuh97AAoJEJzRfVgHwHE6NjoP/RAKLWVsH3xbt+Dr7JoPVzk6
GN9lMNdrSI4jFtIL9xDyn743k4dd85Urt8q2PPOk6vJdRyBFiw6gJ3UWA+9+jHq0
dvpjLEynrFY1rQnlMG//nYypacg0jYi95h+U2uT2PHu6yjVgwgBVxbz0hb6tQlmC
i0z+hZ+W0WwIz7g9+PlbzQqQm6AmWL4t7yKC8u/l0+n84BwyI7G9DjOnmOsg9C7Z
VZVp81y9h/bWKv3c5+QlDWb37Mxa30AETXQAHeWJTfZ+plZNBRkY0nVPOroMEnAM
u2EOxKntzTHuFRtqEU1dk4nUWfhd+LJP2+10ditneq0VYac0Vhs8vHhnpLt5BBMg
44tkDPcBtb/OvIzN74knxT0I+N1bkFemvD/Te4b1EnM984nN1GATyLfMbF/tu2S8
Xny2nd7kAI3vD1RUyDgyWWzMwyS7NP8vmx9bZ6LTCxaVSH1j/NuJgJHW/3opdnch
4PXXBho2uz8tY2q3zqUy4LF1/ASX2WmYzyionN6Wx37g/NNhB1cZA3QLabL+Cgg0
x04v78p6ncekpBUWoCLBZI+EMacZIfbPTAJJPLNSXbb4AmYIvZ9wNufKv51nNGrY
sTf1Wy4Ad+nHJhUcHPpcehSBkc17EPYR4himPLX1+44Sfr5rCYezxHMDWwXba4la
ugxYBcMuM+ruiX326hOu
=DEmJ
-END PGP SIGNATURE-

Re: another mount issue on jessie

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Feb 09, 2016 at 10:38:26AM -0700, Sebastian Kuzminsky wrote:
> On another Jessie machine I had to apply the same workaround to some
> additional services.  I identified the services that needed the workaround
> by grepping for 'PrivateTmp' in /lib/systemd.

So any program that uses this option is broken?  Doesn't that mean we should
always disable it?  Is there a reason that it is ever enabled for anything?

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWujfyAAoJEJzRfVgHwHE6gH4P/ish9UZmNhBz6OcZ3RGkbSbO
BEP2m/5kDwY2Vqbdn/ZNY6MNSuD6nx3AuVqslpeuysyvq/0N+EeyLEuJ5bcuP16G
2oSryre1XnqakMbdt+dauop/3jD29e+TtEBzP1Gpd7gXgOEWPrXA3kh6maFusUU8
aGFLjE6ndtR447VgB6xTf21xdAFWsS/Jfrosc1PjJ98fmXATsCpfXqXp+uiVPuG+
dL52dFyq61SwV1jqB5no+l9qWPlCPodwMUZL92StiMYlQ6zmgyiLLRQSbmaoiJLE
CLn65gwitYmDKo19JvSOHeZcWWkWUeAT6n5WkbG0QQ60WqxCS0Zl+Otbj/dBEP+Y
NJqk+GvYdr708MC09eDZ7+dOPA3NpQLzdu3Af6CmOTt6WsZ7kJEX2+yIGVi3jNCr
PNX7P9uVE8FEhWUL/i1WlDVugYY7LbkOGRmn/YyuMZy8EHjHjzMvgg8oKqKFVjXi
4ABu8V9F5O4MsI41HRxKKhPJu8+DSCXeaKtkE/fqCzLu/3Oo6sjuViSjIcEmjWS2
f4M7i0JOM6EyaCk3AFujXfc9a66OiOondojcgPAZY1Wl6MENFyrLflR9NjN9dO1n
P2KwgrtbwW2vgZgfbwjyMMuU6Ek7voP5JTjiBDMBphniBUudOAkLx49eUd4M1me2
bSaaGs+9comFByXuoRBL
=ajY3
-END PGP SIGNATURE-

Re: Statically linked library in libdevel packages? (Was: Status of teem package (packaging moved from svn to git))

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Jan 29, 2016 at 06:03:26PM +0100, Dimitri John Ledkov wrote:
> Imho, if static libraries, are shipped we should be conservative about
> them (e.g. do it pretty much for libc only to compile minimal
> freestanding bootloaders and that's about it).
> 
> Or for example do split them into a separate link path, or separate
> package - since it would also require Built-Using stanzas. If one
> build-depends on static library package, and doesn't generate
> Built-Using something fishy is going on.
> 
> Anything leaf, or beyond minimal/core libraries, really has no need
> for static libraries. And definitely none of the TLS or crypto
> libraries.

We all agree that Debian packages should only use static libraries in
exceptional situations; a Linian check against using them would be useful (and
perhaps it already exists?)  The exceptional situations can use overrides.

But that doesn't mean we should prevent our users from using them.  Some want
to, and they have their reasons for it.  We should explain that shared
libraries are better in most cases, but if they aren't convinced, we should let
them do what they want.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWrCXyAAoJEJzRfVgHwHE6RRAQAJmUZnP7vU0J9Le9En8LWt3B
6cCtoKgbxRJlkLwjk2XE6Y5SZGblVBtNn4XgrrDCf2wz3QhbW6SQNfP+V77afG1l
QwgIYVT5gCnIXyY9E+keyUb8NKOO1IAI82NQJ4MnVFy80peqeHL2Yqj0GloFWv1x
xawoCJ2htX+lPXilXgqs87W9ZD3CpM9FzBAVxIrVy7Q7uecPgy19cK2SG9l+R1R/
eLD4OEgczOeI0wLdu9oQSm+/a5Jl07nFB7ABojBMVK23eYiXEqRTzsFxirHXJGyM
uygE6V7dlM0HT2IGAd9EGFg11x7SGrw+6Cfbg1tDXhBTAozGNYUgLJm9cGijxm8x
N22O4iclPjcc4JV/gwnycC3vD8Xs62qiq9jd2HL8JbnHd8w277OD/dhyBKUlAnSo
zJObXI7rQIyD1RAwe9pteir0edgVzbWaJJEXvmQAkj+jKGsKMw6586ZejWMombcm
6iTdUsmwQmlf5z5GnZ/VCJTkDI6d6+jf1tKoG3A93z1dPvE4m8lvJyzcmcsEnvhN
KP2LX77OPGo0DNpYuj9gaPtdhGGO3hRJnpjBVGZpjh8uXLiArUTGOVlb606w3/WK
cdYwKOkKrC3qlbtq5QiAyGm1fRXyG4DMfbyi5svWC9g5Ms+b5i2OyKAR3OM9Gnoo
YRuOmAuamUx3hmLU9S2n
=2S42
-END PGP SIGNATURE-

Re: Statically linked library in libdevel packages? (Was: Status of teem package (packaging moved from svn to git))

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jan 28, 2016 at 01:38:11PM +, Ian Jackson wrote:
> Andreas Tille writes ("Statically linked library in libdevel packages? (Was: 
> Status of teem package (packaging moved from svn to git))"):
> > I came across this question since policy says (see link above) that
> > static libraries are *usually* provided.  I do not question Mattia's
> > arguing but if his opinion might reflect a consensus the wording in
> > policy is IMHO wrong.
> > 
> > I stumbled upon the missing static library since d-shlibmove (from
> > d-shlibs package) is requiring this static library (since d-shlibs
> > is implementing library policy).  So if there is some consensus to
> > drop the static library I'd file a bug report against d-shlibs.
> 
> Static libraries are useful to users who want to build binaries and
> then ship them about without all the library clobber.  I don't know
> how much that happens but when it does happen it's probably people who
> are already having some kind of problem.

It doesn't have to be a problem.  I'm writing an OS for embedded systems and I
simply don't have a dynamic linker (yet).  I expect to be able to use Debian to
build software for it, which means I need static libraries.

> Overall I do think the costs of providing the static libraries, even
> where a shared library is also provided, are justifiable.

Agreed.  We obviously shouldn't drop shared libraries; static libraries are
extra, not a replacement.  The only reason I can see not to ship a static
library would be if for some reason it is hard to generate it.  It would still
be nice, but it may not be worth the effort.  This is very unusual, however;
AFAIK they are always built easily and just have to be installed into the
package.

The argument I see here ("people shouldn't use static libraries") is not
correct in all situation, and I don't think Debian should make it hard for
people who want to use them.  It shouldn't be the default (and it isn't), but
it should be easy.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWqi5XAAoJEJzRfVgHwHE6TxwP/0UB0fNj8Ib4wawab441NTML
JtFzATp/UXvZiKOUuD570d0ak4ja8uzB/fNCy572sJa3DyTTYH5LAIRO1NKmoSlP
NvCqRj293qKZE3JJQJYNIZmRChw8zHBGrxlvtYIIdvQ7695kW69WGGoGgnBMgRFI
GTr61XWhJkeND7nVYHVtT7ODEG4CQeek3PcF4I/PsBV6TaIv4OORXjrCwQhgm1Rm
rfxAjDrlsSnlfRRlGtKDTFES3Ir/FtCEfr2qOqZxd39WY5u/KDxgXQsI7FJMne0+
Z+O4HuWMKkEemtEIkeXv4orUczQeX83Sq8HnaxHWQ9lfaTr0JeeZZ1hWDjtt5uIT
0knXhblr9r6QczbQFotbqPXnSluM6sP4q6UFb8uxkfIyAkYa73b4DxDMTTYnPPC/
AtsG89rPa4jm13mis56Tga2rciLEthuWP3xj4+MuffnTF0OCq4AffbVe4LrndV78
sejIMA2nSRBsiDD8v0fikbCW0WetFB9fRVh/h3DZaGx5/JKxhc8IbR2dTZ9d1H+9
916kIqs05CdGFlHr845oJHaHJvc8+2ioOI0S9H0gKKPLAgSQvS9pHu7zondyKP8Q
7H71OL1Ju6ulVKgBd/7WmuEXcOVZHeWBF1RIoewwfDyaaHLUGMP3bq0TXuiYkI7v
06uA6NkIrzzwzfkHqs5t
=PRGv
-END PGP SIGNATURE-

Re: Libre graphics could become the standard if we push right now

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Jan 19, 2016 at 06:57:43PM +0100, gaffa wrote:
> It's an MIT license:
> 
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/firmware/WHENCE#n758

That's a fine license as far as the DFSG is concerned, but as long as they
don't provide source, it's still not free software.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWnoq/AAoJEJzRfVgHwHE6gTgP/jDl77EqRRPczNxTuMI9CJnF
14+aHHq3qVnjaBtKtjgPDL/7NIc6o4jQCjFJZ4q9zhkoHmE07JUdyN8a5B5tkGL2
xM/Ri4UAReYaTTOsN71zNxp3q5vzSp9KFySs3fiFHKL1ANjg93qfG6Z4XRIyjEjk
4dGnn8ZMsRSKFZyLRIPMB75wGGcDzwwOtCC+PX5GQtlbqnCpaG5ODDeQwga6beu2
8AYKIHGP0VNd2u6oV/eLU+8j2fBzWpXY9Ns2SBNTH3i+SGTf9phr/8ZnyMGFkJaM
Nkj3KP/aoXPtG9IiodDW7M78VWtl3ctYi82w/6tDIL7fGHiA5xi2Mn29AcgP8O7f
MSr9AOSn4cBbHXnusyuQCGk9AlDxVEa9BB/1jjXwhQxhrtKUSvtKlok+GZoCwTh2
bY6g0iJOxR0KsOV50BU04LAoq6jrI1aLPysaygEg/WE36x4FTl0Gf09jmH8xrl9y
uAP2DjaIdlDLd3GUXc281ISi7T8MsojB5DJ9aOG1WDgN2JxDD2TltIaNDb5EoebL
2ejMROdAwG1QhCYCXzPpU5OV7J0VdXXsE/OUUV6yefUYkF2irK/cZQmqtd5wH4H/
qShClr4iiTRcPDhdrRtXyB471cadgTc1KHp5tMrdWJMydy/V2O3XwuXPRrEcEf4Z
MbDHHsf4aZ7gTh0fWmyA
=ZbHh
-END PGP SIGNATURE-

Re: support for merged /usr in Debian

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Jan 16, 2016 at 04:09:00PM +0100, Marc Haber wrote:
> It would help to be friendly to each other. No CoC needed by that,
> it's just basic common sense.

The meaning of "friendly" and "common sense" is different for different people.
If you write down what you mean by that, it's called a CoC.  If you use it as a
guideline, and not a stick to beat with, it is exactly what you ask for.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWmmHXAAoJEJzRfVgHwHE6E0cQAIKVkbk+jucSMCHj7fuhGRRb
VoS8lM0xDsMnh5pA3aVPtROXI8XTJOyGIRikr6g1q/vFJtEhDvkSIbJD9m2WfmXk
h2qXSAeXbR+xEZLPI3UlqL/8PvoNhczOQ09xKD5rqncL2KyRfSSWQQe53KN6l9MI
fMXwChpO8yzC29nn5KnMr8eSPjlhK+spOTZNj50YVZW6J6DkGvTQ8y8yHn0aDclp
iL8yKle1wKH981gJgMl3iUOWm/FLXUXQDknysapvXVN2T4R/rPiW+SVm080BKadh
Jy+JfTR0BKPfq2QZ0DJbuG6HWvmHCqZPJ6dbuxFnIqEgYsZOJglJQZD4CDGoQ/mQ
zWI9DkAYYf6CTLvhn6DVuw9vXxUHYhg4i//8vMMc0V5gloF5rVnhef8hLZtMIDnb
mUN5FH7qAQiNfq+CCAYDN3EzkPVKEc2s1Ce8qRDN1TN6Jn+YnXYjxKce2oysx8d6
sb9cSmS7YOlvpo73at3PKZGFvlu41j5Sc2irspESGR2Onyt1jlgkemAsi7a01u7m
cO3wXuiKJgth0DNgKpRIPTK0bciYX9zq2rYKsSfYCoVDkXU/gdEtLmQqjciPUJuH
we6ptGhDjUv7GIYr3Tpny6IUmVO5AnA1T2tF5T0BTcSgRpmsOnpRW3TrDhHDD2Sf
E1WwGO9UJ8cevTy0RLeT
=VTdd
-END PGP SIGNATURE-

Defaults and virtual package rules (was: default softphone in Debian stretch)

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Jan 16, 2016 at 01:48:46PM +0100, Daniel Pocock wrote:
> On 15/01/16 14:20, Bas Wijnen wrote:
> > On Fri, Jan 15, 2016 at 11:08:35AM +0100, Daniel Pocock wrote:
> >> On 15/01/16 04:00, Paul Wise wrote:
> >>> On Tue, Jan 12, 2016 at 5:42 PM, Daniel Pocock wrote:
> >>> 
> >>>> default softphone in Debian[1]
> >>> 
> >>> It should be up to the user what communications tools they want
> >>> to use and or have installed (if any), that is none of our
> >>> business, other than perhaps informing them of the security
> >>> properties of what is available and or providing the default
> >>> upstream tool choices via metapackages where available.
> > 
> > I strongly disagree.  Users should be able to choose, and we should
> > not force one option on them.  But users should not be forced to
> > choose.  A major feature of using a distribution is that you don't
> > need to choose individual programs to install, but get a well
> > functioning system.
> > 
> > Don't confuse the freedom to choose with the obligation to choose.
> > Freedom is good, and so is having good defaults.
> 
> Yes, I wasn't insisting that every user should be forced to install
> something or even worse, forcing users to create a SIP or XMPP account
> in some designated service provider.

I wasn't disagreeing with you, but with Paul.  AIUI, he wants to force users to
choose which softphone they want.  I understand the resistance against forcing
users to install one softphone and not allowing them to use any other.  But
that doesn't mean there shouldn't be a default.  If a user wants a softphone
and doesn't care which, they should be getting a good default.

In short, if a user wants a softphone, Paul says: we give the options and they
_must_ study those options and choose one.  I say: we give them one that works
well, plus a list of options.  They can ignore the list of options if they
don't care about it, or use it to get exactly what they want if they do care.

> Making it as easy as possible for those who do want such things and
> helping them make a good choice on their first attempt are the things
> I'm concerned with.

I almost agree.  On their first attempt, I don't want to help them make a good
choice; I want to make the choice for them.  Unless they want to choose
themselves, of course; I'm not saying we should stop that.  But I think most
people just want it to work.  They don't care what the program is called, and
they don't want to spend their time on choosing one.

> >> I think there should be a threshold.  Failing to meet that should
> >> be ground for an RC bug.  In other words, the package can be in
> >> unstable, but not in testing (or stable).
> >
> > Is this approach used in a formal manner with any other sets of
> > packages, meta-packages or tags in Debian?
> 
> No, I don't think we have some sort of "quality" level for providing a
> virtual package.  Just take a look at www-browser which is provided by
> packages not getting any security updates at all or implementing SSL in
> very broken ways (I remember reading about browsers that would just
> accept any certificate silently).

Perhaps it would be good to allow virtual packages to have a description where
they can specify rules that providers must follow in order to be allowed to
provide it.  And in some cases, it may be possible to run automated tests (if
one of the rules is to implement some protocol).  This could be implemented by
creating a package that is used as a Build-Depends, which adds the virtual
package to the Depends of selected packages through substvars.  Lintian can
check that packages don't have hardcoded Depends on the virtual packages.

Would this be useful for more virtual packages, or not?

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWmlsEAAoJEJzRfVgHwHE6vH8QAJ1PDeJ6/R5Yoh0S661eDlvP
TwqwLQqABMRnnUKi1+MYHNTUfxT13hbfSVcymEvlQJ9xQvYAE8H6DUKr43eyzOmJ
d0UBNOc9HI/5rx9A2nyY9Pz7u09StLzy1btD1rZUa9LaCzZm2WAj0HtWSpsH27yq
tOAB9nObLj01ZOANotP6VpIX2lUm2G85ROGgivv4pkhDVEAzgzPX1mRTOrYX/y2E
FPtdcdanWrqKgQuIgxhQAkzcOk4ylnU4DOqdSlHgwWlaQ/KJVG95awqI1D83DqbZ
EyKsezbD6rV6k9+FuGgb6xou6/xPxNM8e0ogZwWSOiuz0GdV9ap5P1tTUtO71iqu
jsDndRFFoOKhbGuCHYAqYLEToOxKbgGlc8nKm7b2GzxqefJVkcoP8UdZZFNNqEr3
Y0lNFbSYdwjMGalMbsEt2hpizUQDOZLi6FMC42TRGlqLycPg9fg5GTR4dzdamtj+
ZfYjLu/zw+562fWJqyJZLFEBkIyZIIuAhXcQwLZSh9+1OYfeLwgmZgIx2bjvkKkL
zohrbHLtc3ozQAV1SKCMUSRkzAQQguq2MxGu7+8D4EYShj8uNGA2hoZbTu6iPKLM
XE1Ef+ceg+j9ji9DifRILV6TaIGv2thl1TqAijjTBAgGSWQhv3srejchvCHYwxe0
jxMPCZfwt+Et43WEx8OV
=8mga
-END PGP SIGNATURE-

Re: default softphone in Debian stretch

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Jan 15, 2016 at 11:08:35AM +0100, Daniel Pocock wrote:
> 
> 
> On 15/01/16 04:00, Paul Wise wrote:
> > On Tue, Jan 12, 2016 at 5:42 PM, Daniel Pocock wrote:
> > 
> >> default softphone in Debian[1]
> > 
> > It should be up to the user what communications tools they want to use
> > and or have installed (if any), that is none of our business, other
> > than perhaps informing them of the security properties of what is
> > available and or providing the default upstream tool choices via
> > metapackages where available.

I strongly disagree.  Users should be able to choose, and we should not force
one option on them.  But users should not be forced to choose.  A major feature
of using a distribution is that you don't need to choose individual programs to
install, but get a well functioning system.

Don't confuse the freedom to choose with the obligation to choose.  Freedom is
good, and so is having good defaults.

> If there are meta-packages (e.g. sip-client, xmpp-client), should any
> softphone be able to assert that it provides sip-client?  Or should
> there be some quality threshold?

I think there should be a threshold.  Failing to meet that should be ground for
an RC bug.  In other words, the package can be in unstable, but not in testing
(or stable).

> For example, WebRTC browsers must officially support G.711 and Opus
> codecs.  Many softphones don't support Opus yet.  Should we say that
> support for Opus is mandatory for any package that provides sip-client
> or xmpp-client and any package that falls short has to remove the
> Provides line from debian/control or be hit with an RC bug?

Yes, that sounds reasonable.  If a package Depends: sip-client, things are
expected to work well.

> Using some threshold for quality and interoperability will help the
> majority of users to choose from the more desirable softphones, but no
> softphone would be excluded from the distribution.

Also, an RC bug is not always a problem.  If a maintainer believes that it is
useful to have a work in progress program in Debian, it can be in unstable,
with an RC bug to prevent it from entering testing.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWmPIrAAoJEJzRfVgHwHE6ZpMP/0/EEjPpfCBTu479xUqDMZFr
g3/7qjPVUhD7DI6SIez55Rav8YC7UiS+khwb4emlmT/olk18nfdpYEVwhkniv4vN
pxDE8YerOUAqs3ZqicbhwsNx1SRw+rHnurJfJFUEldw5+M1hnLTnSZ3NCpoS1IUI
06VLw6yuKa2udwaP+JpXyBVrRceRXWti9gU5xHCO2VgsDol6ug1jHWGZq8tugPqL
QLBeWzswFszAhSp81SIY8Ez9DvIIXBrQrVzUCUly/yaSAzOHUi5hD88KHaMSZrzt
DLx8yAVM6iG4fVYD7f6VzRTCl55YMKJIU2XuH19efI94/5WEZTumPEL19RrRe+8u
Bo+xzlFd346skNp+cT8ytHyGlXHUQCbPp9GxAPMbNeoal/DF7zFgTudDcNPnyPb4
cJOnUfhFbfekr3l3ETfwMyuf0Awv2SGmY2XaS5mqxdMNuRsCWbGp0AJTI7nR4Lil
wAeZW1HWS2cE0r3cd3Te99O7jC6loDgPXAb/BrWLSEBpR2TqXzBEnR6q712JezMK
pkoelAiFaJ3DKtx4ONp/hyC5D6Zr2u1j83dGACZamlzfJ3UFTqVfHsuNu2f/VPjA
Q2Y5vtjBE3IyS2FZX8K2Y3t2FTmuhHKhGiUh44opkgyH5kOh4ATBHEwp2VtOP4eI
2qQfoqbIzezKrYmeYOgx
=iUqi
-END PGP SIGNATURE-

Re: Going ahead with non-free-firmware

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Jan 10, 2016 at 02:09:24AM +0100, Philippe Cerfon wrote:
> On Sun, Jan 10, 2016 at 1:11 AM, Josh Triplett  wrote:
> > They will if people care as much about that separation as they do about
> > separating firmware.
> 
> Which effectively still means, that it won't happen for exactly those
> reasons I gave you before.

No, it's for the reason I gave: we're not anywhere near a consensus on what
would be good sections for a further split of the archive.  Everyone wants
something different.  You suggest that your split is supported by everyone, but
it isn't.  Many people don't care, some will even be opposed to it.  The same
is true for several other splits that some people might like to see (for
example "violates privacy", "intentionally crippled", or "contains
advertising").

You may wonder why firmware is so special that it does deserve a section right
now.  That's simple: at the moment, users with the "wrong" hardware need to
enable all of non-free if they want to install Debian.  There is a big
difference between someone saying "if I can't use this non-free program, I
don't want to use Debian" and "without this firmware, I am technically
incapable of using Debian".  The former we want to give an incentive to change
their mind, the latter is objectively correct and we can't do anything to
change it.

Your point is that some non-free things are not as bad as others.  This is
true.  However, there is no consensus on what is and what isn't "too much".
The only split on which we agree is free vs non-free.

And not only is there disagreement on which sections would be useful, the
options are also overlapping.  This means that a tag system is better than a
section system to solve this problem.  Just to be clear: the problem is that
people may want to install some software from non-free, but only if it follows
certain rules.  What those rules are is different for different people.  Your
preference is clear, but not shared by everyone.

If you think this is important and want to work on it, I suggest to do it in a
way that results in maximum support from others.  That means you shouldn't just
support the split you want, but other splits as well.  As I wrote, tags seem to
be the way to go.  What you would need to do:
- - Add debtags to differentiate the groups.
- - Patch apt to be able to use debtags filters, so the "wrong" packages will
  never be shown.

I think you should be able to find some people who want this as well, so you
don't have to do this alone.  Personally, I'm content with just non-free
(except for firmware), so I'm not going to work on this.

> - The name could be confusing, followed by some strange discussion of
> what open/free is.

This "strange discussion" is quite relevant however.  It demonstrates that
there is no agreement on how to split the archive.

> - That potentially other wishes for more non-free/* or non-open/*
> arise, which is however purely speculative as of now.

No, in the previous discussion several options came up.  There is no consensus.

> So let me perhaps ask more directly again:
> 1: Does Debian assume, that software for which the sources aren't
> publicly available can be generally trusted?

Debian doesn't have a shared opinion about that.  It's not about trust.  Debian
wants to make an operating system that is 100% free.  That is what the DFSG is
about, and that's the only thing we all agree on.

(Also, your next question assumes that saying "I don't trust things without
sources" implies "I do trust things with sources", which is incorrect.)

> If not:
> 
> 2: What would be the big disadvantages of allowing users to opt-in to
> software that is currently in "non-free" and has sources available,
> but opt-out of software which is currently in "non-free" as well, but
> doesn't have sources available (like for example steam)?

I don't like it personally, because it tells people "you can use some of
non-free, this part isn't so bad".  I prefer to send the message that free
software is what they should want to use.  That also gives authors more
incentive to choose a really free license (as opposed to "It'll get into the
almost-free section of Debian, which is good enough for me").

This is very personal though; others will have different opinions on this.
Again, there is no consensus.

> If none:
> 
> 3: What seems bad about the idea to solve this opt-in/opt-out via a
> suite like "non-free", "contrib", "main" (or are these called "archive
> areas" and not "suite"), especially when one considers the big
> advantage of that solution, namely that such software would then not
> even show up in the system?

They are called sections.  Suites are stable, testing, unstable.

The bad part is that this is very specific to the split you like, while others
want a different split.  A solution that would fix all of them at once would be
better.

> If nothing:
> 
> 4: Does it seam feasible to find a name for 

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote:
> Philippe Cerfon:
> > On Sun, Jan 3, 2016 at 7:35 AM, Christian PERRIER  
> > wrote:
> >> Discussing infrastructure changes like what you're proposing (which I
> >> have no advice about) should usually be done through our mailing
> >> lists,
> > Which one would be the appropriate list?

debian-project, or hopefully debian-devel.  -project for talking about the
idea, -devel for discussing an implementation.  Having an implementation ready
hugely improves chances of it being done.  But of course probing the community
to see if there are any protests (as you are doing now) is a good idea.

> Your second item has been brought up before with different
> focus/rationale/purpose.  At least I remember there being an interest in
> splitting "non-free" into "non-free/firmware" vs. various other non-free
> sub components.
> 
> Mind you, its primary goal was not to address "source vs. no-source",
> but it is the closest related idea I could think of.  Sadly, I don't
> have a reference ready to backup my memory.

Yes; I think the conclusion of that discussion was two things:
1. Different people want different splits.  Using something like debtags may be
   more useful, so users can block their own tag selection.
2. The firmware category is special in that pretty much everyone needs it, so
   we may want to make that its own section the old way.  This allows people to
   use their hardware without enabling any (other) non-free sections and
   without worrying about debtags filters (once implemented).

Note that it was just my impression that there was consensus on this; I may be
mistaken.

Note also that nothing has happened (AFAIK) since that discussion.  Someone
implementing things would be very welcome as far as I'm concerned.

> On your first item, I would have to agree with Christian.  It is not
> actionable and much less by Debian.  At best we could stop packaging
> such software or disabling such features, but both have their disadvantages:
> 
>  * Even if we stop shipping them, people will still download them.
>Except your average user will probably be worse off because most of
>them do not verify their downloads.

I agree that not shipping things (that we are allowed to ship) is a bad idea
most of the time (except if it's because nobody considers it a priority; giving
upstream an incentive to release their software under a free license is good).
The exception is software that actively hurts the user (malware, spyware).
Which we can only block if we know about it, of course.

>  * If we disable the functionality, we would "cripple" the software to
>many people.  If this annoys people, we will end up in a situation
>where people will advise /against/ using the Debian package because
>it is "crippled", which leads to the situation above.  Or we could
>get badly unpopular with upstream (see the "Debian vs. Ruby" issue
>from a couple of years ago).

This is a valid concern, but it shouldn't always be the deciding factor.  Many
people (including me) use Debian because it easily allows installing a 100%
free system with a huge choice of packages.  If the choice is "move a thing to
non-free, or keep it in main and disable the functionality", those people will
lose the software completely if it's moved to non-free.

Disabling functionality is work, and when it's done, it's done for this group.
It leads to "crippled" packages and the complaints you mention, but the
alternative is moving it to non-free, which leads to the software missing from
Debian main entirely.  Either option may be better, depending on the situation.
Perhaps it's best to do both, like unrar does (AFAIK): package a "crippled"
version in main, and the original version in non-free.  But this is even more
work, and the maintainer has to decide if it's worth their time.

Personally, I don't care much for non-free, so I would choose between disabling
the functionality and not packaging the software at all.  But that doesn't mean
everyone has to work that way; if others want to spend their time on non-free
packages, I'm not stopping them.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWijfHAAoJEJzRfVgHwHE6J7gP/izcwZPCJ9YvtpDf9FNtDKmA
7Vop3e1wZD2h7G93FY/YvQkufkFQhW9KJp3cIZ2UkCDq6EBt5Of6xtoDEtSWmedV
Hi4djop7nIXJxFnzB2/5wMYVLa+DIeRUUhtR8/HkQu2/GCbf1SIbOH3ZjH2SW0Kj
BozkqzyQQkFv7t/GK9y34goW6l4oc0CF+vINlRV+iV886C0166Kim1rOBWM8Ctfq
JrP9JcfwVBFIVzznK2+6E4/0bCLT1AeRORyfpwIW/QI0+3wmjoECdmA2PRrtTxgD
vy1ZNEfAY+BxYIo4XJsSQpE4VTgtYMmnYDuP4IWx9NUlYKVA3jWwjdn4FSim5fRl
BqWk9tdY4zmM62WGkqLexwSgeyx2Ozh+zh9Cf4TIVRK5OXmUK3E2VUCA9CvE87pw
Dayw3F7ZJX0N5Tpal55DDcBEVHOFFmLgfqHHy80HEM1rgQnwbQE9Z0CrRckhDjIK
jQkCaZynCSknB/5iG7eL1U4UiLySmrxNYqCbuU7T5gEY6SABghwCdcFyCwtRttXC
Q/4H5bXDw7E/PszsSvaUDe39NsDS9xBDbpgSZ/OhylkhimhwUhtixWaNBCDzC9Tw
SLgQaW8TYrAClRzKM+JRBSJM8hTX1R3+CsnS1wVy3em6BRohFO/I8uq+kZZ5007S

Accepted openmsx 0.12.0-1 (source all amd64) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 06 Oct 2015 09:09:16 -0400
Source: openmsx
Binary: openmsx openmsx-data
Architecture: source all amd64
Version: 0.12.0-1
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen <wij...@debian.org>
Changed-By: Bas Wijnen <wij...@debian.org>
Description:
 openmsx- MSX emulator that aims for perfection
 openmsx-data - datafiles for openMSX, an MSX emulator
Changes:
 openmsx (0.12.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Update debian/watch and debian/copyright to reflect move to github.
   * Update homepage in debian/control.
Checksums-Sha1:
 3216832399244fd11d697046a3df64c8afc2ac26 1989 openmsx_0.12.0-1.dsc
 45ac624b0da03a4529d3cdb30d2f0e7eddc0ae5a 4927702 openmsx_0.12.0.orig.tar.gz
 a85ef6f92b2a9a24d0dbe1ac9748490ad9f9e80f 9884 openmsx_0.12.0-1.debian.tar.xz
 2b18b037258b061daadc5eaa349b24102b7d4ed3 1342876 openmsx-data_0.12.0-1_all.deb
 031754638ad57c1a1aff486196a6a9db376b0cd7 1654676 openmsx_0.12.0-1_amd64.deb
Checksums-Sha256:
 e4cda2cd4dba9498ea57835b6c06176cdec94a3c7603c054fa5dbde763870aff 1989 
openmsx_0.12.0-1.dsc
 c9cc015316a59712c0921936f6e2084363c3d59a90be8cbebd607dd1cc2dd641 4927702 
openmsx_0.12.0.orig.tar.gz
 1b3b456472e00bef2ee2d536b31de224701fd8baf18659c0cb54d0f4161c1962 9884 
openmsx_0.12.0-1.debian.tar.xz
 7b48c27f9c1a6ebbbd58795e6111043f73e398674e868e6fd9c5c14a4a6619ef 1342876 
openmsx-data_0.12.0-1_all.deb
 5f4eee1eab717f6769e3fad9961dfc737f36896f21e810a13e55bc2b0038d5bd 1654676 
openmsx_0.12.0-1_amd64.deb
Files:
 b109a7b1571c4733eb4ed3f192b4e7cb 1989 otherosfs optional openmsx_0.12.0-1.dsc
 ab9d7e9b3d662e89b412ee00cdc19d17 4927702 otherosfs optional 
openmsx_0.12.0.orig.tar.gz
 f9731b895bf5ae682ab53fd1ea268c3c 9884 otherosfs optional 
openmsx_0.12.0-1.debian.tar.xz
 69530b369780ffa041f3a16b317a53f0 1342876 otherosfs optional 
openmsx-data_0.12.0-1_all.deb
 88bb6451c1632eab41dda754853cb2ce 1654676 otherosfs optional 
openmsx_0.12.0-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWFGE/AAoJEJzRfVgHwHE60SYQAIwLJHol/b7BAH70pxxf3v3J
jQroU6vSblG4wvYt5LQD1qhGv+X+h9Uax1hlxlgtiENVUU6I3O75336nyRMmReW7
tulAb9/ss7xTtrRsvhGjH9tdweu7lRZHVct/UnXu/JMi1z6kw8UQ+bjMwpIzL/u5
2QrUUXWxddDPK4cj3Pb5W/HJ56Th4/NTYO5G+/7e5xH9aseYrtVjZ35OAvZH1hrv
HnQtdqPdwd9skiHN8hi5Fq5Qel9q0s06ESnJXq7VuloLS1QaciaBKN4ipb6iG+iv
tkF5fM1j7opuGN1vLa0P3fsn8YZMH5hLbKStXFKgsFm+QW5+yNVgedRoUz24mXRr
2u9UnnY25s/G3gOQukkV0+gFxvwvFnppmZC37QkiIj1qfGTk+lX+rUcf9JypAdL2
qM8okqEPZYlfV3C5xIzu0BvV7CuNmhItvs45oZ+pkLSl8n+4iBGIWJAtzV1KjS1Z
Mikhs1cY+zeIL7UDg44D/kQ+zHu3PNnL5MbJKhYHvuAjE4oYeJ5c2QFdpJo/RW3l
Tw5gkG3zQAKThd3LpKdNHZBJQWyQqJ/3qkYWtvZTvvB8FdmJuoBYWkOOoAmTn3Hy
GRzSQUzuvg9DwU85cxsc7C4R4RXzAkvU6eLCvYQ6kSQ1YpgIZcCxS/6AMCTudl7m
MInl4wQmLRRdwjrg/Hzr
=Ya6b
-END PGP SIGNATURE-

Accepted openmsx-catapult 0.12.0-1 (source amd64) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 06 Oct 2015 09:06:08 -0400
Source: openmsx-catapult
Binary: openmsx-catapult
Architecture: source amd64
Version: 0.12.0-1
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen <wij...@debian.org>
Changed-By: Bas Wijnen <wij...@debian.org>
Description:
 openmsx-catapult - GUI for openMSX
Changes:
 openmsx-catapult (0.12.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Update debian/watch and debian/copyright to reflect move to github.
   * Update homepage in debian/control.
Checksums-Sha1:
 98631090337004563e88ad3997c441eabeb8c948 1812 openmsx-catapult_0.12.0-1.dsc
 0c242d45ae0de4573bebfac6e5be56db51682cfc 1486380 
openmsx-catapult_0.12.0.orig.tar.gz
 8ce285ef85574d839ede6d4d7dde523e288c183f 9088 
openmsx-catapult_0.12.0-1.debian.tar.xz
 de1c14745e9076df92448006842ff6f8f14bc69d 387264 
openmsx-catapult_0.12.0-1_amd64.deb
Checksums-Sha256:
 faa3657df22301d1f980dad30f2783e186fb288f53f08dca60755b2ce485f9cb 1812 
openmsx-catapult_0.12.0-1.dsc
 3a58f6f9890b5d687daf5acda39b7bbd4a44736a1cad3c62fed6ecc4c971 1486380 
openmsx-catapult_0.12.0.orig.tar.gz
 51649ef370b734f390dd3431788e95dc4fda3ad3e35f3ea043150b0fa8381772 9088 
openmsx-catapult_0.12.0-1.debian.tar.xz
 0d78f79c1ad439c10d371bbeba505d2331b1ce4fe381b8b2e9cc934b54b78ca1 387264 
openmsx-catapult_0.12.0-1_amd64.deb
Files:
 246884e032a407a6b5ebd6ed30883a1a 1812 otherosfs optional 
openmsx-catapult_0.12.0-1.dsc
 ea11f459a2d40ad7977a10e783421af5 1486380 otherosfs optional 
openmsx-catapult_0.12.0.orig.tar.gz
 d1fd3fbf096aa84527a4afc7f6b05b6a 9088 otherosfs optional 
openmsx-catapult_0.12.0-1.debian.tar.xz
 b4ded22290939e023f6461d6e0ab8eec 387264 otherosfs optional 
openmsx-catapult_0.12.0-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWE8iNAAoJEJzRfVgHwHE6v/wQAJR1jeyuFkAK9M85RzxKU2fb
lNDS1Q9g0Y5y0RX6746bHF3payppDxScGwdltvDFQozbxgslV1wAub/475uQ2VqN
OfcMe/jHDk5Jn0TWvVHijtqe2NLsGoZAx0UMFOgVcbmoUXH5GmwUkI90ccHoIX/e
QdPJSKESEe7N+r1P4OnNnO/fFxvXDRvwwh0zQLZBwYs0hWCZK5bhx3shQksTKdud
hpUTqi4uib6sLibwGVoQM47c3KkIVAsNt+pArPUwILoYOoorjOXazv0E8RnUBPcJ
9HDXyu6aXUhrjqyH6uNGTRDJAm9VaKL7dYas5SYwKqHGQBcJ5Ax0aWm/caAunpcC
NKH8odt7XtOPJYoQzK5w0HKb1iFs44TyrCAaIiAmmu/vHbc+AKjbUOuIDDHZjzgB
rwwUkqGVe6r7NoJoBwl1Bo/qBXClt8QF2yM1PGUmH+3x932bke6LuRwRrbwcfAqp
dccB+EC8wSQkVsD/W6fK5Rb06pvAM1CxXbmS8JohWn61n3/rgDKrMqyMoxbrlV18
IpiHGCyEUSU6liqUo1McXY4SCqbh1KtAl4FyQsPMeMP1tG3L3PiypPOuUeHMOAMq
JOnpna2dlxwsm9Nnt+J2CmO3OglbgjyvZnWwPUTIf8/TRChImhj223yaah0npQ1g
dpcx2alUgKHjLrfcpb7H
=N0qs
-END PGP SIGNATURE-

Re: Security concerns with minified javascript code

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Sep 03, 2015 at 08:47:11AM +0200, Vincent Bernat wrote:
> Without minification, we'll just ship packages that people won't
> use. Why would I run a crippled installation of Wordpress that will
> drive of part of my users to another competitor?

Because you know you have the right and the ability to be a part of the free
software community that created the software.  That is why you are running
Debian and don't have contrib or non-free in your sources.list.

- From your mails it is clear that you don't care much about that.  That is 
fine.
I recommend that you do put contrib and non-free in your sources.list.  You'll
get all the non-crippled programs that we ship, but there's no guarantee that
you will be able to get the source, or compile it if you can get it.

To keep all our users happy, not just the ones who want contrib and non-free
enabled, please put things that people like me don't want to see in there, not
in main.  (Of course, fixing the problem is even better, but if you're not
willing to do that work, then at least don't put the software in main.)

> We don't turn C into an interpreted language because it would be easier
> to inspect the resulting binaries.

We do remove non-free content (or things that need non-main content) from
upstream sources and I'm sure some people consider that crippling as well.
There are two options: they are the maintainer and really like the stuff: they
can package it for contrib or non-free.  They are not: they can go use a
distribution that doesn't care as much about freedom as Debian does.

There is also a non-option: they break the rules we have set up for main, with
the excuse that otherwise our users would be unhappy.  That is what you
suggest.  We don't do that.  People who don't like our rules shouldn't be using
Debian.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV6IHpAAoJEJzRfVgHwHE6zHoP/38VNuzOKVDbCeZCpvOBItJh
EFCTkNBxQTBCmTrj7JArMYN1CKUVkkb+qKMLex2xxjfPIdydTeT+bOYHIBIWBNHm
a2ZNEN+0zg5cxte3D8m54YYFBfbaKuFPE9/jqkSWkWAIBjt9p84G663q5S8o6P4X
dqwLTvOjVgPc0BZ6j6Bo7s8BQiFW/UBIyMgsN32HlLhRyYOG7TErkOwdSmFqq6tw
GZEh9GMvRAw/3yTPVoZsJ9RyWKP5TpTRuGZe69CAaTmWDRtuq33O4JSzhmW+hdd7
T8jSAhrhpVe92AGo8qZodF/WLU61J4LbpLg42r9xhmKVu/OkrC7NdHhKK6ypwh6O
MNgxh4jf4MUMysCBuL2F2Fb1kcHb5ezvNq71IzeOIU0ry3EHDSnUlJQGbdwhiqrr
9xTEGeGsSgmUqKR2/twZx6+lk59/sto9WyEpZ21wdKk8zRU+cXaJZC4VREHYky0i
YDORHnt3yYBJnu+C5eYlgNZbXUObOrB2CedjVeLcBIGP9sHwAvOY2A/ZPs1SrseO
y8zc163CjXaZ7ETjcoTT6DGlbT1FUmHwsmOrt34ODERl+GZPX6GbrbiPdBklPsxS
/XTZk61I8SS2c25Bt1QOI+aG/70KKhGqTkY3qd/pT+w7EGEWeE6FqnKAzM/+X1hw
t6yOkF8zT3TQIIfe+918
=JSxd
-END PGP SIGNATURE-

Re: Security concerns with minified javascript code

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Sep 02, 2015 at 07:33:10PM +0100, Neil Williams wrote:
> On Wed, 2 Sep 2015 13:33:57 -0400
> Marvin Renich  wrote:
> 
> > * Ben Hutchings  [150902 10:12]:
> > > My preferred form is a git repository of code written in C, Python,
> > > or some other language I know.  That doesn't mean that a tarball of
> > > Haskell code is non-free!
> 
> > No, "A preferred form" is what upstream uses.  The DFSG does not use
> > the term "THE preferred form", and I believe that was wise.

The DFSG doesn't define source at all.  There seems to be consensus (you're the
only one who doesn't seem to agree) that the definition from the GPL is a good
one, and that does say "the".

> > There can be multiple "preferred forms" for some software, and all are, in
> > my opinion, acceptable by the DFSG.  The real question is whether it is
> > reasonable to expect someone who wishes to modify the software to consider
> > the form "source".

I disagree partly.  It is possible to copy a generated file and use that as
source.  IMO that isn't the case until there have actually been made
modifications to that file, though.  If an upstream (which doesn't need to be
the original upstream) actually uses a file to make modifications, an argument
can be made that this format is source.

At the same time, we should try to convince upstreams that do such a thing to
stop it; it causes code duplication and a (security) support nightmare.

"Someone might think they can make modifications to this file" is much too
broad; for some modifications a hex editor is good enough.  And in some cases
that is totally reasonable, such as an executable for which you don't have
source.  That doesn't make binary exectutables source.

A requirement that there is a (serious, not set up to circumvent this rule)
upstream that actually uses this format as their source is still too broad, but
it's a lot better than the overly broad definition you propose.  With your
definition, literally everything is source.

Here's a rule to limit the selection a bit: a file is certainly not source if
it was originally generated from a different file, and has not been modified.

> Minified isn't source for modification, that much is as far as we've
> got on consensus in this thread. However, lintian has had checks on
> minified without unminified JS available for some time and embedding
> upstreams can follow that, so there is source for modification which
> the embedding upstream would be able to use but, likely as not, the
> original JS upstream would not.

If the embedding upstream wants to use updates from the original upstream, they
will not want to make changes to the generated code.  By the sound of it they
haven't figured that out yet, but if they port their changes to new releases of
the original upstream, then those releases are definitely not source,
regardless of whether the embedding upstream is using them for modification.

> Debian could mandate that embedding upstreams do not include .min.js at
> all and I could live with that. It doesn't fix the problem that Debian
> lacks a sane way of maintainers keeping javascript packages up to date
> with javascript upstreams in ways that embedding upstreams can actually
> use.

Why?  If we rebuild everything, the embedding upstreams can copy our build
procedure, or they can take the minified file we generated.

> The result of that is making software in Debian worse by having more
> unminified embedded copies at different versions across lots of
> packages, exponentially more security issues and more JS packages out of
> date relative to the JS upstream. That would not be good.

I thought the minified files were going to be in their own package so there can
be symlinks?  Any other solution involves code duplication which causes those
problems.

> Embedding software is a bad idea - Debian needs a way of keeping
> javascript packages up to date with JS upstreams so that other
> upstreams don't need to embed (minified or non-minified) JS in the first
> place and everyone has a source for modification in a single place, not
> spread across a dozen large packages that simply add in some JS to make
> one small (but important) bit of code work.

Upstreams will always continue embedding though, because even if Debian fixes
it, not everyone will.  And they want their software to run on those other
platforms as well.  So what we want, is to make sure that Debian doesn't need
the embedded copy.  It can still be there, we just shouldn't use it.

> It's not about contrib or main, that is roughly equivalent to thinking
> that every DFSG problem looks like a nail because all you have available
> is a large hammer instead of solving the problem inside main.

But in the end, it is.  If a maintainer refuses to make their package conform
to the DFSG, it cannot be in main.  We all agree that fixing the problem is
better, but people are now claiming that 

Re: Security concerns with minified javascript code

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Aug 31, 2015 at 08:49:53AM +0200, Raphael Hertzog wrote:
> On Sun, 30 Aug 2015, Bas Wijnen wrote:
> > Why do you care that software is in main, if you evidently do not care about
> > any of the rules we have for it?
> 
> I don't think that implying that Vincent doesn't not care about Free
> Software is very constructive.

I agree, and if my mail sounded like I was pissed off, that would be correct.
He waves off every criticism that what he's doing is wrong, implying he doesn't
care.  His position seems to be "I have my own definition of what free software
is, and I'll apply that to decide whether software can go into main or not".
That greatly bothers me, because our rules for what software goes into main are
probably the biggest feature of the distribution to me.  His attitude (ignoring
those rules) harms that feature.

I tried to convince him normally first, trying to get him to see why what he
does is wrong.  However, the main question is the one I asked in the text you
quoted from me, it has been asked several times, but never been answered.

> If all the energy spent in this thread would have been spent in improving
> our javascript ecosystem, it would have been better.

If we have people maintaining our packages with the attitude displayed here,
some outsiders trying to patch things for them is not going to help much.  For
all I can see, he'd not even accept the patches because he doesn't consider any
of this a problem.

I agree that working on code is good, but I disagree that talking about
philosophy is wasted time.

> I understand both sides of this discussion and it's a hard problem.

I do understand that packaging minified JS code is hard.  I also understand
that a maintainer may give up on doing it right.  I do not understand that when
that happens, they still insist the package can be in main.

> I certainly do not want to move wordpress or publican to contrib because
> some of the javascript libraries that it uses can't be rebuilt from main.

In that case, my question applies to you as well: why do you care for it to be
in main, if you are unwilling to follow the rules we have set up for it?

> Do you see now how you question is not constructive? The javascript bits
> are free software

Which require a compiler that is not in main to build.  That is the definition
of what contrib is for.  Why shouldn't it go in there?

> and are often a small part of a bigger project that is free software.

If they were separately packaged, they'd need to be in contrib.  The bigger
software, having a Depends on that package, would then also need to be in
contrib.  There is no "unless it's only a little" exception to our requirement
that things must have their compiler in main.

> As long as we provide the non-minified javascript files along with all
> the embedded copies that we have, we are respecting our social contract.

I'll give you that the SC isn't very clear on requiring compilers to be in
main, but policy is (for programs anyway, and javascript certainly is a
program) and I didn't think there was any real discussion about it, really.

Are you arguing that having tools to go from source to binary available in main
should not be a requirement for a package to be in main?

> But now I'd like that people stop to give lessons to their fellow DD who
> are actively trying to package parts of the javascript world.

If people have good intentions (and don't get me wrong, I believe everyone
involved does have good intentions), that doesn't mean I automatically have to
agree that their course of action is acceptable.  And if I feel that what they
do harms Debian, I think it isn't just my right, but it is my duty to say
something about it.  To me, the SC doesn't just mean that my packages will
follow the rules, but also that I will attempt to fix problems that aren't in
my packages (as time permits, of course).  In this case, the main problem that
needs fixing seems to be the interpretation of our rules.  That's a social
problem, which needs to be fixed by talking.

On Mon, Aug 31, 2015 at 11:21:55AM -0400, Marvin Renich wrote:
> * Bas Wijnen <wij...@debian.org> [150830 07:53]:
> > On Sun, Aug 30, 2015 at 10:14:13AM +0200, Vincent Bernat wrote:
> > > Is that the preferred form of modification? It depends, but from the
> > > jQuery author point of view, it isn't:
> > 
> > Then it isn't.
> 
> I take exception to this.

I agree with your point.  What I meant to say is that what upstream actually
uses for modifying the work is what we should use as source.  That may change
if upstream changes, and it may not be a clear definition anyway if upstream
consists of multiple people and they have different ideas about it.  But most
of the time this is very clear; if you send a patch and they say "that's not
the file I use for e

Re: Security concerns with minified javascript code

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Aug 30, 2015 at 10:14:13AM +0200, Vincent Bernat wrote:
 The build script determines the outcome of what will effectively run on
 our users' machine. I fail to see how this is not an important
 issue.

You are correct, this is important.

 But until the effort to get ppc64el, not regenerating the
 configure script was just a fine option and not considered as DFSG
 violation (all bugs were filed with normal severity). And this existed
 for as long as Debian existed!

We changed our minds on this.  The previous situation _was_ a problem and so we
no longer think this is acceptable.  That's not because autoconf has matured,
but because we changed our priorities.

Your argument seems to be we did this wrong in the past, so we must do it
wrong now.  It surprises me that you think this is a good argument.

 Is that the preferred form of modification? It depends, but from the
 jQuery author point of view, it isn't:

Then it isn't.

 However, this is a readable source code that will accomodate any
 modification that a end user will deem necessary.

That is not the only reason that we want the user to have source.  They are not
some detached customer.  When we make changes to upstream code, we want to
give those changes back to upstream(SC#2).  I expect that our users (other than
ourselves) often want the same thing.  Both for us and for them, it is made
less likely to get changes accepted by upstream if we work on generated files.

 For me, there is no strong problem with DFSG #2 by just using this file as
 the source code.

I wasn't aware that the source was not even provided.  So far, I thought the
problem was that the compiler was not available.

So we have:
- - A problem with SC#2, making it harder to give back to the community.
- - A violation of DFSG#2, because the source isn't in the package.
- - A violation of SC#1/Policy 2.2, because the compiler isn't in main[0].

And you say all of this should be ignored, because otherwise some of our users
might be annoyed by our principles?  I think you're missing the point then.
Those principles are what sets us apart from other distributions.  If users
don't like them, they should use something else.  Users that do like our
principles expect us to live up to them.  Those are the ones I care about.

You wrote before that you don't want to put something in contrib just because
the compiler isn't in main.  But that's exactly what contrib is for.  Why do
you insist on not using it?  Do you feel your software is less free if it's in
there?  Well, our documents agree.  But refusing to do it even if it should be
done doesn't solve that problem.  Packaging the compiler(s) and running it/them
during package build does.

Thanks,
Bas

[0] As was mentioned in this thread before, policy 2.2.2 says:
The contrib archive area contains supplemental packages [...] which
require software outside of the distribution to [...] build [...].
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV4u6EAAoJEJzRfVgHwHE67lYP/j2bQnLCOJkurJdSC0/wTCkS
y/m8GMOhr5VdMm8fHAT++YNDJcBUZnFIdYeTXuaD2p15dquCoCOZsnHCo4AO3fC5
NilbtVt301WYGd29svRkhsRDgmZwADKE02NNN7Wm9bhCGoHSFyyfuvjrpwU8aTZ/
7c/VPlYaxbVDPIdSlvuZoYNyMNR6TagjLG9srYAf0WkyMqK18h10vpH4MzTZbnsb
nMU2R4PMUq6j8SXJ0Nb1HphoSchqyvMvMb/pwRJOLsqp4Fxrk8DzPUMcnvwBw/+z
q0XyKEu4jinMsQzjdjQmira5O1x45RGsX4mBzh5rb9vKG2Z7+FhvmIPK1bDUYXDl
qToJCDEwsshyxdJE9HlzB62NGCUInTgx6B5IycSwHoFLfS/dYS+Our4O+L5P6KeD
1QPCeJq6pqn2ip4Lz6QLDC4VVWbmNcrXPS7XmdWa+MwtxJ1nuuCiiQLRC5Loanf3
DCd7NTMLxxrBR2s3vdcArpBwZBzBbfC4xB152pI4ICVsjO6sL/auU47Rrbl9Ud+o
8LdrvPF0VMMTJOUQdIaQQFWQ0hIyRvev6YypYa96HpVk8p6iOg1om0dWDGspZ4Ri
di2Zbav/fMYcsDxu5iF+GgPZYQeueFvD3PHe0e8N1f6NHqVNywmr+v74SbQPqpp/
HN8KCT0/OghVeMeKPC7q
=G8EQ
-END PGP SIGNATURE-

Re: Security concerns with minified javascript code

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Aug 30, 2015 at 02:12:43PM +0200, Vincent Bernat wrote:
 This is becoming quite a stretch. At this rate, we will fail to match
 SC#2 because we ship previous versions of software and upstream is
 unlikely to accept a patch against a non-current version.

So you do not care if we (or our users) can send patches upstream in a good
way, you do not care if source is provided, and you do not care if a compiler
is in main.

Why do you care that software is in main, if you evidently do not care about
any of the rules we have for it?

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV42k/AAoJEJzRfVgHwHE6YD8P/0GDf8O3gZ5fmnsczeWVRTcf
qWUsWC3/o8tUC2tQ4otxY8TY7/YbkXeV1ZUmu8NlIiPyQPNc+iBDEWElis+cESjg
fPO6MibCL69jHRUCfW1c9p/CNDbdk7qCwuxokTtCBSH2W9j0uBqnFzCbkDqXeR3Q
ZfYDtHdfRW+k7t9pw0uLgiAgRvCzRP0yKehiztOHAm2/lV4pdvMYYzc9CdcGBZr6
J0S9m/R8fdlPBOELXHt+8V1luAbGlTHGqfaEqkHVCrwzdkHnmbI/xLr1wf+wJTM/
Lrotm5CBrVEVGIPX6kUxl+jMLRRRm+tETVEuVHnShD71ZxFmVl4bLcIrtuC/hM9f
GCxICn6KxAHpCPaXZN5U8N8v+JooskGdENwBfLx1xqry1qf4bPruetZ+w6Fn4jjy
rPaJmV6vkhw7dYmGWQHO02mRGLqAyTOsnbQhDOpFyTERU6YO5DrB3DfyGwKimLGE
ff3AUMKBXITq9nn5/lpb28vyHDPCoTq/oxf85V/buSmnTkJr2y8Konv8RATb5ckR
WcqR4QlNRQr+DTSmMuHdeWp6gxUwDq81g2s1ij28Ib5GqtVv2byfl9LB9E8Thdym
90R+ckZ6GU+WmK8NgoF4x4jxgp6L+9BmdnfxePlctSvHNW1SnmTxccffIgWg7cGB
3jf1BmpZQCZs4ddFo8+f
=hkQ+
-END PGP SIGNATURE-

Re: Summary of the DebConf firmware discussion

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

First of all, thanks for having this discussion.  I think it is a serious
problem.  Debian is currently hard to install on many machines, and I very much
dislike the idea of telling people to enable all of non-free because of some
hardware.  Installing a package manually and then no longer updating is also
not a good idea (even though it is unlikely that we can fix much in those
packages, it's just wrong to keep them out of the automatic update process).

On Sat, Aug 29, 2015 at 03:54:56PM +0200, Jan Hauke Rahm wrote:
 On Sat, Aug 29, 2015 at 01:15:21PM +0200, Paul Wise wrote:
  non-free/docs
  non-free/firmware
  non-free/drivers
  non-free/web
  non-free/comm
  non-free/formats
  non-free/apps
 
 I don't care much for making this more complicated, but splitting
 non-free may find many (even reasonable) metrics to do so.

What you're describing is debtags.  For users who want that sort of control, it
may be useful to add functionality to apt to hide packages that match some rule
involving debtags.  It will download the full package list, but it only
presents what the user chose to see.

On the other hand, if I see the above list, it seems like splitting non-free
into the sections it already has might also be an idea.  My guess is no split
in the archive is really needed for that; instead, we'd need to have some way
to download a package list of one section at a time.  In other words,
sources.list should be able to include something like:

deb http://http.debian.net unstable main non-free/kernel

My guess is that this is also relatively easy to implement, but I haven't
looked at the code at all, so I may be wrong about that.

 Think of some package with a non-commercial clause in its otherwise free
 license. Many of our users are non-commercial and could use
 non-free/non-commercial.  Or think of those non-military/non-evil licenses
 which (almost) any private citizen and even many companies could use.

Everything in non-free can be used by people, otherwise we couldn't distribute
it.  If people want to only not use things they aren't allowed to use, they
should enable all of non-free and read the licenses.  The debtags approach I
described above may help (and even without apt helping, users can use debtags
to find their packages).

About the installation media: I agree that they are part of main, and therefore
should not contain the firmware.  On the other hand, I think it is important
that it is easy for users to install Debian and on many systems that is not
currently the case.  A firmware bundle that is automatically detected at
installer boot seems like a good option to me.  I also didn't know those
existed, and so I don't know how easy it is to use them.  I don't think
messages are particularly important; users will ignore them anyway, and by
downloading and preparing the firmware bundle they have already indicated that
they want to use it.  I'm opposed to more messages than usual, otherwise the
Windows-effect of users not reading them and just clicking Ok, Agree, Continue
will happen.  There should of course be a message at the download link of the
bundle, but no I Agree-button IMO.  We're trying to help them, not annoy
them.

Finally, I think we should advertize those bundles.  We should be clear that
they are non-free and therefore not part of Debian, but also that they may need
them.  We even say in our SC that we don't have a problem with people who need
non-free things, so we shouldn't make life hard for them by hiding things that
we know they need.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV4cNSAAoJEJzRfVgHwHE6+aoP/3ewjv7T+KmzWNLZrvxJqGmN
o3Ux79iPGwtKzhFYivblJ3fKh49fKvaT2ml6dwHB22Rof+sLrmkl/kS39++uja19
nx0vyT30cWhb+cxA8NNlNk/1aotUkGnRQS8TcJOSg9Qc2cvPOUFA9Kc9Dqycqd7N
WHxREZy1h1OLtTm3FpCSZtuZO3GC7D9RcE+QJAsAHQFjD/eRfkxcDtpTEGYoYcMz
gfzCHAb45mKI1UUy3CSXYNDlmle/jRYG7A5SUDJIUjgwUk3KJEv2zSrxORQ9NTAm
3bTFRg8lFfJJp7v98IAb0uktl60ei1ALBp8YfORY/FWQN2zl+f/GMbHrlEV6I2Cm
EdJKOq1OsiFeIE6tq71V3W0rfbggBAwSJtqmnFRrN3VzLcYreClWAS8qaw6soKbv
B/ryWztJq74KoDjtxUcGcXrXpXFjoSwYxyS8JxAtgEw1hYnnd87qIY+WT7lXTxfD
J0l69brCcvgKdqO67mBbQp/CWAta1FJaTVhY7EYpYdYzpyzp2xUOSrKDwQtFu09g
9dzLV2YxyOunDSbAm1Q6qctBuihC9+ClQ1vJ0euJ3lDIWXO3lzvkrOPloEo9T5qK
3lP8x579GBpywEo3DZ6ZnOUo045v3DENLRnzl8yZ8wLLsoiskEfgcWbLSWy90AF+
QWw14pyPyfFmH2ViIXjH
=Vno9
-END PGP SIGNATURE-

Re: Security concerns with minified javascript code

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Aug 26, 2015 at 07:35:01AM +0200, Vincent Bernat wrote:
  ❦ 25 août 2015 22:37 GMT, Bas Wijnen wij...@debian.org :
 
  We need to leave the Javascript ecosystem mature a bit more but in the
  meantime, a bit of tolerance would be appreciated
 
  The minifier is a compiler.  If it's not in main, files that are compiled 
  with
  it cannot be in main.  For javascript, the easy solution is to not use the
  compiler.  Non-minified code works fine.
 
 Non-minified code is decomposed in several dozen files. Using them is as
 painful as trying to concat them and minifying them properly.

What does minify properly mean?  Using cat as a replacement for minifying
sounds attractive to me; what else is needed?

 There are a lot of solutions. All of them will make the package a bit more
 buggy than the previous ones. At the end, we will just get angry users and
 angry upstream.

On the other hand, shipping packages that cannot be rebuilt with tools from
Debian will also result in angry users.  For me personally, one of the bigger
reasons I use Debian is that we take good care that I can modify everything on
my system, and use the modified version.  The users you're talking about
probably don't care (much) about this, and should have contrib and non-free
enabled.

Why should code that doesn't meet our standards (compiler in main) be allowed
in main?  What is the downside of putting it in contrib?  Users who don't have
contrib enabled can't use it then is a feature, not a bug.

As to people who care about having only free software in main should fix
things for us: that's not how it works.  Debian's rules say that this sort of
thing is not allowed.  You can't say that people who care about those rules
must fix other people's packages.  (You suggested that using --with autoreconf
was similar, but it wasn't; most work on that front was making sure autoreconf
could actually run and produced good output, and that work was done by the
maintainers, not by dh_autoreconf.)

 The main effect of this religious and overzealous application of our
 guidelines is that people just stay away of JS stuff in Debian and
 packaging any web-related app is becoming more complex as anyone needs
 to deal with JS stuff in its own package.

Yes, that is a danger.  I think putting those things in contrib should be a
good solution if rebuilding is such a big problem.  Because if it is, the code
really really doesn't belong in main.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV34l6AAoJEJzRfVgHwHE6uG0QAKHAOxR4GcstYPProuE7xfgT
ZlKCvg3755hMcgHGay4gdybSSGIFKhCfw+gD2CSmEZFwDjGYYoQQdGGBfx3yTcsp
cBIJIQOdcL6dNvYH8R8BeCzbVbT1JKNZD/OdDPQb3+oSPyJ+gcndGO2aEvzwEHFA
znwFqRyR6nNAfp/xkLpXKLjbICtvk79sKfiP03vLlbbMMkXU2JKOSZE3yyj7nLpN
CVRaVxAbSpYwzW2odEheeL9azRjLx+JC95Et4Ef76xr8tfKaeNdQk/krTTaEmDH/
8fCbXXkSc6WPHtYUxjn8O2T1EKhnI74F73ZLZhqUO4FxECcBrPfcA0Sm62RulXma
A4ZpXEdMXHXubIpqsQGFwPdNvSehGVz0B6YSibMNqLpXJflCqKXyZexnUUA62XEP
FK52qyOyyLd2dKLZcsc6ATXWAeveVaPaZjX94rlGsJ/NtGZMvi75eazjEp5Qz+4U
AdtlQvpweBsD94MWu99yvC+GTIIfC0v2OW6j7BLPs4PbRzbIhpZtSfk7+2c2oPdu
7YuMMF01vD1RuSviO+vM9JbcxMY+qAJKza+bdQjeSl8bG0o60SUIHpTv2ZSVpqrJ
CmH+xB8Z5KceibrM0AFYZsHhSq/CQgMj3Ca7whYEqH5tHj9tip8pjhZHaR+OFAD5
aRhkuFILHhbFJdJ4lvBA
=XAHu
-END PGP SIGNATURE-

Re: Security concerns with minified javascript code

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Aug 27, 2015 at 04:14:53PM -0700, Russ Allbery wrote:
 Bas Wijnen wij...@debian.org writes:
 
  On the other hand, shipping packages that cannot be rebuilt with tools
  from Debian will also result in angry users.  For me personally, one of
  the bigger reasons I use Debian is that we take good care that I can
  modify everything on my system, and use the modified version.  The users
  you're talking about probably don't care (much) about this, and should
  have contrib and non-free enabled.
 
  Why should code that doesn't meet our standards (compiler in main) be
  allowed in main?  What is the downside of putting it in contrib?  Users
  who don't have contrib enabled can't use it then is a feature, not a
  bug.
 
 Last time I checked, Doxygen includes minified Javascript in all of its
 generated output.  Would we have to move every piece of Doxygen-generated
 documentation into a separate package so that we could put it in contrib,
 or strip it from our packages?

These are not the only solutions.  We have many bugs in our packages that we
would like to fix, but that doesn't mean they're all fixed.  As long as we are
working on the issue, we can live with it.  But I get the feeling that people
just want to let it be this way and never fix it.  That is not a solution IMO.

And yes, I think this is important.  I think files that cannot be regenerated
with programs from main do not belong in main.  It surprises me that this is
controversial, really.

I'll agree that in this case it is something that may be accepted for a while,
but not that it doesn't require fixing.

But I still don't understand the problem.  Originally I thought minifying
consisted of renaming identifiers to be short and removing whitespace.  That
can be omitted at almost no cost.  I just learned that files may be combined.
That can be done with cat.  Even if the minifying tools that upstream use
constantly change and aren't suitable to be packaged, what complex thing do
they do that can't be done with commandline tools?  Why can't we fix this
problem by just minifying our own way, which may be less cool, but just as
effective?

Or alternatively, by packaging the minifier that is being used with the package
that needs it.  Yes, that's a horrible idea with lots of code duplication, but
if I understand the problem, every JS file must be minified with the exact
version of the minifier that upstream used, so then every package would have
its own unique package that it depends on, and in that case they can just be
merged.  But it can't really be that bad, right?

 This is typical of the sorts of problems that I would expect.  It would
 surprise me if this were a smaller project than the GFDL purging.  It
 might be quite a bit larger.

If the minifiers are so complex and at the same time unpackageable, I think it
is the right thing to do, though.  Our main+contrib+non-free users won't care
(and they won't notice either), but our main-only users expect it of us.  It is
very similar to the GFDL situation, indeed.  Including the fact that there
seems to be discussion about whether there is a problem.

But let me be clear: I don't maintain any minified JS code.  I don't expect to
be doing this work.  I'm also not saying that other people must do it right
away.  I am saying that they should consider this a serious issue, because it
breaks our promise to the community.  So even though it doesn't have to be
their top priority, I certainly hope it is something that they think of as a
bug, which deserves to be fixed at some point.  From this discussion it seems
there is no consensus on that, and that worries me.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV372GAAoJEJzRfVgHwHE6C2AP/0C8I1yg3QiEoeYNyRWJzQpx
c9BzlB2ISimbym2DjAMVf0hZSzjFTY2q5BNMt8vmqOeKJ/TxlkwzxXC+ZSoLo+2o
E69gQvLrFpnLdO+z+8YZdoLPpz9S3l6HkhlUVVVlRiqdPSL3Pb3vI8w7nSBEpfqE
ooavdNvug10O6w0SiY3EhTeTVzmCF4pi/ZCyU4n8fmDHJT3xRG+SgrYe1YYq3QkR
qESTLXaoBVu4B7tcWUAJvbC0ICG7n0K3JD2t1fcM1WmiBZYWwuNmBSt9yDeYmeq9
OKGWAYvWRK55/9ofRvMgAk3yA0eqm4+XQw4DFixFUidCHHLrUAN91nJGsjjkin3O
JanPvbrk+pg4MWZSol9UESp0iLTawahEedYWjD8Jdckhb8fWul3c2SOms/2zhCJS
fb58BpdKihB4n4UzrDpB1O6MNF/66JV+0Iji4mspH3HsZuB93yYEtgV1JntmLP3r
eZKUJt7tjlydzNfJc/mb0AoyHfUip8pakexDb/AnQzqP2q17lLitoTRsp8Q4kgJM
1Vmm9AGJm+1ki5jwHtrQSOj0VRtxZdbmRFgUkr1yRdMis5iI+DVUPlOk6wq5cjbQ
Y0yo8eFx3rk2gXrQaIyQ33/Ntc7NgLy3W1fjgaV+W2H9AxSRqTkqB/f6hxys2qaF
+1wo0YDVgi4tef9wbheP
=LJbz
-END PGP SIGNATURE-

Re: Security concerns with minified javascript code

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Aug 25, 2015 at 07:17:12PM +0200, Jonas Smedegaard wrote:
 Quoting Scott Kitterman (2015-08-25 17:57:11)
  AFAIK we've only ever discussed the need to provide source.  I don't 
  know why there would be a requirement to reminify.
 
 I see no reason to require javascript code shipped in binary packages to 
 be minified.

My guess would be for performance.  I don't know how much it actually does
(it'll be mostly bandwidth, I suppose).

 I do see a reason to require that *if* such code is minified then the 
 minification must be done during build, not upstream.

AFAIK Debian doesn't *require* generated files to be rebuilt.  For example, it
used to be common practice for a long time to copy config.{guess,sub} from
autotools-dev instead of regenerating them with autoreconf (I think there is
consensus now that regenerating is better, but it still isn't a policy
requirement).

I think everyone agrees that binaries should be compiled during package build.
Just shipping a precompiled binary and its source is not how things should be
done.

I don't see why javascript minification would be different from C compilation
in a way that would lead to a different way of handling it.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV3Ky6AAoJEJzRfVgHwHE6xdAQAIZUkdzmmIr8u2ug5jjqYD96
OO2vDku0uAt6chvH/qu/eh7w+b4Udy0/d3MOE6vWEo95ThJLQefVnxrMU1u1fUah
2CYoDZerixODAb9MgKSwzSlQ0dOG9H8iELTnbOlyfVYD4gpW204BSN0sFrQkuKTp
2sOX/3kR2QVMHM/Ywsrzd54qrhSSovC9vbVlbFJ5XOK7d0DoepE7vhZMdbmLjq2D
fezKm6caAUwi+bjiyYRFvP7eQKvrVygckVy8LY7AT0Vr1OwmKsiynYBGh39GzozS
A1Pb9TH/3szsNYITF36tCmJF9A6npjHApF/ysePBsgMxESXzGAfG9SrRLUzT+9tO
AXfSa76KWQpvEGAz1jWkuB11cevrSyH3gA4tpJ1aOKngFniV3trGeETN8ZH/y7KL
CMceSZMzFPYSXsR5rrONXasIhj7qB87yHKim1AGsHXBzbf/oA/sdePze3BB2nT2F
4QV8GetTslvHsIT6pTuJsfg8wpDp8pvopeSJrm90cb4KN+odmxoQgUjXpbhGHvCx
BPu2xKv5y8k8OonObvxQM/9IUlHLpdYWPJIGEnetxyBpwAm0KnO5yPLkA56neqeo
pOndBqDysQCwPshh6RtmgvkWUKmd4KdcdK3kkvCvxlj+p3D6vXAmaplnRRr6dzag
iF/wxplyM+n+chCTCZzY
=qMBg
-END PGP SIGNATURE-

Re: Security concerns with minified javascript code

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Aug 25, 2015 at 07:08:06PM +0100, Ian Jackson wrote:
 Bas Wijnen writes (Re: Security concerns with minified javascript code):
  AFAIK Debian doesn't *require* generated files to be rebuilt.  For
  example, it used to be common practice for a long time to copy
  config.{guess,sub} from autotools-dev instead of regenerating them
  with autoreconf (I think there is consensus now that regenerating is
  better, but it still isn't a policy requirement).
 
 config.{guess,sub} aren't modified by autotools, are they ?  Just
 copied.  I think you probably want to be thinking about configure.

They are just copied, but there are some more things happening when running
autoreconf (or running auto* manually) and IME autoreconf may not always work.
If it doesn't, the user cannot modify Makefile.am and have those changes work
their way into the compiled program.

(What it really means is that while Makefile.am is the source for Makefile, the
compilation process to turn one into the other is sometimes nontrivial; running
autoreconf during package build documents that process in debian/rules, or else
the package build will fail.)

 So I think that while you are right in the general case that
 we should regenerate everything from source, I think that autotools
 output might reasonably get an exception.  There might be other
 possible exceptions.

Yes, I agree that there are exceptions.  My point is not that it is a hard rule
(it isn't, and I think that is a good thing).  It may be broken, but you need a
reason.  I see no reason to break it for javascript code.

 The key point is that we want to be confident that we can modify what
 are supposedly the input files, regenerate the output files, and get a
 working package.

Exactly.  And the easiest way to be confident about it is to rebuild things, so
that is what you do unless you have a reason not to.

 In practice, given the widely adopted poor practice surrounding
 webapps in general and minified javascript in particular, I think that
 the only way we can be confident enough that we have useable source
 code is to actually use what we think is the source code.

Agreed.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV3LNXAAoJEJzRfVgHwHE6FhoP/A0FckLDm+1NwhNhN/0AMypa
OKATAwHEqND5BLyvAAI5Kqi3qJ5c1GrLbNUD5/Ccsd40yMdOtAOLbpwur7MeGvzh
JoHGBXm0Q6Q0jHm5c67YySlS5/Gp4P58GUqLt8DF2NN1olx0AMWtZUzP052/Tn2i
9JVMhhZTgPproA0EhjawsqGsVHvleqNw4xNzh/fCfTbUKnT5Zt52DsabDJjEEvFK
bTNGOPd6Qd3PAf1yhvb17vqGeWMNpZP8opOxv89eUuQiCi1LfHciSV5fyFBXD/XG
VavTyjzXInMi/CuhamFDdrxLeyIW1qfqJCgt4G43uc+Dm8t8ICTkvdZTuekbjf96
hNYcZ6jaZ59GkQJI26p61Ffe6MCsnw5C9lOSUbXLEule6zeuRJazVKvjRocZWJtm
quRiXdI+DwHKsLSebjqGffmAWVaIrugubPNDBFvR8T9vXyL4WhsDsMm0gyz1iQ03
UE8nKfzOwFTmCM2OCY/kQXoGiIcd3jLUPuJQE3zO8h3YgKgLWdXuqJDxGsrDiOFR
idB561jLPpN0VBsUdVQaLmT5mj89AZPCedZQTgIQiELlxOMA/WnfYAs/5HeZ9Tap
IQ3JKnn0ZVys0WX9PZ/kHrU+aC4/mLyknFE9nBr7XnvOD/nYiQsvTMYG2CP69upt
LCQhv2chCCrU8yb5FVLp
=m7m8
-END PGP SIGNATURE-

Re: Security concerns with minified javascript code

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Aug 25, 2015 at 11:13:15PM +0200, Vincent Bernat wrote:
  ❦ 25 août 2015 17:58 GMT, Bas Wijnen wij...@debian.org :
 
  I don't see why javascript minification would be different from C 
  compilation
  in a way that would lead to a different way of handling it.
 
 It has already been said numerous time in the past, for some Javascript
 code, we don't really have the tools in Debian to easily go from the
 source to the minified version. It's possible, but without the
 appropriate tools, it's painful.

In that case, it should be treated like any other thing for which the compiler
is not in Debian: either package the compiler, or put it in contrib.  But for
javascript that isn't even needed:

 We need to leave the Javascript ecosystem mature a bit more but in the
 meantime, a bit of tolerance would be appreciated

The minifier is a compiler.  If it's not in main, files that are compiled with
it cannot be in main.  For javascript, the easy solution is to not use the
compiler.  Non-minified code works fine.

If you really want minified code, then you need to go for the hard solution,
just like in any other language: package the compiler and run it during build.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV3O40AAoJEJzRfVgHwHE6snwP/RjBujWfFHEVhf9JNCAO5vxP
XmQinXIJiZ8DS6i2zst5Pw+eL2Zj80Sa26+7b1mKshJm064H9cr5YxxeZFx389Hm
dPsds8CzFgsxY5H2rsfA0ipC+oUzYpCYnrQwzPjJoC0As14BWMpMfvbNbNHFEMjc
7gS1POcN6N/zSv9xVHVeJjuXyNTwi6CEjvcHr0cXaJ594iZHE85OEyjywnYF3MiM
Vbtl3GkeCyF9QLE6QTTjhytCqtpu7RzU91kr1F1zF9ZMbzCxz5/jto1hhNvuhbD5
U57mEJ/mxXvbFMSXNouWDHhr1TX2Y3CwUijBz4MNpb14+1uptJPWQ/8SEL2SZQKe
g3Of8P4Jq+L+vOlc8B9N8s9GTHvPY4haOmI8PB6VHp75e5RQtZ77TMFekYAsI+Ev
GQulvjT+0+cw/JbBkuQfRkaBuG8MCx76z8aFvAjQt3EeDeiH4c6QDBvSTLROBpZp
qbLEDz5+Ux01AjBoMj6NFzjwdli/+H9RfAvKtb3r081yEf6v4NzntPlzvU8PWW/b
0+FWDDwvKQw0InkKMLQ8QSeyBK7Xk5Rkp4rxaCtzwCKOyHU+sw4jg8lg0K8p0edu
uJ2OVm5Chpqo7mbkfikS/4e0dZh4AYuhwHYCefJ5ORKAQFNJaRE+00zODrYqW0Oe
oD2QZIGbekgWegNtfv5Y
=wczl
-END PGP SIGNATURE-

Accepted openmsx-catapult 0.11.0-2 (source amd64) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Wed, 12 Aug 2015 22:13:12 -0400
Source: openmsx-catapult
Binary: openmsx-catapult
Architecture: source amd64
Version: 0.11.0-2
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen wij...@debian.org
Changed-By: Bas Wijnen wij...@debian.org
Description:
 openmsx-catapult - GUI for openMSX
Closes: 750918
Changes:
 openmsx-catapult (0.11.0-2) unstable; urgency=medium
 .
   * Fix libwxgtk dependency version.  (Closes: #750918)
Checksums-Sha1:
 4ed81fe5d7c1d4c2f32cbff03974be325f76497a 1815 openmsx-catapult_0.11.0-2.dsc
 f9c33be1071aa08d49bdb3f440f0129eed1aab0d 8988 
openmsx-catapult_0.11.0-2.debian.tar.xz
 3b4d78d51900ad2acf18fd1d58346821e95b27cc 403320 
openmsx-catapult_0.11.0-2_amd64.deb
Checksums-Sha256:
 fdc2cf3f7e8fd3a34e266ad9517b3dc968d4a99236fe41a993628c80e090b6f5 1815 
openmsx-catapult_0.11.0-2.dsc
 26425311b3829d60a1a1e92ca68ece7acc607c66d979f8705e429394b0c04ebf 8988 
openmsx-catapult_0.11.0-2.debian.tar.xz
 d03a9fd5950e2b0e42fbf10b0977546f7bacbaa11d96849adeab822edc23854d 403320 
openmsx-catapult_0.11.0-2_amd64.deb
Files:
 3e3367af15f037a93a2e9291a656e2ad 1815 otherosfs optional 
openmsx-catapult_0.11.0-2.dsc
 5b5770095b12f1dbb0d98cd9992aced0 8988 otherosfs optional 
openmsx-catapult_0.11.0-2.debian.tar.xz
 a691fc2f0501332380c2b5af78032fac 403320 otherosfs optional 
openmsx-catapult_0.11.0-2_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVy/3OAAoJEJzRfVgHwHE6W6QP/322Eg2viseaXIpPRizaWB46
3nWYTyvNUinDaYETJRhSSPjQcEUCNx8xHuWH7u07qc7MgcOklO79lWPd+hvc3Rk2
EpH1EjaY0grwtuP0dlIfBSK/nud9q/Fxvl+tcO+ujgKTqLVGpr6hYQ/KnF8+Oopv
1QXbpcJqb+pdhBVAkbffr55HwT0ckFIegWAvrK+HBhkRv4E9QJ5kITDp6QgrTskf
M7xnYrOlvO1o7A0OURKAWHS1epEv19H9h3UZEgJ3cheVpNBIEynRffYckKnHwYE8
ZKL4MXjsGN+UUsfwEZCE2/Lf6jRiAPQ3J4m8DYxL+ig7vWh+l8U0wEBFTBm/u5fh
jkMI+ThnePIiEaFDlDqA+JXtlhv3wp7rCMkemE7EFT/eNJuo66bAP4vWNK3O/QYD
Y6dhCr5bIAuDwaGxOk2oQV9bfX0VQEBMMJgDstMM/iNm4UqslRCFS/3Y1h97jZ0E
AxHGfJCUhE5rw1R54r9tjKDBx1hDfpqkfeUq+oBIdhI0LP0vRZO8UrTmLf/PZAI8
QhqOwuxu3z5YsykocZL9/F98THqfsV1McaPVDqeLvXX1K/9V8QGjOuGo7AHCRLUx
Gy485PFLC8/8ArsUcJLRUn8UrUhN+82nnsPa78fxxT8jtDPo/JdKFgqZeCLiNKaf
Hk7VUaKdPc8Q4ENz3Ulv
=Pbif
-END PGP SIGNATURE-

Re: certificate creation in postinst, potentially using letsencrypt script

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Aug 02, 2015 at 05:44:06PM +0200, Christoph Anton Mitterer wrote:
 Some ideas that pop up in my mind:
 - Would be yet another location of privacy leak in Debian, where the
 system automatically calls home to some more commercial than
 community organisations.

I agree this should not be automatic, but it would be good to support it.  Note
that this is a community organization; Mozilla is a part of it, but so is the
EFF.

 - Why should Debian - as a neutral community organisation - push
 Mozilla's letsecnrypt?

Aside from it not being just Mozilla's; the answer is simple: because it helps
our goals.  Encryption everywhere is a really good idea.  At the moment, the
only reasonable way to get encryption witout either dealing with the companies
you hate as much as I do, or training your users to ignore really scary looking
warnings, is through this service.

 It has more or less the same inherent problems than the other CAs that
 offer free certs,... so why not pushing for CAcert? Or StartSSL?
 I think it's a bad development, that we get more and more corporate
 into Debian.

I agree that we should watch out that corporate interests do not get a place in
our decision making process.  But that doesn't mean we can't use anything that
a corporation also supports, or even pays for.  They don't get a vote in
Debian.  They just provide a service which is aligned with our goals, and we
help our users to use that service, because we think it is good for them.

Or are you saying that this service would harm our users?  If so, how?

I agree that CAcert in particular is something I would like to see supported by
Debian.  On the other hand, even if they are put back in Debian's trusted
certificates list, the rest of the world would still not trust them.  So using
their certificates doesn't help much compared to self signed if you have any
non-Debian visitors (and at the moment, even if if you don't).

This is similar to kernels for me: I think it would be best if everyone would
use the Hurd instead of Linux.  But with the current state of affairs, that's
just not a good recommendation for most people.

 - People may automatically start using these certs, but given the
 inherent problems of the strict hierarchical X.509 system, this also
 means that one gives up control to e.g. letsencrypt, compared to self
 -signed certificates where I'm under complete control, and not
 potentially rogue or governmentally forced CA could issue forged
 certificates for my name.

This is simply not true.  CAs can do this _anyway_.  If a rogue CA decides to
hand out certificates to people who don't own the website that's on it, the
owners of those websites have a problem.  There's nothing they can do about it
(except legal action and pushing for removing trust from that CA).

 - Some packages may just create such certs, but not be configured to
 ever actually use them

That sounds like a bug.  We can fix bugs. :-)

 - Your idea mentioned above, of using the same cert for different
 services...
 This has advantages and disadvantages, so both should be possible or at
 least any such automatic handling shouldn't make it impossible for
 users to do whatever they like.

In particular, I would like it to be possible for users without root access to
install their own keys in a way that doesn't allow other users to read them.

 - And that later point is actually another concern.
 Automatically handling such things (e.g. the certificates) often means
 that certain constraints come up how things are expected in order to
 work.
 So any such automatic handling should be better darn good and
 completely transparent.

Of course.  I think the idea is something like this:
- - Keys are installed in /etc/ssl/private/.
- - Certificates are placed in /etc/ssl/certs/.
- - Keys with their certificate in one file are generated in /etc/ssl/combined/
  (which is restricted to the same users that are allowed to read
  /etc/ssl/private/).

Programs can use the separate keys and certificates, or the combined ones;
whatever they need.  When installing a key or certificate, a trigger must be
run to update the combined list.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVvlKqAAoJEJzRfVgHwHE6TpUQAJ1Qc3ZBtrEMMA7MBlpUxuHc
OoGsyPT/u9tKJGhPXAli7aI95H22EQWnz75P8YT9OvA1sMN3j5i+Uw8FnRvfN1GP
JXyX0dfgrBvYfG0Cg6fSYaWsv8QfTN3CHx46bcWMximR+EbnxQTNZT3Vp4pN1HKO
kiCLsAqJZ4hQ7jmbo/tbZX1TANuYdRSRaf7vGmMIKYOrY0tLQ0h+C8OsrlgaRoWV
zIEF+LxLMfcNggQjAGte9ZCvB9kWnbrcKIBVeYf4378X9aXSlkJCl1ifbJ9JsVsm
Os/dtX/rBQn6Lw6NH49MrHeeAXHLja8XfHM8fQyrGQPj9eh3oCxzs+r1EX8yiOce
RpdJPg0XpKOUzMOQGSOHOV/6dOJTskLi8WPOx2CM23znJFFbdCRyU9jjWF0Qo9yB
Xy3qV5asJ3cAIh/cQ9DiXs69ywpA2vIthUucM+QY95vNreNOG8ACJEgqY/7QxBBt
PfcoaFbzBwFG6mKXoWXJ50UlhaWd+DhPvTqgXVM6RMX5VxQYeViOkI2z9kgESIjn
pIRTqjEoQt7T+aWeoYBDlXThatH57VLZt+Gk+nJ30HdSuRJ0cr+kNaxhkkGPlIzG
1XHYBnBzroP2hQeosmQh89+caRJW0pwvFLJ9ka67scvLZL/GGAcnnIaXdMeKlouQ
jLxoegsM3jriCVuAtNHp
=BxUg

Re: Packaging certain libraries as end-user software

[Bas Wijnen]

On Sun, Jul 19, 2015 at 11:06:45AM +0200, Eduard Bloch wrote:
   It's less of a library than an environment used for research. Compiling
   is just a required step to run your code, but applications are usually
   not distributed in binary form.
  
  What is the benefit of providing a shared library at all?  Why not ship 
  only a
  static library?
 
 This is not a rhetorical question, is it?

No.  There's a maintainance burden to properly ship a shared library, and if it
doesn't have a stable interface, it is significant.  From the description I
understand that this work may not be done.  The question then becomes: do you
want a shared library that isn't properly handling its interface, or do you
want to waste a little hd space for built binaries?

Unless you are building for embedded systems with very tight resources, a few
MB of hd space is irrelevant.  Using a shared library the way you propose
allows for programs to stop working on upgrade without understandable error
messages.  That's a downside, even if it's small because it doesn't happen
often.  But there is no real upside to shipping a shared library, AFAICS.

 The obvious benefit is the whole principle of a library: common code is
 shared across multiple binaries. I prefer a lib of 2MB size and 5x
 executable (100kB each) over 10MB.

The main benefit of a library is that you don't have code duplication.  With a
static library, the downside is that you need to recompile if you want to use
the new ABI-compatible version of the library (if it's not compatible, you need
to recompile no matter what you use).  If the user recompiles everything all
the time anyway, that isn't a downside.

 The package size might still be ok (xz works well on duplicated code)
 but the installed size isn't.

Executables in a package?  I thought this was for local use only, not for
building packages?  If packages make any sense (whether in Debian or not), then
it's a really bad idea to change the ABI without changing the SONAME, and that
will happen with an unstable ABI.

   Changing the soname often is not an issue; it's just for Debian if the
   package name changes with the soname...
  
  It's not a problem if the SONAME is changed a lot.  The problem is that it
 
 That's a problem that has made me wondering for years. We are
 over-complicating things; we interpret the simple fact of has a SONAME
 as an obligation to make the thing available to all potential users of
 that library... even if there are no users who care!

A SONAME is a form of technical documentation.  It is a note saying this is
the version of the symbols in here.  If a library has a SONAME, users may
expect it to be properly used.  If you don't want to use it, then don't put it
in there.

You can create a shared object without a SONAME if you want to; that's called a
module and they can be loaded with dlopen.  You need your own method of
handling versions then.

In this case, I don't think modules make sense.  A static library seems more
appropriate.  But it is an option.

 And won't care in future because it's clear that upstream is not using a
 stable API.

So if they aren't, why would they put in a SONAME, which means we take care of
handling versions well?  That just confuses people.  If you don't care, then
don't put that in the library.  Trying to install such a module into the
library path will give you a lintian error, and rightfully so.

 If it isn't clear, than making it clear should be the easier mission.

You're proposing to put up a sign claiming that you follow a standard, with a
note saying not true on it.  Why don't you remove the sign?

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150720233709.gx8...@fmf.nl

Re: Packaging certain libraries as end-user software

[Bas Wijnen]

On Fri, Jul 17, 2015 at 05:30:04PM +0200, Ansgar Burchardt wrote:
 It's less of a library than an environment used for research. Compiling
 is just a required step to run your code, but applications are usually
 not distributed in binary form.

What is the benefit of providing a shared library at all?  Why not ship only a
static library?

  and that do not have a stable ABI.
  
  That is an issue.  It means that upstream will either need to change the 
  soname
  a lot, which is probably not what they do, or that it shouldn't be a shared
  library (but a static library instead).
 
 Changing the soname often is not an issue; it's just for Debian if the
 package name changes with the soname...

It's not a problem if the SONAME is changed a lot.  The problem is that it
needs to change a lot and upstream may forget it.  If programs need to be
recompiled before running anyway, I don't think there's a benefit in shipping a
shared library.

 Note that Haskell also doesn't rename packages all the time, but instead
 Provides: a virtual package which name changes on ABI changes. What I
 plan to do is similar.

That is a good idea also when shipping only a static library.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150719021020.gv8...@fmf.nl

Re: The Spirit of Free Software, or The Reality

[Bas Wijnen]

Hi,

On Thu, Jul 16, 2015 at 06:00:17PM +0200, Simon Richter wrote:
 Am 16.07.2015 um 16:57 schrieb Don Armstrong:
  How easy would it be to modify the code so that it only gets the
  favorite icons when the site is actually visited? [Does it already try
  to update the icons when it visits one of the configured sites?]
 
 The problem is that the icons are displayed in the search field
 dropdown, which should be fully functional before visiting the first site.

Also, if it is acceptable to auto-download them, I don't see why it wouldn't be
acceptable to ship them.  It's one or the other: we want to protect our users
against this non-free material and don't give it to them, or we don't think it
is non-free (or that it is an acceptable exception, just like license texts)
and we do.  In the former case we don't ship and don't download; in the latter
case, we do ship and therefore still don't download.

 I believe that it is acceptable to ship these icons -- while they aren't
 free to modify, there is no real reason why we would need that.

I agree, and it seems Mike will start shipping them, which is good IMO.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150716162105.gs8...@fmf.nl

Re: The Spirit of Free Software, or The Reality

[Bas Wijnen]

On Wed, Jul 15, 2015 at 07:56:42PM +0100, Ian Jackson wrote:
 Right.  I find it disappointing to discover that in Debian we have
 deliberately modified Iceweasl to make this problem worse, even if
 only in a modest way.
... 
 And one thing we could easily do (well, easily from a technical point
 of view, if we could agree to do it) would be to not download the
 icons.  AIUI downloading the icons was a change that was made in
 Debian for DFSG reasons.

I've seen Mike's mail, and agree that his solution is appropriate.  I'd like to
note my opinion on what seems to have happened here though (it may not actually
be what happened, but this is a theoretical argument, so that is irrelevant):

We found that some content was not DFSG free, and therefore we didn't want to
distribute it in Debian.  I don't see how anyone could think that let the
program download the non-free material at first boot is an appropriate
solution for anything in main.  The point of software in main is that our users
trust that we don't put non-free stuff on their machine.  It really doesn't
matter if that stuff comes from the archive or is auto-downloaded from
somewhere else.

I don't expect this to be controversial, but I wanted to mention it anyway,
because nobody did so far, and if there is no consensus about this, I think we
should have a discussion about it.

The problem that nobody mentioned it may be caused by the fact that nobody
really considers those icons non-free, and so having them on our users'
machines isn't a problem.  But then I agree with Ian and Mike, we should just
ship them in the package.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150716051023.gq8...@fmf.nl

Re: The Spirit of Free Software, or The Reality

[Bas Wijnen]

On Wed, Jul 15, 2015 at 01:26:16PM +0900, Mike Hommey wrote:
 On Wed, Jul 15, 2015 at 03:51:42AM +0200, Bas Wijnen wrote:
  On Wed, Jul 15, 2015 at 01:06:28AM +0200, Jakub Wilk wrote:
   POST 
   https://safebrowsing.google.com/safebrowsing/downloads?client=Iceweaselappver=38.1.0pver=2.2key=no-google-api-key
   + a few dozens of GET requests to https://safebrowsing.google.com/
   
   So nothing serious here. It's just casually violating your privacy.
  
  I disagree that the safebrowsing part is not serious, especially considering
  that it continues to send a message there on every new page you visit.  Best
  case the only thing that happens is that Google checks that you aren't 
  visiting
  a dangerous site.  But really?  Does anyone believe that Google does not 
  store
  this data to monitor browsing habits?
 
 FUD is easy. How about documenting yourself on how Safe browsing
 actually works?

Please don't be so harsh.  FUD is about trying to mislead people into thinking
untrue bad things about someone.  I have no bad intentions, and I don't see why
you would think that I do.

I have some experience with safe browsing, but indeed I have not looked up how
it works.  I do know that it continuously sends data to Google, and I have
quite a bit of confidence in their capability and willingness to use that data
for tracking.  From your description it sounds like that is not trivial, but
there are smart people at Google, and they have near infinite resources.

 Hint: urls are _never_ sent to Google. The worst thing
 that Google can know is that the _hash_ of /some/ url you went to, has the
 first n bits matching the first n bits of the hash of one (or multiple)
 of the known malware of phishing urls. Nothing more.

That sounds good, and I believe you that is how it's supposed to work, but I
can't quite match it with my observations.  The first time I encountered safe
browsing was when I was running wireshark for an unrelated reason.  I saw lots
of packets going to a remote server even though I wasn't doing anything on the
network yet.  So I checked which host it was, and it turned out to be Google.
Given that every product they have seems to be targeting maximum gathering of
personal information on people, I worry when my computer is sending a lot of
data to them without me asking for it.

I also note that it sent requests there all the time.  I wasn't even doing
anything with my browser, and I didn't have any sites open that would obviously
keep contact with the server.  I don't remember exactly what happened, but I do
remember that it looked like Iceweasel was sending a lot of information about
me to Google.

As Jakub was saying: just starting it up without even visiting a site yet will
do a POST and a *few dozen* GET requests.  Shouldn't it be waiting with its
checks until it actually knows what to check?  What is it sending them at
browser startup?

So I wanted to make it stop; I can live without the safe browsing feature.  I
couldn't find it anywhere in the regular preferences.  In about:config I
searched for it and there is an enabled flag, which I turned off, but that
didn't actually stop the traffic (is that a bug, or does it disable something
in a different way?)  Eventually I managed to stop it by replacing all the
safebrowsing related urls with empty strings.  I don't like that I need to do
that much work to prevent my computer from contacting Google.  I also don't
think I am obligated to find out the technical details of the protocol before
I'm allowed to complain about it.

All that being said, I agree with Ben that the Iceweasel packaging in Debian is
excellent, and I'm happy to know that this is the case.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150715121808.gp8...@fmf.nl

Re: Cluebat needed: Proper way to reference MathJax.js

[Bas Wijnen]

On Mon, Jul 13, 2015 at 08:01:48PM -0500, Dirk Eddelbuettel wrote:
 | To make it work only when served by a webbrowser, use this:
 | 
 |   script src=/javascript/mathjax/MathJax.js/script
 
 I think this is what I had in mind, thanks!
  
 | ...and make sure javascript-common is installed and in use by the 
 | web-server (all libjs-* packages should recommend it, and it should be 
 | enabled by default for apache).
 
 Hm, libjs-mathjax does not. So I'll add two depends.
  
 | To make it work only offline, use this:
 | 
 |   script src=file://usr/share/javascript/mathjax/MathJax.js/script
 
 Icky that it is either or!
  
 | To make it work both offline and offline, use this:
 | 
 |   script src=/usr/share/javascript/mathjax/MathJax.js/script
 | 
 | ...and edit /etc/apache2/conf-available/javascript-common.conf or 
 | /etc/lighttpd/conf-available/90-javascript-alias.conf to use 
 | /usr/share/javascript/ as base path.

Can't you make a link in the directory of the file referencing it and use
a non-absolute path, i.e. src=MathJax.js?  That should work both locally and
through a browser without any configuration, right?  (Except that the directory
must be served by the web server, of course.)

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150714061610.gk8...@fmf.nl

Re: Cluebat needed: Proper way to reference MathJax.js

[Bas Wijnen]

On Tue, Jul 14, 2015 at 05:56:56AM -0500, Dirk Eddelbuettel wrote:
 | Can't you make a link in the directory of the file referencing it and use
 | a non-absolute path, i.e. src=MathJax.js?  That should work both locally 
 and
 | through a browser without any configuration, right?  (Except that the 
 directory
 | must be served by the web server, of course.)
 
 I could. What I am unsure about is whether the path gets followed (which you
 alude to as well).  I presume it does...

Ah, good point.  AFAIK the default setup for Apache is to allow that if the
link and its target are owned by the same user (which should be the case here).

It's easy enough to test.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150714132251.gl8...@fmf.nl

Re: The Spirit of Free Software, or The Reality

[Bas Wijnen]

On Tue, Jul 14, 2015 at 04:21:07PM +0200, Wouter Verhelst wrote:
 On Mon, Jul 06, 2015 at 02:10:08PM +0800, Paul Wise wrote:
  Perhaps we could run everything in $PATH in virtual machines and log
  all network beyond localhost.
 
 I look forward to not reading your emails anymore ;-P
 
 (or did I misunderstand something?)

I think so; AIUI he was describing a test procedure to automatically check if
anything in the archive initiates network connections without being asked.
It's not a setup to run on a production machine; you are correct that the
machine wouldn't be much use.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150714211847.gm8...@fmf.nl

Re: The Spirit of Free Software, or The Reality

[Bas Wijnen]

On Wed, Jul 15, 2015 at 01:06:28AM +0200, Jakub Wilk wrote:
 POST 
 https://safebrowsing.google.com/safebrowsing/downloads?client=Iceweaselappver=38.1.0pver=2.2key=no-google-api-key
 + a few dozens of GET requests to https://safebrowsing.google.com/
 
 So nothing serious here. It's just casually violating your privacy.

I disagree that the safebrowsing part is not serious, especially considering
that it continues to send a message there on every new page you visit.  Best
case the only thing that happens is that Google checks that you aren't visiting
a dangerous site.  But really?  Does anyone believe that Google does not store
this data to monitor browsing habits?

I'm not saying I have a solution; unsafe sites are a reality, and a static
database delivered with the package is just not good enough.  But it would be
good to try to solve this.  Tor seems like the best service for the job.
However, auto-connecting every Debian machine with Iceweasel installed (which
is pretty much every Debian machine) to Tor may not be the best idea either.

Are there any other ideas?  Am I the only one who thinks this is a big deal?

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150715015142.go8...@fmf.nl

Re: Packaging certain libraries as end-user software

[Bas Wijnen]

Hi,

On Thu, Jul 09, 2015 at 05:26:32PM +0200, Ansgar Burchardt wrote:
 I'm wondering about the shared library packaging requirements in Policy
 for the special case of scientific libraries that are not intended to be
 used by applications, but are to be used by end-users directly,

What does to be used by end users directly mean?  That they will use them to
compile programs?  That's not special.  Because they are used for compiling,
most shared libraries are Build-Depends of other packges, but that's not the
only reason they exist.  All libraries are available for developer end users.

 and that do not have a stable ABI.

That is an issue.  It means that upstream will either need to change the soname
a lot, which is probably not what they do, or that it shouldn't be a shared
library (but a static library instead).

 In particular does splitting out the shared library package provide
 anything useful here? It means additional work for no benefit I can see
 as parallel installation of multiple versions would require having
 multiple -dev packages as well to be useful...

The benefit of changing the soname and package name of a shared library is not
that multiple versions can be used for development, but rather that programs
compiled against an incompatible old version will still work when the new
version is installed.  This is because the old version is not uninstalled from
the system (even if it may be removed from the archive after the dependency is
upgraded there; the old application still links to the old library, which will
remain installed on the user's machine at least until that application is
upgraded or removed).

This is true regardless of whether the application is provided by Debian or
not.  (But if it isn't, it is technically easy to remove the old library and
break the application; the user must take care not to do that.)

 Does anyone see any problems with this plan?

Yes.  The way we handle shared libraries for Debian packages works also for
programs that aren't in Debian.  Your proposal makes it harder for users to
keep their programs running when the library is upgraded (they are forced to
recompile).

Also, to repeat: if the ABI is very unstable, the library should probably not
be distributed as a shared library, but only as a static library.  Then all
those problems don't exist (but you're also missing some benefits, which is why
most libraries should better be shared, with the static version only installed
for special cases).

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150709163908.gd8...@fmf.nl

Accepted openmsx 0.11.0-1 (source all amd64) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sat, 20 Jun 2015 09:27:01 -0400
Source: openmsx
Binary: openmsx openmsx-data
Architecture: source all amd64
Version: 0.11.0-1
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen wij...@debian.org
Changed-By: Bas Wijnen wij...@debian.org
Description:
 openmsx- MSX emulator that aims for perfection
 openmsx-data - datafiles for openMSX, an MSX emulator
Changes:
 openmsx (0.11.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Remove mips cpu detect patch, included in this release.
   * Update standards version to 3.9.6.  (No changes needed.)
   * Move desktop file from data package to package containing executable.
Checksums-Sha1:
 d7e05d23998594b8796e95bede5e2cf2d10ded5f 1992 openmsx_0.11.0-1.dsc
 ecbd854f4ea420a8ac7cb2616b6c9fd6212ed4ba 3249448 openmsx_0.11.0.orig.tar.gz
 b67b4548acb9166d1338a207afc955f447f7f525 9780 openmsx_0.11.0-1.debian.tar.xz
 715097eada8c67736d06fc485d88488fc9058f38 1330152 openmsx-data_0.11.0-1_all.deb
 b66780fce2dc7caf79b89d95faa94f979d9cee8a 1644674 openmsx_0.11.0-1_amd64.deb
Checksums-Sha256:
 dbe7e4b7044ba09a0062c9c8ab107232792996218d094d5ba612b1bf9d55916d 1992 
openmsx_0.11.0-1.dsc
 93611a12b3860f31ef081d625e9e7f68a48c81c564d629801def868a87b75a77 3249448 
openmsx_0.11.0.orig.tar.gz
 d5b6c088c8fb18062ea5b65dc04c853f871ef51a598fac17624f832af815c971 9780 
openmsx_0.11.0-1.debian.tar.xz
 749cabac41faa7b11545264b90f523992c70a98f05d9af18f8021abac66da214 1330152 
openmsx-data_0.11.0-1_all.deb
 a589eebd805b8b4197f6e0cdd2a4bb835affac09ce68743ea8551a2f20572ad5 1644674 
openmsx_0.11.0-1_amd64.deb
Files:
 70d2edf98492919852b64d27fc84db1b 1992 otherosfs optional openmsx_0.11.0-1.dsc
 b6f9c92f3921d9022b89b727c99897f0 3249448 otherosfs optional 
openmsx_0.11.0.orig.tar.gz
 9d04d0d6523b288f04351219ddf84d77 9780 otherosfs optional 
openmsx_0.11.0-1.debian.tar.xz
 bceabd81efe04ab589765a19774eb565 1330152 otherosfs optional 
openmsx-data_0.11.0-1_all.deb
 d5a92c3267084483812760d5ea960d85 1644674 otherosfs optional 
openmsx_0.11.0-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIbBAEBAgAGBQJVj2EeAAoJEJzRfVgHwHE64KwP+MhbdcL5lMQ32f2Um+ZyDazq
6f7cx7bJZLaif5I0NZapAl/R4Z9iOZe+xs1c4hn1OcVRdrcU66knAtl1kG4iLRrb
zJ3BT1mewPXD/3Gn29vTj63HF4+Jf36grN5GWbdimwkxgYe/EXByanyQbk7gn0/C
gdhni5wnI7luZVibMcCY7Hxj5UoXjIyHdGW3ES/dW2G39IwcSlgTF94lnGV/v3eY
uf9opUlvrd3g93a+yhx5zm+PsvGpJ6Dl4q60dCiTAgLFlwQyj5mPyjF3ztqTmVRC
PNa2nI2IEwA5CBde+KetuwlQLcO23+zAGBMJzBNGI2iBoXeldX/olRGJF6Rdt8hk
+xluj6yZ6p9rT+pqAexO/jK+PmygyDtrWu+cqBDS7p/8Eo3gdr5rI0AtAmPORapF
Hy2A12pGkJQhmXxj3Nhw/9dvRPvXSppt8zbLuyEV/fFEKOZOPFTY7PLMBYLQ490V
Z0iiVckkE31xtMqfF/C7/LQlMmJHB1hwYrqnvcaW4WbwQNIO/W1UXdankwduhP3D
NQwYwstHL3QjJEc93I6ncK15meLptd/7+kUKYqWZ7shOKPkaKIZ8XIVR4teQZ6Mv
dTgfMV7l2nC66umyHcmITK6hDH/Mp7o9YGaTc3ySgjIdz9rUIFKt0CrTfTIg6/zo
H9TjP76A6YM8CQBbdY0=
=Qifr
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1z937z-0002rr...@franck.debian.org

Accepted openmsx-catapult 0.11.0-1 (source amd64) into unstable

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sat, 20 Jun 2015 09:25:52 -0400
Source: openmsx-catapult
Binary: openmsx-catapult
Architecture: source amd64
Version: 0.11.0-1
Distribution: unstable
Urgency: medium
Maintainer: Bas Wijnen wij...@debian.org
Changed-By: Bas Wijnen wij...@debian.org
Description:
 openmsx-catapult - GUI for openMSX
Changes:
 openmsx-catapult (0.11.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Update standards version to 3.9.6.  (No changes needed.)
   * Make build verbose.
   * Pass debian build flags to install target to make compilation and relinking
 from there use them.
Checksums-Sha1:
 326790c9ee4d48c77065febd6b027067d871fc44 1815 openmsx-catapult_0.11.0-1.dsc
 59c8c2bacc7ab4273b04ff5c571845d05815fe0f 1404388 
openmsx-catapult_0.11.0.orig.tar.gz
 9af3dabdd68ee3ea9cce2e15e831c7efaa1001fc 8948 
openmsx-catapult_0.11.0-1.debian.tar.xz
 a01ee0e6ce6933e53b2cfec3dac936cf9ecdcd29 402808 
openmsx-catapult_0.11.0-1_amd64.deb
Checksums-Sha256:
 154e29530467fdbe825c70ee24227c394ce3155f02d2705e20d142d5cb112d48 1815 
openmsx-catapult_0.11.0-1.dsc
 a76d9ab9e2000679d8cbc69622232c3d6647493d402bffc19f469749ead15ad2 1404388 
openmsx-catapult_0.11.0.orig.tar.gz
 102e9a35d8f2529d240971c2bf50df96d251df03d0e4c9c1f31f37a7eb63eddc 8948 
openmsx-catapult_0.11.0-1.debian.tar.xz
 30ceb005d117c8e34f8356d13c31e3e5e68031d9d9e9241fa70ac9c934196abd 402808 
openmsx-catapult_0.11.0-1_amd64.deb
Files:
 c928af22ea0d3be03b72b1e4366ec19a 1815 otherosfs optional 
openmsx-catapult_0.11.0-1.dsc
 f112f679923f13a2e548a647b593c763 1404388 otherosfs optional 
openmsx-catapult_0.11.0.orig.tar.gz
 b2baeaa9dd687118f0c057126373aeb5 8948 otherosfs optional 
openmsx-catapult_0.11.0-1.debian.tar.xz
 ec04a811b2c1ae87c490eae24fd357de 402808 otherosfs optional 
openmsx-catapult_0.11.0-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVj2E6AAoJEJzRfVgHwHE6Gk8P/29KtMg+fUOfq6JWfA1JXSoz
DZd12FvD8MelfSGfMaybXvPlANwVl/EBia3EieCWO8fl2uEZWvpiR0Pv08VxH5La
bUUZRwTHO5x0s7bin+pRfFH1ERX+iRk577NyveQGOKDG9582faFdAVKziv4X+YTm
R4EODVP+HJV4ZXlOV4DIuWzi4wwM4Q1H7RyAb+ouMo3Y7QXe6YM4ZR0T7rIIdAw+
ydQzb3Z3V5I8YI10Lca7RIKutd/vDiouMdUmcEbrHM+Sgr0AAjFIsOktmMQntm1f
DZCjE5hweGstWwS+VF35pS3DRcQpuCRkcoJXX7XBzr/rI29GProQ/w1F5IHXo1hE
69Df2KmlweY6GSfWKCoWFK/2Hwe4aL5aZhakB+JIqYLRPD79mQretwyQ3g6LsMTw
Baagw+ntn8SAG1j2DY70Sa2XoChEFezgxSOZ5lHBPlwaJNffIBEZYKTkhoGYfC5r
guPjDlKFROdfKrnVi6MjxfhFcRE852jdpF5xXGIfYurysSchk8jQJ2XezBAuxcRC
2uarAHBzKGJAQJpGwaG3YWQlVcoht/o7CsS5o/c3X4GUDWFu/MdRIzHSV4Rwg4wg
mdC/3NYD1weQvLQpFhYGYD8AbjR3MI4ME6LrirmOxqn+5VCEEtzD9NyVXIZydcib
RVZwnJ/6oPZGe+rehmQG
=06ec
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1z93am-0007oa...@franck.debian.org