Re: Default font: Transition from DejaVu to Noto

[Gioele Barabucci]

On 12/09/23 08:24, Fabian Greffrath wrote:

Instead, even
the fonts-noto-core package installs a full pack of 268 (!) font files.
This is discussed in detail in #983291 [1].


The issues is not that there are too many files, but that these files 
become extra entries in font pickers (1 entry for every ~3 files).


Why not collapse all these font files into a few new font files using 
fontforge or a variant of nototools's merge_fonts.py?


For example Noto Serif {Ahom, Bengali, Devanagari, Malayalam, Tamil, 
Thai, …} could be merged into "Noto Serif Asia". Then, Noto * {Africa, 
America, Asia, Europe, Oceania, Symbols} could be shipped in the 
fonts-noto-aggregated package and their entries added to Debian's 
fontconfig as default fallbacks. This would greatly alleviate the 
problem of having too many entries in the font pickers, yet provide the 
same coverage of fonts-noto-core.


Regards,

--
Gioele Barabucci

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

[Hideki Yamane]

Hi,

On Sun, 10 Sep 2023 18:29:36 +0200
Bill Allombert  wrote:
> 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.

 One problem is, that some software declares that they use some licenses
 (e.g. MIT), but sometimes they modify the license term itself a bit.
 So, there's a difference between words in the license list and some words
 in the included license in such software.

 It'd be better to find such software and ask upstream to fix it to use
 proper license terms, by tagging it at BTS. And, it's NOT Debian specific
 issues, so it may be better to ask folks to join such a movement then, IMHO.


-- 
Hideki Yamane 

Bug#1051758: ITP: python-ruyaml -- YAML 1.2 loader/dumper package for Python

[Carsten Schoenert]

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

* Package name: python-ruyaml
  Version : 0.91.0
  Upstream Contact: Anthon van der Neut, Ruamel bvba 

Sorin Sbarnea 
* URL : https://github.com/pycontribs/ruyaml
* License : MIT
  Programming Lang: Python
  Description : YAML 1.2 loader/dumper package for Python

 The ruyaml package is a fork of ruamel.yaml aimed to made in order to secure
 the future of the library, mainly by having a pool of maintainers and can be
 used as a drop-in replacement for python3-ruamel.yaml.

This package is a dependency for yamlfix (a simple opinionated yaml
formatter that keeps your comments) which I intend to package to.

Packaging will happen within the Debian Python Team.

Re: Re: Default font: Transition from DejaVu to Noto

[Fabian Greffrath]

Hi Gioele,

> For example Noto Serif {Ahom, Bengali, Devanagari, Malayalam, Tamil,
> Thai, …} could be merged into "Noto Serif Asia". Then, Noto *
> {Africa, America, Asia, Europe, Oceania, Symbols} could be shipped in
> the fonts-noto-aggregated package and their entries added to Debian's
> fontconfig as default fallbacks. This would greatly alleviate the
> problem of having too many entries in the font pickers, yet provide
> the same coverage of fonts-noto-core.

nice idea! But this is something that has to happen upstream. I don't
think the Debian package is the right place to implement such a
disruptive change.

Cheers,

 - Fabian



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 Hideki Yamane (2023-09-12 09:27:12)
> On Sun, 10 Sep 2023 18:29:36 +0200
> Bill Allombert  wrote:
> > 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.
> 
>  One problem is, that some software declares that they use some licenses
>  (e.g. MIT), but sometimes they modify the license term itself a bit.
>  So, there's a difference between words in the license list and some words
>  in the included license in such software.
> 
>  It'd be better to find such software and ask upstream to fix it to use
>  proper license terms, by tagging it at BTS. And, it's NOT Debian specific
>  issues, so it may be better to ask folks to join such a movement then, IMHO.

I can only assume that the proposal for an automated DEBIAN/copyright
file is limited to source files *possible* to automatically process, and
consequently only relates to debian/copyright files written in the
machine-readable format.

The problem you describe about ambiguous MIT-derived licensing cannot,
in by understanding, occur using the machine-readable format - only with
less strictly structured debian/copyright files.

