[debian-installer] microdpkg

[Joey Hess]

The debian-installer is an effort to redesign and rewrite debian's
installer for woody. It's just getting started.

We've decided that the new installer will be modular, where modules are
maintained by separate people, and can be installed into the installer
itself while it is running, to give it additional capabilities (like the
ability to partition a disk, or run an interactive shell, and so on).
These modules will themselves be debian packages.

So we need some rudimentary package management tools to be part of the
base of the installer. Dpkg, at around 240k, is much too big. The target
size is more like 24k. I'm calling this stripped down dpkg "microdpkg".
It is not intended to be fully compatable with dpkg, or to be a
full-fledged replacement for it; it will support only those dpkg
features we need to manage packages in the installer.

I think that just like dpkg, it should be split into two programs:
microdpkg-deb to handles the low-level unpacking of packages, and 
microdpkg, to do dependency checking, and so on. Maybe this will turn
out not to make sense; some space might be saved if the two were
combined. On the other hand, Erik Anderson might want to put
microdpkg-deb in busybox -- Erik?

If it is a seperate program, microdpkg-deb should implement the following 
switches, with the same behavior as dpkg-deb:
(More may be added later, as needed.)

--info, -I

--field, -F

--extract, -x

It is expected that it will use busyboxes ar, gzip, and tar implementations
to handle pulling packages apart.

microdpkg will use microdpkg-deb to implement a subset of dpkg's
functionality. It will just implement the following switches:
(More may be added later, as needed.)

   -i, --install
 
   -r, --remove

