edit patches in dpkg configuration file dialog

[Nico Golde]

Hi,
what about the following idea.
If a configuration file is marked as conffile in a package 
you have the possibility to select between:

- Install the new version of the configuration file from the 
  package
- Keep your current installed version of the file
- View the differences

This is imho pretty suboptimal because even if you see the 
differences between the files and install a new version or 
keep the old version you always have the problem that you 
might miss new configuration flags or you have to adapt the 
new file manually from your old backup and "merge" the 
changes.

What about the possibility to view the patch, edit it with 
your favorite editor and the just apply the patch?
This way you don't have to do all the manual stuff after 
installing the packages and you don't miss new configuration 
flags.

Are there already people who started to do something 
similar? Do you think this is useful?

The problem is obvious, you can't just edit a patch in an 
editor if you want it to apply cleanly after editing it.
The patchutils package has the editpatch tool to edit 
patches and it basically opens an editor and calls rediff 
afterwards to fix the broken ranges of the diff.
I guess it would be a bad idea to depend on patchutils in 
dpkg so that would be ~1000 LOC C extra for rediff in dpkg.

What do you think?

Kind regards
Nico

-- 
Nico Golde - http://www.ngolde.de
JAB: [EMAIL PROTECTED] - GPG: 0x73647CFF
Forget about that mouse with 3/4/5 buttons,
gimme a keyboard with 103/104/105 keys!


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

Re: On maintainers not responding to bugs

[Robert Collins]

On Fri, 2007-03-02 at 18:57 +0100, Pierre Habouzit wrote:
> but I would
> obviously lessen my implication and work for other teams where I've a
> single damn chance to see my contribution to be compareable to the
> others. 

Better a big fish in a small pond than a small fish in a big pond huh?

So much for the idea of team work.

-Sigh
-- 
GPG key available at: .


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

Re: On maintainers not responding to bugs

[Pierre Habouzit]

On Sat, Mar 03, 2007 at 09:03:40PM +1100, Robert Collins wrote:
> On Fri, 2007-03-02 at 18:57 +0100, Pierre Habouzit wrote:
> > but I would
> > obviously lessen my implication and work for other teams where I've a
> > single damn chance to see my contribution to be compareable to the
> > others. 
> 
> Better a big fish in a small pond than a small fish in a big pond huh?
> 
> So much for the idea of team work.


  You misread me. Better a fish of the same size of the other in a team
as large as you want, than a ridiculous small fish aside a gigantic one.


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp3Y6aIlPEdL.pgp
Description: PGP signature

Re: edit patches in dpkg configuration file dialog

[gregor herrmann]

On Sat, 03 Mar 2007 09:33:30 +0100, Nico Golde wrote:

> you always have the problem that you 
> might miss new configuration flags or you have to adapt the 
> new file manually from your old backup and "merge" the 
> changes.

Ack, that's annoying IMO.
 
> What about the possibility to view the patch, edit it with 
> your favorite editor and the just apply the patch?
> This way you don't have to do all the manual stuff after 
> installing the packages and you don't miss new configuration 
> flags.

Sounds great.
 
> Are there already people who started to do something 
> similar? Do you think this is useful?

IMO this feature would be very useful.
 
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: Dire Straits: Brothers In Arms


signature.asc
Description: Digital signature

Re: On maintainers not responding to bugs

[Theodore Tso]

On Fri, Mar 02, 2007 at 06:57:01PM +0100, Pierre Habouzit wrote:
>   You forgot a single damn point: in debian, like in many projects, the
> one that "do" things is often the guy that "decide" things because he's
> the one there. If you put people that work 5 times more as me because
> they have the time to do that, I will obviously feel they took my
> place. I'm not sure what I would do in those cases. Obviously not
> refusing the help and people that have the time to do this, but I would
> obviously lessen my implication and work for other teams where I've a
> single damn chance to see my contribution to be compareable to the
> others.

The principle you stated obviously tends to be the case in volunteer
organizations, true.  It does not have to be the case of a paid
employee, but yes, even if the maintainer team sets the general policy
and gives direction to the employee, there will be a lot of
hour-to-hour operational control which you will be ceding to the
employee (unless you want to be one of those awful micro-managing
managers --- but that's not a path to productivity, either for the
manager or the managee!  :-)

>   I would feel bad to impose my views to a person that has huges amounts
> of time to work in the team. And necessarily (because of human nature)
> a decision will happen that I would not like or would have made
> differently, and at that point I guess that I would just leave.

