Skip to content

Edit your debian patch header for DEP-3 compliance with cme

While not required by Debian policy, the  patch tagging guidelines (aka DEP-3) recommends to add a structured header to source package patches.

Long story short, patches should begin with something like :

Description: tweak lcdproc config for debian
patch LCDd.conf to:
* use syslog instead of stderr to show message
* run LCDd as root (to read /dev/lcd* file)
.
The latter could be done better by tweaking udev rule
Author: dod
Applied-Upstream: NA

Making sure that the DEP-3 recommendation is respected may not be fun. Do not despair: once libconfig-model-dpkg-perl is installed on your system, you can check whether your patches respect the DEP3 recommendation with the following command:

$ cme check dpkg-patches
loading data
checking data
check done

You can also check individual patches with:

cme check dpkg-patch tweak-conf

Note that bash auto-completion is provided only from version 2.049 of libconfig-model-dpkg-perl package.

If editing the header of your patches with your favorite editor does not strike you as fun, you can also use cme graphical editor provided by libconfig-model-tkui-perl. Once this package is installed, you can run:

cme edit dpkg-patches

You will get this editor to update your patches:

-usr-bin-cme Dpkg::Patches_001

This editor will show you the available parameters and the associated documentation to let you provide relevant information.

Last but not least, patch header check is also performed when you check your whole package with cme check dpkg

All the best

Deprecating experience level and preset value in Config::Model

Hello

The next releases of Config::Model will deprecate 2 (mis)features:

  • Experience level: trying to filter out configuration parameter based on arbitrary experience is a bad idea. This may confuse user by hiding parameter without obvious way to show them back. (actually with the options menu on the graphical interface, but that’s too easy to miss)
  • Preset value: this feature provides a way to specify a default value at runtime. This is now provided with the configuration layer.

The behavior of ‘cme check’ will not change. People using ‘cme edit’ with the GUI will see many more configuration parameters.

All the best

Another package configuration upgrade project …

Hello

I’ve recently learned that Debian Google Summer of Code 2014 features a project to improve package configuration upgrade based on Elektra library

Despite the fact that this project competes directly with the work done for lcdproc upgrades, I’m very glad that the idea of improving configuration upgrade is getting more attention and I welcome this new project.

All the best

Easier Lcdproc package upgrade with automatic configuration merge

Hello

This blog explains how next lcdproc package provide easier upgrader with automatic configuration merge.

Here’s the current situation: lcdproc is shipped with several configuration files, including /etc/LCDd.conf. This file is modified upstream at every lcdproc release to bring configuration for new lcdproc drivers. On the other hand, this file is always customized to suit the specific hardware of the user’s system. So upgrading a package will always lead to a conflict during upgrade. User will always be required to choose whether to use current version or upstream version.

Next version of libconfig-model-lcdproc-perl will propose user whether to perform automatic merge of the configuration: upstream change are taken into account while preserving user change.

The configuration upgrade shown is based on Config::Model can be applied to other package.

Current lcdproc situation

To function properly, lcdproc configuration must always be adapted to suit the user’s hardware. On the following upgrade, upstream configuration is often updated so user will often be shown this question:

Configuration file '/etc/LCDd.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** LCDd.conf (Y/I/N/O/D/Z) [default=N] ?

This question is asked in the middle of an upgrade and can be puzzling for an average user.

Next package with automatic merge

Starting from lcdproc 0.5.6, the configuration merge is handled automatically by the packaging script with the help of Config::Model::Lcdproc.

When lcdproc is upgraded to 0.5.6, the following changes are visible:
* lcdproc depends on libconfig-model-lcdproc-perl
* user is asked once by debconf whether to use automatic configuration upgrades or not.
* no further question are asked (no ucf style questions).

For instance, here’s an upgrade from lcdproc_0.5.5 to lcdproc_0.5.6:

$ sudo dpkg -i lcdproc_0.5.6-1_amd64.deb 
(Reading database ... 322757 files and directories currently installed.)
Preparing to unpack lcdproc_0.5.6-1_amd64.deb ...
Stopping LCDd: LCDd.
Unpacking lcdproc (0.5.6-1) over (0.5.5-3) ...
Setting up lcdproc (0.5.6-1) ...

Changes applied to lcdproc configuration:
- server ReportToSyslog: '' -> '1' # use standard value
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Starting LCDd: LCDd.
Processing triggers for man-db (2.6.6-1) ...

