Bug#931290: general: Asrock A300 Deskmini AMD Athlon 200GE ends in black screen Monitor has no Signal
Package: general Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** After normal installation of Debian Buster (Testing) with Default desktop the grub screen comes up and the system boots. When it normally switches to graphics mode it shows only a blinking cursor. After installing firmware-linux and rebooting the system does not show the blinking server, but a black screen and the monitor shows "No signal". Tested with 3 monitors. Afterwards reinstalled without "Default desktop". Now the system started ok and ended in the login. After installing firmware-linux unfortunately the system did not show the login after booting, but ended once again in a black screen (no Monitor signal). With nomodeset in grub I could start, but had to press "Ctrl + alt + F2" to go in the login as the system stopped after initializing the network card. So graphical interface is not possible with this hardware configuration and Debian 10 Buster. Normally Kernel 4.19... should be good enough for Vega 3 graphics. Live system (LXDE) fails as well with blinking cursor. "Lubuntu 19.04" does the job, but I do not like it and would appreciate if I could stay with Debian. -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#997916: general: bullseye, (sometimes) keyboard freezes after suspend.
Package: general Severity: normal X-Debbugs-Cc: bullk...@protonmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** I've had this issue with this version of Debian 11 and previous as well. It's doesnt always happen, most times I suspend the system and when resume, keyboard works fine, and sometimes it freezes when resume from suspend. Haven't found any solution online yet, I tried removing xscreensaver and xss-lock but issue remains.
Re: Release-critical Bugreport for October 22, 2004
On Fri, Oct 22, 2004 at 06:30:02AM -0700, BugScan reporter wrote: > Bug stamp-out list for Oct 22 06:02 (CST) > > Total number of release-critical bugs: 726 ... > Number that are being ignored: 45 > Number on packages not in testing: 420 > Number concerning the next release (excluding ignored and not-in-testing): 150 For people who care about getting sarge out, it's not useful to put out a report listing 726 bugs, only 150 of which matter, in a form that makes it rather difficult to cleanly extract only the 150 that matter. How about putting out a regular version, every week or so until release, listing only the sarge-affecting bugs? It will be about 1/5 the size of the message I am replying to.
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: I am still on the keyring. With my old key.
"Chip Salzenberg" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Who does a developer have to fuck around here to get his key deleted? I'm not sure your resignation was valid. Most important debian mechanisms require a signature from a key in the keyring. It is hard for anybody to verify that you really are the developer named "chip salzenberg" without having the relevent post signed. If nothing else the resignation shuld have been signed by the new key. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I am still on the keyring. With my old key.
"Chip Salzenberg" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Who does a developer have to fuck around here to get his key deleted? -- Chip Salzenberg <[EMAIL PROTECTED]> Wait. Ignore my previous post. I had forgotten that the resignation post was indeed signed. It might however be the case that your key will not be removed until the new key makes it into the keyring. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Uploading amd64 packages
Jérôme Marant said: Quoting Joerg Jaspert <[EMAIL PROTECTED]>: Jérôme Marant schrieb: > Is it currently possible to upload amd64 packages to ftp-master? No. Well. Yes. Of course you can upload. They just get rejected. :) Not good. What is missing to get this fixed? Well There are two mirror changes. I suspect that scc will need to become operational, before amd64 is added to ftp-master. The scc change is a big change and certainly has te potential to break things, including offical mirrors. So this change will likely be delayed as long as possible. Until amd64 is made an official architecture it would be nonsensical to allow dinstall (or is it katie?) to accept packages for amd64. > If not, is there any upload queue dedicated at them? Nope. Well. Yes (again). But only about 5 people are allowed to upload there, plus one script that syncs the source from Debian. So you dont need to upload there. So, I guess I have no choice but building packages in a i386 chroot, right? I would assume that it was fairly ovbious that the binary upload would need to be for an offical arcitecture, which amd64 is not (yet). In fact, it is probably not reccomended to be developing under a system that is not offically a debian system. (Although amd64 is a bit of a special case. I would not reccomend doing development for debian on an ubuntu system for example. Too much possibility of conflict.)
Re: apt PARALLELISM
"Olaf van der Spek" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On 12/5/05, Ivan Adams <[EMAIL PROTECTED]> wrote: Example: (/etc/apt/sources.list) deb http://ftp.en.debian.org/debian main stable contrib non-free deb http://ftp.de.debian.org/debian main stable contrib non-free in this case the stable packages will be ONLY downloaded from first server from the list ... And what is the problem? This person is requesting parallel downloads from multiple servers. So basicly during package download, if there are three full and up-to-date mirrors in sources.list, there should be simulatious downloads of different packages from all three different mirrors. The concept is that in some cases this can noticable improve performance, especially whith sites that bandwidth throtle, or have some other sort of bottleneck. I would say this is a feature request, rather than a bug report of any kind. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt PARALLELISM
"Olaf van der Spek" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On 12/5/05, Joe Smith <[EMAIL PROTECTED]> wrote: "Olaf van der Spek" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On 12/5/05, Ivan Adams <[EMAIL PROTECTED]> wrote: >> Example: (/etc/apt/sources.list) >> deb http://ftp.en.debian.org/debian main stable contrib non-free >> deb http://ftp.de.debian.org/debian main stable contrib non-free >> >> in this case the stable packages will be ONLY downloaded from first >> server >> from the list ... > > And what is the problem? This person is requesting parallel downloads from multiple servers. So basicly during package download, if there are three full and up-to-date mirrors in sources.list, there should be simulatious downloads of different packages from all three different mirrors. The concept is that in some cases this can noticable improve performance, especially whith sites that bandwidth throtle, or have some other sort of bottleneck. Do you mean throttling at the mirror site? Or between the mirror and the end-user? Either. It is possible that a router could be throttling the flow rate to a network owned by annother company. Other possible cases are where a user has connections speeds higher than some of the servers. (for example, some rich user could have multi-T3). I'm not sure it is needed, but I do understand that in some cases such a feature may be usefull. Now it is useless for users where the bottleneck is on their end. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
"Steve Langasek" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Sun, Dec 11, 2005 at 03:46:12PM -0800, Thomas Bushnell BSG wrote: You have failed to detail any particular difficulty that this causes, I'm pretty sure I saw him do this already, by noting that it increases the number of packages that the release and QA teams have to keep track of. It's great that you're concerned about the portability of the package, but there are 500+ open RC bugs known to be relevant to the next release, and 1300+ RC bugs all up that affect packages in unstable. Packages with bugs in the first category add to the release team's workload of downgrading bugs/NMUing/pestering maintainers/removing packages; packages with bugs in the second category add to the QA team's workload of figuring out if maintainers are MIA, whether packages should be removed from the archive, and so on. Bugs in both categories make it harder for would-be bugsquashers to sift through the bug lists to find packages that they can usefully NMU. Steve, I'm not sure i agree with what you are saying here, although i do generally agree with you. Keep-out-of-testing bugs seem to be fairly common, Especially on packages that maintainers belive are not stable enoughto possibly be included in releases.This is often found in convience packages such as the weekly cvs snapshots of emacs, which proably should never be part of a stable release. It sounds to me like what is needed as a tag for bugs that tells QA (you post noted that the release team would ignore RC bugs on packages not in testing) that it can ignore those bugs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please test new sysvinit, sysv-rc, initscripts
"Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] I won't complain, I'll just send a friendly assassin to your house :-) A friendly assasin? Is that the type that comes in, talks with you for a while, and eventually offers you a poisioned beer? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
"Marco d'Itri" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Furthermore, /dev/shm is a mount point with a _very_ specific function. It's a bad idea to start using it for something else. Reality check: packages have been using it for a long time and the world has not fallen yet. Hmm... Lets see: 1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm, or that if it does exist, that it can be be read as a block device, or that if it can, it has a file system on it. 2. Neither does FHS. 3. The Linux 2.6 device list states that as of now, if /dev/shm exists it should have a tmpfs filesystem. But makes no guarentees that it exists, or that it will remain a filesystem So AIUI: 1. It exists only on Linux-based OS's 2. There is no gaurentee that it will continue to be there at all 3. There is no guareteee that it will remain a filesystem in the future even if it is there. 4. There is no gaurentee that it exists at all. Sounds it sounds to me like it is a bad idea to use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
"Michael Vogt" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Fri, Jan 06, 2006 at 01:22:50AM +0100, Petter Reinholdtsen wrote: [Michael Vogt] > Sorry for the delay. I'm preparing a new upload that adds the 2006 > archive key to the default keyring. Sounds good. Will this automatically take care of the key update and make sure no manual intervention is needed to get packages upgraded? I uploaded a new apt that supports multiple signatures on the release file. The policy is that it needs at least one good signature and no bad signatures (but any number number of NO_PUBKEY signatures) to be considered trusted. It will still warn about missing keys but that's only fatal if no good signature was found. The upload also contains the new key in apts default keyring. This dosn't fix the key-upgrade problem yet. I outlined my proposal in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891 Early testing (from incoming) is welcome :) Wait a second. How will people download the new key using apt if apt refuses to download because it does not have the new key? And then what about the future? A stable release will not be upgradable if the key is not downloaded, but the key will not be downloadable. Or am i missing something? This whole thing sounds like a major problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
Re: Getting rid of circular dependencies, stage 3
"Joey Hess" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Joey Hess <[EMAIL PROTECTED]> debconf debconf-english debconf-i18n These are all necessary, and debconf is an essential package which is not subject to the circular dependency postinst ordering problems afaik. Well, I'm not sure if that is an excuse for violating policy. (Actually apt is the one violating policy, but if apt did work as policy states it should these packages [like all other packages with circular dependencies] would be uninstallable, which as debconf is essential, would probably be a critical priority bug.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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]>
Re: returning emeritus developer, no response from [EMAIL PROTECTED]
"Adeodato Simó" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Can we please fast-track this clairvoyant NM? Umm... I belive that is the policy. He needs to have his email read, and then answer a few questions. The process for returning emeritus Developers is intentionaly much easier than normal NM, as they obviously were able to pass once before, so now the only important thing is to check that they still remember. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: February 08, 2006 Will People be all over this ST0CK?
Best stock for Year 2006 - read the story and you will s e e f o r y o u r s e l f. Breaking news alert issue - big news coming. A $1,000 dollar investment could yield a $4,000 dollar profit in just ONE trade if you trade out at the top. The stocks we profile show a significant increase in stock price and sometimes in days, not months or years. This stock will explode. Do not wait until it is too late. Company Name: M-WISE INC Date: Feb 08, 2006 Symbol: M W I S Price: $0.177 1 Week Target: $0.50 - $0.80 Explosive pick for our members. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Provides: scheme-interpreter
"Florian Weimer" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] * Chad Walstrom: I'm trying to package up tex2page and noticed that there is no virtual package for scheme-interpreter. I would like to specify in the "Depends:" that some sort of scheme-interpreter is required instead of having to list each of them individually. Any thoughts on this suggestion? Are Scheme interpreters sufficiently compatible (in particular in their command line conventions) so that this is feasible? How do you find one? There doesn't appear to be a /usr/bin/scheme. http://people.debian.org/~forcer/debian-scheme-policy/debian-scheme-policy.html/ Which may be an unofficial policy mandates certain symlinks managed by alternatives to scheme interpreters based on what they support. The virtual package names have been accepted by consensus (nobody said anything, so they implicitly concurred). Therefore if the script needs R5RS Scheme it should depend on 'scheme-r5rs' which is a virtual package, and the first line of the script should be: "#! /usr/bin/env scheme-r5rs" or should be "#! /usr/bin/scheme-r5rs" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: copyright law vs. license text (Was: Honesty in Debian)
"Stuart Yeates" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] In the USA copyright can be enforced even on laws: http://www.constructionweblinks.com/Resources/Industry_Reports__Newsletters/May_17_2004/supreme.html I'm assuming that the legislation in question included the codes (literally the text of the codes) rather than simply refer them. IMHO that ruling was just simply wrong. Laws by their nature must be freely available and editable. Therefore public domain or something similar must be applied to them. A state government (or even the federal government) cannot just publish a work copyrighted by somebody else without permission. That is copyright infringment. I would argue that the introducer of the bill should have been sued by the holder of the rights to the codes. But The holder waited far too long, and the law was published, and so now it has implicity granted the right to the government to publish the work into the public domain. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Deadline for amendments to the GR
"Manoj Srivastava" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] If you do not know what GR's are currently open (despite mails on -announce about them), asnd do not know how to simply look it up on vote.debian.org, the subject matter is irrelevent to you anyway. manoj While you have a point, here is annother point: Putting an indicator of the GR in question may help people make sense of that mesage while sorting through the archives someday down the road. Not to say that there is a need to go out of ones way for that, but when it is easy to add information that may help people doing that (regardless of the type, content, or context of the message) it is a nice thing to do. Just a reminder that people do sometimes read long-ago postings, not intended to be criticism of any kind. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353381: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system
Sorry to change the topic, but looking at some of the manpages in the "manpages" package, and some of the pages in the "manpages-dev" causes me no notice some pages that look like they probably should be in a different package. ld-linux(8) ld-linux.so(8) These probably belong in libc6 which appears to be the provider of ld-linux.so sync(8) This should be deleted. Coreutils (the provider of the sync utility) provides sync(1) for that utility. tzselect(8) This should be removed. it duplicates tzslect(1) (which i presume is provided by the package providing tzselect) ksoftirqd(9) I'm pretty sure this does not belong in the manpage package. As for manpages-dev, it would seem more logical for the linux syscall manpages to be part of linux, and the library documentation to be a part of the libraries that provide the documented functions. If somebody with more time can check on these and, if they are valid, file bugs, I would appreciate it, as I do not have the time right now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mirror split, amd64 update
"Philip Charles" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] I have built up a fine-grained mirroring script over time which not only selects the architecture but also the version (stable, testing etc) to be mirrored. Unfortunately this script will require ftp/http access to ../debian-all. Is there any reason to restrict access to ../debian-all to rsync? It looks like nobody else responded to your message, so I will. (IANADD) Allowing http or ftp access to ftp.debian.org/debian-all is somewhat dangerous. Anybody blindly mirroring ALL of ftp.debian.org via http or ftp would end up with two copies of the major architectures. However, doing that is a stupid thing anyway, and Debian has no obligation to protect fools who do that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /lib/modules//volatile on tmpfs
"Sergio Callegari" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] I have this directory on an Ubuntu system and it seems to be present on recent Debian systems too... It is on tmpfs. Can anybody tell me what is its purpose (as many other distros don't have it) and when it gets mounted? Thanks! Sergio I'm betting that it is caused by a bug somewhere. Something is presumably tring to create a tmpfs on /etc/svc/volatile, but is accidentally doing it in that directory instead. What is probably happing is a script that thinks it is executing in /etc/svc is not, or is having its cwd changed unexpectedly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd and experimental
"MJ Ray" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] MFT is broken by design. No-one should expect to remote control other people's mail clients. All one can do is ask and if you want to ask in the headers, fine, but don't go flaming when it gets lost in the noise. All of From, Reply-To and List-Post seem more useful to me than MFT's wrongheaded confusion of Reply-To and Followup-To. Actually mailing lists are broken by design. Email was designed wth private communication in mind. Mailing lists were added to that design but have always had problems. Newsgroups are what most mailing lists should be. They have historically been threaded and most UA's do this right, While some mail UA's do things like omit message-id or reply-to or references. Also newsgroups make it much easier for a new subscriber to reply to messages sent from before they subscribed. (I use GMANE for these reasons). Now if mailing lists are to be used, then nobody should be complaining about cc's. If the mailing list checks for people who are cc'ed then there will be no duplicate messages. Otherwise the mailer should be able to deterimine that the two messages are in fact the same message with one copy coming from the list, and therefore display it only once. So whenever somebody complains about CC's it seems to me that the problem is a broken or incorrectly configure mail client on the side a the *reciever*. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Propose exim4 for debian-volatile (Was: exim4_4.50-8sarge1)
sorry, but i disagree with you on that. For me volatile is handling packages with volatile data, not for handling packages the stable release manager denys to take into a stable release. I've not followed this bug but AIUI SRM has approved the package for the next point release. If the bug is important enough to make it easy for uers of current sarge to upgrade then the proper venue is security, not volitile. If it is not important enough for the security repository then users will just have to wait. Although if I have misunderstood the issue than the above may not apply. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: acceptance of morse-2.1 in unstable
"Jeroen van Wolffelaar" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Sun, Mar 05, 2006 at 07:42:12PM +0100, Joop PG4I wrote: I have uploaded morse-2.1 about 2 weeks ago. Nothing heard if it will get accepted or not. Wondering what is going on Is ftp-master overloaded? NEW queue is actually a heap, and your package simply didn't reach the top yet. Please hang on . A heap http://en.wikipedia.org/wiki/Heap_%28data_structure%29 ? I would have assumed a like a queue, just slightly modified as to allow a package to be skipped temporarally. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New packages.debian.org
"Henrique de Moraes Holschuh" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Mon, 06 Mar 2006, Martin Schulze wrote: Wolfgang Jeltsch wrote: > Am Montag, 6. März 2006 18:29 schrieb Martin Schulze: > > The Debian project happily announces the re-availability of the > > packages.debian.org service on a new machine. The system has been > > donated by Schlund + Parner where it is hosted as well. It is a > > DualCore Opteron and only runs this service for Debian users and > > developers. > > What does it mean that the machine runs this service only for Debian > users and > developers? How can the machine make sure that the person which > accesses the > machine is either a user or a developer of Debian? It checks the User-Agent string. And now, the important question: why are we doing this? That was sarcasm. " It [...] only runs this service for Debian users and developers." should have been something like: "This is the only debian user/developer service running on this machine" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fonts packages maintenance team (second) proposal
"Rene Engelhard" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Enforcing this policy to existing font packages is not in the top priority of the team. What is a policy useful for when most packages are not following it? I think if there's a sane policy people should have to migrate to it; otherwise you don't need to write a policy for that... Well they said that it was not the top priority, but did not deny that it would be a goal. The Policy could be written and time given for people to adapt, then it could be proposed as an offical sub-policy which would make the other packages RC-buggy AIUI. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: No insulting messages?
"Sven Luther" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Yeah, will use that nexty time. I don't know if native speaker realise this, because many non-native speaker seem to have a fluent english, but there are times when the right words just don't come, and you are grasping with finding the right word, and often make un-wise choices. Speaking as a native English speaker, I understand this. We too have this problem, although not as often, and generally not as bad as non-native English speakers. Nevertheless it does exist for us too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Config file management utility
Has much discussion been had about a possible configuration file management script for the package config scripts to use? For example, I installed cron on a Debian box, and then installed mgetty. Mgetty placed the following at the end of my /etc/crontab: #-- mgetty begin 20,40 * * * * root faxrunq #-- mgetty end Then, when I updated cron, it asked if I wanted to replace my /etc/crontab. I'm assuming that this would have hosed my mgetty settings, so I was forced to make the changes to /etc/crontab by hand. So, I was thinking... why not have a utility that the scripts would use to make all modifications to config files kinda like what mgetty did with the "#-- mgetty begin" and "#-- mgetty end"? The only difference is that *all* packages (even the package that "owns" a particular config file) would be encouraged to use the utility. In the example, cron would use the utility to make updates to /etc/crontab, as /etc/crontab would ostensibly have "#-- cron begin" and "#-- cron end" statements as well. Of course, the utility would have to have command switches to alter what comment character to use... whether the file could be deleted if it was empty (after removing a section, say).... Has this already been discussed and thrown out? - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Easier configuration idea....
One of the faculty I have to support here is using Caldera's OpenLinux. Although Debian is still my favorite, I am pleased with some of the easy configuration features of OpenLinux. For those of you who are unaware, OpenLinux has a directory under /etc called, I believe, sysconfig. In there are bunches of scripts that are employed by the rc scripts in rc?.d and init.d. For example, I believe the NFS one is located at /etc/sysconfig/network/nfs and its contents might look something like: run_on_boot=y run_as=root Probably a few others. I forget. The nice thing here is how easy it is to turn something on or off. With Debian, to turn something off I usually go into /etc/init.d and rename netstd_nfs to netstd_nfs.off. Kinda ugly. What I find exciting is the potential to have a dselect-like utility to manage the system configuration. If those little configration files contained some verbage about what the package does, like: descrip=Network File System. Allows you to share directories, etc. then you have the makings of a quick little utility that would let you turn options on and off in a menued utility. Again... has this already been discussed and thrown out? I'd be willing to write the config utility if I could get some sort of buy-in that it would actually be embraced by the package maintainers if the utility didn't suck. - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Security audit tool?
I was just poking around on the Debian web site and noticed that there's a list of some known vulnerabilities in some packages. Has anyone discussed making a tool that could ftp a current copy of this list (in a properly formatted form, of course) and using it along with dpkg to determine if a system had any of the packages/versions that are vulnerable? - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Config file management utility
On Wed, 3 Dec 1997, Adam Heath wrote: > How about this. Some one creates a script, that is run from /etc/crontab. > Whenever this script is run, it checks to see if another program is supposed > to be run. If so, it does it, then checks to see when the next script is > supposed to run. It then remodifies /etc/crontab, updating it's entry, so > that it can run the next item. Does anyone understand this? It sounds like something I was going to suggest as a joke. I was going to propose that, in cron.daily, they put in a script that sets up 288 "at" jobs... all 5 minutes apart. However, that's about at the top of the scale of tackiness and inelegance, IMHO. - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Config file management utility
On 3 Dec 1997, Rob Browning wrote: > Joey Hess <[EMAIL PROTECTED]> writes: > > > Another way, that sould comply with policy, were if cron came with a > > update-crontab script, that was responsible for modifying /etc/crontab, > > in a similar fasion to update-inetd. > > I think that this, or something similar, is in the end, the right > solution. > > Ideally, I think this should be handled like the menu package. > /etc/crontab would be augmented to have something like: > > # BEGIN AUTOMATICALLY GENERATED SECTION -- DO NOT EDIT # > > > # END AUTOMATICALLY GENERATED SECTION -- DO NOT EDIT # > > Then each package would just have a file in /usr/lib/cron/auto (or > whatever) which would be used to (re)build the contents of this > section whenever a relevant package was installed. Well, that's pretty much what I was suggesting in the beginning. The only difference is that you wouldn't have one, monolithic section. Rather, you'd have sections placed there by the individual packages. For example: echo "42 6 * * * root run-parts /etc/cron.daily" | \ alter-file /etc/crontab --package=cron causes /etc/crontab to read: # cron BEGIN 42 6 * * * root run-parts /etc/cron.daily # cron END And then you could append to sections, like so: echo "47 6 * * 7 root run-parts /etc/cron.weekly" | \ alter-file /etc/crontab --package=cron --append to give: # cron BEGIN 42 6 * * * root run-parts /etc/cron.daily 47 6 * * 7 root run-parts /etc/cron.weekly # cron END You get the idea. Of course, in real life, you wouldn't do a section a line at a time. You'd pipe the whole snippet in like so: alter-file /etc/crontab --package=cron < /tmp/mysnippet You could remove a section: alter-file /etc/crontab --package=cron --remove You could also specify that, if removal of a section leaves the file empty, then remove the file: alter-file /etc/crontab --package=mgetty --remove --rm-on-empty Also, since not all config files use "#" as the comment, you'd be able to specify alternate comment chars (that the program uses for the BEGIN and END markers): alter-file /etc/someconfig --package=foobar --comment=";" < /etc/snippet Well, you guys get the idea.. I already have something like this written. One of my company's clients uses us as an e-mail forwarding service. So we maintain the forwarding e-mail addresses in an Access database and, periodically, we export it to a text file and feed it into this script I've got which replaces everything between "# BEGIN someclient" and "# END someclient" with the new section. So... it wouldn't be all that difficult to add the other features I've mentioned. The only problem is that it uses Perl. I haven't read the Debian policies so I don't know if Perl (or a stripped down version of it) is one of the things I can assume is on even the most minimal system. If not, I can do the same thing with bash/sed, I s'pose. - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Config file management utility
On Thu, 4 Dec 1997, Joey Hess wrote: > Some things to look out for, though: > > - if the file alter-file is a conffile, there will be problems later when > you upgrade the package containg the conffile. I'm not sure I follow what you're getting at. The way I'm thinking, if a package (say, cron) was going to use this hypothetical tool to manage /etc/crontab, say... then it wouldn't have a crontab in the /etc directory of the .deb file. It would, instead, have a copy of the _snippet_it_wants_to_contribute_to_the_config_file somewhere like /usr/lib/cron/crontab.snippet or something. Then, the actual creation/ateration of /etc/crontab would be done with the tool... invoked from, say, postinst. So, instead of having an /etc/crontab in the .deb archive, postinst would have something like: alter-file /etc/crontab --package=cron < /usr/lib/cron/crontab.snippet The pitfall I'm forseeing (which doesn't seem to me to be the same one you're thinking of), is what happens the first time we upgrade a package that has now switched over to using this new tool? The new tool will be looking for its BEGIN and END markers for that package when there won't be any. I guess there's no crime in having the tool just stomp on the previous version of the file since that's what dpkg would do (but giving the user the 'ol Y,N,I,O,Z choices). > - you have to consider what happens if alter-file is asked to modify a file > that does not yet exist, becuase the package it is in has not been installed > yet. I had assumed that the default behavior would be that the file would be created right then and there. In fact, I'm having enough trouble forseeing a case where you would NOT want this to happen, I'm debating whether to even bother putting in a command-line switch to turn that behavior off. - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#15859: libc6 in stable is horribly broken
On 12 Dec 1997, Rob Browning wrote: > Scott Ellis <[EMAIL PROTECTED]> writes: > > > I HAVEN'T HEARD ANY REASONS WHY UTMP CORRUPTION IS SO EVIL THAT WE > > NEED TO MAKE ANYONE WHO WANTS TO RUN A FEW LIBC6 PROGRAMS ON BO GO > > THROUGH HELL. > > Say you're an ISP running Debian (bo) on a bunch of machines (and > these people do exist). And I'm one of them. :) Here's a thought. Correct me if I'm wrong, but this utmp/libc6/libc5 fiasco is something that applies to all (or almost all) Linux distributions, no? (Or is libc6 a Debianism?) If everybody in the Linux game is migrating to libc6, then what are the other piecewise-upgradable distributions (like RedHat) doing to avoid ugliness like what we're facing? - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian Administration tool
On Mon, 15 Dec 1997, Brian Bassett wrote: > I recently switched to Debian from RedHat 4.2 and the one thing that I > think that Debian could really use is an administration tool. I suggested something similar a couple weeks ago and was informed that this discussion had taken place already. I guess the general consensus was that we (the Debian folks) should wait for the COAS project (http://www.caldera.com/coas/) to come to fruition. COAS looks to be promising. Caldera's outlines for it call for it to have curses (text), X, and web interfaces. Supposely, the front-ends will interact with "configurators" for the various installed packages. The configurators would, ostensibly, be provided with their respective packages. Caldera even went so far as to stipulate that configurators have to display some sort of intelligence (for example, not letting people enter octets higher than 255 in IP addresses). Caldera says that it's all going to e GPL'd. The only question now is, how long it is going to take. - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [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
unsubscribe
unsubscribe -- Joe Bowman [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
lxdoom: help wanted
For some time I've been more or less MIA, but in the past month or so it became impossible for me to do debian work: the processor in my desktop, my only Debian machine (the only other machine I own has a proprietary, non-Linux compatible (Airport Extreme) wifi card) released its magic smoke. For that reason, could interested developers please NMU lxdoom? It has a couple of patches in the bts that should be applied. Thanks very much to any who can help. Joe PS: Not subscribed to -devel, please CC me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cogito no longer conflicts with git or cgvg
The upstream folks are planning to split cogito and git into two separate packages. I requested (and they seemed to agree) that they change the package name from git to something else before then. Hopefully they'll see the light and try to play nice with the rest of the world. Hmm... It looks to me like git is already a seperate package. http://www.kernel.org/pub/software/scm/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why target Debian developers with Windows worms?
What is interesting is that this worm will not send to addresses that contain: berkeley bugs bsd fsf. gnu kernel linux mozilla unix the.bat root sendmail listserv So it looks like the worm tries to avoid open source or free software sites. The worm contains may other no-sends, in categogories like large corporations, internet realated orgs (IANA, IETF, rfc-ed, etc.) and fake addresses. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
"Goswin von Brederlow" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 01, David Nusinow <[EMAIL PROTECTED]> wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. That's a bold statement. -- ciao, Marco Never used either one. I have cdebootstrap do create chroots, dchroot to use them, buildd/sbuild to test compile under true buildd conditions. Why would I want something else? Debootstrap couldn't even handle dependency resolving a while back. I think that by debootstap David was including both normal and cdebootstrap. After all, cdebootstrap is mostly a port of debootstrap, although with some improvments. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Code of Conduct on the Debian mailinglists
"Ben Pfaff" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Magnus Holmgren <[EMAIL PROTECTED]> writes: No problem at all. Especially with gmane.org around. I used to subscribe to dozens of mailing lists, but now I can just browse all of them as newsgroups. I agree, I use Gmane for the same reason. There are many problems with mailing lists. If email was intended to be threaded, a message ID would be manditory. It is actually optional. Email was designed for unidirectional or recipricating (back and forth replying to the last message) messages, not threaded conversation. This is why few UA's can handle threading well, and even the best UA will have problems with some messages. Email was also definately not designed with mailing lists in mind. Multiple recipients, yes. That is why many MUA's have a "reply all" feature. But it was certainly not designed with what we think of as mailing lists in mind. On the other hand, USENET is the oldest Internet service around that is still in relatively common use. It even predates what we know of as the Internet. It is designed for threaded content, and NNTP messages are closely related to rfc822 (and it successors) messages that tools like spamassassin work just fine. Not to mention with newsgroups it is easy to reply to messages sent before you subscribed, which can be a pain with mailing lists. I am not aware of any common complaint about mewsgrousps that cannot be resolved simply by using a private (i.e. not syndicating) server to host the groups. So I really wonder why mailing lists are so common. -- "The road to hell is paved with convenient shortcuts." --Peter da Silva -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
"Sven Luther" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote: On Aug 30, Nathanael Nerode <[EMAIL PROTECTED]> wrote: > Debian must decide whether it wants to ship BLOBs with licensing which > technically does not permit redistribution. At least 53 blobs have > this > problem. Many of them are licensed under the GPL, but without source > code > provided. Since the GPL only grants permission to distribute if you > provide source code, the GPL grants no permission to distribute in > these > cases. Many people disagree with this interpretation. A few very vocal people do. I guess they can be counted on the fingers of both hands or so. I think everybody can agree that it would be clearer if the blobs used a licence that clearly allows distribution without requiring source. In the case of the GPL that is definately not clear. About the main issue: As I see it, there are three possible catagories for drivers using firmware that all drivers should ideally fall into assuming the driver part is free : 1. Module and firmware in free. (The firmware can be compiled into the module, or can be loaded from a file.) 2. Module in free, firmware in nonfree, loaded from file by driver. [One could argue that the modules belong ion contrib, unless the firmware is optional (perhaps allowing access to non-essential features)]. 3. Module in non-free. [Firmware compiled into module, has not yet be seperated into seperate file. This is acceptable, but many of these could be converted to type 2 if somebody puts in the work]. I know we have some modules of type 1. I'm pretty sure we have some modules of type 3. It has not been clear to me if we currently have any modules of type 2. Obviously if the infrastucture is not there, that should be fixed. Then we have DI. AIUI D-I curretly lacks support for Type 2 and Type 3 modules. This can definately be fixed, but doing it for etch could delay release. Besides all of that we have quite a few modules with problematic licences. Generally the licence problem is on the firmware, although some might affect the rest of the driver. Some are type-3 style (firmware hard-coded into module, firmware lacking source.)Many of those could be shipped as type-3 modules if licence clarification can be obtained (or preferable: relicencing). A few are type-2 style, they could be shipped as type-2 if proper clarification can be obtained. The above is a rough summer of the problems as I understand it. Please correct be if I am wrong. So the question I have is how long would etch need to be delayed to add support for non-free firmware to D-I? We could also push back the freeze on the kernel by the same amount and have some people work on obtaining clarification on some of the problematic licences. With the combination of those two we could end up with having very few drivers not ship, and all shipped drivers both free and non-free be usable during installation. While pushing Etch back is a big deal, it almost seems to me that some of the proposed GRs are an even bigger deal, and, as has been pointed out, the GRs would probably only make a difference for a small number of modules, unless we ignore the problematic licencing of most of the remaining drivers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Code of Conduct on the Debian mailinglists
"Wouter Verhelst" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Mon, Aug 07, 2006 at 11:39:51AM +0900, Miles Bader wrote: "Joe Smith" <[EMAIL PROTECTED]> writes: > So I really wonder why mailing lists are so common. It sort of depends on what you're looking for. Some advantages of mailing lists: * E-mail generally has a "wider reach" -- it gets past corporate firewalls, (my company has never allowed external nntp connections), works even on strange systems, etc. Point. Then again, if your corporate sysadmins don't want you reading news, they probably don't want you reading mailinglists, either. * With email, you can use the same MUA you always use, with the features you're used to. People are _used_ to email, know how to configure it. OTOH, many MUA's (including Thunderbird, mutt with some patches, pine, Mozilla Mail, MS Outlook Express, and of course gnus (which is more of a news client than a mail client)) can read news just fine[1], with an interface that is almost the same as the mail interface. Outlook Express, which does not support threading in the mail interface, will suddenly support threading for NNTP, too. Sorry for the very late reply, but wanted to clarify this: OE does support threading for Email, it is simply disabled by default. However overall the threading is more accuracte an reliable for newsgroups. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for virtual package ircd
"Jeremy Stanley" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Thu, Oct 12, 2006 at 09:14:19AM +0200, Mario Iseli wrote: Ok, this is a good argument. I think the oppinion is more or less clear: Some people think it would be a nice idea, BUT it can be also a problem because some people want more than one Ircd on a system. I only wanted to ask you for your oppinion, so thank you all! :-) Maybe what you're looking for is a "Provides: irc-server" in the ircd packages and a "Recommends: irc-server" or "Suggests: irc-server" in the service packages that potentially benefit from (but do not necessarily require) a locally-installed ircd to which to connect? That way when someone installs the services via, say, aptitude or synaptic, an ircd is pulled in automatically (if one is not already installed) or at least mentioned as being suggested, but multiple ircd packages providing irc-server could still be installed on the same system since there is no conflict expressed. That seems fine to me. Arguably, as mentioned in a different post the ftp servers should do the smae thing instead of conflicting with each other. Mail-tansport-agent should also do the same thing, using the alternatives system to handle the multiple 'sendmail' binaries. Conflicts on a virtual package by a package that provides it is generally questionable because often these is no valid technical reason to restrict the user to only one of the providers of that virtual package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE and Gnome panel applets showing percentage of broken packages
"Frans Pop" wrote in message news:[EMAIL PROTECTED] On Tuesday 05 December 2006 22:25, Berke Durak wrote: I will just say that in my opinion, a repository such as stable, testing or unstable should be self-contained. For stable and testing that is true. However, sid is broken by design as it will always receive new versions of packages first and basically packages that depended on it can only be recompiled against the new package (if needed) once it is in. So, sid will always have a short period after some new uploads where it is inconsistent and a transition is being managed. The strength of Debian's package management tools is that you can still update the part of sid that is good even while some packages you have installed are "broken". (Though you need a little bit of understanding of what is happening to use the tools correctly, which is one of the main reason why sid is not recommended for new users.) The data is still useful for new installations (rather than updates) of sid. If many packages are 'broken' by the definition they are using, then it is quite possible that desired programs will not be installable at that time. It may be useful for other things also, depending on the exactly what tests are being run. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help] Versioning of a library
"Andreas Tille" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Hi, I'm the maintainer of libgtkdatabox-0.2.3.0-0. Until now there was no request for an update of the upstream version and I had personal reasons to stay with an outdated version. Now I was asked to package the latest version and the library is probably not important enough to keep different versions and thus I will package version 0.5.2.0 that is the latest version avialable from http://www.eudoxos.de/gtk/gtkdatabox/ . My guess is that there is an ABI change involved and thus I have to rename the package to libgtkdatabox-0.5.2.0-X . My question is: What is the right choice for 'X' if I skipped several upstream versions inbetween? If this is your first upload of that version then X=1. The correct list for these types of questions is debian-mentors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-minimal
"Steve Langasek" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Sat, Apr 29, 2006 at 09:32:52PM -0700, Russ Allbery wrote: Steve Langasek <[EMAIL PROTECTED]> writes: > Seems to me that this should be at least a bug report on alsa-utils. > I'm surprised that there would be a need for a lintian check for it, > but > I guess it's better than letting such bugs go unnoticed. I can add one; it's not a lot of overhead given that lintian already has a framework for checking for bad dependencies. It's basically just another branch in an if statement. What's the precise check? Any package depending on python-minimal should receive an error (or a warning?) Based on Vorlon's message: If (package depends on python-minimal) and (package is not essential) then ERROR. It's pretty definitely a bug, so AIUI should be marked as an error. with roughly the text of Steve's previous message? Short message: "Non-essential package depends on python-minimal." Long Message: Something along the lines of Steve's meassage. Uh... sure :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-minimal
"Steve Langasek" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Sat, Apr 29, 2006 at 09:00:53PM -0700, Thomas Bushnell BSG wrote: The alsa-utils package depends on python-minimal. As a result, I must now have two versions of python installed. That's a bug. alsa-utils should depend on "python | python-minimal", or perhaps the python packages should Provide python-minimal. Does this seem right? Er... alsa-utils should be depending on python, *not* on python-minimal at all. The previous discussion of this package was that python-minimal exists only for the possibility of use as an Essential: yes package, should never be installed without python, and should not be used as a dependency by other packages. To clarify, AIUI Python-minimal should never be installed without python, unless install of only python-minimal is explicitly requested by the user. This is to avoid having to include full python on an embeded Debian, while minimizing cases where a user is surprised by missing python libraries. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compiling packages for the standard distribution with -Os instead of -O2
"Rogério Brito" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Hi there. I think that this may be interesting to anybody that has to work with computers that are not the latest/more recent as most people in richer countries seem to have. It seems to be that a good amount of people upgrade their computers in a regular basis and, then, don't notice how things can get slower in "weaker" computers. Those of us that live in a country where the already installed base of computers is not recent have to live with software that is ever growing in terms of both RAM and CPU cycles and this leaves less computing power for the applications needed to run. One way to mitigate the memory consumption is to, among other things, compile packages with optimization of GCC set to -Os, instead of -O2, which seems to work at least for some programs (the Linux kernel, mozilla-firefox and my own home-grown programs). Wait a second. Optimizing for size should decrease speed. That is the whole idea of size/speed optimization tradeoffs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Policy version
"Frank Küster" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Hendrik Sattler <[EMAIL PROTECTED]> wrote: However, version 3.7.2.0 is neither in unstable nor at http://www.debian.org/doc/debian-policy/ Both only have version 3.7.1.0. How comes that the PTS has a newer version than all the other sources? http://incoming.debian.org/ It seems to me that it is unreasonable for the PTS to be updated before the policy package actually hits the mirrors. There is a period of time after a package leaves incomming but before the mirrors are updated when the package is difficult to obtain. It is bad enough that Debian-policy 3.7.1 does not indicate meeting itself, but now the PTS is stating that debian-policy should be updated to a version policy newer than "Latest Version" (as the general information section states). See http://packages.qa.debian.org/d/debian-policy.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Policy version
"Raphael Hertzog" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] It seems to me that it is unreasonable for the PTS to be updated before the policy package actually hits the mirrors. There is a period of time after a package leaves incomming but before the mirrors are updated when the package is difficult to obtain. Frankly, I updated it a bit soon, right, but that was only because 3.7.2 revert the cgi-lib stuff and the PTS will let people notice that there's a newer version and that they must take care... And do we really need to complain of something that is broken for a few hours and that's will resolve itself alone in a few hours? /me wishes people wouldn't complain when we're actually fast I was not complaining. I was suggesting that the actions that were taken be avoided in general. It realy is not a big deal, and you are right that complaining about excessive speed is nearly absurd considering the last release cycle. Especially considering the context, what was done is reasonable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: patching a package?
"Lionel Elie Mamane" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
apt-get source ${PACKAGE}
cp -R ${PACKAGE}-${VERSION} ${PACKAGE}-${VERSION}.pristine-deb
cd ${PACKAGE}-${VERSION}
# hack away
cd ..
diff --recursive -u ${PACKAGE}-${VERSION}.pristine-deb
${PACKAGE}-${VERSION} > descriptive_name.patch
#(add -N option to diff if appropriate)
#send descriptive_name.patch to the maintainer, probably through a bug
#report.
Um... the person wanted to build a deb and install it for testing. You
should add those to the list of commands.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Matt Taggart and others" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Hi debian-devel, For a couple years now a few of us have been talking about an idea called "multiarch". This is a way to seamlessly allow support for multiple different binary targets on the same system, for example running both i386-linux-gnu and amd64-linux-gnu binaries on the same system (many other working combinations exist as well). I have created a new page in the wiki to track info and status My thoughts on a few multi-arch concepts. It is important to differentiate between the types of non-native files. There are files that are not native, but are intended to be used by native programs targeting the non-native arch. These include things like arch-specific header files. It almost seems like these should be put in /usr/share/include/$arch-$os/. (where $arch and $os represent the target arch) That is because headers for cross compiling are normally dependent on the target arch, but not the host arch. On the other hand, if we continue that thought process we could end up with all headers and libraries in /usr/share/, which is absurd. Indeed, the current proposal almost seems to be reversing this. Non-target specific libraries and header files remain in $prefix/lib and $prefix/include. It seems to me that libraries and headers that are not target specific are supposed to go in /usr/share. That is because if they are not target specific they are most certainly cross-platform. Hm... This entire concept seems messy. It seems that processors that support multiple architectures, as well as cross compilition are begining to blur the line between /usr and /usr/share. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Adam Borowski" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Thu, May 11, 2006 at 04:49:26PM -0400, Joe Smith wrote: On the other hand, if we continue that thought process we could end up with all headers and libraries in /usr/share/, which is absurd. Why? This is exactly what's beautiful, especially if EVERYTHING ends up in /usr/share/ at one day, at which point /share/ will be redundant and the FHS will change. That will be hard, a /usr/share to /usr symlink would likely end up part of that transition, and poorly written software could ave some trouble with that. Hm... This entire concept seems messy. It seems that processors that support multiple architectures, as well as cross compilition are begining to blur the line between /usr and /usr/share. It's not "messy", it's plain awesome. And if the line gets blurred into oblivion, it will be a reason for joy. Indeed. I was speeking about the transition being messy, not the final result. I take it that you are interested in a multi-arch solution for binaries, which the "upstream" proposal currently does not cover. Overall the idea seems good. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Daniel Ruoso" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Em Qui, 2006-05-11 às 09:56 +0200, Gabor Gombas escreveu: On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote: > Why would that not fly? > Both versions of the arch-independent package could be installed at > the same time. /usr/share/foo/bar can't point to two different files at the same time, so you can't install multiple package versions containing incompatible /usr/share/foo/bar files. The only way to support your proposal would be to kill the concept of arch-independent packages and make everything arch-dependent. And what if dpkg knows about it and handle arch-independant packages in a different way? In fact, if the system is multiarch, dpkg should have a centralized list of which packages are installed for each architecture and which packages are installed for arch: all... But there's still the problem of arch-independant files inside arch-dependant files (maybe an arch-dependant package should not include arch-indenpendant files at all)... The problem is when foo [i386] depends on bar [all] 1.0, but foo [amd64] depends on bar [all] 2.0. There is simply no good way to have bar [all] 1.0 and bar [all] 2.0 installed, so foo [i386] and foo [amd64] cannot both be installed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please revoke your signatures from MartinKraff's keys
"David Moreno Garza" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Luca Capello wrote: As a side note, while my passport was valid (re-newed the day before leaving for Mexico because I forgot it was expired after 5 years and not 10), I didn't get any Mexican seal when I arrived at Mexico City airport. As 2 others DDs with me (Aurelien Jarno and Matthias Klose) got a seal, I went back to the customs officer asking for the seal and he answered me I didn't need it. That's illegal actually. It is quite often to get your passport sealed while leaving your country but it is supposed to be mandatory to get the seal in the country you are arriving, otherwise you could be thought you are an illegal alien since no local official government dependency testifies you are arriving the country legally. I have travelled oversees serveral times, and it is relatively common for customs to fail to stamp US Passports. Apparently the US makes it very clear that US Citizens are not to be pestered at customs "OR ELSE". Of course, customs offcials have also stamped my passport on the wrong page, among other things, although that usually happens at ground borders. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Red team attacks vs. cracking
"Javier Fernández-Sanguino Peña" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Claiming that what Martin did was good since he was showing something useful for our community is equivalent to saying it was a "red team attack". Nobody used that term explicitly probably because they are unfamiliar with it. I know what it means, I've done my share of pen-testing to companies. I do agree with Manoj that this was *not* a legitimate experiment (i.e. not a "red team" test) and that Martin *did* abuse our [0] trust [1] Had Martin never mentioned this, it would have been a non-issue. There is no real damage. While signatures may have been based on a non-offical ID, Martin did indeed own the key in question, so the end harm is zero. But Martin decided to publish this experiment. Is this really a bad thing? He proved that KSP are bad for the web of trust. A legitimate attacker could abuse the KSP just as easilly as Martin, but would result in actual damage, and would most likely not have been caught. So, if KSPs are not changed, then the Web of trust becomes effectively worthless. Manoj should be far more concerned about that, then about Martin's demonstration of this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who can make binding legal agreements
"Martijn van Oosterhout" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On 6/7/06, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: Russ Allbery <[EMAIL PROTECTED]> writes: > John Goerzen <[EMAIL PROTECTED]> writes: >> Sure. SPI owns many of the machines that Debian owns. If any of >> these >> machines are being used to distribute this software, as I think is >> likely, then SPI could be liable. > > Oh, very good point. I hadn't thought of this. No. SPI is liable under the terms of copyright law; at most, it can be told to stop distributing things. Err, copyright infringement can be a criminal act as well. So if a DPP (DA or whatever it's called in your jurisdiction) takes a dislike to you (or perhaps someone whispers into their ear), they can haul you or SPI or mirror operators into court without Sun having anything to say about it. And the result could include gaol time, especially for this sort of large-scale willing mass copyright infringement. Except that In order to prove copyright violation the DA would need to involve Sun. There is no way for the DA to know if Sun secretly granted the infringer the right to distribute in that manner. AFAICT the infringer need not even know about such a grant for it to be valid. IANAL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-DD's in debian-legal
"Ian Jackson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Jeremy Hankins writes ("Non-DD's in debian-legal"):
I'm not sure I understand this part, though. Do you think that folks
like myself, who are not DD's, should not participate in the discussions
on d-l?
Actually, I think they should not participate, in general.
Um.. That is absurd. I participate some in D-legal, and IANADD.
Recently, most of my messages have been initial scans of a licence,
pointing out things that may be problematic, based on what I have seen
previously,
as well as common sense. I believe I usually notice most (not all, but most)
potential problems in a licence, and try to add appropritae recommendations.
If such behavior is not helpful, I will stop, but I find it hard to belive
that
what I described above is not helpful.
I suspect you are speaking more about the non-dd's who start 'software vs
documentation',
or 'softwave vs executables' style threads. I tend to stay out of those, as
regardless of
my feeling on the issues (I'm not even sure what they are), I'm pretty sure
that Debian
has decided that issue, and will not be changing it's mind in the near
future.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package
"Wesley J. Landaker" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Package: wnpp Severity: wishlist Owner: "Wesley J. Landaker" <[EMAIL PROTECTED]> * Package name: googleearth-package Upstream Author : Wesley J. Landaker <[EMAIL PROTECTED]> * URL : (native package) * License : GPL Description : utility for automatically building a Google Earth Debian package Google Earth is a great program now available for GNU/Linux, but sadly is both non-free and non-distributable. For those who wish to run it on their Debian system, but wish it to be managed by the normal Debian packaging system, this program will assist in building a local Debian package in a similar fashion to java-package. This package *itself* contains absolutely no code from Google and is 100% free. (For the curious, this is appropriately destined for contrib.) Is this really needed? Google was very careful in making sure that the package installs in /usr/local, and does not interfere with the system. Normally the main reason why a debian package is better than what upsteam distributed is because using upstreams packages will mess with stuff it should not touch. The reason java-package is needed is that upstream's packages are not well behaved, and install into /usr, potentially causeing problems if it decides to edit the files of other packages. Google Earth takes care of its own updates by prompting the user, and allowing them to download and run the new installer (or at least it does on windows, and I can't imagine why the linux version would not). Needing to use a *-package utility prevents automatic updates anyway, and does not simplify installation much if any. So the only real advantage would seem to be that it would make Google Earth easier to uninstall. Well I guess it simplifies pushing updates out to a bunch of workstations, but in most cases users should just download the the .bin and run it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package
"Nikita V. Youshchenko" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Ok, I agree that it's ok to trust installer source that they will not install a backdoor into your system. However, chances that they will write to directories that should be under control of package manager, or write to system files that should be under control of package manager or appropriate update scripts or administrator's hands - are very high. But AFAICT (I analyized the package quite closely, but neve did install it) Google Earth's Installer does not do this. IMHO, running 'foreign' installers as root is *the* whay to break your debian system. Normally, yes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package
"Wesley J. Landaker" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Joe Smith wrote: Is this really needed? Google was very careful in making sure that the package installs in /usr/local, and does not interfere with the system. Normally the main reason why a debian package is better than what upsteam distributed is because using upstreams packages will mess with stuff it should not touch. Well, it doesn't install in /usr/local (by default, you can get it there) but in a user's home directory. Actually, perhaps if you run it as root it will pick /usr/local by default, but I didn't try that (I don't usually run things as root, even stuff from Google). Google Earth takes care of its own updates by prompting the user, and allowing them to download and run the new installer (or at least it does on windows, and I can't imagine why the linux version would not). Needing to use a *-package utility prevents automatic updates anyway, and does not simplify installation much if any. So the only real advantage would seem to be that it would make Google Earth easier to uninstall. Well I guess it simplifies pushing updates out to a bunch of workstations, but in most cases users should just download the the .bin and run it. Apparently, the "easier to uninstall" is a bigger deal to me than it is to you. So this utility may not be for you. There has only been one version out for GNU/Linux as far as I'm aware, so I'm not sure anyone knows exactly how the updater works. Seeing how their software is packaged, I actually don't see any way that the Debianized version would break updates if run as root (which would have to be the case anyway unless every user has their own version) but personally I don't like programs that try to update themselves outside of package management. I agree that programs that use mechanisms other than the package manager to manage files can be a real pain, but remeber that a GNU/linux system is not guarenteed to have any package manager at all. On such a system self-updates can be quite usefull. Also remeber that /usr/local is not managed by package managers, so programs that live there can manage their files however they want without any problems. I'm pretty sure that it simply downloads and run the new installer. This is what it does on windows. The problem is that if a user uses the installer, and installs into /usr (like the debian package presumably does) then unless the debian package puts everything in exactly the same spot the installer would have, then it will not be possible to fully uninstall using the debs. Anyway, there are a few advantages: * Once you've made the package, you can install on multiple machines easily. * It's much cleaner, as you have a managed Debian package to install/uninstall. * In-program updates are optional (run as root and do them, or don't). * If you don't like doing it this way, nobody is going to make you do it. =) But the most important one of all is: I've found it useful, I've got it working[1], and I'd like to give others an opportunity to use it if they want to. Fair enough. Ideal would be to recive permission from upstream to simply repackage the files in the tarballs into a non-free deb, possibly showing the EULA as a debconf question of the highest priority. Preseeding the EULA question could easilly be seen as pre-accepting the EULA, so that should not be a problem. With a package like that, the only potiential problem is the programs internal update mechanism. Perhaps Google would consider adding a way to remove/hide the internal update choice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cgiirc Hijacking
"Mario 'BitKoenig' Holbe" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Tue, Jun 20, 2006 at 01:18:11PM -0300, Margarita Manterola wrote: In cases where a security bug is being fixed, you usually try to upload the package as soon as possible. If your sponsor is on We did. 0.5.4-6sarge1 was on s.d.o as soon as possible. Since there were no newer version in unstable, the version on s.d.o should have had automatically override even the unstable version. Of course, if you don't source in s.d.o, you don't get security updates :) I run unstable and do not have s.d.o As I understand it, there is no good reason to have s.d.o in my sources list, as the packages in there are for sarge, and may not be compatible with the current sid ABI. Besides, s.d.o is already a highly stressed server. (AFAIK) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new tar behavior and --wildcards
"Petr Vandrovec" wrote in message news:[EMAIL PROTECTED] Since this seems to have been an intentional behavior change by upstream to better align with a published standard, I'm uninclined to fight it, and think our best response is to update our utilities to include the --wildcards option, with a suitable versioned dependency on tar. This decision makes tar completely incompatible. Programs which worked fine with tar for 6 years are suddenly broken, and now you have to have two versions - one for 'tar' before this brokeness, which do not pass --wildcards, and one for this broken 'tar', which passes --wildcards. And older version on newer 'tar' extracts nothing, while new version on older 'tar' fails with an unknown option error. Maybe it could be default for tar's POSIX mode, but I have no idea why GNU mode behavior should be changed in any way. Petr Vandrovec Indeed. If POSIX compatability is important to the GNU tar maintainer, then why has he not updated GNU pax yet? UNIX03 has no tar, but has pax. So reviving the paxutils package seems more imporant than fixing an incompatibility with an outdated version of the Unix spec. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is OSS only support to be considered a bug?
"Preben Randhol" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Mon, 26 Jun 2006 21:35:19 +0200 Wouter Verhelst <[EMAIL PROTECTED]> wrote: On Mon, Jun 26, 2006 at 09:20:34PM +0200, Preben Randhol wrote: > With the 2.6 kernel programs using OSS for sound are not working > anymore. Sound that is. One *may* use aoss, but then the user needs > to open a terminal and write: > > aoss program-name > > because launching from the menu it won't work. So I consider aoss > only as a temporary dirty hack before alsa takes over completely. > > My question is if it is legitimately to open bugs against > applications that only support OSS for spund? No. There is snd-pcm-oss.ko, which provides working OSS sound, even if you don't use aoss. Just make sure to load the proper module. Yes, but isn't this considered to be a temporary transitional thing? It isn't loaded by default by the debian kernel image at least. Umm... See these pages: http://alsa.opensrc.org/aoss http://alsa.opensrc.org/OSSEmulation It sounds like both meathods are supported by the alsa devs, but obviously native Alsa support is prefered, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
