zsnes fails to build on amd64

Build zsnes on amd64 by using ia32-libs (and making necessary symlinks in the build area) to satisfy dependencies.
I don't like the way this works, but it seems to work ok. Providing a ia32-libs-dev package would be better.

There have been some discussions in Debian about this (see bug watch), is it worth waiting for a different (better?) solution?

No, because my solution is dependant on multilib which is only
implemented in Ubuntu in the way to make this work.

It would be better just to upload this debdiff, as I doubt seriously
that they will make a better solution.

On Sat, 2008-01-19 at 18:12 +0000, Luca Falavigna wrote:
> There have been some discussions in Debian about this (see bug watch),
> is it worth waiting for a different (better?) solution?
>
> ** Bug watch added: Debian Bug tracker #402104
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402104
>
> ** Also affects: zsnes (Debian) via
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402104
> Importance: Unknown
> Status: Unknown
>

William, can you add my debdiff patch to new upload of zsnes package? Luca Falavigna has told me that it's better to provide two fixes in the same upload. See this bug: https://bugs.launchpad.net/bugs/181782

Yes, I'll merge them. No problem.

I'm unsubscribing ubuntu-universe-sponsors... Please subscribe it again once you have the new debdiff ready.

Thanks for contributing to Ubuntu!

William, haven't you merged already two our patches? I can do it by myself, if you have no time.

I'm sorry, I've been busy. I'll work on it this evening, or you can work
on it. Whichever you prefer.

William

On Sat, 2008-02-09 at 17:07 +0000, kirchun wrote:
> William, haven't you merged already two our patches? I can do it by
> myself, if you have no time.
>

You can do it, if you have enough time for this work now. Use your name in "changelog" file, this is no problem. But I have one little entreaty: please, don't change any content in my patch! And don't permit Siegfried to make changes too... ;-)

