Error opening /var/log/audit/audit.log (No such file or directory)
Do you even have audit enabled? - I know I don’t.
My grub command line looks like this: GRUB_CMDLINE_LINUX_DEFAULT="mitigations=off audit=0 udev.log_priority=3"
That file indeed does not exist and this is normal (for me) and intentional.
And even if it is enabled, the audit messages might not go to this file, but to the system journal instead. journalctl ...
But that I don’t know.
@BG405 Thanks. I think this is fairly safe as things go, provided you are careful. Fortunately, I’ve just been running makepkg so that an installable package is created, but not makepkg -i to install that package. After makepkg, there’s a built Emacs located in the package subdirectory that can be run to test if everything works before installation. As far as I can tell, everything seems fine, but I want to double check.
@Nachlese This is interesting – could you say more about how audit is configured? My /etc/default/grub has no mention of audit in it, and auditd.service is inactive (dead) according to systemctl.
No, I can’t. (but as it turns out I will anyway )
I knew that I didn’t want it, because I wouldn’t look at it’s log messages anyway, so I disabled it by way of this grub parameter (and out of habit).
Then this sounds like a good explanation for the non-existent log file.
I’d say that it is not important how prevalent it’ use is
but rather whether you want or even need the functionality.
If this is the only test that failed (and you know why it failed), why not just forget about it?
You could also create that file, thereby cheating on yourself so that the test will be happy …
You could also create that file, thereby cheating on yourself so that the test will be happy
That’s a good suggestion … which would be very ironic because part of the reason I’m trying to use the PKGBUILD framework is because I was recommended that it would be better to install packages this way rather than just installing it via make and registering it with pacman via another shortcut (see here).
You decided to run the built in tests, which are not run, not enabled, when you use the compilation options in the PKGBUILD.
You should know what these tests do - why they are there - what they test for - and what it means when a test fails.
In this case:
I don’t know the test condition or purpose - you can know (learn) that by looking at the file that defines the test conditions.
… it seems to be the simple existence of the file - you just need to look at the file that runs the test …
What you seem to misunderstand:
the PKGBUILD is the very same as you running “make” with specific parameters, so that the result will well integrate with the system.
You could just as well run “make” yourself - but then the package manager wouldn’t “know” about what you did (which is the entire purpose of a package manager - to reliably keep track of what is in the system, how to update it, how to remove it).
You can do all that yourself - greetings from LFS (Linux from Scratch) - but even they have implemented a way of tracking what is done to the system.
I assure you, this is the one part I do understand! The point is that I have previously built Emacs by downloading and extracting the tarball and running make via ./configure. The problem was that even after symlinking the package so that my system would detect it, there were issues with “helper” programs for Emacs packages not recognizing the current Emacs version, so I had to write a pseudo-package file for Emacs (with only details like the name and version number) and ran makepkg -i so that this would register my built Emacs in the package database.
This time, rather than go the “fake” way I decided to do the “proper” thing and put all my configuration flags into a PKGBUILD file and build + register it in (more-or-less) one go. Unfortunately I’ve tried to be extra careful and run the tests as well, but now it seems the best advice would be to “fake” the test condition and continue (or not just run the tests). Hence the irony.
(Or maybe to you “irony” is just something in an Alanis Morissette song …)
among other modifications, to the default PKGBUILD file, because I previously used to run tests when building Emacs “by hand”.
However, including this would cause the whole makepkg process to abort, because of the test result shown above. I wasn’t sure what the cause of this test failure was – something trivial or something wrong with the build process, because it doesn’t occur when I build “by hand”.
perhaps your check() function wasn’t placed right inside the PKGBUILD?
I’m tinkering right now - first it needs to finish building the thing - then I’ll try to learn and run the “make test” by hand …
my system is not the fastest - and this happens in a VM as well
It looks like it does because they’re building what they believe to be all the most popular Emacs configurations that Arch-based distro users want! This is a simplification of it to get rid of the useless emacs-wayland builds which I don’t need for my system.
Come on, don’t be afraid of tinkering with code – that’s what Linux is all about!