Bug#777199: Not updated to latest upstream

. --alec leamas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780062: lircrcd segfaults

This is resolved upstream. The reason is that lircrcd (and some others) is using select(2) and related macros which has limitations when the file descriptors becomes > 1024. Which they eventually becomes on a long-running server. Since this is fixed upstream, I'd say that this bug is blocked on

Bug#790969: lircd stopped recognizing codes

Contrary to all other lirc bugs, updating to latest upstream is most likely not the silver bullet here. My first thought is that this is a hardware problem. Things like fluorescent light, bad batteries or simply something else broken in the old remote. That irrecord doesn't work clearly indicates

Bug#782091: lirc: '/etc/init.d/lirc restart' is broken

Hi! No, I'm not the maintainer, I'm upstream. That said, this should be resolved upstream which uses a pure systemd setup. Technically, this means that this bug is blocked on #777188 - Not updated to latest upstream. There are test debian packages available at upstream; you might want to give

Bug#804397: lirc: installs bad udev rule

in upstream bug #37, our oldest open bug. --alec leamas

Bug#655969: rompting due to modified conffiles which where not modified by the user

This is resolved upstream. New upstream configuration sports a systemd service setup + lirc_options.conf instead of hardware.conf. These are classic configuration files with no specific handling which is supposed to resolve this issue. The downside is of course the breakage caused by not

Bug#702140: default device for mode2 is /dev/lirc; should be /dev/lirc0

This is fixed upstream from 0.9.1. From upcoming 0.9.4 the default is configurable using lirc_options.conf which basically means that the default for mode2 is the same as for lircd.

Bug#676343: var/run/lirc contents disappear due to subtle udev interaction

This should be fixed upstream. Recent upstream uses systemd with socket activation. Basically, this means the the socket is created at an very early stage by systemd and then handed to lircd. There is no cleaning of the socket taking place. Together, this means that the scenario described here

Bug#801588: libirman: Multiple issues, some of which blocks updating LIRC

Package: libirman Version: 0.4.4-2 The current libirman package is outdated and needs an update: - The package does not include a shared library. - The note in the description that upstream does not generate a shared library is plain wrong. - The version is old (upstream is 4.4.6) with

Bug#777199: Update also depends on libirman

See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%20801588

Bug#777199: Upstream packaging under way.

FWIW, an upstream packaging effort is under way. The sketch is available as branch 'debian' in the git repo at [1]; a repo view is available at [2]. It will be merged sooner rather than later. Please file upstream bugs as required. Of course, to maintain an upstream package is not ideal.

Bug#801719: Symlink in python directory causes dh_python3 crash.

Package: dh-python Version: 1.2014-2 With a symlink in the python package I install, dh-python3 crashes with enclosed backtrace. Removing the symlink fixes the problem. The symlink is used to locate some configuration relative to the python installation directory i. e., __file__.

Bug#777199: Making a 0.9.3 package

@Trent: I have tried to create a Debian/Ubuntu PPA. My main idea has been to try to understand the difficulties, feed some patches back to upstream and perhaps provide a 0.9.3 package outside of the official distro channels. If you are able to help, perhaps we could get this rolling. First of

Bug#806815: RFS: lirc/0.9.4-devel-0.1 [NMU] -- Linux Infrared Remote Control

ending message to the QA team. I have also requested to be member of this group. The packaging situation has been discussed: https://lists.debian.org/debian-mentors/2015/10/msg00487.html The update is disruptive and needs manual intervention: https://lists.debian.org/debian-devel/2015/11/msg00082.html Regards, --Alec Leamas

Bug#808249: RFS: libirman/0.5.1-1 [NMU]

tained from http://www.example.com. Changes since the last upload: libirman (0.5.1-1) unstable; urgency=medium * Update to latest upstream, closes: #801588. * Handle conditional build of lirc plugin when lirc >= 0.9.4. -- Alec Leamas <leamas.a...@gmail.com> Wed, 11 Nov 2015 18:16:26 +010

Bug#790969: [Pkg-lirc-maint] Bug#790969: Same here...

On 26/06/16 17:01, Andreas Heinlein wrote: I came acrosss this bug since it describes exactly my problem - except that I can rule out any hardware fault. My setup is working fine under Ubuntu 12.04 with Kernel 3.13 and LIRC 0.9.0. I installed Debian 8.5 on the same machine on another

