Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Thu, Dec 02, 2004 at 12:38:03AM +0100, Michelle Konzack wrote: > Am 2004-12-01 18:23:47, schrieb sean finney: > > > then don't give your daughter sudo privileges on your debian machines, > > and she can't install it! :) > > Too late... She is 13 and Administrator already... > Had learned very fast how to 'rm -rf /' and reinstall it alone. Really, she's 13, and you think it'd do any difference whatsoever to expose her to a pixelled image of a nude woman?! Sheesh. Either you've been shielding her completely (no TV, no advertisments, no magazines, no Internet), or you need a reality update. Worried parents should realise, that if their kids are old enough to administrate a Debian-machine to the level of installing their own packages, they've already been exposed to nudity. Lots of times. And they should probably worry more about the cases of non-nudity that are far more hurting, like all commercials with near-anorectic plastic-wonders on billboards, etc, from companies constantly trying to push for the image of the ideal woman as someone who is malnourished, probably will have backproblems before the age of 30 because of frontal overweight, and generally likes drinking alcohol in her underwear... Whether the package hotbabe is something that should be in Debian or not I leave up to others to decide, but personally I feel it to be on the same utility level as xeyes (that is, none, but probably amusing to some persons for a day or two). I can agree that putting the work erotic in the package description might not be ideal though; a.) I had a look at the pictures and I have a *very* hard time finding them even mildly erotic... b.) it'll definitely annoy people. But please wake me up when bible-kjv-text has been removed. Descriptions of rape, incest, murder, and about everything else, cannot possibly be good for children to read about, now can it?! As for hotbabe being pornographic? Nah. It does it's fair share to objectify women though, something that I find more worrying. Indeed, in a society where people were more equal (and more relaxed about sexuality), the porn industry would very likely both be sanitised and less prosperous. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Wed, Dec 01, 2004 at 11:32:18PM +, Will Newton wrote: > On Wednesday 01 Dec 2004 21:35, Manoj Srivastava wrote: > > > Right. We should not have games like quake, doom, or > > nethack,. since they promoite murder and mayhem and eating of > > corpses. > > So far so sarcastic. IMO if it can be demonstrated that distributing > something is illegal we should think about not distributing it. And, as demonstrated elsewhere in the thread, whoops goes bible-kjv-text. > We are not the EFF. If they or anyone else wants to fight for the No, we're not. We're also not the PTA or the moral police. > right to look at cartoon tits then that's fine by me. We are trying to > build an operating system. I think. Indeed. From that point of view, hotbabe is pretty meaningless. Then again, so is quake, doom, nethack, etc. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thu, Dec 02, 2004 at 08:15:16AM +1100, Matthew Palmer wrote: > On Wed, Dec 01, 2004 at 08:50:08PM +0200, Kalle Kivimaa wrote: > > Yes, hotbabe is sexist (at least in it's current incarnation - if it > > included a male theme then it would only be sexually offensive to > > some) > > Anyone who feels that hot-babe would become less sexually offensive because > it included naked male images as well as naked female images really does > need to rethink their ideas about offensiveness. Somehow putting more > offensive images into a package doesn't strike me as being the way to make > something less offensive. Not less sexually offensive. But adding naked male images would probably take the edge of the argument of the package being sexist. > Personally, I don't have a problem with the package as-is -- the pictures > aren't exactly the most graphic thing that's likely to pop up unannounced in > a web-browser window, but the authorities frown on distributing anything > tittilating to minors in a lot of places, so I'd "vote" for making it a > series of pictures of a tree shedding it's leaves or something in the > default incarnation. While being all for that series of pictures (nature is beautiful), I find the package pretty meaningless anyway, so I don't see the point of including it in Debian in the first place. I do, however, see some relevance to the discussions. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Thu, Dec 02, 2004 at 04:07:14PM +0100, Michelle Konzack wrote: > Am 2004-12-02 08:44:34, schrieb David Weinehall: > > > Really, she's 13, and you think it'd do any difference whatsoever to > > expose her to a pixelled image of a nude woman?! Sheesh. Either > > you've been shielding her completely (no TV, no advertisments, > > no magazines, no Internet), or you need a reality update. > > And if she does not like violence and naked people ? Well, the first shows she's quite tasteful, the second might be a problem during physical education, no? (But I realise you didn't mean it that way). The question is, who would install the package on her computer? She surely wouldn't. She'd probably dodge the pr0n-sites on the Internet too. Why worry? > And publicity using half naked people is offensive !!! Sure, I didn't say otherwise. Of course, it depends on what you're doing commercials for. If it's underwear, I can see the point. Then again, the market for underwear is probably not big enough to warrant billboard ads with supermodels; they are rather an excuse for using semi naked surgically modified anorectics to sell everything else the stores have to offer. That's sad, but as long as people keep buying their products, the ads will continue. > > Worried parents should realise, that if their kids are old enough to > > administrate a Debian-machine to the level of installing their own > > She has an IQ enorm and will make her Lycee examen next year. > 4 years before the others... I didn't question that, and I'm glad to hear you have such an intelligent daughter. > She do not like to see everywhere naked People... > > It is TOO much ! > > Exhibiting of naked women is offensiv and disriminating. > Even it is a cartoon. I hate mens using women as sexobjects... Objectifying women is indeed degrading, both to women and men. Naked people as such isn't, it's natural and beatiful. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bug#283578: ITP: hot-babe -- (abusive?) erotic images in Debian
On Fri, Dec 03, 2004 at 02:12:19PM -0800, Martin Olsson wrote: > > I have not seen this image thus I do not if I would find it offensive or > not. Could someone please upload a .png of it somewhere and post the URL? The ITP contains a link to the source for the package. You *really* need to have a look at the pictures. All of your argumentation below about pron neatly goes *wooosh*. [snipped totally irrelevant though eloquent reasoning] > I'm not advocating a limitation on the freedom of speech though, neither > am I saying that nudity is an unmoral thing per se. I believe that it's > necessary to depict/discuss/describe even 'bad' things such as brutal > violence, exploitation, rape and war in a non-sugarcoated form. The > problem is typically the context, when an image depicting rape is > presented as entertainment I strongly oppose it. Again, have a look at the pictures *before* making comments. I don't doubt that you have have these opinions; in fact, I suspect most people here agree with you (I do). It's not really relevant wrt these pictures, however. [snip] Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bug#283578: ITP: hot-babe -- (abusive?) erotic images in Debian
On Mon, Dec 06, 2004 at 04:35:41PM +1100, Brian May wrote: > >>>>> "Tollef" == Tollef Fog Heen <[EMAIL PROTECTED]> writes: > > Tollef> | Finally, I would like to commend Michelle Konzack for > Tollef> standing up on | this issue. Debian should never promote | > Tollef> degradation/abuse/exploitation, in any form, of females > Tollef> (or males or | blacks or whites or whatever). Be careful with your attributions, that was written by Martin Olsson, not Tollef Fog Heen. > Tollef> Please take a look at the images and I'd be surprised if > Tollef> you feel them degrade, abuse or exploit females. I think > Tollef> they are silly and nothing to be upset about. Not porn, > Tollef> not erotic, just silly. This part, was written by Tollef though =) [snip] Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Debian package selection depending on user location/belief/society(was bug #283578 hot-babe (AGAIN :-)))
On Tue, Dec 07, 2004 at 09:49:57AM +, Will Newton wrote: [snip] > Not to point out the obvious, but "foul language" is dependant on the > language you speak, so most countries are unlikely to be offended by > the Linux kernel. Not to point out the obvious, but what is pornographic is dependant on the viewer, so most people are unlikely to be offended by the artwork in hotbabe... Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: The 98% and N<=2 criteria (was: Vancouver meeting - clarifications)
On Fri, Mar 18, 2005 at 11:32:08PM -0800, Steve Langasek wrote: [snip] > As pointed out in a recent thread, most of the core hardware portability > issues are picked up just by building on "the big three" -- i386, powerpc, > amd64. If we know the software isn't going to be used, is it actually > useful to build it as a "QA measure"? What value is there, in fact, in > checking for bugs that will only be tripped while building software that > isn't going to be used? Because bugs are bugs, no matter if they bite us currently. That said, I'm a firm believer of the suggestion posed by Jesus Climent[1], that we should have base set of software (where base is probably a bit bigger than our current base) released for all architectures that have a working installer, and then only have full official releases for a limited set of architectures. This way, we'd both satisfy people using Debian as a base for embedded and other customised systems, and most (but not all) porters. Of course some people are never satisfied, but then again, there is no way to solve this that makes everyone happy. [1] Hopefully, I might remember incorrectly. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // ~ // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
On Mon, Dec 19, 2005 at 09:58:30PM -0600, Peter Samuelson wrote: > > [Thomas Hood] > > Any other defenders of /lib/run? Of /run? > > /etc/run. mtab and resolv.conf and the lvm1 state files and so forth > always lived in /etc before, so there's continuity. Oh please, let's not dump even more crap into /etc; it's ugly enough as it is... Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Tue, Jan 17, 2006 at 09:25:40AM -0800, Matt Zimmerman wrote: [snip] > There will always be differing personal preferences, but in spite of these, > there are times when an organization needs to take an official position on > behalf of its members, even if they don't all agree, so that other > organizations can respond to it with confidence. If a consensus can't be > reached informally, that's what I think we will need. Why would Debian need to take an official position on behalf of its members? Yes, I can see that it would be in Ubuntu's best interest for Debian to do so, but since it's obvious from this discussion that different Debian developers have different opinions on this issue, it's clearly not in Debian's best interest. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Sun, Jan 22, 2006 at 02:26:57AM -0800, Scott Ritchie wrote: [snip] > In the case of such a package, the same fixes by the Debian maintainer > to the Debian package do end up in the contents of the Ubuntu package > when it gets resynched. > > Now, before I confuse myself with word games and contemplate whether > that implies "control" or not, I'm going to offer up the conjecture that > bug reports on an Ubuntu universe package are potentially more relevant > to a Debian maintainer than bug reports on a Debian stable package, > since they're closer to the current unstable. Since all Ubuntu packages are recompiled against a different set of libraries, the bug might not even affect the Debian package, even though they share the same source. Hence having Ubuntu developers triage the bugs to rule out such issues before they are forwarded to Debian's BTS is always a good thing; thus the maintainer field should be changed for *binary packages*. The source is the same, so the field should NOT be changed for *source packages*. If the bug indeed exists in both Ubuntu and Debian, then the bug is in the source and needs fixing in Debian too, but if the bug is caused by the Ubuntu build environment, then the bug is purely in the package, and any bugreport would just waste the Debian developer's time, *AND* risk Ubuntu losing vital information about a bug in their build environment. Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: helix player package for debian?
On Wed, Feb 08, 2006 at 11:18:10AM -0900, Britton Kerin wrote: > > is anyone working on packaging helix player? I'd like to see > RealPlayer packaged also, though it would have to go in > non-free of course. > > I saw an old resolved RFP for helix, but searching in synaptic > doesn't show up any matches for helix. apt-cache search helix-player yields: helix-player - the helix audio and video player Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system
On Sat, Feb 18, 2006 at 03:30:38AM -0500, Kevin Mark wrote:
> On Sat, Feb 18, 2006 at 09:02:57AM +0100, Javier Fern?ndez-Sanguino Pe?a
> wrote:
> > On Fri, Feb 17, 2006 at 11:55:22PM +0100, Guerkan Senguen wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > >
> > > * Package name: freebsd-manpages
> > > Version : 6.0
> > Wouldn't this package conflict with the 'manpages' package (which
> > provides them for GNU/Linux) and with the manpages provided by other
> > (core) packages? Or are all manpages going to be renamed so that
> > there is no filename conflict under /usr/share/man/man{2,4}?
> >
> > Regards
> >
> > Javier
>
> Hi,
> if 'manpages' are GFDL and freebsd-manpages is under a bsd license,
> then if freebsd-manpages CAN replace manpages and GFDL docs are
> removed, then there will be no conflict.
a.) The manpages packages does not (AFAIK) contain any GFDL docs;
it's not provided by FSF, since they have a strange aversion
against manpages, and an even stranger predilection for info
pages...
b.) The package itself does not *need* to conflict with the manpages
package, since it provides manpages for 4, 5, and 7,
(and manpages-dev provides 2, and 3).
Replaces: manpages, manpages-dev
is needed though.
HOWEVER, since manpages-dev presumably contains documentations for
interfaces that are Linux specific, it might make sense to have a
Conflicts: manpages, manpages-dev
anyway. This would mean that users of Debian GNU/FreeBSD would lose
the manual-pages for glibc though (since they are also in manpages-dev).
Maybe the manpages source package should be split into more binary
packages? manpages (generic stuff for all Debian systems),
manpages-linux (Linux specific things, like sysfs), manpages-linux-dev
(Linux specific programming interfaces).
Regards: David Weinehall
--
/) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\
// ~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353381: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system
On Sun, Feb 19, 2006 at 11:26:57AM +0100, Florian Weimer wrote: > * Russ Allbery: > > > Your points about sync(8) and tzselect(8) seem reasonable on the surface, > > but the rest of this seems to be disregarding the fact that manpages and > > manpages-dev are not native packages. Those man pages are included in > > that package because they're maintained together upstream in a > > distribution that Debian packages. > > Upstream includes non-free manpages these days, so in reality, we have > already forked. Further Debian-specific changes are needed to address > bugs such as #295211 (upstream does not document our libc/kernel > combination). What manpages in upstream are non-free? Do we have rewritten alternatives in Debian, or are those pages simply removed without replacement? Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353381: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system
On Mon, Feb 20, 2006 at 12:42:08PM +0100, Florian Weimer wrote: > * David Weinehall: > > >> Upstream includes non-free manpages these days, so in reality, we have > >> already forked. Further Debian-specific changes are needed to address > >> bugs such as #295211 (upstream does not document our libc/kernel > >> combination). > > > > What manpages in upstream are non-free? Do we have rewritten > > alternatives in Debian, or are those pages simply removed without > > replacement? > > They are simply removed without replacement. For most of the older > system calls, the old free manpages (which also contain Linux-specific > details) are still included in the upstream package. Only new system > calls (such as mq_receive) appear to be undocumented. Do you making a list of the missing pages? I've written quite a few manpages for various programs, and I'm a really frequent user of the already existing manpages, so I can hopefully help contributing a few free replacements. Who knows, if they are good enough we might even be able to convince upstream to replace the non-free versions. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Marking BTS spam
On Wed, Feb 22, 2006 at 04:33:57AM -0500, Kevin Mark wrote: [snip] > Hi Nico, > I just had an interesting idea to implement a way to get spam deleted > from @debian.org. Create an email address say [EMAIL PROTECTED] You > simply bounce/forward a debian.org email address to this address. A > script associated with [EMAIL PROTECTED] parses the email and > determines which mailing list it came from and then it will delete this > mail from the archives and add the email to a 'spam' queue for > spamassassin to learn. It requires interested humans to patrol their > email and send in 'bug reports' on their @debian.org mailing lists. > Cheers, > Kev echo "[EMAIL PROTECTED]" > .forward+debian-devel +debian-devel). Whoops goes the entire list... =) Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Tue, Feb 28, 2006 at 09:36:46AM -0800, Adam McKenna wrote: > On Tue, Feb 28, 2006 at 02:38:53PM +0100, Gabor Gombas wrote: > > One point that nobody raised so far: _reliable_ working on ndiswrapper > > depends on the 16k-stack patch that is not available in Debian AFAIK. > > Without that patch, drivers requiring ndiswrapper (being free or not) > > only work by pure chance. So whatever the Depends: line says, > > ndiswrapper for any practical purposes depends on software that is not > > in main. > > I've been using ndiswrapper with stock kernels since 0.2 or 0.3, and I have > never heard of the '16k-stack patch'. The thing is: Windows has a 16k stack for drivers. The Linux kernel has either a 4k + 4k stack or an 8k stack, depending on what version of the kernel you use. Most drivers don't need >8k stack (some might even work with 4k too), but some do, thus you need to patch the kernel to provide 16k stacks (this is really bad for other reasons). Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apply to NM? ha!
On Tue, Jan 25, 2005 at 01:43:32AM +, Helen Faulkner wrote: [snip] > 3. If anyone says something to you that is insulting or upsetting or > offensive, you are possibly better off just ignoring it than trying to > argue with them. Remember 1 :) 3.5. A lot of nuance gets lost when communicating over the Internet, especially in a multi-culture, multi-language environment. Tongue-in-cheek humour, irony, subtle jokes, or local variances all stand a big risk of everything between becoming totally incomprehensible to becoming rudely insulting. Also, most subcultures tend to develop a language of their own, a with its own internal jokes, idioms, etc. For instance, all of my geek friends (and I presume most people here?) know, that if I tell them to RTFM, it's not because I wish to insult them, but to remind them that there is a manual-page for that command/function/whatever. My mother would probably not understand that however, and she'd very likely be quite upset to see output from dict). Similarly, there's quite a difference between a coffee table discussion where I tell my buddy "Fuck off!" when he reads me an awesome article from today's paper, and the "Fuck off!" newbies sometimes get on an IRC-channel when asking the wrong question. The problem is that to alleviate the problem completely, we'd either have to stop people from writing what they think (mind control), or have everyone convert to new speak (double plus bad). [snip] Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: scripts to download porn in Debian?
On Tue, Jan 25, 2005 at 10:32:13PM -0600, Ron Johnson wrote: > On Wed, 2005-01-26 at 03:38 +0100, Uwe A. P. Wuerdinger wrote: > > Ron Johnson schrieb: > > > On Tue, 2005-01-25 at 12:34 +0200, Kalle Kivimaa wrote: > > > > [-snip-] > > > > > And yes, I've already thought of that. However, I'd rather some > > > things (URLs, in this case) not be dropped my children's laps, > > > even though they could be blocked further upstream. > > > > > > When they start to get curious about such things, let 'em learn > > > about porn the old fashioned way... ;) > > > > Looks like an other round of underestimating children and censorship is > > coming up. > > Parents are *supposed* to censor what their children see. Says who (well, except you)? > They are also supposed to educate their children. Can't disagree with this one though. But there's always the saying: "Do as I say, not as I do". And it's always a mistake... [snip] Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Sun, Mar 20, 2005 at 11:22:48AM -0600, Steve Greenland wrote: > On 19-Mar-05, 10:00 (CST), Matthias Urlichs <[EMAIL PROTECTED]> wrote: > > > > Umm, rp_filter is for rejecting packets whose *source* address is from the > > wrong network. > > Right. I know this. But what Joel was originally talking about was > rejection of packets on interface A that are destined for an address on > interface B; Joel seemed to be claiming that if this didn't happen by > default, then the OS was a "toy"; I was pointing out that Linux itself > fails this. > > > If you want to block accepting your own address as the *destination*, then > > no, there's no config parameter for that. Use iptables rules. :-/ > > And that's what we do. But some other OSs (Solaris) do support strict > multihoming with a config parameter, it would be nice if Linux did. netdev@oss.sgi.com <--- patches goes that way. linux-kernel@vger.kernel.org <--- or possibly that way. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to detect which user is connected to $DISPLAY
On Mon, Mar 28, 2005 at 12:01:05AM +0100, Marc Haber wrote: > On Sun, 27 Mar 2005 20:23:29 +0200, Michelle Konzack > <[EMAIL PROTECTED]> wrote: > >Am 2005-03-27 20:12:37, schrieb Marc Haber: > >> You should ask user-related questions on a user-related mailing list. > > > >I have asked here because I have already > >gotten unuseful $USER answers. > > > >I need a qualified REAL solution. > > Hire a consultant. -devel is not the second-level-support hotline. A, come off it, this question is a hell lot more on-topic for this list than 95% of all flame-wars here... Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
On Thu, Mar 31, 2005 at 02:46:21PM +0100, Matthew Garrett wrote: > Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > Huh? I'm not saying I pretend it isn't there. Do I want to modify > > the source code? No, because there's nothing I could do with it if I > > could. > > I had to modify my BIOS in order to get my laptop to work with my > wireless card. This would have been rather a lot easier if I'd had the > source code. > > > "If software of class X is distributed sometimes burned into hardware, > > then Debian should distribute other software of class X, even if it > > isn't free, for different hardware." > > I would say that "If software of class X is distributed sometimes burned > into hardware, then Debian distributing other software of class X would > not have a significant impact upon the rights of our users". As far as I think that's a *very* slippery slope. Think embedded devices; a lot of them has the software on flash or even as ROMs. Would this software be acceptable in main just because it was available on ROM too? > freedom is concerned, both types are equivilently bad. The choice is > either: > 1) Distribute the non-free firmware. Our users are happy. Sure, as long as we distribute it in *non-free* where it belongs. [snip] Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian as living system
On Wed, May 18, 2005 at 04:36:18PM +0200, Ingo Juergensmann wrote: > On Wed, May 18, 2005 at 04:25:02PM +0200, Benjamin Mesing wrote: > > > You would rather have silence than know why you are being ignored? > > > Then silence you shall have. > > Well, its the tone that makes the music we use to say here in Germany. > > Certainly there would have been ways to tell Bluefuture that his mail > > was hard to read/understand without becoming offensive. > > That would have been too easy > asuffield seems to be a bored person that like starting flame wars by > getting offensive and doing ad hominem attacks with a very arrogant POV. So, Pot. Kettle. Black. [snip] Regards: David weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Thu, May 19, 2005 at 11:47:31AM +0200, Goswin von Brederlow wrote: [snip] > But the problem remains that you have to look at each dire entry in > unhashed ext2/3, fat or minix. Ehrm, I don't think having /usr/lib on a fat FS is an option anyway, considering its lacking file ownership/permission support and its filename munging... And I somehow doubt that minix is a problem either, these days. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Nokia device is Debian-based?
On Fri, May 27, 2005 at 10:40:41AM +0200, Olivier Bornet wrote: > Hello, > > > From: http://linuxdevices.com/news/NS3716070830.html > > > > ... > > The open source software component of the Nokia 770 can be downloaded from > > Maemo.org as a complete filesystem, or managed as a collection of Debian > > source and binary packages. > > ... > > Right. I have received some information from a friend who is working on > this product at Nokia, and he say it's Debian based, with a 2.6 kernel. Indeed. The Nokia OSSO (Open Source Software Operations) that work on this product consists of several DD's (myself being one), plus at least one person in the NM-queue. Some of our subcontractors are also DD's. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Nokia device is Debian-based?
On Mon, Jun 06, 2005 at 02:21:46AM -0700, Stephen Birch wrote: > Florian Weimer([EMAIL PROTECTED])@2005-06-06 09:32: > > * Stephen Birch: > > > > > Wow Nokia just became my new favourite company. > > > > To put things into perspective, Nokia is one of the companies lobbying > > for unlimited software patents in Europe. > > Oops. I don't like to appear fickle but I guess they just went from > top company to bottom in my mind. Sigh ... I would have liked one of > those tablet computer. So, I take it you don't buy any products from Apple, IBM, Sony, etc either? There's a distinct difference between corporate policy and the project internal policy of the Nokia/OSSO team who have developed the N770. > Software patents are an absolute menace in the USA it would be crazy > for Europe to also start issuing them. Well, the European Parliament is (or has at least been) strongly opposed to software patents, so it's unlikely that they will pass without some serious trickery. NOTE: I'm a Nokia employee and work on the N770 team, but this is by no means an official statement... Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 06:09:01PM -0500, John Hasler wrote: > Roberto C. Sanchez writes: > > Where, pray tell, is a newbie going to learn about [runlevels]? > > a) By having used Red Hat. > b) By reading up on Linux before trying to use it (yes, some people _do_ >that). Yup. They'll also have learned that packages are managed by rpm. We'd better change our package management system. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Fri, Jun 10, 2005 at 12:20:14AM +0200, Giuseppe Sacco wrote: > Il giorno gio, 09-06-2005 alle 19:06 +0200, Frans Pop ha scritto: > > On Thursday 09 June 2005 18:45, Marco d'Itri wrote: > > > On Jun 09, Adrian von Bidder <[EMAIL PROTECTED]> wrote: > > > > Dropping 2.4 can easily be done on relatively short notice prior to > > > > etch release, so no need to worry about now. > > > > > > It would be too late, because at that time we would have wasted a > > > couple of years trying to support them. > > > This kind of decision should be taken early in the development cycle. > > > > Making the decision early would also help d-i development as we could then > > start cleaning e.g. keyboard selection (and console-data). > > Being able to rely on sysfs being present would also simplify hardware > > detection in some cases. > > Right, this would really simplify d-i development. My personal opinion > is that 2.6.8 isn't enought mature to be used on server installation > with multidisk, lvm and XFS. > But, when Etch will be released, we will probably have 2.6.25 or such > available. I think, in this case, 2.6 could really be offered as a > complete replacement for 2.4. 2.6.25?! The current release pace for the 2.6-kernel is somewhere along 2-3 months / kernel. The kernel version now is 2.6.11, but 2.6.12 is out any day now, hopefully. Unless there are some radical changes, there won't be more than 6-8 new kernels released 18 months from now. So we're more looking at 2.6.20. I totally agree about goes 2.6.xx full out, however. 2.6.11 is already pretty stable, 2.6.12 promise to be even more so. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian menu update and /usr/share/menu transition
On Wed, Jun 15, 2005 at 04:34:06PM +0200, Bill Allombert wrote: [snip] > 3) menu now support automatic translations of menu sections, in 32 > different languages and this is supported out-of-the-box by a fair > number of window-manager in Sarge. Crappy snapshots here: > <http://people.debian.org/~ballombe/menu-snapshot> Sounds great! Do you have a list of the translations available, so that people who's language is missing can submit a translation? Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two versions of pan in etch?
On Thu, Jul 27, 2006 at 08:31:34PM +0200, Søren Boll Overgaard wrote: > Hello, > > Pan[0] is currently undergoing a major rewrite, and being the > maintainer, I am currently considering what version of pan to include > in etch. This mail[1] from one of the pan mailing lists sums up the > situation quite nicely. Is the new version of pan able to migrate the information from the old version yet? Last time I tried switching to the new version, it wouldn't recognize the fact that I was subscribed to several newsgroups. If it does support this now (or if you could at least add a postinst script that does the migration), then I'm all for a switch to the new version. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lots of (easily recognisible) spam sent to the BTS today
On Tue, Oct 31, 2006 at 11:24:06PM +1100, Hamish Moffatt wrote: > On Tue, Oct 31, 2006 at 12:46:46AM +0100, Javier Fernández-Sanguino Peña > wrote: > > BTW, could it be possible to provide an alternate interface to submit spam? > > (like the 'report-listspam AT lists.debian.org' we can bounce spam from the > > mailing lists to) > > Using the devscripts package you can "bts reportspam ". > > I wrote a trivial perl script to which I pipe in BTS spams from mutt; > it extracts the bug number from the Subject then runs the bts program. Isn't there a risk of causing double work? Person A reports spam, Blars removes it Person B reports the same spam, Blars checks again - no spam found Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Sat, Nov 11, 2006 at 11:10:52PM -0600, Manoj Srivastava wrote: [snip] > > It is my opinion that we would be better off dumping this > whole shell specification thing in policy, standardizing on bash, and > let it go. You know, people base embedded systems on Debian. And as long as the ballpark of all initscripts are written in POSIX shell, it's really easy to dump bash completely on those systems, since most embedded systems only use a fairly limited set of packages anyway. But if a significant number of packages (especially the essential & required ones) begin using bash-only features, we'll lose that ability. On an embedded system, noone really cares whether the shell has smart tab-expansion, customisable prompts, etc. Only a few things count: memory footprint (including dependencies that are not needed elsewhere), storage footprint (again including dependencies) and speed of execution. For all of these, dash is a far better choice than bash. I wouldn't give up bash bash on any of my desktop systems - it's a really nice shell to do work in - but all scripts I write can be run using any of the SuSv3-compliant shells available in Debian... Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of IPW3945 (Was: IPW3945)
On Sun, Nov 12, 2006 at 11:42:17AM +0100, Loïc Minier wrote: > Hi, > > Here's a short status of IPW3945 in Debian: > IPW3945 needs three things: firmware (binary blob), driver, and daemon > (non-free): > - firmware is in firmware-ipw3945, up-to-date with upstream >(<http://bughost.org/ipw3945/>) at version 1.13 in etch/testing; >maintained by the Kernel team > - public packages for the driver may be found on personal web sites of >various people, I've found Joachim Reichel, Russel Stuart, and Stefan >Lippers-Hollmann to be providing such packages; I could update the >more recent version based on a packaging mostly by Kel Modderman to >the latest upstream version for my local needs, and it works like a >charm, especially with the patches Kel has been adding recently; >Daniel Baumann ITPed this driver, and Kel requested comments on his >packages on the debian-mentors@ list > - daemon is also available publicly from Joachim Reichel's site; Jurij >Smakov ITPed the daemon, and started separate packaging efforts which >he offered for comments as well recently; I've tested the packages of >Jurij, and they work nicely (except for a point I believe is being >addressed) > > I believe the latest versions of the above packages are of release > quality, and I wish they ship in etch as well. I think we should wait until the next firmware version is out; that way we'll avoid the binary only regulatory daemon. See the following post: http://marc.theaimsgroup.com/?l=linux-netdev&m=116226285115407&w=1 Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Mon, Nov 13, 2006 at 09:06:05AM +0100, Lionel Elie Mamane wrote: > On Mon, Nov 13, 2006 at 07:11:43AM +0200, Jari Aalto wrote: > > Manoj Srivastava <[EMAIL PROTECTED]> writes: > > > IMPROVE QA > > > All discussion about "policy has problems" is really due to lack of > > quality assurance work that prevents non-sh-compliant scripts to > > enter into the packaging in the first place. If people are sloppy or > > don't know how to comply with standard sh scripts, > > You know, it is rather hard to comply to a standard you do not have a > copy of; POSIX costs money, and no trivial amount of it. We > kinda-learn what is in POSIX and what not by "common lore" that one > picks up as one goes or by reading other documents such as the SUS or > the bash/dash/... manual that more or less partially indicate what > feature they document is POSIX and which one is not. > > Up to now, I've been surviving with SUS as a reference and the bash > manual for quick reference for things I know it says (e.g. is the > POSIX equality operator = or == ?). Not that I write that many > maintainer scripts, but still. In general, though, for all but the > most basic scripts, I have abandoned the idea of making /bin/sh > scripts and do /bin/bash scripts. I don't have to count anymore how > many times I have to escape nested backquotes, I had until very > recently with the GFDL debacle a manual I could easily refer to, ... The SuSv3 is to be considered as POSIX these days, so it's available for free (and even packaged in Debian...) PS: The equality operator is =. RegardS: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Mon, Nov 13, 2006 at 05:59:46PM +, Darren Salt wrote: > I demand that Gabor Gombas may or may not have written... > > [snip] > > So again I propose that instead of listing features, policy should just > > say "maintainer scripts must work with bash, dash [and probably a 3rd > > alternative]". > > busybox? Such a requirement would at least be wonderful for us embedded developers... Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Tue, Nov 14, 2006 at 05:11:27PM +0100, Marco d'Itri wrote: > On Nov 14, David Weinehall <[EMAIL PROTECTED]> wrote: > > > > busybox? > > Such a requirement would at least be wonderful for us embedded developers... > But hardly practical, IIRC there are some commonly used shell features > supported by dash but not busybox. Well, as long as they are standard features that requires relatively small changes, they can be implemented in busybox too -- it's not like busybox is set in stone... Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Tue, Nov 14, 2006 at 08:03:54PM +0100, Marco d'Itri wrote: > On Nov 14, Manoj Srivastava <[EMAIL PROTECTED]> wrote: > > > So, what features do we settle on? we can either standardize > > on, well, a standard: POSIX/SUSv3, -- but there are things we use > > that come from XSI. I guess we could standardize on SUSv3 +XSI > > shells. Would still make local illegal:). The issue here sems to be > > that we are beginning to see people want to add in various and sundry > > features which are not pure POSIX just because people have been using > > it in their scripts. > No, there is no such issue. The issue is that a few people tried to > remove all use of test -a/-e and local from /bin/sh scripts, I admit belonging to the group of some people here. > and failed > miserably. And you belong to the group of people that caused it to fail... > Before this there was a widely agree definition of what > /bin/sh needs to support and almost no bugs related to this. Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Tue, Nov 14, 2006 at 12:36:04PM -0600, Manoj Srivastava wrote:
[snip]
> So, what features do we settle on? we can either standardize
> on, well, a standard: POSIX/SUSv3, -- but there are things we use
> that come from XSI. I guess we could standardize on SUSv3 +XSI
> shells. Would still make local illegal:). The issue here sems to be
> that we are beginning to see people want to add in various and sundry
> features which are not pure POSIX just because people have been using
> it in their scripts.
I don't really like -a and -o (especially since they both exist in unary
versions too), but they are widely used, and since some people (hey MD!)
refuse to accept patches to remove them, I guess we're stuck with them.
With them also follows ( ).
As you mention, local isn't part of XSI either, but we could grandfather
that in just like echo -n behaviour (everything (?) echo -n
does can be achieved just as nicely with printf, but the amount of
scripts to fix is just too vast).
But SuSv3 + XSI (at least the XSI extensions for test -- I haven't
checked what other legacy crap it might bring) + local -- I can live
with that I guess, as long as we get rid of crap like [[ ]], <, >, -nt,
-ot, -ef, $RANDOM, $"...", read -e, declare, typeset, function (augh, I
cannot understand why bash even introduced that one), let, source
(again, completely pointless), pushd, popd, &>, {}...
I can probably come up with more, but this is a good start.
Regards: David
--
/) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\
// ~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Fri, Nov 10, 2006 at 12:01:10AM -0600, Manoj Srivastava wrote:
> Hi,
>
> Firstly, should we be pointing to the SuS instead of POSIX
> (there is work going on a new version of the SUS), since it is open,
> and readily available on th 'net, and people can readily see it (as
> opposed to people who have shelled out $500 for a version)?
Sounds good.
> Secondly, why should we explicity carve out an exception for
> test -a and -o, rather than saying that the XSI extensions need be
> supported? The X/Open System Interface is the core application
> programming interface for C and sh programming for systems conforming
> to the Single UNIX Specification.
Don't forget ( ) in that case, they go hand in hand with -a and -o.
> + local to create a scoped variable must be
> + supported; however, local may or may not preserve
> + the variable value from an outer scope and may or may not
> + support arguments more complex than simple variable
> + names
>
> Perhaps a example/footnote needs be inserted here? If I were
> writing a script, it would help to be reminded that I can't really
> depend on very much of the semantics of local from any specific
> implementation.
>
> fname () {
> local a # keep it simple
> a='' # initialize the variable
> use a ...
> }
> is the only safe way to do use a local variable.
Fine by me.
Regards: David
--
/) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\
// ~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Wed, Nov 15, 2006 at 10:46:51AM -0800, Russ Allbery wrote: > Bill Allombert <[EMAIL PROTECTED]> writes: > > > Hard-coding path is frowned upon theses days and there is no standard > > way to disable a shell built-in, so in practice we are actively > > prevented from using coreutils test and thus coreutils test features. So > > the question is not merely what should be the default. > > Who is arguing that you can't use /usr/bin/test when you explicitly need a > feature of coreutils test? The relevant Policy section says: > > Programs called from maintainer scripts should not normally have a > path prepended to them. Before installation is started, the package > management system checks to see if the programs ldconfig, > start-stop-daemon, install-info, and update-rc.d can be found via the > PATH environment variable. Those programs, and any other program that > one would expect to be on the PATH, should thus be invoked without an > absolute pathname. Maintainer scripts should also not reset the PATH, > though they might choose to modify it by prepending or appending > package-specific directories. These considerations really apply to all > shell scripts. > > That's a "should normally," not a must, and this sort of situation is > seems to me to be exactly why it says "should normally" instead of "must." > The reason for not prepending a path is that it's pointless and may create > problems later if the binary moves. The first is not true in this case, > and I don't think the second is strong enough by itself. > > In fact, if you squint the right way, that paragraph gives a sort of > blessing to using an absolute path in this situation, since coreutils test > is not quite "any other program that one would expect to be on the PATH" > simply because in this case the shell isn't going to *look* at the PATH. Of course, any scripts that may be run before mounting /usr must not use /usr/bin/test... Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Wed, Nov 15, 2006 at 10:05:47PM -0800, Thomas Bushnell BSG wrote: > On Wed, 2006-11-15 at 22:50 -0600, Manoj Srivastava wrote: > > I would rather get away from this wording totally. > > , > > | "Shell scripts specifying /bin/sh as interpreter must only use POSIX > > | features, additionally, they may assume that echo -n . Also, > > | they may use test -a/o and the local directive in shell functions, > > | as long as If a shell script uses features beyond this set > > | listed, then the appropriate shell must be specified in the first > > | line of the script (e.g., #!/bin/bash) and the package must depend on > > | the package providing the shell (unless the shell package is marked > > | "Essential", as in the case of bash). " > > ` > > > > This does specify what the scripts may expect, but drops all > > wording from this section regarding what the policy expectation of > > /bin/sh is. > > No, this does *not* specify what scripts may expect. > > May I expect test to work with parentheses? If not, it must be because > 'test ( )' is not a "POSIX feature". And yet, there is nothing in Posix > which makes test have *anything* to do with the shell particularly. If > using 'test ( )' is not allowed, because it's not a "POSIX feature", > then using "debconf" is *also* not allowed, because it is *also* not a > "POSIX feature". The point is that "POSIX feature" is *not* a > specification of anything, given the way that POSIX deals with builtins. Sorry, but that's a strawman, for two reasons. First, POSIX only covers commands that *are* part of POSIX, it does not specifies that other commands are illegal. Second of all, debconf does not have a history of being a builtin, test does. Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Thu, Nov 16, 2006 at 07:35:14PM -0800, Thomas Bushnell BSG wrote: > On Thu, 2006-11-16 at 21:16 -0600, Manoj Srivastava wrote: > > Your scripts shouuld really just use whatever POSIX mandates > > ls has. Just like it should use whatever POSIX mandates test has. > > Ok, so this means something like the following would be good for policy: > > "When POSIX specifies a command, shell scripts should only use the > options mandated by POSIX for that command, even if the standard Debian > versions have more. Specify a complete pathname to the command if you > need the options the standard Debian version provides. (Exceptions: > echo -n, and test -a/-e may be used even though not mandated by POSIX.) > > "You may use commands not specified by POSIX, provided they are in > essential packages, or packages that you Depends: on." This proposal has some merit, as long as we do s/POSIX/SuSv3/. Also, we probably want to make exceptions for find/xargs (to get -0). [snip] Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Sat, Nov 18, 2006 at 08:01:04AM -0800, Thomas Bushnell BSG wrote:
> On Sat, 2006-11-18 at 11:30 +0100, Andreas Metzler wrote:
> > > Well, the goal was (in part) to catch scripts which use non-Posix
> > > features of echo and test; why are non-Posix features of ls not an
> > > issue?
> >
> >
> > Since I cannot think of a legitimate reason for anyone to use
> > ls in a shell script, I think it would add little value.
> >
>
> Makes you wonder why it's in Posix.2 at all, huh? (Posix.2 is about
> scripts, not user interaction.)
"The ls utility shall conform to the Base Definitions volume of IEEE Std
1003.1-2001, Section 12.2, Utility Syntax Guidelines."
It's a *utility*, not a shell function.
The volume is called "Shell & Utilities". Other covered utilities are
*for instance* awk, bc, chmod, chown, diff, and grep.
> How about grep? Is there a legitimate reason to use grep? Can we have
> a list of which Posix.2 shell commands may not be legitimately used in
> shell scripts?
There are definitely lots of reasons to include grep in shell scripts,
though some of the current users can probably be covered by the
${}-variants. And for a shell like busybox it makes sense to
have both ls and grep as builtins...
Things not acceptable from SuSv3 would for instance include the entire
BE-section (Batch Environment Services -- then again I'm not even sure
it's provided by anything in Debian), the FR-extensions (Fortran
Runtime), most (all?) of the utilities marked as DEVELOPMENT (things
such as compilers, sccs-related commands, cflow, and ctags).
Regards: David
--
/) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\
// ~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Sun, Nov 19, 2006 at 07:13:22PM +0100, Andreas Metzler wrote: > Michelle Konzack <[EMAIL PROTECTED]> wrote: > [...] > > ...and where is SuSv3 in Debian (which package?). > [...] > Nonfree. http://packages.debian.org/susv3 Uhm, no? susv3: Installed: 6.1 Candidate: 6.1 Version table: 6.1 0 500 http://ftp.se.debian.org unstable/contrib Packages Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about "Depends: bash"
On Wed, Nov 22, 2006 at 07:31:37PM +0100, Michelle Konzack wrote:
[snip]
> ${#NAME}
> ${parameter:-word}
> ${parameter:=word}
These are supported in SuSv3 compliant shells too.
> ${parameter:offset}
> ${parameter:offset:length}
These are not.
> disown
You actually use job-control in your shell-scripts? Interesting...
Regards: David
--
/) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\
// ~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Archive Automatic Signing Key (4.0/etch)?
On Wed, Nov 22, 2006 at 10:54:47PM +0100, Bartosz Fenski aka fEnIo wrote: > On Tue, Nov 21, 2006 at 11:52:38PM +0100, Kurt Roeckx wrote: > > > > gpg --recv-keys A70DAF536070D3A1 && (gpg --export -a A70DAF536070D3A1 | > > > > apt-key add -) > > > > > > Uh, don't forget the part about verifying that the key is actually > > > signed by the ftpmasters. Skipping that step pretty much defeats the > > > entire point. > > > > > > gpg --list-sigs A70DAF536070D3A1 > > > > Try gpg --check-sigs A70DAF536070D3A1 instead. > > Very useful: > > ([EMAIL PROTECTED])~$gpg --check-sigs A70DAF536070D3A1 > pub 1024D/6070D3A1 2006-11-20 [expires: 2009-07-01] > uid Debian Archive Automatic Signing Key (4.0/etch) <[EMAIL > PROTECTED]> > sig!36070D3A1 2006-11-20 Debian Archive Automatic Signing Key > (4.0/etch) <[EMAIL PROTECTED]> > > 2 signatures not checked due to missing keys ^^^ Those signatures are: sig 2A4E3EAA 2006-11-20 Anthony Towns <[EMAIL PROTECTED]> sig 29982E5A 2006-11-21 Steve Langasek <[EMAIL PROTECTED]> > ([EMAIL PROTECTED])~$ > > Looks that it's signed by itself. Yes, aren't all keys self-signed? Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Thu, Nov 23, 2006 at 09:16:15AM -0800, Thomas Bushnell BSG wrote: > On Thu, 2006-11-23 at 13:43 +0200, Jari Aalto wrote: > > > > Bash is not essential for running Debian. It is possible to run old > > PCs and old laptops completely free of bash. The point here is not the > > disk consumption, but the reduced memory constrainsts. When scripts > > are written with only "sh" in mind, they become portable to even > > embedded systems (think busybox). Every bash-dependent scipt that runs > > on the system, takes memory out from other processes. > > What about "perl". Is that essential? Why are you not going for big > targets? > > Education sector and 3rd world still have PCs that are *years* and > > *tears* old. Everybody do not live in countries where computers or > > hardware are cheap. > > Guess what? I used bash on that old hardware when it was shiny and new > also. Didn't seem to have any problems. Somehow I doubt that you used today's version of bash (which I bet is a lot bigger and more memory-consuming due to new features). Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Thu, Nov 23, 2006 at 07:09:49PM +0100, Steinar H. Gunderson wrote: > On Thu, Nov 23, 2006 at 06:37:52PM +0100, David Weinehall wrote: > > Somehow I doubt that you used today's version of bash (which I bet > > is a lot bigger and more memory-consuming due to new features). > > Comparing bash from woody and sid, respectively: > > -rwxr-xr-x root/root511400 2002-04-08 21:07 ./bin/bash > -rwxr-xr-x root/root677184 2006-10-22 15:55 ./bin/bash > > RSS of woody's bash is 4528 kB on my system; 4888 kB for sid's bash. > > So, unless you want to claim that 162 kB bigger and using 8% more memory is > "a lot", you should probably be less careless about your betting. Most hardware that was nice and shiny back in 2002 wasn't exactly underpowered, seeing as the Pentium 4 and Athlon Palomino was what was used back then. So, I kind of doubt that the statement was concerning Woody. Try Potato or Slink. Oh, and 8% is quite a difference if you only have a limited amount to begin with. It's not like bash is the only thing that's bloated since then either. On an embedded system, 162kB more storage or 360kB more RAM *is* a big difference. And compared to dash, the difference is vast: -rwxr-xr-x 1 root root 80200 2006-11-21 16:36 /bin/dash RSS for dash on sid seems to be 464kB. No woody to compare with. Now the choice of 464kB or 4528kB on a desktop where you're actually using the shell for interactive things is probably not a big deal, personally I'd never use dash, posh, or busybox (except for rescue purposes) on a desktop (or server, for that matter) other than for scripts. But for an embedded system, where the shell is only used for scripts anyway, and for that matter, for scripts used on bootup (where speed counts), any performance difference and every kB is gonna count. On a machine with 64MB of RAM, a shell that takes 4.5MB of that is quite a hog. Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Thu, Nov 23, 2006 at 07:54:46PM +0100, Bill Allombert wrote: > On Thu, Nov 23, 2006 at 07:41:08PM +0100, David Weinehall wrote: > > > > And compared to dash, the difference is vast: > > > > -rwxr-xr-x 1 root root 80200 2006-11-21 16:36 /bin/dash > > > > RSS for dash on sid seems to be 464kB. No woody to compare with. > > dash in woody was still called ash. What I meant was that I don't have a system running woody =) Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Thu, Nov 23, 2006 at 07:49:10PM +0100, Martijn van Oosterhout wrote: [snip] > > There's a difference between requiring maintainer scripts to say > /bin/bash if they need bash constructs and rewriting existing scripts > to work with some generic shell. The former is going to be *much* > easier. Isn't that enough? If you just want to avoid things breaking, it's enough. If you want to be able to use the scripts on an embedded platform, or to take advantage of the performance boost of using dash instead of bash, it isn't. Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Thu, Nov 23, 2006 at 11:23:23AM -0800, Thomas Bushnell BSG wrote: > On Thu, 2006-11-23 at 13:50 +0200, Jari Aalto wrote: > > I'm not suggesting to remove features from essential, but I think the > > policy should take the shells as special case, because the > > sh-compliances (SusV/POSIX) itself is a matter of its own. There are > > no viable alternative implementation of Perl which is in essential, likewise > > for the rest. > > Why should shells be a special case and all the other things mentioned > by SusV/POSIX are not? Why do we not want users to have the ability to > substitute a different ls, a different du, a different cp, a different > cat, a different grep? Well, let's hope people don't use any of the non-SuSv3 features of cat in their shell scripts... ls and du aren't used in scripts (normally), and only "normal" features of cp are used in scripts. As for grep, yes, it would be nice to be able to use busybox grep. Busybox grep isn't fully SuSv3 compliant though, it lacks the -x option. Personally I wouldn't mind limiting init-scripts and scripts that are parts of essential to use only SuSv3 compliant features. I think rewriting *all* scripts to use only SuSv3 features would be too big of an ordeal, but just fixing the initscripts, plus all scripts in essential should be doable. Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Thu, Nov 23, 2006 at 11:20:03AM -0800, Thomas Bushnell BSG wrote: > On Thu, 2006-11-23 at 19:33 +0200, Jari Aalto wrote: > > I don't see perl used that much for maintainer scripts, or daemon > > scripts. > > Exactly the *point*. So why isn't this your target? > > > Some prefer bash and see no problems. Others consider bash's memory > > consumption a problem when compared to other alternatives. > > The only alternative in Debian is dash, which explicitly says it's not a > replacement: > > "bash" is a better shell for most users, since it has some nice > features absent from "dash", and is a required part of the system. dash is better for scripts (smaller memory footprint, faster), bash is better for interactive use. Most users need a good interactive shell, hence it's better for most users. That doesn't mean we should limit ourselves to using bash for non-interactive use though. Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Thu, Nov 23, 2006 at 11:56:48AM -0800, Thomas Bushnell BSG wrote: > On Thu, 2006-11-23 at 20:46 +0100, David Weinehall wrote: > > Well, let's hope people don't use any of the non-SuSv3 features of cat > > in their shell scripts... > > Why? Who cares? Well, be honest. Have you ever used any options *at all* to cat in your scripts? > This is some huge amount of work for some very little benefit. It's work that has to be done only once, and as long as people accept patches, you don't even have to do it yourself, there's plenty of other people willing to help. Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Thu, Nov 23, 2006 at 09:48:31PM +0100, Florian Weimer wrote: > * David Weinehall: > > > On Sun, Nov 19, 2006 at 07:13:22PM +0100, Andreas Metzler wrote: > >> Michelle Konzack <[EMAIL PROTECTED]> wrote: > >> [...] > >> > ...and where is SuSv3 in Debian (which package?). > >> [...] > >> Nonfree. http://packages.debian.org/susv3 > > > > Uhm, no? > > > > susv3: > > Installed: 6.1 > > Candidate: 6.1 > > Version table: > > 6.1 0 > > 500 http://ftp.se.debian.org unstable/contrib Packages > > It's just an installer. The actual document is not even > redistributable (which makes it kind of weired that Debian relies so > heavily on it). I was just correcting the location of the package, not making a political statement one way or the other. We do rely quite heavily on the glibc too, yet its documentation is nonfree... Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Fri, Nov 24, 2006 at 11:10:19AM -0800, Thomas Bushnell BSG wrote: > On Thu, 2006-11-23 at 22:56 +0200, Jari Aalto wrote: > > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > > > > On Thu, 2006-11-23 at 19:33 +0200, Jari Aalto wrote: > > > > I don't see perl used that much for maintainer scripts, or daemon > > > > scripts. > > > > > > Exactly the *point*. So why isn't this your target? > > > > > > > Some prefer bash and see no problems. Others consider bash's memory > > > > consumption a problem when compared to other alternatives. > > > > > > The only alternative in Debian is dash, which explicitly says it's not a > > > replacement: > > > > > > "bash" is a better shell for most users, since it has some nice > > > features absent from "dash", and is a required part of the system. > > > > This refers to inteactive use. dash suits well for scripts. > > You miss the point. If there is any interactive use at all, then bash > needs to be on the system. Embedded systems are nifty, but they are not > an issue for Debian. You miss the point too... dash is suitable scripts, and any Linux machine, embedded or not, runs lots of scripts. dash runs those scripts faster. To be able to run those scripts at all, it needs the scripts to be free from bashisms. You can use whatever bashisms you like when you're working interactively, that won't hinder dash from executing shells on boot and elsewhere. Using bashisms in scripts does however cause a problem. Oh, and there *are* other suitable interactive shells than bash. tcsh, ksh, zsh, rc... Whether any of these actually consume less memory than bash, I cannot say, since I'm a bash user myself on the desktop. Yet all the scripts I write run perfectly well (and faster) in dash. Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Sat, Nov 25, 2006 at 10:02:14AM +0200, Jari Aalto wrote: > Hubert Chan <[EMAIL PROTECTED]> writes: > > > On 23 Nov 2006 22:40:01 +0200, Jari Aalto <[EMAIL PROTECTED]> said: > > > > > My point. If there is explicit "Depends: bash", then someone can post > > > a patch to provide alternative solution to a person who may not know > > > alternative constructs (having learned only bashism). > > > > Sorry, but I don't understand what you're trying to do here. Can you > > please explain what dependencies have to do with wishlist bugreports? > > "Depends:" make dependency visible, whereas filing a wishlist is > usually result of someone by accident finding the script to include > bashism. He may offer a patch to convert those constructs to standard > sh-way-of-doing-things. > > It's easier to eyeball packages that explicitly announce "bash". > Those could be put to a stress test through: > > /bin/dash > /bin/posh > ... > > If someone feels up to. I don't really see the point. If the maintainer knows the package contains bashisms, he might just as well fix them instead. Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about "Depends: bash"
On Fri, Nov 24, 2006 at 02:21:43PM -0800, Thomas Bushnell BSG wrote: [snip] > I don't care about making anything sh-agnostic. bash is just a > language; dash is just a language. We don't insist that our C programs > be C-compiler-agnostic; we don't insist that lisp or scheme programs be > dialect-agnostic; why should we insist this for shell programs? Well, code that only compiles using, for instance, gcc v2.95, is frowned upon. And the fact that we need to lug around automake1.4, 1.7, 1.8, and 1.9 is scary (but if I understand things correctly, some of that comes down to bad software design on the automake side rather than bad makefiles). [snip] Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: madison not working correctly on merkel
On Sun, Dec 17, 2006 at 04:52:04PM +0100, Frederic Peters wrote: > Luk Claes wrote: > > > Julian Gilbey wrote: > > > I've noticed (and I'm not the only one) that the package database as > > > access by madison on merkel is no longer up-to-date. Does anyone know > > > why? Could someone rectify this situation, please? > > > > The updates have not been reactivated since the move of ftp-master.d.o > > AFAIK. > > I have been using madison on merkel to produce the GNOME 2.16 status > page[1] and it worked until very recently (sometimes between Nov 19th > and Nov 27h). > > > Regards, > Frederic > > [1] http://www.0d.be/debian/debian-gnome-2.16-status.html Some entries seem to list newer Debian-versions than upstream versions... Some watch-files out of sync? Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#358003: ITP: ttf-dzongkha -- TrueType fonts for Dzongkha language
On Sun, Mar 26, 2006 at 02:02:43PM +0300, Lars Wirzenius wrote: > su, 2006-03-26 kello 04:11 -0600, Peter Samuelson kirjoitti: > > > On Tue, Mar 21, 2006 at 07:08:02AM +0100, Christian Perrier wrote: > > > > Well, I have one very little argument against doing so: why do it > > > > for Dzongkha and why not do it for, say, French...:-) > > > > [Lionel Elie Mamane] > > > Because "French" is the adjective in English (the language the > > > package description is written in) for "from France". The same, I > > > would not expect it to be done if the language were called > > > "Bhutanese". > > > > OTOH, if you have no idea what language or what country the font > > pertains to, why would you want that font? > > It is not inconceivable that one could stumble on a document from > Bhutan, and want to install a font to be able to view it. It is a bit > more convenient to be able to find the correct package by only having to > search for "Bhutan", and not have to know that the language is > "Dzongkha". > > This is not what I would call a common use case, but it exists. I've > been in the situation once searching for a "Russian" font, when I > should've been looking for a "Cyrillic" font, for example. I should've > known better, but sometimes it is difficult to come up with the right > search terms even when you supposedly know the right ones. Wouldn't it be enough to have something like "Dzongkha, a language spoken in Bhutan" in the long package description? apt-cache search will pick that up. regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible conflict with XFree 4.5
On Sun, Apr 16, 2006 at 01:40:42PM +0300, gustavo halperin wrote: > Daniel Stone wrote: > > >On Sat, Apr 15, 2006 at 04:17:28PM +0300, gustavo halperin wrote: > > > > > >>I think that we have a problem when the common library between XFree and > >>/usr/lib are update in /usr/lib. > >>I currently have XFree 4.5, when the library libfontconfig1 was update > >>to version 2.3.2-1 was also updated > >>the file libfontconfig.so to the version 1.0.4 but in the XFree > >>(/usr/X11R6/lib/) this library still be the version 1. > >>The problem came we we use programs like Gimp that must at least version > >>1.0.2 of this library. I solve this > >>problem by link the libfontconfig in /usr/X11R6/lib to the newest > >>library in /usr/lib. That is the solution or that > >>is a Bug in Debian System ?? > >> > >> > > > >I assume that you're installing XFree86 4.5 by yourself, since it wasn't > >packaged for Debian. In that case, local installation conflicts are > >your problem to sort out. > > > > > > > I see, you are absolutely right. Thank you for you explanation. Just out of curiousity, any particular reason why you would want to use XFree rather than Xorg? Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trouble with some X applications.
On Sat, Apr 29, 2006 at 12:13:38PM +0200, Klaus Ethgen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Am Sa den 29. Apr 2006 um 12:08 schrieb Andrew Donnellan: > > >That whould be a catastrope. As 2.6 is miles from stable a 2.6 kernel is > > >no kernel for stable servers. (Well, my system with sid is not in this > > > > Not stable?!?! It's been around for several years now. Please ask on -user. > > Its not a question. Its a fact! No, it's not a fact, it's your personal opinion. I don't doubt that there are cases where the 2.4 kernel is more stable than the 2.6 kernel, but I highly question your earlier statement that the futex:es are broken, since a lot of other people would've experienced and reported the problem in that case. And if you really believe that the kernel maintainers don't want to fix certain bugs, you're really out on thin ice. They might, however, disagree with your opinion that a certain behaviour is a bug at all... Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Light Desktop - meta package
On Sat, May 13, 2006 at 10:27:50AM +0200, Marc Haber wrote: > On Fri, 12 May 2006 01:10:17 +0200, Eugen Paiuc <[EMAIL PROTECTED]> > wrote: > >I'd add localepurge - witch save my >25 % disk space on 6-700 mb > >installation. > > Localepurge is a bad hack which tries to compensate for a shortcoming > in dpkg, one that I have been waiting to be fixed since I started > using Debian nearly ten years ago. I begin to lose my hope. Did you remember to submit a patch to the bugreport you filed? Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making init scripts use dash
On Thu, May 18, 2006 at 10:38:08PM +0200, Goswin von Brederlow wrote: > "Margarita Manterola" <[EMAIL PROTECTED]> writes: > > > During some tests I've performed, I've found that making the init > > scripts run with dash as default shell instead of bash makes the boot > > time a 10% faster (6 seconds in a 60 second boot). > > > > To make this speed up available to everyone, we have 2 main choices: > > > > 1. Make /bin/sh point to /bin/dash > > That would mean having 2 shells since some scripts need bash. What a > waste on small systems. Well, most of those scripts can be fixed quite easily, some require a bit more work. I hereby promise to help fixing them to the extent of my capability. Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making init scripts use dash
On Fri, May 19, 2006 at 03:34:17PM +0200, Wouter Verhelst wrote: > On Fri, May 19, 2006 at 05:45:46AM +0200, David Weinehall wrote: > > Well, most of those scripts can be fixed quite easily, some require > > a bit more work. I hereby promise to help fixing them to the extent > > of my capability. > > Let's see. The nbd-client and nbd-server initscripts use bash arrays. Do > you have an alternative way to implement their current behaviour, so > that it would work with dash? > > (note that requiring the configuration file format to be changed would > not be something I would oppose too strongly, if it would make sense) I'll have a look at it and see what I can do. Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
On Mon, Jul 24, 2006 at 06:32:54PM -0400, Joey Hess wrote: > Steve Greenland wrote: > > This really seems like something that while they may, very occasionally, > > be required, are mostly unnecessary and often misused. > > Rather, I'd characterise it as a feature that is necessary for any > general-purpose depencency-based system to be complete[1], which is > totally safe and does not adversely affect any aspect of the system > if some simple rules are followed, and which, if used incorrectly, is > still orders of magnitude safer than other dpkg features, such as its > support for setuid files, or its support for postinst scripts that run > arbitrary code at install time. Well, if foo depends on foo-data, and foo-data depends on foo, I find it really hard to see the point of splitting the two into distinctive packages... Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
On Tue, Jul 25, 2006 at 11:42:39AM +0900, Miles Bader wrote: > David Weinehall <[EMAIL PROTECTED]> writes: > > Well, if foo depends on foo-data, and foo-data depends on foo, I find > > it really hard to see the point of splitting the two into distinctive > > packages... > > It could be useful if foo-data is very large, but changes rarely, > whereas foo is small, but changes more often. Then if the user updates > frequently, he will usually only have to download a new foo, not > foo-data. That relies on the fact that the user knows that foo-data doesn't contain any updates, and that (s)he manually inhibits the package manager from downloading the updated version of foo-data, since foo-data will be available in a new version too, even if it does not contain any real changes. Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
On Tue, Jul 25, 2006 at 01:34:47PM +0200, Wouter Verhelst wrote: > On Tue, Jul 25, 2006 at 04:39:24AM +0200, David Weinehall wrote: > > On Mon, Jul 24, 2006 at 06:32:54PM -0400, Joey Hess wrote: > > > Steve Greenland wrote: > > > > This really seems like something that while they may, very occasionally, > > > > be required, are mostly unnecessary and often misused. > > > > > > Rather, I'd characterise it as a feature that is necessary for any > > > general-purpose depencency-based system to be complete[1], which is > > > totally safe and does not adversely affect any aspect of the system > > > if some simple rules are followed, and which, if used incorrectly, is > > > still orders of magnitude safer than other dpkg features, such as its > > > support for setuid files, or its support for postinst scripts that run > > > arbitrary code at install time. > > > > Well, if foo depends on foo-data, and foo-data depends on foo, I find > > it really hard to see the point of splitting the two into distinctive > > packages... > > foo is 2kb and arch:any > foo-data is 200M and arch:all > > There you have it. Ah, true, I'd totally forgotten about that scenario. Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pre-RFA] Intending to drop twenty-some packages
On Sun, Jan 16, 2005 at 10:05:46AM +0100, Tollef Fog Heen wrote: > * Dirk Eddelbuettel > > | - time (dead upstream) > > [...] > > | Please CC me on follow-ups to debian-devel, or email me directly if you have > | any interest. I should follow up with RFA and O bug reports over the next > | few weeks, but doing this informally first may be simpler. Or maybe not. > > I'd like time, please. Wouldn't we all? =P Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: changing architecture from any to all
On Mon, Jan 17, 2005 at 10:07:25AM +0100, Frank Küster wrote: > Jay Berkenbilt <[EMAIL PROTECTED]> schrieb: > > > If one changes the architecture of a package from "any" to "all" but > > makes no change to the package name, does this require any special > > manual intervention, or would an upload that makes such a change go > > through as quickly as a normal upload would go through? Hypothetical > > situation: a compiled executable gets replaced with a shell script. > > Not so hypothetical: I've done this with netenv, which compiled a small > executable from C code just because the upstream author didn't know how > to do bitwise calculations in bash; I replaced the calls to that execu- > table by > > let R1=$((~N1 & 255 | I1)) > let R2=$((~N2 & 255 | I2)) > > and similar, and *woosh* it was Architecture: all. Skip the let, and *woosh*, it's even POSIX compliant shell script... =) Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Useless packages (was Re: anarchism_7.7-1.deb)
On Mon, 27 Sep 1999, Matthew Vernon wrote: > David Starner writes: > > On Fri, Sep 24, 1999 at 05:59:27PM -0400, Jaldhar H. Vyas wrote: > > > Nevertheless it is moot point because we are running out of room and > there > > > has to be a third CD. It might as well contain all the documents and > > > other packages non-essential to using an OS. > > > > > > Here's another idea. What about putting all the non-essential compilers, > > > includes and other development tools on the extra CD too. They take up a > > > lot of room and does the average Debian user really need an eiffel > > > compiler or the IMAP development kit? > > > > Instead of each developer chose what packages are and aren't useful > > to them, why don't we look at the popularity contest? A simple, bias-free > > way of seperating programs on to the CD's, by actual use. That is what > > it was made for. > > And how difficult would it be to fiddle the results of this??? Oh, and of course, when the ratio developers/programmers vs non-programmers turns into what it is for other OS's (that is, when Debian reaches world-domination), the main-CD would only contain X-related stuff + games... Non really the ideal distribution, eh?! /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/
mtools
How comes mtools depend on xlib6g? I don't use X, and thus I consider it very stupid to have both xlib6g & xfree86-common installed, but I have to if I want mtools installed... Rationale? If there's no good explanation, I'll submit a bug-report. And if there's something in xlib6g that mtools really needs, why not break it out of xlib6g and make it a separate package? Oh, and why does xlib6g depend on xfree86-common? Wouldn't it be more natural the other way around only? /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/
Re: mtools
On Tue, 28 Sep 1999, Dale Scheetz wrote: [snip] > Guys, guys, guys... This is a discussion that was had quite a while ago, > and which lead to the creation of xlib6. The whole point was that it was > unnecessary glut to include a console version _and_ an X aware version of > packages like emacs (and others), when a small library could provide all > that was necessary to make a single program both console and X compatible. > xfree86-common is simply a recent way to remove the architectural > independent pieces from xlib6 and provide them in an independent fashion. This is ok with me for stuff like emacs (eventhough I'd really become aggressive if someone removed the vim-tty package.), but when it comes to mtools, it's only one single file; a daemon (floppyd, if I'm not all wrong) that needs xlib6g. It'd be simple to extract this daemon from mtools and create an extra package with just this file, and make this file recommended by mtools, and make mtools required by the extra-package. /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/
Re: pine in other distributions?
On Tue, 28 Sep 1999, Nick Moffitt wrote: > Quoting Piotr Roszatycki: > > BTW, other pine's version is a part of official RedHat distribution, > > but I don't know is it legal? > > > > Will the pine return back to distribution? > > Well, this is the mostly used mailer by my users (and me). > > From http://linuxmafia.com/debian/tips (and based on some > suggestions by yours truly): > > > pine/pico: > > Debian does not by default install "non-free" packages -- those under > restrictive software licences (although many are provided and > available for installation). If you are a user of the "pine" e-mail > client or the "pico" text editor that pine provides, please be aware > that pine is non-free and therefore is not a default installation > item. > > The U. of Washington's licence forbids distribution of pine/pico in > binary form. This restriction is routinely violated by many GNU/Linux > distributions, but not by Debian. (U. of Washington is aware of this > licencing problem, but elects not to fix it.) You can thus install > pine and pico (in Debian) by installing the pine source-code package > and then compiling the programs. This is incorrect. I quote: Pine and Pico are registered trademarks of the University of Washington. No commercial use of these trademarks may be made without prior written permission of the University of Washington. Pine, Pico, and Pilot software and its included text are Copyright 1989-1999 by the University of Washington. Use of Pine/Pico/Pilot: You may compile and execute these programs for any purpose, including commercial, without paying anything to the University of Washington, provided that the legal notices are maintained intact and honored. Local modification of this release is permitted as follows, or by mutual agreement: In order to reduce confusion and facilitate debugging, we request that locally modified versions be denoted by appending the letter "L" to the current version number, and that the local changes be enumerated in the integral release notes and associated documentation. Redistribution of this release is permitted as follows, or by mutual agreement: (a) In free-of-charge or at-cost distributions by non-profit concerns; (b) In free-of-charge distributions by for-profit concerns; (c) Inclusion in a CD-ROM collection of free-of-charge, shareware, or non-proprietary software for which a fee may be charged for the packaged distribution. Redistribution of binary versions is further constrained by license agreements for incorporated libraries from third parties, e.g. LDAP, GSSAPI. The University of Washington encourages unrestricted distribution of individual patches to the Pine system. By "patches" we mean "difference" files that can be applied to the University of Washington Pine source distribution in order to accomplish bug fixes, minor enhancements, or adaptation to new operating systems. Submission of these patches to University of Washington for possible inclusion in future Pine versions is also encouraged. [legal blurp with disclaimers concerning functionality stripped] End of Quote Thus we are free to distribute even a patched Pine, as long as we apply an L at the end of the version#. Not too big a sacrifice, huh? We'll still have to keep it in the non-free area, of course, as it's a BSD-style license, but... I'd love to see Pine 4.10 (in a Debian-modified state that has the pretty colours patch + a fix for the VERY annoying bug that removes backslashes from signatures) /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/
Re: pine in other distributions?
On Wed, 29 Sep 1999, Thomas Schoepf wrote: > On Tue, 28 Sep 1999, David Weinehall wrote: > > > Thus we are free to distribute even a patched Pine, > > No! Anyone is allowed to _locally_ modify Pine, but there's no statement > about distributing such modified versions. And "Redistribution of this > release is permitted as follows [...]" of course only covers "this > release" as provided from U. of Washington. As it stands now, we don't even distribute a binary Pine at all, if I'm not all incorrect, only the sources for (the outdated) Pine 3.96. Furthermore, there is NO clause explicitly forbidding distribution of modified versions; the only clause that mentions patches binaries is the one concerning Local modification. I suggest one of the guys on Debian-legal makes contact with UW and asks for their consent to distribute a Pine vx.yDebian binary. I do believe them to be pretty reasonable. > > We'll still have to keep it in the non-free area, of course, as it's a > > BSD-style license, but... > > When did the BSD license change to non-free? From the Debian Policy > section 2.1.1.: > > Example Licenses > The ``GPL,'' ``BSD,'' and ``Artistic'' licenses are examples of > licenses that we consider _free_. Ok... Sorry, I guess that was personal disliking of the BSD-license biasing my statement. :^/ /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/
Re: warning: lilo 22dev0-1 can make your system unbootable !
On 30 Sep 1999, Stephen Zander wrote: > >>>>> "Thomas" == Thomas Schoepf <[EMAIL PROTECTED]> writes: > Thomas> Did you /run/ lilo, too? Or just installed it? > > Yep, the postinst automatically reruns lilo assuming you take the > default answers to all the questions it asks. I can confirm this behaviour; I run a v2.2.13pre14 kernel, with some additional patches (a cpuinfo patch + my own cbmfs patch) I had no problems with the new lilo at all, and I KNOW that I did run it properly. However, I still downgraded when the new package was upped; I'm not taking any unnecessary risks... /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/
Re: linking binfmt_misc with mime-types
On Wed, 6 Oct 1999, Brian May wrote: [snip] > - The information it proprietary, and not used anywhere else. That's true... > - I am not very familar with the operating system, so there might > be more points that I have missed. Perhaps there are difficulties > loading a file for one application inside another application? This isn't a problem. There are two different values here; creator and the filetype. > - AFAIK, Macintosh doesn't really store "file type" but rather "which > application is this file associated with". So if you have multiple > programs that deal with the same file type, the file has to be > associated with *exactly one* application. (not sure about this) Sort of, yes. You associate the type with one program, which will be the default program to open if you double-click on such a file. This won't influence the possibility to edit the file in another program, however. > - just curious: what other times do you need to change this file type? The time is stored in the resource-fork on the Mac, and sometimes it gets screwed (programs that can't transfer dual/multi forked programs over the net properly, etc.) [snip] /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/
Re: Packages file under version control
On Tue, Jun 03, 2003 at 05:10:24PM +1200, Corrin Lakeland wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Tue, 03 Jun 2003 13:59, Glenn McGrath wrote: > > If we put the Packages file under some sort of version control (e.g. > > cvs), bandwidth requirments would be minimised as cvs automatically > > takes care of diff's and patching, and i assume the CPU load from cvs > > server is a lot better than rsync. > > You could use cvsup rather than cvs to reduce load further. But > ideally you'd just use rsync and make the gzip using --rysncable... > However, given the packages.gz file is much smaller than the total > files being downloaded, is it really worth it? When the mirrors sync, yes, when the average user runs # apt-get update # apt-get -u upgrade No. Fetching Packages.gz over modem is a pain in the arse. Having it only rsync the changes would be so nice. /David -- o/~ It would be so nice, it would be so nice o/~ o/~ It would be so nice to meet some time o/~ Five brownie points to the first to guess the artist...
Re: Proposal: removing libc5, altgcc and all their old-days dependencies
On Fri, Jun 20, 2003 at 12:39:45AM +1200, Philip Charles wrote: [lots of text snipped] > It is not a question of using non-free software, I use it almost > exclusively, but that of accessing documents that were created with > non-free software before there were free alternatives. > > Please remember this is 2003 and not 1983. People have accumulated a lot > on their HDDs in twenty years. What it comes down to is this: Alternative 1: You, and rest of the minority who use libc5 program, can dual-boot an older distribution of Debian (say potato) where the programs still work. Yes, it can be a hassle, but it works. Alternative 2: Debian can continue to drag along support for libc5-binaries (hey, nobody out there with need for libc4?) to the end of days, with more and more problems accumulating, and more and more baggage needed to build them (for every new release of binutils/gcc/etc, it becomes less likely that libc5 will work properly without serious tinkering). Regards: David Weinehall -- /> David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander <\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \> http://www.acc.umu.se/~tao/
Re: Update re: read-only root filesystem
On Sun, Jun 22, 2003 at 11:52:45AM +0200, Xavier Roche wrote: > > To tell the truth, I didn't realize that so many files in /dev/ > > were being fiddled. Obviously, one solution to the problem is > > to have a separate writable /dev/ filesystem, e.g., devfs. > > Note that devfs is still "experimental" in 2.4 > > Another remark for the HOWTO : mounting /tmp in "tmpfs" (since 2.4.1 ?) > allows you not to resevre space for /tmp on a specific partition > > > The question is: Should we concede that a separate /dev/ fs is > > required for running with a read-only root filesystem > > Dunno.. shall we consider devfs and tmpfs as standard (which is IMHO a > good idea) for future releases? tmpfs - yes (tmpfs is a requirement for posix shm), devfs - no, at least not until it's been cleaned up properly. Afaik it still has quite some race conditions in the v2.4, and there are still things left that need to be solved in a nice manner (just ask Alexander Viro...) [snip] Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sun, Jun 22, 2003 at 12:06:16PM +0200, Andreas Barth wrote: > * "Martin v. Löwis" ([EMAIL PROTECTED]) [030622 11:50]: > > problem here (C++ ABI compatibility with other Linux distributions). The > > discussion is now about *how* to fix this bug: > > 1. just bump minimum supported i386-family processor to i486 > 1a. like 1, but just for c++-packages. 1b. Ban C++ and rewrite everything in C, and rejoice over the fact the we are rid of the horrid kludge that is C++. (No, I do not expect this to happen, and I do indeed expect flames for this... I've donned the asbestos suite...) > > 2. like 1, but bump to some other processor. this is not strictly needed > >to fix the bug, but it might be a good idea for other reasons. > >Dropping other architectures to fix this bug is probably not a good > >idea, as it won't fix the bug. > > 3. bump the supported processor, and rename the port > > 4. like 3, and also add an i386 distribution which does not support > >C++ at all > > 5. like 4, but support C++ in a way incompatible with other Linux > >distributions in the i386 distribution. /David -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 27, 2003 at 02:08:46PM -0400, Nathanael Nerode wrote: > >* what opcodes need to be emulated? > > >* all 386->486 opcodes (there's just a few of them, right?) > This is the correct answer. :-) Then all programs can be compiled with > gcc --arch=i486 --tune=i686 (which should probably be mandated as the > standard, in fact). > > >* do you need SMP on 80386? Is there even such thing as 80386 SMP > > machines? Not requiring SMP support would make the ABI change > > trivial... > I think there is no such thing as SMP for 80386. There is afaik. Not in widespread use though, and the Linux kernel hasn't been ported to that hardware. I think we can safely ignore this hardware without stepping on anyone's toes... /David -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Debconf or not debconf
On Thu, Jul 03, 2003 at 12:27:24PM +1000, Herbert Xu wrote: > Joe Drew <[EMAIL PROTECTED]> wrote: > > On Wed, 2003-07-02 at 17:23, Herbert Xu wrote: > >> I'd prefer no interaction at all during installation. I'm perfectly > >> able to read documenation thank you very much. > > > > Happily, the noninteractive debconf frontend exists. > > And getting hundreds of emails after a mass upgrade? No thanks. man 5 procmailrc Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: [VAC] June 9 - August 30 [UPDATE]
On Mon, Jul 07, 2003 at 01:47:41AM -0400, Jimmy Kaplowitz wrote: > On Tue, Jul 01, 2003 at 01:09:22PM -0500, Branden Robinson wrote: > > What you describe has already happened. The "right" to pollute the air > > that people breathe is already bought and sold like a commodity in the > > U.S. > > > > http://www.bizjournals.com/sacramento/stories/2003/04/21/story8.html > > We actually discussed this (pollution permits in general, not the > article to which you refer) in the introductory economics class I'm > taking now. Basically, that allows the government to cause a reduction > in pollution relative to pre-permit levels at the least economic cost > possible, using free-market principles to allocate the permits > efficiently. In other words, those people who can reduce pollution > cheaply will sell the permits to those who have a harder time reducing > pollution, using the profits to offset the cost to their business of > reducing pollution. If the total amount of pollution allowed by all the > permits is less than the pollution before, this will be an environmental > gain at minimal cost. If they built in some way for the allowed > quantities to be adjusted (e.g., variable-value or finite-duration > permits), they can do further reductions using the same > free-market-based system. > > I think it's pretty clever, actually, and it's a good thing for the > environment rather than a bad one. You're not going to get rid of all > pollution, because that would shut down too much business/industry, and > this solution allows for reduction to desired levels in the most > economically efficient manner possible. You and I often have the same > knee-jerk reaction to things, and the first time I heard about these (a > few years ago) I had the same negative reaction you did. Now that I have > learned about it, my reaction in this case has changed. The problem with this thinking of course being, that this way, pollution will stabilize at the levels set, because a lot of countries in the developing world don't really have "use" for their quotas at the moment, and will happily sell their quotas, which will lead to more pollution, not less. Consider: P: pollution, Q: Quota Country A: P: 10 Q: 50 Country B: P: 100 Q: 50 Trade allowed situation: Country A sells 40 of their quota to country B, thus: Country A: P: 10 Country B: P: 90 == P:100 while in the no trade allowed situation we get: Country A: P: 10 Country B: P: 50 == P:60 Of course because mr Bush decided the Kyoto-treaty wasn't really worth signing, we instead have the C alternative: Country A..n: P: x Q: x Country USA: P: inf Q: Couldn't care less... And, while pollution is global, it is of little gain to, say, the smog-infested Los Angeles, that Ulan Bator don't release any pollution if that pollution instead continues to take place in L.A. because the local authorities purchased their quotas (of course, L.A. might be a bad example, because I know that they _are_ doing their best to reduce pollution even though it's a tough struggle.) Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: python 2.2 -> python 2.3 transition
On Thu, Aug 21, 2003 at 01:37:10PM +1000, Anthony Towns wrote: > On Thu, Aug 21, 2003 at 12:34:12PM +1000, Donovan Baarda wrote: > > On Wed, 2003-08-20 at 15:49, Anthony Towns wrote: > > > On Tue, Aug 19, 2003 at 11:44:22PM -0400, Derrick 'dman' Hudson wrote: > > > > The negative effect for the users is that you can't upgrade python > > > > while wxgtk-python is installed so you can't try out the > > > > latest-and-greatest python in the meantime. This is the issue at > > > > hand. > > > Sure you can: > > > $ sudo apt-get install python2.3 > > > The dependency stuff merely notes that upgrading python without also > > > upgrading wxgtk-python may break stuff. > > actually, if the dependencies are right, you cannot upgrade to python > > (2.3) without also upgrading to wxgtk-python (2.3) or de-installing > > wxgtk-python (2.2). > > Sure you can. dpkg --force-depends -i python_*.deb will do it for you. > > If you want something bad enough, and don't mind breaking things, anything's > possible. Please, don't turn Debian into Red Hat ;-) Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bits from the RM
On Sat, Aug 23, 2003 at 01:26:20PM +0200, Tollef Fog Heen wrote: > * Joe Drew > > | On Fri, 2003-08-22 at 01:42, Tollef Fog Heen wrote: > | > * Teófilo Ruiz Suárez > | > > | > | What about Apache? Should we change the apache2 package to apache? > | > > | > No. (Wearing apache & apache2 maintainer hat.) > | > | What are the criteria for the apache package to become Apache 2? > > Seamless upgrade without loss of functionality (that includes > modules), > > or > > making pigs fly. Pink Floyd already made the latter happen for the cover for their album Animals. The pig escaped though, and made it a beautiful story. http://www.myputney.co.uk/wandsworth/community-batterseapowerstation.htm http://www.floydianslip.com/discs/animals.htm /David -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Debian Weekly News - August 19th, 2003
On Sun, Aug 24, 2003 at 02:25:51PM -0400, Brian T. Sniffen wrote: > "Marco d'Itri" <[EMAIL PROTECTED]> writes: > > > On Aug 22, "Brian T. Sniffen" <[EMAIL PROTECTED]> wrote: > > > > >Additionally, whether the DFSG should apply to documentation in Debian > > >is not relevant to the survey, which asks whether the GFDL complies > > >with the DFSG: we can deal with the insanity of whether this software > > >over here is or is not software later, but figuring out whether the > > >GFDL is a DFSG-free licence for software is also important. That's > > >what the survey's asking about. > > I'd say that you have your priorities wrong. If we decide that > > documentation is not software then there is no reason to waste time to > > figure out if the GFDL is DFSG-free or not. > > Of course there is: there is source code licensed under the GFDL in > several Debian packages. In order to not have to do surgery on the > GNU Emacs and GCC packages, the GFDL will have to be found DFSG-free > anyway. > > -Brian Pardon? I seriously hope that you're being sarcastic, because trying to bend over backwards and deliberately trying to misinterpret the DFSG just to get accept certain software is just hipocrisy. Yes, gcc would be nearly impossible to replace, but reasonably one can assume that the parts of it that are licensed under the GFDL are small enough that they are replacable, either by using earlier versions of those files and doing a lot of work on our own to redo the rest, or by rewriting them from scratch. As for GNU Emacs, the situation is less serious, since it's an editor, not a build-essential package. I am pretty sure the same thing can be done here, though. And if its manual is licensed under the GFDL, we'll simply have to make due without the manual, sad but true. Or have the manual in non-free, whatever feels is most appropriate (let's not start a discussion about removing non-free now, shall we?) Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: NMUs applying sleeping wishlist bugs about translation (was something else)
On Mon, Aug 25, 2003 at 08:43:55AM +0200, Andreas Metzler wrote: > Stephen Frost <[EMAIL PROTECTED]> wrote: > > * Andreas Metzler ([EMAIL PROTECTED]) wrote: > >> Parse error. I cannot see a connection between answer and question. > > > Life's a beach. There's all of one line in the developer's reference > > which talks about your responsibilities when doing an NMU: > > "Follow what happens, you're responsible for any bug that you introduced > > with your NMU." Now, this works fine when the official maintainer is > > going to follow up; it doesn't work worth a damn if the official > > maintainer isn't taking care of the package at all anymore. > > Why? Neither the package, nor its quality nor its state of > unmaintainedness has changed, it just has one (wishlist) bug less. [snip] Pah, let's require all maintainers to be able to fix all translation-bugs on their own. It should be a requirement to be fluent in all nuances of all languages to be a maintainer. Right? I mean, you must be able to fix any bug in the package just because you NMU a new translation, so you better be able to fix any translation-bug if you fix a memory-leak, right? Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: vrms and contrib installers (was: Re: "non-free" software included in contrib)
On Tue, Sep 02, 2003 at 05:46:58PM +0200, Mathieu Roy wrote: [snip] > So, is there any obvious reason why some proprietary software get a > "installer" package in contrib instead of a debian package in > non-free? For instance, why the non-free flashplayer does not get a > true debian package in non-free, to benefit truly of the debian tools. Yes, some (a lot of) non-free, but gratis, software do not allow redistribution, or imposes limits on the redistribution such that it cannot be packaged even for non-free. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: GPG Key Signing
On Wed, Jul 20, 2005 at 02:14:10PM -0700, Allyn, MarkX A wrote: > Hello: > > Are there any Debian developers in the Portland, Oregon area? > > I need to have my GPG key signed in order to become a Debian developer. > > I found one person at Intel who had his key signed by a Debian > developer. Can I have him sign it as his was already signed by a > developer, or do I have to find someone who is a current > developer/maintainer? You need to find someone who's a Debian developer; non-direct signatures are not enough. The only *listed* offers for Oregon are: OR, Bend: Nick Rusnov <[EMAIL PROTECTED]> OR, Medford: Sam Powers <[EMAIL PROTECTED]> but I'm not familiar enough with US geography to know if that's close enough. You should however get your key signed by as many people as possible anyway, to build the web of trust, so don't pass up on the chance to get it signed by someone just because they aren't DD's =) Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mass-filing bugs based on piuparts?
On Thu, Jul 21, 2005 at 03:41:10PM +0300, Lars Wirzenius wrote: > I'm running piuparts, my package installation, upgrading, and removal > tester, against etch. It takes a while, and produces a fairly large > number of error logs that need to be investigated manually. This > sometimes reveals a bug in piuparts, and sometimes in the package, or a > depency of the package. > > When there are problems in packages, I would like to file bugs. This is > potentially a large number of bugs, up to hundreds. I want to file them > one by one, not all at once, since it will take weeks or months to go > through the entire archive. A few bugs a day, in other words, not > hundreds all at once. > > I will verify the existence of every bug manually, and will attempt to > use the best possible taste in deciding whether something is a bug in > the package or not. For this first run, I will concentrate on the clear > cases: if a package leaves /usr/bin/foo on the filesystem after purging, > it is pretty clearly a bug. > > Is this acceptable to everyone? Suggestions on how to do this better? I say "Go ahead!". I suggest you start with our base system; hopefully it's already correct, but you never know, and fixing such bugs as early in the release cycle as possible is important. Also, branch packages (for instance perl/php/python/apache/mysql) seems more important to test at an early stage than leaf packages (applications that use those packages). Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Public service announcement about Policy 10.4
On Mon, Aug 01, 2005 at 12:40:43AM -0700, Steve Langasek wrote: > On Mon, Aug 01, 2005 at 08:44:17AM +0200, Thomas Hood wrote: > > Steven Langasek wrote: > > > One might as well be able to expand "posh" as the "Pathologically > > > Overstrict SHell" > > > Well, if, contrary to fact, the idea were widely supported then posh > > could be adapted so that it implemented the minimum set of features > > that Debian expected sh scripts to have. Then posh could be used to > > test whether scripts were compliant. I gather that that was the idea > > behind posh. > > > > while Policy's mandate of POSIX sh is important as a standard, the > > > practical impact is nil once you start questioning those POSIX > > > extensions that are supported by all of bash, ksh, dash, and busybox. > > > I don't know what kind of importance a policy clause can have if it > > has "nil" practical impact. > > I mean that the practical *benefit* of such strict enforcement is nil. The > *impact* is that it would be a royal waste of developer time to make all > scripts compatible with a strict POSIX shell that isn't even optimal from a > size POV. > > It's still useful to have a package which lets one practically test one's > scripts for POSIX compatibility, but it just doesn't make any sense to > enforce this level of strictness archive-wide. I think we should require that a base install should be POSIX compliant; for everything else we can be a bit more lax. But unlike some others, I don't see the point of rejecting patches to fix XSI:isms/bashisms in various shell scripts. It's one thing to not actively fix your packages because other things have a higher priority, but when someone else goes through the trouble of fixing your packages and submit patches, I think rejecting the patches is pretty unnecessary. Having POSIX-clean scripts also ensures that busybox sh will be able to run the scripts, something that's *very* useful on embedded Debian-based systems. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted arts 1.4.2-3 (source i386 all)
On Mon, Aug 15, 2005 at 06:02:06PM -0700, Debian Qt/KDE Maintainers wrote: [snip] > libarts1c2 - aRts sound system core components [snip] >* Use g++-3.4 on arm and m68k since 4.0 ICEs there (#323133): Won't this create g++ transition chaos on those two platforms?! Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#323855: ITP: opencvs -- OpenBSD CVS implementation with special emphasis in security
On Sun, Aug 21, 2005 at 09:11:20PM +1000, Matthew Palmer wrote: > On Sun, Aug 21, 2005 at 10:05:43PM +1200, Martin Langhoff wrote: > > On 8/19/05, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: > > > I'd love to see people migrating to Arch > > > > Being a long-time Arch user, let me tell you that Arch has been > > orphaned upstream. > > Correction: tla, an Arch frontend, has been orphaned upstream. Most of the > interesting development work for the past 6 months or so has been on baz, > another Arch frontend. > > Saying Arch has been orphaned upstream because of Tom Lord's announcement is > roughly similar to saying that Linux has been orphaned because the 2.0 > kernel series is no longer maintained... Oh, thanks for the news, I didn't know that. [snip] Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Results of the meeting in Helsinki about the Vancouver proposal
On Sun, Aug 21, 2005 at 07:28:55PM +0200, Jonas Smedegaard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 21-08-2005 03:58, Wouter Verhelst wrote: > > > We also came to the conclusion that some of the requirements proposed in > > Vancouver would make sense as initial requirements -- requirements that > > a port would need to fulfill in order to be allowed on the mirror > > network -- but not necessarily as an 'overall' requirement -- a > > requirement that a port will always need to fulfill if it wants to be > > part of a stable release, even if it's already on the mirror network. > > Those would look like this: > [snip] > > Overall: > [snip] > > - binaries must have been built and signed by official Debian > > Developers > > Currently, sponsored packages are only signed, not built, by official > Debian Developers. I don't know about others, but I never sign and upload packages built by others; I always rebuild packages when I sponsor someone. I really hope others do the same. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing /etc/hotplug.d/ support
On Wed, Aug 24, 2005 at 11:14:53PM +0200, martin f krafft wrote: > also sprach Gabor Gombas <[EMAIL PROTECTED]> [2005.08.24.2204 +0200]: > > So IMHO udev is more generic than hotplug. > > This is Unix, not monolithic-land. > > Also, udev was set out to do nothing other than device node > management. Well, having both hotplug and udev means a lot of code duplication. That's not very Unix either... > > > The other comment is that udev is not generally accepted. A lot > > > of people still have reservations about it. > > > > I think the reason is that udev is still under rapid development > > and people are only starting to explore the flexibility it > > provides. > > Uh, that's one way of looking at it. The other might be sheer > insanity on the side of the developers. Well, since Greg K-H is upstream for both udev and hotplug, I'd say that's probably quite unlikely... [snip] Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Thu, Aug 25, 2005 at 12:17:56PM -0300, Henrique de Moraes Holschuh wrote: > On Thu, 25 Aug 2005, Marc Chantreux wrote: > > that is a point which surprise me : i understand the dash for a posix > > and lightweight attitude but why use bash as "modern shell" ? why not > > perl or zsh (which are both more powerfull) ? > > Well, as long as you don't start using stuff that breaks often, or that > loads a ton of crap dynamically, or (even worse) is in /usr instead of /bin > or /sbin... > > Note that using dash is probably MUCH faster than perl. I don't know about > zsh. Well, writing scripts that use /bin/sh or perl means that the init script will run without any dependencies on optional packages. zsh is Priority: optional... And while dash is also optional, all *correctly* written /bin/sh scripts should work with dash too. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Fri, Aug 26, 2005 at 10:19:06PM +0200, Adrian von Bidder wrote: > On Wednesday 24 August 2005 17.15, Miquel van Smoorenburg wrote: > > Make sure you use only POSIX features when doing this. I think > > "grep -o" is a GNU extension, FreeBSD doesn't have it for example. > > Doesn't the 'only POSIX' apply to the shell code only? At least, shouldn't > it be judged on a per-tool basis? While awk is (was?) usually mawk on > Debian, and not gawk, I don't think anybody uses a BSD grep on their Debian > system. Please don't standardise on a minimal future set only for the > corner case that somebody cripples his system beyond every reassonable > limit. > > The 'POSIX shell' rule is here for a reason: there are people with /bin/sh > being not bash. For other tools, this rule can be relaxed, imho. Well, it's helpful when you might want to replace grep etc with its busybox counterparts; for instance, busybox grep doesn't support -o. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: major problem with gnome-games dependency]
On Tue, Oct 11, 2005 at 04:21:30PM -0400, Joe Smith wrote: > > "Frans Pop" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >On Tuesday 11 October 2005 21:34, Daniel Burrows wrote: > >> No, because people like to turn off the installation of > >>recommendations > > > >Or yes, because it offers more flexibility to people who have a basic idea > >of what they are doing. > > Exactly. Unless you plan to examine each and every reccomendation of each > and every package you install then you should not turn off reccomendation > installation. > > Recoomendations are intended to be weak depends. In other words > recommendations mean: "This package does not actually NEED the listed > packages, but it is unlikely you will want to install this package without > the listed package." An even better way to think of it is a Depends that > can be overridden without apt complaining. Well, the problem is the widespread misuse of Recommends and Depends. People have a tendency to use Depends where a Recommends would be enough, and a Recommends where a Suggests would do the trick. And until this is corrected, a lot of us won't enable default installation of Recommendations, simply because our systems get unnecessarily bloated. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Sat, Aug 27, 2005 at 02:16:39PM -0700, Thomas Bushnell BSG wrote: > David Weinehall <[EMAIL PROTECTED]> writes: > > > And while dash is also optional, all *correctly* written /bin/sh > > scripts should work with dash too. > > That's incorrect. A correctly written /bin/sh script is allowed to > use Debian programs (including, say, test) and expect to get the > Debian versions. Please read the thread on the policy list from quite > a while ago. (Sorry for an extremely late reply, found this sorted into the wrong mailbox): test is in /usr/bin/ (together with [), thus at the very least init-scripts cannot rely on behaviour provided by /usr/bin/test, but make do with what /bin/sh provides, which limits you to what POSIX-test (e.g. dash) provides. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Mirror with lzma compressed packages
On Tue, Jan 16, 2007 at 09:25:38AM +0900, Junichi Uekawa wrote: > Hi, > > > > I'm not sure if the smaller size that LZMA allows is worth it if > > > it then takes a lot longer to unpack files, or if it becomes > > > impossible to do so due to memory requirements. > > > > I don't know on memory requirements. but i didn't notice any speed > > drawbacks for my personal use. > > > Last I checked, bzip2 requires a lot of memory to decompress. It's > documented in bzip2 manpage. 8MB is still a large number considering > embedded devices and Debian running on virtual machines. How about > LZMA ? > > bzip2: > Compress Decompress Decompress Corpus >Flag usage usage -s usage Size [snip] > -9 7600k 3700k2350k 828642 2350k (+ 828642, I guess) != 8MB... The 8MB you cite is for compressing, not decompressing. [snip] regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
