Why the "Print server" package is now marked as OBSOLETE?

foris

#1

The “Print server” package is marked as OBSOLETE in Foris/Updater tab. This is the case since this commit.
What is the reason? Is this because the print sharing functionality is now available by default without this package installed? Or maybe because this feature will soon be removed?


Forris - Seznamy balíčků - obsolete
#2

I’m also interested in this… Anyone knows why those (OBSOLETE) tags were added?


#3

They are going to be dropped or trimmed a lot with 4.0 release so we marked them in 3.x as obsolete. There are multiple reasons why some of them are getting obsoleted but to react on your question: we are dropping cups and hplip because of not enough manpower to maintain those packages. There is going to be official announcement with Turris OS 4.x migration.


#4

Does it mean that jst the packages will not be handled by Turis team and will be available from LEDE as TOS4 shold be much more standard LEDE based?

Cause this is quite key functionality (print and scanner server) and there exist almost no way how to replace it. To chose bad or bad - no netwrok printing or stuck at TOS3x.


#5

Those packages will not be handled by Turris team and upstream OpenWRT dropped them about two year ago. We don’t have resources at the moment to maintain set of packages that are not our core functionality. That might change in the future but currently we are understaffed and maintaining two versions of Turris OS. We have no time to port those packages at the moment to latest OpenWRT. There was a choice between dropping them and not releasing 4.0, only one answer made sense.

List it self is going to stay but cups is replaced with p910nd. Depending on your setup it might mean only reconfiguration or complete breakage of your workflow.

Look into the p910nd if it would work in your workflow. After that If cups is very important to you then you can take our packages, update them and push them to upstream.

I understand that it is not ideal. We would like to see all our key features present but that is just not possible at the moment. We took liberty to drop a lot of stuff with Turris 4.0 which should give us free hands to target more core stability over wide feature set.


#6

There is better print server CUPS anyway so instead p910 use CUPS!


#7

You don’t understand. Cups is not maintained and supported by upstream but by us. p910 is maintained and somewhat supported by upstream. We are dropping our support for print servers. If you want cups then ask upstream or contribute it upstream. Otherwise if I would exaggerate you can either have cups or updates… choose wisely.


#8

Has someone looked if it’s viable to use cups in a container?


#9

It should be possible. You only have to pass usb device to container which is pretty much possible and then you can run it in container. It is a possibility if you need cups no matter what.


#10

I have cups running in an ubuntu 18.04 LXC-Container, although I don‘t have an usb-printer passed through (I only use it as an AirPrint „Proxy“ for a network printer without AirPrint Capability)


#11

If that’s the case, can you sort out mismatch of obsolete directives in config files ? There are some obsolete now and some were moved between config files of cusps and in the package there are still some mismatch. I personally cleaned this in my configs myself but should be fixed in package defaults.


#12

How to archieve that ? in lxc config ? Please share advice with us.

lxc.mount.entry=devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
lxc.mount.entry = /dev/snd dev/snd none bind,optional,create=dir
lxc.mount.entry = /dev/net dev/net none bind,optional,create=dir
lxc.mount.entry=proc /proc proc nodev,noexec,nosuid 0 0
lxc.mount.entry=tmpfs /dev/shm tmpfs defaults 0 0
lxc.mount.entry= /data data none bind.ro 0.0
lxc.mount.entry= /mnt/flash mnt/flash none bind.ro 0.0
lxc.mount.entry= /lib/modules lib/modules none bind.ro 0.0


#13

Perhaps https://medium.com/@konpat/usb-passthrough-to-an-lxc-proxmox-15482674f11d

I am not sure though whether it depends on a certain LXC version since the LXC packages provided in OWRT/TOS are kind of outdated.


#14

@n8v8r We currently have cups on Turris 3.x. It is not going to be dropped in 3.x release cycle so problem is only if you need it when you transfer to Turris OS 4.x. LXC version in that release is pretty much in sync with upstream.

@Twinkie do a google search. In general you have to do two things. Mount device to container and configure cgroups to have access to it.


#15

upstream = OWRT then that is true but as I mentioned LXC in OWRT is outdated and not well maintained


#16

I see. It still uses 2.x version while 3.x version is already out there for some time. When stuff get little bit less hot (meaning when we drop 3.x versions) we might can get around and push some updates to packages like these.


Turris OS 4.0 alpha5 is released!
Risk of privileged lxc containers and the lack of maintenance of the lxc package
Turris OS 4.0 alpha4 is out!
Turris OS 4.0 alpha2 is out!
#17

just as cross reference with regard to upstream maintenance of LXC


#18

Related to LXC: 2.1 support has ended on September 2018, so it’s deprecated and unsupported version of LXC already. 2.0 is/was the LTS version, that does still have support to June 2021, but this doesn’t apply to 2.1 (as far as I understand). So yeah, upgrading to 3.0 series is already soon half year late.


#19

Thank you for your answer! I’m more affected by the drop of Home Automation than print server, but nonetheless, it’s a shame that it’s being dropped. Guess that’s just business, you have to make options to keep going in the right direction… Thank you for your work! Turris OS 4.0 can’t be released soon enough…


#20

It’s a shame that you advertise print server on your main page (https://omnia.turris.cz/en/) and drop it silently.