minutes of debburn/cdrkit team meeting, 2006-09-05

[Peter Samuelson]

The debburn/cdrkit maintainers held an IRC meeting on #debburn on
irc.debian.org, Tuesday, 2006-09-05, 19:00 UTC.  26 people were in the
channel.  Participating and "actively lurking":

  * Joerg Jaspert, developer / project admin
  * Eduard Bloch, developer
  * Steve McIntyre, developer
  * Peter Samuelson, contributor
  * Luis Medinas, Gentoo cdrtools maintainer
  * Christian Fromme, contributor
  * Motoko Aoyama

(Note: in these minutes, "Joerg" is Joerg Jaspert, _not_ former
upstream maintainer Joerg Schilling.)

Joerg opened the meeting at 19:02 with a question: "Do we want to go
away from source compatibility with cdrtools?"  He believes that
license problems prevent merging most patches from cdrtools anyway,
except mkisofs.  Eduard said it's possible to encourage contributors to
send patches to both forks; Peter and Joerg suggested that patches
might flow from cdrkit to cdrtools.  Steve expressed some doubt that
Joerg Schilling ever accepts outside patches to cdrecord anyway.
Consensus was that source-level compatibility is _not_ worth the
trouble, although command-line compatibility with cdrecord shall be
provided at least until after etch is released.

Joerg proposed a hacking policy of doing disruptive changes on a
branch, and keeping the development trunk stable.  Nobody disagreed.

Joerg asked whether to split the source into multiple tarballs - wodim,
cdda2wav, mkisofs, possibly the support libraries.  He suggested that
this be done after etch.  Luis thought separate tarballs would be
easier to maintain.  Peter thought it was a good idea, though possibly
a lot of work due to the use of libscg and libschily.  Joerg agreed.
Steve wanted to start phasing out libschily, as "we should be able to
assume a working libc for our target platforms".  More general
agreement, though Joerg was concerned about ensuring portability.
Peter asked for confirmation that cdrkit can officially require ANSI C.
(The question had come up earlier as an aside, and several people had
agreed.)  Joerg proposed that this happen on a branch.  Everyone
agreed.  Eduard asked for confirmation that the 'mods-archive'
directory (a set of Debian cdrtools patches, already applied to cdrkit)
could be deleted or moved.  [Two minutes later he moved it outside the
main tree.]

Joerg asked about a policy for deciding to give someone svn commit
access.  He noted that while some contributors are well known from
Debian work, other current and future contributors will come from
outside Debian and will not be well known here.  Peter suggested that
it be decided simply based on a history of good patches.  Steve agreed.
Eduard suggested also requiring a gpg chain-of-trust.  Joerg agreed
that it's necessary to see some patches before giving a person commit
access, and suggested that when someone asks for access, an existing
commiter "advocate" the person.  Luis thought that was fair.

Eduard asked for opinions on a "copyright messages" policy, given the
potential for social and legal FUD and harassment from the original
upstream author.  Peter clarified that this was about user-visible
output messages, not copyright notices inside the source, which must be
retained regardless.  Joerg suggested leaving the original copyright
lines in the output, and adding a line for the current maintainers
where appropriate, as well as a notice not to bother the original
author.  Peter was unhappy with the verbose report currently output.
Eduard proposed adding even more text, including the address for bug
reports ([EMAIL PROTECTED]).  Consensus was to add
this notice, but also streamline the whole header somewhat.  [Eduard
wrote and committed a patch for this a few minutes after the meeting].

Eduard asked what to do about the bugs now open against cdda2wav and
mkisofs in the Debian BTS.  He suggested to "ping the contributors,
wait 4 weeks, close?"  Joerg agreed.

After a bit of off-meeting-topic discussion, Joerg declared the meeting
adjourned at 19:35.


signature.asc
Description: Digital signature

Bug#386206: ITP: fedora-directory-server -- An LDAP server designed to manage large directories of users and resources

[Sven Herzberg]

Package: wnpp
Severity: wishlist
Owner: Sven Herzberg <[EMAIL PROTECTED]>


* Package name: fedora-directory-server
  Version : 1.0.2
  Upstream Author : 
* URL : http://www.directory.fedora.redhat.com/
* License : GPL + exceptions: 
http://directory.fedora.redhat.com/wiki/Licensing
  Programming Lang: C
  Description : An LDAP server designed to manage large directories of 
users and resources

An LDAP server designed to manage large directories of users and
resources. Feature include:
..
 * 4-Way Multi-Master Replication
 * High Scalability
 * Active Directory user and group synchronization
 * Secure authentication and transport (SSLv3, TLSv1, and SASL)
 * Support for LDAPv3
 * On-line, zero downtime, LDAP-based update of schema, configuration,
   management and in-tree Access Control Information (ACIs)
 * Graphical console for all facets of user, group, and server
   management 

-- System Information:
Debian Release: testing/unstable
  APT prefers sid
  APT policy: (500, 'sid')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.17-6-686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)


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

Re: dh_python and python policy analysis

[Otavio Salvador]

Manoj Srivastava <[EMAIL PROTECTED]> writes:


>Copyright (c) 2006 Manoj Srivastava
>
>Revision History
>Revision 1.0.5   4^th November 2006
   Setember?

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


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

Re: Buildd maintenance for dummies

[Roger Leigh]

Luk Claes <[EMAIL PROTECTED]> writes:

Hi Luk,

> I recently took over the buildd maintenance of signy.farm.ftbfs.de, a mips
> buildd for experimental, sarge-backports, sarge-volatile and non-free
> (whitlisted packages). I actually started in helping with the buildd
> maintenance of odin.farm.ftbfs.de which is a similar buildd for sparc.
>
> As newbie I made some stupid mistakes... I hereby want to announce a
> wiki page to make sure newbies in buildd maintenance don't make this
> mistakes again :-)

It sounds like a great idea.

Also, feel free to note them down in a new README under
  svn+ssh://svn.debian.org/svn/buildd-tools/trunk/buildd
and I'll turn them into a nice manpage at some point.  I'm about
halfway through packaging it, though I'm bogged down
with other commitments right at the present.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


pgpNET28lyNIB.pgp
Description: PGP signature

Linking a static library with -fPIC for flex

[Manoj Srivastava]

Hi,

Starting with version 2.5.31-18 of flex we have started
 providing a static library compiled with position independent code,
 namely, libfl_pic.a, in addition to the normal libfl.a library. This
 is my mail, in accordance to §10.2 of the Debian policy.

The problem is with packages that contain shared libraries
 with a flex scanner compiled in. Since flex generates code 
 that is not self contained, and the missing symbols live in
 libfl.a. However, since linking a shared library with a object
 containing non position independent code stopped working with gcc 4.1
 (apparently, it was sheer luck that it worked at all). So now we also
 provide libfla_pic.a for shared library packages to link with.

I was initially going to just provide libfl.a with position
 independent code, which would have prevented the FTBS breakage for
 scanner containing shared libraries, at the expense of a register
 lost for binaries that were otherwise statically linked, and perhaps
 slower execution speeds. When I broached this on IRC, people
 commented that I could provide libfl_pic.a in addition to libfl.a ,
 but compile them both with -fPIC, and transition back at some later
 point to having a non position independent static libfl.a

Then I realized I was falling into the trap of preferring
 convenience to correctness; the right thing to identify and fix
 packages building shared objects linked to non relocatable code. So,
 now these packages can link to  libfl_pic.a, and binaries can
 continue to link with  libfl.a.

An alternative would have been to provide a full fledged
 shared library, but that would have been a major break with upstream
 and other distributions that also have flex, and would entail
 creating new library and devel packages for flex, which is more work
 that seems justified (considering that we would have to maintain the
 fork, and keep track of any ABI changes, and all that).

 manoj

arch-tag: 7421b315-d205-4e09-9a81-0fef07ba57b7

-- 
A grammarian's life is always in tense.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: dh_python and python policy analysis

[Manoj Srivastava]

Hi,

This is version 1.05 of the draft, now with typo fixes, and
 some initial policy support for partial upgrades for pure python
 public modules that are trying to drop support for older versions of
 python. The idea is that error cases are minimized if we do not drop
 a version of python in a new stable that was the default version in
 oldstable; at the same time insisting that every pre python public
 module that says "all" in the versions supported field must support
 all shipping versions of python in stable (even if this takes extra
 effort in the form of splitting off private modules and including them
 conditionally based on python version from a wrapper module that does
 little but conditional imports.

The current version, and future updates, are to be
 found at http://www.golden-gryphon.com/software/manoj-policy/

manoj

  Packaging with the new Python policy

A package developers view

  Manoj Srivastava

   Developer
   The Debian Project

   Copyright (c) 2006 Manoj Srivastava

   Revision History
   Revision 1.0.5   4^th November 2006
   Revision 1.0.4   12 Aug 2006
   Revision 1.0.3   10 Aug 2006
   Revision 1.0.2   8 Aug 2006
   Revision 1.0.1   07 Aug 2006
   Revision 1.0.0   31 Jul 2006

   Specification of the new Python policy. This article grew as an attempt to
   correct a gap in the concrete specification of the new Python policy, and
   has grown to be close to a formal specification of the proposed new
   policy.

   --

   Table of Contents

   1. [1]Introduction

1.1. [2]Acknowledgements

   2. [3]Goals of the new Python policy

   3. [4]Nomenclature and definitions

3.1. [5]Python versions

 3.1.1. [6]The Default Python version

3.2. [7]Categorization of Python software

   4. [8]General Notes

4.1. [9]Naming python module packages

4.2. [10]Python versions supported by the source

4.3. [11]Byte compilation

4.4. [12]Linking extention modules

4.5. [13]Depends:

4.6. [14]Provides

4.7. [15]Build-Depends:

4.8. [16]Deprecating "current" in versions supported

   5. [17]Recipe for developers

5.1. [18]Script

 5.1.1. [19]Supported versions

5.2. [20]Private Pure Python Modules

 5.2.1. [21]Byte compilation

 5.2.2. [22]Supported versions

5.3. [23]Private Extension

 5.3.1. [24]Supported versions

5.4. [25]Public pure Python Module

 5.4.1. [26]Byte compiling

 5.4.2. [27]Supported versions

 5.4.3. [28]Depends:

5.5. [29]Public Extension

 5.5.1. [30]Supported versions

 5.5.2. [31]Provides

   6. [32]Changing the default Python version

6.1. [33]Python rtupdate scripts

 6.1.1. [34]rtupdate script invocation

1. Introduction

 While trying to update SELinux packages, I ran across problems in trying
   to determine if my packages were complying with the new python policy: any
   practical tips for packaging generally devolved to the statement "Oh, just
   run dh_python". This is my attempt to offer more concrete tips for
   packaging. While this document started by reverse engineering dh_python,
   it has, thanks to help from various people more knowledgeable about Python
   than I, moved beyond that, and is closer to being a specification
   unfettered by the idiosyncrasies of current tools and implementations.

 So now this document is a draft formal specification of the proposed new
   Python packaging policy. While it draws upon earlier documents, notable
   [35]Debian Python Policy , and the [36]new policy Wiki, the [37]Debian
   Python FAQ, and the source code for dh_python, and debhelper scripts, it
   has essentially been written from scratch, with material reworded,
   reorganized, and rearranged, to the extent that it bears little
   resemblance to the original sources.

 Compiled Python modules are very dependent on the specific Python
   version they were compiled against, and may otherwise have restrictions on
   the versions of Python they are compatible with. Unless care is taken,
   introducing, or dropping, new versions of Python, or changing the default
   version, trigger long and often painful transitions where the archive is
   inconsistent, and the systems is ill-integrated for the duration. This new
   Python policy seeks to address these potential messy transitions, and
   minimize the pai

Re: Buildd maintenance for dummies

[Marc Singer]

On Tue, Sep 05, 2006 at 07:58:18PM +0200, Luk Claes wrote:
> Hi
> 
> I recently took over the buildd maintenance of signy.farm.ftbfs.de, a mips
> buildd for experimental, sarge-backports, sarge-volatile and non-free
> (whitlisted packages). I actually started in helping with the buildd
> maintenance of odin.farm.ftbfs.de which is a similar buildd for sparc.
> 
> As newbie I made some stupid mistakes... I hereby want to announce a wiki page
> to make sure newbies in buildd maintenance don't make this mistakes again :-)

Hurah!

> The wiki page [0] only talks about answering to build logs as there is already
> some decent information for setting up and configuring a buildd host and
> wanna-build [1] [2] [3].
> 
> Don't hesitate to add or improve content of the page, it's a wiki page after
> all...
> 
> Cheers
> 
> Luk
> 
> [0] http://wiki.debian.org/Buildd/BuildLogs
> [1] http://kmuto.jp/open.cgi?buildd
> [2] http://www.debian.org/devel/buildd/
> [3] https://db.farm.ftbfs.de/farm-reference/index.en.html
> 
> -- 
> Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
> Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D
> 




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

Re: Bug#386138: ITP: mpop -- a POP3 client

[Nacho Barrientos Arias]

Date: Tue, 05 Sep 2006 16:23:27 +0200
Carlos Martin <[EMAIL PROTECTED]> wrote:

-- snip --

> * Package name: mpop
>   Version : 1.0.2
>   Upstream Author : Martin Lambers <[EMAIL PROTECTED]>
> * URL : http://mpop.sourceforge.net
> * License : GPL
>   Programming Lang: C
>   Description : a POP3 client

IMHO, this description is a bit... "insipid" :)

-- 
bye,
- Nacho


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

Re: Bug#386138: ITP: mpop -- a POP3 client

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Carlos Martin wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Carlos Martin <[EMAIL PROTECTED]>
> 
> 
> * Package name: mpop
>   Version : 1.0.2
>   Upstream Author : Martin Lambers <[EMAIL PROTECTED]>
> * URL : http://mpop.sourceforge.net
> * License : GPL
>   Programming Lang: C
>   Description : a POP3 client
> 
> mpop can retreive mail from several POP3 mailboxes, do filtering and
> deliver the mail through a mail delivery agent (MDA) or to to maildir
> folders or mbox files.
> 
> It supports encryption several types of encryption and authentication
>  mechanisms, as well as pipelining.

It might be helpful to summarize the "Some things that mpop can do
and fetchmail cannot:" in the full description".

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE/bwgS9HxQb37XmcRAlO5AKDd9fOgyMmtrJpOtUtG+D4fE9oqAgCfZSRf
0XOqB7b6zknskI6djfW78qA=
=JpCW
-END PGP SIGNATURE-


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

Buildd maintenance for dummies

[Luk Claes]

Hi

I recently took over the buildd maintenance of signy.farm.ftbfs.de, a mips
buildd for experimental, sarge-backports, sarge-volatile and non-free
(whitlisted packages). I actually started in helping with the buildd
maintenance of odin.farm.ftbfs.de which is a similar buildd for sparc.

As newbie I made some stupid mistakes... I hereby want to announce a wiki page
to make sure newbies in buildd maintenance don't make this mistakes again :-)

