Re: Bug#834756: ITP: powershell -- scripting language interpreter built on .NET

[Mario Lang]

Christoph Egger  writes:

> Marcin Kulisz  writes:
>> Most likely I'm missing something but what's the use case for Powershell on
>
> I don't know, what's the usecase for tcsh or lua?

tcsh is to support legacy scripts, but, very good question: What *is*
the use-case for Lua actually? :-)

-- 
CYa,
  ⡍⠁⠗⠊⠕

Re: system upgrade by systemd

[Mario Lang]

Marc Haber  writes:

> On Tue, 25 Aug 2015 20:35:30 +0200, Matthias Klumpp  wrote:
>>This is a feature of systemd and PackageKit.
>>See http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
>
> Please disable this for Debian. Not tomorrow, do it today.

+1

-- 
CYa,
  ⡍⠁⠗⠊⠕

Re: debian github organization ?

[Mario Lang]

Ben Caradoc-Davies  writes:

> On 19/07/15 23:36, Florian Weimer wrote:
>> The single account policy means that users
>> would have to share authentication information across different roles,
>> which may not be acceptable.
>
> I am not sure why this would be unacceptable to anyone. Authentication
> is your ability to prove who you are. GitHub accounts provide
> this. Authorization is your permission to commit to repositories. Your
> authorization to commit to one repository has no effect on other
> repositories to which you have commit access.

I can very well see how this could be an issue to some.  I at least keep
a relatively strict separation between my work-related accounts and
everything I do privately.  That obviously applies to ssh keys for me.
A security breach at work will not compromise my Debian access tokens,
and vice versa.  While this is pretty obvious to me regarding ssh keys,
if that doesn't do it for you yet, try imagining to have the same
*password* for your work and Debian accounts.  These are things that
should be avoided IMO.

And if you are forced to share a GitHub account across organisations,
you loose your ability to have a bit of separation.

-- 
CYa,
  ⡍⠁⠗⠊⠕


pgpqGPN1ACkfv.pgp
Description: PGP signature

Re: JavaScript usage

[Mario Lang]

Thorsten Glaser  writes:

> On Sun, 31 Aug 2014, Octavio Alvarez wrote:
>
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
>
> Because I use lynx as browser.

+1

-- 
CYa,
  ⡍⠁⠗⠊⠕


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjei6s4a@fx.delysid.org

Re: Debian default desktop environment

[Mario Lang]

Jonathan Dowland  writes:

> We go over the same ground over and over. I'm increasingly in favour of *no*
> default. You must pick one from a list on install. Randomize the list if
> necessary.

The day Debian starts to randomize menu items I am going to stop using
it.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/>
  .''`. | Get my public key via finger mlang/k...@db.debian.org
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-  http://delysid.org/>  http://www.staff.tugraz.at/mlang/>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ioqax4hy@fx.delysid.org

Re: pulseaudio related problems....

[Mario Lang]

Paul Gevers  writes:

> On 21-02-14 10:57, John Paul Adrian Glaubitz wrote:
>> On 02/21/2014 09:29 AM, Mario Lang wrote:
>>> I am sorry, both are not an option for me, since alsamixer is a ncurses
>>> program, and pavucontrol apparently requires $DISPLAY to be set.
>>>
>>> I guess that explains why the accessibility community has
>>> problems with PA.
>> 
>> What's wrong with the accessibility mechanisms provided in GNOME
>> (screen reader, magnifier)? (Serious question). I had the impression
>> that accessibility works rather well in GNOME and upstream actually
>> puts efforts into making that happen.
>
> I think the point of Mario is that people like him don't have a DE, but
> work from console. I haven't checked, but apparently pavucontrol needs
> an X-session to show itself. Of course ALSA has the same problem that if
> you don't hear it you can't change it, but at least it doesn't require
> an DE just to change your sound settings (to get it to work).
>
> Maybe I haven't understood Mario's remark and I am fully wrong.

No, you have summarized it pretty neatly.
I just don't consider an X11 program a true alternative to a ncurses tool.

Having to get X11 + a11y configured just to be able to *properly* adjust
a volume slider is just hilarious.

-- 
CYa,
  ⡍⠁⠗⠊⠕


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r46w7d5u@fx.delysid.org

Re: pulseaudio related problems....

[Mario Lang]

John Paul Adrian Glaubitz  writes:

> I think most people simply don't configure PulseAudio correctly.
> They have the assumption that sound cards are still simple devices
> with one input jack and one output jack and any application using it
> just has to find the sound card and output its audio signal.
>
> It's not as simple as that anymore. Modern audio codecs have tons of
> options and volume controls, and - from my experience - most problems
> to PulseAudio relate to the sound card being incorrectly configured.
>
> To resolve this problem, people then try to use tools like alsamixer
> and naturally, since alsamixer doesn't know anything about PulseAudio,
> it cannot fully configure it.
>
> So, in order to be able to properly configure PulseAudio, install
> "pavucontrol" or use the sound preferences in GNOME3 or MATE (with
> the package mate-media-pulse being installed).

I am sorry, both are not an option for me, since alsamixer is a ncurses
program, and pavucontrol apparently requires $DISPLAY to be set.

I guess that explains why the accessibility community has
problems with PA.

-- 
CYa,
  ⡍⠁⠗⠊⠕


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878ut4zx4r@fx.delysid.org

Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.

[Mario Lang]

Stephan Seitz  writes:

> On Wed, Feb 12, 2014 at 11:39:06AM +, Darac Marjal wrote:
>>> But the normal case is that uninstalling a software you also stop
>>> getting the functionality it provides, with pulseaudio you START
>>> getting the functionality it claims to provide by uninstalling it.
>>Really? Uninstalling Pulseaudio gives you a graphical interface for
>>moving streams of audio between devices? Uninstalling Pulseaudio gives
>>you software mixing of audio streams? Uninstalling Pulseaudio gives you
>
> Alsa is using the DMIX plugin for years, and before that I always had
> soundcards with hardware mixing. Simply buy the proper tools.

That is what I was thinking as well, but just recently I had
to killall pulseaudio to be able to access my ALSA device again.

For me, pulseaudio falls into the same category as network-manager.
Whenever I had to deal with it, it didnt do what I expected.

-- 
CYa,
  ⡍⠁⠗⠊⠕


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lhxfrvk8@fx.delysid.org

Re: Valve games for Debian Developers

[Mario Lang]

Neil McGovern  writes:

> Immediately though, they've offered a free subscription to any Debian
> Developer which provides access to all past and future Valve produced
> games [1]!

I feel singled out.  As a blind DD, I can not play any of their games
since they are not accessible. :-/  OTOH, thats probably an advantage
for me, since I am not risking to waste alot of hours with unproductive
work. :-)

-- 
CYa,
  ⡍⠁⠗⠊⠕


pgp6NQxqBCBqW.pgp
Description: PGP signature

Re: idea -- apt-based init daemon

[Mario Lang]

hhm  writes:

> As is well known, init daemons in distros the distro-world over are
> replacing sysvinit.
>
> As far as I can tell, among the reasons for this phenomena is:
> 1) to take advantage of parallel processing
> 2) to work better with event-based systems (linux kernel etc.)
>
> Sysvinit was created in the age of synchronous computing systems, and
> it reflects this. Now systems are becoming more asynchronous.
>
> The way these things are addressed is often:
> 1) a dependency system
> 2) an event trigger system
>
> Well, does those two things sound familiar, by any chance :-)?
>
> Apt manages dependencies, and processes triggers. It was created for
> managing software packages...
>
> ...maybe it can be augmented with functionality to manage software services 
> too!

Is it first of April again?  I haven't even noticed!
This idea violates the KISS-principle.

-- 
CYa,
  ⡍⠁⠗⠊⠕


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87libu5xoj@fx.delysid.org

Bug#681499: ITP: bmc -- Braille Music Compiler

[Mario Lang]

Package: wnpp
Owner: Mario Lang 
Severity: wishlist

* Package name: bmc
  Version : 0.0.1
  Upstream Author : Mario Lang 
* URL or Web page : https://github.com/mlang/bmc
* License : GPLv3
  Description : Braille Music Compiler

BMC aims to become a system for translating between visual and tactile
western music notation.
It currently parses a subset of braille music code and can emit LilyPond
input files from that.  Export to other formats like MusicXML is
planned.
Eventually, BMC should also be able to convert from MusicXML to braille
music code.

It is intended as a bridge between visual and tactile music notation,
allowing for more and better cooperation between sighted and visually
handicapped musicians.

There is no official upstream release yet, the code is still only
available through github.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/>
  .''`. | Get my public key via finger mlang/k...@db.debian.org
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-  http://delysid.org/>  http://www.staff.tugraz.at/mlang/>


