Bug#999069: console-cyrillic: diff for NMU version 0.9-17.2
On Tue, Jan 04, 2022 at 09:19:29AM +0200, Adrian Bunk wrote: > > I've prepared an NMU for console-cyrillic (versioned as 0.9-17.2) and > uploaded it to DELAYED/7. Please feel free to tell me if I should cancel it. Thanks. Anton Zinoviev
Bug#767442: trscripts: diff for NMU version 1.18+nmu3
On Mon, Sep 20, 2021 at 11:53:48AM +0200, Jochen Sprickerhof wrote: > > Thanks for the maintainer offer, I don't intent to put more work into it > currently Well, perhaps there is no immediate need for more work. > but if you want to pass maintainership I would propose to move it to > the Debian Fonts Task Force (Cced) and have both of us as uploaders. > What do you think? Whatever you decide. However, notice that I won't have much time for work in a group. Anton Zinoviev
Bug#767442: trscripts: diff for NMU version 1.18+nmu3
On Sun, Sep 19, 2021 at 09:34:44PM +0200, Jochen Sprickerhof wrote: > > I've prepared an NMU for trscripts (versioned as 1.18+nmu3) and > uploaded it. I also took the freedom to modernize the package, hope that is > fine with you. The changes a somewhat too big for a NMU. So I must ask you if you want to take over this package? Do you want to become its maintainer? Anton Zinoviev
Bug#965029: console-setup: fonts missing numerous unicode->font mappings for box-drawing characters
On Mon, Jul 20, 2020 at 09:03:33PM -0400, Nick Black wrote: > > Tested all three using the same methodology as outlined earlier. > > Looks perfect =]. Thanks. Anton Zinoviev
Bug#965029: console-setup: fonts missing numerous unicode->font mappings for box-drawing characters
On Mon, Jul 20, 2020 at 09:34:36AM -0400, Nick Black wrote: > > I don't make use of the following, so they're not important to > me, but it might be worthwhile to handle these: > > U+2BBD BALLOT BOX WITH LIGHT X > U+2718 HEAVY BALLOT X > U+2717 BALLOT X Оk. I've attached updated versions of Arabic-Fixed16.psf, Arabic-VGA16.psf and Lat15-Terminus16.psf. Hopefully, this time the fonts are ok. > Will this work be going upstream? I'm not clear on whether > you're the upstream maintainer, or just Debian's. In this case Debian = upstream. Anton Zinoviev Arabic-VGA16.psf Description: Binary data Arabic-Fixed16.psf Description: Binary data Lat15-Terminus16.psf Description: Binary data
Bug#965029: console-setup: fonts missing numerous unicode->font mappings for box-drawing characters
On Mon, Jul 20, 2020 at 05:32:55AM -0400, Nick Black wrote: > > To be more precise, U+2571 BOX DRAWINGS LIGHT DIAGONAL UPPER > RIGHT TO LOWER LEFT ought be getting mapped to U+002F SOLIDUS > aka '/', but is instead being mapped to U+0025 PERCENT SIGN aka > '%'. Thanks. On Mon, Jul 20, 2020 at 05:48:15AM -0400, Nick Black wrote: > While I've got you here, while the case isn't quite as clear-cut > for these two, I'd suggest mapping > > U+2612 BALLOT BOX WITH X -> U+0058 LATIN CAPITAL LETTER X > > and > > U+2610 BALLOT BOX -> U+002D HYPHEN-MINUS or, if you prefer, > U+004F LATIN CAPITAL LETTER O What about these? . for U+2610 BALLOT BOX v for U+2611 BALLOT BOX WITH CHECK x for U+2612 BALLOT BOX WITH X Anton Zinoviev
Bug#965029: console-setup: fonts missing numerous unicode->font mappings for box-drawing characters
On Tue, Jul 14, 2020 at 12:54:59PM -0400, Nick Black wrote: > > I'm happy to make these patches and send them upstream, but Anton Zinoviev > requested that I file a bug here. In this way the requiest is documented. More difficult to forget about it... > I consider the following wide strings to be acceptable fallback sets (taken > from Notcurses src/lib/linux.c): Thanks. > Let me know how I can make myself useful. If you can, please test the fonts I have attached. Anton Zinoviev Arabic-VGA16.psf Description: Binary data Arabic-Fixed16.psf Description: Binary data Lat15-Terminus16.psf Description: Binary data
Bug#961362: fonts-terminus-otb: In rxvt-unicode, M and m characters missing the left vertical stroke
On Sat, May 23, 2020 at 08:42:59AM -0700, Ian Zimmerman wrote: > > The PCF format font (which I assume is generated from the same source) > has no such problem. I suppose this is not a font problem but a problem of the rendering engine. The rendering engine of the OTB fonts is more sofisticated than the rendering engine of the PCF fonts. It can render the fonts in arbitrary font sizes (including non-integer sizes). But as usually, with sofistication come problems, undebugged cases, etc. > Specifically, I use the 12 size font. How about 13 size? Or maybe something like 12.1, 12.2, 12.3 or 12.4 (or 12,1, 12,2, 12,3 and 12,4 in locales with decimal comma)? Anton Zinoviev
Bug#960503: xfonts-terminus: 50-enable-terminus.conf missing, fonts are not enabled
On Thu, May 14, 2020 at 11:22:20PM +0200, Jochen Sprickerhof wrote: > > Did you try it without xfonts-terminus installed (to not run into > #960502)? No, I didn't. :) Ok, now i managed to reproduce the bug. I made some tests also with mate-terminal. It always seems to prefer the otb fonts and always displays them differently than st. No matter what font size I select, the ratio width/height is always larger in st and smaller in mate-terminal. Also, in mate-terminal font size 14 corresponds to approximately 20 in st. I suppose that mate-terminal takes into account that my monitor has slightly larger dpi than the normal monitors. Anton Zinoviev
Bug#960503: xfonts-terminus: 50-enable-terminus.conf missing, fonts are not enabled
On Wed, May 13, 2020 at 06:15:28PM +0200, Jochen Sprickerhof wrote: > > I'm ok with that, except I found that I had to adopt the width of the otb > version by 0.85 to resemble the one of the pcf. Specifically I compared > Terminus:pixelsize=14 to ter-u14n_iso-8859-1.pcf.gz in the suckless terminal > st, setting cwscale=0.85 in the config. Is the different width on purpose? I can not reproduce this. First I tried static char *font = "Terminus:pixelsize=14"; Then I tried static char *font = "-xos4-terminus-medium-r-normal--14-140-72-72-c-80-iso10646-1"; In both case the st window is indentical and uses the font I requested. In the second case, however, st prints twice the message "font weight does not match". Anton Zinoviev
Bug#960503: xfonts-terminus: 50-enable-terminus.conf missing, fonts are not enabled
severity 960503 normal retitle 960503 After upgrade from 1.40 fonts are no longer enabled thanks On Wed, May 13, 2020 at 01:16:32PM +0200, Jochen Sprickerhof wrote: > Severity: grave > Justification: renders package unusable Well, the package is not unusable. It is usable by all X programs which do not rely on fontconfig. On the other hand, programs which rely on fontconfig should probably use the fonts in fonts-terminus-otb instead of the fonts in this package. Practically, this means that most users should install fonts-terminus-otb instead xfonts-terminus. > the new version lacks the 50-enable-terminus.conf, meaning the fonts are > not usable anymore. Please either add a dependency to fonts-terminus-otb > (as long as you don't apply #960502) or create the file(s) again. Returning 50-enable-terminus.conf to xfonts-terminus is not good because programs relying on fontconfig should use fonts-terminus-otb instead. (If a program is based on GTK it is unable to use PCF fonts no matter how we configure fontconfig). Dependency on fonts-terminus-otb is not good because programs which are able to use the fonts of xfonts-terminus don't need the fonts in fonts-terminus-otb. And yes, I am considering applying the patch (or a similar one) in #960502. I don't like the fact that after upgrade the Terminus fonts are not enabled. But I am not sure what is the proper fix for this. One possible course of action would be to: 1. rename xfonts-terminus => xfonts-terminus-pcf 2. create an empty package xfonts-terminus depending on both xfonts-terminus-pcf and fonts-terminus-otb But isn't this an overkill? Anton Zinoviev
Bug#960502: fonts-terminus-otb: 71-enable-terminus.conf enables PCF fonts too
On Wed, May 13, 2020 at 01:02:16PM +0200, Jakub Wilk wrote: > > Worse, at least on my system, fontconfig seems to prefer the PCF > fonts. :-/ Why is this a problem? Thanks. Anton Zinoviev
Bug#843982: Still having this issue
On Mon, May 11, 2020 at 12:44:42PM -0300, Nelson A. de Oliveira wrote: > > Today after upgrading from 4.40-2 to 4.48-1 I had this issue one more > time (where I was unable to open any terminal; message was "urxvt: > unable to load base fontset, please specify a valid one using -fn, > aborting.") > > I had to manually run "xset fp rehash" again. The command xset has to be executed _within_ the X session of the current user. On the other hand the upgrade of the package can happen anywhere, for example in the text console or in a X terminal but as root user without the rights to execute X programs. Therefore, the upgrading packages (including xfonts-terminus) are not always allowed to execute X commands. > Now I am unsure if "xset fp rehash" needs to be called in some other > step while upgrading/installing xfonts-terminus or if there is another > kind of issue somewhere else. I am unsure too. It would be best if X autodetects that the fonts have changed and runs this command automatically. Anton Zinoviev
Bug#932258: console-setup-freebsd: missing dependency
On Wed, Jul 17, 2019 at 04:15:51PM +0200, Guillem Jover wrote: > > this seems like a problem with console-setup-freebsd being arch:all > and depending on kFreeBSD-specific packages which will not be > available elsewhere, in the same way console-setup-linux is an > arch:all depending on Linux-specific packages. Why is it a problem to have an arch:all package which is installable only on some architectures (due to missing dependencies)? Anton Zinoviev
Bug#833116: fgetty: Incorrect keystroke interpretation
On Thu, Dec 20, 2018 at 06:02:47PM +, Dmitry Bogatov wrote: > > Anton, could you please clarify, how locale is set up by this function > call if process inhereted no locale-related variables. I don't know. Anton Zinoviev
Bug#833116: fgetty: Incorrect keystroke interpretation
On Wed, Dec 05, 2018 at 08:56:16AM +, Dmitry Bogatov wrote: > > [ Added console-setup maintainers into thread ] > Hello, dear console-setup maintainers. Could you please take a look at > this bug? Maybe the locale is not set properly by some versions of getty? If bash is started in a non-UTF8 locale and some of the startup scripts of bash assigns an UTF-8 locale to the LANG variable, we can expect problems exactly like this. Suppose that we have a working bash shell with UTF-8 console where ñ displays properly. Then try this: LANG=C bash # run a subshell in a non-UTF8 locale If you press ñ, you will see (arg: 1). The programs (including a subshell) also work incorrectly because the locale is not UTF8. Now execute this: LANG=. (some UTF-8 locale) Now, if you press ñ, you will see (arg: 1) like before. The programs (including a subshell), however, will work correctly. Now execute this: export LANG Now also ñ works correctly. If you are sure that the problem does not come from the locale, another thing to check is to compare the output of bind -v bind -p in bash where ñ works properly and in bash where ñ leads to (arg: 1). Also make sure there are no files ~/.inutrc and the variable INPUTRC is unset. Anton Zinoviev
Bug#899979: keyboard-configuration: the caron dead-key of the czech keyboard on the console does not work as expected
On Fri, Jun 01, 2018 at 04:28:23PM +0200, Samuel Thibault wrote: > > Maybe we should just go and define all X11 deadkeys in Linux (there > are like 55 of them, that will fit), to be done with the issue. Either this, or console-setup can have a hardcoded list of "Latin2" layouts. Anton Zinoviev
Bug#899979: keyboard-configuration: the caron dead-key of the czech keyboard on the console does not work as expected
On Fri, Jun 01, 2018 at 04:10:36PM +0200, Samuel Thibault wrote: > > U+015A would be what you'd expect for a latin1 language (^ + S), and I > guess due to rule ordering, the existing rule doesn't get overrident by > the rule you introduced, so we need to explicitly remove the existing > rule. And what should the future console-setup do with compose+^+S when the encoding is UTF-8? How is this problem solved in X? Anton Zinoviev
Bug#899979: keyboard-configuration: the caron dead-key of the czech keyboard on the console does not work as expected
On Thu, May 31, 2018 at 11:12:43PM +0300, Anton Zinoviev wrote: > > only important bugs are fixed I realised the word 'important' was very inapropriate in this context. What is unimportant for one user can be very important for another. So by 'important' bugs I meant things about unauthorized access or corruption/deletion of data. If a bug makes a package totally unusable, but otherwise harmless, then this bug is (usually) not going to be fixed in the stable release. Anton Zinoviev
Bug#899979: keyboard-configuration: the caron dead-key of the czech keyboard on the console does not work as expected
On Mon, May 28, 2018 at 12:25:04PM +0200, Jan Rafaj wrote: > > Anton, thanks for suggesting the workaround. However, adding the kmap > "snapped" with ckbcomp and hand-modified afterwards as a value to 'KMAP=' in > the /etc/default/keyboard is not really a workaround, since > this overrides whatever that the user may have set in the XKBOPTIONS (such > as grp switching/toggling), effectively leaving her/him with only the > localised KMAP loaded. Instead of the command ckbcomp cz >cz.kmap which I suggested in my previous message, you can use something like ckbcomp cz dvorak-ucw grp:win_menu_switch lv3:menu_switch >cz.kmap See `ckbcomp -help` or `man ckbcomp`. > With all the above said, I've been able to create a (hopefully) complete > set of all the missing compose defs for the czech letters. Thanks, this will be useful. > I think this could be fixed right in the Stretch. When I have time I will upload a fixed package to Unstable. I am not sure, but I think only important bugs are fixed in the stable releases of Debian. Unless there is some change in the policies of Debian of which I am not aware (which is not impossible, to be honest...). Anton Zinoviev
Bug#899979: keyboard-configuration: the caron dead-key of the czech keyboard on the console does not work as expected
On Sat, May 26, 2018 at 01:17:03PM +0200, Samuel Thibault wrote: > > Keymaps do have e.g. > > ./keymaps/i386/qwerty/et.kmap:compose '^' 'S' to Scaron > > I don't remember whether console-setup generates compose sequences, but > it should be feasible. Ah, I didn't know that the compose sequences are used for the dead keys. Compose sequences in console-setup are encoding-based. See for example /etc/console-setup/compose.ISO-8859-2.inc. However at present there is no file compose.UTF-8.inc and even if there is one ckbcomp will not use it. On Thu, May 24, 2018 at 10:46:36AM +0200, Jan Rafaj wrote: > > Please suggest a fix or a workaround. Thanks. This bug should be fixed in a future version of console-setup. But for the time being I can suggest the following fix. Run (as root) cd /etc/console-setup/ ckbcomp cz >cz.kmap Open the created file cz.kmap in a text editor and add the following two lines at the end: compose '^' 'd' to U+010F compose '^' 'D' to U+010E Run (as root) in order to confirm that the new layout works as it should: loadkeys cz.kmap If it does, then add in the file /etc/default/keyboard the following line: KMAP=/etc/console-setup/cz.kmap Remove this line from /etc/default/keyboard when you receive a message that the bug has been fixed. Anton Zinoviev
Bug#899979: keyboard-configuration: the caron dead-key of the czech keyboard on the console does not work as expected
On Thu, May 24, 2018 at 10:46:36AM +0200, Jan Rafaj wrote: > > I have confirmed that the problem described exists for the "bksl", > "qwerty" and "qwerty_bksl" keyboard variants, as well as XKBVARIANT "" > (in the /etc/default/keyboard). > > The problem described above appeared since the switch from the kbd > package to the keyboard-configuration/console-setup packages, and did not > exist in Debian < 9. The original keyboard layouts of kbd are in the package console-data. Can you install this package and see if some of the Czech layouts works properly with UTF-8 encoding. I have some doubts that the dead keys are usable with non-Latin1 symbols on the console. You can try the various Czech layouts with one of the following six commands: loadkeys cz-lat2.kmap.gz loadkeys cz-us-qwerty.kmap.gz loadkeys cz-lat2-prog.kmap.gz loadkeys cz-us-qwertz.kmap.gz loadkeys sunt5-cz-us.kmap.gz loadkeys sunt5-us-cz.kmap.gz Anton Zinoviev
Bug#883566: console-setup-linux: Add a font which is 9 pixel wide
On Tue, Dec 05, 2017 at 10:57:13AM +0100, Mario Lang wrote: > > I sort of wonder if this is actually a bug/oversight? > Is Fixed15 supposed to have size 15x8? When Fixed15 is used while the graphic card is in text mode (not framebuffer), the font works as 15x9. However, it has to be packaged as 15x8 because of the way the hardware/the kernel driver work. > Therefore, I suggest to add a new face called Fixed15x9. Indeed. These days people most likely use framebuffer so it makes sense to improve the framebuffer support. Fixed15 is not the only x9 font. TerminusBoldVGA is another nice font which is developed as x9 font but is packaged as x8. Also all x8 VGA fonts and the non-bold Terminus font are designed to look ok if they are used as x9 fonts. Anton Zinoviev
Bug#818065: console-setup is not read correctly at boottime and must be started manually
On Mon, Oct 23, 2017 at 02:55:58PM +, Rupert Perry wrote: > > > This happened to me as well, check if a slight change to the systemd > > unit file helps: > > /lib/systemd/system/console-setup.service > > RequiresMountsFor=/usr /tmp > > I have this same problem and I tried this solution and it didn't fix > the problem for me. I suppose this fixes the problem with the upgrades of console-setup. But I don't like this solution because even if it fixes the problem (does it?), it is not the right solution. I don't think console-setup needs /tmp for its work. This solution works only because requiring /tmp to be mounted means some other dependency will be satisfied as well. But who knows what this other dependency is... Anton Zinoviev
Bug#869513: console-setup changes remain only till next reboot
forcemerge 857132 861454 863630 869513 thanks On Tue, Jul 25, 2017 at 10:47:18PM +0200, Harry Haller wrote: > > Yes, setupcon works - (but only until the next boot too). It seems this bug is another reappearance of a known problem. Unfortunately, some smart people have tried to find the cause and have failed. The bug shows itself only when the system uses systemd. For now you have two options: 1. you can include the command 'setupcon' in some script, for example in .(bash_)profile so that it is executed when you login or 2. you can remove systemd from your system, http://without-systemd.org. Anton Zinoviev
Bug#869513: console-setup changes remain only till next reboot
On Tue, Jul 25, 2017 at 09:47:21PM +0200, Harry Haller wrote: > > Thanks for Your answer. No, there is an error. setupcon says: > > setupcon: None of /etc/default/keyboard./etc/console-setup/cached_Lat15- > TerminusBold24x12.psf.gz, /etc/default/console-setup./etc/console-setup/ > cached_Lat15-TerminusBold24x12.psf.gz, /root/.console-setup./etc/console- > setup/cached_Lat15-TerminusBold24x12.psf.gz, /root/.keyboard./etc/console- > setup/cached_Lat15-TerminusBold24x12.psf.gz exists. Hello! You have to run setupcon without any arguments. Just setupcon and not setupcon /etc/console-setup/cached_Lat15-TerminusBold24x12.psf.gz Anton Zinoviev
Bug#869513: console-setup changes remain only till next reboot
On Sun, Jul 23, 2017 at 10:50:56PM +0200, Harry Haller wrote: > > The changes of the console after "dpkg-reconfigure console-setup" are > as expected, Does the console configure properly (even if only temporarily) if you run "setupcon" instead of "dpkg-reconfigure console-setup"? Anton Zinoviev
Bug#846256: failure on boot
On Fri, Jun 23, 2017 at 02:23:04PM +0200, Badics, Alex wrote: > > We also encountered the bug, and to me, it seems to be caused by the > systemd-tmpfiles-setup.service, shown as "Create Volatile Files and > Directories". This is because /tmp is listed as "D" in > /usr/lib/tmpfiles.d/tmp.conf, which means its contents gets removed > when /bin/systemd-tmpfiles --remove is called, and the service files > does exactly that. > > You might see it in your journal that the bug only happens if > console-setup is started before systemd-tmpfiles-setup. Since I do not know well systemd, I will prefer if some other developer looks into this. The script /bin/setupcon does not require the existence of /tmp because it can use alternative directories if necessary (look at the function tempfile in setupcon). However it will use /tmp if it exists. Therefore, the following perhaps can explain the bug: 1. The scripts of console-setup are started before systemd-tmpfiles-setup. 2. If they finish in time, this is ok. Suppose however that systemd-tmpfiles-setup starts before the scripts of console-setup finish their work. (Is this possible?) 3. Then, ofcourse, if systemd-tmpfiles-setup deletes files that the scripts of console-setup have creaded and expected to be deleted by them and not by some third party, these scripts will fail to work properly. > I think not having "DefaultDependencies=no" in setup-console's unit > file or explicitly having systemd-tmpfiles-setup in After would solve > the problem. It wourld be preferable if there were a directive to tell systemd not to run systemd-tmpfiles-setup during the execution of console-setup. But ofcourse, if this is impossible, then removing DefaultDependencies=no is (maybe) also a solution. > Also, isn't Bug#818065 a duplicate of this? I doubt this can explain #818065. If the system uses systemd, then after `setupcon --save' has been run, the script setupcon is no longer required in order to setup the system. And the other scripts are short and simple and do not require temporary files. On the other hand, it seems likely to me that this bug is a duplicate of #819288. Anton Zinoviev
Bug#863630: console-setup.service doesn't affect tty consoles
forcemerge 857132 861454 863630 thanks On Mon, May 29, 2017 at 02:56:13PM +0200, Андрей Доценко wrote: > > I configured locale to russian language but after logging into tty* > terminal (Alt+Ctrl+F*) a font without support for my locale was applied. I suppose this is a duplicate of 857132 and 861454. Unfortunately nobody has been able to find the cause of this bug. Anton Zinoviev
Bug#861454: console-setup: Have to use setupcon at every booty
forcemerge 857132 861454
thanks
On Sat, Apr 29, 2017 at 03:35:08PM +0100, Brian Potkin wrote:
>
> root@cupsexp:~# cat /etc/console-setup/cached_setup_font.sh
>
> #!/bin/sh
>
> setfont '/etc/console-setup/cached_Lat15-TerminusBold22x11.psf.gz'
>
> if ls /dev/fb* >/dev/null 2>/dev/null; then
> for i in /dev/vcs[0-9]*; do
> { :
> setfont '/etc/console-setup/cached_Lat15-TerminusBold22x11.psf.gz'
> } < /dev/tty${i#/dev/vcs} > /dev/tty${i#/dev/vcs}
> done
> fi
>
> mkdir -p /run/console-setup
> > /run/console-setup/font-loaded
> for i in /dev/vcs[0-9]*; do
> { :
> printf '\033%%G'
> } < /dev/tty${i#/dev/vcs} > /dev/tty${i#/dev/vcs}
> done
This file looks ok.
> Apart from configuring the console font (and installing gpm and less)
> the system is as described earlier - a minimal installation without
> the standard utilities or a DE.
>
> Yes, it has systemd. However, I note that the one unstable machine I
> have with sysvinit does not exhibit this issue.
Then it seems this is a duplicate of the misterious bug #857132.
Anton Zinoviev
Bug#861454: console-setup: Have to use setupcon at every boot
On Sat, Apr 29, 2017 at 11:32:13AM +0100, Brian Potkin wrote: > > Debian (i386) was installed without tasksel's extra software using the > RC3 Stretch installer. 'dpkg-reconfigure console-setup' was run after > the first boot to give > > CODESET="Lat15" > FONTFACE="TerminusBold" > FONTSIZE="11x22" > > in /etc/default/console-setup. What about /etc/console-setup/cached_setup_font.sh? Something unusual about the kernel? Read-only file systems? With or without systemd? Anton Zinoviev
Bug#860582: Nokia N900 keyboard support in console
On Wed, Apr 19, 2017 at 12:24:17AM +0200, Enrico Menotti wrote: > > I am experimenting with Debian on a Nokia N900 (RX-51). I > debootstrapped a Jessie file system. When configuring the keyboard, I > found an issue. Namely, the symbols file uses a custom type called > PC_FN_LEVEL2; however, when setupcon is called, and from there ckbcomp > is invoked, this type is not recognised. Can you send: 1. A sample command line for ckbcomp. 2. The output ckbcomp generates. > My conclusion is that the problem is ckbcomp not reading the type file > indicated in the rule file, and that should be fixed, instead of > hardcoding the custom type into ckbcomp. I think it is impossible to base the behaviour of ckbcomp on the contents of the type file. The actual semantics of the types is undocumented and I think some details are unknown even to X developers. Fortunately, this is not necessary because the type files define only a few types and it is not difficult to hardcode the proper behaviour in ckbcomp. Anton Zinoviev
Bug#859458: [to...@wolfpuppy.org.uk: Bug#620041:]
- Forwarded message from Torne Wuff - Date: Thu, 6 Apr 2017 21:21:39 -0400 From: Torne Wuff To: 620...@bugs.debian.org Subject: Bug#620041: Being able to set the font during initramfs would be immensely useful on my HiDPI laptop, since the default console font renders the LUKS decryption prompt at a minuscule size I can barely read. - End forwarded message -
Bug#859458: console-setup: Setup font on initrd
rename 859458 Because of displays with very high dpi, not only the keyboard, but the font has to be configured early thanks Console packages have always configured the keyboard as early as possible in order to facilitate interaction during bad fsck. They have never tried (at least in Debian) to configure the font. But your argument is valid so I am renaming this bug accordingly. On Mon, Apr 03, 2017 at 09:12:21PM +0200, Jörg Sommer wrote: > > Can you add files like these to the package, please? I am considering this issue closed because there are already files like these in the package. :) See the option setupcon --setup-dir which is supposed to be used by initrd builders. At the moment Dracut uses this option, I don't know if there are other initrd builders in Debian which use it. But even with Dracut, the font will not be configured by initrd because console-setup does not try to do this. Which is unfortunate because earlier versions of console-setup included font configuration in initrd. Anton Zinoviev
Bug#859059: keyboard-configuration: many mac keymap in keyboard-configuration are faulty
On Thu, Mar 30, 2017 at 10:37:03PM +0200, raphael truc wrote: > > I understand it may not be easy. Maybe a solution would to be to have more > atomic keyboard description file that could be combined together, but it > may add some strange results, though. In my opinion, one solution is to move all mac specific layouts to the respective pc file. Then we can get rid of the files in macintosh_vndr. I don't see a problem if we allow mac users to use non-mac layouts and pc users to use mac layouts. By the way, did you select Mac keyboard model manually? As far as I can remember, by default, keyboard-configuration (hence the installer too) use pc keyboard model on Macs (and not macintosh, ibook, powerbook, macbook78 or macbook79). Are there some problems if you reconfigure keyboard-configuration to use pc keyboard model? In this case there will be no need to copy the altgr part of the pc keyboard to the macintosh one. Anton Zinoviev
Bug#859059: keyboard-configuration: many mac keymap in keyboard-configuration are faulty
forcemerge 535834 859059 thanks On Wed, Mar 29, 2017 at 10:28:42PM +0200, raphael wrote: > > I have a macbook pro with us keymap, I tried different layouts > available in keyboard-configuration to get accents, but ended with Can > not find "mac" in "macintosh_vndr/us". or Can not find "altgr-intl" in > "macintosh_vndr/us". and No Symbols named "altgr-intl" in the include > file "macintosh_vndr/us" or No Symbols named "mac" in the include file > "macintosh_vndr/us" > > I ended up copying the altgr part of the pc keyboard (found in > /usr/share/X11/xkb/symbols) to the macintosh one. I already had the > same kind of problem with mac french azerty keyboard. I think either > the /usr/share/X11/xkb/symbols/macintosh_vndr files should be > corrected or choices in the keyboard-configuration setup reduced to > what's really available (it took me quite a long time to understand > why I couldn't get the accents though everything looked fine). Yes, this is an unfortunate bug which is reported from time to time. Unfortunately, it can not be fixed because of https://bugs.freedesktop.org/show_bug.cgi?id=33670 Anton Zinoviev
Bug#857132: console-setup: additional info needed ?
On Sun, Mar 26, 2017 at 08:18:16PM +0200, Karsten Hilbert wrote: > > > Maybe this happened because cached_setup_font.sh was run while / was > > still read-only? > > Possibly. Suspecting that is why I chose / in the hope it'll > get mounted rw real early :-) I think for early logs /run/initramfs/ can be used. Also /usr/bin/logger might be able to help. Anton Zinoviev
Bug#857132: console-setup: additional info needed ?
On Fri, Mar 24, 2017 at 11:52:32AM +0100, Karsten Hilbert wrote: > I have done some more experimentation and it shows fairly > strange results. Thanks a lot! :) > Sometimes cached_setup_font.sh does not seem to get run AT > ALL -- the log file simply does not exist after a clean boot. Maybe this happened because cached_setup_font.sh was run while / was still read-only? On Sun, Mar 26, 2017 at 04:04:45PM +0200, Karsten Hilbert wrote: > > However, as witnessed by this log snippet from the most > recent boot, it does not ALWAYS run in parallel: Let us clear one point: no matter whether it runs in parallel or not -- the console is never configured properly? Or sometimes it is? Anton Zinoviev
Bug#857132: console-setup: additional info needed ?
On Thu, Mar 23, 2017 at 11:36:20AM +0100, Karsten Hilbert wrote: > > Directly after boot, during which no VT switch occurred, I > will see the login manager for KDE. When I now switch to the > first console and then ALT-RIGHT through my other consoles up > until vt6 they don't have a getty running just yet (they show > up as empty black screens). Actually, this is an indication that console-setup has already configured these consoles. As far as I know, there are only two components in a Debian system that open VTs -- getty and console-setup (and X for vt7). If you see a created console without getty, then this console exists only because console-setup has done something to it. If you would repeat this experiment on a system which didn't have console-setup installed, then ALT-RIGHT simply wouldn't work, it wouldn't switch to a console which didn't exist yet. And it would be impossible to see an empty console without getty running on it. Ofcourse, this doesn't explain why the configuration doesn't work -- because something overwrites it or because the configuration is performed too early, while the system is not prepared for it yet. Anton Zinoviev
Bug#857132: console-setup: additional info needed ?
On Thu, Mar 23, 2017 at 02:12:44PM -0300, Felipe Sateler wrote:
>
> As mentioned by Michael, this is not done by udev or systemd.
I think systemd runs getty which opens a console. Then the kernel
creates virtual consoles on demand.
> > From my tests it seems that the font used
> > for this initialization is the same as the font used on the current
> > console. Isn't it possible that sometimes this font is set only _after_
> > udev has started the script cached_setup_font.sh by the following rule
> >
> > ACTION=="add", SUBSYSTEM=="vtconsole", KERNEL=="vtcon*",
> > RUN+="/etc/console-setup/cached_setup_font.sh"
> >
> > however the font of the current console is read _before_ the script
> > cached_setup_font.sh has had a chance to configure the font?
>
> I don't know of any component that does that.
The kernel?
> However, I see the following in cached_setup_font:
>
> setfont '/etc/console-setup/cached_Lat15-Fixed16.psf.gz'
>
> if ls /dev/fb* >/dev/null 2>/dev/null; then
> for i in /dev/vcs[0-9]*; do
> { :
> setfont '/etc/console-setup/cached_Lat15-Fixed16.psf.gz'
> } < /dev/tty${i#/dev/vcs} > /dev/tty${i#/dev/vcs}
> done
> fi
>
> Might it be that /dev/fb* do not exist during boot, and thus the font
> is not loaded in all ttys?
If /dev/fb* doesn't exist then the graphics card is in hardware text
mode in which case there is one font on all ttys (due to hardware
limitation). If /dev/fb* is created afterwards, then udev will run
cached_setup_font again.
I don't know what is going to happen if:
1. udev runs cached_setup_font while there is no framebuffer
2. the script tests that there is no /dev/fb*
3. before the script completes its work /dev/fb* is created
In this case the rule of udev will trigger for a second time. However
since the script hasn't finished yet will then udev run a second copy of
it? If not, then this too, might create problems. On the other hand,
if udev always runs cached_setup_font again, do both copies run in
parallel (this shoudn't be a problem for cached_setup_font but it is
good to know if such possibility exists)?
Anton Zinoviev
Bug#857132: console-setup: additional info needed ?
On Thu, Mar 23, 2017 at 03:30:36PM +0100, Michael Biebl wrote: > > > > ...suppose udev creates a new console. Then it has to be initialized > > with some font, hasn't it? > > udev does not create any consoles. That's a misconception. Well, whoever does it... :) Anton Zinoviev
Bug#857132: console-setup: additional info needed ?
On Thu, Mar 23, 2017 at 02:37:48PM +0100, Michael Biebl wrote: > > In Debian, we don't enable the systemd-vconsole component [1]. This is good, but... > So there should be no console configuration happening from systemd's > side. ...suppose udev creates a new console. Then it has to be initialized with some font, hasn't it? From my tests it seems that the font used for this initialization is the same as the font used on the current console. Isn't it possible that sometimes this font is set only _after_ udev has started the script cached_setup_font.sh by the following rule ACTION=="add", SUBSYSTEM=="vtconsole", KERNEL=="vtcon*", RUN+="/etc/console-setup/cached_setup_font.sh" however the font of the current console is read _before_ the script cached_setup_font.sh has had a chance to configure the font? Anton Zinoviev
Bug#857132: console-setup: additional info needed ?
[I am sending a CC to pkg-systemd-maintain...@lists.alioth.debian.org] On Thu, Mar 23, 2017 at 11:07:14AM +0100, Sven Joachim wrote: > > There might be a third possibility which seems to happen on one of my > systems: the cached_setup_font.sh script does not work correctly when > run during boot by udev. Because this is what I am observing here, I > even added some debug messages to it to see if it is run at all (as > intended by /lib/udev/rules.d/90-console-setup.rules), and indeed it > does run but the font still remains unchanged. > > Manually running /etc/console-setup/cached_setup_font.sh (or > setupcon -f, for that matter) works fine, so I'm a bit at a loss here. Since systemd makes some configuration of the console, maybe the following scenario might explain what we observe: 1. systemd/udev creates a new console. 2. systemd begins the initialization of this console. 3. udev runs /etc/console-setup/cached_setup_font.sh by the following rule: ACTION=="add", SUBSYSTEM=="vtconsole", KERNEL=="vtcon*", RUN+="/etc/console-setup/cached_setup_font.sh" 4. Now cached_setup_font.sh and systemd execute in parallel. If cached_setup_font.sh wins, it will configure the console font first and then systemd will load another font. My tests of how systemd works show that it does the following: 1. It reads the curent font of the current console. 2. Then it does some things to the console(s) (configuration). 3. When a new console is created it loads on it the font read in 1. Therefore, it seems to me that if cached_setup_font.sh completes its job before 1. then everything should be ok. And if systemd completes its configuration before cached_setup_font.sh starts its work, then again everything will be ok. However if both work simultaneously things can go wrong. So, if this scenario is possible, a natural question is what can be done in order to make sure the scripts of console-setup do not execute in parallel with systemd while configuring the console. Anton Zinoviev
Bug#857132: console-setup: additional info needed ?
On Wed, Mar 22, 2017 at 05:56:04PM +0100, Karsten Hilbert wrote: > 2017-03-22 13:05:13.364493514 +0100 /etc/console-setup/cached_setup_font.sh > 2017-03-22 13:05:13.364493514 +0100 > /etc/console-setup/cached_setup_keyboard.sh > 2017-03-22 13:05:13.364493514 +0100 > /etc/console-setup/cached_setup_terminal.sh > 2017-03-22 12:54:59.368053266 +0100 > /etc/console-setup/cached_UTF-8_del.kmap.gz > 2017-03-22 12:53:10.459239057 +0100 /etc/default/console-setup > 2017-03-07 09:26:01.171789164 +0100 /etc/default/keyboard It seems something has changed /etc/default/console-setup. If this file is changed, then boot scripts of console-setup will recreate the cached_* files in /etc. Do you know what has caused this file to be changed? Its time seems to be only few minutes before the time of the reboot. I can't think of anything in the scripts of console-setup that can cause changes in this file. Something unrelated that might explain the bug is this: maybe this system runs X but doesn't have framebuffer on the console? In this case the problem is hardware related and the best solution is to use framebuffer. BTW, instead of `systemctl restart console-setup.service` you can use the command `setupcon`. Anton Zinoviev
Bug#857132: console-setup: additional info needed ?
On Wed, Mar 22, 2017 at 03:19:57PM +0100, Karsten Hilbert wrote:
> On Wed, Mar 22, 2017 at 03:02:28PM +0200, Anton Zinoviev wrote:
> >
> > 2. the bug still exists and each time the system boots, it recreates
> > these three files. In this case we have to find out the cause of this.
>
> The latter: currently, after each boot, I manually run
>
> systemctl restart console-setup.service
>
> which fixes the console problem for me until the next boot.
> That's why those files are from today.
This will update thethree files /etc/console-setup/cached_setup* if the
times of /etc/default/{keyboard,console-setup} are more recent. On the
other hand, times of the files in /etc/default/* are not supposed to
change.
> > And what about the files
> > /etc/default/{keyboard,console-setup} -- do their times change too?
>
> Likely because of the above, too.
Actualy these files should change only if console-setup is upgraded or
the admin runs dpkg-reconfigure.
> Feel free to ask for more information you may need.
Thanks. :) Well, can you report the state of the affairs before you run
systemctl restart console-setup.service
ls --full-time /etc/default/{console-setup,keyboard} /etc/console-setup/cached_*
Anton Zinoviev
Bug#857132: console-setup: additional info needed ?
On Wed, Mar 22, 2017 at 01:00:17PM +0100, Karsten Hilbert wrote:
>
> > ls -l /etc/console-setup/
>
> -rwxr-xr-x 1 root root 465 Mar 22 11:20 cached_setup_font.sh
> -rwxr-xr-x 1 root root 358 Mar 22 11:20 cached_setup_keyboard.sh
> -rwxr-xr-x 1 root root73 Mar 22 11:20 cached_setup_terminal.sh
Hm, the times of these three are too recent. I can see two possibilities:
1. either the bug no longer exists in this system, in which case we
have to find out what caused these files to be created, or
2. the bug still exists and each time the system boots, it recreates
these three files. In this case we have to find out the cause of this.
Can you check if the times of these three files change each time the
system boots? And what about the files
/etc/default/{keyboard,console-setup} -- do their times change too?
> > cat /etc/console-setup/cached_setup_font.sh
> > cat /etc/console-setup/cached_setup_terminal.sh
These look ok to me. I was kind of hoping to find something wrong here...
> > /run/console-setup/font-loaded
>
> (the line starting with ">" strikes me as odd - should it not
> be on the "mkdir -p" line ?)
This line creates an empty file /run/console-setup/font-loaded which is
used by /lib/udev/rules.d/90-console-setup.rules to make sure the script
/etc/console-setup/cached_setup_terminal.sh is not run before
/etc/console-setup/cached_setup_font.sh.
> > cat /etc/default/console-setup
> > cat /etc/default/keyboard
These look ok as well...
Anton Zinoviev
Bug#857132: console-setup: additional info needed ?
On Wed, Mar 22, 2017 at 11:29:48AM +0100, Karsten Hilbert wrote: > > is there anything I can do/provide to help get this resolved ? Yes, thanks! The output of the following commands: ls -l /etc/console-setup/ cat /etc/console-setup/cached_setup_font.sh cat /etc/console-setup/cached_setup_terminal.sh cat /etc/default/console-setup cat /etc/default/keyboard Anton Zinoviev
Bug#818065: live-config / console-setup issue
On Fri, Mar 17, 2017 at 08:17:42AM +0100, Jörn Heissler wrote: > > It appears to me that "Set console font and keymap" is done before > live-config regenerates the files. I think this explains the bug. Anton Zinoviev
Bug#818065: live-config / console-setup issue
On Thu, Mar 16, 2017 at 04:10:35PM +0100, Jörn Heissler wrote: > > I had the same issue. > Running a live-build image, nothing worked to setup the keyboard layout. > > I found out that my image contained /etc/console-setup/cached_* files. > What really helped was adding a hook in live-build to remove those > files, before the image was built. Can you send the output of ls --full-time /etc/console-setup/cached* /etc/default/console-setup /etc/default/keyboard If the times of the cached files are more recent than the times of the configuration files, then console-setup won't look at the configuration files at all. I don't know how live-config works but isn't the script components/0150-keyboard-configuration (I am looking at the source package of live-config) supposed to edit /etc/default/keyboard? And if this is so, then how it is possible for the cached files to be more recent than /etc/default/keyboard? Anton Zinoviev
Bug#857132: console-setup (again) stopped to apply font at startup
On Wed, Mar 08, 2017 at 12:02:45PM +0100, Karsten Hilbert wrote: > > console-setup just stopped to apply font settings during startup. Does this system has some read-only file systems? Anton Zinoviev
Bug#852929: scalable-cyrfonts: FTBFS: LaTeX requires e-TeX.
On Sun, Feb 26, 2017 at 07:54:28PM +0100, Sascha Steinbiss wrote: > > Switching to ‘luatex' instead of ‘tex’ fixed the issue for me. Please > see attached patch. However, I would be happy if someone could take a > second look. I don’t usually write Cyrillic ;) Thanks. I am uploading the package now. :) Anton Zinoviev
Bug#817232: Stil present in 1.158
tags 817232 + patch thanks On Fri, Jan 20, 2017 at 02:49:42AM -0500, sacrificial-spam-addr...@sciencehorizons.net wrote: > > Either add -f to the update-rc.d invocation, or try something more like: > > #!/bin/sh > > set -e > > for file in keyboard-setup console-setup; do > if [ -x /etc/init.d/$file ]; then > dpkg-maintscript-helper rm_conffile /etc/init.d/$file 1.138~ -- "$@" > update-rc.d $file remove >/dev/null > fi > done Thanks. Anton Zinoviev
Bug#818065: console-setup is not read correctly at boottime and must be started manually
On Tue, Jan 03, 2017 at 11:27:26PM +, Kristian Klausen wrote: > > So I looked a bit on the code, and I think the issue is caused by line > 11 in console-setup (*), the line make so console-setup.sh does > nothing at first run after boot, and as console-setup.service is only > run once per boot, setupcon (which configure keyboard layout) is never > run. Yes, in this case setupcon is never run from console-setup.sh. However there is no need to use setupcon in order to configure the font because this is done by /lib/udev/rules.d/90-console-setup.rules and the keyboard is configured by /lib/systemd/system/keyboard-setup.service. > As it is a live-image, every boot is "first boot" as Anton said could > give issue. How big is is this image? Will it be possible to send it to me so I can test? Anton Zinoviev
Bug#844579: console-setup: CyrAsia font missing Kazakh letter
On Tue, Nov 22, 2016 at 06:44:15AM +0500, Baurzhan Muftakhidinov wrote: > > Fonts/CyrAsia-Fixed13.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Fixed13.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Fixed14.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Fixed14.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Fixed14.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Fixed14.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Fixed15.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Fixed15.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Fixed16.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Fixed16.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Fixed16.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Fixed16.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Fixed18.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Fixed18.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Terminus14.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Terminus14.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Terminus16.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-Terminus16.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-TerminusBold14.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-TerminusBold14.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-TerminusBold16.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-TerminusBold16.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-TerminusBoldVGA14.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-TerminusBoldVGA14.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-TerminusBoldVGA16.raw.log:WARNING: U+2116: no glyph defined > Fonts/CyrAsia-TerminusBoldVGA16.raw.log:WARNING: U+2116: no glyph defined Are these all messages? So the numero sign is missing only in CyrAsia and in no other fontset? Also, the numero sign is missing in CyrAsia-Terminus16.raw.log and not in CyrAsia-Terminus16.log (the first font is for BSD, the second for Linux)? Can you try building the package using clean sources, without any changes, and see if this helps. Anton Zinoviev
Bug#844579: console-setup: CyrAsia font missing Kazakh letter
On Mon, Nov 21, 2016 at 08:20:52PM +0500, Baurzhan Muftakhidinov wrote: > > Should I prepare a patch for it? It is only 3 lines change. I suppose you shouldn't. > >> WARNING: U+2116: no glyph defined Hmm, now I realise that this looks very suspicious because the numero sign is defined in most (all?) source fonts. I don't get such a message when I build the package. What does the following command output: grep '2116: no glyph defined' Fonts/*.log Anton Zinoviev
Bug#844579: console-setup: CyrAsia font missing Kazakh letter
On Sun, Nov 20, 2016 at 12:14:33AM +0100, Cyril Brulebois wrote: > > I'm not sure what's involved to add support for those. Maybe it's > sufficient to add two lines with the codepoint to the file you > mentioned? Yes, it is sufficient, provided there is enough space in the font (only 256 glyphs can be included). On Mon, Nov 21, 2016 at 10:32:46AM +0500, Baurzhan Muftakhidinov wrote: > > >> Recently I loaded CyrAsia font in console, and have noticed > >> that it misses one Kazakh letter: > >> > >> Ұ U+04B0 Cyrillic Capital Letter Straight U with Stroke > >> ұ U+04B1 Cyrillic Small Letter Straight U with Stroke > > Also I see that currency symbols of some countries are added, > so I would like to add Kazakh tenge as well, its code is > > ₸ - Unicode Character 'TENGE SIGN' (U+20B8) This is how you can check that there haven't been problems with space in the fonts (after you compile the package): grep 'no space in the font' Fonts/*.log If you see no such warnings, then everything is ok. I've tried this myself and it seems there is enough space in the fonts for these three additional symbols. So, go ahead and add them! > While we are at it, I wonder where these glyphs are taken from? > Because in build log I see that № symbol is missing from the resulting font. > In log file it says > > WARNING: U+2116: no glyph defined The glyphs come from the fonts in the directory Fonts/bdf. This particular warning means that no suitable source font includes this glyph, so it has been impossible to support it in the generated console font. Anton Zinoviev
Bug#843982: xfonts-terminus: Can't load "terminus-12" anymore
On Mon, Nov 14, 2016 at 03:09:33PM -0200, Nelson A. de Oliveira wrote: > > > 3. Do you have a file /usr/share/fonts/X11/misc/fonts.alias? > > > > 4. Does this file have a line starting with terminus-12? > > And yes too: This is puzzling. :( > Is there anything else that I can verify or test, please? What about xlsfonts | grep terminus-12 Anton Zinoviev
Bug#843982: xfonts-terminus: Can't load "terminus-12" anymore
On Fri, Nov 11, 2016 at 11:33:38AM -0200, Nelson A. de Oliveira wrote: > > Until the last version (4.39-1) I used to call urxvt like this: > > = > /usr/bin/urxvtc -bg black -fg lightgray +sb -sl 65535 -fn terminus-12 > = > > But now I get: > > = > $ /usr/bin/urxvtc -bg black -fg lightgray +sb -sl 65535 -fn terminus-12 > urxvt: unable to load base fontset, please specify a valid one using -fn, > aborting. > = > > Did I miss something that was not explained in the changelog? No, this shouldn't happen. Please check the following things: 1. Do you have a directory /etc/X11/fonts/misc/ with a file xfonts-terminus.alias? 2. Does this file contain a line starting with terminus-12? 3. Do you have a file /usr/share/fonts/X11/misc/fonts.alias? 4. Does this file have a line starting with terminus-12? Anton Zinoviev
Bug#842324: console-setup: During apt-get dist-upgrade stage, console-setup did not finish cleanly under ja_JP.UTF-8 locale.
On Wed, Nov 02, 2016 at 02:44:13PM -0400, Sandro Tosi wrote: > > in particular if the error in is `iconv` that program is part of > libc-bin so this bug should be reassigned to that pkg. Yes, the bug belongs to libc-bin. Unfortunately, I was unable to reproduce the bug on my computer, so I won't be able to provide any useful data to the libc-bin maintainers. Therefore, I suppose it won't do any good if I reassign the bug (but I can be wrong). > I'll let the console-setup maint decide what to do of course, just > posting my quick check on this RC bug. I've commited a change that will make console-setup use untranslated keyboard names in case of failed iconv. This should fix the bug in console-setup. Of course, when we have more data or something reproducible we can submit a bug against libc-bin. Anton Zinoviev
Bug#838310: keyboard-configuration: user configuration lost + error message from setupcon
On Thu, Sep 22, 2016 at 06:31:17PM +0200, Vincent Lefevre wrote: > > I suppose that this is OK if /usr/share/console-setup/kbdnames-maker > is expected to be run with /usr/share/console-setup as the current > working directory. Otherwise, I'm wondering... What is the goal of > this script here? http://bugs.debian.org/420914 Anton Zinoviev
Bug#838310: keyboard-configuration: user configuration lost + error message from setupcon
tags 838310 +help thanks On Thu, Sep 22, 2016 at 02:17:54PM +0200, Sven Joachim wrote: > > I'm pretty sure it is. The list of keyboard models is generated by > running "./kbdnames-maker KeyboardNames.pl" from the Keyboard/ > directory, and currently this command does not print anything. I > tracked the problem down to the removal of the current directory from > @INC in perl, running "perl -I. kbdnames-maker KeyboardNames.pl" gives > the long list of keyboard models again. I am adding to this bug a 'help' tag because the bug is grave and at the moment I don't have updated Debian machine so I can not debug. Conceivably, the fix will be trivial. I don't know if the following will fix the bug and if this is the right thing to do, but it seems simple to change the first line #!/usr/bin/perl of Keyboard/kbdcompiler and Keyboard/kbdnames-maker to #!/usr/bin/perl -I. Anton Zinoviev
Bug#838310: keyboard-configuration: user configuration lost + error message from setupcon
On Mon, Sep 19, 2016 at 07:31:12PM +0200, Vincent Lefevre wrote: > > Just after the upgrade of keyboard-configuration from 1.148 to 1.149, > I could see that my previous configuration was lost. More precisely, > config.dat changed in the following way: When /etc/default/keyboard is ok, config.dat is ignored by console-setup (default values are set before asking questions). > and /etc/default/keyboard changed in the following way: If this file becomes corrupted during upgrade, then this is certainly a bad thing. > -XKBMODEL="pc105" > +XKBMODEL="" > XKBLAYOUT="gb" > XKBVARIANT="" > XKBOPTIONS="" This doesn't look as a file created by console-setup. Because of the missing XKBMODEL, it looks like a file created by systemd-localed.service. Would you experiment with the command # localectl set-keymap and # localectl set-x11-keymap ... and see if it corrupts /etc/default/keyboard. > I don't know the possible consequences, though. The > /usr/share/doc/keyboard-configuration/changelog.gz file just says: > > console-setup (1.149) unstable; urgency=medium > > [ Updated translations ] > * Danish (da.po) by Joe Hansen If I am right that the file was corrupted by systemd-localed, then /etc/default/keyboard must have been corrupted after the upgrade of console-setup. If this file was corrupted before the upgrade, then console-setup would have repaired it. > Note: I have > > -rw-r--r-- 1 root root 145 2016-09-19 19:03:19 /etc/default/keyboard > > Thus this file was modified when keyboard-configuration was upgraded > (and before this upgrade of the Linux kernel and the nvidia packages). Do you know what other packages were upgraded after console-setup and before the Linux kernel and nvidia? > This error message is just a consequence of this bug. Yes. The error message was added in version 1.138 after I became aware that other packages modify the configuration file of console-setup. Anton Zinoviev
Bug#777304: console-cyrillic: please make the build reproducible
On Tue, Aug 16, 2016 at 07:53:49PM +0100, Chris Lamb wrote: > > I'm disappointed to hear that you can't find the time to apply it. This > is only a wishlist bug however, so I don't feel it warrants an NMU at > this point. I am used to do all my work for Debian in a batch mode. When I work for Debian I work full time. It is not exactly that I can't find the time now, it is more like I don't want to find the time before there are enough Debian tasks waiting in my todo list. Anyway, I suppose it might be possible to "find the time" during the next week. :) Anton Zinoviev
Bug#777304: console-cyrillic: please make the build reproducible
On Sun, Aug 14, 2016 at 08:12:21PM +0100, Chris Lamb wrote: > > There hasn't seem to be any update on this bug in 554 days, That's because I haven't updated this package since 2009-11-06. Maybe we don't need to build this package at all --- either in a reproducible or in a non-reproducible way. ;-) This was of course a joke. There are some things about this package that have to be done, for example the scripts in /etc/init.d are no longer necessary. Years ago I planned to make the changes about these scripts after analogous changes in console-data, but the required changes in console-data turned out to be difficult. > Would you consider applying this patch and uploading? Right now I can not tell when exactly I will be able to build and upload the package. If you want, feel free to make a NMU. Anton Zinoviev
Bug#833053: Syntax error in the script that setupcon outputs
On Tue, Aug 02, 2016 at 10:43:45PM +0200, Philip Hands wrote: > It looks like there are a couple of other instances of the potentially > empty braces problem in this script, so we could address them at the > same time just in case. I agree. Even if the current script didn't have more empty braces problems, it would be safer to protect against bugs caused by future changes. > How about just adding : to each brace, as in the following patch. I like this solution. Anton Zinoviev
Bug#796604: Bumping severity of missing rcS systemd units to RC
severity 796604 important thanks On Thu, Jul 07, 2016 at 04:05:30PM +0200, Martin Pitt wrote: > severity 796604 grave > > Then your package will most likely stop working properly under > systemd. Because console-setup is a standard for Debian now, the main function of the package console-cyrillic in recent Debian releases is to provide a collection of Cyrillic console fonts to be used with console-setup. Therefore, grave severity is quite inappropriate for bug #796604. Anton Zinoviev
Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))
On Wed, May 18, 2016 at 01:33:06PM -0300, Felipe Sateler wrote: > > Ok. I see that the rules file appears to invoke the scripts in /etc > directly. Is this intended Yes. The keyboard is configured by /lib/console-setup/keyboard-setup.sh and the font by the scripts in /etc. Notice that /lib/console-setup/console-setup.sh does not run the scripts in /etc at all. If necessary it runs setupcon. > (IOW, shouldn't they invoke the wrappers at /lib/console-setup)? Although setupcon is an universal and reliable tool, this cames at a price --- it is slow. Many people have complained that console-setup slows down the boot and thats the only reason I decided to use scripts in /etc instead of setupcon. By the way, the only thing /lib/console-setup/console-setup.sh does in addition to the scripts in /etc is to rebuild the scripts in /etc if necessary. And it is necessary to rebuild these scripts only if the sysadmin modifies the console configuration by hand and doesn't run `setupcon --save-only` afterwards. In this case the wrapper will rebuild the scripts in /etc during the first reboot. > But upstream systemd and udev have pushed for mounting /usr in the > initramfs for a long time, Is there a place where one can learn about such things? > Note that because it has no WantedBy line, this service will not be > actually executed during boot. If the service should run as part of > normal system boot, it should have either WantedBy=sysinit.target or > WantedBy=multi-user.target. > Services WantedBy=sysinit.target will be pulled in both single user > and multi user boots. Services in multi-user.target will only be > pulled in multi user boots. OK, then it has to be WantedBy=multi-user.target. Rebuilding the scripts in /etc is not something we want in single user mode. Anton Zinoviev
Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))
On Wed, May 11, 2016 at 01:27:52PM -0300, Felipe Sateler wrote: > > Sure. Also, feel free to point me to what you have, and I can comment > on that as well. I've pushed the changes I made in git. The new version of keyboard-setup.service is more or less unchanged: [Unit] Description=Set the console keyboard layout DefaultDependencies=no Before=local-fs-pre.target Wants=local-fs-pre.target ConditionPathExists=/bin/setupcon [Service] Type=oneshot ExecStart=/lib/console-setup/keyboard-setup.sh RemainAfterExit=yes [Install] WantedBy=sysinit.target As for console-setup.service, this script doesn't actually configure the console (that is on Linux; on FreeBSD it does). Therefore, I removed the instructions Before=system-getty.slice and WantedBy=sysinit.target. The actual configuration of the console is accomplished by udev (see /lib/udev/rules.d/90-console-setup.rules). > > What about the following additional instruction: RequiresMountsFor=/usr > > It would be redundant, as /usr is guaranteed to be mounted by the > initramfs (for stretch, both dracut and initramfs-tools do so). It > would cause no harm, though. > > Split-/usr without an initramfs that mounts /usr is not supported and > is likely to break. I suppose this is so only on Debian? In order to support other nonstandard/future distributions I added this instruction. So, now console-setup.service looks in this way: [Unit] Description=Set console font and keymap DefaultDependencies=no After=console-screen.service kbd.service local-fs.target RequiresMountsFor=/usr ConditionPathExists=/bin/setupcon [Service] Type=oneshot ExecStart=/lib/console-setup/console-setup.sh RemainAfterExit=yes Anton Zinoviev
Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))
On Wed, Mar 16, 2016 at 03:22:42PM -0300, Felipe Sateler wrote: > > > On Sun, Mar 06, 2016 at 02:51:34PM -0300, Felipe Sateler wrote: > >> > >> I meant the logic to determine if setupcon or the cached scripts > >> should be run. If in the future that part is changed (eg, the names > >> are changed, or more scripts are generated), there is no guarantee > >> the change will reach users, since they may have modified the init > >> script. Right now I am preparing some changes in console-setup and one of them is to implement your suggestion to move the logic out of the init scripts. > Would you be OK, until further development comes along, to use a > wrapper unit like this: And while I am reviewing your changes, I find (as expected) that there are things I don't understand. So before I make changes and introduce bugs, I decided to ask. > [Install] > WantedBy=sysinit.target What is the purpose of this instruction? Wouldn't it be possible to remove it at least for console-setup.service? Also, inside console-setup.service I find these: > After=console-screen.service kbd.service local-fs.target What about the following additional instruction: RequiresMountsFor=/usr > Before=system-getty.slice Nothing really serious is going to happen if this script is executed after getty. Wouldn't it be better to remove this instruction? Anton Zinoviev
Bug#822946: Don't set console setting over logout/login
On Tue, May 03, 2016 at 09:17:03AM +0100, Klaus Ethgen wrote: > > > I suppose now > > > > printf '\033%%G' > > > > is the default in the kernel, that is UTF-8, > > Well, that is not true. I have that bug as well on systems that uses > standard debian kernel as also on systems where I have a custom kernel > with "CONFIG_NLS_DEFAULT="iso8859-1"". This is because mingetty overrides the default of the kernel. > > In order to test this try adding the option --noclear to all > > instances of mingetty. > > Yes, that keeps the setting. Good. Now we know the culprit. > > If the option --noclear fixes the problem, then there will be two things > > we can do. First, maybe file a bug against mingetty (I don't know if > > this should be considered a bug or a feature of mingetty...). > > Well, reallocating the tty is as it should be from my perspective. So I > wouldn't see that a bug. Reallocating the tty is not a bug, but leaving it unconfigured is. > > ACTION=="add", SUBSYSTEM=="vc", KERNEL=="vcs[1-9]|vcs[1-9][0-9]", > > TEST=="/run/console-setup/font-loaded", > > RUN+="/etc/console-setup/cached_setup_terminal.sh %k" > > > > In theory this should reconfigure a tty each time it is allocated. > > I will give that a try. Will give you feedback. At least with systemd this works. I wonder what makes mingetty different. Anton Zinoviev
Bug#822946: Don't set console setting over logout/login
On Mon, May 02, 2016 at 10:39:49PM +0100, Klaus Ethgen wrote: > > > > printf '\033%%@' > > > > Does this reconfigure the console to use ISO-8859-1? > > I already tried that and yes, it works. (or print '\033%@') So when I > read that correct (The information about % is very rar) that sets > the default settings. Shouldn't that be the "default" anyway? I suppose now printf '\033%%G' is the default in the kernel, that is UTF-8, > I think I have configured Terminus font on all systems. But I have to > crosscheck. My question was in order to see whether console-setup sets the font as expected or not. >~> grep 'tty[0-9]$' /etc/inittab >1:45:respawn:/sbin/mingetty --noclear tty1 >2:23:respawn:/sbin/mingetty tty2 >3:23:respawn:/sbin/mingetty tty3 >4:23:respawn:/sbin/mingetty tty4 >5:23:respawn:/sbin/mingetty tty5 >6:23:respawn:/sbin/mingetty tty6 > > I use mingetty on all systems. And console 1 is only allowed for login > in init level 4 and 5 and never clears as I need to have the boot > messages. Hmm, I've never used mingetty, but isn't it possible that it shows the same behaviour as systemd, that is it disallocates the tty after each logout? In order to test this try adding the option --noclear to all instances of mingetty. If the option --noclear fixes the problem, then there will be two things we can do. First, maybe file a bug against mingetty (I don't know if this should be considered a bug or a feature of mingetty...). And second, try to do something about the problem in console-setup. In the file /lib/udev/rules.d/90-console-setup.rules console-setup installs the following rule: ACTION=="add", SUBSYSTEM=="vc", KERNEL=="vcs[1-9]|vcs[1-9][0-9]", TEST=="/run/console-setup/font-loaded", RUN+="/etc/console-setup/cached_setup_terminal.sh %k" In theory this should reconfigure a tty each time it is allocated. Anton Zinoviev
Bug#822946: Don't set console setting over logout/login
On Fri, Apr 29, 2016 at 10:15:26AM +0100, Klaus Ethgen wrote: > > When using console-setup to setup proper console char set (latin1), it > does not preserve it over logout/login or reboot. After logout, the > console is again set to UTF-8. Console-setup supports non-UTF-8 encodings, which means we have to find out the source of the problem. > When logging in as root and do dpkg-reconfigure console-setup with all > settings as before (or running cached_setup_font.sh), Just to be sure that the only problem is with the encoding try this. Instead of dpkg-reconfigure console-setup or running cached_setup_font.sh execute the following command on the console: printf '\033%%@' Does this reconfigure the console to use ISO-8859-1? Does the font on the console look like Terminus or it is like the default VGA font? > it works for all presently consoles (until logout). Are you saying that even if you configure the console to use ISO-8859-1 and then logout and login (without a reboot) the console is wrong again? I suppose I don't have to ask this, but just in any case: is the locale set properly in /etc/default/locale? Systemd is another suspect because it has the habit to disallocate the console after each logout and then to allocate it again. It seems, however, that your system doesn't use systemd. But again, let me ask, just for any case: does your system use the traditional /etc/inittab and is getty run using it? If yes, then does this file contain a line like this one: 1:2345:respawn:/sbin/getty 38400 tty1 Anton Zinoviev
Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)
On Fri, Apr 01, 2016 at 08:55:31PM -0300, Felipe Sateler wrote: > > I have uploaded a new version. I have not yet, however, secured commit > rights to d-i git repository. If you want to pull the changes before I > get the access, you can pull the signed tag from my fork: I noticed that you put the files *.service in the package console-setup-freebsd and (as far as I can tell) this doesn't seem an oversight but rather done by intention. Why? I think that the non-Linux ports of Debian do not use systemd or am I missing something? Anton Zinoviev
Bug#819288: /tmp is used before /tmp being mounted
On Wed, Apr 13, 2016 at 11:52:44AM +0200, François Scala wrote: > > While working on a Debian installation base on a ZFS root filesystem > with LUKS encryption I've encountered a problem with keyboard-setup > init script that create file in /tmp before /tmp being mounted. Yes, keyboard-setup can attempt to create files in /tmp but it can do its job even when it is impossible to create a file there (because some other locations will be tried instead of /tmp). There is some chance, however, that after keyboard-setup creates a temporary file in /tmp, /tmp gets mounted and the temporary file will no longer be accessible. Fortunately, this is not a big problem, because temporary files will be used only if not everything necessary is prepared in /etc/console-setup. The other init script of console-setup -- /etc/init/console-setup(.sh) -- has the job to put in /etc/console-setup the necessary files. This means that if you reboot the system, no files in /etc will be used. I suppose I have to document in the man pages of /etc/default/keyboard and /etc/default/console-setup that the sysadmin has to run setupcon --save-only if he edits some of these files and /tmp is in a separate file system. > Here is the process tree > > |-keyboard-setup,1334 /etc/init.d/keyboard-setup start > | `-setupcon,1336 /bin/setupcon -k > | `-ckbcomp,1387 /usr/bin/ckbcomp -backspace del -model pc105 us This information confirms that not all necessary files were present in /etc/console-setup. Normally setupcon does not run ckbcomp and in the recent versions of console-setup (>=1.138) the keyboard-setup.sh init script does not run setupcon. Anton Zinoviev
Bug#820213: console-setup: The non breaking space has a bad symbol with fr_FR charset
On Thu, Apr 07, 2016 at 01:06:10AM +0300, Anton Zinoviev wrote: > > Unfortunately, at the moment I have no idea what might have caused this > strange behaviour. Ah, it just occured to me that maybe you have observed the following: 1. fsck displays its messages with correct non-break space. 2. A second later console-setup changes the font and only then the non-break space is replaced with "strange" symbol. Am I right? If so, then I think I understand the cause of the problem and the possible fixes. Anton Zinoviev
Bug#820213: console-setup: The non breaking space has a bad symbol with fr_FR charset
On Wed, Apr 06, 2016 at 07:02:03PM +0200, rpnpif wrote: > > In fr_FR.UTF-8 charset, Lat15 for console-setup or also guest charset, > console-setup change the non-breaking space in the boot message of > systemd to garbage character. Unfortunately, at the moment I have no idea what might have caused this strange behaviour. Moreover, I am unable to reproduce it. I booted my system with French locale and fsck displayed the non-break space correctly. Could you check the following two things. First, is everything correct after the system has booted? Try for example on the text console as root the following commands: dd if=/dev/zero of=/tmp/test.hdi count=10 mkfs.ext4 /tmp/test.hdi fsck.ext4 /tmp/test.hdi Second, when do the following messages occur? > /dev/sda2€: propre ... > /dev/sda3€: propre ... Before the framebuffer is activated (big letters) or afterwards (small letters)? Can you observe the exact time when console-setup modifies the font (not the size of the letters but their shape)? > Whatever the font, a non-breaking space should be displayed in fr_FR > before this colon or at least a simple space. The non-breaking space > is better. On the console 'non-breaking space' = 'space'. Anton Zinoviev
Bug#819288: console-setup-linux: keyboard-setup.sh init script (actually, the cached scripts) rely on /tmp, which may not be mounted at early boot
On Sun, Mar 27, 2016 at 12:06:39PM -0300, Felipe Sateler wrote: > > But, maybe setupcon should force remove the cached script if it > contains references to /tmp (or better yet, the script does not match > /etc/console-setup/cached_*.map.gz) Yes, something has to be done about this. Anton Zinoviev
Bug#819288: console-setup-linux: keyboard-setup.sh init script (actually, the cached scripts) rely on /tmp, which may not be mounted at early boot
On Sat, Mar 26, 2016 at 12:53:45AM -0300, Felipe Sateler wrote: > > The cached scripts rely on the compiled keyboard maps to be present in > /tmp (presumably by having being saved by setupcon -k). Hm, this is totaly unexpected. Normally the cached scripts rely on compiled keyboard maps in /etc. The only reason I can see the cached scripts rely on maps in /tmp is that /etc/ was read-only when `setupcon --save-only` was executed by /etc/init.d/console-setup.sh or `dpkg-reconfigure`. The cached scripts should never rely on files in /tmp and this is a bug I will have to fix somehow. However, an important question we have to investigate here is this: why in your system the cached scripts rely on files in /tmp. Anton Zinoviev
Bug#796603: OT: console-setup (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))
On Sun, Mar 20, 2016 at 11:46:30AM +0300, Adam Wilson wrote: > > Is console-setup the thing which initialises the console fonts and Yes. > resolution? No. > Is its slowness the reason why, on boot, it takes a few > seconds for the text-mode screen to transition to a virtual terminal, No. > Why is console-setup so slow? It is not. :) Anton Zinoviev
Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)
On Wed, Mar 16, 2016 at 03:22:42PM -0300, Felipe Sateler wrote: > > Yet another one would be to have setupcon itself detect the existence > of the cached scripts. The only reason there are cached scripts is that people are complaining that console-setup is slow at boot. The cached scripts contain the mininum configuration sufficient to configure the console. If we run setupcon, we don't need cached scripts. > Would you be OK, until further development comes along, to use a > wrapper unit like this: Yes and thank you! > I plan to do a NMU fixing this bug via a unit like the above, please > tell me if you want to address this in some other way. However, I don't think it is appropriate to do a NMU with such changes. Instead you should make a regular upload of the package. I don't know whether you have commit rights in the repository of Debian installer (where the sources of console-setup are), or not, but in any case I think you can obtain such rights in no time. Anton Zinoviev
Bug#818065: console-setup is not read correctly at boottime and must be started manually
On Sun, Mar 13, 2016 at 10:08:23AM +0100, Thomas Schmidt wrote: > >* What led up to the situation? > > Not reproduceable There is a slight possibility for the current console-setup to leave the console unconfigured during the first boot. Have you observed misconfigured console more than once? Anton Zinoviev
Bug#818065: #818065 - console-setup does not work correctly
On Sun, Mar 13, 2016 at 01:23:20PM +0100, Thilo Six wrote: > > -rw-r--r-- 1 root root 4,6K 2016-03-12 17:23 > /etc/console-setup/cached_UTF-8_del.kmap.gz > > But lately i found a file with *600* in there. Is this something reproducible? Did you observe problems with console configuration when there was a file with *600*? > According to my own tests it is save to 'rm /etc/console-setup/*.gz' It is safe to 'rm /etc/console-setup/cached_*'. These files can be recreated by 'setupcon --save-only'. Anton Zinoviev
Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)
Thank you for the useful explanations in your message! On Sun, Mar 06, 2016 at 02:51:34PM -0300, Felipe Sateler wrote: > > I meant the logic to determine if setupcon or the cached scripts should be > run. If in the future that part is changed (eg, the names are changed, or > more scripts are generated), there is no guarantee the change will reach > users, since they may have modified the init script. I see... Yes, you are correct about this. > However, this is not exactly the same: if the cached script fails, then > setupcon would not be run. I was just pondering on the different options I had. One of them was to change the cached script so that it runs setupcon when necessary. > Also, I would advise against having different logic in the systemd services > than in the init scripts: the maintenance burden is higher, and requires a > higher initial understanding from people not already familiar with the > package. I agree in 100% with this. Anton Zinoviev
Bug#804988: keyboard-configuration: Please drop dependency on initscripts package
On Fri, Mar 04, 2016 at 11:23:52AM -0300, Felipe Sateler wrote: > > AFAICT, initscripts itself is only needed to ensure the Required-Start > dependency of keyboard-setup.sh. This problem is solved by replacing > the dependency with init-system-helpers (>= 1.29~), which will do the > right thing when initscripts is not installed (ie, not abort the > installation). Another problem is the $remote_fs dependency of console-setup.sh. See #621077. Anton Zinoviev
Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)
On Fri, Mar 04, 2016 at 03:08:39PM -0300, Felipe Sateler wrote: > > > Unfortunately, I will not be able to maintain this file or to update it > > in accordance with future changes in systemd. So I suppose that unless > > you or somebody else volunteers to maintain it, it will be better to > > continue without it. > > As long as the initscript does simple things, it should require very > little maintainance. While I can't commit to maintain it (I am no > expert in console matters), feel free to CC pkg-systemd-maintainers or > myself if you ever receive a bug about this. The reason I hesitate is that I am not a "normal" maintainer of console-setup. While I have enough time for development related to console-setup, my limitations force me to allocate this time in batches with relatively large periods between them. In fact, it won't be incorrect to say that most of the time other people take care of this package (one can easily observe this in the changelog). > >> Before=local-fs-pre.target > >> Wants=local-fs-pre.target > > > > What is the meaning of these two? > > This ensures it is run before systemd attempts to fsck and mount any > local filesystems. It is therefore a relatively appropriate > replacement for the checkroot dependency. What does 'Wants' do? Is this some kind of optimization? > There does not appear to be a keymap init script: > > These are created by the kernel when devtmpfs is mounted, and systemd > mounts /dev before starting any units, so they should be available, > yes. This is good. It seems we don't need 'After'. > > One novelty in version 1.138 is that it is unnecessary to run setupcon > > in order to configure the console. It is OK to configure the keyboard > > in this way, but this usually will be slower than what the script > > keyboard-setup.sh does -- instead of setupcon it runs > > /etc/console-setup/cached_setup_keyboard.sh and reverts to using > > setupcon only when this script doesn't exist of fails. > > IMO, the init script should be as dumb as possible, as it is a > conffile. Therefore all program logic should move outside the script > and into a helper script that lives in /lib. This way, improvements > are guaranteed to be shipped to users. The script /etc/console-setup/cached_setup_keyboard.sh is not a configuration file and the user is not supposed to edit it. Since it is autogenerated, there is no problem to ship improvements to the users. (Under FHS this script would have to go in /var rather than in /etc, however, we need it while /var is not yet mounted. Years ago, nobody at debian-devel could find a solution to this problem, so now console-setup violates this aspect of FHS.) > The resulting unit would be: > > ConditionPathExists=/bin/setupcon Is there a possibility to use something like 'ConditionPathDoesntExist? If yes, then we can use two units like these: Unit 1: ConditionPathExists=/etc/console-setup/cached_setup_keyboard.sh ExecStart=/etc/console-setup/cached_setup_keyboard.sh Unit 2: ConditionPathDoesntExist=/etc/console-setup/cached_setup_keyboard.sh ConditionPathExists=/bin/setupcon ExecStart=/bin/setupcon --keyboard-only Anton Zinoviev
Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)
On Fri, Mar 04, 2016 at 11:23:54AM -0300, Felipe Sateler wrote: > > There is still keyboard-configuration.sh in runlevel S. So this > problem is still present. Yes. The problem however is much smaller because this script does not require $remote_fs. > I suggest including a service file like this: OK. Unfortunately, I will not be able to maintain this file or to update it in accordance with future changes in systemd. So I suppose that unless you or somebody else volunteers to maintain it, it will be better to continue without it. > Description=Set preliminary keymap 'Set the console keyboard layout' is a better description. The new console-setup is better optimized for speed and configures the keyboard only once. > Before=local-fs-pre.target > Wants=local-fs-pre.target What is the meaning of these two? > After=udev.service keymap.service The reason for keymap.service is that the keymap of console-setup can take precedence to the keymap provided by the package kbd (I am not sure this package still configures the keyboard, in the past it did). The keyboard configuration depends on the existence of /dev/null and /dev/tty[1-6]. I have no idea whether this small dependency requires udeb.service. > EnvironmentFile=-/etc/default/locale What does this do? This file is used (optionally) only in abnormal situations. > ExecStart=/bin/setupcon --keyboard-only One novelty in version 1.138 is that it is unnecessary to run setupcon in order to configure the console. It is OK to configure the keyboard in this way, but this usually will be slower than what the script keyboard-setup.sh does -- instead of setupcon it runs /etc/console-setup/cached_setup_keyboard.sh and reverts to using setupcon only when this script doesn't exist of fails. Anton Zinoviev
Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file
On Mon, Feb 29, 2016 at 04:41:41PM -0300, Felipe Sateler wrote: > On 29 February 2016 at 15:22, Anton Zinoviev <an...@lml.bas.bg> wrote: > > > this script will move out of runlevel S on Linux and on FreeBSD there is no > > systemd. > > Interesting. Why is it no longer required during early boot? Because Udev scripts will be used. Normally this script is not going to configure anything and its main function will be to keep the files in /etc/console-setup in good shape. Anton Zinoviev
Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file
tags 796603 -help thanks On Mon, Feb 29, 2016 at 09:54:23AM -0300, Felipe Sateler wrote: > > On Mon, 22 Feb 2016 19:33:28 +0300 Anton Zinoviev <an...@lml.bas.bg> wrote: > > tags 796603 + help patch > > I see you tagged this bug help. What can I do to help move this forward? Thank you. In the new version I am preparing now (should be ready in a couple of days), this script will move out of runlevel S on Linux and on FreeBSD there is no systemd. So it seems there will be no need for a systemd service unit. Anton Zinoviev
Bug#816090: console-setup: does not avoid waiting for $remote_fs during early boot
On Sat, Feb 27, 2016 at 09:12:55PM +0700, Igor Liferenko wrote: > > So, for those who need to enable NetworkManager-wait-online.service > (which is disabled in Debian by default and which is required to be > able to mount NFS shares during boot) it would be interesting to know > if it is safe with current settings in console-setup package. If it is > not safe, please put a warning somewhere what should be do to make it > safe. With the current versions (<=1.137) if /usr is not mounted by a networked file system, then it is safe. If /usr is networked, then the sysadmin has to run manually 'setupcon --save-only' when the installation completes and each time he modifies the configuration files of console-setup. With the next release, I don't know yet. Anton Zinoviev
Bug#816090: console-setup: does not avoid waiting for $remote_fs during early boot
On Sat, Feb 27, 2016 at 06:32:09PM +0700, Igor Liferenko wrote: > > It has been fixed in ubuntu > > > http://launchpadlibrarian.net/199935500/console-setup_1.108ubuntu3_1.108ubuntu4.diff.gz This patch lowers the init script requirement from $remote_fs to $local_fs. This is incorrect because console-setup relies on /usr being available and /usr is provided by $remote_fs. Anton Zinoviev
Bug#759657: console-setup w/ systemd forgets font setting
On Fri, Feb 26, 2016 at 11:19:54AM +0100, Yuri D'Elia wrote: > > I've just experienced this bug. I've installed a fresh debian system on a new > laptop (using sid) from scratch. > > I've configured console-setup to use TerminusBold 16x32, and while it works > just after running dpkg-reconfigure, the setting is not correctly restored > after a reboot. I expect a fixed package will be ready in a few days. Anton Zinoviev
Bug#815154: gnome-control-center removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard
On Tue, Feb 23, 2016 at 11:51:35AM -0300, Felipe Sateler wrote: > On 19 February 2016 at 14:52, Anton Zinoviev <an...@lml.bas.bg> wrote: > > > > XKBMODEL has no default value (at least in console-setup). It should > > always be > > present and never as empty value. Thanks to this discussion, now I think it will be a good idea for console-setup to compute some default XKBMODEL. > This is not what keyboard(5) says: > > > XKBMODEL > Specifies the XKB keyboard model name. Default: pc105 for most > platforms. Thank you. I acknowledge that this is a bug in the documentation. I will have to rewrite this man-page so that it becomes clearer which parts in it are software independent and which are related specificly to console-setup. > On 20 February 2016 at 11:02, Anton Zinoviev <an...@lml.bas.bg> wrote: > > In case it is difficult to preserve the existing value, you can use 'pc105' > > as a > > default value. Alternatively, the following table with default values can > > be > > used: > > > > Architecture Subarchitecture Model > > --- > > m68k atari ataritt > > m68k mac macintosh_old > > m68k Other pc105 > > powerpc amiga amiga > > powerpc Other pc105 > > Other pc105 > > Maybe console-setup should encode this table itself, so that the > documentation becomes correct. In fact, console-setup can compute default XKBMODEL if one is missing. If the file /etc/default/keyboard becomes corrupt, then this will be corrected when the package is upgraded (or the user uses dpkg-reconfigure). The reason no such logic exists in /bin/setupcon (the script used to actually configure the console) is that the script setupcon can be used on any Linux or FreeBSD variety (not just Debian) and I don't know how to implement a table like this in a distribution independent way. Therefore, all such logic is encoded in the package scripts (mostly debconf config and postinst). Even if I include such a logic in setupcon, it will be somewhat primitive, so a warning to the user will have to be issued when XKBMODEL is missing. Anton Zinoviev
Bug#815154: gnome-control-center removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard
On Sat, Feb 20, 2016 at 11:38:59PM +0100, Andreas Henriksson wrote: > > Anyway, this is getting pretty meta-discussion like here so we should > probably > just say that it's good that we both know we have different views on a couple > of things here. As far as I can see, the only difference is that you were talking about a configuration file which is maintained by (a specific) software and I was talking about a configuration file maintained by a human. > > This is a configuration text file maintained manually by the system > > administrator. > > (Except manual labour is becoming less and less common. After all we use > computers to automate things.) This is irrelevant. The file /etc/default/keyboard is a file maintained by a human by definition. :) Any program modifying it has to do this with care as described in http://man.cx/debconf-devel%287%29#heading14 > All I can say it that such a person should not be reconfiguring the > system keyboard setup with gnome-control-center then. Also I kind > of doubt that GNOME doesn't already have very good internationalisation > support, but I personally don't have any experience with non-latin setups. You will be surprised how bad is it. In order to toggle the keyboard between Latin/non-Latin mode one has to click with the mouse on a button in the upper right corner of the screen. Alternatively, one can go in gnome-control-center to 'Keyboard' and then 'Shortcuts' and then on 'Typing', where there is a possibility create a shortcut for changing the keyboard mode. Notice how hidden is this possibility and even if one goes along this long path (control center->keyboard->shortcuts->typing) he will find non-informative descriptions such as 'Switch to next input source' which tell nothing about changes in the keyboard mode. But suppose our hypothetical user uses Google and finds out this hidden place. Then he will be able to use a complex combination such as Control-Alt-K to toggle the keyboard mode instead of something more convenient or popular. For example I am using the right Alt to toggle the keyboard mode and I think that in Russia people often use the key CapsLock as a toggler and Windows users are used to the combinations Alt-Shift and Control-Shift. By the way, combinations as Control-Alt-K are not supported by plain X. They can not be used outside Gnome -- in X or on the console. (P.S. Some more googling told me that one can use gnome-tweak-tool to configure properly the keyboard in Gnome.) > Then I looked at the examples at the bottom of the manpage > Please note how none of them includes XKBMODEL! > Are the manpage examples broken or what am I missing? I think it is normal for examples in a man page not to cite whole files but only the relevant lines. XKBMODEL has nothing to do with the keyboard layout whose configuration is explained in these examples. > I was initially thinking that hardcoding pc105 would be very ugly, but > given your explanation now I think it sounds like a sane solution. If we are talking about keyboard at the Login Screen, then yes -- pc105 is a sane solution. It seems this is the point of view of the developers of gnome control center, as in order to configure the system wide keyboard layout the user has to press the button 'Login Screen'. > (Still wondering though if we really need to hardcode an output > of XKBMODEL=pc105 into /etc/default/keyboard. If this is the default we > shouldn't need to include it in the configuration file IMHO. Despite what the developers of gnome control center think, ;) the system wide keyboard configuration is used not only at the Login Screen. While pc105 is more or less ok for the Login Screen, it is not always ok in the desktop environment. The functions of some multimedia and game keyboards will be limited with pc105. > And as mentioned the examples of keyboard(5) suggest it's not needed) The examples suggest the user doesn't need to modify the model in order to change the layout. Think of it in this way: XKBMODEL -> describes the hardware XKBLAYOUT,XKBVARIANT,XKBOPTIONS -> describe the intended software behaviour Anton Zinoviev
Bug#751955: About bug #751955: Broken /etc/default/keyboard
Hello, In the log of Bug #751955 we can find the following comments: == > Since one or two days, the keymap on my laptop is wrong at really early > boot when I need to input the password for my cryptsetup partion. > I encountered the exact same issue on Stretch. I just reinstalled my computer > and then just wanted to move my root LVM volume to another one. I really > don't > know what I did wrong since it's not the first time I'm doing such things but > well I may have done something bad that messed it up > The problem first appeared when I updated from Debian 8.0 to 8.1 - so there > might > be a lot of users affected. > Just had this on a recent Jessie install. The culprit seems to be the absence > of XKBMODEL in /etc/default/keyboard. > Some days ago, probably after an update, I suddenly had a rough time entering > my > password on boot > In my case changing keyboard layout settings in Gnome resulted in the > XKBMODEL > being deleted from /etc/default/keyboard. == In all cases the problem seems to be caused by errors in /etc/default/keyboard. It is known that gnome-control-center (and possibly other configuration programs based on systemd/localed) erase the value of XKBMODEL from /etc/default/keyboard. On the other hand, for Björn Siebke the problem seems to have arised after upgrade from Debian_8.0 to Debian_8.1. Since Debian_8.0 and Debian_8.1 use identical versions of console-setup, some other package must have corrupted /etc/default/keyboard but I have no idea which one. Therefore, I'd like to ask you: Have you observed this bug in situations when you are certain you haven't used gnome-control-center or some other configuration program based on systemd/localed? Anton Zinoviev
Bug#757688: keyboard-configuration: Strange AltGr key
On Sun, Aug 10, 2014 at 08:10:59PM +0300, Anton Zinoviev wrote: > On Sun, Aug 10, 2014 at 04:36:50PM +0300, Victor Porton wrote: > > > > When the keyboard is in English mode, AltGr has no effect. > > > > When the keyboard is in Russian mode, holding AltGr temporarily > > switches to English mode. (By the way when the keyboard is in Russian mode, > > pressing AltGr makes an unpleasant beep, what I reported in an other bug > > report.) > > > > Make it symmetric: in Russian holding AltGr should temporarily switch to > > English and in English to Russian. > > It looks like misconfigured keyboard. > > Run > > dpkg-reconfigure keyboard-configuration > > as root and then reboot the system. Then report back with the results. Hello, Is this bug still existing? If not, I suppose we can close it? Anton Zinoviev
Bug#800522: console-setup: purge leaves files behind
On Wed, Sep 30, 2015 at 02:17:33PM +0200, Andreas Henriksson wrote: > > $ sudo aptitude purge console-setup console-setup-linux > dpkg: warning: while removing console-setup-linux, directory > '/etc/console-setup' not empty so not removed > > $ ls /etc/console-setup/ > Lat15-Fixed16.psf.gz Uni2-Terminus32x16.psf.gz Hello, These two files are leaved there by an old version of console-setup (pre 1.111). Unfortunately, the names of these files are unpredictable, so it is impossible to remove them automatically when purging the packages. The newer versions of console-setup (>=1.111, this includes the version you purged) don't create files with unpredictable names so they can remove all files when purged. Since, the new versions of console-setup do this I suppose we can close this bug? Ofcourse, it would be nice if the newer versions of console-setup removed the files leaved by older versions but there is nothing we can do about this, so not much will be gained if we keep the bug open. Anton Zinoviev
Bug#815154: gnome-control-center removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard
Bug #765343 is related to this one. On Fri, Feb 19, 2016 at 08:33:08PM +0100, Andreas Henriksson wrote: > > On Fri, Feb 19, 2016 at 08:52:25PM +0300, Anton Zinoviev wrote: > > > The modifying program, however, has to leave everything else intact: > > assignments of unknown variables, commented lines and blank lines. > > I don't think this is good advice however. The unknown variables really have to be preserved because we have no idea what variables will be used by future versions of console-setup, X or other keyboard using applications. As for the comments, they should be preserved because this is not some registry of values like Gconf or the registry of Microsoft. This is a configuration text file maintained manually by the system administrator. > Consider the highly theoretical case of a very simple configuration > program only dealing with XKBLAYOUT and leaving other fields intact, > eg. XKBVARIANT. Well, XKBVARIANT is not exactly an unknown variable. :) > > XKBMODEL has no default value (at least in console-setup). It should > > always be present and never as empty value. > > (If there's no default, how can it be expected to never be empty?! Debian installer puts there a sensible value. > Also empty seems to be perfectly acceptable by/for X atleast.) I don't know what exactly X does when XKBMODEL is an empty string. On most architectures there is a default model which works in most cases (but some multimedia and game keyboards require a specific model to be fully supported). On hppa it is impossible to have any default model but X doesn't run on hppa... > > XKBOPTIONS is not necessary in which case empty value is assumed. > > Notice however that XKBOPTIONS should never be empty (or missing) when > > the keyboard is for a non-Latin language. > > Thanks for this advice. I think it would be great if we could formalize > the expectations programs parsers (and writers) of /etc/default/keyboard > can make on a wiki.debian.org page or similar When I wrote 'XKBOPTIONS should never be empty' I didn't mean some program expects it not to be empty. I only meant that the user is going to be very upset if his XKBOPTIONS are removed. > I'm thinking a table with all known variables listed plus if they're > optional, default value, what else? Try 'man keyboard'. Then ask me, if there are any questions. :) > (Once it's more clear to me I'll volunteer trying to improve the debian > systemd/localed patch to follow your advice when I find time, unless someone > else beats me to it. Main question would be the one in paranthesis above.) As for the systemd/localed, the only problem I can see there is that it removes the comments from the file. Other than that it seems ok -- it preserves the values of the unknown variables and it works correctly with spaces. > > Since gnome-control-center doesn't provide means to configure > > XKBOPTIONS, I suppose it will be best if it leaves the current value > > unchanged (this is debatable). > > As discussed above I don't really agree and appreciate this being > debatable. ;) I haven't made tests but I suppose that Gnome ignores the system-wide keyboard layout and always sets a user specific layout. If no other working environments are used (graphical or console based), then few people are going to miss the value of XKBOPTIONS because most of these options are not necessary to type the username and the password. This also has the additional benefit, also debatable ;) that the keyboard at the login window will be more or less standard. For example the keys CapsLock and Control are not going to be swapped. On the other hand, if we want to be able to configure system-wide keyboard layout not only for Gnome, then the only realistic solution for Debian based systems I can see is to keep XKBOPTIONS unchanged. This is so because console-setup puts there a very sensible value and it is more or less layout independent. But I am not sure that we really want to be able to configure system-wide keyboard layout for non-Gnome environments using gnome-control-center. There are other more powerful programs to do this. Therefore, despite the title of this bug report, we can consider it fixed if gnome-control-center doesn't remove the variable XKBMODEL. Deleting XKBOPTIONS is acceptable. In case it is difficult to preserve the existing value, you can use 'pc105' as a default value. Alternatively, the following table with default values can be used: Architecture Subarchitecture Model --- m68k atari ataritt m68k mac macintosh_old m68k Other pc105 powerpc amiga amiga powerpc Other pc105 Other pc105 Notice that m68k is no longer supported by Deb
Bug#815244: gnome-control-center: Doesn't work properly with spaces in the values of XKB{LAYOUT, VARIANT, OPTIONS} in /etc/default/keyboard
Package: gnome-control-center Version: 1:3.14.2-3 Severity: normal gnome-control-center doesn't work properly when the values of XKBLAYOUT, XKBVARIANT or XKBOPTIONS contain spaces. Steps to reproduce: 1. $ sed 's|^ *XKBLAYOUT=.*|XKBLAYOUT="us, fr"|' /etc/default/keyboard >/tmp/keyboard.tmp 2. $ sudo mv /tmp/keyboard.tmp /etc/default/keyboard 3. $ grep XKBLAYOUT /etc/default/keyboard --> XKBLAYOUT="us, fr" 4. $ gnome-control-center 5. Go to "Region & Language" 6. Go to "Login Screen" 7. In the "Input Sources" section add Chinese keyboard layout 8. $ grep XKBLAYOUT /etc/default/keyboard --> XKBLAYOUT="us,cn" That is, the French layout is removed. Let me add that systemd seems to work correctly with spaces in the values of the variables. For example if /etc/default/keyboard contains an assignment SOMEOPTION='option with spaces' then after gnome-control-center modifies the file, we will obtain SOMEOPTION="option with spaces" Anton Zinoviev -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=bg_BG.utf8, LC_CTYPE=bg_BG.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-control-center depends on: ii accountsservice0.6.37-3+b1 ii apg2.2.3.dfsg.1-2 ii colord 1.2.1-1+b2 ii desktop-file-utils 0.22-1 ii gnome-control-center-data 1:3.14.2-3 ii gnome-desktop3-data3.14.1-1 ii gnome-icon-theme 3.12.0-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii gnome-settings-daemon 3.14.2-3 ii gsettings-desktop-schemas 3.14.1-1 ii libaccountsservice00.6.37-3+b1 ii libatk1.0-02.14.0-1 ii libc6 2.19-18+deb8u2 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libcanberra-gtk3-0 0.30-2.1 ii libcanberra0 0.30-2.1 ii libcheese-gtk233.14.1-2 ii libcheese7 3.14.1-2 ii libclutter-1.0-0 1.20.0-1 ii libclutter-gtk-1.0-0 1.6.0-1 ii libcolord-gtk1 0.1.25-1.1+b1 ii libcolord2 1.2.1-1+b2 ii libcups2 1.7.5-11+deb8u1 ii libdbus-glib-1-2 0.102-1 ii libfontconfig1 2.11.0-6.3 ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u4 ii libgl1-mesa-glx [libgl1] 10.3.2-1+deb8u1 ii libglib2.0-0 2.42.1-1 ii libgnome-bluetooth13 3.14.0-2 ii libgnome-desktop-3-10 3.14.1-1 ii libgoa-1.0-0b 3.14.2-1 ii libgoa-backend-1.0-1 3.14.2-1 ii libgrilo-0.2-1 0.2.11-2 ii libgtk-3-0 3.14.5-1+deb8u1 ii libgtop2-7 2.28.5-2+b1 ii libibus-1.0-5 1.5.9-1 ii libkrb5-3 1.12.1+dfsg-19+deb8u2 ii libmm-glib01.4.0-1 ii libnm-glib-vpn10.9.10.0-7 ii libnm-glib40.9.10.0-7 ii libnm-gtk0 0.9.10.0-2 ii libnm-util20.9.10.0-7 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-01.36.8-3 ii libpolkit-gobject-1-0 0.105-8 ii libpulse-mainloop-glib05.0-13 ii libpulse0 5.0-13 ii libpwquality1 1.2.3-1 ii libsmbclient 2:4.1.17+dfsg-2+deb8u1 ii libsoup2.4-1 2.48.0-1 ii libupower-glib30.99.1-3.2 ii libwacom2 0.8-1 ii libx11-6 2:1.6.2-3 ii libxi6 2:1.7.4-1+b2 ii libxml22.9.1+dfsg1-5+deb8u1 Versions of packages gnome-control-center recommends: ii cracklib-runtime 2.9.2-1 ii cups-pk-helper 0.2.5-2+b1 ii gkbd-capplet 3.6.0-1 ii gnome-online-accounts 3.14.2-1 ii gnome-user-guide 3.14.1-1 ii gnome-user-share 3.14.0-2 ii iso-codes 3.57-1 ii libnss-myhostname 0.3-9 ii mesa-utils 8.2.0-1 ii mousetweaks3.12.0-1 ii network-manager-gnome 0.9.10.0-2 ii policykit-1-gnome 0.105-2 ii realmd 0.15.1-1+b2 ii rygel 0.24.2-1+b1 ii rygel-tracker 0.24.2-1+b1 ii system-config-printer 1.4.6-1 Versions of packages gnome-control-center suggests: ii gstreamer1.0-pulseaudio 1.4.4-2 pn libcanberra-gtk-module ii libcanberra-gtk3-module 0.30-2.1 ii x11-xserver-utils7.7+3+b1 -- no debconf information
Bug#815154: gnome-control-center removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard
On Fri, Feb 19, 2016 at 05:10:03PM +0100, Andreas Henriksson wrote: > > > By the way, I was very surprised to find that gnome-control-center modifies > > a > > configuration file belonging to other package. This is not something > > Debian > > policy permits. > > If you want to get into policy discussion land you should know that > /etc/default/keyboard is *not* a conffile (as far as I can see). Now I can see how what I wrote can be confusing in Debian context. When I wrote 'conffile' I simply used it as an abbreviation for 'configuration file'. The following is the relevant part in the Policy: ] If it is desirable for two or more related packages to share a configuration file ] and for all of the related packages to be able to modify that configuration file, ] then the following should be done: ] ] One of the related packages (the "owning" package) will manage the configuration ] file with maintainer scripts as described in the previous section. ] ] The owning package should also provide a program that the other packages may use ] to modify the configuration file. In our case the "owning" package is keyboard configuration because this is the package which creates /etc/default/keyboard and maintains this file in the package scripts. Since in the last sentence the Policy says 'should' and not 'must' there is no need for keyboard-configuration to provice a modifying program. (However, if the maintainters of systemd want to have such a program, I don't mind to provide one.) My point, however, is this: any package modifying a foreign configuration file has to _at_least_ inform the maintainer of the owning package. People are going to report bugs about broken configuration files against the respective owning package and if its maintainer is unaware that other packages are modifying it, then he will be unable to deal with such bugs properly. > > Nevertheless, we do want the keyboard configuration to be user > > friendly, so I approve what gnome-control-center does, as long as it does > > it > > correctly. :) > Suggestions on what correctly means here could be helpful. In my opinion "correctly" (in this case) means this: If some configuration program wants to modify the value of some variable in /etc/default/keyboard, it can do so. The modifying program, however, has to leave everything else intact: assignments of unknown variables, commented lines and blank lines. > Is XKBMODEL= always expected to be written out to the file even > if the value is empty? (or is it a bug in the parsers not handling > when its missing? I'd say normally you want parsers to be liberal > in what they accept.) XKBMODEL has no default value (at least in console-setup). It should always be present and never as empty value. XKBOPTIONS is not necessary in which case empty value is assumed. Notice however that XKBOPTIONS should never be empty (or missing) when the keyboard is for a non-Latin language. Since gnome-control-center doesn't provide means to configure XKBOPTIONS, I suppose it will be best if it leaves the current value unchanged (this is debatable). > I also noticed that patched localed writes out the file without the > values quoted is that considered required? > eg. FOO="bar" becomes FOO=bar when localed writes the file. Thank you for noticing this. It doesn't matter whether it will be FOO="bar" or FOO=bar, as long as bar doesn't contain spaces. I don't know if there is any configuration program which puts spaces there, but both console-setup and X permit spaces, so the sysadmin may put spaces there. I've just tested that gnome-control-center doesnt work properly when the values contain spaces (for example when XKBLAYOUT="us, fr"). Fortunately, it doesn't put spaces in bar. However it erases some parts of the string. This is another bug. Anton Zinoviev
Bug#815154: gnome-control-center removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard
On Fri, Feb 19, 2016 at 08:52:25PM +0300, Anton Zinoviev wrote: > > The following is the relevant part in the Policy: > > ] If it is desirable for two or more related packages to share a > configuration file > ] and for all of the related packages to be able to modify that configuration > file, > ] then the following should be done: > ] > ] One of the related packages (the "owning" package) will manage the > configuration > ] file with maintainer scripts as described in the previous section. > ] > ] The owning package should also provide a program that the other packages > may use > ] to modify the configuration file. > > In our case the "owning" package is keyboard configuration because this is > the > package which creates /etc/default/keyboard and maintains this file in the > package scripts. Please, ignore this. Obviously, it talks about the package configuration scripts and gnome-control-center is not such a script. Anton Zinoviev
