Re: checklib

[Francesco P. Lovergine]

On Thu, May 24, 2007 at 09:22:12PM +0200, Pierre Habouzit wrote:
> 
>   We're still waitinf for the lufthansa machines to set it up :/
> 
That remembers me that having some bits about that would be nice.

-- 
Francesco P. Lovergine


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

Re: Bug#425952: ITP: emacs-rails -- Emacs minor-mode for developing RubyOnRails applications

[Luca Brivio]

Alle venerdì 25 maggio 2007, Jan Michael Alonzo wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jan Michael Alonzo <[EMAIL PROTECTED]>
>
>
> * Package name: emacs-rails
>   Version : 0.5.99.5
>   Upstream Author : Emacs Rails Team
> * URL : http://rubyforge.org/projects/emacs-rails/
> * License : GPL
>   Programming Lang: Ruby
>   Description : Emacs minor-mode for developing RubyOnRails
> applications

I think this should be merged with #418558 ("RFP: rails-el -- minor mode for 
editing RubyOnRails code in Emacs"). Thanks.

--
Luca Brivio

Re: discussion with the FSF: GPLv3, GFDL, Nexenta

[Frank Küster]

Michael Poole <[EMAIL PROTECTED]> wrote:

> However, most contracts -- any negotiated contract, and many standard
> form contracts -- may specify a venue for court actions arising from
> the contract.  

That is generally the same in Germany and, AFAIK, Switzerland.  I'm not
sure about specialities like "shrink-wrap licenses", but if you rent a
car or buy a refrigerator, it's common.

Regards, Frank

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

Re: discussion with the FSF: GPLv3, GFDL, Nexenta

[Nathanael Nerode]

Don Armstrong wrote:

>To underline, the following clauses in the CDDL are problematic:
>
>   9. MISCELLANEOUS 
>
>   [...]
>   This License shall be governed by the law of the jurisdiction
>   specified in a notice contained within the Original Software
>   (except to the extent applicable law, if any, provides otherwise),
The consensus is that choice-of-law is acceptable (provided it's the
law of a 'reasonable' jurisdiction)

>   excluding such jurisdiction's conflict-of-law provisions.
Haven't heard any opinion about this exclusion

> Any
>   litigation relating to this License shall be subject to the
>   jurisdiction of the courts located in the jurisdiction and venue
>   specified in a notice contained within the Original Software,

...but this is choice of jurisdiction, and many of us think this is 
*not* free. If Sun turned nasty and decided to sue me, I should not have 
to hire a *California* lawyer or fly there simply in order to defend 
myself.  This is the problematic part.  Without choice-of-jurisdiction, 
I could simply have my lawyer file a reply saying "No alleged 
infrigement took place in California, throw this out, you have to file 
suit in my home state."

This clause could be used in an acceptable manner, of course: if the 
"notice contained within the Original Software" stated that it was in 
fact subject to the jurisdiction and venue of whatever court would 
normally have jurisdiction, then this clause would really be moot.  :-)

> with
>   the losing party responsible for costs, including, without
>   limitation, court costs and reasonable attorneys' fees and
>   expenses.
Haven't heard much if any comment on this.

>   [...]
>   You agree that You alone are responsible for compliance with the
>   United States export administration regulations (and the export
>   control laws and regulation of any other countries) when You use,
>   distribute or otherwise make available any Covered Software.
Probably OK.  Doesn't cause non-US people to be covered by export 
regulations anyway.

>It's not appropriate for a Free Software license to require users of
>software to give up rights that they would normaly have in their own
>jurisdiction.
>
>
>Don Armstrong


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

Re: discussion with the FSF: GPLv3, GFDL, Nexenta

[Michael Poole]

Nathanael Nerode writes:

>> with
>>   the losing party responsible for costs, including, without
>>   limitation, court costs and reasonable attorneys' fees and
>>   expenses.
> Haven't heard much if any comment on this.

Fee shifting distorts the default legal environment in the United
States.  European courts often award costs to the winner even with no
license clause to that effect.  I am not sure about the rest of the
world.  There are good arguments to be made on each side, but I think
a free software license is not an appropriate place to make them, or
an appropriate vehicle to enforce the licensor's views on the issue.

Michael Poole


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

Is wx salvageable? (was Re: Is Ron Lee MIA?)

[Ron]

On Thu, May 24, 2007 at 08:34:04PM -0400, Aaron M. Ucko wrote:
> "Paul Wise" <[EMAIL PROTECTED]> writes:
> 
> > I exchanged a couple of emails with him about GPG signing in April.
> 
> Good to know; apologies for the false alarm.
> 
> > I'm thinking there needs to be a co-maintainence team for wxWidgets,
> > and ron seems open to the idea.
> 
> Sounds reasonable, though I'm spread too thin already to participate
> myself; wxWidgets is rather large and popular for anyone to take on
> solo, even with close ties to upstream.

Just so we're all nice and clear on what I think is really needed here:

Linus doesn't have any trouble with the kernel tree, and its somewhat
larger, much more popular, and probably most importantly in this
context, much better managed.

The problem here is not that anything is all on one person's head.
Its actually more like the problem of the security council where a
small group of self proclaimed superpowers all claim the right of
veto over what the others try to do.  The result is not unlike that
of any other committee where the majority of players like to put Dr.
in their names.

Devoted self-interest and serving the best needs of a broadening
userbase just don't always go hand in hand, and I think that simply
throwing more eager beavers at a problem like that might give you
a bigger pile of lumber, but they aren't going to do very much to
improve your architecture.

So, if this lib is going to have a long and prosperous future,
then what it really needs is for its most devoted users to take
control over their own future with it from a grass roots level.
They are the people who are actually testing it in real use
situations, and they are the people most able to identify what
features are missing and what bugs are troublesome.

Perhaps we need to get this in git and set up a system where
people can push changes that they tested locally through a web
of related users toward inclusion in a new package release.

That seems a lot more sustainable than having me or some arbitrary
team foisting random new releases upon the users in the hope that
more of them will swim than sink.  Changes that apps in the distro
require can percolate into a new upload in a controlled and well
tested fashion, and changes that they don't require, or that are
harmful to too many of them can be excluded until they are refined.

UNPUBLISHED PROPRIETARY SOURCE (their caps not mine) and its ilk
should also be less likely to slip in and be nearly included in a
release with more eyes overseeing what gets pushed to the common
tree.

Actually maintaining the package that gets uploaded is trivial
beyond the mythical Good Judgement, its auditing the changes made
to the library api and implementation itself that is the really
tricky and ultimately the only important task, which is why I think
that what we need here is not really a team of co-maintainers so much
as a way to empower the existing and future co-dependents to share
their knowledge of what needs to change where and when.

The lib itself is pretty useless without the authors of dependent
apps, so ideally it should evolve to suit their needs, not the
other way around, whatever the rule of thumb for using a 'framework'
is supposed to be.

So if you're still reading at this point, and think I'm talking
about you and that this is a way you'd like to get _your_ work
done effectively, then give me a ping in private mail and we'll
see what sort of infrastructure we'll need to get it bootstrapped.

This isn't really a package that takes well to people dabbling in
it, but I really do think it could benefit greatly at this point
in its lifecycle from engaging its active users far more closely.

Cheers,
Ron



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

Re: Is wx salvageable? (was Re: Is Ron Lee MIA?)

[Adeodato Simó]

* Ron [Sat, 26 May 2007 01:39:41 +0930]:

> So, if this lib is going to have a long and prosperous future,
> then what it really needs is for its most devoted users to take
> control over their own future with it from a grass roots level.
> They are the people who are actually testing it in real use
> situations, and they are the people most able to identify what
> features are missing and what bugs are troublesome.

> Perhaps we need to get this in git and set up a system where
> people can push changes that they tested locally through a web
> of related users toward inclusion in a new package release.

> That seems a lot more sustainable than having me or some arbitrary
> team foisting random new releases upon the users in the hope that
> more of them will swim than sink.  Changes that apps in the distro
> require can percolate into a new upload in a controlled and well
> tested fashion, and changes that they don't require, or that are
> harmful to too many of them can be excluded until they are refined.

Ron, while I can see how your propoosed model could improve the quality
and usefulness of wxWidgets for the users of the library, it does not
address the original problem raised in this thread, which is: "Stable
releases of wxWidgets get uploaded to Debian very late".

If you want to work on improving the development process of wxWidgets in
order to produce better releases, that's perfectly fine, but once the
wxWidgets project releases a certain version as "stable", your wishes
for a better development process should not prevent you from doing your
task as a Debian maintainer. If something is released, it is a
reasonable expectation that the maintainer will upload it in a timely
manner, unless there's evidence that it's utterly broken -- which it
doesn't seem to be the case here.

Since you reckon that actually maintaining the package is not difficult,
yet you seem to be more motivated by upstream-related stuff than mere
maintenance, maybe you could benefit after all from some motivated
co-maintainers? And hey, this is completely orthogonal to your quest for
involvement from co-dependents, for which I wish you luck.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Guy: My dad made my mom have a cesarean when she had my little brother.
He wanted to make sure he was born in the 1986 tax year so he could get
another tax credit.
-- http://www.overheardinnewyork.com/archives/002968.html


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

