Bug#857131: RFS: fgrun/2016.4.0-0.1 [RC, NMU]

[Markus Wanner]

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]

[Mattia Rizzolo]

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]

[Sean Whitton]

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]

[Markus Wanner]

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]

[Boyuan Yang]

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]

[Markus Wanner]

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]

[Boyuan Yang]

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