category, history and nplayers files
Emmanuel Kasper
>> contribute for VGA, either with a shell script or a make file target.
>
> No, but I was talking to mbarnes about this. The MAME package for Fedora
> apparently include the category, history and nplayers files.
>
> Also, I'm not sure on your system, but in mine, the autogenerated mame.ini
> file does not enable OpenGL by default, or multithreading. Unless you're
> somewhat a "power user", these are not easily discoverable options, and we
> should make sure that somehow, they get enabled if they can be enabled.
> Otherwise, MAME is just not usable at all in my Pentium4 @ 3GHz.
>
> What do we do then, should we add these files to the package? I think I
> would.
>
> Jordi
Greets !
I have seen you talking in the mails you sent about a mame-data package,
it seems a good idea !
I was thinking of some script to distribute with gnome-video-arcade to
download these files, but getting them together packaged is even better
! ( If you allow me here some bikesheding, the resulting package should
be called mame-frontend-data as mame itself uses none of this :)
BTW these files are not distributed with the fedora package cf
http://pkgs.org/fedora-14/rpmfusion-nonfree-updates-testing-i386/mame-0.142-1.fc14.i686.rpm.html
Concerning Mame and performance issues, I will add performance tips in
the Debian Readme ( OpenGL is already mentionned there), I would prefer
not to change the upstream default options. Would that be OK to you ?
On a PowerPC mac mini I got the same situation as you: without OpenGL
and Hardware Rendering I could not use mame.
Mame 0.142 has been released, I have seen it compiles fine with the
default gcc-4.5 in sid, I have now to sort out the copyrights of the 150
or so files added to the archive since 0.141 for DEP-5
Thank you for asking the build admins to trigger the compilation of mame
on all supported architectures. I am curious to see how it builds on s390 :)
Manu
Jordi Mallach
> I have seen you talking in the mails you sent about a mame-data package,
> it seems a good idea !
Yeah, we need to make it easy to have MAME up and running with all the
cool stuff. A package like this will help a lot.
How important is mameinfo.dat? If anyone has good contacts in the MAME
community, it'd be cool if they could talk to this guy to explain a
license is nothing evil. :(
> I was thinking of some script to distribute with gnome-video-arcade to
> download these files, but getting them together packaged is even better
> ! ( If you allow me here some bikesheding, the resulting package should
> be called mame-frontend-data as mame itself uses none of this :)
I was thinking making it mame-data was good at least to share the package
name with Fedora.
>
> BTW these files are not distributed with the fedora package cf
> http://pkgs.org/fedora-14/rpmfusion-nonfree-updates-testing-i386/mame-0.142-1.fc14.i686.rpm.html
it's mame-data.
> Concerning Mame and performance issues, I will add performance tips in
> the Debian Readme ( OpenGL is already mentionned there), I would prefer
> not to change the upstream default options. Would that be OK to you ?
> On a PowerPC mac mini I got the same situation as you: without OpenGL
> and Hardware Rendering I could not use mame.
Changing upstream defaults is something Debian does all the time, and even
more if it makes the package work better for a majority.
I'm not sure what CPU is needed to make MAME with a software renderer not
suck, but even if my computer is not the newest out there, well, this is
just an emulator of machines created 20 or 30 years ago, and it crawls.
FWIW, the RPM does default to OpenGL, and I think it's a good idea.
There are *horrible* defaults in the generated ini:
rompath roms;/usr/share/games/mame/roms
samplepath samples;/usr/share/games/mame/samples
artpath artwork;/usr/share/games/mame/artwork
ctrlrpath ctrlr;/usr/share/games/mame/ctrlr
inipath $HOME/.mame;/etc/mame
fontpath .
cheatpath cheat;/usr/share/games/mame/cheat
crosshairpath crosshair
I'm sure defaulting first to paths relative to the current dir was a good
idea in 1993, but I don't think it is a sane default these days.
I think that should more like this:
rompath $/HOME/roms;/usr/share/games/mame/roms
or
rompath $/HOME/.mame/roms;/usr/share/games/mame/roms
or even
rompath /usr/share/games/mame/roms
(which can be overriden in $/HOME/mame/mame.ini)
but that's my opinion. :)
For instance, here's the static config the RPM is shipping:
# Define multi-user paths
artpath /usr/share/mame/artwork;/usr/share/mame/effects
ctrlrpath /usr/share/mame/ctrlr
fontpath /usr/share/mame/fonts
rompath /usr/share/mame/roms;/usr/share/mame/chds
samplepath /usr/share/mame/samples
cheatpath /usr/share/mame/cheats
# Allow user to override ini settings
inipath $HOME/.mame/ini;/etc/mame
# Set paths for local storage
cfg_directory $HOME/.mame/cfg
comment_directory $HOME/.mame/comments
diff_directory $HOME/.mame/diff
input_directory $HOME/.mame/inp
memcard_directory $HOME/.mame/memcard
nvram_directory $HOME/.mame/nvram
snapshot_directory $HOME/.mame/snap
state_directory $HOME/.mame/sta
# Fedora custom defaults
video opengl
autosave 1
joystick 1
*I* would try to get something in this direction: omit default values and
just add entries for those defaults that change, and make mame.ini a
proper dpkg conffile. We can, if needed, autogenerate a full mame.ini
after the build and stick it in /usr/share/doc/mame/examples if needed.
Anyways, what do you think about this? I have a quite strong opinion on
default configurations that should work for most of the people, and the
reality seems to be that MAME is apparently too slow to be good for
anything without opengl video.
Also, the current handling of mame.ini seems a bit crippled: it avoids
any kind of correct conffile handling (ie either shipping a static
mame.ini as I propose, or using ucf to handle the changes): right now, the
first time you install mame you get a configuration file and if a newer
mame version comes along and changes any default, or adds more options,
you won't see this reflected in any way as the postinst script won't do
anything if the file exists already.
I think we need to debate this before our first upload to unstable, which
hopefully we can do for 0.142-1?
> Mame 0.142 has been released, I have seen it compiles fine with the
> default gcc-4.5 in sid, I have now to sort out the copyrights of the 150
> or so files added to the archive since 0.141 for DEP-5.
Yikes, sounds like a hell of a job! :/
> Thank you for asking the build admins to trigger the compilation of mame
> on all supported architectures. I am curious to see how it builds on s390 :)
Well, it doesn't. :)
Compiling src/osd/sdl/sdlwork.c...
src/osd/sdl/sdlwork.c: In function 'int osd_work_queue_wait(osd_work_queue*, osd_ticks_t)':
src/osd/sdl/sdlwork.c:281: error: 'osd_yield_processor' was not declared in this scope
src/osd/sdl/sdlwork.c: In function 'int osd_work_item_wait(osd_work_item*, osd_ticks_t)':
src/osd/sdl/sdlwork.c:516: error: 'osd_yield_processor' was not declared in this scope
src/osd/sdl/sdlwork.c: In function 'void* worker_thread_entry(void*)':
src/osd/sdl/sdlwork.c:666: error: 'osd_yield_processor' was not declared in this scope
make[2]: *** [obj/sdl/mame/osd/sdl/sdlwork.o] Error 1
https://buildd.debian.org/status/package.php?p=mame&suite=experimental
powerpc has also failed, as did kfreebsd-*. I'll ask the kfreebsd people
to see if they can have a look.
Next on my TODO: the Great Discussion on Git repository usage: to have the
full source, or not, that is the question.
Jordi
--
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/
Ludo
Jordi Mallach
> About the mame.ini file, I would not recommend to ship a custom one because
> the content is changing regularly, we could lost some important
> configurations directive.
If the configuration lacks a configuration directive, mame will just use
the default value: that's better than the current way of handling it
(where the config is generated once, and will never change after that).
> So during installation process, the package
> actually creates a new one and changes default *horrible* values :-)
Yeah, I see it does change some things. It should, at least, change more
of them. :)
> Or maybe I have misunderstood and your question was about a ini file
> created when the package is build? This would be a good solution, then
> the dpkg process would ask the user if he wants to replace it's existing
> old ini.
If we want to keep the looooong autogenerated mame.ini file with all the
possible values, what you say is the easiest way to get it handled by
dpkg, so it can be upgraded in a sane way.
I see two sane alternatives:
1) Ludo's suggestion above: mame.ini is autogenerated after the binary is
built and the result is transformed and then installed as a conffile.
No postinst magic happening at all.
2) Jordi's approach to just ship a minimal config. All values that don't
need to be modified are omitted and mame will just use the defaults.
An autogenerated mame.ini is installed with the docs for reference.
Evidently I favour the second because I don't see the value of a 267 line
long configuration file with options nobody is ever going to modify, but
as I'm very late to this game, I'm very happy to take whatever the rest of
the team wants. :)
> Default path for ini is set to /etc/mame but it must be overrided by
> $HOME/.mame (as ini is historically in this folder).
This is ok.
> $HOME/mame folder is used for user specific data like roms, samples,
> artwork, ctrlr, cheat and crosshair. I think it's a good place, easy to
> find and it avoids roms or artworks directly in the user folder.
Is it? Not in my system:
rompath roms;/usr/share/games/mame/roms
samplepath samples;/usr/share/games/mame/samples
artpath artwork;/usr/share/games/mame/artwork
ctrlrpath ctrlr;/usr/share/games/mame/ctrlr
inipath $HOME/.mame;/etc/mame
fontpath .
cheatpath cheat;/usr/share/games/mame/cheat
crosshairpath crosshair
I agree ~/mame would be a good base directory. $PWD isn't!
> Folders created dynamically by MAME during a game are stored in
> /var/games/mame (cfg, nvram, memcard, inp, sta, snap, diff and
> comments). It's a good place IMHO.
But the $PWD dirs have precedence, right?
Ie,
# CORE OUTPUT DIRECTORY OPTIONS
#
cfg_directory cfg;/var/games/mame/cfg
nvram_directory nvram;/var/games/mame/nvram
memcard_directory memcard;/var/games/mame/memcard
input_directory inp;/var/games/mame/inp
state_directory sta;/var/games/mame/sta
snapshot_directory snap;/var/games/mame/snap
diff_directory diff;/var/games/mame/diff
comment_directory comments;/var/games/mame/comments
In my homedir, I see I have a "cfg" dir with configs for the games I have
used. In my eyes, and according to what you say, this should be:
cfg_directory $HOME/mame/cfg;/var/games/mame/cfg
> Providing defaults sets of ini files in /usr/share is a good idea! We
> could set one for very basic configurations and another with hardware
> acceleration. But I would really like to avoid crashes when MAME starts.
Ah, crashes. I didn't know this! :)
> About "joystick" var, a fresh install of MAME on a PC last
> week<http://wiki.ludomatic.fr/DebianMameCab>gave me annoying thing: the
> cursor was stuck in the top left corner because joystick was set to "1"
> but there was not any joystick or any controller except my mouse plugged
> in. I've set "joystick" to "0" and it worked fine. Again during this
> install, setting video to OpenGL crashed MAME. Nothing launched at all
> because I didn't have any graphic acceleration available on the board
> (i386 VIA microATX). Setting "video" to "soft" was the only manner to
> launch MAME, and lots of games works fine now. So I would not be very
> positive to set OpenGL in the ini shipped by default as all
> configurations without graphic acceleration will certainly not launch
> MAME at all if OpenGL is set. Instead, we could tell the user how to
> tweak it's conf to speed up MAME like OpenGL and frameskip if available
> (and offer sets of ini files in usr/share).
Ideally, MAME would test if OpenGL is available when starting up and then
switch to using that. That could be called "video auto"...
That can't be so hard to implement.
I'll ask the Fedora people how's their experience with the opengl default.
I agree that if it crashes when there's a problem with OpenGL, we should
use the conservative option, even if it sucks.
> BTW, do you have already seen this package? it's 0.142!
> http://debian-multimedia.org/dists/unstable/main/binary-i386/package/sdlmame.php
> http://debian-multimedia.org/dists/unstable/main/binary-i386/package/sdlmame-tools.php
*shrug*, there's no need for them anymore! ;)
FWIW, I plan to make an official backport of MAME for squeeze (maybe even
lenny!) once we have the config stuff sorted out.
> PS: Really exciting to see package in Debian autobuild process, after
> many many many hours trying to get something with pbuilder/qemu! Next
> step is working builds ;-)
If you need help to setup cowbuilder, just ask. cowbuilder is how I build
the official mame packages, and it's really easy to use.
Ludo
I see two sane alternatives:
1) Ludo's suggestion above: mame.ini is autogenerated after the binary is
built and the result is transformed and then installed as a conffile.
No postinst magic happening at all.
2) Jordi's approach to just ship a minimal config. All values that don't
need to be modified are omitted and mame will just use the defaults.
An autogenerated mame.ini is installed with the docs for reference.
Evidently I favour the second because I don't see the value of a 267 line
long configuration file with options nobody is ever going to modify, but
as I'm very late to this game, I'm very happy to take whatever the rest of
the team wants. :)
> $HOME/mame folder is used for user specific data like roms, samples,Is it? Not in my system:
> artwork, ctrlr, cheat and crosshair. I think it's a good place, easy to
> find and it avoids roms or artworks directly in the user folder.
I agree ~/mame would be a good base directory. $PWD isn't!
rompath roms;/usr/share/games/mame/roms
samplepath samples;/usr/share/games/mame/samples
artpath artwork;/usr/share/games/mame/artwork
ctrlrpath ctrlr;/usr/share/games/mame/ctrlr
inipath $HOME/.mame;/etc/mame
fontpath .
cheatpath cheat;/usr/share/games/mame/cheat
crosshairpath crosshair
> Folders created dynamically by MAME during a game are stored inBut the $PWD dirs have precedence, right?
> /var/games/mame (cfg, nvram, memcard, inp, sta, snap, diff and
> comments). It's a good place IMHO.
Ie,
# CORE OUTPUT DIRECTORY OPTIONS
#
cfg_directory cfg;/var/games/mame/cfg
nvram_directory nvram;/var/games/mame/nvram
memcard_directory memcard;/var/games/mame/memcard
input_directory inp;/var/games/mame/inp
state_directory sta;/var/games/mame/sta
snapshot_directory snap;/var/games/mame/snap
diff_directory diff;/var/games/mame/diff
comment_directory comments;/var/games/mame/comments
In my homedir, I see I have a "cfg" dir with configs for the games I have
used. In my eyes, and according to what you say, this should be:
cfg_directory $HOME/mame/cfg;/var/games/mame/cfg
> BTW, do you have already seen this package? it's 0.142!*shrug*, there's no need for them anymore! ;)
> http://debian-multimedia.org/dists/unstable/main/binary-i386/package/sdlmame.php
> http://debian-multimedia.org/dists/unstable/main/binary-i386/package/sdlmame-tools.php
FWIW, I plan to make an official backport of MAME for squeeze (maybe even
lenny!) once we have the config stuff sorted out.
> PS: Really exciting to see package in Debian autobuild process, afterIf you need help to setup cowbuilder, just ask. cowbuilder is how I build
> many many many hours trying to get something with pbuilder/qemu! Next
> step is working builds ;-)
the official mame packages, and it's really easy to use.
Félix Arreola Rodríguez
El mié, 06-04-2011 a las 13:27 +1100, Ludo escribió:
>
> Yes, it should be like "$HOME/mame/roms;/usr/share/games/mame/roms"
>
> I've talked about /var/games/mame/ as default place but in a
> multi-user environment, it's better to save each generated data on
> ~/mame/ so let's use "$HOME/mame/cfg;/var/games/mame/cfg" as
> suggested.
>
>
> --
> Ludo.
>
>
I have a question about $HOME/mame, why we can't use $HOME/.mame?
I suggest this to keep mame things hidden in the home user. In this way,
the home user could be more "ordered".
Obviously, we should explain this in the Debian README.
--
Atte. Félix Arreola Rodríguez,
Firmado con GPG, llave 1E249EE4
Ludo
I have a question about $HOME/mame, why we can't use $HOME/.mame?
I suggest this to keep mame things hidden in the home user. In this way,
the home user could be more "ordered".
Obviously, we should explain this in the Debian README.
Emmanuel Kasper
>> artwork, ctrlr, cheat and crosshair. I think it's a good place, easy to
>> find and it avoids roms or artworks directly in the user folder.
>
> Is it? Not in my system:
>
I think you might have an old auto-generated mame.ini. If you purge the
package and reinstall it, default core search paths should be something
like
$HOME/mame/my_whatever;/usr/share/mame/my_whatever
and core output folders ( like snap or save ) should be
$HOME/.mame/my_mame_generated_stuff
I think the postinst script was modified in this way a couple of months ago.
But this points out the pb that during the first package installation a
mame.ini is generated, which is afterwards left in place during every
following package upgrade !
Emmanuel Kasper
Greets everyone !
Le 06/04/2011 04:27, Ludo a écrit :
> Hi,
>
> I see two sane alternatives:
>>
>> 1) Ludo's suggestion above: mame.ini is autogenerated after the binary is
>> built and the result is transformed and then installed as a conffile.
>> No postinst magic happening at all.
>>
>> 2) Jordi's approach to just ship a minimal config. All values that don't
>> need to be modified are omitted and mame will just use the defaults.
>> An autogenerated mame.ini is installed with the docs for reference.
>>
>> Evidently I favour the second because I don't see the value of a 267 line
>> long configuration file with options nobody is ever going to modify, but
>> as I'm very late to this game, I'm very happy to take whatever the rest of
>> the team wants. :)
>>
>
> I don't see anything that would avoid us to use the second option, I think
> it's a good idea if the ini is verified on each update to check the
> consistency of our options and the default ones (so we don't use old options
> or forget new ones on a new version).
>
I also favour the second option, on the ground that it would facilitate
the user's work on package upgrade.
If we have only 15 options in /etc/mame/mame.ini, in case we have change
something there it will be much easier for the user to diff the changes
between the maintainer provided config file and his own customizations.
For this to work we shoud:
* move out our debian specific options to a minimal mame.ini
* install that file during package installation
I have seen when a conf file is provided by a package, and has been
modified, during an upgrade it spits somehting like:
<code>
This package has a new configuration file. Would you like to keep your
locally modified version or install the package maintainer's version ?
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situatio
</code>
Does it comes for free with dpkg, or do we have to configure something
special to get that dialogue during a package upgrade ?
Manu
Emmanuel Kasper
> BTW, do you have already seen this package? it's 0.142!
> http://debian-multimedia.org/dists/unstable/main/binary-i386/package/sdlmame.php
> http://debian-multimedia.org/dists/unstable/main/binary-i386/package/sdlmame-tools.php
>
> PS: Really exciting to see package in Debian autobuild process, after many
> many many hours trying to get something with pbuilder/qemu! Next step is
> working builds ;-)
> --
> Ludo.
>
I downloaded this package to have a look and the developper behinds
looks familiar ^_^
The Debian packaging is (c) 2007-08 Ludovic Lechapt
<ludo...@gmail.com> and is
licensed under the GPL, see '/usr/share/common-licenses/GPL'.
so Ludo it looks like a fork from your old sdlmame package from two
years ago:
sdlmame (0.131-0.0) unstable; urgency=low
* New upstream release.
* Initial upload to debian-multimedia.org
-- Christian Marillat <mari...@debian.org> Mon, 27 Apr 2009 14:28:13
+0200
One thing we should pick from there is the support for gnu/kfreebsd:
in debian/rules
ifeq ($(DEBIAN_ARCH),kfreebsd-i386)
SDLMAME_OPTS += \
TARGETOS=freebsd
endif
ifeq ($(DEBIAN_ARCH),kfreebsd-amd64)
SDLMAME_OPTS += \
PTR64=1 \
SUFFIX64= \
TARGETOS=freebsd
endif
This looks right as the mame makefile defaults to a freebsd target when
it detects a gnu/kFreeBSD system with uname.
I will be on holyday the next three weeks, I don't think I will have
much time or internet connection to work on the package.
Greets !
Manu
Jordi Mallach
> >> 2) Jordi's approach to just ship a minimal config. All values that don't
> >> need to be modified are omitted and mame will just use the defaults.
> >> An autogenerated mame.ini is installed with the docs for reference.
> >> Evidently I favour the second because I don't see the value of a 267 line
> >> long configuration file with options nobody is ever going to modify, but
> >> as I'm very late to this game, I'm very happy to take whatever the rest of
> >> the team wants. :)
> > I don't see anything that would avoid us to use the second option, I think
> > it's a good idea if the ini is verified on each update to check the
> > consistency of our options and the default ones (so we don't use old options
> > or forget new ones on a new version).
> I also favour the second option, on the ground that it would facilitate
> the user's work on package upgrade.
> If we have only 15 options in /etc/mame/mame.ini, in case we have change
> something there it will be much easier for the user to diff the changes
> between the maintainer provided config file and his own customizations.
Yay, cool!
> For this to work we shoud:
> * move out our debian specific options to a minimal mame.ini
> * install that file during package installation
I can take care of this.
> I have seen when a conf file is provided by a package, and has been
> modified, during an upgrade it spits somehting like:
>
> <code>
> This package has a new configuration file. Would you like to keep your
> locally modified version or install the package maintainer's version ?
>
> Y or I : install the package maintainer's version
> N or O : keep your currently-installed version
> D : show the differences between the versions
> Z : background this process to examine the situatio
> </code>
>
> Does it comes for free with dpkg, or do we have to configure something
> special to get that dialogue during a package upgrade ?
This is standard dpkg functionality for files in /etc marked as conffiles.
Debhelper marks all files in etc as conffiles automatically, so it'll be
easy to do.
I'll do this tomorrow.
Jordi Mallach
> I don't see anything that would avoid us to use the second option, I think
> it's a good idea if the ini is verified on each update to check the
> consistency of our options and the default ones (so we don't use old options
> or forget new ones on a new version).
Ok then; as I said before I'll work on this as soon as I can. Not today,
as I have to finish an assignment! :)
> Yes, it should be like "$HOME/mame/roms;/usr/share/games/mame/roms"
We'll hardcode this in the "option 2 config".
> I've talked about /var/games/mame/ as default place but in a multi-user
> environment, it's better to save each generated data on ~/mame/ so let's use
> "$HOME/mame/cfg;/var/games/mame/cfg" as suggested.
Yeah, there's no way to tell if a Debian box is used by one or many. It'd
be nice to share highscores and so on with other users in the system, but
that would probably make it necessary to make MAME suid games or something
like this, so it's not recommended.
The question is, when you have
$HOME/mame/cfg;/var/games/mame/cfg
do you ever get the chance to write anything in /var/games/mame/cfg? Does
a normal user have permission to write in there? It shouldn't, I guess?
If it can't, why should we list it?
> > FWIW, I plan to make an official backport of MAME for squeeze (maybe even
> > lenny!) once we have the config stuff sorted out.
> Excellent! What's the process to have MAME in Backport ?
When we upload MAME to unstable, it'll enter testing after a few days.
When this happens, we can just recompile it in a squeeze chroot or lenny
chroot, adding +bpo60 to the debian revision number, and upload it to a
special backports queue of the Debian archive. Once the backports team
verifies the package is correctly signed and based on a package from
wheezy, it'll be accepted and will automatically be available from
backports.debian.org.
> > If you need help to setup cowbuilder, just ask. cowbuilder is how I build
> > the official mame packages, and it's really easy to use.
> I would really like. I currently use a "home" script and many tweaks but I
> think the process could be a bit less fastidious. Do you have up-to-date
> links or usable howtos ?
Ok, cowbuilder is a piece of cake.
Let's create a chroot where you can compile packages for debian unstable:
$ sudo apt-get install cowbuilder
$ sudo cowbuilder --create
(After debootstrap, you'll be left with a full Debian system in
/var/cache/pbuilder/base.cow.)
If you want to create a squeeze chroot, to prepare packages for backports,
for example, you'll just add:
$ sudo cowbuilder --create --distribution squeeze --basepath /var/cache/pbuilder/squeezebase.cow
base.cow is just a chroot directory. You can alter anything in your chroot
by editing the files with your editor. If you want to be able to install
build-dependencies from experimental, just edit
/var/cache/pbuilder/base.cow/etc/apt/sources.list to add the required line.
Now, here's where the fun starts.
Let's try out the new chroot:
$ cowbuilder --login
This will create a temporary copy of base.cow and execute a shell in it.
Now you're inside your sid chroot and can do any test you want. When you
exit your session, the chroot will be deleted and base.cow will be
unmodified.
If you want to save any change you do to your base.cow during a login (say
you want to install vim in it), use the --save-after-login option:
$ cowbuilder --login --save-after-login
Finally, the important step: integration with pbuilder:
Add this to your normal user's ~/.pbuilderrc:
-------------------------------------------------------------------------------
PDEBUILD_PBUILDER="cowbuilder"
PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-aptitude"
EXTRAPACKAGES="eatmydata"
if [ -z "$LD_PRELOAD" ]; then
LD_PRELOAD=/usr/lib/libeatmydata/libeatmydata.so
else
LD_PRELOAD="$LD_PRELOAD":/usr/lib/libeatmydata/libeatmydata.so
fi
export LD_PRELOAD
-------------------------------------------------------------------------------
Now, let's build a package in a clean chroot.
dpkg-source -x mame_1.141-2.dsc
cd mame-1.141
pdebuild
This will ask for our sudo password, and will start a build. If it
succeeds, the resulting packages will be in /var/cache/pbuilder/result.
That are the basics -- but you can tweak pbuilder more (mirror to use,
etc.) -- see /etc/pbuilderrc.
Hope that helps!
Jordi
--
Jordi Mallach P�rez -- Debian developer http://www.debian.org/
Jordi Mallach
> We talked about ".mame" for configuration files, and others that the
> end-user does not need to know about in a ordinary usage. The "mame.ini"
> would stay here like others previous MAME package do.
> Everything else (like roms or titles artworks) that the user will
> save/manage by himself can be set in "mame", a folder that he will find
> easily with console tools or GUI file explorers.
I'm with F�lix in that I don't like having yet another dir in my home.
It's enough with these "Documents Music Pictures Desktop" and so on... ;)
But I agree a dotdir is probably not the best place to put data like ROMs
or artwork. I'm not sure what's the best choice here. :(
Jordi
--
Jordi Mallach P�rez -- Debian developer http://www.debian.org/
Jordi Mallach
> I think you might have an old auto-generated mame.ini. If you purge the
> package and reinstall it, default core search paths should be something
> like
>
> $HOME/mame/my_whatever;/usr/share/mame/my_whatever
>
> and core output folders ( like snap or save ) should be
>
> $HOME/.mame/my_mame_generated_stuff
Yeah, I see the new postinst does that. Sorry about the confusion!
> But this points out the pb that during the first package installation a
> mame.ini is generated, which is afterwards left in place during every
> following package upgrade !
Yeah, that's why I proposed two alternatives that would handle it. It
seems we're reaching an agreement for the second one.
Jordi
--
Jordi Mallach P�rez -- Debian developer http://www.debian.org/
Jordi Mallach
> ifeq ($(DEBIAN_ARCH),kfreebsd-i386)
> SDLMAME_OPTS += \
> TARGETOS=freebsd
> endif
As far as I can tell, the normal makefile already should detect this:
ifeq ($(firstword $(filter GNU/kFreeBSD,$(UNAME))),GNU/kFreeBSD)
TARGETOS = freebsd
endif
but of course needs to be overriden as debian/rules sets "unix" globally.
Why is this, if the makefile appears to detect it?
> This looks right as the mame makefile defaults to a freebsd target when
> it detects a gnu/kFreeBSD system with uname.
Ah, yeah. I have no idea of how to handle the rest of options, though.
We need config snippets for many other architectures but I have no idea of
how to tweak them.
> I will be on holyday the next three weeks, I don't think I will have
> much time or internet connection to work on the package.
Ok. Will you be able to finish your work on debian/copyright so we can
upload the new version?
At least, maybe you could commit whatever you have done until now.
Happy holidays!
Jordi
--
Jordi Mallach P�rez -- Debian developer http://www.debian.org/
Emmanuel Kasper
> On Wed, Apr 06, 2011 at 02:55:32PM +1100, Ludo wrote:
>> We talked about ".mame" for configuration files, and others that the
>> end-user does not need to know about in a ordinary usage. The "mame.ini"
>> would stay here like others previous MAME package do.
>> Everything else (like roms or titles artworks) that the user will
>> save/manage by himself can be set in "mame", a folder that he will find
>> easily with console tools or GUI file explorers.
>
> It's enough with these "Documents Music Pictures Desktop" and so on... ;)
>
> But I agree a dotdir is probably not the best place to put data like ROMs
> or artwork. I'm not sure what's the best choice here. :(
If I can bikeshed, I would prefer that we keep the core search path ( as
mame calls them on ) as it is now in $HOME/mame. It is not nice to have
your $HOME polluted by various aplications but hiding a couple of Gig of
roms in a dot directory is worse IMHO.
For the rest I am all the way for staying in $HOME instead of
/var/games, I can't think of any mame variable data files that different
users would use.
I've put in debian/rules the build flags for k/freebsd, looking at the
build logs I have good hope it would fix the problem, as the build
process looks for a function defined in a linux specific header (openpty
are defined at different places on Linux and FreeBSD )
Funnily enough for mame unix=linux and the other unices around need
specific make targets :)
In the long term debian/rules would need also a bit of clean up, we
override here completely mame's autodetection scheme, which means we
need to be very verbose for each architecture.
Greets
Manu
Félix Arreola Rodríguez
package /var/games/mame/* was writable by normal users that owns to
group "Games". I recommed to keep hiscores shared among all users.
Also, about putting roms in a hidden directory, I don't like it, but we
could suggest put them in /usr/share/games/mame/roms (to keep the
"shared mode") and also inform the user about ~/.mame/roms
So the paths should be:
roms=$HOME/.mame/roms;/usr/share/games/mame/roms
saves=/var/games/mame/saves
(I don't remember the name of saved games)
Ludo
Jordi Mallach
> Thanks for the tips! The process is very similar to the one I use with
> a simple script managing pbuilder [ http://wiki.ludomatic.fr/Pbuilder ]
> with the exception that cowbuilder starts chroot much faster!!
Not only that: if you care about the health of your hard drive, cowbuilder
is for you. Cowbuilder just creates hardlinks of the base.cow, while
pbuilder unpacks real files (ie, does real writes in disk) from the tar.gz.
Avoid pbuilder. :)
> Also I have "ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so'
> from LD_PRELOAD cannot be preloaded: ignored." when loggin in the
> chrooted environment. I think I have to install the package "eatmydata"
> on the chroot. Thanks again for the memo about cowbuilder, very useful.
Yes. And once you do, you'll be in awe at how fast dpkg will work.
--
Jordi Mallach P�rez -- Debian developer http://www.debian.org/