[no subject]

[5209071928]

Hot cock !

--
===
Brought to you by, Cingular Wireless Messaging
http://www.CingularMe.COM/


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

Re: How to maintain packaging files for multiple distributions in the same tree?

[Michael Spang]

Goswin von Brederlow wrote:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
>   
>> On Thu, 15 Feb 2007 19:00:03 +0100, Goswin von Brederlow
>> <[EMAIL PROTECTED]> said:  
>>
>> 
>>> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>>   
 On Thu, 15 Feb 2007 13:34:47 +0100, Goswin von Brederlow
 <[EMAIL PROTECTED]> said:

 Err, So I apply a change to say, branch--foo. The I go to
 branch--bar, and I say: tla replay branch--foo--revsion-x--patch-y;
 and the same change is applied.

 What if I had independently applied the same patch to both working
 trees? I would commit the identical change, and use tla sync-tree
 to let arch know the changes had been made in both branches, and
 any future merge should not try to redo the changes -- no matter
 which direction the future merge was done from.
 
>>> Which means manual work which you can easily forget or even mess up.
>>>   
>> Err, if I am applying the same patch on two different
>>  branches (which is a pretty weird thing to do, as far as I am
>>  concerned), running a sync tree comes pretty naturally. Sure, I can
>>  also forget to breathe, and the consequences are worse :)
>> 
>
> What I want to do is apply a patch to the common ancestry of a set of
> branches but have the RCS system check that it doesn't break any
> branch. Currently I have to apply the patch to one branch and then
> replay, merge, pull, whatever it across all the branches that have the
> same ancestry.
>
>   
 Of course, in arch, conflicting changes in different branches is
 often the very reason to have the branch in the first place, so it
 is not really helpful to have warning emitted all over the
 place. I'll still learn of the changes whenever I try to merge; in
 which case I'll notice, and apply a sync-tree later to not redo the
 same change twice, and move on.
 
>>> The reason I want branches is so I keep the seperate issues and
>>> their patches seperate. So changes to each issue remain managable.
>>>   
>> So why are you committing the same patch to both branches? I
>>  have never actually had to do this, so far.
>> 
>
> +---+
>/ \
> Ubuntu version   ++---+   +--+--
> //   /   |
> Debian version-++---+++--+--
> \\   \   |
> Multiarch version++---+   \  |
>\   \ |
> +---++--
>
>^ initial branch  ^ feature merge
>  ^ upstream update   ^ local fix for all branches 
>^ feature update
>
> Say you have the above branches to maintain your package. In
> particular I'm concerned with "local fix for all branches". You would
> edit one branch and then want to commit the change to all
> branches. Currently you have to apply the patch to each branch in cvs
> or replay, merge or pull it on other RCSes.
>
> There is no RCS that lets you edit the common source and tells you on
> commit if any branch would break.
>
>   
>>> The problem is that when you get to 40 or 50 branches that have
>>> common ancestors the required replays and merges on upstream updates
>>> become complicated and time consuming. Manually pushing changes from
>>> branch to branch just doesn't scale well.
>>>   
>> When I create feature branches, I generally don't go around
>>  pushing the same patch on to multiple branches at all. Most patches
>>  belong to one branch or the other.
>>
>> This is a hypothetical corner case that rarely happens, and
>>  even then, the problem only comes when merging two branches, when the
>>  presence of the same changes in tow different commits on either
>>  branch would show up. I'll just do a sync tree, and continue with the
>>  merge.  So a patch set  applied to two branches (and somehow missed
>>  when I create the integration branch)  would be caught when I did
>>  anything real with the branches.
>> 
>
> Again a "little" picture. This should be a 3 dimensional cube. Linux
> versions on one axis, Lustre versions on the other and the stacked
> patchs on the 3rd axis
>
> Lustre \ Linux  2.6.12   2.6.152.6.19   2.6.20
> 1.4.6 ++ ++
> 1.4.7 ++ ++
> 1.4.8 ++ ++
> 1.6.0 ++ ++
>
> Patch 1: add intents
> Lustre \ Linux  2.6.12   2.6.152.6.19   2.6.20
> 1.4.6 v1   v1v1-19v1-19
> 1.4.7 v1   v1v1-19v1-19
> 1.4.8 v2   v2-15 v2-19v2-20
> 1.6.0 v3   v3-15 v3-15v3-20
>
> Patch 2: add no-intents fixes
> Lustre 

Re: unwanted loading of libnss_nis.so in etch

[Mark Brown]

On Fri, Feb 16, 2007 at 10:52:10AM +1100, Brian May wrote:

> My understanding is that compat is mode to allow the +/- syntax which
> is considered obsolete these days...

Why do you say it is considered obsolete (beyond the whole "being NIS"
thing)?  It gives slightly more control than using the NSS module
directly.  It is also what is currently recommended by our NIS package.

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


signature.asc
Description: Digital signature

Re: recent etch upgrade... sashroot (uid=0) started to impersonate uid=0 (root)

[Gabor Gombas]

On Fri, Feb 16, 2007 at 10:45:53AM +1100, Brian May wrote:

> I suspect you will find it behaves in much the same way on all Unix
> like operating systems, unless caching is used or /etc/passwd has been
> replaced with a db file or database (do any OS do this by default?).

We've used nscd on Solaris 10 years (boy, was it that long?) ago and
observed the same feature. This is not something new.

> Unfortunately, like it or not, many people have seen it as a de-facto
> standard - if this is a defacto standard we want to preserve or not is
> another matter.

A couple hundred years ago the de-facto standard was that the Earth is
flat. Many people beleiving something does not make it true.

There are many interesting aspects and side-effects of large-scale user
databases that small systems simply do not see. That does not mean that
large systems should give up performance & flexibility just to mimic
systems with less than a hundred real users.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: unwanted loading of libnss_nis.so in etch

[Petter Reinholdtsen]

[Brian May]
> My understanding is that compat is mode to allow the +/- syntax which
> is considered obsolete these days...

We use NIS and the compat module here at the University of Oslo on
most of our 2000 unix machines, so I can assure you that it is in
active use and not obsolete at all. :)

If only LDAP had client side server failover like NIS.  It would make
it easier to switch to LDAP for us.  We would still need the compat
mechanism to control machine access.

Friendly,
-- 
Petter Reinholdtsen


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

Re: unwanted loading of libnss_nis.so in etch

[Gabor Gombas]

On Fri, Feb 16, 2007 at 09:42:20AM +, Mark Brown wrote:

> Why do you say it is considered obsolete (beyond the whole "being NIS"
> thing)? It gives slightly more control than using the NSS module
> directly.

Because it uses NIS even if you are not aware of it thus wasting memory
in _every_ running process, it is a little slower than "passwd files
nis", and because very few people need the extra flexibility the
plus-adressing provides.

> It is also what is currently recommended by our NIS package.

That may very well be a remnant from the early-libc6 times when
preserving compatibility with libc5 and other Unices lacking nsswitch
was important.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -

ITP: libauthen-simple-radius-perl -- Simple RADIUS authentication

[Xavier Oswald]

Package: wnpp
Severity: wishlist
Owner: Xavier Oswald <[EMAIL PROTECTED]>

* Package name: libauthen-simple-radius-perl
  Version : 0.1
  Upstream Author : Christian Hansen <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~chansen/Authen-Simple-RADIUS-0.1/
* License : GPL
  Description : Simple RADIUS authentication

This package allow to use RADIUS authentication methods.

It uses the libauthen-simple-perl framework.

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.8-powerpc
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

-- 
  ,''`.  Xavier Oswald <[EMAIL PROTECTED]>
 : :' :  GNU/LINUX Debian & Debian-Edu 
 `. `'   GnuPG Key ID 0x88BBB51E 
   `-938D D715 6915 8860 9679  4A0C A430 C6AA 88BB B51E


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

