Re: Uploading MAME to Debian
Emmanuel Kasper
> In the bug report, others have suggested hosting mame in the games
> packaging team repository. I think it's a good idea, but it's your call. I
> don't think the Alioth admins are really happy about creating new groups
> for just one app, and MAME really fits well in the games repo, while that
> does not mean you'll lose control over your package.
> As for the mailing list, you might want to just use the pkg-games-devel
> list.
Last time I tried to register a project on Alioth, you needed to be a
DD/DM to get your project approved that is why we set up our own
VCS/Forge system.
OTOH I have nothing again moving our VCS to Alioth for collab
maintainance. There is also a pkg-xmame project on Alioth which has been
inactive since 5 years, we could take that over as well.
>
>> A feedback on the packaging is more than welcome !
>
> This is very good!
Thank you for your feedpack, I at least need some help if we want the
dpkg-source v3 / policy version thing :) Actually I thought that
debian-helper would take care of such things.
A question regarding the Package, I am somehow skeptical of the auto
downloading of Roms which takes place right now after the package
installation. First I am not sure if we are allowed to do this, second I
don't like this kind of magic stuff happening, as anyway you should know
how/where to copy your own roms if you want to use Mame properly. What
is your opinion on that ?
In chdcd.c I see
Copyright Nicola Salmoria and the MAME Team.
Visit http://mamedev.org for licensing and usage restrictions.
what is wrong here ?
So now I will push on our forge some of the changes you suggested, and
wait for Ludo's feedback if we are moving to Alioth.
Merci
Manu
Emmanuel Kasper
> Ludo: I don't know where all the packaging history went. If you've been
> maintaining mame for years, I don't see why you should be getting rid of
> your entire debian/changelog. There's nothing bad in doing that, it just
> doesn't show all the previous work behind the package.
AFAIK Ludo restarted the packaging from scratch on September which is
why the changelog is emply.
> You should probably update the package to the newest Standards-Version. I
> also suggest you convert it to DpkgSource v3, as you're using quilt
> anyway. If you need help with this, just say!
Thanks for the patch. Although it not did not apply properly ( I am
wondering if this has to do with the use of non-ascii characters in the
control file, or poor me ) I integrated the changes on shaperstudio.
>> Nitpicks in the control file:
>
> Extra newline between source package and mame binary package.
>
> Description:
>
> - "... is a hardware emulator..."
> - This package provides the MAME binary..."
> - Remove the authorship information. That will be available in the
> copyright file.
OK
> - No space between a word and :
> This package provides tools to be used with MAME:
Looks OK according to
http://en.wikipedia.org/wiki/Colon_%28punctuation%29#Spacing
> In the copyright file, you refer to BSD, GPL and LGPL, but no links to
> common-licenses.
I will tackle that.
> In chdcd.c I see
> > Copyright Nicola Salmoria and the MAME Team.
> > Visit http://mamedev.org for licensing and usage restrictions.
> >
> > what is wrong here ?
>There's no licence. It just points at a website. There should be a clear
> licensing statement.
is that enough if we change the link to mamedev.org/legal, where the
standard mame license is ?
> Why do you put the .desktop and .xpm file in a deep dir inside the debian
> dir? Why not move them to debian/, and reference those files in
> mame.install (like you do, but using the longest path ever!)
This I won't :) Feel free to pick it
> A suggestion: on your sed constructs, use another separator and avoid
> escaping the slashes:
>
> sed -i 's%\( comments\).*%\1;/var/games/mame/comments%' $INIFILE
I will improve that.
> You should not run find -exec chmod on every upgrade. If there are a lot
> of files in that dir, installation could take ages.
Actually I don't undestand actually why we have this find command on the
postinst. I notice that while deinstalling mame, the package tries to
remove /var/games:
dpkg: warning: while removing mame, directory '/var/games' not empty so
not removed.
Is not the /var/games a part of the FHS ? Then I don't think we should
try to remove it, it may have been installated as part of the base system.
> Many manual pages need a bit more work ("etc." all over the place!)
> Finally, as you need to repack the .zip, why not do a .tar.bz2?
I prefer tar.gz because bzip format uses too much CPU. However it
reminds me I should the -9 compression level from gzip. ( I think debian
source packages have this level of compression as well )
I have also found a free as in free-beer rom to put as an example in the
quickstart documentation, it looks much nicer that the roms from the
mamedev website !
It is called World Rally and it's available from
http://www.gaelco.com/
Greetings
Emmanuel
Ludo
Hi!
Ok. My first suggestion is to maybe move all of this to Alioth and upload
On Fri, Nov 05, 2010 at 06:06:06PM +0100, Emmanuel Kasper wrote:
> Ludo did most of the packaging work, I commited some fix for powerpc.
>
> Right now the two packages ( mame and mame-tools) are lintian clean
> exepct for debian-helper overrides warning and the packaging code is
> available from download from:
> http://indefero.shaperstudio.com/p/mamedeb/
>
> This will build a mame v 0.139 binary ( althoug upstream has just
> released 0.140 )
>
> We have also a mailing list at http://groups.google.com/group/mamedeb
the packages to mentors.debian.net. If you don't have Alioth accounts, you
should apply for one now.
In the bug report, others have suggested hosting mame in the games
packaging team repository. I think it's a good idea, but it's your call. I
don't think the Alioth admins are really happy about creating new groups
for just one app, and MAME really fits well in the games repo, while that
does not mean you'll lose control over your package.
As for the mailing list, you might want to just use the pkg-games-devel
list.
> A feedback on the packaging is more than welcome !
This is very good!
Ludo: I don't know where all the packaging history went. If you've been
maintaining mame for years, I don't see why you should be getting rid of
your entire debian/changelog. There's nothing bad in doing that, it just
doesn't show all the previous work behind the package.
You should probably update the package to the newest Standards-Version. I
also suggest you convert it to DpkgSource v3, as you're using quilt
anyway. If you need help with this, just say!
Nitpicks in the control file:
Extra newline between source package and mame binary package.
Description:
- "... is a hardware emulator..."
- This package provides the MAME binary..."
- Remove the authorship information. That will be available in the
copyright file.
- No space between a word and :
This package provides tools to be used with MAME:
In the copyright file, you refer to BSD, GPL and LGPL, but no links to
common-licenses.
dhdcd.c and others don't have an explicit copyright notice in the header,
but a pointer to MAME's website. You should probably tell upstream about
this.
Why do you put the .desktop and .xpm file in a deep dir inside the debian
dir? Why not move them to debian/, and reference those files in
mame.install (like you do, but using the longest path ever!)
A suggestion: on your sed constructs, use another separator and avoid
escaping the slashes:
sed -i 's%\( comments\).*%\1;/var/games/mame/comments%' $INIFILE
You should not run find -exec chmod on every upgrade. If there are a lot
of files in that dir, installation could take ages.
Many manual pages need a bit more work ("etc." all over the place!)
Finally, as you need to repack the .zip, why not do a .tar.bz2?
--
Jordi Mallach Pérez -- Debian developer http://www.debian.org/
jo...@sindominio.net jo...@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/
Emmanuel Kasper
Hej Ludo !
> Back to business after holidays.
> Thanks a lot Jordi, the MAME package is evolving faster with updates
> and (I hope) upload it is greatly appreciated!
>
> About Alioth, as said by Emmunuel, we were not allowed to create a
> project because none of us are Debian developer/maintainer so we
> hosted ourselves the "mamedeb" project. In my opinion, there is no
> problem to switch from our VCS (Git) to Alioth if we can keep the
> history of our previous commits.
I asked the alioth to be added to the pkg-games team. Since we're backup
by an official DD this time, hopes are good :)
Copy of my message
Hello
I am part of a team of two three people working on packaging an actual
version of Mame, the Arcade Emulator. ( see ITP
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424905 )
As suggested by the Debian Developper Jordi Mallach in the bug report ,
I would like to become a member of the pkg-game to co-maintain the
debian package on Alioth. Right now we use our own forge with git
located at
http://indefero.shaperstudio.com/p/mamedeb/
Thank you !
Emmanuel
Ludo
Hi,Hej Ludo !
Back to business after holidays.good news
Thanks a lot Jordi, the MAME package is evolving faster with updates
from Emmunuel and Félix. The help of a Debian developer to finalize
and (I hope) upload it is greatly appreciated!
About Alioth, as said by Emmunuel, we were not allowed to create a
project because none of us are Debian developer/maintainer so we
hosted ourselves the "mamedeb" project. In my opinion, there is no
problem to switch from our VCS (Git) to Alioth if we can keep the
history of our previous commits.
Félix Arreola Rodríguez
I'm also reading all of your messages, I'm also glad to move to alioth. Will be my fisrt time working on a Debian project.
I suggest to keep using git, because it's hard to me learn another system.
Well, I will try to register at Alioth.
Thanks for this message. I think we have good chances to be acceptedthis time :)--Ludo.
--
Atte. Félix Arreola Rodríguez,
Firmado con GPG, llave 1E249EE4
Jordi Mallach
Sorry, I've been terribly swamped with different stuff but I still haven't
forgotten!
On Mon, Nov 15, 2010 at 11:15:38AM +1100, Ludo wrote:
> Back to business after holidays.
> Thanks a lot Jordi, the MAME package is evolving faster with updates
> from Emmunuel and Félix. The help of a Debian developer to finalize
> and (I hope) upload it is greatly appreciated!
I really want to help, and would like to get some package up in the NEW
queue in the following weeks. In mid january I'll be totally swamped again
and won't be able to do much until after FOSDEM.
> About Alioth, as said by Emmunuel, we were not allowed to create a
> project because none of us are Debian developer/maintainer so we
> hosted ourselves the "mamedeb" project. In my opinion, there is no
> problem to switch from our VCS (Git) to Alioth if we can keep the
> history of our previous commits.
I have little experience with Git, but I guess it'll be easy enough to
import the current history.
If you think having a dedicated MAME group/project is important, I can ask
for one. If you think you can live with the Debian Games repository,
that's ok also. I'll ask for a pkg-mame project after sending this email,
in the meantime.
> About debian/changelog, I would really like to keep a log of all the
> initial work and bugfixes but I was not sure if I can put them as-is.
Sure, I'm sure you can. If you want to describe anything specific of the
packaging (other than the history), README.source or even copyright might
be good places. Depends on the content.
> About the "longest path ever" :) I have put the files into subfolders in
> order to separate "media" and link files from the "core" debian files.
> There are no other reason, so I'll put them on the debian folder.
Thanks!
> Sed separator replacement is on the way, ugly slashes escaping
> is replaced by "_" in most of the commands:
> sed -i 's_[ +]comments_ /var/games/mame/comments;comments_' $INIFILE
Ok. It's not uncommon to find _ in paths, but it'll work in the meanwhile.
I normally use !, which is pretty hard to find in a filename.
> MAN pages are completed now: ldresample, mame-regrep, mame-split,
> mame-src2html, mame-srcclean, unidasm and mame.
You rock!
> About the "chmod o+rw" on the postinst: it is here to allow end-user
> to move/delete/save ROMs or ini files in this folder. In fact it is not
> necessary because end user will have it's own ini and ROM path so
> I'll remove it.
Good!
So, what's the current status? Come on, I need to build a new mame box for
our house in the mountain! :P
Jordi
Emmanuel Kasper
> If you think having a dedicated MAME group/project is important, I
> can ask for one. If you think you can live with the Debian Games
> repository, that's ok also. I'll ask for a pkg-mame project after
> sending this email, in the meantime.
I wrote one month ago to the alioth admins to request an admission in
Debian Games but got no reply. So pkg-game is great in the mean-time.
I guess we have to show some (working, preferably ) code to get
admitted in the team.
> So, what's the current status? Come on, I need to build a new mame
> box for our house in the mountain! :P
We were discussing the topic yesterday with Ludo ( well not the topic
of your house on the mountain but the mame package :)
We have three issues still open on our bug tracker
(http://indefero.shaperstudio.com/p/mamedeb/issues/) and we thought we
would send the package to you or mentors.debian.net once they get
resolved. Your help / feedback is welcomed on those !
Jordi Mallach
Great to hear from you! Let's get this done (ie, let's discuss what's
missing):
On Mon, Dec 27, 2010 at 05:33:27PM +0100, Emmanuel Kasper wrote:
> I wrote one month ago to the alioth admins to request an admission in
> Debian Games but got no reply. So pkg-game is great in the mean-time.
> I guess we have to show some (working, preferably ) code to get
> admitted in the team.
Ok. In any case, this isn't a blocker. The package can live outside
alioth for it's initial upload if necessary, and we can move it in as soon
a suitable group is created.
> We have three issues still open on our bug tracker
> (http://indefero.shaperstudio.com/p/mamedeb/issues/) and we thought we
> would send the package to you or mentors.debian.net once they get
> resolved. Your help / feedback is welcomed on those !
I see.
11. Comment out Mame rom downloading or move it in a separate package
I think this is release critical. My opinion is:
- move this stuff to mame-roms-free (if free means libre; if the licences
are “free beer”, then I'd go for mame-roms-nonfree or just mame-roms)
- get rid of debconf entirely, if you install the mame roms package, you
will not get any kind of questions whether the files should be
downloaded or not. The postinst will always try to do it. The package
description will warn about this. (flashplugin-nonfree is an example of
a package that does this).
- add a Suggests: mame-roms-free to the mame package.
I think this is the easiest and cleanest way of doing it.
We should think if mame-roms-* should be in a separate source package, or
inside mame's. The latter would make the mame-roms get installed every
time there's a new mame version, while it's highly improbable the free
roms will ever change again. I think it should be a separate source
package, but that's up to you.
12. dpkg-shlibdeps sends warning
This isn't critical at all. Using --as-needed is generally a good idea,
unless it breaks things. I don't think it would break anything, but in any
case, we can go ahead without this "fix" and add it in the future, if
wanted. It's probably a trivial fix anyway.
9. Review what is needed to be sent upstream ( and send it )
This isn't release critical either. Of course, we should be doing it ASAP,
but it doesn't block the upload in any way.
I'm more than happy to sponsor the first upload!
Emmanuel Kasper
> On Mon, Dec 27, 2010 at 05:33:27PM +0100, Emmanuel Kasper wrote:
>> I wrote one month ago to the alioth admins to request an admission in
>> Debian Games but got no reply. So pkg-game is great in the mean-time.
>> I guess we have to show some (working, preferably ) code to get
>> admitted in the team.
>
> Ok. In any case, this isn't a blocker. The package can live outside
> alioth for it's initial upload if necessary, and we can move it in as soon
> a suitable group is created.
OK I am looking forward to manage the package in a team on alioth, as 15
Mo of compressed source code is a big thing to take care of :)
> 11. Comment out Mame rom downloading or move it in a separate package
>
> I think this is release critical. My opinion is:
>
> - move this stuff to mame-roms-free (if free means libre; if the licences
> are “free beer”, then I'd go for mame-roms-nonfree or just mame-roms)
> - get rid of debconf entirely, if you install the mame roms package, you
> will not get any kind of questions whether the files should be
> downloaded or not. The postinst will always try to do it. The package
> description will warn about this. (flashplugin-nonfree is an example of
> a package that does this).
> - add a Suggests: mame-roms-free to the mame package.
>
> I think this is the easiest and cleanest way of doing it.
>
> We should think if mame-roms-* should be in a separate source package, or
> inside mame's. The latter would make the mame-roms get installed every
> time there's a new mame version, while it's highly improbable the free
> roms will ever change again. I think it should be a separate source
> package, but that's up to you.
Since we all agree on the idea of splitting that part let's do it.
I will reorganize the git repository for the package mame-get-roms and
remove the downloading stuff from the mame package
The mame-get-roms package should go in contrib, as the roms themselves
are only "free-beer"
> 12. dpkg-shlibdeps sends warning
>
> This isn't critical at all. Using --as-needed is generally a good idea,
> unless it breaks things. I don't think it would break anything, but in any
> case, we can go ahead without this "fix" and add it in the future, if
> wanted. It's probably a trivial fix anyway.
OK. As a Debian packaging newbie it is somewhat difficult to see what is
critical or not, as besides Lintian, each debian developper is picky on
different subjects :) as I see from debian-mentors
> 9. Review what is needed to be sent upstream ( and send it )
>
I wrote a message on the sdl mame forum which was picket by R Belmont
http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=66431
who takes care of the unix/linux bits in mame, whith a link to our mame
pages.So this issue is closed
Concerning the upload to NEW for me as soon as the download rom things
are removed from the package mame, the package is OK to be uploaded.
Would like to be added to our mamedeb mailing lists until we get
approved on Alioth ?
Manu
Emmanuel Kasper
>
> Concerning the upload to NEW for me as soon as the download rom things
> are removed from the package mame, the package is OK to be uploaded.
I just forgot that the package is OK *IMHO* !
>
> Manu
>
>
>
Emmanuel Kasper
Some update about the status of the package.
> 11. Comment out Mame rom downloading or move it in a separate package
>
> I think this is release critical. My opinion is:
>
> - move this stuff to mame-roms-free (if free means libre; if the licences
> are “free beer”, then I'd go for mame-roms-nonfree or just mame-roms)
> - get rid of debconf entirely, if you install the mame roms package, you
> will not get any kind of questions whether the files should be
> downloaded or not. The postinst will always try to do it. The package
> description will warn about this. (flashplugin-nonfree is an example of
> a package that does this).
> - add a Suggests: mame-roms-free to the mame package.
>
> I think this is the easiest and cleanest way of doing it.
> We should think if mame-roms-* should be in a separate source package, or
> inside mame's. The latter would make the mame-roms get installed every
> time there's a new mame version, while it's highly improbable the free
> roms will ever change again. I think it should be a separate source
> package, but that's up to you.
I moved this a a different source package, which is not yet finished
yet, but the mame pacakge itself is now fine. I have a look at how
fedora packages mame, and they have also a separate rom package,
containing one *single* rom.
> 12. dpkg-shlibdeps sends warning
>
> This isn't critical at all. Using --as-needed is generally a good idea,
> unless it breaks things. I don't think it would break anything, but in any
> case, we can go ahead without this "fix" and add it in the future, if
> wanted. It's probably a trivial fix anyway.
ok
> 9. Review what is needed to be sent upstream ( and send it )
>
> This isn't release critical either. Of course, we should be doing it ASAP,
> but it doesn't block the upload in any way.
I sent our mame pages to the sdlmame forums here
http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=66395#Post66395
> I'm more than happy to sponsor the first upload!
There is still room for improvement, but the package is quite usable
now, so feel free to go ahead :) !
Manu
Emmanuel Kasper - Libera
> I've made a few changes to make lintian happy, but otherwise the
> package
looked very good. It's being uploaded as we speak!
he he cool. Is there any URL where we can see your package in experimental so I can merge
back your changes in our git repository ?
> I don't see if the split, src2html & other needless binaries were
> removed,
but it seems the upstream authors said they are only useful for the
> MAME
release managers. We might want to remove them in the next upload.
OK
> I have uploaded to experimental, as there are binary packages that
> would
conflict in unstable. We need to ask for a removal of xmame, if that
> was
the original plan.
yes, xmame should be removed, although xmame had some feature not found in mame
( for instance xmame had this advanced scaling : http://scale2x.sourceforge.net/ )
Ideally mame should replace xmame-svga, xmame-x, xmame-sdl by doing a dist-upgrade,
so I created some virtual packages to do so. But the problem is only aptitude correctly does the
transition, not apt-get. And I don't know why.
> Congrats for the hard work!
you're welcome !
a propos any news from the alioth admins ?
Manu
Jordi Mallach
On Thu, Jan 13, 2011 at 11:04:36AM +0100, Emmanuel Kasper - Libera wrote:
> he he cool. Is there any URL where we can see your package in
> experimental so I can merge back your changes in our git repository ?
Yes, I'm uploading this stuff to http://web.iti.upv.es/~jordi/mame/.
It's a temporary location, and should be deleted in a few days.
I forgot to tell you about committing the changes, so sorry. Can you do so
in a way the author is Jordi Mallach <jo...@debian.org>? I know you can in
Git, but as I said, I'm all but a git expert.
> yes, xmame should be removed, although xmame had some feature not found
> in mame ( for instance xmame had this advanced scaling :
> http://scale2x.sourceforge.net/ )
Wow, this rocks. Why isn't this in MAME?
> Ideally mame should replace xmame-svga, xmame-x, xmame-sdl by doing a
> dist-upgrade, so I created some virtual packages to do so. But the
> problem is only aptitude correctly does the transition, not apt-get. And
> I don't know why.
We need to investigate this then.
> a propos any news from the alioth admins ?
No. I insisted a bit the night I uploaded, and got some info:
if we just want to use alioth to host a git/svn/bzr repo, we should use a
generic project like collab-maint. If we need any other Alioth facility,
like a webpage, a mailing list and so on, then an individual project is
ok. I think we can benefit from a mailing list and a bugtracker (you
already have one) but the mailing list can arguably be replaced by mail to
ma...@packages.qa.debian.org, and the bugtracker will now be the BTS.
What's your opinion? I can do a formal project request if you think it's
needed. If not, we would go to pkg-games or collab-maint.
Jordi
--
Jordi Mallach P�rez -- Debian developer http://www.debian.org/
Emmanuel Kasper
> It's a temporary location, and should be deleted in a few days.
> I forgot to tell you about committing the changes, so sorry. Can you do so
> in a way the author is Jordi Mallach<jo...@debian.org>? I know you can in
> Git, but as I said, I'm all but a git expert.
>
ok after fiddling with some git commands, I pushed your changes back
to the git directory under your own name.
>> yes, xmame should be removed, although xmame had some feature not found
>> in mame ( for instance xmame had this advanced scaling :
>> http://scale2x.sourceforge.net/ )
>
> Wow, this rocks. Why isn't this in MAME?
I think it was dropped when sdlmame and mame merged properly, as it was
not working on all platforms. Mame itself isn't that much intersted in
features which improve playability, like network gaming. I guess this is
the reason that some many mame forks exist on Windows.
Right now mame looks not very nice on my 1920x1200 screen, I will try to
make it run wich xephyr, a nested x server with 3d acceleration support,
so I can have mame in a smaller window inside my X desktop.
>> Ideally mame should replace xmame-svga, xmame-x, xmame-sdl by doing a
>> dist-upgrade, so I created some virtual packages to do so. But the
>> problem is only aptitude correctly does the transition, not apt-get. And
>> I don't know why.
>
> We need to investigate this then.
I have seen there is a Debug::pkgProblemResolver option in apt.conf,
maybe the place to look for help.
>
>> a propos any news from the alioth admins ?
>
> No. I insisted a bit the night I uploaded, and got some info:
>
> if we just want to use alioth to host a git/svn/bzr repo, we should use a
> generic project like collab-maint. If we need any other Alioth facility,
> like a webpage, a mailing list and so on, then an individual project is
> ok. I think we can benefit from a mailing list and a bugtracker (you
> already have one) but the mailing list can arguably be replaced by mail to
> ma...@packages.qa.debian.org, and the bugtracker will now be the BTS.
This all makes sense and I completely agree twith idea, let'S fo
collab-maint except I also use our own bug tracker as an issue list /
todo list. Is that proper use of the BTS ?
In the mean time would you like to have commit access on our git
repository ? ( as this alioth thing seems to take ... time ... )
Git is not so much different from svn, the thing is wou have to commit
first time in you local ( local computer branch ) and then push that to
the master server.
If you feel more confortable with subversion, we can use that for the
package in the future, as far i am concerned I don't care.
Manu
Emmanuel Kasper
> if we just want to use alioth to host a git/svn/bzr repo, we should use a
> generic project like collab-maint. If we need any other Alioth facility,
> like a webpage, a mailing list and so on, then an individual project is
> ok. I think we can benefit from a mailing list and a bugtracker (you
> already have one) but the mailing list can arguably be replaced by mail to
> ma...@packages.qa.debian.org, and the bugtracker will now be the BTS.
>
> What's your opinion? I can do a formal project request if you think it's
> needed. If not, we would go to pkg-games or collab-maint.
Hello !
The git repository is now hosted on Alioth.
I moved the informative bits from shaperstudio to a page in the Debian Wiki:
http://wiki.debian.org/Mame
I propose we use the mam...@googlegroups.com email list until the
ma...@packages.qa.debian.org email becomes available.
For the bugtracker, we can use the BTS as Jordi suggested, or write our
issues/todo on the the wiki page.
@Ludo + Felix: hope to see you soon on Alioth !
In the mean time, you can still push to indefeero , and I will merge
your changes back to Alioth ( in theory git should be good at doing this )
@jordi: should I contact the alioth admins with apologies to delete the
pkg-mame project?
Manu