0 days till bug horizon
This is the current list of bugs that are headed for the horizon. I generated it from the bugscan report of Mar 26 15:08, and subtracted the bugs that were fixed by uploads I installed today. I will start removing these packages soon (unless they're too important, in which case we have a different problem). Removal of a package is final. Richard Braakman --- Total number of bugs listed: 34 Explanation for tags: * [FIX]: describes a simple method to deal with the bug. * [STRATEGY]: describes a possible approach for fixing the bug. * [HELP]: help is needed to fix this bug. Package: autofs (debian/main). Maintainer: Justin Maurer [EMAIL PROTECTED] 52132 autofs: Race condition when expiring autofs submounts leaves daemon crippled [STRATEGY] Patch available, waiting for reply from upstream [ This is taking rather long -- RB ] Package: bash (debian/main). Maintainer: Matthias Klose [EMAIL PROTECTED] 58404 bash: *ap++ == 0x55 , segmentation fault out of nowhere! Package: bbdb (debian/main). Maintainer: Frederic Lepied [EMAIL PROTECTED] 59177 xemacs20 didn't compile bbdb-gnus on installation Package: boot-floppies (debian/main). Maintainer: Debian Install System Team debian-boot@lists.debian.org 58266 [fixed in CVS] bf-2.2.7: PCMCIA network install is broken 58779 boot-floppies: Can't boot on my Powerpc 58857 The boot floppies do not work with milex raid on root. 60218 [fixed in CVS] error when setting active partition Package: communicator-smotif-461 (debian/non-free). Maintainer: Adam Heath [EMAIL PROTECTED] 43849 communicator-smotif: Floating point exception error [ We have netscape 4.72 to replace it, but not for all architectures. --RB ] Package: debiandoc-sgml (debian/main). Maintainer: Ardo van Rangelrooij [EMAIL PROTECTED] 60246 debiandoc-sgml: error handling in two commands is inappropriate [ Being worked on ] Package: debianutils (debian/main). Maintainer: Guy Maor [EMAIL PROTECTED] 59121 run-parts hangs during /etc/cron.daily runs Package: dpkg (debian/main). Maintainer: Wichert Akkerman [EMAIL PROTECTED] 33237 /etc/alternatives/emacs not managed properly - /usr/bin/emacs doesn't run emacs20 [STRATEGY] Switches to manual-mode too quickly, maintainer will look at it this weekend. 58091 package name Eterm -- eterm 60105 dselect dies with 'failed to getch in main menu: Success' Package: epic4 (debian/main). Maintainer: Joseph Carter [EMAIL PROTECTED] 58508 Epic pre2.503 has bugs which 2.505 has not Package: fetchmailconf (debian/main). Maintainer: Paul Haggart [EMAIL PROTECTED] 57287 generates wrong config files [ Removing fetchmailconf means also removing fetchmail, unless someone uploads a fetchmail version that does not create a fetchmailconf package ] Package: g++ (debian/main). Maintainer: Debian GCC maintainers [EMAIL PROTECTED] [HELP] For gcc/g++ bug reports to be sent to the upstream maintainers, certain procedures must be followed, so help from clueful people is required 48530 g++ [fixed in 2.96 CVS Feb 2000] [alpha]: internal compiler error building open-amulet [WAITING] Maintainer was contacted on Dec 12, awaiting reply. 55291 [alpha] g++ causes internal compiler error compiling hatman Package: gcc (debian/main). Maintainer: Debian GCC maintainers [EMAIL PROTECTED] 59819 gcc_2.95.2-7(frozen): fails to compile itself on m68k Package: gnudip (debian/main). Maintainer: Randolph Chung [EMAIL PROTECTED] 59248 gnudip: Gnudip prerm script fails with error `groupdel: group gnudip does not exist' Package: ircd (debian/main). Maintainer: Johnie Ingram [EMAIL PROTECTED] 58757 wont start Package: libc6-dev (debian/main). Maintainer: Joel Klecker debian-glibc@lists.debian.org 59962 sys/ucontext.h shouldn't define ERR Package: libgd-graph-perl (debian/contrib). Maintainer: Piotr Roszatycki [EMAIL PROTECTED] 59442 libgd-graph-perl: Missing files, missing dependencies Package: nscd (debian/main). Maintainer: Joel Klecker debian-glibc@lists.debian.org 58367 nscd: 'broken pipe' error causes entire box to be unusable Package: pdl (debian/main). Maintainer: Raul Miller [EMAIL PROTECTED] 55268 [Strategy: use older version on alpha] PDL fails to compile on alpha [ Nice strategy, but someone needs to implement it. -- RB ] Package: perl-5.005 (debian/main). Maintainer: Darren Stalder [EMAIL PROTECTED] 55794 Wrong system call numbers on alpha (and probably other non-i386) Package: perl-5.005-doc (debian/main). Maintainer: Darren Stalder [EMAIL PROTECTED] 60233 incorrect copyright for documentation Package: pvm (debian/main). Maintainer: Drake Diedrich [EMAIL PROTECTED] 59903 pvm_3.4.2-4(frozen): build fails due to root-owned files [FIXED] in 3.4.2-5, waiting for m68k to confirm. [ This is taking rather long -- RB ] Package: sendmail (debian/main). Maintainer:
Re: Idea: Debian Developer Information Center
Hi Raphael, - information about the NMU policy that the maintainer has adopted (timeframe before a NMU is allowed, do i need an authorization to do a nmu ?, ...) easy to add. Jason would be the person to do this (add a field to the db). The web interface can easily be changed to update/view this info. - the list of packages he's maintaining (yes some maintainer forget that they're maintaining some packages) with up-to-date statistics for each package (number of important/normal/wishlist bugs, standards-version that it does follow, last upload) I actually have some code to do this, but until our bug system is ldapified or at least have a non-textual backend, it will be difficult to do. Ben has a bts ldap setup, but i understand it is not official and not necessarily maintained all the time. - a link to the personnal bug page the problem with this is that many maintainers have packages registered under different forms of their email address, so this is actually more difficult to do. You will probably need to do something with the pgp/gpg sig on the .dsc files. again, this is something i've looked at in the past, but at that time i was asked to hold off until the bug system has been overhauled. - any other information that may be suitable for such a page like the latest news that must be read by Debian developers (think about debian-devel-announce) Wouldn't this just be a link to the mail archive for that mailing list? randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/
Re: Bash and Letter E
Date: Sun, 26 Mar 2000 11:46:23 -0300 From: Rodrigo Castro [EMAIL PROTECTED] To: debian-user@lists.debian.org, debian-devel@lists.debian.org Subject: Bash and Letter E Hello Sorry for asking again about my problem but I can't make my letter E work in bash (neither in console nor xterm). See what happens: - E is treated like a dead key. It is not showed at first time, but when you press another key after E, it beeps - E works in other programs and shells (ksh, csh and so on), so it is not a hardware - I booted with another kernel (in case one from RedHat 6.1 CD) and it didn't work - I booted with init option (linux init=/bin/bash) in order to run no init script and it didn't work either. I also tried D option (linux D). - I tried another keyboard and no success - I reinstalled libc6, libncurses5 and base-files - I installed older and newer versions of bash and libc6 - I created a new user with no /etc/input, no ~/.inputrc, no ~/.bash(rc|_profile) and even so it didn't work I am running out of ideas. I am almost getting bash source code, compiling with debug option and running gdb!! Anyone have an idea? PS: Could you send a copy to my email address? I am not a subscriber of debian-devel nor debian-user Is it really just bash that has this problem? You tested other shells, but I don't think they use GNU readline. What about other things that use readline, like octave (find something smaller if you don't have it installed already! Use the package dependencies to see what depends on libreadline4.) Try using showkey(1) to see what pressing 'E' does on your hardware. Also try dumpkeys and loadkeys, to see if the keymaps are ok. Maybe you have a weird setting in /etc/inputrc? Is there such a config file? To see what bash is reading in, try strace -e file bash -login -- #define X(x,y) x##y DUPS Secretary ; http://is2.dal.ca/~dups/ Peter Cordes ; e-mail: X([EMAIL PROTECTED] , dal.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BCE
re: stuffit expander?
Date: Sun, 26 Mar 2000 21:50:54 +0200 (CEST) From: Nils Jeppe [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: stuffit expander? Hello, Is there any debian package (or in fact Unix tool at all) that allows uncompression of Mac .sit (stuffit) archives? I think you want the macutils package. Peter Cordes
Re: Bash and Letter E
Date: Sun, 26 Mar 2000 18:55:21 -0300 From: Rodrigo Castro [EMAIL PROTECTED] To: Samuel Tardieu [EMAIL PROTECTED], debian-devel@lists.debian.org, debian-user@lists.debian.org Subject: Re: Bash and Letter E Hello, [...] INPUTRC -- [...] \e[C:forward-char \e[D:backward-char \e[E:beginning-of-line \e[H:beginning-of-line \eOH:beginning-of-line \eOF:end-of-line \EOF:end-of-line \e[F:end-of-line \e[e:end-of-line -- Is \EOF really what your file says here? maybe \E isn't treated as escape, so bash is looking for a literal E to be followed by OF, and then it will go to the end of the line. (Try that, typing EOF, and see if the cursor jumps to the end of the line.) If it does, then remove that line from /etc/inputrc! -- #define X(x,y) x##y DUPS Secretary ; http://is2.dal.ca/~dups/ Peter Cordes ; e-mail: X([EMAIL PROTECTED] , dal.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BCE
Re: Bug#32888: marked as done (base: Removing Obsolete package base kills a system)
On Sun, Mar 26, 2000 at 09:39:09PM +1000, Hamish Moffatt wrote: On Sun, Mar 26, 2000 at 11:03:27AM -, Debian Bug Tracking System wrote: The base package doesn't exist any more for quite a long time, those first time Debian user are most of them quite good and knows what to do to correct this problem. Furthermore for those who can't, they simply have to not remove the base package (which is guaranteed by its essential flag)... this bug deserves no more to be open. I think we are closing bugs for the sake of it here. Any reason why the suggestion can't be implemented? (ie make base-files.postinst truncate base.list). OK it's not a very nice solution but there isn't a better one. I personally have nuked the base package and lost all my devices this way. Sorry to step in, but there might be a better solution to the problem. I think you can preserve files of an old package which otherwise wold be removed. The possible solution I see to this case is using dpkg-divert. If base is still installed you should dpkg-divert every file in /dev that used to be in that package to some other place. Example: dpkg-divert --package base-files --divert-to /dev.base/hda /dev/hda Then if you remove base, the devices would not get removed. There however might be many files to divert and I don't know if somebody really wants to do this. And as already mentioned this package is quite old so only few people would using it. I won't reopen this bug but I forward this information to the BTS. Just my 2 cent. Ingo -- Windows, me?
Re: Bug#32888: marked as done (base: Removing Obsolete package base kills a system)
dpkg-divert --package base-files --divert-to /dev.base/hda /dev/hda Ugh.. ugly... The clean solution is to truncate the file list of base, as proposed. This will release all the files owned by that package safely, with no danger at all.
Re: Bash and Letter E
On Sun, Mar 26, 2000 at 09:37:27PM -0400, Peter Cordes wrote: Is it really just bash that has this problem? You tested other shells, but I don't think they use GNU readline. What about other things that use readline, like octave (find something smaller if you don't have it installed already! Use the package dependencies to see what depends on libreadline4.) The problem occurs also with gdb or ftp, for example. I think the problem is in readline library. I copied my INPUTRC file in a previous message, but I dont think the problem comes from this file or something related to bash, once gdb and ftp dont work either. Try using showkey(1) to see what pressing 'E' does on your hardware. Also try dumpkeys and loadkeys, to see if the keymaps are ok. Showkey shows a normal behaviour for my 'E' key. I tested other keymaps, that's not where the problem is. Maybe you have a weird setting in /etc/inputrc? Is there such a config file? To see what bash is reading in, try strace -e file bash -login I have already done. It is in a previos message. Give a look, it doesn't work with 'E' as it should and how it works for other keys. Thank you for your help, Peter. PS: Please, carbon copy the message to me. []'s -- Rodrigo Castro [EMAIL PROTECTED] Computer Science undergraduate student - University of Sao Paulo I do not fear computers. I fear the lack of them. -- Isaac Asimov
Re: stuffit expander?
On Sun, Mar 26, 2000 at 09:50:54PM +0200, Nils Jeppe wrote: Hello, Is there any debian package (or in fact Unix tool at all) that allows uncompression of Mac .sit (stuffit) archives? there is no debian package, and more to the point there is no *nix utility period that will extract stuffit version 4 and version 5 files. this format is highly proprietary and only one compnay i am aware of has reverse engineered it, Mindvision (with there macos Mindexpander utility) they have however chosen not to share their knowledge with anyone (or their source). the version 5 file format no one has yet reverse engineered AFAIK. (look for Aladdin systems to be moving to Virginia soon)... there is however some OLD (have not been touched since '88) utilities that used to extract version 1.5 stuffit files, but they don't really work anymore, and are not included in any debian package i have seen. its just as well, they tend to do a better job creating corrupt files/archives then unpacking a .sit file. my suggestion is to deal with users using this blatently proprietary format to use something standard and open, such as a combination of macbinary and gzip. which unix utilities should not have any problem with. -- Ethan Benson http://www.alaska.net/~erbenson/
Re: stuffit expander?
On Sun, Mar 26, 2000 at 09:54:50PM -0400, Peter Cordes wrote: Date: Sun, 26 Mar 2000 21:50:54 +0200 (CEST) From: Nils Jeppe [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: stuffit expander? Hello, Is there any debian package (or in fact Unix tool at all) that allows uncompression of Mac .sit (stuffit) archives? I think you want the macutils package. nope, that package does not include the stuffit 1.5 utilities, because they are quite old and broken. -- Ethan Benson http://www.alaska.net/~erbenson/
iptables deb for 2.4.X kernels in incoming
Just found iptables for 2.4.X kernels (for packet filtering, NAT etc) and packaged it up. Its in incoming. Sorry for the missing ITP. Will remove it if someone has somethin better.
Potato - update-alternatives (Ian Jackson) and window managers - doubt (and Slink to Potato Success)
Hello! First, I'm proud of Debian! I upgraded my Debian system to Potato this weekend, and everything went really fine! Enven my glibc 2.0.7 programs ran (almost all)! Thank you all developers! Go ahead! Make the world better! Second, I'm a bit confused about one point: I compiled gnome, wmaker and a large bunch of X-related software, and I was using a file in the /etc/X11/ (I can't remember its name, since it was deleted during the upgrade) to set my default window manager to /usr/local/bin/gnome-session. When I restarted my computer and ran X (startx), I was in front of a tiny almost-unuseable window manager. Digging the scripts I found one symlink (/etc/alternatives/x-window-manager) pointing to that ugly wm. I removed that symlink, created a new one pointing to /usr/local/bin/gnome-session. startx went fine. Till I restarted the computer. Then, once again, that link was set to /usr/bin/X11/vtwm . What a mess. I was poking update-alternatives, but didn't find a way to point my default window manager to /usr/local/bin/gnome-session. Yes I did read the man 8 update-alternatives, but it was a bit confusing to me (as I think it is a bit confusing to anyone but the man writer aka Ian Jackson), since it was not sufficiently explanatory (at least to me. Shame on me...). Could anyone explain to me the right way to make it work like I want, in the update-alternatives way? Thank you all! P.S.: Is Ian the Deborah's husband? :) Just to know... :) Thanks twice, Claudio
apache-1.3.9-12
Anyone using mod_rewrite w/ a dbm map type with this package in potato? basically whevener i use a map type of dbm rweriting fails to look up the key value pairs, works ok with text and regexp based rulesets but not dbm. If anyone else is experiencing this same sort of difficulty then perhaps a bug should be filed against thuis package???
Re: Idea: Debian Developer Information Center
Le Sun, Mar 26, 2000 at 06:02:43PM -0700, Randolph Chung écrivait: Hi Raphael, Hi, easy to add. Jason would be the person to do this (add a field to the db). The web interface can easily be changed to update/view this info. That's what I thought. :) the problem with this is that many maintainers have packages registered under different forms of their email address, so this is actually more difficult to do. You will probably need to do something with the pgp/gpg sig on the .dsc files. again, this is something i've looked at in the past, but at that time i was asked to hold off until the bug system has been overhauled. Yes I know, I should probably extract all the identities from a single PGP/GPG key and look for all those adresses in the Packages file. Or something like that. Wouldn't this just be a link to the mail archive for that mailing list? yes, probably. Cheers, -- Raphaël Hertzog 0C4CABF1 http://tux.u-strasbg.fr/~raphael/ pub CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd Formations Linux et logiciels libres : http://www.logidee.com /pub
Re: Removing compiled-by-hand packages [WAS:] Potato - update-alternatives and window managers
... But, since there are pretty current versions of gnome in potato you might use those... Surely it woulb be _very_good_ idea, along with communicator and a really _huge_ stuff I have in, but I really afraid about messing my system with broken dependencies and so... Ok, removing almos all the bunch I have would be a great idea too... but I have some questions to ask: 1. Does Debian install any stuff inside /usr/local ? 2. Is secure to the system integrity to _wipe_ /usr/local (no daemons/services stored in /usr/local and such issues)? The sense of _wiping_ /usr/local means removing files/symlinks from /usr/local/bin, /usr/local/lib and such. I'm a bit short of space in my /usr partition, and it would be useful... :) Claudio
Re: RBL report..
* Joseph Carter ([EMAIL PROTECTED]) [000326 16:45]: On Sun, Mar 26, 2000 at 04:00:54PM +0200, Nils Jeppe wrote: Given every report I've heard to the contrary, I'm not sure I believe that. I've also been told that there are cases where their tests produce false positives. I don't see how you can create a false positive on a relay test. Either the message gets through, and you're an open relay, or it doesn't, and you're fine. It's quite simple, really. Or it appears to have been accepted and goes nowhere. I've seen a setup or two like this specifically for the purposes of tracking who was trying to use the relay... Nope, this can't happen with ORBS. They definitely check that. They figure out wether you are dropping their testmails or relay them. Mike
Re: Anyone's able to run 2.3.99-pre*?
On Sun, Mar 26, 2000 at 02:50:43AM -0700, [EMAIL PROTECTED] wrote: Do you have an IDE ZIP drive? I believe I had the same problem starting No. around 2.3.43. The problem is related to having an uninitialized ATA ZIP Yes, that's when it started. drive around(on the same chain, maybe) as your harddrive. modprobing ide-floppy was enough to work around the problem. I added ide-floppy to my /etc/modules and it hasn't bothered me since. I don't know if this was ever fixed. I only have two disks running on one port and two CDs on the other. Since one of these is a burner I use scsi emulation for CD but not for the disks. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
Re: Anyone's able to run 2.3.99-pre*?
On Sun, Mar 26, 2000 at 11:52:40AM +0200, Petr Cech wrote: check that you don't mount devfs, and have IDE subsystem compiled in (it changed location). DEVFS is enabled but not mounted. After all the problem occurs way to early for a mount call. And yes, IDE is compiled in. The system can read from the disk. For instance init or e2fsck sre started. But it does not seem to find the superblock. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
Re: Anyone's able to run 2.3.99-pre*?
On Mon, Mar 27, 2000 at 08:58:11AM +0200 , Michael Meskes wrote:
On Sun, Mar 26, 2000 at 11:52:40AM +0200, Petr Cech wrote:
check that you don't mount devfs, and have IDE subsystem compiled in (it
changed location).
DEVFS is enabled but not mounted. After all the problem occurs way to early
if you don't say otherwise, devfs is _automagicaly_ mounted on /dev, and it
that you have some devices missing. Try running with
append=devfs=nomount
Petr Cech
--
Debian GNU/Linux maintainer - www.debian.{org,cz}
[EMAIL PROTECTED]
Re: Anyone's able to run 2.3.99-pre*?
On Sun, Mar 26, 2000 at 10:35:02AM +0200, Michael Meskes wrote: e2fscheck always tells me it cannot read the superblock. Up to 2.3.4? it worked well. And of course 2.2.14 runs without a problem. Sounds like you may have turned on support for devfs. You might want to turn that off until debian has a package for devfsd. Alternatively, if you have SCO login enabled, you can go into /dev and create symlinks from /dev/ide/bus0/unit0/part1 to /dev/hda1 etc... then exit and continue rebooting. I can't use it because the PCnet32 driver is completely broken. (though I have tested it using a pcmcia ethernet) -smj
Re: RBL report..
On Sun, Mar 26, 2000 at 11:05:40AM +0200, Nils Jeppe wrote: On Sat, 25 Mar 2000, Jason Gunthorpe wrote: * Note, once a site is listed in one of these RBLs it becomes impossible for a user to unsubscribe from our lists - no matter what they do they will never be able to communicate a bounce or a unsubscribe request - this is pretty bad. Hmmm actually, I use Exim, and Exim has a way to configure exceptions from RBL blocks. So you could enter an unsubscribe-alias-email-address into these exceptions. I have M4's for sendmail that address this problem as well, and have packaged them... One M4 allows you to select (based on the recipient address) which of the four tests to run for blockage. Another M4, allows you to select (based on the recipient address) which of the four tests to run for inserting X-Spam-* headers. -smj
Re: UPS setup problems (apcuspd and genpower)
On Fri, 24 Mar 2000, Thomas R. Shemanske wrote: A few days ago, I posted this to the debian-users list, but got no takers. Perhaps someone here has some ideas. OK, if noone else replied I'll give it a trial. Consider me as a fool with the fortune to get a running UPS daemon and not as an expert in this field!! Once I tried *every* single UPS daemon package of the Debian system without any success. The reason was (if I remember right) that they were talking to the UPS via SMART connection (please read more in your documentation about that topic). Unfortunately the cable shipped with my UPS didn't support this mode. It only supportet SIMPLE connection. (Note: Possibly you have to swap the words SMART and SIMPLE in the previous text. They are possibly confused by my unSMART memory :-). ) Please read all the documentation (of the daemon and the hardware) very carefully, which cables you need or how you can build the right cable yourself. After failing with all I tried to package ssd from the APC site. I was successfull in packaging it but it failed to work because of the same reason I stated above. Because I couldn't test it I uploaded it to experimental. May be you give it a triel. But don't blame me if it don't work!! Take it or ask me to remove it from there. Finally I took the smupsd which is shipped with RedHat and happyly I was successful. The package is available in potato. Please check the configuration file very carefully. It needs investigation by hand! (Any volunteers to add debconf stuff to the package??? Unfortunately I have no time for this. May be anyone more experienced than me takes over the package. It is in a works for me state.) May be you can gain more information in a Hardware related mailinglist or newsgroup as I did. Kind regards Andreas.
gpm in vim
Craig Sanders [EMAIL PROTECTED] wrote: On Sun, Mar 26, 2000 at 05:57:38PM +0200, [EMAIL PROTECTED] wrote: * Enable gpm support (except in vim-tiny of course) on popular request. can this be disabled in ~/.vimrc? The opposite is infact true, console mouse support has to be enabled in the ~/.vimrc to be used. text-mode programs which use the mouse make it difficult to use the mouse for the purpose that the gods intended (cut paste with left, right, and middle buttons). having to remember to press shift every time you want to cut and paste sucks...it upsets the natural order of things and is a blasphemy against all that is good and right in the world. :) if it cant be disabled, then please consider this a wishlist bug report to make it do so. -- while :;do read x;echo \?;done
Re: Potato - update-alternatives (Ian Jackson) and window managers - doubt (and Slink to Potato Success)
Taupter wrote: I was poking update-alternatives, but didn't find a way to point my default window manager to /usr/local/bin/gnome-session. Yes I did read the man 8 update-alternatives, but it was a bit confusing to me (as I think it is a bit confusing to anyone but the man writer aka Ian Jackson), since it was not sufficiently explanatory (at least to me. Shame on me...). Could anyone explain to me the right way to make it work like I want, in the update-alternatives way? update-alternatives --config x-window-manager This will put the alternative in manual mode and pointing to the window manager you have chosen when replying questions prompted by the script. Cheers, -- = Agustín Martín Domingo, Dpto. de Física, ETS Arquitectura Madrid, (U. Politécnica de Madrid) tel: +34 91-336-6536, Fax: +34 91-336-6554, email:[EMAIL PROTECTED], http://corbu.aq.upm.es/~agmartin/welcome.html
Bug#32888: marked as done (base: Removing Obsolete package base kills a system)
reopen 32888 reassign 32888 base-files On Sun, 26 Mar 2000, Hamish Moffatt wrote: On Sun, Mar 26, 2000 at 11:03:27AM -, Debian Bug Tracking System wrote: The base package doesn't exist any more for quite a long time, those first time Debian user are most of them quite good and knows what to do to correct this problem. Furthermore for those who can't, they simply have to not remove the base package (which is guaranteed by its essential flag)... this bug deserves no more to be open. I think we are closing bugs for the sake of it here. Any reason why the suggestion can't be implemented? (ie make base-files.postinst truncate base.list). OK it's not a very nice solution but there isn't a better one. I personally have nuked the base package and lost all my devices this way. base-files will truncate base.list if it exists and will tell the user to read README.base to remove this package safely (doing it automatically would be an ugly hack). Thanks. -- 1e14fb9158b36d0960a96eb7a4010223 (a truly random sig)
Re: Idea: Debian Developer Information Center
Raphael Hertzog [EMAIL PROTECTED] writes: Yes I know, I should probably extract all the identities from a single PGP/GPG key and look for all those adresses in the Packages file. Or something like that. Hmm, /usr/share/keyrings/debian-keyring.gpg lists 278 identities, while the Maintainer fields in my available file lists 543 separate values. -- Robbe
Re: Signing Packages.gz
Anthony Towns aj@azure.humbug.org.au writes: The only reason not to trust a key dinstall uses explicitly for signing Packages is if you believe dinstall is compromised. If you believe that, then you shouldn't be downloading .deb's *ever*, because you're immediately running *untrusted* scripts as root on your systems. That's just the point: the security of a singly-signed Packages.gz would not be much higher than that of the ftp sites themselves. Nothing to win, here. All this FUD about no, no, we can't do that, it's not secure! is, well, just that. *Nothing* is absolutely `secure', some things just have fewer or different exploits than others. Of course. But implementing a scheme that does give only marginally more security may not be worth the effort. Packages should come with their *.changes file, and dpkg should have an option to verify the signature of individual packages. Note that this makes debian-keyring a more or less standard package. Either that, or just let dpkg Recommend it. If it is not installed, package verification is not available. Note that it requires you to trust everyone in that keyring with every aspect of your system. That's already the case, isn't it? Signed packages give you the benefit, that you'll *only* have to trust the maintainers you install packages from - not every man-in-the-middle. Note that this doesn't help with revoking signatures: if some idiot decides that being a Debian maintainer should give him the right to 0wn all the machines that use his package; then gets thrown out; he can still use his key to sign packages that'll be happily installed by anyone with an out of date debian-keyring. Indeed. But I am sure that this fact will get big coverage on the lists and the websites. Debian has handled security leaks in other packages well - this is just a leak in the package system that updating debian-keyring will plug, nothing else. If he can gain control of an ftp mirror, he can keep updating the debian-keyring.deb to include his key, and keep maintaining any packages he likes. No, see below. It also leads to something of a chicken-and-egg situation. It's much easier to verify a *single* key than that every one of five-hundred of the things is uncompromised. (It can be signed by previous versions of itself, it can be widely published in Debian books, it can be signed by the ftp team, etc) The solution is to have one master key (in the hands of a highly trusted person) that is treated like your single key (published everywhere). Every developer's key has to be signed by at least by this key. If one trusts this key, the confidence into keys signed by it is quite high. Additionally, I can verify keys by other means (e.g. those of developers living in my vicinity). Corrupting the debian-keyring package is useless, since the attacker will not be able to put valid (signed by master) keys into it. -- Robbe
Help debugging X program (moonlight)
Hi,
[ please keep me on the Cc:, I'm not on -devel atm ]
this is driving me nuts. moonlight segfaults on start up if libGL.so
is utah-glx's instead of regular mesa's. I have recompiled the
bloody thing against utah-glx's libGL.so (it was using some Mesa
extension that utah-glx doesn't provide) and now I'm dealing with
what seems to be a documentation problem... compiled in `development
mode' (that means don't strip the thing a behave a little different),
I'm getting:
[604 ysabell:~/devel/debian/moonlight/moonlight-0.5.3/src] gdb
main/.libs/moonlight-0.5.3 core
[...]
(gdb) bt
#0 0x401c5627 in ErrorHandler (display=0x804efa8, event=0xb35c)
at XGraphicsSystem.C:138
#1 0x4043ba5d in _XError () from /usr/X11R6/lib/libX11.so.6
#2 0x4043a14b in _XReply () from /usr/X11R6/lib/libX11.so.6
#3 0x404293c3 in XInternAtom () from /usr/X11R6/lib/libX11.so.6
#4 0x401cf84e in set_mwm_border (dpy=0x804efa8, w=41943087)
at set_mwm_border.C:73
[...]
(gdb) list
133
134 #ifndef NDEBUG
135 // crash 'n' burn for debugging purposes
136 char *str;
137 str = NULL;
138 *str = '0';
139 exit(-1);
140 #endif
141
142 return 0;
(gdb) list set_mwm_border.C:73
68 /* setup the property */
69 motif_hints.flags = MWM_HINTS_DECORATIONS;
70 motif_hints.decorations = flags;
71
72 /* get the atom for the property */
73 prop = XInternAtom( dpy, _MOTIF_WM_HINTS, True );
74 if (!prop) {
75/* something went wrong! */
76return;
77 }
(gdb) print *event
$1 = {type = 0, display = 0x804efa8, resourceid = 71, serial = 92,
error_code = 8 '\b', request_code = 1 '\001', minor_code = 0
'\000'}
Error code 8 is (X11/X.h):
#define BadMatch 8/* parameter mismatch */
but XInternAtom(3x) says:
XInternAtom can generate BadAlloc and BadValue errors.
wtf!
Even more confusing, XRequest.1 is X_CreateWindow. X_InternAtom is
XRequest.16... aggghhh! There's a XCreateWindow a few lines
before the call to XInternAtom, but none of the documented reasons
for a BadMatch generated by XCreateWindow are met.
Help? Anyone?
Marcelo
Re: Potato - update-alternatives (Ian Jackson) and window managers - doubt (and Slink to Potato Success)
Taupter [EMAIL PROTECTED] writes: I was poking update-alternatives, but didn't find a way to point my default window manager to /usr/local/bin/gnome-session. FWIW, gnome-session is not a window manager. If you're sure you want to do that, you could issue: update-alternatives --install /usr/bin/x-window-manager \ x-window-manager /usr/local/bin/gnome-session 90 \ --slave /usr/share/man/man1/x-window-manager.1.gz \ x-window-manager.1.gz path-to-gnome-session-manpage (if there is no manpage, leave out the last two lines) Yes I did read the man 8 update-alternatives, but it was a bit confusing to me (as I think it is a bit confusing to anyone but the man writer aka Ian Jackson), since it was not sufficiently explanatory (at least to me. Shame on me...). I agree. Trial-and-error helps. But I think the better way to do this is to start gnome-session from your ~/.xinitrc This way x-window-manager will still start a window manager, not a session manager or whatever. -- Robbe
Re: Removing compiled-by-hand packages
Taupter [EMAIL PROTECTED] writes: 1. Does Debian install any stuff inside /usr/local ? That would be a bug. You can make sure with dpkg -S /usr/local (or dlocate /usr/local if you have the dlocate package) 2. Is secure to the system integrity to _wipe_ /usr/local (no daemons/services stored in /usr/local and such issues)? The sense of _wiping_ /usr/local means removing files/symlinks from /usr/local/bin, /usr/local/lib and such. Since /usr/local is not used by the distribution, anything started from there was started by you. In the future, you may want to look at stow. -- Robbe
Re: Idea: Debian Developer Information Center
On Sat, Mar 25, 2000 at 10:40:27PM +0100, Josip Rodin wrote: Hey people ! I posted this mail in order to have some input ... it would be great if some of you gave their opinion about this proposition I posted a while ago : I guess the silent majority overwhelmingly agrees to your proposal ;) Yeah, I agree this is a great idea :) We want this done by the end of the week :P With this system, each developer can add his own page on one of his bookmark and from time to time he can check what he's responsible for and what he should do in one look. It would be my first bookmark... please do it :) Haha! Pleaase let's call it my.debian.org, *grin*. Now, something like this would be really useful. Jordi -- Jordi Mallach Pérez || [EMAIL PROTECTED] || Rediscovering Freedom, ka Oskuro in RL-MUD || [EMAIL PROTECTED]|| Using Debian GNU/Linux http://sindominio.net GnuPG public information: pub 1024D/917A225E telnet pusa.uv.es 23 73ED 4244 FD43 5886 20AC 2644 2584 94BA 917A 225E pgpzGvF2JlW7x.pgp Description: PGP signature
Re: Idea: Debian Developer Information Center
Le Mon, Mar 27, 2000 at 11:51:19AM +0200, Robert Bihlmeyer écrivait: Hmm, /usr/share/keyrings/debian-keyring.gpg lists 278 identities, while the Maintainer fields in my available file lists 543 separate values. $ gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.pgp --list-key | sort | uniq | wc -l 1211 $ gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.pgp --list-key | grep pub | wc -l 528 [ I used the pgp keyring ... and thoses number are still not significant since one may have several keys (PGP and GPG) ] When I said identities I meant the name + email that can be different for the same guy... Anyway, if the number doesn't match exactly it may be because we have already several dozen of future Debian developers that are sponsored. Cheers, -- Raphaël Hertzog 0C4CABF1 http://tux.u-strasbg.fr/~raphael/ pub CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd Formations Linux et logiciels libres : http://www.logidee.com /pub
Re: RBL report..
-BEGIN PGP SIGNED MESSAGE- It is rumored that on 26-Mar-2000 Nils Jeppe wrote: On Sun, 26 Mar 2000, Mark Brown wrote: ORBS also blacklist sites for other reasons, such as if their probes are firewalled out. This will, for example, catch sites that automatically firewall out sites that attempt to relay through them - the site notices the first check, blocks the rest and gets added to the list. Well I didn't know that, however, that's a pretty redundant thing to do - afterall, you can just disable relaying alltogether and be done with it. ;-) If you are on a 64K line and get hit by a spam blast from some well known providers only the rejects fill your line completely. Unfortunately I have seen this quite afew times and been hit a few years ago by it a few times. So this is actually a good policy. Though if you are smart enough to configure something like this yous hould be smart enough to make it avoid the orbs wrath ;-) [snip] - -- Anton R. Ivanov IP Engineer Level3 Communications RIPE: ARI2-RIPE E-Mail: Anton Ivanov [EMAIL PROTECTED] @*** Sociology's Iron Law of Oligarchy *** In every organized activity, no matter the sphere, a small number will become the oligarchial leaders and the others will follow. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iQEVAwUBON9JjilWAw/bM84zAQEk9AgAjvcaQWoFX9GvpwgYlitlrektqR4OuhYR jgvOWv+hU5IoYpNun9tUeEVbpuhckQqNpLtDoC7OX6lpk7Uim5jKiq3WtTN/LAEg 3u9VJbIydyEI8LUGTruFz5Fl5gaHrF2B1ILPNxcfPK1FVywBXVfM3Rx5CYbH9P8W tcfnpTfS1lX6hiiA0hwPFfiavDe5cAHELKLQczgur1PVfBZdBuYhobfwuMFIEn1T U2dQaBrOmaTzAxh7B6XGkOZ6XcasEENBi5VoqLhd/rK0TTsrhx8/VWGktnjT3Mwi 9qRT1pOfn/cZRdt3qu+B6n+7o2jBHXksSoDVBCuDs+Pob1tfT0udzQ== =531T -END PGP SIGNATURE-
Kernel 2.4, Apache2, X
Surely the solution is simple include deb for (X,Apache,Kernel - NEWSTUFF) as we currently doing for php4 its not installed by default.. but can easily be selected for people having problem with new stuff with a potato 2.2rx coming out in month or so after would making it stabled and included in default installs As slink running @ r5 still only has Stone aged x 3.3.2.3a when everyone else has as part of the install 3.3.6 or an upgrade we still have nether publicly available All newstuff should be included as suggest in potato Mark :) [EMAIL PROTECTED]
Re: RBL report..
-BEGIN PGP SIGNED MESSAGE- It is rumored that on 26-Mar-2000 Hamish Moffatt wrote: On Sun, Mar 26, 2000 at 02:41:09AM -0800, Joseph Carter wrote: The domain's technical contact. Ideally, yes. In practice, I'd say that's no more likely to work than [EMAIL PROTECTED] I've seen NIC entries with technical contacts called NOC Administrator [EMAIL PROTECTED]; do you think hotmail addresses should be acceptable for domain contacts? I don't but apparently Yes. Think of the case when you are out of connectivity and have to change to new dns servers and your auth scheme happens to be mail from:. If your email was from non-neutral ground you would have had to deal with internic personally. Though after the invention of auth-DES and other more sane auth schemes at the registries this is no longer the case but quite a lot of people still keep their info using an off-site address. ;-) [snip] - -- Anton R. Ivanov IP Engineer Level3 Communications RIPE: ARI2-RIPE E-Mail: Anton Ivanov [EMAIL PROTECTED] @*** Uhlmann's Razor *** When stupidity is a sufficient explanation, there is no need to have recourse to any other. Corollary: It seemed like the thing to do at the time. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iQEVAwUBON9LailWAw/bM84zAQEjpwf/YuatKapv0VN6mC4xZnO0FJ7JP9BlddDQ dPhUrN+yffECHptkYYHcuPnVFhhiScZboqEarWnWdUGaswIwpXNO/ROxKJWNlb1h 08z0vIlVRVfw5Vx4eAKpRLRpDlh2vo2qkdmzHLk5dk+KDCv/AEIyyxPqmCyXCUuQ xnVaDt0blmhxy+wA0LV91WVhh4JjGB4D72wf9RhmHcwGJMuOIhv3UIQM8Dx9nCkf bD+zT80w95G9LZfsIaoem7EMWl8FnZsOZgtPuL7zf0IbgaeZkfPkrr9Sv9VDDFd1 q89g/4BhDP3XOn4+rSrWYvRm6yjPz5OReVjg8bc9fWFrVT8/uR8+0w== =yVvu -END PGP SIGNATURE-
Re: Potato - update-alternatives (Ian Jackson) and window managers - doubt (and Slink to Potato Success)
On Mon, Mar 27, 2000 at 12:33:39PM +0200, Robert Bihlmeyer wrote: update-alternatives --install /usr/bin/x-window-manager \ x-window-manager /usr/local/bin/gnome-session 90 \ --slave /usr/share/man/man1/x-window-manager.1.gz \ x-window-manager.1.gz path-to-gnome-session-manpage (if there is no manpage, leave out the last two lines) ...and the backslash at the end of the second line, for those uninitiated ones who might have wondered. /nitpick :) -- Digital Electronic Being Intended for Assassination and Nullification
Re: Bug#32888: marked as done (base: Removing Obsolete package base kills a system)
MoiN On Sun, Mar 26, 2000 at 11:14:06PM -0300, Nicolás Lichtmaier wrote: dpkg-divert --package base-files --divert-to /dev.base/hda /dev/hda Ugh.. ugly... The clean solution is to truncate the file list of base, as proposed. This will release all the files owned by that package safely, with no danger at all. But this will only work as long as the internal format of dpkg's database won't change. But I heard it will definitely be changed in the future. So how will you deal with this change? I just wanted to point out a way _without_ changing any _internal_ structures. I agree with you that it is ugly. But please be careful messing around with dpkg's internals!!! Ingo -- Windows, me?
Re: UPS setup problems (apcuspd and genpower)
This is one of the reasons why I've been happy I bought a Smart-UPS, not only does it provide more information(ammount of battery power and UPS load as well as other information), but the apcd package for APC monitoring worked on it out of the box for slink. Dave Bristel On Mon, 27 Mar 2000, Andreas Tille wrote: Date: Mon, 27 Mar 2000 08:51:51 +0200 (CEST) From: Andreas Tille [EMAIL PROTECTED] To: Thomas R. Shemanske [EMAIL PROTECTED] Cc: Debian Development liste debian-devel@lists.debian.org Subject: Re: UPS setup problems (apcuspd and genpower) Resent-Date: 27 Mar 2000 07:01:59 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; On Fri, 24 Mar 2000, Thomas R. Shemanske wrote: A few days ago, I posted this to the debian-users list, but got no takers. Perhaps someone here has some ideas. OK, if noone else replied I'll give it a trial. Consider me as a fool with the fortune to get a running UPS daemon and not as an expert in this field!! Once I tried *every* single UPS daemon package of the Debian system without any success. The reason was (if I remember right) that they were talking to the UPS via SMART connection (please read more in your documentation about that topic). Unfortunately the cable shipped with my UPS didn't support this mode. It only supportet SIMPLE connection. (Note: Possibly you have to swap the words SMART and SIMPLE in the previous text. They are possibly confused by my unSMART memory :-). ) Please read all the documentation (of the daemon and the hardware) very carefully, which cables you need or how you can build the right cable yourself. After failing with all I tried to package ssd from the APC site. I was successfull in packaging it but it failed to work because of the same reason I stated above. Because I couldn't test it I uploaded it to experimental. May be you give it a triel. But don't blame me if it don't work!! Take it or ask me to remove it from there. Finally I took the smupsd which is shipped with RedHat and happyly I was successful. The package is available in potato. Please check the configuration file very carefully. It needs investigation by hand! (Any volunteers to add debconf stuff to the package??? Unfortunately I have no time for this. May be anyone more experienced than me takes over the package. It is in a works for me state.) May be you can gain more information in a Hardware related mailinglist or newsgroup as I did. Kind regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Potato - update-alternatives (Ian Jackson) and window managers - doubt (and Slink to Potato Success)
[EMAIL PROTECTED] (Robert Bihlmeyer) wrote: Taupter [EMAIL PROTECTED] writes: Yes I did read the man 8 update-alternatives, but it was a bit confusing to me (as I think it is a bit confusing to anyone but the man writer aka Ian Jackson), since it was not sufficiently explanatory (at least to me. Shame on me...). I agree. Trial-and-error helps. I find 'update-alternatives --help' more useful, myself. It's mainly intended for developers, though - I only used it when I wanted to fix broken man page links in various packages. -- Colin Watson [EMAIL PROTECTED]
Re: Bug#32888: marked as done (base: Removing Obsolete package base kills a system)
On Mon, Mar 27, 2000 at 11:15:50AM +0200, Santiago Vila wrote: base-files will truncate base.list if it exists and will tell the user to read README.base to remove this package safely (doing it automatically would be an ugly hack). Thanks, that sounds like an excellent solution. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Signing Packages.gz
On Mon, Mar 27, 2000 at 12:17:47PM +0200, Robert Bihlmeyer wrote: Anthony Towns aj@azure.humbug.org.au writes: The only reason not to trust a key dinstall uses explicitly for signing Packages is if you believe dinstall is compromised. If you believe that, then you shouldn't be downloading .deb's *ever*, because you're immediately running *untrusted* scripts as root on your systems. That's just the point: the security of a singly-signed Packages.gz would not be much higher than that of the ftp sites themselves. Nothing to win, here. Pay attention. There is an existing single-point vulnerability in *every* mirror. Compromise the mirror and you can compromise every single Debian user who upgrades from that mirror. You don't even have to try touching anything at *.debian.org. That is the vulnerability being addressed, not anything else. And note that the vulnerability you quoted above is decidedly difficult to avoid. For example, if you compromise master, you can pretend to just be the new-maintainer team and surreptitiously add yourself as a maintainer. Or you can pretend to be on the ftp team, and surreptitiously add or change existing package, and replace someone else's key with your own, say. So let's run through that again: having a `dinstall' key used to automatically sign Packages.gz: * doesn't solve the insoluble * plugs the main vulnerability * is relatively easy to setup and maintain * is easy to fix, should it be exploited Packages should come with their *.changes file, and dpkg should have an option to verify the signature of individual packages. Note that this makes debian-keyring a more or less standard package. Either that, or just let dpkg Recommend it. If it is not installed, package verification is not available. Let me rephrase that. This makes debian-keyring a base package, since if you want to verify the packages you download, you really want to do it right from the word go, rather than just some time later. This isn't necessarily a bad thing, but it's worth noting since it adds about half a floppy to base. Note that it requires you to trust everyone in that keyring with every aspect of your system. That's already the case, isn't it? Signed packages give you the benefit, that you'll *only* have to trust the maintainers you install packages from - not every man-in-the-middle. It's currently the case, yes, but it *could* be changed. You could, for example setup dinstall so that it wouldn't accept NMUs of certain important packages (such as gnupg). Note that this doesn't help with revoking signatures: if some idiot decides that being a Debian maintainer should give him the right to 0wn all the machines that use his package; then gets thrown out; he can still use his key to sign packages that'll be happily installed by anyone with an out of date debian-keyring. Indeed. But I am sure that this fact will get big coverage on the lists and the websites. And, equally, a deliberately compromised package would probably get a fair bit of coverage too. It'd be nice not have to rely on staying up to date with slashdot and the mailing lists and IRC before doing an apt-get dist-upgrade though. Debian has handled security leaks in other packages well - this is just a leak in the package system that updating debian-keyring will plug, nothing else. The *reason* Debian handles security bugs (security leaks?) in packages well is that we have a mechanism for handling bugs, and we make use of it. The best way to ensure that we always have mechanisms for fixing things is to think about it first, not just handwave it away and say She'll be right, mate. If he can gain control of an ftp mirror, he can keep updating the debian-keyring.deb to include his key, and keep maintaining any packages he likes. No, see below. ...where you add extra complexity to the security model. The originally stated model does have this problem. It also leads to something of a chicken-and-egg situation. It's much easier to verify a *single* key than that every one of five-hundred of the things is uncompromised. (It can be signed by previous versions of itself, it can be widely published in Debian books, it can be signed by the ftp team, etc) The solution is to have one master key (in the hands of a highly trusted person) The phrase is A solution. The highly trusted person you're referring to here is eash member of the new-maintainer team, by the way. that is treated like your single key (published everywhere). Every developer's key has to be signed by at least by this key. And if a developer gets kicked out? You can't revoke a signature (PGP signatures are designed to certify identity, not trustworthyness), so instead you have to revoke the key, and sign everyone else again. Revoke n people, and you have n signatures on every key in the keyring. How elegant. And note that this makes revocation a standard (although
Re: Bug#32888: marked as done (base: Removing Obsolete package base kills a system)
On Mon, Mar 27, 2000 at 03:25:51PM +0200, Ingo Saitz wrote: But this will only work as long as the internal format of dpkg's database won't change. But I heard it will definitely be changed in the future. So how will you deal with this change? Worry about it when it happens. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Signing Packages.gz
On Mon, Mar 27, 2000 at 01:42:47AM +0200, Robert Bihlmeyer wrote: There is no need to check all of [the packages] Well, it'd be nice to be able to do so, to verify that a mirror hasn't been compromised, but no, you're right. Actually, now I think about it, the Packages file itself is valuable information. Consider a Packages file that doesn't actually changes the .deb's, but changes the netbase entry, say to read: Package: netbase Depends: vim Conflicts: nvi, emacsen and leaves everything else the same. You can only achieve fairly petty vadalism with this, but it would still be nice to avoid it, IMO. One thing to consider is that this would make the Package.gz file noticeably bigger. Per-package signatures would naturally accompany the package, not the Packages.gz file. Whose key should be used? Probably a special one just for dinstall, that's kept fairly securely by the Novare and -admin folks, and revoked regularly. This key's security value would not be much above that of the debian machines themselves. Speaking about `more secure than the debian machines themselves' is meaningless. If you can compromise the debian machines themselves, you're home and hosed. You can do anything and everything. And it's a *major* *major* change to the way we do *everything* to try to change that, really. We may *do* everything in a decentralised, distributed manner, but we're *still* one organisation. If you can take over `Debian', by definition you've taken over Debian. You'd get about the same security by a mirror of master, that is administed by the same people (does this mirror exist?). No, it doesn't. And what would such a mirror actually *do*? Just mirror master as it gets compromised, and end up compromised itself? Or should there be three masters which talk to each other and vote on any changes? (And then, somehow, you need to work out how to avoid people compromising all three machines in just one heck, by, say, breaking into one of the personal machines of anyone with root access on all three...) Whose key should be used by entry-level signing? I assume that .debs are created by an automated process with no user intervention. Huh? .debs are never created and uploaded without any intervention, as I understand it. Including ports. They're moved from Incoming to unstable without interaction, but that's about it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgp244VJQnc89.pgp Description: PGP signature
Debconf question
Dear Friends I am working on debconf support for libnss-ldap and libpam-ldap. Since both share some common information (ldap-server and ldap-base-dn) I want to have a shared debconf entry (say shared/ldapns/ldap-server,base-dn). I tryed adding this to the template and config file of both packages and hoped that after installing one lib, db_get shared/ldapns/ldap-server for the other lib would return the value entered in the first lib. But it didn't work. Any help would appreciated :) bye Michael -- GPG Fingerprint = EA71 B296 4597 4D8B 343E 821E 9624 83E1 5662 C734 /\ o \ / ASCII RIBBON CAMPAIGN /|\ XAGAINST HTML MAIL / \ o
Re: 0 days till bug horizon
On Mon, Mar 27, 2000 at 05:38:54PM +0200, Richard Braakman wrote: This is the current list of bugs that are headed for the horizon. I generated it from the bugscan report of Mar 26 15:08, and subtracted the bugs that were fixed by uploads I installed today. I will start removing these packages soon (unless they're too important, in which case we have a different problem). Removal of a package is final. [...] Package: whiptail (debian/main). Maintainer: Enrique Zanardi [EMAIL PROTECTED] 59150 still missing dependency on libnewt0 for m68k [HELP] Maintainer doesnt know how to fix this bug. someone with m68k? whiptail 0.50-6 (current version in potato for i386 and sparc) compiles with -O2 to avoid a gcc bug on m68k. That should be enough to let the m68k buildd recompile this package and fix this bug. -- Enrique Zanardi [EMAIL PROTECTED]
Re: 0 days till bug horizon
On Mon, Mar 27, 2000 at 05:35:30PM +0100, Enrique Zanardi wrote: On Mon, Mar 27, 2000 at 05:38:54PM +0200, Richard Braakman wrote: This is the current list of bugs that are headed for the horizon. I generated it from the bugscan report of Mar 26 15:08, and subtracted the bugs that were fixed by uploads I installed today. I will start removing these packages soon (unless they're too important, in which case we have a different problem). Removal of a package is final. [...] Package: whiptail (debian/main). Maintainer: Enrique Zanardi [EMAIL PROTECTED] 59150 still missing dependency on libnewt0 for m68k [HELP] Maintainer doesnt know how to fix this bug. someone with m68k? whiptail 0.50-6 (current version in potato for i386 and sparc) compiles with -O2 to avoid a gcc bug on m68k. That should be enough to let the m68k buildd recompile this package and fix this bug. I've just checked, and there's a whiptail_0.50-6_m68k.deb in incoming with the right dependency. I'm closing this bug. -- Enrique Zanardi [EMAIL PROTECTED]
Re: Release-critical Bugreport for March 24, 2000
On 24-Mar-00, 03:15 (CST), BugScan reporter [EMAIL PROTECTED] wrote: Package: nvi (debian/main) Maintainer: Steve Greenland [EMAIL PROTECTED] 61035 nvi munches database dump Fixed and in potato. -- 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: python-wxwin
[cc'd to -devel in case anyone else was wondering :-] Hi Yeah, the current packages in the distro are getting rather out of date. I've totally redone the packaging for them so I can now build packages easily from the wxWin cvs but probably wont upload them to the archive until wxWin2.2 is released (real soon now ;-) 2.1.14 has just been released, but is undergoing some fairly heated bugfixing.. really its just a release candidate for 2.2 which we hope to release sometime next month. There will only be a single source package, I've been tweaking the wxWin makefile system to allow me to build all the packages from a single source tree. There will be packages for wxGTK, wxPython (built with gtk) as well as packages of the manual and the samples etc. I'm currently working on packaging for the contrib libs (ogl, mmedia, the new stc lib, and the GLcanvas lib) and they should be ready in time for the 2.2 release as well.. Also there will be packages for wxBase (the non-gui parts of wxWin which can now be used separately). So yeah, I am actively working on them.. expect to see them hit the archives shortly after wxPython2.2 is officially released. (probably about a week after the main wxWin2.2 release date.) best, Ron On Mon, Mar 27, 2000 at 07:16:34PM +0200, André Dahlqvist wrote: Hi I heard from Ben, the previous maintainer of the wxwin-relates packages, that you have taken over maintainership of these packages. I thought I would ask you if you are working on releasing any new versions of these packages soon? There have been a few upstream releases since 2.1.11, and I'm eager to try them out:-) Also, will you be packaging python-wxwin and wxgtk2.1 separately, or will you continue to build python-wxwin as part of wxgtk2.1? The reason for me asking is that Ben mentioned that building them together was done to straighten out some knotty build dependencies, but if he would do it again he would package them separately. Regards // André
Re: 0 days till bug horizon
Package: fetchmailconf (debian/main). Maintainer: Paul Haggart [EMAIL PROTECTED] 57287 generates wrong config files [ Removing fetchmailconf means also removing fetchmail, unless someone uploads a fetchmail version that does not create a fetchmailconf package ] I fixed this one! It was in incoming for weeks. Maybe there was a new upstraem fetchmail still containing the old bugs. I do a fixed upload of fetchmailconfig immediately! bye, -christian- -- Linux - the choice of the GNU generation. Join the Debian Project http://www.debian.org Christian Hammers * Oberer Heidweg 35 * D-52477 Alsdorf * Tel: 02404-25624 50 3C 52 26 3E 52 E7 20 D2 A1 F5 16 C4 C9 D4 D3 1024/925BCB55 1997/11/01
fetchmailconf
Correction to my previous mail: The bug itself can be closed - fetchmailconfig generates working config files now (the ssl options are gone away). The only problem now (as now is version 5.3.3) is that fetchmailconf cannot read its own files a second time :-( I would suggest *not* to remove it as it is at least good enough for its purposes. bye, -christian- (As I don't speak Python and the current problem seems to be a bit more difficult I cannot do anymore to it) -- Linux - the choice of the GNU generation. Join the Debian Project http://www.debian.org Christian Hammers * Oberer Heidweg 35 * D-52477 Alsdorf * Tel: 02404-25624 50 3C 52 26 3E 52 E7 20 D2 A1 F5 16 C4 C9 D4 D3 1024/925BCB55 1997/11/01
Re: 0 days till bug horizon
Richard Braakman [EMAIL PROTECTED] writes: Package: bbdb (debian/main). Maintainer: Frederic Lepied [EMAIL PROTECTED] 59177 xemacs20 didn't compile bbdb-gnus on installation I have spent the last 3 hours attempting to reproduce this with no success. I have tried it both with and without seperate gnus packages, with all of the same package versions as the bug submitter. In the log output we can see that it fails to build the bbdb-gnus.elc target because it can't load a needed file. The file it is attempting to load, gnus, is in /usr/lib/xemacs-20.4/lisp/gnus which is in the xemacs20-support package. Even with -no-site-file xemacs still will find that directory if it wasn't removed by a user. Unless someone else can reproduce this bug, I suggest we either close it, or downgrade it to normal. I suspect it was an issue with the users environment. -- Craig Brozefsky [EMAIL PROTECTED] Free Scheme/Lisp Software http://www.red-bean.com/~craig Hiding like thieves in the night from life, illusions of oasis making you look twice. -- Mos Def and Talib Kweli
Re: 0 days till bug horizon
Richard == Richard Braakman [EMAIL PROTECTED] writes: Richard Package: bbdb (debian/main). Richard Maintainer: Frederic Lepied [EMAIL PROTECTED] Richard 59177 xemacs20 didn't compile bbdb-gnus on installation This should not be a RC bug: bbdb works just fine for emacs19/20, and even the basic package continues to work for XEmacs (for VM users, for example). Only the interface between bbdb and gnus in _one_ of the flavours of emacs is broken; does it justify yanking bbdb despite the fact it works for a large number of people? Richard Package: communicator-smotif-461 (debian/non-free). Richard Maintainer: Adam Heath [EMAIL PROTECTED] Richard 43849 communicator-smotif: Floating point exception error Richard [ We have netscape 4.72 to replace it, but not for all architectures. --RB ] Technically, this is not a part of Debian, and does not, per se, get released. I don't think that bugs on non-fee packages should be considered RC. manoj -- Malpractice makes malperfect. -- Solomon Short 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: Debconf question
Michael Vogt wrote: I am working on debconf support for libnss-ldap and libpam-ldap. Since both share some common information (ldap-server and ldap-base-dn) I want to have a shared debconf entry (say shared/ldapns/ldap-server,base-dn). I tryed adding this to the template and config file of both packages and hoped that after installing one lib, db_get shared/ldapns/ldap-server for the other lib would return the value entered in the first lib. But it didn't work. Any help would appreciated :) Hm. That should work. Any package can access the values of any question in the debconf database. -- see shy jo
Re: 0 days till bug horizon
On Mon, Mar 27, 2000 at 11:55:49AM -0600, Manoj Srivastava wrote: This should not be a RC bug: bbdb works just fine for emacs19/20, and even the basic package continues to work for XEmacs (for VM users, for example). Only the interface between bbdb and gnus in _one_ of the flavours of emacs is broken; does it justify yanking bbdb despite the fact it works for a large number of people? That depends on what happens. Does the install process fail because xemacs20 happens to be installed? Richard Package: communicator-smotif-461 (debian/non-free). Richard Maintainer: Adam Heath [EMAIL PROTECTED] Richard 43849 communicator-smotif: Floating point exception error Richard [ We have netscape 4.72 to replace it, but not for all architectures. --RB ] Technically, this is not a part of Debian, and does not, per se, get released. I don't think that bugs on non-fee packages should be considered RC. They are release-critical for that package. In any case, I think we should have at least one working Netscape to go with a release. It is a special case. Richard Braakman
Missing parse-xf86config breaks login.app [was: Re: New version of xserver-svga gives poorer display on laptop]
On Sun, Mar 26, 2000 at 02:48:49PM -0500, Branden Robinson wrote: On Sun, Mar 26, 2000 at 06:05:43PM +0400, Konstantin Kivi wrote: I also had to add Set_LCDClk 40 to the Device section. Be aware that parse-xf86config used in /etc/init.d/xdm doesn't unserstand it Be aware that because of problems like this, parse-xf86config has been eliminated from recent XFree86 packages. Potato will ship without it. For what it's worth (very little :) this breaks the automatic install for login.app. Personally it's no big deal to edit /etc/inittab by hand, but a newbie might find this troublesome. Perhaps the lines should be added to /etc/inittab but commented out. Should I file a wishlist bug? -- Nathan Norman Eschew Obfuscation Network Engineer GPG Key ID 1024D/51F98BB7http://home.midco.net/~nnorman/ Key fingerprint = C5F4 A147 416C E0BF AB73 8BEF F0C8 255C 51F9 8BB7 pgpvX47ej9JbJ.pgp Description: PGP signature
Re: 0 days till bug horizon
Manoj Srivastava [EMAIL PROTECTED] writes: Richard == Richard Braakman [EMAIL PROTECTED] writes: Richard Package: bbdb (debian/main). Richard Maintainer: Frederic Lepied [EMAIL PROTECTED] Richard 59177 xemacs20 didn't compile bbdb-gnus on installation This should not be a RC bug: bbdb works just fine for emacs19/20, and even the basic package continues to work for XEmacs (for VM users, for example). Only the interface between bbdb and gnus in _one_ of the flavours of emacs is broken; does it justify yanking bbdb despite the fact it works for a large number of people? And as I pointed out previously, it worked for me using xemacs20, both with and without the seperate gnus package. -- Craig Brozefsky [EMAIL PROTECTED] Free Scheme/Lisp Software http://www.red-bean.com/~craig Hiding like thieves in the night from life, illusions of oasis making you look twice. -- Mos Def and Talib Kweli
Re: Potato - update-alternatives (Ian Jackson) and window managers - doubt (and Slink to Potato Success)
Previously Robert Bihlmeyer wrote: FWIW, gnome-session is not a window manager. But it starts one for you, so it would be a good candidate for an x-window-manager alias imho. 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 |
ITP: tinydns and dnscache
Hello, I just subscribed, and I'd like to let the list know I'm (hopefully) going to be working on a couple of new packages, namely tinydns/dnscache by djb, which is a replacement for BIND, and djb's daemontools, (which is required for running tinydns). If you are interested in reading about dnscache and tinydns, please visit the website at http://cr.yp.to/dnscache.html . Version 1.00 was just released. I am currently running tinydns and dnscache on my own two webservers. It is a full replacement for BIND. Right now, I am using rsync to move zone files to my secondary server (which I control), as well as allowing several sites running BIND that slave from me to do secondary (with per-zone configuration of slave servers). It really is a nice package. I would encourage anyone who doesn't like running BIND to take a look at this. --Adam
Bug 59121 (run-parts) (Was: Re: 0 days till bug horizon)
Package: debianutils (debian/main). Maintainer: Guy Maor [EMAIL PROTECTED] 59121 run-parts hangs during /etc/cron.daily runs There's a patch in the BTS. Does someone want to do an NMU or should I? 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: Idea: Debian Developer Information Center
Jordi Mallach ([EMAIL PROTECTED]) wrote: Haha! Pleaase let's call it my.debian.org, *grin*. Now, something like this would be really useful. that's exactly the name i was going to suggest. has the author decided on a language to tame this beast in? if php, i'd love to help. -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) think free speech, not free beer. (gnu foundataion)
Re: 0 days till bug horizon
Package: bbdb (debian/main). Maintainer: Frederic Lepied [EMAIL PROTECTED] 59177 xemacs20 didn't compile bbdb-gnus on installation Instead of removing this package, couldn't we just change the Depends: to emacs20 | xemacs21 ? -- Colin Walters [EMAIL PROTECTED] http://web.verbum.org/levanti (1024D/C207843A) A580 5AA1 0887 2032 7EFB 19F4 9776 6282 C207 843A
Re: 0 days till bug horizon
Le Mon, Mar 27, 2000 at 07:14:57PM +0200, Christian Hammers écrivait: Package: fetchmailconf (debian/main). Maintainer: Paul Haggart [EMAIL PROTECTED] 57287 generates wrong config files [ Removing fetchmailconf means also removing fetchmail, unless someone uploads a fetchmail version that does not create a fetchmailconf package ] I fixed this one! It was in incoming for weeks. Maybe there was a new upstraem fetchmail still containing the old bugs. I do a fixed upload of fetchmailconfig immediately! No ! There's no need for that since my fetchmail NMU was installed. fetchmail ( fetchmailconfig) 5.3.3 is now in potato. In the bug report, someone explained that he can't reproduce it with this version ... i'm closing the bug report since neither potato nor woody has this bug anymore. Cheers, -- Raphaël Hertzog 0C4CABF1 http://tux.u-strasbg.fr/~raphael/ pub CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd Formations Linux et logiciels libres : http://www.logidee.com /pub
Re: RBL report..
Nils Jeppe wrote: ORBS blocks all open relays. A lot of people have open relays. Since open relays still do not have any reason for existence other than admin ignorance, the correct way here would be to block all open relays and then fix the mail servers. ORBS really cuts down on spam, the accounts I have protected by ORBS usually only get one type of spam: that is spam resent via mailing lists. Right, and any debian mail server that comes configured as an open relay should have an important bug filed on it. So long as we default to closed relays on all mailers in debian, I see little problem with using ORBS. -- see shy jo
WNPP
Someone should package AIDE (http://www.cs.tut.fi/~rammer/aide.html). It's a free tripwire replacement. -- see shy jo
Re: 0 days till bug horizon
Richard Braakman [EMAIL PROTECTED] writes: On Mon, Mar 27, 2000 at 11:55:49AM -0600, Manoj Srivastava wrote: This should not be a RC bug: bbdb works just fine for emacs19/20, and even the basic package continues to work for XEmacs (for VM users, for example). Only the interface between bbdb and gnus in _one_ of the flavours of emacs is broken; does it justify yanking bbdb despite the fact it works for a large number of people? That depends on what happens. Does the install process fail because xemacs20 happens to be installed? No it does not, the install process does not fail for the whole of the bbdb package. What happened is that at installation time the bbdb-gnus target fails because the xemacs process byte-compiling it cannot load the gnus file. That means that bbdb-gnus.elc is not built and when bbdb is loaded into xemacs20, at startup time or later, it bombs because it tried to load bbdb-gnus.elc which is not there. I attempted to reproduce this problem but was not able to get the package installation process to bomb when compiling bbdb-gnus for xemacs20. The reason for this is xemacs20-suppport include a gnus distribution, so as long as xemacs20-support is installed (which xemacs20 depends on) that file will be found by the byte-compiling xemacs20 process. If you install the seperate gnus package it compiled bbdb-gnus against that. Being unable to reproduce the bug, and due to the fact that even if it were to mysteriously manifest it only effected xemacs20 users without gnus installed, I see no reason for this to be an RC bug. -- Craig Brozefsky [EMAIL PROTECTED] Free Scheme/Lisp Software http://www.red-bean.com/~craig Hiding like thieves in the night from life, illusions of oasis making you look twice. -- Mos Def and Talib Kweli
woody mutt users, please read
You have to change all lists commands in your ~/.muttrc in subscribe. -- ciao, Marco
Re: 100Mb/Full Duplex
Bdale == Bdale Garbee [EMAIL PROTECTED] writes: Bdale Some folks at work saw similar weirdness with the Bdale negotiation on some HP switch products, their solution was Bdale to configure the switch to not do the auto discovery Bdale protocol, but instead have each port on the switch hard Bdale configured, as 100/full for the machines that could take Bdale it, and less for the ones that can't. What he said. Cisco products are known not to autonegotiate correctly with SPARC networks cards too (speaking from direct experience). The only thing to do is disable protocol negotiation on the switch and force the NIC to the setting you want. -- Stephen Farcical aquatic ceremonies are no basis for a system of government!
Re: Bash and Letter E
Le 2000-03-26, [EMAIL PROTECTED] écrivait : read(0, g, 1) = 1 ^^^ It waits for another key. I typed g here write(2, \7, 1) = 1 ^ Hum. It looks like someone here is behaving as though the Control key was held down. -- [EMAIL PROTECTED]
keyring-maint@debian.org
How long does it take to get your gpg key updated via this e-mail address?
first draft aptitude howto
Hello, need to spell check it, but i guess it might be helpfull anyway: aptitude (c) Copyright 2000, Bernd Eckenfels, Germany aptitude is a front-end to apt and dpkg, the Debian GNU/Linux Package Management tools. It tries to provide a nice user interface to every-day package management on Debian GNU/Linux Systems. This is a short tutorial to help you with using the default installation of aptitude. This tutorial is based on the version 0.5.1 of aptitude. Starting You can start aptitude as non root (for example if you want to look for a package or see a list of new packages, but you can only use it as root to actually change the state of packages on your system. Aptitude is started from the command line in a console window or xterm with the command aptitude. First Steps Aptitude uses APT's cache of available packages. This means you have to configure /etc/apt/source.list like you are used from apt-get. With the 'u' key you ask aptitude to retransmit the lists of available packages from different sources. If there is a new package present, it will be grouped unter New Packages. To tell aptitude, that it should remeber all new packages as seen, you tell it 'f' to forget. With those two keys you usually will type 'u' and then 'f' in aptitude to reset it to its default working mode. In that mode you have a list of: Installed Packages Not Installed Packages Upgradeable Packages Virtual Packages You can open each of this sections by ,oving the cursor to the line and pressing enter. Subsections for the different trees in debian package archives will be visible. If you have a packe selected, you will get information about it in the status line. The 'i' key will show the information/description of the package, the enter key a more complete information about the debian package system values for this package. To leave the information screens, you can use the 'q' key. Within the main tree, the 'q' key will quit the program. In the Not Installed Packages or in the New Packages, or even in the Dpendencies of installed pacages, you can use the + key to mark a package for installation. You can also use the - key on a intalled package to mark it for removal. Packages which are upgradeable can be put on hold with the '-' key, so their desired state is downgraded from upgrade to hold. If you press the '-' key once more, they are even deleted. To purge a package instead of deleting it (purging will remove all data, especially the config files, too) you use the '_' key. If you made your selections (which action should be taken on which package with +, -, _) you press the 'g'o key. Another screen will list you all desred options (which packages will be updated, which installed and which deleted. You can make changes there, too. While pressing 'q' will get you back to the main tree, pressing 'g' a second time will actiate the installation/download/deleting of packages. Additional Keys in aptitude include '/' for searching, 'home', 'end' and 'up' 'down' for navigation. NOTE: with aptitude 0.0.4a (included in potato) you will find it confusing if you dont have support for colors in your term, since: (todo: find the right names for those colors :) white = normal red= broken green = install turkis = remove bl n wh= hold cyan = update (same as green but alrady installed). Also in the 0.0.4a version a split screen view with package details and a key help menu is missing. bernd
