[Buildroot] [PATCH v4 1/3] chocolate-doom: new package

[Buildroot] [PATCH v4 1/3] chocolate-doom: new package

[Rodrigo Rebello]

Chocolate Doom is a set of conservative source ports for Doom, Heretic,
Hexen and Strife, with a philosophy of preserving the look, feel, and
bugs of the vanilla versions of each.

http://www.chocolate-doom.org

Signed-off-by: Rodrigo Rebello <rprebello@gmail.com>
---
Changes v3 -> v4:
  - Add patch to fix build for non-x86 architectures (Romain Naour);
  - Add comment to chocolate-doom.mk explaining why autoreconf is
    necessary (Romain Naour);
  - Fix indentation in chocolate-doom.mk (Romain Naour);
  - Remove CHOCOLATE_DOOM_SOURCE from chocolate-doom.mk since it's
    equal to the default value.

Changes v2 -> v3:
  - Rewrite commit message for upstream patch 2 (hopefully clearer now);
  - Include upstream status in patches.
---
 package/Config.in                                  |  1 +
 ...ruct-attribute-directive-ignored-warnings.patch | 49 +++++++++++++
 ...-configure-fix-with-PACKAGE-option-checks.patch | 67 ++++++++++++++++++
 ...se-of-ioperm-inb-outb-to-x86-architecture.patch | 80 ++++++++++++++++++++++
 package/chocolate-doom/Config.in                   | 12 ++++
 package/chocolate-doom/chocolate-doom.hash         |  2 +
 package/chocolate-doom/chocolate-doom.mk           | 44 ++++++++++++
 7 files changed, 255 insertions(+)
 create mode 100644 package/chocolate-doom/0001-Fix-gcc_struct-attribute-directive-ignored-warnings.patch
 create mode 100644 package/chocolate-doom/0002-configure-fix-with-PACKAGE-option-checks.patch
 create mode 100644 package/chocolate-doom/0003-opl-limit-use-of-ioperm-inb-outb-to-x86-architecture.patch
 create mode 100644 package/chocolate-doom/Config.in
 create mode 100644 package/chocolate-doom/chocolate-doom.hash
 create mode 100644 package/chocolate-doom/chocolate-doom.mk

diff --git a/package/Config.in b/package/Config.in
index bdc3063..1eb9ccf 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -204,6 +204,7 @@ comment "Themes"
 endmenu
 
 menu "Games"
+	source "package/chocolate-doom/Config.in"
 	source "package/doom-wad/Config.in"
 	source "package/gnuchess/Config.in"
 	source "package/lbreakout2/Config.in"
diff --git a/package/chocolate-doom/0001-Fix-gcc_struct-attribute-directive-ignored-warnings.patch b/package/chocolate-doom/0001-Fix-gcc_struct-attribute-directive-ignored-warnings.patch
new file mode 100644
index 0000000..bff8e3e
--- /dev/null
+++ b/package/chocolate-doom/0001-Fix-gcc_struct-attribute-directive-ignored-warnings.patch
@@ -0,0 +1,49 @@
+From d9c517d9a4e168c1f7ed28ad0eb9365d69f5ceb2 Mon Sep 17 00:00:00 2001
+From: Rodrigo Rebello <rprebello@gmail.com>
+Date: Thu, 22 Oct 2015 11:29:55 -0200
+Subject: [PATCH] Fix "`gcc_struct' attribute directive ignored" warnings
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Compilation for target architectures other than i386, x86_64 or PowerPC
+(e.g. ARM) caused multiple warnings like the following to appear:
+
+  doomdata.h:75:1: warning: ?gcc_struct? attribute directive ignored
+   } PACKEDATTR mapsidedef_t;
+   ^
+
+This was due to 'gcc_struct' being undefined for these architectures.
+Since that attribute was actually introduced by commit 87db726b9a9ae61ca
+to address the fact that -mms-bitfields became the default for GCC on
+Windows, limit it to that case.
+
+Upstream-status: accepted, not yet released.
+https://github.com/chocolate-doom/chocolate-doom/pull/629
+
+Signed-off-by: Rodrigo Rebello <rprebello@gmail.com>
+---
+ src/doomtype.h | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/doomtype.h b/src/doomtype.h
+index bf0a40e..77c026c 100644
+--- a/src/doomtype.h
++++ b/src/doomtype.h
+@@ -52,10 +52,10 @@
+ 
+ #ifdef __GNUC__
+ 
+-#ifdef __clang__
+-#define PACKEDATTR __attribute__((packed))
+-#else
++#if defined(_WIN32) && !defined(__clang__)
+ #define PACKEDATTR __attribute__((packed,gcc_struct))
++#else
++#define PACKEDATTR __attribute__((packed))
+ #endif
+ 
+ #else
+-- 
+2.1.4
+
diff --git a/package/chocolate-doom/0002-configure-fix-with-PACKAGE-option-checks.patch b/package/chocolate-doom/0002-configure-fix-with-PACKAGE-option-checks.patch
new file mode 100644
index 0000000..f4d09f5
--- /dev/null
+++ b/package/chocolate-doom/0002-configure-fix-with-PACKAGE-option-checks.patch
@@ -0,0 +1,67 @@
+From fd12fa91aa8e35dbd3ffa5bfe055baf6bde0cd63 Mon Sep 17 00:00:00 2001
+From: Rodrigo Rebello <rprebello@gmail.com>
+Date: Thu, 22 Oct 2015 15:28:11 -0200
+Subject: [PATCH] configure: fix --with-PACKAGE option checks
+
+Options of the form --with-PACKAGE[=yes] (e.g. --with-libpng), when
+passed to configure, were being treated as though --without-PACKAGE had
+been given.
+
+Although the intention is to have configure check and use PACKAGE by
+default if it's available, thus requiring the user to pass an option
+only if PACKAGE must NOT be used, there are times when the opposite
+might be desired (i.e. the user wants to indicate PACKAGE MUST be used).
+Moreover, allowing --with-PACKAGE and behaving as if --without-PACKAGE
+had been specified is in itself quite confusing.
+
+Fix that by testing the result of 'with_PACKAGE' in configure.ac and
+acting accordingly instead of blindly assuming a 'no'.
+
+Upstream-status: accepted, not yet released.
+https://github.com/chocolate-doom/chocolate-doom/pull/630
+
+Signed-off-by: Rodrigo Rebello <rprebello@gmail.com>
+---
+ configure.ac | 18 ++++++++++++++++--
+ 1 file changed, 16 insertions(+), 2 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index ee97fe2..7b03485 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -80,7 +80,14 @@ AC_SDL_MAIN_WORKAROUND([
+         [Build without libsamplerate @<:@default=check@:>@]),
+     [],
+     [
+-        AC_CHECK_LIB(samplerate, src_new)
++        [with_libsamplerate=check]
++    ])
++    AS_IF([test "x$with_libsamplerate" != xno], [
++        AC_CHECK_LIB(samplerate, src_new, [], [
++            AS_IF([test "x$with_libsamplerate" != xcheck], [AC_MSG_FAILURE(
++                [--with-libsamplerate was given, but test for libsamplerate failed])
++            ])
++        ])
+     ])
+     # Check for libpng.
+     AC_ARG_WITH([libpng],
+@@ -88,8 +95,15 @@ AC_SDL_MAIN_WORKAROUND([
+         [Build without libpng @<:@default=check@:>@]),
+     [],
+     [
++        [with_libpng=check]
++    ])
++    AS_IF([test "x$with_libpng" != xno], [
+         AC_CHECK_LIB(z, zlibVersion)
+-        AC_CHECK_LIB(png, png_get_io_ptr)
++        AC_CHECK_LIB(png, png_get_io_ptr, [], [
++            AS_IF([test "x$with_libpng" != xcheck], [AC_MSG_FAILURE(
++                [--with-libpng was given, but test for libpng failed])
++            ])
++        ])
+     ])
+     AC_CHECK_LIB(m, log)
+ 
+-- 
+2.1.4
+
diff --git a/package/chocolate-doom/0003-opl-limit-use-of-ioperm-inb-outb-to-x86-architecture.patch b/package/chocolate-doom/0003-opl-limit-use-of-ioperm-inb-outb-to-x86-architecture.patch
new file mode 100644
index 0000000..860f563
--- /dev/null
+++ b/package/chocolate-doom/0003-opl-limit-use-of-ioperm-inb-outb-to-x86-architecture.patch
@@ -0,0 +1,80 @@
+From 87c7399305b30045a856d737bbfd8f59b8f52392 Mon Sep 17 00:00:00 2001
+From: Rodrigo Rebello <rprebello@gmail.com>
+Date: Fri, 6 Nov 2015 12:14:01 -0200
+Subject: [PATCH] opl: limit use of ioperm/inb/outb to x86 architecture
+
+The use of I/O ports in the Linux driver to directly control OPL chips
+is x86 specific and only really makes sense for x86-based PC's with
+compatible hardware.
+
+For some architectures (e.g. ARM), ioperm, inb and outb do exist and are
+detected by the configure script (via AC_CHECK_FUNCS(ioperm)), but their
+use is inappropriate in these cases and should be avoided.
+
+In some other scenarios, like when using a GNU toolchain + uClibc for
+PowerPC, the build even fails with the following error:
+
+  opl_linux.c:26:20: fatal error: sys/io.h: No such file or directory
+
+That is so because ioperm() is exported by uClibc and gets detected by
+configure, which enables the "Linux" driver via definition of
+HAVE_IOPERM, but in practice 'sys/io.h' is missing for ppc (inb/outb is
+not implemented, and the call to ioperm() would return EIO anyway).
+
+So, besides testing for HAVE_IOPERM, also test if either __i386__ or
+__x86_64__ are defined before enabling this OPL driver.
+
+Upstream-status: accepted, not yet released.
+https://github.com/chocolate-doom/chocolate-doom/pull/638
+
+Signed-off-by: Rodrigo Rebello <rprebello@gmail.com>
+---
+ opl/opl.c       | 4 ++--
+ opl/opl_linux.c | 4 ++--
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/opl/opl.c b/opl/opl.c
+index 60f027d..0d25689 100644
+--- a/opl/opl.c
++++ b/opl/opl.c
+@@ -27,7 +27,7 @@
+ 
+ //#define OPL_DEBUG_TRACE
+ 
+-#ifdef HAVE_IOPERM
++#if (defined(__i386__) || defined(__x86_64__)) && defined(HAVE_IOPERM)
+ extern opl_driver_t opl_linux_driver;
+ #endif
+ #if defined(HAVE_LIBI386) || defined(HAVE_LIBAMD64)
+@@ -40,7 +40,7 @@ extern opl_driver_t opl_sdl_driver;
+ 
+ static opl_driver_t *drivers[] =
+ {
+-#ifdef HAVE_IOPERM
++#if (defined(__i386__) || defined(__x86_64__)) && defined(HAVE_IOPERM)
+     &opl_linux_driver,
+ #endif
+ #if defined(HAVE_LIBI386) || defined(HAVE_LIBAMD64)
+diff --git a/opl/opl_linux.c b/opl/opl_linux.c
+index 5df5d46..19e4c3e 100644
+--- a/opl/opl_linux.c
++++ b/opl/opl_linux.c
+@@ -17,7 +17,7 @@
+ 
+ #include "config.h"
+ 
+-#ifdef HAVE_IOPERM
++#if (defined(__i386__) || defined(__x86_64__)) && defined(HAVE_IOPERM)
+ 
+ #include <stdio.h>
+ #include <string.h>
+@@ -99,5 +99,5 @@ opl_driver_t opl_linux_driver =
+     OPL_Timer_AdjustCallbacks,
+ };
+ 
+-#endif /* #ifdef HAVE_IOPERM */
++#endif /* #if (defined(__i386__) || defined(__x86_64__)) && defined(HAVE_IOPERM) */
+ 
+-- 
+2.1.4
+
diff --git a/package/chocolate-doom/Config.in b/package/chocolate-doom/Config.in
new file mode 100644
index 0000000..5e0d9c1
--- /dev/null
+++ b/package/chocolate-doom/Config.in
@@ -0,0 +1,12 @@
+config BR2_PACKAGE_CHOCOLATE_DOOM
+	bool "chocolate-doom"
+	depends on BR2_USE_MMU # fork()
+	select BR2_PACKAGE_SDL
+	select BR2_PACKAGE_SDL_MIXER
+	select BR2_PACKAGE_SDL_NET
+	help
+	  Chocolate Doom is a set of conservative source ports for Doom,
+	  Heretic, Hexen and Strife, with a philosophy of preserving the
+	  look, feel, and bugs of the vanilla versions of each.
+
+	  http://www.chocolate-doom.org
diff --git a/package/chocolate-doom/chocolate-doom.hash b/package/chocolate-doom/chocolate-doom.hash
new file mode 100644
index 0000000..bdf5698
--- /dev/null
+++ b/package/chocolate-doom/chocolate-doom.hash
@@ -0,0 +1,2 @@
+# Locally computed
+sha256	ad11e2871667c6fa0658abf2dcba0cd9b26fbd651ee8df55adfdc18ad8fd674a	chocolate-doom-2.2.1.tar.gz
diff --git a/package/chocolate-doom/chocolate-doom.mk b/package/chocolate-doom/chocolate-doom.mk
new file mode 100644
index 0000000..d64ad51
--- /dev/null
+++ b/package/chocolate-doom/chocolate-doom.mk
@@ -0,0 +1,44 @@
+################################################################################
+#
+# chocolate-doom
+#
+################################################################################
+
+CHOCOLATE_DOOM_VERSION = 2.2.1
+CHOCOLATE_DOOM_SITE = http://www.chocolate-doom.org/downloads/$(CHOCOLATE_DOOM_VERSION)
+CHOCOLATE_DOOM_LICENSE = GPLv2+
+CHOCOLATE_DOOM_LICENSE_FILES = COPYING
+CHOCOLATE_DOOM_DEPENDENCIES = sdl sdl_mixer sdl_net
+
+# We're patching configure.ac, so we need to autoreconf
+CHOCOLATE_DOOM_AUTORECONF = YES
+
+# Avoid installing desktop entries, icons, etc.
+CHOCOLATE_DOOM_INSTALL_TARGET_OPTS = DESTDIR=$(TARGET_DIR) install-exec
+
+ifeq ($(BR2_STATIC_LIBS),y)
+# SDL_mixer uses symbols from SDL, but ends up after it on the link
+# cmdline. Fix it by forcing the SDL libs at the very end.
+CHOCOLATE_DOOM_CONF_ENV = LIBS="`$(STAGING_DIR)/usr/bin/sdl-config --static-libs`"
+endif
+
+CHOCOLATE_DOOM_CONF_OPTS = \
+	--disable-sdltest \
+	--with-sdl-prefix=$(STAGING_DIR)/usr \
+	--with-sdl-exec-prefix=$(STAGING_DIR)/usr
+
+ifeq ($(BR2_PACKAGE_LIBPNG),y)
+CHOCOLATE_DOOM_DEPENDENCIES += libpng
+CHOCOLATE_DOOM_CONF_OPTS += --with-libpng
+else
+CHOCOLATE_DOOM_CONF_OPTS += --without-libpng
+endif
+
+ifeq ($(BR2_PACKAGE_LIBSAMPLERATE),y)
+CHOCOLATE_DOOM_DEPENDENCIES += libsamplerate
+CHOCOLATE_DOOM_CONF_OPTS += --with-libsamplerate
+else
+CHOCOLATE_DOOM_CONF_OPTS += --without-libsamplerate
+endif
+
+$(eval $(autotools-package))
-- 
2.1.4

[Buildroot] [PATCH v4 2/3] doom-wad: bump to version 1.9

[Rodrigo Rebello]

Also add a hash file.

The extraction method had to be changed, since the WAD file for this
version is not distributed as a stand-alone file, but comes inside a
2-part DOS self-extracting zip archive.

Signed-off-by: Rodrigo Rebello <rprebello@gmail.com>
---
Changes v1 -> v2:
  - Upgrade shareware Doom WAD file to the latest 1.9 version. This
    allows dropping the comment in the next commit about having to pass
    the option "-gameversion 1.8" to the chocolate-doom-* executables.
---
 package/doom-wad/doom-wad.hash |  2 ++
 package/doom-wad/doom-wad.mk   | 10 ++++++----
 2 files changed, 8 insertions(+), 4 deletions(-)
 create mode 100644 package/doom-wad/doom-wad.hash

diff --git a/package/doom-wad/doom-wad.hash b/package/doom-wad/doom-wad.hash
new file mode 100644
index 0000000..fa069c1
--- /dev/null
+++ b/package/doom-wad/doom-wad.hash
@@ -0,0 +1,2 @@
+# Locally computed
+sha256	cacf0142b31ca1af00796b4a0339e07992ac5f21bc3f81e7532fe1b5e1b486e6	doom19s.zip
diff --git a/package/doom-wad/doom-wad.mk b/package/doom-wad/doom-wad.mk
index 6f4f9da..6c870d0 100644
--- a/package/doom-wad/doom-wad.mk
+++ b/package/doom-wad/doom-wad.mk
@@ -4,16 +4,18 @@
 #
 ################################################################################
 
-DOOM_WAD_VERSION = 1.8
-DOOM_WAD_SOURCE = doom-$(DOOM_WAD_VERSION).wad.gz
+DOOM_WAD_VERSION = 1.9
+DOOM_WAD_SOURCE = doom19s.zip
 DOOM_WAD_SITE = ftp://ftp.idsoftware.com/idstuff/doom
 
 define DOOM_WAD_EXTRACT_CMDS
-	$(ZCAT) $(DL_DIR)/$($(PKG)_SOURCE) > $(@D)/doom1.wad
+	$(UNZIP) -p $(DL_DIR)/$($(PKG)_SOURCE) 'DOOMS_19.[12]' > \
+		$(@D)/doom-$(DOOM_WAD_VERSION).zip
+	$(UNZIP) -d $(@D) $(@D)/doom-$(DOOM_WAD_VERSION).zip DOOM1.WAD
 endef
 
 define DOOM_WAD_INSTALL_TARGET_CMDS
-	$(INSTALL) -m 0644 -D $(@D)/doom1.wad \
+	$(INSTALL) -m 0644 -D $(@D)/DOOM1.WAD \
 		$(TARGET_DIR)/usr/share/games/doom/doom1.wad
 endef
 
-- 
2.1.4

[Buildroot] [PATCH v4 3/3] doom-wad: add BR2_PACKAGE_CHOCOLATE_DOOM as alternate dependency

[Rodrigo Rebello]

The shareware WAD file is also supported by Chocolate Doom.

Signed-off-by: Rodrigo Rebello <rprebello@gmail.com>
---
 package/doom-wad/Config.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/doom-wad/Config.in b/package/doom-wad/Config.in
index aa1d029..edd299b 100644
--- a/package/doom-wad/Config.in
+++ b/package/doom-wad/Config.in
@@ -1,6 +1,6 @@
 config BR2_PACKAGE_DOOM_WAD
 	bool "shareware Doom WAD file"
-	depends on BR2_PACKAGE_PRBOOM
+	depends on BR2_PACKAGE_CHOCOLATE_DOOM || BR2_PACKAGE_PRBOOM
 	help
 	  This will install the shareware wad data file for the doom game.
 
-- 
2.1.4

[Buildroot] [PATCH v4 1/3] chocolate-doom: new package

[Thomas Petazzoni]

Dear Rodrigo Rebello,

On Fri,  6 Nov 2015 17:47:57 -0200, Rodrigo Rebello wrote:
> Chocolate Doom is a set of conservative source ports for Doom, Heretic,
> Hexen and Strife, with a philosophy of preserving the look, feel, and
> bugs of the vanilla versions of each.
> 
> http://www.chocolate-doom.org
> 
> Signed-off-by: Rodrigo Rebello <rprebello@gmail.com>

I've applied, thanks! I'd like to say that I really appreciated the
fact that all three patches had already been submitted and accepted
upstream. It really gives more confidence in accepting them as a
temporary solution until upstream does a new release.

I have one comment though.

> +ifeq ($(BR2_STATIC_LIBS),y)
> +# SDL_mixer uses symbols from SDL, but ends up after it on the link
> +# cmdline. Fix it by forcing the SDL libs at the very end.
> +CHOCOLATE_DOOM_CONF_ENV = LIBS="`$(STAGING_DIR)/usr/bin/sdl-config --static-libs`"
> +endif

It would be great if this was fixed properly in the chocolate-doom
build system. An obvious suggestion is to use pkg-config, which handles
static linking scenarios a lot better.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v4 3/3] doom-wad: add BR2_PACKAGE_CHOCOLATE_DOOM as alternate dependency

[Thomas Petazzoni]

Dear Rodrigo Rebello,

On Fri,  6 Nov 2015 17:47:59 -0200, Rodrigo Rebello wrote:
> The shareware WAD file is also supported by Chocolate Doom.
> 
> Signed-off-by: Rodrigo Rebello <rprebello@gmail.com>
> ---
>  package/doom-wad/Config.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v4 2/3] doom-wad: bump to version 1.9

[Thomas Petazzoni]

Dear Rodrigo Rebello,

On Fri,  6 Nov 2015 17:47:58 -0200, Rodrigo Rebello wrote:

> diff --git a/package/doom-wad/doom-wad.hash b/package/doom-wad/doom-wad.hash
> new file mode 100644
> index 0000000..fa069c1
> --- /dev/null
> +++ b/package/doom-wad/doom-wad.hash
> @@ -0,0 +1,2 @@
> +# Locally computed
> +sha256	cacf0142b31ca1af00796b4a0339e07992ac5f21bc3f81e7532fe1b5e1b486e6	doom19s.zip
> diff --git a/package/doom-wad/doom-wad.mk b/package/doom-wad/doom-wad.mk
> index 6f4f9da..6c870d0 100644
> --- a/package/doom-wad/doom-wad.mk
> +++ b/package/doom-wad/doom-wad.mk
> @@ -4,16 +4,18 @@
>  #
>  ################################################################################
>  
> -DOOM_WAD_VERSION = 1.8
> -DOOM_WAD_SOURCE = doom-$(DOOM_WAD_VERSION).wad.gz
> +DOOM_WAD_VERSION = 1.9
> +DOOM_WAD_SOURCE = doom19s.zip

So shouldn't the version be "19" and not "1.9" ? It is a bit weird to
have a version not used in the _SOURCE variable. Or if you really want
to have 1.9 as the version, then:

	DOOM_WAD_SOURCE = doom$(subst .,,$(DOOM_WAD_VERSION))s.zip

>  DOOM_WAD_SITE = ftp://ftp.idsoftware.com/idstuff/doom

However, the main reason I didn't apply is because this server seems to
be unavailable at the moment. So I can't test the package, and it would
cause build failures in the autobuilders.

Are you also experiencing the same issue?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v4 2/3] doom-wad: bump to version 1.9

[Rodrigo Rebello]

Thomas,

2015-12-23 20:37 GMT-02:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Dear Rodrigo Rebello,
>
> On Fri,  6 Nov 2015 17:47:58 -0200, Rodrigo Rebello wrote:
>
>> diff --git a/package/doom-wad/doom-wad.hash b/package/doom-wad/doom-wad.hash
>> new file mode 100644
>> index 0000000..fa069c1
>> --- /dev/null
>> +++ b/package/doom-wad/doom-wad.hash
>> @@ -0,0 +1,2 @@
>> +# Locally computed
>> +sha256       cacf0142b31ca1af00796b4a0339e07992ac5f21bc3f81e7532fe1b5e1b486e6        doom19s.zip
>> diff --git a/package/doom-wad/doom-wad.mk b/package/doom-wad/doom-wad.mk
>> index 6f4f9da..6c870d0 100644
>> --- a/package/doom-wad/doom-wad.mk
>> +++ b/package/doom-wad/doom-wad.mk
>> @@ -4,16 +4,18 @@
>>  #
>>  ################################################################################
>>
>> -DOOM_WAD_VERSION = 1.8
>> -DOOM_WAD_SOURCE = doom-$(DOOM_WAD_VERSION).wad.gz
>> +DOOM_WAD_VERSION = 1.9
>> +DOOM_WAD_SOURCE = doom19s.zip
>
> So shouldn't the version be "19" and not "1.9" ? It is a bit weird to
> have a version not used in the _SOURCE variable. Or if you really want
> to have 1.9 as the version, then:
>
>         DOOM_WAD_SOURCE = doom$(subst .,,$(DOOM_WAD_VERSION))s.zip
>

Indeed, I agree that looks a bit weird. I believe the zip filename
carries the number '19' instead of '1.9' merely because it dates back
to the old times of DOS, when its FAT filesystem imposed quite a few
limitations, like the dot character being allowed in a filename only
to separate it from its extension.

The correct version number, however, is really 1.9, so I'd prefer to
keep DOOM_WAD_VERSION untouched and apply the substitution you
proposed to the zip filename only. Would that be OK to you?

>>  DOOM_WAD_SITE = ftp://ftp.idsoftware.com/idstuff/doom
>
> However, the main reason I didn't apply is because this server seems to
> be unavailable at the moment. So I can't test the package, and it would
> cause build failures in the autobuilders.
>
> Are you also experiencing the same issue?
>

Yes, I have confirmed the server is unresponsive at the moment. I have
found an alternative URL that seems to work fine, though:

http://www.jbserver.com/downloads/games/doom/misc/shareware/doom19s.zip

Should I respin this patch with that temporary URL?

Regards,
Rodrigo

> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

[Buildroot] [PATCH v4 1/3] chocolate-doom: new package

[Rodrigo Rebello]

Thomas,

2015-12-23 20:34 GMT-02:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
[snip]
>> +ifeq ($(BR2_STATIC_LIBS),y)
>> +# SDL_mixer uses symbols from SDL, but ends up after it on the link
>> +# cmdline. Fix it by forcing the SDL libs at the very end.
>> +CHOCOLATE_DOOM_CONF_ENV = LIBS="`$(STAGING_DIR)/usr/bin/sdl-config --static-libs`"
>> +endif
>
> It would be great if this was fixed properly in the chocolate-doom
> build system. An obvious suggestion is to use pkg-config, which handles
> static linking scenarios a lot better.
>

Agreed. I have considered exactly that when I was working on the
patch, but I have decided to leave it for later since a patch for
SDL_mixer is also necessary (SDL_mixer.pc is missing a 'Libs.private'
section with libraries necessary for static linking). I've just had a
look at it and the solution is actually quite simple, so I'll work on
it and propose a patch. That will also be useful to fix a recent ltris
autobuild failure related to static linking as well.

Regards,
Rodrigo

> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

[Buildroot] [PATCH v4 2/3] doom-wad: bump to version 1.9

[Thomas Petazzoni]

Rodrigo,

On Wed, 23 Dec 2015 21:59:08 -0200, Rodrigo Rebello wrote:

> Indeed, I agree that looks a bit weird. I believe the zip filename
> carries the number '19' instead of '1.9' merely because it dates back
> to the old times of DOS, when its FAT filesystem imposed quite a few
> limitations, like the dot character being allowed in a filename only
> to separate it from its extension.
> 
> The correct version number, however, is really 1.9, so I'd prefer to
> keep DOOM_WAD_VERSION untouched and apply the substitution you
> proposed to the zip filename only. Would that be OK to you?

Yes, this is perfectly fine.

> 
> >>  DOOM_WAD_SITE = ftp://ftp.idsoftware.com/idstuff/doom
> >
> > However, the main reason I didn't apply is because this server seems to
> > be unavailable at the moment. So I can't test the package, and it would
> > cause build failures in the autobuilders.
> >
> > Are you also experiencing the same issue?
> 
> Yes, I have confirmed the server is unresponsive at the moment. I have
> found an alternative URL that seems to work fine, though:
> 
> http://www.jbserver.com/downloads/games/doom/misc/shareware/doom19s.zip
> 
> Should I respin this patch with that temporary URL?

Yes, if the hash matches the one from the original server, it is fine
to use an alternate one. Indicate it in the .mk file:

# Official server currently unavailable
# DOOM_WAD_SITE = ....
DOOM_WAD_SITE = http://www.jbserver.com/downloads/games/doom/misc/shareware/

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v4 1/3] chocolate-doom: new package

[Thomas Petazzoni]

Dear Rodrigo Rebello,

On Wed, 23 Dec 2015 22:33:01 -0200, Rodrigo Rebello wrote:

> Agreed. I have considered exactly that when I was working on the
> patch, but I have decided to leave it for later since a patch for
> SDL_mixer is also necessary (SDL_mixer.pc is missing a 'Libs.private'
> section with libraries necessary for static linking). I've just had a
> look at it and the solution is actually quite simple, so I'll work on
> it and propose a patch. That will also be useful to fix a recent ltris
> autobuild failure related to static linking as well.

Indeed, according to your description of the problem, it is really
SDL_mixer.pc that needs to be fixed. However, if I looked correctly,
chocolate-doom doesn't use pkg-config to find libraries, so it would
have to be changed as well.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v4 1/3] chocolate-doom: new package

[Rodrigo Rebello]

Thomas,

2015-12-24 5:29 GMT-02:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Dear Rodrigo Rebello,
>
> On Wed, 23 Dec 2015 22:33:01 -0200, Rodrigo Rebello wrote:
>
>> Agreed. I have considered exactly that when I was working on the
>> patch, but I have decided to leave it for later since a patch for
>> SDL_mixer is also necessary (SDL_mixer.pc is missing a 'Libs.private'
>> section with libraries necessary for static linking). I've just had a
>> look at it and the solution is actually quite simple, so I'll work on
>> it and propose a patch. That will also be useful to fix a recent ltris
>> autobuild failure related to static linking as well.
>
> Indeed, according to your description of the problem, it is really
> SDL_mixer.pc that needs to be fixed. However, if I looked correctly,
> chocolate-doom doesn't use pkg-config to find libraries, so it would
> have to be changed as well.
>

