Bug#1051588: ITP: rust-pkcs8 -- pure Rust implementation of PKCS#8

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-pkcs8
  Version : 0.10.2
  Upstream Contact: RustCrypto Developers
* URL : https://github.com/rustcrypto/formats
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : pure Rust implementation of PKCS#8

 The pkcs8 crate is a pure Rust implementation
 of Public-Key Cryptography Standards (PKCS) #8:
 Private-Key Information Syntax Specification (RFC 5208).
 .
 PKCS#8 is a format for cryptographic private keys,
 often containing pairs of private and public keys.

This package will be maintained in the collaborative Debian section of
salsa, at .
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmT9apgACgkQLHwxRsGg
ASF3EhAApqSs0osaDj0TKQHPOsojxNNsEfYy9JeKhlkg1oJCF12v607EMlZc2o0x
VQNh7cQTJUIASLoh965ntMOkfpclAPmqGqW0/D0V+ECDsCN7iaMnggllgxXnG/Yi
6nZumKICsQQu6wJME2T3a3gOaOoRIW591P+x26EFO4fABiDLz29ARnc24zNQknEy
XL/xeN7A+MemMKub2pzYp8tqssGB8L/ARw31zqP5tjKyPAeEMFbVr59HfWqJrdU5
PcWiAGrYEC+MBfeO16a3tV6bot0Yomh6NetvbiYiOC5nEtq9tTIaOudON+0zIbom
FcvPAKW2H6C1xCVg9T87iwsFjntbUn+mnVsXyhDUZYa/6bKO16mswuD0ZEDBN++Z
w/l/DoQtrbP7WgYHeJONYJJADwZy334/m5MqukryjPxr9mYuW5/5M70cK5naWLuV
7M2HYi3lbefHvd3zbxh7UeqYXUq0yARnh8USyC9g4cR57d9rnNKwJbMixlTLrzfj
tNZMYQI3U+hSn8rGXEWAjPk3n9QOAMPhRVotP/lFLX5u5UU+1yGrIebBD6G7Wf27
vnX0t0el0ME1kBnPOdtvKD1f5qHH7Om0++0y9Vu6o2MbSJRnTRlJ4cBtT8+JCZ9Y
rLeawJcuVdrle2lYFDMUixrh9N4o50Q+id0Qo0i3Qxecmb/GNO8=
=KMXB
-END PGP SIGNATURE-

Bug#1051590: general: Received error from D-Bus search

[WR]

Package: general
Severity: normal
X-Debbugs-Cc: kru...@gmail.com

Dear Maintainer,

Received error from D-Bus search provider org.gnome.Terminal.desktop:
Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Obiekt nie
istnieje w ścieżce „/org/gnome/Terminal/SearchProvider”

Bug#1051591: ITP: node-vega-tooltip -- Tooltip for node-vega and node-vega-lite

[Yadd]

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

* Package name: node-vega-tooltip
  Version : 0.33.0
  Upstream Contact: https://github.com/vega/vega-tooltip/issues
* URL : https://github.com/vega/vega-tooltip
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : Tooltip for node-vega and node-vega-lite

node-vega-tooltip is a tooltip plugin for Vega and Vega-Lite visualizations.
This plugin implements a custom tooltip handler for Vega that uses custom
HTML tooltips instead of the HTML title attribute.

This is a dependency of node-jupyterlab. It will be maintained under JS
Team umbrella.

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

[Hideki Yamane]

On Sat, 09 Sep 2023 22:41:48 -0700
Russ Allbery  wrote:
> >  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).

 Hmm, how about providing license-common package and that depends on
 "license-common-list", and ISO image provides both, then? It would be
 no regressions.


 I expect license-common-list data as below

 license-short-name: URL
 GPL-2: file:///usr/share/common-licenses/GPL-2
 Boost-1.0: https://spdx.org/licenses/BSL-1.0.html

-- 
Hideki Yamane 

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

[Marco d'Itri]

On Sep 10, Enrico Zini  wrote:

> 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.
Me too.

> 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.
Agreed.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Jonas Smedegaard]

Quoting Hideki Yamane (2023-09-10 11:00:07)
> On Sat, 09 Sep 2023 22:41:48 -0700
> Russ Allbery  wrote:
> > >  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).
> 
>  Hmm, how about providing license-common package and that depends on
>  "license-common-list", and ISO image provides both, then? It would be
>  no regressions.
> 
> 
>  I expect license-common-list data as below
> 
>  license-short-name: URL
>  GPL-2: file:///usr/share/common-licenses/GPL-2
>  Boost-1.0: https://spdx.org/licenses/BSL-1.0.html

Ah, so what you propose is to use file URIs.

I guess Russ' response above was a concern over using http(s) URIs
towards a non-local resource.

What I practice since some years is the following syntax:

Files: foo/bar
Copyright:
  2022  Someone
License: Apache-2.0 or Expat

License: Apache-2.0
Reference: /usr/share/common-licenses/Apache-2.0

License: Expat
 [the full contents of the Expat license]

That syntax introduces a new field "Reference" (our copyright file
format permits new fields, despite lintian complaining about it).
Related discussion is at https://bugs.debian.org/786450


 - 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#1051601: ITP: node-geojson -- Node.js library to convert geo data into GeoJSON

