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 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 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 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 5/30/20 11:04 AM, Tobias Frost wrote: > On Sat, May 30, 2020 at 02:38:09AM +0200, Roland Plüss wrote: >> 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. > Ok, thanks for being honest. (I guess the "GB of game data" is nothing to be > concerned right now and when it becomes a thing you can always extend your > programm to look in more than one location or the games provide some launcher > script. (To be clear, this does not change anything about /opt being > unsuitable.) > > But there is now another chicken-egg problem: In Debian we don't try to > package > every piece of software; e.g it should have have already some relevnace, > users, > games, etc… Please don't think that being in Debian will boost the > userbase significantly. > > We have already plenty other game engines in the archives, so maybe elaborate > a bit what makes yours special over the others? > > One plus I immediatly see is that there are free examples (they should be part > of the package!) and seems to work well with a FLOSS toolchain only. (at least > I have the impression it does). But on the other side, it has yet to proof in > real games that it fit enough for them. > > One the minus side I see that you are alone on the project and despite the > project being quite old (I see featurelists dated 2014) it seems not to have > gained traction. Hinted by the absence of games and contributions to your > project, so I fear that the project is missing relevance. > > I write above not to discourage you, I just want to be frank with you that I'm > not sure that the software is ready for Debian. I want to avoid that you put > significant work into the packagaging just to find it rejected later. > > On the other hand, fixing the issues mentioned can also improving the > quality of your project. > > The videos you have published have kind of impressed me, but _disclaimer_ I'm > not a game developer ;-). > The reason for this is quite simple. 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. The entire design philosophy and workflows are different than other engines so getting the workflows working solid and fast had been important. This required especially waiting with a release until the various parts reached the goal level so changes and additions do not break things left and right (looking at source engine here in particular). Games typically compile engines into the file project or at least link hard-link against engine versions. This creates maintenance costs, tends to break with OS/Platform updates and requires rebuilding/repadistributing for different platforms. This engine fully separates the engine from the project. You do not link against the engine in any way. Delgas are thus truly cross platform and you are not forced into licenses. Even after after a game is release ant not maintained any more if new updates and features get into the engine the game still benefits from it with 0 maintenance cost. This means you can make a game on windows and people can run it on linux although you never touched this OS at all. From the developer side this is a directory based engine so no need to import/export all the time or fighting with assets. Edit an image with GIMP in the project directory and test-run. Export from Blender right into the project directory and run. You can even change the file while test-running and load the file again. The used file formats are open. There are no closed proprietary formats (nor media nor assets) used. For the engine defined file formats Blender scripts are present so you can export anything from Blender straight into your project. The distributing is also WYSIWYG: what is in your project directory becomes the distributable. No hidden magic, no cooking. Due to the directory n
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, 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
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
