From mr.ecik at gmail.com Mon Jan 1 00:50:09 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Mon, 1 Jan 2007 01:50:09 +0100 Subject: OpenArena/ioquake3 In-Reply-To: <20061231201728.GA30636@osiris.silug.org> References: <20061231201728.GA30636@osiris.silug.org> Message-ID: <668bb39a0612311650n230fd89bo87a7ffdf6c069bee@mail.gmail.com> I am interested in packaging this. Should be available within a few days. 2006/12/31, Steven Pritchard : > Is anyone working on OpenArena (http://openarena.ws/) or ioquake3 > (http://ioquake3.org/)? > > FreshRPMS has a package for ioquake3 at > http://zod.freshrpms.net/rpm.html?id=391, and I haven't looked closely > at it yet, but there's a package for ioquake3 at > ftp://ftp.suse.com/pub/people/lnussel/quake3/src/ that might also be > useful. > > There's a Mandriva package for OpenArena (search for it on > rpmfind.net), but that's all I've been able to find so far. > > Steve > -- > Steven Pritchard - K&S Pritchard Enterprises, Inc. > Email: steve at kspei.com http://www.kspei.com/ > Phone: (618)398-3000 Mobile: (618)567-7320 > > _______________________________________________ > Fedora-games-list mailing list > Fedora-games-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-games-list > -- Micha? Bentkowski mr.ecik at gmail.com From j.w.r.degoede at hhs.nl Mon Jan 8 08:09:55 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 08 Jan 2007 09:09:55 +0100 Subject: Gnometris In-Reply-To: <4594C3C8.302@nicubunu.ro> References: <4594C3C8.302@nicubunu.ro> Message-ID: <45A1FC53.2080407@hhs.nl> Nicu Buculei wrote: > There is a talk on GNOME Games about Fedora not including Gnometris for > some undisclosed legal issues: > http://mail.gnome.org/archives/games-list/2006-December/msg00043.html > > There are two specific questions: > - what are the specific copyright/trademark problems? The name is too close to tetris which is a strongly defended trademark. > - what can be done so Fedora is able to include the game (or at least > another Tetris clone)? > There already is a tetris clone in Fedora Extras: fbg (falling block game), what can be done is change the name and remove all references to tetris from the docs. I've done the same for crack attack (remove all references to tetris from the docs) Thanks & Regards, Hans From nicu_fedora at nicubunu.ro Mon Jan 8 09:59:03 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Mon, 08 Jan 2007 11:59:03 +0200 Subject: Gnometris In-Reply-To: <45A1FC53.2080407@hhs.nl> References: <4594C3C8.302@nicubunu.ro> <45A1FC53.2080407@hhs.nl> Message-ID: <45A215E7.80304@nicubunu.ro> Hans de Goede wrote: > Nicu Buculei wrote: >> There is a talk on GNOME Games about Fedora not including Gnometris >> for some undisclosed legal issues: >> http://mail.gnome.org/archives/games-list/2006-December/msg00043.html >> >> There are two specific questions: >> - what are the specific copyright/trademark problems? > The name is too close to tetris which is a strongly defended trademark. I am not sure, in this bugzilla entry https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=148883 Havoc says "All Tetris clones are illegal, unfortunately. Nothing we can do about it.", which seems very strong and nor related to the name. If the name was the only problem, it seems the GNOME people are disposed to change the name. >> - what can be done so Fedora is able to include the game (or at least >> another Tetris clone)? >> > > There already is a tetris clone in Fedora Extras: fbg (falling block I know about the Core and Extras being merged, but Gnometris is a base GNOME module, so a matter of Core or default desktop install (along with the rest of GNOME Games) > game), what can be done is change the name and remove all references to > tetris from the docs. I've done the same for crack attack (remove all > references to tetris from the docs) See above: default desktop install. Red Hat goes to extra measure to remove a default GNOME component, so it should be something more. Crack Attack is very different as playing style than Tetris, is an entirely new game. -- nicu Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From j.w.r.degoede at hhs.nl Mon Jan 8 10:16:48 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 08 Jan 2007 11:16:48 +0100 Subject: savage In-Reply-To: <459061DD.1020004@flummiball.de> References: <459061DD.1020004@flummiball.de> Message-ID: <45A21A10.4080509@hhs.nl> Jonas G wrote: > Hi! > Did you know that Savage(http://www.s2games.com/savage/index.php) became > freeware? I'm going to install it on my fedora... > freeware != free software, so it cannot go into fedora. Maybe it can go into livna, care to volunteer packaging it for livna? Regards, Hans From j.w.r.degoede at hhs.nl Mon Jan 8 10:31:38 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 08 Jan 2007 11:31:38 +0100 Subject: Gnometris In-Reply-To: <45A215E7.80304@nicubunu.ro> References: <4594C3C8.302@nicubunu.ro> <45A1FC53.2080407@hhs.nl> <45A215E7.80304@nicubunu.ro> Message-ID: <45A21D8A.9080800@hhs.nl> Nicu Buculei wrote: > Hans de Goede wrote: >> Nicu Buculei wrote: >>> There is a talk on GNOME Games about Fedora not including Gnometris >>> for some undisclosed legal issues: >>> http://mail.gnome.org/archives/games-list/2006-December/msg00043.html >>> >>> There are two specific questions: >>> - what are the specific copyright/trademark problems? >> The name is too close to tetris which is a strongly defended trademark. > > I am not sure, in this bugzilla entry > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=148883 Havoc says > "All Tetris clones are illegal, unfortunately. Nothing we can do about > it.", which seems very strong and nor related to the name. > > If the name was the only problem, it seems the GNOME people are disposed > to change the name. > That really is the only problem, with fbg and crack attack there has been discussion about this and although some people would rather not have any tetris clones in Fedora as the tetris trademark owners are rather trigger happy with lawsuits, it was decided that a trigger happy trademark owner is not a good reason to keep anything out of Fedora as long as it doesn't violate the trademark. Thus if the trademark issue is resolved gnometris really should be fine, although it will probably still need some discussion then as, as said already, some people would rather avoid tetris clones to be 100.1% safe. >> game), what can be done is change the name and remove all references >> to tetris from the docs. I've done the same for crack attack (remove >> all references to tetris from the docs) > > See above: default desktop install. Red Hat goes to extra measure to > remove a default GNOME component, so it should be something more. > Something more? TM infringement is more then enough to remove something! > Crack Attack is very different as playing style than Tetris, is an > entirely new game. > Yes but crack attack is inspired by tetris attack and had some references ti this in the docs, so we once again hit the tetris TM. Regards, Hans From j.w.r.degoede at hhs.nl Mon Jan 8 10:33:09 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 08 Jan 2007 11:33:09 +0100 Subject: OpenArena/ioquake3 In-Reply-To: <668bb39a0612311650n230fd89bo87a7ffdf6c069bee@mail.gmail.com> References: <20061231201728.GA30636@osiris.silug.org> <668bb39a0612311650n230fd89bo87a7ffdf6c069bee@mail.gmail.com> Message-ID: <45A21DE5.1060205@hhs.nl> Micha? Bentkowski wrote: > I am interested in packaging this. Should be available within a few days. > Let us now the bugzilla ticket for the review, then maybe one of us can do the review. Regards, Hans From seg at haxxed.com Mon Jan 8 15:09:08 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 08 Jan 2007 09:09:08 -0600 Subject: Second Life client source released GPL! Message-ID: <1168268949.7408.4.camel@max.booze> Way sooner than I ever imagined, the Second Life client has been released under GPLv2 license. Though it has the usual "still needs some proprietary third party libs" strings attached. Namely fmod. I'm working on building it right now. See: http://secondlife.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lemenkov at gmail.com Mon Jan 8 17:39:32 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Mon, 8 Jan 2007 20:39:32 +0300 Subject: Second Life client source released GPL! In-Reply-To: <1168268949.7408.4.camel@max.booze> References: <1168268949.7408.4.camel@max.booze> Message-ID: 2007/1/8, Callum Lerwick : > Way sooner than I ever imagined, the Second Life client has been > released under GPLv2 license. Though it has the usual "still needs some > proprietary third party libs" strings attached. Namely fmod. AFAIK it's the only closed-source lib there. But I've seen mentions about CDDL-licensed matherial (FC-folks afraid of that license). Bad news that there isn't a PowerPC-variant of that blob. > I'm working on building it right now. Good news! -- With best regards! From seg at haxxed.com Mon Jan 8 22:19:30 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 08 Jan 2007 16:19:30 -0600 Subject: Second Life client source released GPL! In-Reply-To: References: <1168268949.7408.4.camel@max.booze> Message-ID: <1168294771.12738.11.camel@localhost.localdomain> On Mon, 2007-01-08 at 20:39 +0300, Peter Lemenkov wrote: > 2007/1/8, Callum Lerwick : > > Way sooner than I ever imagined, the Second Life client has been > > released under GPLv2 license. Though it has the usual "still needs some > > proprietary third party libs" strings attached. Namely fmod. > > AFAIK it's the only closed-source lib there. But I've seen mentions > about CDDL-licensed matherial (FC-folks afraid of that license). Bad > news that there isn't a PowerPC-variant of that blob. Okay, turns out you can build without fmod, you just don't get sound. SL also makes extensive use of JPEG2000 for texture compression, using a proprietary lib. It can be built against OpenJPEG, but supposedly its performance is rather bad. So, we should be able to get SL into Fedora, though it will be rather suboptimal until fmod is replaced with, say, OpenAL, and OpenJPEG gets optimized. Still working on getting it to build. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mr.ecik at gmail.com Tue Jan 9 19:51:56 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Tue, 9 Jan 2007 20:51:56 +0100 Subject: OpenArena/ioquake3 In-Reply-To: <45A21DE5.1060205@hhs.nl> References: <20061231201728.GA30636@osiris.silug.org> <668bb39a0612311650n230fd89bo87a7ffdf6c069bee@mail.gmail.com> <45A21DE5.1060205@hhs.nl> Message-ID: <668bb39a0701091151y5cd72b8dkfcd0b1fdda56b8d0@mail.gmail.com> Package is already reviewed but I'm encountering problems with compiling it on ppc. I don't want to do testing on buildsys, so currently I'm looking for a ppc machine because I found a patch, but I'm not sure it works. 07-01-08, Hans de Goede napisa?(a): > Micha? Bentkowski wrote: > > I am interested in packaging this. Should be available within a few days. > > > > Let us now the bugzilla ticket for the review, then maybe one of us can > do the review. > > Regards, > > Hans > > _______________________________________________ > Fedora-games-list mailing list > Fedora-games-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-games-list > -- Micha? Bentkowski mr.ecik at gmail.com From wayward4now at gmail.com Wed Jan 10 02:20:39 2007 From: wayward4now at gmail.com (Ric Moore) Date: Tue, 09 Jan 2007 21:20:39 -0500 Subject: Second Life client source released GPL! In-Reply-To: <1168294771.12738.11.camel@localhost.localdomain> References: <1168268949.7408.4.camel@max.booze> <1168294771.12738.11.camel@localhost.localdomain> Message-ID: <1168395639.13524.43.camel@iam.wayward4now.net> On Mon, 2007-01-08 at 16:19 -0600, Callum Lerwick wrote: > On Mon, 2007-01-08 at 20:39 +0300, Peter Lemenkov wrote: > > 2007/1/8, Callum Lerwick : > > > Way sooner than I ever imagined, the Second Life client has been > > > released under GPLv2 license. Though it has the usual "still needs some > > > proprietary third party libs" strings attached. Namely fmod. > > > > AFAIK it's the only closed-source lib there. But I've seen mentions > > about CDDL-licensed matherial (FC-folks afraid of that license). Bad > > news that there isn't a PowerPC-variant of that blob. > Speaking of Secondlife, has anyone tried Croquet and Squeak?? Ric -- ================================================ My father, Victor Moore (Vic) used to say: "There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome." R.I.P. Dad. Linux user# 44256 Sign up at: http://counter.li.org/ http://www.sourceforge.net/projects/oar http://www.wayward4now.net ================================================ From lemenkov at gmail.com Wed Jan 10 08:30:07 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Wed, 10 Jan 2007 11:30:07 +0300 Subject: OpenArena/ioquake3 In-Reply-To: <668bb39a0701091151y5cd72b8dkfcd0b1fdda56b8d0@mail.gmail.com> References: <20061231201728.GA30636@osiris.silug.org> <668bb39a0612311650n230fd89bo87a7ffdf6c069bee@mail.gmail.com> <45A21DE5.1060205@hhs.nl> <668bb39a0701091151y5cd72b8dkfcd0b1fdda56b8d0@mail.gmail.com> Message-ID: 2007/1/9, Micha? Bentkowski : > Package is already reviewed but I'm encountering problems with > compiling it on ppc. I don't want to do testing on buildsys, so > currently I'm looking for a ppc machine because I found a patch, but > I'm not sure it works. I've got PowerPC-box and therefore can test whether this patch works. Please provide your SRPM. -- With best regards! From j.w.r.degoede at hhs.nl Wed Jan 10 14:30:40 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 10 Jan 2007 15:30:40 +0100 Subject: Second Life client source released GPL! In-Reply-To: <1168294771.12738.11.camel@localhost.localdomain> References: <1168268949.7408.4.camel@max.booze> <1168294771.12738.11.camel@localhost.localdomain> Message-ID: <45A4F890.70102@hhs.nl> Callum Lerwick wrote: > On Mon, 2007-01-08 at 20:39 +0300, Peter Lemenkov wrote: >> 2007/1/8, Callum Lerwick : >>> Way sooner than I ever imagined, the Second Life client has been >>> released under GPLv2 license. Though it has the usual "still needs some >>> proprietary third party libs" strings attached. Namely fmod. >> AFAIK it's the only closed-source lib there. But I've seen mentions >> about CDDL-licensed matherial (FC-folks afraid of that license). Bad >> news that there isn't a PowerPC-variant of that blob. > > Okay, turns out you can build without fmod, you just don't get sound. SL > also makes extensive use of JPEG2000 for texture compression, using a > proprietary lib. It can be built against OpenJPEG, but supposedly its > performance is rather bad. > > So, we should be able to get SL into Fedora, though it will be rather > suboptimal until fmod is replaced with, say, OpenAL, and OpenJPEG gets > optimized. > Replacing fmod with openAL seems strange, SDL_mixer or mikmod would be much better choices as they are modtrackers too. This shouldn't be too hard. Regards, Hans From mr.ecik at gmail.com Wed Jan 10 18:05:36 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Wed, 10 Jan 2007 19:05:36 +0100 Subject: OpenArena/ioquake3 In-Reply-To: References: <20061231201728.GA30636@osiris.silug.org> <668bb39a0612311650n230fd89bo87a7ffdf6c069bee@mail.gmail.com> <45A21DE5.1060205@hhs.nl> <668bb39a0701091151y5cd72b8dkfcd0b1fdda56b8d0@mail.gmail.com> Message-ID: <668bb39a0701101005p24c75dag2d119586911507e6@mail.gmail.com> 2007/1/10, Peter Lemenkov : > I've got PowerPC-box and therefore can test whether this patch works. > Please provide your SRPM. I realized that this patch couldn't be working. However, after some looking at debian package it seems to me that there's a flag problem. Currently I'm not able to upload new SRPM (connection problems...) so if you really want to test it, you have to add following lines beneath FLAGS: %ifarch ppc FLAGS="$FLAGS -maltivec -DNO_VM_COMPILED" %endif make distclean -C source/ioq3-* -- Micha? Bentkowski mr.ecik at gmail.com From wayward4now at gmail.com Wed Jan 10 19:47:04 2007 From: wayward4now at gmail.com (Ric Moore) Date: Wed, 10 Jan 2007 14:47:04 -0500 Subject: Second Life client source released GPL! In-Reply-To: <45A4F890.70102@hhs.nl> References: <1168268949.7408.4.camel@max.booze> <1168294771.12738.11.camel@localhost.localdomain> <45A4F890.70102@hhs.nl> Message-ID: <1168458424.13524.141.camel@iam.wayward4now.net> On Wed, 2007-01-10 at 15:30 +0100, Hans de Goede wrote: > Callum Lerwick wrote: > > On Mon, 2007-01-08 at 20:39 +0300, Peter Lemenkov wrote: > >> 2007/1/8, Callum Lerwick : > >>> Way sooner than I ever imagined, the Second Life client has been > >>> released under GPLv2 license. Though it has the usual "still needs some > >>> proprietary third party libs" strings attached. Namely fmod. > >> AFAIK it's the only closed-source lib there. But I've seen mentions > >> about CDDL-licensed matherial (FC-folks afraid of that license). Bad > >> news that there isn't a PowerPC-variant of that blob. > > > > Okay, turns out you can build without fmod, you just don't get sound. SL > > also makes extensive use of JPEG2000 for texture compression, using a > > proprietary lib. It can be built against OpenJPEG, but supposedly its > > performance is rather bad. > > > > So, we should be able to get SL into Fedora, though it will be rather > > suboptimal until fmod is replaced with, say, OpenAL, and OpenJPEG gets > > optimized. > > > > Replacing fmod with openAL seems strange, SDL_mixer or mikmod would be > much better choices as they are modtrackers too. This shouldn't be too hard. Both Squeak and Croquet use openal. I beleive that squeak is part of the secondlife server base. Ric -- ================================================ My father, Victor Moore (Vic) used to say: "There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome." R.I.P. Dad. Linux user# 44256 Sign up at: http://counter.li.org/ http://www.sourceforge.net/projects/oar http://www.wayward4now.net ================================================ From seg at haxxed.com Thu Jan 11 04:39:19 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 10 Jan 2007 22:39:19 -0600 Subject: Second Life client source released GPL! In-Reply-To: <45A4F890.70102@hhs.nl> References: <1168268949.7408.4.camel@max.booze> <1168294771.12738.11.camel@localhost.localdomain> <45A4F890.70102@hhs.nl> Message-ID: <1168490360.3984.11.camel@max.booze> On Wed, 2007-01-10 at 15:30 +0100, Hans de Goede wrote: > Replacing fmod with openAL seems strange, SDL_mixer or mikmod would be > much better choices as they are modtrackers too. This shouldn't be too hard. The modplayer in fmod is not used in SL. Its just being used as a 3D audio lib. OpenAL would work well as it's well supported on Windows (Vista apparently killed of DirectSound3D acceleration, leaving Creative's OpenAL implementation as the only hardware accelerated 3D API available in Vista) and OSX, (Apparently an official implementation ships in Tiger.) so fmod could be fully replaced on all platforms. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Thu Jan 11 08:48:29 2007 From: j.w.r.degoede at hhs.nl (Goede, J.W.R. de) Date: Thu, 11 Jan 2007 09:48:29 +0100 Subject: Second Life client source released GPL! In-Reply-To: <1168490360.3984.11.camel@max.booze> References: <1168268949.7408.4.camel@max.booze> <1168294771.12738.11.camel@localhost.localdomain> <45A4F890.70102@hhs.nl> <1168490360.3984.11.camel@max.booze> Message-ID: On Wed, 10 Jan 2007 22:39:19 -0600 Callum Lerwick wrote: > On Wed, 2007-01-10 at 15:30 +0100, Hans de Goede wrote: > > Replacing fmod with openAL seems strange, SDL_mixer or > mikmod would be > > much better choices as they are modtrackers too. This > shouldn't be too hard. > > The modplayer in fmod is not used in SL. Its just being > used as a 3D > audio lib. OpenAL would work well as it's well supported > on Windows > (Vista apparently killed of DirectSound3D acceleration, > leaving > Creative's OpenAL implementation as the only hardware > accelerated 3D API > available in Vista) and OSX, (Apparently an official > implementation > ships in Tiger.) so fmod could be fully replaced on all > platforms. Ah, I see, then OpenAL is indeed a good choice. Regards, Hans From mr.ecik at gmail.com Thu Jan 11 18:17:46 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Thu, 11 Jan 2007 19:17:46 +0100 Subject: OpenArena/ioquake3 In-Reply-To: <668bb39a0701101005p24c75dag2d119586911507e6@mail.gmail.com> References: <20061231201728.GA30636@osiris.silug.org> <668bb39a0612311650n230fd89bo87a7ffdf6c069bee@mail.gmail.com> <45A21DE5.1060205@hhs.nl> <668bb39a0701091151y5cd72b8dkfcd0b1fdda56b8d0@mail.gmail.com> <668bb39a0701101005p24c75dag2d119586911507e6@mail.gmail.com> Message-ID: <668bb39a0701111017m338590a5pc8e657a225c3aec5@mail.gmail.com> Ehh... SRPM URL: http://ecik.nonlogic.org/openarena/openarena-0.6.0-1.src.rpm 07-01-10, Micha? Bentkowski napisa?(a): > 2007/1/10, Peter Lemenkov : > > I've got PowerPC-box and therefore can test whether this patch works. > > Please provide your SRPM. > > I realized that this patch couldn't be working. However, after some > looking at debian package it seems to me that there's a flag problem. > Currently I'm not able to upload new SRPM (connection problems...) so > if you really want to test it, you have to add following lines beneath > FLAGS: > %ifarch ppc > FLAGS="$FLAGS -maltivec -DNO_VM_COMPILED" > %endif > make distclean -C source/ioq3-* > > -- > Micha? Bentkowski > mr.ecik at gmail.com > -- Micha? Bentkowski mr.ecik at gmail.com From nicu_fedora at nicubunu.ro Wed Jan 24 14:30:59 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 24 Jan 2007 16:30:59 +0200 Subject: Lost Labyrinth Message-ID: <45B76DA3.3050107@nicubunu.ro> I just saw a nice looking roguelike GPL game, "Lost Labyrinth": http://www.lostlabyrinth.com/ I added it to the proposals list on the wiki (http://fedoraproject.org/wiki/Extras/SIGs/Games) to be visible if someone want to package it. -- nicu Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From tibbs at math.uh.edu Wed Jan 24 15:42:34 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 24 Jan 2007 09:42:34 -0600 Subject: Lost Labyrinth In-Reply-To: <45B76DA3.3050107@nicubunu.ro> References: <45B76DA3.3050107@nicubunu.ro> Message-ID: >>>>> "NB" == Nicu Buculei writes: NB> I just saw a nice looking roguelike GPL game, "Lost Labyrinth": NB> http://www.lostlabyrinth.com/ I'm not sure how it could possibly be packaged when PureBasic, which it is written in, costs $99. - J< From chris.stone at gmail.com Tue Jan 30 23:36:47 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 30 Jan 2007 15:36:47 -0800 Subject: Guideline Question Message-ID: There is a package up for review, glob2, found here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225010 The packager is putting the data files into a sub packge because of this guideline in the Fedora Games SIG page: "Package game files and data files separately, if possible, to reduce size of bugfix updates. This must be done if upstream packages game data in separate tarballs, and should be done even if upstream uses one tarball for game source and data. See Nazghul and tong for examples." This does not make sense to me. Shouldn't the data package be in an entirely different spec file instead of just a subpackage of the main spec file? If you are going to make a bug fix to the app, and do a rebuild, the data package is also going to be upgraded at the same time because they are both in the same spec file and get the same release number. Please clarify. Regards, Chris From wart at kobold.org Tue Jan 30 23:45:06 2007 From: wart at kobold.org (Michael Thomas) Date: Tue, 30 Jan 2007 15:45:06 -0800 Subject: Guideline Question In-Reply-To: References: Message-ID: <45BFD882.9090803@kobold.org> Christopher Stone wrote: > There is a package up for review, glob2, found here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225010 > > The packager is putting the data files into a sub packge because of > this guideline in the Fedora Games SIG page: > "Package game files and data files separately, if possible, to reduce > size of > bugfix updates. This must be done if upstream packages game data in > separate > tarballs, and should be done even if upstream uses one tarball for game > source > and data. See Nazghul and tong for examples." > > This does not make sense to me. Shouldn't the data package be in an > entirely different spec file instead of just a subpackage of the main > spec file? If you are going to make a bug fix to the app, and do a > rebuild, the data package is also going to be upgraded at the same > time because they are both in the same spec file and get the same > release number. True, if the game data is in a subpackage then you don't gain much benefit during updates. In that case it's more of a cosmetic issue with no real drawback. Though if Fedora ever starts using delta rpms, then we'd see an immediate benefit with no additional work. The next option would be to leave the data and code all in the same package, with no subpackage for the data. This is the default case that we're trying to optimize by having -data subpackages. Another option, as you suggest, is to use separate spec files with the same source tarball. I like this option because it benefits the end users, but has the drawback of increasing the disk space consumption of the mirrors due to the source tarball being packaged twice in two separate src rpms. What's good for the users is bad for the mirrors, I guess. Ideally upstream would separate the game data and game code into separate packages, but that's not always an option. Perhaps we should clarify the 'should be done' sentence thus: "...and is recommended, but not required, even if upstream uses one tarball for game source and data" ? --Wart From j.w.r.degoede at hhs.nl Wed Jan 31 08:55:33 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 31 Jan 2007 09:55:33 +0100 Subject: Guideline Question In-Reply-To: <45BFD882.9090803@kobold.org> References: <45BFD882.9090803@kobold.org> Message-ID: <45C05985.8080407@hhs.nl> Michael Thomas wrote: > Christopher Stone wrote: >> There is a package up for review, glob2, found here: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225010 >> >> The packager is putting the data files into a sub packge because of >> this guideline in the Fedora Games SIG page: >> "Package game files and data files separately, if possible, to reduce >> size of >> bugfix updates. This must be done if upstream packages game data in >> separate >> tarballs, and should be done even if upstream uses one tarball for >> game source >> and data. See Nazghul and tong for examples." >> >> This does not make sense to me. Shouldn't the data package be in an >> entirely different spec file instead of just a subpackage of the main >> spec file? If you are going to make a bug fix to the app, and do a >> rebuild, the data package is also going to be upgraded at the same >> time because they are both in the same spec file and get the same >> release number. > > True, if the game data is in a subpackage then you don't gain much > benefit during updates. In that case it's more of a cosmetic issue with > no real drawback. Though if Fedora ever starts using delta rpms, then > we'd see an immediate benefit with no additional work. > > The next option would be to leave the data and code all in the same > package, with no subpackage for the data. This is the default case that > we're trying to optimize by having -data subpackages. > > Another option, as you suggest, is to use separate spec files with the > same source tarball. I like this option because it benefits the end > users, but has the drawback of increasing the disk space consumption of > the mirrors due to the source tarball being packaged twice in two > separate src rpms. What's good for the users is bad for the mirrors, I > guess. > Note that this has all been discusses on the extras mailing list already (discussion started by me) and that the outcome in the case upstream has only one tarbal was, that you must also have only one SRPM, or create 2 different tarbals for use in 2 different SRPM's yourself. IOW having 2 srpms with the same tarbal in them to get 2 really seperate data and engine packages was deemed no acceptable. > Ideally upstream would separate the game data and game code into > separate packages, but that's not always an option. > Yes when the data is big that would be the best, we should try to encourage the different upstreams todo the split in the big data cases. > Perhaps we should clarify the 'should be done' sentence thus: > > "...and is recommended, but not required, even if upstream uses one > tarball for game source and data" ? > I must admit that when upstream uses only one tarbal I never do a seperate -data subpackage (see scorched3d for example) as that is utterly useless then IMHO. Regards, Hans From chris.stone at gmail.com Wed Jan 31 15:36:37 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 31 Jan 2007 07:36:37 -0800 Subject: Guideline Question In-Reply-To: <45C05985.8080407@hhs.nl> References: <45BFD882.9090803@kobold.org> <45C05985.8080407@hhs.nl> Message-ID: On 1/31/07, Hans de Goede wrote: > Michael Thomas wrote: > > Christopher Stone wrote: > >> There is a package up for review, glob2, found here: > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225010 > >> > >> The packager is putting the data files into a sub packge because of > >> this guideline in the Fedora Games SIG page: > >> "Package game files and data files separately, if possible, to reduce > >> size of > >> bugfix updates. This must be done if upstream packages game data in > >> separate > >> tarballs, and should be done even if upstream uses one tarball for > >> game source > >> and data. See Nazghul and tong for examples." > >> > >> This does not make sense to me. Shouldn't the data package be in an > >> entirely different spec file instead of just a subpackage of the main > >> spec file? If you are going to make a bug fix to the app, and do a > >> rebuild, the data package is also going to be upgraded at the same > >> time because they are both in the same spec file and get the same > >> release number. > > > > True, if the game data is in a subpackage then you don't gain much > > benefit during updates. In that case it's more of a cosmetic issue with > > no real drawback. Though if Fedora ever starts using delta rpms, then > > we'd see an immediate benefit with no additional work. > > > > The next option would be to leave the data and code all in the same > > package, with no subpackage for the data. This is the default case that > > we're trying to optimize by having -data subpackages. > > > > Another option, as you suggest, is to use separate spec files with the > > same source tarball. I like this option because it benefits the end > > users, but has the drawback of increasing the disk space consumption of > > the mirrors due to the source tarball being packaged twice in two > > separate src rpms. What's good for the users is bad for the mirrors, I > > guess. > > > > Note that this has all been discusses on the extras mailing list already > (discussion started by me) and that the outcome in the case upstream has > only one tarbal was, that you must also have only one SRPM, or create 2 > different tarbals for use in 2 different SRPM's yourself. IOW having 2 > srpms with the same tarbal in them to get 2 really seperate data and > engine packages was deemed no acceptable. > > > Ideally upstream would separate the game data and game code into > > separate packages, but that's not always an option. > > > > Yes when the data is big that would be the best, we should try to > encourage the different upstreams todo the split in the big data cases. > > > Perhaps we should clarify the 'should be done' sentence thus: > > > > "...and is recommended, but not required, even if upstream uses one > > tarball for game source and data" ? > > > > I must admit that when upstream uses only one tarbal I never do a > seperate -data subpackage (see scorched3d for example) as that is > utterly useless then IMHO. So should we encourage people to split up their packages in the same SRPM even though its completely pointless? Perhaps we should update the guidelines? I think pointing them to nazghul and tong as examples is not a good idea since these packages do not accomplish anything by breaking their data up into a subpackage of the same SRPM. Regards, Chris From j.w.r.degoede at hhs.nl Wed Jan 31 16:02:33 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 31 Jan 2007 17:02:33 +0100 Subject: Guideline Question In-Reply-To: References: <45BFD882.9090803@kobold.org> <45C05985.8080407@hhs.nl> Message-ID: <45C0BD99.3070600@hhs.nl> Christopher Stone wrote: > On 1/31/07, Hans de Goede wrote: >> Michael Thomas wrote: >> > Christopher Stone wrote: >> >> There is a package up for review, glob2, found here: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225010 >> >> >> >> The packager is putting the data files into a sub packge because of >> >> this guideline in the Fedora Games SIG page: >> >> "Package game files and data files separately, if possible, to reduce >> >> size of >> >> bugfix updates. This must be done if upstream packages game data in >> >> separate >> >> tarballs, and should be done even if upstream uses one tarball for >> >> game source >> >> and data. See Nazghul and tong for examples." >> >> >> >> This does not make sense to me. Shouldn't the data package be in an >> >> entirely different spec file instead of just a subpackage of the main >> >> spec file? If you are going to make a bug fix to the app, and do a >> >> rebuild, the data package is also going to be upgraded at the same >> >> time because they are both in the same spec file and get the same >> >> release number. >> > >> > True, if the game data is in a subpackage then you don't gain much >> > benefit during updates. In that case it's more of a cosmetic issue >> with >> > no real drawback. Though if Fedora ever starts using delta rpms, then >> > we'd see an immediate benefit with no additional work. >> > >> > The next option would be to leave the data and code all in the same >> > package, with no subpackage for the data. This is the default case >> that >> > we're trying to optimize by having -data subpackages. >> > >> > Another option, as you suggest, is to use separate spec files with the >> > same source tarball. I like this option because it benefits the end >> > users, but has the drawback of increasing the disk space consumption of >> > the mirrors due to the source tarball being packaged twice in two >> > separate src rpms. What's good for the users is bad for the mirrors, I >> > guess. >> > >> >> Note that this has all been discusses on the extras mailing list already >> (discussion started by me) and that the outcome in the case upstream has >> only one tarbal was, that you must also have only one SRPM, or create 2 >> different tarbals for use in 2 different SRPM's yourself. IOW having 2 >> srpms with the same tarbal in them to get 2 really seperate data and >> engine packages was deemed no acceptable. >> >> > Ideally upstream would separate the game data and game code into >> > separate packages, but that's not always an option. >> > >> >> Yes when the data is big that would be the best, we should try to >> encourage the different upstreams todo the split in the big data cases. >> >> > Perhaps we should clarify the 'should be done' sentence thus: >> > >> > "...and is recommended, but not required, even if upstream uses one >> > tarball for game source and data" ? >> > >> >> I must admit that when upstream uses only one tarbal I never do a >> seperate -data subpackage (see scorched3d for example) as that is >> utterly useless then IMHO. > > So should we encourage people to split up their packages in the same > SRPM even though its completely pointless? Perhaps we should update > the guidelines? I think pointing them to nazghul and tong as examples > is not a good idea since these packages do not accomplish anything by > breaking their data up into a subpackage of the same SRPM. > Agreed, Regards, Hans