Re: On maintainers not responding to bugs

[Josselin Mouette]

Le mercredi 28 février 2007 à 02:02 +0100, Eduard Bloch a écrit :
> #include 
> * Josselin Mouette [Tue, Feb 27 2007, 10:30:39AM]:
> > Le mardi 27 février 2007 à 09:24 +0100, Eduard Bloch a écrit :
> > > And how do you help a maintainer that does not admit that he needs help?
> > 
> > I can't believe people are thinking such crap.
> > 
> > Please show me where a current maintainer of Mozilla, KDE, GNOME, the
> > glibc, the kernel, X.org or any such big group of packages said he
> > didn't need help for them.

> > Who is not acknowledging such obvious things?
> 
> Dunno. I think you confused the subthreads when replying here.
> As usual somebody needs to make the hands dirty and deal with the old
> odd bug reports. And yes, I know that my talk here does not help but I
> have no time to help either so I am stopping here.

I'm not the one who said maintainers don't admit they need help.

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

Re: On maintainers not responding to bugs

[Stefano Zacchiroli]

On Mon, Feb 26, 2007 at 09:51:13PM -0500, Joey Hess wrote:
> maintainers not always responsing to bugs, then probably the simplest
> thing to do would be to code up a view in the BTS that lists bugs that
> have not had a maintainer response (filtering out responses that appear
> to be from the bug submitter, or filtering out all responses not from a
> given email, or something reasonable). If I had an easy[1] way to see

More generally, I would say a view in which the bugs are sorted in
reverse order of last activity; with activity defined either as
"received mail from anyone" or "mail from the maintainer(s)".

I have no clue about the code of the web interface of the bts, but I can
try to mock-up a sorting criterion to be integrated in the "bts"
devscript.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Bug#412704: ITP: ocaml-ao -- OCaml bindings for libao

[Stefano Zacchiroli]

On Tue, Feb 27, 2007 at 04:07:37PM +0100, Romain Beauxis wrote:
> Owner: Samuel Mimram <[EMAIL PROTECTED]>

Given this, I guess you're already familiar with what I'm going to say,
but better safe then sorry ...

> OCaml bindings for the cross platform audio output library.

Please Cc: [EMAIL PROTECTED] for ITP of OCaml-related packages
and ensure your package conforms to the OCaml packaging policy [1]
before uploading or asking for sponsorship.

Cheers.

[1] http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.html/

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: On maintainers not responding to bugs

[Hamish Moffatt]

On Mon, Feb 26, 2007 at 03:41:57PM -0700, Warren Turkal wrote:
> This is from the perspective of a non-DD systems administrator. While most 
> maintainers are good. Some are pretty lousy with regard to addressing issue 
> even when one is proactive about finding a solution.
> 
> On Monday 26 February 2007 14:55, Don Armstrong wrote:
> > I don't believe any maintainer of
> > packages, given enough hours in the day, would fail to respond to
> > reasonable bug reports.
> 
> I don't agree with this statement. I have dealt with some maintainers that 
> refuse to acknowledge a bug when I report it. At the worst, the maintainer 
> makes some wild assumption and code dumps a new revision of their package. 
> That action causes me to have to totally work around their packages to make 
> things work.
> 
> The aoetools package is a fine example of this phenomenon. I have to 
> completely override what that package does with it's init script to get my 
> aoe devices working. [1] is a good example of a maintainer refusing to 
> acknowledge any level of my trying to help find a solution for a bug. 

In all fairness, you didn't seem to comment on his response to your
suggestion. 
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387552;msg=30;att=0).
This seems to be more of a case of not liking his solution than having a
legitimate grievance?

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


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

Re: 0-day bug forwarding and bug patching on ALL bugs

[Stefano Zacchiroli]

On Tue, Feb 27, 2007 at 08:46:11PM +0100, Wouter Verhelst wrote:
> (and hopefully this madness will now stop)

We all know everyone can triage/patch/... whatever bug in the BTS.

Still, if some team feels they are understaffed and that they need
triaging help since they are becoming overwhelmed by their bugs, then
it's legitimate to ask for help on -devel.  It's not that different in
principle than tagging bugs +help, with the exception that this need to
be done before even touching the bug reports.

Of course that need to be done with a grain of salt, and I personally
found not particularly wise to chain three help requests in a row after
the first one, but that's totally.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: 0-day bug forwarding and bug patching on ALL bugs

[Stefano Zacchiroli]

On Wed, Feb 28, 2007 at 09:20:57AM +0100, Stefano Zacchiroli wrote:
> Of course that need to be done with a grain of salt, and I personally
> found not particularly wise to chain three help requests in a row after
> the first one, but that's totally.
   ^
   \- "IMO" missing here.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: 0-day bug forwarding and bug patching on ALL bugs

[Bernhard R. Link]

* Wouter Verhelst <[EMAIL PROTECTED]> [070227 20:46]:
> You've read this correctly!  Starting TEN YEARS AGO, we are in
> permanent bug triaging, bug forwarding, but patching party on ALL
> bugs, pick one before it's too late!
>
> You may immediately take any bugs which didn't receive due care and
> forward it upstream and/or send a patch to it and/or request more
> information.

I think there are two problems here:

First problem is that the list misses the most important stuff. It's no
fun to look at bugs when the bug-list is a utter mess. What is needed
is someone
- retitling the bug-report to properly describe the problem
- tag bugs to get clear view (when there are many bugs):
- what has enough information to reproduce it
- what has not (even more important)
- what are upstream issues
- closing fixed bugs
- closing things that are obviously no bugs
- reassigning bugs to where the problem is
This is all best done in a coordinated way. But it needs to be done
anyway. Otherwise suggesting "you may forward it upstream and/or send a patch"
is a bad joke.

The other problem is that your sentence contained a "didn't recevice due
care". Many people are a bit reluctant to imply something like that.
What about something like the low-treshold-nmu page for bugs? That may
be both be usefull as a indicator where people wanting to help can help
and as way to allow people also the things from the list above.

Hochachtungsvoll,
Bernhard R. Link


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