Bug#808249: RFS: libirman/0.5.1-1 [NMU]

On 02/03/16 19:27, Gianfranco Costamagna wrote: Hi, now we are waiting for Stefan to review the package :) cheers, G. And, probably more important, we we are waiting for Stefan to review the lirc package. lirc currently has a build dependency on libirman, but the upcoming lirc package

Bug#806815: RFS: lirc/0.9.4~pre1-1.3 [NMU]

On 15/05/16 17:19, Mattia Rizzolo wrote: On Sun, May 15, 2016 at 03:16:01PM +, Mattia Rizzolo wrote: Given that nothing happened here in the last 6 months, I'm closing this RFS ticket. Feel free to open a new one if/when you'll come back. I mean, Stefan is (at least in Debian) very much

Bug#790969: [Pkg-lirc-maint] Bug#790969: Bug#790969: Same here...

On Fri, 8 Jul 2016 18:07:34 +0200 Alec Leamas <leamas.a...@gmail.com> wrote: > > > On 03/07/16 11:21, Andreas Heinlein wrote: > > I did as described and could reproduce the bug. Both the debug messages > > and irrecord claiming it cannot find any toggle mask. What no

Bug#790969: [Pkg-lirc-maint] Bug#790969: Bug#790969: Same here...

On 03/07/16 11:21, Andreas Heinlein wrote: I did as described and could reproduce the bug. Both the debug messages and irrecord claiming it cannot find any toggle mask. What now? First, since the bug is present also on 0.9.4 I filed an upstream bug [1]. If possible, I would appreciate if we

Bug#790969: [Pkg-lirc-maint] Bug#790969: Bug#790969: Same here...

Hi! On Phone now (sailing), back later -Alec Andreas Heinlein skrev: (3 juli 2016 11:21:29 CEST) >I did as described and could reproduce the bug. Both the debug messages >and irrecord claiming it cannot find any toggle mask. What now? > >Greets, >Andreas >

Bug#851618: [Pkg-lirc-maint] Bug#851618: lirc: adequate reports multiple obsolete-conffiles for lirc Package: lirc

On Sat, 21 Jan 2017 13:52:48 +0800 Paul Wise <p...@debian.org> wrote: > On Thu, 2017-01-19 at 15:22 +0100, Alec Leamas wrote: > > > So, since this is a bug, have you any pointer/idea how to resolve it? > > Since this isn't one of the standard 'conffile got removed' or

Bug#851618: [Pkg-lirc-maint] Bug#851618: lirc: adequate reports multiple obsolete-conffiles for lirc Package: lirc

On 19/01/17 06:21, Paul Wise wrote: On Thu, 2017-01-19 at 06:15 +0100, Alec Leamas wrote: Question is still *why* adequate flagged these files as obsolete... It is dpkg that flagged them as obsolete, adequate just relays that. OK, leaving bug open for a day or two in case submitter

Bug#851618: [Pkg-lirc-maint] Bug#851618: lirc: adequate reports multiple obsolete-conffiles for lirc Package: lirc

On 19/01/17 01:44, Paul Wise wrote: dpkg doesn't handle removal of conffiles when they disappear from packages, so the package postinst files need to handle removing obsolete unmodified conffiles from user systems to avoid cruft building up. Thanks fpr reply. Since none of the files flagged

Bug#851618: [Pkg-lirc-maint] Bug#851618: lirc: adequate reports multiple obsolete-conffiles for lirc Package: lirc

On 19/01/17 12:01, Paul Wise wrote: On Thu, 2017-01-19 at 11:41 +0100, Alec Leamas wrote: OK, leaving bug open for a day or two in case submitter wants to re-assign it to dpkg. Will otherwise eventually close it since it doesn't seem to be a lirc bug. This is incorrect, it is a lirc bug

Bug#851618: lirc: adequate reports multiple obsolete-conffiles for lirc Package: lirc

> On Tue, 17 Jan 2017 03:12:49 +0530 > =?UTF-8?B?c2hpcmlzaCDgpLbgpL/gpLDgpYDgpLc=?= wrote: > > > Adequate reported multiple obsolete-conffiles for lirc - > > > > [$] adequate lirc > > > > lirc: obsolete-conffile /etc/lirc/irexec.lircrc > > lirc: obsolete-conffile

