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#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#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#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#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#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#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#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
Bug#729321: keyboard-configuration: changes /etc/default/keyboard upon upgrade without asking
On Fri, Nov 15, 2013 at 02:54:55PM +, Steve Cotton wrote:
The upgrade scripts do lots to preserve configuration changes, but the option
* keyboard-configuration/unsupported_config_options: false
has a much longer lifespan than it seems it should. Answering false to the
debconf prompt below means that it will clobber the options on every upgrade,
although the intention seems to be that it would only affect the initial
interactive migration from debian-installer or XOrg settings.
I think there has been a reported bug against a very old version of
console-setup caused by the fact that when the configuration in
/etc/default/{console-setup,keyboard} was not supported by the upgrade
scripts, console-setup refused to ask any question. So this question is
necessary - there are cases when the changes in the configuration files
are not intended and the user might want to use dpkg-reconfigure in
order to fix the files.
I suppose the attached patch is going to fix this bug but I haven't made
any tests. Unfortunately I won't be albe to work on console-setup for
about a month, so I prefer to keep for now the patch in the BTS rather
than to commit it (unless, of course, some other developer has the time
to check whether the patch fixes the bug).
Anton Zinoviev
diff -Naur console-setup-1.103/debian/keyboard-configuration.config console-setup-1.103.new/debian/keyboard-configuration.config
--- console-setup-1.103/debian/keyboard-configuration.config 2013-09-16 08:18:50.0 +0300
+++ console-setup-1.103.new/debian/keyboard-configuration.config 2013-11-19 11:05:13.391026477 +0200
@@ -1253,6 +1253,8 @@
# the locale or xorg.conf (in which case the user may
# be unaware).
if [ -f $CONFIGFILE ]; then
+ db_reset keyboard-configuration/unsupported_config_layout || true
+ db_fset keyboard-configuration/unsupported_config_layout seen false
db_subst keyboard-configuration/unsupported_config_layout \
XKBLAYOUT $XKBLAYOUT
db_subst keyboard-configuration/unsupported_config_layout \
@@ -1267,6 +1269,8 @@
fi
db_get keyboard-configuration/unsupported_config_layout
else
+ db_reset keyboard-configuration/unsupported_layout || true
+ db_fset keyboard-configuration/unsupported_layout seen false
db_subst keyboard-configuration/unsupported_layout \
XKBLAYOUT $XKBLAYOUT
db_subst keyboard-configuration/unsupported_layout \
@@ -1293,10 +1297,6 @@
unsupported_layout=no
fi
else
- db_reset keyboard-configuration/unsupported_config_layout || true
- db_fset keyboard-configuration/unsupported_config_layout seen false
- db_reset keyboard-configuration/unsupported_layout || true
- db_fset keyboard-configuration/unsupported_layout seen false
# skip the question without making Debconf loop
STATE=$(( $STATE + $STATE - $old_state ))
fi
@@ -1436,6 +1436,8 @@
[ $unsupported_options = yes -a $is_not_debian_installer ]
then
if [ -f $CONFIGFILE ]; then
+ db_reset keyboard-configuration/unsupported_config_options || true
+ db_fset keyboard-configuration/unsupported_config_options seen false
db_subst keyboard-configuration/unsupported_config_options \
XKBOPTIONS $XKBOPTIONS
db_input medium \
@@ -1448,6 +1450,8 @@
fi
db_get keyboard-configuration/unsupported_config_options
else
+ db_reset keyboard-configuration/unsupported_options || true
+ db_fset keyboard-configuration/unsupported_options seen false
db_subst keyboard-configuration/unsupported_options \
XKBOPTIONS $XKBOPTIONS
db_input medium keyboard-configuration/unsupported_options || true
@@ -1462,10 +1466,6 @@
unsupported_options=no
fi
else
- db_reset keyboard-configuration/unsupported_config_options || true
- db_fset keyboard-configuration/unsupported_config_options seen false
- db_reset keyboard-configuration/unsupported_options || true
- db_fset keyboard-configuration/unsupported_options seen false
# skip the question without making Debconf loop
STATE=$(( $STATE + $STATE - $old_state ))
fi
Bug#657904: converting /usr/share/doc/console-setup into a symlink
On Sat, Jul 28, 2012 at 02:27:16PM +0200, Julien Cristau wrote: I think personally I would prefer undoing this symlink mess altogether. Not sure what others think... Symlinks are there in order to 1. Simplify the maintaining of the package, as there is no need to take care of too many directories and what goes where (there have errors in the past caused by too many binary packages built by console-setup and having to watch too many files if they need to be updated). 2. Help the user find the documentation. What can be a problem for the maintainer is most certainly a bigger problem for the casual user who has to dig into various directories and combine the split information. 3. In some cases separate directories lead to artificial and unnecessary split of the information. If the patch of Sven works, it is going to save us from lots of future headaches. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666647: Still cannot use LaTeX with cyrillic symbols
On Mon, Jul 23, 2012 at 01:43:17AM +0900, Norbert Preining wrote: * these fonts have unclear license status. It is not clear whether taking the various glyphs from various sides and adding some things and sticking it together is fine. Technical issues aside, I'd like to ask everybody not to make any calims like this one. The fonts are absolutely legal in their current form. I mean both copyright and trademark. With respect to the copyright the situation is clear because the original fonts were GPL-licensed. With respect to the trademarks years ago I was given legal advise. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666647: Still cannot use LaTeX with cyrillic symbols
On Sat, Jul 14, 2012 at 12:16:32AM +0200, Francesco Poli wrote: Both of the current RC bugs against scalable-cyrfonts seem to be related to the -tex binary package. If the binary package isn't needed any more (as the above suggests), maybe it should just be dropped? Maybe... I am not sure, though. Anyway, I am just a (former) user: let's wait for the package maintainer's reply... The maintainer listens, but he doesn't know what to reply... When the maintainter created this package many years ago (that was me) there was no such conflict and the font names of the package were compliant with the font name guidelines used by the TeX community. http://tug.org/fontname/html/ As far as I know, at that time no TeX font conflicted with these names and in particular no Debian package shipped fonts with conflicting font names. A long time passed since then. I no longer feel myself competent to either assess properly the present conflict or to be sure I am implementing the right solution. Dropping scalable-cyrfonts-tex is not something desirable. This package provides several styles whose effect (I think) is not achievable without this package. I mean styles such as cyrtimes, cyrbookman, cyrnewcent, cyrpalatino, teams. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669604: kbdcontrol can't load any keymap
On Wed, May 16, 2012 at 11:28:29PM +0200, Robert Millan wrote: /dev/console works for me. If I don't hear any more news on this, I'll assume that it also works for everyone else and consider this bug as fixed. No, this doesn't work for me. Unfortunately I have upgraded from kernel 8.2 to 8.3 so this doesn't help. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669604: kbdcontrol can't load any keymap
Package: kbdcontrol Version: 9.0+ds1-1 Severity: grave I am not sure whether this bug belongs to kbdcontrol or to the kernel. I am unable to use kbdcontrol for any keymap. Even for a simplest test one-line keymap it issues the following error message: # kbdcontrol -l any_file.kbd kbdcontrol: setting keymap: Inappropriate ioctl for device I observed this bug on testing(wheezy). After I upgraded the system to unstable(sid) the bug still remains. Anton Zinoviev -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.2-1-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kbdcontrol depends on: ii debconf [debconf-2.0] 1.5.42 ii libbsd00.3.0-2 ii libc0.12.13-27 kbdcontrol recommends no packages. kbdcontrol suggests no packages. -- debconf information: * kbdcontrol/keymap: us.iso.kbd -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632235: source contains non-DFSG components
On Thu, Jun 30, 2011 at 07:58:23PM +0200, Daniel Baumann wrote: src:console-data is in main, therefore any parts, regardless if they are installed into the binary packages or not, needs to fulfil the DFSG. the 'Agafari' files clearly are not DFSG compliant. please remove the files from the source, and please consider to write an copyright file that has references to files so that normal people can dereference it. All bitmap fonts are public domain by their nature (according to the decision of some court). There is no need to remove these fonts. http://www.renpy.org/wiki/renpy/misc/Bitmap_Fonts_and_Copyright Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619711: console-setup: breaks copying keymap to initramfs
reassign 619711 initramfs-tools
thanks
On Sat, Mar 26, 2011 at 12:49:24PM +0100, Mario 'BitKoenig' Holbe wrote:
if a system's keymap needs to be loaded during the initramfs stage,
initramfs-tools' /usr/share/initramfs-tools/hooks/keymap looks for
/etc/console-setup/cached.kmap.gz
and copies it to the initramfs.
I had no idea that initramfs-tools does this. I think this was wrong
even with old version of console-setup because in some situations
cached.kmap.gz will not correspond to the actual configuration and in
some versions of the package it was even possible for this file not to
exist.
console-setup 1.71 changed the name of this file to
/etc/console-setup/cached_${CHARMAP}_$backspace$VARIANT.kmap.gz
i.e. something like
/etc/console-setup/cached_ISO-8859-15_del.kmap.gz
The new version of console-setup tries to guess good values for several
configuration options if values are not provided in its configuration
files. Because of this, it is possible (when the system environment
changes - locale and/or terminal settings) that a new keymap will be
required even when the user has not changed anything in the
configuration files of console-setup. Hence, it would be impossible for
console-setup to tell whether cached.kmap.gz can be used or the keymap
has to be regenerated.
There are several alternatives to fix this bug like
* symlinking the new name to the old
* moving the keymap-copying from initramfs-tools to console-setup
* updating initramfs-tools to honor the new keymap name
It will be difficult for initramfs-tools to tell what is the correct
name of the cached keymap. Symlinking the new name to the old is
unreliable so I'd prefer not to implement this. Because of this in
version 1.72 of console-setup a new option of setupcon is implemented
--save-keyboard. Suppose you want to save the keymap in
/tmp/initrd/etc/console-setup/cached.kmap.gz. Then simply use the
following command:
setupcon --save-keyboard /tmp/initrd/etc/console-setup/cached.kmap.gz
Alternatively, instead of --save-keyboard you can use --setup-dir. I
will explain this second option in a separate bug report. Both new
options of setupcon are for now undocumented because I want to know
first that they will be useful.
Anton Zinoviev
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583388: Non-US keyboard problem with graphical installer
On Tue, Jul 06, 2010 at 04:13:02PM +0200, Frans Pop wrote: If you care enough to investigate an issue like this, it takes only very little extra time to find the real trouble spot and fix things there instead of just papering over the real bug and making the code less efficient and maintainable than it already is. I think what Cyril did is enough. Now he can do some other job. Fixing this bug in c-s is something that I can do. The opposite is not true :), I mean I can not work for g-i and he can. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564611: console unusuable after upgrade
close 564611 thanks I am closing this bug because as I said there is nothing wrong in console-setup. On Wed, Jan 13, 2010 at 03:37:21PM +0100, Marc Dequènes (Duck) wrote: This freeze was not caused by the removal of console-setup. Perhaps, but rebooting without reinstalling it did not solve anything, so it is linked somehow. Ok, and it is true - I don't know anything about this. But the fact is this happens only while console-setup is not installed so most certainly the problem is somewhere else. Seems you don't know much about anything. If console-tools is not faulty, then you could help me find out why this removal has such unattended impact. From your report I concluded that you knew the reason console-setup was removed. It was automatically installed by the dependency of xserver-xorg(-core) and then removed when this dependency was changed to a dependency on keyboard-configuration. And it is obvious why its removal had such an impact. I find it quite rude to just say that's not my responsability and not try at all to help users. I agree. I decided that you didn't need help because you fixed your own system. And I think no action is required in any package so it is better to close the bug than to reassign somewhere else. And it would be stupid to tag it 'wontfix' because no fix is necessary. Every autoremoval of packages involves the risk to remove a package that the user does not want removed. If users migrating from Lenny have important packages removed with the default way of cleaning his system (with apt-get autoremove, as suggested by the tool itself), then i think this is a problem. Yes, it would be a problem and it would probably mean xserver-xorg has to depend again on console-setup. Fortunately the lenny's version of xserver-xorg doesn't depend on console-setup. So, why don't you want to help ? Because I don't know what I can do about it. I don't think Debian will be improved in any way if xserver-xorg(-core) depends again on console-setup. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560570: console-setup: FTBFS: Couldn't open ckb/rules/xorg.xml
tags 560570 unreproducible thank you On Fri, Dec 11, 2009 at 09:54:15AM +0100, Lucas Nussbaum wrote: Source: console-setup Version: 1.50 Severity: serious User: debian...@lists.debian.org Usertags: qa-ftbfs-20091210 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Can you test this again? Maybe there was something wrong with your build environment? ./xmlreader KeyboardNames.pl Couldn't open ckb/rules/xorg.xml: No such file or directory at ./xmlreader line 67 The file ckb/rules/xorg.xml exists in the source package and it is a static file - nothing removes or changes it. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558475: Bug#558386: keyboard-configuration: Keyboard map not recognized (Lenovo Thinkpad T61)
On Sun, Nov 29, 2009 at 11:52:59AM -0200, Renato S. Yamane wrote: Now, slash (/) and ccedilla (ç) works fine on console, BUT now, when I press backspace it give me 3 losang (⧫⧫⧫) and tilde followed by word a give me È and 2 losang (È⧫⧫) I am not sure I understand, but does this happen only with the ccedilla? If yes, then the problem is perhaps due to incomplete support of UTF-8 on the console (a kernel problem). Julien tell me to report this bug to bugs.freedesktop.org: https://bugs.freedesktop.org/show_bug.cgi?id=25338 And they tell me to report this bug to KDE :-( KDE is responsible to console? No. :) Tell them that br(thinkpad) doesn't exist in /usr/share/X11/xkb/rules/base.xml Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558475: Bug#558386: keyboard-configuration: Keyboard map not recognized (Lenovo Thinkpad T61)
forwarded 558386 https://bugs.freedesktop.org/show_bug.cgi?id=25353 thank you On Sun, Nov 29, 2009 at 01:34:29PM -0200, Renato S. Yamane wrote: Em 29-11-2009 13:18, Anton Zinoviev escreveu: On Sun, Nov 29, 2009 at 11:52:59AM -0200, Renato S. Yamane wrote: Now, slash (/) and ccedilla (ç) works fine on console, BUT now, when I press backspace it give me 3 losang (⧫⧫⧫) and tilde followed by word a give me È and 2 losang (È⧫⧫) No. The big problem is with slash (/), that is placed in CTRL_R place. So, in console, when I type /, it is interpreted like a CTRL_R. Please describe what happens with the right Control key if you remove cached.kmap.gz and invoke 'setupcon' as root. I can't understand what you wrote. Does right Control always behave as right Control and doesn't produce /? Or it produces / but then something weird happens when you use Backspace? Does it happen only on the console? Th problem is not in kernel, because the kernel is not updated in my last aptitude upgrade. I meant that Backspace doesn't work well with some symbols when the console is in Unicode mode. This has always been a problem. Tell them that br(thinkpad) doesn't exist in /usr/share/X11/xkb/rules/base.xml But my keyboard is working fine on X. The problem is in console. The keyboard configuration programs (including keyboard-configuration) will not show br(thinkpad) as a possible option. I reported the problem (https://bugs.freedesktop.org/show_bug.cgi?id=25353). Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536683: closed by Anton Zinoviev zinov...@debian.org (Bug#536683: fixed in console-setup 1.46)
severity 536683 normal thank you On Thu, Nov 19, 2009 at 08:15:21AM +0100, Tibor Zenis wrote: Upgrade to version 1.47 spans many processes. I can't reproduce this behaviour by reinstallation of the console-setup. The behaviour might be changed after installation of the keyboard-configuration package. This allows me to hope that 1.47 fixed the problem. For now I will lower the severity of this bug report. I am going to close it if no new reports of this kind follow for a while. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536683: keyboard-configuration postinst stuck in loop
reopen 536683 thank you On Wed, Nov 18, 2009 at 09:26:22AM +0100, Erich Schubert wrote: Note that I didn't choose Other in the first place. Could it be that the script tries to interpret Other as 'Go back to previous menu', but then just gets the cached debconf options again, thus ending up stuck in this menu loop of going into USA and back via Other? Thank you, it seems this was the reason for the loop. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536683: closed by Anton Zinoviev zinov...@debian.org (Bug#536683: fixed in console-setup 1.46)
On Wed, Nov 18, 2009 at 09:48:53PM +0100, Tibor Zenis wrote:
Hello,
the original bug is still present. To complete the upgrade I had to
change the XkbLayout to us (file /etc/default/console-setup).
Do you mean that version 1.47 spans 1000 grep, sed, sort processes?
This was the bug I believe was fixed. Or something different happens
this time? Can you send your /etc/default/{keyboard,console-setup}
files so I can make tests.
Anton Zinoviev
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541291: console-setup: No special characters after update
retitle 541291 Some issues to document in FAQ severity 541291 minor thank you On Thu, Aug 13, 2009 at 01:31:51PM +0200, Harald Braumann wrote: For `€' two additional characters are deleted. For the other symbols one additional character is deleted. And it adds up. Thus if I type '€öäü', 5 additional characters are deleted. This is because in UTF-8 '€' is coded with 3 bytes and the non-ascii letters with 2 bytes. It also makes it impossible for different users to use different locale settings. For instance as root I usually use POSIX, because all the files I touch as root are ASCII-only anyway. So far I never had a problem with that. The keyboard was set to a DE layout and the console font supported ISO-8859-15. That's all that was needed. Now this doesn't work anymore. Console-setup permits user-level configuration. The system configuration in /etc/default/console-setup can be overriden by ~/.console-setup. But during the last few years, due to a change in the kernel configuration the non-priviledged users are not allowed to change the keyboard layout. On Thu, Aug 13, 2009 at 03:33:29PM +0200, Harald Braumann wrote: Contrary to what I believed, I could have set LC_CTYPE to POSIX instead of ISO-8859-1 (small bug in .profile). With the combination of LC_CTYPE=POSIX and CHARMAP=ISO-8859-15 I can reproduce the weird behaviour. However, this very same combination worked before the upgrade. But I've also upgraded bash and libreadline. So the changed behaviour might very well be due to changes in those packages or a combination of changes in those and in console-setup. The change in the behaviour is unrelated to console-setup. PS: I think you can close that bug. /usr/share/doc/console-setup/FAQ.gz has not been updated for a while and your bug contains several things that need to be documented there. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524233: console-setup should conflict with console-data
On Wed, Apr 15, 2009 at 07:14:34PM +0200, Kurt Roeckx wrote: Package: console-setup, console-data Severity: serious Hi, console-setup and console-data both allow you to setup the keyboard layout but they do not take each other settings into account. I think there is yet an other package that does the same thing, but I'm not sure about it's name. I didn't close this bug because I was considering to add a Debconf question asking which package should configure the console (similar to that the user gets with more than one display manager - xdm, wdm, kdm, gdm). But after a second thought I doubt this is worth the effort - console-tools is almost unmaintained and there are still some things that console-setup doesn't do, such as the default state of NumLock, setterm. Moreover the scripts in console-tools and console-data are in bad shape and it will be difficult for their maintainers to do the required changes. So unless there are objections I'd like to close #524233 and #524239. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527641: Package installation overwrites /etc/default/console-setup without warning
On Wed, May 20, 2009 at 10:21:10AM +0200, Raphael Hertzog wrote: found 527641 1.35 found 527641 1.36 thanks If you have found the bug in versions 1.35 and 1.36, please provide more information: is this reproduced behaviour, how did it occur, what was the contents of the configuration file before and after it was overwriten, etc. This is the real problem this bug is about... so closing it with this explanation: * Support unset font in Debconf configurator. Thanks Dave Witbrodt, closes: #527641. This documents how I fixed the problem discovered by Dave Witbrodt. You must have found a completely different problem and thats why I am asking for more information. To fix it, you have to: 1/ document in the file that it's auto-updated based on the debconf infos and that dpkg-reconfigure console-setup is recommended to update it The use of dpkg-reconfigure is optional. Console-setup is not supposed to overwrite its configuration file. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527641: Package installation overwrites /etc/default/console-setup without warning
On Wed, May 20, 2009 at 12:45:55PM +0200, Raphael Hertzog wrote: Well, when I reported #528033, something had lost my bepo setting on upgrade without me doing dpkg-reconfigure console-setup. I assumed it was already reported since 527641 said Package installation overwrites /etc/default/console-setup without warning in its title. Thas was consistent with what I saw: /etc/default/console-setup had been modified/overwritten without my consent to something that did not match my manual configuration. I didn't see how you adressed that by supporting empty values... so I reopened the bug. You are right. #528033 was completely different problem and it was fixed by this: * Escape commas in Debconf questions. Thanks to Raphaël Hertzog, closes: #528033. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526862: console-setup: fail to configure Japanese keyboard
On Tue, May 05, 2009 at 08:05:15AM +0900, Osamu Aoki wrote: On Mon, May 04, 2009 at 04:53:07PM +0300, Anton Zinoviev wrote: XKBLAYOUT=us,jp XKBVARIANT=,OADG109A This worked as work around. After this change X should be usable again. Well, it was sort of usable if I blind touch ... I closed prematurely your bug in version 1.23 of console-setup but I hope the bug was properly fixed in the version 1.24 I uploaded the next day. Now the settings in the config file should become automaticaly like this: XKBLAYOUT=jp XKBVARIANT=OADG109A Please do not hesitate to reopen the bug or to submit a new one if you still think console-setup doesn't work properly. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527057: console-setup: insecure tempfile handling
On Tue, May 05, 2009 at 12:08:14PM +0100, Colin Watson wrote: Anton, I'm filing this bug rather than just correcting it because I'm not sure what you want to achieve here. Was it just code you committed by accident, or do you explicitly want to have extra logging in the package? If the latter, I'd suggest perhaps calls to logger(1) guarded by an environment variable. This happened by accident. I will correct this the next 1-2 hours. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524239: Bug#524233: console-setup should conflict with console-data
I think currently the goal is setterm, keyboard rate and numlock to be set by kbd (notice that console-tools is also obsoleted) and font keyboard layout -- by console-setup. It is not difficult for console-setup to take control on these too but I am not sure about the advantages of this (except maybe that the keyboard rate can be shared with X). Regarding the 2 config files and the user not knowing which one is going to win -- I think you are right. I think we can add a Debconf menu similar to the one the user gets when he installs together several desktop managers (xdm, gdm, kdm and wdm). Anton Zinoviev - Original message - I think there are a few things that console-setup doesn't do that atleast console-tools does: - calling setterm to set powersaving mode. - Set keyboard rate - Being able to set numlock on boot Anyway, my problem with the current situation is that there are 2 config files where I can set the same thing, and it's not obvious which of the 2 is going to win.
Bug#524233: console-setup should conflict with console-data
merge 524233 524239 thanks On Wed, Apr 15, 2009 at 07:14:34PM +0200, Kurt Roeckx wrote: console-setup and console-data both allow you to setup the keyboard layout but they do not take each other settings into account. Why this should be considered a bug? Normaly the users don't have to install both packages but perhaps there are many reasons why they might want to install them both. Console-data and console-cyrillic have happily coexisted for a decade and now this can continue with console-setup (exept that it seems console-data and console-cyrillic are going to become obsolete). Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521122: console-setup: fails to install: eval: line 2125: unexpected EOF while looking for matching `'
On Wed, Mar 25, 2009 at 07:55:54PM +0100, Julien Cristau wrote:
On Wed, 2009-03-25 at 20:09 +0200, Anton Zinoviev wrote:
It is not only your script - the parsing of console-setup doesn't allow
spaces between options so this will require a patch too.
It should be easy to remove the spaces directly from the awk script, if
you want to avoid touching other parts of console-setup for that. Let
me know if I should prepare an updated patch.
I decided it is best to do both, so after some reading of the mawk
manual ;) I added in console-setup support for spaces and made the
awk-script remove them. I also made the script to ignore lines such as
Option XkbModel pc104
Since this is a grave bug I decided to build and upload the package now.
However I am not 100% sure about the syntax of xorg.conf, so if you want
you can check that the new variant of the script works properly.
:) I have attached it.
BTW, the xorg.conf of Celejar discovered another bug in Debconf
configuration of console-setup:
xkblayout=us,il
xkbvariant=dvorak,
became
xkblayout=us,il
xkbvariant=,
I fixed this too.
Anton Zinoviev
#!/usr/bin/awk -f
{
$0 = tolower($0);
sub(#.*,)
xkb = ;
}
/^[ \t]*section[ \t]+inputdevice/,/^[ \t]*endsection/ {
if ($1 == option) {
if ($2 == \xkbmodel\) {
xkb = XKBMODEL;
} else if ($2 == \xkblayout\) {
xkb = XKBLAYOUT;
} else if ($2 == \xkbvariant\) {
xkb = XKBVARIANT;
} else if ($2 == \xkboptions\) {
xkb = XKBOPTIONS;
}
$1 = ;
$2 = ;
}
}
xkb != /^[ \t]*\[^]+\[ \t]*$/ {
sub(^[ \t]*\, );
sub(\.*, );
gsub([ \t], );
print xkb =\ $0 \;
}
Bug#521122: console-setup: fails to install: eval: line 2125: unexpected EOF while looking for matching `'
On Wed, Mar 25, 2009 at 03:07:33AM +0100, Julien Cristau wrote: Thanks, the problem was the space in the XkbOptions value which my script didn't handle. The attached patch fixes that. It is not only your script - the parsing of console-setup doesn't allow spaces between options so this will require a patch too. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#443709: FTBFS: Does not handle comments starting with #
On Sun, Sep 23, 2007 at 08:09:31PM +0200, Christian Perrier wrote: console-setup fails because it does not handle files that have comments beginning with #: Anyone objecting to /me committing Matt's patch? I have just uploaded the package. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405630: NMU uploaded
On Wed, Jan 10, 2007 at 08:26:21PM +0100, Andreas Barth wrote: I uploaded an NMU of your package. Please see this as help to get the package into a releaseable condition for etch. Thank you. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294520: libparted1.6-13: Incorrect handling of extended partitions
I was able to reproduce this bug on my flash device and the result was the same as the submitter reported. In order to reproduce the bug it seams enough to use parted in the following way: 1. Create an extended partition that ocupies the whole disk. 2. Create a logical partition at the beginning of the ext. partition 3. Create a logical partition at the end of the extended partition 4. Create a logical partition at the remaining space Create the partitions with different sizes so you can distinguish them in qtparted. The result should be like this: (parted) p Disk geometry for /dev/sda: 0kB - 260MB Disk label type: msdos Number Start End SizeType File system Flags 1 16kB260MB 260MB extended 5 32kB49MB49MBlogical 7 49MB200MB 151MB logical 6 200MB 260MB 60MBlogical (Notice that partition #7 is before #6.) Now start qtparted. In order to be safe you can start it as non-root provided your user has write access to /dev/sda. The result is that partition #7 is listed as #6 and #6 is listed as #7. Since both parted and partman seam not to be affected by this bug I would recommend to reassign it back to qtparted. Notice that if you decide not to create the partition at the beginning of the extended partition and use a partition table like that: (parted) p Disk geometry for /dev/sda: 0kB - 260MB Disk label type: msdos Number Start End SizeType File system Flags 1 16kB260MB 260MB extended 6 17kB208MB 208MB logical 5 208MB 260MB 52MBlogical then qtparted will be unable to work with this partition table at all. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352449: [Pkg-kbd-devel] Bug#352449: console-setup: seriously broken
On Sun, Feb 12, 2006 at 01:03:47PM +0200, Anton Zinoviev wrote: As Denis supposed this happened because ckbcomp interpretes acute as ACUTE ACCENT (0xb0 in ISO-8859-15) instead of APOSTROPHE (0x27). For the record I meant ISO-8859-1. There is similar bug for some other accents. It seams for the other accents X doesn't act that way. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352299: [Pkg-kbd-devel] Bug#352299: Maybe there is no bug
On Sun, Feb 12, 2006 at 03:24:51PM +0200, Juhapekka Tolvanen wrote: Here is output of locale by root: LANG=en_GB.utf8 [...] Here are contents of /etc/environment : LANGUAGE=fi_FI:fi:en_GB:en LANG=fi_FI.UTF-8 Obviously the contents of /etc/environment was overriden by en_GB.utf8 somewhere but that is not relevant, because... dpkg --purge console-setup apt-get install console-setup Got it! That bug appeared, when I run those commands and debconf was run during pre-configure phase of installation. I need to run dpkg-reconfigure in order to fix that. ... because I can confirm the same behaviour on my system. Now I only have to see the reason for this bug. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352299: [Pkg-kbd-devel] Bug#352299: Maybe there is no bug
On Sat, Feb 11, 2006 at 05:53:36PM +0200, Juhapekka Tolvanen wrote: I just run dpkg-reconfigure console-setup and this time used arrow-keys and return in a little bit different way: I use that curses-based front-end of debconf. I pressed return-key when cursor of terminal was in right choice and not not when it was in OK-button. After that /etc/default/console-setup was just right. Then I run /etc/init.d/console-setup restart and then keys started to work right. Do you think that there is something in console-setup that needs to be fixed or the bug can be closed? Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352299: [Pkg-kbd-devel] Bug#352299: Maybe there is no bug
On Sat, Feb 11, 2006 at 07:10:46PM +0200, Juhapekka Tolvanen wrote: Feel free to close this bug. Or move my bugreport to package called debconf. It would be best to reassign the bug to debconf. Unfortunately I was unable to reproduce it on my system. I tried Debconf both with dialog and whiptail. Do you know what should I do in order to reproduce the bug? Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351089: xfonts-terminus: build-depends on non-existing package `bdf2psf'
On Thu, Feb 02, 2006 at 07:57:56PM +0100, Bastian Kleineidam wrote: Package: xfonts-terminus Version: 4.16-2 Severity: serious Justification: build-depends must exist I just tried to build this package from source and realized that it build depends on a non-existing package `bdf2psf'. Please specify the correct build dependencies. The build dependencies are correct but the bdf2psf package is waiting in the queue for new packages. I had to upload this version of xfonts-terminus because the source package of bdf2psf is console-setup and the binary package console-setup depends on console-terminus (= 4.16-2). Thanks for this bug report, I should report it myself. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347696: console-terminus: Font name changes will break D-I beta1
On Thu, Jan 12, 2006 at 06:23:04PM +0100, Christian Perrier wrote: BTW, I intend to push a more general use of Terminus fonts which seem to me way more complete...and nice.than fonts from console-data. BTW, the most complete console font is Fixed16 from console-setup. For example it supports Armenian, Georgian, Lao, Thai and Vietnamese -- languages that are currently completely unsupported on the console. The only alphabet that can be supported on the console but is not supported by Fixed16 is the Ethiopian. On the other hand Terminus is nice and I am in favour of its more general use. I plan to upload console-setup the coming weekend. Except maybe the case of the Cyrillic K.:) The upstream sent me a patch so the Cyrillic K is OK now. :-) Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336619: Uninstallable on sid
Package: ickle Version: 0.3.2-4 Severity: grave Tags: sid The package is uninstallable on unstable because it depends on libicq2000. It seams in order to fix this bug the only thing that must be done is to remove the file debian/shlibs.local. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329881: bgoffice: ftbfs [sparc] /bin/sh: line 1: 21600 Bus error
On Fri, Sep 23, 2005 at 09:10:38PM -0700, Blars Blarson wrote: Package: bgoffice Severity: serious Version: 3.0-5 Justification: no longer builds from source bgoffice failed to build on a sparc buildd, duplicated on my sparc pbuilder. It also failed on some other buildds. In order to build aspell-bg requires more than 1GB RAM+swap. May be this is what has caused the problem? I hoped this won't be a problem for autobuilders because in its new version aspell-bg has changed its architecture from any to all. If I was wrong I can change aspell-bg to contain a precompiled dictionary hash in its source package. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329881: bgoffice: ftbfs [sparc] /bin/sh: line 1: 21600 Bus error
clone 329881 -1 reassign -1 aspell retitle -1 aspell munch-list fails on some architectures severity -1 normal submitter -1 [EMAIL PROTECTED] thanks Since this aspell munch-list command is quiet CPU+memory intensive for the sake of the autobuilders I am going to fix this bug by including precompiled dictionary hash in the souce package (as the other aspell-* packages do). However there is still some bug in aspell so I have created a small package to reproduce the bug. Get it from http://lml.bas.bg/~anton/misc/aspell-munch-bug.tar.bz2 Run the command ./command in it. Notice that although it refers to the locale bg_BG it is not important to have this locale compiled in the system. I am reassigning a clone of this bug to aspell. However I have not been able to reproduce it using the prepared small package because I don't have access to non-i386 machine. Acording to buildd logs the bug manifests on the following platforms: arm, hppa, ia64, mipsel, powerpc, s390 and sparc. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
