Question regarding aur, PKGBUILD and namcap

PlusMinus · 2016-09-16 11:10:10

About half a year ago I started maintaining the orphaned package displaylink and just today I put the required libevdi into it's own package. When I check the package with namcap, a few questions arose.

For evdi

The module has to be installed via dkms so I install the code into /usr/src/evdi-$pkgver, resulting in this output of namcap (shortened):

evdi W: File (usr/src/) exists in a non-standard directory.
evdi W: File (usr/src/evdi-1.2.55/) exists in a non-standard directory.
evdi W: File (usr/src/evdi-1.2.55/evdi_fb.o) exists in a non-standard directory.
[..]
evdi E: ELF file ('usr/src/evdi-1.2.55/evdi_fb.o') outside of a valid path.
[..]
evdi W: Dependency included and not needed ('dkms')

How do I get rid of the non-standard directory warning?
how do I get rid of the valid path error?
Why does namcap not realize that dmks is needed (in evdi.install)

For displaylink

As mentioned, I removed the libevdi.so from the package because it always fails to compile when a new kernel is released. This makes maintaining it easier. namcap of new package

displaylink E: Insecure RPATH '.' in file ('usr/lib/displaylink/DisplayLinkManager')
displaylink W: Directory (var/log/displaylink) is empty
displaylink E: Symlink (usr/lib/displaylink/libevdi.so) points to non-existing /usr/lib/libevdi.so
displaylink W: File (var/log/displaylink) does not have the world readable bit set.
displaylink W: Directory (var/log/displaylink) does not have the world executable bit set.
displaylink E: Dependency libusb detected and not included (libraries ['usr/lib/libusb-1.0.so.0'] needed in files ['usr/lib/displaylink/DisplayLinkManager'])
displaylink W: Dependency included and not needed ('evdi')
displaylink W: Dependency included and not needed ('grep')
displaylink W: Dependency included and not needed ('gawk')

What does insecure RPATH mean? I know which directive is responsible, I just don't get what it means
Why does it matter that the log folder is empty? Should i create an empty log file?
It is true that the symlink points to a non-existing file in this package, but it does exist on the system. Why does namcap not see this?
Does it matter that the world readable bit is not set? I guess I could change it.
But does a log directory/file really have to be executable
libusb is shipped with the original ubuntu installer and I din't try changing that yet, but why does it think, the package depends on it, when the dependency is actually shipped?
And then namcap complains that an actual dependency is not needed
grep and awk are obviously needed during package() why does namcap say otherwise

I would really appreciate it, if somebody could answer all my questions (sorry that they are so numerous). To me it seems like namcap just isn't suited for checking the packges and I don't know why it is recommended to do so.

Awebb · 2016-09-16 12:36:07

Well, namcap is very well suited for "checking the packages", but you're trying to tighten a screw with a dildo. A valid statement would be, that namcap isn't fully DKMS ready yet. I mean, if you push the dildo hard enough into the screw, it will eventually take the right shape, but the result won't be as satisfying. Namcap still gives you valuable information, but you should not rely on namcap alone.

Homework: What is the difference between E: and W: in namcap's output?

evdi

a) You don't, the error is valid, at least from where namcap is standing.
b) Well...
c) I'd say namcap is not yet dkms aware. Read the DKMS article on the Arch wiki, there is a "namcap output" section. You might call this plain and simple a namcap bug.

displaylink:

a) I don't mean to be a smartass, but I did the google "insecure RPATH" thingy and the first result was https://bugs.archlinux.org/task/14049. I think it explains it very well.

b) It's not so much about being an empty log directory, but about an empty directory. It also has the W: not the E:, so it's a warning and not an error. It's trying to tell you, that you might be doing something stupid, but it's a nice chap about it.

c) If it's a log file, it should be world readable, unless there are reasons to prevent other users and processes from reading the log. Many people believe, that log files should be "restricted on demand" and not by default. Imagine a user process trying to read the log file (it's about a display over USB, if I'm not mistaken, so there is a lot of non-root involved) and it's not there. However, the W: (warning) does not indicate an error, it's only trying to warn you about something that more often than not causes problems. In this case, namcap doesn't know, whether displaylink is a file or a folder (it says file).

d) It does...

e) because if it's a directory (and it identifies it as a directory this time) and if it is not something super secret, then it needs the global x flag. Try it yourself, create a directory, unset the x flag and try to cd into it. However, again, it's a W: (warning) and up to your own discretion. For the global question, see c).

f) See a). I think it gets confused over your insecure RPATH.

g) I'd say this is another DKMS problem, in case of evdi, because there is no package, that owns the file it's looking for. That file is being created by DKMS.

h) Missing feature in namcap.

Conclusion: Instructions unclear, screwdriver stuck in ceiling fan.

Last edited by Awebb (2016-09-16 12:37:14)

PlusMinus · 2016-09-16 12:47:36

Thank you for your reply. I still don't quite fully understand the RPATH issue (I found the link before), but I'll read it again when I find more time for it.

I think you answered the wrong question in you c) answer. It's probably as well nothing I should worry about, right?

I'll fix the log file part next week.

Thanks again.

Awebb · 2016-09-17 16:54:42

Yes, c) is off. I used namcap to check my response. Identifying wrong alphabetic list markers is not supported yet. Didn't even throw a W:.

Last edited by Awebb (2016-09-17 16:54:58)

Arch Linux

#1 2016-09-16 11:10:10