[gentoo-amd64] Re: attempt to emerge dev-texlive/texlive-latexextra-2008-r1 failed

[Duncan]

"John P. Burkett" <burkett@×××.edu> posted 4A06F178.7060007@×××.edu,
excerpted below, on  Sun, 10 May 2009 11:23:36 -0400:

> Duncan wrote:
>> "John P. Burkett" <burkett@×××.edu> posted 49FDCD09.7070204@×××.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