first draft "aptitude howto"

[Bernd Eckenfels]

Hello,

need to spell check it, but i guess it might be helpfull anyway:


aptitude
(c) Copyright 2000, Bernd Eckenfels, Germany

aptitude is a front-end to apt and dpkg, the Debian GNU/Linux Package
Management tools. It tries to provide a nice user interface to every-day
package management on Debian GNU/Linux Systems.

This is a short tutorial to help you with using the default installation of
aptitude. This tutorial is based on the version 0.5.1 of aptitude.

Starting

You can start aptitude as non root (for example if you want to look for a
package or see a list of new packages, but you can only use it as root to
actually change the state of packages on your system.

Aptitude is started from the command line in a console window or xterm with
the command "aptitude".

First Steps

Aptitude uses APT's cache of available packages. This means you have to
configure /etc/apt/source.list like you are used from "apt-get". With the
'u' key you ask aptitude to retransmit the lists of available packages from
different sources.

If there is a new package present, it will be grouped unter "New Packages".
To tell aptitude, that it should remeber all new packages as seen, you tell
it 'f' to forget.

With those two keys you usually will type 'u' and then 'f' in aptitude to
reset it to its default working mode. In that mode you have a list of:

Installed Packages
Not Installed Packages
Upgradeable Packages
Virtual Packages

You can open each of this sections by ,oving the cursor to the line and
pressing enter. Subsections for the different trees in debian package
archives will be visible.

If you have a packe selected, you will get information about it in the
status line. The 'i' key will show the information/description of the
package, the  key a more complete information about the debian
package system values for this package. To leave the information screens,
you can use the 'q' key. Within the main tree, the 'q' key will quit the
program.

In the "Not Installed Packages" or in the "New Packages", or even in the
Dpendencies of installed pacages, you can use the "+" key to mark a package
for installation. You can also use the "-" key on a intalled package to mark
it for removal.

Packages which are upgradeable can be put on hold with the '-' key, so their
desired state is downgraded from "upgrade" to "hold". If you press the '-'
key once more, they are even deleted. To purge a package instead of deleting
it (purging will remove all data, especially the config files, too) you use
the '_' key.

If you made your selections (which action should be taken on which package
with "+", "-", "_") you press the 'g'o key. Another screen will list you all
desred options (which packages will be updated, which installed and which
deleted. You can  make changes there, too. While pressing 'q' will get you
back to the main tree, pressing 'g' a second time will actiate the
installation/download/deleting of packages.

Additional Keys in aptitude include '/' for searching, 'home', 'end' and
'up' 'down' for navigation.

NOTE: with aptitude 0.0.4a (included in potato) you will find it confusing if
you dont have support for colors in your term, since:

(todo: find the right names for those colors :)
white  = normal
red= broken
green  = install
turkis = remove
bl n wh= hold
cyan   = update (same as green but alrady installed).

Also in the 0.0.4a version a split screen view with package details and a
key help menu is missing.

bernd

 

keyring-maint@debian.org

[Mike Mattice]

How long does it take to get your gpg key updated via
this e-mail address?

Re: Bash and Letter E

[Thomas Quinot]

Le 2000-03-26, [EMAIL PROTECTED] écrivait :

> read(0, "g", 1) = 1
> ^^^
> 
> It waits for another key. I typed g here
> 
> write(2, "\7", 1)   = 1
> ^

Hum. It looks like someone here is behaving as though the Control
key was held down.

-- 
[EMAIL PROTECTED]

Re: 100Mb/Full Duplex

[Stephen Zander]

> "Bdale" == Bdale Garbee <[EMAIL PROTECTED]> writes:
Bdale> Some folks at work saw similar weirdness with the
Bdale> negotiation on some HP switch products, their solution was
Bdale> to configure the switch to not do the auto discovery
Bdale> protocol, but instead have each port on the switch hard
Bdale> configured, as 100/full for the machines that could take
Bdale> it, and less for the ones that can't.

What he said.  Cisco products are known not to autonegotiate correctly
with SPARC networks cards too (speaking from direct experience).

The only thing to do is disable protocol negotiation on the switch and
force the NIC to the setting you want.

-- 
Stephen

"Farcical aquatic ceremonies are no basis for a system of government!"

woody mutt users, please read

[Marco d'Itri]

You have to change all "lists" commands in your ~/.muttrc in
"subscribe".

-- 
ciao,
Marco

Re: 0 days till bug horizon

[Craig Brozefsky]

Richard Braakman <[EMAIL PROTECTED]> writes:

> On Mon, Mar 27, 2000 at 11:55:49AM -0600, Manoj Srivastava wrote:
> > This should not be a RC bug: bbdb works just fine for
> >  emacs19/20, and even the basic package continues to work for XEmacs
> >  (for VM users, for example). Only the interface between bbdb and gnus
> >  in _one_ of the flavours of emacs is broken; does it justify yanking
> >  bbdb despite the fact it works for a large number of people? 
> 
> That depends on what happens.  Does the install process fail because
> xemacs20 happens to be installed?

No it does not, the install process does not fail for the whole of the
bbdb package.

What happened is that at installation time the bbdb-gnus target fails
because the xemacs process byte-compiling it cannot load the "gnus"
file.  That means that bbdb-gnus.elc is not built and when bbdb is
loaded into xemacs20, at startup time or later, it bombs because it
tried to load bbdb-gnus.elc which is not there.

I attempted to reproduce this problem but was not able to get the
package installation process to bomb when compiling bbdb-gnus for
xemacs20.  The reason for this is xemacs20-suppport include a gnus
distribution, so as long as xemacs20-support is installed (which
xemacs20 depends on) that file will be found by the byte-compiling
xemacs20 process.  If you install the seperate gnus package it
compiled bbdb-gnus against that.

Being unable to reproduce the bug, and due to the fact that even if it
were to mysteriously manifest it only effected xemacs20 users without
gnus installed, I see no reason for this to be an RC bug.

-- 
Craig Brozefsky  <[EMAIL PROTECTED]>
Free Scheme/Lisp Software  http://www.red-bean.com/~craig
"Hiding like thieves in the night from life, illusions of 
oasis making you look twice.   -- Mos Def and Talib Kweli

WNPP

[Joey Hess]

Someone should package AIDE (http://www.cs.tut.fi/~rammer/aide.html). It's
a free tripwire replacement.

-- 
see shy jo

Re: RBL report..

[Joey Hess]

Nils Jeppe wrote:
> ORBS blocks all open relays. A lot of people have open relays. Since open
> relays still do not have any reason for existence other than admin
> ignorance, the "correct" way here would be to block all open relays and
> then fix the mail servers. ORBS really cuts down on spam, the accounts I
> have protected by ORBS usually only get one type of spam: that is spam
> resent via mailing lists.

Right, and any debian mail server that comes configured as an open relay
should have an important bug filed on it.

So long as we default to closed relays on all mailers in debian, I see little
problem with using ORBS.

-- 
see shy jo

Re: 0 days till bug horizon

[Raphael Hertzog]

Le Mon, Mar 27, 2000 at 07:14:57PM +0200, Christian Hammers écrivait:
> > Package: fetchmailconf (debian/main).
> > Maintainer: Paul Haggart <[EMAIL PROTECTED]>
> >   57287 generates wrong config files
> > [ Removing fetchmailconf means also removing fetchmail, unless someone 
> >   uploads a fetchmail version that does not create a fetchmailconf package ]
> 
> I fixed this one! It was in incoming for weeks. Maybe there was a new
> upstraem fetchmail still containing the old bugs. I do a fixed
> upload of fetchmailconfig immediately!

No ! There's no need for that since my fetchmail NMU was installed.
fetchmail (& fetchmailconfig) 5.3.3 is now in potato.  In the bug report,
someone explained that he can't reproduce it with this version ... i'm
closing the bug report since neither potato nor woody has this bug
anymore.

Cheers,
-- 
Raphaël Hertzog >> 0C4CABF1 >> http://tux.u-strasbg.fr/~raphael/
 CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd
  Formations Linux et logiciels libres : http://www.logidee.com 

Re: 0 days till bug horizon

[Colin Walters]

> Package: bbdb (debian/main).
> Maintainer: Frederic Lepied <[EMAIL PROTECTED]>
>  59177 xemacs20 didn't compile bbdb-gnus on installation

Instead of removing this package, couldn't we just change the Depends:
to emacs20 | xemacs21 ?

-- 
Colin Walters <[EMAIL PROTECTED]>
http://web.verbum.org/levanti
(1024D/C207843A) A580 5AA1 0887 2032 7EFB  19F4 9776 6282 C207 843A

Re: Idea: Debian Developer Information Center

[Jacob Kuntz]

Jordi Mallach ([EMAIL PROTECTED]) wrote:
> Haha! Pleaase let's call it my.debian.org, *grin*.
> Now, something like this would be really useful.

that's exactly the name i was going to suggest. has the author decided on a
language to tame this beast in? if php, i'd love to help.

-- 
(jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL 
PROTECTED]
(megabite systems) "think free speech, not free beer." (gnu foundataion)

Bug 59121 (run-parts) (Was: Re: 0 days till bug horizon)

[Julian Gilbey]

> Package: debianutils (debian/main).
> Maintainer: Guy Maor <[EMAIL PROTECTED]>
>   59121 run-parts hangs during /etc/cron.daily runs

There's a patch in the BTS.  Does someone want to do an NMU or should I?

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

ITP: tinydns and dnscache

[Adam McKenna]

Hello,

I just subscribed, and I'd like to let the list know I'm (hopefully) going to
be working on a couple of new packages, namely tinydns/dnscache by djb, which
is a replacement for BIND, and djb's "daemontools", (which is required for
running tinydns).

If you are interested in reading about dnscache and tinydns, please visit the
website at http://cr.yp.to/dnscache.html .  Version 1.00 was just released.

I am currently running tinydns and dnscache on my own two webservers.  It is
a full replacement for BIND.  Right now, I am using rsync to move zone files
to my secondary server (which I control), as well as allowing several sites
running BIND that slave from me to do secondary (with per-zone configuration 
of slave servers).

It really is a nice package.  I would encourage anyone who doesn't like
running BIND to take a look at this.

--Adam

Re: Potato - update-alternatives (Ian Jackson) and window managers - doubt (and Slink to Potato Success)

[Wichert Akkerman]

Previously Robert Bihlmeyer wrote:
> FWIW, gnome-session is not a window manager.

But it starts one for you, so it would be a good candidate for an
x-window-manager alias imho.

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: 0 days till bug horizon

[Craig Brozefsky]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> >>"Richard" == Richard Braakman <[EMAIL PROTECTED]> writes:
> 
>  Richard> Package: bbdb (debian/main).
>  Richard> Maintainer: Frederic Lepied <[EMAIL PROTECTED]>
>  Richard>   59177 xemacs20 didn't compile bbdb-gnus on installation
> 
> This should not be a RC bug: bbdb works just fine for
>  emacs19/20, and even the basic package continues to work for XEmacs
>  (for VM users, for example). Only the interface between bbdb and gnus
>  in _one_ of the flavours of emacs is broken; does it justify yanking
>  bbdb despite the fact it works for a large number of people? 

And as I pointed out previously, it worked for me using xemacs20, both
with and without the seperate gnus package.

-- 
Craig Brozefsky  <[EMAIL PROTECTED]>
Free Scheme/Lisp Software  http://www.red-bean.com/~craig
"Hiding like thieves in the night from life, illusions of 
oasis making you look twice.   -- Mos Def and Talib Kweli

Missing parse-xf86config "breaks" login.app [was: Re: New version of xserver-svga gives poorer display on laptop]

[Nathan E Norman]

On Sun, Mar 26, 2000 at 02:48:49PM -0500, Branden Robinson wrote:
> On Sun, Mar 26, 2000 at 06:05:43PM +0400, Konstantin Kivi wrote:
> > I also had to add
> >  Set_LCDClk  40
> > to the Device section. Be aware that parse-xf86config
> > used in /etc/init.d/xdm doesn't unserstand it
> 
> Be aware that because of problems like this, parse-xf86config has been
> eliminated from recent XFree86 packages.  Potato will ship without it.

For what it's worth (very little :) this breaks the automatic install
for login.app.  Personally it's no big deal to edit /etc/inittab by
hand, but a newbie might find this troublesome.

Perhaps the lines should be added to /etc/inittab but commented out.
Should I file a wishlist bug?

-- 
Nathan Norman "Eschew Obfuscation"  Network Engineer
GPG Key ID 1024D/51F98BB7http://home.midco.net/~nnorman/
Key fingerprint = C5F4 A147 416C E0BF AB73  8BEF F0C8 255C 51F9 8BB7


pgpvX47ej9JbJ.pgp
Description: PGP signature

Re: 0 days till bug horizon

[Richard Braakman]

On Mon, Mar 27, 2000 at 11:55:49AM -0600, Manoj Srivastava wrote:
> This should not be a RC bug: bbdb works just fine for
>  emacs19/20, and even the basic package continues to work for XEmacs
>  (for VM users, for example). Only the interface between bbdb and gnus
>  in _one_ of the flavours of emacs is broken; does it justify yanking
>  bbdb despite the fact it works for a large number of people? 

That depends on what happens.  Does the install process fail because
xemacs20 happens to be installed?

>  Richard> Package: communicator-smotif-461 (debian/non-free).
>  Richard> Maintainer: Adam Heath <[EMAIL PROTECTED]>
>  Richard>   43849 communicator-smotif: Floating point exception error
>  Richard> [ We have netscape 4.72 to replace it, but not for all 
> architectures. --RB ]
> 
> Technically, this is not a part of Debian, and does not, per
>  se, get released. I don't think that bugs on non-fee packages should
>  be considered RC.

They are release-critical for that package.

In any case, I think we should have at least one working Netscape to go
with a release.  It is a special case.

Richard Braakman

Re: Debconf question

[Joey Hess]

Michael Vogt wrote:
> I am working on debconf support for libnss-ldap and libpam-ldap.
> Since both share some common information (ldap-server and ldap-base-dn)
> I want to have a shared debconf entry (say shared/ldapns/ldap-server,base-dn).
> 
> I tryed adding this to the template and config file of both packages and
> hoped that after installing one lib, "db_get shared/ldapns/ldap-server"
> for the other lib would return the value entered in the first lib.
> But it didn't work. Any help would appreciated :)

Hm. That should work. Any package can access the values of any question in
the debconf database.

-- 
see shy jo

Re: 0 days till bug horizon

[Manoj Srivastava]

>>"Richard" == Richard Braakman <[EMAIL PROTECTED]> writes:

 Richard> Package: bbdb (debian/main).
 Richard> Maintainer: Frederic Lepied <[EMAIL PROTECTED]>
 Richard>   59177 xemacs20 didn't compile bbdb-gnus on installation

This should not be a RC bug: bbdb works just fine for
 emacs19/20, and even the basic package continues to work for XEmacs
 (for VM users, for example). Only the interface between bbdb and gnus
 in _one_ of the flavours of emacs is broken; does it justify yanking
 bbdb despite the fact it works for a large number of people? 

 Richard> Package: communicator-smotif-461 (debian/non-free).
 Richard> Maintainer: Adam Heath <[EMAIL PROTECTED]>
 Richard>   43849 communicator-smotif: Floating point exception error
 Richard> [ We have netscape 4.72 to replace it, but not for all architectures. 
--RB ]

Technically, this is not a part of Debian, and does not, per
 se, get released. I don't think that bugs on non-fee packages should
 be considered RC.

manoj
-- 
 Malpractice makes malperfect.  -- Solomon Short
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: 0 days till bug horizon

[Craig Brozefsky]

Richard Braakman <[EMAIL PROTECTED]> writes:

> Package: bbdb (debian/main).
> Maintainer: Frederic Lepied <[EMAIL PROTECTED]>
>   59177 xemacs20 didn't compile bbdb-gnus on installation

I have spent the last 3 hours attempting to reproduce this with no
success.  I have tried it both with and without seperate gnus
packages, with all of the same package versions as the bug submitter.

In the log output we can see that it fails to build the bbdb-gnus.elc
target because it can't load a needed file.  The file it is attempting
to load, gnus, is in /usr/lib/xemacs-20.4/lisp/gnus which is in the
xemacs20-support package.  Even with -no-site-file xemacs still will
find that directory if it wasn't removed by a user.

Unless someone else can reproduce this bug, I suggest we either close
it, or downgrade it to normal.  I suspect it was an issue with the
users environment.

-- 
Craig Brozefsky  <[EMAIL PROTECTED]>
Free Scheme/Lisp Software  http://www.red-bean.com/~craig
"Hiding like thieves in the night from life, illusions of 
oasis making you look twice.   -- Mos Def and Talib Kweli

fetchmailconf

[Christian Hammers]

Correction to my previous mail:
The bug itself can be closed - fetchmailconfig generates working 
config files now (the ssl options are gone away).

The only problem now (as now is version 5.3.3) is that fetchmailconf
cannot read its own files a second time :-(


I would suggest *not* to remove it as it is at least good enough for its
purposes.

bye,

 -christian-

(As I don't speak Python and the current problem seems to be a bit more 
difficult I cannot do anymore to it)

-- 
Linux - the choice of the GNU generation.  Join the Debian Project 
 http://www.debian.org 
Christian Hammers * Oberer Heidweg 35 * D-52477 Alsdorf * Tel: 02404-25624
50 3C 52 26 3E 52 E7 20  D2 A1 F5 16 C4 C9 D4 D3  1024/925BCB55 1997/11/01

Re: 0 days till bug horizon

[Christian Hammers]

> Package: fetchmailconf (debian/main).
> Maintainer: Paul Haggart <[EMAIL PROTECTED]>
>   57287 generates wrong config files
> [ Removing fetchmailconf means also removing fetchmail, unless someone 
>   uploads a fetchmail version that does not create a fetchmailconf package ]

I fixed this one! It was in incoming for weeks. Maybe there was a new
upstraem fetchmail still containing the old bugs. I do a fixed
upload of fetchmailconfig immediately!

bye,

 -christian-

-- 
Linux - the choice of the GNU generation.  Join the Debian Project 
 http://www.debian.org 
Christian Hammers * Oberer Heidweg 35 * D-52477 Alsdorf * Tel: 02404-25624
50 3C 52 26 3E 52 E7 20  D2 A1 F5 16 C4 C9 D4 D3  1024/925BCB55 1997/11/01

Re: python-wxwin

[Ron]

[cc'd to -devel in case anyone else was wondering :-]

Hi

Yeah, the current packages in the distro are getting rather out of date.
I've totally redone the packaging for them so I can now build packages
easily from the wxWin cvs but probably wont upload them to the archive
until wxWin2.2 is released (real soon now ;-)

2.1.14 has just been released, but is undergoing some fairly heated
bugfixing..  really its just a release candidate for 2.2 which we hope to
release sometime next month.

There will only be a single source package, I've been tweaking the wxWin
makefile system to allow me to build all the packages from a single
source tree.  There will be packages for wxGTK, wxPython (built with gtk)
as well as packages of the manual and the samples etc.  I'm currently
working on packaging for the contrib libs (ogl, mmedia, the new stc lib,
and the GLcanvas lib) and they should be ready in time for the 2.2 release
as well..  Also there will be packages for wxBase (the non-gui parts of
wxWin which can now be used separately).

So yeah, I am actively working on them..  expect to see them hit the
archives shortly after wxPython2.2 is officially released.  (probably
about a week after the main wxWin2.2 release date.)

best,
Ron

On Mon, Mar 27, 2000 at 07:16:34PM +0200, André Dahlqvist wrote:
> 
> Hi
> 
> I heard from Ben, the previous maintainer of the wxwin-relates packages,
> that you have taken over maintainership of these packages. I thought I
> would ask you if you are  working on releasing any new versions of these
> packages soon? There have been a few  upstream releases since 2.1.11, and
> I'm eager to try them out:-)
> 
> Also, will you be packaging python-wxwin and wxgtk2.1 separately, or will
> you continue to build python-wxwin as part of wxgtk2.1? The reason for me
> asking is that Ben mentioned that building them together was done to
> straighten out some knotty build dependencies, but if he would do it again
> he would package them separately.
> 
> Regards
> 
> // André

Re: Release-critical Bugreport for March 24, 2000

[Steve Greenland]

On 24-Mar-00, 03:15 (CST), BugScan reporter <[EMAIL PROTECTED]> wrote: 
> Package: nvi (debian/main)
> Maintainer: Steve Greenland <[EMAIL PROTECTED]>
>   61035  nvi munches database dump

Fixed and in potato.

-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)

Re: 0 days till bug horizon

[Enrique Zanardi]

On Mon, Mar 27, 2000 at 05:35:30PM +0100, Enrique Zanardi wrote:
> On Mon, Mar 27, 2000 at 05:38:54PM +0200, Richard Braakman wrote:
> > This is the current list of bugs that are headed for the horizon.
> > I generated it from the bugscan report of Mar 26 15:08, and subtracted
> > the bugs that were fixed by uploads I installed today.
> > 
> > I will start removing these packages soon (unless they're too important,
> > in which case we have a different problem).  Removal of a package is final.
> [...]
> > Package: whiptail (debian/main).
> > Maintainer: Enrique Zanardi <[EMAIL PROTECTED]>
> >   59150 still missing dependency on libnewt0 for m68k
> > [HELP] Maintainer doesnt know how to fix this bug. someone with m68k?
> 
> whiptail 0.50-6 (current version in potato for i386 and sparc) compiles
> with "-O2" to avoid a gcc bug on m68k. That should be enough to let
> the m68k buildd recompile this package and fix this bug.

I've just checked, and there's a whiptail_0.50-6_m68k.deb in incoming
with the right dependency.

I'm closing this bug.

-- 
Enrique Zanardi [EMAIL PROTECTED]

Re: 0 days till bug horizon

[Enrique Zanardi]

On Mon, Mar 27, 2000 at 05:38:54PM +0200, Richard Braakman wrote:
> This is the current list of bugs that are headed for the horizon.
> I generated it from the bugscan report of Mar 26 15:08, and subtracted
> the bugs that were fixed by uploads I installed today.
> 
> I will start removing these packages soon (unless they're too important,
> in which case we have a different problem).  Removal of a package is final.
[...]
> Package: whiptail (debian/main).
> Maintainer: Enrique Zanardi <[EMAIL PROTECTED]>
>   59150 still missing dependency on libnewt0 for m68k
> [HELP] Maintainer doesnt know how to fix this bug. someone with m68k?

whiptail 0.50-6 (current version in potato for i386 and sparc) compiles
with "-O2" to avoid a gcc bug on m68k. That should be enough to let
the m68k buildd recompile this package and fix this bug.

-- 
Enrique Zanardi [EMAIL PROTECTED]

Debconf question

[Michael Vogt]

Dear Friends

I am working on debconf support for libnss-ldap and libpam-ldap.
Since both share some common information (ldap-server and ldap-base-dn)
I want to have a shared debconf entry (say shared/ldapns/ldap-server,base-dn).

I tryed adding this to the template and config file of both packages and
hoped that after installing one lib, "db_get shared/ldapns/ldap-server"
for the other lib would return the value entered in the first lib.
But it didn't work. Any help would appreciated :)

bye
 Michael

-- 
GPG Fingerprint = EA71 B296 4597 4D8B 343E  821E 9624 83E1 5662 C734
 /"\ o
 \ / ASCII RIBBON CAMPAIGN  /|\
  XAGAINST HTML MAIL >>
 / \ o

Re: Signing Packages.gz

[Anthony Towns]

On Mon, Mar 27, 2000 at 01:42:47AM +0200, Robert Bihlmeyer wrote:
> There is no need to check all of [the packages]

Well, it'd be nice to be able to do so, to verify that a mirror hasn't
been compromised, but no, you're right.

Actually, now I think about it, the Packages file itself is valuable
information. Consider a Packages file that doesn't actually changes the
.deb's, but changes the netbase entry, say to read:

Package: netbase
Depends: vim
Conflicts: nvi, emacsen

and leaves everything else the same. You can only achieve fairly petty
vadalism with this, but it would still be nice to avoid it, IMO.

> One thing to consider is that this would make the Package.gz file
> noticeably bigger.

Per-package signatures would naturally accompany the package, not the
Packages.gz file.

> > Whose key should be used? Probably a special one just for dinstall,
> > that's kept fairly securely by the Novare and -admin folks, and revoked
> > regularly.
> This key's security value would not be much above that of the debian
> machines themselves.

Speaking about `more secure than the debian machines themselves' is
meaningless. If you can compromise the debian machines themselves,
you're home and hosed. You can do anything and everything. And it's a
*major* *major* change to the way we do *everything* to try to change
that, really.

We may *do* everything in a decentralised, distributed manner, but we're
*still* one organisation. If you can take over `Debian', by definition
you've taken over Debian.

> You'd get about the same security by a mirror of
> master, that is administed by the same people (does this mirror
> exist?).

No, it doesn't. And what would such a mirror actually *do*? Just mirror
master as it gets compromised, and end up compromised itself? Or should
there be three masters which talk to each other and vote on any changes?

(And then, somehow, you need to work out how to avoid people compromising
all three machines in just one heck, by, say, breaking into one of the
personal machines of anyone with root access on all three...)

> Whose key should be used by entry-level signing? I assume that .debs
> are created by an automated process with no user intervention.

Huh? .debs are never created and uploaded without any intervention,
as I understand it. Including ports. They're moved from Incoming to
unstable without interaction, but that's about it.

Cheers,
aj

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

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgp244VJQnc89.pgp
Description: PGP signature

Re: Bug#32888: marked as done (base: Removing "Obsolete" package base kills a system)

[Hamish Moffatt]

On Mon, Mar 27, 2000 at 03:25:51PM +0200, Ingo Saitz wrote:
> But this will only work as long as the internal format of dpkg's
> database won't change. But I heard it will definitely be changed
> in the future. So how will you deal with this "change"?

Worry about it when it happens.


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

Re: Signing Packages.gz

[Anthony Towns]

On Mon, Mar 27, 2000 at 12:17:47PM +0200, Robert Bihlmeyer wrote:
> Anthony Towns  writes:
> > The only reason not to trust a key dinstall uses explicitly for signing
> > Packages is if you believe dinstall is compromised. If you believe that,
> > then you shouldn't be downloading .deb's *ever*, because you're immediately
> > running *untrusted* scripts as root on your systems.
> That's just the point: the security of a singly-signed Packages.gz
> would not be much higher than that of the ftp sites themselves.
> Nothing to win, here.

Pay attention.

There is an existing single-point vulnerability in *every*
mirror. Compromise the mirror and you can compromise every single Debian
user who upgrades from that mirror. You don't even have to try touching
anything at *.debian.org.

That is the vulnerability being addressed, not anything else.

And note that the vulnerability you quoted above is decidedly difficult to
avoid. For example, if you compromise master, you can pretend to just be
the new-maintainer team and surreptitiously add yourself as a maintainer.
Or you can pretend to be on the ftp team, and surreptitiously add or
change existing package, and replace someone else's key with your own,
say.

So let's run through that again: having a `dinstall' key used to automatically
sign Packages.gz:

* doesn't solve the insoluble
* plugs the main vulnerability
* is relatively easy to setup and maintain
* is easy to fix, should it be exploited

> > > Packages should come with their *.changes file, and dpkg should have an
> > > option to verify the signature of individual packages.
> > Note that this makes debian-keyring a more or less standard package.
> Either that, or just let dpkg Recommend it. If it is not installed,
> package verification is not available.

Let me rephrase that. This makes debian-keyring a base package, since
if you want to verify the packages you download, you really want to do
it right from the word "go", rather than just some time later.

This isn't necessarily a bad thing, but it's worth noting since it adds
about half a floppy to base.
 
> > Note that it requires you to trust everyone in that keyring with
> > every aspect of your system.
> That's already the case, isn't it? Signed packages give you the
> benefit, that you'll *only* have to trust the maintainers you install
> packages from - not every man-in-the-middle.

It's currently the case, yes, but it *could* be changed. You could,
for example setup dinstall so that it wouldn't accept NMUs of certain
important packages (such as gnupg).

> > Note that this doesn't help with revoking signatures: if some idiot
> > decides that being a Debian maintainer should give him the right to 0wn
> > all the machines that use his package; then gets thrown out; he can still
> > use his key to sign packages that'll be happily installed by anyone with
> > an out of date debian-keyring.
> Indeed. But I am sure that this fact will get big coverage on the
> lists and the websites.

And, equally, a deliberately compromised package would probably get a
fair bit of coverage too. It'd be nice not have to rely on staying up to
date with slashdot and the mailing lists and IRC before doing an apt-get
dist-upgrade though.

> Debian has handled security leaks in other
> packages well - this is just a leak in the package system that
> updating debian-keyring will plug, nothing else.

The *reason* Debian handles security bugs (security leaks?) in packages
well is that we have a mechanism for handling bugs, and we make use of
it. The best way to ensure that we always have mechanisms for fixing
things is to think about it first, not just handwave it away and say
"She'll be right, mate".

> > If he can gain control of an ftp mirror, he can keep updating the
> > debian-keyring.deb to include his key, and keep "maintaining" any
> > packages he likes.
> No, see below.

...where you add extra complexity to the security model. The originally
stated model does have this problem.

> > It also leads to something of a chicken-and-egg situation. It's much
> > easier to verify a *single* key than that every one of five-hundred of
> > the things is uncompromised. (It can be signed by previous versions of
> > itself, it can be widely published in Debian books, it can be signed by
> > the ftp team, etc)

> The solution is to have one master key (in the hands of a highly
> trusted person) 

The phrase is "A solution".

The highly trusted person you're referring to here is eash member of the
new-maintainer team, by the way.

> that is treated like your single key (published
> everywhere). Every developer's key has to be signed by at least by
> this key. 

And if a developer gets kicked out? You can't revoke a signature (PGP
signatures are designed to certify identity, not trustworthyness), so
instead you have to revoke the key, and sign everyone else again. Revoke
n people, and you have n signatures on every key in the keyring. How
elegant. And note

Re: Bug#32888: marked as done (base: Removing "Obsolete" package base kills a system)

[Hamish Moffatt]

On Mon, Mar 27, 2000 at 11:15:50AM +0200, Santiago Vila wrote:
> base-files will truncate base.list if it exists and will tell the user to
> read README.base to remove this package safely (doing it automatically
> would be an ugly hack).

Thanks, that sounds like an excellent solution.


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

Re: Potato - update-alternatives (Ian Jackson) and window managers - doubt (and Slink to Potato Success)

[Colin Watson]

[EMAIL PROTECTED] (Robert Bihlmeyer) wrote:
>Taupter <[EMAIL PROTECTED]> writes:
>> Yes I did read the man 8 update-alternatives, but it was a bit confusing
>> to me (as I think it is a bit confusing to anyone but the man writer aka
>> Ian Jackson), since it was not sufficiently explanatory (at least to me.
>> Shame on me...).
>
>I agree. Trial-and-error helps.

I find 'update-alternatives --help' more useful, myself. It's mainly
intended for developers, though - I only used it when I wanted to fix
broken man page links in various packages.

-- 
Colin Watson   [EMAIL PROTECTED]

Re: UPS setup problems (apcuspd and genpower)

[David Bristel]

This is one of the reasons why I've been happy I bought a Smart-UPS, not only
does it provide more information(ammount of battery power and UPS load as well
as other information), but the apcd package for APC monitoring worked
on it out of the box for slink.

Dave Bristel


On Mon, 27 Mar 2000, Andreas Tille wrote:

> Date: Mon, 27 Mar 2000 08:51:51 +0200 (CEST)
> From: Andreas Tille <[EMAIL PROTECTED]>
> To: "Thomas R. Shemanske" <[EMAIL PROTECTED]>
> Cc: Debian Development liste 
> Subject: Re: UPS setup problems (apcuspd and genpower)
> Resent-Date: 27 Mar 2000 07:01:59 -
> Resent-From: debian-devel@lists.debian.org
> Resent-cc: recipient list not shown: ;
> 
> On Fri, 24 Mar 2000, Thomas R. Shemanske wrote:
> 
> > A few days ago, I posted this to the debian-users list, but got no
> > takers.  
> > Perhaps someone here has some ideas.
> OK, if noone else replied I'll give it a trial.  Consider me as a
> fool with the fortune to get a running UPS daemon and not as an
> expert in this field!!
> 
> Once I tried *every* single UPS daemon package of the Debian system
> without any success.  The reason was (if I remember right) that they
> were talking to the UPS via "SMART" connection (please read more
> in your documentation about that topic).  Unfortunately the cable
> shipped with my UPS didn't support this mode.  It only supportet
> "SIMPLE" connection.  (Note:  Possibly you have to swap the words
> SMART and SIMPLE in the previous text.  They are possibly confused
> by my "unSMART" memory :-). )
> 
> Please read all the documentation (of the daemon and the hardware)
> very carefully, which cables you need or how you can build the
> right cable yourself.
> 
> After failing with all I tried to package ssd from the APC site.
> I was successfull in packaging it but it failed to work because
> of the same reason I stated above.  Because I couldn't test it I
> uploaded it to experimental.  May be you give it a triel.  But don't
> blame me if it don't work!!  Take it or ask me to remove it from
> there.
> 
> Finally I took the smupsd which is shipped with RedHat and happyly
> I was successful.  The package is available in potato.  Please
> check the configuration file very carefully.  It needs investigation
> by hand!  (Any volunteers to add debconf stuff to the package???
> Unfortunately I have no time for this.  May be anyone more experienced
> than me takes over the package.  It is in a "works for me" state.)
> 
> May be you can gain more information in a Hardware related mailinglist
> or newsgroup as I did.
> 
> Kind regards
> 
> Andreas.
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

Re: Bug#32888: marked as done (base: Removing "Obsolete" package base kills a system)

[Ingo Saitz]

MoiN

On Sun, Mar 26, 2000 at 11:14:06PM -0300, Nicolás Lichtmaier wrote:
> > dpkg-divert --package base-files --divert-to /dev.base/hda /dev/hda
> 
>  Ugh.. ugly... 
> 
>  The clean solution is to truncate the file list of base, as proposed. This
> will "release" all the files owned by that package safely, with no danger at
> all.

But this will only work as long as the internal format of dpkg's
database won't change. But I heard it will definitely be changed
in the future. So how will you deal with this "change"?

I just wanted to point out a way _without_ changing any
_internal_ structures. I agree with you that it is ugly. But
please be careful messing around with dpkg's internals!!!

Ingo
--
Windows, me?

Re: Potato - update-alternatives (Ian Jackson) and window managers - doubt (and Slink to Potato Success)

[Josip Rodin]

On Mon, Mar 27, 2000 at 12:33:39PM +0200, Robert Bihlmeyer wrote:
> update-alternatives --install /usr/bin/x-window-manager \
>   x-window-manager /usr/local/bin/gnome-session 90 \
>   --slave /usr/share/man/man1/x-window-manager.1.gz \
>   x-window-manager.1.gz 
> 
> (if there is no manpage, leave out the last two lines)

...and the backslash at the end of the second line, for those uninitiated
ones who might have wondered.

 :)

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: RBL report..

[Anton Ivanov]

-BEGIN PGP SIGNED MESSAGE-


It is rumored that on 26-Mar-2000 Hamish Moffatt wrote:
> On Sun, Mar 26, 2000 at 02:41:09AM -0800, Joseph Carter wrote:
>> The domain's technical contact.
> 
> Ideally, yes. In practice, I'd say that's no more likely to work
> than [EMAIL PROTECTED] I've seen NIC entries with technical contacts
> called "NOC Administrator <[EMAIL PROTECTED]>"; do you think hotmail
> addresses should be acceptable for domain contacts? I don't but apparently

Yes. 

Think of the case when you are out of connectivity and have to change to new
dns servers and your auth scheme happens to be "mail from:". If your email was
from non-neutral ground you would have had to deal with internic personally.

Though after the invention of auth-DES and other more sane auth schemes at the
registries this is no longer the case but quite a lot of people still keep
their info using an off-site address.

;-)

