Debian Bug report logs - #657793
quakespasm: FTBFS on kfreebsd-* and hurd-*

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: submit@bugs.debian.org

Subject: quakespasm: FTBFS on kfreebsd-*

Date: Sat, 28 Jan 2012 21:31:53 +0000

[Message part 1 (text/plain, inline)]

Package: src:quakespasm
Version: 0.85.6-1
Severity: serious
Tags: patch
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-bsd@lists.debian.org

Hi!

For your package to build on kfreebsd arches, a small change seems to be
needed.  Please see my attached patch.

Log of build failure was:
https://buildd.debian.org/status/fetch.php?pkg=quakespasm&arch=kfreebsd-i386&ver=0.85.6-1&stamp=1327687747

Thanks,
Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

[kfreebsd-support.diff (text/x-patch, attachment)]

Message #10 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Steven Chamberlain <steven@pyro.eu.org>, 657793@bugs.debian.org

Cc: debian-bsd@lists.debian.org

Subject: Re: Bug#657793: quakespasm: FTBFS on kfreebsd-*

Date: Sat, 28 Jan 2012 22:12:28 +0000

severity 657793 normal
thanks

On 28/01/12 21:31, Steven Chamberlain wrote:
> Severity: serious

As far as I can tell, it's never built successfully on kFreeBSD (it
failed differently before), so downgrading this.

> For your package to build on kfreebsd arches, a small change seems to be
> needed.  Please see my attached patch.

The patch looks fine in principle. Do the resulting binaries work? (i.e.
can you play single-player, and preferably also host and join a
networked server?) I notice that QuakeSpasm uses OpenGL: does kFreeBSD
have hardware-accelerated 3D, or if not, is software performance acceptable?

They're probably easiest to test by downloading the shareware version of
Quake 1 and packaging it with game-data-packager; they should also work
with OpenQuartz (GPL), but I don't know the specifics.

Thanks,
    S

Message #17 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: 657793@bugs.debian.org

Subject: Re: Bug#657793: quakespasm: FTBFS on kfreebsd-*

Date: Sat, 28 Jan 2012 22:48:15 +0000

Hi,

On 28/01/12 22:12, Simon McVittie wrote:
> severity 657793 normal

> As far as I can tell, it's never built successfully on kFreeBSD (it
> failed differently before), so downgrading this.

Oh.  I was under the impression that a build failure on kfreebsd is an
RC bug for Wheezy, although I can't find a reference or specific
announcement regarding this.

> Do the resulting binaries work? (i.e.
> can you play single-player, and...

I'm afraid I have no idea;  my only kfreebsd-i386 environment right now
is a slow virtual machine with no Xorg or 3D acceleration...

I thought if we could at least take care of the build failure now, then
someone could file a new bug later if there are any problems running it.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Message #22 received at 657793@bugs.debian.org (full text, mbox, reply):

From: David Banks <amoebae@gmail.com>

To: 657793@bugs.debian.org

Subject: Re: Bug#657793: quakespasm: FTBFS on kfreebsd-*

Date: Tue, 28 Feb 2012 14:48:56 +0000

I have confirmed the patched version builds and runs succesfully on
kfreebsd amd64 sid.  I was only able to use vesa mode as I have an
nvidia card, so I wasn't able to get any reasonable speed at high
resolutions.  The game plays nicely at 320x200 however ;)  I confirmed
that you can play on a LAN using a listen server and a dedicated
server.  I have a quirky NAT configuration that means Quakespasm can't
play against internet servers in my test environment, so I wasn't able
to test that.*

Quakespasm does not have a software renderer.  I think some video
cards have 3D acceleration in kfreebsd, though.  I can imagine
kfreebsd might be a popular platform for dedicated servers.

Patch pushed to alioth (7d831ee5612e6f6dc1096d1d6447c1c3cc48f38a).

* Reported upstream:
<http://sourceforge.net/tracker/index.php?func=detail&aid=3488233&group_id=304914&atid=1285036>.
 I believe this only affects a vanishing minority of setups.

-- 
David Banks  <amoebae@gmail.com>

Message #27 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Svante Signell <svante.signell@telia.com>

To: 657793@bugs.debian.org

Subject: Updated patch for 657793

Date: Tue, 10 Apr 2012 18:00:52 +0200

Package: src:quakespasm
Version: 0.85.6-1
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: kfreebsd, hurd

Hello,

Inlined is an update to the kfreebsd-support.diff patch to work also on GNU/Hurd:

#cat  kfreebsd+gnu-support.diff
--- Quake/net_sys.h.orig        2012-01-28 21:28:41.000000000 +0000
+++ Quake/net_sys.h     2012-04-10 17:32:50.000000000 +0200
@@ -62,7 +62,8 @@
 
 #if defined(__FreeBSD__) || defined(__DragonFly__)     || \
     defined(__OpenBSD__) || defined(__NetBSD__)                || \
-    defined(__MACOSX__)
+    defined(__MACOSX__)  || defined(__FreeBSD_kernel__) || \
+    defined(__GNU__)
 /* struct sockaddr has unsigned char sa_len as the first member in BSD
  * variants and the family member is also an unsigned char instead of an
  * unsigned short. This should matter only when PLATFORM_UNIX is defined,

Message #32 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Svante Signell <svante.signell@telia.com>

To: control <control@bugs.debian.org>

Cc: 657793@bugs.debian.org

Subject: Adding tags to 657793

Date: Wed, 11 Apr 2012 10:08:20 +0200

severity 657793 important
tags 657793 + hurd
usertags 657793 + debian-hurd@lists.debian.org
thanks

Message #41 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Robert Millan <rmh@debian.org>

To: 657793@bugs.debian.org

Subject: NMU to DELAYED/10

Date: Sun, 29 Apr 2012 12:47:43 +0200

[Message part 1 (text/plain, inline)]

tag 657793 pending
thanks

NMU to fix this has been uploaded to DELAYED/10.  Debdiff is attached.

-- 
Robert Millan

[quakespasm.diff (application/octet-stream, attachment)]

Message #48 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Robert Millan <rmh@debian.org>, 657793@bugs.debian.org, Svante Signell <svante.signell@telia.com>

Subject: Re: Bug#657793: NMU to DELAYED/10

Date: Sun, 29 Apr 2012 14:12:38 +0100

On 29/04/12 11:47, Robert Millan wrote:
> NMU to fix this has been uploaded to DELAYED/10.  Debdiff is attached.

Has anyone tested this on Hurd? Does it work? Does Hurd work
sufficiently well that it makes any sense to run a Quake or OpenQuartz
dedicated server, or a rather retro[1] single-player game or network
client, there?

David has packaged a newer upstream version (in pkg-games git) with the
kFreeBSD-only version of the patch, so I'd prefer to fix this by
uploading that, either as-is or with the kFreeBSD-only patch replaced by
Svante's kFreeBSD-and-Hurd version.

    S

[1] David's testing on kFreeBSD indicated that without 3D acceleration,
320x200 resolution is usable, but more than that is too slow

Message #53 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Robert Millan <rmh@debian.org>

To: Simon McVittie <smcv@debian.org>

Cc: 657793@bugs.debian.org, Svante Signell <svante.signell@telia.com>, debian-hurd@lists.debian.org

Subject: Re: Bug#657793: NMU to DELAYED/10

Date: Sun, 29 Apr 2012 15:34:53 +0200

Hi Simon,

2012/4/29 Simon McVittie <smcv@debian.org>:
> On 29/04/12 11:47, Robert Millan wrote:
>> NMU to fix this has been uploaded to DELAYED/10.  Debdiff is attached.
>
> Has anyone tested this on Hurd? Does it work? Does Hurd work
> sufficiently well that it makes any sense to run a Quake or OpenQuartz
> dedicated server, or a rather retro[1] single-player game or network
> client, there?

I leave this for Svante (or debian-hurd) to answer.

> David has packaged a newer upstream version (in pkg-games git) with the
> kFreeBSD-only version of the patch, so I'd prefer to fix this by
> uploading that, either as-is or with the kFreeBSD-only patch replaced by
> Svante's kFreeBSD-and-Hurd version.

No objection with either of these options.  If you upload a new
version during the following 10 days, it will automatically take
precedence to the one in DELAYED.  Or if you need more time, please
let me know.

-- 
Robert Millan

Message #58 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 657793@bugs.debian.org, svante.signell@telia.com, Robert Millan <rmh@debian.org>

Cc: Steven Chamberlain <steven@pyro.eu.org>

Subject: Re: Bug#657793: quakespasm: FTBFS on kfreebsd-*

Date: Tue, 1 May 2012 10:12:13 +0100

On Wed, 11 Apr 2012 at 10:08:20 +0200, Svante Signell wrote:
> severity 657793 important

Please do not exaggerate bug severities.

I can *just about* see how running a Quake dedicated server on the FreeBSD
kernel might be a rational thing to do, if you're really, really keen on
FreeBSD's firewalling... but I don't see any way in which the inability to
run a Quake dedicated server on Hurd could be construed to have
"a major effect on the usability of a package".

Running the client side of quakespasm on either kFreeBSD or Hurd makes
very little sense unless either can do better than VESA graphics.

On Sun, 29 Apr 2012 at 12:47:43 +0200, Robert Millan wrote:
> NMU to fix this has been uploaded to DELAYED/10.  Debdiff is attached.

With that in mind, I don't think this is an appropriate use of an NMU.
Quakespasm has never been present on either of the affected architectures,
so there's certainly no regression here, and I doubt you can claim with
a straight face that any of our users have ever been disappointed to find
that they can't run their Quake server on non-Linux kernels.

Looking more closely at the code being patched, it's a workaround for
mis-design in Quakespasm, which makes it risky to apply patches to
fix the build without also testing thoroughly that the result actually works:

On Sat, 28 Jan 2012 at 21:31:53 +0000, Steven Chamberlain wrote:
> --- Quake/net_sys.h.orig      2012-01-28 21:28:41.000000000 +0000
> +++ Quake/net_sys.h   2012-01-28 21:28:46.000000000 +0000
> @@ -62,7 +62,7 @@
>  
>  #if defined(__FreeBSD__) || defined(__DragonFly__)   || \
>      defined(__OpenBSD__) || defined(__NetBSD__)              || \
> -    defined(__MACOSX__)
> +    defined(__MACOSX__) || defined(__FreeBSD_kernel__)
>  /* struct sockaddr has unsigned char sa_len as the first member in BSD
>   * variants and the family member is also an unsigned char instead of an
>   * unsigned short. This should matter only when PLATFORM_UNIX is defined,

I should have noticed that this was suspicious when I reviewed it before. Given
the structure of the Quakespasm code, it's a reasonable thing for porters
to do, but the right answer for high-quality code would be to make this list
of special cases irrelevant. Why would Quakespasm even care? Why would it be
relevant that Linux vs. BSD networking stacks have this difference?

It turns out that the reason this patch matters is that Quakespasm
defines "qsockaddr" to be a reinvention of struct sockaddr, then passes
a qsockaddr (with a cast, just to make sure there's no type-safety...) to
system functions that expect a struct sockaddr. It's not surprising that this
isn't portable.

Abstracting system differences can be useful if it actually abstracts things
(like GLib's GSocketAddress does), but this isn't abstraction, it's just
reinventing the system type, and then kludging around differences between
OSs by changing its redefinition to match theirs. The right way to be
portable would be to use the system's struct sockaddr as intended, perhaps by
replacing qsockaddr with something like this:

    typedef union {
        struct sockaddr sa;
        struct sockaddr_in sa_in;
    #ifdef HAVE_IPX
        struct sockaddr_ipx sa_ipx;
    #endif
        /* ... and maybe IPv6, sockaddr_storage, etc. too */
    } qsockaddr;