The wiki page [0] only talks about answering to build logs as there is already
some decent information for setting up and configuring a buildd host and
wanna-build [1] [2] [3].

Don't hesitate to add or improve content of the page, it's a wiki page after
all...

Cheers

Luk

[0] http://wiki.debian.org/Buildd/BuildLogs
[1] http://kmuto.jp/open.cgi?buildd
[2] http://www.debian.org/devel/buildd/
[3] https://db.farm.ftbfs.de/farm-reference/index.en.html

-- 
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D



signature.asc
Description: OpenPGP digital signature

Re:[DCCIT2006] Talk soppressi

[[EMAIL PROTECTED]]

> * Compilazione del Kernel su Debian (Rappa Mauro)
>
> perchè i relatori non mi hanno confermato la loro presenza.

Scusate, ma sono pressimo!
confermo la mia presenza!

se possibile,  lo terrei il sabato pomeriggio!

Ciao *!

Bug#386146: ITP: libconfig-file-perl -- Parses simple configuration files

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf <[EMAIL PROTECTED]>

* Package name: libconfig-file-perl
  Version : 1.4
  Upstream Author : Gunnar Wolf <[EMAIL PROTECTED]>
* URL : http://www.cpan.org/modules/by-module/Config
* License : GPL+Artistic
  Description : Parses simple configuration files

 ConfigFile parses simple configuration files and store its values in
 an anonymous hash reference. The syntax of the configuration file is
 quite simple:

 # This is a comment
 VALUE_ONE = foo
 VALUE_TWO = $VALUE_ONE/bar
 VALUE_THREE = The value contains a \# (hash). # This is a comment.
 COMPOSED_VALUE[one] = The first component of a clustered value
 COMPOSED_VALUE[two] = The second component of a clustered value

This module is already packaged in Debian as libconfigfile-perl
(dpkg-sig and apt-file depend on it) - It is a native package, and I
am renaming it in order to make it available in CPAN for wider
distribution and to turn it into a non-native package. 

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.14-cajita
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#386138: ITP: mpop -- a POP3 client

[Carlos Martin]

Package: wnpp
Severity: wishlist
Owner: Carlos Martin <[EMAIL PROTECTED]>


* Package name: mpop
  Version : 1.0.2
  Upstream Author : Martin Lambers <[EMAIL PROTECTED]>
* URL : http://mpop.sourceforge.net
* License : GPL
  Programming Lang: C
  Description : a POP3 client

mpop can retreive mail from several POP3 mailboxes, do filtering and
deliver the mail through a mail delivery agent (MDA) or to to maildir
folders or mbox files.

It supports encryption several types of encryption and authentication
 mechanisms, as well as pipelining.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-rc5
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Re: [DCCIT2006] Talk soppressi

[Marco Bertorello]

On Tue, 5 Sep 2006 16:30:06 +0200
Marco Bertorello <[EMAIL PROTECTED]> wrote:

> Ciao *

ops!

sorry me, this mail was for [EMAIL PROTECTED] :-(

sorry me, again

-- 
Marco Bertorello
System Administrator
http://bertorello.ns0.it


signature.asc
Description: PGP signature

Re: potential mass bug filing: sysvinit dependency

[martin f krafft]

also sprach Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2006.09.05.1645 
+0200]:
> You're always welcome to use the init-ng alioth project to discuss
> ideas and do upstart development, you know.  It is completely
> on-topic there.

Right. We're moving there. Anyone interested, please follow!

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
#define emacs eighty megabytes and constantly swapping.


signature.asc
Description: Digital signature (GPG/PGP)

Re: potential mass bug filing: sysvinit dependency

[Henrique de Moraes Holschuh]

On Tue, 05 Sep 2006, martin f krafft wrote:
> also sprach Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2006.09.05.1614 
> +0200]:
> > invoke-rc.d is a maintainer script compatibility layer to
> > interface to the initscript subsystem (that happens to guarantee
> > some functionality that some initscript subsystems don't provide
> > natively while at it).
> > 
> > If that layer doesn't allow for everything we need, then it is
> > time to revise it, of course.  Just like it is well past time to
> > fix the update-rc.d crap.
> 
> I am going to retreat now to my cave and ponder on how this could be
> done. Need to understand upstart better.
> 
> I appreciate anyone interested in helping out. Co-maintainers more
> than welcome!

You're always welcome to use the init-ng alioth project to discuss ideas and
do upstart development, you know.  It is completely on-topic there.

I'd very much like to see runit and upstart being easily deployable in
Debian *and* usable to their full capabilities.

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


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

Re: potential mass bug filing: sysvinit dependency

[martin f krafft]

also sprach Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2006.09.05.1614 
+0200]:
> invoke-rc.d is a maintainer script compatibility layer to
> interface to the initscript subsystem (that happens to guarantee
> some functionality that some initscript subsystems don't provide
> natively while at it).
> 
> If that layer doesn't allow for everything we need, then it is
> time to revise it, of course.  Just like it is well past time to
> fix the update-rc.d crap.

I am going to retreat now to my cave and ponder on how this could be
done. Need to understand upstart better.

I appreciate anyone interested in helping out. Co-maintainers more
than welcome!

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
NP: Bass Communion / Ghosts on Magnetic Tape


signature.asc
Description: Digital signature (GPG/PGP)

[DCCIT2006] Talk soppressi

[Marco Bertorello]

Ciao *

Ad oggi, mi trovo a dover sopprimere diversi talk:

* DebianPAit: Una distribuzione per la P.A.
* Migrazione a DEBIAN nella P.A.
* Le politiche di debian

perchè sono talk orfani (ovvero il relatore non si sa chi sia)

* Debian: Strumenti di Gestione (Claudio Moratti)

a causa della impossibilità del relatore di essere presente alla
debconf :-(

* APT-GET (FrancescoEsposito)
* Compilazione del Kernel su Debian (Rappa Mauro)

perchè i relatori non mi hanno confermato la loro presenza.

Ovviamente, se qualcuno vuole rientrare, fa ancora in tempo ;-) basta
modificare il wiki [1]  e rispondere alla mia mail circa la conferma (e
le preferenze)

ciao,

[1] http://italiandebconf.debianizzati.org/

-- 
Marco Bertorello
System Administrator
http://bertorello.ns0.it


signature.asc
Description: PGP signature

Re: potential mass bug filing: sysvinit dependency

[Henrique de Moraes Holschuh]

On Tue, 05 Sep 2006, martin f krafft wrote:
> also sprach Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2006.09.05.1526 
> +0200]:
> > This one needs to depend on sysv-like link farm functionality (as
> > opposed to, say, file-rc style).  If upstart provides symlinks,
> > then we need a virtual package.  If it doesn't, sysv-rc-conf needs
> > to keep depending on sysvinit.
> 
> Well, upstart does get rid of SysV as we know it. The upstart
> package itself gets rid of the need for invoke-rc.d, providing
> /sbin/start and /sbin/stop.

invoke-rc.d is a maintainer script compatibility layer to interface to the
initscript subsystem (that happens to guarantee some functionality that
some initscript subsystems don't provide natively while at it).

If that layer doesn't allow for everything we need, then it is time to
revise it, of course.  Just like it is well past time to fix the update-rc.d
crap.

I still think we should have renamed these utilities to "initscript-invoke"
and "initscript-register" while implementing at the very least as much
namespace control as we have in dpkg-divert for initscript-register (and a
command line interface that could be better extended for out-of-band
dependency information too).

> However, upstart-compat-sysv provides compatibility.

Right answer.  Just make sure to always have that package installed.  Even
if we eventually switch to upstart as the default initscript subsystem, we
will still need to support alternate initscript subsystems, and that means
invoke-rc.d or something else that does its job for *all* supported
initscript subsystems.

Ah, there is also all required telinit functionality, too (we should
identify this subset and write it down as policy, as a matter of fact).

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


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

Re: potential mass bug filing: sysvinit dependency

[Henrique de Moraes Holschuh]

On Tue, 05 Sep 2006, Mark Brown wrote:
> On Tue, Sep 05, 2006 at 10:28:43AM -0300, Henrique de Moraes Holschuh wrote:
> > On Tue, 05 Sep 2006, Mark Brown wrote:
> > > invoke-rc.d.  IIRC doing something more obvious caused upgrade issues at
> > > the time due to issues with having both sysv-rc and file-rc.
> 
> > invoke-rc.d was added to sysv-rc and file-rc at almost the same time, we
> > didn't botch THAT transition at all, thank you very much.
> 
> Well, I'm glad that I didn't say that the transition had been botched,
> then.

I apologise, I can see how my answer would imply that I was annoyed at you.
No, you did not say (or imply) the transition had been botched.

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


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

Re: potential mass bug filing: sysvinit dependency

[Mark Brown]

On Tue, Sep 05, 2006 at 10:28:43AM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 05 Sep 2006, Mark Brown wrote:
> > invoke-rc.d.  IIRC doing something more obvious caused upgrade issues at
> > the time due to issues with having both sysv-rc and file-rc.

> invoke-rc.d was added to sysv-rc and file-rc at almost the same time, we
> didn't botch THAT transition at all, thank you very much.

Well, I'm glad that I didn't say that the transition had been botched,
then.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: potential mass bug filing: sysvinit dependency

[martin f krafft]

also sprach Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2006.09.05.1526 
+0200]:
> This one needs to depend on sysv-like link farm functionality (as
> opposed to, say, file-rc style).  If upstart provides symlinks,
> then we need a virtual package.  If it doesn't, sysv-rc-conf needs
> to keep depending on sysvinit.

Well, upstart does get rid of SysV as we know it. The upstart
package itself gets rid of the need for invoke-rc.d, providing
/sbin/start and /sbin/stop.

However, upstart-compat-sysv provides compatibility.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
NP: Bass Communion / Bass Communion


signature.asc
Description: Digital signature (GPG/PGP)

Re: potential mass bug filing: sysvinit dependency

[Henrique de Moraes Holschuh]

