Re: Fwd: Build failed in Jenkins: ceph-master #1860

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux