Duncan wrote: > "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
Thank you, Duncan, for your very clear and helpful suggestions. I have now cloned the bug. It is in the database as bug 270230. The CC list includes 1i5t5.dun...@cox.net. While waiting for a portage bug fix, I'll follow your suggestions about trying to learn to update my kernel. Thanks again! > > 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. > -- John P. Burkett Department of Economics University of Rhode Island Kingston, RI 02881-0808 USA phone (401) 874-9195
