Re: [gentoo-user] Help with world update
Rafael Fernández López schreef: Hello, I am running a emerge -u world and there is a package (realplayer) that keeps failing the build due to an error in package retrieval. Well, give realplayer a try, and see if it is installed in any way: # equery list -p realplayer You'll see in a list if any version is installed. My first question is why is portage trying to emerge this package as I do not have it installed in the first place ( I had it once a while ago, then it was unmerged) and my second is how tell portage not to emerge the package. Just edit /etc/portage/package.mask (as root) and add this line: media-video/realplayer Save the changes and that's it. Great idea, Rafael, but that may break other updates, if any of them (like xmms, mplayer, xine, etc) use the real USE flag which is probably what's dragging in realplayer in the first place. As you later suggested, using the --verbose option is /always/ wise when doing an emerge -uD world (myself, I use emerge -uaDtv world), in order to get an idea of what USE flags are being enabled (or not), so that you have the opportunity to make changes and keep unwanted packages from being emerged as optional dependencies (or make sure that wanted packages are emerged as optional dependencies). HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Optical mouse lights off on kernel 2.6.14 but works on kernel 2.4.30
Raphael Melo de Oliveira Bastos Sales schreef: I had legacy /dev/psaux on. Besides, it doesn't explain why the lights go off even outside X. Perhaps I could try to disable this option and let /dev/input/mice be the sole device node for the mouse... OK, it's time then for the stupid questions: You said the mouse was new. Is it rechargeable? Is it fully charged, or are the batteries new? Is this perhaps a feature of the mouse (the light goes off when it thinks it's idle) or does it have some other 'quirk' that requires it to have specific conditions under which it works properly (non-reflective desk, no other nearby magnetic devices, etc)? Certainly my optical mouse needs a mousepad (a dull, non-reflective one-- it doesn't work at all on my white desk, for example, as it's not only white (a bit too reflective), but also an incompatible surface in some way (too rough, I think). And so on, and so on... HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] problems emergeing (through winxp shared connection)
Nacho schreef: Hi, I'm trying to emerge kde-meta, but i get stuck here (the error reproduces with emerge kde-meta): -- gentoo ~ # emerge kde-meta Calculating dependencies ...done! emerge (1 of 278) dev-libs/glib-2.6.3 to / Resuming download... Downloading http://distfiles.gentoo.org/distfiles/glib-2.6.3.tar.bz2 --12:15:45-- http://distfiles.gentoo.org/distfiles/glib-2.6.3.tar.bz2 = `/usr/portage/distfiles/glib-2.6.3.tar.bz2' Resolving distfiles.gentoo.org... 64.50.238.52, 64.50.236.52, 216.165.129.135, ... Connecting to distfiles.gentoo.org[64.50.238.52]:80... connected. HTTP request sent, awaiting response... 404 Not Found The file is already fully retrieved; nothing to do. Resuming download... Downloading http://distro.ibiblio.org/pub/Linux/distributions/gentoo/distfiles/glib-2.6.3.tar.bz2 --12:15:46-- http://distro.ibiblio.org/pub/Linux/distributions/gentoo/distfiles/glib-2.6.3.tar.bz2 = `/usr/portage/distfiles/glib-2.6.3.tar.bz2' Resolving distro.ibiblio.org... 152.2.210.109 Connecting to distro.ibiblio.org[152.2.210.109]:80... connected. HTTP request sent, awaiting response... 404 Not Found The file is already fully retrieved; nothing to do. Resuming download... Downloading ftp://ftp.gtk.org/pub/gtk/v2.6/glib-2.6.3.tar.bz2 --12:15:47-- ftp://ftp.gtk.org/pub/gtk/v2.6/glib-2.6.3.tar.bz2 = `/usr/portage/distfiles/glib-2.6.3.tar.bz2' Resolving ftp.gtk.org... 128.32.112.248 Connecting to ftp.gtk.org[128.32.112.248]:21... connected. Logging in as anonymous ... Exiting on signal 2 - (I abort manually because it hangs up) I'm acceding Inet through a winxp shared connection (w/nat) (NOT a proxy, so http_proxy is unset), but there wasn't any problem with other emergeings or apps. (for example, i can ping, navigate, and emerge other packages too) what can i do? When i look at /usr/portage/distfiles there is a glib-2.6.3.ebuild so, why is emerge trying to download it? Sorry I don't know why your download is all borked (try changing mirrors)-- but I can tell you that 1). Portage is not trying to download an ebuild when you're actually emerging a program; it's trying to download the source tarball for that program in order to compile it; 2) Any ebuild should not be found in /usr/portage/distfiles-- it should be found in /usr/portage/cag-egory/package_name. What you find in /usr/portage/distfiles are the tarballs containing the downloaded source code. So if you've put an ebuild in /usr/portage/distfiles, get rid of it. It has no business being in that particular folder. is there a manual way to install this package and in general any package that can`t be emerged traditionally? Yes, download the source code tarball manually (in this case, glib-2.6.3.tar.bz2), and place it in /usr/portage/distfiles. Portage won't try to download the tarball if it finds that its already been downloaded. Hope this helps somewhat, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] straggling with paper size
Joseph schreef:
Please excuse me for interrupting when I know nothing about this issue
at all, but:
I keep noticing that latex seems to supercede divps
Sql-Ledger is using latex forms to generate invoices. So to
my understanding the program will be using dvips to convert
latex to postscript and send it directly to printer, am I
right?
looking at the configuration file in sql-ledger it is looking
for: latex, dvips or pdflatex, but making any changes to dvips
makes no difference.
if ($self-{format} eq 'postscript') { system(latex
--interaction=nonstopmode $self-{tmpfile} $self-{tmpfile}.err);
$self-error($self-cleanup) if ($?);
$self-{tmpfile} =~ s/tex$/dvi/;
system(dvips $self-{tmpfile} -o -q /dev/null);
$self-error($self-cleanup.dvips : $!) if ($?); $self-{tmpfile}
=~ s/dvi$/ps/; } if ($self-{format} eq 'pdf') { system(pdflatex
--interaction=nonstopmode $self-{tmpfile} $self-{tmpfile}.err);
$self-error($self-cleanup) if ($?); $self-{tmpfile} =~
s/tex$/pdf/; }
So it seems to me that rather than adjusting the configuration of divps,
we (meaning you, of course) should at least *look* at the
configuration of latex-- what paper size is /it/ set to??
HTH,
Holly
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [SOLVED] straggling with paper size
Joseph schreef: SOLVED, SOLVED! Believe me or not, I'm not sure what I did. Don't care (since I don't know anything about this anyway) ;-) ; I'm just happy for you. Congratulations Persistence pays (as does restarting a server or two, apparently). :-D Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Need drive space, what to delete?
Dale schreef: LOL It helped a little bit, but not much. swifty / # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda6 3564108 3505584 58524 99% / udev12738880127308 1% /dev /dev/hda148312 37412 10900 78% /boot none 127388 0127388 0% /dev/shm swifty / # Any more ideas? I would hate to have to remove KDE from that thing. OK, ideas 1 (Traditional): delete the contents of /usr/portage/distfiles. These are the downloaded tarballs of the programs you have previously installed. Since they are already installed, the tarballs are no longer needed unless you reinstall the same program, soeleting these files only means that if you want to reinstall the same version of the same program, you'd have to download the tarball again. However, since you're on dialup, this might be a problem for you. So I would suggest that you burn any tarballs you consider 'precious' or difficult to acquire to CD or DVD (do you have a CD or DVD burner?) and *then* delete the contents of /usr/portage/distfiles. If you need to reinstall something that's difficult to download, you can pop the item back into /distfiles/ from the backup. I commonly do this for the Neverwinter Nights data tarball, which is 1GB of tarball, and I not only don't really want to be downloading that again (even on my 8Mbit ADSL line) when I want to reinstall NWN, but I don't need a gig of space being eaten on my / partiton either. The file doesn't change, so it's safe enough. 2 (Traditional, little-known): Check /var/tmp/portage. There is a directory for every compile you've done, and normally (when the compile completes successfully) the temp compilation files are replaced by a tiny .keep file. If the compile fails, however, the compilation files remain, taking up space-- sometimes a lot of space. Find the directories that take up more than a few KB and delete them. The program isn't installed anyway (since the compilation failed), so no harm done. 3 (Tough Love): You don't want to get rid of KDE, but there's a good chance you don't need all of KDE-- you might consider trimming it. This is the gigantic benefit of the split ebuilds; you don't have to have *all* of KDE, just the parts you need. You perhaps installed KOffice-- but do you actually need the spreadsheet and the presentation whatever? Uninstall KOffice and reinstall just KWord. Do you need the accessibility functions?The educational programs? The PIM, toys, and webdev programs? Etc, etc. If you have kde-meta installed, you might want to consider unmerging that, re-emerging just the split ebuilds for the KDE programs you use, then emerge depclean-ing the rest. 4. (Tough Love 1a): Do the above and switch to a 'lighter' WM-- you can perfectly well use KDE applications while using... oh, IceWM or Openbox or Fvwm-Crystal. I personally don't like KDE or most of its programs, but there are a few KDE programs I do use under Fvwm-Crystal (Krusader, K3b, KView). While of course this means I must have kdelibs, kdebase, and QT installed (and the Control Center to manage the KDE backend quickly for those few times its necessary), I don't *use* Konqueror, so I don't need it, and I don't have to have a gigantic KDE backend installed for no purpose (on my system). Using -kde in your USE flags can often eliminate some cruft when installing such programs (because I don't use the KDE backend for the applications, I don't need the KDE setup tool for K3b, or the linkages that optional KDE support creates when installing Krusader). Think about it. 5 (Tough Love 2): Consider not keeping every d*mn thing on your computer's drive all the time. Back lesser-used personal data files off the disk (twice, if you're thorough) and *delete them from the disk*. If you need the file, copy it back from the CD-- or use it from the CD, if it's like a movie or something. The originals don't have to be sitting there taking up space just because. And you should back up anyway (it's good policy). 6 (External Tools): Consider emerging/using /kgraphspace/ (if you must have a KDE application), or /xdiskusage/ to see what is actually taking up the space. Once you have located what directories contain files that are taking up too much space, you can determine what to do with them (delete, back up, whatever). Hope this helps, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Need drive space, what to delete?
Dale schreef: Holly Bostick wrote: 3 (Tough Love): You don't want to get rid of KDE, but there's a good chance you don't need all of KDE-- you might consider trimming it. I plan to let my mom use it if I move so I hope I can keep it all. Now, see, that's where you lose me because your mom *may* use the computer if you move, you want to keep every possibility of KDE available for her? What is your mother actually likely to use the computer for, if she in fact does use it (which you don't even know if she will)? If she's never heard of an MP3, and isn't likely to download any, she doesn't *need* amaroK/juK/noatun (kdemultimedia-meta), no matter how nice it is. Kscd (for audio CDs) will be fine. If she doesn't have any DVDs or download films, (k)mplayer and xine and its ilk are a waste of space. Is she really likely to change her wallpaper or window decoration a lot (or ever)? If not, kde-artwork is pretty pointless. Is she likely to administer users or create cron jobs? No? So much for kdeadmin-meta. Has she a digital camera or video camera? A fax? Does she edit graphics files? Take screenshots of her desktop? No? Well then The Gimp and kdegrapics-meta doesn't have to be there either. Does she do a lot of document editing? Of MSWord documents? Does she really need OO.o, or even KWord for this? Might abiword not be sufficient, or even kedit or kate? You see where I'm going with this. I admit that I'm a bit hot on this issue; my bf's mother was recently forced to accept a computer by her other son (hand-me-down). She does not know anything about computers, and in fact doesn't want this one (but everyone is figuring that she needs one, and once she gets used to it and sees the capabilities, she'll love it. I'm not so sure myself, but it could go that way, of course). At her recent birthday party, she was complaining that all of her friends and family (who are experienced, average users) were giving her advice like you need to get cable internet, and that sort of thing-- while she's trying to master Windows Solitaire *in order to* *learn how to use the mouse*. We have a printer (hand-me-down) to give her, but what's the rush when she doesn't know what a text file (or a *.doc file) is, or what programs are needed to open or view them-- in fact, she doesn't have any text documents-- much less a need to print said non-existent documents (which if needed she could create in Notepad just as well as OO.o Writer, and probably easier). I'm also hot on this issue because this was always my major complaint about Windows. Microsoft, like any company, wants to create a positive experience for the users of their product, so that the user will continue to buy their product. That's normal. What isn't normal, imo, is their design philosophy-- that the only (or most successful) way to ensure a positive user experience is to control the user's environment so severely that it only encompasses those areas that Microsoft is guaranteed to deliver a positive experience in. So MSOffice saves files in a proprietary format that MSOffice reads best. Optimization of webpages created in Frontpage (free with MSOffice) display perfectly in IE, and poorly in Mozilla. *.wmv files are beneficial to use due to the compression, but are hard to play in media players that are not WMP. And the list goes on-- though I'm still not sure why the \My * folders (Documents, Media, Music, etc) are placed on the C:\ drive by default when the most common way to fix Windows is to reformat and reinstall (thereby deleting your C:\My * files). The reason that I will not use Windows is that *the ability to control* *my environment is an essential part of a positive user experience* for me. Therefore I must object to your efforts to create a positive user experience for your mother by controlling her environment excessively. This position is supported by the fact that you *cannot* provide every single bell-and-whistle available-- you simply don't have the disk space. So for you, if you want to encourage your mother (and the greatest encouragement is a positive user experience), the best way to do that is to customize the PC to her actual needs, rather than trying to cover every possible eventuality of what you *think* she *might* want *someday*. I'd say, strip the system down to the bare minimum of what she's likely to need daily (and what the system can reasonably support to run quickly, since a slow computer is not part of a positive user experience), and let her get comfortable with that-- if she then expands her horizons and needs more functionality, she can ask you (mother-son bonding, an added benefit), or she can learn about Gentoo at her own pace and have the thrill of accomplishment just like you've had. Just my 5 Euros, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Installing old version of a package
Leandro Melo de Sales schreef: Hi folks, Recently I installed mysql using emerge mysql, but the version that was installed is 4.1.14, but I'd like to install the last available version of the 4.0 release. How can I do this? dev-db/mysql Available versions: 3.23.58-r1 4.0.25-r2 ~4.0.26 4.1.14 ~4.1.15 ~4.1.15-r1 *4.1.15-r30 ~5.0.15 ~5.0.16-r3 *5.0.16-r30 Installed: none Homepage:http://www.mysql.com/ Description: A fast, multi-threaded, multi-user SQL database server So I guess you want 4.0.26? Well, that's unstable, and the fact that you just installed 4.1.14 suggests that your ACCEPT_KEYWORDS setting in /etc/make.conf is set to stable (assuming x86 arch). The best way to solve this would be by using a mixture of settings in /etc/portage/package.mask and /etc/portage/package.keywords: Assuming that the directory /etc/portage exists already (create it if not): (as root) echo =dev-db/mysql-4.1.14 /etc/portage/package.mask to mask all versions of mysql greater than or equal to 4.1.14 and echo dev-db/mysql ~x86 /etc/portage/package.keywords to unmask the unstable versions below the masked version (thus 4.0.26). or you could unmask the specific version using echo =dev-dv/mysql-4.0.26 ~x86 /etc/portage/package.keywords but be warned that this will not enable you to upgrade if 4.0.26 is revised (4.0.26-r1) or upgraded (4.0.27), as those will still be masked by the ~arch keword, as opposed to the previous command, which unmasks all future unstable versions below 4.1.14. If you use a different arch, change the ~x86 to your correct arch (assuming that the version of mysql you want is available for that arch; if it is not, adapt the above commands to the available versions that you want to mask and unmask. Then an emerge -uav world should come up with a [UD] for mysql (the upgrade is a downgrade), and whatever else might need to be updated on your system; if you don't want to emerge the other upgrades, just do an emerge -uav mysql (but that will put mysql in your world file if it was previously installed as a dependency of something else, and you may or may not want mysql in your world file. But that's your choice). Hope this helps. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Package conflicts
Leandro Melo de Sales schreef: Hi folks, I'm trying to make a world update, but I got the following: # emerge -uD world Calculating world dependencies ...done! !!! Error: the =kde-base/kcheckpass-3.4* package conflicts with another package. !!!both can't be installed on the same system together. !!!Please use 'emerge --pretend' to determine blockers. How can I solve this? Leandro. Do as instructed: run emerge -upD world. The blocked package will be shown, as well as the package blocking it at the beginning of the output. The normal solution is to unmerge the blocking package so that the blocked package can emerge, but if you are unsure if you want to do that, or what effect it will have, then post the message as to what is blocking kcheckpass here and we'll see what's what. HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Re: Re: Still not getting how to influence compile flags with emerge
Mick schreef: Ciaran McCreesh wrote: On Fri, 02 Dec 2005 19:55:47 + Mick [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Fri, 2 Dec 2005 16:25:07 - Michael Kintzios | [EMAIL PROTECTED] wrote: | | Which USE flag will make that +xterm_clipboard | | | | This is a dependency flag which I guess can be flipped by first | | emerging x11-apps/xclipboard. | | Er. No. | | Go on, tell us more. Package source build options must never be controlled by stuff that is installed. Basic policy issue. OK, then we're back to the OP question: how does one control the xterm_clipboard flag? As said (several times)-- by enabling the vim-with-x USE flag. /usr/portage/profiles/use.local.desc:app-editors/vim:vim-with-x - Link console vim against X11 libraries to *enable title and clipboard features* in xterm Enabling the USE flag enables the ./configure option. If dependencies are needed to satisfy the option, they will be installed automatically before the package itself emerges. *This is what USE flags do*-- they enable or disable optional support for stuff, enabling you to customize your system and its packages. So if I don't need the clipboard features of vim, I don't have to have them, but if you do, you can. Voila! It's Gentoo!! :-) . Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Re: Re: Home Network Printing
Mick schreef: Richard Fish wrote: On 11/30/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Are you running cups? And if so, post the output of: grep -v ^# /etc/cups/cupsd.conf | grep -v ^$ for both systems. Thanks Richard, this is what I get from box 1 (this is the client): = snip Order Deny,Allow Deny From All Allow From 127.0.0.1 snip Allow From 127.0.0.1 /Location = This is what I get from host 2 (the server): = snip Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 192.168.0.2 /Location Location /printers Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 192.168.0.2 snip Any wrong entries? What I see is: I assume the printer is connected to the server--- but the server only allows connections from localhost (itself), and 192.168.0.2. If 192.168.0.2 is not the network IP address of the client (host 1), then the connection is denied. If the printer is connected to host 1... well, that only allows connections from localhost (itself). Connections from everywhere else are refused. So what I would suggest is that the server allow connections from the network as a whole, or the specific network IPs of the various networked clients. According to the well-commented cupsd.conf file: # Allow: allows access from the specified hostname, domain, IP address, # network, or interface. # # Deny: denies access from the specified hostname, domain, IP address, # network, or interface. # # Both Allow and Deny accept the following notations for addresses: # # All # None # *.domain.com # .domain.com # host.domain.com # nnn.* # nnn.nnn.* # nnn.nnn.nnn.* # nnn.nnn.nnn.nnn # nnn.nnn.nnn.nnn/mm # nnn.nnn.nnn.nnn/mmm.mmm.mmm.mmm # @LOCAL # @IF(name) # # The host and domain address require that you enable hostname lookups # with HostNameLookups On above. # # The @LOCAL address allows or denies from all non point-to-point # interfaces. For example, if you have a LAN and a dial-up link, # @LOCAL could allow connections from the LAN but not from the dial-up # link. Similarly, the @IF(name) address allows or denies from the # named network interface, e.g. @IF(eth0) under Linux. Interfaces are # refreshed automatically (no more than once every 60 seconds), so # they can be used on dynamically-configured interfaces, e.g. PPP, # 802.11, etc. # So if you have more than one machine on the network, you might consider changing the Allow From statements to read something like Allow From 192.168.0.* (assuming that your network mask is 192.168.0. , which it may not be). Modify for your actual network configuration. Sorry, I use Samba to connect to the network printer, as it's connected to a Windows box, so I can't help much more. Hope this is helpful though. Holly -- gentoo-user@gentoo.org mailing list
[gentoo-user] How does Portage prioritze emerges in emerge world?
OK, I take it back. I said that the situation of upgrading a kernel with the 'symlink' USE flag active occurring at the same time as a (particular) program needing to compile against a configured kernel was not likely to occur all that often, but I was wrong. It's happened again today, but with a different program than the ones I normally keep an eye on. The good thing is that I (think I) see what the problem is. The problem is that Portage emerges the new kernel before (almost) everything else, without regard for whether the 'symlink' USE flag is active, and whether or not any of the other programs proposed to emerge need to compile against a configured kernel source-- or rather, the currently-running kernel, which the symlink most likely pointed to before Portage changed it via a previous emerge. Honestly, there's really no reason (that I can see) to emerge a kernel source before everything else, since the kernel source is useless until at the very least configured, and preferably compiled and installed, and since you're in the middle of an emerge -uwhatever world, you can't reasonably configure and compile the new source until the entire operation is finished. Yeah, OK, technically you can, but it's not really something that an ordinary person would do, I think. And if the 'symlink' USE flag is active, emerging the kernel sources before everything else-- which may include packages that must compile against a configured kernel, with the assumption that the /usr/src/symlink points to such a kernel, which it no longer does because the symlink has been changed during a previous emerge and you have not had time to configure the newly-emerged kernel-- is a real problem. I just had to open another term, su to root, run MC to change the symlink-- and got it wrong because I had a second unconfigured kernel (2.6.14-r2; 2.6.14-r3 was being installed) that I forgot I had not yet upgraded to), so had to change the link again to the *real* running kernel (2.6.14) and emerge --resume. And of course I'll have to eventually change the symlink back manually in order to actually manage the new kernel. Which means I have to remember to do that-- which is not the point of having the 'symlink' USE flag active. It seems to me that this could all be avoided if Portage emerged a new kernel *last* in the list if the 'symlink' USE flag is active for kernel emerges-- then everything in the list that needed a configured kernel would have one (the currently-running kernel), the emerge would complete normally, and the symlink would be changed at the end of the procedure so that my next operation could be to upgrade the kernel, which seems to me a reasonable and ordinary order of operation (emerge -u** world, then configure and compile new kernel and run module-rebuild). Am I doing things wrong, or is this a valid enhancement request for b.g.o? Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] How does Portage prioritze emerges in emerge world?
Zac Medico schreef: Holly Bostick wrote: I said that the situation of upgrading a kernel with the 'symlink' USE flag active occurring at the same time as a (particular) program needing to compile against a configured kernel was not likely to occur all that often, but I was wrong. It's happened again today, but with a different program than the ones I normally keep an eye on. The good thing is that I (think I) see what the problem is. The problem is that Portage emerges the new kernel before (almost) everything else, without regard for whether the 'symlink' USE flag is active, and whether or not any of the other programs proposed to emerge need to compile against a configured kernel source-- or rather, the currently-running kernel, which the symlink most likely pointed to before Portage changed it via a previous emerge. snip The portage developers will not add a special case for kernel packages, so any reordering/prioritization would have to be done in a generic way that is usable for any type of package. Also, it seems desireable to compile against the latest kernel that is installed. . OK, I understand this to some extent (meaning I get it that Portage is not going to be revised in this way), but I must question that last statement, it seems desirable to compile against the latest kernel that is installed. The latest kernel that is *installed* (as opposed to the latest kernel whose source is emerged, regardless of whether it's configured, compiled, or installed) is the one I'm booted into, and while I presumably intend/want to upgrade to the newly emerged kernel at some reasonably soon point, I don't necessarily want to do it *right that minute*, nor am I necessarily going to avoid rebooting until such time as I have installed the upgraded kernel. Perhaps it would make sense to have a default kernel config that is used to configure the kernel sources automatically (make oldconfig; make modules_prepare) after a new kernel is installed? Something like this could be done ebuild postinst phase (when symlink is created). It is planned for future versions of portage to have pre/post phase hooks, which will allow users to define actions such as this via /etc/portage/bashrc: This sounds great, but what about the kernel I'm booted into, against which the module will *not* be compiled, if I have to reboot before actually configuring/compiling/installing the new kernel? The kernel modules will not be upgraded for that kernel (because the upgrades compiled only against the future kernel), and while that won't precisely break the old kernel (hopefully, since the old modules should still be good, though I cannot vouch for all circumstances), it means I don't have the upgraded modules for the currently-running kernel. After all, module-rebuild will re-build all the modules against a newly-compiled kernel; I don't need to build some limited subset of said modules against the new kernel source at the time I emerge the new kernel source, since I will build all of them at the end of the operations which make the new kernel actually available for use. What I do want is to build the upgraded modules against the currently-running kernel, which I expect to be using for some short additional period of time (until I compile and install the new kernel, which may be hours or days in the future). It would be nice to then have the future kernel source prepared for compilation and installation automatically (by redirecting the symlink), so that said compilation and installation goes on a next-to-do, asap list of sorts, but I'm not essentially forced to drop everything in order to compile the new kernel source *right now* in order to use the upgraded modules, which may be mission-critical in some respect (if the upgrade fixes functionality that I need working). Maybe the issue is really that the 'symlink' USE flag is obsolete in some respect, since it appears that automatic redirection of the /usr/src/linux symlink can often cause more problems than it solves, since the user cannot really know ahead of time whether a kernel module is going to upgrade in the same operation as a new kernel source is going to be emerged (which is not the same as installing a new kernel, of course). I guess I'll turn off the USE flag and manage the symlink directly, but it seems like there ought to be a better way. http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1107 Thanks for the link. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] How does Portage prioritze emerges in emerge world?
Zac Medico schreef: Holly Bostick wrote: This sounds great, but what about the kernel I'm booted into, against which the module will *not* be compiled, if I have to reboot before actually configuring/compiling/installing the new kernel? You can get pretty close to your desired behavior (merge kernel last) if you simple mask kernel package versions greater than the one that is currently installed. mkdir -p /etc/portage echo sys-kernel/gentoo-sources-2.6.14-r2 /etc/portage/package.mask That way, portage will not attempt to upgrade it until you tell it that you are ready, by removing the mask. And yeah, if USE=symlink causes problems, don't use it (in my suggested scenario above it might be useful though). So the ultimate conclusion is that I can either 1) disable the symlink USE flag and manage the redirect manually, which would enable me to download any kernel at any time without concern for whether a kernel module was upgrading in the same operation; or 2) manually mask kernels, which would enable me to upgrade any kernel modules at any time but force me to manually oversee the availability of kernel upgrades and manually enable them (and re-disable them following said upgrade). I guess I'll go for option 1, but the long and the short of it is that complete automation is unavailable and my only choice is what I prefer to manage manually. OK, then. sigh Thanks. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge --newuse misses package that new USE affects
glen martin schreef: As an aside, I wonder whether it is a good feature idea that ACCEPT_KEYWORDS=keyword emerge foo without --oneshot should automatically add foo keyword to the package.keywords file. That's an idea with some merit, but imo not enough (merit) to make it feasible (but it's not my decision; submit a feature request and see what happens). You now know firsthand one of the many reasons that using ACCEPT_KEYWORDS on the command line is *not* recommended. It is a temporary setting, useful only for testing situations. The fact that if you use it, then decide to make the testing situation permanent but do not add a permanent setting (in package.keywords), you will encounter problems of this sort underlines the nature of the setting (temporary, temporary, use for explicit testing only; if you want a permanent setting, make one explicitly). The idea of having the temporary setting invisibly add a permanent setting seems cool, but undermines both the function of the temporary setting (since it's no longer truly temporary), and the function of the permanent setting (since you have not explicitly made the setting, you may or may not want it set), and what about dependencies? You'd have to unmask them explicitly (or else you'll get a lot of thus and so cannot be installed because thus and so is masked errors, and if you have to do that, you've already destroyed any usefulness an automatic addition might have had. So it's not something for me, but I'm weird ;-) ; others might feel differently. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge --newuse misses package that new USE affects
glen martin schreef: Holly Bostick wrote: glen martin schreef: As an aside, I wonder whether it is a good feature idea that ACCEPT_KEYWORDS=keyword emerge foo without --oneshot should automatically add foo keyword to the package.keywords file. That's an idea with some merit, but imo not enough (merit) to make it feasible (but it's not my decision; submit a feature request and see what happens). You now know firsthand one of the many reasons that using ACCEPT_KEYWORDS on the command line is *not* recommended. It is a temporary setting, useful only for testing situations. That makes sense. I hadn't encountered that recommendation at the time - I'd seen the ACCEPT_KEYWORDS syntax without such warning. Not in the man page, obviously, which has it right. The idea of having the temporary setting invisibly add a permanent setting seems cool, The trick here is the word 'temporary'. If 'temporary', the keyword --oneshot would (should?) be present. In absence thereof ... It seems analogous to the world file - the world file is the permanent specification, and it written per presence or absence of oneshot. Why not so for /etc/portage/package.*? How are those files different-in-kind from world? OK, I'm not an expert either, but I *think* that the issue is the fact that ACCEPT_KEYWORDS and emerge are *two separate commands*. Are you familiar with exporting variables? ACCEPT_KEYWORDS is, of course a variable. When you export a variable (DISPLAY, LD_ASSUME_KERNEL, LD_LIBRARY_PATH, LD_PRELOAD, PS1, ACCEPT_KEYWORDS), the variable is changed for the current login shell session, but is not persistent. Period. That has nothing to do with Portage or any program, that's how Linux works. Variables are permanently set in configuration files (in the case of ACCEPT_KEYWORDS, in /etc/make.conf, with modifications allowed from /etc/portage/package.keywords). Most of the time, the temporary nature of this change can be assumed without thinking-- if the startup script for Neverwinter Nights includes an export LD_LIBRARY_PATH=./lib:./miles:$LD_LIBRARY_PATH command, the fact that it's temporary doesn't matter, because it only needs to be in effect while I'm running Neverwinter Nights, which is a temporary condition. This is completely different from the state of the Portage tree and your world file when running emerge. Basically, when you use ACCEPT_KEYWORDS on the command line, you are changing a variable temporarily, which Portage then reads, but because the condition does not persist-- and the state of Portage variables must persist across sessions-- you're essentially confusing Portage, which must rely on you to have a stable list of variable conditions in order for it to know what it's doing. This is not a flaw in Portage, it's just how it's constructed, and it really couldn't be constructed any better than it is-- it already does a lot more than one might have thought possible in terms of being flexible and 'pushing the envelope'. But the conditions of the environment must be respected. There is no way for Portage to become aware that you exported a variable prior to running the emerge command, and so there is no way for Portage to automatically add the --oneshot switch if you had done so, in the same way that --update implies --pretend or whichever switch it is that implies another, so the second switch is automatically added if the first is present. Because (export) ACCEPT_KEYWORDS is not part of the emerge command, and the emerge command can only adjust itself, based on its own settings, not other settings that you have manually adjusted prior to running the command. If you see what I mean. Anyway, I could be totally wrong, but I think it hangs together, and I suspect it is in fact the case. Perhaps it could be better explained to people, though, so that they understood the relationship between the variables that Portage is reading and the commands that one might run to modify them. Of course, a good thorough grounding in shell operations would take care of that, too, I suppose Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
Harry Putnam schreef: First let me add that (mjpegtools-1.6.2-r3) isn't even installed: root # qpkg -v -I |grep mjpegtools media-video/mjpegtools-1.8.0-r1 * equery depends mjpegtools [ Searching for packages depending on mjpegtools... ] media-video/transcode-0.6.14-r2 media-video/cinelerra-cvs-20050801 both are installed here: # qpkg -v -I |grep 'transcode\|cinelerra' media-video/transcode-0.6.14-r2 * media-video/cinelerra-cvs-20050801 * This seems odd: Runtime Dependencies transcode-0.6.14-r2 media-libs/libexif media-libs/netpbm | = media-video/ffmpeg - 0.4.9_pre1 a52 = media-libs/a52dec - 0.7.4 avi = media-video/avifile - 0.7.41.20041001 dv = media-libs/libdv - 0.99 dvdread = media-libs/libdvdread - 0.9.0 encode = media-sound/lame - 3.93 fame = media-libs/libfame - 0.9.1 gtk = x11-libs/gtk+ - 1.2* imagemagick = media-gfx/imagemagick - 5.5.6.0 jpeg media-libs/jpeg lzo = dev-libs/lzo - 1.08 mjpeg = media-video/mjpegtools - 1.6.2-r3 mpeg media-libs/libmpeg3 ogg media-libs/libogg pvm = sys-cluster/pvm - 3.4 quicktime = media-libs/libquicktime - 0.9.3 sdl media-libs/libsdl theora media-libs/libtheora truetype = media-libs/freetype - 2 vorbis media-libs/libvorbis xvid = media-libs/xvid - 1.0.2 X virtual/x11 Runtime Dependencies cinelerra-cvs-20050801 media-libs/faad2 media-libs/libdv | = media-libs/libogg - 1.0 media-libs/libpng | = media-libs/libtheora - 1.0_alpha4-r1 | = media-libs/libvorbis - 1.0.1-r2 | = media-libs/openexr - 1.2.1 | = media-sound/esound - 0.2.34 ! media-video/cinelerra - ! media-video/cinelerra - media-video/mjpegtools | = sys-libs/libavc1394 - 0.4.1 |= sys-libs/libraw1394 - 0.9.0 virtual/x11 What seems odd to me is that neither of these two programs depends on that specific version of mpegtools. Transcode will take that version or above, cinelerra doesn't care. And, since you have a greater version installed, there seems to be no reason that revdep-rebuild should be trying to install an older version in this way. The highest likelihood is that-- as previously suggested-- you're running an old output from revdep-rebuild -p (when this version was the installed version of mjpegtools), and did not delete the old output files and re-run revdep-rebuild -p to get a new prospective rebuild list. You might want to check your /root/ folder and see what the dates on those .revdep-rebuild files is. If they aren't from a recent time, remove them, and run revdep-rebuild (-p) again. Alternatively (hacky solution), try re-emerging cinelerra and transcode again (to retrain them in where their dependent files are and what version they are). Even more hackily, remove mjpegtools totaly (unmerge), then do an emerge -uaDtv world, and let it get pulled back in as a dependency of the two packages that need it. That ought to straighten everything out. But probably you're just using old revdep-rebuild output, and the easiest solution would be to delete those files so that revdep-rebuild can update itself with the current state of your system. HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] dovecot problem
[EMAIL PROTECTED] schreef: I'm having a problem with dovecot. I upgraded dovecot yesterday to 0.99.14-r1, although dovecot --version still claims to be 0.99.14 I don't know how to fix your problem (sorry); just wanted to mention that the reason that the version is still claimed to be 0.99.14 is because it *is* 0.99.14-- usually revisions (-r#) relate to the *ebuild* being revised, not the program. If the program is itself revised, upstream changes the version number most of the time; for example to 0.99.15, indicating a relatively minor release update. This is a good thing, because if the source has changed, you will then have to download a new tarball due to the new release number, whereas if Gentoo revised an updated tarball with an -r1, you would probably miss the changes, because the old tarball would still be in /distfiles/ and Portage would not think it had to download a new one. Good luck with solving the issue with the program itself. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
Harry Putnam schreef: Richard Fish [EMAIL PROTECTED] writes: (Including Richard in reply as well) Nagatoro [EMAIL PROTECTED] writes: [...] Assigning files to ebuilds... using existing /root/.revdep-rebuild.4_ebuilds. Evaluating package order... using existing Nagatoro replied: ^^^using existing^^^ means that you are using the results from an older run of revdep-rebuild. First remove all .revdep* files and the run it again and see if you find the same errors. Harry responds: Ack, yes of course and it even warns you about that However having removed them I still get a huge list of stuff listed as BROKEN Yes, well, that's what revdep-rebuild does-- finds broken stuff. It's doing its job-- what's the problem with that? One of the first involves the same mjpeg package that isn't even installed: broken /usr/bin/cinelerra (requires libmjpegutils-1.6.so.0) U--- why do you feel that this is the same package that isn't even installed? You said that you have libmjpegutils installed, just not the same version that was attempting to be rebuilt before 1.8.0 installed, rather than the 1.6.2-r3 that was attempting to be rebuilt). eix mjpegtools * media-video/mjpegtools Available versions: 1.6.2-r4 ~1.8.0 ~1.8.0-r1 Installed: 1.6.2-r4 Homepage:http://mjpeg.sourceforge.net/ Description: Tools for MJPEG video equery files media-video/mjpegtools [ Searching for packages matching media-video/mjpegtools... ] * Contents of media-video/mjpegtools-1.6.2-r4: /usr/lib/libmjpegutils-1.6.so.0 - libmjpegutils-1.6.so.0.2.2 Now, obviously this is not the same version of mjpegtools that you have, but what it indicates is that the file libmjpegutils-1.6.so.0 is a symlink to whatever version of the actual library is installed by the package. I rather expect that what would happen if I were to upgrade this package is that the symlink itself would remain, but the target of the symlink would change. If this is in fact the case, two points: 1: your symlink seems to be broken; 2: the error you have listed does not say anything about what version of mjpegtools is installed or broken, so revdep-rebuild is not necessarily talking about the same version as previously, But better to go to the source: == Full output of revdep-rebuild (minus all config make stuff [sorry about control chars I forgot to use -nc but have removed some]): Note it doesn't appear to say what pkg actually failed: Evaluating package order... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild.. emerge --oneshot =dev-php/mod_php-4.4.0 =dev-php/php-4.4.0 =media-libs/imlib-1.9.14-r3 =kde-base/kdegraphics-3.4.1-r1 =media-gfx/imagemagick-6.2.5.4 =media-libs/libdv-0.102 =media-video/avifile-0.7.41.20041001-r1 =media-video/cinelerra-cvs-20050801 =media-video/transcode-0.6.14-r2 =net-libs/libwww-5.4.0-r3 ^G.^G.^G.^G.^G.^G.^G.^G.^G.^G. --8 [big snip] you have the following choices: - if emerge failed during the build, fix the problems and re-run revdep-rebuild So apparently the rebuild failed. But first of all, I don't see mjpegtools being rebuilt in this list, so that is not the problem apparently (the problem is not that mjpegtools is not installed, but that the programs that depend on it are not linked against it, which is what revdep-rebuild is trying to fix by re-emerging them); ... and second of all, which package failed to emerge and why? Meaning, what was the error in whichever package failed to emerge? Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
Harry Putnam schreef: I still don't see the actual error there and it was the output of: revdep-rebuild -nc 21|tee revdep.log revdep.log is what I posted online. Richard Fish replied with the specific issue about half an hour ago: Richard Fish schreef: Ok, now we are going to need to see the output of emerge --info, because for some reason your toolchain thinks it is cross-compiling: checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib) works... yes checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib) is a cross-compiler... yes The problem occurs with the very first compile configure: error: can not run test program while cross compiling ...done! | emerge (1 of 10) dev-php/mod_php-4.4.0 to / ... so the problem is definitely somewhere in your toolchain, rather than anything to do with either revdep-rebuild or the specific programs attempting to be rebuilt. Posting emerge info is a good starting point to troubleshoot this (unless you already happen to know why this is occurring, that's also possible). Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Could not emerge app-crypt/gnupg-1.4.2-r2 due to new kernel being emerged too
Jules Colding schreef: Hi, Todays emerge -vauDN world failed with gnupg not being emerged. The reason seems to be that I am emerging a new kernel too. This new kernel has obviously not been configured/build yet which makes gnupg unable to find .config in /usr/src/linux/. I expect this problem to go away when the new kernel is up and running. emerge output below. Best regards, jules Or, you could just change the /usr/src/symlink back to your currently-configured kernel, emerge gnupg, then change it (the symlink) back to point at the new, unconfigured kernel. I take it you're using the 'symlink' USE flag, which does this automatically. I usually do too, and had a similar problem with a different program just a week or two ago. Fortunately, I noticed that it was going to happen before the emerge proceeded (I was getting a new kernel, and upgrading the ati-drivers package, which I know must compile against a configured kernel), so I just disabled the 'symlink' USE flag for the new, about-to-be-downloaded kernel *only* (and learned that you can manage specific versions of an app in /etc/portage/package.use), so that the symlink was not changed, and the ati-drivers emerged normally against my current, configured kernel. Then I manually redirected the /usr/src/linux symlink to the new, uncompiled kernel for the later kernel upgrade. So I only had to do the redirect once, and it all worked out fine. Of course I had to re-emerge the ati-drivers, but that's normal anyway when upgrading a kernel. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Could not emerge app-crypt/gnupg-1.4.2-r2 due to new kernel being emerged too
Neil Bothwick schreef: On Thu, 24 Nov 2005 12:49:04 +0100, Holly Bostick wrote: Fortunately, I noticed that it was going to happen before the emerge proceeded (I was getting a new kernel, and upgrading the ati-drivers package, which I know must compile against a configured kernel), so I just disabled the 'symlink' USE flag for the new, about-to-be-downloaded kernel *only* (and learned that you can manage specific versions of an app in /etc/portage/package.use), Couldn't you have achieved the same with less effort with USE=-symlink emerge world -blah ? Yes (qualified yes), but 1) I'm training myself out of changing USE flags on the command line (though it would have been OK in this case, the reason I have a general policy is to keep to it, not except it :-) ) 2) I learned something (because I don't want to use USE= on the command line, I had to use package.use, which I didn't know up to that moment allowed specification of package versions. But I found that =sys-kernel/gentoo-sources-2.6.13-r5 -symlink is actually valid, which is useful information, enabling me to turn the USE flag off for just this one emerge, without disturbing later kernels for which I want to keep the 'symlink' flag default enabled. Since this situation is not terribly likely to occur again-- an upgrade to the ati-drivers being offered in the same operation as a new kernel, given that the ati-drivers don't update that terribly often, and on a schedule, and since I often mask shiny-new kernels because the ati-drivers are generally unlikely to compile against them lately-- knowing that a 'oneshot mask' is possible in package.use is handy). So yes, it would have been easier to do it the way you say, but I find taking unexpected opportunities to explore the capabilities of Portage more valuable than doing things the easy way (sometimes). Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How to alter ./configure flags from emerge
Harry Putnam schreef:
Since syncing yesterday and emerge -u world, I now get
mysql-5.0.16-r1 when I emerge mysql. It doesn't have the docs built
either regardless of what USE variable are in force.
Are there in fact docs available for this version yet? From MYSQL, I
mean, not Gentoo. Perhaps that's why you haven't been able to find such
a separate package-- it doesn't yet exist, because the 'source' (the
docs themselves) don't. Worth checking, anyway.
I've took the tips about /etc/portage/package.use syntax and
arrangement so it now is correct (I think): cat
/etc/portage/package.use
mail-mta/sendmail mbox sasl milter dev-db/mysql mysql mysqli doc
ndb-doc dev-backup/bacula mysql mysqli doc
Except that most of those flags are no longer valid for the unstable
version...
ACCEPT_KEYWORDS=~x86 emerge -pv mysql
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild N] dev-db/mysql-5.0.16-r2 -berkdb -big-tables -cluster
-debug -extraengine -minimal +perl (-selinux) +ssl -static -utf8
But now I've got worse provlems than no documentation. I can't even
start this install of mysql.
/etc/init.d/mysql status * status: stopped
/etc/init.d/mysql start * working on 0 * Starting mysqld0
(/etc/mysql/my.cnf) ... .. * MySQL NOT started (0)
Here is where the docs would be quite handy...
The ChangeLog suggests that you may have missed a step or two, or
perhaps should reconsider that ~arch setting in this case:
less /usr/portage/dev-db/mysql/ChangeLog
# ChangeLog for dev-db/mysql
# Copyright 2002-2005 Gentoo Foundation; Distributed under the GPL v2
# $Header: /var/cvsroot/gentoo-x86/dev-db/mysql/ChangeLog,v 1.266
2005/11/23 19:44:22 vivo Exp $
*mysql-5.0.16-r2 (23 Nov 2005)
23 Nov 2005; Francesco Riosa [EMAIL PROTECTED] mysql-4.1.15.ebuild,
mysql-4.1.15-r30.ebuild, -mysql-5.0.16-r1.ebuild, +mysql-5.0.16-r2.ebuild,
mysql-5.0.16-r30.ebuild:
fix Bug #113352 , mysql-5.0.16-r1 does not create
/usr/lib{64}/libmysqlclient.so.15 symlink
==The linkage has been somewhat improved too. It has been moved in
==pkg_postinst() function to advise the user to use revdep-rebuild
with the
==right --so-name option.
As a consequence it does not rely on dosym but use ln program
directly(bug).
==it work now with FEATURES=prelink notitles sandbox strict userpriv
==usersandbox keeptemp keepwork but in the future may be needed to
advise
sandbox that we are messing up with the live file-system
*mysql-5.0.16-r1 (23 Nov 2005)
23 Nov 2005; Francesco Riosa [EMAIL PROTECTED] files/mysql-slot.rc6,
-mysql-5.0.16.ebuild, +mysql-5.0.16-r1.ebuild:
Version bump, modified rc init script thanks to Jasper Bryant-Greene for
reporting a bug
*mysql-5.0.16-r30 (23 Nov 2005)
*mysql-5.0.16 (23 Nov 2005)
23 Nov 2005; Francesco Riosa [EMAIL PROTECTED] files/mysql-slot.rc6,
-mysql-4.0.26-r30.ebuild, mysql-4.1.15-r30.ebuild,
-mysql-5.0.13_rc.ebuild, -mysql-5.0.15-r30.ebuild, +mysql-5.0.16.ebuild,
+mysql-5.0.16-r30.ebuild:
Version bump for the 5.0 series.
The ebuild has been rewritten, it's the first step to slot the mysql
database
server. (diff 5.0.16 and 5.0.16-r30 if you don't belive at it)
Also the rc scripts are changed, hopefully bug #109380 is gone (Thanks to
Rodrigo Severo for shaping it).
It's possible from now start more than one server tweaking the
/etc/conf.d/mysql .
The future of slotted MySQL is still uncertain but the rc script will
be kept.
More than uncertain is the slotting of MySQL-4.0 too.
==reassuming, be careful playing with these ebuilds, never ever
== ~ARCH keywords has been so unstable.
---
Of course, you might want to upgrade to -r2, since clearly some things
didn't work in -r1 (in ebuild terms)
You might also want to stick with stable until things settle down a bit.
Just my 2 Eurocents, as you see, I'm not a MySQL user.
HTH,
Holly
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How to alter ./configure flags from emerge
Harry Putnam schreef: Holly Bostick [EMAIL PROTECTED] writes: Of course, you might want to upgrade to -r2, since clearly some things didn't work in -r1 (in ebuild terms) You might also want to stick with stable until things settle down a bit. Holly, Thanks for the usual helpful effort. Maybe you can tell me how one controlls what ebuild is used. For example: snip I was able to to at least start mysql-5.0.15.ebuild, how would I select it out of the others thru emerge? Lots of ways-- to return to the stable build, try # echo 'dev-db/mysql x86' /etc/portage/package.keywords This will essentially change the ACCEPT_KEYWORDS setting for this package only to stable. You may also have to add settings for the dependencies, as they will still be unstable versions if you do not, and I don't know how well the stable mysql build plays with the unstable versions of its dependencies. To only allow version 5.0.15, try # echo 'dev-db/mysql-5.0.15' /etc/portage/package.mask This will mask all unstable versions above 5.0.15. You will have to be responsible for unmasking later versions when you feel that they have stabilized to your needs (meaning, you have to keep an eye on the status of the ebuilds, because even when later versions go stable, you won't have them available to you in Portage). So I would almost say go back to stable, and when the currently unstable upgrades become stable, just upgrade normally. Unless you have some burning reason to have version 5 now, today, no matter what the circumstances. I foolishly ran the last -u world with ACCEPT_KEYWORDS=~x86 and have since set that globally. So I'm now bleeding edge and it appears that it would take some doing to undo that at this point so thought I'd go with it for a while and see if I could get ontop of it. I know about using the actual path and that is how I'm installing it as I write but one always gets those troublesome messages about installing by path being broken U no you don't so much need to use the actual path as you need to use the correct syntax to emerge a particular version of a package: emerge =dev-db/mysql-5.0.15 or emerge (=)[= - the exact version; = - any version greater than or equal to; = - any version less than or equal to; - any version greater than; - any version less than]cate-gory/package-version.number Naturally if you do something like this, though, you'll want to utilize package.mask to block other versions so that Portage doesn't try to upgrade or downgrade the package you've specifically emerged in a particular version. HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] ERROR: media-libs/smpeg-0.4.4-r6 failed
Ernie Schroder schreef: I've figured out most of my 11 month updates, but this one is driving me mad. I would appreciate some advice here. I still have a few apps to update that fail like this: checking for SDL - version = 1.2.0... no *** Could not run SDL test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means SDL was incorrectly installed *** or that you have moved SDL since it was installed. In the latter case, you *** may want to edit the sdl-config script: /usr/bin/sdl-config configure: error: *** SDL version 1.2.0 not found! eix smpeg * media-libs/smpeg Available versions: 0.4.4-r6 ~0.4.4-r7 Installed: 0.4.4-r6 Homepage:http://www.lokigames.com/development/smpeg.php3 Description: SDL MPEG Player Library equery depgraph =media-libs/smpeg-0.4.4-r6 [ Searching for packages matching =media-libs/smpeg-0.4.4-r6... ] * dependency graph for media-libs/smpeg-0.4.4-r6 `-- media-libs/smpeg-0.4.4-r6 `-- media-libs/libsdl-1.2.8-r1 Runtime Dependencies smpeg-0.4.4-r7 |= media-libs/libsdl - 1.2.0 gtk = x11-libs/gtk+ - 1.2* opengl virtual/opengl X virtual/x11 smpeg-0.4.4-r6 |= media-libs/libsdl - 1.2.0 gtk = x11-libs/gtk+ - 1.2* opengl virtual/opengl X virtual/x11 As you see, smpeg depends (hard, irrefutable dependency, not optional) on libsdl, in a version equal to or greater than 1.2.0 (I use 1.2.8, as you can also see). What is the status of libsdl on your box? Is it installed? If so, what version? It appears that either an incorrect version is installed, or the installed version is broken (if it was not installed at all, smpeg would have installed it before installing itself, so clearly there is some reason that Portage thinks it didn't have to). HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge --newuse misses package that new USE affects
glen martin schreef: snip I've changed some USE flags deliberately to add features to a package snip Despite the USE change, I find that that apache is not being caught by emerge --newuse world. snip I added threads nptlonly mpm-worker to USE in make.conf. I've probably made some other changes to USE since my last world rebuild. I've also done an emerge --sync. Then: snip of all the proof that the assessment is correct So, any thoughts on why emerge --newuse doesn't want to rebuild apache? Well, assuming it's not a bug (what version of Portage are you using?) then is it possible that apache is neither in your world file, nor a dependency of something that is (does it show up in the list of a depclean -p)? That's the only reason I can think of that the combination of --update and --deep wouldn't recognize that apache is one of the packages that should be considered for --newuse. HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] masked package woes
James schreef: Hello, Jffnms is masked. However I am able to install it on an intel portable by adding this line to the /etc/portage/package.keywords net-analyzer/jffnms ~x86 This is pretty must standard approach. However, on a gentoo system that I manually hacked a jffnms installation on on a very early (experimental) ebuild does not even show jffnms as a masked package. It intalled configuration file is /etc/jffnms, but I delete that dir and contents. Still I cannot install the jffnms masked package on this one system. Everyother system can install jffnms with the aforementioned line added to package.keywords. Any ideas how to track this down? Should I just copy over the ebuild manually to /usr/portage/distfiles ? Ebuilds don't go in /usr/portage/distfiles, so doing that won't help you. When you say that you manually hacked an installation, what do you mean? If you created an ebuild in your PORTDIR_OVERLAY (the correct procedure), do you still have an overlay directory enabled (preferably the same one), in /etc/make.conf? If you put your ebuild in the regular Portage tree, and you have since synced , the illegal ebuild has likely been removed. In that case, I would suggest enabling an overlay in /etc/make.conf, setting up an overlay tree (default location is /usr/local/portage), putting the ebuild there, then digesting it. It should then emerge normally. Did you even install the previous 'hack' with Portage? Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Anyone know where I can find an ebuild for projectx?
Nick Rout schreef: ProjectX is a java mpeg2 editor. It used to be in portage but has been dumped with no warning. I didn't have a chance to move it to overlay. Does anyone have an ebuild for this package? If it used to be in Portage, you can probably find it in the CVS attic-- check the gentoo.org homepage, use the Browse CVS menu item to get to the CVS, and then surf to the correct category. There should be a folder called Attic, where, iirc, you will find such removed ebuilds. Just download/save it and pop it in your overlay. I would check why it was removed, though, before doing so... but that's just me. :-) HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How to alter ./configure flags from emerge
Harry Putnam schreef: Alexander Skwar [EMAIL PROTECTED] writes: Me too. Seems that the system didn't get that change. Please send output of: grep dev-db/mysql /etc/portage/package.use dev-db/mysql mysql mysqli dev-db/mysql doc dev-db/mysql ndb-doc Harry, put all the USE flags on one line. What is happening to you is that the lines do not concantate (add on to each other, however you spell that word), they override each other. The way you have it, first the mysql and mysqli flags are being turned on, then the flags go back to default, and the doc flag is turned on, then the flags go back to default and the ndb-doc flag is turned on, so ndb-doc is the only non-default flag that ultimately is turned on. But if you have dev-db/mysql mysql mysqli doc ndb-doc (just one line instead of three), they will all be turned on. I usually find it helpful to pop into package.use with nano and do a Ctrl-W search to confirm that I have not already set some USE flags for a popular application (if I modify it a lot), so I know whether to add to an existing line or create a new one. Since I'm already in nano, creating a new line if necessary is easy enough. Hope this helps,. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] how to create a pgp signature
Alexander Skwar schreef: Holly Bostick schrieb: However, other than pointing this out by the simple expedient of confusing everyone further, Alexander's reply was less than helpful, since it neither pointed out why the answer given was presumably not correct, Uhm. Yes, I did not point that out. Why and how should I? OP asked, how a signature can be created. That's a clear question. I don't know how to explain, why --gen-key is the wrong answer. It's just so plain totally wrong, that I just don't know how to explain it. Well, if someone asks how to create a signature, and someone else answers how to provide a key pair, clearly someone is confused as to the fact that a signature is not a key pair. Saying so explicitly (i.e., this will generate a key pair, not a signature, and they are not the same thing), seems to be to be a simple way of saying why the answer is wrong. But that's just me and my conviction that people can't learn what you don't tell 'em (with the corollary assumption that people ask questions because they want to learn/know/understand something). or provided a correct answer if the answer given was in fact not correct. Oh, I did not? What about the -s? How's that not the sign command? Sorry, Alexander-- I missed the *second* mail in which you did this. In the mail quoted by Jason (the first mail), you were distinctly obscure :-) , and that's the one I was referring to. My mistake. Holly -- gentoo-user@gentoo.org mailing list
Re: default stage3 (was : [gentoo-user] Is Gentoo still on the right path?)
Hemmann, Volker Armin schreef: On Monday 21 November 2005 13:33, Steve B wrote: WTF.. I'm getting ready to rebuild my gentoo box. I have always did a stage 1 install. i was under the impression that if u used a stage 3 u couldn't muck with your CFLAGS or what not. If I'm forced to use canned binaries I might as well go with FC or Debian.. I've never listened to the Gentoo is dead comments.. but now who knows.. this is just crazy.. who came up with this stupid idea? from the sounds of it certianly not the Gentoo Community! well, it was made, because the idiots are too dumb to read and follow the stage1 instructions. And gentoo needs more idiots, right? Up until now, the installation was a nice filter - but that has weakend now, too. I don't actually agree... the impression I'm getting is that Gentoo has now matured/evolved into a state where filters are no longer necessary (or as necessary as previously). Before now, the Gentoo install was rather fragmented, because all the tools necessary to install Gentoo did not all work, or did not all work as well as they needed to, or did not all work as well as they needed to in combination with each other. In practical market terms, you wouldn't want just everybody installing it-- in order to ensure a good and successful experience for the largest number of people, you would not want to encourage those who were untrained or refused training, since the state of the backend required training for successful use. Those who were turned off by the amount or complexity of the documentation (and/or the length of time the install entailed) would tend naturally to fall away. But once Gentoo is actually installed, it's just as easy to use as anything else. Maybe you have to learn emerge -whatever instead of apt-get whatever, but one is not particularly harder than the other. It was always the install that was hard, not the usage. The evolution/maturation of Gentoo and its associated tools means that in order to install Gentoo you no longer have to carefully pick your way across a minefield (stage 1), but can with confidence stride across a beautiful grassy plain (stage 3). If you then want to turn around and customize that field-- plant some flowers, for example-- you can do that (emerge -e world), or you don't have to. But the point is that if you want to interrupt your journey to whatever was on the other side of that field (use your PC for whatever you planned to do with the system, instead of suffering to install the system in the first place) you now have a choice about whether to do that or not. You are not essentially forced to do so by the fact that the minefield was not clear and passage to the other side was not easy or safe and required a great deal of attention. Unbelievable that people are complaining about an improvement in ease-of-use (or in this case, installation). I'd also wonder why Steve B. is installing (again) anyway; one of Gentoo's hallmarks is that you basically install it once and you (almost) never have to do it again. That is of course Steve's business. although if he's going to reinstall, again I must wonder why he would complain that such a reinstall is now likely to be much easier, and lead to a functioning system (from which he can emerge -e world to his heart's content) much faster. But maybe I just have a strange point of view. Holly -- gentoo-user@gentoo.org mailing list
Re: default stage3 (was : [gentoo-user] Is Gentoo still on the right path?)
Daniel da Veiga schreef: Gentoo is not easy, its not simple and its not designed or the best distro to start in the Linux world. Hogwash. What's so hard about it, as opposed to any other Linux distro, once you get past the install issue? Is learning Portage somehow intrinsically harder than figuring out how to manage YAST and YOU, if you don't know anything at all about package management (which, after all, Windows doesn't have at all)? Does having to figure out how to acquire a media player that will play your MP3s and DVDs by default, because you're using a distro that does not legally prefer this functionality to be distributed, somehow make that distro easier to use, or simpler in some way? The ATI drivers are a b**ch to install no matter what distro you use, if you need them. Just what precisely is so not-simple about Gentoo as opposed to any other distro (barring perhaps Linspire)? Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] root password gremlin
Abhay Kedia schreef: On Sunday 20 Nov 2005 7:16 pm, Holly Bostick wrote: equery hasuse pam Wow!!! I performed that thing on my system and the stupid PAM is everywhere (I am scared as shit after reading this thread). What would be the easiest way to get rid of PAM from a single user desktop system working smoothly? Would a -pam in make.conf and emerge -uDN world suffice? Abhay Just because you have a lot of packages installed that have the pam USE flag doesn't mean that much-- is the flag actually enabled for those packages? If so, and your system is not having any issues, I wouldn't necessarily become hysterical just yet. But if you really are concerned, and want to remove it, you might consider the following wiki entry, and then think about it before making a decision: http://www.gentoo-wiki.com/HOWTO_Remove_PAM HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] problem with wxGTK
Antoine schreef: !!! set-wxconfig: /usr/bin/wxgtk2u-*2.4*-config not found [ebuild R ] x11-libs/wxGTK-*2.6.1* -debug -doc +gnome +gtk2 -joystick +odbc +opengl +sdl +unicode -wxgtk1 0 kB equery belongs /usr/bin/wxgtk2u-2.4-config [ Searching for file(s) /usr/bin/wxgtk2u-2.4-config in *... ] x11-libs/wxGTK-2.4.2-r3 (/usr/bin/wxgtk2u-2.4-config) eix wxgtk * x11-libs/wxGTK Available versions: 2.4.2-r2 2.4.2-r3 [M]2.5.3 ~2.6.0-r1 2.6.1 ~2.6.2 Installed: 2.4.2-r3 2.6.1 Homepage:http://www.wxwindows.org Description: GTK+ version of wxWidgets, a cross-platform C++ GUI toolkit and wxbase non-gui library Any ideas? Yes, you need to install a 2.4 version of wxGTK. Hope this helps, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] how to create a pgp signature
Jason Ausmus schreef: -Original Message- From: Alexander Skwar [mailto:[EMAIL PROTECTED] Sent: Sunday, November 20, 2005 3:48 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] how to create a pgp signature You're answer was to a different question. Whose answer was to a different question? Ralph Slooten schrieb: gpg --gen-key Wrong. can anybody tell me methode to create my own pgp signature? That's the question. Was the answer Ralph gave not correct? I don't understand what you're trying to say... Alexander Skwar Posting out-of-order makes it easy to follow context. Alexander may have been complaining about the top-posting, or maybe the OP was not completely clear in the question, or maybe Ralph misunderstood the difference between a /key pair/ and a /signature/: gpg --help Syntax: gpg [options] [files] sign, check, encrypt or decrypt default operation depends on the input data Commands: == -s, --sign [file] make a signature --clearsign [file]make a clear text signature -b, --detach-sign make a detached signature -e, --encrypt encrypt data -c, --symmetric encryption only with symmetric cipher -d, --decrypt decrypt data (default) --verify verify a signature --list-keys list keys --list-sigs list keys and signatures --check-sigs list and check key signatures --fingerprint list keys and fingerprints -K, --list-secret-keyslist secret keys == --gen-key generate a new key pair --delete-keys remove keys from the public keyring --delete-secret-keys remove keys from the secret keyring --sign-keysign a key So if the question really does relate to creating a signature, Ralph was wrong. If the question was wrong, and a key pair needs to be generated in order to sign something, then Ralph was right. However, other than pointing this out by the simple expedient of confusing everyone further, Alexander's reply was less than helpful, since it neither pointed out why the answer given was presumably not correct, or provided a correct answer if the answer given was in fact not correct. Awaiting more data in order to answer /your/ question, Jason (can not compute). but everybody could just read the man page and work it out for themselves, of course :) . Holly -- gentoo-user@gentoo.org mailing list
Re: default stage3 (was : [gentoo-user] Is Gentoo still on the right path?)
George Garvey schreef: On Mon, Nov 21, 2005 at 04:17:45PM +0100, Holly Bostick wrote: reinstall, again I must wonder why he would complain that such a reinstall is now likely to be much easier, and lead to a functioning system (from which he can emerge -e world to his heart's content) much faster. But maybe I just have a strange point of view. No, you presume a strange point of view on Steve's part, quite unfairly. That is why he posted: stage 3 did NOT leave him a functioning system from his POV. I don't know the right or wrong of this, but implying Steve is an idiot seems quite derogatory. But maybe I just have a strange point of view. Sorry, no intention of implying that anyone other than myself was an idiot (I wonder implies I do not understand something, so if anyone is an idiot, it must be me for missing something so obvious to everyone else, so I was actually asking for clarification), and apologies if it read that way. Myself, I don't consider that either a stage 1 or stage 3 leaves me with more than a minimally functional system after the initial install, but a stage 3 leaves me with a *higher functioning* minimal install than a stage 1 does. Either way, I have to put in a fair amount of time either installing the full system that includes the apps and whatnot that I actually use, or customizing the stage 3 to reflect my actual usage patterns, both of which operations take a lot of time. But at least after a stage 3, I don't have to be *uncomfortable* while I'm waiting to get my system up to my personal spec-- I can still *use* Mozilla, even if it's compiled with Mail, and Composer, and IRC, while I wait for it to recompile with the -moz*** USE flags. Of course, that's the reason I generally did an Alternative Stage 1 install from inside another distro (Knoppix once, SuSE once), because I only have the one system, and looking at a relatively useless console for two or three days while my mail piles up doesn't suit me (not a big Mutt user, and lynx annoys me). So this entire discussion doesn't have so much personal relevance to me, except that it means that I can just install Gentoo (in a couple of hours) should I ever need to do that again, rather than having to haul out a Knoppix CD or boot to my SuSE install because I want to (re-)install Gentoo (over a couple of days). Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] root password gremlin
Arturo 'Buanzo' Busleiman schreef: Alexander Skwar wrote: /etc/passwd like on HP-UX 11.00. Ie. no /etc/shadow. /etc/shadow was provided by an additional package and libraries. Just like PAM. Shadow changed from being a security measure to be an auth storage backend. As a storage backend, it needs libraries to access it. That's where PAM enters. No, that's where PAM *can* enter, but it *need* not-- eix shadow * sys-apps/shadow Available versions: 4.0.4.1-r4 4.0.5-r2 4.0.5-r3 ~4.0.6-r1 ~4.0.7 ~4.0.7-r1 4.0.7-r3 4.0.7-r4 ~4.0.11.1-r1 ~4.0.11.1-r2 ~4.0.12 ~4.0.13 Installed: 4.0.7-r4 Homepage:http://shadow.pld.org.pl/ Description: Utilities to deal with user accounts eix pam * app-vim/pam-syntax Available versions: 20030818 Installed: none Homepage: http://www.vim.org/scripts/script.php?script_id=735 Description: vim plugin: PAM configuration syntax highlighting * dev-perl/Authen-PAM Available versions: 0.14 ~0.16 Installed: none Homepage:http://www.cs.kuleuven.ac.be/~pelov/pam/ Description: Interface to PAM library * kde-base/kdebase-pam Available versions: 4 5 6 Installed: none Homepage:http://www.kde.org Description: pam.d files used by several KDE components. * net-mail/checkpassword-pam Available versions: 0.97 0.99 Installed: none Homepage:http://checkpasswd-pam.sourceforge.net/ Description: checkpassword-compatible authentication program w/pam support * net-www/mod_auth_pam Available versions: 1.1.1 ~1.1.1-r1 Installed: none Homepage:http://pam.sourceforge.net/mod_auth_pam/ Description: PAM authentication module for Apache2 * sys-apps/pam-login Available versions: 3.14 3.17 ~4.0.11.1-r2 ~4.0.12 Installed: none Homepage:http://www.thkukuk.de/pam/pam_login/ Description: Based on the sources from util-linux, with added pam and shadow features * sys-auth/pam_ldap Available versions: 156 ~161 ~164 ~167 171 176 176-r1 ~178 178-r1 180 Installed: none Homepage:http://www.padl.com/OSS/pam_ldap.html Description: PAM LDAP Module * sys-auth/pam_ssh_agent Available versions: ~0.1 0.2 ~0.2-r1 Installed: none Homepage:http://pam-ssh-agent.sourceforge.net/ Description: PAM module that spawns a ssh-agent and adds identities using the password supplied at login * sys-auth/pam_usb Available versions: 0.3.1 0.3.2 Installed: none Homepage:http://www.pamusb.org/ Description: A PAM module that enables authentication using an USB-Storage device (such as an USB Pen) through DSA private/public keys. * sys-auth/pam_smb Available versions: 1.9.9-r1 2.0.0_rc5 ~2.0.0_rc6 Installed: none Homepage:http://www.csn.ul.ie/~airlied/pam_smb/ Description: The PAM SMB module, which allows authentication against an NT server. * sys-auth/pam_ssh Available versions: 1.9 1.91 ~1.91-r1 Installed: none Homepage:http://pam-ssh.sourceforge.net/ Description: Uses ssh-agent to provide single sign-on * sys-auth/pam_dotfile Available versions: 0.7 ~0.7-r1 Installed: none Homepage: http://www.stud.uni-hamburg.de/users/lennart/projects/pam_dotfile/ Description: pam module to allow password-storing in $HOME/dotfiles * sys-auth/pam_passwdqc Available versions: 0.7.5 ~1.0.2 Installed: none Homepage:http://www.openwall.com/passwdqc/ Description: Password strength checking for PAM aware password changing programs * sys-auth/pam_mysql Available versions: ~0.4.7 0.5 ~0.6.0 Installed: none Homepage:http://pam-mysql.sourceforge.net/ Description: pam_mysql is a module for pam to authenticate users with mysql * sys-auth/pam_krb5 Available versions: 1.0 1.0-r1 ~20030601 ~20030601-r1 Installed: none Homepage:http://www.fcusack.com/ Description: Pam module for MIT Kerberos V * sys-auth/pam_pwdfile Available versions: ~0.99 Installed: none Homepage:http://cpbotha.net/pam_pwdfile.html Description: PAM module for authenticating against passwd-like files. * sys-auth/pam_require Available versions: ~0.6 Installed: none Homepage: http://www.splitbrain.org/Programming/C/pam_require/ Description: Allows you to require a special group or user to access a service. * sys-libs/pam Available versions: 0.77-r6 ~0.77-r8 0.78-r2 0.78-r3 Installed: none
Re: [gentoo-user] root password gremlin
Arturo 'Buanzo' Busleiman schreef: Holly Bostick wrote: As you see, all the relevant programs that *can* use PAM (which is *optional*) do *not* do so on my system. I do not need PAM authentication, and I do not use PAM authentication. As far as I know, my system runs fine (or at least has no PAM-related issues). I never said PAM was needed :P - I'm defending its usage. :) Well, defend it, then :-). Why should I-- who has further had (very) bad experiences with the use of PAM, give it another try, when my system clearly runs without it, which suggests I have no need for it? What overwhelming benefit can I gain, that will offset my previous bad experience and make what I (because of the bad experience) must consider a risking my system worthwhile? Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] root password gremlin
Alexander Skwar schreef: Patrick McLean schrieb: Running a system withoug pam is a rather strange thing to do on a modern Linux system, and I can think of very few reasons to do it. What do you need PAM for, when there's basically just one (human) user on the system and the system acts as a consumer (ie. no servers)? Why add the complexity of PAM? Where's the gain - in *THAT* scenario? What I found even worse than the irrelevancy of PAM in that situation (which is mine), was what Walter Dnes mentioned: everything you know is wrong when it comes to config files all over the place. You end up using entirely several different config files to control access. When PAM broke for me (as it did for so many others) during the Great PAM Debacle of a year or two ago, I was *shocked* to discover that I knew nothing at all about PAM configuration, and couldn't figure out anything about PAM configuration--despite having used Gentoo for a couple of years already and having figured out plenty of things that I had previously known nothing about. I was forced to stand by and watch as my authentication protocols progressively broke-- first GUI su (programs that pop up a dialog to give root privileges), then my DE login, then my console login. What distressed me the most-- even more than having to install another distro in order to ultimately do an alternative reinstall-- was that it was clear that PAM was mission-critical yet the first I ever heard of/dealt with it was when it broke. That seemed so un-Gentoo-like to me that I totally lost my bearings about the whole issue. By the time I got back from my dalliance with SuSE, people had figured out how to run a PAM-free system, ebuilds that had previously depended on PAM now had PAM optional and I was free to put -pam in my USE flags and hope to have a working system. Which I did, and do. I'm sure that PAM has a function, and that function is important for those who need a lot of authentication protocols to be passed to their machine (as in the case of servers that need to be protected). But for the average Jill or Joe like me, who runs no servers and doesn't have to ever do things like ssh into my machine (because I'm sitting right here), I think it's overkill and in this case, rather dangerous overkill, because if this unnecessary set of protocols ever does break (again), the average Jill or Joe is quite up the creek without a paddle. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] root password gremlin
Arturo 'Buanzo' Busleiman schreef: and, *on the other hand*, the whole point of using free, open source software, is usually to get hands-on software on a lower level than in windows like platforms. That's what I wanted to say. Most gnu/linux/oss users like screwing up their systems :P I understand your point, Arturo, but (list-- save this mail, becaue this is likely the only time you'll ever hear me play devil's advocate on this issue, and you'll want the proof if you ever want to throw it up in my face) you're just not right. What you're basically saying is that Linux is for geeks and aspiring geeks (who enjoy and have time to screw up their systems and get hands-on software on a lower level than in Windows-like platforms), and even if this 1) was historically true; 2) is in some respects still philosophically true, it is not *functionally* true at this time, and it will become less functionally true as time goes on. The general thrust of the OSS/GNU/Linux movement at this time is distinctly towards attaining some kind of comfort zone for former Windows users, and former/current Windows users do not care to get hands-on software, they do not care to screw up their systems (since that means a reformat and reinstall most of the time), and they are paralyzed like a deer in the headlights of an oncoming semi at the very mention of CLI or ($DEITY forfend) man pages (that must be read via the CLI). These are people who cannot conceive that breaking X does not mean you can't use your system (because under their previous OS, the GUI *was* the OS, not like here where X is just another program). To increase our userbase, the users must come from the proprietary OSes-- it's not like there's a whole herd of loose first-time users just roaming the plains. These are owned users, some of whom have realized that the barn is burning down around them and have the good sense to run. That doesn't mean that they are capable of coping in the wild, just because they have been forced out into it, and it doesn't mean that they ran out into the wild because they wanted to be free. I admit the reason I first dual-booted was because I personally never liked Windows, and hated the inability to understand what my system was doing. But the reason I've stayed with Linux is not because I like screwing up my system; it's because I really really hate Microsoft's policies and I refuse to submit to them, and I'm willing to take a h-e-double-hockey-sticks of a lot of pain (and it has been painful at times, and-- at many fewer times-- it still is) to back my own refusal. I admit I enjoy the triumph of overcoming the many obstacles I've encountered in this journey, but I'm just weird (very hardheaded. That doesn't mean I ram my head into walls for *fun*, though). Most average users have no interest in overcoming obstacles just to I dunno, rip a DVD (you don't want to know how painful it was learning how to use transcode, or how long it took), or to play Morrowind or Need for Speed Most Wanted. And I can't and don't blame them for that, nor do I expect them to be like me. They are going to have to change to some extent if they want to switch, that's true. There's no other way, and it's unfortunate that most average users are completely unaware of the gravity of changing their OS before they do it. But that's not the same as expecting them to magically *be* different than what they were, and have different expectations than what they've had their entire computing life, just because they switched to Linux, for reasons that are their own, not yours or mine. Tolerance is difficult too, but the first step is recognizing that different people are actually different-- and then finding a way to live with that. We're still working on that second part. SuSE has one way, Ubuntu has another, Linspire has a third direction, and Gentoo yet a fourth. But it's very much not as if a SuSE user wants to get hands-on with their system (you really hardly can do that with SuSE). Surely a Linspire user is not prepared in any way to do so (the Linspire target market is most definitively not the geekish), and even Gentoo users complain(ed) about the complexities and length of installation, despite the extraordinarily copious documentation (perhaps no longer so much needed with the recent switch to Stage 3 default). So no, I do wish I could agree with you (it would certainly be a more comfortable environment for me than what we actually have in terms of geek-friendliness), but I just cannot. Holly -- Then anyone who leaves behind him a written manual, and likewise anyone who receives it, in the belief that such writing will be clear and certain, must be exceedingly simple-minded. (Plato) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] revdep-rebuild fails
James Colby schreef: Thanks, revdep-rebuild did give me the list of files that would not link, and equery belongs FILENAME tells me that the files are part of the kde-base/kdelibs-3.3.2-r7 package. Is there a way for me to find out which packages on my system depend on kdelibs-3.3.2-r7? Thanks, James Am I missing the reason you don't just upgrade to a version of KDE 3.3.2 which *is* in Portage? It's not as if kdelibs has radically changed its contents between revisions of kdelibs-3.3.2-r-whatever: eix kdelibs * kde-base/kdelibs Available versions: 3.3.2-r10 3.4.1-r1 3.4.1-r2 3.4.2 3.4.2-r1 3.4.3 [M]3.5_beta1-r1 [M]3.5.0_beta2 [M]3.5.0_rc1 Installed: 3.4.3 Homepage:http://www.kde.org/ Description: KDE libraries needed by all kde programs The current revision of the 3.3.2 series is -r10, an upgrade from -r7. I suppose you could unmerge -r7 first, but frankly I don't see why it wouldn't suffice to simply do an emerge -ua** kdelibs and then re-run revdep-rebuild. Has the overwhelmingly obvious reason that this is not doable somehow escaped me (always possible)? Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Radeon 9200/Xorg refresh rate
Richard Fish schreef: On 11/17/05, Holly Bostick [EMAIL PROTECTED] wrote: The point being, you need to know your monitor's specs. Back in the day, that was true. But with modern monitors (I'm not sure of the spec, I think is part of the VESA compliance requirements) the video driver can query the monitor for what refresh rates and modes supported by the monitor. Back in the day, indeed! True, but all monitors currently in use or available for sale are not necessarily compliant with the spec, or with the current spec. Perhaps they're older models, hand-me-downs or remaindered at a store. Compliance or incomplete compliance with specs such as VESA are not particularly a deal-breaker (or even much mentioned) when buying a monitor, and there's no explicit reason that anyone might choose a modern monitor rather than a remaindered one (a model that is no longer actively produced by the manufacturer, but unused units of the product remain at the store's warehouse), and of course if one buys an off-the-shelf computer (Compaq, HP, Packard Bell) that comes with a monitor, you have no idea or choice what you in fact are getting in terms of modernity-- most likely such a no-longer-produced model is the one provided, to reduce costs. Because, really, if the monitor displays acceptably, why should Compaq or HP or PacBell particularly care to provide the very most recent model, for which they must pay more (and pass the extra cost on to the end buyer)? How many people actually ask the monitors specific specs in such a situation? And further, monitors may be actively limited in specification, the way mine is. I'm almost sure that I've tried autodetection at least once (when the head of the ATI team said that the new drivers were better served by having a relatively empty xorg.conf, and that autodetection was now working in fgrlxconfig/aticonfig). Unsurprisingly, my monitor was again limited to [EMAIL PROTECTED], and I had to insert my refresh rates in order to get [EMAIL PROTECTED] But of course, since the actual monitor specs are not all that critical to the average user, the average user who owns this model probably doesn't even know that the monitor is capable of 1280x1024 (and if they want that resolution, they buy a new monitor), and are satisfied to eat what they're given, as it were. That's fine for those who find it fine, but I've gotta say, it really burned me, just on the principle of the thing, to discover that my monitor was had capabilities that were actively concealed from me, for my own protection I suppose. This is what the DDC module in X is for, and why monitors no longer require 'drivers' (which was never a 'driver' anyway, just a .inf that told the video driver what the possible modes were). All monitors do not correctly report their DDC information, flatly put. Sometimes because of active limitation as I experience, or because they're cheaply made (just well enough to hit the mark, rather than with strict compliance to spec), or simply because they were made before the spec was implemented. After all, on anyone's standard upgrade list, how high priority is really the monitor, as opposed to the CPU, the mobo, the memory, the video card-- even the sound card or network hardware? Who really bothers if the monitor works (meaning, displays without corruption)? All of which means, yes, you have a point, and in many (possibly even most) situations you're probably right, but there is still a place for knowing your monitor's actual specifications, and there is still a place/reason for inserting such specs actively into xorg.conf. I stand by know your specs. :-) . Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: udev: lost dvd
Neil Bothwick schreef: On Fri, 18 Nov 2005 16:19:58 + (UTC), James wrote: Do the (2) layer NEC devices, such as the NEC ND-3540A work on linux? It works, whether it works in DL mode I have no idea as I haven't tried it. DL discs are so expensive. Is there anything special about the way DL discs are written, or does the drive recognise the medium and write accordingly? LOL, Neil-- I have a NEC 2510A and I have the same problem-- never tried DL, because the disks are too expensive (and I don't really have any desperate need to burn a DL disk to make it worth my while). But I have no reason to suspect that it *wouldn't* work, insofar as the drive otherwise works correctly. I suppose that so long as K3b is capable of doing whatever needs to be done to manage a DL disk, then burning one should work fine as well. However, I have not investigated whether the common burning tools are capable of doing whatever needs to be done, and in fact, I don't know precisely what needs to be done different (if anything does), and I would like to know the answer to your question as well. On the other hand, I have great faith in K3b, and I do think that when I need it to burn DL disks, it most likely won't bat an eye. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Radeon 9200/Xorg refresh rate
Mark Knecht schreef: On 11/17/05, Michael Kjorling [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a ATI Radeon 9200 graphics card (lspci says ATI Technologies, device 5940, rev 01) which currently drives my monitor at 48.5 kHz 60 Hz 1024x768 using x11-base/xorg-x11-6.8.2-r4 and the radeon driver. I would like to raise the refresh rate to 75 Hz. How do I do that? Various Google searches have turned me up empty, except that possibly the answer lies in the ModeLine used. Is that correct and if so, what values would I need to tune to adjust the refresh rate? /etc/X11/xorg.conf says that the vertical refresh rate is 50-90 Hz. Generically modeline is the path to doing this. (I think...) I've done similar things using this site: http://koala.ilog.fr/cgi-bin/nph-colas-modelines That's a good suggestion, but what all the replies so far seem to miss is the fact that refresh rate is a *monitor* setting, not a video card setting (although, because the monitor is a part of the X server-- along with the video card, mouse, and keyboard-- the possible refresh rates are also set in xorg.conf). So the possible refresh rates for any given resolution rely on the monitor's capabilities, not those of the video card. From my own experience, this can sometimes be tricky, depending on the monitor. For example, my monitor is a 17 Eizo F550i-W. From the Eizo site (I don't have a manual, as this was a hand-me-down from an office that was upgrading), I found that the monitor is capable of 1280x1024-- but [EMAIL PROTECTED], which many people find uncomfortable. That's not the problem, though, if I want to use 1280x1024 (which I do); the problem is that Eizo lists their monitor under both Windows and X, meaning that they provide drivers for it, which I can use by selecting the monitor's manufacturer and model during setup (under either Linux or Windows). Except that the manufacturer-provided drivers are *limited* by the manufacturer, to the optimal resolution of [EMAIL PROTECTED] So under either Linux or Windows (when I was still using Windows), I could not use the manufacturer-provided drivers for the monitor, if I wanted to use a resolution of 1280x1024-- that resolution was not available, because the monitor only displays that resolution at 60Hz, and Eizo doesn't want me to use a 60Hz resolution. The only way I am able to set my desktop to [EMAIL PROTECTED] is to not use the manufacturer-provided driver; under Windows I used Generic VESA 1280x1024, and under X I must set my Horizontal and Vertical refresh ranges manually (provided on the manufacturer's site, or in a manual, if I had one). Under X, as long as the ranges are set correctly, X knows that the monitor can display at 1280x1024, and sets the refresh to 60 automatically for that resolution (because the ranges I've given tell it the correct combination of possible resolutions and refresh rates that can be displayed). The point being, you need to know your monitor's specs. Is it in fact capable of displaying [EMAIL PROTECTED] If so, the same place that told you that should tell you the refresh ranges of the monitor. Plug those into xorg.conf rather than whatever defaults might be there (which for me are usually off by quite a bit, especially the horizontal range), and the problem should sort itself after restarting the X server. You can also do this with modelines, but I don't understand them (meaning, I can't look at a modeline spec and know what it's trying to do so that at need I could plug in my own), and so don't bother with them. Hope this helps. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Local dictionary in KDE?
abhay schreef: On Wednesday 16 Nov 2005 4:25 am, Willie Wong wrote: An option to skip installing dictd is to install the commandline version of StarDict, http://sdcv.sourceforge.net/ Last I checked it is not in portage. It doesn't really work like Kdict, but suits my needs well enough. Ok so I installed sdcv but for every word I search the output is Nothing similar to word, sorry :( Do I need to install something else as well? Also the download size is just 163KB and I seriously doubt that it contains dictionary files. What am I doing wrong? Abhay It would seem that you need some dictionaries: From sdcv homepage: SDCV is simple, cross-platform text-base utility for work with dictionaries in StarDict's format. This does not suggest that sdcv actutally *has* these dictionaries contained within it. But likely whatever is missing can be found at the stardict site http://stardict.sourceforge.net/ Dictionaries would seem to be found at http://stardict.sourceforge.net/Dictionaries.php which at the top of the page has links to several sites containing stardict dictionaries, and then the page itself gives instructions on how to insert them into the program; or perhaps /stardict-ed/ , a fork of stardict which is now known as wisedict (found at http://wise.sourceforge.net/ ) WiseDict is a computer dictionary based on StarDict may also contain some dictionaries by default. Hope this is helpful in some way. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] what z p2p clients for linux?
Csányi András schreef: 2005/11/15, El Nino [EMAIL PROTECTED]: dear friends, what is the best p2p (Gnutella support) client for linux? -- IMHO the best is MLDONKEY Not if you've ever used aMule--- but El Nino asked for a p2p client with *Gnutella support* so I see your point. However, the Donkey client on MlDonkey is so close to death (you'll get errors from servers that refuse to connect, saying that your client is too old please update, even if you have the most recent 'free' version-- it took me *ages* to figure out that this essentially meant 'switch to aMule, you dope!'), that one might as well just use a dedicated Gnutella client rather than something like mldonkey, which is supposed to support multiple networks, but didn't seem to in fact do so (didn't try gnutella support, but I couldn't get the torrent support to work at all, meaning that mldonkey accepted torrents for download, but could not connect to trackers or clients), and whose 'native' network seems to have reached its eol. In this case, multi-protocol clients do not seem to be preferable to multiple clients, each one dedicated to whatever network you use. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: realplayer download security problem
James schreef: How does a gentoo system know the difference between an rpm file that it can install and a rpm file that it cannot or should not install on a gentoo system? It's not like RPMs (or DEBs for that matter) just *appear* on the system and are installed by mental telepathy if you emerge an ebuild for which the package file is an RPM (RealPlayer and the ATI proprietary drivers are two which come to mind), then that is what will be installed. The Portage system knows what files are available to it, because that's what the Portage tree is for. For example, the Cedega binary package is available as an RPM, a DEB amd a TGZ-- but if you attempt to install it (it's a fetch-restricted package, which requires subscription to download, so you have to download it and put it in /usr/portage/distfiles yourself by default) it's not like Portage wants any of the three. It wants specifically the -small.tgz, and you could put the RPM in distfiles if you wanted, but Portage wouldn't install it. Because that's not the package that the ebuild specifies. Of course, you could install rpm and install any rpm you wanted with it-- but since you don't have an RPM database, and even if you did, all the dependent libraries and system files wouldn't be in it (because they were not installed from RPM), it would be likely to end in tears (which would be no less than one deserved, since if one wanted to use RPMs so bad, one should have installed a binary distro that depends on them and not a source-based distro like this one :-) ). In any case, the relatively few RPMs in the Portage tree are generally there (afaik), because we don't get a choice about it-- the binaries provided (usually by some proprietary source) are only packaged *as* RPMs, so if we want or need them, that's what we have to use. Certainly that is the case for the ATI drivers, and likely for the RealPlayer package as well. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: realplayer download security problem
Nick Rout schreef: [1] The easiest way i have found to look inside an rpm is to use midnight commander (mc) and hit enter with the rpm highlighted. You get a virtual look inside the rpm, including all the metadata, the install scripts, and the files to be installed. The rpm package must be present on your system. mc can be used in this way to look inside zipped files, tar files, bzipped files etc etc. You can also do this (look inside an RPM) with: -Krusader (KDE file manager) -KFM (Konqueror; at least I could under SuSE, and while you of course don't get the SuSE-added patch functionality of being able to Install (the RPM) with YAST directly from Konq, I believe the ability to open the archive is native to Konq) - Any GUI archive program (file-roller, KArchiver, etc). Simplistically speaking, an RPM is just another kind of archive, so most any application that can look inside archives (transparently or dedicated) can do this, for those of you who are not big terminal geeks. But even if you're not a big term geek, mc has a lot to recommend it (especially if you don't happen to have X available), and this is one of the abilities that makes mc worth remembering and encourages one to use a terminal every once in a while (or more often-- more cli applications than one might imagine are extraordinarily functional, and that high function makes them cooler than one might expect). Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: [Iptables related] How to make one machine only talk on loc lan
Harry Putnam schreef: Apparently you too are not looking at the router I've specified: NETGEAR FVS318 Not to mix in (not having a Netgear router), but I wonder if perhaps the reason you are not seeing the ability to block IPs (which several people have said exists) is because you have not enabled it by setting a schedule: John Jolet [EMAIL PROTECTED] writes (twice): look at the schedule setups. set them up only to be able to access the internet for, say a second on sunday at 3 am, and not for the rest of the time here. you set a schedule, then limit certain ip addresses As I said, I'm not familiar with this router, but I am familiar with the concept of options not becoming enable-able (and often even visible) until some precondition has been met (in this case setting a schedule). Certainly it would not seem logical for a high-end router *not* to be able to block IPs (and fairly thoroughly), especially if lower-end models of the same brand are capable of doing so; certainly it seems possible that such a device would not be interested in knowing what you want it to do (ip blocks) if it didn't have a category under which to perform the series of actions (the schedule). Just an idea, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Xorg.. twm not starting and terrible performance with fluxbox
Mrugesh Karnik schreef: Richard Fish wrote: The via_drv I am talking about is an _x.org_ driver, not a kernel driver. It has nothing to do with the kernel sources or rebuilding the kernel. It should exist at /usr/lib/modules/drivers/via_drv.o (along with all other X11 drivers). I know! My xorg just doesn't want to compile that file! So what I tried was to enable the VIA drivers in the kernel. It then compiled both drm.ko and via.ko and also via_drv.o, but the via_drv.o never left the /usr/src directory. Possibly because you don't have the 'insecure-drivers' USE flag enabled: On 11/10/05, Mrugesh Karnik [EMAIL PROTECTED] wrote: carcharias rjf # equery belongs /usr/lib/modules/drivers/via_drv.o [ Searching for file(s) /usr/lib/modules/drivers/via_drv.o in *... ] x11-base/xorg-x11-6.8.2-r6 (/usr/lib/modules/drivers/via_drv.o) carcharias rjf # emerge -vp x11-base/xorg-x11 These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] x11-base/xorg-x11-6.8.2-r6 -3dfx -3dnow +bitmap-fonts -cjk -debug -dlloader -dmx +doc +font-server -insecure-drivers +ipv6 -minimal +mmx +nls -nocxx +opengl +pam -sdk +sse -static +truetype-fonts +type1-fonts (-uclibc) -xprint +xv 0 kB /usr/portage/profiles/use.local.desc:x11-base/xorg-x11:insecure-drivers - Builds insecure DRI stuff for via, mach64 and savage You might as well try it; you can't be much worse off. I just can't understand why the file isn't compiled by xorg. Not to mention, FC4 uses vesa and works perfectly. I wonder what's going on with Gentoo :( Like most binary distros, the FC RPMs probably enable everything 'enableable'. I have no idea why the drivers are considered 'insecure', but assuming they are (which would not surprise me), it's well within the realm of possibility that they fall under the you have to know what you're doing and decide for yourself' section of the Gentoo design philosopy (which is the major thrust of the Gentoo design philosopy, so that doesn't surprise me either). Why FC 4 would enable them and Gentoo would mark them as insecure well, heck-- FC4 uses GCC 4.0 *by default* as I understand it, and we have it completely masked (and most other distros don't use it either, afaik, certainly not by default yet). So since FC4 seems to want to live even further out on the 'bleeding edge' than we are said to do, again, I'm not surprised that the drivers would be enabled by default, no matter their status in terms of security, completeness, or stability. HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] strange problem with fam USE-flag
Rumen Yotov schreef: Hi, Recently (last two days) when running:emerge -DNu world -ptv receive the following: ... #emerge -DNu world -ptv These are the packages that I would merge, in reverse order: Calculating world dependencies ...done! [ebuild R ] mail-filter/maildrop-2.0.1 +berkdb -debug +fam* -gdbm -ldap -mysql -postgres 0 kB [ebuild R ] net-mail/courier-imap-4.0.1 +berkdb -debug +fam* -gdbm +ipv6 +nls (-selinux) 0 kB Total size of downloads: 0 kB ... In first look nothing strange, only i don't have/use fam (use 'gamin' instead). More info,no fam in /etc/make.conf: grep fam /etc/make.conf nothing. So must be some issue with virtuals. In maildrop-2.0.1.ebuild there is the following: ... Now don't need to post this as a question, thing are clear. Gamin also provides virtual/fam although it's gamin not fam. Just a confusion with fam USE-flag. Post this for info only. Thanks. This happened to me yesterday, except with a twist. For a change, I did an emerge -uaDNtv world instead of without a --newuse like normal, and I got a block, because of emelfm2: Calculating dependencies ...done! [ebuild R ] app-misc/emelfm2-0.1.2 +fam* -gamin +nls -utf8only 0 kB [1] Total size of downloads: 0 kB Portage overlays: [1] /usr/local/portage Now, since I use gamin, fam wanted to install, and was (naturally) blocked by gamin. Fortunately, emelfm2 has a 'gamin' USE flag, so I just disabled fam and enabled gamin to clear the block. Comparing this to your situation, it looks like 'fam' is a new USE flag, enabled by default (since fam is installed by default). I don't really have much of a problem with that-- except I misss the corresponding 'gamin' USE flag for the programs you are upgrading. However, I also assume that these programs may not be able to use gamin, or have not been updated to use a virtual/fam rather than fam itself. Either way, I would be clued that these programs were out of date in some respect, and would start checking their current status on the web page: are they currently maintained? are there plans to enable gamin support? If not, then I would check Bugzilla to see if a bug had been filed to allow for virtual/fam instead of fam directly. If not, I would copy the ebuilds to my overlay and modify them to take a virtual/fam, and install those. If they worked that way, I would submit the modified ebuilds to b.g.o. My 2 eurocents (which we don't even have anymore), Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: vlc dies on GL
James schreef: Hmmm. I not sure I did compile the ati-drivers: media-video/ati-drivers Available versions: 8.14.13-r2 [M]8.14.13-r3 8.14.13-r4 8.14.13-r5 *8.16.20 *8.16.20-r1 8.18.6 8.18.6-r1 8.18.8 8.18.8-r1 Installed: none Well, depending on which ATI video card you have, the ati-driver package may be the only one which supplies OpenGL for your video card's chipset (above the 9250 must use the drivers, 9250 and below can use the kernel 'radeon' driver and X.org MESA to get OpenGL support). So if you're getting an error in OpenGL, that may be because you have no video drivers with OpenGL support installed. HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: vlc dies on GL
Richard Fish schreef: If you want to try the ati-drivers, generally you just need to merge the package and change the Driver setting in xorg.conf from radeon to fglrx. Not completely true; the ati-driver module (fglrx) will not work if the kernel DRM is compiled (either as a module or statically). Further, the driver has an included agpgart, but this does not cover all mobo agp chipsets (no idea which ones it does cover, but not mine apparently)-- so while the kernel agpgart must be available (preferably as a module, since the fglrx install script checks this before it will compile), depending on whether you need to use the internal (fglrx) agpgart, or an external one (from the kernel; I use via-agp), one may need to do some kernel voodoo (compiling the correct agpgart for your mobo) or some xorg.conf voodoo (turning on UseInternalAGPGART yes or no), some /etc/modules.autoload.d/kernel-2.6 voodoo (to load your agpgart before the driver agpgart), or possibly even some /etc/hotplug/blacklist voodoo (to prevent the kernel DRM from loading, because if the kernel loads its own DRM, the ATI DRM won't load, and the driver does not work with the kernel DRM). It's quite likely that several forms of voodoo will be necessary. Apparently the fglrx module does not work in combination with the radeonfb driver, either, so if one used that, and the driver did not work, one might not know why. In any case, the fglrx requires a specific kernel configuration in order to work even as well as it does (which may, or may not, be that well, depending on what you want to do with it), and switching to it is not necessarily a matter of simply changing the setting in xorg.conf. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge kino problem
Nick Rout schreef: On Wed, 09 Nov 2005 13:34:59 +1000 Richard Watson [EMAIL PROTECTED] wrote: !!! If you need support, post the topmost build error, NOT this status message. In other words, please post the 10-20 lines *above* the lines you posted (which were the status report); the actual compile error will be found there. And there's no way to know what happened without seeing the error itself. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
Norberto Bensa schreef: Peter Ruskin wrote: ebegin Checking that /usr/src/linux is linked to booted kernel... if [ /usr/src/linux-$(uname -r) != $(ls -l /usr/src/linux|cut -f2 -d\|cut -f2,3,4 -d' ') ] This looks more complicated than it really should be. Just run ln on reboot (stolen from your post): rm -f /usr/src/linux ln -s /usr/src/linux-$(uname -r) /usr/src/linux Thanks for the tip-- but (no offense meant) who cares? Can someone tell me on what basis this *needs* to be done as a standard operation? -- If you have some external module that compiles against the kernel source, you most likely need it against *all* kernel sources, not just the running one (so redirecting the link is only of limited usefulness); -- If you need some external module compiled against the kernel source and you don't have it (thus needing to compile it against the currently running kernel), then there's likely to be something seriously wrong with that boot anyway (you don't have 3D hardware acceleration, you don't have wireless networking, you don't have sound-- whatever the external module in question is), so you're much less likely to boot it as a matter of course... Not that you wouldn't want to try to fix it, and if you did try, you would naturally want to compile the external modules against that kernel source, but that doesn't by a long shot add up to redirecting the /linux symlink every time you boot; --makes no provision for newly-installed/upgraded kernel sources, which imo need the symlink more than old, already compiled kernels. Or rather, if you redirect the symlink to the currently running kernel at boot, you have to redirect it again to your about-to-be-installed kernel in order to compile the external modules against it anyway, so why do extra work-- either you wait till you compile and boot the new kernel to redirect the symlink (at which point you've got a half-broke system because the needed external modules have not yet been compiled because the symlink was not redirected unless you use the symlink USE flag when emerging, which rather negates the point of having redirected the symlink to the currently-running kernel), then compile the external modules, then reboot to load the external modules (depending on the module), or you redirect the symlink manually before compiling the newly-installed source, which (again) negates the purpose of redirecting the symlink automatically at boot (rather than via the USE flag during emerge) in the first place? Not getting it at all. How many kernels does one keep in a bootable state, anyway-- and use commonly, without needed external modules, no less-- that this would be necessary? Really, truly, not getting the point. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
Digby Tarvin schreef: On Wed, Nov 09, 2005 at 03:35:42PM +0100, Holly Bostick wrote: -- If you have some external module that compiles against the kernel source, you most likely need it against *all* kernel sources, not just the running one (so redirecting the link is only of limited usefulness); Ok - this seems to be the bit that I am a little unclear on. If there are, as indicated in your earlier response (which I was still mulling over) applications, libraries and external kernel modules that need to be compiled against a kernel, Not against a kernel. Against a kernel *source*. These are not the same thing. The kernel you actually boot is a binary file, compiled from the source in /usr/src/whatever. When it is compiled, you copy the binary to /boot, and that is what you boot. That is the meaning of 'make install'. Like any binary, once compiled it is 'detatched', let us say, from the source, and is no longer related to it in that any changes to the source do not affect the compiled binary-- if you make a change to the source, you have to recompile the binary to reflect the changes in the new binary. and we want to be able to use grubs ability to select from a choice of kernels, what is the mechanism by these we ensure the correct applications, libraries and external kernel modules (lets call them 'objects' to avoid having to list the possibilities each time - not to be confused with the current trendy programming paradigm) are used for the currently running kernel? If you compiled the objects against the source of the kernel under consideration -- and this is the purpose of the /usr/src/linux symlink, to tell the emerge which kernel source the objects should be compiled against, then they are compiled against the source of the kernel Let me put it this way. ati-drivers (the proprietary drivers for ATI video cards) are an external kernel module. External, because they are not contained in the kernel source (being proprietary), but a kernel module because they 'hook' into the kernel as a normal module. When I compile them, here is the beginning of the output: Determining the location of the kernel source code Found kernel source directory: /usr/src/linux Found sources for kernel version: 2.6.13-gentoo-r4 Checking for MTRR support enabled ... Checking for AGP support enabled ... Checking for DRM support disabled ... X11 implementation is xorg-x11. | Unpacking source... Unpacking Ati drivers ... The drivers, like all other drivers, need certain kernel functions to be available (or not available) in order to operate correctly; so because this driver must compile against the kernel source, the script checks to confirm that the necessary kernel functions are enabled/disabled prior to compiling.This is why you must compile against a *configured* kernel source (it need not be compiled, but it must be configured, so that the script can determine what functions will be available in the kernel binary). As you see, this emerge of the ATI drivers compiled against the source of 2.6.13-gentoo-r4, because that was where the /usr/src/symlink was pointing when I performed the emerge. This was in fact an upgrade to the driver, and 2.6.13-r4 was my currently-running kernel. However, later, I downloaded and configured 2.6.14, and re-emerged the ATI drivers (I use the symlink USE flag, so the symlink was automatically redirected): Determining the location of the kernel source code Found kernel source directory: /usr/src/linux Found sources for kernel version: 2.6.14-gentoo Checking for MTRR support enabled ... Checking for AGP support enabled ... Checking for DRM support disabled ... X11 implementation is xorg-x11. | Unpacking source... This emerge compiled against the source of 2.6.14-gentoo, because the /usr/src/linux symlink was redirected to the source of that kernel. Both kernels now have the ATI drivers compiled for them, because when compiled (either during a kernel compile, or an external module compile), modules are placed in a kernel-specific directory: la /lib/modules totaal 9 drwxr-xr-x 12 root root 384 nov 7 15:43 . drwxr-xr-x 12 root root 5688 nov 7 16:34 .. drwxr-xr-x 5 root root 472 mei 25 17:29 2.6.11-ck8-r1 drwxr-xr-x 4 root root 448 jul 24 00:04 2.6.11-gentoo-r11 drwxr-xr-x 5 root root 472 jun 15 03:06 2.6.11-gentoo-r6 drwxr-xr-x 5 root root 472 jul 7 02:17 2.6.11-gentoo-r8 drwxr-xr-x 6 root root 496 okt 13 14:53 2.6.12-gentoo-r10 drwxr-xr-x 4 root root 448 aug 19 06:36 2.6.12-gentoo-r6 drwxr-xr-x 4 root root 448 sep 2 05:39 2.6.12-gentoo-r9 drwxr-xr-x 6 root root 496 nov 7 18:30 2.6.13-gentoo-r4 drwxr-xr-x 6 root root 496 nov 7 19:03 2.6.14-gentoo and within it: la /lib/modules/2.6.13-gentoo-r4/video totaal 317 drwxr-xr-x 2 root root 72 nov 7 18:00 . drwxr-xr-x 6 root root496 nov 7 18:30 .. -rw-r--r-- 1 root root 321951 nov 7 18:00 fglrx.ko la /lib/modules/2.6.14-gentoo/video totaal 317 drwxr-xr
Re: [gentoo-user] Beautified kernel config
Mark Knecht schreef: On 11/9/05, Richard Fish [EMAIL PROTECTED] wrote: On 11/9/05, ellotheth rimmwen [EMAIL PROTECTED] wrote: G'afternoon, list, silly question for you. Often here or in the forums, a user will post a snippet of his kernel configuration, a la snip Bus options PCCARD * PCCard (PCMCIA/CardBus) [ ] Enable PCCARD debugging * 16-bit PCMCIA support * 32-bit PCMCIA support /snip and so forth. Assuming it hasn't been typed by hand, where does the pretty formatting come from? Copy-n-paste from 'make menuconfig' helps some, but mostly, I type them by hand. -Richard Cut-n-paste and then a bit of hand editing for me. - Mark Ditto, usually select-copy and middle-click-paste from make menuconfig to the compose window, and then hand-edit. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] portage: fixed or not???
Neil Bothwick schreef: A recent update to dovecot stopped it completely until you updated the config file. I suppose you could fix that with a cron job that did echo -5 | etc-update :-) My goodness, Neil-- are you aiming to be the next Stephen King? You certainly have an eye for true horror. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] X freezes locks up, constantly
Phill MV schreef: Every now and then, usually while doing something related to firefox ( mozilla-firefox-1.0.7-r2) but it's also happened when someone sent me a file over MSN in gaim (gaim-1.5.0), my copy of xorg-x11-6.8.2-r4 will lock up and refuse all interaction. All windows stop responding; xmms keeps playing; keyboard locks up and the mouse, although free to wiggle around won't cross from one screen to another. Logging in from another machine over SSH, top reveals that X is occupying 90-something% of the CPU; killing individual applications like firefox or xmms doesn't do anything but killing X gives me back a working, functional login screen. This is, as you might imagine, amazingly annoying. For whatever reason, it'll happen when I click specific links in Firefox (i.e. my professor's labs assignments link) snip Before going further, let me say that I agree that X is becoming a real annoyance. I'm at this very moment upgrading to the unstable version (6.8.2-r6, not the masked pre-7.0 versions; I'm not that desperate :-) ) to see if it helps. That said, this would seem to be an interaction between 'problems with X' and 'problems with Firefox' (we've had discussions of the increasing memory usage of Firefox lately-- it may well be that both these sets of issues are manageable on their own, but together, Firefox becomes the straw that breaks the back of X. So try using another web browser for a while. I myself like Galeon for my alternate browser, but there's Epiphany, Dillo, Konqueror (of course), kazehakase, w3m, amaya, skipstone, and of course the text-based browsers such as links, lynx and so on. I would avoid Mozilla, because it's about the only thing that could possibly be yet more bloated than Firefox is becoming. In any case, see if the problem persists when using another browser; if it doesn't, then at least you can do your work, if it does, perhaps we'll get more information as to what is going wrong. Hope this helps, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
Digby Tarvin schreef: Something which I havn't found any explicit elaboration of in the documentation... The convention in the Linux/gentoo filesystem seems to be to have a unique directory for each installed kernel in /usr/src, with a symbolic link to the 'current' kernel directory named /usr/src/linux.. The question is - is this just a user convenience, or will parts of the system break if it is not maintained correctly? The reason I ask is that if I have several kernels which I have configured grub to allow me to select from at boot time, where should this symlink point? The newest kernel? An experimental one being worked on? The one most recently booted from. If the latter case then it is likely to be wrong for a finite period following boot until the system has come up far enough to allow me to update it. The symlink has nothing to do with the compiled kernels in /boot at all. What it has to do with are applications, libraries and external kernel modules that are compiled against the kernel source. For example, ati-drivers is a kernel module which compiles against the kernel source. In order for it to do so, it needs to know what kernel source to compile against. The easiest way for it to know that is for it to seek the target of the /usr/src/linux symlink, which generally points to either 1) the source of the currently running kernel, or 2) the source of the kernel that *will* be the currently-running kernel, after you compile/install/reboot to it. Anyone know what is likely to break (if anything) if I boot from a kernel other than the one which corresponds to the directory /usr/src/linux points to, and neglect to update the link? Does it direct (for instance) the target directory for an emerge of new kernel components? Or does it perhaps have to point to the kernel being built during any recompile? Nothing, no (all internal kernel components are in the kernel source, and if you are emerging external kernel modules, they'll just be compiled against some other kernel than the one you're booting to, so they won't be available for that kernel-- but that is not, strictly speaking, broken), and no, whatever recompile you might be doing is unrelated to the symlink, unless it involves external kernel modules or one of the relatively rare applications or libraries that compile directly against the kernel source. You might consider, however, activating the symlink USE flag, which will update the symlink when you install a new kernel source. Hope this helps. Holly Regards, DigbyT -- gentoo-user@gentoo.org mailing list
[gentoo-user] Big problem with module-rebuild
.. and that problem is, in short, that the rebuild unmerges the previous version, in the currently-running (or previous) kernel modules folder, breaking the previous kernel. And my question is, how to get it to stop doing that. If Portage has a FEATURES setting that prevents the previous version being unmerged this way, I don't know what it is. Example: I'm currently using 2.6.13-gentoo-r4, and am compiling 2.6.14-gentoo. /usr/src/linux points to 2.6.14-gentoo. module-rebuild rebuild ** Preparing to merge modules: ** Packages which I will emerge are: =sys-fs/submount-0.9-r2 =media-libs/svgalib-1.9.23 =media-video/ati-drivers-8.18.8-r1 Now, taking the most important of these modules, let's look at what happens with ati-drivers (it's most important because X is set to use it, and naturally X won't start if the driver is not found). | emerge (3 of 3) media-video/ati-drivers-8.18.8-r1 to / snip * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found sources for kernel version: * 2.6.14-gentoo * Checking for MTRR support enabled ... [ ok ] * Checking for AGP support enabled ... [ ok ] * Checking for DRM support disabled ... [ ok ] * X11 implementation is xorg-x11. So, the drivers are going to compile against 2.6.14, which is what I want, and correct. So far so good. | Unpacking source... * Unpacking Ati drivers ... [ ok ] * Applying fglrx-2.6.14-access_ok.patch ... [ ok ] | Source unpacked. * Building the DRM module... make: Entering directory `/usr/src/linux-2.6.14-gentoo' snip make: Leaving directory `/usr/src/linux-2.6.14-gentoo' | Test phase [not enabled]: media-video/ati-drivers-8.18.8-r1 | Install ati-drivers-8.18.8-r1 into /var/tmp/portage/ati-drivers-8.18.8-r1/image/ category media-video * Installing fglrx module snip --- /lib/modules/ --- /lib/modules/2.6.14-gentoo/ --- /lib/modules/2.6.14-gentoo/video/ | /lib/modules/2.6.14-gentoo/video/fglrx.ko snip | /usr/lib/opengl/ati/lib/libGL.so.1 - libGL.so.1.2 And the drivers build and install fine... then this: | Safely unmerging already-installed instance... snip ==--- cfgpro obj /lib/modules/2.6.13-gentoo-r4/video/fglrx.ko ==--- cfgpro dir /lib/modules/2.6.13-gentoo-r4/video ==--- cfgpro dir /lib/modules/2.6.13-gentoo-r4 snip Switching to ati OpenGL interface... done | original instance of package unmerged safely. Switching to ati OpenGL interface... done So the rebuild process has *removed* the kernel modules for what will be the previous kernel when I reboot--- and if my new kernel doesn't boot, well neither will my previous one, depending on how critical the modules are (in this case, I just won't have X, but depending on one's setup, one might have lost something really necessary). In any case this is really not correct behaviour (I want both the currently-running kernel module and the future-kernel module to be installed). The only way I can see to avoid this is to step through the emerges with the 'ebuild' command, stopping after 'install', and not performing 'postinst' or 'unmerge' (whichever one is performed at the end to remove the previously-existing package). I don't see SLOTs as being precisely appropriate, but I don't see what other method *might* resolve this, since the previously-installed package is in this case (in most cases?) *not* the same as the re-emerged package, because they are compiled against different kernels. Is there a way to SLOT external kernel modules against the kernel version it's being compiled against? This seems to definitely be a bug, but I have not the first clue how to submit it, nor what against help, help, help and hope 2.6.14 works, because if it doesn't, I've got no modules for my previous kernel Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] portage: fixed or not???
Qian Qiao schreef: On 11/6/05, Jarry [EMAIL PROTECTED] wrote: All I do is running this set of commands every night from crontab: emerge --sync emerge --update --deep --newuse world emerge --depclean revdep-rebuild So my portage is also always updated, to the last stable version. Now it is 2.0.51.22-r3... Omg, you have emerge --deep --newuse --update world as a *cron* job? and just when you thought it couldn't get any worse, comes a depclean every night. Ciaran said it best: I really hope you don't want your system to carry on working... Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Big problem with module-rebuild
Neil Bothwick schreef: On Mon, 07 Nov 2005 18:26:02 +0100, Holly Bostick wrote: And my question is, how to get it to stop doing that. If Portage has a FEATURES setting that prevents the previous version being unmerged this way, I don't know what it is. Doesn't AUTOCLEAN=no do this? It is a separate setting, not a FEATURE. Yes, I see that, but since the description of it is not exactly clear, I don't know if setting it to no would help, except by testing, which I'm not prepared to do atm: (from man make.conf) AUTOCLEAN = [yes | no] Automatically cleans the system by removing outdated packages which will not remove functionalities or prevent your system from working. On major ABI changes this may need to be set to off to ensure that the system can be rebuilt using the new libs before the old ones are removed. Downgrading with this option turned off may result in missing symlinks and an inoperable system. Defaults to yes. In this respect, am I to assume that the outdated package is the previously-installed version? I don't think so; I think this is a separate process. I just reinstalled Wine (unrelated, but perhaps appropriate for an example) and the output does the clean process well after the previous version (which is in this case the same version) was removed: | Safely unmerging already-installed instance... --- !mtime obj /usr/share/wine/wine.inf snip --- !targe sym /usr/lib/libwine.so --- !targe sym /usr/bin/wineg++ --- !targe sym /usr/bin/winecpp | original instance of package unmerged safely. * ~/.wine/config is now deprecated. For configuration either use * winecfg or regedit HKCU\Software\Wine | Regenerating /etc/ld.so.cache... | app-emulation/wine-0.9 merged. | clean: No packages selected for removal. | Auto-cleaning packages ... But I could most certainly be reading this all wrong; it would certainly be an easy solution if that was the case. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] portage: fixed or not???
Jarry schreef: Holly Bostick wrote: Qian Qiao schreef: On 11/6/05, Jarry [EMAIL PROTECTED] wrote: All I do is running this set of commands every night from crontab: emerge --sync emerge --update --deep --newuse world emerge --depclean revdep-rebuild Omg, you have emerge --deep --newuse --update world as a *cron* job? and just when you thought it couldn't get any worse, comes a depclean every night. Ciaran said it best: I really hope you don't want your system to carry on working... http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2chap=1#doc_chap3 copypaste= Updating your System To keep your system in perfect shape (and not to mention install the latest security updates) you need to update your system regularly. Since Portage only checks the ebuilds in your Portage tree you first have to update your Portage tree. Code Listing 2: Updating the Portage tree # emerge --sync When your Portage tree is updated, you can update your system with emerge --update world ... Code Listing 16: Removing orphaned dependencies # emerge --update --deep --newuse world # emerge --depclean # revdep-rebuild Could some of you, gentoo-wizards, be kind enough and explain, what is wrong in doing the things the way gentoo handbook recommends it? The Gentoo Handbook does *not* recommend you do these procedures *unattended*, the way you are doing them. And a depclean-- which should 1) always be run with --pretend first, and 2) should be checked for sanity before running without --pretend, certainly should not be run both unattended and unchecked, every night. I suppose you've never seen this message: emerge -p depclean *** WARNING *** : DEPCLEAN CAN SERIOUSLY IMPAIR YOUR SYSTEM. USE CAUTION. *** WARNING *** : (Cancel: CONTROL-C) -- ALWAYS VERIFY ALL PACKAGES IN THE *** WARNING *** : CANDIDATE LIST FOR SANITY BEFORE ALLOWING DEPCLEAN TO *** WARNING *** : UNMERGE ANY PACKAGES. *** WARNING *** : *** WARNING *** : USE FLAGS MAY HAVE AN EXTREME EFFECT ON THE OUTPUT. *** WARNING *** : SOME LIBRARIES MAY BE USED BY PACKAGES BUT ARE NOT *** WARNING *** : CONSIDERED TO BE A DEPEND DUE TO USE FLAG SETTINGS. *** WARNING *** : emerge --update --deep --newuse world TO VERIFY *** WARNING *** : SANITY IN THIS REGARD. *** WARNING *** : *** WARNING *** : Packages in the list that are desired may be added *** WARNING *** : directly to the world file to cause them to be ignored *** WARNING *** : by depclean and maintained in the future. BREAKAGES DUE *** WARNING *** : TO UNMERGING AN ==IN-USE LIBRARY== MAY BE REPAIRED BY *** WARNING *** : MERGING *** THE PACKAGE THAT COMPLAINS *** ABOUT THE *** WARNING *** : MISSING LIBRARY. emerge -uDN world... well, it's not so much that anything is wrong with doing that every night, but ... unattended? So you have no idea what USE flags you're using, what versions of anything you're using, and when something else breaks (because you updated a dependency but the program that depends on it isn't able to use the update as yet, which happens a lot)-- you have no idea what broke the program, or why. If you have an nVidia card, but the new drivers don't support your particular card, and you just upgrade blindly, how are you going to know why X doesn't work all of a sudden? If you suddenly wake up to find that you have no disk space, because you have installed Evolution and Evolution Data Server (which you don't use, but there is a new USE flag for many GNOME programs-- eds-- that will install those applications unless you turn the flag off)-- who do you have to blame but yourself? And how are you going to determine what is suddenly eating your disk space and prevent it from happening again? With great power comes great responsibility, and Gentoo gives you a lot of power to configure and manage your system. However, you are responsible for paying attention to what is happening and keeping everything under control. Which you are not doing, and frankly, you're pretty lucky that something hasn't blown up up to now. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Big problem with module-rebuild [SOLVED]
Remy Blank schreef: Holly Bostick wrote: And the drivers build and install fine... then this: | Safely unmerging already-installed instance... snip ==--- cfgpro obj /lib/modules/2.6.13-gentoo-r4/video/fglrx.ko ==--- cfgpro dir /lib/modules/2.6.13-gentoo-r4/video ==--- cfgpro dir /lib/modules/2.6.13-gentoo-r4 snip Switching to ati OpenGL interface... done | original instance of package unmerged safely. Switching to ati OpenGL interface... done So the rebuild process has *removed* the kernel modules for what will be the previous kernel when I reboot I don't think so. cfgpro means the modules are *not* removed on unmerge. Have a look, they should still be there. At least, they are on my machines, although I don't use module-rebuild but a custom script (a one-liner, actually). I have always had the messages as you describe above, and the modules have always stayed around. If they don't, then something is wrong with your configuration. It's kinda the same as /etc on unmerge. The files just stick around. -- Remy Thank you, Remy-- you're right: la /lib/modules/2.6.13-gentoo-r4/video/ totaal 317 drwxr-xr-x 2 root root 72 nov 7 18:00 . drwxr-xr-x 6 root root496 nov 7 18:30 .. -rw-r--r-- 1 root root 321951 nov 7 18:00 fglrx.ko OK, so I'm panicking over nothing, which is good to know, but now I'm a little P.O.'d that I should have had *cause* to panic (I've gotta be a bit P.O'd about something, since I've made a fool of myself ;-) ). Seems to me that someone even less technically adept than I am (and I'm not really all that, after all), could really lose their cool under these circumstances, all because of that little cfgpro that they might not know what it means, even if they saw it. I'm really glad to know that the files are not in fact removed, but I have this feeling that it should have been clearer that they really weren't removed, despite the fact that that section of the operation was removing files. Ah well, I know Portage isn't perfect, but it usually doesn't scare the pants off me just during normal operation like that (which tends to scare me more than just normal Portage scary-stuff). Anyway, thanks again. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] two ati-drivers packages using --deep --update
Mark Knecht schreef: Hi, Is the following expected with recent ati-drivers? Is this slotted? No, and no. If so, and if I did the --deep --update command, then how do I know which one I'm using when I load fglrx? fglrxinfo would tell you the version of the ati-drivers in use. But... there can be only one (the package is not slotted). Thanks, Mark lightning ~ # emerge -pv ati-drivers ati-drivers-extra These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] media-video/ati-drivers-8.18.8-r1 [8.14.13-r2] +opengl 52,237 kB [ebuild N] media-video/ati-drivers-extra-8.14.13 +qt 0 kB Total size of downloads: 52,237 kB lightning ~ # emerge -pv --deep --update ati-drivers ati-drivers-extra These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] media-video/ati-drivers-8.18.8-r1 [8.14.13-r2] +opengl 52,237 kB [ebuild U ] media-video/ati-drivers-8.14.13-r5 [8.14.13-r2] -dlloader +opengl 0 kB [ebuild N] media-video/ati-drivers-extra-8.14.13 +qt 0 kB Problem here-- afaik-- is that the drivers-extra package is hooked to the drivers package of the same version. The --deep update of the drivers-extra package requires the 'same' version of the drivers package as it itself is numbered. What I don't understand is why you are not getting drivers-extra-8.18.8, but only 8.14.13. And I definitely don't know how the double upgrade would work, except that it would likely be an upgrade/downgrade (but not shown as such because the upgrade has not yet been performed). emerge -p ati-drivers ati-drivers-extra These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] media-video/ati-drivers-8.18.8-r1 [ebuild R ] media-video/ati-drivers-extra-8.18.8 Do you maybe have a mask on ati-drivers-extra? Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] portage: fixed or not???
Jarry schreef: Holly Bostick wrote: The Gentoo Handbook does *not* recommend you do these procedures *unattended*, the way you are doing them. Well, gentoo says ...update your system regularly I thought it means really regularly, not when root finds some spare time to do it. And things, which must be done on my server regularly, I usually put into crontab... Hmmm, interesting concept. What else does root have to do but administer the server? Why exactly does root, whose job is to run the server, have no time to schedule the actual running of the server, which includes: checking whether updates are available; checking whether updates are *appropriate*; making sure that available, appropriate updates don't interrupt the running of the server for which root is responsible? If it was a desktop system, I could understand. I hate to take time out from a good run of AisleRiot to do a glsa-check, myself (and why isn't *that* one of your cron jobs?). But a server is something else entirely. when something else breaks (because you updated a dependency but the Personally, I prefer rather breaking some dependencies in my system, over leaving some security hole in it. I am fully aware of the possibility that some services might be unavailable, but logsentry and monit will inform me about it... You would rather have your server not work than have a security hole in it. What difference does it make if there's a security hole if the server itself doesn't work? Not that I'm advocating security holes, but this just doesn't make sense (the security hole in X package can't be exploited if the program segfaults when you try to start it because its dependencies are broken). If you suddenly wake up to find that you have no disk space Again, logsentryquota would inform me, I think. And 2x160GB is plenty of space. BTW, no X/KDE/Gnome on my server... So you have time to fix the errors, but not time to prevent them before they occur? And of course, somehow you are going to be able to fix the errors without taking the server down, without any interruption to your users? I don't get it, but more power to you. Which you are not doing, and frankly, you're pretty lucky that something hasn't blown up up to now. That might happen, sooner o later. But still I think it is still better than leaving some hole for uninvited visitors. The invited vistors (ordinary users of the server) are on their own, apparently. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OTAnn] Feedback
shenanigans schreef: We have mirrored your mail list in a new application Is this permitted? (a mirror of the mail list that is unaffiliated with the Gentoo organization and administration? or is this affiliated?) And is there something wrong with me that it rather gives me the creeps if it is (permitted, but not affiliated)? Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] portage: fixed or not???
Jeff Smelser schreef: On Monday 07 November 2005 02:04 pm, Jarry wrote: Which you are not doing, and frankly, you're pretty lucky that something hasn't blown up up to now. That might happen, sooner o later. But still I think it is still better than leaving some hole for uninvited visitors. Thanks for your constructive explanation. Yeah, but your not restarting anything anyway, so your point is moot.. The service is still running with a big fat hole in it regardless.. No, no, Jeff, that is apparently where you are wrong: Jarry schreef: Well, this will be probably criticised, but after every upgrade (independently of what was really updated) I restart sshd, named, sendmail and apache, even with old config-files. I thought that way not only my system is updated, but also new versions of those daemons are running. Rest (I thought) is not important... So you see, the mail server, ssh server and web server *are* restarted. Whether or not they were the services actually updated (or needing update), and without regard to whether the change required an updated *configuration* file, which-- since etc-update was not run-- did not take place. But we all know that fixing a security hole never has any relationship to the application's config files, ever. Don't we? And of course restarting those four servers, even with old config files, constitutes a full and complete update, patching all relevant security holes covered by the emerge -uDN world. *Ob*viously. Because *ob*viously, emerge -uDNworld updates to the version of whatever containing the patch for the hole. No matter what your ACCEPT_KEYWORDS is set to, no matter what USE flags are enabled. I mean, *really*, Jeff. What *are* you thinking? Why on earth should we need to pay attention to any of that stuff? Don't you know Gentoo manages your server(s) for you? (Wonder why it takes two days to a week to install, if it does all this automatic management so well?!) I hope you see how mistaken you are and are duly chastened. Holly ;-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] /usr/local/portage does not seem to have a valid PORTDIR structure.
Norberto Bensa schreef: Hello list, I'm trying to make an ebuild for kbfx (http://kde-apps.org/content/show.php?content=24898) but when I do: sudo ebuild ./kbfx-0.4.8beta.ebuild digest I get: Appending /usr/local/portage to PORTDIR_OVERLAY... !!! /usr/local/portage does not seem to have a valid PORTDIR structure. This seems new in portage-2.0.53rc7. What is it and how do I fix this? Many thanks in advance, I'm not sure if this is the answer, since I've not seen that error, but I have had many errors based on the fact that my overlay ebuild was not placed in the same tree structure as Portage -- and it does rather sound like that's what this error is saying. For example, let's say you make an alternative ebuild for... (make something up)... mplayer. The overlay ebuild would have to be placed in (assuming your overlay is /usr/local/portage) /usr/local/portage/media-video/mplayer/mplayer-whatever.ebuild If you placed it in /usr/local/portage/media-video/mplayer-whatever.ebuild, or /usr/local/portage/mplayer/mplayer-whatever.ebuild you would get an error, because the Portage tree structure is /portage/directory/category/packagename/package-ver.sion.ebuild Any other format will not be recognized, and you will get one of a variety of errors. So I would first suggest that you make sure your ebuild is correctly placed in the correct tree structure, and then I would digest it by full path, rather than from within the directory, as you seem to be doing. Afaik, the syntax of the ebuild command requires the full path, even if you're at the correct location. Hope this helps, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] /usr/local/portage does not seem to have a valid PORTDIR structure.
Norberto Bensa schreef: Holly Bostick wrote: Norberto Bensa schreef: sudo ebuild ./kbfx-0.4.8beta.ebuild digest I get: Appending /usr/local/portage to PORTDIR_OVERLAY... !!! /usr/local/portage does not seem to have a valid PORTDIR structure. So I would first suggest that you make sure your ebuild is correctly placed in the correct tree structure, and then I would digest it by full path, rather than from within the directory, as you seem to be doing. [EMAIL PROTECTED] /usr/local/portage/kde-misc/kbfx $ sudo ebuild /usr/local/portage/kde-misc/kbfx/kbfx-0.4.8beta.ebuild digest Password: Appending /usr/local/portage to PORTDIR_OVERLAY... !!! /usr/local/portage does not seem to have a valid PORTDIR structure. $ grep OVERLAY /etc/make.conf PORTDIR_OVERLAY=/usr/local/portage I don't know. Perhaps one of those (stupid) security settings somewhere for latest portage :( Thank you Holly and Rumen. Now, now; not so hasty what I notice is that this is a *very* explicit error message. So if we assume that it means exactly what it says, where does that get us? /usr/local/portage does not seem to have a valid PORTDIR structure very clearly says that the overlay must have a structure identical to PORTDIR; your portdir *is* /usr/portage, is it not? Assuming that it is, then you have replicated this structure in /usr/local/portage for this ebuild-- but there are three possible holes in this 'theory' such as it is. One is that you are trying to digest the ebuild from within the directory, rather than from, say, /usr/local. It is remotely possible that this is not a good idea, since the overlay tree should possibly not be the current working directory (as I suggested before). Second is that you're using sudo. I find many anomolies in sudo; mostly revolving around it not being a 'real' login shell, but some kind of weird spawned shell process that doesn't necessarily transfer all variables and/or permissions, depending on settings. You might try again, using su - -c instead of sudo to get root privileges. Third is that there's a problem with your ebuild, which also uses the PORTDIR variable. It is possilbe that your ebuild is incorrectly using this variable and not using a 'valid' PORTDIR. I'm not much of an ebuild writer, but you might want to go over it with a fine-toothed comb to make sure that this error isn't reporting an anomaly in the ebuild it's trying to read, rather than Portage, and is just poorly expressing that (it happens). HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] /usr/local/portage does not seem to have a valid PORTDIR structure.
Norberto Bensa schreef: Holly Bostick wrote: you're using sudo. I find many anomolies in sudo; Why does people hate sudo so much? Actually, I don't hate sudo at all; I use it all the time, and it saves a lot of difficulty. I just get annoyed because I, in my ignorance, generally expect it to act like a super su, and it doesn't-- in fact, it's something else by design, but I don't know enough about the underlying design and the reasons for it, to not fall into the mistaken assumption if I attempt to use sudo on the fly, as it were. Which ultimately means that I have to either set sudo up very carefully, or pay very close attention when using it on the fly, or use an alternative, and two out of three of those choices obviate my reason for using sudo, which is to be able to perform certain root functions *quickly*, without breaking stride in the overall operation I'm performing. For example, I get the mail saying what updated packages I have available, I run a --pretend emerge, am not happy with the USE flags, and so want to change them, meaning I have to edit root-only files. I can run nano using either su or sudo, but either way I have to input a password (under normal circumstances), and the passwords aren't the same, meaning I have to think about something else (am I running su or sudo, and which one uses which password), which is a distraction from the job at hand. So unless I set sudo (and in fact ~/.bashrc) up to not interrupt the flow of my main activity (which I have taken some pains to do), sudo is no better than su -- and the fact that sudo does not do some things that su - does (unless explicitly set up to do them), just makes the situation worse. But I assume that this is most likely because I'm using sudo for purposes that it can handle, but are not strictly within its design parameters naturally the fit is not perfect. I'm sure that if I was a server admin, using sudo to manage root access privileges in defined areas for defined groups, it would be a much smoother ride. The fact that a coin can unscrew a screw, but is not the best or most comfortable tool to do so, is no reflection on the coin, nor the screw. In fact, I'm just glad that the coin can do double-duty. What a waste of time and energy it would be to hate such a tool, for taking advantage of a bit of luck in both designs. there's a problem with your ebuild, which also uses the PORTDIR variable. I've found the problem. Portage doesn't like packge-0.0.1beta. Instead you must name it like package-0.0.1_beta. Now I need to do some magic inside the ebuild to s/_// Many thanks! Well, I'm sure you can handle that bit of ebuild magic. Glad to have been of help in finding the problem. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] viewing quicktime online
Harry Putnam schreef: What do I need to do to be able to view a quicktime video online? I see a couple of quicktime library packages but neithers website mention plugin tools for Mozilla. I'm guessing there are viewers available that employ these libs. But need to know what combination of things I need. mplayerplug-in net-www/mplayerplug-in Available versions: 2.80 2.85 3.11 Installed: 3.11 Homepage:http://mplayerplug-in.sourceforge.net/ Description: mplayer plug-in for Mozilla MPlayer Media Types Supported Window Mediawmv, avi, asf, wav and asx QuickTime mov and smil MPEG Video and Audiompeg and mp3 Ogg Vorbis ogg AutoDesk FLIfli and flc Vivovivo Real Player ram and rm is probably the best-known of these tools, but there are others; there is a package called 'mozplugger', which supports several formats (possibly more than mplayerplug-in), as well as the older netscape-plugger on which it is based,; gxine creates a plugin for web browsers (plain xine might do so as well, I'm not sure); so does realplayer, iirc; and you can also install QuickTime itself using Wine or Crossover Office, which will also give you a browser plugin. HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] wine emerge wants to downgrade?
Mark Knecht schreef: Is there some small thing I'm overlooking. It seems that portage thinks that wine-20050930 is newer than the first official release wine-0.9 and therefore wants to 'upgrade' Wine when it's really a downgrade. Does portage need to be informed of something special here? Yes, it does. There is a bug on b.g.o about the issue, but said issue will ex not be resolved until the maintainer sees how future releases are going to be numbered. For now, just mask (piped to prevent Thunderbird quoting) | app-emulation/wine-0.9 in /etc/portage/package.mask, and that should do it. (It's how I did it). Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] KDE GUI for network settings
Qv6 schreef: On Wednesday 02 November 2005 09:02 am, Mark wrote: I have a KDE desktop on one of my machines, and noticed I couldn't find any GUI interface to manage the IP address and related configurations for the 2 ethernet cards on the box. I have installed kdenetworks, but still don't see anything. What do I need to install/enable/locate on my system to manage eth0 and eth1 from the GUI? Thanks! You are referring to knetworkconf. This is currently not available in kde under Gentoo. Not completely true-- someone has taken the opportunity to practice their ebuild writing skills, so there is a proposed ebuild on bugs.gentoo.org (b.g.o), found by searching ALL knetworkconf: http://bugs.gentoo.org/show_bug.cgi?id=19413 While putting an unofficial build in one's overlay is also not 'simple' if you've never done it before, 1) it's a useful skill to have if you're a Gentoo user; and 2) it's easier than building from source for what is likely a complex build (suggested by the fact that no one has it but knoppix). So while there are likely to be problems, at least you can also contribute to the bug so that 1) you might get help/fixes if the ebuild doesn't emerge and 2) any problems with the ebuild get fixed faster, paving the way to get the ebuild into Portage that much sooner. You probably want to have a look at the following references: Adding unofficial ebuilds (Gentoo docs) http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3chap=5#doc_chap2 HOW-TO Installing 3rd party ebuilds (gentoo-wiki.com) http://www.gentoo-wiki.com/HOWTO_Installing_3rd_Party_Ebuilds HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Replacement for qpkg... please!?!?
Neil Bothwick schreef: You still can, gentoolkit still installs qpkg, but doesn't put it in your path. You'll find it in /usr/share/doc/gentoolkit-version/deprecated/qpkg 'Problem' is, if you also have portage-utils installed, that package also includes a *different program* which is unfortunately also named qpkg; so if you have both that and gentoolkit installed, and you want to use the deprecated qpkg binary, you have to use the full path to it, or symlink it into your PATH with a name distinct from the other binary. Just a note. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] revdep-rebuild is giving me fits
Dale schreef: Bob Sanders wrote: Before you do that, get rid of /root/.revdep* Run - python-updater Then - perl-cleaner all Then - emerge -uDNav world Then - revdep-rebuild -p OK. I went in circles with those for a while. I have now come to a brick wall here. I had a earlier thread about this just in case. I have a package.use file that tells it not to do the doc thing for gentoo-sources but it seems it is more stubborn than I am. [EMAIL PROTECTED] / # emerge -uDNavp world --pretend disables --ask... removing --ask from options. These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild N] app-text/xmlto-0.0.18 0 kB Total size of downloads: 0 kB [EMAIL PROTECTED] / # Did you re-emerge gentoo-sources after removing the doc USE flag? If not, then the currently installed version, which was installed using the doc flag, would still require that xmlto be installed. That brings me to another question, because if you didn't re-emerge gentoo-sources, and you have changed the USE flag, then it *should* be coming up as recompileable when you do a --newuse (-N). Why isn't it? Most likely because you have not actually changed the USE flag. What is the format of the relevant entry in /etc/portage/package.use? If it does not look like this sys-kernel/gentoo-sources -doc then fix it. Alternatively, you could just remove doc or add -doc to /etc/make.conf, if you don't use that USE flag the majority of the time, and only add it for those packages you *do* use it for. This is how I do it, doc is off by default, but enabled specifically for imagemagick, for which I need all the docs I can get. Also, try emerge -uDNptv world emerge --update --deep --newuse --pretend --tree --verbose (with --tree being the important change) to see what packages are requiring xmlto. We're just guessing that it's gentoo-sources, really; maybe it's not. I did take the -p out and try it but it failed, like I expected. May be something in the command that is making it want to ignore the package.use file. Anyway . . . . . . No, your syntax in package.use is likely wrong. Happens to all of us. :-) . OK, the revdep-rebuild command now gives me this: snip Dynamic linking on your system is consistent... All done. Great. No more need to deal with that atm, then. Don't get me started on that libingif and giflib circle either. :/ I'm not sure what to do about that. The forums don't seem to have a fix either. If I emerge it, it gripes, if I unmerge it, it gripes. I'm confused. What next, hammer? Will a emerge -ev world help those broken things? *Will* you stop trying to get authorization for emerge -e at every opportunity!!!??? :-) It's really not necessary. And you're getting yourself all worked up over a relatively minor issue (or in fact a couple of them). As I said, you probably have a typo in /etc/portage/package.use. You want to spend a week reinstalling your system over a typo? As for the gif/libungif problem, search the ML archives; we just talked about this last week. I'd have to look it up, but iirc the solution has to do with uninstalling either gif or libungif and the program that's being a problem about it, then reinstalling the apps in the correct order. But depending on your usage patterns, perhaps you don't even need to worry about this *at this minute*. If the program or programs that depend on the gif/libungif circle are not mission critical for you atm (or you aren't using it because you're solving the other issues), then put the issue on the back burner for now. Basically, you seem to be upset because Portage is having a fit when you try to update world. Not because a program is broken, or because you can't do some specific task (because a program is broken). If that is a correct assessment of the situation, then have some perspective. You don't have to update world every day, or even every month. So don't. If things work OK for what you need them to do, then the fact that you can't update easily right now is *not a problem*. Certainly not one needing a reinstall of the entire system. If something specific is broken due to the gif/libungif issue, then tell us what that is. It may be that gif/libungif needs to be sorted out to fix whatever is broken, but we can cross that bridge when we come to it. It's really not a big deal. Relax. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] beagle compile error
karlos schreef: Hi, I run into this compilation error when trying to emerge beagle: Calculating dependencies ...done! emerge (1 of 12) dev-dotnet/gtk-sharp-2.3.92 to / cp ../gtk-sharp.snk . cp ../AssemblyInfo.cs . /usr/bin/mcs -nowarn:0169,0612,0618 -unsafe -out:gdk-sharp.dll-target:library /r:../glib/glib-sharp.dll /r:../pango/pango-sharp.dll generated/*.cs ./EventButt on.cs ./EventClient.cs ./EventConfigure.cs ./EventCrossing.cs ./Event.cs ./Event DND.cs ./EventExpose.cs ./EventFocus.cs ./EventKey.cs ./EventMotion.cs ./EventPr operty.cs ./EventProximity.cs ./EventScroll.cs ./EventSelection.cs ./EventSettin g.cs ./EventVisibility.cs ./EventWindowState.cs ./Key.cs ./Size.cs ./TextPropert y.cs AssemblyInfo.cs generated/PangoHelper.cs(17,55): error CS0039: Cannot convert type `GLib.Object' to `Pango.Context' via a built-in conversion generated/PangoHelper.cs(51,55): error CS0039: Cannot convert type `GLib.Object' to `Pango.Context' via a built-in conversion Compilation failed: 2 error(s), 0 warnings Has anyone experienced similar errors? I am not sure about what information to include, so please tell me what I need to post. I've experienced many errors in attempting to compile Beagle (before I eventually succeeded), but not this one. What I do know is that 1) beagle needs very specific compile order and dependency versions to compile successfully, and 2) pango-sharp does not exist in the Portage tree, or the gentopia overlay (so why you're getting a pango error I don't know, but it seems a trifle odd). The best sources of information for how to compile Beagle are http://www.beagle-project.org/Gentoo_Installation and http://www.gentoo-wiki.com/HOWTO_Beagle Using these instructions, I was able to build Beagle successfully. The only inaccuracy in the Wiki is that Beagle needs wv-1.0.3-r1 specifically; it will not compile against a lower version, or the current 1.2.2 version (there's a bug on b.g.o to that effect, and I just spent two days confirming it before I found it). So as long as you mask wv-1.0.3-r1, you should be good to go. But other than that, if you follow the instructions, it should work. It was a real pain to get installed, though; I will say that. However, it is pretty cool. HTH for a start, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] revdep-rebuild is giving me fits
Dale schreef: Holly Bostick wrote: Did you re-emerge gentoo-sources after removing the doc USE flag? Yup, I sure did. What is the format of the relevant entry in /etc/portage/package.use? If it does not look like this sys-kernel/gentoo-sources -doc Mine looks like this: O_O sys-kernel/gentoo-sources -doc OK, that eliminates that possibility; it must be something else, then. Also, try emerge -uDNptv world emerge --update --deep --newuse --pretend --tree --verbose (with --tree being the important change) to see what packages are requiring xmlto. We're just guessing that it's gentoo-sources, really; maybe it's not. [EMAIL PROTECTED] / # emerge -uDNptv world These are the packages that I would merge, in reverse order: Calculating world dependencies ...done! [nomerge ] sys-kernel/vanilla-sources-2.6.12.5 -build +doc -symlink [ebuild N ] app-text/xmlto-0.0.18 0 kB Total size of downloads: 0 kB [EMAIL PROTECTED] / # And so, in fact, it is something else. Or something more, that we didn't know about. Do you use/need vanilla-sources? If not, then you might consider unmerging it, so it does not appear in your world file and attempt to update every time you do an emerge -whatever world. And you might also consider adding -doc to /etc/make.conf, as noted previously. Something new that didn't show up last time. My new package.use: sys-kernel/gentoo-sources-doc sys-kernel/vanilla-sources -doc That should solve that, then. Great. No more need to deal with that atm, then. What about the broke stuff? According to your last output: [EMAIL PROTECTED] / # revdep-rebuild Checking reverse dependencies... Packages containing binaries and libraries broken by any package update, will be recompiled. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... broken /usr/lib/gaim/tcl.so (requires libtcl8.3.so libtk8.3.so) broken /usr/lib/libgtkmm-2.0.so.1.5.9 (requires libsigc-1.2.so.5) broken /usr/lib/libgdkmm-2.0.so.1.5.9 (requires libsigc-1.2.so.5) broken /usr/lib/libpangomm-1.0.so.1.5.9 (requires libsigc-1.2.so.5) broken /usr/lib/libglibmm-2.0.so.1.5.9 (requires libsigc-1.2.so.5) broken /usr/lib/libatkmm-1.0.so.1.5.9 (requires libsigc-1.2.so.5) broken /usr/lib/python2.2/lib-dynload/_tkinter.so (requires libtk8.3.so libtcl8.3.so) broken /usr/lib/libgtkmm_generate_extra_defs-2.0.so.1.5.9 (requires libsigc-1.2.so.5) broken /usr/bin/icewm-session (requires libungif.so.4) broken /usr/bin/icewm (requires libungif.so.4) broken /usr/bin/gnome-panel-properties-capplet (requires libcapplet.so.0) broken /usr/bin/icewmtray (requires libungif.so.4) broken /usr/bin/icehelp (requires libungif.so.4) broken /usr/bin/icewmbg (requires libungif.so.4) broken /usr/X11R6/lib/gaim/tcl.so (requires libtcl8.3.so libtk8.3.so) broken /usr/X11R6/lib/libgtkmm-2.0.so.1.5.9 (requires libsigc-1.2.so.5) broken /usr/X11R6/lib/libgdkmm-2.0.so.1.5.9 (requires libsigc-1.2.so.5) broken /usr/X11R6/lib/libpangomm-1.0.so.1.5.9 (requires libsigc-1.2.so.5) broken /usr/X11R6/lib/libglibmm-2.0.so.1.5.9 (requires libsigc-1.2.so.5) broken /usr/X11R6/lib/libatkmm-1.0.so.1.5.9 (requires libsigc-1.2.so.5) broken /usr/X11R6/lib/python2.2/lib-dynload/_tkinter.so (requires libtk8.3.so libtcl8.3.so) broken /usr/X11R6/lib/libgtkmm_generate_extra_defs-2.0.so.1.5.9 (requires libsigc-1.2.so.5) broken /usr/X11R6/bin/icewm-session (requires libungif.so.4) broken /usr/X11R6/bin/icewm (requires libungif.so.4) broken /usr/X11R6/bin/gnome-panel-properties-capplet (requires libcapplet.so.0) broken /usr/X11R6/bin/icewmtray (requires libungif.so.4) broken /usr/X11R6/bin/icehelp (requires libungif.so.4) broken /usr/X11R6/bin/icewmbg (requires libungif.so.4) done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds) Evaluating package order... done. (/root/.revdep-rebuild.5_order) Dynamic linking on your system is consistent... All done. Dynamic linking on your system is consistent... All done. means that nothing needs rebuilding, in the opinion of revdep-rebuild (meaning no libraries are disconnected from the programs that depend on them). By the way, what version of gentoolkit do you have installed? If the last stable (0.2.0-r2), you might very well want to consider unmasking the unstable version for this package only -- add app-portage/gentoolkit ~x86 to /etc/portage/package.keywords-- as revdep-rebuild is vastly improved (though still not perfect) in the most recent unstable version. It is within the realm of possiblility that your version of revdep-rebuild is less trustworthy than mine (I use the unstable version), so the reason why you're receiving untrustworthy reports
Re: [gentoo-user] emerge --sync
Qian Qiao schreef: On 11/2/05, Martins Steinbergs [EMAIL PROTECTED] wrote: 002617 !!! Digest verification Failed: 002618 !!! /usr/portage/dev-python/pyrex/pyrex-0.9.3.1.ebuild 002619 !!! Reason: Filesize does not match recorded size 002620 002621 Please ensure you have sync'd properly. Please try 'emerge sync' and 002622 optionally examine the file(s) for corruption. A sync will fix most cases. You can either wait for a re-sync, or do a:- # ebuild /path/to/the/ebuild digest That's true, but redigesting official Portage files manually is a *very* bad habit to get into, and I would strongly recommend against it. The whole point of Portage's digesting and digest verification is to ensure/verify that the files you have received have not been tampered with/contain no errors. If the official digest doesn't match the file, *something is wrong*, and unless you (generic 'you') happen to be in a position to know what that is, and because you know, you can safely override Portage (which is what a manual digest does), you in fact cannot safely override Portage, and should not do so. Patience is a virtue. Wait, and sync again, for official files. Overlay files are a different story. For all you know, the 'problem' is that the mirrors have not finished syncing yet, and you only have half the distfile/the wrong distfile. So when you attempt to emerge, the emerge will fail because there's actually something wrong with the tarball, and then you've screwed your digest and have to sync again anyway to fix it, and you didn't get any result anyway (the app has not emerged). Just wait. Portage fixes itself pretty quick. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge xmlto ERROR: app-text/xmlto-0.0.18 failed.
Dale schreef: Hans-Werner Hilse wrote: in order to build documentation. Remove the doc USE flag if you don't want it to. So the Kernel has documentation or is this the little help screen in menuconfig? I need that help screen. I don't know what half that stuff is even with the help. Don't they have a new thing that we can override the USE for specific packages in /etc/portage? This would be a good time to use it if it is not the help screen. Maybe that was a future feature I was reading about. No, the doc USE flag is extra documentation, useflag doc /usr/portage/profiles/use.desc:doc - Adds extra documentation (API, Javadoc, etc) the 'help' screen you're talking about is part of the kernel. Removing it doesn't remove internal help, like the kernel help, or man and info pages-- those are *required*, and options subject to USE flags are *optional*. But if it will help, I don't use the doc flag either: [ebuild NS ] sys-kernel/gentoo-sources-2.6.14 -build -doc +symlink (-ultra1) 38,399 kB And my kernel help works fine. And what you're talking about w.r.t the overriding of USE flags is not 'a new thing' (though it may be new to you :-) ), it's a Portage feature. You can create a file, called /etc/portage/package.use, which contains such overrides; here's a snippet of mine: sys-libs/glibc userlocales erandom glibc-compat20 glibc-omitfp linuxthreads-tls www-client/kazehakase-cvs estraier firefox thumbnail www-client/mozilla-firefox mozsvg mozxmlterm www-client/mozilla moznocompose moznoirc moznomail mozp3p mozplaintext mozsvg mozxmlterm www-client/galeon firefox mail-client/mozilla-thunderbird mozplaintext mail-client/sylpheed-claws clamav dillo media-video/gxine -mozilla dev-libs/gmime mono dev-python/gnome-python-extras mozilla net-libs/gecko-sdk mozsvg mozdevelop dev-java/blackdown-jre mozilla dev-java/blackdown-jdk mozilla dev-java/sun-jre-bin mozilla Read man portage for more details. In any case, this feature allows you to override the USE flags for specific packages, while leaving the flag active for the rest of the packages that may use it. So if I was someone who actually used the mozilla USE flag generally (it was + in /etc/make.conf), gxine would build without it, but other programs that use it would still build with it, because I only overrode /etc/make.conf with respect to gxine, not all other programs-- and in fact all my java installs and gnome-python extras will be built with the flag active (because I specified that, too). Keeps one from clogging up /etc/make.conf with anything but the essentials (truly global settings). Read man portage for more details; it's a wealth of information. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Old devfs files in /etc
Dale schreef: Hi, I switched to udev a while back and have some old devfs files left in /etc. Here is a list: /etc/devfs.d /etc/devfs.d/.keep /etc/modules.devfs.256 /etc/config-archive/etc/udev/scripts/ide-devfs.sh /etc/config-archive/etc/udev/scripts/ide-devfs.sh.dist /etc/modprobe.devfs /etc/modprobe.devfs.256 /etc/modprobe.devfs.old /etc/modules.devfs /etc/devfsd.conf Can I get rid of these files and not kill anything? I already unmerged devfsd though. It just doesn't get rid of the config files. It would be nice of there was a option to tell it too. There is, of course, an option to tell it to; you just don't know about it :-) . You might want to have a closer look at the Gentoo Documentation pages, most specifically Gentoo Linux Documentation -- Environment Variables at http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2chap=5 . In any case, the deal is configuration files are protected by default. That means that when you unmerge a program (or merge a new version of the same program), the configuration files will not be automatically overwritten (or deleted, for that matter). This saves you trouble, because it doesn't screw up your config, if you later reinstall the program, or when you update a program that had a complex configuration. However, it also means that things such as what happened to you can happen (config files that you want deleted don't get deleted automatically). But the thing is, such files are important enough that they shouldn't be just deleted like it's nothing. That's the Gentoo design and the Gentoo way; an action like deleting /etc/devfsd can have sweeping consequences if the system is not prepared to pick up the ball with udev-- forcing you to delete it manually is both a way of making sure that you know you did it, and also making sure you know what you're doing before you do it (90% of the users ask the list before taking any action, which is fine-- we *want* people to know what they're doing and have a healthy respect for their own power to bork their system, so good you ask first!) In any case, yes you can override the setting (of *course*, this is Gentoo!) to delete certain (or all) protected files after an unmerge of various programs; but now you have to look up how to do that, and that means you have to read a bit about the consequences of your proposed action before taking it (since you don't know how to take it before you read a bit), and then you have a much better chance of not doing something that's going to come back and bite you in the butt later, but will instead make your system more effective for your usage pattern for the future. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Old devfs files in /etc
Dale schreef: Holly Bostick wrote: There is, of course, an option to tell it to; you just don't know about it :-) . You're kidding right. Something that I don't know about, yea right. LOL LOL Treat me like a sponge, I'm absorbing your knowledge, I hope anyway. I have been using Gentoo a while and have a little understanding of how it works but not much. I just know it is better than winders. You might want to have a closer look at the Gentoo Documentation pages, most specifically Gentoo Linux Documentation -- Environment Variables at http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2chap=5 . That link didn't make sense. That the right chapter? May just be me. LOL From the link; under Important Examples CONFIG_PROTECT This variable contains a space-delimited list of directories which should be protected by Portage during updates . CONFIG_PROTECT_MASK This variable contains a space-delimited list of directories which should not be protected by Portage during updates. From man make.conf, under variables: CONFIG_PROTECT = [space delimited list of dirs] All directories that are defined here will have config file protection enabled for them. For more information, please see `emerge --help config`. CONFIG_PROTECT_MASK = [space delimited list of dirs] All directories that are defined here will have config file protection disabled for them. For more information, please see `emerge --help config`. In any case, the deal is configuration files are protected by default. And the CONFIG_PROTECT and CONFIG_PROTECT_MASK variables are how it's done. snip It is no suprise that I didn't know about it, yet. I did a man emerge and didn't see it. Is it a newer version that I don't have yet? I run stable packages. Did I say man emerge? I meant man portage... oops, wrong again, should be man make.conf. But the thing is, such files are important enough that they shouldn't be just deleted like it's nothing. That's the Gentoo design and the Gentoo way; an action like deleting /etc/devfsd can have sweeping consequences if the system is not prepared to pick up the ball with udev-- forcing you to delete it manually is both a way of making sure that you know you did it, and also making sure you know what you're doing before you do it (90% of the users ask the list before taking any action, which is fine-- we *want* people to know what they're doing and have a healthy respect for their own power to bork their system, so good you ask first!) I have been running udev for a while and it seems to be working fine. Time for devfs to go. Indeed. It's continued presence is shortly going to start causing you problems if it hasn't already. There was a 'grace period' where they were allowed to co-exist; that grace period has ended for unstable users not long ago, and stable users with both systems installed will be seeing issued as devfs finally goes definitively from 'deprecated' to 'obsolete'. So yes, it's time for it to go. In any case, yes you can override the setting (of *course*, this is Gentoo!) to delete certain (or all) protected files after an unmerge of various programs; but now you have to look up how to do that, and that means you have to read a bit about the consequences of your proposed action before taking it (since you don't know how to take it before you read a bit) I cheat. When I know I am about to delete some config files that I worry about, I back-up my /etc directory. I save it until I reboot a few times just to make sure. Smart huh? You're one of the few I mean, it's extra work for you, and not really necessary, but better that you should do a little unneccessary extra work than bork everything. Better safe than sorry, as it were. But I'm sure you know how many computer users don't take any precautions whatsoever to protect themselves from system error, or human error. Doing so is not 'cheating', it's just good common sense. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge xmlto ERROR: app-text/xmlto-0.0.18 failed.
Dale schreef: There is no , or = in there. I copy and paste all I can because my typing sucks. I type slow and it still sucks. :( emerge gtypist emerge tuxtype emerge tuxtype2 emerge dvorak7min (if you happen to have a dvorak keyboard) emerge dvorakng (ditto) emerge typespeed emerge ktouch Naturally you don't need all of these, but I thought I'd list what's in Portage. I have gtypist and tuxtype2 installed, but haven't got around to scheduling them yet :-( . Isn't it nice to know you can use your computer to help you in your life? :-) Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Glibc, userlocales, and ENV Variables
Hans-Werner Hilse schreef: Hi, On Wed, 02 Nov 2005 15:53:11 +0100 Holly Bostick [EMAIL PROTECTED] wrote: [...] /etc/locales.build which says # This file names the list of locales to be built when glibc is installed. # The format is locale/charmap, where locale is a locale from the # /usr/share/i18n/locales directory, and charmap is name of one of the files # in /usr/share/i18n/charmaps/. All blank lines and lines starting with # are # ignored. Here is an example: # en_US/ISO-8859-1 [...] Glibc built fine (afaict), but my problem is that I now don't know what to export with a LANG variable. For example, if I want [EMAIL PROTECTED]/UTF-8, how do I export that as opposed to [EMAIL PROTECTED]/ISO-8859-15 (or worse, ISO-8859-1)? Note the comment you've cited: The format is locale/charmap. This generates the locale data for a certain language (it's a little bit more than just language, though) for the specified charmap. In LANG/LC_* you only set the locale. The charmap is (semi-) automatically chosen, which makes sense, since it's terminal dependant which charset is used. OK, I kinda get that and dmesg says during boot that the terminal (agetty) is being configured to use UTF-8 (which is what I told it to do when I built the kernel, so that's OK). So does that mean that when I log in to my DE/WM, and start X, the charmap will be automatically UTF-8, because that's what the getty was? I want the full ISO-8859-15 charset and the Euro symbol. UTF-8 gets me the charset, but afaik I need some attachment to @euro to get the Euro symbol (for those fonts that even have the character(s), which is another horror show that I won't get into, since once you've found a reasonably attractive font with all the characters, half the time it doesn't have bold or italic or bold italic, so it's not very useful on the desktop a horror show). It's not clear to me whether the Euro symbol is included in UTF-8 encodings, or only as a special variant of ISO-8859-15 (the @euro variant), which is one of the reasons I try to encode both. Was I supposed to give the locales individual names as the Localization Guide implies? locales.build doesn't indicate that you can do that (and in fact, I thought perhaps the reason why language exports were mildly borked might be because I had done so). [EMAIL PROTECTED]/ISO-8859-1 didn't make much sense to me (and maybe causes some failures when building?), but other from that it seemed OK. Well, of course I know less about this than you do, but my native Dutch boyfriend runs a English Windows machine, I run Windows programs with Wine, and about the only thing I think I know about the whole issue is that Windows pretty much only knows ISO-8859-1 (unless you had a multi-lingual version, which neither of us did). So I wanted support for ISO-8859-1 to be available (with support for the Euro symbol for those MS fonts that support it, which I think that the core MS fonts now do by default, though I'm not sure about that either). In any case, if such an application called for ISO-8859-1 , I wanted it to be there, though as you can tell, I don't get how this is all supposed to work well enough to be sure that was the way to accomplish the goal. Should I just get rid of the 'extra' locales (ISO-8859-15 and ISO-8859-1)? Since I guess I'm going to try to stick to UTF-8, maybe I don't really need them (I was mostly covering my butt, concerned that my current and future network connections might not support UTF-8, since they're mostly to Windows machines). All the terminals you're using support UTF-8? Well, I thought so, but maybe I was wrong. I use mostly multi-gnome-terminal (which does appear to have unicode support by default), but when I switched window managers to fvwm-crystal, I started using mrxvt and aterm a bit more (because fvwm-crystal likes them, and xterm-- which crystal also likes-- takes forever to open for some reason, likely unrelated but very annoying). This may well be when I started noticing this as a problem rather than an annoyance, because I was suddenly seeing it so much. Previously, the issue had only raised its ugly head in some X programs, but not X programs I use that often, so it was easy to ignore. None of the terms I use have a unicode USE flag, but I have been by the homepages. Now I see that support for CJK does not mean that UTF is automatically supported; it seems that mrvxt does not support unicode, nor do aterm/multi-aterm/rvxt. OK, that answers that, I guess, but what did you Europeans do when these terminals were all you had, for Pete's sake? Your output would have been half-gibberish, and I don't see how people would have stood for that. I guess I've made a mistake, but I'm not quite sure what to do about it. Since fixing it will most almost certainly require a recompile of glibc, and since compiling glibc takes nine-tenths of forever, I'd like to get
Re: [gentoo-user] emerge xmlto ERROR: app-text/xmlto-0.0.18 failed.
Dale schreef: Hi, I have ran into this error a lot of times. I posted it the other day but have learned that a lot of people don't read HTML stuff. So here I go again. This is the whole thing, sorry it is a bit long but I didn't want to cut out the very part you need. Yes, my rig is named smoker. :/ [EMAIL PROTECTED] / # emerge -v xmlto Calculating dependencies ...done! emerge (1 of 1) app-text/xmlto-0.0.18 to / snip warning: failed to load external entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl; compilation error: file /var/tmp/portage/xmlto-0.0.18/temp/xmlto-xsl.ShHrwX line 4 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl warning: failed to load external entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl; compilation error: file /var/tmp/portage/xmlto-0.0.18/temp/xmlto-xsl.Rpd0Wc line 4 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl Q: I'm trying to build xmlto on my Debian box, but it doesn't work. A: If you get `Attempt to load network entity' errors when building xmlto, your system does not have the required support for XML Catalogs snip It wants to emerge it sometimes during a emerge -uv world. I try to keep it up to date. OK, if it's emerging only during a -uv world, it's 1) not in your world file; and 2) a direct dependency of something that is. Since there are two solutions to this problem (actually 3), and this information impacts one of them, we'll look at that impact first, but the three solutions are: 1) if it's an actual bug (check b.g.o.) then you have to wait for it to be fixed (unless you happen to be able to fix it in the source code yourself). 2) If it's a bug you cannot fix, or if it's not a bug at all (meaning it's either an unmoveable obstacle, or you have a system problem), you have one choice either way; 2a) eliminate the need for the program (until the bug is fixed, but you can also choose this if you're lazy and don't really feel like messing around with the problem, no crime in that) 2b) fix the underlying system problem so the program emerges. So far we know that xmlto is being emerged as a direct dependency of something-- but what? (from www.gentoo-portage.com ) Programs That Depend On xmlto app-text/robodoc dev-util/mercurial sci-geosciences/gpsd sys-auth/libnss-pgsql doc media-gfx/k3d Which, if any of these programs do you have installed on your system? I did also try USE=-doc emerge xmlto and it still fails. This is not a solution-- xmlto does not have any USE flags; all its dependencies are required, not optional. However, if k3d is the program you have installed in your world file that depends on xmlto, then compiling *that* -doc will remove the dependency on xmlto and the problem is solved (because xmlto will not attempt to compile or upgrade as a result of an emerge -uv world. You might then consider removing it via emerge depclean-- but be careful with depclean-- or manually with emerge -Cav xmlto). If k3d is not the program you have installed which depends on xmlto, but one of the others listed above and you want/need to keep that program, you have to try and fix xmlto (assuming that this is not an unresolved bug; again, check b.g.o if you haven't-- ALL xmlto should do for the search terms). Since the problem seems to revolve around docbook, and one of the dependencies of xmlto is (again from www.gentoo-portage.com , piped to prevent Thunderbird thinking its a quote) Runtime Dependencies xmlto-0.0.18 |app-shells/bash |app-text/docbook-xml-dtd4.2 |= app-text/docbook-xsl-stylesheets - 1.62.0-r1 |dev-libs/libxslt |sys-apps/utillinux xmlto-0.0.17 |app-shells/bash |app-text/docbook-xml-dtd4.2 |= app-text/docbook-xsl-stylesheets - 1.62.0-r1 |dev-libs/libxslt |sys-apps/utillinux I would suggest recompiling the two docbook dependencies, most notably docbook-xml-dtd, and seeing if that helps in any way. If you really need xmlto. But I admit that if I had this problem, I'd be more likely to get rid of xlmto, and any programs that depended on it (or find an alternative to the programs which did not require xmlto) to solve the problem. You've gotta pick your battles, and I myself do not need to fight to get xmlto working. You may have different priorities, though. HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] power-down during emerge -u world causing library-issues
Fernando Meira schreef: This is what emerge would do: # emerge -Dav dbus hal Calculating dependencies ...done! [ebuild R ] sys-apps/dbus-0.36.2 +X -debug -doc -gtk -mono +python +qt +xml2 0 kB [ebuild UD] sys-apps/dbus-0.23.4-r1 [0.36.2] +X -debug -gtk -mono +python +qt +xml2 0 kB [ebuild R ] sys-apps/hal-0.4.7-r2 -debug -doc -livecd -pcmcia 0 kB So, i updated dbus, but for hal, it would downgrade dbus... isn't it strange that it upgraded it and now wants to downgrade it.. with no emerge --sync in between? And, should I do this? No, it's not weird, just kinda a pain. HAL and dbus are tied together, and dbus is tied to k3b. This happened to me, kinda, which is how I noticed it. What's happening is that the version of hal you have installed requires the version of dbus you have installed, but the version of K3b you currently have installed requires a lower version of dbus than the one you have (so it's downgrading dbus). Had you been able to install k3b, then it would have all worked out (the upgrade to k3b can use the upgraded dbus). IIrc, the version of dbus you're downgrading to would break HAL (because it's a lower version than the one required by the higher version of HAL-- they're very tightly tied together). ATM, you have the correct versions of hal and dbus installed. What I would do (and what I think I may have in fact done) was: 1) unmerge k3b totally. Don't worry, it's not for long. 2) reboot to re-initialize hal and dbus with the new versions (you might be able to do this with stopping and restarting the services, but I found it generally more reliable to just reboot, so I did). 3) re-emerge k3b (which should get you the new version which should detect that the required verisons of HAL and dbus are in use). If this fails for some reason, try re-emerging HAL and dbus again; they may have installed with faults due to the power outage, then try steps 2 and 3 again. Or you could just remove the hal USE flag from k3b, so it doesn't use HAL and dbus at all, but I don't know the effects of that (it is, however, optional, so the effects shouldn't be that severe). I didn't want to do that, though, when I ran into this problem (or one very similar). Hope this helps, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge xmlto ERROR: app-text/xmlto-0.0.18 failed.
Dale schreef: Holly Bostick wrote: Programs That Depend On xmlto app-text/robodoc dev-util/mercurial sci-geosciences/gpsd sys-auth/libnss-pgsql doc media-gfx/k3d Which, if any of these programs do you have installed on your system? I have none of those installed, but that k3d looks familiar. It is not installed though. May have read about it somewhere. Is that that 3D desktop thing? I did install that once but unmerged it ages ago. It is not *currently* installed, you mean. But xmlto remains installed as a dependency of the uninstalled package. Does it (xmlto) appear in the output of an emerge deplclean -p (don't forget the -p!!)? snip Runtime Dependencies xmlto-0.0.18 |app-shells/bash |app-text/docbook-xml-dtd4.2 |= app-text/docbook-xsl-stylesheets - 1.62.0-r1 |dev-libs/libxslt |sys-apps/utillinux xmlto-0.0.17 |app-shells/bash |app-text/docbook-xml-dtd4.2 |= app-text/docbook-xsl-stylesheets - 1.62.0-r1 |dev-libs/libxslt |sys-apps/utillinux I would suggest recompiling the two docbook dependencies, most notably docbook-xml-dtd, and seeing if that helps in any way. snip I did re-emerge the docbook things, several times I might add, no workey, just more smoke. :( What would die if I unmerged it? Apparently nothing, since you don't have any applications installed that depend on it to work. I don't want to remove it and then reboot or something and it blow smoke at me. :/ I don't relish in reinstalling Gentoo. I would, but I would rather not. First of all, a reinstall of Gentoo is very rarely necessary, and certainly not for a minor text application being uninstalled, no matter what depends on it. Even in a dire emergency, when almost eveyrthing seems to be broken, it's rarely *necessary* to reinstall, but it's a *choice* one might make to save work or time. But Gentoo can almost always be fixed /in situ/, without a full reinstall being needed. Second of all, you have checked everything you can check; apparently you don't need this application (nothing you do need depends on it), and it's causing you problems with its irrelevant self. Uninstall it and see what happens. It *should* be all right, but sometimes being a Gentoo user requires a leap of faith. So you will know, this comes up on occasion when I do a emerge -uv world. I usually do a emerge --resume --skipfirst and it carries on. It just seems to pop up on occasion and is getting under my skin. This further suggests thaxt nothing depends on the application, so you're likely safe to just emerge -C it. HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] realplayer emerge problem
Will White schreef: When I emerge realplayer I get: emerge (1 of 1) media-video/realplayer-10.0.6 to / Downloading https://helixcommunity.org/download.php/1589/RealPlayer-10.0.6.776-20050915.i586.rpm https://helixcommunity.org/download.php/1589/RealPlayer-10.0.6.776-20050915.i586.rpm: Unsupported scheme. !!! Couldn't download RealPlayer-10.0.6.776-20050915.i586.rpm. Aborting. I have emerged 10.0.5 in the past with no problem, and have installed it from realplay, but I want to emerge mplayer with USE real, when the same thing happens. Does anyone know the answer. Thanks One answer: Open https://helixcommunity.org/download.php/1589/ in a web browser. See if RealPlayer-10.0.6.776-20050915.i586.rpm is there. If so, download it, copy it to /usr/portage/distfiles and try your emerge again. If not, or you cannot go directly to that page, go to the helix homepage, get to their download page, and by whatever means the page demands, download RealPlayer-10.0.6.776-20050915.i586.rpm, copy it to /usr/portage/distfiles, and try your emerge again (if the file is already in /usr/portage/distfiles, Portage won't try to fetch it). If RealPlayer-10.0.6.776-20050915.i586.rpm does not exist for some reason (that particular version is not available), then you'll likely have to either emerge a different version, sync, or wait to resolve the issue. Hope this helps, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Quoting styles
Dale schreef: Alexander Skwar wrote: Dale schrieb: Well I have to have HTML because I use email for a LOT more than just this list. And why do you need HTML there? Anyway, Mozilla/Thunderbird makes it very easy to decide if HTML is used or not - when you set the default to text/plain, you hold down shift while you click on the Compose, Reply, Reply All or Forward button. This will then create an HTML mail. Because I send pictures and make my text have color and all that stuff. Ain't that HTML? Ain't no list getting between me and my lady. No way! Who said anything about 'getting between you and your lady'? That's *personal* mail, and this list, nor any other list, cares what you do in your personal mail. But mail sent to this list is *public* mail, and such public mail has preferences for display and use so that it can reach the widest area of public view possible-- those who read the list via text readers, those who read it via newsgroups (some of which do not accept/display HTML), those who read it via webmail (and some of those don't display HTML either, or only do so with certain browsers, which any given person may or may not be using at that moment), those who read the archives, those who filter it, those who thread it, those who do not have much time and only want to read what they are interested in, and are not going to be scrolling and trimming just to do you a favor... don't forget, you are asking for *help from a stranger*-- that's a favor in anybody's book. Both Alexander and I have shown you how you can 'fix' mail for *this list only*, without bothering any of your other mail, where you can, as I said, do what you like. Nobody cares, or if they do, it's their problem to tell you about. But if you want us to help you, for free, out of the kindness of our hearts, it's not only polite to consider our relatively mild and minor conditions, but worse, it's *impolite* to reject them so violently. Getting on the bad side of those you want aid and succor from is simply dim, in strategic terms. Strategically, as the person who needs help, you want to make it as easy as possible for as many people as possible to read *and understand* your mail, so that they can answer your question. And yes, that means plain-text to reduce irrelevant data and bandwidth; it means appropriately trimming, to reduce wasted time; it means proper subjects and not hijacking threads. You are of course free to ignore these mild conditions, but you may well find that your question goes unanswered, because the people who could answer it could not or would not read your post (they couldn't understand it because it was in the middle of a mixed top- and bottom- posted thread; it was in HTML and they use mutt; it was a hijack-by-subject name of a thread they had filtered so they never saw it; you are now on their 'ignore' list because you're snarking so severely over something so stupid, and they don't read any of your posts). I myself prefer success (getting my question answered) to the 'moral high ground' of doing things the way I want them within a community setting and be damned to the rest of you, but if you prefer it the other way around, that is your right, and you can have the consequences as well, for all of me. But, whatever. I'm really out of this. It's too ridiculous. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Quoting styles
Alexander Skwar schreef: Holly Bostick schrieb: The other joke is similar, but goes like this There are 10 kinds of people in the world Those who understand binary, and those who don't (1 is yes in binary language, which only consists of the letters 1 and 0, and is the basis of all computer languages, and 0 means no). Interesting explanation :) I always explained that joke, like this: 10 in binary is 2 in decimal. But if you don't know about binary, you read 10 and might think decimal 10. If you think that, than it's kind of strange to only name 2 types of people. Oooh, so it's a double joke (in both binary and decimal). Now I like it even more. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Replacing Suse on my server.
Matthias Bethke schreef: Hi Anthony, on Sunday, 2005-10-30 at 16:06:47, you wrote: The main reason for my interest in Gentoo was to replace Suse on my server, since it looked promising in the control I have over the installation. My question is this: I want to replace Suse on the server with the minimal amount of server downtime (I won't have time to do a complete installation in one sitting - the Gentoo install I expect to take a number of weeks to set up before it will have the necessary software installed to replace Suse). I'm just in the process of doing the same thing. I would also like to point out that the SuSE installer has a special condition that I have not seen elsewhere: copy your current install to another location. I don't have a server, but I used this function to move my then-current SuSE install from one drive to another (from the emergency drive I had installed when I last broke Gentoo) to a semi-permanent partition on the drive where I now have Gentoo installed). Because the operation was a 'copy' of my current install, it wasn't bad at all in terms of downtime (there were a couple of minor errors, iirc), and I was able to do a normal alternative install from within the SuSE installation. Since the old SuSE installation was redundant, I was able to remove the emergency drive 'immediately' (had I so desired, but I didn't get around to it all that quick, since I was more interested in getting Gentoo installed). Obviously server settings and data are a separate issue, but it seemed relevant to mention the functionality, which seems specific to SuSE. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Quoting styles
Dale schreef: Well, I have Mozilla set up to send both types, plain and HTML, so that you can get whatever you want. It makes it take longer to send over my slow dial-up but I thought it polite, maybe it is not after all. In that case, you're wasting your own bandwidth, since many of us don't even want the HTML part and plain text is perfectly good enough for this list. If you told Mozmail to just send the text part to this list Edit=Preferences= Composition= Text composition= Send Options button= Plain text domains tab =Add button = type lists.gentoo.org and hit OK it would save you bandwidth and us a headache. To be honest, I just joined the list a few days ago and it is getting to be a bit much. It was sort of humorous at first but I can't seem to please everybody. Maybe I should just cancel and go somewhere else. Would that be OK??? I wish you'd make up your mind if we are the boss of you or not. We are the unwanted boss of you, since you refuse to just follow a couple of simple steps to produce more satisfactory mail, but now we are the wanted boss of you, who must permit you to unsubscribe to the list? It's your bloody life, if you want to unsubscribe, then do that... you don't need me/us to tell you whether it's OK or not! Holly (who clearly doesn't have enough to do today, if 10 minutes after saying she's out, is back in. Sigh.) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Quoting styles
Dale schreef: I wonder which one worked, the telling it to ask first, which it didn't, or setting the domain thing. I don't know why the asking thing didn't work (I'd have to look, and it's not really important anymore), but the domain thing doesn't have to ask you, because you've told it what to do. Don't worry, there is an explanation of what's going on, but I don't think you want to hear it; rest assured that all is working correctly at this point. snip I can't tell any difference over here. It looks the same to me. scratches head Well, there's nothing but text in this message, so there's no reason it should look different when displayed as HTML or as text (because there's nothing to display *but* text, which looks the same in HTML as it does plain) Did it work this time too? I'm confused. It's OK, it's normal for me. Well, you could look at your headers to see for sure, but that would probably confuse you more; suffice to say I've looked at the header for this mail, and it is plain text. Dale :-) --- Not HTML right? I put in : - ) with no spaces. No, it's not HTML-- a cute trick of Mozilla mail and Thunderbird is the ability to convert known smiley text to a graphic (it's a setting, on by default, but it can be turned off). It appears to me as a yellow smiley face as well (because I use Thunderbird and have the setting on), but to those using command-line email readers, it appears as a text smiley, which those users should be able to recognize just as well as the graphic. :-D Welcome back! Glad you let your huff go off without you :-) . Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Quoting styles
Dale schreef: Hemmann, Volker Armin wrote: Sometimes this 'educating' may sound much harsher than ment - but don't forget, that for a lot of people on this (or every public) mailing list english is only the second or third language - and hitting the right 'tone' is not easy, if you are not a native speaker. Thanks, I needed that. Can I assume english is not your native language? The writing was fine, the name gave it away though. Tip: the name doesn't give it away, the email address (in combination with the name) does. (Sorry to use you as an example, Volker, but you're a good one for this). Dale, when reading mail in Mozilla (which of course I know you're doing), you might notice in the window where the mail content actually appears, next to the word Subject in the bar above the text of the mail, there's a little white box with a plus sign in it. That bar, for this mail, probably says: Subject: blah blah blah_Holly Bostick_ (as a link, that if you click it, will open up a compsition window addressed to me, so you can curse my name or tell me what a bi-atch I am, or whatever :-) ). The thing is, the designers of this mail program figure you don't necessarily want more information than that right at the outset; you most likely want to read the mail-- and that is most likely true. But you can easily get more information (though still simplified, unless you change certain other settings), by clicking that little white box next to the word Subject. If you do so, the bar containing the *mail header* will be expanded (taking up some of the display room of the mail itself, which is why it's normally not expanded) and you will be able to see the email address of the sender (as well as some other information. There is even more information contained in the headers, but these are 'Normal' headers; to see all the information, you would have to display Full headers, which is not necessary atm). So, getting back to Volker, yes, he has a very German name-- but anybody can have a very German name, if they're of German descent. But if you select a mail from him, and click that little white plus sign, you'll see that his email address is [EMAIL PROTECTED] I'm sure you know that .de means Germany, just as the .nl at the end of my email address indicates that I'm in The Netherlands. A guy with a German name, posting from Germany-- that's proof enough for me that Volker is in fact a native German, which of course means that his native language would be German. You'd never know it to talk to him on the list, though :-) . Anyway, this doesn't always work (for example, I'd never be able to guess where you're living from your email address, with its anonymous .net suffix), but it's a good place to start. Holly -- gentoo-user@gentoo.org mailing list
[gentoo-user] Weird pauses making me nuts
Hey, all, Sorry that this will not be an extremely clear question, but I really have no idea where to start, or what the problem is. Basically, my system is running fine (no overt problems), but about every 30 seconds or so, it 'pauses' to do something, and I have to wait for 5-10 seconds while it does it before I can go further. Or the display pauses, and I have to wait for the redraw , I can't tell which. The system is still running during these pauses, but if I'm typing this mail, for example, the letters I typed during the pause will not appear until the system resumes (or resumes displaying). If I then backspace to remove the typos I made when I couldn't see what I was typing, if a pause occurs during the repeated backspace hitting, I have to stop and wait, since I can't know where the cursor actually is until it again active. Gkrellm's animated displays pause during the pauses as well (which is a bit useful, so that I know when they're happening). Changing desktops is delayed, Page down in word processors is delayed, activities in the console are delayed. Heck, even dragging cards around in AisleRiot is delayed by these stupid unattributable pauses. Memory and CPU use are not bizarre, I have a lot of processes going, but nothing weird or unexpected seems to be running if I can trust top and gnome-system-monitor. Since all the problems seem to be related to the X server, maybe it's an X problem; I'm currently using the VESA driver, as I wanted to get a clean install of the new ATI drivers when I compile the next kernel (2.13-r5, I'm using 2.13-r4 atm). I'm not using anything but 2D applications atm, though (of course, since I have no 3D-capable drivers available). But maybe it's a kernel scheduling problem. Or maybe gamin sucks, halting the whole system while it updates the file tree. I really have no idea, and if it wasn't so very annoying, I wouldn't post such a formless plea for help, but if this rings a bell with anyone, I'd appreciate a nudge/push/shove in the right direction. Thanks, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Weird pauses making me nuts
Martins Steinbergs schreef: On Monday 31 October 2005 18:24, Holly Bostick wrote: Basically, my system is running fine (no overt problems), but about every 30 seconds or so, it 'pauses' to do something, and I have to wait for 5-10 seconds while it does it before I can go further. Or the display pauses, and I have to wait for the redraw , I can't tell which. snip Memory and CPU use are not bizarre, I have a lot of processes going, but nothing weird or unexpected seems to be running if I can trust top and gnome-system-monitor. Since all the problems seem to be related to the X server, maybe it's an X problem; I'm currently using the VESA driver, as I wanted to get a clean install of the new ATI drivers when I compile the next kernel (2.13-r5, I'm using 2.13-r4 atm). I'm not using anything but 2D applications atm, though (of course, since I have no 3D-capable drivers available). But maybe it's a kernel scheduling problem. Or maybe gamin sucks, halting the whole system while it updates the file tree. sounds like no DMA enabled mar bin # hdparm /dev/hdb /dev/hdb: multcount= 16 (on) IO_support = 1 (32-bit) unmaskirq= 1 (on) --using_dma= 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) geometry = 19929/255/63, sectors = 320173056, start = 0 Would that it was so simple: hdparm /dev/hda /dev/hda: multcount= 16 (on) IO_support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) geometry = 65535/16/63, sectors = 80060424192, start = 0 hdparm /dev/hdb /dev/hdb: multcount= 16 (on) IO_support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) geometry = 16383/255/63, sectors = 82348277760, start = 0 hdparm /dev/hdc /dev/hdc: IO_support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) HDIO_GETGEO failed: Invalid argument hdparm /dev/hdd /dev/hdd: multcount= 16 (on) IO_support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) geometry = 65535/16/63, sectors = 40027029504, start = 0 But thanks; I wouldn't have thought to check/confirm that DMA was (still) on. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Weird pauses making me nuts
Robert Svoboda schreef: * Holly Bostick [EMAIL PROTECTED] [2005-10-31 18:50]: Hey, all, Hi, [...] Since all the problems seem to be related to the X server, maybe it's an X problem; So have you tried it without X running? Not yet; can't kill X without killing a couple of high-priority jobs (both in computer terms and in RL terms), otherwise I would have tried that. But it's a fair question. On that note, though; what the heck could I do to test, without X? I can't think of much else than running a movie under command-line mPlayer, and while that sounds like a pretty valid test as far as it goes, I'm not sure it goes far enough to be adequate. What else could I do alongside it, other than running an emerge or something? Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] OT: top quotes, html mail, and binary jokes
Antoine schreef: Indeed, life is harder for those of us who don't have English as first language. kashani, still trying to get his German, Spanish, and Farsi up to speed Can you imagine how hard it is to learn another language when everyone wants to speak English to you? We used to complain about this *all the time* at Taalschool (the year-long Dutch as A Second Language course that is required by the government as part of the conditions for granting a Permit of Stay). Many of us lived with Dutch people (certainly those of us who were in the country because we were married to one), and of course that means family and neighbors and other contacts who were native Dutch speakers... but we found it universally difficult to get said native speakers to help us by speaking Dutch (preferably slowly), or (heaven forfend) helping us with our homework and the like, because they all wanted to improve or show off their English/Russian/French. Of course it's tiring for everyone, trying to have a conversation and having the subject under discussion interrupted by constant grammatical correction, and it's not really helpful to hold said conversations in the other language for purposes of clarity, but often necessary when new to the second language. But it was clear to us that the amount of practice time we were getting from our 'aces in the hole' was far less than could be explained by those excuses. We all found it very frustrating. Of course, now that I have a fair working knowledge of Dutch, my personal Dutchman helps me a lot more. Can't say I don't appreciate it, but I could have used the help more two years ago. I suspect that this expectation of (to my mind, rather excessive) self-reliance is common across Europe, though the Dutch may be a bit stricter about it than other European cutural groups. So once you get over the 'novelty hump', it should get better :-) . Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] arts crasheing: FIXED!
Schleimer, Ben schreef: Hi again, I figured out that artsd was crashing because I was trying to play a .ogg without having emerged kdemultimedia with the vorbis USE flag set. Well, that makes sense. Congratulations! I added the USE flag, reemerged kdemultimedia (which wasn't autoemerge when I did emerge -ND world??) If kdemultimedia wasn't emerged by itself, but rather as a direct dependency-- of amarok, for example-- you would need -u (--update) to catch it. Emerge world itself handles items directly in the world file (in this example amarok) and --deep handles deep dependencies (such as kcontrols, which is a direct dependency of konqueror, which is a direct dependency of amarok, which makes kcontrols a deep/indirect dependency of amarok, since kcontrols is required for one of amarok's direct dependencies to run). --update catches the direct dependencies of the program in your world file, and in fact it's not too wise to update --deep without -u as well, since that kinda reinforces the very crown of the pyramid (the packages directly in your world file), and the very foundation (indirect/deep dependencies of the packages in your world file), without reinforcing the middle(direct dependencies of the packages in your world file), which can lead to errors of ommision (a library gets updated without the package that depends on that library being updated, and so the package that depends on the library crashes the application that depends on the package that depends on the library, because only the new version of the middle package works with the updated library, when the version that you have installed and did not update does not). In terms of problems potentially caused by doing an emerge -D world without -u, you got off fairly easy. snip HOnestly though, is there some kind of standard set of flags one should have enabled? Well, there are the default USE flags, of course, but...should have? Under Gentoo? Um, no, she said mildly, stifling snickers, since that would be unkind. The entire design of Gentoo revolves around choice. Your choice. Under Gentoo, your system is quite definitively yours, your creation, your responsibility. Which is, imo, as it should be-- only you know what your system needs to run the way you want it to. But you do have to know what you want your system to do, and you have to pay attention to the infrastructure (USE flags and the like) to see if the current setup is going to follow your useage pattern, and change it if not. If I don't have any *.ogg files on my system, I don't need or care about the +vorbis or +ogg files being set. But you do, and it's up to you to know that and to use the available tools (like emerge --verbose) to see what packages use these flags and make sure that they are set before emerging those packages. Cost of doing business, as they say. Also, maybe there could be a standard way of telling the user that the feature is disabled because of a USE flag instead of just crashing. Cute idea, but really, how would that work? Since it would have to be encoded in the program, and that's obviously out of our control. Some programs do say I don't have support for this feature, but most of the time-- especially with multimedia programs, ime-- they just crash. But then again, only source-based distros allow you to pick and choose your feature-set before compiling the app; binary distros just choose all features and enable them, for the most part. Since any given program is ultimately expected to work under both sets of conditions, I can see how the designers would not be eager to prioritize their development time to design in a feature for what is ultimately a minority need (thus-and-so feature is not enabled), since the majority of 'users' (meaning distributions repackaging the application for... distribution) are not going to need this functionality (since all features are by default enabled), and those who do are expected/hoped to be experienced enough to know that they need to verify the feature-set beforehand. The fact that you fall outside both these categories (not using a binary distribution, yet did not verify your feature set before compiling) is, sadly, not likely to engender a great deal of sympathy. We're a hard crew, we Linux users (or maybe it's just me). But you could well post an enhancement bug somewhere (you could try b.g.o and see if they'll bump it upstream, or a bug on the individual application's site if it has one, or with KDE, if the individual application doesn't have its own bug reporting structure), and see what the response is. You never know. PS. The things you learn after hours and hours of messing with the system... Not sure if it's worth it... That's your decision and your choice, too. There's SuSE, there's Debian ($DEITY knows, there's good and plenty of Debian), there's Mandriva, there's Windows. It's your brainpower, it's your time, it's your computer. Do as you will. Holly -- gentoo-user@gentoo.org
