Re: Braille devices

[Nicolas Pitre]

From: Simon Richter <[EMAIL PROTECTED]>

> [CCed to linux-kernel, as IMO the best idea would be to implement this at
>  kernel level]
> 
> On Wed, 16 Aug 2000, VZW AUDIO/BRAILLE wrote:
> 
> > Hi, I have on one pc the very great chance to use Debian 2.1 with a
> > hardware braille-display. But actually on another pc I'm suffering from
> > the refusal of my old braille display (not brltty supported) to let
> > me work under Deb. So on pc1 I've a great pleasure to work, on another
> > nothing more than frustration!
> 
> [...]
> 
> I've seen the request for braille device support during installation here
> on debian-devel for many times, and IMO the best approach would be to
> support these devices at kernel level. The reason for this is that a
> daemon approach would compromise system security, as some (luckily not too
> many) braille devices have special interface cards which require hardware
> access. Also, a daemon has to be started in order to be useful, so that
> you cannot see anything if the boot fails.
> 
> Comments?

First, let me say that I'm actually the maintainer of BRLTTY
(http://www.cam.org/~nico/brltty) and used it most everyday on Linux for
nearly six years now.  I would like to take this opportunity to answer
some questions and kill some common myths that I keep encountering over
and over.  All this rambling also applies to other packages similar to
BRLTTY...

Braille Display Support
---

BRLTTY is quite modular and actually support over 10 different brands of
braille display families.  Adding another is just a matter of having the
protocol specification from the manufacturer (you know the classic
problem?) and someone to implement it.  So the user space vs kernel space
argument is a non-issue for "my display isn't supported" statements.

The scarce braille displays requireing a special interface card are mostly
using firmware on the card that emulates a VGA text display, or that
retrieve data directly from the video memory of your VGA card, in order to
send it directly to the braille display thus not relying on software
support at all.  In the case where kernel support is absolutely required,
only the raw low-level communication support must be in the kernel,
nothing more.

System Security
---

BRLTTY only requires access to /dev/vcsa0, /dev/tty0 and /dev/ttyS0.  It
is intended to be used by the person at the console only and that person
usually has root access.  If you don't want to run BRLTTY as root, you
just have to adjust permissions on the above devices.

Braille-Enabled Linux Installation
--

The fastest and easiest way to have Linux installed for a blind person
might still consist of a sighted person assisting the instalation up to
the activation of BRLTTY.  Has anyone been able to install NT or W2K with
braille support during the OS installation anyway?

But... since Linux is also about freedom...  Linux installation may even
be done with BRLTTY on bootdisks!  I've installed many version of Red Hat
in the past without any sighted help and also got reports of success
stories for Slackware and Debian as well. The current development version
of BRLTTY contains a mini-howto on installation bootdisks hacking.  I
encourage every interested distributors to have a look at it and maintain
a special bootdisk for braille-enabled Linux installation.  I did it for
me, the recipee is available, but don't ask me to do it for you please.

Here again, the kernel solution isn't much of an advantage because you'll
typically have BRLTTY reside on an initial ramdisk (initrd) which contents
is executed before any kind of installation procedure.  When the loading
of the initrd fails, it'll most probably be the case for the kernel as
well, and the blind person will remain clueless either ways.  The "in the
kernel approach" doesn't bring an advantage worth its cost.

Since BRLTTY uses /dev/vcsa0, all kernel messages are available from the
console's scrollback function.  Even the BIOS boot messages can be
consulted that way!

Conclusion
--

BRLTTY is a daemon simply because its job can be done outside the kernel.
It has been like that since 1995 and you know what? the first old version
from 1995 still can run unmodified on a 2.4.x kernel.  So please always
look at what can be done in user space before advocating kernel solutions.
Putting this into the kernel would simply be a maintenance overhead.

My pay job consists of kernel hacking and I also maintain kernel support
for the StrongARM SA1100 in my free time. Therefore I'm quite familiar
with it and don't think adaptive applications belongs there.  Some will
argue that Speakup is in kernel space but speech is a different matter
than braille, and I'm still not convinced anyway.

As a sidenote, people used to their good old DOS TSR for their
braille/speech hardware could have a look at DOSgate
(http://www.cs.unibo.it/~zinie/dosgate/).  It lets you access the Linux
console transparently

Re: Learning dpkg/apt

[Steve Bowman]

On Sat, Aug 19, 2000 at 02:20:26PM -0600, Dwayne C . Litzenberger wrote:
> I know that, but dpkg/apt is a huge pile of source.  I'd like to know what
> order I should read things in, so not to get too confused with too many
> forward references.

Try cflow.  BTW, avoiding forward refs => bottom-up "parsing".  IMHO,
attacking a new piece of source top-down seems to make comprehension
easier.  I'd start with main().

-- 
Steve Bowman  <[EMAIL PROTECTED]> (preferred)
Buckeye, AZ   <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
  

Powered by Debian GNU/Linux 

Re: Learning dpkg/apt

[Dwayne C . Litzenberger]

> it seems to me that this would make things slower since everything is
> written twice, the text database would still have to be processed in
> order to update it properly, so i don't think installing packages
> would be much faster, if not slower.  
> 
> querying would indeed be fast but as i mentioned that can be better
> achieved by rebuilding a binary database with a cron job as in
> dlocate. 

You underestimate how many times the database is read from.  For example, 
AFAIK, for each file installed, it must be checked against the diversions 
database to see if it has been diverted elsewhere.

Anyway, the actual details have not been worked out.  Another way of doing it
would be as follows:

1. The checksum (md5, sha, etc) is computed for all the txtDB files.  If they
do not match the checksums in the binDB, the binDB files are recomputed.  If
they do, things are left as they are.

2. Packages are manipulated (installed, removed, configured, etc) using the
binDB only.  Changes are also written to a textmode journal, in case the binDB
is corrupted.

3. The txtDB is then recomputed and written.  Or, the changes journal is
optimised, then merged with the txtDB.  This occurs *once* at the end of an
install cycle, rather than for each and every package manipulated.

I think that would speed things up substantially.

Anyway, this is getting a bit offtopic.  The main question was that if someone
who is familiar with dpkg could give me a few pointers as to where to start,
or how I should go about learning the internals of dpkg from scratch.

-- 
Dwayne C. Litzenberger - [EMAIL PROTECTED]

- Please always Cc to me when replying to me on the lists.
- See the mail headers for GPG/advertising/homepage information.


pgpePiaCnzqAq.pgp
Description: PGP signature

ITP: Biomail - automated medical searcher

[Seth Cohn]

Package: wnpp
Version: N/A; reported 2000-08-19
Severity: important

 
Author is excited about getting this packaged for Debian.
Homepage is http://biomail.sourceforge.net
License is GPL
I think this will go into contrib, since it uses PubMed's database,
and it is pretty useless without access to their database.  The code itself
is free, and I think someone could easily modify this into doing many other
similar database searches.  Imagine if someone tweaked this to do searches
on common web sites, so it would email you anytime the topic you desired
was mentioned.

I'm still waiting in the new maintainer queue, but I'm sure I can get this  
uploaded via sponsorship.

   BioMail is a small web-based application for medical researchers,
   biologists, and anyone who wants to know the latest information about
   a disease or a biological phenomenon. It is written to automate
   searching for recent scientific papers in the PubMed Medline database.
   BioMail is free and will stay free.
   
   What does BioMail do?
   Periodically BioMail does a user-customized Medline search and sends
   all matching articles recently added to Medline to the users' e-mail
   address. HTML-formatted e-mails generated by BioMail can be used to
   view selected references in medline format (compatible with most
   reference manager programs).
   
   Why is BioMail helpful?
   If you use Medline, it may be hard to remember when you did your last
   search. Often you must scan titles you have already seen to be certain
   you didn't miss an important reference. BioMail will perform routine
   searches for you. This program alerts users to all new papers in their
   fields automatically. It also helps the user to 'refine' search
   patterns once and for all. There is no need to wonder: 'What was that
   great search pattern I used last Saturday?'. All patterns are safe in
   the database and can be accessed, tuned, or deleted any time.
   
   It is also useful for countries where access to the Internet is not
   yet widely available. If a person has a permanent e-mail address, but
   only sporadic www access, she/he only needs to fill out a BioMail form
   once and then will receive new references from Medline continually.
   License
   
   It is released under GNU GPL license. This means it can be freely
   used, distributed, modified and redistributed as a new application, or
   it can even be sold for money, as long as the original or modified
   source codes remain freely available (and a little respect to the
   author is shown).
 
  Requirements
   
   BioMail was written in Perl for Linux. It was also checked under San
   Solaris7, Irix 6.5 (on SGI), Tru64 Unix 4.OE (on Digital alpha), and
   should be fine for other Unix OSes.
   
   BioMail requires a standard Perl distribution and two additional Perl
   modules from CPAN -- LWP::Simple and Mail::Mailer.
   
   Code by Dmitry Mozzherin ([EMAIL PROTECTED])
   

Re: Potato now stable

[Jason Gunthorpe]

On Fri, 18 Aug 2000, Anthony Towns wrote:

> Presumably sections and tasks will both be subsumed by this. I think
> these should probably be handled differently: saying "I want the games
> task" should probably default to installing all; whereas you'd probably
> not want to say "I want the games section" and have all of them installed.

Well, is this really an issue? If we maintain the taks-* prefix it becomes
clear to the user.. Maybe someone will want to install a full section
- especially if our sections become significantly more useful!

> Changing the meaning of "Section" like this is probably dependent on
> getting dinstall rewritten and the archive restructured first.

Hm, Possibly. I'd have to ask James of course.

> > be installed. The UI tool will track when new packages are added to groups
> > and present that information in conjunction with the traditional new
> > packages display.

> This sort of behaviour probably wouldn't be suitable for sections. Are
> there any other "grouping" style things apart from sections and tasks
> that we can consider?

Why? Right now our sections are pretty useless because they have too wide
a mismatch of things in them. But that doesn't have to remain true.
 
> This makes the "extra" priority not really fit in though: while you can
> (in theory) install all packages of any of the other priorities you
> specifically *can't* do this with packages in extra. This priority is

True - eliminate it would be my answer. 'extra' packages are gouped into a
view by sections or by name - but not by priority.

> I suspect you'd want a different interface to play with priorities than
> with tasks though, too.

Possibly, I don't know..

> (if you *really* group everything into just one way of doing things),
> but I think this would probably require icky handling on behalf of apt
> or dselect. It probably *would* make it much easier to introduce new
> styles of groupings in future though.

If people want to see this then internally I will convert all groupable
things into whatever the internal group representation is - that makes it
much, much, much simpler to deal with. It isn't so important if that is
done in the archive or not.

Do people like this idea? I mean - if nobody cares I'm certianly not going
to spend any time on it.

Jason

Re: Learning dpkg/apt

[Ethan Benson]

On Sat, Aug 19, 2000 at 06:00:54PM -0600, Dwayne C . Litzenberger wrote:
> > no it wouldn't, as soon as that database gets corrupted in whatever
> > way your completly screwed and have to reinstall.
> 
> That's why I suggested a *cacheing* system for the text database.  Every write

sorry i have not followed this thread very close.

> operation happens twice (once in the binDB, once in the txtDB), but every read
> operation can come straight from the binDB.  Hashing could be used to check if
> the text database is still equal to the binary database.

it seems to me that this would make things slower since everything is
written twice, the text database would still have to be processed in
order to update it properly, so i don't think installing packages
would be much faster, if not slower.  

querying would indeed be fast but as i mentioned that can be better
achieved by rebuilding a binary database with a cron job as in
dlocate. 

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpMxwPV4b8ir.pgp
Description: PGP signature

Re: Installed black-box 1.3-1 (source i386)

[Branden Robinson]

On Sat, Aug 19, 2000 at 02:52:16PM -0400, Adrian Bunk wrote:
> Description: 
>  black-box  - Find the crystals
> Changes: 
>  black-box (1.3-1) unstable; urgency=low
>  .
>* Initial Release.
>* Upload sponsored by Tony Mancill <[EMAIL PROTECTED]>.

That sure does come darn close to colliding with the name of a window
manager that's been around for a couple of years.

Do you think it would be possible to rename this package before it gets too
entrenched?  It sure would suck to have to talk about "blackbox" versus
"black dash box".

-- 
G. Branden Robinson |
Debian GNU/Linux|It tastes good.
[EMAIL PROTECTED]  |-- Bill Clinton
http://www.debian.org/~branden/ |


pgpg4EvS5fs2h.pgp
Description: PGP signature

Re: Learning dpkg/apt

[Dwayne C . Litzenberger]

> no it wouldn't, as soon as that database gets corrupted in whatever
> way your completly screwed and have to reinstall.

That's why I suggested a *cacheing* system for the text database.  Every write
operation happens twice (once in the binDB, once in the txtDB), but every read
operation can come straight from the binDB.  Hashing could be used to check if
the text database is still equal to the binary database.

> ill take slow over unrecoverable any day.

Same here, but it is possible to have the best of both worlds.
 
-- 
Dwayne C. Litzenberger - [EMAIL PROTECTED]

- Please always Cc to me when replying to me on the lists.
- See the mail headers for GPG/advertising/homepage information.


pgp4RzulMDyyT.pgp
Description: PGP signature

Re: Learning dpkg/apt

[Ethan Benson]

On Sat, Aug 19, 2000 at 05:07:41PM +0200, Simon Richter wrote:
> On Fri, 18 Aug 2000, Dwayne C . Litzenberger wrote:
> 
> > I want to learn the total innards of dpkg/apt.  I recently filed a bug
> > complaining about the fact that dpkg is too slow, but I want to actually 
> > _do_
> > something about it (other than ordering other developers around).
> 
> Actuallu the slowest thing about dpkg is the database of files. I would be
> cool if dpkg could use some sort of relational database for that.

no it wouldn't, as soon as that database gets corrupted in whatever
way your completly screwed and have to reinstall.

this happened to me once and the only thing that saved me was the fact
that the dpkg databases were in human readable text format.  

ill take slow over unrecoverable any day.

for things like querying (dpkg -s and such) install dlocate it solves
that problem the Right Way.  (unfortunatly it got removed from potato
for less then critical bugs)

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpiQMnRN865i.pgp
Description: PGP signature

Re: WNPP now on the BTS

[Josip Rodin]

On Sat, Aug 19, 2000 at 09:10:50PM +0200, Marcelo E. Magallon wrote:
> Attached is the intended documentation for the WNPP system.

I've formatted this text with html/wml and put it in the web pages. It
should appear shortly as http://www.debian.org/devel/wnpp .

I'll make a few other changes to it, to indicate the status of
[EMAIL PROTECTED] address etc... suggestions welcome.

The FTP copy of the old wnpp page will be removed, and the WWW copy will be
updated to point at the new place.

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: Intent To Split: netbase

[LaMont Jones]

> I'll be happy to do whatever is required for sendmail, but we also need
> the assistance of (at least - any others?):
> LaMont Jones <[EMAIL PROTECTED]>  postfix

If someone wants to tell me exactly what to change and how (I haven't
had to deal with alternatives before...), I'd be happy to make the
change and submit.  Do we need/want to do all of these at once, or
can they happen separately?

lamont

Re: Subpackaging

[Dwayne C . Litzenberger]

> And maybe
> prevent installing any 'non-newbie' packages
>  ("Sorry, your system level is set to 'newbie'.  To install
> 'complex-manually-configured-package', you must turn this off first)
>   [And if you can't figure out how to turn it off, you are too newbie]

Uh... how about we avoid hand-holding.  I think the following would be more
appropriate:

"Your system level is set to 'newbie', but the package you are attempting to
select is rated "complexity-rating", and should not be installed
unless you know what you're doing.  Do you know what you're doing? [y/N]"

That also allows for someone knowledgeable to install something for a newbie,
without requiring one to turn off the newbie feature.

-- 
Dwayne C. Litzenberger - [EMAIL PROTECTED]

- Please always Cc to me when replying to me on the lists.
- See the mail headers for GPG/advertising/homepage information.


pgpVvIpIv3EOM.pgp
Description: PGP signature

Re: Learning dpkg/apt

[Dwayne C . Litzenberger]

> Source is the best documentation for a program...all hail the invention of
> comments :)

I know that, but dpkg/apt is a huge pile of source.  I'd like to know what
order I should read things in, so not to get too confused with too many
forward references.

-- 
Dwayne C. Litzenberger - [EMAIL PROTECTED]

- Please always Cc to me when replying to me on the lists.
- See the mail headers for GPG/advertising/homepage information.


pgp4aZS1RL9FQ.pgp
Description: PGP signature

Braille devices

[Simon Richter]

[CCed to linux-kernel, as IMO the best idea would be to implement this at
 kernel level]

On Wed, 16 Aug 2000, VZW AUDIO/BRAILLE wrote:

> Hi, I have on one pc the very great chance to use Debian 2.1 with a
> hardware braille-display. But actually on another pc I'm suffering from
> the refusal of my old braille display (not brltty supported) to let
> me work under Deb. So on pc1 I've a great pleasure to work, on another
> nothing more than frustration!

[...]

I've seen the request for braille device support during installation here
on debian-devel for many times, and IMO the best approach would be to
support these devices at kernel level. The reason for this is that a
daemon approach would compromise system security, as some (luckily not too
many) braille devices have special interface cards which require hardware
access. Also, a daemon has to be started in order to be useful, so that
you cannot see anything if the boot fails.

Comments?

   Simon

-- 
PGP public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: 10 62 F6 F5 C0 5D 9E D8  47 05 1B 8A 22 E5 4E C1
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: WNPP now on the BTS

[Marcelo E. Magallon]

Hi,

>> Anthony Towns  writes:

 *sip*

 After reading and rereading the Developer's Reference and the QA
 docs, I did away with that oh-not-so-good WTO/ITO classifications and
 added a RFA, as per your suggestion.  Attached is the intended
 documentation for the WNPP system.


Marcelo Work-Needing and Prospective Packages, WNPP for short, is a pseudo
 package on the Debian Bug Tracking System (BTS) and its intention is to
 track closely the real status of such things as prospective packages in
 Debian and packages in need of new maintainers.  Since it uses the BTS,
 every developer is already familiar with the technical details, such as
 submission of new information, modification of information or closing
 of pending requests.  On the other hand, in order to achieve the
 highest level of automatization, some procedures have to be observed.

 In order to submit new information, a bug has to be filed against the
 wnpp pseudo package for each (prospective) package that is affected.
 The format of the submission should be like this:

 To: [EMAIL PROTECTED]
 Subject: {TAG}: {package name} -- {short package description}

 Package: wnpp
 Severity: {see below}

 {Some information about the package.  If this is an ITP or RFP an
 URL where the package can be downloaded from is required, as well
 as information concerning its license.}

 The tags to be used and their corresponding severities are:

 Onormal The package has been Orphaned.  It needs a new
 maintainer as soon as possible.  If the package
 as a Priority of standard, required or essential,
 the severity should be set to important.  If the
 package remains in this orphaned state after one
 month, the severity will be raised to important and
 the ftp maintainers will be asked to move it to
 project/orphaned.

 RFA  normal This is a 'Request for Adoption'.  Due to lack of
 time, resources, interest or something similar, the
 current maintainer is asking for someone else to
 maintain this package.  Meanwhile the package is 
 being maintained, but perhaps not in the best 
 possible way.  In short: the package needs a new
 maintainer.
 
 ITP  wishlist   Someone 'Intents To Package' this.  Please submit
 a package description along with copyright and URL
 in such a report.

 RFP  wishlist   This is a 'Request For Package'.  Someone has found
 an interesting piece of software and would like
 someone else to package it for Debian and upload
 it to the archives.  Please submit a package 
 description along with copyright and URL in such
 a report.
 
 Wwishlist   The package has been withdrawn and can be found
 in project/orphaned.  Such reports should not be
 submited directly, but instead should be a product
 of retitling and downgrading 'O' reports.

 The procedures for closing this bugs are as follow:

 Oadopt the package, upload to the main archive and close this
  bug once the package has been installed.  If you are going
  to do this, retitle the bug with 'ITA:' + the old title.
  This is necessary in order for other people to know the
  package is being adopted and to prevent its automatic removal
  from the archive.

 RFA  adopt the package, upload to the main archive and close this
  bug once the package has been installed.  If you are going
  to do this, retitle the bug with 'ITA:' + the old title.
  This is necessary in order for other people to know the
  package is being adopted.

  If you as the package maintainer decide to Orphan the package,
  please retitle as necessary.  If you withdraw your request,
  please close the bug.

 ITP  package the software, upload to the main archive and close
  this bug once the package has been installed.

  If you change your mind, and no longer want to package this,
  either close the bug or retitle and reclasify it as RFP, as
  you see fit.

 RFP  package the software, upload to the main archive and close
  this bug once the package has been installed.  If you are
  going to do this, retitle the bug as 'ITP:' + the old title.
 
 Wadopt the package, upload to the main archive and close this
  bug once the package has been installed.  If you are going
  to do this, retitle the bug with 'ITA:' + the old title.
  This is necessary in order for other people to know the
  p

SuSE-Blinux: a new Screenreader; Debian? (fwd)

[VZW AUDIO/BRAILLE]

(Forward it to interested deb-devels if necessary or to ther right
Deb person).

Hi, I have on one pc the very great chance to use Debian 2.1 with a
hardware braille-display. But actually on another pc I'm suffering from
the refusal of my old braille display (not brltty supported) to let
me work under Deb. So on pc1 I've a great pleasure to work, on another
nothing more than frustration!

Okay there is now an Ocularis project around Deb. But blind do
prefer braille; SuSE seems to have understood this.
Then, what about braille support and voice while installing for Deb ???
Is Ocularis the one and only idea ? Is there any release date ?

SuSE did it; but I LOVE DEBIAN and want to continue using Deb,
without having to change. DEB is GREAT! I thing deb is a good dist
for blind, because of a much developed console-mode philosiphy/apps.
In general ways I do appreciate much more the Debian philosophy.

Short inst experience journal:
to solve on my 2nd pc this access problem, my friend Frederic Peters
(Deb devel), have tried to install screader + Festival:
impossible to run this combination (75 % of total processor capacity is
used for that)!!! If devs are happend, I recommend the porting of
Euler (tts) + mbrola for Linux; see http://tcts.fpms.ac.be
link to Mbrola.

Now follows the article.

Grtnx, Osvaldo La Rosa - Deb user - BE


   >-- Forwarded message --
   >Date: Sat, 12 Aug 2000 16:02:07 +0200
   >Hi Listers!
   >Maybe the folloing article about the new Sscreen-reader SuSE-Blinux
   >is interesting for some of you...
   >
   > ***
   >SuSE Linux 7.0 suitable for partially sighted and blind people
   >The first Linux-distribution which supports installation and
   >applications
   >in Braille!
   >Since the mid-eighties, more and more partially sighted and blind
   >people have been able to work on computers. This was made possible
   >by the invention of the Braille-device (Braille-Zeile). This is an
   >additional device which is connected to the serial port of the PC.
   >Via the Braille-device, the blind person can read the information
   >displayed on the
   >screen line by line and check his/her own entries.
   >As part of the new version 7.0, SuSE Linux has now developed the
   >screen reader SuSE Blinux - a piece of software which enables
   >partially sighted and blind people to work with Linux comfortably.
   >SuSE Blinux is neither an independent distribution nor a kernel
   >patch but rather a so-called daemon, i.e. a program that runs in
   >the background. One advantage of this
   >is that SuSE Blinux does not compromise system security in any way.
   >Furthermore, blind users have unrestricted use of all applications
   >of the
   >new SuSE Linux version which run on the text console. They can even
   >compile their own kernel.
   >During the boot-process of the installation-CD the system
   >recognises a Braille-device, if connected to the system. If this is
   >the case, the SuSE-specific installation tool Yast2 switches to
   >text-mode. At the same time, even before the LogIn, the screen
   >reader is started. This makes SuSE
   >Linux the only system in the world which offers Braille-support
   >during installation. Blind users can follow the complete
   >LogIn-process and install and configure their own system. They can
   >then work on the text console, using the Braille device and
   >possibly a voice system.
   >Braille writing, as it is taught in schools, is made up of a
   >combination of 6 dots per character. Computer-Braille, however,
   >uses 8-dot combinations. In this way all 256 characters which can
   >be displayed on the
   >screen can also be output in a Braille module.  More options for
   >transferring the information from the screen become available. E.g.
   >lower
   >and upper case letters or various colours can be differentiated. All
   >those
   >who are familiar with 6-dot Braille will not find it difficult to
   >convert
   >to 8-dot Braille. Reading Braille information from a Braille device
   >does,
   >however, require disproportionately more effort from the user:
   >While users without sight-impairments can scan the screen at a
   >glance and pick out the relevant data, blind users have to work
   >their way through the screen contents line by line.
   >This is why SuSE Blinux supports the user during screen navigation
   >by putting the Braille device at the position of the relevant
   >information. To
   >put it more clearly: The Braille device represents exactly that
   >line on the screen on which the cursor is currently positioned.
   >Data which are not
   >relevant at the moment are of course still available on the screen.
   >With every move of the cursor the Braille device jumps to the
   >current line of the cursor.  Therefore, the user can immediately
   >follow any changes on the
   >screen. Cursor routing, e.g. for correction purposes, can be
   >achieved via
 

Re: Nautilus Debian Package

[Christian Marillat]

 "TK" == Takuo KITAME <[EMAIL PROTECTED]> writes:

CD> Hello,
CD> The Nautilus deb depends on "libgtkhtml4 (>= 0.6.1-1)".
CD> ^
CD> I can't find a package that provides that anywhere.  I'm wondering
CD> about that '4' above the caret.  Could you advise?

TK> It's in Incoming, http://incoming.debian.org/

And the latest is 0.6.1-2

Christian

Re: corelinux debian packages

[goswin . brederlow]

"Christophe Prud'homme" <[EMAIL PROTECTED]> writes:

> Hi,
> 
> I am waiting for my debian maintainer application to take place.
> In the mean time, I want to provide my work to the masses
> 
> Here is the apt line to add if you want corelinux (OOA and OOD library for 
> Linux)
> These packages were compiled using WOODY
> 
> deb http://augustine.mit.edu/~prudhomm/debian ./
> 
> more packages (not corelinux related) to follow in the future:

How about source? Does

deb-src http://augustine.mit.edu/~prudhomm/debian ./

work?

May the Source be with you.
Goswin

PS: Get a mentor to upload those. :)

Re: Problem with apt on slink systems

[goswin . brederlow]

> Where the heck the word 'stable' comes from? I removed my hole
> /var/state/apt/ and I do not know where it comes from. Hardcoded anywhere
> perhaps? Or did I miss something grave?
> 
> 
> MfG/Regards, Alexander

What revision of slink do you have? slink 2.1R3 doesn't have that
problem.

Try to update to potato, since thats now stable.

May the Source be with you.
Goswin

Re: build dependencies

[goswin . brederlow]

Peter S Galbraith <[EMAIL PROTECTED]> writes:

> # apt-get source --compile gri
> 
> Or have I missed something?

What is still missing is

apt-get --compile dist-upgrade

That should download all sources (in the correct order) build them,
move the debs to its cache and install.

May the Source be with you.
Goswin

Re: new developper with new packages

[goswin . brederlow]

"Christophe Prud'homme" <[EMAIL PROTECTED]> writes:

> Hi
> 
> I am developper on two projects:
> 1- corelinux (LGPL):   http://corelinux.sourceforge.net OOA and OOD for Linux
> 2- freefem(GPL):   http://kfem.sourceforge.net Finite Element Code and
> 
> 
> I have created rather involved debian packages for them and I would like to 
> submit them to woody ( see on the respective web sites )
> I read some stuff on the developper's corner, but the actions to do to become 
> a debian developper are not clear to me.
> I was one a long time ago but for a short time.
> 
> It seems that I am an applicant and some kind of applicant manager should
> review my application if I am worthy enough .
> so what is the process?
> 
> I have other packages in store:
> 1- vtk Visualisation ToolKit http://www.kitware.com
> 2- vtkqgl a Qt widget for vtk 
> 
> thx for any help,
> Christophe

Please subscribe to debian-mentors. There ask for a mentor for your
Packages. Normaly a few people respond that have similar
interests. You choose one of them to be your mentor and he helps you
with the packages and will upload them for you.

Getting a mentor first is a good thing, because its easy and
fast. You have direct connection to someone experienced if you have
any question and you have someone watching over you a bit, pointing
out little mistakes you might make or improvements.

Becoming a maintainer is a more lengthy process and debian-mentor
and your mentor will help you with any questions about that as well.

May the Source be with you.
Goswin

pcre

[Mark Baker]

I've just uploaded version 3 of libpcre.

I've put it in a new package, libpcre3, and given it a new soname. I'm not
sure if this was strictly necessary or not: the upstream documentation
doesn't mention binary compatibility with the old version, probably because
older versions weren't intended to be built as shared libraries at all.

I intend to stop maintaining libpcre1 (not that I've touched it in the last
year as it is) and think it should be removed from debian; I will continue
to fix any bugs in libpcre2 but would like to see as much as possible
migrating to using libpcre3 instead; this should just be a recompile for
most things.

I'll package a new version of exim tomorrow which will be linked against
libpcre3. Once this is uploaded, I'll request for libpcre3 to be made
standard priority and libpcre2, currently standard, to be made optional.

Please Cc me on any replies as I don't normally read this list.

Re: CD rom image for net install

[goswin . brederlow]

Kenneth Scharf <[EMAIL PROTECTED]> writes:

> Sometime ago someone here mentioned the existance of a bootable cd rom
> image that contained only the contents of the boot floppies to allow
> install over the network on a computer with NO os installed.  Anyone
> know the URL where I can find this image for Potato?

I don't know about a finished iso, but download the disks directory
and burn that with the 2.88Mb rescue disk as boot image.

May the Source be with you.
Goswin

Re: how to setup an apt-getable site

[goswin . brederlow]

"Dr. Guenter Bechly" <[EMAIL PROTECTED]> writes:

> Hi,
> 
> I just have some weird problems to make my uploaded inofficial deb-packages
> apt-getable. The referring site is http://www.bechly.de/debian/. I had all
> five Debian packages in a local directory called 'debian' and correctly run
> dpkg-scanpackages on it. After adjusting my apt sources.list it was no 
> problem 
> at all to access the local directory with the Packages.gz file with apt-get 
> or 
> dselect. I then uploaded the complete directory to my website via ftp (binary 
> mode). Now I can access the site with 'apt-get update' without errors, but as 
> soon as I use 'apt-get install foo' the package foo is downloaded but the 
> installation fails with the error 'Size mismatch'.
> I checked the referring manpages and docs, and several Debian books, and
> did not find the slightest clue (therefore PLEAAASE no RTFMs).
> Any help would be greatly appreciated.

Run dpkg-scanpackages again. You seem to have updated the deb after
building the Packages.gz. Anothe rproblem might be some http/ftp proxy
inbetween.

Compare the size entry in the Packages.gz with the actual size of the
debs.

May the Source be with you.
Goswin

Re: policy changes toward Non-Interactive installation

[goswin . brederlow]

Joey Hess <[EMAIL PROTECTED]> writes:

> Manoj Srivastava wrote:
> > Right. I just do nt see these invariants being very useful. I
> >  would much rather have a mk-realplayer package that helps me create a
> >  realplayer-blah.deb; and the invariants are then natural and not
> >  artificially imposed. When that realplayer.deb is installed,
> >  realplayer is installed (duh), and the version of that package tells
> >  me what version I have installed. 
> > 
> > I can then move the .deb to my local apt-able tree, and all
> >  other machines in my environemnt can just install this.
> >
> > the ml-realplayer does not have to be upgrade every time
> >  realplayer changes. I can install an older verison of real player if
> >  I wish (getting it off a CD, or something).
> 
> Well I for one find being able to make sure I am upgraded to the current
> version is very useful, especially given the historical buginess of
> realplayer.

Why not just ask in the preinst whether to update or not and provide a
script to do so later as well.

Also all information needed for downloading could be asked in the
preinst as well or not? (Never used that package)

> 
> >  Joey> If you don't want to download realplayer right now, why are you
> >  Joey> installing the package?
> > 
> > It is not useful hectoring the user when they report a
> >  percieved problem.  
> 
> I'm not hectoring, I'm asking a question. That is why my sentence ended
> with a question mark.

A good example for this are the xanim modules. The packages asks
whether to downlaod or not and one can start installing the modules at
any time as well.

May the Source be with you.
Goswin

Re: policy changes toward Non-Interactive installation

[goswin . brederlow]

Joey Hess <[EMAIL PROTECTED]> writes:

> Manoj Srivastava wrote:
>... 
> Quite simply: This type of thing can not be handled before unpacking, so
> it isn't. Debconf allows package to ask questions in their postinst,
> this is just *strongly* discouraged. See the realplayer installer for a
> package that (rarely) has to use debconf interactively in its postinst.

My option on this that packages that need to ask questions after
unpacking should not be setup toether with packages that don't need
that.

There should be a preconfigure and postconfigure and the unpacking
inbetween those should be non-interactive. There is no need to stop
all packages from being configured just because the kernel-image
packages needs some input. Downtime of services should be minimal.
 
> > Let me try a concrete example; the kernel image postinst, and
> >  see how far we get. These are the questions the kernel image
> >  postinstall asks, and I have tried to figure out if the question can
> >  be pre asked. 
> > 
> > ==
> >  - Question depends on test on fie system
> > /  Question important (IMHO)
> > |/ --- Depends on previous answer 
> > ||/ -- Needs run time test
> > |||/ __ can be pre asked
> > /
> > |
> > |   
> > X...Y1) Ask to remove /System.map files
> > .X  Y2) ask to prepare a boot floppy
> > XXX.Y3) ask which floppy drive to use
> > .XX.?4) do I need to format the floppy?
> > .XXXN5) Insert floppy, hit return
> > .XXXN6) failure, retry?
> > .XXXN7) failure, you have formatted floppy?
> > .XXXN8) you have floppy, hit return when ready
> > .XXXN9) Failure writing floppy, retry?
> > .XXXN   10) failure, hit return when youhave new floppy
> > XX..Y   11) if conf exists ask if we should run $loader with old 
> > config
> > XXX.Y   12)Or else ask if a new $loader config
> > .XX.Y   13) Or else ask if loader needed at all
> > .XX.N   14) Install boot vlock on partition detected at runtime
> > N   15) Install mbr root disk
> > .XXXN   16) Failure writing mbr, do this manually, hit return 
> > .XX.N   17) make that partition active?
> > ==
> 
> Right. This is obviously a rather important package, which *cannot*
> fail, plus is is very dependant on the actual state of the system. As
> such, the best you'll be able to do is allow a few questions to be
> pre-asked, and defer the remainder to the appropriate maintainer script.

I think that the configuring the package twice is not so good. If you
know that you need to bother the user after unpacking anyway, lets do
it all in one step.
 
> (BTW, I'm ccing this to Wichert and AJ as a sterling example of why
> debconf has to continue to support this type of thing in maintainer
> scripts. I think both of them don't want it to have this capability, but
> it is, as you have noted, essential for some packages.

May the Source be with you.
Goswin

Re: GNOME question

[Anthony Towns]

On Fri, Aug 11, 2000 at 09:18:48AM -0400, Peter Teichman wrote:
> > I would really like to start merging the Helix changes but as Peter Teichman
> > from Helix pointed out there seem to be license issues about the graphics. 
> > And what's nice about Helix if not the graphics? I also can't understand 
> > why Helix does not like advertisement by having their logo in the world's
> > most stable Linux distribution...
> The problem is not whether we would like the advertising. I'm not sure
> whether our graphics are freely redistributable enough for Debian to
> ship. I need to ask the appropriate people here.
>
> Nothing can be done on this end for at least a week or so - most
> people here are heading to Linuxworld Expo. If anyone from Debian is
> there and interested, I'll be glad to try to hash out some of these
> issues.

Hi. This is just a short message to say that Linuxworld's over now.

Heck, there's even a good chance you've recovered from any hangovers by
now. Is that considerate or what??

Anyway, can we please resolve this now?

Another thing, the helixcode website repeatedly and incorrectly refers
to woody as "Debian GNU/Linux 2.3 (Woody)". As woody's not released yet,
it hasn't been assigned a version number. There's at least a 50/50 chance
that when it is eventually assigned a version that it'll be 3.0, too.

In any event, it's really disappointing to have licensing problems
stoping Debian from distributing either of the main desktop environments.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

  ``We reject: kings, presidents, and voting.
 We believe in: rough consensus and working code.''
  -- Dave Clark


pgp56gCmj2xor.pgp
Description: PGP signature

Re: Learning dpkg/apt

[Simon Richter]

On Fri, 18 Aug 2000, Dwayne C . Litzenberger wrote:

> I want to learn the total innards of dpkg/apt.  I recently filed a bug
> complaining about the fact that dpkg is too slow, but I want to actually _do_
> something about it (other than ordering other developers around).

Actuallu the slowest thing about dpkg is the database of files. I would be
cool if dpkg could use some sort of relational database for that.

   Simon

-- 
PGP public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: 10 62 F6 F5 C0 5D 9E D8  47 05 1B 8A 22 E5 4E C1
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

ITP: muh

[Norbert Tretkowski]

muh is a smart irc-bouncing-tool that remains on IRC all the time.
You can take control over your nick by connecting to muh with an
IRC client that is able to supply a password for the server
connection.

http://mind.riot.org/muh


Regards/Gruesse, Norbert

-- 
Norbert Tretkowski


pgpae4xANLLVO.pgp
Description: PGP signature

Re: devfsd: ide cdr with scsi simulator

[Malcolm Parsons]

On Sat, Aug 19, 2000 at 04:16:31PM +0800, [EMAIL PROTECTED] wrote:
> i have to manually
> modprobe ide-scsi and sg
> before i can use
> cdrecord -scanbus
> for creative 4224e ide cdrecorder.
> 
> question is: how can i add them into
> /etc/modutils/devfsd ?

alias   /dev/sg*/dev/sg
probeall/dev/sg ide-scsi sg

-- 
Malcolm Parsons
finger [EMAIL PROTECTED] for info

Re: devfsd: ide cdr with scsi simulator

[Eduard Bloch]

#include 
[EMAIL PROTECTED] wrote on Sat Aug 19, 2000 um 04:16:31PM:

> i have to manually
> modprobe ide-scsi and sg
> before i can use
> cdrecord -scanbus
> for creative 4224e ide cdrecorder.
> 
> question is: how can i add them into
> /etc/modutils/devfsd ?

Learn the syntax of modules.conf (see "man modprobe") and write an
"include" file. Then save it as /etc/modutils/whatever and call
update-modules. Alternatively, use modconf as described in my
mini-Howto for Potato (cdrecord-1.10a02, README.ATAPI, latest section):

/*--*/
From: Eduard Bloch <[EMAIL PROTECTED]>

Situation:
   Linux: Kernel 2.2.15 (Debian package kernel-image-2.2.15)
   Distribution: Debian Potato (deep freeze), i386
   Devices: one CDRW-Writer, one CDROM-drive, both ATAPI

1. Become root, try "grep hd.: /var/log/kern.log" to find out where your
   ATAPI-devices are connected to (hd?-names).
2. Edit your boot configuration file, eg. /etc/lilo.conf if you use
   lilo or the batch-file if you boot via loadlin.
3. Find a line where you can append additional kernel parameters, eg.
   "append=" in lilo.conf or the loadlin-line in the batch file.
4. Append sth. like this: "hdb=ide-scsi hdc=ide-scsi max_scsi_luns=1"
   The hdX-parameters defines devices that should be mapped to SCSI
   latter. You may do it with non-writers too, since the emulation layer
   is almost complete, or let them out so the devices will use their
   native drivers.
5. Save the file, reinstall the bootloader (ie. running "/sbin/lilo")
6. Call "modconf", load "sg" and "ide-scsi" from the SCSI-section
7. Reboot Debian, watch while booting, you should see a line like this
   "Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0".
   Your old ATAPI devices virtually don't exist any longer, use ther
   SCSI equivalents instead.
8. Become root, setup devices:
  cd /dev
  MAKEDEV sg scd
  ln -s scd0 cdrom # NOTE: or cdrw, first check which drive is here
  ln -s scd1 cdrw  # NOTE: see above, maybe cdrom
   Check the new SCSI settings:
  cdrecord -scanbus
   Setup cdrecord's environment - edit /etc/default/cdrecord:
  CDR_DEVICE=cdrw
  cdrw=1,0,04   8m
  cdrom=1,2,0   0   0m
   Input the right values, the fields are described in the manpage
   of cdrecord. Alternatively, you may use this values as
   cdrecord-parameter or take a frontend with an own configuration
   scheme, then you don't need to modify /etc/default/cdrecord.
9. It's done! Insert a CD and try "cdrecord -v -toc"

Gr{us,eeting}s,
Eduard.
-- 
=
Eduard Bloch <[EMAIL PROTECTED]>; HP: http://eduard.bloch.com/edecosi
0xEDF008C5(GnuPG): E6EB 98E2 B885 8FF0 6C04  5C1D E106 481E EDF0 08C5
**
"The three principal virtues of a programmer are Laziness, Impatience,
and Hubris"  (from the man-page for perl).

Re: Essential virtual packages

[Colin Watson]

Glenn McGrath <[EMAIL PROTECTED]> wrote:
>I cant find any details on the virtual package kernel-image except its
>name, do virtual packages have priorities and can they be marked
>essential ?

Virtual packages are called that because they are just names that are
provided by other packages. The packages that provide them have
priorities and can be marked essential, sure. But, since there's no
entry in the Packages file for them, there's nowhere to mark the virtual
package itself essential.

The situation is slightly different with mixed virtual packages, where
you also have a real package by the same name; for instance, trn is a
real package and is also provided by strn. However, the control fields
of trn still don't apply to strn; the virtual package is a different
entity to the real package by the same name.

I'm sure I've explained this badly, because it's complicated. For the
full, accurate details, you should look in section 2.3.5 of the Debian
Policy Manual (package debian-policy) and section 8.4 of the Debian
Packaging Manual (package packaging-manual).

-- 
Colin Watson [EMAIL PROTECTED]

Re: Nautilus Debian Package

[Takuo KITAME]

> On Sat, 19 Aug 2000 05:13:52 -0500
> "CD" == Curt Daugaard <[EMAIL PROTECTED]> wrote...

CD> Hello,
CD> The Nautilus deb depends on "libgtkhtml4 (>= 0.6.1-1)".
CD>^
CD> I can't find a package that provides that anywhere.  I'm wondering
CD> about that '4' above the caret.  Could you advise?

It's in Incoming, http://incoming.debian.org/

Regards.
-- 
Takuo Kitame <[EMAIL PROTECTED]>

Re: Nautilus Debian Package

[Curt Daugaard]

Hello,

The Nautilus deb depends on "libgtkhtml4 (>= 0.6.1-1)".
   ^
I can't find a package that provides that anywhere.  I'm wondering
about that '4' above the caret.  Could you advise?

Thanks for any help you can give, and thanks for packaging this.

Curt Daugaard
[EMAIL PROTECTED]


On Fri, Aug 18, 2000 at 08:35:49AM +0900, Takuo KITAME wrote:
> Hi.
> 
> I've built Nautilus 0.1.0 release package. (for woody)
> Just now, it depends on some Incoming packages such as gtkhtml or gconf.
> So, I put also some needed packages medusa, w3c-libwww, gconf and gnome-vfs.
> 
> I'm intent to upload nautilus, medusa and w3c-libwww to Debian main stream.
> gconf was uploaded already. gnome-vfs will be uploaded by Vincent Renardias.
> 
> You can get it with apt-get.
>   deb http://www.debian.org/~kitame/gnome/release ./
> 
> Thanks.
> -- 
> Takuo KITAME / [EMAIL PROTECTED]
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

devfsd: ide cdr with scsi simulator

[zw]

i have to manually
modprobe ide-scsi and sg
before i can use
cdrecord -scanbus
for creative 4224e ide cdrecorder.

question is: how can i add them into
/etc/modutils/devfsd ?

thanks,

Re: Embedded Debian (was: compaq iPaq)

[Chris Rutter]

On Sat, 19 Aug 2000 09:22:12 Glenn McGrath wrote:

> hmm, im not sure its practical to create extra binary packages, wouldnt
> it be more effective to exclude files from regular packages as its
> installed.

I was suggesting that the script would create them on-the-fly -- they
wouldn't reside anywhere as such.
 
> It could use an external script like you mention in your second point.
> 
> You could have some sort of wrapper around dpkg to do it, would be
> easier than creating new tools, new packages.

That's the sort of thing I meant, yeah.  I suggested the existence of a
tool which would handle all this sort of thing to create a whole
filesystem, or individual small packages which could be transferred onto
an embedded system and `dpkg -i'ed.

c.

Re: Embedded Debian (was: compaq iPaq)

[Glenn McGrath]

Chris Rutter wrote:
> 
> On Wed, 16 Aug 2000 14:14:24 Ben Armstrong wrote:
> 
> > For the most part, I think there is enough flexibility within Debian to
> > pick and choose the smallest tools that will do the job from among the
> > binary packages.  Where Debian currently falls short, we can create -tiny
> > versions of packages as needed.  Most useful optimizations that can be
> > done at compile time can also be used to create binary packages to save
> > people the time and bother of compiling it themselves.
> 
> Yes; I have an idea for a solution to the problem:
> 
>   * For each package, logically create another two packages (although there
> could be many categories): `-small' and `-tiny'.
>
>   * Write a script that will take a binary package and, based on guesses,
> squeeze it down to size; e.g. squeezing binaries, removing documentation,
> removing bash or Perl scripts (depending on whether the target supports
> bash and perl), header files, etc.
> 
>   * Define a mechanism so that a binary package can contain a file in
> `DEBIAN/', called (say) `squeeze-small' and `squeeze-tiny', overriding
> the script's guesses, and specifying more exactly how to squeeze the
> package to its corresponding smaller version.
> 
>   * Define a mechanism so that a source package can contain a file which
> specifies a list of `small' options (e.g. portions of glibc to compile
> in) which can be defined to create a squeezed package in one form.
> (I think few packages would need these.)
> 
>   * Write a tool analagous to the task selector to build these `small'
> packages and create filesystem images out of them.
> 
>   * Package up newlib and friends and make them provide libc6. :-)
> 
> c.
> 

