Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

2004-12-01 Thread Joe Wreschnig
On Wed, 2004-12-01 at 09:16, Fernanda Giroleti Weiden wrote:
> Hi all,
> I read all the thread and I noted you are forgeting a main problem about
> this package. In my point of view:
> 
> First of all, it's a sexist package, sure. Putting a program on Debian
> in which you have pictures of nude women is VERY agressive to the most 
> women. Yes, it's agressive to me.
> 
> One way of fixing this specific problem is creating a way to choose
> between pictures of women or men on the program. Yes, why not have p0rn
> pictures of a man in the .deb package too? Is it possible to fix this
> sexism problem?

If you draw some (DFSG-free) pictures of naked men for the program, I
hereby promise to patch it to support theming (offer good for two months
from today).
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

2004-12-01 Thread Joe Wreschnig
On Wed, 2004-12-01 at 15:42, Manoj Srivastava wrote:
> On Tue, 30 Nov 2004 14:01:08 -0600, Joe Wreschnig <[EMAIL PROTECTED]> said: 
> 
> > On Tue, 2004-11-30 at 13:26, Eric Lavarde wrote:
> >> Hi again,
> >> 
> >> perhaps to bring down the conversation to something more
> >> constructive, I think we should base decision to have something or
> >> not in Debian:
> >> 1. _NOT_ on personal belief (else we would probably end with
> >>nothing).
> 
> > Agreed.
> 
> >> 2. _NOT_ on local laws (same comment).
> 
> > Disagreed. If Debian is illegal to distribute to some important
> > section of people in the world, because we include strange
> > noncritical bits of software (hotbabe, the bible), then we have a
> > real problem.
> 
>   In that portion of the world, sure. DSebian should continue to
>  practice freedom, and hope that those portions of the world get
>  better in time.

But by this logic, Debian should include every bit of software it can --
if those countries with pesky copyright laws won't let us distribute it
there, then we hope that portion of the world gets better in time.
Debian will continue to practice freedom.

Of course, that's stupid. We need to decide what statutes if any this
program could violate if distributed, and if the risks of
alienating/denying that portion of users (in this case, people under
18/21 in various countries Debian is currently "ok" in) are worth it.

The feeling I get from the thread so far is that most developers don't
consider this pornography, and so okay to distribute to minors. Or
alternately, if it is, then we don't care about blocking distribution of
Debian to people in the affected countries because they have bigger
problems. Fine, then I have no problem including it, though I will
lament the continual archive bloat for Yet Another System Monitor.

(The other feeling I get is that most developers are unable to consider
this question without flaming one or more of religion, the US, or
natural human instinct to engage in sexual activity.)
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

2004-12-01 Thread Joe Wreschnig
On Wed, 2004-12-01 at 17:55, Manoj Srivastava wrote:
> On Wed, 01 Dec 2004 16:41:30 -0600, Joe Wreschnig <[EMAIL PROTECTED]> said: 
> 
> > On Wed, 2004-12-01 at 15:42, Manoj Srivastava wrote:
> >> On Tue, 30 Nov 2004 14:01:08 -0600, Joe Wreschnig
> >> <[EMAIL PROTECTED]> said:
> >> 
> >> > On Tue, 2004-11-30 at 13:26, Eric Lavarde wrote:
> >> >> Hi again,
> >> >> 
> >> >> perhaps to bring down the conversation to something more
> >> >> constructive, I think we should base decision to have something
> >> >> or not in Debian:
> >> >> 1. _NOT_ on personal belief (else we would probably end with
> >> >>nothing).
> >> 
> >> > Agreed.
> >> 
> >> >> 2. _NOT_ on local laws (same comment).
> >> 
> >> > Disagreed. If Debian is illegal to distribute to some important
> >> > section of people in the world, because we include strange
> >> > noncritical bits of software (hotbabe, the bible), then we have a
> >> > real problem.
> >> 
> >> In that portion of the world, sure. DSebian should continue to
> >> practice freedom, and hope that those portions of the world get
> >> better in time.
> 
> > But by this logic, Debian should include every bit of software it
> > can -- if those countries with pesky copyright laws won't let us
> > distribute it there, then we hope that portion of the world gets
> > better in time.  Debian will continue to practice freedom.
> 
>   I think this is mostly correct.

I think you misunderstood me. I meant *any and all programs*. After all,
just because I can't legally exercise my freedoms to modify and
distribute Microsoft Word here in the US, that shouldn't stop us from
putting it in. It's just US copyright law being dumb.

No, that doesn't work. There's some base level of stuff that's so
unlawful we don't include it because it would cut off far too much of
the userbase (or cause them to commit illegal acts). Enforced patents or
situations where taking advantage of the freedoms outlined in the DFSG
are two of them. Would you have Debian include child pornography if it
was DFSG-free and someone wanted to maintain it, and it was legal in
their country?

> > We need to decide what statutes if any this program could violate if
> 
>   Cool, for all the jurisdiction, it'll probably take 10
>  lawyers for every DD.

Or we could use common sense.

> > distributed, and if the risks of alienating/denying that portion of
> > users (in this case, people under 18/21 in various countries Debian
> > is currently "ok" in) are worth it.
> 
>   And how do we find who we are alienating? Oh, I know: lets
>  have a GR.

Don't put words in my mouth. I hate GRs.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

2004-12-02 Thread Joe Wreschnig
On Thu, 2004-12-02 at 01:36, Manoj Srivastava wrote:
> On Wed, 01 Dec 2004 18:23:21 -0600, Joe Wreschnig <[EMAIL PROTECTED]> said: 
> > On Wed, 2004-12-01 at 17:55, Manoj Srivastava wrote:
> >> And how do we find who we are alienating? Oh, I know: lets have a
> >> GR.
> 
> > Don't put words in my mouth. I hate GRs.
> 
>   That, unfortunately, may be the only recourse you have, if
>  this thing ever gets packaged.

You seem to be under the false impression I am vehemently against
packaging hot-babe.

In reality, I only wanted people to consider the legal (rather than
ethical) consequences. Early in the thread the conversation was veering
off in stupid directions about whether or not it was sexist or whether
or not we want 13 year olds seeing it; I wanted to get it off of that.

Since it seems that at least some people (such as yourself) have
considered it as a legal issue and think it not a problem, I am fine
supporting its entry into main, as I have stated elsewhere in this
thread. I am open to a common sense resolution of the issue -- provided
people are actually addressing the issue (which the vast majority of
participates in this thread are not).

This will be my last post on this topic; it's wasted too much of
everyone's time already.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Bug#284283: ITP: fairuse -- spam filter based on sender identity verification

2004-12-05 Thread Joe Wreschnig
On Sun, 2004-12-05 at 02:23, Andreas Barth wrote:
> * Stephen Birch ([EMAIL PROTECTED]) [041205 09:10]:
> > FairUCE is a spam filter that prevents spam from reaching the
> > recipient's inbox by verifying the identity of the sender. It will stop
> > the vast majority of spam without the use of a content filter, and
> > without requiring a probable spam or bulk folder that needs to be
> > checked periodically.
> 
> Is the name FairUCE or fairuse? And, what is the major advantage over
> e.g. using SPF? (In other words: In which way is the verification done?)

I dug up https://secure.alphaworks.ibm.com/tech/fairuce:

"FairUCE tries to find a relationship between the envelope sender's
domain and the IP address of the client... If such a relationship cannot
be found, FairUCE attempts to find one by sending a user-customizable
challenge/response... A future version will incorporate Sender Policy
Framework (SPF) or similar sender identification systems..."

So not only does it fail to stop spam in any useful way, it doesn't even
fail to do so according to the standard, and it sends out more email
noise while doing so.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: On the freeness of a BLOB-containing driver

2004-12-12 Thread Joe Wreschnig
On Sun, 2004-12-12 at 17:37, Matthew Palmer wrote:
> On Sun, Dec 12, 2004 at 11:39:30PM +1100, Hamish Moffatt wrote:
> > On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
> > [..]
> > > There are a number of reasons that a device's firmware won't generally 
> > > be opened to us:
> > > 
> > > 1. The manufacturer's concerns regarding the proprietary nature of 
> > > information about their device that is below the bus.
> > > 2. The fact that misprogramming the device at that level can damage the 
> > > hardware.
> > > 3. They aren't going to want to support more firmware versions than they 
> > > have to.
> > 
> > And 4. They're not allowed to by regulations, eg wireless hardware
> > whose firmware cannot be distributed by FCC rule.
> 
> I'm pretty sure that FUD got killed last time someone (perhaps you, even)
> raised it.  From memory, the FCC rules only state that there must be a means
> for effectively preventing the modification of the firmware used in the
> device.  Obscurity is not the only means of doing that.

Nor is it a means for doing that (though it's probably good enough for
FCC approval).
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Bug#285705: ITP: libifp -- library for communicating with iRiver iFP audio devices

2004-12-14 Thread Joe Wreschnig
Package: wnpp
Severity: wishlist

* Package name: libifp
  Version : 0.1.0.11
  Upstream Author : Geoff Oakham
* URL : http://ifp-driver.sourceforge.net/libifp/
* License : GNU GPL
  Description : library for communicating with iRiver iFP audio devices

libifp allows you to communicate with iRiver iFP audio devices. It
provides a high-level interface to upload and download files to and
from the device, as well as other functions like battery status and
firmware updating.

The API and code are derived from the ifp-line tool.




Bug#285707: ITP: quodlibet -- audio library manager and player for GTK+

2004-12-14 Thread Joe Wreschnig
Package: wnpp
Severity: wishlist

* Package name: quodlibet
  Version : 0.7
  Upstream Author : Joe Wreschnig <[EMAIL PROTECTED]>
* URL : http://www.sacredchao.net/~piman/software/quodlibet.shtml
* License : GNU GPL
  Description : audio library manager and player for GTK+

 Quod Libet is a music player based around searching your audio library
 based on the values of the tags in it. It supports MP3, Ogg Vorbis, FLAC,
 and tracked (MOD/XM/IT) audio formats. Features include:
  - A simple user interface.
  - Searching based on regular expression matching.
  - Tag editing, including cross-format changes and mass editing.
  - Many supported tags, like "conductor", "performer", and "discnumber".
  - Shuffle, repeat, multimedia keys, Unicode, a tray icon, album cover
display, and other features found in most modern media players.
 .
 Quod Libet is written in Python and uses PyGTK+.

I've been maintaining packages for this outside of the Debian archive
since its inception; the next release (coming sometime within the next
week, I hope) is the first I feel comfortable putting in the archive.

The package will be split up into an arch: all and an arch: any
prior to the upload, since the arch-dep part is only about 50k.




Re: Bug#293382: ITP: zen-cart -- simple SQL and php based e-commerce solution

2005-02-02 Thread Joe Wreschnig
On Wed, 2005-02-02 at 15:46 -0500, Tim Peeler wrote:
> Package: wnpp
> Severity: wishlist
> 
> 
> * Package name: zen-cart
>   Version : 1.2.3d
>   Upstream Author : Ian C Wilson 
> * URL : http://www.zen-cart.com/
> * License : GPL
>   Description : simple SQL and php based e-commerce solution
> 
> Zen Cart is a php driven e-commerce solutions based on oscommerce
> ..
> Zen Cart truly is the art of e-commerce; a free, user-friendly, open
> source shopping cart system. The software is being developed by group
> of like-minded shop owners, programmers, designers, and consultants
> that think e-commerce could be and should be done differently. Some
> "solutions" seem to be complicated programming exercises instead of
> responding to users' needs, Zen Cart puts the merchant's and shopper's
> requirements first.  Similarly, other programs are nearly impossible
> to install and use without an IT degree, Zen Cart can be installed and
> set-up by anyone with the most basic computer skills. Others are so
> expensive ... not Zen Cart, it's FREE!

So what does it actually do, besides generate buzzwords?
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Bug#293167: ITP: request-tracker3.4 -- Extensible trouble-ticket tracking system

2005-02-02 Thread Joe Wreschnig
On Wed, 2005-02-02 at 19:04 -0600, Steve Greenland wrote:
> On 02-Feb-05, 18:31 (CST), Matthew Palmer <[EMAIL PROTECTED]> wrote: 
> > 
> > So archive bloat is not a problem for you, and "apt-get dist-upgrade" not
> > actually providing upgrades to the latest versions of everything is
> > perfectly fine? 
> 
> In the case of RT, yes. 
> 
> I notice that there are several different versions of gcc in the
> archive, and nobody seems to be bothered by that. Likewise, there are
> several versions of python. There are, of course, good reasons for both.

As for Python, no there aren't, except for stupid upstream behavior
(Python upstream, and upstream for applications that don't keep
themselves up-to-date). Even then, the situation we had at one point
where Debian contained four versions of Python was totally stupid. GCC
at least has the excuse different architectures need different versions.

Why not hold up the examples of the tens of thousands of packages that
only have one version, even though they are development "frameworks"? To
pick one of extreme complexity, Perl. Perl migrations go smoother than
Python migrations, too...
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: dh_movefiles, tar vs. mv

2005-02-26 Thread Joe Wreschnig
On Fri, 2005-02-25 at 11:32 -0800, Oliver Kurth wrote:
> On Fri, 2005-02-25 at 20:25 +0100, GOMBAS Gabor wrote:
> > On Fri, Feb 25, 2005 at 07:54:27PM +0100, Frank KÃster wrote:
> > 
> > > Correct. So, why not use mv?
> > 
> > Add a new "--move" flag to dh_installfiles, come up with some exact
> > numbers showing the build time/disk usage savings for your favorite Big
> > Package (hard numbers usually very helpful for promoting new features),
> > and send the numbers together with the patch to the debhelper maintainer. 
> > 
> > Someone already mentioned that a complex package might want to install
> > the same file to multiple different locations, so making this the
> > default is probably not feasible.
> 
> How about hard linking with ln instead? You would have the best of both
> approaches: it is fast, and still possible to have the same file in
> multiple packages.

I believe Python distutils (like autoconf/automake for Python) uses this
approach for its various build/dist targets, and there don't seem to
have been any problems/complaints. It also cuts down on hard drive space
requirements.

However, it probably shouldn't be default. A hard link would be a pretty
incompatible change if someone modifies the file after it's been
dh_installed (I don't have any concrete examples, but I suspect
something does it, if only because 13000 packages guarantees every nasty
hack appears at least once :).
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Bug#297233: ITP: wmansied -- An ANSI/ASCII editor.

2005-02-28 Thread Joe Wreschnig
On Mon, 2005-02-28 at 21:28 +, Roger Leigh wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> "Nelson A. de Oliveira" <[EMAIL PROTECTED]> writes:
> 
> > WMAnsiEd is an ANSI editor with functions like line drawing, ellipse,
> > box, etc., written in Qt. All IBM ANSI and ASCII characters are
> 
> "ANSI" is pretty meaningless as a "standard", since ANSI standardised
> many different things.  Perhaps you mean it implements ISO-6429
> (ECMA-48) SGR control sequences, or maybe something entirely
> different?  Either way, it would help if you were much more specific.
> 
> (This applies equally to the other ITP.)

For most of us who grew up on IBM PC systems in the DOS days, "ANSI" was
a character set / graphics style first, and an organization second. I
don't know what the official standards for the character set and
terminal specifications are, but people who are interested are going to
be looking for "ANSI" or "ANSI graphics", not a standards document
number.

(Compare the usage of "ISOs" to refer to CD images regardless of their
status as ISO-9660 filesystems and ISO's other standards.)
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Is NEW processing on hold? (was: Question for candidate Towns)

2005-03-07 Thread Joe Wreschnig
On Mon, 2005-03-07 at 22:32 +0100, Martin Zobel-Helas wrote:
> Hi Marc,
> 
> On Monday, 07 Mar 2005, Marc Haber <[EMAIL PROTECTED]> wrote:
> > On Sat, 5 Mar 2005 18:03:50 +0100, Nico Golde <[EMAIL PROTECTED]> wrote:
> > >* Frank KÃster <[EMAIL PROTECTED]> [2005-03-05 17:52]:
> > >>http://lists.debian.org/debian-devel-changes/2005/03/msg00019.html
> > >
> > >But it is very slow at the moment.
> > 
> > Yes. And the people responsible refuse - as usual - to communicate. So
> > nobody knows about the reason.
> Might it be that they try to get no new packages into the archive before
> a release? It is just a guess...

One of the goals of testing was to avoid freezing large portions of
unstable prior to a release. NEW should not stop processing before a
release.

Now it's possible (even likely) that the people involved have better
things to do before a release than process NEW, like talk to mirrors or
test infrastructure. I haven't seen any evidence to this effect, though,
and if it's the case I think most people would like to know.

This delay is bothering our users -- I have several packages waiting in
NEW, and I've either had to upload them to people.debian.org (libifp,
which has even had a new upstream release while it's been rotting
there), or gotten 2-3 people per week emailing me privately about
(libmusepack, python-flac).

If NEW is stopped because the FTP masters are busy, other developers
should know. If NEW is stopped because FTP masters or RMs think that
processing new packages prior to a release causes problems, other
developers should know. I'm not saying they're *wrong*; likely they know
better than most developers the relationship between RC bugs in testing
and new packages. But I would like to have something concrete to tell
upstream developers when they ask me why, despite my having a package
ready a month ago, their users still can't get it via APT. Right now I
just have to mumble something about sarge, busy people, and "Real Soon
Now." It frustates upstream, it frustrates our users, and it frustates
other Debian developers.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Bug#346528: ITP: gnome-clipboard-daemon -- keeps the content of your X clipboard in memory so the clipboard won't get lost even after you close the application you copied from

2006-01-08 Thread Joe Wreschnig
On Sun, 2006-01-08 at 12:29 -0500, Asheesh Laroia wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Asheesh Laroia <[EMAIL PROTECTED]>
> 
> X-Debbugs-CC: Josselin Mouette <[EMAIL PROTECTED]>;

^-- This needs to be a proper header, not a pseudo-header.
You probably also meant 'Debian GNOME Maintainers
<[EMAIL PROTECTED]>'.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Intent to remove several packages - ddrmat-source, python-flac, python-modplug

2006-01-12 Thread Joe Wreschnig
Hi,

I'm going to be requesting removals for packages I no longer need or
have the hardware to test (and was also upstream for); speak up within
the next week if you want them.

ddrmat-source: I believe this driver was merged into the kernel early in
the 2.6 series; it's also for pretty obsolete hardware (parallel port
Playstation controller adapters; most people have moved onto USB ones).
My parallel port fried recently, so I can no longer make sure it works
properly.

python-flac: Quod Libet used to use this. It won't as of the next
release. It's a pretty nasty SWIG wrapper, and upstream's email bounces.
If this is of interest to you, talk to me first, because the replacement
I've written might suit your needs better (no SWIG, fully tested, nicer
API).

python-modplug: Two people on IRC have expressed interest in using this
for their own projects about 6 months ago, but then never got back to
me, so as far as I know there are no users of it. It is fully tested and
simple enough that it probably won't require any maintenance beyond
Python transitions.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Andrew Suffield

2006-01-15 Thread Joe Wreschnig
On Sun, 2006-01-15 at 06:28 -0500, sean finney wrote:
> On Sun, Jan 15, 2006 at 11:58:51AM +0100, Adrian von Bidder wrote:
> > Do you think your constant bitching is funny?  Do you think it achieves 
> > anything?
> > 
> > There are other DDs who are also involved in intense debates and flamewars 
> > very often, but you're the only one  where I constantly get the impression 
> > that you're just being childish, insulting and annoying for the sake of it.
> 
> ...says someone who just publicly ostracized a fellow dd
> on a public mailing list.  personal opinions of the matter aside,
> debian-devel is not the place for ridiculing other developers, no
> matter how justified you feel you may be. 
> 
> please post follow-ups to -private.

I said this on -private, and I'll say it here -- why is it appropriate
to be an ass on -private, but not on -devel? It's not appropriate
anywhere. That goes for Adrian, and Andrew, and everyone. It also leads
to situations like the present, where it looks like we're doing nothing
to reprimand offensive behavior, because most conversation is happening
on -private, while the original, offensive message is sitting on d-d-a.

If you are upset by how Andrew acted, talk to him rationally, regardless
of whether it's public or private.

If you are *very* upset by how Andrew acted, there is an appropriate and
agreed-to policy for expelling developers. Roger Leigh has mentioned his
interest in seeing this through; contact him.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: when and why did python(-minimal) become essential?

2006-01-17 Thread Joe Wreschnig
On Tue, 2006-01-17 at 09:32 -0800, Matt Zimmerman wrote:
> On Tue, Jan 17, 2006 at 02:31:47PM +0100, Adam Borowski wrote:
> > You're underestimating the grave consequences of losing 25MB off every 
> > memory stick and virtual machine.
> 
> python-minimal is about two megabytes installed, with no non-Essential
> dependencies.
> 
> (strictly an observation of fact; I'm not expressing an opinion either way
> about the change)

The python-minimal I see depends on all of python2.3. In Ubuntu perhaps
it's 2MB, but in Debian right now it's almost all of Python.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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



Re: when and why did python(-minimal) become essential?

2006-01-18 Thread Joe Wreschnig
On Wed, 2006-01-18 at 11:21 +0100, Thomas Hood wrote:
> Steve Langasek wrote:
> > Given that python-minimal is Essential: yes in Ubuntu, the *only*
> > use for this package in Debian (given that there would be no
> > packages in the wild that depend on it -- the definition of Essential
> > is that you don't need to depend on it) is if we make it Essential: yes
> > as well.
> 
> 
> I don't see why.  If python-minimal were included in Debian then some
> packages that currently Depend on python could (if their needs are
> minimal) Depend on python-minimal instead.  This would be an improvement,
> and obtaining this benefit does not require that python-minimal be
> Essential: yes in Debian.

This depends entirely on what's in python-minimal. At 2MB, I have my
doubts that most Python programs/modules in Debian will work.

I agree with Steve. Unless we're going to make this package Essential,
it's kind of pointless (unless compatibility with Ubuntu is a primary
goal -- maybe it should be, but then someone needs to explain why,
because it's not obviosu to me). And I don't see a need to make it
Essential.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: when and why did python(-minimal) become essential?

2006-01-18 Thread Joe Wreschnig
On Wed, 2006-01-18 at 13:27 -0800, Matt Zimmerman wrote:
> On Wed, Jan 18, 2006 at 11:21:32AM +0100, Thomas Hood wrote:
> > Steve Langasek wrote:
> > > Given that python-minimal is Essential: yes in Ubuntu, the *only*
> > > use for this package in Debian (given that there would be no
> > > packages in the wild that depend on it -- the definition of Essential
> > > is that you don't need to depend on it) is if we make it Essential: yes
> > > as well.
> > 
> > I don't see why.  If python-minimal were included in Debian then some
> > packages that currently Depend on python could (if their needs are
> > minimal) Depend on python-minimal instead.  This would be an improvement,
> 
> This is something that Python upstream explicitly does not want; the only
> reason for creating python-minimal was so that it could be Essential: yes,
> not to support stripped-down Python installations.

So why does Debian need/want python-minimal?

(This is a question mostly for Matthias, I think, but if you know the
answer that's great.)
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: when and why did python(-minimal) become essential?

2006-01-18 Thread Joe Wreschnig
On Thu, 2006-01-19 at 12:12 +1000, Anthony Towns wrote:
> debian-python Cc'ed
> 
> On Wed, Jan 18, 2006 at 07:02:32PM -0600, Joe Wreschnig wrote:
> > > This is something that Python upstream explicitly does not want; the only
> > > reason for creating python-minimal was so that it could be Essential: yes,
> > > not to support stripped-down Python installations.
> > So why does Debian need/want python-minimal?
> > (This is a question mostly for Matthias, I think, but if you know the
> > answer that's great.)
> 
> Some reasons:
> 
>   * compatability with Ubuntu -- so that packages can be easily ported back
> and forth between us and them; I expect most of the work ubuntu might do
> on improving boot up will require python-minimal

This would be nice. Right now it's accomplished through patches Ubuntu
makes to dh_python and cdbs. They'd probably like to drop those.

>   * allowing us to easily use python (as well as C, C++ and perl) for programs
> in the base system

I wouldn't mind this, but it does seem to be somewhat against the
definition of "base."

>   * allowing us to provide python early on installs to make users happier

This feels weak to me; it applies equally well to any language a user
might want.

> I don't know what's actually in (or more importantly not in)
> python2.4-minimal though.

I'm eyeballing right now. Things that jump out at me:
 * No character encoding, translation, or locale handling.
 * A little oddly, loss of shutil.
 * No sockets.

The first one seems like it would be a show-stopper to me, unless we
expect programs in the base system to only deal with ASCII. This is a
fairly large addition to package, too.

The second can easily be fixed; possibly just oversight. It's a small
module and gives Python equivalents of cp -r, rm -r, and mv.

The third seems like something software in base may want to do; I
mention it specifically because perl-base include socket support.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: when and why did python(-minimal) become essential?

2006-01-19 Thread Joe Wreschnig
On Thu, 2006-01-19 at 09:31 +, Colin Watson wrote:
> On Wed, Jan 18, 2006 at 11:36:13PM -0600, Joe Wreschnig wrote:
> > On Thu, 2006-01-19 at 12:12 +1000, Anthony Towns wrote:
> > > Some reasons:
> > > 
> > >   * compatability with Ubuntu -- so that packages can be easily ported 
> > > back
> > > and forth between us and them; I expect most of the work ubuntu might 
> > > do
> > > on improving boot up will require python-minimal
> > 
> > This would be nice. Right now it's accomplished through patches Ubuntu
> > makes to dh_python and cdbs. They'd probably like to drop those.
>
> As a point of information, Ubuntu doesn't patch dh_python at present,
> and I don't see any Python-related changes in cdbs at the moment either.

Oh, hrm. So packages that need to use python-minimal manually handle
their Python dependencies? That seems like a significant step backwards,
in terms of handling transitions.

>   $ dpkg -c 
> /mirror/ubuntu/pool/main/p/python2.4/python2.4-minimal_2.4.2-1ubuntu2_i386.deb
>  | grep socket
>   -rw-r--r-- root/root 49608 2006-01-17 12:59:02 
> ./usr/lib/python2.4/lib-dynload/_socket.so
>   -rw-r--r-- root/root 12876 2006-01-17 12:58:18 
> ./usr/lib/python2.4/socket.py

D'oh. Apparently I'm blind.

Thanks.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: when and why did python(-minimal) become essential?

2006-01-21 Thread Joe Wreschnig
On Sat, 2006-01-21 at 01:48 -0800, Thomas Bushnell BSG wrote:
> Matt Zimmerman <[EMAIL PROTECTED]> writes:
> 
> > One example is .config maintainer scripts, some of which are quite complex
> > and worth writing in a higher-level language than shell.
> 
> This is surely true; Steve Langasek asked if this was a real issue in
> Ubuntu or merely a potential issue.
> 
> Granted if it is a real issue, then why not use perl?   Yes, I hate
> perl too, but really, the argument "hey, people like Python too"
> implies that we should have a scheme interpreter, a perl, a python,
> emacs lisp, and well, everything anyone might want.
> 
> Or, we say "we aren't going to support *every* high-level language"
> and stick to one.

There's nothing that prevents us saying "we aren't going to support
every high-level language" and stick to more than one (we already stick
to two -- sh and Perl). It just means "I'd like to write scripts in X"
alone isn't a good enough reason.

Python is the "official" language of Ubuntu. If we want to merge work
they're doing (Anthony Towns mentioned their work on boot speed, for
example) it's a good idea to structure our Python like theirs is. This
seems to be a good reason to consider python-minimal and some form of
Python in Essential.

The real issue here is that the original upload didn't do that; it went
through the motions without actually changing our Python packaging or
upgrading the version, so we just got all of Python as Essential. No one
wanted that.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: when and why did python(-minimal) become essential?

2006-01-21 Thread Joe Wreschnig
Don't reply to me directly. I should not have to tell you this.

On Sat, 2006-01-21 at 13:03 -0800, Thomas Bushnell BSG wrote:
> > Python is the "official" language of Ubuntu. If we want to merge work
> > they're doing (Anthony Towns mentioned their work on boot speed, for
> > example) it's a good idea to structure our Python like theirs is. This
> > seems to be a good reason to consider python-minimal and some form of
> > Python in Essential.
> 
> This does not scale.  If each Debian derivative chooses a different
> "official language", and we put each of them in Essential, then we end
> up with every language in Essential.

We can burn those bridges when we come to them. Right now there's only
one such distribution, with one such language, which has already done
all the work to strip it down to a small size.

Unless you expect some derived Debian distribution to use Scheme some
day, this is sophistry. If you really do expect that, it's insanity.

> What I hear is *not* that Python is the official language instead of
> Perl, but that it is the official language *in addition to* Perl.  So
> now, why?  Remember, "I'd like to write scripts in X" is not a good
> enough reason, so what is the reason for having two official
> languages?

I don't manage Ubuntu policy, nor do I want to. I am a Debian developer
interested in Debian. The argument for Debian is not "I'd like to write
scripts in X" but "There is this large body of people writing scripts in
X, and it'd be nice if we could work with them."
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer

2006-01-24 Thread Joe Wreschnig
On Tue, 2006-01-24 at 20:52 +0100, Mike Hommey wrote:
> On Tue, Jan 24, 2006 at 06:58:14PM +0100, Loïc Minier <[EMAIL PROTECTED]> 
> wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Loic Minier <[EMAIL PROTECTED]>
> > 
> > * Package name: gst-fluendo-mp3
> >   Version : 0.10.0
> >   Upstream Author : Jan Schmidt <[EMAIL PROTECTED]>
> > * URL : http://www.fluendo.com/resources/fluendo_mp3.php
> > * License : MIT
> >   Description : Fluendo mp3 decoder GStreamer plugin
> >  This GStreamer plugin permits decoding of MPEG 1 audio layer III
> >  streams.  It is derived from the ISO MPEG dist10 reference package.
> >  .
> >  This plugin differs from the GStreamer MAD plugin in that it doesn't
> >  depend on a GPL library.
> >  .
> >  http://www.fluendo.com/resources/fluendo_mp3.php
> 
> What about the "redistribution contract" that "any distribution or Unix
> maker out there who want to include the Fluendo MP3 plug-in with their
> distribution" have to sign "to become an official redistributor" ?

AFAIK that's only if you want to distribute their binary. If you want to
distribute their source, then that's just the MIT license.

However, why are we packaging this if we're not going to sign that?
Plenty of GPLd applications in Debian still use GStreamer, so this
doesn't solve a real problem. I would rather see either
 1) -ugly get past NEW, we get MAD, users get MP3 decoding, situation
stays as its been for years, or 
 2) We take the patent issue seriously, and drop all MP3 support.

(Speaking with my hat as a DD, and as upstream maintainer of an MP3
player that uses GStreamer and doesn't want to deal with two sets of MP3
decoding bugs.)
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer

2006-01-24 Thread Joe Wreschnig
On Wed, 2006-01-25 at 17:08 +1100, Russell Coker wrote:
> On Wednesday 25 January 2006 12:10, Joe Wreschnig <[EMAIL PROTECTED]> wrote:
> >  2) We take the patent issue seriously, and drop all MP3 support.
> 
> MP3 software does not belong in Debian/main.  Unlike many patents the MPEG 
> patents probably have a good basis.

To make it clear, this is a *radical* divergence from our previous
position. If other distributions start shipping the Fluendo plugin, it
is also a major step backwards in usability.

> As far as I am aware OGG media is a good alternative to MPEG in every 
> technical measure.  OGG is not as well supported by 3rd party devices (no 
> support in iPod for example) but there are devices which support it (iRiver 
> as an example - incidentally the iRiver gives better sound quality according 
> to the experts and allows recording so is better than the iPod anyway).

It's clear to me you've never had to use an iRiver's Ogg support. It
fails outside a limited bitrate range, drains battery faster, does not
read metadata, and is not available on all devices. Newer iRivers also
use a proprietary communications protocol that is not yet supported in
Debian. Finally, the recording is MP3 only.

Technical qualities of a format have also never been a major
consideration of Debian's support of them, or in user choices.

If we're going to do it, do it because we're taking a stand or think
there's a license violation. Not because we like Ogg.

> By continuing to support MPEG in Debian/main we are decreasing the support of 
> OGG.

By continuing to support MS Word .doc in Debian/main, we are decreasing
the support of OpenDocument. So what? Users have millions, billions of
files in these formats. If we can support them, we should.

> This also applies to mpc123.

The Musepack developers are of the opinion that they no longer infringe
on any patents, as the algorithm has diverged wildly from the MPEG-1
Layer 2 algorithm upon which it is based. It's on at least as good legal
ground as every other audio format in Debian. So please leave it out of
this discussion.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer

2006-01-24 Thread Joe Wreschnig
On Wed, 2006-01-25 at 07:49 +0100, Daniel Baumann wrote:
> Russell Coker wrote:
> > MP3 software does not belong in Debian/main.  Unlike many patents the MPEG 
> > patents probably have a good basis.
> > 
> > Any software which is based on Frauhoffer patents (MP3 and other similar 
> > encoding systems) should be on an external archive.
> 
> From a technical point of view, I disagree. Fluendo seems to have a
> patent license for its plugin, and they are allowed to relicense it
> (under some conditions, e.g. the redistribution contract). Assumed, that
> this is all sane, there is no legal problem to include it main.

To get this license one must agree to a contract that forbids
modification and further redistribution. It's not going to happen for
Debian.

Alternately, you can download the source, which is freely licensed. But
then you don't get the patent license. So we're back at the status quo,
but with an MP3 decoder that's worse than the one we currently don't
have a patent license for.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer

2006-01-24 Thread Joe Wreschnig
On Wed, 2006-01-25 at 07:59 +0100, Daniel Baumann wrote:
> Joe Wreschnig wrote:
> > To get this license one must agree to a contract that forbids
> > modification and further redistribution. It's not going to happen for
> > Debian.
> 
> Ok, when its not DFSG-compliant but redistributable, why not put it in
> non-free (except personal reasons like 'I don't support non-free')?

Are you going to sign the contract? I'm sure not putting my signature on
anything about MP3s.

How does Debian sign a contract anyway?
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer

2006-01-25 Thread Joe Wreschnig
On Wed, 2006-01-25 at 19:58 +1100, Russell Coker wrote:
> On Wednesday 25 January 2006 17:40, Joe Wreschnig <[EMAIL PROTECTED]> wrote:
> > On Wed, 2006-01-25 at 17:08 +1100, Russell Coker wrote:
> > > MP3 software does not belong in Debian/main.  Unlike many patents the
> > > MPEG patents probably have a good basis.
> >
> > To make it clear, this is a *radical* divergence from our previous
> > position. If other distributions start shipping the Fluendo plugin, it
> > is also a major step backwards in usability.
> 
> Have we consulted a lawyer about this?

Probably not.

> > > As far as I am aware OGG media is a good alternative to MPEG in every
> > > technical measure.  OGG is not as well supported by 3rd party devices (no
> > > support in iPod for example) but there are devices which support it
> > > (iRiver as an example - incidentally the iRiver gives better sound
> > > quality according to the experts and allows recording so is better than
> > > the iPod anyway).
> >
> > It's clear to me you've never had to use an iRiver's Ogg support. It
> > fails outside a limited bitrate range, drains battery faster, does not
> > read metadata, and is not available on all devices. Newer iRivers also
> > use a proprietary communications protocol that is not yet supported in
> > Debian. Finally, the recording is MP3 only.
> 
> iRiver will have more incentive to support OGG well if Linux distributions 
> take a stand on this issue.

Hah hah. Yeah, sure. Or iRiver will just ignore us like they always
have.

(p.s. It's "Ogg". Not "OGG".)

> > > By continuing to support MPEG in Debian/main we are decreasing the
> > > support of OGG.
> >
> > By continuing to support MS Word .doc in Debian/main, we are decreasing
> > the support of OpenDocument. So what? Users have millions, billions of
> > files in these formats. If we can support them, we should.
> 
> If there was a patent on the MS file formats then I would advocate removing 
> support from Debian.

MS claims they've patented the Office 12 format, the ASF format, the FAT
filesystem, etc. There's a patent on 90-100% of the archive.

> > > This also applies to mpc123.
> >
> > The Musepack developers are of the opinion that they no longer infringe
> > on any patents, as the algorithm has diverged wildly from the MPEG-1
> > Layer 2 algorithm upon which it is based. It's on at least as good legal
> > ground as every other audio format in Debian. So please leave it out of
> > this discussion.
> 
> Do we have any legal advice on this?

No, we don't have any legal advice that says Musepack is patent-free. We
don't have legal advice that says Ogg is patent-free. We probably don't
have legal advice that says *anything* in the archive is patent-free,
and I suspect if we tried we'd find out *nothing* is. I suggest you find
something better to do than witch-hunt every non-Ogg format out of main.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer

2006-01-25 Thread Joe Wreschnig
On Wed, 2006-01-25 at 09:35 +0100, Loïc Minier wrote:
> Hi,
> 
> On Tue, Jan 24, 2006, Joe Wreschnig wrote:
> > AFAIK that's only if you want to distribute their binary. If you want to
> > distribute their source, then that's just the MIT license.
> 
>  Yes, that's how I see it too.
> 
> > Plenty of GPLd applications in Debian still use GStreamer, so this
> > doesn't solve a real problem.
> 
>  I think MAD support is in the "ugly" plugins precisely because it has a
>  GPL dep (libmad).  The fluendo mp3 plugin does not "taint" GStreamer.
>  #317129 relates a similar problem.

In summary, Bastian is wrong. LGPLd code can be linked to GPLd code
without problem. It's when you mix in a non-GPL-compatible license as
well (as another module, or program) that the problems arise. I can't
imagine Debian ever including such a module (since I can't imagine
anyone writing a free-but-not-GPL-compatible module), so this isn't a
problem for us.

It only affects people that want to ship GStreamer with both MP3 support
and some proprietary modules like RA or WMA or something, or link it
against their GPL-incompatible program.

Debian ships a number of programs that use GStreamer and are licensed
under the GPL, without a GStreamer module exception. These present the
same "problem" (really, it's just copyleft as intended) as
gstreamer-mad, so gst-fluendo-mp3 doesn't get us anywhere practical,
from a license perspective.

> >  1) -ugly get past NEW, we get MAD, users get MP3 decoding, situation
> > stays as its been for years, or 
> >  2) We take the patent issue seriously, and drop all MP3 support.
> > (Speaking with my hat as a DD, and as upstream maintainer of an MP3
> > player that uses GStreamer and doesn't want to deal with two sets of MP3
> > decoding bugs.)
> 
>  I agree in general with your opinion, but I want to emphasize that I'm
>  not preparing fluendo-mp3 _because_ ugly is still in NEW.  It's only
>  the more open license of fluendo-mp3 which motivated this decision.

Okay. I wondered if this was connected to the long time -ugly has spent
in NEW; I'm very glad to hear it's not.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>



Bug#292105: ITP: libmusepack -- Musepack (MPC) format decoder library

2005-01-24 Thread Joe Wreschnig
Package: wnpp
Severity: wishlist

* Package name: libmusepack
  Version : 1.1
  Upstream Author : The Musepack Development Team
* URL : http://www.musepack.net
* License : 3-clause BSD
  Description : Musepack (MPC) format decoder library

libmusepack allows you to decode files in the Musepack audio format,
which usually use the 'mpc' extension. MPC is a lossy compression format
like MP3 or Ogg Vorbis. It is based on the MPEG-1 Layer-2 / MP2 algorithms,
but has vastly improved.


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



Bug#292106: ITP: pyflac -- Free Lossless Audio Codec [Python bindings]

2005-01-24 Thread Joe Wreschnig
Package: wnpp
Severity: wishlist

* Package name: pyflac
  Version : 0.0.2
  Upstream Author : David Collett
* License : GPL
  Description : Free Lossless Audio Codec [Python bindings]

 FLAC stands for Free Lossless Audio Codec. Grossly oversimplified, FLAC is
 similar to Ogg Vorbis, but lossless.

 This package contains Python bindings for libFLAC, allowing programs
 written in Python to read or write FLAC audio data or metadata.

Currently you can get pyflac from my personal SVN repository at
http://svn.sacredchao.net/svn/quodlibet/trunk/pyflac.

David Collett appears to have dropped off the face of the earth since
he released 0.0.1 and exchanged a few emails with me. If anyone knows
how to get ahold of him, please let me know, I have some patches for it.
(And I'll be taking over upstream if he remains missing).


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



Bug#292107: ITP: pymusepack -- Musepack (MPC) decoder library [Python bindings]

2005-01-24 Thread Joe Wreschnig
Package: wnpp
Severity: wishlist

* Package name: pymusepack
* URL : http://www.sacredchao.net/~piman/software/python.shtml
* License : GNU GPL v2
  Description : Musepack (MPC) decoder library [Python bindings]

 libmusepack allows you to decode files in the Musepack audio format,
 which usually use the 'mpc' extension.

 This package contains Python bindings for libmusepack, allowing
 Python programs to decode MPC files, and read and write APEv2
 metadata tags.

Prior to their initial release, these bindings can be gotten at
http://svn.sacredchao.net/svn/quodlibet/trunk/pymusepack.


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



Bug#292109: ITP: pymodplug -- ModPlug mod-like music shared libraries [Python bindings]

2005-01-24 Thread Joe Wreschnig
Package: wnpp
Severity: wishlist

* Package name: pymodplug
  Version : 1.1
  Upstream Author : Joe Wreschnig
* URL : http://sacredchao.net/~piman/software/python.shtml
* License : GNU GPL v2
  Description : ModPlug mod-like music shared libraries [Python bindings]

 libmodplug is a library for decoding MODs and similar tracked formats.
 It features high-quality audio output including noise reduction and
 support for many MOD-like formats.

 This package contains Python bindings for libmodplug, allowing programs
 written in Python to read music in MOD, XM, IT, and other formats.

Whew, and that's the last of them. :)


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



Re: NEW queue and ftp-master approval

2005-01-24 Thread Joe Wreschnig
On Tue, 2005-01-25 at 01:06 -0600, Ron Johnson wrote:
> On Tue, 2005-01-25 at 07:39 +0100, Goswin von Brederlow wrote:
> > Ron Johnson <[EMAIL PROTECTED]> writes:
> > 
> > > On Mon, 2005-01-24 at 22:28 +0100, Goswin von Brederlow wrote:
> > >> Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes:
> > > [snip]
> > >> have to be done for NEW packages, e.g. inform some U.S. government
> > >> agency about the new deb, add an override entry into the db. The only
> > >
> > > Could you flesh that out a little?
> > 
> > Details were a bit scetchy there on irc too. I would rather have an
> > ftp-master say what is actualy going on then repeat speculations.
> 
> Sounds(*) like the paranoid rantings of a W-hater.

Sounds like the nationalistic rantings of someone ignorant of US law.
(But then, Clinton never did anything worth knowing anyway, did he?)

It's not hard to find information about the measures Debian has taken
for crypto export compliance, which do involve sending information a
government mailbox (albeit one that probably goes unread) about our
exports:
http://lwn.net/2002/0328/a/deb-crypto.php3
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Ubuntu and its "appropriation" of Debian maintainers

2005-05-01 Thread Joe Wreschnig
On Sun, 2005-05-01 at 22:38 +0200, Alexander Wirt wrote:
> Hi Matt!
> 
> On Sun, 01 May 2005, Matt Zimmerman wrote:
> 
> > On Sun, May 01, 2005 at 09:36:57PM +0200, Andreas Barth wrote:
> > 
> > > Actually, I don't think that the packages.*-code is part of the problem.
> > > Ubuntu treats the Debian maintainers at many places as "their"
> > > maintainers, e.g. at apt-cache show $package. The packages.*-code just
> > > displays that wrong information.
> > 
> > [Note that this is an entirely different matter from the one mentioned in 
> > the
> > original post]
> > 
> > Every Debian derivative I have seen does this the same way.  There is some
> > inaccuracy in either case, but I think this is the lesser of the evils:
> > 
> > - Changing the maintainer field
> >   - " is taking credit for my work!"
> >   - Requires modification of every source package, even if it is otherwise
> > identical
> If they change anything - this includes branding stuff too - the should 
> change the maintainer field. If the package is identical to the debian one
> it could stay as it is.

Unfortunately this isn't easy to check; I'm listed as the python-gst
maintainer, and I doubt anything in my package has been changed, but I'm
also pretty sure it's compiled against Ubuntu's Python version rather
than Debian's (and since it uses dh_python, nothing in the package is
changed for it to do that).

I'd be happy if it just said "Foo Bar is the Debian maintainer for this
package; there is no Ubuntu maintainer. Foo Bar may not be able to help
you if you are having problems." or something similar. Right now it
indicates that we're Ubuntu maintainers, and that's just wrong.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: ITP: backgrounds-debian-shell -- Photography of shells aligned to form the Debian logo

2005-01-16 Thread Joe Wreschnig
On Sun, 2005-01-16 at 19:31 +0100, GÃrkan SengÃn wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: backgrounds-debian-shell
>   Version : 1.0
>   Upstream Author : Jakub Budziszewski <[EMAIL PROTECTED]>
> * URL : http://linuks.mine.nu/jakub/
> * License : Artistic License
>   Description : Photography of shells aligned to form the Debian logo
>  A photography that consists of shells aligned to form the
>  Debian logo.

A package for a single background is a remarkably stupid idea. This
should go in desktop-base.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Status of Unofficial Sarge Release Issues (Updated for July)

2003-07-02 Thread Joe Wreschnig
On Wed, 2003-07-02 at 11:20, Drew Scott Daniels wrote:
> I know text is preferred by many over html, but formatting is easier for
> me in html than in text. If anyone's interested in a text only version,
> let me know.

$ lynx -dump usri.html > usri.txt

Attach/use that next time, with a reference to the HTML if it's actually
that important.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Please remove RFCs from the documentation in Debian packages

2003-07-03 Thread Joe Wreschnig
On Thu, 2003-07-03 at 15:19, Thomas Viehmann wrote:
> Cameron Patrick wrote:
> > On Thu, Jul 03, 2003 at 02:36:48PM -0500, Branden Robinson wrote:
> > | Well, once you folks have come up with a definition of "software", you
> > | be sure and let us know.
> > How about "anything included in Debian"?  That way we won't be in danger
> > of violating the Social Contract #1.
> 
> Oh, cool. How about changing in DFSG to "Anything that can go in main or 
> contrib."

Because that's a circular definition. Saying everything in Debian is
software, is not.

It's also the only reasonable way to define software. Or at least, the
only reasonable way I (or anyone else who has voiced their opinion on
this issue here) have come up with in 3 years, and it's not for a lack
of trying.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Please remove RFCs from the documentation in Debian packages

2003-07-03 Thread Joe Wreschnig
On Thu, 2003-07-03 at 14:53, Cameron Patrick wrote:
> On Thu, Jul 03, 2003 at 02:34:56PM -0500, Branden Robinson wrote:
> 
> | The Debian Social Contract says "Debian Will Remain 100% Free Software"

Re: Please remove RFCs from the documentation in Debian packages

2003-07-04 Thread Joe Wreschnig
On Fri, 2003-07-04 at 11:06, Cameron Patrick wrote:
> On Thu, Jul 03, 2003 at 11:54:17PM -0500, Joe Wreschnig wrote:
> 
> | How do you show it's not software? How does it differ from software?
> | 
> | What if I take the view that Mozilla is an interpreter and anarchism is
> | the program? Please explain how that differs from the Perl interpreter
> | and Perl programs.
> 
> I would argue that while Perl is Turing complete, HTML is not, thus
> anarchism is not software.

So only programs in Turing-complete languages can be considered
software?

What if your program is written in a Turing-complete language (say,
LaTeX), but doesn't require the language to be Turing-complete to run
(like most LaTeX documents)? You could make a non-Turing complete LaTeX
interpreter that would process the document just as well. Does that mean
it's suddenly not software?

What if I made Turing-complete language of which HTML is a subset? I
could call it PHP.

Don't Cc me. I'm on the list.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: why no python, tcl, tk metapackage?

2003-07-23 Thread Joe Wreschnig
On Tue, 2003-07-22 at 20:03, Dan Jacobson wrote:
> I see my sid system has collected various python 2.1 and 2.2 packages, but
> no 2.3 packages.  Couldn't there be a python metapackage that I could
> install to always keep python at its freshest, also saving disk space
> by disposing older versions?

When Debian switches its default Python version to 2.3, the metapackage
'python' will depend on Python 2.3. Likewise, the various python-foo
packages will (if their maintainers are active) depend on python2.3-foo
instead of python2.2-foo, as they do currently.

Conflicting with an old version of Python is a bad idea, because the
migration from x to x+1 does not happen instanteously, and so you may
very reasonably with x and x+1 to be installed together.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Bug#201769: gradm doesn't build on ia64

2003-07-30 Thread Joe Wreschnig
On Tue, 2003-07-29 at 18:20, martin f krafft wrote:
> gradm doesn't support ia64 yet. What are the implications that
> result from this. I don't think we should remove it from the
> distribution, as it is a very important and handy tool...

The usual course of action, then, is to only list the architectures it
builds on, rather than 'any.

> Can we provide ia64 development space for the guys at grsecurity?

http://testdrive.hp.com/ has limited (actually, unlimited, which is the
problem) free IA64 porting/testing facilities.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: CUPS should be the default print service in Debian/Sarge

2003-08-02 Thread Joe Wreschnig
On Fri, 2003-08-01 at 23:31, Marc Wilson wrote:
> On Thu, Jul 31, 2003 at 02:52:04PM +0100, Ross Burton wrote:
> > However, I am biased, as I package the GNOME CUPS packages... :)
> 
> And as a random comment, it's really sad that a printing system would have
> any sort of dependency whatsoever on Gnome (or KDE, for that matter).

Which is why CUPS doesn't.

CUPS is configurable via ordinary text configuration files like most
Unix programs, a web interface (which is what I use), GNOME or KDE
frontends, probably a number of miscelleaneous toolkit frontends, too...

Personally, I'm surprised there's still people with printers who
*haven't* tried CUPS. For the vast majority of situations, it's
incredibly easier to configure, and usually more reliable about output,
than lprng.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: CUPS should be the default print service in Debian/Sarge

2003-08-03 Thread Joe Wreschnig
On Sun, 2003-08-03 at 01:44, Marc Wilson wrote:
> On Sat, Aug 02, 2003 at 02:51:53AM -0500, Joe Wreschnig wrote:
> > For the vast majority of situations, it's incredibly easier to configure,
> > and usually more reliable about output, than lprng.
> 
> Implying that there are circumstances where CUPS will produce valid output,
> and lprng will not?  I'm interested.  Examples, please.

Having not used lprng in over 3 year, I can't come up with any examples
off the top of my head.

I think you're primarily objecting to my characterization of these bugs
as lprng bugs, rather than filter bugs, which is what they probably
actually were. However, from the perspective of J. Random Enduser, it
doesn't matter if the bug is in the filter or the print server; if it
doesn't print (or prints with garbage), it doesn't print.

I'm sure if I had spent many, many more hours configuring filters for
lprng (I used apsfilter for some time with Slackware, and then changed
magicfilter shortly after moving to Debian), I could've gotten the same
quality of output with these that I got with CUPS after about 5 minutes
with its web interface.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Fw: Re: Ruby 1.8 transition plan; debian-ruby

2003-08-05 Thread Joe Wreschnig
On Tue, 2003-08-05 at 12:12, Fumitoshi UKAI wrote:
> Since ruby 1.8.0 was released recently, ruby developers will go to 
> ruby 1.8.x, so that we, ruby maintenance team (akira, tagoh, ukai), 
> are discussing about how to deal with Ruby 1.8 transition and trying to make
> debian ruby policy soon.
> 
> For now, ruby package provides /usr/bin/ruby of ruby 1.6.x, and
> ruby1.8 package provides /usr/bin/ruby1.8 of ruby 1.8.x.  Someone
> want to use /usr/bin/ruby of ruby 1.8.x, so we're considering to use 
> alternatives for /usr/bin/ruby to choice either ruby1.6, ruby1.8 (or any
> other version of ruby in future).

There was a bug about this at some point, which I can no longer find,
where I suggested doing for Ruby what Python does. Which is essentially:
- 'ruby' is a metapackage depending the current default version of Ruby
for Debian.
- 'rubyX.Y' is a specific version of Ruby. 'ruby' depends on one of
these.

- 'libfoo-bar-ruby' is a metapacakge depending on libfoo-bar-rubyX.Y,
where X.Y is the default version of Ruby (the same as the one 'ruby'
depends on).
- 'libfoo-bar-rubyX.Y' is foo-bar for a specific version of Ruby. The
above depends on one of these. (These packages may be unncessary if the
directory tree I outlined below is used, and the package is
version-independent.)

As for module include paths, they're less important since most Ruby
modules query Ruby for the right information at build-time anyway, but
I'd like to see version-independent directories, and also preferrably a
tree under /usr/share, too. Say,

These are arch-independent:
- /usr/share/ruby for Ruby modules that work with any version.
- /usr/share/ruby/X.Y for Ruby modules that depend on version X.Y.

These are arch-dependent:
- /usr/lib/ruby/version/X.Y/#{arch}-#{os} for all arch-dependent
modules. I believe most architecture-dependent modules need to be
recompiled for each version of Ruby anyway, and so a version-independent
architecture-dependent directory makes no sense.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: About NM and Next Release

2003-08-06 Thread Joe Wreschnig
On Wed, 2003-08-06 at 14:32, Steve Lamb wrote:
> Except when your sponsor goes AWOL for 3 weeks after giving them the URL
> to download the packages to paw through and upload.

This is not different than someone in your path-to-Linus being AWOL. It
happens.

It's a problem, but it's a problem every large project and many small
ones have, not just Debian. Claiming that Debian is dying because of it
is absurd.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Usefulness of SSMTP [Was: Should MUA only Recommend mail-transfer-agent?]

2003-08-06 Thread Joe Wreschnig
On Wed, 2003-08-06 at 09:27, Steve Langasek wrote:
> On Wed, Aug 06, 2003 at 06:51:12PM +1000, Brian May wrote:
> > On Wed, Aug 06, 2003 at 09:35:29AM +0200, Matthias Urlichs wrote:
> > > IMHO using any local mailer is a bad idea on a desktop system. You send
> > > off the mail, your MUA says "Sent", you power down or just close the
> > > laptop, and, if your smarthost happens to be a bit slow today, the mail
> > > sits there indefinitely.
> 
> > Unless it is something like SSMTP...
> 
> > SSMTP has no queue and sends E-Mail immediately to a smarthost.
> 
> And is a much better choice than expecting every user to locally
> configure smtp settings in the MUA.  Lack of direct-SMTP support in mutt
> is a good thing.

SSMTP is not acceptable for those of us that use SMTP AUTH+TLS, unless
it supports those (it didn't, last time I looked). In fact, there don't
appear to be any "dumb" MTAs (like ssmtp or nullmailer) that support TLS
and SMTP authentication. This is why I can't use Mutt anymore.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Should this be filed as grave? Gcc-2.95

2003-08-06 Thread Joe Wreschnig
On Wed, 2003-08-06 at 15:48, Jaldhar H. Vyas wrote:
> On Wed, 6 Aug 2003, Matthias Urlichs wrote:
> 
> > You asked for gcc-2.95. You got gcc-2.95. Whatever else you got should be
> > of no consequence whatsoever.
> 
> It's this kind of attitude that drives people to gentoo.

Let them go. IMO it's far better to install more than is necessary, but
always get the desired functionality, than install less than is desired,
and then have to spend 20 hours recompiling for the necessary
functionality.

For most people, disks are cheap. Time isn't.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Usefulness of SSMTP [Was: Should MUA only Recommend mail-transfer-agent?]

2003-08-06 Thread Joe Wreschnig
On Wed, 2003-08-06 at 17:09, Mark Ferlatte wrote:
> ssmtp in unstable supports TLS and certificate based AUTH (so you can
> authenticate on a per machine basis for relay).  It appears to have AUTH
> CRAM-MD5 support, but it's unclear if that's distributable (according to
> comments in the source).  It also has AUTH LOGIN support (on a per user basis,
> via the -au and -ap command line options).

Interesting. I'm running unstable, but I can't find instructions on
enabling TLS anywhere (nor does SSMTP seem to link to any TLS
libraries). I see mention of it in the README (specifically, only a
credit for it), but not the manual page, nor the configuration file, nor
README.Debian. ssmtp.conf has no manual page.

If it is there, it's damned well hidden.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Should this be filed as grave? Gcc-2.95

2003-08-06 Thread Joe Wreschnig
On Wed, 2003-08-06 at 17:01, Steve Lamb wrote:
> On 06 Aug 2003 16:48:18 -0500
> Joe Wreschnig <[EMAIL PROTECTED]> wrote:
> > Let them go. IMO it's far better to install more than is necessary, but
> > always get the desired functionality, than install less than is desired,
> > and then have to spend 20 hours recompiling for the necessary
> > functionality.
> 
> ECUSE me?  Care to explain how this has any relevance at all? 
> gcc-2.95 is going to somehow break without a SYMLINK to 3.3? It's going to
> require a RECOMPILE because a SYMLINK TO A COMPLETELY UNRELATED VERSION ISN'T
> PRESENT!?  

First, calm down.

You found a bug in the kernel build system, which happens to be
triggered by some otherwise innocuous behavior that Debian's GCC package
has had for 2.5 years.

Perhaps the Debian package is installing GCC 3.3 unneededly. This is a
wishlist bug against the GCC package, then. Or perhaps you should've
emailed the GCC maintainer before filing it, asking him if there was a
good reason for this behavior.

At this point, you're blowing up about what is an almost non-issue, with
a trivial fix. It would be nice to get GCC 2.95 to stop depending on GCC
3.3; it might even be possible (I haven't looked at #85135, #85141,
#85154, #85222, #85539, #85570, or #85578, so it may or may not be). But
even if it is, you've blown your chances of this thread ever achieving
anything, I think.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Usefulness of SSMTP [Was: Should MUA only Recommend mail-transfer-agent?]

2003-08-06 Thread Joe Wreschnig
On Wed, 2003-08-06 at 18:04, Mark Ferlatte wrote:
> I'm not sure why ssmtp has TLS disabled by default; perhaps a bug should be
> filed?  It seems like it would provide all of the needed outgoing MTA
> functionality without requiring a daemon.

Looking at the SSMTP bug page, the package seems to be very
unmaintained. :/ Two important bugs, one of which I'd consider critical,
both with patches, and no update for 6 months.

I'm going to test a package with TLS (and probably the other patches in
the BTS); if I don't find anything wrong, I'll file another bug.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: About NM and Next Release

2003-08-06 Thread Joe Wreschnig
On Wed, 2003-08-06 at 20:18, Adam Majer wrote:
> On Wed, Aug 06, 2003 at 04:27:24PM -0500, Joe Wreschnig wrote:
> > On Wed, 2003-08-06 at 14:32, Steve Lamb wrote:
> > > Except when your sponsor goes AWOL for 3 weeks after giving them the 
> > > URL
> > > to download the packages to paw through and upload.
> > 
> > This is not different than someone in your path-to-Linus being AWOL. It
> > happens.
> 
> Don't you just post a [PATCH] to the kenrel-devel mailing list??
> Then Linus applies it or not.

Don't you just file a bug with a patch tag?? Then the maintainer accepts
it or not. This is the way it works now in Debian, too; the subtlties
come in how the maintainer doesn't (or does) apply it.

He might ignore it, or reject it explicitly. He might merge it silently.

Or, equally likely, Linus pays little attention to it - one of the other
main kernel hackers (Alan, Marcelo, Al Viro, whoever) includes it in one
of their large patches, after reviewing it. Linus then applies them
after what's probably a lot less review than he'd give some random patch
alone.

Face it - no free software project is "easy" to join (except apparently
KDE...), and there's a reason for that. It's a process that selects
against bad code and bad maintainers. It's also a process that happens
to have false positives probably more often than it has false negatives.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: [RFC] Debian ruby policy (Re: Fw: Re: Ruby 1.8 transition plan; debian-ruby)

2003-08-20 Thread Joe Wreschnig
On Wed, 2003-08-20 at 12:53, Fumitoshi UKAI wrote:
> Joe Wreschnig <[EMAIL PROTECTED]>
>  libtest-unit-ruby1.8 (<- libtest-unit-ruby)

Actually, I now only maintain Test::Unit for Ruby 1.6. Since it became
included with 1.8, akira yamada maintains that version, and when 1.8 was
packaged I dropped support for 1.7 from my package.

I'll rename the 1.6 package appropriately, though, but I'll wait until
the Ruby/GTK packages are renamed (unless that's going to take a very
long time?)

> Currently, ruby upstream doesn't support such version independent module 
> path /usr/share/ruby in $LOAD_PATH. Should we modify ruby 1.8 or later 
> to support this?

I think so, but I'm open to suggestions about it. It does IMO make
packaging modules without C code much simpler. The downside is when a
major incompatibility happens (i.e. code that works correctly on more
than one version is impossible), but I believe this is a rare enough
case to ignore (AFAIK it's never happened).
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: "non-free" software included in contrib

2003-09-02 Thread Joe Wreschnig
On Mon, 2003-09-01 at 23:40, Manoj Srivastava wrote:
> On 31 Aug 2003 17:51:42 +0200, Mathieu Roy <[EMAIL PROTECTED]> said: 
> 
> > But now we're discussing about it and I express my opinion: since
> > these packages in their postinst script install non-free stuff, I
> > think that even if there's no non-free stuff within the packages
> > themselves, the result of the installation of these packages (and
> > not their dependancies!) is to get non-free stuff. And so, it leads
> > me to the conclusion that, whatever the fact that the non-free part
> > is downloaded at the same time than the debian package or not, this
> > package itself contains non-free stuff.
> 
>   This is no different from any package in contrib that actually
>  depends on non-free software. You seem to be implying that contrib is
>  only supposed to be composed of software that may build depend on
>  non-free packages, but may not depend on, or install, non-free
>  packages.

Really? I read it as a request to be honest about the program's
intentions. When you install a program from contrib that depends on
something in non-free, you're clearly installing something in non-free
(vrms will recognize it, dselect will say that it's non-free, and so
on), in addition to the thing in contrib. Also, the thing in contrib is
suppossedly a useful piece of almost-free software, that happens to use
a non-free toolkit, compression library, or whatever. You may be
installing it to rewrite that part, for example.

The installer packages aren't recognized as non-free by vrms or dselect,
and I would question the copyrightability of the installer (is a
wget/dpkg line copyrightable? I doubt it). Furthermore, the installer is
totally useless for doing anything but writing another non-free
installer, since it's so trivial. There is no reason to install the
installer unless you plan to install and use the non-free software.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: python's gettext.gettext broken, use gettext.lgettext

2005-08-07 Thread Joe Wreschnig
On Mon, 2005-08-08 at 07:45 +0900, Junichi Uekawa wrote:
> Hi,
> 
> While I was hacking at debconf, I noticed that 
> python's gettext function returns strings encoded in the 
> original encoding; which will appear as garbage on 
> the screen.

The best way to do gettext in Python is to do:

gettext.install(textdomain, unicode=True)

Which installs ugettext as '_' function into the __builtin__ namespace.
That makes _ return Python 'unicode' objects, which is what programs
should be using internally anyway.

This is harder if you're trying to localize a module since then you
don't want to screw with __builtin__; you should use a local _
assignment instead (http://www.python.org/doc/current/lib/node329.html).
It's basically what you wrote.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: python's gettext.gettext broken, use gettext.lgettext

2005-08-08 Thread Joe Wreschnig
On Mon, 2005-08-08 at 21:34 +0900, Junichi Uekawa wrote:
> Hi,
> 
> > > It is also useless for the issues at hand: since linda and
> > > apt-listchanges apparently use local strings, giving them Unicode
> > > strings would break them. So Junichi's change looks right to me.
> > > 
> > Standing up for Linda, I am more than willing to fix her usage of
> > gettext, and I am currently investigating using Joe's suggestion, to
> > see what that gives me. 
> > 
> > Anyway, in Python, unicode string objects behave the same as normal
> > string objects, so to my mind, the breakage should be minimal.
> 
> What's broken about linda currently, and what following Joe's 
> suggestion will still break linda is that linda doesn't 
> follow the current CODESET.
> 
> You'd expect iso-8859-1 output on stdout when the locale says so, and 
> utf-8 output on stdout when the locale says so.
> 
> 'ugettext' is a python's invention of gettext which only 
> returns UTF-8; which you will have to call like:

No, it doesn't return UTF-8, it returns unicode objects. They're
automatically recoded when you try to print them (based on the same
function lgettext uses, locale.getpreferredencoding()). As Steve said,
unicode objects are basically like str objects, so code changes should
be minimal. I'll take a look at Linda/Lintian soon to see what needs to
be done, but I suspect it'll be trivial.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Results of the meeting in Helsinki about the Vancouver proposal

2005-08-21 Thread Joe Wreschnig
On Sun, 2005-08-21 at 19:28 +0200, Jonas Smedegaard wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 21-08-2005 03:58, Wouter Verhelst wrote:
> 
> > We also came to the conclusion that some of the requirements proposed in
> > Vancouver would make sense as initial requirements -- requirements that
> > a port would need to fulfill in order to be allowed on the mirror
> > network -- but not necessarily as an 'overall' requirement -- a
> > requirement that a port will always need to fulfill if it wants to be
> > part of a stable release, even if it's already on the mirror network.
> > Those would look like this:
> [snip]
> > Overall:
> [snip]
> > - binaries must have been built and signed by official Debian
> >   Developers
> 
> Currently, sponsored packages are only signed, not built, by official
> Debian Developers.
> 
> 
> Is that intended to change, or is it a typo in the proposal?

I have always rebuilt (with pbuilder) packages I sponsor before
uploading them. This has accidentally broken a sponsored package once
due to a misconfiguration, but it's also caught missing build-deps,
builds against testing, etc, a dozen times.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: downgrading optimization for m68k [was: Bug#328453: pbzip2_0.9.4-1(m68k/unstable/zeus): FTBFS on m68k]

2005-09-15 Thread Joe Wreschnig
On Thu, 2005-09-15 at 19:47 -0700, Steve Langasek wrote:
> On Thu, Sep 15, 2005 at 07:15:16PM -0700, tony mancill wrote:
> > Stephen R Marenka wrote:
> > > On Fri, Sep 16, 2005 at 10:40:50AM +1000, Anibal Monsalve Salazar wrote:
> 
> > >>>to bug #317475 on gcc-4.0. As a workaround, you might try compiling with
> > >>>less optimization or gcc-3.3/gcc-3.4.
> 
> > >>+ifneq (,$(findstring m68k,$(DEB_HOST_ARCH)))
> > >>+ CFLAGS = -Wall -O0
> > >>+endif
> 
> > > For the record, -O2 seems to work fine. The segfaults only seem to 
> > > apply to -O3 and better (at least in my experience).
> 
> > This seems to affect one of the packages I sponsor as well:
> 
> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325557
> 
> > If gcc-4.0 is going to puke on lots of packages that use -O3, doesn't it
> > make more sense to upload a patched gcc-4.0 for m68k that silently
> > changes the optimization level back to 2 untile the problem with the
> > compiler can be fixed rather than upload and recompile a large number of
> > packages for every architecture?
> 
> If you have a patch that fixes the ICEs on m68k, by all means please forward
> it to the BTS.
> 
> But a larger question is, why are so many packages being built entirely with
> -O3 when policy recommends -O2?  Policy does say it's ok to use other
> compiler flags if appropriate, but I'd be surprised if all of these packages
> have been benchmarked to confirm that -O3 actually gives measurable
> performance benefits.

I don't know if it gives measurable benefits, but all Python extensions
use -O3 by default (from /usr/lib/python2.3/config/Makefile). Personally
I think it's dumb, but maybe the Python maintainers know better? This is
what triggered the bug in python-flac for me. Overriding distutils isn't
something I've figured out yet (doing so is a task for the weekend).
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Removing and replacing a binary package with a new source package?

2005-10-08 Thread Joe Wreschnig
I'm planning to remove ifp-line from the archive now that libifp (and
its ifp-line-equivalent) is mature and tested. Right now, the ifp-line
source package generates an ifp-line binary package, and the libifp
source package generates an ifp-line-libifp package (that Provides:
ifp-line).

What's the best way to do this to avoid confusing the archive scripts
and/or bothering ftp-masters? The easiest thing to do would be file an
RM bug for ifp-line and just have libifp generate an ifp-line package
(which Provides: ifp-line-libifp). Is this going to cause any problems?
Do I need to wait for ifp-line to be removed before uploading the new
libifp?
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: nethack popularity contest - number_pad?

2003-10-17 Thread Joe Wreschnig
On Thu, 2003-10-16 at 20:30, Joshua Kwan wrote:
> Searching for a general consensus here...
> 
> These days Debian's nethack packages contain default nethackrcs which
> enable number_pad style controls (instead of hjkl keys) by default, due
> to a bug filed on the packages a long time ago. Of course, there are some
> who like it and some who don't. It's too trivial to ask a debconf question
> about it upon install so it boils down to a popularity contest.
> 
> Which is better? I like the default keys because you learn how to use
> nvi very efficiently knowing the hjkl-style keys :) I'm searching for as
> many opinions as possible so please speak up!

Lots of modern laptop (and "compact") keyboards lack number pads; the
only way to play NetHack on my laptop is hjkl.

Honestly, hjkl rather than a number pad is one of the least confusing
NetHack parts of NetHack's UI to a new player. I'd prefer it was hjkl by
default.

(And, I'm an Emacs user, at that.)
-- 
Joe Wreschnig <[EMAIL PROTECTED]>




Re: Why you are wrong [Was: On linux kernel packaging issue]

2003-11-10 Thread Joe Wreschnig
On Mon, 2003-11-10 at 15:46, Glenn McGrath wrote:
> A program that is CPU bound will benefit from compiler optimisations.

A program that is CPU-bound *and* can be encoded more efficiently will
benefit from compiler optimizations. Some CPU bound things just aren't
going to be helped much by vectorization, instruction reordering, etc. I
mean, integer multiply is integer multiply.

> I am not going to individually check every debian package just to give
> you "evidence" and some sort of blanket statment covering all released
> packages at a particualr instant in time.

You don't need to check every Debian package; like you said yourself,
nothing that isn't CPU-bound is going to get helped at all. That cuts
out a whole lot of programs. Especially since this discussion involves
the Linux kernel, you only need to make your point for one program --
the Linux kernel.

> You comments on compiler bugs are irrelevent, it is not debians role to
> try and predict future compiler bugs, just to work around previous ones.

This sounds like the talk of someone who never got bit by a compiler
bug... I had a hell of a time when a number of Gentoo users compiled
broken glibc at one point (some combination of -O3 and i686); the only
thing that consistently failed on their systems was a piece of software
I wrote (and the minimal test cases I put together after being
completely confused for a few weeks).

Debugging compiler problems is *not fun*. They are incredibly difficult
to trace (pydance crashed generating arrow events, due to problems with
Python's floating point processing, due to problems with glibc that only
occurred on a handful of systems -- how quickly could you have figured
that out?) from the perspective of an application developer. They can be
incredibly difficult to fix from the perspective of a compiler
developer.

As for trying to predict future bugs, Debian does this all the time.
That's why we have things like the testing distribution. We know that
essentially all software has mistakes; we should try and mitigate the
damage from those mistakes as much as possible.

> Other than exposing bugs (which is a good thing) compiler optimisations
> do no harm.

Unless it rearranges the instructions so that they run slower through
common pipelines, e.g. optimizing for i586 seems to do this on Athlons
and P4s. Optimizations happen in both new instructions *and* new
instruction ordering; the former is usually upwards-compatible, but the
latter is not.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Why you are wrong [Was: On linux kernel packaging issue]

2003-11-10 Thread Joe Wreschnig
On Mon, 2003-11-10 at 16:27, Adam Heath wrote:
> On Mon, 10 Nov 2003, Joe Wreschnig wrote:
> 
> > A program that is CPU-bound *and* can be encoded more efficiently will
> > benefit from compiler optimizations. Some CPU bound things just aren't
> > going to be helped much by vectorization, instruction reordering, etc. I
> > mean, integer multiply is integer multiply.
> 
> But if the target cpu supports pipelining, and has multiple multiplication
> units(which means it can do them in parallel), or can do a 128bit multiple, or
> 1 64 bit multiple, at once, then it's more efficient to do a partial loop
> unroll, and thereby have faster code, because of more efficient parallization.
> 
> (sorry, read Dr. Dobbs last week).

I knew someone would chime in with this. :) AIUI this is only possible
when there is no data dependency issue (i.e. multiply no. n+1 does not
depend on no. n), otherwise you still have to serialize them.

This is also a good example where optimizing for one chip might slow
another one; say you've got 2 multiplication units on chip A, but only 1
on chip B. You unroll the loop partially when compiling. On A, this
helps, because you can do both multiplies at once. On B, this may slow
it down because of greater icache usage from the unrolled loop, or
because B could be doing (e.g.) an add and a multiply but not two
multiplies.

Of course, I'm far from a compiler and chip design expert (or even
novice); this is what I remember from my classes last year. :) But it
shows how complicated optimizing compilers can get, and why you can't
say any optimization is always good/safe/faster/etc. The only truly safe
way to tell is extensive, controlled benchmarking.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: possible compromise for ITP: linux?

2003-11-10 Thread Joe Wreschnig
On Mon, 2003-11-10 at 19:31, Adam Heath wrote:
> On Tue, 11 Nov 2003, Santiago Vila wrote:
> 
> > If Robert is such an incompetent developer as some people say and the
> > package does not build on the 11 different architectures, then the
> > package will not propagate to testing and the world will be safe from
> > the disaster.
> 
> You misunderstand how testing works.
> 
> If a *new* package doesn't build on some arch, it won't be held up from
> testing because of it.
> 
> It's only when an *existing* package that *previously* built on some arch, and
> now it doesn't, that testing will ignore it.

Given that we know Linux does in fact compile and run on all those
architectures (by virtue of the fact we have them in the first place), I
think it would be fair to insist that Robert's package do the same
before it propagates to testing. He's stated numerous times that the
porting is just packaging work and that he's capable of doing it.

I am not sure of the best technical way to make this happen, though.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


ITP: pyxine -- interface to the xine media player for Python

2003-11-11 Thread Joe Wreschnig
(Because I forgot the X-Debbugs-Cc...)

Package: wnpp
Severity: wishlist

* Package name: pyxine
  Version : 0.1alpha2
  Upstream Author : Geoffrey T. Dairiki <[EMAIL PROTECTED]>
* URL or Web page : http://pyxine.sourceforge.net
* License : GNU GPL v2 or later
  Description : interface to the xine media player for Python

 Pyxine is a Python package which provides Python bindings for libxine,
 the backend of the xine media player. Using Pyxine, it is possible to
 write simple (or complex) user-interfaces to xine. This makes it much
 easier for one to write custom xine UIs.

Sample i386 packages along with source are available at
http://people.debian.org/~piman/pyxine. Python 2.2 and 2.3 are
supported; it didn't compile for Python 2.1, and that's old enough that
I don't care enough about it. Four of the tests are failing, which I
have asked on the upstream mailing list about. It does, however, seem to
work fine despite that.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


Re: Patent problems still exist [Was: Bug#158631: ITP: mp32ogg -- Converts mp3 file to Ogg Vorbis]

2002-08-28 Thread Joe Wreschnig
Regardless of the quality issues, the audio->mp3->ogg encoding process
that this does still includes the mp3 process, which is patented. This
means, since Ogg is deterministic, as is MP3, it's probably very easy
for someone (say, Thomson) to prove a given Ogg was once an MP3. Once
they can prove that, they can still demand royalties for distribution
(and the distribution royalties are worse than the decoder ones).

So, basically, this script makes your files sound worse, and just as
costly as before. Reencoding things from scratch is the only way to
avoid the patent problems.

(Those of you who have too much MP3 music - too bad. You clung to a
closed standard, and Ogg's been out for a long time.)
-- 
 - Joe Wreschnig <[EMAIL PROTECTED]>  -  http://www.sacredchao.net
  "What I did was justified because I had a policy of my own... It's
   okay to be different, to not conform to society."
   -- Chen Kenichi, Iron Chef Chinese


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


Re: Uplink release with Debian

2002-04-03 Thread Joe Wreschnig
Mark,

I've had a third party Uplink Debian package available -
http://www.sacredchao.net/software/dists/unstable/main/binary-i386/games/uplink_2_i386.deb.
The package itself is just an installer, but it can install the demo, or
off the Uplink CD, and patch an installed copy. I emailed Chris Delay
about it a while ago, and posted it to the forums, but it never got
linked off the download page or "Other Files" section.

No matter what you do, Debian isn't going to include Uplink, because
it's not DFSG-free software ("open source"). On the other hand, Cc:ing
-devel in case one of the official developers wants to hammer my work
into something suitable for contrib (a non-official part of Debian that
many users of Debian get packages from).
-- 
 - Joe Wreschnig <[EMAIL PROTECTED]>  -  http://www.sacredchao.net
  "What I did was justified because I had a policy of my own... It's
   okay to be different, to not conform to society."
   -- Chen Kenichi, Iron Chef Chinese


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


Re: O: gnu-standards -- GNU coding standards

2002-04-07 Thread Joe Wreschnig
On Sun, 2002-04-07 at 06:14, Federico Di Gregorio wrote:
> people, i just want to remember you that DFSG stands for debian free
> SOFTWARE guidelines. documentation is *not* software

Unfortunately this is becoming less true. CSS contains statements for
content generation and counting variables. Is this a program? I'm not
sure, but it's definitely not just a document anymore. XSLT can be
included as "documentation" (and probably is in a lot of places, in or
outside of Debian), and XSLT is Turing-complete. Where does the line get
drawn? Is it possible to draw one?

IMO, an FDL-licensed document with invariant sections is non-free. As a
user of Debian, I'd like to know that they're not installed on my system
if I'm only using packages from main.
-- 
 - Joe Wreschnig <[EMAIL PROTECTED]>  -  http://www.sacredchao.net
  "What I did was justified because I had a policy of my own... It's
   okay to be different, to not conform to society."
   -- Chen Kenichi, Iron Chef Chinese


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


Re: The GNU FDL is a free license! (Was: Re: O: gnu-standards --GNU coding standards)

2002-04-07 Thread Joe Wreschnig
On Sun, 2002-04-07 at 14:29, Jeroen Dekkers wrote:
> > Unfortunately this is becoming less true. CSS contains statements for
> > content generation and counting variables. Is this a program? I'm not
> > sure, but it's definitely not just a document anymore. XSLT can be
> > included as "documentation" (and probably is in a lot of places, in or
> > outside of Debian), and XSLT is Turing-complete. Where does the line get
> > drawn? Is it possible to draw one?
> 
> It's possible to draw a line. The GNU FDL clearly describes what a
> "Transparant copy" is for example.

Whether or not it describes what a transparent copy is is irrelevant. In
fact, XML and HTML (and I would imagine therefore CSS and XSLT) are
explicitly listed as transparent formats. I'm not going to argue that.
The problems, although they're transparent, they're programs as well as
documents. I'm sure there's typesetting systems (I only have a passing
familiarity with LaTeX) that are Turing-complete too. What is a
document, and what is a program? How can Debian even begin to
distinguish what makes free documentation different from free software
when we can't distinguish whether a particular piece of data is software
or documentation in the first place?

...

> The FDL is not DFSG-compliant, but that doesn't make it non-free.

I agree. I'm sure someone could show me a non DFSG compliant license I
consider free. But that wasn't what I said. I said I consider a document
with invariant sections non-free, which is my own personal judgement,
and not the FSF's or DFSG's. It just happens that, right now, the DFSG
agrees with my point of view.

-- 
 - Joe Wreschnig <[EMAIL PROTECTED]>  -  http://www.sacredchao.net
  "What I did was justified because I had a policy of my own... It's
   okay to be different, to not conform to society."
   -- Chen Kenichi, Iron Chef Chinese


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


Re: O: gnu-standards -- GNU coding standards

2002-04-07 Thread Joe Wreschnig
On Sun, 2002-04-07 at 16:08, Federico Di Gregorio wrote:
> documentation != document. XSLT is cleary a program and s stylesheet
> should go under a code license. but a manual about programming in XSLT
> is definitely documentation and should be treated in a different way.

What about inline stylesheets? What about XSLFOs in an XML document?

> > IMO, an FDL-licensed document with invariant sections is non-free. As a
> > user of Debian, I'd like to know that they're not installed on my system
> > if I'm only using packages from main.
> 
> IYO. IMHO they *are* free. i explain why: if i write a 300 pages book
> about something and 2 pages about my motivations, greetings to people
> that helped me, etc. i want you to fix the 300 pages of technical stuff
> but i don't see why you should the 'feelings' i put in that 2 pages.
> you're *free* to adapt the document to your liking and even add some
> comments (invariant) criticizing my own, but litterature (even technical
> one) is much different from code.

I agree. The needs of nontechnical writing are not the same as the needs
of technical writing. However, say I want to take a 10 page chapter out
of your book and, e.g., strip it down into a 4 page quick reference
guide. The FDL says I have to preserve your 2 pages of greetings and
thanks. I believe invariant sections (in the general sense) are a good
idea, and necessary for nontechnical writing. However, I believe
Invariant Sections (as in the FDL) impose restrictions that are
non-free.

-- 
 - Joe Wreschnig <[EMAIL PROTECTED]>  -  http://www.sacredchao.net
  "What I did was justified because I had a policy of my own... It's
   okay to be different, to not conform to society."
   -- Chen Kenichi, Iron Chef Chinese


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


Re: O: gnu-standards -- GNU coding standards

2002-04-07 Thread Joe Wreschnig
On Sun, 2002-04-07 at 20:29, [EMAIL PROTECTED] wrote:
> Whatcha mean "becoming"?  Lispers have been blurring the line between
> data and code for the last half-century.

Speaking as a budding LISPer (working my way through "On Lisp" while my
classes ruin my brain with Java), I'm well aware of this. But aside from
DSSSL, it never became very popular with software documentation writers,
who preferred troff, HTML, TeX, etc, and either the capabilities didn't
exist, or they weren't used. Count the number of DSSSL stylesheets in
Debian, and then the number of XML documents. Or the number of
LISP-generated documents versus the number of static documents.

I was actually wondering when I wrote my first message if any package in
Debian was using LISP for document creation, but I couldn't think of any
offhand. Thanks. :)
-- 
 - Joe Wreschnig <[EMAIL PROTECTED]>  -  http://www.sacredchao.net
  "What I did was justified because I had a policy of my own... It's
   okay to be different, to not conform to society."
   -- Chen Kenichi, Iron Chef Chinese


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