Bug#638163: Bug is obsolete

Due to the major update to 0.9.4b (currently in experimental) this bug is obsolete, The configuration is completely different, and whatever problems which are left needs to be asserted in new bugs against the new version.

Bug#527932: [Pkg-lirc-maint] Bug#527932: 0.4.5 released

On 24/10/16 23:22, Gianfranco Costamagna wrote: control: fixed -1 0.5.2-0.2 control: close -1 0.4.5 was released Apr 10th: But not this year: * Fri Apr 10 2009 Ján ONDREJ (SAL) - 0.4.5-1 --a

Bug#842330: [PATCH] [RC] Fix syslog.h conflict with upcoming lirc-0.9.4

lirc_client.h. Since ffmpeg uses macros like LOG_DEBUG which conflicts with the symbols in syslog.h this leads to FTBS erros. Enclosed patch basically undefines the syslog symbols before re-using them. Author: Alec Leamas <lea...@nowhere.net> --- squeezelite-1.8.orig/ir.c +++ squeezelite-1.8/ir.c @@

Bug#842326: [PATCH] [RC] Fix FTBS for when building against upcoming lirc-0.9.4

; urgency=medium + + * New upstream release + + -- Alec Leamas <lea...@nowhere.net> Fri, 28 Oct 2016 07:05:23 +0200 + ncmpc (0.24-1) unstable; urgency=medium diff -rNU2 ncmpc-0.24/debian/control ncmpc-0.25/debian/control --- ncmpc-0.24/debian/control 2014-04-27 13:38:06.0 +0200 +++

Bug#842695: [Pkg-lirc-maint] Bug#842695: lirc: block testing migration

On 31/10/16 12:51, Gianfranco Costamagna wrote: Source: lirc Version: 0.9.4c-4 Severity: Serious Lets block the testing migration until we are confident with the package and some more users have tested it :) So, what does this mean. Who is expected to test things not in unstable? I'm not

Bug#842695: lirc: block testing migration

On 31/10/16 12:51, Gianfranco Costamagna wrote: Lets block the testing migration until we are confident with the package and some more users have tested it So, what does this mean. Who is expected to test things not in unstable? I'm not that concerned about the overall functionality, it

Bug#842954: ITP: lirc-compat-remotes

package: wnpp Severity: wishlist Owner: Alec Leamas <leamas.a...@gmail.com> * Package name: lirc-compat-remotes Version : 0.0.9 Upstream Author : lirc project * URL : http:/sf.net/p/lirc * License : GPL2+ Programming Lang: n/a Description : Obs

Bug#845499: Mid-air collision

Hi! Thanks for patch However, this has become somewhat messy since I have addressed the BSD failures in last release 0.9.4c-5. As a consequence, your patch does not apply. If you could rebase your patch against i the current -5 release I would be happy to merge it in debian as well as

Bug#845499: Clarification...