In the absence of a solution like that, we shouldn't blindly "fix the build"
without proper testing - if Quakespasm is making that sort of OS-specific
assumption, getting it to compile successfully on a particular kernel is
no guarantee that it'll work correctly, or fail without crashing, or for that
matter avoid having security vulnerabilities.

If what you're trying to achieve is to increase "proportion of Architecture:any
packages that compile" statistics, I wouldn't object to setting
Architecture: linux-any (or linux-any,kfreebsd-any with reasonable kFreeBSD
testing). I don't think it's to anyone's benefit to publish packages that
compile, have not been tested, and have a significant chance of not working.

    S

Message #63 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 657793@bugs.debian.org, steve@sk2.org

Cc: Robert Millan <rmh@debian.org>, Svante Signell <svante.signell@telia.com>

Subject: Re: Bug#657793: NMU to DELAYED/10

Date: Tue, 1 May 2012 10:39:45 +0100

On Sun, 29 Apr 2012 at 14:12:38 +0100, Simon McVittie wrote:
> David has packaged a newer upstream version (in pkg-games git) with the
> kFreeBSD-only version of the patch, so I'd prefer to fix this by
> uploading that, either as-is or with the kFreeBSD-only patch replaced by
> Svante's kFreeBSD-and-Hurd version.

I think it's reasonable to assume that it does work on kFreeBSD, given David's
testing, and the fact that upstream support Mac OS X - which essentially
has FreeBSD network code, AIUI - with the same implementation.
I'm preparing a release, and I'll clone a bug for "doesn't build on Hurd".

