raptor.d.o down

[Bastian Blank]

Hi folks

raptor.d.o and the other debian related guests on this system (skuld,
lophos) are down. The storage for this systems died partially today and
needs to be investigated on site.

Bastian

-- 
If I can have honesty, it's easier to overlook mistakes.
-- Kirk, "Space Seed", stardate 3141.9


signature.asc
Description: Digital signature

Re: Why no Opera?

[Stanislav Maslovski]

On Tue, Aug 28, 2007 at 10:49:21AM +0200, Bernd Zeimetz wrote:
> Michael Banck wrote:
> > On Tue, Aug 28, 2007 at 02:57:07AM +0300, Lars Wirzenius wrote:
> >> It is not free software. I had a quick peek at the license in the .deb
> >> available from Opera's website, and it would not seem that they allow
> >> other parties to distribute the software, therefore Debian cannot do so.
> > 
> > That shouldn't stop us from having a discussion about it anyway!
> 
> true. If somebody could convince the opera guys to open their source -
> that would be a great thing. Opera is a very well working browser and it
> is a shame, that it is not under an open source license.
  ^^
[flame on]

I do not understand why that is "a shame". I think that the real shame is
too many broken or never finished programs under open source licenses.

[flame off]

-- 
Stanislav


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

Bug#442366: ITP: nova-filters -- a set of high-resolution ladspa filters

[Tim Blechmann]

Package: wnpp
Severity: wishlist
Owner: Tim Blechmann <[EMAIL PROTECTED]>


* Package name: nova-filters
  Version : 0.2
  Upstream Author : Tim Blechmann <[EMAIL PROTECTED]>
* URL : https://tim.klingt.org/nova/nova-filters
* License : GPL
  Programming Lang: C++
  Description : a set of high-resolution ladspa filters

The nova-filters are broken out of the nova computer music system. They 
are interpolation the control parameters and use double-precision floating 
point numbers for their internal sample representation.

i created some debian packages, that are available from:
http://klingt.org/~tim/nova-filters/

best, tim

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

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



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

Re: Packages with RFCs deleted

[Miriam Ruiz]

2007/9/14, Charles Plessy <[EMAIL PROTECTED]>:
> This said, it does not make a big difference, apart from the packager's
> time... But would I be asked to expurge one of my package, I would
> probably consider moving it in non-free instead.

The nice thing about the current system is that whoever wants to
create a derivative of Debian, knows that it's free. I understand that
you're suggesting to just make Debian maintainers life more easy by
moving that task forward to whoever wants to use Debian's source.

As a side point, IMHO the RFCs from the packages should be removed,
not just because they're not free, but also because it makes no sense
to have the same doc repeated 10 times around your system without any
reason for it.

Miry


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

Bug#442381: ITP: mirmon -- monitor the state of mirrors

[Hideki Yamane]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: mirmon
Version: 1.38-1
Upstream Author: Henk Penning <[EMAIL PROTECTED]>
URL: http://people.cs.uu.nl/henkp/mirmon/
License: MIT
Description: Mirmon helps administrators in keeping an eye on the 
 mirror sites.
 In a concise graphic format, mirmon shows each site's 
 status history of the last two weeks. It is easy to 
 spot stale or dead mirrors.





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

Re: Debian's Linux kernel continues to regress on freedom

[paddy]

On Thu, Sep 13, 2007 at 09:51:09AM -0700, Russ Allbery wrote:
> [EMAIL PROTECTED] writes:
> > On Thu, Sep 13, 2007 at 11:28:25AM -0300, Henrique de Moraes Holschuh wrote:
> 
> >> Which we have always allowed in software, even.  It falls under the
> >> "publish it with another name".
> 
> > the requirement to publish in a specific manner is an additional
> > restriction.  Granted there are software licenses like that, but are
> > they DFSG free ?
> 
> Integrity of The Author's Source Code
> 
> The license may restrict source-code from being distributed in
> modified form only if the license allows the distribution of "patch
> files" with the source code for the purpose of modifying the program
> at build time. The license must explicitly permit distribution of
> software built from modified source code. The license may require
> derived works to carry a different name or version number from the
> original software. (This is a compromise. The Debian Project
> encourages all authors to not restrict any files, source or binary,
> from being modified.)

Russ,

Thanks, but I'm thinking more of the kinds of license that says you *have*
to publish your changes and in a specific venue. seems like a close 
comparison with what has been said here about RFCs.

Seems to me that by the time I can't share my patch with my friend
directly, but *only* post it to the vendor, it is not free software,
and it sounds like this is the situation with RFCs.

Regards,
Paddy


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