hmm, im not sure its practical to create extra binary packages, wouldnt
it be more effective to exclude files from regular packages as its
installed.

It could use an external script like you mention in your second point.

You could have some sort of wrapper around dpkg to do it, would be
easier than creating new tools, new packages.

Glenn

Re: Intel Assembly error

[Bernhard R. Link]

On Fri, 18 Aug 2000, Joseph Carter wrote:

> I do not know if there is a way to access the rest of EAX when accessing
> AX, AL, etc.  Not sure how endianness applies to EAX offhand (I've been up
> a whole 10 minutes) but given 0x12345678 in EAX, AX may contain 0x5678
> which is where the confusion comes from.  

It is this way. AX ist the low part of EAX (Since eax and ax shall
make the same for values less then 2^16.) And there is no direct way to
address to higher 16 Bits. But as a shr eax,16 need only one cycle it is
not that serious.

Hochachtungsvoll,
  Bernhard R. Link

Re: Subpackaging (Was: Potato now stable)

[Bernhard R. Link]

On Fri, 18 Aug 2000, Edward Betts wrote:

> I agreed with everything else that you said, you give a good example of how
> subpackaging could be implemented using dpkg. However, one of my concerns as a
> low bandwidth user is transferring stuff. Great, I can split my debs up into
> subpackages inside the deb, but what about downloading. If I do not want to
> download man pages, then I do not want to download man pages, if they are all
> together in a deb, then I have to.


