Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
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
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
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
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
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
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
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+
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
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
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
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.
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)
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
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
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
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?
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?
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?
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?
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?
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?
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?
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
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
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
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
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
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
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
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]
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]
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]
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
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
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
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)
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
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
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
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?
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
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
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
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
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
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?]
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
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?]
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
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?]
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
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)
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
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
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
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
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]
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?
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?
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]
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]
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?
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
(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]
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
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
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)
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
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
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