Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On 5/31/20 9:19 AM, Tobias Frost wrote: > If you want to follow this route, your next step would be now to contact > the fox1.6 maintainer by filing a wishlist bug against src:fox1.6, asking > to package the version you need, explaining the situation and maybe (== > if you want) tell them that you would commit helping to offset the extra > work caused by maintaining the development snapshot. > > * dak spits out those r-deps: > ace: libfox-1.6-dev > gogglesmm: libfox-1.6-dev > libgwenhywfar: libfox-1.6-dev > pcsc-cyberjack: libfox-1.6-dev > sumo: libfox-1.6-dev > xfe: libfox-1.6-dev (>= 1.6.45) > Figured it out now. The package name is "libfox-1.6-0". If I did nothing wrong the wishlist bug should be filed now. -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On 5/31/20 9:19 AM, Tobias Frost wrote: > If you want to follow this route, your next step would be now to contact > the fox1.6 maintainer by filing a wishlist bug against src:fox1.6, asking > to package the version you need, explaining the situation and maybe (== > if you want) tell them that you would commit helping to offset the extra > work caused by maintaining the development snapshot. > > * dak spits out those r-deps: > ace: libfox-1.6-dev > gogglesmm: libfox-1.6-dev > libgwenhywfar: libfox-1.6-dev > pcsc-cyberjack: libfox-1.6-dev > sumo: libfox-1.6-dev > xfe: libfox-1.6-dev (>= 1.6.45) > I tried doing this with reportbug but I failed. It asks me first for the package where the bug is found. I entered as you suggested "src:fox1.6". Reportbug complains "src:fox1.6 is not a valid package name.". What am I doing wrong? -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Thu, Jun 04, 2020 at 06:33:10PM +0200, Roland Plüss wrote: > > On 5/31/20 9:19 AM, Tobias Frost wrote: > > If you want to follow this route, your next step would be now to contact > > the fox1.6 maintainer by filing a wishlist bug against src:fox1.6, asking > > to package the version you need, explaining the situation and maybe (== > > if you want) tell them that you would commit helping to offset the extra > > work caused by maintaining the development snapshot. > > > > * dak spits out those r-deps: > > ace: libfox-1.6-dev > > gogglesmm: libfox-1.6-dev > > libgwenhywfar: libfox-1.6-dev > > pcsc-cyberjack: libfox-1.6-dev > > sumo: libfox-1.6-dev > > xfe: libfox-1.6-dev (>= 1.6.45) > > > I tried doing this with reportbug but I failed. It asks me first for the > package where the bug is found. I entered as you suggested "src:fox1.6". > Reportbug complains "src:fox1.6 is not a valid package name.". What am I > doing wrong? Ah, sorry, didn't meant to confuse you. src:$package just means "against the source package", so you would do a "reportbug --src fox1.6" or a plain "reportbug fox1.6" works too. > -- > Mit freundlichen Grüssen > Plüss Roland > > Game Development and Game Engine Technologies https://dragondreams.ch >
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On 6/2/20 1:05 PM, Tobias Frost wrote: > On Mon, Jun 01, 2020 at 04:13:33PM +0200, Roland Plüss wrote: >> On 5/31/20 9:19 AM, Tobias Frost wrote: > (...) > >>> It seems at first glance possible that both versions can be in Debian, >>> however, the release/security team will not be happy to have both of >>> them in a stable release, IOW, having two versions can only be a >>> intermediate solution until all reverse dependencies of 1.6* have been >>> updated (by patching the respective Debian packages.) More about such >>> library transision: >>> https://wiki.debian.org/Teams/ReleaseTeam/Transitions >>> >> FOX-1.7 and FOX-1.6 are not compatible (well, mostly yes but in >> important things not). That said they are different libraries with >> separate include and library names (/usr/include/fox-1.6 vs >> /usr/include/fox-1.7 and the same for libraries). So technically >> applications linking against FOX-1.6 do not have to be change if FOX-1.7 >> is added on the same system (the two can coexist). But it depends if two >> library versions of the same library are accepted even if they are disjoint. > Those versions are not disjoint, the new version is just an evolution of the > old one. > > > Incompatible ABI changes is nothing special and happens all the time in Debian > (called library transistios). As I tried to explain earlier, the maintainer > duty is to resolve this by a transistion when updating the library. > > For you, hat means you need either 1.6 for code base or you need to help that > all of Debian is using 1.7. You can't have both versions in Debian… > I don't see any way for me to get other projects to update to 1.7 . FOX separates 1.7 from 1.6 so projects are not forced to upgrade if they don't want to. I can try ask the maintainer but I consider this a 0% success rate. -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Thu, Jun 04, 2020 at 12:25:39PM +0200, Roland Plüss wrote: > > On 6/2/20 1:05 PM, Tobias Frost wrote: > > On Mon, Jun 01, 2020 at 04:13:33PM +0200, Roland Plüss wrote: > >> On 5/31/20 9:19 AM, Tobias Frost wrote: > > (...) > > > >>> It seems at first glance possible that both versions can be in Debian, > >>> however, the release/security team will not be happy to have both of > >>> them in a stable release, IOW, having two versions can only be a > >>> intermediate solution until all reverse dependencies of 1.6* have been > >>> updated (by patching the respective Debian packages.) More about such > >>> library transision: > >>> https://wiki.debian.org/Teams/ReleaseTeam/Transitions > >>> > >> FOX-1.7 and FOX-1.6 are not compatible (well, mostly yes but in > >> important things not). That said they are different libraries with > >> separate include and library names (/usr/include/fox-1.6 vs > >> /usr/include/fox-1.7 and the same for libraries). So technically > >> applications linking against FOX-1.6 do not have to be change if FOX-1.7 > >> is added on the same system (the two can coexist). But it depends if two > >> library versions of the same library are accepted even if they are > >> disjoint. > > Those versions are not disjoint, the new version is just an evolution of the > > old one. > > > > > > Incompatible ABI changes is nothing special and happens all the time in > > Debian > > (called library transistios). As I tried to explain earlier, the maintainer > > duty is to resolve this by a transistion when updating the library. > > > > For you, hat means you need either 1.6 for code base or you need to help > > that > > all of Debian is using 1.7. You can't have both versions in Debian… > > > I don't see any way for me to get other projects to update to 1.7 . FOX > separates 1.7 from 1.6 so projects are not forced to upgrade if they > don't want to. This would not be the first library transition that requires patches to packages in the archives. If upstreams accept those patches is a different story, orthogonal to this discussion. However, I want to make sure you understand, when your package is accepted, and a library transition is impacting your package, the same rules will apply to you: You will need to work with the library's maintainer to make your package compatible with the new version. It will be not an option to stay at the old version of the library. That would be not how distributions work. > I can try ask the maintainer but I consider this a 0% success rate. I don't agree. Though 1.7 is a development version and it depends on the maintainer if they accept it, you will not know until you have filed that bug. So please assume good faith first, it could be that the maintainer acutally likes the idea. -- tobi
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Mon, Jun 01, 2020 at 04:13:33PM +0200, Roland Plüss wrote: > > On 5/31/20 9:19 AM, Tobias Frost wrote: (...) > > It seems at first glance possible that both versions can be in Debian, > > however, the release/security team will not be happy to have both of > > them in a stable release, IOW, having two versions can only be a > > intermediate solution until all reverse dependencies of 1.6* have been > > updated (by patching the respective Debian packages.) More about such > > library transision: > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > > FOX-1.7 and FOX-1.6 are not compatible (well, mostly yes but in > important things not). That said they are different libraries with > separate include and library names (/usr/include/fox-1.6 vs > /usr/include/fox-1.7 and the same for libraries). So technically > applications linking against FOX-1.6 do not have to be change if FOX-1.7 > is added on the same system (the two can coexist). But it depends if two > library versions of the same library are accepted even if they are disjoint. Those versions are not disjoint, the new version is just an evolution of the old one. Incompatible ABI changes is nothing special and happens all the time in Debian (called library transistios). As I tried to explain earlier, the maintainer duty is to resolve this by a transistion when updating the library. For you, hat means you need either 1.6 for code base or you need to help that all of Debian is using 1.7. You can't have both versions in Debian… -- tobi signature.asc Description: PGP signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On 5/31/20 9:19 AM, Tobias Frost wrote: > On Sat, May 30, 2020 at 06:55:42PM +0200, Roland Plüss wrote: >> On 5/30/20 4:45 PM, Tobias Frost wrote: >>> I see those options: >>> - talk to the fox-1.6 maintainer about updating the package to 1.7. >>> (though I see that they generally stick to released versions and 1.7.* >>> seems >>> to be only development snapshots; a question to ask: is the 1.7 ABI >>> stable already?) >>> - make the features optional that requires 1.7 >>> - use only 1.6 features (listed for completeness, as you said you can't) > There is another option I've forgot to mention: > - Talk to the maintainers of 1.6 and work together with them to package > 1.7. Maybe Florian is happy to get you as (co-)maintainer the 1.7 > package, so you could offer that. > > It seems at first glance possible that both versions can be in Debian, > however, the release/security team will not be happy to have both of > them in a stable release, IOW, having two versions can only be a > intermediate solution until all reverse dependencies of 1.6* have been > updated (by patching the respective Debian packages.) More about such > library transision: > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > If you want to follow this route, your next step would be now to contact > the fox1.6 maintainer by filing a wishlist bug against src:fox1.6, asking > to package the version you need, explaining the situation and maybe (== > if you want) tell them that you would commit helping to offset the extra > work caused by maintaining the development snapshot. > > * dak spits out those r-deps: > ace: libfox-1.6-dev > gogglesmm: libfox-1.6-dev > libgwenhywfar: libfox-1.6-dev > pcsc-cyberjack: libfox-1.6-dev > sumo: libfox-1.6-dev > xfe: libfox-1.6-dev (>= 1.6.45) > FOX-1.7 and FOX-1.6 are not compatible (well, mostly yes but in important things not). That said they are different libraries with separate include and library names (/usr/include/fox-1.6 vs /usr/include/fox-1.7 and the same for libraries). So technically applications linking against FOX-1.6 do not have to be change if FOX-1.7 is added on the same system (the two can coexist). But it depends if two library versions of the same library are accepted even if they are disjoint. -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Sat, May 30, 2020 at 06:55:42PM +0200, Roland Plüss wrote: > > On 5/30/20 4:45 PM, Tobias Frost wrote: > > I see those options: > > - talk to the fox-1.6 maintainer about updating the package to 1.7. > > (though I see that they generally stick to released versions and 1.7.* > > seems > > to be only development snapshots; a question to ask: is the 1.7 ABI > > stable already?) > > - make the features optional that requires 1.7 > > - use only 1.6 features (listed for completeness, as you said you can't) There is another option I've forgot to mention: - Talk to the maintainers of 1.6 and work together with them to package 1.7. Maybe Florian is happy to get you as (co-)maintainer the 1.7 package, so you could offer that. It seems at first glance possible that both versions can be in Debian, however, the release/security team will not be happy to have both of them in a stable release, IOW, having two versions can only be a intermediate solution until all reverse dependencies of 1.6* have been updated (by patching the respective Debian packages.) More about such library transision: https://wiki.debian.org/Teams/ReleaseTeam/Transitions If you want to follow this route, your next step would be now to contact the fox1.6 maintainer by filing a wishlist bug against src:fox1.6, asking to package the version you need, explaining the situation and maybe (== if you want) tell them that you would commit helping to offset the extra work caused by maintaining the development snapshot. * dak spits out those r-deps: ace: libfox-1.6-dev gogglesmm: libfox-1.6-dev libgwenhywfar: libfox-1.6-dev pcsc-cyberjack: libfox-1.6-dev sumo: libfox-1.6-dev xfe: libfox-1.6-dev (>= 1.6.45) -- tobi
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On 5/30/20 4:45 PM, Tobias Frost wrote: > On Sat, May 30, 2020 at 03:08:21PM +0200, Roland Plüss wrote: >> On 5/30/20 2:00 PM, Tobias Frost wrote: >>> * Update to my hints list: There is a fox package, fox-1.6 [1]; you'll >>> know for >>> sure if it suitable… >>> >>> [1] https://tracker.debian.org/pkg/fox1.6 >>> >> I've seen that. I need though fox1.7 since 1.6 is not compatible to 1.7 >> . There had been API breaking changes in 1.7 . >> >> If this is a vital problem please tell me. It's not possible to remove >> fox1.7 requirement unless various parts of the package are not build >> (namely the basic crash recovery module, the gui launcher and the entire >> IGDE). > Yes, this gonna be a problem due to the Debian Policy about embedded code > copies [1]. > > I see those options: > - talk to the fox-1.6 maintainer about updating the package to 1.7. > (though I see that they generally stick to released versions and 1.7.* seems > to be only development snapshots; a question to ask: is the 1.7 ABI stable > already?) > - make the features optional that requires 1.7 > - use only 1.6 features (listed for completeness, as you said you can't) > > [1] > https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies > To be honest I don't know how stable the author thinks 1.7 is. I had no troubles with stability so far. The features can be made optional but then only the console-launcher is working. This would mean games can be played (from the console) but no gui-launcher can be used and no development environment can be used. To be honest I don't think such a stripped down version is useful except for one scenario: game server hosting. -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On 5/30/20 2:00 PM, Tobias Frost wrote: > * Update to my hints list: There is a fox package, fox-1.6 [1]; you'll > know for > sure if it suitable… > > [1] https://tracker.debian.org/pkg/fox1.6 > I've seen that. I need though fox1.7 since 1.6 is not compatible to 1.7 . There had been API breaking changes in 1.7 . If this is a vital problem please tell me. It's not possible to remove fox1.7 requirement unless various parts of the package are not build (namely the basic crash recovery module, the gui launcher and the entire IGDE). -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Sat, May 30, 2020 at 03:08:21PM +0200, Roland Plüss wrote: > > On 5/30/20 2:00 PM, Tobias Frost wrote: > > * Update to my hints list: There is a fox package, fox-1.6 [1]; you'll > > know for > > sure if it suitable… > > > > [1] https://tracker.debian.org/pkg/fox1.6 > > > I've seen that. I need though fox1.7 since 1.6 is not compatible to 1.7 > . There had been API breaking changes in 1.7 . > > If this is a vital problem please tell me. It's not possible to remove > fox1.7 requirement unless various parts of the package are not build > (namely the basic crash recovery module, the gui launcher and the entire > IGDE). Yes, this gonna be a problem due to the Debian Policy about embedded code copies [1]. I see those options: - talk to the fox-1.6 maintainer about updating the package to 1.7. (though I see that they generally stick to released versions and 1.7.* seems to be only development snapshots; a question to ask: is the 1.7 ABI stable already?) - make the features optional that requires 1.7 - use only 1.6 features (listed for completeness, as you said you can't) [1] https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies -- tobi signature.asc Description: PGP signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Sat, May 30, 2020 at 01:11:45PM +0200, Roland Plüss wrote: > I did not wanted to go down the "release early, release crap, become a mess" > route so I did not release the source base to the public until recently. Well, OK, your choice… Though I's recommend reading "The Bazaar and the Cathedral" from Eric S. Raymond. (...) snipped engine summary, thanks for it. Its essence should probably attached to the ITP or it would be a start point for the package description… > Now if you insist this will be rejected because not having yet finished > games projects out for years then there is not much I can do about it. > This engine had been already at a game show and used by players and > didn't falter so I'm positive it is ready. That said I'm doing things > like supporting new OS and packaging for OS also to improve the project. > So if this should be rejected, no problem to me. I've got other path I > can walk too. But please if you really think this has no chance to enter > Debian no matter what I do then tell me this please now. Then I will at > least improve things using the lintian and go on from there. Let me clarify that I only described the mechanics in Debian. I just said it is _possible_ that it could be rejected, but I'm not the one which decides about it, that would be the ftp masters. If you want to go the route and give it a try: great! But there still work to be done on the packaging level before an upload can be made. As said, work on the package*, reupload to mentors, remove the moreinfo tag and we will see how things develop. * Update to my hints list: There is a fox package, fox-1.6 [1]; you'll know for sure if it suitable… [1] https://tracker.debian.org/pkg/fox1.6 > -- > Mit freundlichen Grüssen > Plüss Roland > > Game Development and Game Engine Technologies https://dragondreams.ch > signature.asc Description: PGP signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On 5/29/20 10:07 PM, Tobias Frost wrote: > On Fri, May 29, 2020 at 12:32:42PM +0200, Roland Plüss wrote: > >> I'm a bit cautious to allow installing games into the user home >> directory. Game files can quickly grow large (up to GB of data). One >> reason why I opted for /opt in the first place. > Speaking of games, are there free (FOSS) games available? A quick Internet > research yielded no results, so I'd appreciate if you could provide pointers. > > Thanks! > Not yet. The engine has been released public for the first time recently. Available right now are example projects including ready-to-run delgas: https://github.com/LordOfDragons/deexamples . The engine can be used for both FOSS and commercial alike without troubles. To makes games though you need the engine in the first place. It's sort of chicken/egg problem here. -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On 5/29/20 4:21 PM, Tobias Frost wrote: > Control: tag -1 moreinfo > > Hi Roland, > > On Fri, May 29, 2020 at 03:13:34PM +0200, Roland Plüss wrote: >> On Fri, 29 May 2020 14:21:03 +0200 Tobias Frost wrote: >>> On Thu, May 28, 2020 at 11:16:18AM -0400, Boyuan Yang wrote: >>> >>> (..) >>> There are other issues but I'd rather stop here. Since you yourself is also the upstream, it could be possible for you to actually review the software buildsystem (scons scripts) since it seems to have diverted from traditional software installation procedures on UNIX-like platforms. In any case, the source repository and packaging scripts your provided need >> improvement. >>> It is discouraged to use scons as build system [1]. If you see the >> possiblity >>> please change it to something else, (e.g. cmake) >>> >>> [1] https://wiki.debian.org/UpstreamGuide#SCons >>> >>> >>> >> Switching away from SCons is not an option. As I mentioned on IRC the >> cons against SCons in that article are no cons but incorrectly using >> SCons or not understanding SCons at all. > I'm not aware of this discussion. > >> Like many things in live SCons >> is like a bazooka: if you handle it correctly it gives you a punch like >> nothing else but it doesn't prevent you from pointing it at your own feet. > It is incredible difficult to use scons correctly, as it sometimes lacks > proper > default behaviour. Especially in multiarch and crosscompilations scenarios > (which is relevant for Debian). But if you say you can handle it, go ahead. > >> If for the debian package improvements are required please tell me > I do not sponsor scons based packages. > > However here's something: > - take a look at the mentors page for your package: there are many lintian > reportings to fix. Some of them also indicates that your buildsystem is not > properly building or configured. > - libraries are not built for Multiarch > - dev-pkg-without-shlib-symlink > - hardening. > - debug-file-with-no-debug-symbols > - dont hardcoding the number of CPUS d/rules, scons _-j8_ ) > (- there mihgt be more lintian stuff) > > More hints: > - Section X11 is likely wrong. You maybe want games? > - Spelling errors in binary. > - new-package-should-close-itp-bug > - no watch file. > - A game (engine) should not need a postinst. As said, /opt is off limit for > packages. Don't addgroup games. > - What is about those extern/ directory? There are tarballs… e.g fox*.tar.bz. > You can't have embedded code copies, if they are not in Debian they need to > be packaged. You should remove the complete extern folder using > Files-Exclude, if > possible. (The source package is 46MiB…) > - Where are the fonts in e.g deige/shared/data/data/fonts from? What is the > copyright? > Same for the icons? > - You package does not build in a pbuilder enviornment. Missing > Build-Dependencies (B-D) e.g on scons. > - A ton of other B-Ds are also missing (assuming extern lists the libraries > you > need) > > Looking at your repo: > https://github.com/LordOfDragons/dragengine/blob/debian/debian/rules lines > 34-41 > (you maybe want a install target? It should honour $DESTDIR, though) > looks quite weird. Also lines 27-29 are weird (clean target not working?) > Line 53-58 looks fishy to me. > >> and I'll apply the required changes but I will not go back to makefiles. > For sure you know that cmake is a buildsystem generator. It can > to create Makefiles, but it does not need to. > > Ok, I found many issues by only barley looking, so I marked the RFS as > "moreinfo". > Please fix the issues and then remove the "moreinfo" tag to have the > indication for > sponsors to take a look again. Please read also the "upstream guide" I posted > earlier, > it contains important information who to package software distribution > friendly. You are looking there at an older package version. I fixed some of these points already. For the other points I need to check them out in more detail since some I have no idea what lintian is actually complaining about. -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Fri, May 29, 2020 at 12:32:42PM +0200, Roland Plüss wrote: > I'm a bit cautious to allow installing games into the user home > directory. Game files can quickly grow large (up to GB of data). One > reason why I opted for /opt in the first place. Speaking of games, are there free (FOSS) games available? A quick Internet research yielded no results, so I'd appreciate if you could provide pointers. Thanks! -- tobi
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Fri, 29 May 2020 14:21:03 +0200 Tobias Frost wrote: > On Thu, May 28, 2020 at 11:16:18AM -0400, Boyuan Yang wrote: > > (..) > > > There are other issues but I'd rather stop here. Since you yourself is > > also the upstream, > > it could be possible for you to actually review the software > > buildsystem (scons scripts) since it seems > > to have diverted from traditional software installation procedures on > > UNIX-like platforms. In any case, > > the source repository and packaging scripts your provided need improvement. > > It is discouraged to use scons as build system [1]. If you see the possiblity > please change it to something else, (e.g. cmake) > > [1] https://wiki.debian.org/UpstreamGuide#SCons > > > Switching away from SCons is not an option. As I mentioned on IRC the cons against SCons in that article are no cons but incorrectly using SCons or not understanding SCons at all. Like many things in live SCons is like a bazooka: if you handle it correctly it gives you a punch like nothing else but it doesn't prevent you from pointing it at your own feet. If for the debian package improvements are required please tell me and I'll apply the required changes but I will not go back to makefiles. -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Fri, 29 May 2020 05:33:43 + Paul Wise wrote: > On Thu, May 28, 2020 at 6:33 PM Roland Plüss wrote: > > > What path do you think should I choose to be best conform with Debian? > > I would package the games into Debian packages so that the source > data/code is available and built by the Debian packaging, using paths > something like /usr/share/dlauncher/games/. For games that don't have > Debian packages (I guess you plan to have a central store or > something), install the games to the ~/.local/share/dlauncher/games/ > dir since different users will want different sets of games installed. > You could also add a directory in /usr/local that the sysadmin could > install games to for all users if they want. > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise > > I should have mentioned a point or two. The launchers operate on a single central installation directory only but this does not mean games are necessarily installed there. Delga files do not need to be physically there. They can be also just sym-links. The launchers use the content of this directory to populate the list of installed games. That said launchers can run delgas without being installed at all. You can download a delga and just open it and it launches without the need to be installed at all. Installing though is more convenient but not required. This requires only the "mime-types" included in the package to be properly registered. I'm a bit cautious to allow installing games into the user home directory. Game files can quickly grow large (up to GB of data). One reason why I opted for /opt in the first place. That said the directory used by the launchers can be altered by env-param DELAUNCHER_GAMES . So for multi-user this can be shifted to the home-directory with all the potentially size caveats if required. I think for this package I would prefer /usr/share/delauncher/games with the option of using env-param or maybe global/local directories in the future (needs further discussion because this has its own set of problems). -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
Control: tag -1 moreinfo Hi Roland, On Fri, May 29, 2020 at 03:13:34PM +0200, Roland Plüss wrote: > On Fri, 29 May 2020 14:21:03 +0200 Tobias Frost wrote: > > On Thu, May 28, 2020 at 11:16:18AM -0400, Boyuan Yang wrote: > > > > (..) > > > > > There are other issues but I'd rather stop here. Since you yourself is > > > also the upstream, > > > it could be possible for you to actually review the software > > > buildsystem (scons scripts) since it seems > > > to have diverted from traditional software installation procedures on > > > UNIX-like platforms. In any case, > > > the source repository and packaging scripts your provided need > improvement. > > > > It is discouraged to use scons as build system [1]. If you see the > possiblity > > please change it to something else, (e.g. cmake) > > > > [1] https://wiki.debian.org/UpstreamGuide#SCons > > > > > > > > Switching away from SCons is not an option. As I mentioned on IRC the > cons against SCons in that article are no cons but incorrectly using > SCons or not understanding SCons at all. I'm not aware of this discussion. > Like many things in live SCons > is like a bazooka: if you handle it correctly it gives you a punch like > nothing else but it doesn't prevent you from pointing it at your own feet. It is incredible difficult to use scons correctly, as it sometimes lacks proper default behaviour. Especially in multiarch and crosscompilations scenarios (which is relevant for Debian). But if you say you can handle it, go ahead. > If for the debian package improvements are required please tell me I do not sponsor scons based packages. However here's something: - take a look at the mentors page for your package: there are many lintian reportings to fix. Some of them also indicates that your buildsystem is not properly building or configured. - libraries are not built for Multiarch - dev-pkg-without-shlib-symlink - hardening. - debug-file-with-no-debug-symbols - dont hardcoding the number of CPUS d/rules, scons _-j8_ ) (- there mihgt be more lintian stuff) More hints: - Section X11 is likely wrong. You maybe want games? - Spelling errors in binary. - new-package-should-close-itp-bug - no watch file. - A game (engine) should not need a postinst. As said, /opt is off limit for packages. Don't addgroup games. - What is about those extern/ directory? There are tarballs… e.g fox*.tar.bz. You can't have embedded code copies, if they are not in Debian they need to be packaged. You should remove the complete extern folder using Files-Exclude, if possible. (The source package is 46MiB…) - Where are the fonts in e.g deige/shared/data/data/fonts from? What is the copyright? Same for the icons? - You package does not build in a pbuilder enviornment. Missing Build-Dependencies (B-D) e.g on scons. - A ton of other B-Ds are also missing (assuming extern lists the libraries you need) Looking at your repo: https://github.com/LordOfDragons/dragengine/blob/debian/debian/rules lines 34-41 (you maybe want a install target? It should honour $DESTDIR, though) looks quite weird. Also lines 27-29 are weird (clean target not working?) Line 53-58 looks fishy to me. > and I'll apply the required changes but I will not go back to makefiles. For sure you know that cmake is a buildsystem generator. It can to create Makefiles, but it does not need to. Ok, I found many issues by only barley looking, so I marked the RFS as "moreinfo". Please fix the issues and then remove the "moreinfo" tag to have the indication for sponsors to take a look again. Please read also the "upstream guide" I posted earlier, it contains important information who to package software distribution friendly. -- Cheers, tobi > -- > Mit freundlichen Grüssen > Plüss Roland > > Game Development and Game Engine Technologies https://dragondreams.ch >
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Thu, May 28, 2020 at 6:33 PM Roland Plüss wrote: > What path do you think should I choose to be best conform with Debian? I would package the games into Debian packages so that the source data/code is available and built by the Debian packaging, using paths something like /usr/share/dlauncher/games/. For games that don't have Debian packages (I guess you plan to have a central store or something), install the games to the ~/.local/share/dlauncher/games/ dir since different users will want different sets of games installed. You could also add a directory in /usr/local that the sysadmin could install games to for all users if they want. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
Hi, > Hi, > > Long story short, this hasn't reached a satisfactory quality. I will > point out issues > I found but there are more to fix. > * Please make sure the debian/files file does not exist in your packaging added "rm" to the clean step. > * Your debian/postinst script is missing the #DEBHELPER# placeholder. fixed > * Your debian/postinst file has to recognize whether it is being called during installation, upgrade or removal. modified the postinst to operate only on "configure" > * Official Debian packages in "main" section should not manipulate files under /opt/ directory at any time. this one will be interesting. the /opt/delauncher/games is where the user installs to the games he wants to play. in my opinion these are optional packages the user manually installs and uninstalls. That said this path can be configured at compile time. According to a page on the internet about FHS+Games (http://www.roguebasin.com/index.php?title=Filesystem_hierarchy_standard_for_game_developers) these possible locations are named (terms I used from that page): - /usr/games/: standard installation - /usr/share/games/: architecture-independent static game data "*.delga" files contain by definition no binary code, only data and script code (depending on what the developer chooses) and thus are never executable. From this point of view the "architecture-independent static game data" directory seems a suitable choice. This directory would then be /usr/share/games/delauncher/games . But the user (I choose group "games" to be part of) has to have write access to this directory so he can install/uninstall *.delga files. In this situation the "standard installation" seems better. This would then be /usr/games/delauncher/games . What path do you think should I choose to be best conform with Debian? > * You are using "3.0 (native)" format, which is not suitable for a non-Debian-specific project. modified file. > * Your "Build-Depends" field is missing way too many build dependencies. Looks like the changes to debian/control did not commit correctly. Pardon me for having overlooked this. I'll fix it right away. > * Your package bundles way too many external libraries under /extern/ directories. These are used for the "live-mode" build. Only three of them are actually used because the respective debian package is not existing or failing configure. I've added now "debian/source/options" with "tar-ignore" lines for each not used external file. I hope this helps. I'll re-upload with these changes. I would then appreciate more reviewing to iron out the remaining problems as good as i can. -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dragengine" * Package name : dragengine Version : 1.1 Upstream Author : rol...@rptd.ch * URL : https://dragondreams.ch * License : LGPL-3.0+ * Vcs : upstream debianization branch: https://github.com/LordOfDragons/dragengine/tree/debian Section : x11 It builds those binary packages: dragengine - Drag[en]gine Game Engine dragengine-dev - Drag[en]gine Game Engine Development deigde - Drag[en]gine Game Development Environment deigde-dev - Drag[en]gine IGDE Development To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dragengine Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dragengine/dragengine_1.1.dsc Changes since the last upload: * Initial debianization. Regards, -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
Hi, (see bottom) Roland Plüss 于2020年5月28日周四 上午10:45写道： > > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "dragengine" > > * Package name : dragengine > Version : 1.1 > Upstream Author : rol...@rptd.ch > * URL : https://dragondreams.ch > * License : LGPL-3.0+ > * Vcs : upstream debianization branch: > https://github.com/LordOfDragons/dragengine/tree/debian > Section : x11 > > It builds those binary packages: > > dragengine - Drag[en]gine Game Engine > dragengine-dev - Drag[en]gine Game Engine Development > deigde - Drag[en]gine Game Development Environment > deigde-dev - Drag[en]gine IGDE Development > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/dragengine Long story short, this hasn't reached a satisfactory quality. I will point out issues I found but there are more to fix. * Please make sure the debian/files file does not exist in your packaging. This file is automatically created and should not be created manually. * Your debian/postinst script is missing the #DEBHELPER# placeholder. * Your debian/postinst file has to recognize whether it is being called during installation, upgrade or removal. See https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html for details. I guess the best way is to take a look at existing postinst scripts written by others. * Official Debian packages in "main" section should not manipulate files under /opt/ directory at any time. Your package will be part of the system, not some so called "Optional application software packages". Please place files following the File Hierarchy Standard (FHS) using directories under /usr/. * You are using "3.0 (native)" format, which is not suitable for a non-Debian-specific project. See https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#native-dh-make for details. Please use "3.0 (quilt)" format. * Your "Build-Depends" field is missing way too many build dependencies. An easy example is that if scons is not installed on your system, your package surely cannot build. Please list all non-trivial build-dependencies required to build your package. See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydeps for details. * Your package bundles way too many external libraries under /extern/ directories. You must either document license information for those project or exclude those files from your source code. If building your package needs those libraries, please use existing libraries in current Debian archive. There are other issues but I'd rather stop here. Since you yourself is also the upstream, it could be possible for you to actually review the software buildsystem (scons scripts) since it seems to have diverted from traditional software installation procedures on UNIX-like platforms. In any case, the source repository and packaging scripts your provided need improvement. -- Regards, Boyuan Yang
