Build issues on Debian 8 Jessie

mdeguzis commented 8 years ago

SuperTux version: System information:

OS: Debian Jessie ARCH: amd64

Expected behavior

Using standard debhelper, build configures correctly.

Actual behavior

Build fails configure stage:

 debian/rules build
dh build 
   dh_testdir
   dh_auto_configure
CMake Error: The source directory "/tmp/buildd/supertux-0.5.0+git+bsos/build/--disable-dependency-tracking" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
dh_auto_configure: ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --libdir=${prefix}/lib/x86_64-linux-gnu --libexecdir=${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking returned exit code 1
debian/rules:4: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Log: http://sprunge.us/jKKU

Steps to reproduce actual behavior

Attempt to build with simple debian/rules that does not override dh_auto_configure.

tobbi commented 8 years ago

It looks like there needs to be a space in between the directory and the --disable-dependency-tracking flag.

mdeguzis commented 8 years ago

@tobbi, hmm, is this due to the "$@" in configure? Sorry if I missed an obvious here.

dh_auto_configure: ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --libdir=${prefix}/lib/x86_64-linux-gnu --libexecdir=${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking

tobbi commented 8 years ago

I have to say that I am a noob when it comes to build systems, so I am likely not any help at all. Someone like maths22 or mt will take a look at it.

mdeguzis commented 8 years ago

Ok, for now I am just overriding dh_auto_configure with:

override_dh_auto_configure:
        rm -rf build && mkdir build
        cd build && cmake ..
        make -C build

..Which is part of the build instructions, yes I know. But, for what it's worth, I would argue automatic configuration should* work (configure/make/make install), unless I missed something quite obvious.

Edit, nevermind I think: switched to using dh $@ --buildsystem=cmake ok.

maxteufel commented 8 years ago

The configure script is, in this case, just a very basic wrapper that calls CMake for anyone who expects ./configure && make && make install to work. It doesn't handle any options that are not CMake-compatible.

@ProfessorKaos64 I have no idea why you would need to this. If you have any reason to modify the Debian package, please either use our "official" (maintained mostly by @maths22) Debian package sources or the official Debian ones. In case you want to set up a PPA or the like: the license permits you to do so, but I'd ask you to refrain from that. With OBS we can maintain packages for more distros; including Debian (and derivatives).

mdeguzis commented 8 years ago

I made a package to use myself on SteamOS, a rebuild, as SteamOS is based on Debian Jessie, and carries an old version. I do not just enable backports or Sid/Stretch, of course that is dangerous. I usually backport the package, according to Debian's wiki. I maintain and create/backport packages at packages.libregeek.org not just for SteamOS, but mainly.

jessie (stable) (games): Classic 2D jump 'n run sidescroller with Tux 
0.1.3-3: amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el s390x

sid (unstable) (games): Classic 2D jump 'n run sidescroller with Tux 
0.5.0-1: amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el powerpc ppc64el s390x x32

maxteufel commented 8 years ago

It's best to try the official package backports or our official builds. Really. And for what it's worth, Debian "unstable" is very stable and safe to use for all-day desktop stuff. It just means it's not very stable as in the application's behavior stays consistent. The latter is usually something large enterprises want, but normal users don't.

mdeguzis commented 8 years ago

Really

It is not ideal to mix packages like that. I am not going to just install the deb on SteamOS. Backporting it is the proper way I've always read from Debian's wiki. I won't assume package X will just install on SteamOS/Jessie, just as folks use jessie-backports. I offer a supplemental repo for SteamOS, and having one extra source is more than enough, as I don't want to be mixing packages, or again, asume something is just going to work by including the deb.

maxteufel commented 8 years ago

Mixing packages is indeed a very stupid idea. Using the official backports repo tends not to be, because they're specifically designed to work. Our official builds should work on anything based on Jessie, too.

mdeguzis commented 8 years ago

Yes I understand that, but for safety's sake, I prefer to backport the package, as Valve has it's own repository, even if based on Debian Jessie. I do not override their packages, so I prefer to build against their repo. I understand it will just "work" likely, but for best compatibility, I backport. I implement package pinning so Valve's packages are not overwritten by any build (even in my pbuilder setup unless overriden). But I digress, I won't argue semantics. If a newer version is available upstream, I backport it to SteamOS, typically modeling off of what Debian's official debian/ files already have, if not I create the set myself. The reason I don't include jessie backports, is it can conflict with what Valve already offers in their repository, so I stick to Jessie only, adding only what is missing or out of date.

SuperTux / supertux