Sorry, last note was clear as mud. The release 0.9.4c-5 builds fine on bsd, so from that perspective no further patching is required. However, I would be happy to accept patches to make it build also on hurd (atltough without USB and major desktop support, the hurd usecase seems, well, far

Bug#848135: 848135

Hm... thanks for reporting! That said, what's the problem here, besides the piuparts message?. It is perfectly possible (actually, recommended) to run lircd as a regular user. When doing so, the output socket is by default created as /run/lirc/lircd which will fail unless the directory is

Bug#849266: [Pkg-lirc-maint] Bug#849266: lirc: does not work with update 0.9.4c-4 to 0.9.4c-5

On Sun, 25 Dec 2016 16:42:10 +0100 Thomas Renard wrote: > Because I did not find out how (and with wich lib) kodi connects to lirc > I need some time to investigate. Please stand by - I will give you more > information if I find out the problem from my point of view. Ping? I

Bug#849266: [Pkg-lirc-maint] Bug#849266: Kodi problem

On 06/01/17 20:19, Thomas Renard wrote: So for me this bug can be closed. I will certainly not close it until the README.debian is updated. This important piece of information is missing there. That said, this is somewhat insane. That device is gone since very long. And given that

Bug#850467: kodi: Wrong "device" path for lirc

On Fri, 06 Jan 2017 20:27:05 +0100 Thomas Renard wrote: > > kodi is hard coded to the wrong "device" path to lirc. > The binary tries /dev/lircd but the "device" (which is a socket!) > can be found at /var/run/lirc/lircd. Hi! lirc maintainer speaking... note that the

Bug#850467: kodi: Wrong "device" path for lirc

On 07/01/17 02:57, Bálint Réczey wrote: Hi, A proper fix for this needs to be something accepted by upstream, I guess. Kodi's build system allows setting the default device through a ./configure option thus I think this does not have to be upstreamed. Do you mean upstreaming a more

Bug#845499: Clarification...

On Mon, 26 Dec 2016 17:38:47 +0100 Samuel Thibault <sthiba...@debian.org> wrote: > Hello, > > Mails sent to n...@bugs.debian.org are NOT sent to the submitter, so I > actually never got this answer... Oops, debian still has a few surprises in her sleeves... thanks for he

Bug#850467: kodi: Wrong "device" path for lirc

On 07/01/17 03:55, Alec Leamas wrote: Just syncing is of course the first, minimal step. But bottom line is that a lirc user could set the (typically secondary) device to anything, it's just a config file. So a compile-time setting will not make in the long run. Other apps e. g., mythTV has

Bug#849266: [Pkg-lirc-maint] Bug#849266: Kodi problem

On Fri, 6 Jan 2017 21:13:43 +0100 Thomas Renard wrote: > Reported kodi problem in #850467 Discussed there, conclusions: Update defaults, until then kodi can be configured to use the proper path. Still, the really strange thing here is the existence of the /dev/lirc link.

Bug#810445: lirc: please switch to libusb 1.0

On Sat, 9 Jan 2016 01:20:15 +0100 Aurelien Jarno wrote: > On 2016-01-09 01:05, Stefan Lippers-Hollmann wrote: > > > I'm asking because there are two options: > > > > - pushing the current upstream version, with a transition, involving > > around 30 rdepends, needing

Bug#790969: We need to do something...

There are now updated lirc packages in stretch and sid. Assuming that this is indeed about the kernel bug described above, the issue is worked-around by them. Of course, I would appreciate if there was more input on this bug. Will close shortly otherwise.

Bug#849266: [Pkg-lirc-maint] Bug#849266: lirc: does not work with update 0.9.4c-4 to 0.9.4c-5

On 24/12/16 13:15, Thomas Renard wrote: Package: lirc Version: 0.9.4c-5 Severity: normal Dear Maintainer, with the upgrade to 0.9.4c-5 there is no communication to vdr and kodi possible anymore. irw works fine but there is no reaction from kodi and vdr anymore. Hi! What version where

Bug#849266: [Pkg-lirc-maint] Bug#849266: lirc: does not work with update 0.9.4c-4 to 0.9.4c-5

Hi Tomas! On 24/12/16 16:40, Thomas Renard wrote: What version where you updating from? it was 0.9.4c-4 and yes, I needed to change my configs with upgrading to 0.9.4xxx some weeks ago. OK, that should rule out a lot of things... > etc/lirc/lircd.conf.dist [Errno 2] Datei oder

Bug#860039: [Pkg-lirc-maint] Bug#860039: liblirc-dev pkg-config does not provide proper include paths

On 10/04/17 17:29, Matthew Gabeler-Lee wrote: Package: liblirc-dev Version: 0.9.4c-9 Severity: normal Trying to build an LIRC plugin using liblirc-dev doesn't work, because the installed pkg-config file does not provide proper include flags for the cflags output: Thanks for reporting.

Bug#860065: [Pkg-lirc-maint] Bug#860065: lirc: Ignores remote configs included with absolute paths

On 11/04/17 04:13, Matthew Gabeler-Lee wrote: Package: lirc Version: 0.9.4c-9 Severity: normal If you put a line like this in lircd.conf or one of the files it includes: include "/absolute/path/to/remote.conf" It will be ignored. Thanks for reporting! This is tracked upstream at

Bug#859491: systemd socket activation is missing in 0.9.4c

Package: lirc Version: 0.9.4c-8 This is a tracker for upstream bug https://sourceforge.net/p/lirc/tickets/274/ Due to upstream systemd changes, lirc fails to use systemd activation. This causes subtle bugs during system boot.

Bug#860300: [Pkg-lirc-maint] Bug#860300: lircmd does not work

On 14/04/17 11:18, Bernd Schumacher wrote: I want to use lircmd After making sure that lirc works to control vdr and kodi, I configured lircmd in /etc/lirc/lirc_options.conf [lircmd] uinput = True nodaemon= False After starting "systemctl start lircmd", lircmd started

Bug#860296: [Pkg-lirc-maint] Bug#860296: lirc is spamming syslog with messages

On 14/04/17 10:15, Hans-J. Ullrich wrote: Sadly I have to tell, the latest version of lirc is spamming syslog with mwessages. To make sure, it is not a problem of an earlier configuration, I deinstalled it completely and reinstalled it new. The message, which is spamming is the following:

Bug#860551: [Pkg-lirc-maint] Bug#860551: lircd-0.9.4c[845]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*

On 18/04/17 15:03, Sebastian Niehaus wrote: Hi! Thanks for reporting! lircd produces high load on loggin: syslog says lircd-0.9.4c[845]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]* not sure if I have done something wrong ... The thing is that the default lirc

Bug#860300: [Pkg-lirc-maint] Bug#860300: lircmd does not work

On Sat, 15 Apr 2017 06:37:28 +0200 Alec Leamas <leamas.a...@gmail.com> wrote: > I cannot reproduce this... something is missing. Could you please expand > on what you did to get this message? Ping? Cheers! --alec

Bug#872147: RFS: lirc/0.10.0-2 NMU

; > Why does the report title say "NMU"? Perhaps it shouldn't - large parts of the debian workflow is still a mystery for me. > On Mon, Aug 14, 2017 at 05:41:45PM +0200, Alec Leamas wrote: > > * Restore parallel builds, accidentally disabled in -2 > debian/compat says 10, so --

Bug#872147: RFS: lirc/0.10.0-2 NMU

On Wed, 16 Aug 2017 02:01:12 +0500 Andrey Rahmatullin <w...@debian.org> wrote: > On Tue, Aug 15, 2017 at 10:32:55PM +0200, Alec Leamas wrote: > > > Why does the report title say "NMU"? > > > > Perhaps it shouldn't - large parts of the debian workflow i

Bug#860296: lirc is spamming syslog with messages

On Wed, 09 Aug 2017 12:43:19 +0200 =?utf-8?q?J=C3=B6rg_Frings-F=C3=BCrst?= wrote: > > the same here. > > Lirc is installed as a dependency. This is IMHO the basic problem. lirc should really never be installed as a dependency (lirc-lib is another story). Installing

Bug#872074: liblirc-dev: missing #include

On Mon, 14 Aug 2017 10:03:15 +0300 Adrian Bunk wrote: > Package: liblirc-dev > Version: 0.10.0-1 > Severity: serious > Control: affects -1 src:libirman > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libirman.html > > ... > In file included from

Bug#872147: RFS: lirc/0.10.0-2 NMU

lircmd non-existing socket writes, in -1. Regards, -- Alec Leamas

Bug#872375: lirc: irrecord segfaults when recording a button

On Fri, 18 Aug 2017 22:38:15 +0200 Gianfranco Costamagna wrote: > Hello, > > > Dear Maintainer, > > > > When trying to create a configuration file for my remote, irrecord > > crashes when it gets to the 'Now hold down button Xxx' step: > can you please try 0.10.0 from

Bug#860296: [Pkg-lirc-maint] Bug#860296: lirc is spamming syslog with messages

On 20/08/17 12:22, Jörg Frings-Fürst wrote: Hello Alec, > Lirc is installed as a dependency. This is IMHO the basic problem. lirc should really never be installed as a dependency (lirc-lib is another story). Installing lirc means installing the server/service which as of now means

Bug#872749: [Pkg-lirc-maint] Bug#872749: lircd logs all messages twice

On 20/08/17 20:48, Jörg Frings-Fürst wrote: Package: lirc Version: 0.9.4c-9 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, every message if lircd logged twince: Aug 20 20:38:21 merkur lircd[2361]: lircd-0.9.4c[2361]: Error: Cannot glob

Bug#872985: [Pkg-lirc-maint] Bug#872985: lirc: Installation fails, if systemd-tempfiles is not present (sysv-init) (see log)

On 23/08/17 11:46, Stefan Hachmann wrote: Package: lirc Version: 0.10.0-2 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** Der Standardweg ist das Beibehalten der momentanen Version. *** devinput.lircd.conf

