> I dropped all references to specific boot loaders since there
> are over a dozend different ones used with linux and people
> beagan to complain that I didn't mention the one they use.
To pull out a cliche, this is "letting the perfect be the enemy of the
good". Covering the two most popular bo
Package: wnpp
Because I no longer use them myself I am looking for someone to take
over the below packages. (The second, binutils-sparc, exists only to
service the first and is a trivial modification of binutils-avr, so I
list them together.)
I'm not swizzling the Maintainer: field to QA because
Well okay, granted ... but the locale would almost always be
explicitly set, and wouldn't change when eg the lat/long are modified.
Package: general
Severity: wishlist
I'm not sure where to assign this, but ... there are too many packages
in Debian that ask for your location or variants thereof, all in an
uncoordinated fashion. To whit:
time zone
latitude/longitude (wmmoonclock, wmsun, various mapping programs)
nearest IC
Years ago, NeXT modified GCC and the rest of the GNU tools to allow
them to produce multi-architecture binaries, so that a single binary
executable could run on both 68k and i386 platforms. They also had a
tool that could strip out hunks for unwanted architectures.
Maybe that code has decayed, an
I'm putting the finishing touches on a packaged version of ADOLC.
This is a low-performance but convenient automatic differentiation
library which uses C++ overloading of arithmetic operators.
The upstream sources contain no copyright notice, but the author has
agreed to place the entire work unde
It looks like a big Linux Beowulf cluster kind of thing is going to be
built here at UNM. Hundreds of CPUs, at least. I'd like to convince
them to use Debian and 21264s, but that's up in the air. One big
issue is finding someone good who could be in charge of systems
software for the beast.
So,
[EMAIL PROTECTED]:
> Instead of the two-cd's-without-source, I'd rather see a special
> lightweight _single_ Debian cd for i386 that carries:
> ...
> A cd like this, with approximately 250 meg binaries, 250 meg sources, 40
> meg documentation, 10 meg kernels and a 100 meg live filesystem would
> ma
Inspired by your cute reboot/halt button hack, I added it plus a
little background color to my own xdm. Everyone here is pretty happy
with the result.
--BAP.
Added to the bottom of /etc/X11/xdm/Xsetup_0
# reboot button
/usr/bin/wish < /var/run/xdmbutt
Package: binutils
Version: 2.6-2
The penultimate line in this excerpt from /usr/man/man1/strip.1
.B \-v
.TP
.B \-\-verbose
Verbose output: list all object files modified. In the case of
archives,
.B "strip \-V"
lists all members of the arch
Package: most
Version: 4.5.0-1
Filenames passed to a shell by most are not properly escaped:
$ most '/usr/doc/tapes/SPEED&MEMORY.gz'
/usr/doc/taper/SPEED.gz: No such file or directory
This allows trojan horse filenames to be constructed:
$ echo gotcha | gzip > 'bug;cp `which sh` hole; chmod u+
Package: dpkg
Version: 1.2.14elf
in dselect's package selection smorgasboard menu, there's this great
big list of packages, one per line. Which is wonderful. But when
scrolling through it for the very first time, during setup of a a
brand new debian gnu/linux system, the user doesn't know how fa
Package: dpkg
Version: 1.2.14elf
dselect knows about upgrades (packages on the currently available
medium that are upgrades of currently installed version) and offers
the user the option of taking advantage of them. But it doesn't have
much notion of packages that are available on the current med
Package: dpkg
Version: 1.2.14elf
When you go through lots of dselect work editing the package selection
menu, then you're done (whew!) and you hit the big INSTALL button ...
before dselect goes ahead and installs stuff, it should give you a
very short description of what it's about to do, and giv
Package: dpkg
Version: 1.2.14elf
When one fires up dselect, puts all packages on hold, chooses one tiny
little package to install --- say, jgraph --- then hits the big
install button ... it takes FOREVER as a long long list of "skipping
deselected package mumble ..."'s scrolls by at an agonizingly
Package: fortune
Version: 2.1-1
The /usr/games/fortune executable is a.out rather than ELF. Either a
dependency upon the old a.out libraries should be added, or the
executable should be recompiled.
$ ldd /usr/games/fortune
libc.so.4 (DLL Jump 4.5pl26) => not found
$ file /usr/games/for
Package: kernel-source-2.0.6
Version: 2.0.6-0
I am an experienced linux person. Even have a little code in the
kernel. Decided to give debian a shot. But I'd like to avoid
learning about debian internals, to the extent possible. On the other
hand, sometimes it is necessary to install the absol
Package: kernel-source-2.0.6
Version: 2.0.6-0
The package currently
Depends: binutils | gas
but actually gas isn't enough: as86 is needed to compile the kernel,
and that program is in the bin86 package. Which should at least be
recommended.
Similarly recommending the gcc package might not be
Package: kernel-source-2.0.6
Version: 2.0.6-0
The file /usr/src/kernel-source-2.0.6/#make.log snuck its way into the
package.
Package: cdtool
Version: 1.0-5
during setup, a prompt reads "... the actuall device ..."
In actuality, actual actually only has one L.
Package: taper
Version: 6.2-1
The taper package recommends the ftape package, which is not available
(at least on the cdrom distribution I have, or on the debian archives
I searched.)
Since ftape is covered by the GPL, if it is recommended then it should
be provided. Unless it is bug ridden ---
Package: xtel
Version: 3.0.7-2
In the information displayed by dselect about xtel, it explains that
"This package is almost for french users."
Package: xautolock
Version: pl10-1
The xautolock package should depend upon xlock (eg xlockmore). Or at
least suggest it.
Package: xbase
Version: 3.1.2-9
The program /usr/X11R6/bin/xf86config contains a typo. When it asks
about the mouse device, it suggests as a possibility the nonexistent
/dev/tty00. The proper suggestion would be /dev/ttyS0.
Package: xbase
Version: 3.1.2-9
The /etc/X11/window-managers file constructed by xbase.postinst
contains fvwm but omits fvwm2. This is somewhat disconcerting if the
fvwm2 package is installed, but not the fvwm package.
Another option would be for the fvwm2 package's installation scripts
to add a
Package: xwpe
Version: 1.4.1-2
there are mismatched parens in the short description of xwpe displayed
by dselect:
>
> xwpe - Programming environment for X11 and character terminals)
>
26 matches
Mail list logo