Responsible Changed From-To: freebsd-ports-bugs->alepulver I'll take it.
State Changed From-To: open->feedback Builds fails: touches filesystem prior to install (file/dir etc/settings). Ask submitter.
Alejandro Pulver wrote: > Hello. > Hi there. Thanks for looking at the port submission. > The port fails to build because modifies the filesystem (outside > WRKDIR) before installing. The log is attached. > I have yet to trip this error condition although I have performed numerous port test builds using both 6.2 and current. Is there some way for me to reproduce the exact build process you used? > As a reference, the ${PREFIX}/etc/settings directory seems to be used > by Qt. > > Could you please investigate? > I will do my best but am not exactly sure where to start :/ Until you mentioned it, I didn't even know that the ${PREFIX}/etc/settings directory existed. The file manipulation must be related to some automated cmake build process. I will try to bring it up on their mailing list and see if I can get a straight answer. Thanks, -Matthew
On Tue, 02 Oct 2007 20:59:31 -0500 Matthew Grooms <mgrooms@shrew.net> wrote: > Alejandro Pulver wrote: > > Hello. > > > > Hi there. Thanks for looking at the port submission. > > > The port fails to build because modifies the filesystem (outside > > WRKDIR) before installing. The log is attached. > > > > I have yet to trip this error condition although I have performed > numerous port test builds using both 6.2 and current. Is there some way > for me to reproduce the exact build process you used? > Yes, install misc/tinderbox. The build process is the same, but happens in a clean environment, and does additional checks to the port behavior (like this one). This building system is derived (and periodically synced) from the FreeBSD building cluster scripts (which means the port will fail there too in this case). See the post-installation message and website for configuration information. > > As a reference, the ${PREFIX}/etc/settings directory seems to be used > > by Qt. > > > > Could you please investigate? > > > > I will do my best but am not exactly sure where to start :/ Until you > mentioned it, I didn't even know that the ${PREFIX}/etc/settings > directory existed. The file manipulation must be related to some > automated cmake build process. I will try to bring it up on their > mailing list and see if I can get a straight answer. > Maybe cmake generates a Makefile that creates the directory when building, try checking with grep(1) for "settings" in the work directory after 'cmake' was called, and/or read the complete Makefile (this could certainly be the problem). Best Regards, Ale P.S.: sorry for the long delay, I've been busy with some exams.
Alejandro Pulver wrote: > Hello. > > The port fails to build because modifies the filesystem (outside > WRKDIR) before installing. The log is attached. > > As a reference, the ${PREFIX}/etc/settings directory seems to be used > by Qt. > > Could you please investigate? > Ale, I tracked down this problem to the Qt user interface compiler ( uic ) which manipulates a plugin lock file. If you do a google search regarding this you will find several posts on the subject :/ Here is the relevant ktrace/kdump excerpt from the build ... 95971 uic NAMI "/usr/X11R6/etc/settings/qt_plugins_3.3rc" 95971 uic RET access 0 95971 uic CALL open(0x80b3b80,0x202,0x180) 95971 uic NAMI "/usr/X11R6/etc/settings/.qt_plugins_3.3rc.lock" 95971 uic RET open 5 95971 uic CALL fcntl(0x5,0x9,0xbfbfd7b0) 95971 uic RET fcntl 0 95971 uic CALL open(0x80b3b80,0,0x1b6) 95971 uic NAMI "/usr/X11R6/etc/settings/qt_plugins_3.3rc" Not sure how I can avoid this issue as uic is part of the official qt distribution, is required to build user interface components and has the lock file functionality built into the tool binary without any documented switch to disable the behavior. Any suggestions? Thanks, -Matthew
On Wed, 10 Oct 2007 00:23:19 -0500 Matthew Grooms <mgrooms@shrew.net> wrote: > Alejandro Pulver wrote: > > Hello. > > > > The port fails to build because modifies the filesystem (outside > > WRKDIR) before installing. The log is attached. > > > > As a reference, the ${PREFIX}/etc/settings directory seems to be used > > by Qt. > > > > Could you please investigate? > > > > Ale, > > I tracked down this problem to the Qt user interface compiler ( uic ) > which manipulates a plugin lock file. If you do a google search > regarding this you will find several posts on the subject :/ > > Here is the relevant ktrace/kdump excerpt from the build ... > > 95971 uic NAMI "/usr/X11R6/etc/settings/qt_plugins_3.3rc" > 95971 uic RET access 0 > 95971 uic CALL open(0x80b3b80,0x202,0x180) > 95971 uic NAMI "/usr/X11R6/etc/settings/.qt_plugins_3.3rc.lock" > 95971 uic RET open 5 > 95971 uic CALL fcntl(0x5,0x9,0xbfbfd7b0) > 95971 uic RET fcntl 0 > 95971 uic CALL open(0x80b3b80,0,0x1b6) > 95971 uic NAMI "/usr/X11R6/etc/settings/qt_plugins_3.3rc" > > Not sure how I can avoid this issue as uic is part of the official qt > distribution, is required to build user interface components and has the > lock file functionality built into the tool binary without any > documented switch to disable the behavior. > > Any suggestions? > Hello. Thank you for identifying the problem, this happens only when building as root (more precisely: with writing permission in ${QTBASE}/etc/settings). Gentoo have patched Qt 3.3 to avoid this. For the meantime I have added a post-build target to remove these files right after building. This is because that version of Qt is old and I don't think this will happen with other ports, otherwise I will look at the Gentoo patches. Best Regards, Ale
alepulver 2007-10-21 02:51:21 UTC FreeBSD ports repository Modified files: security Makefile Added files: security/ike Makefile distinfo pkg-descr pkg-plist Log: This port contains the Shrew Soft ike daemon and client tools. The software supports ike v1 communications between two gateways or a a client and a gateway. For more information please visit ... WWW: http://www.shrew.net/ PR: ports/116684 Submitted by: mgrooms at shrew.net Revision Changes Path 1.925 +1 -0 ports/security/Makefile 1.1 +94 -0 ports/security/ike/Makefile (new) 1.1 +3 -0 ports/security/ike/distinfo (new) 1.1 +7 -0 ports/security/ike/pkg-descr (new) 1.1 +8 -0 ports/security/ike/pkg-plist (new) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: feedback->closed New port added, with minor changes. Thanks!
Alejandro Pulver wrote: > > Hello. > > Thank you for identifying the problem, this happens only when building > as root (more precisely: with writing permission in > ${QTBASE}/etc/settings). Gentoo have patched Qt 3.3 to avoid this. For > the meantime I have added a post-build target to remove these files > right after building. This is because that version of Qt is old and I > don't think this will happen with other ports, otherwise I will look > at the Gentoo patches. > Ale, Thanks for finding a work around. If this port hasn't been committed yet, I am about to release 2.0.2 which has quite a few updates and bug fixes. Is it too late to base the initial port on that version instead of 2.0.1? If not, what information do you need from me to make this happen? Thanks, -Matthew
On Tue, 23 Oct 2007 01:53:40 -0500 Matthew Grooms <mgrooms@shrew.net> wrote: > Alejandro Pulver wrote: > > > > Hello. > > > > Thank you for identifying the problem, this happens only when building > > as root (more precisely: with writing permission in > > ${QTBASE}/etc/settings). Gentoo have patched Qt 3.3 to avoid this. For > > the meantime I have added a post-build target to remove these files > > right after building. This is because that version of Qt is old and I > > don't think this will happen with other ports, otherwise I will look > > at the Gentoo patches. > > > > Ale, > > Thanks for finding a work around. If this port hasn't been committed > yet, I am about to release 2.0.2 which has quite a few updates and bug > fixes. Is it too late to base the initial port on that version instead > of 2.0.1? If not, what information do you need from me to make this happen? > > Thanks, > Hello. You're welcome. I have committed it, so please send a patch to the current version. Best Regards, Ale
Alejandro Pulver wrote: > > Hello. > > You're welcome. I have committed it, so please send a patch to the > current version. > Fair enough. A patch is attached. I also updated the NAT-T patch notices a bit so please let me know if it looks alright. Thanks again, -Matthew
Matthew Grooms wrote: > Alejandro Pulver wrote: >> >> Hello. >> >> You're welcome. I have committed it, so please send a patch to the >> current version. >> > > Fair enough. A patch is attached. I also updated the NAT-T patch notices > a bit so please let me know if it looks alright. > Ale, The Ubuntu folks have a requirement that man pages be included for each executable binary in a package. I checked the CVS version of the ports tree and saw that you hadn't committed the 2.0.2 update so I went ahead and rolled the new files into the official release archives. Of course this means the original update patch that I sent you wont do so I have attached an updated version. Please accept my apologies if this creates any additional work for you. Thanks in advance, -Matthew