Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs
On Wed, 30 Aug 2000, Peter Teichman wrote: I have one question. What is the preferred way for me to handle our gtk package? This is a library package that we actually apply some patches to for a slightly nicer user interface. Well, we don't have much provision for flavors of shared libraries. The best solution would be to use versioned provides and provide a differently named package, libgtk-helix or something. Jason
Re: Crazy idea: removing version numbers from debian
On Wed, Aug 30, 2000 at 11:58:22AM -0500, Vincent L. Mulhollon wrote: Perhaps any package can live in unstable, but any package that has a release critical bug older than 1 week is zapped from stable and placed back in unstable. Upon next package upload, it will be reinstated into stable. That wont help very much because the users who have installed the package will have the buggy version anyway. On the other hand disappearing and reappearing packages (especially in the stable distribution) will confuse the users and break dependencies. Bugs in stable packages are bad, but as long as they are no security related or data corrupting bugs we have to live with them. For security or data corrupting bugs we have to use out of band methods for pushing fixes/warnings anyway. Of course in that case it might be wort to actually plug the unfixed packages from the distribution to avoid bad informed/educated usrs to run into a trap. Greetings Bernd
Re: APT problem
On Wed, Aug 30, 2000 at 05:37:52PM -0400, Daniel Burrows wrote: (especially since this looks like just the well-established behavior of downloading changed packages..) I dont have a example right now, but on my system aptitude will download the same package again and again. So in case it sees a difference must be related two different sources provide the same package entry. then it downloads the pakcage from one source and compares it with the entry of another source. Hmm.. i will watch the problems and report them. 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: Bug#70269: automatic build fails for potato
On Wed, Aug 30, 2000 at 01:06:30PM -0500, Steve Greenland wrote: Which is just a stupid pain in the ass. I had to track through three different references and finally install the build-depends package to find out what I could leave out of by Build-Depends stanza. It would *much* easier for developers, if less ideologically pure, to just list the damn packages on the Developers Corner part of the website. And include it in lintian. Actually I dont mind having too much in the Build-Depends list since it wont hurt. And requiring debhelper is done by dh_make now automatically. Greetings Bernd
Re: /etc/terminfo/x/xterm problem with ncurses-base 4.2-3 to 5.0-6
On Thu, Aug 31, 2000 at 01:17:20PM +1100, Trent Swift wrote: When you telnet/ssh from an xterm on a dec/solaris box to potato machine with ncurses.v.5.0-6, and then run less (or something that uses /etc/terminfo/x/xterm) the screen goes into reverse video for all output and with vi/emacs they fail to guess the size of the screen correctly. See http://dickey.his.com/xterm/xterm.faq.html. Specifically: Reverse video is not reset When running less or other programs that do highlighting, you see the highlighting not turned off properly. This may be due to incompatible terminal descriptions for xterm. With XFree86 3.2, I modified the terminal description for XFree86 xterm to use the VT220 (aka ISO 6429) controls that allow an application to turn off highlighting (or bold, underline) without modifying the other attributes. The X Consortium xterm does not recognize these controls. If, for example, you are running an older xterm and rlogin to a system where the newer xterm has been installed, you will have this problem, because both programs default to $TERM set to xterm. The solution for mixed systems is to install the newer terminal description as as a different name (e.g., xterm-color) and set the termName resource accordingly in the app-defaults file for the system which has the newer xterm. However - see below. What $TERM should I use? The xterm-color value for $TERM is a bad choice for XFree86 xterm because it is commonly used for a terminfo entry which happens to not support bce. Use the xterm-xfree86 entry which is distributed with XFree86 xterm (or the similar one distributed with ncurses). The term bce stands for back color erase. Terminals such as XFree86 xterm and rxvt implement back color erase, others such as dtterm do not. (Roughly half of the emulators that I know about implement bce). When an application clears the screen, a terminal that implements back color erase will retain the last-set background color. A terminal that does not implement back color erase will reset the background color to the default or initial colors. Applications that paint most of the screen in a single color are more efficient on terminals that support back color erase. Curses libraries that support color know about bce and do the right thing - provided that you tell them what the terminal does. That is the whole point of setting $TERM. The xterm-color description distributed with ncurses does not list bce, because it was applied originally to a terminal type which does not implement back color erase. It will work for XFree86 xterm, though less efficient. Some other applications such as the slang library have hardcoded support for terminals that implement back color erase. Given the xterm-color description, those will be efficient - and fortuitously work. However, slang (through version 1.4.0) does not work properly for the terminals that xterm-color was designed for. See this page for an example of (n)curses and slang running on dtterm. That bug in slang is reported to be fixed for succeeding versions, though your application may require changes to use this fix. (The demo which comes with slang to illustrate the use of bce does not work properly, for instance). The xterm-color value for $TERM is also (for the same reason) a bad choice for rxvt, but works due to the large number of hard-coded applications that override this. *** You can use the -tn option to xterm to have it use a different terminal type: -tn name This option specifies the name of the terminal type to be set in the TERM environment variable. This terminal type must exist in the termcap(5) database and should have li# and co# entries. (Of course, a terminfo entry works as well.) Try xterm-r6, perhaps. -- G. Branden Robinson | Debian GNU/Linux| Music is the brandy of the damned. [EMAIL PROTECTED] | -- George Bernard Shaw http://www.debian.org/~branden/ | pgpTiQsutWSyA.pgp Description: PGP signature
Re: /bin/ksh as a default POSIX shell
Manoj Srivastava [EMAIL PROTECTED] wrote:
Herbert == Herbert Xu [EMAIL PROTECTED] writes:
Herbert And this is Debian where we have a policy that says #!/bin/sh
scripts
Herbert need to be POSIX compliant.
What policy says is:
We were talking about echo -ne, not echo -n which ash does understand.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: APT problem
Jason Gunthorpe [EMAIL PROTECTED] writes: On 30 Aug 2000, Alex Romosan wrote: can we please, please reverse the behaviour, or at least make it configurable in /etc/apt/apt.conf, something like PreferLocal yes. if there is such an option and i missed it, please point it out to me. Come up with a reasonable situation where you would want to have a non-held package not be moved to the archive version of the same version but be moved to the newer archive version : if a new version becomes available, i don't mind upgrading. i just don't want apt to upgrade to the archive package if the packages have the same version. i think the ability to set this as a configuration option is best. as for a reasonable situation... let's say i want to compile some packages with pentium optimizations on, but if there is a new version i would like to upgrade automatically. now dselect tells me there is a new version, but if i use apt-get upgrade i won't even know the new version exists. i don't know if you consider the above situation reasonable, but for me it is. this is why i would like to be able to change the current behaviour with an option in apt.conf. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
trouble with portmap on diskless machines
Hi, I have a cluster of diskless machines. I've followed the instructions in the diskless package, and the machines boot up as a result. The diskless package is simply great. I'd spent a whole lot of time making SuSE remote boot and thats what I have to use until i get Debian working properly. NIS doesn't work on the diskless machines. After some looking around, I figured that it was the portmapper that really wasn't working. It shows up in the ps listing, and there are no errors reported during bootup for portmap. But rpcinfo -p localhost says 'RPC: Remote System error - Connection refused' and ypbind says 'Neigbour table overflow'. Please reply straight to me, as I'm not on the list, yet. viral
Big Thankx!
I just wanted to thank you guys! I run Debian at work, one gateway and one server. Debian Slink 2.1 Today I upgraded to Potato, upgrade went almost perfectly except that Samba 2.0.7 was not compatible with a 2.0.36 kernel. :-( Maybe i just didn't read the docs. This night I upgraded the kernel to 2.2.17. Everything worked worked perfect again (also samba 2.0.7) (I have to check X.) I ordered a dell poweredge 2400 with a 4*18Gb raid-5, 128Mb RAM file server. I will install potato in it. YES Also at home. Nothing but Champagne! Yesterday I connected a apple to the network, even a apple was no problemo. Again Thanx! Ries van twisk
Bug#70634: Typo in policy manual
Package: debian-policy Version: 3.2.1.0 On 2830T184956-0400, Matt Zimmerman wrote: On Wed, Aug 30, 2000 at 08:51:47PM +0300, Antti-Juhani Kaijanaho wrote: The definition is the following: It is not be necessary to explicitly specify build-time relationships on a minimal set of packages that are always needed to compile, link and put in a Debian package a standard Hello World! program written in C or C++. The required packages are called _build-essential_, and an informational list can be found in `/usr/share/doc/build-essential/list' (which is contained in the `build-essential' package). (Debian Policy v. 3.2.1.0, section 2.4.2.) I can't find a bug open regarding the obvious grammatical error at the beginning of this paragraph (It is not be). Is someone aware of it nonetheless? I imagine it should read It is not necessary -- - mdz Why didn't you file the bug then? (I believe it originally said it will not be and then somebody edited it.)
Re: Pre-ITA: ntop
Oliver M . Bolzer [EMAIL PROTECTED] writes: # BTW, is there any docu on how to properly operete the new WNPP ? See http://www.debian.org/devel/wnpp/ Marcelo
Re: imap mailbox killer
On Thu, 31 Aug 2000, +00:52:25 EEST (UTC +0300), Cristian Ionescu-Idbohrn [EMAIL PROTECTED] pressed these keys: Package: imap Version: 4.7c-1 (Juhapekka Tolvanen's messages may be found on these mailing lists: debian-devel@lists.debian.org,debian-legal@lists.debian.org) Man, you got great headers on your messages! Maybe the problem is caused by my X-Keywords-header, that serves as spook line (Hello, NSA! :-) ). I shortened it. Do you still have that problem? There might be bug in either Pine or IMAP(D) or both. -- Juhapekka naula Tolvanen * * * U of Jyväskylä * * [EMAIL PROTECTED] http://www.cc.jyu.fi/~juhtolv/index.html * STRAIGHT BUT NOT NARROW! - so impressed with all you do. tried so hard to be like you. flew too high and burnt the wing. lost my faith in everything nine inch nails
Re: .bashrc (ls --color=auto setting)
On Wed 30 Aug 2000, Wichert Akkerman wrote: Previously Paul Slootman wrote: Then you must have some other arrangement to get the colors; it's not enabled by default. Try a fresh install (I have). Maybe a direct setting of LS_COLORS in your .bash_profile or whatever? Nope: [tornado;~/cistron]-15 env|grep LS zsh: done env | zsh: exit 1 grep LS OK, so no setting of LS_COLORS. I have ls aliased to 'ls --color=auto', which works great. Ah, so you *do* have some other arrangement to get the colors. So why did you write nope as your first response (which would imply an response to my first statement)? Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/
ITP: erb, libiconv-ruby, libintl-gettext-ruby, liblv-ruby, libmhash-ruby, libnet-irc-ruby, libsnmp-ruby, libzlib-ruby, libsyslog-ruby
I intent to some packages -- erb, libiconv-ruby, libintl-gettext-ruby, liblv-ruby, libmhash-ruby, libnet-irc-ruby, libsnmp-ruby, libzlib-ruby and libsyslog-ruby. erb: Yet another implementation of eRuby. It is written as pure Ruby script. License: Ruby's (see below) libiconv-ruby: This is wrapper class of iconv for the Ruby, which translates string between various coding systems. License: LGPL libintl-gettext-ruby: A simple wrapper of GNU gettext for ruby. License: LGPL liblv-ruby: This is a ruby extention library for converting text encoding with text viewer LV. (LV is already packaged and installed into Woody by GOTO Masanori san.) License: GPL libmhash-ruby: A simple wrapper of mhash library. License: Ruby's (see below) libnet-irc-ruby: This is a Ruby library for IRC (Internet Relay Chat) and consists of low-level communication library and client framework. License: Ruby's (see below) libsnmp-ruby: Ruby SNMP is UCD-SNMP library interface for the Ruby. A current version is 0.2.1 (unstable), only supporting SNMP protocols are SNMPv1 GET, GETNEXT reqest. License: Ruby's (see below) libzlib-ruby: The extension library to use zlib from Ruby. Ruby/zlib also provides the features for accessing gzipped files. License: Ruby's (see below) libsyslog-ruby: Ruby interface to the UNIX syslog(3) calls. License: Ruby's (see below) Ruby's License: Ruby is copyrighted free software by Yukihiro Matsumoto [EMAIL PROTECTED]. You can redistribute it and/or modify it under either the terms of the GPL (see COPYING file), or the conditions below: 1. You may make and give away verbatim copies of the source form of the software without restriction, provided that you duplicate all of the original copyright notices and associated disclaimers. 2. You may modify your copy of the software in any way, provided that you do at least ONE of the following: a) place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or by allowing the author to include your modifications in the software. b) use the modified software only within your corporation or organization. c) rename any non-standard executables so the names do not conflict with standard executables, which must also be provided. d) make other distribution arrangements with the author. 3. You may distribute the software in object code or executable form, provided that you do at least ONE of the following: a) distribute the executables and library files of the software, together with instructions (in the manual page or equivalent) on where to get the original distribution. b) accompany the distribution with the machine-readable source of the software. c) give non-standard executables non-standard names, with instructions on where to get the original software distribution. d) make other distribution arrangements with the author. 4. You may modify and include the part of the software into any other software (possibly commercial). But some files in the distribution are not written by the author, so that they are not under this terms. They are gc.c(partly), utils.c(partly), regex.[ch], fnmatch.[ch], glob.c, st.[ch] and some files under the ./missing directory. See each file for the copying condition. 5. The scripts and library files supplied as input to or produced as output from the software do not automatically fall under the copyright of the software, but belong to whomever generated them, and may be sold commercially, and may be aggregated with this software. 6. THIS SOFTWARE IS PROVIDED AS IS AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Re: Bug#70269: automatic build fails for potato
On Wed, Aug 30, 2000 at 01:06:30PM -0500, Steve Greenland wrote: Which is just a stupid pain in the ass. I had to track through three different references and finally install the build-depends package to find out what I could leave out of by Build-Depends stanza. It would *much* easier for developers, if less ideologically pure, to just list the damn packages on the Developers Corner part of the website. Could we add this as a footnote to the relevant section in policy or the packaging manual (can't remember which offhand)? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: imap mailbox killer
Sorry I couldn't answer yout letters earlier. I had to repair my mailbox. I also had to involve and help the system administrators to go through all the IMAP mailboxes and filter out all the messages with suspect headers. Looks better now, thanks. I don't know much about the IMAP intrinsics, but here is the story of what happend (comming from an uninitiated user ;-). Looks like all boxes get an extra message inserted. It looks something like this: ,- | From MAILER-DAEMON Wed Aug 30 09:54:25 2000 | Delivery-Date: Thu May 11 21:51:47 2000 | Date: Thu, 11 May 2000 21:51:47 +0200 (MET DST) | From: Mail System Internal Data [EMAIL PROTECTED] | Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA | X-IMAP: 0928135936 033614 | Status: RO | X-Status: | X-Keywords: | X-UID: 2 | | This text is part of the internal format of your mail folder, and is not | a real message. It is created automatically by the mail system software. | If deleted, important folder data will be lost, and it will be re-created | with the data reset to initial values. `- I don't know if it's the IMAP daemon or the pine client who is responsible for this. One (or several) of Juhapekka message header entries, probably this: ,- | X-Keywords: =?iso-8859-1?Q?kettutyt=F6t=2C_Sanna_Sillanp=E4=E4=2C_IKL=2C_Jammu_Silta?= | =?iso-8859-1?Q?vuori=2C_ryss=E4=2C_somali=2C_lesbo=2C_homo=2C_lesbian=2C?= | =?iso-8859-1?Q?_anarchism=2C_nazi=2C_communism=2C_CIA=2C_bomb=2C_nuclear?= | =?iso-8859-1?Q?=2C_Semtex=2C_satan=2C_traitor=2C_pedophile?= `- caused the daemon (or the client) screw up the magic. I ended up with a magic message looking like this: ,- | From MAILER-DAEMON Wed Aug 30 16:36:48 2000 | Date: 30 Aug 2000 16:36:48 +0200 | From: Mail System Internal Data [EMAIL PROTECTED] | Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA | Message-ID: [EMAIL PROTECTED] | X-IMAP: 0967646162 000339 =?iso-8859-1?Q?kettutyt=F6t=2C_Sanna_Sillanp=E4=E4=2C_IKL=2C_Jammu_Silta?= | Status: RO | | This text is part of the internal format of your mail folder, and is not | a real message. It is created automatically by the mail system software. | If deleted, important folder data will be lost, and it will be re-created | with the data reset to initial values. `- and a lot of NULL characters preceeding a few (5-6) of the messages in some boxes. Hope this helps to find the problem. There's definitely a BUG lurking somewhere. Cheers, Cristian On Thu, 31 Aug 2000, Juhapekka Tolvanen wrote: On Thu, 31 Aug 2000, +00:52:25 EEST (UTC +0300), Cristian Ionescu-Idbohrn [EMAIL PROTECTED] pressed these keys: Package: imap Version: 4.7c-1 (Juhapekka Tolvanen's messages may be found on these mailing lists: debian-devel@lists.debian.org,debian-legal@lists.debian.org) Man, you got great headers on your messages! Maybe the problem is caused by my X-Keywords-header, that serves as spook line (Hello, NSA! :-) ). I shortened it. Do you still have that problem? There might be bug in either Pine or IMAP(D) or both. -- I respect faith, but doubt is what gets you an education. -- Wilson Mizner
Re: .bashrc (ls --color=auto setting)
From: Wichert Akkerman [EMAIL PROTECTED] Subject: Re: .bashrc (ls --color=auto setting) Date: Wed, 30 Aug 2000 21:52:18 +0200 [tornado;~/cistron]-15 env|grep LS zsh: done env | zsh: exit 1 grep LS I have ls aliased to 'ls --color=auto', which works great. Well, the arguments become too complicated or technical for me so I only tested the above comment. Yes 'ls --color=auto' works without setting of LS_COLORS but colors are bit different from those with setting of LS_COLORS. Only FYI. Best Regards, 2000.8.31 -- Debian JP Developer - much more I18N of Debian Atsuhito Kohda [EMAIL PROTECTED] Department of Math., Tokushima Univ.
Re: trouble with portmap on diskless machines
On Thu, Aug 31, 2000 at 11:29:06AM +0530, [EMAIL PROTECTED] wrote: NIS doesn't work on the diskless machines. After some looking around, I figured that it was the portmapper that really wasn't working. It shows up in the ps listing, and there are no errors reported during bootup for portmap. But rpcinfo -p localhost says 'RPC: Remote System error - Connection refused' and ypbind says 'Neigbour table overflow'. That may mean something's wrong with the loopback interface. Does ifconfig lo up help anything? Wouter
Re: imap mailbox killer
On Thu 31 Aug 2000, Cristian Ionescu-Idbohrn wrote: caused the daemon (or the client) screw up the magic. I ended up with a magic message looking like this: ,- | From MAILER-DAEMON Wed Aug 30 16:36:48 2000 | Date: 30 Aug 2000 16:36:48 +0200 | From: Mail System Internal Data [EMAIL PROTECTED] | Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA | Message-ID: [EMAIL PROTECTED] | X-IMAP: 0967646162 000339 =?iso-8859-1?Q?kettutyt=F6t=2C_Sanna_Sillanp=E4=E4=2C_IKL=2C_Jammu_Silta?= | Status: RO | | This text is part of the internal format of your mail folder, and is not | a real message. It is created automatically by the mail system software. | If deleted, important folder data will be lost, and it will be re-created | with the data reset to initial values. `- and a lot of NULL characters preceeding a few (5-6) of the messages in some boxes. Yuck. Smells like a serious buffer overflow somewhere. This needs to be fixed fast. Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/
Re: imap mailbox killer
Package: imap Version: 4.7c-1 Severity: important On Thu 31 Aug 2000, Paul Slootman wrote: Yuck. Smells like a serious buffer overflow somewhere. Upon a quick glance, there indeed appears to be no checks at all for buffer overflows. A buf of 8k is allocated into which the From:, Status:, X-Status, and X-Keywords: headers are placed, with simple sprintf (buf + strlen (buf),... commands. So having extremely long X-Keywords in mail messages will screw things up. Double yuck. This is in imap-4.7c/src/osdep/unix/unix.c BTW. See the original message and the accompanying thread in debian-devel, archive/latest/67244 , Message-ID [EMAIL PROTECTED] from Cristian Ionescu-Idbohrn [EMAIL PROTECTED] Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/
Re: dpkg-scanpackages arguments, output Packages files, and apt
Eray Ozkural [EMAIL PROTECTED] wrote:
This was what I had to write to make a Packages file in a flat dir:
[EMAIL PROTECTED]:~/public_html/debian$ dpkg-scanpackages . override ./
Packages
You don't have to supply a third argument.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: trouble with portmap on diskless machines
viral == viral [EMAIL PROTECTED] writes: viral NIS doesn't work on the diskless machines. After some viral looking around, I figured that it was the portmapper that viral really wasn't working. It shows up in the ps listing, and viral there are no errors reported during bootup for portmap. I am not sure if this is relevant or not (the error is different to what I would have expected), however I haven't been able to get the pure Debian version of NIS working on diskless systems. See bug #48628. I submitted a patch about this years ago, but for some reason it was later removed. It is easy to fix in the source code (IIRC: modify the if condition to test if F_GETLK returns the PID of the current process), but am not sure if this is the current fix or not. -- Brian May [EMAIL PROTECTED]
Re: imap mailbox killer
Package: imap Version: 4.7c-1 Severity: important On Thu 31 Aug 2000, Paul Slootman wrote: Yuck. Smells like a serious buffer overflow somewhere. Upon a quick glance, there indeed appears to be no checks at all for buffer overflows. A buf of 8k is allocated into which the From:, Status:, X-Status, and X-Keywords: headers are placed, with simple sprintf (buf + strlen (buf),... commands. So having extremely long X-Keywords in mail messages will screw things up. Double yuck. This is in imap-4.7c/src/osdep/unix/unix.c BTW. See the original message and the accompanying thread in debian-devel, archive/latest/67244 , Message-ID [EMAIL PROTECTED] from Cristian Ionescu-Idbohrn [EMAIL PROTECTED] This definately needs to be passed upstream... My mailbox was screwed up as well, and I get my mail from a Solaris box, not a Debian one. Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Buddha Buck [EMAIL PROTECTED] Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects. -- A.L.A. v. U.S. Dept. of Justice
Re: imap mailbox killer
On Thu, Aug 31, 2000 at 07:32:17AM -0400, Buddha Buck wrote: commands. So having extremely long X-Keywords in mail messages will screw things up. Double yuck. This is in imap-4.7c/src/osdep/unix/unix.c BTW. See the original message and the accompanying thread in debian-devel, archive/latest/67244 , Message-ID [EMAIL PROTECTED] from Cristian Ionescu-Idbohrn [EMAIL PROTECTED] This definately needs to be passed upstream... My mailbox was screwed up as well, and I get my mail from a Solaris box, not a Debian one. My mailbox didn't get screwed up (thank god..) but I did get some very confused messages from Mutt. I though mutt was at fault, but evidently it was imapd... Jules
Re: APT problem
On Thu, Aug 31, 2000 at 06:36:34AM +0200, Bernd Eckenfels [EMAIL PROTECTED] was heard to say: On Wed, Aug 30, 2000 at 05:37:52PM -0400, Daniel Burrows wrote: (especially since this looks like just the well-established behavior of downloading changed packages..) I dont have a example right now, but on my system aptitude will download the same package again and again. So in case it sees a difference must be related two different sources provide the same package entry. then it downloads the pakcage from one source and compares it with the entry of another source. Hmm.. i will watch the problems and report them. Ok, between this and another message sent to me, I think that the problem is that aptitude doesn't clear sticky reinstall flags, and must be autoflagging stuff for reinstall when this occur. This doesn't have a really great solution, since you can't (easily) tell whether a reinstall was successful after the fact, but I could just unconditionally clear the reinstall flag for now; I doubt many people use it manually. In the future, I suppose a fancy system for detecting reinstallations is possible, but it might be more trouble than it's worth. Daniel -- /- Daniel Burrows [EMAIL PROTECTED] -\ | f u cn rd ths, | Apostrophes are not a warning that a | | u cn gt a jb s | word is about to end in an s.| | a cmptr prgrmr. | | \-Evil Overlord, Inc: planning your future today. http://www.eviloverlord.com-/
Re: Bug#70269: automatic build fails for potato
Steve == Steve Greenland [EMAIL PROTECTED] writes: Steve Are you saying that someone running a build daemon is not Steve going to keep up-to-date on build-essential packages? Why not? Steve And if not, why is my (the maintainer's) job to keep changing Steve the version numbers in my control file to force it to happen? Firstly, build essential package is ot merrely for build daemaons. Therefore packages would need to specify the oldest version of the build package they can be built with (in the worst case, exactly the version they were built with), since not every machine they can be built on can be depended to ahve the altest version of the helper packages. Indeed, none of may machines have _any_ helper packages installed. I think that since every package using a helper package seems to need a versioned dependency, addign debhelper to build essential shall not remove the burden from the packages. And auto build daemons can also augment the build environment beyond build essential, as they already do. Am I missing the mark here? manoj -- Just go ahead and write your own multitasking multiuser os! Worked for me all the times. Linus Torvalds Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: BTS not showing my bugs
On Wed, Aug 30, 2000 at 04:57:51PM -0700, Joey Hess wrote: All statically updated BTS pages are broken, please see DWN for details. Might it be an idea to put a notice about this on the web page? It'd avoid a lot of confusion. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpaWRJ983UwX.pgp Description: PGP signature
Re: Bug#70269: automatic build fails for potato
On Tue, Aug 29, 2000 at 10:37:01PM -0500, Branden Robinson wrote: Purists happen to be whoever disagrees with Hamish Moffat. Cf. his rhetoric here with his rhetoric in the great Social Contract amendment flamewar. Perhaps you should stick with your one liners, Branden. Your three-liners aren't much better, and take more effort to read. By the way, please watch your spelling. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: imap mailbox killer
At 08:21 AM 8/31/00 -0400, Richard A Nelson wrote: On Thu, 31 Aug 2000, Juhapekka Tolvanen wrote: There might be bug in either Pine or IMAP(D) or both. Both... I had to manually delete several messages in Pine 4.21 folders and I don't use IMAP I don't use pine or imap, but the school hosting my mailbox uses imap. The behavior I saw: Using POP to copy new mail to my workstation at work (running Eudora) seemed to cause ipop3d to crash without properly cleaning up -- $MAIL.lock still around, messages not marked as old, etc. Telnetting in, and mucking around in $MAIL by hand revealed the messages preceeded by nulls. Elm read the mailbox fine, but treated the messages preceeded by nulls as continuations of the previous messages. Eudora, getting the messages from POP3, also read the messages fine, but again with the broken messages tacked on to the preceeding messages. Manually deleting the nulls wasn't a reliable way to fix the problem. My school uses imap, but I didn't -directly- invoke it in this process. It may have been invoked by their mailer behind the scenes, though.
Re: Security of Debian SuX0r?
Bob Bernstein [EMAIL PROTECTED] writes: So there's a warning? At least MD5 *can* be implemented at install-time. Why doesn't he mention that Caldera for one doesn't even offer MD5 as an _option_ at install-time? Next: What Caldera do doesn't matter at all. Neither does it matter what anyone else does. Debian should just be a reliable (securitywise) distibution which is safe to use if you not clueless. I've just helped a friend instaling Debian. He had two comment about the above question. Is it the red or blue button there is active? It is badly marked which button you are about the press. The other comment is something about the wording of two of the questions. The firste question was saying something like Do you want to keep the standard (less secure) option and the next question said Would you use the new (more secure) option. If the user just thinks that he wants the most secure box but not really reading precisly what it says he will say no to both questions. (That was what we did). I don't really remember which questions it was, but I'm almost sure one of them was the MD5 password question. -- Peter
Re: Security of Debian SuX0r?
Peter Makholm writes: I've just helped a friend instaling Debian. He had two comment about the above question. Is it the red or blue button there is active? It is badly marked which button you are about the press. You know, that *has* been bugging me... However you can use the cursor to figure it out (unless your terminal is weird, I suppose). Is this hardcoded into dialog, or could the appearance be configured by debconf at runtime? -- There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)
Confusing Red/Blue buttons (was: Security of Debian SuX0r?)
Peter Makholm writes: I've just helped a friend instaling Debian. He had two comment about the above question. Is it the red or blue button there is active? It is badly marked which button you are about the press. On Thu, 31 Aug 2000, Decklin Foster wrote: You know, that *has* been bugging me... However you can use the cursor to figure it out (unless your terminal is weird, I suppose). It bugs me too. Is this hardcoded into dialog, or could the appearance be configured by debconf at runtime? Perhaps the underscore attribute could be set in addition to highlighting for the currently selected option? Of course, I'm totally ignorant of the actual implementation, so perhaps there is some reason this is difficult to accomplish. Ben -- nSLUG http://www.nslug.ns.ca [EMAIL PROTECTED] Debian http://www.debian.org [EMAIL PROTECTED] [ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ] [ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
Where's the prc-tools package?
It's still mention in Suggests: etc. but the package is not listed in the Packages files anymore. Just a temporary situation or a real problem? Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: Crazy idea: removing version numbers from debian
Thank you for your answers. Some misunderstood my idea, I don't want to remove version numbers from packages. Bernd: How do u call slink? Old Stable? :) Yes, old_stable or past Bernd: No i think it is not a bad idea to have a version number. The only question is if the Version number should cover the whole distribution (including contrib, non-free, non-US,...) or only the base section (like with FreeBSD). Yes, that what I had in mind, too. I would apply 2.2 only to the base section and the other packages should keep their version numbers. Vincent: New packages would not be allowed into stable until x days had passed in unstable status without a Release Critical Bug. What about a doing things like this on a feedback basis? After a package was installed on your computer successfully, you get asked if you want to send a sucess-feedback. After N positiv feedbacks the package gets stable. Vincent: Finally the idea I like the best is no numbers, only named updates I think you still need to distinguish between foo_pack1.2-stable1 foo_pack1.2-stable2 Eric: Better yet, don't put packages into stable until we release. Stable has a fairly well-defined meaning; I don't see much benefit from changing it. I am new to debian-dev, why not release stable packages daily? Why in a single step? Colins: Those who do not understand ajt's testing distribution are doomed to reinvent it, poorly. :) OK, I will RTFM, I hope there is some. Wichert: Also, having versioned released is something that CD vendors want to have. If we only had an ever changing semi-stable they could only sell snapshots, which means they can't produce a large number of CDs, costs will go up and they will switch to selling CDs of other distributions instead. That's true. One solution would be to give the boot-floppies and related things the version number 2.2. The rest could be floating. BTW, I even think the CD-Vendors would sell more CDs with a floating system. I ordered Debian 2.2 in january, now it's nearly september. If I would have got them at once, I would maybe buy my next CDs now (don't like downloading netscape with a modem connection). -- Thomas Guettler Office: guettli_NoSpam_interface-business.de www.interface-business.de Private:guettli_NoSpam_gmx.de http://yi.org/guettli (Replace _NoSpam_ with @)
Re: Security of Debian SuX0r?
On Thu, Aug 31, 2000 at 10:03:04AM -0400, Decklin Foster [EMAIL PROTECTED] was heard to say: Peter Makholm writes: I've just helped a friend instaling Debian. He had two comment about the above question. Is it the red or blue button there is active? It is badly marked which button you are about the press. You know, that *has* been bugging me... However you can use the cursor to figure it out (unless your terminal is weird, I suppose). Is this hardcoded into dialog, or could the appearance be configured by debconf at runtime? I know that joeyh has been working on a much nicer-looking slang frontend which doesn't suffer from this problem; maybe we can just ditch dialog eventually and use that? Daniel -- /- Daniel Burrows [EMAIL PROTECTED] -\ | This space |Hi, I'm a .signature virus!| |intentionally|Copy me into your .signature to help me spread!| | left blank. | | \ Real Programmers don't have braces. -- http://www.python.org ---/
Re: APT problem
On Wed, Aug 30, 2000 at 09:57:38PM +0200, Wichert Akkerman wrote: It means the libc6 package you have installed has a different md5sum then the package it finds on ftp.corel.com, and assumes that the version on ftp.corel.com is a newer recompile. Strange logic, but that is how Which of course is correct. Not only the md5sum is different but also the filesize. Wonder what they did with the source. Thanks. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: APT problem
On Wed, Aug 30, 2000 at 02:47:15PM -0600, Jason Gunthorpe wrote: What needs to be done is diff the record from the corel package file against what is in their .deb and see if there is a difference in any fields. Yup, md5sum and size. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: Where's the prc-tools package?
On Thu, Aug 31, 2000 at 04:32:38PM -0700, Michael Meskes wrote: It's still mention in Suggests: etc. but the package is not listed in the Packages files anymore. Just a temporary situation or a real problem? prc-tools (0.5.0r-3.1) frozen; urgency=low * NMU * Specify the archs (excluding sparc), closes: #51647 * Only uploading source, since I can't build on sparc, and only to frozen -- Ben Collins [EMAIL PROTECTED] Fri, 17 Mar 2000 11:23:04 -0700 dinstall has a bug where if it gets uploaded to frozen it gets removed from unstable... Someone just needs to re-uploaded a recompiled version for woody. -- Brian M. Almeida Linux Systems Engineer | http://www.winstar.com | [EMAIL PROTECTED] Debian Developer | http://www.debian.org | [EMAIL PROTECTED] -- Bosnia Marxist smuggle Soviet munitions explosion Watergate Noriega JFK domestic disruption radar cypherpunk Mena militia Vince Foster spy Serbian Rule Psix security ECHELON
Re: Where's the prc-tools package?
Previously Michael Meskes wrote: It's still mention in Suggests: etc. but the package is not listed in the Packages files anymore. Just a temporary situation or a real problem? Someone *really* needs to NMU that package again and bring it up to date, the current version is ancient and can't even compile PalmIII apps. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: APT problem
On Thu 31 Aug 2000, Michael Meskes wrote: Which of course is correct. Not only the md5sum is different but also the filesize. Wonder what they did with the source. It doesn't take much to create a different filesize. E.g. different timestamps in the archive will lead to different compression behaviour, hence different sizes. Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/
Re: Bug#70269: automatic build fails for potato
Previously Manoj Srivastava wrote: I think that since every package using a helper package seems to need a versioned dependency, addign debhelper to build essential shall not remove the burden from the packages. And auto build daemons can also augment the build environment beyond build essential, as they already do. Right. In fact it makes things worse since people will just assume that their helper is already essential and they don't need to bother to to check if they need to specify a versioned dependency for it as well. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Bug#70269: automatic build fails for potato
On 31-Aug-00, 07:18 (CDT), Manoj Srivastava [EMAIL PROTECTED] wrote: Firstly, build essential package is ot merrely for build daemaons. No, but I think that's the primary reason for it's existence. If it was mainly for humans, it would be sufficient to have checks in the in debian/rules, or a list of required packages somewhere in README.Debian. Therefore packages would need to specify the oldest version of the build package they can be built with (in the worst case, exactly the version they were built with), since not every machine they can be built on can be depended to ahve the altest version of the helper packages. So I'm supposed to go back and figure out if my packages can be successfully built with debhelper 2.0.58? If so, how can I -- is there a complete archive of all released debhelpers somewhere? I don't think this is going to happen. Instead, I'll just (probably automatically) update my build-depends line to the version of debhelper that's installed on my machine. So the de-facto requirement is going to be a nearly current version of debhelper. The same is true for the build-essential packages -- nobody is going to go back and check their stuff against old versions of gcc and make. Admittedly, those are much slower moving targets...but dpkg-dev isn't, necessarily. Indeed, none of may machines have _any_ helper packages installed. But you're not running a build daemon, or otherwise trying to build a significant number of packages from source. People doing so are the consumers of Build-depends. If you were, I don't think you'd object to being expected to having a helper package installed (well, you might object, but the helper packages *are* a reality, and *are* widely used). I think that since every package using a helper package seems to need a versioned dependency, addign debhelper to build essential shall not remove the burden from the packages. Mine don't. Or rather, the version needed is sufficiently old that I have no idea what it might be. Hmmm, let me ammend that. To comply with *current* policy, I need a (nearly) *current* version of debhelper. But my package builds won't fail with an older version, and someone with an older version is probably running an old system under old policy. One could argue that this is a *good* thing -- if someone wants to build a woody+1 version of cron on slink, isn't it better that they get slink-consistent handling of /usr/doc vs. /usr/share/doc? And auto build daemons can also augment the build environment beyond build essential, as they already do. Of course. My point is *exactly* that any build daemon (or other significant beneficiary of build-depends) *must* have debhelper installed, so why not make it build-essential? Am I missing the mark here? I think we may just have to different conclusions from the same base facts. This is not necessarily unreasonable. In particular, I don't buy into the debhelper requires versioned dependencies argument. I think *if* a package needs a specific version of debhelper it would be fine to put it into the build-depends list. I also think it's reasonable to say the current version of debhelper is build-essential. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Crazy idea: removing version numbers from debian
Previously Thomas Guettler wrote: Eric: Better yet, don't put packages into stable until we release. Stable has a fairly well-defined meaning; I don't see much benefit from changing it. We already do that. I am new to debian-dev, why not release stable packages daily? Why in a single step? Because you can't test the new complete system that way. That's true. One solution would be to give the boot-floppies and related things the version number 2.2. The rest could be floating. That won't help much, you still have an essentialy completely floating system except for a really smart part. BTW, I even think the CD-Vendors would sell more CDs with a floating system. Maybe, but their margins would be too small to make it viable. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Testing packages: Smurf and libsndfile
pgpWxQNs9EwTi.pgp Description: PGP message
Re: BTS not showing my bugs
Brian May wrote: From URL:http://www.debian.org/Bugs/, click on Index of maintainers of packages with bug reports., and then Brian May [EMAIL PROTECTED] takes you to: URL:http://www.debian.org/Bugs/db/ma/lBrian_May,bam,debian.org,.html Why is bug #69807, for my diskless-image-secure package not shown??? Try: http://bugs.debian.org/[EMAIL PROTECTED] Peter
Re: imap mailbox killer
[Please Cc [EMAIL PROTECTED] on any replies to this thread.] On Thu, 31 Aug 2000, Buddha Buck wrote: I don't use pine or imap, but the school hosting my mailbox uses imap. The behavior I saw: Using POP to copy new mail to my workstation at work (running Eudora) seemed to cause ipop3d to crash without properly cleaning up -- $MAIL.lock still around, messages not marked as old, etc. Telnetting in, and mucking around in $MAIL by hand revealed the messages preceeded by nulls. Elm read the mailbox fine, but treated the messages preceeded by nulls as continuations of the previous messages. Eudora, getting the messages from POP3, also read the messages fine, but again with the broken messages tacked on to the preceeding messages. Manually deleting the nulls wasn't a reliable way to fix the problem. Thanks for the description, I found it very useful. My school uses imap, but I didn't -directly- invoke it in this process. It may have been invoked by their mailer behind the scenes, though. Not necessarily. However ipop3d and imapd both use the c-client library for all the mail handling routines. That's where the bug is so both would have been affected. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: imap mailbox killer
[Please Cc [EMAIL PROTECTED] on any replies to this thread.] On Thu, 31 Aug 2000, Richard A Nelson wrote: There might be bug in either Pine or IMAP(D) or both. Both... I had to manually delete several messages in Pine 4.21 folders and I don't use IMAP Pine also uses libc-client which is where the bug is. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: imap mailbox killer
Funny side effect of the bug, here is the new magic message in my mailbox :-) Check out the X-IMAP: entry: ,- | From MAILER-DAEMON Thu Aug 31 17:15:15 2000 | Date: 31 Aug 2000 17:15:15 +0200 | From: Mail System Internal Data [EMAIL PROTECTED] | Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA | Message-ID: [EMAIL PROTECTED] | X-IMAP: 0967708347 84 lesbo, homo, lesbian, anarchism, nazi, communism, CIA, bomb, nuclear, Semtex, satan, traitor, pedophile | Status: RO | | This text is part of the internal format of your mail folder, and is not | a real message. It is created automatically by the mail system software. | If deleted, important folder data will be lost, and it will be re-created | with the data reset to initial values. `- Cheers, Cristian -- I respect faith, but doubt is what gets you an education. -- Wilson Mizner
Re: imap mailbox killer
On Thu, 31 Aug 2000, Paul Slootman wrote: On Thu 31 Aug 2000, Paul Slootman wrote: Yuck. Smells like a serious buffer overflow somewhere. Upon a quick glance, there indeed appears to be no checks at all for buffer overflows. A buf of 8k is allocated into which the From:, Status:, X-Status, and X-Keywords: headers are placed, with simple sprintf (buf + strlen (buf),... commands. So having extremely long X-Keywords in mail messages will screw things up. Double yuck. This is in imap-4.7c/src/osdep/unix/unix.c BTW. See the original message and the accompanying thread in debian-devel, archive/latest/67244 , Message-ID [EMAIL PROTECTED] from Cristian Ionescu-Idbohrn [EMAIL PROTECTED] Ok, I've patched unix.c to use snprintf(3) instead of sprintf(3). This is only the tip of the iceberg however. There is a source code scanner called its4 which checks for unsafe coding practices and I ran it on imapd. The report was about a mile long :( Oddly enough I read that message and wasn't affected even though I use pine 4.21 and imapd. -- Jaldhar H. Vyas [EMAIL PROTECTED]
netscape 4.75 in security.debian.org is broken
Package: communicator Version: 1:4.75-1 Severity: grave I've updated communicator from security.d.o's potato packages. I had to erase my preferences in ~/.netscape because it refused to save new settings and when launched it was always like the first time with box with license. I've lost cache, proxy, smart browsing, default page, fonts settings. I've lost all application section, netscape wants to see images with xv (all types, jpg, gif and png included). I set again correctly for jpg and gif, but no results with png. Plugin do not work, in application section I can't use it. I've lst all my settings for them. -- System Information Debian Release: 2.2 Architecture: i386 Kernel: Linux kgb 2.2.10 #1 Sat Sep 4 15:23:05 CEST 1999 i586 Versions of packages communicator depends on: ii communicator-smotif-475 4.75-1 Netscape Communicator 4.75 (static ii netscape-java-475 4.75-1 Netscape Java support for version
Re: netscape 4.75 in security.debian.org is broken
Christian Surchi ([EMAIL PROTECTED]) wrote: Package: communicator Version: 1:4.75-1 Severity: grave I've updated communicator from security.d.o's potato packages. I had to erase my preferences in ~/.netscape because it refused to save new settings and when launched it was always like the first time with box with license. I've lost cache, proxy, smart browsing, default page, fonts settings. I've lost all application section, netscape wants to see images with xv (all types, jpg, gif and png included). I set again correctly for jpg and gif, but no results with png. Plugin do not work, in application section I can't use it. I've lst all my settings for them. not to mention that text/plain is displayed with vim! -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED]
Need a gateway guru
I'm looking for someone to help me add a section to my newest Debian book (which will be released under the GFDL BTW) that covers gateway configuration. My primary problem is that I know next to nothing about how this is accomplished, which makes it pretty hard to write about it ;-) Some of the steps are obvious, but I'm not at all clear on how to accomplish the routing correctly, nor any of the other details. I have a LAN and a machine to make the PPP connection, so I have an adequate test bench. (one of the machines on the LAN is Win98, so I even have some diversity ;-) The only payment I can make is your name on the credits page, and my many thanks. If that is sufficient, please let me know so we can get started. I'm trying to finish writing by next week, so time is short... Waiting is, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: netscape 4.75 in security.debian.org is broken
On Thu, Aug 31, 2000 at 12:18:54PM -0400, Jacob Kuntz wrote: not to mention that text/plain is displayed with vim! All associated following mailcap I think, and it's impossible to handle text/* with navigator too. :( -- Christian Surchi | [EMAIL PROTECTED] | [EMAIL PROTECTED] FLUG: http://www.firenze.linux.it | Debian GNU/Linux: http://www.debian.org - http://www.firenze.linux.it/~csurchi -- Help me, I'm a prisoner in a Fortune cookie file!
Re: Bug#70269: automatic build fails for potato
On 2830T234249+0100, Julian Gilbey wrote: On Wed, Aug 30, 2000 at 01:06:30PM -0500, Steve Greenland wrote: Which is just a stupid pain in the ass. I had to track through three different references and finally install the build-depends package to find out what I could leave out of by Build-Depends stanza. It would *much* easier for developers, if less ideologically pure, to just list the damn packages on the Developers Corner part of the website. Could we add this as a footnote to the relevant section in policy or the packaging manual (can't remember which offhand)? Um, the current note in policy manual is not sufficient? (It explicitly mentions the package build-essential.) -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Hypertekstivisionääri Ted Nelson luennoi Jyväskylässä 29.-31.8. Lisätietoja saa minulta.
NFSMounting
How I get NFS to mount at bootup? - Khisar Paika Albuquerque, NM 505-277-0808
Re: Where's the prc-tools package?
Yes, and while you're at it, please close some bugs :-) I gave that package away two years ago when I moved to alpha and I'm still getting bug reports for it. Somebody else can take it if it's being ignored (in fact, please do). -- John Wichert Akkerman [EMAIL PROTECTED] writes: Previously Michael Meskes wrote: It's still mention in Suggests: etc. but the package is not listed in the Packages files anymore. Just a temporary situation or a real problem? Someone *really* needs to NMU that package again and bring it up to date, the current version is ancient and can't even compile PalmIII apps. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- John Goerzen [EMAIL PROTECTED] www.complete.org Sr. Software Developer, Progeny Linux Systems, Inc.www.progenylinux.com #include std_disclaimer.h [EMAIL PROTECTED]
Re: Where's the prc-tools package?
Previously John Goerzen wrote: Yes, and while you're at it, please close some bugs :-) I gave that package away two years ago when I moved to alpha and I'm still getting bug reports for it. What prevents you from maintaining it on alpha? Wichert. -- _ / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: MANA - Free Pine? yet another dead mailer/newsreader?
For your amusement: http://ftp-master.debian.org/~sanvila/mana If upstream maintainers tell me this is alive, I'll upload it (for project/experimental first). Thanks.
Re: Where's the prc-tools package?
At the time, it would build only on i386. I don't know if this is still the case or not -- the whole thing is convoluted, I think it forked into three or four separate branches by now. -- John Wichert Akkerman [EMAIL PROTECTED] writes: Previously John Goerzen wrote: Yes, and while you're at it, please close some bugs :-) I gave that package away two years ago when I moved to alpha and I'm still getting bug reports for it. What prevents you from maintaining it on alpha? Wichert. -- _ / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- John Goerzen [EMAIL PROTECTED] www.complete.org Sr. Software Developer, Progeny Linux Systems, Inc.www.progenylinux.com #include std_disclaimer.h [EMAIL PROTECTED]
Re: Security of Debian SuX0r?
Peter Makholm wrote: I've just helped a friend instaling Debian. He had two comment about the above question. Is it the red or blue button there is active? It is badly marked which button you are about the press. Yes well there are already bugs filed on this, but it is going to change a lot in woody anyway. The other comment is something about the wording of two of the questions. The firste question was saying something like Do you want to keep the standard (less secure) option and the next question said Would you use the new (more secure) option. If the user just thinks that he wants the most secure box but not really reading precisly what it says he will say no to both questions. (That was what we did). Shadow passwords make your system more secure because nobody is able to view even encrypted passwords. Passwords are stored in a separate file that can only be read by special programs. We recommend the use of shadow passwords. If you're going to use NIS you could run into trouble. Shall I install shadow passwords? I'm very confused how someone can skim something like 'Shadow passwords make your system more secure' 'Shall I install shadow passwords?', and then pick no if they want a secure box. -- see shy jo
Re: Security of Debian SuX0r?
Daniel Burrows wrote: I know that joeyh has been working on a much nicer-looking slang frontend which doesn't suffer from this problem; maybe we can just ditch dialog eventually and use that? That is the plan; dialog is very limiting. However there is a trivial fix for dialog/whiptail too -- just make the color of an unselected button the same as the color of the rest of the window. A bug to this effect is already in the BTS. -- see shy jo
ITP enhydra
Package: wnpp Severity: normal I intend to package Enhydra, an open source Java/XML application server http://www.enhydra.org/software/enhydra/index.html. It is licensed as follows (according to http://www.enhydra.org/software/license/): Base Enhydra server and tools: FreeBSD license XMLC component: Enhydra public license (EPL) Enhydra Enterprise server: Enhydra Public License (EPL) The EPL http://wWW.ENHYDRa.org/software/license/epl.html is based on the Mozilla license, and claims to be DFSG-free. I am attaching copies of the license, in text and HTML formats, so that someone with a better feel for these things may review it. The base server will go into either main or contrib, depending on whether it will work with Kaffe (no one seems to have been able to, but I will try). The Enterprise Server requires a 1.2 JDK, so it will definitely go into contrib. I may or may not package Enhydra Enterprise to start, as it is currently in alpha. My decision will depend on whether there appear to be usable point releases. -- - mdz Title: Enhydra: Open Source Java/XML Application Server Home Who We Are FAQs Partners News Contact Us Community Getting Involved Mailing Lists Working Groups Profiles Hall Of Fame ECP Community Resources Online Demos Community Library Bug/Feature Report Wireless Info BookShop Reference Links Resources & Events Software Enhydra Enhydra Enterprise Downloads Documentation CVS Repositories Roadmap License Services & Products Services Third-Party Products Commercial Enhydra Classifieds Marketing Kit Enhydra PUBLIC LICENSE Version 1.0 1. Definitions. 1.1. ``Contributor'' means each entity that creates or contributes to the creation of Modifications. 1.2. ``Contributor Version'' means the combination of the Original Code, prior Modifications used by a Contributor, and the Modifications made by that particular Contributor. 1.3. ``Covered Code'' means the Original Code or Modifications or the combination of the Original Code and Modifications, in each case including portions thereof. 1.4. ``Electronic Distribution Mechanism'' means a mechanism generally accepted in the software development community for the electronic transfer of data. 1.5. ``Executable'' means Covered Code in any form other than Source Code. 1.6. ``Initial Developer'' means the individual or entity identified as the Initial Developer in the Source Code notice required by Exhibit A. 1.7. ``Larger Work'' means a work which combines Covered Code or portions thereof with code not governed by the terms of this License. 1.8. ``License'' means this document. 1.9. ``Modifications'' means any addition to or deletion from the substance or structure of either the Original Code or any previous Modifications. When Covered Code is released as a series of files, a Modification is: A. Any addition to or deletion from the contents of a file containing Original Code or previous Modifications. B. Any new file that contains any part of the Original Code or previous Modifications. 1.10. ``Original Code'' means Source Code of computer software code which is described in the Source Code notice required by Exhibit A as Original Code, and which, at the time of its release under this License is not already Covered Code governed by this License. 1.11. ``Source Code'' means the preferred form of the Covered Code for making modifications to it, including all modules it contains, plus any associated interface definition files, scripts used to control compilation and installation of an Executable, or a list of source code differential comparisons against either the Original Code or another well known, available Covered Code of the Contributor's choice. The Source Code can be in a compressed or archival form, provided the appropriate decompression or de-archiving software is widely available for no charge. 1.12. ``You'' means an individual or a legal
ITP: bibtex2html -- BibTeX to HTML translator and BibTeX filter tool
Package: wnpp Severity: wishlist BibTeX2HTML is a collection of tools for producing automatically HTML documents from bibliographies written in the BibTeX format. It consists in two command line tools: - bib2bib is a filter tool that reads one or several bibliography files, filters the entries with respect to a given criterion, and outputs the list of selected keys together with a new bibliography file containing only the selected entries; - bibtex2html is a translator that reads a bibliography file and outputs two HTML documents that respectively the cited bibliography in a nice presentation, and the original BibTeX file augmented with several transparent HTML links to allow easy navigation. Licence: GPL. Home page: http://www.lri.fr/~filliatr/bibtex2html/index.en.html Ralf.
Re: ITP enhydra
On Thu, Aug 31, 2000 at 03:05:04PM -0400, Matt Zimmerman wrote: Package: wnpp Severity: normal I intend to package Enhydra, an open source Java/XML application server http://www.enhydra.org/software/enhydra/index.html. It is licensed as follows (according to http://www.enhydra.org/software/license/): I just noticed that Matthias Klose [EMAIL PROTECTED] has expressed an interest in packaging Enhydra. I searched -devel using http://lists.debian.org/#search and found no matches, but a later google search turned up messages there. Is the mailing list archive search engine broken? I also checked wnpp in the BTS and found nothing. Matthias, are you still interested in packaging Enhydra? If not, I am interested in taking it over. -- - mdz pgpuo1Cv9W6FO.pgp Description: PGP signature
Machine-specific optimizations
I know this theme has been repeated a lot here, but I still think that using machine-specific optimizations can make a difference. Specifically, there are a few packages (libgmp, gnupg, bzip2) where it could make a lot of difference. Some packages use every tiny bit of extra compiler optimization, while others have subarch-dependent assembly code which makes a lot of difference. So, is there any plan to use them (like recompiling the package on the user's machine)? -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Machine-specific optimizations
On Thu, Aug 31, 2000 at 05:34:01PM -0300, Cesar Eduardo Barros wrote: So, is there any plan to use them (like recompiling the package on the user's machine)? Yes, that is the plan. No, there is no other plan. (Why can't we have cool undying threads like, I don't know, katanas?) -- David Starner - [EMAIL PROTECTED] http/ftp: dvdeug.net.dhis.org It was starting to rain on the night that they cried forever, It was blinding with snow on the night that they screamed goodbye. - Dio, Rock and Roll Children
Re: Free Pine?
I've an outstanding, unanswered question which I've sent to UW in a related context (IMAPD): what specific clause of the copyright is being violated, when modified versions are distributed. Their position was that the words permission to copy, distribute and modify do not grant permission to distribute a modified version. In other words, they say you can distribute the software, and you can modify the software, but you can't modify it and then distribute the result. I think that, until we get a decent answer, this should be the question asked by anyone who gets a threat under these conditions: ask what specific terms of the license are being violated. You may never get an answer from the U of W, because right now the U of W can achieve its goals by saying nothing. If they have the feeling that you will let the issue slide if they let it drop, they are likely to let it drop. However, you now do have an answer to that question, so I hope you can proceed to take the appropriate action, and remove IMAPD from Main. The message I forwarded you shows clearly that they treat IMAPD as non-free software, that their position is that people must ASK for permission to release a modified version, and that the license does not give permission. That message does not give all the details. It makes sense to want to know more about the situation, but it makes no sense to let the issue slide unless and until they give you a full explanation. That is not the way to make the DFSG something that the users can rely on. If Debian decides to reject IMAPD and tells the U of W so, that will put some pressure on them to clarify the license. Otherwise they may prefer to leave it unclear in order to to have it both ways.
RE: Machine-specific optimizations
So, is there any plan to use them (like recompiling the package on the user's machine)? you always have the option of using 'apt-get source' to recompile a package, then place it on hold and we wont touch it. Beyond that, it gets very messy. Not to mention the disk usage. Users who insist that they most optimize packages often are the same ones who compile everything for themselves anyways. The gain for the project as a whole versus time spent is not enough.
Re: netscape 4.75 in security.debian.org is broken
On Thu, Aug 31, 2000 at 18:09:24 +0200 (+), Christian Surchi wrote: Package: communicator Version: 1:4.75-1 Severity: grave I've updated communicator from security.d.o's potato packages. I had to erase my preferences in ~/.netscape because it refused to save new settings and when launched it was always like the first time with box with license. I've lost cache, proxy, smart browsing, default page, fonts settings. I've lost all application section, netscape wants to see images with xv (all types, jpg, gif and png included). I set again correctly for jpg and gif, but no results with png. Plugin do not work, in application section I can't use it. I've lst all my settings for them. I had to blow away my preferences file (from v3) and let netscape recreate one called preferences.js. Otherwise it barfed: ~$ netscape no recognized font charsets! Adrian email: [EMAIL PROTECTED] Windows NT - Unix in beta-testing. PGP key available on public key servers Debian GNU/Linux -*- because I'm allergic to Prozac -*- www.debian.org
Re: Bug#70269: automatic build fails for potato
On Thu, Aug 31, 2000 at 08:29:30PM +0300, Antti-Juhani Kaijanaho wrote: Which is just a stupid pain in the ass. I had to track through three different references and finally install the build-depends package to find out what I could leave out of by Build-Depends stanza. It would *much* easier for developers, if less ideologically pure, to just list the damn packages on the Developers Corner part of the website. Could we add this as a footnote to the relevant section in policy or the packaging manual (can't remember which offhand)? Um, the current note in policy manual is not sufficient? (It explicitly mentions the package build-essential.) I guess. Maybe he didn't look in the right place ;-) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Bug#70269: automatic build fails for potato
Steve == Steve Greenland [EMAIL PROTECTED] writes: Steve On 31-Aug-00, 07:18 (CDT), Manoj Srivastava [EMAIL PROTECTED] wrote: Firstly, build essential package is ot merrely for build daemaons. Steve No, but I think that's the primary reason for it's Steve existence. If it was mainly for humans, it would be sufficient Steve to have checks in the in debian/rules, or a list of required Steve packages somewhere in README.Debian. Hmm. Were it just the build daemons, we would not have had to create policy and a whole package; informal arrangements would have worked as well (there are not that many build daemons out there, and any new one requires enough patching that coming up with a decent list of starter packages would not be an obstacle). The policy, and the build essential package, exists to provide the equivalent of the essential packages for the build depends headers, and one of the common goals of both Essential packages and the packages listed in build essentials is to help developers minimize the depend header lines, and it helps the special requirements stand out. That is where most people shall use the essential package lists. (I am not saying, mind you, that this is the sole goal) Steve So I'm supposed to go back and figure out if my packages can Steve be successfully built with debhelper 2.0.58? If so, how can I I think that you start with a particular version dependency, and then only update the dependency if you use new features not present in older helper packages. Steve -- is there a complete archive of all released debhelpers Steve somewhere? I don't think this is going to happen. Instead, Does the changelog help? Steve I'll just (probably automatically) update my build-depends Steve line to the version of debhelper that's installed on my Steve machine. So the de-facto requirement is going to be a nearly Steve current version of debhelper. I beg to differ. Most people shall follow the procedure outlined above -- start with some version of the debhelper for the dependency, and not update that version unless you use new features. Steve The same is true for the build-essential packages -- nobody is Steve going to go back and check their stuff against old versions of Steve gcc and make. Admittedly, those are much slower moving Steve targets...but dpkg-dev isn't, necessarily. Actually, I do have versioned dependencies on dpkg-dev, and the process works as I outlined above -- older version of dpkg-dev broke for my packages, and I created a versioned dependency -- and have never had to change that, really. Steve But you're not running a build daemon, or otherwise trying to Steve build a significant number of packages from source. People Steve doing so are the consumers of Build-depends. If you were, I Steve don't think you'd object to being expected to having a helper Steve package installed (well, you might object, but the helper Steve packages *are* a reality, and *are* widely used). Well, I think that these customers are so few, and need to be quite competent, often have to have a list of packages that goes beyon just the build essentials. We should not need a policy and a package for just these consumers. Our differences seem to stem from this basic difference in opinion: whom is the build essentials package primarily for? And my take is that the primary consumers are the developers of the 5000+ packages, and additionally, a few buld daemons, most of whom need a core set that may not be reflected in build essentials. Your opinion, obviously, differs. manoj -- All heiresses are beautiful. John Dryden Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Where's the prc-tools package?
It can now be maintained on alpha, IIRC. I looked into it awhile ago and they had brought it up to date with a modern gcc (so long 2.7.x, which didn't work on alpha unless severely patched). C On 31 Aug 2000, John Goerzen wrote: At the time, it would build only on i386. I don't know if this is still the case or not -- the whole thing is convoluted, I think it forked into three or four separate branches by now. -- John Wichert Akkerman [EMAIL PROTECTED] writes: Previously John Goerzen wrote: Yes, and while you're at it, please close some bugs :-) I gave that package away two years ago when I moved to alpha and I'm still getting bug reports for it. What prevents you from maintaining it on alpha? Wichert. -- _ / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- John Goerzen [EMAIL PROTECTED] www.complete.org Sr. Software Developer, Progeny Linux Systems, Inc.www.progenylinux.com #include std_disclaimer.h [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
My recent bug's and continuing effort to debconf-ize Debian
I started this afternoon submitting bugs against packages which print verbose output in their maintainer scripts. The future that Debian must take is to fully support debconf. To further this goal I will continue submitting patches to any package which prompts the user in a maintainer script. If any maintainer would like a) to join in the effort b) me to debconf their package or need help doing so please mail me. With debconf, Debian can have its own kickstart, or unattended installs, and all the other little things that people have been asking for years to have Debian support. This also means that companies using Debian to not have to rip apart packages because they ask too many questions. As for my patches to make maintainer scripts quiet, the days where the messages were useful have passed. They now whiz by during install leaving users wondering if they missed something. Or they scare the newbie. I watched an install yesterday where a package ran a tex function and echoed all the output to screen -- you know what tex output looks like to the unsuspecting? With task packages, users do not always know exactly what packages are being installed. I am not asking for Debian to coddle newbies. But the little things like package installation output can be easily changed.
gpm and X problem investigated
Hi! In the recent past, there have been multiple (bug) reports about the behaviour of potato ( woody?) gpm in the presence of X (or vice versa, really). I've done some research, with these results: 1. On slink and probably before (because I don't remember things being differently), gpm did not default to be in repeater mode or even ask about that. In the X config, you would mention your real /dev/mouse and your real protocol. 2. On any-potato upgrades, the config file is not touched, and gpm and X continue to behave as before. In an upgraded potato system, X still needs your real /dev/mouse and your real protocol. 3. On new potato installs, gpm defaults to be in repeater mode, and to repeat in the ms3 protocol. 4. When gpm is in repeater mode, it does not release the mouse device when switching to X, but expects X to read data from /dev/gpmdata. So, in the current potato default install, IF you install gpm, X config must use /dev/gpmdata and ms protocol always, regardless of mouse type. 5. In the current potato install, IF you do NOT install gpm, X config needs your real /dev/mouse with your real protocol. 6. My personal experience shows that, with gpm repeating in the ms3 protocol, the middle mouse button is very hard to get working in X, if at all. Also, movement data of the mouse appears to get lost, resulting in erratic and uncomfortable mouse behaviour. 7. The solution to the repeating problem in 6. is to default to repeating in the raw = untranslated protocol. Then, X config would need /dev/gpmdata always, but your real protocol. So, on a potato system, the X configuration may require three different settings, dependent on your personal history: real /dev/mouse + real protocolwhen upgraded from slink or before OR on new potato install without gpm /dev/gpmdata+ ms protocol on unmodified new potato install w/gpm /dev/gpmdata+ real protocolon modified new potato install w/gpm This situation seems highly undesirable to me, if only because this is not documented properly anywhere -- and even documenting the current situation in a way that is clear to the average user (i.e. M$Win convert) is a daunting task. Apart from changing nothing and leaving our users completely in the dark, there seem to be two options: a. Let gpm default to repeating in raw mode (to solve 6.), and add a very clear notice that X should be (re)configured with /dev/gpmdata but using the real protocol -- but when gpm is either stopped or removed/purged, that the X config should be changed again (!! I don't know any package that requires _another_ package to be _manually_ reconfigured on install/ remove). b. Let gpm default to not repeating at all, without needing any further documentation (AFAIK; I don't remember questions on gpm - X behaviour in slink). Obviously, b. is the right choice (IMHO ;-). Furthermore, a fix to this effect seems more than necessary to go into 2.2r1. Or... is there a flaw in my logic? Or is there some very important reason for gpm's current behaviour? Regards, Anne Bezemer
Re: Machine-specific optimizations
On Thu, Aug 31, 2000 at 01:49:13PM -0700, Sean 'Shaleh' Perry wrote: So, is there any plan to use them (like recompiling the package on the user's machine)? you always have the option of using 'apt-get source' to recompile a package, then place it on hold and we wont touch it. I've tried doing this occasionally -- more often to change a compile-time feature than optimise for CPU -- and it's not very convenient. I mean, the apt-get source couldn't be easier, but unless I put the package on hold, apt `upgrades' to the *same* version on the very next apt-get upgrade. I've had to resort to using NMU versioning in the changelogs to stop this, which is not really ideal (for my laziness). Is this just the way it has to be? Why is it so? Wouldn't it be better to allow users to compile if they want and only upgrade when there's a new release? What have I missed? :-) -- Alisdair McDiarmid[EMAIL PROTECTED] [http://wasters.org/pubkey.asc perl -i.mac -p -e 's/\r/\n/smg;']
Re: gpm and X problem investigated
I support your conclusion and and asks the same question. Why did it change? Regards, /Karl --- Karl HammarAspö Data [EMAIL PROTECTED] Lilla Aspö 2340 +46 173 140 57Networks S-742 94 Östhammar +46 70 511 97 84 Computers Sweden Consulting --- From: J.A. Bezemer [EMAIL PROTECTED] Subject: gpm and X problem investigated Date: Fri, 1 Sep 2000 00:22:23 +0200 (CEST) Hi! In the recent past, there have been multiple (bug) reports about the behaviour of potato ( woody?) gpm in the presence of X (or vice versa, really). I've done some research, with these results: 1. On slink and probably before (because I don't remember things being differently), gpm did not default to be in repeater mode or even ask about that. In the X config, you would mention your real /dev/mouse and your real protocol. 2. On any-potato upgrades, the config file is not touched, and gpm and X continue to behave as before. In an upgraded potato system, X still needs your real /dev/mouse and your real protocol. 3. On new potato installs, gpm defaults to be in repeater mode, and to repeat in the ms3 protocol. 4. When gpm is in repeater mode, it does not release the mouse device when switching to X, but expects X to read data from /dev/gpmdata. So, in the current potato default install, IF you install gpm, X config must use /dev/gpmdata and ms protocol always, regardless of mouse type. 5. In the current potato install, IF you do NOT install gpm, X config needs your real /dev/mouse with your real protocol. 6. My personal experience shows that, with gpm repeating in the ms3 protocol, the middle mouse button is very hard to get working in X, if at all. Also, movement data of the mouse appears to get lost, resulting in erratic and uncomfortable mouse behaviour. 7. The solution to the repeating problem in 6. is to default to repeating in the raw = untranslated protocol. Then, X config would need /dev/gpmdata always, but your real protocol. So, on a potato system, the X configuration may require three different settings, dependent on your personal history: real /dev/mouse + real protocolwhen upgraded from slink or before OR on new potato install without gpm /dev/gpmdata+ ms protocol on unmodified new potato install w/gpm /dev/gpmdata+ real protocolon modified new potato install w/gpm This situation seems highly undesirable to me, if only because this is not documented properly anywhere -- and even documenting the current situation in a way that is clear to the average user (i.e. M$Win convert) is a daunting task. Apart from changing nothing and leaving our users completely in the dark, there seem to be two options: a. Let gpm default to repeating in raw mode (to solve 6.), and add a very clear notice that X should be (re)configured with /dev/gpmdata but using the real protocol -- but when gpm is either stopped or removed/purged, that the X config should be changed again (!! I don't know any package that requires _another_ package to be _manually_ reconfigured on install/ remove). b. Let gpm default to not repeating at all, without needing any further documentation (AFAIK; I don't remember questions on gpm - X behaviour in slink). Obviously, b. is the right choice (IMHO ;-). Furthermore, a fix to this effect seems more than necessary to go into 2.2r1. Or... is there a flaw in my logic? Or is there some very important reason for gpm's current behaviour? Regards, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: My recent bug's and continuing effort to debconf-ize Debian
On Thu, Aug 31, 2000 at 03:21:17PM -0700, Sean 'Shaleh' Perry wrote: I started this afternoon submitting bugs against packages which print verbose output in their maintainer scripts. The future that Debian must take is to A thread came up here a little while back about installation scripts sometimes not being able to use debconf for security or other reasons. But we would like an interference-free install. So what about introducing a dpkg-postconfigure program which runs package.postconfig files after any dpkg run has finished, in an analagous way to dpkg-preconfigure. Only this time, it will be only for things that *must* wait till post-installation, and cannot use debconf for whatever reason. There shouldn't be that many of these, but it would probably be a good idea to introduce this soon as we move to non-interactive installs. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: My recent bug's and continuing effort to debconf-ize Debian
Julian Gilbey wrote: A thread came up here a little while back about installation scripts sometimes not being able to use debconf for security or other reasons. That's not particularly accurate. But we would like an interference-free install. So what about introducing a dpkg-postconfigure program which runs package.postconfig files after any dpkg run has finished, in an analagous way to dpkg-preconfigure. Only this time, it will be only for things that *must* wait till post-installation, and cannot use debconf for whatever reason. There shouldn't be that many of these, but it would probably be a good idea to introduce this soon as we move to non-interactive installs. This is not necessary, it is perfectly possible to prompt for passwords or anything else in the postinst, using debconf, if you feel that is necessary for security reasons or whatever other reason. -- see shy jo
Re: gpm and X problem investigated
On Fri, 1 Sep 2000, J.A. Bezemer wrote: **cut b. Let gpm default to not repeating at all, without needing any further documentation (AFAIK; I don't remember questions on gpm - X behaviour in slink). Obviously, b. is the right choice (IMHO ;-). Furthermore, a fix to this effect seems more than necessary to go into 2.2r1. On my test installs I configured gpm manually, as I always do, and switched off repeat mode. I have never had any problems in X. A generic serial mouse on ttyS1. Phil. - Philip Charles; 39a Paterson St., Abbotsford, New Zealand; +64 3 4882818 Mobile 025 267 9420. I sell GNU/Linux CDs. See http://www.copyleft.co.nz
Re: potato + updates
On Wed, Aug 30, 2000 at 11:02:58AM -0700, Michael Meskes wrote: On Tue, Aug 29, 2000 at 06:44:48PM -0800, Ethan Benson wrote: The README on security.debian.org already gives you that line.. Hmm, strange. It seems I missed reading this. Maybe the complete list of sources should be at http://www.debian.org/security/. -- - mdz pgpkZ9vZru6Zr.pgp Description: PGP signature
New key signing coordination page
Greetings all, With the help of Domenico Andreoli, I have revised the Debian (NM process) key signing coordination page. It is located here: http://oink.cc.ntu.edu.tw/~cklin/signing/ Now the operations are fully automated, with a PostgreSQL database in the back holding all information. The package, including the PHP script and some other documents, are released under GPL and also available from the page above. As always, feedbacks are welcome! -- Chuan-kai Lin
