Bug#962215: libfox-1.6-0: Is it possible to package fox-1.7.67 or higher?
Package: libfox-1.6-0 Version: 1.6.57-1 Severity: wishlist Dear Maintainer, I try to package my game engine project for debian which requires fox-1.7.67 or higher. Existing version is 1.6.57 which is not compatible to 1.7.67 . I've been told to create a wishlist bug to see if such an upgrade is possible, especially seeing how fox-1.7 is not yet marked stable upstream. Kind Regards -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.97-gentoo (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages libfox-1.6-0 depends on: ii libc6 2.30-8 ii libfontconfig1 2.13.1-4.2 ii libfreetype62.10.1-2 ii libgcc-s1 [libgcc1] 10.1.0-3 ii libgl1 1.3.1-1 ii libglu1-mesa [libglu1] 9.0.1-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libpng16-16 1.6.37-2 ii libstdc++6 10.1.0-3 ii libtiff54.1.0+git191117-2 ii libx11-62:1.6.9-2+b1 ii libxcursor1 1:1.2.0-2 ii libxext62:1.3.3-1+b2 ii libxft2 2.3.2-2 ii zlib1g 1:1.2.11.dfsg-2 libfox-1.6-0 recommends no packages. libfox-1.6-0 suggests no packages. -- no debconf information
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/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
Bug#961635: uploaded package
Uploaded the package to mentors as requested: https://mentors.debian.net/package/dragengine -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961635: ITP: dragengine -- Drag[en]gine Game Engine
Package: wnpp Severity: wishlist Owner: Roland Plüss * Package name: dragengine Version : 1.1 Upstream Author : Roland Plüss * URL : https://dragondreams.ch * License : LGPL-3 Programming Lang: C++, DragonScript, GLSL, Python Description : Drag[en]gine Game Engine Required to play games (*.delga) or developing games. Run delauncher-gui or delauncher-console. The Drag[en]gine is a new, fully free software game engine based on the GLEM design which allows to develop games faster, more stable and fully platform indepentend (-1 day portability). * Package name: dragengine-dev Version : 1.1 Upstream Author : Roland Plüss * URL : https://dragondreams.ch * License : LGPL-3 Programming Lang: C++, DragonScript, GLSL, Python Description : Drag[en]gine Game Engine Development Files Required to create Drag[en]gine Modules (like graphic module, input module and so forth). Not required to develop games. * Package name: deigde Version : 1.1 Upstream Author : Roland Plüss * URL : https://dragondreams.ch * License : LGPL-3 Programming Lang: C++, DragonScript, GLSL, Python Description : Drag[en]gine Game Development Environment Required to developing games using the Drag[en]gine Game Engine. Run deigde. Developing games using Drag[en]gine does not require compiling or linking against the game engine. * Package name: deigde-dev Version : 1.1 Upstream Author : Roland Plüss * URL : https://dragondreams.ch * License : LGPL-3 Programming Lang: C++, DragonScript, GLSL, Python Description : Drag[en]gine IGDE Development Required to create Drag[en]gine IGDE Editors. Not required to create games. === All these packages build from he same source repository at: https://github.com/LordOfDragons/dragengine The debianization is located in upstream repository in branch "debian": https://github.com/LordOfDragons/dragengine/tree/debian The packages are build from this branch but I dont know how to continue from here. Here the information requested by reportbug: - why is this package useful/relevant? It's a powerfull and future oriented game engine. I can harness this power already so I would like to allow other to harness this power too - do you use it? For active game development projects - how do you plan to maintain it? As much as possible which is why I put aside an own branch in the upstream repository - inside a packaging team? The "games" team seems appropriate. I've talked to the team already on IRC recently - are you looking for co-maintainers? I do not think multiple maintainers are required. But it never hurts to have helping hands - do you need a sponsor? If I have understood the documentation correctly I do need a sponsor. So yes, I'm looking for one.