If you mean to say that ambiguous MIT declarations exist in
debian/copyright files written using the machine-readable format, then
please point to an example, as I cannot imagine how that would look.


 - 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

Re: Default font: Transition from DejaVu to Noto

[Jonas Smedegaard]

Quoting Gioele Barabucci (2023-09-12 09:19:26)
> On 12/09/23 08:24, Fabian Greffrath wrote:
> > Instead, even
> > the fonts-noto-core package installs a full pack of 268 (!) font files.
> > This is discussed in detail in #983291 [1].
> 
> The issues is not that there are too many files, but that these files 
> become extra entries in font pickers (1 entry for every ~3 files).
> 
> Why not collapse all these font files into a few new font files using 
> fontforge or a variant of nototools's merge_fonts.py?
> 
> For example Noto Serif {Ahom, Bengali, Devanagari, Malayalam, Tamil, 
> Thai, …} could be merged into "Noto Serif Asia". Then, Noto * {Africa, 
> America, Asia, Europe, Oceania, Symbols} could be shipped in the 
> fonts-noto-aggregated package and their entries added to Debian's 
> fontconfig as default fallbacks. This would greatly alleviate the 
> problem of having too many entries in the font pickers, yet provide the 
> same coverage of fonts-noto-core.

Please discuss that proposal with the Noto project upstream, not here.

My understanding (and I believe documented somewhere too, e.g. in the
Noto CJK subproject which is the most extreme in amount of glyphs) is
that it is technically impossible to join all glyphs due to limitations
of the font formats.


 - 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

Re: bookworm+½ needed (Arc GPUs, ...)

[Adam Borowski]

On Tue, Sep 12, 2023 at 08:32:17AM +0200, Fabian Greffrath wrote:
> > Before we go and bother the relevant folks (or maybe even do part of the
> > work ourselves...), could someone name other pieces of hardware that
> > would be wanted for Bookworm+½?
> 
> not sure of that's what you mean, but the Realtek RTL8852BE Wi-Fi
> adapter is only properly supported by Linux 6.2.

Then it would require no other action but grabbing a backported kernel, thus
is already included in any reasonable Bookworm+½ plan (we don't do
frankenkernels).  But even in this case, it is still good to know that,
to include such an adapter in documentation.

Obviously there's no point in listing every newly supported piece of
hardware as every kernel version adds hundreds of them, but some are more
prominent than others.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁'Russkiy voyennyi korabl, idi nakhuy'
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Re: Default font: Transition from DejaVu to Noto

[Adam Borowski]

On Tue, Sep 12, 2023 at 09:19:26AM +0200, Gioele Barabucci wrote:
> On 12/09/23 08:24, Fabian Greffrath wrote:
> > the fonts-noto-core package installs a full pack of 268 (!) font files.
> > This is discussed in detail in #983291 [1].
> 
> The issues is not that there are too many files, but that these files become
> extra entries in font pickers (1 entry for every ~3 files).
> 
> Why not collapse all these font files into a few new font files using
> fontforge or a variant of nototools's merge_fonts.py?

You don't need to physically merge font files, fontconfig is fine with many
fonts sharing the same name.  You can't then request a specific font, but
taking missing glyphs from others still works.

