On Thu, 16 Jul 2009 02:25:15 pm you wrote:
> richard terry wrote:
> > (11/11) installing scribus
> > [
> >] 100%
> > sh: error while loading shared libraries: libreadline.so.5: cannot open
> > shared object file: No suc
richard terry wrote:
(11/11) installing scribus
[]
100%
sh: error while loading shared libraries: libreadline.so.5: cannot open shared
object file: No such file or directory
sh: error while
On Thu, Jul 16, 2009 at 1:07 AM, Daniel J
Griffiths wrote:
> richard terry wrote:
>>
>> (11/11) installing scribus
>> []
>> 100%
>> sh: error while loading shared libraries: libreadline.so.5: cannot open
>> shared obje
richard terry wrote:
(11/11) installing scribus
[]
100%
sh: error while loading shared libraries: libreadline.so.5: cannot open shared
object file: No such file or directory
sh: error while
(11/11) installing scribus
[]
100%
sh: error while loading shared libraries: libreadline.so.5: cannot open shared
object file: No such file or directory
sh: error while loading shared librar
David C. Rankin wrote:
Listmates,
On an i586 box with kde4 from testing, I am now unable to login. kdm
starts to login, crashes and restarts. (detailed in a separate post) I was
hoping that this would be fixed by an update or two, but upon checking this
evening, I received the follow
Listmates,
On an i586 box with kde4 from testing, I am now unable to login. kdm
starts to login, crashes and restarts. (detailed in a separate post) I was
hoping that this would be fixed by an update or two, but upon checking this
evening, I received the following:
19:27 supersff:~> p
On Mittwoch, 15. Juli 2009 22:50 Stefan Husmann wrote:
> no, that might break a hundred of other packages you might have
> installed. The best way would be to wait for the mirror syncing or to
> rebuild emacs-cvs using abs.
First, i'm not waiting for emacs-cvs.-) My problem is that i don't know w
Attila schrieb:
On Mittwoch, 15. Juli 2009 19:27 Florian Pritz wrote:
Get the old libjpeg package, extract it and copy the .so file to
/usr/lib. Linking is a no-go.
Thanks very much, this is the best way and i saved the files from libjpeg
6b-6.
See you, Attila
no, that might break a hundre
On Mittwoch, 15. Juli 2009 19:27 Florian Pritz wrote:
> Get the old libjpeg package, extract it and copy the .so file to
> /usr/lib. Linking is a no-go.
Thanks very much, this is the best way and i saved the files from libjpeg
6b-6.
See you, Attila
Attila wrote:
> On Mittwoch, 15. Juli 2009 14:14 Allan McRae wrote:
>
>> Don't symlink libraries
>>
>> http://bugs.archlinux.org/task/15222#comment46995 -> it should be on its
>> way to a mirror near you.
>
> Okay, it is the best to don't do this but i have a technical question about it
> in th
On Mittwoch, 15. Juli 2009 14:14 Allan McRae wrote:
> Don't symlink libraries
>
> http://bugs.archlinux.org/task/15222#comment46995 -> it should be on its
> way to a mirror near you.
Okay, it is the best to don't do this but i have a technical question about it
in this case: What would be th
2009/7/15 Thomas Bächler :
> What readelf said is what is written in the binary. If the binary says
> libjpeg.so.62, then it's an old binary!
You're right. I reverted back to the puzzle.ch mirror and I saw it
didn't sync properly, it still has the old mldonkey. Thanks for
clarifications =)
Corrad
bardo schrieb:
2009/7/15 bardo :
Yes, i686, but just to be sure I checked on both arches, and I get the
new version.
The problem has been solved by switching repos. Could it be that
mldonkey just linked to libjpeg.so, and readelf recurred to
libjpeg.so.62, while the program said it didn't find
2009/7/15 bardo :
> Yes, i686, but just to be sure I checked on both arches, and I get the
> new version.
The problem has been solved by switching repos. Could it be that
mldonkey just linked to libjpeg.so, and readelf recurred to
libjpeg.so.62, while the program said it didn't find the library
be
On Wed, Jul 15, 2009 at 15:39, Denis A. Altoé
Falqueto wrote:
> Hi,
>
> I didn't find the original signoff message, but here is my user
> signoff for cups-1.3.11-1 in x86_64. The server starts, web interface
> is fine, pdf printer is also ok.
There wasn't signoff message because cups is in Extra,
Hi,
I didn't find the original signoff message, but here is my user
signoff for cups-1.3.11-1 in x86_64. The server starts, web interface
is fine, pdf printer is also ok.
--
---
Denis A. Altoe Falqueto
---
Milton Ber
2009/7/15 Allan McRae :
> Strange - both using the same architecture?
Yes, i686, but just to be sure I checked on both arches, and I get the
new version.
bardo wrote:
2009/7/15 bardo :
It worked for me, but it seems it did not for the user, so I'm waiting
to know which mirror he uses and readelf's output.
He uses archlinux.puzzle.ch... I had problems in the last few days
with it too, so I switched to another one, maybe this caused the
i
2009/7/15 bardo :
> It worked for me, but it seems it did not for the user, so I'm waiting
> to know which mirror he uses and readelf's output.
He uses archlinux.puzzle.ch... I had problems in the last few days
with it too, so I switched to another one, maybe this caused the
issue. Anyway, here's
Hi,
I fixed it yesterday (emacs-cvs-20090714)
At Wed, 15 Jul 2009 19:57:26 +0800,
goodme...@gmail.com wrote:
>
> As a temp methord,
>cd /usr/lib
>ln -s libjpeg.so libjpeg.so.62
> resolved the bug
>
>
> Anyother has the same problem?
goodme...@gmail.com wrote:
As a temp methord,
cd /usr/lib
ln -s libjpeg.so libjpeg.so.62
resolved the bug
Anyother has the same problem?
Don't symlink libraries
http://bugs.archlinux.org/task/15222#comment46995 -> it should be on its
way to a mirror near you.
Allan
2009/7/15 Allan McRae :
> If a full update does not help, you might want to try lddd from devtools to
> try and find what is still using libjpeg6.
It worked for me, but it seems it did not for the user, so I'm waiting
to know which mirror he uses and readelf's output.
Corrado
As a temp methord,
cd /usr/lib
ln -s libjpeg.so libjpeg.so.62
resolved the bug
Anyother has the same problem?
Thomas Bächler wrote:
bardo schrieb:
Hi guys.
Yesterday I rebuild mldonkey since it depended on libjpeg. On x86_64
there are no problems, and everything works as expected; this is not
the case for i686, where there's a strange problem:
[r...@plafone ~]# ldd /usr/bin/mldonkey | grep libjpeg
bardo schrieb:
Hi guys.
Yesterday I rebuild mldonkey since it depended on libjpeg. On x86_64
there are no problems, and everything works as expected; this is not
the case for i686, where there's a strange problem:
[r...@plafone ~]# ldd /usr/bin/mldonkey | grep libjpeg
libjpeg.so.7 => /us
2009/7/15 bardo :
> The package was created with makechrootpkg in a clean chroot. How is
> it even possible to link with two different versions of the same
> library? And where did it get the old version, since it didn't exist
> in the chroot?
I may start to understand... The command I posted was
Hi guys.
Yesterday I rebuild mldonkey since it depended on libjpeg. On x86_64
there are no problems, and everything works as expected; this is not
the case for i686, where there's a strange problem:
[r...@plafone ~]# ldd /usr/bin/mldonkey | grep libjpeg
libjpeg.so.7 => /usr/lib/libjpeg.so.
28 matches
Mail list logo
