This release adds the configuration and documentation to use Euro-Office for nextcloud.
As per the MAINTENANCE.md file, it must be installed by at least two maintainers.
@ineiti confirms it's working, specifically including euro-office
#LLM_enabled
I take full responsibility for this code
I understand every line of this code
I tested this code thoroughly on my own computer / servers
None of the commit messages were created using LLMs
I will participate in any discussion on my own and will not use an LLM for the discussion
This release adds the configuration and documentation to use Euro-Office for nextcloud.
As per the MAINTENANCE.md file, it must be installed by at least two maintainers.
1. @ineiti confirms it's working, specifically including euro-office
#LLM_enabled
- [x] I take full responsibility for this code
- [x] I understand every line of this code
- [x] I tested this code thoroughly on my own computer / servers
- [x] None of the commit messages were created using LLMs
- [x] I will participate in any discussion on my own and will not use an LLM for the discussion
ineiti
requested review from dannygroenewegen 2026-09-28 19:18:22 +00:00
ineiti
requested review from moritz 2026-09-28 19:18:23 +00:00
ineiti
requested review from javielico 2026-09-28 19:18:43 +00:00
ineiti
requested review from carla 2026-09-28 19:18:59 +00:00
ineiti
requested review from simon 2026-09-28 19:18:59 +00:00
ineiti
changed title from WIP: Moving to latest nextcloud 34 release to WIP: Moving to latest nextcloud 35 release2026-09-28 19:21:33 +00:00
ineiti
changed title from WIP: Moving to latest nextcloud 35 release to WIP: Moving to latest nextcloud 34 release2026-09-28 19:21:52 +00:00
For the next one, it would be better to have separate PRs for something like adding eurooffice and upgrading nextcloud. So they can be reviewed and merged seperatly.
It's on my list to test v34, but currently focusing on other things so might take a bit.
For the next one, it would be better to have separate PRs for something like adding eurooffice and upgrading nextcloud. So they can be reviewed and merged seperatly.
It's on my list to test v34, but currently focusing on other things so might take a bit.
For the next one, it would be better to have separate PRs for something like adding eurooffice and upgrading nextcloud. So they can be reviewed and merged seperatly.
If it is easier for you to test, I can make two PRs. As we're already one major version behind, I didn't want to have to bug people too often :)
> For the next one, it would be better to have separate PRs for something like adding eurooffice and upgrading nextcloud. So they can be reviewed and merged seperatly.
If it is easier for you to test, I can make two PRs. As we're already one major version behind, I didn't want to have to bug people too often :)
I started our pipeline on this PR to test v34: https://drone.cicd.local-it.cloud/local-it/kolli-config/1280 but I haven't enabled euro-office yet. I will test this later.
I tested the nextcloud update to version 34 and it works and nothing breaks so far.
I haven't tested the onlyoffice integration, but I think it's safe enough to merge it. If someone finds any issues with the onlyoffice integration a new fixing PR could be created.
I tested the nextcloud update to version 34 and it works and nothing breaks so far.
I haven't tested the onlyoffice integration, but I think it's safe enough to merge it. If someone finds any issues with the onlyoffice integration a new fixing PR could be created.
ineiti
marked the pull request as ready for review 2026-10-08 07:39:11 +00:00
@ineiti Shouldn't #108 be merged and released first so there is a nextcloud:33-fpm recipe version before the upgrade to 34?
Great that this appears to work!
@ineiti Shouldn't #108 be merged and released first so there is a `nextcloud:33-fpm` recipe version before the upgrade to 34?
@ineiti Shouldn't #108 be merged and released first so there is a nextcloud:33-fpm recipe version before the upgrade to 34?
I prefer to release first the update to the major version, in case something goes wrong, and it's better to do one more patch/minor upgrade on the previous version.
But the MAINTENANCE.md file tells otherwise: BEFORE major upgrade, do a nextcloud:xx-fpm... Will do that for the 34-35 then...
> Great that this appears to work!
>
> @ineiti Shouldn't #108 be merged and released first so there is a `nextcloud:33-fpm` recipe version before the upgrade to 34?
I prefer to release first the update to the major version, in case something goes wrong, and it's better to do one more patch/minor upgrade on the previous version.
But the `MAINTENANCE.md` file tells otherwise: BEFORE major upgrade, do a `nextcloud:xx-fpm`... Will do that for the 34-35 then...
I prefer to release first the update to the major version, in case something goes wrong, and it's better to do one more patch/minor upgrade on the previous version.
Can you elaborate on this in more detail? Our current release 33.0.9 is already the latest nextcloud 33 version.
So you would release version 34 and then do one more patch/minor upgrade on version 33 in an extra branch?
This PR is already merged, but as there is no release yet, it would be simple to revert this PR, merge #108 first, release it and then release this version 34.
> I prefer to release first the update to the major version, in case something goes wrong, and it's better to do one more patch/minor upgrade on the previous version.
Can you elaborate on this in more detail? Our current release `33.0.9` is already the latest nextcloud 33 version.
So you would release version 34 and then do one more patch/minor upgrade on version 33 in an extra branch?
This PR is already merged, but as there is no release yet, it would be simple to revert this PR, merge #108 first, release it and then release this version 34.
Can you elaborate on this in more detail? Our current release 33.0.9 is already the latest nextcloud 33 version.
So you would release version 34 and then do one more patch/minor upgrade on version 33 in an extra branch?
If somebody doesn't want to move to the next major version, they can use the "floating" version "33" and update easily manually. Once they're ready to do the jump, they'll go to 34.
This PR is already merged, but as there is no release yet, it would be simple to revert this PR, merge #108 first, release it and then release this version 34.
I'm again stuck with abra not being able to create the release - I had the problem already one month ago, something to do with my ssh keys and abra and ssh not agreeing of which key to use. Unfortunately I didn't have the time to look into it.
Your suggestion makes sense. However, #108 is a bit outdated in the meantime, I'll have to update it.
> Can you elaborate on this in more detail? Our current release `33.0.9` is already the latest nextcloud 33 version.
> So you would release version 34 and then do one more patch/minor upgrade on version 33 in an extra branch?
If somebody doesn't want to move to the next major version, they can use the "floating" version "33" and update easily manually. Once they're ready to do the jump, they'll go to 34.
> This PR is already merged, but as there is no release yet, it would be simple to revert this PR, merge #108 first, release it and then release this version 34.
I'm again stuck with abra not being able to create the release - I had the problem already one month ago, something to do with my ssh keys and abra and ssh not agreeing of which key to use. Unfortunately I didn't have the time to look into it.
Your suggestion makes sense. However, #108 is a bit outdated in the meantime, I'll have to update it.
I prefer to release first the update to the major version
with this you mean Version nextcloud:33-fpm and not the next major version 34?
If you rebase and merge #108 in the next hours I could do the release. Later I'm on holidays for two weeks. Maybe someone else could do the release then.
Further I would recommend not to update postgres in #108 in the same step. For postgres major updates I recommend extra releases.
Ah ok, I think I misunderstood you
> I prefer to release first the update to the major version
with this you mean Version `nextcloud:33-fpm` and not the next major version 34?
If you rebase and merge #108 in the next hours I could do the release. Later I'm on holidays for two weeks. Maybe someone else could do the release then.
Further I would recommend not to update postgres in #108 in the same step. For postgres major updates I recommend extra releases.
You understood me correctly, but I changed my mind mid-comment after reading MAINTENANCE.md, sorry...
If you rebase and merge #108 in the next hours I could do the release. Later I'm on holidays for two weeks. Maybe someone else could do the release then.
I should be able to do it, but I have some ssh-key mess I need to sort out. I hope I have time this evening.
Further I would recommend not to update postgres in #108 in the same step. For postgres major updates I recommend extra releases.
Yes, I think we agreed on that. The current postgres update is still waiting because nobody tested it, and I'm not using it. #108 is closed, I'll create a new one.
> Ah ok, I think I misunderstood you
You understood me correctly, but I changed my mind mid-comment after reading MAINTENANCE.md, sorry...
> If you rebase and merge #108 in the next hours I could do the release. Later I'm on holidays for two weeks. Maybe someone else could do the release then.
I should be able to do it, but I have some ssh-key mess I need to sort out. I hope I have time this evening.
> Further I would recommend not to update postgres in #108 in the same step. For postgres major updates I recommend extra releases.
Yes, I think we agreed on that. The current postgres update is still waiting because nobody tested it, and I'm not using it. #108 is closed, I'll create a new one.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
This release adds the configuration and documentation to use Euro-Office for nextcloud.
As per the MAINTENANCE.md file, it must be installed by at least two maintainers.
#LLM_enabled
WIP: Moving to latest nextcloud 34 releaseto WIP: Moving to latest nextcloud 35 releaseWIP: Moving to latest nextcloud 35 releaseto WIP: Moving to latest nextcloud 34 release2bd5cbaf22to41eb0711c535.0.1 is already out!
@dannygroenewegen @moritz @javielico @carla @simon if you have some time to test this, so I can go and prepare the PR for version 35!
For the next one, it would be better to have separate PRs for something like adding eurooffice and upgrading nextcloud. So they can be reviewed and merged seperatly.
It's on my list to test v34, but currently focusing on other things so might take a bit.
If it is easier for you to test, I can make two PRs. As we're already one major version behind, I didn't want to have to bug people too often :)
I started our pipeline on this PR to test v34: https://drone.cicd.local-it.cloud/local-it/kolli-config/1280 but I haven't enabled euro-office yet. I will test this later.
I tested the nextcloud update to version 34 and it works and nothing breaks so far.
I haven't tested the onlyoffice integration, but I think it's safe enough to merge it. If someone finds any issues with the onlyoffice integration a new fixing PR could be created.
41eb0711c5to9d25f7ee3cGreat that this appears to work!
@ineiti Shouldn't #108 be merged and released first so there is a
nextcloud:33-fpmrecipe version before the upgrade to 34?I prefer to release first the update to the major version, in case something goes wrong, and it's better to do one more patch/minor upgrade on the previous version.
But the
MAINTENANCE.mdfile tells otherwise: BEFORE major upgrade, do anextcloud:xx-fpm... Will do that for the 34-35 then...Can you elaborate on this in more detail? Our current release
33.0.9is already the latest nextcloud 33 version.So you would release version 34 and then do one more patch/minor upgrade on version 33 in an extra branch?
This PR is already merged, but as there is no release yet, it would be simple to revert this PR, merge #108 first, release it and then release this version 34.
If somebody doesn't want to move to the next major version, they can use the "floating" version "33" and update easily manually. Once they're ready to do the jump, they'll go to 34.
I'm again stuck with abra not being able to create the release - I had the problem already one month ago, something to do with my ssh keys and abra and ssh not agreeing of which key to use. Unfortunately I didn't have the time to look into it.
Your suggestion makes sense. However, #108 is a bit outdated in the meantime, I'll have to update it.
Ah ok, I think I misunderstood you
with this you mean Version
nextcloud:33-fpmand not the next major version 34?If you rebase and merge #108 in the next hours I could do the release. Later I'm on holidays for two weeks. Maybe someone else could do the release then.
Further I would recommend not to update postgres in #108 in the same step. For postgres major updates I recommend extra releases.
You understood me correctly, but I changed my mind mid-comment after reading MAINTENANCE.md, sorry...
I should be able to do it, but I have some ssh-key mess I need to sort out. I hope I have time this evening.
Yes, I think we agreed on that. The current postgres update is still waiting because nobody tested it, and I'm not using it. #108 is closed, I'll create a new one.