how to request help for bugs (Re: 0-day bug forwarding and bug patching on ALL bugs)

[Bart Martens]

On Wed, 2007-02-28 at 09:20 +0100, Stefano Zacchiroli wrote:
> On Tue, Feb 27, 2007 at 08:46:11PM +0100, Wouter Verhelst wrote:
> > (and hopefully this madness will now stop)
> 
> We all know everyone can triage/patch/... whatever bug in the BTS.

Yes of course.

> 
> Still, if some team feels they are understaffed and that they need
> triaging help since they are becoming overwhelmed by their bugs, then
> it's legitimate to ask for help on -devel.  

True, but I would contact -devel for specific bugs with specific
techical questions.

For a general call/cry for help for packages with many bugs, I would
submit an RFH, RFA or O before the number of bugs becomes uncomfortable.
Of course, this probably won't work for all packages; it's not always so
simple.

> It's not that different in
> principle than tagging bugs +help, with the exception that this need to
> be done before even touching the bug reports.

I use the bug tag "help" for bugs I have studied and I don't know how to
fix.  This is in my opinion different than handling many unprocessed
bugs.



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

who forwards bugs to upstream (Re: 0-day bug forwarding and bug patching on ALL bugs)

[Bart Martens]

On Wed, 2007-02-28 at 09:35 +0100, Bernhard R. Link wrote:
> * Wouter Verhelst <[EMAIL PROTECTED]> [070227 20:46]:
> > You've read this correctly!  Starting TEN YEARS AGO, we are in
> > permanent bug triaging, bug forwarding, but patching party on ALL
> > bugs, pick one before it's too late!
> >
> > You may immediately take any bugs which didn't receive due care and
> > forward it upstream and/or send a patch to it and/or request more
> > information.

> suggesting "you may forward it upstream and/or send a patch"
> is a bad joke.

It feels perfectly allright to me that anyone is allowed to do this
without first consulting the debian package maintainer.  Especially for
packages with many unprocessed bugs.  But also for any of the packages I
maintain (although I try to be fast enough to do the triaging myself).



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

Re: 0-day bug forwarding and bug patching on ALL bugs

[Sune Vuorela]

On 2007-02-28, Bernhard R. Link <[EMAIL PROTECTED]> wrote:
> anyway. Otherwise suggesting "you may forward it upstream and/or send a patch"
> is a bad joke.

Why is it a bad joke ?