[snip]

- --
Anton R. Ivanov
IP Engineer Level3 Communications
RIPE: ARI2-RIPE  E-Mail: Anton Ivanov <[EMAIL PROTECTED]>
@*** Uhlmann's Razor ***
  When stupidity is a sufficient explanation, there is no need
  to have recourse to any other.
  Corollary: "It seemed like the thing to do at the time."

- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iQEVAwUBON9LailWAw/bM84zAQEjpwf/YuatKapv0VN6mC4xZnO0FJ7JP9BlddDQ
dPhUrN+yffECHptkYYHcuPnVFhhiScZboqEarWnWdUGaswIwpXNO/ROxKJWNlb1h
08z0vIlVRVfw5Vx4eAKpRLRpDlh2vo2qkdmzHLk5dk+KDCv/AEIyyxPqmCyXCUuQ
xnVaDt0blmhxy+wA0LV91WVhh4JjGB4D72wf9RhmHcwGJMuOIhv3UIQM8Dx9nCkf
bD+zT80w95G9LZfsIaoem7EMWl8FnZsOZgtPuL7zf0IbgaeZkfPkrr9Sv9VDDFd1
q89g/4BhDP3XOn4+rSrWYvRm6yjPz5OReVjg8bc9fWFrVT8/uR8+0w==
=yVvu
-END PGP SIGNATURE-

Kernel 2.4, Apache2, X

[Mark Messer]

Surely the solution is simple include deb for (X,Apache,Kernel -
NEWSTUFF) as we currently doing for php4 its not installed by default..
but can easily be selected for people having problem with new stuff

with a potato 2.2rx coming out in month or so after would making it
stabled and included in default installs

As slink running @ r5 still only has Stone aged x 3.3.2.3a when everyone

else has as part of the install 3.3.6 or an upgrade we still have nether

publicly available

All newstuff should be included as suggest in potato

Mark :)
[EMAIL PROTECTED]

Re: RBL report..

[Anton Ivanov]

-BEGIN PGP SIGNED MESSAGE-


It is rumored that on 26-Mar-2000 Nils Jeppe wrote:
> On Sun, 26 Mar 2000, Mark Brown wrote:
> 
>> ORBS also blacklist sites for other reasons, such as if their probes are
>> firewalled out.  This will, for example, catch sites that automatically
>> firewall out sites that attempt to relay through them - the site notices
>> the first check, blocks the rest and gets added to the list.
> 
> Well I didn't know that, however, that's a pretty redundant thing to do -
> afterall, you can just disable relaying alltogether and be done with
> it. ;-)

If you are on a 64K line and get hit by a spam blast from some well known
providers only the rejects fill your line completely. 

Unfortunately I have seen this quite afew times and been hit a few years ago by
it a few times.

So this is actually a good policy. Though if you are smart enough to configure
something like this yous hould be smart enough to make it avoid the orbs wrath
;-)

[snip]

- --
Anton R. Ivanov
IP Engineer Level3 Communications
RIPE: ARI2-RIPE  E-Mail: Anton Ivanov <[EMAIL PROTECTED]>
@*** Sociology's Iron Law of Oligarchy ***
  In every organized activity, no matter the sphere,
  a small number will become the oligarchial leaders
  and the others will follow.

- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iQEVAwUBON9JjilWAw/bM84zAQEk9AgAjvcaQWoFX9GvpwgYlitlrektqR4OuhYR
jgvOWv+hU5IoYpNun9tUeEVbpuhckQqNpLtDoC7OX6lpk7Uim5jKiq3WtTN/LAEg
3u9VJbIydyEI8LUGTruFz5Fl5gaHrF2B1ILPNxcfPK1FVywBXVfM3Rx5CYbH9P8W
tcfnpTfS1lX6hiiA0hwPFfiavDe5cAHELKLQczgur1PVfBZdBuYhobfwuMFIEn1T
U2dQaBrOmaTzAxh7B6XGkOZ6XcasEENBi5VoqLhd/rK0TTsrhx8/VWGktnjT3Mwi
9qRT1pOfn/cZRdt3qu+B6n+7o2jBHXksSoDVBCuDs+Pob1tfT0udzQ==
=531T
-END PGP SIGNATURE-

