Re: lilo removal in squeeze (or, "please test grub2")
In gmane.linux.debian.devel.general Stephen Powell wrote: > But like lilo it stays out of unallocated (and therefore not backed up) > sectors. The boot block of extlinux is installed in the boot sector > of a partition, and the second stage loader occupies a file within the > partition. It does not use the master boot record. It relies on a > master boot record program to chain load it from the partition boot > sector. (I use the mbr package for that.) BTW, you can install grub exactly the same way. I usually do this because I absolutely don't like the idea to install something as important as a boot loader into unallocated sectors. Just do "grub-install /dev/sda1" and Grub will adapt its installation procedure accordingly. It's a pity that this isn't documented more prominently... Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/htl90g$hu...@dough.gmane.org
Bug#560744: O: xview -- XView UI toolkit library and client programs
Package: wnpp Severity: normal I'm orphaning the XView package, containing the XView UI toolkit libraries plus a few applications using them (most notably olwm/olvwm). I haven't used it for a long time and I guess it's finally time to let it die in peace. However, for some strange reason, some parts of XView (e.g. olwm and olvwm) are still quite popular and the XView libraries still seem to be used for a few scientific applications. If you're brave enough to adopt that package, please take into account that there is no upstream (there hasn't been one for years), so all bugfixes will be your responsibility. Please also take into account that most of the code was written in the early 90's and as such is quite ugly by today's standards (e.g. not at all 64 bit clean and nearly impossible to fix). Reverse dependencies from other source packages are: treetool arb xvmount xjove workman imaze-xview circlepack Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dselect features request
On Fri, Dec 19, 1997 at 01:49:59PM -0500, Scott Ellis wrote: > Unfortunatly, that is because of the way dselect runs dpkg (dpkg -iGROBE), > which then goes through the directorys and checks every package. I did a quick hack on dpkg last week to speed up -iGROEB. Basically, the patch does the following: When dpkg runs `find -name "*.deb"', it checks whether every file found looks like 'name_version*.deb'. If all files match that pattern, my patched dpkg assumes that all the filenames are valid and contain the real package-name. It then skips those packages that aren't marked for installation without even reading their control-file (this causes a major speedup because on an average system, only a minority of all available packages are installed). Orignially, I also wanted to read the package's version from the filename, but that doesn't work because the epoch is missing. My patch is definitely not as foolproof as the current method, but I think it's good enough. You can have a look my completely unofficial and experimental version at http://meteosat.e-technik.uni-ulm.de/~mbuck/dpkg/ . There's a .deb-package for libc5, the diff for dpkg 1.4.0.8 and a dpkg-binary for libc6 (not .deb-package, sorry). I'd like to know what people think about it before trying to get the patch into the standard dpkg. Thanks, Martin -- /* Martin Buck E-Mail: [EMAIL PROTECTED] */ /* Student of electrical engineering WWW: http://www.uni-ulm.de/~s_mbuck1/ */ /* University of Ulm, Germany Snail-Mail: Paukengasse 2, 89077 Ulm, Germany */ #include /* PGP Key availableMIME-Mail welcome */ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: why are shared libs chmod +x? (again)
On Fri, Jun 27, 1997 at 11:03:25AM +0200, joost witteveen wrote: > The only reason I remember is that the shared libraries are > "executed", only not from the commandline, but within other binaries. Yes, but the file mode suggests that they can be executed from the commandline (or by calling execve(2), more precisely). After all, only execve(2) cares about files having their executable bits set -- ldso/mmap works fine without. I don't think that "telling the user that the file may be part of an executable" is a good reason for using mode 755. If a user wants to know more about the purpose of a file, he can use file(1) and get a much better answer. Martin -- /* Martin Buck E-Mail: [EMAIL PROTECTED] */ /* Student of electrical engineering WWW: http://www.uni-ulm.de/~s_mbuck1/ */ /* University of Ulm, Germany Snail-Mail: Paukengasse 2, 89077 Ulm, Germany */ #include /* PGP Key availableMIME-Mail welcome */ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