Well, anytime we have people working on a package with team
maintenance, there are bound to be disagreements.  If we all left the
moment a decision was made that we didn't agree with, Debian would be
empty.  

I can't read your mind, of course, but it may be that the harder
psychological hurdle is the one where a DD realizes that (say) 10
hours a week of volunteer labor is no longer enough to be one of the
primary contributors on a package team.  That is a real issue, and
perhaps maybe _the_ major issue.

>   Whereas in balanced teams where every contributor has the same level
> of contribution, I would have argued my point, or tried to make the
> proposal better, or discussed it or... whichever adequate behaviour in a
> team where every single member is equal to the other.

Although this may be a great platonic ideal, the reality is that no
team is going to be completely balanced.  First of all, not everyone
does _can_ contribute at the same level.  Some people have jobs that
cause them to work very long hours, for example.  (And of these, some
of them would like to be able to help Debian, and one of the ways they
might be willing and able do so is via contributing money, not time.)   

Secondly, even if assume that everyone could give the same number of
hours of contribution, the reality is that different people have
different levels of talent --- and it is still the case in the
programming world that differences in talent can account for 2+ orders
of magnitude in productivity.  So in the end, talent will probably
still dominate far more than whether someone can work 10 hours as a
volunteer versus 40 hours as a paid employee.  (This I think is one of
the ways that an examples of paid versus volunteer firemen may not be
applicable for Debian.)

>   Money introduces bias. OK you were talking about bug triaging, and bug
> triaging is not necessarily a big decision making place, I agree. Though
> it will depend a lot of the kind of people you want to recruit:
>   * if those are already contributors they will want to take more and
> more decisions, and won't only do bug triaging: if you do bug
> triaging you begin to know packages a lot, and become skilled
> enough to take decisions, and so on. Then commits rights are
> granted, and you take more and more responsibilities. That's good,
> it's indeed what is often suggested to newcomers. Though we end up
> in the not-so-nice situation I described.

Money introduces bias; no question.  But it also does introduce a
certain amount of control.  For example, suppose we only paid people
to do bug triaging.  If they want to do more, that's great but it will
be on their own time.  Would something like this magically make all of
the problems go away?  Of course not, but I think it shows that with
the right amount of thoughtfulness, it's possible to make the benefits
outweight the costs.  

>   but please, I'm not sure there is a damn single maintainer in a big
> team that will refuse help, paid or not. I don't really understand how
> that mythical maintainer in a big team that refuses help has emerged in
> the discussions, but I'd really like names here. In fact, that seems
> pretty contradictory with the very notion of a team. Of course, there is
> teams with 1 single member in it in debian, but that's not a "large
> team" and is out of the scope if I'm not mistaken.

Well, Josselin has been very negative about the whole concept of
paying volunteers, and given that he was asking for help, and saying
that his GNOME team was drowning under bug reports, I

Bug#413240: ITP: sshfp -- DNS SSHFP records generator

[Julien Valroff]

Package: wnpp
Severity: wishlist
Owner: Julien Valroff <[EMAIL PROTECTED]>

* Package name : sshfp
  Version  : 1.1.1
  Upstream Authors : Paul Wouters <[EMAIL PROTECTED]> and Jake Appelbaum 
<[EMAIL PROTECTED]>
* URL  : http://www.xelerance.com/software/sshfp/
* License  : GPL
  Programming Lang : Python
  Description  : DNS SSHFP records generator

sshfp generates RFC4255 SSHFP DNS records based on the public keys stored in
a known_hosts file, or public keys can be obtained by using ssh-keyscan.
Serve these entries from the DNS server for your domain to provide
authentication via the ssh VerifyHostKeyDNS option.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)



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

Re: On maintainers not responding to bugs

[Josselin Mouette]

Le samedi 03 mars 2007 à 10:45 -0500, Theodore Tso a écrit :
> Well, Josselin has been very negative about the whole concept of
> paying volunteers, and given that he was asking for help, and saying
> that his GNOME team was drowning under bug reports, I couldn't help
> but reply that if he really was serious about wanting help, would it
> extend to accepting paid help  since many people have asserted
> that they would leave the project if some of the contributors to
> debian were paid, in effect trying to hold the project hostage against
> paying developers.  Part of the reason why I suspect they are doing
> this is specifically because of some of the fears which you outlined
> above, and which I acknowledge are real ones and ones which are
> legitimate.

You are again biasing the discussion by trying to make your dunc-tank
paid developers look like paid developers we already have.

If some company wishes to see GNOME in Debian work better and starts
paying someone to do packaging and bug-triaging work on the GNOME
packages, he will be welcome. This may lead to other members of the team
doing less, but the overall quality of the packages would improve.

Oh, and this already happens with volunteer members. When someone has
more time and does plenty of uploads, you can magically see
contributions from other members decrease.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: On maintainers not responding to bugs

[Manoj Srivastava]

On Sat, 3 Mar 2007 10:45:47 -0500, Theodore Tso <[EMAIL PROTECTED]> said: 

> The principle you stated obviously tends to be the case in volunteer
> organizations, true.  It does not have to be the case of a paid
> employee, but yes, even if the maintainer team sets the general
> policy and gives direction to the employee, there will be a lot of
> hour-to-hour operational control which you will be ceding to the
> employee (unless you want to be one of those awful micro-managing
> managers --- but that's not a path to productivity, either for the
> manager or the managee!  :-)

> I can't read your mind, of course, but it may be that the harder
> psychological hurdle is the one where a DD realizes that (say) 10
> hours a week of volunteer labor is no longer enough to be one of the
> primary contributors on a package team.  That is a real issue, and
> perhaps maybe _the_ major issue.

Volunteers volunteer because of non-monetary rewards they gain
 from contributing. And merely improved quality of packages does not
 explain spending the time giving away ones labour for no mopnetary
 remuneration when you could be working on paid basis to get the money
 for eating out at a fancy restautrant or buying the new guitar.

Volunteers take part in activity that is fun, accomplishing
 tasks that  give one a feeling of accomplishment, and, to a large
 extent, respect from their peers for the work they do.

If a paid employee does the lions share of the work, and thus
 makes the decisions, garners (rightly) the kudos for the work done,
 then the volunteer might have lost all the incentives they had to do
 the activity in the first place.

In order to get the fun (decisions, design, crafting a well
 made piece of work), and recognition, it is not unreasonable to
 expect the volunteer to find other areas where they can still get the
 rewards and satisfaction they sought in their volunteer work in the
 first place.

So it seems to me that there would be a significant motion of
 volunteers to paid employees. And then, or course, all the underlying
 forces that govern a company with paid employees would be in play in
 Debian.

Perhaps such a transition is what is best for  someone, I
 suppose.  But I definitely do not look at these influences with
 equanimity.

manoj
-- 
A good awakening have ever Gotama's disciples, whose recollection is
always established, day and night on the body. 299
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: On maintainers not responding to bugs

[Roberto C. Sanchez]

On Sat, Mar 03, 2007 at 10:16:17AM -0600, Manoj Srivastava wrote:
> 
> Volunteers volunteer because of non-monetary rewards they gain
>  from contributing.

Really?  I volunteer (in addition to the altruistic reasons) because I
want to learn more about Linux and Debian, which makes me a better
consultant to people and also improves future job prospects.  Those two
things are decidedly monetary gains.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: On maintainers not responding to bugs

[cobaco (aka Bart Cornelis)]

On Saturday 03 March 2007, Theodore Tso wrote:
> So I understand where people are coming from when they say that they
> want Debian to remain 100% fully volunteer.  But first of all, that
> isn't even true even now; HP is funding some DD's to work mostly on
> Debian-related projects, and certainly some DD's are being paid by
> Cannonical, for example.  But secondly and more importantly, there
> people withour community that have aspirations to be better than what
> we can currently offer to our users now, and this includes responding
> to bug reports in a timely fashion, and for some people at least,
> getting releases out on time and with stable not being quite so
> embarassingly out-of-date for quite as long before we can get the next
> release of stable out.

There's a humongous difference between Debian paying people to work on 
Debian and 3rd parties like HP paying people to Debian. 

In particular having Debian paying for labor, moves the decision of who gets 
payed to work on what into Debian. Doing so brings with it a whole new 
level of politics.

I think we should be very, very carefull before we change the equation that 
way. 

-> There's a difference between saying that Debian should remain 100%
   volunteer, and sayin Debian should not become an employer.
-- 
Cheers, cobaco (aka Bart Cornelis)


pgpyrwRlmfZhu.pgp
Description: PGP signature

Re: On maintainers not responding to bugs

[David Nusinow]

On Sat, Mar 03, 2007 at 11:26:51AM -0500, Roberto C. Sanchez wrote:
> On Sat, Mar 03, 2007 at 10:16:17AM -0600, Manoj Srivastava wrote:
> > 
> > Volunteers volunteer because of non-monetary rewards they gain
> >  from contributing.
> 
> Really?  I volunteer (in addition to the altruistic reasons) because I
> want to learn more about Linux and Debian, which makes me a better
> consultant to people and also improves future job prospects.  Those two
> things are decidedly monetary gains.

If you're volunteering on a project and someone with more time does all the
work that involves learning, you don't end up learning much because you
don't end up solving much.

On the other hand, if your job involves so much of the same work over and
over again, you don't get to learn new things either. I've spent the last
year and a half (two years? I've lost count) trying to learn more about X,
but I've spent most of my time just doing packaging because it takes so
much time. I can't say I've been able to learn much and improve my skills
though.

 - David Nusinow


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

Re: On maintainers not responding to bugs

[Roberto C. Sanchez]

On Sat, Mar 03, 2007 at 11:50:56AM -0500, David Nusinow wrote:
> 
> If you're volunteering on a project and someone with more time does all the
> work that involves learning, you don't end up learning much because you
> don't end up solving much.
> 
> On the other hand, if your job involves so much of the same work over and
> over again, you don't get to learn new things either. I've spent the last
> year and a half (two years? I've lost count) trying to learn more about X,
> but I've spent most of my time just doing packaging because it takes so
> much time. I can't say I've been able to learn much and improve my skills
> though.
> 
Good and valid points.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: On maintainers not responding to bugs

[Manoj Srivastava]

On Sat, 3 Mar 2007 11:26:51 -0500, Roberto C Sanchez
<[EMAIL PROTECTED]> said:  

> On Sat, Mar 03, 2007 at 10:16:17AM -0600, Manoj Srivastava wrote:
>> 
>> Volunteers volunteer because of non-monetary rewards they gain from
>> contributing.

I should have known better to not guard against nit picking.
 Let me put it this way: if one volunteers to do some work for
 $REWARD, where $REWARD != money, and if one does not have tie to
 spend on it as one would for a full time job, then the situation
 *MAY* arise that the paid employee, with more time, and focus, has
 done the taks before you get a round tuit.

That means $REWARD does not come to you.

Let me now address the specific case you raise:

> Really?  I volunteer (in addition to the altruistic reasons) because
> I want to learn more about Linux and Debian, which makes me a better
> consultant to people and also improves future job prospects.  Those
> two things are decidedly monetary gains.

So, when you find that you are not learning much because the
 paid employee has tackled everything on your plate to do to learn
 things while you were struggling with item number 1, and does
 anything quicker than you do, because, well, they have more time, and
 are learning faster than you because they do the work and, you know,
 practice helps.  You are relegated to reading other people's code,
 with is not the best way to learn.

You'll be learning faster, making mistakes and learning from
 them, were you to go into an area where no one just steps in and does
 your work for you.

manoj
 who, since Ted is involved in this thread, is not gonna post more
 than twice in a 24 hour period. With this mail, my quota is up for
 the day.
-- 
Happiness isn't having what you want, it's wanting what you have.
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: [EMAIL PROTECTED]: /usr/sbin/sshd: wrong DISPLAY is due to hijacking someone other's one...]

[Yaroslav Halchenko]

Hi Ben,

Thank you for the help. FWIW, I confirm that it indeed fixes an issue on
my box.

1.

unfortunately it probably implies that I was wrong in my estimate of
connection of this issue to original old #152250. It was reported
on 1:3.4p1-0.0woody1, which came out on 26 Jun 2002 whenever the patch
you've mention is from Oct 2002... Heh - now I need to go to snapshots
to verify if that line wasn't there in debian's release.. I wish we had
CVS for all the projects ;-)

hm - got
459c1d0262e939d6432f193c7a4ba8a8  openssh_3.4p1.orig.tar.gz
and that one has already that condition in:
and Changelog states release of 20020626

so I don't get it... may be there was some custom patch to
openssh_3.4p1.orig.tar.gz from debian? (not in diff.gz?) which later on
was applied upstream in 1.183

so where am I wrong or am I right?

2.

ok - looking sober look at the list of occupied ports now I see why the
heck it happened at the first place here.

VNC occupied localhost:6013 but left ip6-localhost:6013 free. There was
one other VNC running on port 10 (so the one which could interfere with
sshd), BUT there was already one victim who ran ssh with forwarded X,
but probably never used any X app to discover that he can't ;-) :

,---
| sshd 4566   kuzey8u  IPv6 121986047   TCP ip6-localhost:6010 
(LISTEN)
| Xvnc4   11957bart0u  IPv4 110812220   TCP *:6010 (LISTEN)
`---

and the next VNC was on :13, so whenever less salient user hit a but,
she reported it to me, so I became investigating the issue. 

Meanwhile I was running main sshd with -4, so all new connections occupy
only localhost:60XX, while old ones go for both {ip6-,}localhost:

,---
| sshd27484 yoh8u  IPv4 125284718   TCP localhost:6020 (LISTEN)
| sshd27484 yoh9u  IPv6 125284719   TCP ip6-localhost:6020 
(LISTEN)
| sshd21917 arielle8u  IPv4 127502258   TCP localhost:6021 (LISTEN)
`---

without the problems-giving break, sshd allowed to ipv6 also occupies
both (reporting FWIW)

,--
| $> sudo lsof -i :6024
| COMMAND PID USER   FD   TYPEDEVICE SIZE NODE NAME
| sshd441  yoh8u  IPv4 127627340   TCP localhost:6024 (LISTEN)
| sshd441  yoh9u  IPv6 127627341   TCP ip6-localhost:6024 (LISTEN)
`---


On Fri, 02 Mar 2007, Ben Hutchings wrote:

> On Thu, 2007-03-01 at 17:44 -0500, Yaroslav Halchenko wrote:
> 
> > | if (ai->ai_next)
> > | continue;
> 

> I believe these two lines are the source of the bug.  Here's the change
> that introduced it:
> http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c#rev1.183

> The commit message cites:
> http://mail-index.netbsd.org/current-users/2002/09/16/0005.html
> which says that binding to the wildcard IPv6 address fails if no
> interfaces have IPv6 addresses assigned.  I think that's a BSD kernel
> bug that we don't need to pander to (and has probably been fixed in the
> mean time).

> Ben.
-- 
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]

[RFR] po-debconf://amavisd-new (6 strings)

[cobaco (aka Bart Cornelis)]

-- 
Cheers, cobaco (aka Bart Cornelis)


amavisd-new_1:2.4.2-6.1_nl.po
Description: application/gettext


pgppErUFqy9Yf.pgp
Description: PGP signature

[RFR] po-debconf://boinc (3 strings)

[cobaco (aka Bart Cornelis)]

-- 
Cheers, cobaco (aka Bart Cornelis)


boinc_5.4.11-4_nl.po
Description: application/gettext


pgp3qHNCj8kw9.pgp
Description: PGP signature

Re: [RFR] po-debconf://amavisd-new (6 strings)

[cobaco (aka Bart Cornelis)]

oops, wrong list should've gone to debian-l10n-dutch

-- 
Cheers, cobaco (aka Bart Cornelis)


pgpsfu7t4U5Pj.pgp
Description: PGP signature

Debian French localisation team completes the translation of debconf screens

[Christian Perrier]

(crossposted to several mailing lists. Please respect the Reply-To field)

As of March 3rd 2007, all packages in Debian unstable that have
translatable debconf templates are translated into French [1].

This is the result of a continuous effort in the last years and
particularly the last 4.5 years, since the upload of po-debconf back
in September 2002 by Denis Barbier which enabled translators to use
gettext to handle debconf translations.

This achievement, combined with the translation of the Debian
Installer, is the guarantee that even a complete installation of a
Debian system with all possible packages, when run in French, will
only show French-speaking prompts to the user.

That effort is also ongoing for several other languages [2], thanks to
the commitment of the numerous contributors from the Debian
internationalisation community [3].

All thanks and credits for the achievement of the French localisation
are due to the French translators [5] as well as all Debian package
maintainers who have regularly fixed the dozens of bug reports sent
by translators over the years.

A last effort will now target the 100% mark for packages in
testing. The current status, as of [4], is 99.2%.

Links:
[1] http://www.debian.org/intl/l10n/po-debconf/fr
[2] http://www.debian.org/intl/l10n/po-debconf/rank
[3] http://lists.debian.org/debian-i18n/
[4] http://alioth.debian.org/~thuriaux-guest/tmp/testing.stats
[5] Contributors of the French translations:

Adam Cécile (Le_Vert) 
Alexis Sukrieh  
Aurelien Jarno  
Aurelien Ricard  
BUIRA Etienne  
Cédric Favry  
Christian Perrier 
Christophe lincoln  
Christophe Masson  
Clément Stenac  
Cyril Brulebois 
Cyril Martin 
Daniel Déchelotte  
DELACOUR Guillaume  
Denis Barbier  
Emmanuel le Chevoir 
Eric Madesclair 
Florentin Duneau  
Florent Usseil  
Frédéric Bothamy  
Frédéric Schütz  
Frédéric Zulian  
Gabriel Laurent  
Gaetan CRAHAY  
Gregory Colpart  
Guilhelm Panaget  
Guillaume Nault  
Ivan Buresi  
Jean-Baka Domelevo-Entfellner  
Jean-Christophe Champarnaud  
Jean-Christophe Dubacq  
Jean-Luc Coulon  
Jean-Marc Chaton  
Jérémie Corbier  
Jose Luis Tallon 
Julien Louis  
Julien Rosal  
Julien Valroff  
Laszlo   
Laurence Colombet  
Laurent Pelecq  
Le Mignant pierre 
Ludovic Drolez  
Ludovic Rousseau  
Marco Presi  
Martin Quinson  
Michel Grentzinger  
Mohammed Adnène Trojette 
Nicolas Bertolissio  
Olivier Gauwin  
Olivier Trichet  
Philippe Batailler  
Pierre Machard  
Rémi Pannequin  
Séverine lombardo  
Simon Paillard  
Steve Langasek  
Steve Petruzzello  
Sylvain Archenault  
Sylvain LE GALL 
Thomas Capacci  
Thomas Huriaux  
Thomas Morin  
Thomas Viehmann  
Valéry Perrin  
Xavier Luthi  
Yannick Roehlly  
Yves Rütschlé  

Special credit to Steve Langasek who corrected this announcement

-- 




signature.asc
Description: Digital signature

Re: hijacking imagemagick

[Daniel Baumann]

Luciano Bello wrote:
> The maintainer of imagemagick, Ryuichi Arafune <[EMAIL PROTECTED]>, 
> didn't answer any ping [1]. So, I will hijack this package. I will comaintain 
> [2] it with Daniel Kobras <[EMAIL PROTECTED]>. A new upload is coming.

great, thanks you too for taking care.

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


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

Bug#413286: ITP: mppenc -- Musepack lossy audio codec encoder

[Jorge Salamero Sanz]

Package: wnpp
Severity: wishlist
Owner: Jorge Salamero Sanz <[EMAIL PROTECTED]>


* Package name: mppenc
  Version : 1.16
  Upstream Author : Musepack Development Team
* URL : http://www.musepack.net/
* License : LGPL
  Programming Lang: C
  Description : Musepack lossy audio codec encoder

 Musepack is a lossy audio codec specifically optimized for transparent
 compression of stereo audio at bitrates of 160-180 kbit/s.
 .
 This package contains the encoder, for decoding see libmpcdec3.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-powerpc
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#413289: ITP: mcs -- abstraction library and tools for the storage of configuration settings

[Le_Vert]

Package: wnpp
Severity: wishlist
Owner: "Adam Cécile (Le_Vert)" <[EMAIL PROTECTED]>

* Package name: mcs
  Version : 0.4.1
  Upstream Author : William Pitcock <[EMAIL PROTECTED]>
* URL : http://sacredspiral.co.uk/~nenolod/mcs/
* License : BSD
  Description : abstraction library and tools for the storage of 
configuration settings

mcs is a library and set of userland tools which abstract the storage of
configuration settings away from userland applications.
.
Is is licenced under the BSD licence, to help people to adopt it.
.
Highlights :
  * Cleanly implemented BSD-licenced code.
  * Simple, elegant, non-intrusive programming interface.
  * Modular design allows for third-party configuration backends to be
implemented without any extra effort on the part of the development
process of your products.
  * Dummy configuration backend which pretends that the configuration is
blank.
  * Many other features planned, such as configuration profiles.
  * Robust object-oriented design implemented as low-footprint C, mcs only
adds a ~20KB memory footprint to your application.
  * Full XDG BASEDIR spec compliance.
  * GConf support for free, with KDE settings support available in 0.4 or
later.
  * It's fast.
.
 Homepage: http://sacredspiral.co.uk/~nenolod/mcs/

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (900, 'testing'), (400, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.18-3-amd64
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)