[Yadd]

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

* Package name: node-geojson
  Version : 0.5.0
  Upstream Contact: Casey Cesari
  
* URL : https://github.com/caseycesari/geojson.js
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js library to convert geo data into GeoJSON

node-geojson is a dependency of node-vega-lite and a TS dependency of
node-d3. It will be maintained under JS Team umbrella.

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

[Luca Boccassi]

On Sun, 10 Sept 2023 at 04:36, 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.

+1, great work and great starting point.

I also agree with Enrico and I'd like lower limits too, but any
progress is good progress on this matter for me.

Bug#1051608: ITP: node-d3-geo-projection -- Extended geographic projections for node-d3-geo

[Yadd]

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

* Package name: node-d3-geo-projection
  Version : 4.0.0
  Upstream Contact: Mike Bostock 
* URL : https://d3js.org/d3-geo-projection/
* License : ISC
  Programming Lang: JavaScript
  Description : Extended geographic projections for node-d3-geo

node-d3-geo-projection provides extended geographic projections for
node-d3-geo. It's a dependency of node-vega-lite, needed to build
node-jupyterlab. It will be maintained under JS Team umbrella.

Re: Default font: Transition from DejaVu to Noto

[Praveen Arimbrathodiyil]

On 10 September 2023 2:38:38 am IST, Gunnar Hjalmarsson  
wrote:
>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.)

For Malayalam, we prefer traditional script font by default. Noto Malayalam 
coverage is not in traditional script.

>* 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.
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

/usr/-only image

[Nils Kattenbeck]

Hello,

I am looking to generate a Debian image with only a /usr and /var
partition as per discoverable partition specification. However, it
seems to me like the omission of /etc leads to several issues in core
packages and logging in becomes impossible.
Is this an unsupported use case and if yes, is there ongoing work to
eventually support this?
Many packages in Fedora for example are already configured to support
this using systemd-sysuser, systemd-tmpfiles, and other declarative
means stored in /usr/ to create any required files upon boot.

Kind regards, Nils

Re: Default font: Transition from DejaVu to Noto

[The Wanderer]

On 2023-09-09 at 23:23, 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.

While I concur and have done the same, I am not sure why DejaVu is the
alternative default under discussion.

Prior to the switch to Noto, the default preferred font family (listed
first in /etc/fonts/conf.d/60-latin.conf) was not DejaVu; that was, as
it still is, listed as the second preference. The font family listed as
the first preference was Bitstream Vera.

The change made appears to have been, not moving Noto up in the list
from a lower position, but rather replacing Bitstream Vera entirely with
Noto.

I have just grabbed version 2.13.1-4.5 of fontconfig-config from
snapshots.debian.org to confirm. Comparing preference order
60-latin.conf from that version against the one from the package version
currently installed on my system, I see:

 2.13.1-4.5   2.14.2-4
Bitstream Vera   firstnot listed
DejaVu   second   second
Noto not listed   first


If the intended design is that people who prefer one of the
lower-priority entries in the 60-latin.conf lists should remove the
packages that provide the fonts listed with higher preference priority,
then it seems problematic for the former highest-priority option to be
omitted entirely.

Rather than discussing only Noto vs. DejaVu, is there any possibility of
reintroducing Bitstream Vera as a default-font option (even if with a
low priority), for systems which have that installed?


For myself, I have worked around this (since March, when I first noticed
the change) by copying the 2.13.1-4.5 version of 60-latin.conf into
~/.config/fontconfig/conf.d/. That approach appears to mean that I will
miss out on any potentially-desirable changes that may be introduced in
this file in the future, but it was the only way of bringing back
Bitstream Vera as the preferred default font (without
risking having the changes overwritten on a future package update) that
I could find.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

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

[Russ Allbery]

Jonas Smedegaard  writes:
> Quoting Hideki Yamane (2023-09-10 11:00:07)

>>  Hmm, how about providing license-common package and that depends on
>>  "license-common-list", and ISO image provides both, then? It would be
>>  no regressions.

I do wonder why we've never done this.  Does anyone know?  common-licenses
is in an essential package so it doesn't require a dependency and is
always present, and we've leaned on that in the past in justifying not
including those licenses in the binary packages themselves, but I'm not
sure why a package dependency wouldn't be legally equivalent.  We allow
symlinking the /usr/share/doc directory in some cases where there is a
dependency, so we don't strictly require every binary package have a
copyright file.

>>  I expect license-common-list data as below
>> 
>>  license-short-name: URL
>>  GPL-2: file:///usr/share/common-licenses/GPL-2
>>  Boost-1.0: https://spdx.org/licenses/BSL-1.0.html

> Ah, so what you propose is to use file URIs.

> I guess Russ' response above was a concern over using http(s) URIs
> towards a non-local resource.

Yes, I think the https URL is an essential part of the first proposal,
since it avoids needing to ship a copy of all of the licenses.  But I'm
dubious that would pass legal muster.

The alternative proposal as I understand it would be to haave a
license-common package that includes full copies of all the licenses with
some more relaxed threshold requirement and have packages that use one of
those licenses depend on that package.  (This would obviously require a
maintainer be found for the license-common package.)

> License: Apache-2.0
> Reference: /usr/share/common-licenses/Apache-2.0

This is separate from this particular bug, but I would love to see the
pointer to common-licenses turned into a formal field of this type in the
copyright format, rather than being an ad hoc comment.

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

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

[Russ Allbery]

Russ Allbery  writes:

> 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.

In the thread so far, there's been a bit of early convergence around my
threshold of 100 packages above.  I want to make sure people realize that
this is a very conservative threshold that would mean saying no to most
new license inclusion requests.

My guess is that with the threshold set at 100, we will probably add
around eight new licenses with the 25 line threshold (AGPL-2,
Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and
OFL-1.1, and I'm not sure about some of those because the CC licenses have
variants that would each have to reach the threshold independently; my
current ad hoc script does not distinguish between the variants), and
maybe 10 to 12 total without that threshold (adding Expat, zlib, some of
the BSD licenses).  This would essentially be continuing current practice
except with more transparent and consistent criteria.  It would mean not
including a lot of long legal license texts that people have complained
about having to duplicate, such as the CDDL, CeCILL licenses, probably the
EPL, the Unicode license, etc.

If that's what people want, that's what we'll do; as I said, that's what I
would do if the choice were left entirely up to me.  But I want to make
sure I give the folks who want a much more relaxed standard a chance to
speak up.

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

Re: /usr/-only image

[Marco d'Itri]

On Sep 10, Nils Kattenbeck  wrote:

> I am looking to generate a Debian image with only a /usr and /var
> partition as per discoverable partition specification. However, it
> seems to me like the omission of /etc leads to several issues in core
> packages and logging in becomes impossible.
> Is this an unsupported use case and if yes, is there ongoing work to
> eventually support this?
There are some people generally working in this area, but I fear that 
we are still far from being able to support an empty /etc/.
Still, it would be very good to start documenting what needs to be 
fixed.

I suggest that you join #debian-systemd.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Jonas Smedegaard]

Quoting Russ Allbery (2023-09-10 18:16:07)
> Russ Allbery  writes:
> 
> > 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.
> 
> In the thread so far, there's been a bit of early convergence around my
> threshold of 100 packages above.  I want to make sure people realize that
> this is a very conservative threshold that would mean saying no to most
> new license inclusion requests.
> 
> My guess is that with the threshold set at 100, we will probably add
> around eight new licenses with the 25 line threshold (AGPL-2,
> Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and
> OFL-1.1, and I'm not sure about some of those because the CC licenses have
> variants that would each have to reach the threshold independently; my
> current ad hoc script does not distinguish between the variants), and
> maybe 10 to 12 total without that threshold (adding Expat, zlib, some of
> the BSD licenses).  This would essentially be continuing current practice
> except with more transparent and consistent criteria.  It would mean not
> including a lot of long legal license texts that people have complained
> about having to duplicate, such as the CDDL, CeCILL licenses, probably the
> EPL, the Unicode license, etc.
> 
> If that's what people want, that's what we'll do; as I said, that's what I
> would do if the choice were left entirely up to me.  But I want to make
> sure I give the folks who want a much more relaxed standard a chance to
> speak up.

Good point.

Another way of reading the responses is that there was some interest in
including even more licenses.

I would also prefer inclusion of more licenses, simply had the
impression that a) we could do that step by step, and b) my habit of
writing copyright files (and other teksts) using [semantic linebreaks]
made me forget that Expat license is arguably only 3 lines long (whereas
in my style of writing it is 24-25 lines long).

If "include all SPDX licenses" is for some reason (space in minimal
systems?) problematic, then let me propose a threshold of 1000
characters - as that just about covers Expat ;-)


 - Jonas


[semantic linebreaks]: https://sembr.org/

-- 
 * 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: Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Bill Allombert]

On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> > Quoting Hideki Yamane (2023-09-10 11:00:07)
> 
> >>  Hmm, how about providing license-common package and that depends on
> >>  "license-common-list", and ISO image provides both, then? It would be
> >>  no regressions.
> 
> I do wonder why we've never done this.  Does anyone know?  common-licenses
> is in an essential package so it doesn't require a dependency and is
> always present, and we've leaned on that in the past in justifying not
> including those licenses in the binary packages themselves, but I'm not
> sure why a package dependency wouldn't be legally equivalent.  We allow
> symlinking the /usr/share/doc directory in some cases where there is a
> dependency, so we don't strictly require every binary package have a
> copyright file.

Or we could generate DEBIAN/copyright from debian/copyright using data in
license-common-list at build time. So maintainers would not need to manage the 
copying
themselves.

Cheers,
Bill

Bug#1051628: ITP: node-d3-delaunay -- Node.js fast library for computing the Voronoi diagram

[Yadd]

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

* Package name: node-d3-delaunay
  Version : 6.0.4
  Upstream Contact: Observable, Inc.
  
* URL : https://github.com/d3/d3-delaunay
* License : ISC
  Programming Lang: JavaScript
  Description : Node.js fast library for computing the Voronoi diagram

node-d3-delaunay is a fast library for computing the Voronoi diagram of a set
of two-dimensional points. It is based on included node-delaunator, a fast
library for computing the Delaunay triangulation using sweep algorithms.
The Voronoi diagram is constructed by connecting the circumcenters of
adjacent triangles in the Delaunay triangulation.

It's a missing dependency of node-vega, needed to build node-jupyterlab