[VAC] Sailing until 2007-07-01

[Shaun Jackman]

... and after the sailing trip I'm moving and changing jobs. So, I
won't be spending much time on Debian for the next couple months. NMU
as necessary. If anyone is interested in adopting any of my packages
on a more permanent basis, please contact me.

Cheers,
Shaun


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

Re: Is wx salvageable? (was Re: Is Ron Lee MIA?)

[Ron]

On Fri, May 25, 2007 at 07:02:26PM +0200, Adeodato Simó wrote:
> Ron, while I can see how your propoosed model could improve the quality
> and usefulness of wxWidgets for the users of the library, it does not
> address the original problem raised in this thread, which is: "Stable
> releases of wxWidgets get uploaded to Debian very late".

You seem to miss the point.  "stable" releases of wx tend to not
actually be usable for everyone for quite some time, and this is
a trend that is not improving with age.

Perhaps "tend" is the wrong word here.  Let me clarify:  NEVER has
the first "stable" release of some new wx branch gone out the door
without some critical flaw that required an immediate errata release.

It's usually not until a branch is abandoned by most of the upstream
developers that it actually becomes stable, and usable for a majority
of application developers.  Especially those trying to make and
maintain stable releases of their own.  That, by definition, is a
waiting game.

We can't just keep adding more and more wx versions to the distro,
we need a clear plan to migrate from one to the next.  Without that
we will create an awful, confusing, bloated mess for users.  The
new release has to prove itself at least as usable as the old one
before it can be considered a viable replacement.

> If you want to work on improving the development process of wxWidgets in
> order to produce better releases, that's perfectly fine, but once the
> wxWidgets project releases a certain version as "stable", your wishes
> for a better development process should not prevent you from doing your
> task as a Debian maintainer. If something is released, it is a
> reasonable expectation that the maintainer will upload it in a timely
> manner, unless there's evidence that it's utterly broken -- which it
> doesn't seem to be the case here.

You seem to also not read the daily influx of bug reports to the wx-dev
list.  Nor offer any proof that we can transition to this release
without major breakage in an important application.  That it Works For
You (perhaps) for some unspecified purposes may be nice information,
now what about for everyone else?

> Since you reckon that actually maintaining the package is not difficult,
> yet you seem to be more motivated by upstream-related stuff than mere
> maintenance, maybe you could benefit after all from some motivated
> co-maintainers? And hey, this is completely orthogonal to your quest for
> involvement from co-dependents, for which I wish you luck.

Are you volunteering to help, or demanding that I put your wishes above
carefully selecting what should be a part of the distribution and
deciding when the right time to initiate a transition might be?

As I've already said, people who have the skill and inclination to help
are eagerly invited to contact me privately about how they might do that
best.  And I think the people who can help best are those who are actually
developing and testing applications that use it.  People who just want to
throw the weight of their unsubstantiated opinion and personal demands
into the ring are invited to first read the constitution and social
contract.

I'll not entertain a flame war here on this topic.  If you are not
prepared and capable of actually helping, then I'm afraid you are
simply not, well, helping...

make sense?

 Ron



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

Processed: I have etch, but I can't reproduce, the page downloads right away

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> tags 412940 unreproducible
Bug#412940: general: every other OS can receive an HTTP response, but not etch
There were no tags set.
Tags added: unreproducible

> thanks
Stopping processing here.

Please contact me if you need assistance.

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


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

Bug#412940: I have etch, but I can't reproduce, the page downloads right away

[Eddy Petrișor]

tags 412940 unreproducible
thanks


[EMAIL PROTECTED] ~ $ wget -d http://www.ureg.ohio-state.edu/ourweb/online.html
DEBUG output created by Wget 1.10.2 on linux-gnu.

--22:00:04--  http://www.ureg.ohio-state.edu/ourweb/online.html
   => `online.html'
Rezolvare www.ureg.ohio-state.edu... 128.146.64.104
Caching www.ureg.ohio-state.edu => 128.146.64.104
Connecting to www.ureg.ohio-state.edu|128.146.64.104|:80... conectat.
Created socket 3.
Releasing 0x00560aa0 (new refcount 1).

---request begin---
GET /ourweb/online.html HTTP/1.0
User-Agent: Wget/1.10.2
Accept: */*
Host: www.ureg.ohio-state.edu
Connection: Keep-Alive

---request end---
Cerere HTTP trimisă, se aşteaptă răspuns...
---response begin---
HTTP/1.1 200 OK
Content-Length: 18506
Content-Type: text/html
Last-Modified: Thu, 17 May 2007 21:09:10 GMT
Accept-Ranges: bytes
ETag: "9f56529dc798c71:9a306"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Fri, 25 May 2007 19:00:05 GMT
Connection: keep-alive

---response end---
200 OK
Registered socket 3 for persistent reuse.
Dimensiune: 18.506 (18K) [text/html]

100%[==>]
 18.506--.--K/s

22:00:08 (623.76 KB/s) - `online.html' saved [18506/18506]
[EMAIL PROTECTED] ~ $ cat /etc/debian_version
4.0


