Re: Google Summer of Code 2008

[Anthony Towns]

On Wed, Feb 27, 2008 at 01:53:17PM +, Jon Dowland wrote:
> On Wed, Feb 27, 2008 at 09:42:17AM +0100, Lucas Nussbaum
> wrote:
> > (1) Forbid DDs and people in the NM process waiting for
> > FD/DAM to apply as students.
> What if we do this, and still do not get many new people
> applying? How about a policy of prioritising
> non-DD/NM/DM/whatever contributions, rather than outright
> forbidding established people?

Uh, applicants who're already familiar with the project (both Debian
and the specific GSoC project they're applying for) have a much better
chance of success; applicants who are already DDs have a much easier
time actually contributing than people who aren't. Hamstringing ourselves
and our applicants by discouraging prior involvement is crazy.

For comparison: I mentored the same project in 2006 and 2007 with
different students; the 2006 student unfortunately wasn't able to get
anywhere; the 2007 student has been involved in Debian as a sponsored
package maintainer for a while that happened to be related to the topic,
worked on academic research also related to the topic, and at the end
of the summer was was one of the test cases for deployment of Debian
Maintainers; he was impressively successful at the GSoC task and has
been continuing with it since then.

Sorry, but preferncing people with no experience or involvement is a
*completely* backwards approach, however you water it down.

That said, GSoC is meant to be about *learning* and *getting people
involved* in the project and mentorship, so a student who's already
really experienced with Debian will still need to find some area that
they don't already know inside and out, aren't already involved in
completely, and can find someone who knows more about it than they do
to act as their mentor.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Google Summer of Code 2008

[Steve Langasek]

On Thu, Feb 28, 2008 at 09:17:56AM +0100, Lucas Nussbaum wrote:

> > I really can't figure out what you're saying, here.  AFAICS, we had
> > significantly *better* results when choosing GSoC projects submitted by
> > existing Debian contributors.  Where are these failures you're talking
> > about?

> My definition of failure is: "(what was achieved) < (what I expected to
> be achieved, given the skills of the people assigned and the time they
> were supposed to spend on the project)".

> That's of course subjective,

Yes, subjective to the point of absurdity.  If failure is defined in terms
of *your* expectations, I don't see how we can even have a meaningful
dialogue about it.

> but I think that the evaluation done by the mentors is subjective too. How
> were the GSOC projects evaluated?

I don't know how they were evaluated, but why are you only now asking this
question, and of debian-devel instead of the program mentors?  This seems
like a question that ought to be asked of the relevant parties *before*
declaring that Debian's participation in GSoC has been a "failure".

An objective metric for success and failure is "accomplished the goals that
were stated at the beginning of the project".  Another is "produces working
code".  I think these are the most important objective metrics for success,
and it's my understanding that by these standards, Debian's participation in
the 2007 GSoC was a success.

There may be other objective metrics to consider; yet I don't see any way
that the *students* should be judged to have failed if they met the goals
that were agreed to up front, whether or not they met *your* expectations of
output.  The latter might indicate that the mentors failed to set
appropriate goals, but that's an entirely separate question.

> Were they given goals to fullfill? We probably need to improve the
> descriptions of the projects a bit, so people know a bit more what they
> are expected to do.

Again, questions that should be directed to the GSoC admins and/or mentors.
But this is also addressed in the GSoC FAQ:

  10. Will a student receive the stipend if the organization does not use
  her/his code?

  As long as the goals listed in a student's accepted application are met
  according to the judgment of her/his mentoring organization, the student
  will receive the stipend whether or not the project uses the code
  produced.

  http://code.google.com/soc/2008/faqs.html#0.1_stipend_code

But the evaluations of the students' projects are not public in nature.
It's up to Debian's GSoC admins to decide how much detail to share with you;
I don't think it would be appropriate to make students have to answer to all
1000+ DDs for their GSoC work, whether or not the students are themselves
DDs.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

Bug#468311: ITP: octave-pkg-dev -- helper for building Octave packages

[Rafael Laboissiere]

Package: wnpp
Severity: wishlist
Owner: Rafael Laboissiere <[EMAIL PROTECTED]>


* Package name: octave-pkg-dev
  Version : 0.1
  Upstream Author : Rafael Laboissiere <[EMAIL PROTECTED]>
* URL : 
http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/trunk/?rev=0&sc=0
* License : GPL
  Programming Lang: Make, Perl
  Description : helper for building Octave packages

This package provides the infrastructure for building add-on packages for
Octave, a numerical computation program [1].  These add-on packages can be
installed by the user through the Octave's pkg.m system, but the Debian
Octave Group (DOG) [2] will provide them as Debian packages. The main origin
of such add-ons is the octave-forge project [3].

This package is meant to be used by the members of the DOG and should be of
very limited interest to the general user. 

[1] http://www.octave.org
[2] http://pkg-octave.alioth.debian.org/
[3] http://octave.sf.net/packages.html




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

Bug#468314: RFH: k3b -- A sophisticated KDE CD burning application

[Francois Marier]

Package: wnpp
Severity: normal

I request a co-maintainer for K3b. There are often quite a few bugs which take 
some time
to investigate and attempt to reproduce before forwarding upstream (and 
following up).

It's not a huge amount of work, but it would be quite nice to split the work 
with someone
else.

On my list of things to do is merge the packaging with the Ubuntu version and 
try to
collaborate more with the Ubuntu maintainers.

So if anyone is keen to help out with a package that's use by a very large 
number of users,
please get in touch with me.

Francois

The package description is:
 K3b is a GUI frontend to the CD recording programs cdrdao and cdrecord.
 Its aim is to provide a very user friendly interface to all the tasks
 that come with cd recording.
 .
 It can be used to copy CDs and burn:
  - audio CDs (from wav, mp3, ogg vorbis, mpc or flac files)
  - data CDs and DVDs
  - mixed-mode CDs (CD-Extra support)
  - VCDs (1.1, 2.0 and SVCD)
  - ISO files (Joliet/Rockridge and El Torito support)
  - eMovix CDs

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.23.17-hrt3-grsec (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_CA.utf8)
Shell: /bin/sh linked to /bin/bash



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

Re: Google Summer of Code 2008

[Lucas Nussbaum]

On 28/02/08 at 01:09 -0800, Steve Langasek wrote:
> On Thu, Feb 28, 2008 at 09:17:56AM +0100, Lucas Nussbaum wrote:
> 
> > > I really can't figure out what you're saying, here.  AFAICS, we had
> > > significantly *better* results when choosing GSoC projects submitted by
> > > existing Debian contributors.  Where are these failures you're talking
> > > about?
> 
> > My definition of failure is: "(what was achieved) < (what I expected to
> > be achieved, given the skills of the people assigned and the time they
> > were supposed to spend on the project)".
> 
> > That's of course subjective,
> 
> Yes, subjective to the point of absurdity.  If failure is defined in terms
> of *your* expectations, I don't see how we can even have a meaningful
> dialogue about it.

Note that my main point in the thread is "we should use GSOC to get
fresh blood in Debian, not to fund existing contributors". The point
about "Debian GSOC projects have been unsuccessful in the past" is
totally secondary.

I am under the impression that results from last years' GSOC projects
weren't up to par with what could have reasonably been expected from
them, based on the skills of the students and the time they were
supposed to spend on the projects. Maybe I'm wrong, but it will be
difficult for you to convince me of that, since we lack data :-)

> > but I think that the evaluation done by the mentors is subjective too. How
> > were the GSOC projects evaluated?
> 
> I don't know how they were evaluated, but why are you only now asking this
> question, and of debian-devel instead of the program mentors?

Mainly because GSOC 2008 was announced on d-d-a with a reply-to set to
[EMAIL PROTECTED] Also, my goal is not to do a witch hunt about last years'
projects. Frankly, I don't care. My goal is to see if we can improve
things this year (if there's something to improve).

> This seems
> like a question that ought to be asked of the relevant parties *before*
> declaring that Debian's participation in GSoC has been a "failure".

I never said that.

> An objective metric for success and failure is "accomplished the goals that
> were stated at the beginning of the project".  Another is "produces working
> code".  I think these are the most important objective metrics for success,
> and it's my understanding that by these standards, Debian's participation in
> the 2007 GSoC was a success.
> 
> There may be other objective metrics to consider; yet I don't see any way
> that the *students* should be judged to have failed if they met the goals
> that were agreed to up front, whether or not they met *your* expectations of
> output.  The latter might indicate that the mentors failed to set
> appropriate goals, but that's an entirely separate question.

I was not aware that all of last year's projects were "succesful" (by
the mentors' metrics). Am I allowed to change what I wrote in a previous
mail? I'd like to substitute:
> I'm not saying that students that were DD did nothing of their time
> during GSoc, but most of them failed their projects
With:
> I'm not saying that students that were DD did nothing of their time
> during GSoc, but most of them produced results that were a bit
> disappointing given what people could have expected from them, mainly
> because they used their GSOC time to work on other Debian tasks.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: Google Summer of Code 2008

[Cyril Brulebois]

On 28/02/2008, Lucas Nussbaum wrote:
> > Nice claims. Pointers?
>
> I agree that this is mainly based on personal perception (but that's
> not really my fault: no final report about what students did (in
> detail) are available).

OK. So you lack info, thus assume people failed. Nice. Steve already
answered about this, anyway.

> > How is this distinction relevant? Isn't that possible to be
> > waiting-for-that-never-coming-DAM-review, student, but also
> > working on various opensource projects, as well as maintaining
> > packages, alone or within teams, working on various areas of the
> > Debian project (e.g. QA, by providing with patches, NMUing
> > packages; or mentoring people with their new or updated packages),
> > at the very same time?
> >
> > I believe it's possible. And I believe you'll find a trivial
> > example.
>
> GSOC != "get funding for existing DDs to do $DEBIAN_WORK". If GSOC
> is only DuncTank 2.0, I think that we could have a nice
> thread^Hflamewar about whether it's good or evil. GSOC is considered
> good by many people because one of its stated goals is to bring
> fresh blood to free software.

I'm not saying that GSOC is about getting funded to do
$USUAL_DEBIAN_WORK, I'm just saying that it's possible to work on very
different areas, and to keep a separation before “usual work” and
“GSOC work”, and that your distinction (early-NM, waiting-forever-NM,
and so on) is totally irrelevant.

BTW, it might be relevant to check GSOC's FAQ to see what it is about.

,
| Google Summer of Code has several goals:
|
| * Get more open source code created and released for the benefit of
|   all;
| * Inspire young developers to begin participating in open source
|   development;
| * Help open source projects identify and bring in new developers and
|   committers;
| * Provide students in Computer Science and related fields the
|   opportunity to do work related to their academic pursuits during
|   the summer (think "flip bits, not burgers");
| * Give students more exposure to real-world software development
|   scenarios (e.g., distributed development, software licensing
|   questions, mailing-list etiquette).
`

Source: http://code.google.com/soc/2008/faqs.html#0.1_goals

Please note that it's not only about “bringing fresh blood to free
software”.

> Now, I agree that "fresh blood" is difficult to define. Is someone
> that has been involved a bit in Debian for 1-2 months "fresh blood"?

Again, that's not the (only) point.

> Someone who submitted some bug reports, but never got involved?

Submitting bug reports is IMHO a way to get involved. At least in my
experience, FTWC.

> someone who is very involved in GNOME, but not involved in Debian?
> So my distinction sucks, but I couldn't come up with something
> better that fitted in a line.

There's no line to fit.

> > Now. How come it wouldn't be possible to apply for a GSOC slot,
> > lowering the involvement in one (or more) of the above-mentioned
> > areas, and concentrating on a specific project?
>
> Past years show that this is very hard to do,

Pointers? Ahah, no, you already said you haven't got any.

> but of course it's possible. But that also means that we are
> shooting ourselves in the foot: we are asking someone to lower his
> involvement in some areas of Debian, where we might be depending on
> him. Many Debian teams might not be able to afford to lose an active
> contributor during the summer (just before the lenny release!) so he
> can work on his GSOC project.

Huh? You know about libre arbitre, right? If people apply to GSOC,
their choice. I really don't know why you would forbid them to apply.
So that they keep doing the dirty job before a release?

-- 
Cyril Brulebois


pgpSjKxjhcWxG.pgp
Description: PGP signature

Bug#468315: ITP: efreet -- Implementation of the freedesktop.org specs for use with E17/EFL

[Jan Luebbe]

Package: wnpp
Severity: wishlist
Owner: Jan Luebbe <[EMAIL PROTECTED]>


* Package name: efreet
  Version : 0.0.3.042
  Upstream Author : Carsten Haitzler and the e17 devel team <[EMAIL PROTECTED]>
* URL : http://www.enlightenment.org/
* License : BSD
  Programming Lang: C
  Description : Implementation of the freedesktop.org specs for use with 
E17/EFL

An implementation of several specifications from freedesktop.org intended for
use in Enlightenment DR17 (e17) and other applications using the Enlightenment
Foundation Libraries (EFL). Currently, the following specifications are
included:
 - Base Directory
 - Desktop Entry
 - Icon Theme
 - Menu

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (300, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-x60s (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: Google Summer of Code 2008

[Cyril Brulebois]

On 28/02/2008, Lucas Nussbaum wrote:
> 2) | * Inspire young developers to begin participating in open
>|   source development;

> 3) | * Help open source projects identify and bring in new
>|   developers and committers;

> 5) | * Give students more exposure to real-world software
>|   development scenarios (e.g., distributed development,
>|   software licensing questions, mailing-list etiquette).

> Points 2,3 and 5 can be summarized as "goal of GSOC is get fresh
> blood". Only point 1 is about "goal of GSOC is to get code written".
> This is too ambiguous to conclude anything from it.

No. 2) is about *development*. Development is not necessarily a part
of the usual job of Debian packagers. 5) is also about development.
And I really believe that there's a very large gap between packaging
and developping. Of course that depends on the packages, the
packagers, and so on. But in the cases you try to address, it looks
like glibc or X hackers aren't concerned. You also don't speak about
4) at all.

> > Pointers? Ahah, no, you already said you haven't got any.
>
> It would be a good idea to ask jvm, ana, marga, tincho and lamby
> about their opinion on that topic.

Looks to me like the very first thing you should have done.

> > Huh? You know about libre arbitre, right? If people apply to GSOC,
> > their choice. I really don't know why you would forbid them to
> > apply. So that they keep doing the dirty job before a release?
>
> Gah, you discovered my evil plans :-)

I don't find that funny. At all.

-- 
Cyril Brulebois


pgpoGJUuUPPma.pgp
Description: PGP signature

Re: Idea of Debian mascot

[Jeremiah C. Foster]

How about a potato as a mascot? It is a staple in many diets, it dovetails
nicely with the Toy Story leitmotif running through debian versioning, and 
is malleable allowing it to look like a lot of things, i.e. with a face, a 
swirl on its belly, etc.

The logos are fantastic and should not be changed. Changing the swirl would
damage the debian brand which stands for "technically advanced", "commited
to freedom", "user-focused", "stable and supported" amongst other things.
If the swirl changed, it would make debian seem less "stable" since the image
of the brand would be seen to shift.

A mascot might help with branding. While branding is generally something that 
FLOSS engineers care nothing about, and seems trivial, it has an impact.


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

Re: Google Summer of Code 2008

[Lucas Nussbaum]

On 28/02/08 at 11:36 +0100, Cyril Brulebois wrote:
> On 28/02/2008, Lucas Nussbaum wrote:
> > 2) | * Inspire young developers to begin participating in open
> >|   source development;
> 
> > 3) | * Help open source projects identify and bring in new
> >|   developers and committers;
> 
> > 5) | * Give students more exposure to real-world software
> >|   development scenarios (e.g., distributed development,
> >|   software licensing questions, mailing-list etiquette).
> 
> > Points 2,3 and 5 can be summarized as "goal of GSOC is get fresh
> > blood". Only point 1 is about "goal of GSOC is to get code written".
> > This is too ambiguous to conclude anything from it.
> 
> No. 2) is about *development*. Development is not necessarily a part
> of the usual job of Debian packagers.

Remember that those goals apply to all participating organizations, not
only to Debian. I don't think (but I might be wrong) that (2) should be
read as:
  Inspire young developers to begin participating in open source
  development (as opposed to packaging, documentation, translation).
I think that "development" should be understood as something general.
In Debian, I think that packaging is usually considered "development".
Or many of us are "debian packagers", not "debian developers" :-)

> 5) is also about development.

Indeed, "more exposure" could be understood as "more exposure than they
currently have". But really, I'm not so sure that's the case.

> You also don't speak about 4) at all.

Because (4) doesn't seem relevant to the current discussion?

> > > Pointers? Ahah, no, you already said you haven't got any.
> >
> > It would be a good idea to ask jvm, ana, marga, tincho and lamby
> > about their opinion on that topic.
> 
> Looks to me like the very first thing you should have done.

Who said I didn't? But maybe it was in private IRC discussions/mails.
And maybe I didn't talk to all of them about that neither, so I'm
biaised.

> > > Huh? You know about libre arbitre, right? If people apply to GSOC,
> > > their choice. I really don't know why you would forbid them to
> > > apply. So that they keep doing the dirty job before a release?
> >
> > Gah, you discovered my evil plans :-)
> 
> I don't find that funny. At all.

I understand that you are frustrated by the current state of DAM (Cyril
has been waiting for DAM to review his application for more than 3
months). I am, too (in fact, I think that our inability to give accounts
to some of our most active contributors is one of the biggest problem in
Debian currently). But please don't let this reflect too badly on your
state of mind. I think that your tone in some mails of this thread has
been unnecessarily agressive.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: Google Summer of Code 2008

[Lucas Nussbaum]

On 28/02/08 at 10:54 +0100, Cyril Brulebois wrote:
> BTW, it might be relevant to check GSOC's FAQ to see what it is about.
> 
> ,
> | Google Summer of Code has several goals:
> |
> | * Get more open source code created and released for the benefit of
> |   all;
> | * Inspire young developers to begin participating in open source
> |   development;
> | * Help open source projects identify and bring in new developers and
> |   committers;
> | * Provide students in Computer Science and related fields the
> |   opportunity to do work related to their academic pursuits during
> |   the summer (think "flip bits, not burgers");
> | * Give students more exposure to real-world software development
> |   scenarios (e.g., distributed development, software licensing
> |   questions, mailing-list etiquette).
> `
> 
> Source: http://code.google.com/soc/2008/faqs.html#0.1_goals
> 
> Please note that it's not only about “bringing fresh blood to free
> software”.

Points 2,3 and 5 can be summarized as "goal of GSOC is get fresh blood".
Only point 1 is about "goal of GSOC is to get code written".
This is too ambiguous to conclude anything from it.

> > > Now. How come it wouldn't be possible to apply for a GSOC slot,
> > > lowering the involvement in one (or more) of the above-mentioned
> > > areas, and concentrating on a specific project?
> >
> > Past years show that this is very hard to do,
> 
> Pointers? Ahah, no, you already said you haven't got any.

It would be a good idea to ask jvm, ana, marga, tincho and lamby about
their opinion on that topic.

> > but of course it's possible. But that also means that we are
> > shooting ourselves in the foot: we are asking someone to lower his
> > involvement in some areas of Debian, where we might be depending on
> > him. Many Debian teams might not be able to afford to lose an active
> > contributor during the summer (just before the lenny release!) so he
> > can work on his GSOC project.
> 
> Huh? You know about libre arbitre, right? If people apply to GSOC,
> their choice. I really don't know why you would forbid them to apply.
> So that they keep doing the dirty job before a release?

Gah, you discovered my evil plans :-)
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: Google Summer of Code 2008

[Cyril Brulebois]

On 28/02/2008, Lucas Nussbaum wrote:
> Who said I didn't? But maybe it was in private IRC
> discussions/mails. And maybe I didn't talk to all of them about that
> neither, so I'm biaised.

Because you said that your previous claims were based on your personal
impressions rather than anything else? Why didn't you provide us with
info/pointers, then, instead of “It would be a good idea…”? It would
be nice to stop using maybe's.

> I understand that you are frustrated by the current state of DAM
> (Cyril has been waiting for DAM to review his application for more
> than 3 months).
> I am, too (in fact, I think that our inability to give accounts to
> some of our most active contributors is one of the biggest problem
> in Debian currently).
> But please don't let this reflect too badly on your state of mind.

My state of mind is “nothing too dramatic”.

> I think that your tone in some mails of this thread has been
> unnecessarily agressive.

I think that your trying to keep almost-DD's out of GSOC for bogus
reasons has been unnecessarily aggressive.

-- 
Cyril Brulebois


pgpc67crjt6XN.pgp
Description: PGP signature

Re: apt-get and SOCKS!

[Nico Golde]

Hi Edward,
* Edward Tjornhammar <[EMAIL PROTECTED]> [2008-02-28 12:26]:
> This might not be the correct place but here goes..
> 
> apt-get provides http_proxy and ftp_proxy support but why not SOCKS?
[...] 
No idea but nothing prevents you from using for example 
tsocks.
Kind regards
Nico
-- 
Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpRTHadNJhxz.pgp
Description: PGP signature

apt-get and SOCKS!

[Edward Tjornhammar]

This might not be the correct place but here goes..

apt-get provides http_proxy and ftp_proxy support but why not SOCKS?
I have no experience with SOCKS other than that I use it daily in conjunction
with firefox and ssh. I think it is a feature which could be of use 
to others as well since it would enable you to use apt over ssh.
--
Edward Tjörnhammar \_\X\_
Cube²   \_\_\X
+46703784224 \X\X\X


!DSPAM:47c68f4a30731151511124!



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

Fwd: Introduction

[idowu sola]

Note: forwarded message attached.
   
-
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.--- Begin Message ---


andrew warri <[EMAIL PROTECTED]> wrote: Date: Mon, 25 Feb 2008 08:00:40 -0800 
(PST)
From: andrew warri <[EMAIL PROTECTED]>
Subject: Introduction
To: [EMAIL PROTECTED]

 We write to introduce Health & Missions International
(HMI), a Christian, Non-profit, non-governmental
organization registered under the company and Allied
Acts of 1990 of the Federal Republic of Nigeria. Our
registration No. is CAC/11/NO21821 with corporate
Affairs Commission Nigeria 
(see website www.cacnigeria.org).

We are involved with the provision of Free Health Care
to the doorsteps of the poor underserved people of the
rural areas of Nigeria, West Africa and recently,South Africa.
 We have been able to achieved this with a strong collaborative 
bond with A.M.PROJECTS(amp). We have reached out to as 
much as 250,000 poor across Africa with free health care since 
2003 when we started

We have a volunteer base of almost 1000 doctors/surgeons/pharmacist and 
paramedics and others who are ready to invest their time and skill free of 
charge to treat poor people.

You can be part of us through your:
1. Prayers
2. Participation as a volunteer
3. Sending us used or unused hospital equipment/consumables/drugs
4. Sending us All Terrain Vehicles
5. Sponsoring the treatment of the poor by sending us
cash (dollars or pounds). As little as one dollar or
pound will go a long way to save a life. 


You may wish to reach us through our site; www.amphmi.org or e-mail Dr. Warri 
at [EMAIL PROTECTED] or call on; +2348033127959, +23484482484 or +27731162870


  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping


   
-
Never miss a thing.   Make Yahoo your homepage.--- End Message ---

apt-get and SOCKS

[xHemi]

This might not be the correct place but here goes..

apt-get provides http_proxy and ftp_proxy support but why not SOCKS?
I have no experience with SOCKS other than that I use it daily in conjunction
with firefox and ssh. I think it is a feature which could be of use
to others as well since it would enable you to use apt over ssh.

Regards


!DSPAM:47c6934330731369617410!



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

FW by [EMAIL PROTECTED] : Bug#467249: man-db: over sensitive on the spell of locale

[Michelle Konzack]

Hello Maintainers,

It seems there is a common problem while setting up the correct UNICODE
locale in systems.  As the posster in the attached message has written,
he has setup his locale to "zh_CN.utf8" which is wrong, but as he has
written too, the output of "locale -a" show it.

I have many customers with the same problem...

I think, there should be a global solution for this, since patching
man-db is worthless.

Please discuse this problem and let me stay in the MFT.

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant



- Forwarded message from LI Daobing <[EMAIL PROTECTED]> -

Date: Sun, 24 Feb 2008 11:51:44 +0800
From: LI Daobing <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: Bug#467249: man-db: over sensitive on the spell of locale
X-PTS-Package: man-db
X-Debian-PR-Package: man-db

Package: man-db
Version: 2.5.1-2
Severity: important


when set locale to zh_CN.UTF-8, I can view a chinese manpage with 
"man -l ls.zh_CN.1", but when set locale to zh_CN.utf8, I got many
rubbish charaters on the screen.

and the information generated by "locale -a" is zh_CN.utf8, so many
users set locale to utf8 instead of UTF-8.

the ls.zh_CN.1 in attchment.

please fix it, thanks.

or you can reproduce this bug with following commands. Thanks.

$ LANG=zh_CN.UTF-8 man --warnings -l ls.zh_CN.1 > /dev/null
$ LANG=zh_CN.utf8 man --warnings -l ls.zh_CN.1 > /dev/null
:9: warning: can't find special character `u013F'
:9: warning: can't find special character `u011A'
:9: warning: can't find special character `u021D'
:11: warning: can't find special character `u0321'
:11: warning: can't find special character `u04AA'
:12: warning: can't find special character `u0461'
// snip


- End forwarded message ---





-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Intent to hijack pyicqt

[Michal Čihař]

Hi

package was only initially uploaded and then no bug fixes happened, what
lead to completely broken package which I fixed by NMU in October 2007.
Patrick promised to work on the package in December 2007 (see bug 
#453959 [1]), but nothing happened and I did not get any reply on my
emails since that time.

I have prepared package with new version in svn[2][3] and will upload
them next week if no objections will appear.

[1]:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453959
[2]:svn://svn.cihar.com/debian-pyicqt
[3]:http://viewsvn.cihar.com/viewvc.cgi/debian-pyicqt/

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: Intent to hijack pyicqt

[Patrick]

Hi,

I waited for a new version + waited for the final end of migration to 
google-code-base. Unfortunately I am quite busy at the moment but my 
intention was to get a new version ready before end of february - which 
was the last deadline you mentioned.


Nevertheless - I totally understand your point and hereby agree to you 
taking over my package - but since it is my work in the first place + 
due to my continuing interest in the pyicqt package I'd like to 
co-maintain it.


I hope you agree to that compromise.


regards,
Patrick



Michal Čihař wrote:

Hi

package was only initially uploaded and then no bug fixes happened, what
lead to completely broken package which I fixed by NMU in October 2007.
Patrick promised to work on the package in December 2007 (see bug 
#453959 [1]), but nothing happened and I did not get any reply on my

emails since that time.

I have prepared package with new version in svn[2][3] and will upload
them next week if no objections will appear.

[1]:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453959
[2]:svn://svn.cihar.com/debian-pyicqt
[3]:http://viewsvn.cihar.com/viewvc.cgi/debian-pyicqt/

  



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

Re: Intent to hijack pyicqt

[Michal Čihař]

Hi

On Thu, 28 Feb 2008 16:32:50 +0100
Patrick <[EMAIL PROTECTED]> wrote:

> I waited for a new version + waited for the final end of migration to 
> google-code-base. Unfortunately I am quite busy at the moment but my 
> intention was to get a new version ready before end of february - which 
> was the last deadline you mentioned.

I just did not see any reaction from your side, that's why I wrote this
email. End of February is tomorrow and wanted to get feedback ;-).

> Nevertheless - I totally understand your point and hereby agree to you 
> taking over my package - but since it is my work in the first place + 
> due to my continuing interest in the pyicqt package I'd like to 
> co-maintain it.
> 
> I hope you agree to that compromise.

Of course no problem with that. Maybe we can use PAPT [1] for
co-maintaining it as Sandro Tosi has suggested me.

[1] http://wiki.debian.org/Teams/PythonAppsPackagingTeam

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Uzeneted erkezett!

[Kicsiandika]

Udv!:)

Tudom, hogy nem szeretsz ilyen leveleket kapni, de hidd el most az egyszer 
megeri elolvasnod, mert sok levelet kapunk vissza hogy majdnem kitorolte de 
azert csak megerte elolvasni, mert fantasztikus az oldal amit 
ajanlunk, es tenyleg az! Nalunk tiszta tartamat kapsz, semmi reklam semmi 
elougro ablak! Kerlek nezd meg:

http://bioweb.webhop.net/

Koszonettel:

BiO Team

ui.: email cimedet egy adatbazisbol kaptuk, amihez elozetesen hozzajarultal. 
Ezt a levelt csak 1x kapod meg, mi nem fogunk ezzel zaklatni tobbet.


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

Bug#468381: ITP: commithooks -- Hooks to inject VCS commits into bug-tracking systems

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen <[EMAIL PROTECTED]>

* Package name: commithooks
  Version : 1.0.0
  Upstream Author : John Goerzen <[EMAIL PROTECTED]> et al
* URL : http://software.complete.org/commithooks
* License : GPL and BSD
  Programming Lang: Shell and Python
  Description : Hooks to inject VCS commits into bug-tracking systems
 This is a collection of scripts to process commit actions from
 different version control systems (VCS) and inject the results into
 different bug-tracking systems (BTS), sometimes closing bugs as a
  result.
 .
 Supported VCS include Darcs, Mercurial, and Git.  Supported BTS
 include debbugs (the Debian BTS) and Trac.

This package will be uploaded once #468226 has been resolved, as it
contains a derivative of the referenced script.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (99, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash



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

Re: apt-get and SOCKS!

[Jon Dowland]

On Thu, Feb 28, 2008 at 11:39:06AM +0100, Edward Tjornhammar wrote:
> apt-get provides http_proxy and ftp_proxy support but why not SOCKS?
> I have no experience with SOCKS other than that I use it daily in
> conjunction with firefox and ssh. I think it is a feature which could
> be of use to others as well since it would enable you to use apt over
> ssh.

I'd suggest checking for a wishlist bug filed against apt,
requesting SOCKS support.  If it doesn't exist, file it.


-- 
Jon Dowland


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

Re: apt-get and SOCKS!

[William Pitcock]

On Thu, 2008-02-28 at 16:53 +, Jon Dowland wrote:
> On Thu, Feb 28, 2008 at 11:39:06AM +0100, Edward Tjornhammar wrote:
> > apt-get provides http_proxy and ftp_proxy support but why not SOCKS?
> > I have no experience with SOCKS other than that I use it daily in
> > conjunction with firefox and ssh. I think it is a feature which could
> > be of use to others as well since it would enable you to use apt over
> > ssh.
> 
> I'd suggest checking for a wishlist bug filed against apt,
> requesting SOCKS support.  If it doesn't exist, file it.

At least with curl, 'export http_proxy="socks5://ip:port/"'. So it might
work with apt too. I've used apt with a socks proxy before, I know that.

William


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

Bug#468408: ITP: libgenome -- toolkit for developing bioinformatic related software

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille <[EMAIL PROTECTED]>

* Package name: libgenome
  Version : 1.3.0
  Upstream Author : Aaron Darling >[EMAIL PROTECTED]> and others
* URL : 
http://asap.ahabs.wisc.edu/software/software-development-libraries/libgenome.html
 
* License : GPL
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : toolkit for developing bioinformatic related software

 libGenome is a freely available toolkit for developing bioinformatic related 
 software in C++.  It is intended to take the hassle out of performing common 
 tasks on genetic sequence and annotation data. 
 .
 Among other things, libGenome can help you:
 .
  * Read and write Multi-FastA format files 
  * Read and write GenBank flat file database entries 
  * Append, chop, truncate, reverse, complement, translate, and otherwise 
mangle sequence data
  * Access annotation in GenBank flat files 


The package will be team maintained by the Debian-Med packaging team.
Preliminary packaging stuff can be found at

  
http://svn.debian.org/wsvn/debian-med/trunk/packages/libgenome/trunk/debian/?rev=0&sc=0

Kind regards

Andreas.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'unstable'), (5, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash



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

Re: Debian Configuration Packaging System

[Ian Jackson]

Timothy G Abbott writes ("Re: Debian Configuration Packaging System"):
> So, our goal is to provide our users with the same opportunities to 
> override our configuration defaults as they would have had if Debian had 
> been providing them instead.  Using the Debian packaging system for this 
> configuration is a good way to achieve this.

The Debian packaging system and configuration setups are not designed
to provide more than the one level of override for the contents of
system files.

Ian.


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

Re: Debian Configuration Packaging System

[Timothy G Abbott]

On Thu, 28 Feb 2008, Ian Jackson wrote:


Timothy G Abbott writes ("Re: Debian Configuration Packaging System"):

So, our goal is to provide our users with the same opportunities to
override our configuration defaults as they would have had if Debian had
been providing them instead.  Using the Debian packaging system for this
configuration is a good way to achieve this.


The Debian packaging system and configuration setups are not designed
to provide more than the one level of override for the contents of
system files.


Configuration packages made using our system distribute only conffiles. 
End-users of the configuration packages can modify (e.g.) 
/etc/ldap/ldap.conf by changing /etc/ldap/ldap.conf.debathena, which is a 
normal Debian conffile (and is what users will change if they try to 
modify /etc/ldap/ldap.conf using any editor).


While this may not have been something envisioned by the designers of the 
Debian packaging system, our system's use of standard pieces of the Debian 
packaging system certainly supports this.


-Tim Abbott



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

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Ian Jackson]

Mark Brown writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg 
maintenance)"):
> I've no idea if anyone involved would consider it acceptable but might
> merging the triggers branch into the mainline with --squash be a
> suitable comprimise?  This would give a single commit discarding the
> branch history which isn't ideal but would avoid having the history
> >from  your branch in the main history.

Does this not also suffer from the problem that branches made from my
triggers branch become unuseable or difficult to merge ?

Ian.


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

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Ian Jackson]

Raphael Hertzog writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg 
maintenance)"):
> As soon as you edit commits, they'll get a new id, and thus you'll disrupt
> merging. 

As I thought.

What I am trying to achieve is to use git in the proper way: that is,
in a way which makes merging work properly.

Insisting that I use git in a manner which makes merges break but
gives prettier logfiles is absurd.

> The thing that you doesn't seem to understand is that if you don't do it,
> Guillem will do it for you and you'll have to fix up your other branches
> (flex-based parser, ...) anyway and you won't be able to use plain merge
> for that (or rather you can but it will be highly inefficient compared to
> a "git-rebase -i" where you skip the irrelevant commits that have been
> merged with other id). 

Only if Guillem insists on not taking on board the points that I and
others are making here.

Ian.


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

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Raphael Hertzog]

On Thu, 28 Feb 2008, Ian Jackson wrote:
> Mark Brown writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg 
> maintenance)"):
> > I've no idea if anyone involved would consider it acceptable but might
> > merging the triggers branch into the mainline with --squash be a
> > suitable comprimise?  This would give a single commit discarding the
> > branch history which isn't ideal but would avoid having the history
> > >from  your branch in the main history.
> 
> Does this not also suffer from the problem that branches made from my
> triggers branch become unuseable or difficult to merge ?

git merge --squash is more or less equivalent to applying the patch
corresponding to the whole branch. So it will also break merging from
other branches based on the merged branch.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: FW by [EMAIL PROTECTED] : Bug#467249: man-db: over sensitive on the spell of locale

[Adam Borowski]

On Thu, Feb 28, 2008 at 10:42:30AM +0100, Michelle Konzack wrote:
> Hello Maintainers,
> 
> It seems there is a common problem while setting up the correct UNICODE
> locale in systems.  As the posster in the attached message has written,
> he has setup his locale to "zh_CN.utf8" which is wrong, but as he has
> written too, the output of "locale -a" show it.

No way which way the _locale_ is spelt (including "vi_VI" without even the
word "utf" inside), the _charset_ is UTF-8.  No program ever should look at
the locale's name, as it has more quirks like this.  Checking the charset
will get you what you want.

> I think, there should be a global solution for this, since patching
> man-db is worthless.

Actually, it's groff what's at fault here.  Mostly.

> $ LANG=zh_CN.UTF-8 man --warnings -l ls.zh_CN.1 > /dev/null
> $ LANG=zh_CN.utf8 man --warnings -l ls.zh_CN.1 > /dev/null
> :9: warning: can't find special character `u013F'
> :9: warning: can't find special character `u011A'
> :9: warning: can't find special character `u021D'
> :11: warning: can't find special character `u0321'
> :11: warning: can't find special character `u04AA'
> :12: warning: can't find special character `u0461'
> // snip

Too bad, groff doesn't have real Unicode support, and supports only several
special-cased locales (which may then be transcoded as UTF-8, but they still
get wrapped into their old-style charsets).

Instead of changing the special-case recognition, I would instead completely
skip special-casing and just treat all characters equally.  Including, but
not limited to, u013F and u0461.


I've did some initial work at this, but unfortunately I'm dead busy right
now.  For "show me the code", working but not good enough to even to submit
to Colin pan-Unicode groff and man-db are at
deb-src http://angband.pl/debian sid main
(just don't look inside, they're too ugly to live).  On the upside, on tty
everything but RTL (Hebrew/Arabic) works just fine, including CJK,
Vietnamese, Devanagari and cuneiform, even all together in one manpage (try
"man utf8test").  What's lacking is support for html (should be trivial), ps
(aargh...) and other devices.
I'm afraid I can do nothing at least until late friday...  but it looks like
we may be able to help Colin squash at least this bastion of locale
dependency.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Ian Jackson]

Ian Jackson writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg 
maintenance)"):
> It is very unfortunate for git that most of its advocates want to
> adopt these almost unmanageable development practices along with the
> revision control software.

I'd like to expand on this, and partly reiterate what John Goerzen
said earlier about other revision control systems.

