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

[John P. Burkett]

Duncan wrote:
> "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

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.duncan@×××.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 [phone]