A few Debian packages use cz for lang code name for Czech
Hello, I just discovered that 4 Debian packages incorrectly use cz for the language code for Czech: http://www.debian.org/intl/l10n/po-debconf/cz (of course, the correct code is cs) I reported a bug against each of those, but wanted to let you be aware of that. I think you need to check what package maintainers are doing as, unfortunately, some people are wrong about the correct code for your language. --
Re: A few Debian packages use cz for lang code name for Czech
On Tue, Dec 14, 2004 at 07:55:35AM +0100, Christian Perrier wrote: Hello, I just discovered that 4 Debian packages incorrectly use cz for the language code for Czech: http://www.debian.org/intl/l10n/po-debconf/cz (of course, the correct code is cs) I reported a bug against each of those, but wanted to let you be aware of that. I think you need to check what package maintainers are doing as, unfortunately, some people are wrong about the correct code for your language. As a matter of fact, yesterday I sent the same wishlist bugreport against mysql (#285438) and I guess M. Jezbera asked the same about slay (#272399 several months ago...). -- Miroslav Kure
Re: Linux Core Consortium
me Ian Murdock (quotes out of order) If the LSB only attempts to certify things that haven't forked, then it's a no-op. Well, that's not quite fair; I have found it useful to bootstrap a porting effort using lsb-rpm. But for it to be a software operating environment and not just a software porting environment, it needs to have a non-trivial scope, which means an investment by both ISVs and distros. That's precisely what we're trying to do. :-) The context of my remark was your claim that by definition, the LSB codifies existing standards, i.e., things everyone already agree[s] with. If that's true, then the LSB doesn't represent a non-trivial investment on the distros' part, and no one should be surprised that the ISVs don't care about it. Agreeing on a set of LCC binaries would be non-trivial for the distros but its entire justification would be that it's trivial for the ISVs. That would be fine (on the assumption that ISV success is what matters) except that I don't think it will work. I respect your efforts to make commercial software on Linux more viable. But be careful what you wish for -- you might get it. Make it impossible to remove implementation warts because the binaries are more authoritative than the specification, and pretty soon you have a thriving ISV market -- for antivirus software, system repair utilities, interface hacks, and virtual machines to graft unreproducible system images onto new hardware. Wishing the ISVs operated a different way doesn't really get us any closer to a solution.. You seem to have missed my point. I don't wish for ISVs to operate a different way; I cope daily with the way that they _do_ operate, and am distressed by proposals that I think will make it worse. In my opinion, catering to poor software engineering practice by applying Holy Penguin Pee to a particular set of core binaries is unwise. I would have expected you and Bruce to agree -- in fact, to hold rather more radical opinions than I do -- so I must be missing something. Here's the case I would expect a Debian founder to be making. In short, I don't think that ISVs can afford for their releases to become hothouse flowers that only grow in the soil in which they germinated. It's understandable for ISVs to pressure distros to pool their QA efforts and to propose that this be done at a tactical level by sharing binaries. But I think that's based on a naive analysis of the quality problem. Inconsistent implementation behavior from one build to another is generally accompanied by similar inconsistencies from one use case to another, which don't magically get better by doing fewer builds. The requirement that software run on multiple distros today serves as a proxy for the much more important requirement that it run on the same distro today and tomorrow. It's a poor substitute for testing in a controlled environment, exposing only functionality which is common denominator among distros, but that takes skill, understanding, and labor beyond what ISVs are willing to invest. In practice, there are still going to be things that break when bits change out from under them. But it makes a great deal of difference whether an ISV is committed to fixing accidental dependencies on binary internals. Suppose I want to use an ISV's product on Debian myself, or to support its use on systems that I control. Usually the ISV's approach to Linux is to list a set of supported RedHat and SuSE distributions (often from years ago) on which they have more or less tested their software. That gives me some idea of what its de facto environmental requirements are. Then I reverse engineer the actual requirements (shared library versions, which shell /bin/sh is assumed to be, which JVM installed where, etc.) and select/adapt Debian packages accordingly. This is a pain but at least I get to use competently packaged open source code for all of the supporting components, and I can fix things incrementally without expecting much help from the ISV. If I'm going to go to this trouble, it's actually to my advantage that Debian packages are completely independently built -- separate packaging system, separate configure parameters, separately chosen patches. I find a lot of things up front that would otherwise hit me in the middle of an urgent upgrade -- calls to APIs that are supposed to be private, incorrectly linked shared objects (I do an ldd -r -v on everything), code built with dubious toolchains, weird uses of LD_LIBRARY_PATH, FHS violations. Sometimes ISVs even appreciate a heads-up about these problems and fix them in the next build. Given this strategy for ISV handling, obviously I prefer the ABI / test kit approach to distro convergence. For one thing, if commercial distros cooperated that way, it would make the reverse engineering easier. More importantly, any ISV which publicly buys into ABI-based testing will immediately gain credibility with me in a way that I can explain to
Re: LCC and blobs
* Goswin von Brederlow | I think something like Failure: firmware not loaded or Failure: | path/firmware: No such file or directory counts as a dependency. Nobody's said that the driver has to load the firmware. The firmware might well be loaded by first booting to some other OS, then into Linux, for instance. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Bug#285518: misdn-utils includes a firmware loader
* Simon Richter | (If the firmware used by this tool really is Free Software, my | apologies. However, in that case, the firmware still does not appear to | be available in Debian.) | | The tool is generic, hence I cannot make any assumptions on the | freeness of any firmware that may be loaded with it once the mISDN | stack reaches a non-beta state. You might also want to look into the ruling from tech-ctte on 119517 (referenced in the bug logs) wrt dependency when it's a minor part on a package's purpose. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: If you really want Free firmware...
* Kenneth Pronovici | I think what you're forgetting (or at least ignoring) is that designing | hardware is not exactly like designing software. The process is | similar, yes, but it's not an apples-to-apples comparison. At the | least, this is because testing your hardware implementation is not | free (as in beer). Nor am I aware of many free (or even cheap) | hardware development tools or environments. You can get microcontroller development boards with a handfull of ICs off atmel for around 30-40 euros. Etching 12x8cm boards costs you a couple of Euros and you can get a lot done without going that far, even, but just soldering stuff. Not free, but cheap enough that «it's too expensive» isn't a real argument. FPGA equipment is on the same magnitude of cost -- still a bit off «thousands of dollars» -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Are BLOBs source code?
Goswin von Brederlow wrote: (and it really was him this time -- sorry about last time; hand-quoting is tricky stuff): Is the pseudo source file enough for BSD or Artistic license? It's enough for BSD. (Which doesn't actually require source.) On the same subject but going in a totally different direction: As you say many blobs have been identified as code. Having pseudo source files under a free license would give everyone the right to disassemble the code. Reverese engeneering of the firmware would be allowed. Allowing pseudo source might be benefitial because it alows this. Yes. BSD-licensed BLOBs could be legally disassembled, decompiled, cleaned up, commented, improved, and the result could be Free.
Re: If you really want Free firmware...
On Tue, Dec 14, 2004 at 11:17:24AM +0100, Tollef Fog Heen wrote: * Kenneth Pronovici | I think what you're forgetting (or at least ignoring) is that designing | hardware is not exactly like designing software. The process is | similar, yes, but it's not an apples-to-apples comparison. At the | least, this is because testing your hardware implementation is not | free (as in beer). Nor am I aware of many free (or even cheap) | hardware development tools or environments. You can get microcontroller development boards with a handfull of ICs off atmel for around 30-40 euros. Etching 12x8cm boards costs you a couple of Euros and you can get a lot done without going that far, even, but just soldering stuff. Not free, but cheap enough that «it's too expensive» isn't a real argument. FPGA equipment is on the same magnitude of cost -- still a bit off «thousands of dollars» But none of that is on the same scale. You can't do highly complicated hardware designs with an 8-bit micro or the type of FPGA you can solder at home. You can (and do) do highly complicated software though. That FPGA equipment doesn't have free development tools, btw. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#285518: misdn-utils includes a firmware loader
Simon Richter [EMAIL PROTECTED] wrote: Hi, [quoting Josh Triplett] Package: misdn-utils Version: 0.0.0+cvs20041018-4 Severity: serious misdn-utils contains a utility loadfirm, for loading firmware onto ISDN devices. Unless this firmware is Free Software with source, which did not appear to be the case after a large amount of searching, this utility should not be in Debian main. In what respect is a utility to upload data (which are probably non-free) to a hardware device different from, for example, pybliographer? Pybliographer contains functionality to download data from PubMed, a free-as-in-beer literature database? What about a program that is designed to do uploads to the PDB, a free-as-in-beer scientific database of protein structures? All the data handled by these programs are non-free (because modification of scientific information is generally not acceptable, and usage is often restricted). By the way, what about ftp, a program designed to upload arbitrary data - often non-free files - to a hardware device via a protocol based on TCP/IP? Regards, Frank P.S. Shouldn't this be moved to -legal? -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: dselect survey
On Fri, Dec 10, 2004 at 11:52:05AM +0900, Miles Bader wrote: Completely and utterly wrong in my case. I'm exactly the sort of person that you apparently think should like dselect, but I think aptitude is _far_ superior, for both experts and newbies. The competition isn't even close. Except when you face the fact that aptitude uses a very sick kind of MDI. Sick because there's actually no MD, you're editing a single chunk of information using multiple views. It's very hard to figure out what just happened because there's no direct visual feedback. The other problem with aptitude is touted as a design feature: it tends to be all-or-nothing. Either you use it always or you don't (automatic removal thingie). This becomes a problem when multiple persons use different interfaces for adding and removing packages to the system. Marcelo
Re: If you really want Free firmware...
Op di, 14-12-2004 te 02:24 +, schreef Andrew Suffield: On Mon, Dec 13, 2004 at 03:57:19PM -0500, Brendan wrote: On Monday 13 December 2004 14:50, Andrew Suffield wrote: On Mon, Dec 13, 2004 at 11:21:54AM -0800, Bruce Perens wrote: My surmise is that we'd need an effort like that, raising $250K, to design and go to full-custom fabrication of an FPLA with fully-open design. Mine is that one can get useful things done without having to spend ridiculous amounts of money, or even any money at all. Yours is that you can't. Debian proves you wrong every day. What does that have to do with hardware, please? I mean, it's a lovely statement and all, but it's wrong. Right back at you. Not quite. To design software, all you need is a fully functional computer. To design hardware, you need to create and test a prototype every once in a while. That'll cost you. -- Wouter Verhelst NixSys BVBA Louizastraat 14, 2800 Mechelen T:+32 15 27 69 50 / F:+32 15 27 60 51 / M:+32 486 836 198
Re: Bug#285518: misdn-utils includes a firmware loader
On Tue, Dec 14, 2004 at 10:58:52AM +0100, Tollef Fog Heen wrote: * Simon Richter | (If the firmware used by this tool really is Free Software, my | apologies. However, in that case, the firmware still does not appear to | be available in Debian.) | | The tool is generic, hence I cannot make any assumptions on the | freeness of any firmware that may be loaded with it once the mISDN | stack reaches a non-beta state. It's fine for software in main to be able to do stuff with non-free data; that's not the issue. The question is whether there *exists* any free data that it works with, and if not, whether that's a problem. You might also want to look into the ruling from tech-ctte on 119517 (referenced in the bug logs) wrt dependency when it's a minor part on a package's purpose. That's an issue of Depends:, not of the Social Contract's never make the system depend on an item of non-free software, which I believe is the issue. (My understanding--which may well be wrong, of course--is that the tech-ctte's authority does not extend to the Social Contract or the DFSG.) -- Glenn Maynard
Re: If you really want Free firmware...
Any commercial software company will tell you exactly the same thing about software: testing is not free. Testing is not free only in the sense that a *vendor* might lose clients if said clients are the *testers*... Historically, lots of clients are performed free testng for vendors. I'm not talking about the open source realm either. -- WC -Sx- Jones http://insecurity.org/
Re: Bug#285518: misdn-utils includes a firmware loader
Frank Küster [EMAIL PROTECTED] wrote: P.S. Shouldn't this be moved to -legal? No. -legal is useful for determining whether a given piece of code meets the DFSG or not. It doesn't make policy decisions. -project is a better place for non-technical discussion of this sort of thing. -- Matthew Garrett | [EMAIL PROTECTED]
Re: If you really want Free firmware...
To design software, all you need is a fully functional computer. To design hardware, you need to create and test a prototype every once in a while. That'll cost you. Your logic doesnt follow. Why, then, isn't Be (BeOS) still around ? Plenty of fully functional computers around at the time -- and Yes, I know Steve Jobs killed off the Apple clone market. But the problem was Be could not switch architectures fast enough to survive. True point revealed: functional hardware doesnt go very far without functional Software. -- WC -Sx- Jones http://insecurity.org/
Re: If you really want Free firmware...
Op di, 14-12-2004 te 07:48 -0500, schreef Chasecreek Systemhouse: To design software, all you need is a fully functional computer. To design hardware, you need to create and test a prototype every once in a while. That'll cost you. Your logic doesnt follow. Why, then, isn't Be (BeOS) still around ? I don't see why that's relevant. To design software, all you need is a fully functional computer. To design software and make a profitable business out of that, you need quite a bit more; but that's not what's being discussed here. To design Open Source software (which BeOS never was, TTBOMK) and make that successful, you need a slight bit more than 'just' a computer, too (although not /that/ much more); but that's not being discussed here either. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Bug#285518: misdn-utils includes a firmware loader
Hi, It's fine for software in main to be able to do stuff with non-free data; that's not the issue. The question is whether there *exists* any free data that it works with, and if not, whether that's a problem. I don't believe that is a problem. We don't ship the non-free data, we just allow its use. I can see your point, however, that it is useless to ship an utility that cannot be used at present without having non-free data installed. This case is similar to the Quake one, I think, but I'm not sure it is really warranted to make a separate package for a single utility just to move it into contrib. The case was clearly different IMO if core functionality was affected, but in fact we are discussing about 100 lines of code within an ISDN stack. :-) Simon (who never thought he'd be on the pragmatic side) signature.asc Description: OpenPGP digital signature
Re: Linux Core Consortium
On Fri, 2004-12-10 at 00:44 +0100, Christoph Hellwig wrote: Besides that the LCC sounds like an extraordinarily bad idea, passing around binaries only makes sense if you can't easily reproduce them from the source (which I defined very broadly to include all build scripts and depencies), and that case is the worst possible thing a distribution can get into. The LCC core will be fully reproducible from source. You may (and probably will) lose any certifications if you do that, for the same reason that the distros reproduced from the Red Hat Enterprise Linux source (e.g., White Box Linux) lose them. But it won't be take it or leave it. If reproducing from source and/or modifying the core packages is more important to you than the certifications, you will be able to do that. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible. -T.E. Lawrence
Re: If you really want Free firmware...
Try to take a look to this http://lists.duskglow.com/open-graphics/ about problems, solutions and ASIC vs FPGA proposed for a real project to build a open design 2d/3d graphic card. Cheers, Blue.
Re: Linux Core Consortium
On Fri, 2004-12-10 at 10:07 +0100, Wouter Verhelst wrote: If this is what's going to happen, then the first time a security fix comes along in one of those binaries the system suddenly isn't LCC-compiant anymore (due to the fact that different distributions handle security updates differently -- one backports fixes, the other throws in the newest upstream release). Because the LCC is developed collaboratively by the distros that use it, this won't happen--the security fix will be applied to the LCC core, and the distros that are based on the LCC will incorporate the result in a uniform, consistent manner. In other words, there will be a single security update policy, not divergent ones for each LCC-based distro. It'll also severely hurt a distribution's ability to easily update to the newest upstream, or even to release when it's ready (but the next version of the LCC for some reason isn't). The LCC core will be reproducible from source, so if a distro wishes to do something differently, it may do so--though at the risk of losing certifications (and the ability to call it LCC-based, since it won't be, by definition, as long as its core is different from the LCC core). -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible. -T.E. Lawrence
Bug#285617: ITP: libxbox0 -- Shared library to allow xbox-linux applications to utilise the Xbox hardware
Package: wnpp Version: N/A; reported 2004-12-14 Severity: wishlist * Package name: libxbox0 Version : 0.1.0 Upstream Author : David Pye [EMAIL PROTECTED] * URL : http://www.xbox-linux.org * License : GPL Description : Shared library to allow xbox-linux applications to utilise the Xbox hardware Libxbox provides a number of functions to allow Linux applications running on Microsoft Xboxes to manipulate system attributes, such as ejecting and loading the DVD tray, changing the color of the frontpanel LED, and providing low-level information about the system and chipset versions. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux titanium 2.4.26-xbox #1 Thu Jul 8 19:42:03 BST 2004 i686 Locale: LANG=C, LC_CTYPE=C
Re: Linux Core Consortium
On Thu, 2004-12-09 at 14:33 -0600, John Hasler wrote: Why don't standard ABIs suffice? Because the LSB bases its certification process on a standard ABI/API specification alone, and this approach simply hasn't worked. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible. -T.E. Lawrence
Re: If you really want Free firmware...
Chasecreek Systemhouse writes: To design software, all you need is a fully functional computer. To design hardware, you need to create and test a prototype every once in a while. That'll cost you. Your logic doesnt follow. Why, then, isn't Be (BeOS) still around ? Plenty of fully functional computers around at the time -- and Yes, I know Steve Jobs killed off the Apple clone market. But the problem was Be could not switch architectures fast enough to survive. True point revealed: functional hardware doesnt go very far without functional Software. That is an entirely different point. Creating complex functional hardware (for a definition of complex that changes over time, as proto boards and cheap FGPAs become more capable) is much more expensive than creating software of comparably complex functionality. Tooling up for an ASIC production run using current processes costs tens or hundreds of thousands of dollars -- even if you assume the design is bug-free and there is zero cost until the design has taped out. That is a generous assumption given the absense of free software to perform many pre-tape-out steps and the dependence of that design file on a particular ASIC vendor's cell library. Those tens or hundreds of thousands have to be spent by everyone who wants to actually build the chip. If you just need to do a circuit board design, depending on number of layers and other details, ignoring per-unit costs and again assuming zero design costs, you might get off with paying thousands to low tens of thousands of dollars for a production run. Hardware design has very different and higher third-party costs than software design, and the cost to make and test minor revisions can be a significant fraction of the cost to do the initial build. As long as that is true, free hardware is not possible on the same scale as free software or with many of its benefits. Michael Poole
Re: If you really want Free firmware...
Another interesting link is Electronic Design Automation (EDA) software on Linux: http://www.linuxeda.com/ Cheers, Blue.
Re: Linux Core Consortium
On Fri, 2004-12-10 at 10:57 +0100, Adrian von Bidder wrote: On Friday 10 December 2004 06.15, Gunnar Wolf wrote: John Goerzen dijo [Thu, Dec 09, 2004 at 09:40:51PM -0600]: we could participate in this organization even if we didn't take their packages? That is, perhaps we could influence the direction to a more useful one? Then we would be non-participants, we would be just bitchers No, I don't think so. I think what Bruce and Ian are aiming at is - Debian can get influence in LCC, so - some things LCC does might actually make sense, so Debian does these things in the way LCC does. - other things will be done in LCC-space, that will not make sense in Debian, so Debian can still do it in its own way. What is the benefit? The divergence between LCC and Debian will still be smaller than when Debian just stays outside. So - vendors may offer compatibility to LCC with manageable overhead (Ubuntu, perhaps?) - porting LCC applications to Debian is limited to those small areas where divergence between LCC and Debian diverge. I think about things like hardware detection and autoconfiguration, where there's a lot development right now, and there are a lot of different solutions. In many cases, the various solutions are more or less equivalent and things are done differently mainly because of personal taste of whoever does the implementation. Having a voice in how LCC does these things and doing it the same way in Debian, in these cases, would be a Very Good Idea(tm), I feel. Well said. Even if Debian ends up not adopting the LCC core, Debian participation would 1. help make the LCC core, community, and processes better and thus more likely to achieve the desired result; and 2. help make the eventual differences between the LCC core and the Debian core smaller, which at least eases the compatibility problem even if it can't be eliminated entirely. In short, it's not an all-or-nothing thing. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible. -T.E. Lawrence
Re: Linux Core Consortium
On Mon, Dec 13, 2004 at 05:07:12PM -0500, Ian Murdock wrote: On Sat, 2004-12-11 at 03:49 -0800, Steve Langasek wrote: On Thu, Dec 09, 2004 at 03:39:55PM -0500, Ian Murdock wrote: You've just described the way the LSB has done it for years, which thus far, hasn't worked--while there are numerous LSB-certified distros, there are exactly zero LSB-certified applications. The reason for this is that substantially the same isn't good enough--ISVs want *exactly the same*, and there's a good reason for that, as evidenced by the fact that while Debian is technically (very nearly) LSB compliant, there are still a lot of edge cases like file system and package namespace differences that fall outside the LSB that vastly complicate the certify to an ABI, then support all distros that implement the ABI as defined by whether or not it passes a test kit model. Well, my first question is why, irrespective of how valuable the LSB itself is to them, any ISV would choose to get their apps LSB certified. The benefits of having one's distro LSB certified are clear, but what does an LSB certification give an ISV that their own internal testing can't? In an ideal world, ISVs could certify once, to the LSB, and their applications would run the same on every LSB-certified distro. This dramatically reduces the amount of internal distro-specific work each has to do. The stronger the LSB, the closer the distro-specific work is to zero, and the closer they get to a single Linux port. That wasn't my question. My question was, why should any ISV care if their product has been LSB-*certified*? ISVs can test against, and advertise support for, whatever they want to without getting the LSB's imprimatur. I cannot fathom why any ISV would go through the expense (money or time) of getting some sort of LSB certification instead of simply making this part of their in-house product QA; and therefore I don't see how the absence of LSB-certified applications can be regarded as a failure of the LSB process. Secondly, is this merely conjecture about the needs of ISVs, or have you (or someone else involved with the LCC) actually talked to people who've said these things? If this initiative is truly a response to the needs of ISVs, it should be fairly easy to publically specify the LCC's scope up front so that Debian can decide whether there's any sense in trying to get involved. We have absolutely been talking to ISVs about their needs--indeed, this has been a conversation that has been ongoing for years.. What about the LCC's scope isn't clear? Er, the fact that no actual scope has been stated? What does core mean? What packages (libraries) are included in this core? If Debian is not going to accept external binaries provided by the LCC into the archive, or finds it necessary to patch the source during the course of a release, does this mean Debian will not be a certified platform? If so, and given that these are very likely outcomes, what reason remains for Debian to get involved in the LCC if it's not going to result in any ISVs supporting Debian as a platform through the LCC effort? (If you see ways that Progeny would benefit from Debian's involvement in the LCC even if the official Debian releases are not LCC-certified in the end, I think that's relevant here; but I would like to know how you think it would benefit Progeny and other companies building on Debian, and why you think that Debian itself warrants representation at the table.) I don't think any of the above questions are ones to be hashed out by the distros participating in the LCC. If the impetus for the LCC really comes from ISVs, then the answers to these questions must be *their* answers; and if we don't have those answers, inter-distro talks would be aimless and futile. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity
Package: wnpp Severity: wishlist * Package name: expocity Version : 2.6.2-1 Upstream Author : Martin Grimme [EMAIL PROTECTED] * URL : http://www.pycage.de/software_expocity.html * License : GPL Description : An enanced Window Manager based on metacity Modern desktop environments make it possible for you to work on several documents in several windows at the same time. This will inevitably result in lots of open windows on your desktop. Switching between applications can become a real pain: the buttons in the taskbar already got too small to be usable, and finding the right window in the tablist takes ages. expocity is an effort to integrate an efficient means of switching between applications into the window manager metacity, similar to Expos(tm) on Apple's OS-X. Expos is a trademark of Apple Computer, Inc. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.26-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)
Re: If you really want Free firmware...
[Please Note that I'm not trying to create a hardware holy war. Of all the OSes I have used and upon all the architectures I have built - both commercial and non-commercial -- Debian has consistently delivered a great wholistic, as well as holistic, system solution.] On 14 Dec 2004 09:03:20 -0500, Michael Poole [EMAIL PROTECTED] wrote: Hardware design has very different and higher third-party costs than software design, and the cost to make and test minor revisions can be a significant fraction of the cost to do the initial build. As long as that is true, free hardware is not possible on the same scale as free software or with many of its benefits. Those costs exist mainly, IMHO, because the general public doesn't have wide spread manufacturing like Linux developers do with regard to software development. Personally I'm not buying it. Hardware costs what it does for the same reasons as software -- to advance the state of the art and to create better hardware (or software as the case may be.) Long ago someone said software would be cheaper to make if there was only one hardware platform to design for. Again, a non-relevant example would be IBM and the PC market -- why are there so many clones? If hardware manufacturers would stop creating 50 types of hardware - software development would cost nothing, right :-) As an aside to actual hardware -- I'm using (and chose) Debian for PowerPC and Ultrasparc, btw; not that it matters. But I will assure Debian that if support for PowerPC and/or Ultrasparc declines and I cannot use a platform of choice I can without hesitation choose soemthing other than Debian. Not that my one voice matters. Most of my *paying* clients, if not all of them use SuSE or Redhat -- they have lots of trouble too (most of them choose an OS other than Debian and then call me when there's an emergency) but thats another story and thread topic all together. Those clients that use Debian get help from me just about for free -- Debian, over all, is that good. -- WC -Sx- Jones http://insecurity.org/
Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity
also sprach Marco Nenciarini [EMAIL PROTECTED] [2004.12.14.1533 +0100]: expocity is an effort to integrate an efficient means of switching between applications into the window manager metacity, similar to Exposé(tm) on Apple's OS-X. enlighten us non-Darwinists: what does Exposé do? How does this differ from tabs as provided e.g. by fluxbox. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity
== Date: Tue, 14 Dec 2004 16:33:43 +0100 From: martin f krafft [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity == enlighten us non-Darwinists: what does Exposé do? How does this differ from tabs as provided e.g. by fluxbox. http://www.apple.com/macosx/features/expose/ bye Christian
Re: Linux Core Consortium
Yo all! Seeing this discussion wander in many directions, please consider what is acutally under discussion here: Bruce: I would not suggest that Debian commit to using LCC packages at this time. We should participate for a while and see how many changes we'd have to make and whether the project works for us. But I think we should be at the table and in a position to influence the project. The other members are willing to have us on those terms. - Debian is invited to participate in the LCC - Debian does not, at this time, have to commit to anything at all, whatever the output of the LCC is. Looking just at this, it seems - to me - more or less obvious that Debian should participate in this project, if there is manpower available to do so. Any 'Debianisms' that get pushed into LCC will lower the work ISVs have to do to support their applications on Debian. Any LCCisms that get accepted into Debian (for whatever reason) will do the same. Any output of LCC that some affected package maintainer does not like, he may ignore. (Having sound reasons may help keeping the discussions short, though :^) Whether Debian should or should not strive to be an LCC compliant distribution is not under discussion right now. The same goes for all the other 27 topics that are being discussed in this thread. (Hmm. Shouldn't this actually be under discussion on -project instead of here?) thanks for listening -- vbi (Hmmm. Can the list server be set up to reject replies to new mails within the first 2h after them having been sent out? ;-) -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/opinion pgpqFKJC1Fnr2.pgp Description: PGP signature
Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity
* [ 14-12-04 - 15:33 ] Marco Nenciarini [EMAIL PROTECTED] wrote: Description : An enanced Window Manager based on metacity s/enanced/enhanced/ expocity is an effort to integrate an efficient means of switching between applications into the window manager metacity, similar to Exposé(tm) on Apple's OS-X. IMHO you should put this sentence at the beginning of the long description rather than at the end. A more descriptive description would be cool too. :) ciao, ema
Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity
On Tue, Dec 14, 2004 at 04:43:11PM +0100, Christian Surchi wrote: == Date: Tue, 14 Dec 2004 16:33:43 +0100 From: martin f krafft [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity == enlighten us non-Darwinists: what does Expos? do? How does this differ from tabs as provided e.g. by fluxbox. http://www.apple.com/macosx/features/expose/ If you want to do something like this it seems more practical to make it available to all window managers. The package 'skippy' was recently mentioned on debian-mentors[1], and can be found here: [Upstream] http://thegraveyard.org/skippy.php [Initial packages] http://cxhome.ath.cx/debian/skippy/ It works nicely with my IceWM environment, and I'd love to see it uploaded... Steve -- # Debian Administration Tips www.debian-administration.org [1] http://lists.debian.org/debian-mentors/2004/12/msg00135.html
Re: If you really want Free firmware...
On Mon, Dec 13, 2004 at 08:57:20PM -0600, Kenneth Pronovici wrote: And no, I can't confirm or refute the numbers, which is why *I* didn't comment on whether they were realistic. You might want to try that sometime. I cannot figure out what mail you were reading. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity
On Tuesday, 14 de December de 2004 16:33, martin f krafft wrote: enlighten us non-Darwinists: what does Expos do? How does this differ from tabs as provided e.g. by fluxbox. Similar to Kompose: http://kompose.berlios.de/kompose_0.4.jpg pgp40arFgR6uG.pgp Description: PGP signature
Re: If you really want Free firmware...
Chasecreek Systemhouse writes: On 14 Dec 2004 09:03:20 -0500, Michael Poole [EMAIL PROTECTED] wrote: Hardware design has very different and higher third-party costs than software design, and the cost to make and test minor revisions can be a significant fraction of the cost to do the initial build. As long as that is true, free hardware is not possible on the same scale as free software or with many of its benefits. Those costs exist mainly, IMHO, because the general public doesn't have wide spread manufacturing like Linux developers do with regard to software development. Well, yeah. Have you priced out a quarter micron fab lately or looked at price lists for multi-layer PCB manufacturing equipment? The general public doesn't have widespread electronics manufacturing because the up-front and operating costs are both orders of magnitude above what you need for software, and because (again) a minor tweak of hardware involves disproportionately more cost than a minor tweak of software. Personally I'm not buying it. Hardware costs what it does for the same reasons as software -- to advance the state of the art and to create better hardware (or software as the case may be.) I have been on the design teams for an ASIC and a full system that required custom PCI boards. I have a reasonably accurate idea about the manufacturing costs for hardware, and those costs are all my email talked about. I ignored the design and testing costs, since free software has shown that you can amortize them across users. The manufacturing and distribution cost for software, on the other hand, can be effectively driven to zero. When the cost to produce an existing third-party design (making no changes) is five or six figures, there is not much reason to freely license whole designs. That cost is not your own labor: it is what you need to pay the companies who own fabs or PCB mills to build your design. The economics demand added value. That is why opencores.org deals with logic cores and proto boards rather than retail products. Michael Poole
Re: If you really want Free firmware...
On Mon, Dec 13, 2004 at 09:20:53PM -0600, Kenneth Pronovici wrote: I think what you're forgetting (or at least ignoring) is that designing hardware is not exactly like designing software. The process is similar, yes, but it's not an apples-to-apples comparison. At the least, this is because testing your hardware implementation is not free (as in beer). Any commercial software company will tell you exactly the same thing about software: testing is not free. We're *still* here. Consider why this works (without resorting to things which are obviously not true, like current hardware doesn't ship with (many) known bugs, or proprietary software is more reliable). The difference is that software testing is often free in a capital sense. I can volunteer my time to test or write open source software, and there is very little capital expense associated with it (my cable modem, my electricity, my PC, etc., much of which has other uses in my household). The commercial software companies use volunteers like this too, even on pure-proprietary stuff, and it's not what they're talking about when they say testing is expensive. Testing hardware of this sort requires actually manufacturing it (which is a capital expense) and requires various pieces of test equipment (the purchase of which would also be a capital expense). One way or another, someone will have to bear these expenses. And they say that about software too. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity
On Tue, 2004-12-14 at 15:33 +0100, Marco Nenciarini wrote: Package: wnpp Severity: wishlist * Package name: expocity Version : 2.6.2-1 Upstream Author : Martin Grimme [EMAIL PROTECTED] * URL : http://www.pycage.de/software_expocity.html * License : GPL Description : An enanced Window Manager based on metacity I like the idea... But unfortunately switching between desktops gets awfully slow. Too slow for me (as I switch between desktops a lot). But again, otherwise I like it... -- Hanspeter Kunz Artificial Intelligence Laboratory Ph.D. Student Department of Information Technology Email: [EMAIL PROTECTED] University of Zurich Tel: +41.(0)44.63-54306 Andreasstrasse 15, Office 2.12 http://ailab.ch/people/hkunzCH-8050 Zurich, Switzerland Spamtraps: [EMAIL PROTECTED] [EMAIL PROTECTED] --- Honesty is the best policy, but insanity is a better defense. signature.asc Description: This is a digitally signed message part
Re: If you really want Free firmware...
On 14/12/2004 Chasecreek Systemhouse wrote: Personally I'm not buying it. Hardware costs what it does for the same reasons as software -- to advance the state of the art and to create better hardware (or software as the case may be.) I personally don't think that the price of products in a capitalistic society is to advance creation of better hardware in general. it might be, that other reasons take into account here, as most people who determine the price of products don't know much about the products themselves. bye jonas
Re: Linux Core Consortium
On Tue, 2004-12-14 at 06:16 -0800, Steve Langasek wrote: On Mon, Dec 13, 2004 at 05:07:12PM -0500, Ian Murdock wrote: On Sat, 2004-12-11 at 03:49 -0800, Steve Langasek wrote: Well, my first question is why, irrespective of how valuable the LSB itself is to them, any ISV would choose to get their apps LSB certified. The benefits of having one's distro LSB certified are clear, but what does an LSB certification give an ISV that their own internal testing can't? In an ideal world, ISVs could certify once, to the LSB, and their applications would run the same on every LSB-certified distro. This dramatically reduces the amount of internal distro-specific work each has to do. The stronger the LSB, the closer the distro-specific work is to zero, and the closer they get to a single Linux port. That wasn't my question. My question was, why should any ISV care if their product has been LSB-*certified*? ISVs can test against, and advertise support for, whatever they want to without getting the LSB's imprimatur. I cannot fathom why any ISV would go through the expense (money or time) of getting some sort of LSB certification instead of simply making this part of their in-house product QA; and therefore I don't see how the absence of LSB-certified applications can be regarded as a failure of the LSB process. My point was this: *If* getting their products LSB-certified would allow them to support those products on any LSB-certified distro without the major investment necessary to deal with the edge cases the LSB doesn't currently cover, they would do it. That isn't the case now, which is why none of them are LSB-certifying their products today. Certification should mean it works. That's not the case as regards LSB certification today, so the ISVs put the investment into supporting each distro separately. If certify to LSB, run on any LSB-certified distro was a reality, they could put that investment into the LSB and end up with a longer list of supported distros to boot--smaller cost, larger benefit, i.e., it's a win-win. What about the LCC's scope isn't clear? Er, the fact that no actual scope has been stated? What does core mean? What packages (libraries) are included in this core? Core means implemention of LSB, and the packages/libraries that will constitute that are being determined now, as a collaborative process. I assumed Debian would want to be involved in this process too, rather than being presented with a more well-defined scope as a fait accompli.. If Debian is not going to accept external binaries provided by the LCC into the archive, or finds it necessary to patch the source during the course of a release, does this mean Debian will not be a certified platform? Yes. If so, and given that these are very likely outcomes, what reason remains for Debian to get involved in the LCC if it's not going to result in any ISVs supporting Debian as a platform through the LCC effort? At the very least, the differences would be smaller than they otherwise would be, and that can only be a good thing for LCC, Debian, and the Linux world as a whole. And, who knows, with Debian participation, perhaps the differences would end up being small enough and the processes, methods, and mechanisms defined such that it's no longer a very likely outcome. (If you see ways that Progeny would benefit from Debian's involvement in the LCC even if the official Debian releases are not LCC-certified in the end, I think that's relevant here; but I would like to know how you think it would benefit Progeny and other companies building on Debian, and why you think that Debian itself warrants representation at the table.) As I said at the very outset, one possible way forward is to simply produce a Debian-packaged version of the LCC core independently, and to make sure that core is 100% compatible with Debian (i.e., you can take any Debian package and install it on the LCC Debian core and get the same results as if you'd installed it on Debian itself). I'm truly hoping that's not the only way forward though, which is why I'm trying to engage the Debian community to find another way. One thing is clear: No matter how we end up approaching the ideal of common core that can form the basis of both RPM- and Debian-based distros, it'll clearly be better for all involved that the differences between Debian and LCC remain small. The smaller the differences, the closer the LCC Debian core is to Debian itself, which in turn benefits Debian because those folks are more closely working with Debian rather than working on LCC Debian. I don't think any of the above questions are ones to be hashed out by the distros participating in the LCC. If the impetus for the LCC really comes from ISVs, then the answers to these questions must be *their* answers; and if we don't have those answers, inter-distro talks would be aimless and futile. The ISVs have spoken. They want to support
Re: If you really want Free firmware...
On Tue, Dec 14, 2004 at 11:17:24AM +0100, Tollef Fog Heen wrote: * Kenneth Pronovici | I think what you're forgetting (or at least ignoring) is that designing | hardware is not exactly like designing software. The process is | similar, yes, but it's not an apples-to-apples comparison. At the | least, this is because testing your hardware implementation is not | free (as in beer). Nor am I aware of many free (or even cheap) | hardware development tools or environments. You can get microcontroller development boards with a handfull of ICs off atmel for around 30-40 euros. Etching 12x8cm boards costs you a couple of Euros and you can get a lot done without going that far, even, but just soldering stuff. Not free, but cheap enough that «it's too expensive» isn't a real argument. I stand corrected on these costs. Again, I'm not claiming to be an expert here - can the development Bruce is suggesting really be done on this sort of development board? FPGA equipment is on the same magnitude of cost -- still a bit off «thousands of dollars» Not sure where thousands of dollars came from (not me), but OK. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpbqZpqhAPjX.pgp Description: PGP signature
Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity
also sprach Isaac Clerencia [EMAIL PROTECTED] [2004.12.14.1610 +0100]: Similar to Kompose: http://kompose.berlios.de/kompose_0.4.jpg I fail to see the innovative component. What am I looking for? also sprach Christian Surchi [EMAIL PROTECTED] [2004.12.14.1643 +0100]: also sprach Steve Kemp [EMAIL PROTECTED] [2004.12.14.1651 +0100]: http://www.apple.com/macosx/features/expose/ quote: Admit it, Mac OS X has you spoiled. Youve become so used to its reliability that you dont hesitate to have a dozen applications running at the same time. Which means, of course, that you probably spend a fair amount of time each day poking through open windows and documents just to uncover the one you need at the moment. Damn, and I run about 60 applications simultaneously and never lose overview with fluxbox or ion. I must be doing something wrong. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: If you really want Free firmware...
On Tue, 2004-12-14 at 17:43 +0100, Jonas Meurer wrote: On 14/12/2004 Chasecreek Systemhouse wrote: Personally I'm not buying it. Hardware costs what it does for the same reasons as software -- to advance the state of the art and to create better hardware (or software as the case may be.) I personally don't think that the price of products in a capitalistic society is to advance creation of better hardware in general. it might be, that other reasons take into account here, as most people who determine the price of products don't know much about the products themselves. The *price* of product has *nothing* to do with how much it *cost* to create. The price that someone is willing to pay for an item is a function of it's *perceived* value to the purchaser. That's why, unfortunately, sales and marketing are so important in capitalist/free market systems: use S M to convince the consumer that they need the product, and will thus pay more than, for example, cost of goods sold + 8% profit. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. My husband and I are either going to buy a dog or have a child. We can't decide whether to ruin our carpet or ruin our lives. Rita Rudner signature.asc Description: This is a digitally signed message part
Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity
On Tue, Dec 14, 2004 at 06:10:08PM +0100, martin f krafft wrote: Damn, and I run about 60 applications simultaneously and never lose overview with fluxbox or ion. I must be doing something wrong. This seems to me to be a sloppy way to work. If all these apps are doing significant amounts of work, each one is going to run very slowly. More than a few simultaneous compiles and you're just thrashing. I have a fast computer and have selected apps that start quickly. I find it neater and cleaner to open and close the handful of things I'm working on, and instead run hundreds of tasks serially rather than in parallel. I think this is just sloppiness.
Re: If you really want Free firmware...
On Tue, Dec 14, 2004 at 03:51:43PM +, Andrew Suffield wrote: On Mon, Dec 13, 2004 at 08:57:20PM -0600, Kenneth Pronovici wrote: And no, I can't confirm or refute the numbers, which is why *I* didn't comment on whether they were realistic. You might want to try that sometime. I cannot figure out what mail you were reading. The attributions were intact in my reply. I guess I can help you out, though. Let's see: Message-ID: [EMAIL PROTECTED] Bruce said, My surmise is that we'd need an effort like that, raising $250K... Message-ID: [EMAIL PROTECTED] You said, There is absolutely no reason why any money is needed for this. Design the damn thing... Message-ID: [EMAIL PROTECTED] Hamish said, Manufacturing an ASIC involves NRE...of hundreds of thousands to millions per revision... Message-ID: [EMAIL PROTECTED] You said, Manufacturing an operating system involves NRE costs of hundreds of thousands to millions per revision... you're quoting Redmond propoganda... [This implied that Hamish's numbers were not valid.] Message-ID: [EMAIL PROTECTED] (This is the message you just replied to) I said, Do you have any actual hardware design experience to draw on here..., in reply to your implication about Hamish's numbers. Clear now? KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpZmPM7Cr8Dy.pgp Description: PGP signature
Re: Linux Core Consortium
* Ian Murdock | On Fri, 2004-12-10 at 10:07 +0100, Wouter Verhelst wrote: | If this is what's going to happen, then the first time a security fix | comes along in one of those binaries the system suddenly isn't | LCC-compiant anymore (due to the fact that different distributions | handle security updates differently -- one backports fixes, the other | throws in the newest upstream release). | | Because the LCC is developed collaboratively by the distros that use it, | this won't happen--the security fix will be applied to the LCC core, | and the distros that are based on the LCC will incorporate the result | in a uniform, consistent manner. In other words, there will be a single | security update policy, not divergent ones for each LCC-based distro. This sounds a bit like the government whose country had three different types of power plugs. None compatible, of course. Somebody then got the great idea that if they invented another one to supersede the three plugs in use (since that caused overhead). That country now has four plugs in use. (Whether this is an urban legend, whether it was three, five or eight different kinds of plugs is beside the point here.) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: binary NMUs and version numbers
Anthony Towns aj@azure.humbug.org.au writes: Goswin von Brederlow wrote: 1.rc 1.rc2 1.rc+b1 1.2-1~beta 1.2-1~beta2 1.2-1~beta+b1 1.2~beta-1 1.2~beta-1+b1 1.2~beta2-1 Keeping the Debian revision simple is a Good Thing. Adding the implicit '0' that dpkg assumes on versions ending in alpha chars would solve both cases: That'd mean REJECTing uploads whose versions match [^0-9]+[a-z][0-9]+$ presumably. No, why? A version matching [a-z]$ has an implicit trailing 0 in dpkg version terms. When adding a + that implicit 0 must be added explicitly to preserve the ordering. With that rule there is no reason to rstrict the version to exclude [a-z]$. Another case that should be considered is the existing use of + for revisions of a cvs snapshot (e.g. mutt uses a + but always does so): 1.2-20041208 1.2-20041208+2 1.2-20041208+b1 Hrm, why isn't this 1.2+20041208-1 ? Isn't the date describing the upstream version? Or 1.2-20041208-1, or 1.2+cvs20041208-1 or whatever. -rw-rw-r-- 16 katiedebadmin 2908273 May 2 2004 pool/main/m/mutt/mutt_1.5.6.orig.tar.gz -rw-rw-r-- 16 katiedebadmin 412082 Nov 17 10:17 pool/main/m/mutt/mutt_1.5.6-20040907+2.diff.gz It seems to result in rather large diffs, and I can't really see the benefit? There are 3 simple solutions to this: 1. forbid + in debian versions and think of another character instead doing the same (must be '.') Actually, that doesn't work either -- otherwise a new maintainer version (x-y#1) compares less than an old NMU (x-y.1). For the same reason = . doesn't work. Right, so a debian version may only be extended by characters that compare '.'. That should be noted somewhere. Cheers, aj MfG Goswin
Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity
also sprach William Ballard [EMAIL PROTECTED] [2004.12.14.1825 +0100]: Damn, and I run about 60 applications simultaneously and never lose overview with fluxbox or ion. I must be doing something wrong. This seems to me to be a sloppy way to work. If all these apps are doing significant amounts of work, each one is going to run very slowly. More than a few simultaneous compiles and you're just thrashing. You forget that application != memory/performance hog. I did not say I run OpenOffice.org or KDE or Gnome or anything. If I do not use an application, it idles and consumes a PID and a couple of file handles and that's it. I find it neater and cleaner to open and close the handful of things I'm working on, and instead run hundreds of tasks serially rather than in parallel. I leave the serialisation up to the scheduler. I would claim to range up in the 98% efficiency department with my computer use. Part of that is related to the way my apps and screen estate are organised. The other part is that I click the mouse button maybe five times a day. I think this is just sloppiness. i might disagree with what you have to say, but I'll defend to the death your right to say it. -- voltaire You must have had horrible experiences with your computer. I am sorry. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: If you really want Free firmware...
[Yes, replying to myself.] On Tue, Dec 14, 2004 at 11:05:44AM -0600, Kenneth Pronovici wrote: On Tue, Dec 14, 2004 at 11:17:24AM +0100, Tollef Fog Heen wrote: * Kenneth Pronovici | I think what you're forgetting (or at least ignoring) is that designing | hardware is not exactly like designing software. The process is | similar, yes, but it's not an apples-to-apples comparison. At the | least, this is because testing your hardware implementation is not | free (as in beer). Nor am I aware of many free (or even cheap) | hardware development tools or environments. You can get microcontroller development boards with a handfull of ICs off atmel for around 30-40 euros. Etching 12x8cm boards costs you a couple of Euros and you can get a lot done without going that far, even, but just soldering stuff. Not free, but cheap enough that «it's too expensive» isn't a real argument. I stand corrected on these costs. Again, I'm not claiming to be an expert here - can the development Bruce is suggesting really be done on this sort of development board? (I think someone else answered this in a different reply to my original note.) FPGA equipment is on the same magnitude of cost -- still a bit off «thousands of dollars» Not sure where thousands of dollars came from (not me), but OK. Aha, I see where you found this in my original note (although you didn't quote it). In that paragraph, thousands of dollars was just an example for illustration, although I chose the magnitude of the cost from one of the links Bruce posted (I recall seeing a $5400 fabrication cost listed on one of those pages). KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpvB5QF42RfO.pgp Description: PGP signature
Re: Linux Core Consortium
Ian Murdock dijo [Tue, Dec 14, 2004 at 11:53:54AM -0500]: (snip) The ISVs have spoken. They want to support as few ports as possible, because those ports cost money. They also want to support as much of the market as possible, and the current reality is that many of those markets are out of reach today. Beyond that, they don't care. If there's an open standard they can certify to and reach a broader market, they'll be very happy with that. If commercial Linux ends up being owned by Red Hat, they'll be fine with that too. I for one am hoping it doesn't come to that. The current reality seems like a pretty big opportunity to me to define a different future. Ok, so with this you are stating that the only way to get the ISVs to certify Debian is to gain market share. If by adhering to the LSB we got no results then, how would you think that by adhering to the LCC we would? Yes, it will be a bit simpler for them to have their applications run natively on all LCC-certified distributions... But they want to be sure to be able to guarantee to each of their users the application will work just as they tested it. And LCC is just one step, there is still a lot of components outside it. I really doubt that the LCC will be enough to lure them in. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity
martin f krafft [EMAIL PROTECTED] wrote: also sprach Christian Surchi [EMAIL PROTECTED] [2004.12.14.1643 +0100]: also sprach Steve Kemp [EMAIL PROTECTED] [2004.12.14.1651 +0100]: http://www.apple.com/macosx/features/expose/ quote: Admit it, Mac OS X has you spoiled. Youve become so used to its reliability that you dont hesitate to have a dozen applications running at the same time. Which means, of course, that you probably spend a fair amount of time each day poking through open windows and documents just to uncover the one you need at the moment. Damn, and I run about 60 applications simultaneously and never lose overview with fluxbox or ion. I must be doing something wrong. Probably a matter of taste. On Linux, I usually have multiple workspaces, and therefore no problem finding the right window. Others may prefer to have everything on a single workspace. IIRC in MacOSX you have no choice, and there I liked the feature very much. But this also depends on an other misfeature of MacOSX: If an application has multiple windows open, you cannot cycle between them (at least not with the same keystrokes used to cycle between applications). But you can use Expose to get the right window. Regards, Frank -- Frank Kster Inst. f. Biochemie der Univ. Zrich Debian Developer
Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity
On Tue, Dec 14, 2004 at 06:33:31PM +0100, martin f krafft wrote: You must have had horrible experiences with your computer. I am sorry. Not at all. I've just never been a fan of having a thousand windows open. I keep 4 terminals tiled on 1 desktop, use screen to background things, and use a tabbed Firefox on desktop 2. Occasionally an additional terminal is spawned to background music in mplayer. Other apps such as Gimp or Code Editors are transient and float over some of the terminals. Heavy work is done in server processes, and I have lots of those, but they aren't managed by my WM. I get my rocks off on heavy-duty apps starting in subsecond times. I like transient windows, above my bedrock of workers. Sometimes serial is sexy.
Re: /var/log on Debian systems
martin f krafft wrote: On all my Debian systems, /var/log seems like a big pile of dumps without much consistency. Especially, while 0640:root:adm seems to be a commonly accepted guideline, proggies like aptitude, scrollkeeper, X, xdm, fontconfig, and many others basically just dump their files world-readable into there. What's so private in these log files that they should not world readable? Regards, Joey -- Every use of Linux is a proper use of Linux. -- Jon 'maddog' Hall Please always Cc to me when replying to me on the lists.
Re: /var/log on Debian systems
also sprach Martin Schulze [EMAIL PROTECTED] [2004.12.14.1955 +0100]: be a commonly accepted guideline, proggies like aptitude, scrollkeeper, X, xdm, fontconfig, and many others basically just dump their files world-readable into there. What's so private in these log files that they should not world readable? Let me ask you the complementary question: what's so public in these log files that they should be world readable? I understand your question, and it's a very good one, and I wonder if this is a fundamental question about Debian. It reminds me of the decision to make /bin/su 4754:root:wheel instead of 4750:root:wheel. If you ask me, 4754 is a sane choice with a very pragmatic reason. Log files, however, are different, and claiming that they are non-private and thus world-readable is somewhat arbitrary to me. It makes no sense to chmod 4750 /bin/su or 0711 /sbin or anything of that sort, because that would be obscurity as any other Debian system could deliver the information. However, log files are specific to each system and no two log files will ever be the same. Whether the information therein is inherently public or private is not really the issue. I think the issue is rather whether Debian generally approaches security from a conservative or liberal position. Conservative maps to denying everything that isn't explicitly allowed, and liberal allows everything unless explicitly denied. Look no further than the security team... your policy (on critical bugs) is to hide information unless you have reason to make them public. Why should other parts of Debian do it the other way around? I claim the set of potential dangers, attacks, problems, and watchouts to be infinite. Thus, it's a Sysiphus job to attempt to protect the things known to be sensitive. Instead, unprotect those that are known to be save! This is standard security and safety procedure, this is what any sensible security person these days will advocate for a generic purpose. Information is the primary asset of a hacker (next to skill). Between X and fontconfig and other logs, a hacker (or malicious (or not)) user can map out behaviour patterns of users without being noticed (which may or may not be the case when using ps(1) or /proc). These can seriously augment social engineering attacks. Security cannot be perfect, but giving full access to information is outright careless. I really do not want to reopen cans of worms here, nor do I want to start a heated discussion. I screwed up in that I did not research before posting the first message of this thread. Santiago corrected me by mentioning a consensus that had been reached. I cannot find this consensus. Could someone please shove it in my face? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
having trouble with xdm/xfs 4.3.0.dfsg.1-9?
[Followups set to debian-x.] Hi folks, I just wanted to bring the following information to the attention of those who may be frustrated by problems with the latest xdm and xfs packages. [...] [14 December] XFree86 4.3.0.dfsg.1-9 sneaked out with a couple of small but annoying bugs in it. Specifically, the xdm and xfs packages suffer from some bad shell syntax in conffiles. Fabio and I plan to release what it is currently on the SVN trunk as 4.3.0.dfsg.1-10 in a couple of days. In the meantime, you can grab fixes (in unified diff format) for the [14]xdm bug and the [15]xfs bug from the archives of the debian-x mailing list. 14. http://lists.debian.org/debian-x/2004/12/msg00411.html 15. http://lists.debian.org/debian-x/2004/12/msg00410.html [...] The above is from the X Strike Force news page. If you use Debian X Strike Force-maintained packages from testing or unstable, please bookmark the following site: http://necrotic.deadbeast.net/xsf/XFree86/NEWS.xhtml -- G. Branden Robinson| The greatest productive force is Debian GNU/Linux | human selfishness. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Drop testing
Hello I may write exactly the same thing as Steve Langasek but I just have to tell why I would like to keep testing. On Sat, Oct 23, 2004 at 12:56:36PM +0200, Eduard Bloch wrote: #include hallo.h Some improvements have already been proposed by Eduard Bloch and Adrian Bunk: freezing unstable while keeping testing. Jerome, please, you could have asked me. I prepare an internal GR draft for exactly this issue, but it is to be made public on the day of the release, and better not before. We should concentrate on making the Sarge release ready, NOW. Do not start another flamewar. To hell with it, the avalanche has already started. The attached paper was written down as a GR draft, but if the problem can be solved peacefully by a consens on d-d and in agreement of the release manager(s), this is the way to go. Otherwise, take it as a real GR draft which should be completed later. It may sound a bit radical, but core points have been mentioned in the thread already. I suggest to do it in a more radical way: - unstable lockdown in the freeze - drop Testing and concentrate on work instead of wasting time on synching stuff. This eliminates the need for testing-security. See the last part of the paper for details. The sync problems will not exist if we drop testing? - about the filtering updates for frozen - yes, some additional manpower is required but that work must be done. The problems with Testing synchronisation are not of pure technical nature, they are social problem, and so they should be solved by people and not scripts. So this means that we need more FTP-maintainers, or more effort spent by them. Regards, Eduard. -- Ein Bauer zwischen zwei Advokaten gleicht einem Fisch zwischen zwei Katzen. -- Sprichwort ABSTRACT I propose that the Debian project resolve these questions: - should we continue using Testing and the gradual freeze model? - should we change the freeze model to the tristate model (similar to the one from the old days) Possible choices: - stop using Testing distribution and change to the Tristate freeze model - stop using Testing, the release manager should develop the freeze model - continue using the current release model RATIONALE - Why is testing bad? == One of the first and most known things: it puts a lot of outdated packages on the head of our users! Yes, testing sounds like a good compromise for people that want to have bleeding edge software without taking the risk, but we saw in the past years that testing created more problems that it was really worth. Well testing is not a perfect solution for people to use as it do not contain security updates and lack updated packages. Yes, and I do not think that is a bad thing. I actually think that is what you can expect. If people want to have a secure system they should use stable and if they want bleeding edge they should use unstable. That is their decision and not ours. Testing is a good thing to use for development and not something you sould see as a form of stable. If that were the case it should be named prerelease or something. As a testbed testing is something good. You will not have the most critical known bugs in the system so you can keep on testing things. We also have a good mixture of people using unstable and testing (I know many people that use unstable and also many people that use testing), so that is not a problem. The only advantages guaranteed by its structure was a promise to keep an installable set of packages. Which does not promise a useful/bugfree piece Yes and this is a very good thing as we did have problems with this before testing was created. of software. I think we should be fair to our users when we tell them to report bugs - we should tell all of them that reporting bugs in Sarge is often duplicated work because the problem has been fixed in Unstable. I I do not know if you have noticed that people tend to report bugs at whatever they are using. I get a lot of bugs on packages in stable, testing and unstable. Sometimes even exprimental. If we drop testing we will still keep getting bugs from people that use unstable (and not a fully updated one). I do not see the big problem with this. Replying to the mail and closing the bug is very easy and do not take much time. I maintain about 60 packages (at my spared time) and I do not see this as a big problem. think we should be fair to our users - we should not put a lot of buggy software onto their heads (promising some bogus stability at the same time), without having working security upgrade system. Without giving the I do not really see your point. I think it is quite clearly stated that neither unstable and testing have security support. Should we restrict people from running unstable too? individual developer a chance to fix bugs in the development distribution quickly
Re: Right Way to make a configuration package
Hello I assume that my answer is a bit late as you wrote this in october. I have written a package, dysyco that do similar things to what you want. Take a look. I may have misunderstood you. // Ola On Thu, Oct 14, 2004 at 03:37:27PM -0400, Mark Roach wrote: I am working on creating a package for UserLinux which will configure several packages with sensible defaults for an authentication server. At the moment, that means samba, slapd, pam and nss, but will also include heimdal later on. My naive question is: is there currently any mechanism for forcing the user to configure package x from within package y, and/or for reconfiguring one package based on reconfiguring another? ## warning, verbosity follows ## Perhaps I'm just approaching this the wrong way, so here is what I am doing (and where the problem comes in), and if anyone has a suggestion for a better approach, I would be happy to hear it. userlinux-auth-server depends on slapd, samba, libpam-ldap, and libnss- ldap. In the postinst, it gets the samba domain name, the dns domain name, and the ldap master password out of debconf, and populates the necessary entries. One problem is that the user may not necessarily have ever configured samba or slapd through debconf. This package needs that info, but it's not possible to dpkg-reconfigure a package from within the postinst of another package. So we would have to tell them to manually dpkg- reconfigure the dependancies and then reinstall, or gather the information ourselves, but then there is potentially conflicting info in debconf... Another similar problem is that the user may reconfigure samba-common or slapd at any point and obviously my package wouldn't know about it. So, my conclusion is that debconf is not particularly well suited to integrating several otherwise-unrelated packages and I am unsure whether working around the problem, or helping to improve debconf, or doing it some other way entirely is the better approach... thoughts? Thanks, Mark Roach -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Bug#285682: ITP: xbox-blink -- Tool to manipulate the front-panel LED on the Microsoft Xbox
Package: wnpp Version: N/A; reported 2004-12-14 Severity: wishlist * Package name: xbox-blink Version : 0.1.0 Upstream Author : David Pye [EMAIL PROTECTED] * URL : http://www.xbox-linux.org * License : GPL Description : Tool to manipulate the front-panel LED on the Microsoft Xbox This small tool is for people running GNU/Linux on the Microsoft Xbox, and allows manipulation of the front panel LED color via libxbox. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux titanium 2.4.26-xbox #1 Thu Jul 8 19:42:03 BST 2004 i686 Locale: LANG=C, LC_CTYPE=C
Bug#285681: ITP: libxbox-dev -- Libxbox-dev provides the headers for libxbox0 and the libxbox.so symlink
Package: wnpp Version: N/A; reported 2004-12-14 Severity: wishlist * Package name: libxbox-dev Version : 0.1.0 Upstream Author : David Pye [EMAIL PROTECTED] * URL : http://www.xbox-linux.org * License : GPL Description : Libxbox-dev provides the headers for libxbox0 and the libxbox.so symlink As title. See the recent ITP for libxbox0 for more information about what libxbox provides. (Bug#285617) -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux titanium 2.4.26-xbox #1 Thu Jul 8 19:42:03 BST 2004 i686 Locale: LANG=C, LC_CTYPE=C
ITP: wrapperfactory.app -- Application wrappers configuration tool for GNUstep
Package: wnpp Severity: wishlist * Package name: wrapperfactory.app Version : 0.1.0 Upstream Author : Raffael Herzog [EMAIL PROTECTED] * URL : ftp://ftp.raffael.ch/software/GNUstepWrapper/ * License : GNU GPL Description : Application wrappers configuration tool for GNUstep This provides an easy way to create GNUstep app-wrappers of non-GNUstep applications. It is the most useful in conjunction with GWorkspace environment. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc Locale: LANG=POSIX, LC_CTYPE=POSIX pgpfVjl5VNIri.pgp Description: PGP signature
Re: /var/log on Debian systems
On Tue, 14 Dec 2004 19:55:59 +0100, Martin Schulze [EMAIL PROTECTED] wrote: What's so private in these log files that they should not world readable? A local user can look at usage patterns and formulate a plan of attack. A badly written CGI can leak server data across the public Internet. It gets worse - shall I continue? -- WC -Sx- Jones http://insecurity.org/
Re: Right Way to make a configuration package
Ola Lundqvist [EMAIL PROTECTED] writes: Hello I assume that my answer is a bit late as you wrote this in october. I have written a package, dysyco that do similar things to what you want. Take a look. I may have misunderstood you. // Ola On Thu, Oct 14, 2004 at 03:37:27PM -0400, Mark Roach wrote: I am working on creating a package for UserLinux which will configure several packages with sensible defaults for an authentication server. At the moment, that means samba, slapd, pam and nss, but will also include heimdal later on. My naive question is: is there currently any mechanism for forcing the user to configure package x from within package y, and/or for reconfiguring one package based on reconfiguring another? Actually that is forbidden by policy. A package may not change another packages conffiles. If that can be overlooked for a package which sole purpose is to overwrite configuration for other packages is a question you have to ask yourself. MfG Goswin
Re: Right Way to make a configuration package
[Goswin von Brederlow] Actually that is forbidden by policy. A package may not change another packages conffiles. Actually, the policy forbids the _maintainer scripts_ of a package to change another packages conffiles. It does not forbid a script in a package to change another packages conffiles. I'm not saying it is smart to change packages conffiles using a script in another package. It isn't. But as far as I know it isn't forbidden by policy. :) If that can be overlooked for a package which sole purpose is to overwrite configuration for other packages is a question you have to ask yourself. It can be done if the package A only provide the means to do it, and don't overwrite the configuration of package B when package A is installed. Providing a base-config fragment to be executed during first install is a common way to do it.
Re: Linux Core Consortium
On Tue, Dec 14, 2004 at 08:34:17AM -0500, Ian Murdock wrote: On Fri, 2004-12-10 at 00:44 +0100, Christoph Hellwig wrote: Besides that the LCC sounds like an extraordinarily bad idea, passing around binaries only makes sense if you can't easily reproduce them from the source (which I defined very broadly to include all build scripts and depencies), and that case is the worst possible thing a distribution can get into. The LCC core will be fully reproducible from source. You may (and probably will) lose any certifications if you do that, for the same reason that the distros reproduced from the Red Hat Enterprise Linux source (e.g., White Box Linux) lose them. But it won't be take it or leave it. If reproducing from source and/or modifying the core packages is more important to you than the certifications, you will be able to do that. So again what do you gain by distributing binaries if their reproducible from source?
Re: If you really want Free firmware...
Ron Johnson wrote: The *price* of product has *nothing* to do with how much it *cost* to create. In a purely competitive market the price of goods would approach their cost. The system of "intellectual property" is a barrier that prevents certain goods from becoming commodities. There are other mechanisms, such as branding, that create perceptual rather than legal barriers. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
woodworking website...
Hello,
I am offering custom website upgrades for $99 flat fee (*up to 8
pages) when you switch to my hosting service.
Hosting at $30/month includes
email
forms
scripts
stats
databases
photogalleries
free updates
more
You will CAPTURE more business with a SLICK website. Please check out
some of my work, clients and references, and also the style that your
webpresence could/should have:
http://www.pelhamplastics.com {http://www.pelhamplastics.com}
http://www.i2tlds.com {http://www.i2tlds.com}
http://www.jttheodore.com {http://www.jttheodore.com}
http://www.strafford.com {http://www.strafford.com}
http://www.amking.com {http://www.amking.com}
http://www.oceanrentalproperties.com
{http://www.oceanrentalproperties.com}
If it's time for a website facelift, call me and i will take care of
everything you need to switch to my service.
TOLL FREE 1-888-682-2074
I also have guaranteed top 10 Yahoo/MSN placement
(the guarantee is that you pay NOTHING unless results are showing).
Thank you.
Chris Taylor
Whitemountain Webarts
25 Bert St. Hooksett, NH 03106
http://www.wmwebarts.com {http://www.wmwebarts.com}
--
Powered by PHPlist, www.phplist.com --
Re: If you really want Free firmware...
On Tue, 2004-12-14 at 14:42 -0800, Bruce Perens wrote: Ron Johnson wrote: The *price* of product has *nothing* to do with how much it *cost* to create. In a purely competitive market the price of goods would approach their cost. The system of intellectual property is a barrier that prevents certain goods from becoming commodities. There are other mechanisms, such as branding, that create perceptual rather than legal barriers. If consumers have adequate knowledge of all goods and services, then yes, the price of goods would approach their cost. Yet, even if there were no IP issues, consumers still wouldn't have adequate knowledge of all goods and services. Do you have time to research *every* good and service that you and your S.O. purchase? Neither do we. Branding is what Sales Marketing (which I already mentioned) do. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. His mother should have thrown him away and kept the stork. Mae West signature.asc Description: This is a digitally signed message part
Re: Bug#285681: ITP: libxbox-dev -- Libxbox-dev provides the headers for libxbox0 and the libxbox.so symlink
First, please don't send mails to the BTS with a local address. Le mardi 14 décembre 2004 à 20:06 +, [EMAIL PROTECTED] a écrit : Package: wnpp Version: N/A; reported 2004-12-14 Severity: wishlist * Package name: libxbox-dev Version : 0.1.0 Upstream Author : David Pye [EMAIL PROTECTED] * URL : http://www.xbox-linux.org * License : GPL Description : Libxbox-dev provides the headers for libxbox0 and the libxbox.so symlink As title. See the recent ITP for libxbox0 for more information about what libxbox provides. (Bug#285617) Why do you need to make it a separate source package? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Bug#285681: ITP: libxbox-dev -- Libxbox-dev provides the headers for libxbox0 and the libxbox.so symlink
Hi, On Tuesday 14 December 2004 23:35, Josselin Mouette wrote: First, please don't send mails to the BTS with a local address. Le mardi 14 décembre 2004 à 20:06 +, [EMAIL PROTECTED] a Yes, how I cursed that one, once I realised it had got out. I sent three ITPs, and one made it out wrong. I knew some one would spot it, nonetheless ;) snip * Package name: libxbox-dev Version : 0.1.0 Upstream Author : David Pye [EMAIL PROTECTED] * URL : http://www.xbox-linux.org * License : GPL Description : Libxbox-dev provides the headers for libxbox0 and the libxbox.so symlink snip again Why do you need to make it a separate source package? Ah. So that's what I did wrong, maybe. The two packages build from the same source. Does that mean a single ITP is necessary? I have not raised ITPs before, so was not sure exactly. One question this raises in my mind: suppose I have a single source tar.gz, that I want to build into four debian binary packages, with different names (obviously). If this should require only one ITP, which package name should the ITP be made for? David -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s-: a-- C++ UL P L+++ E--- W++ N+ o+ K- w--- O M V- PS+ PE+ Y+ PGP t 5- X+ R- tv+ b+ DI++ D+ G+ e++ h--- r++ y++ --END GEEK CODE BLOCK--
Re: Bug#285681: ITP: libxbox-dev -- Libxbox-dev provides the headers for libxbox0 and the libxbox.so symlink
On Tuesday 14 December 2004 23:35, Josselin Mouette wrote: Why do you need to make it a separate source package? No, no, ignore my last email. I 'get it' now. It for some reason escaped my notice that the ITP needed only to be raised against the source package, and not the multiple binary packages it would spawn. D'oh. Sorry, I'll close this spurious ITP. David -- -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s-: a-- C++ UL P L+++ E--- W++ N+ o+ K- w--- O M V- PS+ PE+ Y+ PGP t 5- X+ R- tv+ b+ DI++ D+ G+ e++ h--- r++ y++ --END GEEK CODE BLOCK--
Re: Bug#285681: ITP: libxbox-dev -- Libxbox-dev provides the headers for libxbox0 and the libxbox.so symlink
On Tue, Dec 14, 2004 at 11:49:55PM +, David Pye wrote: Ah. So that's what I did wrong, maybe. The two packages build from the same source. Does that mean a single ITP is necessary? I have not raised ITPs before, so was not sure exactly. That's it. With a few rare exceptions (that don't apply here), we file exactly one ITP per source. One question this raises in my mind: suppose I have a single source tar.gz, that I want to build into four debian binary packages, with different names (obviously). If this should require only one ITP, which package name should the ITP be made for? Debian source packages also have a name. We normaly use that for the ITP. For simple 1:1 packages the source name is usualy the same as the binary name, but that's absolutely not a requisite. For example, the xfree86 source package provides a gazillon of binary packages but there's no xfree86 binary package as such (And soon won't be any xfree86 at all anyway ;). -- .''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S) : :' : `. `'http://www.debian.org/ports/kfreebsd-gnu `-
Re: binary NMUs and version numbers
Goswin von Brederlow wrote: Anthony Towns aj@azure.humbug.org.au writes: Goswin von Brederlow wrote: 1.rc 1.rc2 1.rc+b1 1.2-1~beta 1.2-1~beta2 1.2-1~beta+b1 1.2~beta-1 1.2~beta-1+b1 1.2~beta2-1 Adding the implicit '0' that dpkg assumes on versions ending in alpha chars would solve both cases: That is, 1.2-1~beta == 1.2-1~beta0 1.2-1~beta0+b1 1.2-1~beta1 That'd mean REJECTing uploads whose versions match [^0-9]+[a-z][0-9]+$ presumably. ^ ^ First + is literal, second + is one or more. One should be escaped. Which one? Depends whether it's a regexp or an eregexp... :-/ No, why? Because 1.2-1~beta+b1 1.2-1~beta1. That regexp is rejecting uploads where there *isn't* a number before the +. '[^0-9]\+[a-z0-9]+$' (as an eregexp) might be better. A version matching [a-z]$ has an implicit trailing 0 in dpkg version terms. Not really; it just compares equally to the same string with any number of trailing zeroes. Versions without an epoch don't have an epoch, but they do compare equally to the same version with an epoch of zero. Try: ] dpkg --compare-versions 'beta' eq '00:beta-000'; echo $? for those playing along at home. Or ] dpkg --compare-versions '10' eq '010'; echo $? When adding a + that implicit 0 must be added explicitly to preserve the ordering. With that rule there is no reason to rstrict the version to exclude [a-z]$. Err, the above regexp didn't match anything ending in a-z, no matter how you construe it... Cheers, aj
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.
Re: dselect survey
Marcelo E. Magallon [EMAIL PROTECTED] writes: The other problem with aptitude is touted as a design feature: it tends to be all-or-nothing. Either you use it always or you don't (automatic removal thingie). This becomes a problem when multiple persons use different interfaces for adding and removing packages to the system. You exaggerate. Support for this feature -- one the coolest things about aptitude -- should clearly be added to other clients too[*], but until that happens, it's not like the system explodes if you also use other clients. The occasional use of other clients causes only slight degradation in the quality of the automatically added annotations, which is hardly something serious. [Of course with aptitude around, you'll almost never want to use apt-get anyway because aptitude implements essentially the same command-line interface.] [*] and you can hardly blame aptitude because other clients are slow on the uptake! If anything this situation is mostly an argument for not using those other clients... -Miles -- [|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that will make every christian in the world foamm at the mouth? [iddt] nurg, that's the goal
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: Re: Linux Core Consortium
Joey Hess wrote (on debian-devel): My experience as a developer who's tried to write an app to use the LSB (only the init script interface) is that it's poorly enough specified and/or implemented divergently within the spec to the point that I had to test my implementation on every LSB distriution I wanted to support, and might as well have written distro-specific code in the first place. I got pointed here, I'm not on debian-devel, so I'm coming a little late to the thread. It's kind of ironic: the LSB doesn't want to invent new stuff, just standardize existing best practice. One of the VERY few places where we were forced to do something exactly because there was so much divergence was this initscript area, and of course it's been the source of a number of problems completely out of proportion to the size of the topic, reinforcing why we really don't want to be in the invent business - I guess we'll leave that to HP :-) Unfortunately, while we got spec contribution in this area, we didn't get matching code contributions: tests OR sample implementation. It sure would be helpful to get either or both, and also helpful would be bugreports at bugs.linuxbase.org when it doesn't work right. The takeaway: if the LSB is going to succeed as the community standard for the Linux core, we need as much of the community as possible to let us know how it's working, and when it's not. -- mats wichmann P.S.: turnabout being fair play, I think lsb-related activities have turned up a disproportionate number of issues in alien and the now-orphaned rpm... sorry, Joey!
Re: binary NMUs and version numbers
Anthony Towns aj@azure.humbug.org.au writes: Goswin von Brederlow wrote: Anthony Towns aj@azure.humbug.org.au writes: That'd mean REJECTing uploads whose versions match [^0-9]+[a-z][0-9]+$ presumably. ^ ^ First + is literal, second + is one or more. One should be escaped. Which one? Depends whether it's a regexp or an eregexp... :-/ No, why? Because 1.2-1~beta+b1 1.2-1~beta1. That regexp is rejecting uploads where there *isn't* a number before the +. '[^0-9]\+[a-z0-9]+$' (as an eregexp) might be better. Ahh, you mean reject the +b1 and not the source upload. Got you. MfG Goswin
Help needed with debconf
Hi list, I need some help with debconf, especially for the config and postinst scripts. I tried to craft my own ones for my font package and when I try to install the package the postinst script exits with status 10. What does this mean? Further more, the dialog I have created in config gets never displayed to the user... :( I have attached the config, templates and postinst files. Can someone help me to review them and find the mistakes? Thanks Arne -- Arne Gtje () [EMAIL PROTECTED] (Spam catcher. Address might change in future!) PGP/GnuPG key: 1024D/685D1E8C Fingerprint: 2056 F6B7 DEA8 B478 311F 1C34 6E9F D06E 685D 1E8C Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. config Description: application/shellscript postinst Description: application/shellscript Template: ttf-arphic-uming/variant Type: select Choices: Unicode, MBE, both Default: Unicode Description: Which font variant do you want to install? This font contains bopomofo extended glyphs, which are used to annotate chinese glyphs to show how the characters should be pronounced. These bopomofo extended glyphs are used for some minority languages, like Taiwanese and Hakka. They are mainly used in Taiwan. . There are two variants of these bopomofo extended glyphs in use, one which conformes to the Unicode standard, and one, called Modern Bopomofo Extensions (MBE), which aims to be easier to read and write. . The Unicode variant also contains the MBE variants encoded as TTF stylistic alternatives (SALT). As only few programs can support this feature, users who prefer to use the MBE glyphs should install the MBE variant instead of the Unicode one. . If you don't know what I'm talking about or don't intend to use those glyphs at all, choose Unicode. pgpHwabkxCsZ7.pgp Description: PGP signature
Re: If you really want Free firmware...
Kenneth Pronovici wrote: Aha, I see where you found this in my original note (although you didn't quote it). In that paragraph, thousands of dollars was just an example for illustration, although I chose the magnitude of the cost from one of the links Bruce posted (I recall seeing a $5400 fabrication cost listed on one of those pages). For small (50K gates) chips FPGAs are cost-effective and you never have to go to fab. We can put together a development system for 1M gates systems for about $500. I'm starting smaller than this, and am putting out a $20 device that makes embedded programming really easy for Free Software folks. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Accepted hylafax 1:4.2.0-16 (powerpc all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Dec 2004 16:53:10 +0100 Source: hylafax Binary: hylafax-doc hylafax-server hylafax-client Architecture: source all powerpc Version: 1:4.2.0-16 Distribution: unstable Urgency: medium Maintainer: Giuseppe Sacco [EMAIL PROTECTED] Changed-By: Giuseppe Sacco [EMAIL PROTECTED] Description: hylafax-client - Flexible client/server fax software - client utilities hylafax-doc - Flexible client/server fax software - HTML Documentation hylafax-server - Flexible client/server fax software - server daemons Changes: hylafax (1:4.2.0-16) unstable; urgency=medium . * Removed dependency on c++compiler since compiler is provided by build-essential (Thanks to Francesco P. Lovergine) * Added an example script for archiving cover pages, as described in http://bugs.hylafax.org/bugzilla/show_bug.cgi?id=603 * Urgency medium in onder to enter sarge Files: 5cf0ba4f16c56a7bb9bcabe25751ede8 776 comm extra hylafax_4.2.0-16.dsc ef99a75a64a9c3c7a773e140b9e2cc35 64996 comm extra hylafax_4.2.0-16.diff.gz c19937233920ba72e6deca87323dafe9 809438 comm extra hylafax-server_4.2.0-16_powerpc.deb 58ef98f352cafb02b879648af1bee4f2 353842 comm extra hylafax-client_4.2.0-16_powerpc.deb 8bdc8e6464fe9613b795d892fdfbfbcd 358400 doc extra hylafax-doc_4.2.0-16_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBvxNqIgfFlOyXCJ0RAtBmAJ9CbT6HHS7LwDaiZHPbLATzHhc3rwCeLPka jMSiLLBnTGxBszLJ3WmzaXM= =B2gJ -END PGP SIGNATURE- Accepted: hylafax-client_4.2.0-16_powerpc.deb to pool/main/h/hylafax/hylafax-client_4.2.0-16_powerpc.deb hylafax-doc_4.2.0-16_all.deb to pool/main/h/hylafax/hylafax-doc_4.2.0-16_all.deb hylafax-server_4.2.0-16_powerpc.deb to pool/main/h/hylafax/hylafax-server_4.2.0-16_powerpc.deb hylafax_4.2.0-16.diff.gz to pool/main/h/hylafax/hylafax_4.2.0-16.diff.gz hylafax_4.2.0-16.dsc to pool/main/h/hylafax/hylafax_4.2.0-16.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xzgv 0.8-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 13 Dec 2004 12:23:47 -0500 Source: xzgv Binary: xzgv Architecture: source i386 Version: 0.8-3 Distribution: unstable Urgency: high Maintainer: Theodore Y. Ts'o [EMAIL PROTECTED] Changed-By: Theodore Y. Ts'o [EMAIL PROTECTED] Description: xzgv - Picture viewer for X with a thumbnail-based selector Closes: 284127 Changes: xzgv (0.8-3) unstable; urgency=high . * Applied security fix to prevent buffer overruns from: http://www.svgalib.org/rus/zgv/zgv-5.8-integer-overflow-fix.diff Addresses vulnerability: CAN-2004-0994 (Closes: #284127) Files: 4b682d415e97e5b45620b7aaa9ecf1e0 628 graphics optional xzgv_0.8-3.dsc 5371d3394c641765514fda8841370884 8188 graphics optional xzgv_0.8-3.diff.gz 8bc13671f8c70ccc6ec2f72f97081c85 194262 graphics optional xzgv_0.8-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBvxQS7To545NnTEARAt2vAJwJl8Fpm2yIinfDyxc4lAAoctRo0ACggvQe DG/8C2y9jj/0H4aXfTdnqwo= =Yt1q -END PGP SIGNATURE- Accepted: xzgv_0.8-3.diff.gz to pool/main/x/xzgv/xzgv_0.8-3.diff.gz xzgv_0.8-3.dsc to pool/main/x/xzgv/xzgv_0.8-3.dsc xzgv_0.8-3_i386.deb to pool/main/x/xzgv/xzgv_0.8-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ocamlgsl 0.3.5-1 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 8 Dec 2004 00:51:07 +0100 Source: ocamlgsl Binary: libocamlgsl-ocaml-dev libocamlgsl-ocaml Architecture: source powerpc Version: 0.3.5-1 Distribution: unstable Urgency: low Maintainer: Sylvain Le Gall [EMAIL PROTECTED] Changed-By: Sylvain Le Gall [EMAIL PROTECTED] Description: libocamlgsl-ocaml - GNU scientific library for OCaml libocamlgsl-ocaml-dev - GNU scientific library for OCaml Changes: ocamlgsl (0.3.5-1) unstable; urgency=low . * New upstream release Files: e586c708ce320544c7073d492bddee52 739 devel optional ocamlgsl_0.3.5-1.dsc a7b74d3c01315c25aae4446ad89733a9 212783 devel optional ocamlgsl_0.3.5.orig.tar.gz b908dc35a0a7d110565f81affa929c04 3230 devel optional ocamlgsl_0.3.5-1.diff.gz 556823c72bcee3684023815955020501 500152 libdevel optional libocamlgsl-ocaml-dev_0.3.5-1_powerpc.deb 1d1e9fd792b63f2e39645d0f2f9c9459 79970 libs optional libocamlgsl-ocaml_0.3.5-1_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBvwU62WTeT3CRQaQRAm2dAJ9f7oo1+Zg+TH+ehIdkNfURkeE/AQCgnU1O tBPF11EICf7h9w8ID6UNyRI= =Eetl -END PGP SIGNATURE- Accepted: libocamlgsl-ocaml-dev_0.3.5-1_powerpc.deb to pool/main/o/ocamlgsl/libocamlgsl-ocaml-dev_0.3.5-1_powerpc.deb libocamlgsl-ocaml_0.3.5-1_powerpc.deb to pool/main/o/ocamlgsl/libocamlgsl-ocaml_0.3.5-1_powerpc.deb ocamlgsl_0.3.5-1.diff.gz to pool/main/o/ocamlgsl/ocamlgsl_0.3.5-1.diff.gz ocamlgsl_0.3.5-1.dsc to pool/main/o/ocamlgsl/ocamlgsl_0.3.5-1.dsc ocamlgsl_0.3.5.orig.tar.gz to pool/main/o/ocamlgsl/ocamlgsl_0.3.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ocaml-fileutils 0.3.0-3 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 13 Dec 2004 23:55:32 +0100 Source: ocaml-fileutils Binary: libfileutils-ocaml-dev Architecture: source powerpc Version: 0.3.0-3 Distribution: unstable Urgency: low Maintainer: Sylvain Le Gall [EMAIL PROTECTED] Changed-By: Sylvain Le Gall [EMAIL PROTECTED] Description: libfileutils-ocaml-dev - File manipulation for OCaml Changes: ocaml-fileutils (0.3.0-3) unstable; urgency=low . * Rebuild for binary compatiblity Files: 553ff09d083cd8c3bb0829814ebf0f98 658 libdevel optional ocaml-fileutils_0.3.0-3.dsc f3a30da47f5514e1c230aab185dedba9 2824 libdevel optional ocaml-fileutils_0.3.0-3.diff.gz 7c6e45866a87d331819e1a53ee157997 152564 libdevel optional libfileutils-ocaml-dev_0.3.0-3_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBvwZ/2WTeT3CRQaQRAg8yAJ0ctEj4gO/6+OaUrkjrzLFuI2yTBACeJz4K +uEI7s+/iTfiYDMxzof/sKE= =sMxp -END PGP SIGNATURE- Accepted: libfileutils-ocaml-dev_0.3.0-3_powerpc.deb to pool/main/o/ocaml-fileutils/libfileutils-ocaml-dev_0.3.0-3_powerpc.deb ocaml-fileutils_0.3.0-3.diff.gz to pool/main/o/ocaml-fileutils/ocaml-fileutils_0.3.0-3.diff.gz ocaml-fileutils_0.3.0-3.dsc to pool/main/o/ocaml-fileutils/ocaml-fileutils_0.3.0-3.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xmail 1.20-5 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 10 Dec 2004 00:42:06 +0200 Source: xmail Binary: xmail xmail-doc Architecture: source i386 all Version: 1.20-5 Distribution: unstable Urgency: low Maintainer: Radu Spineanu [EMAIL PROTECTED] Changed-By: Radu Spineanu [EMAIL PROTECTED] Description: xmail - Advanced, fast and reliable ESMTP/POP3 mail server xmail-doc - Documentation for xmail Closes: 268066 269008 284161 Changes: xmail (1.20-5) unstable; urgency=low . * Updated French translation (closes: #268066, #284161) * Added Japanese translation. Thanks to Hideki Yamane (closes: #269008) Files: d154f207523645d4fb3b224d48f09492 645 mail extra xmail_1.20-5.dsc 4f8e0fb849d3573a33908d6c8b3a51c5 25391 mail extra xmail_1.20-5.diff.gz 3ad479f22b41ced22e703a8c2951dc3b 160320 mail extra xmail-doc_1.20-5_all.deb 0c078e6f98638a479363a4fcf7d640e9 210592 mail extra xmail_1.20-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBvwUCpFNRmenyx0cRAg+KAJ9NeVIwqkEQpqAc6pYhvosZfwSmggCgxyfi a7XtLpOJ0gBvGHzuZuSXIPk= =3DGX -END PGP SIGNATURE- Accepted: xmail-doc_1.20-5_all.deb to pool/main/x/xmail/xmail-doc_1.20-5_all.deb xmail_1.20-5.diff.gz to pool/main/x/xmail/xmail_1.20-5.diff.gz xmail_1.20-5.dsc to pool/main/x/xmail/xmail_1.20-5.dsc xmail_1.20-5_i386.deb to pool/main/x/xmail/xmail_1.20-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted logjam 4.4.0-6 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Dec 2004 11:14:17 -0500 Source: logjam Binary: logjam-xmms logjam Architecture: source i386 Version: 4.4.0-6 Distribution: unstable Urgency: low Maintainer: Ari Pollak [EMAIL PROTECTED] Changed-By: Ari Pollak [EMAIL PROTECTED] Description: logjam - Client for LiveJournal-based sites logjam-xmms - Command-line XMMS song title retriever Closes: 285638 Changes: logjam (4.4.0-6) unstable; urgency=low . * Fix configure script to properly build with curl support (Closes: #285638) Files: 822f73be2deb9eeda19f63067eaba04f 665 net optional logjam_4.4.0-6.dsc 504ee3623eaf24c63ec4735649cbfc42 28911 net optional logjam_4.4.0-6.diff.gz 8c305545683156aab29d554693528156 288556 net optional logjam_4.4.0-6_i386.deb 190cf4dea6d079c5db091bbd82177425 30722 net optional logjam-xmms_4.4.0-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBvxKtwO+u47cOQDsRAqtsAJ0TQlSOA+HUzDOdQAz9GyPW5ahqvgCgnE6K ixdGjImMyXuyaYI70w4kxSs= =9Ez3 -END PGP SIGNATURE- Accepted: logjam-xmms_4.4.0-6_i386.deb to pool/main/l/logjam/logjam-xmms_4.4.0-6_i386.deb logjam_4.4.0-6.diff.gz to pool/main/l/logjam/logjam_4.4.0-6.diff.gz logjam_4.4.0-6.dsc to pool/main/l/logjam/logjam_4.4.0-6.dsc logjam_4.4.0-6_i386.deb to pool/main/l/logjam/logjam_4.4.0-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted beep-media-player 0.9.7-1 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 13 Dec 2004 23:31:43 +0100 Source: beep-media-player Binary: beep-media-player-dev beep-media-player Architecture: source powerpc Version: 0.9.7-1 Distribution: unstable Urgency: low Maintainer: Michiel Sikkes [EMAIL PROTECTED] Changed-By: Michiel Sikkes [EMAIL PROTECTED] Description: beep-media-player - Versatile audio player that supports Winamp skins beep-media-player-dev - Beep Media Player development static library and header files Closes: 272876 281080 282016 284355 Changes: beep-media-player (0.9.7-1) unstable; urgency=low . * New upstream release. - Fixes MIME-type entries (Closes: #281080) - Fixes crash on long dirname in file chooser (Closes: #284355) - bmp-alarm plugin can now be compiled (Closes: #282016) - GNOME support disabled since it's experimental (Closes: #272876) Files: 2bd94de81b3a1fca41dec133f6d3ee53 789 sound optional beep-media-player_0.9.7-1.dsc 624dfb79c5797411e190b5f651c33ee9 2053945 sound optional beep-media-player_0.9.7.orig.tar.gz 46e6a8a960023494ede7478568c06ca7 10739 sound optional beep-media-player_0.9.7-1.diff.gz e85a8a861d6524970a8a2a9855864f74 940042 sound optional beep-media-player_0.9.7-1_powerpc.deb 9497fad026b1332930a5d9f216cf7610 102630 devel optional beep-media-player-dev_0.9.7-1_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBvyeAJBBhylAGQYERAhN/AKCZcH5FwsPV9xjrnFaJpY9IinxJ+ACfQYzu Bxtdr087hSqj+V23tOjQork= =4erO -END PGP SIGNATURE- Accepted: beep-media-player-dev_0.9.7-1_powerpc.deb to pool/main/b/beep-media-player/beep-media-player-dev_0.9.7-1_powerpc.deb beep-media-player_0.9.7-1.diff.gz to pool/main/b/beep-media-player/beep-media-player_0.9.7-1.diff.gz beep-media-player_0.9.7-1.dsc to pool/main/b/beep-media-player/beep-media-player_0.9.7-1.dsc beep-media-player_0.9.7-1_powerpc.deb to pool/main/b/beep-media-player/beep-media-player_0.9.7-1_powerpc.deb beep-media-player_0.9.7.orig.tar.gz to pool/main/b/beep-media-player/beep-media-player_0.9.7.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted base-files 3.1.1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Dec 2004 19:06:00 +0100 Source: base-files Binary: base-files Architecture: source i386 Version: 3.1.1 Distribution: unstable Urgency: low Maintainer: Santiago Vila [EMAIL PROTECTED] Changed-By: Santiago Vila [EMAIL PROTECTED] Description: base-files - Debian base system miscellaneous files Changes: base-files (3.1.1) unstable; urgency=low . * The file /etc/profile is not a conffile anymore. Instead, it is created by postinst in the very first base-files install, made by debootstrap. * Accordingly, removed bash from Replaces field. Files: 75e5e93c457dd2f6bc352795b0b3d1f9 464 base required base-files_3.1.1.dsc 3c68d2bdd44fbd12c3273e47482ed9df 32485 base required base-files_3.1.1.tar.gz f365814ad495871a54412accafd447da 34154 base required base-files_3.1.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBvyvWd9Uuvj7yPNYRAgIlAJ9fFYbiGRs919notz/uuZ6oN2jQpwCgopZ5 6O+p6sUw1Jg4z1OYLitji3c= =D6Mv -END PGP SIGNATURE- Accepted: base-files_3.1.1.dsc to pool/main/b/base-files/base-files_3.1.1.dsc base-files_3.1.1.tar.gz to pool/main/b/base-files/base-files_3.1.1.tar.gz base-files_3.1.1_i386.deb to pool/main/b/base-files/base-files_3.1.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gtk-gnutella 0.95-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Wed, 15 Dec 2004 04:45:08 +1100 Source: gtk-gnutella Binary: gtk-gnutella Architecture: source i386 Version: 0.95-2 Distribution: unstable Urgency: low Maintainer: Anand Kumria [EMAIL PROTECTED] Changed-By: Anand Kumria [EMAIL PROTECTED] Description: gtk-gnutella - shares files in a peer to peer network Closes: 205196 271312 285383 Changes: gtk-gnutella (0.95-2) unstable; urgency=low . * Workaround for G_BREAKPOINT not including the right headers on various platforms. (Closes: #285383) * The Purge button has been moved to the bottom of the 'File' (previously the FileInfo) tab. It being inaccessible should now longer be an issue. (Closes: #205196) * The Download section has been rearranged into three tabs (Active, File and Queue) with Queue replacing 'inactive sources' so you can't cause 'show settings' to futz the UI in this screen anymore. (Closes: #271312) However you still can futz it in other screens. Files: d81927b07142106ae1cc69a226fb7c25 811 net optional gtk-gnutella_0.95-2.dsc 08c8e5bded7eb08162e8fc02e8f2c4d2 105904 net optional gtk-gnutella_0.95-2.diff.gz 6276d8d82213fb2bbd96c4253ca89ea1 1630786 net optional gtk-gnutella_0.95-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQCVAwUBQb8wBWRmcAD8BdppAQFI4wP/SQbSzNBzus1NxS6BLGpJZKziszPrI5Yn b+4lVx/1oUGakfxJPXWNTQm4FGI6tpFjtbeEpuKPTlBdeMDzMEIZnpERf5bFrr2K yni9pO5/n+smztAVQb7Y4QwmkDtajrd7O5QtHKINd4RW3hq1noMFpwNzesTe73/g gwbWHcZKxGg= =da9e -END PGP SIGNATURE- Accepted: gtk-gnutella_0.95-2.diff.gz to pool/main/g/gtk-gnutella/gtk-gnutella_0.95-2.diff.gz gtk-gnutella_0.95-2.dsc to pool/main/g/gtk-gnutella/gtk-gnutella_0.95-2.dsc gtk-gnutella_0.95-2_i386.deb to pool/main/g/gtk-gnutella/gtk-gnutella_0.95-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted db4.3 4.3.21-11 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Dec 2004 14:28:16 -0500 Source: db4.3 Binary: libdb4.3++-dev libdb4.3 libdb4.3-java libdb4.3-dev libdb4.3-tcl libdb4.3++ db4.3-util db4.3-doc Architecture: source all Version: 4.3.21-11 Distribution: unstable Urgency: medium Maintainer: Debian Berkeley DB Maintainers [EMAIL PROTECTED] Changed-By: Clint Adams [EMAIL PROTECTED] Description: db4.3-doc - Berkeley v4.3 Database Documentation [html] db4.3-util - Berkeley v4.3 Database Utilities libdb4.3 - Berkeley v4.3 Database Libraries [runtime] libdb4.3++ - Berkeley v4.3 Database Libraries for C++ [runtime] libdb4.3++-dev - Berkeley v4.3 Database Libraries for C++ [development] libdb4.3-dev - Berkeley v4.3 Database Libraries [development] libdb4.3-tcl - Berkeley v4.3 Database Libraries for TCL [module] Changes: db4.3 (4.3.21-11) unstable; urgency=medium . * Revert powerpc mutexes to the version from db4.2, which actually works. Files: fc17795f309dfef00573ba4a63f4368b 836 libs standard db4.3_4.3.21-11.dsc 79af70628cd3775b4503deafa6ff2c88 75161 libs standard db4.3_4.3.21-11.diff.gz e67b64ae6692b4b9bb6d51518b2341c6 2970588 libs optional db4.3-doc_4.3.21-11_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Debian! iD8DBQFBv0b65m0u66uWM3ARAobNAKCm0uJvHS59LSzeIRwM1siTN7i7CQCfQS+1 CfqVQb5I046LcLomTKfL0pg= =JgRt -END PGP SIGNATURE- Accepted: db4.3-doc_4.3.21-11_all.deb to pool/main/d/db4.3/db4.3-doc_4.3.21-11_all.deb db4.3_4.3.21-11.diff.gz to pool/main/d/db4.3/db4.3_4.3.21-11.diff.gz db4.3_4.3.21-11.dsc to pool/main/d/db4.3/db4.3_4.3.21-11.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted asn1-mode 2.7-4 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Dec 2004 20:23:23 + Source: asn1-mode Binary: asn1-mode Architecture: source all Version: 2.7-4 Distribution: unstable Urgency: low Maintainer: W. Borgert [EMAIL PROTECTED] Changed-By: W. Borgert [EMAIL PROTECTED] Description: asn1-mode - Emacs mode for editing ASN.1 specification files Closes: 232745 Changes: asn1-mode (2.7-4) unstable; urgency=low . * Remove dependency on Emacs 21 (closes: #232745), thanks to Martin Michlmayr [EMAIL PROTECTED]. Files: 7c25a6836a071bb7974b4cd0dd1a38ae 580 editors optional asn1-mode_2.7-4.dsc 552b8db0813f2df231b6e85044d30349 2982 editors optional asn1-mode_2.7-4.diff.gz f47e84e0e8a9736b070de67ce5aeb7c1 95458 editors optional asn1-mode_2.7-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBv0yd+xM0OFfj6IgRAp66AKCVM2XNdhEZNhNMSaNIqtptY3Hx3wCcCh1Z dvuURbjdNmIN7zJ4icz/els= =ryK7 -END PGP SIGNATURE- Accepted: asn1-mode_2.7-4.diff.gz to pool/main/a/asn1-mode/asn1-mode_2.7-4.diff.gz asn1-mode_2.7-4.dsc to pool/main/a/asn1-mode/asn1-mode_2.7-4.dsc asn1-mode_2.7-4_all.deb to pool/main/a/asn1-mode/asn1-mode_2.7-4_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mozilla-firefox-locale-tr 1.0 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Dec 2004 16:53:48 +0200 Source: mozilla-firefox-locale-tr Binary: mozilla-firefox-locale-tr Architecture: source all Version: 1.0 Distribution: unstable Urgency: critical Maintainer: Recai Oktaş [EMAIL PROTECTED] Changed-By: Recai Oktaş [EMAIL PROTECTED] Description: mozilla-firefox-locale-tr - Mozilla Firefox Turkish Language/Region Package Changes: mozilla-firefox-locale-tr (1.0) unstable; urgency=critical . * New upstream. * Bump to new policy. * Rewrite the build system for 1.0 based on -locale-it package. * Recode the maintainer name as UTF-8. * Urgency critical to get Firefox 1.0 into Sarge. Files: 510d5189c7e01fa3e0da9df6a314b969 543 web optional mozilla-firefox-locale-tr_1.0.dsc 84838e20e8d10b0b54b1e6ce8c7dc5e5 85767 web optional mozilla-firefox-locale-tr_1.0.tar.gz 41080004ad9d481859ca673dde5e21bf 85446 web optional mozilla-firefox-locale-tr_1.0_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBv2eWAJWfo5xHjUkRAjmUAJ9rTnfCcgqVxO0RG/T3o9hIynOr5gCfVqNp VsEGkce+DnV7juoYE1fADsA= =5ZlI -END PGP SIGNATURE- Accepted: mozilla-firefox-locale-tr_1.0.dsc to pool/main/m/mozilla-firefox-locale-tr/mozilla-firefox-locale-tr_1.0.dsc mozilla-firefox-locale-tr_1.0.tar.gz to pool/main/m/mozilla-firefox-locale-tr/mozilla-firefox-locale-tr_1.0.tar.gz mozilla-firefox-locale-tr_1.0_all.deb to pool/main/m/mozilla-firefox-locale-tr/mozilla-firefox-locale-tr_1.0_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted fet 3.9.20-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 9 Dec 2004 01:22:50 +0200 Source: fet Binary: fet Architecture: source i386 Version: 3.9.20-1 Distribution: unstable Urgency: low Maintainer: Radu Spineanu [EMAIL PROTECTED] Changed-By: Radu Spineanu [EMAIL PROTECTED] Description: fet- Timetable generator Closes: 284433 Changes: fet (3.9.20-1) unstable; urgency=low . * New upstream release (closes: #284433) Files: 39c3c63ce70e1b613b19aeed168cadb3 570 utils optional fet_3.9.20-1.dsc 05e25309729a5c856ba3f54f68aeaa81 302096 utils optional fet_3.9.20.orig.tar.gz 17ab1d9e47ab1fb37b668d3b7264cbf0 2204 utils optional fet_3.9.20-1.diff.gz 736e7c277bc9b56319c093fa4eba8b22 541430 utils optional fet_3.9.20-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBv2eFpFNRmenyx0cRAgZ8AJwOcuzFZZvygwgGYL30yStjNz8ikwCg1PTu vaiHLUtk8q1eqLqMQZwn14k= =lAvC -END PGP SIGNATURE- Accepted: fet_3.9.20-1.diff.gz to pool/main/f/fet/fet_3.9.20-1.diff.gz fet_3.9.20-1.dsc to pool/main/f/fet/fet_3.9.20-1.dsc fet_3.9.20-1_i386.deb to pool/main/f/fet/fet_3.9.20-1_i386.deb fet_3.9.20.orig.tar.gz to pool/main/f/fet/fet_3.9.20.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xdu 3.0-12 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 13 Dec 2004 22:03:21 +0100 Source: xdu Binary: xdu Architecture: source i386 Version: 3.0-12 Distribution: unstable Urgency: low Maintainer: Remi Vanicat [EMAIL PROTECTED] Changed-By: Remi Vanicat [EMAIL PROTECTED] Description: xdu- display the output of du in an X window Closes: 280317 Changes: xdu (3.0-12) unstable; urgency=low . * really apply the malloc patch (closes: #280317) Files: bfa15d166d2ff6edb4eb84445e1a924e 579 utils optional xdu_3.0-12.dsc 4d50c6e7f63af9434b9a2810181307bb 4366 utils optional xdu_3.0-12.diff.gz 8c5ac470770e21ff9093a3d947ba5185 15402 utils optional xdu_3.0-12_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBvyKOsOGY15BXtdMRAqo4AJ9jRRthkMbzc14I64nOMmcHeX95GQCdGyiy IwYy9pW/jwP/XJ3Ub+wG55w= =BTMM -END PGP SIGNATURE- Accepted: xdu_3.0-12.diff.gz to pool/main/x/xdu/xdu_3.0-12.diff.gz xdu_3.0-12.dsc to pool/main/x/xdu/xdu_3.0-12.dsc xdu_3.0-12_i386.deb to pool/main/x/xdu/xdu_3.0-12_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted msc 1.1.0-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Dec 2004 20:05:45 + Source: msc Binary: msc Architecture: source all Version: 1.1.0-2 Distribution: unstable Urgency: low Maintainer: W. Borgert [EMAIL PROTECTED] Changed-By: W. Borgert [EMAIL PROTECTED] Description: msc- Generates simple ASCII message sequence charts Changes: msc (1.1.0-2) unstable; urgency=low . * Fixed some lintians. * Moved from subsection devel to graphics. * Using cdbs. Files: 34cb32f171335b60c59662fc95ff62c4 569 graphics optional msc_1.1.0-2.dsc da153f34a984a4665099d53b20d6df27 1076 graphics optional msc_1.1.0-2.diff.gz 8edfcf222a65a02f0d64858a3c2acc1d 6934 graphics optional msc_1.1.0-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBv0jK+xM0OFfj6IgRAgS7AJ9Reuoai7+dmQtO/iQsFre+eyBlQwCeOb5y xagVxnhYunY20ePqU1N0vKQ= =w+LD -END PGP SIGNATURE- Accepted: msc_1.1.0-2.diff.gz to pool/main/m/msc/msc_1.1.0-2.diff.gz msc_1.1.0-2.dsc to pool/main/m/msc/msc_1.1.0-2.dsc msc_1.1.0-2_all.deb to pool/main/m/msc/msc_1.1.0-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kvirc 2:2.1.3.1-2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Dec 2004 15:32:19 -0500 Source: kvirc Binary: kvirc-doc kvirc-dev kvirc-data kvirc Architecture: source i386 all Version: 2:2.1.3.1-2 Distribution: unstable Urgency: low Maintainer: Robin Verduijn [EMAIL PROTECTED] Changed-By: Robin Verduijn [EMAIL PROTECTED] Description: kvirc - Fully scriptable graphical IRC client with plugin support kvirc-data - Data files for KVIrc kvirc-dev - Development files for KVIrc kvirc-doc - Help files for KVIrc Changes: kvirc (2:2.1.3.1-2) unstable; urgency=low . * Change Recommends on xmms to a Suggests. * Rebuild against KDE 3.3.1 Files: b729c04ee6e9a8e59d6e51842c636f33 643 net optional kvirc_2.1.3.1-2.dsc fdbd06ae1776778cedcc5145d6e09547 30979 net optional kvirc_2.1.3.1-2.diff.gz a20282886aae35cd48868abbd6483ced 874718 net optional kvirc-data_2.1.3.1-2_all.deb df2f21bce746ca7ce7b16fccb4ecb5f8 209798 doc optional kvirc-doc_2.1.3.1-2_all.deb 4bae099fabcb750e1a03c244352f3449 1463470 net optional kvirc_2.1.3.1-2_i386.deb 18e9549e7e494192a8f059086989a556 258446 devel optional kvirc-dev_2.1.3.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBv10Ezog/I2psrrURAvZvAJ0Zt9rY+BbstWB9Z1eFKhwYih/zEgCfWi1t pp9jTFq7ckTo8bgcbtntBkE= =Uj9f -END PGP SIGNATURE- Accepted: kvirc-data_2.1.3.1-2_all.deb to pool/main/k/kvirc/kvirc-data_2.1.3.1-2_all.deb kvirc-dev_2.1.3.1-2_i386.deb to pool/main/k/kvirc/kvirc-dev_2.1.3.1-2_i386.deb kvirc-doc_2.1.3.1-2_all.deb to pool/main/k/kvirc/kvirc-doc_2.1.3.1-2_all.deb kvirc_2.1.3.1-2.diff.gz to pool/main/k/kvirc/kvirc_2.1.3.1-2.diff.gz kvirc_2.1.3.1-2.dsc to pool/main/k/kvirc/kvirc_2.1.3.1-2.dsc kvirc_2.1.3.1-2_i386.deb to pool/main/k/kvirc/kvirc_2.1.3.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted greylistd 0.6 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Dec 2004 12:35:49 -0800 Source: greylistd Binary: greylistd Architecture: source all Version: 0.6 Distribution: unstable Urgency: low Maintainer: Tor Slettnes [EMAIL PROTECTED] Changed-By: Tor Slettnes [EMAIL PROTECTED] Description: greylistd - Greylisting daemon for use with Exim 4 Closes: 267075 267221 267296 267314 267316 270814 272572 273089 Changes: greylistd (0.6) unstable; urgency=low . * Now uses DebConf for initial setup and configuration. * New utility greylistd-setup-exim4 adds/removes support for greylistd in Exim 4 configuration files; optionally invoked via DebConf. * Tries to detect ownership of MTA process, and set greylistd ownership accordingly, to circumvent problems with users who cannot read. Closes: #267075. * 'whitelist-hosts' moved from /etc/mail to /etc/greylistd. Closes: #267221. * 'whitelist-hosts' contains some text explaining syntax. Closes: #267314. * 'whitelist-hosts' contains warning about lookup failures. Closes: #270814. * Default/documented Exim 4 examples do not greylist authenticated clients. Closes: #272572. * Depend on Python version 2.3 or newer; also, program checks that we are running a supported version. Closes: #267296. * Greylist data is now saved at regular intervals, as specified in the configuration file (default is 300 seconds). File saves can also be triggerd with the save command. Closes: #267316. * The original (unhashed) greylist data is now retained in a separate file; a list command gives access to it. * Clean up (remove UNIX domain socket) after exceptions. * Init script supports 'reload' (saves greylist triplets). * restart command in init script sleeps for one second after killing old process, before starting new one. Closes: #273089. Files: 7e0a2f61e79526fdafef84d917e6c294 487 mail optional greylistd_0.6.dsc 05fdb8d304b67ec81b2012e78e966f29 31448 mail optional greylistd_0.6.tar.gz 2e94df6dd091be931bba50b785912186 34142 mail optional greylistd_0.6_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBv3O5nt4KtwvubPwRAivVAJ4xIxDN8nQK938mHfAmsQhrp2ECnQCfSNAw TkWZDRtIRGIDPV+4jMGj0SE= =yW0U -END PGP SIGNATURE- Accepted: greylistd_0.6.dsc to pool/main/g/greylistd/greylistd_0.6.dsc greylistd_0.6.tar.gz to pool/main/g/greylistd/greylistd_0.6.tar.gz greylistd_0.6_all.deb to pool/main/g/greylistd/greylistd_0.6_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kaffe 2:1.1.4.PRECVS6-1 (powerpc all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Dec 2004 15:48:51 +0100 Source: kaffe Binary: kaffe-dev kaffe-common jikes-kaffe kaffe-pthreads-profile kaffe-pthreads kaffe-doc kaffe kjc kaffe-jthreads Architecture: source all powerpc Version: 2:1.1.4.PRECVS6-1 Distribution: unstable Urgency: low Maintainer: Ean R. Schuessler [EMAIL PROTECTED] Changed-By: Arnaud Vandyck [EMAIL PROTECTED] Description: jikes-kaffe - Wrapper for jikes using Kaffe classes kaffe - A JVM to run Java bytecode kaffe-common - Files shared between all Kaffe VM versions kaffe-dev - Header files and other resources for building against Kaffe kaffe-doc - Documentation for the Kaffe VM kaffe-jthreads - A green threads enabled version of the Kaffe VM kaffe-pthreads - A POSIX threads enabled version of the Kaffe VM kjc- A compiler for the Java language written in Java Changes: kaffe (2:1.1.4.PRECVS6-1) unstable; urgency=low . * New upstream release (gjdoc fix and swing improvements and more) Files: 4bf3a435036878c2cadc6970e16e6408 979 interpreters optional kaffe_1.1.4.PRECVS6-1.dsc 8c5f2eeab6f964b93f4ad54ebc924f4d 10564531 interpreters optional kaffe_1.1.4.PRECVS6.orig.tar.gz cbc3431d8939022eeedf9ec442eb49bb 24459 interpreters optional kaffe_1.1.4.PRECVS6-1.diff.gz c0668a4b8f3517c79d0483885a6c5de5 54400 interpreters optional kaffe_1.1.4.PRECVS6-1_all.deb 7fbba271a958dbb55589c309a95da7d9 1028850 interpreters optional kjc_1.1.4.PRECVS6-1_all.deb c844ec7910d46bacb8e9bb8615d8a28d 5573528 interpreters optional kaffe-common_1.1.4.PRECVS6-1_all.deb d995f43dc62e75bc46db4a325b39b015 70056 interpreters optional kaffe-dev_1.1.4.PRECVS6-1_all.deb 23c739b6517f4370347df8fe2e0f9d1f 53912 interpreters optional jikes-kaffe_1.1.4.PRECVS6-1_all.deb d605290445a151789097f41654179ab8 129748 interpreters optional kaffe-doc_1.1.4.PRECVS6-1_all.deb 75d05079a911bee3924d1e76c08b145c 860774 interpreters optional kaffe-jthreads_1.1.4.PRECVS6-1_powerpc.deb 4b7d7383186e9ff4530dbc5c392a2749 977458 interpreters optional kaffe-pthreads_1.1.4.PRECVS6-1_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBv3tC4vzFZu62tMIRAuilAJ9QhJSuzyR0+j50efrEqte8vFEQjwCdHM7U nXtLqspRutMO3VMmWHr+jDY= =ftV2 -END PGP SIGNATURE- Accepted: jikes-kaffe_1.1.4.PRECVS6-1_all.deb to pool/main/k/kaffe/jikes-kaffe_1.1.4.PRECVS6-1_all.deb kaffe-common_1.1.4.PRECVS6-1_all.deb to pool/main/k/kaffe/kaffe-common_1.1.4.PRECVS6-1_all.deb kaffe-dev_1.1.4.PRECVS6-1_all.deb to pool/main/k/kaffe/kaffe-dev_1.1.4.PRECVS6-1_all.deb kaffe-doc_1.1.4.PRECVS6-1_all.deb to pool/main/k/kaffe/kaffe-doc_1.1.4.PRECVS6-1_all.deb kaffe-jthreads_1.1.4.PRECVS6-1_powerpc.deb to pool/main/k/kaffe/kaffe-jthreads_1.1.4.PRECVS6-1_powerpc.deb kaffe-pthreads_1.1.4.PRECVS6-1_powerpc.deb to pool/main/k/kaffe/kaffe-pthreads_1.1.4.PRECVS6-1_powerpc.deb kaffe_1.1.4.PRECVS6-1.diff.gz to pool/main/k/kaffe/kaffe_1.1.4.PRECVS6-1.diff.gz kaffe_1.1.4.PRECVS6-1.dsc to pool/main/k/kaffe/kaffe_1.1.4.PRECVS6-1.dsc kaffe_1.1.4.PRECVS6-1_all.deb to pool/main/k/kaffe/kaffe_1.1.4.PRECVS6-1_all.deb kaffe_1.1.4.PRECVS6.orig.tar.gz to pool/main/k/kaffe/kaffe_1.1.4.PRECVS6.orig.tar.gz kjc_1.1.4.PRECVS6-1_all.deb to pool/main/k/kaffe/kjc_1.1.4.PRECVS6-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pmp-common 2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Dec 2004 17:11:08 -0600 Source: pmp-common Binary: pmp-common Architecture: source all Version: 2 Distribution: unstable Urgency: low Maintainer: Joe Wreschnig [EMAIL PROTECTED] Changed-By: Joe Wreschnig [EMAIL PROTECTED] Description: pmp-common - hotplug scripts for portable music players Changes: pmp-common (2) unstable; urgency=low . * Include device IDs for the iRiver 9xx and N10 series. * Use the new 'plugdev' group instead of the custom 'pmp-common'. Files: 08354192274793857d4ab38a86f7ca59 497 admin extra pmp-common_2.dsc a7276c218a27ffa27d0fbac6ba56de5b 1805 admin extra pmp-common_2.tar.gz c7b35f87227b9d295d20cbdac472a912 2622 admin extra pmp-common_2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBv4cLTFkUq7Drx3cRAvXOAJ4sSjgLYnIh/blAlNhOrGcx2jnYWgCgrDlW yh96VUvxLzVUDC73Ucch3Kw= =y5b/ -END PGP SIGNATURE- Accepted: pmp-common_2.dsc to pool/main/p/pmp-common/pmp-common_2.dsc pmp-common_2.tar.gz to pool/main/p/pmp-common/pmp-common_2.tar.gz pmp-common_2_all.deb to pool/main/p/pmp-common/pmp-common_2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gst-python 0.8.1-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Dec 2004 18:11:50 -0600 Source: gst-python Binary: python-gst Architecture: source i386 Version: 0.8.1-1 Distribution: unstable Urgency: low Maintainer: Joe Wreschnig [EMAIL PROTECTED] Changed-By: Joe Wreschnig [EMAIL PROTECTED] Description: python-gst - generic media-playing framework (Python bindings) Changes: gst-python (0.8.1-1) unstable; urgency=low . * New upstream version. Files: 1cc5b42ce94cbdf9b5d951d792180199 702 python optional gst-python_0.8.1-1.dsc 99732726575dc4b0873f8984a14f2bf9 394501 python optional gst-python_0.8.1.orig.tar.gz b6b683bffa553816c2403c856c52e242 7908 python optional gst-python_0.8.1-1.diff.gz f4312e9489a44923af1767d4b0d90169 115466 python optional python-gst_0.8.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBv4oFTFkUq7Drx3cRAmzdAKCPhVL4o9PmYClICkguOGZRStuNHgCfe4QC uCP0Yz15EpYzBXEUUmCjELs= =Lfe4 -END PGP SIGNATURE- Accepted: gst-python_0.8.1-1.diff.gz to pool/main/g/gst-python/gst-python_0.8.1-1.diff.gz gst-python_0.8.1-1.dsc to pool/main/g/gst-python/gst-python_0.8.1-1.dsc gst-python_0.8.1.orig.tar.gz to pool/main/g/gst-python/gst-python_0.8.1.orig.tar.gz python-gst_0.8.1-1_i386.deb to pool/main/g/gst-python/python-gst_0.8.1-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted zoph 0.3.3-10 (all source)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 15 Dec 2004 01:55:48 +0100
Source: zoph
Binary: zoph
Architecture: source all
Version: 0.3.3-10
Distribution: unstable
Urgency: low
Maintainer: Edelhard Becker [EMAIL PROTECTED]
Changed-By: Edelhard Becker [EMAIL PROTECTED]
Description:
zoph - Web based digital image presentation and management system
Changes:
zoph (0.3.3-10) unstable; urgency=low
.
* command in post{inst,rm} made zoph uninstallable when apache2 is not found
on the system
Files:
287625a94bcc58c198896495a8b2fb98 558 web optional zoph_0.3.3-10.dsc
652f2d6c87676de4328bc95f1631c57b 51754 web optional zoph_0.3.3-10.diff.gz
86067dc3fd7aacc0842ba7f1f4cc7a37 172422 web optional zoph_0.3.3-10_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFBv41QlByGkm8iLx8RAn0AAKCSKMnowkv3T6tg3ntNM/nMtHt9ugCdF9FG
e0ekt+FIkL2GAixlc++kW8M=
=DAHR
-END PGP SIGNATURE-
Accepted:
zoph_0.3.3-10.diff.gz
to pool/main/z/zoph/zoph_0.3.3-10.diff.gz
zoph_0.3.3-10.dsc
to pool/main/z/zoph/zoph_0.3.3-10.dsc
zoph_0.3.3-10_all.deb
to pool/main/z/zoph/zoph_0.3.3-10_all.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