(Haven't looked at this in a while, would need to test.)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Latin:   meow 4 characters, 4 columns,  4 bytes
⣾⠁⢠⠒⠀⣿⡁ Greek:   μεου 4 characters, 4 columns,  8 bytes
⢿⡄⠘⠷⠚⠋⠀ Runes:   ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes
⠈⠳⣄ Chinese: 喵   1 character,  2 columns,  3 bytes <-- best!

Re: /usr/-only image

[Marc Haber]

On Tue, 12 Sep 2023 14:37:10 +0900, Simon Richter 
wrote:
>The problem isn't so much the location of the configuration file, but 
>the method used to merge default, distro-provided and system-specific 
>configuration, and how much deviation from the default configuration is 
>expected.
>
>I'd argue that udev and systemd are kind of special here in that they 
>mostly provide a registry for other components to hook into, and that 
>the majority of users stick with the default configuration.

I'd go so far that the systemd/udev way is a strategy to cope with
nearly non-existent conffile handling on non-Debian distributions. We
didn't do ourselves a favor by blindly adopting this scheme, while
we're having a vastly superior package managed that handles conffiles
and conffile changes so nicely.

Please considernot throwing this advantage away for the rest of our
distribution.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Bug#1051779: ITP: docopt-ng -- command-line arguments parser (python3)

[Hugh McMaster]

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

* Package name: docopt-ng
  Version : 0.9.0
  Upstream Contact: Nick Crews 
* URL : https://jazzband.co/projects/docopt-ng
* License : MIT
  Programming Lang: Python
  Description : command-line arguments parser (python3)

docopt-ng is a fork of the original docopt, which helps users
create beautiful command-line interfaces.
.
docopt-ng parses a command-line string and ensures that all options,
arguments and commands match the usage patterns and option descriptions
specified in a Python program's docstring.
.
Users can define valid usage patterns, option descriptions, arguments and
commands using patterns and syntax familiar to users command-line programs.
.
This is the Python 3-compatible version of the package.


The original docopt project has not been updated for many years.
docopt-ng is maintained by the jazzband project and comes with
maintenance, typehints, and complete test coverage.

Re: Default font: Transition from DejaVu to Noto

[The Wanderer]

On 2023-09-12 at 02:28, Fabian Greffrath wrote:

> Hi Wanderer,
> 
>> 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?
> 
> can you even see a difference between Bitstream Vera and DejaVu? The 
> latter should be identical to the former, but with wider glyph 
> coverage.

The fact that I am not sufficiently certain about my answer to that
question is the reason why I had not previously replied since Gunnar
pointed out the connection.

When I was flailing about after the introduction of Noto as first
preference, one of the steps I wound up taking appears to have been the
removal of the fonts-noto package. If that had been enough to restore
the look I was going for (as presumably would have been the case if
DejaVu were enough to provide that look), then presumably I would not
have felt the need to keep digging and experimenting, much less to have
gone so far as a user-profile custom copy of 60-latin.conf in order to
reintroduce Bitstream Vera. Unfortunately, six months or so later, my
memory of the specifics of what I did or how I reacted at each stage of
the experimenting is not clear enough for me to claim that I can in fact
see a difference between the two.

In looking at depictions of DejaVu glyphs and Bitstream Vera glyphs
online, I have seen apparent inconsistencies; some such depictions I
found seem at least superficially identical, but I found at least one
case where I saw visual differences that I suspect I would find
off-putting if used in "production" rendering.

I have been considering how best to test this in something like a live
environment, and have not yet settled on something that seems both
sufficiently doable in my setup and also sufficiently likely to produce
accurate results about my observations.

If I can find such a method, and it does show that I see differences,
then I will probably return and report about that. If I do not see
differences, then I may either return and report that (and apologize for
the noise, and probably drop the custom config file for the future), or
just remain silent to avoid adding further noise. If I cannot find such
a method, then I will probably remain silent - and continue using the
custom config file - until such time as that changes.

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

Bug#1051782: ITP: kiwix-zim -- script to check for updates to your local ZIM library

[Kunal Mehta]

Package: wnpp
Severity: wishlist
Owner: Kunal Mehta 
X-Debbugs-Cc: debian-devel@lists.debian.org, lego...@debian.org

* Package name: kiwix-zim
  Version : 3.0
  Upstream Contact: jojo2357
* URL : https://github.com/jojo2357
* License : GPL-2
  Programming Lang: bash
  Description : script to check for updates to your local ZIM library

kiwix-zim accompanies kiwix/kiwix-tools by automatically downloading new
versions of ZIM files when they are available from the Kiwix server.

I've suggested a slightly more clear name like `kiwix-zim-updater` upstream
at .

Bug#1051784: ITP: python-kr8s -- A batteries-included Python client library for Kubernetes that feels familiar for folks who already know how to use kubectl

[Guilherme de Paula Xavier Segundo]

Package: wnpp
Severity: wishlist
Owner: Guilherme de Paula Xavier Segundo 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org, 
guilherme@gmail.com

* Package name: python-kr8s
  Version : 0.8.17
  Upstream Contact: Jacob Tomlimson 
* URL : https://github.com/kr8s-org/kr8s
* License : BSD
  Programming Lang: Python
  Description : Library for Kubernetes similar to use kubectl

 This library provides a simple and extensible way to interact with Kubernetes
 clusters. The way of use is very similar to the 'kubectl' command and provides
 most of the features that this command has.
 .
 Features:
 .
 - API inspired by 'kubectl' to reduce the developer learning curve.
 - Sensible standards for reducing boilerplate.
 - No hubris-generated code, just human-readable code.
 - It also has an asynchronous API that can be used with 'asyncio' and 'trio'.
 - Client caching to reduce API object passing.
 - Batteries included providing useful utilities and methods inspired by
   'kubectl'.
 .
 Packaging will happen within the Debian Python Team.

Re: Default font: Transition from DejaVu to Noto

[nick black]

The Wanderer left as an exercise for the reader:
> I have been considering how best to test this in something like a live
> environment, and have not yet settled on something that seems both
> sufficiently doable in my setup and also sufficiently likely to produce
> accurate results about my observations.

I've been doing a lot of font comparison on arbitrary text using
font-manager recently, if that's all you need.

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature

Re: bookworm+½ needed (Arc GPUs, ...)

[M. Zhou]

Intel is also slow in upstreaming their SYCL implementation to LLVM
upstream. So that there is still a very far way to go towards
the pytorch variant that can use intel ARC GPU.


On Mon, 2023-09-11 at 12:47 +0200, Adam Borowski wrote:
> So...
> If you've watched our Dear Leader's talk, a prominent problem listed
> was problems with new graphics cards.
> 
> While he didn't elaborate, I assume it was about Intel Arc -- ie, new
> DG2
> discrete GPUs.  And the problem is, proper support didn't hit the
> kernel
> until after 6.1.  You can kinda-sorta run on 6.1 by whitelisting it
> by PCIe
> ID on the kernel cmdline, and it even works (6.0 couldn't cope with
> my
> setup, 6.1 was ok), but such an intentional block doesn't suggest
> it's
> something wise for a normal user to do.
> 
> I'm not sure if firmware shipped with Bookworm is good enough, either
> (having grabbed a copy of the files much earlier, would need to
> test).
> 
> Of course, this wasn't Debian's fault.  The group at Intel
> responsible
> for upstreaming kernel/etc bits was too slow, not providing drivers
> until
> after the hardware has already been shipping to regular non-NDAed
> customers.
> 
> But then, hardware makers do this all the time.  Intel Arc just gives
> a
> more prominent reason to have an installer with backported
> kernel+stuff.
> 
> Before we go and bother the relevant folks (or maybe even do part of
> the
> work ourselves...), could someone name other pieces of hardware that
> would
> be wanted for Bookworm+½?
> 
> 
> Meow?

Re: bookworm+½ needed (Arc GPUs, ...)

[Adam Borowski]

On Tue, Sep 12, 2023 at 10:31:17AM -0400, M. Zhou wrote:
> Intel is also slow in upstreaming their SYCL implementation to LLVM
> upstream. So that there is still a very far way to go towards
> the pytorch variant that can use intel ARC GPU.

Yeah, but that's not a problem for the installer.  Nor for a random user
who wants to do some coding, browsing, and maybe play a game sometimes.

I know that it's frustrating for you, but for now I'd care about more basic
uses.  As far as I know, Intel cares about SYCL mostly for server GPUs like
Ponte Vecchio with ARC being only an afterthought.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Elemental clouds:
⣾⠁⢠⠒⠀⣿⡁ • earth: cumulogranite (aviation)
⢿⡄⠘⠷⠚⠋⠀ • fire:  pyrocumulus (forestry, volcanism)
⠈⠳⣄ No known relations of clouds to air or water.

Bug#1051790: ITP: xdg-desktop-portal-lxqt -- xdg-desktop-portal implemenation for libfm-qt xdg-desktop-portal that is using Qt/KF5/libfm-qt

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬) 
X-Debbugs-Cc: debian-devel@lists.debian.org, team+l...@tracker.debian.org

* Package name: xdg-desktop-portal-lxqt
  Version : 0.4.0
  Upstream Contact: tsujan
* URL : https://github.com/lxqt/xdg-desktop-portal-lxqt
* License : LGPL-2.1+
  Programming Lang: C
  Description : xdg-desktop-portal implemenation for libfm-qt

 The package will be maintained under LXQt team.

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
https://czchen.org/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Re: Efforts to Improve Virtual Console

[Bill Allombert]

Le Fri, Aug 18, 2023 at 12:22:13AM -0700, Aryeh Hillman a écrit :
> I am looking to either find or help create a better virtual console
> experience on linux, especially in Debian. I am talking about tty1, tty2,
> tty3, ... typically mapped via CTRL-ALT-F1.
> 
> *Help with the following would be much appreciated!:*
> 
>- where does the virtual console code live for debian?
>- is virtual console code distro-specific or does it ship with the
>kernel?

The default console is in the kernel, but other versions exist, for
example fbterm.

If you like mouse support, you should try consolation.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

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

[Russ Allbery]

Jonas Smedegaard  writes:

> If you mean to say that ambiguous MIT declarations exist in
> debian/copyright files written using the machine-readable format, then
> please point to an example, as I cannot imagine how that would look.

I can see it: people use License: Expat but then include some license that
is essentially, but not precisely, the same as Expat.  If we then tell
people that they can omit the text of the license and we'll fill it in
automatically, they'll remove the actual text and we'll fill it in with
the wrong thing.

