Dear list,
Still working with the opencpn package. Now trying to normalize the
Ubuntu PPA builds so they can are based on the same debian/ directory
and tools as the existing Debian opencpn package.
opencpn is currently in a beta phase targeting a 5.10.1 release. The
beta versions are like "
On 01/07/2024 20:48, Alec Leamas wrote:
Dear list,
Still working with the opencpn package. Now trying to normalize the
Ubuntu PPA builds so they can are based on the same debian/ directory
and tools as the existing Debian opencpn package.
opencpn is currently in a beta phase targeting a
On 01/07/2024 21:51, Andrey Rakhmatullin wrote:
Hi Andrey.
Thanks for input.
On Mon, Jul 01, 2024 at 09:46:11PM +0200, Alec Leamas wrote:
After some thought, I tend to think that adding an epoch is the right thing
here.
The Policy [1] says:
---
Epochs can help when the upstream version
On 02/07/2024 00:10, Scott Kitterman wrote:
Hi Scott,
Upstream can change the versioning however they want. They are upstream. If
they don't care to fix it, then I think we assume they are fine with it and
leave it as is.
But here the situation is that upstream do care and wants to fix it.
On 02/07/2024 00:31, Scott Kitterman wrote:
HI again
On July 1, 2024 10:18:07 PM UTC, Alec Leamas wrote:
But here the situation is that upstream do care and wants to fix it. But they
need our help (an epoch) to accomplish this to handle the legacy.
We could be helpful, or not. Why not
On 02/07/2024 00:54, Scott Kitterman wrote:
On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
If you switch hats for a moment: have you any advice for upstream in
this situation?
8763.5.10
Yes, I have had a similar idea using 1 instead of 8763 to make it
stand out less. In
Hi again
On 02/07/2024 01:13, Scott Kitterman wrote:
On Monday, July 1, 2024 7:07:16 PM EDT Alec Leamas wrote:
On 02/07/2024 00:54, Scott Kitterman wrote:
On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
If you switch hats for a moment: have you any advice for upstream in
this
On 02/07/2024 01:19, Alec Leamas wrote:
Let's drop this subthread, keeping eyes on the ball: what is a sane
version?
Looking at this from another point of view: is there any situation where
an epoch is appropriate?
--alec
Soren et. al.,
On 02/07/2024 01:31, Soren Stoutner wrote:
Alec,
If upstream wants to fix this problem, they could just make their next release
version 9000, with the one after that either being 9001 or 9000.1.
Or, possibly, they could encourage everyone to uninstall the PPA package
before ins
Soren,
On 02/07/2024 01:41, Soren Stoutner wrote:
Alec,
On Monday, July 1, 2024 4:25:59 PM MST Alec Leamas wrote:
On 02/07/2024 01:19, Alec Leamas wrote:
Let's drop this subthread, keeping eyes on the ball: what is a sane
version?
Looking at this from another point of view: is ther
HI again,
This becomes somewhat more complicated than it perhaps is.
On 02/07/2024 02:08, Soren Stoutner wrote:
Although I generally agree with your conclusions, using a PPA is the type of
end user task that involved them making modifications to the repositories on
their systems. I would assu
On 02/07/2024 02:31, Scott Kitterman wrote:
On July 2, 2024 12:26:49 AM UTC, Soren Stoutner wrote:
That adds some needed clarification. I agree that in that circumstance, adding
an epoch is the best way forward. It allows you to maintain the current
upstream program version number, while u
Hi Jens,
On 02/07/2024 06:38, Jens Reyer wrote:
You may avoid the epoch if upstream is willing to provide a separate
package for about 2 years. (I did something similar to get rid of an
epoch in Ubuntu's wine packages a few years ago, replacing them with our
Debian packages):
package 9000.5
On 02/07/2024 20:46, Gunnar Wolf wrote:
Alec Leamas dijo [Tue, Jul 02, 2024 at 01:59:26AM +0200]:
So, at least three possible paths:
1. Persuade users to uninstall PPA packages before installing official
packages and also generation 2 PPA packages with sane versions like 5.10.x
2. Use
Hi Milan,
On 02/07/2024 23:54, Milan Kupcevic wrote:
On 7/1/24 14:48, Alec Leamas wrote:
[...]
Hi Alec,
opencpn is currently in a beta phase targeting a 5.10.1 release. The
beta versions are like "5.9.2-beta2+dfsg-1ubuntu1~bpo2204.1". The
upstream policy is to use 5.9.2-be
On 03/07/2024 10:10, Philip Hands wrote:
Alec Leamas writes:
It seems better to take an "If we build it, they will come" approach.
New installs will likely get the Debian version without ever needing to
discover the PPA, and the rumour will spread (assuming the Debian
package work
Dear list,
The opencpn program can use an usb dongle to administrate commercial
chart licenses. Most opencpn users purchases licenses locked to a
specific computer and don't use this dongle. Using a dongle users can
use one license on several machines by just moving the dongle.
The dongle
Hi Marco,
thanks for taking time
On 04/07/2024 00:56, Marco d'Itri wrote:
On Jul 03, Alec Leamas wrote:
1. Is it possible to package such a solib in the non-free section?
Is it actually redistributable?
Yes
2. opencpn would have a weak Suggests: or Recommends: on this package.
Dear list,
Still trying to maintain opencpn. Now looking at an error in the armel
build [1]. The core is a bunch of messages like
/usr/include/c++/14/bits/atomic_futex.h:278:(.text+0x16dc): undefined reference
to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
/usr/bin
Hi Timo and Paul,
On 16/08/2024 18:10, Timo Röhling wrote:
Hi Alec,
* Alec Leamas [2024-08-16 17:46]:
/usr/include/c++/14/bits/atomic_futex.h:278:(.text+0x16dc): undefined
reference to
`std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
/usr/bin/ld:
/usr/include/c
On 17/08/2024 14:42, Wookey wrote:
On 2024-08-16 17:46 +0200, Alec Leamas wrote:
From another perspective: what is the right thing to do in a situation like
this? Trying to hunt down the problem, and thus causing all sorts of noise
like this message? This is what the policy says, but
Hi Stephen,
On 18/08/2024 09:04, Stephen Kitt wrote:
On Fri, 16 Aug 2024 17:46:45 +0200, Alec Leamas wrote:
Or just exclude that architecture i. e., list all archs but armel?
If you can’t fix the build, you don’t need to exclude the architecture — you
can ask for removal of the armel package
Hi;
On 18/08/2024 06:11, Wookey wrote:
On 2024-08-17 17:58 +0200, Alec Leamas wrote:
To make it more interesting, the simple -latomic fix doesn't seem to cut it
That's a pity, it sounds plausible. I'll try to take a look.
Thanks!
That said, unless you have oceans of time, p
Hi list,
On 18/08/2024 11:23, Andrey Rakhmatullin wrote:
On Sun, Aug 18, 2024 at 11:02:03AM +0200, Alec Leamas wrote:
Hi Stephen,
On 18/08/2024 09:04, Stephen Kitt wrote:
On Fri, 16 Aug 2024 17:46:45 +0200, Alec Leamas wrote:
Or just exclude that architecture i. e., list all archs but
On 18/08/2024 11:35, Adam D. Barratt wrote:
On Sun, 2024-08-18 at 14:23 +0500, Andrey Rakhmatullin wrote:
On Sun, Aug 18, 2024 at 11:02:03AM +0200, Alec Leamas wrote:
[...]--
If you can’t fix the build, you don’t need to exclude the
architecture — you
can ask for removal of the armel
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 fo
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 for
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 the
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,
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
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 to
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"
reveal
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.
A
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
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 che
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 tha
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
bec
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'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 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 the
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 is
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).
Fedo
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 migh
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 of
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.,
sigmavirus24-
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
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
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
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 somethi
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 of
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 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 nece
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 changin
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 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 h
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
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 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???
Pl
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 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 11/02/17 10:29, Bastien Roucaries wrote:
Le 10 février 2017 16:13:15 GMT+01:00, Alec Leamas 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).
- The lirc user is added to the
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 all
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, bu
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?
_to_help_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'
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
>
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 pro
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 arch
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
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
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 ocpn_plu
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 pa
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 ano
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 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 pri
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
Dear list,
I am in the process on creating a new lirc packaging. The core reason is
that current debian version is stalled at 0.9.0 as of 2011 whereas the
upstream version is 0.9.3, with 0.9.4 under way. My plan is to try to
package 0.9.4.
Besides the more practical issues here is a big configura
On 07/11/15 10:05, Dominique Dumont wrote:
> On Friday 06 November 2015 18:48:29 Alec Leamas wrote:
>> So, an upgrade will not support hardware.conf. Which basically breaks
>> each and every installation. While we could (i. e., should) provide docs
>> and perhaps some toolin
On 08/11/15 19:28, Dominique Dumont wrote:
> On Sunday 08 November 2015 15:19:30 Alec Leamas wrote:
>> Some tooling to build the new configuration from the old will indeed be
>> required. This is actually some work - it includes a complete lircd
>> command line parser with
On 09/11/15 17:44, Alec Leamas wrote:
> On 08/11/15 19:28, Dominique Dumont wrote:
>> On Sunday 08 November 2015 15:19:30 Alec Leamas wrote:
> So, this is a change, yes. But in the long run, wouldn't we be better
> off by sticking to upstream's way of doing it instea
On 10/11/15 13:26, Andrew Shadura wrote:
> I think migrating from old config to a new config in a postinst is okay
> as long as you keep the old config and complain to the user that a
> manual verification may be needed.
>
> As least ifupdown did that a couple of times, and nobody complained :)
On 10/11/15 14:49, Andrew Shadura wrote:
> On 10/11/15 13:39, Alec Leamas wrote:
>> On 10/11/15 13:26, Andrew Shadura wrote:
> I think you can try to do it systemd way: keep the default configuration
> in /usr/lib, and leave /etc for local user configuration which overrides
>
On 10/11/15 14:49, Andrew Shadura wrote:
> On 10/11/15 13:39, Alec Leamas wrote:
>> On 10/11/15 13:26, Andrew Shadura wrote:
>>
>>>> I think migrating from old config to a new config in a postinst is okay
>>>> as long as you keep the old config and
On 11/11/15 10:37, Marc Haber wrote:
> On Tue, 10 Nov 2015 18:24:52 -0800, Josh Triplett
> wrote:
>> Vincent Danjean wrote:
> I violently disagree. We have always done it the other way, and had
> the advantage that our conffile handling (which used to be and IMO
> still is far superior to everyth
On 11/11/15 13:28, Marc Haber wrote:
On Wed, 11 Nov 2015 11:04:01 +0100, Alec Leamas
wrote:
On 11/11/15 10:37, Marc Haber wrote:
On Tue, 10 Nov 2015 18:24:52 -0800, Josh Triplett
wrote:
Vincent Danjean wrote:
I violently disagree. We have always done it the other way, and had
the
On 11/11/15 15:17, Vincent Danjean wrote:
Le 11/11/2015 10:37, Alec Leamas a écrit :
However, it touches one possible route: to store the original vendor
files separately and create the actually used config files in postinst.
ucf has been written for this. Do not reinvent the wheel, use ucf
On 04/01/16 11:40, Andreas Tille wrote:
Hi,
I'm trying to package libncl[1] but I failed to fight the following
lintian error:
E: ncl-tools: binary-or-shlib-defines-rpath usr/bin/NCLconverter
/usr/lib/x86_64-linux-gnu/ncl
I deactivated my quilt patches and the override_dh_auto_configure sinc
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
ar
On 15/01/16 14:13, Dmitrii Kashin wrote:
Alec Leamas 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 distributions. And if it's no
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 in
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 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
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 what
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 differe
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 \
-
95 matches
Mail list logo