pgpDIvoWGwNWc.pgp
Description: PGP signature

Re: GDM, getty and VTs

[Mario Lang]

Josselin Mouette  writes:

> it’s been a long-standing tradition on Linux to have 6 started getty
> processes, in tty1 to tty6. However this doesn’t correspond anymore to
> the way we use our machines. 
>   * I don’t think we need more than 2 of these. They are still
> useful for servers or when some disaster happens in the GUI, but
> who opens 6 console sessions nowadays? 

I do, and I suspect that some blind users have a similar habit.
The point here is that X11 is really not stable enough for us to be
useful on a daily basis (at least that is my experience).  I still prefer
virtual terminals over any sort of X11 based terminal, if its not
for stability its for speed.  X11 terminals are noticeably more sluggish
than real virtual consoles, and the overhead involved in screen reading
is just ridiculous.

> To make things worse, the latest GDM upstream version doesn’t include a
> tty manager anymore. Each started X server will simply use the first
> available VT. Red Hat can afford to do that because their gdm is started
> by the inittab (which is really a bad idea, but well), but in Debian
> this means it takes tty1, stomping on the getty that gets launched here
> later.
>
> So before we start adding hacks on top of the existing, maybe now is the
> time to think about how we want to use our VTs.
>
> 1/ What should be on tty1? Ideally, we should have the display manager
> here if it is started, and we should have a getty otherwise. 

[...]

> 2/ How do we prevent bad interaction between console VTs and graphical
> VTs? (Of course this is closely related to question 1.)

I think graphical environments shouldn't start ignoring the existance of
VTs.
It certainly feels that way to me upon reading your description.


VTs have been around longer than X11, why do people have to forcefully
break things which perfectly worked in the past?

I think it is a misunderstanding to conclude that VTs are really
not useful anymore.  Linux has always been about choice (to me at
least), something I start to miss in recent years.


-- 
CYa,
  ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/>
  .''`. | Get my public key via finger mlang/k...@db.debian.org
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-  http://delysid.org/>  http://www.staff.tugraz.at/mlang/>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reminder: /usr/share/doc/${PACKAGE}/examples/

[Mario Lang]

Hi.

A comment from Martin F. Krafft in his talk today at DebConf9
reminded me that many of our binary packages do actually not include
the example files which are included in the source package.

I've been anoyed by this several times in the past already, and
wheenever I stumble across a binary package missing available example
files I file a bug.  I just did a quick check and found 2 out of
5 packages I looked at to have examples in the source package which are
not shipped with any binary package.

I will probably try to automate this process somewhat and file a lot
more bugs soon, but before I start this effort I'd like to remind
individual package maintainers to look at their packages and check if
they are providing example files that are not shipped yet.

As Martin said today, many of us actually like to start from some simple
templates, instead of creating something new completely from scratch.
I very very much agree with this.

So, please, remember policy 12.6, thank you.

http://www.debian.org/doc/debian-policy/ch-docs.html#s12.6

-- 
CYa,
  ⡍⠁⠗⠊⠕


pgpqpK9n7Ol0I.pgp
Description: PGP signature

Bug#537779: RFP: java-atk-wrapper -- An ATK implementation for Java using JNI

[Mario Lang]

Package: wnpp
Severity: wishlist

* Package name: java-atk-wrapper
  Version : 0.27.4
  Upstream Author : Ke Wang 
* URL or Web page : http://ftp.gnome.org/pub/GNOME/sources/java-atk-wrapper/
* License : LGPL 2.1
  Description : An ATK implementation for Java using JNI

Java ATK Wrapper is an implementation of ATK by using JNI. It
converts Java Swing events into ATK events, and send these events to
ATK-Bridge.

JAW is part of the Bonobo deprecation project. It will replace the
java-access-bridge after being fully tested.
By talking to ATK-Bridge, it keeps itself from being affected by the
change of underlying communication mechanism.

-- 
Thanks,
  ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/>
  .''`. | Get my public key via finger mlang/k...@db.debian.org
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-  http://delysid.org/>  http://www.staff.tugraz.at/mlang/>