This is just a bug in handling the debian/copyright file, though.  If we
take this approach, we'll need to be very explicit that you can only use
whatever triggers the automatic inclusion of the license text if your
license text is word-for-word identical.  Otherwise, you'll need to cut
and paste it into the file as always.

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

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

[Jonas Smedegaard]

Quoting Russ Allbery (2023-09-12 18:15:27)
> Jonas Smedegaard  writes:
> 
> > If you mean to say that ambiguous MIT declarations exist in
> > debian/copyright files written using the machine-readable format, then
> > please point to an example, as I cannot imagine how that would look.
> 
> I can see it: people use License: Expat but then include some license that
> is essentially, but not precisely, the same as Expat.  If we then tell
> people that they can omit the text of the license and we'll fill it in
> automatically, they'll remove the actual text and we'll fill it in with
> the wrong thing.
> 
> This is just a bug in handling the debian/copyright file, though.  If we
> take this approach, we'll need to be very explicit that you can only use
> whatever triggers the automatic inclusion of the license text if your
> license text is word-for-word identical.  Otherwise, you'll need to cut
> and paste it into the file as always.

Ah, right.  I see it now.

Strictly speaking it is not (as I was more narrowly focusing on) that
the current debian/copyright spec leaves room for *ambiguity*, but
instead that there is a real risk of making mistakes when replacing with
centrally defined ones (e.g. redefining a local "Expat" from locally
meaning "MIT-ish legalese as stated in this project" to falsely mean
"the MIT-ish legalese that SPDX labels MIT").

If you disagree, then please shout, as then I am still missing your
point here...


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

> Strictly speaking it is not (as I was more narrowly focusing on) that
> the current debian/copyright spec leaves room for *ambiguity*, but
> instead that there is a real risk of making mistakes when replacing with
> centrally defined ones (e.g. redefining a local "Expat" from locally
> meaning "MIT-ish legalese as stated in this project" to falsely mean
> "the MIT-ish legalese that SPDX labels MIT").

Right, the existing copyright format defines a few standard labels and
says that you should only use those labels when the license text matches,
but it doesn't stress that "matches" means absolutely word-for-word
identical.  I suspect, although I haven't checked, that we've made at
least a few mistakes where some license text that's basically equivalent
to Expat is labelled as Expat even though the text is not word-for-word
identical.  Given that currently all labels in debian/copyright are
essentially local and the full text is there (except for common-licenses,
where apart from BSD the licenses normally are used verbatim), this is not
currently really a bug.  But we could turn it into a bug quite quickly if
we relied on the license short name to look up the text.