Re: Packages with RFCs deleted

[paddy]

On Sat, Sep 15, 2007 at 11:38:38AM +0900, Charles Plessy wrote:
> Le Fri, Sep 14, 2007 at 12:05:26PM +0200, Pierre Habouzit a ?crit :
> 
> 
> I think that shipping the non-programmatic, non-modifiable works in
> non-free binary packages generated from source packages located in main
> would better deliver the information.

who cares about the binaries ?  after all it is not like I am going to 
want to modify the binaries directly ?  The point is that all the
materials in main fit an understood definition.  doing what you 
suggest will make source packages a lot harder to work with for users.

Regards,
Paddy


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

Bug#442394: ITP: virtualenv -- Python virtual environment creator

[Jeff Licquia]

Package: wnpp
Severity: wishlist
Owner: Jeff Licquia <[EMAIL PROTECTED]>

* Package name: virtualenv
  Version : 0.8.1
  Upstream Author : Ian Bicking
* URL : http://pypi.python.org/pypi/virtualenv/
* License : MIT-style
  Programming Lang: Python
  Description : Python virtual environment creator

virtualenv creates custom Python virtual environments, each of which can 
contain their own modules and such which are incompatible with each 
other or with the system's installed modules.  These are useful for 
running newer or older modules than are available, or for installing 
modules without requiring root access.



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

Re: Debian's Linux kernel continues to regress on freedom

[Russ Allbery]

[EMAIL PROTECTED] writes:

> Thanks, but I'm thinking more of the kinds of license that says you
> *have* to publish your changes and in a specific venue. seems like a
> close comparison with what has been said here about RFCs.

Ah, yes, that's normally not considered DFSG-free, I believe.  I had
thought this part of the thread was about a hypothetical license that
would allow reuse of RFC material provided that the result was not called
an RFC, which I believe would be DFSG-free.

> Seems to me that by the time I can't share my patch with my friend
> directly, but *only* post it to the vendor, it is not free software,
> and it sounds like this is the situation with RFCs.

Yup.  The IETF process is certainly more open than most vendors, but they
don't publish all submitted I-Ds and using RFC material requires that you
work through the process so far as I can tell.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Why no Opera?

[Russ Allbery]

Stanislav Maslovski <[EMAIL PROTECTED]> writes:
> On Tue, Aug 28, 2007 at 10:49:21AM +0200, Bernd Zeimetz wrote:

>> true. If somebody could convince the opera guys to open their source -
>> that would be a great thing. Opera is a very well working browser and it
>> is a shame, that it is not under an open source license.
>   ^^
> [flame on]

> I do not understand why that is "a shame". I think that the real shame is
> too many broken or never finished programs under open source licenses.

> [flame off]

Why?  That doesn't make a lot of sense to me.  It sounds equivalent to
saying that it's a shame that so many badly written and incoherent essays
have been published.  But of course, for essays, that's something we
embrace, since exchange of information is valuable and even though
(following Sturgeon's Law) 95% of everything is crap, you have to have the
95% to get the 5% that's good.

It seems to me that the same argument applies to software.  Of course 95%
of free software is crap; that's true of 95% of *everything*.  Reducing
the amount of free software doesn't only reduce the crap.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

IEEE 754 conformance on various architectures

[Kamaraju S Kusumanchi]

Hi
I am trying to understand why guile 1.8.2 FTBFS on alpha architecture.
The corresponding build log is at
http://buildd.debian.org/fetch.cgi?&pkg=guile-1.8&ver=1.8.2%2B1-2&arch=alpha&stamp=1188100514&file=log

I looked at the source guile-1.8-1.8.2+1/test-suite/standalone/test-round.c

and the lines where the build fails is 

  /* 2^DBL_MANT_DIG-1
 In the past scm_c_round had incorrectly incremented this value, due
 to the way that x+0.5 would round upwards (in the usual default
 nearest-even mode on most systems).  */
  x = ldexp (1.0, DBL_MANT_DIG) - 1.0;
  assert (x == floor (x));  /* should be an integer already */
  assert (scm_c_round (x) == x);  /* scm_c_round should return it
unchanged */

I do not have access to an alpha machine, so the only way I can debug the
problem is by looking at the source code. I gather that the above test
should not fail provided IEEE 745 standard is followed for performing
floating point arithmetic. What is the status of this on various
architectures (especially on alpha)?

thanks in advance
raju
-- 
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/


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

Re: Why no Opera?

[Ben Finney]

Stanislav Maslovski <[EMAIL PROTECTED]> writes:

> I do not understand why [failure to release as free software] is "a
> shame". I think that the real shame is too many broken or never
> finished programs under open source licenses.

Whether a program is broken or never finished seems to me to be
entirely orthogonal to whether the program is released as free
software. That is to say, there is plenty of broken and unfinished
software under *all* types of license, including no license.

Software released under free license terms at least has the beneficial
property that someone *else* can take it up and continue its
development after the copyright holder loses interest.

-- 
 \"Always code as if the guy who ends up maintaining your code |
  `\ will be a violent psychopath who knows where you live." —John |
_o__) F. Woods |
Ben Finney


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

Re: Why no Opera?

[Manoj Srivastava]

On Sat, 15 Sep 2007 17:40:33 +0400, Stanislav Maslovski <[EMAIL PROTECTED]> 
said: 

> On Tue, Aug 28, 2007 at 10:49:21AM +0200, Bernd Zeimetz wrote:
>> Michael Banck wrote:
>> > On Tue, Aug 28, 2007 at 02:57:07AM +0300, Lars Wirzenius wrote:
>> >> It is not free software. I had a quick peek at the license in the
>> >> .deb available from Opera's website, and it would not seem that
>> >> they allow other parties to distribute the software, therefore
>> >> Debian cannot do so.
>> > 
>> > That shouldn't stop us from having a discussion about it anyway!
>> 
>> true. If somebody could convince the opera guys to open their source
>> - that would be a great thing. Opera is a very well working browser
>> and it is a shame, that it is not under an open source license.
>   ^^
> [flame on]

> I do not understand why that is "a shame". I think that the real shame
> is too many broken or never finished programs under open source
> licenses.

> [flame off]

Well, it is a shame that I can't tweak such a good browser just
 a little bit to make it perfect (perhaps just for me).

It is a shame that people cannot help improve the browser by
 adding little bits of their own

It is a shame that people can't derive their own browsers off
 the opera engine, like they have off the gecko engine.

If you believe that freedom in the software arena empowers urs,
 and helps innovation, it is indeed a shame to see software remain
 closed source.

manoj
-- 
The days just prior to marriage are like a snappy introduction to a
tedious book.
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]

speed of COW directory copying: XFS 20x slower than ext3

[Ondrej Certik]

Hi,

I am using cowbuilder for building my packages, because the
initialization takes like 10s, compared to several minutes with
pbuilder on my system. A few days ago, I realized that on one of my
systems, it takes 0.5s only to copy the COW directory. I became
curious and wanted to know why, so I did a benchmarking [1] and to my
utter surprise, it turned out the problem is in the XFS filesystem,
that is 20x slower, than the ext3 filesystem. I know that XFS is bad
at handling small files, but 20x times?

Basically, what cowbuilder is doing is just those 2 commands:

cp -al /var/cache/pbuilder/base.cow /tmp/new
rm -rf /tmp/new

and those are the ones I tested. So it's a benchmarking of creating a
tree of hardlinks and then deleting it. For details see that page [1].

If you use cowbuilder, which filesystem are you using? And how long
does it take to copy the COW dir for you?

Ondrej

P.S. I don't know if this belongs to mentors or devel, so I am posting to both.

[1] http://wiki.debian.org/cowbuilder_benchmark


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

Re: IEEE 754 conformance on various architectures

[Steve Langasek]

On Sat, Sep 15, 2007 at 05:59:06PM -0400, Kamaraju S Kusumanchi wrote:

> I am trying to understand why guile 1.8.2 FTBFS on alpha architecture.
> The corresponding build log is at
> http://buildd.debian.org/fetch.cgi?&pkg=guile-1.8&ver=1.8.2%2B1-2&arch=alpha&stamp=1188100514&file=log

> I looked at the source guile-1.8-1.8.2+1/test-suite/standalone/test-round.c

> and the lines where the build fails is 

>   /* 2^DBL_MANT_DIG-1
>  In the past scm_c_round had incorrectly incremented this value, due
>  to the way that x+0.5 would round upwards (in the usual default
>  nearest-even mode on most systems).  */
>   x = ldexp (1.0, DBL_MANT_DIG) - 1.0;
>   assert (x == floor (x));  /* should be an integer already */
>   assert (scm_c_round (x) == x);  /* scm_c_round should return it
> unchanged */

> I do not have access to an alpha machine, so the only way I can debug the
> problem is by looking at the source code. I gather that the above test
> should not fail provided IEEE 745 standard is followed for performing
> floating point arithmetic. What is the status of this on various
> architectures (especially on alpha)?

Here's the problem:

value: 9007199254740991.00, floor: 9007199254740990.00

This is evidently a bug in glibc, calculating the floor() value wrong on
alpha.

-- 
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/


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