Note: the automatic upgrade currently applies only to LCDd.conf. The other configuration files of lcdproc are handled the usual way.

Other benefits

User will also be able to:
* check lcdproc configuration with sudo cme check lcdproc
* edit the configuration with a GUI (see Managing Lcdproc configuration with cme for more details)

Here’s a screenshot of the GUI:

GUI to edit lcdproc configuration

More information

* libconfig-model-lcdproc-perl package page. This package provides a configuration model for lcdproc.
* This blog explains how this model is generated from upstream LCDd.conf.
* How to adapt a package to perform configuration upgrade with Config::Model

Next steps

Automatic configuration merge can be applied to other packages. But my free time is already taken by the maintenance of Config::Model and the existing models, there’s no room for me to take over another package.

On the other hand, I will definitely help people who want to provide automatic configuration merge on their packages. Feel free to contact me on:
* config-model-user mailing list
* debian-perl mailing list (where Config::Model is often used to maintain debian package file with cme)
* #debian-perl IRC channel

All the best

Config::Model::OpenSsh now supports OpenSSH 6.4 configuration

Hello

This was long overdue.

I’ve released Config::Model::OpenSsh 1.232. This new release
supports a lot of new parameters that were added to OpenSSH 6.0 and later versions, like AllowAgentForwarding, AuthenticationMethods or AuthorizedKeysCommand.

This new version is also available in Debian.

Happy new year !

LWP::UserAgent https proxy now fixed in Debian

Hello

For more 10 years, opening a https connection throught a proxy was not possible
with LWP::UserAgent.

Thanks to Steffen Ullrich, this bug is now fixed in LWP::UserAgent and LWP::Protocol::https repositories.

In Debian, I’ve updated libwww-perl 6.05-2 and liblwp-protocol-https-perl 6.04-2 to include the same patches. This fix is now available in Debian unstable.

See my previous blog for more details on this story.

All the best

About LWP::UserAgent, https and proxy setup

Hello

The last few weeks, I’ve been banging my head to use uscan, Pithub and JIRA::Client::Automated behind a corporate firewall. They are all written in Perl and use LWP::UserAgent to fetch information from Internet. At $work, using a proxy is mandatory to connect to Internet. But LWP::UserAgent https connection does not work through a proxy. This bug was reported 10 years ago but is still not fixed.

Here’s my plan to fix (or work-around) this issue, at least for Debian.

Before going further, let’s step back to explain briefly what is https and how proxies work.

https is not a protocol by itself. https is plain http over a socket encrypted with SSL (aka TLS). To create a https connection, the agent must first setup the SSL socket with the server. Then the agent uses http protocol to communicate with the server. All the traffic is encrypted on agent side and decrypted on server side by the SSL layer.

When creating a connection through a proxy, things get a little more complicated. Plain http requests (like GET, POST and so on…) are sent to the proxy as if the proxy was the http server. Then, the proxy forwards the request to the actual server.

From what I’ve read, most proxy servers refuse to plainly forward encrypted data to a web server. First a negotiation to create a tunnel towards the web server must be done by sending a http CONNECT request to the proxy server. The encrypted socket is then set up between the user and the web server through the proxy. Once this encrypted tunnel is set up, the usual http communication can be done.

Let’s go back to LWP::UserAgent. To create a connection over SSL, LWP::UserAgent will use a SSL library to setup the socket. This SSL library can be IO::Socket::SSL or Net::SSL. Direct https connection with LWP::UserAgent works fine with either library.

That said, only IO::Socket::SSL is able to perform correctly the verification of the server name. Net::SSL does not check correctly SSL certificates. For more details, see https://github.com/libwww-perl/libwww-perl/pull/51 and https://bugzilla.redhat.com/show_bug.cgi?id=705044 .

When trying to setup a https connection through a proxy, LWP::UserAgent (<= 6.05) tries to use the proxy like a regular http proxy without going through the CONNECT phase. This does not work.

Thanks to Steffen Ullrich, LWP::UserAgent and LWP::Protocol::https are now fixed in github.

In Debian, libwww-perl 6.05-2 and liblwp-protocol-https-perl 6.04-2 contains the same patch to fix https_proxy and are now uploaded in Debian unstable.

Next step is to provide simple patches to let uscan, Pithub and JIRA::Client::Automated correctly connect through proxies without jumping through hoops.

All the best

[ Edited: I’ve removed some bad ideas from this blog about using Net::SSL ]

Follow

Get every new post delivered to your Inbox.

Join 45 other followers