Re: /usr/-only image

[Luca Boccassi]

On Sun, 10 Sept 2023 at 18:55, Nils Kattenbeck  wrote:
>
> Hello,
>
> I am looking to generate a Debian image with only a /usr and /var
> partition as per discoverable partition specification. However, it
> seems to me like the omission of /etc leads to several issues in core
> packages and logging in becomes impossible.
> Is this an unsupported use case and if yes, is there ongoing work to
> eventually support this?
> Many packages in Fedora for example are already configured to support
> this using systemd-sysuser, systemd-tmpfiles, and other declarative
> means stored in /usr/ to create any required files upon boot.

It is being slowly worked towards, but we are still at the
prerequisites at this time. Hopefully we'll have some usable
experiments for the Trixie timeline, but nothing definite yet.

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

[Jeremy Stanley]

On 2023-09-09 20:35:27 -0700 (-0700), Russ Allbery wrote:
[...]
> Finally, as promised, here is the count of source packages in
> unstable that use the set of licenses that I taught my script to
> look for.  This is likely not accurate; the script uses a bunch of
> heuristics and guesswork.
[...]

I'm surprised, for example, by the absence of the ISC license given
that not only ISC's software but much of that originating from the
OpenBSD ecosystem uses it. My personal software projects also use
the ISC license. Are you aggregating the "License:" field in
copyright files too, or is it really simply a hard-coded list of
matching patterns?

Regardless, this is great work, thanks for kicking off the
reevaluation!
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

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

[Russ Allbery]

Jeremy Stanley  writes:

> I'm surprised, for example, by the absence of the ISC license given that
> not only ISC's software but much of that originating from the OpenBSD
> ecosystem uses it. My personal software projects also use the ISC
> license. Are you aggregating the "License:" field in copyright files
> too, or is it really simply a hard-coded list of matching patterns?

It's only a hard-coded list of matching patterns, and it doesn't match any
of the short licenses because historically I wasn't considering them (with
the exception of common-licenses references to the BSD license, which I
kind of would like to make an RC bug and clean up so that we could remove
the BSD license from common-licenses on the grounds that it's specific to
only the University of California and confuses people).  If we go with any
sort of threshold, the script will need serious improvements.

That was something else I wanted to ask: I've invested all of a couple of
hours in this script, and would be happy to throw it away in favor of
something that tries to do a more proper job of classifying the licenses
referenced in debian/copyright.  Has someone already done this (Jonas,
perhaps)?

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

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

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Bill Allombert (2023-09-10 18:29:36)
> On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote:
> > Jonas Smedegaard  writes:
> > > Quoting Hideki Yamane (2023-09-10 11:00:07)
> > >>  Hmm, how about providing license-common package and that depends on
> > >>  "license-common-list", and ISO image provides both, then? It would be
> > >>  no regressions.
> > 
> > I do wonder why we've never done this.  Does anyone know?  common-licenses
> > is in an essential package so it doesn't require a dependency and is
> > always present, and we've leaned on that in the past in justifying not
> > including those licenses in the binary packages themselves, but I'm not
> > sure why a package dependency wouldn't be legally equivalent.  We allow
> > symlinking the /usr/share/doc directory in some cases where there is a
> > dependency, so we don't strictly require every binary package have a
> > copyright file.
> 
> Or we could generate DEBIAN/copyright from debian/copyright using data in
> license-common-list at build time. So maintainers would not need to manage
> the copying themselves.

I very much like this idea. The main reason maintainers want more licenses in
/usr/share/common-licenses/ is so that they do not anymore have humongous
d/copyright files with all license texts copypasted over and over again. If
long texts could be reduced to a reference that get expanded by a machine it
would make debian/copyright look much nicer and would make it easier to
maintain while at the same time shipping the full license text in the binary
package.

Does anybody know why such an approach would be a bad idea?

I have zero legal training so the only potential problem with this approach
that I was able to come up with is, that then the source package itself would
not anymore contain the license text and thus we would be shipping code covered
by a license that states that the code may only be distributed with the license
text alongside it without that text. So while auto-generating this would
probably create compliant binary packages, it would leave the source package
without the license text. Is that a problem?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1051637: ITP: python-bitmath -- handle file sizes with different prefix notations

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-bitmath
  Version : 1.3.3.1
  Upstream Contact: Tim Bielawa 
* URL : https://github.com/tbielawa/bitmath
* License : Expat
  Programming Lang: Python
  Description : handle file sizes with different prefix notations

 bitmath simplifies many facets of interacting with file sizes in various units.
 Originally focusing on file size unit conversion, functionality now includes:
  * Converting between SI and NIST prefix units (kB to GiB)
  * Converting between units of the same type (SI to SI, or NIST to NIST)
  * Automatic human-readable prefix selection (like in hurry.filesize)
  * Basic arithmetic operations (subtracting 42KiB from 50GiB)
  * Rich comparison operations (1024 Bytes == 1KiB)
  * bitwise operations (<<, >>, &, |, ^)
  * Reading a device's storage capacity (Linux/OS X support only)
  * argparse integration as a custom type
  * click integration as a custom parameter type
  * progressbar integration as a better file transfer speed widget
  * String parsing
  * Sorting
 .
 In addition to the conversion and math operations, bitmath provides human
 readable representations of values which are suitable for use in interactive
 shells as well as larger scripts and applications. The format produced for
 these representations is customizable via the functionality included in stdlibs
 string.format.

