Opened 13 years ago

Closed 13 years ago

#31078 closed defect (fixed)

qjson @0.7.1_1 build failure

Reported by: anonymous@… Owned by: nerdling (Jeremy Lavergne)
Priority: Normal Milestone:
Component: ports Version: 2.0.2
Keywords: Cc: rmstonecipher@…, pixilla (Bradley Giesbrecht), ryandesign (Ryan Carsten Schmidt)
Port: qjson

Description

Can't install qjson (on 10.6.8), needed by amarok.

--->  Computing dependencies for qjson
--->  Fetching archive for qjson
--->  Attempting to fetch qjson-0.7.1_1.darwin_10.x86_64.tbz2 from http://packages.macports.org/qjson
--->  Fetching qjson
--->  Verifying checksum(s) for qjson
Error: Target org.macports.checksum returned:  does not exist in /opt/local/var/macports/distfiles/qjson
Log for qjson is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_qjson/qjson/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>

Attachments (2)

main.log (44.2 KB) - added by anonymous@… 13 years ago.
qjson error log (/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_qjson/qjson/main.log)
qjson-Portfile.diff (719 bytes) - added by rmstonecipher@… 13 years ago.

Download all attachments as: .zip

Change History (12)

Changed 13 years ago by anonymous@…

Attachment: main.log added

qjson error log (/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_qjson/qjson/main.log)

comment:1 Changed 13 years ago by mf2k (Frank Schima)

Keywords: qjson removed
Owner: changed from macports-tickets@… to snc@…

comment:2 Changed 13 years ago by rmstonecipher@…

Jeremy,
Must qjson fetch from git when tarballs are available from SourceForge mirrors?
Attached is a patch to switch the fetch to sourceforge.

Cheers,
Ryan Stonecipher

Changed 13 years ago by rmstonecipher@…

Attachment: qjson-Portfile.diff added

comment:3 Changed 13 years ago by nerdling (Jeremy Lavergne)

Cc: rmstonecipher@… added
Status: newassigned

Was simply where I had found it when I created the port; my initial clicking to get the project home page continued to keep me at gitorious instead of sf. Feel free to submit this patch if you have time before I do.

comment:4 Changed 13 years ago by nerdling (Jeremy Lavergne)

I think the real issue here might be in how base is handling a package that was not fully failed on the archive mirror (that is, fetch failed but not building or license).

comment:5 Changed 13 years ago by raimue (Rainer Müller)

The issue has been fixed on trunk in r83471, but was not yet released.

comment:6 Changed 13 years ago by raimue (Rainer Müller)

I committed a workaround for this problem to qjson in r83492.

comment:7 Changed 13 years ago by rmstonecipher@…

Resolution: fixed
Status: assignedclosed

Switched to SourceForge, workaround removed in r83506.

comment:8 Changed 13 years ago by pixilla (Bradley Giesbrecht)

Resolution: fixed
Status: closedreopened

My port command is built from trunk r83544.
qjson extracts to ${name} rather then ${distname}.

DEBUG: Executing proc-post-org.macports.extract-extract-1
Error: Target org.macports.extract returned: /opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_devel_qjson/qjson/work/qjson-0.7.1: no such file or directory

Oddly, setting "worksrcdir ${name}" still produces this error.
Adding the following is working for me:

extract.mkdir       yes
extract.post_args   "| tar -xf - --strip-components 1 -C ${worksrcpath}"

comment:9 Changed 13 years ago by pixilla (Bradley Giesbrecht)

Cc: pixilla@… added

Cc Me!

comment:10 in reply to:  8 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added
Resolution: fixed
Status: reopenedclosed

Replying to pixilla@…:

qjson extracts to ${name} rather then ${distname}.

[snip]

Oddly, setting "worksrcdir ${name}" still produces this error.

The kde4 portgroup was buggy. Fixed in r83562.

extract.post_args   "| tar -xf - --strip-components 1 -C ${worksrcpath}"

Let's not do that kind of thing if possible. It introduces too much knowledge into the portfile about the internals of how the extract phase currently works, and makes it harder for us to change / improve the extract phase later.

Note: See TracTickets for help on using tickets.