let us take `kmail' - it has around 2500 bugs in the upstream bugzilla -
and 100 bugs not forwarded in debian. 
In order to forward those 100 bugs upstream is just a matter of finding
the right bug in the kde bugzilla.  You don't have to be package
maintainer for that.

/Sune


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

KD 39303 Webshop Bestellung 27.02.2007

[TMS Logistik]

Guten Tag,

Vielen Dank fur Ihre Bestellung!

Die von Ihnen bestellten Waren sind vollstandig am Lager und werden umgehend
durch die Logistikabteilung an Sie versandt.

http://tanknk.dothome.co.kr

Um eine schnellstmogliche Bearbeitung Ihre Ruckfragen gewahrleisten zu
konnen,
bitten wir Sie bei Ruckfragen immer Ihre Kundennummer 39303 und
Belegnummer [3816712] anzugeben.


Vielen Dank

Mit freundlichem Grub

Eberhard Schmidt

TMS Logistik GmbH

Call Center:
tel (0180) 31 57 16 21 - 0,09 EUR/min aus dem dt. Festnetz/T-Com
fax (030) 90 16 - 29 19
web www.tms-logistik.de

Niederlassung Berlin
Albrechstrasse 117
D-01271 Berlin


--

 Auf den Punkt gebracht - Ihre Vorteile als TMS Logistik Kunde

--


 o 14 Tage Ruckgaberecht fur originalverpackte Neuware
 o Beratung durch unsere Fachverkaufer
 o Transparente Preisgestaltung und Verfugbarkeitsanzeige
 o Rundumschutz durch optionales Servicepaket
 o Kostenfreie Parkplatze
 o Bequeme Zusendung durch uns oder DHL moglich
 o Kostenfreier 80-seitiger Gesamtkatalog - auch per Post nach Hause


--

 TMS Logistik - seit 12 Jahren erfolgreich in Berlin

--


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

Re: how to request help for bugs (Re: 0-day bug forwarding and bug patching on ALL bugs)

[Roberto C. Sanchez]

On Wed, Feb 28, 2007 at 11:39:54AM +0100, Bart Martens wrote:
> 
> For a general call/cry for help for packages with many bugs, I would
> submit an RFH, RFA or O before the number of bugs becomes uncomfortable.
> Of course, this probably won't work for all packages; it's not always so
> simple.
> 
I would think that orphaning would be the wrong way to go.  If the
maintainer has some, but perhaps not enough, time to work on it and just
needs help, I think he is more likely to find someone is willing to
pitch in and help get the package shaped up.  Orphaning the package has
the potential to leave things worse off.  Now, if the package has sat
untouched for a very long time and accumulated many bugs, that may be
the only option.

Regards,

-Roberto

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


signature.asc
Description: Digital signature

On management

[Josselin Mouette]

Hi,

it is certainly a bit too early to look back at the etch release
process, as we still haven't released yet, but I'd like to share some
thoughts on what happened. Please note that these are entirely personal
views.

Back in September, it seemed impossible to the GNOME team to bring GNOME
2.16 into a releasable state before the planned release date. We took
then the hard decision to keep GNOME 2.14 and bring only the few parts
of 2.16 that weren't disruptive (meaning especially, no gtk+ 2.10 and no
gnome-vfs transition to dbus).

It should be obvious now that, with the delays the release is facing,
this decision was wrong. With the icon themes fixing, I think the last
showstopper for GNOME 2.16 is now fixed. Of course, at the time it
became clear it would be possible to polish 2.16 before the release, the
distribution was already frozen. The result is, we have a desktop with
less bugs, more features and speed improvements, which is almost
completely ready (apart from evince) for the upcoming stable release,
and it's not going to be shipped. Currently it is only used by a handful
of people running experimental. As GNOME 2.18 is scheduled in two
months, this means we will be lagging two versions behind upstream as
soon as we have released.

Not only did it generate more work as we had two GNOME versions to
maintain during the freeze, but it is now generating a lot of
frustration because this extra work looks like a loss of time.

It is my belief that such things could be avoided if we had proper
release management. Don't get me wrong: I'm not trying to throw stones
at the release team, especially because I couldn't have done better
myself, and because I'm partly responsible for the GNOME decision. The
release team is doing an excellent job; unfortunately this job isn't
about management, but about technical expertise. Of course this is
helping the release, but I wouldn't call it "management". Fixing RC bugs
is a thing, setting release goals and dates depending on lots of
people's work is another.

Management is quite a different job that what most of us are doing. In
the real world, a good manager is as rare a resource as a good engineer,
and you need both to make a business running. The Debian project is
currently good at attracting technically excellent people, but we also
need a few people with management skills, and currently I fail to see
what could bring them to work for the project.

As of now, I see it as a failure of the project. But this is also
nothing that can't be fixed. What do you people think could be done to
bring the skills we are lacking to the project, with its current
structure?

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


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

Re: On management

[Steinar H. Gunderson]

On Wed, Feb 28, 2007 at 02:58:12PM +0100, Josselin Mouette wrote:
> It should be obvious now that, with the delays the release is facing,
> this decision was wrong.

I'm not so sure. By not trying to push 2.16 in, you've probably been creating
a lot less work for the release team than if you were to push in 2.16 and
then ask for hinting in new stuff through the freeze.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: On management

[Roberto C. Sanchez]

On Wed, Feb 28, 2007 at 02:58:12PM +0100, Josselin Mouette wrote:
> 
> Management is quite a different job that what most of us are doing. In
> the real world, a good manager is as rare a resource as a good engineer,
> and you need both to make a business running. The Debian project is
> currently good at attracting technically excellent people, but we also
> need a few people with management skills, and currently I fail to see
> what could bring them to work for the project.
> 
I would think that the same things that attract a technical individual
could attract a non-technical individual.  Desire to learn.  Desire to
contribute.  Desire to build skills for resume or future employment.
And so on.  The thing is that the current NM process is heavily biased
toward technical people/programmers/developers/etc.  That is probably a
discouragement to people who are more management oriented.

Add to that the fact that the people in leadership and management roles
in Debian now started out as developers and moved up.  Someone with
management might look and think "I have the management skill, but I
can't cut it in a technical role for three or four or whatever years to
get that far in the project."

I am not criticizing the current arrangement, I just think that if it is
to become a goal to attract more skilled management-types, we need to
create a sort of management track for new contributors.

Regards,

-Roberto

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


signature.asc
Description: Digital signature

Re: how to request help for bugs (Re: 0-day bug forwarding and bug patching on ALL bugs)

[Bart Martens]

On Wed, 2007-02-28 at 08:51 -0500, Roberto C. Sanchez wrote:
> On Wed, Feb 28, 2007 at 11:39:54AM +0100, Bart Martens wrote:
> > 
> > For a general call/cry for help for packages with many bugs, I would
> > submit an RFH, RFA or O before the number of bugs becomes uncomfortable.
> > Of course, this probably won't work for all packages; it's not always so
> > simple.
> > 
> I would think that orphaning would be the wrong way to go.  

I didn't say that packages with many bugs should be orphaned. :)
Obviously a package should be orphaned if it is no longer maintained,
and only then.

What I meant to say is that the maintainer him/herself should
voluntarily "submit an RFH, RFA or O before the number of bugs becomes
uncomfortable".

> If the
> maintainer has some, but perhaps not enough, time to work on it and just
> needs help, I think he is more likely to find someone is willing to
> pitch in and help get the package shaped up.  

Yes, that's what I meant with RFH, see above.

> Orphaning the package has
> the potential to leave things worse off.  

Orphaning an unmaintained package invites new maintainers to adopt the
package.

> Now, if the package has sat
> untouched for a very long time and accumulated many bugs, that may be
> the only option.

Yes, I agree with that.

So I think that we have +/- the same opinion about when a package should
be orphaned.



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

Re: On management

[Marc 'HE' Brockschmidt]

Heya,

I certainly agree with some of things you said, as I also believe that
Debian could profit from better management and/or planning in some
areas, I don't think this would have made the timely release of etch
possible.

Josselin Mouette <[EMAIL PROTECTED]> writes:
> Back in September, it seemed impossible to the GNOME team to bring GNOME
> 2.16 into a releasable state before the planned release date. We took
> then the hard decision to keep GNOME 2.14 and bring only the few parts
> of 2.16 that weren't disruptive (meaning especially, no gtk+ 2.10 and no
> gnome-vfs transition to dbus).
>
> It should be obvious now that, with the delays the release is facing,
> this decision was wrong. With the icon themes fixing, I think the last
> showstopper for GNOME 2.16 is now fixed.

The point is that pushing Gnome 2.16 into the release would have taken
even more time from the release team (and you and other maintainers), so
that we would release at an even later point. And then the KDE team
would come up and say that KDE 3.5.6 would be nice to have in etch. And
XFCE 4.4 was also released recently, so we should probably have included
it too. And by that point, etch would have been so late that Gnome 2.18
would be a candidate...

> Of course, at the time it became clear it would be possible to polish
> 2.16 before the release, the distribution was already frozen. The
> result is, we have a desktop with less bugs, more features and speed
> improvements, which is almost completely ready (apart from evince) for
> the upcoming stable release, and it's not going to be
> shipped. Currently it is only used by a handful of people running
> experimental.

Right. The problem is that a large number of users would find a large
number of bugs, which would show unexpected problems.

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
173: Ada
   Ada ist der gelungene Versuch, die Schwächen von C, Pascal und
   Fortran in einer Sprache zu vereinigen. (Holger Spielmann)


pgph7V8KLtYy0.pgp
Description: PGP signature

Re: On management

[Clint Adams]

> I would think that the same things that attract a technical individual
> could attract a non-technical individual.  Desire to learn.  Desire to
> contribute.  Desire to build skills for resume or future employment.
> And so on.  The thing is that the current NM process is heavily biased
> toward technical people/programmers/developers/etc.  That is probably a
> discouragement to people who are more management oriented.

I'm not sure what you're advocating, but in my experience, project
managers without the capacity to understand the technical issues of the
project that they are supposed to be managing are worse than useless.


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

Re: On management

[Roberto C. Sanchez]

On Wed, Feb 28, 2007 at 10:31:37AM -0500, Clint Adams wrote:
> > I would think that the same things that attract a technical individual
> > could attract a non-technical individual.  Desire to learn.  Desire to
> > contribute.  Desire to build skills for resume or future employment.
> > And so on.  The thing is that the current NM process is heavily biased
> > toward technical people/programmers/developers/etc.  That is probably a
> > discouragement to people who are more management oriented.
> 
> I'm not sure what you're advocating, but in my experience, project
> managers without the capacity to understand the technical issues of the
> project that they are supposed to be managing are worse than useless.
> 
I am not advocating having a manager without technical competency or the
ability to understand technical issues.  Just that being a manager does
not require being a fourth-degree blackbelt in Perl or having written a
textbook on C++ programming.  The point is that there are people who
understand the technical issues but are much more adept managers.  All I
am saying is that the current NM process (I am just at the tail end of
it now) is heavily biased toward those with a strong interest in
programming, system administration, and so on.  I know that some people
become DDs to work on documentation (a very important and thankless
job), but they are by far the exception and not the rule.

Regards,

-Roberto

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


signature.asc
Description: Digital signature

incorrect path to locales? (might be rc)

[Yaroslav Halchenko]

Dear All,

I am packaging remake and found out that I could not enable messaging in
other locales... I've tested on make -- the same story... it seems that
libc6 looks for /usr/lib/locale/ whenever it should look under
/usr/share/locale/. 

Pardon my ignorance if I am saying something RTFM since I wonder how this could
slipped through (also glancing over bugs of libc6 didn't show similar
issue), so I decided first to ask if I am right in my suspicion

Here is a "log" of actions from etchy box (same behavior is on another sid box)

,
| *$> LC_MESSAGES=ko strace -fF -o /tmp/make.strace make
| make: *** No targets specified and no makefile found.  Stop.
|
| $> grep locale /tmp/make.strace
| 3003  open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
| 3003  open("/usr/share/locale/locale.alias", O_RDONLY) = 3
| 3003  open("/usr/lib/locale/ko/LC_MESSAGES", O_RDONLY) = -1 ENOENT (No such 
file or directory)
|
| $> ls -ld /usr/{share,lib}/locale/ko/LC_MESSAGES
| ls: /usr/lib/locale/ko/LC_MESSAGES: No such file or directory
| 4 drwxr-xr-x 2 root root 4064 2007-02-09 17:42 
/usr/share/locale/ko/LC_MESSAGES
`---

-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]



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

Re: incorrect path to locales? (might be rc)

[Pierre Habouzit]

On Wed, Feb 28, 2007 at 10:39:25AM -0500, Yaroslav Halchenko wrote:
> ,
> | *$> LC_MESSAGES=ko strace -fF -o /tmp/make.strace make
> | make: *** No targets specified and no makefile found.  Stop.

  that's because ko is not a valid locale specifier.

$ LC_MESSAGES=ko_KR.utf8 make
make: *** 타겟이 지정되지 않았고 메이크파일이 없습니다.  멈춤.


  You can get valid locale specifier that work on your system with
locale -a.

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


pgpIt6RuoNG8h.pgp
Description: PGP signature

Re: On maintainers not responding to bugs

[Eduard Bloch]

#include 
* Loïc Minier [Tue, Feb 27 2007, 06:51:05PM]:
> On Tue, Feb 27, 2007, Eduard Bloch wrote:
> > >  I already warned you about this privately in december; here's another
> > "Warn"? You feel the need to warn me? Does bringing me to STFU make you
> > happy or so?
> 
>  No; I warned you not to put everybody in the same bag in the same
>  pointless discussion that was happening back then about maintainer not
>  applying patches timely.
>  The proposals you made in this thread do not match the attitude you
>  follow yourself...

"put everybody into the same bag"? Jeez, what else are you interpreting
into it?

> > Nice game. Pointless attempt to create a "who wants to throw the first
> > stone" situation. Looking at your dirty clothes:
> > 401095 359033 371694 372127 372611 373277 375904 403194
> > What about them? Now don't tell me "It is okay the package was adopted
> > from other bad maintainer". I adopted some bug hives too.
> 
>  You could _at least_ search for good examples.  First, most of the bugs

That is what BTS reported on a quick request. But it seems like you
maintain only few simple packages. As you can imagine it is hard to look
for "optimal" examples there.

>  your took are from Galeon which is RFAed /and/ obsolete; second, these
>  bugs do not have patches; third, I AM NOT THE ONE WHO ARGUES THAT
>  MAINTAINERS SHOULD RESPOND TO ALL BUGS, remember: it's you.

Yeah. Keep constructing bogus arguments.

>  You're the guy who's been complaining about "the maintainer is doing
>  uploads but only for bugs that have RC priority or important" and
>  proposed the "solution shall be setting some RC priority to all bugs
>  then".

Oh boy. Now I see what you are on. Please tune your irony detector and
guess why I added a comment after the last statement.

>  Back in december, you were also pestering about "maintainers that
>  prefer to let such bug reports rot instead of tagging them", and back
>  then I already sent you another list of bug reports to which you did
>  not bother replying to for MONTHS, even bugs _I_ filed, _with patches_.
> 
>  And the worse is that you are upstream for most of the bugs I quoted.

That is worse? Have you ever considered that I get more bug reports
because I am upstream and the Debian BTS catches both, upstream and
Debian related problems?

Apparently not. You prefer to play with simple packages and only
packagement problems where you can come and close lots of bugs with
simple changes. At least this is my impression looking at the attitude
shining through.

>  So, yes, please, SFTU; your position is so naive that it is pointless;
>  instead of complaining about what busy maintainers could do, do it
>  yourself, or find more people to do it.  Instead of reading your
>  bitching about Debian bug handling, I spent some hours yesterday
>  backporting the 10 bugs with the most duplicate reports from GNOME
>  upstream (check:
>  ), I
>  bet this was at least 1200% more useful than your arguing.

1200%? ROTFL. Yes, master, now you are my hero after making 10 trivial
fixes.

Eduard.

-- 
 hmhm... hier ist bestimmt niemand, dem die begriffe RED und ns im
kontext netzwerke was sagen, oder?
 Y_Plentyn: rot kennt jeder, und ueber NS redet man nicht mehr...


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

Re: incorrect path to locales? (might be rc)

[Yaroslav Halchenko]

doh - thanks! but problem persists... also I found that I was missing ko locale
for make due to localepurge... I've removed it and reinstalled make. I've ran
dpkg-reconfigure locales and included ko_* locales... the same luck since it
works for you, I guess it most probably has to do with some configuration, but
I am not sure where to look (terminal I was running it in is utf8 capable,
although it should be irrelevant probably)

,--
| $> ls -l /usr/share/locale/ko/LC_MESSAGES/make.mo 
| 28 -rw-r--r-- 1 root root 25548 Sep 11 16:15 
/usr/share/locale/ko/LC_MESSAGES/make.mo
| *$> validlocale ko_KR.utf8
| locale 'ko_KR.utf8' valid and available
| $> locale -a
| C
| POSIX
| en_DK
| en_DK.iso88591
| en_DK.iso885915
| en_DK.utf8
| en_US
| en_US.iso88591
| en_US.utf8
| ko_KR
| ko_KR.euckr
| ko_KR.utf8
| korean
| korean.euc
| ru_RU
| ru_RU.iso88595
| ru_RU.koi8r
| ru_RU.utf8
| ru_UA
| ru_UA.koi8u
| ru_UA.utf8
| russian
| uk_UA
| uk_UA.koi8u
| uk_UA.utf8
| $> LC_MESSAGES=ko_KR.utf8 strace -fF -o /tmp/make.strace make ; grep locale 
/tmp/make.strace
| make: *** No targets specified and no makefile found.  Stop.
| 29695 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
| 29695 open("/usr/share/locale/locale.alias", O_RDONLY) = 6
| 29695 open("/usr/share/locale/us/LC_MESSAGES/make.mo", O_RDONLY) = -1 ENOENT 
(No such file or directory)
|
`---

,-
| $> apt-cache policy libc6
| libc6:
|   Installed: 2.3.6.ds1-12
|   Candidate: 2.3.6.ds1-12
|   Version table:
|  *** 2.3.6.ds1-12 0
| 990 file: sid/main Packages
| 100 /var/lib/dpkg/status
`---


-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]



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

Re: On maintainers not responding to bugs

[Reid Priedhorsky]

On Tue, 27 Feb 2007 08:10:08 +0100, Mike Hommey wrote:

> 
> The other half of the problem that noone has talked about here yet, is
> that the users are as responsive as the maintainers, i.e. pretty badly.
> 
> Why do we have rotting unclosed bugs concerning old fixed issues ?
> Why don't most users just send in a message to say if the bug they
> reported is gone with a new upstream version ? Because they either don't
> care or moved along. Not necessarily because the maintainers didn't
> answer, because it happens even when we do.

I'd say that frequently the reason is simple ignorance on the part of the
user: i.e. they don't know how to send in an update or they don't know
that one would be welcome. IMO, it would be perfectly appropriate in these
cases to ping the user and, if no reply is forthcoming, to close the bug.

> And not only when bug are fixed don't we get feedback. We sometimes also
> face non-responsiveness to our requests for more precisions on the bug...

I think in these cases it's also often appropriate to close the bug.

Reid


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

Re: incorrect path to locales? (might be rc)

[Pierre Habouzit]

On Wed, Feb 28, 2007 at 11:17:50AM -0500, Yaroslav Halchenko wrote:
> doh - thanks! but problem persists... also I found that I was missing ko 
> locale
> for make due to localepurge... I've removed it and reinstalled make. I've ran
> dpkg-reconfigure locales and included ko_* locales... the same luck since it
> works for you, I guess it most probably has to do with some configuration, but
> I am not sure where to look (terminal I was running it in is utf8 capable,
> although it should be irrelevant probably)

  that's strange. If that can help, I use locales-all where all locales
are compiled by default. It's not _that_ big (20Mo) and spares the time
of generation of the locales. Maybe there is a bug in how locales (the
package) deals with them ?

  Thouth since it's on your system, I don't really understand the
problem. Could you please run:
  $ LC_MESSAGE=ko_KR.utf8 locale

  The problem could be that you have set your LC_ALL, that overrides any
of the LC_* variables. e.g.:

  $ locale|grep LC_MESS
  LC_MESSAGES=C

  $ LC_ALL=fr_FR.utf8 LC_MESSAGES=ko_KR.utf8 locale|grep LC_MESS
  LC_MESSAGES="fr_FR.utf8"

  $ LC_MESSAGES=ko_KR.utf8 locale|grep LC_MESS
  LC_MESSAGES=ko_KR.utf8


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


pgpmCBUcG2FH4.pgp
Description: PGP signature

Re: On management

[Wouter Verhelst]

On Wed, Feb 28, 2007 at 02:58:12PM +0100, Josselin Mouette wrote:
[...]
> of people running experimental. As GNOME 2.18 is scheduled in two
> months, this means we will be lagging two versions behind upstream as
> soon as we have released.

What's wrong with that? Many packages lag behind. The kernel, for
instance, will also lag two versions behind upstream. OpenOffice.org
will be version 2.0.x, while upstream has recently released 2.1. Heck,
even my pet package nbd-server is lagging behind by a major version (2.8
vs 2.9).

Yes, sometimes we have to make a choice which then eventually turns out
to have been suboptimal. But the world won't end because we don't have
the l33test version of GNOME in Debian; there's Ubuntu for that (and
this is meant neither pejoratively nor negatively).

Management is all about making choices based on available data and on
risk assessments. Given the data that was available to the release team
and the GNOME team at the time the decision was made, I do not think the
choice to stick with GNOME 2.14 was wrong. It may turn out to have been
suboptimal; but that doesn not mean it was the wrong decision at the
time.

As it turns out, getting GNOME 2.16 into etch would have been possible,
so I agree that it's a pity it did not happen. However, we did not and
could not know this back in September. Had we made the decision to go
with 2.16 at the time, and had we ran into problems with doing that,
then we might very well have been in the situation today that GNOME was
currently delaying the release, rather than the kernel. I'm quite sure
you prefer the current minor inconvenience over the alternative where
people might have been bashing you all over the place for not getting
your act together in time.

> Not only did it generate more work as we had two GNOME versions to
> maintain during the freeze, but it is now generating a lot of
> frustration because this extra work looks like a loss of time.

The choice to get GNOME 2.16 into experimental was your own. While I
could understand your frustration for lost time, it's hardly an argument
for good (or bad) release management.

> It is my belief that such things could be avoided if we had proper
> release management.

I'm quite utterly convinced that this is not true. I do agree that the
release team made a bad call in deciding what would go into etch and
what wouldn't. However, that bad call was related to GNOME -- it had
everything to do with the kernel. GNOME was ready in time, but the
kernel unfortunately isn't.

Given that the release team made a single bad call in co-deciding which
major subsystems could go in etch and which couldn't, I think they did a
fairly good job. It's a pity they couldn't do better, but that doesn't
mean they're not doing "proper release management".

[...]

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: incorrect path to locales? (might be rc)

[Yaroslav Halchenko]

let me first proceed with your diagnostic steps:

,-
| $> export | grep LC
| #2 !3169 [0].:Wed Feb 28 11:51:20:.
| belka:~
| $> LC_MESSAGE=ko_KR.utf8 locale
| LANG=C
| LANGUAGE=us
| LC_CTYPE="C"
| LC_NUMERIC="C"
| LC_TIME="C"
| LC_COLLATE="C"
| LC_MONETARY="C"
| LC_MESSAGES="C"
| LC_PAPER="C"
| LC_NAME="C"
| LC_ADDRESS="C"
| LC_TELEPHONE="C"
| LC_MEASUREMENT="C"
| LC_IDENTIFICATION="C"
| LC_ALL=
| $> LC_ALL=fr_FR.utf8 LC_MESSAGES=ko_KR.utf8 locale|grep LC_MESS
| locale: Cannot set LC_CTYPE to default locale: No such file or directory
| locale: Cannot set LC_MESSAGES to default locale: No such file or directory
| locale: Cannot set LC_ALL to default locale: No such file or directory
| LC_MESSAGES="fr_FR.utf8"
| $> LC_MESSAGES=ko_KR.utf8 locale|grep LC_MESS
| LC_MESSAGES=ko_KR.utf8
`---

and now I installed locales-all

,
| $> LC_ALL=fr_FR.utf8 LC_MESSAGES=ko_KR.utf8 locale|grep LC_MESS
| LC_MESSAGES="fr_FR.utf8"
| $> LC_MESSAGES=ko_KR.utf8 strace -fF -o /tmp/make.strace make ; grep
| locale /tmp/make.strace
| make: *** No targets specified and no makefile found.  Stop.
| 2255  open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
| 2255  open("/usr/share/locale/locale.alias", O_RDONLY) = 6
| 2255  open("/usr/share/locale/us/LC_MESSAGES/make.mo", O_RDONLY) = -1
| ENOENT (No such file or directory)
| $> LC_MESSAGES=ru_RU.utf8 strace -fF -o /tmp/make.strace make ; grep
| locale /tmp/make.strace
| make: *** No targets specified and no makefile found.  Stop.
| 2328  open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
| 2328  open("/usr/share/locale/locale.alias", O_RDONLY) = 6
| 2328  open("/usr/share/locale/us/LC_MESSAGES/make.mo", O_RDONLY) = -1
| ENOENT (No such file or directory)
|
`---

so that seems to be of no help... sid box seems to be slightly off
up-to-date - I am upgrading it to try once again, although it should not
matter - I upgraded it few days ago..

>   that's strange. If that can help, I use locales-all where all locales
> are compiled by default. It's not _that_ big (20Mo) and spares the time
> of generation of the locales. Maybe there is a bug in how locales (the
> package) deals with them ?
-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]



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

Re: On management

[Wouter Verhelst]

argl

On Wed, Feb 28, 2007 at 05:46:05PM +0100, Wouter Verhelst wrote:
> On Wed, Feb 28, 2007 at 02:58:12PM +0100, Josselin Mouette wrote:
> > It is my belief that such things could be avoided if we had proper
> > release management.
> 
> I'm quite utterly convinced that this is not true. I do agree that the
> release team made a bad call in deciding what would go into etch and
> what wouldn't. However, that bad call was related to GNOME -- it had
   ^ -- not
> everything to do with the kernel. GNOME was ready in time, but the
> kernel unfortunately isn't.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: Bug#412704: ITP: ocaml-ao -- OCaml bindings for libao

[Samuel Mimram]

Hi,

Stefano Zacchiroli wrote:
> On Tue, Feb 27, 2007 at 04:07:37PM +0100, Romain Beauxis wrote:
>> Owner: Samuel Mimram <[EMAIL PROTECTED]>
> 
> Given this, I guess you're already familiar with what I'm going to say,
> but better safe then sorry ...
> 
>> OCaml bindings for the cross platform audio output library.
> 
> Please Cc: [EMAIL PROTECTED] for ITP of OCaml-related packages
> and ensure your package conforms to the OCaml packaging policy
> before uploading or asking for sponsorship.

No need to worry: Romain and I have discussed privately and I will
review his package (and possibly also maintain it). FYI, we need this
library to package liquidsoap[1], a project in which we are both involved.

Cheers,

Samuel.

[1] http://savonet.sf.net/


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

Re: On maintainers not responding to bugs

[Sam Hocevar]

On Wed, Feb 28, 2007, Eduard Bloch wrote:
> But it seems like you maintain only few simple packages.

   Did you really just say that to Loïc Minier?

Amazed,
-- 
Sam.


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

Re: On management

[Christian Perrier]

> I'm not sure what you're advocating, but in my experience, project
> managers without the capacity to understand the technical issues of the
> project that they are supposed to be managing are worse than useless.


But project manageers who understand too well the technical issues
involved are also worse than useless because they tend to have an
engineer point of voew on things rather than a manager point of view.

The balance is pretty hard to find, indeed. We don't actually need
people who can understand all the internals involved in the work of
the GNOME team, or the kernel team, or D-i, or whatever. We probably
more need people with enough abstraction and general view on the whole
projectwho can then be able to driver things into the right
direction and then make decisions at critical moments.

That deeply involves taking the advice of the technically skilled
members of the project, then take decisions from this.

I think that I quite deeply agree with Joss on that issue.




signature.asc
Description: Digital signature

Re: On maintainers not responding to bugs

[Josselin Mouette]

Le mercredi 28 février 2007 à 18:00 +0100, Sam Hocevar a écrit :
> On Wed, Feb 28, 2007, Eduard Bloch wrote:
> > But it seems like you maintain only few simple packages.
> 
>Did you really just say that to Loïc Minier?

Hey, that's true. He maintains many complicated packages, but only few
simple ones.

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


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

Re: On maintainers not responding to bugs

[Mike Hommey]

On Wed, Feb 28, 2007 at 07:26:24PM +0100, Josselin Mouette <[EMAIL PROTECTED]> 
wrote:
> Le mercredi 28 février 2007 à 18:00 +0100, Sam Hocevar a écrit :
> > On Wed, Feb 28, 2007, Eduard Bloch wrote:
> > > But it seems like you maintain only few simple packages.
> > 
> >Did you really just say that to Loïc Minier?
> 
> Hey, that's true. He maintains many complicated packages, but only few
> simple ones.

I guess Eduard looked at
http://qa.debian.org/developer.php?login=lool
which implies he maintains only few simple packages and sponsor a lot,
rather than
http://qa.debian.org/[EMAIL PROTECTED]

Mike


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

Custom repository and "WARNING: The following packages cannot be authenticated!"

[Michael S. Peek]

Hello gurus,

I'm hoping someone can give me a hand.

I have been running my own repository for a while now, and with the
release of etch as the new stable just around the corner, I would like
to add my own authentication to my repository.  So I set up an install
host running etch, put a repository on it, and followed the instructions
to set up authentication -- but it's a no-go.  I admit that I have a
problem understanding what I'm doing, since I've never used gnupg or pgp
before.  I'm hoping some kind soul on the list here can take a look at
what I've done and will see what I've got wrong.

Here's what I've done:

1) First, I created a gpg key with the following script, gpg-gen-key.
It relies on the existence of a file named passphrase.txt that holds my
passphrase.  (The whole process is automated on a secure host, so I'm
not worried about users being able to read the file.)  The script follows:

   #!/bin/bash

   set -e
   set -x

   this_dir=$(cd $(dirname "${0}") && pwd)
   gpg_home="${this_dir}/.gnupg"
   input_file="${this_dir}/input.txt"

   test -d "${gpg_home}" \
   || mkdir "${gpg_home}"
   test -d "${gpg_home}" \
   && chmod 0700 "${gpg_home}"

   test -f "${this_dir}/passphrase.txt"
   test -f "${this_dir}/input.txt" \
   || cat > "${input_file}" << EOF
   1
   2048
   0
   y
   Michael Peek
   [EMAIL PROTECTED]

   o

   EOF

   test -f "${gpg_home}/pubring.gpg" \
   || gpg \
   --homedir "${gpg_home}" \
   --command-file "${this_dir}/input.txt" \
   --passphrase-file "${this_dir}/passphrase.txt" \
   --gen-key \
   2>&1

   str=$( \
   gpg --homedir "${gpg_home}" --list-keys 2>&1 \
   | grep '^pub' \
   | head -1 \
   | awk '{print $2}' \
   | awk -F/ '{print $2}' \
   )

   echo "${str}" > tiem.id

   test -f tiem.key \
   || gpg --homedir "${gpg_home}" --armor --export "${str}" > tiem.key

   # vim:ts=2:shiftwidth=2:filetype=sh:syntax=sh:

This script generates a .gnupg/ directory, and spits out a tiem.key file
containing the key that I give to apt-key on my clients.  An example of
each file:

tiem.key:

   -BEGIN PGP PUBLIC KEY BLOCK-
   Version: GnuPG v1.4.6 (GNU/Linux)

   mQGXX9pq

   ...stuff...

   ...stuff...

   ...stuff...

   D8NXXJqR
   dKKfig==
   =8w/+
   -END PGP PUBLIC KEY BLOCK-

tiem.id:

   666C18A7

2) Next, I use the above keys to sign my Release file, placing the
signature in Release.gpg.  This is done with another script, gpg-sign,
which follows:

   #!/bin/bash

   set -e
   set -x

   this_dir=$(cd $(dirname "${0}") && pwd)
   gpg_home="${this_dir}/.gnupg"
   test -d "${gpg_home}"
   test -f "${this_dir}/passphrase.txt"
   gpg --homedir ${gpg_home} --list-keys
   str=$( \
   gpg --homedir ${gpg_home} --list-keys 2>&1 \
   | grep '^pub' \
   | head -1 \
   | awk '{print $2}' \
   | awk -F/ '{print $2}' \
   )

   test ! -f "${2}" \
   || rm -f "${2}"

   gpg \
   --homedir "${gpg_home}" \
   --passphrase-file "${this_dir}/passphrase.txt" \
   --default-key "${str}" \
   -abs \
   -o "${2}" "${1}" \
   2>&1

   # vim:ts=2:shiftwidth=2:filetype=sh:syntax=sh:

An example of the Release.gpg file:

   -BEGIN PGP SIGNATURE-
   Version: GnuPG v1.4.6 (GNU/Linux)

   iD8XXA8d
   Z6CXXQw=
   =3twD
   -END PGP SIGNATURE-