Re: Idea: Debian Developer Information Center

[Raphael Hertzog]

Le Mon, Mar 27, 2000 at 11:51:19AM +0200, Robert Bihlmeyer écrivait:
> Hmm, /usr/share/keyrings/debian-keyring.gpg lists 278 identities,
> while the Maintainer fields in my available file lists 543 separate
> values.

$ gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.pgp 
--list-key | sort | uniq | wc -l
   1211
$ gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.pgp 
--list-key | grep pub | wc -l   
528

[ I used the pgp keyring ... and thoses number are still not significant
since one may have several keys (PGP and GPG) ]

When I said identities I meant the name + email that can be different for
the same guy... 

Anyway, if the number doesn't match exactly it may be because we have
already several dozen of future Debian developers that are sponsored. 

Cheers,
-- 
Raphaël Hertzog >> 0C4CABF1 >> http://tux.u-strasbg.fr/~raphael/
 CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd
  Formations Linux et logiciels libres : http://www.logidee.com 

Re: Idea: Debian Developer Information Center

[Jordi Mallach]

On Sat, Mar 25, 2000 at 10:40:27PM +0100, Josip Rodin wrote:
> > Hey people ! I posted this mail in order to have some input ... it would
> > be great if some of you gave their opinion about this proposition I posted
> > a while ago :
> 
> I guess the silent majority overwhelmingly agrees to your proposal ;)

Yeah, I agree this is a great idea :) We want this done by the end of the
week :P

> 
> > > With this system, each developer can add his own page on one of his
> > > bookmark and from time to time he can check what he's responsible for and
> > > what he should do in one look.
> 
> It would be my first bookmark... please do it :)

Haha! Pleaase let's call it my.debian.org, *grin*.
Now, something like this would be really useful.

Jordi

-- 
Jordi Mallach Pérez || [EMAIL PROTECTED]   || Rediscovering Freedom,
ka Oskuro in RL-MUD || [EMAIL PROTECTED]|| Using Debian GNU/Linux

http://sindominio.net  GnuPG public information:  pub  1024D/917A225E 
telnet pusa.uv.es 23   73ED 4244 FD43 5886 20AC  2644 2584 94BA 917A 225E


pgpzGvF2JlW7x.pgp
Description: PGP signature

Re: Removing compiled-by-hand packages

[Robert Bihlmeyer]

Taupter <[EMAIL PROTECTED]> writes:

> 1. Does Debian install any stuff inside /usr/local ?

That would be a bug. You can make sure with "dpkg -S /usr/local" (or
"dlocate /usr/local" if you have the dlocate package)

> 2. Is secure to the system integrity to _wipe_ /usr/local (no
> daemons/services stored in /usr/local and such issues)? The sense of
> _wiping_ /usr/local means removing files/symlinks from /usr/local/bin,
> /usr/local/lib and such.

Since /usr/local is not used by the distribution, anything started
from there was started by you.

In the future, you may want to look at "stow".

-- 
Robbe

Re: Potato - update-alternatives (Ian Jackson) and window managers - doubt (and Slink to Potato Success)

[Robert Bihlmeyer]

Taupter <[EMAIL PROTECTED]> writes:

> I was poking update-alternatives, but didn't find a way to point my
> default window manager to /usr/local/bin/gnome-session.

FWIW, gnome-session is not a window manager. If you're sure you want
to do that, you could issue:

update-alternatives --install /usr/bin/x-window-manager \
  x-window-manager /usr/local/bin/gnome-session 90 \
  --slave /usr/share/man/man1/x-window-manager.1.gz \
  x-window-manager.1.gz 

(if there is no manpage, leave out the last two lines)

> Yes I did read the man 8 update-alternatives, but it was a bit confusing
> to me (as I think it is a bit confusing to anyone but the man writer aka
> Ian Jackson), since it was not sufficiently explanatory (at least to me.
> Shame on me...).

I agree. Trial-and-error helps.

But I think the better way to do this is to start gnome-session from
your "~/.xinitrc" This way "x-window-manager" will still start a
window manager, not a session manager or whatever.

-- 
Robbe

Help debugging X program (moonlight)

[Marcelo E. Magallon]

Hi,

 [ please keep me on the Cc:, I'm not on -devel atm ]

 this is driving me nuts.  moonlight segfaults on start up if libGL.so
 is utah-glx's instead of regular mesa's.  I have recompiled the
 bloody thing against utah-glx's libGL.so (it was using some Mesa
 extension that utah-glx doesn't provide) and now I'm dealing with
 what seems to be a documentation problem... compiled in `development
 mode' (that means don't strip the thing a behave a little different),
 I'm getting:

 [604 ysabell:~/devel/debian/moonlight/moonlight-0.5.3/src] gdb 
main/.libs/moonlight-0.5.3 core
 [...]
 (gdb)  bt
 #0  0x401c5627 in ErrorHandler (display=0x804efa8, event=0xb35c)
 at XGraphicsSystem.C:138
 #1  0x4043ba5d in _XError () from /usr/X11R6/lib/libX11.so.6
 #2  0x4043a14b in _XReply () from /usr/X11R6/lib/libX11.so.6
 #3  0x404293c3 in XInternAtom () from /usr/X11R6/lib/libX11.so.6
 #4  0x401cf84e in set_mwm_border (dpy=0x804efa8, w=41943087)
 at set_mwm_border.C:73
 [...]
 (gdb) list
 133 
 134 #ifndef NDEBUG
 135   // crash 'n' burn for debugging purposes
 136   char *str;
 137   str  = NULL;
 138   *str = '0';
 139   exit(-1);
 140 #endif
 141 
 142   return 0;
 (gdb) list set_mwm_border.C:73
 68 /* setup the property */
 69 motif_hints.flags = MWM_HINTS_DECORATIONS;
 70 motif_hints.decorations = flags;
 71  
 72 /* get the atom for the property */
 73 prop = XInternAtom( dpy, "_MOTIF_WM_HINTS", True );
 74 if (!prop) {
 75/* something went wrong! */
 76return;
 77 }
 (gdb) print *event
 $1 = {type = 0, display = 0x804efa8, resourceid = 71, serial = 92, 
   error_code = 8 '\b', request_code = 1 '\001', minor_code = 0
   '\000'}

 Error code 8 is (X11/X.h):

 #define BadMatch   8/* parameter mismatch */

 but XInternAtom(3x) says:

XInternAtom can generate BadAlloc and BadValue errors.

 wtf!

 Even more confusing, XRequest.1 is X_CreateWindow.  X_InternAtom is
 XRequest.16... aggghhh!  There's a XCreateWindow a few lines
 before the call to XInternAtom, but none of the documented reasons
 for a BadMatch generated by XCreateWindow are met.

 Help?  Anyone?

Marcelo

Re: Signing Packages.gz

[Robert Bihlmeyer]

Anthony Towns  writes:

> The only reason not to trust a key dinstall uses explicitly for signing
> Packages is if you believe dinstall is compromised. If you believe that,
> then you shouldn't be downloading .deb's *ever*, because you're immediately
> running *untrusted* scripts as root on your systems.

That's just the point: the security of a singly-signed Packages.gz
would not be much higher than that of the ftp sites themselves.
Nothing to win, here.

> All this FUD about "no, no, we can't do that, it's not
> secure!" is, well, just that. *Nothing* is absolutely `secure', some
> things just have fewer or different exploits than others.

Of course. But implementing a scheme that does give only marginally
more security may not be worth the effort.

> > Packages should come with their *.changes file, and dpkg should have an
> > option to verify the signature of individual packages.
> 
> Note that this makes debian-keyring a more or less standard package.

Either that, or just let dpkg Recommend it. If it is not installed,
package verification is not available.

> Note that it requires you to trust everyone in that keyring with
> every aspect of your system.

That's already the case, isn't it? Signed packages give you the
benefit, that you'll *only* have to trust the maintainers you install
packages from - not every man-in-the-middle.

> Note that this doesn't help with revoking signatures: if some idiot
> decides that being a Debian maintainer should give him the right to 0wn
> all the machines that use his package; then gets thrown out; he can still
> use his key to sign packages that'll be happily installed by anyone with
> an out of date debian-keyring.

Indeed. But I am sure that this fact will get big coverage on the
lists and the websites. Debian has handled security leaks in other
packages well - this is just a leak in the package system that
updating debian-keyring will plug, nothing else.

> If he can gain control of an ftp mirror, he can keep updating the
> debian-keyring.deb to include his key, and keep "maintaining" any
> packages he likes.

No, see below.

> It also leads to something of a chicken-and-egg situation. It's much
> easier to verify a *single* key than that every one of five-hundred of
> the things is uncompromised. (It can be signed by previous versions of
> itself, it can be widely published in Debian books, it can be signed by
> the ftp team, etc)

The solution is to have one master key (in the hands of a highly
trusted person) that is treated like your single key (published
everywhere). Every developer's key has to be signed by at least by
this key. If one trusts this key, the confidence into keys signed by
it is quite high. Additionally, I can verify keys by other means (e.g.
those of developers living in my vicinity).

Corrupting the debian-keyring package is useless, since the attacker
will not be able to put valid (signed by master) keys into it.

-- 
Robbe

Re: Idea: Debian Developer Information Center

[Robert Bihlmeyer]

Raphael Hertzog <[EMAIL PROTECTED]> writes:

> Yes I know, I should probably extract all the "identities" from a single
> PGP/GPG key and look for all those adresses in the Packages file. Or
> something like that.

Hmm, /usr/share/keyrings/debian-keyring.gpg lists 278 identities,
while the Maintainer fields in my available file lists 543 separate
values.

-- 
Robbe

Bug#32888: marked as done (base: Removing "Obsolete" package base kills a system)

[Santiago Vila]

reopen 32888
reassign 32888 base-files

On Sun, 26 Mar 2000, Hamish Moffatt wrote:

> On Sun, Mar 26, 2000 at 11:03:27AM -, Debian Bug Tracking System wrote:
> > The base package doesn't exist any more for quite a long time, those first
> > time Debian user are most of them quite good and knows what to do to
> > correct this problem. Furthermore for those who can't, they simply have
> > to not remove the base package (which is guaranteed by its essential
> > flag)...  this bug deserves no more to be open.
> 
> I think we are closing bugs for the sake of it here. Any reason
> why the suggestion can't be implemented? (ie make base-files.postinst
> truncate base.list). OK it's not a very nice solution but there isn't
> a better one. I personally have nuked the base package and lost all
> my devices this way.

base-files will truncate base.list if it exists and will tell the user to
read README.base to remove this package safely (doing it automatically
would be an ugly hack).

Thanks.

-- 
 "1e14fb9158b36d0960a96eb7a4010223" (a truly random sig)

Re: Potato - update-alternatives (Ian Jackson) and window managers - doubt (and Slink to Potato Success)

[Agustín Martín Domingo]

Taupter wrote:
> 
> I was poking update-alternatives, but didn't find a way to point my
> default window manager to /usr/local/bin/gnome-session.
> Yes I did read the man 8 update-alternatives, but it was a bit confusing
> to me (as I think it is a bit confusing to anyone but the man writer aka
> Ian Jackson), since it was not sufficiently explanatory (at least to me.
> Shame on me...).
> 
> Could anyone explain to me the right way to make it work like I want, in
> the update-alternatives way?

update-alternatives --config x-window-manager

This will put the alternative in manual mode and pointing to the window
manager you have chosen when replying questions prompted by the script.

Cheers,

-- 
=
Agustín Martín Domingo, Dpto. de Física, ETS Arquitectura Madrid, 
(U. Politécnica de Madrid)  tel: +34 91-336-6536, Fax: +34 91-336-6554, 
email:[EMAIL PROTECTED], http://corbu.aq.upm.es/~agmartin/welcome.html

gpm in vim

[Edward Betts]

Craig Sanders <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 26, 2000 at 05:57:38PM +0200, [EMAIL PROTECTED] wrote:
> >* Enable gpm support (except in vim-tiny of course) on popular request.
> 
> can this be disabled in ~/.vimrc?

The opposite is infact true, console mouse support has to be enabled in the
~/.vimrc to be used.

> text-mode programs which use the mouse make it difficult to use the
> mouse for the purpose that the gods intended (cut & paste with left,
> right, and middle buttons). having to remember to press shift every time
> you want to cut and paste sucks...it upsets the natural order of things
> and is a blasphemy against all that is good and right in the world. :)
> 
> if it cant be disabled, then please consider this a wishlist bug report
> to make it do so.

-- 
while :;do read x;echo \?;done

Re: UPS setup problems (apcuspd and genpower)

[Andreas Tille]

On Fri, 24 Mar 2000, Thomas R. Shemanske wrote:

> A few days ago, I posted this to the debian-users list, but got no
> takers.  
> Perhaps someone here has some ideas.
OK, if noone else replied I'll give it a trial.  Consider me as a
fool with the fortune to get a running UPS daemon and not as an
expert in this field!!

Once I tried *every* single UPS daemon package of the Debian system
without any success.  The reason was (if I remember right) that they
were talking to the UPS via "SMART" connection (please read more
in your documentation about that topic).  Unfortunately the cable
shipped with my UPS didn't support this mode.  It only supportet
"SIMPLE" connection.  (Note:  Possibly you have to swap the words
SMART and SIMPLE in the previous text.  They are possibly confused
by my "unSMART" memory :-). )

Please read all the documentation (of the daemon and the hardware)
very carefully, which cables you need or how you can build the
right cable yourself.

After failing with all I tried to package ssd from the APC site.
I was successfull in packaging it but it failed to work because
of the same reason I stated above.  Because I couldn't test it I
uploaded it to experimental.  May be you give it a triel.  But don't
blame me if it don't work!!  Take it or ask me to remove it from
there.

Finally I took the smupsd which is shipped with RedHat and happyly
I was successful.  The package is available in potato.  Please
check the configuration file very carefully.  It needs investigation
by hand!  (Any volunteers to add debconf stuff to the package???
Unfortunately I have no time for this.  May be anyone more experienced
than me takes over the package.  It is in a "works for me" state.)

May be you can gain more information in a Hardware related mailinglist
or newsgroup as I did.

Kind regards

Andreas.

Re: RBL report..

[Scott Jennings]

