First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 116739
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Luca Longinotti <chtekk@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Michael Cramer <portage@bigmichi1.dyndns.org>
Add CC:
CC:
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 116739 depends on: Show dependency tree
Bug 116739 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2005-12-25 15:14 0000
emerging these package with the USE-Flags: "crypt -debug login-watch
mounts-check mysql -netclient -netserver postgres prelude -static suidcheck
userfiles -xml" results in not compiling the database backend, because both are
enabled, disabling one of them fixes this and the backend will be recognized
during ./configure. it seems the confugre script has problems with option
specified more than ones.

------- Comment #1 From Michael Cramer 2005-12-25 15:28:52 0000 -------
also it would be nice to have a use flag for the kernel module "--with-kcheck="

------- Comment #2 From Luca Longinotti 2005-12-25 16:46:38 0000 -------
Thanks for spotting the database conflict problem! I now added a check to
app-forensics/samhain-2.1.1a so that, if you have both postgres and mysql
enabled, it dies, warning you that you need to choose between one of them for
it to work correctly.
I won't add a flag/support for the kernel relative parts of Samhain to the
Samhain ebuild, since they are Linux/FreeBSD specific (there are other ports
for Gentoo), work on x86 only (Gentoo has many architectures), are relatively
troublesome to configure, and require a System.map (not all machines have this
around). If you want protection for such kernel problems, GRSecurity takes a
better, proactive approach, and I'd recommend that.
Best regards, CHTEKK.

First Last Prev Next    No search results available      Search page      Enter new bug