Bug#404503: Wrong characters typed using dead keys
Hi, Pavel Vávra, le Tue 26 Dec 2006 01:01:40 +0100, a écrit : thank you for your explanation. How short is the term you are talking about? Someone has to write a patch, have it accepted upstream, published in a new kernel, then the interface may be considered accepted, and the kbd package be fixed for using it. Is any chance that it will be fixed in stable etch? I don't think so. I cannot believe that I am the first one who find this bug/feature. I'm not surprised. Not many people use the linux console nowadays (this bug only affects the linux console, not X!). Even less people use the linux console _and_ need non-latin1 chars. Does it men that etch will not be ready to UTF-8 for non-Latin1 countries? It _is_ ready for UTF-8 for non-Latin1 countries concerning gnome/kde/etc. desktops. But Linux kernel's console is not. Actually, the linux console sucks for a lot of such utf-8-related things, and not many people are really brave enough to tackle the issue, considering how many people really use it nowadays. Another approach would be to use a framebuffer xterm like bogl or jfbterm. Samuel
Bug#357001: closed by Bastian Blank [EMAIL PROTECTED] (asm/io.h not exported)
Debian Bug Tracking System, le Mon 10 Sep 2007 14:19:34 +, a écrit : asm/io.h is not exported for ia64. What do you mean by exported? The file is there, and some configure scripts hence find it and make C files #include it... If it is not meant to be used, then just drop it... Samuel
Re: kernel 2.6.24 speakup
Samuel Thibault, le Tue 25 Mar 2008 18:39:54 +, a écrit : Apply patches/kernel-integration-2.6.24-source.patch to the main kernel source to GPL-export 4 symbols, Note: by that, I mean to pick that patch into the regular linux-2.6 kernel. That patch is already in the -mm tree actually. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.6.24 speakup
Frans Pop, le Tue 25 Mar 2008 19:29:56 +0100, a écrit : (Please don't CC me on list mail.) Then tell your mailer to use followup-to :) On Tuesday 25 March 2008, Samuel Thibault wrote: The idea is to compile the speakup module out-of-tree but still include it in d-i. Why would you want to compile a module that is in-tree as an out-of-tree module? Mmm, maybe I don't understand what you mean by in-tree. The idea is not to compile speakup built into the kernel, but just as a module, and then it doesn't need to be integrated to the kernel build system, but just be compiled separately, just like exmap, ndiswrapper, spca5xx etc. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.6.24 speakup
Hello, maximilian attems, le Tue 25 Mar 2008 19:31:03 +0100, a écrit : On Tue, Mar 25, 2008 at 03:06:58PM -0300, Otavio Salvador wrote: Samuel Thibault [EMAIL PROTECTED] writes: Hello, Mario Lang, le Tue 25 Mar 2008 17:28:32 +0100, a écrit : Samuel Thibault [EMAIL PROTECTED] writes: (speakup can now be compiled fully independently) linux-modules-extra-2.6 seems like the perfect place for speakup, now that it does not require the kernel to be patched anymore. Well, a small patch is still needed, but it just boils down to GPL-exporting 4 symbols, and that is already in the -mm tree, so backporting it to the debian kernel shouldn't be a problem.. It would be nice if you could talk to Debian Kernel Team (just added it to cc list) and see if this could be added for next 2.6.24 upload or later. That would allow the module to be build from linux-modules-extra-2.6 and later to be added to d-i if needed. ok thanks for informing us. :) afair we had a discussion about speakup and it would point to security troubles of that patch. but i don't remember the cicurmstances why it got droped when going from 2.4 to 2.6? Well, things have evolved a lot since then. Speakup used to need to patch the kernel quite heavily in order to get keyboard screen access. I have worked with lkml to integrate that part much more nicely with notifiers, and it is now part of 2.6.24. The result is that the patch that Speakup needs is now reduced to exporting the inverse_translate, kbd_table, kd_mksound, and screen_glyph symbols, which is already the case in the -mm tree. As a consequence, speakup can now be compiled as a separate module which can be loaded only when necessary (blind people). Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.6.24 speakup
Hello, Otavio Salvador, le Tue 25 Mar 2008 15:06:58 -0300, a écrit : Samuel Thibault [EMAIL PROTECTED] writes: Mario Lang, le Tue 25 Mar 2008 17:28:32 +0100, a écrit : Samuel Thibault [EMAIL PROTECTED] writes: (speakup can now be compiled fully independently) linux-modules-extra-2.6 seems like the perfect place for speakup, now that it does not require the kernel to be patched anymore. Well, a small patch is still needed, but it just boils down to GPL-exporting 4 symbols, and that is already in the -mm tree, so backporting it to the debian kernel shouldn't be a problem.. It would be nice if you could talk to Debian Kernel Team (just added it to cc list) Oh, right, it was still not included. and see if this could be added for next 2.6.24 upload or later. That would allow the module to be build from linux-modules-extra-2.6 and later to be added to d-i if needed. Basically, all is needed is to git clone http://linux-speakup.org/speakup.git Apply patches/kernel-integration-2.6.24-source.patch to the main kernel source to GPL-export 4 symbols, and then run make $(cat allmodules.mk) SUBDIRS=$PWD -C /some/where/linux-whatever from src/ Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.6.24 speakup
maximilian attems, le Tue 25 Mar 2008 20:13:30 +0100, a écrit : On Tue, Mar 25, 2008 at 06:50:01PM +, Samuel Thibault wrote: Samuel Thibault, le Tue 25 Mar 2008 18:39:54 +, a écrit : Apply patches/kernel-integration-2.6.24-source.patch to the main kernel source to GPL-export 4 symbols, Note: by that, I mean to pick that patch into the regular linux-2.6 kernel. That patch is already in the -mm tree actually. once it is in next in next? we can maybe backport, other wise we'll just pick it up when merged. Ah, but it will probably not happen before 2.5.26 since it didn't make it into 2.5.25, whose window is closed since a long time now. 2.6.24 window is closed anyway. You mean the upstream or the Debian? Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.6.24 speakup
Hello, Bastian Blank, le Tue 25 Mar 2008 21:22:25 +0100, a écrit : On Tue, Mar 25, 2008 at 06:39:54PM +, Samuel Thibault wrote: make $(cat allmodules.mk) SUBDIRS=$PWD -C /some/where/linux-whatever First: s/SUBDIRS/M/. Oh, right. | $ make -C /usr/src/linux-headers-2.6.24-1-powerpc M=$(pwd) $(cat allmodule.mk) | make: Entering directory `/usr/src/linux-headers-2.6.24-1-powerpc' | CC [M] /home/waldi/linux/speakup/src/synth.o | /home/waldi/linux/speakup/src/synth.c:20:58: error: asm-ppc/pc_serial.h: No such file or directory | make[1]: *** [/home/waldi/linux/speakup/src/synth.o] Error 1 | make: *** [_module_/home/waldi/linux/speakup/src] Error 2 | make: Leaving directory `/usr/src/linux-headers-2.6.24-1-powerpc' asm-ppc is so legacy that this hurts. Oh, right, I could not test non-x86 archs myself. I've pushed a fix. Thanks, Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.6.24 speakup
Frans Pop, le Tue 25 Mar 2008 21:40:24 +0100, a écrit : On Tuesday 25 March 2008, Samuel Thibault wrote: It is not part of the upstream kernel. OK. I misunderstood that. My apologies. No problem. Anyway, it still needs to be included in linux-2.6 and l-e-m before we can really discuss inclusion in the installer. Yes, sure. Having it in l-m-e should not be a problem for us. We already do have other modules (loop-aes and squashfs) we take from that. Ok, leaving the debian-boot Cc for now then. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.6.24 speakup
Frans Pop, le Tue 25 Mar 2008 20:44:03 +0100, a écrit :
The idea is not to compile speakup built into the kernel, but just as a
module, and then it doesn't need to be integrated to the kernel build
system,
Compiling it into the kernel is not what I'm talking about. It definitely
should be built as a module, but as it is part of the upstream kernel,
It is not part of the upstream kernel.
but just be compiled separately, just like exmap, ndiswrapper, spca5xx
etc.
The reason they are in linux-modules extra is exactly because they are _not_
included in the official upstream kernel source, and thus need to be in a
different source package.
If you wanted speakup to be in linux-modules-extra, you should not have sent
your patches to lkml for inclusion...
Speakup didn't got to lkml for inclusion. Only the notifier part did,
and it's now available in Debian. The few still needed export symbols
didn't get through however, so a very light patch is still needed (see
attachement).
Samuel
diff --git a/drivers/char/consolemap.c b/drivers/char/consolemap.c
index 4b3916f..37c7980 100644
--- a/drivers/char/consolemap.c
+++ b/drivers/char/consolemap.c
@@ -277,6 +277,7 @@
return p-inverse_translations[m][glyph];
}
}
+EXPORT_SYMBOL_GPL(inverse_translate);
static void update_user_maps(void)
{
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -111,6 +111,8 @@
struct kbd_struct kbd_table[MAX_NR_CONSOLES];
+EXPORT_SYMBOL_GPL(kbd_table);
static struct kbd_struct *kbd = kbd_table;
+EXPORT_SYMBOL_GPL(kd_mksound);
struct vt_spawn_console vt_spawn_con = {
.lock = __SPIN_LOCK_UNLOCKED(vt_spawn_con.lock),
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -3934,6 +3934,7 @@
c |= 0x100;
return c;
}
+EXPORT_SYMBOL_GPL(screen_glyph);
/* used by vcs - note the word offset */
unsigned short *screen_pos(struct vc_data *vc, int w_offset, int viewed)
Re: kernel 2.6.24 speakup
maximilian attems, le Tue 25 Mar 2008 23:27:14 +0100, a écrit : On Tue, Mar 25, 2008 at 07:43:47PM +, Samuel Thibault wrote: maximilian attems, le Tue 25 Mar 2008 20:13:30 +0100, a écrit : once it is in next in next? next is the linux tree of things that are ready for the next merge window aka 2.6.26 now. Ok. 2.6.24 window is closed anyway. You mean the upstream or the Debian? debian Ah, so since Lenny's d-i is supposed to use 2.6.24, speakup won't make it into it :/ Thanks for the info anyway, Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.6.24 speakup
Hello, maximilian attems, le Wed 26 Mar 2008 14:58:57 +0100, a écrit : On Tue, 25 Mar 2008, Samuel Thibault wrote: Ah, so since Lenny's d-i is supposed to use 2.6.24, speakup won't make it into it :/ as otavio said we gonna release with 2.6.24 for debian 2.6.24 stuff would have to go through the stable releases. 7 out of 9 hunks FAILED -- saving rejects to file drivers/char/keyboard.c.rej 12 out of 16 hunks FAILED -- saving rejects to file drivers/char/vt.c.rej 1 out of 2 hunks FAILED -- saving rejects to file include/linux/keyboard.h.rej 1 out of 1 hunk FAILED -- saving rejects to file include/linux/notifier.h.rej 1 out of 1 hunk FAILED -- saving rejects to file include/linux/vt.h.rej (+) FAIL notifier-integration.patch notifier-integration.patch taken from HEAD 465da369435f5dc853656bb01731c59759d0a5e2 Little wonder you get so many failures: you don't need to apply that patch: keyboard/vt notifiers are _already_ in 2.6.24 kernels. Again, the only patch you need to apply to 2.6.24 is speakup/patches/kernel-integration-2.6.24-source.patch and then you can compile speakup as an independant module from the src/ directory. No need to fetch other patches like the one below it'be nice if your git repo would feature a gitweb and a git server. anyway the -mm patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc5/2.6.25-rc5-mm1/broken-out/input-put-ledstate-in-the-keyboard-notifier.patch seems to apply fine for 2.6.25, but has none of the wanted exports. It indeed isn't needed at all for speaup. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.6.24 speakup
maximilian attems, le Wed 26 Mar 2008 14:58:57 +0100, a écrit : anyway the -mm patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc5/2.6.25-rc5-mm1/broken-out/input-put-ledstate-in-the-keyboard-notifier.patch seems to apply fine for 2.6.25, but has none of the wanted exports. BTW, the patch that adds the export is basic-braille-screen-reader-support.patch Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.6.24 speakup
maximilian attems, le Thu 27 Mar 2008 17:13:58 +0100, a écrit :
On Thu, Mar 27, 2008 at 03:39:42PM +0100, Samuel Thibault wrote:
maximilian attems, le Wed 26 Mar 2008 14:58:57 +0100, a écrit :
anyway the -mm patch
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc5/2.6.25-rc5-mm1/broken-out/input-put-ledstate-in-the-keyboard-notifier.patch
seems to apply fine for 2.6.25, but has none of the wanted exports.
BTW, the patch that adds the export is
basic-braille-screen-reader-support.patch
i have head ache today, so i'll keep it short.
it would be great if this messy thread comes to some result.
the braille module itself unless merged would be in
linux-modules-extra. does it still need a specific patch in linux-2.6
itself for 2.6.25 and if yes please point to the mm one instead
of letting people fish in the dark, thanks :)
Erf, it looks like I've brought even more confusion with that braille
patch. I'll try to be clearly sum up:
- Vanilla 2.6.24 has keyboard/VT notifier support
- both braille module and speakup need additional 4 exports to work
- to get braille module in -mm, I had to stuff the 4 exports in its
patch
Now, I was not talking about importing the whole braille module patch
into the debian kernel, but just the 4 exports, so that speakup can be
compiled as modules. So
- either (as I originally said in the thread) apply Speakup's
speakup/patches/kernel-integration-2.6.24-source.patch ,
- or use the equivalent exerpt of the -mm braille patch, attached to
this mail.
and then speakup can be compiled as separate modules in
linux-modules-extra.
Samuel
diff -puN drivers/char/consolemap.c~basic-braille-screen-reader-support
drivers/char/consolemap.c
--- a/drivers/char/consolemap.c~basic-braille-screen-reader-support
+++ a/drivers/char/consolemap.c
@@ -277,6 +277,7 @@ u16 inverse_translate(struct vc_data *co
return p-inverse_translations[m][glyph];
}
}
+EXPORT_SYMBOL_GPL(inverse_translate);
static void update_user_maps(void)
{
diff -puN drivers/char/keyboard.c~basic-braille-screen-reader-support
drivers/char/keyboard.c
--- a/drivers/char/keyboard.c~basic-braille-screen-reader-support
+++ a/drivers/char/keyboard.c
@@ -109,6 +109,7 @@ const int max_vals[] = {
const int NR_TYPES = ARRAY_SIZE(max_vals);
struct kbd_struct kbd_table[MAX_NR_CONSOLES];
+EXPORT_SYMBOL_GPL(kbd_table);
static struct kbd_struct *kbd = kbd_table;
struct vt_spawn_console vt_spawn_con = {
@@ -259,6 +260,7 @@ void kd_mksound(unsigned int hz, unsigne
} else
kd_nosound(0);
}
+EXPORT_SYMBOL_GPL(kd_mksound);
/*
* Setting the keyboard rate.
diff -puN drivers/char/vt.c~basic-braille-screen-reader-support
drivers/char/vt.c
--- a/drivers/char/vt.c~basic-braille-screen-reader-support
+++ a/drivers/char/vt.c
@@ -4003,6 +4003,7 @@ u16 screen_glyph(struct vc_data *vc, int
c |= 0x100;
return c;
}
+EXPORT_SYMBOL_GPL(screen_glyph);
/* used by vcs - note the word offset */
unsigned short *screen_pos(struct vc_data *vc, int w_offset, int viewed)
Re: kernel 2.6.24 speakup
maximilian attems, le Thu 27 Mar 2008 21:13:49 +0100, a écrit : On Thu, 27 Mar 2008, Samuel Thibault wrote: Erf, it looks like I've brought even more confusion with that braille patch. I'll try to be clearly sum up: - Vanilla 2.6.24 has keyboard/VT notifier support - both braille module and speakup need additional 4 exports to work ok understood, thanks :) Now, I was not talking about importing the whole braille module patch into the debian kernel, but just the 4 exports, so that speakup can be compiled as modules. So - either (as I originally said in the thread) apply Speakup's speakup/patches/kernel-integration-2.6.24-source.patch , - or use the equivalent exerpt of the -mm braille patch, attached to this mail. cool applies fine to 2.6.25-rc7, add to current linux-2.6 trunk. will be in the next 2.6.25 upload, that can be expected soon. Cool, thanks! Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486394: linux-modules-extra-2.6: Please add speakup modules
Package: linux-modules-extra-2.6 Severity: wishlist Tags: patch Hello, As discussed on the linux-boot and linux-kernel mailing lists, for accessibility purpose it would be useful to have speakup modules compiled for the debian installer, and thus to add them to linux-modules-extra-2.6. Here is a patch that does so. Cheers, Samuel -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'oldstable'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Index: speakup/copyright === --- speakup/copyright (révision 0) +++ speakup/copyright (révision 0) @@ -0,0 +1,6 @@ +Copyright: + + Speakup is licensed under the GPL; the GNU General Public License. + +On Debian systems, the complete text of the GNU General Public License +can be found in `/usr/share/common-licenses/GPL'. Index: speakup/rules === --- speakup/rules (révision 0) +++ speakup/rules (révision 0) @@ -0,0 +1,7 @@ +$(BUILD_STAMP): + $(MAKE) -C $(HEADERS_DIR) M=$(CURDIR)/$(DIR)/src $(JOBS_ARG) `cat $(CURDIR)/$(DIR)/src/allmodule.mk` + touch $@ + +install: LIB_MODULES = $(PACKAGE_DIR)/lib/modules/$(REAL_VERSION) +install: + $(MAKE) -C $(HEADERS_DIR) M=$(CURDIR)/$(DIR)/src modules_install INSTALL_MOD_PATH=$(PACKAGE_DIR) INSTALL_MOD_DIR=extra/$(MODULE) `cat $(CURDIR)/$(DIR)/src/allmodule.mk` Index: speakup/defines === --- speakup/defines (révision 0) +++ speakup/defines (révision 0) @@ -0,0 +1,7 @@ +[base] +not-featuresets: smp +desc: A screen review module for the Linux kernel +longdesc: + Speakup allows you to interact with applications and the GNU/Linux + operating system with audible feedback from the console using a + synthetic speech device. Index: defines === --- defines (révision 11250) +++ defines (copie de travail) @@ -14,6 +14,7 @@ r6040 redhat-cluster sfc + speakup squashfs tp-smapi unionfs
Bug#486394: linux-modules-extra-2.6: Please add speakup modules
Hello, Daniel Baumann, le Mon 16 Jun 2008 08:56:56 +0200, a écrit : As discussed on the linux-boot and linux-kernel mailing lists, for accessibility purpose it would be useful to have speakup modules compiled for the debian installer, and thus to add them to linux-modules-extra-2.6. Here is a patch that does so. good, but don't override rules, please fix your module-source package instead. Mmm, well, the speakup-source package builds fine via module-assistant, and I had to override the rules because it looked like linux-module-extra is using the upstream packages' non-existing top-level Makefile instead of the speakup-source -provided rules. Should I add a toplevel Makefile in the upstream source, or is there something else to be done to make linux-modules-extra use speakup-source's rules, or to direct it to speakup's src/ path? Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486394: linux-modules-extra-2.6: Please add speakup modules
Daniel Baumann, le Mon 16 Jun 2008 12:07:05 +0200, a écrit : Samuel Thibault wrote: Should I add a toplevel Makefile in the upstream source yes Ok, we have uploaded a new version of speakup-source, here is the fixed patch. Samuel Index: speakup/copyright === --- speakup/copyright (r�vision 0) +++ speakup/copyright (r�vision 0) @@ -0,0 +1,6 @@ +Copyright: + + Speakup is licensed under the GPL; the GNU General Public License. + +On Debian systems, the complete text of the GNU General Public License +can be found in `/usr/share/common-licenses/GPL'. Index: speakup/defines === --- speakup/defines (r�vision 0) +++ speakup/defines (r�vision 0) @@ -0,0 +1,6 @@ +[base] +desc: A screen review module for the Linux kernel +longdesc: + Speakup allows you to interact with applications and the GNU/Linux + operating system with audible feedback from the console using a + synthetic speech device. Index: defines === --- defines (r�vision 11250) +++ defines (copie de travail) @@ -19,3 +19,4 @@ unionfs virtualbox-ose virtualbox-ose-guest + speakup
Bug#486394: closed by Daniel Baumann [EMAIL PROTECTED] (Bug#486394: fixed in linux-modules-extra-2.6 2.6.25-3)
Hello, Debian Bug Tracking System, le Sun 22 Jun 2008 00:05:30 +, a écrit : #486394: linux-modules-extra-2.6: Please add speakup modules It has been closed by Daniel Baumann [EMAIL PROTECTED]. Cool, thanks! It looks like it doesn't compile yet at least on arm* and sparc. We'll try to fix that upstream. In the meanwhile we can disable it on those archs, as the attached patch does. Samuel Index: speakup/defines === --- speakup/defines (révision 11683) +++ speakup/defines (copie de travail) @@ -1,4 +1,5 @@ [base] +arches: alpha amd64 hppa i386 ia64 m68k mips mipsel powerpc s390 desc: screen review module longdesc: Speakup allows you to interact with applications and Linux with audible
Bug#377350: linux-modules-2.6.16-2-xen-686_2.6.16-15 depends on initramfs-tools
Hi, James Harper, le Sat 08 Jul 2006 23:02:57 +1000, a écrit : linux-modules-2.6.16-2-xen-686 only contains modules for xen domains, and should not require any initrd or initramfs tools. Mmm, but for dom0 you need to build an initrd. And BTW, IMHO that should be automatically done when installing it, juste like with other linux images. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377350: linux-modules-2.6.16-2-xen-686_2.6.16-15 depends on initramfs-tools
James Harper, le Tue 18 Jul 2006 13:22:36 +1000, a écrit : Hi, James Harper, le Sat 08 Jul 2006 23:02:57 +1000, a écrit : linux-modules-2.6.16-2-xen-686 only contains modules for xen domains, and should not require any initrd or initramfs tools. Mmm, but for dom0 you need to build an initrd. Yes, but you'd solve that by making initramfs a dependency of the kernel image, not the modules, same as for any other (non-xen) kernel. Ah yes, indeed. And BTW, IMHO that should be automatically done when installing it, juste like with other linux images. Yes, I was bitten by the fact that there was no initrd, do you know if there is a reason why one wasn't generated? I don't, but I'm not maintainer :) And this along the merge of grub's patch for having update-grub work fine with xen kernels would result to a very easy way to setup xen. Samuel
Bug#385574: Dom0 crashes with linux-image-2.6.16-2-xen-686
Hi, Same problem here, version 2.6.16-18 gets the same trace as posted to the bug before. Version 2.6.16-16 works fine. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386674: Dom0 crashes with linux-image-2.6.17-2-xen-686=2.6.17-8
Package: linux-image-2.6.17-2-xen-686 Version: 2.6.17-8 Severity: important Hi, I can't boot linux-image-2.6.17-2-xen-686=2.6.17-8 as Dom0 with hypervisor xen-hypervisor-3.0-i386=3.0.2+hg9697-2. I get a crash very early (seemingly before Linux prints anything). Unfortunately, I don't have any mean to get the output: the last thing I can see is the Guest stack trace, full of . Regards, Samuel -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-xen-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages linux-image-2.6.17-2-xen-686 depends on: ii initramfs-tools 0.77b tools for generating an initramfs ii linux-modules-2.6.17-2-xen-68 2.6.17-8 Linux 2.6.17 modules on PPro/Celer Versions of packages linux-image-2.6.17-2-xen-686 recommends: ii libc6-xen2.3.6.ds1-4 GNU C Library: Shared libraries [X -- no debconf information -- Samuel Thibault [EMAIL PROTECTED] $ du temp.iso 2,0Ttemp.iso $ ls temp.iso -l -r-xr-xr-x1 samy thibault 16E 2003-03-22 14:44 temp.iso* -+- je vous dirai pas la marque de mon disque dur, na :p -+- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386674: closed by Bastian Blank [EMAIL PROTECTED] (Re: Bug#386674: Dom0 crashes with linux-image-2.6.17-2-xen-686=2.6.17-8)
Debian Bug Tracking System, le Sat 09 Sep 2006 04:49:16 -0700, a écrit : On Sat, Sep 09, 2006 at 12:45:04PM +0200, Samuel Thibault wrote: I can't boot linux-image-2.6.17-2-xen-686=2.6.17-8 as Dom0 with hypervisor xen-hypervisor-3.0-i386=3.0.2+hg9697-2. This versions are not compatible for a dom0. Ah. But which kernel package should I use then? Samuel
reassign 498205 to linux-2.6, reassign 497568 to linux-2.6, reassign 494374 to linux-2.6 ...
# Automatically generated email from bts, devscripts version 2.10.35 reassign 498205 linux-2.6 reassign 497568 linux-2.6 reassign 494374 linux-2.6 forcemerge 498205 497568 494374 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404503: Wrong characters typed using dead keys
reassign 404503 kbd
clone 404503 -1
reassign -1 console-tools
thanks
Pavel Vávra, le Fri 17 Oct 2008 23:18:14 +0200, a écrit :
(1) unmaintained console-tools exist in lenny and this package is installed
by default
And kbd doesn't yet include the patch anyway...
http://bugzilla.kernel.org/attachment.cgi?id=12359
Attached is a console-tools port of the patch, could you please check
that it works? You should just need to
$ apt-get source console-tools
$ sudo apt-get build-dep console-tools
$ cd console-tools-version
$ ./debian/rules stampdir/patchapply
$ (cd build-tree/console-tools-version ; patch -p1 ~/patch-console-tools)
$ fakeroot ./debian/rules binary-arch
and install console-tools_version_arch.deb
Samuel
diff -ur console-tools-0.2.3-orig/include/lct/ksyms.h
console-tools-0.2.3/include/lct/ksyms.h
--- console-tools-0.2.3-orig/include/lct/ksyms.h2008-12-01
23:48:27.0 +0100
+++ console-tools-0.2.3/include/lct/ksyms.h 2008-12-01 23:54:50.0
+0100
@@ -21,6 +21,7 @@
extern const int charsets_size;
extern int set_charset(const char *name);
+extern const char *chosen_charset;
extern int add_number(int code);
extern int add_capslock(int code);
extern const char *codetoksym(int code);
diff -ur console-tools-0.2.3-orig/kbdtools/loadkeys.y
console-tools-0.2.3/kbdtools/loadkeys.y
--- console-tools-0.2.3-orig/kbdtools/loadkeys.y2008-12-01
23:48:27.0 +0100
+++ console-tools-0.2.3/kbdtools/loadkeys.y 2008-12-01 23:56:36.0
+0100
@@ -70,6 +70,7 @@
#include linux/keyboard.h
#include sys/ioctl.h
#include ctype.h
+#include iconv.h
#include sysexits.h
#include signal.h
@@ -111,7 +112,11 @@
/* the kernel structures we want to set or print */
u_short *key_map[MAX_NR_KEYMAPS];
char *func_table[MAX_NR_FUNC];
+#ifdef KDSKBDIACRUC
+struct kbdiacruc accent_table[MAX_DIACR];
+#else
struct kbdiacr accent_table[MAX_DIACR];
+#endif
unsigned int accent_table_size = 0;
char key_is_constant[512]; // 512 == Max. value of NR_KEYS across kernels =
2.6.1
@@ -692,7 +697,7 @@
static void compose(int diacr, int base, int res)
{
- struct kbdiacr *p;
+ typeof(*accent_table) *p;
if (accent_table_size == MAX_DIACR)
{
fprintf(stderr, _(compose table overflow\n));
@@ -860,11 +865,80 @@
return ct;
}
+#ifdef KDSKBDIACRUC
+static wchar_t convert_char(iconv_t conv, unsigned char c) {
+ wchar_t wc;
+ char *i = (void*)c;
+ size_t is = sizeof(c);
+ char *o = (void*)wc;
+ size_t os = sizeof(wc);
+ if (iconv(conv, i, is, o, os) == (size_t) -1) {
+ perror(iconv);
+ fprintf(stderr, _(Couldn't convert character %u from charset %s to
unicode\n), c, chosen_charset);
+ wc = 0;
+ }
+ return wc;
+}
+static int
+defdiacsuc(int fd){
+struct kbdiacrsuc kd;
+ int i;
+ iconv_t conv;
+
+ if (!chosen_charset)
+ return 0;
+
+ kd.kb_cnt = accent_table_size;
+ if (kd.kb_cnt MAX_DIACR) {
+ kd.kb_cnt = MAX_DIACR;
+ fprintf(stderr, _(too many compose definitions\n));
+ }
+ conv = iconv_open(WCHAR_T, chosen_charset);
+ if (conv == (iconv_t)(-1)) {
+ perror(iconv_open);
+ fprintf(stderr, _(Can't convert from charset %s to unicode\n),
chosen_charset);
+ return 0;
+ }
+ for (i = 0; i kd.kb_cnt; i++) {
+ wchar_t wc;
+ wc = convert_char(conv, accent_table[i].diacr);
+ if (!wc)
+ goto err;
+ kd.kbdiacruc[i].diacr = wc;
+ wc = convert_char(conv, accent_table[i].base);
+ if (!wc)
+ goto err;
+ kd.kbdiacruc[i].base = wc;
+ wc = convert_char(conv, accent_table[i].result);
+ if (!wc)
+ goto err;
+ kd.kbdiacruc[i].result = wc;
+ }
+
+ if(ioctl(fd, KDSKBDIACRUC, (unsigned long) kd)) {
+ if (errno == EINVAL)
+ return 0;
+ perror(KDSKBDIACR);
+ exit(1);
+ }
+ return kd.kb_cnt;
+err:
+ iconv_close(conv);
+ return 0;
+}
+
+#endif
static int defdiacs(int fd)
{
struct kbdiacrs kd;
unsigned i;
+#ifdef KDSKBDIACRUC
+ int cnt = defdiacsuc(fd);
+ if (cnt)
+return cnt;
+#endif
+
kd.kb_cnt = accent_table_size;
if (kd.kb_cnt MAX_DIACR)
{
@@ -872,7 +946,11 @@
fprintf(stderr, _(too many compose definitions\n));
}
for (i = 0; i kd.kb_cnt; i++)
- kd.kbdiacr[i] = accent_table[i];
+{
+ kd.kbdiacr[i].diacr = accent_table[i].diacr;
+ kd.kbdiacr[i].base = accent_table[i].base;
+ kd.kbdiacr[i].result = accent_table[i].result;
+}
if(ioctl(fd, KDSKBDIACR, (unsigned long) kd))
{
diff -ur console-tools-0.2.3-orig/lib/ksyms.c console-tools-0.2.3/lib/ksyms.c
--- console-tools-0.2.3-orig/lib/ksyms.c2008-12-01 23:48:27.0
+0100
+++ console-tools-0.2.3/lib/ksyms.c
Bug#252335: tc filter ls .. makes a kernel oops
Hi, Isn't the bug resolved ? The proposed patch is now in 2.4.27... Regards, Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486394: closed by Daniel Baumann [EMAIL PROTECTED] (Bug#486394: fixed in linux-modules-extra-2.6 2.6.25-3)
Ah, the previous module failure in s390 masked a speakup failure so that arch should be disabled for now too. Alpha compiled fine, however. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492293: linux-modules-extra-2.6: Please add arm* and sparc compilation of speakup
Package: linux-modules-extra-2.6 Version: 2.6.25-5 Severity: normal Hello, Thanks to porters testing, version 3.0.3+git20080724.dfsg.1-1 of speakup-source should now compile fine on arm* and sparc archs. Could you please re-enable compilation for them in next upload? s390 remains a no-go, however, so it needs to be kept ruled out. Samuel -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'oldstable'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18.8 (SMP w/1 CPU core) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498205: perhaps a patch already in bugzilla.kernel.org
Hello, It got applied in Linus' tree. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Speakup modules in squeeze
Hello, Ben Hutchings, le Wed 14 Oct 2009 01:54:47 +0100, a écrit : There is a big problem with the current linux-modules-extra-2.6 package, which is that the resulting binary packages are related to their source only by build-dependency, and this does not ensure that corresponding source and binary packages are kept released together. Yes, that was a source of confusion for the users too. Those modules that may be needed at installation time will be added to the linux-2.6 package, and the speakup modules are clearly among those. I have added patches that put them under drivers/staging: svn://svn.debian.org/svn/kernel/dists/trunk/linux-2.6/debian/patches/features/all/speakup/ Please review these So speakup-add.patch would always be a mere copy of speakup-source? Speakup-kbuild.patch seems just right and will probably never have to change. and let the kernel team know whenever speakup needs to be updated. Mmm, couldn't linux-2.6 build-depend on speakup-source and just automatically import the source from there? Currently staging drivers are only built for x86 because many of them are not really portable. I think this is not the case for speakup, so let me know if it should be built for more architectures. Speakup should build and work on basically all archs (it was tested on both 32 and 64bit platforms, and both little and big endians). Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Speakup modules in squeeze
Ben Hutchings, le Wed 14 Oct 2009 03:52:20 +0100, a écrit : On Wed, 2009-10-14 at 03:12 +0200, Samuel Thibault wrote: [...] Those modules that may be needed at installation time will be added to the linux-2.6 package, and the speakup modules are clearly among those. I have added patches that put them under drivers/staging: svn://svn.debian.org/svn/kernel/dists/trunk/linux-2.6/debian/patches/features/all/speakup/ Please review these So speakup-add.patch would always be a mere copy of speakup-source? Yes, or you could drop speakup-source. Speakup-kbuild.patch seems just right and will probably never have to change. and let the kernel team know whenever speakup needs to be updated. Mmm, couldn't linux-2.6 build-depend on speakup-source and just automatically import the source from there? No, that just moves the problem we have now to linux-2.6. Ok, so basically speakup could now only contain the tools and we'll push the kernel modules as needed to linux-2.6 itself. I think we should still keep speakup-source for people who are compiling their own vanilla kernel or such. Thanks, Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: speakup in Debian kernel and installer
Hello, Ben Hutchings, le Tue 24 Aug 2010 00:35:03 +0100, a écrit : [Please include debian-kernel or me in replies; I'm not subscribed to -accessibility.] I haven't seen any bug reports regarding speakup drivers included in the Linux 2.6.32 kernel packages or testing versions of the installer. However I haven't seen any positive reports either. Are they working properly? I've tried the daily build yesterday, and it worked just fine. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100824011105.gv4...@const.famille.thibault.fr
Bug#594089: keyboard-configuration: caps lock keycode problem
Hello, Tom Vier, le Thu 02 Sep 2010 15:11:49 -0400, a écrit : It says UNICODE mode and the codes for caps lock are: press: 0x3a 0xe0 0x66 repeat: 0x3a release: 0xba 0xe0 0x 0xe6 I guess? I also just discovered the right shift key goes back a page in iceweasel. Here are the right-shift codes: showkey -s: press: 0x36 0xe0 0x6a repeat: 0x36 release: 0xb6 0xe0 0xea All this looks like one of the few keyboard glitches that linux-2.6 fixes for some keyboards known to be bogus, while other keyboards do use these scancodes to report e.g. multimedia keys. Could you try showkey -s with the older, working kernel? Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100902194630.gh5...@const.famille.thibault.fr
Bug#594089: keyboard-configuration: caps lock keycode problem
Tom Vier, le Fri 03 Sep 2010 16:35:47 -0400, a écrit : On 09/02/2010 03:46 PM, Samuel Thibault wrote: Hello, Tom Vier, le Thu 02 Sep 2010 15:11:49 -0400, a écrit : It says UNICODE mode and the codes for caps lock are: press: 0x3a 0xe0 0x66 repeat: 0x3a release: 0xba 0xe0 0x 0xe6 I guess? Yes. I also just discovered the right shift key goes back a page in iceweasel. Here are the right-shift codes: showkey -s: press: 0x36 0xe0 0x6a repeat: 0x36 release: 0xb6 0xe0 0xea All this looks like one of the few keyboard glitches that linux-2.6 fixes for some keyboards known to be bogus, while other keyboards do use these scancodes to report e.g. multimedia keys. Could you try showkey -s with the older, working kernel? Stable (2.6.26) which worked fine gives the same as Testing (2.6.32): When you say Stable, you mean both kernel and Xorg? Could you also run xev on your stable box? press: 0x3a 0xe0 0x66 repeat: 0x3a release: 0xba 0xe0 0xe6 ...which makes me think it's an xorg problem, but I'm not familiar with how the whole keyboard stack works. It's a big mess :) I wonder why the logitech generates so many codes. It looks to me like a keyboard bug. Do you see any pattern, e.g. does the left shift key produce one too? Do the keys which do produce extra scancodes form any particular shape on the keyboard? Such bug should probably be fixed in the kernel, just like it is already in atkbd.c for some keyboards. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100903234552.gk5...@const
Bug#594089: keyboard-configuration: caps lock keycode problem
Tom, le Mon 23 Aug 2010 11:43:53 -0400, a écrit : The model name is logimel, which is set in both /etc/default/keyboard and /etc/X11/xorg.conf. Which explains why Xorg has the behavior you describe: the logimel model includes the logitech base, which includes the common navigation keys, which makes XF86Back from 0xe0 0x6a, and XF86Favorites from 0xe0 0x66. Do you actually have navigation keys on your keyboard? I'm afraid we'll just have to blacklist it in the usb driver according to the usb ID. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100903235540.ga9...@const
Bug#612105: qemu-kvm: hangs and irq timeout unless -no-kvm-irqchip passed
Hello, Jonathan Nieder, le Thu 24 Mar 2011 05:40:34 -0500, a écrit : Jonathan Nieder wrote: When I boot the HURD without passing -no-kvm-irqchip on the command line, the system usually will print hd2: irq timeout: status=0x50 hd2: irq timeout: status=0x50 hd2: irq timeout: status=0x50 hd2: unexpected_intr: status=0x58 [and so on] Fix (for the KVM host) merged to linus's master as part of kvm-updates/2.6.39, as a commit named 7049467b (KVM: remove isr_ack logic from PIC, 2011-02-09). So v2.6.39 will fix this. Great! Thanks for the notice! Do you happen to know which version the bug was introduced it? Hope that helps, Sure! Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110324105538.gm5...@const.bordeaux.inria.fr
Bug#612105: qemu-kvm: hangs and irq timeout unless -no-kvm-irqchip passed
Jonathan Nieder, le Thu 24 Mar 2011 05:58:47 -0500, a écrit : [1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/58669/focus=67483 Cool! Thanks for having handled this. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110324121547.gp5...@const.bordeaux.inria.fr
Bug#594089: keyboard-configuration: caps lock keycode problem
Tom Vier, le Tue 07 Sep 2010 12:32:19 -0400, a écrit : I have bunch of extra keys. 8) It's one of those internet keyboards with keys for: email sms webcam itouch search shipping home favorites, plus volume, track skip, play/pause, record. So there indeed is a favorites key, that makes it hard to blacklist its events. I guess it works on testing but not on stable? Would you be able to test the keyboard on windows? I'm starting to wonder whether your keyboard might just have become dirty and you didn't realize it because on stable favorites and back don't work by default anyway. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100907200144.gc4...@const.famille.thibault.fr
Bug#594089: keyboard-configuration: caps lock keycode problem
Tom Vier, le Tue 07 Sep 2010 12:28:24 -0400, a écrit : Such bug should probably be fixed in the kernel, just like it is already in atkbd.c for some keyboards. Samuel Showkey looks almost identical between kernels tho. Yes, but the bug is actually in the keyboard, not in the kernel or in Xorg: they're just obeying the keyboard. The best place to fix it is thus the component that drives it. The difference between stable and testing is that testing now uses evdev by default, which doesn't need setkeycodes invocations to get multimedia keys working. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100907202639.gt4...@const.famille.thibault.fr
Re: Sending speakup upstream
Hello, Apparently your mail isn't getting to the speakup mailing list for some reason, so I'm trying to forward it: Ben Hutchings, le Fri 10 Sep 2010 04:44:59 +0100, a écrit : I'm a member of the Debian Linux kernel team. We have a general policy that any features added to the kernel package should already have been accepted for inclusion in some later upstream version of Linux. If a driver has not been accepted then it should be packaged separately. We have made an exception for speakup so that it can be used during installation, but we do not want to carry this patch indefinitely. I talked to Greg Kroah-Hartman about this briefly and he would welcome a submission of speakup for inclusion under 'staging'. Is there any reason not to do this? One issue still pending is that speakup pokes the serial i/o ports itself, but apart from that it could be a good idea, yes. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100911213442.gy5...@const.famille.thibault.fr
Bug#594089: keyboard-configuration: caps lock keycode problem
The short story is: Tom's keyboard sends all that when he presses caps lock: press: 0x3a 0xe0 0x66 repeat: 0x3a release: 0xba 0xe0 0xe6 0xe0 0x66 happens to be the favorites key on his keyboard with internet navigation keys. I thus believe there's a bug in his keyboard that needs to be filtered at the kernel level. The long story can be read on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594089 Tom Vier, le Mon 13 Sep 2010 14:07:29 -0400, a écrit : Here's xev from Stable. It looks like in Testing that some of the extra key codes that show up in showkey are getting interpreted as additional key presses in Testing's xorg but not Stable's. Yes, as I said in a previous mail, squeeze Xorg now interprets the internet scancodes by default, while it wouldn't in lenny and previous, thus not showing the bug. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101024144150.gv24...@const.famille.thibault.fr
Bug#594089: keyboard-configuration: caps lock keycode problem
Tom Vier, le Mon 25 Oct 2010 09:37:26 -0400, a écrit : On 10/25/2010 12:50 AM, Dmitry Torokhov wrote: On Sun, Oct 24, 2010 at 04:41:51PM +0200, Samuel Thibault wrote: The short story is: Tom's keyboard sends all that when he presses caps lock: press: 0x3a 0xe0 0x66 repeat: 0x3a release: 0xba 0xe0 0xe6 0xe0 0x66 happens to be the favorites key on his keyboard with internet navigation keys. I thus believe there's a bug in his keyboard that needs to be filtered at the kernel level. The long story can be read on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594089 Hmm, the question is whether the real favorites key send the same usage and the fake one after caps lock. Any chance Tom could locate evtest utility and see what MSC_SCAN events being emitted? Sure. Here's caps-lock: Event: time 1288013671.633008, -- Report Sync Event: time 1288013674.171812, type 4 (Misc), code 4 (ScanCode), value 70039 Event: time 1288013674.171853, type 1 (Key), code 58 (CapsLock), value 1 Event: time 1288013674.171862, -- Report Sync Event: time 1288013674.172210, type 17 (LED), code 1 (CapsLock), value 1 Event: time 1288013674.299553, type 4 (Misc), code 4 (ScanCode), value 70039 Event: time 1288013674.299580, type 1 (Key), code 58 (CapsLock), value 0 Event: time 1288013674.299593, -- Report Sync Right-shift (the other problem key): Event: time 1288013798.388025, -- Report Sync Event: time 1288013800.742088, type 4 (Misc), code 4 (ScanCode), value 700e5 Event: time 1288013800.742130, type 1 (Key), code 54 (RightShift), value 1 Event: time 1288013800.742142, -- Report Sync Event: time 1288013800.861777, type 4 (Misc), code 4 (ScanCode), value 700e5 Event: time 1288013800.861812, type 1 (Key), code 54 (RightShift), value 0 Event: time 1288013800.861824, -- Report Sync Could you also post results when pressing the favorite and the prev internet keys of your keyboard? Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101025180320.ga4...@const.famille.thibault.fr
Bug#594089: keyboard-configuration: caps lock keycode problem
Dmitry Torokhov, le Wed 27 Oct 2010 02:10:29 -0700, a écrit : Also, based on evtest data I only see presses/releases for one key (Caps Lock, Right Shift, etc.) I do not see the presses for the additional keys in the evtest stream so I am baffled as to where the additional scancode is coming from... Do you have some funky keymap loaded? Anything interesting in dumpkeys? Err, since the duplicates appear in scancodes already, is the content of dumpkeys really involved? Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101027120513.gt4...@const.famille.thibault.fr
Re: Bug#605009: serious performance regression with ext4
Mike Hommey, le Tue 30 Nov 2010 10:07:55 +0100, a écrit : On Mon, Nov 29, 2010 at 07:18:17AM +0100, Guillem Jover wrote: What's going on here? sync_file_range() is a Linux specific system call that has been around for a while. It allows program to control when writeback happens in a very low-level fashion. The first set of sync_file_range() system calls causes the system to start writing back each file once it has finished being extracted. It doesn't actually wait for the write to finish; it just starts the writeback. Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) instead, skimming over the kernel source seems to indicate it might end up doing more or less the same thing but in a portable way? On the other hand, there is no guarantee that other kernels do the same, Err, that's posix. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101130093511.ge9...@const.bordeaux.inria.fr
Bug#697709: pcspkr and snd-pcsp fighting
Jonathan Nieder, le Sat 19 Jan 2013 14:09:54 -0800, a écrit : Option 2 sounds reasonable. Actually yet another option sounds tempting: 3. Stop building snd-pcsp. Would that hurt accessibility? For people who don't know, snd-pcsp is a driver that uses the PC speaker in order to produce sound. So it would only be useful if you don't have a sound card at all, and don't mind the quite bad result that pcsp gets. Cc-ing debian-accessibility just to let anybody raise hand, but I don't think accessibility really needs it (I wonder what speech synthesis would look like with such driver). Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130119224814.gv5...@type.home
Bug#682368: linux: Please add snd-hda-codec-ca0132 to sound-modules
Package: linux Version: 3.5~ Severity: normal Tags: patch Hello, Linux 3.5 introduces a new HDA codec, please add it for d-i, as attached patch does. Samuel -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.0.4 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Samuel Thibault samuel.thiba...@fnac.net *** s has joined channel #ens-mim N re s pfff s mare de la pfp. s pas commencer et j'en ai deja marre. s bon ct juste un cou de gueule ++ *** s has left channel #ens-mim (s) -+- #ens-mim et la peufeupeu -+- Index: installer/modules/sound-modules === --- installer/modules/sound-modules (révision 19273) +++ installer/modules/sound-modules (copie de travail) @@ -64,6 +64,7 @@ snd-harmony ? snd-hda-codec-analog ? snd-hda-codec-ca0110 ? +snd-hda-codec-ca0132 ? snd-hda-codec-cirrus ? snd-hda-codec-cmedia ? snd-hda-codec-conexant ?
Bug#682368: linux: Please add snd-hda-codec-ca0132 to sound-modules
Ben Hutchings, le Sun 22 Jul 2012 15:53:01 +0100, a écrit : On Sun, 2012-07-22 at 15:07 +0900, Samuel Thibault wrote: Package: linux Version: 3.5~ Severity: normal Tags: patch Hello, Linux 3.5 introduces a new HDA codec, No, it's not new in 3.5: Oops, I've missed it in previous versions then. $ modinfo snd-hda-codec-ca0132 filename: /lib/modules/3.2.0-3-amd64/kernel/sound/pci/hda/snd-hda-codec-ca0132.ko description:Creative CA0132, CA0132 HD-audio codec license:GPL alias: snd-hda-codec-id:11020011 depends:snd-hda-codec,snd intree: Y vermagic: 3.2.0-3-amd64 SMP mod_unload modversions please add it for d-i, as attached patch does. Shouldn't this be done for wheezy/sid? Yes, otherwise blind people with such device will not have sound for speech synthesis. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120724020225.gg4...@type.ccs.tsukuba.ac.jp
Re: Bug#661379: debian-installer: Keyboard connected via Logitech Unifying sender/receiver stops working during installation
Christian PERRIER, le Mon 06 Aug 2012 08:27:56 +0200, a écrit : Dunno what the ? means It means not to fail if the module does not actually exist, which is useful when the availability depends on the arch. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120806101238.gd32...@type.famille.thibault.fr
Bug#685953: linux: crash on speakup goto operation
Package: linux
Version: 3.2.23-1
Severity: important
Tags: patch
Hello,
Speakup currently has a bug which can lead to a mere crash when using
its goto function:
You can reproduce the bug by pressing numpad_insert, numpad_asterisk.
As soon as you start typing a position, for instance 23y,
the system will crash.
The attached patch is the upstream fix for it. It'd be good to have it
for wheezy.
Samuel
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.0.4 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
Samuel Thibault samuel.thiba...@ens-lyon.org
Les roots ne sont plus ce qu'ils étaient...Maintenant il sont dioxinés,
c'est de la m... ! Avant on les élevaient avec du bon unix mais ça été
remplacé par des farines industrielles nouvelles technologies (NT).
-+- JdK in NPC : Exigez un root élevé sous la mère ! -+-
commit 4ea418b8b2fa8a70d0fcc8231b65e67b3a72984b
Author: Christopher Brannon ch...@the-brannons.com
Date: Sat Jun 16 16:55:20 2012 -0500
Staging: speakup: fix an improperly-declared variable.
A local static variable was declared as a pointer to a string
constant. We're assigning to the underlying memory, so it
needs to be an array instead.
Signed-off-by: Christopher Brannon ch...@the-brannons.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 92b34e2..40e2488 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -1854,7 +1854,7 @@ static void speakup_bits(struct vc_data *vc)
static int handle_goto(struct vc_data *vc, u_char type, u_char ch, u_short key)
{
- static u_char *goto_buf = \0\0\0\0\0\0;
+ static u_char goto_buf[8];
static int num;
int maxlen, go_pos;
char *cp;
Bug#686742: linux: speakup: lower default software speech rate
Package: linux
Version: 3.2.23-1
Severity: important
Tags: patch
Hello,
The following patch has been applied to greg's staging tree, it would be
important to get it into Wheezy, as it noticeably improves usability for
blind users.
Samuel
From cfd757010691eae4e17acc246f74e7622c3a2f05 Mon Sep 17 00:00:00 2001
From: Samuel Thibault samuel.thiba...@ens-lyon.org
Date: Sun, 26 Aug 2012 23:35:17 +0200
Subject: speakup: lower default software speech rate
Speech synthesis beginners need a low speech rate, and trained people
want a high speech rate. A medium speech rate is thus actually not a
good default for neither. Since trained people will typically know how
to change the rate, better default for a low speech rate, which
beginners can grasp and learn how to increase it afterwards
This was agreed with users on the speakup mailing list.
Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/staging/speakup/speakup_soft.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/speakup/speakup_soft.c
b/drivers/staging/speakup/speakup_soft.c
index 42cdafe..2a67610 100644
--- a/drivers/staging/speakup/speakup_soft.c
+++ b/drivers/staging/speakup/speakup_soft.c
@@ -46,7 +46,7 @@ static int misc_registered;
static struct var_t vars[] = {
{ CAPS_START, .u.s = {\x01+3p } },
{ CAPS_STOP, .u.s = {\x01-3p } },
- { RATE, .u.n = {\x01%ds, 5, 0, 9, 0, 0, NULL } },
+ { RATE, .u.n = {\x01%ds, 2, 0, 9, 0, 0, NULL } },
{ PITCH, .u.n = {\x01%dp, 5, 0, 9, 0, 0, NULL } },
{ VOL, .u.n = {\x01%dv, 5, 0, 9, 0, 0, NULL } },
{ TONE, .u.n = {\x01%dx, 1, 0, 2, 0, 0, NULL } },
--
1.7.10.130.g36e6c
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120905083350.ga9...@type.bordeaux.inria.fr
Bug#686742: linux: speakup: lower default software speech rate
Ben Hutchings, le Mon 10 Sep 2012 04:04:59 +0100, a écrit : But I looked at what exactly is done with this 'vars' table and... it looks really nasty. This goes into an initialisation string which will be the first thing the userland synthesiser gets when it reads the softsynth char device, right? Yes. However: 1. The last character of the init string will be repeated. 2. If the read() caller doesn't provide a big enough buffer for the init string, the next read() will get it again from the start, so it can never make progress. Indeed. Would you be able to test the attached patch, that should fix those bugs? It looks and works fine for me indeed. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120911002847.gi5...@type.youpi.perso.aquilenet.fr
Re: Nonexistent modules in Linux kernel-wedge configuration
Ben Hutchings, le Sun 29 Jan 2012 20:24:53 +, a écrit : brlvger modules/brltty-modules This is an oldie, removed in 2004. I'll drop it from kernel-wedge (it's not used anywhere any more). Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120129204147.gu4...@type.famille.thibault.fr
Re: Nonexistent modules in Linux kernel-wedge configuration
Ben Hutchings, le Sun 29 Jan 2012 20:24:53 +, a écrit : snd-dt019xmodules/sound-modules snd-es968 modules/sound-modules snd-hda-codec-atihdmi modules/sound-modules snd-hda-codec-intelhdmi modules/sound-modules snd-hda-codec-nvhdmi modules/sound-modules snd-hifiermodules/sound-modules snd-sa11xx-uda1341modules/sound-modules snd-sgalaxy modules/sound-modules snd-uda1341 modules/sound-modules These seem to have been dropped from Linux 3.2, they can be removed from the list. snd-aaci modules/sound-modules snd-aica modules/sound-modules snd-at73c213 modules/sound-modules snd-atmel-abdac modules/sound-modules snd-atmel-ac97c modules/sound-modules snd-au1x00modules/sound-modules snd-aw2 modules/sound-modules snd-ml403-ac97cr modules/sound-modules snd-pxa2xx-ac97 modules/sound-modules snd-pxa2xx-pcmmodules/sound-modules snd-sh_dac_audio modules/sound-modules I don't know why these aren't included in the configs. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120129230039.gb4...@type.famille.thibault.fr
Re: Sparc netboot image is too large to boot (again)
Jurij Smakov, le Sat 04 Feb 2012 12:16:25 +, a écrit : I've noticed that, yet again, sparc daily netboot image is too large to boot. Last time we mitigated the problem by removing the support for wireless networking. I'm going to poke around again to see what else can be get rid of, please let me know if you have any ideas. AIUI, linux can now have support for uncompressing bzip2, lzma and lzo. Trying them on amd64's initrd: -rw-r--r-- 1 samy samy 8,5M févr. 5 14:06 initrd.gz -rw-r--r-- 1 samy samy 7,7M févr. 5 14:06 initrd.bz2 -rw-r--r-- 1 samy samy 6,2M févr. 5 14:06 initrd.lzma -rw-r--r-- 1 samy samy 9,4M févr. 5 14:06 initrd.lzo -rw-r--r-- 1 samy samy 6,2M févr. 5 14:07 initrd.xz (for comparison) Doesn't it seem worthwhile to enable lzma support in the kernel to save more than 2M here? Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120205130911.gm4...@type.famille.thibault.fr
Re: Sparc netboot image is too large to boot (again)
Bastian Blank, le Sun 05 Feb 2012 14:55:49 +0100, a écrit : On Sun, Feb 05, 2012 at 02:09:11PM +0100, Samuel Thibault wrote: AIUI, linux can now have support for uncompressing bzip2, lzma and lzo. CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y The amd64 image have support for gzip, bzip2, lzma and the xz variant. Ah, right, it's not explicitly set in the linux-2.6 configs, but automatically enabled by Kconfig. So, anything against using xz compression instead? (except that there might be quite a few scripts to update from initrd.gz to initrd.xz...) Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120205141148.gb4...@type.famille.thibault.fr
Bug#665769: linux-2.6: Update sound modules list
Source: linux-2.6 Version: 3.3-1~experimental.1 Severity: normal Tags: patch Hello, Here is a patch to update the sound module list for linux 3.3. Samuel -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.4 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Samuel Thibault samuel.thiba...@fnac.net il y a 10 catégories de personnes dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas Index: debian/installer/modules/sound-modules === --- debian/installer/modules/sound-modules (révision 1) +++ debian/installer/modules/sound-modules (copie de travail) @@ -64,6 +64,7 @@ snd-harmony ? snd-hda-codec-analog ? snd-hda-codec-ca0110 ? +snd-hda-codec-ca0132 ? snd-hda-codec-cirrus ? snd-hda-codec-cmedia ? snd-hda-codec-conexant ?
Bug#730418: linux-2.6: Update sound module list for 3.12
Package: linux-2.6 Version: 3.12.1-1~exp1 Severity: normal Tags: patch Hello, Here is a patch to update the sound module list for linux 3.12. Samuel -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12.0 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Samuel Linux, c'est simple : ça s'adresse à une machine qui est parfois un peu maraboutée mais qui d'habitude n'a pas d'états d'âme. Sur Usenet y'a plein d'humains et de primates, et ça devient vraiment gore par moment. -+- TP in : Guide du linuxien pervers - Le linuxien a-t-il une âme ? -+- Index: installer/modules/sound-modules === --- installer/modules/sound-modules (révision 20822) +++ installer/modules/sound-modules (copie de travail) @@ -141,6 +141,7 @@ snd-usb-6fire ? snd-usb-audio ? snd-usb-caiaq ? +snd-usb-hiface ? snd-usb-us122l ? snd-usb-usx2y ? snd-via82xx ?
Bug#738758: [PATCH] ext4: optimize Hurd tests when reading/writing inodes
Theodore Ts'o, le Fri 21 Mar 2014 12:48:53 -0400, a écrit : Also, add a sanity check to make sure the 64-bit feature is not set for Hurd file systems, since i_file_acl_high conflicts with a Hurd-specific field. This is not a big deal, since Hurd doesn't support file systems larger than 1GB[1] anyway. Err, it does. We regularly use volumes with dozens of GiB. [1] http://walfield.org/pub/people/neal/papers/hurd-faq/FAQ.en.html#q2-6 That faq is very largely outdated. See the official faq on http://www.gnu.org/software/hurd/faq.html Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140321171114.ga5...@type.youpi.perso.aquilenet.fr
Bug#717183: linux: Please update sound-modules
Package: linux Version: 3.10~ Severity: normal Tags: patch Hello, Here is an update of the sound-modules list for linux 3.10. Samuel -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10.0 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Samuel Dans mutt, taper cceci (ou cthis selon votre locale) Index: debian/installer/modules/sound-modules === --- debian/installer/modules/sound-modules (révision 20359) +++ debian/installer/modules/sound-modules (copie de travail) @@ -33,6 +33,7 @@ snd-azt3328 ? snd-bt87x ? snd-ca0106 ? +snd-cmi8328 ? snd-cmi8330 ? snd-cmipci ? snd-cs4231 ? @@ -125,6 +126,7 @@ snd-sb8 ? snd-sbawe ? snd-sc6000 ? +snd-scs1x ? snd-sgi-hal2 ? snd-sgi-o2 ? snd-sh_dac_audio ?
Bug#743319: linux: Update sound module list
Source: linux Version: 3.14-1~exp1 Severity: normal Tags: patch Hello, Here is a patch to update the sound module list for 3.14. Samuel -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14.0 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Samuel D I hated the Mighty Mouse in the Apple Store every time I played with it. I hated the Mighty Mouse at work whenever I set up a Mac for somebody. D I decided to give it one last chance when I set up my new Mac D And golly, I like it at home. D Maybe mine is defective in a way that makes it good. Index: debian/installer/modules/sound-modules === --- debian/installer/modules/sound-modules (révision 21205) +++ debian/installer/modules/sound-modules (copie de travail) @@ -46,6 +46,7 @@ snd-ctxfi ? snd-darla20 ? snd-darla24 ? +snd-dice ? snd-echo3g ? snd-emu10k1 ? snd-emu10k1x ? @@ -69,6 +70,7 @@ snd-hda-codec-cirrus ? snd-hda-codec-cmedia ? snd-hda-codec-conexant ? +snd-hda-codec-generic ? snd-hda-codec-hdmi ? snd-hda-codec-idt ? snd-hda-codec-realtek ?
Bug#751345: linux: Sound modules list update for 3.15
Source: linux Version: 3.14-1~exp1 Severity: normal Tags: patch Hello, Here is the sound module list update for linux 3.15. Thanks, Samuel -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14.0 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Index: debian/installer/modules/sound-modules === --- debian/installer/modules/sound-modules (révision 21419) +++ debian/installer/modules/sound-modules (copie de travail) @@ -77,6 +77,7 @@ snd-hda-codec-si3054 ? snd-hda-codec-via ? snd-hda-codec ? +snd-hda-controller ? snd-hda-intel ? snd-hdsp ? snd-hdspm ?
Bug#756998: linux: Update sound module list for 3.16
Source: linux Version: 3.16~rc6-1~exp2 Severity: normal Tags: patch Hello, Here is an update of the sound module list for Linux 3.16 for d-i. Samuel -- System Information: Debian Release: jessie/sid APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15.0 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Samuel * B kicks DW (non mais franchement) * DW was kicked -+- #ens-mim - comment ça hopeless ? -+- Index: debian/installer/modules/sound-modules === --- debian/installer/modules/sound-modules (révision 21681) +++ debian/installer/modules/sound-modules (copie de travail) @@ -31,6 +31,7 @@ snd-azt2316 ? snd-azt2320 ? snd-azt3328 ? +snd-bebob ? snd-bt87x ? snd-ca0106 ? snd-cmi8328 ? @@ -57,6 +58,7 @@ snd-es1938 ? snd-es1968 ? snd-firewire-speakers ? +snd-fireworks ? snd-fm801 ? snd-gina20 ? snd-gina24 ? @@ -78,6 +80,7 @@ snd-hda-codec-via ? snd-hda-codec ? snd-hda-intel ? +snd-hda-tegra ? snd-hdsp ? snd-hdspm ? snd-ice1712 ?
Re: Bug#718548: bcache in D-I
Andreas Kloeckner, le Wed 07 Jan 2015 11:44:14 -0600, a écrit : Samuel Thibault sthiba...@debian.org writes: Andreas Kloeckner, le Wed 07 Jan 2015 09:59:58 -0600, a écrit : It's true that bcache is in the full kernel image package, but bcache.ko is *not* available in D-I (without extracting the kernel package, manually finding the .ko, insmod, ...). I would like to suggest that at least bcache.ko be included in the installer image, so that this annoying charade can be avoided. Will it be useful at all since bcache-tools is not available? Yes, since all you need to get a preexisting bcache volume up and running is: modprobe bcache echo /dev/sdb /sys/fs/bcache/register echo /dev/sdc /sys/fs/bcache/register Ok, it looks nice enough indeed. The module is not so small (354K here), so I guess this should be shipped in a separate udeb to avoid filling initrds. This udeb would then be available among others in the expert-mode d-i component list. Perhaps it could be auto-loaded at partman stage, but at least making it available would be way more convenient than fetching it by hand. Ben, Bastian, do you think it could be added for Jessie? Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150120010043.gn2...@type.youpi.perso.aquilenet.fr
Bug#779384: base: Gigabit Ethernet connection being downgraded to 100Mb/s mode (Renegotiation issues)
Please always keep the bug in Cc. I'm not the one to be convince, but the community. Info Geek, le Mon 30 Mar 2015 19:59:18 +0300, a écrit : I'm afraid that is false. A speed downgrade directly affects throughput, in applications that rely on stability and/or specific buffering of data etc. this is a critical problem. Sure, just like any kind of bug in specific situations. That's however not what serious means in Debian bug reports. Notably, I don't think we want to delay the release of Debian Jessie only due to this bug. Anyway, this is now in the hands of the linux package maintainers. They are the ones to be convinced. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150330171742.GY2385@type
Re: Bug#779384: base: Gigabit Ethernet connection being downgraded to 100Mb/s mode (Renegotiation issues)
Control: severity -1 normal Control: reassign -1 linux Hello, Info Geek, le Sat 28 Feb 2015 00:59:48 +0200, a écrit : Severity: serious This bug (speed downgrade) is not causing a package to completely stop working, lose data etc. so this is not of serious severity. AIUI, data negociation is mostly done by hardware, so I'd tend to think that this is a hardware issue, but perhaps the linux driver is involved, thus reassigning there. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150330164517.GA10594@type
Bug#782495: linux: sound modules list update for 4.0
Source: linux Version: 3.19.3-1~exp1 Severity: normal Tags: patch Hello, Here is the sound modules list update for linux 4.0. Samuel -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) -- Samuel /* Amuse the user. */ printk( \\|/ \\|/\n \@'/ ,. \\`@\\n /_| \\__/ |_\\\n \\__U_/\n); (From linux/arch/sparc/kernel/traps.c:die_if_kernel()) Index: debian/installer/modules/sound-modules === --- debian/installer/modules/sound-modules (révision 22506) +++ debian/installer/modules/sound-modules (copie de travail) @@ -115,6 +115,7 @@ snd-opti92x-ad1848 ? snd-opti92x-cs4231 ? snd-opti93x ? +snd-oxfw ? snd-oxygen ? snd-pcsp ? snd-pcxhr ? @@ -147,8 +148,13 @@ snd-usb-audio ? snd-usb-caiaq ? snd-usb-hiface ? +snd-usb-line6 ? +snd-usb-pod ? +snd-usb-podhd ? +snd-usb-toneport ? snd-usb-us122l ? snd-usb-usx2y ? +snd-usb-variax ? snd-via82xx ? snd-virtuoso ? snd-vx222 ?
Bug#797843: linux: sound update for 4.2
Source: linux Version: 4.2 Severity: normal Hello, As usual, here is the list update for sound-modules. That said, as discussed at debconf, perhaps now that we don't build oss drivers, we could just ship all modules of kernel/sound? I have attached the script I usually use to create the list, the idea was that it heuristically excludes the oss (but it's not built any more), soc and synth modules, which we don't need for d-i, core modules (since the drivers will depend on whatever they actually need), and all modem/tuner/synth/dummy modules. In the end, when I look at the figures: € du /lib/modules/4.2.0-trunk-amd64/kernel/sound -sh 9,4M/lib/modules/4.2.0-trunk-amd64/kernel/sound € du -sh /tmp/sound-modules-4.2.0-trunk-amd64-di/lib/modules/4.2.0-trunk-amd64/kernel/ 7,9M /tmp/sound-modules-4.2.0-trunk-amd64-di/lib/modules/4.2.0-trunk-amd64/kernel/ We gain 1.5M, which is mostly soc/: € du -sh /lib/modules/4.2.0-trunk-amd64/kernel/sound/soc 1,1M/lib/modules/4.2.0-trunk-amd64/kernel/sound/soc which I had assumed would not be useful for installation with speech synthesis, but maybe I'm actually wrong, and we should just as well ship everything in sound/ and save the maintenance of the list? Samuel -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Samuel muhahaha... ya un train qui part de Perrache à 14h57 qui passe à Part-Dieu à 15h10 si je le prend à Perrache, je suis en zone bleue si je le prends à Part-Dieu, je suis en zone blanche donc je vais le prendre à Perrache *mais* à Part-Dieu ;-) -+- #ens-mim - vive la SNCF -+- Index: sound-modules === --- sound-modules (révision 22941) +++ sound-modules (copie de travail) @@ -133,6 +133,7 @@ snd-sbawe ? snd-sc6000 ? snd-scs1x ? +snd-se6x ? snd-sgi-hal2 ? snd-sgi-o2 ? snd-sh_dac_audio ? #!/bin/bash export LC_ALL=C for i in `find . -name Makefile \ ! -path './oss/*' \ ! -path './soc/*' \ ! -path './core/*' \ ! -path './synth/*' ` do mangebackslash < $i | grep obj-; done \ | grep -v '^ *obj-y' \ | sed -e 's/ *obj-.*[+:]=//' \ | tr ' ' $'\n'$'\n' \ | grep -v '^$' \ | grep -v '/$' \ | sort -u \ | sed -e 's/\.o$//' \ | grep -v -- '-modem' \ | grep -v -- '-tuner' \ | grep -v -- '-synth' \ | grep -v -- '-lib' \ | grep -v -- '-common' \ | grep -v -- '-core' \ | grep -v -- '-soundbus' \ | grep -v -- '-dsp' \ | grep -v -- '-csp' \ | grep -v -- '_bus' \ | grep -v -- '_dma' \ | grep -v '^sound_firmware$' \ | grep -v '^soundcore$' \ | grep -v '^snd-i2c$' \ | grep -v '^snd-ac97-codec$' \ | grep -v '^snd-aloop$' \ | grep -v '^snd-dummy$' \ | grep -v '^snd-virmidi$' \ | grep -v '^snd-hda-controller$' \ | grep -v '^snd-mpu401$' \ | grep -v '^snd-mpu401-uart$' \ | grep -v '^snd-intel8x0m$' \ | grep -v '^snd-adlib$' \ | grep -v '^snd-mtpav$' \ | grep -v '^snd-mts64$' \ | grep -v '^snd-portman2x4$' \ | grep -v '^snd-serial-u16550$' \ | grep -v '^snd-tea6330t$' \ | grep -v '^snd-bcd2000$' \ | sed -e 's/$/ ?/'
Bug#814036: initramfs-tools: mdadm doesn't assemble disk
Package: initramfs-tools Version: 0.120 Severity: important Hello, Our server failed to reboot this afternoon. initrd was stuck trying to get the root device, running local-block in a loop before starting an emergency shell. There, running mdam -A --scan discovered everything and exitting the shell allowed the boot to proceed. There was no previous mention in the boot about being running mdadm. My guess (we can't really afford retrying etc. as it's a production system) is that AIUI mdadm is called just once from local-top, but that's perhaps too early, the disks are not yet discovered because the controller is slow. local-block is then run repeatedly to try to get the block devices, but mdadm from local-top should be called repeatedly too to try to assemble the md too? Samuel # mdadm Debian configuration # # You can run 'dpkg-reconfigure mdadm' to modify the values in this file, if # you want. You can also change the values here and changes will be preserved. # Do note that only the values are preserved; the rest of the file is # rewritten. # # INITRDSTART: # list of arrays (or 'all') to start automatically when the initial ramdisk # loads. This list *must* include the array holding your root filesystem. Use # 'none' to prevent any array from being started from the initial ramdisk. INITRDSTART='all' # AUTOCHECK: # should mdadm run periodic redundancy checks over your arrays? See # /etc/cron.d/mdadm. AUTOCHECK=true # START_DAEMON: # should mdadm start the MD monitoring daemon during boot? START_DAEMON=true # DAEMON_OPTIONS: # additional options to pass to the daemon. DAEMON_OPTIONS="--syslog" # VERBOSE: # if this variable is set to true, mdadm will be a little more verbose e.g. # when creating the initramfs. VERBOSE=false ARRAY /dev/md/0 metadata=1.2 name=apollon:0 UUID=0251c1f9:87d10ee8:f35106f1:fc2c1ce0 ARRAY /dev/md/1 metadata=1.2 name=apollon:1 UUID=de5c51dd:dc646570:a791dde2:76b95a00 ARRAY /dev/md/2 metadata=1.2 name=apollon:2 UUID=b07a6bab:d8d016a7:0203809b:8313199b ARRAY /dev/md/3 metadata=1.2 name=apollon:3 UUID=b8fe6506:06f4d3b1:cbbcb08c:73a2a178 ARRAY /dev/md/4 metadata=1.2 name=apollon:4 UUID=7d928fd5:e3f0d6ec:b81cd933:f056df30 ARRAY /dev/md10 metadata=1.2 name=apollon:10 UUID=b3f44d83:70a26fe7:8e43d4aa:3242f60c MAILADDR root
Re: Bug#718548: bcache in kernel udeb for D-I
Control: reassign -1 src:linux Control: retitle -1 Please add bcache module udeb Cyril Brulebois, on Sat 04 Feb 2017 05:47:36 +0100, wrote: > Samuel Thibault <sthiba...@debian.org> (2015-01-20): > > Andreas Kloeckner, le Wed 07 Jan 2015 11:44:14 -0600, a écrit : > > > Samuel Thibault <sthiba...@debian.org> writes: > > > > Andreas Kloeckner, le Wed 07 Jan 2015 09:59:58 -0600, a écrit : > > > >> It's true that bcache is in the full kernel image package, but > > > >> bcache.ko > > > >> is *not* available in D-I (without extracting the kernel package, > > > >> manually finding the .ko, insmod, ...). I would like to suggest that at > > > >> least bcache.ko be included in the installer image, so that this > > > >> annoying charade can be avoided. > > > > > > > > Will it be useful at all since bcache-tools is not available? > > > > > > Yes, since all you need to get a preexisting bcache volume up and > > > running is: > > > > > > modprobe bcache > > > echo /dev/sdb > /sys/fs/bcache/register > > > echo /dev/sdc > /sys/fs/bcache/register > > > > Ok, it looks nice enough indeed. > > > > The module is not so small (354K here), so I guess this should be > > shipped in a separate udeb to avoid filling initrds. This udeb would > > then be available among others in the expert-mode d-i component list. > > Perhaps it could be auto-loaded at partman stage, but at least making it > > available would be way more convenient than fetching it by hand. > > > > Ben, Bastian, do you think it could be added for Jessie? > > It would probably make sense to turn this into a wishlist bug report > against src:linux so that we get an extra udeb to be used in expert mode > indeed. I'm not sure anyone is going to do more integration work on the > d-i side, so we could probably just reassign this bug report to > src:linux? I agree, so doing it. Samuel
Re: Bug#718548: bcache in D-I
Ben Hutchings, on ven. 17 févr. 2017 02:30:58 +, wrote: > On Sat, 2017-02-04 at 05:47 +0100, Cyril Brulebois wrote: > > It would probably make sense to turn this into a wishlist bug report > > against src:linux so that we get an extra udeb to be used in expert mode > > indeed. I'm not sure anyone is going to do more integration work on the > > d-i side, so we could probably just reassign this bug report to > > src:linux? > > I'll add bcache to md-modules, as it seems to belong there (source is > even under drivers/md). Ah, good thing indeed :) Samuel
Bug#825840: localechooser: image display inverts red and blue color
Mathieu Malaterre, on Tue 06 Sep 2016 08:03:53 +0200, wrote: > On Tue, Sep 6, 2016 at 2:32 AM, Samuel Thibault <sthiba...@debian.org> wrote: > > I really don't think it's a bterm bug, its only change of behavior is > > when type or visual changes, which is not the case. It however does > > use FBIOPUTCMAP, whose implementation does seem suspicious in offb for > > RockHo. > > I did initially look into that direction (see the early bug report). > However when I realized that other TERM did not have the color > inversion I suspected that bterm was assuming BGR instead of RGB. What happens is that other terms do not use FBIOPUTCMAP. There is no risk that bogl gets RGB wrong in there, it just fills a struct fb_cmap, which has explicit "red", "green", and "blue" field names :) > I will try your suggested patch, but I fear it will break every single > other TERM out there (at least in assumption of color organisation). They don't use it, so they don't risk breaking. Samuel
Bug#825840: your mail
Mathieu Malaterre, on Tue 06 Sep 2016 08:36:14 +0200, wrote: > tags 825840 - help > tags 825840 + patch Well, I don't consider my patch a reasonable fix: depending on the actual board, the rgb order will vary. My patch is just changing the default order, and I believe it will fix yours, but it will also break others. So perphas a new value should be defined in the cmap_ enum. That should be discussed with the driver maintainer. Samuel
Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2
Lennart Sorensen, on Tue 04 Oct 2016 09:41:34 -0400, wrote: > while with TERM=bterm > it might be trying to create custom colours, which puts it into the > higher range where different handling is done for the pallete and > cmap_simple no longer works on the radeon. € grep bogl_set_palette * bogl.c: bogl_set_palette = bogl_fb_set_palette; bogl.c: bogl_set_palette = bogl_fb_set_palette; bogl.c: bogl_set_palette = bogl_tcfb_set_palette; bogl.c: the palette with bogl_set_palette() for this to take effect. */ bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char palette[][3]); bogl-test.c: bogl_set_palette (0, 16, palette); bogl-test.c: bogl_set_palette (6, 8, pixmap->palette); bowl.c: bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette); bterm.c: bogl_set_palette(0, 16, palette); bterm.c: bogl_set_palette(0, 16, palette); ChangeLog: * bterm.c (main): Call bogl_set_palette after VT switch. It looks like bterm always set only colors 0-15. Samuel
Re: Bug#709879: espeak: Alsa lib underflow and clicking sounds.
Control: reassign -1 linux Hello, Really sorry this apparently went unnoticed for so long. anton, on dim. 26 mai 2013 19:19:32 +1000, wrote: > Espeak does not start normally and throws out the error message: > ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred > Hundreds of times. It does it when the computer has been on for a while. > A reset is needed before it returns to normal for a few hours then the same > problem shows up again. Is it still an issue today? Since espeak is not running all that time along, this really rather looks like a kernel bug, thus reassigning. Samuel
Bug#931507: kernel-wedge: HDA sound board detection takes 60s in d-i
Ben Hutchings, le dim. 07 juil. 2019 17:36:03 +0100, a ecrit: > On Sun, 2019-07-07 at 17:16 +0200, Samuel Thibault wrote: > > Ben Hutchings, le dim. 07 juil. 2019 13:35:20 +0100, a ecrit: > > > i915 belongs in fb-modules. I'm not sure that sound-modules should > > > depend on it, as it's not a hard dependency. > > > > It is not a hard-hard dependency for the HDA driver, but without it > > there is a 60s delay for the detection of HDA-based devices... > > I think that could (and should) be avoided by only waiting if > request_module() succeeds. Ah, request_modules() is synchronous, I then wonder what this is waiting for, actually. > And I think all installer configurations that include sound-modules > also include fb-modules already. Probably indeed, but I don't find i915.ko in fb-modules. Samuel
Bug#931507: kernel-wedge: HDA sound board detection takes 60s in d-i
Ben Hutchings, le dim. 07 juil. 2019 13:35:20 +0100, a ecrit: > i915 belongs in fb-modules. I'm not sure that sound-modules should > depend on it, as it's not a hard dependency. It is not a hard-hard dependency for the HDA driver, but without it there is a 60s delay for the detection of HDA-based devices... Samuel
Bug#931507: kernel-wedge: HDA sound board detection takes 60s in d-i
Ben Hutchings, le sam. 10 août 2019 16:24:47 +0100, a ecrit: > I thought you also wanted us to add i915 to the installer though? It was just another way of fixing the problem with no source change: instead of waiting for the load of a non-available module, that module could just be shipped. Samuel
Bug#931507: kernel-wedge: HDA sound board detection takes 60s in d-i
Samuel Thibault, le ven. 26 juil. 2019 16:53:37 +0200, a ecrit: > Indeed. I can confirm that the attached patch fixes that. I can look > at the submission to upstream. FTR, this was included in 4.19.65. Samuel
Bug#931507: kernel-wedge: HDA sound board detection takes 60s in d-i
Control: tags -1 + patch
Hello,
Ben Hutchings, le dim. 07 juil. 2019 17:36:03 +0100, a ecrit:
> On Sun, 2019-07-07 at 17:16 +0200, Samuel Thibault wrote:
> > Ben Hutchings, le dim. 07 juil. 2019 13:35:20 +0100, a ecrit:
> > > i915 belongs in fb-modules. I'm not sure that sound-modules should
> > > depend on it, as it's not a hard dependency.
> >
> > It is not a hard-hard dependency for the HDA driver, but without it
> > there is a 60s delay for the detection of HDA-based devices...
>
> I think that could (and should) be avoided by only waiting if
> request_module() succeeds.
Indeed. I can confirm that the attached patch fixes that. I can look
at the submission to upstream.
> And I think all installer configurations that include sound-modules
> also include fb-modules already.
Indeed.
We really need to fix this for the 10.1 release: since hda-based boards
are very common we are getting more and more reports of people failing
to get speech synthesis (no, they don't read the errata).
What do you prefer? Including the proposed patch in the Buster Debian
package? Rather wait for upstream to include the patch, and in the
meanwhile adding i915.ko to fb-modules in Buster?
Samuel
hda: Fix 1-minute detection delay when i915 module is not available
Do not try to wait for i915 registration when loading the i915 module is known
to have failed (and not just because modules are not enabled)
Signed-off-by: Samuel Thibault
---
sound/hda/hdac_i915.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -143,10 +143,14 @@ int snd_hdac_i915_init(struct hdac_bus *
if (!acomp)
return -ENODEV;
if (!acomp->ops) {
- request_module("i915");
- /* 60s timeout */
- wait_for_completion_timeout(_complete,
- msecs_to_jiffies(60 * 1000));
+#ifdef CONFIG_MODULES
+ if (request_module("i915") == 0)
+#endif
+ {
+ /* 60s timeout */
+ wait_for_completion_timeout(_complete,
+ msecs_to_jiffies(60 *
1000));
+ }
}
if (!acomp->ops) {
dev_info(bus->dev, "couldn't bind with audio component\n");
Bug#657707: [initramfs-tools] modules for initrd are not stripped
Ben Hutchings, le mer. 24 juil. 2019 13:48:00 +0100, a ecrit: > On Wed, 2019-07-24 at 13:06 +0200, Samuel Thibault wrote: > > I'm also hitting disk contraints with almost-100M initrds. > > > > Ben Hutchings, le mar. 05 févr. 2019 01:00:31 +0100, a ecrit: > > > On Sat, 28 Jan 2012 08:34:31 +0100 =?utf-8?q?Micha=C5=82_Miros=C5=82aw?= > > > wrote: > > > > Please add an option (possibly defaulted to on) to strip kernel modules > > > > and > > > > binaries put in initrd. When using kernel with debugging enables the > > > > unstripped modules are available in /lib/modules. Unneeded copy of the > > > > symbols > > > > in initrd image take over 80% of its size. > > > [...] > > > > FTR, plain strip shouldn't be used as such, > > > > strip --strip-unneeded > > > > is needed instead, to avoid breaking loading the modules. > > strip breaks module signatures. Sure, I didn't mean it wouldn't. I just mean that even for people who don't care about signatures, strip shouldn't be used alone, since it'll even break loading the module. Samuel
Bug#657707: [initramfs-tools] modules for initrd are not stripped
I'm also hitting disk contraints with almost-100M initrds. Ben Hutchings, le mar. 05 févr. 2019 01:00:31 +0100, a ecrit: > On Sat, 28 Jan 2012 08:34:31 +0100 =?utf-8?q?Micha=C5=82_Miros=C5=82aw?= > wrote: > > Please add an option (possibly defaulted to on) to strip kernel modules and > > binaries put in initrd. When using kernel with debugging enables the > > unstripped modules are available in /lib/modules. Unneeded copy of the > > symbols > > in initrd image take over 80% of its size. > [...] FTR, plain strip shouldn't be used as such, strip --strip-unneeded is needed instead, to avoid breaking loading the modules. Samuel
Bug#931507: hda: Fix 1-minute detection delay when i915 module is not available
Distribution installation images such as Debian include different sets
of modules which can be downloaded dynamically. Such images may notably
include the hda sound modules but not the i915 DRM module, even if the
latter was enabled at build time, as reported on
https://bugs.debian.org/931507
In such a case hdac_i915 would be linked in and try to load the i915
module, fail since it is not there, but still wait for a whole minute
before giving up binding with it.
This fixes such as case by only waiting for the binding if the module
was properly loaded (or module support is disabled, in which case i915
is already compiled-in anyway).
Signed-off-by: Samuel Thibault
---
sound/hda/hdac_i915.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -143,10 +143,14 @@ int snd_hdac_i915_init(struct hdac_bus *
if (!acomp)
return -ENODEV;
if (!acomp->ops) {
- request_module("i915");
- /* 60s timeout */
- wait_for_completion_timeout(_complete,
- msecs_to_jiffies(60 * 1000));
+#ifdef CONFIG_MODULES
+ if (request_module("i915") == 0)
+#endif
+ {
+ /* 60s timeout */
+ wait_for_completion_timeout(_complete,
+ msecs_to_jiffies(60 * 1000));
+ }
}
if (!acomp->ops) {
dev_info(bus->dev, "couldn't bind with audio component\n");
Bug#931507: [PATCHv2] hda: Fix 1-minute detection delay when i915 module is not available
Distribution installation images such as Debian include different sets
of modules which can be downloaded dynamically. Such images may notably
include the hda sound modules but not the i915 DRM module, even if the
latter was enabled at build time, as reported on
https://bugs.debian.org/931507
In such a case hdac_i915 would be linked in and try to load the i915
module, fail since it is not there, but still wait for a whole minute
before giving up binding with it.
This fixes such as case by only waiting for the binding if the module
was properly loaded (or module support is disabled, in which case i915
is already compiled-in anyway).
Signed-off-by: Samuel Thibault
---
sound/hda/hdac_i915.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -136,10 +136,13 @@ int snd_hdac_i915_init(struct hdac_bus *
if (!acomp)
return -ENODEV;
if (!acomp->ops) {
- request_module("i915");
- /* 60s timeout */
- wait_for_completion_timeout(_complete,
- msecs_to_jiffies(60 * 1000));
+ if (!IS_ENABLED(CONFIG_MODULES) ||
+ !request_module("i915"))
+ {
+ /* 60s timeout */
+ wait_for_completion_timeout(_complete,
+ msecs_to_jiffies(60 * 1000));
+ }
}
if (!acomp->ops) {
dev_info(bus->dev, "couldn't bind with audio component\n");
Bug#948866: linux: Please enable terminus 16x32 font
Source: linux Version: 5.4.8-1 Severity: normal Hello, With hidpi displays, the default 8x16 font is unreadable. Could you enable CONFIG_FONTS=y CONFIG_FONT_TER16x32=y so that we can set fbcon=font:TER16x32 on the command line on systems with a hidpi display? Samuel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Samuel muhahaha... ya un train qui part de Perrache à 14h57 qui passe à Part-Dieu à 15h10 si je le prends à Perrache, je suis en zone bleue si je le prends à Part-Dieu, je suis en zone blanche donc je vais le prendre à Perrache *mais* à Part-Dieu ;-) -+- #ens-mim - vive la SNCF -+-
Re: Bug#981442: apparmor: Please do not install by default or depend on python3
Hello, intrigeri, le lun. 01 févr. 2021 09:16:23 +0100, a ecrit: > Samuel Thibault (2021-01-31): > > As of Debian bullseye alpha3, apparmor is getting installed by default > > even in the base system, > > To be clear, in this context "base system" is d-i terminology, right? Yes. That's when one selects no task, so the absolute minimum that gets installed. > > bringing with it python3 and thus 30MB of > > various stuff that didn't used to get installed in the past, which I do > > not think we want. > > Could you please confirm whether "in the past" means "in Stretch and > older" here, or something else? I'm surprised here. It does seem that Stretch, even as 10.0, does install apparmor and thus python, indeed. But I check for the install size before each Debian release, and did not notice that. Perhaps the apparmor recommendation appeared late in the Stretch process. I'm not sure whether debian-boot was aware that python ended up getting installed. > > or avoid making it hardly depend on python3? > > The only reason why apparmor "Depends: python3" in current testing/sid > is that /usr/sbin/aa-status is written in Python. > > Upstream commit 8f9046b1b179190d0003ae1beacf460ee93c5090, included in > upstream 3.0.0 release, and thus in Debian experimental already, > ported that program to C, which should allow dropping the dependency > on python3. I did not check how hard it would be to backport > this commit. That would be great to backport! Samuel
Re: Bug#981442: apparmor: Please do not install by default or depend on python3
Hello, Cc-ing the linux package maintainers since that's what recommends apparmor, thus pulling the 30MB. Also Cc-ing d-b for information. Samuel Samuel Thibault, le dim. 31 janv. 2021 12:10:43 +0100, a ecrit: > Package: apparmor > Version: 2.13.6-7 > Severity: important > > Hello, > > As of Debian bullseye alpha3, apparmor is getting installed by default > even in the base system, bringing with it python3 and thus 30MB of > various stuff that didn't used to get installed in the past, which I do > not think we want. Could you have a look at not installing apparmor by > default, or avoid making it hardly depend on python3? > > Samuel > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, > 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), > (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), > (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, > 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages apparmor depends on: > ii cdebconf [debconf-2.0] 0.256 > ii debconf [debconf-2.0] 1.5.74 > ii libc6 2.31-9 > ii lsb-base11.1.0 > ii python3 3.9.1-1 > > apparmor recommends no packages. > > Versions of packages apparmor suggests: > pn apparmor-profiles-extra > pn apparmor-utils > > -- debconf information excluded
Re: Bug#981442: apparmor: Please do not install by default or depend on python3
Samuel Thibault, le dim. 31 janv. 2021 13:19:28 +0100, a ecrit: > Cc-ing the linux package maintainers since that's what recommends > apparmor, thus pulling the 30MB. Actually, that not only pulls python3 but also perl, libicu, and in the end with dependencies, that amounts to 114MB. Samuel > Samuel Thibault, le dim. 31 janv. 2021 12:10:43 +0100, a ecrit: > > Package: apparmor > > Version: 2.13.6-7 > > Severity: important > > > > Hello, > > > > As of Debian bullseye alpha3, apparmor is getting installed by default > > even in the base system, bringing with it python3 and thus 30MB of > > various stuff that didn't used to get installed in the past, which I do > > not think we want. Could you have a look at not installing apparmor by > > default, or avoid making it hardly depend on python3? > > > > Samuel > > > > -- System Information: > > Debian Release: bullseye/sid > > APT prefers testing > > APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, > > 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), > > (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), > > (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, > > 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) > > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE > > not set > > Shell: /bin/sh linked to /usr/bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages apparmor depends on: > > ii cdebconf [debconf-2.0] 0.256 > > ii debconf [debconf-2.0] 1.5.74 > > ii libc6 2.31-9 > > ii lsb-base11.1.0 > > ii python3 3.9.1-1 > > > > apparmor recommends no packages. > > > > Versions of packages apparmor suggests: > > pn apparmor-profiles-extra > > pn apparmor-utils > > > > -- debconf information excluded
Re: Bug#985956: Merge request submittted to initramfs-tools
Hello, Pete Batard, le jeu. 15 avril 2021 16:11:02 +0100, a ecrit: > Quite a few people are negatively affected by this bug, and one can expect a > lot more to be if Debian 11 goes to release without the inclusion of > mdio-bcm-unimac.ko in the netinst ARM64 ISOs. > > I have created an initramfs-tools merge request to attempt to fix the > problem, which can be found at: > https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/46 AIUI initramfs-tools rules are not used to build the nic-modules udeb, it'd rather be happening in the linux package, in debian/installer/modules/nic-modules, which indeed doesn't include drivers/net/mdio/. Linux maintainers, do you know more on this issue? Samuel
Re: Bug#985696: debian-installer: Speech synthesis and Intel SOF firmware
Hello, Asking debian-kernel about firmwares: is the firmware-intel-sound package needed for getting sound on some hardware? Do you know if arm64 has some platforms which require such kind of sound firmwares? Samuel Samuel Thibault, le lun. 14 févr. 2022 12:55:15 +0100, a ecrit: > Arnaud Rebillout, le lun. 22 mars 2021 17:30:30 +0700, a ecrit: > > some recent Intel sound cards require a firmware to work. This firmware > > is packaged under 'firmware-sof-signed'. For reference, you might want > > to look at the ITP [1]. > > > > I tried it with my laptop. What happens is that the installer gets stuck > > straight from the beginning, prior it can show any kind of GUI. All I > > get is a black scree with the lines: > > > > Please wait while we probe your sound card(s)... > > Could you try with the following image: > > https://people.debian.org/~sthibault/tmp/debian-sid-amd64-NETINST-1.iso > > It's supposed to have the firmware available for loading before speech > starts. > > Samuel
Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64
Diederik de Haas, le lun. 20 févr. 2023 00:38:28 +0100, a ecrit: > On Monday, 20 February 2023 00:27:57 CET Samuel Thibault wrote: > > Diederik de Haas, le lun. 20 févr. 2023 00:14:19 +0100, a ecrit: > > > On Tuesday, 14 February 2023 18:10:11 CET Samuel Thibault wrote: > > > > Some people on debian-accessibility wanted to install debian in arm64 > > > > under the utm wrapped qemu on Macos. The current installation images > > > > however do not include sound drivers and speakup. > > > > > > Currently working on a MR to achieve that, but ... > > > > > > > ... indeed, it seems these modules are getting built only for > > > > amd64, 686, mips, sh4. > > > > > > ... this architecture list seems rather random? Why not also add it to > > > f.e. > > > armhf, which itself is also a rather random not-previously-enabled-arch? > > > > I don't see why we shouldn't indeed. If some drivers didn't make sense > > on these archs they would rather be disabled by the arch configuration > > anyway. Speakup itself is portable and should be working on any arch, > > provided it has a virtual console. > > > > The only historical reason I can see is that it was enabled only for > > architectures which have a gtk installer image (for which we consider > > that size doesn't matter). > > On https://www.debian.org/devel/debian-installer/ I checked the links under > "other images (netboot, USB stick, etc.)" for the presence of a > "netboot/gtk/" > folder and that turned out to be arm64 and armhf, so I'll only add those. > > If other arches should be added too, that can be done later. I'm just thinking that probably people won't actually do it. That's what happened for arm64: see commit ea37896526075fb9d0f453ec537536149ea97d16 which copied over the gtk configuration, but left speakup/sound commented, most probably just because the package was not available, and only now, 4 years later, we notice the missing feature. Samuel
Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64
Diederik de Haas, le lun. 20 févr. 2023 00:14:19 +0100, a ecrit: > On Tuesday, 14 February 2023 18:10:11 CET Samuel Thibault wrote: > > Some people on debian-accessibility wanted to install debian in arm64 > > under the utm wrapped qemu on Macos. The current installation images > > however do not include sound drivers and speakup. > > Currently working on a MR to achieve that, but ... > > > ... indeed, it seems these modules are getting built only for > > amd64, 686, mips, sh4. > > ... this architecture list seems rather random? Why not also add it to f.e. > armhf, which itself is also a rather random not-previously-enabled-arch? I don't see why we shouldn't indeed. If some drivers didn't make sense on these archs they would rather be disabled by the arch configuration anyway. Speakup itself is portable and should be working on any arch, provided it has a virtual console. The only historical reason I can see is that it was enabled only for architectures which have a gtk installer image (for which we consider that size doesn't matter). Samuel
Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64
Hello,
Samuel Thibault, le mar. 14 févr. 2023 22:02:34 +0100, a ecrit:
> Samuel Thibault, le mar. 14 févr. 2023 18:10:11 +0100, a ecrit:
> > E: Unable to locate package sound-modules-6.1.0-4-arm64-di
> > E: Unable to locate package speakup-modules-6.1.0-4-arm64-di
> >
> > and indeed, it seems these modules are getting built only for amd64,
> > 686, mips, sh4.
> >
> > Could we consider adding them on arm64 in the linux package?
>
> Which boils down to:
>
> cp debian/installer/modules/{i386,arm64}/speakup-modules
> cp debian/installer/modules/{i386,arm64}/sound-modules
> rm -f debian/control.md5sum
> ./debian/rules debian/control
Do you think this could be uploaded in time for bookworm?
Thanks,
Samuel
Bug#958311: cloud kernel 5.5.0-2 does not boot under xen
Andy Smith, le jeu. 16 févr. 2023 15:44:21 +, a ecrit: > - The PV part of grub is quite old and from what I understand > implemented in a strange way Ah, uh :/ > that no one wants to maintain any > more, so this part of grub is stuck without ability to > understand the newer kernel compressions. Ok :/ Samuel
Bug#958311: cloud kernel 5.5.0-2 does not boot under xen
Hello, Getting the same issue :) Andy Smith, le jeu. 09 juin 2022 15:32:38 +, a ecrit: > On Thu, Jun 09, 2022 at 02:00:30PM +0300, Aleksi Suhonen wrote: > > The underlying problem is that the cloud kernel is compressed with an > > algorithm that grub can't uncompress. What I've been doing as a workaround > > is that I decompress the kernel myself in a kernel install hook. > > Can you show us your xen domu config file? I'm interested in what > method you are using to boot these. Using /usr/lib/grub-xen/grub-x86_64-xen.bin here. > If you're using pvgrub2 to boot PV mode then the bad news is that it > seems to be largely abandoned as nobody wants to alter it to support > different kernel compression methods. Uh... I wonder how it is that it's not just orthogonal to whether booting in native/PV/PVH... > The good news is that you should be able to easily switch to PVH > mode with pvhgrub which uses grub's core routines to decompress the > kernel and therefore supports whatever compression methods that grub > normally does. Ok, so why not switch to PVH indeed. I just replaced kernel = '/usr/lib/grub-xen/grub-x86_64-xen.bin' with type="pvh" kernel = '/usr/lib/grub-xen/grub-i386-xen_pvh.bin' and it went fine with the cloud image indeed! Though now I have to fix the default console, to get kernel messages on hvc0: console=hvc0 Samuel
Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64
Source: linux
Version: 6.1.8-1
Severity: normal
Tags: a11y d-i
Hello,
Some people on debian-accessibility wanted to install debian in arm64
under the utm wrapped qemu on Macos. The current installation images
however do not include sound drivers and speakup. Applying the attached
patch to d-i brings:
E: Unable to locate package sound-modules-6.1.0-4-arm64-di
E: Unable to locate package speakup-modules-6.1.0-4-arm64-di
and indeed, it seems these modules are getting built only for amd64,
686, mips, sh4.
Could we consider adding them on arm64 in the linux package?
Thanks,
Samuel
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500,
'proposed-updates-debug'), (500, 'proposed-updates'), (500,
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'),
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1,
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64
Kernel: Linux 6.1.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
diff --git a/build/pkg-lists/cdrom/grub/gtk/arm64.cfg
b/build/pkg-lists/cdrom/grub/gtk/arm64.cfg
index 25992fbe8..def0e98d5 100644
--- a/build/pkg-lists/cdrom/grub/gtk/arm64.cfg
+++ b/build/pkg-lists/cdrom/grub/gtk/arm64.cfg
@@ -5,7 +5,7 @@ event-modules-${kernel:Version}
xserver-xorg-input-libinput-udeb
xserver-xorg-video-fbdev-udeb
-#speakup-modules-${kernel:Version}
-#sound-modules-${kernel:Version}
-#console-setup-linux-fonts-udeb
-#espeakup-udeb
+speakup-modules-${kernel:Version}
+sound-modules-${kernel:Version}
+console-setup-linux-fonts-udeb
+espeakup-udeb
diff --git a/build/pkg-lists/netboot/gtk/arm64.cfg
b/build/pkg-lists/netboot/gtk/arm64.cfg
index 25992fbe8..def0e98d5 100644
--- a/build/pkg-lists/netboot/gtk/arm64.cfg
+++ b/build/pkg-lists/netboot/gtk/arm64.cfg
@@ -5,7 +5,7 @@ event-modules-${kernel:Version}
xserver-xorg-input-libinput-udeb
xserver-xorg-video-fbdev-udeb
-#speakup-modules-${kernel:Version}
-#sound-modules-${kernel:Version}
-#console-setup-linux-fonts-udeb
-#espeakup-udeb
+speakup-modules-${kernel:Version}
+sound-modules-${kernel:Version}
+console-setup-linux-fonts-udeb
+espeakup-udeb
Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64
Samuel Thibault, le mar. 14 févr. 2023 18:10:11 +0100, a ecrit:
> E: Unable to locate package sound-modules-6.1.0-4-arm64-di
> E: Unable to locate package speakup-modules-6.1.0-4-arm64-di
>
> and indeed, it seems these modules are getting built only for amd64,
> 686, mips, sh4.
>
> Could we consider adding them on arm64 in the linux package?
Which boils down to:
cp debian/installer/modules/{i386,arm64}/speakup-modules
cp debian/installer/modules/{i386,arm64}/sound-modules
rm -f debian/control.md5sum
./debian/rules debian/control
Samuel
Bug#1039092: linux: Braille keyboards broken with Linux 6.3 with disabled TIOCSTI
Source: linux Version: 6.3.7-1 Severity: important Tags: a11y upstream Forwarded: https://lkml.org/lkml/2022/12/27/719 Hello, This is an upstream issue, but I am reporting it here so it gets documented. With version 6.3, Linux disabled TIOCSTI by default, for security reasons. This basically broke Braille keyboards: brltty needs that interface to properly simulate keypresses. I had proposed upstream on https://lkml.org/lkml/2022/12/27/719 some solutions, without any answer. Now that we actually have a regression and people start complaining on debian-accessibility, perhaps they'll listen? We really need to do something about it, anyway. A workaround is to set dev.tty.legacy_tiocsti=1 in /etc/sysctl.conf, but that basically re-exposes the security issues. Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.3.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria.