What about having just data-packages outside the .deb-archives. (I love
this idea so much, that I start to bore my self by always repeating it).

The .deb could be just advanced by a Data: and suggestedData:, which could
be ignores by old dpkg without very high problems. (There would be no
data). Then one data-package would only be plattform-inependend data,
which has only name,title,classification. One such data-package could 
be stored in a directory with a control file and the packages itself.

There could be a additional program (for example called
debian-data-managment-untily ddmu) which is called by apt with the
packagecontrol file and states which files are needed and not yet
installed. Then dpkg is called and calls ddmu to install the data-pacages.

This way there could be a file describig what to install. (For example,
install PostScript always, Man never, others when viewable, install
english and german, and where no german install dutch)

Then ddmu could install the packages and mention why they are there.
([EMAIL PROTECTED], where packagexyz can also be "manual"). By specifing an
additional name for the system, data-files within /usr/share could be 
managed in an own file in /usr/share/ddmu/installed (while non /share are
in /usr/lib/ddmu/installed or in the home-dirs) and several system could
use the same /usr/share with different rules what to install, so that no
data is doubled but one system can remove a package and exacly that is
removed in /usr/share what was there becaus only this package needed it).

Hochachtungsvoll,
  Bernhard R. Link
 

Re: Essential virtual packages

