Mailing List Archive: atrpms: devel

The state of lirc...

Index | Next | Previous | View Threaded

jarod at wilsonet

May 9, 2008, 8:56 AM

Post #1 of 12 (1473 views)
Permalink

The state of lirc...

Remind me again... Why does atrpms continue to package lirc? Both the
user-space and kernel-space bits of lirc are already provided in Fedora.
I was prompted to ask this, because I"ve built and pushed lirc 0.8.3
final into fedora 8 and 9, but noted that this winds up being
rpm-*older* than the atrpms' ~2mo old pre-0.8.3 cvs snapshot... In my
eyes, there's really no justification for atrpms to continue shipping
lirc.

--
Jarod Wilson
jarod [at] wilsonet

_______________________________________________
atrpms-devel mailing list
atrpms-devel [at] atrpms
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

drees76 at gmail

May 9, 2008, 12:00 PM

Post #2 of 12 (1421 views)
Permalink

Re: The state of lirc... [In reply to]

On Fri, May 9, 2008 at 8:56 AM, Jarod Wilson <jarod [at] wilsonet> wrote:
> Remind me again... Why does atrpms continue to package lirc? Both the
> user-space and kernel-space bits of lirc are already provided in Fedora.
> I was prompted to ask this, because I"ve built and pushed lirc 0.8.3
> final into fedora 8 and 9, but noted that this winds up being
> rpm-*older* than the atrpms' ~2mo old pre-0.8.3 cvs snapshot... In my
> eyes, there's really no justification for atrpms to continue shipping
> lirc.

Last time I tried using lirc strictly from Fedora, I had problems with
the lirc_serial driver. IIRC, at some point in time it wasn't included
with the kernel. I see that it is now on my Fedora 8 machine, so I'll
try removing the ATrpms versions of lirc and see if the upstream
versions work.

Looks like I need to grab the latest lirc from koji - not showing up
in updates-testing yet.

-Dave

_______________________________________________
atrpms-devel mailing list
atrpms-devel [at] atrpms
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

jarod at wilsonet

May 9, 2008, 12:10 PM

Post #3 of 12 (1425 views)
Permalink

Re: The state of lirc... [In reply to]

On Fri, 2008-05-09 at 12:00 -0700, David Rees wrote:
> On Fri, May 9, 2008 at 8:56 AM, Jarod Wilson <jarod [at] wilsonet> wrote:
> > Remind me again... Why does atrpms continue to package lirc? Both the
> > user-space and kernel-space bits of lirc are already provided in Fedora.
> > I was prompted to ask this, because I"ve built and pushed lirc 0.8.3
> > final into fedora 8 and 9, but noted that this winds up being
> > rpm-*older* than the atrpms' ~2mo old pre-0.8.3 cvs snapshot... In my
> > eyes, there's really no justification for atrpms to continue shipping
> > lirc.
>
> Last time I tried using lirc strictly from Fedora, I had problems with
> the lirc_serial driver. IIRC, at some point in time it wasn't included
> with the kernel. I see that it is now on my Fedora 8 machine, so I'll
> try removing the ATrpms versions of lirc and see if the upstream
> versions work.

Yep, lirc patches have been in the Fedora kernels since sometime in the
2.6.23 timeframe, including the kernel F8 originally shipped with, iirc.

(For the record, I'm the one who patched lirc into the Fedora kernel
builds, and any problems with the in-kernel drivers I'd really like to
hear about and get fixed).

> Looks like I need to grab the latest lirc from koji - not showing up
> in updates-testing yet.

I think it just got pushed that direction today, so it'll probably hit
the master repo and sync out to mirrors tonight.

I did talk with Ryan Pisani on this topic a bit, sounds like there may
be a few drivers in the ATrpms package that aren't in the kernel for
whatever reason. Assuming this is the only compelling reason for
out-of-tree builds anymore, I'd either suggest the atrpms packages only
carry those modules, or we figure out what's required to build them in
with the kernel. User-space though, I can't think of any reason for
duplication.

--
Jarod Wilson
jarod [at] wilsonet

_______________________________________________
atrpms-devel mailing list
atrpms-devel [at] atrpms
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

drees76 at gmail

May 9, 2008, 12:25 PM

Post #4 of 12 (1421 views)
Permalink

Re: The state of lirc... [In reply to]

On Fri, May 9, 2008 at 12:10 PM, Jarod Wilson <jarod [at] wilsonet> wrote:
> On Fri, 2008-05-09 at 12:00 -0700, David Rees wrote:
>> Last time I tried using lirc strictly from Fedora, I had problems with
>> the lirc_serial driver. IIRC, at some point in time it wasn't included
>> with the kernel. I see that it is now on my Fedora 8 machine, so I'll
>> try removing the ATrpms versions of lirc and see if the upstream
>> versions work.

Just switched over to the RPMs from koji and got everything migrated
and working. Here's what I had installed before:

lirc-0.8.3-73_cvs20071109.fc8
lirc-lib-0.8.3-74_cvs20080314.fc8
lirc-kmdl-2.6.24.5-85.fc8-0.8.3-74_cvs20080314.fc8

I removed the kmdl and then tried to upgrade using the new lirc and
lirc-libs, but lirc complained that it was older than the ATrpms
version. So then I tried --oldpackage, but then lirc-libs conflicted
with lirc-lib from ATrpms.

Finally just removed lirc and lirc-lib with --nodeps then reinstalled
lirc and lirc-libs.

ATrpms uses /etc/sysconfig/lircd, Fedora uses /etc/sysconfig/lirc so I
had to transfer my lircd options over.

Unloaded the old lirc modules I had loaded, loaded the ones from the
kernel and stopped/started lircd. Restarted mythwelcome and
mythfrontend and everything seems to still work. So from my point of
view, looks good! :-)

> Yep, lirc patches have been in the Fedora kernels since sometime in the
> 2.6.23 timeframe, including the kernel F8 originally shipped with, iirc.

I swear I tried using Fedora lirc when I upgraded this machine to F8,
but I could be wrong... Maybe it was some other issue that kept it
from working. Is Fedora still shipping lirc patches with recent
kernels? Are you working on getting them upstream into Linus' kernel?

> I did talk with Ryan Pisani on this topic a bit, sounds like there may
> be a few drivers in the ATrpms package that aren't in the kernel for
> whatever reason. Assuming this is the only compelling reason for
> out-of-tree builds anymore, I'd either suggest the atrpms packages only
> carry those modules, or we figure out what's required to build them in
> with the kernel. User-space though, I can't think of any reason for
> duplication.

Neither can I. And I also think that keeping as much as possible
upstream simplifies things for the end users as well.

-Dave

_______________________________________________
atrpms-devel mailing list
atrpms-devel [at] atrpms
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

jarod at wilsonet

May 9, 2008, 1:15 PM

Post #5 of 12 (1422 views)
Permalink

Re: The state of lirc... [In reply to]

On Fri, 2008-05-09 at 12:25 -0700, David Rees wrote:
> On Fri, May 9, 2008 at 12:10 PM, Jarod Wilson <jarod [at] wilsonet> wrote:
> > On Fri, 2008-05-09 at 12:00 -0700, David Rees wrote:
> >> Last time I tried using lirc strictly from Fedora, I had problems with
> >> the lirc_serial driver. IIRC, at some point in time it wasn't included
> >> with the kernel. I see that it is now on my Fedora 8 machine, so I'll
> >> try removing the ATrpms versions of lirc and see if the upstream
> >> versions work.
>
> Just switched over to the RPMs from koji and got everything migrated
> and working. Here's what I had installed before:
>
> lirc-0.8.3-73_cvs20071109.fc8
> lirc-lib-0.8.3-74_cvs20080314.fc8
> lirc-kmdl-2.6.24.5-85.fc8-0.8.3-74_cvs20080314.fc8
>
> I removed the kmdl and then tried to upgrade using the new lirc and
> lirc-libs, but lirc complained that it was older than the ATrpms
> version. So then I tried --oldpackage, but then lirc-libs conflicted
> with lirc-lib from ATrpms.
>
> Finally just removed lirc and lirc-lib with --nodeps then reinstalled
> lirc and lirc-libs.

Yeah, part of my original complaint was that the atrpms packages were
rpm-newer than the fedora 0.8.3 final packages, despite being a ~2mo old
pre-0.8.3 cvs snap. :)

> ATrpms uses /etc/sysconfig/lircd, Fedora uses /etc/sysconfig/lirc so I
> had to transfer my lircd options over.

And similarly, service lircd start vs. service lirc start.

> Unloaded the old lirc modules I had loaded, loaded the ones from the
> kernel and stopped/started lircd. Restarted mythwelcome and
> mythfrontend and everything seems to still work. So from my point of
> view, looks good! :-)

