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
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
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. Youâve become so used to its reliability that you donât 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 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. Youâve become so used to its > reliability that you donât 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 KÃster Inst. f. Biochemie der Univ. ZÃrich 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 > > > > 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 dev
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 ;) > > * 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 > 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 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 writes: > Goswin von Brederlow wrote: >> Anthony Towns 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 GÃtje (éçè) <[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
