Meta: DSM7 package status

hgy59 commented 3 years ago

Overview of the status of packages for DSM7

Successfull build/install/run is tested with x64 only (unless otherwise stated).

As of may 2021 all pure CLI packages are ready to be published for DSM7. Please regard DSM7 packages still as beta. The synocommunity package repository does not support beta packages per TCVERSION so it is not possible to mark packages as beta for DSM7 only. Packages that other packages depend on are distingueshed in bold. Those should be published as early as possible.

PACKAGE	Build	Install	Run	Data Folders ⁸⁾	Published	COMMENT
adminer	✔️	✔️	✔️		✔️	⁷⁾, noarch, #4514, finallized with #5160, but issue #5191
beets	✔️	✔️	✔️		✔️
bicbucstriim	✔️	✔️	✔️		✔️	#5952
borgbackup	✔️	✔️	✔️		✔️	#4710
boxbackup-client	✔️				⛔	¹⁾
chromaprint	✔️	✔️	✔️		✔️	#4545, #4692
comskip	✔️	✔️	✔️		✔️	#4545, #4692
cops	✔️	✔️	✔️		✔️	^{2, 7)}, noarch #5192
couchpotatoserver	✔️					⁴⁾, noarch
couchpotatoserver-custom	✔️					noarch
curaengine	✔️					¹⁾
dante-sockd	✔️				⛔	#4898, #5006
darkstat	✔️				⛔	requires root to capture network trafic
debian-chroot	❌️
deluge	✔️	✔️	✔️		✔️	⁶⁾, #4429, #4695, #5398
demoservice	✔️					⁶⁾, noarch
dnscrypt-proxy	✔️					³⁾
domoticz	✔️	✔️	✔️		✔️	#4674
duplicity	✔️	✔️	✔️		✔️	#3823
ejabberd	✔️	✔️	✔️	~target/etc/ejabberd/~ target/var/lib/ejabberd/	✔️	#4333, #4959
erlang	✔️	✔️	✔️		✔️
fengoffice	✔️					²⁾
ffmpeg	✔️	✔️	✔️		✔️	#4545, #4576, #4692
ffsync	✔️	✔️	✔️		✔️	#5942
fish	✔️	✔️	✔️		✔️
fishnet	✔️	✔️	✔️
flexget	✔️	✔️	✔️		✔️	#4603, #4657
fossil-scm	✔️	✔️	✔️		✔️	#4915
full-text-rss	✔️					¹⁾, noarch
gateone	✔️				⛔	noarch
gentoo-chroot	❌️			target/etc
git	✔️	✔️	✔️		✔️	#4597
~git-server~	✔️					^3,7), ⁵⁾, git, noarch, package removed, use gitea instead
gnupg	✔️	✔️	✔️		✔️	#4599
haproxy	✔️				⛔	³⁾
~~hassio~~	✔️					Package removed
he853	✔️				⚙️	needs root to activate udev rules
headphones	✔️	✔️	✔️		✔️	⁴⁾, noarch, WIP #5488
headphones-custom	✔️					noarch
homeassistant	✔️	✔️	✔️		✔️	#4580
horde	✔️					²⁾, noarch
htpcmanager	✔️					³⁾, noarch
icecast	✔️	✔️	✔️		✔️	#4628
imagemagick	✔️	✔️	✔️		✔️	#4585
inotify-tools	✔️	✔️	✔️		✔️	#4644
irssi	✔️			target/etc		¹⁾
itools	✔️				⚙️	³⁾, #4985
jackett	✔️	✔️	✔️		✔️	.net version only, mono is not supported (yet)
jappix	✔️					¹⁾, noarch
jellyfin	✔️	✔️	✔️		✔️	⁵⁾, ffmpeg #3932
~jupp~	✔️					¹⁾, package removed, integrated into synocli-file
lazylibrarian	✔️	✔️	✔️			noarch
lidarr	✔️	✔️	✔️		✔️	⁵⁾, ~mono~, chromaprint #5485
lirc	❌️			target/etc		Mandatory requires kernel sources and they are not available for DSM7
lua	✔️	✔️	✔️		✔️	#4596
mantisbt	✔️					²⁾, noarch
maraschino	✔️					³⁾, noarch
mediainfo	✔️	✔️	✔️		✔️	#4762
memcached	✔️	✔️	✔️		✔️	³⁾ #4522
mercurial	✔️	✔️	✔️		✔️	^1,5), #4591
minio	✔️	✔️	✔️		✔️	^{6, 9, 10)}, #4683
mkvtoolnix	✔️	✔️	✔️		✔️	#4622
monit	✔️	✔️	✔️		✔️	#4827
monitoring-plugins	✔️	✔️	✔️		✔️	#5082
mono	✔️	✔️	✔️		✔️	(#4669) - avoid mono for DSM7, migrate related packages to dotnet instead #3715 https://github.com/SynoCommunity/spksrc/pull/4669#issuecomment-881737801
mosh	✔️	✔️	✔️		✔️	#4667
mosquitto	✔️	✔️	✔️		✔️
mtproxy	✔️					#4725
mutt	✔️	✔️	✔️		✔️	#4922
mylar	✔️					noarch
node-exporter	✔️	✔️	✔️		✔️	#5207
nodejs	❌️				✔️	#5037, DSM 7 only
ntopng	✔️				⛔	^3,5), redis
nzbget	✔️	✔️	✔️	target/share	✔️	⁶⁾, #4996
~nzbget-testing~					package removed
nzbhydra	✔️					noarch
nzbmegasearch	✔️					³⁾
octoprint	✔️	✔️	✔️		✔️ ⚙️	³⁾ this might have issues with serial devices
owncloud	✔️	✔️	✔️		✔️	#5619
plexivity	✔️					³⁾, noarch
plexpy-custom	✔️					noarch
plowshare	✔️
ps3netsrv	✔️	✔️	✔️		✔️	⁶⁾, #4984
pyload	✔️	✔️	✔️
python2	✔️	✔️	✔️			¹¹⁾, ~dependent packages should use python 2.7.18 of DSM7~
python3	✔️	✔️	✔️		✔️
python38	✔️	✔️	✔️		✔️
rabbitmq	✔️	✔️	✔️		✔️	⁵⁾, erlang
radarr	✔️	✔️	✔️		✔️	finally fixed with #5268
rdiff-backup	✔️
redis	✔️	✔️	✔️		✔️	#4727
roundcube	✔️					²⁾, noarch
rsnapshot	✔️	✔️	✔️		✔️	noarch, #5019
ruby	✔️	✔️	✔️		✔️	#4715
rutorrent	✔️	✔️	✔️		✔️	^{6, 7)} #4695, #5617
sabnzbd	✔️	✔️	✔️		✔️	⁶⁾
salt-master	✔️	✔️	✔️		✔️	#5017, #5145
salt-minion	✔️	✔️	✔️		✔️	#5017, #5145
saltpad	✔️					^3,5), salt-master
selfoss	✔️	✔️	✔️		✔️	#5916
shairport-sync	✔️
sickbeard-custom	✔️					noarch
sickchill	✔️	✔️	✔️		✔️	¹⁾, #4703, #4964
sickrage	✔️					noarch
sonarr	✔️	✔️	✔️		✔️	https://github.com/SynoCommunity/spksrc/issues/4706#issuecomment-881783371
squidguard	✔️			target/etc		#4695
sslh	✔️	✔️	✔️		✔️	⁹⁾, #4742
stockfish	✔️	✔️	✔️
stunnel	✔️	✔️	✔️		✔️	#4828
subliminal	✔️					³⁾
syncthing	✔️	✔️	✔️		✔️	#4527
synocli-disk	✔️	✔️	✔️		✔️	#4694
synocli-file	✔️	✔️	✔️		✔️	#4616
synocli-monitor	✔️	✔️	✔️		✔️	#4694
synocli-net	✔️	✔️	✔️		✔️	#4643
syno-magnet	✔️	✔️	✔️		✔️	noarch
tcl	✔️	✔️	✔️		✔️	#4577
transmission	✔️	✔️	✔️		✔️	⁶⁾, #4313
tt-rss	✔️	✔️	✔️		✔️	²⁾, #4840, #4630, #4923
tvheadend	✔️	✔️	✔️		✔️	#4545, #4686, #4692
umurmur	✔️	✔️	✔️		✔️	#4990
vim	✔️	✔️	✔️		✔️
wallabag	✔️	✔️	✔️			`dsm7-packages` branch
znc	✔️	✔️	✔️		✔️	#4602
zsh	✔️	✔️	✔️		✔️
zsh-static	✔️	✔️	✔️		✔️

