Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
On 2021-03-23 02:08, Mathias Gibbens wrote: > On Tue, 2021-03-16 at 12:57 +0200, Andrius Merkys wrote: >> On 2021-03-15 19:28, Mathias Gibbens wrote: I have reviewed your packaging, and saw libcurl4-openssl-dev among the build dependencies. Do you know what does openrct2 need it for? My concern here is that in-game network access/downloads may interfere with Debian policies. >>> >>> Grepping through the code, it appears that openrct2 uses the >>> libcurl >>> dependency primarily in two places. The first is to automatically >>> download missing objects referenced in a scenario or save game. >>> There's >>> a vibrant community of openrct2 fans who create custom scenery >>> objects, >>> and it looks like this is a helper to fetch missing custom objects. >>> I've not gotten into this aspect of the game, so I haven't >>> personally >>> used it. The second place libcurl is used is in support of >>> multiplayer >>> connection making. >>> >>> Both of these only happen when the end-user is running the >>> program, >>> so I think that shouldn't run afoul of Policy. (I know network >>> access >>> during build is verboten, which is why there's an >>> override_dh_auto_configure in d/rules and corresponding component >>> source tars [more below].) >> >> Thanks for checking this out. Both use cases are indeed not violating >> the policy. >> >> However, we need to make sure the downloader for missing objects >> knows >> the right place to put them. It must not attempt writing outside >> user's >> home directory. > > Yes, by default openrct2 places all config, save games, objects, etc > in ~/.config/OpenRCT2/. It also respects the XDG_CONFIG_HOME > environment variable. Good then. Thanks for confirming. I fail to build the package as of e6e4103971b570a179ef5a59a709c24b2fcc5d68 on clean sid chroot with the following error log (only the last lines): [snip] Any ideas what might have gone wrong? >>> >>> This is the first package I've created that contains multiple >>> upstream tarballs as described in uscan(1). The normal openrct2 >>> build >>> downloads a handful of pre-generated metadata (the "objects" >>> component >>> tarball) and custom scenarios for the opening sequence (the "title- >>> sequences" component tarball) at build time, but we can't do that >>> in >>> Debian. So I added them as additional sources. The error you're >>> seeing >>> indicates that for some reason they aren't being properly extracted >>> into the source directory prior to starting the build. >> >> Indeed, this must be the problem on my side, due to incorrectly >> created >> upstream tarball. I admit I know very little about multiple upstream >> tarballs (MUTs). >> >> However, in this case it looks like the split of the MUT to >> individual >> source packages would make sense. They seem to have version numbers >> on >> their own, and I notice no signs in them being released in a >> lockstep. >> For example, it might happen that at some point objects or >> title-sequences are released more often that the main game, and >> bumping >> Debian version of the MUT just to update the components will become >> tedious. What do you think about splitting? > > It would certainly be easy enough to split the components out into > three distinct source packages: > > openrct2 > openrct2-objects > openrct2-title-sequences > > And then have openrct2 depend on the other two to properly bring in > all the required bits of the program. I would suggest exactly the same. > I set things up using MUTs to try to reflect upstream's build process > as closely as possible, but as you point out having three distinct > packages will allow more flexibility when updating in the future. > > My only question would be if having three different packages would > make the RFS process any harder, and if I should then file two more RFS > bugs for the two new source packages. I do not think this would make RFS process any harder. As the releases of these three packages do not happen in a lockstep, you would probably want to upload the MUT whenever any of them is released anyway. MUT might save extra RFSes in case of simultaneous release, but I do not think this is worth optimizing for. In practice, instead of filing RFSes I used to ping my initial sponsor(s) with a list of packages I want to get uploaded. RFS is a formal request, but I see people directly mailing packaging teams with requests for uploads. And maybe at some point you will become a DD and will be able to upload packages yourself. > Thanks for helping me build a better package(s)! Thank you for working on openrct! Best wishes, Andrius
Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
On Tue, 2021-03-16 at 12:57 +0200, Andrius Merkys wrote: > Hi Mathias, > > On 2021-03-15 19:28, Mathias Gibbens wrote: > > > I have reviewed your packaging, and saw libcurl4-openssl-dev > > > among > > > the build dependencies. Do you know what does openrct2 need it > > > for? > > > My concern here is that in-game network access/downloads may > > > interfere with Debian policies. > > > > Grepping through the code, it appears that openrct2 uses the > > libcurl > > dependency primarily in two places. The first is to automatically > > download missing objects referenced in a scenario or save game. > > There's > > a vibrant community of openrct2 fans who create custom scenery > > objects, > > and it looks like this is a helper to fetch missing custom objects. > > I've not gotten into this aspect of the game, so I haven't > > personally > > used it. The second place libcurl is used is in support of > > multiplayer > > connection making. > > > > Both of these only happen when the end-user is running the > > program, > > so I think that shouldn't run afoul of Policy. (I know network > > access > > during build is verboten, which is why there's an > > override_dh_auto_configure in d/rules and corresponding component > > source tars [more below].) > > Thanks for checking this out. Both use cases are indeed not violating > the policy. > > However, we need to make sure the downloader for missing objects > knows > the right place to put them. It must not attempt writing outside > user's > home directory. Yes, by default openrct2 places all config, save games, objects, etc in ~/.config/OpenRCT2/. It also respects the XDG_CONFIG_HOME environment variable. > > > > I believe uploads to unstable are discouraged only for packages > > > already in testing, so targeting unstable here should be OK. > > > > OK, I've switched back to unstable and staged it locally. I'll > > bundle > > that with any other changes that come from the package review > > process > > before openrct2 gets uploaded to NEW. > > Good, thanks. > > > > I fail to build the package as of > > > e6e4103971b570a179ef5a59a709c24b2fcc5d68 on clean sid chroot with > > > the > > > following error log (only the last lines): > > > > > > [snip] > > > > > > Any ideas what might have gone wrong? > > > > This is the first package I've created that contains multiple > > upstream tarballs as described in uscan(1). The normal openrct2 > > build > > downloads a handful of pre-generated metadata (the "objects" > > component > > tarball) and custom scenarios for the opening sequence (the "title- > > sequences" component tarball) at build time, but we can't do that > > in > > Debian. So I added them as additional sources. The error you're > > seeing > > indicates that for some reason they aren't being properly extracted > > into the source directory prior to starting the build. > > Indeed, this must be the problem on my side, due to incorrectly > created > upstream tarball. I admit I know very little about multiple upstream > tarballs (MUTs). > > However, in this case it looks like the split of the MUT to > individual > source packages would make sense. They seem to have version numbers > on > their own, and I notice no signs in them being released in a > lockstep. > For example, it might happen that at some point objects or > title-sequences are released more often that the main game, and > bumping > Debian version of the MUT just to update the components will become > tedious. What do you think about splitting? It would certainly be easy enough to split the components out into three distinct source packages: openrct2 openrct2-objects openrct2-title-sequences And then have openrct2 depend on the other two to properly bring in all the required bits of the program. I set things up using MUTs to try to reflect upstream's build process as closely as possible, but as you point out having three distinct packages will allow more flexibility when updating in the future. My only question would be if having three different packages would make the RFS process any harder, and if I should then file two more RFS bugs for the two new source packages. > > > I personally use lxc containers which I can quickly spin up to > > get a > > clean minimal build environment, and the following commands build > > the > > openrct2 package for me: > > > >dget -x > > https://mentors.debian.net/debian/pool/main/o/openrct2/openrct2_0.3.3+dfsg-1.dsc > > dpkg-source -x openrct2_0.3.3+dfsg-1.dsc > > cd openrct2-0.3.3+dfsg/ > > debuild > > > > I know there's several additional tools for building packages > > (like > > pbuilder), but I haven't really had a strong need to get those > > working > > due to my use of lxc. > > I see. I have no knowledge about lxc builder, but somehow I imagine > that > it should have the same build sequence. > > Best, > Andrius > Thanks for helping me build a better package(s)! Mathias signature.asc Description: Th
Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
Hi Mathias, On 2021-03-15 19:28, Mathias Gibbens wrote: >> I have reviewed your packaging, and saw libcurl4-openssl-dev among >> the build dependencies. Do you know what does openrct2 need it for? >> My concern here is that in-game network access/downloads may >> interfere with Debian policies. > > Grepping through the code, it appears that openrct2 uses the libcurl > dependency primarily in two places. The first is to automatically > download missing objects referenced in a scenario or save game. There's > a vibrant community of openrct2 fans who create custom scenery objects, > and it looks like this is a helper to fetch missing custom objects. > I've not gotten into this aspect of the game, so I haven't personally > used it. The second place libcurl is used is in support of multiplayer > connection making. > > Both of these only happen when the end-user is running the program, > so I think that shouldn't run afoul of Policy. (I know network access > during build is verboten, which is why there's an > override_dh_auto_configure in d/rules and corresponding component > source tars [more below].) Thanks for checking this out. Both use cases are indeed not violating the policy. However, we need to make sure the downloader for missing objects knows the right place to put them. It must not attempt writing outside user's home directory. >> I believe uploads to unstable are discouraged only for packages >> already in testing, so targeting unstable here should be OK. > > OK, I've switched back to unstable and staged it locally. I'll bundle > that with any other changes that come from the package review process > before openrct2 gets uploaded to NEW. Good, thanks. >> I fail to build the package as of >> e6e4103971b570a179ef5a59a709c24b2fcc5d68 on clean sid chroot with the >> following error log (only the last lines): >> >> [snip] >> >> Any ideas what might have gone wrong? > > This is the first package I've created that contains multiple > upstream tarballs as described in uscan(1). The normal openrct2 build > downloads a handful of pre-generated metadata (the "objects" component > tarball) and custom scenarios for the opening sequence (the "title- > sequences" component tarball) at build time, but we can't do that in > Debian. So I added them as additional sources. The error you're seeing > indicates that for some reason they aren't being properly extracted > into the source directory prior to starting the build. Indeed, this must be the problem on my side, due to incorrectly created upstream tarball. I admit I know very little about multiple upstream tarballs (MUTs). However, in this case it looks like the split of the MUT to individual source packages would make sense. They seem to have version numbers on their own, and I notice no signs in them being released in a lockstep. For example, it might happen that at some point objects or title-sequences are released more often that the main game, and bumping Debian version of the MUT just to update the components will become tedious. What do you think about splitting? > I personally use lxc containers which I can quickly spin up to get a > clean minimal build environment, and the following commands build the > openrct2 package for me: > >dget -x > https://mentors.debian.net/debian/pool/main/o/openrct2/openrct2_0.3.3+dfsg-1.dsc > dpkg-source -x openrct2_0.3.3+dfsg-1.dsc > cd openrct2-0.3.3+dfsg/ > debuild > > I know there's several additional tools for building packages (like > pbuilder), but I haven't really had a strong need to get those working > due to my use of lxc. I see. I have no knowledge about lxc builder, but somehow I imagine that it should have the same build sequence. Best, Andrius
Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
Hi Andrius, Thanks for your feedback! To answer your questions: > I have reviewed your packaging, and saw libcurl4-openssl-dev among > the build dependencies. Do you know what does openrct2 need it for? > My concern here is that in-game network access/downloads may > interfere with Debian policies. Grepping through the code, it appears that openrct2 uses the libcurl dependency primarily in two places. The first is to automatically download missing objects referenced in a scenario or save game. There's a vibrant community of openrct2 fans who create custom scenery objects, and it looks like this is a helper to fetch missing custom objects. I've not gotten into this aspect of the game, so I haven't personally used it. The second place libcurl is used is in support of multiplayer connection making. Both of these only happen when the end-user is running the program, so I think that shouldn't run afoul of Policy. (I know network access during build is verboten, which is why there's an override_dh_auto_configure in d/rules and corresponding component source tars [more below].) > I believe uploads to unstable are discouraged only for packages > already in testing, so targeting unstable here should be OK. OK, I've switched back to unstable and staged it locally. I'll bundle that with any other changes that come from the package review process before openrct2 gets uploaded to NEW. > I fail to build the package as of > e6e4103971b570a179ef5a59a709c24b2fcc5d68 on clean sid chroot with the > following error log (only the last lines): > > [snip] > > Any ideas what might have gone wrong? This is the first package I've created that contains multiple upstream tarballs as described in uscan(1). The normal openrct2 build downloads a handful of pre-generated metadata (the "objects" component tarball) and custom scenarios for the opening sequence (the "title- sequences" component tarball) at build time, but we can't do that in Debian. So I added them as additional sources. The error you're seeing indicates that for some reason they aren't being properly extracted into the source directory prior to starting the build. I personally use lxc containers which I can quickly spin up to get a clean minimal build environment, and the following commands build the openrct2 package for me: dget -x https://mentors.debian.net/debian/pool/main/o/openrct2/openrct2_0.3.3+dfsg-1.dsc dpkg-source -x openrct2_0.3.3+dfsg-1.dsc cd openrct2-0.3.3+dfsg/ debuild I know there's several additional tools for building packages (like pbuilder), but I haven't really had a strong need to get those working due to my use of lxc. Mathias signature.asc Description: This is a digitally signed message part
Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
Hi again, I fail to build the package as of e6e4103971b570a179ef5a59a709c24b2fcc5d68 on clean sid chroot with the following error log (only the last lines): find ./debian -name libopenrct2.a -delete find ./debian -empty -type d -delete make[1]: Leaving directory '/<>' dh_install dh_install: warning: Cannot find (any matches for) "objects/*" (tried in ., debian/tmp) dh_install: warning: openrct2-data missing files: objects/* dh_install: warning: Cannot find (any matches for) "title-sequences/*" (tried in ., debian/tmp) dh_install: warning: openrct2-data missing files: title-sequences/* dh_install: error: missing files, aborting make: *** [debian/rules:8: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Any ideas what might have gone wrong? Best, Andrius
Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
Hi Mathias, Thank you for an interesting ITP. It would be nice to have openrct2 in Debian. I have reviewed your packaging, and saw libcurl4-openssl-dev among the build dependencies. Do you know what does openrct2 need it for? My concern here is that in-game network access/downloads may interfere with Debian policies. On 2021-03-13 20:21, Mathias Gibbens wrote: > Upstream released v0.3.3 earlier today, and I have updated my > packaging accordingly. Additionally, I updated the distribution to > experimental, as the bullseye freeze is in full swing. I believe uploads to unstable are discouraged only for packages already in testing, so targeting unstable here should be OK. Best, Andrius
Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
retitle 979592 RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2 thanks Upstream released v0.3.3 earlier today, and I have updated my packaging accordingly. Additionally, I updated the distribution to experimental, as the bullseye freeze is in full swing. As usual, you can download my package with dget -x https://mentors.debian.net/debian/pool/main/o/openrct2/openrct2_0.3.3+dfsg-1.dsc Changes since the previous upload can also be viewed on salsa: https://salsa.debian.org/gibmat/openrct2/-/commit/e6e4103971b570a179ef5a59a709c24b2fcc5d68 Thanks, Mathias signature.asc Description: This is a digitally signed message part
