Re: debian/copyright format and SPDX

[Paul Wise]

On Fri, 2023-09-08 at 12:09 +0530, Hideki Yamane wrote:

> Making appropriate debian/copyright file is hard and boring task, IMHO

Using scancode-toolkit/etc can probably automate most of that work.

https://wiki.debian.org/CopyrightReviewTools

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: debian/copyright format and SPDX

[Jonas Smedegaard]

Quoting Paul Wise (2023-09-09 09:18:59)
> On Fri, 2023-09-08 at 12:09 +0530, Hideki Yamane wrote:
> 
> > Making appropriate debian/copyright file is hard and boring task, IMHO
> 
> Using scancode-toolkit/etc can probably automate most of that work.
> 
> https://wiki.debian.org/CopyrightReviewTools

Yeah, although that page is aiming at debian/copyright format, not SPDX.

As an example, it does not cover (and I think it would be confusing to
add to it, at least as currently structured) how licensecheck also
supports producing SPDX shortnames e.g. like this (which generates a
slightly **broken** debian/copyright file sude to MIT/Expat difference,
so beware):

  licensecheck --check '.*' --recursive --deb-machine --lines 0 
--shortname-scheme spdx -- *


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature

Bug#1051528: ITP: magic-wormhole-rs -- Rust implementation of Magic Wormhole, with new features and enhancements

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-devel@lists.debian.org, 
pkg-rust-maintain...@alioth-lists.debian.net, werdah...@riseup.net
Control: block 1040664 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: magic-wormhole-rs
  Version : 0.6.0 
  Upstream Contact: piegames , Brian Warner 

* URL : https://github.com/magic-wormhole/magic-wormhole.rs
* License : EUPL 1.2
  Programming Lang: Rust
  Description : Rust implementation of Magic Wormhole, with new features 
and enhancements

- From the upstream page:

New features (over the python version):
- - Can do direct connections across the internet (NATs) and firewalls
- - Automatically copies your code to the clipboard
- - Port forwarding in addition to file transfer (experimental)
- - Send a file to multiple people (experimental)

It's still fully compatible with the python and go implementations in the
archive.

It will be maintained with the Debian Rust team.

thanks,

werdahias


-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmT8MTUVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR15scQAJws31rLNbSpzCmlO8nQIOkPaGPE
LeoEX6a0I/4WhfWmCl2cTV9/hC1Y5rdX6IYp2EwkKCcpo/khFnD3q/2/wUtPKIh6
iA0skzay/JaeuVtvF+KvgvhQA3t1jhB4C2xDxqxAoYIHJz3K8b/cKIMVSFBEz8Tb
Ggbp+D2gO2nWXkzBWG8d2DHhUoqTdghFKtPMN6BgHIZMMqzEj5kyJyx0yuNnzX1q
U6kJd55n6lA4Fl9XTxAixomk1kI+LfaaO3BTjuUIMoYebeiT+nhU6pGdURKdpM2C
JwmR6Grv/xk2GVGEdxWzbKJGmQY/T83jae1sRTqWEsfrJdr1IIoDCZ1e9I478Jqa
NFKDJH/VKdfCzDavLqmpL9i2F0yET7GIm3BRHYNeQqoRRouzhqBKU1puS65+MCTY
6dnCygM423oIFNBKFoQ1IzrjnQ4a/OCVTPjN+wOepD6uQrNlJLIx7aQjwbeRVC9Z
Ha6A91dd9D3fwr85AabAeI6JaHRK92US190RH56nLyz+aMdYM2wHxKiL0TnJ/aAp
z7d1PBHFvKHvT/gK5bcF+YP/7d2i4wu9rgrfhRfUenWTGVGdfz0AL2lq1YUH2ZeD
PFvVau+FQEgrOD7scDfo03GtsCy1c61RBUYzsEmhdqL3CHYBkt+fj8dxKxaBch2c
z0tiBmh34E9jYjqC
=fsA/
-END PGP SIGNATURE-

Bug#1051540: ITP: golang-github-jesseduffield-generics -- Extensions on Go generics packages

[Jongmin Kim]

Package: wnpp
Severity: wishlist
Owner: Jongmin Kim 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-jesseduffield-generics
  Version : 0.0~git20220320.727e535
  Upstream Contact: Jesse Duffield 
* URL : https://github.com/jesseduffield/generics
* License : Expat
  Programming Lang: Go
  Description : Extensions on Go generics packages

 This package provides some helper methods/structs that involve generics.
 The library have enhanced methods and structs for slices, list, set and
 maps.

The package is in the dependency tree of lazygit (#908894)[1,2].

[1] https://bugs.debian.org/908894
[2] https://github.com/jesseduffield/lazygit-debian/wiki/Dependency-graph

Bug#1051549: ITP: node-jsan -- JavaScript "All The Things" Notation

[Yadd]

Package: wnpp
Severity: wishlist
Owner: Yadd 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: node-jsan
  Version : 3.1.14
  Upstream Contact: Moshe Kolodny
  
* URL : https://github.com/kolodny/jsan
* License : Expat
  Programming Lang: JavasCRIPT
  Description : JavaScript "All The Things" Notation

node-jsan Easily stringify and parse any object including objects with
circular references, self references, dates, regexes, `undefined`, errors,
and even functions.

node-jsan is a dependency of node-redux-devtools which is needed by
node-jupyterlab. This package will be maintained under JS Team umbrella.

Re: Kind invitation to join my DebConf BoF "Chatting with ftpmasters"

[Andreas Tille]

Short note:  The print version of the slides has only 25 pages:


https://people.debian.org/~tille/talks/20230911_debconf_ftpmaster_bof/ftpmaster_chat_handout.pdf

Sorry for not mentioning in advance
 Andreas.

Am Sat, Sep 09, 2023 at 07:46:08AM +0200 schrieb Andreas Tille:
> Hi ftpmasters and
> developers who contributed to previous discussion with ftpmaster on this list
> 
> You might have noticed that I registered "Chatting with ftpmasters"[1]
> for Debconf which is scheduled Sep 11 (Mon): 16:30  local time in Kochi
> (just check the website for your local time which is printed as an
> alternative).
> 
> I'd like to invite anybody who is interested to enhance the
> communication to join this BoF either at site or from remote.  Locally
> I'll bring some homemade sweets (quince jelly) for every member of the
> ftpmaster team to thank you for all your work.
> 
> I have put my (preliminary) slides online[2] and I'm open for comments
> and enhancements.  You can also add notes to etherpad[3] in advance.
> 
> Looking forward to meet you in Kochi
> Andreas.
> 
> [1] https://debconf23.debconf.org/talks/31-chatting-with-ftpmasters/
> [2] https://people.debian.org/~tille/talks/20230911_debconf_ftpmaster_bof/
> [3] https://pad.dc23.debconf.org/p/31-chatting-with-ftpmasters
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Bug#1051553: ITP: lib25519 -- X25519/Ed25519 microlibrary

[Jan Mojzis]

Package: wnpp
Severity: wishlist
Owner: Jan Mojzis 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: lix25519
  Version : 20230630
  Upstream Authort: Daniel J. Bernstein
* URL : https://lib25519.cr.yp.to/
* License : LicenseRef-PD-hp OR CC0-1.0 OR 0BSD OR MIT-0 OR MIT
  Programming Lang: C
  Description : X25519 microlibrary


lib25519 is a microlibrary for the X25519 encryption system and the Ed25519 
signature system, both of which use the Curve25519 elliptic curve. Curve25519 
is the fastest curve in TLS 1.3, and the only curve in Wireguard, Signal, and 
many other applications (see Nicolai Brown's page 
https://ianix.com/pub/curve25519-deployment.html).

lib25519 has a very simple stateless API based on the SUPERCOP API, with 
wire-format inputs and outputs, providing functions that directly match the 
central cryptographic operations in X25519 and Ed25519:

lib25519_dh_keypair(pk,sk): X25519 key generation
lib25519_dh(k,pk,sk): shared-secret generation
lib25519_sign_keypair(pk,sk): Ed25519 key generation
lib25519_sign(sm,&smlen,m,mlen,sk): signing
lib25519_sign_open(m,&mlen,sm,smlen,pk): verification + message recovery
Internally, lib25519 includes implementations designed for performance on 
various CPUs, implementations designed to work portably across CPUs, and 
automatic run-time selection of implementations.

lib25519 is intended to be called by larger multi-function libraries, including 
libraries in other languages via FFI. The idea is that lib25519 will take 
responsibility for the details of X25519/Ed25519 computation, including 
optimization, timing-attack protection, and eventually verification, freeing up 
the calling libraries to concentrate on application-specific needs such as 
protocol integration. Applications can also call lib25519 directly.

I'm using this library and I'm going to maintain using https://salsa.debian.org/
I need sponsor for the first upload (I'm DM).

Default font: Transition from DejaVu to Noto

[Gunnar Hjalmarsson]

Hi!

With fontconfig 2.14, which entered testing last January, upstream 
fontconfig prefers Noto over DejaVu in /etc/fonts/conf.d/60-latin.conf. 
The change was not preceded by any discussion I'm aware of. It appears 
to be related to this Fedora measure:


https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts

So Debian was kind of caught off guard.

My personal view is that it is a change in the right direction, and I 
have taken a couple of follow-up steps in Debian. There are still loose 
ends and more work to be done to achieve a consistent configuration in 
this respect. However, before taking further steps, I feel there is a 
need to reach out to a broader audience about the change. Hence this 
message. Basically I'm asking if this move towards Noto is desirable 
and, if so, I plea for relevant input for the completion of the transition.


While this message was crossposted to several mailing lists, since the 
topic affects multiple packages and teams, I suggest that the replies 
are posted to the general debian-devel list only.



The current situation
-
From a Debian POV, the effective default font for sans-serif and serif 
depends on whether the fonts-noto-core package is installed or not. For 
some desktop environments that package is pulled by default. As regards 
the GNOME desktop, fonts-noto-core is not installed by default with 
Debian 12 stable, but it does get pulled if you install trixie via a 
weekly build ISO.


The change as regards GNOME is probably my fault:

https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/5aa10dde

While I thought that that commit wouldn't change much in practice, since 
there typically are other fonts which satisfy the fontconfig-config 
alternative dependency list, it probably does make a difference since 
fontconfig is installed early during the installation process.


Some bugs were filed early this year, where people expressed some 
dissatisfaction. The strongest objections were about the change of the 
monospace font. (fonts-noto-mono is included by default also in Debian 
12 stable with GNOME.) So I addressed that in trixie via a Debian level 
patch which changes the default monospace font back to DejaVu Sans Mono.


So at this time we have these preferences in 60-latin.conf:

sans-serif   Noto Sans
serifNoto Serif
monospaceDejaVu Sans Mono

So far so good. Mostly good IMHO. I can mention that I'm also working 
with fonts in Ubuntu, and similar changes will happen in Ubuntu 23.10.



Some steps to consider
--
These are some points for consideration I have in mind:

* The task-* packages should be reconsidered. At first hand I'm thinking 
of all the non-latin task-* packages which recommend a particular font. 
Let's take task-hindi-desktop as an example, which currently recommends 
fonts-lohit-deva. I think it would be consistent to change that to:


Recommends: fonts-noto-core | fonts-lohit-deva

fonts-noto-core covers "all" scripts, so with that package installed 
there shouldn't be a need to install fonts-lohit-deva. (And for many 
non-latin scripts Noto offers better quality than the other non-latin 
font packages in the archive.)


* Maybe it would be motivated to recommend fonts-noto-core in the 
umbrella package task-desktop too. While fontconfig-config seems to pull 
fonts-noto-core for new installs, I suspect that it wouldn't be pulled 
during an upgrade to Debian trixie.


* System admins have the option to do "dpkg-reconfigure 
fontconfig-config" and that way control some fontconfig symlinks 
affecting things like hinting and subpixel rendering. As regards the 
related templates file I recently made a tiny change that appeared to be 
necessary:


https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/45d8eda0

but I suspect that the feature may need an overhaul also in other 
respects if we change the default font.


* I've noticed the fonts-recommended bug 
https://bugs.debian.org/1051314, which rightly points out the need to 
consider Noto in that context.


* Almost 3 years have passed since the fonts-noto source package was 
last updated from upstream. A new update with latest upstream is desirable.



Looking forward to your response.

--
Cheers,
Gunnar Hjalmarsson

Re: Default font: Transition from DejaVu to Noto

[Paul Wise]

On Sat, 2023-09-09 at 23:08 +0200, Gunnar Hjalmarsson wrote:

> My personal view is that it is a change in the right direction, and I
> have taken a couple of follow-up steps in Debian. There are still loose 
> ends and more work to be done to achieve a consistent configuration in 
> this respect. However, before taking further steps, I feel there is a
> need to reach out to a broader audience about the change. Hence this 
> message. Basically I'm asking if this move towards Noto is desirable 
> and, if so, I plea for relevant input for the completion of the transition.

Personally, I found Noto Mono to be very ugly in comparison to the
DejaVu fonts that I was used to, so my knee-jerk reaction was to
override the fontconfig settings to avoid all of the Noto fonts.
I haven't yet evaluated the non-monospace Noto fonts though.

Related discussion on the various IRC channels suggested that: 

Noto is meant to be a fallback font (something like unifont but
not using bitmaps) not the default font for all or any languages.

Noto makes the font selector useless because each alphabet shows up.
Apparently fixing this requires changing the OpenType file format.

Apparently the Noto meta package installs 700+ MB of font data,
which seems a bit excessive to some folks.

Some folks are setting explicit fonts in applications they use to avoid
relying on system defaults and also seeing changes to those defaults.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

What licenses should be included in /usr/share/common-licenses?

[Russ Allbery]

Hello everyone,

I come seeking your opinions.  Please cc 885...@bugs.debian.org on replies
so that we can accumulate this discussion in a Debian Policy bug.

One of the responsibilities of the Policy Editors is to determine which
licenses should be included in /usr/share/common-licenses, and thus do not
have to be reproduced in the copyright file of every package that use
them.  We have never had a clear criteria for this.  We need one, so that
we can advertise a clear and transparent policy for inclusion without
having the conversation from first principles for each new license.

I was the one who made the last few decisions, and I based the decision
largely on the number of binary packages in Debian using the license.
When I was doing this, I set a fairly high threshold (more packages than
the least popular package currently in /usr/share/common-licenses, which
historically has been GFDL-1.3 although it now appears to be MPL-1.1).  No
one was entirely satisfied with that criteria, including me.

I have the following questions:

1. What criteria (besides the obvious one of being a DFSG-free license)
   should we apply when deciding what licenses to include?  Number of
   packages?  Length?  How positive we feel towards the license?  Some
   combination of these things?  Please be specific.

2. If we use number of packages as a criteria, what should the threshold
   be?  I have appended to the bottom of this message the current output
   of my ad-hoc license-count tool run against the current archive so that
   you have a feeling for how many packages use various licenses.

3. If we use number of packages, should that be source packages or binary
   packages?  Source packages represent maintainer effort; binary packages
   represent disk clutter.

4. Should there be a length cutoff for licenses, such that we do not
   include in /usr/share/common-licenses any license shorter than some
   number of lines or bytes?  The justification would be that telling
   people to go look elsewhere for the license has some inherent overhead
   and annoyance when they discover that the license is all of ten lines
   and could have just been included in the copyright file.

5. Should we exclude licenses that contain text that all or most users of
   the license customize when they use it?  For example, the existing
   /usr/share/common-licenses/BSD contains the clause:

  3. Neither the name of the University nor the names of its
 contributors may be used to endorse or promote products derived
 from this software without specific prior written permission.

   which users of this specific license usually change to instead include
   the name of their organization, or their name, or something else.  Full
   disclosure: it will be very hard to convince me that licenses used this
   way should be included in common-licenses, since I believe it is
   technically incorrect to omit a license and point to the
   common-licenses version when the provisions of the common-licenses
   version are different in detail due to naming different people or
   requiring or prohibiting mentioning of different names as endorsements.

Here are various concerns that people have had in this area in the past.
I'm neither indicating agreement nor disagreement with any of these
points, only listing them to provoke thought about some of the things
people have raised before.

* Including long legal texts in debian/copyright, particularly if one
  wants to format them for copyright-format, is tedious and annoying and
  doesn't benefit our users in any significant way, and therefore we
  should include as many licenses as possible in common-licenses to spare
  people that work.

* common-licenses consumes disk space on every installed Debian system of
  any size, and therefore should be kept small to avoid wasting system
  resources.

* Every appproved DFSG license should be included in common-licenses so
  that it serves as a repository of licenses the project has approved.

* Including a license in common-licenses implies that the project approves
  of that license, and therefore licenses such as the LaTeX Project Public
  License 1.0, which requires renaming derived works, should not be
  included even though DFSG #4 grudgingly allows for this type of license
  term.

* All licenses explicitly mentioned in the Debian Free Software Guidelines
  should be present in common-licenses (as justification for including the
  BSD license even though the current text is specific to the Regents of
  the University of California).

In order to structure the discussion and prod people into thinking about
the implications, I will make the following straw man proposal.  This is
what I would do if the decision was entirely up to me:

Licenses will be included in common-licenses if they meet all of the
following criteria:

* The license is DFSG-free.
* Exactly the same license wording is used by all works covered by it.
* The l

Bug#1051583: ITP: node-fast-json-patch -- Node.js implementation of JSON-Patch

[Yadd]

Package: wnpp
Severity: wishlist
Owner: Yadd 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: node-fast-json-patch
  Version : 3.1.1
  Upstream Contact: Joachim Wester 
* URL : https://github.com/Starcounter-Jack/JSON-Patch
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js implementation of JSON-Patch

node-fast-json-patch is a leaner and meaner implementation of JSON-Patch.
Small footprint. High performance. It can:
 * apply patches (arrays) and single operations on JS object
 * validate a sequence of patches
 * observe for changes and generate patches when a change is detected
 * compare two objects to obtain the difference

node-fast-json-patch is a dependency of node-vega-embed, needed for
node-jupyterlab.

Re: Default font: Transition from DejaVu to Noto

[M. Zhou]

On Sun, 2023-09-10 at 11:23 +0800, Paul Wise wrote:
> On Sat, 2023-09-09 at 23:08 +0200, Gunnar Hjalmarsson wrote:
> 
> > My personal view is that it is a change in the right direction, and
> > I
> > have taken a couple of follow-up steps in Debian. There are still
> > loose 
> > ends and more work to be done to achieve a consistent configuration
> > in 
> > this respect. However, before taking further steps, I feel there is
> > a
> > need to reach out to a broader audience about the change. Hence
> > this 
> > message. Basically I'm asking if this move towards Noto is
> > desirable 
> > and, if so, I plea for relevant input for the completion of the
> > transition.
> 
> Personally, I found Noto Mono to be very ugly in comparison to the
> DejaVu fonts that I was used to, so my knee-jerk reaction was to
> override the fontconfig settings to avoid all of the Noto fonts.
> I haven't yet evaluated the non-monospace Noto fonts though.
> 
> Related discussion on the various IRC channels suggested that: 
> 
> Noto is meant to be a fallback font (something like unifont but
> not using bitmaps) not the default font for all or any languages.
> 
> Noto makes the font selector useless because each alphabet shows up.
> Apparently fixing this requires changing the OpenType file format.
> 
> Apparently the Noto meta package installs 700+ MB of font data,
> which seems a bit excessive to some folks.
> 
> Some folks are setting explicit fonts in applications they use to
> avoid
> relying on system defaults and also seeing changes to those defaults.
> 

I have similar personal feelings. Aesthetic matter differs from person
to person. As font can be seen as kind of artwork, can we make a pool
for the default font just like our wallpaper?

Noto is usually annoying to me. It provides too many "Noto .*" fonts
in whatever software which shows you a font selection menu.
It is likely that at least 1/3 of the whole fonts menu will be
overwhelmed by the Noto .* fonts that I'll never use, even
if I only keep fonts-noto-core and fonts-noto-cjk.

The number of fonts is overwhelming especially when I frequently
change the font in software like libreoffice, inkscape, etc.
I usually end up deleting the ttf files that I will never need.

Just a negative vote on Noto. Anything else is better.

Re: What licenses should be included in /usr/share/common-licenses?

[Jonas Smedegaard]

Quoting Russ Allbery (2023-09-10 05:35:27)
> In order to structure the discussion and prod people into thinking about
> the implications, I will make the following straw man proposal.  This is
> what I would do if the decision was entirely up to me:
> 
> Licenses will be included in common-licenses if they meet all of the
> following criteria:
> 
> * The license is DFSG-free.
> * Exactly the same license wording is used by all works covered by it.
> * The license applies to at least 100 source packages in Debian.
> * The license text is longer than 25 lines.

I fully support the above proposed criteria, and appreciate your
initiative to have this conversation.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature

Re: What licenses should be included in /usr/share/common-licenses?

[Hideki Yamane]

On Sat, 09 Sep 2023 20:35:27 -0700
Russ Allbery  wrote:
> Licenses will be included in common-licenses if they meet all of the
> following criteria:

 How about just pointing SPDX licenses URL for whole license text and
 lists DFSG-free licenses from that? (but yes, we should adjust short
 name of licenses for DEP-5 and SPDX for it).


-- 
Hideki Yamane 

Re: What licenses should be included in /usr/share/common-licenses?

[Enrico Zini]

On Sat, Sep 09, 2023 at 08:35:27PM -0700, Russ Allbery wrote:

> Licenses will be included in common-licenses if they meet all of the
> following criteria:
> 
> * The license is DFSG-free.
> * Exactly the same license wording is used by all works covered by it.
> * The license applies to at least 100 source packages in Debian.
> * The license text is longer than 25 lines.

I like this. I'd say that even if a license is shorter than 25 lines I'd
appreciate to be able to link to it instead of copypasting it.

I like to be able to fill the license field with a value, after checking
that the upstream license didn't diverge from what it looks like. I'd
love to use SPDX IDs there, for example. In an ideal world, I'd like to
autofill debian/copyright with SPDX IDs from upstream metadata. Having a
link to a file goes closer to having a declarative license ID.

In general the less bytes I have to maintain in debian/* the happier I
am, and as a personal aesthetic sense I feel like the less bytes we all
have to maintain in debian/* the less is our collective maintenance
burden.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 

Re: What licenses should be included in /usr/share/common-licenses?

[Russ Allbery]

Hideki Yamane  writes:
> Russ Allbery  wrote:

>> Licenses will be included in common-licenses if they meet all of the
>> following criteria:

>  How about just pointing SPDX licenses URL for whole license text and
>  lists DFSG-free licenses from that? (but yes, we should adjust short
>  name of licenses for DEP-5 and SPDX for it).

Can we do this legally?  If we can, it certainly has substantial merits,
but I'm not sure that this satisfies the requirement in a lot of licenses
to distribute a copy of the license along with the work.  Some licenses
may allow that to be provided as a URL, but I don't think they all do
(which makes sense since people may receive Debian on physical media and
not have Internet access).

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