Re: Handling of (inactive) Debian Accounts

[gregor herrmann]

On Thu, 15 Feb 2007 23:22:08 -0500, Kevin Mark wrote:

> But Manoj says the 'maintainer ping' was tried and was
> not liked. So I guess some other method need to be found.

Just out of curiosity: What exactly was this "maintainer ping" and
why was it disliked?

gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian: the universal operating system - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: R.E.M.: Nightswimming


signature.asc
Description: Digital signature

Re: unwanted loading of libnss_nis.so in etch

[Gabor Gombas]

On Fri, Feb 16, 2007 at 11:54:59AM +0100, Petter Reinholdtsen wrote:

> If only LDAP had client side server failover like NIS.

In theory, it has, you can specify multiple server URIs in the config
file. In practice the OpenLDAP client libraries do not handle failover
very well (at least not in the past, things may have changed).

> It would make
> it easier to switch to LDAP for us.  We would still need the compat
> mechanism to control machine access.

Using the compat module for authorization decisions is a gross hack.
With NIS you don't have much choice but with a well-designed LDAP setup
you can nicely decouple the authorization decisions from user
identification.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: unwanted loading of libnss_nis.so in etch

[Petter Reinholdtsen]

[Gabor Gombas]
> In theory, it has, you can specify multiple server URIs in the
> config file. In practice the OpenLDAP client libraries do not handle
> failover very well (at least not in the past, things may have
> changed).

Nope, not even in theory.  Sequencial 3 minute timeout per server is
not client side failover.  It is just painful and useless. :)

> Using the compat module for authorization decisions is a gross hack.
> With NIS you don't have much choice but with a well-designed LDAP
> setup you can nicely decouple the authorization decisions from user
> identification.

Not with equally simple notation.  compat is here to stay. :)

Friendly,
-- 
Petter Reinholdtsen


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

Re: unwanted loading of libnss_nis.so in etch

[Mark Brown]

On Fri, Feb 16, 2007 at 12:08:59PM +0100, Gabor Gombas wrote:
> On Fri, Feb 16, 2007 at 09:42:20AM +, Mark Brown wrote:

> > Why do you say it is considered obsolete (beyond the whole "being NIS"
> > thing)? It gives slightly more control than using the NSS module
> > directly.

> Because it uses NIS even if you are not aware of it thus wasting memory
> in _every_ running process,

This is a reason why one might prefer files over compat, not a reason
why one would prefer compat over the NIS module.

> it is a little slower than "passwd files
> nis", and because very few people need the extra flexibility the
> plus-adressing provides.

I'd be interested to see if the difference there was actually
benchmarkable - it would surprise me if it were.  I'd expect it would be
more likely that the hit from loading the compat module over files were
noticable.

> > It is also what is currently recommended by our NIS package.

> That may very well be a remnant from the early-libc6 times when
> preserving compatibility with libc5 and other Unices lacking nsswitch
> was important.

It's not just a hangover from older libcs - the additional
functionality, the fact that it works with the default nsswitch.conf and
the compatiblity with other Unixes are more important factors.  This
means that random documention people find with Google is likely to work
and nobody familiar with the traditional way of doing things will be
surprised.

Given that it has benefits and I can't really see any substantial
negatives to compat I don't see changing it.

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


signature.asc
Description: Digital signature

Re: How to maintain packaging files for multiple distributions in the same tree?

[Manoj Srivastava]

On Fri, 16 Feb 2007 07:43:48 +0100, Goswin von Brederlow
<[EMAIL PROTECTED]> said:  

> What I want to do is apply a patch to the common ancestry of a set
> of branches but have the RCS system check that it doesn't break any
> branch. Currently I have to apply the patch to one branch and then
> replay, merge, pull, whatever it across all the branches that have
> the same ancestry.