pgpMXDVVgjgdt.pgp
Description: PGP signature

flite, screader and yasr are looking for a new maintainer

[Mario Lang]

Hi.

This is a call for help.  I'd like to reduce the number of packages
I am responsible for to hopefully improve the overall quality as a result.

If any DD is willing to help the debian accessibility effort, please
consider taking over one of the following packages: flite, screader, yasr.

eflite has a new upstream availabe, but will need patching to get shared library
support working again (the flite library is very big, and forcing apps to
statically include it is not acceptable).

yasr and screader are terminal screen readers mostly working like screen.
I dont really use either of them these days, but I think they are
still valuable to have around.  yasr does have a new upstream available.

-- 
Thanks,
  ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/>
  .''`. | Get my public key via finger [EMAIL PROTECTED]
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-  http://delysid.org/>  http://www.staff.tugraz.at/mlang/>


pgp1kG90qfDtu.pgp
Description: PGP signature

Bug#454349: RFA: biomode -- Emacs mode to edit genetic data

[Mario Lang]

Package: wnpp
Severity: normal

biomode is looking for a new loving and caring maintainer.

I dont have any use for it, so I feel I do a very poor
job of "maintaining" it.

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
  .''`. | Get my public key via finger [EMAIL PROTECTED]
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-  http://delysid.org/>  http://www.staff.tugraz.at/mlang/>



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [help] brltty: Java behaves strangely on different archs?

[Mario Lang]

Michael Koch <[EMAIL PROTECTED]> writes:

> On Sun, Nov 18, 2007 at 12:57:47AM +0100, Mario Lang wrote:
>> Hi.
>> 
>> One of my packages (brltty) recently gained Java bindings for its API.
>> Now since I added the usage of gcj to brltty, I see that the java toolchain
>> seems to be quite out of sync on different archs in different ways.
>> 
>> At first everything worked here on amd64, but when I uploaded I saw
>> the i386 build failing[1], the builddeps were all there but the java bindings
>> are somehow not built and therefore dh_install fails.
>> Then I noticed in the same run that on arm, the build-deps couldn't be
>> satisfied[2].
>> Later on, the problem on i386 vanished magically[3] and it just autobuilds
>> fine there now.  But the same problem as I saw on i386 originally
>> now seems to persist at least on alpha[4].  arm still can't install
>> the build-deps.  This is about 2 months later since I first uploaded
>> the java-using version of brltty...  I was originally hoping
>> this would all just sort out by itself.  Now that I'd actually need
>> brltty to go to testing for other reasons, I am sort of lost.
>> 
>> This is a call for help.  If you have any idea or can shed a little
>> light on the whole issue, please let me know what I can do to fix this
>> and get brltty in testing.  I *know* I could remove the java support again,
>> but I'd like to make sure there is no other way before doing so.
>> 
>> [2] 
>> http://buildd.debian.org/fetch.cgi?&pkg=brltty&ver=3.8-6&arch=arm&stamp=1188732968&file=log
>
> GCJ is not really working on arm. You can just forget about this.

Thanks, I've disabled building java bindings on arm now.

>> [4] 
>> http://buildd.debian.org/fetch.cgi?&pkg=brltty&ver=3.9-2&arch=alpha&stamp=1195173383&file=log
>
> You should use /usr/lib/jvm/java-gcj as JAVA_HOME with
> java-gcj-compat(-dev) and not /usr. Never use /usr/bin/javac,
> /usr/bin/java, etc. when building packages. You never really know where
> this points to.

Thanks a lot for this one!  The problem on alpha is now gone.

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
  .''`. | Get my public key via finger [EMAIL PROTECTED]
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-  http://delysid.org/>  http://www.staff.tugraz.at/mlang/>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[help] brltty: Java behaves strangely on different archs?

[Mario Lang]

Hi.

One of my packages (brltty) recently gained Java bindings for its API.
Now since I added the usage of gcj to brltty, I see that the java toolchain
seems to be quite out of sync on different archs in different ways.

At first everything worked here on amd64, but when I uploaded I saw
the i386 build failing[1], the builddeps were all there but the java bindings
are somehow not built and therefore dh_install fails.
Then I noticed in the same run that on arm, the build-deps couldn't be
satisfied[2].
Later on, the problem on i386 vanished magically[3] and it just autobuilds
fine there now.  But the same problem as I saw on i386 originally
now seems to persist at least on alpha[4].  arm still can't install
the build-deps.  This is about 2 months later since I first uploaded
the java-using version of brltty...  I was originally hoping
this would all just sort out by itself.  Now that I'd actually need
brltty to go to testing for other reasons, I am sort of lost.

This is a call for help.  If you have any idea or can shed a little
light on the whole issue, please let me know what I can do to fix this
and get brltty in testing.  I *know* I could remove the java support again,
but I'd like to make sure there is no other way before doing so.

[1] 
http://buildd.debian.org/fetch.cgi?&pkg=brltty&ver=3.8-6&arch=i386&stamp=1188733192&file=log
[2] 
http://buildd.debian.org/fetch.cgi?&pkg=brltty&ver=3.8-6&arch=arm&stamp=1188732968&file=log
[3] 
http://buildd.debian.org/fetch.cgi?&pkg=brltty&ver=3.8-7&arch=i386&stamp=1189354533&file=log
[4] 
http://buildd.debian.org/fetch.cgi?&pkg=brltty&ver=3.9-2&arch=alpha&stamp=1195173383&file=log

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
  .''`. | Get my public key via finger [EMAIL PROTECTED]
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-  http://delysid.org/>  http://www.staff.tugraz.at/mlang/>


pgpCvLvuWmVp6.pgp
Description: PGP signature

Bug#428174: O: oleo -- GNU spreadsheet program

[Mario Lang]

Package: wnpp
Severity: normal

I have neglected this package for far to long, my apologies.