David: while releasing what was in pkg-games git, I ran into some problems.
The upstream branch in quakespasm.git seems to have been filtered
to remove the SDL binaries, but the pristine-tar metadata seems to result in
the original upstream tarball, with SDL binaries for Windows and Mac OS X.
SDL is under the LGPL, so shipping binaries without corresponding source is
a license violation, and we shouldn't do it.

It looks as though the solution might be to add "filter-pristine-tar = True"
to gbp.conf and re-run git-import-orig. I'm not sure why that option isn't
the default :-/

Stephen: you prepared the last upstream release, and it does seem to have a
correctly-filtered orig tarball. What did you do to get that? Do you have
filter-pristine-tar enabled locally or something?

Thanks,
    S

Message #70 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Svante Signell <svante.signell@telia.com>

To: Simon McVittie <smcv@debian.org>

Cc: 657793@bugs.debian.org, Robert Millan <rmh@debian.org>, Steven Chamberlain <steven@pyro.eu.org>

Subject: Re: Bug#657793: quakespasm: FTBFS on kfreebsd-*

Date: Tue, 01 May 2012 12:15:10 +0200

On Tue, 2012-05-01 at 10:12 +0100, Simon McVittie wrote:
> On Wed, 11 Apr 2012 at 10:08:20 +0200, Svante Signell wrote:
> > severity 657793 important
> 
> Please do not exaggerate bug severities.

I do not exaggerate the bug severity: FTBFS with a patch has this
importance level.

> Running the client side of quakespasm on either kFreeBSD or Hurd makes
> very little sense unless either can do better than VESA graphics.

Might be so, but nevertheless, with this tiny patch the package builds
on both kFreeBSD _and_ Hurd.

> If what you're trying to achieve is to increase "proportion of Architecture:any
> packages that compile" statistics, I wouldn't object to setting
> Architecture: linux-any (or linux-any,kfreebsd-any with reasonable kFreeBSD
> testing). I don't think it's to anyone's benefit to publish packages that
> compile, have not been tested, and have a significant chance of not working.

Regarding testing the client I will do so, but not until Wednesday when
I have physical access to the box I will test it on.

Message #75 received at 657793-close@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 657793-close@bugs.debian.org

Subject: Bug#657793: fixed in quakespasm 0.85.7-1

Date: Tue, 01 May 2012 10:21:46 +0000

Source: quakespasm
Source-Version: 0.85.7-1

We believe that the bug you reported is fixed in the latest version of
quakespasm, which is due to be installed in the Debian FTP archive:

quakespasm-dbg_0.85.7-1_amd64.deb
  to main/q/quakespasm/quakespasm-dbg_0.85.7-1_amd64.deb
quakespasm_0.85.7-1.debian.tar.gz
  to main/q/quakespasm/quakespasm_0.85.7-1.debian.tar.gz
quakespasm_0.85.7-1.dsc
  to main/q/quakespasm/quakespasm_0.85.7-1.dsc
quakespasm_0.85.7-1_amd64.deb
  to main/q/quakespasm/quakespasm_0.85.7-1_amd64.deb
quakespasm_0.85.7.orig.tar.gz
  to main/q/quakespasm/quakespasm_0.85.7.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 657793@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated quakespasm package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Tue, 01 May 2012 10:36:36 +0100
Source: quakespasm
Binary: quakespasm quakespasm-dbg
Architecture: source amd64
Version: 0.85.7-1
Distribution: unstable
Urgency: low
Maintainer: David Banks <amoebae@gmail.com>
Changed-By: Simon McVittie <smcv@debian.org>
Description: 
 quakespasm - engine for iD software's Quake
 quakespasm-dbg - engine for iD software's Quake - debug symbols
