Re: [gentoo-user] Makeing /dev/rtc1 accessible as soon as possible - how?
On Sun, 25 Aug 2013 06:04:13 meino.cra...@gmx.de wrote: Hi, There are two RTCs in my system: /dev/rtc0 and /dev/rtc1 rtc0 is not powered by a battery and forgets time/date with system shutdown and rtc1 is a I2C-rtc (DS3231) which is powered by a battery. It is extremly accurate in comparison with rtc0. rtc0 is accessible with system boot - rtc1 is not (current state). I know this might be obvious, but just in case: Have you checked to see if the dud RTC can be disabled in the BIOS? Or completely remove its drivers from the kernel? -- Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/ Asking for technical help in newsgroups? Read this first: http://catb.org/~esr/faqs/smart-questions.html#intro
Re: [gentoo-user] Proxy server problem
I set up squid on a remote system so I can browse the internet from that IP address. It works but it stalls frequently. I had similar results with ziproxy. I went over this with the squid list but we got nowhere as it seems to be some kind of a system or network problem. http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-3-5-hangs-the -en tire-system-td4660893.html Can anyone here help me figure out what is wrong? I'm not sure where to start. - Grant Just a quick pointer in case it applies to you: if you tunnel into the proxy machine (using ssh, VPN, proxychains and what not) you would suffer from packet fragmentation, which could quickly snowball. In this case try reducing your mtu to lower values, than the default ethernet 1500 byte packets, to cater for the overhead of the larger tunnelling headers. I've tried disconnecting from my SSH tunnel and changing the mtu on my laptop and on the remote proxy server via ifconfig and there is some kind of an improvement but I can't narrow it down. I've tried mtu down to 1000 on both systems but the proxy server still stalls sometimes. Any tips for narrowing this down further? - Grant Now that you mentioned using ssh, I don't think that you can improve this. An mtu at 1000 bytes is lower than I thought might have helped. The problem is caused by stacking tcp packets (tcp within tcp) each of which is using its own timeout for failed fragments. I think I may have misunderstood you. I do SSH into the machine running squid, but I don't tunnel through that connection in order to use the proxy. I connect to the remote squid instance directly via my browser and I also happen to SSH into the same machine to run commands. Do any of your recommendations apply in this scenario? - Grant The problem is explained here (tcp meltdown): http://sites.inka.de/~W1011/devel/tcp-tcp.html and here (useful relevant references to other works are also made): http://publications.lib.chalmers.se/records/fulltext/123799.pdf There are some suggested solutions like increasing buffer size, but I don't know this might work in a real world use case. You can experiment with different buffer sizes as suggested here and see if it makes a difference: http://www.cyberciti.biz/faq/linux-tcp-tuning/ If the interruptions are not acceptable to you, you could consider using a different tunnel method. A network layer VPN, like IPSec (you can use StrongSwan which also offers IKEv2 and MOBIKE for your laptop, or ipsec-tools with racoon for IKEv1 only) should work without such problems. You will be tunnelling tcp in udp packets. If you tunnel to your home router you will need to configure an IPSec tunnel mode connection, otherwise you would use an IPSec transport mode connection directly to your server after you allow IP protocol 50 packets through your router.
Re: [gentoo-user] Makeing /dev/rtc1 accessible as soon as possible - how?
Paul Colquhoun paul...@andor.dropbear.id.au [13-08-25 12:04]: On Sun, 25 Aug 2013 06:04:13 meino.cra...@gmx.de wrote: Hi, There are two RTCs in my system: /dev/rtc0 and /dev/rtc1 rtc0 is not powered by a battery and forgets time/date with system shutdown and rtc1 is a I2C-rtc (DS3231) which is powered by a battery. It is extremly accurate in comparison with rtc0. rtc0 is accessible with system boot - rtc1 is not (current state). I know this might be obvious, but just in case: Have you checked to see if the dud RTC can be disabled in the BIOS? Or completely remove its drivers from the kernel? -- Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/ Asking for technical help in newsgroups? Read this first: http://catb.org/~esr/faqs/smart-questions.html#intro Hi Paul, I cannot remove rtc0 since it is integrated into the CPU. I cannot remove the CPU for various reasons... ;) I put the script (see previous mail) into /etc/init.d and call it now at sysinit times. This works so far...but I still have entries in /sys and /proc which show 1.1.1970. Is there any way to get rid of the need to use echo..bla..bla into files of the sysfs but to give the kernel the needed informations directly, so rtc1 is available to the kernel...? Best regards, mcc
Re: [gentoo-user] Proxy server problem
On Sunday 25 Aug 2013 11:13:07 Grant wrote: I set up squid on a remote system so I can browse the internet from that IP address. It works but it stalls frequently. I had similar results with ziproxy. I went over this with the squid list but we got nowhere as it seems to be some kind of a system or network problem. http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-3-5-hangs- the -en tire-system-td4660893.html Can anyone here help me figure out what is wrong? I'm not sure where to start. - Grant Just a quick pointer in case it applies to you: if you tunnel into the proxy machine (using ssh, VPN, proxychains and what not) you would suffer from packet fragmentation, which could quickly snowball. In this case try reducing your mtu to lower values, than the default ethernet 1500 byte packets, to cater for the overhead of the larger tunnelling headers. I've tried disconnecting from my SSH tunnel and changing the mtu on my laptop and on the remote proxy server via ifconfig and there is some kind of an improvement but I can't narrow it down. I've tried mtu down to 1000 on both systems but the proxy server still stalls sometimes. Any tips for narrowing this down further? - Grant Now that you mentioned using ssh, I don't think that you can improve this. An mtu at 1000 bytes is lower than I thought might have helped. The problem is caused by stacking tcp packets (tcp within tcp) each of which is using its own timeout for failed fragments. I think I may have misunderstood you. I do SSH into the machine running squid, but I don't tunnel through that connection in order to use the proxy. I connect to the remote squid instance directly via my browser and I also happen to SSH into the same machine to run commands. Do any of your recommendations apply in this scenario? Ahh! I misunderstood your set up too. The problem I described only applies to setting up an application layer tunnel (e.g. SSH) and running tcp within that secure tunnel. In your case, you establish a direct connection to your server over http or https and a separate connection using SSH. No tunnelling involved and no tcp stacking. Sorry for the bum steer. Is this stalling problem happening when you just browse the internet, visiting websites, or do you get it when you are downloading large files such as videos, or music? If it is the former, then I am not sure what causes it. If it is the latter, then this may be relevant to http timeout settings. I don't have in depth knowledge of this, other than increasing timeout and data rates from default values on a hosted server to avoid this problem (apache's mod_reqtimeout). Eventually, I ended up using ftp to download large files, instead of http. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Makeing /dev/rtc1 accessible as soon as possible - how?
On Sunday 25 Aug 2013 11:35:29 meino.cra...@gmx.de wrote: Paul Colquhoun paul...@andor.dropbear.id.au [13-08-25 12:04]: On Sun, 25 Aug 2013 06:04:13 meino.cra...@gmx.de wrote: Hi, There are two RTCs in my system: /dev/rtc0 and /dev/rtc1 rtc0 is not powered by a battery and forgets time/date with system shutdown and rtc1 is a I2C-rtc (DS3231) which is powered by a battery. It is extremly accurate in comparison with rtc0. rtc0 is accessible with system boot - rtc1 is not (current state). I know this might be obvious, but just in case: Have you checked to see if the dud RTC can be disabled in the BIOS? Or completely remove its drivers from the kernel? Hi Paul, I cannot remove rtc0 since it is integrated into the CPU. I cannot remove the CPU for various reasons... ;) I put the script (see previous mail) into /etc/init.d and call it now at sysinit times. This works so far...but I still have entries in /sys and /proc which show 1.1.1970. Is there any way to get rid of the need to use echo..bla..bla into files of the sysfs but to give the kernel the needed informations directly, so rtc1 is available to the kernel...? I noticed you mentioned rtc0 is not powered by a battery, but that's what the CMOS battery does. I'm curious why you don't add a new CMOS battery to your MoBo? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Makeing /dev/rtc1 accessible as soon as possible - how?
Mick michaelkintz...@gmail.com [13-08-25 13:44]: On Sunday 25 Aug 2013 11:35:29 meino.cra...@gmx.de wrote: Paul Colquhoun paul...@andor.dropbear.id.au [13-08-25 12:04]: On Sun, 25 Aug 2013 06:04:13 meino.cra...@gmx.de wrote: Hi, There are two RTCs in my system: /dev/rtc0 and /dev/rtc1 rtc0 is not powered by a battery and forgets time/date with system shutdown and rtc1 is a I2C-rtc (DS3231) which is powered by a battery. It is extremly accurate in comparison with rtc0. rtc0 is accessible with system boot - rtc1 is not (current state). I know this might be obvious, but just in case: Have you checked to see if the dud RTC can be disabled in the BIOS? Or completely remove its drivers from the kernel? Hi Paul, I cannot remove rtc0 since it is integrated into the CPU. I cannot remove the CPU for various reasons... ;) I put the script (see previous mail) into /etc/init.d and call it now at sysinit times. This works so far...but I still have entries in /sys and /proc which show 1.1.1970. Is there any way to get rid of the need to use echo..bla..bla into files of the sysfs but to give the kernel the needed informations directly, so rtc1 is available to the kernel...? I noticed you mentioned rtc0 is not powered by a battery, but that's what the CMOS battery does. I'm curious why you don't add a new CMOS battery to your MoBo? -- Regards, Mick Hi Mick, this MoBo has neither a BIOS and therefore no BIOS battery. I added the DS3231 rtc myself to get a battery buffered rtc. Best regards, mcc
Re: [gentoo-user] Makeing /dev/rtc1 accessible as soon as possible - how?
On 25/08/13 20:50, meino.cra...@gmx.de wrote: Mick michaelkintz...@gmail.com [13-08-25 13:44]: ... Hi Mick, this MoBo has neither a BIOS and therefore no BIOS battery. I added the DS3231 rtc myself to get a battery buffered rtc. Best regards, mcc What is the device ... a raspberry pi? A pi also has a rtc thats not battery backed so the first thing you need to do is set the time as soon as the network comes up with the results you describe ... nobody cares and the device works fine. Under what circumstances is this a problem? - I see where you say some files have an epoch date, but again thats normal for a pi and doesn't cause any problems. This might help us understand what you are trying to do ... BillK
[gentoo-user] gentoo on a kvm - can't install kernel sources
Hi List, Since a few days i'm trying to install gentoo on a kvm guest from edis.at. They support to boot from a gentoo minimal live-cd in order to install your own gentoo. The system has 5GB storage and 256MB ram. Actually that should be enough for a minimal installation. However, till now i couldn't get over that point where i'm trying to install the kernel sources... The partition of the hd looks like this right now: 64MB/boot 256MB swap ~4,3GB / Swap is active and i also made sure there are enough inodes on / (i had to raised them). Even though there is enough space and 256mb ram + 256mb swap should be enough ram i can't install (copy) the kernel sources. They just stop suddenly. There is nothing in the build.log. Last view lines are: /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-ac97.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-pcm.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa-ssp.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-i2s.c However i'll get errors in dmesg and it seems i'll get out of memory while installing: [snip] [63599.551452] emerge invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 [63599.551466] Pid: 12358, comm: emerge Not tainted 3.8.13-gentoo #1 . . . [63599.552434] Out of memory: Kill process 13382 (emerge) score 635 or sacrifice child [63599.552435] Killed process 13382 (emerge) total-vm:438472kB, anon- rss:206552kB, file-rss:0kB [snip] Any idea what i can do here, except buying an better kvm? From the docs 256MB should be fine so i don't know why it doesn't work? thx mmike
Re: [gentoo-user] gentoo on a kvm - can't install kernel sources
On Sunday 25 Aug 2013 14:51:33 Michael Mair-Keimberger wrote: Hi List, Since a few days i'm trying to install gentoo on a kvm guest from edis.at. They support to boot from a gentoo minimal live-cd in order to install your own gentoo. The system has 5GB storage and 256MB ram. Actually that should be enough for a minimal installation. However, till now i couldn't get over that point where i'm trying to install the kernel sources... The partition of the hd looks like this right now: 64MB /boot 256MB swap ~4,3GB/ Swap is active and i also made sure there are enough inodes on / (i had to raised them). Even though there is enough space and 256mb ram + 256mb swap should be enough ram i can't install (copy) the kernel sources. They just stop suddenly. There is nothing in the build.log. Last view lines are: /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-ac97.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-pcm.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa-ssp.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-i2s.c However i'll get errors in dmesg and it seems i'll get out of memory while installing: [snip] [63599.551452] emerge invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 [63599.551466] Pid: 12358, comm: emerge Not tainted 3.8.13-gentoo #1 . . . [63599.552434] Out of memory: Kill process 13382 (emerge) score 635 or sacrifice child [63599.552435] Killed process 13382 (emerge) total-vm:438472kB, anon- rss:206552kB, file-rss:0kB [snip] Any idea what i can do here, except buying an better kvm? From the docs 256MB should be fine so i don't know why it doesn't work? thx mmike I don't know why the docs say 256MB is enough, or if the statement is out of date. Did you try increasing swap just for now to see if it completes the installation? Some packages like gcc would eat up a lot RAM and it may never be able to finish compiling without more memory and/or swap. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Is sound broken?
Hi list, Today after I had my system down for its weekly backup, on restarting KDE (phonon) said some internal devices had been removed, in particular the default device. And indeed I had no sound. This was with kernel 3.10.7 driving the on-board Intel HDA audio. The kernel module snd_hda_intel had been loaded. On rebooting the previous kernel, 3.8.13, sound worked OK but KDE said it had noticed some other devices missing - presumably some that had been found by kernel 3.10.7. I've made the kernel configs the same as regards sound, but still I get sound from 3.8.13 but not from 3.10.7. The kernel change-log hasn't helped either. Anyone have a clue to offer? -- Regards, Peter
Re: [gentoo-user] Makeing /dev/rtc1 accessible as soon as possible - how?
William Kenworthy bi...@iinet.net.au [13-08-25 15:16]: On 25/08/13 20:50, meino.cra...@gmx.de wrote: Mick michaelkintz...@gmail.com [13-08-25 13:44]: ... Hi Mick, this MoBo has neither a BIOS and therefore no BIOS battery. I added the DS3231 rtc myself to get a battery buffered rtc. Best regards, mcc What is the device ... a raspberry pi? A pi also has a rtc thats not battery backed so the first thing you need to do is set the time as soon as the network comes up with the results you describe ... nobody cares and the device works fine. Under what circumstances is this a problem? - I see where you say some files have an epoch date, but again thats normal for a pi and doesn't cause any problems. This might help us understand what you are trying to do ... BillK Hi BillK, nearly ;) Its a Beaglebone Black... Regarding the situation of rtcs it is the same as with the Raspi. Changing between bein connected to the internet and being not creates a chaos is correctly and incorrectly time stamped files. Previously I got headaches while trying to figure out why certain things (emerging, compiling etc.) does not work properly. Secondly I feel be far more comfortably knowing that I do not have to care about the correct time stamps. Thirdly I dont like such a mess on my system... But the question remains: How can I can introduce the existing of a I2C device (the DS3231) to the system as soon as possible? Since the kernel can be configured to not only care about rtc0 but to use any other rtc, it must be possible to introduce/initiate such a device to the kernel in a pre-filesystem-mount state of booting the system...I simply dont know how... Best regards, mcc
Re: [gentoo-user] gentoo on a kvm - can't install kernel sources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/13 17:51, Michael Mair-Keimberger wrote: Hi List, Since a few days i'm trying to install gentoo on a kvm guest from edis.at. They support to boot from a gentoo minimal live-cd in order to install your own gentoo. The system has 5GB storage and 256MB ram. Actually that should be enough for a minimal installation. However, till now i couldn't get over that point where i'm trying to install the kernel sources... IMHO, 5Gb is not enough, have you tried df -h? - -- Stop talking and start compiling. Linux user #557897 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSGiOtAAoJEK64IL1uI2ha2lYIAIni4+C0UFrNi1xjyIdU7uSQ RgzgGfvomCPxzJDhM0HHWQEO7QWctxdaYXFV+DwFl3tZ67moUr5Ph4twGThGv92k 8KzU/u+wlhBfkXc4t3ZUoCi03/1omv65I/lqxC5n6StYC1S+aKqbEl2asoxLGinK ZY+HBGNTr56N0VsMp+hZYZxxhrWh/4X5U6O6BdW3Mq3DMTMg2mueKBwAnoijZjxm mCrteT0qyCMPX+umrPhMaiRw4wOhETD1NcXx1Y+7knnercCE7UGXcRLICYowX99V 0g8gix1cEazX+SdOGBoovT0cjzOXf96WcC9LPYzv9McBscJGTNcKp/OWMFvjAjM= =vIlH -END PGP SIGNATURE-
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On 25/08/2013 02:45, »Q« wrote: On Sat, 24 Aug 2013 09:49:43 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 24/08/2013 06:26, Chris Stankevitz wrote: On Fri, Aug 23, 2013 at 9:12 PM, »Q« boxc...@gmx.net wrote: It looks like maybe the best way to tell which ebuilds support which kernels is to read the conditional for the ewarn message in each ebuild. If this sort of problem spreads it might be good to build into portage some kind of blocker/keyword mechanism so that users need not deal with this not that I have any appreciation for the work involved. Those tools already exist. Blockers, which do not really apply here; In a comment on the bug (which is full of bugspam), someone suggested blocking kernels which are incompatible with the currently-installed nvidia-drivers. I'm glad that idea was dismissed. elog messages Those elog messages are presented after compiling a new kernel and then trying and failing to compile nvidia-drivers. So now I grep the nvidia-drivers ebuilds for the messages before I compile a new kernel. A wiki page with info about which nvidia-drivers will build against which kernels would be a nice thing to have. Your reply demonstrates nicely the true nature of the problem: With nvidia-drivers, sometimes things break and there's nothing sane that portage and the devs can do to help you. You can't check the configured kernels as they may not be running. You can't check the installed sources as they may not be in use. You can't even try identify the sources symlinked by /usr/src/linux as they may have been patched, tweaked or modified and nvidia-drivers may well build whereas against stock sources they don't. The entire problem is completely due to how nVidia chose to do things, it's their business decision. Now, if they were to get their shim code into mainline, most of this nonsense would not happen anymore. The only thing left for Portage and the devs to do is to provide the ebuild and ask you to run it. If it doesn't compile, then don't run that kernel. I doubt your wiki page idea will work, it will be just accurate enough to look like it might work and just inaccurate enough to be useless. Which brings you back to the previous paragraph - try emerge nvidia-drivers and if it fails then don't use that kernel. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] gentoo on a kvm - can't install kernel sources
On 25/08/2013 15:51, Michael Mair-Keimberger wrote: Hi List, Since a few days i'm trying to install gentoo on a kvm guest from edis.at. They support to boot from a gentoo minimal live-cd in order to install your own gentoo. The system has 5GB storage and 256MB ram. Actually that should be enough for a minimal installation. However, till now i couldn't get over that point where i'm trying to install the kernel sources... The partition of the hd looks like this right now: 64MB /boot 256MB swap ~4,3GB / Swap is active and i also made sure there are enough inodes on / (i had to raised them). Even though there is enough space and 256mb ram + 256mb swap should be enough ram i can't install (copy) the kernel sources. They just stop suddenly. There is nothing in the build.log. Last view lines are: /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-ac97.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-pcm.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa-ssp.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-i2s.c However i'll get errors in dmesg and it seems i'll get out of memory while installing: [snip] [63599.551452] emerge invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 [63599.551466] Pid: 12358, comm: emerge Not tainted 3.8.13-gentoo #1 . . . [63599.552434] Out of memory: Kill process 13382 (emerge) score 635 or sacrifice child [63599.552435] Killed process 13382 (emerge) total-vm:438472kB, anon-rss:206552kB, file-rss:0kB [snip] Any idea what i can do here, except buying an better kvm? From the docs 256MB should be fine so i don't know why it doesn't work? I cannot untar kernel sources on my virtualbox VMs with =256M either, and that goes back at least 18 months. tar just consumes too much memory. Your options: - untar somewhere else and copy the uncompressed sources over - get more memory when you build the kernel, you will find the same issue. gcc is going to use much more ram than 256M to get the job done. Do keep in mind that you can probably get that VM to *run* in teeny amounts of memory - maybe even only 64M - but building a kernel is a hugely memory-intensive task -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Proxy server problem
I set up squid on a remote system so I can browse the internet from that IP address. It works but it stalls frequently. I had similar results with ziproxy. I went over this with the squid list but we got nowhere as it seems to be some kind of a system or network problem. http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-3-5-hangs- the -en tire-system-td4660893.html Can anyone here help me figure out what is wrong? I'm not sure where to start. Is this stalling problem happening when you just browse the internet, visiting websites, or do you get it when you are downloading large files such as videos, or music? If it is the former, then I am not sure what causes it. If it is the latter, then this may be relevant to http timeout settings. Actually it happens when I'm just browsing the internet. How can a problem of this nature be debugged? - Grant
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On Sunday 25 Aug 2013 17:18:09 Alan McKinnon wrote: On 25/08/2013 02:45, »Q« wrote: On Sat, 24 Aug 2013 09:49:43 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 24/08/2013 06:26, Chris Stankevitz wrote: On Fri, Aug 23, 2013 at 9:12 PM, »Q« boxc...@gmx.net wrote: It looks like maybe the best way to tell which ebuilds support which kernels is to read the conditional for the ewarn message in each ebuild. If this sort of problem spreads it might be good to build into portage some kind of blocker/keyword mechanism so that users need not deal with this not that I have any appreciation for the work involved. Those tools already exist. Blockers, which do not really apply here; In a comment on the bug (which is full of bugspam), someone suggested blocking kernels which are incompatible with the currently-installed nvidia-drivers. I'm glad that idea was dismissed. elog messages Those elog messages are presented after compiling a new kernel and then trying and failing to compile nvidia-drivers. So now I grep the nvidia-drivers ebuilds for the messages before I compile a new kernel. A wiki page with info about which nvidia-drivers will build against which kernels would be a nice thing to have. Your reply demonstrates nicely the true nature of the problem: With nvidia-drivers, sometimes things break and there's nothing sane that portage and the devs can do to help you. You can't check the configured kernels as they may not be running. You can't check the installed sources as they may not be in use. You can't even try identify the sources symlinked by /usr/src/linux as they may have been patched, tweaked or modified and nvidia-drivers may well build whereas against stock sources they don't. The entire problem is completely due to how nVidia chose to do things, it's their business decision. Now, if they were to get their shim code into mainline, most of this nonsense would not happen anymore. The only thing left for Portage and the devs to do is to provide the ebuild and ask you to run it. If it doesn't compile, then don't run that kernel. I doubt your wiki page idea will work, it will be just accurate enough to look like it might work and just inaccurate enough to be useless. Which brings you back to the previous paragraph - try emerge nvidia-drivers and if it fails then don't use that kernel. I've been always running ATI Radeon cards, by accident rather than design. I was thinking of moving to NVidia on a new box to be built soon, because of the many accolades that I have read on the Internet, but reports of problems like this make me pause for thought. Sure it's not major borkage, but it is an inconvenience. How do NVidia users manage such problems? Trial and error? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] gentoo on a kvm - can't install kernel sources
On Sunday 25 August 2013 18:23:07 Alan McKinnon wrote: On 25/08/2013 15:51, Michael Mair-Keimberger wrote: Hi List, Since a few days i'm trying to install gentoo on a kvm guest from edis.at. They support to boot from a gentoo minimal live-cd in order to install your own gentoo. The system has 5GB storage and 256MB ram. Actually that should be enough for a minimal installation. However, till now i couldn't get over that point where i'm trying to install the kernel sources... The partition of the hd looks like this right now: 64MB /boot 256MB swap ~4,3GB / Swap is active and i also made sure there are enough inodes on / (i had to raised them). Even though there is enough space and 256mb ram + 256mb swap should be enough ram i can't install (copy) the kernel sources. They just stop suddenly. There is nothing in the build.log. Last view lines are: /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-ac97.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-pcm.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa-ssp.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-i2s.c However i'll get errors in dmesg and it seems i'll get out of memory while installing: [snip] [63599.551452] emerge invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 [63599.551466] Pid: 12358, comm: emerge Not tainted 3.8.13-gentoo #1 . . . [63599.552434] Out of memory: Kill process 13382 (emerge) score 635 or sacrifice child [63599.552435] Killed process 13382 (emerge) total-vm:438472kB, anon-rss:206552kB, file-rss:0kB [snip] Any idea what i can do here, except buying an better kvm? From the docs 256MB should be fine so i don't know why it doesn't work? I cannot untar kernel sources on my virtualbox VMs with =256M either, and that goes back at least 18 months. tar just consumes too much memory. Your options: - untar somewhere else and copy the uncompressed sources over - get more memory when you build the kernel, you will find the same issue. gcc is going to use much more ram than 256M to get the job done. Do keep in mind that you can probably get that VM to *run* in teeny amounts of memory - maybe even only 64M - but building a kernel is a hugely memory-intensive task Thx for crosschecking. Well it looks like docs are out of date, 256MB ram is definitely not enough. I already though about to extract it here and than copy it to the vm. However, uploading uncompressed kernel sources would take quite some time over my slow internet connection and i really wanted to avoid that. Anyway, either copy or buy a better vm. I guess i'll gonna make my own vm at home and copy the full system over... thx mmike
Re: [gentoo-user] Proxy server problem
On Aug 25, 2013 11:38 PM, Grant emailgr...@gmail.com wrote: I set up squid on a remote system so I can browse the internet from that IP address. It works but it stalls frequently. I had similar results with ziproxy. I went over this with the squid list but we got nowhere as it seems to be some kind of a system or network problem. http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-3-5-hangs- the -en tire-system-td4660893.html Can anyone here help me figure out what is wrong? I'm not sure where to start. Is this stalling problem happening when you just browse the internet, visiting websites, or do you get it when you are downloading large files such as videos, or music? If it is the former, then I am not sure what causes it. If it is the latter, then this may be relevant to http timeout settings. Actually it happens when I'm just browsing the internet. How can a problem of this nature be debugged? - Grant After reading your description on the squid mailing list, I'm suspicious that you might've run out of TCP buffers. Please post the results of: sysctl -A | egrep (mem)|(tcp) Rgds, --
[gentoo-user] having problems building webkit-gtk
I have been having problems building webkit-gtk right along through the various versions, but this one stumps me completely -- I get the error: libtool: link: x86_64-pc-linux-gnu-gcc -o /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/tmp-introspectCZNJhf/.libs/WebKit-3.0 -O2 -mtune=core\2 -pipe -std=c99 -Wl,-O1 -Wl,--no-keep-memory /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/tmp-introspectCZNJhf/WebKit-3.0.o -Wl,--export-dy\namic -pthread -Wl,--export-dynamic -Wl,--as-needed -L. /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/.libs/libwebkitgtk-3.0.so -L/usr/lib64\ -lenchant -lharfbuzz-icu -lharfbuzz -lgailutil-3 -lgeoclue -ldbus-glib-1 -ldbus-1 -lgstapp-1.0 -lgstaudio-1.0 -lgstfft-1.0 -lgstpbutils-1.0 -lgstvideo-1.0 -lg\stbase-1.0 -lgstreamer-1.0 -ljpeg -lsecret-1 -lxslt -lxml2 -lGL -ldl -lpangoft2-1.0 -lfreetype -lfontconfig -lpng16 -lsqlite3 -lwebp -lXcomposite -lXdamage -lX\fixes -lXrender -lXt -lX11 -lz /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/.libs/libjavascriptcoregtk-3.0.so -lpthread -licui18n -licuuc -l\icudata -lgthread-2.0 -lrt -lgmodule-2.0 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lsoup-2.4 -lgio-2.0 -\lgobject-2.0 -lglib-2.0 -pthread^M PT PaX marking -m ./tmp-introspectCZNJhf/.libs/WebKit-3.0^M ^M (process:24006): GLib-GObject-CRITICAL **: g_object_class_install_property: assertion `class-set_property != NULL' failed I have search through google and bgo and found nothing -- how can I fix this one? Thanks in advance for any suggestions. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] gentoo on a kvm - can't install kernel sources
On 25/08/13 at 07:01pm, Michael Mair-Keimberger wrote: Thx for crosschecking. Well it looks like docs are out of date, 256MB ram is definitely not enough. I already though about to extract it here and than copy it to the vm. However, uploading uncompressed kernel sources would take quite some time over my slow internet connection and i really wanted to avoid that. Anyway, either copy or buy a better vm. I guess i'll gonna make my own vm at home and copy the full system over... thx mmike Alternatively you can build the kernel and maybe bin packages of things that are too heavy to compile on the VM and just copy those. -- - Yohan Pereira The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. -- Mark Twain
[gentoo-user] Who sets the symlink /dev/rtc = /dev/rtc0 ?
Hi, In the kernel config I set CONFIG_RTC_HCTOSYS_DEVICE=rtc1 and I grepped through /etc and looked for something suspicious...nothing found. So...which ghost in my system dares to set the symlink /dev/rtc to point to /dev/rtc0 instead of /dev/rtc1 ??? Any ides? Best regards, mcc
Re: [gentoo-user] Who sets the symlink /dev/rtc = /dev/rtc0 ?
On Sunday 25 August 2013 20:26:32 meino.cra...@gmx.de wrote: Hi, In the kernel config I set CONFIG_RTC_HCTOSYS_DEVICE=rtc1 and I grepped through /etc and looked for something suspicious...nothing found. So...which ghost in my system dares to set the symlink /dev/rtc to point to /dev/rtc0 instead of /dev/rtc1 ??? Any ides? I bet it's /usr/lib64/udev/rules.d/50-udev-default.rules
Re: [gentoo-user] Who sets the symlink /dev/rtc = /dev/rtc0 ?
On 25/08/2013 20:26, meino.cra...@gmx.de wrote: Hi, In the kernel config I set CONFIG_RTC_HCTOSYS_DEVICE=rtc1 and I grepped through /etc and looked for something suspicious...nothing found. So...which ghost in my system dares to set the symlink /dev/rtc to point to /dev/rtc0 instead of /dev/rtc1 ??? You say there's a ghost in the machine, and the instant answer udev did not immediately jump into your mind? tut, tut (such an obvious target) :-) grep through every file installed by udev for rtc, let's see what comes out -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] gentoo on a kvm - can't install kernel sources
On 25/08/2013 19:01, Michael Mair-Keimberger wrote: On Sunday 25 August 2013 18:23:07 Alan McKinnon wrote: On 25/08/2013 15:51, Michael Mair-Keimberger wrote: Hi List, Since a few days i'm trying to install gentoo on a kvm guest from edis.at. They support to boot from a gentoo minimal live-cd in order to install your own gentoo. The system has 5GB storage and 256MB ram. Actually that should be enough for a minimal installation. However, till now i couldn't get over that point where i'm trying to install the kernel sources... The partition of the hd looks like this right now: 64MB /boot 256MB swap ~4,3GB / Swap is active and i also made sure there are enough inodes on / (i had to raised them). Even though there is enough space and 256mb ram + 256mb swap should be enough ram i can't install (copy) the kernel sources. They just stop suddenly. There is nothing in the build.log. Last view lines are: /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-ac97.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-pcm.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa-ssp.c /usr/src/linux-3.10.7-gentoo/sound/soc/pxa/pxa2xx-i2s.c However i'll get errors in dmesg and it seems i'll get out of memory while installing: [snip] [63599.551452] emerge invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 [63599.551466] Pid: 12358, comm: emerge Not tainted 3.8.13-gentoo #1 . . . [63599.552434] Out of memory: Kill process 13382 (emerge) score 635 or sacrifice child [63599.552435] Killed process 13382 (emerge) total-vm:438472kB, anon-rss:206552kB, file-rss:0kB [snip] Any idea what i can do here, except buying an better kvm? From the docs 256MB should be fine so i don't know why it doesn't work? I cannot untar kernel sources on my virtualbox VMs with =256M either, and that goes back at least 18 months. tar just consumes too much memory. Your options: - untar somewhere else and copy the uncompressed sources over - get more memory when you build the kernel, you will find the same issue. gcc is going to use much more ram than 256M to get the job done. Do keep in mind that you can probably get that VM to *run* in teeny amounts of memory - maybe even only 64M - but building a kernel is a hugely memory-intensive task Thx for crosschecking. Well it looks like docs are out of date, 256MB ram is definitely not enough. I already though about to extract it here and than copy it to the vm. However, uploading uncompressed kernel sources would take quite some time over my slow internet connection and i really wanted to avoid that. Anyway, either copy or buy a better vm. I guess i'll gonna make my own vm at home and copy the full system over... I'd recommend cross-building just a kernel and modules locally and copying that to the vm, it will only be about 6 to 8M Some food for thought: I do question the wisdom though of running Gentoo on a VM like that. I've always found that Gentoo (despite all it's fantastic awesomeness elsewhere) is really not fitted for that specific task very well - it tends to be a lot of pain and not much gain. Why do you want Gentoo on the vm? Is there a very good reason, or is it because you are familiar with it? If the second reason, you might want to have a look at FreeBSD or one of the binary distros based of Gentoo like Sabayon. You might find the best of both worlds in that space. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] having problems building webkit-gtk
On 25/08/2013 19:22, cov...@ccs.covici.com wrote: I have been having problems building webkit-gtk right along through the various versions, but this one stumps me completely -- I get the error: libtool: link: x86_64-pc-linux-gnu-gcc -o /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/tmp-introspectCZNJhf/.libs/WebKit-3.0 -O2 -mtune=core\2 -pipe -std=c99 -Wl,-O1 -Wl,--no-keep-memory /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/tmp-introspectCZNJhf/WebKit-3.0.o -Wl,--export-dy\namic -pthread -Wl,--export-dynamic -Wl,--as-needed -L. /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/.libs/libwebkitgtk-3.0.so -L/usr/lib64\ -lenchant -lharfbuzz-icu -lharfbuzz -lgailutil-3 -lgeoclue -ldbus-glib-1 -ldbus-1 -lgstapp-1.0 -lgstaudio-1.0 -lgstfft-1.0 -lgstpbutils-1.0 -lgstvideo-1.0 -lg\stbase-1.0 -lgstreamer-1.0 -ljpeg -lsecret-1 -lxslt -lxml2 -lGL -ldl -lpangoft2-1.0 -lfreetype -lfontconfig -lpng16 -lsqlite3 -lwebp -lXcomposite -lXdamage -lX\fixes -lXrender -lXt -lX11 -lz /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/.libs/libjavascriptcoregtk-3.0.so -lpthread -licui18n -licuuc -l\icudata -lgthread-2.0 -lrt -lgmodule-2.0 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lsoup-2.4 -lgio-2.0 -\lgobject-2.0 -lglib-2.0 -pthread^M PT PaX marking -m ./tmp-introspectCZNJhf/.libs/WebKit-3.0^M ^M (process:24006): GLib-GObject-CRITICAL **: g_object_class_install_property: assertion `class-set_property != NULL' failed I have search through google and bgo and found nothing -- how can I fix this one? Did you try building with -j1? I did find this one bgo, dunno if you found it in your searches (seems relevant at first glance): http://forums.gentoo.org/viewtopic-p-7369078.html https://bugs.webkit.org/show_bug.cgi?id=119261 https://bugs.gentoo.org/show_bug.cgi?id=463960 The first URL links to the other two. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On 08/25/2013 06:34 PM, Mick wrote: On Sunday 25 Aug 2013 17:18:09 Alan McKinnon wrote: On 25/08/2013 02:45, »Q« wrote: On Sat, 24 Aug 2013 09:49:43 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 24/08/2013 06:26, Chris Stankevitz wrote: On Fri, Aug 23, 2013 at 9:12 PM, »Q« boxc...@gmx.net wrote: It looks like maybe the best way to tell which ebuilds support which kernels is to read the conditional for the ewarn message in each ebuild. If this sort of problem spreads it might be good to build into portage some kind of blocker/keyword mechanism so that users need not deal with this not that I have any appreciation for the work involved. Those tools already exist. Blockers, which do not really apply here; In a comment on the bug (which is full of bugspam), someone suggested blocking kernels which are incompatible with the currently-installed nvidia-drivers. I'm glad that idea was dismissed. elog messages Those elog messages are presented after compiling a new kernel and then trying and failing to compile nvidia-drivers. So now I grep the nvidia-drivers ebuilds for the messages before I compile a new kernel. A wiki page with info about which nvidia-drivers will build against which kernels would be a nice thing to have. Your reply demonstrates nicely the true nature of the problem: With nvidia-drivers, sometimes things break and there's nothing sane that portage and the devs can do to help you. You can't check the configured kernels as they may not be running. You can't check the installed sources as they may not be in use. You can't even try identify the sources symlinked by /usr/src/linux as they may have been patched, tweaked or modified and nvidia-drivers may well build whereas against stock sources they don't. The entire problem is completely due to how nVidia chose to do things, it's their business decision. Now, if they were to get their shim code into mainline, most of this nonsense would not happen anymore. The only thing left for Portage and the devs to do is to provide the ebuild and ask you to run it. If it doesn't compile, then don't run that kernel. I doubt your wiki page idea will work, it will be just accurate enough to look like it might work and just inaccurate enough to be useless. Which brings you back to the previous paragraph - try emerge nvidia-drivers and if it fails then don't use that kernel. I've been always running ATI Radeon cards, by accident rather than design. I was thinking of moving to NVidia on a new box to be built soon, because of the many accolades that I have read on the Internet, but reports of problems like this make me pause for thought. Sure it's not major borkage, but it is an inconvenience. How do NVidia users manage such problems? Trial and error? Sort of. When I hit a nice spot with a kernel/nvidia-driver combination, then I do not update both for quite a while.
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On 25/08/2013 18:34, Mick wrote: On Sunday 25 Aug 2013 17:18:09 Alan McKinnon wrote: On 25/08/2013 02:45, »Q« wrote: On Sat, 24 Aug 2013 09:49:43 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 24/08/2013 06:26, Chris Stankevitz wrote: On Fri, Aug 23, 2013 at 9:12 PM, »Q« boxc...@gmx.net wrote: It looks like maybe the best way to tell which ebuilds support which kernels is to read the conditional for the ewarn message in each ebuild. If this sort of problem spreads it might be good to build into portage some kind of blocker/keyword mechanism so that users need not deal with this not that I have any appreciation for the work involved. Those tools already exist. Blockers, which do not really apply here; In a comment on the bug (which is full of bugspam), someone suggested blocking kernels which are incompatible with the currently-installed nvidia-drivers. I'm glad that idea was dismissed. elog messages Those elog messages are presented after compiling a new kernel and then trying and failing to compile nvidia-drivers. So now I grep the nvidia-drivers ebuilds for the messages before I compile a new kernel. A wiki page with info about which nvidia-drivers will build against which kernels would be a nice thing to have. Your reply demonstrates nicely the true nature of the problem: With nvidia-drivers, sometimes things break and there's nothing sane that portage and the devs can do to help you. You can't check the configured kernels as they may not be running. You can't check the installed sources as they may not be in use. You can't even try identify the sources symlinked by /usr/src/linux as they may have been patched, tweaked or modified and nvidia-drivers may well build whereas against stock sources they don't. The entire problem is completely due to how nVidia chose to do things, it's their business decision. Now, if they were to get their shim code into mainline, most of this nonsense would not happen anymore. The only thing left for Portage and the devs to do is to provide the ebuild and ask you to run it. If it doesn't compile, then don't run that kernel. I doubt your wiki page idea will work, it will be just accurate enough to look like it might work and just inaccurate enough to be useless. Which brings you back to the previous paragraph - try emerge nvidia-drivers and if it fails then don't use that kernel. I've been always running ATI Radeon cards, by accident rather than design. I was thinking of moving to NVidia on a new box to be built soon, because of the many accolades that I have read on the Internet, but reports of problems like this make me pause for thought. Sure it's not major borkage, but it is an inconvenience. How do NVidia users manage such problems? Trial and error? The second (trial and error). When you find a combination that works correctly and well, mark it in your mind as stable++ and stick with it. My current laptop has a Radeon, the three before that were nVidia. I just got used to having to use a kernel that was a few versions behind the most current one to be able to use the binary blob driver. It's really no big deal in the grand scheme of things - kernels don't change their behaviour *that* much between versions - most user-facing changes are new drivers and decent power management stuff. More often than not the user will have got along just nicely with an older kernel for a while, and that kernel will carry on doing what it always did and work. It's very rare that a user *must* have some new kernel and absolutely cannot go back to an earlier version. I satisfied myself with trying the most recent kernels once a month and seeing if the drivers built. If yes, and they worked, great. If not, oh well I would just go back to what I had before. Half the time I'd have to do that anyway due to some regression from nVidia anyway (I lost track of how often a driver update would send GPU temps through the roof and have the fan running constantly) nouveau also worked well for me. I don't need fancy 3D graphics (KDE and e17 effects is about my limit of GPU stressing) and I don't need awesome battery life, so I was willing to trade power efficiency and piece-of-mid efficiency. Your needs might be different so YMMV. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
hasufell wrote: On 08/25/2013 06:34 PM, Mick wrote: I've been always running ATI Radeon cards, by accident rather than design. I was thinking of moving to NVidia on a new box to be built soon, because of the many accolades that I have read on the Internet, but reports of problems like this make me pause for thought. Sure it's not major borkage, but it is an inconvenience. How do NVidia users manage such problems? Trial and error? Sort of. When I hit a nice spot with a kernel/nvidia-driver combination, then I do not update both for quite a while. I rarely have issues with them installing. I may find some odd bug but not a clash with kernel and driver. Then again, I don't update my kernel very often either. I did make it to 3.9.5 a little while back. I do recall reading about issues with the 3.10.* kernels tho. I think something moved or something and Nvidia needed to update the drivers. I would usually say I am lucky but folks that know me know better than that. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] gentoo on a kvm - can't install kernel sources
On 25/08/13 at 09:50pm, Alan McKinnon wrote: I'd recommend cross-building just a kernel and modules locally and copying that to the vm, it will only be about 6 to 8M Some food for thought: I do question the wisdom though of running Gentoo on a VM like that. I've always found that Gentoo (despite all it's fantastic awesomeness elsewhere) is really not fitted for that specific task very well - it tends to be a lot of pain and not much gain. Why do you want Gentoo on the vm? Is there a very good reason, or is it because you are familiar with it? If the second reason, you might want to have a look at FreeBSD or one of the binary distros based of Gentoo like Sabayon. You might find the best of both worlds in that space. Well I have a couple VM's running on 256 mb of RAM. While I'll admit I initially chose gentoo because of familiarity. It seemed to work out fine although I'll admit I've I haven't updated the kernel, just using the kernel provided by the host. AFAIR the heaviest(memory wise) thing I did on such a VM was running a java stock trading application in a virtual screen that was accessed via VNC. I've never had problems(yet) compiling gcc etc. I remeber being able to compile faster than my laptop's aging core 2 due processor. Currently I use one for my personal a mail server, quassel (irc client), tt-rss, git/mecurial collaboration, development web hosting and other random stuff. It hasn't borked on me yet but YMMV. Heres the output of free from the VM. $ free -m total used free sharedbuffers cached Mem: 246231 15 0 14157 -/+ buffers/cache: 59187 Swap: 494 57437 -- - Yohan Pereira The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. -- Mark Twain
Re: [gentoo-user] Who sets the symlink /dev/rtc = /dev/rtc0 ?
130825 Pavel Volkov suggested: On Sunday 25 August 2013 20:26:32 meino.cra...@gmx.de asked: So...which ghost in my system dares to set the symlink /dev/rtc to point to /dev/rtc0 instead of /dev/rtc1 ??? I bet it's /usr/lib64/udev/rules.d/50-udev-default.rules I have /usr/udev/rules.d/50-udev-default.rules (on a 64-bit system), which contains the lines : # select system RTC or just use the first one SUBSYSTEM==rtc, ATTR{hctosys}==1, SYMLINK+=rtc SUBSYSTEM==rtc, KERNEL==rtc0, SYMLINK+=rtc, OPTIONS+=link_priority=-100 However, in /dev I have : crw--- 1 root root 10, 135 Aug 25 07:39 /dev/rtc ie it's not a symlink. I'm using udev-204 . HTH -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Optional /usr merge in Gentoo
On 2013-08-18 5:16 AM, Alan McKinnon alan.mckin...@gmail.com wrote: While we're on the topic, what's the obsession with having different bits of the file hierarchy as different*mount points*? That harks back to the days when the only way to have a chunk of fs space be different was to have it as a separate physical thing and mount it. Nowadays we have something better - ZFS. To me this makes so much more sense. I have a large amount of storage called a pool, and set size limits and characteristics for various directories without having to deal with fixed size volumes. Eh? *Who* has ZFS? Certainly not the linux kernel.
Re: [gentoo-user] gentoo on a kvm - can't install kernel sources
On Monday 26 August 2013 01:49:17 Yohan Pereira wrote: On 25/08/13 at 09:50pm, Alan McKinnon wrote: I'd recommend cross-building just a kernel and modules locally and copying that to the vm, it will only be about 6 to 8M Some food for thought: I do question the wisdom though of running Gentoo on a VM like that. I've always found that Gentoo (despite all it's fantastic awesomeness elsewhere) is really not fitted for that specific task very well - it tends to be a lot of pain and not much gain. Why do you want Gentoo on the vm? Is there a very good reason, or is it because you are familiar with it? If the second reason, you might want to have a look at FreeBSD or one of the binary distros based of Gentoo like Sabayon. You might find the best of both worlds in that space. Well I have a couple VM's running on 256 mb of RAM. While I'll admit I initially chose gentoo because of familiarity. It seemed to work out fine although I'll admit I've I haven't updated the kernel, just using the kernel provided by the host. AFAIR the heaviest(memory wise) thing I did on such a VM was running a java stock trading application in a virtual screen that was accessed via VNC. I've never had problems(yet) compiling gcc etc. I remeber being able to compile faster than my laptop's aging core 2 due processor. Currently I use one for my personal a mail server, quassel (irc client), tt-rss, git/mecurial collaboration, development web hosting and other random stuff. It hasn't borked on me yet but YMMV. Heres the output of free from the VM. $ free -m total used free sharedbuffers cached Mem: 246231 15 0 14157 -/+ buffers/cache: 59187 Swap: 494 57437 Well, familiarity was my main reason but actually i though gentoo fits anyway quite good on such weak systems? (well besides compiling on it) You get a small system which needs not much space and performs quite good. (thats why 5GB is actually enough for me - i don't store anything there). FreeBSD might be a good alternative and in case gentoo is to much pain i'll give it a try. :) BTW, i have an alix device at home which also has just 256MB Ram and while the CF-Card (where the gentoo system is stored) has 8GB now, i've started with an 4GB CF-Card and i did compile on this device - even (hardened)kernels :) That was ~3 years ago, now i cross-compile for this device. However, gentoo on such devices runs perfectly well and rock stable. :) mmike
Re: [gentoo-user] gentoo on a kvm - can't install kernel sources
On 25/08/2013 23:33, Michael Mair-Keimberger wrote: On Monday 26 August 2013 01:49:17 Yohan Pereira wrote: On 25/08/13 at 09:50pm, Alan McKinnon wrote: I'd recommend cross-building just a kernel and modules locally and copying that to the vm, it will only be about 6 to 8M Some food for thought: I do question the wisdom though of running Gentoo on a VM like that. I've always found that Gentoo (despite all it's fantastic awesomeness elsewhere) is really not fitted for that specific task very well - it tends to be a lot of pain and not much gain. Why do you want Gentoo on the vm? Is there a very good reason, or is it because you are familiar with it? If the second reason, you might want to have a look at FreeBSD or one of the binary distros based of Gentoo like Sabayon. You might find the best of both worlds in that space. Well I have a couple VM's running on 256 mb of RAM. While I'll admit I initially chose gentoo because of familiarity. It seemed to work out fine although I'll admit I've I haven't updated the kernel, just using the kernel provided by the host. AFAIR the heaviest(memory wise) thing I did on such a VM was running a java stock trading application in a virtual screen that was accessed via VNC. I've never had problems(yet) compiling gcc etc. I remeber being able to compile faster than my laptop's aging core 2 due processor. Currently I use one for my personal a mail server, quassel (irc client), tt-rss, git/mecurial collaboration, development web hosting and other random stuff. It hasn't borked on me yet but YMMV. Heres the output of free from the VM. $ free -m total used free shared buffers cached Mem: 246 231 15 0 14 157 -/+ buffers/cache: 59 187 Swap: 494 57 437 Well, familiarity was my main reason but actually i though gentoo fits anyway quite good on such weak systems? (well besides compiling on it) You get a small system which needs not much space and performs quite good. (thats why 5GB is actually enough for me - i don't store anything there). FreeBSD might be a good alternative and in case gentoo is to much pain i'll give it a try. :) BTW, i have an alix device at home which also has just 256MB Ram and while the CF-Card (where the gentoo system is stored) has 8GB now, i've started with an 4GB CF-Card and i did compile on this device - even (hardened)kernels :) That was ~3 years ago, now i cross-compile for this device. However, gentoo on such devices runs perfectly well and rock stable. :) If it works for you then it works :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Optional /usr merge in Gentoo
On 18/08/2013 21:38, Tanstaafl wrote: On 2013-08-18 5:16 AM, Alan McKinnon alan.mckin...@gmail.com wrote: While we're on the topic, what's the obsession with having different bits of the file hierarchy as different*mount points*? That harks back to the days when the only way to have a chunk of fs space be different was to have it as a separate physical thing and mount it. Nowadays we have something better - ZFS. To me this makes so much more sense. I have a large amount of storage called a pool, and set size limits and characteristics for various directories without having to deal with fixed size volumes. Eh? *Who* has ZFS? Certainly not the linux kernel. FreeBSD You can get ZFS on Linux with relative ease, you just have to build it yourself. Distros feel they can't redistribute that code. The bit you quoted shouldn't be read to mean that we have ZFS, it works on Linux and everyone should activate it and use it and chuck ext* out the window. I meant that we've been chugging along since 1982 or so with ancient disk concepts that come mostly from MS_DOS and limited by that hardware of that day. And here we are in 2013 *still* fiddling with partition tables, fixed file systems, fixed mountpoints and we still bang our heads weekly because sda3 has proven to be too small, and it's a *huge* mission to change it. Yes, LVM has made this so much easier (kudos to Sistina for that) but I believe the entire approach is wrong. The ZFS approach is better - here's the storage, now do with it what I want but don't employ arbitrary fixed limits and structures to do it. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Makeing /dev/rtc1 accessible as soon as possible - how?
On Sun, Aug 25, 2013 at 12:54 PM, meino.cra...@gmx.de wrote: Hi Mark, hi William, the script ds3231 in /etc/init.d is -- according to rc-update -- set as folows: ds3231 | boot Long and short of it, here's the boot order: sysinit - boot - (single) - default rc(8) tells me that sysinit is for bringing up system specific stuff such as /dev, /proc, /sys. So it's appropriate for a special device file such as yours, with the caveat that you want it up AFTER any dependencies such as sysfs. Now how to do that is to make your script openrc compliant, so... There is no corresponding file in /etc/conf.d since the script onlu consist of two commands (see previous posting). There is no initramfs. Since openrc is running your script, it will check /etc/conf.d/same-name for any script with environment variables. Or you can put it in the init script itself. Mind you, I don't know where to find documentation on how openrc implements this, unlike, say, some controversial init system on this list... -- This email is:[ ] actionable [x] fyi[ ] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
[gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On Sun, 25 Aug 2013 18:18:09 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 25/08/2013 02:45, »Q« wrote: On Sat, 24 Aug 2013 09:49:43 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 24/08/2013 06:26, Chris Stankevitz wrote: On Fri, Aug 23, 2013 at 9:12 PM, »Q« boxc...@gmx.net wrote: It looks like maybe the best way to tell which ebuilds support which kernels is to read the conditional for the ewarn message in each ebuild. If this sort of problem spreads it might be good to build into portage some kind of blocker/keyword mechanism so that users need not deal with this not that I have any appreciation for the work involved. Those tools already exist. Blockers, which do not really apply here; In a comment on the bug (which is full of bugspam), someone suggested blocking kernels which are incompatible with the currently-installed nvidia-drivers. I'm glad that idea was dismissed. elog messages Those elog messages are presented after compiling a new kernel and then trying and failing to compile nvidia-drivers. So now I grep the nvidia-drivers ebuilds for the messages before I compile a new kernel. A wiki page with info about which nvidia-drivers will build against which kernels would be a nice thing to have. Your reply demonstrates nicely the true nature of the problem: With nvidia-drivers, sometimes things break and there's nothing sane that portage and the devs can do to help you. You can't check the configured kernels as they may not be running. You can't check the installed sources as they may not be in use. You can't even try identify the sources symlinked by /usr/src/linux as they may have been patched, tweaked or modified and nvidia-drivers may well build whereas against stock sources they don't. The entire problem is completely due to how nVidia chose to do things, it's their business decision. Now, if they were to get their shim code into mainline, most of this nonsense would not happen anymore. The only thing left for Portage and the devs to do is to provide the ebuild and ask you to run it. If it doesn't compile, then don't run that kernel. I doubt your wiki page idea will work, it will be just accurate enough to look like it might work and just inaccurate enough to be useless. Which brings you back to the previous paragraph - try emerge nvidia-drivers and if it fails then don't use that kernel. I was unclear to the point of being misleading. I'm sorry. The wiki idea is only for a page which tells which kernel/nvidia-drivers combinations the Gentoo nvidia-drivers maintainers support. And by support, I mean they'll look into bugs and fix build problems if they're able to. This is exactly the info I'm grepping out of ewarn messages in their ebuilds now.
Re: [gentoo-user] Who sets the symlink /dev/rtc = /dev/rtc0 ?
Alan McKinnon alan.mckin...@gmail.com [13-08-26 04:34]: On 25/08/2013 20:26, meino.cra...@gmx.de wrote: Hi, In the kernel config I set CONFIG_RTC_HCTOSYS_DEVICE=rtc1 and I grepped through /etc and looked for something suspicious...nothing found. So...which ghost in my system dares to set the symlink /dev/rtc to point to /dev/rtc0 instead of /dev/rtc1 ??? You say there's a ghost in the machine, and the instant answer udev did not immediately jump into your mind? tut, tut (such an obvious target) :-) grep through every file installed by udev for rtc, let's see what comes out -- Alan McKinnon alan.mckin...@gmail.com Hi Alan, carefully read my posting again ;) Best regards, mcc
Re: [gentoo-user] Who sets the symlink /dev/rtc = /dev/rtc0 ?
Philip Webb purs...@ca.inter.net [13-08-26 04:35]: 130825 Pavel Volkov suggested: On Sunday 25 August 2013 20:26:32 meino.cra...@gmx.de asked: So...which ghost in my system dares to set the symlink /dev/rtc to point to /dev/rtc0 instead of /dev/rtc1 ??? I bet it's /usr/lib64/udev/rules.d/50-udev-default.rules I have /usr/udev/rules.d/50-udev-default.rules (on a 64-bit system), which contains the lines : # select system RTC or just use the first one SUBSYSTEM==rtc, ATTR{hctosys}==1, SYMLINK+=rtc SUBSYSTEM==rtc, KERNEL==rtc0, SYMLINK+=rtc, OPTIONS+=link_priority=-100 However, in /dev I have : crw--- 1 root root 10, 135 Aug 25 07:39 /dev/rtc ie it's not a symlink. I'm using udev-204 . HTH -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca Hi, I finally found the culprit: There udev-related files under /lib, where I did not search for it. I had expected them under /etc... I fixed one of the rules and now there is the correct link. Nonetheless, ls -l /proc shows: beagleboneblack:/rootls -l /proc total 0 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 1 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 10 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 11 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 12 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 13 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 14 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 15 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 16 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 17 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 18 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 188 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 19 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 196 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 2 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 20 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 21 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 24 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 27 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 3 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 36 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 362 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 363 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 364 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 365 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 38 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 39 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 40 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 41 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 42 dr-xr-xr-x 8 messagebus messagebus 0 2013-08-26 05:12 436 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 45 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 46 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 5 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 53 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 55 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 56 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 612 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 632 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 69 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 698 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 7 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 70 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 71 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 74 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 75 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 76 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 79 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 8 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 80 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 800 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 855 dr-xr-xr-x 8 root root 0 2013-08-26 05:13 882 dr-xr-xr-x 8 root root 0 2013-08-26 05:13 883 dr-xr-xr-x 8 root root 0 2013-08-26 05:13 884 dr-xr-xr-x 8 root root 0 2013-08-26 05:13 885 dr-xr-xr-x 8 root root 0 2013-08-26 05:13 886 dr-xr-xr-x 8 root root 0 2013-08-26 05:13 887 dr-xr-xr-x 8 root root 0 2013-08-26 05:13 896 dr-xr-xr-x 8 root root 0
Re: [gentoo-user] having problems building webkit-gtk
Alan McKinnon alan.mckin...@gmail.com wrote: On 25/08/2013 19:22, cov...@ccs.covici.com wrote: I have been having problems building webkit-gtk right along through the various versions, but this one stumps me completely -- I get the error: libtool: link: x86_64-pc-linux-gnu-gcc -o /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/tmp-introspectCZNJhf/.libs/WebKit-3.0 -O2 -mtune=core\2 -pipe -std=c99 -Wl,-O1 -Wl,--no-keep-memory /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/tmp-introspectCZNJhf/WebKit-3.0.o -Wl,--export-dy\namic -pthread -Wl,--export-dynamic -Wl,--as-needed -L. /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/.libs/libwebkitgtk-3.0.so -L/usr/lib64\ -lenchant -lharfbuzz-icu -lharfbuzz -lgailutil-3 -lgeoclue -ldbus-glib-1 -ldbus-1 -lgstapp-1.0 -lgstaudio-1.0 -lgstfft-1.0 -lgstpbutils-1.0 -lgstvideo-1.0 -lg\stbase-1.0 -lgstreamer-1.0 -ljpeg -lsecret-1 -lxslt -lxml2 -lGL -ldl -lpangoft2-1.0 -lfreetype -lfontconfig -lpng16 -lsqlite3 -lwebp -lXcomposite -lXdamage -lX\fixes -lXrender -lXt -lX11 -lz /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/.libs/libjavascriptcoregtk-3.0.so -lpthread -licui18n -licuuc -l\icudata -lgthread-2.0 -lrt -lgmodule-2.0 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lsoup-2.4 -lgio-2.0 -\lgobject-2.0 -lglib-2.0 -pthread^M PT PaX marking -m ./tmp-introspectCZNJhf/.libs/WebKit-3.0^M ^M (process:24006): GLib-GObject-CRITICAL **: g_object_class_install_property: assertion `class-set_property != NULL' failed I have search through google and bgo and found nothing -- how can I fix this one? Did you try building with -j1? I did find this one bgo, dunno if you found it in your searches (seems relevant at first glance): http://forums.gentoo.org/viewtopic-p-7369078.html https://bugs.webkit.org/show_bug.cgi?id=119261 https://bugs.gentoo.org/show_bug.cgi?id=463960 The first URL links to the other two. OK, thanks I will look at those -- I always use -j1 maybe slower, but I think its better. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Who sets the symlink /dev/rtc = /dev/rtc0 ?
On 26/08/13 11:30, meino.cra...@gmx.de wrote: Philip Webb purs...@ca.inter.net [13-08-26 04:35]: 130825 Pavel Volkov suggested: On Sunday 25 August 2013 20:26:32 meino.cra...@gmx.de asked: So...which ghost in my system dares to set the symlink /dev/rtc to point to /dev/rtc0 instead of /dev/rtc1 ??? I bet it's /usr/lib64/udev/rules.d/50-udev-default.rules I have /usr/udev/rules.d/50-udev-default.rules (on a 64-bit system), which contains the lines : # select system RTC or just use the first one SUBSYSTEM==rtc, ATTR{hctosys}==1, SYMLINK+=rtc SUBSYSTEM==rtc, KERNEL==rtc0, SYMLINK+=rtc, OPTIONS+=link_priority=-100 However, in /dev I have : crw--- 1 root root 10, 135 Aug 25 07:39 /dev/rtc ie it's not a symlink. I'm using udev-204 . HTH -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca Hi, I finally found the culprit: There udev-related files under /lib, where I did not search for it. I had expected them under /etc... I fixed one of the rules and now there is the correct link. Nonetheless, ls -l /proc shows: beagleboneblack:/rootls -l /proc total 0 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 1 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 10 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 11 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 12 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 13 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 14 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 15 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 16 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 17 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 18 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 188 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 19 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 196 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 2 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 20 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 21 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 24 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 27 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 3 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 36 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 362 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 363 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 364 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 365 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 38 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 39 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 40 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 41 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 42 dr-xr-xr-x 8 messagebus messagebus 0 2013-08-26 05:12 436 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 45 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 46 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 5 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 53 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 55 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 56 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 612 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 632 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 69 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 698 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 7 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 70 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 71 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 74 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 75 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 76 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 79 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 8 dr-xr-xr-x 8 root root 0 1970-01-01 01:00 80 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 800 dr-xr-xr-x 8 root root 0 2013-08-26 05:12 855 dr-xr-xr-x 8 root root 0 2013-08-26 05:13 882 dr-xr-xr-x 8 root root 0 2013-08-26 05:13 883 dr-xr-xr-x 8 root root 0 2013-08-26 05:13 884 dr-xr-xr-x 8 root root 0 2013-08-26 05:13 885 dr-xr-xr-x 8 root root 0 2013-08-26 05:13 886 dr-xr-xr-x 8 root root 0 2013-08-26 05:13 887
Re: [gentoo-user] having problems building webkit-gtk
Alan McKinnon alan.mckin...@gmail.com wrote: On 25/08/2013 19:22, cov...@ccs.covici.com wrote: I have been having problems building webkit-gtk right along through the various versions, but this one stumps me completely -- I get the error: libtool: link: x86_64-pc-linux-gnu-gcc -o /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/tmp-introspectCZNJhf/.libs/WebKit-3.0 -O2 -mtune=core\2 -pipe -std=c99 -Wl,-O1 -Wl,--no-keep-memory /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/tmp-introspectCZNJhf/WebKit-3.0.o -Wl,--export-dy\namic -pthread -Wl,--export-dynamic -Wl,--as-needed -L. /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/.libs/libwebkitgtk-3.0.so -L/usr/lib64\ -lenchant -lharfbuzz-icu -lharfbuzz -lgailutil-3 -lgeoclue -ldbus-glib-1 -ldbus-1 -lgstapp-1.0 -lgstaudio-1.0 -lgstfft-1.0 -lgstpbutils-1.0 -lgstvideo-1.0 -lg\stbase-1.0 -lgstreamer-1.0 -ljpeg -lsecret-1 -lxslt -lxml2 -lGL -ldl -lpangoft2-1.0 -lfreetype -lfontconfig -lpng16 -lsqlite3 -lwebp -lXcomposite -lXdamage -lX\fixes -lXrender -lXt -lX11 -lz /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/.libs/libjavascriptcoregtk-3.0.so -lpthread -licui18n -licuuc -l\icudata -lgthread-2.0 -lrt -lgmodule-2.0 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lsoup-2.4 -lgio-2.0 -\lgobject-2.0 -lglib-2.0 -pthread^M PT PaX marking -m ./tmp-introspectCZNJhf/.libs/WebKit-3.0^M ^M (process:24006): GLib-GObject-CRITICAL **: g_object_class_install_property: assertion `class-set_property != NULL' failed I have search through google and bgo and found nothing -- how can I fix this one? Did you try building with -j1? I did find this one bgo, dunno if you found it in your searches (seems relevant at first glance): http://forums.gentoo.org/viewtopic-p-7369078.html https://bugs.webkit.org/show_bug.cgi?id=119261 https://bugs.gentoo.org/show_bug.cgi?id=463960 The first URL links to the other two. Well, the post seems to think that setting opengl to xserver instead of nvidia should help -- but I am in a text console -- I might try it anyway, but how could that possibly help? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] having problems building webkit-gtk
On Sun, Aug 25, 2013 at 11:54 PM, cov...@ccs.covici.com wrote: Alan McKinnon alan.mckin...@gmail.com wrote: On 25/08/2013 19:22, cov...@ccs.covici.com wrote: I have been having problems building webkit-gtk right along through the various versions, but this one stumps me completely -- I get the error: libtool: link: x86_64-pc-linux-gnu-gcc -o /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/tmp-introspectCZNJhf/.libs/WebKit-3.0 -O2 -mtune=core\2 -pipe -std=c99 -Wl,-O1 -Wl,--no-keep-memory /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/tmp-introspectCZNJhf/WebKit-3.0.o -Wl,--export-dy\namic -pthread -Wl,--export-dynamic -Wl,--as-needed -L. /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/.libs/libwebkitgtk-3.0.so -L/usr/lib64\ -lenchant -lharfbuzz-icu -lharfbuzz -lgailutil-3 -lgeoclue -ldbus-glib-1 -ldbus-1 -lgstapp-1.0 -lgstaudio-1.0 -lgstfft-1.0 -lgstpbutils-1.0 -lgstvideo-1.0 -lg\stbase-1.0 -lgstreamer-1.0 -ljpeg -lsecret-1 -lxslt -lxml2 -lGL -ldl -lpangoft2-1.0 -lfreetype -lfontconfig -lpng16 -lsqlite3 -lwebp -lXcomposite -lXdamage -lX\fixes -lXrender -lXt -lX11 -lz /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/.libs/libjavascriptcoregtk-3.0.so -lpthread -licui18n -licuuc -l\icudata -lgthread-2.0 -lrt -lgmodule-2.0 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lsoup-2.4 -lgio-2.0 -\lgobject-2.0 -lglib-2.0 -pthread^M PT PaX marking -m ./tmp-introspectCZNJhf/.libs/WebKit-3.0^M ^M (process:24006): GLib-GObject-CRITICAL **: g_object_class_install_property: assertion `class-set_property != NULL' failed I have search through google and bgo and found nothing -- how can I fix this one? Did you try building with -j1? I did find this one bgo, dunno if you found it in your searches (seems relevant at first glance): http://forums.gentoo.org/viewtopic-p-7369078.html https://bugs.webkit.org/show_bug.cgi?id=119261 https://bugs.gentoo.org/show_bug.cgi?id=463960 The first URL links to the other two. Well, the post seems to think that setting opengl to xserver instead of nvidia should help -- but I am in a text console -- I might try it anyway, but how could that possibly help? The problem seems to be in the output of a command being too long (or so I remember from the two occasions I have encountered it). I don't understand it either. I remember that I had to use the -j1 trick, and also that I ssh'd to the machine, I started a screen session, and from there did the build (with X not running). It only has happened to me in my desktop machine (with an NVidia card). Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México