On Tue, 05 Sep 2006, Henrique de Moraes Holschuh wrote:
> system since stable.  Any initscript package that does not provide
> invoke-rc.d (and doesn't piggyback on the one from sysvinit or file-rc) has

I do mean "init script subsystem" package, of course.  Not regular packages
that have initscripts for the services they provide.

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


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

Re: potential mass bug filing: sysvinit dependency

[Henrique de Moraes Holschuh]

On Tue, 05 Sep 2006, Mark Brown wrote:
> invoke-rc.d.  IIRC doing something more obvious caused upgrade issues at
> the time due to issues with having both sysv-rc and file-rc.

invoke-rc.d was added to sysv-rc and file-rc at almost the same time, we
didn't botch THAT transition at all, thank you very much.

It is also available since oldstable, and a *requirement* of any initscript
system since stable.  Any initscript package that does not provide
invoke-rc.d (and doesn't piggyback on the one from sysvinit or file-rc) has
a critical bug.

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


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

Re: potential mass bug filing: sysvinit dependency

[Henrique de Moraes Holschuh]

On Tue, 05 Sep 2006, martin f krafft wrote:
> Here is the list of packages that depend on sysvinit. For packages
> marked with (*), I already have the maintainers' consent.
> 
>   sysv-rc-conf

This one needs to depend on sysv-like link farm functionality (as opposed
to, say, file-rc style).  If upstart provides symlinks, then we need a
virtual package.  If it doesn't, sysv-rc-conf needs to keep depending on
sysvinit.

> If there are cases when the dependency cannot be removed, we ought
> to consider introducing a new virtual package for init daemons.

Virtual packages are for interfaces, so if anyone needs the sysv initscript
interface and we start supporting something else (we don't right now, but
runit would benefit from it), we need a virtual package for that (one which
right now *all* packages with initscripts would have to depend upon).  If
anyone needs the sysv symlink farm interface, and more than one package
provides it, we will need another virtual package for that, etc.

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


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

Re: Accepted lynx-cur 2.8.6pre2-1 (source i386 all)

[Thomas Dickey]

In article <[EMAIL PROTECTED]> you wrote:
>* There was no time to upload 2.8.6dev19 because 2.8.6pre2 was released
>  so soon.

Thanks - I put out pre.1 on Thursday since I anticipated not having time
yesterday to work on it, but decided that the feedback from pre.1 was
doable for Sunday.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


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

Re: potential mass bug filing: sysvinit dependency

[martin f krafft]

also sprach martin f krafft <[EMAIL PROTECTED]> [2006.09.05.1344 +0200]:
> Anyway, I shall wait until tomorrow and if I don't hear any
> objections, I'll go ahead.

The list is down to seven packages that need updating. I shall thus
send out the bugs now. Sorry for the noise.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"i believe that the moment is near when by a procedure
 of active paranoiac thought, it will be possible
 to systematise confusion and contribute to
 the total discrediting of the world of reality."
  -- salvador dali


signature.asc
Description: Digital signature (GPG/PGP)

Re: Bug#385866: ITP: ttf-vlgothic -- Japanese TrueType font from VineLinux

[Hideki Yamane]

Hi,

On Tue, 05 Sep 2006 00:02:58 +0900
Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> Please paste the full debian/copyright information.
 
 OK, here is.


This package was debianized by Hideki Yamane (Debian-JP) <[EMAIL PROTECTED]> on
Fri, 25 Aug 2006 02:51:33 +0900.

It was downloaded from http://dicey.org/vlgothic/

Upstream Authors: Daisuke SUZUKI <[EMAIL PROTECTED]> and Project Vine <[EMAIL 
PROTECTED]>

Copyright: (c) 1990-2003 Wada Laboratory, the University of Tokyo
   (c) 2003-2004 Electronic Font Open Laboratory (/efont/)
   (c) 2003-2006 M+ FONTS PROJECT
   (c) 2006 Daisuke SUZUKI <[EMAIL PROTECTED]>
   (c) 2006 Project Vine <[EMAIL PROTECTED]>

License:


Upstream author's license information (In Japanese, UTF-8)

  バイナリは、ソースコードのライセンスと同等とします。ただし、フォントの
  文書への埋め込みなど、フォントとしての再使用を目的としない用途においては、
  以下で言う Redistribution には当たらず、制限なく行えるものとします。

  Copyright (c) 1990-2003
Wada Laboratory, the University of Tokyo. All rights reserved.
  Copyright (c) 2003-2004
Electronic Font Open Laboratory (/efont/). All rights reserved.

  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions
  are met:
  1. Redistributions of source code must retain the above copyright notice,
 this list of conditions and the following disclaimer.
  2. Redistributions in binary form must reproduce the above copyright notice,
 this list of conditions and the following disclaimer in the documentation
 and/or other materials provided with the distribution.
  3. Neither the name of the Wada Laboratory, the University of Tokyo nor
 the names of its contributors may be used to endorse or promote products
 derived from this software without specific prior written permission.

  THIS SOFTWARE IS PROVIDED BY WADA LABORATORY, THE UNIVERSITY OF TOKYO AND
  CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
  NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
  PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE LABORATORY OR
  CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
  EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
  PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
  OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
  OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

  埋め込まれたビットマップフォントのライセンスについては、各フォントの添付
  ドキュメントを同梱しておりますので、そちらをご参照ください。

  本フォントに含まれる東風フォント由来のグリフは、古川泰之さんが単独で作成した
  オリジナルデザインに基づく Public Domain 相当のデータのみが含まれています。
  日立製作所とタイプバンクにより開発された 32 ドットビットマップに由来する
  漢字データ、ビットマップデータ、現在の CLWFK の ライセンスと異なるライセンス
  で配布されていた和田研フォントに由来するデータは含まれていません。


Upstream author's license information (original under Japanese, translated to
English by GOTO Masanori <[EMAIL PROTECTED]> for convenience)

  Binary data is handled equivalent to source code license.  However,
  there is no limitation and the below description is not applied
  as for in order not to reuse as font (ex: font is embeddd to documents).


  Copyright (c) 1990-2003
Wada Laboratory, the University of Tokyo. All rights reserved.
  Copyright (c) 2003-2004
Electronic Font Open Laboratory (/efont/). All rights reserved.

  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions
  are met:
  1. Redistributions of source code must retain the above copyright notice,
 this list of conditions and the following disclaimer.
  2. Redistributions in binary form must reproduce the above copyright notice,
 this list of conditions and the following disclaimer in the documentation
 and/or other materials provided with the distribution.
  3. Neither the name of the Wada Laboratory, the University of Tokyo nor
 the names of its contributors may be used to endorse or promote products
 derived from this software without specific prior written permission.

  THIS SOFTWARE IS PROVIDED BY WADA LABORATORY, THE UNIVERSITY OF TOKYO AND
  CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
  NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
  PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE LABORATORY OR
  CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
  EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
  PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
  OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
  OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


  Licenses for embedded bi

Re: Bug#386060: ITP: c++-annotations -- The C++ Annotations tutorial by Frank B. Brokken

[Frank B. Brokken]

George Danchev  wrote:
> On Tuesday 05 September 2006 13:21, Hamish Moffatt wrote:
>
> > This sounds interesting but why is it useful to have a package?
> 
> Well, because it is easier for Debian users to search for, install, upgrade 
> such books. Basically on the same line wrt packaging are the c-cpp-reference 
> package (although not being so exhaustive) and ocaml-book-en|fr (being a very 
> serious book, but unfortunately in non-free).

Let me add to that the following:

- One of the backbones of Debian is to give back to the community what
basically belongs to the community. There's no need to restrict that to
executable software and its associated documentation like user guides and
man-pages. The Annotations are used by a large number of people all over the
world. If you'd like to see some reactions, consider browsing through
http://www.icce.rug.nl/documents/cplusplus.fanmail.txt. It might also be
enlightning to ask Google to search for 'C++ Annotations'.
The large number of people already using the Annotations seems like a
good basis for deciding that the Annotations are something `for the
community'. But if you look at Google's list, then you'll see that many
links refer to old versions. That's a pity, and by adding the Annotations
to Debian's set of packages it will be very easy for all those people to keep
their versions up-to-date or to obtain an installation of their own.

- Related to the above: I have been approached by publishers asking me to
allow them to publish the Annotations. The problem here has always been that I
also would like to remain to be able to upgrade them. The situation could
arise where the publisher publishes an outdated version, which becomes
unattractive since a more recent version has appeared on the Internet. 
When the Annotations are added to Debian this problem does not occur: although
Debian can be considered the `publisher' it will always be simple to
upgrade. Nobody would suffer any disadvantage from that, and everybody
involved would benefit. I like win-win situations ;-)

