Summary: | sys-apps/man-db keyword request | ||||||
---|---|---|---|---|---|---|---|
Product: | Gentoo Linux | Reporter: | SpanKY <vapier> | ||||
Component: | Keywording | Assignee: | Gentoo/BSD Team <bsd+disabled> | ||||
Status: | RESOLVED OBSOLETE | ||||||
Severity: | normal | CC: | cjwatson, esigra, kumba, pinkbyte | ||||
Priority: | High | Keywords: | KEYWORDREQ | ||||
Version: | unspecified | ||||||
Hardware: | All | ||||||
OS: | FreeBSD | ||||||
Whiteboard: | |||||||
Package list: | Runtime testing required: | --- | |||||
Attachments: |
|
Description
SpanKY
![]() fails to link here: it's missing a lot of -lintl at link step btw the ebuild should probably depend on virtual/libintl (not sure if that's related to the nls useflag) (Hi, I'm the upstream maintainer.) Could you try man-db 2.5.3? Mike just committed an ebuild for it. Also, could I have the complete build log, including configure arguments, so that I can work out what's going on in the event that this is still happening? Thanks. usually -lintl errors are due to the package not utilizing $(LTLIBINTL) / $(LIBINTL) ... Yeah, I just reproduced this on a friend's FreeBSD box. Fix is in trunk now, but there's still something odd with gnulib's include path that I haven't sorted out yet. I've figured out the remaining include path problems, and they'll be fixed in man-db 2.4.4. Obviously I meant man-db 2.5.4 in that last comment. Since 2.5.4 came out a long time ago, have any BSD folks looked at it again since then? Has this bug been fixed yet? All the actual bugs I know about have been fixed. Somebody still needs to retest a moderately recent version, it seems. Not man-db itself but libpipeline is using "clearenv()" which is not available on FreeBSD. So building man-db fail. (In reply to Naohiro Aota from comment #9) > Not man-db itself but libpipeline is using "clearenv()" which is not > available on FreeBSD. So building man-db fail. Thanks for your report. Could you indicate which version of libpipeline you're testing, and provide a configure log? If possible, it would also be helpful if you could report whether building libpipeline from bzr trunk (http://bzr.savannah.nongnu.org/r/libpipeline/trunk) works for you. Created attachment 350140 [details] config.log libpipeline-1.2.3 (In reply to Colin Watson from comment #10) > (In reply to Naohiro Aota from comment #9) > > Not man-db itself but libpipeline is using "clearenv()" which is not > > available on FreeBSD. So building man-db fail. > > Thanks for your report. Could you indicate which version of libpipeline > you're testing, and provide a configure log? If possible, it would also be > helpful if you could report whether building libpipeline from bzr trunk > (http://bzr.savannah.nongnu.org/r/libpipeline/trunk) works for you. I've used libpipeline-1.2.3 config.log attached. OK, I've asked bug-gnulib if they can help with this. I've released libpipeline 1.2.4, which I've tested to work on FreeBSD. I've also put some effort into fixing various porting issues in man-db on FreeBSD, mainly though not exclusively in the test suite, and I now have the test suite passing and at least man(1) apparently working fine. I expect to release man-db 2.6.4 in a week or two with these changes. I have now released man-db 2.6.4, which should work on FreeBSD in conjunction with libpipeline 1.2.4. Please retest. (In reply to Colin Watson from comment #14) > I have now released man-db 2.6.4, which should work on FreeBSD in > conjunction with libpipeline 1.2.4. Please retest. Thanks. man-db 2.6.4 built fine. Some things left is that - "fowners man:root /var/cache/man" in man-db-2.6.4.ebuild won't work - Jut replacing "root" with 0 is fine. - /usr/bin/catman collide with freebsd-ubin. - We can also drop "catman" subdir from freebsd-ubin? (In reply to Naohiro Aota from comment #15) > - "fowners man:root /var/cache/man" in man-db-2.6.4.ebuild won't work > - Jut replacing "root" with 0 is fine. I just did it. > - /usr/bin/catman collide with freebsd-ubin. > - We can also drop "catman" subdir from freebsd-ubin? @aballier would dropping catman fine with you? There are a couple of issues here which I'll get back to soon. Just to sum them up so that you know there is a status update, several dependencies need keywording as well, I had trouble with po4a on my system (nls USE flag), but I am not sure if that is just my system. Additionally, there is conflict with freebsd-ubin's /usr/bin/catman See bug 674834. |