Re: Default font: Transition from DejaVu to Noto

[Fabian Greffrath]

Hi Gunnar,

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

as has already been stated elsewhere, fontconfig upstream's move to
Noto as the default font has most probably not been done for
aesthetical reasons. That is, it is not the "most beautiful font" that
people "like better" then DejaVu, but the single usable fallback font
with the widest glyph coverage.

However, I think that the acceptance - or rather lack thereof - of the
Noto fonts in Debian has indeed to do with the way they are currently
packaged. There is no pendant to the fonts-dejavu-core package which
only installs the generic serif and sans-serif flavors. Instead, even
the fonts-noto-core package installs a full pack of 268 (!) font files.
This is discussed in detail in #983291 [1].

So, if asked for my personal opinion, I could live with DejaVu Mono as
the default monospace font (for aesthetical reasons) and Noto Sans and
Serif as the default sans-serif and serif fonts (for pragmatic
reasons), respectively, but only if the latter are packaged separately.

Cheers,

 - Fabian

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983291


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

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

[Fabian Greffrath]

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.

Cheers,

 - Fabian



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

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

[Fabian Greffrath]

Hi Adam,

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

Cheers,

 - Fabian



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

Bug#1051748: RFP: pdf2htmlex -- convert PDF to HTML without losing text or format

[Lev Lamberov]

Package: wnpp
Severity: wishlist

* Package name: pdf2htmlex
  Version : 0.18.8rc1
  Upstream Author : Lu Wang  and other contributors
* URL or Web page : https://github.com/pdf2htmlEX/pdf2htmlEX
* License : GPL-3+
  Description : convert PDF to HTML without losing text or format

pdf2htmlEX renders PDF files in HTML, utilizing modern Web technologies.
It aims to provide an accurate rendering, while being optimized for Web
display. Text, fonts and formats are natively preserved in HTML.
Mathematical formulas, figures and images are also supported.

pdf2htmlEX is also a publishing tool: almost 50 options make it flexible
for many different use cases: PDF preview, book/magazine publishing,
personal resume, etc.

pdf2htmlEX is optimized for modern web browsers such as Mozilla Firefox
& Google Chrome.

Re: /usr/-only image

[Russ Allbery]

Simon Richter  writes:

> This would not work for a package like postfix, which absolutely
> requires system-specific configuration, and we'd have to be careful with
> packages like postgresql where there is a default configuration that
> works fine for hobbyists that we do not make life too difficult for
> professional users.

I don't think there's any desire to avoid system-specific configuration.
The model instead is that the package comes with a set of defaults, and if
you don't set something in the local configuration in /etc, the default is
used.  I think this is exactly the model used by Postfix for main.cf.
There are a few mandatory settings, but for the most part you can omit any
setting and the default is used.  The defaults are just hard-coded (at
least so far as I know) rather than stored in separate configuration files
in /usr, which doesn't make a fundamental difference.

The problem configuration files are ones like Postfix's master.cf, where a
whole ton of stuff almost no one ever changes is mixed into the same file
that you're supposed to change for local configuration and there's no
merger process.  And honestly I have always hated the Postfix master.cf
file, dating back to before systemd even existed.  I think it's a bad
configuration design.

That of course is just my opinion and doesn't get us anywhere closer to
using a defaults plus overrides syntax for master.cf, even assuming that
upstream would consider it.

There are a ton of packages with configuration syntaxes that were created
a very long time ago or have accumulated over time.  I maintain one of
them upstream, INN, and I'll be the first to say that the INN
configuration syntax is *awful*, and I have actively contributed to making
it what it is.  There are dozens of files, they use about fourteen
completely separate and incompatible syntaxes, there's boilerplate in some
places and defaults in other places, and learning all the ins and outs of
the configuration is a full-time job.  It's nonsense, and it's badly
designed, and if I were writing it from scratch I'd replace the whole
thing with simplified YAML or some similar well-known syntax with a schema
and good editor support and a data model that supports configuration
merging.

And the chances of any of that happening when I have more free software
projects lying on the floor in pieces than I have ones I'm managing to
keep in the air is... low, even though I do have a much more active
comaintainer.

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

Re: /usr/-only image

[Simon Richter]

Hi,

On 9/11/23 23:08, Simon McVittie wrote:


Some packages rely on their own configuration existing in /etc. For these
packages, ideally they'd try loading from /etc as highest priority, but
fall back to /usr as a lower-priority location. This is a
package-by-package change, and probably best achieved upstream.


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.


This would not work for a package like postfix, which absolutely 
requires system-specific configuration, and we'd have to be careful with 
packages like postgresql where there is a default configuration that 
works fine for hobbyists that we do not make life too difficult for 
professional users.


   Simon

