| Summary: | New ebuild for log4cpp | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michael Labhard <m.labhard> |
| Component: | New packages | Assignee: | George Shapovalov (RETIRED) <george> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | 1.4_rc1 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
New ebuild script for unstable version of log4cpp
Output of log4cpp emerge. This ebuild installs without error. |
||
|
Description
Michael Labhard
2002-11-07 18:02:51 UTC
Created attachment 5463 [details]
New ebuild script for unstable version of log4cpp
Hi Michael. Thanks for your submission! I have cleaned-up and committed the ebuild. Please test. George George: Thanks very much for including log4cpp. I did try the emerge. I did it by using ACCEPT_KEYWORDS="~x86" and with the --nodeps option. The problem I have found with Portage emerging unstable releases of packages is that it ends up bringing in the unstable versions of all dependencies of that package, which often includes gcc and binutils and this does not work. So I tried to emerge without the dependencies to avoid this and the emerge failed. I wish there was a way to tell Portage to update a package to an unstable version and only update a dependency to an unstable version if the existing installed version of that dependency absolutely will not do. -- Michael Hi Michael. Well, off the top of my head I do not remember an easy way to use emerge to create such "incoherent" installation, guess why ;). So, why don't you mark it stable for the duration of the test at least (this is the supposed way, btw)? The ebuild is keymasked, meaning it has "~x86" in KEYWORDS. Just remove '~' (tilda) from "~x86" and you shoul be set to go... You can also use ebuild (utility for deveopers) to "force-install" the package: cd /usr/portage/dev-libs/log4cpp ebuild log4cpp-0.3.4b.ebuild merge You will need to make sure that all dependencies are sutisfied. You can do "emerge --onlydeps pkgname", though this will require this ebuild be unmasked as well. George Hmmm. Yes, that's good advise to change "~x86" to "x86". However, when I do this I still cannot emerge the package. Sorry. Guess the dependencies had nothing to do with it. Something about open_wr not having permission to create directories in /usr/share/man/man3. I have attached the complete output. Created attachment 6045 [details]
Output of log4cpp emerge.
Hi Michael. Just a quick note: If you are interested in helping by testing various packages, you can take a look at http://gentoo-stable.iq-computing.de/. The site cotains an online database with test results, making it easy to add and see testing stats. George Hi Michael.
Thanks for the report!
Strangely, I do not have this problem - I am getting the package built and
installed fine. Though looks like I am not getting docs and man pages installed
on me. Quite strange as this is pretty simple ebuild (just econf and emake and
then make install, no optional functionality and use falgs..) and every other
package that comes with man pages gets them installed :/.
As I can grep from your report, the reason it is failing is that make install
tries to copy man pages directly onto live filesystem which causes sandbox
violation.
I'll shortly look into this more thoroughly.
The wrong mandir path can be dealt with by either specifying the --mandir
containing ${D} in configure or spelling out all the necessary dirs in make
install..
George
George: I just installed a new machine and ran into the same problem with the ebuild so I had to fix it. I will attach the fixed ebuild. Starting from the clues you gave me and what was done in log4c's ebuild I tried not to mess up your elegantly brief code. Don't know why this is better than your solution but this works. Hope you can use it. -- Michael Created attachment 6424 [details]
This ebuild installs without error.
Hi Michael.
Thanks for an update!
This is much better now and I am getting docs and man pages installed as well.
Just one thing: in your update docs were getting installed into
${D}/usr/doc/${P} while they should have been put under
${D}/usr/share/doc/${PF}/html (.../html since they are in html form). /usr/doc
is a symlink to /usr/share/doc, but still it is better to take care of proper
placment of docs in ebuild. I have made the necessary change and committed the
ebuild.
Please test.
George
Yup, the newest ebuild works great. Thanks for fixing that doc's problem. Thanks for testing! Closing the bug now. George |