Excellent. I've been using the in-kernel stuff for quite a while myself,
with lirc_i2c, lirc_mceusb and lirc_mceusb2 (I have something like 6
different IR receivers now...)

> > Yep, lirc patches have been in the Fedora kernels since sometime in the
> > 2.6.23 timeframe, including the kernel F8 originally shipped with, iirc.
>
> I swear I tried using Fedora lirc when I upgraded this machine to F8,
> but I could be wrong... Maybe it was some other issue that kept it
> from working.

Hrm, beats me, I think I've been using them since the day I patched them
into the kernel.

> Is Fedora still shipping lirc patches with recent kernels?

Yes. Although I need to refresh them -- there's a
just-fixed-right-before-0.8.3 segfault or oops with lirc_i2c and 2.6.25
that I need to get taken care of.

> Are you working on getting them upstream into Linus' kernel?

Yes. Although working with upstream is... slow. Its high-latency, but
upstream has already taken a ton of patches I've thrown at them to get
lirc much closer to at least patching checkpatch.pl muster and replace
some deprecated interfaces.

> > I did talk with Ryan Pisani on this topic a bit, sounds like there may
> > be a few drivers in the ATrpms package that aren't in the kernel for
> > whatever reason. Assuming this is the only compelling reason for
> > out-of-tree builds anymore, I'd either suggest the atrpms packages only
> > carry those modules, or we figure out what's required to build them in
> > with the kernel. User-space though, I can't think of any reason for
> > duplication.
>
> Neither can I. And I also think that keeping as much as possible
> upstream simplifies things for the end users as well.

Axel, anything to add here?

--
Jarod Wilson
jarod [at] wilsonet

_______________________________________________
atrpms-devel mailing list
atrpms-devel [at] atrpms
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

john.robinson at anonymous

May 9, 2008, 6:12 PM

Post #6 of 12 (1421 views)
Permalink

Re: The state of lirc... [In reply to]

On 09/05/2008 16:56, Jarod Wilson wrote:
> Remind me again... Why does atrpms continue to package lirc?

Because Fedora x (some x) and ELx (any x) don't include it, but Axel
supports them.

Cheers,

John.

_______________________________________________
atrpms-devel mailing list
atrpms-devel [at] atrpms
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

promac at gmail

May 9, 2008, 7:34 PM

Post #7 of 12 (1420 views)
Permalink

Re: The state of lirc... [In reply to]

On Fri, May 9, 2008 at 5:15 PM, Jarod Wilson <jarod [at] wilsonet> wrote:

> On Fri, 2008-05-09 at 12:25 -0700, David Rees wrote:
> > On Fri, May 9, 2008 at 12:10 PM, Jarod Wilson <jarod [at] wilsonet>
> wrote:
> > > On Fri, 2008-05-09 at 12:00 -0700, David Rees wrote:
> > >> Last time I tried using lirc strictly from Fedora, I had problems with
> > >> the lirc_serial driver. IIRC, at some point in time it wasn't included
> > >> with the kernel. I see that it is now on my Fedora 8 machine, so I'll
> > >> try removing the ATrpms versions of lirc and see if the upstream
> > >> versions work.
> >
> > Just switched over to the RPMs from koji and got everything migrated
> > and working. Here's what I had installed before:
> >
> > lirc-0.8.3-73_cvs20071109.fc8
> > lirc-lib-0.8.3-74_cvs20080314.fc8
> > lirc-kmdl-2.6.24.5-85.fc8-0.8.3-74_cvs20080314.fc8
> >
> > I removed the kmdl and then tried to upgrade using the new lirc and
> > lirc-libs, but lirc complained that it was older than the ATrpms
> > version. So then I tried --oldpackage, but then lirc-libs conflicted
> > with lirc-lib from ATrpms.
> >
> > Finally just removed lirc and lirc-lib with --nodeps then reinstalled
> > lirc and lirc-libs.
>
> Yeah, part of my original complaint was that the atrpms packages were
> rpm-newer than the fedora 0.8.3 final packages, despite being a ~2mo old
> pre-0.8.3 cvs snap. :)
>
>
> > ATrpms uses /etc/sysconfig/lircd, Fedora uses /etc/sysconfig/lirc so I
> > had to transfer my lircd options over.
>
> And similarly, service lircd start vs. service lirc start.
>
> > Unloaded the old lirc modules I had loaded, loaded the ones from the
> > kernel and stopped/started lircd. Restarted mythwelcome and
> > mythfrontend and everything seems to still work. So from my point of
> > view, looks good! :-)
>
> Excellent. I've been using the in-kernel stuff for quite a while myself,
> with lirc_i2c, lirc_mceusb and lirc_mceusb2 (I have something like 6
> different IR receivers now...)
>
> > > Yep, lirc patches have been in the Fedora kernels since sometime in the
> > > 2.6.23 timeframe, including the kernel F8 originally shipped with,
> iirc.
> >
> > I swear I tried using Fedora lirc when I upgraded this machine to F8,
> > but I could be wrong... Maybe it was some other issue that kept it
> > from working.
>
> Hrm, beats me, I think I've been using them since the day I patched them
> into the kernel.
>
> > Is Fedora still shipping lirc patches with recent kernels?
>
> Yes. Although I need to refresh them -- there's a
> just-fixed-right-before-0.8.3 segfault or oops with lirc_i2c and 2.6.25
> that I need to get taken care of.
>
> > Are you working on getting them upstream into Linus' kernel?
>
> Yes. Although working with upstream is... slow. Its high-latency, but
> upstream has already taken a ton of patches I've thrown at them to get
> lirc much closer to at least patching checkpatch.pl muster and replace
> some deprecated interfaces.
>
> > > I did talk with Ryan Pisani on this topic a bit, sounds like there may
> > > be a few drivers in the ATrpms package that aren't in the kernel for
> > > whatever reason. Assuming this is the only compelling reason for
> > > out-of-tree builds anymore, I'd either suggest the atrpms packages only
> > > carry those modules, or we figure out what's required to build them in
> > > with the kernel. User-space though, I can't think of any reason for
> > > duplication.
> >
> > Neither can I. And I also think that keeping as much as possible
> > upstream simplifies things for the end users as well.
>
> Axel, anything to add here?
>

