Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 140459 - Layman is dropping the target host name from HTTP fetch requests
Summary: Layman is dropping the target host name from HTTP fetch requests
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Gunnar Wrobel (RETIRED)
URL:
Whiteboard:
Keywords:
: 140464 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-07-15 03:09 UTC by Peter Humphrey
Modified: 2006-08-20 00:35 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Humphrey 2006-07-15 03:09:45 UTC
I've just finished rebuilding my ~amd64 box from scratch, and now when I run layman I get the following error:

-- 
# cat /usr/portage/local/layman/cache_65bd38402ac8431067b54904bd2ed2d1.xml
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The requested URL could not be retrieved</TITLE>
<STYLE type="text/css"><!--BODY{background-color:#ffffff;font-family:verdana,sans-serif}PRE{font-family:sans-serif}--></STYLE>
</HEAD><BODY>
<H1>ERROR</H1>
<H2>The requested URL could not be retrieved</H2>
<HR noshade size="1px">
<P>
While trying to retrieve the URL:
<A HREF="/proj/en/overlays/layman-global.txt">/proj/en/overlays/layman-global.txt</A>
<P>
The following error was encountered:
<UL>
<LI>
<STRONG>
Invalid URL
</STRONG>
</UL>

<P>
Some aspect of the requested URL is incorrect.  Possible problems:
<UL>
<LI>Missing or incorrect access protocol (should be `http://'' or similar)
<LI>Missing hostname
<LI>Illegal double-escape in the URL-Path
<LI>Illegal character in hostname; underscores are not allowed
</UL>
<P>Your cache administrator is <A HREF="mailto:root">root</A>.

<BR clear="all">
<HR noshade size="1px">
<ADDRESS>
Generated Sat, 15 Jul 2006 09:19:39 GMT by gate.prhnet (squid/2.5.STABLE14)
</ADDRESS>
</BODY></HTML>
-- 

Secondly, I assume that /usr/portage/local/layman/make.conf gets built when layman runs for the first time, but until then any emerge operation fails with no-such-file. Perhaps layman ought to create an empty file on installation, then fill it when it runs.

-- 
# emerge --info
Portage 2.1.1_pre2-r8 (default-linux/amd64/2006.0, gcc-3.4.4/amd64-vanilla, glibc-2.4-r3, 2.6.17-gentoo-r2 x86_64)
=================================================================
                       System Settings
=================================================================
System uname: 2.6.17-gentoo-r2 x86_64 AMD Opteron(tm) Processor 246
Gentoo Base System version 1.12.1
ccache version 2.4 [disabled]
app-admin/eselect-compiler: 2.0.0_rc2-r1
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r2
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.17
sys-devel/gcc-config: 2.0.0_rc1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.16
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--alphabetical"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk         http://ftp.easynet.nl/mirror/gentoo         http://trumpetti.atm.tut.fi/gentoo/         ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo         http://distfiles.gentoo.org         http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LANG="en_GB.ISO-8859-15"
LC_ALL="en_GB.ISO-8859-15"
LINGUAS="en_GB"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/vmware"
SYNC="rsync://gate.prhnet/gentoo-portage"
USE="amd64 X alsa arts avi bash-completion berkdb bitmap-fonts bzip2 cdr cli crypt cups dlloader dri dvd eds emboss encode foomaticdb fortran gif gpm gstreamer gtk gtk2 imlib ipv6 isdnlog ithreads javascript jpeg kde kdeenablefinal lm_sensors logitech-mouse logrotate lzw lzw-tiff mp3 mpeg ncurses nls nptl nptlonly nsplugin ogg opengl pam pcre pdflib perl png ppds pppd python qt qt3 qt4 quicktime readline reflection sample scanner sdl session spell spl ssl symlink tcpd tiff truetype truetype-fonts type1-fonts unicode usb userlocales vorbis wmf xml xml2 xorg xpm xv zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_en_GB userland_GNU video_cards_nv"
Unset:  CTARGET, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Peter Weller (RETIRED) gentoo-dev 2006-07-15 03:45:17 UTC
*** Bug 140464 has been marked as a duplicate of this bug. ***
Comment 2 Gunnar Wrobel (RETIRED) gentoo-dev 2006-07-18 12:24:05 UTC
This was probably caused by a problem of the gentoo webserver. layman-1.0.4 did not handle such errors very well.

Please test with layman-1.0.5. It is available in my overlay:

layman -f -a wrobel
emerge layman

It will be moved to portage next week if there are no major bugs discovered.
Comment 3 Gunnar Wrobel (RETIRED) gentoo-dev 2006-07-18 23:54:33 UTC
Hm, looking at the error again I am not quite certain that this had anything to do with the gentoo webserver. But I'd also so no reason why layman should drop the http://www.gentoo.org part from the urls. The urls are never modified whitin layman but only used as spoecified in the config file.

Anyhow the newer version of layman should not overwrite the cache file in such cases anymore but instead use the old version.
Comment 4 Peter Humphrey 2006-07-19 01:04:54 UTC
(In reply to comment #2)
> This was probably caused by a problem of the gentoo webserver. layman-1.0.4 did
> not handle such errors very well.
> 
> Please test with layman-1.0.5. It is available in my overlay:
> 
> layman -f -a wrobel
> emerge layman

Of course I can't do that. I need another tool, say svn. I've looked at http://overlays.gentoo.org/dev/wrobel, and rather than messing about creating a local layman overlay, and probably applying diffs wrongly, I'll wait until:

> It will be moved to portage next week if there are no major bugs discovered.

Thanks.
Comment 5 Peter Humphrey 2006-07-27 09:09:36 UTC
On trying 1.0.6 on my laptop today I get the following error:

-- 
# layman -L
* Failed to update the overlay list from: http://www.gentoo.org/proj/en/overlays/layman-global.txt
* Error was:
* Failed to parse the overlays list fetched from http://www.gentoo.org/proj/en/overlays/layman-global.txt
* This means that the downloaded file is somehow corrupt or there was a problem with the webserver. Check the content of the file. Error was:
* Failed to parse the overlay list!
* Error was:
* mismatched tag: line 5, column 2
* Failed to read a cached version of the overlay list from http://www.gentoo.org/proj/en/overlays/layman-global.txt. You probably did not download the file before. The corresponding entry in your layman.cfg file will be disregarded.
* Error was:
* Failed to read the overlay list at ("/usr/portage/local/layman/cache_65bd38402ac8431067b54904bd2ed2d1.xml")!
* Error was:
* [Errno 2] No such file or directory: '/usr/portage/local/layman/cache_65bd38402ac8431067b54904bd2ed2d1.xml'
-- 

I tried 1.0.5 yesterday on my main box and got the same result.

On both boxes I ran "emerge -C layman", then removed all the directories that layman had been using, then remerged layman.

I think the problem remains. Do I need to add a protocol to my squid server?
Comment 6 Gunnar Wrobel (RETIRED) gentoo-dev 2006-07-28 07:01:38 UTC
What do you see when you look at http://www.gentoo.org/proj/en/overlays/layman-global.txt in your browser? Does it look like an xml file (it should be xml despite the .txt ending)?
Comment 7 Peter Humphrey 2006-07-28 07:39:59 UTC
Yes - the first few lines say:

<?xml version="1.0" ?>
<layman>

  <overlay
      type = "svn"
      src  = "https://gentopia.gentooexperimental.org/svn/overlay/"
      name = "gentopia">

    <link>
      http://gentopia.gentooexperimental.org/
    </link>

    <description>
      Purpose

      To provide a smooth, seamlessly functional and enjoyable Gentoo
      Desktop experience by following the mantra of "Just Works".
    </description>

  </overlay>

...
Comment 8 Gunnar Wrobel (RETIRED) gentoo-dev 2006-07-28 09:27:42 UTC
Hm, this seems strange. If it is the standard xml file I would expect that it validates just fine. But layman sees a problem in that file (mismatched tag: line 5, column 2)

What does layman report if you fetch the list manually into the cache file:

wget http://www.gentoo.org/proj/en/overlays/layman-global.txt -O /usr/portage/local/layman/cache_65bd38402ac8431067b54904bd2ed2d1.xml

and run 

layman -n -L

afterwards? Does it fail to read the cache file?
Comment 9 Peter Humphrey 2006-07-28 10:15:38 UTC
I got the same mismatched-tag error with earlier versions of layman, when it was complaining about the format of the cache_*.xml file it had created in /usr/portage/local/layman[1]. The complaint seemed to be about the form of the error message layman itself was generating to report fetch failure. So today I wondered if a file like that was still skulking somewhere in the file system, and went looking:

-- 
# find /root -xdev -iname \*.xml | grep -v kde | grep -v lib32 | grep -v portage | grep -v mime | grep -v \/root\/etc
/etc/gconf/gconf.xml.defaults/%gconf-tree.xml
/var/lib/cache/gstreamer-0.8/registry.xml
/usr/lib64/python2.4/test/test.xml
/usr/share/X11/xkb/rules/xorg.xml
/usr/share/X11/xkb/rules/base.xml
/usr/share/doc/libxslt-1.1.17/html/tutorial2/libxslt_pipes.xml
/usr/share/doc/libxslt-1.1.17/html/tutorial/libxslttutorial.xml
/usr/share/doc/libxml2-python-2.6.26/examples/valid.xml
/usr/share/doc/libxml2-python-2.6.26/examples/tst.xml
/usr/share/doc/libxml2-python-2.6.26/examples/invalid.xml
/usr/share/doc/libxslt-python-1.1.17/examples/test.xml
/usr/share/qt4/q3porting.xml
/root/.gstreamer-0.8/registry.xml
-- 

I did as you asked in #8 - wget, then layman -n -L - and it worked just fine. But [2] :

-- 
# layman -a vmware
* Running command "/usr/bin/svn co http://overlays.gentoo.org/svn/proj/vmware/trunk/ /usr/portage/local/layman/vmware"...
svn: PROPFIND request failed on '/svn/proj/vmware/trunk'
svn: PROPFIND of '/svn/proj/vmware/trunk': 400 Bad Request (http://overlays.gentoo.org)
* Failed to add overlay "vmware".
* Error was: Adding the overlay failed!
-- 

This smacks of a config problem with my squid server. Its config file does already contain:
-- 
extension_methods REPORT MERGE MKACTIVITY CHECKOUT
-- 
but perhaps I need to add another method?

I notice that /usr/portage/local/ and below are owned root:root, but after:

-- 
# chown portage:portage -R /usr/portage/local
-- 

I got error [2] again.

[1] When layman 1.0.4 failed to fetch the overlay list, it created /usr/portage/local/layman/cache_*.xml and stored the error message in there. Then it appeared to parse the file instead of bombing out, and gave the mismatched-tag error re its own error message. I didn't bother to report that as a fault as you seemed to be working towards the next version anyway. Perhaps I should have - apologies if so.
Comment 10 Gunnar Wrobel (RETIRED) gentoo-dev 2006-08-01 09:22:39 UTC
The

svn: PROPFIND request failed on '/svn/proj/vmware/trunk'
svn: PROPFIND of '/svn/proj/vmware/trunk': 400 Bad Request

is definitely a squid problem. I actually had the same problem for some time now but I did not take the time to fix that. Especially since some svn stuff works just fine and only a few repositories fail.

So I guess the problem has been fixed and this is something is not related to layman anymore. I'll close the bug for now but please feel free to reopen if the problem is still caused by layman. 

And I wouldn't mind if you send me a mail in case you find out how to fix squid in order to work together with subversion :)
Comment 11 Peter Humphrey 2006-08-03 07:36:48 UTC
Curiouser and curiouser. I unset proxy environment variables, removed proxy statements from make.conf, shut down squid on my firewall box and tried layman -a vmware once more. Exactly the same result.

I'll see what I can do with tcpdump to prove what's going between boxes. Watch this space.
Comment 12 Gunnar Wrobel (RETIRED) gentoo-dev 2006-08-03 08:12:08 UTC
If you want to determine if layman is causing the problem or if it is the network connection you can also try to run the bare command:

/usr/bin/svn co http://overlays.gentoo.org/svn/proj/vmware/trunk/ /usr/portage/local/layman/vmware

If this fails it is not a layman problem, if it works layman is the culprit :)
Comment 13 Peter Humphrey 2006-08-04 04:17:33 UTC
(In reply to comment #12)
> If you want to determine if layman is causing the problem or if it is the
> network connection you can also try to run the bare command:
> 
> /usr/bin/svn co http://overlays.gentoo.org/svn/proj/vmware/trunk/
> /usr/portage/local/layman/vmware
> 
> If this fails it is not a layman problem, if it works layman is the culprit :)

It failed. So I'd better get down to sorting squid out. Thanks for your help Gunnar!

Comment 14 François Bissey 2006-08-19 16:26:42 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > If you want to determine if layman is causing the problem or if it is the
> > network connection you can also try to run the bare command:
> > 
> > /usr/bin/svn co http://overlays.gentoo.org/svn/proj/vmware/trunk/
> > /usr/portage/local/layman/vmware
> > 
> > If this fails it is not a layman problem, if it works layman is the culprit :)
> 
> It failed. So I'd better get down to sorting squid out. Thanks for your help
> Gunnar!
> 

Did you get to solve this problem? I am having the same problem,
some svns work while some other fail, for no apparent reason.
And since the one that fails also fails manually it is probably 
the same problem.

Of course I will have to deal with the added bonus that this is
not my own firewall but my employer firewall :( .
Comment 15 Peter Humphrey 2006-08-20 00:35:16 UTC
Not fixed here, I'm afraid. I thought I'd found a stray shorewall redirection rule, because after deleting it I managed to download the vmware overlay. But I couldn't repeat it and I'm back to being unable to use layman.

Actually, I do use layman, but on the firewall itself, which seems risky, and then scp the directories into place on my workstation box.

I hope to come back to this problem soon, after finishing some other work I'm on.