Remarks: ¹⁾ Avoid link and usage of /usr/local/{package-name} ²⁾ Migrate mysql to mariadb-10 ³⁾ Does not install due to required root privilege ⁴⁾ Installer uses unsupported function like set_unix_permissions, syno_remove_user, syno_group_create, syno_group_remove, syno_user_add_to_group, set_syno_permissions, syno_user_add_to_legacy_group ⁵⁾ Requires a dependent package that might not be published yet. ⁶⁾ SERVICE_WIZARD_SHARE is not supported for DSM7. Shared folders must be declared in resources and must be the name of the share (without volume). ⁷⁾ Packages that integrate into WebStation (web apps, web services) must register via WebStation webapi or use a Package Worker. ⁸⁾ target/var is not listed here, as migration is already implemented in current installer. ⁹⁾ Invalid version number. DSM7 validates $(SPK_VERS)-$(SPK_REV) with regex [^\d+(\.\d+){0,5}(-\d+)?$]. So only digits and dots are allowed in SPK_VERS. ¹⁰⁾ SERVICE_EXE needs migration to SERVICE_COMMAND. ¹¹⁾ As Python2 of DSM 7 comes neigther with pip nor virtualenv it looks like we have to deploy python2 for DSM 7 (at least for the single package ffsync that will never be ported to Python 3 as it is about to be migrated to Rust).

⛔ Packages that require root privilege to run will not be compatible with DSM7. ⌛ Packages that need root previlege for installation will not be compatible until synology allows permission settings for specific installation steps. ⚙️ Packages that need access to USB devices. synology might drop support for USB devices.

publicarray commented 3 years ago

I like the idea of a SynoCommunity shared folder, however migrating data from DSM6 is might be hard. I think I would prefer the user to mange their own files and permissions, we can guide them. The positives of this approach is that it eases maintenance significantly. It also means that users can organise their folder how they want. And Less magic/code to migrate if Synology releases a DSM8. Just my 2c

Edit: I've updated the permission wiki with DSM7 screenshots

BenjV commented 3 years ago

Regardless whether or not a SynoCommunity share is implemented, it would be a good idea to use common group for all SynoCommunity packages by adding this groupname to the privilege file of all packages.

bluet commented 3 years ago

In the table it says borgbackup can Build, Install, and Run on DSM7, but it seems failed in my test. #4709

hgy59 commented 3 years ago

In the table it says borgbackup can Build, Install, and Run on DSM7, but it seems failed in my test. #4709

The table says that borgbackup is not published to the synocommunity package repository. So you must build this package yourself and install manually in the DSM package center of your Diskstation.

There are different reasons that a package is not published yet. Most are mentioned in the comment column, but others are not, like: package upgrade is not updated for DSM7.

BenjV commented 3 years ago

@publicarray You wrote a nice wiki on permissions, but some of that is no longer valid for DSM 7. Packages cannnot execute any command that needs root privs anymore on DSM 7, so things like creating or adding users to the group sc-download does not function anymore. Adding the "system internal user" of a package to a group like sc-download is not possible anymore on DSM 7. So maybe add some comment that this Concepts is only valid for DSM 6.

Also I would suggest to add a statement that when using existing shares/ folders or files permissions to the "system internal user" this must be set recursively and not only on the top share or folder.

By the way, if all packages would be created (via the privilege file) in the same group then we can mimic the behavior of the old sc-download group, because all package would then belong to that group.

publicarray commented 3 years ago

@BenjV I think @ymartin59 wrote those a while ago, I've only updated some of the DSM7 part, there are many things that still need to be updated. This just was one I thought needed it most since we link to it in the wizard. AFAIK anyone can contribute, edit and improve the wiki. I'll look at updating the wiki further when I'm able.

By the way, if all packages would be created (via the privilege file) in the same group then we can mimic the behavior of the old sc-download group, because all package would then belong to that group.

I don't think it works, last time I played with it the implantation seemed incomplete or partly broken. Or maybe I just did not understand how they were meant to be used. Any group name is not visible to the user, so I don't see any benefit here. The only potential use I found is that you can read/write files from another package with the same group. Another problem is that if you called the group sc-download in the privilege file it will be renamed if the group already exits in the user interface. So there is no migration path.

If wizards are really going to go without an official alternative I think there are 4 ways to work without them.

Provide sensible defaults for packages and let the user change setting from the package interface themselves. (Transmission etc. could work well here)
- Most secure, easy for maintainers, not beginner friendly,
- some packages don't have an interface so SSH is the only other way to change config files. We would need to make users aware of the configuration file locations. (e.g. HASS.io)
Create a package that has the permissions to edit any other package file from SynoCommunity (I attempted something like this before: SynoEdit) I might revisit this if there is interest.
- Less secure, need to setup the permissions for every package. More user-friendly, but more work for maintainers
- 2 ways the editor can work,
  1. With a file allow list which we would need to constantly maintain.
  2. Or just any file on the system (would need to implement a file browser) which could also allow a user to break things
Create a shared SynoCommunity folder where package config files can go and use Synology's build in text editor.
- Less secure, more initial work for maintainers,
- Some packages might not like to have the config files in non-standard locations.
  1. Any better option you can think of :bulb:

BenjV commented 3 years ago

In the past you could not use the same group for different packages, if you did the packagecenter added a random number to it. When Synology release Dsm 6, I asked their developers to change this a they said they would consider it in future release and now it is corrected. I tested this and it functions fine on Dsm 7.

The user can use this group in the permission viewer and in the advanced permission settings.

The most benefit would be that all packages would belong to the same group and could read/write each others files if they have group permissions. This can replace the current functionality create with the current sc-download group.

And as you said, using sc-download is not possible, so I would propose to use the groupname "synocommunity".

The wizard is gone from the documentation, but still functions as before, so lets just use it as long as it is there. Synology themselves are also still using it in their packages.

mirceadamian commented 3 years ago

On the zsh and zsh-static packages I do not see anything in the COMMENT column. I was wondering if they are being also looked at for the DSM7 package format (same problem as others are reporting on other packages that the installer is complaining about the format).

I've just pulled the trigger on the DSM7.0 and I was probably a bit too early and realized that a dozen of my scripts are not working anymore because zsh is not working :-)

hgy59 commented 3 years ago

On the zsh and zsh-static packages I do not see anything in the COMMENT column. I was wondering if they are being also looked at for the DSM7 package format (same problem as others are reporting on other packages that the installer is complaining about the format).

@mirceadamian, all (stateless) CLI packages are expected to run with DSM 7. These must be built for DSM 7 only. I've just published zsh and zsh with modules for DSM 7. These have the same Version as the latest DSM6 packages (v5.8-11 and v5.8-7) and are ready for manual download. It will take up to 48 hours until those are available for Installation with the DSM integrated package manager (until then, you still get the non installabel DSM 6 version).

mirceadamian commented 3 years ago

It was working but I was trying to cleanup the repair list and accidentally uninstalled it. I will manually download it.

publicarray commented 3 years ago

@BenjV I've updated the wiki please let me know if this is accurate. The groups you are talking about won't be available to select in the GUI anymore, so it doesn't make managing permissions any easier for the end user.

The wizard is gone from the documentation, but still functions as before, so lets just use it as long as it is there. Synology themselves are also still using it in their packages

Agree 100%, but I think it's worth exploring other options just in case.

BenjV commented 3 years ago

@publicarray With setting the same group for all packages, it makes it possible to share data between packages without the end-users involvement, that would be the purpose. If you have for example a package like SickChill that search for torrents and use the Transmission package for the download, during installation the package could create a share for that and via the group settings they can share the files. Package builders don't need to use this, but if we choose to use the same group, this option is available. If we leave is as is, then for every package DSM will create it's own (useless) group.

Regarding the wiki: When users migrate from DSM 6 to DSM 7 and the need to give access to another package user, then granting that "system internal user" access to that share is not enough if there already are existing folders and/or files present. The privs of those will not change. That has to be done with FileStation, by creating permissions for the "system Internal user", and thick the box "apply to this folder, sub-folders and files.

Maybe you could add that advice to the wiki?

By the way DSM 7 defined and create several new locations for files (see page 76, FHS of the development manual). DSM does not clean-up those folders after uninstalling the a package. I would suggest to add cleaning up of those folder in the post-uninstall phase of all packages to keep the system clean. Something like this:

rm -fr "${SYNOPKG_PKGVAR}"
rm -fr "${SYNOPKG_PKGHOME}"
rm -fr "${SYNOPKG_PKGDEST_VOL}/@appconf/${SYNOPKG_PKGNAME}"

publicarray commented 3 years ago

With setting the same group for all packages, it makes it possible to share data between packages without the end-users involvement, that would be the purpose. If you have for example a package like SickChill that search for torrents and use the Transmission package for the download, during installation the package could create a share for that and via the group settings they can share the files.

yes, but not shared folders, they behave differently: you would have to add every package username

"data-share": {
    "shares": [{
    "name": "<share-name>",
    "permission": {
        "ro": ["<user-name>", ...],
        "rw": ["<user-name>", ...]
    },
    "once": "<once>"
        }
, ...]
}

ls -l /volume1/downloads/somefile.txt
-rwx------+ 1 sc-transmission sc-transmission 

group of the package was `synocommunity`

Please test your ideas first.

Regarding the wiki:

Yea thanks, I agree the wiki can be made more clear.

DSM does not clean-up those folders after uninstalling the a package.

We already have a new uninstall wizard that takes care of this.

BenjV commented 3 years ago

Not clear what you mean with "test your ideas first". I did test it. Seems to me that you tested with the wrong privilege file.

If you add in the privilege file the groupname "synocommunity" then everything the package creates wiil have "synocommunity" as group, only if you don't add a groupnane Dsm will create a group with the package name and currently the framework uses sc-***** as username and also as groupname in the privilege file See my ealier post abiut this. https://github.com/SynoCommunity/spksrc/issues/4524#issuecomment-869634575

publicarray commented 3 years ago

If you have for example a package like SickChill that search for torrents and use the Transmission package for the download, during installation the package could create a share for that and via the group settings they can share the files.

This use case works when both packages use the same shared folder and have correct permissions. With the DSM7 transmission package (#4719) this works by using a wizard. No groups needed. I probably don't understand what you are after.

seby@DSM7:/$ sudo synogroup --get synocommunity
Group Name: [synocommunity]
Group Type: [AUTH_LOCAL]
Group ID:   [207066]
Group Members: 
0:[sc-transmission]
1:[synoedit]
seby@DSM7:/$ ls -lh /volume1/downloads/ubuntu-21.04-desktop-amd64.iso.part
-rwxrwxrwx+ 1 sc-transmission sc-transmission 2.7G Jul  9 10:15 /volume1/downloads/ubuntu-21.04-desktop-amd64.iso.part

~~not sure why the permissions changed to rwxrwxrwx~~

seby@DSM7:/$ sudo su
Password: 
ash-4.4#  ls -lh /volume1/downloads/ubuntu-21.04-desktop-amd64.iso.part
-rwx------+ 1 sc-transmission sc-transmission 2.7G Jul  9 10:36 /volume1/downloads/ubuntu-21.04-desktop-amd64.iso.part

:thinking:

What you are saying about groups is true for files not in shared folders.

ls -l /var/packages/transmission/var/settings.json
-rw------- 1 sc-transmission synocommunity 2321 Jul  9 10:54 /var/packages/transmission/var/settings.json

So how I really don't see how that would help....

FYI: To set a group in the permission file just set the SPK_GROUP variable in a Makefile. (after #4721 is merged to fix a bug)

Thanks for the link to your comment (It got lost to me in this long thread). I did this stuff ages ago too and did the transmission package but for some reason it didn't get merged from the dsm7-packages branch, hence the new PR.

BenjV commented 3 years ago

Files created in folders get the permission of the parent. So if you create a shared folder in resource files and create subfolder there with the correct permissions then all files and folder created there gets the correct permissions. Those subfolder must be created by the package of package group. If you do it as in my example(https://github.com/SynoCommunity/spksrc/issues/4524#issuecomment-869634575), everything will function fine. I tested it extensively.

And I propose not to set the group via the SPK_GROUP but to force it for all packages to "synocommunity", that is the only reliable way else we get a possible mixture of all kind of groups. Remember the whole Linux group idea is to share groups, not to create a separate group for every package user.

piotrtobolski commented 3 years ago

MediaInfo can be marked as not compatible. Version 20.08-11 doesn't repair or install on DSM 7.0-41890 showing error about invalid file format.

Mosquitto 1.6.15-12 failed to launch after repair. Uninstalled (erased config), installed again and works like a charm.

hgy59 commented 3 years ago

MediaInfo can be marked as not compatible. Version 20.08-11 doesn't repair or install on DSM 7.0-41890 showing error about invalid file format.

All packages that are not marked as published in the table above are not yet available for DSM7.

volo-zyko commented 3 years ago

What about mc (Midnight Commander) port to DSM7? I don't see it in the table above. Is it abandoned? Or are there technical issues with the port (I don't see related separate issues either)?

hgy59 commented 3 years ago

mc is part of synocli-file package and thus available for DSM 7. There is no dedicated mc package anymore (but you could build one by your self with diyspk/mc).

eddie8de commented 3 years ago

I do know that rsnapshot is still red, yet it is working with DSM7 (at least with intel x64): I had installed it before the update to DSM7, the package manager also still says rsnapshot has to be repaired. Yet it is working nicely every day. Anyway, I hope an update will be made some day for first installations.

larieu commented 3 years ago

I am not able to find info about Medio

https://bitbucket.org/polandj/medio/src/master/

it was a helpful piece of software - it needs Python ( apparently not compatible with DSM 7 ) is it any reason to not be listed here?

daxcore commented 3 years ago

i'm waiting for the port of umurmur. is there any reason, why it is not adapted?

Safihre commented 3 years ago

i'm waiting for the port of umurmur. is there any reason, why it is not adapted?

Because SynoCommunity is run by volunteers that have to do this next to their regular jobs and life, so to implement the changes Synology requires takes time since (almost) each package needs to be manually updated.

mesquitafmr commented 2 years ago

Hey everyone. Is there any news about #4429 ? Thanks!

Tjadevisser commented 2 years ago

Will there be packages for Radarr and Jackett that are compatible with the EVANSPORT Architecture (DS214 Play)?

Alexeyrz commented 2 years ago

Please make the ps3netsrv package compatible with DSM 7.

publicarray commented 2 years ago

Will there be packages for Radarr and Jackett that are compatible with the EVANSPORT Architecture (DS214 Play)?

No, the 32-bit (x86) architecture is not supported by .NET on Linux and mono builds will be phased out anyway, at least there are no new builds for Radarr. Maybe if someone wants to spend some time on it and push a PR or when .NET decides it wants to support 32 bit on Linux

AnotherSoul commented 2 years ago

Just a short message to say that I tried to upgrade the tt-rss package to MariaDB 10 and then DSM 7. The migration to MariaDB 10 worked well, but upgrading DSM to 7 broke the package. I recompiled it directly for DSM 7 and the new version was not working at all (I assume there are privileges issues). In the end, I manually installed tt-rss to /var/services/web. I needed a few changes (especially to be able to run the rss feeds auto-update ; there's a call to the php cli from within the scripts and the PHP_EXECUTABLE const must be modified in /classes/config.php to fit the dedicated php73 cli binary) but it is working well now. The thing is that tt-rss doesn't support officially anymore such installations. They now provide a Docker image and it's the only official way to use tt-rss (data must be migrated from MariaDB to Postgre, that's why I did not make it, but there is a procedure for that), so I guess that this package will (should ?) be dropped off from SynoCommunity.

hgy59 commented 2 years ago

@LeBlondTenebreux there is already @smaarn working on this (see #4840 and #4630 )

th0ma7 commented 2 years ago

Merging #4695 would add 4x new "build" check-marks that now builds on DSM7, namely deluge, ffsync, rutorrent and squidguard. Afterwards I'll look into getting the remaining ones to build on DSM7 ...

itsme9x commented 2 years ago

sickchill works fine now.

BKSteve commented 2 years ago

@hgy59 grateful if you could update the table now that SickChill can install and run on DSM7.

McEnnes commented 2 years ago

I do not understand the status of nzbget. Is it not possible to develop this for DSM 7? Is there a workaround, besides running the package in Docker?

timrettop commented 2 years ago

@McEnnes I'm certainly keenly interested in this as well. Without hearing from someone more knowledgeful, I only guessed that it was related to the way it had to be installed on DSM6 (via command line). The remarks for the package status indicate SERVICE_WIZARD_SHARE is not supported, but I don't know if that means PRs upstream or just work for the Synocommunity. People with docker capabilities don't have any qualms, but lowly little people like us just have to wait :) I do appreciate all the work on the rest of the repo, this (and less so headphones) are the only components that's keeping me from upgrading.

publicarray commented 2 years ago

Hi @McEnnes, @timrettop is mostly right. Packages are slowly being updated to include DSM7 support with limited resources this can take some time. Some technical details: Indeed SERVICE_WIZARD_SHARE has given us some trouble. We did add support to DSM7 but We had reports where it doesn't always work. Basically when the share already exist and was initially created with an older version (unknown what specific settings/dsm version causes this) then it could fail. As it turns out Synology had a different implementation for shared folders or ACL permissions and the new API/worker in DSM7 can't work with it. The solution so far is to recreate them in DSM7.

McEnnes commented 2 years ago

Hi @publicarray, @timrettop , thanks for the updates, i appreciate this! Keep up the good work guys!

AlphaMWB commented 2 years ago

Literally, I would throw some money to someone who will complete the NZBGet process. It has value enough to me.

Libre12 commented 2 years ago

Any update on supporting dnscrypt-proxy on DSM 7?

hgy59 commented 2 years ago

Any update on supporting dnscrypt-proxy on DSM 7?

dnscrypt-proxy will need a new approach for DSM 7 as it is not possible to serve privileged ports (53) without root access.

publicarray commented 2 years ago

Any update on supporting dnscrypt-proxy on DSM 7?

dnscrypt-proxy will need a new approach for DSM 7 as it is not possible to serve privileged ports (53) without root access.

Yes I've started doing this and have created a beta release here: https://github.com/publicarray/spksrc/releases/tag/dnscrypt-proxy-2.0.45_1

eddie8de commented 2 years ago

I am a bit surprised, that rsnapshot is still open: I thought this in my opinion best backup solution would be used by some more people. The binaries from the DSM6 package are still working under DSM7, so for me it looks like the issue is only the package itself, which has to be reworked?

hgy59 commented 2 years ago

I am a bit surprised, that rsnapshot is still open: I thought this in my opinion best backup solution would be used by some more people. The binaries from the DSM6 package are still working under DSM7, so for me it looks like the issue is only the package itself, which has to be reworked?

@eddie8de you're right, rsnapshot is not a big deal to update for DSM 7. Can't remember what the reason was to mark does not build in the table above. This is now WIP in #5019. I would like to move the config file from etc to var folder to benefit of the backup/restore automatism in our framework. If you don't object?

eddie8de commented 2 years ago

@eddie8de you're right, rsnapshot is not a big deal to update for DSM 7. Can't remember what the reason was to mark does not build in the table above. This is now WIP in #5019. I would like to move the config file from etc to var folder to benefit of the backup/restore automatism in our framework. If you don't object?

Thank you so much for the fast reply. If somewhere in early 2022 an installation would be possible, it would safe me lot of time, cause I want to set up two new NAS with rsnapshot. For me, I do not mind where the config file is located, and I cannot think of a reason why other people could bother.

Dragoniacs16 commented 2 years ago

Hi community! Can anyone have time to publish new package update in synocommunity ? https://packages.synocommunity.com/

publicarray commented 2 years ago

Hi community!

Can anyone have time to publish new package update in synocommunity ?

https://packages.synocommunity.com/

Can be more specific? What package do you require?

Dragoniacs16 commented 2 years ago

My HomeAssistant is still in version 2021.9.7 I have a DS218play (no docker), so I only use synocommunity system to update it Thanks for support ☺️

hgy59 commented 2 years ago

@Dragoniacs16 in #4969 I gave some hints why it will take some time for the next updated homeassistant package. Currently I tend to say: do not expect more than two updates / year.

Dragoniacs16 commented 2 years ago

Ok, no problem, I'll wait. Thanks for not forgetting syno package users 😁

mietzen commented 2 years ago

Is there an overview which packages are ready for DSM 7.1 ? I'm afraid my Setup beaks after updating to DSM 7.1. I'm running all SynoCLI, Python 3.10, zsh and git.

Edit: I’ve successfully upgrade to 7.1 without any problems.

SynoCommunity / spksrc

Meta: DSM7 package status #4524