Bug#369329: ITP: phpmybibli-doc-fr -- French documentation for PMB

[Vincent Danjean]

Package: wnpp
Severity: wishlist
Owner: Vincent Danjean <[EMAIL PROTECTED]>

* Package name: phpmybibli-doc-fr
  Version : 20050529 (none upstream)
  Upstream Author : [EMAIL PROTECTED]
* URL : http://www.pizz.net/index_logiciel.php
* License : CeCILL
  Programming Lang: HTML
  Description : French documentation for PMB

This package contains three french guides for PhpMyBibli:
 + the installation guide (not really useful on a Debian system)
 + the user guide
 + the administrator guide

I do not think that these guides already have an english translation...

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


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

Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys

[Steve Langasek]

On Sun, May 28, 2006 at 08:57:55PM -0700, Thomas Bushnell BSG wrote:

> > If I were to crack a key signing party, using Bubba's travel
> >  documents, I too would swear up and down the street that he indeed
> >  correctly and diligently verified all kinds of _other_ government
> >  ID's when practising his art.

> How is it "cracking" to use Bubba's documents?  People who do not know
> and trust Bubba should not accept the ID, period.

Heh, I think you missed the subtext of Manoj's hypothetical, which is that
Bubba sells fake IDs to underage students.

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


signature.asc
Description: Digital signature

Re: Bug#369257: remote bug tracking system doesn't look at versions

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Mon, May 29, 2006 at 03:40:59AM +0200, Matthias Klose wrote:
>> > What problems with the information in the BTS are you talking about?
>
>> the usertags, which are wrongly set and removed.
>
>> please don't get me wrong; generally the btslink information is
>> useful, but I do see the BTS maintainers in charge as well, if the
>> system is "misused". we did see this in the past with unreflected
>> changes of the forwarded information, now with wrong usertags. what
>> comes next?
>
> Um... usertags have user-defined semantics.  How can you claim that the
> usertags being set are wrong?

As I understand it, the complaint is that bts-link is changing user
tags set by the maintainer.


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

Re: [Debconf-discuss] Alternative keysigning procedures

[Aníbal Monsalve Salazar]

On Sun, May 28, 2006 at 06:40:28PM -0500, Andrew McMillan wrote:
>On Sun, 2006-05-28 at 04:54 -0700, Steve Langasek wrote:
>>On Sat, May 27, 2006 at 04:47:20PM -0500, martin f krafft wrote:
>>
>>>I imagine an improved protocol for the keysigning, which is based on
>>>an idea I overheard after the party (and someone mentioned it in the
>>>thread): instead of the everyone-signs-everyone approach, it might
>>>be interesting to investigate forming groups (based on connectivity
>>>statistics) such that everyone's mean distance in the web of trust
>>>can be increased by a fair amount in a short amount of time. At the
>>>same time, such circles could be used for education by those with
>>>high connectivity (and thus much experience). The problem here is of
>>>course the somewhat unreliable attendance of people. Comments
>>>welcome.
>>
>>I agree that this is the way to go.  Who has time to work on implementing
>>the necessary code?

[Sending to -devel only]

I just talked to a friend who is an expert in mathematics (Senior
Lecturer of Deakin University, Melbourne). He said the problem is
a discrete programming problem and could be represented as a
classical problem with a known solution algorithm. He will futher
look into this problem.

I'll do the coding of the optimization program (with his help).

>It is something that has been discussed before, and it was certainly
>something that I was discussing with Anibal after the keysigning.
>
>The concept that Anibal and I were discussing post-keysigning was as
>follows:
>
>(a) Order the list of keysigning participants by centrality.
>
>(b) Decide on a group size for the keysigning.  Something around 10-15
>seems likely to be a worthwhile choice.
>
>(c) Allocate partcipants to the groups in a round robin following
>centrality order and starting with the most central.

To allocate participants in each group we'll use the optimization
program to improve the mds of all ksp participants.

>Produce the keysigning list, with group numbers in addition to the key
>numbers (or perhaps instead of).
>
>All of the other pre-keysigning activities are the same.
>
>At the keysigning, the initial reading out of MD5 / SHA1 of the
>keysigning list would still happen, as it normally does.
>
>After this, the keysigning would follow two parts:
>
>Part One
>
>
>People split into their assigned groups and cross-sign only within those
>groups.  The intention is that these groups are small enough that
>everyone can see everything that is going on.  Experienced people can be
>observed performing comprehensive checks, and inexperienced people can
>be educated.
>
>Part Two
>
>
>Optionally, after part one is complete, some people may choose to
>personally and individually participate in keysignings outside of their
>assigned groups.  Note that this can still be facilitated by the fact
>that both individuals have their fingerprints within the keysigning
>list.

The group of "Part Two" could consist of people with the lowest mds
and people who want to participate in keysignings outside of their
"Part One" groups.

>==
>Finito.
>And gradually it fades out.
>
>
>Rationale
>=
>
>Keysignings stop being fun ways to meet people after about 15 minutes.
>For me, the worst experience was in Helsinki, with around 300 people,
>getting sunburned in a carpark.
>
>Keysignings are about improving the web of trust.  The most efficient
>enhancement of the web of trust will be if the edges exchange keys with
>the middle.  Signing keys with _everyone_ is inefficient, unnecessary
>and promotes competitive behaviour rather than trust relationships.
>
>Keysignings should promote education of WoT best practices, and not
>_worst_ practices.
>
>Keysignings should not take more than one hour.
>
>
>So that's my 2c.
>
>
>If people agree that this would be a useful approach, I am willing to
>undertake to provide some additional tools within the signing-party
>package to make such a keysigning more easily doable.
>
>Of course the above does not address how to handle the people who didn't
>manage to get their act together soon enough to be in the initial list.
>There are several ways to deal with this also:
>
>1) The "additional list" is produced, SHA1'd, read, but these people can
>only participate in "Part Two" above.
>
>2) The "additional list" is produced and these people are also
>allocated to groups in round robin, but randomly, rather than in
>centrality order.

Or we could use the optimization program to allocate people in the
"additional list" to the small groups.

>and no doubt there are other ways to deal with it...
>
>
>Regards,
>   Andrew.
>
>PS.  Please feel free to CC me on replies, since I am not subscribed to
>Debian Devel and I _do_ have sane procmail dupe filters :-)
>
>-
>Andrew @ Catalyst .Net .NZ  Ltd,  PO Box 11-053, Manners St,  Wellington
>WEB: http://catalyst.net.nz/ 

Re: Please revoke your signatures from Martin Kraff's keys

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Sun, May 28, 2006 at 11:57:43PM -0400, Roberto C. Sanchez wrote:
>
>
>> The identification showed his real name and real likeness [0].  He did not
>> misrepresent any information in either obtaining the document or in
>> presenting it to those who requested he identify himself.
>
> The real issue is that, for those people who did not notice the problematic
> ID and check his passport as well, the truth value of the above statements
> is completely unknown.  This makes it unreasonable to sign his key based on
> such an ID; it also makes it unreasonable, IMHO, to insist that
> Martin-or-someone-saying-his-name-is-Martin has deceived us, because for the
> people who only looked at his Transnational Republic ID, there is not enough
> information available to say either way.

Quite right.  It seems certainly appropriate to me to suggest to
people who signed the ID on the basis of the Transnational Republic ID
that they should revoke the signature, and that people who aren't sure
should do the same.

But the claim that Martin lied or committed a fraud, this claim is not
suggested at all.


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

Re: Bug#369257: remote bug tracking system doesn't look at versions

[Steve Langasek]

On Mon, May 29, 2006 at 03:40:59AM +0200, Matthias Klose wrote:
> > What problems with the information in the BTS are you talking about?

> the usertags, which are wrongly set and removed.

> please don't get me wrong; generally the btslink information is
> useful, but I do see the BTS maintainers in charge as well, if the
> system is "misused". we did see this in the past with unreflected
> changes of the forwarded information, now with wrong usertags. what
> comes next?

Um... usertags have user-defined semantics.  How can you claim that the
usertags being set are wrong?

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


signature.asc
Description: Digital signature

Re: [Debconf-discuss] list of valid documents for KSPs

[Benjamin A'Lee]

On Sun, May 28, 2006 at 09:22:10PM -0700, Thomas Bushnell BSG wrote:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
> 
> > Once he has broken faith, nothing coming from that source can
> >  be accepted, since the source is now tainted.  Any information flow
> >  with that origination is tainted, and since you offer the same
> >  statements, without any form of untainting that is visible, I think
> >  you are rapidly approaching the untrusted relay category.
> 
> What I don't see is what exactly the scam *was*.  
> 
> It seems to me that you are saying that presenting an ID which should
> *scream* to anyone paying the least attention "this is not a
> government ID", has, ipso facto, lied.  
> 
> But no, they haven't.  They haven't forged, or been dishonest.

In fact (as I understand it) Martin willingly showed his real ID to
anyone who didn't accept his Transnational Republic ID.  That doesn't
sound all that dishonest to me - surely if the intent was to deceive he
wouldn't have shown any real ID?

bma

-- 
Benjamin A'Lee - 
Secretary, TermiSoc - 
"Graphs of higher degree polynomials have this habit of doing unwanted
wiggly things." -- From a Cambridge maths lecture.


signature.asc
Description: Digital signature

Re: Please revoke your signatures from Martin Kraff's keys

[Steve Langasek]

On Sun, May 28, 2006 at 11:57:43PM -0400, Roberto C. Sanchez wrote:


> The identification showed his real name and real likeness [0].  He did not
> misrepresent any information in either obtaining the document or in
> presenting it to those who requested he identify himself.

The real issue is that, for those people who did not notice the problematic
ID and check his passport as well, the truth value of the above statements
is completely unknown.  This makes it unreasonable to sign his key based on
such an ID; it also makes it unreasonable, IMHO, to insist that
Martin-or-someone-saying-his-name-is-Martin has deceived us, because for the
people who only looked at his Transnational Republic ID, there is not enough
information available to say either way.

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


signature.asc
Description: Digital signature

Re: Debian GNU/MINIX

[Goswin von Brederlow]

"Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes:

> On Thu, 25 May 2006, El Presidente wrote:
>
>> I have seen on the internet that someone wanted to port debian to minix3, but
>> the report was old. Is there anyone that wants to port? I find it usefull.
>> I don't have the ability to do it, but if it works I will switch to it [ the
>> next versionof minix will handle driver crashes(no more nasty fs crash - hard
>> reboot) ].
>>
>
> That would be me.  I've done a lot of compiling of packages over the
> past few months but avoided the hard parts of a full port also my
> build machine has become severely limited in disk space.  Next week
> I'm getting a replacement and at that time I'll tidy things up and
> hopefully start making faster progress.

Any chance of getting a minix-amd64 started?

MfG
Goswin


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

Re: [Debconf-discuss] list of valid documents for KSPs

[Thomas Bushnell BSG]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> Once he has broken faith, nothing coming from that source can
>  be accepted, since the source is now tainted.  Any information flow
>  with that origination is tainted, and since you offer the same
>  statements, without any form of untainting that is visible, I think
>  you are rapidly approaching the untrusted relay category.

What I don't see is what exactly the scam *was*.  

It seems to me that you are saying that presenting an ID which should
*scream* to anyone paying the least attention "this is not a
government ID", has, ipso facto, lied.  

But no, they haven't.  They haven't forged, or been dishonest.

What is stunning here is that you check such things as expiration
dates, which don't affect identity at all as long as the picture is
recognizable, and you don't check such things as whether the country
named on the ID is a real country or not.

If anything, it is you whose signatures are suspect, you who have
essentially declared "I don't bother checking whether the country is a
real country", and are now defending the principle that you apparently
shouldn't have to.  (Or perhaps it's that you really did think that
the Transnational Republic is a real country; is that it?)

By contrast, I *do* read such things as what the issuing authority is
whenever I check IDs.  So Martin's shenanigans wouldn't have suckered
me in.

If what you did was to say "hey, people should know that one of
Martin's IDs at the KSP was from a non-government of dubious
reliability, so they should consider not signing their key if they may
have been mistaken", that would be fine.  What you said was *much*
stronger, and impugned his honesty.

Thomas


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

Re: Please revoke your signatures from Martin Kraff's keys

[Daniel Dickinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Er, is it just me or isn't the point of gnupg that there *are* people
you *can't trust*.  We wouldn't be needing digital signatures if
everybody honoured the 'gentleman's agreement' that we should only
sign as ourselves (or at most as a pseudonym that can't be confused for
a real person) in plaintext email.

If the KSP is so weak that it depends on gentleman's agreements to
work, it's been cracked with unannounced malicious intent already, or
soon will be.

The whole point of the web of trust is that you should only say you
trust people you actually trust.  Personally I think a keysigning where
I only know people by ID, is at best a marginal trust.

GnuPG is about security, and security implies that there is a need to
be secure against someone or something.  In the case of GnuPG it's
people pretending to be something they are not.  If you depend on
'acceptable behaviour' to prevent abuse of this system you've already
lost, because the person is pretending to who they are not with
malicious intent, is not going to honour that understanding.  They also
won't tell you about it.

So, again, what's the point of security if it depends on 'acceptable
behaviour' or 'gentleman's agreements' to succeed?

- -- 
And that's my crabbing done for the day.  Got it out of the way early, 
now I have the rest of the afternoon to sniff fragrant tea-roses or 
strangle cute bunnies or something.   -- Michael Devore

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

iD8DBQFEenZ9hvWBpdQuHxwRAqioAJ90MDtm99rqadrB9ix1wt6E/1bWbwCcCeBb
fxIQww9KC+oAVaRrIpo3IO4=
=ySo4
-END PGP SIGNATURE-

Re: [Debconf-discuss] list of valid documents for KSPs

[Manoj Srivastava]

On 28 May 2006, Thomas Bushnell told this:

>>> This may be true, except that *the document was not forged*.
>>
>> So you continue to claim.  And since you make statements like this
>> with no discernible means of you having verified them, I do not see
>> how discussion with you has any value whatsoever -- you'll make any
>> statements to back your position, whether or not you know them to
>> be true.
>
> It is as if you don't bother to read what you are replying to.
>
> Notice I said "as it has been reported."  

I also noticed whom it was so reported -- and the second
 statement you made was an emphatic one, with no such disclaimers.

> So help me out here: are you claiming that Martin's card was *not* a
> genuine credential from the Transnational Republic?  If so, do you
> have any evidence for that?  You seem to be upset at Martin, or at
> the people who signed his key, but I can't tell what *exactly* is
> the basis for the anger.

Hmm. Let us see here. A KSP is one where one presents the best
 papers one has, since the tacit understanding is that the cheks that
 had been undergone, and the international treeaties and laws governing
 travel papers (or national laws governing misuse of such documents)
 are a proxy for checks that the people at the party are unable to
 perform.

A good faith participation in a key signing party would have
 involved all us foreigners presenting our passports, and being
 present to get our keys signed, and extending the web of trust for
 Debian.

This is not what that individual who porports to be Marting
 actually did:  by self confession, the participation was to
 "experiment" with the expectation of trust and to game the system to
 "prove" how weak it was.  At this point, the expectation of good
 faith participation is broken; we now have a social enginnering
 exploit based on expectations of the people (something all grifters
 know and exploit).

The expectation of trust is broken, as is the trust I have in
 that individual. What is the trust path I have to determine if the
 papers presented were not fake? Ah, yes, the words of the scam
 artist.  As far as I can tell, the person or organization has not
 entered into bilateral agreements with an agency or government I
 have even an iota of trust in, nor would there be any consequences
 for these organizations to issue fake papers.

So, once someone acts in bad faith, I can't trust anything
 else they say: How do I know it is not a hoax within a hoax to see
 how gullible people are, to accept that the papers presented were not
 faked, or outright forgeries?

Once he has broken faith, nothing coming from that source can
 be accepted, since the source is now tainted.  Any information flow
 with that origination is tainted, and since you offer the same
 statements, without any form of untainting that is visible, I think
 you are rapidly approaching the untrusted relay category.

It is all basic information flow analysis.

manoj
-- 
The District of Columbia has a law forbidding you to exert pressure on
a balloon and thereby cause a whistling sound on the streets.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Please revoke your signatures from Martin Kraff's keys

[Thomas Bushnell BSG]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> Any act of deception, meant to exploit the weaknesses of the
>  system rather than participating in a key signing in good faith is
>  likely to have had this effect, yes.

That's true.  What about Martin's actions, as they have been reported,
makes you think there was any deception going on?

>  An so called "unofficial" document, purchased from some unknown
>  entity, which has not entered into these international agreements,
>  does not carry the same weight.

Oh, this is certainly true.  But there isn't anything particularly
deceptive about me presenting an ID that is *not* from a government;
it simply shouldn't be accepted by itself as evidence of identity,
that's all.  It's certainly not dishonest.

Now, the first people who signed my Debian key were developers who
knew me personally.  They didn't look at any ID at all.  How's that?!
Seems perfectly reasonable to me.  The purpose of the ID is to satisfy
the signatory about identity; if they are otherwise satisfied, then
that's great.

And, incidentally, the Transnational Republic is not an unknown
entity in the objective sense, though certainly a given signer might
not know it.  Signers should certainly not trust IDs from
organizations they've never heard of.

But that doesn't mean that it's wrong to present an ID from such an
organization.  It might well be that the Transnational Republic's
procedures are sufficiently controlled that their IDs are perfectly
trustable, by those who know of its existence and nature.

(For example, my university ID card should not be adequate ID to
someone who doesn't know of the University of California or its
procedures for checking identity.  But to someone who does, perhaps to
a fellow member of the institution, the ID card might well be a
perfectly satisfactory basis for a signature on a key.)

> If I were to crack a key signing party, using Bubba's travel
>  documents, I too would swear up and down the street that he indeed
>  correctly and diligently verified all kinds of _other_ government
>  ID's when practising his art.

How is it "cracking" to use Bubba's documents?  People who do not know
and trust Bubba should not accept the ID, period.

> Any one would have their right to doubt further protestations
>  from a known cheater: how do we know this is not an further elaborate
>  test of the credulity of the community at large?

How does Martin rank as a "known cheater"?  You seem to be *assuming*
that he was dishonest, as part of your proof that what he did was
dishonest.  

This looks for all the world as if *YOU* were taken in, and rather
than wipe the egg off your face and promise to check IDs more
carefully in the future, you're blaming him for your failure to notice
that the Transnational Republic is not a real country.

> I have not, and never will sign your key, ever again.  I don't
>  trust you to present identity papers that are trustworthy -- unless I
>  can get a law enforcement official I select to test and verify your
>  papers, and possibly not then.

Really?  Why?  What has Martin done to lose your trust?  Please lead
me through it carefully, because it seems like you're skipping a
step.  Start with the evidence you have for your assertions, whatever
they are.

> Well, yes, since the KSP was indeed subverted, I am not
>  signing any keys from this event. I am considering not signing keys
>  from the Debian community, since it apparently condones Bubba ID
>  papers.

How was the KSP "subverted"?

Who has said that IDs from the Transnational Republic are condoned?

Thomas


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

Re: Please revoke your signatures from Martin Kraff's keys

[Roberto C. Sanchez]

Manoj Srivastava wrote:
> On 27 May 2006, martin f. krafft spake thusly:
> 
> 
>>Dear Manoj, dear fellow DDs,
>>
>>I guess I could have known that this experiment of mine would turn
>>into a huge thread, unfortunately extending across two mailing
>>lists. Thus, it is surely in order for me to apologise for being the
>>cause that your inboxes filled up.
> 
> 
> Any act of deception, meant to exploit the weaknesses of the
>  system rather than participating in a key signing in good faith is
>  likely to have had this effect, yes.
> 

I'm sorry to join this thread, but I am wondering what Martin's
deception was.  As I understand it, he used a form of identification
which was issued by an organization which is not recognized as the
governing body of any place in particular.  The identification showed
his real name and real likeness [0].  He did not misrepresent any
information in either obtaining the document or in presenting it to
those who requested he identify himself.  So, to the best of my
reckoning, this is all really an issue dealing with the fact that there
exist organizations which we would not trust to do certain things.  I
think this is hardly an earth-shattering revelation.

-Roberto

[0] At least as far as those things have been previously known.

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


signature.asc
Description: OpenPGP digital signature

Re: Please revoke your signatures from Martin Kraff's keys

[Manoj Srivastava]

On 27 May 2006, martin f. krafft spake thusly:

> Dear Manoj, dear fellow DDs,
>
> I guess I could have known that this experiment of mine would turn
> into a huge thread, unfortunately extending across two mailing
> lists. Thus, it is surely in order for me to apologise for being the
> cause that your inboxes filled up.

Any act of deception, meant to exploit the weaknesses of the
 system rather than participating in a key signing in good faith is
 likely to have had this effect, yes.

> 0. http://blog.madduck.net/geek/2006.05.24-tr-id-at-keysigning
>
> First of all, my name is Martin Felix Krafft (with a final 't'), and
> my GPG key ID is 0x330c4a75. The unofficial ID I presented listed
> that name (without the middle name), a photo is available from [1]
> (sorry, can't do better now). Thus, the ID card is an unofficial
> card, but the identity it claims is my real identity, not a fake
> one. To me, this is an important distinction in the context of this
> discussion.

Err, so you claim. I have no means of determining if this is
 true.  The official ID's issued as travel papers have a certain trust
 metric: there are international agreements that are enforced when it
 comes to travel documents.  Each government, in order to allow it's
 citizens the right of travel abroad, goes through certain measures to
 tie down the papers issued to their citizens, and there are various
 standards that are applicable to identity verification.  An so called
 "unofficial" document, purchased from some unknown entity, which has
 not entered into these international agreements, does not carry the
 same weight.

The only reason for having a key signed is to associate an
 identity, even if indirectly, by proxy, via a government issued
 identity document; the tacit understanding is that the cheks and
 verification conducted by the governments to meet the international
 agreements are "good enough".


Now let me talk about Bubba.  Bubba is an entrepreneur, who
 has dedicated his professional career  to serving the freshmen of
 University of Tennessee at Knoxville, in meeting their obligations
 and rights as college students to worship at the altar of Bacchus.
 On examinations of the Benjamins, and other documents bearing the
 imprints various presidents of the United States, he provides you,
 after due process, travel documents of various domains and
 verisimilitude.

If I were to crack a key signing party, using Bubba's travel
 documents, I too would swear up and down the street that he indeed
 correctly and diligently verified all kinds of _other_ government
 ID's when practising his art.

Any one would have their right to doubt further protestations
 from a known cheater: how do we know this is not an further elaborate
 test of the credulity of the community at large?



>
> From within the project, what matters is that everything you do
> within the project can be attributed to one and the same person: the
> same person that went through our NM process. The GPG key is one
> technical measure to allow for this form of identification. Its
> purpose is not, as Micah Anderson states, a means to confirm the
> validity of a government-issued ID.

A GPG key that can not be traced to a real person who has
 introduced a trojan into Debian and has stolen valuable data
 (perhaps, just as another "test" to prove how stupid people are to
 trust Debian), is worth less than a key that can implicate a real
 person, and perhaps mitigate some damage done by the attack.

>> I do not need an ID to identify martin, so i dont need to rely on
>> his (forged or real) passport or other id from him in order to
>> sign his key. If you did not know him before you should not sign
>> his key (if your judgement was based on the unofficial ID). 

>> Maybe we should just drop holding KSPs, and fall back to the
>> traditional method of "Hey, nice dinner we had yesterday. Say, now
>> that you know me, my family and my history, would you like to sign
>> my key as well?" - Signing for people you actually know, not just
>> linking
>
> In my eyes, this is exactly what a keysigning is and should be all
> about: a statement of familiarity with a person, nothing more and
> nothing less. And as a project, we should either accept that, or
> find a better way to identify our developers.

This is also silly --- what is the trust path he has to the
 crackers identity?  Say, some person walks up to a LUG or linuxtag or
 debconf and says, "Hi, I am Donal Duck".  He proceeds to talk about
 free software, goes out for drinks, and tells a fine tale.  He does
 so again a year later, again calling himself Donal Duck.

Now, with the help of Bubba, he walks in, and our dear friend
 would happily sign the key of young Donal.  Knowing the person does
 no good for real identity verification if we accept the behaviour of
 presenting Bubba's identity papers.

> So what to do in this very situation? Should you re

Re: [Debconf-discuss] list of valid documents for KSPs

[Thomas Bushnell BSG]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

>>> If people start bringing in forged documents, no amount of caution
>>> on part of laypeople like most software developers is proof against
>>> such deception.  If such deception is accepted behaviour, we may as
>>> well throw out thetrust metric, and let /. upload packages into
>>> Debian.
>>
>> This may be true, except that *the document was not forged*.
>
> So you continue to claim.   And since you make statements like
>  this with no discernible means of you having verified them, I do not
>  see how discussion with you has any value whatsoever -- you'll make
>  any statements to back your position, whether or not you know them to
>  be true.

Perhaps my just-posted message has too many words to see my point.

In the paragraph above, marked >>>, which was written by you, you
speak of deception and forgery.  Nothing in the reports of the
recent incident involving Martin suggests any deception and forgery.
What about this incident makes you think that any kind of deception or
forgery was going on?

Thomas


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

Re: [Debconf-discuss] list of valid documents for KSPs

[Thomas Bushnell BSG]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> On 28 May 2006, Thomas Bushnell verbalised:
>
>> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>
>>> I see you have never been in a large key signing party.  There is a
>>> certain expectation of trust, since no one can actrually detect
>>> delibrate forgeries.
>>
>> Except that there was nothing forged about Martin's ID card, as it
>> has been reported.  It was exactly what it claimed to be, nothing
>> more and nothing less.
>>
>>> If people start bringing in forged documents, no amount of caution
>>> on part of laypeople like most software developers is proof against
>>> such deception.  If such deception is accepted behaviour, we may as
>>> well throw out thetrust metric, and let /. upload packages into
>>> Debian.
>>
>> This may be true, except that *the document was not forged*.
>
> So you continue to claim.   And since you make statements like
>  this with no discernible means of you having verified them, I do not
>  see how discussion with you has any value whatsoever -- you'll make
>  any statements to back your position, whether or not you know them to
>  be true.

It is as if you don't bother to read what you are replying to.

Notice I said "as it has been reported."  

So help me out here: are you claiming that Martin's card was *not* a
genuine credential from the Transnational Republic?  If so, do you
have any evidence for that?  You seem to be upset at Martin, or at the
people who signed his key, but I can't tell what *exactly* is the
basis for the anger.

You had been saying that Martin presented a forged credential.  But
nothing that has been reported about the incident supports that
conclusion.  To say that his credential was forged, in the absence of
any evidence to the contrary, is strange; why do you think his
credential is doubtful?  Why do you not doubt *every* credential?

And if you say that you *do* doubt every credential, thinking now that
any of them might be forged, what about *this* incident provoked you
to that doubt, since nothing suggests that *this* incident has
anything to do with a forged credential?

In other words, it is you who injected talk of "forgery", and I'm
wondering where that came from, since it manifestly did not come from
Martin, or from anyone else.

Thomas


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

Re: [Debconf-discuss] list of valid documents for KSPs

[Manoj Srivastava]

On 28 May 2006, Thomas Bushnell verbalised:

> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
>> I see you have never been in a large key signing party.  There is a
>> certain expectation of trust, since no one can actrually detect
>> delibrate forgeries.
>
> Except that there was nothing forged about Martin's ID card, as it
> has been reported.  It was exactly what it claimed to be, nothing
> more and nothing less.
>
>> If people start bringing in forged documents, no amount of caution
>> on part of laypeople like most software developers is proof against
>> such deception.  If such deception is accepted behaviour, we may as
>> well throw out thetrust metric, and let /. upload packages into
>> Debian.
>
> This may be true, except that *the document was not forged*.

So you continue to claim.   And since you make statements like
 this with no discernible means of you having verified them, I do not
 see how discussion with you has any value whatsoever -- you'll make
 any statements to back your position, whether or not you know them to
 be true.

manoj
-- 
The happiest time of a person's life is after his first
divorce. J.K. Galbraith
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Alternative keysigning procedures

[Andrew McMillan]

On Sun, 2006-05-28 at 19:23 -0500, martin f krafft wrote:
> Taking this to debian-devel...
> 
> also sprach Andrew McMillan <[EMAIL PROTECTED]> [2006.05.28.1840 -0500]:
> > (c) Allocate partcipants to the groups in a round robin following
> > centrality order and starting with the most central.
> 
> This sounds great. We might want to consider letting people with
> experience specifically opt in for the educational part. I don't
> think it's a good idea to just assume that central people will be
> happy to show up and explain.
> 
> Also, what do we do if the central people don't show up? It's been
> known to happen at KSPs.

I guess that you should choose a number-per-group which allows for
multiple experienced people in each group.

For example, with the Debconf6 keysigning there were ~150 participants.
If we had chosen a group size of 15 then we would reasonably expect that
at least the top 3-5 connected keys in each group would have plenty of
experience.

Of course the fact that the keysignings would be shorter would also
encourage more people to participate, as well.  At least that is my
belief, having been tempted to avoid the last couple myself...

Cheers,
Andrew.


Please keep me in the CC list thanks... :-)

-
Andrew @ Catalyst .Net .NZ  Ltd,  PO Box 11-053, Manners St,  Wellington
WEB: http://catalyst.net.nz/PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201  MOB: +64(272)DEBIAN  OFFICE: +64(4)499-2267
  It may or may not be worthwhile, but it still has to be done.
-



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

Re: Multiarch preparations needed for etch dpkg

[Goswin von Brederlow]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Sat, May 27, 2006 at 01:07:01AM +0200, Goswin von Brederlow wrote:
>> Steve Langasek <[EMAIL PROTECTED]> writes:
>
>> > On Mon, May 22, 2006 at 10:07:00AM +0200, Goswin von Brederlow wrote:
>> >> Only the "dpkg:arch" is required and that can be done with "Provides:
>> >> dpkg-arch" again.
>
>> > Right.  I wonder if even this should strictly be necessary, though, or if
>> > dpkg shouldn't be able to provide the needed features for build-essential 
>> > in
>> > any architecture version...
>
>> The problem is that dpkg has the default architecture hardcoded in the
>> binary and that can't be changed without large side effects.
>
>> If we allow an amd64 dpkg to behave like an i386 dpkg then I bet
>> people will start messing things up and build i386 debs on amd64
>> systems and complain why they can't build amd64 debs.
>
>> Keeping the architecture hardcoded in dpkg and have the architecture
>> of the dpkg (dpkg-dev?) package decide what architecture to build for
>> seems a simple solution.
>
>> But that is just me. And I'm also to lazy to dig through dpkg source
>> to make it provide the same behaviour for any arch.
>
> Well, since the whole reason we would need to declare a dpkg-dev:arch
> dependency is that dpkg-dev is *not* going to be a multiarch package, having
> such a dependency makes it impossible for (e.g.) build-essential:i386 and
> build-essential:amd64 to be co-installable, right?  That seems unfortunate
> to me.

Yes. I don't think it would be wise to have build-essential be
coinstallable for multiple archs.

Note: dpkg-dev is architecture all. The dpkg package itself determines
the native architecture for a system. I guess it wouldn't be too hard
to add a /etc/dpkg/architectures file that sets the native
architecture for building packages, the prefered architecture when
installing packages and any compatible architectures allowed on the
system. We already need some config option to allow/disalow
architectures in case you don't want multiarch.

> Assuming no one comes up with a brilliant^Wcrazy plan to make dpkg-dev
> autoselect the default architecture based on something like the Linux
> personality, I would figure that the sensible thing here is to require
> anyone trying to build packages for a non-default arch to declare this arch
> using the -a option to dpkg-buildpackage.

You can't set your linux personality to i386 on ppc or alpha but
people wanted to use qemu to install and run i386 packages
there. There is also the case of switching between glibc and uclibc
that isn't reflected in the personality. This needs something more
than the "linux32/64" binary.

MfG
Goswin


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

Re: Debian GNU/MINIX

[Jaldhar H. Vyas]

On Thu, 25 May 2006, El Presidente wrote:


I have seen on the internet that someone wanted to port debian to minix3, but
the report was old. Is there anyone that wants to port? I find it usefull.
I don't have the ability to do it, but if it works I will switch to it [ the
next versionof minix will handle driver crashes(no more nasty fs crash - hard
reboot) ].



That would be me.  I've done a lot of compiling of packages over the past 
few months but avoided the hard parts of a full port also my build machine 
has become severely limited in disk space.  Next week I'm getting a 
replacement and at that time I'll tidy things up and hopefully start 
making faster progress.


--
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/


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

Bug#369257: remote bug tracking system doesn't look at versions

[Matthias Klose]

Don Armstrong writes:
> On Mon, 29 May 2006, Matthias Klose wrote:
> > Don Armstrong writes:
> > > On Sun, 28 May 2006, Matthias Klose wrote:
> > > > this bug is fixed for 4.1; with these changes you invalidate the
> > > > information kept in the Debian BTS. Please fix it, or stop it.
> > > 
> > > This has nothing to do with bugs.debian.org or the BTS at all. Talk to
> > > the btslink implementer instead, please. [Reassigning to general
> > > instead of closing outright in case there is a better place; otherwise
> > > it should be closed.]
> > 
> > with the very same logic you could close bugs filed against
> > ftp.debian.org about changing overrides or removing packages from
> > the archive.
> 
> If I was an ftpmaster or filed those bugs, yes... but since I'm not, I
> won't be closing them.
>  
> > you can fix it by not processing the mails affecting some packages,
> > so it's appropriate to file against bugs.debian.org.
> 
> 1) There's nothing wrong with the messages that have been sent by
> bts-link.

the only thing that is correct. is the syntax. everything else is
wrong. the messages should have been generated for gcc-snapshot (if at
all), but not for 4.1.

> 2) While I can do so, adding administrative prohibitions over
> something which should be worked out between the GCC maintainers and
> the btslink maintainers is not something that I'm going to do as an
> initial step.

that's difficult, emails to to
[EMAIL PROTECTED] are automatically rejected,
if you're not subscribed. I really do not intend to subscribe to each
system / ML, which sends bogus control messages.

> 3) If the GCC maintainers don't want btslink modifying any non-user
> tags for their packages, I'm fairly sure that the btslink maintainer
> can implement that fairly simply; they should just communicate with
> eachother instead of expecting the bts administrators to mediate for
> them via administrative prohibitions.
> 
> > sorry, no. A bug tracking system doesn't track responsibilities, but
> > problems. That is a problem with the information in the BTS. It
> > doesn't matter if the changes can be done by the BTS admins or
> > others.
> 
> What problems with the information in the BTS are you talking about?

the usertags, which are wrongly set and removed.

please don't get me wrong; generally the btslink information is
useful, but I do see the BTS maintainers in charge as well, if the
system is "misused". we did see this in the past with unreflected
changes of the forwarded information, now with wrong usertags. what
comes next?

  Matthias


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

Re: [Debconf-discuss] list of valid documents for KSPs

[Thomas Bushnell BSG]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> I see you have never been in a large key signing party.  There
>  is a certain expectation of trust, since no one can actrually detect
>  delibrate forgeries. 

Except that there was nothing forged about Martin's ID card, as it has
been reported.  It was exactly what it claimed to be, nothing more and
nothing less.

> If people start bringing in forged documents,  no amount of
>  caution on part of laypeople like most software developers is proof
>  against such deception.  If such deception is accepted behaviour, we
>  may as well throw out thetrust metric, and let /. upload packages
>  into Debian.

This may be true, except that *the document was not forged*.



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

Re: gnome 1 packages up for adoption

[Thomas Bushnell BSG]

Loïc Minier <[EMAIL PROTECTED]> writes:

> On Sat, May 27, 2006, Steve Langasek wrote:
>>python-gnome has a build-dependency on libgtkhtml-dev which
>> should be trivially removable since none of its binary packages use it.
>
>  python-gnome is also deprecated and should go away when possible, I've
>  filed bugs on the rdeps already.  (As Steve already pointed out, this
>  caused me to make the same mistake as Thomas, because apt-cache
>  rdepends includes Suggests and Conflicts).

Lol, I get more than just that from rdepends.  I get packages that
don't even exist any more.

Re: Please revoke your signatures from MartinKraff's keys

[Thomas Bushnell BSG]

Paul Johnson <[EMAIL PROTECTED]> writes:

>> But the standards of "reasonable" are different for minors than for
>> adults.  Right?
>
> Constitutional law doesn't differentiate.

Yes, it does.


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

Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys

[Thomas Bushnell BSG]

Junichi Uekawa <[EMAIL PROTECTED]> writes:

> This has opened a can of worms; because your transnational ID was as
> official as it could get. Most of us do not know what other countries
> consider to be official, and it's more of an intent and goodwill
> rather than scientific or legally binding officialness that we are
> signing and interchaning keys based on ID cards.

Wow, you thought there was a country called the Transnational
Republic?  Or you thought that Germany prints ID cards with
"Transnational Republic" on them?  Or what, exactly?


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

Re: Alternative keysigning procedures

[Martin Langhoff]

On 5/29/06, martin f krafft <[EMAIL PROTECTED]> wrote:

Also, what do we do if the central people don't show up? It's been
known to happen at KSPs.


Put more than one in each subgroup, and have a coordinator ready to
shift the central people around if a given subgroup is really
orphaned. Or split the orphan group across all the other groups.

Means that the coordinators should be checking attendance of the
well-connected people at the KSP, but that's usually easy at a DebConf
as connectedness goes well beyond web-of-trust -- that is, we all know
them ;-)

Overall, it sounds like a good plan to me.



martin

Bug#369257: remote bug tracking system doesn't look at versions

[Don Armstrong]

On Mon, 29 May 2006, Matthias Klose wrote:
> Don Armstrong writes:
> > On Sun, 28 May 2006, Matthias Klose wrote:
> > > this bug is fixed for 4.1; with these changes you invalidate the
> > > information kept in the Debian BTS. Please fix it, or stop it.
> > 
> > This has nothing to do with bugs.debian.org or the BTS at all. Talk to
> > the btslink implementer instead, please. [Reassigning to general
> > instead of closing outright in case there is a better place; otherwise
> > it should be closed.]
> 
> with the very same logic you could close bugs filed against
> ftp.debian.org about changing overrides or removing packages from
> the archive.

If I was an ftpmaster or filed those bugs, yes... but since I'm not, I
won't be closing them.
 
> you can fix it by not processing the mails affecting some packages,
> so it's appropriate to file against bugs.debian.org.

1) There's nothing wrong with the messages that have been sent by
bts-link. Martin marked the bug as forwarded, so btslink marked the
bug as being an upstream bug which it appears to be since there's an
entry in upstream's BTS.

2) While I can do so, adding administrative prohibitions over
something which should be worked out between the GCC maintainers and
the btslink maintainers is not something that I'm going to do as an
initial step.

3) If the GCC maintainers don't want btslink modifying any non-user
tags for their packages, I'm fairly sure that the btslink maintainer
can implement that fairly simply; they should just communicate with
eachother instead of expecting the bts administrators to mediate for
them via administrative prohibitions.

> sorry, no. A bug tracking system doesn't track responsibilities, but
> problems. That is a problem with the information in the BTS. It
> doesn't matter if the changes can be done by the BTS admins or
> others.

What problems with the information in the BTS are you talking about?


Don Armstrong

-- 
No amount of force can control a free man, a man whose mind is free
[...] You can't conquer a free man; the most you can do is kill him.
 -- Robert Heinlein _Revolt in 2010_ p54

http://www.donarmstrong.com  http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: Alternative keysigning procedures

[Robert Collins]

On Sun, 2006-05-28 at 19:23 -0500, martin f krafft wrote:
> Taking this to debian-devel...
> 
> also sprach Andrew McMillan <[EMAIL PROTECTED]> [2006.05.28.1840 -0500]:
> > (c) Allocate partcipants to the groups in a round robin following
> > centrality order and starting with the most central.
> 
> This sounds great. We might want to consider letting people with
> experience specifically opt in for the educational part. I don't
> think it's a good idea to just assume that central people will be
> happy to show up and explain.
> 
> Also, what do we do if the central people don't show up? It's been
> known to happen at KSPs.

Run the allocator routine again ?

Rob

-- 
GPG key available at: .


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

Re: Alternative keysigning procedures

[martin f krafft]

Taking this to debian-devel...

also sprach Andrew McMillan <[EMAIL PROTECTED]> [2006.05.28.1840 -0500]:
> (c) Allocate partcipants to the groups in a round robin following
> centrality order and starting with the most central.

This sounds great. We might want to consider letting people with
experience specifically opt in for the educational part. I don't
think it's a good idea to just assume that central people will be
happy to show up and explain.

Also, what do we do if the central people don't show up? It's been
known to happen at KSPs.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"it is only the modern that ever becomes old-fashioned." 
-- oscar wilde


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

Re: Bug#368985: ITP: mod-bt -- BitTorrent tracker for the Apache2 web server

[Tyler MacDonald]

Steve Langasek <[EMAIL PROTECTED]> wrote:
> > - When the API becomes incompatible (which would implicitly make the
> > ABI incompatible), both the -dev and library package should increment their
> > numbers.
> 
> > - When the ABI becomes incompatible without affecting the API, only
> > the library package should increment it's number.
> 
> > Is that right?
> 
> With changing the package name on API changes being optional as well, since
> API changes generally affect build-dependencies only, not dependencies, are
> thus largely invisible to users, and in the general case don't tend to
> happen in a way that justifies updates to all packages that would
> build-depend on it.

Makes sense...

> But if you think you'll be making sufficient backwards-incompatible changes
> to the library API to warrant such package name changes, yes, the above is
> the right way to go about it.

I do. I can easily see thread safety and abstracting database
interaction causing API changes in the future. Thanks!

- Tyler


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

Alternative keysigning procedures

[Andrew McMillan]

On Sun, 2006-05-28 at 04:54 -0700, Steve Langasek wrote:
> On Sat, May 27, 2006 at 04:47:20PM -0500, martin f krafft wrote:
> 
> > I imagine an improved protocol for the keysigning, which is based on
> > an idea I overheard after the party (and someone mentioned it in the
> > thread): instead of the everyone-signs-everyone approach, it might
> > be interesting to investigate forming groups (based on connectivity
> > statistics) such that everyone's mean distance in the web of trust
> > can be increased by a fair amount in a short amount of time. At the
> > same time, such circles could be used for education by those with
> > high connectivity (and thus much experience). The problem here is of
> > course the somewhat unreliable attendance of people. Comments
> > welcome.
> 
> I agree that this is the way to go.  Who has time to work on implementing
> the necessary code?

It is something that has been discussed before, and it was certainly
something that I was discussing with Anibal after the keysigning.

The concept that Anibal and I were discussing post-keysigning was as
follows:

(a) Order the list of keysigning participants by centrality.

(b) Decide on a group size for the keysigning.  Something around 10-15
seems likely to be a worthwhile choice.

(c) Allocate partcipants to the groups in a round robin following
centrality order and starting with the most central.

Produce the keysigning list, with group numbers in addition to the key
numbers (or perhaps instead of).

All of the other pre-keysigning activities are the same.

At the keysigning, the initial reading out of MD5 / SHA1 of the
keysigning list would still happen, as it normally does.

After this, the keysigning would follow two parts:

Part One


People split into their assigned groups and cross-sign only within those
groups.  The intention is that these groups are small enough that
everyone can see everything that is going on.  Experienced people can be
observed performing comprehensive checks, and inexperienced people can
be educated.

Part Two


Optionally, after part one is complete, some people may choose to
personally and individually participate in keysignings outside of their
assigned groups.  Note that this can still be facilitated by the fact
that both individuals have their fingerprints within the keysigning
list.

==
Finito.
And gradually it fades out.


Rationale
=

Keysignings stop being fun ways to meet people after about 15 minutes.
For me, the worst experience was in Helsinki, with around 300 people,
getting sunburned in a carpark.

Keysignings are about improving the web of trust.  The most efficient
enhancement of the web of trust will be if the edges exchange keys with
the middle.  Signing keys with _everyone_ is inefficient, unnecessary
and promotes competitive behaviour rather than trust relationships.

Keysignings should promote education of WoT best practices, and not
_worst_ practices.

Keysignings should not take more than one hour.


So that's my 2c.


If people agree that this would be a useful approach, I am willing to
undertake to provide some additional tools within the signing-party
package to make such a keysigning more easily doable.

Of course the above does not address how to handle the people who didn't
manage to get their act together soon enough to be in the initial list.
There are several ways to deal with this also:

1) The "additional list" is produced, SHA1'd, read, but these people can
only participate in "Part Two" above.

2) The "additional list" is produced and these people are also
allocated to groups in round robin, but randomly, rather than in
centrality order.

and no doubt there are other ways to deal with it...


Regards,
Andrew.

PS.  Please feel free to CC me on replies, since I am not subscribed to
Debian Devel and I _do_ have sane procmail dupe filters :-)

-
Andrew @ Catalyst .Net .NZ  Ltd,  PO Box 11-053, Manners St,  Wellington
WEB: http://catalyst.net.nz/PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201  MOB: +64(272)DEBIAN  OFFICE: +64(4)499-2267
Be different: conform.
-



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

Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys

[Matthew Garrett]

Junichi Uekawa <[EMAIL PROTECTED]> wrote:

> This has opened a can of worms; because your transnational ID was as
> official as it could get. Most of us do not know what other countries
> consider to be official, and it's more of an intent and goodwill
> rather than scientific or legally binding officialness that we are
> signing and interchaning keys based on ID cards.

If there's anyone who should be revoking signatures, it's the people who 
are signing keys without being fairly certain that they belong to the 
correct person. This really shouldn't be controversial.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: Shouldn't we have more ftp masters ?

[Stefano Zacchiroli]

On Sun, May 28, 2006 at 11:42:16PM +0200, Bartosz Fenski aka fEnIo wrote:
> I think it's debconf time and everything is slower, but will be as
> usual when it's end and everyone came back to his/her normal work.

The point of the first mail was exactly about that. NEW queue can't stay
unprocessed just because 1 or 2 ftp masters/assistants are attending
debconf or on vacation. They have all rights of doing so, of course! But
we need someone else able to take over their duties in this respect.

I do think that NEW processing is rather important for package
maintenance and that it can hinder development.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys

[Junichi Uekawa]

Hi,

> First of all, my name is Martin Felix Krafft (with a final 't'), and
> my GPG key ID is 0x330c4a75. The unofficial ID I presented listed
> that name (without the middle name), a photo is available from [1]
> (sorry, can't do better now). Thus, the ID card is an unofficial
> card, but the identity it claims is my real identity, not a fake
> one. To me, this is an important distinction in the context of this
> discussion.

This has opened a can of worms; because your transnational ID was as
official as it could get. Most of us do not know what other countries
consider to be official, and it's more of an intent and goodwill
rather than scientific or legally binding officialness that we are
signing and interchaning keys based on ID cards.


regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


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

Bug#369257: remote bug tracking system doesn't look at versions

[Matthias Klose]

reopen 369257
severity 369257 serious
thanks

Don Armstrong writes:
> reassign 369257 general
> severity 369257 normal
> thanks
> 
> On Sun, 28 May 2006, Matthias Klose wrote:
> > this bug is fixed for 4.1; with these changes you invalidate the
> > information kept in the Debian BTS. Please fix it, or stop it.
> 
> This has nothing to do with bugs.debian.org or the BTS at all. Talk to
> the btslink implementer instead, please. [Reassigning to general
> instead of closing outright in case there is a better place; otherwise
> it should be closed.]

with the very same logic you could close bugs filed against
ftp.debian.org about changing overrides or removing packages from the
archive.

you can fix it by not processing the mails affecting some packages, so
it's appropriate to file against bugs.debian.org.

Steve Langasek writes:
> On Sun, May 28, 2006 at 06:50:21PM +0200, Matthias Klose wrote:
> > Package: bugs.debian.org
> > Severity: serious
> 
> > this bug is fixed for 4.1; with these changes you invalidate the
> > information kept in the Debian BTS. Please fix it, or stop it.
> 
> > If you do want to do it correct, you have to keep information, which
> > package is built from which branch.
> 
> I'm pretty sure this bug doesn't belong to bugs.debian.org, given that it's
> not the BTS admins making these changes?

sorry, no. A bug tracking system doesn't track responsibilities, but
problems.  That is a problem with the information in the BTS. It
doesn't matter if the changes can be done by the BTS admins or others.

Or would you suggest a severity grave because of data loss/corruption?
Please don't suggest that it's still possible to track down these
changes following each control mail.

  Matthias


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

Processed: Re: Bug#369257: remote bug tracking system doesn't look at versions

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reopen 369257
Bug#369257: remote bug tracking system doesn't look at versions
Bug reopened, originator not changed.

> severity 369257 serious
Bug#369257: remote bug tracking system doesn't look at versions
Severity set to `serious' from `normal'

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: Multiarch preparations needed for etch dpkg

[Steve Langasek]

On Sat, May 27, 2006 at 01:07:01AM +0200, Goswin von Brederlow wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:

> > On Mon, May 22, 2006 at 10:07:00AM +0200, Goswin von Brederlow wrote:
> >> Only the "dpkg:arch" is required and that can be done with "Provides:
> >> dpkg-arch" again.

> > Right.  I wonder if even this should strictly be necessary, though, or if
> > dpkg shouldn't be able to provide the needed features for build-essential in
> > any architecture version...

> The problem is that dpkg has the default architecture hardcoded in the
> binary and that can't be changed without large side effects.

> If we allow an amd64 dpkg to behave like an i386 dpkg then I bet
> people will start messing things up and build i386 debs on amd64
> systems and complain why they can't build amd64 debs.

> Keeping the architecture hardcoded in dpkg and have the architecture
> of the dpkg (dpkg-dev?) package decide what architecture to build for
> seems a simple solution.

> But that is just me. And I'm also to lazy to dig through dpkg source
> to make it provide the same behaviour for any arch.

Well, since the whole reason we would need to declare a dpkg-dev:arch
dependency is that dpkg-dev is *not* going to be a multiarch package, having
such a dependency makes it impossible for (e.g.) build-essential:i386 and
build-essential:amd64 to be co-installable, right?  That seems unfortunate
to me.

Assuming no one comes up with a brilliant^Wcrazy plan to make dpkg-dev
autoselect the default architecture based on something like the Linux
personality, I would figure that the sensible thing here is to require
anyone trying to build packages for a non-default arch to declare this arch
using the -a option to dpkg-buildpackage.

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


signature.asc
Description: Digital signature

Re: Please revoke your signatures from Martin Kraff's keys

[Javier Fernández-Sanguino Peña]

On Sat, May 27, 2006 at 04:47:20PM -0500, martin f krafft wrote:
> Dear Manoj, dear fellow DDs,

Hi, I'm just going to address the question you made that was directed to me.

> also sprach Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> 
> [2006.05.25.1300 -0500]:
> > FWIW, I noted down those keys I would *not* sign and didn't tell
> > the people at the KSP that I would not sign them. I guess his
> > experiment "only one in ten said that they would *not* sign it" is
> > moot unless he backs it up with the signatures he eventually got
> > sent from those he showed a wrong ID to.
> 
> Out of curiosity, did you mark my key to be "questionable"?

Yes. But then again, you have to trust that I did since you cannot 
see the (2) I added next to your name and the ID check :-)
(on a scale of 1-5 with 5 being the highest). You got a (2) (and
not a (1) like others did) not because of your ID but because we actually
talked throughout the Debconf.

> The point you raise is a valid one. However, given how many people
> just don't sign keys after keysignings, the data would be skewed in
> the other direction.

True. But skew is always present in lies^statistics :-)

> I do not yet understand why some people do not confront those with
> questionable IDs. Maybe you can shine some light on that.

For two reasons:

1.- People might not have a better ID (I guess I trust people to bring
their best ID to the KSP) and that means that: 
  a) they will be ashamed that they cannot provide a better ID
  b) they will be offended that I don't trust their national ID
  c) they will not understand why I'm asking for a better ID

2.- Lack of time and peer pressure ("you are taking too long!")

The only case in which I would bother explaining is 1-b, but with 2) taken
into account I did not had time to explain why their ID was not sufficient
for me. And I can actually do that (with a canned e-mail) after the KSP.

Hope that explains it.

Javier



signature.asc
Description: Digital signature

Re: Bug#367028: ITP: cpulimit -- limits the cpu usage of a process

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

gregor herrmann wrote:
> On Fri, May 12, 2006 at 05:34:23PM -0500, Ron Johnson wrote:
> 
>>>   Description : limits the cpu usage of a process
>>>  cpulimit is a simple program that attempts to limit the cpu usage of a
>>>  process (expressed in percentage, not in cpu time). This is useful to
>>>  control batch jobs, when you don't want then to eat too much cpu. It does 
>>> not
>>>  act on the nice value or other priority stuff, but on the real cpu usage.
>> I thought nice was supposed to handle these kinds of things, and
>> that a busy CPU is a *good* thing.
> 
> On an otherwise idle box even a process (re-)niced to 19 uses all the
> CPU. That might be desirable often but in other cases (e.g. when
> CPU temperature is an issue) you might still want to say "assign this
> process only xy% of CPU resources".

Roll-your-own CPU scaling...

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

iD8DBQFEeh1YS9HxQb37XmcRAhXaAJ46xZtVYGCD+r+ZDG/QAAWsxc8b/QCgxQmM
c8e/oKVrca4K2/YeuG44t+Y=
=Ij/N
-END PGP SIGNATURE-


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

Re: Shouldn't we have more ftp masters ?

[Bartosz Fenski aka fEnIo]

On Sun, May 28, 2006 at 08:27:26PM +0200, Hans Kroegle wrote:
>It seems that the ftp-masters haven't looked at the NEW queue
> during the last month (or maybe only for java), and its size is still
> increasing (see http://haydn.debian.org/~corsac-guest/new/ ). I agree
> that they may want to take vacations, but IMHO, NEW is such an
> important process for Debian that it shouldn't be left aside like this
> for a so long time. It's why I think that if there isn't currently
> enought ftp-masters to ensure that the NEW process will work without
> interruptions, we should have more ftp-masters.
> 
> What do you think about that ?

I think it's debconf time and everything is slower, but will be as
usual when it's end and everyone came back to his/her normal work.

regards
fEnIo

-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

Re: Please revoke your signatures from Martin Kraff's keys

[Javier Fernández-Sanguino Peña]

On Sat, May 27, 2006 at 01:55:44PM -0500, Manoj Srivastava wrote:
> On 27 May 2006, Gunnar Wolf verbalised:
> > For me, yes, some questions asked, some delays involved, but no
> > detailed background checks. I'm sure neither the FBI or the CIA (or,
> > as for Mexican authorities, CISEN or PGR) were involved.
> 
> Then some government organizations do not take as stringent a
>  set of precautions as others do. That, by itself, is an unsurprising
>  statement. 

In Spain, you are *required* to have a national ID card (if you are
over 18 years old), that means the Police will provide you with one
regardless of what background checks they might want to run. That is, they
*have* to provide you with a national ID card. Same happens with the passport
BTW. Unless they want to remove you of it (because you are being prosecuted
and they fear you might ran away), they *have* to provide you with a
passport. Not because it is a requirement, but because you have the *right*
to travel abroad (at least it is in Spain)

Regards

Javier


signature.asc
Description: Digital signature

Re: not running depmod at boot time

[Marco d'Itri]

On May 28, Marc Wilson <[EMAIL PROTECTED]> wrote:

> On Thu, May 25, 2006 at 09:35:31AM +0200, Marco d'Itri wrote:
> > "make install" already runs depmod.
> What if you don't use the 'install' target?  I certainly don't.  Does the
> 'modules_install' target also run depmod?
Yes.

> I don't claim to understand what
> the comments in the kernel Makefile say about it, other than that they
> imply there's some dependency on System.map.
Don't worry, understanding of the topic being discussed has been
optional for a long time on [EMAIL PROTECTED]

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: not running depmod at boot time

[Marc Wilson]

On Thu, May 25, 2006 at 09:35:31AM +0200, Marco d'Itri wrote:
> "make install" already runs depmod.

What if you don't use the 'install' target?  I certainly don't.  Does the
'modules_install' target also run depmod?  I don't claim to understand what
the comments in the kernel Makefile say about it, other than that they
imply there's some dependency on System.map.

Speaking as the "user" in this discussion, if depmod is no longer going to
be run at boot, and my current kernel installation method isn't going to do
it, I need to make sure I do it myself or change how I install kernels.

-- 
 Marc Wilson | Cats, no less liquid than their shadows, offer no
 [EMAIL PROTECTED] | angles to the wind.


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

Bug#368546: more information

[M. Dietrich]

after another slowdown last week i installed metacity. i killed
sawfish and started metacity without X restart. immediatly everything
was fine. so i assume this is a bug with sawfish. probably not with
sawfish itself but the integration of sawfish with gnome (and/or my
settings).


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

Bug#369257: remote bug tracking system doesn't look at versions

[Don Armstrong]

reassign 369257 general
severity 369257 normal
thanks

On Sun, 28 May 2006, Matthias Klose wrote:
> this bug is fixed for 4.1; with these changes you invalidate the
> information kept in the Debian BTS. Please fix it, or stop it.

This has nothing to do with bugs.debian.org or the BTS at all. Talk to
the btslink implementer instead, please. [Reassigning to general
instead of closing outright in case there is a better place; otherwise
it should be closed.]


Don Armstrong

-- 
What I can't stand is the feeling that my brain is leaving me for 
someone more interesting.

http://www.donarmstrong.com  http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Bug#369257: marked as done (remote bug tracking system doesn't look at versions)

[Debian Bug Tracking System]

Your message dated Sun, 28 May 2006 12:10:07 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Bug#369257: remote bug tracking system doesn't look at versions
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: bugs.debian.org
Severity: serious

this bug is fixed for 4.1; with these changes you invalidate the
information kept in the Debian BTS. Please fix it, or stop it.

If you do want to do it correct, you have to keep information, which
package is built from which branch.

[EMAIL PROTECTED] writes:
> #
> # bts-link upstream status pull for source package gcc-4.1
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> 
> user [EMAIL PROTECTED]
> 
> # remote status report for #356569
> #  * http://gcc.gnu.org/PR26757
> #  * remote status changed: NEW -> REOPENED
> usertags 356569 - status-NEW
> usertags 356569 + status-REOPENED
> 
> thanks

--- End Message ---
--- Begin Message ---
On Sun, May 28, 2006 at 06:50:21PM +0200, Matthias Klose wrote:
> Package: bugs.debian.org
> Severity: serious

> this bug is fixed for 4.1; with these changes you invalidate the
> information kept in the Debian BTS. Please fix it, or stop it.

> If you do want to do it correct, you have to keep information, which
> package is built from which branch.

I'm pretty sure this bug doesn't belong to bugs.debian.org, given that it's
not the BTS admins making these changes?

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


signature.asc
Description: Digital signature
--- End Message ---

Processed: Re: Bug#369257: remote bug tracking system doesn't look at versions

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 369257 general
Bug#369257: remote bug tracking system doesn't look at versions
Bug reassigned from package `bugs.debian.org' to `general'.

> severity 369257 normal
Bug#369257: remote bug tracking system doesn't look at versions
Severity set to `normal' from `serious'

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: Shouldn't we have more ftp masters ?

[Michael Banck]

Your mail is not about general development of the Debian distribution
and thus rather on topic on debian-project, please follow-up there.

On Sun, May 28, 2006 at 08:27:26PM +0200, Hans Kroegle wrote:
>It seems that the ftp-masters haven't looked at the NEW queue
> during the last month (or maybe only for java), and its size is still
> increasing (see http://haydn.debian.org/~corsac-guest/new/ ). I agree
> that they may want to take vacations, but IMHO, NEW is such an
> important process for Debian that it shouldn't be left aside like this
> for a so long time. It's why I think that if there isn't currently
> enought ftp-masters to ensure that the NEW process will work without
> interruptions, we should have more ftp-masters.

I don't think NEW is that critical, but it would sure be nice if it gets
processed from time to time.

The FTP-masters are choosing additions to their team themselves and I
think they are the best in place to judge when they need help.

As for the current situation of both ftp-assisstants being on leave,
maybe one of the regular ftp-masters could jump in and process the NEW
queue for the time being?  I have CC'd them on this mail.


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Shouldn't we have more ftp masters ?

[Hans Kroegle]

Hi,

   It seems that the ftp-masters haven't looked at the NEW queue
during the last month (or maybe only for java), and its size is still
increasing (see http://haydn.debian.org/~corsac-guest/new/ ). I agree
that they may want to take vacations, but IMHO, NEW is such an
important process for Debian that it shouldn't be left aside like this
for a so long time. It's why I think that if there isn't currently
enought ftp-masters to ensure that the NEW process will work without
interruptions, we should have more ftp-masters.

What do you think about that ?


--
H. K.

Re: [Debconf-discuss] list of valid documents for KSPs

[Manoj Srivastava]

On 27 May 2006, Thomas Bushnell spake thusly:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>
>> But then again people could lookup say mexican IDs and visas before
>> going to a KSP in mexico so they have some clue what it should look
>> like.
>
> Actually, in the present case, I believe it turns out that Martin
> Krafft's ID was exactly what it claimed to be, an identification
> card issued by the Transnational Republic, which is not a fake-ID
> shop, but is also not an actual government.
>
> So if anything, the problem is *not* that we have trouble
> distinguishing genuine credentials from forged ones.  
>
> No.  The problem is that people have trouble distinguishing genuine
> *nations* from forged ones.
>
> So all those people who believe there is a country known as the
> "Transnational Republic", should rightly have egg on their faces.

I see you have never been in a large key signing party.  There
 is a certain expectation of trust, since no one can actrually detect
 delibrate forgeries. There items I used to check on were the
 photograph, seplling of the name, expiration date for the document,
 and, optionally, age.  Often foreign documents have strange names
 (and the propensity for some languages (like sanskrit or german) to
 concatenate words make for document titles to be unintelligible, so
 often were not looked at -- since good faith expectations were that
 people were not trying to game the system.

If people start bringing in forged documents,  no amount of
 caution on part of laypeople like most software developers is proof
 against such deception.  If such deception is accepted behaviour, we
 may as well throw out thetrust metric, and let /. upload packages
 into Debian.

manoj

-- 
"What people have been reduced to are mere 3-D representations of
their own data." -- Arthur Miller
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Please revoke your signatures from MartinKraff's keys

[Manoj Srivastava]

On 27 May 2006, Paul Johnson told this:

> On Saturday 27 May 2006 16:48, Thomas Bushnell BSG wrote:
>> Paul Johnson <[EMAIL PROTECTED]> writes:
>>> On Saturday 27 May 2006 16:03, Ron Johnson wrote:
 Lionel Elie Mamane wrote:
> On Sat, May 27, 2006 at 05:19:21PM -0500, Manoj Srivastava wrote:
>> On 27 May 2006, Lionel Elie Mamane spake thusly:
>>> On Sat, May 27, 2006 at 02:04:31PM -0500, Manoj Srivastava wrote:
 On 27 May 2006, Lionel Elie Mamane stated:

 [snip]

> That's precisely the issue. The standards of "reasonable" are
> different for minors than they are for 'normal' people.

 Minors are *normal*.  They are not *adults*.
>>>
>>> The US constitution does not say, "Void if you're a minor."
>>
>> But the standards of "reasonable" are different for minors than for
>> adults.  Right?
>
> Constitutional law doesn't differentiate.

Constitutional lawsays"reasonable" .  reasonable people then
 define what reasonable means.

manoj
-- 
Work expands to fill the time available. Cyril Northcote Parkinson,
"The Economist", 1955
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: remote bug tracking system doesn't look at versions

[Pierre Habouzit]

Le Dim 28 Mai 2006 18:50, Matthias Klose a écrit :
> Package: bugs.debian.org
> Severity: serious
>
> this bug is fixed for 4.1; with these changes you invalidate the
> information kept in the Debian BTS. Please fix it, or stop it.
>
> If you do want to do it correct, you have to keep information, which
> package is built from which branch.
>
> [EMAIL PROTECTED] writes:
> > #
> > # bts-link upstream status pull for source package gcc-4.1
> > # see
> > http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> > #
> >
> > user [EMAIL PROTECTED]
> >
> > # remote status report for #356569
> > #  * http://gcc.gnu.org/PR26757
> > #  * remote status changed: NEW -> REOPENED
> > usertags 356569 - status-NEW
> > usertags 356569 + status-REOPENED
> >
> > thanks

I completely fail to see where any problem lies here.. the mail you 
quote only changes usertags, that are used as a storage of the current 
upstream bugs statuses. and sorry, but upstream bug PR26757 is 
*REOPENED* and that's the information I store. So it does what it's 
supposed to do.

I never, (like in never ever) reopen bugs, I only track upstream status 
changes and in *some*[1] cases changes the fixed-upstream/wontfix tags 
accordingly. Like tbm said on the lists, fixed-upstream is (like the 
`fixed' state) an information that the maintainer just has to 
ackowledge/validate adding the valuable versions it needs. I will NEVER 
EVER touch the closed/open state of a debian bug, and I even don't 
fight against fixed-upstream/wontfix tags changes from you.

So please explain what was done wrong here ?

I will be happy to implement what you consider beeing the best way to 
work for bts-link... 

I Cc: debian-devel, because I'd like that people really tell what they 
need, and want to happen with bts-link. Those quite aggressive bug 
reports, that are even not accurate, do not help.

there is a few concern people have with bts-link, and all of them are 
worked on (especially the uri's issues on the BTS, that are not 
interpreted correctly). I am open to any suggestion, for the second 
time Matthias, could you please use less offending ways to express 
them, especially when it's clear to everyone that my goal is to improve 
and soften the work conditions of the maintainers, and not to fight 
against them, I've more interesting things to do.


 [1] those case are when an upstream bug status goes from a open state
 to a closed state or the reverse.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpNxRZgwRK4y.pgp
Description: PGP signature

Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys

[Christian Perrier]

Quoting Andreas Barth ([EMAIL PROTECTED]):

> I know that Peter Palfrader (weasel) submits sometimes a clear fake key
> to KSPs and looks for people signing it. (No, there is nobody there who
> claims to be that person. Only the key on the list.)


For future reference, I personnally dislike people trying to trick
down other people.

If the above is meant to later mail the people inadvertently signing
the "fake" key, I'm OK with it.

If this is intended to make a self-statement like " this person is not
thrustworthy because she signed a key that wasn't in the keysigning
party", then I think this crosses my own personal line




signature.asc
Description: Digital signature

Re: proposal for a more efficient download process

[Goswin von Brederlow]

"curt manucredo (hansycm)" <[EMAIL PROTECTED]> writes:

> Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote:
>
>  >Nope. You will need to keep all normal debs anyway, for new
>  >installations.
>
> i thought it could be possible in the end to download the tree-package
> and all its patches to then have the latest package for a new install!
> so i thought there will be no more need for a lot of full packages. is
> it not? one of the advantages could be that you have more versions
> available then just the latest - this would be great for sid!

But stupid for stable and, since testing is the testbed for the next
stable, for testing also. You need a full deb there to build proper
CDs and DVDs. And since you don't know what version will make it into
stable beforehand you have to save the full deb of every version.

MfG
Goswin


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

Re: [Debconf-discuss] list of valid documents for KSPs

[Henning Makholm]

Scripsit Gunnar Wolf <[EMAIL PROTECTED]>

> There is something, though, that I think would be a worthy addition to
> future KSPs, if we continue to hold them: Many of us have our photo as
> part of our key. Maybe if the printed sheet was not plain-text but
> included those photos that are available, it would be at least a
> slight improvement?

How exactly would that help anything? That is, under which attack
model would it improve the security of the system?

Note that when you stand before a stranger at a KSP, it is _not_ in
doubt that he controls the _key_ that he wants you to sign. (Or
rather: if he does not control it, he would have nothing to gain from
having you sign it). Submitting a (signed) photo in avance would prove
nothing but his control of the key, and that is not an intersting
property.

What _is_ in doubt is that his real-life identify is the same as the
user id that he wants you to sign. And the fact that someone has a
photograph of himself says nothing about what his name is. _Anybody_
can have a photograph of themselves, easily, no matter whether they
are who they claim to be or not.

Thus the relevant attack model is: An attacker creates a key and types
in somebody else's name as an uid. He goes to key-signing parties and
tries to get other participants to sign the connection between his
actual key fingerprint and the false name he has assumed.

How would it help prevent such an attack that the attacker could
supply a photo of his own to the KSP organizers and have all of the
participants check that he looks like he does? On the contrary, it
would inspire confusion because some participants would _think_ that
the fact that the fraudster looks exactly like the photo he himself
supplied could somehow mitigate the mismatch with the photo on the
official ID document he presents.

-- 
Henning Makholm  "Ambiguous cases are defined as those for which the
   compiler being used finds a legitimate interpretation
   which is different from that which the user had in mind."


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

Re: Request for key signing in Shanghai

[Sha Li Jun]

Ralf Treinen wrote:


On Sun, May 28, 2006 at 12:57:10AM +0800, Thomas Goirand wrote:
 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stephen Gran wrote:
   


This one time, at band camp, Thomas Goirand said:
 


Hello!

Is there somebody in Shanghai from Debian able to check my ID
and sign my key? If there is none, is there somebody in
Singapore, where I might be able to go? I wouldn't be able to
go in Hongkong (because of visa problems) where I could see there
was somebody available.
   


I don't know off hand.  The list (probably slightly outdated)
of people  offering key signing is at
https://nm.debian.org/gpg_offer.php
 


It's a shame it's not up-to-date. Is there somewhere it's more accurate?
   



What make you thinkit is not up to date? Debian developers are not
obliged to register there, and some decide tonot make their adresses
public. 

 


Will there be somebody around in Paris or in Florida this summer for
signing my key??? (I might travel there...)
   



https://nm.debian.org/gpg_offer.php :-)

-Ralf.
 

take a look at the www.shlug.org, but this web site is in chinese, all 
shlug guys are chinese.



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

re: proposal for a more efficient download process

[curt manucredo (hansycm)]

Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote:

>Anyway, this was proposed some times now. Have you actually read the >old
>threads and can explain why your proposal is better and actually works?
>Why haven't you implemented it yet?

not right now. i just have found out that there were some same 
discustions about it just some days before. sorry. i never have claimed 
that to be my idea. i just sad it is a proposal. since i am new on 
debian-devel i will probably have to find out even more. so please let 
me have a chance to do so! and i never said my proposal will work 
though. well, i just thought i would have come up with a new idea. how 
stupid! :-)


--
greetings from austria

well, though i think i can't fix that problem, but i believe i can make 
a workaround!

*
curt manucredo
[EMAIL PROTECTED]

"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein
--


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

Re: Request for key signing in Shanghai

[Ralf Treinen]

On Sun, May 28, 2006 at 12:57:10AM +0800, Thomas Goirand wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Stephen Gran wrote:
> > This one time, at band camp, Thomas Goirand said:
> >> Hello!
> >>
> >> Is there somebody in Shanghai from Debian able to check my ID
> >> and sign my key? If there is none, is there somebody in
> >> Singapore, where I might be able to go? I wouldn't be able to
> >> go in Hongkong (because of visa problems) where I could see there
> >> was somebody available.
> >
> > I don't know off hand.  The list (probably slightly outdated)
> > of people  offering key signing is at
> > https://nm.debian.org/gpg_offer.php
> 
> It's a shame it's not up-to-date. Is there somewhere it's more accurate?

What make you thinkit is not up to date? Debian developers are not
obliged to register there, and some decide tonot make their adresses
public. 

> Will there be somebody around in Paris or in Florida this summer for
> signing my key??? (I might travel there...)

https://nm.debian.org/gpg_offer.php :-)

-Ralf.


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

re: proposal for a more efficient download process

[curt manucredo (hansycm)]

Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote:

>Nope. You will need to keep all normal debs anyway, for new
>installations.

i thought it could be possible in the end to download the tree-package 
and all its patches to then have the latest package for a new install! 
so i thought there will be no more need for a lot of full packages. is 
it not? one of the advantages could be that you have more versions 
available then just the latest - this would be great for sid!


>Now the interesting questions: How many diffs do you keep?

i thought of keeping the tree-package and its patches as long it makes 
sence. for example if there is a next-version package and the patches 
would grow to big, there will come up a new tree-package. well, yes, it 
is difficult to think this through, but anyway!


>How do you
>integrate this approach with the minimal security Release files give us
>today? What about the kind of signatures dpkg-sig provides?

sure. this proposal would require a lot of changes not just a few. but 
as i have suggested not to make a .deb oriented but a file oriented 
patchment, the new package will be created on the users system with the 
downloaded patch(es). so in the end, there will be a .deb package in the 
cache and it will just install as always. if you make a package-mirror- 
update to look for updates, it just will show there is a new package.

the user will not find out that it just downloads the patches.
hope that answers your question. i am not quite sure. i am new!
so please try to ask in another way if this does not satisfy you!
thank's :-)
--
greetings from austria

well, though i think i can't fix that problem, but i believe i can make 
a workaround!

*
curt manucredo
[EMAIL PROTECTED]

"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein
--


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

Re: not running depmod at boot time

[Jörg Sommer]

Hello Eduard,

Eduard Bloch <[EMAIL PROTECTED]> wrote:
> #include 
> * Marco d'Itri [Sat, May 27 2006, 11:29:32AM]:
>
>> > > This is not a choice, every package which installs modules must run
>> > > depmod or they will not be available until a reboot.
>> > Yes. But no package (besides maybe module-init-tools) should ever run
>> > depmod at boot time. This all started because several packages do run
>> They do it at install time if they install modules.
>
> No, they don't. At least my packages call it only if `uname -r` ==
> target version. When you drop the depmod run, and someone installs a new
> kernel together with accompanying module packages and only THEN reboots,
> the modules.dep* files won't be updated.

Why the kernel does not run depmod? Either the modules package or the
kernel package is the last one. Marco had explained in one of his mails
how to run depmod for a kernel version != `uname -r`. Why this does not
work for you?

Good night, Jörg.
-- 
Du hast keine Chance--also nutze sie.


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

Re: Please revoke your signatures from Martin Kraff's keys

[Stephen Gran]

This one time, at band camp, Paul Johnson said:
> On Saturday 27 May 2006 16:49, Thomas Bushnell BSG wrote:
> > Paul Johnson <[EMAIL PROTECTED]> writes:
> > > The vote at champoeg was when the Oregon Territory voted to become
> > > Canadian.  We're on the south side of the border exclusively due to
> > > the threat of military force when the US couldn't handle the fact
> > > that we don't want them here the first time around.  That's not
> > > democracy, that's coercion.
> >
> > Does it matter any more?  Surely the opinions of a majority of
> > *present day* Oregonians matters a whole lot more, right?
> 
> Not many of the locals I talk about this with are terribly happy with the 
> situation today, either.

And I'm really having a hard time seeing what the purported national
allegiance of Oregon has to do with developing an OS.

Private mail, please, for the remainder of this silly and oversized
thread.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: gnome 1 packages up for adoption

[Loïc Minier]

On Sat, May 27, 2006, Steve Langasek wrote:
>python-gnome has a build-dependency on libgtkhtml-dev which
> should be trivially removable since none of its binary packages use it.

 python-gnome is also deprecated and should go away when possible, I've
 filed bugs on the rdeps already.  (As Steve already pointed out, this
 caused me to make the same mistake as Thomas, because apt-cache
 rdepends includes Suggests and Conflicts).

-- 
Loïc Minier <[EMAIL PROTECTED]>
"You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04


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

Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys

[Steve Langasek]

On Sat, May 27, 2006 at 04:47:20PM -0500, martin f krafft wrote:

> The Debian project heavily relies on keysigning for much of its
> work. However, I think the question what the signing of a key
> actually accomplishes has not been properly addressed. In my
> opinion, from the point of view of the Debian project, a person's
> actual identity (as in the name on your birth certificate) matters
> very little; the Debian project does not actively interfere with
> a person's real life in such a way as to require the birth
> certificate identity (legal cases, liability issues, etc.).

I don't agree that the Debian project shouldn't care about being able to map
the names of its contributors back to real-world entities.  The work we do
in Debian has real-world impact on lots of people, and if someone attacks
the integrity of Debian from the inside they should expect real-world
consequences for doing so.

Having a contributor's real name is an aid to holding them accountable, even
though it's neither globally unique nor permanent.

> Moreover, it's rather trivial in several countries of this world to
> change your official name. In this context, even the claim that in
> the case of a trust abuse, your reputation throughout the FLOSS
> community (and the rest of the Internet) should be properly
> tarnished, does not stand, IMHO.

In the jurisdictions I'm familiar with, unless you're in a witness
protection program, changing one's official name is accompanied by open
court records showing the old and new names and it is thus not a terribly
effective means of avoiding pesky inconveniences like creditors and criminal
charges.  So legally changing your name isn't going to stop us from getting
your ass thrown in jail for computer crimes; OTOH, if you were using a
pseudonym in the first place and no one detected it, that may be more of an
obstacle.

> I imagine an improved protocol for the keysigning, which is based on
> an idea I overheard after the party (and someone mentioned it in the
> thread): instead of the everyone-signs-everyone approach, it might
> be interesting to investigate forming groups (based on connectivity
> statistics) such that everyone's mean distance in the web of trust
> can be increased by a fair amount in a short amount of time. At the
> same time, such circles could be used for education by those with
> high connectivity (and thus much experience). The problem here is of
> course the somewhat unreliable attendance of people. Comments
> welcome.

I agree that this is the way to go.  Who has time to work on implementing
the necessary code?

> also sprach Enrico Zini <[EMAIL PROTECTED]> [2006.05.25.1218 -0500]:
> > However, from the book you don't get the address of madduck's
> > home, which is what you want when you have to go and drag him to
> > jail if he willingly uploads some malicious code.

> Could you even drag me to jail for anything I do (or don't do) in
> Debian? Which jurisdiction would be used? Who'd be the prosecutor?
> What kind of legal claims would actually stand a chance?

There are federal computer crime laws in the US that would cover things like
trojaning packages or rooting Debian servers.
http://conventions.coe.int/Treaty/en/Treaties/Html/185.htm suggests that EU
member states should have laws criminalizing such activities as well, though
I don't know the implementation details of any.

That would certainly cover the majority of DDs today, anyway.  And for the
rest, we always have the CIA to kidnap them for us so they can be tried in
the US. :-P

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


signature.asc
Description: Digital signature

Processed: update 4.1 blockers

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> block 366820 by 339921
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 275774 339921 355163 355165 355189 355325 355326 355352 355396 
355463 355598 355599 355663 355738 355739 355741 355744 355841 355980 355983 
355986 355988 355989 355990 355992 355993 355996 355997 355998 356003 356004 
356093 356098 356100 356109 356110 356111 356113 356115 356116 356121 356153 
356155 356156 356157 356159 356160 356161 356163 356168 356169 356170 356171 
356173 356174 356175 356176 356228 356229 356232 356233 356234 356238 356240 
356241 356242 356244 356245 356246 356248 356303 356304 356305 356321 356322 
356323 356324 356361 356362 356366 356367 356370 356374 356405 356422 356423 
356424 356425 356428 356436 356439 356440 356442 356444 356445 356453 356455 
356516 356517 356522 356540 356546 356549 356564 356570 356574 356579 356582 
356583 356585 356590 356592 356597 356598 356601 356606 356611 356620 356634 
356636 356646 356679 356684 356691 356767 356875 356878 356881 356892 356893 
356964 356965 356967 356968 356970 356971 356972 356979 356980 357056 357057 
357059 357061 357064 357070 357084 357096 357111 357112 357113 357117 357119 
357182 357184 357186 357189 357190 357316 357317 357322 357324 357325 357328 
357334 357335 357339 357340 357357 357358 357359 357360 357376 357380 357382 
357383 357401 357402 357403 357404 357408 357447 357455 357467 357476 357478 
357479 357481 357483 357490 357513 357552 357555 357556 357557 357558 357565 
357566 357600 357601 357614 357640 357644 357648 357651 357656 357659 357687 
357710 357711 357717 357720 357748 357750 357770 357774 357789 357810 357825 
357849 357861 357863 357864 357866 357897 357901 357959 357960 357961 357962 
357964 357967 357995 357996 358053 358062 358068 358069 358074 358075 358077 
358087 358090 358096 358206 358207 358208 358212 358214 358218 358219 358221 
358228 358240 358243 358259 358261 358263 358271 358277 358280 358281 358282 
358284 358285 358286 358287 358289 358290 358291 358292 358293 358294 358298 
358300 358301 358449 358542 358582 358591 358643 358644 358650 358881 358884 
358886 361331 361333 361334 361335 361336 361389 361396 361766 364814 366753 
366821 366963
Blocking bugs added: 339921

> block 366820 by 367360
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 275774 339921 355163 355165 355189 355325 355326 355352 355396 
355463 355598 355599 355663 355738 355739 355741 355744 355841 355980 355983 
355986 355988 355989 355990 355992 355993 355996 355997 355998 356003 356004 
356093 356098 356100 356109 356110 356111 356113 356115 356116 356121 356153 
356155 356156 356157 356159 356160 356161 356163 356168 356169 356170 356171 
356173 356174 356175 356176 356228 356229 356232 356233 356234 356238 356240 
356241 356242 356244 356245 356246 356248 356303 356304 356305 356321 356322 
356323 356324 356361 356362 356366 356367 356370 356374 356405 356422 356423 
356424 356425 356428 356436 356439 356440 356442 356444 356445 356453 356455 
356516 356517 356522 356540 356546 356549 356564 356570 356574 356579 356582 
356583 356585 356590 356592 356597 356598 356601 356606 356611 356620 356634 
356636 356646 356679 356684 356691 356767 356875 356878 356881 356892 356893 
356964 356965 356967 356968 356970 356971 356972 356979 356980 357056 357057 
357059 357061 357064 357070 357084 357096 357111 357112 357113 357117 357119 
357182 357184 357186 357189 357190 357316 357317 357322 357324 357325 357328 
357334 357335 357339 357340 357357 357358 357359 357360 357376 357380 357382 
357383 357401 357402 357403 357404 357408 357447 357455 357467 357476 357478 
357479 357481 357483 357490 357513 357552 357555 357556 357557 357558 357565 
357566 357600 357601 357614 357640 357644 357648 357651 357656 357659 357687 
357710 357711 357717 357720 357748 357750 357770 357774 357789 357810 357825 
357849 357861 357863 357864 357866 357897 357901 357959 357960 357961 357962 
357964 357967 357995 357996 358053 358062 358068 358069 358074 358075 358077 
358087 358090 358096 358206 358207 358208 358212 358214 358218 358219 358221 
358228 358240 358243 358259 358261 358263 358271 358277 358280 358281 358282 
358284 358285 358286 358287 358289 358290 358291 358292 358293 358294 358298 
358300 358301 358449 358542 358582 358591 358643 358644 358650 358881 358884 
358886 361331 361333 361334 361335 361336 361389 361396 361766 364814 366753 
366821 366963
Blocking bugs added: 367360

> block 366820 by 356215
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 275774 339921 355163 355165 355189 355325 355326 355352 355396 
355463 355598 355599 355663 355738 355739 355741 355744 355841 355980 355983 
355986 355988 355989 355990 355992 355993 355996 355997 355998 356003 356004 
356093 356098 356100 356109 356110 356111 356113 356115 356116 356121 356153 
356155 356156 356157 356159 356160 356161 356163 356168 356169 356170 356171 
356173 356174 356175 356176 356228 356229 356232 356233 3

Re: openssl will block bacula into etch?

[Goswin von Brederlow]

John Goerzen <[EMAIL PROTECTED]> writes:

> On Sun, May 28, 2006 at 02:55:39AM +0200, Goswin von Brederlow wrote:
>> > regards,
>> > -- stratus
>> 
>> Any source that builds udebs is always frozen (openssl builds
>> libcrypto0.9.8-udeb). Udebs have to be moved into testing manualy and
>> without the freeze the source+deb and udeb versions would drift apart.
>> Another reason for this is so that the Debian-installer have a
>> consistent set of udebs to work with.
>
>
> Hmm.  But openssl is in testing already, and bacula doesn't build-dep
> on a newer version.  Why does it matter?

I bet it depends on the new version that isn't in testing.

Looking at the packages.qa.d.o page for bacula I see different reasons
why bacula won't go into testing. Age, Bugs. Fix that before you worry
about some depends.

>> You have to ask -release to hint openssl in if the bacula change is
>> important.
>
> Done.  There was no Bacula in testing at all, since it had been
> removed in February due to bugginess.  So yes, I'd call it important.

Nothing important then. No bugs or security holes to fix.

MfG
Goswin


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

Re: Bug#368985: ITP: mod-bt -- BitTorrent tracker for the Apache2 web server

[Steve Langasek]

On Sat, May 27, 2006 at 06:02:07PM -0700, Tyler MacDonald wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> > You're missing the point that sonames track *ABI* changes, and -dev package
> > names should track *API* changes.  Typically, upstreams make API changes on
> > new major releases; ABI changes can happen much more often than this. 
> > Tracking sonames in your -dev package names is therefore wrong and
> > (inevitably, eventually) causes gratuitous churn for any packages
> > build-depending on yours.

>   OK, so it sounds like this is what you are saying:

>   Since this is the first public API *and* ABI, both counters should
> start at zero.

>   - When the API becomes incompatible (which would implicitly make the
> ABI incompatible), both the -dev and library package should increment their
> numbers.

>   - When the ABI becomes incompatible without affecting the API, only
> the library package should increment it's number.

>   Is that right?

With changing the package name on API changes being optional as well, since
API changes generally affect build-dependencies only, not dependencies, are
thus largely invisible to users, and in the general case don't tend to
happen in a way that justifies updates to all packages that would
build-depend on it.

But if you think you'll be making sufficient backwards-incompatible changes
to the library API to warrant such package name changes, yes, the above is
the right way to go about it.

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


signature.asc
Description: Digital signature

Re: [Debconf-discuss] list of valid documents for KSPs (was: Please revoke your signatures from Martin Kraff's keys)

[Javier Fernández-Sanguino Peña]

On Sat, May 27, 2006 at 02:12:48PM -0700, Steve Langasek wrote:
> On Sat, May 27, 2006 at 05:28:35PM +0200, Filippo Giunchedi wrote:
> > Is there a list of official documents (with photos) that we can consider
> > acceptable for a KSP?.  If there's not we definitely need one.
> > However this is rather tricky because the list itself should be 
> > authenticated
> > somehow, with a (gpg)signed photo of the person in charge for it? It seems 
> > clear
> > that having the list somehow authoritative creates a chicken-egg problem.
> 
> Not meaningful.  Individual KSP participants are still free to apply their
> own personal standards for ID verification; attempting to "standardize" them
> likely just means fewer KSP participants in the future.

Regardless of this, I think it would be nice to have a document (wikipedia
article?) listing official documents of countries all over the world. KSP
attendants need not base their decissions on this, but could be useful
as background information.

If someone opens up a Wikipedia article on this, maybe extending
http://en.wikipedia.org/wiki/Identity_document (which only describes
*national* cards) I would gladly contribute to it.

Regards

Javier


signature.asc
Description: Digital signature