Re: RFC: Why are so many debian packages outdated?
I _knew_ Apple was behind this somehow! -miles -- Ocean, n. A body of water covering seven-tenths of a world designed for Man - who has no gills. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878ve5g5v9@catnip.gol.com
Re: glibc very old
Vincent Lefevre vinc...@vinc17.net writes: So... these functions were made almost an order of magnitude slower in the (overwhelmingly) common case, in order to handle rare and exceptional cases...? This depends on the processor. You should get a processor that handles rounding-mode change in a better way (the slowdown should not be noticeable when you just run the program, without looking at the exact running time). It's about 5 times slower on both phenom2 (AMD) and core2 (Intel) cpus I dunno if these are unusual. But note that this could actually be slower with some processors: the processor already knows the rounding mode it is running under, so that if the rounding mode is not changed, the rounding-mode control instruction should be no slower than no-op! Ok, I guess there's no really guaranteed way to make it fast, so glibc's method (with arch-specific reimplementations for those cases where it proves to be slow) it is reasonable enough ... -miles -- Circus, n. A place where horses, ponies and elephants are permitted to see men, women and children acting the fool. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vchbfz1i@catnip.gol.com
Re: glibc very old
Vincent Lefevre vinc...@vinc17.net writes: But with: ... int r = fegetround(); if (r != FE_TONEAREST) fesetround (FE_TONEAREST); y = exp(x); ... I only get a 9% slowdown. I suppose that withing glibc code, it can be lower. Makes sense... I can imagine the way overworked CPU designers not bothering to optimize mode setting at all (e.g.., just flush all pipelines when it happens...), on the assumption that setting the rounding mode is a very rare operation... The advantage of this method compared to remembering the rounding mode in glibc is that it is 100% safe, in case the user or some library bypasses the C libary to change the rounding mode. I think that there could be an optimization like that in fesetround() too. Do you think it's worth proposing this to the glibc people? [I'm always a little scared to do that, nest of vipers, etc...] -miles -- In New York, most people don't have cars, so if you want to kill a person, you have to take the subway to their house. And sometimes on the way, the train is delayed and you get impatient, so you have to kill someone on the subway. [George Carlin] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq7jf8et@catnip.gol.com
Re: glibc very old
Vincent Lefevre vinc...@vinc17.net writes: Based on a glance at the source, it seems like the math libraries were changed in lots of little ways between 2.13 and 2.16 [and it looks like the FPU-twiddling that made expf slow in 2.13 has been _added_ to the generic version of the exp (double-precision) function, meaning it might actually be (much) _slower_ in 2.16 on ports without optimized implementations... :( ] However (if this is the change I'm thinking of) this makes math functions correct in directed rounding modes and potentially more secure. By correct, I mean that the result is somewhat acceptable (not that the result is correctly rounded and the rounding direction is honored), instead of getting completely wrong values or even a crash. But how often are directed rounding modes used? Like 0.001% of the time? So... these functions were made almost an order of magnitude slower in the (overwhelmingly) common case, in order to handle rare and exceptional cases...? I can see that as an emergency workaround when the deadline is next week, but it seems kind of questionable as a general technique. Is there no more sane method? E.g.: (1) have the FPU-twiddling functions (fenv.h stuff?) set a global flag FPU_is_twiddled = 1; (2) write these rounding-mode-sensitive functions like: if (FPU_is_twiddled) return slow_ass_FPU_twiddling_version (); /* ... otherwise fall through to normal fast code ... */ thanks, -miles -- Alone, adj. In bad company. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d33lhinf@catnip.gol.com
Re: glibc very old
Steve Langasek vor...@debian.org writes: Is there a reason that Debian has such an old version of glibc, even in unstable? The current upstream version of glibc seems to be 2.16, whereas Debian has 2.13 (which is circa 2011-02). The basic reasons are that 2.14 was a dud of an upstream release, and no one found the time after 2.15 came out to get it into shape for all our ports before the freeze. Thanks Steve (etc) ... I wonder if it's worth filing a bug about expf in particular; I dunno whether that change is isolated enough to make a patch easy... Based on a glance at the source, it seems like the math libraries were changed in lots of little ways between 2.13 and 2.16 [and it looks like the FPU-twiddling that made expf slow in 2.13 has been _added_ to the generic version of the exp (double-precision) function, meaning it might actually be (much) _slower_ in 2.16 on ports without optimized implementations... :( ] -miles -- Carefully crafted initial estimates reward you not only with reduced computational effort, but also with understanding and increased self-esteem. -- Numerical methods in C, Chapter 9. Root Finding and Nonlinear Sets of Equations -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3xvhvrk@catnip.gol.com
glibc very old
Is there a reason that Debian has such an old version of glibc, even in unstable? The current upstream version of glibc seems to be 2.16, whereas Debian has 2.13 (which is circa 2011-02). [The particular improvement I'm interested in is a (significantly) faster version of the expf function (unfortunately only on x86-64, although the silly lossage [FPU mode twiddling] that makes the old version (currently in Debian!) slow might not be as severe on other architectures).] Thanks, -miles -- Sabbath, n. A weekly festival having its origin in the fact that God made the world in six days and was arrested on the seventh. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3y1nak5@catnip.gol.com
Re: Recommends for metapackages
Jeremy Bicha jbi...@ubuntu.com writes: I don't claim to be a networking expert, but I believe half the conversation here is based on wrong or outdated information. My (personal) complaint about NM is that it doesn't correct correctly work with NFS mounts, I believe because it doesn't run at the right time during bootup. That's perhaps illustrative of more general practical and conceptual issues with NM: it doesn't seem to be tested with much in the way of non-standard setups, and in general seems to assume too many low-level and central system tasks that arguably aren't appropriate for software associated with a specific desktop (even if Gnome is installed on a system to make some users happy, other users of the same system may use some other desktop). GNOME considers NM to be part of GNOME Core, therefore gnome-core depends on it. Debian need not slavishly follow how upstream thinks about things. Plenty of upstreams have downright bizarre opinions about various issues (often related to the not playing nice with others), but nevertheless still make useful software. In such cases I think one of the proper tasks of a distribution is to act as a buffer between upstream and the users, installing the software in a way that works well in the actual distribution, for actual users (as opposed to the imaginary distribution and users upstream may be targeting). Obviously this can be a lot of work, which is why it's generally a good idea to defer to upstream's views when they are sane -- but that isn't always the case... -miles -- Friendship, n. A ship big enough to carry two in fair weather, but only one in foul. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txxcp15z@catnip.gol.com
Re: Recommends for metapackages
Gergely Nagy alger...@balabit.hu writes: if upstream considers a package a core part of a platform, recommends *is* wrong. Er, no. Upstreams are not infallible, and are often quite fallible... Upstream's view is a good _default_, but such judgements should be made based on the reality on the ground. -miles -- Non-combatant, n. A dead Quaker. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obnkp0sx@catnip.gol.com
Re: duplicates in the archive
Félix Arreola Rodríguez fgatuno@gmail.com writes: But, ignoring the a desktop works fine without n-m thing, n-m makes more, much more easy connecting to wifi networks, espeacially for laptops. I suggest make Laptop task depend on n-m, in this way, n-m don't get installed on desktop systems, just on laptop systems. What's wrong with Recommends: in that case? It seems to perfectly match the makes life easier for common but not universal use-case XXX scenario you describe. A hard package-dependency in a case like this, when there isn't actually any hard functional dependency, and there are issues with the depended-upon package, are decidedly user-unfriendly. [Yeah, the various desktops tend to abuse hard-dependencies in a lot of other ways, but ... in most cases this just results in bloat. NM is a bit worse than that.] -Miles -- Brain, n. An apparatus with which we think we think. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vest3i6@catnip.gol.com
Re: Concerns and Challenges of Squeeze and Ongoing Elements
Charles Plessy ple...@debian.org writes: I do not think there is much trolling. We need to discuss issues openly. It certainly _resembles_ a classic troll: long and vaguely insulting (under a surface veneer of politeness), yet curiously vague and information-free, despite its length, and ending with I'm giving up on Debian. When pushed for details (in a later message), he says I'm too busy to file bug reports. There are certainly valid complaints about Debian (and have been for every release), but people who are really trying to give constructive criticism almost always seem to act very differently: they complain about specific problems, in at least enough detail that people know what they're talking about. Even if the OP didn't actually intend to troll, somebody who does nothing other than make vague insinuations and refuses to provide details simply isn't a very useful part of any conversation whose goal is to make things better... -miles -- Opposition, n. In politics the party that prevents the Goverment from running amok by hamstringing it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762a2yfwv@catnip.gol.com
Re: Bug#678815: ITP: wmfs -- Window Manager From Scratch
Arno Töll a...@debian.org writes: On 24.06.2012 19:15, Neil Williams wrote: This bug is *not* useful to anyone. Please close it and find an RC bug to close instead. I'm pretty sure this could be expressed in another tone. Especially since we welcome everyone (you know) and we have _no_ written rule what belongs into Debian and what not, and nobody who decides on that beyond legal issues. OTOH, drama-queen whining about new packages is absolutely _classic_ Debian... -miles -- It wasn't the Exxon Valdez captain's driving that caused the Alaskan oil spill. It was yours. [Greenpeace advertisement, New York Times, 25 February 1990] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipeg7zic@catnip.gol.com
Re: Moving /tmp to tmpfs makes it useful
Salvo Tomaselli tipos...@tiscali.it writes: This is indeed a valid point. But that’s no regression; /tmp has always been for small short-lived files, and /var/tmp for those that are not one of them or not both. You just made up this difference. No he didn't, it's common practice from unix-days-of-yore (though it was /usr/tmp or whatever back then...). -miles -- Christian, n. One who follows the teachings of Christ so long as they are not inconsistent with a life of sin. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wr3wal0m@catnip.gol.com
Re: Exported (ba)sh functions in the environment
Peter Samuelson pe...@p12n.org writes: If you can think of a way to implement this same stuff (and remember, bash-completion supports a _lot_ more complex cases than 'kill') without adding 200 kB of shell functions to bash's runtime, by all means, do it and see how it works out. What would seem interesting would be a way to autoload bash completion support for each command ... as it would seem not uncommon to have shell sessions where the user never tries to use completion for 99% of the commands handled. [or does it already do this?] -miles -- Consult, v.i. To seek another's disapproval of a course already decided on. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obp7aioj@catnip.gol.com
Re: Packaging on GitHub ?
Brian May br...@microcomaustralia.com.au writes: This is not a good idea: http://mako.cc/writing/hill-free_tools.html MUCH seconded. Thanks for sharing the link! I don't see the problem, github is just a hosting provider. Unlike, say Bitkeeper, you are free to make git clones anywhere, entirely with open source software, and are in no way locked down to using github. Except maybe features like the issue tracking, which may not be really appropriate for Debian packages anyway. Debian has its own BTS that should be used. Github issue tracking is very bare-bones, and they provide a convenient API that can be used to extract all information from it (or add new info); moving a project from github to a new service wouldn't be a huge task (if the new service provides equivalent functionality). Moreover, these days it's not uncommon to maintain a project on multiple sites simultaneously... So the amount of lockin with github seems fairly minimal. [Mako-hill's paper is well-intended, but seems a little dated in its assumptions.] -Miles -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipffa834@catnip.gol.com
Re: Moving /tmp to tmpfs is fine
Thomas Goirand z...@debian.org writes: Perhaps it should be extended to allow the directory to be below ~/ instead of below /tmp/. :) I don't think so. As other pointed out, your /home could be remote (over NFS?), and then slow, while /tmp is normally on your local machine, so moving the temp folder in ~/ will potentially slow them down, and break quota. ... yeah, my homedir is in NFS, and I get no end of grief from the bazillion packages in debian that blithely cache vast quantities of (often very uninteresting) data in random subdirs of $HOME... and then expect accessing it to be very fast :[ -miles -- Year, n. A period of three hundred and sixty-five disappointments. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d35na73z@catnip.gol.com
Re: Moving /tmp to tmpfs makes it useful
Serge sergem...@gmail.com writes: Every tool either supports setting TMPDIR=/var/tmp before running it or is buggy. Go fix these instead Do I understand you right? You suggest every tool that need large tmp files to use /var/tmp instead? That's not a new suggestion, it's been standard practice for nigh-on _decades_... -miles -- Do not taunt Happy Fun Ball. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zk8vdbnx@catnip.gol.com
Re: Moving /tmp to tmpfs makes it useful
Serge sergem...@gmail.com writes: I'm asking for *popular* apps, that create files in /tmp, *never put large files* there, and become *noticeably* faster with /tmp on tmpfs? Is that even the issue, for the most part? My impression is that using tmpfs is just logistically simpler and safer -- it can be mounted very early, doesn't muck with the (possibly small or r/o) root fs, makes it simple to limit temp space without a separate partition, etc. -miles -- 「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]
Re: Moving /tmp to tmpfs makes it useless
Jakub Wilk jw...@debian.org writes: ACK. /tmp on tmpfs is a nice hack (I use it myself!), but it's a terrible default. I can't say whether it's a good default or not (though it seems to work pretty well in practice), but the OP's argument is completely silly. Most apps use /tmp not for reducing memory usage, but for communicating with other apps (of course, often, such as in a shell script, or indeed the user himself, the choice of /tmp is not done by the app itself, but by the invoker) -- it's a common namespace. Of course it's the rare exceptions to this that cause problems; whether there are enough such exceptions to make the default a bad idea, I dunno. [apparently my /tmp got switched over to tmpfs by some automatic upgrade, and it took me _months_ to even notice...] -miles -- Mayonnaise, n. One of the sauces that serve the French in place of a state religion. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq9tdpbl@catnip.gol.com
Re: amd64 as default architecture
Paul Wise p...@debian.org writes: There is smolt for that, but folks haven't packaged it for Debian yet: https://fedorahosted.org/smolt/ http://bugs.debian.org/435058 Hmm... from http://smolts.org/static/stats/stats.html: The statistics script is no longer running and creating new data. We're in the process of decomissioning smolt. Please take a look at the census project if you'd like to help out with the replacement for smolt. -miles -- Quack, n. A murderer without a license. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87likmhyxw@catnip.gol.com
Re: Making -devel discussions more viable
Alexander Wirt formo...@debian.org writes: I am just speaking for myself as listmaster. But I don't think any DD has more right to talk on a mailinglist than anybody else. I won't support such a proposal nor want I participate in it. If you have a problem with someone on a mailinglist, report it and listmasters decide if we should step in. ... and as a non-DD who's been using Debian for 15 years (and reading this list for many of them), and understands at least some of the technical issues, I find the suggestion that I be automatically considered a negative influence and excluded kind of annoying. The issues discussed here often do affect me, because I use Debian. I don't actively participate most of the time but I do read, and every once in a while, feel I have something to add. The problem is not non-DDs, it's jerks and/or the clueless. Maybe on this list there's _some_ correlation between non-DDness and those things -- but it's far from perfect... (and not, IMHO, enough to justify censorship). -miles -- Un-American, adj. Wicked, intolerable, heathenish. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mx5jp53o@catnip.gol.com
Re: RFC: OpenRC as Init System for Debian
Svante Signell svante.sign...@telia.com writes: So, the real problem is: How do you define the boot process of a computer. For me it is when the kernel has been loaded by the boot media, memory, graphics card, etc initialized. Some modules are needed for boot, other modules can be loaded later. The only case I can see when you need a network during the boot process is when booting from the network, and for that you can predefine which modules to load. Isn't mounting filesystems, which can depend on the network, part of the boot process? I recently had an unpleasant experience where I switched to network-manager to make gnome-shell happy, but network-manager runs too late in the boot process, so none of my NFS filesystems got mounted. I certainly wished there was a bit more proper ordering going on then... -miles -- Philosophy, n. A route of many roads leading from nowhere to nothing. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87haw2irxf@catnip.gol.com
Re: RFC: OpenRC as Init System for Debian
Stephan Seitz stse+deb...@fsing.rootsland.net writes: Isn't mounting filesystems, which can depend on the network, part of the boot process? Yes, but how do you check if the network is configured and operational? - when the link is up? - when the IP address is configured (how do you check this with IPv6?)? What are you doing if more than one IP address is configured for this NIC or more than one NIC is available? - when the switch accepts traffic on the port you are connected to? - when the router/firewall accepts traffic from your IP address? No event based init system will solve these problems when you have dependencies outside the box you are booting. The local admin has to check if all timings are right and must adjust them if they are not fitting. Er, what? Please don't throw out silly strawmen... -miles -- Inhumanity, n. One of the signal and characteristic qualities of humanity. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vheipu5@catnip.gol.com
Re: RFC: OpenRC as Init System for Debian
Bernd Zeimetz be...@bzed.de writes: Er, what? Please don't throw out silly strawmen... Stephan's points are valid. Just having a link on your favourite cisco does not mean that you are allowed to send packets anywhere yet. Getting a ipv6 address via radvd does not mean that you are able too access your nfsv4 server (and the other way round...). And so on. No, his points are strawmen. Nothing is perfect, and there are no absolute guarantees of _anything_, but there are things which can generally assumed to be work in practice (in particular anything outside the current box). If there are ipv6 / nfsv4 interoperability issues, that's a shame, but it certainly shouldn't be used as an excuse to gimp the entire system, when it may work fine for people using ipv4 and nfsv3... That's what it sounds like Stephan is doing: oh it can't be perfect, so let's not even try to be good. -miles -- gravity a demanding master ... soft soft snow -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwblhoth@catnip.gol.com
Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator
Bernhard R. Link brl...@debian.org writes: For the grammer I personally would prefer it expanded, though I think it is more understandable as EBNF (Extended Backus-Naur Form) Grammar than the other way around. I agree -- in reinforces the fact that these are well-known terms which are often known by their acronym. -miles -- P.S. All information contained in the above letter is false, for reasons of military security. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4vphh6a@catnip.gol.com
Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator
Adam Borowski kilob...@angband.pl writes: On Sat, Apr 14, 2012 at 11:22:06AM +0200, Jakub Wilk wrote: GLR means Generalized Left-to-right Rightmost deviation parser or maybe Generalized LR parser. EBNF is the Extended BackusâNaur Form. Acronyms like these - i.e. LL, LL(k), SLR, LALR - are pretty common when talking about parsers. Sure, they are also much more common than GLR. And if you are just interested in parsing and not a computer scientists, there's a chance you've never heard about any of them. I can't really imagine someone writing a parser using such tools without having heard these acronyms first, though. And I'd risk saying they are actually more widely known than their expansions. In my experience, EBNF and LL/SLR/LALR are widely known (they are classic compiler terms), for the type of person who might be interested in parser generators, but GLR isn't. So I'd provide an expansion (maybe in parentheses) for the latter only. Moreover, one wants to err on the side of being too verbose, at least in the long description; of course one should provide both the acronym and the expansion in case the person only recognizes the former [e.g. XYZ (Xxx Yyyy Zzzz)]. -Miles -- Acquaintance, n. A person whom we know well enough to borrow from, but not well enough to lend to. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wr5hhha2@catnip.gol.com
Re: Standard C Library complance test suite
David Weinehall t...@debian.org writes: Consider the case where a legal department was worried about the code repository becoming tainted with uncontrolled or ill-considered GPL obligations. If the legal department is that incompetent it's about time they got replaced by more competent people... I think in many cases, the issue is not really an incompetent legal department per se, but a culture of risk-avoidance combined with a legal department that doesn't really gain much either way and incompetent high-level management (in the sense that they don't spend a lot of time listening to those in the trenches). And sometimes things are rather more sinister (e.g. Apple's crusade against the GPL)... -miles -- I'm beginning to think that life is just one long Yoko Ono album; no rhyme or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buofwch4heo@dhlpc061.dev.necel.com
Re: On init in Debian
Carlos Alberto Lopez Perez clo...@igalia.com writes: $ sudo apt-get remove network-manager* $ sudo apt-get install wicd wicd-curses wicd-gtk ^ wicd-kde ? $ wicd-curses And enjoy your network without the NM mess :) ... unless, of course, you're using gnome-shell, which currently doesn't work without network-manager...! [naturally network-manager plays badly with NFS, so just installing NM causes other problems... argh] :( -miles -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- Donald Knuth -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buopqbvgbhu@dhlpc061.dev.necel.com
Re: Unofficial repositories on 'debian' domains
Reinhard Tartler siret...@gmail.com writes: On Mon, Mar 5, 2012 at 11:52 AM, Milan P. Stanic m...@arvanta.net wrote: For me d-m.o was (and still is) valuable resource. Some codecs missing in Debian packages because of the policy (I don't blame Debian for that) and in that case d-m.o is best option for me because I don't want/have time to package it from the source. Out of curiousity, what codecs do you miss in the official debian packages? Er ... MP3 encoding ? [Is that available in debian-official now?] -miles -- Circus, n. A place where horses, ponies and elephants are permitted to see men, women and children acting the fool. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buopqcqtk14@dhlpc061.dev.necel.com
Re: Bug#661565: ITP: nyancat -- Terminal-based Pop Tart Cat animation
Jonathan McCrohan jmccro...@gmail.com writes: I certainly don't plan on uploading and abandoning this package, but given the high level of opposition to this ITP, guess there is little point pursuing it. There's some whining by the usual sorts, but why would anyone pay attention to them...? -miles -- Bacchus, n. A convenient deity invented by the ancients as an excuse for getting drunk. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buosjhs27ci@dhlpc061.dev.necel.com
Re: Default display manager should not be gdm3
Ian Jackson ijack...@chiark.greenend.org.uk writes: We should not still be using this software. Er, given that gdm3 works fine for many people, that seems excessive. Moreover, the choice of default display manager seems unrelated to its ability to support obscure tweaks -- indeed, it's very common for default packages to be those that are nicer for average users, not those that are the most customizable. You have the choice of easily installing other display managers that meet your criteria, so what's the big deal? -miles -- Idiot, n. A member of a large and powerful tribe whose influence in human affairs has always been dominant and controlling. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buobooqksmr@dhlpc061.dev.necel.com
Re: Use of the first person in messages from the computer
Ian Jackson ijack...@chiark.greenend.org.uk writes: Finally, the reviewer revealed in the review that they're not a native speaker of English. Is it normal for l10n reviews to be conducted by non-native speakers of the target language ? Are we really so short of native English speaking l10n reviewers ? If so I would be happy to help (although you may find me too opinionated...) Hmmm, while it may not be the best thing to have a non-native speaker in charge of wording, I think it actually _is_ useful to have their input. Sometimes language that seems pretty obvious to a native speaker isn't clear at all to many non-native speakers (even if they're fairly competent)... -miles -- Discriminate, v.i. To note the particulars in which one person or thing is, if possible, more objectionable than another. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buoipjfclhh@dhlpc061.dev.necel.com
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
Adam Borowski kilob...@angband.pl writes: And things may change yet again in the future. With Btrfs, one can have a single filesystem with multiple subvolumes. The subvolumes can be mounted independently, and also snapshotted independently, but have a common pool for free data, so unlike partitions any subvolume can grow/shrink as required. Ie, almost all upsides of LVM. Wait, what? AFAIK, multiple partitions in LVM _don't_ share free-space, they're basically independent filesystems, with the individual hard allocation limits (and if one wants to _change_ those limits, growing-shrinking filesystems in concert with partitions seems all too easy for a user to screw up, hosing their data). No...? -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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buo62h2ziax@dhlpc061.dev.necel.com
Re: Increasing minimum 'i386' processor
Ian Jackson ijack...@chiark.greenend.org.uk writes: The 486-class processors that would no longer be supported are: 1. All x86 processors with names including '486' I'm still running the machine below, and it would be irritating to have to replace it. ... vendor_id : CentaurHauls cpu family: 6 model : 7 model name: VIA Samuel 2 AFAICT, the above would be considered a 586-class CPU... so no prob! -Miles -- A zen-buddhist walked into a pizza shop and said, Make me one with everything. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buor50e1eo5@dhlpc061.dev.necel.com
Re: Bug#651093: ITP: libyui -- Qt, GTK+ and ncurses UI-Engine
Björn Esser bjoern.es...@googlemail.com writes: So how shall I name it then? Given that there isn't actually any conflict, that the two libraries are in different domains (one C/C++, the other html/javascript), and that neither of them appears to be heavily used (though the lib used in yast seems to get many more google hits), wouldn't a simple note in the project description be enough? Any actual renaming seems likely to cause more problems than it solves. E.g.: ... package description ... Note: this library shouldn't be confused with the 'libjs-yui' package, which is the 'yahoo user interface library' for javascript. [and a similar note in the libjs-yui package description.] -Miles -- Do not taunt Happy Fun Ball. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buoobvklr6p@dhlpc061.dev.necel.com
Re: Bug#651093: ITP: libyui -- Qt, GTK+ and ncurses UI-Engine
Jaldhar H. Vyas jald...@debian.org writes: * Package name: libyui the package for the Yahoo! User Interface toolkit is called libyui-js which is bound to cause confusion. Can you rename yours to maybe libyastui or something? libyastui would seem sort of misleading -- from the description, it sounds like libyui isn't part of yast, but rather an independent library upon which yast depends. Also, there isn't actually a libyui-js package... -Miles -- gravity a demanding master ... soft soft snow -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buor50icfsm@dhlpc061.dev.necel.com
Re: directory under /usr/bin -- Ok or not?
Ben Hutchings b...@decadent.org.uk writes: I don’t think Debian requests FHS to document something before we can use it. The real problem with the bizarre GNU invention that is /usr/libexec is that nobody knows what it is here for. It's not a GNU invention; I believe it derives from BSD. Yes, it originally came from BSD. Seems to make good sense too. -Miles -- We live, as we dream -- alone -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nyj1556@catnip.gol.com
Re: aptitude weirdness wrt upgrades and keeps
Paul Wise p...@debian.org writes: Not a solution for the interactive mode, or am I wrong? Not AFAICT, I only read the documentation rather than the code though. Kinda surprising, actually; this has long been the #1 most horrible thing about aptitude, and one about which there's been plenty of complaining... [With the normal U command, for my typical usage, aptitude seems to choose the worst possible solution about 98% of the time.] -Miles -- Cabbage, n. A familiar kitchen-garden vegetable about as large and wise as a man's head. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buohb3cow4e@dhlpc061.dev.necel.com
Re: Bug#644535: ITP: eclipse-autotools -- Eclipse Linux Tools: Autotools support for CDT
Jakub Adam jakub.a...@ktknet.cz writes: With this additional support, a vast repository of C/C++ code can be checked out, built, and maintained under the CDT rather easily without having to resort to the command line. Nice! [Maybe having to resort is a bit judgemental in tone, though ...] -miles -- Logic, n. The art of thinking and reasoning in strict accordance with the limitations and incapacities of the human misunderstanding. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buowrchjmn1@dhlpc061.dev.necel.com
Re: *-config programs and multi-arch
Adam Borowski kilob...@angband.pl writes:
AFAICT, the easiest way to handle all this is just to make a missing
cross-pkg-config look like a missing pkg-config to the configure
script. Then whatever logic the script may have for detecting the
not pkg-config at all case, will do the right thing for the cross
case too.
Currently I just have my configure script completely disable use of
pkg-config when cross-compiling (by setting PKG_CONFIG=), but
obviously this is undesirable if a cross-version of pkg-config was
actually found...
How can you link to libraries that require special handling then?
Do you hard-code the compiler/linker arguments? That seems fragile,
especially with library/include paths changing weekly these days.
I'm a little confused as to what your saying here; what seems fragile?
Are you saying that pkg-config is necessary in some cases because
some libraries use wacky magic that only pkg-config can provide, so a
non-pkg-config fallback in configure will be hard to make work?
If so, that's certainly true, but I'm not sure how it affects my
argument -- for libraries where pkg-config is necessary, the current
cross-compiling behavior when a cross-pkg-config isn't found is still
almost certainly the wrong thing.
[If, on the other hand, you're really just asking what I do in the
case where pkg-config isn't present, I mostly just assume the
pkg-config-using libraries aren't present either (they're all
optional); for a few important ones, I fallback to traditional
autoconf methods like AC_CHECK_LIB... some libraries, after all, are
simple enough that this works fine.]
My argument in this thread is just:
When cross-compiling, there shouldn't be any default fallback for
pkg-config if a cross-pkg-config (${ARCH}-pkg-config) isn't found;
the current default behavior is more harmful than useful.
configure files that _depend_ on pkg-config being present (and
don't use extra magic like you describe), should simply give a
fatal error after PKG_PROG_PKG_CONFIG in the case where
PKG_CONFIG= (but then, they should do this already, to handle the
case where the system simply has no pkg-config installed at all).
-Miles
--
Fast, small, soon; pick any 2.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/buoty8clt17@dhlpc061.dev.necel.com
Re: *-config programs and multi-arch
Tollef Fog Heen tfh...@err.no writes:
]] Miles Bader
|When cross-compiling, there shouldn't be any default fallback for
|pkg-config if a cross-pkg-config (${ARCH}-pkg-config) isn't found;
|the current default behavior is more harmful than useful.
You could argue this for any tool checked for using AC_PATH_TOOL, I
think and if you agree with that premise this should be fixed in
autoconf, not pkg-config.
Sure. What's the best way to proceed then? File a bug against
autoconf? [upstream?]
[Someone mentioned that pkg-config also can be used for
architecture-independent packages, but that seems like an orthogonal
point, and not an overriding concern given than most packages aren't
architecture-independent.]
Thanks,
-Miles
--
Quotation, n. The act of repeating erroneously the words of another. The words
erroneously repeated.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zki3higk@catnip.gol.com
Re: *-config programs and multi-arch
Tollef Fog Heen tfh...@err.no writes: | I don't know how pkg-config handles multiarch either, but however | it detects the desired host arch (is it just the PKG_CONFIG_PATH | variable?), your /usr/bin/foo-config shouldn't have to care. Your cross-toolchain is supposed to set up a symlink from /usr/bin/$triplet-pkg-config to /usr/share/pkg-config-crosswrapper which will then DTRT. That's the idea at least, I haven't actually tested it. How is one supposed to make pkg-config use this feature? I mean, say I do: ./configure --host=muckey-muck-muck --build=my-host-type That generally does something reasonable for compilers, but ... not for pkg-config, using the normal PKG_... autoconf macros. A brief browse of the pkg-config docs doesn't show any obvious user-level way of specifying an alternate host architecture. There's the environment variable PKG_CONFIG_SYSROOT_DIR, but that seems a little low-level. Thanks, -Miles -- One of the lessons of history is that nothing is often a good thing to do, and always a clever thing to say. -- Will Durant -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buoipou6y2x@dhlpc061.dev.necel.com
Re: *-config programs and multi-arch
Miles Bader mi...@gnu.org writes: A brief browse of the pkg-config docs doesn't show any obvious user-level way of specifying an alternate host architecture. There's the environment variable PKG_CONFIG_SYSROOT_DIR, but that seems a little low-level. Also, PKG_CONFIG_SYSROOT_DIR doesn't really seem to do the right thing -- it only affects path-substitution when there are paths in the output, but doesn't otherwise change how pkg-config operates. -Miles -- Corporation, n. An ingenious device for obtaining individual profit without individual responsibility. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buo7h5a6w2c@dhlpc061.dev.necel.com
Re: *-config programs and multi-arch
Simon McVittie s...@debian.org writes: On Thu, 15 Sep 2011 at 16:53:26 +0900, Miles Bader wrote: Tollef Fog Heen tfh...@err.no writes: Your cross-toolchain is supposed to set up a symlink from /usr/bin/$triplet-pkg-config to /usr/share/pkg-config-crosswrapper which will then DTRT. That's the idea at least, I haven't actually tested it. How is one supposed to make pkg-config use this feature? I mean, say I do: ./configure --host=muckey-muck-muck --build=my-host-type With the symlink Tollef mentioned, that should be all you need. Recent versions of pkg.m4 use AC_PATH_TOOL, so they will try to run arm-linux-gnueabi-pkg-config (if arm-linux-gnueabi is the host triplet) in preference to pkg-config; if arm-linux-gnueabi-pkg-config in your PATH is a symlink to pkg-config-crosswrapper, the right thing is meant to happen automatically. If the depending package was last autoreconf'd with an older version of pkg.m4, it might need an autoreconf to pick up the newer, multiarch-aware version. Hmm, I did autoreconf, and aclocal.m4 didn't change. I looked at the pkg.m4 part of that file, and it does indeed use AC_PATH_TOOL -- but that doesn't seem to really do the proper thing for my cross-compilation test. Ok, to be more concrete, I was trying to use the mingw cross tools. I did: ./configure --host=x86_64-w64-mingw32 --build=`config.guess` of course since there isn't an x86_64-w64-mingw32-pkg-config program, instead it just uses the normal pkg-config, and this does the wrong thing (it _does_ emit a warning message, although it was rather cryptic until I started writing this post). It seems to me that the right thing in this case (no host-prefix tool is found) is simply to act as if pkg-config was not present at all, instead of using the non-host-prefixed version. -Miles -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buo39fy5b8u@dhlpc061.dev.necel.com
Re: *-config programs and multi-arch
Simon McVittie s...@debian.org writes: That's the missing piece of the puzzle: some sort of cross-toolchain package (which doesn't exist yet in Debian - but neither does a cross-gcc) should make the symlink x86_64-w64-mingw32-pkg-config - /usr/share/pkg-config-crosswrapper in your $PATH. For the moment, making that symlink is part of the process of installing a cross-toolchain manually. Ok, but still, it should be more robust when things are not set up properly. It seems to me that the right thing in this case (no host-prefix tool is found) is simply to act as if pkg-config was not present at all, instead of using the non-host-prefixed version. Well, it does give you a warning... perhaps the warning should default to being fatal, but it's basically the same situation as any other missing cross-tool (e.g. if you had a cross gcc but no cross ld). autoconf currently stumbles on regardless, in the hope that your non-cross (build-arch) tool I dunno, pkg-config is different, I think -- unlike a missing compiler or linker, a missing pkg-config often simply means you can't use any libraries for which pkg-config is required, and missing libraries [etc] is an issue which configure scripts are often prepared. So the pkg-config missing = fatal error decision is really something that should be left left to the configure script, not embedded in the pkg-config autoconf macros. However, the current state, where it pretends pkg-config is present, when it really isn't in a useful way, just fools the configure script into doing the wrong thing. [For very important libraries, I often write the library test twice, once with pkg-config, and once using traditional autoconf methods to handle the no-pkg-config case.] AFAICT, the easiest way to handle all this is just to make a missing cross-pkg-config look like a missing pkg-config to the configure script. Then whatever logic the script may have for detecting the not pkg-config at all case, will do the right thing for the cross case too. Thanks, -miles -- The automobile has not merely taken over the street, it has dissolved the living tissue of the city. Its appetite for space is absolutely insatiable; moving and parked, it devours urban land, leaving the buildings as mere islands of habitable space in a sea of dangerous and ugly traffic. [James Marston Fitch, New York Times, 1 May 1960] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vpplvl3@catnip.gol.com
Re: *-config programs and multi-arch
Simon McVittie s...@debian.org writes: That's the missing piece of the puzzle: some sort of cross-toolchain package (which doesn't exist yet in Debian - but neither does a cross-gcc) should make the symlink x86_64-w64-mingw32-pkg-config - /usr/share/pkg-config-crosswrapper in your $PATH. For the moment, making that symlink is part of the process of installing a cross-toolchain manually. Ok, but still, it should be more robust when things are not set up properly. It seems to me that the right thing in this case (no host-prefix tool is found) is simply to act as if pkg-config was not present at all, instead of using the non-host-prefixed version. Well, it does give you a warning... perhaps the warning should default to being fatal, but it's basically the same situation as any other missing cross-tool (e.g. if you had a cross gcc but no cross ld). autoconf currently stumbles on regardless, in the hope that your non-cross (build-arch) tool I dunno, pkg-config is different, I think -- unlike a missing compiler or linker, a missing pkg-config often simply means you can't use any libraries for which pkg-config is required, and missing libraries [etc] is an issue which configure scripts are often prepared. So the pkg-config missing = fatal error decision is really something that should be left left to the configure script, not embedded in the pkg-config autoconf macros. However, the current state, where it pretends pkg-config is present, when it really isn't in a useful way, just fools the configure script into doing the wrong thing. [For very important libraries, I often write the library test twice, once with pkg-config, and once using traditional autoconf methods to handle the no-pkg-config case.] AFAICT, the easiest way to handle all this is just to make a missing cross-pkg-config look like a missing pkg-config to the configure script. Then whatever logic the script may have for detecting the not pkg-config at all case, will do the right thing for the cross case too. Thanks, -miles -- The automobile has not merely taken over the street, it has dissolved the living tissue of the city. Its appetite for space is absolutely insatiable; moving and parked, it devours urban land, leaving the buildings as mere islands of habitable space in a sea of dangerous and ugly traffic. [James Marston Fitch, New York Times, 1 May 1960] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762ktlvkl@catnip.gol.com
Re: *-config programs and multi-arch
I earlier wrote: However, the current state, where it pretends pkg-config is present, when it really isn't in a useful way, just fools the configure script into doing the wrong thing. AFAICT, the easiest way to handle all this is just to make a missing cross-pkg-config look like a missing pkg-config to the configure script. Then whatever logic the script may have for detecting the not pkg-config at all case, will do the right thing for the cross case too. BTW, if such a change isn't made (though I'd be very curious to know why -- is using a non-cross pkg-config _ever_ useful when cross-compiling?), I think there would still need to be a way for configure scripts to detect this situation (a non-cross pkg-config chosen while cross-compiling). Currently I just have my configure script completely disable use of pkg-config when cross-compiling (by setting PKG_CONFIG=), but obviously this is undesirable if a cross-version of pkg-config was actually found... Thanks, -miles -- Occam's razor split hairs so well, I bought the whole argument! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buod3f1m4gl@dhlpc061.dev.necel.com
Re: relationships with GNU as an upstream - call for feedback
Josselin Mouette j...@debian.org writes: I’m not a GNU package maintainer (unless you still consider GNOME a GNU project), so I’m not saying anything about GNU as upstream developers, but if you want to discuss frankly our issues with them, I hope you can talk about RMS and the handful of holier-than-thou followers who ... ... and so the rants begin... -Miles -- ((lambda (x) (list x x)) (lambda (x) (list x x))) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buowrg3akgq@dhlpc061.dev.necel.com
Re: Conditional Recommends
Josselin Mouette j...@debian.org writes:
Package: A
Recommends: A-plugin-B {B}
APT would be made to install A-plugin-B by default, but only if B is
installed too. In addition, it would also have to install it while
pulling B if A is already here.
It would be very nice!
I've noticed many cases where packages recommend a bunch of stuff that,
while it might be very nice for some users, really isn't of general
interest. E.g., recommending a vim plugin when vim isn't installed
(though of course the result of installing the plugin is that vim ends
up being installed too!)
-Miles
--
Acquaintance, n. A person whom we know well enough to borrow from, but not
well enough to lend to.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/buomxie58b5@dhlpc061.dev.necel.com
Re: Best practice for cleaning autotools-generated files?
Simon McVittie s...@debian.org writes: the convention is that autogen.sh *does* call ./configure Huh? This is not my impression at all. I'm sure there probably are packages out there where autogen.sh calls configure, my general sense is that it usually doesn't. Rather, autogen.m4 usually seems to act like autoreconf + appropriate tweaks. -Miles -- Idiot, n. A member of a large and powerful tribe whose influence in human affairs has always been dominant and controlling. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buopqnnhxp6@dhlpc061.dev.necel.com
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
Josselin Mouette j...@debian.org writes: For example, Thunar works perfectly fine outside Xfce, but you don’t want to show it in KDE or GNOME. Why not? Some users may prefer it to the standard app for the desktop environment they're using. -Miles -- Politeness, n. The most acceptable hypocrisy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buooc40kr49@dhlpc061.dev.necel.com
Re: Directories named after packages
Russ Allbery r...@debian.org writes: I'm hesitant to recommend moving the documentation to /usr/share/doc/foo when we've always put it in a directory named after the package in the past; I'm afraid long-time Debian users won't be able to find it. I'd certainly be confused! Being able to just look in /usr/share/doc/PKG is really, really, convenient, even if it only contains symlinks/pointers/whatever referring to the real location. Otherwise looking for related documentation becomes a guessing game (OK, I guess one can do dpkg -L pkg | grep /usr/share/doc, but ...). Thanks, -miles -- Most attacks seem to take place at night, during a rainstorm, uphill, where four map sheets join. -- Anon. British Officer in WW I -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrmhv58t@catnip.gol.com
Re: debian can be better
Mark Allums m...@allums.com writes: In my opinion, and at risk of starting a fruitless spiral into the flames, I think Ubuntu have jumped on the crazy train with 10.10 Maverick Meerkat. Just out of curiosity, what changed with that version...? -Miles -- Dictionary, n. A malevolent literary device for cramping the growth of a language and making it hard and inelastic. This dictionary, however, is a most useful work. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hgy853o@catnip.gol.com
Re: debian can be better
Michael Banck mba...@debian.org writes: Just out of curiosity, what changed with that version...? Miles, you can lookup their release notes if you like, but this question is really unappropriate for this list. If such information is deemed too inflammatory, an off-list reply would be cool too... Thanks, -Miles -- Friendship, n. A ship big enough to carry two in fair weather, but only one in foul. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjzl7o75@catnip.gol.com
Marius Vollmer [magit] MIA?
Hi, He's the maintainer of the magit package, which doesn't seem to have received any attention in a long time. I sent email to him a few weeks ago, but haven't received any reply. Has anyone had contact with Marius Vollmer, or know what's up with the magit package? Thanks, -Miles -- Innards, n. pl. The stomach, heart, soul, and other bowels. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eic7yb2a@catnip.gol.com
Re: Marius Vollmer [magit] MIA?
Paul Wise p...@debian.org writes: Usually it is a good idea to CC the allegedly MIA maintainer (done on this mail). Have you done any of the things suggested by the devref? http://www.debian.org/doc/developers-reference/beyond-pkging.html#mia-qa Thanks for the tips -- I'm not a DD, so I don't think I access to non-public databases, etc, but these developers-reference guidelines seem useful for the future. [I'm guessing that MIA queries may often come from non-DDs because it's the users of a package that are most likely to notice inactivity.] I did try to look for activity outside of debian but didn't find anything recent... Thanks, -Miles -- The automobile has not merely taken over the street, it has dissolved the living tissue of the city. Its appetite for space is absolutely insatiable; moving and parked, it devours urban land, leaving the buildings as mere islands of habitable space in a sea of dangerous and ugly traffic. [James Marston Fitch, New York Times, 1 May 1960] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocbawxbv@catnip.gol.com
Re: Bug#560786: gdb: Please make the python dependency optional
Python does seem a very poor choice for this kind of application, given the traditional bloat of a python installation, but I suppose they've made their decision... -Miles -- ... The revolution will be no re-run brothers; The revolution will be live. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#560863: ITP: lamson -- The Python SMTP Server
Sebastian Otaegui fen...@gmail.com writes: Lamson's goal is to put an end to the hell that is e-mail application development. Rather than stay stuck in the 1970s, Lamson adopts modern web application framework design and uses a proven scripting language (Python). How about dropping all the breathless and annoying advertising-speak from the description? -Miles -- Neighbor, n. One whom we are commanded to love as ourselves, and who does all he knows how to make us disobedient. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian, universal operating system?
Chris Lamb la...@debian.org writes: Agreed. IMHO, it is one of those phrases (along with Our priority is our users) that actually means extremely little in practice, except for generating lots of hot air with nobody agreeing. Our priority is endless surreal flamewars over minor technicalities seems about right to me. -miles -- Defenceless, adj. Unable to attack. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Goswin von Brederlow goswin-...@web.de writes: And why should there be. The package it totally usable and functional as designed. Does it properly support aptitude / synaptic / etc yet? [The whole print a message on stdout telling the user he'd better do something else thing was dodgy beyond belief, and clearly is not acceptable for testing.] -Miles -- Brain, n. An apparatus with which we think we think. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Goswin von Brederlow goswin-...@web.de writes: Does it properly support aptitude / synaptic / etc yet? [The whole print a message on stdout telling the user he'd better do something else thing was dodgy beyond belief, and clearly is not acceptable for testing.] Sure the support isn't perfect yet. But it is useable. Not useable enough for testing though, that's all I'm saying. -Miles -- Run away! Run away! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Yannick yannick.roeh...@free.fr writes: Correct me if I'm wrong, but doesn't multiarch do the same thing as ia32- apt-get but at the distribution level? My impression is that it's not necessarily the abstract idea of ia32-apt-get that's so wrong, but rather the apparently clumsy way it was implemented. I, at least, was completely taken by surprise when everything started breaking, and get the feeling that one of the big problems is that all of this was done without adequate communication/consultation beforehand. [Ok, maybe I just missed the pre-breakage discussion/flames (the post-breakage discussion/flames are all too obvious :), but this seems much less carefully planned than most debian transitions...] -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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Roger Leigh rle...@codelibre.net writes: Although I use amd64, I have yet to want to install any 32bit software, so I'm not entirely sure what the use case is for it. While I agree in general, I do occasionally want a more fully functional 32-bit system infrastructure. Typically this is when I need to compile a program which is buggy, and has 32-bit assumptions in it, or runs faster in 32-bit mode, or whatever. When all the libraries the program needs are available in ia32-libs, then gcc -m32 works great, but when they _aren't_, it can get miserable pretty quickly. So I love the _idea_ of a seamless automatic system for installing arbitrary 32-bit libraries on amd64. The current ia32-apt-get thing, seems pretty kludgey and fragile though... [I've reverted my systems to the old versions for the time being and have a lot of packages on hold... hopefully after a while either things will be a bit more solid or these changes will have been backed out.] -Miles -- Barometer, n. An ingenious instrument which indicates what kind of weather we are having. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
Manoj Srivastava sriva...@debian.org writes: and documentation all over the place that assumes the Debian default is Exim I think that's a weakness that should be addressed regardless of what happens with the default. [Of course changing defaults is one way to force the issue a bit, but of course it doesn't stop people from just replacing one assumption with another...] -Miles -- Most attacks seem to take place at night, during a rainstorm, uphill, where four map sheets join. -- Anon. British Officer in WW I -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?
Ben Finney ben+deb...@benfinney.id.au writes: You're arguing that a Reply-To header is harmful (not that I am convinced) That field is very useful. What's harmful is mailing-list software munging that field, which is for the author to set and for nothing else to fiddle with. Yup. Reply-To is for the _original sender's_ use! If mailing list software were to start setting Reply-To, what is it supposed to do if it gets a message with Reply-To already set (by the original sender)? It could (1) overwrite the original Reply-To header, breaking personal replies to the sender, or it could (2) refrain from setting Reply-To for such messages, completely confusing the readers who have become accustomed to depending on the mailing-list's setting. I think there's no perfect solution to the general problem, because there's too wide a variety of MUAs in use, which support different feature sets. But it's much better to get duplicate messages in some cases than to break things in a way that leads to _lost_ messages. My experience is that in practice, it's not such a huge problem anyway; a combination of MUA list-followup commands + Mail-Followup-To: headers + MUA duplicate suppression seems to keep duplicates in check reasonably well... -Miles -- If you can't beat them, arrange to have them beaten. [George Carlin] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#465809: ITP: hpt -- Creates a TCP tunnel through http and https proxies
Christian Perrier [EMAIL PROTECTED] writes: tunnelling utility through HTTP and HTTPS proxies to better fit the write style recommended in DevRef. Or with correct grammar: utility for tunneling through http and https proxies -Miles -- Generous, adj. Originally this word meant noble by birth and was rightly applied to a great multitude of persons. It now means noble by nature and is taking a bit of a rest. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#465813: ITP: cyclone -- Safe dialect of C
Michael Tautschnig [EMAIL PROTECTED] writes: Description : Safe dialect of C I suggest C-like compiler with improved security checks I disagree - dialect is the proper technical term here. Though the actual thing being compackage seems to be a compiler, so: compiler for a safe dialect of C -Miles -- Bacchus, n. A convenient deity invented by the ancients as an excuse for getting drunk. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposition: 'NMU' upload of wxwidgets 2.8
Dirk Eddelbuettel [EMAIL PROTECTED] writes: if you appreciate using Debian as a development platform, the fact that CodeBlocks can't be built on it is IMHO a pretty critical problem. Why? Maybe because not being able to build and development platform don't go so well together? Differently put, why do you think that NOT having current versions of a popular library, here wxwidgets in version 2.8, is a feature and not a bug? I don't. I'm just questioning the (apparent) assertion that the presence or lack of CodeBlocks is critical to those who appreciate using Debian as a development platform. Surely 99% of people who do development on Debian haven't even _heard_ of CodeBlocks. -Miles -- Patience, n. A minor form of despair, disguised as a virtue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposition: 'NMU' upload of wxwidgets 2.8
Vadim Zeitlin [EMAIL PROTECTED] writes: if you appreciate using Debian as a development platform, the fact that CodeBlocks can't be built on it is IMHO a pretty critical problem. Why? -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Manoj Srivastava [EMAIL PROTECTED] writes:
Umm. Why would any distributed version control system always
need history truncation? I am not even sure that arch has such a
thing; and I have never felt the need for such a beast.
A distributed VCS that bundles in the whole archive in every
checkout might well need that, but not all distributed VCS systems do
that.
I wouldn't be surprised if arch took as much room to store log files
({arch}/...) as e.g. git takes to store the actual content of historical
revisions. Deleting those log files is arch's version of history
truncation.
[Not that I've actually felt the need to do so, but they do take up a
lot of room...]
-Miles
--
.Numeric stability is probably not all that important when you're guessing.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposition: 'NMU' upload of wxwidgets 2.8
Dirk Eddelbuettel [EMAIL PROTECTED] writes: Wearing a Debian 'user' as well as 'developer' hat, I was stopped in the tracks a few days ago when I tried to look at some C/c++ IDE (code::blocks) which would not configure on my testing box due to a lack of wxWidgets 2.8. Not nice at all. I can typically rely on Debian for having recent and common software. In this case, Ubuntu won. So are the purported problems with wxw 2.8 bad or not? -Miles -- /\ /\ (^.^) ()) *This is the cute kitty virus, please copy this into your sig so it can spread. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#455730: ITP: lua-peg -- Parsing Expression Grammars For Lua
Enrico Tassi [EMAIL PROTECTED] writes: Package name: lua-peg Version: 0.7 Upstream Author: Roberto Ierusalimschy [EMAIL PROTECTED] URL: http://www.inf.puc-rio.br/~roberto/lpeg.html License: MIT/X Description: LPeg is a new pattern-matching library for Lua, based on Parsing I think it's going to cause a lot of confusion if you call this package lua-peg -- _everybody_ knows it as lpeg... [But it's definitely a great thing to package:-] -Miles -- `Suppose Korea goes to the World Cup final against Japan and wins,' Moon said. `All the past could be forgiven.' [NYT] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#455730: ITP: lua-peg -- Parsing Expression Grammars For Lua
Stefano Zacchiroli [EMAIL PROTECTED] writes: I think it's going to cause a lot of confusion if you call this package lua-peg -- _everybody_ knows it as lpeg... Hence, I guess, the proposed name would be lua-lpeg, right? That seems best... The crucial thing, I think, is that somebody searching for lpeg finds it. -Miles -- I distrust a research person who is always obviously busy on a task. --Robert Frosch, VP, GM Research -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MTA comparison (postfix, exim4, ...)
Osamu Aoki [EMAIL PROTECTED] writes: For me, exim4 is better: * less memory on run time * mailname is implimented as expected by the policy. Postfix has a reputation for being faster and more secure than exim. Why is it worth worrying about, though? Are the difference between exim and postfix really great enough to matter for typical use?!? [If you're a high-volume mail site, of course, you will care about the difference, but then you should be doing your own analysis...] -MIles -- My books focus on timeless truths. -- Donald Knuth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
Daniel Jacobowitz [EMAIL PROTECTED] writes: If you enforce longer passwords than people are comfortable with, you get weaker passwords (or poor password management practices). It's the humans that matter, not the machines. Exactly. If the system is excessively anal about what passwords it will let you use, people will just start writing them down... [One system I like is the password strength meter that you get when signing up for a gmail account, updated with every keystroke when entering a password. I don't recall whether it actually enforced anything, but I think when the user can see what's happening and very easily make incremental modifications, the results would tend to be better.] -miles -- (\(\ (^.^) ()) *This is the cute bunny virus, please copy this into your sig so it can spread. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what happened to social contract?
Peter Samuelson [EMAIL PROTECTED] writes: I think your problem is that you have confused our priorities are our users... with our priority is everything icelinux believes might help some subset of our users. To which I can only say, get over yourself. Do you really expect any different from someone calling himself icelinux? -miles -- .Numeric stability is probably not all that important when you're guessing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: ttf-atarismall -- Very small 4 x 8 font
Peter Samuelson [EMAIL PROTECTED] writes: If anyone knows how to limit the fontsize to 8 only for a otf/ttf font, please contact me. (The original font is in bdf format) If this font is intended to be used at one fixed size, why bother with ttf/otf at all? Just ship it as bdf. Aren't the former formats more generally usable these days (e.g. by various apps that do their own font blathering, not necessarily for display)? -miles -- `Life is a boundless sea of bitterness' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Andrew Lau (netsnipe) MIA?
Roger Leigh [EMAIL PROTECTED] writes: The packages he maintains and co-maintains are listed below. Most are GNOME packages he has not apparently uploaded. Some are already comaintained by others. The two of most concern are cinepaint and cupsys-pt, which are not comaintained. cinepaint has since had several NMUs to fix build issues. ... openexr 20050819Yes Yes The openexr package also seems to be fairly out of date -- the current debian version is 1.2.2 (from 2005); the latest release version (from savannah.nongnu.org) is 1.5.0. [I filed a wishlist bug saying this about 6 months ago, with no reply yet.] -Miles -- Suburbia: where they tear out the trees and then name streets after them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#427297: ITP: sturmbahnfahrer -- simulated obstacle course for automobiles
Klaus Ethgen [EMAIL PROTECTED] writes: So please calm down and come back to the reality and do not try to see nazis in all thinks in the world. Amen. I'm reminded of vehement protests over a public official's use of the word niggardly... -Miles -- `To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Eduard Bloch [EMAIL PROTECTED] writes: What is not really understandable is why this stupid naming has been kept in Windows XP. Because nobody actually cares except control-freak types, and they're certainly not who windows is targetting! -Miles -- `To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Magnus Holmgren [EMAIL PROTECTED] writes: No it doesn't. The SI binary prefixes are an abomination. Why - besides pronunciation? Well among other things, the end result of this whole mess will likely be to _increase_ confusion, rather than lessen it: Until now, in a typical computer app, 900K had an unambiguous meaning: 900*1024. Now that a bunch of people are all in a misguided frenzy to correct things (which weren't broken), there will almost certainly be cases where some silly fool will change the _calculation_ but not the label (e.g., in a case where space is at a premium) -- e.g., they'll keep K, but change the calculation to / 1000, because that's correct. However it's _guaranteed_ that many apps will stick with / 1024. Thus a suffix (e.g. K) which was previously unambiguous in practice (and no, disk-drive advertisements don't count) will have become more ambiguous in practice. [At which point of course the kib-fans will start crying out that because things are now very confused, we muuust switch to gib suffixes -- all because they basically screwed things up.] Great. -Miles -- `To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
shirish [EMAIL PROTECTED] writes: It isn't just ubuntu or debian but this needs to be done everywhere. No it doesn't. The SI binary prefixes are an abomination. Kibibytes? Christ... [Did they try pronouncing these horrid things when standarizing them?!?] -Miles -- We are all lying in the gutter, but some of us are looking at the stars. -Oscar Wilde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Bastian Venthur [EMAIL PROTECTED] writes: I agree with the sounds stupid part, although I don't belive this is a valid argument. What I don't believe is your 80 colums argument. Could you please name a few of the *many* programs which would have to drop information, precision, or significantly change their display to use the KiB unit? E.g. all of the top-type programs, which display stuff in colums like memory sizes etc, and are _extremely_ starved for space. It would be ludicrous to change the memory size displays in such programs from 224K to 224KiB just to give some obsessive-compulsive types a warm fuzzy. On the other hand, we have the chance to avoid user confusion No one is actually confused. This standard doesn't actually solve a real problem. -Miles -- Whatever you do will be insignificant, but it is very important that you do it. Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Steve Greenland [EMAIL PROTECTED] writes: Since then, it seems like most users have switched to apt-get and synaptic, with hardly anyone using aptitude or dselect any more Really? I'd have guessed that most people used aptitude. I can't imagine anyone preferring synaptic to aptitude. Yeah, that was my impression too, at least from reading debian mailing lists. A lot of people still like apt-get, but there seems to be a fairly strong movement to aptitude, and synaptic is sort of in the oh some people use that too category (no doubt the numbers are different among unsophisticated users, but they're harder to see). -Miles -- Suppose He doesn't give a shit? Suppose there is a God but He just doesn't give a shit? [George Carlin] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`
Jari Aalto [EMAIL PROTECTED] writes: Le't call this wishlist if we need to be pedantic. I would still call this a bug from a QA perspective. Quality is more than valid syntax. It's not a bug from any perspective, it's you trying to legislate your personal tastes. The place for that is a rant in your blog, not in debian's bug system. While there are certainly times most people would want to use $(), there's absolutely nothing wrong with `` in many circumstances. -Miles -- Next to fried food, the South has suffered most from oratory. -- Walter Hines Page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Message header fields
Ben Finney [EMAIL PROTECTED] writes: Meanwhile, the message header is about the message *as an email message*, and the From field is supposed to be about the individual who sent the message. ... unless there's a Sender: header, in which case _that's_ the person who send the email, and the From: header names the true sender of the message. [Every once in a while the Emacs mailing list gets email from Donald Knuth, who as you may have heard, has sworn off the use of email. In these messages, From: is Knuth himself, and Sender: is his secretary, who is the person that actually sent the message.] -Miles p.s. The sig below is from my random sig-generator, which strangely often seems to pick signatures which are apopos to the message at hand! -- My books focus on timeless truths. -- Donald Knuth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Mirror with lzma compressed packages
Goswin von Brederlow [EMAIL PROTECTED] writes: A few more examples below. I think lzma isn't the right thing for the archive. p7zip seems much faster, needs a lot less ram and compression is similar. .. Should you be using the -9 option? The lzma help output says this: -3 .. -9 good to excellent compression. -7 is the default. --fast alias for -1 --best alias for -9 (usually *not* what you want) Feel free to try other options. Er, I was just pointing out that your conclusion (lzma isn't the right thing ... p7zip seems must faster and needs a lot less ram) is rather dodgy because you used an option that lzma specifically warns against using. From my own experiencd I know that lzma consumes much more memory with -9 than with the default setting. So though I'm certainly in no position to repeat these tests myself, I think others should be wary of your results. -Miles -- o The existentialist, not having a pillow, goes everywhere with the book by Sullivan, _I am going to spit on your graves_. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Mirror with lzma compressed packages
Goswin von Brederlow [EMAIL PROTECTED] writes: A few more examples below. I think lzma isn't the right thing for the archive. p7zip seems much faster, needs a lot less ram and compression is similar. ... Lzma: 34306752 Bytes Compressing : 19410 mrvn 0 376m 370m R 97.2 36.9 1:58.33 lzma -9 Decompressing: 19488 mrvn 0 100m 79m R 96.8 7.9 0:03.24 lzma Should you be using the -9 option? The lzma help output says this: -3 .. -9 good to excellent compression. -7 is the default. --fast alias for -1 --best alias for -9 (usually *not* what you want) -miles -- = (^o^; (())) *This is the cute octopus virus, please copy it into your sig so it can spread. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: localisation in system wide daemons
Manoj Srivastava [EMAIL PROTECTED] writes: Merriam-Webster is falling into the old non-PC over-generalization that all inhabitants of India are Hindus. Merriam-Webster isn't falling into anything, it's a dictionary, and dictionaries describe usage. I know from reading old books that this particular usage (usually with the slightly odd spelling given hindoo) used to be very common. I presume that most people these days are better informed, so perhaps there should be some notation in the dictionary like archaic or whatever, but I don't know if they generally make such distinctions. -Miles -- We have met the enemy, and he is us. -- Pogo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: localisation in system wide daemons
Manoj Srivastava [EMAIL PROTECTED] writes: I hate to break it to you (and I do sincerely apologize for spoiling your innocence), but lexicons are not handed down to mankind on tablets writ in stone as some kind of divine donation. I was not claiming that. Indeed, I was claiming exactly the opposite, that the dictionary was describing a _usage_ of the word by english speakers. I've personally seen many such uses with exactly the meaning given, so it's pretty clear to me that the dictionary has not somehow screwed up in that mission. As I said, it's more or less archaic usage these days, and it would be nice if they indicated that, but I do not know how dictionaries handle such cases in general. -Miles -- Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: localisation in system wide daemons
Manoj Srivastava [EMAIL PROTECTED] writes: The etymology of the word is not english: (Hindu + stan). When incorporating it into English, the word came with a well defined meaning. Apparently the english authors who used it didn't realize that, and I assume their usage reflects the general usage at the time they were writing. Anyway, for whatever reason, the given usage was present, and reasonably common, _in english_ at one time. The dictionary documents that, as is their job. -miles -- Any man who is a triangle, has thee right, when in Cartesian Space, to have angles, which when summed, come to know more, nor no less, than nine score degrees, should he so wish. [TEMPLE OV THEE LEMUR] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bugs in default GNOME etch?
Michael Banck [EMAIL PROTECTED] writes: Well we shouldn't keep ourselves hostage of stupid upstream behaviour, should we? Contrary to us, GNOME (in this case RedHat) actually employs usability experts. Who are we to think we know better? Actual users? -Miles -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bugs in default GNOME etch?
Josselin Mouette [EMAIL PROTECTED] writes: Having eog and evince in the menu serves the I want to look at a file I know I have on my disk case. But you can open the file in the same number of clicks but with a better interface, by launching a nautilus window. Better interface for some people perhaps. I don't run Nautilus at all (and don't want to, it's simply not a very nice program), but I certainly use Gnome apps to look at files. The Gnome project has apparently developed an enormous blindspot because of their fixation with novice users, but Debian need not follow this. That's the beauty of free software. -Miles -- `Cars give people wonderful freedom and increase their opportunities. But they also destroy the environment, to an extent so drastic that they kill all social life' (from _A Pattern Language_) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing sodipodi
Brian May [EMAIL PROTECTED] writes: Eventually I guessed that inkscape was a newer version of sodipodi, and not a competing program. oh ... really? That's one confusion cleared up... -miles -- 自らを空にして、心を開く時、道は開かれる -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Downgrading the priority of nfs-utils
Steinar H. Gunderson [EMAIL PROTECTED] writes: The university here is opening up for Kerberos-enabled NFSv4 from the entire campus network RSN. Now you know one :-) [Isn't nfs4 rather different than previous versions, in that it's fixed some of the most egregious nfs bogosities?] I use nfs everyday, and in its default form it's insanely slow, completely insecure, and annoyingly clunky to administer -- but it's what people use... and there really isn't much in the way of widely available, easily deployable/maintainable, legacy-compatible alternatives. All things considered I'd rather have nfs, even in it's horrid traditional form, than nothing. -Miles -- `Cars give people wonderful freedom and increase their opportunities. But they also destroy the environment, to an extent so drastic that they kill all social life' (from _A Pattern Language_) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
Wouter Verhelst [EMAIL PROTECTED] writes: That's a bad example. X is a client/server system for a reason. E.g., there is no graphical hardware for s390, yet it can still be a good idea to use X software on s390 hardware with X terminals. Yeah, that's the thing -- while maintainers are usually competent to judge can't (i.e., non-trivial porting effort is required), they often don't seem any better than anyone else at judging shouldn't / don't-need-to . Users do all _kinds_ of weird things... -Miles -- `The suburb is an obsolete and contradictory form of human settlement' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: adun.app -- a Molecular Simulator
Frank Küster [EMAIL PROTECTED] writes: .app is pretty much meaningless. Therefore I'd prefer if you'd use a suffix with a less arcane meaning, like -gnustep. Does anyone truly care? Is it worth any effort to rename? -miles -- Unless there are slaves to do the ugly, horrible, uninteresting work, culture and contemplation become almost impossible. Human slavery is wrong, insecure, and demoralizing. On mechanical slavery, on the slavery of the machine, the future of the world depends. -Oscar Wilde, The Soul of Man Under Socialism
Re: Moving /var/run to a tmpfs?
Hendrik Sattler [EMAIL PROTECTED] writes: Which OS combination does not define int to be 32bit on a 64bit architecture? long should better be 64bit then as many assume that you can cast a pointer into a long and back (e.g. timer in the linux kernel has a long for private data and not a void*, really sick). I meant long, not int. Sorry. -Miles -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- Donald Knuth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
Steve Langasek [EMAIL PROTECTED] writes: It is also clear that this is how many maintainers have understood it, because as you yourself have noticed, there are many packages that assume they can ship directories in /var/run and have them remain available after reboot. :) I think it's more likely that the average maintainer just never thought about the issue, and did what they did because it works. I.e. the same reason many people used to assume int was 32 bits. When 64-bit processors became common, lots of programs broke. The solution to that was to educate programmers to be more careful and assume less, not to retroactively add silly restrictions to the definition of int. -miles -- Any man who is a triangle, has thee right, when in Cartesian Space, to have angles, which when summed, come to know more, nor no less, than nine score degrees, should he so wish. [TEMPLE OV THEE LEMUR] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why not only support Sid and Testing?
Marc Haber [EMAIL PROTECTED] writes: http://www.markshuttleworth.com/archives/56. It says 76% of Debian users run unstable and probably a fair fraction of the rest run testing. I tend to doubt these numbers, especially if they come from a source that is known for its Ubuntu / Canonical marketing blurb. Yeah, especially since the kind of person who runs stable is, I expect, much less likely to answer web polls etc... :-) -Miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to rethink ifupdown
martin f krafft [EMAIL PROTECTED] writes: Python (and any language that depends on vast amounts of installed infrastructure) seems a bit dodgy for a core low-level facility. It's a great language to develop stuff at a moderate speed. It may well be (kinda ugly though) -- but that doesn't mean it's appropriate for a core system facility, which often needs to work even when the system is in a degraded state. -Miles -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
