Re: Q: Create non-free package

[Alec Leamas]

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. Would
it mean it has to move to contrib?

Suggests, no. Recommends, yes. See policy 2.2.1.


3. If it is possible to package in non-free, how is this done? I don't find
much on this topic googling around

You set "Section: non-free/misc" in debian/control. See policy 2.4.
Since there is no source then you will also need to set an appropriate
value for the Architecture field.



Seems to boil down  to that this is possible. Thanks!

--alec

Q: Create non-free package

[Alec Leamas]

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 interface is a small, closed-source solib. I guess it could 
be described as a sort of user-space driver. Since it is closed source 
it cannot go to the main archive. From here, I have some questions:


1. Is it possible to package such a solib in the non-free section?

2. opencpn would have a weak Suggests: or Recommends: on this package. 
Would it mean it has to move to contrib?


3. If it is possible to package in non-free, how is this done? I don't 
find much on this topic googling around


Cheers!
--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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 works at least as well) that there's no need to bother with the
PPA, and then people will do the work to remove the PPA from their
configs, at a time of their choosing.


The truth is rather that the rumour will be the current: "Don't use the 
heavily outdated official package, at least not on Ubuntu"



Please see  https://lists.debian.org/debian-devel/2024/07/msg00031.html

--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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-beta2, 5.9.3-beta3 so this ordering 
is, although a bit strange, still ok.


However, a quite large user base have PPA packages installed. These 
have versions like 8767+b2cbf5a3f~ubuntu24.04.1. The prefix is a build 
number, so they are ordered. but all these versions are higher than 
anything like 5.9.x.




[...]


The upstream shall consider adopting 5 digit release version numbering 
without dots/periods. E.g. 50903 would mean version 5, major 09, minor 
03. Thus you would go with package version numbering 50903-1 or 
50903+dfsg0-1 as the case might be.





The upstream "shall" not do anything, they are open for discussions but 
certainly not for dictates.


If you are able to sell this idea to upstream it would certainly work. I 
would not try it, it would generate a lot of friction to no use. And at 
least I would fail to convince upstream. The user community is used to a 
certain version scheme and if  using the Debian package requires such an 
odd version the Debian package will probably not be used.


The proposed version also does not even resemble the ubiquitous  semver 
specifications which actually are more or less followed now. Seems like 
a wrong move just to avoid the epoch.


Again, Russ Allbery's post [1] describes these kind of considerations. 
IMHO they apply also to this idea.


Cheers!
--alec

[1] https://lists.debian.org/debian-devel/2024/07/msg00029.html

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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 versions like 9000.5.10, 9000.5.12. etc.

3. Use an epoch.


You can also consider a third possible path: Pick a different package
name.

I am unfamiliar with opencpn to be able to suggest an alternative. But
given opencpn has never been part of Debian, you could just name your
package "opencpn-deb". Just to be sure users don't get surprised by
having two different versions of the same package, it can "Conflict:
opencpn". Then, you get a blank slate from which you can work your
versioning as you deem adequate.

It does, yes, introduce some confusion, but I think is the least evil
option.


opencpn is part of Debian since many years. However, the major 
distribution is through an Ubuntu PPA, the official Debian package is 
not that visible and of course outdated in Ubuntu.


opencpn users are counted in at least thousands. We are trying to 
convince the developer community that it's a good idea to use a package 
created as an official Debian package  rather than an auto-generated 
cmake package distributed using the Ubuntu PPA.


If the condition for this is to change the package name, the idea to use 
the official package will fail;  the package name has some substantial 
mindshare. In other words, this would probably be a even harder sell to 
upstream than the 9000.5.10 ideas floated earlier in this thread.


Russ Allbery has phrased the overall considerations applicable also to 
this idea earlier in this thread [1].


Cheers!
--alec

[1] https://lists.debian.org/debian-devel/2024/07/msg00029.html

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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.10
Depends: package-transition-to-new-versioning

package-transition-to-new-versioning 5.9.2-1


In 2 years:
package-transition-to-new-versioning 5.9.2-2
Depends: package 5.9.2-2

You'll also need some breaks/replaces in Debian's packages.

I might dig out the details later if your interested.


Thanks for interesting input, I do appreciate it even if I don't think 
it works in this case for two reasons.


The first is that upstream should accept to use a package version like 
9000.5.x. Even if it's for a limited time it's a very hard sell. Russ 
Allberry phrased this well earlier in this thread.


The second is that this is navigation software used in boats and ships 
which often are off line. In this context users tends to cling to their 
working installations. That is, it will take a long time before the 
existing 8764.x versions are gone, much longer than two years.


OTOH, I understand the idea and can see it being useful in other cases.

Cheers!
--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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 unifying the Debian, Ubuntu, and PPA
version numbers in such a way that packages from those repositories can be
used interchangeably.


I would suggest that you work with upstream on how they will version things in 
the future, so you aren't bumping the epoch every year.


Agreed.

I have many hats here, one of them being the upstream one. There is a 
clear vision how this should work in the future; this vision does not 
include any further epoch bumps.


--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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 assume that anyone who has done so, and who is already
running Linux instead of Windows, is fully capable of handling a “downgrade”
to an official package.  Asking users to remove the PPA they manually added and
install an official package doesn’t really seem like that hard of an ask to me.



But this is not about replacing the PPA with the official packages.

For various reasons opencpn tends be released just after a Debian 
release in summertime, and the Debian version thus quite outdated when 
it hits the Ubuntu repos.


For Debian users we backport opencpn which works well. However, the 
Ubuntu backport process is, well, interesting (been there, done that).


The PPA represents a much better way to publish backports to current 
Ubuntu branches. But for this to work we need to reset the versioning so 
it works together with the official stream from Debian.


Anyway, seems we have a emerging conclusion that an epoch is a correct 
solution here.


--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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 there any situation where
an epoch is appropriate?

--alec


Epocs are usually used when upstream changes their versioning system in a way
that causes problem for our packaging.  For example, if they previous have
used dates for their release versions and switch to ordinals, Debian needs a
way of indicating that version 1.0 is newer than 2024.01.05.


So have I also understood it.

And this is more or less the situation. For all practical purposes the 
PPA is the current upstream packages, it's not some random packaging of 
opencpn. I have some control over both the PPA and the debian/ubuntu 
packages.


And what we want to do is to switch the upstream versioning in a way 
which means the "next" version is lower than current version. The end 
game is that the PPA is proper pre-releases of the official packages, 
built from the same sources and debian/ directories.


On other words, a rather good example on when an epoch makes sense.

--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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 installing an official one.  For example, release a new package to their
PPA that displays a message encouraging everyone to uninstall the PPA package,
remove the PPA from their list of repositories, and *then* install the official
one.

As a general rule, I wouldn’t expect a user to keep a PPA package installed
when switching to an official package.  There is generally no guarantee that
upgrading from a PPA package to an official one will work without errors.

Or, once the official package had entered the system, they could instruct users
to remove the PPA from their list of repositories and then perform a
downgrade.

All of that being said, Debian could use an epoch to fix the problem.  Having
an epoch on a package isn’t the worst thing that has ever happened.


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 versions like 9000.5.10, 9000.5.12. etc.

3. Use an epoch.

Of these I would say that 1. is a **very** hard sell upstream. Users are 
used to just update and will try, fail and cause friction.


2. and 3. both adds something which must be kept forever. Given this 
choice I tend to think that the epoch is the lesser evil, mostly because 
the package version could match the "real" version.


That is, the idea that next opencpn release officially would be 
9000.5.10 just won't fly. 2. would be about using package versions with 
a number prefix like 9000. which is not really visible to users.  And 
that means an impedance problem between the upstream version and the 
packaged one. A problem the epoch does not have.


--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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 situation?


8763.5.10


Yes, I have had a similar idea using 1 instead of 8763 to make it
stand out less. In my eyes, this is worse and will lead to that the
package versions does not match the "public" version like 5.10.2.

But if the list agrees that this is the correct solution so be it. To be
honest, it might be a hard sell upstream.


Next build is:

8763.5.10~8764


Why?

--alec


Because the '~' means less than.  It's a way to add the build number to the
interim versions in the future without causing the same problem again.  I
guess it should have been 8763.5.11~8764, if 5.11 is the next 'real' version.


There is absolutely no need of build numbers in the version, it's just a 
sad legacy.


Let's drop this subthread, keeping eyes on the ball: what is a sane version?

--a

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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 my eyes, this is worse and will lead to that the 
package versions does not match the "public" version like 5.10.2.


But if the list agrees that this is the correct solution so be it. To be 
honest, it might be a hard sell upstream.




Next build is:

8763.5.10~8764


Why?

--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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 give a hand?



No.  That's us fixing it.  They can bump the version to whatever they want to 
address the issue.  Epochs are forever, so should be a last resort.



Yes, epochs are forever and should not be taken lightly, agreed.

Expanding on the situation. The current opencpn version is 5.9.x, soon 
to be 5.10 in a tick-tock cycle.


However, the opencpn packages have versions like 8763.x, automatically 
generated from a build number. This is not communicated to users, they 
just install and update.


Obviously, upstream should start building packages with versions like 
5.9.x..., 5.10.x... etc. But any such version is lower than the current 
build number.


If you switch hats for a moment: have you any advice for upstream in 
this situation?


--alec

Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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. But 
they need our help (an epoch) to accomplish this to handle the legacy.


We could be helpful, or not. Why not give a hand?

--a

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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 numbering scheme changes, but they
must be used with care. You should not change the epoch, even in
experimental, without getting consensus on debian-devel first.
---

With all this said: Is this a case where using a epoch is justified? If not,
why?


Adding epochs to work around 3rd-party repo version problems sounds quite wrong.
We don't even add epochs that Ubuntu itself adds.



But this is not about third parties, it's about upstream which publishes 
PPA packages. So far these are by far the most used Linux packages.


I also hesitate to add an epoch, after all they are basically considered 
evil. But if we should not use them when upstream has a broken 
versioning we are about to replace, when should we use it?


I have good relations with upstream, and they are willing to abandon the 
current broken versioning in favor of something sane. But the legacy is 
there, and we need to handle it.


Have considered tricks like adding a 1. prefix to the debian/ubuntu 
versions. But to me, this looks even worse.


Thoughts?

--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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 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-beta2, 5.9.3-beta3 so this ordering is, 
although a bit strange, still ok.


However, a quite large user base have PPA packages installed. These have 
versions like 8767+b2cbf5a3f~ubuntu24.04.1. The prefix is a build 
number, so they are ordered. but all these versions are higher than 
anything like 5.9.x.




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 numbering scheme changes, but 
they must be used with care. You should not change the epoch, even in 
experimental, without getting consensus on debian-devel first.

---

With all this said: Is this a case where using a epoch is justified? If 
not, why?


--alec

Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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 "5.9.2-beta2+dfsg-1ubuntu1~bpo2204.1". The 
upstream policy is to use 5.9.2-beta2, 5.9.3-beta3 so this ordering is, 
although a bit strange, still ok.


However, a quite large user base have PPA packages installed. These have 
versions like 8767+b2cbf5a3f~ubuntu24.04.1. The prefix is a build 
number, so they are ordered. but all these versions are higher than 
anything like 5.9.x.


I understand that one way to handle this is to just say that sloppy PPA 
version numbers is not a Debian problem. That said, are there other 
ideas out there how to handle this?


Cheers!

--alec

Re: wxWidgets update & opencpn.

[Alec Leamas]

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 a dependency. The problem with
opencpn is that it has a plugin universe, and updating the current 
5.6.2

version to wxWidgets 3.2 would break the plugin ABI.


Hi Alec,

Your plan to wait until 5.8 comes out is probably fine.  However, just 
curious - if you switched opencpn to use wx 3.2 now, couldn't you just 
rebuild/binNMU the plugins?  Or are you trying to avoid that extra effort?


Plugins are not packaged, opencpn loads external plugins. And yes, there 
is a warning dialog for loading unpackaged sw...


Expanding on this: plugin checks the os version, basically deems 
themselves as compatible if built for Debian 10 or 11. There are 
provisions to build separate ABI:s for the same version (here 11), but 
it's complicated and we want to avoid it.


That is,  Debian 11/wxW 3.0 and Debian 12/wxW 3.2 is the two natural 
combinations we want to use. This makes the plugin compatibility issue 
so much simpler.


Cheers!
--alec

Re: wxWidgets update & opencpn.

[Alec Leamas]

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 current 5.6.2
version to wxWidgets 3.2 would break the plugin ABI.


Is this breakage due to wxWidgets or due to other upstream changes?
If the latter, *it might be* possible to backport the wxWidgets patches,
however whether that is feasible I don't know…


The breakage is about wxWidgets, backporting wxWidgets patches is 
certainly not possible. End even it it was, it just not worth it for a 
window for about a month.




Don't see that as a threat. Sure it is annoying but testing removal
is temporary and as you package will be still in backports, people
should be able to install from there, if they are on stable…
If they are on testing, well, that is the peril of testing.



Ah... Feared being forced to pass the NEW queue if removed from testing. 
Now less nervous...



More generally, any response to a release critical bug will restart
the removal timer. So if you reply to the bugs below, and document
the plan, this will reset the timer, so you can delay the automatic
removal a bit. However, that will not stop the release team for
manually removal; contrary, they might be unhappy if people using
this as tactic to delay autoremovals, as this creates work for them.

Said that, a reply to the bug laying out the plan should be done anyways,
because this is useful information for many… (If there is an upstream
discussion, set the Forwarded: BTS metainfo to link to that discussion)



I have already replied in the opencpn bug. Will do the same in the wxsvg 
one, handle whatever replies turns up there and hope for the best.


Thanks for clarifying!
--alec

wxWidgets update & opencpn.

[Alec Leamas]

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 that it has a plugin universe, and updating the current 5.6.2 
version to wxWidgets 3.2 would break the plugin ABI.


The upstream plan to handle the ABI break is to do it when releasing 
next version 5.8.0 which is going into beta in November and will be 
released before Christmas. My thinking has been that if opencpn 5.8.0 is 
uploaded before Christmas the update process should be ok, since the 
wxWidgets 3.2 version will be uploaded before the freeze.


Opencpn (current master, upcoming 5.8.0) builds fine using wxWidgets 3.2.

However, I get nag messages that opencpn will be removed from testing at 
November 8 unless I update it to using 3.2. Obviously, this makes me 
nervous. Questions:


1) Is my overall plan ok?
2) If so, how handle the threat of being removed from testing?

Cheers!
--alec

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019769
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019765

Re: Python installation paths

[Alec Leamas]

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-packages. This scheme has basically worked
fine.

However, here is an Ubuntu bug [1] where a user runs into problems because
this installation path is not in sys.path by default.

I have been trying to look in the python policy docs, but cannot find the
exact way to install code like this, in the policy [2]
parlance an "extension module".

