Packaging

[ovh]

Packaging

[widowild1]

now in archlinux
https://aur.archlinux.org/packages/svfs/

for test:
yaourt -S svfs

[metal3d]

Yes, but rpm build by fpm are not safe. :)

FPM is a very nice tool to build local rpm, tests, propose little programs if you don't have the time to build a specfile yourself. I agree and I'm using it a lot. But you cannot propose this rpm in a standard repository as "copr".

Copr repository makes some standard test to insure that rpm are dnf/yum compliant and that binaries are ok. That's why I want to propose a fedora/centos rpm build properly with my spec file.

Can you tell me the used license ?

[xlucas]

FRENCH

Bonjour !

Le script de packaging utilisé supporte à priori pacman. Je n'ai pas encore eu l'occasion de tester mais ça devrait être possible de sortir un package officiel d'ici peu dans ce cas.

Note : Pour des raisons pratiques, les issues github sont de préférence rédigées en anglais.

ENGLISH

Packaging is done with the great fpm which apparently has native support for pacman. Given this, it shouldn't take long for us to release an official package.

[metal3d]

I'm preparing a rpm for Copr repositories (fedora, centos) but I need to know the license name.

Glad to see this project :)

[xlucas]

Hello :)

Did you see we already provide rpm with our releases ?

[xlucas]

That's true, actually we use fpm to avoid maintaining a bunch of spec files whilst still in pre-release. We likely will propose proper packages on first release though.

But if you can already build a rpm with linted spec file etc that's great !

Licence is BSD, and I think most necessary information is already set in our rpms :

$ rpm -qip svfs-0.5.1-1.x86_64.rpm
Name        : svfs
Version     : 0.5.1
Release     : 1
Architecture: x86_64
Install Date: (not installed)
Group       : default
Size        : 11656712
License     : BSD
Signature   : (none)
Source RPM  : svfs-0.5.1-1.src.rpm
Build Date  : lun. 04 avril 2016 20:43:02 CEST
Build Host  : build.ovh.net
Relocations : / 
Packager    : [email protected]
Vendor      : OVH SAS
URL         : https://www.ovh.com
Summary     : The Swift Virtual Filesystem
Description :
The Swift Virtual Filesystem

[xlucas]

@widowild1 If you think fpm packaging won't likely match aur repos guidelines, contribution is welcome in order to bundle pre-releases for arch. Build steps are in the ruby packaging script which actually does this :

• Run go build with relevant GOOS and GOARCH environment variables set. Should be linux & amd64 in your case.
• Bundle with file mode 755 mount.svfs, hubic-application.rb and the freshly built binary renamed as svfs so package content looks like :

/sbin/mount.svfs
/usr/local/bin/hubic-application
/usr/local/bin/svfs

Dependencies are :

• ruby > 1.9.1
• fuse > 2.8

[metal3d]

@xlucas that's very complicated, right now, to have a linted package for go packages. Fedora advices to use "gofed" (https://github.com/gofed/gofed) but it's not fully compliant with svfs. These dependencies are problematics:

• golang(bazil.org/fuse) that is not packaged
• golang(github.com/ncw/swift)
• golang(github.com/xlucas/swift)
• golang(golang.org/x/net/context)
• golang(golang.org/x/sys/unix)

And I cannot, at this time, compile them with gofed for some reason. Example, your "swift" package dependes on bazil.org/fuse that cannot be built, so I cannot package it.

bazil.org/fuse cannot be managed by gofed unless using the "github" source, but dependencies cannot be ok.

And so on.

I'm currently seeking another way to fixup.

Note that to be fedora compliant, we shouldn't use "vendor", and have the entire dependencies packaged... that is very... ennoying :)

Thanks for the licence BTW :)

[xlucas]

Thanks alot ! 👍

I will try it.

[xlucas]

Just built a pkg for OSX (darwin/amd64, v0.6.0)

[Minims]

I've just make a try on OSX El Capitan 10.11.5, but .pkg fails.

loginwindow[93]: -[SFLListManager(ServiceReplyProtocol) notifyChanges:toListWithIdentifier:] Notified of item changes to list with identifier com.apple.LSSharedFileList.RecentApplications
CoreServicesUIAgent[1685]: Error -60005 creating authorization
SecurityAgent[1730]: activateIgnoringOtherApps:1
SecurityAgent[1730]: makeKeyAndOrderFront
SecurityAgent[1730]: com.apple.SecurityAgent.consoleLogin.UIShown
kernel[0]: ignored is_io_service_close(0x1000003f8,IOHIDParamUserClient)
UserEventAgent[45]: Failed to send message because the port couldn't be created.
sandboxd132: shove(1733) System Policy: deny file-write-create /sbin/mount_svfs
UserEventAgent[45]: Failed to send message because the port couldn't be created.
Installer[1729]: Le programme d’installation a rencontré une erreur qui a provoqué l’échec de l’installation. Contactez l’éditeur du logiciel pour obtenir de l’aide.

[xlucas]

The pkg was built on a previous OSX version so it has not been tested with the sandbox. Unfortunately I don't have such a setup at disposal right now.

Could you try to extract the pkg, put /sbin/mount_svfs script in a "/usr/local/sbin" directory inside the archive, instead of "/sbin", flatten it to a new package then try to install it again ?

[Minims]

I've extract the .pkg file, then moved them to /usr/local/bin & /usr/local/sbin and it works. I have not tried toi build à New .pkg file for now

[xlucas]

Apparently, the sandbox on El Capitan denies writing files in /System, /bin, /sbin and /usr (except /usr/local) as a security measure.

I've rebuilt the pkg for version 0.6.1 and bundled everything inside /usr/local/bin to address this issue.

[xlucas]

I'm closing this issue since the answer to the OP was provided.

Let's open more specific issues about packaging, this way we don't have a long standing catch-all issue.