Re: [Mailman-Developers] Let's try to package mailman3 in Debian!

[Pierre-Elliott Bécue]

Le lundi 14 décembre 2015 à 17:01:57+0100, Pierre-Elliott Bécue a écrit :
> Le lundi 23 novembre 2015 à 02:56:27+0100, Pierre-Elliott Bécue a écrit :
> > Le vendredi 11 septembre 2015 à 00:49:44+0200, Pierre-Elliott Bécue a écrit 
> > :
> > > [packaging mailman3]
> > 
> > Hey,
> > 
> > Here is an update.
> > 
> > For now on, I focused on mailman3-core package in order to get good
> > practices working.
> > 
> > One can find my work here : https://github.com/P-EB/mailman3-core
> > 
> > I'm working on having working systemd/sysv services and after that it'll be
> > a good idea to try installing the package and see how it goes.
> > 
> > I also have to design a good config file for debian, (see
> > debian/contrib/mailman.cfg in master branch). Any suggestion is welcome!
> > 
> > Cheers
> 
> Small bump here, I'd appreciate if somebody finds the time to tell me two
> things:
> 
>  * Is my config file enough for a start ?
>  * Is my systemd service good to have mailman started properly ?
> 
> I'd rather be sure it's okay before writing a sysv service.
> 
> You can find contrib files in debian/contrib.

Hello!

Before requesting for sponsorship, and packaging officially the other
components of mailman3, I'd like some "testers" for the core package I
built, in order to be sure that it works, and that I will not introduce some
stupid caveats on the packaging of the other components.

.deb can be found here: http://peb.pimeys.fr/mailman/mailman3-core/
git repo can be found there: https://gitlab.pimeys.fr/PEB/mailman3-core
and there: https://github.com/P-EB/mailman3-core

Any volunteer welcome! Please, I need your help, I cannot review my work
alone! :)

-- 
PEB

Re: Adding SONAME to a shared object in KLEE

[Simon McVittie]

I don't know anything about this specific project, so I don't know
whether you're an upstream or downstream developer. In general SONAMEs
are something that should be managed upstream, to avoid incompatibility
between distributions. If your upstream rejects reasonable patches,
SONAMEs can be managed internally within Debian as a last resort;
but that would make binaries from Debian and not-Debian incompatible,
which is best avoided, and can also cause problems in future if upstream
later starts using SONAMEs correctly.

On Thu, 18 Feb 2016 at 22:58:48 +0100, Filippo Rusconi wrote:
> The library file proper should store a specific bit of information
> that is called a SONAME (shared object name). That SONAME should be in
> the form lib.so.. In our example, that would be
> libkleeRuntest.so.1 (as suggested by then file klee_1.1.0-1.dsc).

Please note that the version in the SONAME is not the "marketing version"
that you tell your users (or even your version control system), it's the
ABI version. The SONAME must change whenever the ABI changes incompatibly,
and should not change when the ABI remains compatible.  If you're using
"semantic versioning", the version in the SONAME *might* match the
human-readable major version, but it also might not; if you're not using
semantic versioning, the version in the SONAME probably won't match the
major version.

For instance, choosing a couple of random libraries from my system:

- libappstream has broken ABI (several times?) before reaching version 1,
  so its SONAME is libappstream.so.3 even though its version number is 0.9.1

- conversely, libassuan has never broken ABI, so its SONAME is libassuan.so.0
  (meaning "compatible with the first ever version of libassuan.so") even
  though its version number is 2.4.2

In some libraries you'll also see an  "API version number" in the name
of the library itself. This is to allow for parallel-installation
of the *development files* for more than one version. For instance,
you can't have libjpeg 6b and libjpeg 8 installed at the same time,
because they both ship a libjpeg.so symlink; but you *can* have
Gtk 1, 2 and 3 development files at the same time, because their
libraries are called things like libgtk-3.so.0 (first ABI-version
for Gtk 3), with development symlink names like libgtk-3.so.
The classic document on this is ,
with an updated version recently made available at
.
Parallel-installation is not at all GNOME-specific - it can also be
seen in Qt/KDE, SDL and DirectFB, for example - but it's very popular
in GNOME and GNOME-related projects, and those documents are the best
reference I've seen for how to do it and why.

S

Re: Adding SONAME to a shared object in KLEE

[Vincent Danjean]

  Hi,

Le 18/02/2016 22:58, Filippo Rusconi a écrit :
> [ longish mail, bear with me ]

Thank you for this long explaination. I just think there is a typo:

[...]
> How would we do that ? We need to tell the linker how to create the
> library file:
> 
> compilation flags to build your libkleeRuntest shared object lib:
> 
> -shared -fPIC -Wl,-soname,libkleeRuntest.so.1.1 -o libkleeRuntest.so.1.1

The argument of the linker option -soname should be the soname and not
the real name:
  -shared -fPIC -Wl,-soname,libkleeRuntest.so.1 -o libkleeRuntest.so.1.1

as this is reflected by your output:
[...]
> readelf -d libkleeRuntest.so.1.1
[...]
>   0x000e (SONAME) Library soname: 
> [libkleeRuntest.so.1]
  