Can we minimise the change to only things which are strictly needed (I don't see the point in changing the description in control for instance).
Note that your desktop file is not compliant to the HIG (comment should use an imperative verb).

I've corrected errors in desktop file.
Quote: "Can we minimise the change to only things which are strictly needed..."
Answer: No, we can't. We shouldn't be afraid to make any changes in Ubuntu packages. Debian maintainers can trace all changes in Ubuntu by themself.

By the way, it is discouraged to remove debdiff's that have already
been reviewed (or which other comments mention).

What's wrong now? Silence is the worst reaction. Can anybody make a new package with amd64 support for Hardy Heron release?

Well, it isn't really motivating for reviewers to get answers like comment #15. Anyway:

 - Do not change the Section in debian/control, it is already right. See: "Other OS's and file systems: Software to run programs compiled for other operating system, and to use their filesystems." (http://packages.ubuntu.com/hardy/).

 - Mention Maintainer Field change in debian/changelog.

 - I neither see much point in changing the description in debian/control, but this isn't really a blocking issue.

1. What do you think about these Ubuntu packages of console emulators, that has no "otherosfs" in "Section"?
https://launchpad.net/ubuntu/+search?text=visualboy (Game Boy emulator)
https://launchpad.net/ubuntu/+search?text=fceu (NES emulator)
https://launchpad.net/ubuntu/+search?text=pcsx (Sony PlayStation emulator
https://launchpad.net/ubuntu/+search?text=snes9x (SNES emulator)
Is there an unified standart for packages of console emulators?
2. Sorry, but I don't understand what do you want from me in this point.
3. I've made changes in debian/control description accordingly new desktop file. Can't we make any changes in debian/control description? Why?

1. Hm... But there are more emulators in the otherosfs section, and this section's description matches the best for them, so I guess those packages are wrong (report this to Debian if you want). And anyway, the section has to be manually changed by an Archive Admin (just changing it in debian/control has no effect).

2. Just add an entry like "* Modify Maintainer value to match the DebianMaintainerField specification." to debian/changelog.

3. Well, you can make them, but they will just make the diff to Debian bigger and would be overwritten anyway with the next Debian upload that fixes the other issues (unless the Maintainer decides that he likes your description better than his and uses it there). The proper way to get such trivial changes in (which isn't even because of a typo, just a "I like the description better this way) would be to propose them to it's Debian Maintainer, who is the guy in charge for this package.

Uploading with additional changes (add dh_desktop call, and change "reassign" to "change" -as it's the first time this package is modified in Ubuntu- and "deb-control" to "debian/control" -for better clarity- in the changelog).

Thanks for contributing to Ubuntu!

Sorry for my ignorance, but what exactly does the "fix released" for this bug means? I'm not able to see ZSNES X86_64 package on Hardy's repositories... is this due to the usual lag to update mirrors (I'm trying Ubuntu US), or it's just because this bug is for only 1 of several steps to have the package ready for distribution? (In this case, what step would come next?)

Thanks in advance.

I'm reopening this bug because, for some reason, the package is not building on amd64. The build daemon doesn't appear to even be trying, despite amd64 being in the control file now. Gnome-app-install still has it unclickable, and apt-get install zsnes fails to find a package on amd64. It's just not being built.

However, apt-get --build source zsnes will work (though when I did this it would segfault on startup). Something weird is going on.

The package is currently listed under Packages-arch-specific as building in i386 only. It should probably be removed from there, as the control file can fill that function.

Unfortunately, the control file is ignored when there is an entry in the Packages-arch-specific file[1]. If this build problem can be resolved with Debian, this exception should go away.

[1] http://cvs.debian.org/srcdep/Packages-arch-specific?rev=1.738&root=dak&view=log

As I understand it, the Debian and Ubuntu zsnes packages already restrict the control file to i386 only (except the last patch adding amd64 support for Ubuntu). So in this case we can rely on it.

Any possibility for this being done to Intrepid?

New versions for intrepid and jaunty fix this bug.

What new versions? This page: http://packages.ubuntu.com/intrepid/zsnes still shows only an i386 package.

Hi, package builds fine in amd64: https://launchpad.net/ubuntu/+source/zsnes/1.510-2.1ubuntu1.1

Package url: http://mirrors.kernel.org/ubuntu/pool/universe/z/zsnes/zsnes_1.510-2.1ubuntu1.1_amd64.deb

This is not "Fix Released". The package may be being built, but it's not listed in the package list, so I can't install it without knowing ahead of time that it exists and manually grabbing it from the mirror.

I concede that it's in intrepid-proposed, but jaunty does not have this fix.

Interesting. The package from intrepid-proposed crashes hard for me.

Can I still file bugs against things from intrepid-proposed?

If the package segfaults immediately (which happened to me last time I tried this), then it should be removed from -proposed.

If the package isn't showing up in Applications->Add Applications after it's built for amd64, then the problem there is in Gnome-App-Install (Wine had a similar issue when it added support for amd64)

Scott Ritchie: the crash you were seeing might be bug 250425, which was fixed in the same upload which should have fixed this bug.

It does not crash immediately for me (I can get to the main menu, which was not possible before; I did not test further by loading a ROM). And it seems it is now in intrepid-updates, not intrepid-proposed, so you can go ahead and file a bug report.

Very well, adding a Gnome-App-Install task: on Intrepid and Jaunty Gnome-App-Install needs to include zsnes on amd64

Actually this is an app-install data task

There's no amd64-package in jaunty, doesn't look like it's beeing told to build one: https://launchpad.net/ubuntu/jaunty/+source/zsnes/1.510-2.2ubuntu1

Apparently zsnes is in the Packages-arch-specific file, preventing amd64 builds:

https://buildd.debian.org/quinn-diff/Packages-arch-specific

I don't know what's required to remove it from this file.

I see a launchpad project for packages-arch-specific, but they don't have a bug tracker, and only core-dev can upload to it.

https://launchpad.net/packages-arch-specific

There is not evident work being done in this bug. Despite there is a package for zsnes in intrepid amd64 it seems to be impossible for users have an amd64 package on jaunty or karmic. If the problem is that zsnes is in the Packages-arch-specific file can someone contact the maintainer for removing it from there or seek a better solution?. If it is not possible, what sounds like a kind of huge bureaucracy, why don't you put the won't fix status to this bug? It is hard to say it but for bugs like this (bugs that never get fixed) is that there is people asking for themselves if ubuntu is really for human beings, and if it cares about people who uses it.

The current blocking dependency is in this debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520479 Since the packages-arch-specific file is shared between ubuntu and debian, the work needs to be done in debian to backport the amd64 compatibly version of zsnes into debian. This may include modifications to the ia32-libs package in debian as well.

ok, Phillip Kern mentioned that zsnes amd64 doesn't work for him. In fact it works well for me. I have just replied to that debian bug that zsnes amd64 works well for me. Should we encourage all the people that have zsnes working in intrepid amd 64 post a reply in that debian bug? Phillip Kern says that he needs reports of that. If that is necessary to solve this bug we should do it.

Certainly reports of it working in ubuntu would help, but also someone will need to make it work in debian before it will be removed from the p-a-s file.

bugs.debian displays your email address, so I'd prefer not to post there, but I can supply any of my system specs if anybody needs it. I used zsnes heavily for several months with Ubuntu 8.10 AMD64 Desktop, and I can't recall having any problems at all. I just manually installed the 8.10's package for Ubuntu 9.04 AMD64 Desktop, tested it briefly with one rom for a few minutes, and everything was running smoothly with it also.

I tried getting zsnes building properly on amd64 karmic for a while today and ultimately gave up. Here's what I've learned:

ia32-libs is complete enough (we even have libao now), so that shouldn't be an issue
sdl-config is hard-coded to point to /usr/lib, but we need it to point to /usr/lib32

The package in its current form contains the old hack to manuall make a lib folder and create .so symlinks to /usr/lib32. This should no longer be necessary as ia32-libs now provides them. However, if I remove this logic from the package build script, it fails after sdl-config as it doesn't look for SDL in /usr/lib32 (despite it being there). If I leave the logic in, the package builds for some reason, however it segfaults instantly on startup.

I've added a task to libsdl to deal with the hard-coding, although this may end up just not being fixed until multiarch

I close the app-install-data task, once there is a amd64 version, it will pick it up automatically.

still not not amd64 package in maverick

I've unmarked the debdiff as a patch as it does not fix this particular bug.

I recall a comment I made more than a year ago, why don't you set the bug status as won't fix?, there is no progress in this bug at all, and nobody knows how to solve it or if somebody knows, does not made the needed thing to solve this bug. I get surprised when an e-mail is sent to me about activity in this bug because... maybe this will be fixed when no one of us who used to play with zsnes remember how to use it, or may be it will be fixed when we are 80 y.o.

Can anyone try the patch they are talking about in these comments? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402104
if they are successful in building on an amd64 Debian sid, it should build on an updated Ubuntu.

Etienne Millon says that it is possible to build zsnes 1.510-3 in debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402104#104 , but we will have to wait until wheezy is in development. It would be great if some ubuntu developer could backport zsnes 1.510-3 in some ppa, anyway the code can be gotten from http://git.debian.org/?p=pkg-games/zsnes.git

For those who want to have zsnes installed on an amd64 machine there is this a launchpad ppa (MedOS) https://launchpad.net/~smaxein/+archive/ppa that uses zsnes 1.510-3 from the debian git repo, thanks Simeon for the effort!

Hello,
I'm the maintainer of the Debian package.
Now that wheezy is in development I could publish

(sorry, end of message following)

... version 1.510+bz2-1, which includes amd64 support. Feel free to pull it from sid. If you need to patch it to build it on Ubuntu, patches are welcome (or better, clone the git repository).

Have a nice day
Etienne

Fix in Debian testing http://packages.debian.org/wheezy/zsnes

In the mean time, after almost 4 years of this bug being open, it would be worth to provide bsnes. It is a viable alternative with native amd64 support and is supposed to have more emulation accuracy than both zsnes and snes9x. Check the corresponding bug: https://bugs.launchpad.net/ubuntu/+bug/622185

Santiago,

It's already in the universe repository for Precise :-)

Incidentally, now that we have multi-arch support, should installing "zsnes:i386" be considered a solution to this bug report?

If you invoke "apt-get install zsnes" on Oneiric, it will install zsnes:i386 and all its dependencies.

No., it should not. Installing zsnes:i386 requires i386 versions of several libraries that are incompatible with amd64 programs. For instance, one cannot have both zsnes:i386 and mpd:amd64 installed. I can confirm that this bug is still significant in Oneiric.

Also, workaround: Build the amd64 package from source and install.

By Precise the dependent libraries of zsnes should be multiarched, so it will be ok by then. Shame it's been broken for so long though.

Now that Debian has multiarch support, it is possible to use it to package zsnes.
I'd like to do that at least for wheezy (S2 2012), but of course I'd happily merge that from Ubuntu if someone wants to do it :)
The GBP repository is at <git://anonscm.debian.org/pkg-games/zsnes.git>.

Finally solved with precise and multiarch!