On Sun, Mar 26, 2000 at 11:05:40AM +0200, Nils Jeppe wrote:
> On Sat, 25 Mar 2000, Jason Gunthorpe wrote:
> > * Note, once a site is listed in one of these RBLs it becomes impossible
> > for a user to unsubscribe from our lists - no matter what they do they
> > will never be able to communicate a bounce or a unsubscribe request - this
> > is pretty bad.
> 
> Hmmm actually, I use Exim, and Exim has a way to configure
> "exceptions" from RBL blocks. So you could enter an
> unsubscribe-alias-email-address into these exceptions.

I have M4's for sendmail that address this problem as well, and
have packaged them...  One M4 allows you to select (based on the
recipient address) which of the four tests to run for
blockage. Another M4, allows you to select (based on the
recipient address) which of the four tests to run for inserting
X-Spam-* headers.

  -smj

Re: Anyone's able to run 2.3.99-pre*?

[Scott Jennings]

On Sun, Mar 26, 2000 at 10:35:02AM +0200, Michael Meskes wrote:
> e2fscheck always tells me it cannot read the superblock. Up to 2.3.4? it
> worked well. And of course 2.2.14 runs without a problem.

Sounds like you may have turned on support for "devfs".

You might want to turn that off until debian has a package for "devfsd".

Alternatively, if you have "SCO login" enabled, you can go into /dev
and create symlinks from /dev/ide/bus0/unit0/part1 to /dev/hda1 etc...
then exit and continue rebooting.

I can't use it because the PCnet32 driver is completely broken.
(though I have tested it using a pcmcia ethernet)

  -smj

Re: Anyone's able to run 2.3.99-pre*?

[Petr Cech]

On Mon, Mar 27, 2000 at 08:58:11AM +0200 , Michael Meskes wrote:
> On Sun, Mar 26, 2000 at 11:52:40AM +0200, Petr Cech wrote:
> > check that you don't mount devfs, and have IDE subsystem compiled in (it
> > changed location). 
> 
> DEVFS is enabled but not mounted. After all the problem occurs way to early

if you don't say otherwise, devfs is _automagicaly_ mounted on /dev, and it
that you have some devices missing. Try running with 
append="devfs=nomount"

Petr Cech
--
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

Re: Anyone's able to run 2.3.99-pre*?

[Michael Meskes]

On Sun, Mar 26, 2000 at 11:52:40AM +0200, Petr Cech wrote:
> check that you don't mount devfs, and have IDE subsystem compiled in (it
> changed location). 

DEVFS is enabled but not mounted. After all the problem occurs way to early
for a mount call. And yes, IDE is compiled in. The system can read from the
disk. For instance init or e2fsck sre started. But it does not seem to find
the superblock.

Michael
-- 
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De   | Use PostgreSQL!

Re: Anyone's able to run 2.3.99-pre*?

[Michael Meskes]

On Sun, Mar 26, 2000 at 02:50:43AM -0700, [EMAIL PROTECTED] wrote:
>   Do you have an IDE ZIP drive?  I believe I had the same problem starting

No.

> around 2.3.43.  The problem is related to having an uninitialized ATA ZIP

Yes, that's when it started.

> drive around(on the same chain, maybe) as your harddrive.  modprobing
> ide-floppy was enough to work around the problem.  I added ide-floppy to my
> /etc/modules and it hasn't bothered me since.  I don't know if this was ever
> fixed.

I only have two disks running on one port and two CDs on the other. Since
one of these is a burner I use scsi emulation for CD but not for the disks.

Michael
-- 
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De   | Use PostgreSQL!

Re: RBL report..

[Michael Neuffer]

* Joseph Carter ([EMAIL PROTECTED]) [000326 16:45]:
> On Sun, Mar 26, 2000 at 04:00:54PM +0200, Nils Jeppe wrote:
> > > Given every report I've heard to the contrary, I'm not sure I believe
> > > that.  I've also been told that there are cases where their tests produce
> > > false positives.
> > 
> > I don't see how you can create a false positive on a relay test. Either
> > the message gets through, and you're an open relay, or it doesn't, and
> > you're fine. It's quite simple, really.
> 
> Or it appears to have been accepted and goes nowhere.  I've seen a setup
> or two like this specifically for the purposes of tracking who was trying
> to use the relay...

Nope, this can't happen with ORBS. They definitely check that. They figure
out wether you are dropping their testmails or relay them.



Mike

Re: Removing compiled-by-hand packages [WAS:] Potato - update-alternatives and window managers

[Taupter]

> ... But, since there are pretty current versions of
> gnome in potato you might use those...

Surely it woulb be _very_good_ idea, along with communicator and a
really _huge_ stuff I have in, but I really afraid about messing my
system with broken dependencies and so... Ok, removing almos all the
bunch I have would be a great idea too... but I have some questions to
ask:

1. Does Debian install any stuff inside /usr/local ?
2. Is secure to the system integrity to _wipe_ /usr/local (no
daemons/services stored in /usr/local and such issues)? The sense of
_wiping_ /usr/local means removing files/symlinks from /usr/local/bin,
/usr/local/lib and such.

I'm a bit short of space in my /usr partition, and it would be
"useful"... :)


Claudio

Re: Idea: Debian Developer Information Center

[Raphael Hertzog]

Le Sun, Mar 26, 2000 at 06:02:43PM -0700, Randolph Chung écrivait:
> Hi Raphael,

Hi,

> easy to add. Jason would be the person to do this (add a field to the db).
> The web interface can easily be changed to update/view this info.

That's what I thought. :)

> the problem with this is that many maintainers have packages registered
> under different forms of their email address, so this is actually more
> difficult to do. You will probably need to do something with the pgp/gpg sig
> on the .dsc files. again, this is something i've looked at in the past, but
> at that time i was asked to hold off until the bug system has been overhauled.

Yes I know, I should probably extract all the "identities" from a single
PGP/GPG key and look for all those adresses in the Packages file. Or
something like that.

> Wouldn't this just be a link to the mail archive for that mailing list?

yes, probably.

Cheers,
-- 
Raphaël Hertzog >> 0C4CABF1 >> http://tux.u-strasbg.fr/~raphael/
 CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd
  Formations Linux et logiciels libres : http://www.logidee.com 

apache-1.3.9-12

[Ben O'Shea]

Anyone using mod_rewrite w/ a dbm map type with this package in potato?

basically whevener i use a map type of dbm rweriting fails to look up the
key value pairs, works ok with text and regexp based rulesets but not dbm.
If anyone else is experiencing this same sort of difficulty then perhaps a
bug should be filed against thuis package???

Potato - update-alternatives (Ian Jackson) and window managers - doubt (and Slink to Potato Success)

[Taupter]

Hello!


First, I'm proud of Debian!

I upgraded my Debian system to Potato this weekend, and everything went
really fine! Enven my glibc 2.0.7 programs ran (almost all)!

Thank you all developers! Go ahead! Make the world better!

Second, I'm a bit confused about one point:

I compiled gnome, wmaker and a large bunch of X-related software, and I
was using a file in the /etc/X11/ (I can't remember its name, since it
was deleted during the upgrade) to set my default window manager to
/usr/local/bin/gnome-session.

When I restarted my computer and ran X (startx), I was in front of a
tiny almost-unuseable window manager. Digging the scripts I found one
symlink (/etc/alternatives/x-window-manager) pointing to that ugly wm. I
removed that symlink, created a new one pointing to
/usr/local/bin/gnome-session. startx went fine.
Till I restarted the computer.
Then, once again, that link was set to /usr/bin/X11/vtwm . What a mess.

I was poking update-alternatives, but didn't find a way to point my
default window manager to /usr/local/bin/gnome-session.
Yes I did read the man 8 update-alternatives, but it was a bit confusing
to me (as I think it is a bit confusing to anyone but the man writer aka
Ian Jackson), since it was not sufficiently explanatory (at least to me.
Shame on me...).

Could anyone explain to me the right way to make it work like I want, in
the update-alternatives way?

Thank you all!

P.S.: Is Ian the Deborah's husband? :) Just to know... :)


Thanks twice,


Claudio

iptables deb for 2.4.X kernels in incoming

[Christoph Lameter]

Just found iptables for 2.4.X kernels (for packet filtering, NAT etc) and
packaged it up. Its in incoming.

Sorry for the missing ITP. Will remove it if someone has somethin better.

Re: stuffit expander?

[Ethan Benson]

On Sun, Mar 26, 2000 at 09:54:50PM -0400, Peter Cordes wrote:
> > Date: Sun, 26 Mar 2000 21:50:54 +0200 (CEST)
> > From: Nils Jeppe <[EMAIL PROTECTED]>
> > To: debian-devel@lists.debian.org
> > Subject: stuffit expander?
> > 
> > Hello,
> > 
> > Is there any debian package (or in fact Unix tool at all) that allows
> > uncompression of Mac .sit (stuffit) archives?
> 
>  I think you want the macutils package.

nope, that package does not include the stuffit 1.5 utilities, because
they are quite old and broken.

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

Re: stuffit expander?

[Ethan Benson]

On Sun, Mar 26, 2000 at 09:50:54PM +0200, Nils Jeppe wrote:
> 
> Hello,
> 
> Is there any debian package (or in fact Unix tool at all) that allows
> uncompression of Mac .sit (stuffit) archives?

there is no debian package, and more to the point there is no *nix
utility period that will extract stuffit version 4 and version 5
files.  this format is highly proprietary and only one compnay i am
aware of has reverse engineered it, Mindvision (with there macos
Mindexpander utility) they have however chosen not to share their
knowledge with anyone (or their source).  the version 5 file format no
one has yet reverse engineered AFAIK. (look for Aladdin systems to be
moving to Virginia soon)...

there is however some OLD (have not been touched since '88) utilities
that used to extract version 1.5 stuffit files, but they don't really
work anymore, and are not included in any debian package i have seen.
its just as well, they tend to do a better job creating corrupt
files/archives then unpacking a .sit file.

my suggestion is to deal with users using this blatently proprietary
format to use something standard and open, such as a combination of
macbinary and gzip.  which unix utilities should not have any problem
with. 

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

Re: Bash and Letter E

[Rodrigo Castro]

On Sun, Mar 26, 2000 at 09:37:27PM -0400, Peter Cordes wrote:
>  Is it really just bash that has this problem?  You tested other shells, but
> I don't think they use GNU readline.  What about other things that
> use readline, like octave (find something smaller if you don't have it
> installed already!  Use the package dependencies to see what depends on
> libreadline4.)

The problem occurs also with gdb or ftp, for example. I think
the problem is in readline library. I copied my INPUTRC file in a
previous message, but I dont think the problem comes from this file or
something related to bash, once gdb and ftp dont work either.

>  Try using showkey(1) to see what pressing 'E' does on your hardware.  Also
> try dumpkeys and loadkeys, to see if the keymaps are ok.

Showkey shows a normal behaviour for my 'E' key. I tested
other keymaps, that's not where the problem is.

>  Maybe you have a weird setting in /etc/inputrc?  Is there such a config
> file?  To see what bash is reading in, try
> strace -e file  bash -login

I have already done. It is in a previos message. Give a look,
it doesn't work with 'E' as it should and how it works for other keys.

Thank you for your help, Peter.

PS: Please, carbon copy the message to me.

[]'s
-- 
Rodrigo Castro   <[EMAIL PROTECTED]>
Computer Science undergraduate student - University of Sao Paulo

I do not fear computers.  I fear the lack of them.
-- Isaac Asimov

Re: Bug#32888: marked as done (base: Removing "Obsolete" package base kills a system)

[Nicolás Lichtmaier]

> dpkg-divert --package base-files --divert-to /dev.base/hda /dev/hda

 Ugh.. ugly... 

 The clean solution is to truncate the file list of base, as proposed. This
will "release" all the files owned by that package safely, with no danger at
all.

Re: Bug#32888: marked as done (base: Removing "Obsolete" package base kills a system)

[Ingo Saitz]

On Sun, Mar 26, 2000 at 09:39:09PM +1000, Hamish Moffatt wrote:
> On Sun, Mar 26, 2000 at 11:03:27AM -, Debian Bug Tracking System wrote:
> > The base package doesn't exist any more for quite a long time, those first
> > time Debian user are most of them quite good and knows what to do to
> > correct this problem. Furthermore for those who can't, they simply have
> > to not remove the base package (which is guaranteed by its essential
> > flag)...  this bug deserves no more to be open.
> 
> I think we are closing bugs for the sake of it here. Any reason
> why the suggestion can't be implemented? (ie make base-files.postinst
> truncate base.list). OK it's not a very nice solution but there isn't
> a better one. I personally have nuked the base package and lost all
> my devices this way.

Sorry to step in, but there might be a better solution to the
problem. I think you can preserve files of an old package which
otherwise wold be removed.

The possible solution I see to this case is using dpkg-divert. If
base is still installed you should dpkg-divert every file in /dev
that used to be in that package to some other place. Example:

dpkg-divert --package base-files --divert-to /dev.base/hda /dev/hda

Then if you remove base, the devices would not get removed.

There however might be many files to divert and I don't know if
somebody really wants to do this. And as already mentioned this
package is quite old so only few people would using it. I won't
reopen this bug but I forward this information to the BTS.

Just my 2 cent.

Ingo
--
Windows, me?

Re: Bash and Letter E

[Peter Cordes]

> Date: Sun, 26 Mar 2000 18:55:21 -0300
> From: Rodrigo Castro <[EMAIL PROTECTED]>
> To: Samuel Tardieu <[EMAIL PROTECTED]>, debian-devel@lists.debian.org,
>   debian-user@lists.debian.org
> Subject: Re: Bash and Letter E 
> 
> Hello,
> [...]
> 
> INPUTRC
> --
> [...]
> "\e[C":forward-char
> "\e[D":backward-char
> "\e[E":beginning-of-line
> "\e[H":beginning-of-line
> "\eOH":beginning-of-line
> "\eOF":end-of-line
> "\EOF":end-of-line
> "\e[F":end-of-line
> "\e[e":end-of-line
> --


 Is "\EOF" really what your file says here?  maybe \E isn't treated as
escape, so bash is looking for a literal "E" to be followed by "OF", and
then it will go to the end of the line.  (Try that, typing "EOF", and see if
the cursor jumps to the end of the line.)  If it does, then remove that line
from /etc/inputrc!

-- 
#define X(x,y) x##y
DUPS Secretary ; http://is2.dal.ca/~dups/
Peter Cordes ;  e-mail: X([EMAIL PROTECTED] , dal.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BCE

re: stuffit expander?

[Peter Cordes]

> Date: Sun, 26 Mar 2000 21:50:54 +0200 (CEST)
> From: Nils Jeppe <[EMAIL PROTECTED]>
> To: debian-devel@lists.debian.org
> Subject: stuffit expander?
> 
> Hello,
> 
> Is there any debian package (or in fact Unix tool at all) that allows
> uncompression of Mac .sit (stuffit) archives?

 I think you want the macutils package.

Peter Cordes

Re: Bash and Letter E

[Peter Cordes]

> Date: Sun, 26 Mar 2000 11:46:23 -0300
> From: Rodrigo Castro <[EMAIL PROTECTED]>
> To: debian-user@lists.debian.org, debian-devel@lists.debian.org
> Subject: Bash and Letter E
> 
> Hello
> 
>   Sorry for asking again about my problem but I can't make my
> letter E work in bash (neither in console nor xterm). See what
> happens:
> 
> - "E" is treated like a dead key. It is not showed at first time, but
> when you press another key after "E", it beeps
> 
> - "E" works in other programs and shells (ksh, csh and so on), so it
> is not a hardware 
> 
> - I booted with another kernel (in case one from RedHat 6.1 CD) and it
> didn't work
> 
> - I booted with init option (linux init=/bin/bash) in order to run no
> init script and it didn't work either. I also tried D option (linux
> D).
> 
> - I tried another keyboard and no success
> 
> - I reinstalled libc6, libncurses5 and base-files
> 
> - I installed older and newer versions of bash and libc6
> 
> - I created a new user with no /etc/input, no ~/.inputrc, no
> ~/.bash(rc|_profile) and even so it didn't work
> 
> I am running out of ideas. I am almost getting bash source code,
> compiling with debug option and running gdb!! Anyone have an idea? 
> 
> PS: Could you send a copy to my email address? I am not a subscriber
> of debian-devel nor debian-user

 Is it really just bash that has this problem?  You tested other shells, but
I don't think they use GNU readline.  What about other things that
use readline, like octave (find something smaller if you don't have it
installed already!  Use the package dependencies to see what depends on
libreadline4.)

 Try using showkey(1) to see what pressing 'E' does on your hardware.  Also
try dumpkeys and loadkeys, to see if the keymaps are ok.

 Maybe you have a weird setting in /etc/inputrc?  Is there such a config
file?  To see what bash is reading in, try
strace -e file  bash -login


-- 
#define X(x,y) x##y
DUPS Secretary ; http://is2.dal.ca/~dups/
Peter Cordes ;  e-mail: X([EMAIL PROTECTED] , dal.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BCE

Re: Idea: Debian Developer Information Center

[Randolph Chung]

Hi Raphael,

> - information about the NMU policy that the maintainer has adopted
>   (timeframe before a NMU is allowed, do i need an authorization to do a
>   nmu ?, ...)

easy to add. Jason would be the person to do this (add a field to the db).
The web interface can easily be changed to update/view this info.

> - the list of packages he's maintaining (yes some maintainer forget
>   that they're maintaining some packages) with up-to-date statistics for
>   each package (number of important/normal/wishlist bugs,
>   standards-version that it does follow, last upload)

I actually have some code to do this, but until our bug system is ldapified
or at least have a non-textual backend, it will be difficult to do. Ben has
a bts ldap setup, but i understand it is not official and not necessarily
maintained all the time.

> - a link to the personnal bug page

the problem with this is that many maintainers have packages registered
under different forms of their email address, so this is actually more
difficult to do. You will probably need to do something with the pgp/gpg sig
on the .dsc files. again, this is something i've looked at in the past, but
at that time i was asked to hold off until the bug system has been overhauled.

> - any other information that may be suitable for such a page like
>   the latest news that must be read by Debian developers (think
>   about debian-devel-announce)

Wouldn't this just be a link to the mail archive for that mailing list?

randolph
-- 
Debian Developer <[EMAIL PROTECTED]>
http://www.TauSq.org/