If dpkg were in darcs, bzr or arch, hardly anyone would seriously
suggest a workflow like the suggested git-rebase; we've heard that
it's in a minority amongst hg users as well.  Everyone would assume
that we would use the workflow I am proposing.  That workflow is
indeed supported by git.  So it is clear that my suggested workflow is
not inherently unacceptable or unworkable for dpkg.

Is it really the case that just because git has this rebase
functionality (which is designed for submitting patches in enormous
projects), we must use it ?

Surely the question is whether the benefits of the rebase workflow
outweigh the costs.

Costs:
  * Code changes need to be reworked and reorganised
  * Commit logs need to be reedited
  * Code needs to be retested after the above changes have been made,
probably several times
  * The commit logs do not reflect reality

Benefits:
  * It is somewhat easier to read the diffs when considering whether
to merge, or whether to do substantial structural rework first
  * The commit logs are neater

The first one of those two benefits is obviously the only one that is
relevant.  But it can only be relevant if there is some doubt as to
whether my triggers code should be merged without substantial rework.

Surely it must be clear that it should ?  The specification was
discussed extensively and agreed in the appropriate Debian fora.  The
implementation has been deployed and tested in a very widely used
Debian derivative.

The cost of attempting to reorganise the timeline of code changes
should not be underestimated.  It's not just the work (and its
tiresome nature).  These kind of activities, like merging, are very
error-prone.  Ie, if we adopt the rebase workflow the result is likely
to have more bugs.

Ian.


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

Bug#468421: ITP: libtest-xml-simple-perl -- easy testing for XML

[Jaldhar H. Vyas]

Package: wnpp
Severity: wishlist
Owner: "Jaldhar H. Vyas" <[EMAIL PROTECTED]>

* Package name: libtest-xml-simple-perl
  Version : 0.09
  Upstream Author : Joe McMahon, <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Test-XML-Simple/
* License : GPL+Artistic
  Programming Lang: Perl
  Description : easy testing for XML

Test::XML::Simple is a very basic class for testing XML. It uses the XPath
syntax to locate nodes within the XML. You can also check all or part of the
structure vs. an XML fragment.



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

Re: Bug#467249: FW by [EMAIL PROTECTED] : Bug#467249: man-db: over sensitive on the spell of locale

[Colin Watson]

On Thu, Feb 28, 2008 at 09:21:41PM +0100, Adam Borowski wrote:
> On Thu, Feb 28, 2008 at 10:42:30AM +0100, Michelle Konzack wrote:
> > It seems there is a common problem while setting up the correct UNICODE
> > locale in systems.  As the posster in the attached message has written,
> > he has setup his locale to "zh_CN.utf8" which is wrong, but as he has
> > written too, the output of "locale -a" show it.
> 
> No way which way the _locale_ is spelt (including "vi_VI" without even the
> word "utf" inside),

Irrelevant to this bug, as you'll see if you look at the code.

> the _charset_ is UTF-8.  No program ever should look at the locale's
> name, as it has more quirks like this.  Checking the charset will get
> you what you want.
> 
> > I think, there should be a global solution for this, since patching
> > man-db is worthless.
> 
> Actually, it's groff what's at fault here.  Mostly.

man-db really does have some special-casing here. Trust me. It was
necessary at the time. There are a finite number of known aliases for
the very small number of locales in question, and until it becomes
unnecessary I will simply support those.