I originally adopted it to prevent it from being removed from the archive,
since I was using it from time to time.  These days, I have not used
it for very long.  Additionally, I was only interested in oleo
for its text-mode interface.  I understand that it offers
a graphical (non-gtk) interface as well these days.  Since I can
only use ATK-aware apps, I could not test this aspect of
the package, so I do not feel appropriate as a maintainer anymore.

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
  .''`. | Get my public key via finger [EMAIL PROTECTED]
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-  http://delysid.org/>  http://www.staff.tugraz.at/mlang/>


pgpkLkM6PpsUp.pgp
Description: PGP signature

Bug#428168: RFA: flite -- A small run-time speech synthesis engine

[Mario Lang]

Package: wnpp
Severity: normal

flite is basically a C version of festival, compiling all
the necessary data for speech synthesis down to a library which
gets linked into programs that do want to do text-to-speech.

There is #350484 which needs to be dealt with.  When flite 1.2
was released, I worked directly with upstream to integrate a patch
which allowed to build the library also as shared object
files, not just statically.  This is obviously important
for a distro since the flite library is pretty huge (8MB or so) and
to link it into every package that uses it is extreme archive bloat.
Unfortunately, the 1.3 release seems to have dropped
this feature, and my initial attempt at looking on how
to refix .so support failed.  I've since then heard Fedora
carries a patch to do this.  So maybe it isn't that hard
to get 1.3 into Debian after all.

However, these days, I find espeak much more promising for
the future (especially since it does provide multilanguage support),
and my free time does not permit me to maintain several speech engines
anymore (at least, I am not motivated enough to do a good job, obviously).

I'd like to find a good home for flite.  It does have three other
packages depend on it that I know of, speech-dispatcher, eflite
and brltty.

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
  .''`. | Get my public key via finger [EMAIL PROTECTED]
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-  http://delysid.org/>  http://www.staff.tugraz.at/mlang/>


pgphPrHFsfsEw.pgp
Description: PGP signature

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[Mario Lang]

Jari Aalto <[EMAIL PROTECTED]> writes:

> FOREWORD
>
> I have seen following construct to be used in shell-context
> (makefiles, sh-scripts, Perl):
>
>   `cmd` [1]
>
> However, the POSIX standard and SUSv[23] declares alternative way of
> accomplishing the same with in *sh context:
>
>   $(cmd) [2]
>
> I would see following problems quality wise with [1]:
>
> - The backtick version is not easily readable in high resolution screens
>   or in terminals with small fonts 
>
> - There may be problems in distinguishing character ' from ` with sme
>   particularly selected font.
>
> - The missing backtick is hard to find in highly quoted context, where
>   single, double quotes and backticks play the code tune.
>
> - The backtick is awkwardly located in some keyboards. (possible
>   orphan/adopt/NMU maintenance problem)
>
> - Lastly, isually impaired people have problems with non-easily
>   dintinguishable content. ' and ` fall into this category.

I am 100% blind, and I use ``.  Its not that braille does care
if glyphs are undintinguishable...  Your argument talks
about visually impaired people that still use their eyes for reading...
And it sounds rather contrived if you ask me.

I wouldn't consider `` usage a bug, not at all.  In fact, since
there is $(()) and $(), I consider `` more clear.  If you talk
about unreadability, sed expressions are probably something you should
try to replace :-).  There are surely tons of other things you
could patch in typical shell scripts that make them more readable
and maintainable.

-- 
CYa,
  Mario


pgpQRXNQjIFuP.pgp
Description: PGP signature

Re: FSG Packaging Summit in Berlin

[Mario Lang]

Joey Hess <[EMAIL PROTECTED]> writes:

> Jonathan Corbet wrote:
>>  Debian will get the Etch release out this year. Honest. What
>>  could possibly go wrong? Thereafter, the Debian developers will
>>  go back to arguing about firmware in the kernel.
>> 
>> Honestly, it was not my intent to insult anybody.  I'm sorry if I did.
>> But, being the socially-challenged person I am, I still don't understand
>> how that could be.
>
> As I read it, there's an implication that all I, as a DD, am good for is
> failing to get Debian releases out and spending all my time in pointless
> discussion. I don't really feel that accurately describes me.

Come on, what happened to Debian recently?  I miss the times when we
simply said "xxx will release when it is ready".  In my book, such
statements are what we deserve for pretending to have a crystal ball.
We should never have started to publicly predict release dates IMO.
Commercial vendors can predict release dates if they like, but
volunteer based projects shouldn't IMO, at least not those that are as
large as Debian is.

I find this kind of amusing, and am NOT offended by such a statement.

And, there is a bit of truth in the sarcasm, isn't there?

Oh, I love sarcasm, its one of these things that make life worth living!

-- 
CYa,
  Mario


pgpWGqttot8Es.pgp
Description: PGP signature

Re: Bug#354831: ITP: bfc -- Brainfuck compiler

[Mario Lang]

Henning Makholm <[EMAIL PROTECTED]> writes:

> Scripsit Panu Kalliokoski <[EMAIL PROTECTED]>
>
>> * License : BSD-like
>>   Description : Brainfuck compiler
>
> What is this useful for?

Curling braincells...  I once wrote a Emacs Lisp implementation[1]
of a BrainFuck compiler, its probably the simplest kinda-useful
compiler you can implement.

If someone wants to add this t emacs-goodies-el, I am fine with it :-)

http://delysid.org/emacs/bf.el

-- 
CYa,
  Mario


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debconf and cdebconf are coinstallable now

[Mario Lang]

Martin Michlmayr <[EMAIL PROTECTED]> writes:

> * Colin Watson <[EMAIL PROTECTED]> [2006-03-02 05:08]:
>> Joey has been campaigning [1] for a while to get everything in the
>> archive changed to depend on debconf | debconf-2.0 or similar rather
>> than just debconf, in order that we can start rolling out cdebconf
>> as its replacement.
>
> It would be nice if you could tell _why_ you're interested in
> migrating to cdebconf.  What does it have that debconf doesn't, or
> what other advantages does it have?  Is it easier to maintain,
> smaller, ...?

Two reasons I can think of: Its smaller, and it does not depend on perl.

-- 
CYa,
  Mario


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#312660: ITP: shish -- the diet shell

[Mario Lang]

Gerrit Pape <[EMAIL PROTECTED]> writes:

> On Thu, Jun 09, 2005 at 02:38:06PM +0200, Michael Prokop wrote:
>> * Package name: shish
>>   Version : 0.7-pre3
>>   Upstream Author : Roman Senn <[EMAIL PROTECTED]>
>> * URL : http://www.blah.ch/shish/
>> * License : GPL
>>   Description : the diet shell
>> 
>> shish is a shell language interpreter and an interactive command
>> line interpreter.
>> 
>> This shell aims at being very small and doing its tasks in
>> efficient ways (and not through 100 abstraction layers), which
>> is mainly done by using the dietlibc and libowfat libraries.
>> 
>> shish will be a POSIX compatible shell language interpreter
>> according to the IEEE P1003.2 Draft 11.2 by its 1.0 release.
>
> He, here's a challenge..
>
> $ DEB_BUILD_OPTIONS=diet fakeroot apt-get source -b dash >/dev/null 2>&1 &&
> ls -l dash-0.5.2/debian/dash/bin/dash && ldd $_
> -rwxr-xr-x  1 pape pape 75080 Jun 10 07:59 dash-0.5.2/debian/dash/bin/dash
> not a dynamic executable

-rwxr-xr-x  1 mlang mlang 74352 Jul 25 17:52 dash-0.5.2/debian/dash/bin/dash
not a dynamic executable

gcc 4 :-)

-- 
CYa,
  Mario


pgpaeufljTx3D.pgp
Description: PGP signature

Re: Help needed: People willing to help co-maintain debian accessibility packages

[Mario Lang]

Joey Hess <[EMAIL PROTECTED]> writes:

> Mario Lang wrote:
>> * speakup: A co-maintainer on this one would be wonderful.  I once bought
>>   a hardware speech synthesizer for testing speakup, but since
>>   my primary output medium is still braille, it doesn't get as
>>   much attention as I'd wish it should.  Besides, I always
>>   had those strange lockups when speakup tries to deliver a lot
>>   of speech to the serial port, which very badly interacts
>>   with my other pet interests, namely low-latency audio work,
>>   so I had to finally stop using the prebuild speakup kernel images 
>> myself... :(
>
> FWIW, this kernel varient (kernel-image-speakup-i386) also currently
> FTBFS and has dozens of unfixed security bugs (which are fixed in the
> general Debian kernel source it builds from), so it's looking quite
> likely to be removed if these RC bugs arn't addressed sometime.

Yes, I am aware of this, and I'd like to thank you for your previous NMU joey.

> Fixing it is probably pretty easy, it just needs to use an older gcc for
> building.

I'd rather prefer to use a newer speakup which works properly with
gcc 4.  The current patch used is pretty old, and adding yet another workaround
doesn't feel like moving much forward.  Besides, It'd probably make
sense to switch to 2.6 for kernel-image-speakup-i386 at some point.  This will
involve quite a bit of d-i hacking I guess... I'll seriously try to allocate
the required time to get this done as soon as possible, however, the offer
still stands, if someone wants to work on speakup, I am very happy about this.

Again, I am aware that I fucked this kernel package up pretty badly due to
nonresponsiveness, and I'd like to publicly say sorry.  And thanks for
helping out at least a bit joey.

-- 
CYa,
  Mario


pgp3XkMiGm1dw.pgp
Description: PGP signature

Re: Help needed: People willing to help co-maintain debian accessibility packages

[Mario Lang]

Frans Pop <[EMAIL PROTECTED]> writes:

> On Monday 25 July 2005 15:20, Mario Lang wrote:
>> We seriously need people willing to help maintain various a11y related
>> packages.
>
> During DebConf5 Joey Hess also called for help with the "speakup" 
> installation images [1]. Currently we only offer "speakup" floppy 
> installation. Adding CD installation to that would be very nice.

This point was actually already mentioned in my posting.

> [1] http://www.debian.org/releases/stable/debian-installer/index#speakup

-- 
CYa,
  Mario


pgpPQghMKmuQt.pgp
Description: PGP signature

Help needed: People willing to help co-maintain debian accessibility packages

[Mario Lang]

Hi.

As many of you might already have noticed, I recently didn't have as
much time for Debian related work as I'd wish (or as the size of the
packages I'm involved in would require).  It is now about 2
years since the Debian Accessibility project started, and the number
of active maintainers of accessibility packages seems to actually go down.
For instance, the Emacspeak maintainer recently gave up emacspeak
and asked me to take over maintainership.  Since I very rarely use
Emacspeak these days, it is just yet another thing adding to my TODO list...
I actually tried to prepare an upload of emacspeak 21 for
several hours, but since something obscure kept breaking I finally
gave up on it for a while.

We seriously need people willing to help maintain various a11y related
packages.

I'd like to get help on the following packages:
* Emacspeak: Someone to fully take this over would be ideal.
  I've already asked Sam Hartman but he doesn't have time either
  and would only take emacspeak over if not doing so would mean it
  gets removed from the archives.  We are at release 17, while
  upstream is at release 22. Tasks which would need doing are:
  * Get emacspeak-22 into unstable
  * Get rid of non-debconf prompting

  You should be able to work on elisp packages fairly independently,
  don't expect upstream to give you much help.

* speakup: A co-maintainer on this one would be wonderful.  I once bought
  a hardware speech synthesizer for testing speakup, but since
  my primary output medium is still braille, it doesn't get as
  much attention as I'd wish it should.  Besides, I always
  had those strange lockups when speakup tries to deliver a lot
  of speech to the serial port, which very badly interacts
  with my other pet interests, namely low-latency audio work,
  so I had to finally stop using the prebuild speakup kernel images myself... :(

Besides, we'd need people to work on specific tasks which involve
several packages:
* A framework for building drivers for commercial software speech
  synthesizers on Debian is needed.  Examples include
  gnome-speech and Emacspeak.  I am not a fan of non-free software,
  but in the area of software speech, free software is not delivering
  what the users require, so there are actually some commercial
  software speech packages out there which are used by
  the typical blind user using speech.  We sould make it as easy as possible
  for those users to install support for their favourite commercial synth
  into backends like gnome-speech.  This is obviously a quite involved
  task, since in the end it means the person doing this would
  need to buy most of the available software for testing.
* We should assess what the current situation regarding
  gnopernicus and Java-based applications or OpenOffice
  is.  What would need to be done to make gnoperncius
  support Java apps on Debian out of the box?  Can it be done
  with the currently available Java tools in Debian or is
  a (non-free) JDK required?  If so, what would be needed to make
  gnopernicus/OpenOffice cooperate with the free java tools?
* A access initrd for Debian-Installer CDs would be needed.
  Currently, accessibility drivers are only available via the
  access floppies.  As we all know, floppies are legacy these days,
  and we should offer these drivers on the standard CD.  AIUI, a special
  isolinux target with a special initrd should suffice.  Someone
  with debian-cd and debian-installer background, or the willingness
  to learn a lot, would be required for this task.

If you want to help improve overall a11y of Debian, this
is your chance.  As usual, volunteering for one of these jobs
automatically means you accept to work within the Debian framework,
i.e. you go with Debian Policy.  I can sponsor packages
if someone not yet in Debian wants to help, but only
if: 1) That person actually knows what he/she is doing.  The idea of this
call for help is to get some work off my back, not to add even
more.  If I have to doublecheck every single line of changes you
do, this is not helpful.   and 2) you should consider applying
as a Debian developer.  I am not happy with sponsoring people
who actually dont want to be official developers at some point
in the near future.

Accessibility, as some of you may know, is one of the painful
areas in Free software.  Usually, people scratch their own itches,
and so bugs get fixed, but accessibility involves 1) very small
specialized groups of people and 2) many different types of these
small groups.  So there are a lot of unsolved problems out there, and
very few people actually interested to solve these.  If you
are looking for an area of Free Software development that really
needs (wo)manpower, consider helping to make Free Software (and
Debian in particular) more useable for people with various disabilities.

Perhaps some more words of clarification:  I am definitely *NOT* planning
on leaving the project, I'd just like to see more active development then
I can curren

Re: many .pc files in wrong package / mass bugfiling?

[Mario Lang]

Rene Engelhard <[EMAIL PROTECTED]> writes:

> Many packages are buggy and include the .pc file in the main package (not the 
> -dev).
>
> Mass bugfiling with allowed? Which severity?
>
> A quick apt-file search on sarge/i386 shows:
>
> $ apt-file search \.pc | grep pc$ | grep pkgconfig | grep -v dev

[...]

> gnopernicus: usr/lib/pkgconfig/gnopernicus-1.0.pc

Gnopernicus has no -dev package at all, but it still installs some libraries
with .pc files.  I'd rather not split it up in several packages, since
for now it seems quite unlikely that someone really has to link against
the library without having the main package installed.

All in all, please none such bug for gnopernicus, i'd just close it again.

-- 
CYa,
  Mario


pgp9ulYGva9rC.pgp
Description: PGP signature

Re: Grsec/PaX and Exec-shield

[Mario Lang]

Peter Busser <[EMAIL PROTECTED]> writes:

>> On Tue, 04 Nov 2003, Peter Busser wrote:
>> > In fact, anyone can do it Russell, I'm pretty sure even you can do
>> > it:
>> Why not volunteer to make the .deb, get a sponsor and get it uploaded
>> then?
>
> Good idea! Already did that in fact. So who do I send this new kernel-source
> .deb to?

I sincerely hope that you did not create a prepatched kernel-source
package.  OTOH, this would explain a lot about your mails on d-d.

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
| Get my public key via finger [EMAIL PROTECTED]
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

Bug#211014: initscripts: Do not remove /var/un/brltty.pid

[Mario Lang]

Miquel van Smoorenburg <[EMAIL PROTECTED]> writes:

> On Mon, 15 Sep 2003 12:17:37, Mario Lang wrote:
>> Package: initscripts
>> Version: 2.85-7
>> Severity: minor
>> Tags: patch
>> 
>> Package brltty needs to use a pid-file mechanism for
>> start-stop-daemon, since automatic restarting on upgrade is
>> no good idea for this software.
>> 
>> BRLTTY also needs to be started as early as possible in the
>> boot process.  Currently, it is at S25, but I'd even like
>> to have it earlier in the future.
>> 
>> However, bootmisc.sh removes /var/run/brltty.pid, which
>> results in /etc/init.d/brltty stop no longer working.
>
> Yes, that is a known problem, for which noone has found
> a proper solution yet (it's also a /hard/ problem)
>
> Problem: clean /var/run as soon as it is mounted
> Complication: what if /var or /var/run is mounted
> from the network in /etc/rcS.d/   ?

Well, it seems as if the case of /var over Network is
not really very wide-spread.  But I see your point.

> Also, for you to think of - what if brltty is run on a system
> which mounts /var or /var/run over the network at
> S45mountnfs.sh ? You really can't assume /var/run is
> even available at S25brltty. See also /etc/rcS.d/README.

Well, however, the FHS demands that I place pid-files in /var/run.

To clarify my point, having BRLTTY start early is really essential.
Especially before file-system checks.  If your machine ever happens
to get in a state where fsck fails and demands manual interaction,
you really need Braille output to be able to fix the machine on your own.
Same is for just fs-check.  It would be nice to be able to see
the progress bar, instead of having to hope for the best.
Put in other words, imagine video output only being available
after S55.  I dont think you would like that.

>> Attached is a patch against bootmisc.sh which adds
>> brltty.pid to the exclude list.  I think this is the
>> right way to go, since there are already two other special cases
>> (for innd and pump) there.
>
> It's the wrong way to go - the proper solution should enable us
> to get rid of the special cases, not add to it.

I can see your point.  However, I can not see a obvious
solution for the problem at hand for brltty in the near future.  I would need
to find a way to eihter
 * Save pid-files somewhere else, which violates FHS
 * Do not use pid-files at all, and find another mechanism to make
   start-stop-daemon work reliably.

In any case, if you really think that no special cases
should be added, I will file another bug requesting the removal of
the currently existing special cases.

>> This is, for brltty, a fairly important bug currently.
>> So if you do not have time currently, please let me know
>> and I will do a proper NMU with this included.
>
> Please find a proper solution - brltty should not use /var/run
> before it is officially available.
>
> Perhaps brltty should include a rcS file at say S70 that does
> a "pidof brltty" and writes the result to /var/run/brltty.pid ?

Ugh, sorry, but this 
 1. Sounds horrible
 2. Is not reliable.  Since BRLTTY 3.3, brltty has several instances
(three) running.  So a "pidof brltty" returns 3 PIDs.  And in any case,
it sounds a lot more broken to me having to create a pid-file
twice in the boot process.  After all, FHS says:

"This directory contains system information data describing the system
since it was booted. Files under this directory must be cleared
(removed or truncated as appropriate) at the beginning of the boot
process."

I dont quite think that S55 is really "at the beginning of the boot process."

> This bug should really be reassigned to brltty itself ;)
I am not sure.  Currently, I still think a change to initscripts
is required to fix this problem.

Maybe cleaning up /var/run could be done earlier, if /var | /var/run
has no entry in /etc/fstab.  This way, at least the standard
setup would work, and only people who want to have /var | /var/run on
NFS, would need to do further modifications to their systems.

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
| Get my public key via finger [EMAIL PROTECTED]
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

Re: debconf 2005 in Vienna, Austria

[Mario Lang]

Gerfried Fuchs <[EMAIL PROTECTED]> writes:

> I'd like to start organizing the debconf for the year 2005 in Vienna,

Great idea!

-- 
CYa,
  Mario

Re: update-alternatives priorities for editors

[Mario Lang]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> On Fri, 25 Jul 2003 09:21:47 +0100, Colin Watson <[EMAIL PROTECTED]> said: 
>
>> /usr/bin/editor is not only something invoked directly. It's also
>> invoked by programs as the default editor. And, if vim is the only
>> editor installed on the system, it had better be the default editor
>> for such programs! 
>
>   Is that not an argument for emacs also providing
>  /usr/bin/editor alternatives, since emacs may be the sole editor on
>  the system?

It might just not be very useful by default since Emacs usually takes quite
some time to startup, and therefore people prefer to use emacsclient
if they really set $EDITOR to something emacsish.  OTOH, for
emacsclient to work, you actually need some code in your .emacs,
like

(add-hook 'after-init-hook 'server-start)

P.S.: Tip of the day

