"John P. Burkett" <burk...@uri.edu> posted 4a06f178.7060...@uri.edu, excerpted below, on Sun, 10 May 2009 11:23:36 -0400:
> Duncan wrote: >> "John P. Burkett" <burk...@uri.edu> posted 49fdcd09.7070...@uri.edu, >> excerpted below, on Sun, 03 May 2009 12:57:45 -0400: >> >>> Thanks, Duncan. [...] The results are the same; the latest version >>> available version of sys-apps/portage is still listed as 2.1.6.11, >>> which is the version I have installed. >>> >>> I attempted to manually download the source file, and place it in >>> distfiles, and then run emerge. [Still had the problem.] >> >> That's clearly a portage bug (even if we didn't already know it based >> on the bug you mentioned and the new versions that are /supposed/ to be >> out), as that argument list isn't even that long at all. >> >> So one way or another, we gotta get around that bug. >> >> You've verified that you can decompress that source archive manually, >> right? > Yes, it appears that I can decompress lzma files. >> Meanwhile, on portage upgrade side... >> 2.1.6.12 is indeed in-tree, but no arch has keyworded it stable yet. >> I don't see any masking and checking the ebuild itself, I see it's >> keyworded ~arch. >> I don't know why it hasn't been stable-keyworded, except that >> archs probably haven't gotten to it yet, but you might wish to consider >> adding: >> >> ~sys-apps/portage-2.1.6.12 >> >> ... to your package.keywords file or directory. > After adding ~sys-apps/portage-2.1.6.12 to my package.keywords file, I > did "emerge portage". That process appears to have been successful. Now > when I do "emerge --search portage" the response is > * sys-apps/portage > Latest version available: 2.1.6.12 > Latest version installed: 2.1.6.12 OK, great. At least that's still working as it should. > So far, so good. However, when I do "emerge texlive-latexextra", the > response is as follows: > Calculating dependencies... done! > >>>> Verifying ebuild manifests > >>>> Emerging (1 of 1) dev-texlive/texlive-latexextra-2008-r1 > [Errno 7] Argument list too long: [etc] >> There are other alternatives too. Did you try using the --fetchonly >> option? The bug mentions that worked for some people. > Doing "emerge -f texlive-latexextra" also produces "argument list too > long" errors, for example: >>>> Downloading > 'http://ftp.jaist.ac.jp/pub/Linux/Gentoo/distfiles/texlive-module- pdfcprot-2008.tar.lzma' > [Errno 7] Argument list too long: > /usr/bin/wget -t 5 -T 60 --passive-ftp -O > /usr/portage/distfiles/texlive-module-pdfcprot-2008.tar.lzma > http://ftp.jaist.ac.jp/pub/Linux/Gentoo/distfiles/texlive-module- > pdfcprot-2008.tar.lzma So the workaround others found doesn't work for you. Ugly! >> There's some additional discussion on why it happens -- are you using >> an old kernel (<2.6.23)? They had shorter max commandline lengths. >> Thus, upgrading your kernel is presumably another alternative. > I'm using kernel 2.6.20-gentoo-r6. Upgrading to a more recent kernel > would probably be beneficial but may require skills that I lack. Well, you'll need to learn to do it at some point. Now's probably as good a time as any... OK. We have two paths we can work on. First, whatever they did to fix the bug in portage-2.1.6.12 might have fixed it for some, but it didn't for you. Thus, one path is continuing to work on the portage bug. At this point, it's time to reopen (or clone since we can't reopen) the bug and get the portage devs looking at it again, since it's a portage bug that's obviously not fixed for you, when they think it is. I see 2.1.6.13 is out now. You will want to update to it (you'll need to change your package.keywords again) to ensure the bug isn't fixed by something else they did. If the bug is still there, here's what I'd do. Go to bug 262647. As it isn't your bug, you can't reopen it. However, you can clone it (link at the bottom of the main bug status area, under the Additional Comments textbox, but BEFORE the comments, "Clone This Bug" link to the right). Do so, choose as a product "Portage Development", version 2.1, component "Core", then explain why you are cloning the bug, that 2.1.6.12 (and .13) that were supposed to have the fix, don't seem to work for you. You'll also want to mention that -f and/or downloading it manually to $DISTFILES, then rerunning the emerge, does NOT fix it for you. Mention your kernel version 2.6.20 as that's useful information as well, add your emerge --info and anything else you can think of that would be useful. You can also link to this thread as it's seen on gmane, so they can see what we've already tried without you having to retype it all. Finally, add me to the CC for the bug, as I'm interested in following it. http://comments.gmane.org/gmane.linux.gentoo.amd64/14380 Meanwhile, the second path we can try is the kernel upgrade path. You weren't sure about it, but luckily, Gentoo has quite some help on the subject. But first, a hint. Gentoo really does have some good documentation. Actually, Gentoo's documentation is often good enough folks from other distributions use it too. =:^) As such, anything big you're thinking about doing on your system, it's worth checking to see Gentoo has some documentation on the subject. What I usually do is go to the docs list page and then use my browser's search function look for docs on whatever it is I'm interested in. In this case, that's kernel upgrades, so I searched on "kernel", and came up with the below list of links from the documents list page. The big list of Gentoo documents. Bookmark it! =:^) http://www.gentoo.org/doc/en/list.xml ..... Some kernel related documentation that should be of help: Gentoo Linux Kernel Upgrade Guide The kernel upgrade guide looks to be the one most immediately of interest here. http://www.gentoo.org/doc/en/kernel-upgrade.xml Gentoo Linux Kernel Guide The kernel guide is mainly about choosing the right kernel sources, from multiple choices available. http://www.gentoo.org/doc/en/gentoo-kernel.xml Gentoo Linux Kernel Configuration Guide The kernel config guide is an overview of the manual kernel configuration process. It doesn't go into too much detail, but if you've never done it before, it could be very helpful, none-the-less. It does cover several areas people often find confusing, SATA as SCSI, IDE and DMA, USB, multi- core/multi-CPU, etc. Another section links a bunch of other more topic specific documents, on ALSA/sound, bluetooth, printing, power management, USB, etc. http://www.gentoo.org/doc/en/kernel-config.xml Compiling the Linux kernel This is not a Gentoo-specific document but one written originally for IBM developerWorks by Daniel Robbins, Gentoo's founder. It'll give you a lot of generally useful background and DRobbins is good at explaining things, but parts of it are now a bit dated. For example, it discusses LILO for booting, while Gentoo (and most modern x86 and amd64 distributions) now uses GRUB. Thus, you'll probably want to skip that section (section 5). http://www.gentoo.org/doc/en/articles/linux-kernel-compiling.xml The Gentoo Handbook also covers the kernel briefly, in the install coverage. But you probably read that while installing and are still a bit leery about kernel config, thus the above. I'm mentioning it here mainly for completeness, but if you've not looked at it in awhile, it couldn't hurt to review that information as well. ..... Also possibly of interest: The Gentoo Linux Genkernel Guide (outdated) Genkernel is a tool designed to help automate the kernel compilation process. It'll help you create kernels similar to those on the installation CDs. But while this document is still linked from several of documents above, it's outdated and no longer maintained. As such, while parts of it may be helpful, other parts may be more confusing than helpful, unfortunately. As they say, YMMV. http://www.gentoo.org/doc/en/genkernel.xml With those to help, and by copying the .config of your existing kernel and using make oldconfig, you should be well on your way to a successful kernel upgrade. A few of those and it'll be old hat. =:^) I'd probably start with the general Compiling the Linux kernel link, to get a background, then look at the upgrade guide to get a better idea of what you're looking at here, then I'd use the config guide for configuration, and if necessary, go back to the upgrade guide again to actually do it. Again, a very good place to start is with the .config from your existing kernel, using make oldconfig to adapt it to the newer kernel. However, it's reasonably likely that you'll still have questions about individual choices. That's normal. You just experiment a bit until you get a kernel that does what you need. As long as you don't remove your old kernels, you can always reboot to one of them if the new kernel doesn't work. And in fact, that's what even the Linux kernel hackers themselves do. I do a lot of kernel testing here, and my rule of thumb is to keep at least two known working kernels around, one good stable release from the release BEFORE the one I'm testing, and a generally working current kernel. Thus, until I have a known working current pre-release kernel, I keep at least two previous release series kernels around, generally the release and the first stable point release after it. (So for instance for the current 2.6.30 series pre-release testing, I kept 2.6.29 and 2.6.29.1 around, until I had a decently stable 2.6.30-rc2 plus version working to my satisfaction, after which I deleted 2.6.29 but kept the latest stable I had, 2.6.29.1, just in case something weird turned up with the 2.6.30- rc2+ I had /thought/ was working.) For you, you'll probably keep 2.6.20.x around for some time, since you're not going to be doing the kernel testing I do, and will presumably only be running stable versions. ..... So anyway, between opening a portage bug and trying out a new kernel, one way or another, you should eventually get around that bug. I'd encourage you to keep working on both paths. In particular, if you do the clone bug thing, even if you get a new kernel working that doesn't have the issue, I'd encourage you to keep around your current 2.6.20 for testing until that portage bug is resolved one way or another, because there's probably others that will run into it as well. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