OK. Your problem can be abstracted down to be the same on,
 topographically speaking, as the one of having a new upstream version
 come out, when you have a whole slew of branches, and have to apply
 the upstream change-set to every one of the branches you maintain.
 Your specific example can be mapped into this problem, which is,
 essentially, changes that have been applied to an ancestor branch
 needing to be propagated down every branch, and ensuring that there
 are no confilcts.

I have scripted this, so certainly this is easy to do with
 arch. In order for the script to make sense to you, you need to
 understand a little bit about my working setup. Here is my setup,
 which is a fairly common paradigm for me (I started doing this with
 cvs-buildpackage): 
,
|   $workdir_top/# contains all the packages
| $pkg/  # (has orig.tar.gz)
|   $pkg-$upstream_version/
|debian/
|  common/
|upstream/
|$pkg--upstream--$revision
|$pkg--feature-A--$revision
|$pkg--feature-B--$revision
|
|$pkg--feature-N--$revision
|$pkg--devo--$revision
`

The --devo-- branch is the integration branch, which contains
 all the features, and is used for building the binary.

Now, suppose there is a new upstream version. I update  the
 branch $pkg--upstream--$revision using tla_load_dir, but now I have N
 feature branches, and the integration branch, to take care of.

Voila. I 'cd $workdir_top/$pkg/upstream', and run the
 following script. This script then:
  a) Applies the missing changes in the upstream branch to the
 integration branch. This is where I get to know if there is going
 to be any conflicts in the feature branches. Most of my packages,
 most of the time, require no manual intervention. Really. If
 there is any manual intervention needed, then, for all conflicts:
i) I inspect the conflict, determine which feature branch would
   be affected; 
   ii) fix the conflict in this throw away integration branch
   copy, and satisfy myself the resolution is OK
  iii) make the same changes to the affected feature branch. 
   iv) Commit changes to the feature branch
v) Undo upstream changes to the integration branch, and pull the
   changes made to the feature branch. At this point, if we
   were to re-try merging the upstream, then this conflict
   would be gone.
At this point, I can just re-run the script from the top, and
there will be no conflicts, since all conflicts have been fixed.
  b) Applies the missing changes in the upstream branch to all the
 feature branches, 1..N. 
  c) It commits the new revision of the feature branch
  d) It does a sync tree in the integration branch, so future merges
 are  gonna be fine.
  e) Finally, it commits the changes in the development branch.


So, for the setup you have with upstream, debian, and ubuntu,
 you can generate a very similar shell script  to apply common
 changes to ancestor branches -- and even generalize it more than I
 have needed to.

I really like the scriptability of arch :)

manoj

#!/bin/zsh
#   -*- Mode: Sh -*- 
# upgrade.sh --- 
# Author   : Manoj Srivastava ( [EMAIL PROTECTED] ) 
# Created On   : Thu Aug 11 13:55:22 2005
# Created On Node  : glaurung.internal.golden-gryphon.com
# Last Modified By : Manoj Srivastava
# Last Modified On : Wed Sep 20 11:49:41 2006 (-18000 CDT)
# Last Machine Used: glaurung.internal.golden-gryphon.com
# Update Count : 17
# Status   : Unknown, Use with caution!
# HISTORY  : 
# Description  : 
# 
# arch-tag: 25520dc3-7d73-4b47-ab69-77483e2749d2
# 
progname="`basename \"$0\"`"
set -e

workdir_top=/usr/local/src/arch/packages--debian
curdir=$(pwd)
pkg=$(pwd | sed -e 's,^/usr/local/src/arch/packages--debian/,,' -e 's,/.*$,,')
TLA=baz # uses baz status, so do not change

withecho () {
echo " $@" >&2
"$@"
}
action='withecho'
#action='echo'

usageversion () {
cat >&2 <
Options: 
  -h   print this message
  -n   "Dry-run" mode - No action taken, only print commands.
  -v   Make the command verbose

END
}

