We're using Gentoo Prefix on OS X. Installing media-libs/x264 or media-video/x264-encoder via the ECOPY script fails because the ebuild has hardcoded libdir and prefix options. For example in x264-0.0.20081218.ebuild: (src_compile) ./configure --prefix=/usr \ --libdir=/usr/$(get_libdir) \ must be changed to: ./configure --prefix="${EPREFIX}"/usr \ --libdir="${EPREFIX}"/usr/$(get_libdir) \ for x264 to install correctly. After this change is made x264 and x264-encoder run fine in Prefix. Reproducible: Always Steps to Reproduce: 1. ecopy media-libs/x264 2. emerge x264 3.
first bug report take it easy on me!
(In reply to comment #1) > first bug report take it easy on me! > Its really important for the Prefix bugs to come directly to us, instead of going to bug-wranglers. (They don't nessacarily know what we do)
(In reply to comment #2) > (In reply to comment #1) > > first bug report take it easy on me! > > > > Its really important for the Prefix bugs to come directly to us, instead of > going to bug-wranglers. (They don't nessacarily know what we do) > I wondered about that, but a first I didn't see a fix being handled by Prefix developers. Wouldn't this bug be fixed at the main Portage tree? That way ecopy scripts will run fine and x264 can be added to the Prefix tree automagically.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > first bug report take it easy on me! > > > > > > > Its really important for the Prefix bugs to come directly to us, instead of > > going to bug-wranglers. (They don't nessacarily know what we do) > > > > I wondered about that, but a first I didn't see a fix being handled by Prefix > developers. Wouldn't this bug be fixed at the main Portage tree? Nope, the main portage tree doesn't have EPREFIX in it. (yet) > > That way ecopy scripts will run fine and x264 can be added to the Prefix tree > automagically. > ecopy is simply a best effort script written by us to make porting ebuilds to prefix easier. It does not check anything for you and is not always correct. Ebuilds can never be trusted to be imported automatically, they always must be checked. It is important that you file bugs for any ebuild that you have ported though. We cannot get to all of them ourselves! (This ebuild also needs yasm (not in prefix yet) for my arch, so I will get to it later unless someone beats me to it)
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > first bug report take it easy on me! > > > > > > > > > > Its really important for the Prefix bugs to come directly to us, instead of > > > going to bug-wranglers. (They don't nessacarily know what we do) > > > > > > > I wondered about that, but a first I didn't see a fix being handled by Prefix > > developers. Wouldn't this bug be fixed at the main Portage tree? > > Nope, the main portage tree doesn't have EPREFIX in it. (yet) > > > > > That way ecopy scripts will run fine and x264 can be added to the Prefix tree > > automagically. > > > > ecopy is simply a best effort script written by us to make porting ebuilds to > prefix easier. It does not check anything for you and is not always correct. > Ebuilds can never be trusted to be imported automatically, they always must be > checked. > > It is important that you file bugs for any ebuild that you have ported though. > We cannot get to all of them ourselves! > > (This ebuild also needs yasm (not in prefix yet) for my arch, so I will get to > it later unless someone beats me to it) > What arch are you? If you are amd64 or x86 yasm should ecopy just fine... I ecopy'd yasm right before I emerged x264 and it rolled out nicely.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #2) > > > > (In reply to comment #1) > > > > > first bug report take it easy on me! > > > > > > > > > > > > > Its really important for the Prefix bugs to come directly to us, instead of > > > > going to bug-wranglers. (They don't nessacarily know what we do) > > > > > > > > > > I wondered about that, but a first I didn't see a fix being handled by Prefix > > > developers. Wouldn't this bug be fixed at the main Portage tree? > > > > Nope, the main portage tree doesn't have EPREFIX in it. (yet) > > > > > > > > That way ecopy scripts will run fine and x264 can be added to the Prefix tree > > > automagically. > > > > > > > ecopy is simply a best effort script written by us to make porting ebuilds to > > prefix easier. It does not check anything for you and is not always correct. > > Ebuilds can never be trusted to be imported automatically, they always must be > > checked. > > > > It is important that you file bugs for any ebuild that you have ported though. > > We cannot get to all of them ourselves! > > > > (This ebuild also needs yasm (not in prefix yet) for my arch, so I will get to > > it later unless someone beats me to it) > > > > What arch are you? If you are amd64 or x86 yasm should ecopy just fine... I > ecopy'd yasm right before I emerged x264 and it rolled out nicely. > Sorry I ecopy'd then emerged yasm before I emerged mplayer. x264 is one of my USE flags and it gets compiled with mplayer. First attempt emerging mplayer it did not compile yasm with x264 and halted because of the dependency. So yasm needed to be emerged manually. hmmmm I think I have another bug report brewing....
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > > (In reply to comment #2) > > > > > (In reply to comment #1) > > > > > > first bug report take it easy on me! > > > > > > > > > > > > > > > > Its really important for the Prefix bugs to come directly to us, instead of > > > > > going to bug-wranglers. (They don't nessacarily know what we do) > > > > > > > > > > > > > I wondered about that, but a first I didn't see a fix being handled by Prefix > > > > developers. Wouldn't this bug be fixed at the main Portage tree? > > > > > > Nope, the main portage tree doesn't have EPREFIX in it. (yet) > > > > > > > > > > > That way ecopy scripts will run fine and x264 can be added to the Prefix tree > > > > automagically. > > > > > > > > > > ecopy is simply a best effort script written by us to make porting ebuilds to > > > prefix easier. It does not check anything for you and is not always correct. > > > Ebuilds can never be trusted to be imported automatically, they always must be > > > checked. > > > > > > It is important that you file bugs for any ebuild that you have ported though. > > > We cannot get to all of them ourselves! > > > > > > (This ebuild also needs yasm (not in prefix yet) for my arch, so I will get to > > > it later unless someone beats me to it) > > > > > > > What arch are you? If you are amd64 or x86 yasm should ecopy just fine... I > > ecopy'd yasm right before I emerged x264 and it rolled out nicely. > > > > Sorry I ecopy'd then emerged yasm before I emerged mplayer. x264 is one of my > USE flags and it gets compiled with mplayer. First attempt emerging mplayer it > did not compile yasm with x264 and halted because of the dependency. So yasm > needed to be emerged manually. hmmmm I think I have another bug report > brewing.... > Caught it... In x264-0.0.20081218.ebuild: DEPEND="amd64? ( >=dev-lang/yasm-0.6.2 ) x86? ( >=dev-lang/yasm-0.6.2 ) x86-fbsd? ( >=dev-lang/yasm-0.6.2 )" Should be: DEPEND="amd64? ( >=dev-lang/yasm-0.6.2 ) x86? ( >=dev-lang/yasm-0.6.2 ) x86-fbsd? ( >=dev-lang/yasm-0.6.2 ) x86-macos? ( >=dev-lang/yasm-0.6.2 )" (add your arch-env as needed, I'm using x86-macos) Another situation that ecopy doesn't cover?
added x264, thx.
