Meta: DSM7 package status

[hgy59]

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 8)	Published	COMMENT
adminer	✔️	✔️	✔️		✔️	7), noarch, #4514, finallized with #5160, but issue #5191
beets	✔️	✔️	✔️		✔️
bicbucstriim	✔️	✔️	✔️		✔️	1, 7), noarch, #5952
borgbackup	✔️	✔️	✔️		✔️	#4710
boxbackup-client	✔️				⛔	1)
chromaprint	✔️	✔️	✔️		✔️	#4545, #4692
comskip	✔️	✔️	✔️		✔️	#4545, #4692
cops	✔️	✔️	✔️		✔️	2, 7), noarch #5192
couchpotatoserver	✔️					4), noarch
couchpotatoserver-custom	✔️					noarch
curaengine	✔️					1)
dante-sockd	✔️				⛔	#4898, #5006
darkstat	✔️				⛔	requires root to capture network trafic
debian-chroot	❌️
deluge	✔️	✔️	✔️		✔️	6), #4429, #4695, #5398
demoservice	✔️					6), noarch
dnscrypt-proxy	✔️					3)
domoticz	✔️	✔️	✔️		✔️	#4674
duplicity	✔️	✔️	✔️		✔️	#3823
ejabberd	✔️	✔️	✔️	~target/etc/ejabberd/~ target/var/lib/ejabberd/	✔️	#4333, #4959
erlang	✔️	✔️	✔️		✔️
fengoffice	✔️	✔️	✔️		✔️	2), #5992
ffmpeg	✔️	✔️	✔️		✔️	#4545, #4576, #4692
ffsync	✔️	✔️	✔️		✔️	#5942
fish	✔️	✔️	✔️		✔️
fishnet	✔️	✔️	✔️
flexget	✔️	✔️	✔️		✔️	#4603, #4657
fossil-scm	✔️	✔️	✔️		✔️	#4915
full-text-rss	✔️					1), noarch
gateone	✔️				⛔	noarch
gentoo-chroot	❌️			target/etc
git	✔️	✔️	✔️		✔️	#4597
~git-server~	✔️					3,7), 5), git, noarch, package removed, use gitea instead
gnupg	✔️	✔️	✔️		✔️	#4599
haproxy	✔️				⛔	3)
~~hassio~~	✔️					Package removed
he853	✔️				⚙️	needs root to activate udev rules
headphones	✔️	✔️	✔️		✔️	4), noarch, #5488
headphones-custom	✔️					noarch
homeassistant	✔️	✔️	✔️		✔️	#4580
horde	✔️					2), noarch
htpcmanager	✔️					3), noarch
icecast	✔️	✔️	✔️		✔️	#4628
imagemagick	✔️	✔️	✔️		✔️	#4585
inotify-tools	✔️	✔️	✔️		✔️	#4644
irssi	✔️	✔️	✔️	target/etc		1) #6863
itools	✔️				⚙️	3), #4985
jackett	✔️	✔️	✔️		✔️	.net version only, mono is not supported (yet)
jappix	✔️					1), noarch
jellyfin	✔️	✔️	✔️		✔️	5), ffmpeg #3932
~jupp~	✔️					1), package removed, integrated into synocli-file
lazylibrarian	✔️	✔️	✔️			noarch
lidarr	✔️	✔️	✔️		✔️	5), ~mono~, chromaprint #5485
lirc	❌️			target/etc		Mandatory requires kernel sources and they are not available for DSM7
lua	✔️	✔️	✔️		✔️	#4596
mantisbt	✔️	✔️	✔️		✔️	2), noarch, #6237
maraschino	✔️					3), noarch
mediainfo	✔️	✔️	✔️		✔️	#4762
memcached	✔️	✔️	✔️		✔️	3), #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	✔️	6), #4996
~nzbget-testing~						package removed
nzbhydra	✔️					noarch
nzbmegasearch	✔️					3)
octoprint	✔️	✔️	✔️		✔️ ⚙️	3) this might have issues with serial devices
owncloud	✔️	✔️	✔️		✔️	2) #5619
plexivity	✔️					3), noarch
plexpy-custom	✔️					noarch
plowshare	✔️					package completly removed with #6246
ps3netsrv	✔️	✔️	✔️		✔️	6), #4984
pyload	✔️	✔️	✔️
python2	✔️	✔️	✔️			11), ~dependent packages should use python 2.7.18 of DSM7~
python3	✔️	✔️	✔️		✔️
python38	✔️	✔️	✔️		✔️
rabbitmq	✔️	✔️	✔️		✔️	5), erlang
radarr	✔️	✔️	✔️		✔️	finally fixed with #5268
rdiff-backup	✔️
redis	✔️	✔️	✔️		✔️	#4727
roundcube	✔️	✔️	✔️		✔️	2), noarch, #6243
rsnapshot	✔️	✔️	✔️		✔️	noarch, #5019
ruby	✔️	✔️	✔️		✔️	#4715
rutorrent	✔️	✔️	✔️		✔️	6, 7) #4695, #5617
sabnzbd	✔️	✔️	✔️		✔️	6)
salt-master	✔️	✔️	✔️		✔️	#5017, #5145
salt-minion	✔️	✔️	✔️		✔️	#5017, #5145
saltpad	✔️					3,5), salt-master
selfoss	✔️	✔️	✔️		✔️	2), #5916
shairport-sync	✔️
sickbeard-custom	✔️					noarch
sickchill	✔️	✔️	✔️		✔️	1), #4703, #4964
sickrage	✔️					noarch
sonarr	✔️	✔️	✔️		✔️	#4706
squidguard	✔️			target/etc		#4695
sslh	✔️	✔️	✔️		✔️	9), #4742
stockfish	✔️	✔️	✔️
stunnel	✔️	✔️	✔️		✔️	#4828
subliminal	✔️					3)
syncthing	✔️	✔️	✔️		✔️	#4527
synocli-disk	✔️	✔️	✔️		✔️	#4694
synocli-file	✔️	✔️	✔️		✔️	#4616
synocli-monitor	✔️	✔️	✔️		✔️	#4694
synocli-net	✔️	✔️	✔️		✔️	#4643
syno-magnet	✔️	✔️	✔️		✔️	noarch
tcl	✔️	✔️	✔️		✔️	#4577
transmission	✔️	✔️	✔️		✔️	6), #4313, #4719, #5956
tt-rss	✔️	✔️	✔️		✔️	2), #4840, #4630, #4923
tvheadend	✔️	✔️	✔️		✔️	#4545, #4686, #4692
umurmur	✔️	✔️	✔️		✔️	#4990
vim	✔️	✔️	✔️		✔️
wallabag	✔️	✔️	✔️		✔️	2), #6232
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.