Yes, both SDL_mixer and chocolate-doom need patching. That's actually
what I meant in my previous email. I'll be working on that soon.

Regards,
Rodrigo

> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

[Buildroot] [PATCH v4 1/3] chocolate-doom: new package

[Romain Naour]

Hi Rodrigo, Thomas, All,

Le 24/12/2015 12:11, Rodrigo Rebello a ?crit :
> Thomas,
> 
> 2015-12-24 5:29 GMT-02:00 Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com>:
>> Dear Rodrigo Rebello,
>>
>> On Wed, 23 Dec 2015 22:33:01 -0200, Rodrigo Rebello wrote:
>>
>>> Agreed. I have considered exactly that when I was working on the
>>> patch, but I have decided to leave it for later since a patch for
>>> SDL_mixer is also necessary (SDL_mixer.pc is missing a 'Libs.private'
>>> section with libraries necessary for static linking). I've just had a
>>> look at it and the solution is actually quite simple, so I'll work on
>>> it and propose a patch. That will also be useful to fix a recent ltris
>>> autobuild failure related to static linking as well.
>>
>> Indeed, according to your description of the problem, it is really
>> SDL_mixer.pc that needs to be fixed. However, if I looked correctly,
>> chocolate-doom doesn't use pkg-config to find libraries, so it would
>> have to be changed as well.
>>
> 
> Yes, both SDL_mixer and chocolate-doom need patching. That's actually
> what I meant in my previous email. I'll be working on that soon.

Any update on this topic ?

I looked at chocolate-doom static build failure [1] and I have some comments to
complete this discussion.

If libmad is available, SDL_mixer forget to add -lmad in SDL_mixer.pc file for
static build only (you're right it should have a 'Libs.private' section). This
means that all SDL_mixer will unlikely forget -lmad in their LDFALGS leading to
the build failure similar to :

[...]sysroot/usr/lib/libSDL_mixer.a(music_mad.o): In function `read_next_frame':
music_mad.c:(.text+0xbc): undefined reference to `mad_stream_buffer'
music_mad.c:(.text+0xd0): undefined reference to `mad_frame_decode'
music_mad.c:(.text+0x134): undefined reference to `mad_timer_add'

So, fixing SDL_mixer and adding pkg-config support to chocolate-doom and ltris
(maybe others) is needed if we want to support static only build.

As a quick workaround, we may disable libmad support in SDL_mixer for static
build only ? Thomas ?

Best regards,
Romain

[1]
http://autobuild.buildroot.net/results/e09/e09ea3a64d396bbc855acf7c07fcbea28fb2395d/build-end.log