Re: [Cooker] Licq no worky
Geoffrey Lee <[EMAIL PROTECTED]> writes: >> fcntl: No locks available >> Licq Segmentation Violation Detected. >> Backtrace: >> /lib/i686/libpthread.so.0 [0x4012ce55] >> Attempting to generate core file. >> > > hmm I don't have this problem, can you tell me how to reproduce this? > > Note: the backtrace it goes here is going to be inaccurate, but it looks > like you can't even get as far as libc / libpthread. The reason for the invalid backtrace is that libpthread is stripped. I tried sending a mail to the cooker list about this (but I don't know if it made it - don't remember seeing a request to confirm the email). Also sent a mail to Gwenole and Chmouel since they appeared in the glibc change log. To sum up the problem: When libpthread is stripped, you can no longer debug threaded programs with gdb and backtraces like the above break. I pointed this out to Cooker/Chmouel early 2001 and it was fixed: * Wed Feb 21 2001 Chmouel Boudjnah <[EMAIL PROTECTED]> 2.2.2-4mdk - Exclude libpthread to be stripped also. However in July this year, Gwenole again stripped this library. Please fix this - it's making Mandrake unusable as a serious software development platform (unless you build your own libpthread, which have done). It also breaks backtraces often found in games and applications (that utilize the 'backtrace()' call), making it harder impossible to debug (commercial) applications like that when the user runs Mandrake. -- David -- [ Below is a random fortune, which is unrelated to the above message. ] Recursion is the root of computation since it trades description for time.
Re: [Cooker] urpmi deleting already downloaded packages, and fails with dependencies
[EMAIL PROTECTED] (François Pons) writes: > David Hedbor <[EMAIL PROTECTED]> writes: > >> Hello. Since apt-get no longer works (files used by apt-get aren't >> updated anymore), I am forced to use urpmi for "auto"-updating. In >> general it's ok, but there are a couple of major problems: >> >> 1) urpmi deletes downloaded packages that are not installed. This >>seems to occur when the application is started - any packages not >>to be installed will be removed. This is extremely annoying, for >>example in this scenario: >>- start urpmi --auto-select >>- stop process after downloading 200 MB >>- start urpmi >>- start urpmi --auto-select => downloading starts from the >> beginning >> >> Packages should be deleted only if they are obsolete (i.e older than >> installed) or installed. The best solution, used by apt-get is not >> to delete anything automatically, with a command by the user to >> flush when desired. > > This is the current behaviour of urpmi, will be changed maybe. > > You can use --noclean to avoid this. I think the default behavior really shouldn't be to downloaded but not installed and still valid packages. That flag is nice to know about though. >> 2) urpmi often fails with dependencies. For example I just upgraded >>openssh. "urpmi openssh' failed with a dependency on an old version >>of openssh-askpass. I had to manually specify it. This was extra >>annoying since I got the original failure after downloading 50 MB >>rpms which weren't installed due to the failed dependencies, and >>subsequently deleted as described in issue #1. >> >> Summary: I _really_ miss my apt-get! > > This is a bug on urpmi which has to be fixed. Nice to hear, especially since it's the main reason for #1 to occur. -- [ Below is a random fortune, which is unrelated to the above message. ] mixed emotions: Watching a bus-load of lawyers plunge off a cliff. With five empty seats.
[Cooker] urpmi deleting already downloaded packages, and fails with dependencies
Hello. Since apt-get no longer works (files used by apt-get aren't updated anymore), I am forced to use urpmi for "auto"-updating. In general it's ok, but there are a couple of major problems: 1) urpmi deletes downloaded packages that are not installed. This seems to occur when the application is started - any packages not to be installed will be removed. This is extremely annoying, for example in this scenario: - start urpmi --auto-select - stop process after downloading 200 MB - start urpmi - start urpmi --auto-select => downloading starts from the beginning Packages should be deleted only if they are obsolete (i.e older than installed) or installed. The best solution, used by apt-get is not to delete anything automatically, with a command by the user to flush when desired. 2) urpmi often fails with dependencies. For example I just upgraded openssh. "urpmi openssh' failed with a dependency on an old version of openssh-askpass. I had to manually specify it. This was extra annoying since I got the original failure after downloading 50 MB rpms which weren't installed due to the failed dependencies, and subsequently deleted as described in issue #1. Summary: I _really_ miss my apt-get! -- [ Below is a random fortune, which is unrelated to the above message. ] Idaho state law makes it illegal for a man to give his sweetheart a box of candy weighing less than fifty pounds.
Re: [Cooker] evolution hanging in latest cooker
"Brian J. Murrell" <[EMAIL PROTECTED]> writes: > I have cooker updated as of this morning, including glibc and kernel > and I seem to be having an issue with evolution. It starts up mostly > normal like but just before painting the main widget it hangs. I have > tried removing ~/evolution and also rebooting and the problem still > seems to persist. > > Any ideas? try this: killev killall gconfd-1 gconfd-1 & evolution & or so. I don't know what's wrong, just know that restarting gconfd seems to resolve the issue (temporarily). Then, later I get error about the mail component not being able to talk to evolution. At that point I have to repeat the above. Highly annoying (that's what I get for changing mail reader from Gnus to Evolution...). -- [ Below is a random fortune, which is unrelated to the above message. ] The church saves sinners, but science seeks to stop their manufacture. -- Elbert Hubbard
[Cooker] NFS (cache?) bug with mdk-specific kernels
After a complete crash (user error :-), I reinstalled my box using recent cooker CD's (more or less up to date). Doing so I discovered a problem I had not seen before - newly created files (for example compiled programs) in my NFS home directory were not executable. After some debugging I figured out that the file actually was executable on the NFS server (which is running Mandrake 7.1 with a 2.2 kernel). After some frustration I installed the "plain" kernel, kernel-linus2.4-2.4.16-4mdk to be exact. Now I do not have such a problem. Thus some patch in the mdk-kernels do cause this NFS attribute caching bug (just my guess that the problem is something like that). Broken kernels I've tried with are kernel-2.4.16.11mdk-1-1mdk and kernel-enterprise-2.4.16.11mdk-1-1mdk. Unfortunately I can't use the plain kernel since my main partition uses XFS. If required, I can give exact specs on the NFS server as well (the NFS client is an up-to-date cooker as of the time I write this email). Thanks. -- [ Below is a random fortune, which is unrelated to the above message. ] Q: How many mathematicians does it take to screw in a lightbulb? A: One. He gives it to six Californians, thereby reducing the problem to the earlier joke.
Re: [Cooker] synthesis in contrib
[EMAIL PROTECTED] (François Pons) writes: > Borsenkow Andrej <[EMAIL PROTECTED]> writes: > >> Contrib. has synthesis.hdlist. Can I use it to add contrib to urpmi >> (without hdlist)? What is it used for? > > This is exactly the case, use it with urpmi.addmedia instead of hdlist, urpmi > should notice it and use it accordingly. You may so notice a time improvement to > download it :-) Is there (or will there be) any way to download contrib packages using apt-get? -- [ Below is a random fortune, which is unrelated to the above message. ] Expedience is the best teacher.
Re: [Cooker] latest sawfish not working..
"Frederic Crozat" <[EMAIL PROTECTED]> writes: > On Fri, 26 Oct 2001 20:07:37 +0200, Jorg wrote: > > > latest cooker fresh install from last night. sawfish-1.0.1-1mdk when you > > select sawfish as wm, after login, screen just sits at a blue screen > > with a movable mouse cursor, sawfish never comes up. > > Wrong : it is running. Just click on background with left button mouse However it needs to be rebuilt with the new libpng. It's running but not working (no transparency in PNG's, tons of error output due to png mismatch). -- [ Below is a random fortune, which is unrelated to the above message. ] Oppernockity tunes but once.
[Cooker] Sawfish libpng problem
Just updated sawfish and libpng to libpng 3. It seems like although sawfish now depends on libpng3, it was compiled for libpng2: libpng error: Incompatible libpng version in application and library libpng warning: Application was compiled with png.h from libpng-1.0.12 libpng warning: Application is running with png.c from libpng-1.2.0 It seems to have the effect that png's in themes are not transparent, plus of course, lots of error messages like the above. -- [ Below is a random fortune, which is unrelated to the above message. ] Information Processing: What you call data processing when people are so disgusted with it they won't let it be discussed in their presence.
[Cooker] broken packages or RPM broken?
I'm also seeing the problems with packages not being "installed" (when they are): : 0 root@stellar rpm -q xmms apt/archives/ package xmms is not installed : 1 root@stellar rpm -Uvh xmms_1.2.5-2mdk_i586.rpm libxmms1_1.2.5-2mdk_i586.rpm Preparing...### [100%] 1:libxmms1 ### [ 50%] 2:xmms ### [100%] : 0 root@stellar rpm -q xmms apt/archives/ : 0 root@stellar rpm --rebuilddb apt/archives/ : 0 root@stellar rpm -q xmms apt/archives/ package xmms is not installed : 1 root@stellar rpm -q libxmms1 apt/archives/ package libxmms1 is not installed : 1 root@stellar apt-get dist-upgrade apt/archives/ Processing File Dependencies... Done Reading Package Lists... Done Building Dependency Tree... Done You might want to run `apt-get -f install' to correct these. Sorry, but the following packages have unmet dependencies: bug-buddy: Depends: libglade.so.0 galeon: Depends: libglade.so.0 gdm: Depends: libglade.so.0 gnome-core: Depends: libglade.so.0 gnome-guile: Depends: libglade.so.0 gnome-pilot: Depends: libglade.so.0 Depends: libpisock.so.4 gnome-utils: Depends: libglade.so.0 gtkhtml: Depends: bonobo (>= 0.32) but it is not installed Depends: libglade.so.0 libgtkhtml14: Depends: libglade.so.0 libgtkhtml7: Depends: libglade.so.0 memprof: Depends: libglade (>= 0.7-1) Depends: libglade.so.0 menudrake: Depends: libglade.so.0 nautilus: Depends: bonobo (>= 1.0.7) but it is not installed Depends: medusa (>= 0.5.1) but it is not installed Depends: eel (>= 1.0.1) but it is not installed Depends: fam but it is not installed Depends: libeel.so.0 Depends: libmedusa.so.0 Depends: librsvg.so.1 nautilus-mozilla: Depends: libeel.so.0 Depends: librsvg.so.1 perl-GTK-Glade: Depends: libglade.so.0 pygnome-libglade: Depends: libglade.so.0 pygtk-libglade: Depends: libglade.so.0 sawfish: Depends: librep (>= 0.14) but it is not installed Depends: rep-gtk (>= 0.15-3mdk) but it is not installed Depends: rep-gtk-gnome (>= 0.15-3mdk) but it is not installed Depends: librep.so.9 sawfish-themer: Depends: rep-gtk-libglade (= 0.15-3mdk) but it is not installed xmms-kjofol-skins: Depends: xmms (>= 1.2.0) but it is not installed Depends: libxmms.so.1 xmms-more-vis-plugins: Depends: xmms (>= 1.0.0) but it is not installed Depends: libxmms.so.1 xmms-skins: Depends: xmms but it is not installed Unmet dependencies. Try using -f. : 0 root@stellar apt-get -f install apt/archives/ Processing File Dependencies... Done Reading Package Lists... Done Building Dependency Tree... Done Correcting dependencies... Done The following extra packages will be installed: bonobo eel fam libeel0 libglade0 libmedusa0 libpilot-link4 librep librsvg1 libxmms1 medusa rep-gtk rep-gtk-gnome rep-gtk-libglade xmms The following NEW packages will be installed: bonobo eel fam libeel0 libglade0 libmedusa0 libpilot-link4 librep librsvg1 libxmms1 medusa rep-gtk rep-gtk-gnome rep-gtk-libglade xmms 0 packages upgraded, 15 newly installed, 0 to remove and 389 not upgraded. Need to get 0B/3529kB of archives. After unpacking 9605kB will be used. Do you want to continue? [Y/n] If I do continue the packages are installed but none of them are being recognized as being installed. -- [ Below is a random fortune, which is unrelated to the above message. ] Disc space -- the final frontier!
Re: [Cooker] gcc-2.96
Chmouel Boudjnah <[EMAIL PROTECTED]> writes: > Chmouel Boudjnah <[EMAIL PROTECTED]> writes: > > > David Hedbor <[EMAIL PROTECTED]> writes: > > > > > The bug was fixed in the gcc CVS just a week or so ago and on the 20th > > > I sent a patch for this to Chmouel. It doesn't seem to be applied to > > > the RPM yet though, but I hope it will be. > > > > i am bad i forgot about this one, gonna to make a new release... > > humm sorry hes already included in 0.39mdk. Ah. Only saw 0.38mdk on my mirror. It is recent I presume? -- [ Below is a random fortune, which is unrelated to the above message. ] QOTD: "I've got one last thing to say before I go; give me back all of my stuff."
Re: [Cooker] gcc-2.96
"J . A . Magallon" <[EMAIL PROTECTED]> writes: > On 03.02 Mattias Eriksson wrote: > > > > For you who haven't read about the use of gcc 2.96 you can read the this > > by Linus Torvalds. > > http://boudicca.tux.org/hypermail/linux-kernel/2000week51/0868.html > > > > Well, don't tell only the begin of the story, tell also the end. > If people see the date of the post, it is of Dec 14 2000. Many things > have happend since then. > > Everybody agrees that 2.96 was veru broken at his inital release. But now > it is as good as 2.95.3, if not even better. I think it generates the > best code in all gcc (pseudo)releases. And the initial problems with the > optimizer are solved. I have been building kernels with 2.96 since many [snip] I was struck by a bug in which dependencies generated with -MM (etc) were incorrect for cases where the build directory is separate from the source directory. Basically the dependent was the source file with the source extension replaced with the object extension. The correct behavior is to use the basename of the source file as opposed to the exact path. This incorrect behavior resulted in the object files being placed in the source directory. The bug was fixed in the gcc CVS just a week or so ago and on the 20th I sent a patch for this to Chmouel. It doesn't seem to be applied to the RPM yet though, but I hope it will be. Although this is not related to the stability / correctness of the generated code, it's an example of a bug that only exists in 2.96 (since it didn't exist in any prior versions and is fixed in 3.0). -- [ Below is a random fortune, which is unrelated to the above message. ] Life is a grand adventure -- or it is nothing. -- Helen Keller
Re: [Cooker] new glibc in unsupported directory
Guillaume Rousse <[EMAIL PROTECTED]> writes: > On 2001.02.14 13:03:36 +0400 David Hedbor wrote: > > Chmouel Boudjnah <[EMAIL PROTECTED]> writes: > > > > > David Hedbor <[EMAIL PROTECTED]> writes: > > > > > > > Thank you. I have one question though - why strip (any) libraries? > > The > > > > nice thing with Linux is that your libraries have debug symbols. If > > > > you debug a program, this usually helps a lot when the bug is > > > > triggered somewhere in system or third party libs. I certainly > > > > understand the space savings issue, but it really does make > > developing > > > > on Mandrake a lot less convenient. > > > > > > ...space... most of the end-users don't debug programs... > > > > How about at least having core libraries (mainly the glibc package, > > i.e libc, libm etc), and in the very least libpthreads, unstripped? I > > know that having KDE, Gnome and god knows what unstripped most likely > > would use up way to much space > > What about glibc-debug (or libc, libm, ect...) packages then, as an > alternative to standard glibc (libc, libm...) ? That would be a great thing to have, yes. And I'd suggest the "developer" install choice would use these per default. -- [ Below is a random fortune, which is unrelated to the above message. ] VMS, n.: The world's foremost multi-user adventure game.
Re: [Cooker] new glibc in unsupported directory
Chmouel Boudjnah <[EMAIL PROTECTED]> writes:
> David Hedbor <[EMAIL PROTECTED]> writes:
>
> > Hmm, that's glibc 2.1.3. The problem I'm having is with cooker and
> > glibc-2.2.1. I recompiled the libs myself (well, I used the RPM and
> > grabbed the libs before the build was complete and build tree removed).
>
> which libs ? normally it should since there is :
>
> EXCLUDE_FROM_STRIP=ld-%{version}.so
> export EXCLUDE_FROM_STRIP
libpthread.so is the main problem since, if stripped, it inhibits all
and any debugging of threaded programs.
--
[ Below is a random fortune, which is unrelated to the above message. ]
Many are cold, but few are frozen.
Re: [Cooker] new glibc in unsupported directory
Chmouel Boudjnah <[EMAIL PROTECTED]> writes: > David Hedbor <[EMAIL PROTECTED]> writes: > > > Thank you. I have one question though - why strip (any) libraries? The > > nice thing with Linux is that your libraries have debug symbols. If > > you debug a program, this usually helps a lot when the bug is > > triggered somewhere in system or third party libs. I certainly > > understand the space savings issue, but it really does make developing > > on Mandrake a lot less convenient. > > ...space... most of the end-users don't debug programs... How about at least having core libraries (mainly the glibc package, i.e libc, libm etc), and in the very least libpthreads, unstripped? I know that having KDE, Gnome and god knows what unstripped most likely would use up way to much space -- [ Below is a random fortune, which is unrelated to the above message. ] Nice guys finish last. -- Leo Durocher
Re: [Cooker] new glibc in unsupported directory
Chmouel Boudjnah <[EMAIL PROTECTED]> writes: > Hi, > > Just FYI i let you know that there is a new glibc rpm in unsupported > directory with no STRIPPING librarry which make works gdb. > > one of the unsupported mirors can be found here : > > ftp://ftp.sunet.se/pub/Linux/distributions/mandrake-devel/unsupported> Hmm, that's glibc 2.1.3. The problem I'm having is with cooker and glibc-2.2.1. I recompiled the libs myself (well, I used the RPM and grabbed the libs before the build was complete and build tree removed). -- [ Below is a random fortune, which is unrelated to the above message. ] After an instrument has been assembled, extra components will be found on the bench.
Re: [Cooker] new glibc in unsupported directory
Chmouel Boudjnah <[EMAIL PROTECTED]> writes: > Hi, > > Just FYI i let you know that there is a new glibc rpm in unsupported > directory with no STRIPPING librarry which make works gdb. > > one of the unsupported mirors can be found here : > > ftp://ftp.sunet.se/pub/Linux/distributions/mandrake-devel/unsupported> Thank you. I have one question though - why strip (any) libraries? The nice thing with Linux is that your libraries have debug symbols. If you debug a program, this usually helps a lot when the bug is triggered somewhere in system or third party libs. I certainly understand the space savings issue, but it really does make developing on Mandrake a lot less convenient. -- [ Below is a random fortune, which is unrelated to the above message. ] An ounce of mother is worth a ton of priest. -- Spanish proverb
[Cooker] glibc stripped libraries?
I tried to debug a threaded program in cooker and gdb didn't work as it should. After lots of trouble and investigations, I noticed that /lib/libpthread.so is stripped. This is what breaks gdb. In Mandrake 7.1 it's not stripped and it works (and when I do strip the lib, it breaks). -- [ Below is a random fortune, which is unrelated to the above message. ] At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.
[Cooker] apt-get contrib?
Hey, using cooker now with apt-get (love it). However I miss the ability to apt-get contrib packages. Is this a planned feature (or is there even a way to do this today already?). Also thought I'd report that apt-cache has some problems: : 0 neotron@huitzilopochtli apt-cache search sawfish sawfish - An extensible window manager for the X Window System zsh: 31982 segmentation fault apt-cache search sawfish -- [ Below is a random fortune, which is unrelated to the above message. ] May you have warm words on a cold evening, a full mooon on a dark night, and a smooth road all the way to your door.
[Cooker] glibc fdsetsize problem
It appears that at least glibc 2.1 <= 2.1.3 has a hard limit of 1024 fds in select. This is rather limiting for high-load, single-process webservers (among other things). I have attached a patch that increases the fd limit to 8192 (a hard limit sucks, but 8192 is at least better). Let me know if you want me to upload a patched SRPM. -- [ Below is a random fortune, which is unrelated to the above message. ] Where it is a duty to worship the sun it is pretty sure to be a crime to examine the laws of heat. -- Christopher Morley glibc 2.1.3 fdsetsize patch
[Cooker] nfs-utils-client problem
There are two errors in the /etc/rc.d/init.d/nfslock init file. 1) it looks for the binaries in /sbin/ when they are in /usr/sbin/ (rcp.lockd/rpc.statd) 2) It only runs rpc.lockd when _not_ using a mdk-kernel (the ! shouldn' tbe in the if test). -- [ Below is a random fortune, which is unrelated to the above message. ] Chemistry is applied theology. -- Augustus Stanley Owsley III
Re: [Cooker] USB backport
Chmouel Boudjnah <[EMAIL PROTECTED]> writes: > David Hedbor <[EMAIL PROTECTED]> writes: > > > I just tried the USB syncing with my Visor and noticed that the > > backported code is rather old. To be exact, it spits out a lot of > > debug and if the hotsync is aborted prematurely, and the USB is > > disconnected while the devices are in use, just about all programs > > sigsegv and the kernel is left in a very unstable state. This is > > problems there existed in the very first Visor drivers and have since > > been fixed. > > I don't have any Visor to test, USB is very very unstable for some > devices, what working is : I am aware of that. However the Visor support in 2.3.99 is very good (never had a visor problem with the 2.3.99 kernel. > > Maybe some others devices but i can't guarantee(fix/support) anything. > > > Are there any plans to integrate a never version of the USB support? > > I'd love to avoid using a 2.3 kernel for many reasons... > > The USB backport come from 2.3.99-pre6 i can't upgrade the backport > now and i don't think upgrade to the latest kernel will fix all USB > problems (even with 2.3.* USB is very unstable). Again, I ran Visor USB w/o a problem with the 2.3 kernel. However it does look like the source tree has a new version. Perhaps the backport is more unstable than the 2.3 version. In any case, I did have this exact problem back with the 2.3.40 kernel (or something in that range) and it was fixed. -- [ Below is a random fortune, which is unrelated to the above message. ] Don't get even -- get odd!
[Cooker] USB backport
I just tried the USB syncing with my Visor and noticed that the backported code is rather old. To be exact, it spits out a lot of debug and if the hotsync is aborted prematurely, and the USB is disconnected while the devices are in use, just about all programs sigsegv and the kernel is left in a very unstable state. This is problems there existed in the very first Visor drivers and have since been fixed. Are there any plans to integrate a never version of the USB support? I'd love to avoid using a 2.3 kernel for many reasons... -- [ Below is a random fortune, which is unrelated to the above message. ] I don't get no respect.
[Cooker] Upgrade problems.
I just upgraded two machines to the latest devel using NFS and HD install. The first one, a PII-450/G200/NFS from 7.0 worked great. No problems at all. With the second one, a K6-2/366, SCSI&IDE, Matrox Millennium / 4 MB from Mandrake 6.x using HD method I had the following problems: 1) First time I tired, X crashed (segfault). I had been changing frmo X to console a bunch of times. Probably not much to do about this. On the third try I used X again and it worked (didn't change to console just to be safe). 2) Second time - tried text mode. Got a segfault. Unfortunately I don't remember exactly where it crashed. :-( 3) Third time, X again. Worked fine except when it was time to do the lilo. It insisted in putting the following line in /etc/lilo.conf: append=aha152x=0x140,9 It doesn't work without quotes. I finally gave up and did lilo manually from the shell and rebooted without finishing the install. 4) When I booted, computer died when trying to load USB stuff. I had no time seeing what went wrong (USB flashed and it crashed). After fscking 30 GB of disk (GAH!) I rebooted in single user and removed usb start and it worked fine. The motherboard is an IT5H. -- [ Below is a random fortune, which is unrelated to the above message. ] Without life, Biology itself would be impossible.
[Cooker] upload: sash w/ readline srpm
I uploaded the sash with readline support source-rpm to ftp://ftp.mandrake.org/incoming/ I fixed the dependencies in that version. -- [ Below is a random fortune, which is unrelated to the above message. ] Hatred, n.: A sentiment appropriate to the occasion of another's superiority. -- Ambrose Bierce, "The Devil's Dictionary"
Re: [Cooker] Rescue ISO?
Tim & Val Litwiller <[EMAIL PROTECTED]> writes: > If you have problems with long line in pico use pico -w to turn of > automatic word wrap. That doesn't solve all the problems actually. Lines longer than some number of chars gets wrapped anyway. :) > I think pico is the perfect quick editor, but I would hate to use it to write a > whole web site or some such project. Sure, never said it wasn't ok, but jed is so much better (and somewhat less minimal I guess). -- [ Below is a random fortune, which is unrelated to the above message. ] Mitchell's Law of Committees: Any simple problem can be made insoluble if enough meetings are held to discuss it.
[Cooker] Patch for sash.
Attached is a patch for sash. It enables readline support. The patch
is something I made quite some time ago for myself. It replaces the
-misc patch (includes the same changes plus the readline stuff). The
binary size of sash is increased about 100 KB but I think readline
support is worth that much.
--
[ Below is a random fortune, which is unrelated to the above message. ]
There's no easy quick way out, we're gonna have to live through our
whole lives, win, lose, or draw.
-- Walt Kelly
Summary: A statically linked shell, including some built-in basic commands.
Name: sash
Version: 3.3
Release: 3mdk
Copyright: GPL
Group: System Environment/Shells
Source0: http://www.tip.net.au/~dbell/sash-%{version}.tar.bz2
Patch0: sash-%{version}-misc+readline.patch.bz2
Buildroot: /var/tmp/sash-root
%description
Sash is a simple, standalone, statically linked shell which includes
simplified versions of built-in commands like ls, dd and gzip. Sash
is statically linked so that it can work without shared libraries, so
it is particularly useful for recovering from certain types of system
failures. Sash can also be used to safely upgrade to new versions of
shared libraries.
%prep
%setup -q
%patch0 -p1 -b ".misc"
%build
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"
%install
mkdir -p $RPM_BUILD_ROOT/sbin
mkdir -p $RPM_BUILD_ROOT/usr/man/man8
install -s -m755 sash $RPM_BUILD_ROOT/sbin
install -m644 sash.1 $RPM_BUILD_ROOT/usr/man/man8/sash.8
bzip2 -9f $RPM_BUILD_ROOT/usr/man/*/*
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
/sbin/sash
/usr/man/man8/sash.8.bz2
%changelog
* Sat Feb 26 2000 David Hedbor <[EMAIL PROTECTED]>
- Added readline support.
* Tue Oct 26 1999 Chmouel Boudjnah <[EMAIL PROTECTED]>
- Build release.
* Thu Aug 05 1999 Chmouel Boudjnah <[EMAIL PROTECTED]>
- 3.3.
* Sat Apr 10 1999 Bernhard Rosenkraenzer <[EMAIL PROTECTED]>
- Mandrake adaptions
- bzip2 man/info pages
- add de locale
* Wed Feb 24 1999 Preston Brown <[EMAIL PROTECTED]>
- Injected new description and group.
* Fri Dec 18 1998 Preston Brown <[EMAIL PROTECTED]>
- bumped spec number for initial rh 6.0 build
diff -C 3 -r sash-3.3/Makefile sash-3.3-patched/Makefile
*** sash-3.3/Makefile Sun Apr 18 07:18:46 1999
--- sash-3.3-patched/Makefile Fri Feb 25 23:58:37 2000
***
*** 5,13
# The HAVE_EXT2 definition adds the -chattr and -lsattr comamnds.
#
! CFLAGS = -O3 -Wall -Wmissing-prototypes -DHAVE_GZIP -DHAVE_EXT2
LDFLAGS = -static -s
! LIBS = -lz
BINDIR = /bin
--- 5,14
# The HAVE_EXT2 definition adds the -chattr and -lsattr comamnds.
#
! #CFLAGS = -O3 -Wall -Wmissing-prototypes -DHAVE_GZIP -DHAVE_EXT2
! CFLAGS = $(RPM_OPT_FLAGS) -DHAVE_GZIP -DHAVE_EXT2 -DHAVE_READLINE
LDFLAGS = -static -s
! LIBS = -lz -lreadline -lncurses
BINDIR = /bin
diff -C 3 -r sash-3.3/cmds.c sash-3.3-patched/cmds.c
*** sash-3.3/cmds.c Thu Jun 3 14:42:39 1999
--- sash-3.3-patched/cmds.c Fri Feb 25 23:58:37 2000
***
*** 16,23
#include
#include
#include
#include
!
void
do_echo(int argc, const char ** argv)
--- 16,24
#include
#include
#include
+ /*
#include
! */
void
do_echo(int argc, const char ** argv)
diff -C 3 -r sash-3.3/sash.c sash-3.3-patched/sash.c
*** sash-3.3/sash.c Wed Jun 16 04:02:38 1999
--- sash-3.3-patched/sash.c Sat Feb 26 00:06:47 2000
***
*** 1,4
--- 1,5
/*
+
* Copyright (c) 1999 by David I. Bell
* Permission is granted to use, distribute, or modify this source,
* provided that this copyright notice remains intact.
***
*** 13,21
#include
#include "sash.h"
! static const char * const version = "3.3";
/*
--- 14,26
#include
#include "sash.h"
+ #ifdef HAVE_READLINE
+ #include
+ #include
+ #endif
! static const char * const version = "3.3-readline";
/*
***
*** 479,485
*/
if (!quietFlag && isatty(STDIN))
{
! printf("Stand-alone shell (version %s)\n", version);
if (aliasFlag)
printf("Built-in commands are aliased to standard commands\n");
--- 484,491
*/
if (!quietFlag && isatty(STDIN))
{
! printf("Stand-alone shell (version %s)\n"
! "Readline support added by David Hedbor <[EMAIL PROTECTED]>\n",
version);
if (aliasFlag)
printf("Built-in commands are aliased to standard commands\n");
***
*** 523,528
--- 529,538
int cc;
BOOLttyFlag;
charbuf[CMD_LEN];
+ #ifdef HAVE_READLINE
+ char *rlbuf;
+ char *cp;
+ #endif
if (sourceCount >= MAX_S
Re: [Cooker] Rescue ISO?
"geoffrey lee" <[EMAIL PROTECTED]> writes: > E...!! emacs!! urgh... it's so big and kludged ! :-) It might be big, but I use Emacs for A LOT of things, like writing this email for example. What I like with emacs other than the editor-part is being able to use it for so many things. > I use vi myself. but i guess pico is a good choice. it's nice and easy to > use. I must say I prefer jed. First of all its more emacs-like. Also it's more powerful than pico (which has problems with long lines for example). > So i gues the list of editors could be ed, vi , ex, and pico. > Please remember that the rescue _is_ a minimal distro, which is only for > getting your system back up. it is not a distro for daily use!! so i > wouldn't dream if adding more editors than necessary.. If you have an ISO-rescue-image, there really isn't any reason why it would _have_ to be minimal other than to save potential download time. -- [ Below is a random fortune, which is unrelated to the above message. ] Fun Facts, #14: In table tennis, whoever gets 21 points first wins. That's how it once was in baseball -- whoever got 21 runs first won.
Re: [Cooker] Rescue ISO?
Pixel <[EMAIL PROTECTED]> writes: > "Geoffrey lee" <[EMAIL PROTECTED]> writes: > > > Hi, > > > > oh ok. :) i misunderstood your msg. so you want a ISO image that can be > > burned onto the CD-R for booting when you screw up something on your system? > > As for the rescue. 7.1 should have a good one. > > The idea is to use a rescue_stage2.img instead of mdkinst_stage2.img > this file should be less than 15MB to fit in ramdisk. That way the cdrom can be > removed after booting and replaced by another one :) Sounds nice. The only thing I want to avoid is having to use floppys. If it can fit on the normal CD - great! Please consider having some editor other than vi though, like jed or at least pico. We emacs people don't like and can't use vi* and since emacs couldn't fit in 15 MB... :) -- [ Below is a random fortune, which is unrelated to the above message. ] Lazlo's Chinese Relativity Axiom: No matter how great your triumphs or how tragic your defeats -- approximately one billion Chinese couldn't care less.
Re: [Cooker] Rescue ISO?
"geoffrey lee" <[EMAIL PROTECTED]> writes: > Hi, > > If your system is too broken to even use sash (linux 1 at the lilo boot > prompt.) why don't you check out tomsrtbt... Well, often when I need a rescue disk is if I screw up a kernel install. I normally do this now by booting the normal install and using the shell vt to mount the harddrive and run lilo from it. So running sash won't help since the system won't boot. :) > It uses kernel 2.0 + libc5 i think, but i hear that if you want to use glibc > you can, provided that yo have glibc placed somewhere on the hasrd drive, > and you can use chroot. a lot of the commands in toms are actually clevwerly > written shell scripts. That is just a thing - something that uses the same kernel, libc and other tools would be a lot more valuable to me. > Vim and emacs?!! they wouldn't fit on one floppy...btw, tomsrtbt does have > vi. Well, that is why I was taking about making a CDROM ISO image. :) I might simply do an install in vmware and make a iso of the entire installed filesystem with single user as the default boot mode. The problem then is that you'll get some weirdness with a read-only filesystem. To do it "right" you would want at least /etc/ mounted on a ramdisk. -- [ Below is a random fortune, which is unrelated to the above message. ] If anything can go wrong, it will.
[Cooker] Rescue ISO?
Since I stopped using Slackware oh so many years ago, I haven't used one distribution with a good rescue disk using standard tools. I have never checked out the Mandrake rescue disk either - mostly due to the requirement of actually using a floppy. What about providing a second iso-image that is a bootable system, for rescue work. It could include all kinds of useful tools and not just some weird special environment like the Redhat rescue (again, haven't tried Mandrake's but Redhat's has always been completely useless). Basically, put the best system recovery tools and also stuff like your "favorite" editor like vim and emacs on a decently sized, bootable ISO image. Not only would it incredibly useful - I think it would be a great to use when trying to convince people in upgrading to Mandrake. What do you think? -- [ Below is a random fortune, which is unrelated to the above message. ] Hey, what do you expect from a culture that *drives* on *parkways* and *parks* on *driveways*? -- Gallagher
Re: [Cooker] Acrobat reader NS plugin problem
Giuseppe Ghibò <[EMAIL PROTECTED]> writes: > Geoffrey lee wrote: > > > > hi, > > > > not sure, maybe evne though youu've got it installed the symlink is missing. > > Make sure the symlink is there and it point to the right place. on my mdk 6 > > it points to libc.so.5.3.12. > > It's a matter of linkage of the plugin. You have to use our RPM > version we provided in Applic CD (and it was on Cooker/contrib some > time ago, I don't remember if still there), where we patched > nppdf.so. If you install Acrobat from standard tgz instead you get > from Adobe site it won't never work under glibc netscape (only way > in that case is to use netscape libc5 or move libc 5.3.12 into > /usr/lib/netscape and change LD_LIBRARY_PATH into /usr/bin/netscape > adding /usr/lib/netscape in the path list. You know, when you mentioned patching the so-file I figured that binary patching is always fun. So I did. It worked! What I did is extremely simple. I just looked for libc - the string is only there once. It says "libc.so.5". I changed it to "libc.so.6", saved and that's it - everything now works. Thanks for giving me the idea. I don't know what the license is on acrobat and whether distributing a binary patched version would be ok. -- [ Below is a random fortune, which is unrelated to the above message. ] "The identical is equal to itself, since it is different." -- Franco Spisani
[Cooker] Acrobat reader NS plugin problem
Hello, This is a problem that baffles me - sometimes it works, sometimes it doesn't. It is rather frustrating though. Anyway, the problem is loading the PDF plugin. It's linked to libc5, which is probably the main problem: ERROR: libc.so.5: cannot open shared object file: No such file or directory Cant load plugin /usr/lib/netscape/plugins/nppdf.so. Ignored. Error message speaks for itself. It doesn't find libc.so.5 even though it certainly does exist. Interestingly enough I have gotten it to work when installing my own netscape on a Mandrake 6.1 system. Any ideas? -- [ Below is a random fortune, which is unrelated to the above message. ] Please go away.
