I am trying to record Perl coverage.
I use the ready to use Debian VM from Turnkey running Bugzilla. (https://www.turnkeylinux.org/download?file=turnkey-bugzilla-14.2-jessie-amd64-vmdk.zip)
I was able to install the perl coverage module Devel::Cover, and can record the coverage when executing a perl script in the console.
However, I have problems to record the coverage for the .cgi files when executing the Bugzilla webpage.
I tried several solutions but none led to success:
Setting the enviorment variable like: export PERL5OPT"-MDevel::Cover" (to always run perl with coverage) had no noticeable effect.
Adding use Devel::Cover; to var/www/bugzilla/mod_perl.pl also had no noticeable effect.
Adding use Devel::Cover; to var/www/bugzilla/index.cgi lead to an Internal Server Error when calling the Bugzilla page (the apache2 error log showed a permission error when trying to create directory cover_db). After changeing the permission in directory var/www/bugzilla to maximum access for all I still get the server error but the coverage for the error is recorded, which is weird (the error log shows a bad header error for index.cgi).
I also tried to add the module fia the apache server configurations: etc/apache2/sites-enabled/bugzilla.conf by adding SetEnv PERL5OPT "-MDevel::Cover=-dir,/var/www/bugzilla" there, but this did also not have any noticeable effect.
Does anybody have an idea what the problem could be?
Or anything elso I should try? (I am new to Perl and also not much of a Linux expert)
Could it be a permissions issue, because the server is not run under root as far as I know, but www-data?
Thanks!
Related
I am trying to build custom linux image using yocto. The set up is;
Ubuntu 20.04 on Oracle Virtual Machine
Yocto release dunfell
It gives this error
NOTE: Exit code 127. Output:
/home/user234/yocto-project/image/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/intercept_scripts-1bf6a9721f164ba99b8a07325a9c3fe0f21a700fea55c8351519b59cf02d0aca/update_desktop_database:
7: update-desktop-database: not found
ERROR: The postinstall intercept hook 'update_desktop_database' failed, details in /home/user234/yocto-project/image/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs
The problem only occures in Virtual Machine Environment, It works fine with native linux environment on my other machine.
I have installed the desktop-file-utils and I can run from my shell manually. Somehow, bitbake is unable to detect it. Does someone know the solution?
You can resolve this issue immediately by patching poky sources to skip execution of "update_desktop_database" in this path:
poky/scripts/postinst-intercepts/update_desktop_database
Just comment the line.
It may happen again for other scripts. Just do the same for the other scripts. Finally, the do_rootfs task will complete successfully.
I had a similar problem (without virtual machine, you will see that this part is unrelated). The issue is with file permissions of the Yocto sources, or part of them. In my particular case the DevOps have set the POSIX file permissions on the entire Yocto source directory to 777, i.e. -rwxrwxrwx. Don't ask me why.
In the OP's case it seems like the Yocto sources may have been copied to the virtual machine with a help of some permission-less file system, like FAT32, which results in the same outcome. A good example is copying the sources with a USB flash drive formatted with FAT32. YMMV, this may probably be relevant for ACLs as well, I haven't tried to fiddle with that.
In my opinion, this should be considered as a bug in bitbake. If the source files permissions can cause such an unpredictable behavior, they have to be verified before or during the build, and the user must be informed by generating an error.
This is clearly irrelevant to the OP by now, hope somebody finds it useful.
I have been trying to compile a script that was written in perl by someone other than myself into an executable format that can be used without having perl installed. There seems to be some sort of issue with Crypt::SSLeay packaging but I'm not sure what the error means. Here is a screenshot of the error message.
I've tried using PAR pp and cava to package, both will create executables that run just fine on the machine I'm using that has perl, but whenever I transfer it to a different computer I get the error seen in the screenshot. It's been the same error each time after changing compiler settings, and I'm not sure what to do at this point. If I have left anything out that may assist in answer please let me know and I will be happy to provide, coding is not my field so I am still learning and this is my first encounter with Perl.
First off, you probably do not need and should not use Crypt::SSLeay. However, both the modern Net::SSLeay and Crypt::SSLeay require OpenSSL binaries to be installed on the machine to run.
both will create executables that run just fine on the machine I'm using that has perl, but whenever I transfer it to a different computer I get the error ...
That's because the target machine does not have OpenSSL installed in the same location on which compiled the modules you are bundling.
It might be simple query, but still I'm not clear regarding this.
In my script I'm connecting to SFTP client server using Net::SSH::Perl module. Previously I was using Net::SFTP but removed from the script, as all of a sudden it stopped working and throwing an error.
When I used Net::SFTP, most often I will use the below command to Put/get files from remote server.
$sftp->put("/home/ftpford/ftpcon/conout/$file","/Uti_Integrator/READYFORPICKUP/PENDING/$file");
But I'm not sure of how to get/put files using Net::SSH::Perl.
Can any one suggest? I have tried many ways and even I tried to search in Google but I'm not clear of any thing.
And please note that I don't have privileges to install new modules in my server.
I want to get/put files using the above Module.
I don't think that's a standard feature of Net::SSH::Perl.
One option is to use other modules that do (you don't necessarily need to install them in the system directories, you can have them in your own directories if you include them via PERL5LIB or use lib.
The other option (which answers your question stricto sensu) is to emulate it. You can try to simply run cat >$destination_file on the remote box via Net::SSH::Perl, and then send the contents of the file over the ssh connection.
Of course, error handling and the like might not be very straightforward...
BTW, you tell us you have tried many things, but you don't tell us which, and what problems you encountered.
Running the Twitter Application in Perl and facing the above mentioned problem. The Perl is 5.8.8 and system is AIX with no root access.
Code
./p_t.pl
Error
Unable to load HMAC_SHA1 plugin at
/vv/mm/tt/perl5/lib/perl5/Net/Twitter/Lite.pm line 192
Hwoever
cpan Digest::HMAC_SHA1
is running fine.
O/P
Digest::HMAC_SHA1 is up to date (1.03).
and SHA1 is not running properly
cpan
force install Digest::SHA1
Running make test Can't test without successful make Running make
install Make had returned bad status, install seems impossible
Failed during this command: GAAS/Digest-SHA1-2.13.tar.gz
: make NO
I realize this is an ancient post, but it's high on google, so this advice may eventually reach someone who can use it.
I was fighting with a similar issue, and it turned out my perl distribution did not include integer.pm (part of the distro) and I fixed said bug.
To check if this, or something similar, causes problems in your case, run this script:
#!/usr/bin/env perl
use Digest::HMAC_SHA1;
And check what it fails on.
I have downloaded strawberry PERL and writing one application with CGI Perl Apache on Winxp sp3).
One of the libraries (written by someone else) which I using uses XML::LibXML. When i load the page it gives Internal Server Error. From Apache error log i can see this error:
Can't load 'C:/strawberry/perl/site/lib/auto/XML/LibXML/LibXML.dll' for module XML::LibXML: load_file:The specified module could not be found at C:/strawberry/perl/lib/DynaLoader.pm line 190.
C:/strawberry/perl/site/lib/auto/XML/LibXML/LibXML.dll exists with all permissions.
Also this library works properly on Linux. My application also works fine if I remove all code that needs LibXML.
Can anyone tell me when can be possible issue here.
If you peek into the source for DynaLoader you'll find
Many dynamic extension loading problems will appear to come from
this section of code: XYZ failed at line 123 of DynaLoader.pm.
Often these errors are actually occurring in the initialisation
C code of the extension XS file. Perl reports the error as being
in this perl code simply because this was the last perl code
it executed.
You should have also gotten (but may not have noticed) the following dialog, which provides a more accurate error message:
The problem isn't that perl can't find LibXML.dll; it's that LibXML.dll can't find the real libxml. (The former is just a wrapper that provides Perl bindings for the latter.) To fix that you need to ensure that Strawberry Perl's c\bin folder is in your PATH. In your case, that would be C:\strawberry\c\bin.
You might have to check the environment variable settings in the windows,
make sure that the installation path of the module is present in the PATH variable.
The reason it works in linux is that make files usually set the environment variables for you in linux in windows it may not have set properly.
For eg;
go to Control Panel\System and Security\System click change settings then advanced tab in user variable section see if there is a variable called perl5lib.
if not create an new perl5lib variable and add the path of your library ( usuall C:\Perl\site\lib but may be different in your case)
I had the same issue after installing Strawberry perl. It was working fine when I run the script from server, but not remotely from a automation tool. The issue was because of the Environment variables not updated when we run it remotely. So I did server reboot, which resolved the issue.
I encountered the same problem recently, in my case it was not related to PATH variable (it was already correct). The thing is I was executing my script from Git Bash console and as it turned out git-bash perl was being used instead of Strawberry (see git-bash perl should not be first in path). Switching to standard Windows CMD terminal helped.