On 6-3-2018 18:10, John Spray wrote: > On Tue, Mar 6, 2018 at 4:59 PM, Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote: >> On 6-3-2018 17:12, Ricardo Dias wrote: >>> Hi Willem, >>> >>> This only means that you cannot currently build the dashboard_v2 >>> frontend in freebsd. >>> >>> I'm not familiar with freebsd, but we can investigate if it's possible >>> to make it work. >> >> Yup, that much I found out. :) >> Disabling with `-D WITH_MGR_DASHBOARD_V2_FRONTEND=OFF` will restore >> successful building and testing. >> Probably not all modules (fsevents??) are compatible with FreeBSD, given >> the more detailed error output. >> >> So probably it'll need a version that matches: >> 26225 warn notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform >> for fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: >> {"os":"freebsd", >> "arch":"x64"}) >> >> >> But then still building this way of creating the DASHBOARD_V2 module >> into the FreeBSD package is going to be even more of a problem, since it >> is not expected (allowed) that neither during the building of the >> package the make file fetches extra online "code", nor during >> installation of the package is it expected to fetch more code. >> >> If so, then that code needs to be installed as another (set of) packages. >> >> >> Perhaps a trick around it would be to fetch the data before the actual >> building starts, but I know that that method is frowned upon. > > In the linux packaging, we sort of sidestep that issue by doing the > javascript pre-processing before the source tarball is generated. > That way, from the point of view of rpm/deb builds, the frontend is > all just static files. It stretches the definition of "source code" a > little bit, but it's the best compromise we have. > > There have been some attempts to remove the need for node/npm in > builds by individually rpm-izing javascript dependencies, but that > approach hasn't been too popular with people building applications, > and the last time I did an informal survey I found that most major > projects were either using static JS in their trees or using > npm-managed dependencies and having a node build step like we do. Sounds very much like the evasive action that would be needed here too. But then I would like it to be a tarball just for this part. Don't want to have the whole ceph-tree as tarball, if I can prevent it. This used to be a real BIG issue when Boost/Beast was onboard, but still. With that tarball, I would extract it at post_install into the staging area. AND it should be stable in the files/directories that are in there, since I need to be able to generate a pkg-plist containing all filenames before I can actually assemble the package. If the tarball is variable, that is not going to work because the staging does not match the plist. --WjW > > Cheers, > John > > >> >> >> --WjW >> >> >>> >>> Thanks, >>> Ricardo >>> >>> On 06-03-2018 15:48, Willem Jan Withagen wrote: >>>> >>>> This is not going to work on FreeBSD atm... >>>> So I guess no dashboard_v2 for the time being. >>>> >>>> --WjW >>>> >>>> >>>> cd >>>> /home/jenkins/workspace/ceph-master/src/pybind/mgr/dashboard_v2/frontend >>>> && npm install >>>> >>>> npm ERR! code E404 >>>> npm ERR! 404 Not Found: node-freebsd-x64@8.9.4 >>>> >>>> npm ERR! A complete log of this run can be found in: >>>> npm ERR! /home/jenkins/.npm/_logs/2018-03-06T15_43_35_298Z-debug.log >>>> module.js:559 >>>> throw err; >>>> ^ >>>> >>>> Error: Cannot find module 'node-freebsd-x64/package.json' >>>> at Function.Module._resolveFilename (module.js:557:15) >>>> at Function.resolve (internal/module.js:18:19) >>>> at ChildProcess.<anonymous> >>>> (/home/jenkins/workspace/ceph-master/src/pybind/mgr/dashboard_v2/frontend/node_modules/node-bin-setup/index.js:18:27) >>>> >>>> at ChildProcess.emit (events.js:127:13) >>>> at maybeClose (internal/child_process.js:936:16) >>>> at Process.ChildProcess._handle.onexit >>>> (internal/child_process.js:220:5) >>>> npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.1.3 >>>> (node_modules/fsevents): >>>> npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for >>>> fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: >>>> {"os":"freebsd","arch":"x64"}) >>>> >>>> npm ERR! code ELIFECYCLE >>>> npm ERR! errno 1 >>>> npm ERR! node@8.9.4 preinstall: `node installArchSpecificPackage` >>>> npm ERR! Exit status 1 >>>> npm ERR! >>>> npm ERR! Failed at the node@8.9.4 preinstall script. >>>> npm ERR! This is probably not a problem with npm. There is likely >>>> additional logging output above. >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >>> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html