Re: Should this be filed as grave? Gcc-2.95
On Mon, 4 Aug 2003 23:37:32 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: What you meant to do was to run make CC=gcc-2.95 instead of make. There is no need to futz around with the default gcc version; just ask for what you want. Uh, no. I am aware of that. That, however, did not prevent it from running the wrong GCC. v2.4.21 of the kernel had a problem with 3.3. It would die repeatedly on the same line in ide-cd.h. I did tell make to use gcc-2.95 and it failed on the exact same line. Removing gcc, which is 3.3, gcc-2.95 which depended on 3.3 (this is NOT 2.95 in my eyes) and then installing the packages from woody did allow me to recompile that version of the kernel. I fail to see how 2.95 installing 3.3 somehow equates to 2.95. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. |-- Lenny Nero - Strange Days ---+- pgpuXaBQgLH2c.pgp Description: PGP signature
Re: Should this be filed as grave? Gcc-2.95
On Mon, 4 Aug 2003 21:14:08 -0700 Steve Lamb [EMAIL PROTECTED] wrote: Uh, no. I am aware of that. That, however, did not prevent it from running the wrong GCC. v2.4.21 of the kernel had a problem with 3.3. Correction, 2.4.20. For some reason 2.4.21 seems to be crashing my system hard every few minutes/hours/days (pick one). EG, see: 1 151 days, 15:35:00 | Linux 2.4.20Tue Feb 4 01:18:37 2003 2 8 days, 06:50:33 | Linux 2.4.21Sun Jul 13 06:54:34 2003 3 7 days, 12:59:18 | Linux 2.4.21Sat Jul 5 17:54:21 2003 4 3 days, 19:56:57 | Linux 2.4.21Wed Jul 30 23:49:33 2003 5 3 days, 04:21:28 | Linux 2.4.21Thu Jul 24 05:24:04 2003 6 2 days, 14:54:17 | Linux 2.4.21Mon Jul 21 13:55:47 2003 7 2 days, 07:26:42 | Linux 2.4.21Sun Jul 27 11:01:21 2003 8 0 days, 20:15:04 | Linux 2.4.21Tue Jul 29 19:09:21 2003 9 0 days, 15:30:14 | Linux 2.4.21Sun Aug 3 21:08:12 2003 10 0 days, 06:15:31 | Linux 2.4.21Wed Jul 30 15:26:33 2003 Unfortunately I didn't keep the 2.4.20 kernel package hence the need to recompile it. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. |-- Lenny Nero - Strange Days ---+- pgpoqGLs3OGW1.pgp Description: PGP signature
Re: Should this be filed as grave? Gcc-2.95
On Mon, Aug 04, 2003 at 09:14:08PM -0700, Steve Lamb wrote: On Mon, 4 Aug 2003 23:37:32 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: What you meant to do was to run make CC=gcc-2.95 instead of make. There is no need to futz around with the default gcc version; just ask for what you want. Uh, no. I am aware of that. That, however, did not prevent it from running the wrong GCC. v2.4.21 of the kernel had a problem with 3.3. It would die repeatedly on the same line in ide-cd.h. I did tell make to use gcc-2.95 and it failed on the exact same line. Removing gcc, which is 3.3, gcc-2.95 which depended on 3.3 (this is NOT 2.95 in my eyes) and then installing the packages from woody did allow me to recompile that version of the kernel. I fail to see how 2.95 installing 3.3 somehow equates to 2.95. I fail to see how 2.95 installing both 3.3 and 2.95 somehow equates to a problem! It brings in 3.3 for hysterical raisins, but that doesn't stop gcc-2.95 from being perfectly usable. I build kernels with alternate compilers all the time. Did you check the log to see which compiler the kernel actually built with? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Should this be filed as grave? Gcc-2.95
On Tue, 5 Aug 2003 00:25:27 -0400 Daniel Jacobowitz [EMAIL PROTECTED] wrote: I fail to see how 2.95 installing both 3.3 and 2.95 somehow equates to a problem! A failed kernel compile when trying to bring stability to a machine constitutes as a problem in my book. I build kernels with alternate compilers all the time. Did you check the log to see which compiler the kernel actually built with? Given that I told it to build with 2.95 and it failed in the same manner as with 3.3 but when I installed 2.95 from Woody which ONLY installs 2.95 it succeeded I, quite frankly, don't care if it compiled with 1.10.0.101.10.2. 2.95 should install what it says it installs, 2.95. Debian has version numbers in the names for a reason and that reason being when people NEED the previous version and not to upgrade to the current one. See the whole thread about exim vs exim4 as reference. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. |-- Lenny Nero - Strange Days ---+- pgpObY4Tf4W0w.pgp Description: PGP signature
Re: libraries being removed from the archive
Hi, Peter Mathiasson wrote:
[...] distcc sends the complete preprocessed source code across
the network for each job.
Hmm, OK, but that would just speedup the actual compilation. Granted,
that's the largest chunk, but cpp/asm/ld could do with a speed-up too.
Anyway, thanks for the pointers to existing software everybody.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
If Columbus had had an advisory committee he would probably still be at
the dock.
-- Justice Arthur Goldberg
Debconf in Porto Alegre (Re: debconf 2005 in Vienna, Austria)
On Wed, Jul 30, 2003 at 07:37:29PM +, Michelle Ribeiro wrote: Em 30 Jul 2003 15:09:51 -0400 Joe Drew [EMAIL PROTECTED] escreveu: I've been waiting for them to speak up as they have said they would. I am in favour of holding Debconf 4 in South America, but will organise it in Vancouver if necessary. Yeah, we would like to host the next Debconf in Brazil, Porto Alegre, some days before the International Free Software Forum. Thus, devels can join us at this event, if they like. With a list set up, discussion planning, and funding research well underway and with the most prominent Debconf4 organizer up until now (Joe Drew) in support, I think the Brazilians have their foot in the door on this one. There was a bit of discussion about doing it again next year at Brazil at Debconf3 with a lot of positive feedback. Doing it with the IFSF will cut down on travel costs and increase sponsorship possibilities. Personally, I really like to see South America host an official Debconf. With a bit of searching the tickets can be reasonable from both the North American and Europe. Once you're there, you will make it up quickly because you won't spend much while you are there. It would be nice to give the folks in South America, who have been largely unrepresented at the past Debconfs, a chance to participate. Brazil has been extremely active in the Free Software arena and much of the rest of the world hears remarkably little. Before make a official proposal, we are checking for free food and accommodations, plane tickets and some government support. This seems extremely reasonable. I hope this all works out well and am looking forward to hearing more about this. As the dollar is 1,00 to 2.89 real (local money) this travel should be very cheap. :) From what I've been told, this means that in practical terms you can go out to dinner and eat and drink as much as you can and have trouble dropping more than 12USD. But IMHO, the best part about having Debconf in Brazil that is those those us that go to Debconf also get to go to Brazil. :) Regards, Mako -- Benj. Mako Hill [EMAIL PROTECTED] http://mako.yukidoke.org/ pgpxRVHX0GcYl.pgp Description: PGP signature
Re: Should this be filed as grave? Gcc-2.95
On Mon, Aug 04, 2003 at 09:14:08PM -0700, Steve Lamb wrote: Uh, no. I am aware of that. That, however, did not prevent it from running the wrong GCC. v2.4.21 of the kernel had a problem with 3.3. It would die repeatedly on the same line in ide-cd.h. I did tell make to use gcc-2.95 and it failed on the exact same line. Removing gcc, which is 3.3, gcc-2.95 which depended on 3.3 (this is NOT 2.95 in my eyes) and then installing the packages from woody did allow me to recompile that version of the kernel. What exactly does gcc-2.95 -v say? It could be a different version on 2.95 than what's in woody.
Re: Should this be filed as grave? Gcc-2.95
Steve Lamb wrote: I build kernels with alternate compilers all the time. Did you check the log to see which compiler the kernel actually built with? Given that I told it to build with 2.95 and it failed in the same manner as with 3.3 but when I installed 2.95 from Woody which ONLY installs 2.95 it succeeded I, quite frankly, don't care if it compiled with 1.10.0.101.10.2. 2.95 should install what it says it installs, 2.95. Debian has version numbers in the names for a reason and that reason being when people NEED the previous version and not to upgrade to the current one. I have managed to compile using gcc-2.95, using the gcc-2.95 package from testing a few weeks ago. I'm sure that it was actually gcc-2.95 that was used, since the program I was compiling has a bug which manifests itself on gcc 3.x, but not 2.95. And it worked when I used gcc-2.95, (from the debian package), but not with gcc-3.x (also from the debian packages). -- Keith
Re: libraries being removed from the archive
On Tue, Aug 05, 2003 at 01:07:42AM +0400, Nikita V. Youshchenko wrote: So buidd + distcc on a slow m68k/arm/whatever, and distccd on a fast P4 or Athlon, or even on several of those. This is expected to reduce the compile time to almost the same as it is on x86 :). I'm not sure that's true; but it would be interesting to know for sure. Many packages spend a lot of time running tests and generating documentation. These would still take forever. Also, when using distcc, the m68k is still responsible for preprocessing source, assembling compiler output, and linking objects. These operations take up a nontrivial amount of time on m68k. Plus, the buildd's currently install every non-essential build dependency before building a specific package, and remove them after. Running dpkg is slow on m68k, especially if you're installing a giant chain of build dependencies like GNOME or KDE. I'm sure distcc would help though ;).
Bug#204177: ITP: sec-rpc -- rpc-proxy that allows tunneling of nis and nfs over ssh
Package: wnpp Version: N/A; reported 2003-08-05 Severity: wishlist * Package name: sec-rpc Version : 1.5.2 Upstream Author : John Bowman [EMAIL PROTECTED] * URL : http://www.math.ualberta.ca/imaging/snfs/ * License : GPL Description : rpc-proxy that allows tunneling of nis and nfs over ssh ecure versions of the Network File System (SNFS) and Network Information System (SNIS) have now been implemented via SSH2 tunneling of UDP datagrams, as described in the SSH FAQ. This tunneling software is available for download under the GPL License: sec_rpc-1.52.tar.gz. This is a major enhancement of the original sec_rpc package developed by Holger Trapp. -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux voyager 2.4.20-xfs #1 SMP Mit Jan 29 18:47:59 CET 2003 i586 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: How to install X-Chat in five hours (or more)
Hey guys, I was amused to see my blog post [1] made it to this list. I figured I'd clarify a few points which were omitted from that blog in the interests of brevity and humour. Mike Hommey [EMAIL PROTECTED] wrote: Unfortunately, his main problem is Having not used Debian for about 8 years. Most of your new users (all of them in fact, by definition!) will never have used Debian before. This should not stop them using your product. Part of the problem I had was that I had a vague understanding that there was something called apt, but that I didn't know what it was or how to do anything with it. The man page said to see apt-get's; apt-get's man page suggested the tool was a back-end but didn't really give any clues as to what front end to use. The strange thing is that he has been able to apt-get install aptitude, but tryed something else for xchat at first... I did actually try using apt-get originally when I had my original libgtk1.2 problem: # apt-get libgtk1.2 E: Invalid operation libgtk1.2 I tried to understand this: # man apt-get /E: Invalid Pattern not found (press RETURN) After reading the whole man page, I did try apt-get install libgtk1.2, but then I got the whole conflict problem I mention later in my blog. I decided to get the source and do it myself, but since I didn't know where that would be, I switched to trying to get X-Chat, and since I was already in source mode, it didn't even cross my mind to use apt-get for that. (After all, apt-get had just failed me, why would it succeed now?) To the end user (me), apt-get is arbitrarily verbose. Selecting previously deselected package libbla3.2? Get:1 ftp://apt sid/main libbla3.2 3.2.10-9 [827kB]? Look at operating systems used by less intelligent users. They just see: [# ] 60% 2 minutes remaining Admittedly, this is usually followed by a crash, but the user is not intimidated. (Having said that, personally, I quite like seeing the verbose output, it's useful for debugging. Most users don't.) And another thing : it seems that the pre-installed Debian he got was configured with both testing/unstable in the sources.list file. Pinning is not the easiest thing to catch when you are (alone) beginner with Debian... Matt Zimmerman [EMAIL PROTECTED] wrote: It's also a really stupid trick to pull on someone for whom you are installing a system where they hope to get actual work done. Yeah. Unfortunately, to support my radeon chipset I have to use the unstable version apparently. (though it's equally possible that he did this himself, making random changes without understanding them in the hope of making things work) Nope, I wouldn't even have known where to start with respect to using unstable releases if it wasn't for the kind people on #mozilla. :-) Nikolai Prokoschenko [EMAIL PROTECTED] wrote: | | I used apt-get to get aptitude. I fired up aptitude. The writer is obviously a moron if he did this with such ease and it never occured to him he could've done the same for any of the other packages he needed. While I wouldn't like to dispute my moronity, as I described above, I had tried apt-get earlier with little success. I used it for aptitude possibly because Eddy suggested I do that, or possibly because having had a break, I was no longer locked on to the idea of getting the source for the packages I wanted. I think Debian's package system is remarkably nice. Unfortunately, it's UI leaves a lot to be desired. The biggest problem is probably the package names: freetype, pango, libgtk2.0, etc, mean absolutely nothing to me, as a user, and I really shouldn't ever have to even see these packages. I really think aptitude should only show end user packages with decent, readable, localised names (Apache Web Server, x Chat (IRC Client), Infrared Control for XMMS). At the moment the user is completely overwhelmed by the list of packages, which is not helped by the fact that each one comes with a dozen or more libraries, extensions, and so forth. Anyway. Just a few thoughts. :-) -- References -- [1] http://ln.hixie.ch/?start=1060025253count=1 -- Ian Hickson )\._.,--,'``.fL meow /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
Re: How to install X-Chat in five hours (or more)
On Tuesday 05 August 2003 10:33, Ian Hickson wrote: Hey guys, I was amused to see my blog post [1] made it to this list. I figured I'd clarify a few points which were omitted from that blog in the interests of brevity and humour. Mike Hommey [EMAIL PROTECTED] wrote: Unfortunately, his main problem is Having not used Debian for about 8 years. Most of your new users (all of them in fact, by definition!) will never have used Debian before. This should not stop them using your product. What I meant with that is that your main problem is that you have an old linux user approach. A typical new user won't even try to build from sources. [snip] After reading the whole man page, I did try apt-get install libgtk1.2, but then I got the whole conflict problem I mention later in my blog. This is the problem with pinning. It is not easy to handle for beginners (especially if they are by themselves), and it is IMHO a very bad idea from whoever installed a Debian system on your laptop to have put different releases sources in the sources.list file. [snip] (After all, apt-get had just failed me, why would it succeed now?) Because Dr. Murphy sometimes forgets to annoy you ? ;) [snip] Yeah. Unfortunately, to support my radeon chipset I have to use the unstable version apparently. I think the testing version works at least in 2D for every radeon chip. What can't be denied, is that X is not the easiest part to configure on a Debian system... (though it's equally possible that he did this himself, making random changes without understanding them in the hope of making things work) Nope, I wouldn't even have known where to start with respect to using unstable releases if it wasn't for the kind people on #mozilla. :-) When trying to solve debian issues, try #debian ;) Mike -- Do you know what's the best thing about being me ? There's so many me ! -- Agent Smith Reloaded
Re: How to install X-Chat in five hours (or more)
I think Debian's package system is remarkably nice. Unfortunately, it's UI leaves a lot to be desired. The biggest problem is probably the package names: freetype, pango, libgtk2.0, etc, mean absolutely nothing to me, as a user, and I really shouldn't ever have to even see these packages. I really think aptitude should only show end user packages with decent, readable, localised names (Apache Web Server, x Chat (IRC Client), Infrared Control for XMMS). At the moment the user is completely overwhelmed by the list of packages, which is not helped by the fact that each one comes with a dozen or more libraries, extensions, and so forth. Some people like Ian Hickson don't want to see package names like libgtk2.0. But _I_ want to see this, I am sys admin and want to know exactly what I am putting on _my_ systems. Just one of the reasons why I like GNU/Linux ... I know what I'm doing! Anyway, does this mean we need something like a GNU/Linux Debian and a GNU/Linux Debian For Dummies showing only icons? Fred -- http://www.linox.be L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^
QQ230414701
http://www.35home.com http://bbs.35home.com 230414701 - 30M asp 60 100M asp 100 50M php 705Mmysql 100 php 100mysql 1+50M(ASP)+10===120( 2+20M(html)+10==100 http://www.35home.com; QQ230414701
buildd probs sbcl/common-lisp-controller
What's the status of the sbcl/common-lisp-controller problems that were blocking builds on sparc and other platforms? -- Neil Roeth
Re: libraries being removed from the archive
On Tue, Aug 05, 2003 at 01:07:42AM +0400, Nikita V. Youshchenko wrote: So buidd + distcc on a slow m68k/arm/whatever, and distccd on a fast P4 or Athlon, or even on several of those. This is expected to reduce the compile time to almost the same as it is on x86 :). I'm not sure that's true; but it would be interesting to know for sure. Many packages spend a lot of time running tests and generating documentation. Maybe this can be compensated by running distccd on several fast x86 machines, and run parallel make while package building? Distcc is known to scale almost lineary for small number of hosts. I use distcc at regular basis and can confirm this. Perhaps someone who has access to both m68k and a fast x86 connected by a fast network should try this.
Re: Should this be filed as grave? Gcc-2.95
On Mon, Aug 04, 2003 at 09:14:08PM -0700, Steve Lamb wrote: On Mon, 4 Aug 2003 23:37:32 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: What you meant to do was to run make CC=gcc-2.95 instead of make. There is no need to futz around with the default gcc version; just ask for what you want. Uh, no. I am aware of that. That, however, did not prevent it from running the wrong GCC. Works fine for me. *** End of Linux kernel configuration. *** Check the top-level Makefile for additional configuration. *** Next, you must run 'make dep'. mizar:[.../linux/kernel-source-2.4.21] make CC=gcc-2.95 make[1]: Entering directory `/space/tmp/mdz/linux/kernel-source-2.4.21/arch/i386/boot' make[1]: Nothing to be done for `dep'. make[1]: Leaving directory `/space/tmp/mdz/linux/kernel-source-2.4.21/arch/i386/boot' rm -f .depend .hdepend make _sfdep_kernel _sfdep_drivers _sfdep_mm _sfdep_fs _sfdep_net _sfdep_ipc _sfdep_lib _sfdep_crypto _sfdep_arch/i386/kernel _sfdep_arch/i386/mm _sfdep_arch/i386/lib _FASTDEP_ALL_SUB_DIRS=kernel drivers mm fs net ipc lib crypto arch/i386/kernel arch/i386/mm arch/i386/lib make[1]: Entering directory `/space/tmp/mdz/linux/kernel-source-2.4.21' make -C kernel fastdep make[2]: Entering directory `/space/tmp/mdz/linux/kernel-source-2.4.21/kernel' gcc-2.95 -D__KERNEL__ -I/space/tmp/mdz/linux/kernel-source-2.4.21/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -nostdinc -iwithprefix include -E -D__GENKSYMS__ signal.c [...] Yes, I know that's 2.4.21, but I'm not going to unpack a whole 2.4.20 tree to demonstrate that it works the same way. It does. v2.4.21 of the kernel had a problem with 3.3. It would die repeatedly on the same line in ide-cd.h. I did tell make to use gcc-2.95 and it failed on the exact same line. Removing gcc, which is 3.3, gcc-2.95 which depended on 3.3 (this is NOT 2.95 in my eyes) and then installing the packages from woody did allow me to recompile that version of the kernel. gcc-2.95 doesn't depend on 3.3; it depends on the gcc package, which happens to be version 3.3 in unstable. That package doesn't contain any compilers; it just sets the default compiler and related tools, e.g. /usr/bin/gcc. I fail to see how 2.95 installing 3.3 somehow equates to 2.95. It doesn't. -- - mdz
Re: Should this be filed as grave? Gcc-2.95
On Tue, 5 Aug 2003 08:56:50 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: Yes, I know that's 2.4.21, but I'm not going to unpack a whole 2.4.20 tree to demonstrate that it works the same way. It does. I never said it didn't work. What I said was that when I did it 2.4.20 had the same error as if it were compiled with 3.3. So without compiling 2.4.20 w/ide-cd in it you're not replicating what I did and providing any basis of comparison whatsoever. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. |-- Lenny Nero - Strange Days ---+- pgpzCqOoIThkC.pgp Description: PGP signature
Re: Should this be filed as grave? Gcc-2.95
On Tue, Aug 05, 2003 at 06:00:27AM -0700, Steve Lamb wrote: On Tue, 5 Aug 2003 08:56:50 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: Yes, I know that's 2.4.21, but I'm not going to unpack a whole 2.4.20 tree to demonstrate that it works the same way. It does. I never said it didn't work. What I said was that when I did it 2.4.20 had the same error as if it were compiled with 3.3. Then perhaps this particular problem was not with gcc 3.3. I think some additional investigation would be prudent before any talk about grave bugs. -- - mdz
Re: Should this be filed as grave? Gcc-2.95
On Mon, Aug 04, 2003 at 10:51:41PM -0700, Steve Lamb wrote: On Tue, 5 Aug 2003 00:25:27 -0400 Daniel Jacobowitz [EMAIL PROTECTED] wrote: I fail to see how 2.95 installing both 3.3 and 2.95 somehow equates to a problem! A failed kernel compile when trying to bring stability to a machine constitutes as a problem in my book. I build kernels with alternate compilers all the time. Did you check the log to see which compiler the kernel actually built with? Given that I told it to build with 2.95 and it failed in the same manner as with 3.3 but when I installed 2.95 from Woody which ONLY installs 2.95 it succeeded I, quite frankly, don't care if it compiled with 1.10.0.101.10.2. 2.95 should install what it says it installs, 2.95. Debian has version numbers in the names for a reason and that reason being when people NEED the previous version and not to upgrade to the current one. See the whole thread about exim vs exim4 as reference. And you're missing the point. Installing gcc-2.95 does install GCC 2.95. What else it installs is irrelevant. It installs a particular version of glibc that isn't gcc 2.95, too. Please stop crusading, and find out what your kernel build actually did. Because it works just fine for all the rest of us. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: How to install X-Chat in five hours (or more)
Frederik Rousseau [EMAIL PROTECTED] writes: I really think aptitude should only show end user packages with decent, readable, localised names (Apache Web Server, x Chat (IRC Client), Infrared Control for XMMS). At the moment the user is completely overwhelmed by the list of packages, which is not helped by the fact that each one comes with a dozen or more libraries, extensions, and so forth. Some people like Ian Hickson don't want to see package names like libgtk2.0. But _I_ want to see this, I am sys admin and want to know exactly what I am putting on _my_ systems. Just one of the reasons why I like GNU/Linux ... I know what I'm doing! Anyway, does this mean we need something like a GNU/Linux Debian and a GNU/Linux Debian For Dummies showing only icons? It probably means there should be a configuration option in aptitude to hide sections like devel, libdevel, libs, and interpreters, since end users typically don't care (and 90% of the time I find myself not caring, too). Perhaps suggesting to new users that they look in the tasks section of aptitude would help reduce the package overload, too. I don't think we need to abandon the power of our current infrastructure, just have ways of making it less visible for people who don't want it. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell
Re: [Debconf] Re: The slides for my talk
On Wed, 23 Jul 2003, Branden Robinson wrote: Well, poor Joey Hess didn't notice it, and he's a native speaker. ;-) This does not necessarily help! In Germany we all know that best English is spoken by native German spaekars - at least we understand them best (because we do mostly the same mistakes). ;-) I guess this works for Italian people, too. I picked up on it, I think, because I'd been hanging around Enrico a fair amount and could tell he had a good sense of humor. Definitely! Kind regards Andreas, who just placed a symlink to my talks directory to the apropriate place. gluck:/home ls -l -d */public_html/talks drwxr-xr-x3 dopeyDebian 4096 Jan 10 2002 dopey/public_html/talks drwxr-xr-x5 enrico Debian 4096 Jul 22 06:46 enrico/public_html/talks drwxr-xr-x2 joerglan Debian 4096 Jul 14 07:55 joergland/public_html/talks drwxr-xr-x3 kelbert Debian 4096 Jul 25 17:00 kelbert/public_html/talks drwxr-xr-x4 lolando Debian 4096 Jun 12 15:00 lolando/public_html/talks drwxr-x---2 maxx Debian 4096 Mar 11 14:40 maxx/public_html/talks drwxr-xr-x3 mjb Debian 4096 Jul 22 09:53 mjb/public_html/talks lrwxrwxrwx1 tilleDebian 16 Aug 5 08:03 tille/public_html/talks - debian-med/talks
Re: How to install X-Chat in five hours (or more)
On Tue, 2003-08-05 at 15:04, David Z Maze wrote: I don't think we need to abandon the power of our current infrastructure, just have ways of making it less visible for people who don't want it. Just a random off-the-wall idea, but *maybe* there could be a new package tag added which means that a package is something that Joe User is likely to use, i.e. a good word processor/web browser/etc. Then a minimal graphical interface could be built to show just these. Of course, the flames when deciding what packages to tag would be huge... Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part
Re: Should this be filed as grave? Gcc-2.95
On Tue, 5 Aug 2003 09:25:38 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: Then perhaps this particular problem was not with gcc 3.3. I think some additional investigation would be prudent before any talk about grave bugs. Which is why I asked here first before just filing. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. |-- Lenny Nero - Strange Days ---+- pgpw6uX16u2UM.pgp Description: PGP signature
Re: Should this be filed as grave? Gcc-2.95
On Tue, 5 Aug 2003 09:33:53 -0400 Please stop crusading, and find out what your kernel build actually did. Because it works just fine for all the rest of us. Who's crusading? I am pointing out what I see as an apparent problem for discussion. Crusading would be to file the damned bug without discussion and defending it to the last breath. Calm down! -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. |-- Lenny Nero - Strange Days ---+- pgpClj4e8XXDx.pgp Description: PGP signature
Re: How to install X-Chat in five hours (or more)
On Tue, Aug 05, 2003 at 01:33:19AM -0700, Ian Hickson wrote: Part of the problem I had was that I had a vague understanding that there was something called apt, but that I didn't know what it was or how to do anything with it. The man page said to see apt-get's; apt-get's man page suggested the tool was a back-end but didn't really give any clues as to what front end to use. Not directly, but the SEE ALSO list does include dselect(8) which is what you really should have used. [...] To the end user (me), apt-get is arbitrarily verbose. Selecting previously deselected package libbla3.2? Get:1 ftp://apt sid/main libbla3.2 3.2.10-9 [827kB]? Look at operating systems used by less intelligent users. They just see: [# ] 60% 2 minutes remaining I don't see how some extra verbosity hurts. apt-get still displays a percentage and a time estimate. Frankly if verbosity loses us some users, too bad. I'm sure we pick up more users because of the same. To rant a bit, the thing that bugs me the most about MS Windows is how when it breaks randomly you can't fix it because it runs on smoke and mirrors and doesn't give helpful information on what went wrong. With UNIX/Linux you get details and you can fix it. I think Debian's package system is remarkably nice. Unfortunately, it's UI leaves a lot to be desired. The biggest problem is probably Which UI did you use? We have a few. apt-get is not an interface for the Debian newbie. dselect and aptitude are GUI tools if that's what you need. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Should this be filed as grave? Gcc-2.95
On Mon, Aug 04, 2003 at 09:20:21PM -0700, Steve Lamb wrote: On Mon, 4 Aug 2003 21:14:08 -0700 Steve Lamb [EMAIL PROTECTED] wrote: Uh, no. I am aware of that. That, however, did not prevent it from running the wrong GCC. v2.4.21 of the kernel had a problem with 3.3. Correction, 2.4.20. For some reason 2.4.21 seems to be crashing my system hard every few minutes/hours/days (pick one). Don't compile your kernel with gcc 3.3. I don't know whether the bugs lie in the kernel or in gcc (or both), but this combination does not work correctly. -- - mdz
Re: Should this be filed as grave? Gcc-2.95
On Tue, 5 Aug 2003 10:54:38 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: Don't compile your kernel with gcc 3.3. I don't know whether the bugs lie in the kernel or in gcc (or both), but this combination does not work correctly. Yeah. That was the whole reason I was trying to get a copy of 2.4.20 compiled with gcc 2.95. I didn't know if it was the compiler or the newer version of the kernel that had the problem. I just knew that my problems started with the newer version. If 2.4.20 is stable for 2 weeks I'll move it to my stable boot option, compile 2.4.21 w/gcc 2.95 and install it as the current and give it a whirl. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. |-- Lenny Nero - Strange Days ---+- pgpAa52aqzGqG.pgp Description: PGP signature
Re: Should this be filed as grave? Gcc-2.95
On Tue, Aug 05, 2003 at 07:59:20AM -0700, Steve Lamb wrote: Yeah. That was the whole reason I was trying to get a copy of 2.4.20 compiled with gcc 2.95. I didn't know if it was the compiler or the newer version of the kernel that had the problem. I just knew that my problems started with the newer version. If 2.4.20 is stable for 2 weeks I'll move it to my stable boot option, compile 2.4.21 w/gcc 2.95 and install it as the current and give it a whirl. 2.4.21 built with gcc 2.95 has been rock solid for me. -- - mdz
Re: Should this be filed as grave? Gcc-2.95
On Tue, Aug 05, 2003 at 07:59:20AM -0700, Steve Lamb wrote: On Tue, 5 Aug 2003 10:54:38 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: Don't compile your kernel with gcc 3.3. I don't know whether the bugs lie in the kernel or in gcc (or both), but this combination does not work correctly. Yeah. That was the whole reason I was trying to get a copy of 2.4.20 compiled with gcc 2.95. I didn't know if it was the compiler or the newer version of the kernel that had the problem. I just knew that my problems started with the newer version. If 2.4.20 is stable for 2 weeks I'll move it to my stable boot option, compile 2.4.21 w/gcc 2.95 and install it as the current and give it a whirl. [snip] Did you check your compile logs to see if it actually compiled with gcc-2.95 or with just gcc (==3.3) ? It happened to me several times that when building 2.4.21, it would use gcc-2.95 for the initial configuration and cleanup targets (since I specified CC=gcc-2.95), but revert to gcc for the actual build. I had to hand-edit kernel makefiles to stop it from using gcc by default and use gcc-2.95 instead. Or perhaps try setting CC=gcc-2.95 in your environment before running the build. T -- We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL
Re: How to install X-Chat in five hours (or more)
On Wed, 6 Aug 2003, Hamish Moffatt wrote: On Tue, Aug 05, 2003 at 01:33:19AM -0700, Ian Hickson wrote: Part of the problem I had was that I had a vague understanding that there was something called apt, but that I didn't know what it was or how to do anything with it. The man page said to see apt-get's; apt-get's man page suggested the tool was a back-end but didn't really give any clues as to what front end to use. Not directly, but the SEE ALSO list does include dselect(8) which is what you really should have used. The term dselect means nothing to me. It isn't a usable name. That's another example of the problem I mentioned. Would it not be possible for debian to have a command setup or install or something similarly named? Note that, if for some reason the user knew about the command apropos, even that wouldn't help him -- none of dselect, aptitude, and apt-get come up for apropos install or apropos setup. To the end user (me), apt-get is arbitrarily verbose. Selecting previously deselected package libbla3.2? Get:1 ftp://apt sid/main libbla3.2 3.2.10-9 [827kB]? Look at operating systems used by less intelligent users. They just see: [# ] 60% 2 minutes remaining I don't see how some extra verbosity hurts. It hurts because it scares users. My dad would take one look at the text, and give up. (And 15 years ago he was a VMS administrator, so it's not like he's computer illiterate.) My mum wouldn't even give the text a chance, she'd just see a wad of text with odd punctuation and run for the hills. Frankly if verbosity loses us some users, too bad. I'm sure we pick up more users because of the same. You will lose many more than you will gain, since there are many more computer illiterate users than geeks. To rant a bit, the thing that bugs me the most about MS Windows is how when it breaks randomly you can't fix it because it runs on smoke and mirrors and doesn't give helpful information on what went wrong. With UNIX/Linux you get details and you can fix it. Just to clarify, I've nothing against verbosity itself. /var/log, for instance, is great (although var is a historical name that really should be replaced by something more user friendly, but that's another story). The problem is verbosity when things don't go wrong. I'm all for a tell me what is going on feature for debugging. Even then, though, it would be nice if the verbose messages were consistently formatted, and used plain english instead of jargon. Error messages like E: Invalid operation foo are not helpful. I think Debian's package system is remarkably nice. Unfortunately, it's UI leaves a lot to be desired. The biggest problem is probably Which UI did you use? We have a few. apt-get is not an interface for the Debian newbie. dselect and aptitude are GUI tools if that's what you need. I used aptitude. It is not easy to use. It's fine for me, as I'm a geek. But if I told my mum to load aptitude and install X, she wouldn't have a clue how to do it. I just tried using deselect, to see if it is any better. The first option I'm faced with is: * 0. [A]ccessChoose the access method to use. I have no idea what that means. I tried using it (not logged in as root) and I got the following message: dselect: requested operation requires the superuser privilege Yet another example of an obscure error message. :-) -- Ian Hickson )\._.,--,'``.fL meow /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
Re: How to install X-Chat in five hours (or more)
On Tue, 5 Aug 2003 08:14:23 -0700 (PDT) Ian Hickson [EMAIL PROTECTED] wrote: Note that, if for some reason the user knew about the command apropos, even that wouldn't help him -- none of dselect, aptitude, and apt-get come up for apropos install or apropos setup. I do believe they are mentioned several times in the manual. Y'know, that thing collecting dust over yonder. It hurts because it scares users. And? You will lose many more than you will gain, since there are many more computer illiterate users than geeks. And? There are a slew of other OSs and Linux distributions as well. This is what always gets me in discussions that are based on the lowest common denominator in computer users; the presumption that everyone wants to cater to them. It has been my experience that packages that cater to the lowest common denominator are packages I don't care to use because I find them *hard to use* even though they purport to be easy to use. I have almost always been on the side of the scale where I preferred the harder package because in the long run, once I got over the nominal learning curve, it was easier to use. However there was always that drive to go for the lowest common denominator, the computer illiterate. It has ruined more programs that I care to list because they would add too much, dumb things down, make the program too large and hard-to-use in the quest to get people who have to ask Left or right click after the first time you tell them to right-click something. IE, people with no concept of default behaviors/actions. I have never, EVER understood why anyone would want to take a package which is beloved by the niche geek market and destroy it for the illiterate market. That is triply so for commercial packages. You're wrong in saying that we (in general) would gain more by making our package (program, OS, etc) more palatable to the neophyte. As I said above, there are a slew of OSs and distributions that cater to that segment. To move Debian into that realm would be to lose what it has and compete with established entities. 100% of this slice is better than 1% of *that* slice. Just to clarify, I've nothing against verbosity itself. /var/log, for instance, is great (although var is a historical name that really should be replaced by something more user friendly, but that's another story). The problem is verbosity when things don't go wrong. Erm, no, it should not be. While it is a historical name it is a name that should remain because every person who's ever worked on a Unix-like system during that history knows where /var is, why it is there and what is in it. It is up to those new people to catch up, not for us to ruin what works and works well in the vain attempt to catch more of a market which, in the end, doesn't really matter as this is not a commercial venture. I'm all for a tell me what is going on feature for debugging. Which is why you need verbosity when nothing is going wrong. Let's see a show of hands on this situation. Ya boot up a Windows box post after '95. Here's the sum of it letting you know something is going on: a rotating palette for the bar at the bottom. The palette stops rotating. So, uh, what's wrong? Oh, wait, it started rotating again. No, wait, it stopped again... for 30 seconds. No, there it goes, it's fine. Even then, though, it would be nice if the verbose messages were consistently formatted, and used plain english instead of jargon. Error messages like E: Invalid operation foo are not helpful. No, that's a bad idea. Take a look at IE's 404 message sometime. It's a dumbed down version which doesn't explain jack or shitte. Error messages are there for people who know what they need to do. People who don't know what they need to do will not have that knowledge suddenly imparted upon them by a plain english error message because, without the jargon to point you in the right direction, there would be absolutely no place to start. The first option I'm faced with is: * 0. [A]ccessChoose the access method to use. I have no idea what that means. I tried using it (not logged in as root) and I got the following message: Did you choose it to find out? dselect: requested operation requires the superuser privilege Yet another example of an obscure error message. :-) Uh, no, it isn't. Superuser, aka, root. But not always root. sudo can grant superuser access w/o root. Also any account with a uid of 0 has superuser access but that doesn't mean it is called root. I recall one job where we had root and jfroot. Both were uid 0 but they had different passwords. Don't ask me why we had to 0s w/different passwords. Didn't make sense to me then, doesn't make sense to me now. But the really ironic part about all this is that the above message is more of the plain english message you want. Root is jargon. Yank someone off the street and ask
Re: Should this be filed as grave? Gcc-2.95
On Tue, 5 Aug 2003 11:06:26 -0400 H. S. Teoh [EMAIL PROTECTED] wrote: Did you check your compile logs to see if it actually compiled with gcc-2.95 or with just gcc (==3.3) ? It happened to me several times that when building 2.4.21, it would use gcc-2.95 for the initial configuration and cleanup targets (since I specified CC=gcc-2.95), but revert to gcc for the actual build. That is most likely what happened. I didn't check logs. Didn't care. It didn't work, fuggit, I needed the machine stable and was mighty pissed that I couldn't just rip 3.3 off the damned system to force the issue without resorting to a serious downgrade to woody packages just to do it. I had to hand-edit kernel makefiles to stop it from using gcc by default and use gcc-2.95 instead. Or perhaps try setting CC=gcc-2.95 in your environment before running the build. Might have worked but forcing the issue is better IMHO. Without 3.3 present there is absolutely no chance of some process down the line sanitizing the environment and monkeying up the works. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. |-- Lenny Nero - Strange Days ---+- pgpmQil8My3gr.pgp Description: PGP signature
Re: Should this be filed as grave? Gcc-2.95
On Tue, 5 Aug 2003, Steve Lamb wrote: On Tue, 5 Aug 2003 11:06:26 -0400 H. S. Teoh [EMAIL PROTECTED] wrote: Did you check your compile logs to see if it actually compiled with gcc-2.95 or with just gcc (==3.3) ? It happened to me several times that when building 2.4.21, it would use gcc-2.95 for the initial configuration and cleanup targets (since I specified CC=gcc-2.95), but revert to gcc for the actual build. That is most likely what happened. I didn't check logs. Didn't care. It didn't work, fuggit, I needed the machine stable and was mighty pissed that I couldn't just rip 3.3 off the damned system to force the issue without resorting to a serious downgrade to woody packages just to do it. If you need the machine stable, then why are you running testing or unstable? gcc 3.3 isn't in stable/woody. Plus, this sounds like a kernel bug not honoring your CC cmdline var. Bitching to debian will not help you, and just annoys us. I had to hand-edit kernel makefiles to stop it from using gcc by default and use gcc-2.95 instead. Or perhaps try setting CC=gcc-2.95 in your environment before running the build. Might have worked but forcing the issue is better IMHO. Without 3.3 present there is absolutely no chance of some process down the line sanitizing the environment and monkeying up the works. Forcing the issue? What are you forcing? We can't fix this. Besides, what stability issues are you having? Hardware? If so, test it better before deploying, or if it has gone flaky after deployment, buy replacement hardware.
Re: Should this be filed as grave? Gcc-2.95
Adam, where does it say anywhere in my sig or headers that I want a CC? I read the list just fine, you can reply to the list and only the list just fine. I don't appreciate replying to what I think is a private message only to see a copy of it in the public area and have to resend the message for others to see. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. |-- Lenny Nero - Strange Days ---+- pgpwYxfZdMQ89.pgp Description: PGP signature
Re: Should this be filed as grave? Gcc-2.95
On Tue, Aug 05, 2003 at 08:43:36AM -0700, Steve Lamb wrote: On Tue, 5 Aug 2003 11:06:26 -0400 H. S. Teoh [EMAIL PROTECTED] wrote: Did you check your compile logs to see if it actually compiled with gcc-2.95 or with just gcc (==3.3) ? It happened to me several times that when building 2.4.21, it would use gcc-2.95 for the initial configuration and cleanup targets (since I specified CC=gcc-2.95), but revert to gcc for the actual build. That is most likely what happened. I didn't check logs. Didn't care. It didn't work, fuggit, I needed the machine stable and was mighty pissed that I couldn't just rip 3.3 off the damned system to force the issue without resorting to a serious downgrade to woody packages just to do it. Downgrading sounds like overkill in this situation. I only had to edit /usr/src/linux/Makefile to change HOSTCC to gcc-2.95 and export CC=gcc-2.95 in the environment, and it worked fine for me. This is on 2.4.21, of course, but I suspect the same holds for 2.4.20. I had to hand-edit kernel makefiles to stop it from using gcc by default and use gcc-2.95 instead. Or perhaps try setting CC=gcc-2.95 in your environment before running the build. Might have worked but forcing the issue is better IMHO. Without 3.3 present there is absolutely no chance of some process down the line sanitizing the environment and monkeying up the works. [snip] ln -s /usr/bin/gcc-2.95 /usr/bin/gcc build kernel ln -s /usr/bin/gcc-3.3 /usr/bin/gcc Problem fixed. T -- Nothing in the world is more distasteful to a man than to take the path that leads to himself. -- Herman Hesse
Re: How to install X-Chat in five hours (or more)
On Tue, Aug 05, 2003 at 08:14:23AM -0700, Ian Hickson wrote: On Wed, 6 Aug 2003, Hamish Moffatt wrote: On Tue, Aug 05, 2003 at 01:33:19AM -0700, Ian Hickson wrote: Part of the problem I had was that I had a vague understanding that there was something called apt, but that I didn't know what it was or how to do anything with it. The man page said to see apt-get's; apt-get's man page suggested the tool was a back-end but didn't really give any clues as to what front end to use. Not directly, but the SEE ALSO list does include dselect(8) which is what you really should have used. The term dselect means nothing to me. It isn't a usable name. That's another example of the problem I mentioned. Tools have names, and they don't really have to be generic. I think it's quite acceptable for the installation manual to tell you the names you need to know to get started, and it does: see sections 8.11 to 8.15 of http://www.debian.org/releases/stable/installmanual. mozilla isn't a particularly obvious name, when you get down to it; why not web-browser? (Because it's not the only web browser on the planet, of course. Likewise, it's important not to confuse people migrating between distributions by having the generic name setup do something completely different wherever you go because people were scared of using program names.) Would it not be possible for debian to have a command setup or install or something similarly named? I think that's a good example of why generic names may not be a good thing to encourage people to expect; /usr/bin/install has existed for a long time, can't feasibly be changed, and is definitely not what you're looking for. Note that, if for some reason the user knew about the command apropos, even that wouldn't help him -- none of dselect, aptitude, and apt-get come up for apropos install or apropos setup. They all show up for 'apropos package', along with a bunch of other stuff, but yes, that would probably be a useful enhancement to at least one of those man pages. To the end user (me), apt-get is arbitrarily verbose. Selecting previously deselected package libbla3.2? Get:1 ftp://apt sid/main libbla3.2 3.2.10-9 [827kB]? Look at operating systems used by less intelligent users. They just see: [# ] 60% 2 minutes remaining I don't see how some extra verbosity hurts. It hurts because it scares users. My dad would take one look at the text, and give up. (And 15 years ago he was a VMS administrator, so it's not like he's computer illiterate.) My mum wouldn't even give the text a chance, she'd just see a wad of text with odd punctuation and run for the hills. However, it's better for a command-line tool to be verbose up-front, because if it crashes or blows up or just goes slightly wrong, at least the last of which is frequent with buggy packages, we need the information for bug reports (at any rate until such time as we have logging in dpkg, but since that's bug #957 I wouldn't hold your breath ...). With a graphical front-end it's much easier to hide the verbosity and have a show me the installation log option in case of error. I've seen graphical front-ends for the Debian package management system that do exactly this. I wouldn't suggest that your mum use apt-get in any case, no more than I'd try to get my parents to do everything on the command line. I'd suggest a point-and-click package manager instead, if I were having them do routine package maintenance at all. Frankly if verbosity loses us some users, too bad. I'm sure we pick up more users because of the same. You will lose many more than you will gain, since there are many more computer illiterate users than geeks. That hasn't historically been a good argument on Debian mailing lists. :-) Fundamentally, we're trying to produce the best, most stable, most reliable, etc. system we can, not get as many users as we can. The two goals aren't always entirely synonymous. In fact, computer-literate users may often be better from our perspective because they often produce better bug reports! That's not to say that the goal is user-hostility, just that user-friendliness isn't always the all-defeating trump card when discussing relatively low-level tools like dpkg and apt-get. To rant a bit, the thing that bugs me the most about MS Windows is how when it breaks randomly you can't fix it because it runs on smoke and mirrors and doesn't give helpful information on what went wrong. With UNIX/Linux you get details and you can fix it. Just to clarify, I've nothing against verbosity itself. /var/log, for instance, is great (although var is a historical name that really should be replaced by something more user friendly, but that's another story). You can't get there from here, I think. Unix admins coming to Debian will scream blue murder if it starts being /My Variable Data/Logs, and that group is important to us. The problem is
Re: Should this be filed as grave? Gcc-2.95
On Tue, 5 Aug 2003, Steve Lamb wrote: Adam, where does it say anywhere in my sig or headers that I want a CC? I read the list just fine, you can reply to the list and only the list just fine. I don't appreciate replying to what I think is a private message only to see a copy of it in the public area and have to resend the message for others to see. lart, killfile.
Please NMU dovecot
Could someone please NMU dovecot adding the patch in bug #203892? Either gcc 3.3.1 sucks or I'm having another hardware problem, ... Making all in lib make[4]: Entering directory `/home/jaldhar/src/dovecot/dovecot-0.99.10/src/lib' i386-linux-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -c alarm-hup.c alarm-hup.c: In function `alarm_hup_init': alarm-hup.c:72: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [alarm-hup.o] Error 1 make[4]: Leaving directory `/home/jaldhar/src/dovecot/dovecot-0.99.10/src/lib' make[3]: *** [all-recursive] Error 1 ... -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/
Re: How to install X-Chat in five hours (or more)
Em Tue, 5 Aug 2003 10:49:17 +0200, Frederik Rousseau [EMAIL PROTECTED] escreveu: Anyway, does this mean we need something like a GNU/Linux Debian and a GNU/Linux Debian For Dummies showing only icons? Yes, I think so... Debian-Desktop should be that, probably. I would like to see a package manager like the one suggested by Ian Hickson you don't need to mess with all of Debian, you just need a better UI, really. The short description, together with a good selection of 'what is for the users, what is for the developers and what is for system admins' could be used to achieve that. []s! -- [EMAIL PROTECTED]: Gustavo Noronha http://people.debian.org/~kov Debian: http://www.debian.org * http://www.debian-br.org Dúvidas sobre o Debian? Visite o Rau-Tu: http://rautu.cipsga.org.br
Re: How to install X-Chat in five hours (or more)
On Tue, 5 Aug 2003, Steve Lamb wrote: Note that, if for some reason the user knew about the command apropos, even that wouldn't help him -- none of dselect, aptitude, and apt-get come up for apropos install or apropos setup. I do believe they are mentioned several times in the manual. Y'know, that thing collecting dust over yonder. What manual? I receieved the machine with Debian preinstalled and no offline documentation except a post it note with the root username and password. On other systems (Mac OS X, Windows XP, etc) I am clearly shown where to look for more information (on Windows, in fact, the OS goes to the other extreme and tries to ram help down your throat), but on Debian, there was no clear path to the documentation. Typing help at the command line, which to most new users would seem like a sensible starting point, gives very terse information about bash and shell commands. (The bit at the top of this does mention 'man', but it scrolls off the top of my screen so it's not that helpful to a new user who doesn't know about Shift + Page Up.) The only manual I was aware of was apropos and man. But as I said in another message, neither apropos install nor apropos setup lead the user to look at any of apt-get, dselect, or aptitude. It hurts because it scares users. And? From a usability point of view, scaring users is a bad thing. You will lose many more than you will gain, since there are many more computer illiterate users than geeks. And? There are a slew of other OSs and Linux distributions as well. And I'm a geek, one who has been using GNU-based distributions on multiple machines on a daily basis for at least 3 years, and Sun for 6 years before that, and I _still_ have difficulty. This should be ringing usability alarm bells. This is what always gets me in discussions that are based on the lowest common denominator in computer users; the presumption that everyone wants to cater to them. Being usable does not mean catering for the lowest common denominator; I fully agree that other distributions are more adequately positioned to target computer illiterate users. although var is a historical name that really should be replaced by something more user friendly, but that's another story Erm, no, it should not be. While it is a historical name it is a name that should remain because every person who's ever worked on a Unix-like system during that history knows where /var is, why it is there and what is in it. It is up to those new people to catch up, not for us to ruin what works and works well in the vain attempt to catch more of a market which, in the end, doesn't really matter as this is not a commercial venture. Without meaning offense, that is a very selfish attitude. The number of future debian users is *significantly* larger than the number of existing users, unless something drastic happens to either humanity or debian itself. Why should everyone who will use debian in future be forced to learn archaic commands, paths, and deal with other historical holdbacks, instead of the few who already use it being taught easier conventions? I'm all for a tell me what is going on feature for debugging. Which is why you need verbosity when nothing is going wrong. Let's see a show of hands on this situation. Ya boot up a Windows box post after '95. Here's the sum of it letting you know something is going on: a rotating palette for the bar at the bottom. The palette stops rotating. So, uh, what's wrong? Oh, wait, it started rotating again. No, wait, it stopped again... for 30 seconds. No, there it goes, it's fine. Right. That's poor UI. However, it's not _that_ much better on Debian: Incomprehensible status message #1. Incomprehensible status message #2. Incomprehensible status message #3. (long pause) Incomprehensible status message #4. Incomprehensible status message #5. Incomprehensible status message #6. By Incomprehensible status message I mean things like: bootlogd. Activating swap. fsck 1.35-WIP (01-Aug-2003) Running 0dns-down to make sure resolv.conf is ok...done. Please contribute if you find this software useful. DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5 Starting Xprint servers: Xprt. ...all of which are taken directly from my boot log. Why can't we instead have nice friendly messages? e.g.: Startup logging has begun. Log will be stored in '/var/log/boot'. ...instead of bootlogd. Even then, though, it would be nice if the verbose messages were consistently formatted, and used plain english instead of jargon. Error messages like E: Invalid operation foo are not helpful. No, that's a bad idea. Take a look at IE's 404 message sometime. It's a dumbed down version which doesn't explain jack or shitte. Again, IE's 404 message is terrible UI. It is much, much too long and is not very helpful. It is, however, a little better than: 404 Error Resource
Re: Fw: Re: Ruby 1.8 transition plan; debian-ruby
At Mon, 4 Aug 2003 18:02:52 +0300, Dmitry Borodaenko wrote: As rightfully pointed out by Fumitoshi UKAI, this discussion belongs to the wider audience of debian-devel, especially since Ruby 1.8.0 was released today. NB: some points raised here can be of interest not only to Ruby developers, but also to developers from other scripting languages. Generic questions are: Is there or shouldn't there be policy or guidelines on major version transition for scripting languages? Currently, there are no such policy or guidelines. There are policies for each specific languages such as perl, python, java, emacsen, however, it seems that they have somewhat different approaches. I think it is impossible or very difficult to make general policy. Anyway, it would be very helpful to make a guideline that suggests the answers for the following questions. What considerations should be taken into account when deciding whether to keep several different major language versions co-installable? Where should libraries written in a scripting language go? (That one is my pet question: FHS seems to point to /usr/share/, while in Debian, most languages use /usr/lib/, and I have arguments against both :) Ruby-specific question is, of course, how do we deal with Ruby 1.8 transition? Since ruby 1.8.0 was released recently, ruby developers will go to ruby 1.8.x, so that we, ruby maintenance team (akira, tagoh, ukai), are discussing about how to deal with Ruby 1.8 transition and trying to make debian ruby policy soon. For now, ruby package provides /usr/bin/ruby of ruby 1.6.x, and ruby1.8 package provides /usr/bin/ruby1.8 of ruby 1.8.x. Someone want to use /usr/bin/ruby of ruby 1.8.x, so we're considering to use alternatives for /usr/bin/ruby to choice either ruby1.6, ruby1.8 (or any other version of ruby in future). I wonder we should rename ruby package to ruby1.6 package and ruby package for meta package for default version of ruby now. It requires package renaming which is somehow troublesome, so I suspect it's worth to do it. Anyway, I don't think we'll change ruby1.8 to ruby in the future, and ruby becomes meta package for default version of ruby after ruby 1.6.x is removed from unstable. The default include paths of each ruby version are as follows: % ruby -e 'puts $:' /usr/local/lib/site_ruby/1.6 /usr/local/lib/site_ruby/1.6/i386-linux /usr/local/lib/site_ruby /usr/lib/ruby/1.6 /usr/lib/ruby/1.6/i386-linux
Re: How to install X-Chat in five hours (or more)
I agree with every word There are lot's of packages to do Debian more user friendly, they are available at install time and after by running tasksel. Maybe the problem was the way that Debian was pre-installed I think they only installed base. This isn't suitable for a user. Maybe if you installed Debian by your own you could feeled more confortable with dselect and tasksel (called from debian installer) among other words/commands. You will lose many more than you will gain, since there are many more computer illiterate users than geeks. And? There are a slew of other OSs and Linux distributions as well. I think many people choose Debian because it's a geek distro, without those RH/Mandrake annoyances that are good for users and bad for us. After all .. all this problem happened not just because libgtk1.2 .. but to install a browser, right ? ... just apt-get install mozilla . =) C´ya and sorry for poor english .. just my 2 c. []'s On Tue, 2003-08-05 at 12:41, Steve Lamb wrote: You will lose many more than you will gain, since there are many more computer illiterate users than geeks. And? There are a slew of other OSs and Linux distributions as well. This is what always gets me in discussions that are based on the lowest common denominator in computer users; the presumption that everyone wants to cater to them. It has been my experience that packages that cater to the lowest common denominator are packages I don't care to use because I find them *hard to use* even though they purport to be easy to use. I have almost always been on the side of the scale where I preferred the harder package because in the long run, once I got over the nominal learning curve, it was easier to use. However there was always that drive to go for the lowest common denominator, the computer illiterate. It has ruined more programs that I care to list because they would add too much, dumb things down, make the program too large and hard-to-use in the quest to get people who have to ask Left or right click after the first time you tell them to right-click something. IE, people with no concept of default behaviors/actions. I have never, EVER understood why anyone would want to take a package which is beloved by the niche geek market and destroy it for the illiterate market. That is triply so for commercial packages. You're wrong in saying that we (in general) would gain more by making our package (program, OS, etc) more palatable to the neophyte. As I said above, there are a slew of OSs and distributions that cater to that segment. To move Debian into that realm would be to lose what it has and compete with established entities. 100% of this slice is better than 1% of *that* slice. Just to clarify, I've nothing against verbosity itself. /var/log, for instance, is great (although var is a historical name that really should be replaced by something more user friendly, but that's another story). The problem is verbosity when things don't go wrong. Erm, no, it should not be. While it is a historical name it is a name that should remain because every person who's ever worked on a Unix-like system during that history knows where /var is, why it is there and what is in it. It is up to those new people to catch up, not for us to ruin what works and works well in the vain attempt to catch more of a market which, in the end, doesn't really matter as this is not a commercial venture. I'm all for a tell me what is going on feature for debugging. Which is why you need verbosity when nothing is going wrong. Let's see a show of hands on this situation. Ya boot up a Windows box post after '95. Here's the sum of it letting you know something is going on: a rotating palette for the bar at the bottom. The palette stops rotating. So, uh, what's wrong? Oh, wait, it started rotating again. No, wait, it stopped again... for 30 seconds. No, there it goes, it's fine. Even then, though, it would be nice if the verbose messages were consistently formatted, and used plain english instead of jargon. Error messages like E: Invalid operation foo are not helpful. No, that's a bad idea. Take a look at IE's 404 message sometime. It's a dumbed down version which doesn't explain jack or shitte. Error messages are there for people who know what they need to do. People who don't know what they need to do will not have that knowledge suddenly imparted upon them by a plain english error message because, without the jargon to point you in the right direction, there would be absolutely no place to start. The first option I'm faced with is: * 0. [A]ccessChoose the access method to use. I have no idea what that means. I tried using it (not logged in as root) and I got the following message: Did you choose it to find out? dselect: requested operation
Re: How to install X-Chat in five hours (or more)
On Tue, 5 Aug 2003, Colin Watson wrote: The term dselect means nothing to me. It isn't a usable name. That's another example of the problem I mentioned. Tools have names, and they don't really have to be generic. I think it's quite acceptable for the installation manual to tell you the names you need to know to get started, and it does: see sections 8.11 to 8.15 of http://www.debian.org/releases/stable/installmanual. Ok, that's fair enough. Note that, if for some reason the user knew about the command apropos, even that wouldn't help him -- none of dselect, aptitude, and apt-get come up for apropos install or apropos setup. They all show up for 'apropos package', along with a bunch of other stuff, but yes, that would probably be a useful enhancement to at least one of those man pages. I'm glad you agree. :-) However, it's better for a command-line tool to be verbose up-front, because if it crashes or blows up or just goes slightly wrong, at least the last of which is frequent with buggy packages, we need the information for bug reports [...]. That's probably true. It would still be nice if the verbose messages were more consistent, though. For example, 'apt-get' error messages start with 'E:' instead of the more standard 'apt-get:'. Similarly, when you do an apt-get update, you get some messages of the form: Hit ftp://apt sid/mail Packages ...some of the form: Get:1 ftp://apt ./ Packages ...and some of the form: Reading Package Lists... Done ...which is odd: why three different kinds of messages? What does Hit mean, as opposed to Ign or Get:1? And so on. This isn't only a problem with apt-get, of course. Error and status messages throughout the industry and in particular throught the free software world are often obscure, obtuse, and unclear. Indeed, Mozilla has its share of such problems! :-) With a graphical front-end it's much easier to hide the verbosity and have a show me the installation log option in case of error. I've seen graphical front-ends for the Debian package management system that do exactly this. That's cool. (aptitude doesn't, as far as I can tell.) :-) Fundamentally, we're trying to produce the best, most stable, most reliable, etc. system we can, not get as many users as we can. That's fair enough! :-) That's not to say that the goal is user-hostility, just that user-friendliness isn't always the all-defeating trump card when discussing relatively low-level tools like dpkg and apt-get. I think that user-friendliness, even at such a low level, should still be important -- just because the user is an expert doesn't mean he wants to have to decode messages. although var is a historical name that really should be replaced by something more user friendly, but that's another story. You can't get there from here, I think. Unix admins coming to Debian will scream blue murder if it starts being /My Variable Data/Logs, and that group is important to us. Note that there is at least one project which is looking at doing exactly that while retaining backwards compatability (GoboLinux). It may be worth, on the long term, looking at how it may be possible to migrate from obscure paths like /opt, /bin, /sbin, /usr/bin, etc, to more sensible names, in that way. And I would scream if you called it /_My_ Variable Data/ too... :-P -- Ian Hickson )\._.,--,'``.fL meow /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
Should MUA only Recommend mail-transfer-agent?
Hello I've found your bugreport: http://bugs.debian.org/202869 I see no issue to not depending mutt on mail-transfer-agent. Mutt as is, is a software for reading, writing and sending emails. And to provide a full functionality it needs a kind of transfer-agent. I am not convinced to only Recommend on mail-transfer-agent. I rather tend to closing this wishitem or tag it as wontfix. OTOH this case concerns not only mutt but also other MUA's. Feel free to discuss it on debian-devel mailing list or propose a changes to Debian Packaging Policy. I will leave this wishitem open until an agreement is reached. Regards Artur -- Artur R. Czechowski [EMAIL PROTECTED]
Re: Should MUA only Recommend mail-transfer-agent?
Artur R. Czechowski dijo [Tue, Aug 05, 2003 at 07:21:00PM +0200]: Hello I've found your bugreport: http://bugs.debian.org/202869 I see no issue to not depending mutt on mail-transfer-agent. Mutt as is, is a software for reading, writing and sending emails. And to provide a full functionality it needs a kind of transfer-agent. I am not convinced to only Recommend on mail-transfer-agent. I rather tend to closing this wishitem or tag it as wontfix. OTOH this case concerns not only mutt but also other MUA's. Feel free to discuss it on debian-devel mailing list or propose a changes to Debian Packaging Policy. I will leave this wishitem open until an agreement is reached. I agree with Andreas. On one hand, I have used mutt to read a mbox file I have lying around while flying - it does not require a MTA to work. On the other hand, mutt can work in a more mundane environment with a remote IMAP server. Yes, a MTA is required to send mail, and is thus strongly recommended - but not having one does not render the package unusable, so it is not really depending on it. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF pgpIIvqr3YCcD.pgp Description: PGP signature
Re: How to install X-Chat in five hours (or more)
On Wed, Aug 06, 2003 at 12:33:18AM +1000, Hamish Moffatt [EMAIL PROTECTED] was heard to say: I think Debian's package system is remarkably nice. Unfortunately, it's UI leaves a lot to be desired. The biggest problem is probably Which UI did you use? We have a few. apt-get is not an interface for the Debian newbie. dselect and aptitude are GUI tools if that's what you need. aptitude is neither a GUI tool nor a tool for the Debian newbie. The GUI tool I hear mentioned most frequently is synaptic; maybe the writer would have better luck with that? Daniel -- / Daniel Burrows [EMAIL PROTECTED] ---\ | Will the last person to leave the Universe please | | turn off the lights and close the door?| \-Evil Overlord, Inc: planning your future today. http://www.eviloverlord.com-/
Re: Should MUA only Recommend mail-transfer-agent?
On Tue, Aug 05, 2003 at 07:21:00PM +0200, Artur R. Czechowski wrote: OTOH this case concerns not only mutt but also other MUA's. Feel free to discuss it on debian-devel mailing list or propose a changes to Debian Packaging Policy. I will leave this wishitem open until an agreement is reached. There are enough SMTP/POP3 MUAs which do not need any MTA infrastructure on the local host, whatsoever. Mutt can fetch by pop-3, but I think it has no smtp support build in, or? Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: How to install X-Chat in five hours (or more)
On Tuesday 05 August 2003 18:55, Ian Hickson wrote: Without meaning offense, that is a very selfish attitude. The number of future debian users is *significantly* larger than the number of existing users, unless something drastic happens to either humanity or debian itself. Why should everyone who will use debian in future be forced to learn archaic commands, paths, and deal with other historical holdbacks, instead of the few who already use it being taught easier conventions? More comfort requires more system resources (except for a few really clever hacks). Beginners are most likely willing to accept that a few CPU cycles are used for making their computing time easier - you'll see that they like icons (animated ones even), tooltips, first-time wizards and so on. Now, the unix file system layout was never designed to be end-user friendly in the beginning (the short ASCII-style file and directory names take care of that), yet development didn't stop. What Linux and other OSes lack in the kernel space, has started to exist in the user space. With KDE, you've got a Home folder already and a Trash folder. With GNOME, you've got a Preferences container. You can easily write an implementation which fits your needs, e.g. a KIO slave for directory name translation, or a Hurd translator for system-level bindings. Of course, in order to not be flamed from time to time, you should come up with a nice concept first. You don't have to write the code yourself, but you do have to invent the user-friendly layer and make it public. Josef -- Play for fun, win for freedom. Hurd^H^H^H^HLinux-Info-Tag Dresden 2003: http://www.linux-dresden.de
Re: Should MUA only Recommend mail-transfer-agent?
On Tue, Aug 05, 2003 at 08:00:03PM +0200, Bernd Eckenfels wrote: There are enough SMTP/POP3 MUAs which do not need any MTA infrastructure on the local host, whatsoever. But there are some important packages which depends on MTA directly, like: at, cron, debconf, logrotate, mailx. I can imagine a workstation without those packages but it is, IMO, mutilated box. Mutt can fetch by pop-3, but I think it has no smtp support build in, or? Mutt has no support for SMTP. BTW, there is no need for exim4-daemon-heavy. There are other lightweight MTA's. Another solution is to prepare a dummy-mta package, which only provides mail-transfer-agent and required by policy /usr/sbin/sendmail and /usr/bin/newaliases binaries to do nothing[1]. Advanced Debian users has another opportunity to solve this problem: equivs. I would like to know Md's opinion, but for me there are no reasons to relax dependencies for mutt (and other MUA). I would not like to do it without policy requirements because it concerns also other MUA's. I, personally, like the dummy-mta solution, however nullmailer also looks good. Cheers Artur [1] maybe logging to syslog will be good. -- http://hell.pl/arturcz/ pgpdTSwUxStgb.pgp Description: PGP signature
Re: How to install X-Chat in five hours (or more)
Hi, On Tue, Aug 05, 2003 at 09:55:59AM -0700, Ian Hickson wrote: [SNIP] Why can't we instead have nice friendly messages? e.g.: Startup logging has begun. Log will be stored in '/var/log/boot'. ...instead of bootlogd. [SNIP] Error messages are there for people who know what they need to do. So if I do something wrong (like get the command line arguments to 'apt-get' wrong, as I did), then I don't deserve to be helped by the program? What would be wrong with a helpful message, such as: apt-get: the first argument should be one of 'install', 'remove', 'update', or another operation ...instead of just E: Invalid operation foo? [SNIP] How about a message such as: dselect: to select an installation source, superuser privileges are required (try logging in as root) It's still accurate, but now it's helpful as well, and uses a more friendly voice. (This also changes access method to installation source, which makes more sense to me.) You know, I think these are actually good suggestions. I think there's a lot to be gained *not* by dumbing down, *not* by losing any information that might be useful to a geek or to a new user as (s)he's learning, but by phrasing texts so that they appeal more to generally intelligent human beings, rather than to people that just happen to have some specific knowledge. Apple has a great way of doing that. They don't dumb down, they don't belittle you, they assume an intelligent being who can grasp reasonably complex English sentences, but who has less knowledge of computer idiom. I think this is an area in which software can be improved without scaring the geeks with offensive 'my first Sony' UIs, teletubby landscapes, informationless error messages, and stupid attempts to fix things behind the users back (simply displaying expired pages from a cache for instance). Indeed, Microsoft gets it all wrong, from a UI standpoint. But instead of assuming that we are pushed in that scary direction when someone complains about our UI, we may also realise that there are things that can actually be improved, without harming Unix's strong points, UI-wise. I fully agree with the poster that increasing the number of intelligent and intelligible English sentences that we output is one of those things that can be done without harming the hacker in any way. Of course, like any enhancement, it needs a volunteer who can scratch his or her itch by doing this work. This may actually be one of the bigger problems. Most developers who can do the work have gotten used to the idiom and badly worded error messages. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgprXSw5bIZGU.pgp Description: PGP signature
Bug#204263: ITP: gngeo -- NeoGeo emulator
Package: wnpp Version: reported 2003-08-05 Severity: wishlist * Package name: gngeo Version : 0.5.9a Upstream Author : M. Pepone [EMAIL PROTECTED] * URL : http://m.peponas.free.fr/gngeo/ * License : GPL Description : NeoGeo emulator gngeo is an emulator for NeoGeo games, it runs with SDL library. Gamepad can be use to play the games. You MUST have a neo-geo bios rom stored on your system (in /usr/share/gngeo) -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux evira 2.6.0-test1 #2 Mon Jul 14 18:56:06 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: How to install X-Chat in five hours (or more)
Hi,
On Tue, Aug 05, 2003 at 10:19:53AM -0700, Ian Hickson wrote:
And I would scream if you called it /_My_ Variable Data/ too... :-P
I would even scream at
/Variable Data/
simply because it encourages slow and RSI-inducing click and drag
behaviour, because such path names are impossible to type in (and this
one even requires escaping the space to distinguish between the argument
separator).
Don't underestimate the typing convenience of TLAs! They may not be the
most descriptive, but at least they're blindingly fast to work with when
you get used to it.
In short, such path names are definitely no improvement from a UI
standpoint, even though it may seem that way from a casual observer.
Even shorter: UIs are rarely obvious. And there must be a reason why
geeks like working with Unix.
One thing for me is that the command line allows me to work almost as
quickly as I think. I really hate it when the UI drags me down ('open
folder, open subfolder, click on file, type Ctrl-C, open other folder,
type Ctrl-V', it's just horrible). The computer should wait for me, not
the other way around!
Cheers,
Emile.
--
E-Advies - Emile van Bergen [EMAIL PROTECTED]
tel. +31 (0)70 3906153 http://www.e-advies.nl
pgpX3JoSsrW5E.pgp
Description: PGP signature
Re: Should MUA only Recommend mail-transfer-agent?
Artur R. Czechowski wrote: On Tue, Aug 05, 2003 at 08:00:03PM +0200, Bernd Eckenfels wrote: There are enough SMTP/POP3 MUAs which do not need any MTA infrastructure on the local host, whatsoever. But there are some important packages which depends on MTA directly, like: at, cron, debconf, logrotate, mailx. I can imagine a workstation without those packages but it is, IMO, mutilated box. ... it's strange for MUA to require MTA, lot of them support IMAP (for viewing email) and SMTP (for sending email), both of which can be on remote servers. So why MTA on local box? Yes, there are other reasons to have MTA on box (non related to MUA) but that's irrelevant. erik
Re: Should MUA only Recommend mail-transfer-agent?
On Tue, Aug 05, 2003 at 08:00:03PM +0200, Bernd Eckenfels wrote: There are enough SMTP/POP3 MUAs which do not need any MTA infrastructure on the local host, whatsoever. Mutt can fetch by pop-3, but I think it has no smtp support build in, or? I just (actually few hours ago) find patch which adds smtp support to mutt. http://www.deez.info/sengelha/projects/mutt/libesmtp/patch-1.5.3.sde.libesmtp.3 It depends on libesmtp. I personally always liked MUAs with smtp and my main objection to mutt was lack of it. Now, I have it for my (loved) MUA. :-) -- Milan
Re: How to install X-Chat in five hours (or more)
Debian should not change its attitude or methods to meet the end user's needs. Think of Debian as a the painter's palette. All of the tools you need are available to you. It installs a base system and you customize from there. Would I recommend Debian for John Doe user? As a base raw install (even with X), I would not. However, Debian is a wonderful tool. I can pick and choose what packages I wish to install and how I wish those packages to be configured. If I so desire, I can setup a Debian to meet the needs of an end user. An end user has different needs such as a router, an OpenMosix cluster, a desktop machine, and the list can go on and on. Debian is a generalist. Debian sub-projects and Debian based distros takes the Debian tools to meet the needs of the end user. Without the painter's palette, the pictures for the end user cannot be created. By the way, I like the verbose messages. Also, there are mechanisms to submit bug reports to fix code and documentation bugs. That's my two bits. carlosP -- QOTD: Recursion n.: See Recursion. -- Random Shack Data Processing Dictionary Carlos E. Pruitt, Jr. National Center for Computational Hydroscience and Engineering 102 Carrier University, MS 38677 USA phone: 662-915-7786 On Tue, 5 Aug 2003, Colin Watson wrote: The term dselect means nothing to me. It isn't a usable name. That's another example of the problem I mentioned. Tools have names, and they don't really have to be generic. I think it's quite acceptable for the installation manual to tell you the names you need to know to get started, and it does: see sections 8.11 to 8.15 of http://www.debian.org/releases/stable/installmanual. Ok, that's fair enough. Note that, if for some reason the user knew about the command apropos, even that wouldn't help him -- none of dselect, aptitude, and apt-get come up for apropos install or apropos setup. They all show up for 'apropos package', along with a bunch of other stuff, but yes, that would probably be a useful enhancement to at least one of those man pages. I'm glad you agree. However, it's better for a command-line tool to be verbose up-front, because if it crashes or blows up or just goes slightly wrong, at least the last of which is frequent with buggy packages, we need the information for bug reports [...]. That's probably true. It would still be nice if the verbose messages were more consistent, though. For example, 'apt-get' error messages start with 'E:' instead of the more standard 'apt-get:'. Similarly, when you do an apt-get update, you get some messages of the form: Hit ftp://apt sid/mail Packages ...some of the form: Get:1 ftp://apt ./ Packages ...and some of the form: Reading Package Lists... Done ...which is odd: why three different kinds of messages? What does Hit mean, as opposed to Ign or Get:1? And so on. This isn't only a problem with apt-get, of course. Error and status messages throughout the industry and in particular throught the free software world are often obscure, obtuse, and unclear. Indeed, Mozilla has its share of such problems! With a graphical front-end it's much easier to hide the verbosity and have a show me the installation log option in case of error. I've seen graphical front-ends for the Debian package management system that do exactly this. That's cool. (aptitude doesn't, as far as I can tell.) Fundamentally, we're trying to produce the best, most stable, most reliable, etc. system we can, not get as many users as we can. That's fair enough! That's not to say that the goal is user-hostility, just that user-friendliness isn't always the all-defeating trump card when discussing relatively low-level tools like dpkg and apt-get. I think that user-friendliness, even at such a low level, should still be important -- just because the user is an expert doesn't mean he wants to have to decode messages. although var is a historical name that really should be replaced by something more user friendly, but that's another story. You can't get there from here, I think. Unix admins coming to Debian will scream blue murder if it starts being /My Variable Data/Logs, and that group is important to us. Note that there is at least one project which is looking at doing exactly that while retaining backwards compatability (GoboLinux). It may be worth, on the long term, looking at how it may be possible to migrate from obscure paths like /opt, /bin, /sbin, /usr/bin, etc, to more sensible names, in that way. And I would scream if you called it /_My_ Variable Data/ too... -- Ian Hickson )\._.,--,'``. fL meow /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ -- QOTD: Recursion n.: See Recursion. -- Random Shack Data Processing Dictionary Carlos E. Pruitt, Jr. National Center for Computational Hydroscience and Engineering 102 Carrier University, MS 38677 USA phone: 662-915-7786 -- QOTD: Recursion n.: See
python 2.2 - python 2.3 transition
Last weekend, python 2.3 was released. For an overview see http://python.org/2.3/highlights.html With the next python2.3 upload, python2.3 becomes the default python version. Some packages become uninstallable until they are converted to the new version. In this time you should not update python or remove all packages depending on python2.2 as the default. The upgrade itself should not make major problems. Many packages are already built for python2.3, those which do not build/work with python2.3 (I'm not aware of any) can still explicitely use python2.2. You can find packages with python2.3 as the default python version at http://ftp-master.debian.org/~doko/python/. I'm going to upload these on Friday. As there are new binary packages involved, these won't hit the archives before Saturday. Some packages as python-bz2 or python-optik become obsolete, because these modules are included in the python2.3 standard library.
Re: How to install X-Chat in five hours (or more)
* Emile van Bergen | Hi, | | On Tue, Aug 05, 2003 at 10:19:53AM -0700, Ian Hickson wrote: | | And I would scream if you called it /_My_ Variable Data/ too... :-P | | I would even scream at | | /Variable Data/ | | simply because it encourages slow and RSI-inducing click and drag | behaviour, because such path names are impossible to type in (and this | one even requires escaping the space to distinguish between the argument | separator). Tab completion or using /Va* is about as fast as /var. | In short, such path names are definitely no improvement from a UI | standpoint, even though it may seem that way from a casual observer. | Even shorter: UIs are rarely obvious. And there must be a reason why | geeks like working with Unix. UIs have two costs: an initial learning cost and a «running cost» (which also includes the retaining the learnt level) which is per operation (a little bit simplified, but you get the idea). If you are going to use a system a lot and over a long period of time, the initial cost matters a lot less than if you are only going to use the system occasionally and for short periods of time. Also, catering for the different conditions of users is important; I'd hate to have to use a command line interface with obscure unix-like commands for operating an ATM, since I fairly seldom use those and therefore the running cost is less important than the initial cost. Geeks use systems a lot and for long periods of time, so using more or less obscure interfaces is good, not bad for us. :) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: How to install X-Chat in five hours (or more)
Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 5 Aug 2003, Steve Lamb wrote: Note that, if for some reason the user knew about the command apropos, even that wouldn't help him -- none of dselect, aptitude, and apt-get come up for apropos install or apropos setup. I do believe they are mentioned several times in the manual. Y'know, that thing collecting dust over yonder. What manual? I receieved the machine with Debian preinstalled and no offline documentation except a post it note with the root username and password. On other systems (Mac OS X, Windows XP, etc) I am clearly shown where to look for more information (on Windows, in fact, the OS goes to the other extreme and tries to ram help down your throat), but on Debian, there was no clear path to the documentation. [...] * In my experience the windows-help system is frequently next to useless, it looks pretty, but is not helpful. * $total_computer_newbie is completely at loss with windows, too (just tried it two months ago). If somebody set up your machine totally b0rked (mixed sid/testing) without installing the docs it is not Debian's fault. If you want to start with Debian, Suse, RedHat, or whatever you have always have to find a decent manual or at least a person who sets up the system and helps you. Yes, you probably can install RedHat by just pressing enter but you'll get stuck on the third day without manual and learning to help yourself, Debian will just bite you earlier. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: Should MUA only Recommend mail-transfer-agent?
Bernd Eckenfels [EMAIL PROTECTED] wrote: On Tue, Aug 05, 2003 at 07:21:00PM +0200, Artur R. Czechowski wrote: OTOH this case concerns not only mutt but also other MUA's. Feel free to discuss it on debian-devel mailing list or propose a changes to Debian Packaging Policy. I will leave this wishitem open until an agreement is reached. There are enough SMTP/POP3 MUAs which do not need any MTA infrastructure on the local host, whatsoever. Yes, probably almost all the others with whitespread userbase, for example pine, mozilla, (afaik) sylpheed, kmail do support SMTP.[1] Mutt can fetch by pop-3, but I think it has no smtp support build in, or? Yes, but iirc there is unofficial patch for linking mutt against libesmtp on the web. Imho mutt's dependency on mail-transfer-agent is strong enough for a Depends. - There are usage szenarios which do not require an mail-transfer-agent (reading mbox-archives of mailing-lists) but mutt without MTA is seriously crippled. cu andreas [1] I won't list Gnus but would be really surprised if it _needed_ /usr/sbin/sendmail ;-) -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: How to install X-Chat in five hours (or more)
Oh, look, someone else who CCs when it is obvious the person they're responding to is participating right here. On Tue, 5 Aug 2003 09:55:59 -0700 (PDT) Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 5 Aug 2003, Steve Lamb wrote: What manual? I rest my case. I receieved the machine with Debian preinstalled and no offline documentation except a post it note with the root username and password. And this is the problem of Debian... how? I would ask why you weren't given better help from the person who installed it or why you didn't ask them for help. The facilities are there. On other systems (Mac OS X, Windows XP, etc) I am clearly shown where to look for more information (on Windows, in fact, the OS goes to the other extreme and tries to ram help down your throat), but on Debian, there was no clear path to the documentation. And on my install the same is true. KDE menu, Help. It hurts because it scares users. And? From a usability point of view, scaring users is a bad thing. Ever hear the saying Unix is user friendly, it's just picky about its friends. You missed my entire point. Debian isn't scaring off users. It is scaring off *neophyte* users. However, that segment of the population is covered by *other distributions*. This is a *good thing* as Debian often attracts users with some experience who want exactly what it has to offer. And I'm a geek, one who has been using GNU-based distributions on multiple machines on a daily basis for at least 3 years, and Sun for 6 years before that, and I _still_ have difficulty. This should be ringing usability alarm bells. No, it shouldn't. I should be ringing alarms about the veracity of your claims and your capabilities. Being usable does not mean catering for the lowest common denominator; I fully agree that other distributions are more adequately positioned to target computer illiterate users. Debian is quite usable. *NO* computer system, however, is going to be completely intuative to someone who is handed it with nothing more than Here, here's the username and password. g'luck! Quick, tell me, how do you get more software for Windows? Help doesn't point you to TUCOWS or the like. Without meaning offense, that is a very selfish attitude. No, it is selfish for people to come into a culture and flat out state, No, I don't want to learn so things should change to cater to ME! The number of future debian users is *significantly* larger than the number of existing users, unless something drastic happens to either humanity or debian itself. Why should everyone who will use debian in future be forced to learn archaic commands, paths, and deal with other historical holdbacks, instead of the few who already use it being taught easier conventions? Because they're not that hard to learn and the easier conventions are not easier in any quantifiable sense of the word. Furthermore any system you, or anyone else, would propose would cause no end of upheaval to the software that ran on it. It would take years to make any meaningful shift and in the end guess what would happen. New users would still have to learn where everything goes. Right. That's poor UI. However, it's not _that_ much better on Debian: Quite the contrary. By Incomprehensible status message I mean things like: bootlogd. Activating swap. fsck 1.35-WIP (01-Aug-2003) Running 0dns-down to make sure resolv.conf is ok...done. Please contribute if you find this software useful. DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5 Starting Xprint servers: Xprt. If the pause were after fsck and it was showing that it was checking the disk that would let me know the machine is doing something. If the pause is after DHCPDISCOVER I can surmise that if the network isn't hooked up then it is waiting for a timeout there. Furthermore if I am calling up to my dad who is 400 miles away and doesn't know all that much about Linux he can read me the lines and I can tell him likely causes of problems and pauses. Try that with See, about 12 seconds into bootup the little bar stops rotating for about 30 seconds. Like I said, those messages aren't meant for the neophytes. The neophytes aren't going to get it either way. They're there for the people that have to fix it when it breaks which may be through the interface of the neophyte. Do you REALLY think I want to walk my father through turning on boot-up logging on his Windows box, have it boot, then talk him, through booting into safe mode and *then* have him drill down to where the log would be? Yeah, that's easy alright. Why can't we instead have nice friendly messages? e.g.: Startup logging has begun. Log will be stored in '/var/log/boot'. ...instead of bootlogd. Because when it breaks what do you fix? What mechanism logs? Oh, the user's going to have to find that out. When it says bootlogd failed
Re: How to install X-Chat in five hours (or more)
First off, error messages can always be improved, and I bet the program maintainers would be happy to accept patches, so long as those patches don't *decrease* the amount of information available. But in one area you're dead wrong: On 05-Aug-03, 11:55 (CDT), Ian Hickson [EMAIL PROTECTED] wrote: Without meaning offense, that is a very selfish attitude. The number of future debian users is *significantly* larger than the number of existing users, unless something drastic happens to either humanity or debian itself. Why should everyone who will use debian in future be forced to learn archaic commands, paths, and deal with other historical holdbacks, instead of the few who already use it being taught easier conventions? Without meaning offense, that's a very selfish attitude. You want to ruin a system that provide incredible productivity and ease-of-use for the experienced user, for the sake of some hypothetical users who might be better served by another OS? You see, a great many of us (not just Debian users, but Unix users in general) have learned what those archaic commands and paths are, and their very shortness increases usability -- not learnability perhaps, but actual usuability, for those who use it every day. Combine that with the fact that they are the same[1] from system to system, and any changes are a complete detriment to usability. To you, 'list' may look better than 'ls', but for someone who types it several hundred times a week, and is *far* more likely to mis-type 'list', 'ls' is completely superior. Compare 'ls -ltr' with the VMS equivalent[2] 'directory/sort=date/order=reverse'. Yes, the latter is easier to read *IF* you don't know either. But which would you rather type? Which should keep you (or whoever wants to do it) from building a shell that provides more english like commands. But please don't ruin the system for the rest of us. [Re: UI designers] Unfortunately we don't seem to have many of those in the free software community. Now *that* is a true statement. Steve [1] The existing variations are painful enough. Let's not add to the problem [2] Yes, I know that's probably not the actual VMS command. It's been a while, and I don't have manual handy. But it's close enough to get the flavor of it. -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: How to install X-Chat in five hours (or more)
On Tue, Aug 05, 2003 at 11:06:53PM +0200, Tollef Fog Heen wrote: Tab completion or using /Va* is about as fast as /var. Heh, teach yourself to type /Va* and you're going to get BURNED one day. (Your co-sysadmin finds a rootkit on another machine and stores it in /Various Dangerous Programs/ for later examination...) Tab completion is fine in contexts where it works. Richard Braakman
Re: How to install X-Chat in five hours (or more)
On Tue, 5 Aug 2003 21:38:19 +0200 Emile van Bergen [EMAIL PROTECTED] wrote: Apple has a great way of doing that. They don't dumb down, they don't belittle you, they assume an intelligent being who can grasp reasonably complex English sentences, but who has less knowledge of computer idiom. *blink, blink* Funny, I consider Apple on of the worst when it comes to dumbing down the interface. Let's not forget they only took about 10 years to get *2* mouse buttons because it was too confusing. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. |-- Lenny Nero - Strange Days ---+- pgpNO5gaWvjcw.pgp Description: PGP signature
Re: How to install X-Chat in five hours (or more)
On Tue, 5 Aug 2003 22:16:37 +0200 Emile van Bergen [EMAIL PROTECTED] wrote: I would even scream at /Variable Data/ simply because it encourages slow and RSI-inducing click and drag behaviour, because such path names are impossible to type in (and this one even requires escaping the space to distinguish between the argument separator). Come now, there is always tab. Of course there is another reason why such descriptive names aren't all that great. Here's me sitting in a directory mounted off my Windows box. Can you tell where the unix system leaves off, where the Microsoft system catches on and why the Microsoft system was clearly never meant to be viewed from the command line? :) [EMAIL PROTECTED]:/mnt/morpheus_D/Program Files/Microsoft Games/Asheron's Call} If it were an all unix world we might have this: [EMAIL PROTECTED]:/mnt/morpheus_D/Games/AC} No less descriptive, just as readable but, by gum, I have more than 3 spaces before my command wraps! And heaven forbid I go one directory deeper! -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. |-- Lenny Nero - Strange Days ---+- pgpf68OSEt0xK.pgp Description: PGP signature
Re: Should MUA only Recommend mail-transfer-agent?
On Tue, 5 Aug 2003 21:42:43 +0200 Artur R. Czechowski [EMAIL PROTECTED] wrote: I would like to know Md's opinion, but for me there are no reasons to relax dependencies for mutt (and other MUA). I would not like to do it without policy requirements because it concerns also other MUA's. But it doesn't really concern other MUAs. Neither KMail or Sylpheed-claws have a depends on an MTA. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. |-- Lenny Nero - Strange Days ---+- pgp7SwlzTQAZU.pgp Description: PGP signature
Re: Should this be filed as grave? Gcc-2.95
On Tue, 5 Aug 2003 12:16:43 -0400 H. S. Teoh [EMAIL PROTECTED] wrote: Downgrading sounds like overkill in this situation. I only had to edit /usr/src/linux/Makefile to change HOSTCC to gcc-2.95 and export CC=gcc-2.95 in the environment, and it worked fine for me. This is on 2.4.21, of course, but I suspect the same holds for 2.4.20. [ SNIP ] ln -s /usr/bin/gcc-2.95 /usr/bin/gcc build kernel ln -s /usr/bin/gcc-3.3 /usr/bin/gcc Both of which I'd have to remember to do again later on if I compiled the kernel again. No, when 2.95 didn't work for whatever reason when I told make to use it I preferred to reduce the variables on the system. If 3.3 isn't present it can't be invoked, period. I don't have to remember to edit Makefiles later on on a different revision. I don't have to remember to reset symlinks, change alternatives or equivs or anything. I'm miffed mainly because I asked for 2.95 installed and got 3.3 as part of the deal. I don't take kindly to software installing other software without a clear need and there simply was no clear need. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. |-- Lenny Nero - Strange Days ---+- pgpqD18CMCOyb.pgp Description: PGP signature
Re: Bug#202869: Should MUA only Recommend mail-transfer-agent?
I can imagine a workstation without those packages but it is, IMO, mutilated box. please keep your opinion outside the control file. cron, at friends __need__ an MTA (or to be exact: a /usr/sbin/sendmail app), they will not work without. mutt can do many nice things without /usr/sbin/sendmail. a dependency is set if something is always required, a recommends if is required for the common use, and a suggestion is used if it improved the functionality. so depending on mail-transport-agent is wrong, the recommendation is fine. or fix the policy to make a clear statement. in that case maybe you want to reassign the bug. BTW, there is no need for exim4-daemon-heavy. There are other lightweight MTA's. I know. but still the dependency dialog is confusing and allmost all MTA even if not configure add poisen to a clean system like useless cron jobs, logfile rotation etc. an unused library only takes up a few inodes and kilobytes of disk ram and thus is easy to bear. an unused MTA however is quite a heavy thing compared to that. take a look at all those silly debconf questions some packages have, and you know why it is a good thing not to install one on a system where you don't need it. Another solution is to prepare a dummy-mta package, which only provides mail-transfer-agent and required by policy /usr/sbin/sendmail and /usr/bin/newaliases binaries to do nothing[1]. sounds like shooting in ones foot to me. If debian has one major policy, it is not to have a policy. debian does not decide what architecture or window manager or mail transport agent your want - you can choose. debian does not decide whether you want a small systme or a big fat installation - you can choose. why should debian insist on installing a mail transport agent where none is needed? and the easy solution is to relax the dependency to a recommendation. The policy supports this. Not that the wording in the policy is perfekt, it could be improved (see my suggestion above) to support the recommendation or to deny this bug report and put an explicit dependency in the policy. sure, this bug report is bigger than mutt, it will affect many other mail readers and apps everywhere as well. closing the bug or marking it as whishlist would be wrong. debian claims not to hide problem. here is one. please accept it and handle it. Regards, Andreas
Re: Fw: Re: Ruby 1.8 transition plan; debian-ruby
On Tue, 2003-08-05 at 12:12, Fumitoshi UKAI wrote:
Since ruby 1.8.0 was released recently, ruby developers will go to
ruby 1.8.x, so that we, ruby maintenance team (akira, tagoh, ukai),
are discussing about how to deal with Ruby 1.8 transition and trying to make
debian ruby policy soon.
For now, ruby package provides /usr/bin/ruby of ruby 1.6.x, and
ruby1.8 package provides /usr/bin/ruby1.8 of ruby 1.8.x. Someone
want to use /usr/bin/ruby of ruby 1.8.x, so we're considering to use
alternatives for /usr/bin/ruby to choice either ruby1.6, ruby1.8 (or any
other version of ruby in future).
There was a bug about this at some point, which I can no longer find,
where I suggested doing for Ruby what Python does. Which is essentially:
- 'ruby' is a metapackage depending the current default version of Ruby
for Debian.
- 'rubyX.Y' is a specific version of Ruby. 'ruby' depends on one of
these.
- 'libfoo-bar-ruby' is a metapacakge depending on libfoo-bar-rubyX.Y,
where X.Y is the default version of Ruby (the same as the one 'ruby'
depends on).
- 'libfoo-bar-rubyX.Y' is foo-bar for a specific version of Ruby. The
above depends on one of these. (These packages may be unncessary if the
directory tree I outlined below is used, and the package is
version-independent.)
As for module include paths, they're less important since most Ruby
modules query Ruby for the right information at build-time anyway, but
I'd like to see version-independent directories, and also preferrably a
tree under /usr/share, too. Say,
These are arch-independent:
- /usr/share/ruby for Ruby modules that work with any version.
- /usr/share/ruby/X.Y for Ruby modules that depend on version X.Y.
These are arch-dependent:
- /usr/lib/ruby/version/X.Y/#{arch}-#{os} for all arch-dependent
modules. I believe most architecture-dependent modules need to be
recompiled for each version of Ruby anyway, and so a version-independent
architecture-dependent directory makes no sense.
--
Joe Wreschnig [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: How to install X-Chat in five hours (or more)
On Tue, Aug 05, 2003 at 03:03:54PM -0700, Steve Lamb wrote: On Tue, 5 Aug 2003 09:55:59 -0700 (PDT) Ian Hickson [EMAIL PROTECTED] wrote: And I'm a geek, one who has been using GNU-based distributions on multiple machines on a daily basis for at least 3 years, and Sun for 6 years before that, and I _still_ have difficulty. This should be ringing usability alarm bells. No, it shouldn't. I should be ringing alarms about the veracity of your claims and your capabilities. Hixie's pretty well-known in certain other free software circles. What I've seen of him elsewhere implies to me that he isn't incompetent in the least, and frankly I think you're going way overboard in the hostility of your responses. I'm sure it's possible for us to recognize that things aren't perfect even if we disagree on how to fix them. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: How to install X-Chat in five hours (or more)
Steve Lamb [EMAIL PROTECTED] writes: Oh, look, someone else who CCs when it is obvious the person they're responding to is participating right here. Maybe you should stop whining and just set the Mail-Copies-To header, which is generally respected by posters on Debian lists? -- Alan Shutko [EMAIL PROTECTED] - I am the rocks. What's all this I hear about endangered feces?
Re: How to install X-Chat in five hours (or more)
On Tue, 5 Aug 2003 23:30:11 +0100 Colin Watson [EMAIL PROTECTED] wrote: Hixie's pretty well-known in certain other free software circles. What I've seen of him elsewhere implies to me that he isn't incompetent in the least, and frankly I think you're going way overboard in the hostility of your responses. I'm sure it's possible for us to recognize that things aren't perfect even if we disagree on how to fix them. You're most likely right, I'll bow out. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. |-- Lenny Nero - Strange Days ---+- pgp1k6Er4gb9A.pgp Description: PGP signature
Re: How to install X-Chat in five hours (or more)
Richard Braakman [EMAIL PROTECTED] writes: Heh, teach yourself to type /Va* and you're going to get BURNED one day. (Your co-sysadmin finds a rootkit on another machine and stores it in /Various Dangerous Programs/ for later examination...) And gee, your shell beeps, completes up to /Various\ , and doesn't go further. How is this going to get you burned? -- Alan Shutko [EMAIL PROTECTED] - I am the rocks. Your rifle won't leave a wet spot on the bed after you use it.
Re: Bug#202869: Should MUA only Recommend mail-transfer-agent?
* Andreas Jellinghaus [Wed, 6 Aug 2003 at 00:27 +0200] mutt can do many nice things without /usr/sbin/sendmail. a dependency is set if something is always required, a recommends if is required for the common use, and a suggestion is used if it improved the functionality. so depending on mail-transport-agent is wrong, the recommendation is fine. Mutt can read mail without an MTA, but cannot send mail without one. Whether sending mail is considered simply common use or is a core functionality has been and certainly will be nit-picked. Your argument rests on the former. -- Hans Fugal | De gustibus non disputandum est. http://hans.fugal.net/ | Debian, vim, mutt, ruby, text, gpg http://gdmxml.fugal.net/ | WindowMaker, gaim, UTF-8, RISC, JS Bach - GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460 pgpVhuUMAFDkO.pgp Description: PGP signature
Re: Bug#202869: Should MUA only Recommend mail-transfer-agent?
Hi, [ note that I atm have the tendency to say that the Depends should remain... ] Hans Fugal wrote: * Andreas Jellinghaus [Wed, 6 Aug 2003 at 00:27 +0200] mutt can do many nice things without /usr/sbin/sendmail. a dependency is set if something is always required, a recommends if is required for the common use, and Right, although I normally, I decide from pkg to pkg with this and if the feature needing a package is one of main ones of the software or not. And the MUAs main features are reading and _sending_ mails a suggestion is used if it improved the functionality. so depending on mail-transport-agent is wrong, the recommendation is fine. Mutt can read mail without an MTA, but cannot send mail without one. ... but this is bullshit. I don't need a MTA to send my mail with mutt. I use offlineimap, courier's outbox feature, direct the mail to the local Outbox[1], synchronize it and the _mail server_ sends it out. Or if someone accesses IMAP directly it could set sendmail=/dev/null and set Fcc to the Outbox which has the same effect. There are so many possibilities to send mails from mutt without an MTA.. Yes, sure, this is not the common configuration, but possible and the argument that people using mutt _need_ a MTA is evidently wrong... Grüße/Regards, René [1] set sendmail=~/bin/imap/mailout which contains safecat /home/rene/Mail/INBOX.Outbox/tmp /home/rene/Mail/INBOX.Outbox/new hi Omnic :) -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 pgpbY9uc6wnP3.pgp Description: PGP signature
Re: Have Linux boot with eye-candy
Hi, i have built packages for the bootsplash tools (no package for the patch itself though. just download and apply the diff). They are available on http://people.debian.org/~erich/boot/bootsplash/ and work fine on my notebook as well as my sisters. I didn't get the bootsplash support of swsusp working though; but maybe i just forgot applying that connector patch... ;) No AA Text rendering yet (what text to use? that would require modifications to the init scripts... i didn't build this fbtruetype tool yet, but i probably is as easy as the rest) and no animations (packages are built, but i don't have nice animations, i'm no artist. ;) ) Progress bar is working fine if you use the supplied rc.splash (just change it in /etc/inittab) You'll find a theme i built for Debian there, too. It uses a really cool background made by Alexis Younes (ayo), http://www.73lab.com/ -- unfortunately i don't know if it is DFSG-free. using the debian logos it probably isn't. ;) Greetings, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ There was never a good war or a bad peace. - Benjamin Franklin //\ Die kürzeste Verbindung zwischen zwei Menschen ist ein Lächeln. V_/_
Re: How to install X-Chat in five hours (or more)
Em Tue, 05 Aug 2003 17:39:06 -0500, Alan Shutko [EMAIL PROTECTED] escreveu: Richard Braakman [EMAIL PROTECTED] writes: Heh, teach yourself to type /Va* and you're going to get BURNED one day. (Your co-sysadmin finds a rootkit on another machine and stores it in /Various Dangerous Programs/ for later examination...) And gee, your shell beeps, completes up to /Various\ , and doesn't go further. How is this going to get you burned? I guess he's not talking about tab completion in this case, but about '*'... I actually use this stuff when I cannot use tabs... [~] [EMAIL PROTECTED] $ cd /ho*/k* [/home/khaotikuz] [EMAIL PROTECTED] $ This should make the problem clearer... I actually wanted to go to '/home/kov', but my dumb sysadmin (me =P) created a khaotikuz user... []s! -- [EMAIL PROTECTED]: Gustavo Noronha http://people.debian.org/~kov Debian: http://www.debian.org * http://www.debian-br.org Dúvidas sobre o Debian? Visite o Rau-Tu: http://rautu.cipsga.org.br
Re: How to install X-Chat in five hours (or more)
Em Tue, 5 Aug 2003 10:19:53 -0700 (PDT), Ian Hickson [EMAIL PROTECTED] escreveu: You can't get there from here, I think. Unix admins coming to Debian will scream blue murder if it starts being /My Variable Data/Logs, and that group is important to us. Note that there is at least one project which is looking at doing exactly that while retaining backwards compatability (GoboLinux). It may be worth, on the long term, looking at how it may be possible to migrate from obscure paths like /opt, /bin, /sbin, /usr/bin, etc, to more sensible names, in that way. They had a presentation on the IV Free Software International Forum in Porto Alegre (Brazil) this year and I can assure you I didn't hear a lot of good things about this (I didn't actually attend to the thing, but other DD's did). It seems like a mess of symlinks and they say it doesn't need 'package management' when it actually has a bunch of scripts to handle the symlink 'farm' they grow on /usr/bin and such. Doesn't seem like a clean solution to me, no no no... It also seems like they want to have each package installed in its own directory, which I think sucks tremendously... I hated that when I lived with windows... I always wanted to have all my binaries in the PATH, etc. And the real end user does not even care about that. I don't really care about /. I think path abstraction should be achieved by graphical file management utilities like Nautilus, not by messing with something that's actually working, to then cause more problems. []s! -- [EMAIL PROTECTED]: Gustavo Noronha http://people.debian.org/~kov Debian: http://www.debian.org * http://www.debian-br.org Dúvidas sobre o Debian? Visite o Rau-Tu: http://rautu.cipsga.org.br
Re: How to install X-Chat in five hours (or more)
Gustavo Noronha Silva dijo [Tue, Aug 05, 2003 at 09:26:20PM -0300]: Note that there is at least one project which is looking at doing exactly that while retaining backwards compatability (GoboLinux). It may be worth, on the long term, looking at how it may be possible to migrate from obscure paths like /opt, /bin, /sbin, /usr/bin, etc, to more sensible names, in that way. They had a presentation on the IV Free Software International Forum in Porto Alegre (Brazil) this year and I can assure you I didn't hear a lot of good things about this (I didn't actually attend to the thing, but other DD's did). (...) I don't really care about /. I think path abstraction should be achieved by graphical file management utilities like Nautilus, not by messing with something that's actually working, to then cause more problems. I completely agree with you... I was arguing with a friend of mine, a Ximian developer. He insisted me that they were bringing Unix to the desktop of people, just like what Apple did. I insst that is *not* what they are doing. Even though under every Ximian and MacOS X system there is a Unix box, the user only uses a strange abstraction that -maybe without the user's knowledge- uses Unix itself. Debian is a Unix system (ok, Unix-like for purism). It should stay a Unix system. We already have a very important user base, we are obliged not to give them such a headache. Besides, I really doubt that even one tenth of the Debian developers would be happy to switch ;-) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: How to install X-Chat in five hours (or more)
Alan Shutko [EMAIL PROTECTED] writes: Steve Lamb [EMAIL PROTECTED] writes: Oh, look, someone else who CCs when it is obvious the person they're responding to is participating right here. Maybe you should stop whining and just set the Mail-Copies-To header, which is generally respected by posters on Debian lists? Har! The people that use a decent MUA already know how to participate in list discussions, and those that don't won't pay a bit of attention to that header. -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgpSznaaJXdBF.pgp Description: PGP signature
Request for maintainer
Hi! Subject: RFP: GRubik -- A 3D Rubik cube game Package: wnpp Version: N/A; reported 2003-08-06 Severity: wishlist * Package name: GRubik Version : 1.16 Upstream Author : John Darrington [EMAIL PROTECTED] * URL : http://www.freesoftware.fsf.org/rubik/grubik.html * License : GPL-2 Description : A 3D Rubik cube game This is an OpenGL / GTK+ package which I have written. I've had positive feedback from the people who've looked at it so far. It's fully internationalised, has a number (5?) localisations. I'm not a DD, and am not currently able to commit to being one. However if a DD wants to become a maintainer of this package I will co-operate with him/her (eg upstream patches where needed). I have created an unofficial deb for this software, and you can get it from my website http://darrington.wattle.id.au/deb if you want to use that as a starting point. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux freyja.cellform.com 2.2.17 #1 Sun Jun 25 09:24:41 EST 2000 i?86 Locale: LANG=en_AU, LC_CTYPE=en_AU -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://wwwkeys.pgp.net or any PGP keyserver for public key. pgpdTirubV8Nf.pgp Description: PGP signature
OT (Re: Excessive wait for DAM - something needs to be done)
Martin Michlmayr - Debian Project Leader [EMAIL PROTECTED] writes: * Jamin W. Collins [EMAIL PROTECTED] [2003-07-21 18:52]: Perhaps that is because only the DPL can appoint them (as far as I can tell) and we haven't seen a request from you for them. Request for help are usually very ineffective; examples: apt's maintainer asked for help and didn't get any (with the exception that mdz has started more apt work, but he worked on apt before so effectively there are no new volunteers), Bdale is looking for a co-maintainer of ntp as is md for mutt. Mails with suggestions and offers to help (and I'm esspecially mean apt here :( ) also go unanswered or patches for bugs or improvements get just overlooked and never included. Shit happens. Don't stop trying. MfG Goswin
Re: Excessive wait for DAM - something needs to be done
Dwayne C. Litzenberger [EMAIL PROTECTED] writes: On Sun, Jul 13, 2003 at 01:09:47PM -0600, Jamin W. Collins wrote: 2001-01-24 - Dwayne Litzenberger [EMAIL PROTECTED] http://nm.debian.org/nmstatus.php?email=dlitz%40dlitz.net For the record, I'm still interested in becoming a DD. Nice to see this finally being addressed! Thanks! http://nm.debian.org/nmstatus.php?email=brederlo%40informatik.uni-tuebingen.de Received application2000-08-25 Still waiting too. MfG Goswin
Re: NM non-process
Steve Langasek [EMAIL PROTECTED] writes: On Mon, Jul 21, 2003 at 10:17:24AM -0400, Nathanael Nerode wrote: Martin Schulze is listed as the other DAM member. He's also the Press Contact, so I certainly hope he has good communication skills! And the Stable Release Manager, and a member of the Security Team, and a member of debian-admin. What makes you think he would give a higher priority to DAM work than James currently does? Actually, given that Joey is already listed as part of DAM, and isn't actively involved, doesn't this suggest he already gives a lower priority to this work? As far as I heard Matrin is only there in case the DAM dies. He won't create or delete account on his own while the DAM is still breathing (or thought to be). MfG Goswin
Re: NM non-process
[EMAIL PROTECTED] (Nathanael Nerode) writes: Steve Langasek said: I don't think it irrelevant that those clamouring loudest for the DPL to do something to fix the situation are people who don't actually have a say in the outcome of DPL elections. While I'm not happy to see such long DAM wait times, I'm also not volunteering to take on the thankless job myself. No, it's not irrelevant. It means precisely that Debian is in danger of becoming an unresponsive, closed group which does not admit new people. If this continues for, say, 2 more years, I would expect a new Project to be formed, replicating what Debian is doing, but admitting new people. I'd probably be right there starting it. That would be a stupid waste of effort, so I hope it turns out to be unnecessary. I know of several DDs and non-DDs thinking about creating a Debian2 (or whatever named) project due to this and other lack of responce problems and the group is growing. The danger is already there and should not be ignored. MfG Goswin
Re: NM non-process
Kalle Kivimaa [EMAIL PROTECTED] writes: Roland Mas [EMAIL PROTECTED] writes: with. The MIA problem is significant enough that NM might be the only way to tackle with it seriously. That means taking time to examine applications. BTW, has anybody done any research into what types of package maintainers tend to go MIA? I would be especially interested in a percentage of old style DD's, DD's who have gone through the NM process, people going MIA while in the NM queue, and people going MIA without ever even entering the NM queue. I'll try to do the statistics myself if nobody has done it before. And how many NMs go MIA because they still stuck in the NM queue after years? Should we ask them? :) MfG Goswin
Re: Request for maintainer
[EMAIL PROTECTED] writes: Hi! Subject: RFP: GRubik -- A 3D Rubik cube game Package: wnpp Version: N/A; reported 2003-08-06 Severity: wishlist * Package name: GRubik Version : 1.16 Upstream Author : John Darrington [EMAIL PROTECTED] * URL : http://www.freesoftware.fsf.org/rubik/grubik.html * License : GPL-2 Description : A 3D Rubik cube game This is an OpenGL / GTK+ package which I have written. I've had positive feedback from the people who've looked at it so far. It's fully internationalised, has a number (5?) localisations. I'm not a DD, and am not currently able to commit to being one. However if a DD wants to become a maintainer of this package I will co-operate with him/her (eg upstream patches where needed). I have created an unofficial deb for this software, and you can get it from my website http://darrington.wattle.id.au/deb if you want to use that as a starting point. Maybe you should ask on the new maintainer list for some new maintainer thats intrested and needs a package to maintain. Just an idea. MfG Goswin
Accepted time 1.7-16 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 4 Aug 2003 21:03:47 -0500 Source: time Binary: time Architecture: source i386 Version: 1.7-16 Distribution: unstable Urgency: low Maintainer: Dirk Eddelbuettel [EMAIL PROTECTED] Changed-By: Dirk Eddelbuettel [EMAIL PROTECTED] Description: time - The GNU time command. Closes: 201021 203804 Changes: time (1.7-16) unstable; urgency=low . * time.c: When time exits in a non-normal way, return 128 plus the number of the signal which caused time to stop or abort. Thanks to Steve Greenland and Herbert Xu for some clarification in this matter. * debian/time.1: Corrected typo, thanks Justin Pryzby (Closes: #201021) * debian/time.1: Documented exit code, and change above (Closes: #203804) * debian/time.1: Documented that bash users want /usr/bin/time * debian/rules: Converted to cdbs * debian/control: Added cdbs to Build-Depends, increased debhelper version * debian/control: automake Build-Depends changed to automaken * debian/control: Increase Standards-Version to 3.6.0 Files: c19f8ea73c89fcbc0c4c5a08977eeac1 585 utils standard time_1.7-16.dsc dd8896dcad326b986f4b9924e6212513 35661 utils standard time_1.7-16.diff.gz b937701f85796f392e1e68993a0563f6 30374 utils standard time_1.7-16_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/LxDRCZSR95Gw07cRAkrOAKCQqT2ltdKplvjvDbCV6t0nd8HUFACdGgbx qv5IVTf/wdOzKs20WVdvD8w= =GGDQ -END PGP SIGNATURE- Accepted: time_1.7-16.diff.gz to pool/main/t/time/time_1.7-16.diff.gz time_1.7-16.dsc to pool/main/t/time/time_1.7-16.dsc time_1.7-16_i386.deb to pool/main/t/time/time_1.7-16_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted luola 1.2.0-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 4 Aug 2003 20:22:21 -0400 Source: luola Binary: luola luola-data Architecture: source i386 all Version: 1.2.0-1 Distribution: unstable Urgency: low Maintainer: Christian T. Steigies [EMAIL PROTECTED] Changed-By: Christian T. Steigies [EMAIL PROTECTED] Description: luola - multiplayer cave-flying game luola-data - data files for luola Changes: luola (1.2.0-1) unstable; urgency=low . * New upstream release * GNU config automated update: config.sub (20030509 to 20030717), config.guess (20030519 to 20030702) Files: 5096ba2f264c24cc8cb9f31c24690a09 734 games optional luola_1.2.0-1.dsc b28a6a583dc0223ec833a156a8dbf37e 1309298 games optional luola_1.2.0.orig.tar.gz 6a358e5299777e7cf7da345d5a08fa21 18165 games optional luola_1.2.0-1.diff.gz 0eca49720ba9a97243f81bc811acd487 948836 games optional luola-data_1.2.0-1_all.deb ad16da93110adeb3f604f7afce2b36e3 120084 games optional luola_1.2.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/LvlFhWcuXd2lEoARAiTiAKDHixRpPn5VY7CqadSTuZP+wada3ACgskrD 9yJZGi0sv90scpQ1AyENGIo= =RMQf -END PGP SIGNATURE- Accepted: luola-data_1.2.0-1_all.deb to pool/main/l/luola/luola-data_1.2.0-1_all.deb luola_1.2.0-1.diff.gz to pool/main/l/luola/luola_1.2.0-1.diff.gz luola_1.2.0-1.dsc to pool/main/l/luola/luola_1.2.0-1.dsc luola_1.2.0-1_i386.deb to pool/main/l/luola/luola_1.2.0-1_i386.deb luola_1.2.0.orig.tar.gz to pool/main/l/luola/luola_1.2.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gem 0.87cvs20030708-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 5 Aug 2003 12:12:43 +0200 Source: gem Binary: gem Architecture: source i386 Version: 0.87cvs20030708-4 Distribution: unstable Urgency: low Maintainer: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Changed-By: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Description: gem- Graphics Environment for Multimedia - OpenGL animation tools Changes: gem (0.87cvs20030708-4) unstable; urgency=low . * fixed menu entry * removed ffmpeg * incorporated pix_texture alpha blending bugfix Files: ba34e03049d9ea359015d03ed653989b 783 graphics optional gem_0.87cvs20030708-4.dsc 1ea3b650dae52fdeba78349685fe1842 272716 graphics optional gem_0.87cvs20030708-4.diff.gz b9bdcd125c040069affe310803015f5a 1591886 graphics optional gem_0.87cvs20030708-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/L4eZ1pbKhmC2uVgRAl7PAJ9uY10N4n6J7Ek1nVG11kz5ukSAKACfVWjP o2FaAsig+24GdLTBQpZWXlU= =pvUY -END PGP SIGNATURE- Accepted: gem_0.87cvs20030708-4.diff.gz to pool/main/g/gem/gem_0.87cvs20030708-4.diff.gz gem_0.87cvs20030708-4.dsc to pool/main/g/gem/gem_0.87cvs20030708-4.dsc gem_0.87cvs20030708-4_i386.deb to pool/main/g/gem/gem_0.87cvs20030708-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted loudmouth 0.13-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 5 Aug 2003 11:53:29 +0100 Source: loudmouth Binary: libloudmouth0 libloudmouth-dev Architecture: source i386 Version: 0.13-1 Distribution: unstable Urgency: low Maintainer: Ross Burton [EMAIL PROTECTED] Changed-By: Ross Burton [EMAIL PROTECTED] Description: libloudmouth-dev - Development files for Loudmouth Jabber library libloudmouth0 - Lightweight C Jabber library Changes: loudmouth (0.13-1) unstable; urgency=low . * New upstream release Files: 135fa14dbfceab412a1c70bd266dc454 675 libs optional loudmouth_0.13-1.dsc 09598b859d6ebccb36264b4d0297aaca 365653 libs optional loudmouth_0.13.orig.tar.gz 8d75079402ffc455fe5e10a6517c9da7 2150 libs optional loudmouth_0.13-1.diff.gz 062aa82c77c04d10664060f18ff983f1 43084 libdevel optional libloudmouth-dev_0.13-1_i386.deb 9c946694119271529ffe6e01f7490e7e 26278 libs optional libloudmouth0_0.13-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/L41yLQnkR9C0M98RAsHKAJ0T43I2g4mY8EvlJYBcjcBA7VimJQCgzUGu bgpOgPz2rYW+MLthCUkK32Q= =SpFI -END PGP SIGNATURE- Accepted: libloudmouth-dev_0.13-1_i386.deb to pool/main/l/loudmouth/libloudmouth-dev_0.13-1_i386.deb libloudmouth0_0.13-1_i386.deb to pool/main/l/loudmouth/libloudmouth0_0.13-1_i386.deb loudmouth_0.13-1.diff.gz to pool/main/l/loudmouth/loudmouth_0.13-1.diff.gz loudmouth_0.13-1.dsc to pool/main/l/loudmouth/loudmouth_0.13-1.dsc loudmouth_0.13.orig.tar.gz to pool/main/l/loudmouth/loudmouth_0.13.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pam-dotfile 0.6-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 05 Aug 2003 11:29:17 +0200 Source: pam-dotfile Binary: libpam-dotfile Architecture: source i386 Version: 0.6-4 Distribution: unstable Urgency: low Maintainer: Oliver Kurth [EMAIL PROTECTED] Changed-By: Oliver Kurth [EMAIL PROTECTED] Description: libpam-dotfile - A PAM module which allows users to have more than one password Changes: pam-dotfile (0.6-4) unstable; urgency=low . * setuid bit for /usr/sbin/pam-dotfile-helper Files: 2d29dab14934556da5c786f80be1fd53 611 admin optional pam-dotfile_0.6-4.dsc 1a48033a1f39fb93432b3dd3c7855205 16033 admin optional pam-dotfile_0.6-4.diff.gz dd2978e1d836710ad875e879c9e3e364 30636 admin optional libpam-dotfile_0.6-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/L3plUmVSJkUeqxsRAqjYAJ41aUfNj3objZ+G7MitqTmTWc3HygCgncL0 tMq9RAsJp4z6cHeihZnW1Xs= =wvKK -END PGP SIGNATURE- Accepted: libpam-dotfile_0.6-4_i386.deb to pool/main/p/pam-dotfile/libpam-dotfile_0.6-4_i386.deb pam-dotfile_0.6-4.diff.gz to pool/main/p/pam-dotfile/pam-dotfile_0.6-4.diff.gz pam-dotfile_0.6-4.dsc to pool/main/p/pam-dotfile/pam-dotfile_0.6-4.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mopd 1:2.5.3-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 5 Aug 2003 09:36:40 +0100 Source: mopd Binary: mopd Architecture: source i386 Version: 1:2.5.3-3 Distribution: unstable Urgency: low Maintainer: Patrick Caulfield [EMAIL PROTECTED] Changed-By: Patrick Caulfield [EMAIL PROTECTED] Description: mopd - The Maintenance Operations Protocol (MOP) loader daemon Closes: 201246 201285 Changes: mopd (1:2.5.3-3) unstable; urgency=low . * Use gettext-based debconf templates. Closes: #201285 * Fix comma in debconf template Closes: #201246 * Thanks to Christian Perrier for both those. Files: 11980b795721e60a73d3966d447bf0c5 573 net extra mopd_2.5.3-3.dsc a2778456036cf4ecf94b9729ee0d0e74 52973 net extra mopd_2.5.3-3.diff.gz c1c438220d75135cc8901614cf704513 56360 net extra mopd_2.5.3-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/L2zahej7/PCycRMRAnmzAKCY8YtiZbERbDPI3Fuk0QK2QdUcQQCeOqu7 lEDwp/aqp6raSYJmwt5YkRE= =E0uT -END PGP SIGNATURE- Accepted: mopd_2.5.3-3.diff.gz to pool/main/m/mopd/mopd_2.5.3-3.diff.gz mopd_2.5.3-3.dsc to pool/main/m/mopd/mopd_2.5.3-3.dsc mopd_2.5.3-3_i386.deb to pool/main/m/mopd/mopd_2.5.3-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sylpheed-claws 0.9.4claws-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 5 Aug 2003 04:21:43 -0300 Source: sylpheed-claws Binary: sylpheed-claws Architecture: source i386 Version: 0.9.4claws-1 Distribution: unstable Urgency: low Maintainer: Gustavo Noronha Silva [EMAIL PROTECTED] Changed-By: Gustavo Noronha Silva [EMAIL PROTECTED] Description: sylpheed-claws - Bleeding edge version of the Sylpheed mail client Closes: 155293 202073 Changes: sylpheed-claws (0.9.4claws-1) unstable; urgency=low . * New upstream release - notification of valid/invalid signatures is provided by icons at the right of the messageview (Closes: #155293) - pop-before-smtp no longer segfaults (Closes: #202073) Files: c2f97f0df281deda911e4d96b08343ac 993 mail extra sylpheed-claws_0.9.4claws-1.dsc ddb0fa5b8530dafc475597ba23d4b888 3794544 mail extra sylpheed-claws_0.9.4claws.orig.tar.gz 2ba2e6cc40aa5ce373672b199676e3ea 81928 mail extra sylpheed-claws_0.9.4claws-1.diff.gz 37129da132da59ae43a43e48edc77676 3034298 mail extra sylpheed-claws_0.9.4claws-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/L3HAt1anjIgqbEsRAoYrAKCK5+Zsf19xlDddmnBoKy3xrnKmUgCaAyvU qNzt/5iUFr9vHAFYS+X9qAE= =52ZX -END PGP SIGNATURE- Accepted: sylpheed-claws_0.9.4claws-1.diff.gz to pool/main/s/sylpheed-claws/sylpheed-claws_0.9.4claws-1.diff.gz sylpheed-claws_0.9.4claws-1.dsc to pool/main/s/sylpheed-claws/sylpheed-claws_0.9.4claws-1.dsc sylpheed-claws_0.9.4claws-1_i386.deb to pool/main/s/sylpheed-claws/sylpheed-claws_0.9.4claws-1_i386.deb sylpheed-claws_0.9.4claws.orig.tar.gz to pool/main/s/sylpheed-claws/sylpheed-claws_0.9.4claws.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xtokkaetama 1.0b-9 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 5 Aug 2003 09:39:46 +0900 Source: xtokkaetama Binary: xtokkaetama Architecture: source i386 Version: 1.0b-9 Distribution: unstable Urgency: high Maintainer: Kenshi Muto [EMAIL PROTECTED] Changed-By: Kenshi Muto [EMAIL PROTECTED] Description: xtokkaetama - X Puzzle Game. Closes: 204125 204126 Changes: xtokkaetama (1.0b-9) unstable; urgency=high . * Oops, fix another buffer overflow (closes: Bug#204125, Bug#204126). Files: e8c129d1d3256df460ead24b18207825 589 games optional xtokkaetama_1.0b-9.dsc b90528aea161274809c5ab6bf90a8c3f 6772 games optional xtokkaetama_1.0b-9.diff.gz 6a809bc40890aa667b37bb6abe9f5edb 101250 games optional xtokkaetama_1.0b-9_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iEYEARECAAYFAj8veP4ACgkQQKW+7XLQPLFZVgCfRbby54C0NSu38hVi1uh8Ugz6 Ha0AoLry6CXhRaXW5MGWJFSNnldixBSg =UMVf -END PGP SIGNATURE- Accepted: xtokkaetama_1.0b-9.diff.gz to pool/main/x/xtokkaetama/xtokkaetama_1.0b-9.diff.gz xtokkaetama_1.0b-9.dsc to pool/main/x/xtokkaetama/xtokkaetama_1.0b-9.dsc xtokkaetama_1.0b-9_i386.deb to pool/main/x/xtokkaetama/xtokkaetama_1.0b-9_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted fprobe 0.4-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 01 Aug 2003 11:34:39 +1000 Source: fprobe Binary: fprobe Architecture: source i386 Version: 0.4-1 Distribution: unstable Urgency: low Maintainer: Anibal Monsalve Salazar [EMAIL PROTECTED] Changed-By: Anibal Monsalve Salazar [EMAIL PROTECTED] Description: fprobe - exports NetFlow V5 datagrams to a remote collector Changes: fprobe (0.4-1) unstable; urgency=low . * New upstream release. Files: 6641724ba8cdeaccd1aeb0fdeb3e8a96 612 net optional fprobe_0.4-1.dsc 51ae338372e567acf0ce487eaf7412df 20546 net optional fprobe_0.4.orig.tar.gz 11ffedb58062cc7f98ef57552347d051 1714 net optional fprobe_0.4-1.diff.gz 7db99d74c062163f1ab52239bf64f486 12618 net optional fprobe_0.4-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8wVo0ACgkQuCinHABTDCQXjACgh0ndT+4uo+cxjefQpg4cOjDa AqwAn2Gm+ARNx2FIhghOvgIhDfcSrLFI =S9KD -END PGP SIGNATURE- Accepted: fprobe_0.4-1.diff.gz to pool/main/f/fprobe/fprobe_0.4-1.diff.gz fprobe_0.4-1.dsc to pool/main/f/fprobe/fprobe_0.4-1.dsc fprobe_0.4-1_i386.deb to pool/main/f/fprobe/fprobe_0.4-1_i386.deb fprobe_0.4.orig.tar.gz to pool/main/f/fprobe/fprobe_0.4.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted webalizer 2.01.10-19 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 5 Aug 2003 12:51:56 +0200 Source: webalizer Binary: webalizer Architecture: source i386 Version: 2.01.10-19 Distribution: unstable Urgency: low Maintainer: Remco van de Meent [EMAIL PROTECTED] Changed-By: Remco van de Meent [EMAIL PROTECTED] Description: webalizer - Web server log analysis program Closes: 200592 201697 Changes: webalizer (2.01.10-19) unstable; urgency=low . * Updated to Standards-Version 3.6.0 * List all months correctly again in index; applied patch from Tatsuki Sugiura (closes: #200592, #201697) Files: d246aaad46cc828bd07542953235a468 686 web optional webalizer_2.01.10-19.dsc 6ae678b2efcf456b2071b4fe0c93b232 155071 web optional webalizer_2.01.10-19.diff.gz ae8f03264a485129d3d65bb88e402e61 289734 web optional webalizer_2.01.10-19_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/L5MK2tWnGbzBMd4RAuBUAJ9AOztNBu7rWaHEq/lDUvqHaH0mKgCeJsBt SOae8kWgzk3dB4tpZ2jfiSI= =cPhL -END PGP SIGNATURE- Accepted: webalizer_2.01.10-19.diff.gz to pool/main/w/webalizer/webalizer_2.01.10-19.diff.gz webalizer_2.01.10-19.dsc to pool/main/w/webalizer/webalizer_2.01.10-19.dsc webalizer_2.01.10-19_i386.deb to pool/main/w/webalizer/webalizer_2.01.10-19_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
