Bug#1069791: console-setup: Build larger console fonts for HiDPI/accessibility with future 6.9 kernels
My apologies for missing the existing bug scrolling through the list. There were a lot of them to sift through. I may see if some of them have been incidentally fixed as far as I can tell. I understand the eventual goal for the kernel folks is to rid themselves of CONFIG_VT all together, so I realize this is a stopgap. Even so, could you try to include a DejaVuSansMonoBold font as well? I'd appreciate it if it's possible as I can personally read a smaller heavyweight font and it'd really help debugging servers with my portable display. Obviously the long-term solution is some userspace alternative that does the same thing probably using cage and some restricted tabbed terminal maybe? Hmm. I dunno if that's even on anybody's radar any sooner than forky. Joseph On Fri, Apr 26, 2024, at 10:11, Samuel Thibault wrote: > Control: forcemerge -1 816111 > > Hello, > > T. Joseph Carter, le mer. 24 avril 2024 13:25:22 -0700, a ecrit: >> Linux kernel 6.9+ will support larger font sizes for HiDPI screens. This >> is probably aimed at "more than 4k" monitors, but for accessibility >> reasons it would be really useful to have larger sizes available sooner >> for those of us already have 4k sorts of screens. > > Yes, that was the points in adding the support in the kernel :) > >> Perhaps this might best be done by putting those huge-sized fonts in an >> appropriately named -huge fonts package? I'll leave the implementation >> details to you, this is just a request for the fonts to be created. > > We already had the request in #816111, also #595696 was about possibly > generalizing to using rasterized fonts. > > I gave a try at converting terminus.ttf to bdf with otf2bdf: > > otf2bdf -c C -p 32 -r 72 > /usr/share/fonts/truetype/terminus/TerminusTTF-4.46.0.ttf > > /tmp/terminus.bdf > bdf2psf --fb /tmp/terminus.bdf /usr/share/bdf2psf/standard.equivalents > ascii.set 256 /tmp/terminus.psf /tmp/terminus.sfm > > but the baseline is not coherent. Using DejaVuSansMono seems to be > working better: > > otf2bdf -c C -p 32 -r 100 > /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf > > /tmp/DejaVuSansMono.bdf > bdf2psf --fb --width 32 /tmp/DejaVuSansMono.bdf > /usr/share/bdf2psf/standard.equivalents ascii.set 256 > /tmp/DejaVuSansMono.psf /tmp/DejaVuSansMono.sfm > > (I'm adding a new --width parameter to bdf2psf to specify the expected > width since AVERAGE_WIDTH as set by otf2bdf doesn't really tell) > > Samuel
Bug#1069791: console-setup: Build larger console fonts for HiDPI/accessibility with future 6.9 kernels
Package: console-setup Version: 1.226 Severity: wishlist Dear Maintainer, Linux kernel 6.9+ will support larger font sizes for HiDPI screens. This is probably aimed at "more than 4k" monitors, but for accessibility reasons it would be really useful to have larger sizes available sooner for those of us already have 4k sorts of screens. Perhaps this might best be done by putting those huge-sized fonts in an appropriately named -huge fonts package? I'll leave the implementation details to you, this is just a request for the fonts to be created. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages console-setup depends on: ii console-setup-linux 1.226 ii debconf [debconf-2.0] 1.5.86 ii keyboard-configuration 1.226 ii xkb-data2.41-2 console-setup recommends no packages. Versions of packages console-setup suggests: ii locales2.37-18 ii sysvinit-utils [lsb-base] 3.09-1 Versions of packages keyboard-configuration depends on: ii debconf [debconf-2.0] 1.5.86 ii liblocale-gettext-perl 1.07-7 ii xkb-data2.41-2 Versions of packages console-setup-linux depends on: ii init-system-helpers 1.66 ii kbd 2.6.4-2 ii keyboard-configuration 1.226 console-setup-linux suggests no packages. Versions of packages console-setup is related to: pn console-common pn console-data pn console-tools pn gnome-control-center ii kbd 2.6.4-2 ii systemd 255.4-1+b1 -- debconf information: keyboard-configuration/unsupported_config_options: true keyboard-configuration/ctrl_alt_bksp: false keyboard-configuration/unsupported_options: true console-setup/guess_font: keyboard-configuration/unsupported_layout: true console-setup/fontsize: 16x32 * console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic languages keyboard-configuration/optionscode: console-setup/framebuffer_only: keyboard-configuration/layout: console-setup/fontsize-text47: 16x32 (framebuffer only) * console-setup/charmap47: UTF-8 keyboard-configuration/other: keyboard-configuration/model: Generic 105-key PC keyboard-configuration/switch: No temporary switch * console-setup/fontsize-fb47: 16x32 (framebuffer only) keyboard-configuration/store_defaults_in_debconf_db: true keyboard-configuration/toggle: No toggling console-setup/store_defaults_in_debconf_db: true debian-installer/console-setup-udeb/title: keyboard-configuration/variantcode: * keyboard-configuration/variant: English (US) console-setup/use_system_font: keyboard-configuration/layoutcode: us keyboard-configuration/unsupported_config_layout: true keyboard-configuration/compose: No compose key console-setup/codesetcode: Lat15 * console-setup/fontface47: TerminusBold keyboard-configuration/altgr: The default for the keyboard layout keyboard-configuration/xkb-keymap: us keyboard-configuration/modelcode: pc105
Bug#1063686: installation-reports: GUI checkbox in high contrast dark mode isn't high contrast
Package: installation-reports Severity: wishlist Either normal/a11y or wishlist depending how you wanna call it. I normally use the slang version of the Debian installer. Because I'm using a 14" 1080p portable monitor here, I decided to use the GUI. In dark mode because albino. Bright = pain. Sub-optimal install for me, will switch to ssh as soon as the network's configured. Went to select installer components because parted pls, but when I selected it, I didn't see that it was selected at first. That's odd. Then I looked closer and … oh yeah, I guess it is selected. Just this theme/widget set uses a very small/thin checkmark inside the box. Basically, I'd like a checkbox whose checked/unchecked states are more visually not the same. Particularly important in the dark mode, since that's intended to be high contrast for accessibility reasons. (Which is why I was using it…) Suggest a bigger/bolder checkmark might be the path of least resistance for a fix. Boot method: usb Image version: https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso Date: Sat, 10 Feb 2024 17:54:18 -0800 (in the middle of installing now) Machine: Ryzen 3000 series with B450 chipset Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [?] ← Here's where I noticed the problem
Bug#992457: Broken by irresponsible removal of tempfile in debianutils
Control: retitle -1 FTBFS: uses tempfile in build, appears to use deprecated
which(1)
A closer look indicates that tempfile is only actually used to build the
package. The apparent use of which(1) is actually a shell function, however…
On Wed, Aug 18, 2021, at 16:18, Cyril Brulebois wrote:
> > Presumably /installer-team/console-setup would be a better package to
> > patch, unless cdebconf uses tempfile somehow. 😉 I'll see what I can
> > do this evening. 🙂
>
> Sure thing, miscompleted in my browser history plus slightly distracted,
> sorry.
As suggested before, I'm fluent in IRC, so I read what you meant. 😁
MY goof was breaking my initramfs, being _completely_ unable to read the tiny
font, reverting to backup, futzing with it, seeing tempfile and which being
called in setupcon, and having to go to work before I could dig much deeper.
As noted, tempfile is only actually used to build the package. Fixed that. Left
the function in setupcon alone.
The apparent use of which all over the place is also a shell function, but the
shell function just emulates command -v, so I subbed that out and removed the
functions while I was at it. Tested the result on amd64 with amdgpu added to
initramfs for early KMS so that I can take advantage of Plymouth for status
messages I have some chance of being able to use, and a crypttab prompt that
doesn't get lost in the impossibly small console text.
I realized while composing the email that my patch has some trailing whitespace
removal—nvim is configured to do that to source files as it's usually desirable
for git sanity, but I should've trimmed those hunks out of the patch and
retested. I don't have time to do that tonight because I can't conveniently
just reboot right now, so I'll send you the patch as tested. Feel free to omit
purely whitespace change hunks.
You can maybe guess the major thrust of my attempts to fiddle with
console-setup around the time this all happened: You don't even try to set the
font in the initramfs anymore, and I've never actually figured out why Ubuntu's
combination of console-setup and plymouth manages to just work and Debian's
just doesn't—I've spent a little time prodding at packages from both.
I mostly know my way around a Debian system I think—when I reinstalled this
machine about two weeks ago, I found that neither old nor new installer was
really set up to preserve my LUKS devices with LVM on them, keep some
partitions and format others, etc … so I just grabbed a live USB and installed
the system with debootstrap. It … was faster than trying ti figure out if or
how Calamares could do that, and I know the shell of the old debian installer
didn't provide shell UI I'd need to open the LUKS partitions so the partitioner
could use them without obliterating anything "helpfully" for me. *shrug*
I've gotten way off topic now, but I think I just need to write a hook to throw
in setfont and the font to set along with some quick and dirty initramfs
scripts to make sure it dances around plymouth. I had to do something similar
with a MBP to work around proprietary Apple crap.
Anyway, hope this is useful. Salsa didn't exist when last I might've had an
account on it to be able to actually finish this up as a PR. I've considered
changing that a time or two. Perhaps when the Covidium passes.
Joseph
diff -Nru console-setup.orig/debian/console-setup.config console-setup/debian/console-setup.config
--- console-setup.orig/debian/console-setup.config 2021-08-18 22:17:59.892444554 -0700
+++ console-setup/debian/console-setup.config 2021-08-18 22:42:21.524213193 -0700
@@ -64,7 +64,7 @@
# fontsets='Arabic-Fixed15
# Arabic-Fixed16
# Arabic-VGA14
-# ...
+# ...
# Vietnamese-Fixed18
# '
@@ -104,18 +104,6 @@
db_capb backup
-which () {
-local IFS
-IFS=:
-for i in $PATH; do
- if [ -f "$i/$1" -a -x "$i/$1" ]; then
- echo "$i/$1"
- return 0
- fi
-done
-return 1
-}
-
available_fontfaces () {
local prefix
case "$CODESET" in
@@ -195,14 +183,14 @@
}
kernel=unknown
-if which uname >/dev/null; then
+if command -v uname >/dev/null; then
case "`uname`" in
*Linux*) kernel=linux ;;
*FreeBSD*) kernel=freebsd ;;
esac
fi
-if which locale 2>/dev/null >/dev/null; then
+if command -v locale 2>/dev/null >/dev/null; then
eval `locale`
fi
@@ -217,7 +205,7 @@
if [ "$locale" = C ]; then
CHARMAP=ISO-8859-15
charmap_priority=high
-elif which locale 2>/dev/null >/dev/null; then
+elif command -v locale 2>/dev/null >/dev/null; then
CHARMAP=`locale charmap`
else
CHARMAP=unknown
diff -Nru console-setup.orig/debian/console-setup-udeb.postinst console-setup/debian/console-setup-udeb.postinst
--- console-setup.orig/debian/console-setup-udeb.postinst 2021-08-18 22:17:59.892444554 -0700
+++ console-setup/debian/console-setup-udeb.postinst 2021-08-18 22:43:48.226081884 -0700
@@ -5,20 +5,6 @@
# Source debconf library.
. /usr/share/debconf/confmodule
Bug#992457: Broken by irresponsible removal of tempfile in debianutils
On Wed, Aug 18, 2021, at 14:01, Cyril Brulebois wrote: > T. Joseph Carter (2021-08-18): > > It's debianutils' bug, really, and the bugs keep getting filed (and > > resolved), but there's a half a dozen packages on my system that are > > broken by it. Yours happens to be used at boot time and for general > > system operation. > > It's an ongoing conversation on IRC apparently, and yes, some kind of > advance warning would have been appreciated. O yes, I'm sure there is. I've missed those over the years. 🍿 > That being said, it's not entirely crazy to attempt such changes very > early in the release cycle, and if we ought to move away from those > tools, I don't mind much. Yes, but you "try" to do that by marking the packages deprecated and filing bugs that version 5, due out X weeks, and ask them to make changes or allow NMU. Ideally, you then keep it around for a release or so AFTER you make Debian no longer dependent upon the tools. Dunno who else would miss tempfile, but I'm kinda partial to which since command -v will NOT give you the path to a file if you typically alias that file, and type -P is not POSIX and does not work with dash. > > If you're busy and debianutils' change doesn't get reverted, I can > > prepare a patch. It's literally replacing tempfile and which with > > their more generic equivalents, after all. > > I think we'd be happy to have a patch or a merge request to review, even > more so if you've tested it on a real system. > > The git repo is at: > https://salsa.debian.org/installer-team/cdebconf/ > > but a patch against the source package would be fine too. > > Thanks for the heads-up! Presumably /installer-team/console-setup would be a better package to patch, unless cdebconf uses tempfile somehow. 😉 I'll see what I can do this evening. 🙂 Joseph
Bug#992457: Broken by irresponsible removal of tempfile in debianutils
Package: console-setup Version: 1.205 Severity: important X-Debbugs-Cc: Debianutils >= 5 removes tempname and puts a deprecation notice on the which command. The setupcon script (at least) uses both of these, causing people's initramfs's to be subtly broken and leaving them without a keymap in the event of a boot error., Since the maintainer of Debianutils seems to be content to put out fires as they come up with the excuse that the stable version of Debian declares these to be deprecated (y'know, the one that was released a week ago at time of writing), it is apparently incumbent upon others to fix this in their packages. It's debianutils' bug, really, and the bugs keep getting filed (and resolved), but there's a half a dozen packages on my system that are broken by it. Yours happens to be used at boot time and for general system operation. If you're busy and debianutils' change doesn't get reverted, I can prepare a patch. It's literally replacing tempfile and which with their more generic equivalents, after all. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages console-setup depends on: ii console-setup-linux 1.205 ii debconf 1.5.77 ii keyboard-configuration 1.205 ii xkb-data2.33-1 console-setup recommends no packages. Versions of packages console-setup suggests: ii locales 2.31-16 ii lsb-base 11.1.0 Versions of packages keyboard-configuration depends on: ii debconf 1.5.77 ii liblocale-gettext-perl 1.07-4+b1 Versions of packages console-setup-linux depends on: ii init-system-helpers 1.60 ii kbd 2.3.0-3 ii keyboard-configuration 1.205 console-setup-linux suggests no packages. Versions of packages console-setup is related to: pn console-common pn console-data pn console-tools ii gnome-control-center 1:3.38.4-1 ii kbd 2.3.0-3 ii systemd 247.9-1 -- debconf information: keyboard-configuration/layout: keyboard-configuration/unsupported_config_options: true keyboard-configuration/ctrl_alt_bksp: false * console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic languages * console-setup/fontsize-fb47: 16x32 (framebuffer only) keyboard-configuration/store_defaults_in_debconf_db: true debian-installer/console-setup-udeb/title: keyboard-configuration/xkb-keymap: us console-setup/fontsize: 16x32 keyboard-configuration/unsupported_layout: true keyboard-configuration/switch: No temporary switch keyboard-configuration/model: Generic 105-key PC (intl.) keyboard-configuration/toggle: No toggling console-setup/framebuffer_only: keyboard-configuration/layoutcode: us keyboard-configuration/optionscode: keyboard-configuration/compose: No compose key keyboard-configuration/modelcode: pc105 keyboard-configuration/variantcode: keyboard-configuration/unsupported_config_layout: true console-setup/fontsize-text47: 16x32 (framebuffer only) console-setup/store_defaults_in_debconf_db: true keyboard-configuration/altgr: The default for the keyboard layout keyboard-configuration/unsupported_options: true keyboard-configuration/other: * console-setup/fontface47: TerminusBold console-setup/guess_font: * keyboard-configuration/variant: English (US) * console-setup/charmap47: UTF-8 console-setup/codesetcode: Lat15 console-setup/use_system_font:
Bug#908789: Bug never got a followup
This bug never got a followup, but I can name three circumstances I know of under which it still happens. 1. Almost guaranteed to not be the problem, but it should be documented somewhere: If you use an Atom-based "nettop" where the external display is the only one used, it might appear you have this problem at first, however reconfiguring console-setup doesn't fix the problem—or rather, it only fixes the top left corner of the screen. Observed with Lenovo IdeaCentre Q150. The solution here is to modify the grub configuration (in /etc/default/grub) to disable the LDVS port the chipset thinks has a 1024x768 display connected to it, because the chipset is dropping acid and there totally isn't. Using various tools you can determine that the system does think there is an LDVS display, but turning it off in X11 or anywhere else won't make it go away. Gotta be the kernel command line. 2. If you have plymouth installed and working, you'll get a nice and pretty startup, but your font setting won't happen. I'm thinking I might hook setupcon into starting a getty and see if that resolves it. Hack solution, but I'm not sure if that'll work or if it does maybe that it's as good as it gets. 3. If your framebuffer driver loads late, the console may be set up in the initrd before your larger fonts can be loaded. Make sure that your correct framebuffer driver is loaded early by adding it to /etc/modules by hand if necessary and then running update-initramfs -u -k al. There have been other issues with console-setup and the systemd transition that have since been fixed, but I was looking to see if someone had proposed a more elegant solution to #2 than I'm considering and stumbled upon this bug being open from ages ago. That means anyone reporting a bug that their system seems to have small fonts on boot is going to be looking at this bug to see if it describes their problem. These are the things I've seen happen and how to fix them, since none of them are really a problem in console-setup directly. Joseph
Bug#939533: task-xfce-desktop: should use libreoffice-gtk3 instead of -gtk2
Package: task-xfce-desktop Version: 3.55 Severity: normal The XFCE task continues to depend on libreoffice-gtk2, but xfce 4.14 is now fully gtk3-based and has dropped support for gtk2 integration. Time to update to libreoffice-gtk3 for the task package? -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages task-xfce-desktop depends on: ii lightdm 1.26.0-5 ii task-desktop 3.55 ii tasksel 3.55 ii xfce4 4.14 Versions of packages task-xfce-desktop recommends: ii atril 1.22.1-1 ii dbus-user-session [default-dbus-session-bus] 1.12.16-1 ii dbus-x11 [dbus-session-bus] 1.12.16-1 ii hunspell-en-us1:2018.04.16-1 ii hyphen-en-us 2.8.8-7 ii libreoffice 1:6.3.1~rc2-3 ii libreoffice-gtk2 1:6.3.1~rc2-3 ii libreoffice-help-en-us1:6.3.1~rc2-3 ii light-locker 1.8.0-3 ii mousepad 0.4.2-1 ii mythes-en-us 1:6.3.0-1 ii network-manager-gnome 1.8.22-2 ii orca 3.32.0-1 ii parole1.0.4-1 ii quodlibet 4.2.1-1 ii synaptic 0.84.6+b1 ii system-config-printer 1.5.11-4 ii tango-icon-theme 0.8.90-7 ii xfce4-goodies 4.12.6 pn xfce4-mixer ii xfce4-power-manager 1.6.5-2 ii xfce4-terminal0.8.8-1+b1 ii xsane 0.999-7 task-xfce-desktop suggests no packages. -- no debconf information
Bug#77920: passwords entered in base-config are not treated literally
Package: boot-floppies Version: N/A; reported 2000-11-24 Severity: important When asked for a passwd on first boot, certain punctuation characters are mangled. This bug should be considered RC because following good security practices (ie, feeding damned near line noise in for a passwd) is able to give you a system you can't even login to - if this were my first experience with Debian I'd go install something else! The obvious workaround is to enter an alphanumeric passwd and change it after login. The correct solution is to ensure that the string typed by the user is not screwed with in any way. This means nothing special should happen to characters such as $ # \ % & | etc that may be entered. -- System Information Debian Release: woody Architecture: i386 Kernel: Linux trinity 2.2.18pre15 #1 Wed Nov 8 14:37:38 EST 2000 i686 -- Joseph Carter <[EMAIL PROTECTED]> GnuPG key 1024D/DCF9DAB3 Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3 "The difference between genius and stupidity is that genius has it's limits." -- Albert Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
hardware detection
I'm not currently on this list, yadda yadda.. I'm not sure anyone not on irc is aware of it, but I'm working on hardware detection. I've got a bit of it working so far, but I'm still not finished with it. I'm working with libdetect and trying to make its output useful. This is easier said than done given that libdetect only does its thing with a newer isapnptools (I have a NMU ready for dupload) and then is primarily a tool for detecting PCI/ISA.. In other words, it's somewhat ia32-centric right now. It apparently works on Alpha and PPC, but I don't know if it does anything useful yet. It's a ramdisk-based thing, just like other dists have been using. It requires a small kernel patch which is fairly trivial as kernel patches go (someone broke /linuxrc for ramdisks and the patch fixes it, possibly even correctly...) All in all, the program can be used as part of a two-stage detection process, the first stage fitting onto a ramdisk which can be used and then removed from memory later. It's purpose is simply to get / mounted (in case it's a scsi disk or a cdrom drive or something..) The second stage can detect things like sound cards and the like. It's still kinda in the early stages and I'd rather not stop to explain the little details now, but I'm working on it for Progeny anyway and intend to make it available outside of Progeny as soon as I have the major kinks out of it. I may upload it to Debian, but only if it's likely to be used. I don't want to maintain a package that won't work with Debian and this requires small mods to things like kernel-package, the kernel source, and the boot floppies. I know I'll be using it here, but there's no sense in maintaining a useless package. -- Joseph Carter <[EMAIL PROTECTED]> GnuPG key 1024D/DCF9DAB3 Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3 "You have the right not to be an asshole. If you give up that right everything you say and do in here will be held against you. If you cannot afford to stop being an asshole then someone will be appointed to kick yours outta here." -- Your rights as an irc addict -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