- The Annotations will benefit, too. By now they exist for well over a
decade, and from the moment they appeared on the Internet, people have been so
kind as to send in suggestions for clarifications or repairs. Debian's
community consists of a large group of knowledgeable C++ programmers, and I'm
sure many useful suggestions for improvements will come from this group, which
will only result in an improvement of the C++ Annotations's quality.

-- 
Frank B. Brokken
Computing Center, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl:11371/
Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D  B19F DAC4 BE50 38C6 6170


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

Re: potential mass bug filing: sysvinit dependency

[Mark Brown]

On Tue, Sep 05, 2006 at 01:44:57PM +0200, martin f krafft wrote:
> also sprach Marco d'Itri <[EMAIL PROTECTED]> [2006.09.05.1330 +0200]:

> > This may be a good time to remind maintainers that often
> > a versioned conflict may be more appropriate than a versioned
> > dependency.

> Right.

Most of these are probably added to ensure the avalibility of
invoke-rc.d.  IIRC doing something more obvious caused upgrade issues at
the time due to issues with having both sysv-rc and file-rc.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: potential mass bug filing: sysvinit dependency

[martin f krafft]

also sprach Marco d'Itri <[EMAIL PROTECTED]> [2006.09.05.1330 +0200]:
> 11 packages is hardly a mass bugs filing and this is a bug
> regardless of the upstart issue. Please go on.

The devel ref says to contact -devel for more than 10 bugs.

Anyway, I shall wait until tomorrow and if I don't hear any
objections, I'll go ahead.

> This may be a good time to remind maintainers that often
> a versioned conflict may be more appropriate than a versioned
> dependency.

Right.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
why do they sterilise the needle for lethal injections?


signature.asc
Description: Digital signature (GPG/PGP)

Re: potential mass bug filing: sysvinit dependency

[Marco d'Itri]

On Sep 05, martin f krafft <[EMAIL PROTECTED]> wrote:

> I would like to file (normal) bugs to ask the maintainer to remove
> the dependency, and per our Developers' Reference 7.1.1 I am
> soliciting comments.
11 packages is hardly a mass bugs filing and this is a bug regardless of
the upstart issue. Please go on.

This may be a good time to remind maintainers that often a versioned
conflict may be more appropriate than a versioned dependency.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#386060: ITP: c++-annotations -- The C++ Annotations tutorial by Frank B. Brokken

[George Danchev]

On Tuesday 05 September 2006 13:21, Hamish Moffatt wrote:
> On Tue, Sep 05, 2006 at 12:33:56AM +0200, Frank B. Brokken wrote:
> > The C++ Annotations are a tutorial intended for knowledgeable users of C
> > (or any other language using a C-like grammar, like Perl or Java) who
> > would like to know more about, or make the transition to, C++. The C++
> > Annotations do not cover all aspects of C++. In particular, C++'s basic
> > grammar, which is, for all practical purposes, equal to C's grammar, is
> > not covered. The various C++ topics are covered in the following
> > chapters:
>
> Hi,

Hello,

> This sounds interesting but why is it useful to have a package?

Well, because it is easier for Debian users to search for, install, upgrade 
such books. Basically on the same line wrt packaging are the c-cpp-reference 
package (although not being so exhaustive) and ocaml-book-en|fr (being a very 
serious book, but unfortunately in non-free).

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: Bug#386060: ITP: c++-annotations -- The C++ Annotations tutorial by Frank B. Brokken

[Hamish Moffatt]

On Tue, Sep 05, 2006 at 12:33:56AM +0200, Frank B. Brokken wrote:
> The C++ Annotations are a tutorial intended for knowledgeable users of C (or
> any other language using a C-like grammar, like Perl or Java) who would like
> to know more about, or make the transition to, C++. The C++ Annotations do not
> cover all aspects of C++. In particular, C++'s basic grammar, which is, for
> all practical purposes, equal to C's grammar, is not covered. The various C++
> topics are covered in the following chapters:

Hi,

This sounds interesting but why is it useful to have a package?


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


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

potential mass bug filing: sysvinit dependency

[martin f krafft]

Hi DDs,

I am trying to get Scott's upstart daemon into Debian [0][1][2].
It's an alternative to sysvinit, but there's still quite a bunch of
packages which depend on sysvinit. These dependencies were introduced a while
back to work around an invoke-rc.d issue, and from all I can tell, they are
legacy/obsolete now.

0. http://www.netsplit.com/blog/work/canonical/upstart.hml
1. http://www.netsplit.com/blog/work/canonical/upstart2.html
2. https://wiki.ubuntu.com/ReplacementInit

Here is the list of packages that depend on sysvinit. For packages
marked with (*), I already have the maintainers' consent.

  sysv-rc-conf
  powertweak-extra (*)
  nis (*)
  nfs-kernel-server 
  nfs-common
  modutils
  lm-sensors
  kbd
  genpower
  console-tools
  bluez-utils

I would like to file (normal) bugs to ask the maintainer to remove
the dependency, and per our Developers' Reference 7.1.1 I am
soliciting comments.

If there are cases when the dependency cannot be removed, we ought
to consider introducing a new virtual package for init daemons.

Thanks for any comments.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
NP: Explosions in the Sky / The Earth is not a Cold Dead Place


signature.asc
Description: Digital signature (GPG/PGP)

Bug#386079: ITP: libsnmp-multi-perl -- Perform SNMP operations on multiple hosts simultaneously

[Arne Goetje]

Package: wnpp
Severity: wishlist
Owner: Arne Goetje <[EMAIL PROTECTED]>

* Package name: libsnmp-multi-perl
  Version : 2.1-1
  Upstream Author : Karl ("Terminator rAT") Schilke <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~tpg/SNMP-Multi-2.1/Multi.pm
* License : GPL / Artistic (same as Perl itself)
  Programming Lang: Perl
  Description : Perform SNMP operations on multiple hosts simultaneously

The SNMP::Multi package provides a mechanism to perform SNMP operations
on several hosts simultaneously.  SNMP::Multi builds on G. Marzot's
SNMP
Perl interface to the UC-Davis SNMP libraries, using asynchronous SNMP
operations to send queries/sets to multiple hosts simultaneously.
..
Results from all hosts are compiled into a single object, which
offers
methods to access the data in aggregate, or broken down by host or
the
individual request.
..
SNMP::Multi supports SNMP GET, SET, GETNEXT, GETBULK and
BULKWALK requests.
It also performs PDU packing in order to improve network
efficiency, when
packing is possible.
..
This description was automagically extracted from the
module by dh-make-perl.


The package is available at mentors.debian.net.
---

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (100, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-vserver-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8)


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