Bug#1051974: ITP: inwasm -- Inline WebAssembly for Typescript

[Yadd]

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

* Package name: inwasm
  Version : 0.0.13
  Upstream Contact: Joerg Breitbart 
* URL : https://github.com/jerch/inwasm
* License : Expat
  Programming Lang: JavaScript
  Description : Inline WebAssembly for Typescript

InWasm is a small bundler for inline standalone wasm libraries (Web Assembly).
It compiles and bundles the wasm source code inplace, using either
clang, wabt and/or emscripten.

inwasm is a build dependency needed to build node-xterm-wasm-parts,
which is required by node-xterm 5 which update is needed to build
node-jupyterlab. Will be maintained under JS Team umbrella.

Re: Default font: Transition from DejaVu to Noto

[Scott Kitterman]

On Thursday, September 14, 2023 11:03:07 PM EDT Paul Wise wrote:
Several packages ...
> Recommends: xml2rfc
...

For IETF RFC development, there are specific fonts that are required for the 
PDF format (these are Recommends not Depends because very few RFCs need to be 
in the PDF format, so most people might do without both the fonts and the 
other PDF tools needed.  It's not a free for all if you're building documents 
for the IETF.

The whole situation does seem somewhat messy.  In addition to the defaults 
changes, I guess things are getting moved between packages as well.  We 
recently had #1050053 [1] filed suggesting we change  the Recommends on fonts-
noto-unhinted to "the appropriate package" since it's now empty.  No idea what 
that would be though.  Suggestions welcome.

Scott K

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

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

Re: Default font: Transition from DejaVu to Noto

[Paul Wise]

On Wed, 2023-09-13 at 21:09 +0200, Gunnar Hjalmarsson wrote:

> So we have a conflict of goals here. The good news is that a user who
> speaks some latin language, and who thinks it's important to be able to 
> easily select font directly in various applications, can do:
> 
> apt purge fonts-noto-core

That won't work on some systems because various packages hard-depend
on the various fonts-noto packages and metapackages.

Personally I think Debian should use Recommends instead of Depends
for most deps on font packages (including for the Noto fonts), except
for things that don't fall back on other fonts, or require specific
fonts for aesthetic or other reasons, like games that need fancy fonts,
or code needing OCR-friendly fonts etc.

$ aptitude search fonts-noto -F %p | xargs pipetty apt rdepends | grep -v ': 
fonts-noto'
fonts-noto
Reverse Depends:
  Recommends: plasma-desktop
  Depends: libpixelif-common
  Depends: josm-installer
  Recommends: task-korean-desktop
  Recommends: task-chinese-t-desktop
  Recommends: task-chinese-s-desktop
  Recommends: plasma-desktop
  Depends: libpixelif-common
  Depends: josm
  Depends: cinnamon-desktop-environment
  Suggests: fonts-droid-fallback
fonts-noto-cjk
Reverse Depends:
  Depends: prusa-slicer
  Recommends: xml2rfc
  Recommends: task-korean-desktop
  Recommends: task-chinese-t-desktop
  Recommends: task-chinese-s-desktop
  Suggests: signing-party
  Depends: openstreetmap-carto-common
 |Suggests: mlterm
  Suggests: goby
  Depends: freeciv-client-sdl
  Recommends: ddnet-data
fonts-noto-cjk-extra
Reverse Depends:
  Suggests: texlive-lang-japanese
fonts-noto-color-emoji
Reverse Depends:
  Recommends: dino-im
  Depends: sxmo-utils
  Recommends: nheko
  Depends: texlive-fonts-extra-links
  Recommends: texlive-fonts-extra
  Depends: sxmo-utils
  Depends: supertuxkart-data
  Recommends: python3-sqt
  Depends: pango1.0-tests
  Recommends: gnome-characters
  Recommends: gajim
  Depends: fonts-recommended
  Recommends: emacs-pgtk
  Recommends: emacs-lucid
  Recommends: emacs-gtk
fonts-noto-core
Reverse Depends:
  Recommends: libreoffice
  Depends: prusa-slicer
  Recommends: phosh-osk-stub
  Recommends: freetype2-doc
  Recommends: xml2rfc
  Depends: texlive-fonts-extra-links
  Recommends: texlive-fonts-extra
  Recommends: task-sinhala-desktop
  Depends: supertuxkart-data
  Depends: request-tracker5
  Depends: pango1.0-tests
  Depends: odoo-16
  Depends: qml-module-lomiri-components-labs
  Depends: qml-module-lomiri-components
  Depends: lomiri-system-settings
  Recommends: libreoffice
  Recommends: freetype2-doc
  Depends: arctica-greeter
 |Depends: fontconfig-config
  Recommends: python3-fabulous
fonts-noto-extra
Reverse Depends:
  Recommends: libreoffice
  Depends: retroarch-assets
  Recommends: libreoffice
fonts-noto-hinted
Reverse Depends:
  Recommends: plasma-integration
  Depends: prusa-slicer
  Depends: request-tracker4
  Recommends: plasma-integration
  Depends: openstreetmap-carto-common
  Recommends: kodi-data
fonts-noto-mono
Reverse Depends:
  Depends: buskill
  Recommends: libreoffice
  Depends: libpixelif-common
  Depends: texlive-fonts-extra-links
  Recommends: texlive-fonts-extra
  Suggests: signing-party
  Depends: qml-module-lomiri-components-labs
  Depends: qml-module-lomiri-components
  Depends: lomiri-terminal-app
  Recommends: libreoffice
  Depends: libpixelif-common
  Recommends: kodi-data
  Recommends: fonts-droid-fallback
fonts-noto-ui-core
Reverse Depends:
  Recommends: libreoffice
  Recommends: task-sinhala-desktop
  Depends: supertuxkart-data
  Recommends: libreoffice
fonts-noto-ui-extra
Reverse Depends:
fonts-noto-unhinted
Reverse Depends:
  Recommends: xml2rfc
  Depends: openstreetmap-carto-common

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1051969: ITP: matekbd-keyboard-display -- Display keyboard layouts in MATE

[Mike Gabriel]

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

* Package name: matekbd-keyboard-display
  Version : 23.9.1
  Upstream Contact: Robert Tari 
* URL : https://tari.in/www/software/matekbd-keyboard-display/
* License : LGPL-2+
  Programming Lang: C
  Description : Display keyboard layouts in MATE

 An application that allows you to preview keyboard layouts on MATE
 desktop. It uses the libmatekbd library, similarly to
 gkbd-keyboard-display and libgnomekbd.
 .
 This package is required for the next upstream release of
 ayatana-indicator-display.
 .
 This package will be maintained under the umbrella of the MATE
 packaging team.

Re: Default font: Transition from DejaVu to Noto

[Gunnar Hjalmarsson]

On 2023-09-13 21:09, Gunnar Hjalmarsson wrote:

There are at least two questions:

1. Should fonts-noto-core be installed by default?


I just uploaded fontconfig 2.14.2-6 including this commit:

https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/3b8ef475


2. Which font should fontconfig prefer?


Given that fonts-noto-core is not installed by default, the effective 
"default font" is now DejaVu again, even if 60-latin.conf prefers Noto 
over DejaVu for sans-serif and serif. I see no urgent need to change that.


--
Gunnar

Re: /usr-merge and filesystem bootstrap

[Aurelien Jarno]

Hi,

Answering for the glibc package.

On 2023-09-12 20:15, Helmut Grohne wrote:
> 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

Do you mean you plan to upload source+binaries for all the above
packages and for all architectures? How do you plan to handle ports
architectures? 

> 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

Yes.

>+ 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, with the condition that help is provided to fix the bugs resulting
from moving files from / to /usr in the glibc packages.

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

I haven't looked at the details besides the changes you described above.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net


signature.asc
Description: PGP signature

Bug#1051960: ITP: qadwaitadecorations -- Qt decoration plugin implementing Adwaita-like client-side decorations

[Matthias Geiger]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: qadwaitadecorations
  Version : 0.1.1
  Upstream Contact: Jan Grulich 
* URL : https://github.com/FedoraQt/QAdwaitaDecorations
* License : LGPL-2.1+
  Programming Lang: C++
  Description : Qt decoration plugin implementing Adwaita-like client-side 
decorations

This plugin is the successor to qgnomeplatform implementing an adwaita
style for qt5 apps. It'll be maintained with the Debian QT/KDE Extras
team.

thanks,

Matthias Geiger

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmUDYXgVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1DhQQAJ0+HUpdpm4mBOPTBiklmx70knkg
josCqIzvioyNY5nGPl817pVxq+/xGpgbczA6WTw4W7RTKbSzvOm+ITdnd+Grd99X
TnN3PbfvCrRQu7ANExuzcVlC//7p3LNusRCcYc6DNJCj1fH1nsh+TjjTxJCsLTy5
yfSrfOma5TmASYd1xl/Z/XbDWTaKWqW4GPu9RolcT2tsW4JdRKbbeHXkITI/5pKL
0vAxxC307cpEg2R4Yed3ZNVl1rEcoxhuXWyMy/ffsJkFdtLjqSaPC6s2IHhfn+4M
DanVCo2ITHSfvJQ46s3mSZfALtjdf1tH+DzZZHrQqoUCosGJELiOibjh1FGuEMm5
0GiXY0LMO0C6x+fchPJRZRXCy+0A/kL/HuZj+SueA68cQMN0ECydkstz8zGSkjiq
pwM9UMIK5w9IOD3Y/iCth799ogs+R2lpxNIhkF/SH6sJ+Im6SRfVuy4vVMbVmuZ/
9ZcQE4N5O906an1eIZ28RkW2Fb6z06BHwjpT+iHy1UsXo+T6w4r1Oti/50sldEdb
z85NBw7ry+wW1Ja7rMT0En6wXaMgbCENIZMD2wfWwQpvSOTZw/ZV4k4utpAbNbFI
NBtclOj4b4FjpLVeV7g2OzvqMmF65e+Q3v5wyK+Z2Ub/MO58hlxolcXhr0+PPYbx
VGfNZG2ddbLyWYOs
=lL46
-END PGP SIGNATURE-

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

[Fabian Greffrath]

> It's a bit ironic. I proposed in a MR to prepend fonts-noto-core to
> that list, and you merged it. At the time I wasn't aware of the
> significance of being listed first, and I suppose you weren't either.

Yes, this sounds ironic and you are right, I wasn't aware of the
implications of this change. :/

In my defense, I didn't have the fonts-noto-core package installed at
that time (for obvious reasons). And albeit taking part in the
discussion in #983291, I wasn't aware anymore of the fact that this was
indeed the "core" package that bundled 168 font files. To me it looked
like we were following upstream and replace one "core" font package
with the other, but I admit I wasn't prepared that the latter one
contained ~150 more font files than the former.

Again, I have no problem with replacing DejaVU Sans/Serif/Mono with
Noto Sans/Serif/Mono, my only problem is replacing the former with the
latter plus 150 more fonts that I didn't ask for. ;)

Cheers,

 - Fabian



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

Bug#1051944: ITP: sd-mux-ctrl -- SD card multiplexer controller

[Lisandro Damián Nicanor Pérez Meyer]

Package: wnpp
Severity: wishlist
Owner: Lisandro Damián Nicanor Pérez Meyer 
X-Debbugs-Cc: debian-devel@lists.debian.org, lisan...@debian.org

* Package name: sd-mux-ctrl
  Version : 0.0.3
  Upstream Contact: Lisandro Damián Nicanor Pérez Meyer 
* URL : https://gitlab.com/perezmeyer/sd-mux-ctrl
* License : Apache-2.0
  Programming Lang: C++
  Description : SD card multiplexer controller

sd-mux stands for Secure Digital Multiplexer. This is SD card switcher
(multiplexer) designed to help automatic testing.
.
The software is designed to work with Tizen's SD MUX [0], but it is also
compatible with SDWire [1], which is now recommended over the former.
.
[0] 
[1] 

While the archive has usbsdmux packaged they are simply two different
hardware with different way fo solving the same problem, so they need
different approaches. I have reached usbsdmux's ceratrors and they are
not going to add support for the SDWire, and I prefer C++ rather than
python, so better to have this software also packaged.

Re: /usr/-only image

[Russ Allbery]

Marc Haber  writes:

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

I've been using Debian for a lot of years now, and while describing our
dconfiguration handling as vastly superior is possibly warranted (it's
been a long time since I've tested the competition so I don't know from
first-hand experience), saying that changes are handled nicely doesn't fit
my experience.

I have spent hours resolving configuration changes on Debian systems that
turn out to be changes in comments or settings that I never changed, and
even more hours maintaining absurdly complicated code that tries to handle
in-place updates of all-in-one configuration files, extract information
from them that needs to be used by maintainer scripts, or juggle the
complicated interaction between debconf and the state machine of possible
user changes to the file outside of debconf.  This is certainly something
that we put a lot of effort into, and those of us who have used Debian for
a long time are used to it, but I wouldn't describe it as nice.

Most of this problem is not of our creation.  Managing configuration files
in an unbounded set of possible syntaxes, many of which are ad hoc and
have no standard parser and often do not support fragments in directories,
is an inherently impossible problem, and we try very hard to carve out
pieces of it that we can handle.  But there are many packages for which a
split configuration with a proper directory of overrides and a standard
configuration syntax would be a *drastic* improvement over our complex
single-file configuration management tools such as ucf, let alone over
basic dpkg configuration file management.

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

Bug#1051401: general: PATH variable definition in debian 12

[Timo Lindfors]

On 9/7/23 14:59, robin hodges wrote:

Had a problem when I installed debian 12 onto my PC. As root the reboot and 
shutdown commands wouldnt work.
I have solved this on my PC by including the following into the root .bashrc 
file

export PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin


Did you login as root by typing "su" instead of "su --login"? If yes, 
this is normal behavior, check "man su":


"It is recommended to always use the --login option"

-Timo

Re: Default font: Transition from DejaVu to Noto

[Gunnar Hjalmarsson]

On 2023-09-14 10:50, Adam Borowski wrote:

On Wed, Sep 13, 2023 at 09:09:00PM +0200, Gunnar Hjalmarsson wrote:

There is a problem with fonts-noto-core, though, as several people
have mentioned already: For non-LCG scripts it provides one font
per script. And there are quite a few of those. So for a user, who
wants to actively and often select font in a font picker, the list
of font options gets horribly long.

Personally I see that as a shortcoming in the font pickers. They
ought to offer some "favorites" functionality, in the same manner
as it works with keyboard layouts. Unfortunately they don't, at
least as far as I know.


Why "favorities"?  No other font assumes itself to be special enough
to require such an extra functionality.


I didn't mean to attach any such characteristic to the fonts. The idea 
is to let each user cherry pick a set of fonts between which they can 
switch easily.


--
Gunnar

Re: Default font: Transition from DejaVu to Noto

[Gunnar Hjalmarsson]

On 2023-09-13 21:29, Jonas Smedegaard wrote:

Quoting Gunnar Hjalmarsson (2023-09-13 21:09:00)

There is a problem with fonts-noto-core, though, as several people
have mentioned already: For non-LCG scripts it provides one font
per script. And there are quite a few of those. So for a user, who
wants to actively and often select font in a font picker, the list
of font options gets horribly long.

Personally I see that as a shortcoming in the font pickers. They
ought to offer some "favorites" functionality, in the same manner
as it works with keyboard layouts. Unfortunately they don't, at
least as far as I know.


Perhaps it is then immature to switch to using fonts-noto by
default, for the above reason alone


Yeah, given the Debian culture with respect to font handling, the 
proposal may have been raised prematurely.



So we have a conflict of goals here. The good news is that a user
who speaks some latin language, and who thinks it's important to be
able to easily select font directly in various applications, can
do:

apt purge fonts-noto-core


Just as easily as those disliking a font can remove it, those
appreciating a font can install it.  Difference is if we want to
bloat all systems by default or not.


Yep. That's the crux of this discussion.

--
Gunnar

Re: Default font: Transition from DejaVu to Noto

[Gunnar Hjalmarsson]

On 2023-09-14 11:16, Fabian Greffrath wrote:

Seriously, what I think should be installed on *every* system is a
complete set of serif/sans/mono latin fonts. And then additional
fonts should get pulled in by task-*-desktop packages based on the
user's selected language during D-I. This is how it was in
"fonts-dejavu-core" times.


This discussion tends to confirm that view as the consensus.


Instead, if you install fonts-noto-core on every system (at least as
it is now) you don't actually help the e.g. Devanagari people by
installing a Tamil font on their systems and vice versa (just to
pick some examples). But in the end, everybody ends up with
literally hundreds of fonts that they can read as much or less as the
"tofu" glyphs that they are meant to replace.


True. It's still what I personally would prefer.

Let me point at one not uncommon case: People who are able to read some 
non-Latin language(s) often prefer English as the display language — 
because the particular non-Latin language has poor translation coverage 
or for some other reason — and hence install in English. Then the task-* 
files don't help much.



Anyway, probably the conclusion from this discussion is that we should 
move fonts-noto-core downwards in this list:


$ apt-cache depends fontconfig-config | grep fonts
 |Depends: fonts-noto-core
 |Depends: fonts-dejavu-core
 |Depends: fonts-liberation
 |Depends: fonts-croscore
 |Depends: fonts-freefont-otf
 |Depends: fonts-freefont-ttf
 |Depends: fonts-urw-base35
  Depends: fonts-texgyre

It's a bit ironic. I proposed in a MR to prepend fonts-noto-core to that 
list, and you merged it. At the time I wasn't aware of the significance 
of being listed first, and I suppose you weren't either.


As regards 60-latin.conf there is probably no reason to change it 
further compared to upstream. If a user installs fonts-noto-core, Noto 
will become default for sans-serif and serif, and it's reasonable to 
assume that it is what they want in that case.


What do others think? Is that a reasonable conclusion from this discussion?

--
Gunnar

Bug#1051942: ITP: kiwi-keg -- Create KIWI image descriptions based on snippets

[Isaac True]

Package: wnpp
Severity: wishlist
Owner: Isaac True 
X-Debbugs-Cc: debian-devel@lists.debian.org, isaac@is.having.coffee

* Package name: kiwi-keg
  Version : 2.1.1
  Upstream Contact: Public Cloud Team 
* URL : https://github.com/SUSE-Enceladus/keg
* License : GPL-3.0
  Programming Lang: Python
  Description : Create KIWI image descriptions based on snippets

Keg is a tool which helps to create and manage image descriptions for use with
the KIWI appliance builder. A KIWI image description consists of a single XML
document that specifies type, configuration, and content of the image to
build. Optionally there can be configuration scripts and overlay archives
added to an image description, which allow for further configuration and
additional content.

Since KIWI image descriptions are monolithic, maintaining a number of image
descriptions that have considerable overlap with respect to content and setup
can be cumbersome and error-prone. Keg attempts to alleviate that by allowing
image descriptions to be broken into modules. Those modules can be composed in
different ways in so called image definitions, and modules can inherit from
parent modules which allows for fine-tuning for specific image setups.
Configuration scripts and overlay archives can also be generated in a modular
fashion.

This package depends on the `kiwi` package, along with various Python modules.

Bug#1051940: ITP: golang-github-stefanhaller-tcell -- Cell based view for text terminals

[Jongmin Kim]

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

* Package name: golang-github-stefanhaller-tcell
  Version : 0.0~git20230806.2dfa11e
  Upstream Contact: Jongmin Kim 
* URL : https://github.com/stefanhaller/tcell
* License : Apache-2.0
  Programming Lang: Go
  Description : Cell based view for text terminals

 Package tcell provides a cell based view for text terminals, like xterm.
 It was inspired by termbox, but differs from termbox in some important
 ways. It also adds substantial functionality beyond termbox.

The package is in the dependency tree of lazygit (#908894)[1,2].
The package upstream[3] is a forked version of tcell[4] which is
already packaged in Debian archive[5].

[1] https://bugs.debian.org/908894
[2] https://github.com/jesseduffield/lazygit-debian/wiki/Dependency-graph
[3] https://github.com/jesseduffield/go-git
[4] https://github.com/gdamore/tcell
[5] https://tracker.debian.org/pkg/golang-github-gdamore-tcell.v2

Bug#1051939: ITP: ubpm - Universal Blood Pressure Manager

[Steven Robbins]

Package: wnpp
Severity: wishlist
Owner: "Steve M. Robbins" 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org

* Package name: ubpm
  Version : 1.9.0
  Upstream Contact: Thomas Löwe 
* URL : https://codeberg.org/LazyT/ubpm
* License : GPL v3
  Programming Lang: C++
  Description : Universal Blood Pressure Manager

The UBPM manages blood pressure readings, imported directly from supported
devices,
from files (CSV, JSON, XML, SQL), or entered manually.  Readings may be viewed,
printed, or mailed as a chart, table, or statistics.

Features:
  * export data to CSV, JSON, XML, SQL or PDF format
  * migrate data from vendor software
  * analyze data via SQL queries
  * plugin interface for blood pressure monitors with a computer interface
(USB, Bluetooth)

My intention is to maintain this under the Debian-med umbrella
https://salsa.debian.org/med-team

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

Bug#1051930: ITP: node-node-pty -- Node.js library to allow one to fork processes with pseudoterminal file descriptors

[Yadd]

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

* Package name: node-node-pty
  Version : 1.0.0
  Upstream Contact: node-pty authors
  
* URL : https://github.com/microsoft/node-pty/issues
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js library to allow one to fork processes with 
pseudoterminal file descriptors

node-node-pty provides forkpty bindings for node.js. This allows one to fork
processes with pseudoterminal file descriptors. It returns a terminal object
which allows reads and writes. This is useful for:
 * Writing a terminal emulator
 * Getting certain programs to think they are in a terminal

node-node-pty is a dependency of node-xterm 5 which is needed to build
node-jupyterlab. Will be maintained under JS Team umbrella.

Bug#1051928: ITP: python3-kiwi-boxed-plugin -- KIWI plugin to provide self contained build support using QEMU

[Isaac True]

Package: wnpp
Severity: wishlist
Owner: Isaac True 
X-Debbugs-Cc: debian-devel@lists.debian.org, isaac@is.having.coffee

* Package name: python3-kiwi-boxed-plugin
  Version : 0.2.28
  Upstream Contact: Marcus Schäfer 
* URL : https://github.com/OSInside/kiwi-boxed-plugin/
* License : GPL-3.0
  Programming Lang: Python
  Description : KIWI plugin to provide self contained build support using 
QEMU

Users building images with KIWI face problems if they want to build an image
matching one of the following criteria:

 - Build should happen as non root user.
 - Build should happen on a host system distribution for which no KIWI
   packages exists.
 - Build happens on an incompatible host system distribution compared to the
   target image distribution. For example building an apt/dpkg based system on
   an rpm based system.
 - Run more than one build process at the same time on the same host.
 - Run a build process for a different target architecture compared to the
   host architecture (Cross Arch Image Build)

The python3-kiwi-boxed-plugin is an optional plugin for KIWI which
adds an additional command (`kiwi system boxbuild`) that allows building
KIWI images inside a self-contained QEMU VM environment and overcoming
the problems mentioned above.

This is helpful for users of KIWI who have complex requirements for
generating KIWI images. It requires `qemu-system-x86/arm`, as well as the
`kiwi` package (already in the archives). It is an optional extension to KIWI.

As this is will be my first package in Debian, I am looking for a
sponsor to help to get this included in the archives.

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

[Fabian Greffrath]

> So we have a conflict of goals here. The good news is that a user who
> speaks some latin language, and who thinks it's important to be able
> to easily select font directly in various applications, can do:
> 
> apt purge fonts-noto-core

If this is deemed "okayish", then why bother about a default font
installation at all? Why not install all the cruft and let the user
uninstall what they don't need? Its that easy. 

Seriously, what I think should be installed on *every* system is a
complete set of serif/sans/mono latin fonts. And then additional fonts
should get pulled in by task-*-desktop packages based on the user's
selected language during D-I. This is how it was in "fonts-dejavu-core"
times.

Instead, if you install fonts-noto-core on every system (at least as it
is now) you don't actually help the e.g. Devanagari people by
installing a Tamil font on their systems and vice versa (just to pick
some examples). But in the end, everybody ends up with literally
hundreds of fonts that they can read as much or less as the "tofu"
glyphs that they are meant to replace.

> Some people have complained.[3] But overall I think that most users
> like the idea with a worldwide font coverage.

That may be the Noto project's goal, but not mine. Is it Debian's goal
at all? Note that I am not talking about font *availability* here, but
worldwide coverage in the default install.

> Perhaps the primary suggestion, but not the expected future:  I
> maintain
> the package fonts-noto, and what you refer to is the opinion of
> Fabian,
> who disagrees with my views on how to maintain that package.

No, that's the one thing that the bug reporter in #983291 requested
from you. Please read it again.

Also, maybe it would make sense to populate the fonts-noto-core package
by an actual selection based on alternatives and quality. The summary
provided here may provide a hint:

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

Cheers,

 - Fabian



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

Re: Default font: Transition from DejaVu to Noto

[Adam Borowski]

On Wed, Sep 13, 2023 at 09:09:00PM +0200, Gunnar Hjalmarsson wrote:
> There is a problem with fonts-noto-core, though, as several people have
> mentioned already: For non-LCG scripts it provides one font per script. And
> there are quite a few of those. So for a user, who wants to actively and
> often select font in a font picker, the list of font options gets horribly
> long.
> 
> Personally I see that as a shortcoming in the font pickers. They ought to
> offer some "favorites" functionality, in the same manner as it works with
> keyboard layouts. Unfortunately they don't, at least as far as I know.

Why "favorities"?  No other font assumes itself to be special enough to
require such an extra functionality.  And in good font pickers (eg. GTK2 but
spefically _not_ GTK3), each font family gives a single entry, with
styles being a secondary choice.

Also, for pickers that are helpful enough to provide a sample outright,
being told that a family is family means they need to load and render the
sample from only one font file.  I don't see a real way to speed that up
(can parallelize, but that's about it).  Fontconfig's caches let you avoid
having to open the font files to fetch metadata, but there's too many
details that can alter rendering samples (connected monitors, font size,
etc) to cache the images reasonably.

> So we have a conflict of goals here. The good news is that a user who speaks
> some latin language, and who thinks it's important to be able to easily
> select font directly in various applications, can do:

I wouldn't care about Latin languages at all here.  About any font can do
this well, and there are thousands of fonts that do it better than Noto
(plus hundreds of thousands that do it worse).  Heck, my favourite font I
use for non-monospace browser setting is Aroania (bin:fonts-ancient-scripts)
-- a byproduct of a random script I can't even read nor I care about.

> But the many fonts is not only a disadvantage. It allows you to prefer Noto
> fonts for some non-latin scripts, and other fonts for other ditto. This
> flexibility is effectively blocked if DejaVu Sans, where everything is
> bundled into the same font, is installed and default.

This can be done by giving high-quality optional packages a higher score
than the fallback default.

> Since it already has been changed back to DejaVu Sans Mono for monospace,
> let's talk about sans-serif/serif here.

I wouldn't call either Dejavu Sans Mono nor Noto Mono contenders for a
good Latin monospace font, it's a pretty crowded competition.  Things were
different the previous millenium when Dejavu was made, but we can do better.

> you need to be attentive to the font rendering settings. As an example I
> think that enabling 10-sub-pixel-rgb.conf is a good idea for many screens
> when using Noto fonts.

That's a bad default as it produces a distinctly bad result on any non-RGB
(usually rotated) screen.  Monochrome AA is safe, and while it might be even
good to enable sub-pixel RGB _dynamically_, changing sub-pixel dynamically
is not a thing yet as far as I'm aware.  Thus, let's pick an AA default
that's good enough but works for everyone.

Requiring RGB to look good is another strike against Noto.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ I was born a dumb, ugly and work-loving kid, then I got swapped on
⢿⡄⠘⠷⠚⠋⠀ the maternity ward.
⠈⠳⣄