Re: [gentoo-user] locate can not find a file
On 15/03/2017 18:03, the...@sys-concept.com wrote: > On 03/15/2017 09:51 AM, the...@sys-concept.com wrote: > [snip] >>> >>> Do you have file consent_extraction1.pdf in your working directory? In >>> that case, your shell will begin by expending your asterisk and you will >>> really look for consent_extraction1.pdf. >> >> It is a strange behaviour :-/ >> Yes, I had a link "consent_extraction1.pdf" in a working directory and >> locate could only locate: consent_extraction1.pdf >> It could not find: consent_extraction.pdf >> >> When I removed "consent_extraction.pdf" from my working directory. >> run "updatedb" and >> "locate *consent_extraction*" found both files >> "locate consent_extraction" found both files >> "locate consent_extraction*" didn't find any files >> >> The "*" is is messing up the search. I was under impression the "*" will >> match any character including extensions. >> >> -- >> Thelma > > Sometimes reading the "man" files helps :-/ > > ...If --regex is not specified, PATTERNs can contain globbing > characters. If any PATTERN contains no globbing characters, locate > behaves as if the pattern were *PATTERN*. And none of that matters as the shell will expand the globs before locate even sees it at all. Unless you go to extra measures with quotes. But the whole exercise is completely unnecessary as locate by default does partial matches. This always does what you want: locate consent_extraction -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] locate can not find a file
On Wed, 15 Mar 2017 10:24:27 -0600, the...@sys-concept.com wrote: > > The wildcard is being expanded by your shell, so the command you are > > actually running is > > > > locate consent_extraction1.pdf > > > > If you want to pass the * to locate, you need to escape or quote it. > > locate consent_extraction\* - didn't find anything > locate "consent_extraction*" - didn't find anything > > locate "*consent_extraction*" - found both files > locate *consent_extraction* - found both files Or you could simply use locate consent_extraction because a substring match is the default behaviour. -- Neil Bothwick Q-Tip: When an omnipotent alien gives you advice. pgp1HPGKsj5iu.pgp Description: OpenPGP digital signature
Re: [gentoo-user] locate can not find a file
On 03/15/2017 10:16 AM, Neil Bothwick wrote: > On Wed, 15 Mar 2017 09:10:26 -0600, the...@sys-concept.com wrote: > >> Yes, I run as root: updatedb >> But when run: >> locate consent_extraction* >> >> It only list one file: >> /home/fd/consent_extraction1.pdf (this is a link file) >> /home/fd/business/forms/consent_extraction1.pdf > > The wildcard is being expanded by your shell, so the command you are > actually running is > > locate consent_extraction1.pdf > > If you want to pass the * to locate, you need to escape or quote it. locate consent_extraction\* - didn't find anything locate "consent_extraction*" - didn't find anything locate "*consent_extraction*" - found both files locate *consent_extraction* - found both files I guess I have to erase my memory of DOS -- Thelma
Re: [gentoo-user] locate can not find a file
On Wed, 15 Mar 2017 09:10:26 -0600, the...@sys-concept.com wrote: > Yes, I run as root: updatedb > But when run: > locate consent_extraction* > > It only list one file: > /home/fd/consent_extraction1.pdf (this is a link file) > /home/fd/business/forms/consent_extraction1.pdf The wildcard is being expanded by your shell, so the command you are actually running is locate consent_extraction1.pdf If you want to pass the * to locate, you need to escape or quote it. -- Neil Bothwick Downloading - A quick way of catching a virus from anywhere in the world. pgpoVentnElkh.pgp Description: OpenPGP digital signature
Re: [gentoo-user] locate can not find a file
On 03/15/2017 09:51 AM, the...@sys-concept.com wrote: [snip] >> >> Do you have file consent_extraction1.pdf in your working directory? In >> that case, your shell will begin by expending your asterisk and you will >> really look for consent_extraction1.pdf. > > It is a strange behaviour :-/ > Yes, I had a link "consent_extraction1.pdf" in a working directory and > locate could only locate: consent_extraction1.pdf > It could not find: consent_extraction.pdf > > When I removed "consent_extraction.pdf" from my working directory. > run "updatedb" and > "locate *consent_extraction*" found both files > "locate consent_extraction" found both files > "locate consent_extraction*" didn't find any files > > The "*" is is messing up the search. I was under impression the "*" will > match any character including extensions. > > -- > Thelma Sometimes reading the "man" files helps :-/ ...If --regex is not specified, PATTERNs can contain globbing characters. If any PATTERN contains no globbing characters, locate behaves as if the pattern were *PATTERN*. -- Thelma
Re: [gentoo-user] locate can not find a file
On 03/15/2017 09:31 AM, Alarig Le Lay wrote: > On mer. 15 mars 09:10:26 2017, the...@sys-concept.com wrote: >> Yes, I run as root: updatedb >> But when run: >> locate consent_extraction* >> >> It only list one file: >> /home/fd/consent_extraction1.pdf (this is a link file) >> /home/fd/business/forms/consent_extraction1.pdf >> >> It can not find: "consent_extraction.pdf" both files are in same directory >> >> ll business/forms/ >> total 688 >> ... >> -rw-r--r-- 1 fd fd 63032 Mar 15 08:52 consent_extraction1.pdf >> -rw-r--r-- 1 fd fd 397649 Mar 14 20:05 consent_extraction.pdf >> >> I observe the same behaviour on my local machine and remote machine. >> >> Running "find" finds both files >> >> find . -name '*consent_extraction*' >> ./business/forms/consent_extraction.pdf >> ./business/forms/consent_extraction1.pdf >> ./consent_extraction1.pdf >> >> Why? > > Hi, > > Do you have file consent_extraction1.pdf in your working directory? In > that case, your shell will begin by expending your asterisk and you will > really look for consent_extraction1.pdf. It is a strange behaviour :-/ Yes, I had a link "consent_extraction1.pdf" in a working directory and locate could only locate: consent_extraction1.pdf It could not find: consent_extraction.pdf When I removed "consent_extraction.pdf" from my working directory. run "updatedb" and "locate *consent_extraction*" found both files "locate consent_extraction" found both files "locate consent_extraction*" didn't find any files The "*" is is messing up the search. I was under impression the "*" will match any character including extensions. -- Thelma
Re: [gentoo-user] locate can not find a file
On mer. 15 mars 09:10:26 2017, the...@sys-concept.com wrote: > Yes, I run as root: updatedb > But when run: > locate consent_extraction* > > It only list one file: > /home/fd/consent_extraction1.pdf (this is a link file) > /home/fd/business/forms/consent_extraction1.pdf > > It can not find: "consent_extraction.pdf" both files are in same directory > > ll business/forms/ > total 688 > ... > -rw-r--r-- 1 fd fd 63032 Mar 15 08:52 consent_extraction1.pdf > -rw-r--r-- 1 fd fd 397649 Mar 14 20:05 consent_extraction.pdf > > I observe the same behaviour on my local machine and remote machine. > > Running "find" finds both files > > find . -name '*consent_extraction*' > ./business/forms/consent_extraction.pdf > ./business/forms/consent_extraction1.pdf > ./consent_extraction1.pdf > > Why? Hi, Do you have file consent_extraction1.pdf in your working directory? In that case, your shell will begin by expending your asterisk and you will really look for consent_extraction1.pdf. -- alarig signature.asc Description: PGP signature
[gentoo-user] locate can not find a file
Yes, I run as root: updatedb But when run: locate consent_extraction* It only list one file: /home/fd/consent_extraction1.pdf (this is a link file) /home/fd/business/forms/consent_extraction1.pdf It can not find: "consent_extraction.pdf" both files are in same directory ll business/forms/ total 688 ... -rw-r--r-- 1 fd fd 63032 Mar 15 08:52 consent_extraction1.pdf -rw-r--r-- 1 fd fd 397649 Mar 14 20:05 consent_extraction.pdf I observe the same behaviour on my local machine and remote machine. Running "find" finds both files find . -name '*consent_extraction*' ./business/forms/consent_extraction.pdf ./business/forms/consent_extraction1.pdf ./consent_extraction1.pdf Why? -- Thelma
Re: [gentoo-user] locate
Hello Bo Ørsted Andresen, > A script won't help as it will only change the path in the context of > the script. A shell function is required. It would work if you sourced it, but a shell function would be better. -- Neil Bothwick WinErr 020: Error recording error codes - Additional errors will be lost. signature.asc Description: PGP signature
Re: [gentoo-user] locate
On Friday 11 May 2007 16:09:40 Neil Bothwick wrote: > > Anyway I don't have a mouse on that system, so I'll have to use Alan > > suggestion. > > You could use a script. e.g. A script won't help as it will only change the path in the context of the script. A shell function is required. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] locate
On 11 May 2007, Martin S wrote: > That works yes. > A bit much to typw though. Don't know if I'd save much time from first > doing a locate and the manually typing the cd [result] string :) Make it a shell function if you need it often. Uwe -- The Informal Linux Group Namibia: http://www.linux.org.na SysEx (Pty) Ltd.: http://www.SysEx.com.na -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] locate
Martin S writes:
Anyway I don't have a mouse on that system, so I'll have to use Alan
suggestion.
You could use a little shell function like this one. Add it to your
~/.bashrc or somewhere like that.
locatecd()
{
oldIFS=$IFS
IFS=$'\n'
results=( $( locate "$1" ) )
ret=$?
IFS=$oldIFS
if (( ret ))
then
echo "Sorry, '$1' was not found."
return $ret
fi
if (( [EMAIL PROTECTED] > 1 ))
then
echo "More than one file found, using the first one."
fi
cd "$( dirname "[EMAIL PROTECTED]" )"
}
Alex
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-user] locate
On Fri, 11 May 2007 15:53:42 +0200, Martin S wrote:
> Forgot you're still toppost sensitive in this group.
And always will be, once oyu've seen the one true way you don't change :)
> Anyway I don't have a mouse on that system, so I'll have to use Alan
> suggestion.
You could use a script. e.g.
#!/bin/sh
# cdlocate.sh
cd $(dirname $(locate $1 | head -n 1))
The head -n 1 will avoid it falling over when locate returns more than
one hit, although it will still break if there are no hits. Maybe,
although I haven't tested it, something like
FILE=$(locate "$*" | head -n 1))
[[ "${FILE}" ]] && cd $(dirname "${FILE}")
--
Neil Bothwick
Error reading FAT record: Try the SKINNY one? (Y/N)
signature.asc
Description: PGP signature
Re: [gentoo-user] locate
2007/5/11, Neil Bothwick <[EMAIL PROTECTED]>: On Fri, 11 May 2007 15:29:03 +0200, Martin S wrote: > A bit much to typw though. Don't know if I'd save much time from first > doing a locate and the manually typing the cd [result] string :) Or type "cd " Forgot you're still toppost sensitive in this group. Anyway I don't have a mouse on that system, so I'll have to use Alan suggestion. Regards, Martin S
Re: [gentoo-user] locate
On Fri, 11 May 2007 15:29:03 +0200, Martin S wrote: > A bit much to typw though. Don't know if I'd save much time from first > doing a locate and the manually typing the cd [result] string :) Or type "cd " PS - please don't top-post. -- Neil Bothwick Two is not equal to three, even for large values of two. signature.asc Description: PGP signature
Re: [gentoo-user] locate
That works yes. A bit much to typw though. Don't know if I'd save much time from first doing a locate and the manually typing the cd [result] string :) Martin S 2007/5/11, Neil Bothwick <[EMAIL PROTECTED]>: On Fri, 11 May 2007 14:34:44 +0200, Martin S wrote: > Just recently tried using > > locate foo.conf | cd > > to automagically move to the directory in which I've saved foo.conf > Of course it didn't work as you can't cd to /bar/foo.conf > > I didn't find a way to dropping the actual file name from the result of > locate. cd $(dirname $(locate foo.conf)) -- Neil Bothwick WinErr 010: Reserved for future mistakes by our developers -- Regards, Martin S
Re: [gentoo-user] locate
On Fri, 11 May 2007 14:34:44 +0200, Martin S wrote: > Just recently tried using > > locate foo.conf | cd > > to automagically move to the directory in which I've saved foo.conf > Of course it didn't work as you can't cd to /bar/foo.conf > > I didn't find a way to dropping the actual file name from the result of > locate. cd $(dirname $(locate foo.conf)) -- Neil Bothwick WinErr 010: Reserved for future mistakes by our developers signature.asc Description: PGP signature
Re: [gentoo-user] locate
On Friday 11 May 2007 14:34, Martin S wrote: > Just recently tried using > > locate foo.conf | cd > > to automagically move to the directory in which I've saved foo.conf > Of course it didn't work as you can't cd to /bar/foo.conf It would not have worked anyway, since cd does not read its input from stdin. Try: [/]$ echo "etc" | cd -bash: echo: write error: Broken pipe [/]$ > I didn't find a way to dropping the actual file name from the result > of locate. > I did a brief google on locate, but didn't find a switch to drop the > actual file name from the result. It's not a locate problem. Use the "dirname" command. $ dirname /bar/foo.conf /bar $ and do something like cd $(dirname "$(locate foo.conf)") of course, make sure that the locate command returns just a single entry. -- [EMAIL PROTECTED] mailing list
[gentoo-user] locate
Just recently tried using locate foo.conf | cd to automagically move to the directory in which I've saved foo.conf Of course it didn't work as you can't cd to /bar/foo.conf I didn't find a way to dropping the actual file name from the result of locate. I did a brief google on locate, but didn't find a switch to drop the actual file name from the result. Can it be done, or if not what should I use to get the desired result? Regards, Martin S
Re: [gentoo-user] Locate and Fix .text Relocations (TEXTRELs)
On 7/14/06, Graham Murray <[EMAIL PROTECTED]> wrote: "Richard Fish" <[EMAIL PROTECTED]> writes: > Hrm, these are really not sane. -march is telling gcc to build C code > that will only run on a p4, and then you have -mtune specifying to run > on everything back to a pentium-II. I *think* -march takes precedence > here Does it? I would have thought that having both -march and -mtune would be valid, but normally would be other way round by having, for example, '-march=i686 -mtune=pentium4' to build code which will run on a pentium-II or later but optimised for running on a P4. Right, this is the normal case. But in some sense, you could also consider -march to have precedence here. If it ever needs to make a choice between generating optimized code for a p4, or code that will run on a P-II, gcc will choose the P-II compatible code. But the fact is that I am not sure what -march=pentium4 -mtune=i686 would generate... -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Locate and Fix .text Relocations (TEXTRELs)
"Richard Fish" <[EMAIL PROTECTED]> writes: > Hrm, these are really not sane. -march is telling gcc to build C code > that will only run on a p4, and then you have -mtune specifying to run > on everything back to a pentium-II. I *think* -march takes precedence > here Does it? I would have thought that having both -march and -mtune would be valid, but normally would be other way round by having, for example, '-march=i686 -mtune=pentium4' to build code which will run on a pentium-II or later but optimised for running on a P4. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Locate and Fix .text Relocations (TEXTRELs)
On Fri, 14 Jul 2006 01:30:49 -0700
Richard Fish wrote:
> On 7/14/06, Arnau Bria <[EMAIL PROTECTED]> wrote:
> > CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer -mtune=i686"
> > CXXFLAGS="-O2 -mcpu=i686 -pipe"
>
> Hrm, these are really not sane. -march is telling gcc to build C code
> that will only run on a p4, and then you have -mtune specifying to run
> on everything back to a pentium-II. I *think* -march takes precedence
> here
>
> But for C++ code, you are specifying that should run on any P-II. So
> C and C++ code is being compiled in very different ways on your
> system. This is bad. I have no idea whether these are causing your
> problems with akregator or not however...
>
> BTW, the TEXTREL messages are directly attributable to your CXXFLAGS.
> I built akregator with the same flags, and get the same messages.
>
> So what I recommend you set in /etc/make.conf is:
>
> CFLAGS="-march=pentium4 -O2 -pipe"
> CXXFLAGS="${CFLAGS}"
Mmm... I don't know from where I got this FLAGS, but I'm quite sure I
used some program/script from portage...
Anyway, I did the mod, and remerged akregator... It still doesn't work.
> Then re-merge akregator. If you still have trouble, try renaming
> ~/.kde3.5 to ~/.kde3.5.old and start it. If that works then some
> akregator configuration in .kde3.5.old is responsible.
Well, I moved /home/arnau/.kde/share/apps/akregator to .old. I thinks
this is enough, isn't it?
It did not work, neither.
> Finally, may want to recompile your entire system with the fixed
> compiler flags. This can usually be done with an "emerge -e world",
> but this will take a long time!
This is an option I considered as I saw 114 packages "broken"... now,
with CFLAGS mod, I also think this is a good option.
And, well, I could let my system recompiling all the weekend...
> You can also grep the CFLAGS/CXXFLAGS
> files in the /var/db/pkg/ database to see what packages you merged
> with particular flags. For example: "grep -r --include=CXXFLAGS --
> -mcpu=i686 /var/db/pkg/".
# grep -r --include=CXXFLAGS -- -mcpu=i686 /var/db/pkg/|wc -l
432
some x11-libs, lot of perl, kde-base... etc...
Defintely, I'll recompile my system.
> -Richard
Thanks for your time,
Cheers!
--
Arnau Bria
http://blog.emergetux.net
La vida es una aplastante derrota tras otra hasta que
acabas deseando que se muera Flanders.
~Homer J. Simpson~
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Locate and Fix .text Relocations (TEXTRELs)
On 7/14/06, Arnau Bria <[EMAIL PROTECTED]> wrote:
CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer -mtune=i686"
CXXFLAGS="-O2 -mcpu=i686 -pipe"
Hrm, these are really not sane. -march is telling gcc to build C code
that will only run on a p4, and then you have -mtune specifying to run
on everything back to a pentium-II. I *think* -march takes precedence
here
But for C++ code, you are specifying that should run on any P-II. So
C and C++ code is being compiled in very different ways on your
system. This is bad. I have no idea whether these are causing your
problems with akregator or not however...
BTW, the TEXTREL messages are directly attributable to your CXXFLAGS.
I built akregator with the same flags, and get the same messages.
So what I recommend you set in /etc/make.conf is:
CFLAGS="-march=pentium4 -O2 -pipe"
CXXFLAGS="${CFLAGS}"
Then re-merge akregator. If you still have trouble, try renaming
~/.kde3.5 to ~/.kde3.5.old and start it. If that works then some
akregator configuration in .kde3.5.old is responsible.
Finally, may want to recompile your entire system with the fixed
compiler flags. This can usually be done with an "emerge -e world",
but this will take a long time! You can also grep the CFLAGS/CXXFLAGS
files in the /var/db/pkg/ database to see what packages you merged
with particular flags. For example: "grep -r --include=CXXFLAGS --
-mcpu=i686 /var/db/pkg/".
-Richard
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Locate and Fix .text Relocations (TEXTRELs)
On Thu, 13 Jul 2006 11:12:43 -0700 Richard Fish wrote: > On 7/13/06, Arnau Bria <[EMAIL PROTECTED]> wrote: > > Then, after akregator compilation, I was looking for some warning > > and I found a message that toke me to > > I suggest to post the actual warning message[s], and your emerge > --info output. Here we go! (sorry for not wrapping the text, but I tough I could be more readable in this format) # emerge --info Portage 2.1-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16-gentoo-r9 i686) = System uname: 2.6.16-gentoo-r9 i686 Intel(R) Pentium(R) 4 CPU 3.06GHz Gentoo Base System version 1.6.15 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox:1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer -mtune=i686" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://linuv.uv.es/mirror/gentoo/"; PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 X alsa amarok apache2 apm avi berkdb bitmap-fonts ccache cdr cgi clamav clamd crypt cups dlloader dri encode firefox gdbm gpm gstreamer gtk2 imap imlib jpeg kde kerberosi libwww mad mikmod motif mp3 mpeg mpeg2 mplayer ncurses nls nptl ogg opengl pcre pdflib perl png python qt qt3 qt4 readline sasl sdl session spamassassin spell spl ssl tcpd truetype truetype-fonts type1-fonts udev userlocales vorbis win32codecs wmv xorg xv zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_i810 video_cards_i915 video_cards_vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS And here's akregator en lines from compilation... as it doesn't work, I looked for any note in the output and found this: >>> Completed installing akregator-3.5.2 into /var/tmp/portage/akregator-3.5.2/image/ man: strip: i686-pc-linux-gnu-strip --strip-unneeded usr/kde/3.5/lib/libakregatorprivate.so usr/kde/3.5/lib/kde3/libakregatorpart.so usr/kde/3.5/lib/kde3/libakregator_mk4storage_plugin.so usr/kde/3.5/lib/kde3/libkontact_akregator.so usr/kde/3.5/bin/akregator QA Notice: the following files contain runtime text relocations Text relocations force the dynamic linker to perform extra work at startup, waste system resources, and may pose a security risk. On some architectures, the code may not even function properly, if at all. For more information, see http://hardened.gentoo.org/pic-fix-guide.xml Please include this file in your report: /var/tmp/portage/akregator-3.5.2/temp/scanelf-textrel.log "TEXTREL usr/kde/3.5/lib/libakregatorprivate.so" "TEXTREL usr/kde/3.5/lib/kde3/libakregatorpart.so" "TEXTREL usr/kde/3.5/lib/kde3/libakregator_mk4storage_plugin.so" "TEXTREL usr/kde/3.5/lib/kde3/libkontact_akregator.so" >>> Merging kde-base/akregator-3.5.2 to / --- /usr/ --- /usr/kde/ --- /usr/kde/3.5/ --- /usr/kde/3.5/share/ [...] >>> Original instance of package unmerged safely. >>> Regenerating /etc/ld.so.cache... >>> kde-base/akregator-3.5.2 merged. >>> No packages selected for removal by clean. >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. > -Richard Thanks! -- Arnau Bria http://blog.emergetux.net La vida es una aplastante derrota tras otra hasta que acabas deseando que se muera Flanders. ~Homer J. Simpson~ -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Locate and Fix .text Relocations (TEXTRELs)
On 7/13/06, Arnau Bria <[EMAIL PROTECTED]> wrote: Then, after akregator compilation, I was looking for some warning and I found a message that toke me to I suggest to post the actual warning message[s], and your emerge --info output. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Locate and Fix .text Relocations (TEXTRELs)
On Thu, 13 Jul 2006 09:43:03 +0200 Arnau Bria wrote: > #eix akregator > * kde-base/akregator > Available versions: 3.4.3 3.5.2 ~3.5.3 > Installed: 3.4.3 3.5.2 > > (Why do I have 2 akregators?) Ok, I did not notice that it refers to kde-base... -- Arnau Bria http://blog.emergetux.net La vida es una aplastante derrota tras otra hasta que acabas deseando que se muera Flanders. ~Homer J. Simpson~ -- gentoo-user@gentoo.org mailing list
[gentoo-user] Locate and Fix .text Relocations (TEXTRELs)
Hi, this morning my akregator didn't want to weak up. So, I launched it from konsole and as I saw no output, I decide to rebuild it (I've been playing around with some use flags, adding, removing...) #eix akregator * kde-base/akregator Available versions: 3.4.3 3.5.2 ~3.5.3 Installed: 3.4.3 3.5.2 (Why do I have 2 akregators?) Then, after akregator compilation, I was looking for some warning and I found a message that toke me to http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml. I do not understand much from that site, but I did a: $ scanelf -lpqt |wc -l 114 and, as the howto says: "Ideally, scanelf should not display anything, but on an x86 system, this is rarely the case." I thought that 114 are quite enough to ask some one with more knowledge if my system is completly broken or not. Anyone could explain me why do I have 114 "broken files"? Cheers! -- Arnau Bria http://blog.emergetux.net La vida es una aplastante derrota tras otra hasta que acabas deseando que se muera Flanders. ~Homer J. Simpson~ -- gentoo-user@gentoo.org mailing list
