New speakup-udeb component

[Frans Pop-3]

(No need to CC me on replies. Thx.)

Hi Mario, Samuel, others,

The FTP-masters alerted us to the fact that you uploaded a new D-I component
to the archive: speakup-udeb. We have an agreement with them that they
check with us before approving packages with new udebs.

It seems that this is only a very minimal udeb (only three hook scripts) and
we're wondering if there is really a justification to have a separate udeb
for that.

1) The scripts would possibly fit fine in the rootskel and/or finish-install
   udebs.
2) There would be a change in D-I needed anyway to get your udeb included in
   images.
3) Having a udeb in a source package has a cost: it is blocked by default
   for migrations to testing and causes some release management overhead.

So, our questions are:
- can you please send us the scripts so we can review them
- is there a real reason these scripts need to be in a separate udeb (one
  reason could be because they may need to be updated with upstream changes
  in the same source package; another could be that they should not be
  included for all installation methods)
- how were you planning to use these scripts: what images and what
  architectures; did you already have a patch for D-I to include them

Until we have reached agreement on this, the package will not be accepted
from NEW. For a next time: please check with us before uploading.

Cheers,
FJP

[Samuel Thibault]

Hello,

Ok, I'm the culprit, I should have talked about it with debian-boot.

I thought about putting the scripts (attached to this mail) in a
separate speakup-udeb package because it makes the integration to
the debian installer extremely simple: just add speakup-deb to
installer/build/pkg-list/something/somearchs.cfg and voilà.  The idea
was also that in case we needed to change anything, we just had to
upload a new speakup source package.

Frans Pop, le Wed 28 May 2008 18:07:37 +0200, a écrit :
> It seems that this is only a very minimal udeb (only three hook scripts) and
> we're wondering if there is really a justification to have a separate udeb
> for that.

Possibly not, see attached files: speakup-udeb.startup gets run early,
sees the speakup statement on the kernel command line, and in that
case modprobes speakup and disables the framebuffer.  In addition to
that, speakup-udeb.debinst selects the text frontend.  Eventually,
speakup-udeb.finish-install installs the module on the target system,
and sets the module to be auto-loaded on reboot.

> 1) The scripts would possibly fit fine in the rootskel and/or finish-install
>    udebs.

Yes.

> 2) There would be a change in D-I needed anyway to get your udeb included in
>    images.

Right.

> 3) Having a udeb in a source package has a cost: it is blocked by default
>    for migrations to testing and causes some release management overhead.

And that's where I indeed think I was wrong.  That would make the
upcoming git speakup releases a burden, while the udeb scripts will
probably not change.

> - is there a real reason these scripts need to be in a separate udeb (one
>   reason could be because they may need to be updated with upstream changes
>   in the same source package;

These scripts will actually probably just stay the same.

> another could be that they should not be included for all installation
> methods)

The scripts by themselves should be fine. The problem is more about
room.  Speakup modules need a total of 160KB. If that's fine with any
installation medium, then great, we can just always enable it. We could
also always have the script, and include the modules only in the cases
where we can afford it.  Scrips will just not work when the modules are
not available.

> - how were you planning to use these scripts: what images and what
>   architectures; did you already have a patch for D-I to include them

Attached is the patch I've been using for tests, just adding the udeb to
a few archs.  In principle, there is no reason to restrain from shipping
speakup to all archs.  It's rather about the room constraints.

Samuel

SYNTH=`sed < /proc/cmdline -n -e 's/.* speakup\.synth=\([^ ]*\).*/\1/p'`
if [ -n "$SYNTH" ]
then
        modprobe speakup_$SYNTH
        debconf-set debian-installer/framebuffer false
fi

SYNTH=`sed < /proc/cmdline -n -e 's/.* speakup\.synth=\([^ ]*\).*/\1/p'`
if [ -n "$SYNTH" ]
then
        DEBIAN_FRONTEND=text
        export DEBIAN_FRONTEND
fi

SYNTH=`sed < /proc/cmdline -n -e 's/.* speakup\.synth=\([^ ]*\).*/\1/p'`
if [ -n "$SYNTH" ]
then
        if apt-install speakup-modules 1>&2
        then
                echo speakup_$SYNTH >> /target/etc/modules
        fi
fi

Index: build/boot/x86/f8.txt
===================================================================
--- build/boot/x86/f8.txt (r�vision 53132)
+++ build/boot/x86/f8.txt (copie de travail)
@@ -12,6 +12,7 @@
 Force static network config             0fnetcfg/disable_dhcp=true07
 Set keyboard map                        0fbootkbd=es07
 Use Braille tty                         0fbrltty=driver,device,texttable07
+Use Speakup                             0fspeakup.synth=driver07
 Use high contrast accessibility theme   0ftheme=dark07
 Select the kde or xfce desktops         0fdesktop=kde07
 
Index: build/pkg-lists/netboot/alpha.cfg
===================================================================
--- build/pkg-lists/netboot/alpha.cfg (r�vision 53132)
+++ build/pkg-lists/netboot/alpha.cfg (copie de travail)
@@ -26,3 +26,5 @@
 brltty-udeb
 serial-modules-${kernel:Version} ?
 usb-serial-modules-${kernel:Version} ?
+
+speakup-udeb
Index: build/pkg-lists/netboot/i386.cfg
===================================================================
--- build/pkg-lists/netboot/i386.cfg (r�vision 53132)
+++ build/pkg-lists/netboot/i386.cfg (copie de travail)
@@ -37,3 +37,5 @@
 brltty-udeb
 serial-modules-${kernel:Version}
 usb-serial-modules-${kernel:Version} ?
+
+speakup-udeb
Index: build/pkg-lists/netboot/ppc64.cfg
===================================================================
--- build/pkg-lists/netboot/ppc64.cfg (r�vision 53132)
+++ build/pkg-lists/netboot/ppc64.cfg (copie de travail)
@@ -25,5 +25,7 @@
 serial-modules-${kernel:Version}
 usb-serial-modules-${kernel:Version} ?
 
+speakup-udeb
+
 # IBM Power hypervisor modules, only available on powerpc64.
 hypervisor-modules-${kernel:Version} ?
Index: build/pkg-lists/netboot/ia64.cfg
===================================================================
--- build/pkg-lists/netboot/ia64.cfg (r�vision 53132)
+++ build/pkg-lists/netboot/ia64.cfg (copie de travail)
@@ -16,3 +16,5 @@
 brltty-udeb
 serial-modules-${kernel:Version}
 usb-serial-modules-${kernel:Version} ?
+
+speakup-udeb
Index: build/pkg-lists/netboot/amd64.cfg
===================================================================
--- build/pkg-lists/netboot/amd64.cfg (r�vision 53132)
+++ build/pkg-lists/netboot/amd64.cfg (copie de travail)
@@ -38,3 +38,5 @@
 brltty-udeb
 serial-modules-${kernel:Version} ?
 usb-serial-modules-${kernel:Version} ?
+
+speakup-udeb
Index: build/pkg-lists/netboot/powerpc.cfg
===================================================================
--- build/pkg-lists/netboot/powerpc.cfg (r�vision 53132)
+++ build/pkg-lists/netboot/powerpc.cfg (copie de travail)
@@ -25,6 +25,8 @@
 serial-modules-${kernel:Version}
 usb-serial-modules-${kernel:Version} ?
 
+speakup-udeb
+
 # IBM Power hypervisor modules, only available on powerpc64.
 hypervisor-modules-${kernel:Version} ?
 fancontrol-modules-${kernel:Version} ?

[Otavio Salvador]

Samuel Thibault <samuel.thibault@...> writes:

>> another could be that they should not be included for all installation
>> methods)
>
> The scripts by themselves should be fine. The problem is more about
> room.  Speakup modules need a total of 160KB. If that's fine with any
> installation medium, then great, we can just always enable it. We could
> also always have the script, and include the modules only in the cases
> where we can afford it.  Scrips will just not work when the modules are
> not available.

Floppy wouldn't fit them probably.

--
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@...      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."


--
To UNSUBSCRIBE, email to debian-accessibility-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Frans Pop-3]

On Wednesday 28 May 2008, Samuel Thibault wrote:
> I thought about putting the scripts (attached to this mail) in a
> separate speakup-udeb package because it makes the integration to
> the debian installer extremely simple: just add speakup-deb to
> installer/build/pkg-list/something/somearchs.cfg and voilà.  The idea
> was also that in case we needed to change anything, we just had to
> upload a new speakup source package.

OK. Given your replies it looks like including it in existing udebs is the
better way to go. Based on that I've asked FTP-masters to reject your
upload, which clears the way for a new upload without the udeb (if you
want, you can use the same version).

I'll look at the scripts in detail tomorrow and we can discuss details then.

Thanks for the quick response.

Cheers,
FJP

[Frans Pop-3]

On Wednesday 28 May 2008, Samuel Thibault wrote:
> Possibly not, see attached files: speakup-udeb.startup gets run early,
> sees the speakup statement on the kernel command line, and in that
> case modprobes speakup and disables the framebuffer.  In addition to
> that, speakup-udeb.debinst selects the text frontend.  Eventually,
> speakup-udeb.finish-install installs the module on the target system,
> and sets the module to be auto-loaded on reboot.

Where exactly were you installing these files (full path/filenames
please)?

The scripts need some minor changes to conform with D-I coding style, but
I can take care of that.

> The scripts by themselves should be fine. The problem is more about
> room.  Speakup modules need a total of 160KB. If that's fine with any
> installation medium, then great, we can just always enable it. We could
> also always have the script, and include the modules only in the cases
> where we can afford it.

Right. As the scripts themselves are negligible, I think we should just
include them by default and determine actual support by including or not
including the kernel module udebs. We'll have to see for what arches and
images we can do that.

What is the status of the kernel support and the l-m-e packaging?

> Scrips will just not work when the modules are not available.

Well, that does not seem to be entirely accurate: they will work, but
their effect will be nil. It seems to me that the 2 later script should
check that the $SYNTH module was actually loaded successfully.

From the finish-install script:
> if apt-install speakup-modules 1>&2

Will that actually work? Should that not include the kernel version, ABI
and flavor?

Cheers,
FJP

[Samuel Thibault]

Frans Pop, le Sat 31 May 2008 13:41:16 +0200, a écrit :

> On Wednesday 28 May 2008, Samuel Thibault wrote:
> > Possibly not, see attached files: speakup-udeb.startup gets run early,
> > sees the speakup statement on the kernel command line, and in that
> > case modprobes speakup and disables the framebuffer.  In addition to
> > that, speakup-udeb.debinst selects the text frontend.  Eventually,
> > speakup-udeb.finish-install installs the module on the target system,
> > and sets the module to be auto-loaded on reboot.
>
> Where exactly were you installing these files (full path/filenames
> please)?

speakup-udeb.finish-install to /usr/lib/finish-install.d/05speakup
speakup-udeb.debinst to /lib/debian-installer.d/S20speakup
speakup-udeb.startup to /lib/debian-installer-startup.d/S37speakup

> > The scripts by themselves should be fine. The problem is more about
> > room.  Speakup modules need a total of 160KB. If that's fine with any
> > installation medium, then great, we can just always enable it. We could
> > also always have the script, and include the modules only in the cases
> > where we can afford it.
>
> Right. As the scripts themselves are negligible, I think we should just
> include them by default and determine actual support by including or not
> including the kernel module udebs. We'll have to see for what arches and
> images we can do that.
>
> What is the status of the kernel support and the l-m-e packaging?

Attached is the patch to l-m-e which I have used.

> > Scrips will just not work when the modules are not available.
>
> Well, that does not seem to be entirely accurate: they will work, but
> their effect will be nil.

Right :)

> It seems to me that the 2 later script should
> check that the $SYNTH module was actually loaded successfully.

We can replace the cmdline parsing by lsmod and that should work fine
indeed.

> From the finish-install script:
> > if apt-install speakup-modules 1>&2
>
> Will that actually work?

I couldn't test indeed it since the package wasn't yet on the mirrors.

> Should that not include the kernel version, ABI and flavor?

Hum, indeed.  I don't know how to do that properly.

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

[Frans Pop-3]

On Saturday 31 May 2008, Samuel Thibault wrote:
> > What is the status of the kernel support and the l-m-e packaging?
>
> Attached is the patch to l-m-e which I have used.

OK. But my question actually was: when can we expect these packages to hit
the archive?

> > Should that not include the kernel version, ABI and flavor?
>
> Hum, indeed.  I don't know how to do that properly.

See for example:
http://svn.debian.org/wsvn/d-i/trunk/packages/partman/partman-crypto/finish-install.d/05crypto?op=file&rev=0&sc=0

Note that that assumes l-m-e also generates appropriate meta-packages
(without kernel minor and ABI version) which depend on the actual
package, but I'd expect that to be covered automatically.

Example:
Package: loop-aes-modules-2.6-686
Depends: linux-latest-modules-2.6.25-2-686, loop-aes-modules-2.6.25-2-686


My conclusion for now is that there seems to be no harm in waiting until
the modules are actually available in the archive. The scripts are fairly
trivial and can be added on short notice at that time. With the added
advantage that they then can be properly tested.
We can then also add them in kernel-wedge so that the kernel module udebs
can be generated.

Cheers,
FJP

[Samuel Thibault]

Frans Pop, le Sat 31 May 2008 18:59:32 +0200, a écrit :
> On Saturday 31 May 2008, Samuel Thibault wrote:
> > > What is the status of the kernel support and the l-m-e packaging?
> >
> > Attached is the patch to l-m-e which I have used.
>
> OK. But my question actually was: when can we expect these packages to hit
> the archive?

Ah, well the speakup package is in the NEW queue again, and once it gets
out, l-m-e can be updated.

Samuel


--
To UNSUBSCRIBE, email to debian-accessibility-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Samuel Thibault]

Hello,

Frans Pop, le Sat 31 May 2008 18:59:32 +0200, a écrit :
> On Saturday 31 May 2008, Samuel Thibault wrote:
> > > What is the status of the kernel support and the l-m-e packaging?
> >
> > Attached is the patch to l-m-e which I have used.
>
> OK. But my question actually was: when can we expect these packages to hit
> the archive?

They now are in.

> > > Should that not include the kernel version, ABI and flavor?
> >
> > Hum, indeed.  I don't know how to do that properly.
>
> See for example:
> http://svn.debian.org/wsvn/d-i/trunk/packages/partman/partman-crypto/finish-install.d/05crypto?op=file&rev=0&sc=0

Ok, thanks.

Attached are the patches against rootskel and finish-install which I
could test with success (provided the patch from bug #479227 is applied
to kernel-wedge and the speakup module be added to
linux-kernel-di-*-2.6)

Samuel

diff -urN rootskel-1.62/src/lib/debian-installer.d/Makefile rootskel-1.62-mine/src/lib/debian-installer.d/Makefile
--- rootskel-1.62/src/lib/debian-installer.d/Makefile 2007-12-31 22:34:15.000000000 +0000
+++ rootskel-1.62-mine/src/lib/debian-installer.d/Makefile 2008-06-28 04:41:20.000000000 +0100
@@ -15,6 +15,7 @@
 endif
 
 files += \
+ S20speakup \
  S30term \
  S60frontend \
  S65theme \
diff -urN rootskel-1.62/src/lib/debian-installer.d/S20speakup rootskel-1.62-mine/src/lib/debian-installer.d/S20speakup
--- rootskel-1.62/src/lib/debian-installer.d/S20speakup 1970-01-01 01:00:00.000000000 +0100
+++ rootskel-1.62-mine/src/lib/debian-installer.d/S20speakup 2008-06-28 04:30:30.000000000 +0100
@@ -0,0 +1,5 @@
+if lsmod | grep -q speakup_
+then
+ DEBIAN_FRONTEND=text
+ export DEBIAN_FRONTEND
+fi
diff -urN rootskel-1.62/src/lib/debian-installer-startup.d/Makefile rootskel-1.62-mine/src/lib/debian-installer-startup.d/Makefile
--- rootskel-1.62/src/lib/debian-installer-startup.d/Makefile 2008-02-20 23:56:38.000000000 +0000
+++ rootskel-1.62-mine/src/lib/debian-installer-startup.d/Makefile 2008-06-28 04:41:43.000000000 +0100
@@ -19,7 +19,8 @@
  S02module-params \
  S10syslog \
  S20templates \
- S35term
+ S35term \
+ S37speakup
 
 ifeq ($(DEB_HOST_ARCH_OS),linux)
   ifneq (,$(filter i386 amd64,$(DEB_HOST_ARCH_CPU)))
diff -urN rootskel-1.62/src/lib/debian-installer-startup.d/S37speakup rootskel-1.62-mine/src/lib/debian-installer-startup.d/S37speakup
--- rootskel-1.62/src/lib/debian-installer-startup.d/S37speakup 1970-01-01 01:00:00.000000000 +0100
+++ rootskel-1.62-mine/src/lib/debian-installer-startup.d/S37speakup 2008-06-28 04:30:33.000000000 +0100
@@ -0,0 +1,6 @@
+SYNTH=`sed < /proc/cmdline -n -e 's/.*speakup\.synth=\([^ ]*\).*/\1/p'`
+if [ -n "$SYNTH" ]
+then
+ modprobe speakup_$SYNTH
+ debconf-set debian-installer/framebuffer false
+fi

diff -urN finish-install-2.18/debian/rules finish-install-2.18-mine/debian/rules
--- finish-install-2.18/debian/rules 2008-02-13 13:48:37.000000000 +0000
+++ finish-install-2.18-mine/debian/rules 2008-06-28 04:43:38.000000000 +0100
@@ -3,6 +3,7 @@
 DESTDIR = debian/finish-install
 
 scripts = \
+ 05speakup \
  10bind-mount \
  20final-message \
  50config-target-network \
diff -urN finish-install-2.18/finish-install.d/05speakup finish-install-2.18-mine/finish-install.d/05speakup
--- finish-install-2.18/finish-install.d/05speakup 1970-01-01 01:00:00.000000000 +0100
+++ finish-install-2.18-mine/finish-install.d/05speakup 2008-06-28 04:26:37.000000000 +0100
@@ -0,0 +1,12 @@
+#!/bin/sh
+. /usr/share/debconf/confmodule
+SYNTH=`lsmod | grep ^speakup_ | cut -f 1 -d ' '`
+if [ -n "$SYNTH" ]
+then
+ db_get base-installer/kernel/image
+ KVERS=${RET#*-image-}
+ if apt-install speakup-modules-$KVERS 1>&2
+ then
+ echo $SYNTH >> /target/etc/modules
+ fi
+fi

[Frans Pop-3]

On Saturday 28 June 2008, Samuel Thibault wrote:
> Attached are the patches against rootskel and finish-install which I
> could test with success (provided the patch from bug #479227 is applied
> to kernel-wedge and the speakup module be added to
> linux-kernel-di-*-2.6)

I've just committed these patches in SVN with minor changes for coding
style [1]. It would be great if you could do a final test using a custom
build that includes the now committed changes and then we can discuss for
which architectures and in which images to actually include the speakup
modules.

The patch to kernel-wedge was already committed and uploaded.

Cheers,
FJP

[1] http://svn.debian.org/wsvn/d-i/trunk/packages/?rev=54314&sc=1

[Samuel Thibault]

Hello,

Frans Pop, le Mon 14 Jul 2008 20:04:48 +0200, a écrit :
> On Saturday 28 June 2008, Samuel Thibault wrote:
> > Attached are the patches against rootskel and finish-install which I
> > could test with success (provided the patch from bug #479227 is applied
> > to kernel-wedge and the speakup module be added to
> > linux-kernel-di-*-2.6)
>
> I've just committed these patches in SVN with minor changes for coding
> style [1]. It would be great if you could do a final test using a custom
> build that includes the now committed changes

Done so, it seems to work fine.  BTW, on
http://wiki.debian.org/DebianInstaller/Accessibility
I've put the steps to test it thanks to the dummy driver.

> and then we can discuss for which architectures and in which images to
> actually include the speakup modules.

Well, I don't think there is any architecture which shouldn't be
supported, except s390 on which speakup doesn't even compile.  As for
the images, I guess we can for now include it on the same images as
brltty, that would make things coherent (i.e. "accessible" images).
I have attached a documentation patch.

Samuel

Index: build/boot/x86/f8.txt
===================================================================
--- build/boot/x86/f8.txt (r�vision 53932)
+++ build/boot/x86/f8.txt (copie de travail)
@@ -12,6 +12,7 @@
 Force static network config             0fnetcfg/disable_dhcp=true07
 Set keyboard map                        0fbootkbd=es07
 Use Braille tty                         0fbrltty=driver,device,texttable07
+Use Speakup                             0fspeakup.synth=driver07
 Use high contrast accessibility theme   0ftheme=dark07
 Select the kde or xfce desktops         0fdesktop=kde07
 

[Frans Pop-3]

On Tuesday 15 July 2008, Samuel Thibault wrote:
> Well, I don't think there is any architecture which shouldn't be
> supported, except s390 on which speakup doesn't even compile.  As for
> the images, I guess we can for now include it on the same images as
> brltty, that would make things coherent (i.e. "accessible" images).
> I have attached a documentation patch.

I'm going to have to delay this discussion until I can see what the impact
on image size would be. The patch to include the modules was incomplete
and adding the missing bits causes build failures which means I currently
cannot see that impact easily enough to make the effort.
Otavio is looking into the issue.

Cheers,
FJP

[Samuel Thibault]

Hello,

Frans Pop, le Thu 17 Jul 2008 13:50:45 +0200, a écrit :
> On Tuesday 15 July 2008, Samuel Thibault wrote:
> > Well, I don't think there is any architecture which shouldn't be
> > supported, except s390 on which speakup doesn't even compile.  As for
> > the images, I guess we can for now include it on the same images as
> > brltty, that would make things coherent (i.e. "accessible" images).
> > I have attached a documentation patch.
>
> I'm going to have to delay this discussion until I can see what the impact
> on image size would be.

The speakup-modules package is 51K gz-compressed, 170K uncompressed
with a 1byte block size, 204K with a 4K block size.

Samuel


--
To UNSUBSCRIBE, email to debian-accessibility-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...