Opened 10 years ago

Closed 4 years ago

#43689 closed defect (worksforme)

xorg-libpthread-stubs: Failed to fetch signature for archive: The requested URL returned error: 400 Bad Request

Reported by: switzer.aaron@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.2.1
Keywords: Cc: jeremyhu (Jeremy Huddleston Sequoia), ryandesign (Ryan Carsten Schmidt), cooljeanius (Eric Gallager), chrstphrchvz (Christopher Chavez)
Port: xorg-libpthread-stubs

Description (last modified by ryandesign (Ryan Carsten Schmidt))

I am fairly new at this so I apologize if this is a trivial problem.

running OS X 10.9.2 (Mountain Lion) installed Xcode Version 5.1.1 installed MacPorts-2.2.1-10.9-Mavericks.pkg

I am trying to install gtk2 and I am receiving this error:

bash-3.2# port install gtk2
--->  Computing dependencies for gtk2
--->  Dependencies to be installed: atk gobject-introspection cairo xorg-libXext xorg-libX11 xorg-libxcb xorg-libpthread-stubs xorg-xcb-proto libxml2 xz xorg-xextproto xorg-xcb-util xrender xorg-renderproto libtool gdk-pixbuf2 jasper jpeg tiff hicolor-icon-theme pango Xft2 harfbuzz graphite2 shared-mime-info xorg-libXcomposite xorg-compositeproto xorg-libXfixes xorg-fixesproto xorg-libXcursor xorg-libXdamage xorg-damageproto xorg-libXi xorg-inputproto xorg-libXinerama xorg-xineramaproto xorg-libXrandr xorg-randrproto
--->  Fetching archive for xorg-libpthread-stubs
--->  Attempting to fetch xorg-libpthread-stubs-0.3_0.darwin_13.noarch.tbz2 from http://nue.de.packages.macports.org/macports/packages/xorg-libpthread-stubs
--->  Attempting to fetch xorg-libpthread-stubs-0.3_0.darwin_13.noarch.tbz2.rmd160 from http://nue.de.packages.macports.org/macports/packages/xorg-libpthread-stubs
Error: org.macports.archivefetch for port xorg-libpthread-stubs returned: Failed to fetch signature for archive: The requested URL returned error: 400 Bad Request
Error: Failed to install xorg-libpthread-stubs
Please see the log file for port xorg-libpthread-stubs for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_xorg-libpthread-stubs/xorg-libpthread-stubs/main.log
Error: The following dependencies were not installed: atk gobject-introspection cairo xorg-libXext xorg-libX11 xorg-libxcb xorg-libpthread-stubs xorg-xcb-proto libxml2 xz xorg-xextproto xorg-xcb-util xrender xorg-renderproto libtool gdk-pixbuf2 jasper jpeg tiff hicolor-icon-theme pango Xft2 harfbuzz graphite2 shared-mime-info xorg-libXcomposite xorg-compositeproto xorg-libXfixes xorg-fixesproto xorg-libXcursor xorg-libXdamage xorg-damageproto xorg-libXi xorg-inputproto xorg-libXinerama xorg-xineramaproto xorg-libXrandr xorg-randrproto
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port gtk2 failed

Attached is the main log.

Thank you for all your help.

Attachments (1)

main.log (2.7 KB) - added by switzer.aaron@… 10 years ago.

Download all attachments as: .zip

Change History (8)

Changed 10 years ago by switzer.aaron@…

Attachment: main.log added

comment:1 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: jeremyhu@… ryandesign@… added
Description: modified (diff)
Summary: Cannot install gtk2xorg-libpthread-stubs: Failed to fetch signature for archive: The requested URL returned error: 400 Bad Request

I'm not certain why the server would have declared that your request was bad. Does it happen every time you try? It worked for me when I tried it just now.

comment:2 in reply to:  1 Changed 10 years ago by switzer.aaron@…

Replying to ryandesign@…:

I'm not certain why the server would have declared that your request was bad. Does it happen every time you try? It worked for me when I tried it just now.

Yes, Unfortunately this happened every time I tried to get and build the gtk2 gtkmm and gtkglext dependencies. I ended up installing these dependencies through HomeBrew and now I have them.

Thank you for your reply.

comment:3 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Then I suspect there is some problem with your network connection.

If the problem only appears with this one MacPorts mirror, I believe you can edit a setting in macports.conf to tell MacPorts not to use particular mirrors.

You could try using curl at the command line to see if it too sees the problem, and you could test some of the other mirrors as well to see if the problem is isolated to this mirror.

You should not attempt to use both Homebrew and MacPorts on the same computer. Please use a single package manager only, and uninstall the other and any packages you've installed with it; multiple package managers will likely interfere with one another, and we don't support that configuration.

comment:4 Changed 10 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:5 Changed 4 years ago by chrstphrchvz (Christopher Chavez)

Can this ticket be closed, or is there still an issue?

comment:6 Changed 4 years ago by chrstphrchvz (Christopher Chavez)

Cc: chrstphrchvz added

comment:7 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: worksforme
Status: newclosed

We got a similar report against a different mirror in #41849. That had a bit more analysis including some packet capture showing that the second request was indeed invalid in that where there should have been Host and Accept headers, there was garbage data. Of course without more data we don't know if the reason in that ticket is the same as the reason in this ticket.

I would guess that there was never a problem with the server, just a problem with the user's computer, such as software on the user's computer that interferes with network operations, like a virus scanner or firewall program. Or perhaps a corporate network filtering device doing things wrong.

Both reports were on Mavericks, so it's possible there could be a bug in the version of curl on Mavericks that sometimes affects MacPorts. But aside from these isolated reports, I haven't heard of other MacPorts users experiencing this problem. So unless there is more data that can be provided about this failure (a tcpdump?) I think we have to give up on it for now.

Note: See TracTickets for help on using tickets.