Re: [gentoo-user] trouble emerging x11-libs/gtk+
Le 27/09/2010 21:25, Paul Hartman a écrit : That being said, here is generic advice for any failing to compile:) lafilefixer --justfixit revdep-rebuild This fixes it ;) Thank you Laurent
[gentoo-user] emerge python-updater - raise InvalidAtom(self)
Hello, after emerging portage emerging python-updater brock with this [...] File /home/prefix/gentoo/usr/lib/portage/pym/portage/dep/__init__.py, line 1006, in __init__ raise InvalidAtom(self) portage.exception.InvalidAtom: media-tv/vdrplugin-rebuild::Cygwin overlay I get the same error whenever I call emerge. I found this: http://forums.gentoo.org/viewtopic-t-840263-start-0.html However the case is different. There is no directory var/db/pkg/media-tv/... that I could remove and I never installed that. It's also a different line and function that rises the error: 647 vs. 1006. How can I clean this up? Thanks Al
Re: [gentoo-user] Re: How to compile for less bits :)
Grant Edwards grant.b.edwa...@gmail.com [10-09-27 21:16]: On 2010-09-27, meino.cra...@gmx.de meino.cra...@gmx.de wrote: For my microcontroller board (ATMEL AT81RM920, linux based) Do you mean AT91RM9200? I want to crosscompile kernels and applications on my 64bit Gentoo linux. That's easy enough. The source of a gcc (prepared on a 32bit system I fear) for the purpose of crosscompiling from a 32bit system-- target is the above mentioned processor -- is available. Is it possible to compile this gcc as a 32bit-application on my 64bit system to ensure the same behaviour as it would if to was built on a original 32bit Gentoo Linux? You want to compile gcc on an AMD64 machine and end up with a cross-compiler that runs as an IA32 app and generates code for an ARM9 target? That's called a Canadian Cross, and is rather tricky, since it involves three different architectures: building a compiler on architecture A (AMD64) to be run on architecture B (IA32) and generate code for architecture C (ARM9). Can you explain why you want that rather than a normal cross compiler? IOW, why do you want to build a gcc cross compiler that runs as a 32-bit application? It's _way_ simpler to build a normal cross compiler: building a compiler one architecture (AMD64) to be run on that same architecture (AMD64) and generate code for a second architecture (ARM9). (And in this context: The audio application chuck is only as 32bit application available currently. How is it possible to compile this on a 64bit system?) You use a compiler that generates code for a the desired 32-bit architecture. The width of the host is immaterial. The easiest way to build such a compiler is using crosstool-ng http://ymorin.is-a-geek.org/projects/crosstool Crosstool-NG does have some support for doing a Canadian-cross, but I don't see why you would want to do that. -- Grant Edwards grant.b.edwardsYow! Gibble, Gobble, we at ACCEPT YOU ... gmail.com Hi Grant, Thank you very much for your offered help! Sorry, sorry I think my English confused a lot of infos... I'll try it again. Setup BEFORE I switched to 64bit Gentoo Linux. * a normal system gcc as installed by emerge usually on many (all?) gentoo systems... * a crosscompiling gcc in source form. Compiled with the normal gcc to an executable which runs on the 32bit Gentoo system and produces executables/kernel to run on the ATMEL AT91RM9200 (yes, you're right - this typo was mine ;) ) . * Additional chuck audio application only available for 32bit Linux, also compiled with the normal gcc Wanted setup on my shiny new 64bit Gentoo Linux: * a normal system gcc as installed by emerge usually on many (all?) gentoo systems... (== already there and living quite well) * a crosscompiling gcc in source form. To be Compiled with the normal gcc to an executable which runs on the 64bit Gentoo system and produces executables/kernel to run on the ATMEL AT91RM9200 (yes, you're right - this typo was mine ;) ) . OR: compiled to be an 32bit gcc-executable which generate executable binaries for my ATMEL cookie. As long a 64bit-executable of gcc can do the job I would prefer that solution of course. * Additional chuck audio application only available for 32bit Linux, to be compiled with the normal gcc to be a 32 bit executable since not 64bit-ready. I hope not to have made too much knots into that above... Best regards mcc
Re: [gentoo-user] emerge python-updater - raise InvalidAtom(self)
On 9/29/10, Al oss.el...@googlemail.com wrote: Hello, after emerging portage emerging python-updater brock with this [...] File /home/prefix/gentoo/usr/lib/portage/pym/portage/dep/__init__.py, line 1006, in __init__ raise InvalidAtom(self) portage.exception.InvalidAtom: media-tv/vdrplugin-rebuild::Cygwin overlay I get the same error whenever I call emerge. I found this: http://forums.gentoo.org/viewtopic-t-840263-start-0.html However the case is different. There is no directory var/db/pkg/media-tv/... that I could remove and I never installed that. It's also a different line and function that rises the error: 647 vs. 1006. How can I clean this up? IIRC repo names must be single strings without spaces. -- Arttu V. -- Running Gentoo is like running with scissors
[gentoo-user] e17 default theme fonts
Hi all, So, few years ago I have tried e17 and it was fascinating! Really. Now I wanted to try again. The default theme font it's maybe yogesh fonts. It's unreadable for my eyes. Somebody can tell me how can I change the default font? I won't edit theme file or make a new file. Just changing the font. The strange thing is that I wanted work with opera browser and opera has yogesh default font to. Anybody has any idea what is happened? Thanks in advance! András -- - - -- Csanyi Andras (Sayusi Ando) -- http://sayusi.hu -- http://facebook.com/andras.csanyi -- Trust in God and keep your gunpowder dry! - Cromwell
[gentoo-user] Re: How to compile for less bits :)
On 2010-09-29, meino.cra...@gmx.de meino.cra...@gmx.de wrote: (And in this context: The audio application chuck is only as 32bit application available currently. How is it possible to compile this on a 64bit system?) You use a compiler that generates code for a the desired 32-bit architecture. The width of the host is immaterial. Thank you very much for your offered help! Sorry, sorry I think my English confused a lot of infos... Cross-building stuff is just plain confusing. I'll try it again. Setup BEFORE I switched to 64bit Gentoo Linux. * a normal system gcc as installed by emerge usually on many (all?) gentoo systems... * a crosscompiling gcc in source form. Compiled with the normal gcc to an executable which runs on the 32bit Gentoo system and produces executables/kernel to run on the ATMEL AT91RM9200 (yes, you're right - this typo was mine ;) ). * Additional chuck audio application only available for 32bit Linux, also compiled with the normal gcc Wanted setup on my shiny new 64bit Gentoo Linux: * a normal system gcc as installed by emerge usually on many (all?) gentoo systems... (== already there and living quite well) * a crosscompiling gcc in source form. To be Compiled with the normal gcc to an executable which runs on the 64bit Gentoo system and produces executables/kernel to run on the ATMEL AT91RM9200 (yes, you're right - this typo was mine ;) ) . All you need to do is build a cross compiler for the ARM9 target the same way you did before. The width of the host where you're building things doesn't matter (if it does, that's a bug in gcc or binutils). I've had excellent results using the crosstool-ng makefile: http://ymorin.is-a-geek.org/projects/crosstool Crosstool is used by a lot of embedded developers. If there were problems building an ARM comiler on an AMD64 host, Yann Morin et al. are your best bet for a solution. You may want to take a look at the crossgcc mailing list: http://news.gmane.org/gmane.comp.gcc.cross-compiling http://sourceware.org/ml/crossgcc/ From a brief search of the mailing list, it appears that building an ARM compiler on an AMD64 machines works just fine. or, It's quite likely that you can install IA32 libraries on your AMD64 host OS and then use the exact same compiler executable you used before. OR: compiled to be an 32bit gcc-executable which generate executable binaries for my ATMEL cookie. As long a 64bit-executable of gcc can do the job I would prefer that solution of course. You really don't want to do that. It's rather tricky, and it shouldn't be required. * Additional chuck audio application only available for 32bit Linux, to be compiled with the normal gcc to be a 32 bit executable since not 64bit-ready. Just use the arm-linux-gcc compiler and you should be fine regardless of the width of the host on which you built the arm-linux-gcc compiler. -- Grant Edwards grant.b.edwardsYow! It's the RINSE CYCLE!! at They've ALL IGNORED the gmail.comRINSE CYCLE!!
Re: [gentoo-user] e17 default theme fonts
On Wednesday 29 September 2010 18:50:45 András Csányi wrote: Hi all, So, few years ago I have tried e17 and it was fascinating! Really. Now I wanted to try again. The default theme font it's maybe yogesh fonts. It's unreadable for my eyes. Somebody can tell me how can I change the default font? I won't edit theme file or make a new file. Just changing the font. The strange thing is that I wanted work with opera browser and opera has yogesh default font to. Anybody has any idea what is happened? Hmm ... I'm not even sure I have such a font installed. Either way, go to Settings Panel/Look/Fonts and change it according to what suits you. If you want to change the size of the font, then scroll down beyond fonts, until you find Scaling, where you can change the dpi to make the fonts look larger. HTH. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Notice: possible past, present and future breakage related to .la files
Hi all users,
Some of you might have noticed, others might notice, a few would
probably not notice at all, that some Gentoo developers have started
removing the libtool archive files from packages that they maintain;
these changes have some times been applied to stable ebuilds as well,
but in all cases they won't be applied unless the package is re-emerged.
The reasoning behind this removal is too long to explain in this mail,
but you can find the start of it in [1], [2], and you can find some more
details in [3], [4] (yes these are all posts from my blog that I wrote
in the past few years). What matters to you (users) is that removing .la
files makes it less likely that unexpected libraries get linked in your
executables, even without --as-needed, or where --as-needed is not
working correctly.
If it sounds familiar as a situation, you might have gone through the
now-infamous libpng14 upgrade earlier this year [5], [6].
Removing .la files can cause, though, temporary disruption in the build
processes of libraries depending on those involved, because of the
transitive nature of .la files. For instance you could experiences
something like this:
libtool: link: `/usr/lib/libdbus-1.la' is not a valid libtool archive
with libdbus-1.la being replaced by other library names. If this is the
case, _do not panic_! Nothing is irremediably broken and nothing will
have to be rebuilt!
First of all, you should install lafilefixer and let it pass through the
currently-installed system:
# emerge lafilefixer
# lafilefixer --justfixit
This will convert the references to libtool archives to the -llibname
form, which works both with and without them.
Secondly, you can avoid any future requirement for this by sanitising
the newly installed .la files; this can be done either by using the
(currently testing) Portage 2.1.9 series, or by adding the following
snippet to your /etc/portage/bashrc:
post_src_install() {
lafilefixer ${D}
}
(Users of the bashrcng feature can install a specific plugin to do the
job, I don't remember the name of it though, sorry!)
It's a one time process that _will_ save you from more breakage and work
to do in the future, so please bear with us.
Note: removal of .la files altogether from the system is _not_ possible
and _is_ going to break your system. This is why we've got to handle
this process with care and can't simply nuke them entirely. A few
packages (imagemagick, mpg123) actually use the .la files to load their
plugins; the libtool macros to detect libltld also rely on the presence
of $libdir/libltdl.la (even though it's not really necessary). Plus I
know of at least one package that installs data files with .la extension
even though they are not libtool archives.
Note #2: if you run revdep-rebuild before the above process, it _will_
find you a lot of packages to rebuild, and you'll waste a huge amount of
time running in circles.
At this time it is unclear what the path forward will be, if we either
keep removing .la files from packages, caring about the fact they are
not needed, and causing these disruption for who hasn't gone through the
above-noted process yet, or if we'll be doing a mass-removal and deal
separately with eventual breakage on packages that use them, like those
noted above. Both approaches have advantages and disadvantages and it's
mostly a matter of opinion and taste which one is better.
We'll be looking forward to make this more widely available knowledge
and we hope to be able to provide a better experience for all of you at
the end of this (bumpy) journey.
Thanks!
[1] http://blog.flameeyes.eu/2008/04/14/what-about-those-la-files
[2] http://blog.flameeyes.eu/s/lafiles-2
[3] http://blog.flameeyes.eu/s/lafiles-plugins
[4] http://blog.flameeyes.eu/s/lafiles-chart
[5] http://blog.flameeyes.eu/2010/05/12/gentoo-failed-us-again
[6] http://blog.flameeyes.eu/2010/06/29/stable-users-libpng-update
--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/
If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-user] Re: How to compile for less bits :)
Grant Edwards grant.b.edwa...@gmail.com [10-09-30 00:32]: On 2010-09-29, meino.cra...@gmx.de meino.cra...@gmx.de wrote: (And in this context: The audio application chuck is only as 32bit application available currently. How is it possible to compile this on a 64bit system?) You use a compiler that generates code for a the desired 32-bit architecture. The width of the host is immaterial. Thank you very much for your offered help! Sorry, sorry I think my English confused a lot of infos... Cross-building stuff is just plain confusing. I'll try it again. Setup BEFORE I switched to 64bit Gentoo Linux. * a normal system gcc as installed by emerge usually on many (all?) gentoo systems... * a crosscompiling gcc in source form. Compiled with the normal gcc to an executable which runs on the 32bit Gentoo system and produces executables/kernel to run on the ATMEL AT91RM9200 (yes, you're right - this typo was mine ;) ). * Additional chuck audio application only available for 32bit Linux, also compiled with the normal gcc Wanted setup on my shiny new 64bit Gentoo Linux: * a normal system gcc as installed by emerge usually on many (all?) gentoo systems... (== already there and living quite well) * a crosscompiling gcc in source form. To be Compiled with the normal gcc to an executable which runs on the 64bit Gentoo system and produces executables/kernel to run on the ATMEL AT91RM9200 (yes, you're right - this typo was mine ;) ) . All you need to do is build a cross compiler for the ARM9 target the same way you did before. The width of the host where you're building things doesn't matter (if it does, that's a bug in gcc or binutils). I've had excellent results using the crosstool-ng makefile: http://ymorin.is-a-geek.org/projects/crosstool Crosstool is used by a lot of embedded developers. If there were problems building an ARM comiler on an AMD64 host, Yann Morin et al. are your best bet for a solution. You may want to take a look at the crossgcc mailing list: http://news.gmane.org/gmane.comp.gcc.cross-compiling http://sourceware.org/ml/crossgcc/ From a brief search of the mailing list, it appears that building an ARM compiler on an AMD64 machines works just fine. or, It's quite likely that you can install IA32 libraries on your AMD64 host OS and then use the exact same compiler executable you used before. OR: compiled to be an 32bit gcc-executable which generate executable binaries for my ATMEL cookie. As long a 64bit-executable of gcc can do the job I would prefer that solution of course. You really don't want to do that. It's rather tricky, and it shouldn't be required. * Additional chuck audio application only available for 32bit Linux, to be compiled with the normal gcc to be a 32 bit executable since not 64bit-ready. Just use the arm-linux-gcc compiler and you should be fine regardless of the width of the host on which you built the arm-linux-gcc compiler. -- Grant Edwards grant.b.edwardsYow! It's the RINSE CYCLE!! at They've ALL IGNORED the gmail.comRINSE CYCLE!! Hi Grant, thank you very much for your help again ! :) Life on planet AMD64 becomes easier ;) One question remains open to me: * How can I build 32bit applicationa to run on a 64bit Gentoo Linux (I have both /lib32 and /lib64 and /usr/lib32 and /usr/lib64) with the normal gcc (64 bit executable) on the 64bit Gentoo Linux. Is this trick possible? (Chuck is not 64bit ready...) Thank you very much for your help in advance! Best regards, mcc
Re: [gentoo-user] Re: How to compile for less bits :)
Cross compiling on unix is confusing because the compiler sucks. On Sep 29, 2010 3:50 PM, Grant Edwards grant.b.edwa...@gmail.com wrote: On 2010-09-29, meino.cra...@gmx.de meino.cra...@gmx.de wrote: (And in this context: The aud... Thank you very much for your offered help! Sorry, sorry I think my English confused a lot of i... Cross-building stuff is just plain confusing. I'll try it again. Setup BEFORE I switched to 64bit Gentoo Linux. * a normal system gcc a... All you need to do is build a cross compiler for the ARM9 target the same way you did before. The width of the host where you're building things doesn't matter (if it does, that's a bug in gcc or binutils). I've had excellent results using the crosstool-ng makefile: http://ymorin.is-a-geek.org/projects/crosstool Crosstool is used by a lot of embedded developers. If there were problems building an ARM comiler on an AMD64 host, Yann Morin et al. are your best bet for a solution. You may want to take a look at the crossgcc mailing list: http://news.gmane.org/gmane.comp.gcc.cross-compiling http://sourceware.org/ml/crossgcc/ From a brief search of the mailing list, it appears that building an ARM compiler on an AMD64 machines works just fine. or, It's quite likely that you can install IA32 libraries on your AMD64 host OS and then use the exact same compiler executable you used before. OR: compiled to be an 32bit gcc-executable which generate executable binaries for my ATMEL ... You really don't want to do that. It's rather tricky, and it shouldn't be required. * Additional chuck audio application only available for 32bit Linux, to be compiled with th... Just use the arm-linux-gcc compiler and you should be fine regardless of the width of the host on which you built the arm-linux-gcc compiler. -- Grant Edwards grant.b.edwardsYow! It's the RINSE CYCLE!! at They've ALL IGNORED the gmail.comRINSE CYCLE!!
[gentoo-user] Re: How to compile for less bits :)
On 2010-09-29, meino.cra...@gmx.de meino.cra...@gmx.de wrote: One question remains open to me: * How can I build 32bit applicationa to run on a 64bit Gentoo Linux (I have both /lib32 and /lib64 and /usr/lib32 and /usr/lib64) with the normal gcc (64 bit executable) on the 64bit Gentoo Linux. Is this trick possible? (Chuck is not 64bit ready...) That I don't know. I thought you wanted to build chuck for the ARM target. -- Grant
[gentoo-user] Re: How to compile for less bits :)
On 2010-09-29, Jacob Todd jaketodd...@gmail.com wrote: Cross compiling on unix is confusing because the compiler sucks. We're all looking forward to the better one that you're writing. ;) [I admine that gcc has its warts, but you evidently haven't dealt with some of the compilers I have.] -- Grant
[gentoo-user] Re: Notice: possible past, present and future breakage related to .la files
On 09/29/2010 03:40 PM, Diego Elio Pettenò wrote: Hi all users, we hope to be able to provide a better experience for all of you at the end of this (bumpy) journey. Thanks! On behalf of the Geriatric Gentoo Users Group I say, No, please, allow us to thank YOU for all the great work you do for gentoo! Maintaining high quality is always an uphill battle, and those of us in the GGUG know and appreciate how much work you do on our behalf. So, once again, thanks from the old farts! Alan, Volker, Dale -- anything to add?
Re: [gentoo-user] Re: Notice: possible past, present and future breakage related to .la files
walt wrote: On 09/29/2010 03:40 PM, Diego Elio Pettenò wrote: Hi all users, we hope to be able to provide a better experience for all of you at the end of this (bumpy) journey. Thanks! On behalf of the Geriatric Gentoo Users Group I say, No, please, allow us to thank YOU for all the great work you do for gentoo! Maintaining high quality is always an uphill battle, and those of us in the GGUG know and appreciate how much work you do on our behalf. So, once again, thanks from the old farts! Alan, Volker, Dale -- anything to add? +1 If I could reproduce, I would say +2. Alas there is only one of me. Stop clapping and jumping up and down in your seat. ;-) As least we know this is coming. I just wonder why there wasn't something added to portage to fix this? Maybe that wasn't doable. If a person was to download a new stage3 and do a fresh install, would that put a end to this problem? In other words, does this affect new installs the same as old installs? Dale :-) :-)
Re: [gentoo-user] Re: How to compile for less bits :)
There's already great cross compilers on plan 9. No need to write a new one. On Sep 29, 2010 8:15 PM, Grant Edwards grant.b.edwa...@gmail.com wrote: On 2010-09-29, Jacob Todd jaketodd...@gmail.com wrote: Cross compiling on unix is confusing because the compiler sucks. We're all looking forward to the better one that you're writing. ;) [I admine that gcc has its warts, but you evidently haven't dealt with some of the compilers I have.] -- Grant
Re: [gentoo-user] Re: Notice: possible past, present and future breakage related to .la files
On Thursday 30 September 2010, walt wrote: On 09/29/2010 03:40 PM, Diego Elio Pettenò wrote: Hi all users, we hope to be able to provide a better experience for all of you at the end of this (bumpy) journey. Thanks! On behalf of the Geriatric Gentoo Users Group I say, No, please, allow us to thank YOU for all the great work you do for gentoo! Maintaining high quality is always an uphill battle, and those of us in the GGUG know and appreciate how much work you do on our behalf. So, once again, thanks from the old farts! Alan, Volker, Dale -- anything to add? thank you Diego for informing us about the upcoming fun. I am sure a lot of people will not read your mail and will complain about random breakage later. As always. ;)
Re: [gentoo-user] Re: Notice: possible past, present and future breakage related to .la files
Alan is relaxing by the seaside watching the waves go in and out. So he has nothing sensible to add at this time, but maybe on Sunday :-) On 09/29/2010 03:40 PM, Diego Elio Pettenò wrote: Hi all users, we hope to be able to provide a better experience for all of you at the end of this (bumpy) journey. Thanks! On behalf of the Geriatric Gentoo Users Group I say, No, please, allow us to thank YOU for all the great work you do for gentoo! Maintaining high quality is always an uphill battle, and those of us in the GGUG know and appreciate how much work you do on our behalf. So, once again, thanks from the old farts! Alan, Volker, Dale -- anything to add?
