Re: RFS: dwarf-fortress
Hi and thanks for you interest,
On Tue, Feb 21, 2012 at 5:24 PM, Andrey Rahmatullin <wrar@wrar.name> wrote:
> Did you try to contact the previous ITP owner?
I did, a year ago and before as well. The answer I got was "it's still
work in progress, we are trying to talk with the upstream author to
have a more FHS compliant game". No updates since. I haven't asked
again, but it has been WIP for almost two years now and without any
release. I don't want to hijack the package, but I've got something
working for a year already and I took the opportunity of the new
upstream release for uploading it to debian mentors.
> You should not embed libraries. You also should not set Architecture: any.
> If you want to see a i386-only binary packaged for amd64, you may look at
> zsnes (though the proper way is multi-arch dpkg but it is not available in
> unstable now).
I've been already told like half a year ago that the correct way was
to use multi-arch package. However as you said, muti-arch isn't
available and I couldn't even make it work with experimental
dpkg/aptitude, so I gave up [1].
The other correct way, as far as I could see, to have an i386 package
available on amd64 is to use ia32-libs package, however this package
does not contain all the required dependencies for dwarf-fortress
(sdl-ttf, sdl-image and glew are missing). I asked the ia32-libs
maintainer if it was possible to add these libraries, but I've been
told that ia32-libs should not be used and that I should use
multi-arch (cf [1]). Therefore, embed libraries it is.
> You have a build system that uses git magic and branches while an
> unpacked Debian source package is a directory with upstream sources from
> upstream tarball(s) and debian/ directory with build files. Also, as you
> include 3rd-party mods, you should ask about their distribution licenses
> and mention them in debian/copyright.
I'm using git-buildpackage for building, and patch queue maintained
with the same tool. Patches aren't commited to debian branch (maybe
they should), but can be regenerated with "gbp-pq export" command
before running git-buildpackage. Regarding the copyright thing, I
understand that and I'll add the copyrights to the corresponding
files, and ask/tell/talk upstream authors about it.
> There are some more or less minor things such as copyright notices in
> descriptions and old Standards-Version, but they are not important for
> now, as I could not even build the package.
I'm not sure what the procedure is to build the package from the
mentors uploaded files, if you can tell me the issues you are facing,
I can try to solve them.
--
Beren Minor
Reply to: