Re: Sun Java available from non-free

[Walter Landry]

Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Mon, May 22, 2006 at 01:08:17AM +0200, Josselin Mouette wrote:
> > Indeed, they will bear the *primary* liability. However if legal action
> > is taken against them or our mirror operators because of their decision,
> > the whole distribution process might suffer, affecting all developers
> > and users.
> 
> Er, of course we all might be affected by it, but the ftpmasters would be
> affected *way* more by getting sued than *we* would be affected by their
> getting sued, so I think it's ridiculously presumptuous to criticize the
> ftpmasters for lack of transparency here instead of trying to support them
> to make good decisions.

Actually, the ftpmasters are unlikely to get sued, simply because they
probably don't have that much money.  It is much more likely that
companies sponsoring parts of the mirror network would get sued
(e.g. Brainfood).

That puts a heavy burden upon the ftpmasters.  Announcing an ITP and
referring questionable licenses to debian-legal relieves some of that
burden, because then the license is subjected to far greater analysis
by a larger group of people.  Since the ftpmasters decided not to do
that, it is appropriate to complain about their ineptness in analysing
the license.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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

Re: Sun Java available from non-free

[Adam Warner]

On Sun, 21 May 2006 23:25:28 -0700, Russ Allbery wrote:

> Adam Warner <[EMAIL PROTECTED]> writes:
>> On Sun, 21 May 2006 20:20:09 -0700, Russ Allbery wrote:
> 
>>> It's an important document and certainly something that every developer
>>> should read and endeavor to follow where it makes sense, but things go
>>> into the Developer's Reference rather than Policy frequently precisely
>>> *because* they don't make sense as global requirements and there are
>>> reasons why one might not wish to follow them.
> 
>> You're correct. So can you give reasonable and legitimate reasons why
>> "one might not wish to follow" the "you must" guidelines in this
>> instance?
> 
> Two, actually.  One for the advantage of PR with the timing of the
> release, which while it's a reason that I can see people not agreeing with
> and it isn't important to me personally, I think it's a reasonable one.

Later in the reply you state, "*I* think the license is murky, potentially
problematic, and borderline for non-free.  Looks like a hard call.  Good
thing I don't have to make it.  Many thanks to the people who do that work."

I don't see how Debian acting as Sun's public relations poodle on such a
murky, potentially problematic and borderline decision is reasonable.

> Second, the people involved were certainly in a position to know whether
> anyone else was working on this (given the people who cooperated on it),
> so they may have concluded that an ITP would have served no useful
> coordinating purpose.  (And, in fact, if they did conclude that, they
> would appear to be correct -- I haven't seen anyone stepping forward upset
> that their efforts to package Sun Java were stomped on.)

The process would have included a license discussion.

>> Yet in this case the ITP would have served an extremely useful
>> coordination purpose: letting interested parties participate. It would
>> only have served no useful purpose if the intent was to ensure the
>> packages went into non-free without dissent.
> 
> Do you think that this package would have ever gone into non-free without
> dissent?  An ITP would have resulted in the exact same discussion we just
> had, and if the ftp-masters had then approved it after concluding that the
> arguments presented weren't strong enough, people would have been just as
> upset if not more so.

Postulating that the same decision would be made if appropriate processes
had been followed does not excuse their short-circuiting. I suspect the
outcome would have been different because a public process would have
removed PR deadline pressure.

> You seem to be assuming that if they'd filed an ITP first, this discussion
> would have changed their mind.  I don't see any reason to believe that.  I
> don't see any reason to believe that this discussion raised any issues
> that they'd not already thought about.  In that case, I'm not sure what
> the point would have been, given that the people involved were the people
> who were going to make the decision anyway.

The murky, potentially problematic and borderline decision was made under
the pressure of a public relations deadline. I see many reasons why a
different decision would have resulted from a leisurely examination of the
license.

> Posting the ITP first would have indeed been the right move if license
> evaluation were a democratic or consensus process.  My understanding is
> that this is not how Debian works, whether one likes that or not.

My understanding is that debian-legal gives INPUT into whether a package
is suitable for main, contrib or non-free; *especially* in the case of a
brand new license.

>> I'll tone down the rhetoric: Having FTP masters Anthony Towns (aka The
>> Debian Project Leader), James Troup and Ryan Murray personally liable
>> to defend and indemnify Sun for mistakes made in the Debian packaging
>> and distribution of Sun Java could adversely affect the wider Debian
>> community.
> 
> Almost everything the ftp-masters do could have an adverse affect on the
> wider Debian community if they do it poorly.  That's why the position is
> so important.

Fair enough. I feel one or more of the ftp-masters did their job poorly.
They inadvertently put the interests of Sun before the wider community.

> So far, I see a bunch of amateur legal theorizing (my own included) and
> a lot of people worrying.  I am, so far, failing to detect falling
> fragments of sky.  *little shrug*.  I do understand some of why you're
> upset, I think, but it does seem like it's at least partially based on a
> mistaken impression of who is responsible for doing license evaluation
> in non-free and who they're obligated to consult with first.
> 
> Maybe I'm weird in this because of my personal background.  One of my
> previous volunteer jobs was to run the Usenet newsgroup creation process
> for the Big Eight hierarchies.  After doing that for a number of years,
> I have to say that I've had the problems with public consensus processes
> rubbed in my face fairly effect

Re: Sun Java available from non-free

[Thijs Kinkhorst]

On Mon, 2006-05-22 at 08:01 +0200, Juergen A. Erhard wrote:
> Wow, thanks for telling us.  I thought the Debian developers elected a DPL
> every year.  Of course, since I'm not one, I got that wrong.

You seem to be thinking that a democracy equals that everyone has a say
in every decision. Have you tried that in Germany? In any democracy,
there's a spelt out procedure in what way "the people" can influence
elected officials and decisions.


Thijs


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

Bug#368430: ITP: cobalt-panel-utils -- System utilities for Sun Cobalt's LCD and LEDs

[Le_Vert]

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

I'm packaging theses tools, right now !

* Package name: cobalt-panel-utils
  Version : 1.0.2
  Upstream Author : Jeff Walter <[EMAIL PROTECTED]>
* URL : http://gentoo.404ster.com/projects.php?action=view&id=1
* License : GPL / LGPL (both)
  Programming Lang: C
  Description : System utilities for Sun Cobalt's LCD and LEDs

System utilities which allow the user to create programs which write to
LCD and LEDs on the Sun Cobalts (x86 and MIPS based).  
..
Also includes a utility to read the buttons on the front panel.
..
Homepage: http://gentoo.404ster.com/ (Jeff Walter)

-- System Information: Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.4.32-raq550
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: Packages violating policy 8.2

[Goswin von Brederlow]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> On 19 May 2006, Goswin von Brederlow outgrape:
>
> setools is in the list, and contains libraries that it uses
>  itself, but does not break it up into multiple installed
>  packages. Setools is moving rapidly rnough that I do not intend to
>  support multiple versions of the libraries until things stabilize a
>  bit.
>
> However, people do build binaries against these libraries, and
>  even have private packages, and I intend to support that.

I think that Policy 8.2 is fully applicable to your package then. It
is a MUST directive so your unwillingness to allow multiple versions
of your library to coexist does not affect the violation.

Following 8.2 you only have 2 choices: Split the package or provide
only static libaries and live with the wasted space. Otherwise the
packages is RC buggy.

My 2c,
Goswin


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

Re: Sun Java available from non-free

[Thijs Kinkhorst]

On Sun, 2006-05-21 at 22:56 +0200, Josselin Mouette wrote:
> Le dimanche 21 mai 2006 à 22:38 +0200, Thijs Kinkhorst a écrit :
> > Given this legal background of yours, could you please help by using that
> > to improve the licence, instead of just complaining about how others
> > handled it? Please give the right example.
> 
> I'm afraid I have more interesting things to do than helping non-free
> software developers to get their non-free crap in the non-free archive.

If you do not care about "non-free crap", I don't mind.

> By the way, they also have the power to accept GNOME 2.14 in main. Don't
> you think that would have been more productive than accepting the Sun
> JVM?

Indeed I think that wouldn't have necessarily more productive, but I
certainly know that it's not at all relevant to this discussion.


Thijs


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

Re: Sun Java available from non-free

[Josselin Mouette]

Le dimanche 21 mai 2006 à 17:03 -0700, Steve Langasek a écrit :
> > This is the whole point of the discussion.
> 
> Not that I can see.  Your preceding post focused on the *who* and the *how*
> of the decision, *not* on the what.

This is all entangled. Had this decision been taken in a transparent way
and respecting the way the project works, I would have respected it.

> Er, of course we all might be affected by it, but the ftpmasters would be
> affected *way* more by getting sued than *we* would be affected by their
> getting sued, so I think it's ridiculously presumptuous to criticize the
> ftpmasters for lack of transparency here instead of trying to support them
> to make good decisions.

Support them for what? Michael already answered to this question.

> No, I'm acknowledging that the ftpmasters have no obligation to do as *you*
> say.  The ftp-masters aren't the ones trying to tell other people what to do
> in this thread.

They are the ones to tell other people what to do in general. They are
the ones rejecting new maintainers or new packages for frivolous
reasons. They are the ones preventing me from working on GNOME 2.14
because packages are stuck in NEW. They are generally considering the
rest of developers like a boss with his employees.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Multiarch preparations needed for etch dpkg

[Goswin von Brederlow]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Steve Langasek <[EMAIL PROTECTED]> writes:
>
>> On Sat, May 20, 2006 at 10:27:35PM +0200, Goswin von Brederlow wrote:
>>> - Allow arch specific depends
>>>   I propose to use "Depends: : (>= 1.2-3)" as syntax for
>>>   thses. While for etch no package should use them dpkg should accept
>>>   them so installing etch+1 debs can go without hitch.
>>>   (Note that this also impacts on apt and aptitude)
>>
>> Please provide a counter-example to the following assertion:
>>
>>  A multiarch package's dependency on another package must be satisfied by a
>>  package of a particular (i.e., of the same) architecture IFF the depended-on
>>  package is also a multi-arch package.
>>
>> If you don't have any counter-examples to this claim, then it's my belief
>> that the last of these changes is not required, because versioned
>> dependencies are enough to ensure the dependency is not incorrectly
>> satisfied by a non-multiarch version of the package, and Multi-Arch: yes
>> flags on the new versions of the package give dpkg & front-ends enough
>> information to correctly determine whether the dependency is properly
>> satisfied and to resolve the dependency if not.
>
> Say you have a binary package (Multi-Arch: no) firfox and a
> library/plugin package firefox-mplayer-plugin.
>
> This could be handled by firefox having a "Provides:
> firefox-abiXX-arch-os-libc". Apt and perl for example already provide
> an abi pseudopackage.

After a lengthy discussion on irc Steve and I have come to the
conclusion that we don't seem to need a "Depends: foo:arch" syntax if
we instead implement versioned provides.

Afaik currently dpkg allows "Provides: foo (= 1.0)" but the version
gets ignored when resolving depends. If we change the semantics so
that version now have meaning an older dpkg will still ignore it and
potentialy install the wrong package. But it won't stop people from
updating to a newer dpkg and frontends, which then in turn can correct
the error.

I think packages with a versioned depends on a provided package will
be uninstallable with the current dpkg, right? If so that would only
mean packages in etch+1 will be uninstallable without a prior update
to a dpkg that handles versioned provides.

> Another example would be build-essential:
>
> Depends: libc6-dev | libc-dev, gcc (>= 3:3.3), g++ (>= 3:3.3), make, dpkg-dev 
> (>= 1.4.1.19)
>
> becomes
>
> Depends: libc6-dev:arch | libc-dev:arch, gcc (>= 3:3.3), g++ (>= 3:3.3), 
> make, dpkg-dev (>= 1.4.1.19), dpkg:arch
>
> Again a provides could be used to achieve the same effect.

Actualy strike that. libc6-dev would not be "Multi-Arch: no" because
the libc.so linker script is arch dependent. Dpkg then resolves the
depends correctly already so that libc6-dev and build-essential always
have the same architecture. Same for gcc and g++.

Only the "dpkg:arch" is required and that can be done with "Provides:
dpkg-arch" again.

>> I believe this removes the need for a backwards-incompatible syntax change
>> to the Depends: field, which is an objection I had to the posted dpkg v2
>> multiarch proposal as well.  (Note that without this change to Depends:
>> syntax, any of these "multiarch" packages can be installed fine on the
>> native architecture with the existing dpkg, but that with this syntax change
>> users must first upgrade to a new set of packaging tools before these
>> package relationships are parseable.)

I now agree with that with one reservation.

For multiarch dpkg in the current WIP implementation to work correctly
no future multiarch package may be installed with the existing
dpkg. But if we get the other preparations into etch dpkg this can be
caught in preinst of dpkg and the user can be instructed to first
install etch dpkg, then reinstall affected packages. I think that is
an acceptable limitation.

So we don't have to change the syntax but we do have to change dpkg
to smooth the way ahead for etch+1.

MfG
Goswin


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

Re: Sun Java available from non-free

[Michael Meskes]

On Sun, May 21, 2006 at 11:26:26PM -0700, Russ Allbery wrote:
> >> [...]  They didn't ask you because Debian is not a democracy and random
> >> opinions on this decision *don't* matter.
> 
> > Wow, thanks for telling us.  I thought the Debian developers elected a
> > DPL every year.  Of course, since I'm not one, I got that
> > wrong.
> 
> That would make Debian, at most, a republic, not a democracy.

Would you care to elaborate and explain it isn't a democratic republic
then?

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: Sun Java available from non-free

[Russ Allbery]

Michael Meskes <[EMAIL PROTECTED]> writes:
> On Sun, May 21, 2006 at 11:26:26PM -0700, Russ Allbery wrote:

>> That would make Debian, at most, a republic, not a democracy.

> Would you care to elaborate and explain it isn't a democratic republic
> then?

Debian's delegate system makes it very strongly on the republican side of
things, enough so that I think calling it a democracy is misleading.  Yes,
in theory we can elect a DPL who can then rescind any delegation and
appoint someone new, but the levels of indirection involved make that more
in the style of the original US Senate.  The point that makes it the most
democratic is the recourse to GR to *overturn* decisions, but most
decisions in the project are not made by vote and shouldn't be.  Most
decisions are not even made by elected officials, as we only have one of
those and most of the job of the DPL is cheerleading, financials,
legalities and public relations.

And whether it's a democratic republic or some other form of hybrid mostly
depends on whether you consider ftp-master to be a delegate position or a
somewhat independent check, a question that I expect would only get firmly
resolved under circumstances that none of us really want to see.

I realize that I'm drawing linguistic distinctions that few people care
about, which is why I marked my original message as a pet peeve, but I'd
say that Debian is somewhat democratic but not a democracy.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Sun Java available from non-free

[Wouter Verhelst]

On Mon, May 22, 2006 at 10:25:35AM +0200, Josselin Mouette wrote:
> Le dimanche 21 mai 2006 à 17:03 -0700, Steve Langasek a écrit :
> > No, I'm acknowledging that the ftpmasters have no obligation to do as *you*
> > say.  The ftp-masters aren't the ones trying to tell other people what to do
> > in this thread.
> 
> They are the ones to tell other people what to do in general. They are
> the ones rejecting new maintainers or new packages for frivolous
> reasons. They are the ones preventing me from working on GNOME 2.14
> because packages are stuck in NEW.

Oh, quit whining already.

First, "the FTP-masters" is not the same group of people as "the DAMs".
There is some overlap, but it is not complete. Ignoring that, I've never
seen the DAM reject new maintainers for "frivolous" reasons. More on
topic, I've also never seen packages rejected because of "frivolous"
reasons. What I have seen is a NEW FAQ which clearly explains the
reasons for which a package might be rejected. None of them seem
frivolous to me; in fact, if it were up to me, I'd be a bit more strict
than what that FAQ seems to suggest.

Second, the NEW queue is indeed a bit backlogged; AIUI, however, that's
mainly because the ftp-masters were at debconf and the Internet
connection there wasn't good enough for interactive traffic, which is
required for ftp-mastery stuff.

Debconf is over now, so I fully expect the NEW queue to be handled again
as good as it used to be in a few weeks. Which would hopefully mean that
emile, a package that I uploaded and which is stuck in NEW as well, will
be accepted into the archive.

> They are generally considering the rest of developers like a boss with
> his employees.

I've never seen any of them ordering me to do something, which is the
essence of an employer/employee-relationship. You must be delusional.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


signature.asc
Description: Digital signature

Re: Sun Java available from non-free

[Michael Meskes]

On Sun, May 21, 2006 at 12:34:00PM -0500, Raphael Hertzog wrote:
> In that case, ftpmasters accepted it, end of discussion. You HAVE to
> accept decisions of delegates within Debian, that's how we can effectively
> work. 

But that means that ALL delegates have to be either elected or appointed
by some elected representants.

> If you really fear legal problems, then you should work with Sun to see if
> you can reword the license so that it better matches the FAQ which gives us

What a srewed logic.

> currently all the warranties that we need. We can terminate the license as
> soon as Sun starts bothering us with non-FAQ-conforming interpretations of
> their license.

I doubt this would work. If Sun were to bother us it is too late because
we already distribute Java from our servers.

> Furthermore, doing a bit of Debian PR by having a timely announce of the
> new java license, is good for us too.

I'm afraid we will receive way more bad PR now because of this
discussion.

> You're not interested in that. "graceful manner" means you want ftpmasters
> to agree with you. They won't. And I don't.

It's kind of strange seeing you decide what some other person is
interested in. 

> You're not facilitating it. People who managed that java upload did
> discuss with Sun and they probably know that this was the right first
> step. You have no idea of the internal lobbying that may be going on and
> you can't judge how to best achieve DFSG-freeness of java.

Before telling people they have no idea, how about explaining it and
sharing your insights? Either you have some, then you can, or you don't,
but then you should be a little bit more careful with your wording.

> PS: Yeah I'm a bit pissed of that we only have people criticizing when we
> do great things.

And I'm pissed of that so much seems to happen behind the scenes and I
as a normal developer who did not go to Mexico do not get the info even
if I ask, but instead people are just told to shut up.

Michael

-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: Sun Java available from non-free

[Michael Meskes]

On Sun, May 21, 2006 at 04:04:37PM -0500, Raphael Hertzog wrote:
> No I don't answer to "shut up". I answer to stop now because Anthony Tows
> responded to all the questions and give a precise course of action on how
> we can continue improving the situation concerning the java licensing.

So he should stop because AJ answered although his questions were
completely answered?

> And I responded to someone who clearly doesn't agree with the ftpmasters
> decision and will continue flaming as hell when he already knows
> everything that he needs.

Well I read all emails in the thread and IMO yours was the one that
was closest to a flame. I assume that it wasn't meant to be, but
accusing others of flaming doesn't give you respectability.

> Fears are unfounded, we can at any time terminate the license by removing
> java!

Again this logic doesn't seem to work for me. If I was offering warez on
my server I couldn't become legal again by just removing it. My prior
action would still get me sued, doesn't it? And no, just saying I
thought it was okay, doesn't help me either.

Michael

-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: Sun Java available from non-free

[Martijn van Oosterhout]

On 5/22/06, Russ Allbery <[EMAIL PROTECTED]> wrote:

Martijn van Oosterhout <[EMAIL PROTECTED]> writes:

> Given the word "estoppel" only has meaning in jurisdictions deriving
> from English common law, I think it'd be silly to assume it works the
> way you think it does in any of the other jurisdictions Debian or any of
> its mirrors may come in contact with...

In the other jurisdictions that you're familiar with, is there any similar
principal where if you make a recorded public statement that something is
okay, you cannot then later sue someone for doing what you said was okay?


Well, IANAL, but as far as I can see, as long as Sun has a valid
reason to change their mind and is willing to compensate any losses
caused by them changing their mind, they can do whatever they like. A
few possible problems are:

- The promise was made without consideration (no symbolic one cent payment)
- The promise was not formally notarised. A press notice may not count.
- It wouldn't damage Debian or anybody much to revoke the statement.

They may not be able to recover damges for the period you relied on
their statement, but nothing prevents them from stating the contrary.
that's assume the promise is considered valid ofcourse.

A comparison of estoppel between English, American and German. It
refers to contracts however, we we don't have in this case:
http://tldb.uni-koeln.de/php/pub_show_document.php?pubdocid=114700

Thie simplest solution in this case would be if Sun simply attached
the FAQ as an addendum to the licence rather than stating it's not
legally binding.
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

Re: Sun Java available from non-free

[Thijs Kinkhorst]

On Mon, 2006-05-22 at 10:50 +0200, Michael Meskes wrote:
> Again this logic doesn't seem to work for me. If I was offering warez
> on my server I couldn't become legal again by just removing it. My
> prior action would still get me sued, doesn't it? And no, just saying
> I thought it was okay, doesn't help me either. 

I don't think the parallel with warez is sound. Allow me to reword to
better match the situation at hand.

You are told by a programmer that you are allowed to offer their
software on your server. They reaffirm that you can, even in person. You
offer it on your server. The programmer changes his mind and commands
you to remove it, which you subsequently do.



Thijs


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

Re: Sun Java available from non-free

[Olaf van der Spek]

On 5/22/06, Thijs Kinkhorst <[EMAIL PROTECTED]> wrote:

On Mon, 2006-05-22 at 10:50 +0200, Michael Meskes wrote:
> Again this logic doesn't seem to work for me. If I was offering warez
> on my server I couldn't become legal again by just removing it. My
> prior action would still get me sued, doesn't it? And no, just saying
> I thought it was okay, doesn't help me either.

I don't think the parallel with warez is sound. Allow me to reword to
better match the situation at hand.

You are told by a programmer that you are allowed to offer their
software on your server. They reaffirm that you can, even in person. You
offer it on your server. The programmer changes his mind and commands
you to remove it, which you subsequently do.


But in that case the 'license' is clear. In this case it's not (to
everybody). So I don't think it's comparable.

Re: Sun Java available from non-free

[Josselin Mouette]

Le lundi 22 mai 2006 à 10:46 +0200, Michael Meskes a écrit :
> And I'm pissed of that so much seems to happen behind the scenes and I
> as a normal developer who did not go to Mexico do not get the info even
> if I ask, but instead people are just told to shut up.

Even people in Oaxtepec have learnt that Java thing by reading the
mailing lists. This is even more frustrating when the people who took
this decision are a few meters away.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Sun Java available from non-free

[Pierre Habouzit]

Le Lun 22 Mai 2006 01:46, Steve Langasek a écrit :
> On Mon, May 22, 2006 at 01:06:42AM +0200, Pierre Habouzit wrote:

> > I personally thinks it hurts our users, and as a secondary effect,
> > us. Beeing distributable is a property that should not be depends
> > upon the time, the color of your hair, or the phase of the moon.

> > Java license (especially clause 4) makes the distribution of a
> > specific version of java beeing revocable, which can hurts a lot of
> > users that may then depends on it. A re-licensing e.g. would not be
> > the same, because the last previous version that had a
> > distributable license would still be allowed to stay in non-free
> > until full deprecation or even for life.

> These are fine reasons why Sun should be encouraged to make Java free
> software, instead of merely making it redistributable; or why we
> should educate users about the importance of Free Software and why
> they should think twice before accepting non-free solutions.  This
> might even be an argument for Debian discontinuing non-free
> altogether.

> But I don't really see that they apply as reasons to keep Java out of
> non-free.  Non-free is, well, non-free: very little, if any, of the
> stuff in there is distributed under terms that would prevent a
> copyright holder from later forbidding us from distributing the
> existing work, AFAIK, and there's no reason in general that we should
> be *happy* with the licenses of any works in non-free (though some
> individuals in the community may be).

I understand your point, but given that make-jpkg (aka java-package) 
exists and works great (i've been a user of it since quite a lot of 
time, and that had never failed me), I don't see much an improvement 
over java-package.

beeing in non-free versus make-jpkg is IMHO making the tacit promise 
that java will remain here forever (I mean in our archive, I really 
hope java won't stay in *non-free* forever, I'd be really happy to see 
it enter main). If it has to be removed from non-free at some point, 
because of Sun exercising one of their retroactive clause, then I think 
we have failed our users.