Not sure where is this documented but you can easily check on your system.
It should be /usr/lib/python3/dist-packages/*.cpython-3*-x86_64-linux-gnu.so



Hm...this is not what I have. Did I get get the term "Extension module" 
 wrong?



That aside, what I have is some python3 scripts and a compiled .so 
library invoked form the python code. The whole thing designed to be in 
the same directory. And the question is how this should be installed...


Cheers!
--aled

Python installation paths

[Alec Leamas]

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 
because this installation path is not in sys.path by default.


I have been trying to look in the python policy docs, but cannot find 
the exact way to install code like this, in the policy [2]

parlance an "extension module".

Any thoughts out there?

Cheers!
--alec






[1] https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/1843988
[2] https://www.debian.org/doc/packaging-manuals/python-policy/

Re: Legal advice regarding the NEW queue

[Alec Leamas]

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 that any package entering
> unstable without having undergone NEW review (which, in the revised
> model, might be every new package) should automatically have a bug 
filed
> against it requesting suitable review, and that bug should be 
treated as

> a blocker for entering testing?

Not really, since anyone in the world could close said bug (including 
the

uploader).

This applies to any RC bug.


Yes, but in this case it means that we wouldn't have that minimal 
standard of at least one person other than the uploader having ever 
reviewed the package--which I think is a fairly low bar that we should 
meet. (It would be even better if we could add reviews for changes, but 
at any rate I don't think we should go backward here.)



This is basically a question of social contracts and tooling. It can 
IMHO certainly be done.


But isn't this discussion on details moot until we clear out the 
fundamentals such as the legal risk/cost analysis of dropping the NEW 
queue in its current form i. e., the topic for this thread?


And not least, some input from the ftp-masters team -- this discussion 
is about a huge change in a process they currently manage.


Cheers,

--alec

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Alec Leamas]

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 check
packages, they can do it once they are in unstable with regular bugs.


Without the NEW queue, there would be no point at which packaging receives
any sort of review.  I'd prefer Debian to deliver at least some level of
quality.


Perhaps wrong to focus on the queue as such. The focus should be the 
need for a manual review -- this is IMHO the important point.


The current ftpmaster review model is somehow modeled after a 
"supervisor" idea. Fedora uses peer reviews. The advantage is the 
incentive to make reviews:  I can review your package if you review 
mine. One could of course imagine that this would lead to sloppy 
reviews. However, this is not my experience.


It also means a more transparent process.



Otherwise, we'd fall to the level of NPM.  And there's ample examples what
that would mean.


Indeed.


Current checks are partly done by Lintian and I suppose people could
watch new Lintian warnings and detect bad packages quickly.


Lintian is just a dumb machine that can ease human reviews but not replace
them.



Yes. It's interesting to compare to Fedora's tooling fedora-review which 
has another focus: It outputs list of things to check when reviewing a 
package. Some of those are automatically checked, others are just a 
checkbox which should be manually checked. Lintian is a good tool, but 
not IMHO a review support.




This could be done when src is not NEW as a test.


I've managed to trample upon someone else's package just yesterday -- and it
escaped automated checks because a binary of that name already existed in
the archive, just not on any arch which I test.



Yes, one of those manual checks...

On 26/01/2022 11:29, Adam Borowski wrote:

> For practical reasons we have to obey the laws, no matter how oppressive
> they are.  But I don't see why we should do more than eg. Fedora which
> has corporate backing with an actual legal team.

Also note that this legal team *not* is used to review all packages. 
Instead, they are a resource which are contacted by packagers when we 
need advice. The typical situation is in a (peer) review where things 
cannot be settled. The legal team also files bugs as required, and 
maintain the packaging manual's copyright part.


Of course, this creates a very different social relation between the 
legal team and the rest.


Just my 5 öre
--alec

Re: Lost package?

[Alec Leamas]

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 seems to be processed, it is (was) empty. But I don't
find any trace of my backported opencpn package anywhere. Accepted?
Rejected? In limbo? I have no idea about what to expect or how to check
status.

Any clue, out there?


I've got the ACCEPTED message,
Message-Id: 
Date: Thu, 23 Dec 2021 17:39:12 +0100
Subject: opencpn_5.6.0+dfsg1-1~bpo11+1_amd64.changes ACCEPTED into 
bullseye-backports, bullseye-backports



Thanks, that sort things out. In hindsight, it is of course how it works.

And now I can see it in buildd. The Debian processes teaches us the 
virtue of patience, though a I'm a slow learner. Sigh.


Cheers!
--alec

Lost package?

[Alec Leamas]

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. 
Accepted? Rejected? In limbo? I have no idea about what to expect or how 
to check status.


Any clue, out there?

Cheers!
--alec

Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]

[Alec Leamas]

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" 
reveals multiple discussions. One IMHO important thread starts at 
https://lists.debian.org/debian-devel/2020/02/msg00118.html.


Another thread is about the NEW queue being more or less cleared about a 
year ago: https://lists.debian.org/debian-devel/2020/11/msg00017.html



Cheers!
--a

Re: Bundling

[Alec Leamas]

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 Debian at
   all

* if wxWidgets 3.2 is in Debian when you are ready to upload to Debian,
   then have your package link against that

* if not, then you approach the wxWidgets maintainer about creating a
   package for it, which would stay in experimental until no longer
   experimental (i.e. when either ABI has stabilized or packaging
   contains reasonable tracking of unstable ABI e.g. using symbols
   tracking).

* if wxWidgets maintainer find it unreasonable to package wxWidgets 3.2
   before its ABI has stabilized, you might consider embedding a snapshot
   in your own package - released only to Debian experimental.

* of there is still no wxWidgets 3.2 package in Debian when Debian gets
   close to freeze **AND YOU ARE FULLY WILLING TO MAINTAIN YOUR FORK OF
   WXWIDGETS YOURSELF FOR SEVERAL YEARS**, then release your experimental
   package to Debian unstable.

* otherwise wait until wxWidgets maintainer consider it reasonable to
   provide the needed version of the wxWidgets library.



OK, see below.



Just for the record: the issue about packaging wxWidgets 3.1 has already 
been discussed with the maintainer:


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919903


--alec

Re: Bundling

[Alec Leamas]

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 dependencies should be fine. This is C++, so library symbols
is bit convoluted.


See https://wiki.debian.org/PkgKde/DhSymbolsFile


After some tries in this area I have leaned to Russ Allberry's post
https://www.eyrie.org/~eagle/journal/2012-02/001.html. Is this
outdated?


Russ Allberry tried to provide more intimately track individual symbols,
but for the packages he did the experiment he considered it too much
work for too little gain, so he reverted to tracking stable ABIs.

Others have come to different conclusions for different packages -
myself included.  I bring it up here - despite Russ finding it
unsuitable for his package maintenance work - to help you explore
options _beyond_ the conventional wisdom of "only rely on stable ABIs.


OK, thanks.



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 Debian at
   all

* if wxWidgets 3.2 is in Debian when you are ready to upload to Debian,
   then have your package link against that

* if not, then you approach the wxWidgets maintainer about creating a
   package for it, which would stay in experimental until no longer
   experimental (i.e. when either ABI has stabilized or packaging
   contains reasonable tracking of unstable ABI e.g. using symbols
   tracking).

* if wxWidgets maintainer find it unreasonable to package wxWidgets 3.2
   before its ABI has stabilized, you might consider embedding a snapshot
   in your own package - released only to Debian experimental.

* of there is still no wxWidgets 3.2 package in Debian when Debian gets
   close to freeze **AND YOU ARE FULLY WILLING TO MAINTAIN YOUR FORK OF
   WXWIDGETS YOURSELF FOR SEVERAL YEARS**, then release your experimental
   package to Debian unstable.

* otherwise wait until wxWidgets maintainer consider it reasonable to
   provide the needed version of the wxWidgets library.



OK, see below.


  >> How do you and OpenCPN upstream expect to handle bugs for that
  >> specific embedded version of wxWidgets?

[upstream hat on] As for maintenance, using 3.1.5 places us in a loop
with wxWidgets upstream where possible patches introduced will be
forwarded, reviewed and eventually released with 3.2. This is also how
bugs will be handled.


You are describing a healthy relationship between a code fork and its
upstream origin.  That's great to hear - it means your fork will likely
be in good shape for as long as it needs to exist.

My concern is that there is a real risk that you will need to maintain
it for longer than you intended if you release your code to Debian
unstable and let it migrate to Debian testing, and if that happens that
you cannot maintain a _stable_ fork - i.e. that you 2 years from now
will need to rebase your fork on a newer upstream snapshot to fix some
bug that is too difficult for you to rebase and that upstream has
progressed too far away from to care about solving it twice - both for
their own codebase and again for your (to them) ancient codebase.


Agreed, we should not do that, se below.


If what you call "provisionary" is something done outside of Debian
or only in Debian experimental, then is seems you agree.  But I am
not sure - in particular your "and uses that in next cycle" sounds
like you will not treat it as only experimental but rely on that
newer release, no matter if embedded code is maintainable or not.


I totally agree with you that embedding is the last option and should
be avoided if possible. After all, I'm raising this issue in time...

I also share your view that if bundling, it must be a temporary
measure. It must definitely not linger in upcoming releases.


Sounds like we agree, then - sorry if I mistook you as less careful in
my previous remarks...



No offense taken ;)



Is there a route where we keep things in experimental (bundled or not)
and let it stay there until wxWidgets 3.2 is out? And we then can make
a sid package without any other dependencies or bundled wxWidgets
code?


I think the route I outline above covers what you describe here - do you
agree?



Yes, besides that I don't really consider releasing the experimental 
package an option.  At least as it looks now.


Thanks for all input, I think we are reaching some consensus here. There 
is a plan...


Cheers!
--alec

Re: Bundling

[Alec Leamas]

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.


See https://wiki.debian.org/PkgKde/DhSymbolsFile


After some tries in this area I have leaned to Russ Allberry's post
https://www.eyrie.org/~eagle/journal/2012-02/001.html. Is this outdated?



What do you think about a plan like this:

- We make a provisionary, internal packaging of 3.1.5 and uses that in
next cycle.

- Around February-March -22 we assess the situation again. If we
believe that 3.2 will ready and packaged before our own release, we
just wait for that to happen.

- If not, we approach the wxWidgets maintainer about getting our
provisionary, temporary package in shape and released, probably in
experimental.

- If the maintainer refuses to make such a release we have to bundle
the library in our own package.


I am concerned that you a) seemingly prefer to postpone involving
wxWidget package maintainers, and b) did not anwer my question about
maintenance:



As for postponing, it's just about that if 3.2 arrives in time there is 
nothing to discuss, and the issue is void. But OTOH, we could always 
discuss things anyway, agreed.


>> How do you and OpenCPN upstream expect to handle bugs for that
>> specific embedded version of wxWidgets?

[upstream hat on] As for maintenance, using 3.1.5 places us in a loop 
with wxWidgets upstream where possible patches introduced will be 
forwarded, reviewed and eventually released with 3.2. This is also how 
bugs will be handled.


(I have too many hats here...)


I think that if you do not want to properly maintain the wxWidget code
you need, then the best for Debian is that you postpone introducing this
newer OpenCPN release until the wxWidget package maintainers consider it
reasonable to introduce the code needed for it.


As long as we don't miss Bookworm it's not that bad. It will still 
affect downstreams like Ubuntu and Raspbian, though.  However, question 
is how much effort we should put in this, since we still don't know if 
3.2 will arrive in time or not.



If what you call "provisionary" is something done outside of Debian or
only in Debian experimental, then is seems you agree.  But I am not sure
- in particular your "and uses that in next cycle" sounds like you will
not treat it as only experimental but rely on that newer release, no
matter if embedded code is maintainable or not.


I totally agree with you that embedding is the last option and should be 
avoided if possible. After all, I'm raising this issue in time...


I also share your view that if bundling, it must be a temporary measure. 
It must definitely not linger in upcoming releases.


Is there  a route where we keep things in experimental (bundled or not) 
and let it stay there until wxWidgets 3.2 is out? And we then can make a 
sid package without any other dependencies or bundled wxWidgets code?


To me, this looks like a road forward (?)

Cheers!
--alec

Re: Bundling

[Alec Leamas]

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 wxWidgets
3.1.5 sources in next OpenCPN release in such a situation?



How do you and OpenCPN upstream expect to handle bugs for that
specific embedded version of wxWidgets?

Sounds more sensible to me to (coordinate with wxwidgets maintainers
to have) wxWidgets 3.1.x packaged as a separate package, tracked
with its proper upstream source.  Then when we get near freeze it
can be assessed how many of the wxWidgets branches we want to
include with the upcoming stable Debian release - and include in
that assessment how many packages reverse-depend on each.



My thinking so far has been that a wxWidgets 3.1.5 package just isn't
possible since there is no ABI stability guarantee.  Am I wrong?


Lack of stable ABI means that each library change may require
recompilation of reverse dependencies.

This can be handled in packaging either by declaring tight dependencies
(see e.g. `man dh_shlibdeps`), or by tracking library symbols and use
those to resolve dependencies (see e.g.
https://wiki.debian.org/UsingSymbolsFiles)



Tight dependencies should be fine. This is C++, so library symbols is 
bit convoluted.


What do you think about a plan like this:

- We make a provisionary, internal packaging of 3.1.5 and uses that in 
next cycle.


- Around February-March -22 we assess the situation again. If we believe 
that 3.2 will ready and packaged before our own release, we just wait 
for that to happen.


- If not, we approach the wxWidgets maintainer about getting our 
provisionary, temporary package in shape and released, probably in 
experimental.


- If the maintainer refuses to make such a release we have to bundle the 
library in our own package.



Thoughts?
--alec

Re: Bundling

[Alec Leamas]

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 that specific
embedded version of wxWidgets?

Sounds more sensible to me to (coordinate with wxwidgets maintainers to
have) wxWidgets 3.1.x packaged as a separate package, tracked with its
proper upstream source.  Then when we get near freeze it can be assessed
how many of the wxWidgets branches we want to include with the upcoming
stable Debian release - and include in that assessment how many packages
reverse-depend on each.



My thinking so far has been that a wxWidgets 3.1.5 package just isn't 
possible since there is no ABI stability guarantee.  Am I wrong?


--alec

Bundling

[Alec Leamas]

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 for 
odd-numbered releases like 3.1 and there is thus no Debian packages 
available.


Now, normally this should not be a problem since the upstream 3.2 
release is due Real Soon, and OpenCPN has rather long cycles release 
cycles, roughly yearly. However, upstream wxWidgets seems stalled, and 
we are probably facing a real risk that 3.2 is still not available for 
next OpenCPN release in about a year.


So, the question: would it be acceptable to bundle the wxWidgets 3.1.5 
sources in next OpenCPN release in such a situation?


Thoughts?

--alec

Accepted opencpn 5.0.0+dfsg-1 (source) into unstable

[Alec Leamas]

-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-1) unstable; urgency=medium
 .
   [ Alec Leamas ]
   * New upstream release
   * Move to gtk3
 (closes: #946018)
   * Drop all patches besides two after being upstreamed
   * Drop some lintian overrides after upstream fixes.
   * Add a patch for broken include paths.
   * Add a patch for broken FIND_WXWIDGETS in CMakeLists
   * Disable assertion messages using the standard NDEBUG flag.
   * Move appstream data to new location, relicense
 and clean up rules.
   * Bump Standards-Version to 4.4.1, no changes.
   * Move to compat level 12, use new compat scheme
   * Drop dfsg.N suffix to reflect local habits.
   * Move around some docs.
 .
   [ Bas Couwenberg ]
   * Restructure control file with cme.
   * Change libgtk2.0-dev build dependency to libgtk-3-dev.
   * Update watch file to handle common issues.
   * Rename install file to opencpn.install.
   * Drop obsolete include-binaries file.
   * Fix typo in lintian override comment.
   * Drop Name field from upstream metadata.
Checksums-Sha1:
 13d4f0cbe6b286245172dd9d60546139af457c3f 2344 opencpn_5.0.0+dfsg-1.dsc
 e8c52c1d8cc0720d10022de00a3a558a1c258b53 18018964 
opencpn_5.0.0+dfsg.orig.tar.xz
 614d4c421e9dea33a1491520c3e83d26af6fec0a 13820 
opencpn_5.0.0+dfsg-1.debian.tar.xz
 ee1dbf9300d0e3106b432a5973d8e7d9d9a95513 16742 
opencpn_5.0.0+dfsg-1_amd64.buildinfo
Checksums-Sha256:
 7196ebeaad080e6594e8fa0d70df65721db62ec94fb194510283b13f848ea985 2344 
opencpn_5.0.0+dfsg-1.dsc
 4842c8d82c4448a4eec0137f23ac4b89dba35466cb18dfb805febc381635 18018964 
opencpn_5.0.0+dfsg.orig.tar.xz
 2dd9508858ba41583e0b9487d541bb68cde0d64ad24aeccb34ed2f5b2ad4e340 13820 
opencpn_5.0.0+dfsg-1.debian.tar.xz
 ae471845474ccaf394846ad2cba3175ee9f9edd74f08b24da042cad4f9d2e0a2 16742 
opencpn_5.0.0+dfsg-1_amd64.buildinfo
Files:
 a95c061a48996d74776be6fb6fa999de 2344 misc optional opencpn_5.0.0+dfsg-1.dsc
 14104cd121776ee86c5d5d25bb1c9326 18018964 misc optional 
opencpn_5.0.0+dfsg.orig.tar.xz
 403ed98794ed4c98e072f79624b711cb 13820 misc optional 
opencpn_5.0.0+dfsg-1.debian.tar.xz
 3c94ac014ca0fbd74c4be9a2db5f1eee 16742 misc optional 
opencpn_5.0.0+dfsg-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJCBAEBCAAsFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAl4YY0YOHHRpbGxlYUBy
a2kuZGUACgkQV4oElNHGRtGfgw/8C9ZGwPseV/DpIyY6mLDhl1fRl+OIMopEWfCV
MqwbmjDY+Ya7h4iNZfETGsc+VQloB+eanPz1pH+7sqEbWO9TT1tTUAejlro1Zov+
roOQIn0+3CICB7fwifGPRMWNUT1QSMhGQtsCAdUbMCC+9QjN0akKTHdc9t1zNoqj
s0qvWTGYjdcwCzagd5j+f34ZxhJ0PZ/uT8Kxd8CtKEsUBnEgkAjL5ipg8lM4zo7X
UTvEc+gdCYY2JepylojebY2LM5sHxLJlH3IVJ19PC7/HUb0KDXfgXuSonTGqfT/m
ROyUPb9ug8vjoToMTPEYvFM76Jp98Wj7H6gMV24vYm4CvlQteqiCB+kT0H6+VMoY
PkdniOpfulLaihqeJ/NBg/F+esPL4NwAqhkepi6axw9yzkssLeWYck7Db1FQzDr8
dlUDYYSPHmhQGUwiZ7WYrDMbBmMMPYL0Nm4rGZWXC/4Waiu3wll5MbLx3wSidqyG
hjod2emC1LKzLC7o1jDx/yHo+KDL57qoFOUC2/wK2duCLv3FgFHe88qgvpg6agGZ
bW+XhzzlmK2Q+hl1+mY+S7TmHl8wPrJtCbWWfFDXVR3tPt6ZVjx1LBhbxhukZseN
G0CAt+FIChO2JCdgHELg5sDQbkkZkCm71RFR80sLtIwr2mJ5tAw53MUKX+0sE3Kl
TWlNaHc=
=Cq5f
-END PGP SIGNATURE-

Accepted wxsvg 2:1.5.21+dfsg.1-1 (source) into unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 04 Dec 2019 13:35:44 -0500
Source: wxsvg
Binary: libwxsvg3 libwxsvg-tools libwxsvg-dev
Architecture: source
Version: 2:1.5.21+dfsg.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Multimedia Maintainers 
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
Closes: 933462
Changes:
 wxsvg (2:1.5.21+dfsg.1-1) unstable; urgency=medium
 .
   * New upstream release
   * Drop upstreamed patch 0002 (invalid color asserts)
   * Move to gtk3, part of Debian overall effort.
 Closes: #933462
   * Bump Standards-version, add Rules-Requires-Root=no
   * Drop unused, false positive lintian overrides.
Checksums-Sha1:
 77526b0adda50772ffd4403b1b2714c4fb25a483 2229 wxsvg_1.5.21+dfsg.1-1.dsc
 469d17d0cd4dd3e6975132138ae6f4fd57ff4930 160604 wxsvg_1.5.21+dfsg.1.orig.tar.xz
 0bf24bd1149aa7c2560b35d56dc4912b9def32a4 5452 
wxsvg_1.5.21+dfsg.1-1.debian.tar.xz
Checksums-Sha256:
 5f0dbeb439cc65b986d04d6319aa2ca2ec7f99e0a3d14f86caaa17ff66a72b50 2229 
wxsvg_1.5.21+dfsg.1-1.dsc
 0c3df520e3cfb9979638ca93999d3dcefb1de8215aa0872ec54d50835c2e56a0 160604 
wxsvg_1.5.21+dfsg.1.orig.tar.xz
 1fcf7984f9035f9300641ca6e7fbed3726f8dbe26c213054f9fe634d48ecf500 5452 
wxsvg_1.5.21+dfsg.1-1.debian.tar.xz
Files:
 e684ef194e505b8cb16047bba19654a0 2229 libs optional wxsvg_1.5.21+dfsg.1-1.dsc
 f3cc06208d76401937d4af8a4e127315 160604 libs optional 
wxsvg_1.5.21+dfsg.1.orig.tar.xz
 258927fd92b542b0689aa605a0402ecd 5452 libs optional 
wxsvg_1.5.21+dfsg.1-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQJCBAEBCAAsFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAl3o2CcOHHRpbGxlYUBy
a2kuZGUACgkQV4oElNHGRtHSQQ/+K/8Mg807am5QSzgMf3luG5H8KR3iBZotI7zk
l1ORpWgAR3381IAk9pcoyyMcOL+A3kejN8rN8uUeSd8yRM23GfqWi4wAJh9qhd0+
4tN22GHRX4XGMb9N8tZMeh9Lrl5E2ATztZUmnz4Z0H0kF70WFN1nA39/9P67P28V
Xee+38fVAQSOINg6s0HaeGkic+B8Ywl1aAt4qP8W9GQGhSqva0AfGwkZiCaiG0Wk
Z6MCLZnM/1iQPtjAP41/aGRs8Pa5FrfyhIS3OkbYty1HcGxS52R8PMMJwrLCPptT
FG/Cd/SnI93ciSGErH9s8cbH6JLYusSXS62xy30oOKf21aOsC7meWF91NNOS6Whu
aDjMJ4JSAvNe+FWh7g446rWKj3ucnjwm3Gn/LUxE4yc5cJZfJsrJypJxS1nWYoSZ
wiWNJ4zNO1xB3ouqqA6Vagld32xWkUfMA/O07tN7z1h5/zCvsJcpA1c1tzTfG8LI
356I0Kiaun679tWUkm5+QMnv9G4FL9sPveTMm4J7ouOCAi2pBqnLRrY9xRpCVvcS
N8jkizJMgVRMGbqW5SLpqSVmpqQhl4zy/+TqkQmLq/dWOzLTFt1tQCIiI93CAUsa
6eUshMLcZa4bdUfXVvyESxLAy8g6zlN14RIDa5RR4ok3Ji3mV8YORv8dxINjj+fA
fvQEAk0=
=KJ3V
-END PGP SIGNATURE-

Accepted opencpn 4.8.8+dfsg.2-1 (source all amd64) into unstable, unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Jul 2019 10:17:35 -0400
Source: opencpn
Binary: opencpn opencpn-data opencpn-plugins
Architecture: source all amd64
Version: 4.8.8+dfsg.2-1
Distribution: unstable
Urgency: medium
Maintainer: Debian GIS Project 
Changed-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-1) unstable; urgency=medium
 .
   [Sebastian Couwenberg]
   * Update gbp.conf to use --source-only-changes by default.
   * Bump Standards-Version to 4.4.0, no changes.
   * Update gbp.conf to source-only uploads
 .
   [Alec Leamas]
   * Drop minified js in source instead of binary packages =>
 new  source repacking.
   * Update get-orig-source to fetch actual version, not latest.
   * Relicense appdata.xml to match overall GPL-2+ license.
Checksums-Sha1:
 7e9aebd61afda29c98b7f583994c4f11b3cdcd8e 2334 opencpn_4.8.8+dfsg.2-1.dsc
 b855181588602aa3f50d37fb5d52c759f64ea7dd 20252316 
opencpn_4.8.8+dfsg.2.orig.tar.gz
 19fdf27925d265532bbb9e82b9c8f03144920a81 2 
opencpn_4.8.8+dfsg.2-1.debian.tar.xz
 7f240d46ace44ea1a05c02df1bce44e614a22a48 4084290 
opencpn-data_4.8.8+dfsg.2-1_all.deb
 591ce58316b466b2c1eefa6faade7af80980d6ba 44389400 
opencpn-dbgsym_4.8.8+dfsg.2-1_amd64.deb
 db7b3893fed3e8178ed47500299bcfbb0ad468bd 7444 
opencpn-plugins_4.8.8+dfsg.2-1_all.deb
 4e97d982110e2bb036bb573b342cebd7ce6d5f1f 15905 
opencpn_4.8.8+dfsg.2-1_amd64.buildinfo
 6f96e0e3e34e8b752186c6b512accbe4176e84ca 3084252 
opencpn_4.8.8+dfsg.2-1_amd64.deb
Checksums-Sha256:
 ad7e856b2de97ec27dce928cf32714e71741288634ff810f5c8ee69eb79ee4a0 2334 
opencpn_4.8.8+dfsg.2-1.dsc
 fae41ada0f28418cd19c879a5742dc88cd97767952a107ebc15a174718830780 20252316 
opencpn_4.8.8+dfsg.2.orig.tar.gz
 d94a650593c4170b39aa59c2bbbcea0663c2bfb5ad92cd2349d4d2ce7b4cb39d 2 
opencpn_4.8.8+dfsg.2-1.debian.tar.xz
 e177ab015b3fe1aa1a7632edce7bd2f75294317bad2c13c0845a76746087f90a 4084290 
opencpn-data_4.8.8+dfsg.2-1_all.deb
 524cc9b95d6d4ec717554be22652b10d5f415ac671e5831ac995a6a6d2ab 44389400 
opencpn-dbgsym_4.8.8+dfsg.2-1_amd64.deb
 dcdfc316e60efc57cb34037b1b73d0e80a98b322313b6b66c661e1f1b075beb5 7444 
opencpn-plugins_4.8.8+dfsg.2-1_all.deb
 75048003760f360cb30ef292ebdfccd1320f4be6afa1a0f0f2cb096fa1764d85 15905 
opencpn_4.8.8+dfsg.2-1_amd64.buildinfo
 45b6efe3d87289b2cd8d44dd24530c3b0abd4882bb8dc8a5575d183a9f308af1 3084252 
opencpn_4.8.8+dfsg.2-1_amd64.deb
Files:
 7d276ef847b4c7c3da898fc9d3d9778d 2334 misc optional opencpn_4.8.8+dfsg.2-1.dsc
 5f7756001fff3cbfec7c3a8b006657db 20252316 misc optional 
opencpn_4.8.8+dfsg.2.orig.tar.gz
 d567dd65c4e74c255bc7a6da5b594094 2 misc optional 
opencpn_4.8.8+dfsg.2-1.debian.tar.xz
 ee2672a66af075304e358eaea1c024dc 4084290 misc optional 
opencpn-data_4.8.8+dfsg.2-1_all.deb
 247b41e95d942f130931f7beaa329d4c 44389400 debug optional 
opencpn-dbgsym_4.8.8+dfsg.2-1_amd64.deb
 3c6ae3a8c50c567a9673d8bf9555ffee 7444 misc optional 
opencpn-plugins_4.8.8+dfsg.2-1_all.deb
 f65fb9371b15a460ce40f2f28ebf3c3e 15905 misc optional 
opencpn_4.8.8+dfsg.2-1_amd64.buildinfo
 cec626bcc200a5f61c16b0c320d94aca 3084252 misc optional 
opencpn_4.8.8+dfsg.2-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQJCBAEBCAAsFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAl05h8wOHHRpbGxlYUBy
a2kuZGUACgkQV4oElNHGRtEG1BAAlO2eZBdCnKIs8AkhiDrgkWnV6n/sqfUNApyW
umpICHf1wtpzplI8C4MlWw8vteBjtC22EKOUGvrre4OMvP6T6TAqYJMp3XmV2muw
bwEo4qmR9FMs6PvttNSkTdvua8AzE1dOZakLjzXx/qsESY1STGnESs5FOsI+/9me
I+WeDb/SL9wjd/essGYz9nDVp6p42cFTDbSdEQS7cOYIJ862O3Xz0mR4eyBM4dNt
A1uQVWWpweOmCOBOdt0YLKagnxxvukvoijnPEyvzlBcsaJpKJ4UdYYAIHGOg4RnT
6OX4GTNsWy4KOj5mEl37XdfgOeuHrFHHdnxFs0AtmSceDnOCknwwM1e7hreGkwL0
uXQE9VkWg4N+VrFf2nwLNALR9vbE5seA9eml3d3Q0rva6XJ39gRfGkpS0LshVaAc
9lHZfZIPNMwpnpRySCZq4vNyll9eao7LcAviNxQdP4FRQZQnnkHi9j85fvI7odZO
jzT+Io+cRG6aagRZVVvBWYj3vkUXLzEF97lcHYVYqnDrUiNmgVl5J/qG/fuHwA3m
CQSyUVANJi255xbP50oLsuJjnb+Eca9OaXopwNf5zuVk2DwR6EXeyaJvpoaAaC/K
QJcVejBltT6+5x7EU9yv/s0M26okYZ3Gadp5aP0Jkxk2tlgZ9HIJB/DMSiLFRPXn
l0PpCas=
=2bNA
-END PGP SIGNATURE-

Accepted ddupdate 0.6.4-1 (source) into unstable

[Alec Leamas]

-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
 .
   *  New upstream release
   *  Drop global systemd/system units in favor of systemd/user ones.
Checksums-Sha1:
 af98ed4ab83a603e8308c883ab6e6e3a37e6eeb6 1905 ddupdate_0.6.4-1.dsc
 22b79630cd8bf5307c0ac410e318b990216b9645 36988 ddupdate_0.6.4.orig.tar.gz
 d1ad49f78accd202f63786ceb9ae0a1d4570aff4 3288 ddupdate_0.6.4-1.debian.tar.xz
 f4ac48c94dbc8decbda9b24c1ec8774aa819faca 6606 ddupdate_0.6.4-1_source.buildinfo
Checksums-Sha256:
 16bc48a43b7ef75b2f91e4f86975bb8891e99b9834e5b36d13b6e12ce3464ccd 1905 
ddupdate_0.6.4-1.dsc
 51f253d44c18652996883c18f0a29a9a1d36e164bab3b6b8becea7e9c249c0f8 36988 
ddupdate_0.6.4.orig.tar.gz
 d100d7c4b74871d47d9787b964c9960bf2ff988bb33e857770e1eb2ec5ac9ab5 3288 
ddupdate_0.6.4-1.debian.tar.xz
 c9a0976a99834034558f8c3b88c6feeb23df69fe56097731dd9bdbb75603e76a 6606 
ddupdate_0.6.4-1_source.buildinfo
Files:
 c8921f4ecbfa23e698b1095dd517fd8b 1905 net optional ddupdate_0.6.4-1.dsc
 37e36f90e1b1aa8bcb19a52f8f5d2a4b 36988 net optional ddupdate_0.6.4.orig.tar.gz
 219b0a117ba9548fee615d08d6b0a5e4 3288 net optional 
ddupdate_0.6.4-1.debian.tar.xz
 d335650b0a37ba16fe9e558b7cdfe82d 6606 net optional 
ddupdate_0.6.4-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJDBAEBCgAtFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAl0i8vEPHGpjY0BkZWJp
YW4ub3JnAAoJELAdGnKsjcmhdaYP/3CKdp78dnNH5l0oke1K9x0lvRjbmqNc7gRa
mhGOHbdtX+tQtTGIpry66Jr0h1IhIZBV0yEPx9pPI3mgUmjB6wbi+ZZ568LSeJNO
CZCD3NmZTW4E7UK3NmYqEsRvzdwkFNBH3FsiBCbYnbacAJaHYs8u559tyP5tJaNX
uB6fRFxvwUFisc8Qy9GvSn0t3Y++TT4RjTAT/rVfDCSsPSt7XVMq7IplIIUWPCla
nJSFMgrwJ2pneBL+41v6J8IjtaBS2bXcF9lXstU5RBDaOwyZwO7I8LJ9XnnqCSVO
I8CXoSn8722/kBqfEHfxqMDUfdmuenwCAvbq6Ltu4EwB+kBAEZ+Z4GGVi02PnwL2
QqWW4w+gUbMKuTDOOHDxOFW2RIsmxAaw5Q7Cd4iNx7WFXhA32VYQqtvWv6lmL6iQ
PYALM9ZWBOguAgWgI+VA4NRP6lacNRDPMhqPUBPv3sAmqFK9pD3qTQAYwjMkzImJ
W27hddd7Ei2MQrv/hCCWbVsOtmxA3cFxWDkncAxTO6VFiz3zfIZ40y5ROMmlofOl
4trU3YNUEL+aZ/Re06RO1JssamTOQ12XpWZXtq8MVZv8QOHPWj8K4oMLv00kBiwv
OtcGWYjwa0DS7kKluZUahYN7yXBw2b492/XQfu3Tj6rC4k2WmSP25D0C2f/Qvf0u
LFYUwVOh
=H4Fr
-END PGP SIGNATURE-

Accepted ddupdate 0.6.3-1 (source) into unstable

[Alec Leamas]

-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
 .
   *  New upstream release
   *  Bump Standards-Version
Checksums-Sha1:
 250c43350899f1daa1b8ec508678107055112428 1884 ddupdate_0.6.3-1.dsc
 b2c05e5a767f5c0696a09d71ab14f6f54ac3c9ad 35820 ddupdate_0.6.3.orig.tar.gz
 e7472d0292e17d0418f9dc7bac5e2f79d1136b1c 3280 ddupdate_0.6.3-1.debian.tar.xz
 9f84dbde52798b1cd5e681a063f2c7dd5f1497d8 5582 ddupdate_0.6.3-1_source.buildinfo
Checksums-Sha256:
 8125ad453e50409c0bb446e9dbed03b18b45366ec83ad6cca60e09651326c327 1884 
ddupdate_0.6.3-1.dsc
 94ad40930a4dcc9d862724d044e22b96d6cf872e8948964daddc966205002393 35820 
ddupdate_0.6.3.orig.tar.gz
 5037b4508bd04c9fedb3b15609c327045e1fee546f0484f4c4b20dd904fed7ca 3280 
ddupdate_0.6.3-1.debian.tar.xz
 69b695cda366e56384157d656f2fc67046ee46d972721c257ceb095ef65440f4 5582 
ddupdate_0.6.3-1_source.buildinfo
Files:
 76bef1246688077931222532970ca87b 1884 net optional ddupdate_0.6.3-1.dsc
 ebeb9e8a7994f9dac64468ebd8a52645 35820 net optional ddupdate_0.6.3.orig.tar.gz
 5336876eeab1def348670ac181645bda 3280 net optional 
ddupdate_0.6.3-1.debian.tar.xz
 d753fe09a3ea83e5910ef993c4ad3b39 5582 net optional 
ddupdate_0.6.3-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEkjZVexcMh/iCHArDweDZLphvfH4FAl0COmoACgkQweDZLphv
fH4q4RAAidAQsNxx5gm3zwCAZI0JIPZmLEj6s9CbJmdEwAiFgkQA3ookNVfreG57
GXSEAw4cgCkakoWIBy3bBKBuWaepQEDez4uKtcjFL7uCpwQPzY4b7nR2UDtaOiPS
tdycZldZLJp90QKphBk0h888p7bffy2q81Uy0b3lBY7ZLvUYM27geJjT93Vv9Lwu
0L0wh5suhFbfTwUdHcgySN2ESQoaabOFfvd1OyFDBECuCjUICSroQOFE0rFkNZ+y
RJ1TmaeU2JQQukX0ehYznSN/LoWHN+pJ2C6MIuz9N6j5GyKkMtpst/n4laeiZDM4
Vjchdltbp54uxZXvNhVhMSc7OxoZYUzRfsQ1qJXbWvsxWX2n69Qz0JKWLoW+A0Mp
o1muL+k5SPNGouNXv8P/9YVAteHBxwIWA4tY0lFpykb218+cRKSejKTyY69z7K+Z
m809Ow2ArweKqs6t0VtP/Hou1Ys5ENByJ1nerhOW9jIzSxvzV+fuNKkeNg8s5dUm
XwSDuWfYEXzzTFifXKhXaYd9Y6xy5rbVgAy2tY35VlrFqgP0goyGo4Rb5G0yxBbb
df8WD/GMzkigd/WtX/+SNtECM+s8EB8Ui234dEm8GX50T8+zX5aLIDiSu0TsR0Y5
B0W2aH+s0sNPLYTNwGryuggXQ/vxHp2EJ5pVrOMOdeJ4QVkeM1s=
=9FeV
-END PGP SIGNATURE-

Accepted ddupdate 0.6.2-1 (source) into unstable

[Alec Leamas]

-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 upstream release.
Checksums-Sha1:
 f08e175f013142cd47ded320dbbefc112c3da761 1884 ddupdate_0.6.2-1.dsc
 0c7022c454c909fd564eec46f8c0ab479b77ab2f 35743 ddupdate_0.6.2.orig.tar.gz
 976124ab938ee79e27e29c5945f755d34e8307fe 3256 ddupdate_0.6.2-1.debian.tar.xz
 510953a885265c5aefedcdcca228cf50cbfbf95b 5523 ddupdate_0.6.2-1_source.buildinfo
Checksums-Sha256:
 55be40e035cf29a7a11fd1383eaf7c5b25319fc5e5ca7177e0e9efc2f211da25 1884 
ddupdate_0.6.2-1.dsc
 707bfb57c3c8be809edd13a5295fab43d4adfdecd6fe693193ac519bd2e77889 35743 
ddupdate_0.6.2.orig.tar.gz
 8df20daaca7cc3aff1661429753f7e129be5d6d2039e944f90d5b347578304c3 3256 
ddupdate_0.6.2-1.debian.tar.xz
 9ad8258ae06e2d5604b981a55046d57ac967a4f84b73fc7fce23efd6edb20c67 5523 
ddupdate_0.6.2-1_source.buildinfo
Files:
 b035d4e41e0e49b9757b40da649fde18 1884 net optional ddupdate_0.6.2-1.dsc
 10be0f03379f56d6a13950739882b54d 35743 net optional ddupdate_0.6.2.orig.tar.gz
 417d47920fffa1aac31e08cf9d940f67 3256 net optional 
ddupdate_0.6.2-1.debian.tar.xz
 e25c7b53d5556d9e4409bc96abb1d965 5523 net optional 
ddupdate_0.6.2-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEkjZVexcMh/iCHArDweDZLphvfH4FAlyyWbMACgkQweDZLphv
fH7cAhAAuZxIwvmTG46FJPKN5R/w8WwgLFSgMnAfHIc4vHl61KmJ9vV5gca1NKsJ
4r/SCplHnq8ztsG+o4q92Ii7wJRMYDQYNrRUQDTOKx6p88t3yBUZkVmzjdAIY+m7
vUXh5fSRK07LqjsBUpuYFWqOzcR95rUCNZSXwkutqBwC1DQZLXtSpRO5X2Syg0DY
Q3lj2l72dLuUKQbrxrI+qAe2VazhAPEmyukTzt3bBPV4zWENyA/S5Wwx6JrfiiTc
QY7PfLl49JSvmriE18C77hA5USKXqpjwBkUg0thEY3Bzi2w2OvxQzxMrLpEclOK9
uaMK2odmwJ83emSqsMAUkgAafrz7uNez18pMX+65mPffc0oUzy3lyT8tfuyXn0GC
EZ8pt2JdrU78VZK+5GBKk1Gh9BB7bm9Qc6sMxAsYBzq1drq7qq1QLV77zcvr5TCl
fW0GgAdWeUMbeaX/0pOxYrLXjxbdFxUh6qVAQdd7sZn4So44w4kk79dDJBaDYwdn
jreAFqpt2bMRSl6FMukd3B+lF/YMOq0JQKVfxS8VFX6BZsuxlp4PcZcGmAvlxVLy
cRrJFdysq/kllFL7SjAtV2/Y3NcGcnolVPITO5xKFbbpAnxPcSuVxW96ie7QttaZ
AenNEKJ7bhCDbtnZxgI6O08KrAilyB1rMd42vvPREuwLIwuR3kw=
=q53e
-END PGP SIGNATURE-

Accepted libcxx-serial 1.2.1-1 (source amd64) into unstable, unstable

[Alec Leamas]

-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 
Changed-By: Alec Leamas 
Description:
 libcxx-serial-dev - Cross-platform, Serial Port library written in C++ (devel)
 libcxx-serial1 - Cross-platform, Serial Port library written in C++ (runtime)
Closes: 917531
Changes:
 libcxx-serial (1.2.1-1) unstable; urgency=medium
 .
   * Initial release (Closes: #917531)
Checksums-Sha1:
 8b0657361afbcb0593bdb65e572e71adf22c9b93 2001 libcxx-serial_1.2.1-1.dsc
 382de698b61ef8d830799e36585af51d81b3e9dc 47116 libcxx-serial_1.2.1.orig.tar.xz
 aabcf19f1352e03fb036a8f27d2c0c47a8a7c973 5592 
libcxx-serial_1.2.1-1.debian.tar.xz
 6cd06efa0f8eb3e6464da9e4322a787ca0cc9b98 109664 
libcxx-serial-dev_1.2.1-1_amd64.deb
 59e3b8acc220ea9ce6bb2678cb451f686b6ae136 295776 
libcxx-serial1-dbgsym_1.2.1-1_amd64.deb
 0b14323af167c1eccae87ac03c75906217860d43 29948 libcxx-serial1_1.2.1-1_amd64.deb
 1fbc54e1fbb755df6a928726d5612d6b81534f62 9633 
libcxx-serial_1.2.1-1_amd64.buildinfo
Checksums-Sha256:
 b1dc077c5f7b06f1a845b32a8af70f965384810d7829e3a23d4c7e46c5ff7f89 2001 
libcxx-serial_1.2.1-1.dsc
 4757c6171b578b079d82f7b955a964747eedce80da9d8ad6841e4d15b160f40b 47116 
libcxx-serial_1.2.1.orig.tar.xz
 46a1c7f9ff1de27fd4abccd8b0592f7685e3b2b4b3a67e27df4c658c465a984d 5592 
libcxx-serial_1.2.1-1.debian.tar.xz
 252a13b45b226dcae6093413d6c4ef871555d3a538ec482894b0d5a1c32c1776 109664 
libcxx-serial-dev_1.2.1-1_amd64.deb
 e7b8542a681057565c827d1ccae6938ad0ab608d07cacd8878de71d211baac17 295776 
libcxx-serial1-dbgsym_1.2.1-1_amd64.deb
 0b4553c7b68e160e6ebfb6f64176ced2ca11c1dfa70a241dc8cc4471792b3d75 29948 
libcxx-serial1_1.2.1-1_amd64.deb
 4c9dafec6bc5e888e6debfbddd991ac30779a0a5d72e1b4769de67814fcfa991 9633 
libcxx-serial_1.2.1-1_amd64.buildinfo
Files:
 21234d615c78e8ceda250e988be14cc4 2001 libs optional libcxx-serial_1.2.1-1.dsc
 b07c93f3e5fab48073a0277e2a7196eb 47116 libs optional 
libcxx-serial_1.2.1.orig.tar.xz
 111f21b4fc025b8317488aca8c4b 5592 libs optional 
libcxx-serial_1.2.1-1.debian.tar.xz
 51821745fb6d6a89d85679b4b7c12df9 109664 libdevel optional 
libcxx-serial-dev_1.2.1-1_amd64.deb
 0774b791ab2c934acaee9eb524cd52e2 295776 debug optional 
libcxx-serial1-dbgsym_1.2.1-1_amd64.deb
 7b6efe76eacf4f5f85ae03ac7a865ca9 29948 libs optional 
libcxx-serial1_1.2.1-1_amd64.deb
 198fd05488a034e8dfdfc5775a6eef19 9633 libs optional 
libcxx-serial_1.2.1-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJDBAEBCgAtFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAlxauUgPHGpjY0BkZWJp
YW4ub3JnAAoJELAdGnKsjcmhkXkP/jLadsMD3Kv/N6DNtluKcUsP6d0c4Xe8BP88
t2kwNM2CYvnnC5ShuJTFaW+m7McVmQq4GKLNHD+j19rvaAzcVAdjSxtXS4BG1Y+b
46AT8JtDhPHQI81xHXOYBbPxTbOcQAbSpILFF2aSCL4r4mDfn8AV1i+t8c3pZhVm
uPQ4vEhWmik+hlJTaiFNDKqnF4ERdj7Pkbwc6lBTr4by1rfdH3Lw9PdDNwxLi6zh
3064+3JzL5yido+eRxgUhgD/Q3Q3X2PSe981hpXJfB8UqBMnIHAJOK3TE2iUSpCC
25cXYfaJtdUeAo9UWCjPKyy2c2y7vYIhJx7kfj3vn9uW6x4/Uxh5VXtVmxypwOOL
KppxeITuIJ0Qu4pXyIf8rb8fg/DpU0w05CeJtCyuYeQdrWCJwDyKX18UeiuKqQOj
yqtmMZDjZrw6ReA6EUHxev3kagC6xgczfILPMD3gg82d696YFInIhdFHIanLRxqJ
D9dP8HzkqSa0ZoYQPS4H/mplfFNagV6jcNDCDQ6xrl7Uh47ZJDQt2xsvkjnUw1NP
c8T26ykCXFFPXxgz9bFu/oQT6npRERRgSWp5nIcfeeGuWyJxveDm60yg59ygYMCM
6CiXtpOZB1AsdZ30VTmUryO95awg+cBqrCcvLjnw5P0a5VdEXsxOM0HmGNBJ/uoU
a1K+G0JJ
=WUqA
-END PGP SIGNATURE-

Accepted lirc 0.10.1-5 (source) into unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 01 Jan 2019 09:19:01 -0500
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.10.1-5
Distribution: unstable
Urgency: medium
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 placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Changes:
 lirc (0.10.1-5) unstable; urgency=medium
 .
   * Fix upstream #343, --connect parsing error.
   * Add systemd-notify call -> lircd won't start with invalid config files.
   * Move VCS repository (now separate from upstream).
   * Fix lintian command-with-path-in-maintainer-script warning.
   * Fix lintian warning for duplicate files; new rdfind(1) build dep.
Checksums-Sha1:
 2b91d57d72cf7d6640e9e8d9078abeda2707bedc 2663 lirc_0.10.1-5.dsc
 1f1a464d195253268ab6eb64fc39ba472114a6c8 35420 lirc_0.10.1-5.debian.tar.xz
 f06bd23495ca487d747ab0836bd09067e15a0ef0 8231 lirc_0.10.1-5_source.buildinfo
Checksums-Sha256:
 ce024984a53e12f48dd0101ade497cbe7b273ad4d2e7da0ac723571e406a27d9 2663 
lirc_0.10.1-5.dsc
 6c3cce8101ec4a1b47b40fb28e0526b4f340e8e50300f3ad30b2366f23f6eeaf 35420 
lirc_0.10.1-5.debian.tar.xz
 40e7452f8fd3c46053158712234ac6669ef40f3c57d1c52a3729e4ef0655f355 8231 
lirc_0.10.1-5_source.buildinfo
Files:
 d9b81e3ecbb6374c69b2b1e15e4afb47 2663 utils optional lirc_0.10.1-5.dsc
 df412245e7ffca0935a0cefa7f2d3009 35420 utils optional 
lirc_0.10.1-5.debian.tar.xz
 ffe62f2bddeda2c111a9586b3ffaaa0c 8231 utils optional 
lirc_0.10.1-5_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkpeKbhleSSGCX3/w808JdE6fXdkFAlw8dgcACgkQ808JdE6f
XdnoyA/+MhK6N5i7lSDH2wSPVssCVZJLrqoQ7ZunUliE8RnqRyOVSPDlxdFn+hVj
c3Kzduu8hM7m9oa+nS7Fs/qMc+1mRzEXolM4FGpWnbQRh0miz/rqF4zGau4TkBdI
hYxhAGcxaqZ4KmVm8/9PU2ShARgLix8dzVxZ6CclVW/lfTkaic9nab2DnVqpB088
QR+4bYdZpg3XkMywgn9tlro0jaS2dx2zDG0AUeh2m6bA9yuDsSS3QqQ6MKzOsKKw
6SSocnlAXL8Qpo/IOwWgaqDZEbvPDGdc48/K0n+cnIkpJqEh3W8XHIrZCNngJiFg
9oIPyHvvcLocxeAHUppxxD6ac5BhgOVD3zrjm2mrFxfIACPQBEdAB+uV2EWXULtM
1zZ0B5eC9x/VF3R0n3wWv3L1IzMfn2ez60uOdXkFwRUz2JHCdQPwEs8bt3n1g7BH
pGhKxT00C0lBwXK+AOj6QefKEtOakblHgFqduGE2cPGpX9MVTjkq3i3CFqjwKAko
znhfg7NavPdwtBgoo64Og2vi72rjtpjBqvOoVfYm+L2kbGI6cpG2tWtoj+Po4Ls0
jMQD0eDHoS4DSKh4LYDRLKKJLA6p0jm/jPP8KYWkD+hugCoWott+sJExZkCEY35m
rXpw8hQkVBQdFVYMT3Qv8rC10y8jlTDZUYb/+Zu2A8+EIKCGLh8=
=h8lk
-END PGP SIGNATURE-

Accepted lirc 0.10.1-4 (source) into unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 23 Nov 2018 23:41:01 -0500
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.10.1-4
Distribution: unstable
Urgency: medium
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 placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Closes: 872749 874246 912400
Changes:
 lirc (0.10.1-4) unstable; urgency=medium
 .
   [ Alec Leamas ]
   * Dont use broken LOG_CONS syslog flag, closes: #872749.
 .
   [ Pino Toscano ]
   * Fix build on !linux OS, restrict systemd only to linux OS. closes: #912400
 .
   [ Gianfranco Costamagna ]
   * Team upload
   * Restrict postinst systemd calls only if systemd is installed
 .
   [ Helmut Grohne ]
   * Remove multiarch-annotation fom liblirc-dev (Closes: #874246)
Checksums-Sha1:
 c0e020ac7929bd469c57c11f82f8ce9abf698eda 2696 lirc_0.10.1-4.dsc
 12c876322712757b71fa4c532e19d22652e8412e 34568 lirc_0.10.1-4.debian.tar.xz
 cbca528a60b3f04208b87bdbd21c748261ee16a8 9066 lirc_0.10.1-4_source.buildinfo
Checksums-Sha256:
 a4f9edcd29fb765f7ed04a74593c346dd5475139ca9cb28b942b69e0beb5acec 2696 
lirc_0.10.1-4.dsc
 ebd5b4f67a87a11e2497230adeeb51a9c9850559f9bb17b7ce4dd5a7a05a9e01 34568 
lirc_0.10.1-4.debian.tar.xz
 56555dfd3c0c217254f6e6fd3ba7a237e32196365441b138c88d01bb4afcf182 9066 
lirc_0.10.1-4_source.buildinfo
Files:
 689d02286025e68d3c9ddc8cc951cbb1 2696 utils optional lirc_0.10.1-4.dsc
 21ce1d95cd0bbeba4b1d69f4c72a 34568 utils optional 
lirc_0.10.1-4.debian.tar.xz
 4452206feac72b10cf08c9d8210a52be 9066 utils optional 
lirc_0.10.1-4_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkpeKbhleSSGCX3/w808JdE6fXdkFAlwp1r8ACgkQ808JdE6f
XdlI6hAAuwdEpJNbp1GRiUsTVVELs1O4lsu5wKVZzOs62UOlShvvrtv1y6pdSN1+
sDNnJjwOCVDRe6yON3Qw8V094pjyThbB0aEufwYw0saTj5DK607ZuigOP9DIhZn2
BHeEcvg84ZDLByK5YRtwHrzaGttEYfycCukHCJshiZlY5+VwNeyux8Jyr86XgEGC
8UIqwHKUvVErZWzOX+Xc/T+KeIvqrReK+ePTlXKdiWfnXr1/MI0n2Lm28mG0ZiVb
tY8xgVB6UJZIQOgwE3cNHB8ruI1ffGWB08UTRNUcrA6pzngd4qZ6/UeAXcV/05S6
JEiBaRtcOLziJ2gu2C88DPlAgM4Iy8wAj55CtS1Oa8Yd3n5n45Feg7pCQ0DV5sHC
9d4PHLeGaaxN7xl5HyRNO1i40sP7izpJKA5zWZmyk8PSOArfBJwHjmTYNvQctLHO
O54nS5nhBP00W9vWw8hj5DpmHgO5gUA9uqZGI+l6Y3OQwjy8+Btd8XzcRZXQYdAm
RTV1D9oXySqo7Cb6fHyTm2wf+jEy0K8hzzA0MZzMnZrgbyaI2Y5Q4x+Q6oVzt+rM
bYymL3u1aMqYAlCx/ADaBXmXb0JydZy6mXhg7i3xjZZx2cyZd6bvzi8k2KoIIjVI
hnaDftleHjAPNF+rtZfBBIKCGmm55YkjJIswqJssNbp7elhdrhQ=
=hnf6
-END PGP SIGNATURE-

Accepted wxsvg 2:1.5.15+dfsg.2-1 (source amd64) into unstable, unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 17 Sep 2018 21:13:56 +0200
Source: wxsvg
Binary: libwxsvg3 libwxsvg-tools libwxsvg-dev
Architecture: source amd64
Version: 2:1.5.15+dfsg.2-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Multimedia Maintainers 
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 upstream release.
   * New -tools package with svgview viewer.
   * Update dfsg versioning scheme.
   * Drop get-orig-source in favor of regular uscan download.
   * Add hardening build flags.
   * Move to libwxsvg3 to match soname.
   * Add rudimentary d/upstream/metadata.
   * Bump Standards-Version.
   * Add libexif build dependency.
   * Drop libav10 patch
   * Drop --with-scour build dependency.
   * Drop bundled but generated files from package.
   * Drop obsolete version requirement on libpango1.0-dev.
   * Drop obsolete g++  and dh_autoreconf dependencies.
Checksums-Sha1:
 d084eae768670fa9e81f766ac52fb0716b4a06c3 2200 wxsvg_1.5.15+dfsg.2-1.dsc
 619393a37e31e9f031fc7d2ba355378d63b7cb1f 164335 
wxsvg_1.5.15+dfsg.2.orig.tar.bz2
 d5f9e523c8f7304fd374514eb88f9888e7dc11ef 5620 
wxsvg_1.5.15+dfsg.2-1.debian.tar.xz
 abd3947c1ba48d412ba477f404e47486e3b81448 51260 
libwxsvg-dev_1.5.15+dfsg.2-1_amd64.deb
 53174ddb998965b6a90fae86ea1dfc22358f2af7 286160 
libwxsvg-tools-dbgsym_1.5.15+dfsg.2-1_amd64.deb
 6039a8cb0695a76e5165eccd27030703fed35ab3 41916 
libwxsvg-tools_1.5.15+dfsg.2-1_amd64.deb
 aaf9a5363f3e65a0dbb42f278357387e75ae15dd 6975648 
libwxsvg3-dbgsym_1.5.15+dfsg.2-1_amd64.deb
 c274e2466050afc699aa661ecf0841e628354211 360680 
libwxsvg3_1.5.15+dfsg.2-1_amd64.deb
 358ffa50b38c281c3a56e94263917b7b95bb1f76 14067 
wxsvg_1.5.15+dfsg.2-1_amd64.buildinfo
Checksums-Sha256:
 809c543c3b2021855c1d68d1c48a80308b57745bff8532d931d25163ecf20ef4 2200 
wxsvg_1.5.15+dfsg.2-1.dsc
 cefa1ddcc60566f1759480e0f7ae1bd0d2a3ab0c9a130b132adab5e3ef48b798 164335 
wxsvg_1.5.15+dfsg.2.orig.tar.bz2
 4bde2565cf8e4d19202d7a8a6428523e66ffda93f9d1010b7831faef567f2397 5620 
wxsvg_1.5.15+dfsg.2-1.debian.tar.xz
 9650a26d24b80b538c147e896b389d2975b0641057e5c81d82884b256ebb335c 51260 
libwxsvg-dev_1.5.15+dfsg.2-1_amd64.deb
 29304daa40e91316cce0386ee805681db5d11923c64b7f52c68ac9070f5f95aa 286160 
libwxsvg-tools-dbgsym_1.5.15+dfsg.2-1_amd64.deb
 a8a61043b269a7966d399ed3e4fbd88080772ddfebfb3fa822ec834737354feb 41916 
libwxsvg-tools_1.5.15+dfsg.2-1_amd64.deb
 0fec7112b022fbfe9686acc4ee6ad5a9db47e663c9a02ae9a412574fc1bb07e7 6975648 
libwxsvg3-dbgsym_1.5.15+dfsg.2-1_amd64.deb
 a41ccc6a3850a49fc16995d67043910d3aa4f965ac5a7d6781a26d8c929a5fa1 360680 
libwxsvg3_1.5.15+dfsg.2-1_amd64.deb
 73095226aca7f548f5e8f9c5d3ab6c44f743e709eed04615bbd45763c9b451f4 14067 
wxsvg_1.5.15+dfsg.2-1_amd64.buildinfo
Files:
 1d4557d476b1a64eebb41d6b897c8922 2200 libs optional wxsvg_1.5.15+dfsg.2-1.dsc
 054b525db4f8077949e872f025d1f543 164335 libs optional 
wxsvg_1.5.15+dfsg.2.orig.tar.bz2
 2ffcc48772786650eb9b15b26a1e49d5 5620 libs optional 
wxsvg_1.5.15+dfsg.2-1.debian.tar.xz
 59066612d373c95770f356865e4ab136 51260 libdevel optional 
libwxsvg-dev_1.5.15+dfsg.2-1_amd64.deb
 d5cfb918ceb1e6fd991a8b74fe04422f 286160 debug optional 
libwxsvg-tools-dbgsym_1.5.15+dfsg.2-1_amd64.deb
 66869cff8293c26c0d0dd21c8790007c 41916 libs optional 
libwxsvg-tools_1.5.15+dfsg.2-1_amd64.deb
 cb7cbec3b8c2fdeb9f2cb52b29490aa2 6975648 debug optional 
libwxsvg3-dbgsym_1.5.15+dfsg.2-1_amd64.deb
 366b8ede653fe62d37a9a962cb5eccce 360680 libs optional 
libwxsvg3_1.5.15+dfsg.2-1_amd64.deb
 f963cbd34c7d78dafa78b3d6a42ca528 14067 libs optional 
wxsvg_1.5.15+dfsg.2-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkpeKbhleSSGCX3/w808JdE6fXdkFAlvR2hEACgkQ808JdE6f
XdmxjxAAlWVN3IhJ9LL3jWJ7Xj4PPVMJfoZZxsn/kwjvU+jjW46B0V3UDB13F+/7
D1HBnxynSTKHZ1nDXtXnvif39uugUY7qK7QLZ7dW+cEVGN+mOLQjOrbMVIhA5BS/
DMF9jNTjhsR8pA+aK48KvKd5ERrpnNkxXpO0pAgFUMgBiTdBo4eijOy+k+VKuiGM
9eNA8moQtG0hwJmzgD1dg+aQEkl/JtGLmwCrn+duuZXe+7l6yXnsGAIAWu7ov/Co
/SakO9L5FVzuWEhMvLBWvza0yBLBaeUvvOCWFKq8JBo+Z9sVUgOUP0yfnmWg5DJg
zk7CaJtqDP9tPB83XiapOZnaul2CsnE4+7YCLpdtJWDzHcOwH67pi56jVyEYD3Sk
iwLrBVbOP3s7S7mhfeDS+ejfeleY1kmT4+mxRiKIwAW6l6rSKva2XS/n1ETBfRiv
sNSWYvWEAk3gSF2sNKEqis/UM9o7eBBe6NS0qiNbfiOGp4qJqHeziXILbNGZcu6p
EeYZXi8fTx4fachlISEKBuwIEWX6uwBgo9LtGhRk+zigAUgjznIXl92AFMlPaLnB
KcwPuk//OK9Tw2Cs6uSU0q0tFQyd0EETacvQe/GtvKf0H/vh0wtPh/RpELI+Wdak
CB2pL+wxlUvw9dtoVxuw9GAS0m8SO+eDdpsjHYdvzrcAHsFexEg=
=O1dC
-END PGP SIGNATURE-

Accepted lirc 0.10.1-3 (source) into unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Oct 2018 13:05:49 -0400
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.10.1-3
Distribution: unstable
Urgency: medium
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 placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Closes: 911548
Changes:
 lirc (0.10.1-3) unstable; urgency=medium
 .
   * Remove links created in postinst, closes: #911548.
   * Add missing Recommends: systemd.
   * Fix insecure URIs in d/control vcs-git: and d/copyright Format:.
   * Add rudimentary upstream/metadata.
Checksums-Sha1:
 82ddfa3761b8744d0e61163dbe54970b84df60ef 2696 lirc_0.10.1-3.dsc
 9902308b74bcee394d50e72fe0b742144befc7f9 34064 lirc_0.10.1-3.debian.tar.xz
 3a13c2c7cb6ec12728d0b2ed74cb4946e15d2aaa 8991 lirc_0.10.1-3_source.buildinfo
Checksums-Sha256:
 3669c2df9b9633d619042f487bf69cc6c9c2ad5df3d292d41dcc667cf34d 2696 
lirc_0.10.1-3.dsc
 a3fccf7a59792a9e8bce8e2e0ba05f6cdc43026811026a87c9d80bce4b45447e 34064 
lirc_0.10.1-3.debian.tar.xz
 2eeaec00df38f2c7d1563d703e185826c7197b8e2030b6a8c0286a6dbb59fb56 8991 
lirc_0.10.1-3_source.buildinfo
Files:
 fe25ac2392ddf2da94035ea336811bbf 2696 utils optional lirc_0.10.1-3.dsc
 7ec9d49834741c63a8386fab1db69d18 34064 utils optional 
lirc_0.10.1-3.debian.tar.xz
 f8598e18df88662e1040e946b9d47660 8991 utils optional 
lirc_0.10.1-3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkpeKbhleSSGCX3/w808JdE6fXdkFAlvYWIYACgkQ808JdE6f
XdntyxAAjo970lDKqljkaXqWUJkvR4DyOIm8CgNNNclXbfMiRucr+APRt7NXaGZx
w3JLQnTMQj8PenD2ouwj8BogmngiIiNpA+Uflzc6LhXuDguTXEuIkHBqa2Al4vbQ
3rwEAKKT9AzL2I2s8cANYmdYH/cJyVSNOYqXlMXgfMm+z5XuyTdY1aAvmFLTXg3N
+jA7JfBTV5GYfHQgBLbKNZAQbx8riUaConbn0+CwXol0mZbVLH8e11cqzNoNt8D/
b9Vv9Y1ZJdB1pyLUPT7Cf2SzjnMulMOa52CiNbq5SaULoxrMK+bDzFKBcpYIwS7L
me5cdXGRwp2kWZm1YfJxVmEmDhJwIMtx7xSZjfXJhqbwWQ/ZcOOrnW64dgjjMPt3
guN5W01uFCBWNh40wp1iYx9fIh2RAn1ZDVMtYZB8AWxpyWAm/i3naittWyOCeagD
HzflLKnpUNktrzo2gAQ0or0vzLj5/ANxHfCwAQVgNCqNU+zI6yLi/yiDpjzojbOr
zjnYYqg7iN398Wkdkx086bWen+C6gboXjhR/YLKt17G2rPLHGeWshuEx/KjWAekF
+zELnC0QHudb63fW2IhMACPL/Qtgtnclk1ypnvfq7m+n5qX+3IE8Sea4Ee8jJsD/
fPIgujDaUYu61/7qmrPLeqT6ZwlwDpQV2VYtunKxHQTEqgTBlDg=
=aeLk
-END PGP SIGNATURE-

Accepted libirman 0.5.2-2 (source) into unstable

[Alec Leamas]

-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 
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 support
Changes:
 libirman (0.5.2-2) unstable; urgency=medium
 .
   * Team upload.
   * Ack previous NMU
   * Update test program installation paths patch.
Checksums-Sha1:
 4f47219743b9c1167e23183d8e65cceeb2b0ed2f 2197 libirman_0.5.2-2.dsc
 8d97ec389fa7e86bbd4fb16e1f43a2c96ba1b64a 5092 libirman_0.5.2-2.debian.tar.xz
 8dd443c0a85ff935e24edc196fb91d47967fc475 6847 libirman_0.5.2-2_source.buildinfo
Checksums-Sha256:
 9c3b6f72bfcfe50d1ff035065f1b933534e8e60e1d550049fad6ac2ed13c76b9 2197 
libirman_0.5.2-2.dsc
 12fde77db06b0ca2172ac53a20513440d286c069db4fbb1fc799148812c5e5e5 5092 
libirman_0.5.2-2.debian.tar.xz
 713a38aac1b60aba1cbbfce3466389e6415e2f59d9edd254b9203605f7b925c7 6847 
libirman_0.5.2-2_source.buildinfo
Files:
 d0d8aada7e902c160a696974e8081676 2197 libs optional libirman_0.5.2-2.dsc
 2055cd563a850541db7d3bf5c9271807 5092 libs optional 
libirman_0.5.2-2.debian.tar.xz
 ce8590dfe31a539d7c372802ab939d0b 6847 libs optional 
libirman_0.5.2-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkpeKbhleSSGCX3/w808JdE6fXdkFAlvG/o0ACgkQ808JdE6f
Xdkp4hAAtd+zAACXs5CFszJeQc3ZXWQkKinf3QG45rtHQbAi0RGFngbXknf2d657
K3mH+x6CixT5JjoEkNmU0YZU05eYTGT4nzEw8X2nQWhsj/EtHCv2IJkt9787gLM2
p1SKXmPG0gAH3r7o+G1TT6SIJMogZiLMT5mHaAa3rzRsxAnqs1oyRnoLx8xBUC4s
dtDk/5XxiSiqhzKo2oHih6wFhW6VeIJsrcKCe9twJrGnPxlca+nqDwUpVM3Btn6Q
OHz3MS246vK77PcbeVwHAxhKkKK8851kDdyrSgA4+ppQErffku4cru3F+xprGtGZ
4XRTpjvbJgnVjfMS23NXea/KI4fO/utSLXDFjVYicWnirefoBJL3FfOQbTMP+Yt1
Ojtt5bGWUL3y/YDXkw5iOd7rWq43ey/dBbcT6zF/Mcu5jJ+0RsLcrl2HH3bBYjfD
CsoIwxqZbgho30S+3MAYWsRCZF4YxEaLF2Xsf9JiXsWYnkEuchFob2vGFFGUm5C7
jdpqwfAbXmGQFZ2Jb1J4I6D4xWqk/XOburF/ztROCtBNe0kPdflVoYmPOmTScuXa
I7prbeBpQ5OEGVuNc0xxER5Yj8B5VQAHksFUUc/z4ZGuid+OGiuDXRlReOSVzRR/
23wmt/SC5UljFYxyuIk6/iZxfZRoZH7k2zMqqMnqF8KvrrxYA+U=
=G5cC
-END PGP SIGNATURE-

Accepted lirc 0.10.1-1 (source) into unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 12 Oct 2018 16:51:50 -0400
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.10.1-1
Distribution: unstable
Urgency: medium
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 - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Changes:
 lirc (0.10.1-1) unstable; urgency=medium
 .
   * New minor upstream release.
   * Add fix for lirc-setup(1) crash on startup.
   * Services besides lircd.socket disabled after install.
   * Bump standards-version to 4.2.1 without changes.
   * Drop 0001-build... patch now upstreamed.
   * Obsolete priority: extra => optional.
Checksums-Sha1:
 eeb40ed3ae88e9e913b860ce4ffc52df1927 2699 lirc_0.10.1-1.dsc
 0188b9886d3bd0d4f0819050865001e2dc7e85e3 2715271 lirc_0.10.1.orig.tar.gz
 075635b4f2b21933a988c619a01d1bdd9f6e0cff 33732 lirc_0.10.1-1.debian.tar.xz
 46186c86b9318900c5f3d284c378b743146be65e 8976 lirc_0.10.1-1_source.buildinfo
Checksums-Sha256:
 5117201c0fca4dc65b7595095f89cda68b05ea6cdf73c92d9c5d2965b722a21a 2699 
lirc_0.10.1-1.dsc
 25b0a5c761d927e9651e6eb54d0ce4cce3870ebb893afad5c4b181182fc642c1 2715271 
lirc_0.10.1.orig.tar.gz
 1eb04c0d51d9ad0296c98e60c5571d18cc7b61ff009510158722fd359f227e90 33732 
lirc_0.10.1-1.debian.tar.xz
 f953c912362509a3a6d7d16bb7fe5e1e41484e4104a8018f2ab57dea835360e6 8976 
lirc_0.10.1-1_source.buildinfo
Files:
 3e2d5939323e0a06fe7d86ec785b1472 2699 utils optional lirc_0.10.1-1.dsc
 2a390b353181fe6c6b5b94dcd10ba743 2715271 utils optional lirc_0.10.1.orig.tar.gz
 35b8fac9b799751928c16b4dd7c6e2b5 33732 utils optional 
lirc_0.10.1-1.debian.tar.xz
 26c9f7fb1d9336b1e03b1013fde80cf8 8976 utils optional 
lirc_0.10.1-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkpeKbhleSSGCX3/w808JdE6fXdkFAlvErPcACgkQ808JdE6f
XdmsDRAAkaRFTzxf2qR2DI1ujSRIprZ02d26y7wSXrb3mNKnsl/lWgNPdmOafGIn
E4vM4Pmbl1JPaiGoD73qpdxTe5rMAhAQ92EMlz01tucYAhHXVHmH/69kfHlHjGZ4
1MUDnJRbNNvrV2vcMmdIKvJ3wF5veD5HuVqRseM5kdGuR9/1Lbrv+o5DBtJXm52O
nMc/I7fotxNYd5DzBeFMCHW3JLZ3/Cz+jTV1yvjRlSEedHUI3y4AwHaYsZX5ooaU
bSkWl0Ni3Qczvo1OorvgbWKx+pptEOVvRFO7f/eV5dKQQxkWwbQBJkkGpz8dvvSN
uAXyAGAyJM8HziB3WZ4btrFWaw0cyVBq/WHZ/M2/lZk8DkrNvzk69O7VboYQfk4I
QMPPzDCpArl8zv6aSGo+xMCmf2omVhr3z+3mfhEW+B3oCtWXD1aXSVlJLUy/Faap
Q4Nb/jfIugGkE9YlYBETNQLbS/xrn833qCvfmo3F8gokZETDxsgC61LnJ+dPla4i
XAQJh6Vtk4gxGtlACS+twB3cJNhfRM6jmoUg3SDJ7LQ7a0uqbDxyZJLqaI98lQ6L
5xc09qPS/GMHbXEY8r1vMf8+dMpeFEujxWw5DJNDWFxbN+K7R+FVVnI76vLBP0so
XKi6WeItQ2nrZ/IGg77obDeR5gqCsglPdO2hpYsH6gQ3dk7Izvo=
=ncHF
-END PGP SIGNATURE-

Accepted unarr 1.0.1-1 (source amd64) into unstable

[Alec Leamas]

-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:
 libunarr-dev - Decompression library for RAR, TAR, ZIP and 7z archives (devel)
 libunarr1  - Decompression library for RAR, TAR, ZIP and 7z archives (runtime)
Changes:
 unarr (1.0.1-1) unstable; urgency=medium
 .
   [ Alec Leamas ]
   * Move to use fork at https://github.com/selmf/unarr
   * Handle regular releases at new upstream
   * Drop all patches besides a spelling error.
 .
   [ Bas Couwenberg ]
   * Update watch file to handle common issues.
   * Update upstream metadata for new upstream.
   * Update symbols version to reflect new upstream releases.
Checksums-Sha1:
 d1ce33d17dc95f8ae82898d20c7b034e9d51f871 1964 unarr_1.0.1-1.dsc
 604c3771e48037539131c169ffed902a370fba5f 79492 unarr_1.0.1.orig.tar.gz
 55116a12ed8fb794128e6db2b773d6dd924835c7 3792 unarr_1.0.1-1.debian.tar.xz
 befc97b34342bd8fbddbaaa847dc3eb96ca586e2 4856 libunarr-dev_1.0.1-1_amd64.deb
 96c963848531acbc060be208b98aa06135abfc15 172152 
libunarr1-dbgsym_1.0.1-1_amd64.deb
 0b2dea1ccdb3d25ecbb7f98b90802e8e06c2dd4e 51064 libunarr1_1.0.1-1_amd64.deb
 a6b9486c73a348e6e01ce7067a396dd2646b4316 7669 unarr_1.0.1-1_amd64.buildinfo
Checksums-Sha256:
 6c74079b51caaf20198ba4ec49fa671a4635547be21cce20a13e8f413d431a62 1964 
unarr_1.0.1-1.dsc
 0098e3f33182d16c13eb21278696651b170360a9a4d1c0214db4bd7882253223 79492 
unarr_1.0.1.orig.tar.gz
 4b4070b8d4e72f992f0cd77963192bf325212fb893d223bdf67942d898e56f0c 3792 
unarr_1.0.1-1.debian.tar.xz
 414458c1b462954db0c8af83bf4bc4bea2bc2fb9ae3e2b8a3df7f244a2aed576 4856 
libunarr-dev_1.0.1-1_amd64.deb
 02df8540437e6939c15170e2390c4ebadde7ddaf277158d6b603ceeaf5165b91 172152 
libunarr1-dbgsym_1.0.1-1_amd64.deb
 54e6c07da15a8044fb878c2db635f2e621e42d547e36e1d91abf74a5ff5e31e6 51064 
libunarr1_1.0.1-1_amd64.deb
 bdf18e765e9fca9d4dd8efb61c0583f091e562866b02ab2c477959738e2b4447 7669 
unarr_1.0.1-1_amd64.buildinfo
Files:
 b62d3536623bedb08aed816a9ae1b8d3 1964 libs optional unarr_1.0.1-1.dsc
 941c66235a4a1738bff1e76397329c65 79492 libs optional unarr_1.0.1.orig.tar.gz
 4ee002b650dc387362d3540e1cef6ae1 3792 libs optional unarr_1.0.1-1.debian.tar.xz
 337961cfe3c2886da4b8c5974b1760ba 4856 libdevel optional 
libunarr-dev_1.0.1-1_amd64.deb
 2e9cbf46eb22dbae7d19e65be2993b6b 172152 debug optional 
libunarr1-dbgsym_1.0.1-1_amd64.deb
 5bfed753ad9687821d76b723d9140585 51064 libs optional 
libunarr1_1.0.1-1_amd64.deb
 053335665bac9e37f07bdd3d47b94f6f 7669 libs optional 
unarr_1.0.1-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEgYLeQXBWQI1hRlDRZ1DxCuiNSvEFAlu94lMACgkQZ1DxCuiN
SvE1nw//Urqp9EYurTZw2O6V8YNX8yXGT5eS9lpxvZUNRC3kHfPgbAKpQEpO0JJA
TYJ5KrBUToGm3KXpuwDmWa+OENt1fBzUdiGsNven9M3n7UWPZGHGQ7mmzoEo0ov3
3ZloKr9VBwYev6F0TYfTiTTrfnUwZwkONXszgXXPkfjFCCn7oCxUUH6KqYFs/8G6
H9IZkpLByEBBFpASvXNPRHsTxe7u3G7SHLoYkuHy5Ci5X+rnvTvGWdZMzIj09oYC
msk8O/tuECGhsbR0bzEUYMeZvQOp7xevvBRKNBhlzfJn/9zorc53PIDIUAS2ZzbQ
zabNfxlE3oLK3r31WTM8K25SBKCoZps+7AzbDM70Y1hRav3a/cJXrcTNQsxe1zqY
xTPSI4Aqw7Krig5g4MS6ydrvRdXb8wv0P6Fanxa2smdYr1ufgNzu6DkurBHDAO9C
uL+k9DyCYdkFctQZaLJnFc9cJtmgVwHU/3oRiSzgK43FpesZshehm/Fe/atb4sv6
sEXJovOxiWgaQ31ogSmexBv7fhIf/a2IIDAnIHo6zKZ6i1SMlxfGF/FxtqRjidC8
83IoRS0Ql5PjudvhIe+0uXyK6tvrgW2hNKcV9Ds0FCD4mNzTnsD/tpDuUNFmKwY+
n2IPW5bUtkZ/Bj5dZcfuKIN9PACOFyFDDNiN/BTC/n6YXye5Pl0=
=JP1Z
-END PGP SIGNATURE-

Accepted unarr 0~20150801.d1be8c4-1 (source amd64) into unstable, unstable

[Alec Leamas]

-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 
Description:
 libunarr-dev - Decompression library for RAR, TAR, ZIP and 7z archives (devel)
 libunarr1  - Decompression library for RAR, TAR, ZIP and 7z archives (runtime)
Closes: 907070
Changes:
 unarr (0~20150801.d1be8c4-1) unstable; urgency=medium
 .
   * Initial release (Closes: #907070)
Checksums-Sha1:
 70219dc51e7dbae1c802a8d9d6f3e23f2cfe5571 2056 unarr_0~20150801.d1be8c4-1.dsc
 af994564b3b14891da0c5b18d54eff4ec15ed255 59152 
unarr_0~20150801.d1be8c4.orig.tar.xz
 45fd846c3617c6dc7898baa5d6eaa861d4395a3b 6572 
unarr_0~20150801.d1be8c4-1.debian.tar.xz
 59a92c7df4c50b94941255bfe9b7dd90c0704453 4024 
libunarr-dev_0~20150801.d1be8c4-1_amd64.deb
 034b03eef7724269ca401d30e42ca5972e8b8abf 168616 
libunarr1-dbgsym_0~20150801.d1be8c4-1_amd64.deb
 aba0963b39043dd520b945590a9e553ccb63995b 49484 
libunarr1_0~20150801.d1be8c4-1_amd64.deb
 8033270b2649c3769e99f1500c989e7e60a3276b 7918 
unarr_0~20150801.d1be8c4-1_amd64.buildinfo
Checksums-Sha256:
 2a43d4b6c25ff0af80611fcdd39e264a8a55576de540995204a596e1428ecb33 2056 
unarr_0~20150801.d1be8c4-1.dsc
 97fd5714893a734b57055f884fc9562b4c012b37a2ee98eccdcd766ead48361b 59152 
unarr_0~20150801.d1be8c4.orig.tar.xz
 5664f9c25de91206a9d3d5d18ca9f9a4c7aefda389350d75ad08b23f9c816812 6572 
unarr_0~20150801.d1be8c4-1.debian.tar.xz
 af2e51936b6bf1b713696b521ba6a1b6276af7bba959a819d563e610b2a9043c 4024 
libunarr-dev_0~20150801.d1be8c4-1_amd64.deb
 546f5fbee34c4196af46dd449ad9c8e218557daa368411d9f9475bf713c1a36b 168616 
libunarr1-dbgsym_0~20150801.d1be8c4-1_amd64.deb
 815909509d4fdd0c9b45b406c07b1db569825b5f4946949eff6128574d18a648 49484 
libunarr1_0~20150801.d1be8c4-1_amd64.deb
 63cf373f9589c8c1d7173d783821cb88aa0cc07a7581907a807f2573f974d6b3 7918 
unarr_0~20150801.d1be8c4-1_amd64.buildinfo
Files:
 0e80faf62f73d733b634baa64df412a0 2056 libs optional 
unarr_0~20150801.d1be8c4-1.dsc
 2941bbcf1e1659e189a7805ca179b88e 59152 libs optional 
unarr_0~20150801.d1be8c4.orig.tar.xz
 0ee2a5b2bcf349cbacbbdb51564630cd 6572 libs optional 
unarr_0~20150801.d1be8c4-1.debian.tar.xz
 fa7356585d72ce881e17e296d8564d4a 4024 libdevel optional 
libunarr-dev_0~20150801.d1be8c4-1_amd64.deb
 c25c7b4f48789a2bf9bdf47f7d5b327f 168616 debug optional 
libunarr1-dbgsym_0~20150801.d1be8c4-1_amd64.deb
 c23f9256b9af35cbb96337451e6ba6a3 49484 libs optional 
libunarr1_0~20150801.d1be8c4-1_amd64.deb
 d6e79ac034d502a75d91fa9c4d129927 7918 libs optional 
unarr_0~20150801.d1be8c4-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEgYLeQXBWQI1hRlDRZ1DxCuiNSvEFAlupEz4ACgkQZ1DxCuiN
SvFcehAAmimEdXsNA6cHiurcyhe65O0RdBnUHOgzJ9+h8wf5Ne09etKNXBZJAfcm
5w+xoHPg6q6aifd0D26u+OCIaJ0i2ZVFA/RFM2lU+6Fj4IrHixlJtEsfthn4n437
aLfFYg4sBx+Jo70DlHH2lYo9/D4VyXLrNRZCV3YcMzwoNP6fV1Au/HvYXkhjfSy3
BOLGuWWdN9wKpxaqGfk/rWR5kORrRA167A5isdnMIKOK4w1tH7kWAzrhotn57bn2
sj4mNJF58eSvXPp9e2dtVXUrfIWa+bSZPrdKAlc/jluLcik6iumzSxUn74uKmDwA
umtBpBgz/P2sAJTidInTNSfAeSlAhSBVBwBqZ+l/VgOWOqTl5LiBOYYG0bse+6BG
s5WVMAPHGortNFe4+KovqH1H96VXFztYT47iwOnwjpErv6ZT86weuB6rklmqaiqJ
NdfOIriGXyrSc5aTYEViVxAixqyEc9b0KMDpHM5W5JR+pa4tFxS8A24Lo7yhcpo7
Uct9IoL5ZtAQaaK1RKpVqyU031TCW5B0gfI5B5Zl6vQoqEK6kPO283eOGnBYw0NW
wNALJOE6Dom8HFm1jfe9Xj5yLxR3n0xdXWvlLD4DLslirlas//XRAruqRwSUqFGL
xPzZx2CotcUuFVbFcmtfMjfOPZBJ1LF8YXB6bKScYVr1c+QEtYk=
=6n5T
-END PGP SIGNATURE-

Re: Q: Debian position on bundled libraries

[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]
>> application won't be packaged in Debian. Upstream is very clear on this.
> 
> Please note that I only mentioned my personal opinion, in practice
> Debian's opinion is that bundling is fine, even of unmodified stuff
> that is already packaged and especially for modified or unpackaged
> things. There are tons of code/data copies in the archive, many of
> which are registered with the security team (see the wiki page linked
> earlier) and many which are not.

OK, if all agrees on this I would be happy... Note that the approach in
[2] is that we are trying to do our homework and unbundle things we
"can", so to speak.

>> the embedded communities would really need a pure Debian package.

> Hmm, why would Flatpak not work for them?

Flatpak isn't that space effective, the downloads are large. Multiple
downloads are de-duplicated, but it's still a lot of bytes. OTOH, it
could be argued that any system using OpenCPN needs a lot of storage for
charts. But still...

>> Fedora today basically allows bundling.
> 
> I thought they actually had a similar policy to Debian; if possible,
> try not to bundle but if you cannot avoid it, fine. We only use
> "should" after all.

Perhaps not that different from what you describe here [1]

Cheers!
--alec

[1]
https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries
[2] https://github.com/OpenCPN/OpenCPN/issues/1124

Re: Q: Debian position on bundled libraries

[Alec Leamas]

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 example is mygdal, a heavily patched subset of the gdal
>> package.

>> So, before proceeding with this work I'd like to know how to handle a
>> situation like this. Under what conditions (if any) is bundling actually OK?
> 
> Personally, I don't think it is ever acceptable.


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]
application won't be packaged in Debian. Upstream is very clear on this.

OTOH, it will be available as a flatpak package (sandboxed, FWIW) which
should satisfy most users. But the embedded communities would really
need a pure Debian package.

I also note that this was the position in Fedora (some years ago I
actually felt that Debian was more flexible then Fedora on this). Fedora
today basically allows bundling. Fedora is not Debian, though.

Cheers!
--alec


[1] https://opencpn.org/OpenCPN/info/newspgI.html

Re: Q: Debian position on bundled libraries

[Alec Leamas]

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 way, but my guess is that we don't expect
> someone to do hours of work that'll be a pain in the ass to maintain just
> for that, especially if the bundled library is a patched set of the original
> one) properly, it won't be a problem
Looking at [1], do you agree that this is along these lines?

> That said, you'll have to reference properly the d/copyright file, 

I have updated d/copyright in [2].

> and you
> should probably strip out all trivially out-strippable libraries that are
> already packaged in Debian or packageable by themselves.

... and be done with it. If we could confirm this, that's what I'm
actually looking for. In a previous packaging attempt this window seemed
very small [3], but there has been water under bridges since that
discussion.

> [1] https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

Yes... but the interpretation of this is the very issue here. It's IMHO
far from crystal-clear.

Cheers!

--alec

[1] https://github.com/OpenCPN/OpenCPN/issues/1124
[2] https://github.com/OpenCPN/OpenCPN/pull/1100
[3] https://lists.debian.org/debian-mentors/2011/05/msg4.html

Q: Debian position on bundled libraries

[Alec Leamas]

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 patched subset of the gdal
package.

So, before proceeding with this work I'd like to know how to handle a
situation like this. Under what conditions (if any) is bundling actually OK?

I deliberately avoid the "convenience copy" term used by the Policy
Manual since i think the term bundled is more accurate here - the plain
copies are not a problem.


Cheers!
--alec

[1] https://opencpn.org/
[2] https://github.com/OpenCPN/OpenCPN/issues/1124

Q: Packaging headers -> need for -dev package

[Alec Leamas]

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_plugin.h which thus i srequired when
writing plugins.

For me, it's natural to package this header in a opencpn-dev package.
However, when confronted with a "citation needed"[2]  I don't find
anything written on this. I see three possibilities:

  - I'm plain wrong, there is no need to package the header
  - I'm right, but it's just common sense.
  - I'm right, and there is something written on it somewhere.

Thoughts?

--alec

[1] http://opencpn.org/
[2] https://github.com/OpenCPN/OpenCPN/pull/1102#issuecomment-414138655

Re: Q: Packaging wiki documentation.

[Alec Leamas]

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 talk to the OSGeoLive people, who kept the opencpn package in
> their Ubuntu based distribution.
> 
> You are also very welcome to maintain the opencpn package within the
> Debian GIS team. See our team policy on how to join:
> 
>  https://debian-gis-team.pages.debian.net/policy/

Thanks! For now, I'm focused on upstream changes [1]. Time permitting, I
will try to fix these parts first and come back once the package is more
consistent from a packaging point of view


Cheers!

--alec

[1] https://github.com/OpenCPN/OpenCPN/issues/1113

Re: Q: Packaging wiki documentation.

[Alec Leamas]

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 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 process which relies on 
>> administrative privileges to the docuwiki instance.
>> 
>> After pushing the generated docs through the packaging toolchain 
>> lintian rightfully complains about missing sources - in this case,
>the 
>> wiki markdown files.
>> 
>> I have no experience in the docuwiki tool. At a glance, already 
>> getting the markdown sources seems non-obvious. Even if I had the 
>> sources, I see no path to rebuild the docs as part of a package build
>
>> process.
>> 
>> Is there any experience out there in this situation? Or just some 
>> thoughts?
>
>You could try generate the documentation with Pandoc.
>
>
> - Jonas
>
>-- 
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
> [x] quote me freely  [ ] ask before reusing  [ ] keep private

Alas, pandoc does not support docuwiki input

Cheers!
--alec 

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Q: Packaging wiki documentation.

[Alec Leamas]

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 archives about this as well as
>looking at the old packaging repository for it.

I have seen the mentors discussion, thanks.  For now filing multiple upstream  
bugs and PR. But where is that old packaging repo? 

Cheers!
--alec

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Q: Packaging wiki documentation.

[Alec Leamas]

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 process which relies on administrative
privileges to the docuwiki instance.

After pushing the generated docs through the packaging toolchain lintian
rightfully complains about missing sources - in this case, the wiki
markdown files.

I have no experience in the docuwiki tool. At a glance, already getting
the markdown sources seems non-obvious. Even if I had the sources, I see
no path to rebuild the docs as part of a package build process.

Is there any experience out there in this situation? Or just some thoughts?

Cheers!
--alec

[1]  https://github.com/OpenCPN/OpenCPN
[2]  https://www.dokuwiki.org/

Accepted ddupdate 0.6.1-2 (source) into unstable

[Alec Leamas]

-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 DNS data for dynamic IP addresses
Changes:
 ddupdate (0.6.1-2) sid; urgency=medium
 .
   * Fix packaging glitches: standards-version, whitespace
   * Add missing debian/upstream/metadata.
Checksums-Sha1:
 b2ff4a52051a3508f2a5423f4a909ecf3f5b7380 1884 ddupdate_0.6.1-2.dsc
 c67208b902cd43d3a03d1a45ce7cefaf3570eaaa 33717 ddupdate_0.6.1.orig.tar.gz
 b8df09f20f539f4d87a0686c36fd3f33ea5097ad 3260 ddupdate_0.6.1-2.debian.tar.xz
 0ff57f0586f1d1fee0428d86f3e3a1bb026d006a 6061 ddupdate_0.6.1-2_source.buildinfo
Checksums-Sha256:
 dd0dbfef03a865c47c00994371298cd46fa5663f7b1a33ca24c4f38f3e4a407b 1884 
ddupdate_0.6.1-2.dsc
 85c098b605ea5fa00714000eeb938b93efccc3de1954d5f57930e97ac2ef928b 33717 
ddupdate_0.6.1.orig.tar.gz
 60b3fac9e4c2b49643c649f09cfb9db2e4261946ee8db656f01f4201be64188d 3260 
ddupdate_0.6.1-2.debian.tar.xz
 ac6fe8e2af1e511e34ec46e6ed01679477f41357d1ac9340731346d22f18f517 6061 
ddupdate_0.6.1-2_source.buildinfo
Files:
 6c4c3afd9f782b6019795a48b450289f 1884 net optional ddupdate_0.6.1-2.dsc
 1fd165f4d7d2388c2e380e62ec43b0a5 33717 net optional ddupdate_0.6.1.orig.tar.gz
 b7ba4596320f09e913d75111ec3917a8 3260 net optional 
ddupdate_0.6.1-2.debian.tar.xz
 226423a57703fec9151cbcc5f9acc694 6061 net optional 
ddupdate_0.6.1-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEkjZVexcMh/iCHArDweDZLphvfH4FAlsiW34ACgkQweDZLphv
fH7nExAAyn5Vu5r9k92TxSynwOd4sZTsWukxzCQbRPdax3FcrKfFfoUqVZVGhr1V
65G8mEnVqGxdO3ppeAQD9uknUUHUGOEECMT/WaWYOhMMxdf2SVLACnQ6SiLT94Da
WieSnswaYaWOz9vePsDkxSfpxlUbndqIj/20nlknHCxqeLHrIg9L7A8UuARprUHH
0ZU3MHbVEBftGhfdc8k2xjULagNlGEr76xM3NdBjZEY5nNECCZwyXzHE9vVYFVAO
y0fyrR45U5ojrr6s0KMlEVKwEmn8MWyJsu5ijdBHKwa2Jd5XH2Y4PXwHgXUq+DV9
SjvrE9CVm9WrKq+LPFwF3ZOg0I55C2xvx4UN/4ZAs4/Q2zsRMf+gn/d5uZsrfccL
OLDDP8IvX+KnnK3+oAWvJIcg/2QN7XNubzroKxSZaoVMlpEuHAe7uHuZgxV2w89q
qQASLu7UDBzdnpcgJ/YsymMipf/Mwub+EJr85tC0y7NH6sqo5hPTZyTL8mli5+1k
0t0U8h6E3WiUX7a/YBffQA0+dXIvFxes+EaR/BmCsZwkXh/I7etC2y1MCw3RYlsc
U/sjFSLwcOCxvnqR0uytHHoCUXwS2tz32S/AC8FNv4p3dxQyCnOUzUstTT2gjzgL
dZRmdvd+XV0FJf3qadGHxR/t06l4rb4hZ4auQzh3CvI4RUH8Wc8=
=1aFi
-END PGP SIGNATURE-

Re: Systemd user instance equivalent of dh_systemd_enable?

[Alec Leamas]

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
> system unit files, but not for user unit files.  Is there some other
> (semi)automatic way of doing it or should I take care of it manually in
> the postinst and prerm maintainer scripts?


I'm no mentor. That said, my immediate reaction is that you cannot
really do this at package installation. systemd --user services are
managed by individual users, and the package can only prepare so that
users can enable their services.

For example:  what happens if a new user is added after the package is
installed?

A good package should support their users doing this, at a minimum in
documentation, still better with  some tooling to set it up properly.
Not all users are comfortable using systemctl --user, and some help is
certainly appreciated.


Cheers!

--alec

Accepted ddupdate 0.6.0-1 (source all) into unstable

[Alec Leamas]

-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 <leamas.a...@gmail.com>
Description:
 ddupdate   - Tool updating DNS data for dynamic IP addresses
Closes: 890121
Changes:
 ddupdate (0.6.0-1) sid; urgency=medium
 .
   * New upstream release
   * Support for system-wide services dropped in favor of systemd
 user services. Use ddupdate-config to reconfigure.
   * Closes: #890121, control file description nit-picking.
Checksums-Sha1:
 24da02c49797fb31c3d54e030bd49e7679a7332a 1905 ddupdate_0.6.0-1.dsc
 bbb4a1d44134fe55d42b0e3590ec7a63fb15cbbc 33660 ddupdate_0.6.0.orig.tar.gz
 f2580e3b7d1f52d1c41e6484f8de9a5fe6f292b8 3016 ddupdate_0.6.0-1.debian.tar.xz
 4d6675e3768ced60f1477c87c78310cb616829bc 34060 ddupdate_0.6.0-1_all.deb
 34e12b254d0a5e71947bcebff2bbd88657ff973c 6423 ddupdate_0.6.0-1_amd64.buildinfo
Checksums-Sha256:
 9830ffc6dfe3dfc9aea1746acc4cc0de0cbf830b9a2df90c7bb933078f67149e 1905 
ddupdate_0.6.0-1.dsc
 8dcfa38ef9077e977cbec8e5fec82699a77b95b6f131176eef16b62e98cb3fb5 33660 
ddupdate_0.6.0.orig.tar.gz
 e116419399cd2ae100da30226cfc1de61b7b9115a842dd49e5b8d7abffc0af98 3016 
ddupdate_0.6.0-1.debian.tar.xz
 7f6bb991d4f69df525f0c1e63a80dc871cdfbdc8bde77a097a335b005fc07304 34060 
ddupdate_0.6.0-1_all.deb
 752d2837eb94def8a62adcd57c6d54fc69bbe04ec20bb33ae4a87c0319f33e46 6423 
ddupdate_0.6.0-1_amd64.buildinfo
Files:
 0cec7e424a6d169f412257cd0aca41a9 1905 net optional ddupdate_0.6.0-1.dsc
 734adef53df71d8585f3ea8605ac4fd9 33660 net optional ddupdate_0.6.0.orig.tar.gz
 1d0c48d95d1122af7566a4a42ec4ab6c 3016 net optional 
ddupdate_0.6.0-1.debian.tar.xz
 372db16be9f44aedd130e2c781872610 34060 net optional ddupdate_0.6.0-1_all.deb
 22ed26177d98c98e1b4d2abd199a9bb4 6423 net optional 
ddupdate_0.6.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJDBAEBCgAtFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAlqfs/oPHGpjY0BkZWJp
YW4ub3JnAAoJELAdGnKsjcmhou4QAKS/x5tHBUaC19tX4GqWfXE4o4H5s9yq7iLI
ts0ZtWQyolZnWPyVs3uQdE5BwpLk7AJX9IIATMfBDKYEBqDK2o7NBnoqTTyxE9Ps
fN2622vbwirmF6lzzwRTfq0R2pcB8R3BtxB+UxUdYa7ozlOLXQ3pIxLP0uoeRK8X
0hvldd/QyyhmhlRtBKyHyxZqULh1flPSdxEauz2BdQkRVmi8WVMZGmKrVZQeBxiR
66K2MiFIayfY/5iszKD8fnHaW77MjVIk38r7/OBkTFt7AYx/WyK7zqwMizhdATjo
Iyz1uUo14XGtYDmHFVVleU3ra4UnO+RuTotxSgekUc1ipUU4UgWl2joGObb8fqU2
rVpI/OtO9pwFYklsqEvWlsarNQmn7zBvITYDXFhD5C16AbQTJx/UE2GvhUSvvypN
J4GVgSruc3IfMbHJFKX5y5bR5Wt+/KOn1qxq3Iu+6+jw+nmdFtQr64EmBxqnoxbz
pUuSinMLRl6FcOl3ozW6VXiiKCbEk/BHZ8GiwSV3yOCoOyftjFkvTc+q5rbZNIob
IG1hbDn3hnnohwnaimZ9BPg3kfL2A4pMDSmWnEy+xtW77lCM7iIF87fePx20j3tZ
pw+q1uldwWszA/i+klovoKVNp3U2z+rZBVbrsZOi53LqJ0i4PqhVGIA+13lmzgct
eDQwK7jj
=ofro
-END PGP SIGNATURE-

Accepted ddupdate 0.5.3-1 (source all) into unstable, unstable

[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 <leamas.a...@gmail.com>
Description:
 ddupdate   - Tool updating DNS data for dynamic IP addresses
Closes: 886546
Changes:
 ddupdate (0.5.3-1) sid; urgency=medium
 .
   * New ITP package, closes: #886546
Checksums-Sha1:
 945d81f6f8feccb76c92bfbbe18745c5acc61a23 1884 ddupdate_0.5.3-1.dsc
 bd1257edbdc812aaeb24a63c391984701a246148 32354 ddupdate_0.5.3.orig.tar.gz
 e7604c42e7cfa208d66aa46f2adbcaf33a3fab55 3412 ddupdate_0.5.3-1.debian.tar.xz
 c74c6da3b32b24e1b0a71293b724f91079f4d964 32992 ddupdate_0.5.3-1_all.deb
 4ab86f64e8aa6b88db9f900f78b8db98ce9333f3 5865 ddupdate_0.5.3-1_amd64.buildinfo
Checksums-Sha256:
 f1f45b1adfbaccbae7dc14499abf27bfc2fad92673b6d8ba147a8f1fad49358e 1884 
ddupdate_0.5.3-1.dsc
 c15a74a7a8a69dd951edfcb814d5a37f1d6c5eea9a27aa4fe77b82b2b0c7c26f 32354 
ddupdate_0.5.3.orig.tar.gz
 50ba4e02013b148eba6ce22f4e8b38d48a7c093ce08301704605f20ddf42623a 3412 
ddupdate_0.5.3-1.debian.tar.xz
 f678268d263641e2b57458a5f81ba88b00a75d14f26bb7b06e5c315a52ed3d9c 32992 
ddupdate_0.5.3-1_all.deb
 894eda837c11551498654d7b5c63df88a163721a818602e6e376f32b1ed1cf7d 5865 
ddupdate_0.5.3-1_amd64.buildinfo
Files:
 11e4d9cb88cd09d19a82c8cbb0e254f7 1884 net optional ddupdate_0.5.3-1.dsc
 92604dce027f793ec12550a92ade8c89 32354 net optional ddupdate_0.5.3.orig.tar.gz
 756eab8d8283b6cac1794517da817bf9 3412 net optional 
ddupdate_0.5.3-1.debian.tar.xz
 9e6483e328e38aedda9ae6b88f80bb74 32992 net optional ddupdate_0.5.3-1_all.deb
 5cf39602e6f26280db156f181c25837a 5865 net optional 
ddupdate_0.5.3-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJDBAEBCgAtFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAlp8HDMPHGpjY0BkZWJp
YW4ub3JnAAoJELAdGnKsjcmhLXMQALQXFBIbJ7aVJ871rpVoHl0c/T800bQYqyai
7aDZHh3dlovp1vrMV6+dDM0yBxnpJH5MO5qZdWsh+a+Vya/NvbisVTy3jvtNU89+
vQtxEHAeMWsIOwj+z0jnH5eZTgKabspdgscM+DBEpJSK5Y4yYh5ijq3cY44fiqOl
UVK0Cyn8/rerNIpFlVmsOAwjFWA2esCqZdEVS05rMbJso2iwxxxt4snNWpXWI1h3
uKO9VUL3x9AncpmL0c7MpKgbcNnGGcYM2VzPeYq8mY7JeMcgOwF0IVKkLq0u9AsQ
EwMy+4V3xp4z0GMxDNlgLeMry/er/IHJtFxbW1dX1nQbAdGCKMxW12DUKD4Uv2GY
/tPOOrWoEsFbnWL+c4M5BlBKWKut+6rbgV5TLp+/+ONT71LAv3FJJOq43VjyRtRD
4zjmjLjjxB4vnCTPwj+Xin1VAh4bAwpY62yzTluNHljO4p//+m9obPq1+d+9eSlb
PYFAv7SNI39TPpm38O2R+hJEj0oUHjGUpieqYzvLRvbp3snalVQNEm1oj9eAcB/F
wjWrjXnQ1BuO6ui20rN+cV3yaAb7HZGEdYOdsMqzUFVwJlvpQIQZiBTMGVJhXHuo
OAFgUSu+haNBLyWVwVFTB+d7Kancb3wZwvxrDH0EfmgPLeNJ+/gpGGY+PZUgrcqI
vMcKGWUp
=jYmZ
-END PGP SIGNATURE-

Package review: ddupdate.

[Alec Leamas]

Dear mentors,

Following the checklist for new packages on debian mentors FAQ [2] I'm
approaching the review point: "Ask on the debian-mentors mailing list
for people to check your packaging..."

So: Have anyone time to check my package ddupdate[1] for errors and
mistakes?

packaging-wise, ddupdate is a small python3 application with very few
dependencies.

As can be seen below, this is the second time I send this message; the
first time was too early.


Cheers!
--alec


[1] https://mentors.debian.net/package/ddupdate
[2]
https://wiki.debian.org/DebianMentorsFaq#I_want_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's too early to ask.
>>
>> OK. So, what's an appropriate time to wait before asking?
> A month probably, especially for a new package.
OK, good to know. Thanks!

Re: Bug#886238: closed by Bastian Blank <wa...@debian.org> (Re: Bug#886238: Please introduce official nosystemd build profile)

[Alec Leamas]

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?


Cheers!
--ale

Re: thoughts about freeradius package (especially dhcp)

[Alec Leamas]

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

Accepted lirc 0.10.0-2 (source) into unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 13 Aug 2017 09:45:34 +0200
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.10.0-2
Distribution: unstable
Urgency: 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
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Closes: 872074
Changes:
 lirc (0.10.0-2) unstable; urgency=medium
 .
   * Fixed missing media/lirc.h, closes: #872074
   * Fixed VCS browser path
   * Fixed upstream bug #294 (VPATH build issues, in -1).
   * Fixed upstream bug #295  - lircmd non-existing socket writes, in -1.
Checksums-Sha1:
 9e20e94f4496d7a9f72d7daefd080390e63a2a1f 2655 lirc_0.10.0-2.dsc
 c873a368f83f9019ec67fc9ee8e40fb227a12f15 34044 lirc_0.10.0-2.debian.tar.xz
Checksums-Sha256:
 ce6aecbaa9e0e17287cef1139d630c51c4aac544b11b5fb07ae489862c4d9923 2655 
lirc_0.10.0-2.dsc
 3fd645e42300166e327ee56422ec69e2c4658e769b5d96ebfbc83570f23cabf3 34044 
lirc_0.10.0-2.debian.tar.xz
Files:
 6739c4e7bbad797d89fc8f9ad7a25ada 2655 utils extra lirc_0.10.0-2.dsc
 5c510daaef540e3b38f631b3d8ed7384 34044 utils extra lirc_0.10.0-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJZlR1RAAoJEPNPCXROn13ZVy4P/31XD8tXbr6OrbloOYRRR6H0
Wd+8fhLor0HJwPY0jYaDXi3si6X/Z3GvyVxZGju/vtPPi69jCWcT4qwu6OmTaq6R
aoL3zkRxPvNnDfHCQv1QuAPIAbK3xO+3a1Q/9zQEiUuKNtMOrENMENhLEppzC84k
cCX4mRjTVmvUrLn4PULmAcMu/PI9yg/S673qqdQZMXKbKXOLu/5IMHw3lIpmyvKx
0uPXzST1/4qzMCmvdpckOu7lwWzukqocrxW+tqsFChD2twz75jIeWGMYbaQWHHw6
jV3KuMFzSRc97kkTzqyA04rQ09FzCLEI44ZfxVC7Gg462YeyqwdV22gfjchuW/qv
KLDTIs+vxk6TVHm42pESrgIuLxy4Tpjge8Jlz1wHM+szL/I5gDZlL1fVYUB4+PBW
M7JdkkvY/h4EeZEYbnBdvDM5BGQZyd7P1mCSoZfJkRI2NO/7/BVmv7cwkB55O/8p
910i96sP2QdKMSPx2forfAWsxefXydUaOUiz9yNjQce34ftdUKmdvCRudMPEcqpH
oer0gaBP9E9lkSwojfxjo31ou3px25YJis1DtHUrSBNgsCkOZcn6dEKFjq0CHRTa
98PNxMBlh6mynXtjlYrCiVik1QiJx5MIFJJ6I3T0Z1IPW4/OptfrYabFJgYUCWtN
6HLLh3wMkGdladEIu6y5
=8TYH
-END PGP SIGNATURE-

Accepted lirc 0.10.0-1 (source) into unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 12 Aug 2017 06:34:57 +0200
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.10.0-1
Distribution: unstable
Urgency: 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
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Changes:
 lirc (0.10.0-1) unstable; urgency=medium
 .
   * New upstream release
   * Upload to unstable
   * Bump std-version to 4.0.1
   * Drop dh-autoreconf, useless with compat level 10
Checksums-Sha1:
 92d1067ce01ef79917f4f3108e230a08786fcc84 2650 lirc_0.10.0-1.dsc
 a4440d56e79b1ab9839aff162907e3eda09e2c0c 2714857 lirc_0.10.0.orig.tar.gz
 f2010937632c1d37078c0a0c96929a5b1fb42599 33308 lirc_0.10.0-1.debian.tar.xz
Checksums-Sha256:
 8a2a91425f4cb95689ed8920eb439454595d66d8c810e3df577b5db23416c9c3 2650 
lirc_0.10.0-1.dsc
 c1a16fe282fdc0a2a3fdbb4ccdd9a1152b628bb53fe8bfc5a7ad87e4faf58ab9 2714857 
lirc_0.10.0.orig.tar.gz
 8ca30212b893af172523f0d4bd421759d7b0409eb37159b5a4bb46d4423634e3 33308 
lirc_0.10.0-1.debian.tar.xz
Files:
 2ecc426ea7345557168ea5506282f76a 2650 utils extra lirc_0.10.0-1.dsc
 afbc426382a84ecfbe18aeff5b3abe25 2714857 utils extra lirc_0.10.0.orig.tar.gz
 43ad14d0f3f6d8d82fe821100253b723 33308 utils extra lirc_0.10.0-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJZjvz7AAoJEPNPCXROn13ZJiQQANLv5bn8NIwrplPOS7MBqLkT
Ju1X2B9Lw/KSemN3Zfqh3HOCdoHKwSa4g81qJwX0tZxiVUSEoqPvpq/xFnX6E1mS
Zm/teCdb2IoyPvSG/aRmrbMGYy6mSRD23M8a6IxW0lJAeTH9MENlXCEnILPRdLiC
jV0T6t4PSLjwSQRFqFGyQcEjBGg1jDiGMi4r3KcYgWVEknD6AwZ0I2oqrEpEwymv
9NOiUZd27PJMDuq1sOK9kFhiRNLZfiu+hYxvbo65okpLt1SvnmNSdCCjhpSlupol
+4g8LB7veW52enAxDtqY5Pp+3M1yMdqjNn8/HiYJZT3zh3VFa/BDD1K9jY2IVu6v
wq6EqsYBP30kBAdrdwzoiqMthKbVp5stbycY0AtbpscY0Z5SpRJX8PzIR54wMwZ5
D2U7OBp5WKzgHvwv5KFWiTRrGZ3rvSO/yO/uH3PnxWGsWPAwhasAnYPT694atvUq
rC9ntFTw+n+lEcRxLaY1Qy9yOI1Fxn7ZPU55rjDS1oSS3NgeYeKXvfXPE/QFRLMO
nelXjUtRjjvkklaOkHP1/jF8xgXqMdhKW046TbRfJs0XciX9sZ2jBkLJm4XTB9gE
onMco9QCSaHBcNcXKrnk8VVOKsEKMoDcsL6FDlyMtvL/92Xow2i/4RwwJ+GTO9R2
p8x/xOxRU2sPuQNSd8yd
=Opd0
-END PGP SIGNATURE-

Accepted lirc 0.10.0~rc3-1 (source) into experimental

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 22 Jun 2017 12:22:52 +0200
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.10.0~rc3-1
Distribution: experimental
Urgency: 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
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Closes: 860065 860551 865376
Changes:
 lirc (0.10.0~rc3-1) experimental; urgency=medium
 .
   * New upstream release.
   * kfreebsd build fixes.
   * Remove lingering /etc/init.d/lirc, closes: #865376.
   * Fix absolute path config files, closes: #860065 (rc1).
   * Suggest stopping lircd in devinput "No device available" message,
 closes: #860551 (rc1).
Checksums-Sha1:
 534f49bcc4e31d8e7c2d66cd5b68da1509a91939 2693 lirc_0.10.0~rc3-1.dsc
 1f4f880e1a6187bd3bba7482b0dcd18360ef5722 3562736 lirc_0.10.0~rc3.orig.tar.xz
 bc26f7dcf60672888249a83a2294521e8652d2b4 33124 lirc_0.10.0~rc3-1.debian.tar.xz
Checksums-Sha256:
 1fcaa301632ce2690d848e01228ebe58450bc664f37b049e465403c48c2c8433 2693 
lirc_0.10.0~rc3-1.dsc
 4e1bebb403b398338669f40b01f30b1818487365f271eb3443590e2070acc096 3562736 
lirc_0.10.0~rc3.orig.tar.xz
 56becff95fc5413485aeee5639ee4a700ca42ad8fcb4b78a85ad0e908d96312c 33124 
lirc_0.10.0~rc3-1.debian.tar.xz
Files:
 6409894eaa7da8ac4923c4988b508327 2693 utils extra lirc_0.10.0~rc3-1.dsc
 038d554e3a19e70e3e067af262e8b3c4 3562736 utils extra 
lirc_0.10.0~rc3.orig.tar.xz
 8b9d28439e156455038c28d6188fae8a 33124 utils extra 
lirc_0.10.0~rc3-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJZTODYAAoJEPNPCXROn13ZCg4QAL9xJXAcR0t56lffrUnTWOVe
2jUydkKNLD6xXUHcQcRYgCYEaHercQcaCRdjIc6v+El4dDupEszBkbiHzLP/vz/R
rhR0e6Lp8jon3LoTz57gBUZnYQW0oEfemVq/ZcYrqZ6bqbfIAVHyp+R3iNRZDKJS
OXfIjXs7fC+DNA69S8wVdV/9PTAYRnNjVY7cHDIUz99TM6VNStsMS+OaVG/QOqFS
qt1LhiboVFmxCqwtif2NE54pPrquNMVJBPdkVwfdSJ09LifU5SzWj8tI1fLom/DH
spvZ6fT3bZ4BYSmkWLQbP3BvsBEtCQqZ9l2obs5/FqlRCM57Y1DocP0KuXcy06sd
MNre8QVS2f5eApVgu04iBST6iyVp53NLtjsI2x+ONJLTHuTVSL73XeHObFA9x8c8
YS4QA/02GQDWhyXf30N9PPCLrXnCcp7sBQ4MbHA2JqS/4lFh7AOW+lhbIwuUS8gP
ZuiPl36ANWW5C1NeuW12RTrV0FcLBWTlqm4NAXdM2K55mbx7dA6Fe7ocva6tfYag
iDRP3jNOGyr/4zMSNOMpCAQS6ZmgcLGbQUCXEGDyhZGryEDF6WdwGjLPTcSut0ku
Kdg7bN5KoYB4bYGd+LYdJK6hmJ189xEZn8IkDmDbkwZZITbLp95FXj0BliLeINnu
qI/2ulFNgoUCYlGsUNO6
=Ci8X
-END PGP SIGNATURE-

Accepted lirc 0.10.0~rc2-3 (source) into experimental

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 14 Jun 2017 16:35:02 +0200
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.10.0~rc2-3
Distribution: experimental
Urgency: 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
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Changes:
 lirc (0.10.0~rc2-3) experimental; urgency=medium
 .
   * Fix broken dh_python3 invocation.
   * Don't build plugins with runtime linkage errors on kfreebsd.
   * Disable failing python unit tests on kfreebsd and hurd.
Checksums-Sha1:
 1f2d83cc9eca712a85afa834b63e6d36603a8346 2691 lirc_0.10.0~rc2-3.dsc
 9680b0c8a643ad0f7dcb77b486cac1ed4a3e01ad 34408 lirc_0.10.0~rc2-3.debian.tar.xz
Checksums-Sha256:
 0c0f7cdc928c5c7fb3fa2b51c1bcfbf244780f67e1e4b96de8e5362ec26e35b7 2691 
lirc_0.10.0~rc2-3.dsc
 7390ba806d83856eb3602e94a363efcfdc84d0d94881030c18063bde4938f172 34408 
lirc_0.10.0~rc2-3.debian.tar.xz
Files:
 a56517923da30822ff9942870edbeeed 2691 utils extra lirc_0.10.0~rc2-3.dsc
 ddebfb22260d51049025dd388072fc95 34408 utils extra 
lirc_0.10.0~rc2-3.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJZQlYSAAoJEPNPCXROn13ZvcUQAJ4GoNHKjFaCuqEYsd1BJSI8
AE2WEaQUN/vWRr1cxh6LoMbf34UCYlkoAfTYn23I8tq7gQtgifJOv5+GBSfqd+Ln
K0/iQfGqfd1R3/UZYkm9mB4zPYiv/YWufzgrAyMmDarSuVfryQSPs1rolbOqdmsq
W+MMqeY1QhlytH6VFqzKoZa5HF/fWr8GIy32hQVuTfoTdAPkD1mCuqYEze56PHm/
mjGDW7P/wugAJDevtuwKdBLlqEvXFHVEgK0a3B0RXOwnusWQAX/3ikRRcJRrO4DU
TMYHJzMzHtkAcGWflCONo8Y7UdjcYx1m1jMxgIu7qkOqN/s4EsZqNfyDD3h1R2pE
c8QAn+n6qU46ew1FPix90KP2V1yCOnRq0BNNWTqMFeXQsieh3GxG3yN99J1qf8QU
muoZB/CFAAubqQb8NhmuJ2VeYARyxOaGOG2QN9jWZIWiRmfa/xssH2OD2Ztboing
3EOSHGSsZgg8AITXSJmWUc6++p2+RY9Ggv0AaQVvP+yyWx739NpIWG6vXBk6UVis
fH886pqBlo65oHbvZD9G9aHVl17a3weVWW1+hJXUGPjbGPcGdKu16lqr8tm/L6cA
uIgXKXt/gOIuLnmBz2J54zeNS/Lpt0TAOzOGSIZX3M7IwazEfJD4JXGGMCVNQ4j3
8nN2E4iHTK9Pthy/kIXx
=ZdgR
-END PGP SIGNATURE-

Accepted lirc 0.10.0~rc2-2 (source) into experimental

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 13 Jun 2017 23:24:50 +0200
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.10.0~rc2-2
Distribution: experimental
Urgency: 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
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Changes:
 lirc (0.10.0~rc2-2) experimental; urgency=medium
 .
   * Don't hardcode paths to socat and expect (test tools).
   * Don't require socat for hurd builds.
   * Don't run tests if socat is missing (e. g., hurd).
   * Limit plugin load tests to look for errors.
   * Fix broken dh_python3 invocation, add missing ${python3:Depends}
Checksums-Sha1:
 d944e6244ed9b7709b195e6620211d298428b468 2682 lirc_0.10.0~rc2-2.dsc
 9b56cf0f7e439ca677eeaf23d14b5cd1bd0f45ab 33748 lirc_0.10.0~rc2-2.debian.tar.xz
Checksums-Sha256:
 1fa73b564682598516daaa289faabe76608de742139e0564befdb4e0dfd6b977 2682 
lirc_0.10.0~rc2-2.dsc
 1e297f02ad8303ec1134c857b4122f3a9bfd63a5dd38a8bb26df6c364c1ef979 33748 
lirc_0.10.0~rc2-2.debian.tar.xz
Files:
 d1a1035333fcbfa67d22646a9e1303ff 2682 utils extra lirc_0.10.0~rc2-2.dsc
 16968474c3193189eca09d426cbd19ca 33748 utils extra 
lirc_0.10.0~rc2-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJZQOhEAAoJEPNPCXROn13ZgxMQAN6QaPaKUg9ExAY7kiVL0gWb
1jfWnnIaww267ZH8xg5D4JTyoOTF92dFSxCeeiRCkmCV9sb4gnS7C3bzrVTFFiwk
ZiBnouTu5qoDpYn0/+/uRTMw1FnyQORmNvKYDm9L/CuGi9NEMQeztkZmDK6iKizN
Mjsx6x1FwIDL1ExqxWxu6vY0Bf/djCxqZg/ZgfabkV49HhzVeb7PM1vLt6Z1gfx6
8G3QN3dJcSI1SppKmwzJrISMBNtDVJvWew97H4ghghTmrE/9gXgaxHQneF6PkAw/
UODz5YCgc+6WSFUhmhMr8Y6HURliGLj+1SzWFRyO8ymn2R7YHjo5w8XfC3oQ/aEf
4wRpVGLZzm4eOALoQkGZCRC5DE8TadAIZnpBoOJMKxV2uiC0kTsgtfDOZmMw+gRw
MRiI0BFG7gZno7MNee0HGbL8KysReOnVihUrnKhGBOMs1kivehiJwotBazUXhN7g
FHtBoM7qpgHlOQ6IwgBGRxprh5lvZi+O4zzEllNb+KZoo7mq1t2tymR3nScBR+FW
LEyJPTt4Q4jb2/xRKU3Dv+ViYmqditlXwG3Yc175iF/fihuETtudEZTLm9UG9oNg
HGAnOxmvB6M63/jgDpolX4bpHjh+CJ4MmZHkwCpiSKGAm0+ZuSZrlyRm84SWqy39
Oh9xkU7GbEnDwwf3+MZ0
=sCdV
-END PGP SIGNATURE-

Accepted lirc 0.10.0~rc2-1 (source) into experimental

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 13 Jun 2017 11:51:06 +0200
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.10.0~rc2-1
Distribution: experimental
Urgency: 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
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Changes:
 lirc (0.10.0~rc2-1) experimental; urgency=medium
 .
   * New upstream release
   * Fixes upstream #290, lirc-setup does not start.
   * Copyright changes reflecting excluded files in attic/
   * Minimal testsuite.
Checksums-Sha1:
 e8dcfd3b6e1be12fcc5c99538fd4c0e48ef1cc8a 2658 lirc_0.10.0~rc2-1.dsc
 13ad5ee08bda29f00dae9d600a9659a19e0c5da0 3503524 lirc_0.10.0~rc2.orig.tar.xz
 1d863a81132179fc8f9f009b035726f8d8b149b8 32872 lirc_0.10.0~rc2-1.debian.tar.xz
Checksums-Sha256:
 cc4150cb724f215eeeb94d7ae95398d86b78a04a6bc043bd9fed1dd77f0862e3 2658 
lirc_0.10.0~rc2-1.dsc
 4cfa27b3b2b5d78dca683dd17e2f768b5f44f26c6b89210ce3b703438ac45b15 3503524 
lirc_0.10.0~rc2.orig.tar.xz
 967c49439de5d02f688dc968345d3e11e64b7fe20a272c4b1d8bbf6880bd2f20 32872 
lirc_0.10.0~rc2-1.debian.tar.xz
Files:
 19e0e7c4462006c2518aadb48247a669 2658 utils extra lirc_0.10.0~rc2-1.dsc
 835024af97a238a311c236461b48e03a 3503524 utils extra 
lirc_0.10.0~rc2.orig.tar.xz
 7ffcaa0ed21ed0cac23ac56de3741801 32872 utils extra 
lirc_0.10.0~rc2-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJZQAcJAAoJEPNPCXROn13ZLHYP/28aP26/DyTOhIGSTt6AzUHm
FmPSF+6zAeSl04/nOKZ4g2imrVlJky2eerSIqpI9sCYE9EZW1/fJtvrhJhEWw56g
iM6eHrVpAqf/CI+3wlfBhHkd526Rf8Pbeui+COJfqQ8ACRDIRGq1B7FfwpkAindX
32ULRgwGtlEuT8oi1T+9f0hQr2TYzhoO6AC9sJllqcIN6IiJPsTCOHOgfCrS39CQ
6Hrm53ioBPBow+BWj7KMDQcG1wX0iS45rxjq//bqzI9fpdtJ0FR8BInw+zSMJwU/
xxfe1FgXG/1FELuLT/zLdqaPwDgjtPuJB5ylQWBXbJ0j/AYOh1ite5nOd8twcKoP
YOENpVzWxgvE/6cVRvTkDYjzDFnXLRkAflpYj79jma/zB1TXPex7Yb3G76snyxPK
bOa/XTcvbGfwnlYh925yVQ11IJ9i+QSGA2OhA7CdQ/PnVgfyyiA+xQ0+rfbR0hvi
+fXRzWleL7cL4vMwMvmSq6RuXizuYvwcdUqoDlf5sm5mVHirArkjcAR0bNlADI/a
J7Q+1PR8+qIRwcTNRvYo9TvYA0J1d+gCyhBUKjioRwJA2QgVeRkfUZqEp8dG7v/5
aj9rWaX9VbO8f25mf2oLd9bOQVZpActydrgu45iq9LbnArEk/gpjDWnUdhyD63Vq
yvTFe7IK3QdNzU5yQFAr
=9de7
-END PGP SIGNATURE-

Accepted lirc 0.10.0~rc1-1 (source) into experimental

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 19 May 2017 16:57:42 +0200
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.10.0~rc1-1
Distribution: experimental
Urgency: 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
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Changes:
 lirc (0.10.0~rc1-1) experimental; urgency=medium
 .
   * New upstream release.
   * Most 0.9.4 patches upstreamed
   * debian/rules update and debian/copyright
Checksums-Sha1:
 d51054ff3a07381d1d09a2f7e03fceba89b04d5e 2661 lirc_0.10.0~rc1-1.dsc
 1a7d705d72104b2be2f7adddf999d544592672f1 3549176 lirc_0.10.0~rc1.orig.tar.xz
 2d53886c60f2bdd68f924facb2a7090ef0c24d93 32132 lirc_0.10.0~rc1-1.debian.tar.xz
Checksums-Sha256:
 8eee4f178001ed56681c83b2f69d8a961b9384ced5c74df02d1741e8a9d93f4e 2661 
lirc_0.10.0~rc1-1.dsc
 8c2e72b7545d8bd05646ddc6fbd07b232f42dfe0c19352ff8c5a44769a4ff08f 3549176 
lirc_0.10.0~rc1.orig.tar.xz
 ef0f53cdf1efe8e0b40c35de5fd1dc39cc81395788bd736395a9ae4c53438408 32132 
lirc_0.10.0~rc1-1.debian.tar.xz
Files:
 a57b563ff22c24855cb4d97a2bf4dc46 2661 utils extra lirc_0.10.0~rc1-1.dsc
 31398dc41556aa3f9a7079f177782e4b 3549176 utils extra 
lirc_0.10.0~rc1.orig.tar.xz
 52954ab4205477ed495b1904bfc2 32132 utils extra 
lirc_0.10.0~rc1-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZPtmgAAoJEPNPCXROn13ZC0wP/1o7crxCbS8am1ZtY0MiEORR
x+QRrXNqh7nWYWXvbLK3TMu5GVIdpVF1X0IOfvjrnTS+g+eR6h3upt+9colXOaWT
XJH2qX/PWI8tt1sV2L9XreNAz2NnXj4LjHmV3CkK6KWQZkN7btKNlJSSCZm7aD1u
PNFq9iv2xGKRJomMj1cyX5HeNf061Hf0s6bynejdIxJWLIKZc9Xep6yntzWX7tp/
arcxKwodGmbVEsZEK2ydeK0seXxoamMOA/k2M2wBckDuwK4cAlFP2F2hbwmWQ7rn
49K3sRRmMdEoGL50QO9FCKwgJ2JfklTaVTwgcs/9+bZKUNJWGgSh81GOMLo618LQ
8AH04ZuvlGi++Gwky+tqw5DZboe3OAECHt0jHSDOd1FXYdOiCt4Ot+jIpYueiSJH
nra9g9Jz+PNmGnd5l7ul8y8CTLShDEO24j3QRm7D2hZZTmOB2jXEr098eGppYiMS
H92y/b6/sqd4ebKGxtI67199JM47wxvP9csRHJ/vdyzZf9mYy2/xvdZFYesri0IV
rzVK+iynhSoUMM21MSJ1uFuDi/yks8obtfEL+dQzU9twSHb7pFy0o2wd19J6X1pB
ogYM+WA3cr7mn7NtParHiBULWIjySwKDRGKIxLukboMNHjgsaWlKha4fuIV3Uf36
0UcJWbWT8hSQv93fGHdr
=v62r
-END PGP SIGNATURE-

Accepted lirc 0.9.4c-9 (source) into unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 06 Apr 2017 05:23:20 +0200
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.9.4c-9
Distribution: unstable
Urgency: 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
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Closes: 852118 859491
Changes:
 lirc (0.9.4c-9) unstable; urgency=medium
 .
   * Fix missing systemd socket activation (Closes: #859491).
   * Fix package purge (Closes: #852118).
Checksums-Sha1:
 3cebd727ffeca827c550758332f79f4b7ebafd34 2605 lirc_0.9.4c-9.dsc
 9d95bf6cc9f5c8b9dbfe875befcba74b832d6dcc 42828 lirc_0.9.4c-9.debian.tar.xz
Checksums-Sha256:
 666c276e09d33bd6cd46fe0e93b1236f4af2dbcfe9015cf965eb3ae1cb4a1ffd 2605 
lirc_0.9.4c-9.dsc
 073058f5afd4e0a5072b9df06c9cdb38023ca41225235f5f23989426f1ba461c 42828 
lirc_0.9.4c-9.debian.tar.xz
Files:
 d2feeb18fa5fbb5cb92dbd266f3379b3 2605 utils extra lirc_0.9.4c-9.dsc
 dfc9c4cf7ff6f8ee941206079aea5d33 42828 utils extra lirc_0.9.4c-9.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJY5lHCAAoJEPNPCXROn13Zl+IP/2zHta8KixX971OvL1XYIujj
pZy/wbkaN9OV1sFCVOtnMQTs89xj+dZ03NUXwcayIAYnQLBcY3fsDx3ypG4F7AtE
6hG7PIciuZrwod/lGvsT/Tg9WCKew68JUtBX2lnwLAo1B06IBxlBsjGWvX2PSDWP
xDJKAwgnkuEdWMdXhG+iZryi9/rP2YpOsFCRHrKxrIHnIGKqZlzntx6YYUfkKkn4
X85vZCQyd8arItFb+2LEfuMlR97fEHUofhTvvAVazmKOt3RDtg+wsUwL2c/u8EaT
JLJw5IOxK6KemC5hJw67sZpj0wx9NfTldLbs3R414iMIigMVzSG8gZB+D/8yO14p
Oki/46d++7orKiw9dmUr+jpIZCUzHXS58wPCrwV5PUl/5ZYAZVYO1giK3qZ5t4Ky
mtVkMUDMPV60YUQYI5XLMX+zioTiM/1Y+7M7dg1ugwk/jpXVVP4zGnN6n8Z9Tnca
EbdIJ7v2M2v4Gy6YYt1BlYDPFkFU+kutCIwXTNBC5fEapOKBn7J9lCxflVX1JxqN
f1smbFP29cRtLyOZmQg81xXka7byRS3ScgrEKmMxsiMQow6QTprEj4pXJyW2nLeG
xub6tue1cD5l/00FOQY2EbAVKk8bKyY16aCIZxwAv2sLTI3klmyWmzeewzEr9pWd
L7BenshtH7HSNdf+7tBo
=hv88
-END PGP SIGNATURE-

Accepted lirc 0.9.4c-8 (source) into unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 21 Mar 2017 17:50:54 +0100
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.9.4c-8
Distribution: unstable
Urgency: 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
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Closes: 858144
Changes:
 lirc (0.9.4c-8) unstable; urgency=medium
 .
   * Fix missinng deps for lirc-setup (Closes: #858144).
Checksums-Sha1:
 9e065969e867492c2320d6d3bcecc8c3570abbee 2605 lirc_0.9.4c-8.dsc
 80d9d5962d6816a36f9437ecf33000d5989c5afd 42376 lirc_0.9.4c-8.debian.tar.xz
Checksums-Sha256:
 42e97fb994ae5d72215c1eeffed828bf257093828b8277efeb90b4c2bbce6d95 2605 
lirc_0.9.4c-8.dsc
 f8215cdb16ef9cf8c8d916f65f0e778351d2257b636821b38b1dc20e826b3c49 42376 
lirc_0.9.4c-8.debian.tar.xz
Files:
 dbdfa762679525ae325e1a8c6c041d0b 2605 utils extra lirc_0.9.4c-8.dsc
 16a131dc07610b518921fe569a88dd43 42376 utils extra lirc_0.9.4c-8.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJY1UtpAAoJEPNPCXROn13ZDIcP/jlATHgbqFAa8cNOkGTTceJ7
GuQ43WqQKBlVHKoi0HHrBbOSyGMl3VDumF3ciSy8H5ErGSAPWlo3T82huOmo/yqX
xEsN8CeJbJu9iOF3eHY133oeZhuTuQ4uN4eFHucQcv/kX1D+r2LYAOFTmFORS1hE
5xOCI12oztgiwAVoZ3giv2Imz3EO1S12s21GRaemrlHvtw2wMPWDPPrpkPsvvoGK
KyERXwe81eCB80kecy3iPxag7olr7Fo4QBsxV3PWsSeUL8d/Cm0ZdIL52v4PStTj
3oEMwU9zRgTDAuDWjTsR0WqIJjIWkJWF84m4Hb4DhCIZJkD9ve2JPWJ1QWsyZadn
XZ9mTUkGVMOjoBKdwZdO7NcqmfgNSDTUgvKFvtwOUN3i8ztYS5qqV6jUJKe6PGJ0
zSJn0bEPJX9Yq0SBsdSxZtkXlafPh2q1/FCK+TMQLFCpufpE7jWb0UFtJM7z3L7o
Q+v/FKuKElWcXWUhG4S+EQEOxj+x5W1msl9BmkAm3SZLLcx2wYaIQBSnHk8Zf/x4
hjPA3qRl5Aa58fy+Cj4DGp+SHucQxpzyPHoHYgRRagIWy6zE93mmyll+zc2ZvPET
aXVavDIJEOSkYrUMZ8/OHRBaDWRWf08wZVJMJ8WMSmWRv3laUea6ezNPnjnKZ4bx
iVtVY6Bn0KrflkVfLrlM
=TXmD
-END PGP SIGNATURE-

Re: lircd daemon as regular user => device access problems

[Alec Leamas]

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, but will only be probed by ModemManager if the userBastien
explicitly requests it via some GUI or CLI frontend).


Following the same logic I think lircd should just implement a 
blacklist. This is because lircd always works according to the greylist 
option - it does not access any device unless it's selected by user on 
CLI or in GUI.


/lib/udev/rules.d/77-mm-usb-device-blacklist.rules looks interesting, 
might be a starting point for a blacklist.


@Bastien: is there anything you would like to add to this list?


Cheers!

--alec

Re: lircd daemon as regular user => device access problems

[Alec Leamas]

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 character devices, it's about 
USB-based character devices. Does this address your concerns?


If not, blacklisting probably is the easiest path - I'm happy to 
blacklist any USB ids if you just provide them. Or, if that's better, 
relevant udev info to make a matching rule.



Cheers!

--alec

Re: lircd daemon as regular user => device access problems

[Alec Leamas]

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).
- The lirc user is added to the input group, to access /dev/input
devices.
- The lirc user is added to the dialout group to access /dev/ttyS
devices.
- The /var/lock dir is root:root 755 in my stretch box but this is
seemingly #813703; assuming this will be fixed to 1777.
- lirc user gets read access to all USB character devices using a udev
rule invoking facl(1).

I know that getting permission is harder than to be forgiven, but
perhaps it makes sense to have a discussion first?

The possibly controversial issue is the USB devices. However, without
this rule a large part of lirc users will be forced to painful udev
rules configuration



Can we list USB device needed (whitelist) ?


I don't think so. The number of devices used by lircd is large, and the 
USB ids are not always well-defined...


It might be possible to whitelist "most" devices, leaving it up to users 
of "uncommon" devices to fix it on their own. More work for both package 
maintainers and users, although more safe...


Personally I don't think read access to character devices should be that 
sensitive. The most obvious concern are hardware login dongles. Of 
those, most seems to be mass storage devices; these are *not* covered by 
the udev rule. Neither is yubikey devices.


Also, whatever risks there are we are already taking them when running 
lircd as root.



--alec

lircd daemon as regular user => device access problems

[Alec Leamas]

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 is code from the 90's, heavily user-configured. Running this as 
root is just not sane, and other distros has moved to running it as a 
regular user since long. I want to make this change for sid/buster.


However, running lircd as non-root raises permissions problems related 
to /dev/... devices. Since lircd is configured in all sorts of ways, 
many kinds of devices are potentially used. The paranoid configuration 
is to block all devices for lircd, leaving it to user to enable them as 
required. This is a breaking update for almost all users.


The alternative is to use the Fedora strategy, outlined below. This 
means changing overall permissions for several /dev/... devices. Is this 
OK, should  it be discussed on this ML, or somewhere else?


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 input group, to access /dev/input devices.
- The lirc user is added to the dialout group to access /dev/ttyS devices.
- The /var/lock dir is root:root 755 in my stretch box but this is 
seemingly #813703; assuming this will be fixed to 1777.
- lirc user gets read access to all USB character devices using a udev 
rule invoking facl(1).


I know that getting permission is harder than to be forgiven, but 
perhaps it makes sense to have a discussion first?


The possibly controversial issue is the USB devices. However, without 
this rule a large part of lirc users will be forced to painful udev 
rules configuration



Thoughts?

--alec

Re: manpages.debian.org has been modernized!

[Alec Leamas]

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 that).


Now, you have made your point - it's a valid for certain kind of fixes 
and users. Can you just try to consider the other aspects, such as 
Debian as a project evolving around the idea of Free Software, actually 
prefers free tools?


Cheers!

--alec

Re: manpages.debian.org has been modernized!

[Alec Leamas]

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???



Please, we should not have a flame war, should we?

And, this is not that simple.You do have a point in that the github 
interface is good for you and many others. OTOH, I actually prefer the 
commandline, and there are a few more on this list who also do. There 
just isn't a "good" UX, although there is "good for me" and "good for 
those who ..."


Another part of the equation: there *is* a point using free software, 
and github is not free.


So, in the best of worlds: something as easy as github for a certain 
class of users, and respecting the Debian workflow. IMHO, it will 
happen, but we are not there. In the meantime, we must find out if

the free tools we have are "good enough", which  I just don't know.

Because, as long as there is a free alternative, we prefer it in our 
workflow. Right?



Cheers!

--alec

Re: manpages.debian.org has been modernized!

[Alec Leamas]

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.


Agreed, sloppy wording from my side. Personally, I also side with you in 
the workflow discussion. That said, github *is* easier for a whole lot 
of people, more used to GUI tools and less comfortable with the  console 
than you. And me.


Which also is a subjective view. I have no data,  just my gut feeling.


--alec

Re: manpages.debian.org has been modernized!

[Alec Leamas]

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 github and how to create a pull
request on the web interface, and I can just merge these changes
with a few clicks.


Please don't forget about git-request-pull(1), or it's simpler
cousin, "to fix this bug please merge branch foo from repo bar".


Easy enough for me. But Sean and Bernd has a point,  the github workflow 
*is* easier. It's also used by so many that it's well established.


That said, the very idea with debian is about free software; free as in 
Open Source. And github is certainly not free. So, we should try hard to 
push for the free alternatives. If we had applied the github thinking 
"use what works, free or not" we shouldn't be where we are.


But, we cannot just say "our tools are as good as github". Because they 
are not.  We need to understand it, and see what can be done. It's an 
uphill battle, but also uphill battles can be won.



Cheers!

--alec

Accepted lirc 0.9.4c-7 (source) into unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 05 Jan 2017 00:05:35 +0100
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.9.4c-7
Distribution: unstable
Urgency: 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
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Changes:
 lirc (0.9.4c-7) unstable; urgency=medium
 .
   * Fix lirc_options.conf upgrade regression in 0.9.4c-6
   * Actually add the hurd build patch missing in 0.9.4c-6
   * Fix segfault on SET_INPUTLOG socket command (upstream #252).
   * Fix bad handling of ircat --config options (upstream #251).
Checksums-Sha1:
 ae02be9ecbf9ca3c04e593be20552ec5f2286a43 2605 lirc_0.9.4c-7.dsc
 36ffb0845f5455fb3e496eb1650cf76bd35b2e7e 42340 lirc_0.9.4c-7.debian.tar.xz
Checksums-Sha256:
 73d59e68ce2d3b85d5796dbf22b0faaee81c90cda87c19ccfadc24ecb5373e9c 2605 
lirc_0.9.4c-7.dsc
 ee88a5c095fd17e9abed6dfff1531b2522b3990b3d15b22027b5311c86ec3ee8 42340 
lirc_0.9.4c-7.debian.tar.xz
Files:
 8d98999434339af71c511e2bac0c3fd1 2605 utils extra lirc_0.9.4c-7.dsc
 4098f3a6cd7c47bda315657deaa68d17 42340 utils extra lirc_0.9.4c-7.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYbhfIAAoJEPNPCXROn13ZszQQAK4eSPhi4CWMJlRpGXjVlCB0
NtnJpi/d/HJQeMY245+CCeJ6HybR3S6yokHXHPjCFmXd4o/xJmb76LevLDf96OVS
fFJQ0trmMb3r2QUMCHBd37vyyWWlT1LSEGOqhYIOXX2nNKweFP51lX3qsiDoQ2wS
JbK/S/f7VwpXbxQs2D99Mmdail0zrpZWBE+ZS8ViskOEgZleeQx3ose2pLATgpz6
y2W+SbhS+UiYtrG3tweu4Y4WO1R4BQmftTiDyOHIzPLXKnehDRPzMnyHfMb9ZCWV
nL7UmoI1sEdsQgj8fx1kDc3R60donQbPr8MUWFRKsV8vGINyfm9MW+2wh5oCvKNJ
Y+V2bxsuOZ3APrbB957y7FH6Q9Fcwep0t+uVUaFu4m1SOcpYfos6o6J5Wui+8CSZ
D+AB+OGGM54Bw9EmjyANQdEuqFX3hoTGj96aXjyuYItINIhxNgU9KpeFh7trP765
76s2fgi0xFWQpBdsUzBwFqkSNRHDqvgd9bLgY33zXSI4iCXCOwjEcWO/zb8dx51q
MrnoMeqfnBbAWdKOCSKHJ2I38sTPoufhRnTyHIQGOVtO472I+h8xssbppSY31Np+
w8qGah6dLn1pH0mGN7gs7PvITGmo6hPi/cMWZR4SCDjVNW1phK8w9RXQy7qZ22Fj
MroHiMxUC9p/7bjihL/m
=VHd5
-END PGP SIGNATURE-

Accepted lirc 0.9.4c-6 (source) into unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 20 Dec 2016 12:36:19 +0100
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.9.4c-6
Distribution: unstable
Urgency: 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
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Closes: 845499 848135 849266
Changes:
 lirc (0.9.4c-6) unstable; urgency=medium
 .
   * Fix unsecure permissions for /run/lirc. Closes: #848135
   * Fix missing config.h header (Upstream #250).
   * Fix HURD build (Closes: #845499)
 - Fix from Samuel Thibault
   * Add missing Suggests: for lirc-compat-remotes.
   * Fix --listen option parsing bug (upstream #249).
   * Fix bad update handling of lirc_options.conf (Closes: #849266).
Checksums-Sha1:
 96777bb360c6eef2d4c0ebdb9c8fa8e7857d1a8f 2605 lirc_0.9.4c-6.dsc
 08e2ec3608df3e0ea0579f485c55774cc1a62172 41168 lirc_0.9.4c-6.debian.tar.xz
Checksums-Sha256:
 018ac352c84644bca441c04eb930b07754d20e6192d17b63f3fc76c5a461048b 2605 
lirc_0.9.4c-6.dsc
 9597e3bc2374dace2cbab2553b3c2512960dbbca172fbb732c98569d81c2 41168 
lirc_0.9.4c-6.debian.tar.xz
Files:
 504efe0ba17050323ff49d1cac903ca7 2605 utils extra lirc_0.9.4c-6.dsc
 9d9ee819d9515f386e5507c933784b4e 41168 utils extra lirc_0.9.4c-6.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYbXL/AAoJEPNPCXROn13ZFVsP/0/qIS7AdoVnaXchjZFhprdD
x0402uZEQez27NBmW4clwk5jUUF0ArJUsr8LhpwxPan7obuldEmxMhfNufEkoH+c
hsIn5F1iBjww+inqf4dzxjBNJ88Z+7gkHsMhEo5MdEgxkwXcWdGRxTmsa1AIptSy
jzpcNM41Wd0GSccBzNqvjuTL0ma2Gt2Xxre2KJF9qvibfnwa7WPjoM8KP4tt5oiK
fmCZW+vdcFpaVgapgBvrSF6MOAf44GxSHJIGF+epTpH8RyMmKGEb1vO8DNDqN9oR
AkFpLEFhaokVDBnr5a5LQpkiUKLyVio/vsqcjlzOyeElX34RLbistNTxDgyQG7eK
mT7+XYus/7jzpIVQct64PoI5L+iF1LWpbbVG7nVU503CSnm1wIyyctDSAhchuSqO
n7HkkY4wV9BHfPH8H13KHfCCqiZyIZ64+LBEFfygGn7D3/0b1VTnQQZN5Y19Efyg
JyvkhCYHL6RPZd0o/qjQLNJq6sgtJ0PXlLIrrgGd06LXHLQrDkRCMxyAFpVrwB4n
pwRr80BJZveFBaoVvZyr5d5e1Ntenf6pc4nYCMx/QOQPaToYyf9/VKL8kSCCBO6C
zjekk6mLKxfkvn9XJFGmfx1EWJToAVS64Kqbrh+ixymEK8DjG/MIi6HaoyDSeZTj
9zLNBsqOQMzhkUXpU2YE
=cQ9x
-END PGP SIGNATURE-

Re: Fwd: Mail delivery failed: returning message to sender

[Alec Leamas]

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 headers,
but the base64 method does not seem entirely inconceivable for some RFC
to support that (especially not considering you can encode the body with
base64).


Nor am I, the experts wrote the MIME RFC [1]. Which basically says that 
both encodings are allowed, but the Q (Quoted printable) is actually 
recommended in a case like this.


Cheers!

--alec


[1] https://www.ietf.org/rfc/rfc2047.txt, section 4,

Accepted lirc 0.9.4c-5 (source) into unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 02 Nov 2016 19:36:19 +0100
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.9.4c-5
Distribution: unstable
Urgency: 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
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Changes:
 lirc (0.9.4c-5) unstable; urgency=medium
 .
   * Team upload.
   * Updated README.debian, new package lirc-compat-remotes info.
   * Added patch for missing lircd-setup.service file.
   * Removed work-around for nowadays fixed  #801719.
   * Added fix for remove --purge not purging all files.
   * lirc-old2new fixes for default device.
   * Fixed to build on freebsd platforms.
Checksums-Sha1:
 4d7cf679fc8bb360fbba253ed20be94b2d4dd01f 2605 lirc_0.9.4c-5.dsc
 c16229dc22ffd3919d5e523d771326d0350a72c3 39588 lirc_0.9.4c-5.debian.tar.xz
Checksums-Sha256:
 dfdef05fe98e956f41a70064b0da694d1cc2d074bcec51e06a9a6916a463d8c1 2605 
lirc_0.9.4c-5.dsc
 491de4281b90cba04d0975b8a16f376615e4977fa8870a475f0d95adc68919d2 39588 
lirc_0.9.4c-5.debian.tar.xz
Files:
 2af5e7e4b1b22d9e3a48168530ef750e 2605 utils extra lirc_0.9.4c-5.dsc
 dfefa5c06ca1b71eebd64488f618c1d9 39588 utils extra lirc_0.9.4c-5.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYSY0GAAoJEPNPCXROn13ZO4AP/R69VAud9CbGEdD+9nbp6Sv4
Vjr4muZCZbrYaZ/QW1LYAmvlWxr2bHxYJveaXsDsr7nC7RcUbNPufOm6+FvNb8Eb
FxD9gU8fWoYUEEgp8XQpGB2D32nJ/ZUD8Jd8sSiEMiZwtnY+H6kJWKE3RFTz+VsD
bd8xeH8Izh97gfEyZU/+50MumQU7UATtj2nGZGns+lmUoOJTRHIi6MwYXbGtvBVr
YPJjsKTaZqYbT0wqEtkUqWhfyu1dGgHbNZNIsCF4+ubcBXc7fxm7t7faO99itM+M
P1v2dPQCz9RWZykfmpAfoH/wQajzTyz37ZSHCtHwlADa6/hrOgl42idFrAPLPGjV
XxEi73favE2HZ39tRJ7nWeSzBjeRW+K3uR0XLVZSTnoX3gozuGL5yUTcgNT/tuCh
D5fnSUQQnlAaKDeDMdfgcvMHkEDpdXD9D+TNofP9+qH8uO3MZgQGKJ9pBiyRwSQ3
g2hPjeT6X8o9QXc1f/0DXZl06iEPwnkeaFRkABpe700h1OI2P6zhgaJWcjmXFjw+
meFUwSeQ7U1TEXCbJR27JfSS26efyjZAxn11ZdULc7KTlM1QsAmPU2xtZcNxpJX+
riRL2OhwQEcGWXOB+EEcTzExGMYc+0Coe5dK54EG+iLViNnlJZm4R9vcZUdZYuPq
uc5kYrIasAuGfJDWQJON
=WHnD
-END PGP SIGNATURE-

Accepted ncmpc 0.25-0.1 (source) into unstable

[Alec Leamas]

-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 Leamas <lea...@nowhere.net>
Description:
 ncmpc  - ncurses-based audio player
 ncmpc-lyrics - ncurses-based audio player (lyrics plugins)
Closes: 842326
Changes:
 ncmpc (0.25-0.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * New upstream release
 - this release includes the autoreconf fixes
   * debian/patches/lirc.patch:
 - Adapt the configure script to detect the new lirc (Closes: #842326).
   (patch has been accepted upstream)
Checksums-Sha1:
 62990f332a2aca17200428a867d63088b3b7acfa 1970 ncmpc_0.25-0.1.dsc
 9a77145612898224be807f17402f61a50ed90fe4 451950 ncmpc_0.25.orig.tar.gz
 d2cec744618d78e0ca8638a21fabfb7831631f75 9220 ncmpc_0.25-0.1.debian.tar.xz
Checksums-Sha256:
 fbdfab8a1e5b2f7d830d4a1da62bc5de4bb4b47c7cd112d16f4b59edd72712c4 1970 
ncmpc_0.25-0.1.dsc
 5b00237be90367aff98b2b70df88b6d6d4b566291d870053be106b137dcc0fd9 451950 
ncmpc_0.25.orig.tar.gz
 1a1cf41da270bbce505891c388f5ae27bd0668ed98831c87681cfc3410989ecc 9220 
ncmpc_0.25-0.1.debian.tar.xz
Files:
 9e2fd820ca9e95271bdf4705825f58ba 1970 sound optional ncmpc_0.25-0.1.dsc
 b6b9a42126de26b50fa3970867a889c5 451950 sound optional ncmpc_0.25.orig.tar.gz
 154a4c7842a076d1d1549ee5a85b8646 9220 sound optional 
ncmpc_0.25-0.1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYJCKwAAoJEPNPCXROn13Z/78QAMW9MOqIcLgUVVkvYUdoCojN
SE7vzPzskjcBBbxprADmS+CKo8/vlJI0riRUs2OLudXTsFRA+DCHY7kxhYMi3IWf
yoEtrdiL45i4vGYn2rCamWo+HJaNOXOkq2PgzegnrBs/3xGgxfv0eDMR9jxPlQRO
HqlZi79QFM5DRNerZHdceIKyqXJH6++L96R6Gl1XujjkpnMcsV3dYB7QF6BY/knV
2l84cI6TP1G9CEmzMDUXU4bVVDmfKi0PnP+fJwlR7oLow0LRG0bjwcK9Sh/Q8UHN
pq628CAscrBV6tpOg/iIVeo9PohCOUrhrB47zrHOY0431CftBHWZF9bLXa9DceKa
nHJpUKXkwlL7lhXm7TQrp4TT540zFbarHBCJ18NwpXYjZVKMFgWeTV+Xl9AvA4My
xBwftxV/K0/xh1E6ZVe+k34xzOTDtL1Qp+6cm+Xf1JaSIeKEIRDId4IChW5+WjYs
2kQ4WkGZj2T30ayIiUSi/3e5KvLS9syiWk9ybqBw038syqrf+Ht7WK9NkJ2Pd3Ds
KPFUNSxkZgi3tFRhGJZHhVKe46mlDHRp1c9A0o9AWDngoTNOr9qbs1Qt9i/fmO12
gRW4E0jEsLIdaAq5rFI0Itzh85gJnWs1yfOGf5Wr8a0I0pvrz4H7N/2IKjkIb/bY
7FfhdnnDQytqgwKANvRv
=aQGP
-END PGP SIGNATURE-

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

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, please use

[linux-any] debian/some-linux-only-file /usr/lib/my-package

So that both kfreebsd, hurd, and any future port, get the fix.


Yup. Been there, done that.

Cheers!

--alec

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

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 the actual location of certain files by
substituting various variables with corresponding values.

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?



You could you debian/install.ARCH files (see man debhelper).

Alternatively, if dh-exec is not enough for you (or you don't get how to
use it), debian/install can be a shell script (or a script in whatever
language, really) that outputs what debian/install should be if it was
not a script:


OK, the means three ways:

   -  debian/install.ARCH
   -  Using dh-exec/dh-filter
   -  Using a general script.

One of these should certainly work. Thanks for all help!


Cheers!

--alec

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

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 necessary.


I'm using dh_systemd_enable...


dh-systemd is a noop on kfreebsd-* and hurd-i386. Also, I just
checked and noticed that I am installing the systemd service in my
packages also on FreeBSD/Hurd so far, and it doesn't FTBFS. I
should probably drop it there (because it's useless), but other
than a tiny amount of disk space it doesn't hurt either. (Obviously
an init script is also present, but not exclusively for non-Linux
ports.)


If it was just the systemd files... I used them as an example. There are 
also some utilities which depends on systemd.



If your package FTBFS, there is probably something else going on
on non-Linux platforms. What is the exact error you're experiencing?


There is no FTBS since the package has a systemd dependency which makes 
the package unbuildable on freebsd. First step is t get rid of that on 
non-linux platfroms, but this is not that hard.



Cheers!

--alec

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

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 would've been the right
list, anyway.


So do I. Next time...



On 08.11.2016 13:39, Alec Leamas 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?


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


A code search [1] showed that syslog-ng does this, so that package might
be worth looking at.

Greets
jre


[1]
https://codesearch.debian.net/search?q=path%3Adebian%2F.*install+kfreebsd-any



Ah... thanks. There are some great tools in the Debian toolchain 
(codesearch!).  This looks like "problem solved". Thanks!



--alec

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

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

files?

Never done that, but I guess use dh-exec filtering in the
debian/*.install files.


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 the actual location of certain files by substituting 
various variables with corresponding values.


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?



Cheers!

--alec

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

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 possible in debian?



It should be. Here are some quick ideas to improve:



  - Is it possible to conditionalize the rules file w r t platform?



GNUMake allows to define conditional parts. Here is an example from owfs:

DEB_HOST_ARCH_OS:=$(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
ifeq ($(DEB_HOST_ARCH_OS),linux)
CONFIGURE_OPTIONS += --enable-w1
else
CONFIGURE_OPTIONS += --disable-w1
endif


This is exactly what I was looking for here, thanks!


Cheers!

--alec

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

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 similar possible in debian?



That said, I think you could get either better (or faster) help on
debian-ment...@lists.debian.org (which I added to Cc:). It is a list
specific to help new maintainers, and doubts about packaging corner
cases are routinely handled there.


Thanks for reply. That said, I'm aware of both lists and posting to 
devel was a deliberate choice. So, if anyone has an actual reply on the 
original post [1], please reply on -devel so we don't run into 
cross-posting problems.



Cheers!

--alec

[1] https://lists.debian.org/debian-devel/2016/11/msg00288.html

Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

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 stuff: tweaks in 
rules/dh_auto_install, systemd configuration files, one or two tools. 
The configure script copes with all this and builds a different set of 
files on freebsd.


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 possible in debian?

In particular:
  - How can I handle that kfreebsd should install a different set of files?
  - Is it possible to conditionalize the rules file w r t platform?
  - If so, how?


Cheers!

--alec

Accepted lirc-compat-remotes 0.9.0-1 (source all) into unstable, unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 02 Nov 2016 14:36:19 +0100
Source: lirc-compat-remotes
Binary: lirc-compat-remotes
Architecture: source all
Version: 0.9.0-1
Distribution: unstable
Urgency: medium
Maintainer: lirc Maintainer Team <pkg-lirc-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)
Checksums-Sha1:
 a9372530e6d042e3016c6f2ce8b2045d4187ca02 1852 lirc-compat-remotes_0.9.0-1.dsc
 0d70b61efac7fc5874953ad1f77ac471c8bf78f9 141494 
lirc-compat-remotes_0.9.0.orig.tar.gz
 32bdee2a4eab9e55ef108594ad30ad8bcb0b9f5b 1672 
lirc-compat-remotes_0.9.0-1.debian.tar.xz
 d9c6deb5ae3c382ef8966e2b70616bed7367f989 120022 
lirc-compat-remotes_0.9.0-1_all.deb
Checksums-Sha256:
 b5974063a700172ce1f66eafd9392c1c4e5c237459ab99ad6debcfff3522a626 1852 
lirc-compat-remotes_0.9.0-1.dsc
 f30c3937f91f3b0c73b859e9bb1b32ee4058de41e0e494f8bb8be070d31f90b6 141494 
lirc-compat-remotes_0.9.0.orig.tar.gz
 e2d15af3c558fdf1621eb3dac37ddce9fea7fe0d9758c46bc4f514707f9c90e7 1672 
lirc-compat-remotes_0.9.0-1.debian.tar.xz
 5a0190abbc36800c04899235942d4bd43906bb4fc42287a196341e130c2e1067 120022 
lirc-compat-remotes_0.9.0-1_all.deb
Files:
 1ad0f39636de408572b9f3c0a7b37dd7 1852 utils extra 
lirc-compat-remotes_0.9.0-1.dsc
 4f623b4a0724211400f334cb513202c4 141494 utils extra 
lirc-compat-remotes_0.9.0.orig.tar.gz
 be4f92638b19c81761f88d000b5e5be8 1672 utils extra 
lirc-compat-remotes_0.9.0-1.debian.tar.xz
 31fe931a9f1fb628b77ec76d3cafd453 120022 utils extra 
lirc-compat-remotes_0.9.0-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJYGhmtAAoJEPNPCXROn13ZHLEP/3YIiv3/p9QayocZr7v4sjZx
N1NNev/ADFWe5r+kOE5YNYgYVc5RhkVRD1kWGKRxZJ13Q6oZZc5YvWjCdVO+A5Oa
kk/1ZhM06XHO3geiLuvUOX5tc2x9ZQ49KBMrqTC1HnY/tAZPn0CmyBIpQG0u81Tj
QcRM9AqieLL499BVlWtPC1F1jxYi3b2IptjEgfvssVvesFFMyNjlWdqvGNkiFttO
bNsmMJLQEuJmIFKH8p7vv00DB40VumXrDIO8Ogqxo84v0tW4yQ9U95NgIKOFtKlR
Rtz9vy+tnD8aucgtRgXeOUl3wJuc3U5mClUAXX2Jeo1aSycIYCDaw7I22gP8MWOz
SaqrLntDvMdDnhq3iCqy8c2r13hEcUIqbiscXMAj6rdkeVN++WZS7+0QIM/EyBvh
O4C0mhlNsLUdR/XcQO/37Tr+wb/SRrF0OmyLfX5PZV76DgeNksD5WEdGEHEQAOuy
V8ybHo8lS9NmKEA2NlfA9WkkaR0RvQWh1udHDEmyzUXMGbS5Eiz/pCqUqhK6Fv8O
VpoMsq9nIecxvPzH/UuudlfNWcpILh0rDFjo5RBKSGC/ZyIsZu3AzY81VqQKod54
16UbJKlmEvUiANgxynitSHcFDwllWh8JU+TBhvYR9nVOBSGe9XNg9V9jPXogzauQ
M7x4yslCu16puzT917KA
=0AV3
-END PGP SIGNATURE-

Accepted lirc 0.9.4c-4 (source) into unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 28 Oct 2016 15:46:34 +0200
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.9.4c-4
Distribution: unstable
Urgency: low
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   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Launchpad-Bugs-Fixed: 1203483 1310508 1393056 1395570 1438381 1497266 1565070 
1636353 1636355
Changes:
 lirc (0.9.4c-4) unstable; urgency=low
 .
   * Team upload.
   * Upload to unstable.
   * Resolves (new bugs) LP: #1636355, LP: #1636353
   * Resolves (old bugs) LP: #1497266, LP: #1565070, LP: #1395570,
 LP: #1393056, LP: #1310508, LP: #1203483, LP: #1438381,
Checksums-Sha1:
 62c3b0795cd852ad6ff0c8eff709b131a92f3ae4 2552 lirc_0.9.4c-4.dsc
 86cd7e8b6536a4d1078144b3bb1a894bb006e8e5 2499425 lirc_0.9.4c.orig.tar.gz
 dc6c3e3e10c9285ac22d5b2e4b0d700ae438df5d 33916 lirc_0.9.4c-4.debian.tar.xz
Checksums-Sha256:
 77ba0cadc6124410fe6a46ad4a5b077b69c21dbc2cd9fb8487d955f4d098f130 2552 
lirc_0.9.4c-4.dsc
 00af1adca9f30ba55928f39520e28dd533892e548082ddc7a9e5e5019355a430 2499425 
lirc_0.9.4c.orig.tar.gz
 768dfeb21f03d53679b223ca95f639aaf015d4e751b48e59ed541d778f716347 33916 
lirc_0.9.4c-4.debian.tar.xz
Files:
 f5b904e7374e95793f97012dc7bffd7d 2552 utils extra lirc_0.9.4c-4.dsc
 cb9ee752aa3a67a689e55aea7fdb6bae 2499425 utils extra lirc_0.9.4c.orig.tar.gz
 e6f2133df465bc3d25e6fe2d8aa31fb7 33916 utils extra lirc_0.9.4c-4.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYFx+7AAoJEPNPCXROn13ZAOsQAJ05NEfNE2VQU4pjHmpBkYQ6
5As65wdiZ6zDVqZy6RQSnYW9+/ET+sZUh5h1D/qy4M2LSYYpAbySBbJfzcLd7lBo
+RObtFPbYbiQkblmMtAXQl1jga4w8kZ9dAzk9trWz33ELzAAWUwXw6ZUHqoeMkDV
2mdfHwNVUBdO6kn22fH8Ch/KTrOxtkhzGN2TrIoWWwaH2oXQNbsL2zp4kIXss4Y6
Obaj89RJRzX6HJzHlREZ1jRgrRN3ZxbD5XEv2NOzTKTYJa448GDgt/9Lg9RoOWnk
tS18cAHyySCGUeiF0FbWvRgBOIG6iRHFlN8ipijSVnQv1kAg4S1GxJQA3TiaemOH
surKMBP/oQiEsAQHSuXcRbQUKG9jsnOwiw0V8wz8RoqU21XpSLf50cj8mSGPT0h0
5I0HpAKizG3AM2+TnN7n4/GAiowMJd6PoD6jI57vGEXf+SbzmvznrkckJayro/jS
SwRB8fFL+trOuCfzWRULX8lOLNSqF2Z2jD9kRQMpo/SDP0TC1KiAy5eTXhtSbd29
z48vufm+RMsXT11gbC1PubcqzNB4Xv7wricvxLhcczgADI+NkVZgN6pBHI6j/SmI
rwn7ro5uORIBnQNGZwADWBtkXMNOje+8nJ7HgEoUJal97bnzHnB3eA2a12vMy/KK
AQN/CQzA5vOOmKSqLSEQ
=zjzm
-END PGP SIGNATURE-

Accepted libirman 0.5.2-1 (source) into unstable

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 29 Oct 2016 05:19:40 +0200
Source: libirman
Binary: libirman-dev libirman0 lirc-drv-irman
Architecture: source
Version: 0.5.2-1
Distribution: unstable
Urgency: medium
Maintainer: lirc Maintainer Team <pkg-lirc-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 support
Changes:
 libirman (0.5.2-1) unstable; urgency=medium
 .
   * Team upload.
   * Upload to unstable
Checksums-Sha1:
 53740eeaf7080552ae939e62bd9f5f29ad95b85f 2204 libirman_0.5.2-1.dsc
 ee8c36b7d16045ec6e5891a6419aa8008dcc3d21 4984 libirman_0.5.2-1.debian.tar.xz
Checksums-Sha256:
 3a46b184411d45924d13964f667e97df153c28e2a18e0c23cd481c81067cac4b 2204 
libirman_0.5.2-1.dsc
 e5917681880e7f06f024b7ea02abcd9f2bb0b63a462e5e6da2f3c4a219035c8f 4984 
libirman_0.5.2-1.debian.tar.xz
Files:
 59b2abb0354208a1d5907c6ef64e8f2f 2204 libs optional libirman_0.5.2-1.dsc
 5e40aff3612ed8f8bd7b8b659db6c1aa 4984 libs optional 
libirman_0.5.2-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYFx/0AAoJEPNPCXROn13ZHEsP/2vDSFT+oBkLr4OvykJf9Xsn
ujieqISlbbS782FPeYhA6nUJKzQNhH3ovzCQytiY1SG3nytnT2JQGzLLl1zPhsrH
kVIE0DTi2iFYGRqiXEHdBE8wKscbuFLpfuwiWzA8J8byMuqhXpdHv4312gu3Ub0r
CGUMGwcHgfmxUBe2f+BnUvUAH9qAIk2YCO55jicvC08n+f2SQZJgSLwb0zTchSS1
MzxrlLkAGfUrNHKWZ3kJh1U+nUQULp57GwW4PkE9Lg2BxpRoG2odSBMv404EVX+f
OnKkk6g39MRiIYbXYosTaKePjzik5lJdMkH3jMUuRnzrVu3E/0Yh4l8ghMZ1VEge
L9rNeCsvJdVmU0yNNU0eibu08jPRu6NKwVd4OfGmb4CaR7mOd9b13yF6uIVMkY/v
rFPfIruOdPmyOeyiLY1ofGJ9m70Hq2pgtZfqiJppsliQNgd9qW/bC2q14M4C4Q1q
QPDxDBMEuUZ2jPf7MAcVXHKBqsDY1Si+YfiOTeVJHyYC1rS+Oael/cEyqdvV51CO
9SGDVpNj+v0b5wvh6F8tDoPWmNSYjmsJmBcrgYUhkBWu+158Xbw3jR3zlJujraTn
wLw+02dhDqPsXLF9PpK96aom9iSXpSXCYNxp5jCKieO+nMepsCipD4PA9EwTV4y6
jCyfJjY3IC2umZJ0mJNi
=nqEm
-END PGP SIGNATURE-

Accepted lirc 0.9.4c-3 (source) into experimental

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 25 Oct 2016 21:46:06 +0200
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.9.4c-3
Distribution: experimental
Urgency: 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
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Changes:
 lirc (0.9.4c-3) experimental; urgency=medium
 .
   * debian/control: Fix bad upgrade paths.
   * Fix bad library specification in lirc.pc (#236)
Checksums-Sha1:
 de3e3e0c4714b7395cd94dd4e61cf10e543c2cf6 2552 lirc_0.9.4c-3.dsc
 3d65be02c94450ee579aebb6facc94221b29c4c1 33076 lirc_0.9.4c-3.debian.tar.xz
Checksums-Sha256:
 8975b940dcefd4b3e53d1693019f2dca484deedf735b7ce31f2eefdbc00147d1 2552 
lirc_0.9.4c-3.dsc
 854e805e7544af9bbe2a146633c4f989b701917e9b3f012a206f33a93dfb08d9 33076 
lirc_0.9.4c-3.debian.tar.xz
Files:
 f46a46042273c322645dc34a1c1b706c 2552 utils extra lirc_0.9.4c-3.dsc
 3cd8b2e19d4888ee432e27a50f3b71fe 33076 utils extra lirc_0.9.4c-3.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYD7/0AAoJEPNPCXROn13ZzsAQAL4g/NuIiSV20heGXP4iobMO
d9h0cbCIv3AKh0+R2Nf3Fe08NDHboXTIlJ6FckzNHDesXKog11iujJWu7tOH/hGQ
NNEY9EvlXPvR40pMQOUdw5qq3XsNRbsjtQlkpTvUL4He5lnVTSABKI4meC9z6YHV
dNh471xRY/31SPlbSq5p2xem8+n3FgiafnfFrNvAFsn0hHZ5OpvkOjoHsERefN0e
lvLd0iuNt9jtc2vYjRSKItA31BVHv1XxLpaFtFQoX7X87TDXO5JAF9tZVOERN4LW
SZHzVdcHfqjZH+ZpB5fNWMa04vMwUKDmHonLJeMPT0ZHBJSa6rzDGit7cfXYzR0Q
2c8wUzIgQlQoAPJp8cufGJ8gAIITHKCwln59Tur922JxkOFUxUQtGvjHmjV/dGYT
rQCA2nyaL0r3vmasEwH8C0nXT9zEWtGTch4iQbt4BumPcdVmo3V+DIVpEDObPB1m
X9UfryKrcG48TOKupg/2FRUxAE71ZiZdo7K0z7lW6DZywoYGfWfWJ3XFWMuiJJvY
kUnd6hHuEtgyrekacDHech7G2GnYLelOV3Y7mPB0uG+hg6aQNZjLPRoKO1CQfp+b
ljJsEcjJ9IW63RJ612rlf3SuXH/SsUhLno3aF+Pt2EimYve6nf56sCcu+B0biviy
HoN2XMKRNxZG64kxD3yZ
=t0fS
-END PGP SIGNATURE-

Accepted lirc 0.9.4c-2 (source) into experimental

[Alec Leamas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 25 Oct 2016 10:32:39 +0200
Source: lirc
Binary: lirc lirc-doc liblirc0 liblircclient0 liblircclient-dev liblirc-dev 
liblirc-client0 lirc-x
Architecture: source
Version: 0.9.4c-2
Distribution: experimental
Urgency: 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
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc   - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities
Changes:
 lirc (0.9.4c-2) experimental; urgency=medium
 .
   * Fix unconfigured clients build errors.
Checksums-Sha1:
 1ff9d6a4c2886446aa5e5e4b8307298b34819d34 2552 lirc_0.9.4c-2.dsc
 9976310dbab2fc9646343c38d933e3c0ec711a9b 32812 lirc_0.9.4c-2.debian.tar.xz
Checksums-Sha256:
 7d76c700cae270c98cf44970b08dc8cb5f19d044d9bb636c8dedf1bf8b0ceb62 2552 
lirc_0.9.4c-2.dsc
 d47a238ccbaab84653c0d6263c14a4ace412eff9568d38c9f5dbf675f20578bd 32812 
lirc_0.9.4c-2.debian.tar.xz
Files:
 ff0b674c06968d9b02fab975f5acb4ba 2552 utils extra lirc_0.9.4c-2.dsc
 8ae81153ba1f57883b1c1f3152d933e1 32812 utils extra lirc_0.9.4c-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYDx1tAAoJEPNPCXROn13ZsEQP/0oo81cXtfCCx4YVmyEQfN82
8EO4XMnukmF8Y9nu9PTImh/Abq93uG6Mp6MhroXOkrrXCLlQFe2tXv27p/YZTdfs
x4hy/bD4hkIj6+UwXoUgFmLl8uDLUl+ZAyL+3B8lEEL4XPYNq851G+wkPHPVhtLa
JuIBaPBNrz1FZUTiX6v7vUNiWs7zKDe3RBAThDRBRK4zvCJvC8gRVwwFcZKxdVUG
h9unfMbne6Gjdtjgm+SKYPMVInJvL1U5D2pUsPxHXmDfM+dLbwkdcFHkAhauG1IB
y1EE3KEWAW6Q9yyfPq62j49/vrIDaUuZCuOBvlAffHwLnb2h4rCrr0SRNQI8sqFN
lzEDfucd6f85XCbWXB4gxFWJ3eud1tGhDPTugnmF7YYHQSs6+6PTaqkZ6b+eR371
fGlKwEPf4HPhafQGb6YVN4OFmRe7aprHCGRUm/3pVn7ZF+DNHxxtZK0BDxTfintV
69KH1yI1KxIjRA5m8XzuAOMfBimw5SFbZMyT7F/bSEhzW2xpDituh67VPjfY8JpD
2CUevVPlBT7WyVie1xuxqRNCOyj+Q5qn9kyQZ6AjFr5b4A8HsfxN6EMpHCtCO8iv
dd9HPaMUOZsLGWlqGUnK81F6NwWlIqKRSXpur4JgxqEwLulTr8+44i3R6H7WqY/X
txvha7VNTHB9XaU3GkWO
=eMRt
-END PGP SIGNATURE-