[Glenn McGrath]

Ben Collins wrote:
> 
> On Sat, Aug 19, 2000 at 04:16:08PM +1000, Glenn McGrath wrote:
> > Im trying to understand a few things relating to packaging... take the
> > kernel for example
> >

> > I cant find any details on the virtual package kernel-image except its
> > name, do virtual packages have priorities and can they be marked
> > essential ?
> 
> Kernel is not and essential package for two very specific reasons.
> Firstly, the user might not wish to use a packaged kernel, and rely on
> manually installed kernels. Secondly, it is very possible to not have a
> kernel installed on the local system at all, like for network based
> clients.
> 
Ahh, ok, didnt think of that..

> As far as your situation, if you installed the same version as the
> original kernel, then it replaced that package.
> 

I was more concerned that if the kernel installed by the kernel should
be listed and its not, then it could be considered a minor bug and
should be fixed.

Im still wondering about properties of virtual packages, another example
comes to mind, bash.

A shell is esential, but does it have to be bash ?
Could there be an esential virtual package called shell or something
that was provided by either bash, zsh, ash or any shell demed to be of
good enough quality, or is bash esential because there a bash specific
shell scripts in other esential packages ?

Glenn

Re: Essential virtual packages

[Ben Collins]

On Sat, Aug 19, 2000 at 04:16:08PM +1000, Glenn McGrath wrote:
> Im trying to understand a few things relating to packaging... take the
> kernel for example
> 
> I just did a fresh install of potato, and then installed my own kernel
> image built by kernel-package, dselect lists my custom kernel as being
> the only kernel-image installed, i cant see any reference to the
> original kernel image.
> Shouldnt both be the original kernel and my custom kernel be listed as
> being installed?
> 
> According to my understanding from the policy manual the functionality
> provided by the virtual package kernel-image, which in my case is
> supplied by both the original and custom kernel should be both required
> and Essential... 
> 
> I cant find any details on the virtual package kernel-image except its
> name, do virtual packages have priorities and can they be marked
> essential ?