Bug#860300: lircmd does not work

This is tracked in upstream bug https://sourceforge.net/p/lirc/tickets/295/ --alec

Bug#860551: lircd-0.9.4c[845]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*

On Fri, 16 Jun 2017 17:32:55 -0300 Eriberto Mota wrote: > Other approach (temporary solution) is disable the lircd daemon: > > # systemctl stop lircd > # systemctl disable lircd Unfortunately, this is not enough. lircd.service is socket-activated from lircd.socket so

Bug#865376: [Pkg-lirc-maint] Bug#865376: lirc: When upgrading from Jessie to Stretch, an old file /etc/init.d/lirc is not deleted

On 20/06/17 22:09, Mikulas Patocka wrote: In Debian Jessie, lirc is started with the /etc/init.d/lirc script In Debian Stretch, lirc is started with the /etc/init.d/lircd script This is not the whole truth. The old lirc script actually controlled all of the the lirc services, lircd being

Bug#864785: libftdi1: link error on kfreebsd

Package: libftdi1 Version: 0.20-4 This happens while building the upcoming version 0.10.0 of lirc. The configure program will find the libftdi1 and thus build lirc's ftdi plugin. However, after building lirc, we have this check available $ tools/lirc-lsplugins -qU plugins/.libs/ ftdi ... -

Bug#860551: [Pkg-lirc-maint] Bug#860551: lircd-0.9.4c[845]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*

I have done some more testing. It seems that on a system with lircd.socket started but no clients running this logging does not occur. Which means that the the excessive logging is the result of some client repeatedly trying to access the lircd socket, but is denied since lircd disconnects

Bug#860300: lircmd does not work

On Wed, 21 Jun 2017 09:44:28 +0200 Alec Leamas <leamas.a...@gmail.com> wrote: > This is tracked in upstream bug https://sourceforge.net/p/lirc/tickets/295/ > > --alec Fixed upstream and in experimental. Thanks for reporting and debugging! --alec

Bug#872375: lirc: irrecord segfaults when recording a button

Hi! On Tue, 22 Aug 2017 17:06:29 +0200 (CEST) Francois Gouget wrote: > On Fri, 18 Aug 2017, Gianfranco Costamagna wrote: > > > Hello, > > > > > Dear Maintainer, > > > > > > When trying to create a configuration file for my remote, irrecord > > > crashes when it gets to the

Bug#872749: [Pkg-lirc-maint] Bug#872749: lircd logs all messages twice

Hi! On 29/08/17 22:03, Jörg Frings-Fürst wrote: Hi Alec, As a starter, what happens if you use journalctl to inspect the logs? Still same error? We need to establish the difference between your setup and those I use... Its the same (log all twice): Aug 29 05:41:28 merkur lircd[4494]:

Bug#872749: [Pkg-lirc-maint] Bug#872749: lircd logs all messages twice

On 04/09/17 16:21, Jörg Frings-Fürst wrote: All messages logged twice: [quote] Sep 4 05:22:48 merkur lircd[2247]: lircd-0.10.0[2247]: Warning: config file /etc/lirc/lircd.conf contains no valid remote control definition Sep 4 05:22:48 merkur lircd[2247]: lircd-0.10.0[2247]: Notice:

Bug#872375: lirc: irrecord segfaults when recording a button

On 24/09/17 16:12, Francois Gouget wrote: Now as to why I have driver=devinput in lirc_options.conf, it's because it's the only way I found to get my remote to work. Setting driver=default driver does not work and if I only provide devinput.lircd.conf and no Hauppauge_PVR350.conf file then it

Bug#876912: [Pkg-lirc-maint] Bug#876912: lirc: nodaemon option

Hi, On 26/09/17 23:02, Arno None wrote: Source: lirc Version: 0.10.0 Severity: normal Dear Maintainer, To start the lirc service lircd with the option 'nodaemon' in /etc/lirc/lirc_options.conf I had to remove the option --nodaemon from

Bug#872375: lirc: irrecord segfaults when recording a button

On 24/09/17 03:50, Francois Gouget wrote: Actually it's the -f option that causes the crash. I can reproduce it with: # irrecord -f /tmp/foo.conf This would just indicate that foo.conf is broken somehow. Given the state of lirc, I don't think it's feasible to make it handle any kind of