Hi,

There are some minor problems, such as the use of lirc-lib-devel instead
of lirc-devel in ATrpms. This will require adjusting some spec files
accordingly.

At least kradio will have to be rebuilt (my bad, for using Requires:
lirc-lib),
and I have already uploaded an improved .src.rpm for it.

But I also tested your lirc packages, and they are working fine for me too.

These naming incompatibilities have always give me problems when using mock.

I really would like to see this issue solved once for all ....

--
Paulo Roma Cavalcanti
LCG - UFRJ

drees76 at gmail

May 9, 2008, 8:00 PM

Post #8 of 12 (1416 views)
Permalink

Re: The state of lirc... [In reply to]

On Fri, May 9, 2008 at 6:12 PM, John Robinson
<john.robinson [at] anonymous> wrote:
> On 09/05/2008 16:56, Jarod Wilson wrote:
>> Remind me again... Why does atrpms continue to package lirc?
>
> Because Fedora x (some x) and ELx (any x) don't include it, but Axel
> supports them.

Jarod's point was to go ahead and build them for the distros that
don't have the proper support upstream, but for those that do, drop it
or only build the parts that are needed (like the kmdls possibly in
F8's case).

-Dave

_______________________________________________
atrpms-devel mailing list
atrpms-devel [at] atrpms
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

promac at gmail

May 10, 2008, 3:21 AM

Post #9 of 12 (1416 views)
Permalink

Re: The state of lirc... [In reply to]

On Sat, May 10, 2008 at 12:00 AM, David Rees <drees76 [at] gmail> wrote:

> On Fri, May 9, 2008 at 6:12 PM, John Robinson
> <john.robinson [at] anonymous> wrote:
> > On 09/05/2008 16:56, Jarod Wilson wrote:
> >> Remind me again... Why does atrpms continue to package lirc?
> >
> > Because Fedora x (some x) and ELx (any x) don't include it, but Axel
> > supports them.
>
> Jarod's point was to go ahead and build them for the distros that
> don't have the proper support upstream, but for those that do, drop it
> or only build the parts that are needed (like the kmdls possibly in
> F8's case).
>

Which modules are missing?

In my experience, it is much more problematic
to maintain a partial package than the whole thing. You end up having to
compile everything
to throw away the common part. That is exactly what happens to xine, and
its free/non-free part (its nuts in my opinion, but solves a license
problem).

The video4linux package in ATrpms exists just to cope with the rapid
development upstream, and
the big delay to see the new code in a new kernel. Furthermore, I do not
like having part of a package compiled in a building system and part on
another. Is to ask for problems...

Maybe we could start using the same nomenclature for lirc and its
components? This way, those who do not need anything special could just use
the RedHat package and nothing else, or switch from one version to the other
very easily.

--
Paulo Roma Cavalcanti
LCG - UFRJ

promac at gmail

May 11, 2008, 9:26 AM

Post #10 of 12 (1391 views)
Permalink

Re: The state of lirc... [In reply to]

On Sat, May 10, 2008 at 7:21 AM, Paulo Cavalcanti <promac [at] gmail> wrote:

>
>
> On Sat, May 10, 2008 at 12:00 AM, David Rees <drees76 [at] gmail> wrote:
>
>> On Fri, May 9, 2008 at 6:12 PM, John Robinson
>> <john.robinson [at] anonymous> wrote:
>> > On 09/05/2008 16:56, Jarod Wilson wrote:
>> >> Remind me again... Why does atrpms continue to package lirc?
>> >
>> > Because Fedora x (some x) and ELx (any x) don't include it, but Axel
>> > supports them.
>>
>> Jarod's point was to go ahead and build them for the distros that
>> don't have the proper support upstream, but for those that do, drop it
>> or only build the parts that are needed (like the kmdls possibly in
>> F8's case).
>>
>
> Which modules are missing?
>
> In my experience, it is much more problematic
> to maintain a partial package than the whole thing. You end up having to
> compile everything
> to throw away the common part. That is exactly what happens to xine, and
> its free/non-free part (its nuts in my opinion, but solves a license
> problem).
>
> The video4linux package in ATrpms exists just to cope with the rapid
> development upstream, and
> the big delay to see the new code in a new kernel. Furthermore, I do not
> like having part of a package compiled in a building system and part on
> another. Is to ask for problems...
>
> Maybe we could start using the same nomenclature for lirc and its
> components? This way, those who do not need anything special could just use
> the RedHat package and nothing else, or switch from one version to the other
> very easily.
>
>
A final remark. The way myth package is now,
it requires the lirc static library (liblirc_client.a),
during compilation. This lib is not present in
Jarod's (devel) package.

Since RH banned static libs sometime ago,
this one will be difficult to accommodate.

I my case I had to recompile Jarod's packages to
be able to use and develop with them in Atrpms.
Basically, I am building the missing static library
and providing lirc-lib-devel in lirc-devel.

But no one needs a third version of lirc packages, right?

--
Paulo Roma Cavalcanti
LCG - UFRJ

jarod at wilsonet

May 11, 2008, 5:58 PM

Post #11 of 12 (1388 views)
Permalink

Re: The state of lirc... [In reply to]

On Sun, 2008-05-11 at 13:26 -0300, Paulo Cavalcanti wrote:
> > Because Fedora x (some x) and ELx (any x) don't
> include it, but Axel supports them.

EL still requires lirc, but all supported Fedora releases have lirc
driver in-kernel and lirc userspace provided.

>
>
> Jarod's point was to go ahead and build them for the
> distros that don't have
> the proper support upstream, but for those that do,
> drop it
> or only build the parts that are needed (like the
> kmdls possibly in F8's case).

F7, F8 and F9 all have lirc drivers in their kernels. There may be a few
modules not built that could still stand to be built, and that could be
done either in-kernel or in a kmdl.

> Which modules are missing?
>
> In my experience, it is much more problematic
> to maintain a partial package than the whole thing.

Why? The spec file contains a static list of which modules to build.

> You end up having to compile everything
> to throw away the common part.

Not true. You only have to compile the modules you want to build.

> That is exactly what happens to xine, and its free/non-free
> part (its nuts in my opinion, but solves a license problem).
>
> The video4linux package in ATrpms exists just to cope with the
> rapid development upstream, and
> the big delay to see the new code in a new kernel.

Nb: if/when I find time, I *might* start tracking the dvb mercurial tip
(or at least reasonably stable snapshots thereof) in the Fedora kernels.

> Furthermore, I do not like having part of a package compiled
> in a building system and part on another. Is to ask for
> problems...

lirc is pretty well separated between userspace and kernel space. I've
been building them separately for quite some time without an issue. If
there ever *is* a problem, I maintain the lirc kernel patches in Fedora
and am a co-maintainer on the lirc userspace packages in Fedora. Yell if
something actually breaks, and I'll fix it.

> A final remark. The way myth package is now,
> it requires the lirc static library (liblirc_client.a),
> during compilation. This lib is not present in
> Jarod's (devel) package.
>
> Since RH banned static libs sometime ago,
> this one will be difficult to accommodate.

Huh? No it won't. I've been building my own mythtv packages against the
lirc-devel in Fedora for AGES and lirc support works just fine, thank
you. You do NOT need the static lib for anything in mythtv. If the
ATrpms mythtv build requires the static lib (I'd be really surprised if
it actually did), then its broken.

> I my case I had to recompile Jarod's packages to
> be able to use and develop with them in Atrpms.
> Basically, I am building the missing static library
> and providing lirc-lib-devel in lirc-devel.
>
> But no one needs a third version of lirc packages, right?

I'm still completely and totally convinced nobody needs a 2nd version
either.

--
Jarod Wilson
jarod [at] wilsonet

_______________________________________________
atrpms-devel mailing list
atrpms-devel [at] atrpms
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

promac at gmail

May 11, 2008, 7:12 PM

Post #12 of 12 (1393 views)
Permalink

Re: The state of lirc... [In reply to]

On Sun, May 11, 2008 at 9:58 PM, Jarod Wilson <jarod [at] wilsonet> wrote:

> On Sun, 2008-05-11 at 13:26 -0300, Paulo Cavalcanti wrote:
> > > Because Fedora x (some x) and ELx (any x) don't
> > include it, but Axel supports them.
>
> EL still requires lirc, but all supported Fedora releases have lirc
> driver in-kernel and lirc userspace provided.
>
> >
> >
> > Jarod's point was to go ahead and build them for the
> > distros that don't have
> > the proper support upstream, but for those that do,
> > drop it
> > or only build the parts that are needed (like the
> > kmdls possibly in F8's case).
>
> F7, F8 and F9 all have lirc drivers in their kernels. There may be a few
> modules not built that could still stand to be built, and that could be
> done either in-kernel or in a kmdl.
>
>
> > Which modules are missing?
> >
> > In my experience, it is much more problematic
> > to maintain a partial package than the whole thing.
>
> Why? The spec file contains a static list of which modules to build.
>
> > You end up having to compile everything
> > to throw away the common part.
>
> Not true. You only have to compile the modules you want to build.
>
> > That is exactly what happens to xine, and its free/non-free
> > part (its nuts in my opinion, but solves a license problem).
> >
> > The video4linux package in ATrpms exists just to cope with the
> > rapid development upstream, and
> > the big delay to see the new code in a new kernel.
>
> Nb: if/when I find time, I *might* start tracking the dvb mercurial tip
> (or at least reasonably stable snapshots thereof) in the Fedora kernels.

That would be very nice.

>
>
> > Furthermore, I do not like having part of a package compiled
> > in a building system and part on another. Is to ask for
> > problems...
>
> lirc is pretty well separated between userspace and kernel space. I've
> been building them separately for quite some time without an issue. If
> there ever *is* a problem, I maintain the lirc kernel patches in Fedora
> and am a co-maintainer on the lirc userspace packages in Fedora. Yell if
> something actually breaks, and I'll fix it.

Then you have my vote. The success of mythtv in Fedora/RHEL is because,
in great part, the work of Axel and yours.

>
>
>
> > A final remark. The way myth package is now,
> > it requires the lirc static library (liblirc_client.a),
> > during compilation. This lib is not present in
> > Jarod's (devel) package.
> >
> > Since RH banned static libs sometime ago,
> > this one will be difficult to accommodate.
>
> Huh? No it won't. I've been building my own mythtv packages against the
> lirc-devel in Fedora for AGES and lirc support works just fine, thank
> you. You do NOT need the static lib for anything in mythtv. If the
> ATrpms mythtv build requires the static lib (I'd be really surprised if
> it actually did), then its broken.
>
>
I just tried to rebuild Axel's .src.rpm (0.21-187) for FC6. Without the
static library it does not link.
I really tried, and it does not go .... One has to have the .a bit.
Perhaps it is just a questions of changing the myth spec file. I do not
know.

Statically linking lirc to mythtv seems to be more appropriate,
but new myth versions come so fast, that it really does not make any
difference
after all.

Your packages work just fine for me with the two changes I told you,
static lib and lirc-lib-devel. I also prefer your nomenclature, such as
/etc/sysconfig/lirc (not lircd).

Since you are the lirc maintainer in Fedora, my vote is to use your packages
for Fedora. Unfortunately, however, Axel will have some extra work to do
...

--
Paulo Roma Cavalcanti
LCG - UFRJ

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads