(In reply to Anssi Hannula from comment #0)
> Old settings should be automatically migrated from
> systemd.service file. (Mageia bug #9528)

Typo, should be lircd.service.

dkms-lirc-extra-0.9.0-10.1.mga4 fails to build the module. Maybe not a regression, though, but that's broken enough to maybe be taken into account into your update?

First build error from the logs:

/var/lib/dkms/lirc-extra/0.9.0-10.1.mga4/build/drivers/lirc_wpc8769l/lirc_wpc8769l.c: In function âirq_handlerr
â:
/var/lib/dkms/lirc-extra/0.9.0-10.1.mga4/build/drivers/lirc_wpc8769l/lirc_wpc8769l.c:364:3: erreur: implicit declaration of function âgeneric_find_next_le_bitâ [-Werror=implicit-function-declaration]
   next_one = generic_find_next_le_bit(ldata, size, 0);
   ^

CC: (none) => stormi
Whiteboard: (none) => feedback

I am not going to port the lirc-extra drivers to current kernels at this time (I do accept patches for that, though, or pointers to someone else's patches). I've removed the subpackage on cauldron.

Should I build a new update candidate with the dkms-lirc-extra package removed, or is it OK as-is?

Whiteboard: feedback => (none)

I don't know what's the best option. We can't remove the broken package from release media, so your update will not make things worse. On the other side, if the newer package forces the removal of dkms-lircd, it will prevent users from installing it for nothing. You decide.

I'll keep it as-is then.

David W. Hodgins mad a plea for testing this bug report in the alt.os.linux.mageia  usenet group. I only tested lircd. My setup has a Silicondust hdhomerun network tuner with the infrared sensor. I use it to control a MythFrontend on my client system.

This was my mga4 64 bit pre-test changes
dif /usr/lib/systemd/system/lircd.service /etc/systemd/system/lircd.service
8c20
< ExecStart=/usr/sbin/lircd --driver=default --device=/dev/lirc0 
---
> ExecStart=/usr/sbin/lircd --driver=default --device=/dev/lirc0 -H udp -d 6546

Your addition of --nodaemon seems to go against the man licrd documentation which indicates it is to be started as a daemon.

Tried putting my "-H udp -d 6546" in /etc/sysconfig/lirc LIRCD_OPTIONS=""
but it seems those arguments are command line location sensitive.

Workaround was to add them to LIRC_DEVICE= which is not going to be intuitive to the casual user.  :(

might I suggest 
ExecStart=/bin/sh -c '/usr/sbin/lircd  \
    --driver ${LIRC_DRIVER} --device ${LIRC_DEVICE} ${LIRCD_OPTIONS}'

Since I removed --nodaemon I also had to change Type=simple to Type-Forking in  my /etc/systemd/system/lircd.service copy of 
/usr/lib/systemd/system/lircd.service

CC: (none) => junknospam

(In reply to Bit Twister from comment #6)
> Your addition of --nodaemon seems to go against the man licrd documentation
> which indicates it is to be started as a daemon.

--nodaemon is used because the service type is set to Type=simple. This avoids extra forking and complexity in tracking the main daemon process.

> Tried putting my "-H udp -d 6546" in /etc/sysconfig/lirc LIRCD_OPTIONS=""
> but it seems those arguments are command line location sensitive.
> 
> Workaround was to add them to LIRC_DEVICE= which is not going to be
> intuitive to the casual user.  :(

-H is the same as --driver and -d is the same as --device. So it is expected that they are specified in LIRC_DRIVER and LIRC_DEVICE, respectively. The comment in the sysconfig file even says:
# similar to passing "-H driver" to lircd(8).  (for LIRC_DRIVER)
# This is the same as passing "-d device" to lircd. It must be set. (for LIRC_DEVICE)

The reason why they don't work in LIRCD_OPTIONS is because the LIRC_DRIVER and LIRC_DEVICE override those.

> might I suggest 
> ExecStart=/bin/sh -c '/usr/sbin/lircd  \
>     --driver ${LIRC_DRIVER} --device ${LIRC_DEVICE} ${LIRCD_OPTIONS}'

Since there is no downside that I can see and it fixes things for users using LIRCD_OPTIONS instead of LIRC_DRIVER/LIRC_DEVICE, I'll do that change.

> Since I removed --nodaemon I also had to change Type=simple to Type-Forking
> in  my /etc/systemd/system/lircd.service copy of 
> /usr/lib/systemd/system/lircd.service

I'm not going to remove --nodaemon so changing Type will not be needed, unless there is something I'm missing.

Updated LIRC packages are in mga4 core/updates_testing.

Minor change regarding coniguration variable order as per comment #7, and non-working dkms-lirc-extra is not part of the update now.

Advisory:
============
This update fixes several issues in the LIRC packages on Mageia 4:

A service configuration file is added as /etc/sysconfig/lirc, allowing the LIRC driver and device to be configured properly, without losing changes after each upgrade. Old settings should be automatically migrated in most cases. (Mageia bug #9528)

Kernel protocol decoders that interfere with using LIRC can now be disabled on a per-device basis by using the LIRC_IR_DEVICE configuration directive in /etc/sysconfig/lirc or for all remote control devices by installing the new lirc-disable-kernel-rc subpackage. Most LIRC users should be fine by just installing the new package, without needing to use LIRC_IR_DEVICE. (Mageia bug #1265)

An old unneeded incorrect non-working udev rule causing a warning log message has been removed. LIRC device files are located in /dev/lircX. (Mageia bug #10537)

Additionally, several minor fixes to the systemd unit files, LIRC tools and the LIRC drivers have been added.

References:
https://bugs.mageia.org/show_bug.cgi?id=9528
https://bugs.mageia.org/show_bug.cgi?id=1265
https://bugs.mageia.org/show_bug.cgi?id=10537
============

Source packages:
lirc-0.9.0-10.2.mga4

Binary packages:
lirc-0.9.0-10.2.mga4
lib64lirc0-0.9.0-10.2.mga4
lib64lirc-devel-0.9.0-10.2.mga4
lirc-disable-kernel-rc-0.9.0-10.2.mga4

(In reply to Anssi Hannula from comment #7)
 
> I'm not going to remove --nodaemon so changing Type will not be needed,
> unless there is something I'm missing.

What you are missing, is those were the changes I had to make to get my remote to work with licrd.

documentation might say -H driver yet I am using -H udp which is not a driver and -d port which is not the device. 

List of my changes to support your release is as follows:

# dif /etc/sysconfig/lirc_vinstall /etc/sysconfig/lirc
15c15
< LIRC_DEVICE="/dev/lirc0"
---
> LIRC_DEVICE="/dev/lirc0 -H udp -d 6546"

# dif /usr/lib/systemd/system/lircd.service /etc/systemd/system/lircd.service
6c6
< Type=simple
---
> Type=forking
11c11
<     --driver ${LIRC_DRIVER} --device ${LIRC_DEVICE}  --nodaemon'
---
>     --driver ${LIRC_DRIVER} --device ${LIRC_DEVICE} '

(In reply to Bit Twister from comment #9)
> # dif /usr/lib/systemd/system/lircd.service /etc/systemd/system/lircd.service
> 6c6
> < Type=simple
> ---
> > Type=forking
> 11c11
> <     --driver ${LIRC_DRIVER} --device ${LIRC_DEVICE}  --nodaemon'
> ---
> >     --driver ${LIRC_DRIVER} --device ${LIRC_DEVICE} '

What exactly happens if you re-add --nodaemon and set Type=simple?

(In reply to Anssi Hannula from comment #10)
> What exactly happens if you re-add --nodaemon and set Type=simple?

It did not work even though systemctl status lircd showed green active.

Testing process was
edit some change/testshot
systemctl stop lircd
systemctl daemon-reload
systemctl start lircd
systemctl status lircd
launch mythfrontend and hit left/right/up/down buttons.

Trying your simple/nodaemon setting was attempted 3 different times while I played with /etc/sysconfig/lirc

(In reply to Bit Twister from comment #11)
> (In reply to Anssi Hannula from comment #10)
> > What exactly happens if you re-add --nodaemon and set Type=simple?
> 
> It did not work even though systemctl status lircd showed green active.
> 
> Testing process was
> edit some change/testshot
> systemctl stop lircd
> systemctl daemon-reload
> systemctl start lircd
> systemctl status lircd
> launch mythfrontend and hit left/right/up/down buttons.
> 
> Trying your simple/nodaemon setting was attempted 3 different times while I
> played with /etc/sysconfig/lirc

Thanks. Since I can't reproduce, could you please provide the full output of "systemctl status lircd" with --nodaemon and Type=simple (after changing, daemon-reloading and re-starting service)?

Also, to rule out any unusual interactions with the lirc socket and mythfrontend, please run the "irw" command in terminal (again with --nodaemon and Type=simple in .service) and then provide the output (if any) when the remote buttons are pressed.

(In reply to Anssi Hannula from comment #12)

> Thanks. Since I can't reproduce, could you please provide the full output of
> "systemctl status lircd" with --nodaemon and Type=simple (after changing,
> daemon-reloading and re-starting service)?

# systemctl status lircd.service
lircd.service - LIRC Infrared Signal Decoder
   Loaded: loaded (/etc/systemd/system/lircd.service; enabled)
   Active: active (running) since Mon 2014-03-03 16:16:41 CST; 5min ago
  Process: 13555 ExecStartPre=/bin/sh -c test -n "${LIRCD_IR_DEVICE}" &&      echo lirc > /sys/class/rc/${LIRCD_IR_DEVICE}/protocols || : (code=exited, status=0/SUCCESS)
 Main PID: 13558 (lircd)
   CGroup: /system.slice/lircd.service
           ââ13558 /usr/sbin/lircd --driver default --device /dev/lirc0 -H udp -d 6546 --nodaemon

 sh[13558]: lircd-0.9.1-git[13558]: removed client
 lircd-0.9.1-git[13558]: removed client
 sh[13558]: lircd-0.9.1-git[13558]: accepted new client on /var/run/lirc/lircd
 sh[13558]: lircd-0.9.1-git[13558]: Initializing UDP: 6546
 sh[13558]: lircd-0.9.1-git[13558]: Listening on port 6546/udp
 lircd-0.9.1-git[13558]: accepted new client on /var/run/lirc/lircd
 lircd-0.9.1-git[13558]: Initializing UDP: 6546
 lircd-0.9.1-git[13558]: Listening on port 6546/udp
 sh[13558]: lircd-0.9.1-git[13558]: removed client
 lircd-0.9.1-git[13558]: removed client

snipped out "Mar 03 16:19:11 tb.home.test" string on above and below


# irw
Noting showed up when pressing buttons
^C


Snippet from journalct -fa --no-pager

 sudo[14209]: bittwister : TTY=pts/5 ; PWD=/home/bittwister ; USER=root ; COMMAND=/bin/su - root
 su[14210]: (to root) bittwister on pts/5
 su[14210]: pam_tcb(su-l:session): Session opened for root by bittwister(uid=0)
 sh[13558]: lircd-0.9.1-git[13558]: accepted new client on /var/run/lirc/lircd
 sh[13558]: lircd-0.9.1-git[13558]: Initializing UDP: 6546
 sh[13558]: lircd-0.9.1-git[13558]: Listening on port 6546/udp
 lircd-0.9.1-git[13558]: accepted new client on /var/run/lirc/lircd
 lircd-0.9.1-git[13558]: Initializing UDP: 6546
 lircd-0.9.1-git[13558]: Listening on port 6546/udp
 sh[13558]: lircd-0.9.1-git[13558]: removed client
 lircd-0.9.1-git[13558]: removed client

(In reply to Bit Twister from comment #13)

Thanks. Unfortunately nothing seems wrong in those.

Could you please try the following (with Type=simple and --nodaemon):
1. Confirm there is nothing showing up in "irw" like before.
2. systemctl stop lircd
3. Run and check if there is output when buttons are pressed:
mode2 -H udp -d 6546

If there is output on button presses, can you provide the output of the same commands from your previous comment and this comment with Type=forking and no --nodaemon, to see if there is any difference?

Also, could you describe from where the UDP packets are coming in your setup? That might help me to reproduce the issue on my system.

(In reply to Anssi Hannula from comment #14)
> (In reply to Bit Twister from comment #13)
> 
> Thanks. Unfortunately nothing seems wrong in those.

Well frap. Stopped lircd, it was active with a simple/--nodaemon and was broke,

# dif /usr/lib/systemd/system/lircd.service /etc/systemd/system/lircd.service
#
Which proves I had reverted to the correct settings.

irw got a refused connection, which is correct for stopped lircd.

ran mode2 -H udp -d 6546 and received output. That made me curious.

removed /etc/systemd/system/lircd.service*, ran reload, start lircd.
irw now has output and of course mythfrontend works.

Just to be sure, rebooted system and it still works using your
/usr/lib/systemd/system/lircd.service with my 
LIRC_DEVICE="/dev/lirc0 -H udp -d 6546" setting in /etc/sysconfig/lirc

I have absolutely no idea why /etc/systemd/system/lircd.service changed back to simple/--nodaemon was broke.

Sorry to have wasted your time.

(In reply to Bit Twister from comment #15)
> Just to be sure, rebooted system and it still works using your
> /usr/lib/systemd/system/lircd.service with my 
> LIRC_DEVICE="/dev/lirc0 -H udp -d 6546" setting in /etc/sysconfig/lirc

Good to hear.

> I have absolutely no idea why /etc/systemd/system/lircd.service changed back
> to simple/--nodaemon was broke.
> 
> Sorry to have wasted your time.

No problem at all, and thanks for testing this.

As one more thing, could you please test that everything still works with lirc-0.9.0-10.2.mga4 I uploaded today? It just contains the change to parameter order you suggested, so it should be OK, but just in case :)

(In reply to Anssi Hannula from comment #16)

> As one more thing, could you please test that everything still works with
> lirc-0.9.0-10.2.mga4 I uploaded today? It just contains the change to
> parameter order you suggested, so it should be OK, but just in case :)

Mar 03 22:13:04 tb.home.test drakrpm-update[7056]: transaction on / (remove=0, install=0, upgrade=2)
 drakrpm-update[7056]: [RPM] lib64lirc0-0.9.0-10.2.mga4.x86_64 installed
 drakrpm-update[7056]: [RPM] lirc-0.9.0-10.2.mga4.x86_64 installed
 drakrpm-update[7056]: [RPM] lirc-0.9.0-10.1.mga4.x86_64 removed
 drakrpm-update[7056]: [RPM] lib64lirc0-0.9.0-10.1.mga4.x86_64 removed

Good/bad news. 

Good news, your reordering arguments works just fine.

Bad news, /etc/sysconfig/lirc from the update overwrote my /etc/sysconfig/lirc changes.  :(

I had expected a /etc/sysconfig/lirc.rpmnew to be created with a notification.

Bad news: I forgot to mark the sysconfig file as a non-overwritable config file.
Good news: You caught it :)

Actually, since there was no change in original /etc/sysconfig/lirc between 10.1.mga4 and 10.2.mga4, no .rpmnew should have been created in this case (rpmnew only gets generated when there is an actual change in the package provided file contents).

But it still should not have been overwritten, of course.

That is now fixed in lirc-0.9.0-10.3.mga4.x86_64, so please try that :)
Your /etc/sysconfig/lirc should be preserved this time.


=============
Updated list of packages:
=============
Source packages:
lirc-0.9.0-10.3.mga4

Binary packages:
lirc-0.9.0-10.3.mga4
lib64lirc0-0.9.0-10.3.mga4
lib64lirc-devel-0.9.0-10.3.mga4
lirc-disable-kernel-rc-0.9.0-10.3.mga4

(In reply to Anssi Hannula from comment #18)
> 
> That is now fixed in lirc-0.9.0-10.3.mga4.x86_64, so please try that :)
> Your /etc/sysconfig/lirc should be preserved this time.

# dif /etc/sysconfig/lirc_vinstall /etc/sysconfig/lirc
6c6
< LIRCD_OPTIONS=""
---
> LIRCD_OPTIONS="-H udp -d 6546"

Yup, looks and tested ok.

Now all you need is a i586 tester.

I was a little surprised I have to continually select lib64lirc0 for update. :(
I would have thought it would be marked as a dependency and automagically mark it for install.   :)

(In reply to Anssi Hannula from comment #14)


Finally found where I found lircd settings.
  http://www.silicondust.com/support/hdhomerun/instructions/mythtv/
Thought you might be interested in last paragraph bottom of page.

 
> Also, could you describe from where the UDP packets are coming in your
> setup? That might help me to reproduce the issue on my system.

Setup is using an old network tuner
  http://www.silicondust.com/hdhomerun/hdhomerun_tech.pdf
Connection is via second nic card inet addr:169.254.1.1
tuner port 6546 selected so there would be one less change in mythtv setup.

# cat /etc/modules-load.d/my_lirc.conf
#********* start of /etc/modules-load.d/my_lirc.conf *********************
#* Created by /local/bin/lirc_changes Thu Feb 09:26 2014
lirc_dev
lirc_serial
#*************** end /etc/modules-load.d/my_lirc.conf ******************** 

No clue as to were I found I needed to do the above lirc_* stuff.

/local/bin/lirc_changes is my script for automating changes after a clean install. It either modifies or creates the following:
$ grep fn= /local/bin/lirc_changes
_in_fn=/usr/lib/systemd/system/lircd.service
_out_fn=/etc/systemd/system/lircd.service
_fn="/etc/lirc/lircrc"
_fn=/etc/modules-load.d/my_lirc.conf
_fn=/etc/lirc/lircd.conf

and runs the systemctl enable/start commands.

That is all I know about what is where.

(In reply to Bit Twister from comment #19)
> Yup, looks and tested ok.
> Now all you need is a i586 tester.

Just to clarify, comment 20 is not a request for more changes?

If that's the case, and with no one with lirc devices on i586, we'll approve
the update, simply if the packages install cleanly on i586.

If that causes problems for i586 users, we'll have someone to ask to help
test the next update.

CC: (none) => davidwhodgins

(In reply to Dave Hodgins from comment #21)
> 
> Just to clarify, comment 20 is not a request for more changes?

Depends on what you are talking about. Since  Anssi Hannula forgot to mark the sysconfig file as a non-overwritable config file I was wondering if maybe 
lib64lirc0 needed to be marked as a dependency. 

> (In reply to Bit Twister from comment #19)
> > Now all you need is a i586 tester.

> If that's the case, and with no one with lirc devices on i586, we'll approve
> the update, simply if the packages install cleanly on i586.

I mentioned it in passing. I have no clue how testing is managed for i586.

lib64lirc0 is a dependency, just not a versioned one. I'm not sure off-hand if it should be a versioned one, but in any case I'm not going make another update candidate round just for that since it should cause no harm at all that I know of.

(In reply to Anssi Hannula from comment #23)
> lib64lirc0 is a dependency, just not a versioned one. I'm not sure off-hand
> if it should be a versioned one, but in any case I'm not going make another
> update candidate round just for that since it should cause no harm at all
> that I know of.

I was mildly worried that normally, I just install lirc. Am I also going to have to hunt down and install the correct lib64lirc0 version during clean installs?

(In reply to Bit Twister from comment #24)
> I was mildly worried that normally, I just install lirc. Am I also going to
> have to hunt down and install the correct lib64lirc0 version during clean
> installs?

No, the dependency is there. You just had the un-updated version of lib64lirc0 already installed.

In normal clean install and update cases lib64lirc0 will be installed automatically.

Testing complete on Mageia 4 i586 (just testing that it installs cleanly).

Advisory added to svn. Validating the update.

Someone from the sysadmin team please push 12685.adv to updates.

Keywords: (none) => validated_update
Whiteboard: (none) => advisory MGA4-64-OK MGA4-32-OK
CC: (none) => sysadmin-bugs

Update pushed:
http://advisories.mageia.org/MGAA-2014-0078.html

Status: ASSIGNED => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED