[gentoo-user] Re: Fire the fox.
On 09/19/10 18:08, Alan McKinnon wrote: Firefox 4 indeed is smoother (probably due to the new animations, probably because none of the plugins I used are compatible yet, but maybe it is just faster); but it is definitely more memory hungrier than before. In Fx3, it usually took around ~20-25% of my 1GB RAM and that's with opening a bunch lot of pages; Fx4 generally takes around ~25-30%. While taking 30% of my RAM is fine when I'm not multitasking, the main problem is I am always multitasking. With Thunderbird taking another 15-20%, emerge ranging from 5-30%, and X about 5-10%, my computer is becoming unbearably slow when memory starved. I've been thinking about adding -Os (optimize-size) to my CFLAGS, does anyone knows if doing that will possibly bring down memory usage and speed up the computer? No it will not. It's the size of the binary code image that is reduced, you may find that the firefox *code* in memory is smaller too. But it will do nothing for the data structures firefox creates to do it's job. Makes sense, I just realized how stupid a thought it was...
[gentoo-user] Re: Fire the fox.
On 09/19/10 19:04, Dale wrote: Alan McKinnon wrote: Apparently, though unproven, at 07:45 on Sunday 19 September 2010, Lie Ryan did opine thusly: On 09/19/10 09:22, Hilco Wijbenga wrote: On 18 September 2010 15:14, Kevin O'Gormankogor...@gmail.com wrote: Is it just me? Or does Firefox get slower every release? And less stable. Indeed. But FF4 is *much* faster. And much more stable. At least, that was my experience when I tried it out. I had to go back to 3.6 because some of the plugins that I need were not yet supported for FF4. At least the later 3.6 releases aren't as unstable as the previous ones. Firefox 4 indeed is smoother (probably due to the new animations, probably because none of the plugins I used are compatible yet, but maybe it is just faster); but it is definitely more memory hungrier than before. In Fx3, it usually took around ~20-25% of my 1GB RAM and that's with opening a bunch lot of pages; Fx4 generally takes around ~25-30%. While taking 30% of my RAM is fine when I'm not multitasking, the main problem is I am always multitasking. With Thunderbird taking another 15-20%, emerge ranging from 5-30%, and X about 5-10%, my computer is becoming unbearably slow when memory starved. I've been thinking about adding -Os (optimize-size) to my CFLAGS, does anyone knows if doing that will possibly bring down memory usage and speed up the computer? No it will not. It's the size of the binary code image that is reduced, you may find that the firefox *code* in memory is smaller too. But it will do nothing for the data structures firefox creates to do it's job. Think of it this way: You have a MySQL instance taking up say 20MB in memory. You use it to access a 500G database so it uses a whopping amount of memory for the indexes. You somehow optimize MySQL so that the code is now 19MB. What effect does that have on the 500G database? Answer: none whatsoever. And you conclusions about memory usage are wrong too. When free says you have 1G or RAM (this is true) and top says Thunderbird uses 150M and Firefox 180M, together they do not use 330M. Much of that memory is shared. top tells you amount of memory that this process can access top does not tell you amount of memory that this process owns and that nothing else can access Yep. I use Seamonkey which is browser and email all in one. It doesn't use much when I first start it up. The amount it accumulates as time goes on depends on the websites I go to. If I go to sites that have a lot of flash, pictures and gifs, then it starts to using a lot more memory. If I go to say the gentoo forums which is mostly text, it doesn't change much. When I'm doing emerge or other things, I usually switches to Epiphany, dillo, or links; depending on how unbearable things becomes. Just like the example Alan gave, it's not the program itself that is using the memory, it's what you are doing with it that uses memory. I have found that the weather radar site and youtube are the biggest memory hogs. I'm opening mostly standard HTML pages (gmail, static pages, etc) and the memory usage is still quite bad. This is my Seamonkey with email also open and I have only visited a couple forums sites: 7493 dale 20 0 253m 133m 28m S 0.7 6.6 1:59.65 seamonkey-bin Incidentally, I've found that browsing using Thunderbrowse extension in Thunderbird is much more memory friendly than using Firefox itself (Thunderbird still uses around 15-20% memory, compared to 20-30% that Firefox uses). If only Thunderbrowse's interface is not so buggy...
[gentoo-user] Re: Fire the fox.
On 09/19/10 09:22, Hilco Wijbenga wrote: On 18 September 2010 15:14, Kevin O'Gorman kogor...@gmail.com wrote: Is it just me? Or does Firefox get slower every release? And less stable. Indeed. But FF4 is *much* faster. And much more stable. At least, that was my experience when I tried it out. I had to go back to 3.6 because some of the plugins that I need were not yet supported for FF4. At least the later 3.6 releases aren't as unstable as the previous ones. Firefox 4 indeed is smoother (probably due to the new animations, probably because none of the plugins I used are compatible yet, but maybe it is just faster); but it is definitely more memory hungrier than before. In Fx3, it usually took around ~20-25% of my 1GB RAM and that's with opening a bunch lot of pages; Fx4 generally takes around ~25-30%. While taking 30% of my RAM is fine when I'm not multitasking, the main problem is I am always multitasking. With Thunderbird taking another 15-20%, emerge ranging from 5-30%, and X about 5-10%, my computer is becoming unbearably slow when memory starved. I've been thinking about adding -Os (optimize-size) to my CFLAGS, does anyone knows if doing that will possibly bring down memory usage and speed up the computer?
[gentoo-user] Re: How many ways are there for a user to increase their permissions?
On 04/18/10 11:02, Jonathan wrote: On Sun, 18 Apr 2010 08:29:37 +1000 Lie Ryan lie.1...@gmail.com wrote: sudoedit is mainly just a shortcut for sudo $EDITOR (plus doing a few things). sudoedit is safer then sudo because sudoedit runs as root but nano (The editor) runs as your user. sudoedit uses a fixed path which is compiled into the program Yes, that's the few things part, sudoedit does solves a couple of security issues that you'd have if you start editor manually, probably calling it just a shortcut is too much undermining. Everything above (su,sudo,policykit,polkit) are just sugar for permission bits (owner,group,others+SUID,GUID); attempting to give finer control over the permissions or provide convenience services. Mess up the configuration and you may as well hand out the root password. They're much better than manual management though, which is unless you're forty-two security wizard in one body you will get it wrong. Most security holes in Linux comes from a SUID program that lets untrusted programs into the trusted-space. 53 SUID or GUID programs on my system! Why does cdrecord have SUID set? No idea. I found sudo, although very handy for desktop, is a huge security hole. And is inadequate for any secure system. This is simply because if you run a program as sudo, then in the next five minute you start a malicious program *without* sudo; the malicious program can gain root access by stealing your previous sudo's timestamp (yes, it can steal the timestamp without being explicitly invoked with sudo[1]). Before running a potentially untrusted program, you must explicitly kill your sudo timestamp with `sudo -k` or set sudo to not use timestamp. Better yet, don't use sudo on secure systems. Wow... I never thought about that. I run sudo on my system 4 to 6 times a day if not more. Can tell me the setting please. Setting for the timeout? See `man sudoers` and look at timestamp_timeout. Setting for allowing program to steal timestamp? Don't worry, it's already default. I had a quick look at man pages and Gentoo docs but I did not see it. Gentoo sudo guide [1] could use a update about this. it was right under my nose but I missed it... If some leaves they PC for 5 mins you could run nano ~/.bashrc and add export PATH=/home/user/.bin:$PATH then make a file called sudo write something to nick the password and by it on to sudo and then clean up after it self. I believe the developers of `sudo` considered security against malicious people with physical access to the computer is out of their scope. Problem is, that means malicious people only need to trick a sudoers into running a piece of complex code and say you're not running my script with sudo, so the script can't do no harm to system. When I first used sudo, I thought by invoking sudo for trusted program only and omitting sudo for everything else and thought the system would be secure. That's a false sense of security. As long as you're a root-sudoers, all program you run can gain root access any time they need to. They just need to daemonize and poll every few minutes for an updated timestamp. Just for fun I did that to one of my terminal tabs, with the script running echo HAHA!. I once written a script that have this in the first line: if [ $UID != 0 ]; then sudo $0 quit fi # do business that requires root the script runs without asking password if I still have active timestamp from running another program. How convenient! (and makes me shivers)
[gentoo-user] Re: Installing Gentoo via Gentoo ?
On 04/18/10 22:21, meino.cra...@gmx.de wrote: Hi, currently I am reading the Gentoo-Handbokk about installing a new Gentoo-System via boot-CD. If I have a running Gentoo-Sytem on my PC...would it be possible to install a new Gentoo-System on a fresh harddisk, which is currently unpartitioned and unformatted electrically wired with my PC (SATAII) ? Yes, you should be able to, installing Gentoo is basically just copying a bunch of files to a partition in a harddisk, nothing magical. However, you will have to be able to compile a compatible kernel from your PC. Compatible usually means either your PC have the same architecture as your laptop (which means everything should be already setup) or you have to cross-compile the kernel. I've never done kernel cross-compiling, but it's definitely possible, you just need to modify modify some of the Makefile manually (search on google for a howto). Also, I'm not sure whether a bootloader installation needs to mess with the BIOS. I *think* it shouldn't, as the low-level booting process between the box and the harddisk is controlled by BIOS from MBR and grub/lilo is just installing onto the MBR.
[gentoo-user] Re: vixie-cron keeps stopping
On 04/17/10 18:47, Mick wrote: On Friday 16 April 2010 22:25:47 Alan McKinnon wrote: On Friday 16 April 2010 20:29:27 Dale wrote: Blimey! That sounds like horribly_broken! Which cron do you recommend for a desktop? One question, do you actually need cron for desktop? I installed vixie because the installation manual says to, but never need to write any cron rule for anything and I don't think there any program I uses installs a cron rule. So why bother with cron?
[gentoo-user] Re: vixie-cron keeps stopping
On 04/17/10 23:08, Alan McKinnon wrote: On Saturday 17 April 2010 14:59:09 Lie Ryan wrote: On 04/17/10 18:47, Mick wrote: On Friday 16 April 2010 22:25:47 Alan McKinnon wrote: On Friday 16 April 2010 20:29:27 Dale wrote: Blimey! That sounds like horribly_broken! Which cron do you recommend for a desktop? One question, do you actually need cron for desktop? I installed vixie because the installation manual says to, but never need to write any cron rule for anything and I don't think there any program I uses installs a cron rule. So why bother with cron? A default install will configure cron to run mkwhatis slocate logrotate updatepciids updateusbids I don't install `locate` as I don't have that many files to start with and `find` is more than adequate for when I need to search (and I typically only do searches on newly downloaded file or system files, those that aren't indexed in locate's database in the first place). In a typical desktop system you only rarely actually read logs (typically only when debugging kernel, X, and failed emerge; you don't meet kernel OOPS every day, don't you?), for the rest of the times I could probably live without logging and I can turn it on when I need to examine some logs. A typical desktop system do not update their hardware everyday and running those updater programs manually isn't such a pain when you do (on the other hand I run `emerge --sync` and `q -r` every week, but then I still much prefer running emerges manually). And bash's tab completion is much more efficient for searching commands than `whatis`. So I don't think a typical desktop system gets crippled much without cron (or even logging). Yes, you lose some features, and you will need to manually update system's database and do certain things manually which otherwise would have been handled for you; but if I have to choose between wasting system resources running cron/logging or losing features I use once in a month, I probably would not bother with cron.
[gentoo-user] Re: How many ways are there for a user to increase their permissions?
On 04/17/10 08:13, Jonathan wrote: I'm trying to work out how many ways there are to increase the permissions of a user. 1: su -: Needs root password and you need to be in the group wheel. 2: sudo: You need to be in the group wheel or in the /etc/sudoers file, using your own user password. I'm not counting gksu and gksudo they are just front ends. 3: sudoedit: This is the best way to edit text files, it uses the same rules as sudo. sudoedit is mainly just a shortcut for sudo $EDITOR (plus doing a few things). 4: Linux Capabilities or caps: Which increases permissions on a per-file basis. e.g. removing SUID from ping and adding CAP_NET_RAW to ping. This is much safer than running the whole program as root. http://linux.die.net/man/7/capabilities 5: Policykit: (Give this a read http://hal.freedesktop.org/docs/PolicyKit/introduction.html ) 6: Polkit: Is the new name for Policykit, it's a higher version and they do not talk to each other. If you run a mixed architecture there is a good chance you will have both. 8: SUID and SGID: One of the fastest ways to open up a security hole in your system. Everything above (su,sudo,policykit,polkit) are just sugar for permission bits (owner,group,others+SUID,GUID); attempting to give finer control over the permissions or provide convenience services. 9: Groups: Lots of groups, but not much information on what permissions you get. http://en.gentoo-wiki.com/wiki/List_of_Groups Udev and Fuse use group settings right? The basis of all Linux security scheme is the file permission bits (owner,group,other) and the SUID/GUID bit (ACL is a distinct security scheme, so we're explicitly excluding it here). Everything else is just sugar. If you want to lock everything, just remove the SUID/GUID-bit from all executables in your system (except for a select few) and remove all groups (make sure you know what you're doing though, lots of program won't work if you really do that). Starting from step zero, you can have very fine control over everything. 7: Access Control Lists: (ACL) Very easy to setup and forget because Nautilus and others do not list the ACL settings. A remote windows user configuring a samba share could let more people read and write to it then Nautilus shows. ACL is largely there for compatibility with Windows' permission scheme, it's a distinct security scheme than Linux. Did I miss any way of increasing your rights? (not counting security holes) Most security holes in Linux comes from a SUID program that lets untrusted programs into the trusted-space. I see that the stable net-misc/iputils (ping) does not use capabilities. Is this included in the unstable version, or is it planned for the future? I wish there was a way to run gedit with sudoedit, is there? I think Polkit support for gedit is planned, does anyone know the bug number? Right now my system has all of the above but not Linux capabilities. I'm having very hard time working out: Which users can do what and how. Which groups can do what and how. Which files can do what and who can run them. How the user's status affects what the program can do. All users can modify the permission bits for the files they owned, everything else is governed by the permission bits. Except for root, which has full access to everything. If you want simplify your environment, you can clear all the `group` and `other` permission bits from all files in your computer and everyone (except root) will only have access to files they own. Then you can start adding permissions on case-by-case basis. Too much hassle though, I think. Is there an all-in-one program for keeping track of all this or do I have to write one? It's very easy for users to set their home folder to other, read, write and execute. It's not just silly users doing that, but any program running with the users rights. There was a buggy program in Ubuntu which set your home folder to other rwx, I never worked out which one was doing that. the only way the program can chmod a file in your home folder is because the program have the permission to chmod a file in your home folder. The only program that have permission to chmod a file in your home folder is the one run with EUID-root or EUID-owner. The only way a program can be run with EUID root is they are executed by root himself or a SUID-root program. The only way a program can be run with EUID owner is SUID-owner program or program executed by the owner himself. However, I don't think buggy program is the case here. It is much more likely that you accidentally runs chmod on your home folder when you actually want to run it in another directory. A fast work around was to set the user's home folder to owner root and make sure that group was set to rwx. Is that safe? You can use this to find all SUID program accesible by your user: find / -perm -u+s -exec ls -l '{}' \; 2 /dev/null I found sudo, although very handy for
[gentoo-user] Re: Anyone ever emerged dev-libs/boost with FEATURES=test and finished?
On 04/06/10 17:23, Neil Bothwick wrote: On Tue, 06 Apr 2010 10:11:02 +1000, Lie Ryan wrote: Anyway, I've been thinking about this for some time that turning on FEATURES=test globally seems quite impractical for many users FEATURES=test is not meant to be used by users, it is a developer setting, and they would only enable it for packages they maintain and then only when they ant to run the tests. But most developers do not have the resources to test on all combinations of platforms. If the barrier for FEATURES=test can be lowered, then everyone that wants to be a global tester can do it without sacrificing too muchs (plus they can control how much time they want to contribute) and this benefits all open-source software as a whole. Lowering barrier for testing also encourages developers to write unittest who would otherwise hand-waving it since they now know their unittest will really be testing the program's true correctness instead of an platform dependent correctness. Probably enabling test by default is too much to ask though. Due to this problem, I think portage could have a test policy feature so people can have finer control to filter out test suites that they don't want to run. This way globally FEATURES=test can be more feasible for most users (and probably can sometime be turned on by default). You can set features on a per-package basis by putting FEATURES=blah into /etc/portage/env/category/package.
[gentoo-user] Re: Anyone ever emerged dev-libs/boost with FEATURES=test and finished?
On 04/06/10 02:43, Paul Hartman wrote: On Mon, Apr 5, 2010 at 10:53 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Mon, Apr 5, 2010 at 9:15 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Sun, Apr 4, 2010 at 5:00 PM, Lie Ryan lie.1...@gmail.com wrote: I'm running with full system FEATURES=test on, and I have a couple of programs that depended on dev-libs/boost. The boost testsuite always fails in my computer due to insufficient disk space, I usually simply skip the test for boost and just go on with the merge. But today, I decided to let the testsuite run to completion; so in preparation for that, I plugged in an external harddisk and made it so that /var/tmp/portage points to an empty disk image in the external harddrive. This setup works ok, and the testsuite is still running, however I saw now that the disk image's is now taking ~18 GB (and counting) while du -sh on /var/tmp/portage counted ~13GB. So, the question is, has anyone successfully compiled and run FEATURES=test on boost and knows how much space the tests eat up in the end? I am suspecting of the possibility that maybe a testsuite gets into an infinite loop while writing a file or something constantly eats up diskspace. Or is it just that boost has an outrageously too extensive testsuite and it will turn out ok if I just left it to run. I'm trying it now, I have 64gb free in /var/tmp so I hope that's enough... :) After almost 1.5 hours it is at its 22000th target and using 14G of /var/tmp so far... I'll keep waiting. It finished, successfully. 1 hour 52 minutes (normal compile of boost without testing takes about 3 minutes). Peak disk usage was about 20G when i spot-checked... Finished too (sorry didn't post the update earlier). And passed the test too, great. Thank you for trying it as well! Final count: the disk image's size is now ~22G but I don't know how large the real disk usage in the end is since portage cleaned the /var/tmp/portage. That's one hell of a test! The ebuild checks for 1024M free, maybe they need to change that to check for 20G if testing? I think so too. Let's see if I can file a bug on that. Done: http://bugs.gentoo.org/show_bug.cgi?id=313315 --- Anyway, I've been thinking about this for some time that turning on FEATURES=test globally seems quite impractical for many users due to some test suites that: - takes a disproportionally huge amount of time to finish - takes a huge amount of harddisk - takes a huge amount of memory - pulled out optional dependencies used only for testing - ships with a test that unconditionally fails (e.g. unimplemented feature) but not marking it expected failure - other behavioral problems (using network, restarting, etc though I've never seen these sort of crime yet as of now, probably they're already filtered before it reaches me) Due to this problem, I think portage could have a test policy feature so people can have finer control to filter out test suites that they don't want to run. This way globally FEATURES=test can be more feasible for most users (and probably can sometime be turned on by default). So is there anyone here that actually wanted to run FEATURES=test globally, but are turned off when experiencing the problems it brings? Do you think if we want to hack this policy feature into portage or emerge, what's the best option? Using USE-flags won't require much change to emerge and portage but is quite inflexible; or new variables in ebuild file; or a separate (optional) test description file that portage will read and compare with the system's policy. Have better alternative?
[gentoo-user] Anyone ever emerged dev-libs/boost with FEATURES=test and finished?
I'm running with full system FEATURES=test on, and I have a couple of programs that depended on dev-libs/boost. The boost testsuite always fails in my computer due to insufficient disk space, I usually simply skip the test for boost and just go on with the merge. But today, I decided to let the testsuite run to completion; so in preparation for that, I plugged in an external harddisk and made it so that /var/tmp/portage points to an empty disk image in the external harddrive. This setup works ok, and the testsuite is still running, however I saw now that the disk image's is now taking ~18 GB (and counting) while du -sh on /var/tmp/portage counted ~13GB. So, the question is, has anyone successfully compiled and run FEATURES=test on boost and knows how much space the tests eat up in the end? I am suspecting of the possibility that maybe a testsuite gets into an infinite loop while writing a file or something constantly eats up diskspace. Or is it just that boost has an outrageously too extensive testsuite and it will turn out ok if I just left it to run.
[gentoo-user] Re: Official document for stabilization policy/guideline
On 03/03/2010 04:52 AM, Mark Loeser wrote: Lie Ryan lie.1...@gmail.com said: I've been running several ~arch-ed packages that appears to be compile and runs fine on my machine and would like to vote them for stabilization. Is it enough to just open a bug issue and pray that the arch manager would notice? The general policy is here: http://devmanual.gentoo.org/keywording/index.html#moving-from-~arch-to-arch Open a bug and let the package maintainer decide if that version should go stable yet, or not at all. We don't mark every version of each package stable since that would waste a lot of cycles all around. Thanks, these are exactly what I've not been able to look for for some time.
[gentoo-user] Official document for stabilization policy/guideline
I've found a few people referencing to a 30-day stabilization policy which basically says a package must be at least 30-days-old to be considered for stabilization, but is there any document that serves as an official guideline/checklist on how to consider to stabilize a package? Is the 30-day policy the only policy? I've been running several ~arch-ed packages that appears to be compile and runs fine on my machine and would like to vote them for stabilization. Is it enough to just open a bug issue and pray that the arch manager would notice?
[gentoo-user] Re: Gentoo down?
On 03/02/10 01:24, Mark Knecht wrote: I guess the web site is down this morning? (6:30AM PST) I cannot get through anyway. - Mark Confirmed, though I can still ping it.
[gentoo-user] Re: Problem with gethostname() returning incorrect value
Lie Ryan wrote: [1] for some reason, after setting HOSTNAME to localhost I can't start new GUI program/create new window after NetworkManager/nm-applet is running. I suspect there is some NetworkManager settings lying around somewhere that resets the name to lieryan and the change confused X. btw, in any case someone in the future is wondering; the NetworkManager's hostname settings are stored in /etc/dhcp/dhclient.conf on these line: send host-name HOSTNAME; supersede host-name HOSTNAME; after changing both this and the one in /etc/conf.d/hostname the computer's hostname is changed for good with none of the side effect.
[gentoo-user] Problem with gethostname() returning incorrect value
Hi, First, sorry if this is not the correct list. Second, the background story... I was tracking a problem that I have always ignored when updating python on my Gentoo laptop. The problem is that emerge-ing python always fail when FEATURES=test is on. Usually, I would just turn FEATURES=test off when updating python, but today I set up to search for the source of the failure. After downloading the latest svn version from python and a few hours of debugging python's test suite; I isolated the problem to this: lier...@lieryan ~/Desktop/pythontrunk/trunk $ ./python Python 2.7a0 (trunk:75376M, Oct 12 2009, 22:17:57) [GCC 4.3.2] on linux2 Type help, copyright, credits or license for more information. import socket socket.gethostname() 'lieryan' socket.gethostbyname(socket.gethostname()) Traceback (most recent call last): File stdin, line 1, in module socket.gaierror: [Errno -2] Name or service not known socket.gethostbyname('localhost') '127.0.0.1' From that, I see that socket.gethostname() returned 'lieryan' which is my user name; instead of 'localhost' which is the correct local machine's name. Tracking the interpreter's source code, it seems that socket.gethostname() simply returns what the libc's gethostname() returns; which man gethostname says The GNU C Library ... implements gethostname() as a library function that calls uname(2)... So running uname -a: lier...@lieryan ~/Desktop/pythontrunk/trunk $ uname -a Linux lieryan 2.6.28-gentoo-r5-LR-15 #14 SMP Tue Oct 6 18:12:23 EST 2009 x86_64 AMD Turion(tm) 64 X2 AuthenticAMD GNU/Linux So clearly this is an environmental issue. = It appears that gethostname() returns 'lieryan'; which is my user name instead of 'localhost' which, I believe, should be the correct hostname for the machine I'm currently in. Now I know where the source of the problem is; but I don't know how to fix it. Anyone got any idea what I should do to change the return value of gethostname()? Googling gethostname() only returned various versions of gethostname() man page. The man pages also mentioned about another libc's function sethostname() but this system call is not available in python and even if I write a C script to call sethostname() with the correct value; I doubt this will really fix the real root cause of the problem. Anyone got any lead? Extra information: lier...@lieryan ~/Desktop/pythontrunk/trunk $ /lib/libc.so.6 GNU C Library stable release version 2.9, by Roland McGrath et al. Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.3.2. Compiled on a Linux 2.6.28-gentoo-r5-LR-12 system on 2009-07-05. Available extensions: C stubs add-on version 2.1.2 crypt add-on version 2.1 by Michael Glad and others Gentoo snapshot 20081201 Gentoo patchset 5 GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al Support for some architectures added on, not maintained in glibc core. BIND-8.2.3-T5B For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html.
[gentoo-user] Re: Problem with gethostname() returning incorrect value
Xavier Parizet wrote: Lie Ryan a écrit : Hi, [SNIP] Extra information: lier...@lieryan ~/Desktop/pythontrunk/trunk $ /lib/libc.so.6 Here the output is clear : lieryan is your machine hostname as well as your username... So check your /etc/hosts and either edit the line containing 127.0.0.1 like this: 127.0.0.1 lieryan.your dns domain name lieryan localhost or set HOSTNAME variable in /etc/conf.d/hostname to localhost, put the error returned by python seems to indicate that you forgot to edit /etc/hosts to put the definition of lieryan hostname ip address. Thanks, redirecting 'lieryan' to 127.0.0.1 solves the problem. Though I'd have preferred not to have my username redirects to the local machine, changing HOSTNAME in /etc/conf.d/hostname seems to result in some unwanted side effects[1] to X. I can live with the redirection though, so problem solved for now. [1] for some reason, after setting HOSTNAME to localhost I can't start new GUI program/create new window after NetworkManager/nm-applet is running. I suspect there is some NetworkManager settings lying around somewhere that resets the name to lieryan and the change confused X.