Hi Scott,
On 28/10/2022 15:57, Scott Talbert wrote:
On Fri, 28 Oct 2022, Alec Leamas wrote:
Hi Tobias!
Thanks for takin time to reply!
On 28/10/2022 11:00, Tobias Frost wrote:
Hi Alec,
On Fri, Oct 28, 2022 at 10:15:49AM +0200, Alec Leamas wrote:
The core issue here is opencpn, wxsvg
Hi Tobias!
Thanks for takin time to reply!
On 28/10/2022 11:00, Tobias Frost wrote:
Hi Alec,
On Fri, Oct 28, 2022 at 10:15:49AM +0200, Alec Leamas wrote:
The core issue here is opencpn, wxsvg is a dependency. The problem with
opencpn is that it has a plugin universe, and updating
Dear list,
I'm maintaining the opencpn and libwxsvg packages. They both depend on
wxWidgets which now is updated to version 3.2 in testing. Hence, I have
two bugs [1], [2] requesting an update of my packages.
The core issue here is opencpn, wxsvg is a dependency. The problem with
opencpn is
Hi Audrey
On 02/06/2022 20:16, Andrey Rahmatullin wrote:
On Thu, Jun 02, 2022 at 07:19:56PM +0200, Alec Leamas wrote:
Dear list,
I try handle a package which installs a partly compiled,
architecture-dependent python module. Until now this has been done in
/usr/lib/triplet/python3.10/site
Dear list,
I try handle a package which installs a partly compiled,
architecture-dependent python module. Until now this has been done in
/usr/lib/triplet/python3.10/site-packages. This scheme has basically
worked fine.
However, here is an Ubuntu bug [1] where a user runs into problems
Dear list,
On 02/02/2022 18:46, Michael Stone wrote:
On Wed, Feb 02, 2022 at 10:16:36PM +0500, Andrey Rahmatullin wrote:
On Wed, Feb 02, 2022 at 12:12:30PM -0500, Michael Stone wrote:
On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote:
> Doesn't that, then, lead to the suggestion
Hi,
Not a DD, still raising my voice. I'm *not* advocating that Fedora's
processes are "better", just trying to add ideas.
On 26/01/2022 11:43, Adam Borowski wrote:
On Tue, Jan 25, 2022 at 09:38:01PM +0100, Vincent Bernat wrote:
I think we should forego the NEW queue. If people want to
Hi Tobi,
On 06/01/2022 15:46, Tobias Frost wrote:
On Thu, Jan 06, 2022 at 03:43:22PM +0100, Alec Leamas wrote:
Dear list,
I had a bullseye backport of opencpn uploaded to the backports-new queue
before Christmas (thanks, Tobi). This is the first backport I've done.
This morning the queue
Dear list,
I had a bullseye backport of opencpn uploaded to the backports-new queue
before Christmas (thanks, Tobi). This is the first backport I've done.
This morning the queue seems to be processed, it is (was) empty. But I
don't find any trace of my backported opencpn package anywhere.
Hi list,
On 18/11/2021 11:51, Gard Spreemann wrote:
Apologies in advance if this is something that has been discussed a lot
in the past. I'd be very interested in being pointed in the right
direction in that case!
No need to apologize... searching the the devel archives on "NEW queue"
On 26/09/2021 19:03, Alec Leamas wrote:
Hi Jonas,
On 26/09/2021 14:41, Jonas Smedegaard wrote:
I deliberately ignored the timing part of your proposal, and instead
think in "stages" - here is a plan I find sensible:
* maybe you make an test packaging of 3.1.5 - not uploaded
Hi Jonas,
On 26/09/2021 14:41, Jonas Smedegaard wrote:
Quoting Alec Leamas (2021-09-26 12:16:00)
On 26/09/2021 11:08, Jonas Smedegaard wrote:
Quoting Alec Leamas (2021-09-26 10:05:04)
Thanks for taking time to try to sort this out!
On 25/09/2021 18:52, Jonas Smedegaard wrote:
Tight
Hi Jonas,
On 26/09/2021 11:08, Jonas Smedegaard wrote:
Quoting Alec Leamas (2021-09-26 10:05:04)
Hi Jonas,
Thanks for taking time to try to sort this out!
On 25/09/2021 18:52, Jonas Smedegaard wrote:
Tight dependencies should be fine. This is C++, so library symbols is
bit convoluted
Hi Jonas,
Thanks for taking time to try to sort this out!
On 25/09/2021 18:52, Jonas Smedegaard wrote:
Quoting Alec Leamas (2021-09-25 18:23:42)
On 25/09/2021 18:04, Jonas Smedegaard wrote:
Quoting Alec Leamas (2021-09-25 17:47:04)
So, the question: would it be acceptable to bundle
Hi Jonas,
On 25/09/2021 18:04, Jonas Smedegaard wrote:
Hi Alec,
Quoting Alec Leamas (2021-09-25 17:47:04)
So, the question: would it be acceptable to bundle the wxWidgets 3.1.5
sources in next OpenCPN release in such a situation?
How do you and OpenCPN upstream expect to handle bugs
Dear list,
Trying to plan the future for the OpenCPN package. Upstream is currently
shipping a beta, and eventually it will be released and packaged.
In next cycle upstream might update the wxWidgets dependency from 3.0 to
3.1.5. This is problematic, since wxWidgets offers no ABI stability
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Tue, 19 Nov 2019 08:49:56 -0500
Source: opencpn
Architecture: source
Version: 5.0.0+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Debian GIS Project
Changed-By: Alec Leamas
Closes: 946018
Changes:
opencpn (5.0.0+dfsg
-By: Alec Leamas
Description:
libwxsvg-dev - Development files for wxSVG
libwxsvg-tools - SVG library for the wxWidgets toolkit (tools)
libwxsvg3 - SVG library for the wxWidgets toolkit
Closes: 933462
Changes:
wxsvg (2:1.5.21+dfsg.1-1) unstable; urgency=medium
.
* New upstream release
-By: Alec Leamas
Description:
opencpn- Open Source Chartplotter and Marine GPS Navigation Software
opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software
(data
opencpn-plugins - Open Source Chartplotter and Marine GPS Navigation Software
(tran
Changes:
opencpn (4.8.8+dfsg.2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 07 Jul 2019 11:35:53 -0400
Source: ddupdate
Architecture: source
Version: 0.6.4-1
Distribution: sid
Urgency: medium
Maintainer: Alec Leamas
Changed-By: Alec Leamas
Changes:
ddupdate (0.6.4-1) sid; urgency=medium
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 12 Jun 2019 16:33:26 -0400
Source: ddupdate
Architecture: source
Version: 0.6.3-1
Distribution: sid
Urgency: medium
Maintainer: Alec Leamas
Changed-By: Alec Leamas
Changes:
ddupdate (0.6.3-1) sid; urgency=medium
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 18 Feb 2019 16:48:40 -0500
Source: ddupdate
Architecture: source
Version: 0.6.2-1
Distribution: sid
Urgency: medium
Maintainer: Alec Leamas
Changed-By: Alec Leamas
Changes:
ddupdate (0.6.2-1) sid; urgency=medium
.
* New
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 27 Dec 2018 14:57:49 -0500
Source: libcxx-serial
Binary: libcxx-serial-dev libcxx-serial1 libcxx-serial1-dbgsym
Architecture: source amd64
Version: 1.2.1-1
Distribution: unstable
Urgency: medium
Maintainer: Alec Leamas
Maintainer: Debian Lirc Team
Changed-By: Alec Leamas
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infra-red remote control support - Run-time libraries
liblircclient-dev - Transitional
Maintainer: Debian Lirc Team
Changed-By: Alec Leamas
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infra-red remote control support - Run-time libraries
liblircclient-dev - Transitional
Changed-By: Alec Leamas
Description:
libwxsvg-dev - Development files for wxSVG
libwxsvg-tools - SVG library for the wxWidgets toolkit (tools)
libwxsvg3 - SVG library for the wxWidgets toolkit
Changes:
wxsvg (2:1.5.15+dfsg.2-1) unstable; urgency=medium
.
* Re-introduce wxsvg to Debian, latest
Maintainer: Debian Lirc Team
Changed-By: Alec Leamas
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infra-red remote control support - Run-time libraries
liblircclient-dev - Transitional
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Tue, 16 Oct 2018 16:36:08 -0400
Source: libirman
Binary: libirman-dev libirman0 lirc-drv-irman
Architecture: source
Version: 0.5.2-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Lirc Team
Changed-By: Alec Leamas
Maintainer: lirc Maintainer Team
Changed-By: Alec Leamas
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infra-red remote control support - Run-time libraries
liblircclient-dev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 01 Oct 2018 01:23:17 -0400
Source: unarr
Binary: libunarr-dev libunarr1
Architecture: source amd64
Version: 1.0.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian GIS Project
Changed-By: Alec Leamas
Description
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 02 Sep 2018 00:44:03 -0400
Source: unarr
Binary: libunarr-dev libunarr1
Architecture: source amd64
Version: 0~20150801.d1be8c4-1
Distribution: unstable
Urgency: medium
Maintainer: Debian GIS Project
Changed-By: Alec Leamas
On 23/08/18 12:01, Paul Wise wrote:
Hi, thanks for replies!
> On Thu, Aug 23, 2018 at 3:51 PM, Alec Leamas wrote:
>
>> It's not that I don't understand your reasoning. Still, if this is the
>> conclusion, it's kind of sad because it's means that a price-awarded [1]
&g
On 23/08/18 09:26, Paul Wise wrote:
> On Thu, Aug 23, 2018 at 12:59 PM, Alec Leamas wrote:
>
>> Here is some libraries to unbundle; this could certainly could be done,
>> However, the core issue is a few libraries which cannot realistically be
>> unbundled. One exam
On 23/08/18 08:34, Pierre-Elliott Bécue wrote:
> Le jeudi 23 août 2018 à 06:59:45+0200, Alec Leamas a écrit :
>> [may I keep bundled libraries?]
Thanks for reply!
> I'd say that as soon as there's no other way of having your package work
> (right, there's always another wa
Dear list,
Still investigating packaging opencpn[1]. In this context I have looked
into the bundling [2].
Here is some libraries to unbundle; this could certainly could be done,
However, the core issue is a few libraries which cannot realistically be
unbundled. One example is mygdal, a heavily
Dear list,
Again: Attempting to package OpenCPN [1].
In my discussions w upstream a header has been on the table. While
OpenCPN certainly isn't a library, there is a lot of third-party plugin
development. The interface between the plugins and the main application
lives in a header called
On 16/08/18 07:57, Sebastiaan Couwenberg wrote:
> On 08/16/2018 07:45 AM, Paul Wise wrote:
>> On Thu, Aug 16, 2018 at 4:32 AM, Alec Leamas wrote:
>>> But where is that old packaging repo?
>
> https://salsa.debian.org/debian-gis-team/opencpn
>
> You should tal
On 14 August 2018 10:44:44 CEST, Jonas Smedegaard wrote:
>Quoting Alec Leamas (2018-08-14 10:20:55)
>> I'm considering packaging OpenCPN[1]. It's mostly straight-forward,
>> but the documentation seems problematic.
>>
>> The docs are basicallly a wiki bas
On 14 August 2018 12:42:35 CEST, Paul Wise wrote:
>On Tue, Aug 14, 2018 at 4:20 PM, Alec Leamas wrote:
>
>> I'm considering packaging OpenCPN[1].
>
>The GIS team has attempted to package this before, it might be worth
>reading the -devel and -mentors list archiv
Dear list,
I'm considering packaging OpenCPN[1]. It's mostly straight-forward, but
the documentation seems problematic.
The docs are basicallly a wiki based on DocuWiki [2]. As part of the
release process the site is exported and html and PDF files in the git
tree is updated. This is a manual
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 14 Jun 2018 08:20:55 +0200
Source: ddupdate
Binary: ddupdate
Architecture: source
Version: 0.6.1-2
Distribution: sid
Urgency: medium
Maintainer: Alec Leamas
Changed-By: Alec Leamas
Description:
ddupdate - Tool updating
Hi Daniele!
On 08/04/18 02:18, Daniele Nicolodi wrote:
> Hello,
>
> I'm working on a package that installs a systemd user instance unit file
> that needs to be enabled with
>
> # systemctl --global enable foo.service
>
> Using debhelper, dh_systemd_enable takes care of this automatically for
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 18 Feb 2018 20:05:37 +0100
Source: ddupdate
Binary: ddupdate
Architecture: source all
Version: 0.6.0-1
Distribution: sid
Urgency: medium
Maintainer: Alec Leamas <leamas.a...@gmail.com>
Changed-By: Alec Leamas <
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 04 Feb 2018 19:35:45 +0100
Source: ddupdate
Binary: ddupdate
Architecture: source all
Version: 0.5.3-1
Distribution: sid
Urgency: medium
Maintainer: Alec Leamas <leamas.a...@gmail.com>
Changed-By: Alec Leamas <
elp_Debian._Tell_me_what_I_can_do
On 15/01/18 19:35, Andrey Rahmatullin wrote:
> On Mon, Jan 15, 2018 at 07:31:32PM +0100, Alec Leamas wrote:
>>>> So: Have anyone time to check my package ddupdate[1] for errors or
>>>> mistakes?
>>> The RFS is 1 day old. It's too ear
On 07/01/18 22:41, Hleb Valoshka wrote:
> Have you sent the same warnings to your mates from LP fanclub
Please, stop this. This is the Debian devel list, and personal opinions
about Lennart Poettering (or anyone else) IMHO just have no place here.
Time to create a new list systemd-flamewars?
On 04/09/17 07:40, Kamil Jońca wrote:
> the only thing is '/var/run/freeradius/' directory creation.
If that's the problem(?), perhaps you should look into systemd's tmpfile
mechanism.
--alec
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infr
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infr
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infr
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infr
On 12/02/17 13:47, Simon McVittie wrote:
Hi, thanks for thoughts!
/lib/udev/??-mm-*.rules are probably of interest. ModemManager
implements a whitelist (devices that are definitely modems), a blacklist
(devices that are definitely not modems), and a greylist (devices that
might be modems,
On 12/02/17 11:16, Bastien Roucaries wrote:
Last time braille stuff break (brick) a FPGA device with a jtag adaptator
(serial to jtag). So i really dislike package that bind to all char device.
>
> Btw if you do this you need a break on braille stuff...
Now, we are not talking about
On 11/02/17 10:29, Bastien Roucaries wrote:
Le 10 février 2017 16:13:15 GMT+01:00, Alec Leamas <leamas.a...@gmail.com> a
écrit :
Dear list,
[cut]
Proposed /dev/ permissions after installing lirc:
- The /dev/lirc? devices are set user:group lirc:lirc and mode 660
(udev rule).
- Th
Dear list,
After some work it seems that an updated LIRC package has landed in
stretch without any major problems. This resolves the urgent need to
update it to something recent enough to be supported by upstream.
One remaining problem is that lircd, the main LIRC daemon, runs as root.
This
On 04/02/17 15:58, Vincent Bernat wrote:
A Github-like interface is totally compatible with the CLI: pull
requests are exposed as branches, you can merge, modify, do anything you
like. The web UI tries to catch up with what you do (if you merge
through the CLI, the web interface will detect
On 04/02/17 13:23, Bernd Zeimetz wrote:
On 01/30/2017 05:45 PM, Sean Whitton wrote:
I agree, they aren't as good. However, they're very nearly as good, and
it's too common to overstate how good GitHub's workflow is.
Nearly as good? Where can I click 'merge' in a web gui in Debian???
On 30/01/17 13:59, Paul Wise wrote:
On Mon, Jan 30, 2017 at 8:54 PM, Alec Leamas wrote:
But, we cannot just say "our tools are as good as github".
Because they are not.
That is a very subjective statement. I for one really really dislike
github and much prefer other workflows
On 30/01/17 13:32, The Wanderer wrote:
On 2017-01-30 at 03:54, Bernd Zeimetz wrote:
On 01/30/2017 12:44 AM, Sean Whitton wrote:
Same here. Also since I've moved my major packages to github, a
constant stream of pull requests for even simple bugs like typos
is coming in. People are used to
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infr
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infr
On 28/12/16 17:02, Niels Thykier wrote:
Note the difference between "=?UTF-8?Q?" vs. "=?UTF-8?b?" (Q vs. b). I
presume the "b" is for "binary" or/and "Base64 encoded" vs. Q which
would be "quoted printed" or something like that.
I am not an expert on permitted ways of quoting UTF-8 in mail
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 28 Oct 2016 07:05:23 +0200
Source: ncmpc
Binary: ncmpc ncmpc-lyrics
Architecture: source
Version: 0.25-0.1
Distribution: unstable
Urgency: medium
Maintainer: Sebastian Harl <tok...@debian.org>
Changed-By: Alec Leama
On 08/11/16 16:05, Samuel Thibault wrote:
Jens Reyer, on Tue 08 Nov 2016 15:31:00 +0100, wrote:
The dh-exec-filter manpage should help. I assume you want something like:
debian/install:
#! /usr/bin/dh-exec
[!kfreebsd-any] debian/some-linux-only-file /usr/lib/my-package
For linuxish things,
On 08/11/16 15:50, Thibaut Paumard wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Le 08/11/2016 à 15:13, Alec Leamas a écrit :
Trying to understand the debhelper, dh-exec and dh-exec-subst
manpages. However, I just don't get it. All these tools seems to
be about changing
On 08/11/16 15:40, Christian Seiler wrote:
However, my need is to actually *remove* some files from e. g.,
debian/install since they are not built on kfreebsd. How could I do
this?
cat > debian/$FOO.install <
OK, got it. Thanks!
That said, if you're using dh-systemd, that shouldn't be
On 08/11/16 15:31, Jens Reyer wrote:
On 08.11.2016 15:13, Alec Leamas wrote:
On 08/11/16 14:56, Jens Reyer wrote:
Hi Alec [answering on debian-mentor
Hi Jens! thanks for reply! We are in cross-posting hell... redirecting
to debian-devel
Yup, but I agree with Henrique that mentors
On 08/11/16 14:56, Jens Reyer wrote:
Hi Alec [answering on debian-mentor
Hi Jens! thanks for reply! We are in cross-posting hell... redirecting
to debian-devel
On 08.11.2016 13:39, Alec Leamas wrote:
In particular:
- How can I handle that kfreebsd should install a different set
On 08/11/16 14:48, Vincent Danjean wrote:
Hi,
Le 08/11/2016 à 13:39, Alec Leamas a écrit :
I'm now trying to wrap my head around how to conditionalize a packet such as
lirc. I'm coming from Fedora/RPM and used to just spread some
%ifarch in the spec file. Now, is something similar
On 08/11/16 14:13, Henrique de Moraes Holschuh wrote:
On Tue, Nov 8, 2016, at 10:39, Alec Leamas wrote:
I'm now trying to wrap my head around how to conditionalize a packet
such as lirc. I'm coming from Fedora/RPM and used to just spread some
%ifarch in the spec file. Now, is something
Dear list,
We are about to push the new lirc to stable. As-is, the package declares
a dependency on systemd and thus rightfully fails to build on kfreebsd
platforms. This is a pity since the core software lirc builds fine at
least on FreeBSD 10.3.
However, lirc contains all sorts of systemd
-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
lirc-compat-remotes - Compatibility remote definitions for lirc
Closes: 842954
Changes:
lirc-compat-remotes (0.9.0-1) unstable; urgency=medium
.
* Initial release (Closes: #842954)
Ch
: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infra-red re
-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
libirman-dev - Library, headers and test tools for the Irman infrared hardware
libirman0 - Shared library to access the libirman hardware
lirc-drv-irman - LIRC plugin providing irman compatible devices sup
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infr
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infr
-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
libirman-dev - Library, headers and test tools for the Irman infrared hardware
libirman0 - Shared library to access the libirman hardware
lirc-drv-irman - LIRC plugin providing irman compatible dev
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infr
On 16/10/16 10:07, Alec Leamas wrote:
On 16/10/16 09:35, SZ Lin (林上智) wrote:
Hi,
I want to package python library - *uritemplate* [1]; however, I found
that there is a same name package with similar function in Debian
archive [3].
Do you have any suggestion on it ?
What about
On 16/10/16 09:35, SZ Lin (林上智) wrote:
Hi,
I want to package python library - *uritemplate* [1]; however, I found
that there is a same name package with similar function in Debian
archive [3].
Do you have any suggestion on it ?
What about following the github scheme i. e.,
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblirc0 - Infr
: medium
Maintainer: lirc Maintainer Team <pkg-lirc-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
liblirc-client0 - infra-red remote control support - client library
liblirc-dev - Infra-red remote control support - development files
liblir
-ma...@lists.alioth.debian.org>
Changed-By: Alec Leamas <leamas.a...@gmail.com>
Description:
libirman-dev - Library, headers and test tools for the Irman infrared hardware
libirman0 - Shared library to access the libirman hardware
lirc-drv-irman - LIRC plugin providing irman compat
On 14/09/16 10:58, Gianfranco Costamagna wrote:
I can sponsor it, but I would like to see some positive feedbacks before doing
it :)
Part of this is the upstream, debian packaging which (besides changelog)
is identical to the package in mentors. There has been several hundred
downloads
On 12/09/16 19:10, Don Armstrong wrote:
On Sun, 11 Sep 2016, Gianfranco Costamagna wrote:
Since the pkg-lirc is almost dead (the last uploader retired some days
ago), and Stefan is too busy to review it again, I'm asking for
advices:
Gregor made the last upload of this package, so that
On 16/08/16 16:21, Jonas Smedegaard wrote:
Quoting Ian Jackson (2016-08-16 15:32:19)
Ghostscript packaged for Debian has a debian/copyright file with ~400
lines enumerating which source files are covered by which license (and
then another ~800 lines covering the actual licenses verbatim).
Dear list,
I get the following linker error building upstream lirc on sid, updated
as of today:
/usr/bin/ld: cannot find /lib/
/usr/bin/ld: cannot find s/libusb-0.1.so.4.4.4
The link command (which builds a plugin):
$ gcc -shared -fPIC -DPIC .libs/atilibusb_la-atilibusb.o -Wl,-rpath \
Hi!
Thansk for long reply!
On 17/01/16 03:23, Jonathan de Boyne Pollard wrote:
Michael Biebl:
I wonder if nosh could be an option for non-linux. According to its
website it supports native systemd service files.
This caught my eye, so I thought that I'd demonstrate. Before getting
to
how far that
>> "systemd support" goes.
>
> This caught my eye, so I thought that I'd demonstrate. Before getting
> to what I did, let's clear up some tangential points.
>
> Alec Leamas:
>
>> The systemd setup [for lirc] is three different service
On 15/01/16 21:58, Stefan Lippers-Hollmann wrote:
Hi
On 2016-01-15, Alec Leamas wrote:
On 15/01/16 21:06, Michael Biebl wrote:
Am 15.01.2016 um 21:01 schrieb Alec Leamas:
On 15/01/16 19:04, Russ Allbery wrote:
[...]
If the names do not match, you can ship a (static) symlink in the
package
Dear list,
In the process of a complicated update, there is a question about how to
handle the systemV init scripts when doing the systemd transition.
The package (lirc) has upstream systemd scripts which of course are
packaged. The existing Debian version has sysV scripts. However, these
On 15/01/16 14:13, Dmitrii Kashin wrote:
Alec Leamas <leamas.a...@gmail.com> writes:
Dear list,
Given all this: would it be OK to drop the sysV files in a stretch update?
I suppose it's not okay, because you'll get a lot of bug reports from
non-linux based debian distrib
On 15/01/16 21:06, Michael Biebl wrote:
Am 15.01.2016 um 21:01 schrieb Alec Leamas:
On 15/01/16 19:04, Russ Allbery wrote:
I feel like removing the sysvinit scripts entirely would be "reverting
existing support without a compelling reason." But I also think that
people who w
On 15/01/16 19:04, Russ Allbery wrote:
I feel like removing the sysvinit scripts entirely would be "reverting
existing support without a compelling reason." But I also think that
people who want to use sysvinit (or upstart, or any other init system)
will have to contribute some support there
1 - 100 of 111 matches
Mail list logo