3) On the client I add the key generated above in step 1 via apt-key.
The output of apt-key list is as follows:

   /etc/apt/trusted.gpg
   
   pub   1024D/2D230C5F 2006-01-03 [expired: 2007-02-07]
   uid  Debian Archive Automatic Signing Key (2006)
   <[EMAIL PROTECTED]>

   pub   1024D/6070D3A1 2006-11-20 [expires: 2009-07-01]
   uid  Debian Archive Automatic Signing Key (4.0/etch)
   <[EMAIL PROTECTED]>

   pub   1024D/1F41B907 1999-10-03
   uid  Christian Marillat <[EMAIL PROTECTED]>
   uid  Christian Marillat <[EMAIL PROTECTED]>
   sub   1536g/C28DCC42 1999-10-03
   sub   1024D/5D3877A7 2002-08-26

   pub   1024D/666C18A7 2007-02-27
   uid  Michael Peek <[EMAIL PROTECTED]>
   sub   2048g/969F8B67 2007-02-27

   pub   1024D/ADB11277 2006-09-17
   uid  Etch Stable Release Key
   

Notice the 666C18A7 key -- that's mine.

4) I run apt-get update, and get:

   Ign http://install1 etch Release.gpg
   Ign http://install1 etch Release
   Ign http://install1 etch/main Packages/DiffIndex
   Ign http://install1 etch/non-free Packages/DiffIndex
   Ign http://install1 etch/contrib Packages/DiffIndex
   Ign http://install1 etch/main Packages
   Ign http://install1 etch/non-free Packages
   Ign http://install1 etch/contrib Packages
   Hit http://install1 etch/main Packages
   Hit http://install1 etch/non-free Packages
   Hit http:/

Re: incorrect path to locales? (might be rc)

[Yaroslav Halchenko]

aha!
Further poking around discovered that I have to provide LANGUAGE, and
LC_ALL for correct locale selection:

(I've ran it in non-utf8 terminal)
,---
| *$> LC_ALL=ru_RU.utf8 LANGUAGE=ru_RU.utf8 make
| make: *** Не заданы цели и не найден make-файл.  Останов.
| *$> LC_ALL=ru_RU.utf8 LC_MESSAGES=ru_RU.utf8 make
| make: *** No targets specified and no makefile found.  Stop.
| *$> LANGUAGE=ru_RU.utf8 LC_MESSAGES=ru_RU.utf8 make
| make: *** ?? ??  ? ?? ?? make-.  ???.
`---

it seems to be time to RTFM now...
-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]



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

Re: On maintainers not responding to bugs

[Warren Turkal]

On Wednesday 28 February 2007 01:19, Hamish Moffatt wrote:
> In all fairness, you didn't seem to comment on his response to your
> suggestion.

I did comment on his suggestion.

"Yes, it should start before NFS because its not just mounting a file system 
like NFS. It needs to make the block devices available."

Not to mention there was a thread on debian-devel at the time where I thought 
he was MIA because he was so unresponsive.

> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387552;msg=30;att=0).
> This seems to be more of a case of not liking his solution than having a
> legitimate grievance?

The solution flat out does not work. I mean, as his scripts are written, the 
machine hangs on shutdown. Here's the basic happenings of that bug.

Sept. 14 - I send initial bug report.
Oct. 2 - After 3.5 weeks the maintainer releases a new package, claiming it 
fixed the bug. I then attempt to point out that the script is not working.
Oct. 3 - I attach my implementation of the init script that at least lets the 
filesystems mount.
Oct. 9 - I try to get the maintainer to do something about letting it 
propagate to testing as I think the "fix" is not a fix. I do not escalate the 
bug myself because I am not the maintainer.
Oct. 12 - The maintainer replies only because a thread on debian-devel[1] 
calls into question his ability to maintain the package. I then respond with 
a comment on the only thing relevant in the email (the order of start scripts 
and how AOE is different from NFS). I provide a link to Coraid's (the 
implementer of aoe in the kernel) documentation about setting up this 
hardware.
Nov. 8 - I document why the new revision of the package doesn't work even for 
the mounting case, and I document that udev may be the right way to 
completely avoid the race condition.

I'd like to point out that the above occurred over about a two month period. 
One response from the maintainer that was prompted by pinging debian-devel is 
ridiculous.

As you can see there is only one human response in there, and I did respond to 
the critical question of his email. He seems to only respond when things get 
emotionally charged or when I publically tried to see if some other developer 
could comment on my changes.

The maintainer's behavior made him very discouraging to work with. I just 
stopped dealing with him after a while. It hasn't stopped me from filing 
other bug reports.

You may think I'm a whiner, but the fact of the matter is that my hardware 
flat out does not work with his scripts, and he was unresponsive to my 
suggestions for fixing them. He didn't even want to consider the use case 
that someone might want to treat a block device like a block device instead 
of a filesystem container. If you don't want to consider it non-responsive, 
it was at least really unproductive and frustrating.

[1]http://lists.debian.org/debian-devel/2006/10/msg00451.html

wt
-- 
Warren Turkal, Research Associate III/Systems Administrator
Colorado State University, Dept. of Atmospheric Science


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

Bug#412919: ITP: predictive -- Text completion package for Emacs

[Jan Alonzo]

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

* Package name: predictive
  Version : 0.16
  Upstream Author : Toby Cubitt <[EMAIL PROTECTED]>
* URL : http://www.dr-qubit.org/emacs.php
* License : GPL
  Programming Lang: Lisp
  Description : Text completion package for Emacs

 Predictive is a minor-mode, text-completion package for Emacs. When enabled,
 predictive mode exploits the redundancy inherent in languages in order to
 complete words you are typing before you've finished typing them (somewhat
 like the IntelliSense feature in some IDEs). It is highly customisable, and
 works happily alongside other Emacs major modes.
 .
  Homepage: http://www.dr-qubit.org/emacs.php

-- System Information:
Debian Release: 4.0
  APT prefers feisty
  APT policy: (500, 'feisty')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20-9-generic
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)


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