Re: [gentoo-user] OT: Copy directories in a special manner
On Sat, 5 Feb 2011 18:05:05 meino.cra...@gmx.de wrote: Hi, I want to do the following as fast as possible and with less system load as possible: There are two directories called 'source' and 'target'. 'source' gets updated via 'svn up', then it gets compiled. Since there is no make install or similiar, installation is done via copying 'source' to 'target'. A symlink from /usr/local/bin/name to the compiled executabe in (now) 'target' completes the installation. BUT: 'source' is a VERY big directory and copying it to 'target' after each svn up is a PAIN. Now I need a copy mechanism which does the following: * copy all files with newer date to 'target' -- this can be done via 'cp -u' * copy all files which only exist in 'source' to 'target' -- this can be done also with 'cp -u' * BUT: Delete all files from 'target' which do not longer exist in 'source' The last point gives me headaches. Scanning both directory after 'cp -u' has done its job may take as long as a blind copy from 'source' to 'target' after 'target' was initially removed. Is there any lean method to do what is described above ? Thank you very much for any help in advance! Best regards, mcc The tool you are looking for is 'rsync'. -- Reverend Paul Colquhoun, ULC.http://andor.dropbear.id.au/~paulcol Before you criticize someone, you should walk a mile in their shoes. Then, when you do, you'll be a mile away, and you'll have their shoes.
[gentoo-user] Re: Any way to get real text console without killing X capability?
On 02/04/2011 08:10 PM, Paul Hartman wrote: On Thu, Feb 3, 2011 at 6:37 PM, Nikos Chantziarasrea...@arcor.de wrote: [...] For the radeon driver at least, disabling KMS means that you won't get DRI2 in X11. That means slower performance and tearing. The non-KMS X driver is pretty much considered deprecated. Anecdote: On my laptop, which has a Radeon Mobility 9700 (uses RV350 or RV360), I got 30fps in Sauerbraten using the old non-KMS radeon driver, and only 15fps using the new KMS driver. Enabling gallium on latest mesa improves that to about 18fps, but causes my computer to crash after a few minutes... Sounds like a very outdated driver to me.
[gentoo-user] Re: OT: Copy directories in a special manner
On 02/05/2011 09:05 AM, meino.cra...@gmx.de wrote: There are two directories called 'source' and 'target'. 'source' gets updated via 'svn up', then it gets compiled. Since there is no make install or similiar, installation is done via copying 'source' to 'target'. A symlink from /usr/local/bin/name to the compiled executabe in (now) 'target' completes the installation. BUT: 'source' is a VERY big directory and copying it to 'target' after each svn up is a PAIN. Of course it's big, since it has all SVN data in it too. You will find that after you delete that data with something like: rm -rf $(find . -name *.svn) It will become much smaller.
Re: [gentoo-user] OT: Copy directories in a special manner
On Sat, 5 Feb 2011 08:05:05 +0100, meino.cra...@gmx.de wrote: Now I need a copy mechanism which does the following: * copy all files with newer date to 'target' -- this can be done via 'cp -u' * copy all files which only exist in 'source' to 'target' -- this can be done also with 'cp -u' * BUT: Delete all files from 'target' which do not longer exist in 'source' rsync -a --delete source/ dest/ -- Neil Bothwick Top Oxymorons Number 36: Alone together signature.asc Description: PGP signature
Re: [gentoo-user] Re: OT: Copy directories in a special manner
Am 05.02.2011 10:06, schrieb Nikos Chantziaras: On 02/05/2011 09:05 AM, meino.cra...@gmx.de wrote: There are two directories called 'source' and 'target'. 'source' gets updated via 'svn up', then it gets compiled. Since there is no make install or similiar, installation is done via copying 'source' to 'target'. A symlink from /usr/local/bin/name to the compiled executabe in (now) 'target' completes the installation. BUT: 'source' is a VERY big directory and copying it to 'target' after each svn up is a PAIN. Of course it's big, since it has all SVN data in it too. You will find that after you delete that data with something like: rm -rf $(find . -name *.svn) It will become much smaller. Easier (but untested!): rsync -a --delete --exclude .svn/ source/ target Excludes every directory called .svn from the transfer. Make sure to include the slash after .svn or otherwise it matches files called .svn Also take note that rsync changes its behavior depending on trailing slashes on the source directory. rsync -a source/ target copies all content from source to target. For example source/foo ends up as target/foo. rsync -a source target copies all content from source to target/source. For example source/foo ends up as target/source/foo Hope this helps, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] OT: Copy directories in a special manner
Paul Colquhoun paul...@andor.dropbear.id.au [11-02-05 10:08]: On Sat, 5 Feb 2011 18:05:05 meino.cra...@gmx.de wrote: Hi, I want to do the following as fast as possible and with less system load as possible: There are two directories called 'source' and 'target'. 'source' gets updated via 'svn up', then it gets compiled. Since there is no make install or similiar, installation is done via copying 'source' to 'target'. A symlink from /usr/local/bin/name to the compiled executabe in (now) 'target' completes the installation. BUT: 'source' is a VERY big directory and copying it to 'target' after each svn up is a PAIN. Now I need a copy mechanism which does the following: * copy all files with newer date to 'target' -- this can be done via 'cp -u' * copy all files which only exist in 'source' to 'target' -- this can be done also with 'cp -u' * BUT: Delete all files from 'target' which do not longer exist in 'source' The last point gives me headaches. Scanning both directory after 'cp -u' has done its job may take as long as a blind copy from 'source' to 'target' after 'target' was initially removed. Is there any lean method to do what is described above ? Thank you very much for any help in advance! Best regards, mcc The tool you are looking for is 'rsync'. -- Reverend Paul Colquhoun, ULC.http://andor.dropbear.id.au/~paulcol Before you criticize someone, you should walk a mile in their shoes. Then, when you do, you'll be a mile away, and you'll have their shoes. Hi all, thank you very much for the hints! Great! Saves me a lot of time. Have a nice weekend! Best regards mcc
Re: [gentoo-user] Xorg segfaults, but GDM welcome screen loads
Am 04.02.2011 23:26, schrieb Grant: Yesterday I caught up with portage and updated quite a few packages on a remote workstation. The system hadn't been updated for about a month. The updates included some xorg stuff and some xfce4 stuff. Today when the workstation's user logged in via gdm, she clicked the xfce4 Migrate Config option, something weird happened, and she ended up back on the gdm welcome screen. Now whenever she logs is via gdm, the screen immediately goes black and she is routed back to the gdm welcome screen again. When I have grsecurity enabled I get this in dmesg: Segmentation fault occurred at 68e453633fdc in /usr/bin/Xorg[X:4777] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/gdm-binary[gdm:4775] uid/euid:0/0 gid/egid:1010/1002 She also tried skipping gdm and issuing startxfce4 manually but it fails in a similar way and displays disconnected from session manager. I get this in Xorg.0.log: Backtrace: [74.799] 0: /usr/bin/X (xorg_backtrace+0x28) [0x49eeb8] [74.799] 1: /usr/bin/X (0x40+0x62849) [0x462849] [74.799] 2: /lib/libpthread.so.0 (0x64727eac2000+0xf3f0) [0x64727ead13f0] [74.800] 3: /usr/lib64/xorg/modules/drivers/nv_drv.so (0x64727bed7000+0x112d0) [0x64727bee82d0] [74.800] 4: /usr/lib64/xorg/modules/libshadowfb.so (0x64727a682000+0x3db2) [0x64727a685db2] [74.800] 5: /usr/bin/X (0x40+0x2da29) [0x42da29] [74.800] 6: /usr/bin/X (0x40+0x2eda9) [0x42eda9] [74.800] 7: /usr/bin/X (0x40+0x2475a) [0x42475a] [74.800] 8: /lib/libc.so.6 (__libc_start_main+0xe6) [0x64727dcb2ba6] [74.800] 9: /usr/bin/X (0x40+0x242f9) [0x4242f9] [74.800] Segmentation fault at address 0x64727462bfdc [74.800] Fatal server error: [74.800] Caught signal 11 (Segmentation fault). Server aborting and when grsecurity is enabled I get this in dmesg: Segmentation fault occurred at 64727462bfdc in /usr/bin/Xorg[X:4647] uid/euid:1003/0 gid/egid:1010/1010, parent /usr/bin/xinit[xinit:4646] uid/euid:1003/1003 gid/egid:1010/1010 I have tried disabling all security options in the kernel but I get the same results with the exception of the dmesg info. I tried re-emerging xorg-server, xf86-video-nv, xinit, and gdm. Strangely, after re-emerging xorg-server and xinit there were files to change in etc-update. I don't see how that's possible since I'm caught up with emerge -DuN world. revdep-rebuild comes up with nothing. I'm running an emerge -e world now. It's weird that the gdm welcome screen will load (which implies xorg) but nothing afterward. Any ideas? - Grant Please try to run `strace startx` and post the output as a file attachment. signature.asc Description: OpenPGP digital signature
Re: [OT] Re: [gentoo-user] Avoiding HAL
On Friday 04 February 2011 18:12:50 Paul Hartman wrote: On Fri, Feb 4, 2011 at 10:36 AM, Peter Humphrey pe...@humphrey.ukfsn.org wrote: At the risk of hijacking the thread, this reminds me of a problem on my workstation. It runs Gentoo fine (well, sluggishly) but when I installed Fedora 14 to try it, I found the mouse and keyboard freezing (but not the display) at random times that ranged from one minute to several hours. When that happened I tried to log in via SSH but got a no-route-to-host error. Then I remembered that the same thing had happened months earlier with Mandriva. Anyone here have an idea? I've tried switching off everything I can think of in the BIOS, but no joy. Temperatures are fine according to gkrellm. Perhaps try a newer kernel version, if you can. I think there was one in 2.6.35 era that did that kind of stuff... I'll look into that - thanks. Meanwhile, yesterday I even had a lockup while running from the live CD, so installing on this box is more a matter of luck than usual. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] The CHOST variable
On 21:21 Fri 04 Feb , Enrico Weigelt wrote: * Nils Holland n...@tisys.org wrote: 1) So a package using the GNU build system determines or is passed (via --host aka. CHOST) a target triplet specifying the system on which the resulting compiled code is supposed to run. What does the package do with that information? Does it only use it to determine what it has to compile (different / special code for different systems / architectures), or does this already have an influence on the optimization of the resulting code for a certain (sub-)architecture? Exactly. Some packages have arch- and subarch-specific optimizations. Those things IMHO should be primarily taken from the target triplet (instead of other ./configure options), as it quite exactly defines what cputype, platform and toolchain type you're using. It's very important for crosscompiling (even some toolchains, eg. gcc., could, and should, be explicitly asked for their target triplet). Hi Enrico, thanks very much for your in-depth explanation in this and also your other mail you've sent in response to my question. That was really helpful, as it cleared up some things I could previously only guess about but was by no means certain about. I've learnt something new (which was my highest priority here), and can even use this knowlede to deduce what makes sense in my current experiments with building my own stage3's and install boot discs via catalyst. So, thanks again for your insightful replies! Greetings, Nils -- Nils Holland * Ti Systems, Wunstorf-Luthe (Germany) Powered by GNU/Linux since 1998
Re: [gentoo-user] Microcode update AMD
* Volker Armin Hemmann volkerar...@googlemail.com wrote: the CPU. All CPUs use microcode. For decades. Google, or go straight to wikipedia. http://en.wikipedia.org/wiki/Microcode Borroughs' large systems (b6500+) were designed as microcode machines from ground up, which essentially interpreted an algol bytecode (the whole OS was directly implemented in assembler, w/o any machine specific assembler code). Paired w/ their entirely stack-based architecture (there were no program-visible registers) they could easily do massive-multiprocessing (everything's reentrant by design), 24/7 uptime even w/ hw replacements/upgrades and cpu improvements w/o ever having to recompile. Their successors (now Unisys) are called emode machines - quite the same approach as nowadays w/ Java (interpreter/JIT). BTW: I'm currently designing an emode/microcode-base computer architecture built on an matrix of nanocores, they don't have a concept of main memory, instead a relatively large (linear addressable) register memory, part of the register space is shared with neighbours (multiport-RAMs). These are programmed by an horizontal microcode, which is decoded by an static demux, that directly connects registers to an micro-ALU (so there're no additional load+store cycles) ... cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-user] Microcode update AMD
* Volker Armin Hemmann volkerar...@googlemail.com wrote: and that is all the intel stuff. For AMD all you have to do is: modprobe -r microcode modprobe microcode Is the microcode permanently flashed or loaded into some internal RAM ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-user] Setting up SMTP relay
I wrote:
In case someone else also wants to setup this, here's the final steps to
make relaying work.
Relaying does not work yet, I get a Relay access denied (in reply to
RCPT TO command) error. But my initial goal is reached, I can send mail
to {root,wonko}@wonkology.org. That's all I wanted.
Many many thanks kashani! Your howto is much more than I expected, it is
much appreciated. I realize that postfix is not too complicated, so I
will play more with it when I have some spare time.
Yesterday I had some. It took me a while to figure out what was wrong. I
read many howtos, but they all did not explain in detail how to
authenticate with another SMTP server, so postfix would act as a client.
It turned out that the error was simple: I had to change
smtp_sasl_tls_security_level = may
to
smtp_tls_security_level = may
. So, my relay config part of main.cf is this:
relayhost = [my.external.relay.host]
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/saslpass
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = may
smtp_tls_cert_file = /etc/ssl/postfix/weird.pem
And I had to create the (self-signed) certificate. It's done like this:
openssl req -x509 -nodes -days 3650 -newkey rsa:1024 -keyout
/etc/ssl/postfix/weird.pem
I was told I had to set my name to my hostname, not sure if this is true.
Done. My host now acts as SMPT server, accepting connections without
password from the LAN. Now I can enable mail sending for the other
Gentoo systems here in make.conf. And in ssmtp.conf, so things like cron
can send status mails to me.
Thanks again Kashani, without you help I would not have tried this.
Wonko
Re: [gentoo-user] Microcode update AMD
Enrico Weigelt weig...@metux.de [11-02-05 16:08]: * Volker Armin Hemmann volkerar...@googlemail.com wrote: and that is all the intel stuff. For AMD all you have to do is: modprobe -r microcode modprobe microcode Is the microcode permanently flashed or loaded into some internal RAM ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- You need a kernel module to load the microcode into the CPU (I dont know for sure what kind of memory holds it then) eacht time you boot the machine. Best regards mcc
Re: [gentoo-user] Re: Any way to get real text console without killing X capability?
On Thu, Feb 03, 2011 at 04:05:01PM -0800, walt wrote On 02/03/2011 02:11 PM, Nikos Chantziaras wrote: On 02/03/2011 08:07 AM, Walter Dnes wrote: Is there a way to have a real text console? I know that I can have 2 X sessions on tty10 and tty11 with different resolutions, and colour depths. Is there a way to set tty1..tty9 to 640x480 *IN TEXT MODE*, so that lat1-?? fonts would look normal, without killing the ability to have X run at 1920x1200? Note that the suggestion the others gave about disabling KMS is probably not what you need. Disabling KMS means that it will also be disabled for X11, not only for the framebuffer. As you can imagine this is a bad thing. I'm aware of KMS because of my experiments with the 'nouveau' driver, but I still have no idea what KMS really does. In other words, I *cannot* imagine why disabling KMS is a bad thing, but I would very much like to know :) Walt, Alan, Enrico, Nikos see the thread Not getting video hardware acceleration that I started on January 31. Without KMS, and the resulting DRI2 acceleration, my laptop could not run mplayer fast enough to keep up with an HDTV feed. With KMS, which is required by the bibary blob in the new Radeon driver, it works fine. The documentation at http://www.gentoo.org/doc/en/xorg-config.xml requires KMS for newer ATI Radeon cards. In make menuconfig, I do not have any drivers enabled under... Device Drivers --- Graphics support --- -*- Support for frame buffer devices --- but I still have /dev/fb0 show up. Under... Console display driver support --- the line... -*- Framebuffer Console support indicates that framebuffer console support is enabled, whether I like it or not. This is part and parcel of the ARI Radeon driver. Without it, no X. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Xorg segfaults, but GDM welcome screen loads
Yesterday I caught up with portage and updated quite a few packages on a remote workstation. The system hadn't been updated for about a month. The updates included some xorg stuff and some xfce4 stuff. Today when the workstation's user logged in via gdm, she clicked the xfce4 Migrate Config option, something weird happened, and she ended up back on the gdm welcome screen. Now whenever she logs is via gdm, the screen immediately goes black and she is routed back to the gdm welcome screen again. When I have grsecurity enabled I get this in dmesg: Segmentation fault occurred at 68e453633fdc in /usr/bin/Xorg[X:4777] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/gdm-binary[gdm:4775] uid/euid:0/0 gid/egid:1010/1002 She also tried skipping gdm and issuing startxfce4 manually but it fails in a similar way and displays disconnected from session manager. I get this in Xorg.0.log: Backtrace: [ 74.799] 0: /usr/bin/X (xorg_backtrace+0x28) [0x49eeb8] [ 74.799] 1: /usr/bin/X (0x40+0x62849) [0x462849] [ 74.799] 2: /lib/libpthread.so.0 (0x64727eac2000+0xf3f0) [0x64727ead13f0] [ 74.800] 3: /usr/lib64/xorg/modules/drivers/nv_drv.so (0x64727bed7000+0x112d0) [0x64727bee82d0] [ 74.800] 4: /usr/lib64/xorg/modules/libshadowfb.so (0x64727a682000+0x3db2) [0x64727a685db2] [ 74.800] 5: /usr/bin/X (0x40+0x2da29) [0x42da29] [ 74.800] 6: /usr/bin/X (0x40+0x2eda9) [0x42eda9] [ 74.800] 7: /usr/bin/X (0x40+0x2475a) [0x42475a] [ 74.800] 8: /lib/libc.so.6 (__libc_start_main+0xe6) [0x64727dcb2ba6] [ 74.800] 9: /usr/bin/X (0x40+0x242f9) [0x4242f9] [ 74.800] Segmentation fault at address 0x64727462bfdc [ 74.800] Fatal server error: [ 74.800] Caught signal 11 (Segmentation fault). Server aborting and when grsecurity is enabled I get this in dmesg: Segmentation fault occurred at 64727462bfdc in /usr/bin/Xorg[X:4647] uid/euid:1003/0 gid/egid:1010/1010, parent /usr/bin/xinit[xinit:4646] uid/euid:1003/1003 gid/egid:1010/1010 I have tried disabling all security options in the kernel but I get the same results with the exception of the dmesg info. I tried re-emerging xorg-server, xf86-video-nv, xinit, and gdm. Strangely, after re-emerging xorg-server and xinit there were files to change in etc-update. I don't see how that's possible since I'm caught up with emerge -DuN world. revdep-rebuild comes up with nothing. I'm running an emerge -e world now. It's weird that the gdm welcome screen will load (which implies xorg) but nothing afterward. Any ideas? - Grant Please try to run `strace startx` and post the output as a file attachment. Gladly. Is there anything else I should try? The workstation is remote and its user only has access infrequently. Is there anything else I should have her try while she's there? - Grant
Re: [gentoo-user] Xorg segfaults, but GDM welcome screen loads
Yesterday I caught up with portage and updated quite a few packages on a remote workstation. The system hadn't been updated for about a month. The updates included some xorg stuff and some xfce4 stuff. Today when the workstation's user logged in via gdm, she clicked the xfce4 Migrate Config option, something weird happened, and she ended up back on the gdm welcome screen. Now whenever she logs is via gdm, the screen immediately goes black and she is routed back to the gdm welcome screen again. When I have grsecurity enabled I get this in dmesg: Segmentation fault occurred at 68e453633fdc in /usr/bin/Xorg[X:4777] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/gdm-binary[gdm:4775] uid/euid:0/0 gid/egid:1010/1002 She also tried skipping gdm and issuing startxfce4 manually but it fails in a similar way and displays disconnected from session manager. I get this in Xorg.0.log: Backtrace: [ 74.799] 0: /usr/bin/X (xorg_backtrace+0x28) [0x49eeb8] [ 74.799] 1: /usr/bin/X (0x40+0x62849) [0x462849] [ 74.799] 2: /lib/libpthread.so.0 (0x64727eac2000+0xf3f0) [0x64727ead13f0] [ 74.800] 3: /usr/lib64/xorg/modules/drivers/nv_drv.so (0x64727bed7000+0x112d0) [0x64727bee82d0] [ 74.800] 4: /usr/lib64/xorg/modules/libshadowfb.so (0x64727a682000+0x3db2) [0x64727a685db2] [ 74.800] 5: /usr/bin/X (0x40+0x2da29) [0x42da29] [ 74.800] 6: /usr/bin/X (0x40+0x2eda9) [0x42eda9] [ 74.800] 7: /usr/bin/X (0x40+0x2475a) [0x42475a] [ 74.800] 8: /lib/libc.so.6 (__libc_start_main+0xe6) [0x64727dcb2ba6] [ 74.800] 9: /usr/bin/X (0x40+0x242f9) [0x4242f9] [ 74.800] Segmentation fault at address 0x64727462bfdc [ 74.800] Fatal server error: [ 74.800] Caught signal 11 (Segmentation fault). Server aborting and when grsecurity is enabled I get this in dmesg: Segmentation fault occurred at 64727462bfdc in /usr/bin/Xorg[X:4647] uid/euid:1003/0 gid/egid:1010/1010, parent /usr/bin/xinit[xinit:4646] uid/euid:1003/1003 gid/egid:1010/1010 I have tried disabling all security options in the kernel but I get the same results with the exception of the dmesg info. I tried re-emerging xorg-server, xf86-video-nv, xinit, and gdm. Strangely, after re-emerging xorg-server and xinit there were files to change in etc-update. I don't see how that's possible since I'm caught up with emerge -DuN world. revdep-rebuild comes up with nothing. I'm running an emerge -e world now. It's weird that the gdm welcome screen will load (which implies xorg) but nothing afterward. Any ideas? - Grant Please try to run `strace startx` and post the output as a file attachment. Another question, is there anything I need to prepare to make sure the strace works? - Grant
Re: [gentoo-user] Microcode update AMD
On Saturday 05 February 2011 15:28:22 Enrico Weigelt wrote: * Volker Armin Hemmann volkerar...@googlemail.com wrote: and that is all the intel stuff. For AMD all you have to do is: modprobe -r microcode modprobe microcode Is the microcode permanently flashed or loaded into some internal RAM ? loaded. microcode is never permanently changed on x86 derivates.
Re: [gentoo-user] Any way to get real text console without killing X capability?
On Thu, Feb 03, 2011 at 09:40:41PM +, Mick wrote Leave KMS enabled and add the parameter: video=1024x768 (or whatever suits your screen and taste) to your kernel line. You shouldn't need vesafb, uvesa or any other drivers to achieve this. Thanks very much. That works. I feel stupid. I always used VGA=6 to get the equivalant of video=640x480. When VGA=6 stopped working, it didn't occur to me to try video=640x480, because I assumed they were identical. Anyhow, I'm typing this in a text console. /etc/conf.d/consolefont is CONSOLEFONT=lat1-10 Combine that with 640x480 video, and that gives me an 80x48 textmode display. Because I'm using a 10-pixel-high font, the text is a lot nicer than VGA 80x50 that you may have seen on Windows. That mode uses an 8-pixel-high font on a 640x400 display for 50 rows. Doing an ll finds more lat1-?? fonts in /usr/share/consolefonts, which give the following possible text displays for video=640x480... lat1-08 == 80x60 lat1-10 == 80x48 lat1-12 == 80x40 lat1-14 == 80x34 lat1-16 == 80x30 As they say in the infomercials but wait, there's more. My monitor supports 1280x720 and 1280x1024 modes. Using screen I should be able to do splitscreen mode with 2 sessions side-by-each. Or vim in one screen with :vsplit splitting into two subscreens. Possibilities include two side-by-each sessions of... Font 1280x720 1280x1024 lat1-08 == 80x90 80x128 lat1-10 == 80x72 80x102 lat1-12 == 80x60 80x85 lat1-14 == 80x51 80x73 lat1-16 == 80x45 80x64 I feel like a kid with a shiney new toy. And when prices for 30 inch monitors come down, I could go nuts with *THREE* 80-column screens side-by-each in 1920x1200 or 1920x1080 video mode. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Microcode update AMD
Am 05.02.2011 14:34, schrieb Enrico Weigelt: BTW: I'm currently designing an emode/microcode-base computer architecture built on an matrix of nanocores, they don't have a concept of main memory, instead a relatively large (linear addressable) register memory, part of the register space is shared with neighbours (multiport-RAMs). These are programmed by an horizontal microcode, which is decoded by an static demux, that directly connects registers to an micro-ALU (so there're no additional load+store cycles) ... cu Interesting. Is there a paper on this? What's its intended purpose? Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Xorg segfaults, but GDM welcome screen loads
Am 05.02.2011 17:59, schrieb Grant: Yesterday I caught up with portage and updated quite a few packages on a remote workstation. The system hadn't been updated for about a month. The updates included some xorg stuff and some xfce4 stuff. Today when the workstation's user logged in via gdm, she clicked the xfce4 Migrate Config option, something weird happened, and she ended up back on the gdm welcome screen. Now whenever she logs is via gdm, the screen immediately goes black and she is routed back to the gdm welcome screen again. When I have grsecurity enabled I get this in dmesg: Segmentation fault occurred at 68e453633fdc in /usr/bin/Xorg[X:4777] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/gdm-binary[gdm:4775] uid/euid:0/0 gid/egid:1010/1002 She also tried skipping gdm and issuing startxfce4 manually but it fails in a similar way and displays disconnected from session manager. I get this in Xorg.0.log: [...] Segmentation fault occurred at 64727462bfdc in /usr/bin/Xorg[X:4647] uid/euid:1003/0 gid/egid:1010/1010, parent /usr/bin/xinit[xinit:4646] uid/euid:1003/1003 gid/egid:1010/1010 I have tried disabling all security options in the kernel but I get the same results with the exception of the dmesg info. I tried re-emerging xorg-server, xf86-video-nv, xinit, and gdm. Strangely, after re-emerging xorg-server and xinit there were files to change in etc-update. I don't see how that's possible since I'm caught up with emerge -DuN world. revdep-rebuild comes up with nothing. I'm running an emerge -e world now. It's weird that the gdm welcome screen will load (which implies xorg) but nothing afterward. Any ideas? - Grant Please try to run `strace startx` and post the output as a file attachment. Another question, is there anything I need to prepare to make sure the strace works? - Grant Um, emerge it? By the way: I recently had a similar freak problem with X11 on a KDE machine. It turned out the system tried to start the default session with twm and xterm (default when no window environment is installed) and crashed because xterm was no longer present. I don't think this is your problem but maybe it gets you closer to a solution if you try to get such a light-weight solution running instead of the full-blown xfce. Did you also try to remove your xorg.conf, if you have any? Hope this helps, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Any way to get real text console without killing X capability?
On Saturday 05 February 2011 15:27:27 Walter Dnes wrote: On Thu, Feb 03, 2011 at 04:05:01PM -0800, walt wrote On 02/03/2011 02:11 PM, Nikos Chantziaras wrote: On 02/03/2011 08:07 AM, Walter Dnes wrote: Is there a way to have a real text console? I know that I can have 2 X sessions on tty10 and tty11 with different resolutions, and colour depths. Is there a way to set tty1..tty9 to 640x480 *IN TEXT MODE*, so that lat1-?? fonts would look normal, without killing the ability to have X run at 1920x1200? Note that the suggestion the others gave about disabling KMS is probably not what you need. Disabling KMS means that it will also be disabled for X11, not only for the framebuffer. As you can imagine this is a bad thing. I'm aware of KMS because of my experiments with the 'nouveau' driver, but I still have no idea what KMS really does. In other words, I *cannot* imagine why disabling KMS is a bad thing, but I would very much like to know :) Walt, Alan, Enrico, Nikos see the thread Not getting video hardware acceleration that I started on January 31. Without KMS, and the resulting DRI2 acceleration, my laptop could not run mplayer fast enough to keep up with an HDTV feed. With KMS, which is required by the bibary blob in the new Radeon driver, it works fine. The documentation at http://www.gentoo.org/doc/en/xorg-config.xml requires KMS for newer ATI Radeon cards. In make menuconfig, I do not have any drivers enabled under... Device Drivers --- Graphics support --- -*- Support for frame buffer devices --- but I still have /dev/fb0 show up. Under... Console display driver support --- the line... -*- Framebuffer Console support indicates that framebuffer console support is enabled, whether I like it or not. This is part and parcel of the ARI Radeon driver. Without it, no X. Right, but a framebuffer (KMS driven or vesa, et al.) is not a bad thing. Just try video=1024x768 (or whatever your desired resolution is) on the kernel line and it should just work. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Any way to get real text console without killing X capability?
On Saturday 05 February 2011 18:00:10 Mick wrote: On Saturday 05 February 2011 15:27:27 Walter Dnes wrote: In make menuconfig, I do not have any drivers enabled under... Device Drivers --- Graphics support --- -*- Support for frame buffer devices --- but I still have /dev/fb0 show up. Under... Console display driver support --- the line... -*- Framebuffer Console support indicates that framebuffer console support is enabled, whether I like it or not. This is part and parcel of the ARI Radeon driver. Without it, no X. Right, but a framebuffer (KMS driven or vesa, et al.) is not a bad thing. Just try video=1024x768 (or whatever your desired resolution is) on the kernel line and it should just work. Oops! Walter please ignore this message ... I just saw that you have solved it on your later reply. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Any way to get real text console without killing X capability?
On Saturday 05 February 2011 17:10:15 Walter Dnes wrote: On Thu, Feb 03, 2011 at 09:40:41PM +, Mick wrote Leave KMS enabled and add the parameter: video=1024x768 (or whatever suits your screen and taste) to your kernel line. You shouldn't need vesafb, uvesa or any other drivers to achieve this. Thanks very much. That works. I feel stupid. I always used VGA=6 to get the equivalant of video=640x480. When VGA=6 stopped working, it didn't occur to me to try video=640x480, because I assumed they were identical. Anyhow, I'm typing this in a text console. /etc/conf.d/consolefont is CONSOLEFONT=lat1-10 Combine that with 640x480 video, and that gives me an 80x48 textmode display. Because I'm using a 10-pixel-high font, the text is a lot nicer than VGA 80x50 that you may have seen on Windows. That mode uses an 8-pixel-high font on a 640x400 display for 50 rows. Doing an ll finds more lat1-?? fonts in /usr/share/consolefonts, which give the following possible text displays for video=640x480... lat1-08 == 80x60 lat1-10 == 80x48 lat1-12 == 80x40 lat1-14 == 80x34 lat1-16 == 80x30 As they say in the infomercials but wait, there's more. My monitor supports 1280x720 and 1280x1024 modes. Using screen I should be able to do splitscreen mode with 2 sessions side-by-each. Or vim in one screen with :vsplit splitting into two subscreens. Possibilities include two side-by-each sessions of... Font 1280x720 1280x1024 lat1-08 == 80x90 80x128 lat1-10 == 80x72 80x102 lat1-12 == 80x60 80x85 lat1-14 == 80x51 80x73 lat1-16 == 80x45 80x64 I feel like a kid with a shiney new toy. And when prices for 30 inch monitors come down, I could go nuts with *THREE* 80-column screens side-by-each in 1920x1200 or 1920x1080 video mode. Glad you cracked this one. :-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Portage is misplaced in /usr
There are several reasons why portage, neither the tree nor (especially not) the distfiles should reside in /usr. /var is expected to be heavily written and read from, as it is the case with the portage tree. It's possibly subject to fragmentation and small file sizes and heavy changes, which is usually accounted for my choosing an appropriate filesystem and configuring it accordingly. /usr is expected to be a static directory with mostly read access and few to no changes on a running system. This issue seems to have been ignored for a long time. When I asked about it, I met two types of responses: a) Those who thought about it and agreed, that portage should be moved b) Those who replied deal with it If you can think of good counter arguement which *logically* supports that portage should by default reside in /usr (including the distfiles and everything else variable) please tell us. If not, please refrain from logically irrelevant statements such as the above, you can always do insert some random workarround here or similar ones. If you have further arguments to support my point, I'd also welcome them to the discussion, I expect 90% or more of the real arguments to support my point. I've also heard rumours that such an outcome has already been there in the past, yet, gentoo developers ignored it and kept portage in /usr for unknown and most likely unlogical reasons. I believe these rumours. If again, the logical conclusion will be that portage should be moved but it is not acted upon but logic is ignored, please ask yourself what kind of distribution we are. It is a community built around a distribution which is driven by more than 300 developers and thousands of users. regards, MD
Re: [gentoo-user] Portage is misplaced in /usr
On Saturday 05 February 2011 19:43:11, Cedric Sodhi wrote: There are several reasons why portage, neither the tree nor (especially not) the distfiles should reside in /usr. /var is expected to be heavily written and read from, as it is the case with the portage tree. It's possibly subject to fragmentation and small file sizes and heavy changes, which is usually accounted for my choosing an appropriate filesystem and configuring it accordingly. /usr is expected to be a static directory with mostly read access and few to no changes on a running system. This issue seems to have been ignored for a long time. When I asked about it, I met two types of responses: a) Those who thought about it and agreed, that portage should be moved b) Those who replied deal with it If you can think of good counter arguement which *logically* supports that portage should by default reside in /usr (including the distfiles and everything else variable) please tell us. If not, please refrain from logically irrelevant statements such as the above, you can always do insert some random workarround here or similar ones. If you have further arguments to support my point, I'd also welcome them to the discussion, I expect 90% or more of the real arguments to support my point. I've also heard rumours that such an outcome has already been there in the past, yet, gentoo developers ignored it and kept portage in /usr for unknown and most likely unlogical reasons. I believe these rumours. If again, the logical conclusion will be that portage should be moved but it is not acted upon but logic is ignored, please ask yourself what kind of distribution we are. It is a community built around a distribution which is driven by more than 300 developers and thousands of users. regards, MD Portage DEFAULTS to /usr/portage as the location for the tree etc. While that may be wrong, you can always change the PORTDIR variable in make.conf ( same with DISTDIR and PKGDIR ). Since it's something you can change in the very beginning of the installation, I wouldn't count that as a workaround ( as symlinking, (re)mounting etc. would be ). I don't see where the problem is ? There is nothing wrong with portage itself in that matter. One could propose to change the default PORTDIR in make.globals and in the docs though. Sincerely Meik Frischke
Re: [gentoo-user] Portage is misplaced in /usr
Cedric Sodhi writes: There are several reasons why portage, neither the tree nor (especially not) the distfiles should reside in /usr. /var is expected to be heavily written and read from, as it is the case with the portage tree. That's why I have /var/portage, with subdirectories tree, distfiles, local, layman, packges and (for my 32bit chroot) packages.32. That's how I think it should be, so I change it that way. Recently I also began moving /var/tmp/portage there, so my /var partition could no longer become full because of emerging openoffice. If again, the logical conclusion will be that portage should be moved but it is not acted upon but logic is ignored, please ask yourself what kind of distribution we are. It is a community built around a distribution which is driven by more than 300 developers and thousands of users. Well, I agree with your point, and I find it strange that this has not been changed, but - I don't care too much about it. I make a few quick changes when I install a Gentoo, and that's it. Wonko
[gentoo-user] Re: Any way to get real text console without killing X capability?
On 02/05/2011 08:00 PM, Mick wrote: Right, but a framebuffer (KMS driven or vesa, et al.) is not a bad thing. Just try video=1024x768 (or whatever your desired resolution is) on the kernel line and it should just work. Unfortunately, it doesn't.
Re: [gentoo-user] Portage is misplaced in /usr
On Sat, Feb 5, 2011 at 10:43 AM, Cedric Sodhi man...@gmx.net wrote: There are several reasons why portage, neither the tree nor (especially not) the distfiles should reside in /usr. SNIP I have no opinion on the subject really, but can't you build a link from /usr/portage to anywhere you want to put it? I put /usr/portage/distfiles on a separate partition as I hate running out of disk space on my root partition when I've not cleaned up distfiles. The only reason I could give for not changing is I don't want to teach my fingers /var/portage vs what they already know. That's a pretty weak reason. - Mark
[gentoo-user] Re: Portage is misplaced in /usr
On 02/05/2011 08:43 PM, Cedric Sodhi wrote: There are several reasons why portage, neither the tree nor (especially not) the distfiles should reside in /usr. [...] If you can think of good counter arguement which *logically* supports that portage should by default reside in /usr (including the distfiles and everything else variable) please tell us. If not, please refrain from logically irrelevant statements such as the above, you can always doinsert some random workarround here or similar ones. How is utilizing the fully supported configuration options of portage a random workaround? It's neither random, *nor* a workaround.
Re: [gentoo-user] Portage is misplaced in /usr
where do the bsds put their ports? also: just set the PORTDIR variable wherever you want it to point. There is no reason to annoy the rest of humanity with a mailing list point complaining about a perceived problem that is none.
Re: [gentoo-user] Portage is misplaced in /usr
Apparently, though unproven, at 20:43 on Saturday 05 February 2011, Cedric Sodhi did opine thusly: There are several reasons why portage, neither the tree nor (especially not) the distfiles should reside in /usr. I've been saying this for years. I always change PORTDIR everywhere to /var/portage /var is expected to be heavily written and read from, as it is the case with the portage tree. It's possibly subject to fragmentation and small file sizes and heavy changes, which is usually accounted for my choosing an appropriate filesystem and configuring it accordingly. 100% correct. The tree is a database. No-one in their right mind would put MySQL data dirs in /usr Juts like no-one would put the portage build dir in /usr either /usr is expected to be a static directory with mostly read access and few to no changes on a running system. This issue seems to have been ignored for a long time. When I asked about it, I met two types of responses: a) Those who thought about it and agreed, that portage should be moved b) Those who replied deal with it If you can think of good counter arguement which *logically* supports that portage should by default reside in /usr (including the distfiles and everything else variable) please tell us. Here's the real reason: FreeBSD puts ports in /usr. So Daniel put portage in /usr when he ported ports to portage Everyone else since has left it there. Sometimes the obvious reason really is the right one. If not, please refrain from logically irrelevant statements such as the above, you can always do insert some random workarround here or similar ones. If you have further arguments to support my point, I'd also welcome them to the discussion, I expect 90% or more of the real arguments to support my point. I've also heard rumours that such an outcome has already been there in the past, yet, gentoo developers ignored it and kept portage in /usr for unknown and most likely unlogical reasons. I believe these rumours. If again, the logical conclusion will be that portage should be moved but it is not acted upon but logic is ignored, please ask yourself what kind of distribution we are. It is a community built around a distribution which is driven by more than 300 developers and thousands of users. It's trivially easy to change, so there's no good reason not to. Reset PORTDIR, edit layman's configs, create new directories. In the vast majority of cases that's all that's required. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Xorg segfaults, but GDM welcome screen loads
Apparently, though unproven, at 02:54 on Saturday 05 February 2011, Grant did opine thusly: Yesterday I caught up with portage and updated quite a few packages on a remote workstation. The system hadn't been updated for about a month. The updates included some xorg stuff and some xfce4 stuff. Today when the workstation's user logged in via gdm, she clicked the xfce4 Migrate Config option, something weird happened, and she ended up back on the gdm welcome screen. Now whenever she logs is via gdm, the screen immediately goes black and she is routed back to the gdm welcome screen again. When I have grsecurity enabled I get this in dmesg: Segmentation fault occurred at 68e453633fdc in /usr/bin/Xorg[X:4777] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/gdm-binary[gdm:4775] uid/euid:0/0 gid/egid:1010/1002 When you upgraded x.org, did you also rebuild it's drivers? I rebuilt nv but not evdev. Could that be responsible for this? I'm not sure how since the gdm welcome screen comes up and the keyboard works fine there for username/password input. I only mention it because in my experience I always have weird shit happening when I upgrade xorg-server over a big version number change. And rebuilding everything that underpins xorg always fixes it. Including drivers and mesa. In the old days when xorg was monolithic this never happened, as all the drivers always got rebuilt anyway. Nowadays with xorg sources being modular, we have to be a little more alert. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Portage is misplaced in /usr
Cedric Sodhi wrote: There are several reasons why portage, neither the tree nor (especially not) the distfiles should reside in /usr. /var is expected to be heavily written and read from, as it is the case with the portage tree. It's possibly subject to fragmentation and small file sizes and heavy changes, which is usually accounted for my choosing an appropriate filesystem and configuring it accordingly. /usr is expected to be a static directory with mostly read access and few to no changes on a running system. This issue seems to have been ignored for a long time. When I asked about it, I met two types of responses: a) Those who thought about it and agreed, that portage should be moved b) Those who replied deal with it If you can think of good counter arguement which *logically* supports that portage should by default reside in /usr (including the distfiles and everything else variable) please tell us. If not, please refrain from logically irrelevant statements such as the above, you can always doinsert some random workarround here or similar ones. If you have further arguments to support my point, I'd also welcome them to the discussion, I expect 90% or more of the real arguments to support my point. I've also heard rumours that such an outcome has already been there in the past, yet, gentoo developers ignored it and kept portage in /usr for unknown and most likely unlogical reasons. I believe these rumours. If again, the logical conclusion will be that portage should be moved but it is not acted upon but logic is ignored, please ask yourself what kind of distribution we are. It is a community built around a distribution which is driven by more than 300 developers and thousands of users. regards, MD Moving the tree out of /usr has been discussed by the devs several times. Each time, they have decided not to move it. I doubt that is going to change anytime soon. On another note, you can edit make.conf and put it anywhere you want. It being in /usr is not etched in stone or anything. This is from my make.conf: # PORTDIR is the location of the portage tree. This is the repository # for all profile information as well as all ebuilds. This directory # itself can reach 200M. WE DO NOT RECOMMEND that you change this. #PORTDIR=/usr/portage # I don't think that warning is in the newer ones. That one came from the 1.4 days. Sort of a old install. ;-) Dale :-) :-)
Re: [gentoo-user] Portage is misplaced in /usr
Replying to the three before messages which basically made the point that one can change the location manyually. I'm aware of that and as I've pointed out I consider it irrelevant to the point that I'm making (with which you appear to agree at least principally), that is, that it should not be the default. A wrong default is wrong. What kind of an aittude is it to acccept a flawed default and just make it right for one self. I for my part have of course changed it but I want to straighten it out for the whole distribution, for those who happen not to have read about how to change it, for those who can't be arsed to fix every single bit that gentoo makes wrong by its own. And what bothers me most is that, as you said, it hasnt been changed in a decade, out of pure ignorance, given that it has been brought up several times already. It does not conform with any accepted standard, it is wrong per se, it should be changed. THIS is the point, please, as I already said in my first email, don't make any more suggestions how one can change this for oneself. It's irrelevant to the issue.
Re: [gentoo-user] Portage is misplaced in /usr
You know... I appreciate all your helpful if you want to move portage to /var you can do it by... 'suggestions', but, can you imagine the following situation: You push a change to a repository, on your way to work you realize that there was an error in the commit so as soon as you get to work you send out an email to everyone Please do not pull until today evening when I have reverted that. And when you're back home and check the status you see that about everyone who could possibly have read you mail pulled from the repo. A parabel for the technically affine...
Re: [gentoo-user] Portage is misplaced in /usr
again, you are starting from a mistaken premise. /usr/portage makes sense, when you consider its history. It may not be the appropriate decision, but with its background it was logical back then. And if something is not broken, don't change it. You do not know what old tool/setting/whatever might suffocate. PORTDIR is not a mere workaround. If you are sure that there is no old crap lingering around that might expect portdir as /usr/portage, use it. Besides /usr/src/ contains linux and other sources. Wrong too? It is f* tradition. portage does not contain temporary data or database stuff - that crap is in /var/db, /var/tmp/portage, /var/lib. So the worst stuff is somewhere already.
Re: [gentoo-user] Portage is misplaced in /usr
Apparently, though unproven, at 22:45 on Saturday 05 February 2011, Volker Armin Hemmann did opine thusly: again, you are starting from a mistaken premise. /usr/portage makes sense, when you consider its history. It may not be the appropriate decision, but with its background it was logical back then. And if something is not broken, don't change it. You do not know what old tool/setting/whatever might suffocate. PORTDIR is not a mere workaround. If you are sure that there is no old crap lingering around that might expect portdir as /usr/portage, use it. Besides /usr/src/ contains linux and other sources. Wrong too? It is f* tradition. portage does not contain temporary data or database stuff - that crap is in /var/db, /var/tmp/portage, /var/lib. So the worst stuff is somewhere already. Tradition on it's own is a lousy idea for retaining anything. A tradition worth keeping is one that's worth having because it has use. However most traditions are merely but we always did it this way... /usr/portage is a tradition, a hangover from BSD. LFS is a standard and /usr/portage gets in the way of the standard. Guess which one should trump the other? And the portage tree IS a database. You put (or cause to be put) data into it, which can be amended, edited, added to or removed, other actors query the database for information (emerge, eix, etc). The fact that it is updated on demand and not on the fly, that it is not relational in nature, that it doesn't have sql anywhere in it's name and that it is purely file-based does not detract in the slightest from the simple fact that the tree is a database. It's just plain outright stupid to have a default location for something (that by definition is variable) in a place that by definition (or by de-facto consent) must be mountable read-only and have no ill effects on the rest of the machine. -- alan dot mckinnon at gmail dot com
[gentoo-user] Re: [OT] Re: Avoiding HAL
On 02/05/2011 05:09 AM, Peter Humphrey wrote: I even had a lockup while running from the live CD Have you tried memtest86 on that machine?
Re: [gentoo-user] Portage is misplaced in /usr
On Sat, Feb 05, 2011 at 09:45:23PM +0100, Volker Armin Hemmann wrote: again, you are starting from a mistaken premise. /usr/portage makes sense, when you consider its history. It may not be the appropriate decision, but with its background it was logical back then. It was consistent back then, I agree. And if something is not broken, don't change it. You do not know what old tool/setting/whatever might suffocate. As I've pointed out portage in /usr *is* broken. If a tool/setting/whatever might suffocate it 1) does not comply to the current state of gentoo 2) will equally suffocate if you change the location trough make.conf As had been correctly pointed out, the only thing that is really required is chaning the *default* portdir(s) PORTDIR is not a mere workaround. If you are sure that there is no old crap lingering around that might expect portdir as /usr/portage, use it. Workarround/Change to make it work, that's hair splitting. Again, we are distracted from the actuall issue which is a (noadays) nonsensical default. If I find out that something relies on a fixed portdir, I will report a bug on that. I will not subordinate the correctness of an Issue A to the incorrectnes of an Issue B. Besides /usr/src/ contains linux and other sources. Wrong too? It is f* tradition. portage does not contain temporary data or database stuff - that crap is in /var/db, /var/tmp/portage, /var/lib. So the worst stuff is somewhere already. You wanna go there? Take my hand, let's go! But consider it a excursion, nothing related to the issue. http://en.wikipedia.org/wiki/Ignoratio_elenchi linux sources do not belong in /usr/ either. However, they are historically based there and this tradition is more deeply rooted than a mere wrong location in gentoo's portage design. There are more flaws like that, none of which justifies that portage should do the same mistakes. Portage does exactly contain temporary data. It contains a database in the most exact meaning of the word. Your argument is absurd.
[gentoo-user] IDE recommendations for writing C?
Can someone recommend a good IDE to write C code in? 1) Something that can display multiple files in a project. 2) Something that have some sort of version control built into it? 3) If possible, I can compile right in the IDE. I've starting writing something. It's hundreds of lines long in 1 file and I just messed up a brace somewhere which I haven't been able to figure out in vi. Thanks, Mark
[gentoo-user] Re: Xorg segfaults, but GDM welcome screen loads
On 02/04/2011 04:54 PM, Grant wrote: Yesterday I caught up with portage and updated quite a few packages on a remote workstation. The system hadn't been updated for about a month. The updates included some xorg stuff and some xfce4 stuff. Today when the workstation's user logged in via gdm, she clicked the xfce4 Migrate Config option, something weird happened, and she ended up back on the gdm welcome screen. Now whenever she logs is via gdm, the screen immediately goes black and she is routed back to the gdm welcome screen again. When I have grsecurity enabled I get this in dmesg: Segmentation fault occurred at 68e453633fdc in /usr/bin/Xorg[X:4777] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/gdm-binary[gdm:4775] uid/euid:0/0 gid/egid:1010/1002 When you upgraded x.org, did you also rebuild it's drivers? I rebuilt nv but not evdev. Could that be responsible for this? I can't answer that specifically, but you should definitely re-emerge it anyway. What happens when you run /usr/bin/Xorg directly instead of with startx? If Xorg still segfaults it may give you better error messages.
Re: [gentoo-user] Portage is misplaced in /usr
On Sat, Feb 5, 2011 at 4:52 PM, Alan McKinnon alan.mckin...@gmail.comwrote: Apparently, though unproven, at 22:45 on Saturday 05 February 2011, Volker Armin Hemmann did opine thusly: again, you are starting from a mistaken premise. /usr/portage makes sense, when you consider its history. It may not be the appropriate decision, but with its background it was logical back then. And if something is not broken, don't change it. You do not know what old tool/setting/whatever might suffocate. PORTDIR is not a mere workaround. If you are sure that there is no old crap lingering around that might expect portdir as /usr/portage, use it. Besides /usr/src/ contains linux and other sources. Wrong too? It is f* tradition. portage does not contain temporary data or database stuff - that crap is in /var/db, /var/tmp/portage, /var/lib. So the worst stuff is somewhere already. Tradition on it's own is a lousy idea for retaining anything. A tradition worth keeping is one that's worth having because it has use. However most traditions are merely but we always did it this way... /usr/portage is a tradition, a hangover from BSD. LFS is a standard and /usr/portage gets in the way of the standard. Guess which one should trump the other? And the portage tree IS a database. You put (or cause to be put) data into it, which can be amended, edited, added to or removed, other actors query the database for information (emerge, eix, etc). The fact that it is updated on demand and not on the fly, that it is not relational in nature, that it doesn't have sql anywhere in it's name and that it is purely file-based does not detract in the slightest from the simple fact that the tree is a database. It's just plain outright stupid to have a default location for something (that by definition is variable) in a place that by definition (or by de-facto consent) must be mountable read-only and have no ill effects on the rest of the machine. -- alan dot mckinnon at gmail dot com Just put portage on it's own partition (LVM) and be done with it.
Re: [gentoo-user] IDE recommendations for writing C?
Mark Knecht writes: Can someone recommend a good IDE to write C code in? 1) Something that can display multiple files in a project. 2) Something that have some sort of version control built into it? 3) If possible, I can compile right in the IDE. Emacs. If you dare to go this way. The learning curve is high, but once you know how to use it, you probably will be glad. Eclipse is pretty cool, and I've heard good things about Kdevelop. I've starting writing something. It's hundreds of lines long in 1 file and I just messed up a brace somewhere which I haven't been able to figure out in vi. Just use the % key. Wonko
Re: [gentoo-user] Portage is misplaced in /usr
Cedric Sodhi writes: Replying to the three before messages which basically made the point that one can change the location manyually. [...] It does not conform with any accepted standard, it is wrong per se, it should be changed. THIS is the point, please, as I already said in my first email, don't make any more suggestions how one can change this for oneself. It's irrelevant to the issue. Hmm, I didn't make myself clear. I did not suggest you should change your PORTDIR, of course you already had done this. And yes, you are right, the location is wrong, it should be changed. But somehow the devs are not really interested in doing this, so I doubt it's worth the battle. So I change the PORTDIR, and now at least my own Gentoo does things right, and is of course cooler than those Gentoos having the totally wrong /usr/portage location. /usr/src is also totally wrong, and I cannot even change this location. But that does not worry me too much either. I assume there are people also trying to change this, but it won't happen. That's bad, but that's just how it is. Wonko
[gentoo-user] Re: Portage is misplaced in /usr
On 02/05/2011 12:05 PM, Alan McKinnon wrote: Apparently, though unproven, at 20:43 on Saturday 05 February 2011, Cedric Sodhi did opine thusly: There are several reasons why portage, neither the tree nor (especially not) the distfiles should reside in /usr. I've been saying this for years. I always change PORTDIR everywhere to /var/portage /var is expected to be heavily written and read from, as it is the case with the portage tree. It's possibly subject to fragmentation and small file sizes and heavy changes, which is usually accounted for my choosing an appropriate filesystem and configuring it accordingly. 100% correct. The tree is a database. No-one in their right mind would put MySQL data dirs in /usr Juts like no-one would put the portage build dir in /usr either /usr is expected to be a static directory with mostly read access and few to no changes on a running system. This issue seems to have been ignored for a long time. When I asked about it, I met two types of responses: a) Those who thought about it and agreed, that portage should be moved b) Those who replied deal with it If you can think of good counter arguement which *logically* supports that portage should by default reside in /usr (including the distfiles and everything else variable) please tell us. Here's the real reason: FreeBSD puts ports in /usr. So Daniel put portage in /usr when he ported ports to portage Everyone else since has left it there. Sometimes the obvious reason really is the right one. Good grief, I just finished sending a reply that says exactly the same. I should have waited a day.
Re: [gentoo-user] IDE recommendations for writing C?
Acme from plan9port. On Feb 5, 2011 5:11 PM, Mark Knecht markkne...@gmail.com wrote: Can someone recommend a good IDE to write C code in? 1) Something that can display multiple files in a project. 2) Something that have some sort of version control built into it? 3) If possible, I can compile right in the IDE. I've starting writing something. It's hundreds of lines long in 1 file and I just messed up a brace somewhere which I haven't been able to figure out in vi. Thanks, Mark
Re: [gentoo-user] Portage is misplaced in /usr
Apparently, though unproven, at 00:23 on Sunday 06 February 2011, Mark Shields did opine thusly: It's just plain outright stupid to have a default location for something (that by definition is variable) in a place that by definition (or by de-facto consent) must be mountable read-only and have no ill effects on the rest of the machine. -- alan dot mckinnon at gmail dot com Just put portage on it's own partition (LVM) and be done with it. Mark, I cannot believe that you actually typed that, you know better. But my eyes don't lie. So. Someone comes along with a valid beef about a default. This default can be changed, this is Gentoo. Ye gods, we change shit around here at the drop of a hat for no good reason sometimes. And your answer is to install LVM with it's deps, re-organize the disk, learn how to use lvm (not everyone knows the product or uses it) then go through the pain of moving stuff which not all users know how to do. All to get around a silly ancient default that long ago failed the most useful to most people test. You want to re-think your answer maybe? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Portage is misplaced in /usr
On Saturday 05 February 2011 23:52:20 Alan McKinnon wrote: Apparently, though unproven, at 22:45 on Saturday 05 February 2011, Volker Armin Hemmann did opine thusly: again, you are starting from a mistaken premise. /usr/portage makes sense, when you consider its history. It may not be the appropriate decision, but with its background it was logical back then. And if something is not broken, don't change it. You do not know what old tool/setting/whatever might suffocate. PORTDIR is not a mere workaround. If you are sure that there is no old crap lingering around that might expect portdir as /usr/portage, use it. Besides /usr/src/ contains linux and other sources. Wrong too? It is f* tradition. portage does not contain temporary data or database stuff - that crap is in /var/db, /var/tmp/portage, /var/lib. So the worst stuff is somewhere already. Tradition on it's own is a lousy idea for retaining anything. A tradition worth keeping is one that's worth having because it has use. However most traditions are merely but we always did it this way... /usr/portage is a tradition, a hangover from BSD. LFS is a standard and /usr/portage gets in the way of the standard. Guess which one should trump the other? And the portage tree IS a database. You put (or cause to be put) data into it, which can be amended, edited, added to or removed, other actors query the database for information (emerge, eix, etc). The fact that it is updated on demand and not on the fly, that it is not relational in nature, that it doesn't have sql anywhere in it's name and that it is purely file-based does not detract in the slightest from the simple fact that the tree is a database. It's just plain outright stupid to have a default location for something (that by definition is variable) in a place that by definition (or by de-facto consent) must be mountable read-only and have no ill effects on the rest of the machine. and you can mount /usr readonly. You can not update /usr/portage - but so what? You can't install anything with /usr being ro anyway. So the last argument is the weakest. Tradition is a much better reason to keep things the same. You need someone to make the change. Which is more than just move /usr/portage to /var or wherever you want it to be (and first: get consent about where to put it). No, you have to update documentation, make sure that there are not old, broken tools and apps that won't get confused etc pp. As long as nobody steps up to do it - why even bother? Most people don't care about it. Those who do can set PORTDIR wherever they want and can live happily ever after.
Re: [gentoo-user] Any way to get real text console without killing X capability?
On Sat, Feb 05, 2011 at 12:10:15PM -0500, Walter Dnes wrote As they say in the infomercials but wait, there's more. My monitor supports 1280x720 and 1280x1024 modes. Using screen I should be able to do splitscreen mode with 2 sessions side-by-each. That is going to have to wait a while. I knew it should be there, but the vertical split doesn't show up. I did some Google searching. http://www.linux.com/learn/tutorials/285795-taking-command-of-the-terminal-with-gnu-screen- says... Some newer releases of screen (later than 4.0.3-10) also support windows split vertically. To split a screen vertically, use Ctrl-a | and then Ctrl-a Tab to enter the new window. To start a new shell in that window, use Ctrl-a c or use Ctrl-a to choose an existing session to display in that window. The current ebuild is screen-4.0.3, and up to screen-4.0.3-r4 (with ~everything) shows up after an emerge --sync. I can ./configure --with-various-options make make install with the best of them (not that I know what I'm doingG), but the latest builds of screen are in a git repository, which I'm not familiar with. Plus which, these builds could be alpha or very early beta, so I don't really want to use them on a production machine. Keywording ~amd64 ebuilds is as much bleeding edge as I want to go. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Re: Any way to get real text console without killing X capability?
On Sat, Feb 05, 2011 at 09:31:48PM +0200, Nikos Chantziaras wrote On 02/05/2011 08:00 PM, Mick wrote: Just try video=1024x768 (or whatever your desired resolution is) on the kernel line and it should just work. Unfortunately, it doesn't. Actually, it does, video=640x480 in my case. The weird part is that the equivalant VGA=6 option no longer works, which is what got me to start this thread in the first place. I had simply assumed that they were identical, and if one doesn't work, neither does the other. Note that this is just for text consoles, X remains at 1920x1200 for me. Of course, the monitor has to support whatever text console resolution you ask for. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] IDE recommendations for writing C?
On Sat, Feb 5, 2011 at 2:39 PM, Alex Schuster wo...@wonkology.org wrote: Mark Knecht writes: Can someone recommend a good IDE to write C code in? 1) Something that can display multiple files in a project. 2) Something that have some sort of version control built into it? 3) If possible, I can compile right in the IDE. Emacs. If you dare to go this way. The learning curve is high, but once you know how to use it, you probably will be glad. Eclipse is pretty cool, and I've heard good things about Kdevelop. I've starting writing something. It's hundreds of lines long in 1 file and I just messed up a brace somewhere which I haven't been able to figure out in vi. Just use the % key. Wonko I specifically _don't_ want a high learning curve. I want this to remain fun, if possible. After an hour and a half of llooking for the problem in vi KDevelop with it's color editor helped me find the problem in a few minutes. That's a big help. I haven't figured out how to tell Kdevelop to use a different compiler but that's not important right now. I can build in a terminal until I learn how. Thanks for the ideas. I also loaded up codeblocks which I read good things about. CodeLite is supposed to be good but I couldn't get it unmasked. Netbeans wanted to install too much Java stuff. Understandable as it's written in Java but I decided not to look at that one right now. For now I'm set. Thanks! Cheers, Mark
Re: [gentoo-user] Portage is misplaced in /usr
On Sat, 5 Feb 2011 19:43:11 +0100 Cedric Sodhi man...@gmx.net wrote: There are several reasons why portage, neither the tree nor (especially not) the distfiles should reside in /usr. Hi Cedric! Why gentoo-user@ ? Choosing (and changing) reasonable defaults is up to developer. You could add gentoo-dev@ to CC to get technical answers. Opening bugzilla entry might also help to get an attention. -- Sergei signature.asc Description: PGP signature
Re: [gentoo-user] Re: Xorg segfaults, but GDM welcome screen loads
Yesterday I caught up with portage and updated quite a few packages on a remote workstation. The system hadn't been updated for about a month. The updates included some xorg stuff and some xfce4 stuff. Today when the workstation's user logged in via gdm, she clicked the xfce4 Migrate Config option, something weird happened, and she ended up back on the gdm welcome screen. Now whenever she logs is via gdm, the screen immediately goes black and she is routed back to the gdm welcome screen again. When I have grsecurity enabled I get this in dmesg: Segmentation fault occurred at 68e453633fdc in /usr/bin/Xorg[X:4777] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/gdm-binary[gdm:4775] uid/euid:0/0 gid/egid:1010/1002 When you upgraded x.org, did you also rebuild it's drivers? I rebuilt nv but not evdev. Could that be responsible for this? I can't answer that specifically, but you should definitely re-emerge it anyway. What happens when you run /usr/bin/Xorg directly instead of with startx? If Xorg still segfaults it may give you better error messages. Thank you everyone. This was due to my using the nv driver on that system. I tried switching to nouveau but it wouldn't work with my onboard GeForce 6150SE nForce 430. I switched to the nvidia driver and all is working. - Grant
Re: [gentoo-user] Portage is misplaced in /usr
Cedric Sodhi wrote: You know... I appreciate all your helpful if you want to move portage to /var you can do it by... 'suggestions', but, can you imagine the following situation: You push a change to a repository, on your way to work you realize that there was an error in the commit so as soon as you get to work you send out an email to everyone Please do not pull until today evening when I have reverted that. And when you're back home and check the status you see that about everyone who could possibly have read you mail pulled from the repo. A parabel for the technically affine... If you mean someone syncs against your system, I don't see how it would matter as to whether portages tree is in /usr or anywhere else. When you move the tree, change the config to point to the new location. My point was, if you don't like it where it is, you can move it and it is easily done. Having the devs change where it is, that is not so easy because that would force a lot, I mean a lot, of people to change their setup. I would be one of those people. I have portage on a separate partition. If it get moved to another directory, I got to change the partition mount point. It may seem like a simple change but it is not so simple when you realize what all it could break. Dale :-) :-)
[gentoo-user] Re: Any way to get real text console without killing X capability?
On 02/06/2011 01:54 AM, Walter Dnes wrote: On Sat, Feb 05, 2011 at 09:31:48PM +0200, Nikos Chantziaras wrote On 02/05/2011 08:00 PM, Mick wrote: Just try video=1024x768 (or whatever your desired resolution is) on the kernel line and it should just work. Unfortunately, it doesn't. Actually, it does, video=640x480 in my case. The weird part is that the equivalant VGA=6 option no longer works, which is what got me to start this thread in the first place. I had simply assumed that they were identical, and if one doesn't work, neither does the other. Note that this is just for text consoles, X remains at 1920x1200 for me. Of course, the monitor has to support whatever text console resolution you ask for. What graphics card are you using? I can't make it work here using the radeon driver.
[gentoo-user] Re: Any way to get real text console without killing X capability?
On 02/05/2011 03:43 PM, Walter Dnes wrote: the latest builds of screen are in a git repository, which I'm not familiar with. (I'm not the same Walter, as you know already :) I urge everyone to get to know git. I admit, I could be prejudiced in git's favor just because it was the first vcs I learned after cvs, but git is going to gain market share just because Linus is who he is. I've now used svn (barf!), bzr (to track grub2), mercurial (to track thunderbird and firefox), and the ancient cvs (which is jumping head first into its grave). I omitted bitkeeper from the list because it's a closed-source product, but Linus has given credit to bitkeeper's creator for inspiring him to write git in the first place. (I barely remember using bitkeeper.) Maybe I just think like Linus, I dunno, but for me git just works, unlike its competitors -- svn in particular, which has earned a very special place in my personal software hell.
Re: [gentoo-user] Any way to get real text console without killing X capability?
On Sat, Feb 05, 2011 at 06:43:32PM -0500, Walter Dnes wrote: The current ebuild is screen-4.0.3, and up to screen-4.0.3-r4 (with ~everything) shows up after an emerge --sync. I can ./configure --with-various-options make make install with the best of them (not that I know what I'm doingG), but the latest builds of screen are in a git repository, which I'm not familiar with. Plus which, these builds could be alpha or very early beta, so I don't really want to use them on a production machine. Keywording ~amd64 ebuilds is as much bleeding edge as I want to go. May be you want to try 'tmux', which was discussed on this list a short while ago. The key combo for vertical splitting is C-b % Since version 1.2 it supports vertical and horizontal splitting, version 1.3 in portage is amd64, and 1.4 is ~amd64. W -- Willie W. Wong ww...@math.princeton.edu Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire et vice versa ~~~ I. Newton
Re: [gentoo-user] Portage is misplaced in /usr
On 5 February 2011 16:15, Sergei Trofimovich sly...@gentoo.org wrote: On Sat, 5 Feb 2011 19:43:11 +0100 Cedric Sodhi man...@gmx.net wrote: There are several reasons why portage, neither the tree nor (especially not) the distfiles should reside in /usr. Hi Cedric! Why gentoo-user@ ? Choosing (and changing) reasonable defaults is up to developer. You could add gentoo-dev@ to CC to get technical answers. Opening bugzilla entry might also help to get an attention. He already did. He was told to ask here. :-) http://bugs.gentoo.org/show_bug.cgi?id=351463 (WONTFIX) And there are several others asking for the same/similar changes. All the way back to 2004, AFAICT. I can understand that we don't want to automatically change everyone's installed Gentoo from /usr/portage to /var/portage but why not try to get new installs set up properly? Then perhaps an explanation on how existing installs could be migrated for those wanting to do so? It would seem that all that's required is: 1) add an explicit PORTDIR=/usr/portage to /etc/make.conf for existing installs (unless PORTDIR is already specified, of course); 2) change the default. Is it really more complicated than that?
[gentoo-user] [OT Xming] Syntax in the launch script
This is a little of the beaten track for this forum but there doesn't seem to be a regular Xming forum. Also since my problem is related to running emacs thru xming, I tried on emacs.help more than once to get this figured out. Any emacs users here will know about emacslcient, and maybe some of you are experienced users. I've used it a bit but not ever very consistently over time. Right now, I'm using Xming running on Win7 to start emacs on my linux destop but it runs in Xming on windows 7 desktop. Quite a nice setup, but so far I've been loading a specific set of fonts and back/fore ground colors (in emacs) ... It seems to loose track of the default font when started this way. I want to combine loading that little `library' I wrote (just a brief *.el file) with the emacsclient cmdline inside the Xming launch script. It appears to be just Xml I guess.. And here is what I use now: (left unwrapped) ?xml version=1.0 encoding=utf-8? XLaunch xmlns=http://www.straightrunning.com/XmingNotes; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.straightrunning.com/XmingNotes XLaunch.xsd WindowMode=MultiWindow ClientMode=StartProgram Program=emacsclient -s nognus -c ClientStart=PuTTY PasswordStart=true RemoteHost=reader RemoteUser=reader Clipboard=true/ That starts emacs running on windows 7 based on the emacs server named `nognus' So the basic syntax, like you'd do from linux cmdline is: emacsclient -s nognus -c And to load the library I want loaded it is: emacsclient -c -s nognus -e (load-library \xming-on-m1\) (xming-on-m1 sets the default font, and fore/backgrd colors) That command line starts emacs in new frame running from the server named nognus. How to get that into the xml is the part where I'm falling down. If you replace the cmd shown in the above xml code: emacsclient -s nognus -c with emacsclient -c -s nognus -e (load-library \xming-on-m1\) That fails... I've tried all different kind of escaping and such as I could come up with. But it all has provoked an error along the line that I have left out a needed white space at char number N. It usually falls right at (load somewhere. The error pops up on the win7 desktop and is coming right from the xming launch script... not from emacs. So as a starting point, the xml code above as shown starts emacs as expected. A couple of attempts I've tried: \(load-library \xming-on-m1\)\ \\(load-library \xming-on-m1\\)\ Then double escapes and on and on. I don't know do-do about xml but hoped that someone here would know how to get the needed code past the script and on to emacs. I'm thinking some kind of combination of escape and quote but maybe I'm clear off base.
[gentoo-user] [OT] Adjusting chromium?
Hello list, Sorry to bother you with another OT question. I've been trying the /chromium/ browser and I've come to like it - except for one thing: I can't see how to force pages to be shown in sans-serif but without forcing a particular font or size etc. Has anyone found a way to do it? I couldn't get anything helpful from Google. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