It will maintain /var/lib/dpkg/status and /var/lib/dpkg/info/* in a
manner compatabile with dpkg. It will not support alternatives, diversions, 
and so forth. It will not support conffiles, nor will it support purging of
packages, nor will it check to see if multiple packages contain the same
file. It will not support preinst and prerm scripts, and will probably
also not support the maintainer script error unwinding done by dpkg.

In package metadata, it will use the following fields: Package, Status,
Depends, Provides -- and will ignore the rest. (Thus, no suggestions, no
reccommendations, no pe-dependencies, no conflicts.) It need not support
OR'd boolean dependencies, or versioned dependencies.

They will be written in C, or perhaps, in POSIX shell script (without
any external commands except ar, tar, gunzip, though..).

I'm looking for a few people who'd like to write this in the next week
or so. I think Randolph Chung may have already done some preliminary work. 
If you'd like to help, make sure you're on the debian-boot mailing list 
and reply to this mail.

-- 
see shy jo

Re: Japanese mailer

[Takao KAWAMURA]

Sorry, wrong ml.

Re: Japanese mailer

[Takao KAWAMURA]

> I want to use Xemacs for Japanese emails (read/send). I'm not sure which
> package to use: vm, gnus, vh, rmail. Suggestions? 

As the maintainer of cmail, I believe it works fine with
XEmacs.  Cmail has the manual in GNU info format written in
English.

-- 
Takao KAWAMURA

Re: Learning dpkg/apt

[Martin Bialasinski]

On 19-Aug-00, 18:56 (CDT), Ethan Benson <[EMAIL PROTECTED]> wrote: 
> 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)

* "Steve" == Steve Greenland <[EMAIL PROTECTED]> wrote:

Steve> man apt-cache. (Assuming you're using apt-get either directly
Steve> or via dselect, and there is no reason not to!)

apt-cache and dlocate cover quite different areas. dlocate is for dpkg
queries like -L and -S (and more). And it is so damn _fast_.

$ time dpkg  -l \*applet\* > /dev/null

real0m2.010s
user0m1.880s
sys 0m0.110s

$ time dlocate -l applet > /dev/null

real0m0.037s
user0m0.030s
sys 0m0.010s

$ time apt-cache --names-only search applet > /dev/null

real0m0.703s
user0m0.350s
sys 0m0.350s

[These are the times of the second invocation, so memory cache/buffers
are used]

IMHO, it is a must have. Cudos to Craig.

Ciao,
Martin

Re: ITP: vlc (VideoLAN Client) & vlms (VideoLAN Mini Server)

[Samuel Hocevar]

On Sun, Aug 20, 2000, Malcolm Parsons wrote:
> On Sun, Aug 20, 2000 at 08:53:48PM +0200, Samuel Hocevar wrote:
> > Description: VideoLAN Client - a free MPEG2 and DVD player
> >  VideoLAN is a free MPEG2 software solution.
> >  .
> >  This is the VideoLAN Client. It plays MPEG2 files, DVDs, or MPEG2
> >  streams from a network source.
> 
> Can you make it clear in this description that it only plays unencrypted 

   Ok, I'll simply change the description to this :

Description: VideoLAN Client - a free MPEG2 and DVD player
 VideoLAN is a free MPEG2 software solution.
 .
 This is the VideoLAN Client. It plays MPEG2 files, unencrypted DVDs,
 or MPEG2 streams from a network source.

> DVDs, perhaps giving a link to upstream's list of them.

   Directly in the package description ? I thought of putting it 
somewhere in the README or HOWTO, as well as documentation on how to
read encrypted ones as well.

Sam.
-- 
Samuel Hocevar - http://www.via.ecp.fr/~sam/

Re: ITP: vlc (VideoLAN Client) & vlms (VideoLAN Mini Server)

[Malcolm Parsons]

On Sun, Aug 20, 2000 at 08:53:48PM +0200, Samuel Hocevar wrote:
> Description: VideoLAN Client - a free MPEG2 and DVD player
>  VideoLAN is a free MPEG2 software solution.
>  .
>  This is the VideoLAN Client. It plays MPEG2 files, DVDs, or MPEG2
>  streams from a network source.

Can you make it clear in this description that it only plays unencrypted 
DVDs, perhaps giving a link to upstream's list of them.

-- 
Malcolm Parsons
finger [EMAIL PROTECTED] for info

CUPS (cupsys) 1.1.2 Available

[Jeff Licquia]

CUPS 1.1.2 packages have been installed into woody.

I know, I know: if you wanted package updates, you'd subscribe to
debian-changes.  But, I've received several requests via private
E-mail as well as in the BTS, so I thought a more general announcement
was warranted, since it seems to be in some demand.

Sorry to take your time; we now return you to your regularly scheduled
flamewar. :-)

Orphaning Tcl/Tk Packages

[David Engel]

In order to allow me to concentrate on other things, I intend to
orphan most of my Tcl/Tk packages.  These include the following:

task-tcltk
tcl8.0, tcl8.0-dev, tcl8.0-doc
tcl8.2, tcl8.2-dev, tcl8.2-doc
tcl8.3, tcl8.3-dev, tcl8.3-doc
tk8.0, tk8.0-dev, tk8.0-doc
tk8.2, tk8.3-dev, tk8.2-doc
tk8.3, tk8.3-dev, tk8.3-doc
expect5.24, expectk5.24, expect5.24-dev
expect5.31, expectk5.31, expect5.31-dev
itcl3.0, itcl3.0-dev, itcl3.0-doc
itcl3.1, itcl3.1-dev, itcl3.1-doc
itk3.0, itk3.0-dev, itk3.0-doc
itk3.1, itk3.1-dev, itk3.1-doc
iwidgets3.1, iwidgets3.1-doc
tcllib
tclreadline

If anyone would like to take these over, please drop me a note in the
next few days.

David
-- 
David Engel
[EMAIL PROTECTED]

ITP: vlc (VideoLAN Client) & vlms (VideoLAN Mini Server)

[Samuel Hocevar]

   I intend to package vlc, a DVD and MPEG2 video player, and vlms, a
broadcasting server application which reads the same files as the vlc
and can send them to it on the network.

   Although they can easily be interfaced with it through a pipe,
neither vlc nor vlms contain DeCSS code. I'm working upstream for the
project as well, so I'll take care not to add suspicious code. Source
can be found on http://www.videolan.org/downloads.html (vlms is to be
released very soon (tm))

   Along with the vlc package are a few other packages: vlc-alsa,
vlc-esd, vlc-fb, vlc-ggi, vlc-glide, vlc-gnome, vlc-sdl, which are
output plugins I put apart because they had their own dependencies.


Package: vlc
Status: install ok installed
Priority: optional
Section: graphics
Installed-Size: 538
Maintainer: Samuel Hocevar <[EMAIL PROTECTED]>
Version: 0.1.99g
Depends: libc6 (>= 2.1.2), xlib6g (>= 3.3.6-4)
Description: VideoLAN Client - a free MPEG2 and DVD player
 VideoLAN is a free MPEG2 software solution.
 .
 This is the VideoLAN Client. It plays MPEG2 files, DVDs, or MPEG2
 streams from a network source.


Package: vlms
Status: install ok installed
Priority: optional
Section: graphics
Installed-Size: 52
Maintainer: Samuel Hocevar <[EMAIL PROTECTED]>
Version: 0.1.99-1
Depends: libc6 (>= 2.1.2)
Description: VideoLAN Client - a free MPEG2 and DVD server
 VideoLAN is a free MPEG2 software solution.
 .
 The VideoLAN Mini Server lets you broadcast or multicast MPEG2 Transport
 Streams which can then be displayed with the VideoLAN Client.

-- 
Sam.

Re: Learning dpkg/apt

[Steve Greenland]

On 19-Aug-00, 18:56 (CDT), Ethan Benson <[EMAIL PROTECTED]> wrote: 
> 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)

man apt-cache. (Assuming you're using apt-get either directly or via
dselect, and there is no reason not to!)

Steve

Re: Braille devices (the problem was DOSemu)

[Nicolas Pitre]

On Sun, 20 Aug 2000, VZW AUDIO/BRAILLE wrote:

> Hi all,
> In my specific case where I wasn't able to run a Alva ABT280, this was the
> hardware problem + this should be the solution:
> - the problem: the DB9 connector on the rear panel didn't have the function
> of serial connection for the device; so the only way for the ABT280 was
> the parallel port. (No spex from factory, as Nicolas Pitre explained).
> But Dosgate, see http://www.cs.unibo.it/~zinie/dosgate uses DOSemu, and
> DOSEMU IS NOT IMPLEMENTED FOR PARALLEL PORT.

Please read carefully the documentation for dosemu!

You can configure it so dosemu (and the Linux kernel) lets DOS
applications access the parallel port hardware directly.  I used an Alva
ABT340 over the parallel port that way in the past.


Nicolas

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

[Adrian Bunk]

On Sat, 19 Aug 2000, Branden Robinson wrote:

> 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".

Upstream already renamed this program from "blackbox" to
"black-box" after I told him that there's a window manager with the same
name. Yes, it's not the best to have two packages with similar names. But
I think it's impossible to avoid similar names in all cases - there are
too many people who write too many programs.


cu,
Adrian

-- 
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi

ITP: Class::MethodMaker

[Peter Palfrader]

Package: wnpp
Severity: normal

Hi, I ITP Class::MethodMaker which is a module for creating generic
methods.

It is needed by GnuPG::Interface.


Upstream source can be found at http://www.cpan.org/modules/by-module/Class/

Author: (Original) Peter Seibel (Organic Online)
Current Maintainer: Martyn J. Pearce [EMAIL PROTECTED]

Copyright: 

# Copyright (c) 2000 Martyn J. Pearce.  This program is free software;
# you can redistribute it and/or modify it under the same terms as Perl
# itself.

# Copyright 1998, 1999, 2000 Evolution Online Systems, Inc.  You may use
# this software for free under the terms of the MIT License.  More info
# posted at http://www.evolution.com, or contact [EMAIL PROTECTED]

# Copyright (c) 1996 Organic Online. All rights reserved. This program is
# free software; you can redistribute it and/or modify it under the same
# terms as Perl itself.

yours,
peter

-- 
PGP encrypted messages preferred.
http://www.cosy.sbg.ac.at/~ppalfrad/
[please CC me on lists]

ITP GnuPG::Interface

[Peter Palfrader]

Package: wnpp
Severity: normal

Hi, I ITP GnuPG::Interface, a Perl interface to GnuPG.

It is distributed under the GPL. Upstream sources are at
http://www.cpan.org/modules/by-module/GnuPG/

Upstream Author is Frank J. Tobin <[EMAIL PROTECTED]>

I'll contact him wheter including GnuPG::Interface is ok with him.

GnuPG::Interface depends on Class::MethodMaker which I also ITP.

yours,
peter

-- 
PGP encrypted messages preferred.
http://www.cosy.sbg.ac.at/~ppalfrad/
[please CC me on lists]

Re: Non-US Incoming

[Michael Sobolev]

On Wed, Aug 16, 2000 at 08:54:53AM -0700, Wichert Akkerman wrote:
> Previously Michael Sobolev wrote:
> > Is it possible to access this for non-developers?
> 
> No.
Hmm..  And what's the reason of that?

--
Misha

incoming is strange! (REQUEST)

[Michael Beattie]

The following was once heard around here...


> > I've uploaded some packages that have been stuck in incoming for 3
> > weeks. The automatic from the installer claims that someone must edit
> > the override file. So who is this person ? Is that normal ?
> 
> One of the FTP admins has to do it.  Three weeks isn't an unheard-of delay.

Anyway, this weekend, james and I cleaned incoming, so, currently, incoming
will be empty after the dinstall run (approx 6 hours away).


What I would like to ask... 

I noticed during this stint that several libraries got upgraded from things
like libfoo0 to libfoo1.

If this is one of your packages, please file a bug on ftp.debian.org to have
the obsolete packages removed. this will not happen for some time, to allow
for packages to be recompiled for the new library.

I'd like to get woody decrufted!

-- 

   Michael Beattie ([EMAIL PROTECTED])

 -
"Bother," said Pooh, as he was assimilated by the Borg.
 -
Debian GNU/Linux  Ooohh You are missing out!



pgp4uEJ3Vjbnc.pgp
Description: PGP signature

Re: xpdf-i obseleted by xpdf

[Josip Rodin]

On Sun, Aug 20, 2000 at 08:59:57AM -0300, Henrique M Holschuh wrote:
> > xpdf already conflicts and replaces xpdf-i. Am I correct in saying that
> > there's no way I can cause an automatic upgrade from xpdf-i to xpdf?
> 
> Hmm... I'll take the oportunity to ask an old doubt of mine: 
> 
> Will it work if xpdf-i is made an empty package which depends on xpdf, and
> its description is changed so as to explain the user that she should purge
> xpdf-i ?  (xpdf still conflicts with xpdf-i).

It will, just make new xpdf conflict with (<< version_before_merge) of
xpdf-i. (But it'll still be ugly)

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: xpdf-i obseleted by xpdf

[Henrique M Holschuh]

On Sun, 20 Aug 2000, Hamish Moffatt wrote:
> xpdf already conflicts and replaces xpdf-i. Am I correct in saying that
> there's no way I can cause an automatic upgrade from xpdf-i to xpdf?

Hmm... I'll take the oportunity to ask an old doubt of mine: 

Will it work if xpdf-i is made an empty package which depends on xpdf, and
its description is changed so as to explain the user that she should purge
xpdf-i ?  (xpdf still conflicts with xpdf-i).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


pgp15ks3douR4.pgp
Description: PGP signature

slink -> archive?

[Josip Rodin]

Hi,

When will slink move to archive.debian.org site?

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: NMU's completely removed from kaffe in woody

[Josip Rodin]

On Fri, Aug 18, 2000 at 03:06:55PM -0500, Ean R . Schuessler wrote:
> The second reason I chose to cut a lot of NMU changelogs was that you
> took it upon yourself to load them with vindictive, personal and
> unprofessional statements.

Editing changelogs is `modifying history' - do not do that.

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: [PROPOSED 2000/08/16] Free pkgs depending on non-US should go into non-US/{main,contrib}

[Josip Rodin]

On Wed, Aug 16, 2000 at 08:04:00PM +1000, Anthony Towns wrote:
> > > A dependency on non-us will also land a package in contrib.
> > I think there was a proposal to change that, so that packages which depend
> > on packages in non-US/main remain in non-US/main.
> 
> Actually, there doesn't seem to be such a proposal; there just seems to
> be your (accepted) proposal to make both main and non-US/main part of
> the Debian distribution.
> 
> So, let's fix that.
> 
> The principle: packages that are DFSG-free, depend on packages in
> non-US/main, but are otherwise candidates for main should go into
> non-US/main also. That way they're still a part of the official
> distribution, but they don't come up as uninstallables for the poor
> deprived US folks.
> 
> Here's a sample wording change.  It incorporates the accepted change
> from #62946. It's not entirely clear where contrib packages that don't
> include crypto, but Depend: on software that does (from non-US/*) would
> go in the following, probably.

Seconded!

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: Braille devices (the problem was DOSemu)

[VZW AUDIO/BRAILLE]

Hi all,
In my specific case where I wasn't able to run a Alva ABT280, this was the
hardware problem + this should be the solution:
- the problem: the DB9 connector on the rear panel didn't have the function
of serial connection for the device; so the only way for the ABT280 was
the parallel port. (No spex from factory, as Nicolas Pitre explained).
But Dosgate, see http://www.cs.unibo.it/~zinie/dosgate uses DOSemu, and
DOSEMU IS NOT IMPLEMENTED FOR PARALLEL PORT.
- The solution was/is: the implementation of DOSemu so that I was able to
run C:\ABT280.EXE 1 (corresponds to lpt1) and that's all,
then returning to Linux.

Project:
it is not promised to me, but I will ask again for confirmation: a student
of the KU-Leuven should start the DOSemu implementation, but not before
November. During this time, I must try a non-braille solution:
Screader + Festival fails.
I do also had contact with the developer of Speakup
(http://www.linux-speakup.org) for developing his screen reader for usage
in combi with software-speech (Mbrola, TuxTalk, not Festival: too
big/slow/75 % of processor usage for him).

--I'm not on this list, for reactions send it in CC to my address:
[EMAIL PROTECTED] or [EMAIL PROTECTED]

Grtnx, Osvaldo La Rosa

---In answer to your session:---
On 2000-08-19 [EMAIL PROTECTED] said:
   >cc: VZW AUDIO/BRAILLE <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
   >org,
   >> [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, 

Re: ITA: netscape4

[Adam Heath]

On Sun, 20 Aug 2000, Ryan Murray wrote:

> On Tue, Aug 01, 2000 at 07:56:04PM -0500, Adam Heath wrote:
> > netscape4.08 (slink) (parts exist in woody, but not in potato)
> > netscape4.72
> > netscape4.73
> > netscape4.base
> 
> I intend to adopt all of the netscape 4 related packages.

May you have a thicker skin, and a larger /dev/null, than I did.


BEGIN GEEK CODE BLOCK
Version: 3.12
GCS d- s: a-- c+++ UL P+ L !E W+ M o+ K- W--- !O M- !V PS--
PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z?
-END GEEK CODE BLOCK-
BEGIN PGP INFO
Adam Heath <[EMAIL PROTECTED]>Finger Print | KeyID
67 01 42 93 CA 37 FB 1E63 C9 80 1D 08 CF 84 0A | DE656B05 PGP
AD46 C888 F587 F8A3 A6DA  3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG
-END PGP INFO-

Re: howto (apt-)get only ./debian dir of a package?

[Colin Watson]

[EMAIL PROTECTED] wrote:
>there is
>$ apt-get source pkg
>but usually i just want to peek at the
>./debian directory to learn from others doing,
>or i want to try the official ./debian stuff on
>a cvs version, ...

It's usually the case that debian/ directories are entirely added by Debian
maintainers rather than being partially maintained upstream; not always,
but usually. In that case you can fetch just package_version.diff.gz
from the source directory of the Debian archive and apply it to an empty
directory, or something similar.

-- 
Colin Watson [EMAIL PROTECTED]

Re: ITA: netscape4

[Ryan Murray]

On Tue, Aug 01, 2000 at 07:56:04PM -0500, Adam Heath wrote:
> netscape4.08 (slink) (parts exist in woody, but not in potato)
> netscape4.72
> netscape4.73
> netscape4.base

I intend to adopt all of the netscape 4 related packages.

-- 
Ryan Murray, ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED])
Programmer, Stormix Technologies Inc., Debian Developer
The opinions expressed here are my own.


pgpedOMEeP4NW.pgp
Description: PGP signature

xpdf-i obseleted by xpdf

[Hamish Moffatt]

Hi debian-develers,

I maintain xpdf and xpdf-i. xpdf-i is xpdf with some non-US-only decryption
patches applied. Given the revised US laws, xpdf now includes those patches
so xpdf-i is obselete.

xpdf already conflicts and replaces xpdf-i. Am I correct in saying that
there's no way I can cause an automatic upgrade from xpdf-i to xpdf?


thanks
Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Bug#69229: [PROPOSED 2000/08/16] Free pkgs depending on non-US should go into non-US/{main,contrib}

[Joseph Carter]

On Wed, Aug 16, 2000 at 08:04:00PM +1000, Anthony Towns wrote:
> The principle: packages that are DFSG-free, depend on packages in
> non-US/main, but are otherwise candidates for main should go into
> non-US/main also. That way they're still a part of the official
> distribution, but they don't come up as uninstallables for the poor
> deprived US folks.
> 
> Here's a sample wording change.  It incorporates the accepted change
> from #62946. It's not entirely clear where contrib packages that don't
> include crypto, but Depend: on software that does (from non-US/*) would
> go in the following, probably.
[..]


Seconded.

-- 
Joseph Carter <[EMAIL PROTECTED]>   GnuPG key 1024D/DCF9DAB3
Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC
The QuakeForge Project (http://quakeforge.net/)   44F9 8FF7 D7A3 DCF9 DAB3

 you know, Linux needs a platform game starring Tux
 kinda Super Marioish, but with Tux and things like little cyber
   bugs and borgs and that sort of thing ...
 And you have to jump past billgatus and hit the key to drop him
   into the lava and then you see some guy that looks like a RMS
   or someone say "Thank you for rescuing me Tux, but Linus
   Torvalds is in another castle!"

howto (apt-)get only ./debian dir of a package?

[zw]

there is
$ apt-get source pkg
but usually i just want to peek at the
./debian directory to learn from others doing,
or i want to try the official ./debian stuff on
a cvs version, ...

the question is can i?
(i know i can check on the packages.debian.org,
but can i get 'em without the need of a browser and
search and clicks, ...)

thanks,

Re: Braille devices

[Joseph Carter]

/* I'm not on l-k at the moment, please Cc replies */

On Sat, Aug 19, 2000 at 09:48:03PM +0200, Simon Richter wrote:
> 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?

Agreed.  I have been pleading with anyone I came across willing to listen
for quite some time now to consider the idea of alternate console device
in the kernel for quite some time.  The same concept that applies to
multihead also applies here except that the alt console would allow for
some secondary I/O device to be used in addition to the primary one.

This would allow for custom alternate output devices such as braile
terminals or possibly speech synthesis drivers to be written as kernel
drivers and essentially always working.  It'd also allow such things as
use of an input device similar to the DARCI hardware (but much less
expensive) right in the kernel and as far as the console driver of the
kernel is concerned, anything sent and processed by the driver came
directly from the local keyboard.  Much more flexible than the serial
console driver is today.

For those who don't know, devices like the DARCI boxes are insanely
expensive - they cost more than twice the average machine of a person
reading this message.  What it does is simulate a keyboard.  It's
extremely flexible in its hardware implementation and extremely complex in
its configuration.  It can use all sorts of inputs from custom matrix
keyboards to a few switches to a surplus morse code key - use your
imagination a bit.  It outputs a standard keyboard signal.  In your choice
of PC, Mac, and I think also Sun formats.  It's purpose is adaptive input
for people who cannot use a traditional keyboard.  They may also have
alternative ways to simulate a mouse in newer models.  Most of these
special purpose devices can be connected to parallel or serial ports with
very little electronics no more complex than wiring up a playstation
controller for your favorite game emulator.