we are *currently* allowed to redistribute java, I agree with that: yes, 
if we have any problem, removing java from the archive *is* a valid 
action, and saves us from any trouble (every clause is written under 
the form [ do $foo or don't ship / stop shipping java ]).. My concern 
is with the "currently".

IMHO, *even* in non-free, packages should be distributable for the 
lifetime of one stable release (e.g. for something like 5 years -- it's 
an example). I know some packages are (or have been) in non-free 
because debian benefits of an exception to have the right to distribute 
those. I've always hopped those exceptions honoured that fact (meaning 
that a package that enters non-free will be able to remain here in a 
predictable manner for the lifetime of that stable release). If not, I 
really think we should re-evaluate some bits of non-free, because to 
me, it sounds like a lie.

even if it's non-free and that our support is going to be harmed in many 
ways due to the non-freeness of the package, the two properties that 
non-free should ensure are:
 * the fact that we are allowed to distribute the packages ;
 * a minimal durability of that package in the archive.
else, we are proposing random bits of shit, that any user is already 
able to install himself from non-official sources. I don't see any 
added value that we have without point 2.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpoDiWL8jrvB.pgp
Description: PGP signature

Re: Sun Java available from non-free

[Michael Meskes]

On Mon, May 22, 2006 at 11:29:05AM +0200, Thijs Kinkhorst wrote:
> On Mon, 2006-05-22 at 10:50 +0200, Michael Meskes wrote:
> > Again this logic doesn't seem to work for me. If I was offering warez
> > on my server I couldn't become legal again by just removing it. My
> > prior action would still get me sued, doesn't it? And no, just saying
> > I thought it was okay, doesn't help me either. 
> 
> I don't think the parallel with warez is sound. Allow me to reword to

Okay, agreed on this one.

> better match the situation at hand.
> 
> You are told by a programmer that you are allowed to offer their
> software on your server. They reaffirm that you can, even in person. You
> offer it on your server. The programmer changes his mind and commands
> you to remove it, which you subsequently do.

But this doesn't seem to be sound either. Let me try one more time:

You are told by a programmer that you are allowed to offer their
software on your server, but the programmer also tells you that his
statement is legally not binding and the license says you are not
allowed to offer it. Then you offer it on your server and some of your
customers has a huge problem with that software and wants to sue someone
to cover their losses. Now the company that developed the software says
you were never allowed to offer it and with their own version your
customer wouldn't have got into trouble. 

See I'm talking about a legal problem that isn't solvable by just
removing software.

Michael

-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: Sun Java available from non-free

[Michael Meskes]

On Mon, May 22, 2006 at 10:24:38AM +0200, Thijs Kinkhorst wrote:
> On Mon, 2006-05-22 at 08:01 +0200, Juergen A. Erhard wrote:
> > Wow, thanks for telling us.  I thought the Debian developers elected a DPL
> > every year.  Of course, since I'm not one, I got that wrong.
> 
> You seem to be thinking that a democracy equals that everyone has a say

No, why so you think he does? 

> in every decision. Have you tried that in Germany? In any democracy,
> there's a spelt out procedure in what way "the people" can influence
> elected officials and decisions.

Which brings up the interesting question whether we do have this
procedure in Debian and of course whether these elected officials make
the decisions.

Michael

-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: Sun Java available from non-free

[Marc 'HE' Brockschmidt]

Heya,

Michael Meskes <[EMAIL PROTECTED]> writes:
[Java flamewar]
> DPL, I wonder Why the Sun-Java package is not handled the same as any
> other package. What makes it so special that it deserves special
> treatment?
>
> Isn't this a discrimination against all other packages? :-)

ACK. This is the most important problem with the Java license for me -
in general, the ftp-masters are *very* strict when it comes to
licenses. Even if upstream provides some FAQ or something to clarify
badly worded parts of the license, they are usually required to change
the license of their software to get it into Debian.

I understand that a lot of people are interested to get Sun Java
packaged for Debian (and it would be a real improvement if we were able
to distribute it!), but I can not understand why it is special-cased
when it comes to licensing issues.

If Sun is interested in getting Java included in the major Linux
distributions, it shouldn't be such a big problem to provide a license
draft, hear opinions and then *change* it. 

In his mail, aj said "both James and Jeroen had extensive contact with
Sun to ensure that the tricky clauses were actually okay" - that's
nice. If the license wasn't public at that point, it shouldn't have been
too hard to change the problematic clauses of the license to say what
they mean. As far as I understand the whole thing, Sun simply provided
their license, but was not willing to address the concerns that were
expressed in the license itself.

It simply doesn't look like this was a fair process with the aim of
getting to a solution that satisfies both parties. Which is not really
helping to ensure that Sun will not try to do bad stuff at some time in
the future.

So at the moment, we have a license with some ambiguous clauses, a lot
of unhappy DDs and Java on those mirrors that provide non-free. I don't
think that removing the packages again is the right signal to send out,
but I think that we should work these problems out before etch is
released.

OK, now to the reason for CCing aj: Could you please delegate someone to
do a status report, talk to Sun and then report back to project? I can
understand that for a big corporation like Sun, it's not easy to work
together with a many-headed hydra like debian(-legal), so this could
help to get to a solution in a reasonable time-frame. To calm everyone
down, it would probably good to choose someone for this who was *not*
involved in this cute little flamewar we're all enjoying so much.

Ignoring the concerns of the developers who are frustrated by the whole
thing will not help anyone, but those people should please remember that
we're trying to create the best Linux distribution *together*. Flaming
is usually not the best way to present one's arguments.

Thanks,
Marc (hating legal stuff and flamewars in general)
-- 
BOFH #431:
Borg implants are failing


pgpXqut5iKMUr.pgp
Description: PGP signature

Re: Sun Java available from non-free

[Michael Meskes]

On Mon, May 22, 2006 at 01:51:21AM -0700, Russ Allbery wrote:
> Michael Meskes <[EMAIL PROTECTED]> writes:
> > On Sun, May 21, 2006 at 11:26:26PM -0700, Russ Allbery wrote:
> 
> >> That would make Debian, at most, a republic, not a democracy.
> 
> > Would you care to elaborate and explain it isn't a democratic republic
> > then?
> 
> Debian's delegate system makes it very strongly on the republican side of
> things, enough so that I think calling it a democracy is misleading.  Yes,

In the sense that in a democracy all decisions are made by vote you're
absolutley right of course.

> in theory we can elect a DPL who can then rescind any delegation and
> appoint someone new, but the levels of indirection involved make that more
> in the style of the original US Senate.  The point that makes it the most
> democratic is the recourse to GR to *overturn* decisions, but most
> decisions in the project are not made by vote and shouldn't be.  Most
> decisions are not even made by elected officials, as we only have one of
> those and most of the job of the DPL is cheerleading, financials,
> legalities and public relations.
> 
> And whether it's a democratic republic or some other form of hybrid mostly
> depends on whether you consider ftp-master to be a delegate position or a
> somewhat independent check, a question that I expect would only get firmly
> resolved under circumstances that none of us really want to see.

Wait a moment, if ftp-master was independant what should we call our structure 
then?

Michael

-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: Sun Java available from non-free

[MJ Ray]

Adam Warner <[EMAIL PROTECTED]>
[...]
>license agreement; and (f) you agree to defend and indemnify Sun
>and its licensors from and against any damages, costs, liabilities,
>settlement amounts and/or expenses (including attorneys' fees)
>incurred in connection with any claim, lawsuit or action by any
>third party that arises or results from (i) the use or distribution
>of your Operating System, or any part thereof, in any manner, or
>(ii) your use or distribution of the Software in violation of the
>terms of this Agreement or applicable law.  You shall not be
>obligated under Section 2(f)(i) if such claim would not have
>occurred but for a modification made to your Operating System by
>someone not under your direction or control, and you were in
>compliance with all other terms of this Agreement.
[...]
> When did we decide, as a community, to defend and indemnify Sun for the
> community's mistakes in packaging Sun's implementation of Java the
> language and platform?

Actually, it looks worse than that to me: "your Operating System, or any
part thereof" - That is all the parts, not just the Sun Java packages,
but stuff like GNU tools and Linux, so long as they weren't modified
after our Operating System distribution.

I'm not sure whoever drafted DLJ really understood what a distribution
is - software packaged in a handy ready-to-eat format.  We didn't write
the whole Operating System.

> Distributor License for Java version 1.1 licensed packages should be
> removed from non-free immediately. Then the normal process for inclusion
> of packages into the archive can begin.

Amen.

(Disclosure: I used to help hack Java code (badly) but I don't
mirror, support or use non-free, so my interest is limited.)

-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: Sun Java available from non-free

[Wouter Verhelst]

On Mon, May 22, 2006 at 10:50:22AM +0200, Michael Meskes wrote:
> On Sun, May 21, 2006 at 04:04:37PM -0500, Raphael Hertzog wrote:
> > Fears are unfounded, we can at any time terminate the license by removing
> > java!
> 
> Again this logic doesn't seem to work for me. If I was offering warez on
> my server I couldn't become legal again by just removing it.

Not even remotely relevant.

The difference would be that while you would act against the original
author's wishes if you were to put warez on your server, the same isn't
true about Sun Java. In fact, Sun explicitely asked us to please
distribute their software. I'd say that accounts to something, and that
a Judge who feels different isn't worth his job.

Consider Sun would turn nasty and would try to use their Java
distributor's license against us. What do you think would happen?

* Sun tells us "remove Sun Java from your server, now!"
* We comply
* End of story.

What's the problem?

They won't sue us for distributing Java. If they do, all we have to do
is point the Judge to the press coverage of this change of license, and
to the fact that Debian was mentioned as one of the distributors asked
to please distribute Java. They won't have a case.

Try as I might, and considering how lawyers and judges are human beings
and not automatons, I can't see any realistic scenario in which we could
be sued and lose a case in relation to this license. Do you?

Sure, the license isn't Free Software. It would be nice if it were; and
I'm sure that Sun Java won't be part of main until it is. But apart from
that, I really don't understand what the big fuss is all about.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Sun Java available from non-free

[Wouter Verhelst]

On Mon, May 22, 2006 at 12:35:41PM +0200, Michael Meskes wrote:
> You are told by a programmer that you are allowed to offer their
> software on your server, but the programmer also tells you that his
> statement is legally not binding and the license says you are not
> allowed to offer it. Then you offer it on your server and some of your
> customers has a huge problem with that software and wants to sue someone
> to cover their losses. Now the company that developed the software says
> you were never allowed to offer it and with their own version your
> customer wouldn't have got into trouble. 

I don't think they'd be able to make a case with that, unless they can
prove that we seriously tampered with their software and that our
version is totally different from theirs. Since they've been doing most
of the packaging work themselves, I think that's going to be very,
*very* hard.

If I ask you to please do something, I can't then suddenly turn around
and say that you shouln't have actually been doing that something. That
would be dishonest, and I can't win a case in court by being dishonest.

> See I'm talking about a legal problem that isn't solvable by just
> removing software.

No you're not. You're talking about an issue that only exists in
fantasy.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Sun Java available from non-free

[Wouter Verhelst]

On Mon, May 22, 2006 at 12:03:25PM +0200, Josselin Mouette wrote:
> Le lundi 22 mai 2006 à 10:46 +0200, Michael Meskes a écrit :
> > And I'm pissed of that so much seems to happen behind the scenes and I
> > as a normal developer who did not go to Mexico do not get the info even
> > if I ask, but instead people are just told to shut up.
> 
> Even people in Oaxtepec have learnt that Java thing by reading the
> mailing lists.

Err, that's not actually true. It was announced at the end of one
particular talk. Even I saw that through the webcast.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]

[Henning Makholm]

Scripsit Don Armstrong <[EMAIL PROTECTED]>
> On Wed, 17 May 2006, Henning Makholm wrote:

>> How does sending directly to from reportbug to an ISP's smarthost
>> validate the user's email address better than sending directly from
>> reportbug to a HTTP POST somewhere?

> I'm talking about an HTTP access method in general; if it were to be
> done, I'd expect that it validate the users email address before
> actually forwarding bug reports from the user.

Why don't you have the same expectation about SMTP access methods?

>> It is not necessary that there is anywhere any HTML form that refers
>> to the posting URL; only reportbug would need to know it.

> Except for the fact that anyone can create a page which posts to that
> url.

... with a big large text box in which a user is supposed to manually
format some text that can be parsed properly by the unknown backend
script? If anybody _really_ wanted to fake a bug report with a wrong
user, it is much simpler to use an off-the-shelf MUA than to try to
reverse-engineer the data format used by a the private reportbug HTTP
application.

-- 
Henning Makholm   "Det er trolddom og terror
 og jeg får en værre
   ballade når jeg kommer hjem!"


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

Re: Sun Java available from non-free

[Alexander Sack]

On Mon, May 22, 2006 at 11:22:25AM +0200, Marc 'HE' Brockschmidt wrote:
> Heya,
> 
> Michael Meskes <[EMAIL PROTECTED]> writes:
> [Java flamewar]
> > DPL, I wonder Why the Sun-Java package is not handled the same as any
> > other package. What makes it so special that it deserves special
> > treatment?
> >
> > Isn't this a discrimination against all other packages? :-)
> 
> ACK. This is the most important problem with the Java license for me -
> in general, the ftp-masters are *very* strict when it comes to
> licenses. Even if upstream provides some FAQ or something to clarify
> badly worded parts of the license, they are usually required to change
> the license of their software to get it into Debian.
> 
> I understand that a lot of people are interested to get Sun Java
> packaged for Debian (and it would be a real improvement if we were able
> to distribute it!), but I can not understand why it is special-cased
> when it comes to licensing issues.
> 

I hope this special treatment has nothing to do with the sun-ubuntu deal
announced a few days ago.


 - Alexander

-- 
 GPG messages preferred.|  .''`.  ** Debian GNU/Linux **
 Alexander Sack | : :' :  The  universal
 [EMAIL PROTECTED]| `. `'  Operating System
 http://www.asoftsite.org/  |   `-http://www.debian.org/


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

Re: Sun Java available from non-free

[Romain Beauxis]

Hi!

On Monday 22 May 2006 13:35, you wrote:
> They won't sue us for distributing Java. If they do, all we have to do
> is point the Judge to the press coverage of this change of license, and
> to the fact that Debian was mentioned as one of the distributors asked
> to please distribute Java. They won't have a case.
>
> Try as I might, and considering how lawyers and judges are human beings
> and not automatons, I can't see any realistic scenario in which we could
> be sued and lose a case in relation to this license. Do you?

While I understand your argument about Sun asking for this, and even found it 
serious, please do not argue the judges are human being after all...
Judges aply law, and that what they are meant for. If there is a law which 
could be used against the project, then the judge has to apply it, no matter 
how 'human' he is...

Now come the strong point about your argument: appart from quoting from the 
press, do you have an offical request from Sun to please distribute Java in 
debian?

If yes, then it is true that it would be very difficult to argue against the 
project in a court. But I fear that press cover is not enough, since it does 
not have an offical mean, and you might even find articles that would claim 
false things..

Romain


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

Re: Unidentified subject!

[Roberto C. Sanchez]

Hex Star wrote:
Hmmm...interesting...the other time someone posted something explicit 
and someone replied to it and pointed it out, everyone joined in and 
investigated it...this time the person who points it out gets 
criticized...go figure...I always get the short end of the stick...




I don't recall that incident.  I do recall, however, that several times 
in the past people have been chastised for replying to spam.  I can 
certainly undertand that since I imaging it can mess up the training of 
your spam filter if you use all of the mail you receive to train it.


-Roberto

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


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

Re: Sun Java available from non-free

[Stephen Frost]

* Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> On Mon, May 22, 2006 at 08:01:34AM +0200, Juergen A. Erhard wrote:
> > On Sun, May 21, 2006 at 03:55:53PM -0700, Steve Langasek wrote:
> > > [...]  They didn't ask you because Debian is not a democracy and random
> > > opinions on this decision *don't* matter.
> > 
> > Wow, thanks for telling us.  I thought the Debian developers elected a DPL
> > every year.
> 
> The presence of elections do not necessarily turn an organization into a
> democracy. Steve is right; Debian is not a democracy, and random
> opinions on this decision are of no relevance to it.

Sure, it's not a democracy, and true the final decision is made by
the select few, but it's rude and insulting to basically say "I don't care
that you were interested enough to look into this license more carefully
and had some concern about it, it's good enough and I don't think you
should care."  Perhaps it's not as bad as all that, but when someone is
willing to take the time to critique a decision or process or way
something was done it's not necessairly a bad thing, even if they don't
actually have a say in the final decision.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: Sun Java available from non-free

[Matt Zimmerman]

On Mon, May 22, 2006 at 01:59:21PM +0200, Alexander Sack wrote:
> I hope this special treatment has nothing to do with the sun-ubuntu deal
> announced a few days ago.

What relationship could you possibly suspect between this event and
processing of this package in Debian's queue/new?

-- 
 - mdz


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

Re: Sun Java available from non-free

[Michael Meskes]

On Mon, May 22, 2006 at 01:35:33PM +0200, Wouter Verhelst wrote:
> The difference would be that while you would act against the original
> author's wishes if you were to put warez on your server, the same isn't
> true about Sun Java. In fact, Sun explicitely asked us to please
> distribute their software. I'd say that accounts to something, and that
> a Judge who feels different isn't worth his job.

I already admitted that the example doesn't cut it. But again most
discussion is about the "allowance to distribute". I don't see a problem
with this. But I see a problem with the idemnify clause. That's why I
tried this example because it doesn't help if you stop distributing java
if you are already in a bind to idemnify Sun.

> Try as I might, and considering how lawyers and judges are human beings
> and not automatons, I can't see any realistic scenario in which we could
> be sued and lose a case in relation to this license. Do you?

Yes, I do, but not for distributing it.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: Changing the default syslogd (again...)

[Stephen Frost]

* Florian Weimer ([EMAIL PROTECTED]) wrote:
> * Nathanael Nerode:
> > (2) Upstream status.
> > There hasn't been a new upstream for sysklogd since 2001.
> > All of the others are active upstream.
> 
> Have you checked if SuSE's syslog-ng is heavily patched?  If it's
> mostly alright, it's probably a good indicator that syslog-ng is the
> way to go (and I assume that it can log to files larger than 2GB
> nowadays 8-).

Yeah, sure, except when the maintainer uploads a version of syslog-ng
that ends up puking all over itself in a most unpleasent way that causes
anything that logs to block.  That version was also in unstable for
quite a while.  I realize it's unstable but there are quite a few people
who use that and for whom it'd probably be less clear what had happened.
("Debian sucks, every morning I have to reboot because I can't log in!")

The version we currently have in unstable is 1.9.9 (which is a
development version), 2.0 hasn't been released yet and I'd be hesitant
to recommend 2.0 for the default right away.  It's possible we could
consider 2.0 for etch (assuming it comes out by then) but I really feel
it's not a good move to make that decision before it actually arrives
and gets quite a bit of testing.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: Sun Java available from non-free

[Michael Meskes]

On Mon, May 22, 2006 at 01:39:47PM +0200, Wouter Verhelst wrote:
> On Mon, May 22, 2006 at 12:35:41PM +0200, Michael Meskes wrote:
> > You are told by a programmer that you are allowed to offer their
> > software on your server, but the programmer also tells you that his
> > statement is legally not binding and the license says you are not
> > allowed to offer it. Then you offer it on your server and some of your
> > customers has a huge problem with that software and wants to sue someone
> > to cover their losses. Now the company that developed the software says
> > you were never allowed to offer it and with their own version your
> > customer wouldn't have got into trouble. 
> 
> I don't think they'd be able to make a case with that, unless they can
> prove that we seriously tampered with their software and that our
> version is totally different from theirs. Since they've been doing most
> of the packaging work themselves, I think that's going to be very,
> *very* hard.

Let me quote the license: "... you agree to defend and indemnify Sun ...
from (i) the use or distribution of your Operating System, or any part thereof 
..."

Where does it say we have to tamper their software?

> If I ask you to please do something, I can't then suddenly turn around
> and say that you shouln't have actually been doing that something. That
> would be dishonest, and I can't win a case in court by being dishonest.

I wish this was true in general. :-)

> > See I'm talking about a legal problem that isn't solvable by just
> > removing software.
> 
> No you're not. You're talking about an issue that only exists in
> fantasy.

And the indemnify clause is also a fantasy? I'm more than willing to
accept arguments that show me that I'm wrong, but all I got so far was
either "Sun won't do it" or "There is no problem!". I'm willing to
accept that I'm too stupid to see it, but you could at least try
convincing me, don't you think?

Michael

-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Bug#368452: ITP: libgeo-postcode-perl -- UK Postcode validation and location

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves <[EMAIL PROTECTED]>

* Package name: libgeo-postcode-perl
  Version : 0.15
  Upstream Author : William Ross <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Geo-Postcode/
* License : Dual GPL/Artistic
  Description : UK Postcode validation and location

Geo::Postcode will accept full or partial UK postcodes, validate them
against the official spec, separate them into their significant parts,
translate them into map references or co-ordinates and calculate
distances between them. Some of these functions require paid-for
databases to be useful.


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

Re: Sun Java available from non-free

[Brett Parker]

On Mon, May 22, 2006 at 01:39:47PM +0200, Wouter Verhelst wrote:
> On Mon, May 22, 2006 at 12:35:41PM +0200, Michael Meskes wrote:
> > You are told by a programmer that you are allowed to offer their
> > software on your server, but the programmer also tells you that his
> > statement is legally not binding and the license says you are not
> > allowed to offer it. Then you offer it on your server and some of your
> > customers has a huge problem with that software and wants to sue someone
> > to cover their losses. Now the company that developed the software says
> > you were never allowed to offer it and with their own version your
> > customer wouldn't have got into trouble. 
> 
> I don't think they'd be able to make a case with that, unless they can
> prove that we seriously tampered with their software and that our
> version is totally different from theirs. Since they've been doing most
> of the packaging work themselves, I think that's going to be very,
> *very* hard.
> 
> If I ask you to please do something, I can't then suddenly turn around
> and say that you shouln't have actually been doing that something. That
> would be dishonest, and I can't win a case in court by being dishonest.

Well, is there a shiny piece of paper, or verifiable gpg signed message,
or anything else actually tangable that could be taken to court that
says "this guy there said it was OK"?

> > See I'm talking about a legal problem that isn't solvable by just
> > removing software.
> 
> No you're not. You're talking about an issue that only exists in
> fantasy.

I think that you're missing the word "currently" in that sentence.

Cheers,
-- 
Brett Parker


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

Re: Sun Java available from non-free

[Frank Küster]

Matt Zimmerman <[EMAIL PROTECTED]> wrote:

> On Mon, May 22, 2006 at 01:59:21PM +0200, Alexander Sack wrote:
>> I hope this special treatment has nothing to do with the sun-ubuntu deal
>> announced a few days ago.
>
> What relationship could you possibly suspect between this event and
> processing of this package in Debian's queue/new?

Various, if I'd intended to start a flamewar.  Just use your fantasy.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: SYLN Sylvan

[Wilbert Dillon]

Cade,

http://au.geocities.com/matriarch85106

Wilbert Dillon, Ref. qqz7978



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

Re: Sun Java available from non-free

[Wouter Verhelst]

On Mon, May 22, 2006 at 01:47:01PM +0200, Romain Beauxis wrote:
> On Monday 22 May 2006 13:35, you wrote:
> > They won't sue us for distributing Java. If they do, all we have to do
> > is point the Judge to the press coverage of this change of license, and
> > to the fact that Debian was mentioned as one of the distributors asked
> > to please distribute Java. They won't have a case.
> >
> > Try as I might, and considering how lawyers and judges are human beings
> > and not automatons, I can't see any realistic scenario in which we could
> > be sued and lose a case in relation to this license. Do you?
> 
> While I understand your argument about Sun asking for this, and even found it 
> serious, please do not argue the judges are human being after all...
> Judges aply law, and that what they are meant for.

Sure. They are, however, supposed to apply some common sense in doing
so, rather than acting like an automaton.

> If there is a law which could be used against the project, then the
> judge has to apply it, no matter how 'human' he is...

My point being that there likely is no such law.

> Now come the strong point about your argument: appart from quoting from the 
> press, do you have an offical request from Sun to please distribute Java in 
> debian?

The press release made by Sun actually mentions Debian...

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Regarding podbrowser

[Ernesto Hernández-Novich]

Hi.

I reported [1] over a month ago, and also fixed it with some i18n on the side.
I've also looked at [2] and solved it, however packing some additional Perl
modules. I'm only a maintainer, my uploads being sponsored by David Moreno
Garza. How should I proceed in order to at least get [1] fixed ASAP, while
working on [2]. I emailed Florian Ragwitz a couple of times, with the same
results as the BTS: none whatsoever.

Thanks in advance.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=362648
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363508
-- 
Ernesto Hernández-Novich - On Linux 2.6.16 i686 - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't aptitude it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3


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

Re: Sun Java available from non-free

[Wouter Verhelst]

On Mon, May 22, 2006 at 02:43:31PM +0200, Michael Meskes wrote:
> On Mon, May 22, 2006 at 01:35:33PM +0200, Wouter Verhelst wrote:
> > Try as I might, and considering how lawyers and judges are human beings
> > and not automatons, I can't see any realistic scenario in which we could
> > be sued and lose a case in relation to this license. Do you?
> 
> Yes, I do, but not for distributing it.

What, prey tell, does Debian do in relation to the non-free archive that
does not involve "distributing"?

Remember that for non-free, we provide no guarantee except for the
notice that we're allowed to distribute. We don't even guarantee that
some end-user might actually be legally allowed to use the software.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Sun Java available from non-free

[Michael Meskes]

On Mon, May 22, 2006 at 03:34:39PM +0200, Wouter Verhelst wrote:
> What, prey tell, does Debian do in relation to the non-free archive that
> does not involve "distributing"?

Sorry for not being precise enough. I was talking about the indemnify
clause that worries me. And you cannot get rid of this by just stopping
to distribute Java.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: Sun Java available from non-free

[Frank Küster]

Wouter Verhelst <[EMAIL PROTECTED]> wrote:

> On Mon, May 22, 2006 at 02:43:31PM +0200, Michael Meskes wrote:
>> On Mon, May 22, 2006 at 01:35:33PM +0200, Wouter Verhelst wrote:
>> > Try as I might, and considering how lawyers and judges are human beings
>> > and not automatons, I can't see any realistic scenario in which we could
>> > be sued and lose a case in relation to this license. Do you?
>> 
>> Yes, I do, but not for distributing it.
>
> What, prey tell, does Debian do in relation to the non-free archive that
> does not involve "distributing"?
>
> Remember that for non-free, we provide no guarantee except for the
> notice that we're allowed to distribute. We don't even guarantee that
> some end-user might actually be legally allowed to use the software.

As I read the Java license, we *do* guarantee something:  We guarantee to
Sun that we will take responsibility for any damage that our operating
system causes, with unchanged Java installed, even if the problem is not
related to Java.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: Sun Java available from non-free

[Tollef Fog Heen]

Josselin Mouette skrev:


They are the ones to tell other people what to do in general.


Uh, they do?  I must have missed my list of assigned tasks from the 
ftp-master team, then.


[...]


They are the ones preventing me from working on GNOME 2.14 because
packages are stuck in NEW.


Nobody is stopping you from doing work in a private repository until 
those packages clear the new queue.


Please stop whining.

- tfheen


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

Re: Sun Java available from non-free

[Manoj Srivastava]

On 22 May 2006, Juergen A. Erhard verbalised:

> On Sun, May 21, 2006 at 03:55:53PM -0700, Steve Langasek wrote:
>> [...]  They didn't ask you because Debian is not a democracy and
>> random opinions on this decision *don't* matter.
>
> Wow, thanks for telling us.  I thought the Debian developers elected
> a DPL every year.  Of course, since I'm not one, I got that
> wrong.

I think your sarcasm is misplaced, and results from an very
 superficial analysis of how Debian works.  Very few decisions in
 Debian are taken based on vox populi; indeed, only electing the DPL
 is a significant event that is decided democratically.

On 22 May 2006, Michael Meskes outgrape:

On 22 May 2006, Michael Meskes outgrape:
> On Sun, May 21, 2006 at 11:26:26PM -0700, Russ Allbery wrote:
>>
>> That would make Debian, at most, a republic, not a democracy.
>
> Would you care to elaborate and explain it isn't a democratic
> republic then?


A DPL does not have the level of powers that I would expect to
 exist in a republic.  Delegates do not serve at the will of the DPL.
 The DPL does not tell delegates how to decide things, and can not
 fire them if they take a decision he disagrees with.

No one can tell a developer how to do their job, and
 developers can't be fired as long as they maintain a certain
 standard. Case in point: a company CEO can say everyone uses cdbs as
 a helper package, no way that is viable for Debian.

On 22 May 2006, Thijs Kinkhorst uttered the following:

> You seem to be thinking that a democracy equals that everyone has a
> say in every decision. Have you tried that in Germany? In any
> democracy, there's a spelt out procedure in what way "the people"
> can influence elected officials and decisions.

Indeed, the converse is in play here: very few decisions are
 made via popular vote. If Germany makes as few decisions based on the
 voice of the people, or the representatives of the people acting in
 their behalf, and responding to the wishes of the people discerned
 either directly or indirectly, then perhaps yes, even Germany should
 stop calling itself any kind of a democracy.  I personally doubt that
 this is the case, however.

On 21 May 2006, Josselin Mouette spake thusly:
> Re-read the constitution. By several aspects, Debian *is* a
> democracy.  Some developers are ignoring it, but this is something
> that should be fixed.

I was under the impression that I was familiar with the
 constitution, and it does not appear that way to me at all. There is
 a check and balance mechanism where a (super) majority of developers
 may override decisions taken elsewhere, but they have no voice in the
 decision making itself, and they still can't force people to act on
 these decisions.

On 22 May 2006, Michael Meskes verbalised:

> Second if Debian is no democracy what else is it???

Debian is a project where a bunch of volunteers come together
 to produce the best distribution of Linux -- and not to form a
 hierarchy, nor to have others dictate how one works.  So while we do
 make accommodations required to work as a group, and to integrate our
 software, the kinds of contracts required for a functional democracy
 have not been entered upon by us as a group.  I happen to think this
 is a good thing.

manoj
-- 
You will contract a rare disease.
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: Packages violating policy 8.2

[Manoj Srivastava]

On 22 May 2006, Goswin von Brederlow outgrape:

> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
>> On 19 May 2006, Goswin von Brederlow outgrape:
>>
>> setools is in the list, and contains libraries that it uses
>> itself, but does not break it up into multiple installed
>> packages. Setools is moving rapidly rnough that I do not intend to
>> support multiple versions of the libraries until things stabilize a
>> bit.
>>
>> However, people do build binaries against these libraries, and
>> even have private packages, and I intend to support that.
>
> I think that Policy 8.2 is fully applicable to your package then. It
> is a MUST directive so your unwillingness to allow multiple versions
> of your library to coexist does not affect the violation.

I beg to differ. There is a rationale for the policy section:
 that in general, shared library packages  are meant to be long lived,
 and that packages linking to older versions of the library are
 supported.  The policy then goes on to define how you achieve that.

In this particular case, that is not supported, or even
 possible: SELinux packages move in lock step, and older versions of
 libraries and policy, and related tools and utilities would not work
 when the base packages are installed, in most cases.

> Following 8.2 you only have 2 choices: Split the package or provide
> only static libaries and live with the wasted space. Otherwise the
> packages is RC buggy.

May I ask what is the underlying rationale for this judgement?
 In what way do you think splitting the package would work? Why is
 facilitating private packages for people who are working with SELinux
 a bad thing, when people who actually build and use these packages
 are aware of the current state of flux of SELinux?

Remember the bit about foolish consistency for the sake of
 consistency and hobgoblins. I have reviewed this issue, and have
 decided tht the current single package approach is best, given the
 circumstances.

msnoj
-- 
Let us endeavor so to live that when we come to die even the
undertaker will be sorry.  -- Maek Twain, "Pudd'nhead Wilson's
Calendar"
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: id gives conflicting results

[Juha Jäykkä]

> Juha> These are different, why? According to man id "id" and "id
> Juha> " are the same.
> The first one shows the groups that are assigned to the current
> process, the second one shows the default list of groups the user will
> get when logging in again.

Ach, I did not know this, but it is not the issue here since they were
both issued on a brand-new ssh session; i.e. they should have provided
the same list.

> That is normal for AFS. Normally I believe AFS only uses two groups
> though, something strange here.

Yep, which is why I doubt they can be the culprit here. Russ, however,
seems to think it's possible. Given the comment Aaron Ucko, I am inclined
to agree with Russ. This is not the whole story, however.

I have an X (started with gdm) session, where any shell will give me

~> id
uid=1000(juhaj) gid=1000(juhaj)
groups=33636,38650,4(adm),24(cdrom),29(audio),40(src),44(video),1000(juhaj),33636,38649

If I ssh from within this X session to the machine, I get *the exact same
list* - even in the same order this time! The plain shell cannot
access /var/log/syslog, but the shell over ssh can. The file is 644
root.adm.

A side note: on *this* machine, I *can* access the cdrom, but on the one
I originally pasted the id outputs, I could not. Go figure?

> I am not convinced it is a good idea to define the group both on the
> system and in LDAP. I prefer to keep low level system groups in
> /etc/group and high level user groups in LDAP.

This is exactly what I am after, but it does not seem to work. =(

> Try bypassing the AFS login stuff (if possible) and see if it changes
> anything.

That would be quite nasty since it would mean throwing away $HOME. If I
log in from a getty, I can access /var/log/syslog (or /dev/hdc)
regardless whether I obtain the AFS PAG or not. I can *only* reproduce
this problem on

a) machine A, user juhaj, file /var/log/syslog, X/gdm
b) machine B, user X, file /dev/hdc, X/gdm

I can work around these by

a) from within X ssh to localhost
b) log in from vt[1-6]

Both users belong to their "uid-group" both in LDAP and /etc/group, both
users also have a corresponding uid in /etc/{passwd,shadow}. These extra
groups are relics which I have not thought necessary to remove; accounts
in /etc/{passwd,shadow} exist because sudo won't work otherwise. (Our
users are accustomed to sudo, not "ssh [EMAIL PROTECTED]" with .k5login
allowing them to log in. Perhaps I could globally 'alias sudo="ssh
[EMAIL PROTECTED]"' and edit /root/.k5login accordingly on each machine?)

What should I try next? =)

-Juha

-- 
 ---
| Juha Jäykkä, [EMAIL PROTECTED]|
| Laboratory of Theoretical Physics |
| Department of Physics, University of Turku|
| home: http://www.utu.fi/~juolja/  |
 ---


signature.asc
Description: PGP signature

Re: Making init scripts use dash

[Jörg Sommer]

Hello Wouter,

Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> On Fri, May 19, 2006 at 04:49:49PM +0200, Olaf van der Spek wrote:
>> On 5/19/06, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
>> Why would they have to work with dash?
>
> If the difference in speed is indeed that insane, that's nice.
>
> I've received a bugreport with patch against the nbd packages now which
> implement whatever it's doing now with eval rather than bash arrays. Now
> I'm not sure whether this is actually going to be any faster (eval might
> require more processing time than arrays?),

Do you search something like this:

% /usr/bin/time dash -c 'i=0; while [ $i -lt 1 ]; do \
  eval test -n "\$foo_$i"; i=$(($i+1)); done'
0.50user 0.00system 0:00.52elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+202minor)pagefaults 0swaps

% /usr/bin/time bash -c 'i=0; while [ $i -lt 1 ]; do \
  test -n ${foo[$i]}; i=$(($i+1)); done'
1.54user 0.04system 0:01.59elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+518minor)pagefaults 0swaps

But I would not weight this comparison to high. This tests only a
_part_ of the init script.

But what counts more in the comparison dash vs. bash is the shell
startup. And the shell is started for every script not name foo.sh.

% /usr/bin/time dash -c 'i=0; while [ $i -lt 100 ]; do \
/bin/bash -c true; i=$(($i+1)); done'
1.13user 0.53system 0:01.68elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+43209minor)pagefaults 0swaps

% /usr/bin/time dash -c 'i=0; while [ $i -lt 100 ]; do \
/bin/dash -c true; i=$(($i+1)); done'
0.13user 0.19system 0:00.32elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+19309minor)pagefaults 0swaps

Some more shells:

% /usr/bin/time dash -c 'i=0; while [ $i -lt 100 ]; do \
/bin/zsh -c true; i=$(($i+1)); done' 
1.56user 0.65system 0:02.23elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+50709minor)pagefaults 0swaps

% /usr/bin/time dash -c 'i=0; while [ $i -lt 100 ]; do \
/bin/posh -c true; i=$(($i+1)); done'
0.14user 0.25system 0:00.75elapsed 53%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1major+20208minor)pagefaults 0swaps

Bye, Jörg.
-- 
Der kommt den Göttern am nächsten, der auch dann schweigen kann,
wenn er im Recht ist. (Cato; 234-149 v. Chr.)


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

Re: pbuilder, and why not...

[Michelle Konzack]

Hi Eduard,

Am 2006-05-14 11:26:48, schrieb Eduard Bloch:

> > a) unbuildable
> > b) uninstallable
> 
> Only in the hands of unworthy[tm].

Not realy...

> > Right solution is to use pbuilder, which will:
> > 
> > a) always ensure that package can be built using unstable
> > b) keep your build environment clean
> > c) keep your local system clean
> 
> d) Need lots of disk space

I have reserved a 9 GByte SCSI drive (u2w) for it.

> e) Take ages to unpack

Unpacking does not take the world...  less then 20 seconds for a
tar.gz of 110 MByte which is stored on another 9 GByte drive.

> f) Add more complexity for establishing build environment

Maybe

> g) Help fragmenting your filesystem

Not if you use a seperatly HDD or
at least partition which is recommended.

> h) Need extra work to be kept in synch with Sid

Hmmm, I can build the tar.gz from a script...

If I update my local Sid mirror,
it updates automaticaly the tar.gz.
(backing up the old one some generations)

Since I use pbuilder I feel more productiv and happy...

> Eduard.

Greetings
Michelle Konzack


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


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

Re: Use pbuilder, Luke... (Was: cleaning up lib*-dev packages?)

[Michelle Konzack]

Am 2006-05-14 18:19:56, schrieb Carlo Segre:

> even better, just put the pbuilder/result in a user-readable and writable 
> volume (/home/pbuilder for example) and run pbuilder as a normal user all 
> the time.

This is what I do.

Greetings
Michelle Konzack


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


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

Re: Use pbuilder, Luke... (Was: cleaning up lib*-dev packages?)

[Michelle Konzack]

Am 2006-05-14 23:08:09, schrieb Hamish Moffatt:

> Without wishing to join the mob,
> 
> e) it's difficult to install versions of packages not available from
> your regular sources.list. For example if you build a new (version of a)
> library package and then an application that uses it and want to upload
> both at the same time. You probably need to set up a local apt
> repository, which is a pain.

???

I can move successfuly build packages directly into my repository.

Greetings
Michelle Konzack


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


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

Bug#368511: Removal of libgtk1.2 ruby bindings (meta-bug)

[Loïc Minier]

Package: general
Severity: wishlist

Hi,

 I wish we could stop shipping the Ruby bindings for libgtk1.2.
 (libgtk1.2 being completely obsolete)

 The rdepends show:
bee% apt-cache rdepends libgdk-imlib-ruby1.6 libgtk-ruby1.6 libglade-ruby1.6 
libgdk-pixbuf-ruby1.6 libart-ruby1.6 libgnome-ruby1.6
libgdk-imlib-ruby1.6
Reverse Depends:
  libgnome-ruby1.6
libgnome-ruby1.6
Reverse Depends:
  libglade-ruby1.6
libart-ruby1.6
Reverse Depends:
  libgnome-ruby1.6
libglade-ruby1.6
Reverse Depends:
libgtk-ruby1.6
Reverse Depends:
  rsjog
  libxml-parser-ruby1.6
  libglade-ruby1.6
  libgdk-pixbuf-ruby1.6
  libgdk-imlib-ruby1.6
libgdk-pixbuf-ruby1.6
Reverse Depends:

 This only shows rsjog and libxml-parser-ruby1.6 as real rdeps, so it
 should be possible to get rid of these bindings quite rapidly.

  Bye,
-- 
Loïc Minier <[EMAIL PROTECTED]>

Re: Sun Java available from non-free

[Mike Bird]

On Monday 22 May 2006 06:56, Wouter Verhelst wrote:
> On Mon, May 22, 2006 at 01:47:01PM +0200, Romain Beauxis wrote:
> > On Monday 22 May 2006 13:35, you wrote:
> > > Try as I might, and considering how lawyers and judges are human beings
> > > and not automatons, I can't see any realistic scenario in which we
> > > could be sued and lose a case in relation to this license. Do you?
> >
> > While I understand your argument about Sun asking for this, and even
> > found it serious, please do not argue the judges are human being after
> > all... Judges aply law, and that what they are meant for.
>
> Sure. They are, however, supposed to apply some common sense in doing
> so, rather than acting like an automaton.

Sun says Java distributors indemnify Sun.  Debian does not have to
distribute Java.  Let us suppose - hypothetically - that Debian rashly
decides to distribute Java.

A supertanker runs aground, discharges a million gallons of crude oil,
and the environmental cleanup costs run into the billions.  Everybody
remotely connected to the event sues everybody else.  The disaster
might have been avoided had a Java weather applet in Firefox on a
Debian laptop not crashed due to a known bug that Sun had not fixed.

Suddenly everyone sues Sun.

Sun tells the court that there is a unilateral contract.  By the act of
distributing Java, Debian has agreed to indemnify Sun.  No signature
is required in law.

Suddenly Debian is in court and looking at millions of dollars in legal
fees even if found not liable.  Most likely the Master and the Owner
take most of the blame, and Debian is found liable for only a few
percent.  That's a few tens of millions of dollars.

To the judge, it's not only the law, it's just common sense.

--Mike Bird


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

Bug#368542: ITP: libcolt-java -- libraries for scientific and technical computing in Java

[Charles Fry]

Package: wnpp
Severity: wishlist
Owner: Charles Fry <[EMAIL PROTECTED]>


* Package name: libcolt-java
  Version : 
  Upstream Author : Wolfgang Hoschek <[EMAIL PROTECTED]>
* URL : http://dsd.lbl.gov/~hoschek/colt/
* License : BSD(ish) and LGPL
  Programming Lang: Java
  Description : libraries for scientific and technical computing in Java

 This distribution provides an infrastructure for scalable scientific
 and technical computing in Java. It contains, among others, efficient
 and usable data structures and algorithms for Off-line and On-line Data
 Analysis, Linear Algebra, Multi-dimensional arrays, Statistics,
 Histogramming, Monte Carlo Simulation, Parallel & Concurrent
 Programming.
 .
 It summons some of the best concepts, designs and implementations
 thought up over time by the community, ports or improves them and
 introduces new approaches where need arises. In overlapping areas, it
 is competitive or superior to toolkits such as STL, Root,  HTL, CLHEP,
 TNT, GSL, C-RAND / WIN-RAND, (all C/C++) as well as  IBM Array,  JDK
 1.2 Collections framework (all Java), in terms of performance (!),
 functionality and (re)usability.
 .
  Homepage: http://dsd.lbl.gov/~hoschek/colt/


-- System Information:
Debian Release: testing/unstable
  APT prefers stable
  APT policy: (900, 'stable'), (80, 'testing'), (70, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

[Michael Prokop]

Hello,

this issue has been discussed some time ago:

  http://lists.debian.org/debian-devel/2004/08/msg00299.html
  http://lists.debian.org/debian-devel/2004/08/msg00298.html

I would like to hear your current opinion about this topic. IMHO
removing a package should "just work" and currently this doesn't
always.

Details: several packages use something like:

# Automatically added by dh_installinit
if [ -x "/etc/init.d/$PACKAGE" ]; then
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
invoke-rc.d $PACKAGE stop || exit $?
else
/etc/init.d/$PACKAGE stop || exit $?
fi
fi

inside their prerm maintainer scripts. If stopping $PACKAGE through
invoke-rc.d/init-script fails, removing the package fails as well.

Using:

  invoke-rc.d $PACKAGE stop || true
  /etc/init.d/$PACKAGE stop || true

would be a replacement already used in some packages like for
example at, binfmt-support, dnsmasq, drbd0.7-utils, freeradius, hal,
scanlogd, sl-modem-daemon, snort.

I scanned through a pool of about 2400 packages and found the
following packages using the "stop || exit $?" construct:

915resolution: Steffen Joeris <[EMAIL PROTECTED]>
apcupsd:   Samuele Giovanni Tonon <[EMAIL PROTECTED]>
atop:  Edelhard Becker <[EMAIL PROTECTED]>
bacula-fd: John Goerzen <[EMAIL PROTECTED]>
brltty:Mario Lang <[EMAIL PROTECTED]>
cfengine2: Andrew Stribblehill <[EMAIL PROTECTED]>
clamav-daemon: Stephen Gran <[EMAIL PROTECTED]>
ddclient:  Torsten Landschoff <[EMAIL PROTECTED]>
dirmngr:   Peter Eisentraut <[EMAIL PROTECTED]>
fnfxd: Agney Lopes Roth Ferraz <[EMAIL PROTECTED]>
fwlogwatch:Alberto Gonzalez Iniesta <[EMAIL PROTECTED]>
gsm-utils: Mark Purcell <[EMAIL PROTECTED]>
hddtemp:   Aurelien Jarno <[EMAIL PROTECTED]>
icecast2:  Debian Icecast team <[EMAIL PROTECTED]>
ifplugd:   Oliver Kurth <[EMAIL PROTECTED]>
installation-report:   Debian Install System Team 
laptop-mode-tools: Bart Samwel <[EMAIL PROTECTED]>
libdevmapper1.02:  Debian LVM Team <[EMAIL PROTECTED]>
lighttpd:  Debian lighttpd maintainers <[EMAIL PROTECTED]>
makedev:   Bdale Garbee <[EMAIL PROTECTED]>
netperf:   Erik Wenzel <[EMAIL PROTECTED]>
nscd:  GNU Libc Maintainers 
openafs-client:Sam Hartman <[EMAIL PROTECTED]>
pcscd: Ludovic Rousseau <[EMAIL PROTECTED]>
pdns-backend-ldap: Debian PowerDNS Maintainers <[EMAIL PROTECTED]>
pdns-backend-pgsql:Debian PowerDNS Maintainers <[EMAIL PROTECTED]>
pdns-backend-sqlite:   Debian PowerDNS Maintainers <[EMAIL PROTECTED]>
pdns-recursor: Debian PowerDNS Maintainers <[EMAIL PROTECTED]>
plptools:  John Lines <[EMAIL PROTECTED]>
postgresql-7.4:Martin Pitt <[EMAIL PROTECTED]>
preload:   Kari Pahula <[EMAIL PROTECTED]>
procps:Craig Small <[EMAIL PROTECTED]>
quota: Michael Meskes <[EMAIL PROTECTED]>
racoon:Ganesan Rajagopal <[EMAIL PROTECTED]>
samba: Eloy A. Paris <[EMAIL PROTECTED]>
sensord:   Aurelien Jarno <[EMAIL PROTECTED]>
slapd: Debian OpenLDAP Maintainers <[EMAIL PROTECTED]>
sleepd:Joey Hess <[EMAIL PROTECTED]>
smartmontools: Guido Guenther <[EMAIL PROTECTED]>
smokeping: Jose Carlos Garcia Sogo <[EMAIL PROTECTED]>
spamassassin:  Duncan Findlay <[EMAIL PROTECTED]>
sqlrelay:  Matthias Klose <[EMAIL PROTECTED]>
sudo:  Bdale Garbee <[EMAIL PROTECTED]>
sysfsutils:Martin Pitt <[EMAIL PROTECTED]>
x11-common:Debian X Strike Force 
xfs:   Debian X Strike Force 
xinetd:Thomas Seyrat <[EMAIL PROTECTED]>

regards,
-mika-


pgpstSn1FIoTn.pgp
Description: PGP signature

Re: Sun Java available from non-free

[Russ Allbery]

Michael Meskes <[EMAIL PROTECTED]> writes:
> On Mon, May 22, 2006 at 01:51:21AM -0700, Russ Allbery wrote:

>> And whether it's a democratic republic or some other form of hybrid
>> mostly depends on whether you consider ftp-master to be a delegate
>> position or a somewhat independent check, a question that I expect
>> would only get firmly resolved under circumstances that none of us
>> really want to see.

> Wait a moment, if ftp-master was independant what should we call our
> structure then?

"A complicated volunteer organization."  :)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Sun Java available from non-free

[Daniel Stone]

On Mon, May 22, 2006 at 01:08:17AM +0200, Josselin Mouette wrote:
> By reading your email, I feel you are acknowledging the fact the
> ftp-masters cabal (I can't name it otherwise after seeing their behavior
> IRL) is treating other developers as second-class contributors who
> should just do as they say.

Actually, Josselin, in this regard you are second-class, by simple
virtue of not being an FTP master.  Just like I don't get to dictate how
GNOME gets packaged in Debian, and you don't get to dictate how X gets
developed in Debian, without the aid of a GR: the ultimate tool of
democracy.

Hope that helps,
Daniel


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

Re: Packages violating policy 8.2

[Goswin von Brederlow]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> On 22 May 2006, Goswin von Brederlow outgrape:
>> I think that Policy 8.2 is fully applicable to your package then. It
>> is a MUST directive so your unwillingness to allow multiple versions
>> of your library to coexist does not affect the violation.
>
> I beg to differ. There is a rationale for the policy section:

And if it where optional then it would read SHOULD. Or what is the
difference between MUST and SHOULD if you can jsut choose to ignore both?

>> Following 8.2 you only have 2 choices: Split the package or provide
>> only static libaries and live with the wasted space. Otherwise the
>> packages is RC buggy.
>
> May I ask what is the underlying rationale for this judgement?

My motivation is that not following 8.2 will make it impossible to
convert the package to multiarch. For the rational of 8.2 itself you
have to read policy and ask the people who wrote it. But I think it is
pretty clear from the text: to be able to install multiple versions of
the library for smooth upgrades.

>  In what way do you think splitting the package would work? Why is

The same way it works for each and every other library package that is
split in Debian.

>  facilitating private packages for people who are working with SELinux
>  a bad thing, when people who actually build and use these packages
>  are aware of the current state of flux of SELinux?

It isn't a bad thing but you aren't doing it "right" (right as laid
out in policy).

MfG
Goswin


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

Re: id gives conflicting results

[Scott J. Henson]

Juha Jäykkä wrote:
> Hi!
>
> I was digging around a problem with a user not being able to access his
> cdrom even though the user belongs to group cdrom (as reported by "groups
> user") and the cdrom device is mode rw- group cdrom. It was immediately
> clear this is a libnss-ldap issue, since the problem disappears if I add
> the user to local (i.e. /etc/group) cdrom group and remove ldap from
> group-line in /etc/nsswitch.conf.
>
> Now, what I am concerned about is this. I am logged in as user "juhaj" and
>
> ~> id
> uid=1000(juhaj) gid=1000(juhaj)
> groups=33731,37810,4(adm),4(adm),24(cdrom),24(cdrom),29(audio),29(audio),40(src),40(src),44(video),1000(juhaj),33731,37809
>
> ~> id juhaj
> uid=1000(juhaj) gid=1000(juhaj)
> groups=1000(juhaj),4(adm),24(cdrom),29(audio),40(src),44(video)
>   
The issue is with pam_group and /etc/security/group.conf.

It adds people logging in to certain groups for desktop purposes or what
not.  Pretty much id tells you what groups the process is a part of
while id  tells you what groups are listed in /etc/group.  Or
thats my understanding of this.


-- 
Scott Henson
LCSEE Systems Staff
WVU MAE Undergraduate
Ubuntu User


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

Re: Sun Java available from non-free

[Wouter Verhelst]

On Mon, May 22, 2006 at 04:48:50PM +0200, Frank Küster wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > Remember that for non-free, we provide no guarantee except for the
> > notice that we're allowed to distribute. We don't even guarantee that
> > some end-user might actually be legally allowed to use the software.
> 
> As I read the Java license, we *do* guarantee something:  We guarantee to
> Sun that we will take responsibility for any damage that our operating
> system causes, with unchanged Java installed, even if the problem is not
> related to Java.

Yes, well, don't we (informally) already do that, regardless of this
Java license?

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Sun Java available from non-free

[Russ Allbery]

Adam Warner <[EMAIL PROTECTED]> writes:
> On Sun, 21 May 2006 23:25:28 -0700, Russ Allbery wrote:
>> Adam Warner <[EMAIL PROTECTED]> writes:

>>> You're correct. So can you give reasonable and legitimate reasons why
>>> "one might not wish to follow" the "you must" guidelines in this
>>> instance?

>> Two, actually.  One for the advantage of PR with the timing of the
>> release, which while it's a reason that I can see people not agreeing
>> with and it isn't important to me personally, I think it's a reasonable
>> one.

> Later in the reply you state, "*I* think the license is murky,
> potentially problematic, and borderline for non-free.  Looks like a hard
> call.  Good thing I don't have to make it.  Many thanks to the people
> who do that work."

> I don't see how Debian acting as Sun's public relations poodle on such a
> murky, potentially problematic and borderline decision is reasonable.

I don't see how those two things are related to each other, and I also
don't think that users of Debian are going to see this as us helping Sun.
It's not like Java wasn't previously available on Debian.  The existence
or not of Java in Debian non-free is really pretty much irrelevant to the
spread of Java.  People who need to run Java applications already do so in
Debian using the existing (excellent) packaging tools and Java packages
that they get from local archives.

All this does is *potentially* make installing Sun's Java distribution
more convenient for Debian users, something that's irrelevant for free
software but which may help with running commercial software on Debian, By
doing this quickly, Debian potentially gains the appearance of being
responsive, something that Debian has had serious PR problems with in the
past.  The commercial software vendors hardly care; all their software
already says that they only support Red Hat.

I can understand this not working.  I can understand a disagreement with
this as a tactical approach.  I can certainly understand not caring, or
arguing that the existing make-jpkg solution was perfectly sufficient (I'm
quite happy with it personally, for those applications we have to run at
Stanford that require Sun's Java).  But to say that trying to gain some
good PR for being responsive is *unreasonable* is really stretching it.
Unreasonable means more than just that you disagree with the decision; it
means that you can't even understand why a reasonable person would want to
do things that way.

>> Do you think that this package would have ever gone into non-free
>> without dissent?  An ITP would have resulted in the exact same
>> discussion we just had, and if the ftp-masters had then approved it
>> after concluding that the arguments presented weren't strong enough,
>> people would have been just as upset if not more so.

> Postulating that the same decision would be made if appropriate
> processes had been followed does not excuse their short-circuiting. I
> suspect the outcome would have been different because a public process
> would have removed PR deadline pressure.

Well, I doubt it.  But it's not a useful place to have a debate.

What I *don't* agree with is your contention that the process wasn't
followed, and that comes back again to my disagreement with you that there
is any sort of public license review in Debian's package acceptance
*process*.  There is a *convention* to do public review as input to the
ftp-master decision, but the only *process* we have for license review is
ftp-master review.  They are the people responsible for doing license
review, full stop.

As long as you don't agree with this view of how Debian functions as an
organization, I doubt we're going to reach any agreement on this,
particularly since I consider the clear line of responsibility for who
does license review and approval to be a feature worth defending.  I don't
consider public consensus to be a useful method of reviewing legal
documents, although a public discussion can sometimes (and sometimes not)
be useful as *input* into the review process.

> The murky, potentially problematic and borderline decision was made
> under the pressure of a public relations deadline.

I don't see any evidence to indicate that pressure had anything to do with
the decision, and a lot of reason to believe it didn't.  I therefore don't
consider this line of reasoning at all convincing (and frankly, it seems a
little insulting to the ftp-masters).

>> *I* think the license is murky, potentially problematic, and borderline
>> for non-free.  Looks like a hard call.  Good thing I don't have to make
>> it.  Many thanks to the people who do that work.  Now, I should really
>> go look at libpam-krb5 bugs, as those are my responsibility.

> May I take this moment to thank you for your work for Debian.

Well... I wasn't digging for compliments or anything, but thank you.  My
point wasn't about what I do or don't, but more about division of labor
and responsibility.

>> As with anything else, if one's decision is 

Re: Sun Java available from non-free

[Steve Langasek]

On Mon, May 22, 2006 at 08:34:22AM +0200, Michael Meskes wrote:
> > the project by not consulting you first is so much bullshit, because *they*
> > are the ones who bear the primary liability from distributing these
> > packages, and other developers (as opposed to mirror operators) bear none at
> > all.  They didn't ask you because Debian is not a democracy and random
> > opinions on this decision *don't* matter.

> Whow! Now that really hist me hard. First of al would you please explain
> why it hurts only ftpadmins and not the project? If Sun was to sue
> someone they certainly sue the project and not a single representative.

"The project" is not a legal entity.  Sun might try to sue, in approximate
descending order of relevance:

- SPI, Inc.
- the mirror operators/sponsors
- the ftpmasters
- the SPI officers
- the package maintainer

"other Debian developers" don't have any reason to worry about their own
liability here, but the ftpmasters definitely *do*, particularly as mirror
operators and SPI could turn around and sue them for negligence.

Yes, we all have a fair bit to lose in a worst-case scenario where Sun sues
and wins SPI's assets, including the Debian trademarks, copyrights, and bank
accounts; or causes us to lose key mirrors because the sponsors deem they
can no longer afford a relationship with us.  But whereas most of us are
then free to go our own ways and create DebianPlusPlus, ftpmasters also run
the risk of winding up in court personally.

> Second if Debian is no democracy what else is it???

A meritocracy^Wtheocracy^Wtechnocracy?

On Mon, May 22, 2006 at 08:36:55AM +0200, Michael Meskes wrote:

> > ftpmasters for lack of transparency here instead of trying to support them
> > to make good decisions.

> How can we support them? I'd really like to know. After all this
> decision was made behind closed doors for reasons that might be valid or
> not. But how can you help someone if you don't know he needs help?

Some people in this thread seem to think the ftpmasters need help, but
aren't being particularly helpful.  Civilly pointing out possible problems
with the license that may have been overlooked is potentially helpful;
complaining that no one shopped the license around to -legal before the
upload (which no one ever has an obligation to do) isn't...

-- 
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: Re: Removal of libgtk1.2 ruby bindings (meta-bug)

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 368511 gnome-ruby
Bug#368511: Removal of libgtk1.2 ruby bindings (meta-bug)
Bug reassigned from package `general' to `gnome-ruby'.

> block 368511 by 368512
Bug#368511: Removal of libgtk1.2 ruby bindings (meta-bug)
Was not blocked by any bugs.
Blocking bugs added: 368512

> block 368511 by 368513
Bug#368511: Removal of libgtk1.2 ruby bindings (meta-bug)
Was blocked by: 368512
Blocking bugs added: 368513

> stop
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: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

[Florian Weimer]

* Michael Prokop:

> Using:
>
>   invoke-rc.d $PACKAGE stop || true
>   /etc/init.d/$PACKAGE stop || true
>
> would be a replacement already used in some packages like for
> example at, binfmt-support, dnsmasq, drbd0.7-utils, freeradius, hal,
> scanlogd, sl-modem-daemon, snort.

I suppose it would be preferable to fix the "stop" target of the init
script top cope with the situation that the daemon has already been
terminated.  The current situation (stopping a daemon manually before
deinstallation makes it fail) is hardly acceptable.


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

Re: Sun Java available from non-free

[Francesco Poli]

On Sun, 21 May 2006 15:55:53 -0700 Steve Langasek wrote:

> They didn't ask you because Debian is not a democracy and random
> opinions on this decision *don't* matter.

What is it, then?
A constitutional monarchy?

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpmyX1OSsAyo.pgp
Description: PGP signature

Re: Packages violating policy 8.2

[Manoj Srivastava]

On 22 May 2006, Goswin von Brederlow stated:

> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
>> On 22 May 2006, Goswin von Brederlow outgrape:
>>> I think that Policy 8.2 is fully applicable to your package
>>> then. It is a MUST directive so your unwillingness to allow
>>> multiple versions of your library to coexist does not affect the
>>> violation.
>>
>> I beg to differ. There is a rationale for the policy section:
>
> And if it where optional then it would read SHOULD. Or what is the
> difference between MUST and SHOULD if you can jsut choose to ignore
> both?

The section in question is about shared library packages, but
 I am not actually creating a shared library package. Perhaps this
 needs clarification in policy.

>>> Following 8.2 you only have 2 choices: Split the package or
>>> provide only static libaries and live with the wasted
>>> space. Otherwise the packages is RC buggy.
>>
>> May I ask what is the underlying rationale for this judgement?
>
> My motivation is that not following 8.2 will make it impossible to
> convert the package to multiarch. For the rational of 8.2 itself you
> have to read policy and ask the people who wrote it. But I think it
> is pretty clear from the text: to be able to install multiple
> versions of the library for smooth upgrades.

That person could well have been me, though I can't say I
 recall writing that.  But the intent of the section is for shared
 library packages, and  as such setools is not a shared library
 package.

I'll be happy to discuss what I need to do about multi-arch.

>> In what way do you think splitting the package would work? Why is

> The same way it works for each and every other library package that
> is split in Debian.

But I have no intention of supporting multiple versions of the
 libraries for setools, like I do for my other shared library packages
 which are indeed split up.

>> facilitating private packages for people who are working with
>> SELinux a bad thing, when people who actually build and use these
>> packages are aware of the current state of flux of SELinux?
>
> It isn't a bad thing but you aren't doing it "right" (right as laid
> out in policy).

Policy is not all infallible, not does it always apply. I
 think packages shipping libraries with relocatable code which
 explicitly do not support backwards compatibility nor multiple
 versions for the library in question, and do not split out library or
 -dev packages, are not covered by the rules designed for shared
 library packages.

manoj
-- 
Machine-Independent, adj.: Does not run on any existing machine.
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: Changing the default syslogd (again...)

[Javier Fernández-Sanguino Peña]

On Sun, May 21, 2006 at 07:38:10AM -0400, Nathanael Nerode wrote:
(...)
> Issues: (1) Quality. 
> sysklogd has 105 open bugs: 3 important (1 with patch), 43 normal (11 with
> patches), 11 minor (4 with patches), and 19 wishlist (some of which are
> really quite important, such as 44523)

Please, when was open bugs a measure of quality? We have crappy code in
Debian with 0 bugs because nobody uses it and cares to file a bug. Don't
confuse popularity (more popular == more users == more *reported* bugs) to
quality (worst code == more bugs). Reported bugs is in no way a measure to
compare package's quality.

> The source code is a hairy mess, in my opinion, and I can see why these
> bugs aren't being fixed.  It's been prone to repeated RC bugs, IMO due to
> the hairiness of the codebase.  (I would also really not like to try a
> licensing audit of this package.)

Actually, from personal experience, bugs are not fixed because the maintainer
is against all NMUs, even those that follow the steps described in the
sysklogd's source 'debian/NMU-Disclaimer'. The current maintainer's
handling of bugs and suggestions to NMU for this package discourages people
to either NMU or help him integrate patches included by other distributions
(like Red Hat / Fedora) into the version in Debian. 

Also, other developers (minus Joey Hess) don't seem to care much about this
one since nobody reported in the experimental packages I announced and
published in November 2004.

Regards

Javier


signature.asc
Description: Digital signature

Bug#368383: dumb "manual page for..." NAME section on many man pages

[jidanni]

Glad that you guys will take care of this, as it is way over my head.


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

Bug#368546: general: remarkable slow-down of whole system after 4-6 hours

[M. Dietrich]

Package: general
Severity: normal


i'm very sorry to report a other/general bug but because i could not
figure out which package is responible for the behavior i try this.

my system slows down after some hours of activity (4-6). i use that
system as desktop, using linux 2.6.16, xorg (dual screen), gnome,
sawfish and severly tools (i.e. vim, firefox, gajim) mostly for
development.

since an upgrade (i think to the xorg system with seperated packages
for drivers) i notice a slowdown of the whole system after some time.
the load in top shows values of 2 and more without any program running
(after closing firefox, vim, etc) while the system is 98% idle. no
noticable memory is used (the system has 2GB ram), swap is mostly
unused. 

opening a window takes seconds. switching focus shows visible drawing
of the highlighted frame. after a x-restart the system is faster but
only for a short time. 

all this looks to me like a memory leak. but where? system ram is not
used. it looks it could be related to sawfish, xorg or linux itself
(agp module?). i use dual screen only at work and i think (its just a
feeling) that with only one screen the system stays fast longer.

i tried google to figure out if someone else has this problem without
any success... can you point me where to look for the bug or what to
do? i'm neither a x11 nor a linux developer but a quit good c
programmer - can you help me in tracking down what's going on? 

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.16-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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