Package Details: ocis 8.0.0-1

Git Clone URL: https://aur.archlinux.org/ocis.git (read-only, click to copy)
Package Base: ocis
Description: A file sync & share platform designed to scale
Upstream URL: https://github.com/owncloud/ocis
Licenses: Apache
Submitter: bgiovanni
Maintainer: MrBlumi
Last Packager: MrBlumi
Votes: 1
Popularity: 0.000000
First Submitted: 2023-06-07 19:35 (UTC)
Last Updated: 2026-02-18 14:11 (UTC)

Latest Comments

1 2 Next › Last »

MrBlumi commented on 2026-01-08 21:21 (UTC)

Build process of OCIS is currently not compatible to go 1.25 Until they have an upstream fix for this, you have to either compile go 1.24.x first or use an old package out of your local package cache or the Arch Linux archives.

Moxon commented on 2025-11-20 21:50 (UTC)

Not yet. I just discovered opencloud which seems to be a useful and more actively developed alternative, so I will probably use this ...

MrBlumi commented on 2025-11-20 19:40 (UTC)

I can have a look at the beginning of dezember. Atm I am traveling and have no computer with me. But have you tried building in a vanilla Arch Linux chroot environment?

Moxon commented on 2025-11-20 15:44 (UTC) (edited on 2025-11-20 15:45 (UTC) by Moxon)

Thank you for this package!

Unfortunately it does not compile at them moment (tested on two different systems, both up to date). Error message is:

  ../services/idp/idp.go:8:12: pattern assets/*: cannot embed file assets/identifier/static/media/javascript,__webpack_public_path__ = __webpack_base_uri__ = htmlWebpackPluginPublicPath;.1feff74f.bin: invalid name javascript,__webpack_public_path__ = __webpack_base_uri__ = htmlWebpackPluginPublicPath;.1feff74f.bin

Any idea how to fix this? Compiling ocis from sources as described here https://github.com/owncloud/ocis?tab=readme-ov-file#use-the-ocis-repo-as-source works.

MrBlumi commented on 2025-01-27 12:08 (UTC) (edited on 2025-05-30 07:54 (UTC) by MrBlumi)

I can't reproduce the issue with kpop - the build runs through without problems. No difference whether I build directly on notebook/vps or if I build in a (completely new) chroot environment on notebook/vps or if I build in an x86_64 or aarch64 environment.

Can you try again please in chroot environment if that is working for you?

mkarchroot /mnt/root base-devel
makechrootpkg -r /mnt

You'll need the devtools package for these commands to work - they'll create an Arch Linux filesystem tree inside the /mnt/root folder and afterwards use it to compile the package in the new environment...

MrBlumi commented on 2025-01-26 23:09 (UTC) (edited on 2025-05-30 07:56 (UTC) by MrBlumi)

Oh damed, I should read these messages more carefully in the future. I have to Apologie to both of you.

@codified_mantel: I will have a look at this myself tomorrow, but as i usually build in a clean chroot without anything except base and base-devel preinstalled this has to be an issue that arrised the last few weeks. I don‘t know if I can come up with a solution…

@TrialnError: thanks for having a look at it. And yes, I will definitively have a look at opencloud but I‘d wait a few weeks until they have at least some code online (atm there is only an announcement in their github page) and until it‘s clear whether they have any legal issues with kiteworks or not…

codified_mantel commented on 2025-01-26 22:36 (UTC)

A little more digging this morning shows that the kpop dependency comes as part of the idp web ui when attempting to build ocis-7.0.0. If you have it installed anywhere on your system already (as is how .pnpm works), you won't encounter this issue. But any without are screwed atm.

codified_mantel commented on 2025-01-26 22:07 (UTC) (edited on 2025-01-26 22:20 (UTC) by codified_mantel)

The kpop dependency comes in at the ci-node... pnpm stage, and if that part isnt fulfilled it ditches the whole build rendering it useless. I checked the PKGBUILD but thats as far as I could get with it. The OpenCloud fork looks interesting but idk. If you want to test the issue, try clearing out your installed node_modules first. Strangely the ETIMEOUT is immediate, regardless of timeout set.

TrialnError commented on 2025-01-26 22:01 (UTC)

Yeah, it didn't really surprise me either. And I hope the best.
No need for immediate action. Release is announced for March. Still some time :D Great to hear, you're considering it :) Dunno about myself maintaining the PKGBUILD alone. But I would be open for sharing the burden (aka Co-Maintainer).

I didn't have that issue. That was codified_mantel :D I just mentioned what can happen if x1 can download y, but x2 not. I did a test build of ocis and it worked, therefore the remark "nothing actionworthy". But didn't check if there is a dep like kpop.

MrBlumi commented on 2025-01-26 20:08 (UTC)

I haven‘t noticed there was going to be a fork of OCIS, although I thought it was only a matter of time. But sure yes, I will have a look in the next few weeks and play around with an adjusted PKGBUILD if I manage to build it. There are several things I hope they will make better than OCIS before 😅. But if you want to maintain the packaging instructions for the fork instead, I won‘t complain either…

Concerning your issue with kopano.io, can you send me a bit more details by PM so that I can try to reproduce the bug in my instance?