The possibilities for output have I think already begun to register.
Besides the obvious things like braille displays and speech, there are a
million different embedded applications for this.  Wearables anyone?


This is really the kind of thing that would not be very hard to do (I
hope) but it seems like it is also the kind of thing that must be agreed
upon because it will certainly affect a lot of things even if the effect
on them is not major.  Nonetheless, I feel it is something that should be
done because it is important to make Linux as accessable as possible.  It
should also be done because it'd be cool and open the door for a lot of
cool stuff.


(Ye personal-stake-in-this disclaimer: I am myself legally blind, but do
not read Braille or use a speech synthesizer.  I have enough vision that
the fact that my wterm has a font half an inch high on a 21" monitor I'm
less than 10" away from is fairly comfortable reading.  My vision is
20/310 and cannot be reasonably corrected at this time.  So yes I want to
see this done for other people with disabilities - but I'd never use such
a kernel device for that reason.  Not necessary.  I might use such a thing
to write a kernel driver for handling I/O for the wearable I've been
planning to build at some point, however.)

-- 
Joseph Carter <[EMAIL PROTECTED]>   GnuPG key 1024D/DCF9DAB3
Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC
The QuakeForge Project (http://quakeforge.net/)   44F9 8FF7 D7A3 DCF9 DAB3

 Yeah, well that's why it's numbered 2.3.1... it's for those of us
 who miss NT-like uptimes

Re: Implementing "testing" (was: Re: Potato now stable)

[Anthony Towns]

On Thu, Aug 17, 2000 at 10:17:30PM +1000, Anthony Towns wrote:
> Hello world,
> So, on -devel-announce, I mentioned:
> > * New "testing" distribution
> [...]

So some more details.

The way testing is supposed to work is to have three distributions at
any one time: a stable tree, a testing tree, and an unstable tree. As
we make releases and such, this'll look roughly like:

stable  testingunstable
~~  ~~~
potato  woody  sid (when testing's rolled out)
woody   [foo]  sid (when woody's released)
[foo]   [bar]  sid
[bar]   [baz]  sid

So basically we're splitting "the development tree" and "the release
candidate" a little. Not really very *much*, the release candidate's
still heavily based on the development tree, so they're by no means
independent, but hopefully the separation will be useful.

This probably changes the way we deal with unreleased architectures a
bit too. Architectures like sparc64, mips, mipsel, hurd-i386 and the
forthcoming superh are all in development, but aren't release candidates
yet. As such, it will presumably be appropriate to leave them in unstable,
without linking to them from testing, at least until they're ready for
release. This is fairly similar to the current motivation behind sid;
hence the reuse of that existing distribution rather than creating a
completely different one.

As far as maintainers go, they more or less just need to keep uploading
to unstable. They still need to be careful to only upload things that
are more or less ready for release, it's not really reasonable to have
two different forks of a package in the different distributions (as it
is for stable/unstable or even for frozen/unstable). Basically, the
version is testing simply won't get updated until the problems with the
version in unstable are worked out.

If a maintainer wants to be a bit more careful about gettig their software
ready for release, they can look at reports like that at

http://auric.debian.org/~ajt/update_excuses.html

to see if testing's noticed any problems. (At the moment, these
aren't mailed to maintainers or anything? Should they be? They're all
(supposedly) worthy of an RC bug, so in many cases the maintainer will
already have been notified because a bug will have been filed)

If a maintainer specifically *doesn't* think a package should be
considered a release candidate just yet, then all s/he has to do is
file an important bug against the package, and it'll be held in unstable
while that bug's opened.

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


pgp6oGKzOhEV6.pgp
Description: PGP signature