From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: [PATCH] Add MARS shooter. Date: Sun, 20 Sep 2015 12:08:03 +0200 Message-ID: <87lhc15rp8.fsf@elephly.net> References: <8761377ct3.fsf@elephly.net> <20150919121718.1eeccc11@openmailbox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdbXZ-0002qO-Fq for guix-devel@gnu.org; Sun, 20 Sep 2015 06:08:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZdbXV-0002V1-DP for guix-devel@gnu.org; Sun, 20 Sep 2015 06:08:13 -0400 Received: from sender163-mail.zoho.com ([74.201.84.163]:25248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdbXV-0002Ux-5h for guix-devel@gnu.org; Sun, 20 Sep 2015 06:08:09 -0400 In-reply-to: <20150919121718.1eeccc11@openmailbox.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Eric Bavier Cc: guix-devel Eric Bavier writes: >> I could not get sound to work, unfortunately, because /dev/dsp does not >> exist on my machine. It’s not a problem with the package, but maybe >> someone could give me a hint about what kernel module to load to get >> this device. > > Same on my machine. I learned about the ossdp software, which may > help. http://sourceforge.net/projects/osspd/ Yes, this would help, but I think it’s unnecessary. OpenAL was built with ALSA and Pulseaudio backends, yet neither seems to work: ~~~~~~~~~ rekado@banana $ ALSOFT_LOGLEVEL=3 /gnu/store/hgx7fddl7ss45jhv4bns2837nd4x1h0f-mars-0.7.5-cc855d04409/bin/mars AL lib: (II) alc_initconfig: Supported backends: pulse, alsa, oss, null, wave ... AL lib: (II) GetConfigValue: Key general:rt-prio not found AL lib: (II) GetConfigValue: Key general:resampler not found AL lib: (II) GetConfigValue: Key general:trap-al-error not found AL lib: (II) GetConfigValue: Key general:trap-alc-error not found AL lib: (II) GetConfigValue: Key reverb:boost not found AL lib: (II) GetConfigValue: Key reverb:emulate-eax not found AL lib: (II) GetConfigValue: Key general:drivers not found AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse" AL lib: (WW) alc_initconfig: Failed to initialize backend "alsa" AL lib: (II) GetConfigValue: Key oss:device not found AL lib: (II) GetConfigValue: Key oss:capture not found AL lib: (II) alc_initconfig: Initialized backend "oss" AL lib: (II) alc_initconfig: Added "oss" for playback AL lib: (II) alc_initconfig: Added "oss" for capture ... AL lib: (EE) oss_open_playback: Could not open /dev/dsp: No such file or directory Failed to open the audio device ... ~~~~~~~~~ I’ll try to get some more information about the failure to initialise the “alsa” backend, but it seems to me that this is a problem with our “openal” package. >> +(define-public mars >> + ;; The latest release on SourceForge relies on an unreleased version of SFML >> + ;; with a different API, so we take the latest version from the official >> + ;; repository on Github. >> + (let ((commit "c855d04409")) >> + (package >> + (name "mars") >> + (version (string-append "0.7.5-c" commit )) > > I realize we have no guidelines in the manual concerning the version > field for git checkouts, but I wonder whether we should, as it comes up > a bit. Several existing packages use (string-append "1.2.3." commit), > where "1.2.3" is the version of the corresponding source. One other > package uses the (string-append "1.2.3-c" commit) method, and another > uses (string-append "1.2.3-" commit. I personally prefer the "-" > notation, since it distinguishes the commit hash from the version > number (does it confuse any internal logic that assumes a package > version number is the last component of the store path following a > dash?). In this case, the "-c" seems confusing because the commit hash > itself begins with a 'c'. True. I have no real preference. If an update to a more recent commit makes the introduction of an ordering character necessary it could still be introduced to force a particular ordering. >> + (source (origin >> + (method git-fetch) >> + (uri (git-reference >> + (url "https://github.com/thelaui/M.A.R.S..git") >> + (commit commit))) > > guix lint should warn now about the 'file-name' of the origin. Oh, right. I’ll fix it. >> + (sha256 >> + (base32 >> + "1r4c5gap1z2zsv4yjd34qriqkxaq4lb4rykapyzkkdf4g36lc3nh")) >> + (patches (list (search-patch "mars-sfml-2.3.patch") > > As mentioned on IRC, I had trouble applying this patch because some DOS > line-endings went missing somewhere. We just need to make sure they > are preserved by git. The patch looks fine when I inspect the commit. It still has the DOS line-endings, so I don’t think this will be a problem when I push it. >> + (search-patch "mars-install.patch"))))) >> + (build-system cmake-build-system) >> + (arguments >> + `(#:tests? #f ; There are no tests >> + #:phases >> + (modify-phases %standard-phases >> + (add-after 'unpack 'fix-install-path >> + (lambda _ >> + (substitute* "src/CMakeLists.txt" >> + (("\\$\\{CMAKE_INSTALL_PREFIX\\}/games") >> + "${CMAKE_INSTALL_PREFIX}/bin")))) > > As in the following phase, could you return #t after the 'substitute*'? Yes, I forgot this when I broke this up into two phases. >> + (add-after 'unpack 'fix-data-path >> + (lambda* (#:key outputs #:allow-other-keys) >> + (substitute* "src/System/settings.cpp" >> + (("C_dataPath = \"./data/\";") >> + (string-append "C_dataPath = \"" >> + (assoc-ref outputs "out") >> + "/share/games/marsshooter/\";"))) >> + #t))))) >> + (inputs >> + `(("mesa" ,mesa) >> + ("fribidi" ,fribidi) >> + ("taglib" ,taglib) >> + ("sfml" ,sfml))) > > Our sfml package has been failing to build on hydra for a few weeks > because of receiving unexpected hashes from the source downloads. It > appears the authors may have changed the zip file in place when they > released the latest version, and you simply had the previous zip in > your store from before. Hydra seems to not be serving the correct zip > file either. I updated our sfml package about an hour ago. It now downloads the sources from the Github tags/releases, which are (almost) immutable. ~~ Ricardo