[Safihre]

@hgy59 Is there an overview of changes I need to make to get DSM7 compatibility for my package (sabnzbd)?

[publicarray]

@Safihre I suggest to start with the Wiki DSM7.0-Beta

For your package you may only need to change ${SYNOPKG_PKGDEST}/var to ${SYNOPKG_PKGVAR} and knowing set_syno_permissions won't be doing anything in DSM 7. Just inspect the log files if there are additional permission errors. Unfortunately I can't test DSM7 stuff for now, as I'm waiting for my replacement unit (possibly something wrong with the power/mobo inside my unit failed.) :cry:

[Safihre]

So how do we handle the permissions?

[publicarray]

Generally you don't. Since you don't have root. DSM will chown the folders for you (using the package name) if you need other folders they need to be given in the resource worker or the user has to add the package from the DSM settings (look for "internal users" category) to a folder.

[Safihre]

Can we maybe update set_syno_permissions to do the service worker stuff?

[publicarray]

Under the DSM 7 restrictions I don't have a clear idea how that would work. Not saying it's impossible but even if done it wouldn't be backwards compatible anyway. If you're willing to contribute sure. But once you read DSM Developer Guide 7 0 Beta in full I think you might reconsider. IMHO the work required (if it's even possible with the new restrictions) to make it work is not worth the time.

I encourage you look at the transmission package. It allows only the user to choose a Shared Folder through the wizard.

The reality is that the NAS now manages the permissions, and packages only get a few selected knobs to play with. The permissions are in the user hands through the file manager and control center as "internal user" (IHMO that's a good thing. So malicious software can't just upload random files to a remote server)

[Safihre]

Sabnzbd also has a wizard already, but I don't quite see from the Transmission example what needs to be changed about it to make it work. Is it something in the name of the variable? I have not really been part of the whole DSM 7 story, so I don't know what's already impmented in the framework. My own NAS can't even run it (old model), so I will admit that I am not very motivated to really dive deep just to update my 1 package. 😕

[DigitalBox98]

On DSM7.0, rabbitmq is failing to start due to incorrect service_postinst(). As indicate in #4539, the installer logs must be redesigned and fixed for DSM7.0 to allow many packages to work again :)

[daxcore]

update/repairing after update to dsm7 of umurmur fails because of

3. Does not install due to required root privilege

[publicarray]

@daxcore This is expected. Did you read our Readme.md? If you where to read the table above then you would see that everything is very much work in progress on the master branch. (no packages are published yet, but you can compile your own).

[hgy59]

@publicarray Thanks for the wiki-page DSM-7.0-Beta.

As we get closer to DSM 7.0, I wonder when we will rename this page (remove the beta). As all the existing links to this page will be broken by a rename, we might better start with a new wiki page for DSM 7.

We could wait for such a page until DSM 7 (final or RC1) is released and document validated facts only.

What would you prefer?

[publicarray]

I propose that relevant stuff in DSM-7.0-Beta is moved/copied to their respective wiki page (Permission Management, Generic Service Support etc.) and that we create a quick DSM7 upgrade guide or a quick dsm7 reference for developers (IMHO the detailed wikis tend to quite long, I think some stuff is repetitive and or It's hard to find a specific thing. It's good to have them tough especially for newcomers but a quick dot-point list like the DSM-7.0-beta is more digestible for a quick lookup, kinda like a cheat sheet. What do you think?

[hgy59]

To give an overview of packages that need additional data migration, I have added the column Data Folder. This is for all folders that need extra data migration (config files). The target/var folder must not be listed here as it is already migrated in the current installer code.

[publicarray]

Maybe we should migrate the target/etc the same way we migrate target/var ?

[hgy59]

Maybe we should start to set os_max_ver (as in #4567) for all DSM<=6 packages to something like os_max_ver=6.999 . Hopefully this will limit the packages shown in DSM7 package center to those that are published for DSM7.

[th0ma7]

@hgy59 perhaps something closer to os_max_ver=6.9-39999. Sadly this field is not well documented in the developer guide (even in previous I found). Will it actually block it from showing in the package center? I guess that could be tested?

That could be quite easy to add to my current PR such as seting from the spksrc.tc-vers.mk file such as:

if ($(word 1,$(subst ., ,$(TC_VERS)),5)
TC_OS_MAX_VER=5.9-6999
else if ($(word 1,$(subst ., ,$(TC_VERS)),6)
TC_OS_MAX_VER=6.9-39999
endif

Then in spksrc.spk.mk change my snipet for:

ifneq ($(strip $(OS_MAX_VER)),)
	@echo os_max_ver=\"$(OS_MAX_VER)\" >> $@
else ifeq ($(strip $(TC_OS_MAX_VER)),)
	@echo os_max_ver=\"$(TC_OS_MAX_VER)\" >> $@
# If require kernel modules then limit
# 'os_max_ver' to point releases only
else ifeq ($(strip $(REQUIRE_KERNEL)),1)
	@echo os_max_ver=\"$(word 1,$(subst ., ,$(TC_VERS))).$(word 2,$(subst ., ,$(TC_VERS)))-$$(expr $(TC_BUILD) + 10)\" >> $@
endif

Lastly add to spksrc.tc.mk:

        @echo TC_BUILD := $(TC_BUILD)
        @echo TC_OS_MIN_VER := $(TC_OS_MIN_VER)
        @echo TC_OS_MAX_VER := $(TC_OS_MAX_VER)
        @echo TC_ARCH := $(TC_ARCH)

[hgy59]

That could be quite easy to add to my current PR such as seting from the spksrc.tc-vers.mk file such as:

I prefer to test this with my local repo as we have to wait up to 48h for the repo on synocommunity.com until new packages appear in the package center in DSM.

[th0ma7]

@hgy59 let me know if you want me to adjust #4567 or prefer another PR if deemed working out as expected.

[hgy59]

Unfortunatly this does not work with the current implementation of spkrepo and there is already an open issue https://github.com/SynoCommunity/spkrepo/issues/63. Your solution in #4567 will not work either.

[th0ma7]

Your solution in #4567 will not work either.

@hgy59 The intent of that particular PR was not related to spkrepo but rather making sure that after an upgrade the package would be disabled as now incompatible with the new kernel.

[hgy59]

@th0ma7 I do not understand what you mean by disabled. As the spkrepo does not care about the third part of the version number and always delivers the highest build number of Major.Minor version this will look like this:

say we have only such versions of package in the repo:

• package-6.2-22259
• package-6.2-24922
• package-6.2-25423
• package-6.2-25556

Now you have devices with different DSM Versions installed

• DSM 6.2-22259
• DSM 6.2.2-24922
• DSM 6.2.3-25423
• DSM 6.2.4-25556
• DSM 7.0-40000

With the current spkrepo implementation all these devices will get the same version of package downloaded in the DSM package center

• package-6.2-25556

You cannot force to download package-6.2-24922 for DSM 6.2.2 when package-6.2-25556 is not compatible with DSM 6.2.2 due to different kernel version.

[th0ma7]

@hgy59 from a spkrepo point of view, you are most probably right. I don't know if there is anything that can be done to add such field so it is understood somehow from the package center which would be quite useful.

I am rather referring to the actual package, already installed/running on your DSM: I want to make sure that it becomes disabled (or removed) pre-post applying a DSM upgrade that affects the kernel.

With this I assume that, lets say you are running DSM 6.2.3-25423 and using a compatible kernel package, it will stop working when you install DSM 6.2.4-25556 upgrade due to the os_max_ver variable in already installed package.

[Dark2004]

Dear @hgy59 how can i install these packages (noarch) on my NAS with DSM 7.0? i do not find any source?

thanks

[hgy59]

Dear @hgy59 how can i install these packages (noarch) on my NAS with DSM 7.0? i do not find any source?

As long as those packages are not published, you need to install the spk files manually in the DSM Package Center of your Diskstation.

You can download packages created with github build action of the related PR or on master branch for merged PRs. Or you can create those packages in the development environment in the spk/{package} folder with

make TCVERSION=7.0

[sam43434]

offical release of DSM 7 for those who hasn't seen the news final build comes out June 29th,

[th0ma7]

ffmpeg + tvheadend + chromaprint + comskip now published.

[BenjV]

I did some testing on DSM 7 and here are some findings and suggestions. For packages that need to share files, the old (pre DSM 7) framework supported the group sc-downloads, but because as of DSM 7 the installation scripts can only run with package privs so this solution does not function any more.

My suggestion would be to use the next privilege file for those packages who needs to share files with other packages.

{
  "defaults": {
    "run-as": "package"
  },
  "username": "sc-<packagename>",
  "groupname": "synocommunity"
}

All those package are then using the group e.g."downloads" (don't use sc-downloads, because that can already exists and will create problems).

Also I would suggest to use a resource file like this:

{
  "data-share": {
    "shares": [
      {
        "name": "{{wizard_share_name}}",
        "permission": {
          "rw": [
            "sc-<package name>"
          ]
        }
      }
    ]
  },
  "port-config": {
    "protocol-file": "app/<package name>.sc"
  }
}

This will create a new share owned by the package user and the group "downloads"

The input for the sharename can be gotten from a install_uifile (or hard coded if you which). Here an example of a install_uifile to do so.

[
  {
    "step_title": "Basic configuration",
    "items": [
      {
        "type": "textfield",
        "desc": "Used Share for downloads",
        "subitems": [
          {
            "key": "wizard_share_name",
            "desc": "sharename",
            "defaultValue": "<package name>"
          }
        ]
      }
    ]
  }
]

Combined with a postinstall script like this:

if [ ! -d "$SYNOPKG_PKGDEST_VOL/$SYNOPKG_PKGNAME/downloads" ] 
then
  mkdir "$SYNOPKG_PKGDEST_VOL/$SYNOPKG_PKGNAME/downloads"
  chmod 770 "$SYNOPKG_PKGDEST_VOL/$SYNOPKG_PKGNAME/downloads"
fi

This configuration will create a new share with group privileges for the group "downloads" and a subfolder name "downloads" with the correct privs.

[sam43434]

unsure if this is the final release thats suppose to come out today but its higher then the RC version https://archive.synology.com/download/Os/DSM/7.0-41890

[Marcoevich]

@sam43434 yeah this one is the final release.

[BenjV]

@hgy59 , @ymartin59 , @th0ma7 and @publicarray What is your opinion on my suggestion to use the same groupname in the privilege file for packages that need to be able to access files from other packages instead of creating the group sc0download in the scripts? And also create a data-share with the resource file to place the files they need to share.

And if you agree with this proposal, what is the best name for this group?