Re: sunffb xorg driver - was: Re: Bullseye planned on sparc64?
>> 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...
Reply to: