* Package name : xserver-xorg-video-sunffb Version : 1.2.2 * URL : http://www.x.org * License : MIT/X Programming Lang: C Description : X.Org X server -- Sun FFB display driver This package provides the driver for Sun Creator, Creator3D, and Elite3D video devices. More information about X.Org can be found at: <URL:http://www.X.org> This package is built from the X.org xf86-video-sunffb driver module. This driver was previously removed from Debian along with sparc support. With the sparc64 Debian port, it has become useful again. I'd like to re-introduce it into Debian to provide support for the aforementioned video adapters, found in certain Sun Microsystems graphical workstations. For the time being, I'd like to maintain it together with the Debian sparc/sparc64 port team, and if possible, with the X Strike Force at a later point of time. Despite being useful only on Sun graphical workstations, the package builds fine on any architecture, so I think it would be acceptable to include it on the Debian package servers. The project hasn't received any upstream updates in a long time, but was not deprecated and is still supported in recent X.Org versions.
I disagree. The package should only build on sparc/sparc64 so doesn't need to be in Debian at this time. What purpose would building/shipping it anywhere else serve? Cheers, Julien
currently a ports-only architecture, so the package would have to go into the "unreleased" repository, making it more tedious to maintain. This was suggested by John: https://lists.debian.org/debian-sparc/2018/08/msg00087.html I'd very much like to get it closer to a state that is acceptable for the XSF, so any advice is appreciated. I'm maintaining the package here: https://salsa.debian.org/onitake-guest/xserver-xorg-video-sunffb And a previous upload to mentors is here: https://mentors.debian.net/package/xserver-xorg-video-sunffb
Hi Julien! It's a workaround to be able to upload the package to unstable. Uploading a package that does not produce any builds on the release architectures would result in the source package being removed immediately by the FTP servers. What we could do is actually split the package into an arch:all and arch:sparc64 part (e.g. documentation) so that the package gets build for arch:all and can be uploaded to unstable. Adrian
I don't understand why that is a requirement. The package could just as well live in debian-ports, like other sparc-specific packages (I assume e.g. silo lives there). That all sounds backwards to me. Cheers, Julien
We are actually trying to get rid of these packages which is one reason why we have switched from SILO to GRUB. The second one is that SILO is unmaintained upstream and 32-bit only. Currently we have only sparc-utils which is in "unreleased" and the problem is there that "unreleased" has to be maintained manually and it's not possible to perform source-only uploads. "unreleased" is rather a stopgap solution rather than something you want to use in the longterm. Adrian