(add-hook 'server-done-hook
  (lambda ()
(shell-command "screen -r -X select `cat 
~/tmp/emacsclient-caller`")))

-- 
CYa,
  Mario

Re: Developer Accessible Hurd Machine

[Mario Lang]

Michael Banck <[EMAIL PROTECTED]> writes:

> Anyway, you can still try to install the Hurd yourself on a free
> partition, for example using the crosshurd package. Most people have an
> i386, so it's just a matter of perhaps freeing some disk-space and
> reading the docs. If it doesn't work with your hardware or you run into
> big problems, you will not have lost a lot of time.

I'd need to port brltty first, before being able to boot a native Hurd.
I could rpobably get it up and running using bochs, but I did not try this yet.

OTOH, the whole port seems miles away from releaseable state,
so I wonder why I should bother.  If there is no permanent buildd running,
I think most developers will not be able to identify
hurd specific problems, even if they were very minor.

-- 
CYa,
  Mario

Re: Developer Accessible Hurd Machine

[Mario Lang]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

"Benj. Mako Hill" <[EMAIL PROTECTED]> writes:

> Some time ago, Martin Schulze pointed out that there is no developer
> accessible Hurd machine available.
>
> I am happy to coordinate the donation of hardware for this if it is
> this something that you (developers, Hurd and otherwise) feel would be
> useful and possible? However, I've heard that Hurd is still unstable
> enough that we will probably need to place the machine at a Hurd
> developer's home or work.
>
> -devel: Is this something developers would like?

I'd like to see something like this happening.  I've already wanted a developer
accessible Hurd machine several times, for investigating the possibility
to port some of my packages.

I think such a machine would be valuable to increase the quality
of the Hurd port overall.  Most of my packages do never get built on hurd,
although that might actually be related to a lack of buildds?

- -- 
CYa,
  Mario
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQE++MLI3/wCKmsRPkQRAjlWAJ9zAMgaML0MueADLfHiDijYRqRKXQCfRymO
1XALGh626gJQkT3KHV+SgYk=
=EKkC
-END PGP SIGNATURE-

Re: Bug#198190: ITP: upx-ucl-beta -- an efficient live-compressor for executables (beta version)

[Mario Lang]

Peter Makholm <[EMAIL PROTECTED]> writes:

> Robert Luberda <[EMAIL PROTECTED]> writes:
>
>> I intend to package an unstable (beta) version of upx.
>> This version supports compresing of the Linux kernel and thus 
>> can be used by our boot floppies team.
>
> Isn't the kernel already compressed?

It is, using gzip.  upx repacks it using its own
algorithm, which usually results in a kernel about
100kb smaller.

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
| Get my public key via finger [EMAIL PROTECTED]
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

Re: package naming

[Mario Lang]

"Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:

> Hi,
>
> On Mon, Jun 02, 2003 at 03:15:19PM -0400, Deedra Waters wrote:
>
>  > I've been working on the package "kernel-patch-speakup" which has a
>  > source package called speakup-cvs and produces the binary called
>  > kernel-patch-speakup_20021221-1_all.deb, well, there is a stable
>  > version of speakup that I'd like to package  and have it keep the
>  > kernel-patch-speakup name. This source package is called speakup, and
>  > produces a similar binary called "kernel-patch-speakup_1.5-1_all.deb"
>
>  > The problem currently is that the new source package produces a
>  > binary package which already exists, and is generated by a different
>  > source package
>
>  I am not sure I understand why that's a problem.  The only thing you
>  have to take into account is adding an epoch to the new
>  kernel-patch-speakup,

Sure, the epoch is of course necessary.  What I am wondering about is how
katie will react if a source package is uploaded which produces a binary
package which is already produced by another source package.

I.e., is there any thing one would need to be careful about, or
does this Just Work?

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
| Get my public key via finger [EMAIL PROTECTED]
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

Re: Bug#192416: ITP: rsh-redone -- Reimplementation of remote shell tools.

[Mario Lang]

Andrew Suffield <[EMAIL PROTECTED]> writes:

> On Thu, May 08, 2003 at 01:24:58PM +0200, Guus Sliepen wrote:
>> On Thu, May 08, 2003 at 01:56:18PM +0300, Lars Wirzenius wrote:
>> 
>> > > Rsh-redone is a reimplementation of the remote shell clients and
>> > > servers.  It is written from the ground up to avoid the bugs found in
>> > > the standard clients and servers.
>> > 
>> > Such as transmitting passwords in cleartext or relying on IP numbers for
>> > authentication?
>> 
>> Sigh, you're obviously trolling.
>
> So that would be a "no", then?
>
>> If you have a network that is already
>> secure (for example, behind a decent firewall, or a VPN), using ssh only
>> means lots of unnecessary overhead. The lack of security in rsh is not a
>> bug, it is just the way it is supposed to work.
>
> Security should be end-to-end, not point-to-point. The sheer number of
> times a site has been compromised because their "secure" network
> wasn't and somebody was using rsh...

Erm, as a Beowulf cluster administrator, I can assure you that there are
uses for rsh.

In a cluster environment, ssh is just overkill.

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
| Get my public key via finger [EMAIL PROTECTED]
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

Bug#172539: lynx: Should have SHOW_CURSOR:TRUE by default

[Mario Lang]

Package: lynx
Version: 2.8.4-2
Severity: wishlist

Quoting from /etc/lynx.cfg:

# SHOW_CURSOR controls whether or not the cursor is hidden or appears
# over the current link in documents or the current option in popups.
# Showing the cursor is handy if you are a sighted user with a poor
# terminal that can't do bold and reverse video at the same time or
# at all.  It also can be useful to blind users, as an alternative
# or supplement to setting LINKS_AND_FIELDS_ARE_NUMBERED or
# LINKS_ARE_NUMBERED.

This "hiding" of the cursor does not only have a visual effect, it also
has the effect that the currently highlighted item (link, popup menu item)
is only highlighted by setting the color attributes of the partiuclar text.
The cursor is usually left in the last line somewhere around the last column.
This kind of highlighting is hard to support for braille display and speech
based screen readers.  Usually, those screen readers use the position
of the cursor to indicate to the user what is currently "highlighted".

Since lynx is one of the most popular web browsers for blind users,
I think we should turn this option on by default.

-- 
Thanks,
  Mario

Bug#170848: pstotext: copiousoutput "support" for Lynx

[Mario Lang]

Package: pstotext
Version: 1.8g-5
Severity: minor
Tags: patch

Lynx does currently not honor the copiousoutput flag in /etc/mailcap.

See
 
http://www.google.com/search?q=cache:www.flora.org/lynx-dev/html/month042000/msg00531.html
for the only evidence I could find about why it doesn't work.  The message
implies that it will not get fixed very soon.

Since it appears  a quite correct test can be made to detect pstotext
usage under Lynx, I've attached a patch against debian/mime.
Tested, and works fine.  No longer watching thousands of lines
scroll by after you've waited for a 4MB pdf file to download! :)

--- mime2002-11-26 22:54:30.0 +0100
+++ /usr/lib/mime/packages/pstotext 2002-11-26 22:54:13.0 +0100
@@ -1,3 +1,6 @@
-application/postscript; pstotext %s; copiousoutput; description="PostScript 
document"; priority=4
-application/ghostview;  pstotext %s; copiousoutput; description="PostScript 
document"; priority=4
-application/pdf; pstotext %s; test=expr `gs --version` ">=" 3.51 >/dev/null 
2>&1; description="Portable Document Format document"; priority=2
+application/postscript; pstotext %s; test=test -z "$LYNX_VERSION"; 
copiousoutput; description="PostScript document"; priority=4
+application/postscript; pstotext %s | /usr/bin/pager; test=test -n 
"$LYNX_VERSION"; description="PostScript document"; priority=4
+application/ghostview;  pstotext %s; test=test -z "$LYNX_VERSION"; 
copiousoutput; description="PostScript document"; priority=4
+application/ghostview;  pstotext %s | /usr/bin/pager; test=test -n 
"$LYNX_VERSION"; description="PostScript document"; priority=4
+application/pdf; pstotext %s; test=test -z "$LYNX_VERSION" && expr `gs 
--version` ">=" 3.51 >/dev/null 2>&1; copiousoutput; description="Portable 
Document Format document"; priority=2
+application/pdf; pstotext %s | /usr/bin/pager; test=test -n "$LYNX_VERSION" && 
expr `gs --version` ">=" 3.51 >/dev/null 2>&1; description="Portable Document 
Format document"; priority=2

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
| Get my public key via finger [EMAIL PROTECTED]
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

Re: Debian Accessibility Project was: Re: linux for blinds

[Mario Lang]

Milan Zamazal <[EMAIL PROTECTED]> writes:

>>>>>> "ML" == Mario Lang <[EMAIL PROTECTED]> writes:
>
> ML> I now took the time and summarized the current state of things
> ML> regarding accessibility and Debian, and also tried to give a bit
> ML> of overview which areas could use help from people.  
>
> BTW, there's the Free(b)deb project
> (http://www.freebsoft.org/project-freebdeb.html), aiming at producing a
> customized Debian-based distribution for the blind and visually
> impaired.  The project has received some sponsorship recently and we
> hope to produce a usable installation CD or DVD during the next year.

Great!  I'd be happier if you'd try to go maintream from the beginning
on, but knowing the field and nature of the problem, I can understand
your decision and wish you lcuk!

> Our resources are quite limited, so we try to achieve the simplest
> imaginable goal as the first step -- to produce a medium that can be
> used to install and configure a limited set of the most important
> packages (from the point of view of the visually impaired people)
> easily.

Which primary aim do you have there? Speech output?  Braille output?
Which software do you plan to use?

> "Easily" means in such a way, that a non-impaired knowledgeable
> (i.e. one who is a bit familiar with system administration and has
> read the accompanied documentation) person can install several
> systems without big troubles in short time on a common hardware,
> e.g. during an installfest, and get them running in a usual way.

I know Debian-Installer isn't ready for prime-time yet, but just to
let you know I've now comitted brltty-udeb to the i386 cdrom package
list.  From what I could test, it should just work.  Far from blind
friendly yet, but it's a start.

> From the technical point of view, we're just at the beginning.

The Debian Accessibility Project is too.  I'd like to see combined
forces wherever possible.  Lets just try to avoid too much
duplication.

(BTW, see Bug#170692, that might help)

> Anyone interested in participation is welcome to subscribe to the
> developers' mailing list ([EMAIL PROTECTED]).

I've immediately subscribed to your developer list (although there is
something wrong with the subscription system, it refuses to accept my
From: header, but instead subscribed my Sender: header, which is not
quite right).

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
| Get my public key via finger [EMAIL PROTECTED]
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

[buildd] brltty

[Mario Lang]

Hello.

I noticed that buildd doesn't build brltty since 2.98-2.

Well, I know I originally just had i386 in the architecture field, but 
I am currently working with the upstream maintainer to
fix alot of different architectures, and it would be nice
if buildd could build brltty again on all archs listed in
the architecture field.

Could anyone tell me what to do to achieve this again,
or whom to write about it?

-- 
CYa,
  Mario