Bug#1051733: ITP: ayatana-indicator-a11y -- Ayatana Indicator for Accessibility Settings

[Mike Gabriel]

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

* Package name: ayatana-indicator-a11y
  Version : 0.0.1
  Upstream Contact: Robert Tari 
* URL : https://github.com/AyatanaIndicators/ayatana-indicator-a11y
* License : GPL-3
  Programming Lang: C
  Description : Ayatana Indicator for Accessibility Settings

 This Ayatana Indicator provides quick access to accessibility related
 assistance applications such as the screen reader or an on-screen
 keyboard.
 .
 The provided accessibility indicator should show as an icon in the top
 panel of indicator aware destkop environments. It can be used to toggle
 and access various accessibility features.
 .
 Ayatana Indicators are only available on desktop environments that
 provide a renderer for system indicators (such as MATE, Xfce, Lomiri,
 etc.).
 .
 This package will be maintained by the Ayatana Packagers Team in Debian.

Re: /usr/-only image

[Simon McVittie]

On Mon, 11 Sep 2023 at 08:58:09 +0200, Gioele Barabucci wrote:
> An even bigger prerequisite is that many upstream projects does not yet
> support working without /etc or (orthogonally) reading their default
> configuration from /usr.

I agree that an "upstream first" approach is good here - even if we might
want Debian maintainers to backport upstream changes that haven't made it
into a release yet. Loading defaults from /usr is a behaviour change, and
many downstream maintainers are (IMO correctly) reluctant to make
Debian-specific behaviour changes for things that would ideally go
upstream but have not yet been accepted upstream, because that carries a
risk of the change never happening upstream and the Debian delta therefore
becoming permanent.

There are a couple of inter-related things here, which might make sense
to treat as separate topics.

Integration hooks
=

Quite a lot of packages have some sort of integration hook, where package A
installs a file in a location "owned" by package B, to make the two
packages integrate nicely together. It's best if we can change package B
to load these integration hooks from /usr, and then systematically change
all examples of package A to install there.

Because this involves a large number of often trivially small files,
working on this will probably have the largest impact on the number of
files in /etc that would need special management for anyone who wants to
use a /usr-only filesystem image.

For instance, dbus-daemon (and other D-Bus implementations like
dbus-broker) used to require system services to install a snippet into
/etc/dbus-1/system.d. It's now deprecated for packages to install files
into that directory, and instead, they should install into
/usr/share/dbus-1/system.d, reserving /etc/dbus-1/system.d for sysadmin
overrides.

The steps to take here are:

1. Change package B to load from /usr in addition to /etc. This should
   usually be done upstream, because it's a behaviour change.
   (For instance where B = dbus-daemon, we did this in 2015.)
   If multiple packages all load from the same location (like dbus-daemon
   and dbus-broker) then all of them need this change.

2. For each package A, move the integration/configuration snippet from
   /etc to /usr. This should ideally be done upstream too, but it's usually
   straightforward (low maintenance cost) to do this in our packaging,
   and it doesn't necessarily *need* to happen upstream.

Configuration defaults
==

Some packages rely on their own configuration existing in /etc. For these
packages, ideally they'd try loading from /etc as highest priority, but
fall back to /usr as a lower-priority location. This is a
package-by-package change, and probably best achieved upstream.

smcv

Re: /usr/-only image

[Philipp Kern]

On 2023-09-10 22:42, Russ Allbery wrote:
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.


I don't feel like not having /etc is going to be feasible for a while. 
However another interesting question is what a minimal /etc looks like 
and what could be generated on-demand or regenerated from some staging 
ground in /usr and /var (e.g. the debconf database).


If you squint, that's what NixOS is doing. But we have a pretty messy 
way with multiple conflicting systems to put configuration in and how we 
merge the files when updates are installed. There would need to be some 
deeper primitives to make this happen.


Kind regards
Philipp Kern

Bug#1051705: ITP: node-vega-embed -- Node.js library to easily embed vega views

[Yadd]

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

* Package name: node-vega-embed
  Version : 6.22.2
  Upstream Contact: University of Washington Interactive Data Lab
  
* URL : https://github.com/vega/vega-embed/issues
* License : BSD-3-Clause
  Programming Lang: $jAVAsCRIPT
  Description : Node.js library to easily embed vega views

node-vega-embed makes it easy to embed interactive node-vega and
node-vega-lite views into web pages.

It's another dependency needed to build node-jupyterlab. Will be
maintained under JS Team umbrella

Bug#1051694: ITP: node-vega-themes -- Themes for stylized Vega and Vega-Lite visualizations

[Yadd]

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

* Package name: node-vega-themes
  Version : 2.14.0
  Upstream Contact: University of Washington Interactive Data Lab
  
* URL : https://github.com/vega/vega-themes/issues
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : Themes for stylized Vega and Vega-Lite visualizations

A Vega *theme* is a configuration object with default settings for a variety
of visual properties such as colors, typefaces, line widths and spacing. This
module exports a set of named themes, which can be passed as input to the
node-vega or node-vega-lite with node-vega-embed or directly as a
configuration object to the Vega parser.

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

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

[Adam Borowski]

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?
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Re: /usr/-only image

[Marco d'Itri]

On Sep 10, Russ Allbery  wrote:

> 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.
Indeed, at this point we are just experimenting and trying to figure out 
what we can and cannot do.
I am not even sure that general distribution-wide support for this is 
a reasonable goal, but I expect that it will not be hard to have support
for the base system and cooperating packages.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1051676: ITP: kylin-virtual-keyboard -- Kylin Virtual Keyboard

[pengfeiguo]

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

* Package name: kylin-virtual-keyboard
  Version : 2.0.1.0-1
  Upstream Contact: pengfeiguo 
* URL :
https://gitee.com/openkylin/community/tree/master/sig/InputMethod
* License : GPL
  Programming Lang: C, C++
  Description : Kylin Virtual Keyboard

 Virtual keyboard based on fcitx5 InputMethod Framework.
 If you want to use this project, please ensure
 that your system has fcitx5 installed.

Bug#1051675: ITP: rust-bindgen-cli -- automatically generate rust bindings for C/C++ source code

[Matthias Geiger]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-bindgen-cli
  Version : 0.66.1
  Upstream Contact: The rust-bindgen project contributors
* URL : 
https://github.com/rust-lang/rust-bindgen/tree/main/bindgen-cli 
* License : BSD-3-Clause
  Programming Lang: Rust
  Description : automatically generate rust bindings for C/C++ libraries

Starting with 0.61 the bindgen binary was split from the rust-bindgen
source into a seperate crate. The executable named bindgen. Packaging is
done and will be uploaded to NEW soon. It'll be maintained with the Rust
team.

thanks,

werdahias


-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmT+1BQVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1jDEQAJyhw8Qn9v1SsEUITmPaXb2D95UG
AnTm/AlLm7+7+ceFjDjudUyc37bAOycPyEtDhLL9sMj2d7/fbcpQh2fxGWudygSO
0kwjfZu2MXHZHzhAT3ygYwXVUtffyb+AoV7QQCfJC5QsJhXQBA3uhDBW778cLNUC
D472NVelN+vqidQpXBlEvzJsMCvj2P9YH2Z2Xo2XvkPTPTfpYNFaU0GHzPZU9+/I
iIA67h/Y5bOYm4FS6Ul59HEPjWCmr6COxhqi8utOtuPTKY+MQEiFYruVkcXXUgIa
bwYFd4mw26O0r+9UZSJkSOyh/wzE0BXMm9cgi+U3iUWu/VlXcHBeoqvmoslp6ip5
16TCRVZrmPEhrzIl6GpkQBmClUUim36/xfhZWMwauxw0vNaFi8bNFKt4uiHawpIp
EdsQ06Q160+sU6FvgNiV8WJGIcAQBgflL2LjmeWaVULR2ilX3UQ3ym10theqx3Os
VNOBHKnH8AcldUHLpFbNEsoPWavsg2bkHsUapqNDnKfFzhzcj/pZBhpqjZhSZKug
fen/8w9Zvi5MYOeXwP9p98BQZqt5SkeImBn8nAoCzCgS7YieZhvsZOObdljqq7Fo
4Z9VQuzG4h2AjW//AsXe+LmIBJ25CgeEXq1HYtoWUGrymuIhKwTCgw4+3F8TnjRs
2r2HgA6UUFXA+giB
=iM7u
-END PGP SIGNATURE-

Re: /usr/-only image

[Gioele Barabucci]

On 10/09/23 22:42, Russ Allbery wrote:

Luca Boccassi  writes:

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.


An even bigger prerequisite is that many upstream projects does not yet 
support working without /etc or (orthogonally) reading their default 
configuration from /usr.


In my personal experience I found that working directly with upstream 
projects on supporting stateless installs (no /etc, no /var) and 
factory-resets (the system keeps working after `rm -Rf /etc /var`) has a 
better return in investment compared to trying to integrate Debian- or 
distro-specific patches.


Perhaps a more approachable goal for Debian towards statelessness is to 
reach the point where no packages ship files in /var. That is often a 
matter of passing the right parameters to `dh_auto_configure`.


Regards,

--
Gioele Barabucci