no libkleeRuntest.so.1.1 but the correct libkleeRuntest.so.1 soname

>   0x000c (INIT)   0x4e68

  And a few remarks:
* if the upstream build system want to *link* with this library (after
  creating it), it will need to either use the real name or (better) to
  create the required link (the libNAME.so link)
* if the upstream build system want to *run* this library (for
  example as part of a test suite), it will need to create the other
  link (the libNAME.so.SOVERSION link) and to play with
  LD_LIBRARY_PATH (or use LD_PRELOAD)
It is were build frameworks such as autotools/libtools helps the
developer...

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Re: Adding SONAME to a shared object in KLEE

[Josselin Mouette]

Hi Marko,

Le jeudi 18 février 2016 à 10:43 -0700, Marko Dimjašević a écrit :
> I would need help with fixing a SONAME issue with my ITP package. It's a
> tool for development, which systematically explores as many as possible
> execution paths in a given program, potentially triggering crashes
> unknown before.

> E: klee: sharedobject-in-library-directory-missing-soname 
> usr/lib/libkleeRuntest.so

It looks to me that this file is not meant to be a shared library. I
don’t know what it is, but there are no associated headers and nothing
that looks like it could be linked against it.

It’s not even clear you should ship it in the package, maybe it’s part
of a test suite of some sort?

In any case, it is useless to add a SONAME to such a file, because
SONAMEs are here for programs you actually link with that library. If
the file does have some use in the binary, you can move it away in
another directory (it has no place in /usr/lib).

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-

Bug#815165: ITP: fcitx-imlist -- Command-line utility to switch list of Fcitx IM

[HAYASHI Kentaro]

Package: wnpp
Severity: wishlist
Owner: HAYASHI Kentaro 
X-Debbugs-CC: debian-devel@lists.debian.org, debian-de...@lists.debian.or.jp

   Package name: fcitx-imlist
Version: 0.5.0
Upstream Author: HAYASHI Kentaro 
   URL: https://github.com/kenhys/fcitx-imlist
License: GPL-2+

Description: Command-line utility to switch list of Fcitx IM
 fcitx-imlist is a small program to show or change input method list.
 .
 This software is useful for the people who switch keyboard
 layout frequently - sometimes use equipped keyboard of mobile PC,
 sometimes use different layout of external keyboard with that PC.

-- 
HAYASHI Kentaro 


-- 
HAYASHI Kentaro 

Bug#815196: ITP: awlsim -- S7 compatible soft-PLC

[Michael Büsch]

Package: wnpp
Severity: wishlist
Owner: "Michael Büsch" 

* Package name: awlsim
  Version : 0.44?
  Upstream Author : Michael Buesch 
* URL : http://bues.ch/h/awlsim
* License : GPLv2+
  Programming Lang: Python
  Description : S7 compatible soft-PLC

Awlsim is a soft-PLC (see
https://en.wikipedia.org/wiki/Programmable_logic_controller) that can execute
STEP7 (see German https://de.wikipedia.org/wiki/STEP_7) compatible AWL/STL
code.

I plan to maintain the Debian package by myself.
The upstream repository, also maintained by me, already contains some basic
Debian packaging scripts. (see http://bues.ch/gitweb?p=awlsim.git;a=tree)

Bug#815199: ITP: acme-tiny -- letsencrypt tiny python client

[Jeremías Casteglione]

Package: wnpp
Severity: wishlist
Owner: "Jeremías Casteglione" 

* Package name: acme-tiny
  Version : 20151229
  Upstream Author : Daniel Roesler 
* URL : https://github.com/diafygi/acme-tiny
* License : MIT
  Programming Lang: Python
  Description : letsencrypt tiny python client

acme-tiny is a tiny script to issue and renew TLS certs from Let's Encrypt

This is a tiny, auditable script that you can throw on your server to issue and
renew Let's Encrypt certificates. Since it has to be run on your server and
have access to your private Let's Encrypt account key, I tried to make it as
tiny as possible (currently less than 200 lines). The only prerequisites are
python and openssl.

You have to deal yourself wiht the openssl stuff, and with webserver
configuration and such. But it doesn't require more dependencies than openssl
and it just works, no need for sudo nor being root to run it either. I'm using
it for my personal TLS stuff.

I'm not a DD nor a DM either, so an sponsor will be needed.

Bug#815213: ITP: puppet-module-sbitio-monit -- Puppet module for Monit

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-sbitio-monit
  Version : 1.0.0
  Upstream Author : Jonathan Araña Cruz 
* URL : https://github.com/sbitio/puppet-monit
* License : Mit
  Programming Lang: Ruby, Puppet
  Description : Puppet module for Monit

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 Performs installation and configuration of Monit service, along with fine
 grained definition of checks.
 .
 All check types provided by Monit are supported. Namely: directory, fifo,
 file, filesystem, host, process, program, and system.
 .
 In adition to primitive types, a compound check type is provided: service. It
 is a set of primitives to check a service's init script, binary and process.
 .
 service check type can work with sysv, systemd or upstart. In 0.3.x series it
 defaults to sysv for compatibility reasons. From 1.0.x onwards it defaults to
 the init system that each supported OS configures by default. The init type to
 use can be also set per service. See below for details.