>> Actually... most of what I did was concerned with making the package >> buildable again. It contained some cruft and needed a bit of cleanup and >> re-alignment. > > OK. If you have a patch for that, please post it to the list as this will > help me save some time.
I mainly updated standards and debhelper, then fixed the lintian errors that cropped up. The previous maintainers also removed some files from the upstream tarball (mainly automake/autoconf intermediates), that caused me some trouble with gbp. So I simply added them back. The patch can be found here: https://salsa.debian.org/onitake-guest/xserver-xorg-video-sunffb/-/commit/5bac1113023622c191048225f944018ec86ffb9b I suppose I can produce a squashed patch from the rest. >> If I remember correctly, the XAA patch actually came from upstream, but >> wasn't properly released due to deprecation. > > Good to know, thanks. Researching a bit... Someone patched this directly, but the change wasn't in the upstream tarball that Debian used, so caused some build trouble: https://salsa.debian.org/onitake-guest/xserver-xorg-video-sunffb/-/commit/181b60190c1f81fc9b9b5deb07d536b78f2536ab I reverted this here: https://salsa.debian.org/onitake-guest/xserver-xorg-video-sunffb/-/commit/a18f0c12ae43d31aa9ca46c29b31961138ea7d13 Then re-introduced it as a patch: https://salsa.debian.org/onitake-guest/xserver-xorg-video-sunffb/-/commit/3b176696df8652c97282403a411d95801274e822 > Using sbuild or pbuilder is not a matter of preference but building the > package in > a clean environment so it doesn't depend on packages from your day-to-day > system > which may not be available on other systems. Using containers seems to be the better choice to me, at least when working on packages locally. I should definitely give https://manpages.debian.org/testing/debspawn/debspawn-build.1.en.html a try. Hopefully it also works on sparc64...