(And I agree that it should go away, but can't easily just yet.)

Please don't drag groff into this bug. I really hate it when bugs drift
wildly off their original (accurately-constrained) topic despite
attempts to haul them back. It makes them impossible to keep organised.

> > $ LANG=zh_CN.UTF-8 man --warnings -l ls.zh_CN.1 > /dev/null
> > $ LANG=zh_CN.utf8 man --warnings -l ls.zh_CN.1 > /dev/null
> > :9: warning: can't find special character `u013F'
> > :9: warning: can't find special character `u011A'
> > :9: warning: can't find special character `u021D'
> > :11: warning: can't find special character `u0321'
> > :11: warning: can't find special character `u04AA'
> > :12: warning: can't find special character `u0461'
> > // snip
> 
> Too bad, groff doesn't have real Unicode support, and supports only several
> special-cased locales (which may then be transcoded as UTF-8, but they still
> get wrapped into their old-style charsets).
> 
> Instead of changing the special-case recognition, I would instead completely
> skip special-casing and just treat all characters equally.  Including, but
> not limited to, u013F and u0461.

Are you working with Brian M. Carlson on this? He has been working on a
solution acceptable to groff upstream, which is, frankly, the only way I
want to go now. He has already made substantial progress with character
class support.

Treating all characters equally will absolutely not be acceptable to
groff upstream. groff is a typesetter and needs to know about properties
of characters.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: Bug#467249: FW by [EMAIL PROTECTED] : Bug#467249: man-db: over sensitive on the spell of locale

[brian m. carlson]

On Thu, Feb 28, 2008 at 09:30:55PM +, Colin Watson wrote:

On Thu, Feb 28, 2008 at 09:21:41PM +0100, Adam Borowski wrote:
man-db really does have some special-casing here. Trust me. It was
necessary at the time. There are a finite number of known aliases for
the very small number of locales in question, and until it becomes
unnecessary I will simply support those.

(And I agree that it should go away, but can't easily just yet.)


Is there some way to query what character set a locale uses?  If not, I 
think that man-db should default to UTF-8 (since that *is* the standard 
on Debian) and handle exceptions to that.  Processing an ASCII manpage 
as UTF-8 is a no-op.  And it's pretty easy to tell if something isn't 
valid UTF-8, and man-db can handle that as it normally would.


Of course, I'm not contributing code, so my opinion is worth what you 
paid for it.



Too bad, groff doesn't have real Unicode support, and supports only several
special-cased locales (which may then be transcoded as UTF-8, but they still
get wrapped into their old-style charsets).


AIUI, PostScript doesn't have UTF-8 support either, yet it seems to work 
just fine.  Anyway, newer versions of groff have a conversion tool that 
maps UTF-8 (or any arbitrary character set) input into glyph names.  But 
Debian's groff has been very heavily patched with support for kinsoku 
shori (prohibition character handling) and so we cannot simply update to 
a newer version.  Believe me, if it were that easy, I'm sure Colin would 
have done it.



Are you working with Brian M. Carlson on this? He has been working on a
solution acceptable to groff upstream, which is, frankly, the only way I
want to go now. He has already made substantial progress with character
class support.


Please be aware that I have little time with school right now, so this 
may not be implemented soon.  In fact, it may not be ready in time for 
lenny's release.  I will sit down and work on it some more soon, but my 
time is limited.  If people want more information on my plan of attack, 
please do let me know, and I'll be happy to share.


In fact, I'm off to hack some more on groff right now.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#467249: man-db/groff and locales

[Adam Borowski]

On Thu, Feb 28, 2008 at 10:10:32PM +, brian m. carlson wrote:
> On Thu, Feb 28, 2008 at 09:30:55PM +, Colin Watson wrote:
> >On Thu, Feb 28, 2008 at 09:21:41PM +0100, Adam Borowski wrote:
> >man-db really does have some special-casing here. Trust me. It was
> >necessary at the time. There are a finite number of known aliases for
> >the very small number of locales in question, and until it becomes
> >unnecessary I will simply support those.

Of, course, encodings for _source_ pages are those we can't get away with. 

But for all intermediate steps, I don't see any reason to not go to a
well-known encoding, do everything there and finally convert to whatever
locale is set -- and you don't even need to name the charset there.

Special-casing _output_ locales seems quite strange to me.

> >(And I agree that it should go away, but can't easily just yet.)

Could you tell us what keeps us with all the old cruft?  By adding
groff-1.19 like -K to our groff, I was able replace all special-
casing except for source.  In my ugly preliminary code most functions in
src/encodings.c start with 'return "UTF-8";' -- and it seems to work just
fine in all locales I tested, which include zh_CN.GB2312 and similar.

It's very likely I missed something, I hardly know anything about groff, but
at least at the first glance, ripping away most of the file seems to be a
win.

> Is there some way to query what character set a locale uses?  If not, I 
> think that man-db should default to UTF-8 (since that *is* the standard 
> on Debian) and handle exceptions to that.  Processing an ASCII manpage 
> as UTF-8 is a no-op.  And it's pretty easy to tell if something isn't 
> valid UTF-8, and man-db can handle that as it normally would.

AOL.  I agree with Brian 100%.  As you already added code to detect if the
source is valid UTF-8 or not, all that needs to be done is using UTF-8
instead of ISO-8859-1 as the intermediate format.

> >>Too bad, groff doesn't have real Unicode support, and supports only
> >>several special-cased locales (which may then be transcoded as UTF-8,
> >>but they still get wrapped into their old-style charsets).
> 
> AIUI, PostScript doesn't have UTF-8 support either, yet it seems to work 
> just fine.  Anyway, newer versions of groff have a conversion tool that 
> maps UTF-8 (or any arbitrary character set) input into glyph names.

I see.  So, in very short term, groff would be able to output PostScript
only for limited locales.  That's no regression.

And on tty and html, which are 99.99% of uses of man, suddenly all bugs like
"man iso-8859-2", Kanji names in English manpages, regressions in KOI-8R
(#424655) or no support for Indic scripts would dissappear overnight with a
minimal patch.


> >Are you working with Brian M. Carlson on this?

Not yet, I preferred to have some code to show first.

> >He has been working on a solution acceptable to groff upstream, which is,
> >frankly, the only way I want to go now. He has already made substantial
> >progress with character class support.

Sounds great.  And that's the way to go.

For example, when selecting width, groff 1.18 does:
  u2E00..u9FFF 48 0
  uAC00..uD7AF 48 0
  uFF00..uFFEF 48 0
which supports only CJK.

My temporary solution has a hard-coded table (to minimize patching code):
  u0100..u10FF 24 0
  u1100..u115F 48 0
  u1160..u2328 24 0
  u2329..u232A 48 0
  u232B..u2E7F 24 0
  [...]
  u1..u1FFFD 24 0
  u2..u2FFFD 48 0
  u3..u3FFFD 48 0
  u4..u10 24 0
This supports all other code ranges, and is forward-compatible with when
proper character class support and other goodies go in.
 


> Please be aware that I have little time with school right now, so this 
> may not be implemented soon.  In fact, it may not be ready in time for 
> lenny's release.  I will sit down and work on it some more soon, but my 
> time is limited.  If people want more information on my plan of attack, 
> please do let me know, and I'll be happy to share.

Likewise, I'm nearly unavailable for the next two days.  I'll be able to
help later, but bear in mind that groff is not my area of expertise, and I
plan only minimal changes.


-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Bug#468408: ITP: libgenome -- toolkit for developing bioinformatic related software

[David Nusinow]

On Thu, Feb 28, 2008 at 07:36:34PM +0100, Andreas Tille wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Andreas Tille <[EMAIL PROTECTED]>
> 
> * Package name: libgenome
>   Version : 1.3.0
>   Upstream Author : Aaron Darling >[EMAIL PROTECTED]> and others
> * URL : 
> http://asap.ahabs.wisc.edu/software/software-development-libraries/libgenome.html
>  
> * License : GPL
>   Programming Lang: (C, C++, C#, Perl, Python, etc.)
>   Description : toolkit for developing bioinformatic related software
> 
>  libGenome is a freely available toolkit for developing bioinformatic related 
>  software in C++.  It is intended to take the hassle out of performing common 
>  tasks on genetic sequence and annotation data. 

Just out of curiosity, did you forget to specify the programming language
in the field above, or are there really bindings for languages other than
C++ available with this software?

 - David Nusinow


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

Re: How to cope with patches sanely

[Sam Vilain]

Manoj Srivastava wrote:
>> Feature branches don't magically allow you to avoid merge conflicts
>> either, so this is a red herring. Once you've resolved the conflict,
>> then it becomes just another change. This change can become a diff in
>> a stack of diffs.
> 
> This whole message is a red herring, since hte feature branches
>  do not attempt to handle merge conflicts -- that is not their purpose.
>  They capture one single feature, independently from every other
>  feature, and thumb their collective noses at merge conflicts.

Yes.  Feature branches are effectively forking a particular version of a
project - this is not a problem, and is essential for efficient
development.  People jumbling together changes in "trunk" branches is
perhaps one of the worst upshots of the 2002-2006 or so obsession with
poorly designed centralised systems and in my opinion sank many projects.

> The history of the integration branch captures the integration
>   effort; and the integration branch makes no effort to keep the
> integration work up to date with current upstream and feature
> branches. 

Initially perhaps.  However, once a feature is considered ready for
inclusion, it is important that it contains merges FROM the branch they
are targetting.  They mean that a later merge back the other way, to
merge the feature branch into the target branch, can happen painlessly.
 ASSUMING that you're using a system which has commutative merge
characteristics, such as git or mercurial.

> If you think you can extract an up to date integration patch
>  from the entrails of the integration branch -- feel free o smack
>  me down.  But please provide some substance to the assertion that it is
>  doable.

Perhaps I missed the context to this discussion - certainly expressing a
history containing merge nodes in patches is non-trivial and can't be
done with standard patch format - but I believe that this is certainly
possible.

Can you express this problem with reference to a particular history of
an integration branch?  I will provide some short git commands to
extract the information in the form you are after.

Sam


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

Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol

[Gunnar Wolf]

Guus Sliepen dijo [Wed, Feb 27, 2008 at 07:55:08PM +0100]:
> > Monkey is a Web Server written in C based on the HTTP/1.1 protocol. The
> > objective is to develop a fast, efficient, small and easy to configure
> > webserver.
> > Although it is very small and does not need much system resources, it
> > has a lot of nice features like Multithreading, Mimetype Support,
> > Virtualhosts, CGI & PHP, Basic Security features (Deny by URL + IP)
> 
> The language the server is written in is not important.  Use the debtags
> system to annotate the package with that kind of information. Also,
> don't use subjective wording like "nice features". There are also too
> much capitals in your description. I suggest the following:
> 
>  Monkey is a small, fast, and easily configurable HTTP/1.1 compliant web
>  server. It uses multi-threading and has support for MIME, virtual
>  hosts, CGI and PHP. It offers basic security features, such as denying
>  access to certain URLs for certain IP addresses.

Even there, it looks very much like other "very small" webservers,
such as boa, bozohttpd, cherokee, fnord, lighttpd, micro-httpd,
mini-httpd or thttpd. What does it do better than any of them? Or
worse? Or different?

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: How to cope with patches sanely

[Manoj Srivastava]

On Fri, 29 Feb 2008 12:35:30 +1300, Sam Vilain <[EMAIL PROTECTED]> said: 

> Manoj Srivastava wrote:
>>> Feature branches don't magically allow you to avoid merge conflicts
>>> either, so this is a red herring. Once you've resolved the conflict,
>>> then it becomes just another change. This change can become a diff
>>> in a stack of diffs.
>> 
>> This whole message is a red herring, since hte feature branches do
>> not attempt to handle merge conflicts -- that is not their purpose.
>> They capture one single feature, independently from every other
>> feature, and thumb their collective noses at merge conflicts.

> Yes.  Feature branches are effectively forking a particular version of
> a project - this is not a problem, and is essential for efficient
> development.  People jumbling together changes in "trunk" branches is
> perhaps one of the worst upshots of the 2002-2006 or so obsession with
> poorly designed centralised systems and in my opinion sank many
> projects.

Err. If you go back and read this thread in the archive, You'll
 note that I have stated that my feature branches are always kept up to
 date with the latest upstream branch I am basing my Debian package
 on. 

When I have been creating patches for inclusion with upstream, I
 essentially feed them the source patch and a changelog entry --
 essentially, creating a single patch series; squashing the underlying
 history.  Most upstream do not care about the messy history of my
 development; and most do not grok arch well enough to pull directly.

I am not sure what the relevance of trunk changes you mention
 has to the current thread.

>> The history of the integration branch captures the integration
>> effort; and the integration branch makes no effort to keep the
>> integration work up to date with current upstream and feature
>> branches.

> Initially perhaps.  However, once a feature is considered ready for
> inclusion, it is important that it contains merges FROM the branch
> they are targetting.

Please do read the thread history.  The feature branches being
 kept updated with the upstream branch means that my feature branches
 _always_ apply to the current upstream.

> They mean that a later merge back the other way, to merge the feature
> branch into the target branch, can happen painlessly.  ASSUMING that
> you're using a system which has commutative merge characteristics,
> such as git or mercurial.

I use Arch.

>> If you think you can extract an up to date integration patch from the
>> entrails of the integration branch -- feel free o smack me down.  But
>> please provide some substance to the assertion that it is doable.

> Perhaps I missed the context to this discussion - certainly expressing

I think you have.

> a history containing merge nodes in patches is non-trivial and can't
> be done with standard patch format - but I believe that this is
> certainly possible.

Great. Show me the code. My arch repo is publicly available on
 arch.debian.org.   As they say in Missouri, Show me.

> Can you express this problem with reference to a particular history of
> an integration branch?  I will provide some short git commands to
> extract the information in the form you are after.

 http://arch.debian.org/cgi-bin/archzoom.cgi/[EMAIL PROTECTED]

Take any package. Say, flex. Or flex-old. You have all my
 feature branches there. The --devo branch is the integration branch.
 Please show me an automated way you can grab the feature branches and
 generate a quilt series that gives you the devo branch.  The diff.gz is
 how we get from upstream to the devo branch (modulo ./debian); if you
 can break that down nicely for the folks who want each feature
 separate, that would work as well.

If you code works well enough every single time a new upstream
 comes around and I release a new version of flex or whatever,  I'll
 throw in the generated quilt patches.

Until then, could people stop telling me how easy it is to
 automatically generate quilt series for my packages, and that I should
 jut shut up and code it and not stand in the way of other people trying
 to make such quilt series generation the standard way of doing source
 packages?

BTW, I have heard no one comment on my offer to generate a pure
 patch for each feature branch, with no warranty that the patches can be
 applied linearly, along with the diff.gz that defines the integration
 branch, so that a human can probably tell what most of the changes mean
 (which is what people seemed to be after with neatly separated out
 patches).

manoj
 who does not think that one can go easily from a set of independent
 pure feature patches that separately apply to upstream to a quilt
 series programmatically
-- 
Did I do an INCORRECT THING??
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCR

Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol

[William Pitcock]

On Thu, 2008-02-28 at 18:47 -0600, Gunnar Wolf wrote:
> Guus Sliepen dijo [Wed, Feb 27, 2008 at 07:55:08PM +0100]:
> > > Monkey is a Web Server written in C based on the HTTP/1.1 protocol. The
> > > objective is to develop a fast, efficient, small and easy to configure
> > > webserver.
> > > Although it is very small and does not need much system resources, it
> > > has a lot of nice features like Multithreading, Mimetype Support,
> > > Virtualhosts, CGI & PHP, Basic Security features (Deny by URL + IP)
> > 
> > The language the server is written in is not important.  Use the debtags
> > system to annotate the package with that kind of information. Also,
> > don't use subjective wording like "nice features". There are also too
> > much capitals in your description. I suggest the following:
> > 
> >  Monkey is a small, fast, and easily configurable HTTP/1.1 compliant web
> >  server. It uses multi-threading and has support for MIME, virtual
> >  hosts, CGI and PHP. It offers basic security features, such as denying
> >  access to certain URLs for certain IP addresses.
> 
> Even there, it looks very much like other "very small" webservers,
> such as boa, bozohttpd, cherokee, fnord, lighttpd, micro-httpd,
> mini-httpd or thttpd. What does it do better than any of them? Or
> worse? Or different?

Why does a package need to clarify what's different about it than others
like it? Debian is about having the possibility of choosing between many
options for the same thing e.g. openssh, dropbear for sshd, 12 different
httpd options, etc. 

Package descriptions should stick to positive aspects of the package,
and not try to draw comparisons towards other packages. IMO.

It seems to me as if you are trying to get people to justify the
packages they want to work on. If that is the case, then, I think
"because the person wants to use _this_ package" is fine. Infact, I
would go as far as saying that the wide latitude of software options for
a specific task is one of the greatest strengths of Debian.

As such, I think the revised description is perfectly acceptable for
Debian.

William


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

Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/28/08 20:02, William Pitcock wrote:
> On Thu, 2008-02-28 at 18:47 -0600, Gunnar Wolf wrote:
[snip]
>> Even there, it looks very much like other "very small" webservers,
>> such as boa, bozohttpd, cherokee, fnord, lighttpd, micro-httpd,
>> mini-httpd or thttpd. What does it do better than any of them? Or
>> worse? Or different?
> 
> Why does a package need to clarify what's different about it than others
> like it? Debian is about having the possibility of choosing between many
> options for the same thing e.g. openssh, dropbear for sshd, 12 different
> httpd options, etc. 

Because when the long descriptions of many different "competing"
packages all say essentially the same thing, then those descriptions
are meaningless.

> Package descriptions should stick to positive aspects of the package,
> and not try to draw comparisons towards other packages. IMO.

That's fine.  But when it's something as relatively simple as a
small httpd, you need to spell out specifics as to why I should use
monkey instead of cherokee, boa, thttpd, fnord, etc.

The micro-httpd description is a good example.

> It seems to me as if you are trying to get people to justify the
> packages they want to work on. If that is the case, then, I think
> "because the person wants to use _this_ package" is fine. Infact, I
> would go as far as saying that the wide latitude of software options for
> a specific task is one of the greatest strengths of Debian.

It's not "why should you *package* this s/w", it's "convince me that
I should *use* this package".

> As such, I think the revised description is perfectly acceptable for
> Debian.

- --
Ron Johnson, Jr.
Jefferson LA  USA

"(Women are) like compilers.  They take simple statements and
make them into big productions."
Pitr Dubovitch
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHx2uvS9HxQb37XmcRAr1AAJ4nDwIq9qtaFcqcFtaBV8yHC2SobQCeMkV3
8QEs/+nTqEO7w7vs3mvH4IU=
=h3uZ
-END PGP SIGNATURE-


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

Re: Bug#467097: ITP: eficas -- ASter Command FIle Editor

[Ben Hutchings]

On Sat, 2008-02-23 at 10:09 +0100, Guus Sliepen wrote:
> On Sat, Feb 23, 2008 at 01:41:05AM +0100, Sylvestre Ledru wrote:
> 
> >   Upstream Author : EDF / R&D
> 
> Please include the full name of the author(s).


EDF is the usual name of the company whose logo appears on the upstream
web site .  (The initials used to stand for
Electricité de France, but the company has diversified and no longer
expands the initials.)

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.


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

Re: How to cope with patches sanely

[Sam Vilain]

Manoj Srivastava wrote:
>> Yes.  Feature branches are effectively forking a particular version of
>> a project - this is not a problem, and is essential for efficient
>> development.  People jumbling together changes in "trunk" branches is
>> perhaps one of the worst upshots of the 2002-2006 or so obsession with
>> poorly designed centralised systems and in my opinion sank many
>> projects.
> 
> Err. If you go back and read this thread in the archive, You'll
>  note that I have stated that my feature branches are always kept up to
>  date with the latest upstream branch I am basing my Debian package
>  on. 

This technique is also called rebasing the patch set; it's fine, but
it's just one approach.

> When I have been creating patches for inclusion with upstream, I
>  essentially feed them the source patch and a changelog entry --
>  essentially, creating a single patch series; squashing the underlying
>  history.  Most upstream do not care about the messy history of my
>  development; and most do not grok arch well enough to pull directly.

This is sometimes worthwhile and sometimes a bad idea.  The driving
motive, if you want to aim for patches to be easily reviewed, is that
each patch should introduce a single change, which is well explained.  I
agree that the upstream will not want a messy history; which is why you
reshape the individual changes using a tool such as Quilt, Stacked Git,
Guilt, Mercurial Queues, etc, so that they are more easily reviewed.

>> They mean that a later merge back the other way, to merge the feature
>> branch into the target branch, can happen painlessly.  ASSUMING that
>> you're using a system which has commutative merge characteristics,
>> such as git or mercurial.
> 
> I use Arch.

Arch is critically deficient in this respect; it doesn't really have a
concept of tracking branches, and merging is not commutative; if you
merge a branch that just merged from your branch, an unnecessary new
changeset is made.  But if you are rebasing then you don't need to worry
about that.  As I said, it's just more work.

>> Can you express this problem with reference to a particular history of
>> an integration branch?  I will provide some short git commands to
>> extract the information in the form you are after.
> 
>  http://arch.debian.org/cgi-bin/archzoom.cgi/[EMAIL PROTECTED]
> 
> Take any package. Say, flex. Or flex-old. You have all my
>  feature branches there. The --devo branch is the integration branch.
>  Please show me an automated way you can grab the feature branches and
>  generate a quilt series that gives you the devo branch.  The diff.gz is
>  how we get from upstream to the devo branch (modulo ./debian); if you
>  can break that down nicely for the folks who want each feature
>  separate, that would work as well.

Thanks for restating the problem clearly.  While the underlying problem
is easily approached and I would still call it trivial, the details of
what you are asking for make it impossible - because quilt series cannot
contain merges (someone correct me here if it can and I can go forward).

Shipping changes for upstream inclusion as a *single* set of quilt
patches is not possible if you are including merges, but if you allow
the patches to be grouped, and introduce a new type of patch which
encapsulates a merge (gitk has one example of this; it uses different
identifiers to represent which file's lines are included), then it can
be done.  The apply-patches script would need extending to support this,
but I don't think that's particularly show-stopping.

However, ignoring the merges, so far we're not that far away from the
"script" being 'git-log -p' or 'git format-patch upstreamrev'

Also having never really used arch, if you can provide me with the
commands to get a copy of those branches (the man page is sadly not very
forthcoming), and I'll give the git-archimport script a whorl and see if
I can get it imported and show how this can work in practice.  If
someone with git-archimport experience can perform this and publish the
repositories somewhere, I'd be very grateful.

>  If you code works well enough every single time a new upstream
> comes around and I release a new version of flex or whatever,  I'll
> throw in the generated quilt patches.

I think what is required is a rethink of the problem.  What is being
tried to be achieved, and are there any other ways to achieve it which
will solve the problem in a vastly more effective way.

Version control systems that have content-addressable filesystems
(essentially, git and Monotone) are inherently efficient to distribute;
as only the changes between versions need be distributed.  The notion of
stream compressing tarballs is archaic compared with being able to
search for deltas anywhere in the source tree.

You can see this in effect with git, which is capable of very quickly
identifying which objects are new, and sending them all in impressively
small packs on the network.  

Re: How to cope with patches sanely

[Manoj Srivastava]

On Fri, 29 Feb 2008 16:11:48 +1300, Sam Vilain <[EMAIL PROTECTED]> said: 

> Manoj Srivastava wrote:
>>> Yes.  Feature branches are effectively forking a particular version
>>> of a project - this is not a problem, and is essential for efficient
>>> development.  People jumbling together changes in "trunk" branches
>>> is perhaps one of the worst upshots of the 2002-2006 or so obsession
>>> with poorly designed centralised systems and in my opinion sank many
>>> projects.
>> 
>> Err. If you go back and read this thread in the archive, You'll note
>> that I have stated that my feature branches are always kept up to
>> date with the latest upstream branch I am basing my Debian package
>> on.

> This technique is also called rebasing the patch set; it's fine, but
> it's just one approach.

Actually, that is not it. I am not rebasing -- I am doing
 repeated merges. Arch does not rebase -- it just applies  the upstream
 delta, with full history. This allows me to replay into the integration
 branch at will.

>> When I have been creating patches for inclusion with upstream, I
>> essentially feed them the source patch and a changelog entry --
>> essentially, creating a single patch series; squashing the underlying
>> history.  Most upstream do not care about the messy history of my
>> development; and most do not grok arch well enough to pull directly.

> This is sometimes worthwhile and sometimes a bad idea.  The driving
> motive, if you want to aim for patches to be easily reviewed, is that
> each patch should introduce a single change, which is well explained.
> I agree that the upstream will not want a messy history; which is why
> you reshape the individual changes using a tool such as Quilt, Stacked
> Git, Guilt, Mercurial Queues, etc, so that they are more easily
> reviewed.

I can do this by cherry picking the chnages from my topic
 branch, and feeding it separately. Emacs and diff mode makes it easy to
 split off chunks if I want to do it after the fact from the squashed
 diff; or I can regenerate changesets and cherry pick the series.

And no, I can do this using plain old arch, and I don't really
 have to change my SCM.


>>> They mean that a later merge back the other way, to merge the
>>> feature branch into the target branch, can happen painlessly.
>>> ASSUMING that you're using a system which has commutative merge
>>> characteristics, such as git or mercurial.
>> 
>> I use Arch.

> Arch is critically deficient in this respect; it doesn't really have a
> concept of tracking branches, and merging is not commutative; if you
> merge a branch that just merged from your branch, an unnecessary new
> changeset is made.  But if you are rebasing then you don't need to
> worry about that.  As I said, it's just more work.

Which is why we have sync-tree. Yes, I have to keep track myself
 of which delta I am  currently merging; and only apply a merge once
 into each branch; and immedately syn-tree with the other branches.

And since it is all in one fully automated script, called
 arch_upgrade, that takes any new upstream, updates all my topic branches
 and my integration branch automatically, I don't see this as much more
 work. 

Indeed, I have yet to see any porcelain that makes merging  a
 new upstream commit into all my topic branches and the integration
 branch as a single operation, I suspect that it is more work in git; at
 least until I can replicate my arch scaffolding for the git porcelain. 

>>> Can you express this problem with reference to a particular history
>>> of an integration branch?  I will provide some short git commands to
>>> extract the information in the form you are after.
>> 
>> http://arch.debian.org/cgi-bin/archzoom.cgi/[EMAIL PROTECTED]> 
>> Take any package. Say, flex. Or flex-old. You have all my feature
>> branches there. The --devo branch is the integration branch.  Please
>> show me an automated way you can grab the feature branches and
>> generate a quilt series that gives you the devo branch.  The diff.gz
>> is how we get from upstream to the devo branch (modulo ./debian); if
>> you can break that down nicely for the folks who want each feature
>> separate, that would work as well.

> Thanks for restating the problem clearly.  While the underlying
> problem is easily approached and I would still call it trivial, the
> details of what you are asking for make it impossible - because quilt
> series cannot contain merges (someone correct me here if it can and I
> can go forward).

I don't use quilt, so I am not the one to answer this.

> Shipping changes for upstream inclusion as a *single* set of quilt
> patches is not possible if you are including merges, but if you allow
> the patches to be grouped, and introduce a new type of patch which
> encapsulates a merge (gitk has one example of this; it uses different
> identifiers to represent which file's lines are included), then it can
> be done.  The apply-patches script wo

Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol

[Steve Langasek]

On Thu, Feb 28, 2008 at 08:02:39PM -0600, William Pitcock wrote:
> Debian is about having the possibility of choosing between many options
> for the same thing

No, Debian is *about* having a *good*, free operating system.

Having lots of choices is a side effect of Debian's organization, it's not
what Debian is *about*.

> Why does a package need to clarify what's different about it than others
> like it? 

Er, if that's not explained, how in the world is any user supposed to make a
choice among the options?

If there's no difference among the options, why should we release all of
them, adding to the security and QA burden of the distribution?

> It seems to me as if you are trying to get people to justify the
> packages they want to work on.

No - only to justify the inclusion of those packages in Debian.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

Re: Bits from DEHS

[Steve Langasek]

On Thu, Jan 24, 2008 at 09:07:07PM -0600, Raphael Geissert wrote:

> * New upstream version notifications
> Since yesterday DEHS started sending notifications to the 'summary'
> tag/keyword of the PTS when it finds a new upstream version.

Was this blessed by the PTS admins before it was deployed?

I find it completely pointless to have DEHS telling me about new upstream
releases of packages I maintain.  I already track upstream mailing lists for
my packages, and have no interest in being bombarded with automatic notices
of this kind.  But to my dismay, not only are these messages being sent
using a PTS keyword that's enabled by maintainers by default, they're being
sent using a PTS keyword that was already being used for other, relevant
notices that I *can't* subscribe to elsewhere.

So now I have to choose between not receiving notifications when my packages
transition to testing, or having to filter out messages locally that I never
asked to receive; and I have to actively opt out of these DEHS mails that
should be completely redundant for any maintainer who is already tracking
upstream as they ought.  I understand that this is an easy way to enable
maintainers to track upstream releases when they aren't already, but for
those of us who are already involved with upstream it's completely
redundant.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

Re: Bits from DEHS

[Raphael Hertzog]

On Thu, 28 Feb 2008, Steve Langasek wrote:
> On Thu, Jan 24, 2008 at 09:07:07PM -0600, Raphael Geissert wrote:
> 
> > * New upstream version notifications
> > Since yesterday DEHS started sending notifications to the 'summary'
> > tag/keyword of the PTS when it finds a new upstream version.
> 
> Was this blessed by the PTS admins before it was deployed?

Yes, in fact I asked to reuse summary instead of creating a new keyword.

My logic was the following: summary mails only contains the testing
transition mails that are sent both to the maintainer and to the PTS.
Given that the maintainer already receives those notices, he's probably
not subscribed to the summary keyword.

Why doesn't that work in your case?

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Bug#468462: ITP: lmt -- lustre monitoring tool

[Patrick Winnertz]

Package: wnpp
Severity: wishlist
Owner: Patrick Winnertz <[EMAIL PROTECTED]>

* Package name: lmt
  Version : 2.1.0-1chaos
* URL : http://sourceforge.net/projects/lmt/
* License : GPL
  Programming Lang: Python
  Description : lustre monitoring tool

LMT is a Lustre Monitoring Tool, which shows the activity levels of of
the server side notes (OSS, MDS, MGS and portal routers) in a top-like
manner.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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

Work-needing packages report for Feb 29, 2008

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 353 (new: 3)
Total number of packages offered up for adoption: 89 (new: 1)
Total number of packages requested help for: 36 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   apollon (#467091), orphaned 6 days ago
 Description: KDE-based interface to giFT file-sharing system
 Installations reported by Popcon: 465

   c-sig (#467092), orphaned 6 days ago
 Description: A signature tool for GNU Emacs
 Installations reported by Popcon: 37

   libsvg (#467632), orphaned 2 days ago
 Description: library for parsing SVG files
 Reverse Depends: libsvg-dev
 Installations reported by Popcon: 1051

350 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   modconf (#467584), offered 2 days ago
 Description: Device Driver Configuration
 Reverse Depends: pppoeconf
 Installations reported by Popcon: 8509

88 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] k3b (#468314), requested today
 Description: A sophisticated KDE CD burning application
 Reverse Depends: k3b k3b-i18n libk3b-dev
 Installations reported by Popcon: 13440

   aboot (#315592), requested 980 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-client-core
 Installations reported by Popcon: 127

   apt-build (#365427), requested 670 days ago
 Description: Need new developer(s)
 Installations reported by Popcon: 983

   ara (#450876), requested 109 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 112

   athcool (#278442), requested 1220 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 267

   cfs (#458061), requested 62 days ago
 Description: Cryptographic Filesystem
 Installations reported by Popcon: 118

   cvs (#354176), requested 735 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta cvsps (13 more
   omitted)
 Installations reported by Popcon: 22893

   dctrl-tools (#448284), requested 124 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: debian-goodies dlocate feta haskell-devscripts
   hg-buildpackage mlmmj sbuild simple-cdd
 Installations reported by Popcon: 6093

   dpkg (#282283), requested 1195 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc build-essential bzr-builddeb clamsmtp crosshurd (107 more
   omitted)
 Installations reported by Popcon: 75928

   drscheme (#402589), requested 444 days ago
 Description: PLT scheme programming environment
 Reverse Depends: drscheme minlog proofgeneral-minlog
 Installations reported by Popcon: 375

   elvis (#432298), requested 234 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 310

   fglrx-driver (#454993), requested 82 days ago (non-free)
 Description: non-free AMD/ATI r5xx, r6xx display driver
 Reverse Depends: fglrx-amdcccle fglrx-control fglrx-driver fglrx-glx
 Installations reported by Popcon: 2255

   gentoo (#422498), requested 298 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 289

   grub (#248397), requested 1389 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: dfsbuild grub-doc replicator startupmanager
 Installations reported by Popcon: 69973

   imagemagick (#452314), requested 99 days ago
 Description: Image manipulation programs
 Reverse Depends: advi-examples afterstep album ale ascd asymptote
   bins cimg-dev curator dblatex (78 more omitted)
 Installations reported by Popcon: 23398

   ispell-et (#391105), requested 512 days ago
 Description: Estonian dictionary for Aspell/Ispell/MySpell
 Installations reported by Popcon: 56

   lirc (#364606), requested 675 days ago
 

Re: FW by [EMAIL PROTECTED] : Bug#467249: man-db: over sensitive on the spell of locale

[Petter Reinholdtsen]

[Michelle Konzack]
> Hello Maintainers,
>
> It seems there is a common problem while setting up the correct UNICODE
> locale in systems.  As the posster in the attached message has written,
> he has setup his locale to "zh_CN.utf8" which is wrong, but as he has
> written too, the output of "locale -a" show it.

'locale -a' do not show that the locale is working, it just show what
is set in the environment.  Use 'locale charmap' to check that the
locale is working and that the correct character set is selected.  If
it return 'ANSI_X3.4-1968' (which is ASCII), the locale isn't working
(unless it is a locale that uses ASCII, not very likely).  If it show
'UTF-8', the locale settings are working.

In the case you describe, I believe the only fix is to get the user to
stop using an invalid and non-existing locale, and instead use the
correct locale string, which I would suspect is 'zh_CN.UTF-8'.  The
only workaround to this would be to rewrite glibc and locales, and it
does not seem useful to me.

Happy hacking,
-- 
Petter Reinholdtsen


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