To take an example that I've been trying to get rid of for over a decade,
many of the /usr/share/common-licenses/BSD references currently in the
archive are incorrect.  There are a few cases where the code is literally
copyrighted only by the Regents of the University of California and uses
exactly that license text, but this is not the case for a lot of them.  It
looks like a few people have even tried to say "use common-licenses but
change the name in the license" rather than reproducing the license text,
which I don't believe meets the terms of the license (although it's of
course very unlikely that anyone would sue over it).

A quick code search turns up the following examples, all of which I
believe are wrong:

https://sources.debian.org/src/mrpt/1:2.10.0+ds-3/doc/man-pages/pod/simul-beacons.pod/?hl=35#L35
https://sources.debian.org/src/gridengine/8.1.9+dfsg-11/debian/scripts/init_cluster/?hl=7#L7
https://sources.debian.org/src/rust-hyphenation/0.7.1-1/debian/copyright/?hl=278#L278
https://sources.debian.org/src/nim/1.6.14-1/debian/copyright/?hl=64#L64
https://sources.debian.org/src/yade/2023.02a-2/debian/copyright/?hl=78#L78

An example of one that probably is okay, although ideally we still
wouldn't do this because there are other copyrights in the source:

https://sources.debian.org/src/lpr/1:2008.05.17.3+nmu1/debian/copyright/?hl=15#L15

This problem potentially would happen a lot with the BSD licenses, since
the copyright-format document points to SPDX and SPDX, since it only cares
about labeling legally-equivalent documents, allows the license text to
vary around things like the name of the person you're not supposed to say
endorsed your software while still receiving the same label.

We therefore cannot use solely SPDX as a way of determining whether we can
substitute the text of the license automatically for people, because there
are SPDX labels for a lot of licenses for which we'd need to copy and
paste the exact license text because it varies.  At least if I understand
what our goals would be.

(License texts that have portions that vary between packages they apply to
are a menace and make everything much harder, and I really wish people
would stop using them, but of course the world of software development is
not going to listen to me.)

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

/usr-merge and filesystem bootstrap

[Helmut Grohne]

Dear maintainers of relevant essential packages,

this /usr-merge transition covering multiple release has reached a point
where consensus has been reached about completing it by moving files
from / to /usr. The chosen approach also affects filesystem bootstrap
and an earlier discussion of this matter has resulted in consensus for
not changing the bootstrap protocol from the pre-/usr-merge state and
rather returning to that state. To this end, debootstrap has been
updated in trixie and unstable such that it performs the initial unpack
before performing the merge (mirroring how usrmerge does it on existing
systems). This change is being backported to bookworm and bullseye by
Simon McVittie. In order to remove the usrmerge package eventually, we
want base-files to install the aliasing symlinks via its data.tar.
Unfortunately, we cannot just do that, because doing so would break
debootstrap or cdebootstrap/mmdebstrap or both.

The way we get there is to first convert all packages from the
Priority:required set but some exceptions to install no files into
aliased locations such as /bin, /sbin or /lib*.  Getting there will
consume months. I hope we can reach this state in early 2024.

Once the Priority:required set only has that exception set left
unconverted, I will prepare patches for the entire exception set and
upload it coherently in one dinstall window.

That exception set is:
 * base-files
 * bash
 * coreutils maybe
 * dash
 * libc6
 * util-linux

base-files will install /bin, /sbin and /lib as symbolic links in its
data.tar. libc6 will install multilib /lib* where needed as symbolic
links in its data.tar:
 * /lib64: amd64, loong64, mips64el, ppc64, ppc64el
 * /libx32: x32
Since the relevant architectures share their libc soname, these packages
will remain multiarch co-installable. Multilib symlinks that are not
essential to a Debian architecture are not installed in a data.tar and
managed using maintainer scripts instead. For instance, /lib64 will not
be a symlink in libc6-amd64:i386, because /lib64 is not essential to
i386 nor is libc6-amd64:i386 essential to i386.

If we were to upload base-files before other packages, then a
bootstrapping tool could first unpack that other package thereby
creating e.g. /bin as a directory and then extracting the symbolic link
from base-files' data.tar would fail.