-- 
Regards,
EddyP
=
"Imagination is more important than knowledge" A.Einstein



signature.asc
Description: OpenPGP digital signature

Bug#412940: I have etch, but I can't reproduce, the page downloads right away

[Bernd Zeimetz]

Looks like a tcp window scaling problem.
It doesn't download here until I use
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
as workaround.
See
http://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#s-window-scaling
and http://kerneltrap.org/node/6723
for more informations about the problem.

Way to fix this bug: find the broken box and replace it. Nothing Debian
can fix.

Imho this bug can be closed.

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Bug#426043: ITP: liblaf-plugin-java -- support for third-party components in Java look-and-feel libraries

[Torsten Werner]

Package: wnpp
Severity: wishlist
Owner: Torsten Werner <[EMAIL PROTECTED]>

* Package name: liblaf-plugin-java
  Version : 0.2
  Upstream Author : Kirill Grouchnikov and Erik Vickroy
* URL : https://laf-plugin.dev.java.net/
* License : BSD
  Programming Lang: Java
  Description : support for third-party components in Java look-and-feel 
libraries
 The goal of this project is to provide a generic plugin framework for
 look-and-feels and define the interface of a common kind of plugins - the
 component plugins.
 .
  Homepage: https://laf-plugin.dev.java.net/



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

compiling packages

[Oliver Block]

Hello list,

I am not very familiar with the debian developer tools. How to recompile a 
package with debuggin option (gcc -g)?

Thanks in advance.

Best Regards,

Oliver

Bug#426069: ITP: spip -- website engine for publishing

[Romain Beauxis]

Package: wnpp
Severity: wishlist
Owner: Romain Beauxis <[EMAIL PROTECTED]>

* Package name: spip
  Version : 1.9.2b
  Upstream Author : SPIP Development Team <[EMAIL PROTECTED]>
* URL : http://www.spip.net/ and 
http://trac.rezo.net/trac/spip/
* License : Mainly GPL and other open source licences
  Programming Lang: PHP with some JS
  Description : website engine for publishing

 SPIP's benefit consists in:
 .
 * managing a magazine type site i.e. made up mainly of 
   articles and news items inserted in an arborescence 
   of sections nested in each others.
 * completely separating and distributing three kinds of tasks 
   over various players: the graphic design, the site editorial 
   input through the submission of articles and news items and 
   the site editorial management.
 * spare the webmaster and all the participants to the life of 
   the site, a number of tedious aspects of web publishing as 
   well as the need to learn lengthy technical skills. 
   SPIP allows you to start creating your sections and 
   articles straight away.
 .
  Homepage: http://www.spip.net/

Other contributions on this package are welcome.

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

Kernel: Linux 2.6.20-1-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash



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

Re: compiling packages

[Oliver Elphick]

On Sat, 2007-05-26 at 03:29 +0200, Oliver Block wrote:
> Hello list,
> 
> I am not very familiar with the debian developer tools. How to
> recompile a package with debuggin option (gcc -g)?

1. Change the Makefile and/or debian/rules as necessary to add -g to the
compilation options.

2. In debian/rules, comment out the instruction to strip the binaries
(such as dh_strip).

Packages are too diverse to give a method that will work for every one.

-- 
Oliver Elphick  [EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA  92C8 39E7 280E 3631 3F0E  1EC0 5664 7A2F A543 10EA
 
   Do you want to know God?   http://www.lfix.co.uk/knowing_god.html


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

Re: compiling packages

[Guillem Jover]

On Sat, 2007-05-26 at 06:14:46 +0100, Oliver Elphick wrote:
> On Sat, 2007-05-26 at 03:29 +0200, Oliver Block wrote:
> > I am not very familiar with the debian developer tools. How to
> > recompile a package with debuggin option (gcc -g)?
> 
> 1. Change the Makefile and/or debian/rules as necessary to add -g to the
> compilation options.

Per policy all binaries should be compiled with debugging information.

> 2. In debian/rules, comment out the instruction to strip the binaries
> (such as dh_strip).

And most are going to support DEB_BUILD_OPTIONS=nostrip (if they don't
you could file a bug report).

> Packages are too diverse to give a method that will work for every one.

DEB_BUILD_OPTIONS is supposedly that method.

regards,
guillem


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