Kernel is not and essential package for two very specific reasons.
Firstly, the user might not wish to use a packaged kernel, and rely on
manually installed kernels. Secondly, it is very possible to not have a
kernel installed on the local system at all, like for network based
clients.

As far as your situation, if you installed the same version as the
original kernel, then it replaced that package.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Learning dpkg/apt

[Ben Collins]

On Fri, Aug 18, 2000 at 09:30:18PM -0600, Dwayne C . Litzenberger wrote:
> I want to learn the total innards of dpkg/apt.  I recently filed a bug
> complaining about the fact that dpkg is too slow, but I want to actually _do_
> something about it (other than ordering other developers around).
> 
> So Can someone who knows dpkg give me a good list of the stuff I should
> read, or the order in which I should read the dpkg/apt source code?

Source is the best documentation for a program...all hail the invention of
comments :)

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Essential virtual packages

[Glenn McGrath]

Im trying to understand a few things relating to packaging... take the
kernel for example

I just did a fresh install of potato, and then installed my own kernel
image built by kernel-package, dselect lists my custom kernel as being
the only kernel-image installed, i cant see any reference to the
original kernel image.
Shouldnt both be the original kernel and my custom kernel be listed as
being installed?

According to my understanding from the policy manual the functionality
provided by the virtual package kernel-image, which in my case is
supplied by both the original and custom kernel should be both required
and Essential... 

I cant find any details on the virtual package kernel-image except its
name, do virtual packages have priorities and can they be marked
essential ?



Glenn

Learning dpkg/apt

[Dwayne C . Litzenberger]

I want to learn the total innards of dpkg/apt.  I recently filed a bug
complaining about the fact that dpkg is too slow, but I want to actually _do_
something about it (other than ordering other developers around).

So Can someone who knows dpkg give me a good list of the stuff I should
read, or the order in which I should read the dpkg/apt source code?

-- 
Dwayne C. Litzenberger - [EMAIL PROTECTED]

- Please always Cc to me when replying to me on the lists.
- See the mail headers for GPG/advertising/homepage information.


pgprq6HpVYeNv.pgp
Description: PGP signature