Bug#876750: [Pkg-lirc-maint] Bug#876750: lirc: Configuration loglevel

On 25/09/17 16:29, Arno None wrote: When trying to get lirc running with an IguanaIR transceiver I came accross the followig: Loglevel is not configured with 'loglevel' in lirc_options.conf but with 'debug'. Ack, this is a mess that needs to be rectified, keeping it backwards

Bug#872749: [Pkg-lirc-maint] Bug#872749: lircd logs all messages twice

On 21/08/17 09:04, Jörg Frings-Fürst wrote: Aug 20 20:38:21 merkur lircd[2361]: lircd-0.9.4c[2361]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]* Aug 20 20:38:21 merkur lircd-0.9.4c[2361]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]* I cannot reproduce this,

Bug#872749: [Pkg-lirc-maint] Bug#872749: lircd logs all messages twice

On 21/08/17 16:50, Jörg Frings-Fürst wrote: Am Montag, den 21.08.2017, 09:32 +0200 schrieb Alec Leamas: On 21/08/17 09:04, Jörg Frings-Fürst wrote: Aug 20 20:38:21 merkur lircd[2361]: lircd-0.9.4c[2361]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]* Aug 20 20:38:21 merkur

Bug#872985: [Pkg-lirc-maint] Bug#872985: [lirc] postinst of lirc fails if systemd is not installed

Hi! On 29/08/17 01:50, Lars Kruse wrote: /I experienced the same problem after upgrading lirc from v0.9.4c-9 to />/v0.10.0-2 />/On 23/08/17 12:34, Alec Leamas wrote: / /hm... don't you have systemd installed? systemd-tmpfiles is an />>/integral part of systemd, seems strange tha

Bug#872749: [Pkg-lirc-maint] Bug#872749: lircd logs all messages twice

Hi! On 31/08/17 18:56, Jörg Frings-Fürst wrote: I think you should fix the error times instead of thinking about whether the title does not fit. As explained earlier, the fix is not simple from a packaging perspective. Still, users could easily either disable lircd.socket or just remove

Bug#901510: RFS: ddupdate/0.6.1-2 (Upstream bugs #11, #12, #13)

Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ddupdate" * Package name: ddupdate Version : 0.6.1-2 Upstream Author : Alec Leamas * URL : https://github.com/leamas/ddupdate * License

Bug#886547: ITP ddupdate: A Dynamic DNS Updater

Package: wnpp Severity: wishlist * Package name: ddupdate Version : 0.1.0 Upstream Author : Alec leamas * URL : https://github.com/leamas/ddupdate * License : MIT Programming Lang: Python3 Description : A Dynamic DNS Updater ddupdate is a tool

Bug#886546: ITP ddupdate: A Dynamic DNS Updater

Package: wnpp Severity: wishlist * Package name: ddupdate Version : 0.1.0 Upstream Author : Alec leamas * URL : https://github.com/leamas/ddupdate * License : MIT Programming Lang: Python3 Description : A Dynamic DNS Updater ddupdate is a tool

Bug#887126: RFS: ddupdate/0.2.0-1 #886546

Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "ddupdate" Package name: ddupdate Version : 0.2.0-1 Upstream Author : Alec Leamas URL : https://github.com/leamas/ddupdate License

Bug#887126: RFS: ddupdate/0.2.0-1 #886546

Hi Juhani! On 07/02/18 15:38, Juhani Numminen wrote: > Hi Alec, > > Alec Leamas kirjoitti 04.02.2018 klo 18:32 > >>> Please use up-to-date lintian. It'll give you an error tag and several >>> informational and pedantic tags, some of which are easily dealt with

Bug#890121: ddupdate: bad hyphenation and spacing in package description

On 11/02/18 12:20, Paul Wise wrote: > Package: ddupdate > Version: 0.5.3-1 > Severity: minor > > The package description for ddupdate has two minor issues with spacing > and hyphenation. Thanks for reporting! A new upstream release is under way. Unless there are any objections I'll postpone

Bug#872375: lirc: irrecord segfaults when recording a button

On Sun, 11 Feb 2018 10:07:02 -0800 James Bottomley wrote: > I'm getting this same segfault as well.  My old remote fell apart, so I > was trying to train the IR receiver on a new one (well, the unused VCR > section of the current TV remote. > This is what I

