bug swftools
sr/local/lib -lz -lm gcc -c -DHAVE_CONFIG_H -fPIC -Wparentheses -Wimplicit -Wreturn-type -O -fomit-frame-pointer -I../lib PreLoaderTemplate.c -o PreLoaderTemplate.o gcc -DHAVE_CONFIG_H PreLoaderTemplate.o -o PreLoaderTemplate ../lib/librfxswf.a -L/usr/local/lib -lz -lm Calling ./keybard_viewer to create keyboard_viewer.swf ./simple_viewer || true Calling ./simple_viewer to create simple_viewer.swf ./keyboard_viewer || true Calling ./PreLoaderTemplate to create PreLoaderTemplate.swf ./PreLoaderTemplate || true make[1]: Leaving directory `/home/tatu/Desktop/swftools-0.8.1/swfs' make[1]: Entering directory `/home/tatu/Desktop/swftools-0.8.1' make[1]: Nothing to be done for `all-local'. make[1]: Leaving directory `/home/tatu/Desktop/swftools-0.8.1' [EMAIL PROTECTED]:~/Desktop/swftools-0.8.1$ make check make: *** No rule to make target `check'. Stop. [EMAIL PROTECTED]:~/Desktop/swftools-0.8.1$ make install making install in m4... cd m4;make install make[1]: Entering directory `/home/tatu/Desktop/swftools-0.8.1/m4' make[1]: Nothing to be done for `install'. make[1]: Leaving directory `/home/tatu/Desktop/swftools-0.8.1/m4' making install in lib... cd lib;make install make[1]: Entering directory `/home/tatu/Desktop/swftools-0.8.1/lib' make[1]: Nothing to be done for `install'. make[1]: Leaving directory `/home/tatu/Desktop/swftools-0.8.1/lib' making install in lib/python... cd lib/python;make install make[1]: Entering directory `/home/tatu/Desktop/swftools-0.8.1/lib/python' make[1]: Nothing to be done for `install'. make[1]: Leaving directory `/home/tatu/Desktop/swftools-0.8.1/lib/python' making install in src... cd src;make install make[1]: Entering directory `/home/tatu/Desktop/swftools-0.8.1/src' /bin/bash ../mkinstalldirs /usr/local/bin /bin/bash ../mkinstalldirs /usr/local/share/man/man1 mkdir /usr/local/share/man/man1 mkdir: cannot create directory `/usr/local/share/man/man1': Permission denied make[1]: *** [install] Error 1 make[1]: Leaving directory `/home/tatu/Desktop/swftools-0.8.1/src' make: *** [install] Error 2 [EMAIL PROTECTED]:~/Desktop/swftools-0.8.1$ Im using Ubuntu 7.04 can u help me? - Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: should GNU install call matchpathcon by default?
Jim Meyering wrote: Hi, This morning I noticed a flagrant difference in the speed of make install for the just-released gettext-0.17. It took 12(!) times longer on a rawhide system than on a usually-slower debian unstable system. (3min vs. 15s) I tracked it down to the fact that on that rawhide system, I'm using the latest _upstream_ install binary from (SELinux-enabled) coreutils. The rawhide /usr/bin/install only ever calls matchpathcon (via setdefaultfilecon) when its final chown or chmod fails. Looks like a fortuitous bug in the rawhide patch. The version of install from upstream coreutils calls it every time, since that's the only thing that made sense to me when I redid coreutils' SELinux support. Considering no one can be relying on install's matchpathcon semantics, even in rawhide, I think it should not be the default, upstream -- especially considering the enormous performance hit. Any objections or suggestions from the SELinux folks? Don't have a suggestion on the usage, but your overhead is coming from the loading of the file contexts database on each invocation of /bin/install. You could try to make the gettext installer more judicious about batching things into a single /bin/install command line. Or make install a shell builtin, so that it's not a separate process. There is a new handle-based set of calls that replaces matchpathcon() and friends. See include/selinux/label.h. If you're rewriting this part of the code, I'd recommend switching over. It won't affect performance too much I'm afraid, but maybe at some point there will be a daemon backend of some sort so it just makes an IPC call instead of loading the database in the library code. Do you think coreutils' install should use matchpathcon at all? If so, either it'll have to be associated with a new option, or it'll have to be a lot more efficient. Yes, we've discussed this before, and you guys convinced me to provide the functionality for ease of use. But for those not familiar with the issues, note that you can get the same effect without the embedded matchpathcon call, simply by invoking install with a context provided by the matchpathcon _program_: install -Z $(matchpathcon $dest_file) SRC_FILE $dest_file Can someone can look at making matchpathcon more efficient? I understand that making it the default would be nice, and if it's feasible to minimize the performance impact of that matchpathcon call, it'd be much better *not* to add a new option. Unless I find a magic bullet, I'll disable install's use of matchpathcon for the upcoming test release. Jim In case you're interested in trying a recent snapshot, http://meyering.net/cu/coreutils-6.9-ss.tar.gz http://meyering.net/cu/coreutils-6.9-ss.tar.gz.sig -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [EMAIL PROTECTED] with the words unsubscribe selinux without quotes as the message. -- Eamon Walsh [EMAIL PROTECTED] National Security Agency ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Dan Nicolaescu [EMAIL PROTECTED] writes: Nope, nothing. Can you determine whether processes have SIGPIPE trapped somehow? If so, that's the problem; and you can try to track that down. For example, what does this shell command do? bash -c '(while echo foo; do :; done); echo status=$? 2' | head If it eventually outputs write error: Broken pipe, you have SIGPIPE trapped, and that would explain your problem (which you need to track down). If it prints status=141 you do not have SIGPIPE trapped and we need to investigate the issue further. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Paul Eggert [EMAIL PROTECTED] writes: Dan Nicolaescu [EMAIL PROTECTED] writes: Nope, nothing. Can you determine whether processes have SIGPIPE trapped somehow? If so, that's the problem; and you can try to track that down. For example, what does this shell command do? bash -c '(while echo foo; do :; done); echo status=$? 2' | head If it eventually outputs write error: Broken pipe, you have SIGPIPE trapped, and that would explain your problem (which you need to track down). If it prints status=141 you do not have SIGPIPE trapped and we need to investigate the issue further. The output is write error: Broken pipe. If I execute the same thing in a Linux console it never stops. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Dan Nicolaescu wrote: Paul Eggert writes: bash -c '(while echo foo; do :; done); echo status=$? 2' | head If it eventually outputs write error: Broken pipe, you have SIGPIPE trapped, and that would explain your problem (which you need to track down). If it prints status=141 you do not have SIGPIPE trapped and we need to investigate the issue further. The output is write error: Broken pipe. Then that is a pretty strong indication that your session is trapping SIGPIPE. You will have to debug that to root cause. Something, somewhere in the start path for you is trapping that and it will cause endless problems until it is found and fixed. If I execute the same thing in a Linux console it never stops. Do you mean that on the console that you do not get that error and everything seems to be working properly? That is what we would expect and should be the normal behavior in your other terminals too, but apparently is not. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
[EMAIL PROTECTED] (Bob Proulx) writes: Dan Nicolaescu wrote: Paul Eggert writes: bash -c '(while echo foo; do :; done); echo status=$? 2' | head If it eventually outputs write error: Broken pipe, you have SIGPIPE trapped, and that would explain your problem (which you need to track down). If it prints status=141 you do not have SIGPIPE trapped and we need to investigate the issue further. The output is write error: Broken pipe. Then that is a pretty strong indication that your session is trapping SIGPIPE. You will have to debug that to root cause. Something, somewhere in the start path for you is trapping that and it will cause endless problems until it is found and fixed. Advice on finding that would be welcome. If I execute the same thing in a Linux console it never stops. Do you mean that on the console that you do not get that error and everything seems to be working properly? That is what we would expect and should be the normal behavior in your other terminals too, but apparently is not. Please ignore my statement above, I made a typo on the command line. I run a few more experiments with the bash command above: - when run from an xterm it fails with the broken pipe error - when run from in an xterm like this: bash tcsh bash -c '(while echo foo; do :; done); echo status=$? 2' | head it prints 141. - when run from the Linux console it fails with the broken pipe error. In that case the pstree chain is like this: init - login - tcsh ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