# parse Command line
# Note that we use `"$@"' to let each command-line parameter expand to a 
# separate word. The quotes around `$@' 

Re: Handling of (inactive) Debian Accounts

[Manoj Srivastava]

Hi,
On Fri, 16 Feb 2007 14:10:44 +0100, gregor herrmann <[EMAIL PROTECTED]> said: 

> On Thu, 15 Feb 2007 23:22:08 -0500, Kevin Mark wrote:
>> But Manoj says the 'maintainer ping' was tried and was not
>> liked. So I guess some other method need to be found.

> Just out of curiosity: What exactly was this "maintainer ping" and
> why was it disliked?

  http://comments.gmane.org/gmane.linux.debian.devel.announce/231
  http://www.debian.org/News/weekly/2003/20/

manoj
-- 
party, n.: A gathering where you meet people who drink so much you
can't even remember their names.
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]

Key expiry breaks most D-I Etch RC1 images - update

[Frans Pop]

On Sunday 11 February 2007 21:59, Frans Pop wrote:
> The expiration of the Debian archive's signing key for 2006 has broken
> most of the installation media from etch RC1.

This effectively left us without useable full CD and DVD images as the 
weekly builds were affected as well.
After some deliberation, we have decided to change the weekly builds to 
use daily installer images and udebs from unstable, basically the same as 
is done for daily builds.

This means that full CD and DVD images are now available again from [1], 
for all architectures (except S/390). The now available images are 
virtually identical to what will be released as D-I RC2, so testing and 
installation reports [2] are most welcome. 

Thanks to Steve McIntyre for making the needed changes in the debian-cd 
setup.

[1] http://www.debian.org/devel/debian-installer/
[2] http://d-i.alioth.debian.org/manual/en.i386/ch05s03.html#submit-bug


pgp1X4xCb31ju.pgp
Description: PGP signature

Bug#411167: ITP: splix -- Splix - SPL2/SPLc Samsung Printer Driver for CUPS

[Carlos Pasqualini]

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


* Package name: splix
  Version : 1.0.1-1
  Upstream Author : Aurélien Croc <[EMAIL PROTECTED]>
* URL : http://splix.ap2c.org/
* License : GPLv2
  Programming Lang: C
  Description : Splix - SPL2/SPLc Samsung Printer Driver for CUPS

   SpliX is a set of CUPS printer drivers for SPL (Samsung Printer Language) 
printers. If you have a such printer, 
you need to install and use SpliX. Moreover you will find documentation about 
this proprietary language on the splix 
website at http://splix.ap2c.org/.

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=es_AR, LC_CTYPE=es_AR (charmap=ISO-8859-1)


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

Bug#411174: ITP: remake -- GNU make fork with improved error reporting and debugging

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko <[EMAIL PROTECTED]>

* Package name: remake
  Version : 3.80+dbg0.61
  Upstream Author : Rocky Bernstein <[EMAIL PROTECTED]>
* URL : http://bashdb.sourceforge.net/remake/
* License : GPL
  Programming Lang: C
  Description : GNU make fork with improved error reporting and debugging

 Modernized version of GNU make utility that adds improved error
 reporting, the ability to trace execution in a comprehensible way, and a
 debugger. Some of the features of the debugger are:
  * see the target call stack
  * set breakpoints on targets
  * show and set variables
  * execute arbitrary "make" code
  * issue shell commands while stopped in the middle of execution
  * inspect target descriptions
  * write a file with the commands of the target expanded
 .
  Homepage: http://bashdb.sourceforge.net/remake/

-- System Information:
Debian Release: 4.0
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-amd64-generic
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik


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

Re: unwanted loading of libnss_nis.so in etch

[Gabor Gombas]

On Fri, Feb 16, 2007 at 02:30:48PM +, Mark Brown wrote:

> This is a reason why one might prefer files over compat, not a reason
> why one would prefer compat over the NIS module.

If you're using NIS but do not explicitely require plus addressing then
the compat module is still a completely unneeded module loaded
dynamically (DSO loading is not free) and cca. 20k of extra code being
used during NSS calls (icache is also not free).

> Given that it has benefits and I can't really see any substantial
> negatives to compat I don't see changing it.

It's your choice. For me deleting compat from /etc/nsswitch.conf is one
of the routine configuration steps after a fresh install.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: unwanted loading of libnss_nis.so in etch

[Brian May]

> "Petter" == Petter Reinholdtsen <[EMAIL PROTECTED]> writes:

Petter> Nope, not even in theory.  Sequencial 3 minute timeout per server is
Petter> not client side failover.  It is just painful and useless. :)

Can't you change the timeout? According to the comment in my
libnss-ldap you can:

# Your LDAP server. Must be resolvable without using LDAP.
# Multiple hosts may be specified, each separated by a 
# space. How long nss_ldap takes to failover depends on
# whether your LDAP client library supports configurable
# network or connect timeouts (see bind_timelimit).
-- 
Brian May <[EMAIL PROTECTED]>


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

GNOME and usability.

[Greg Folkert]

Seems I am not the only one that believes GNOME is limiting.

Linus Torvalds has submitted patches. I am betting they get ignored or
rejected with "to complex for our idiot users".

Yes, Joss could you please explain this away for me?
-- 
[EMAIL PROTECTED]

Novell's Directory Services is a competitive product to Microsoft's
Active Directory in much the same way that the Saturn V is a competitive
product to those dinky little model rockets that kids light off down at
the playfield. -- Thane Walkup


signature.asc
Description: This is a digitally signed message part

Bug#411209: ITP: libwiimote -- Simple Wiimote Library for Linux

[Kobayashi Noritada]

Package: wnpp
Severity: wishlist
Owner: Kobayashi Noritada <[EMAIL PROTECTED]>

* Package name: libwiimote
  Version : 0.3
  Upstream Author : Joel Andersson 
Chad Phillips 
* URL : http://sourceforge.net/projects/libwiimote/
* License : GPL
  Description : Simple Wiimote Library for Linux

Libwiimote is a simple C library for communicating with the Nintendo Wii
Remote on a Linux system. Even though the API strives to be minimal, it
provides complete control over most features of the wiimote and nunchuk
controllers.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-3-686
Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP (charmap=EUC-JP)


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

Re: Handling of (inactive) Debian Accounts

[Kevin Mark]

On Fri, Feb 16, 2007 at 11:41:23AM -0600, Manoj Srivastava wrote:
> Hi,
> On Fri, 16 Feb 2007 14:10:44 +0100, gregor herrmann <[EMAIL PROTECTED]> said: 
> 
> > On Thu, 15 Feb 2007 23:22:08 -0500, Kevin Mark wrote:
> >> But Manoj says the 'maintainer ping' was tried and was not
> >> liked. So I guess some other method need to be found.
> 
> > Just out of curiosity: What exactly was this "maintainer ping" and
> > why was it disliked?
> 
>   http://comments.gmane.org/gmane.linux.debian.devel.announce/231
>   http://www.debian.org/News/weekly/2003/20/
> 
I read the above links and found nothing to indicate anything but praise
for the effort, updating about inaccurate MIA status and forwarding of
email to another possible address. I used the 'the google' too and it
showed nothing additional based upon my search terms. Could someone
point to an instance or give a hint about this. TIA.
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal |mysite.verizon.net/kevin.mark/|
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
|   my keysever: subkeys.pgp.net | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Seeking for Adrian Bridgett

[Christian Perrier]

I'm having trouble contacting Adrian Bridgett:


<[EMAIL PROTECTED]>: host master.debian.org[70.103.162.29] said: 550 user
account locked (in reply to RCPT TO command)



Would anyone know about an alternate emila address for him?

Apart from this, what does that "locked" account mean, on master?




signature.asc
Description: Digital signature