Bug#857131: RFS: fgrun/2016.4.0-0.1 [RC, NMU]
control: tag -1 -wontfix On 04/10/2017 05:39 PM, Mattia Rizzolo wrote: > On Fri, Mar 10, 2017 at 07:58:52AM -0700, Sean Whitton wrote: > Markus: would you please take this RFS to its end? I'm rather busy with stretch issues I'd like to fix (and then there's the day job as well...) I take it granted there's enough interest to re-introduce fgrun to unstable (without an unblock request, that doesn't affect stretch, and given there's nothing to possibly upgrade in stretch, there's no need for an upload to experimental, only). @Boyuan: could you please: a) change the watch file to point to the github mirror and release tags you found? (Or provide some other way of automatically fetching an orig.tar.gz?) b) commit your changes to alioth / collab-maint (do you have access, there?) c) add yourself as an uploader, I'm happy to review and sponsor uploads of fgrun for you. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#857131: RFS: fgrun/2016.4.0-0.1 [RC, NMU]
control: tag -1 moreinfo On Fri, Mar 10, 2017 at 07:58:52AM -0700, Sean Whitton wrote: > Since Markus has got involved in this thread, perhaps you can organise a > team upload, and/or add Boyuan to the Uploaders: field. Indeed. Markus: would you please take this RFS to its end? > > * This package has a longstanding unfixed RC bug (FTBFS) and fell out of > > Stretch release. With absolutely zero reverse dependency and migration > > blocking, I believe fgrun should be able to enter unstable even though we > > are > > in freeze now (because it wouldn't affect other packages or Stretch release > > at > > all). > > Note that the release team's freeze policy does not allow this. I'm quite positive that the release team doesn't particularly care about what happens to sid-only packages unless as long as they don't correlate to anything that is in stretch (i.e. a package in stretch starting to depending on a sid-only package). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#857131: RFS: fgrun/2016.4.0-0.1 [RC, NMU]
control: tag -1 +wontfix Dear Boyuan, On Wed, Mar 08, 2017 at 06:53:47PM +0800, Boyuan Yang wrote: > fgrun (2016.4.0-0.1) unstable; urgency=medium > . >* Non-maintainer upload. >* New upstream release. (Closes: #839357) > - Drop patches applied upstream. > - Refresh patches. >* Switch upstream to SourceForge. > - Update corresponding debian/watch file. (Closes: #851845) >* Bump debhelper compat version to v10. >* Apply "wrap-and-sort -abst". >* Update Homepage information on SourceForge. Most of these changes are not appropriate for an NMU, so I'm marking this RFS as 'wontfix'. Since Markus has got involved in this thread, perhaps you can organise a team upload, and/or add Boyuan to the Uploaders: field. > * This package has a longstanding unfixed RC bug (FTBFS) and fell out of > Stretch release. With absolutely zero reverse dependency and migration > blocking, I believe fgrun should be able to enter unstable even though we are > in freeze now (because it wouldn't affect other packages or Stretch release > at > all). Note that the release team's freeze policy does not allow this. -- Sean Whitton signature.asc Description: PGP signature
Bug#857131: RFS: fgrun/2016.4.0-0.1 [RC, NMU]
On 03/08/2017 02:29 PM, Boyuan Yang wrote: > I understand that tarballs are important and could greatly reduce extra works. Well, it's relatively trivial to assemble a tarball. So I think of it more as a sign of upstream's quality awareness (or lack thereof). But well... > Fgrun is really important for flightgear Is it? There's an integrated starter or plane selector, now. And personally, I haven't ever really used fgrun. But that's just a tiny datapoint. Popcon says: 688 installs of flightgear vs 201 of fgrun > and we should not leave it behind, so > I made some investigations. Thanks. > Good news: one of flightgear devs set up a mirror on GitHub and sync every 15 > minutes. If you don't mind using a (frequently synchronized) mirror as > d/watch > upstream, we could switch watch target onto GitHub (with proper tarball > support) and update files in this RFS and/or Alioth Git repo. What do you > think? Yes, that sound's feasible to me. Kind Regards Markus signature.asc Description: OpenPGP digital signature
Bug#857131: RFS: fgrun/2016.4.0-0.1 [RC, NMU]
X-Debbugs-CC: pkg-fgfs-c...@lists.alioth.debian.org 在 2017年3月8日星期三 SGT 下午1:06:02,Markus Wanner 写道: > I kind of allow developers to out-source that task (i.e. to github) and > only provide tags. Unfortunately, I didn't find a similar solution with > Sourceforge, yet. (It seems it's all there, but uscan would have to be > extended to handle Sourceforge.) I understand that tarballs are important and could greatly reduce extra works. Fgrun is really important for flightgear and we should not leave it behind, so I made some investigations. Good news: one of flightgear devs set up a mirror on GitHub and sync every 15 minutes. If you don't mind using a (frequently synchronized) mirror as d/watch upstream, we could switch watch target onto GitHub (with proper tarball support) and update files in this RFS and/or Alioth Git repo. What do you think? -- Sincerely, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Bug#857131: [pkg-fgfs-crew] Bug#857131: RFS: fgrun/2016.4.0-0.1 [RC, NMU]
Hello Boyuan, thanks for your efforts. On 03/08/2017 11:53 AM, Boyuan Yang wrote: > * For new d/watch file: I had a hard time making decisions and finally chose > the > sf.net redirector provided by qa.d.o, which points to flightgear *main* > project > tarballs. The lack of an upstream tarball is the main reason I didn't bother to continue to package fgrun. I might be old fashioned, but if upstream doesn't care bundling a tarball, I don't think the software is worth packaging. I kind of allow developers to out-source that task (i.e. to github) and only provide tags. Unfortunately, I didn't find a similar solution with Sourceforge, yet. (It seems it's all there, but uscan would have to be extended to handle Sourceforge.) How did you generate the tarball? For me to sponsor the package (and justify re-introducing it into unstable), I'd at least want a get-orig-source target that automates the process of obtaining a tarball. > Fgrun is now a subproject of flightgear ... ...eh, no more or less than it used to be, before, AFAIUI. > and I really couldn't find a > better page to parse releases or even git tags. Exactly. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#857131: RFS: fgrun/2016.4.0-0.1 [RC, NMU]
Package: sponsorship-requests Severity: important X-Debbugs-CC: pkg-fgfs-c...@lists.alioth.debian.org Dear mentors and pkg-fgfs-crew maintainers, I am looking for a sponsor for the package "fgrun" into Unstable, perhaps into DELAYED/7 or DELAYED/10. * Package name: fgrun Version : 2016.4.0-0.1 Upstream Author : Frederic Bouvier* URL : https://sourceforge.net/p/flightgear/fgrun/ * License : GPL-2+ Section : games It builds those binary packages: fgrun - graphical frontend for running FlightGear To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fgrun Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/fgrun/ fgrun_2016.4.0-0.1.dsc Alternatively, one can view and download detailed package information on deb- o-matic-amd64: dget -x http://debomatic-amd64.debian.net/distribution#unstable/fgrun/ 2016.4.0-0.1/ Changes since the last upload: fgrun (2016.4.0-0.1) unstable; urgency=medium . * Non-maintainer upload. * New upstream release. (Closes: #839357) - Drop patches applied upstream. - Refresh patches. * Switch upstream to SourceForge. - Update corresponding debian/watch file. (Closes: #851845) * Bump debhelper compat version to v10. * Apply "wrap-and-sort -abst". * Update Homepage information on SourceForge. Detailed explanations: * This package has a longstanding unfixed RC bug (FTBFS) and fell out of Stretch release. With absolutely zero reverse dependency and migration blocking, I believe fgrun should be able to enter unstable even though we are in freeze now (because it wouldn't affect other packages or Stretch release at all). * A stripped src debdiff is attached here to ease your review. The stripped part are translation PO file's updates. * For new d/watch file: I had a hard time making decisions and finally chose the sf.net redirector provided by qa.d.o, which points to flightgear *main* project tarballs. Fgrun is now a subproject of flightgear and I really couldn't find a better page to parse releases or even git tags. [1] Any suggestion would be welcome. [1] This should be the correct page but way too hard to write d/watch file: https://sourceforge.net/p/flightgear/fgrun/ref/next/tags/ -- Sincerely, Boyuan Yangdiff -Nru fgrun-3.4.0.final/CMakeLists.txt fgrun-2016.4.0/CMakeLists.txt --- fgrun-3.4.0.final/CMakeLists.txt 2015-01-19 23:59:25.0 +0800 +++ fgrun-2016.4.0/CMakeLists.txt 2017-03-08 00:57:18.0 +0800 @@ -20,7 +20,7 @@ set(CMAKE_MINSIZEREL_POSTFIX "" CACHE STRING "add a postfix, usually empty on windows") file(READ version versionFile) -string(STRIP ${versionFile} FGRUN_VERSION) +string(STRIP ${versionFile} FGRUN_VERSION) #packaging SET(CPACK_RESOURCE_FILE_LICENSE "${PROJECT_SOURCE_DIR}/COPYING") @@ -33,7 +33,7 @@ # split version string into components, note CMAKE_MATCH_0 is the entire regexp match string(REGEX MATCH "([0-9]+)\\.([0-9]+)" CPACK_PACKAGE_VERSION ${FGRUN_VERSION} ) -set(CPACK_PACKAGE_VERSION_MAJOR ${CMAKE_MATCH_1}) +set(CPACK_PACKAGE_VERSION_MAJOR ${CMAKE_MATCH_1}) set(CPACK_PACKAGE_VERSION_MINOR ${CMAKE_MATCH_2}) message(STATUS "version is ${CPACK_PACKAGE_VERSION_MAJOR} dot ${CPACK_PACKAGE_VERSION_MINOR}") @@ -66,7 +66,7 @@ else (EXISTS ${TEST_3RDPARTY_DIR}) set(MSVC_3RDPARTY_ROOT NOT_FOUND CACHE PATH "Location where the third-party dependencies are extracted") endif (EXISTS ${TEST_3RDPARTY_DIR}) -list(APPEND PLATFORM_LIBS "winmm.lib") +list(APPEND PLATFORM_LIBS "winmm.lib" "Shlwapi.lib") else (MSVC) set(MSVC_3RDPARTY_ROOT NOT_FOUND CACHE PATH "Location where the third-party dependencies are extracted") endif (MSVC) @@ -75,13 +75,16 @@ message(STATUS "3rdparty files located in ${MSVC_3RDPARTY_ROOT}") set( OSG_MSVC "msvc" ) - if (${MSVC_VERSION} EQUAL 1700) + if (${MSVC_VERSION} EQUAL 1900) + set( OSG_MSVC ${OSG_MSVC}140 ) + elseif (${MSVC_VERSION} EQUAL 1800) + set( OSG_MSVC ${OSG_MSVC}120 ) + elseif (${MSVC_VERSION} EQUAL 1700) set( OSG_MSVC ${OSG_MSVC}110 ) elseif (${MSVC_VERSION} EQUAL 1600) set( OSG_MSVC ${OSG_MSVC}100 ) - else (${MSVC_VERSION} EQUAL 1700) - set( OSG_MSVC ${OSG_MSVC}90 ) - endif (${MSVC_VERSION} EQUAL 1700) + endif () + if (CMAKE_CL_64) set( OSG_MSVC ${OSG_MSVC}-64 ) set( MSVC_3RDPARTY_DIR 3rdParty.x64 ) @@ -97,7 +100,10 @@ set (CMAKE_LIBRARY_PATH ${FLTK_DIR}/lib ${MSVC_3RDPARTY_ROOT}/${MSVC_3RDPARTY_DIR}/lib ${MSVC_3RDPARTY_ROOT}/install/${OSG_MSVC}/OpenScenegraph/lib ${MSVC_3RDPARTY_ROOT}/install/${OSG_MSVC}/SimGear/lib ) set (CMAKE_INCLUDE_PATH ${FLTK_DIR}/include ${MSVC_3RDPARTY_ROOT}/${MSVC_3RDPARTY_DIR}/include ${MSVC_3RDPARTY_ROOT}/install/${OSG_MSVC}/OpenScenegraph/include