[email protected] <[email protected]>
Subject: Re: Bug#530796: xine-lib: FTBFS on Hurd
Message-ID: <50686adbb0%[email protected]>
In-Reply-To: <[email protected]>
References: <[email protected]>
<50681fd3e0%[email protected]>
<[email protected]>
Mail-Followup-To: =?utf-8?q?Marc_Dequ=C3=A8nes_(Duck)?= <[email protected]>,
[email protected] <[email protected]>
User-Agent: Gemini/2.29m (Qt/3.3.8b) (Linux-x86_64)
X-NuLabour-Date: Fri, 8946 Dec 1984 11:17:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
[M-F-T set. Don't CC to me.]
I demand that Marc Dequ=C3=A8nes (Duck) may or may not have written...
[snip]
>>> Coin,
>> ?
> I'm a duck, so i say Quack (or Coin in french) :-).
Ah, right... wouldn't have occurred to me :-)
>> Agreed, but sending the full version upstream would be good.
> As such kind of problems are... numerous, this is done as a best-effort=
> basis. If it was to add Hurd-specific features, i would agree not to ac=
cept
> such kind of patches,
He who writes, maintains ;-)
> but in this case the software itself does not respect standards.
Not a problem, so long as we're made aware of it...
> Fortunately, its works well on the mainstream GNU/Linux system, but thi=
s is
> not to say this non-Hurd-specific bug has not to be solved. I hope eith=
er
> we get time to provide a better patch, or the upstream authors would be=
> alerted and come back to us to work together on a fix.
Unless a patch is Debian-specific, it is applied upstream then transplant=
ed.
> Until then, I hope this blocker will nevertheless be unlocked.
Only *until* then? ;-)
>>> - hurd_support patch: a very short Hurd-specific patch to correct use=
>>> of an include file not needed and not existing on Hurd
>> Seems fine (so long as it doesn't break things elsewhere).
> The __GNU__ symbol is defined only on the GNU system, aka Hurd.
Ah. Seems fine, then :-)
>>> - dvb_optional patch: we cannot build with DVB support on Hurd, due t=
o
>>> missing and currently unimplementable ioctls, so this patch, along wi=
th
>>> the 'reautogen' patch add the necessary configure option to deactivat=
e
>>> DVB support on Hurd
>> No.
>> The option is acceptable, but the test must be "=3D yes" on (at least)=
>> Windows & Hurd and "!=3D no" elsewhere. I will *not* accept DVB being
>> disabled by default when building xine-lib on systems where the plugin=
is
>> buildable and will work.
> I don't understand. The --disable-dvb is only added to the configure
> options on Hurd, and as it reads itself, it intends to disable support =
"on
> demand", while obviously the original default to yes is kept. Perhaps y=
ou
> mean the AM_CONDITIONAL test is badly done, in this case please help me=
fix
> it, as i don't see what's wrong.
If it is not explicitly enabled or explicitly disabled then $with_dvb wil=
l be
neither "yes" nor "no", and either auto-detection should happen or some
appropriate, possibly OS-specific, default should be chosen.
If it is explicitly enabled but cannot be enabled (detection fails, or it=
's
known not to be supported), the configure script must fail.
Disabling it as is done for Windows =E2=80=92 with or without --{en,dis}a=
ble-dvb =E2=80=92
would be acceptable.
>> A patch series against http://hg.debian.org/hg/xine-lib/pkg/xine-lib-d=
eb
>> would be much preferred since it can easily be applied upstream ("hg
>> transplant", mostly), though debian/rules might be a bit tricky.
>> (An "hg bundle"-generated file is fine for this.)
> Arf. I guess this patch would go to trash if i don't do so,
No; I'd rather have a bit more separation, and patch-specific description=
s
and attribution (see below).
For the two which are acceptable, I'm pretending that you've described th=
em
as "Fix FTBFS on the Hurd" and "Fix a recently-added POSIX incompatibilit=
y".
(These two are committed locally; if you want to improve the descriptions=
,
you still have a chance to do so.)
> but i'm not so happy having to learn every VCS in the world because a
> simple unified patch is not trendy enough nowadays.
A quilt series, then; just not one handled via debian/rules so that the
changes to debian/rules can be included in it. Adding "From" and "Subject=
"
headers, optionally along with a short description, to each patch is usef=
ul:
git and mercurial, at least, will use that information.
That said, I think that I'll just extract the relevant debian/rules chang=
es
and throw away the quilt-specific stuff (which it doesn't make sense to u=
se
without converting a lot of other patches, and anwyay I'd use dpatch (wit=
h a
build dependency) were I to use a patching system here). Should I use the=
"arch-specific install files" line or do you want to provide a better
description? :-)
--=20
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + Generate power using sun, wind, water, nuclear. FORGET COAL AND =
OIL.
You cannot kill time without injuring eternity.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