Bug#890374: Aw: Re: bug in lirc - 'post' and 'pre' not sent

On 14/02/18 10:11, softw...@quantentunnel.de wrote: > Hi Alec > > Thanks. I have filed a bug, see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890374 > > Although not my opinion, I make you aware that Bengt Martensson on the lirc > mailing list is against patching the code. As I wrote

Bug#907070: ITP: unarr -- Decompression library for RAR, TAR, ZIP and 7z archives

Package: wnpp Severity: wishlist Owner: Alec Leamas * Package name: unarr Version : 20150801.d1be8c43 Upstream Author : Simon Bünzli * URL : https://github.com/zeniko/unarr * License : LGPL-3 Programming Lang: C++ Description : Decompression library

Bug#907071: ITP: wxcurl -- Simple API between libCurl and WxWidgets

Package: wnpp Severity: wishlist Owner: Alec Leamas * Package name: wxcurl Version : 1.0 Upstream Author : Casey O'Donnell * URL : http://wxcode.sourceforge.net/components/wxcurl/ * License : wxWidgets Programming Lang: C++ Description : Simple API

Bug#907068: ITP: wxsvg -- C++ library to create, manipulate and render SVG files

Package: wnpp Severity: wishlist Owner: Alec Leamas * Package name: wxsvg Version : 1.5.14 Upstream Author : Alex Thuering * URL : http://wxsvg.sourceforge.net/ * License : wxWindows Programming Lang: C++ Description : C++ library to create

Bug#907065: ITP: opencpn -- Open Source Chartplotter and Marine GPS Navigation Software

Package: wnpp Severity: wishlist Owner: Alec Leamas * Package name: opencpn Version : 4.8.6 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPLv3 Programming Lang: C++ Description : Chartplotter and Marine GPS Navigation

Bug#907333: ITP: libnmea0183: C++ library for decoding NMEA0183 data

Package: wnpp Severity: wishlist Owner: Alec Leamas * Package name: libnmea0183 Version : 0.1.0 Upstream Author : Sam Blackburn * URL : https://github.com/leamas/NMEA0183 * License : Expat Programming Lang: C++ Description : C++ library for decoding

Bug#910895: RFS: lirc/0.10.1-1

e obtained from http://lirc.org. Changes since the last upload: - Updated to latest upstream bugfix release - Fixed a crash when starting lirc-setup(1). - Dropped an upstreamed build patch. - Update to version 4.2.1, compat level 11 (systemd fixes). Regards, Alec Leamas

Bug#911038: sysconfig: inconsistent sitelib path

anything wrong here I file the issue against python. Regards, Alec Leamas

Bug#911541: RFS: wxsvg/2:1.5.15+dfsg.2-1

pendencies. Regards, Alec Leamas

Bug#917531: ITP: libcxx-serial: Cross-platform c++ serial ports library

On Fri, 28 Dec 2018 10:41:09 +0100 Alec Leamas wrote: > This is a dependency for opencpn, #907065, new for 4.8.8. It turns out that the preferred way to build opencpn in 4.8.8 is without this library. It will still be used in 5.0.0, fingers crossed. So:   - This request is still va

Bug#917561: RFS: opencpn/4.8.8+dfsg.1-1 [ITP]

he opencpn website. Downstream patch provides HTML pointer-to-docs page. * A large number of new build dependencies. * The -plugins package is dropped, opencpn is not usable without the default, limited set of plugins. * A debian/upstream/metadata file is added. Regards, Alec Leamas

Bug#872749: [Pkg-lirc-maint] Bug#872749: lircd logs all messages twice

On Sat, 29 Sep 2018 10:14:33 +0200 Tobias Frost wrote: > Regarding the reported issue, at the BSP in Chemnitz, helmut looked at > his (stretch) installation and also saw the duplicated lines. > I've also debootstraped an sid chroot, systemd-nspawn'ed it and could > also see duplicated log lines.

Bug#917531: ITP: libcxx-serial: Cross-platform c++ serial ports library

Package: wnpp Severity: wishlist Owner: Alec Leamas * Package name: cxx-serial Version : 1.2.1 Upstream Author : William Goodall * URL : http://wjwwood.io/serial/ * License : Expat Programming Lang: C++ Description : C++, cross-platform serial

  1   2   >