Re: 01/01: gnu: vlc: Update to 2.2.0

Re: 01/01: gnu: vlc: Update to 2.2.0

[Andreas Enge]

Hello,

On Tue, Mar 03, 2015 at 01:32:08PM +0000, Jason Self wrote:
>     gnu: vlc: Update to 2.2.0

compilation on x86_64 fails for me with the following error message:

access/dtv/linux.c: In function ‘dvb_set_dvbs2’:
access/dtv/linux.c:906:27: error: ‘DTV_STREAM_ID’ undeclared (first use in this function)
                           DTV_STREAM_ID, (uint32_t)sid);
                           ^
access/dtv/linux.c:906:27: note: each undeclared identifier is reported only once for each function it appears in

Is it only my system or a more general phenomenon?

Andreas

Re: 01/01: gnu: vlc: Update to 2.2.0

[Axel]

I got same error on upgrade on x86_64.

2015-03-06 23:31 GMT+03:00 Andreas Enge <andreas@enge.fr>:
> Hello,
>
> On Tue, Mar 03, 2015 at 01:32:08PM +0000, Jason Self wrote:
>>     gnu: vlc: Update to 2.2.0
>
> compilation on x86_64 fails for me with the following error message:
>
> access/dtv/linux.c: In function ‘dvb_set_dvbs2’:
> access/dtv/linux.c:906:27: error: ‘DTV_STREAM_ID’ undeclared (first use in this function)
>                            DTV_STREAM_ID, (uint32_t)sid);
>                            ^
> access/dtv/linux.c:906:27: note: each undeclared identifier is reported only once for each function it appears in
>
> Is it only my system or a more general phenomenon?
>
> Andreas
>
>



-- 
Александр Графов

Re: 01/01: gnu: vlc: Update to 2.2.0

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Tue, Mar 03, 2015 at 01:32:08PM +0000, Jason Self wrote:
>>     gnu: vlc: Update to 2.2.0
>
> compilation on x86_64 fails for me with the following error message:
>
> access/dtv/linux.c: In function ‘dvb_set_dvbs2’:
> access/dtv/linux.c:906:27: error: ‘DTV_STREAM_ID’ undeclared (first use in this function)
>                            DTV_STREAM_ID, (uint32_t)sid);
>                            ^
> access/dtv/linux.c:906:27: note: each undeclared identifier is reported only once for each function it appears in

Jason, could you take a look?

I’ve reverted the upgrade in the meantime.  Apparently this version has
always failed to build:
<http://hydra.gnu.org/job/gnu/master/vlc-2.2.0.x86_64-linux/all>.

Thanks,
Ludo’.

Re: 01/01: gnu: vlc: Update to 2.2.0

[Andreas Enge]

Hello,

I have investigated a bit more why the vlc-2.2.0 build fails. I think it is
due to
/* DVB Card Drivers */
#include <linux/dvb/version.h>
#include <linux/dvb/dmx.h>
#include <linux/dvb/frontend.h>
in modules/access/dvb/linux_dvb.c.

The include files come from linux-libre-headers, which we have in
version 3.3.8. Could this be updated? In master or core-updates?

Andreas

Re: 01/01: gnu: vlc: Update to 2.2.0

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> I have investigated a bit more why the vlc-2.2.0 build fails. I think it is
> due to
> /* DVB Card Drivers */
> #include <linux/dvb/version.h>
> #include <linux/dvb/dmx.h>
> #include <linux/dvb/frontend.h>
> in modules/access/dvb/linux_dvb.c.
>
> The include files come from linux-libre-headers, which we have in
> version 3.3.8. Could this be updated? In master or core-updates?

It would trigger a full rebuild, so it would have to be done in
core-updates.

      Mark

Re: 01/01: gnu: vlc: Update to 2.2.0

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Andreas Enge <andreas@enge.fr> writes:
>
>> I have investigated a bit more why the vlc-2.2.0 build fails. I think it is
>> due to
>> /* DVB Card Drivers */
>> #include <linux/dvb/version.h>
>> #include <linux/dvb/dmx.h>
>> #include <linux/dvb/frontend.h>
>> in modules/access/dvb/linux_dvb.c.
>>
>> The include files come from linux-libre-headers, which we have in
>> version 3.3.8. Could this be updated? In master or core-updates?
>
> It would trigger a full rebuild, so it would have to be done in
> core-updates.

Right.  The version has to be chosen carefully (should be a LTS version
and one that is likely to remain on fsfla.org and/or that we mirror on
alpha.gnu.org), plus we don’t want glibc’s requirement to be too high so
people can use Guix on GNU/Linux with relatively old kernels.

Thanks,
Ludo’.

Re: 01/01: gnu: vlc: Update to 2.2.0

[Jason Self]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

Ludovic Courtès said;
> Right.  The version has to be chosen carefully (should be a LTS
> version and one that is likely to remain on fsfla.org and/or that we
> mirror on alpha.gnu.org), plus we don’t want glibc’s requirement to
> be too high so people can use Guix on GNU/Linux with relatively old
> kernels.

If using an LTS version is desired, support for the 3.3 series ended
almost three years ago. The 3.4 series is supported until September
2016. I seem to recall a discussion about a separation of roles though
where, even though there may be some overlap, the intent of GSRC was
to be something people installed on an existing distro and that the
intent of Guix was to be completely independent and standalone. Given
that, how much effort do we want to put in to maintaining that
overlap? Anyway, Debian seems sufficently slow moving to me and so I
looked at that to get an idea of what might be acceptable. They have
3.5 in Wheezy and are jumping to 3.16 for Jessie which I understand is
due soon? Given that, what about using 3.14? It is much newer and
supported until August 2016 [0].

