Re: [gentoo-amd64] Qt tutorial 7 - anyone got this to work?
On Sunday 25 March 2007, Daiajo Tibdixious wrote: This is probably off-topic, so suggestions to go elsewhere are welcome. I reported this to trolltech as a bug, but it doesn't show in their task tracker. http://doc.trolltech.com/4.2/tutorial-t7.html Introduces creating ones own signals slots. slots seem to work fine but signals are not found in a connect call. I can't see any difference between the Qt supplied signals (in their includes), and my ones. Another funny is that the Q_OBJECT macro works fine in the Qt includes, however if used in my program, linker vtable errors occur caused by the virtual functions declared by the macro. I should probably tell you to read the documentation. What happens is that you must include the macro, AND, run moc on your file which creates another C++ file that you must also compile (and link). The easiest way to build qt projects is to use qmake which handles it for you. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpZXUbTGKaUN.pgp Description: PGP signature
Re: [gentoo-amd64] firefox 2 on amd64
On Wednesday 03 January 2007 23:34, Neil Bothwick wrote: On Wed, 3 Jan 2007 13:55:29 -0600, Boyd Stephen Smith Jr. wrote: There is a script using Perl::curl that will download a youtube video as as mpeg that can be played with mplayer. It was posted to one of the gentoo lists recently, probably this one or gentoo-user. http://www.mail-archive.com/gentoo-user%40lists.gentoo.org/msg48504.html Although according to file, the downloaded files are flash, but mplayer plays them. They are not flash, they are flash video. Which is a format that mplayer indeed knows how to play. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgprv7q4K2MO0.pgp Description: PGP signature
Re: [gentoo-amd64] Is Xorg server built in static form?
On Friday 12 January 2007 23:45, Daniel Iliev wrote: Richard Fish wrote: man xorg.conf. Load and SubSection are two ways to specify the same thing for modules, so you should use one or the other, not both. -Richard I tried this: --snip-- Section Module # Load extmod SubSection extmod Option omit xfree86-dga I'm a bit late, but this line is wrong. It should probably be Option omit xfree86-dga (note the extra two double quotes). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpewXoceSqLl.pgp Description: PGP signature
Re: [gentoo-amd64] Terminal control codes
On Sunday 14 January 2007 18:36, Peter Humphrey wrote:
On Tuesday 02 January 2007 17:09, I wrote:
Secondly, another FAQ says to send setterm codes to /dev/vc/X, but since
(I assume) the rise of udev those devices don't exist any more.
Can anyone help me here? I need to know where to send setterm -blank 0 to
prevent screen blanking on vc1-6 and 12. Or have I to find the blanking
code in the source (which source?) and switch it off there? Maybe there's
an option to a configure script somewhere.
Try /dev/vcs{1..12} or /dev/tty{1..12}
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net
pgp8oI8dPVsnz.pgp
Description: PGP signature
Re: [gentoo-amd64] how to track down strange bug
Florian D. wrote: Hi, I have been hitting by a bug for ages, which I want to get rid of eventually ;) It is not possible for me to watch TV via xawtv, while doing IO intensive tasks in the background. In the majority of cases, it suffices to copy a, say, 50MB file from my USB-stick to the harddisk to freeze my amd64 machine (but, funny enough, the sound is playing further on). It is quite important that you use dma accelerated tv out. Especially with xawtv as it doesn't do postprocessing this should work until you saturise your pci bus. The freezing thing however suggests that dma is not enabled for your harddisk which is an even bigger performance issue. Make sure you have the right drivers in your kernel, or loaded as module. Paul -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: how to track down strange bug
Neil Bothwick wrote: On Fri, 20 Oct 2006 10:41:47 + (UTC), Duncan wrote: At the cost any more, like so much these days, microwave ovens are essentially disposable -- simply not worth repairing. Except mine was an expansive combination oven :( How can you expand combination ovens ;-) ? In general combination ovens don't work either way. The microwave can't really handle the heat. The oven is too cramped to bake anything decent in it. We specifically opted for two devices for that reason. Paul -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Resuming an emerge where it left off
Vladimir G. Ivanovic wrote: Is there a way of resuming an emerge of a package at exactly the place where it stopped, like restating a make where it stopped? For example, it took hours for me to get to the point where the emerge of openoffice failed because I was using the wrong JDK. It would be nice not to have to toss away all that work and to be able to restart from the point where I left off. I see in /etc/make.conf.example that there is a feature called noauto that seems to do what I want, but every time I've tried using it, it has restarted from the beginning. I didn't try it with openoffice, but if I had I would have tried: ebuild openoffice-2.0.4.ebuild compile qmerge Is what I'm after possible? As long as you don't mess with the stages (the .compiled file for example) it should work more or less. A little work will be redone (like running configure again), but make will then skip most of the steps. This generally goes wrong if you change useflags or significantly change the environment (like a different major java version). The result normally is just another miscompile so it might be worth your effort. Paul -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Resuming an emerge where it left off
Vladimir G. Ivanovic wrote: On Fri, 2006-10-20 at 00:34 +0100, Neil Bothwick wrote: On Fri, 20 Oct 2006 01:15:08 +0200, Sebastian Redl wrote: Whereas emerge clears the work directory and starts again, running ebuild directly does not. It's also possible with emerge with FEATURES=keepwork but I prefer the ebuild method. Thanks. I'll give keepwork and/or the ebuild method a try. --- Vladimir A safe alternative that may safe some time, but not as much as make skipping files is ccache. It has checks that exactly all things are equal, so nothing could go wrong. It's as easy as installing ccache. Paul -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Printer Setup
Boyd Stephen Smith Jr. wrote: Probably an MFC-7420, like mine, or possibly one of it's big brothers. They have cups, lpd, and sane drivers available for x86 linux, but no support for other arches (including x86_64) last time I checked. They do have a separate cups driver that allows faxing from your desktop. As I'm on x86_64 and don't need a scanner much, I looked for other cups drivers that were available from portage and found the Brother MFC-9600 Foomatic/hl1250' driver worked fine for simple printing. Actually, cups drivers are binaries, so you could just use the x86 driver on a x86_64 system. It shouldn't really be slower either. Paul -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
Boyd Stephen Smith Jr. wrote: On Wednesday 27 September 2006 11:11, Hemmann, Volker Armin [EMAIL PROTECTED] wrote about 'Re: [gentoo-amd64] First Impressions': -O3 don't do it. O2 is much, much safer and not really slower. It will prevent a lot of breakage. Bah! -O3 breaking just doesn't happen anymore. I'm been running it for years. In fact -O3 has never generated invalid code [1] on x86 or amd64 platforms. It did for a period of time on ppc, but I think that was like 10 years ago. The thing is that besides compiler errors, there are many program errors out there that are not caused by optimization levels, just exposed. From the point of view of a user however it doesn't matter where the error is. It is an error, and thus should be fixed. Now, it is an open question whether -O3 is significantly faster than -O2 and depending on a number of factors it may actually be slower. -O3 will enlarge code to make execution paths shorter, but a cache miss is probably goes to blow away any advantage gained. Conversely, -Os will make execution paths longer to shrink code, and a cache hits may make up for the longer path. [2] The main thing is that -O2 is the default at most places, and as such gets the most testing. That means that things generally work for -O2 where -O3 or -Os exposes bugs in the software. Paul -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] CFLAGS for Core2?
On Wednesday 20 September 2006 22:25, Jack Lloyd wrote: Tomorrow my new Core 2 workstation should be arriving, and reading through the 2006.1 amd64 install notes and so forth, the recomended CFLAGS for EM64T CPUs is -march=nocona. However as that is tuned for 64-bit enabled Netburst rather than Conroe, I'm wondering if anyone had thoughts on good flags. In particular as (to the extent that I know anything about microarchitecture), Conroe seems closer to a K8 than a P4, especially with regards to pipeline length and execution resources, I'm not sure that P4/Netburst tuning is the right thing to do. But the GCC docs say that -march=k8 enables 3dnow, which Intel chips don't have. So, right now the seems likely options would be: -march=k8 -mno-3dnow -msse3 -march=nocona -march=pentium-m -m64 [saw this suggested in the forums, seems like a bad idea] Or can I get away with just something like -mtune=k8 -msse3 (will this get me 64-bit code?) To be clear, my main goals here are a) enable generation of all instructions the CPU has, b) keep GCC from generating 3dnow,etc instructions, and c) get instruction scheduling that is at least moderately decent for the uarch I'm using. Since SSE/SSE2, -mfpmath=sse, and argument passing via registers are default in 64-bit mode, I suspect the only other options I might try are -momit-leaf-frame-pointer, -frename-registers, and -finline-functions. Be aware that -march and -mtune can be used together. This means that you use -march=nocona to specify that such code must be generated, but you can try different options for -mtune that only influences code scheduling and which of alternate code options is chosen. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp1PobRoPWJB.pgp Description: PGP signature
Re: [gentoo-amd64] Boot Problems... /dev/sda
On Wednesday 06 September 2006 00:06, Peter Davoust wrote: Try booting up and then running shutdown -rf now and see if that will do the trick. If I understand correctly gentoo doesn't actually run fsck, is that right? It doesn't do automatic repairs by default. This can be enabled but will NOT solve the problem of a probably broken harddisk. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp08U7PZSKbL.pgp Description: PGP signature
Re: [gentoo-amd64] Boot Problems... /dev/sda
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mario A Wojcik wrote: The fsck run correctly but requires the user interventions for repair. The hd is good, don´t report SMART errors and the fsck correctly logicals errors only. My question is if to some it happens to him the same with ext3 like root and if it is possible that fsck does not request confirmation in the repairs. Let say it as such. If you consistently have filesystem errors that require user intervention something is seriously wrong. There are a number of possible causes: - - Broken harddisk - - Broken filesystem driver (unlikely, but try to recompile your kernel from scratch anyway) - - Broken shutdown process. If your disks are not properly unmounted at shutdown, it could cause these issues. Paul - -- Paul de Vrieze Researcher Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5-ecc0.1.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE/sjfbKx5DBjWFdsRAgAkAKDdrGwmmaxs1mcjHsnyORlnvzNQRQCeIBJ9 07SzySpUWExvDWac4lxU7Es= =EtkB -END PGP SIGNATURE- -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Running a command after closing a session Possible?
On Tuesday 05 September 2006 01:39, David Fellows wrote: Ok, so is there any way to run a command and get it to continue running after closing the current session? I'd really like to be able to ssh to my server, run an emerge --update --newuse world on it and then close the window and be on my way. Any ideas? Thanks, -Peter -- gentoo-amd64@gentoo.org mailing list nohup emerge --update --newuse world This will however redirect the output to a file with a somewhat unpredictable name. The screen method allows you to do things naturally. Otherwise you could also redirect the output to a filename of your choosing. Nohup detects this and then does not create an output file. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpE02XXkXumB.pgp Description: PGP signature
Re: [gentoo-amd64] Re: JRE - how to install one?
On Sunday 03 September 2006 21:39, Duncan wrote: Peter Humphrey [EMAIL PROTECTED] posted What am I doing wrong? nsplugin refers to the mozilla/netscape browser plugin, and you aren't using it for that so it shouldn't matter. I don't use OO.o as I don't need it, and don't have a Java installed as none of the options Gentoo provides for that are freedomware and I don't need it enough to bother researching it further. However, from what I've read about it, you've done everything right in general but for one thing related specifically to OO.o on amd64. Because the OO.o build is 32-bit binary, it apparently looks for a 32-bit Java version, and doesn't see the 64-bit version. I've seen the solution posted here in the past but don't recall exactly what it was. I'm guessing it either involved a symlink placed appropriately so OO.o could find and use the 64-bit version, or installation of a 32-bit version. You're right, the only thing is that openoffice uses the library interface of java. As such you need a 32bit for the 32bit openoffice. (2.0.4 is supposed to compile in 64 bits). A 32bit jdk could be installed manually, by use of a modified ebuild, or by using a binary package. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpnpDhLAFwOM.pgp Description: PGP signature
Re: [gentoo-amd64] VMware and unregister_netdevice
On Saturday 19 August 2006 00:28, Jorgen Jonsson wrote: I just started using gentoo and I was really surprised when I got: unregister_netdevice: waiting for vmnet1 to become free Haven't seen that for a long time in Fedora Did you enable module unloading in your kernel config. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpCGGlHVqcZ9.pgp Description: PGP signature
Re: [gentoo-amd64] USB-Serial Converter?
On Monday 14 August 2006 05:47, Peter Davoust wrote: Dmesg: ohci_hcd :00:13.0: wakeup usb 2-1: new full speed USB device using ohci_hcd and address 4 usb 2-1: configuration #1 chosen from 1 choice This is not exactly what is needed. Basically the easiest thing is to unplug the device. Do a dmesg. Plug the device. Do a dmesg. The new lines are interesting. I think however that the others are right that you don't have the proper driver in your kernel. As you say that you have a driver available, make sure that this module is loaded / compiled into your kernel before pluggin in the device. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgptDOGXjAJxJ.pgp Description: PGP signature
Re: [gentoo-amd64] Problem emerging subversion-1.3.2-r3
On Sunday 06 August 2006 23:25, Marcel Treis wrote: Hi, i have some problems emerging subversion: I tried multiple versions of subversion, even stable ones ;-) but it seems it will produce this error every time: /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../x86_64-pc-linux-gnu/bin/ ld: cannot find -ldb-4.2 Has anybody encountered the same problem and - hopefully - fixed it? The short anwer: remerge apr-util. Subversion uses whichever db version that apr-util was linked against (multiple versions in one binary is ill advised, although the ebuild has special measures to avoid complete havoc). When unmerging db-4.2 you basically broke apr-util (which strangely enough does not by default specify the link in its library so revdep rebuild might not catch it) Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp0YcuAm8F68.pgp Description: PGP signature
Re: [gentoo-amd64] gcc 4.1 + CFLAGS
On Friday 09 June 2006 14:13, Ian McCulloch wrote: On Fri, 9 Jun 2006, Vladimir G. Ivanovic wrote: On Fri, 2006-06-09 at 07:47 +0200, Michael Weyershäuser wrote: I don't recommend -ffast-math on a global basis (or at all), it gets you right where the Pentium fdiv bug brought us some years ago: floating point operations will be faster, but they could get a wrong result in some occasions... Linus seems to use -ffast-math: http://gcc.gnu.org/ml/gcc/2001-07/msg02150.html. At least in 2001 he did. I use it too, in my numerical simulations of the Schroedigner equation, I think it is fairly standard in the numerics community. My understanding is that it results in a fairly consistent and predictable loss of precision for some operations, nothing like the catastrophic *errors* in the the intel fdiv bug. Of course, for algorithms that are sensitive to precision, it can (and does) cause problems. And all please remember that there are fairly easy equasions that can be very numerically unstable. In such cases every bit of precision counts. Just do not enable it globally. If packages can use it, they can enable it themselves. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpuhe9HZ7QCm.pgp Description: PGP signature
Re: [gentoo-amd64] gcc 4.1 + CFLAGS
On Saturday 10 June 2006 00:28, Hemmann, Volker Armin wrote: On Friday 09 June 2006 23:42, Vladimir G. Ivanovic wrote: On Fri, 2006-06-09 at 16:14 -0500, [EMAIL PROTECTED] wrote: Enough research has gone into writing code for IEEE floating point that I would not try to bypass it without a good reason. It’s there to be your friend. Performance is the reason we have hardware FPUs and -ffast-math. no, ffast-math is for the case, that you a) don't need accurate results b) the FPU is not fast enough since you can't say if you need accurate math for an app you did not wrote or examined, using ffast-math is highly dangerous. And sicne the hardware gets faster on an almost monthly basis, it is even less convincing why anybody should use it. I completely agree. The gcc info page puts it this way: This option should never be turned on by any `-O' option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions. In short there is a very good reason it is not on by default and may never be turned on by default. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpNDQC4kPDEN.pgp Description: PGP signature
Re: [gentoo-amd64] gcc 4.1 + CFLAGS
On Saturday 10 June 2006 00:32, Hemmann, Volker Armin wrote: On Friday 09 June 2006 22:45, Vladimir G. Ivanovic wrote: On Fri, 2006-06-09 at 20:50 +0200, Hemmann, Volker Armin wrote: If -ffast-math is filtered or stripped out, there is no harm in leaving it in CFLAGS, right? no, because a lot of other flags are filtered too! What??? Whether only -ffast-math is filtered or all flags are filtered, -ffast-math still filtered. I don't see where the harm lies. the harm lies in an app, that does not filter and breaks in subtle ways when compiled with fast-math. One may even argue that those ebuilds that filter out fast-math are broken as it is an unsupported flag. One that can not be expected to work globally. (And yes I'm maintainer of one of them (ooffice)). The reason that maintainers add them is just because there are too many people that insist on using broken flags, but still want to be able to have a useable system (including an office suite). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpMQqYIEmcQI.pgp Description: PGP signature
Re: [gentoo-amd64] Re: Install Athlon 64 X2 32-bit
On Thursday 01 June 2006 02:29, Mike Owen wrote: On 5/31/06, Duncan [EMAIL PROTECTED] wrote: You have at least four options. The first is to just install it as a normal x86 (using basically the same settings you probably use now, since I see you are on AthlonXP, only with SMP for the dual-core, and perhaps -march=k8 in your CFLAGS). snip That's probably a bad idea. Setting k8 enables the PTA_64BIT option in gcc, which I'm guessing won't work too well with a pure-32bit kernel + userland. You're probably best off using the same profile as you are now. If your kernel supports the hardware, you could even do an inplace upgrade, and not have to reinstall at all. The one thing you'll miss out on with using the athlon-mp or athlon-xp -march settings is sse2, and athlon-fx specific tuning. Actually I've been running mostly 32 bit on my athlon64 and I always use CFLAGS=-march=athlon64. Works perfectly and stable. My guess would be that gcc distinguishes based on what compiler it is. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpwMrIC95kF2.pgp Description: PGP signature
Re: [gentoo-amd64] OT - graphic card for dual-monitor high-resolution graphic station
On Tuesday 30 May 2006 23:43, Piotr Pruszczak wrote: Hi, I have real problem which graphic card to choose for 64-bit Linux It should perfectly work with dual-monitor configuration, my customer wants to try me to configure machine for uStation-J (Bentley GIS software) Price is NOT so important. Problem is this should WORK good @ high-resolutions, full colours optimum performance on 64-bit system. Do you have any ideas ?? Optimum performance means probably one with a dual dvi output. Then it depends on what the customer actually wants. Is 3d performance important? Is support for the latest features important? Basically there is the choice between ati and nvidia chipsets. If you want 3d and dual monitor, the 2048x2048 virtual screen limitation for the opensource ati driver probably counts it out. I don't know whether that limit exists in the closed driver, or in the nvidia driver. In maturity the nvidia closed driver probably is better than the closed ati driver. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpgyNKP4uetI.pgp Description: PGP signature
Re: [gentoo-amd64] amd64 install in chroot?
On Wednesday 24 May 2006 14:56, Tóth Csaba wrote: Hi! I would like to ask a little help. I have a server, some day ago i changed the motherboard on it. The old was a 32 bit system, but the new is a 64 bit system (amd64). Last time when i change from a RedHat to gentoo i make my gentoo install in a simple chroot into a fresh partition on the disk, and to boot the new system i just should make a line in the grub.conf to it. But now can i do this? Or i must get a new harddisk, an another motherboard, install there a 64 bit system, than shutdown the old one, and boot the new from the other disk? Or i can make a hot install? Ok. If you can boot from CD that is way easier. However, it should be possible to do a chroot. However, to do that you must use a 64 bit kernel. A 64bit kernel is however fully capable to run a 32 bit system. Then you can do a normal chroot setup with a 64 bit userland. It should be possible to build a 64bit kernel by crosscompiling, or by taking it from the livecd. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpaVJfvnQdRL.pgp Description: PGP signature
Re: [gentoo-amd64] Re: KDE 3.5.2-r1 emerged Issue!
On Tuesday 23 May 2006 14:40, Hamish Marson wrote: Peter Humphrey wrote: On Friday 12 May 2006 19:16, Duncan wrote: You hit the infamous libexpat bug! I did too, and after several attempts to get revdep-rebuild to fix the problem I gave up and reinstalled from scratch. Now I can't get arts to run - it gobbles 95% CPU from when I log in to when artsd gets killed on a cpu overload. I've raised a bug on this. Infamous expat bug? Would this be where you update libexpat because something wants the later verison then everythig fails because it can't find libexpat.0? Grr... I hit that last night... I'm still running an emerge -D world to re-install everything (Since revdep-rebuild failed for me). What you can do to keep a useable system in the meantime is to create a symbolic link from /usr/lib/libexpat.so.1 to /usr/lib/libexpat.so.0. As the ABI did not actually change this is sufficient to keep things working while you recompile the stuff. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpyU7t9sCRI4.pgp Description: PGP signature
Re: [gentoo-amd64] Nvidia drivers not workin'
On Wednesday 17 May 2006 13:10, giovanni iaboni wrote: Hi, I have searched extensively and have not found anything related to my question, but I apologize if it has been discussed here before. After installing Nvidia drivers (modular xorg-x11), I cannot obtain them working: follows the end of Xorg.0.log [cut] Backtrace: 0: X(xf86SigHandler+0xc5) [0x473662] 1: /lib/libc.so.6 [0x39dff30280] 2: [0x96c12f] Nah, This backtrace alone is not enough information to go on. You could also try bugzilla, but include the full log. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpqTTRhbvuvo.pgp Description: PGP signature
Re: [gentoo-amd64] gnome-2.14.0 masked while gnome-session-2.14.1 is not
On Saturday 13 May 2006 20:45, Mark Knecht wrote: Simon, Sorry. My mistake. For some reason I had three Gnome packages unmasked in my package.keywords file. I suppose it was probably required some time ago to get things installed on my AMD64 system but is not strictly required now. After updating with eix-update and To prevent this, it is important that you limit the unmasking of packages. Use a precise version number if appropriate. Otherwise at least limit the major version. Something like gnome-base/gnome-session-2.13_pre0 This might be some work when that version comes around, but it prevents you from being surprised. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpco2KmxRIfX.pgp Description: PGP signature
Re: [gentoo-amd64] Re: Re: Re: KDE 3.5.2-r1 emerged Issue!
On Monday 15 May 2006 15:26, Duncan wrote: Paul de Vrieze [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 15 May 2006 13:13:16 +0200: Actually this is only one part of the problem. Another part is caused by the fact that in general C++ programs (specially the kde/qt ones) include megabytes of header files. That reminds me... What ever happened to the precompiled headers thing? Could it be useful for Gentoo? (I remember reading about how great precompiled headers were going to be, but not fully understanding the implications, and I haven't the foggiest if gcc ever got the feature.) Well, packages within gentoo could support it. It is necessary to have support for it in the package though. The catch with the headers is that only one header in a compilation can be used precompiled. Effectively this implies the following system: 1 big include most stuff header. Each c file first includes that header Then includes others. The big include header is precompiled. Speedup is achieved. This means that it has consequences for the code. That makes it harder to use. And impossible for gentoo to enforce it. It is one of the consequences of the usage of includes (instead of proper modules) by C. Be aware the choice for include files and a separate preprocessor made a lot of sense when C was designed. C++ has them for compatibility, but for any new language splitting headers and body in different files no longer makes sense. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpuSQMQuTJzi.pgp Description: PGP signature
Re: [gentoo-amd64] really need help
On Monday 10 April 2006 09:53, Jürgen Schinker wrote: bdftopcf.c:32:19: X11/X.h: No such file or directory This is the first error. This file should exist in /usr/include/X11/X.h. I'm not 100% but I believe these are provided by x11-proto/xproto. Which is an indirect dependency (through libXfont). Try to make sure that you have the relevant portions of X emerged? Which portage version are you using? Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpdCKT6HOnO5.pgp Description: PGP signature
Re: [gentoo-amd64] really need help
On Monday 10 April 2006 11:23, Jürgen Schinker wrote: On Mon, April 10, 2006 10:18, Paul de Vrieze wrote: On Monday 10 April 2006 09:53, Jürgen Schinker wrote: bdftopcf.c:32:19: X11/X.h: No such file or directory This is the first error. This file should exist in /usr/include/X11/X.h. I'm not 100% but I believe these are provided by x11-proto/xproto. Which is an indirect dependency (through libXfont). Try to make sure that you have the relevant portions of X emerged? Which portage version are you using? ok i emerge xproto an now this More headers are missing. I don't really know where this one is from, but it shouldn't hurt to make sure that all of the dependencies are merged. It seems that somehow your dependencies are either merged incorrectly or not there at all. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp9ZEWon1KHc.pgp Description: PGP signature
Re: [gentoo-amd64] error while emerging dev-lang/php-5.1.2
On Wednesday 22 March 2006 12:08, Michal Žeravík wrote: Hi all, I've tried to switch off soap, but still getting this error: * * If this package fails with a fatal error about Apache2 not having * been compiled with a compatible MPM, this is normally because you * need to toggle the 'threads' USE flag. * * If 'threads' is off, try switching it on. * If 'threads' is on, try switching it off. * You should have more luck with the threads useflag. Or by remerging apache2. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpDtBsg6sLij.pgp Description: PGP signature
Re: [gentoo-amd64] Am i being over optomistic ?
On Monday 13 March 2006 01:44, David Guerizec wrote: On Sunday 12 March 2006 16:50, Paul de Vrieze wrote: On Sunday 12 March 2006 11:29, Neil Stone wrote: OK, I have managed to get my gentoo system in to a rather wierd state... I will be rebuilding it shortly (several apps installed that fail to work now etc..) Is there anything wrong with building on a separate disk, in the same machine using chroot ? There shouldn't, unless you used some strange bind mounts. (bind mounting /dev, /sys, /usr/portage, and /proc is ok. (If you build binary packages, and it is a 32bit chroot, put them somewhere else). Even building in a subdirectory works (I've done it often enough). I'm curious to know how you built a new system in a subdirectory without chroot. Can you share your experience or a pointer ? Not without CHROOT indeed. That's really really hard to do. And portage can't do it. Chroot works though, and it does not need to be a separate partition/disk. (though you can't boot from a directory well. out of the box) Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpmz27ipWXB8.pgp Description: PGP signature
Re: [gentoo-amd64] Am i being over optomistic ?
On Sunday 12 March 2006 11:29, Neil Stone wrote: OK, I have managed to get my gentoo system in to a rather wierd state... I will be rebuilding it shortly (several apps installed that fail to work now etc..) Is there anything wrong with building on a separate disk, in the same machine using chroot ? There shouldn't, unless you used some strange bind mounts. (bind mounting /dev, /sys, /usr/portage, and /proc is ok. (If you build binary packages, and it is a 32bit chroot, put them somewhere else). Even building in a subdirectory works (I've done it often enough). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpWEDupnibbS.pgp Description: PGP signature
Re: [gentoo-amd64] VMware Player on Gentoo question
On Thursday 09 March 2006 03:45, Mark Knecht wrote: Thierry, Thanks for the response. I tried the player. It emerged but didn't run complaining that I hadn't configured it. With no good instructions about to get me through that quickly I've put the idea to bed for now. I'll revisit it later if it makes sense. You need to run a configure script. I don't know exactly where player stores it, but the ebuild should contain/output the information. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpy2Y0wpCn0w.pgp Description: PGP signature
Re: [gentoo-amd64] No xorg.conf but GNOME works great?
On Tuesday 07 March 2006 05:14, Charles Read wrote: Hi everybody! So I followed the GNOME install from the website, and I can totally run GDM and get into my desktops. But the screen resolution is off and there is no xorg.conf file in /etc/X11 to edit. I am running an HP dv5000 notebook with the Turion AMD 64. Any help? Xorg got so advanced it does not need a configure file. It doesn't know exactly what is desired in all cases though. There are a number of ways to create a config file. One way is to use X -configure. There should be a manual on configuring X somewhere among the docs. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpKt7DVcnx8p.pgp Description: PGP signature
Re: [gentoo-amd64] full write access to ntfs
On Wednesday 01 March 2006 17:17, Michal Žeravík wrote: Hi all, anyone know how to get %subj% on native gentoo64? Kernel has partial write support, captive-ntfs seems to be x86 only. Is there any way? Write support is currently working best with the ntfs-progs / fuse combo. The version in portage is not current though, and the new version is probably better. You must have a fuse enabled kernel though. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpT0Whotj7mV.pgp Description: PGP signature
Re: [gentoo-amd64] full write access to ntfs
On Wednesday 01 March 2006 17:40, Michal Žeravík wrote: Paul de Vrieze wrote: On Wednesday 01 March 2006 17:17, Michal Žeravík wrote: Hi all, anyone know how to get %subj% on native gentoo64? Kernel has partial write support, captive-ntfs seems to be x86 only. Is there any way? Write support is currently working best with the ntfs-progs / fuse combo. The version in portage is not current though, and the new version is probably better. You must have a fuse enabled kernel though. Paul from linux-ntfs.org: *Write support:* Last, but not least, the kernel driver now does all sorts of mambo jumbo when mounting a volume R/W. Features come slower than ntfsmount (fuse) but much more stable. So RW use of kernel-driver is now really reliable? (using 2.6.15-gentoo-r5) Or better to use ntfsprogs/fuse? The kernel is very reliable and will certainly not destroy your data, or even require a chkdsk from windows. It does however support writing less often. For both modes, writing is enabled, but does not always succeed. Whether or not it succeeds is dependent on the structure of the directory the file is to be written into. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpJ0KbrCkqdZ.pgp Description: PGP signature
Re: [gentoo-amd64] Problem emergin cdk
On Tuesday 28 February 2006 09:37, Lorenzo Milesi wrote: It's nearly 1 week I'm trying to upgrade CDK but the compile fails. It seems that your gcc is hosed. Those files it complains about not finding. Those are internal files to gcc. You say you do have the files. Are they readable? Does anything else merge? Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpjdEb8BOUrz.pgp Description: PGP signature
Re: [gentoo-amd64] Problem emergin cdk
On Tuesday 28 February 2006 11:22, Lorenzo Milesi wrote: It seems that your gcc is hosed. Those files it complains about not finding. Those are internal files to gcc. You say you do have the files. Are they readable? Does anything else merge? Yes, I can merge everything but cdk. The files are located in /usr/lib64, attr -rw-r--r-- owned by root:root. Shoud I recompile gcc? You could try. It could also be that cdk just has a sucky link system. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpD9VxfJNwaZ.pgp Description: PGP signature
Re: [gentoo-amd64] Re: Open Office / NFS write problem
On Tuesday 28 February 2006 04:22, Mark Knecht wrote: Excellent!! That seems to work very fine! Thanks very much! I guess that when new OO release come along you must remember to change this again? Alternatively, you might want to consider running nfs.lockd. This provides locking to nfs shares, and as such solves the problem the other way. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp9W5DeWUEFG.pgp Description: PGP signature
Re: [gentoo-amd64] Problem emergin cdk
On Tuesday 28 February 2006 13:01, Kirby Walborn wrote: I had the same problem and fixed it by doing this: emerge --oneshot libtool After doing the above cdk emerged fine. I found the answer in the forums but not the reason why this fixes it. Basically because libtool is often broken. Sometimes more than others. It does however always cause pain. And more than it is supposed to fix. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp53yCv0SjBC.pgp Description: PGP signature
Re: [gentoo-amd64] Re: Problem emergin cdk
On Tuesday 28 February 2006 14:46, Duncan wrote: Kirby Walborn posted [EMAIL PROTECTED], excerpted libtool is, I /believe/, the library tool (real smart there, eh? g) that creates all those *.la (not sure what that stands for but linker advice fits) text files, that in turn give gcc some help figuring out libraries. I've never happened to come across the details and haven't gotten around to looking them up either, but I HAVE seen a Gentoo dev remark that libtool was a solution to one problem that ended up creating another -- PARTICULARLY for a frequently updated from-source distro like Gentoo. It actually does not let gcc figure out anything, but people use libtool to use gcc. Libtool then fixes up the call to gcc. In many cases deleting the .la files just works. Complicating matters is that *.o files are binary object files -- pieces of binary executables and libraries that gcc creates from C and C++ source files, as a mid-stage, before combining them into the various libraries and executables they form. So... *.o object files should exist in the portage working dirs, for a short time until the package is fully created and merged, after which portage usually cleans them up; they should **NOT** exist in the library dirs. Correspondingly, *.so files will be the most common file in the library dirs, and would be what gcc was wanting. These particular files are the default pieces of code that gcc in executable linking mode automatically adds to your executables (not your shared libraries). They take care that your C system behaves as you expect it to. They do things such as setting up the system in such a way that main gets called correctly, libraries are initialised, etc. As this code is common for all C files, gcc just links in these files instead of generating them all the time. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpzyuWlE3ljn.pgp Description: PGP signature
Re: [gentoo-amd64] Re: KDE 3.5 and K3B
On Tuesday 21 February 2006 12:25, Duncan wrote: FWIW, I long since gave up on GNOME -- for the same reason Linus has: This 'users are idiots, and are confused by functionality' mentality of Gnome is a disease. If you think your users are idiots, only idiots will use it. I don't use Gnome, because in striving to be simple, it has long since reached the point where it simply doesn't do what I need it to do. Some background and additional opinion on the issue, in an article by Steven J. Vaughan-Nichols, at [1]. Or simply use Google's linux-specific search page at [2], type in linus gnome kde as your search terms, and take your pick of other coverage. It's worse, the gnome spirit even penetrated through to gnome. After spending several hours trying to find out how to make the gtk file save dialog be opened by default (I like seeing the directory I save stuff in, or setting it), I found it is not configurable. I finally ended up creating a patch to just collapse it (no interest in configuring it at this point). At least my firefox is useable again ;-). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpffKLHAGfnP.pgp Description: PGP signature
Re: [gentoo-amd64] Problems with 32 bit binaries
On Tuesday 21 February 2006 15:41, Marco Matthies wrote: Can you run /usr/lib32/openoffice/program/soffice.bin ? This is the program ultimately called, before setting up lots of environment vars etc. Maybe you should also consider running amd64 and only unmasking those packages where you really need a newer version, though I cannot guarantee this would spare you of this error, of course. I do have openoffice-bin-2.0.1, mozilla-firefox-1.5.0.1-r1 and mozilla-thunderbird-bin-1.5 running fine here on amd64, though. Also try specifying LC_ALL=C and unsetting all other language variables. From the error message it seems that you are using a non-english locale. That might be the cause. Openoffice has had it's share of problems with it. Perhaps it's now gtk's turn. It could however also be something as silly as a broken font that freetype chokes on. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp0XOHFpFcvD.pgp Description: PGP signature
Re: [gentoo-amd64] Re: Re: Fragmentation (Was: Re: Re: Re: Wow! KDE 3.5.1 Xorg 7.0 w/ Composite)
On Tuesday 14 February 2006 18:55, Richard Fish wrote: On 2/14/06, Peter Humphrey [EMAIL PROTECTED] wrote: I did that some time ago in a simple-minded fashion, but I've had to revise my layout somewhat. I had an ext3 partition solely for /usr/portage, and it was mounted on that node, but every emerge --sync deleted the /lost+found directory. I don't know how serious that is, but of course no-one likes to Losing lost+found on an ext3 filesystem is pretty harmless. It is the directory where fsck will attach files that still exist but were detached from the directory tree (i.e, 'lost'). Since this should *never* happen with ext3, there doesn't seem to be any point in lost+found. The one exception would be if you sometimes mount the filesystem as ext2. And even then, the only thing that happens is that those files which where reattached there are now deleted. As finding what file it actually is is hard, and in the case of a /usr/portage partition/disk also pointless, there is no harm whatsoever in losing this directory with a sync. Removing it does certainly not influence filesystem integrity. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpOjOehxcTS6.pgp Description: PGP signature
Re: [gentoo-amd64] Re: Fragmentation
On Wednesday 15 February 2006 05:01, Duncan wrote: By definition, /tmp and /var/tmp should be multi-boot combineable, and combineable between the two, as well (my /var/tmp is simply a symlink to /tmp, altho on a multi-human-user system, there are security issues one should consider before doing it -- yet another place to don't do it without some thought, first g), because the data is by definition temporary, which in this case is defined as not needing to survive a reboot. In principle they are multi-boot combinable. However /var/tmp is supposed to be cleaned less than /tmp. Preferably only when space is an issue. Portage for example stores things there like the ccache cache. While removing it will not cause any problems, the cache is then destroyed, so things go slower. /var/tmp is more meant for stuff that is temporary, but saves time, while /tmp is for stuff that is just temporary (often very shortly) and may be destroyed any time. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpQV1HSTT7H1.pgp Description: PGP signature
Re: [gentoo-amd64] Re: Re: Re: Wow! KDE 3.5.1 Xorg 7.0 w/ Composite
On Thursday 09 February 2006 01:17, Duncan wrote: Simon Stelling posted [EMAIL PROTECTED], excerpted below, on My thinking, which is possibly incorrect (your input appreciated), is that file-based scripts get pulled into cache the first time they are executed, and will remain there (with a gig of memory) pretty much until I'm done doing my upgrades. At the same time, they are simply in cache, not something in bash's memory, so if the memory is needed, it will be reclaimed. As well, after I'm done and on to other tasks, the cached commands will eventually be replaced by other data, if need be. Aliases (and bash-functions) are held in memory. That's not as flexible as cache in terms of being knocked out of memory if the memory is needed by other things. Sure, that memory may be flushed to disk-based swap, but that's disk based the same as the actual script files I'm using, so reading it back into main memory if it's faulted out will take something comparable to the time it'd take to read in the script file again anyway. That's little gain, with the additional overhead and therefore loss of having to manage the temp-copy in swapped memory, if it comes to that. Besides the fact that memory use is negligeable, you should keep into account that scripts (even oneliners) use one memory page per script. Aliasses however are stored by bash in a way that multiple aliases fit into one block of memory. And when the memory is needed, bash will be bumped out of memory too. But the idea is that those small aliasses will not actually need more memory. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpguVY0MYz6G.pgp Description: PGP signature
Re: [gentoo-amd64] Time zone funkiness
On Wednesday 01 February 2006 14:04, Mark Haney wrote: For some reason my clock in KDE has gone screwy. I have it set in BIOS for EST (I'm in NC), yet in KDE the zone is set to UTC. WHen I change it to EST, the clock changes from 8:03 (current time) to 1:03. I can't seem to set it back correctly, even using ntp. Has anyone else seen this problem? Is your timezone properly specified by /etc/localtime? And did you specify in the boot scripts that your system is not utc based. There is also a kernel option to say that the system clock runs UTC. If you don't run UTC, you obviously shouldn't use the option. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgppJkFxjc3Mc.pgp Description: PGP signature
Re: [gentoo-amd64] ~amd64 vs. ~x86
On Tuesday 29 November 2005 12:39, Mark Knecht wrote:
Yes, I hope so. Since I never build with ACCEPT_KEYWORDS=~x86 but
rather put all keywords in package.keywords, I've rebuilt almost all
the ~x86 applications with ~amd64. I have not done the --emptytree
rebuild yet and may not for the next week or two just to see how
things go.
Rebuilding is not necessary. What would probably be a better strategy than
an --emptytree is the following:
find /var/db/pkg -mindepth 3 -maxdepth 3 -name *.ebuild -exec egrep -H \
^KEYWORDS {} \; |egrep -v [^-]amd64
This will find you all ebuilds that do not have any amd64 keywords. You
should try to merge newer versions to see whether the new version is
supported. If not, they are likely not to work. If the outputted keywords
include -amd64 they WILL not work. If they do work and are not marked for
amd64 then you might consider to report them.
Paul
ps. Please remember, keywords do not change packages or the build process.
They are only used to determine whether the package should be provided on
that architecture/testing level.
--
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net
pgpWkT2CQHjs2.pgp
Description: PGP signature
Re: [gentoo-amd64] Re: starting services
On Friday 25 November 2005 00:16, Duncan wrote: Paul de Vrieze posted [EMAIL PROTECTED], excerpted below, on Thu, 24 Nov 2005 20:12:08 +0100: On Thursday 24 November 2005 13:18, DR GM SEDDON wrote [snipped] And btw. You might want to change your username in your email client. It now looks like you are some kind of nigerian trying to rid me of my money. I had noticed that too, but wasn't going to say anything, because he seems nice enough, and one can't be blamed for their name (altho on the net, 'handles are as common as names, and handles are chosen). It is more the uppercase character of it. And the title (although I'm certain he earned it). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp6V6gFwX7CF.pgp Description: PGP signature
Re: [gentoo-amd64] Crossover Office - icons in Quicken corrupted
On Monday 07 November 2005 16:35, Mark Knecht wrote: Hello, I loaded up Crossover Office Ver. 5.0 on my AMD64 machine so that I could move Quicken from Windows to Linux. It seems to be working OK, so far, except that all icons in the program show up as only black while blocks. They still looks sort of like the right icons. THey are readable, not just boxes, but I cannot so far get them to display in color. Any ideas what I might try? Update X, it's a known issue. Apparently the fix is not in stable yet, so you should probably use a testing version. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp3jMqHa7qH4.pgp Description: PGP signature
Re: [gentoo-amd64] Re: Re: modules
On Saturday 05 November 2005 03:12, Ian Hastie wrote: On Fri, 04 Nov 2005 13:35:19 -0700 Which is true unless you run a display manager and log in through that. The only hard and fast rule of Linux is that there are no hard and fast rules. The load time of the display manager is last in the boot sequence. In that it is actually not that different from duncan's view. Of course without the graphics module you cannot actually use the binary driver. In that sense it must be present. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpqNgm19vLJR.pgp Description: PGP signature
Re: [gentoo-amd64] windowmaker and kdm not working
On Monday 07 November 2005 14:46, DR GM SEDDON wrote: Hello, My Gentoo system graphics work when I s'tartx' However, I defined 'wmaker' as my default in '/etc/rc.conf'. When I startx I get a windowmanager similar to the windowmaker I am used to but instead of the 3 icons on the top right and the desktopswitcher on the left I only have a clock. Is this correct? Also, I have set my default runlevel to 5 in '/etc/inittab' and chose kdm as my prefered login method. But when I boot I always get a console login. Kdm runs if I btype 'kdm'. It doesn't give me the option of windowmaker and the default won't start anything. Can anyone help? The location of some windowmaker applications apparently changed some while ago. Perhaps your configuration files point to the wrong locations. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgprD18i29PJH.pgp Description: PGP signature
Re: [gentoo-amd64] Re: OFF-TOPIC but ... you will lough !!!
On Friday 04 November 2005 09:06, Taka John Brunkhorst wrote: thx Nuitari for the error msg :) its funny that MS wont give out exact err msg for that... The worst part of it is that I believe that there are methods that will allow you to make a file with such an illegal name (the API is not consistent). Of course the file then becomes hard to use or delete ;-). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpJqdjJ6XW6C.pgp Description: PGP signature
Re: [gentoo-amd64] OpenOffice.org 2.0
On Tuesday 25 October 2005 01:22, Neil Stone wrote: [blackdown-jre-1.4.2.02] Blackdown JRE 1.4.2.02 (/etc/env.d/java/20blackdown-jre-1.4.2.02) [sun-jre-bin-1.5.0.05] Sun JRE 1.5.0.05 (/etc/env.d/java/20sun-jre-bin-1.5.0.05) [blackdown-jdk-1.4.2.02] Blackdown JDK 1.4.2.02 (/etc/env.d/java/20blackdown-jdk-1.4.2.02) * As jdk's also include a jre you might want to drop blackdown-jre. Paul -- Paul de Vrieze Researcher Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpDxK9X0lrcw.pgp Description: PGP signature
Re: [gentoo-amd64] OpenOffice.org 2.0
On Tuesday 25 October 2005 09:00, Neil Stone wrote: Stuart Haas wrote: /opt/jre1.5.0_04 That's it. OO reports the vendor and version. Is it not working at all or is there a specific thing you use to test it? Stuart Using what path ? when i provided the path to blackdown jre etc, the compiled one(s), it didn't work at all... Now that i have the 32bit version, it seems happy... It uses the jre as library. As such one can not mix 32bit (ooffice) and 64bit code (jre) and it doesn't work. With a 32bit java it should work (as reported). Paul -- Paul de Vrieze Researcher Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpabAVZF4P0l.pgp Description: PGP signature
Re: [gentoo-amd64] openoffice-bin toolbar icons
On Friday 21 October 2005 09:22, Raffaele BELARDI wrote: I had the same problem with openoffice 1.1.4 some months ago, I solved it as stated here: http://forums.gentoo.org/viewtopic-t-365639-highlight-openoffice+icons. html Yesterday I upgraded the system (incl. openoffice and xorg), icons are ok even though the patch mentioned in the forum was not needed, so if you have the problem with a recent ebuild it might be something else. This issue is/was caused by a bug in cvs xorg-x11 that was backported to =xorg-x11-6.8.2-r2 After a long time it has been diagnosed, and fed upstream. The fix is also available in our patchset. This problem actually also caused problems with wine and vnc. Paul -- Paul de Vrieze Researcher Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpOD3h7hCiv7.pgp Description: PGP signature
Re: [gentoo-amd64] System died going from 2005.0 to 2005.1
On Sunday 09 October 2005 05:03, Tres Melton wrote: On Sat, 2005-10-08 at 16:20 -0600, [EMAIL PROTECTED] wrote: My system has developed serious problems related to the emul libs. The advice given as a reply to my bug has made the system impossible to upgrade using emerge. It is possible the problem dates back to the 2004.3-2005.0 upgrade, I don't know. Is there a way to build a from scratch 2005.1 system over the net without having to download and boot from a CD? Will it leave my user directories alone? The installation docs assume that you don't have a runnig gentoo system and start with a boot CD. I wouldn't do this without a developer telling you it is going to work but Get a bootable Linux CD and boot from it and unzip the portage snapshot and stage tarball onto your system as the manual says. Then sync, bootstrap, and emerge -e world. That should get you back to where you are functional. Just use the newest 2005.1 stage on the install. It should get you workable. But if you do this, you should backup your /etc directory above all. tar will hapilly overwrite whatever you put there, and you'd like to keep that. What I like to do is the following: Create a directory somewhere on a partition with enough space. Unpack the stage3 tarball there. (or stage1 or 2 depending on preference). Chroot into the directory. Find the package that is causing the pain (likely gcc, glibc, binutils) create binary packages of those using emerge --buildpkg. Then copy those binary packages to the normal location in your system (out of the chroot) and merge them (you can just point to the .tbz2 files even though portage warns you against it, as binary packages know their category). Then you've got a good chance to get your system working again. You could even do this with the whole system. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpqRYvO13M7a.pgp Description: PGP signature
Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)
On Wednesday 21 September 2005 02:15, Matt Randolph wrote: Tres Melton wrote: On Tue, 2005-09-20 at 20:23 +0200, Paul de Vrieze wrote: On Tuesday 20 September 2005 19:47, Daniel Gryniewicz wrote: I do this: alias emerge='sudo schedtool -B -e /usr/bin/emerge' Obviously the sudo is unnecessary if you're root. You can use similar aliases to run things as SCHED_ISO, which I do for mplayer, for example. Or, more easilly, set the nicelevel to -19 (the lowest) which also amounts to batch scheduling. Nicelevel -19 is treated as batch by default by the 2.6 kernel. Erm, isn't that backwards? The lowest priority is 20. The highest is -19. You have to be root for any priority 0. Paul I would guess that Paul used the word lowest in a strictly numerical sense, rather than priority-wise. By the way, my nice has a range of -20 to 19. Nah, I made a mistake between -19 and 19. Of course it should be 19. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpQ1sAvuGny6.pgp Description: PGP signature
Re: [gentoo-amd64] Re: kernel.org vs. Gentoo-64 bit kernels (xruns)
On Tuesday 20 September 2005 14:25, Mark Knecht wrote: On 9/20/05, Duncan [EMAIL PROTECTED] wrote: I'm not familiar with the term xrun, so this may be entirely off the wall, but have you confirmed the hard drive is running DMA? If your chipset or SATA drivers are wrong, and your hard drive is having to run in legacy interrupt mode instead of DMA mode, it *WILL* destroy latency and generally make the system unusable for any sort of real-time work at all, regardless of the other kernel patches applied. So... in addition to checking the network drivers, investigate the hard drive and chipset I/O drivers as well, and confirm you ARE running DMA mode. Thanks, yes, DMA is running, as far as I can tell. hdparm -tT returns numbers that are 50MB/S. xruns are a term specific to the Jack server (jack-audio-connection-kit) that tell us whether we've had and overrun or an underrun. It's would be off topic to go deeply into how Jack operates when talking to sound cards, but take it to mean something bad has happened with real-time audio data. Nah, it's more alsa specific. What soundcard do you use? Some soundcards are more crappy than others (especially onboard ones). I guess it should support DMA as even the soundblaster pro did so. Soundcards do however provide various levels of hardware accelleration. Interestingly Jack runs from memory so hard drive performance should not cause major problems unless it's not interruptable in a more or less real-time way. On my Gentoo 32-bit machines (using Via and ATI chipsets) I've not had to install any real-time patches and can still run reliable at sub-2mS latencies. On those machines I can do pretty much anything, browse the web with firefox, do and emerge sync, etc., and I get no xruns. On this AMD64/NForce4 machine and emerge sync causes xruns immediately, indicating the sound card is getting starved for data. Good chance the soundcard buffer is smaller or the driver is crappy. You could try to take the soundcard from the old machine and put it in the new one. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpSZxHi5nfhS.pgp Description: PGP signature
Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)
On Tuesday 20 September 2005 19:47, Daniel Gryniewicz wrote: I do this: alias emerge='sudo schedtool -B -e /usr/bin/emerge' Obviously the sudo is unnecessary if you're root. You can use similar aliases to run things as SCHED_ISO, which I do for mplayer, for example. Or, more easilly, set the nicelevel to -19 (the lowest) which also amounts to batch scheduling. Nicelevel -19 is treated as batch by default by the 2.6 kernel. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpXIZis5aYuf.pgp Description: PGP signature
Re: [gentoo-amd64] kernel.org vs. Gentoo-64 bit kernels (xruns)
On Tuesday 20 September 2005 18:01, Mark Knecht wrote: On 9/20/05, Billy Holmes [EMAIL PROTECTED] wrote: Mark Knecht wrote: Thanks. Yes, I've run ck-sources a few times in the past but not had when you run with ck-sources, others have found it's best to use SCHED_ISO rather than SCHED_NORM (ck was patched with ISO support) - which is like real time scheduling for users processes. From what I hear it's easier to setup than the rt limits stuff (ie. it's automatic). -- gentoo-amd64@gentoo.org mailing list Billy, Hey, thanks for the tip. IT would be great to see this run better. I'm looking around in the kernel and haven't foudn SCHED_ISO vs. SCHED_NORM. For the preemption model I chose 'Low Latency Desktop'. In the .config file I see these entries: # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y Am I supposed to choose one at the command line when booting? Or can I change schedulers once the kernel is running, through /proc or something? These ones are schedulers for harddisk (and other IO) access. As such they are not related to the task scheduling that SCHED_ISO is about. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpJjIJNLWKl4.pgp Description: PGP signature
Re: [gentoo-amd64] Video server for mac clients
On Monday 19 September 2005 18:24, P.V.Anthony wrote: Thanks to both of your advice. Yes it is true that I want to mount the remote server as local to mount/edit the videos store on it. From your reply, I understand that NFS is the fastest. Any advice on the resource fork files that are with Mac files? Will the resource files get transfered across? Does NFS see the resource files? No, NFS does not see forks, unless the client on the mac makes a translation of forks to NFS. In any case to use your amd64 based videoserver you must use a linux based video processing application either (at least for the server part). It doesn't make much sense to use such a beefy machine only for storing datafiles does it? Even if there are native mac clients, your applications will not be able to use resource forks to work with a linux server. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpdPMLZW5koZ.pgp Description: PGP signature
Re: [gentoo-amd64] weather.com video - realplayer within firefox-bin
On Sunday 11 September 2005 12:28, Peter Humphrey wrote: Simon Stelling wrote: nsplugin is a use flag to enable the firefox (ns=netscape) plugin, so just recompile with that use flag set $ sudo emerge realplayer Calculating dependencies ...done! emerge (1 of 1) media-video/realplayer-10.0.5 to / Downloading https://helixcommunity.org/download.php/1343/RealPlayer-10.0.5.756-20050513 .i586.rpm --10:24:37-- https://helixcommunity.org/download.php/1343/RealPlayer-10.0.5.756-20050513 .i586.rpm = `/usr/portage/distfiles/RealPlayer-10.0.5.756-20050513.i586.rpm' Resolving helixcommunity.org... 207.188.25.135 Connecting to helixcommunity.org|207.188.25.135|:443... connected. ERROR: Certificate verification error for helixcommunity.org: unable to get local issuer certificate To connect to helixcommunity.org insecurely, use `--no-check-certificate'. Unable to establish SSL connection. !!! Couldn't download RealPlayer-10.0.5.756-20050513.i586.rpm. Aborting. Where should I add the --no-check-certificate parameter? I.e., to what process? And why is emerge not using my proxy server, as it does normally? You could add it to FETCHCOMMAND and RESUMECOMMAND. The default values should be retrieved from /etc/make.globals. Port 443 is the https port. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpcp5E9yFQ48.pgp Description: PGP signature
Re: [gentoo-amd64] portage/emerge and rebooting questions
On Saturday 25 June 2005 01:21, Tres Melton wrote: Another question, at what point is a reboot required? I know that emerging a new kernel requires a reboot (at least to use it) but what about some of the other packages? Take glibc for instance, almost everything links to some part of it (except statically linked programs) so if you update that should you restart? It seems that the file locking and linking in the kernel should keep the old stuff in memory pages as long as it is being referenced by something but everything new should just use the new libraries. This is correct. Problems are going to arise with things like static variables (ones that have only one copy in memory regardless of the number of times called). Is there one copy of the variable for the library, one copy of the variable for each program that links to the library, one copy of the variable for each instance of each program, or one copy for each user? Well... The short answer is that it is per library code. For the kernel two different files even with the same name are different libraries alltogether, and do not share anything. What about dynamically allocated internal data structures? Are they shared (w/ shared memory) between the two different library versions? Does each library (old new) update their own copy blissfully unaware of the existence of the other? Many libraries exist on a Gentoo (and other GNU/Linux) system, I only picked glibc here because it is so high profile. In general datastructures are not shared between library instances. Normally libraries only cause code to be shared, not data. What about the less obvious programs like X, Gnome, Corba/orbit and others (listed from less to more obscure) that may be used by currently running programs? What if spam-assassin is the spam filtering backend for your mail reader. If that is upgraded then do you need to restart your mail reader or is the spam filter started each time it is needed? If bash gets upgraded does that mean that everything running from a script needs restarted? startx runs a script that doesn't finish until you exit X. Would startx have the rest interpreted with the newer version of bash of updated from within X? Spamassassin itself is restarted every time around. However it's resident counterpard (spamd) must be restarted. In short all services living in /etc/init.d should be restarted when their code changed. In general the only things that could create the havoc that would mean that a reboot is necessary is when certain resident parts that cannot be restarted use live datastructures on the filesystem that are incompatibly changed. As everything can be restarted (even init can be told to restart itself) only kernel changes should need reboots. In some cases however it is easier to reboot to not needing to reboot lots of programs. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgphHdRcWQUmJ.pgp Description: PGP signature
Re: [gentoo-amd64] Can't set FQDN
On Thursday 23 June 2005 17:38, Francisco Perez wrote: I've had my AMD 64 box running for a few days, but I just noticed that at the login screen it says Welcome to GOETHALS.UNKNOWN_DOMAIN. Right before that though, it says Setting DNSDOMAINNAME to albrookdata.com. I've checked my resolv.conf file as well as my /etc/hosts, /etc/conf.d/domainname, and /etc/conf.d/hostname and they all seem ok. Here is the contents of the files: The hostname in /etc/conf.d/hostname should include the domain. Then things work. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpwWI16ZwrPm.pgp Description: PGP signature
Re: [gentoo-amd64] error installing jsdk 5.0 (new thread!)
On Tuesday 21 June 2005 16:53, Mauro Venanzi wrote: so in your opinion shuold I use 1.4 version of sun-jdk? That version is not 64 bit. So you should probably use the blackdown 64bit 1.4 jdk. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpquw8NUUFjj.pgp Description: PGP signature
Re: [gentoo-amd64] DSSI build problem
On Sunday 05 June 2005 15:50, Michal eravk wrote:
src_compile() {
#dssi (0.9) does not provide a configure script
if use fluidsynth; then
einfo Building against fluidsynth sources
in ${FLUID}
einfo You must have the same version of
fluidsynth library
installed export FLUID
fi
emake || die emake failed
}
This test seems rather silly. It will allways fail if the fluidsynth useflag
is specified. I guess the ebuild is written wrongly.
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net
pgpQ8HIKqxVpb.pgp
Description: PGP signature
Re: [gentoo-amd64] I've joined the amd64 herd/team
On Wednesday 25 May 2005 22:21, Dan Armak wrote: Hello everyone, I'm a longtime member of the kde team and now I've joined the amd64 team. That's about all I had to say... Just to let you know you'll be seeing more amd64 keywords on kde-related stuff now. Oh, and 3.4.1 will probably be released sometime next week, and hopefully will be given stable keywords quickly. Welcome to the happy club of amd64 owners ;-) Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpVpkZlI8Y9V.pgp Description: PGP signature
Re: [gentoo-amd64] Firefox and 32bit
On Sunday 15 May 2005 04:24, Daniel Gryniewicz wrote: On Sun, 2005-05-15 at 04:01 +0200, Luigi Pinna wrote: Hello! I want to compile firefox as 32 bit program to use flash... I tried to emerge it with the command CFLAGS=-m32 emerge firefox but it doesn't work and I cannot use flash... What must I do? Thanks, Luigi You can't currently build 32-bit apps from portage. However, firefox-bin is already 32-bit, so the solution is to emerge firefox-bin If you know what you're doing and have all dependencies available in 32 bit (if the -bin version works you probably do). You could use ABI=x86 and compiling should then happen in 32bit. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp5YIRVg4bAB.pgp Description: PGP signature
Re: [gentoo-amd64] Firefox and 32bit
On Monday 16 May 2005 03:00, Qian Qiao wrote: However, compiling things into 32bit is another thing. Correct me if I'm wrong, but you need to setup a crosscompile environment for such purpose. A gentoo dev ( sorry I can't remember who) wrote a nice set of cross compiling notes, if you dig the list archive, you'll find it. Not exactly. Crosscompiling is when the architecture on which the compiler runs can not run the binaries of the architecture you are going to run on. This makes configure and build scripts a lot more complicated. In case of amd64 and x86 this is not the case. With the newest gcc-wrapper one can even select the bitness to use based on the ABI environment variable. The main issue with compiling 32bit by portage is that it has no separate dep tracking for different bitnesses. Further the packages have not been checked on whether they would support automatic ABI choice. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpDhkmOSHVKB.pgp Description: PGP signature
Re: [gentoo-amd64] Re: gcc-4.0.1-beta20050514 emerges glibc-2.3.5.20050421, now
On Monday 16 May 2005 15:23, Duncan wrote: I don't know what it is, then, but it's a /dramatic/ improvement, that's for sure. AFAIK, our KDE-3.4 ebuilds turned off the visibility stuff in the Gentoo-gcc-3.4 backports, however, at least at some point. Maybe that's why I haven't experienced issues, and /did/ experience such a speed improvement. You just didn't try kasteroids ;-) It segfaults on keypress with the visibility stuff enabled. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpqeSYdJaLqZ.pgp Description: PGP signature
Re: [gentoo-amd64] Re: Firefox and 32bit
On Thursday 19 May 2005 15:44, Duncan wrote: Paul de Vrieze posted [EMAIL PROTECTED], excerpted below, on Thu, 19 May 2005 09:25:12 +0200: With the newest gcc-wrapper one can even select the bitness to use based on the ABI environment variable. The main issue with compiling 32bit by portage is that it has no separate dep tracking for different bitnesses. Hmm... If one wanted to back-up his portage database, set ABI=what?, 32bit, just 32, what?, determine the dependencies and (r)emerge them as necessary, then emerge a 32-bit app, what would one back up (/var/db/* ?), should checking the deps in the ebuilds suffice for manual dep checks, and just what would the ABI settings be? After the 32-bit emerges are complete, one would presumably restore the portage db backup so as not to disturb the 64-bit dependencies, then keep a written list of the 32-bit packages emerged for dependency tracking there. You'd better use two fully paralel trees and make some kind of emerge32 alias for portage that is changed to get the 32 bit tree. Most of the supported api's can be found in the glibc ebuild. For athlon64/opteron/xeon emt systems they are: amd64 for 64 bit and x86 for 32 bit. I guess what I'm asking is how long until there's an at least mostly working alpha/beta/test-version out there I can actually play with? Not that I'm trying to rush things before they are ready, _certainly_, but some hint as to when it'll be ready for general testing, tomorrow or two months from now (still assuming it's slated for 2005.1 and therefore a test version couldn't be /too/ far beyond two months), would be nice. Or, if it's beginning to look like it'll be 2006.0 instead, knowing that would be nice, too. (See, as I said, I'm NOT trying to rush things before they are ready, not least because I'm not talented enough to be in there helping to code it myself, which is quite different from saying I'd be of no use in /testing/. g) Don't know. Why don't you help out ;-) Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpjFDLpOeaRL.pgp Description: PGP signature
Re: [gentoo-amd64] skype missing 32bit libdbus-1.so.0
On Wednesday 27 April 2005 11:16, Mark Constable wrote: I'm at a loss to understand what's going on here with a non-multilib 2004.3 system. Any suggestions ? # ldd /opt/skype/skype.bin linux-gate.so.1 = (0xe000) libdbus-1.so.0 = not found libqt-mt.so.3 = /emul/linux/x86/usr/qt/3/lib/libqt-mt.so.3 (0x55594000) libXext.so.6 = /usr/lib32/libXext.so.6 (0x55c72000) libX11.so.6 = /usr/lib32/libX11.so.6 (0x55c8) ... I've tried re-emerging dbus and all the emul libs. Apparently skype needs dbus. Dbus is a interprocess communication library. If it's not offered by one of the emul libraries you can file a bug, or get the library from another place such as extract it from an rpm or get it from a chroot system. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpMRdB7nPBZ7.pgp Description: PGP signature
