Master.debian.org down again
It seems that we have a problem with the reliability of the Debian Server.
Could we switch to a network of machines that mirror each other nightly
and enables upload at arbitrary sites? We already have chiark doing
something like that.
Similar things should probably be done to the mailing list.
Also how about having
debian.* newsgroups and running a network of NNTP Servers?
or could we put debian-devel under linux.debian.devel?
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
{}Snail Mail: FTS Box 466, 135 N.Oakland Ave, Pasadena, CA 91182{}
{}FISH Internet System Administrator at Fuller Theological Seminary {}
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
PGP Public Key = FB 9B 31 21 04 1E 3A 33 C7 62 2F C0 CD 81 CA B5
Re: My Packages to go
> p2c > rxvt > ircii > ytalk > tcsh > tf > mandelspawn > lynx > xtron Hi. I think that I'd be interested in p2c if it's what I think it is (a Pascal to C converter). -- Ed Petron [EMAIL PROTECTED] http://www.leba.net/~epetron
Bug#4546: xdm fails when no network present.
Package: xbase Version: 3.1.2-9 xdm fails to work when there is no network card present. X -query came back with 'no valid address'. I was using the default Xaccess file which should allow login from any host. During the installation I specified that the machine was connected to the network.
Bug#4547: X-Server should depend on xfnt*
Package: xserver-svga Version: 3.1.2-5 The X-Server packages should depend on any xfnt package, because without any X-Font the postinst would fail (X -probeonly fails). If it is needed I can investigate if xfnt100 and/or xfnt75 are enough. Regards, Martin
Bug#4548: tset man page appears to be aborted
Package: ncurses-bin Version: 1.1.9e-1 The last line of the tset man page ends in a comma: SEE ALSO csh(1), sh(1), stty(1), tty(4), termcap(5), ttys(5), envi- ron(7), I do not know what ending the author intended, but: -- the comma implies _something_ is missing; -- it seems that terminfo(5) should be among the SEE ALSO's mentioned; and -- it would be nice to know the author of the page (I was curious because it's one of the more clearly written man pages). Susan Kleinmann
Bug#4549: "sac" contains arch dependent compile option
Package: sac Version: 1.3.1-1 1) "Makefile" contains architecture dependent compile option. The following patch corrects this: --- orig/sac-1.3.1/debian/rules Sat Sep 21 11:20:47 1996 +++ sac-1.3.1/debian/rules Sat Sep 21 16:32:55 1996 @@ -17,7 +17,7 @@ build: $(checkdir) - $(MAKE) + $(MAKE) CFLAGS='-O2 -fomit-frame-pointer' touch build clean:
Bug#4550: Build of "ae" fails since it's statically linked
Package: ae Version: 962-9 1) "debian/rules" uses "dpkg-shlibdeps" as you normally would, but for "ae" it's not necessary since "ae" is compiled statically. Unfortunately, "dpkg-shlibdeps" does not handle this case. The following patch corrects the problem: diff -ruN orig/ae-962/debian/rules ae-962/debian/rules --- orig/ae-962/debian/rulesSat Sep 21 16:47:42 1996 +++ ae-962/debian/rules Sat Sep 21 16:52:52 1996 @@ -59,7 +59,6 @@ install modeless.ti debian/tmp/usr/doc/ae/modeless.ti gzip -9f debian/tmp/usr/doc/ae/* gzip -9f debian/tmp/usr/man/man1/ae.1 - dpkg-shlibdeps $(package) dpkg-gencontrol chown -R root.root debian/tmp chmod -R g-ws debian/tmp
Bug#4551: xautolock and xtrlock conflict on screensaver
Package: xautolock Version: pl10-2 Package: xtrlock Version: 2.0-2 If xautolock tries to lock the display (with xlock) when xtrlock is running, the screen flashes black and then returns to showing the X display. After this, the screen saver does not kick in when it should. The lack of a screen saver may lead to monitor burn over extended periods if the user was expecting the screen saver to operate. xautolock should check to see if the display is already locked before attempting to run the locker program. Dave -- Dave Holland <[EMAIL PROTECTED]> Trinity Hall, Cambridge, UK <[EMAIL PROTECTED]>
Bug#4552: xf86config: message is confusing
Package: xserver-svga Version: 3.1.2-5 While configuring this package one is asked the following question: Now give the full device name that the mouse is connected to, for example /dev/tty00. Just pressing enter will use the default, /dev/mouse. Mouse device: /dev/tty00 is the first serial interface on some other unices, such as NetBSD. On Linux this is /dev/ttyS0. I would like to have this changed. :-) Regards, Joey
Bug#4530: ld cannot find most shared libraries
>This is (IMO) a bug in the upstream sources. (I'm not sure whether this >is confined to certain directories or not, especially since libc doesn't >have this problem.) This is the way ELF-ld functions at the moment (as far as I understand it). IMO the programmer's manual (chapter 12) should mention that you should install the -dev packages, if you wish to compile something, since the links are only contained in the -dev packages. Ian? David? David
Re: Bug#4550: Build of "ae" fails since it's statically linked
On Sat, 21 Sep 1996, llucius wrote: > Package: ae > Version: 962-9 > > 1) "debian/rules" uses "dpkg-shlibdeps" as you normally would, but > for "ae" it's not necessary since "ae" is compiled statically. > Unfortunately, "dpkg-shlibdeps" does not handle this case. > This has got to be an architecture thing. I had no problem building the i386 version. It's linked to libc5 and ncurses3.0 (shared), and dpkg-shlibdeps reflects this properly in substvars. Now that I have a chance to think about it, it should probably be linked to the pic versions of these libraries, since it is supposed to run on the base system. What should we do about it? Is there some reason your system builds the package static? Thanks, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Re: Bug#4550: Build of "ae" fails since it's statically linked
On Sat, 21 Sep 1996, Dale Scheetz wrote: > On Sat, 21 Sep 1996, llucius wrote: > > > Package: ae > > Version: 962-9 > > > > 1) "debian/rules" uses "dpkg-shlibdeps" as you normally would, but > > for "ae" it's not necessary since "ae" is compiled statically. > > Unfortunately, "dpkg-shlibdeps" does not handle this case. > > > This has got to be an architecture thing. I had no problem building the > i386 version. It's linked to libc5 and ncurses3.0 (shared), and > dpkg-shlibdeps reflects this properly in substvars. Now that I have a > chance to think about it, it should probably be linked to the pic versions > of these libraries, since it is supposed to run on the base system. > What should we do about it? Is there some reason your system builds the > package static? > I'm sorry it was the "-N" link option that causes "ae" to be linked statically. Is it really necessary to use the option? Leland __ Y_ a_ m_ b_ o_ | The leanest, meanest, fightinest sweet tater on Earth! oo o oo o o | o o o | [EMAIL PROTECTED] o ooo o | -- -- -- -- -- -- | http://www.millcomm.com/~llucius (maybe one day)
Bug#4553: INN crashes
Package: inn Version: 1.4unoff4-1 Recently our news server has begun to crash on a fairly regular basis. It leaves behind the following core file: -rw-r--r-- 1 news news 28004352 Sep 19 18:04 /var/spool/news/core dalesbred:/var/spool/news:[34]% gdb =innd core GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.15.1 (i486-linux), Copyright 1995 Free Software Foundation, Inc... (no debugging symbols found)... Core was generated by `/usr/sbin/innd -p4 -r -i0 -l0'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.5.2.18...(no debugging symbols found)...done. Reading symbols from /lib/ld-linux.so.1...(no debugging symbols found)...done. #0 0x40027b62 in _free_internal () (gdb) bt #0 0x40027b62 in _free_internal () #1 0x40088c54 in __shtab () #2 0x706d6172 in __ypbindlist () #3 0x80c2060 in __ctype_tolower () Cannot access memory at address 0x6e6f2e73. (gdb) The stack trace has been identical in each crash. Any ideas? -- Robert Leslie [EMAIL PROTECTED]
Bug#4530: ld cannot find most shared libraries
David Frey <[EMAIL PROTECTED]> wrote: >>This is (IMO) a bug in the upstream sources. (I'm not sure whether this >>is confined to certain directories or not, especially since libc doesn't >>have this problem.) > >This is the way ELF-ld functions at the moment (as far as I understand it). >IMO the programmer's manual (chapter 12) should mention that you should >install the -dev packages, if you wish to compile something, since the >links are only >contained in the -dev packages. Ah. The problem is, I'm using the XFree86 3.1.2D libraries, with the server currently at 3.1.2Ek (I think; can't remember the exact version.) These libraries _don't_ come with such symlinks, and they aren't added by ldconfig at any point. (that, as an incidental aside, is why vim 4.4 - when I get around to finishing it off, and uploading it - won't have support for X compiled in: incompatible libraries.) This behaviour is extremely annoying, especially if I have to install some other library that isn't available as a Debian package for some reason. (I don't really have the time to maintain more packages - university work and all that.) At least I can work around it. Cheers.
Bug#4554: "dpkg-buildpackage" doesn't pass args to "dpkg-genchanges"
Package: dpkg-dev
Version: 1.4.0
1) "dpkg-buildpackage" is supposed to pass the v, m, and C flags to
"dpkg-genchanges", but it doesn't.
The following patch corrects this:
--- dpkg-buildpackage~ Wed Sep 11 17:20:10 1996
+++ dpkg-buildpackage Sun Sep 22 01:38:03 1996
@@ -106,7 +106,7 @@
withecho $rootcommand debian/rules $binarytarget
$signsource "$pv.dsc"
chg=../"$pva.changes"
-withecho dpkg-genchanges $binaryonly $sourcestyle >"$chg"
+withecho dpkg-genchanges $binaryonly $sourcestyle $version $maint $descfile
>"$chg"
fileomitted () {
set +e
ae as default editor?
Good morning folks, Why is ae the default editor for vipw/vigr even on a completely installed system? Doesn't VI-gr/pw suggest that a VI clone is executed? I can understand to use ae as a fallback editor, but not as the main one # dpkg -l passwd Desired=Unknown/Install/Remove/Purge | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersionDescription +++-===-==- ii passwd 1.0-5 Change password data. Regards, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / Ich glaube nur der Statistik, die ich selbst gefälscht habe! /
Bug#4486: clock bug
The problem still exists with util-linux_2.5-6.
--
Debian GNU/Linux 1.1 is out! { http://www.debian.org/ }
A. B <=> True B. A <=> False
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
PGP Key: [EMAIL PROTECTED] or any other key sites
Re: Bug#4550: Build of "ae" fails since it's statically linked
On Sat, 21 Sep 1996, llucius wrote: > I'm sorry it was the "-N" link option that causes "ae" to be linked > statically. Is it really necessary to use the option? > Well, my man page says: -N specifies readable and writable text and data sec- tions. If the output format supports Unix style magic numbers, the output is marked as OMAGIC. When you use the `-N' option, the linker does not page-align the data segment. none of which seems to have anything to do with static vs shared libraries. Do you have libc5-dev and ncurses3.0-dev installed? I believe that the linker decides whether or not to link static or shared by which kind of library it finds in it's search path. The dev packages provide the shared libraries in the proper place to satisfy the linker. Is your architecture different in this reguard? Thanks, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Bug#4555: msqlperl_1.10-2_i386 installs files in /usr/local
Package: msqlperl Version: 1.10-2 The package installs everything in /usr/local, which should be empty according to the Linux Filesystem Standard. [snip] drwxrwxr-x root/root 0 Sep 18 09:01 1996 usr/local/ drwxrwxr-x root/root 0 Sep 18 09:01 1996 usr/local/lib/ drwxrwxr-x root/root 0 Sep 18 09:01 1996 usr/local/lib/site_perl/ drwxrwxr-x root/root 0 Sep 18 09:01 1996 usr/local/lib/site_perl/i486-linux/ drwxr-xr-x root/root 0 Sep 18 09:01 1996 usr/local/lib/site_perl/i486-linux/auto/ drwxr-xr-x root/root 0 Sep 18 09:01 1996 usr/local/lib/site_perl/i486-linux/auto/Msql/ -r-xr-xr-x root/root 27815 Sep 18 09:00 1996 usr/local/lib/site_perl/i486-linux/auto/Msql/Msql.so -r--r--r-- root/root 0 Sep 18 09:00 1996 usr/local/lib/site_perl/i486-linux/auto/Msql/Msql.bs -rw-rw-r-- root/root 541 Sep 18 09:01 1996 usr/local/lib/site_perl/i486-linux/auto/Msql/.packlist drwxr-xr-x root/root 0 Sep 18 09:01 1996 usr/local/lib/site_perl/auto/ drwxr-xr-x root/root 0 Sep 18 09:01 1996 usr/local/lib/site_perl/auto/Msql/ -r--r--r-- root/root96 Sep 18 08:59 1996 usr/local/lib/site_perl/auto/Msql/autosplit.ix drwxr-xr-x root/root 0 Sep 18 09:01 1996 usr/local/lib/site_perl/Msql/ -r--r--r-- root/root 2983 Sep 18 08:59 1996 usr/local/lib/site_perl/Msql/Statement.pm -r--r--r-- root/root 12058 Sep 18 08:59 1996 usr/local/lib/site_perl/Msql.pm [snip] -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://www.informatik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- "DIE ENTE BLEIBT DRAUSSEN!"
Bug#4523: strace and I/O errors
Please do not apply Frank Neumann's patch. This will break strace on systems where mmap on /proc//mem is prohibited except to root. (This restriction is part of a security measure which should be supported, given the history of horrible security holes with /proc.) Ian.
Re: ae as default editor?
> Why is ae the default editor for vipw/vigr even on a completely > installed system? > > Doesn't VI-gr/pw suggest that a VI clone is executed? I can > understand to use ae as a fallback editor, but not as the main one Probably it is setup for the same reason ae is the default editor on the base disk. A new user, somebody who has only known DOS, WindowsX, or MacOS will probably be completely unable to deal with vi, but will probably be able to handle ae. Because these new users might be told to use vipw or vigr to edit the passwd or group file, it is better to stick them into a "friendly" editor. More experienced users will be able to set their EDITOR variable to call the correct editor (A more experienced user will also be able to get the job done in ae if need be). Jim -- Jim Robinson <[EMAIL PROTECTED]> - http://www.simons-rock.edu/~jimr/ Simon's Rock College.
dpkg changes and queries - the answers to your questions
I've just read debian-devel, and: 0. Yes, all existing packages should now be converted to the new source format, and new packages should be in this format too. 1. Yes, dpkg-source doesn't work with hardlinks. I think that hardlinks in source packages are evil. Perhaps they can be made to work - Heiko's patch seems reasonable (until someone wants a filename containing the string ` link to '). However, I'd recommend just removing the hardlink and replacing it with a symlink (or just deleting one name). There is no problem with doing that, and it is fine wrt our policy about original sources. 2. I don't know what to do about tar doing nasty things to filenames. If this is a design feature of all tars then dpkg-source should be changed to unmangle the filename on output from tar. 3. Do NOT use Michael Meskes's patch to quote the argument to $rootcommand in dpkg-buildpackage. Instead, RTFM. Please DO NOT release a dpkg with Michael Meskes's patch. Thank you. 4. dpkg-name belongs in the dpkg-dev package. If anyone is releasing a new dpkg they should move it. See debian/rules. 5. I don't understand the problem with WIFSIGNALED, but this is definitely a bug in the Perl installation and not in dpkg-source. 6. Karl Sackett's fix for an error message typo (Bug 4524) is good. Heiko, please close the report if you like but definitely mail me the patch. 7. Ives Arrouye asked about `Source: php' / `Package: php-module'. This will work but you have to give dpkg-gencontrol the -p option. There should be no need to have one of the binary packages named the same as the source. 8. Regarding dpkg-shlibdeps: every shared library package should provide a `shlibs' file for the libraries it contains. This is put in the DEBIAN directory when the package is built, and will end up in /var/lib/dpkg/info/.shlibs when it is installed. dpkg-shlibdeps looks there (but earlier versions had a bug). The /etc/dpkg/shlibs.local file is only there to sort things out with the most basic packages before they have shlibs files in the shared library packages. Documentation for this is available. If you find that your package needs a shared library package which doesn't have the dpkg-shlibdeps support why not convert it now ? See the section on other-than-usual-maintainer releases in the policy manual. 9. On permissions of maintainer scripts - this has affected libpng at least: dpkg-source honours the extracter's umask, unlike tar. The debian/rules file should explicitly set the permissions and not rely on (say) cp to copy them correctly. 10. Re dpkg-buildpackage and the failure to build due to permissions (bug 4525). I'm inclined to say "don't build with a umask of 077 then". I don't think that all packages' debian/rules should be responsible for fixing the permissions of the created files. 11. Christian Schwartz posted a Perl script that (I presume) produces much the same output as sed -e 's/ +/ /' | sort +2 does on the Maintainers file in the indices subdirectory of the ftp site. 12. llucius posts a patch to dpkg-buildpackage to make it pass -v, -m and -C to dpkg-genchanges. His patch is not in line with my intent, and won't work when the arguments have spaces. The call to dpkg-genchanges needs to read withecho dpkg-genchanges $sourcestyle "$@" >"$chg" instead of the thing in his patch. (Bug #4554.) I hope this is enough to keep you going for another week :-). Ian.
Bug#4556: inn shouldn't limit message size
Package: inn Version: 1.4unoff4-1 The innd is compiled with a maximum size of news articles. The Eunet company posts monthly news statistics that are longer... Here are the used values: *ott--* ## Largest acceptable article size; 0 allows any size *ott--* =()@>()= *ott--* MAX_ART_SIZE35 Miquel, could you please change this. Regards, Joey