Closes: 657793
Changes: 
 quakespasm (0.85.7-1) unstable; urgency=low
 .
   [ David Banks ]
   * New upstream release.
     - Use the correct definition of sockaddr for kFreeBSD (Closes: #657793)
   * Update to latest policy and DEP-5 version.
   * Refresh support-user-directories.patch and gnu.patch.
   * Refresh upstream changelog.
   * Drop use of ${shlib:Depends} for the debug package.
   * Update manual page: drop dead options, update option descriptions
 .
   [ Simon McVittie ]
   * Configure git-buildpackage to filter Windows and Mac binaries out of
     the "orig" tarball as well as the git repository, and re-import the orig
     tarball
Checksums-Sha1: 
 cdc0dcb1352b3af882467479ca3a8b9b58da371b 2050 quakespasm_0.85.7-1.dsc
 28884e9ce2ddca7b70fd085aa1ad9e164681a1ae 1162080 quakespasm_0.85.7.orig.tar.gz
 59ba4f8ff882cb7589be05d1044531f262aaa273 56984 quakespasm_0.85.7-1.debian.tar.gz
 9d4c8d301332d244ee03e8a50207ae2de6c009dc 397946 quakespasm_0.85.7-1_amd64.deb
 093bcea34750281f8030fa96eb8a7da3600ff856 84610 quakespasm-dbg_0.85.7-1_amd64.deb
Checksums-Sha256: 
 964201029060937db90754f4ad167b541cc42f1161c9b5f4e8e4b1b5288dedee 2050 quakespasm_0.85.7-1.dsc
 3078ff5a80f8410c2defa913bfa9f410ee14621a2ad69a536f087dff7aacf1b4 1162080 quakespasm_0.85.7.orig.tar.gz
 def5cfcf0c3705b555e51d83757eeffc70e18b5cd0856d3dfead272baa3a9601 56984 quakespasm_0.85.7-1.debian.tar.gz
 9103fde57a7d6f0409bb38598f1e4c4f92980d7528ac78ad5de3f7abd2ff3eab 397946 quakespasm_0.85.7-1_amd64.deb
 8c11f88a077ed99bda0e17450136f9cbe361a6fe6774b506084f55edc6b838d6 84610 quakespasm-dbg_0.85.7-1_amd64.deb
Files: 
 2c502faa22c60fcac476ed23af2dd1af 2050 games optional quakespasm_0.85.7-1.dsc
 52eae076aef84cba6e035c5bb8a4ac95 1162080 games optional quakespasm_0.85.7.orig.tar.gz
 a6324b22392166a58082e3fa43d866d7 56984 games optional quakespasm_0.85.7-1.debian.tar.gz
 23d611d23bdd931f998a144ce723035d 397946 games optional quakespasm_0.85.7-1_amd64.deb
 b26655ab3bc91cd5812c50bd006ea02b 84610 debug extra quakespasm-dbg_0.85.7-1_amd64.deb

-----BEGIN PGP SIGNATURE-----

iQIVAwUBT5+zxk3o/ypjx8yQAQhdSg/+JJaFxZpeQFwsZ9oc4xelr3v6MHJfihxG
PTKAQUohLmdVq3gjJR1/nhGX3uXIbaJIHDcpd1TIcPoeE+W66k76IPudj00lm/vT
lYWzOnnZhkY9tz8CEo3DDvjzIL5IPdQBtZgzKYPc2JcMwt1bCwg+/l5uvFpvj4WX
T+1Y9qAyhGIYyuJbdTmKQmw7QOsM9HNgIdLRfVQUkeEs3hupZtfGVV9ZX9IgcyTV
rAs8DWqmgwlVt3tvCtqZLE0ZMNG2qPor6mNZNSpyDGTTe2I0lWC6sf0kswp54eEU
RxPtTrm2iRs9UdoaEEzjYfRGVZ/ZOOWLiWGO0Gd34pkJKtLrRIJ+R8tnCOnLRHS9
cNymGeGI43PLbsSDiqSCousPhMhLtB+b1WtLv1f4YYMziWIvfpemBNmCPPi+YoEp
KQOdC2wsyw9krcZJd4HQFr9vny9KYG74LbJ585IE8hteuBgW7aJkmEqUvrSCA3pD
G3D9f4FoROXqHvgEAgNcAUkJgJYF20ZWN3/lTdZ27VKorMnvVTiwL0wZcumKCa1C
9SnLkm1LU2oORJHMEV+cO0ppGzl0dyTwYSjn5A+Vo612AELd3+MaxrA8TfvwVoMj
jfMhpqEt5PPedu3u9ECFgzDF3Z6GACUUsckRqL/1QHGJZP5dj31kNfKUMwZyZbjL
3XIT9wSpCu8=
=jvDQ
-----END PGP SIGNATURE-----

Message #80 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: Simon McVittie <smcv@debian.org>

Cc: 657793@bugs.debian.org, svante.signell@telia.com, Robert Millan <rmh@debian.org>

Subject: Re: Bug#657793: quakespasm: FTBFS on kfreebsd-*

Date: Tue, 01 May 2012 13:02:13 +0100

On 01/05/12 10:12, Simon McVittie wrote:
> I can *just about* see how running a Quake dedicated server on the FreeBSD
> kernel might be a rational thing to do, if you're really, really keen on
> FreeBSD's firewalling...

Hi!

You seem skeptical...

Arguably it could also have better security/uptime, or even performance
if some benchmarks could be believed (thus allowing a less-powerful
server to do the job).  Maybe the ability to use jails, if we can get
those working, to efficiently host multiple dedicated servers for
different users/customers on the same hardware.

Even if users want none of these things, there may be other things
forcing them to use a FreeBSD kernel on a particular box or desktop.
Maybe Linux doesn't work well on that particular hardware, in which case
still being able to install their favourite Debian packages is great.

So as you said, to increase the "proportion of Architecture:any packages
that compile" was in fact my goal when I originally filed the bug+patch.
 Unfortunately I couldn't test it yet but but someone else has in the
meantime (thanks David).

I would also have written my patch in a way that helps things on
GNU/Hurd if I'd known how to at the time.  And I would have used
wishlist severity had I not misunderstood policy thinking it should be RC.

I'm curious if Svante is right that FTBFS+patch on a release arch
qualifies as important?  Even if it has not built before?


> ... but the right answer for high-quality code would be to make this list
> of special cases irrelevant.

Great, that's another good (but less obvious) thing that I think comes
out of porting efforts.  It has highlighted some questionable code, that
could equally have been broken by some future change in Linux headers,
or might have been broken/insecure already.

Thanks for looking into it, and hopefully upstream could improve it someday.


> ...getting it to compile successfully on a particular kernel is
> no guarantee that it'll work correctly, or fail without crashing...,

But if we can't get it built+installed in the archive there are few
people who would really test it.  Leaving things uncompiled sort of
relegates GNU/kFreeBSD to being a source-based distribution which is not
what Debian is popular for.


Anyway, thanks again for uploading a fixed version.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Message #85 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Stephen Kitt <steve@sk2.org>

To: Simon McVittie <smcv@debian.org>

Cc: 657793@bugs.debian.org, Robert Millan <rmh@debian.org>, Svante Signell <svante.signell@telia.com>

Subject: Re: Bug#657793: NMU to DELAYED/10

Date: Tue, 1 May 2012 23:24:59 +0200

On Tue, May 01, 2012 at 10:39:45AM +0100, Simon McVittie wrote:
> David: while releasing what was in pkg-games git, I ran into some problems.
> The upstream branch in quakespasm.git seems to have been filtered
> to remove the SDL binaries, but the pristine-tar metadata seems to result in
> the original upstream tarball, with SDL binaries for Windows and Mac OS X.
> SDL is under the LGPL, so shipping binaries without corresponding source is
> a license violation, and we shouldn't do it.
> 
> It looks as though the solution might be to add "filter-pristine-tar = True"
> to gbp.conf and re-run git-import-orig. I'm not sure why that option isn't
> the default :-/
> 
> Stephen: you prepared the last upstream release, and it does seem to have a
> correctly-filtered orig tarball. What did you do to get that? Do you have
> filter-pristine-tar enabled locally or something?

The rather crummy release you had to fix up (sorry about that!)... My
shell history doesn't go that far back, but I seem to remember adding
filter-pristine-tar to the git-import-orig command-line, after
noticing that the tarball was supposed to be filtered.

Adding the option to gbp.conf is definitely better. Re-importing the
same tarball probably won't work as-is because git-import-orig won't
be able to tag the new upstream; adding +dfsg to the version number
would avoid this and indicate that the tarball isn't quite the same as
that provided by upstream.

Regards,

Stephen

Message #90 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Robert Millan <rmh@debian.org>

To: Simon McVittie <smcv@debian.org>

Cc: 657793@bugs.debian.org, steve@sk2.org, Svante Signell <svante.signell@telia.com>

Subject: Re: Bug#657793: NMU to DELAYED/10

Date: Wed, 2 May 2012 23:34:19 +0200

FYI, I've cancelled the delayed upload.

2012/5/1 Simon McVittie <smcv@debian.org>:
> On Sun, 29 Apr 2012 at 14:12:38 +0100, Simon McVittie wrote:
>> David has packaged a newer upstream version (in pkg-games git) with the
>> kFreeBSD-only version of the patch, so I'd prefer to fix this by
>> uploading that, either as-is or with the kFreeBSD-only patch replaced by
>> Svante's kFreeBSD-and-Hurd version.
>
> I think it's reasonable to assume that it does work on kFreeBSD, given David's
> testing, and the fact that upstream support Mac OS X - which essentially
> has FreeBSD network code, AIUI - with the same implementation.
> I'm preparing a release, and I'll clone a bug for "doesn't build on Hurd".
>
> David: while releasing what was in pkg-games git, I ran into some problems.
> The upstream branch in quakespasm.git seems to have been filtered
> to remove the SDL binaries, but the pristine-tar metadata seems to result in
> the original upstream tarball, with SDL binaries for Windows and Mac OS X.
> SDL is under the LGPL, so shipping binaries without corresponding source is
> a license violation, and we shouldn't do it.
>
> It looks as though the solution might be to add "filter-pristine-tar = True"
> to gbp.conf and re-run git-import-orig. I'm not sure why that option isn't
> the default :-/
>
> Stephen: you prepared the last upstream release, and it does seem to have a
> correctly-filtered orig tarball. What did you do to get that? Do you have
> filter-pristine-tar enabled locally or something?
>
> Thanks,
>    S



-- 
Robert Millan

Message #95 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Robert Millan <rmh@debian.org>

To: Simon McVittie <smcv@debian.org>

Cc: 657793@bugs.debian.org, svante.signell@telia.com, Steven Chamberlain <steven@pyro.eu.org>

Subject: Re: Bug#657793: quakespasm: FTBFS on kfreebsd-*

Date: Wed, 2 May 2012 23:39:35 +0200

2012/5/1 Simon McVittie <smcv@debian.org>:
> On Sun, 29 Apr 2012 at 12:47:43 +0200, Robert Millan wrote:
>> NMU to fix this has been uploaded to DELAYED/10.  Debdiff is attached.
>
> With that in mind, I don't think this is an appropriate use of an NMU.

It is.  But since the issue is being worked on, there's no reason to.
I've just cancelled the upload.

> Quakespasm has never been present on either of the affected architectures,
> so there's certainly no regression here

That's why it's not release-critical.

> If what you're trying to achieve is to increase "proportion of Architecture:any
> packages that compile" statistics,

Actually I was only going through the list of packages that FTBFS on
kfreebsd-* where a patch was available.  In this case, you might want
to remove the "patch" tag until a proper solution is available.

Best regards

-- 
Robert Millan

Message #100 received at 657793@bugs.debian.org (full text, mbox, reply):

From: Svante Signell <svante.signell@telia.com>

To: Simon McVittie <smcv@debian.org>

Cc: 657793@bugs.debian.org, Steven Chamberlain <steven@pyro.eu.org>, 671014@bugs.debian.org, Robert Millan <rmh@debian.org>

Subject: Re: Bug#657793: quakespasm: FTBFS on kfreebsd-*

Date: Thu, 03 May 2012 17:49:59 +0200

On Wed, 2012-05-02 at 23:39 +0200, Robert Millan wrote:
> 2012/5/1 Simon McVittie <smcv@debian.org>:
> > On Sun, 29 Apr 2012 at 12:47:43 +0200, Robert Millan wrote:

> > Quakespasm has never been present on either of the affected architectures,
> > so there's certainly no regression here
> 
> That's why it's not release-critical.
> 
> > If what you're trying to achieve is to increase "proportion of Architecture:any
> > packages that compile" statistics,
> 
> Actually I was only going through the list of packages that FTBFS on
> kfreebsd-* where a patch was available.  In this case, you might want
> to remove the "patch" tag until a proper solution is available.

I have now tested the game on GNU/Hurd, and it is playable at 320x240 as
for kFreeBSD: I cannot understand why you couldn't add the small fix
when uploading a new version.

Send a report that this bug log contains spam.