I intend to maintain this package as part of DPT.

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmT+GqMbHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqHmIH/iK1ORX0zi4vefRUgYLL
Xlr8MOW83uJzOOTUOF2jfz6Qs/mIYxekeRHR8tAAY4yG37JTRcqgJHtF9GN+XdSx
mrpyRgP8TK0Z9mdDoVd9n0eICK3DLTAePR5zOF/o9CBaEjHkO11851+wU76TNBDU
PXF0853o4z5AcDTlpF5glssHuKLgMlq5jpPXdKJPl1lKo8/ztgs8adC1cBsaUomD
NBCSTGAxerccfHydI0N/V12lmGjR5uHfeTR4gkbHhNx8TEXmwtfNNYvo4jNiPTq0
dzcOn7AY3DhPhgCKkH0UzP0aHncSBwwrMyfNkXHhAC74/Nx25jXXG8BhYNxit9zU
rak=
=30pw
-END PGP SIGNATURE-

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

[G. Branden Robinson]

At 2023-09-10T21:47:36+0200, Johannes Schauer Marin Rodrigues wrote:
> Quoting Bill Allombert (2023-09-10 18:29:36)
> > On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote:
> > > Jonas Smedegaard  writes:
> > > >>  Hmm, how about providing license-common package and that
> > > >>  depends on "license-common-list", and ISO image provides both,
> > > >>  then? It would be no regressions.
> > > 
> > > I do wonder why we've never done this.  Does anyone know?
> > > common-licenses is in an essential package so it doesn't require a
> > > dependency and is always present, and we've leaned on that in the
> > > past in justifying not including those licenses in the binary
> > > packages themselves, but I'm not sure why a package dependency
> > > wouldn't be legally equivalent.  We allow symlinking the
> > > /usr/share/doc directory in some cases where there is a
> > > dependency, so we don't strictly require every binary package have
> > > a copyright file.
> > 
> > Or we could generate DEBIAN/copyright from debian/copyright using data in
> > license-common-list at build time. So maintainers would not need to manage
> > the copying themselves.
[...]
> I have zero legal training so the only potential problem with this approach
> that I was able to come up with is, that then the source package itself would
> not anymore contain the license text

...why wouldn't it?  Remember how a source package is defined:

A DSC file, an upstream source archive (maybe more than one in exciting
new source formats I haven't learned), and a compressed diff of Debian
changes.

Debian _source_ packages generally don't chop copyright notices and
license texts out the upstream distributions, and should not do so
unless those notices/texts are invalid or the material they cover has
been removed.  (Both of these do sometimes happen.)

Even if one worries about theoretical liability due to the existence of
separate files for .dsc, .tar.gz, and .diff.gz, then let us recall that
(1) the DSC is minimal, containing metadata that may not rise to the
threshold or originality required by copyright [in the U.S., anyway];
(2) the upstream archive has the notices and texts that the _original
distributor_ put in it, and as a rule, if permission to distribute the
work exists, it is not incumbent on redistributors to add notices/texts
where the rightsholder themselves neglected to do so; and (3) the
.diff.gz will not be in the business of removing notices/texts except as
contemplated in the previous paragraph (correcting erroneous
notices).[1]

> and thus we would be shipping code covered by a license that states
> that the code may only be distributed with the license text alongside
> it without that text.

I don't think that is a risk as long as people continue to follow
packaging practices that Debian has applied with little objection from
our upstreams for 25+ years.[2]

> So while auto-generating this would probably create compliant binary
> packages, it would leave the source package without the license text.

I am unable to imagine the mechanism by which that would happen, given
what Russ and Bill proposed.

Regards,
Branden

[1] When repackaging, e.g., to remove non-free material, affected
content is removed altogether even from the source.  Nothing in
copyright law can compel you to distribute copyright notices and
texts that don't apply to work you're not distributing.[3]

[2] I don't know of Debian _ever_ having had a problem, as in receiving
a cease-and-desist letter or other threat of legal action with what
one might term an "institutional" copyright holder.  We've certainly
had our share of nasty emails from cantankerous individual copyright
holders, often who had their own perverse misreadings of licenses
drafted by others (hello to the memory of Jörg Schilling).  There
also was once an upstream who stuck a Trojan horse into the source
code to try to get Debian's users to stop using versions we
distributed, but to go directly upstream instead.  Nowadays, that
seems quaint; you can today Trojan your machine much more
conveniently with npm(1).

[3] At the same time a few non-free FSF manuals under the GNU FDL
declaim the GNU _GPL_ text to be an Invariant Section.  Like most of
the defects of the FDL, I think this is a pointless encumbrance; if
you distribute GPL'ed software, a copy of its text must come along
anyway.  The only rationale I can imagine is to mandate, for printed
copies of the manuals, the inclusion of the GPL's preachy preamble.
But I digress.


signature.asc
Description: PGP signature

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

[Russ Allbery]

Johannes Schauer Marin Rodrigues  writes:

> I very much like this idea. The main reason maintainers want more
> licenses in /usr/share/common-licenses/ is so that they do not anymore
> have humongous d/copyright files with all license texts copypasted over
> and over again. If long texts could be reduced to a reference that get
> expanded by a machine it would make debian/copyright look much nicer and
> would make it easier to maintain while at the same time shipping the
> full license text in the binary package.

> Does anybody know why such an approach would be a bad idea?

I can think of a few possible problems:

* I'm not sure if we generate binary package copyright files at build time
  right now, and if all of our tooling deals with this.  I had thought
  that we prohibited this, but it looks like it's only a Policy should and
  there isn't a mention of it in the reject FAQ, so I think I was
  remembering the rule for debian/control instead.  Of course, even if
  tools don't support this now, they could always be changed.

* If ftp-master has to review the copyright files of each binary package
  separate from the copyright file of the source package (I think this
  would be an implication of generating the copyright files during build
  time), and the binary copyright files have fully-expanded licenses, that
  sounds like kind of a pain for the ftp-master reviewers.  Maybe we can
  deal with this with better tooling, but someone would need to write
  that.

* If we took this to its logical end point and did this with the GPL as
  well, we would add 20,000 copies of the GPL to the archive and install a
  *lot* of copies on the system.  Admittedly text files are small and
  disks are large, but this still seems a little excessive.  So maybe we
  still need to do something with common-licenses?

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

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

[Timo Röhling]

* Russ Allbery  [2023-09-10 09:16]:

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.


In the thread so far, there's been a bit of early convergence around my
threshold of 100 packages above.  I want to make sure people realize that
this is a very conservative threshold that would mean saying no to most
new license inclusion requests.

My guess is that with the threshold set at 100, we will probably add
around eight new licenses with the 25 line threshold (AGPL-2,
Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and
OFL-1.1, and I'm not sure about some of those because the CC licenses have
variants that would each have to reach the threshold independently; my
current ad hoc script does not distinguish between the variants), and
maybe 10 to 12 total without that threshold (adding Expat, zlib, some of
the BSD licenses).  This would essentially be continuing current practice
except with more transparent and consistent criteria.  It would mean not
including a lot of long legal license texts that people have complained
about having to duplicate, such as the CDDL, CeCILL licenses, probably the
EPL, the Unicode license, etc.

If that's what people want, that's what we'll do; as I said, that's what I
would do if the choice were left entirely up to me.  But I want to make
sure I give the folks who want a much more relaxed standard a chance to
speak up.


For me, this outcome would already be an improvement over the current
situation and alleviate my biggest pain point (CC licenses).
Still, I'd like to be significantly more relaxed.

I propose the following three criteria must be satisfied for
inclusion in /usr/share/common-licenses:

 * The license is DFSG-free.
 * Exactly the same license wording is used by all works covered by it.
 * The license is in the SPDX list of common licenses 
(https://spdx.org/licenses/)
   OR
   The license applies to at least 100 source packages in Debian.


I am not committed to the 100 source packages threshold, it is
mostly intended as fallback for a hypothetical future license which
is super popular but for some reason does not make it to the SPDX
list in a timely manner.

One very intentional side effect of my proposal is a nudge towards
using SPDX License Identifiers in d/copyright files.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: /usr/-only image

[Russ Allbery]

Luca Boccassi  writes:
> On Sun, 10 Sept 2023 at 18:55, Nils Kattenbeck  wrote:

>> I am looking to generate a Debian image with only a /usr and /var
>> partition as per discoverable partition specification. However, it
>> seems to me like the omission of /etc leads to several issues in core
>> packages and logging in becomes impossible.

>> Is this an unsupported use case and if yes, is there ongoing work to
>> eventually support this?

>> Many packages in Fedora for example are already configured to support
>> this using systemd-sysuser, systemd-tmpfiles, and other declarative
>> means stored in /usr/ to create any required files upon boot.

> It is being slowly worked towards, but we are still at the prerequisites
> at this time. Hopefully we'll have some usable experiments for the
> Trixie timeline, but nothing definite yet.

Just to make this explicit, one of the prerequisites that has not yet
happened is for Debian to agree that this is even something that we intend
to do.

So far as I know, no one has ever made a detailed, concrete proposal for
what the implications of this would be for Debian, what the transition
plan would look like, and how to address the various issues that will
arise.  Moving configuration files out of /etc, in particular, is
something I feel confident saying that we do not have any sort of project
consensus on, and is not something Debian as a project (as opposed to
individuals within the project) is currently planning on working on.

That doesn't mean we won't eventually do this, or that people aren't
working on other prerequisites, or that it's not something that we're
considering.  But I just want to make clear that we are so early in this
process that it is not at all clear that we are even going to do this at
all, and there is a substantial discussion that would need to happen and
detailed design proposal that would need to be written before there is any
chance whatsoever that Debian will officially support this configuration.
(This does not rule out the possibility that certain carefully-crafted
configurations with a subset of packages may work in this mode, of
course.)

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

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

[Jonas Smedegaard]

Quoting Russ Allbery (2023-09-10 21:41:59)
> Jeremy Stanley  writes:
> 
> > I'm surprised, for example, by the absence of the ISC license given that
> > not only ISC's software but much of that originating from the OpenBSD
> > ecosystem uses it. My personal software projects also use the ISC
> > license. Are you aggregating the "License:" field in copyright files
> > too, or is it really simply a hard-coded list of matching patterns?
> 
> It's only a hard-coded list of matching patterns, and it doesn't match any
> of the short licenses because historically I wasn't considering them (with
> the exception of common-licenses references to the BSD license, which I
> kind of would like to make an RC bug and clean up so that we could remove
> the BSD license from common-licenses on the grounds that it's specific to
> only the University of California and confuses people).  If we go with any
> sort of threshold, the script will need serious improvements.
> 
> That was something else I wanted to ask: I've invested all of a couple of
> hours in this script, and would be happy to throw it away in favor of
> something that tries to do a more proper job of classifying the licenses
> referenced in debian/copyright.  Has someone already done this (Jonas,
> perhaps)?

I have so far worked the most on identifying and grouping source data,
putting only little attention (yet - but do dream big...) towards
parsing and processing debian/copyright files e.g. to compare and assess
how well aligned the file is with the content it is supposed to cover.

So if I understand your question correctly and you are not looking for
the output of `licensecheck --list-licenses`, then unfortunately I have
nothing exciting to offer.


 - 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: Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Russ Allbery]

Jonas Smedegaard  writes:

> I have so far worked the most on identifying and grouping source data,
> putting only little attention (yet - but do dream big...) towards
> parsing and processing debian/copyright files e.g. to compare and assess
> how well aligned the file is with the content it is supposed to cover.

> So if I understand your question correctly and you are not looking for
> the output of `licensecheck --list-licenses`, then unfortunately I have
> nothing exciting to offer.

I think that's mostly correct.  I was wondering what would happen if one
ran licensecheck debian/copyright, but unfortunately it doesn't look like
it does anything useful.  I tried it on one of my packages (remctl) that
has a bunch of different licenses, and it just said:

debian/copyright: MIT License

and apparently ignored all of the other licenses present (FSFAP, FSFFULLR,
ISC, X11, GPL-2.0-or-later with Autoconf-exception-generic, and
GPL-3.0-or-later with Autoconf-exception-generic).  It also doesn't notice
that some of the MIT licenses are variations that contain people's names.

(I still put all the Autoconf build machinery licenses in my
debian/copyright file because of the tooling I use to manage my copyright
file, which I also use upstream.  I probably should change that, but I
need to either switch to licensecheck or rewrite my horrible script.)

Also, presumably it doesn't know about copyright-format since it wouldn't
be expecting that in source files, so it wouldn't know to include licenses
referenced in License stanzas without the license text included.

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

Re: /usr/-only image

[Luca Boccassi]

On Sun, 10 Sept 2023 at 21:43, Russ Allbery  wrote:
> (This does not rule out the possibility that certain carefully-crafted
> configurations with a subset of packages may work in this mode, of
> course.)

Yes, this is pretty much what we are talking about in these cases -
targeted experiments, to see what it takes to have a minimal working
bootable image, what are the biggest blockers, and so on. IE,
exploratory development work, not officially supported images or
things like that.

Re: Default font: Transition from DejaVu to Noto

[FC Stegerman]

* Gunnar Hjalmarsson  [2023-09-09 23:08]:
> [...] fonts-noto-core covers "all" scripts [...]

Just want to point out it doesn't cover CJK, which ironically is the
one thing I actually use and prefer Noto for as I definitely prefer
DejaVu (or Bitstream Vera) for latin fonts, which is why I've been
overriding the new default.

- Fay

Re: Default font: Transition from DejaVu to Noto

[Gunnar Hjalmarsson]

Thanks for your replies!

On 2023-09-10 05:23, Paul Wise wrote:

Personally, I found Noto Mono to be very ugly in comparison to the
DejaVu fonts that I was used to,


You did notice that we reversed to DejaVu Sans Mono for monospace, right?

https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/6fae069d


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.


Is the reasoning behind that position published anywhere?

One reason I ask is because upstream made Noto default, so did Fedora, 
so is Ubuntu about to do, and so did some Ubuntu flavors a while ago.


Possibly the way the Noto fonts are packaged in Debian has something to 
do with it. We have currently no way to install the Latin (or more 
precisely the LCG — Latin, Cyrillic, Greek) fonts separately. This 
limitation is discussed in .



Noto makes the font selector useless because each alphabet shows up.


That is more or less true. A concern raised by M. Zhou too.

Also that is a consequence of the current situation with fonts-noto-core 
providing fonts for all scripts, and you can't choose to install e.g. 
LCG only.



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


Hmm.. While that may be true for the fonts-noto meta package, please 
note that it's the fonts-noto-core package for sans-serif and serif 
(installed-size 43,6 MB) I argue for.


On 2023-09-10 06:30, M. Zhou wrote:

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?


Such a change would not be trivial. Maybe suitable for a feature request.

--
Rgds,
Gunnar Hjalmarsson

Re: Default font: Transition from DejaVu to Noto

[Gunnar Hjalmarsson]

On 2023-09-10 17:34, The Wanderer wrote:

I am not sure why DejaVu is the alternative default under
discussion.

Prior to the switch to Noto, the default preferred font family
(listed first in /etc/fonts/conf.d/60-latin.conf) was not DejaVu;
that was, as it still is, listed as the second preference. The font
family listed as the first preference was Bitstream Vera.


The explanation is that upstream dropped Bitstream Vera separately.

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commits/main/conf.d/60-latin.conf

And even if upstream was not very clear about the reason, the Debian bug 
 provides some reasons.


So compared with bullseye you can say that Bitstream Vera was replaced 
with Noto in 60-latin.conf.



If the intended design is that people who prefer one of the
lower-priority entries in the 60-latin.conf lists should remove the
packages that provide the fonts listed with higher preference
priority, then it seems problematic for the former highest-priority
option to be omitted entirely.


Nah.. If you want to use a font — any font — other than the one Debian 
promotes as "default", you can for instance


* prefer it in a code snippet in ~/.config/fontconfig/conf.d (some 
desktops provide GUIs for the purpose)


* cherry pick it in respective application

That is true irrespective of whether it's mentioned in 60-latin.conf or 
not. No need to uninstall anything only for that reason.


--
Rgds,
Gunnar Hjalmarsson

Re: Default font: Transition from DejaVu to Noto

[Gunnar Hjalmarsson]

On 2023-09-10 16:04, Praveen Arimbrathodiyil wrote:

On 10 September 2023 2:38:38 am IST, Gunnar Hjalmarsson
 wrote:

* 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.)


For Malayalam, we prefer traditional script font by default. Noto
Malayalam coverage is not in traditional script.


Noted. So if we ever get that far, let's not touch the 
task-malayalam-desktop package.


And @FC Stegerman: Point taken. :) The reason why I talk so little about 
CJK is that fonts-noto-cjk appears to be the obvious choice for CJK 
scripts nowadays.


--
Rgds,
Gunnar Hjalmarsson

Bug#1051660: ITP: node-vega-lite -- Node.js library that provides a higher-level grammar for visual analysis for node-vega

[Yadd]

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

* Package name: node-vega-lite
  Version : 5.14.1
  Upstream Contact: University of Washington Interactive Data Lab
  
* URL : https://github.com/vega/vega-lite/issues
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : Node.js library that provides a higher-level grammar for 
visual analysis for node-vega

node-vega-lite provides a higher-level grammar for visual analysis that
generates complete Vega specifications.
More details available on https://vega.github.io/vega-lite/docs/. Try
available also on line: https://vega.github.io/editor/#/custom/vega-lite

This library is a dependency of node-vega-embed, needed to build
node-jupyterlab. Will be maintained under JS Team umbrella

Re: Default font: Transition from DejaVu to Noto

[Paul Wise]

On Sun, 2023-09-10 at 11:34 -0400, The Wanderer wrote:

> Rather than discussing only Noto vs. DejaVu, is there any possibility of
> reintroducing Bitstream Vera as a default-font option (even if with a
> low priority), for systems which have that installed?

IIRC DejaVu is a fork of and similar to Bitstream Vera, the latter is
unmaintained so it makes some sense to drop it in favour of DejaVu.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

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

[Jonas Smedegaard]

Quoting Russ Allbery (2023-09-10 23:24:24)
> Jonas Smedegaard  writes:
> 
> > I have so far worked the most on identifying and grouping source data,
> > putting only little attention (yet - but do dream big...) towards
> > parsing and processing debian/copyright files e.g. to compare and assess
> > how well aligned the file is with the content it is supposed to cover.
> 
> > So if I understand your question correctly and you are not looking for
> > the output of `licensecheck --list-licenses`, then unfortunately I have
> > nothing exciting to offer.
> 
> I think that's mostly correct.  I was wondering what would happen if one
> ran licensecheck debian/copyright, but unfortunately it doesn't look like
> it does anything useful.  I tried it on one of my packages (remctl) that
> has a bunch of different licenses, and it just said:
> 
> debian/copyright: MIT License
> 
> and apparently ignored all of the other licenses present (FSFAP, FSFFULLR,
> ISC, X11, GPL-2.0-or-later with Autoconf-exception-generic, and
> GPL-3.0-or-later with Autoconf-exception-generic).  It also doesn't notice
> that some of the MIT licenses are variations that contain people's names.
> 
> (I still put all the Autoconf build machinery licenses in my
> debian/copyright file because of the tooling I use to manage my copyright
> file, which I also use upstream.  I probably should change that, but I
> need to either switch to licensecheck or rewrite my horrible script.)
> 
> Also, presumably it doesn't know about copyright-format since it wouldn't
> be expecting that in source files, so it wouldn't know to include licenses
> referenced in License stanzas without the license text included.

Right.  Licensecheck so far mostly scans for human prose stating "this
has been licensed as..." and "this is the license...", and rarely is
able to recognize "the default license of this project is..." or "that
folder over there is licensed as..." style prose.

That said, there is interest in covering that as well, and also interest
in improving on non-prose forms like "[this is YAML;] Copyright: ..." or
binary forms most commonly embedded in fonts and ICC data in images.

It is helpful if you (i.e. anyone reading this) have a good (as in
particularly rich/tricky/peculiar) case that you file a bugreport
pointing to its failure of being recognized by licensecheck.

Also, I hadn't thought of there being interest in statistics - it should
not be too hard to spit out numbers for variation in licenses or
copyright holders once licensecheck has recognized the information.
Again, if someone has suggestions for formats they'd particularly like
such statistisc to be served from licensecheck then please file a
bugreport.

Sorry this isn't helping anything for the topic being discussed.


 - 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