Opened 7 years ago

Closed 6 years ago

Last modified 5 years ago

#42789 closed defect (fixed)

libevt: no files matched glob pattern "*"

Reported by: ryandesign (Ryan Schmidt) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.2.1
Keywords: Cc: jul_bsd@…, cooljeanius (Eric Gallager)
Port: libevt

Description

libevt failed to build on the Snow Leopard buildslave:

https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/25222/steps/compile/logs/stdio

DEBUG: Executing proc-post-org.macports.destroot-destroot-0
xinstall: mkdir /opt/local/var/macports/build/_opt_mports_dports_security_libevt/libevt/work/destroot/opt/local/Library/Frameworks/Python.framework
xinstall: mkdir /opt/local/var/macports/build/_opt_mports_dports_security_libevt/libevt/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions
xinstall: mkdir /opt/local/var/macports/build/_opt_mports_dports_security_libevt/libevt/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/2.7
xinstall: mkdir /opt/local/var/macports/build/_opt_mports_dports_security_libevt/libevt/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib
xinstall: mkdir /opt/local/var/macports/build/_opt_mports_dports_security_libevt/libevt/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7
xinstall: mkdir /opt/local/var/macports/build/_opt_mports_dports_security_libevt/libevt/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
Error: org.macports.destroot for port libevt returned: no files matched glob pattern "*"
DEBUG: Error code: NONE
DEBUG: Backtrace: no files matched glob pattern "*"
    while executing
"$post $targetname"

Attachments (2)

Portfile (2.3 KB) - added by jul_bsd@… 6 years ago.
patch-libevt-Portfile.diff (2.7 KB) - added by jul_bsd@… 6 years ago.

Download all attachments as: .zip

Change History (21)

comment:1 Changed 7 years ago by jul_bsd@…

from stdio, it seems files are installed by setup.py inside /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7 whereos on my box it was ${destroot}/Library/Python/2.7/site-packages. That's why I was moving after to /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages.

Do you know why there is a change? is "python2.7-config --prefix" different depending on which macos release ? in this case, we need to have something like set python_dir=python2.7-config --prefix and use that

on my system

$ /opt/local/bin/python2.7-config --prefix
/opt/local/Library/Frameworks/Python.framework/Versions/2.7

but the install goes on the wrong path, so move files in post-destroot.

for snow-leopard, it seems target dir is correct, so no need to move files. The ultimate test will be checking plaso work but need all the other dependencies before.

comment:2 Changed 7 years ago by jul_bsd@…

ok. bad direction. real problem is python selection

checking whether to enable enable debug output... (cached) yes
checking whether to enable build Python bindings... (cached) yes
checking whether to use use `python-config --prefix' to determine the Python directories... (cached) /opt/local/Library/Frameworks/Python.framework/Versions/2.7
checking for python... python
checking for python2.6-config... python2.6-config
checking for Python includes... -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6
checking for Python libraries... -ldl -lpython2.6
checking Python.h usability... yes

here a patch

  • force selection of python2.7. not sure if sufficient. need to be test in other environment.
  • just in case, add a if to glob move.

If the patch is good, I will also adjust other security/lib*

comment:3 Changed 7 years ago by jul_bsd@…

any comment?

once solved and if no error, I will adjust other security/lib* so that plaso port can be commited.

Thanks

comment:4 Changed 6 years ago by mf2k (Frank Schima)

The python variant should be re-named based on the actual version of python. In this case use python27.

comment:5 Changed 6 years ago by jul_bsd@…

I modified the name of python variant. What about the rest of the patch and python release selection?

comment:6 Changed 6 years ago by jul_bsd@…

update 20140411

  • port lint --nitpick
  • livecheck
  • /tab/spacex4/

comment:7 Changed 6 years ago by mf2k (Frank Schima)

Per the guidelines, please instead attach your patch as a unified diff.

comment:8 Changed 6 years ago by jul_bsd@…

oops, seems I forgot it. cleared.

Note: I'm not sure the foreach is the right move as for other security/lib* that I submitted, I had to comment it else it was halting destroot. destroot ok on my setup. need to see on others.

comment:9 Changed 6 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:10 Changed 6 years ago by jul_bsd@…

  • bump to 20140531
  • universal cflags
  • pyevt test fix

Changed 6 years ago by jul_bsd@…

Attachment: Portfile added

comment:11 Changed 6 years ago by jul_bsd@…

still waiting feedback why destroot python prefix seems different on some box . for now, using some workaround on other security/lib*

comment:12 Changed 6 years ago by jul_bsd@…

  • bump to 20140731
  • if/path pending

Changed 6 years ago by jul_bsd@…

Attachment: patch-libevt-Portfile.diff added

comment:13 Changed 6 years ago by jul_bsd@…

ping ?

comment:14 Changed 6 years ago by neverpanic (Clemens Lang)

Resolution: fixed
Status: newclosed

I have no idea on the python prefix issue. But from what I can see, the post-destroot phase should fix that?

Anyway, I'm committing this, since the port is currently broken on 10.9 without this patch. Instead of adding the if statement from your patch I took the liberty to add the -nocomplain flag to glob (see man n glob) which makes glob return an empty list instead of causing an error.

Aren't all pythons starting with SL behaving correctly in this case? I'd argue we can just drop the extra code then and let the older systems die.

In r125926.

comment:15 Changed 6 years ago by ryandesign (Ryan Schmidt)

Why were these lines added?

variant universal {}
configure.cflags-append "${configure.cflags} [get_canonical_archflags cc]"

The port's universal variant works fine for me without them, and surely it's wrong to append configure.cflags to itself.

comment:16 Changed 6 years ago by neverpanic (Clemens Lang)

I agree, an oversight by me. jul_bsd, do you think those are needed? Should I remove them?

comment:17 Changed 6 years ago by jul_bsd@…

oops. just see the comment. will update for next round and other lib too, no, it's ok to remove universal stuff. will include too

comment:18 Changed 6 years ago by jul_bsd@…

Ticket #45643

comment:19 in reply to:  17 Changed 5 years ago by ryandesign (Ryan Schmidt)

Replying to jul_bsd@…:

no, it's ok to remove universal stuff.

Done in r137232.

Note: See TracTickets for help on using tickets.