If we were to upload any other package from that set before base-files,
the aliasing links would be absent and merging via usrmerge.postinst
would not work due to missing the dynamic linker, /bin/sh, /bin/bash,
or /bin/cp. Running util-linux.postinst before usrmerge.postinst could
fail for the absence of /bin/more.

Therefore changes need to be uploaded concurrently. I intend to perform
these uploads in coordination with you. I request permission to NMU your
package for the purpose of completing the transition in this way.
Before actually performing such a NMU, I will prepare and send the
to-be-NMUed patches to all affected maintainers for review. The purpose
of having these NMUed is meeting the concurrency requirement. If you
insist on performing the upload yourself, you could arrange handing me a
signed .dsc.

These packages also need to migrate to testing together or we will
temporarily break bootstrappability of testing. We can either ensure
that by temporarily adding suitable Breaks or using special release team
powers.

I will coordinate a suitable time avoiding e.g. a glibc transition or a
time64 transition.

I will try to remove coreutils from the exception set by changing
usrmerge to no longer require a particular location of cp.

I request that affected maintainers reply to this mail:
 * Are you ok with the proposed changes in principle?
   + Moving all files from / to /usr leaving no files in aliased
 locations
   + Installing aliasing symbolic links in base-files and libc6
 * Are you fine in principle with me NMUing your package after having
   reviewed the promised patch?
 * Do you readily see any flaw in the proposed transition already?

Thanks for your cooperation

Helmut

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

[Bill Allombert]

On Tue, Sep 12, 2023 at 10:49:02AM -0700, Russ Allbery wrote:
> To take an example that I've been trying to get rid of for over a decade,
> many of the /usr/share/common-licenses/BSD references currently in the
> archive are incorrect.  There are a few cases where the code is literally
> copyrighted only by the Regents of the University of California and uses
> exactly that license text, but this is not the case for a lot of them.  It
> looks like a few people have even tried to say "use common-licenses but
> change the name in the license" rather than reproducing the license text,
> which I don't believe meets the terms of the license (although it's of
> course very unlikely that anyone would sue over it).

Note that my proposal makes detecting the discrepancy more visible rather
than less, since you can compare the generated copyright file with
the actual license statement without chasing files.

Also, overengineering aside, the copyright generator could support 
parameter substitution to accomodate small discrepancies in license.
For example an option to replace in /usr/share/common-licenses/BSD the
line 
"Copyright (c) The Regents of the University of California."
by whatever is required when generating DEBIAN/copyright.

Cheers,
Bill

Re: /usr-merge and filesystem bootstrap

[Chris Hofstaedtler]

Hi Helmut,

speaking with my util-linux in Debian hat...

* Helmut Grohne  [230912 20:16]:
[..]
> I request that affected maintainers reply to this mail:
>  * Are you ok with the proposed changes in principle?
>+ Moving all files from / to /usr leaving no files in aliased
>  locations
>+ Installing aliasing symbolic links in base-files and libc6

Yes.

>  * Are you fine in principle with me NMUing your package after having
>reviewed the promised patch?

Yes.

Would be nice if the patch ends up in git, at
  https://salsa.debian.org/debian/util-linux
but it's not necessary. Feel free to use the next non-NMU version
number.

>  * Do you readily see any flaw in the proposed transition already?

Nothing from util-linux PoV. Given src:util-linux produces udebs,
that should be taken into consideration, but I think any changes to
the udebs do not need to happen at the same time.

Chris



signature.asc
Description: PGP signature

Bug#1051823: ITP: libjs-simulate-event -- JavaScript library to trigger DOM events on any element

[Yadd]

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

* Package name: libjs-simulate-event
  Version : 1.4.0
  Upstream Contact: Blake Embrey 
* URL : https://github.com/blakeembrey/simulate-event
* License : Expat
  Programming Lang: JavaScript
  Description : JavaScript library to trigger DOM events on any element

libjs-simulate-event provide a simple way to trigger DOM events on any
element:
  * simulateEvent.simulate(document.body, 'click')

It's a build dependency of node-jupyterlab and will be maintaied under
JS Team umbrella