Re: [gentoo-user] glibc 2.13 warning
On Wed, 9 Feb 2011 22:50:44 -0500, Philip Webb wrote: On Wed, 9 Feb 2011 19:09:14 -0500, Philip Webb wrote: (1) I never use testing versions of system pkgs like Glibc Someone has to or they'll never get tested. Come on ! -- not on a production system ! Who mentioned production systems? (2) I have FEATURES=buildsyspkg in make.conf . It didn't help here. The OP was making a proposal to solve the more general problem, incl requiring users to adopt (2) by default. No, he was stating that he had a particular setting, although Alan did suggest it as a default. Either way, it doesn't help with about the most serious package it's possible to break (I use FEATURES=buildpkg). signature.asc Description: PGP signature
Re: [gentoo-user] Disk Labels in Handbook
On Wed, Feb 9, 2011 at 10:58 PM, Alan McKinnon alan.mckin...@gmail.com wrote: Apparently, though unproven, at 16:27 on Wednesday 09 February 2011, Mark Knecht did opine thusly: On Wed, Feb 9, 2011 at 6:16 AM, Dale rdalek1...@gmail.com wrote: James wrote: Hello, So looking at the handbook, I was wondering why it does not describe how to use Disk Labels during the installation process. Dunno. So I poised this question on gentoo-doc and got this encouraging response from *JOSH* snip James Given that some folks on here have ran into USB drives changing the order of partitions, I think this is a good idea. If needed, they could at least introduce the subject then have it link to another page. Even if it is the simplest label of using boot, root and such labels and maybe a mention that there are other ways to accomplish the same thing. I ran into this issue a while back when I added a hard drive and it was not easy to work with. When I boot a CD/DVD, it sees them as hd* instead of sd* so that didn't help since the OS kernel sees them as sd*. It may be uphill to get this included or at least linked to something else explaining it but I think it is a good idea. I also added myself to the bug as well. I saw the post on -doc. Dale Following Walt's recent thread about his experiences using grub2 I think getting folks used to disk labels at installation time, be they names or even better UUID's, might fit in very well with installation instructions that cover using grub2 instead of grub as a boot loader. From a practical perspective, fs labels are easier than GUIDs, so I would recommend labels. Users can invent their own descriptive labels at install time and enter that into fstab. LABEL=SERVER1-ROOT is not much more effort than /dev/sda3 GUIDs are another story. They get autogenerated, are invariably displayed on the screen along with a huge number of other GUIDs (Murphy) and one has to copy paste the damn things into vi. GUIDs are great for ubuntu where an install script does all the heavy lifting, but Gentoo, being a vastly superior operating system, has made the devastatingly astounding assumption that users are actually able to think and type. Whodathunkedit? If we expect users to type stuff, we should set it up so they type easy stuff :-) -- alan dot mckinnon at gmail dot com Hi, If you use vi(m) you don't have to type too much neither. Just use :r!blkid /dev/sda in vi(m) and you have the UUID, with some additional information, but the rest is just vi(m) magic. Best regards Petri
Re: [gentoo-user] Disk Labels in Handbook
Neil Bothwick wrote: On Thu, 10 Feb 2011 12:00:24 +0200, Petri Rosenström wrote: If you use vi(m) you don't have to type too much neither. Just use :r!blkid /dev/sda in vi(m) and you have the UUID, with some additional information, but the rest is just vi(m) magic. None of which makes fstab any more readable. UUIDs are the worst option in this respect, although they do allow disks to be moved around. Filesystem labels are the best option for readability and not only do they allow disks to be moved but also individual filesystems. When I switched mine, I looked into the UUID option but never could figure out how to tell which is what. I have /boot, /, /home, /portage and /var but how do you get it to tell you the number for say /home? Of all the stuff I read, I never did find that. I agree tho, using the plain labels are easier to understand. Even I got that right. ;-) Dale :-) :-)
Re: [gentoo-user] Disk Labels in Handbook
On Thursday 10 February 2011 06:31:12 Dale wrote: Neil Bothwick wrote: On Thu, 10 Feb 2011 12:00:24 +0200, Petri Rosenström wrote: If you use vi(m) you don't have to type too much neither. Just use :r!blkid /dev/sda in vi(m) and you have the UUID, with some :additional information, but the rest is just vi(m) magic. None of which makes fstab any more readable. UUIDs are the worst option in this respect, although they do allow disks to be moved around. Filesystem labels are the best option for readability and not only do they allow disks to be moved but also individual filesystems. When I switched mine, I looked into the UUID option but never could figure out how to tell which is what. I have /boot, /, /home, /portage and /var but how do you get it to tell you the number for say /home? Of all the stuff I read, I never did find that. I agree tho, using the plain labels are easier to understand. Even I got that right. ;-) Dale :-) :-) Dale, Thanks to the email from Petri Rosenström earlier, I finally figured it out. If you know the current /dev/ for it, use: blkid /dev/ That will give you the UUID :) -- Joost
Re: [gentoo-user] Disk Labels in Handbook
Joost Roeleveld wrote: On Thursday 10 February 2011 06:31:12 Dale wrote: Neil Bothwick wrote: On Thu, 10 Feb 2011 12:00:24 +0200, Petri Rosenström wrote: If you use vi(m) you don't have to type too much neither. Just use :r!blkid /dev/sda in vi(m) and you have the UUID, with some :additional information, but the rest is just vi(m) magic. None of which makes fstab any more readable. UUIDs are the worst option in this respect, although they do allow disks to be moved around. Filesystem labels are the best option for readability and not only do they allow disks to be moved but also individual filesystems. When I switched mine, I looked into the UUID option but never could figure out how to tell which is what. I have /boot, /, /home, /portage and /var but how do you get it to tell you the number for say /home? Of all the stuff I read, I never did find that. I agree tho, using the plain labels are easier to understand. Even I got that right. ;-) Dale :-) :-) Dale, Thanks to the email from Petri Rosenström earlier, I finally figured it out. If you know the current /dev/ for it, use: blkid /dev/ That will give you the UUID :) -- Joost Kewl !! That works. Wonder if I should try this way out. See if I can mess this up. o_O Dale :-) :-)
Re: [gentoo-user] Disk Labels in Handbook
On Thursday 10 February 2011 06:45:53 Dale wrote: Joost Roeleveld wrote: On Thursday 10 February 2011 06:31:12 Dale wrote: Neil Bothwick wrote: On Thu, 10 Feb 2011 12:00:24 +0200, Petri Rosenström wrote: If you use vi(m) you don't have to type too much neither. Just use :r!blkid /dev/sda in vi(m) and you have the UUID, with some :additional information, but the rest is just vi(m) magic. None of which makes fstab any more readable. UUIDs are the worst option in this respect, although they do allow disks to be moved around. Filesystem labels are the best option for readability and not only do they allow disks to be moved but also individual filesystems. When I switched mine, I looked into the UUID option but never could figure out how to tell which is what. I have /boot, /, /home, /portage and /var but how do you get it to tell you the number for say /home? Of all the stuff I read, I never did find that. I agree tho, using the plain labels are easier to understand. Even I got that right. ;-) Dale :-) :-) Dale, Thanks to the email from Petri Rosenström earlier, I finally figured it out. If you know the current /dev/ for it, use: blkid /dev/ That will give you the UUID :) -- Joost Kewl !! That works. Wonder if I should try this way out. See if I can mess this up. o_O Dale :-) :-) In your case, yes and yes :) Just make sure you got a backup so you can go back to the way it works now ;) -- Joost
Re: [gentoo-user] Disk Labels in Handbook
On Thu, 10 Feb 2011 06:45:53 -0600, Dale wrote: Kewl !! That works. Wonder if I should try this way out. See if I can mess this up. o_O Why would you want to swap a concise, readable fstab for one that needs to be filled with comments to make any sense at all? signature.asc Description: PGP signature
Re: [gentoo-user] Disk Labels in Handbook
Neil Bothwick wrote: On Thu, 10 Feb 2011 06:45:53 -0600, Dale wrote: Kewl !! That works. Wonder if I should try this way out. See if I can mess this up. o_O Why would you want to swap a concise, readable fstab for one that needs to be filled with comments to make any sense at all? That's true but I may learn something. Then again, it may not work either. I'm going to think on this some more. Besides, I got a couple weeks uptime on my new rig. Dale :-) :-)
Re: [gentoo-user] Re: glibc 2.13 warning
Apparently, though unproven, at 04:07 on Thursday 10 February 2011, Keith Dart did opine thusly: === On Wed, 02/09, Dale wrote: === Now some of you know how much I hate windows. Of course, DOS wasn't much better, === Yep. I've been using Linux on my desktop since version 1.2, and UnixWare before that. Some Mac in there too. I avoid Windows like the plague that it is. Lucky you. I have to deal with MS DNS caches and ntp implementations. And PuTTY. OMFG, I hate PuTTY. Actually I hate PuTTY users but they cause me to hate PuTTY just as much. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] The CHOST variable
On 8/2/2011, at 9:55pm, Alan McKinnon wrote: ... If you're a gambling man, play it by the numbers: A re-install for a Gentoo user with a clue is a certain 1 hour of your life tops to get it redone with a recent stage 3, more likely 30 minutes. That will give you a working system albeit one a bit out of date that emerge -avunD world will fix nicely. That makes no sense to me at all. There are stage3s built on a daily basis - they won't be out of date at all. But they don't include system logger, cron, locale, or any of your personalisations. On any kind of complex system it will take me more than a day to set those up - can I be sure that I'll get them right first time, every time? If we're talking about an older system then I need to back up everything so that I can copy files the files I missed from the /etc to the new one. If you're talking about stuff like KDE then that alone is going to take more than an hour to compile. I understood that a backup that was of your own system - that might be a bit out of date but which includes these things - was called a stage4. And in that case you're still faced with the problem that it's probably just as out of date as the install which is proving difficult to update in the first place. My experience of a system which was a year or even 18 months old was that it did have some blockers and some bugs which had been addressed here months before. It did require me to pull some files out of Gentoo's CVS attic and emerge the old ebuilds from my local tree, before they could be updated to current. But I knew that the configuration was sound and that all I had to do was address the blocker and then resume the `emerge -ud world`- the emerging is something that can go on in the background whilst I'm not paying attention. Stroller.
Re: [gentoo-user] The CHOST variable
On 8/2/2011, at 9:11pm, Nils Holland wrote: On 12:41 Tue 08 Feb , Stroller wrote: If my process wasn't clear from my last email: it looks like, following that document, you have to do the whole thing with changed CHOST, *before* making any changes to CFLAGS. It appears like only after you've `emerge -e world` with the new CHOST can you change CFLAGS. Thanks for the hint, right now I've got the i486 stage3 in a chroot and have changed both the CHOST and CFLAGS to i586. If that leads to problems, as you've described, I'll start over with only setting CHOST to i586 at first and then changing CFLAGS. Currently the build process is running fine, however, but I'm mentally prepared for difficults now. ;-) I completed the `emerge -e world` with the new CHOST, ran `lafilefixer --justfixit revdep-rebuild` and then Python and the Perl packages, as listed in the documentation. I'm pretty sure I ran `lafilefixer --justfixit revdep-rebuild` again, finding nothing. Changing CFLAGS=-march=native -O2 -pipe -fomit-frame-pointer failed again on the first package, ncurses. CFLAGS=-mtune=native -O2 -pipe -fomit-frame-pointer seems to be working (now on package 10 of 155). Perhaps I should have tried CFLAGS=-O2 -march=i586 -pipe instead. I don't really know what the -fomit-frame-pointer part does - I imagine someone suggested it, perhaps on here, years ago, and it has got copied from system to system. Stroller.
Re: [gentoo-user] Disk Labels in Handbook
On 9/2/2011, at 2:27pm, Mark Knecht wrote: ... Following Walt's recent thread about his experiences using grub2 I think getting folks used to disk labels at installation time, be they names or even better UUID's, might fit in very well with installation instructions that cover using grub2 instead of grub as a boot loader. IMO this is what makes the problem a little less tractable. Labels in /etc/fstab are nice, and they may ensure your disks are mounted correctly if the ordering changes. But the ordering might lead GRUB to be looking on the wrong disk for the kernel, and in that case labels in /etc/fstab alone don't help. AIUI GRUB2 isn't yet marked stable. I think I read that GRUB2 is 150MB or so, and contains support for jpegs and whatnot - that's not really what I want in a bootloader. At present use of /dev/sda1 c in the handbook is very consistent. Stroller.
[gentoo-user] Re: Bug#354229 Disk FS Labels in Handbook
walt w41ter at gmail.com writes: Correct, they are two different (but equivalent) ways of naming a filesystem (partition) for use in fstab. mkfs generates a UUID automatically when the fs is created, but it does *not* generate a label unless you give it one using the -L flag, or create one later using e2fslabel or some other utility. The syntax in fstab is either UUID=foo or LABEL=bar, but the idea is exactly the same. The whole point is to divorce the fs from the /dev/ it happens to reside on at boot time. Like I just posted in the previous thread, I think the subject of disk labels and file system labels *are related* and therefore a simple scheme should be developed and explained in the handbook. All sorts of advanced discussions, setup options and other related topics, like grub2 for now, should be located in linked documents. It's a simple subject that can easily become complicated depending on what one intends to achieved with disks and subsequent file systems located therein. We have BTFRS and a host of new file systems, not to mention CEPH and such coming down the pipe. Those topic will need to be documented elsewhere, but, imho, the mount point and currents explanations used in the handbook to set up disks, partitions and file systems, are very out-dated, again imho. Hence this discussion, from a wide base of opinion and experience will hopefully lead to a well written bug report, complete with examples, so all the DOC TEAM has to do is include it in the handbook. All input is welcome! James
[gentoo-user] Re: Disk Labels in Handbook
Neil Bothwick neil at digimed.co.uk writes: These aren't needed to get a system up and running. Yeah, Ubuntu uses them for various ID purposes, but nothing really critical. Unless there's a clear need for them, for example if some package in the @system set will use them in a way that our users will see, I doubt the handbook needs to cover them. Adding labels using udev just seems very finicky and time-consuming, and doesn't seem like it would be of much utility when users are already swamped with everything else the handbook asks them to do. Josh seems to be referring to UUID type disk labels, not filesystem labels. Which are you talking about? Well, I think having this discussion, here on Gentoo-User is our best place to sort out what we want. So far the discussion on using labels makes it simple and straight forward. Disk labels and file system labels are related topics, imho. My thoughts are follow the KISS (keep it simple sonny) means that using a scheme that is easy (like the default one currently in the handbook) makes the most sense. Bright, skilled users, such as those that adorn this list (cough gag snarl), surely can use various schemes. I like the idea of linking to another document for a robust collection of alternatives and such, but keep the handbook simple and straightforward. So Disk Labels would look quite a lot like file system labels, but, that is just my opinion. Surely this discussion is warranted, before we all vote (Neil) for our the best/brightest? person to complete the Bug. If it comes from the list and a discussion occurred, like this one, it can be reference from the bug, and the doc-devs will have some confidence that much thought went into the suggestion. This approach will superceed my half-baked ideas. Already we all agree that it is time to update the handbook. So I still seek guidance... and then consensus. and then we encourage one of our brighter members to complete the bug... Surely Josh will like that? After all, he is still the flux_gate... James
Re: [gentoo-user] The CHOST variable
On Thu, Feb 10, 2011 at 9:24 AM, Stroller strol...@stellar.eclipse.co.uk wrote: I don't really know what the -fomit-frame-pointer part does - I imagine someone suggested it, perhaps on here, years ago, and it has got copied from system to system. I think it removes your ability to get a stack trace when programs crash, in exchange for potentially more speed. If you're a programmer or filing bug reports on crashing software you should not use it, I don't think. But I could be wrong. :)
Re: [gentoo-user] The CHOST variable
On 10/2/2011, at 4:22pm, Paul Hartman wrote: On Thu, Feb 10, 2011 at 9:24 AM, Stroller strol...@stellar.eclipse.co.uk wrote: I don't really know what the -fomit-frame-pointer part does - I imagine someone suggested it, perhaps on here, years ago, and it has got copied from system to system. I think it removes your ability to get a stack trace when programs crash, in exchange for potentially more speed. If you're a programmer or filing bug reports on crashing software you should not use it, I don't think. But I could be wrong. :) Thanks! :D I appreciate the informative helpful answer. Stroller.
Re: [gentoo-user] glibc 2.13 warning
On Thursday 10 February 2011 00:02:07 Neil Bothwick wrote: On Thu, 10 Feb 2011 01:48:18 +0200, Alan McKinnon wrote: And it's very difficult to downgrade it due to that hidden barf check in the ebuild. I have yet to find a supported, documented way to back out of glibc screw-ups; my way is to keep binpkgs of @system and use those. The trouble is that binpkgs keep a copy of the ebuild in them, so even if you remove the downgrade check fro the in-tree ebuild, it still fails. That one had me scratching my head for a few minutes. what happens if you remove the entry in /var/db? From gentoo's point of view, glibc suddenly is not installed. You are free to choose a version.
Re: [gentoo-user] glibc 2.13 warning
On Thu, 10 Feb 2011 09:10:06 -0800 (PST), Volker Armin Hemmann wrote: The trouble is that binpkgs keep a copy of the ebuild in them, so even if you remove the downgrade check fro the in-tree ebuild, it still fails. That one had me scratching my head for a few minutes. what happens if you remove the entry in /var/db? From gentoo's point of view, glibc suddenly is not installed. You are free to choose a version. That's a good question, I had assumed it was getting the info from the binpkg, but a grep of the entry in /var/db shows no sign of the warning message (it's not in the ebuild but in an eblit file) so removing the db entry would appear to be fruitless. However, I've already recovered two machines from glibc breakage this week, I'm not about to do anything to cause any more :( signature.asc Description: PGP signature
Re: [gentoo-user] The CHOST variable
Apparently, though unproven, at 17:18 on Thursday 10 February 2011, Stroller did opine thusly: On 8/2/2011, at 9:55pm, Alan McKinnon wrote: ... If you're a gambling man, play it by the numbers: A re-install for a Gentoo user with a clue is a certain 1 hour of your life tops to get it redone with a recent stage 3, more likely 30 minutes. That will give you a working system albeit one a bit out of date that emerge -avunD world will fix nicely. That makes no sense to me at all. There are stage3s built on a daily basis - they won't be out of date at all. But they don't include system logger, cron, locale, or any of your personalisations. All I'm saying is it is often better to go the reinstall route which will take a known amount of time for a certain result, rather than the try fix it route which is highly variable as to how long it will take or even if it will work at all. It's assumed that one has backups of world and all configs, or can make backups before starting the reinstall. As with all things YMMV and real circumstance trumps abstract theory every time On any kind of complex system it will take me more than a day to set those up - can I be sure that I'll get them right first time, every time? If we're talking about an older system then I need to back up everything so that I can copy files the files I missed from the /etc to the new one. If you're talking about stuff like KDE then that alone is going to take more than an hour to compile. I understood that a backup that was of your own system - that might be a bit out of date but which includes these things - was called a stage4. And in that case you're still faced with the problem that it's probably just as out of date as the install which is proving difficult to update in the first place. My experience of a system which was a year or even 18 months old was that it did have some blockers and some bugs which had been addressed here months before. It did require me to pull some files out of Gentoo's CVS attic and emerge the old ebuilds from my local tree, before they could be updated to current. But I knew that the configuration was sound and that all I had to do was address the blocker and then resume the `emerge -ud world`- the emerging is something that can go on in the background whilst I'm not paying attention. Stroller. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] The CHOST variable
On 10:22 Thu 10 Feb , Paul Hartman wrote: On Thu, Feb 10, 2011 at 9:24 AM, Stroller strol...@stellar.eclipse.co.uk wrote: I don't really know what the -fomit-frame-pointer part does - I imagine someone suggested it, perhaps on here, years ago, and it has got copied from system to system. I think it removes your ability to get a stack trace when programs crash, in exchange for potentially more speed. If you're a programmer or filing bug reports on crashing software you should not use it, I don't think. But I could be wrong. :) Yep, that option leads to the frame pointer not being saved / restored, making an additional register available (but obviously there are differences between architectures; on some this option has no effect at all). On architectures where it does have an effect, it would make debugging impossible. Well, after having written the last paragraph I've decided to check out the GCC man page for more information and see: According to the GCC man page -fomit-frame-pointer gets enabled by default when using optimization levels -O or higher (including, of course -O2, which in my experience is what most people seem to use). As a matter of fact, I have -O2 but intentionally not set -fomit-frame-pointer, not being aware that with -O2, I automatically get it. ;-) I'll have to check out the Gentoo handbook, but if I remember correctly, it actually suggests using -O2 but better stay away from -fomit-frame-pointer. If it really suggests this, that might be considered a bug I guess. ;-) Greetings, Nils -- Nils Holland * Ti Systems, Wunstorf-Luthe (Germany) Powered by GNU/Linux since 1998
[gentoo-user] 32bit xulrunner version?
Hello, Is there a way to install a 32bit version of xulrunner? An application I am using on top of eclipse apparently needs a 32bit version. Don't know exactly why... Currently I have: /usr/lib64/xulrunner-1.9.2 /usr/lib64/xulrunner-devel-1.9.2 /usr/lib64/xulrunner-1.9.2/LICENSE /usr/lib64/xulrunner-1.9.2/README.txt /usr/lib64/xulrunner-1.9.2/chrome ... and I was told to point to MOZILLA_FIVE_HOME=/usr/lib32/xulrunner-1.9.2 Thanks, -- Valmor
Re: [gentoo-user] 32bit xulrunner version?
On Thu, 2011-02-10 at 18:32 -0500, Valmor de Almeida wrote: Hello, Is there a way to install a 32bit version of xulrunner? An application I am using on top of eclipse apparently needs a 32bit version. Don't know exactly why... Currently I have: xulrunner is in the multilib layman overlay; I think you just need to add multilib to the overlay and set the 'lib32' USE flag. Note, however, that you'll end up building all of xulrunner's dependencies as 32-bit, and their dependencies, etc. It could take a while. --Mike
Re: [gentoo-user] 32bit xulrunner version?
On 02/10/2011 09:52 PM, Mike Edenfield wrote: On Thu, 2011-02-10 at 18:32 -0500, Valmor de Almeida wrote: Hello, Is there a way to install a 32bit version of xulrunner? An application I am using on top of eclipse apparently needs a 32bit version. Don't know exactly why... Currently I have: xulrunner is in the multilib layman overlay; I think you just need to add multilib to the overlay and set the 'lib32' USE flag. Note, however, that you'll end up building all of xulrunner's dependencies as 32-bit, and their dependencies, etc. It could take a while. --Mike What will happen to the existing lib64 xulrunner on my system? will it be replaced by lib32? Also will the USE flag lib32 show up after I add the multilib overlay? At the moment I get: - euse -i lib32 global use flags (searching: lib32) no matching entries found local use flags (searching: lib32) no matching entries found Will a lib32 show up when xulrunner is emerged from the multilib overlay? As of now no such USE flag exists - equery uses xulrunner [ Searching for packages matching xulrunner... ] [ Colour Code : set unset ] [ Legend : Left column (U) - USE flags from make.conf ] [: Right column (I) - USE flags packages was installed with ] [ Found these USE variables for net-libs/xulrunner-1.9.2.12 ] U I + + alsa : Adds support for media-libs/alsa-lib (Advanced Linux Sound Architecture) - - custom-optimization : Fine-tune custom compiler optimizations - - dbus : Enable dbus support for anything that needs it (gpsd, gnomemeeting, etc) - - debug: Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see http://www.gentoo.org/proj/en/qa/backtraces.xml - - elibc_FreeBSD: ELIBC setting for systems that use the FreeBSD C library - - gnome: Adds GNOME support - + ipc : Use inter-process communication between tabs and plugins. Allows for greater stability in case of plugin crashes + + java : Adds support for Java - - libnotify: Enable desktop notification support - - startup-notification : Enable application startup event feedback mechanism - - system-sqlite: Use the system-wide dev-db/sqlite installation with secure-delete enabled - - wifi : Enable wireless network functions Thanks for the inputs. -- Valmor
