Re: [gentoo-dev] On shebangs of scripts
On Wednesday 23 September 2009 03:53:43 Fabian Groffen wrote: > Should we start filing bugs on these issues? In the end, they are > broken scripts on the system. Is there interest for porting the Prefix > shebang QA check to normal Portage? for the shell dependency issue, a review bug may be useful, but keep in mind nothing may change. if a package installs examples for a bunch of shells and they're intended for end user use only, then it doesnt make sense to have that package depend on every shell that it installs helpers for. for the other issues, there should be bugs and you should get those checks merged to portage proper. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Gentoo usage in companies
Patrick Lauer wrote: > I'd like to collect your success stories, endorsements and case studies so we > can present to the rest of the world how using Gentoo makes your life easier > and is totally awesome. I had a similar thing in mind, too. Nice to see, you're goinf for it. > I would suggest that you _don't_ reply to this mailinglist but directly send > me an email. Otherwise it'd be a long, but very offtopic thread which I'd > like > to avoid (and we had enough of those already ...) If they send to you the bottleneck is a single person. You know you are busy with other stuff, too. How about the gentoo-project mailing list as the suggested destination, instead? That would also allow me to follow that very mail stream. Sebastian
Re: [gentoo-dev] Re: why doesn't readline-6 install libreadline.so symlink?
On Saturday 26 September 2009 02:03:38 Jonathan Callen wrote: > I'm not completely sure, but I think it doesn't install that symlink > because it (correctly) installs a /usr/lib/libreadline.so ldscript, that > tells the linker to link against /lib/libreadline.so.6 correct > so long as the linker looks at /usr/lib before /lib, which is usually the > case, unless "-L/lib" is passed to ld (by way of gcc) incorrect -- link order doesnt matter here with readline-6 -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Gentoo usage in companies
Hello everybody! As Gentoo approaches its 10th birthday I've been wondering how and where it is used. We used to have some great stories from companies in the weekly newsletter, but that one has become very dormant a while ago. I'd like to collect your success stories, endorsements and case studies so we can present to the rest of the world how using Gentoo makes your life easier and is totally awesome. If you don't want to have that information public I'll gladly anonymize it as long as I can be reasonably certain that you really exist. What is important is that you, if you actively use it in a commercial environment, write me whatever you think is important. Or you motivate someone you know to write it. Do your contribution to making things better :) Everything from "I use it and it's great!" to a story starting on a rainy day in November 1885 is good. Don't be afraid, I'll work with you on making it into something readable. And if you have specific criticism I'll take that too - maybe we can find an easy way to improve things. That is in your best interest too, so go ahead. Invest a few minutes of your time so we can save you more time! I would suggest that you _don't_ reply to this mailinglist but directly send me an email. Otherwise it'd be a long, but very offtopic thread which I'd like to avoid (and we had enough of those already ...) Many thanks in advance for your contributions, Patrick
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-cpp/eigen: eigen-2.0.6.ebuild ChangeLog
В Сбт, 26/09/2009 в 00:18 +, Patrick Lauer (patrick) пишет:
> patrick 09/09/26 00:18:02
> Log:
> Bump to 2.0.6, fixes #286462
> (Portage version: 2.2_rc41/cvs/Linux x86_64)
> 1.1 dev-cpp/eigen/eigen-2.0.6.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-cpp/eigen/eigen-2.0.6.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-cpp/eigen/eigen-2.0.6.ebuild?rev=1.1&content-type=text/plain
> src_test() {
> mycmakeargs="${mycmakeargs}
> -DEIGEN_BUILD_TESTS=ON
> -DEIGEN_TEST_NO_FORTRAN=ON"
> cmake-utils_src_configure
> cmake-utils_src_compile
> cmake-utils_src_test
> }
Does this mean that with tests enabled user will get different package?
If that's true I think user should be at least notified about that as
this is counterintuitive. If not why -D*TEST* are not added at
src_configure phase?
--
Peter.
Re: [gentoo-dev] Re: why doesn't readline-6 install libreadline.so symlink?
On Sat, 26 Sep 2009, Mike Frysinger wrote: so long as the linker looks at /usr/lib before /lib, which is usually the case, unless "-L/lib" is passed to ld (by way of gcc) incorrect -- link order doesnt matter here with readline-6 Here's a specific example: sci-mathematics/pari-2.3.4-r1. It has a hand-written Configure script (not configure). It searches for libreadline.so in a list of directories, and sees that it points to libreadline.so.5 (this is after libreadline-5 has been unmerged). So, it adds -l libreadline.so.5 to the linking flags. Clearly, this is not the desired behaviour. What can be done to avoid it? Andrey
Re: [gentoo-dev] On shebangs of scripts
On Wednesday 23 September 2009 10:09:23 Jeremy Olexa wrote: > On Wed, Sep 23, 2009 at 2:53 AM, Fabian Groffen wrote: > > The problem with these is that they are executable scripts, e.g. a user > > could expect them to be able to run, IMO. Solving this can be done by > > fixing the shebang (as for the first two cases), adding a runtime > > dependency (for the last case), or by removing the executable bit of the > > scripts so they no longer can be run, and they merely become > > examples/documentation. > > Should there ever be executable scripts in /usr/share? If the > consensus is 'no', could portage remove the +x bit automatically? i dont see anything wrong with +x in /usr/share in general. they're shell scripts and thus platform independent, so /usr/share is the place for them to live. packages may internally execute these things, so blindly stripping +x bits sounds like a bit idea. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-cpp/eigen: eigen-2.0.6.ebuild ChangeLog
Dne sobota 26 Září 2009 18:26:48 Peter Volkov napsal(a):
> > src_test() {
> > mycmakeargs="${mycmakeargs}
> > -DEIGEN_BUILD_TESTS=ON
> > -DEIGEN_TEST_NO_FORTRAN=ON"
> > cmake-utils_src_configure
> > cmake-utils_src_compile
> > cmake-utils_src_test
> > }
>
> Does this mean that with tests enabled user will get different package?
> If that's true I think user should be at least notified about that as
> this is counterintuitive. If not why -D*TEST* are not added at
> src_configure phase?
>
No this means that it will add to configure options tests feature.
Since cmake is cascading it will configure and compile in only the required
test stuff.
Then it runs the test.
I dont think users really need tests out of the test scope so why to do it
elsewhere.
It has 0 effect on what is installed in the end
Tomas
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: why doesn't readline-6 install libreadline.so symlink?
On Saturday 26 September 2009 10:48:53 Andrey Grozin wrote: > On Sat, 26 Sep 2009, Mike Frysinger wrote: > >> so long as the linker looks at /usr/lib before /lib, which is usually > >> the case, unless "-L/lib" is passed to ld (by way of gcc) > > > > incorrect -- link order doesnt matter here with readline-6 > > Here's a specific example: sci-mathematics/pari-2.3.4-r1. It has a > hand-written Configure script (not configure). It searches for > libreadline.so in a list of directories, and sees that it points to > libreadline.so.5 (this is after libreadline-5 has been unmerged). So, it > adds -l libreadline.so.5 to the linking flags. Clearly, this is not the > desired behaviour. What can be done to avoid it? the configure script is broken and it should be fixed. linking directly against a SONAME is wrong. -mike signature.asc Description: This is a digitally signed message part.