[0] https://kernel.org/category/releases.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: 01/01: gnu: vlc: Update to 2.2.0

[Andreas Enge]

On Sat, Mar 14, 2015 at 09:47:04AM -0700, Jason Self wrote:
> Anyway, Debian seems sufficently slow moving to me and so I
> looked at that to get an idea of what might be acceptable. They have
> 3.5 in Wheezy and are jumping to 3.16 for Jessie which I understand is
> due soon? Given that, what about using 3.14? It is much newer and
> supported until August 2016 [0].

That sounds like a good plan to me. Would you like to implement it?

Andreas

Re: 01/01: gnu: vlc: Update to 2.2.0

[Ludovic Courtès]

"Jason Self" <jason@bluehome.net> skribis:

> Ludovic Courtès said;
>> Right.  The version has to be chosen carefully (should be a LTS 
>> version and one that is likely to remain on fsfla.org and/or that we
>> mirror on alpha.gnu.org), plus we don’t want glibc’s requirement to
>> be too high so people can use Guix on GNU/Linux with relatively old
>> kernels.
>
> If using an LTS version is desired, support for the 3.3 series ended
> almost three years ago. The 3.4 series is supported until September
> 2016. I seem to recall a discussion about a separation of roles though
> where, even though there may be some overlap, the intent of GSRC was
> to be something people installed on an existing distro and that the
> intent of Guix was to be completely independent and standalone. Given
> that, how much effort do we want to put in to maintaining that
> overlap?

I think we want to Guix to be usable on distros other than GuixSD for
the foreseeable future.  It doesn’t cost us much in terms of
maintenance, and it’s definitely helpful for those not willing/able to
switch to GuixSD.

I don’t this there’s much overlap with GSRC here anyway.

> Anyway, Debian seems sufficently slow moving to me and so I looked at
> that to get an idea of what might be acceptable. They have 3.5 in
> Wheezy and are jumping to 3.16 for Jessie which I understand is due
> soon? Given that, what about using 3.14? It is much newer and
> supported until August 2016 [0].

The real problem is that our libc must be able to work kernels typically
found out there in the wild, which may be older than this.  Thus, 3.14
may be a bit too recent.

Now, I think libc’s --enable-kernel can specify a baseline older than
the available kernel headers.  So it may be that we can use 3.14 headers
but build a libc that assumes a kernel possibly as old as 3.4.

Then again, one should look at kernel-features.h to see what features we
miss out by using, say, 3.4 instead of 3.14 (I expect there are few.)

Would you like to look at these aspects more closely?

Thanks,
Ludo’.

Re: 01/01: gnu: vlc: Update to 2.2.0

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> "Jason Self" <jason@bluehome.net> skribis:
>
>> Anyway, Debian seems sufficently slow moving to me and so I looked at
>> that to get an idea of what might be acceptable. They have 3.5 in
>> Wheezy and are jumping to 3.16 for Jessie which I understand is due
>> soon? Given that, what about using 3.14? It is much newer and
>> supported until August 2016 [0].
>
> The real problem is that our libc must be able to work kernels typically
> found out there in the wild, which may be older than this.  Thus, 3.14
> may be a bit too recent.

Note that currently, we configure GNU libc with --enable-kernel=2.6.32
with headers from linux-libre-3.3.8.  If it's incorrect to use headers
from a kernel newer than the oldest kernel we wish to support, then
we're already doing it wrong.

> Now, I think libc’s --enable-kernel can specify a baseline older than
> the available kernel headers.  So it may be that we can use 3.14 headers
> but build a libc that assumes a kernel possibly as old as 3.4.

One data point: we're running Guix and also Nginx compiled with Guix on
Hydra which runs a 2.6.x kernel, and it seems to work.

Another data point: [GNU/]Linux From Scratch uses headers from Linux
3.19 and configures GNU libc with --enable-kernel=2.6.32.  As I recall
they've been doing this for years, always using headers from the most
recent kernel but configuring libc to support older kernels.

and another: Debian currently builds their libc against headers from
Linux 3.12.6 and with --enable-kernel=2.6.32.

In summary, I think using headers from 3.14 would be fine.

      Mark

Re: 01/01: gnu: vlc: Update to 2.2.0

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:

[...]

>> Now, I think libc’s --enable-kernel can specify a baseline older than
>> the available kernel headers.  So it may be that we can use 3.14 headers
>> but build a libc that assumes a kernel possibly as old as 3.4.
>
> One data point: we're running Guix and also Nginx compiled with Guix on
> Hydra which runs a 2.6.x kernel, and it seems to work.
>
> Another data point: [GNU/]Linux From Scratch uses headers from Linux
> 3.19 and configures GNU libc with --enable-kernel=2.6.32.  As I recall
> they've been doing this for years, always using headers from the most
> recent kernel but configuring libc to support older kernels.
>
> and another: Debian currently builds their libc against headers from
> Linux 3.12.6 and with --enable-kernel=2.6.32.
>
> In summary, I think using headers from 3.14 would be fine.

Indeed, so let’s do that.

Thanks for the analysis and confirmation!

Ludo’.