Bug#1064508: RFP: ior -- parallel storage IO benchmark

[Luca Capello]

Package: wnpp
Severity: wishlist
User: stor...@unige.ch
Usertags: unige.ch-storage

* Package name: ior
  Version : 3.3.0
  Upstream Contact: Los Alamos National Laboratory
(Lawrence Livermore National Laboratory
  William Loewe ,
  Tyce McLarty ,
  Christopher Morrone )
* URL : https://github.com/hpc/ior
(https://github.com/LLNL/ior)
* License : GPL-2
  Programming Lang: C
  Description : parallel storage IO benchmark
   IOR is a parallel IO benchmark that can be used to test the performance
   of parallel storage systems using various interfaces and access
   patterns.
   .
   The IOR package also includes the mdtest benchmark which specifically
   tests the peak metadata rates of storage systems under different
   directory structures.
   .
   Both benchmarks use a common parallel I/O abstraction backend and rely on
   MPI for synchronization.

I have just packaged it, since I need it for a short-lived HPC project I
am working on as part of the storage team at the University of Geneva
(Switzerland).

However, given that I do not plan to continue to use it after this
project, I wonder if someone else would like to maintain it, probably as
part of the "Debian Science Distributed Computing packages" (Cc:ed)?

  <https://blends.debian.org/science/tasks/distributedcomputing>

I will provide the packaging sources once this bug get a number.

Thx, bye,
Gismo / Luca

-- 
Dr. Luca Capello
Ingénieur stockage | Recherche et Information Scientifique
Division du Système et des Technologies de l'Information et de la Communication
Université de Genève | 66, Boulevard Carl-Vogt | 1205 Genève
Tél +41 22 379 77 69 | Bureau D624
mailto:luca.cape...@unige.ch


signature.asc
Description: PGP signature

Bug#1064504: schroot: `schroot -i -c "${SCHROOT_SESSION_ID}"` does not work, differently from the manpage

[Luca Capello]

Package: schroot
Version: 1.6.13-3+b2
Severity: normal
User: stor...@unige.ch
Usertags: unige.ch-packaging

Hi there,

`man schroot` has the following example in the "Sessions" subsection:
```

   Note that the Session Managed option is set to ‘true’.  This is
   a requirement in order to use session manage‐ ment, and is
   supported by most chroot types.  Next, we will create a new
   session:

   % schroot -b -c sid-snap↵
   sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f

   The session ID of the newly-created session is returned on
   standard output.  It is common to store it like this:

   % SESSION=$(schroot -b -c sid-snap)↵
   % echo $SESSION↵
   sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f

   The session may be used just like any normal chroot.  This is
   what the session looks like:

   % schroot -i -c sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f↵
 ——— Session ———
 Name   sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f
 DescriptionDebian sid snapshot
 Type   lvm-snapshot
 Priority   3
[...]
 Mount Location 
/var/lib/schroot/mount/sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f
 Path   
/var/lib/schroot/mount/sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f
```

However, the above example does not work:
```
root@harlock:~# SCHROOT_SESSION_ID="$(schroot -b -c bookworm-amd64-sbuild)"
root@harlock:~# echo "${SCHROOT_SESSION_ID}"
bookworm-amd64-sbuild-638d6de1-c6b8-4fe8-9ce9-a9d0717c7397
root@harlock:~# schroot -i -c "${SCHROOT_SESSION_ID}"
E: bookworm-amd64-sbuild-638d6de1-c6b8-4fe8-9ce9-a9d0717c7397: Chroot not found
root@harlock:~# schroot -l --all
chroot:bookworm-amd64-sbuild
session:bookworm-amd64-sbuild-638d6de1-c6b8-4fe8-9ce9-a9d0717c7397
source:bookworm-amd64-sbuild
root@harlock:~# schroot -r -c "${SCHROOT_SESSION_ID}" -- uname -sr
Linux 6.5.0-0.deb12.4-amd64
root@harlock:~# 
```

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 
'stable'), (500, 'oldstable'), (100, 'bookworm-fasttrack'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages schroot depends on:
ii  debconf [debconf-2.0]   1.5.82
ii  libboost-filesystem1.74.0   1.74.0+ds1-21
ii  libboost-iostreams1.74.01.74.0+ds1-21
ii  libboost-program-options1.74.0  1.74.0+ds1-21
ii  libc6   2.36-9+deb12u4
ii  libgcc-s1   12.2.0-14
ii  libpam0g1.5.2-6+deb12u1
ii  libstdc++6  12.2.0-14
ii  libuuid12.38.1-5+b1
ii  schroot-common  1.6.13-3
ii  sysvinit-utils [lsb-base]   3.06-4

schroot recommends no packages.

Versions of packages schroot suggests:
pn  aufs-tools | unionfs-fuse  
pn  btrfs-progs
ii  bzip2  1.0.8-5+b1
ii  debootstrap1.0.128+nmu2+deb12u1
ii  lvm2   2.03.16-2
pn  qemu-user-static   
ii  xz-utils   5.4.1-0.2
pn  zfsutils-linux 
pn  zstd   

-- debconf information:
  schroot/bad-names:

-- 
Dr. Luca Capello
Ingénieur stockage | Recherche et Information Scientifique
Division du Système et des Technologies de l'Information et de la Communication
Université de Genève | 66, Boulevard Carl-Vogt | 1205 Genève
Tél +41 22 379 77 69 | Bureau D624
mailto:luca.cape...@unige.ch


signature.asc
Description: PGP signature

Bug#1035725: rdiff-backup bug

[Luca Capello]

tags 1035725 + upstream patch
forwarded 1035725 https://github.com/rdiff-backup/rdiff-backup/issues/872
user l...@pca.it
usertags 770171 + pca.it-backup
thanks

Hi there,

On Sun, 14 Jan 2024 10:55:06 +0100, Henrik Riomar wrote:
> On Sat, Jan 13, 2024 at 5:00 AM Otto Kekäläinen  wrote:
> > Looking at https://github.com/rdiff-backup/rdiff-backup/issues/872
> > this was fixed in latest rdiff-backup, which is now available in
> > Debian unstable.
> >
> > If you can confirm that this version fixes the issue, I can backport
> > it to Debian Bookworm as well.
> >
> 
> Yes it works.
> 
> This is the diff we currently apply via Ansible to Debian 12 hosts:
> https://github.com/rdiff-backup/rdiff-backup/pull/873/files

I can confirm that the version in Debian 11/bullseye *does not need*
any modification, while the version in Debian 12/bullseye simply needs
the upstream modifications Henrik linked, thus the following commit:

  


NB, IMHO this must go ASAP in stable-proposed-updates!

Thx, bye,
Gismo / Luca

PS, this is an upstream bug, tagging accordingly!


signature.asc
Description: PGP signature

Bug#1061109: prosody-modules: enable modules mod_cloud_notify_extensions (_i.e._ mod_cloud_notify_encrypted, mod_cloud_notify_priority_tag and mod_cloud_notify_filters)

[Luca Capello]

Package: prosody-modules
Version: 0.0~hg20230223.556bf57d6417+dfsg-1~bpo11+1
Severity: wishlist
Usertags: pca-communication

Hi there,

to fully support "XEP-0357: Push Notifications", `mod_cloud_notify`
(cf. ) is not enough, as explained in
its README:

  

Manually downloading in `/usr/local/lib/prosody/modules/` the 4 Lua
files below...

  `mod_cloud_notify_extensions`
  `mod_cloud_notify_encrypted`
  `mod_cloud_notify_priority_tag`
  `mod_cloud_notify_filters`

...and activating `mod_cloud_notify_extensions` was enough to get "push
notifications" in Siskin:

  

NB, I have been testing this on a production system (and different
iPhones) since 2023-08-05!

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-0.deb11.7-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages prosody-modules depends on:
ii  prosody  0.12.3-1~bpo11+1

Versions of packages prosody-modules recommends:
pn  lua-ldap  

prosody-modules suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1060386: fail2ban: Fail2ban Debian 12 fails to start

[Luca Capello]

tags 1060386 + moreinfo
thanks

Hi there,

On Wed, 10 Jan 2024 14:06:47 +, Guido van Brakel wrote:
> Version: 1.0.2-2
> Severity: important
> Dear Maintainer,
> 
>* What led up to the situation? Installing fail2ban on Debian 12
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action? Fail2ban fails to start
>* What outcome did you expect instead? Fail2ban just starting without 
> needing to

You should provide some more information, like the error message when
you manually launch `/usr/bin/fail2ban-server -vvv -x start`.

> Versions of packages fail2ban depends on:
> ii  python3  3.11.2-1+b1
> Versions of packages fail2ban recommends:
> ii  iptables   1.8.9-2
> ii  python3-pyinotify  0.9.6-2
> ii  python3-systemd235-1+b2
> ii  whois  5.5.17
> Versions of packages fail2ban suggests:
> Versions of packages fail2ban suggests:
> pn  mailx  
> pn  monit  
> pn  sqlite3
> pn  system-log-daemon  
> -- Configuration Files:
> /etc/fail2ban/jail.conf changed:
> [INCLUDES]
> before = paths-debian.conf
> [DEFAULT]
> ignorecommand =
> bantime  = 10m
> findtime  = 10m
> maxretry = 5
> maxmatches = %(maxretry)s
> backend = systemd

Please note that on a default Debian 12.4/bookworm you simply need to
add some lines to `jail.local`, without touching anything else:
```
[DEFAULT]
### 
banaction = nftables
banaction_allports = nftables[type=allports]
### 
backend = systemd
```

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#862348: fail2ban: fails to filter systemd ssh daemon entries from journal

[Luca Capello]

Hi there,

On Fri, 11 Aug 2023 01:08:37 +0100, Andrei Coada wrote:
> This is getting pretty annoying, especially now that Debian 12 does not
> even have a syslog service installed by default.
> Fail2ban fails to start right after its installation.
> 
> The solution is really trivial. At least an SSHD override should be added
> in  "paths-debian.conf"  file, such as:
> 
> sshd_backend = systemd
> 
> so that the fail2ban service can start after one installs it.

Andrei, please read again the submitter report, he explicitely shows
that `fail2ban` reads `/var/log/auth.log`, thus I guess the problem is
not `systemd`-related (he also has `rsyslog` installed, thus
`/var/log/auth.log` *is* present).

NB, the `systemd` issue on a default Debian 12/bookworm has been fixed
one week ago already and it is easily applied to `jail.local`:

  

Alban, 0.9.6-2 is quite an old version and you reported the bug more
than 5 years, can you try on a more up-to-date Debian?

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#770171: closed by Debian FTP Masters (reply to Sylvestre Ledru ) (Bug#770171: fixed in fail2ban 1.0.2-3)

[Luca Capello]

found 770171 1.0.2-2
tags 770171 + upstream
forwarded 770171 https://github.com/fail2ban/fail2ban/issues/1372
user l...@pca.it
usertags 770171 + pca.it-security
thanks

Hi there,

I just got hit by this as well, plus the nftables issue:

  

On Tue, 02 Jan 2024 19:39:13 +, Debian Bug Tracking System wrote:
> Changes:
>  fail2ban (1.0.2-3) unstable; urgency=medium
>  .
>* Add banaction = nftables in the defaults-debian.conf default
>  see 
> https://github.com/fail2ban/fail2ban/discussions/3575#discussioncomment-7045315
>* Move python3-systemd as depend (Closes: #770171, #1037437)
>* Add backend = systemd to jail.d/defaults-debian.conf

The commit corresponding to the last line is:

  


For those waiting the fixed pacakge, without touching any other
packaged file I can confirm that `apt-get install python3-systemd`
plus the below `jail.local` are enough to get `fail2ban` starts on a
fresh Debian 12.4/bookworm:
```
[DEFAULT]
### 
banaction = nftables
banaction_allports = nftables[type=allports]
### 
backend = systemd
```

Thx, bye,
Gismo / Luca

PS, the upstream bug is quite interesting, especially to understand the
differences between `(|*_)backend`:

  


signature.asc
Description: PGP signature

Bug#1049452: fail2ban should use nftables by default.

[Luca Capello]

fixed 1049452 1.0.2-3
user l...@pca.it
Usertags 1049452 + pca.it-security
thanks

Hi there,

On Wed, 16 Aug 2023 09:50:30 +1000, Peter Chubb wrote:
>   iptables is deprecated; fail2ban can use nft instead.
>   Please make nftables the default banning method in 
>   /etc/fail2ban/jail.conf, and consider changing the Recommends: 
>   to a Depends: for nftables.

I just got hit by this as well (plus the systemd backend issue) and
after some research I found out that Sylvestre Ledru released a fixed
package one week ago already, albeit IMHO this needs a
stable-backports or, better, a stable-proposed-updates (thus not
closing this bug):

  
   


Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#1056360: python3-wikitrans: [wikimarkup.py] 'str' object has no attribute 'decode'

[Luca Capello]

Package: python3-wikitrans
Version: 1.3-2
Severity: grave
Control: affects -1 dico-module-mediawiki
Usertags: pca.it-communication

Hi there,

after the dicod's `load python`[1] and `M4 quoting`[2], querying the
WikiMedia databases gives no match and the following errors in `dicod`:
```
root@harlock:~# /usr/bin/dicod --stderr -f
dicod: Info: dicod (GNU dico) 2.11 started
dicod: Info: Client info: "GNU dico 2.11"
dicod: Info: Client info: "GNU dico 2.11"
dicod: Debug: 57843 exited successfully
dicod: Info: Client info: "GNU dico 2.11"
dicod: Error: Traceback (most recent call last):
dicod: Error:   File "/usr/share/dico/python/mediawiki.py", line 98, in 
define_word
dicod: Error: wikiparser = TextWiktionaryMarkup (text=data)
dicod: Error:  
dicod: Error:   File "/usr/lib/python3/dist-packages/wikitrans/wiki2text.py", 
line 278, in __init__
dicod: Error: super(TextWikiMarkup, self).__init__(*args, **keywords)
dicod: Error:   File "/usr/lib/python3/dist-packages/wikitrans/wikimarkup.py", 
line 1028, in __init__
dicod: Error: self.text = keywords[kw].decode('utf-8').split("\n")
dicod: Error: ^^^
dicod: Error: AttributeError: 'str' object has no attribute 'decode'. Did you 
mean: 'encode'?
dicod: Debug: 57846 exited successfully
dicod: Debug: 57847 exited successfully
^Cdicod: Info: dicod (GNU dico) 2.11 terminating
root@harlock:~# 
```

[1] 
[2] 

I am not a Python expert, the problem obviously disappears (and the
query succeeds) if I remove the conditional case at line 1027, which
seems bad to me since AFAIK only from Python3 `str` contains by
default UTF-8/Unicode characters[3] (and anyway user input could not
be in UTF-8):
```
elif kw == 'text':
if sys.version_info[0] > 2:
self.text = keywords[kw].decode('utf-8').split("\n")
else:
self.text = keywords[kw].split("\n")
```

[3] 

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 
'stable'), (500, 'oldstable'), (100, 'bookworm-fasttrack'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-0.deb12.1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-wikitrans depends on:
ii  python3  3.11.2-1+b1

python3-wikitrans recommends no packages.

python3-wikitrans suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1056351: dicod: wrong quotes in MediaWiki snippets in `/etc/dicod.conf`

[Luca Capello]

Package: dicod
Version: 2.11-2+b3
Severity: important
Affects: dico-module-mediawiki
Tags: patch
Usertags: pca.it-communication

Hi there,

after the `load python` bug[1], I tried to configure some WikiMedia
databases using the `dicod`-commented M4 macros, without success:
```
root@harlock:~# /usr/bin/dicod --stderr -f
dicod: Error: /etc/dicod.conf:136.11-11: stray character `
dicod: Error: /etc/dicod.conf:136.14-14: stray character '
dicod: Error: /etc/dicod.conf:137.3-3: stray character `
dicod: Error: /etc/dicod.conf:137.20-20: stray character '
root@harlock:~# 
```

[1] 

NB, plain non-macro configurations as the ones in the
`dico-module-mediawiki`'s README.Debian allowed `dicod` to start.

In fact, after having read the `dico` upstream manual[2] I discovered
that for whatever reason (I am not an M4 neither a `dico` expert) the
wrong quoting characters ` and ' where used instead of [ and ][3],
albeit according to the M4 manual[4] ` and ' are indeed the M4 default
quoting characters.

[2] 
[3] 

[4] 

Thus, replacing `' with [] in the `wikipedia` and `wiktionary` M4
macro definitions was the first step to get something working, albeit
to have everything OK I could not be able to keep the `wiktionary` and
`wiktionary` macro names, attached the full patch.

However, two final notes:

1. the snippets in `dico-module-mediawiki`'s README.Debian are IMHO
   useless if `dicod.conf` contains commented M4 macros.

2. I would go for a even more generic MediaWiki M4 macro and not 2
   different ones, as shown in the included `/etc/dicod.conf`.

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 
'stable'), (500, 'oldstable'), (100, 'bookworm-fasttrack'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-0.deb12.1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dicod depends on:
ii  adduser3.134
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u3
ii  libcrypt1  1:4.4.33-2
ii  libdico2   2.11-2+b3
ii  libgsasl18 2.2.0-1
ii  libldap-2.5-0  2.5.13+dfsg-5
ii  libltdl7   2.4.7-5
ii  libpam0g   1.5.2-6+deb12u1
ii  libpcre3   2:8.39-15
ii  m4 1.4.19-3
ii  sysvinit-utils [lsb-base]  3.06-4
ii  zlib1g 1:1.2.13.dfsg-1

dicod recommends no packages.

Versions of packages dicod suggests:
pn  dico-doc 
pn  openbsd-inetd | inetutils-inetd  

-- Configuration Files:
/etc/dicod.conf changed:
capability (mime,xversion);
timing yes;
pidfile /var/run/dicod/dicod.pid;
listen localhost;
module-load-path ("/usr/lib/dico");
// Enable handling of databases in dict.org format:
load-module dictorg {
command "dictorg sort trim-ws dbdir=/usr/share/dictd";
}
// dicodconfig automatically generates the database sections for dictorg
// formatted dictionaries, the following line makes use of this facility:
// Uncomment the following to enable handling of databases in Emacs outline 
// format:
/* load-module outline {
command "outline";
}
*/
// Uncomment the following to enable Guile interface:
/* load-module guile {
command "guile";
}
*/
// Uncomment the following to enable Python modules (e.g. MediaWiki):
// 
load-module python {
command "python load-path=/usr/share/dico/python";
}
// Emacs outline database example:
/* database {
name "devdict";
handler "outline /usr/share/dico/outline/devils.out";
}
*/
// WikiMedia via `debpkg:dico-module-mediawiki`
// 
m4_define([defdbwikimedia], [
database {
name "$1";
handler "python load-path=/usr/share/dico/python init-script=mediawiki 
$2";
mime-headers <<- EOT
  Content-Type: text/x-wiki
  Content-Transfer-Encoding: quoted-printable
  X-Wiki-Language: $1
EOT;
m4_ifelse([$2],,,[
description "$2";])
m4_ifelse([$3],,,[
info <<- EOT
$3
EOT;])
}
])
defdbwikimedia(wikipedia-en,
  [en.wikipedia.org],
  [English language Wikipedia, a collaborative project to produce a
   free-content multilingual encyclopedia.])
defdbwikimedia(wikipedia-fr, [fr.wikipedia.org])

Bug#1050901: libc6:amd64: install /usr/lib64 without including it

[Luca Capello]

Package: libc6
Version: 2.31-13+deb11u6
Severity: minor
User: l...@pca.it
Usertags: unige.ch-backup
User: stor...@unige.ch
Usertags: unige.ch-backup

Hi there,

at UNIGE we use IBM Spectrum Protect (the old Tivoli Storage Manage) as
the central backup solution, on Debian-based machines via the upstream
Debian packages:

  
<https://public.dhe.ibm.com/storage/tivoli-storage-management/maintenance/client/v8r1/Linux/LinuxX86_DEB/BA/v8119/>

Now, `/var/lib/dpkg/info/gsk(crypt|ssl)64.postinst` checks if
`/usr/lib64` and it creates the `/usr/local/ibm/gsk8_64/lib64/lib*.so`
symlinks there.

This was not a problem on non-usrmerged Debian installations, as
confirmed by various machines of mine, since `/usr/lib64` was not
shipped/created by any package:
```
luca.capello@mantissa:~$ su -c 'etckeeper vcs log | tail -n 5' -
Password:
commit 5deed8583b1a65e9f80a9426496c2e707ce6c860
Author: Luca Capello 
Date:   Thu Dec 31 15:11:07 2009 +0100

initial commit
luca.capello@mantissa:~$ cat /etc/debian_version
11.7
luca.capello@mantissa:~$ dpkg-query -W libc6\*
libc6:amd64 2.31-13+deb11u6
libc6-amd64
libc6-dev-i386
libc6-i386  2.31-13+deb11u6
libc6-mips32
libc6-mips64
libc6-mipsn32
libc6-powerpc
libc6-ppc64
libc6-s390
libc6-sparc
libc6-sparc64
libc6-x32
luca.capello@mantissa:~$ ls -ld /lib* /usr/lib*
drwxr-xr-x 14 root root 4096 Aug  3 23:14 /lib
drwxr-xr-x  2 root root 4096 Aug  3 23:14 /lib32
drwxr-xr-x  2 root root 4096 Aug  3 23:14 /lib64
drwxr-xr-x 64 root root 4096 Aug  4 12:29 /usr/lib
drwxr-xr-x  3 root root 4096 Feb 26  2011 /usr/lib32
drwxr-xr-x  3 root root 4096 Aug  3 23:20 /usr/libexec
luca.capello@mantissa:~$ dpkg-query -S /lib64 /usr/lib64
libc6:amd64: /lib64
dpkg-query: no path found matching pattern /usr/lib64
luca.capello@mantissa:~$ grep -r lib64 /etc/ld.so.conf*
luca.capello@mantissa:~$ 
```

However, on a recent Debian 12/bookworm `/usr/lib64` is now present:
```
luca.capello@gundam:~$ su -c 'etckeeper vcs log | tail -n 5' -
Password:
commit ca2981887f6f7bfdbf7030e0a33c66a910013da5
Author: root 
Date:   Fri Aug 4 16:36:04 2023 +0200

Initial commit
luca.capello@gundam:~$ dpkg-query -W libc6\*
libc6:amd64 2.36-9+deb12u1
libc6-amd64
libc6.1
luca.capello@gundam:~$ ls -ld /lib* /usr/lib*
lrwxrwxrwx  1 root root7 Aug  4 16:28 /lib -> usr/lib
lrwxrwxrwx  1 root root9 Aug  4 16:28 /lib32 -> usr/lib32
lrwxrwxrwx  1 root root9 Aug  4 16:28 /lib64 -> usr/lib64
lrwxrwxrwx  1 root root   10 Aug  4 16:28 /libx32 -> usr/libx32
drwxr-xr-x 51 root root 4096 Aug  4 17:10 /usr/lib
drwxr-xr-x  2 root root 4096 Aug  4 16:28 /usr/lib32
drwxr-xr-x  2 root root 4096 Aug  4 16:28 /usr/lib64
drwxr-xr-x  6 root root 4096 Aug  4 16:31 /usr/libexec
drwxr-xr-x  2 root root 4096 Aug  4 16:28 /usr/libx32
luca.capello@gundam:~$ dpkg-query -S /lib64 /usr/lib64
libc6:amd64: /lib64
dpkg-query: no path found matching pattern /usr/lib64
luca.capello@gundam:~$ grep -r lib64 /etc/ld.so.conf*
luca.capello@gundam:~$ 
```

While the obvious solution would be for the TSM .debs...

  # echo '/usr/lib64' >/etc/ld.so.conf.d/local_tivsm_usr-lib64.conf

..,I wonder why `/usr/lib64` is not included by default.

Thx, bye,
Gismo / Luca

PS, I have looked in the BTS for already-reported bugs, the only ones I
have found are about FHS compliance and/or u`lib64 -> lib` symlinks:

- <https://bugs.debian.org/387446> (via 
<https://stackoverflow.com/questions/61205491/why-usr-lib64-is-not-in-the-default-location-of-ld-so#61216323>)
  => amd64 system not compliant with FHS
- <https://bugs.debian.org/612000>
  => libc6: please postinst symlink /usr/local/lib64 -> /usr/local/lib for 
consistency with /, and /usr ones
- <https://bugs.debian.org/632176>
  => libc6 should not provide /lib64 -> /lib symlink 
(amd64/kfreebsd-amd64/ppc64/sparc64)
- <https://bugs.debian.org/626450>
  => lost /lib64 -> /lib symlink on amd64; upgrade fails
- <https://bugs.debian.org/659064>
  => libc6 - Includes file in /lib64
- <https://bugs.debian.org/720780>
  => libc6:amd64: /usr/local/lib64 (required by FHS) doesn't exist

-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'oldstable'), (100, 
'bullseye-fasttrack'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-0.deb11.7-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6:amd64 depends on:
ii  libcrypt1  1:4.4.18-4
ii  libgcc-s1  10.2.1-6

Versions of packages libc6:amd6

Bug#1005878: s3curl: include --endpoint (and --servicePath) not-upstream patch

[Luca Capello]

Package: s3curl
Version: 20171008-1.1
Severity: wishlist
Tags: patch
User: l...@pca.it
Usertags: unige.ch-s3
User: stor...@unige.ch
Usertags: unige.ch-s3

Hi there,

while testing the UNIGE S3 internal instance (not provided by Amazon),
I discovered a patch adding support for the --endpoint (and
--servicePath) parameter :

  <https://github.com/rtdp/s3curl/pull/12>

Without this, the custom `endpoint` must be manually added in the Perl
code, so it could be a useful addition IMHO, especially considering that
at least another similar patch exists (albeit based on a fork of the
code above):

  <https://github.com/rtdp/s3curl/network>
   
<https://github.com/HeyImAllan/s3curl/commit/ffcb22956272071f093c009949bbb9e3eeb5a1c2>

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 
'oldstable'), (100, 'bullseye-fasttrack')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages s3curl depends on:
ii  curl 7.74.0-1.3+deb11u1
ii  libdigest-hmac-perl  1.03+dfsg-2.1
ii  libdigest-md5-file-perl  0.08-1.1
ii  libfindbin-libs-perl 2.190.02-1
ii  libgetopt-long-descriptive-perl  0.105-1

s3curl recommends no packages.

s3curl suggests no packages.

-- no debconf information

-- 
Dr. Luca Capello
Ingénieur stockage
Division du Système et des Technologies de l'Information et de la Communication
Université de Genève | 24 rue Général-Dufour | 1204 Genève
Tél +41 22 379 77 69 | Bureau 155
mailto:luca.cape...@unige.ch


signature.asc
Description: PGP signature

Bug#929418: screen: /run/screen isn't created

[Luca Capello]

Hi there,

I just got hit by the same bug upon a reboot after 486 days of uptime...

NB, this system booted for the first time with systemd after having
being upgraded from 9.12 to 10.3 on 2020-03-25 following the Debian
Release Notes!

On Fri, 24 May 2019 00:43:25 +0200, Axel Beckert wrote:
> Phil Dibowitz wrote:
> > Tried several reboots, it's very reproducible.
> 
> Thanks.

Same here.

> > I tried adding the '-' and also tried moving the file to /usr/lib,
> > either way nothing works.
> 
> Strange.

FWIW, I have two copies of the tmpfiles.d:
```
root@baloo:~# diff -u /etc/tmpfiles.d/screen-cleanup.conf
/usr/lib/tmpfiles.d/screen-cleanup.conf
--- /etc/tmpfiles.d/screen-cleanup.conf 2020-03-25 23:15:35.132326571
+0100
+++ /usr/lib/tmpfiles.d/screen-cleanup.conf 2021-02-20
21:36:23.0 +0100
@@ -1 +1 @@
-d /run/screen 1777 root utmp
+d /run/screen 0777 root utmp
root@baloo:~# dpkg-query -S /etc/tmpfiles.d/screen-cleanup.conf
dpkg-query: no path found matching pattern /etc/tmpfiles.d/screen-cleanup.conf
root@baloo:~# 
```

I am almost sure I have not manually created such a file, also
considering the following:
```
root@baloo:~# dpkg-query -W screen
screen  4.6.2-3+deb10u1
root@baloo:~# dpkg-statoverride --list | grep screen
root@baloo:~# ls -l $(command -v screen)
-rwxr-xr-x 1 root root 470024 Feb 20 21:59 /usr/bin/scree
root@baloo:~# 
```

And indeed the file has been recorded as "automatically installed"
during the stretch => buster upgrade following the Release Notes:
```
root@baloo:/etc# git log --raw tmpfiles.d/screen-cleanup.conf
commit 9078ca27a81123f0467023e2d0869e32a646cdeb
Author: root 
Date:   Wed Mar 25 23:26:50 2020 +0100

committing changes in /etc made by "apt full-upgrade"

Package changes:
-abcde 2.8.1-1 all
+abcde 2.9.3-1 all
-alsa-utils 1.1.3-1 amd64
-apache2 2.4.25-3+deb9u9 amd64
-apache2-bin 2.4.25-3+deb9u9 amd64
-apache2-data 2.4.25-3+deb9u9 all
-apache2-utils 2.4.25-3+deb9u9 amd64
-apt 1.4.9 amd64
-apt-listchanges 3.10 all
-apt-utils 1.4.9 amd64
-at 3.1.20-3 amd64
+alsa-utils 1.1.8-2 amd64
+apache2 2.4.38-3+deb10u3 amd64
+apache2-bin 2.4.38-3+deb10u3 amd64
+apache2-data 2.4.38-3+deb10u3 all
+apache2-utils 2.4.38-3+deb10u3 amd64
+apt 1.8.2 amd64
+apt-listchanges 3.19 all
+apt-utils 1.8.2 amd64
+at 3.1.23-1 amd64
-avahi-utils 0.6.32-2 amd64
+avahi-utils 0.7-4+b1 amd64
-bash 4.4-5 amd64
+bash 5.0-4 amd64
-bc 1.06.95-9+b3 amd64
[...]
-schroot-common 1.6.10-3+deb9u1 all
-screen 4.5.0-6 amd64
+scdaemon 2.2.19-2~bpo10+1 amd64
+schroot 1.6.10-6+b1 amd64
+schroot-common 1.6.10-6 all
+screen 4.6.2-3 amd64
-smbclient 2:4.5.16+dfsg-1+deb9u2 amd64
[...]
+w3m 0.5.3-37 amd64
-wget 1.18-5+deb9u3 amd64
+wget 1.20.1-1.1 amd64

:00 100644 000 eb1b9f8 Atmpfiles.d/screen-cleanup.conf
root@baloo:/etc# git reflog 
[...]
6b30163 HEAD@{77}: commit: committing changes in /etc made by "apt-get 
autoremove --purge"
9078ca2 HEAD@{78}: commit: committing changes in /etc made by "apt full-upgrade"
9c12e60 HEAD@{79}: commit: committing changes in /etc made by "apt-get upgrade"
aa69b01 HEAD@{80}: commit: apt/sources.list.d/ftp.ch.debian.org.list: 
s/stretch/buster/g
[...]
root@baloo:/etc# 
```

FWIW, the "null" systemd service is there, as per postinst[1]:
```
root@baloo:~# systemctl status screen-cleanup.service 
● screen-cleanup.service
   Loaded: masked (Reason: Unit screen-cleanup.service is masked.)
   Active: inactive (dead)
root@baloo:~# 
root@baloo:~# cat /lib/systemd/system/screen-cleanup.service 
root@baloo:~# ls -l /lib/systemd/system/screen-cleanup.service 
lrwxrwxrwx 1 root root 9 Aug 30  2018 
/lib/systemd/system/screen-cleanup.service -> /dev/null
root@baloo:~# dpkg-query -S /lib/systemd/system/screen-cleanup.service 
dpkg-query: no path found matching pattern 
/lib/systemd/system/screen-cleanup.service
root@baloo:~# 
```

[1] 

> > I tried running `systemd-tmpfiles --create --remove --boot
> > --exclude-prefix=/dev`, but it doesn't create /run/screen at all. No
> > matter how I ran it, I could not get it to create that directory.
> 
> Very strange. *frowning*

In my case the problem had nothing to do with screen, but instead with
an incorrect ownership of / (for a reason I still could not find out...)
and systemd-tmpfiles complaining, but the service not exiting with
errors, instead showing a useless message (thanks to the Internet for
the solution[2]):
```
root@baloo:~# systemctl status systemd-tmpfiles-setup.service
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
   Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static; 
vendor preset: enabled)
   Active: active (exited) since Sun 2021-07-25 14:21:56 CEST; 1min 5s ago
 Docs: man:tmpfiles.d(5)
   man:systemd-tmpfiles(8)
  Process: 749 

Bug#795244: ca-certificates-java.jar - String index out of range: -1

[Luca Capello]

tags 795244 + patch
thanks

Hi there,

On Thu, 12 Apr 2018 16:11:08 +0200, Raphael Hertzog wrote:
> On Wed, 12 Aug 2015, Christian Hammers wrote:
> > It does not work though:
> > 
> > # java -Xmx64m -jar 
> > /usr/share/ca-certificates-java/ca-certificates-java.jar -storepass changeit
> 
> That's because the program expects data on standard input. A list of
> certificates to add (prefixed with "+") or remove (prefixed with "-").
> 
> I'm not sure that there's a real issue here.

Thus, what is the purpose of the same command in
/etc/ca-certificates/update.d/jks-keystore?  As the reporter said the
command line was taken from that file.  Disclaimer: I am not a Java
expert...

While the /usr/share/doc/ca-certificates-java/README.Debian says that
the package "doesn't automagically handle local certificates" (as
Michael Shuler noted[1]), the solution is quite simple and can be
directly taken from postinst:
```
diff --git a/ca-certificates/update.d/jks-keystore 
b/ca-certificates/update.d/jks-keystore
index e0c3445..b5744ce 100755
--- a/ca-certificates/update.d/jks-keystore
+++ b/ca-certificates/update.d/jks-keystore
@@ -79,7 +79,19 @@ do_cleanup()
 fi
 }
 
-if java -Xmx64m -jar $JAR -storepass "$storepass"; then
+## <https://bugs.debian.org/795244>
+find /etc/ssl/certs -name \*.pem | \
+while read filename; do
+alias=$(basename $filename .pem | tr A-Z a-z | tr -cs a-z0-9 _)
+alias=${alias%*_}
+if [ -n "$FIXOLD" ]; then
+echo "-${alias}"
+echo "-${alias}_pem"
+fi
+echo "+${filename}"
+ done | \
+ java -Xmx64m -jar $JAR -storepass "$storepass"
+if [ $? -eq 0 ]; then
 do_cleanup
 else
 do_cleanup
```

[1] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795244#10>

The only drawback is that the cacerts default keystore will be updated
at every invocation of update-ca-certificates.

I am aware that the very same README advises to uses
`update-ca-certificates -f` for a full re-import, but IMHO the patch
proposed is more consistent with the "normal" update-ca-certificates
behavior.

Thx, bye,
Luca

-- 
Dr. Luca Capello
Ingénieur HPC
Division du Système et des Technologies de l'Information et de la Communication
Université de Genève | 24 rue Général-Dufour
Tél +41 22 379 72 42 | Bureau 151
https://hpc-community.unige.ch
mailto:luca.cape...@unige.ch


signature.asc
Description: PGP signature

Bug#787277: [ca-certificates] error on upgrade

[Luca Capello]

Hi Paride,.

On Sat, 30 May 2015 20:12:54 +, Paride Desimone wrote:
> today, I have upgraded sid.
> ca-certificates it has report:
> 
> Elaborazione dei trigger per ca-certificates (20150426)...
> Updating certificates in /etc/ssl/certs...
> 13 added, 6 removed; done.
> Running hooks in /etc/ca-certificates/update.d...
> 
> org.debian.security.InvalidKeystorePasswordException: Cannot open
> Java keystore. Is the password correct?

The output above is the expected behavior when changing the keystore
password without storing it in the "storepass" variable in
/etc/default/cacerts:

  <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823590#34>

If you have not modified the default password, 20150426 is quite old,
I had not installed it on any of my machines, so I can not check old
logs.  However, I have successfully upgraded from 20170929~deb9u1 to
20170929~deb9u3 (thus within stretch) and from 20170929~deb9u3 to
20190405 (stretch to buster), thus I would say that this bug could be
closed.

Thx, bye,
Luca

-- 
Dr. Luca Capello
Ingénieur HPC
Division du Système et des Technologies de l'Information et de la Communication
Université de Genève | 24 rue Général-Dufour
Tél +41 22 379 72 42 | Bureau 151
https://hpc-community.unige.ch
mailto:luca.cape...@unige.ch


signature.asc
Description: PGP signature

Bug#823590: ca-certificates: Having changed the keystore password (for server's security reaosons), update crashes

[Luca Capello]

tags 823590 - important + wishlist
found 823590 20190405
thanks

Hi there,

On Fri, 04 May 2018 22:58:16 +0200, Emmanuel Bourg wrote:
> Why are you changing the password of a keystore holding the public keys
> of the certification authorities? There is nothing secret inside.

Not speaking for Guillaume, but the Debian package explicitly supports
this configuration, for more than 10 years now:
```
root@harlock:~# zless /usr/share/doc/ca-certificates-java/changelog.gz 
[...]
ca-certificates-java (20081022) unstable; urgency=low

  * debian/jks-keystore.hook:
- Don't stop after first error during the update. LP: #244412.
  Closes: #489748.
- Call keytool with -noprompt.
  * On initial install, add locally added certificates. LP: #244410.
Closes: #489748.
  * Install /etc/default/cacerts to set options:
- storepass, holding the password for the keystore.
- updates, to enable/disable updates of the keystore.
  * Only use the keytool command from OpenJDK or Sun Java. Closes: #496587.

 -- Matthias Klose   Wed, 22 Oct 2008 20:51:24 +0200
[...]
root@harlock:~# ls -ld /etc/default/cacerts 
-rw--- 1 root root 384 Apr  2 14:03 /etc/default/cacerts
root@harlock:~# cat /etc/default/cacerts 
# defaults for ca-certificates-java

# The password which is used to protect the integrity of the keystore.
# storepass must be at least 6 characters long. It must be provided to
# all commands that access the keystore contents.
# Only change this if adding private certificates.
#storepass=''

# enable/disable updates of the keystore /etc/ssl/certs/java/cacerts
cacerts_updates=yes
root@harlock:~# 
```

Never mind, what Guillaume experienced is the expected behavior, the
fact that Guillaume would have liked a prompt for the password is a
wishlist feature, bug updated accordingly.

BTW, this is still true on buster as well, bug updated accordingly),
thanks to Pierre Deshayes here at unige.ch for the notice.

Thx, bye,
Luca

-- 
Dr. Luca Capello
Ingénieur HPC
Division du Système et des Technologies de l'Information et de la Communication
Université de Genève | 24 rue Général-Dufour
Tél +41 22 379 72 42 | Bureau 151
https://hpc-community.unige.ch
mailto:luca.cape...@unige.ch


signature.asc
Description: PGP signature

Bug#883263: Bug#884824: etckeeper: daily autocommit is run even though AVOID_DAILY_AUTOCOMMITS=1

[Luca Capello]

forcemerge 884824 904924
severity 884824 important
tags 884824 patch
block 883263 by 884824
thanks

Hi there,

On Wed, 20 Dec 2017 14:30:42 +1100, Martin Schwenke wrote:
> Following a suggestion, I found that if I run:
> 
>   systemctl stop etckeeper.timer

The systemd timer was activated just before you filed your report:

  <https://bugs.debian.org/883263>

And I got hit as well since 2 days, i.e. since I upgraded my **work**
machine from stretch to buster.

> Then it is no longer listed by "systemctl list-units".
> 
> I should have spent more time reading systemctl(1):

Nope, this is a bug in the /etc/etckeeper/daily shell script, which
does not respect /etc/etckeeper/etckeeper.conf, the patch is simple:
=
root@harlock:/etc# git log -1
commit 22dae914f53724d6bd36cd7c4fdd8d03f41f6c97 (HEAD -> master)
Author: root 
Date:   Wed Nov 20 18:49:56 2019 +0100

daily autocommit
root@harlock:/etc# git reset 8454274b14e8401f0d2f7f23973d13f971ee79a9
Unstaged changes after reset:
Mcron.daily/local_report-pointage.sh
Metckeeper/daily
Mfstab
Miptables/rules.v4
root@harlock:/etc# git diff etckeeper/daily
diff --git a/etckeeper/daily b/etckeeper/daily
index f98c6ad..2d291c7 100755
--- a/etckeeper/daily
+++ b/etckeeper/daily
@@ -2,6 +2,10 @@
 # Script that can be run daily to autocommit /etc changes.
 set -e
 if [ -x /usr/bin/etckeeper ] && [ -e /etc/etckeeper/etckeeper.conf ]; then
+   ## <https://bugs.debian.org/884824>
+   . /etc/etckeeper/etckeeper.conf
+   [ ${AVOID_DAILY_AUTOCOMMITS} -eq 0 ] || exit 0
+
# avoid autocommit if an install run is in progress
lockfile=/var/cache/etckeeper/packagelist.pre-install
if [ -e "$lockfile" ] && [ -n "$(find "$lockfile" -mtime +1)" ]; then
root@harlock:/etc# bash -x etckeeper/daily 
+ set -e
+ '[' -x /usr/bin/etckeeper ']'
+ '[' -e /etc/etckeeper/etckeeper.conf ']'
+ . /etc/etckeeper/etckeeper.conf
++ VCS=git
++ GIT_COMMIT_OPTIONS=
++ HG_COMMIT_OPTIONS=
++ BZR_COMMIT_OPTIONS=
++ DARCS_COMMIT_OPTIONS=-a
++ AVOID_DAILY_AUTOCOMMITS=1
++ AVOID_COMMIT_BEFORE_INSTALL=1
++ HIGHLEVEL_PACKAGE_MANAGER=apt
++ LOWLEVEL_PACKAGE_MANAGER=dpkg
++ PUSH_REMOTE=
+ '[' 1 -eq 0 ']'
+ exit 0
root@harlock:/etc# git status
On branch master
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

  modified:   cron.daily/local_report-pointage.sh
  modified:   etckeeper/daily
  modified:   fstab
  modified:   iptables/rules.v4

no changes added to commit (use "git add" and/or "git commit -a")
root@harlock:/etc# 
=

Thx, bye,
Gismo / Luca

-- 
Dr. Luca Capello
Ingénieur HPC
Division du Système et des Technologies de l'Information et de la Communication
Université de Genève | 24 rue Général-Dufour
Tél +41 22 379 72 42 | Bureau 151
https://hpc-community.unige.ch
mailto:luca.cape...@unige.ch


signature.asc
Description: PGP signature

Bug#773358: isc-dhcp-client: dhclient ipv4 ipv6 dualstack don't work well together

[Luca Capello]

Hi there,

On Wed, 17 Dec 2014 21:01:16 +0800, Andrew King wrote:
> I have a dual-stack home network, with ip6 & ip4 addresses provided by dhcp 
> from my router.
> However, by default I cannot get both interfaces to come up correctly
[...]
> In the order specified, the v4 and v6 addresses comes up fine, but the ipv6 
> dhcp overwrites /etc/resolv.conf (ignores the supersede lines)
[...]
> For now, I have added a hook in /etc/dhcp/dhclient-exit-hooks.d/ to recreate 
> resolv.conf using the ipv4 nameservers.

I guess the interaction between the two dhclient (IPv4 and IPv6) was
buggy, given that while setting up my fiber7.ch dual-stack home
connection I ended up with a similar problem, but with the "prepend"
option.

Basically, if you specify both...

  prepend domain-name-servers 127.0.0.1;
  prepend dhcp6.name-servers ::1;

...the first prepend (i.e. the IPv4 one) does not work.

The prepend issue is an upstream bug which should be fixed in 4.4.0
(only available in experimental, currently at 4.4.1-1):

  

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#901403: RM: xf86-video-glamo -- ROM; package broken since 2 years

[Luca Capello]

Hi there,

On Tue, 12 Jun 2018 17:24:22 +0200, Sebastian Reichel wrote:
> The source package does not build for "new" Xorg from 2016,
> has been removed from testing and was not part of last stable
> release. Upstream seems to be dead since 2011:
> 
> https://github.com/openmoko/xf86-video-glamo
> 
> FWIW I never worked on xf86-video-glamo myself, but I'm one of
> the last persons who worked on the FSO packages. I Cc'd the
> persons involved with glamo, so that they can intervene.

I was responsible back in 2009 for the first upload, but then Timo
Jyrinki and Gilles Filippini (both Bcc:ed) took care of it.  Also
because I left the pkg-fso team back in 2012:

  


And FWIW I was quite surprised this package was still in Debian, since I
know no other devices than the OpenMoko Neo FreeRunner using it (on
Debian).

I fully support its removal, also because of the two other serious bugs:

- 
  FTBFS with xserver 1.19

- 
  xf86-video-glamo: Invalid maintainer address 
pkg-fso-ma...@lists.alioth.debian.org

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#851059: Please provide instructions to use with current opennssl version

[Luca Capello]

forwarded 851059 https://github.com/OpenVPN/easy-rsa/issues/159
tags 851059 + fixed-upstream patch
thanks

Hi there,

On Wed, 11 Jan 2017 21:54:38 +0100, Yvan Masson wrote:
> easy-rsa currently does not provide openssl configuration file for the
> openssl version available in testing (1.1.*).

Upstream has already fixed this, but only in the 3.x branch.

Nevertheless, there are differences once the fixed file has been
reordered to match 1.0.0 one (files used to check attached as well).
However, IMHO all of such differences are not related to the OpenSSL
version, but to *default settings*, thus they should be treated
separately.

My proposed patch is the following, after having move openssl-1.0.0.cnf
to openssl-1.x.0.cnf:

--8<---cut here---start->8---
--- whichopensslcnf 2017-12-15 00:06:42.984954153 +0100
+++ whichopensslcnf   2017-12-15 00:06:25.552581087 +0100
@@ -7,8 +7,8 @@
 cnf="$1/openssl-0.9.6.cnf"
 elif $OPENSSL version | grep -E "0\.9\.8[[:alnum:]]?" > /dev/null; then
 cnf="$1/openssl-0.9.8.cnf"
-elif $OPENSSL version | grep -E "1\.0\.[[:digit:]][[:alnum:]]?" > 
/dev/null; then
-cnf="$1/openssl-1.0.0.cnf"
+elif $OPENSSL version | grep -E "1\.[01]\.[[:digit:]][[:alnum:]]?" > 
/dev/null; then
+cnf="$1/openssl-1.x.0.cnf"
 else
 cnf="$1/openssl.cnf"
 fi
--8<---cut here---end--->8---

I can confirm that with the above easy-rsa works with
openssl_1.1.0f-3+deb9u1 to generate all the basic files (DH, CA, server
and one client).

PLEASE NOTE THAT I AM NO SSL EXPERT, so the above patch (and generated
keys) should be audited at least once before distribution in the
official Debian package.

Thx, bye,
Gismo / Luca
# For use with Easy-RSA 3.0 and OpenSSL 1.0.*

RANDFILE= $ENV::EASYRSA_PKI/.rnd


[ ca ]
default_ca  = CA_default# The default ca section


[ CA_default ]

dir = $ENV::EASYRSA_PKI # Where everything is kept
certs   = $dir  # Where the issued certs are kept
crl_dir = $dir  # Where the issued crl are kept
database= $dir/index.txt# database index file.
new_certs_dir   = $dir/certs_by_serial  # default place for new certs.

certificate = $dir/ca.crt   # The CA certificate
serial  = $dir/serial   # The current serial number
crl = $dir/crl.pem  # The current CRL
private_key = $dir/private/ca.key   # The private key
RANDFILE= $dir/.rand# private random number file

x509_extensions = basic_exts# The extentions to add to the cert

# This allows a V2 CRL. Ancient browsers don't like it, but anything Easy-RSA
# is designed for will. In return, we get the Issuer attached to CRLs.
crl_extensions  = crl_ext

default_days= $ENV::EASYRSA_CERT_EXPIRE # how long to certify for
default_crl_days= $ENV::EASYRSA_CRL_DAYS# how long before next CRL
default_md  = $ENV::EASYRSA_DIGEST  # use public key default MD
preserve= no# keep passed DN ordering

# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy  = policy_anything

# For the 'anything' policy, which defines allowed DN fields
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName= optional
organizationName= optional
organizationalUnitName  = optional
commonName  = supplied
name= optional
emailAddress= optional


# Easy-RSA request handling
# We key off $DN_MODE to determine how to format the DN
[ req ]
default_bits= $ENV::EASYRSA_KEY_SIZE
default_keyfile = privkey.pem
default_md  = $ENV::EASYRSA_DIGEST
distinguished_name  = $ENV::EASYRSA_DN
x509_extensions = easyrsa_ca# The extentions to add to the self 
signed cert

# A placeholder to handle the $EXTRA_EXTS feature:
#%EXTRA_EXTS%   # Do NOT remove or change this line as $EXTRA_EXTS support 
requires it


# Easy-RSA DN (Subject) handling

# Easy-RSA DN for org support:
[ org ]
countryName = Country Name (2 letter code)
countryName_default = $ENV::EASYRSA_REQ_COUNTRY
countryName_min = 2
countryName_max = 2

stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = $ENV::EASYRSA_REQ_PROVINCE

localityName= Locality Name (eg, 

Bug#867877: clamav-daemon: please respect manual configuration

[Luca Capello]

severity 867877 minor
tags 867877 + upstream
thanks

Hi there,

On Sun, 20 Aug 2017 19:08:15 +0200, Sebastian Andrzej Siewior wrote:
> On 2017-07-10 23:39:53 [+0200], To Luca Capello wrote:
> > On 2017-07-10 11:40:20 [+0200], Luca Capello wrote:
> > > while debugging why the TCP socket was not responding, I discovered that
> > > everything was fine if clamd was manually started via the CLI.  And then
> > > I found <https://bugs.debian.org/771911>.
> > > 
> > > Please, this is becoming ridiculous:
> > > 
> > > - clamd works as expected with *its* own configuration
> > > - there is no documentation in /usr/share/doc/clamav-daemon about the
> > >   need to dpkg-reconfigure clamav-daemon to change parameters (and even
> > >   worse behavior)
> > > - non-Debian configuration via manual modifications or automatic tools
> > >   (e.g. <https://forge.puppet.com/edestecd/clamav>) is not respected
> > 
> > so what is the problem? You want additional documentation or somehow
> > changed behavior?
[...]
> > That systemd service file is part of upstream since a few releases. You
> > could argue if systemd's socket "feature" should be used or not or third
> > party tools extended to the extend.conf file in systemd's case. Or the
> > documentation updated.
> 
> If there is no feedback, I have no idea what I can/should do.

Given that no documentation was available, not even in the upstream
files, I was lost, so this would be the first improvement.

I was not aware that upstream chose the "full-systemd path", so I guess
changing that is a no-op, so at least the documentation must be fixed.

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#867877: clamav-daemon: please respect manual configuration

[Luca Capello]

:1.2.8.dfsg-2+b1

Versions of packages clamav-daemon recommends:
pn  clamdscan  

Versions of packages clamav-daemon suggests:
pn  apparmor 
pn  clamav-docs  
pn  daemon   

-- debconf information:
  clamav-daemon/FollowDirectorySymlinks: false
  clamav-daemon/TCPSocket: 3310
  clamav-daemon/FixStaleSocket: true
  clamav-daemon/AllowAllMatchScan: true
  clamav-daemon/StreamMaxLength: 25
  clamav-daemon/MaxZipTypeRcg: 1M
  clamav-daemon/MaxHTMLNoTags: 2M
  clamav-daemon/AddGroups:
  clamav-daemon/SelfCheck: 3600
  clamav-daemon/StatsPEDisabled: true
  clamav-daemon/ScanMail: true
  clamav-daemon/LogRotate: true
  clamav-daemon/BytecodeTimeout: 6
  clamav-daemon/StatsEnabled: false
  clamav-daemon/ForceToDisk: false
  clamav-daemon/DisableCertCheck: false
  clamav-daemon/OnAccessMaxFileSize: 5M
  clamav-daemon/TcpOrLocal: UNIX
  clamav-daemon/LocalSocketGroup: clamav
  clamav-daemon/ScanOnAccess: false
  clamav-daemon/ReadTimeout: 180
  clamav-daemon/FollowFileSymlinks: false
  clamav-daemon/Bytecode: true
  clamav-daemon/LogFile: /var/log/clamav/clamav.log
  clamav-daemon/User: clamav
  clamav-daemon/MaxThreads: 12
  clamav-daemon/MaxEmbeddedPE: 10M
  clamav-daemon/BytecodeSecurity: TrustSigned
  clamav-daemon/MaxDirectoryRecursion: 0
  clamav-daemon/LogSyslog: false
  clamav-daemon/StatsHostID: auto
  clamav-daemon/ScanSWF: true
  clamav-daemon/LogTime: true
  clamav-daemon/LocalSocketMode: 666
  clamav-daemon/debconf: true
  clamav-daemon/LocalSocket: /var/run/clamav/clamd.ctl
  clamav-daemon/MaxScriptNormalize: 5M
  clamav-daemon/MaxConnectionQueueLength: 15
  clamav-daemon/TCPAddr: any
  clamav-daemon/StatsTimeout: 10
  clamav-daemon/ScanArchive: true
  clamav-daemon/MaxHTMLNormalize: 10M

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#860602: ruby-net-ldap: FTBFS: ERROR: Test "ruby2.3" failed.

[Luca Capello]

tags 860602 + confirmed
tags 860602 + upstream
tags 860602 + patch
thanks

Hi,

On Wed, Apr 19, 2017 at 08:13:46AM +0200, Lucas Nussbaum wrote:
> Source: ruby-net-ldap
> Version: 0.12.1-1
> Severity: serious

Actually, this severity is questionable, the bug is not in the *build*
process, but in the *test* suite.  For the rationale, see:

  <https://lists.debian.org/871t0vzneq@hope.eyrie.org>

> Tags: stretch sid

We tested this on a clean sid chroot as well with *no* network during
the GULL BSP:

  <http://www2.linux-gull.ch/?q=node/23>

> Relevant part (hopefully):
> > /usr/bin/ruby2.3 /usr/bin/gem2deb-test-runner
> > 
> > ┌──┐
> > │ Run tests for ruby2.3 from debian/ruby-test-files.yaml
> >│
> > └──┘
> > 
> > RUBYLIB=/<>/debian/ruby-net-ldap/usr/lib/ruby/vendor_ruby:. 
> > GEM_PATH=debian/ruby-net-ldap/usr/share/rubygems-integration/all:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
> >  ruby2.3 -ryaml -e YAML.load_file\(\"debian/ruby-test-files.yaml\"\).each\ 
> > \{\ \|f\|\ require\ f\ \}
> > Loaded suite -e
> > Started
> > ..Deprecation warning: 
> > Net::LDAP::ConnectionRefused will be deprecated. Use Errno::ECONNREFUSED 
> > instead.
> > .Deprecation warning: Net::LDAP::ConnectionRefused will be deprecated. Use 
> > Errno::ECONNREFUSED instead.
> > Deprecation warning: Net::LDAP::ConnectionRefused will be deprecated. Use 
> > Errno::ECONNREFUSED instead.
> > Deprecation warning: Net::LDAP::ConnectionRefused will be deprecated. Use 
> > Errno::ECONNREFUSED instead.
> > Deprecation warning: Net::LDAP::ConnectionRefused will be deprecated. Use 
> > Errno::ECONNREFUSED instead.
> > F
> > ===
> > Failure: test_unresponsive_host(TestLDAPConnection)
> > /<>/test/test_ldap_connection.rb:64:in `test_unresponsive_host'
> >  61:   end
> >  62: 
> >  63:   def test_unresponsive_host
> >   => 64: assert_raise Net::LDAP::Error do
> >  65:   Net::LDAP::Connection.new(:host => 'test.mocked.com', :port 
> > => 636)

test.mocked.com does not respond on port 636:
=
rescue@debian:~$ ldapsearch -x -H ldaps://test.mocked.com
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
rescue@debian:~$ 
=

There are different solutions:

1) uncomment "export DH_RUBY_IGNORE_TESTS=all" in debian/rules

2) add "export RES_OPTIONS=attempts:0" do debian/rules, as per

 <https://lists.debian.org/20160929205427.4ormkscfms5gm...@jwilk.net>

3) comment test/test_ldap_connection.rb in debian/ruby-test-files.yaml
   (this seems the best solution)

However, even with network access and DNS resolution, the test does not
behave the same if the connection to test.mocked.com is possible or not.
This can be tested via `iptables -I OUTPUT -p tcp -m tcp -d
test.mocked.com -j $ACTION`:

* DROP, the test does not fail
* REJECT, the test fails

Nevertheless, if no one replies in 7 days, I will upload an NMU with the
solution 3 above (Git patch attached).

Thx, bye,
Gismo / Luca
>From 5e1b2c167c4608110461b10d46c91ba8bf9ee63b Mon Sep 17 00:00:00 2001
From: Luca Capello <l...@pca.it>
Date: Thu, 20 Apr 2017 23:56:23 +0200
Subject: [PATCH] debian/ruby-test-files.yaml: (#860602) comment LDAP

Signed-off-by: Luca Capello <l...@pca.it>
---
 debian/changelog| 7 +++
 debian/ruby-test-files.yaml | 3 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index d7c96dc..351daed 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ruby-net-ldap (0.12.1-2) UNRELEASED; urgency=medium
+
+  * debian/ruby-test-files:
++ comment test/test_ldap_connection.rb (Closes: #860602).
+
+ -- 
+
 ruby-net-ldap (0.12.1-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/ruby-test-files.yaml b/debian/ruby-test-files.yaml
index 1db6484..d5874e5 100644
--- a/debian/ruby-test-files.yaml
+++ b/debian/ruby-test-files.yaml
@@ -1,7 +1,8 @@
 --- 
 - test/test_entry.rb
 - test/test_filter.rb
-- test/test_ldap_connection.rb
+## <https://bugs.debian.org/860602>
+#- test/test_ldap_connection.rb
 - test/test_ldif.rb
 - test/test_password.rb
 - test/test_rename.rb
-- 
2.1.4

Bug#860024: apache2-bin: jessie-backports available

[Luca Capello]

/detail?id=557197>

And I could not find why ALPN would require OpenSSL >= 1.0.2f (despite a
lot of search results stating that), since ALPN is officially supported
by OpenSSL 1.0.2:

  <https://www.openssl.org/news/openssl-1.0.2-notes.html>

Nevertheless, jessie-backports has OpenSSL 1.0.2k, thus simply
installing openssl from jessie-backports should be enough to add
mod_ssl's SSLOpenSSLConfCmd (and "full" ALPN) support:
=
~# dpkg-query -W apache2
apache2 2.4.25-3~bpo8+1
~# dpkg-query -W apache2-bin
apache2-bin 2.4.25-3~bpo8+1
~# dpkg-query -W libssl1.0.0
libssl1.0.0:amd64   1.0.1t-1+deb8u6
~# apt-get install -t jessie-backports -s openssl
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libssl1.0.0
The following packages will be upgraded:
  libssl1.0.0 openssl
2 upgraded, 0 newly installed, 0 to remove and 74 not upgraded.
Inst libssl1.0.0 [1.0.1t-1+deb8u6] (1.0.2k-1~bpo8+1 Debian 
Backports:jessie-backports [amd64])
Inst openssl [1.0.1t-1+deb8u6] (1.0.2k-1~bpo8+1 Debian 
Backports:jessie-backports [amd64])
Conf libssl1.0.0 (1.0.2k-1~bpo8+1 Debian Backports:jessie-backports [amd64])
Conf openssl (1.0.2k-1~bpo8+1 Debian Backports:jessie-backports [amd64])
~#
=

Unfortunately, we do not have a test bed for HTTP/2 right now, could
someone please confirm this?

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#860024: apache2-bin: jessie-backports available

[Luca Capello]

Package: apache2-bin
Version: 2.4.25-3~bpo8+1
Severity: wishlist
User: product...@infomaniak.com
Usertag: infomaniak.com-apache

Hi there,

at work, we need HTTP/2 support in Apache, thus we backported the
following packages:

--8<---cut here---start->8---
spdylay (1.3.2-2.1~bpo8+1) jessie-backports; urgency=medium

  * Rebuild for jessie-backports.
  * debian/control:
+ add myself to Uploaders:.

 -- Luca Capello <luca.cape...@infomaniak.com>  Fri, 13 Jan 2017 17:02:19 +0100

--8<---cut here---end--->8---

--8<---cut here---start->8---
sphinxcontrib-rubydomain (0.1~dev-20100804-1~bpo8+1) jessie-backports; 
urgency=medium

  * Rebuild for jessie-backports.
  * debian/control:
+ add myself to Uploaders:.
  * debian/gbp.conf:
+ debian-branch=jessie-backports.

 -- Luca Capello <luca.cape...@infomaniak.com>  Wed, 01 Feb 2017 09:18:40 +0100

--8<---cut here---end--->8---

--8<---cut here---start->8---
nghttp2 (1.18.1-1~bpo8+1) jessie-backports; urgency=medium

  * Rebuild for jessie-backports.
  * debian/control:
+ add myself to Uploaders:.
+ add python-sphinxcontrib.rubydomain to Build-Depends:.

 -- Luca Capello <luca.cape...@infomaniak.com>  Thu, 09 Mar 2017 11:02:26 +0100

--8<---cut here---end--->8---

--8<---cut here---start->8---
apache2 (2.4.25-3~bpo8+1) jessie-backports; urgency=medium

  * Rebuild for jessie-backports.
  * debian/control:
+ add myself to Uploaders:.
+ remove libssl1.0-dev from Build-Depends:.
  * debian/gbp.conf:
+ debian-branch=jessie-backports.

 -- Luca Capello <luca.cape...@infomaniak.com>  Thu, 09 Mar 2017 11:41:18 +0100

--8<---cut here---end--->8---

We have not deployed them in production, yet, but they work with the
default php5 package in jessie.

Would someone (maintainers of the packages above X-Debbugs-Cc:ed) mind
if I upload them to the official Debian archive?

All the modifications have been made to a Git checkout of the official
Debian repositories, with signed commits and tags.  And I can provide
read-only access to such repositories, if someone would like to
integrate the modifications.

Thx, bye,
Gismo / Luca

-- Package-specific info:

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apache2-bin depends on:
ii  libapr1  1.5.1-3
ii  libaprutil1  1.5.4-1
ii  libaprutil1-dbd-sqlite3  1.5.4-1
ii  libaprutil1-ldap 1.5.4-1
ii  libc62.19-18+deb8u7
ii  libldap-2.4-22.4.40+dfsg-1+deb8u2
ii  liblua5.2-0  5.2.3-1.1
ii  libnghttp2-141.18.1-1~bpo8+1
ii  libpcre3 2:8.35-3.3+deb8u4
ii  libssl1.0.0  1.0.1t-1+deb8u6
ii  libxml2  2.9.1+dfsg1-5+deb8u4
ii  perl 5.20.2-3+deb8u6
ii  zlib1g   1:1.2.8.dfsg-2+b1

apache2-bin recommends no packages.

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  w3m [www-browser]0.5.3-19+deb8u1

Versions of packages apache2 depends on:
ii  apache2-data 2.4.25-3~bpo8+1
ii  apache2-utils2.4.25-3~bpo8+1
ii  dpkg 1.17.27
ii  init-system-helpers  1.22
ii  lsb-base 4.1+Debian13+nmu1
ii  mime-support 3.58
ii  perl 5.20.2-3+deb8u6
ii  procps   2:3.3.9-9

Versions of packages apache2 recommends:
ii  ssl-cert  1.0.35

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  w3m [www-browser]0.5.3-19+deb8u1

Versions of packages apache2-bin is related to:
ii  apache2  2.4.25-3~bpo8+1
ii  apache2-bin  2.4.25-3~bpo8+1

-- no debconf information

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#848110: openssh-server: Please add a note in the sshd_config file that UsePAM must be set to yes with systemd/logind

[Luca Capello]

user product...@infomaniak.com
usertag 751636 + infomaniak.com-authentication
usertag 848110 + infomaniak.com-authentication
block 848110 by 751636
thanks

Hi there,

On Wed, 14 Dec 2016 08:59:28 +0100, Laurent Bigonville wrote:
> In regard to bug #751636,

Even if (now) useless, I added a blocking relationship for the two bugs.

> shouldn't a warning be added in the
> sshd_config file above the UsePAM parameter that it needs to be set to
> "yes" (and have pam_systemd in the stack) otherwise it could cause some
> issues?

FWIW, UsePAM defaults to yes since 1:3.8.1p1-1:

--8<---cut here---start->8---
openssh (1:3.8.1p1-1) unstable; urgency=low
[...]
  * Make sure there's a newline at the end of sshd_config before adding
'UsePAM yes' (closes: #244829).
[...]
 -- Colin Watson <cjwat...@debian.org>  Tue, 11 May 2004 23:38:10 +0100
--8<---cut here---end--->8---

Thus, we need Suggests: libpam-systemd *and* the note either in the
sshd_config file or in the README.Debian.

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#822974: [pkg-gnupg-maint] Backport of GnuPG 2.1

[Luca Capello]

block 822974 by 834281
thanks

Hi Daniel,

On Wed, 08 Feb 2017 18:58:20 -0500, Daniel Kahn Gillmor wrote:
> On Wed 2017-02-08 15:05:09 -0500, Luca Capello wrote:
> 
> >> Daniel, what do you think about adding the jessie-backports branches I
> >> have locally to the corresponding Git repositories on Alioth?
> 
> I think this is a great idea.  gcrypt isn't in the pkg-gnupg git
> repos -- i don't know how Andreas wants to handle that.  But if you've
> got patch series you want to propose for the pkg-gnupg repos, please
> point me at them, either by sending them to this bug report, or by
> pointing me to some other git repos (personal repos on alioth are also
> fine), i can review and import them.

Anything that involves `git format-patch` is missing the OpenPGP
signatures for the commits/tags and this is a no-op, sorry ;-)

I am discussing at work to temporarily open up to the external world the
"needed" repositories hosted on our internal GitLab instance, so I will
be back soon with the links.

> > I will work on the GnuPG 2.1 backports ASAP and report back.
> 
> very much appreciated, thanks!  happy to chat on IRC if you run into any
> trouble.

Done:

--8<---cut here---start->8---
gnupg2 (2.1.18-3~bpo8+1) jessie-backports; urgency=medium

  * Rebuild for jessie-backports.
  * debian/clean:
- remove build-gpgv-win32.
  * debian/control:
+ add myself to Uploaders:.
- remove Build-Depends-Indep: and gpgv-win32 binary package,
  no libz-mingw-w64-dev.
- remove gpgv-static binary package, -pie errors with gcc4.9.
  * debian/gbp.conf:
+ add debian-branch=jessie-backports.
  * debian/rules:
- remove mingw-related variable and override_dh_auto_build-indep.
- remove gpgv-static-related variable and commands.

 -- Luca Capello <luca.cape...@infomaniak.com>  Tue, 28 Feb 2017 21:05:34 +0100

--8<---cut here---end--->8---

Some notes:

* 2.1.18-6, the current version in sid, has (still) not migrated.

* I wanted to reduce to a minimum the delta WRT to stretch.

* building the gpgv-win32 binary package is IMHO useless, AFAIK it is
  used only by the Windows' d-i and I would prefer the stretch version
  of the latter to be tested instead.

* any try to build the gpgv-static binary package ended with the same
  failure:

/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.9/crtbeginT.o:
 relocation R_X86_64_32 against `__TMC_END__' can not be used when
 making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtbeginT.o:
 error adding symbols: Bad value
collect2: error: ld returned 1 exit status

  "any try" (obviously) means playing with the GPGV_STATIC_HARDENING
  variable:


<https://anonscm.debian.org/git/pkg-gnupg/gnupg2.git/tree/debian/rules?h=debian/2.1.18-3#n17>
 
cd build-gpgv-static/g10 && /usr/bin/make LDFLAGS="$LDFLAGS "-pie" -static" 
gpgv
cd build-gpgv-static/g10 && /usr/bin/make LDFLAGS="$LDFLAGS -static" gpgv
cd build-gpgv-static/g10 && /usr/bin/make LDFLAGS="$LDFLAGS "-fPIC" 
-static" gpgv

  In the end, I decided to completely remove the gpg-static binary
  package, NEW since stretch and AFAIK only used on non-Debian-native
  GNU/Linux OSes.

* now the stage is for the Breaks: packages needing a jessie-backports
  as well:

  - debsig-verify (<< 0.15)
=> I have not used it yet

  - libgnupg-interface-perl (<< 0.52-3)
=> done (a simple rebuild to be uploaded soon, Debian Perl Group
   Bcc:ed, BTS updated), Depends: for signing-party and fixed to
   support GnuPG 2.1 by yourself:

 <https://bugs.debian.org/834281>
   
  - libmail-gnupg-perl (<= 0.22-1)
=> I have not used it yet

  - monkeysphere (<< 0.38~)
=> I have not used it yet, even if it was on my ToCheck list for SSH
   via OpenPGP A subkeys, but GnuPG 2.1 natively does the trick,
   even for on-disk subkeys.

  - php-crypt-gpg (<= 1.4.1-1)
=> I have not used it yet

  - python-apt (<= 1.1.0~beta4)
=> Depends: for apt-listchanges and debsecan

  - python3-apt (<= 1.1.0~beta4)
=> Depends: for gdebi and unattended-upgrade
  
  - python-gnupg (<< 0.3.8-3)
=> I have not used it yet

* I have not tested yet the binary packages because of the python*-apt
  Breaks: on all my machines, but I will soon set up a test chroot for
  that.

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#568375: [pkg-gnupg-maint] Bug#568375: gnupg-agent: does not work with `git tag -s`

[Luca Capello]

Hi there,

On Sun, 12 Feb 2017 18:47:15 -0500, Daniel Kahn Gillmor wrote:
> On Sun 2017-02-12 16:52:29 -0500, Luca Capello wrote:
> > Actually, even worse, commit does not work with gnupg2_2.1.11-7:
> >
> >   <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822974#35>
> 
> I'm surprised to see a report about 2.1.11-7 on 2017-02-12 when that
> package was superceded 10 days ago by 2.1.18-3.  Is there a reason that
> you're using 2.1.11-7, which is no longer in debian?

Yes, AFAIK it is the only way to have GnuPG 2.1 (to have gpg-agent
forwarding) on jessie, as I explained in the other bug report I linked.
This is also why I am working on the jessie-backports ;-)

> > What is funny is that if I plug my YubiKey 4 (basically an OpenPGP
> > smartcard) everything (commit + tag) is fine (tested on 2 different
> > jessie).
> 
> If this report is strictly about the yubikey smartcard, we should
> reassign it to scdaemon.  Does "git tag -S" work for you when you are
> *not* using a smartcard?

Oh, sorry if I was not clear enough: no, `git tag -S` does now work
without the YubiKey.

Given that I had actually missed Mickael's second post...

  <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568375#20>

...I tried everything again, starting with a fresh-new ~/.gnupg with
GnuPG 1:
=
$ gpg --version | head -n 1
gpg (GnuPG) 1.4.18
$ gpg --list-secret-keys
$HOME/.gnupg/secring.gpg
-------
sec#  4096R/E397832F 2009-07-01
uid  Luca Capello <l...@pca.it>
uid  Luca Capello <gi...@debian.org>
uid  Luca Capello <luca.cape...@infomaniak.ch>
uid  Luca Capello <luca.cape...@infomaniak.com>
ssb   4096R/3BE9F36D 2009-07-01
ssb#  4096R/2BB95F4B 2009-07-01
ssb>  4096R/675E1031 2016-02-22
ssb>  4096R/A0ACD061 2016-02-22
ssb>  4096R/D18542FA 2016-02-22
$ grep -v -e '^#' -e '^$' ~/.gnupg/gpg.conf
keyserver hkp://keys.gnupg.net
$ echo 'use-agent' >>~/.gnupg/gpg.conf
$ eval $(gpg-agent --daemon)
gpg-agent[13561]: directory $HOME/.gnupg/private-keys-v1.d' created
gpg-agent[13562]: gpg-agent (GnuPG) 2.1.11 started
$ mkdir test.git
$ cd test.git/
$ git init
Initialized empty Git repository in $HOME/test.git/.git/
$ echo 'test file' >file.txt
$ git add file.txt
$ git commit -m 'file.txt: new file'
gpg: pcsc_establish_context failed: no service (0x8010001d)
gpg: card reader not available
gpg: signing failed: general error
gpg: signing failed: general error
error: gpg failed to sign the data
fatal: failed to write commit object
$ git config --global user.signingkey 3BE9F36D
$ git commit -m 'file.txt: new file'
[error as above]
$ gpg --sign file.txt
[error as above]
$ gpg --default-key 3BE9F36D --sign file.txt
[error as above]
$ gpg --default-key E397832F --sign file.txt
[error as above]
$ gpg --default-key 3BE9F36D! --sign file.txt

You need a passphrase to unlock the secret key for
user: "Luca Capello <l...@pca.it>"
4096-bit RSA key, ID 3BE9F36D, created 2009-07-01 (main key ID E397832F)

gpg: gpg-agent is not available in this session
$ 
=

WTF?

=
$ export GPG_TTY=$(tty)
$ gpg --default-key 3BE9F36D! --sign file.txt
[...]
gpg: gpg-agent is not available in this session
$ unset GPG_TTY
$ export GPG_AGENT_INFO="$HOME/.gnupg/S.gpg-agent"
$ gpg --default-key 3BE9F36D! --sign file.txt
[...]
gpg: malformed GPG_AGENT_INFO environment variable
$ export GPG_AGENT_INFO="$HOME/.gnupg/S.gpg-agent:1"
$ gpg --default-key 3BE9F36D! --sign file.txt
[...]
gpg: gpg-agent protocol version 0 is not supported
$ export GPG_AGENT_INFO="$HOME/.gnupg/S.gpg-agent:2"
$ gpg --default-key 3BE9F36D! --sign file.txt
[...]
gpg: gpg-agent protocol version 0 is not supported
$ ls -l ~/.gnupg/private-keys-v1.d/
total 0
$
=

OK, so I guess everything is as expected.

Let me try with the YubiKey:
=
[insert the YubiKey]
$ gpg --card-status
[...]
General key info..: pub  4096R/675E1031 2016-02-22 Luca Capello <l...@pca.it>
[...]
$ git config --unset --global user.signingkey 3BE9F36D
$ unset GPG_AGENT_INFO
$ git commit -m 'file.txt: new file'
gpg: signatures created so far: 1799

Please enter the PIN
[sigs done: 1799]
gpg: gpg-agent is not available in this session
Enter PIN:
gpg: Interrupt caught ... exiting

$ export GPG_TTY=$(tty)
$ git commit -m 'file.txt: new file'
[same as above]
$ git commit -m 'file.txt: new file'
gpg: signatures created so far: 1799

Please enter the PIN
[sigs done: 1799]
gpg: gpg-agent is not available in this session
[master (root-commit) 74bff88] file.txt: new file
 1 file changed, 1 insertion(+)
 create mode 100644 file.txt
$ git tag -s -m 'test file' test_file
gpg: signatures created so far: 1800

Please enter the PIN
[sigs done: 1800]
gpg: gpg-agent is not available in this session
$ 
=

Similar to #802586, ssh works fine:
=
$ pkill gpg

Bug#568375: gnupg-agent: does not work with `git tag -s`

[Luca Capello]

found 568375 2.1.11-7
thanks

Hi there,

On Thu, 12 Jan 2017 11:59:34 +0100, Michal Hocko wrote:
> On Sun, Mar 20, 2016 at 12:12:00AM -0400, Peter Colberg wrote:
> > On Thu, Feb 04, 2010 at 12:32:21PM +0100, Luca Capello wrote:
> > > It seems that `git tag -s` and gpg-agent fails to cooperate and do not
> > > show the pinentry dialog (in my case the -curses variant inside screen):
[...]
> > While this comes too late for signing the tag of your submitted thesis
> > (congratulations!), this is likely caused by a missing GPG_TTY variable.
> > 
> > https://www.gnupg.org/documentation/manuals/gnupg/Common-Problems.html
> > 
> > The gpg-agent man page nowadays includes the following hint:
> > 
> >   It is important to set the GPG_TTY environment variable in your login
> >   shell, for example in the ‘~/.bashrc’ init script:
> > 
> >   export GPG_TTY=$(tty)
>
> So I've tried this and it didn't help.
> $ export GPG_TTY=$(tty)

Actually, even worse, commit does not work with gnupg2_2.1.11-7:

  <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822974#35>

=
$ mkdir test.git
$ cd test.git/
$ git init
Initialized empty Git repository in $HOME/test.git/.git/
$ echo 'test file' >file.txt
$ git add file.txt
$ export GPG_TTY=$(tty)
$ git commit -m 'file.txt: new file'
gpg: signing failed: Card error
gpg: signing failed: Card error
error: gpg failed to sign the data
fatal: failed to write commit object
$ gpg --version | head -n 1
gpg (GnuPG) 2.1.11
$ gpg --sign file.txt
gpg: using "139121880F512EC2E6A464D3D91D57A03BE9F36D!" as default secret key 
for signing
$
=

What is funny is that if I plug my YubiKey 4 (basically an OpenPGP
smartcard) everything (commit + tag) is fine (tested on 2 different
jessie).

BTW, the above gpg message about default secret key is actually useless
 and it is a result of having to specifying the default-key:
 
   <https://bugs.debian.org/829246>

> $ git tag -s -u $ID ...
> 
> I get the password dialog but nothing really happens after then.
> 
> 16699 pts/1S+ 0:00 git tag -s -u B310E347
> 16700 pts/1SL+0:00   gpg --status-fd=2 -bsau B310E347
> 
> gpg is stuck waiting for an input

Is that GnuPG 1 or GnuPG 2?

> nothing really more, so it seems that the process is looping in the userspace.
> Is there any way to disable gpg-agent altogether?

Not with GnuPG 2+.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#822974: [pkg-gnupg-maint] Backport of GnuPG 2.1

[Luca Capello]

Hi there !

Adding Daniel Pocock and Robert Lange to Cc:, sorry if I forgot to do it
with my first reply to this bug.

On Sat, 28 Jan 2017 23:18:10 +0100, Luca Capello wrote:
> > >   libassuan-dev
> 
> --8<---cut here---start->8---
> libassuan (2.4.3-2~bpo8+1) jessie-backports; urgency=medium

In the archive since 2017-02-06:

  <https://lists.debian.org/msgid-search/e1cag5s-0008mz...@fasolo.debian.org>

> > >   libgcrypt20-dev
> 
> "[2017-01-26] Accepted 1.7.6-1 in unstable (medium) (Andreas Metzler)"
> 
> Cc:ing the Debian GnuTLS Maintainers list and Bcc:ing Andreas Metzler
> who did the upload: is that version target for stretch, so the one I
> should backport for GnuPG 2?

--8<---cut here---start->8---
libgcrypt20 (1.7.6-1~bpo8+1) jessie-backports; urgency=medium

  * Rebuild for jessie-backports.
  * debian/control:
+ add myself to Uploaders:.
- remove mingw-w64 and libgpg-error-mingw-w64-dev from
  Build-Depends-Indep: and libgcrypt-mingw-w64-dev binary package,
  no libgpg-error-mingw-w64-dev.
  * debian/rules:
- remove mingw-related instructions from override_dh_auto_build-indep
  and override_dh_auto_install-indep.

 -- Luca Capello <luca.cape...@infomaniak.com>  Wed, 08 Feb 2017 10:04:20 +0100
--8<---cut here---end--->8---

Working fine on 2 jessie-backports with gnupg2_2.1.11-7, it will be
uploaded at the end of the week.

> > >   libgpg-error-dev
> 
> "[2017-01-18] Accepted 1.26-2 in unstable (medium) (Daniel Kahn Gillmor)"
> 
> I guess this is the version intended for stretch, right?

--8<---cut here---start->8---
libgpg-error (1.26-2~bpo8+1) jessie-backports; urgency=medium

  * Rebuild for jessie-backports.
  * debian/control:
+ add myself to Uploaders:.
  * debian/gbp.conf:
+ add debian-branch=jessie-backports.

 -- Luca Capello <luca.cape...@infomaniak.com>  Wed, 08 Feb 2017 17:40:35 +0100
--8<---cut here---end--->8---

Working fine on 2 jessie-backports with gnupg2_2.1.11-7, it will be
uploaded at the end of the week.

Please note that I have also built the mingw-related binaries for
libgpg-error, which means that the other backports I did can be
"upgraded" to build the corresponding mingw-related binaries
(libgpg-error-mingw-w64-dev was a Build-Depends-Indep:), if needed.

> > >   libksba-dev
>
> --8<---cut here---start->8---
> libksba (1.3.5-2~bpo8+1) jessie-backports; urgency=medium

In the archive since 2017-02-06:

  <https://lists.debian.org/msgid-search/e1cag5s-0008nc...@fasolo.debian.org>

> > >   libnpth0-dev
> 
> --8<---cut here---start->8---
> npth (1.3-1~bpo8+1) jessie-backports; urgency=medium

In the archive singe 2017-02-06:

  <https://lists.debian.org/msgid-search/e1cag5t-0008nb...@fasolo.debian.org>

> Daniel, what do you think about adding the jessie-backports branches I
> have locally to the corresponding Git repositories on Alioth?

Still valid, as well as for the other packages (Bcc:ing Eric Dorland).

I will work on the GnuPG 2.1 backports ASAP and report back.

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#824532: [Pkg-auth-maintainers] Bug#848327: RFS: libu2f-host/1.1.3-1

[Luca Capello]

Hi there,

On Fri, 27 Jan 2017 23:08:08 +0100, Nicolas Braud-Santoni wrote:
> On Sun, Dec 25, 2016 at 03:29:39PM +0100, Luca Capello wrote:
> > 
> > sorry for the late reply, the package was rejected:
> > 
> >   
> > <http://lists.alioth.debian.org/pipermail/pkg-auth-maintainers/Week-of-Mon-20161212/000953.html>
> 
> Sorry for the even-more-late reply, I was ill the last few months  :(
> 
> I built a new version of the package
> that has updated copyright metadata.

Thank you.

> > However, can you first push your changes to the Git repository on
> > Alioth?  I find awkward not to use it for Debian work...
> 
> It is in the rfs-848327 branch on alioth.

Again, thank you, two comments not related to the udev rules:

- there are neither upstream/1.1.3 nor debian/1.1.3-1 tags on Alioth,
  which BTW is still missing the upstream and pristine-tar branches, so
  no new binary packages can be built from the Alioth Git repository:

<https://github.com/Yubico/libu2f-host-dpkg/branches>

- the previous rejection was because of a new license for the CLI tools,
  while in the debian/changelog you actually talk about the library
  itself, which has always been LGPL-2+:


<https://github.com/Yubico/libu2f-host/commit/9f53f3ccf81d3e5029eca863014714bf217914e1>

Both issues should be corrected for me to sponsor your upload.

> > > This updates brings:
> > > - - a fix for #846358, so that rules for the right udev version are 
> > > installed;
> > > - - as per #846359 and #824532, this creates a new binary package,
> > >   libu2f-common, containing the udev rules;
> > > - - the new upstream version brings udev rules for additional devices.
> > 
> > Sorry, I still do not see the reasoning behing such a move:
> > 
> >   <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824532#42>
> 
> Well, that one is simple:
> 
> - #846358 is a bug, pure and simple, and this fixes it.

As far as I know, no one has never objected to this and the fix does not
involve touching anything else WRT the current logic.

> - Before this upload, the udev rules were shipped in the libu2f-host0
>   binary package, which is again wrong.

It depends, it would be OK if access to these devices was only possible
via libu2f-host0, which is not the case here:

  <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824532#17>

> There are two options, then
> 
>   1. keeping the udev rules in the libu2f-host *source* package
>   2. moving the udev rules to another source package
> 
> 
> I am strongly in favor of 1, if only because upstream actually maintains
> that list in this package.  The alternative involves
>   - repackaging libu2f-host to get rid of this
> (and patching the build/install scripts),

Sorry?  No need to repack or patch anything from upstream, but simple do
not install the udev rules in a .deb package.

>   - adding the udev rules to some other package,
> likely as a Debian patch,
>   - and keeping the udev rules up-to-date in that other package,
> manually, forever.
> 
> Moreover, in the case where the other source package is udev,
> this adds a lot of synchronisation overhead in maintaining libu2f-host
> because I can't just push the udev rules in udev's packaging repo
> and upload a new version of the package ...

Thanks to Andreas Gnau for the upstream bug:

  <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848327#40>
<https://github.com/systemd/systemd/issues/102>

I find interesting that the end user has been waiting for more than 2
years now for the specific U2F kernel driver (and I guess/hope the right
permissions):

  
<http://lists.freedesktop.org/archives/systemd-devel/2014-November/024824.html>

> > Mickael or Martin (both Bcc:ed), can you elaborate a bit more, please?
> > Yes, I have read the full bug and I fully agree with Robert and Simon
> > (both Bcc:ed), moreover:
> >
> > [...]
> > 
> > 2) U2F devices are becoming more and more frequent and they are
> >considered by at least Google (who, to be fair, co-developed the
> >standard) to be the more secure 2FA mechanism:
> > 
> >  
> > <http://arstechnica.com/security/2016/12/this-low-cost-device-may-be-the-worlds-best-hope-against-account-takeovers/>
> >  <http://fc16.ifca.ai/preproceedings/25_Lang.pdf>
> 
> I'm not sure I see the point there.

The point is that I am expecting more and more people using such
devices, which means that someone plugs her U2F device into a GNU/Linux
system and it can not use it in the web browser because of the missing
permissions.

Robert Norris explained very clearly where such permissions belong to:

  <https://bugs.debian.org/cgi-bin/bugreport.cgi

Bug#822974: [pkg-gnupg-maint] Backport of GnuPG 2.1

[Luca Capello]

user product...@infomaniak.com
usertag 849845 + infomaniak.com-authentication
thanks

Hi Daniel,

On Wed, 18 Jan 2017 02:37:51 -0500, Daniel Kahn Gillmor wrote:
> On Mon 2017-01-16 16:14:01 -0500, Luca Capello wrote:
> > Any news on this?  At work we have recently deployed OpenPGP (via
> > YubiKey 4) for all the sysadmins, installing GnuPG 2 on jessie with the
> > following trick:
> 
> there is a known bug (in particular, 849845, upstream 2902) affecting
> dirmngr in stretch and sid, which makes it very difficult for certain
> common configurations to retrieve keys from the network. i'm reluctant
> to inflict them on jessie users, and am hoping to get that resolved
> before we go with the backport.

Thank you for the explanation, I see that the bug has been reassigned to
tor since the dirmngr part has been fixed, very good.

Nevertheless, IMHO a GnuPG 2 was anyway useful, since it would have not
affectced the main functionality (i.e. signing, encrypting and SSH, even
with a YubiKey/smartcard).  To be clear, your call for the official
backport ;-)

> > From a quick look, the following are the Build-Depends: needing a
> > backport as well:

FWIW, for the jessie-backports below I decided to:

- use debhelper from jessie-backports as well, instead of having a
  bigger delta.
- remove all mingw-related binary packages, because other than missing
  dependencies, I do not think they are useful for their primary target,
  i.e. d-i on Windows.

> >   libassuan-dev

--8<---cut here---start->8---
libassuan (2.4.3-2~bpo8+1) jessie-backports; urgency=medium

  * Rebuild for jessie-backports.
  * debian/control:
+ add myself to Uploaders:.
+ remove Build-Depends-Indep: and libassuan-mingw-w64-dev binary
  package, no libgpg-error-mingw-w64-dev.
  * debian/gbp.conf:
+ add debian-branch=jessie-backports.

 -- Luca Capello <luca.cape...@infomaniak.com>  Sat, 28 Jan 2017 16:12:37 +0100

--8<---cut here---end--->8---

Working fine on my jessie-backports with gnupg2_2.1.11-7.

> >   libgcrypt20-dev

"[2017-01-26] Accepted 1.7.6-1 in unstable (medium) (Andreas Metzler)"

Cc:ing the Debian GnuTLS Maintainers list and Bcc:ing Andreas Metzler
who did the upload: is that version target for stretch, so the one I
should backport for GnuPG 2?

> >   libgpg-error-dev

"[2017-01-18] Accepted 1.26-2 in unstable (medium) (Daniel Kahn Gillmor)"

I guess this is the version intended for stretch, right?  If so, I will
wait for it to migrate to stretch before doing the backport (ATM "Too
young, only 9 of 10 days old").

> >   libksba-dev

--8<---cut here---start->8---
libksba (1.3.5-2~bpo8+1) jessie-backports; urgency=medium

  * Rebuild for jessie-backports.
  * debian/control:
+ add myself to Uploaders:.
    + remove Build-Depends-Indep: and libksba-mingw-w64-dev binary package,
  no libgpg-error-mingw-w64-dev.

 -- Luca Capello <luca.cape...@infomaniak.com>  Sat, 28 Jan 2017 22:39:02 +0100
--8<---cut here---end--->8---

Working fine on my jessie-backports with gnupg2_2.1.11-7.

> >   libnpth0-dev

--8<---cut here---start->8---
npth (1.3-1~bpo8+1) jessie-backports; urgency=medium

  * Rebuild for jessie-backports.
  * debian/control:
+ add myself to Uploaders:.
+ remove Build-Depends-Indep: and libnpth-mingw-w64-dev binary package,
  "/usr/bin/i686-w64-mingw32-ld: .libs/libnpth-0.dll.def:5: syntax error".
  * debian/gbp.conf:
+ add debian-branch=jessie-backports.

 -- Luca Capello <luca.cape...@infomaniak.com>  Sat, 28 Jan 2017 16:48:34 +0100
--8<---cut here---end--->8---

Working fine on my jessie-backports with gnupg2_2.1.11-7.

I will upload the three backports above at the beginning of the next
week after having tested them again at work and if no one says anything
before.

Daniel, what do you think about adding the jessie-backports branches I
have locally to the corresponding Git repositories on Alioth?

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#822974: [pkg-gnupg-maint] Backport of GnuPG 2.1

[Luca Capello]

Hi Daniel,

On Thu, 06 Oct 2016 10:23:25 -0400, Daniel Kahn Gillmor wrote:
> On Thu 2016-10-06 05:17:54 -0400, Thomas Goirand wrote:
> > It'd be nice to have a backport of GnuPG 2.1 to Jessie, so that one
[...]
> https://bugs.debian.org/822974
> 
> last week, the changes i was waiting for did indeed drop into testing,
> but we have a few minor bugs that i'm in the process of cleaning up
> which i'd like to avoid inflicting on users of jessie-backports.
> 
> It'll happen soon, i promise :)

Any news on this?  At work we have recently deployed OpenPGP (via
YubiKey 4) for all the sysadmins, installing GnuPG 2 on jessie with the
following trick:
=
# cat >/etc/apt/sources.list.d/snapshot.debian.org.list <http://snapshot.debian.org/archive/debian/20160424T221003Z/ stretch main
EOF
# etckeeper commit 'apt/sources.list.d/snapshot.debian.org.list: new file 
(GnuPG_2.1)'
# apt-get -o Acquire::Check-Valid-Until=false update
[apt-cache show dirmngr -> Depends: libgnutls30 -> too many debpkg to update]
# apt-get install \
libassuan0=2.4.2-3 libgcrypt20=1.7.0-2 \
gnupg2=2.1.11-7 gnupg-agent=2.1.11-7 scdaemon=2.1.11-7 \
paperkey
# apt-mark auto libassuan0 libgcrypt20
# apt-get autoremove --purge
# sed -i -e 's/^\(deb.*20160424T221003Z.*\)/#\1/' 
/etc/apt/sources.list.d/snapshot.debian.org.list
# etckeeper commit 'apt/sources.list.d/snapshot.debian.org.list: comment 
GnuPG_2.1'
# apt-get update
# if ! apt-cache policy gnupg2 | grep -q stretch; then
echo "OK"
else
echo "E: stretch sources always present."
exit 1
fi
# 
=

From a quick look, the following are the Build-Depends: needing a
backport as well:

  libassuan-dev
  libgcrypt20-dev
  libgpg-error-dev
  libksba-dev
  libnpth0-dev

I have started working on libassuan-dev and go on if no one else is
doing that already, the idea being a *full* bakcport, i.e. completely
replacing GnuPG 1.

Thx, bye,
Gismo / Luca

--
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#814218: lua-ldap: Add support for Lua 5.2

[Luca Capello]

tags 814218  + moreinfo
thanks

Hi there,

sorry for the delay, mostly due to real life and the fact that the
servers (with Prosody + lua-ldap) I administer are still on wheezy.

On Tue, 09 Feb 2016 14:33:53 +0530, Avinash Sultanpur wrote:
> The pdns-recursor is compiled with liblua5.2-0 and this package does
> not have support for Lua 5.2 which makes it unusable with Power DNS.
> 
> There are a couple of open pull requests on Github which add support
> for Lua 5.2. Please merge them in order to support Lua 5.2.
> 
> https://github.com/luaforge/lualdap/pulls

I am sorry, but after having tried for 2 weeks now I have given up
trying to understand where the lualdap sources reside, here some
comments:

- 

  AFAIK still the "official" repository, but development has never
  started on it, except for the 2 pulls requests.

  Yet, there are 13 forks on GitHub only!

- 
  
   


  If I read history correctly, some of the more prominent forks, now all
  stalled.

- 
   

  I do not understand why 2 different repositories from the same author
  and no indications that they are the same :-(

- 

  This should be the official follow-up, but as far as I could see
  nothing from the other forks (nor even the "official" one by
  bdellegrazie) has been integrated:


 

  Indeed, on LuaRocks the bdellegrazie's fork is listed:


  
- 
   

  A very recent fork, wait, not even a Git fork but history rewritten...
  
I am aware of the poor maintenance in Debian, entirely due to my fault,
at least in term of all-the-upstream-sources following.

IMHO the best thing should be to ask for removal, especially given the
various upstream sources and to not give a false idea of what is being
installed.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#824532: [Pkg-auth-maintainers] Bug#848327: RFS: libu2f-host/1.1.3-1

[Luca Capello]

reopen 848327
block 824532 by 846359
user product...@infomaniak.com
usertag 824532 + infomaniak.com-authentication
thanks

Hi there,

sorry for the late reply, the package was rejected:

  
<http://lists.alioth.debian.org/pipermail/pkg-auth-maintainers/Week-of-Mon-20161212/000953.html>

On Fri, 16 Dec 2016 11:58:51 +0100, Nicolas Braud-Santoni wrote:
> I am looking for a sponsor for my package "libu2f-host":

Nicolas, as a (new) member of the pkg-auth team, I can sponsor you
without the need to file RFS bugs for that.

However, can you first push your changes to the Git repository on
Alioth?  I find awkward not to use it for Debian work...

  <https://anonscm.debian.org/cgit/pkg-auth/libu2f-host.git/>

> This updates brings:
> - - a fix for #846358, so that rules for the right udev version are installed;
> - - as per #846359 and #824532, this creates a new binary package,
>   libu2f-common, containing the udev rules;
> - - the new upstream version brings udev rules for additional devices.

Sorry, I still do not see the reasoning behing such a move:

  <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824532#42>

Mickael or Martin (both Bcc:ed), can you elaborate a bit more, please?
Yes, I have read the full bug and I fully agree with Robert and Simon
(both Bcc:ed), moreover:

1) U2F devices are seen as *keyboards*, not a special U2F *device*
   (please anyone correct me if I am wrong), and udev already contains
   exceptions with more-specific devices like iDRACs...

2) U2F devices are becoming more and more frequent and they are
   considered by at least Google (who, to be fair, co-developed the
   standard) to be the more secure 2FA mechanism:

 
<http://arstechnica.com/security/2016/12/this-low-cost-device-may-be-the-worlds-best-hope-against-account-takeovers/>
 <http://fc16.ifca.ai/preproceedings/25_Lang.pdf>

3) some of them are even more than that (e.g. the YubiKey 4 which also
   contains an OpenPGP smartcard), which justify the fact that udev
   rules do not belong to any U2F-specific package:

 <https://wiki.debian.org/Smartcards/YubiKey4#udev>

FYI, IMHO this is a udev upstream bug.

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#793101: Yubikey core error: no yubikey present

[Luca Capello]

Hi there,

On Mon, 03 Oct 2016 15:14:46 +0200, Simon Josefsson wrote:
> fre 2016-09-30 klockan 16:50 +0200 skrev Moritz Muehlenhoff:
> > On Wed, Aug 10, 2016 at 09:30:04AM +0200, Simon Josefsson wrote:
> > > fixed 793101 1.16.2-1
> > > thanks
> > > 
> > > The 1050:0403 device was not supported before 1.16.2-1, so you need
> > > that or a later version.  So this is an upstream wishlist request that
> > > has been resolved.
> > 
> > Can support for the Yubikey 4 be backported to jessie? This currently
> > presents the use of ykpersonalize on stable with the current model.
> 
> Uploads to jessie-backports would indeed be great.   Cc'ing Nicolas who
> has expressed interest to help maintaining these packages.  Would you
> like to work on that?  Getting an update into a minor jessie releases
> might be relevant goal as well.

As the main author of the YubiKey 4 wiki page[1] and given the recent
interest for the YubiKey 4 at work[2], I have successfully prepared a
jessie-backports for 1.17.3-1 (no changes needed).

[1] <https://wiki.debian.org/Smartcards/YubiKey4>
[2] 
<http://lists.alioth.debian.org/pipermail/pkg-auth-maintainers/Week-of-Mon-20161212/000951.html>

I do not have time right now to test with a "clean" (out-of-factory)
YubiKey 4 (the one with me ATM is already in production state) and the
jessie on my laptop already had 1.17.2-1 debpkg from stretch.  However,
everything seems to work as expected:
=
$ dpkg-query -W yubikey-personalization
yubikey-personalization 1.17.3-1~bpo8+1
$ dpkg-query -W \* | grep 1.17.3-1~bpo8+1
libykpers-1-1:amd64  1.17.3-1~bpo8+1
yubikey-personalization 1.17.3-1~bpo8+1
$ ykinfo -V
1.17.3
$ ykinfo -a
serial: NNN
serial_hex: NNN
serial_modhex: NNN
version: 4.2.7
touch_level: 519
programming_sequence: 3
slot1_status: 1
slot2_status: 1
vendor_id: 1050
product_id: 407
$
=

I will try to do extra tests ASAP and then upload to backports if
everything is OK.  Obviously, the debpkg are available for any tests
on private request.

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#689350: brasero: couldn't burn audio cd - dependencies issues

[Luca Capello]

forcemerge 594522 689350
found 594522 3.11.4-1.1
thanks

Hi,

On Mon, 01 Oct 2012 21:40:25 +0200, Martin Dosch wrote:
> while last brasero-upgrade the packages brasero-cdrkit dvdauthor genisoimage
> growisofs wodim got removed.
> Now I wanted to burn an audio cd and it didn't work, the audio cd got ejected
> immediately.
> After I reinstalled the packages brasero-cdrkit dvdauthor genisoimage 
> growisofs
> wodim everything worked fine again.

This is a known issue, see  (bugs
merged), still present on jessie (BTS updated).

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#808433: nethogs STILL crashes in STABLE (Jessie), two months after bug was closed

[Luca Capello]

fixed 808433 0.8.1-1~bpo8+1
user product...@infomaniak.com
usertag 808433 + infomaniak.com-network
thanks

Hi there,

On Sun, 12 Jun 2016 10:01:20 +0200, S. G. wrote:
> I'm desparately waiting to see this fix in jessie.
> 
> Is there a schedule for patching 0.8.0?

No need for a jessie-pu, the problem is fixed for us using the
jessie-backports package (bug updated).

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#827947: reprepro: processincoming errors because of uncommented echo in changelogs.example

[Luca Capello]

tags 827947 + patch
thanks

Hi there,

On Thu, 23 Jun 2016 09:11:16 +0200, Luca Capello wrote:
> Tested patch as soon as this bug get a number :-)

Here we are:

--8<---cut here---start->8---
From 92d022a49103d164121f20b548f929681e62b919 Mon Sep 17 00:00:00 2001
From: Luca Capello <luca.cape...@infomaniak.com>
Date: Thu, 23 Jun 2016 09:25:11 +0200
Subject: [PATCH] docs/changelogs.example: (#827947) comment echo

---
 debian/changelog| 7 +++
 docs/changelogs.example | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 1304fde..3feeaf5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+reprepro (4.17.1-2) UNRELEASED; urgency=medium
+
+  * docs/changelogs.example:
++ comment echo to avoid processincoming errors (Closes: #827947).
+
+ -- Luca Capello <luca.cape...@infomaniak.com>  Thu, 23 Jun 2016 09:22:35 +0200
+
 reprepro (4.17.1-1) unstable; urgency=medium
 
   * new bugfix release
diff --git a/docs/changelogs.example b/docs/changelogs.example
index 4897dc0..33917a3 100755
--- a/docs/changelogs.example
+++ b/docs/changelogs.example
@@ -101,7 +101,7 @@ addsource() {
SUBDIR="$(basename $TARGETDIR)"
BASEDIR="$(dirname $TARGETDIR)"
if ! [ -d "$TARGETDIR" ] ; then
-   echo "extract $CANONDSCFILE information to $TARGETDIR"
+#  echo "extract $CANONDSCFILE information to $TARGETDIR"
mkdir -p -- "$TARGETDIR"
EXTRACTDIR="$(mktemp -d)"
(cd -- "$EXTRACTDIR" && dpkg-source --no-copy -x 
"$CANONDSCFILE" > /dev/null)
-- 
2.1.4

--8<---cut here---end--->8---

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#827947: reprepro: processincoming errors because of uncommented echo in changelogs.example

[Luca Capello]

Package: reprepro
Version: 4.16.0-1
Severity: minor
File: /usr/share/doc/reprepro/examples/changelogs.example.gz
User: product...@infomaniak.com
Usertags: infomaniak.com-packaging

Hello,

the title says all, here the output:
=
reprepro@rhone:~/infomaniak$ bash -x 
/home/reprepro/bin/processincoming-repository.sh -r infomaniak -i incoming -s
+ SNAPSHOTS=false
+ BASEDIR=/home/reprepro
+ REPREPRO=/usr/bin/reprepro
+ getopts :r:i:sh opt
+ case $opt in
+ REPOSITORY=infomaniak
+ getopts :r:i:sh opt
+ case $opt in
+ RULESETNAME=incoming
+ getopts :r:i:sh opt
+ case $opt in
+ SNAPSHOTS=true
+ getopts :r:i:sh opt
+ shift 5
+ '[' -z infomaniak -o -z incoming ']'
+ cd /home/reprepro/infomaniak
++ ls -1 incoming/isc-kea_1.0.0-3~bpo8+1_amd64.changes
+ CHANGES_FILES=incoming/isc-kea_1.0.0-3~bpo8+1_amd64.changes
+ for I in '$CHANGES_FILES'
++ awk '{print $2}'
++ grep Distribution incoming/isc-kea_1.0.0-3~bpo8+1_amd64.changes
+ CODENAME=jessie-backports
+ '[' -z jessie-backports ']'
+++ basename incoming/isc-kea_1.0.0-3~bpo8+1_amd64.changes
++ /usr/bin/reprepro -b /home/reprepro/infomaniak processincoming incoming 
isc-kea_1.0.0-3~bpo8+1_amd64.changes
+ PROCESSINCOMING='extract 
/home/reprepro/infomaniak/pool/main/i/isc-kea/isc-kea_1.0.0-3~bpo8+1.dsc 
information to changelogs/pool/main/i/isc-kea/isc-kea_1.0.0-3~bpo8+1
Exporting indices...'
+ '[' 'xextract 
/home/reprepro/infomaniak/pool/main/i/isc-kea/isc-kea_1.0.0-3~bpo8+1.dsc 
information to changelogs/pool/main/i/isc-kea/isc-kea_1.0.0-3~bpo8+1
Exporting indices...' '!=' 'xExporting indices...' ']'
++ basename incoming/isc-kea_1.0.0-3~bpo8+1_amd64.changes
+ echo 'E: incoming for 
infomaniak/jessie-backports/incoming/isc-kea_1.0.0-3~bpo8+1_amd64.changes not 
processed'
E: incoming for 
infomaniak/jessie-backports/incoming/isc-kea_1.0.0-3~bpo8+1_amd64.changes not 
processed
+ exit 1
reprepro@rhone:~/infomaniak$
=

Tested patch as soon as this bug get a number :-)

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 8.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.18.30-imu (SMP w/1 CPU core)
Locale: LANG=3D3DC, LC_CTYPE=3D3DC (charmap=3D3DANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages reprepro depends on:
ii  libarchive13 3.1.2-11+deb8u1
ii  libbz2-1.0   1.0.6-7+b3
ii  libc62.19-18+deb8u4
ii  libdb5.3 5.3.28-9
ii  libgpg-error01.17-3
ii  libgpgme11   1.5.1-6
ii  liblzma5 5.1.1alpha+20120614-2+b3
ii  pinentry-curses  0.8.3-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages reprepro recommends:
ii  apt  1.0.9.8.3

Versions of packages reprepro suggests:
ii  gnupg-agent  2.0.26-6
pn  inoticoming  
pn  lzip 

-- no debconf information

--=20
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA

--zhXaljGHf11kAtnf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXaR/iAAoJEPN4NMBnXhAxPoIP/AhZlf9ZNq96S31JBgMqviZw
iKOPx38A4BORrrfry8lPVwaUjRc9XQBIgfypntU0+eV0MguMiGMJ+lHmId3H+KuZ
Pyp2yXh3vD0Lu9XMhkYKeqdk8hVhMenlaaqecFygzZue0P2m5vK5S/yTomFjAKnf
Z/p/YqQdhIV0vhGhhB4UVGKgY9DJ9mgX9+R0hG/qyTbSbFTnyyqfIaDWqZkL+w71
Vfmmf5QqHcH/Rbk0DjVimuJJ7dpyt69O8wZL9DXCa3hjwqkhct7dJcWePdnzoClM
uZUSESIBJCNUTt0VcSHMPtFTcO3WvH3soufWfrKIm0jtN5+fvWe0RuxA4tsFvLum
Z/URsEjYMATxJR3Y8Z3O4GH9KGcizXkgJW6dWr4rq1sLXWjRLkotnPT0mwSdRX/u
8AN6ZDCYq9/lW7vVw5kjHLqyqz6uJy7Qbq6a1hNIm4tdtQX3wXCy45oZ3Ea5CldM
sFJauHitzd6VMow4sldrDL9P1fMDeEwMLklcJdRRzzSJtd3V6Bgx5x5zahTuiFXt
wPf8D9RavFpHSic6ZMPj+NC92443UpTKwvoe6AQENUuwJkpZV9f9tG9dKcI69rPA
Aht6eyQ0avmIJ+bAGU4WfK09SOP8Gh1/EPNDn216+3unJjLtTO54cl0fiiExnDUh
EQ/l9QXYvGf1qPrFyH7h
=5Ul/
-END PGP SIGNATURE-

--zhXaljGHf11kAtnf--

dsfsdfd

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#827816: reprepro: add mail-changes.example to notify when (at least) 'accepted' packages

[Luca Capello]

tags 827816 + patch
thanks

On Tue, 21 Jun 2016 13:07:17 +0200, Luca Capello wrote:
> Tested patch for ACTION=3Daccepted (thus to be extended later on) as soon
> as this bug get a number :-)

Here we are:

--8<---cut here---start->8---
From 044e268f9bd32f18165014667a8f3284cecab0ee Mon Sep 17 00:00:00 2001
From: Luca Capello <luca.cape...@infomaniak.com>
Date: Tue, 21 Jun 2016 13:17:23 +0200
Subject: [PATCH] docs/mail-changes.example: (#827816) new file

---
 debian/changelog  |  7 +
 debian/examples   |  1 +
 docs/mail-changes.example | 69 +++
 3 files changed, 77 insertions(+)
 create mode 100755 docs/mail-changes.example

diff --git a/debian/changelog b/debian/changelog
index 1304fde..14c0ea3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+reprepro (4.17.1-2) UNRELEASED; urgency=medium
+
+  * debian/examples, docs/mail-changes.example:
++ new file to notify processing of .changes files (Closes: #827816).
+
+ -- Luca Capello <luca.cape...@infomaniak.com>  Tue, 21 Jun 2016 13:16:06 +0200
+
 reprepro (4.17.1-1) unstable; urgency=medium
 
   * new bugfix release
diff --git a/debian/examples b/debian/examples
index 8754d4d..afc97a7 100644
--- a/debian/examples
+++ b/debian/examples
@@ -7,3 +7,4 @@ docs/copybyhand.example
 docs/outstore.py
 docs/sftp.py
 docs/outsftphook.py
+docs/mail-changes.example
diff --git a/docs/mail-changes.example b/docs/mail-changes.example
new file mode 100755
index 000..2402aaf
--- /dev/null
+++ b/docs/mail-changes.example
@@ -0,0 +1,69 @@
+#!/bin/sh
+#
+#
+# Copyright 2016 Luca Capello <luca.cape...@infomaniak.com>
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02111-1301  USA
+#
+#
+# This is an example script that can be hooked into reprepro
+# to send an email after a .changes file is processed.
+#
+# All you have to do is to:
+# - copy it into you conf/ directory,
+# - add the following to any distribution in conf/distributions
+#   you want to have emails sent for:
+#Log:
+# --changes mail-changes.example
+# (note the space at the beginning of the second line).
+#
+# DEPENDENCIES: mailx
+
+
+set -e
+
+
+if test "x${REPREPRO_OUT_DIR:+set}" = xset ; then
+   # Note: due to cd, REPREPRO_*_DIR will no longer
+   # be usable. And only things relative to outdir will work...
+   cd "${REPREPRO_OUT_DIR}" || exit 1
+else
+   # this will also trigger if reprepro < 3.5.1 is used,
+   # in that case replace this with a manual cd to the
+   # correct directory...
+   cat "mail-accepted.example needs to be run by reprepro!" >&2
+   exit 1
+fi
+
+
+MAIL_TO="$USER"
+
+ACTION="$1"
+CODENAME="$2"
+PACKAGENAME="$3"
+PACKAGEVERSION="$4"
+CHANGESFILE="$5"
+
+if [ "x$ACTION" = "xaccepted" ]; then
+   MAIL_FROM="$(grep Changed-By $CHANGESFILE | \
+ sed -e 's/Changed-By/From/')"
+   ARCHITECTURE="$(grep Architecture $CHANGESFILE | \
+sed -e 's/Architecture: //')"
+   MAIL_SUBJECT="Accepted $PACKAGENAME $PACKAGEVERSION ($ARCHITECTURE) 
into $CODENAME"
+   cat "$CHANGESFILE" | \
+    mail -a "$MAIL_FROM" -s "$MAIL_SUBJECT" "$MAIL_TO"
+fi
+
+
+exit 0
-- 
2.1.4

--8<---cut here---end--->8---

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#827816: reprepro: add mail-changes.example to notify when (at least) 'accepted' packages

[Luca Capello]

Package: reprepro
Version: 4.16.0-1
Severity: wishlist
User: luca.cape...@infomaniak.com
Usertags: infomaniak.com-packaging

Hello,

as the title suggests, I would like to have a way to get an email
every time a .changes file is processed, similar to what happens for the
official Debian archive:

  <https://lists.debian.org/e1yupfs-0004fw...@franck.debian.org>

Tested patch for ACTION=3Daccepted (thus to be extended later on) as soon
as this bug get a number :-)

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 8.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.18.30-imu (SMP w/1 CPU core)
Locale: LANG=3DC, LC_CTYPE=3DC (charmap=3DANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages reprepro depends on:
ii  libarchive13 3.1.2-11+deb8u1
ii  libbz2-1.0   1.0.6-7+b3
ii  libc62.19-18+deb8u4
ii  libdb5.3 5.3.28-9
ii  libgpg-error01.17-3
ii  libgpgme11   1.5.1-6
ii  liblzma5 5.1.1alpha+20120614-2+b3
ii  pinentry-curses  0.8.3-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages reprepro recommends:
ii  apt  1.0.9.8.3

Versions of packages reprepro suggests:
ii  gnupg-agent  2.0.26-6
pn  inoticoming  
pn  lzip 

-- no debconf information

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#827753: emacs24-common: [upstream #19731] /dev/null is deleted by tramp-sh.el

[Luca Capello]

Package: emacs24-common
Version: 24.4+1-5
Severity: important
File: /usr/share/emacs/24.4/lisp/net/tramp-sh.elc
Tags: upstream fixed-upstream patch
Forwarded: -1 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19731#56
User: luca.cape...@infomaniak.com
Usertags: infomaniak.com-editor

Hi there,

the title says all, and since it causes a lot of processes on the remote
server to fail it should be fixed ASAP (still present on unstable).

I have locally added the following small patch (not yet tested, though):

--8<---cut here---start->8---
--- /usr/share/emacs/24.4/lisp/net/tramp-sh.el.gz
+++ /home/users/luca.capello/.emacs.d/lisp/tramp-sh.el
@@ -3735,7 +3735,8 @@
  (setq extra-args (cdr item
   (tramp-send-command
vec (format
-   "exec env ENV='' HISTFILE=/dev/null PROMPT_COMMAND='' PS1=%s PS2='' 
PS3='' %s %s"
+   ;; <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19731#56>
+   "exec env ENV='' HISTFILE=.tramp_history PROMPT_COMMAND='' PS1=%s 
PS2='' PS3='' %s %s"
(tramp-shell-quote-argument tramp-end-of-output)
shell (or extra-args ""))
t))
@@ -4467,7 +4468,7 @@
(delete-process p))
  (setenv "TERM" tramp-terminal-type)
  (setenv "LC_ALL" "en_US.utf8")
- (setenv "HISTFILE" "/dev/null")
+ (setenv "HISTFILE" ".tramp_history")
  (setenv "PROMPT_COMMAND")
  (setenv "PS1" tramp-initial-end-of-output)
  (let* ((target-alist (tramp-compute-multi-hops vec))
--8<---cut here---end--->8---

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs24-common depends on:
ii  dpkg1.17.27
ii  emacsen-common  2.0.8
ii  install-info5.2.0.dfsg.1-6

emacs24-common recommends no packages.

Versions of packages emacs24-common suggests:
pn  emacs24-common-non-dfsg  
ii  emacs24-el   24.4+1-5

-- no debconf information


signature.asc
Description: Digital signature

Bug#826957: sbuild: should allow SUITE-VARIANT for "SUITE named SUITE-backports" chroot

[Luca Capello]

retitle 826957 sbuild: should allow SUITE-VARIANT for "SUITE named 
SUITE-VARIANT" chroot
tags 826957 + patch
thanks

On Fri, 10 Jun 2016 16:40:55 +0200, Luca Capello wrote:
> Tested patch as soon as this bug get a number :-)

Here we are:

--8<---cut here---start->8---
From 64f6338bb906134951d9b84d8f5370399a6b6767 Mon Sep 17 00:00:00 2001
From: Luca Capello <luca.cape...@infomaniak.com>
Date: Fri, 10 Jun 2016 16:52:21 +0200
Subject: [PATCH] bin/sbuild-createchroot: (#826957) add support for
 SUITE-VARIANT

---
 bin/sbuild-createchroot  | 12 +++-
 man/sbuild-createchroot.8.in |  2 ++
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/bin/sbuild-createchroot b/bin/sbuild-createchroot
index efcfe04..68244ad 100755
--- a/bin/sbuild-createchroot
+++ b/bin/sbuild-createchroot
@@ -173,11 +173,13 @@ $conf->set('INCLUDE', add_items($conf->get('INCLUDE'),
"build-essential",
"debfoster"));
 
-my $suite = $ARGV[0];
+# Deal with SUITE-VARIANT
+my $suitevariant = $ARGV[0];
+(my $suite = $suitevariant) =~ s/-.*//;
 
 # check if schroot name is already in use
 
-my $chrootname = "${suite}-" . $conf->get('BUILD_ARCH') . 
$conf->get('CHROOT_SUFFIX');
+my $chrootname = "${suitevariant}-" . $conf->get('BUILD_ARCH') . 
$conf->get('CHROOT_SUFFIX');
 
 open my $pipe, 'schroot -l --all-source-chroots |';
 while (my $line = <$pipe>) {
@@ -301,7 +303,7 @@ if ($conf->get('MAKE_SBUILD_TARBALL')) {
 $config_entry = <<"EOF";
 [$chrootname]
 type=file
-description=Debian $suite/$arch autobuilder
+description=Debian $suitevariant/$arch autobuilder
 file=$tarball
 groups=root,sbuild
 root-groups=root,sbuild
@@ -324,7 +326,7 @@ EOF
 [$chrootname]
 type=directory
 $uniontype
-description=Debian $suite/$arch autobuilder
+description=Debian $suitevariant/$arch autobuilder
 directory=$target
 groups=root,sbuild
 root-groups=root,sbuild
@@ -467,7 +469,7 @@ if ($conf->get('MAKE_SBUILD_TARBALL')) {
 }
 }
 
-print "I: Successfully set up $suite chroot.\n";
+print "I: Successfully set up $suitevariant chroot.\n";
 print "I: Run \"sbuild-adduser\" to add new sbuild users.\n";
 
 exit 0;
diff --git a/man/sbuild-createchroot.8.in b/man/sbuild-createchroot.8.in
index 25e4996..75a1783 100644
--- a/man/sbuild-createchroot.8.in
+++ b/man/sbuild-createchroot.8.in
@@ -135,6 +135,8 @@ empty string to disable signature checking.
 The distribution to bootstrap (e.g. \[oq]sarge\[cq], \[oq]etch\[cq],
 \[oq]lenny\[cq], \[oq]sid\[cq]).  A complete list may be found in
 \fI/usr/share/debootstrap/scripts\fP.
+The special syntax \fISUITE-VARIANT\fP is also supported, which will creates a
+chroot for \fISUITE\fP, but named \fISUITE-VARIANT\fP.
 .TP
 .B TARGET-DIRECTORY
 The directory to create the chroot in.  The directory will be created if it
-- 
2.1.4

--8<---cut here---end--->8---

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#826957: sbuild: should allow SUITE-VARIANT for "SUITE named SUITE-backports" chroot

[Luca Capello]

Package: sbuild
Version: 0.65.2-1
Severity: wishlist
User: luca.cape...@infomaniak.com
Usertags: infomaniak.com-packaging

Hi there,

there is no way to create a variant of a SUITE chroot, which would be
quite helpful to create SUITE-backports chroots.

Tested patch as soon as this bug get a number :-)

Thx, bye,
Gismo / Luca

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 8.5
  APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.18.30-imu (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages sbuild depends on:
ii  adduser 3.113+nmu3
ii  apt-utils   1.0.9.8.3
ii  libsbuild-perl  0.65.2-1
ii  perl5.20.2-3+deb8u5

Versions of packages sbuild recommends:
ii  debootstrap  1.0.67
ii  fakeroot 1.20.2-1

Versions of packages sbuild suggests:
pn  deborphan  
ii  wget   1.16-1

-- no debconf information

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#826847: [buildd-tools-devel] Bug#826847: sbuild: override default debootstap's /etc/apt/sources.list

[Luca Capello]

reopen 826847
severity 826847 minor
tags 826847 + patch
thanks

Hi Raphael,

On Thu, 09 Jun 2016 22:37:39 +0200, Raphael Hertzog wrote:
> On Thu, 09 Jun 2016, Luca Capello wrote:
> > Thank you, I missed that "apt-get build-dep" requires deb-src.
> > 
> > And for "apt-get source" I forgot that by default sbuild builds binary
> > packages, which means that the sources could already be in the archive.
> > 
> > Tagging the bug as wontfix (not really a bug) and closing it, thank you
> > for the explanation.  I have just added the sources to our internal APT
> > mirror ;-)
> 
> Note that sbuild works fine without "deb-src" lines if you feed it a .dsc.
> It grabs build dependencies directly from the extracted source package.
> 
> So your initial request might still make some sense.

Finally, very easy to implement, off by default:

--8<---cut here---start----->8---
From a286347700c10f3a681db06a732cf09afa40d91f Mon Sep 17 00:00:00 2001
From: Luca Capello <luca.cape...@infomaniak.com>
Date: Fri, 10 Jun 2016 13:05:51 +0200
Subject: [PATCH] bin/sbuild-createchroot: (#826847) add --no-deb-src

---
 bin/sbuild-createchroot  | 25 +++--
 man/sbuild-createchroot.8.in |  5 +
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/bin/sbuild-createchroot b/bin/sbuild-createchroot
index efcfe04..7244773 100755
--- a/bin/sbuild-createchroot
+++ b/bin/sbuild-createchroot
@@ -72,6 +72,9 @@ sub setup {
'KEEP_SBUILD_CHROOT_DIR'=> {
DEFAULT => 0
},
+   'DEB_SRC'   => {
+   DEFAULT => 1
+   },
 );
 
 $conf->set_allowed_keys(\%createchroot_keys);
@@ -136,6 +139,9 @@ sub set_options {
},
"keep-sbuild-chroot-dir" => sub {
$self->set_conf('KEEP_SBUILD_CHROOT_DIR', 1);
+   },
+   "no-deb-src" => sub {
+   $self->set_conf('DEB_SRC', 0);
});
 }
 
@@ -266,16 +272,15 @@ chmod(0775, $policy_rc_d) == 1
 print "I: Configured /usr/sbin/policy-rc.d:\n";
 dump_file("$policy_rc_d");
 
-
-
-# Set up minimal /etc/apt/sources.list
-my $sources = "${target}/etc/apt/sources.list";
-my $comps = join(' ',split(/,/,$conf->get('COMPONENTS')));
-open(SOURCES, ">$sources")
-or die "Can't open $sources for writing";
-print SOURCES "deb $mirror $suite $comps\n";
-print SOURCES "deb-src $mirror $suite $comps\n";
-close SOURCES or die "Can't close $sources";
+# Add deb-src to /etc/apt/sources.list.
+if ($conf->get('NO_DEB_SRC')) {
+my $sources = "${target}/etc/apt/sources.list";
+my $comps = join(' ',split(/,/,$conf->get('COMPONENTS')));
+open(SOURCES, ">>$sources")
+or die "E: Can't open $sources for writing";
+print SOURCES "deb-src $mirror $suite $comps\n";
+close SOURCES or die "E: Can't close $sources";
+}
 
 # Display /etc/apt/sources.list.
 print "I: Configured APT /etc/apt/sources.list:\n";
diff --git a/man/sbuild-createchroot.8.in b/man/sbuild-createchroot.8.in
index 25e4996..80a8f4c 100644
--- a/man/sbuild-createchroot.8.in
+++ b/man/sbuild-createchroot.8.in
@@ -34,6 +34,7 @@ sbuild\-createchroot \- create sbuild chroot
 .RB [ "\-\-setup\-only" ]
 .RB [ "\-\-make\-sbuild\-tarball=\fIfile\fP" ]
 .RB [ "\-\-keep\-sbuild\-chroot\-dir" ]
+.RB [ "\-\-no\-deb\-src" ]
 .B SUITE TARGET-DIRECTORY DEBIAN-MIRROR-URI
 .RB [ SCRIPT ]
 .PP
@@ -162,6 +163,10 @@ details.
 .BR \-\-keep\-sbuild\-chroot\-dir
 Don't delete the directory used for creating a file type chroot. This option
 does nothing if not creating a file type chroot.
+.TP
+.BR \-\-no\-deb\-src
+Don't add a deb-src line to the \fI/etc/apt/sources.list\fP file in the
+\fITARGET-DIRECTORY\fP after the debootstrap process.
 .SH TARBALL FILE
 When creating an sbuild tarball \fIfile\fP, the compression format used to
 generate the tarball depends on the entension used in \fIfile\fP. Here is a
-- 
2.1.4

--8<---cut here---end--->8---

Tested successfully backporting it to a jessie-backports sbuild.

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#826847: sbuild: override default debootstap's /etc/apt/sources.list

[Luca Capello]

Package: sbuild
Version: 0.65.2-1
Severity: normal
User: luca.cape...@infomaniak.com
Usertags: infomaniak.com-packaging

Hi there,

I am setting up an internal buildd (with no wanna-build) following:

  <https://wiki.debian.org/BuilddSetup>
  <https://wiki.debian.org/sbuild>

As we plan to recompile official Debian packages from internal Git
repositories, we do not mirror the source architecture, no need to waste
bandwidth and disk space:

  <https://www.debian.org/mirror/size>

I do not understand why sbuild-createchroot completely replaces the
${target}/etc/apt/sources.list generated by debootstrap with its own,
since the following commit:

  commit 7eaa13539e6542f553efbf81c2514cbfad2cbac8
  Author: Roger Leigh <rle...@debian.org>
  Date:   Sun Jul 27 13:54:19 2008 +0100

[sbuild-createchroot] Set up sources.list with --components values

So, my questions are:

1) what is the rationale for the current behavior, i.e. why not leaving
   all the *default* APT sources to debootstrap?

2) why adding by default deb-src for a *building* environment?  This
   seems quite strange to me, but I am sure I am missing something...

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 8.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.18.30-imu (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages sbuild depends on:
ii  adduser 3.113+nmu3
ii  apt-utils   1.0.9.8.3
ii  libsbuild-perl  0.65.2-1
ii  perl5.20.2-3+deb8u5

Versions of packages sbuild recommends:
ii  debootstrap  1.0.67
ii  fakeroot 1.20.2-1

Versions of packages sbuild suggests:
pn  deborphan  
ii  wget   1.16-1

-- no debconf information

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#709774: Enable aufs on tmpfs via configuration parameter

[Luca Capello]

user luca.cape...@infomaniak.com
usertag 709774 + infomaniak.com-packaging
tag 709774 + patch
thanks

Hi there!

On Sat, 25 May 2013 13:02:50 +0200, Joachim Breitner wrote:
> It would be nicer if this feature could be enabled without touching
> fstab, by a simple configuration option in schroot.conf. This could
> additionally have the advantage that if schroot mounts the overy for
> each instance, instead of deleting the overlay afterwards, it can just
> unmount the tmpfs to get rid of it.

To avoid such information to be lost:

  <https://wiki.debian.org/sbuild#sbuild_overlays_in_tmpfs>

=
root@chobin:~# cat </etc/schroot/setup.d/04tmpfs
#!/bin/sh

set -e

. "\$SETUP_DATA_DIR/common-data"
. "\$SETUP_DATA_DIR/common-functions"
. "\$SETUP_DATA_DIR/common-config"

if [ -n "\${CHROOT_UNION_TYPE}" ] && [ "\${CHROOT_UNION_TYPE}" != 'none' ]; then

if [ \$STAGE = "setup-start" ]; then
mount -t tmpfs overlay /var/lib/schroot/union/overlay

elif [ \$STAGE = "setup-recover" ]; then
mount -t tmpfs overlay /var/lib/schroot/union/overlay

elif [ \$STAGE = "setup-stop" ]; then
umount -f /var/lib/schroot/union/overlay
fi

fi
EOF
root@chobin:~# chmod a+x /etc/schroot/setup.d/04tmpfs
=

The above has the disadvantage of mounting a tmpfs on
/var/lib/schroot/union/overlay for each schroot and it is still missing
a configuration option in schroot.conf, but it is already a start ;-)

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#796868: dput-ng: Missing Recommends on python-paramiko causes error with scp uploads

[Luca Capello]

user luca.cape...@infomaniak.com
usertag 796868 + infomaniak.com-packaging
thanks

Hi there!

On Tue, 25 Aug 2015 08:23:15 +0100, Neil Williams wrote:
> Installing python-paramiko fixes the problem, allowing the simulation to 
> complete.

FYI, this "Recommends:" is only visible via the following chain:
=
$ dpkg-query -s dput-ng | grep python-dput
Depends: python:any, python-dput (= 1.8)
$ dpkg-query -s python-dput | grep python-paramiko
Recommends: lintian, python-distro-info, python-paramiko, python-validictory, 
openssh-client, debian-keyring
$
=

There is no other information, so something should be added at least in
the manpage, here instead a full patch:

--8<---cut here---start->8---
From 89e1c41953d56a00a05184801fffa112301d9ef8 Mon Sep 17 00:00:00 2001
From: Luca Capello <luca.cape...@infomaniak.com>
Date: Wed, 1 Jun 2016 17:28:58 +0200
Subject: [PATCH] docs/man/dput5.man: (#796868) python-paramiko for scp/sftp

---
 debian/changelog| 7 ++-
 debian/control  | 4 +++-
 docs/man/dput.5.man | 7 ---
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 051c1a7..08e5c6e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,13 @@
 dput-ng (1.11) UNRELEASED; urgency=medium
 
+  [ Vincent Bernat ]
   * Add {wheezy,squeeze}-backports-sloppy suites. (Closes: #798688)
 
- -- Vincent Bernat <ber...@debian.org>  Sun, 11 Oct 2015 09:29:11 +0200
+  [ Luca Capello ]
+  * debian/control, docs/man/dput.5.man:
++ python-paramiko is required for scp/sftp methods (Closes: #796868).
+
+ -- Luca Capello <luca.cape...@infomaniak.com>  Wed, 01 Jun 2016 17:22:32 +0200
 
 dput-ng (1.10) unstable; urgency=medium
 
diff --git a/debian/control b/debian/control
index da441e5..5873788 100644
--- a/debian/control
+++ b/debian/control
@@ -33,7 +33,7 @@ Conflicts: dput
 Replaces: dput
 Provides: dput
 Depends: ${misc:Depends}, ${python:Depends}, python-dput (= ${binary:Version})
-Recommends: bash-completion
+Recommends: bash-completion, python-paramiko
 Description: next generation Debian package upload tool
  dput-ng is a Debian package upload tool which provides an easy to use
  interface to Debian (like) package archive hosting facilities. It allows
@@ -47,6 +47,8 @@ Description: next generation Debian package upload tool
  .
  dput-ng aims to be backwards compatible with dput in command-line flags,
  configuration files, and expected behavior.
+ .
+ The recommended package python-paramiko is needed to upload via SSH.
 
 Package: python-dput
 Architecture: all
diff --git a/docs/man/dput.5.man b/docs/man/dput.5.man
index 482c870..d7158db 100644
--- a/docs/man/dput.5.man
+++ b/docs/man/dput.5.man
@@ -182,9 +182,10 @@ are supported:
* 'http' or 'https':: Use HTTP or HTTPS to upload files
* 'local':: Upload to a locally mounted location of the file system.
  Internally this calls *install(1)*.
-   * 'scp':: Use scp to upload files. *This method is deprecated*, use 
'sftp'
-   instead when possible.
-   * 'sftp':: Use the sftp protocol (a secured file transfer via SSH).
+   * 'scp':: Use scp to upload files (it requires python-paramiko).
+   This method is deprecated*, use 'sftp' instead when possible.
+   * 'sftp':: Use the sftp protocol (a secured file transfer via
+   SSH, it requires python-paramiko).
 
* *dput-ng* does not support 'rsync'.
 
-- 
2.1.4
--8<---cut here---end------->8---

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#745025: Looking for sponsor

[Luca Capello]

block 745025 by 745027
usertags 745025 + pca.it-synchronization
thanks

Hi Filip,

On Fri, 29 Jan 2016 16:13:48 +0100, Filip Pytloun wrote:
> I have prepare khal package:
> http://mentors.debian.net/package/khal
> 
> Is there anyone interested in sponsoring it?

I am, since I am looking for a CLI CalDAV client for jessie, so I am
also interested in a jessie-backports.

A quick build of your package reveals:

- a non-versioned Depends:

  - python-click (>= 3.2) [jessie-backports: simple rebuild]

- missing Depends:

  - python-tzlocal (>= 1.0) [jessie-backports: simple rebuild]
  - vresyncdir, as you know:

  
  
Thus marking that this bug is blocked until vresyncdir enters Debian.  I

will come back with a more detailed review.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#623539: Takes over GPG and SSH agents from gnupg-agent and ssh-agent

[Luca Capello]

block 623539 by 773304
block 623539 by 760102
affects 623539 + gnupg-agent
affects 623539 + libpam-ssh
user luca.cape...@infomaniak.com
usertag 623539 + infomaniak.com-authentication
thanks

Hi there!

On Fri, 22 Apr 2011 17:02:45 -0700, Josh Triplett wrote:
> retitle 623539 Takes over GPG and SSH agents from gnupg-agent and ssh-agent

At least the GnuPG part of this bug has been fixed:

- upstream[1][2][3] since gnome-keyring_3.17.4 together with
  pinentry_0.9.5 and gnupg_2.1.6

- in Debian[4] since gnome-keyring_3.16.0-3

[1] 
[2] 
[3] 
[4] 

This means that the bug should already been fixed in stretch
(gnome-keyring_3.18.3-1, pinentry_0.9.7-5 and gnupg_2.1.11-6).

For jessie, you still need to avoid gnome-keyring-gpg and -ssh startup
as explained in the README.Debian, either with 'Hidden=true' as
explained on Simon Josefsson's blog[5] or, better, with (works on Ubuntu
14.04 as well, gnome-keyring_3.10.1-1ubuntu4):
=
$ mkdir -p ~/.config/autostart
$ echo 'X-GNOME-Autostart-enabled=false' \
  | cat /etc/xdg/autostart/gnome-keyring-gpg.desktop - \
  >>~/.config/autostart/gnome-keyring-gpg.desktop
$ echo 'X-GNOME-Autostart-enabled=false' \
  | cat /etc/xdg/autostart/gnome-keyring-ssh.desktop - \
  >>~/.config/autostart/gnome-keyring-ssh.desktop
=

[5] 

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#810835: ITP: let-alist -- let-bind values of an assoc-list by their names in Emacs Lisp

[Luca Capello]

Hi there!

On Sat, 16 Jan 2016 19:47:53 -0700, Sean Whitton wrote:
> On Sat, Jan 16, 2016 at 10:34:04PM +0100, Luca Capello wrote:
> > Nothing against you, but a .deb for an 89-line macro sounds a bit
> > overkill to me.
> 
> I want to package emacs-pdf-tools [1]
[...]
> > JFTR, I needed it as well as a dependency for Flycheck and ended up
> > installing everything from (M)ELPA :-(
> 
> That's what I want to avoid!

Look, I completely understand your point, still I think that such a
small package (I guess less than 10kb in the end) for a single file
which has not changed since 2014-12-23 should be avoided.

But I have just discovered that there is already another similar-in-size
package in the archive, so forget my remark:

  <https://packages.debian.org/jessie/sass-elisp>

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#810835: ITP: let-alist -- let-bind values of an assoc-list by their names in Emacs Lisp

[Luca Capello]

Hi there,

On Tue, 12 Jan 2016 10:39:00 -0700, Sean Whitton wrote:
> * Package name: let-alist
>   Version : 1.0.4
>   Upstream Author : Artur Malabarba 
> * URL : https://elpa.gnu.org/packages/let-alist.html
[...]
> let-alist is a useful macro for programming in Emacs Lisp.

Nothing against you, but a .deb for an 89-line macro sounds a bit
overkill to me:
=
$ wget http://elpa.gnu.org/packages/let-alist-1.0.3.el
[...]
$ wc -l let-alist-1.0.3.el 
162 let-alist-1.0.3.el
$ grep -v '^;' -c let-alist-1.0.3.el 
89
$
=

JFTR, I needed it as well as a dependency for Flycheck and ended up
installing everything from (M)ELPA :-(

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#777637: lxde-common: please add a keybinding for finding files

[Luca Capello]

Package: lxde-common
Version: 0.5.5-6
Severity: wishlist
Tags: patch
Control: affects -1 + lxde-core
User: cont...@itopie.ch
Usertags: itopie.ch-installation
User: i...@codha.ch
Usertags: codha.ch-installation

Hi there,

given that PCManFM is the default File Manager for LXDE, IMHO it would
be quite useful to add a keybinding for finding files (the same as on
Windows), with the following patch:

--8---cut here---start-8---
--- a/xdg/openbox/LXDE/rc.xml
+++ b/xdg/openbox/LXDE/rc.xml
@@ -275,6 +275,13 @@
 /action
   /keybind
 
+  !-- Keybindings for finding files --
+  keybind key=W-f
+action name=Execute
+  commandpcmanfm --find-files/command
+/action
+  /keybind
+
   !--keybindings for LXPanel --
   keybind key=W-r
   action name=Execute
--8---cut here---end---8---

Please note that PCManFM search functions require libfm-modules since
libfm = 1.2.0-1.

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 7.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lxde-common depends on:
ii  lxsession  0.4.6.1-4

Versions of packages lxde-common recommends:
ii  lxde-core  4+nmu1

Versions of packages lxde-common suggests:
pn  lxlauncher  none

-- Configuration Files:
/etc/xdg/openbox/LXDE/rc.xml changed [not included]

-- no debconf information


signature.asc
Description: Digital signature

Bug#774531: keysync: missing Depends: python-pkg-resources

[Luca Capello]

Package: keysync
Version: 0.2.1.1-1~bpo70+1
Severity: important
User: cont...@itopie.ch
Usertags: itopie.ch-installation

Hi there,

as the subject says:
=
luca.capello@gismo:~$ keysync --help
Traceback (most recent call last):
  File /usr/bin/keysync, line 17, in module
import otrapps.util
  File /usr/lib/python2.7/dist-packages/otrapps/__init__.py, line 7, in 
module
from pkg_resources import get_distribution, DistributionNotFound
ImportError: No module named pkg_resources
luca.capello@gismo:~$ 
=

Installing python-pkg-resources was enough to get my Pidgin keys into Jitsi :-)

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 7.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages keysync depends on:
ii  python   2.7.3-4+deb7u1
ii  python-bs4   4.1.0-1
ii  python-crypto2.6-4+deb7u3
ii  python-imaging   1.1.7-4+deb7u1
ii  python-imaging-tk1.1.7-4+deb7u1
ii  python-pgpdump   1.4-1~bpo70+1
ii  python-potr  1.0.0-1~bpo70+1
ii  python-psutil0.5.1-1
ii  python-pyasn10.1.3-1
ii  python-pyjavaproperties  0.6-1
ii  python-pymtp 0.0.6-1~bpo70+1
ii  python-pyparsing 1.5.6+dfsg1-2
ii  python-qrcode4.0.1-2~bpo70+1
ii  python-six   1.8.0-1~bpo70+1
ii  python-tk2.7.3-1

keysync recommends no packages.

keysync suggests no packages.

-- no debconf information


signature.asc
Description: Digital signature

Bug#755489: please add jitsi to wheezy-backports

[Luca Capello]

block 755489 by 729904
block 755489 by 760853
user cont...@itopie.ch
usertags 755489 + itopie.ch-installation
thanks

Hi there,

On Mon, 21 Jul 2014 13:47:13 +0200, Kurt Roeckx wrote:
 On Mon, Jul 21, 2014 at 12:26:14PM +0200, Per Andersson wrote:
  Please add jitsi to wheezy-backuports, so those that use Debian stable
  can install jitsi from the repositories.

Fully agree, also because it seems to be the only XMPP client allowing
audio/video call between different platforms (at least GNU/Linux,
Windows, OSX and Android).

 You might also want to look at #729904

And #760853, BTS updated.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#617196: grub-pc: GRUB_GFXMODE silently ignored if font unavailable

[Luca Capello]

found 617196 1.99-27+deb7u2
tags 617196 + patch
user cont...@itopie.ch
usertags 617196 + itopie.ch-installation
thanks

Hi there,

On Fri, 20 Dec 2013 21:50:25 -0800, Ben Longbons wrote:
 I managed to fix the core problem by doing:
 cp /usr/share/grub/unicode.pf2 /boot/grub/unicode.pf2
 Obviously it can't read any partition but /boot since it's on encrypted LVM.

This bug is still present on an up-to-date wheezy, but here /boot is on
RAID-1 and everything else on RAID-1 + LUKS + LVM.

Actually, the problem is in /usr/sbin/grub-mkconfig:172, then
reflected in /etc/grub.d/00_header:126, exactly because of the encrypted
partition.

What is strange is that this was bug #542314 fixed in 1.96+20090825-1
and indeed /var/lib/dpkg/info/grub-pc.postinst:634 deals with it, but
not at package configuration time since /boot/grub/grub.cfg has not been
created yet.  Indeed, a simple `dpkg-reconfigure grub-pc` is enough to
fix this bug ;-)

I would say that the easiest solution would be unconditionally copy the
font, here is a patch against 2.02~beta2-16:

--8---cut here---start-8---
--- /var/lib/dpkg/info/grub-pc.postinst 2014-11-06 14:52:43.0 +0100
+++ /home/users/luca.capello/Downloads/grub-pc.postinst 2015-01-02 
22:58:29.662664200 +0100
@@ -663,13 +663,13 @@
 fi
 
 # /boot/grub/ has more chances of being accessible by GRUB
-if test -e /boot/grub/grub.cfg ; then
-  for i in /usr/share/grub/unicode.pf2 ; do
-if test -e $i ; then
-  cp $i /boot/grub/
-fi
-  done
-fi
+# uncoditionally copy the font because if the package is being
+# installed there is no configuration yet, see #617196
+for i in /usr/share/grub/unicode.pf2 ; do
+  if test -e $i ; then
+cp $i /boot/grub/
+  fi
+done
 
 if [ $fix_mixed_system ]; then
   # These never contain any valuable information, and they aren't
--8---cut here---end---8---

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#772674: RFP: xul-ext-mail-redirect -- Redirect mail to other recipients

[Luca Capello]

user cont...@itopie.ch
usertags 772674 + itopie.ch-installation
thanks

Hi Dominik,

On Tue, 09 Dec 2014 22:36:42 +0100, Dominik George wrote:
 * Package name: xul-ext-mail-redirect
   Version : 0.8.5
   Upstream Author : Paweł Krześniak imosz...@users.sf.net
 * URL : http://mailredirect.sf.net

JFTR, the corresponding URL in the extension list is:

  https://addons.mozilla.org/en-US/thunderbird/addon/mailredirect/

...and the corresponding upstream bug is:

  https://bugzilla.mozilla.org/show_bug.cgi?id=12916
  
 * License : MPL 2.0
   Programming Lang: JavaScript (XUL)
   Description : Redirect mail to other recipients
 
 The Mailredirect extension for Mozilla Thunderbird (version 6.0 and
 above) and SeaMonkey adds the ability to redirect one or more emails to
 one or more recipients. The feature of mail redirecting is also known as
 bouncing forward or resending.

I use this extension for a while now and thus I am willing to package
it, would you like to co-maintain it (I can sponsor, if needed)?

Cc:ing the pkg-mozilla-maintainers@ mailing list: should such an
extension be (team) maintained there or in collab-maint or it does not
matter?

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#761286: blueman: set caja as a possible file browser

[Luca Capello]

forwarded 761286 https://github.com/blueman-project/blueman/issues/94
tags 761286 + upstream fixed-upstream
user cont...@itopie.ch
usertags 761286 + itopie.ch-installation
user i...@codha.ch
usertags 761286 + codha.ch-installation
unarchive 761284
thanks

Hi there,

On Wed, 17 Sep 2014 22:54:41 +0200, Alessandro Barbieri wrote:
 Il 17/09/2014 16:03, Christopher Schramm ha scritto:
 Hi Alessandro, I've created an upstream item for this:
 https://github.com/blueman-project/blueman/issues/94

Christopher, please mark such things in the Debian BTS as well (done
with this email), here the link to the documentation:

  https://www.debian.org/Bugs/server-control

 I think it should be possible to set an arbitrary browser command, but I
 need to check that. Anyway, built-in caja support would definitely be good.
 Thanks Cristopher,
 
 I can't set it from the applet, see bug #761284

Still present in jessie, I will follow-up on that bug as soon as it is
unarchived.

 and i can't find
 configuration files.

They are in ~/.gconf/blueman (created the first time Blueman is closed),
you can then edit them by hand:
=
itopie@debian-jessie:~$ cat .gconf/apps/blueman/transfer/%gconf.xml 
?xml version=1.0?
gconf
entry name=browse_command mtime=1419713108 type=string
stringvaluenautilus obex://[%d]/stringvalue
/entry
entry name=ftp_allow_write mtime=1419712260 type=bool 
value=false/
entry name=shared_path mtime=1419712260 type=string
stringvalue/home/itopie/Public/stringvalue
/entry
entry name=ftp_enabled mtime=1419712259 type=bool value=true/
entry name=opp_enabled mtime=1419712259 type=bool value=true/
/gconf
itopie@debian-jessie:~$ 
=

FWIW, upstream has already fixed it to use Gtk.show_uri if no browse
command is set:

  
https://github.com/blueman-project/blueman/commit/4e7771f40c56336773b04c7533566558f4b1c1bd

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#761284: blueman: can't set alternative file browser

[Luca Capello]

reopen 761284
found 761284 1.99~alpha1-1
user cont...@itopie.ch
usertags 761284 + itopie.ch-installation
user i...@codha.ch
usertags 761284 + codha.ch-installation
thanks

Hi there,

Christopher, please give a more detailed explanation when you close a
bug, I guess you wanted to say that this was a duplicate of #761286,
thus you should have used merge ...:

  https://www.debian.org/Bugs/server-control#merge

On Fri, 12 Sep 2014 15:04:12 +0200, Alessandro Barbieri wrote:
* What exactly did you do (or not do) that was effective (or
  ineffective)?
 
   Click on the tray icon  local services  transfer
 
* What was the outcome of this action?
 
   Grey box with nothing inside and no way to set the alternate browser

Still present in an up-to-date and default (AKA GNOME) jessie, see
screenshot attached, here the terminal output:
=
itopie@debian-jessie:~$ blueman-services 
Loading configuration plugins
Using GConf config backend
blueman-services version 1.99.alpha1 starting
_
load_plugins (/usr/bin/blueman-services:85)
['Audio', 'Network', 'Transfer'] 
_
set_page (/usr/bin/blueman-services:132)
Set page Transfer 
Traceback (most recent call last):
  File /usr/bin/blueman-services, line 159, in on_selection_changed
self.set_page(id)
  File /usr/bin/blueman-services, line 143, in set_page
inst.on_load(self.container)
  File /usr/lib/python2.7/dist-packages/blueman/plugins/services/Transfer.py, 
line 43, in on_load
self.setup_transfer()
  File /usr/lib/python2.7/dist-packages/blueman/plugins/services/Transfer.py, 
line 132, in setup_transfer
status = a.TransferStatus(opp)
  File /usr/lib/python2.7/dist-packages/dbus/proxies.py, line 70, in __call__
return self._proxy_method(*args, **keywords)
  File /usr/lib/python2.7/dist-packages/dbus/proxies.py, line 145, in __call__
**keywords)
  File /usr/lib/python2.7/dist-packages/dbus/connection.py, line 651, in 
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method 
IsStarted with signature  on interface org.openobex.Server doesn't exist

Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
itopie@debian-jessie:~$ 
=

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#618722: libpam-ccreds: pam_deny.so in common-account prevents LDAP authentication

[Luca Capello]

user cont...@itopie.ch
usertags 618722 + itopie.ch-installation
user i...@codha.ch
usertags 618722 + codha.ch-installation
thanks

Hi there,

On Sun, 04 May 2014 00:39:15 +0200, Raymond Pettersen wrote:
 I ended up with the following solution, which doesn't break pam-auth-update.
 
 Change the common-account file in /usr/share/pam, and replace requisite with
 optional. Run pam-auth-update and make sure that the /etc files are updated.
 
 pam-ccreds should now work properly (tested on debian wheezy).

I can confirm that simply demoting pam_deny.so to optional in
common-account does the trick.

However, that should not be done in /usr/share/pam/common-account, since
such modification will be lost whenever the package will be upgraded (or
reinstalled).  Thus, it is better to modify /etc/pam.d/common-account
instead, which is preserved even after a pam-auth-update run.

To answer Guido's request for co-maintenance: I moved to sssd for a
while now, but I am currently testing a wider setup and evaluating again
pam-ccreds...

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#698504: system-config-printer: permission problem though added to lp group

[Luca Capello]

reassign 698504 cups-pk-helper
found 698504 0.1.0-3
found 698504 0.2.3-3
severity 698504 important
affects 698504 + system-config-printer
tags 698504 + patch
user cont...@itopie.ch
usertags 698504 + itopie.ch-installation
user i...@apres-ge.ch
usertags 698504 + apres-ge.ch-installation
thanks

Hi there!

On Tue, 04 Feb 2014 20:49:02 +0100, Claudio Laurita wrote:
 I can confirm this bug in debian wheezy 32 bit too (with mate 1.6.0 desktop,
 kernel 3.11 i386).
 system-config-printer version 1.4.3-1
 cups 1.7.1-2

The problem resides in cups-pk-helper, which does not respect CUPS
'SystemGroup lpadmin' privileges as per /etc/cups/cups-files.conf.

The file below is enough to fix this, but please note that while the
service is org.opensuse.CupsPkHelper.Mechanism, the actions are all
lowercase.  I discover that thanks to the more-than-3-year-old Ubuntu
fix, albeit not in the cups-pk-helper package:

  
https://bugs.launchpad.net/ubuntu/+source/policykit-desktop-privileges/+bug/847896

=
$ cat /etc/polkit-1/localauthority/10-vendor.d/org.opensuse.cupspkhelper.pkla 
[Adding or changing system-wide CUPS settings]
Identity=unix-group:lpadmin;unix-group:sudo
Action=org.opensuse.cupspkhelper.mechanism.*
ResultAny=no
ResultInactive=no
ResultActive=yes
$ 
=

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 7.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages cups-pk-helper depends on:
ii  libc6  2.13-38+deb7u6
ii  libcups2   1.5.3-5+deb7u4
ii  libglib2.0-0   2.33.12+really2.32.4-5
ii  libpolkit-gobject-1-0  0.105-3

cups-pk-helper recommends no packages.

cups-pk-helper suggests no packages.

-- no debconf information


signature.asc
Description: Digital signature

Bug#698504: system-config-printer: permission problem though added to lp group

[Luca Capello]

Hi there!

On Sat, 27 Dec 2014 00:05:11 +0100, Luca Capello wrote:
 On Tue, 04 Feb 2014 20:49:02 +0100, Claudio Laurita wrote:
  I can confirm this bug in debian wheezy 32 bit too (with mate 1.6.0 desktop,
  kernel 3.11 i386).
  system-config-printer version 1.4.3-1
  cups 1.7.1-2
 
 The problem resides in cups-pk-helper, which does not respect CUPS
 'SystemGroup lpadmin' privileges as per /etc/cups/cups-files.conf.

The discrepancy seems to be an upstream decision, whose resolution is
left to each distribution:

  https://bugs.gentoo.org/show_bug.cgi?id=466338

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#770761: intel-microcode: should Depends: on the first working linux-image version (e.g. backports)

[Luca Capello]

Hi Henrique,

On Thu, 27 Nov 2014 14:05:25 -0200, Henrique de Moraes Holschuh wrote:
 On Sun, 23 Nov 2014, Henrique de Moraes Holschuh wrote:
  On Sun, 23 Nov 2014, Luca Capello wrote:
   while installing a new Debian wheezy following our internal
   instructions[1] that worked flawlessly in the past, I was quite
   surprised by the error message about not supported kernel appeared
   during the intel-microcode installation.
  
  ...
  
   1) the default apt-listchanges/which debconf value is news, which means
  that on upgrades the above message is not shown, instead it should
 
  have been added to debian/NEWS.
  
  It *is* in NEWS.Debian.  However, it won't work right for the backported
  package because the version heading in the NEWS file does not end with a
  ~.
 
 I have tested this, and apt-listchanges *did* display the NEWS entry on
 upgrade both from the stable version, and the previous backported version.

My fault, I was thinking something and writing another thing: it should
have been which means that on *new installations* the above message is
not shown.

 But this thing is known to be flaky, and the test procedure requires
 removing the apt-listchanges database (which could easily defuse a bug), so
 I will repload with a bumped version in the NEWS file in hope that it will
 ensure more people gets the warning.

Thank you.

   2) AFAIK, if a backport package needs a feature of another backport
  package to work on a stable installation, than the second package
  should be a Depends:.
 
  That I can't do.  This is a runtime dependency on the kernel version you're
  building the initramfs *for*.  It is not even related to whatever kernel
  you're running at the time the initramfs is built.

Exactly because it is not related to the kernel you are running, but on
*at least* one kernel package installed IMHO it is an hard Depends: for
Debian.

  If you don't need any of the features in the backported intel-microcode
  package, why were using it instead of the stable package?  early microcode
  update support is the whole *point* of the backported package...

IMHO there are two problems in your reasoning: first, how do I know if I
need any of the features in the backported package?  If I have to
manually check them *before* installing the package I do not see why I
would use the Debian package at all.

Second, the previous backported package worked with no problems, it is
the new version that actually stopped working ;-)

To solve both problems there should be a way to say: look, you are
installing a package that requires a newer kernel version...

   Versions of packages intel-microcode recommends:
   ii  initramfs-tools  0.109.1
  
  This is going to be a problem as well.  I will consider switching to a
  Depends.
 
 I've switched to a depends for backports, I can undo this easily if it
 causes problems.  Unstable and stable will remain with a recommends.

Thank you very much!  However, this does not seem to automatically pull
a backported kernel:
=
# apt-get update
[...]
# apt-get install -d -t wheezy-backports initramfs-tools
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be upgraded:
  initramfs-tools
1 upgraded, 0 newly installed, 0 to remove and 32 not upgraded.
Need to get 0 B/92.6 kB of archives.
After this operation, 3,072 B of additional disk space will be used.
[...]
# 
=

BTW, this is not the first time you are so supportive on one of the bugs
 I have reported, it is a pleasure to deal with you :-D

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#756855: synaptic: Should not set APT::Install-Recommends (globally)

[Luca Capello]

found 756855 0.75.13
user cont...@itopie.ch
usertags 756855 + itopie.ch-installation
user i...@codha.ch
usertags 756855 + codha.ch-installation
thanks

0.75.13


Hi there,

On Sat, 02 Aug 2014 18:30:58 +0200, Axel Beckert wrote:
 Package: synaptic
 Version: 0.81.2

This happens in wheezy as well, marked.

 synaptic ships /etc/apt.conf.d/99synaptic which sets
 APT::Install-Recommends to true globally for all APT based applications.

Actually, the above file is not present in the package itself, but it is
generated the first time synaptic is started, as etckeeper told me.

 IMHO no application should be so arrogant to change that value globally
[...]
 If it's needed for synaptic's well-behaving (which I doubt),
 it should set that value internally, but not globally.

Fully, agree.

Please note that IMHO this bug is at least important, if not more.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#770761: intel-microcode: should Depends: on the first working linux-image version (e.g. backports)

[Luca Capello]

Package: intel-microcode
Version: 3.20140913.1~bpo70+1
Severity: important
User: cont...@itopie.ch
Usertags: debian-packaging

Hi there,

while installing a new Debian wheezy following our internal
instructions[1] that worked flawlessly in the past, I was quite
surprised by the error message about not supported kernel appeared
during the intel-microcode installation.

[1] https://docs.itopie.ch/installation/debian

Anyway, I rebooted and since there was still no intel-microcode loaded I
checked the debian/changelog:

--8---cut here---start-8---
intel-microcode (3.20140913.1~bpo70+1) wheezy-backports; urgency=medium

  * Rebuild for wheezy-backports (no changes)
  * THIS PACKAGE REQUIRES LINUX KERNEL 3.10 OR LATER, YOU MUST USE A
BACKPORTED OR CUSTOM KERNEL.  If you use the regular Debian stable
(wheezy) kernel (Linux 3.2), please use the stable (wheezy)
intel-microcode package.

 -- Henrique de Moraes Holschuh h...@debian.org  Thu, 30 Oct 2014 16:19:08 
-0200
--8---cut here---end---8---

I am sorry, but I see two important errors here:

1) the default apt-listchanges/which debconf value is news, which means
   that on upgrades the above message is not shown, instead it should
   have been added to debian/NEWS.

2) AFAIK, if a backport package needs a feature of another backport
   package to work on a stable installation, than the second package
   should be a Depends:.

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 7.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages intel-microcode depends on:
ii  iucode-tool  1.1-1~bpo70+1

Versions of packages intel-microcode recommends:
ii  initramfs-tools  0.109.1

intel-microcode suggests no packages.

-- no debconf information


signature.asc
Description: Digital signature

Bug#770629: sssd-ldap: ldap_result error: [Can't contact LDAP server] when CNAME

[Luca Capello]

Package: sssd-ldap
Version: 1.11.7-1
Severity: important
Usertags: pca.it-authentication

Hi there,

sorry for the delay, the subject says all:
=
root@gismo:/etc# tail -f /var/log/sssd/sssd_LDAP.log
(Sat Nov 22 19:31:14 2014) [sssd[be[LDAP]]] [be_resolve_server_process] 
(0x0200): Found address for server mantissa.pca.it: [83.211.85.135] TTL 512
(Sat Nov 22 19:31:15 2014) [sssd[be[LDAP]]] [sdap_process_result] (0x0040): 
ldap_result error: [Can't contact LDAP server]
^C
root@gismo:/etc# grep ldap_uri /etc/sssd/sssd.conf 
ldap_uri = ldap://mantissa.pca.it
root@gismo:/etc# host mantissa.pca.it
mantissa.pca.it is an alias for home.pca.it.
home.pca.it has address 83.211.85.135
root@gismo:/etc# 
=

If I put home.pca.it in ldap_uri the be_resolve_server_process line is
the same but for the hostname, so I am lost.

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.17-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sssd-ldap depends on:
ii  libc6 2.19-13
ii  libcomerr21.42.12-1
ii  libdhash1 0.4.0-1
ii  libk5crypto3  1.12.1+dfsg-15
ii  libkrb5-3 1.12.1+dfsg-15
ii  libldap-2.4-2 2.4.40-2
ii  libsss-idmap0 1.11.7-2
ii  sssd-common   1.11.7-2
ii  sssd-krb5-common  1.11.7-2

Versions of packages sssd-ldap recommends:
ii  ldap-utils  2.4.40-2

Versions of packages sssd-ldap suggests:
pn  libsasl2-modules-ldap  none

-- no debconf information



signature.asc
Description: Digital signature

Bug#770516: pidgin: please add gstreamer0.10-alsa and gstreamer0.10-ffmpeg to Suggests:

[Luca Capello]

Package: pidgin
Version: 2.10.10-1.1
Severity: minor
Usertags: pca.it-communication

Hi there,

I was quite surprised to find out that in a default minimal installation
(i.e. without any DE and Recommends:) Pidgin relies on OSS as the
default audio subsystem.  AFAIK Debian choose to primarily rely on ALSA,
which means that gstreamer0.10-alsa should *at least* be in the
Suggests: list.

Similarly, I was not able to have any video call without
gstreamer0.10-ffmpeg, which also means that the latter should *at least*
be in the Suggests: list as well.

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.17-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pidgin depends on:
ii  gconf2  3.2.6-3
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-13
ii  libcairo2   1.12.16-2
ii  libdbus-1-3 1.8.10-1
ii  libdbus-glib-1-20.102-1
ii  libfontconfig1  2.11.0-6.2
ii  libfreetype62.5.2-2
ii  libgadu31:1.12.0-5
it  libgdk-pixbuf2.0-0  2.31.1-2+b1
ii  libglib2.0-02.42.1-1
ii  libgstreamer0.10-0  0.10.36-1.5
ii  libgtk2.0-0 2.24.25-1
ii  libgtkspell02.0.16-1.1
ii  libice6 2:1.0.9-1
ii  libpango-1.0-0  1.36.8-3
ii  libpangocairo-1.0-0 1.36.8-3
ii  libpangoft2-1.0-0   1.36.8-3
ii  libpurple0  2.10.10-1.1
ii  libsm6  2:1.2.2-1
ii  libx11-62:1.6.2-3
ii  libxml2 2.9.2+dfsg1-1
ii  libxss1 1:1.2.2-1
ii  perl-base [perlapi-5.20.1]  5.20.1-3
ii  pidgin-data 2.10.10-1.1

Versions of packages pidgin recommends:
ii  gstreamer0.10-plugins-base  0.10.36-2
ii  gstreamer0.10-plugins-good  0.10.31-3+nmu4+b1

Versions of packages pidgin suggests:
ii  libsqlite3-0  3.8.7.1-1

-- no debconf information


signature.asc
Description: Digital signature

Bug#760353: sssd-common: Startup settings in /etc/default/sssd prevents service (re)start

[Luca Capello]

severity 760353 grave
found 760353 1.11.5.1-1
usertags 760353 + pca.it-authentication
thanks

Hi there!

On Wed, 03 Sep 2014 09:06:10 +0200, Andreas Maus wrote:
 The options passed to the sssd service during startup packaged in ssd-common
 are:
 
 DAEMON_OPTS=-i -f
 
 This will prevent a system start or service (re)start, because the -i option
 forces the service to run in the foreground.

This actually breaks an upgrade (hence the severity), which stops at:
=
Setting up sssd-common (1.11.7-1) ...
Installing new version of config file /etc/default/sssd ...
=

Obviously, the processes running are:
=
8690 /bin/sh /var/lib/dpkg/info/sssd-common.postinst configure 1.11.2-1
8713 /bin/sh /etc/init.d/sssd start
8716 /usr/sbin/sssd -i -f
8717 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain LDAP --debug-to-files
8718 /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --debug-to-files
8719 /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --debug-to-files
=

 The correct options should be:
 
 DAEMON_OPTS=-D -f
 
 which were the settings in previous versions.

The changes were introduced in 1.11.5.1-1, with no rationale except a
line in the debian/changelog: simply reverting the settings to the
previous version and then stopping sssd resumes the upgrade.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#765620: lxde-common: please add a Fn+Screen/XF86Display keybinding

[Luca Capello]

Package: lxde-common
Version: 0.5.5-6
Severity: wishlist
Tags: patch
Control: affects -1 + lxde-core lxrandr
User: cont...@itopie.ch
Usertags: itopie.ch-installation
User: i...@codha.ch
Usertags: codha.ch-installation

Hi there,

most laptops has a key to switch between displays, IMHO on the default
LXDE installation on Debian based on Openbox such keybinding should
raise LXRandR.

For this, lxde-common should carry the following patch:

--8---cut here---start-8---
--- a/xdg/openbox/LXDE/rc.xml
+++ b/xdg/openbox/LXDE/rc.xml
@@ -176,6 +176,11 @@
 keyboard
   chainQuitKeyC-g/chainQuitKey
 
+  !-- Launch LXRandR when Fn+Screen is pressed --
+  keybind key=XF86Display
+action name=Executecommandlxrandr/command/action
+  /keybind
+
   !-- from /etc/xdg/openbox/rc.xml:
  http://bugs.debian.org/754207
  http://bugs.debian.org/754558
--8---cut here---end---8---

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 7.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lxde-common depends on:
ii  lxsession  0.4.6.1-4

Versions of packages lxde-common recommends:
ii  lxde-core  4+nmu1

Versions of packages lxde-common suggests:
pn  lxlauncher  none

-- Configuration Files:
/etc/xdg/openbox/LXDE/rc.xml changed [not included]

-- no debconf information


signature.asc
Description: Digital signature

Bug#640918: libpam-modules: pam_mkhomedir.so has no default config in /usr/share/pam-configs

[Luca Capello]

reassign 640918 libpam-runtime
found 640918 1.1.1-6.1
merge 568577 640918
affects 568577 + libpam-modules
user cont...@itopie.ch
usertags 568577 + itopie.ch-installation
user i...@codha.ch
usertags 568577 + codha.ch-installation
thanks

Hi there!

On Thu, 08 Sep 2011 14:42:53 +0100, Wolfgang Schulze-Zachau wrote:
 This module is very useful in environments using LDAP authentication, as it 
 allows users
 to log into any linux workstation on the network (if configured properly). 
 However, since
 there is no default config in /usr/share/pam-configs,

This has already been reported against libpam-runtime, merging:

  https://bugs.debian.org/568577

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#236227: mozilla-firefox: /etc/papersize should be consulted for the default paper size for printing

[Luca Capello]

found 236227 24.7.0esr-1~deb7u1
user cont...@itopie.ch
usertags 236227 + itopie.ch-installation
user i...@codha.ch
usertags 236227 + codha.ch-installation
thanks

Hi there!

On Thu, 28 Mar 2013 10:37:27 +0100, Mgr. Peter Tuharsky wrote:
 Bug still occurs with Debian Wheezy.

Still true, but it seems that something has changed: if you have a
printer installed which defaults to A4, when you configure such a
printer in the File - Page Setup window the page size is A4.  This
new behavior is also present in 31.0~a2+20140523004002-1, which
however lacks File - Page Setup (you can still get it within the print
preview window).

Given that we are deploying Debian workstations for multiple users,
configuring each user manually is a no-op.  The corresponding Ubuntu bug
was a good reading to look for a system-wide solution, especially
comment #143:

  https://bugs.launchpad.net/firefox/+bug/10910

After a series of tests, I ended up adding the following lines to
/etc/iceweasel/pref/iceweasel.js (Debian-specific, I guess the
upstream one is /etc/iceweasel/profile/prefs.js), which IMHO should be
added to README.Debian:

--8---cut here---start-8---
// https://bugs.debian.org/236227
pref(print.postscript.paper_size, iso_a4);
pref(print.print_paper_height, 297.00);
pref(print.print_paper_name, iso_a4);
pref(print.print_paper_size_type, 1);
pref(print.print_paper_size_unit, 1);
pref(print.print_paper_width, 210.00);
--8---cut here---end---8---

Obviously, the same lines works for /etc/icedove/pref/icedove.js, too.

Please note that the Firefox FAQ does not say anything about the above
values, nor about print.print_paper_size, which is a completely
different beast WRT print.postscript.paper_size:

  http://kb.mozillazine.org/Firefox_:_FAQs_:_About:config_Entries#Print.
  http://forums.mozillazine.org/viewtopic.php?t=378536

 Furthermore, Iceweasel ignores not only /etc/papersize, but also the
 environment locale settings, such as LC_PAPER=sk_SK.UTF-8
 I'm not sure, whether should I fill another, separate bug for the instance, or
 this one is enough.

The upstream bug considers both sources, one Debian bug is enough.

FWIW, the submitter of the upstream bug proposed an IMHO correct and
exhaustive solution based on LC_* environment variables:

  https://bugzilla.mozilla.org/show_bug.cgi?id=147419#c25

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#692984: Expected upload of sogo-connector

[Luca Capello]

forcemerge 692984 659291
reassign 705488 wnpp
forcemerge 692984 705488
user cont...@itopie.ch
usertags 692984 + itopie.ch-installation
user i...@codha.ch
usertags 692984 + codha.ch-installation
thanks

Hi there!

Merging all relevant/duplicate bugs and Cc:ing all the interested
people.

On Wed, 30 Apr 2014 13:46:26 +0200, Carsten Schoenert wrote:
 Am 30.04.2014 12:41, schrieb Boris Barbour:
  I'm interested in obtaining the sogo-connector, as this seems to be the 
  only way to sync contacts with owncloud. I'd prefer to get it through 
  the debian repositories. The messages above suggest that it could be (or 
  has been) uploaded, which is good news. When might we expect it to appear?
 
 thanks for your interests!
 I don't know then the FTP Team will allow the upload of the package, so
 sorry, I can't say something promising right now.

The package is still in the NEW queue, please remember to close this bug
when the package will enter Debian, since the current debian/changelog
does not automatically close any bug:

  https://ftp-master.debian.org/new/sogo-connector_24.0.5-1.html

 You can rebuild the package by yourself using the current repository
 which will be found on
 
   https://github.com/tijuca/sogo-connector

Any reason why this is not on Alioth?

 You will probably need a sid chroot to build the package, right know I
 always used git-pbuilder and doesn't have cared about backports or so.
 But that should not be a big problem to created a wheezy-backport
 package too.

Actually, using a *plain* wheezy chroot is not enough:
=
[...]
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
The following NEW packages will be installed:
  bsdmainutils{a} debhelper{a} file{a} gettext{a} gettext-base{a}
  groff-base{a} html2text{a} intltool-debian{a} libasprintf0c2{a}
  libcroco3{a} libffi5{a} libgettextpo0{a} libglib2.0-0{a} libmagic1{a}
  libpcre3{a} libpipeline1{a} libunistring0{a} libxml2{a} man-db{a}
  po-debconf{a}
0 packages upgraded, 20 newly installed, 0 to remove and 0 not upgraded.
Need to get 9191 kB/9656 kB of archives. After unpacking 25.6 MB will be used.
The following packages have unmet dependencies:
 pbuilder-satisfydepends-dummy : Depends: icedove-dev (= 24~) but it is not 
going to be installed.
 Depends: mozilla-devscripts (= 0.32~) but it 
is not going to be installed.
 Depends: python-ply but it is not going to be 
installed.
Unable to resolve dependencies!  Giving up...
[...]
Abort.
E: pbuilder-satisfydepends failed.
=

Here is the reason:
=
$ rmadison icedove-dev | grep wheezy
 icedove-dev | 10.0.12-1  | wheezy| amd64, armel, armhf, 
i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, 
sparc
 icedove-dev | 17.0.10-1~deb7u1   | wheezy-security   | ia64, kfreebsd-amd64, 
kfreebsd-i386, mips, mipsel
 icedove-dev | 24.5.0-1~deb7u1| wheezy-security   | s390, sparc
 icedove-dev | 24.6.0-1~deb7u1| wheezy-security   | amd64, armel, armhf, 
i386, powerpc, s390x
$ 
=

I confirm that adding the wheezy-security repository is enought to build
a wheezy-backports without changing anything in the current Debian
sources on GitHub.

Since we currently use this extension, I am interested in a
wheezy-backports and I could maintain it by myself, but only once it
reaches testing and anyway not before the next 3 months.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#755688: gpointing-device-settings: please add French translation (and maybe others)

[Luca Capello]

Package: gpointing-device-settings
Version: 1.5.1-6
Severity: wishlist
Tags: patch
User: cont...@itopie.ch
Usertags: itopie.ch-installation
User: i...@codha.ch
Usertags: codha.ch-installation

Hi there,

the .desktop file could enjoy the French translation below (as well as
others), courtesy of gnome-control-center_1:3.4.3.1-2:

--8---cut here---start-8---
Name[fr]=Souris et pavé tactile
Comment[fr]=Définir les préférences pour la souris et le pavé tactile
--8---cut here---end---8---

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 7.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gpointing-device-settings depends on:
ii  gconf2  3.2.5-1+build1
ii  libatk1.0-0 2.4.0-2
ii  libc6   2.13-38+deb7u3
ii  libcairo2   1.12.2-3
ii  libdbus-1-3 1.6.8-1+deb7u3
ii  libdbus-glib-1-20.100.2-1
ii  libfontconfig1  2.9.0-7.1
ii  libfreetype62.4.9-1.1
ii  libgconf2-4 3.2.5-1+build1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-5
ii  libgpds01.5.1-6
ii  libgtk2.0-0 2.24.10-2
ii  libpango1.0-0   1.30.0-1
ii  libxi6  2:1.6.1-1+deb7u1

gpointing-device-settings recommends no packages.

gpointing-device-settings suggests no packages.

-- no debconf information


signature.asc
Description: Digital signature

Bug#615092: patch for correctly saving setting in gconf

[Luca Capello]

user cont...@itopie.ch
usertags 615092 + itopie.ch-installation
user i...@codha.ch
usertags 615092 + codha.ch-installation
thanks

Hi there!

On Sat, 16 Jul 2011 12:07:11 +0200, Piers Titus van der Torren wrote:
 attached is a patch which corrects the following:
 * circular scrolling start point saved in gconf, was not saved at all
 * scrolling speed saved as int, was saved as bool

I have not tested your patch since I have another problem related to
settings not kept after logout (tapping properties not saved), but I
would like to note that it seems that nowadays configuration stuff
moved to dconf.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#598414: xserver-xorg-input-evdev: Tapping no longer works on touchpad

[Luca Capello]

forcemerge 572956 598414
severity 572956 important
user cont...@itopie.ch
usertags 572956 + itopie.ch-installation
user i...@codha.ch
usertags 572956 + codha.ch-installation
thanks

Hi there!

On Thu, 30 Sep 2010 21:26:54 +0900, Mattia Dongili wrote:
 On Thu, Sep 30, 2010 at 12:19:44AM +0100, Nattie Mayer-Hutchings wrote:
  On Wed, Sep 29, 2010 at 09:19:39PM +0900, Mattia Dongili wrote:
   man 4 synaptics should tell you how to configure tapping in xorg.conf
   (in short you should set the TabButton* options) but
   gpointing-device-settings saying that tapping is enabled sounds like a
   bug there. I'll reassign the bug report accordingly.
  
  Actually, tapping was disabled even before we installed
  gpointing-device-settings.  We believe these issues to be two separate 
  bugs.  
 
 There is no issue in the driver, the default configuration is the
 intended one, it may not be the best for all users but it's
 definitely not a bug.

I do not agree with the last sentence: it is not a bug for upstream, but
it is definitively a bug for the end-user and, according to Nattie
report, even a regression.

As you pointed out, however, there are two issues: first, the change in
the default behavior of xserver-xorg-input-synaptics and, second, the
fact that gpointing-device-settings does not correctly detect the
initial situation.

Again, as you pointed out, the latter was already reported, both in
Debian (#572956) and upstream, and because of your reasoning I have
merged the two bugs.

ATM and AFAIK, the only possible solution is the system-wide one you
pointed out, even better what explained on Ask Ubuntu, thus activating
the settings in /etc/X11/xorg.conf.d/class-touchpad-tapping.conf:

--8---cut here---start-8---
## file:usr/share/doc/xserver-xorg-input-synaptics/README.Debian
## 
http://askubuntu.com/questions/12435/how-do-i-restore-two-finger-middle-click-again
Section InputClass
  Identifiertouchpad-tapping
  MatchIsTouchpad true
  Driversynaptics
  OptionTapButton11
  OptionTapButton22
  OptionTapButton33
EndSection
--8---cut here---end---8---

Finally, the above solves the default configuration, not the per-user
one, since any customization is lost after logout:

  https://bugs.debian.org/615092

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#749324: volumeicon-alsa: Should provide a .desktop file

[Luca Capello]

tags 749324 + upstream
tags 749324 + patch
user cont...@itopie.ch
usertags 749324 + itopie.ch-installation
user i...@codha.ch
usertags 749324 + codha.ch-installation
thanks

Hi there!

On Mon, 26 May 2014 13:18:43 +0200, Matthijs Kooijman wrote:
 it would be great if this package could provide a .desktop file, which
 makes it easier to start. Also, this allows simply linking or copying
 the desktop file into ~/.config/autostart to make the application
 autostart.
 
 Perhaps it's even better if a desktop file is provided in
 /etc/xdg/autostart, so the application autostarts when installed, though
 that might conflict with existing volume handling tools (depending on
 the X session type chosen).

Here a working .desktop file for /etc/xdg/autostart, IMHO anything else
is useless:

--8---cut here---start-8---
[Desktop Entry]
Name=Volume Icon
Name[fr]=Icône pour le contrôle du volume
Comment=Lightweight volume control for the systray
Comment[fr]=Simple contrôle du volume pour la barre d'état
Icon=volume
Exec=volumeicon
Terminal=false
Type=Application
StartupNotify=false
--8---cut here---end---8---

 notify-osd has a similar problem and seems to handle this by adding
 X-GNOME-Autostart-enabled=false to make it disabled by default,
[...]
 Just providing a desktop file in /usr/share/applications would help in
 any case. This will allow using gnome-tweak-tool (which seems to be the
 de facto tool for gnome customization) to add volumeicon to the list of
 startup applications by picking it from a list.

I do not follow GNOME so closely, but the .desktop file above is the
same as xfce4-power-manager, which is clearly a non-GNOME application,
so it should be fine.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#754558: lxde-common: please add a PrintScreen keybinding

[Luca Capello]

Package: lxde-common
Version: 0.5.5-6
Severity: wishlist
Tags: patch
Control: affects -1 + lxde-core
Control: block -1 by 754207
User: cont...@itopie.ch
Usertags: itopie.ch-installation
User: i...@codha.ch
Usertags: codha.ch-installation

Hi there,

the Debian Openbox configuration comes with a Print keybinding (see
#754207): since the default LXDE installation on Debian is based on
Openbox, IMHO the Print keybinding should be available out of stock.

Fot this, lxde-core needs to at least Suggests: gnome-screenshot and
lxde-common should carry the following patch:

--8---cut here---start-8---
--- a/xdg/openbox/LXDE/rc.xml
+++ b/xdg/openbox/LXDE/rc.xml
@@ -176,6 +176,12 @@
 keyboard
   chainQuitKeyC-g/chainQuitKey
 
+  !-- from /etc/xdg/openbox/rc.xml, http://bugs.debian.org/754207 --
+  !-- Launch gnome-screenshot when PrintScreen is pressed --
+  keybind key=Print
+action name=Executecommandgnome-screenshot -i/command/action
+  /keybind
+
   !-- Keybindings for desktop switching --
--8---cut here---end---8---

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lxde-common depends on:
ii  lxsession  0.4.6.1-4

Versions of packages lxde-common recommends:
ii  lxde-core  4+nmu1

Versions of packages lxde-common suggests:
pn  lxlauncher  none

-- Configuration Files:
/etc/xdg/openbox/LXDE/rc.xml changed [not included]

-- no debconf information


signature.asc
Description: Digital signature

Bug#754560: lxde-common: replace ShowMenu C-Escape with A-F1 for consistency

[Luca Capello]

Package: lxde-common
Version: 0.5.5-6
Severity: minor
Tags: patch
User: cont...@itopie.ch
Usertags: itopie.ch-installation
User: i...@codha.ch
Usertags: codha.ch-installation

Hi there,

so far, I have failed to understand why the default ShowMenu
keybinding is C-Escape and not A-F1 as in other DE (e.g. GNOME) or
distributions (e.g. (L)Ubuntu)).  The major disadvantage of such a
choice is that different platforms do not have a consistent behavior
and thus a user switching between them will be lost.

The following patch fixes this:

--8---cut here---start-8---
--- a/xdg/openbox/LXDE/rc.xml
+++ b/xdg/openbox/LXDE/rc.xml
@@ -280,7 +280,8 @@
   /action
   /keybind
 
-  keybind key=C-Escape
+  !-- as in GNOME and (L)Ubuntu --
+  keybind key=A-F1
   action name=Execute
   commandlxpanelctl menu/command
   /action
--8---cut here---end---8---

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Versions of packages lxde-common depends on:
ii  lxsession  0.4.6.1-4

Versions of packages lxde-common recommends:
ii  lxde-core  4+nmu1

Versions of packages lxde-common suggests:
pn  lxlauncher  none

-- Configuration Files:
/etc/xdg/openbox/LXDE/rc.xml changed [not included]

-- no debconf information


signature.asc
Description: Digital signature

Bug#493722: libpaper1: change default to a4 as well

[Luca Capello]

tags 493722 + upstream
user cont...@itopie.ch
usertags 493722 + itopie.ch-installation
user i...@codha.ch
usertags 493722 + codha.ch-installation
thanks

Hi there!

On Thu, 01 Apr 2010 16:41:51 +0200, Sascha Silbe wrote:
 
 For the same reasons the default should be changed (to a4) as well.
 In addition, since letter is slightly larger than A4, it will cause trouble
 when trying to export (print or send via fax) documents if the default is
 incorrect. OTOH if the default is set to A4, all that happens is a slightly
 larger border.

Fully agree, which means that this is an upstream bug, tagged.

Any news on that?

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#754592: gigolo: should provide an XDG autostart .desktop file

[Luca Capello]

Package: gigolo
Version: 0.4.1+dfsg-1
Severity: minor
Tags: patch
User: cont...@itopie.ch
Usertags: itopie.ch-installation
User: i...@codha.ch
Usertags: codha.ch-installation

Hi there,

I am setting up several workstations and, to mimic Windows AD-managed
logins, SMB shares should be automatically mounted.  Instead of custom
scripts, such feature will be provided by Gigolo, which however lacks
XDG autostart integration.

Here a working .desktop file for /etc/xdg/autostart (based on
#749324), IMHO anything else is useless:

--8---cut here---start-8---
[Desktop Entry]
Name=Gigolo
Name[fr]=Gigolo
Comment=A simple frontend to easily connect to remote filesystems
Comment[fr]=Une interface simple pour se connecter facilement à des systèmes de 
fichiers à distance
Icon=gtk-network
Exec=gigolo
Terminal=false
Type=Application
StartupNotify=false
--8---cut here---end---8---

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gigolo depends on:
ii  libc6 2.13-38+deb7u3
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libgtk2.0-0   2.24.10-2
ii  libx11-6  2:1.5.0-1+deb7u1

Versions of packages gigolo recommends:
ii  gvfs-bin  1.12.3-4

gigolo suggests no packages.

-- no debconf information


signature.asc
Description: Digital signature

Bug#688969: lxpanel: the windows key does not pop up main menu

[Luca Capello]

reassign 688969 openbox 3.5.0-7
affects 688969 + lxpanel
user cont...@itopie.ch
usertags 688969 + itopie.ch-installation
user i...@codha.ch
usertags 688969 + codha.ch-installation
thanks

Hi there!

On Thu, 27 Sep 2012 17:15:04 +0200, Michal Suchanek wrote:
 In most desktop environments that contain a panel with main menu you
 can pop up the main menu pressing the windows/logo/meta/whatever key.
 
 This does not work with lxde making mouseless navigation quite
 challenging.

If I am not wrong, this is a problem in Openbox, the WM LXDE on Debian
is based on (bug reassigned).

And, again if I am not wrong, given the default Openbox configuration,
it is not possible to associate a single keybinding to a key when such a
key has a combination keybinding.  Other than the default upstream
configuration...

  http://openbox.org/wiki/Help:DefaultConfiguration

...Debian add another keybinding:
=
$ grep W- /etc/xdg/openbox/LXDE/rc.xml
  keybind key=W-F1
  keybind key=W-F2
  keybind key=W-F3
  keybind key=W-F4
  keybind key=W-d
  keybind key=W-e
  keybind key=W-r
$ 
=

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#754207: openbox: should Suggests: gnome-screenshot for PrintScreen

[Luca Capello]

Package: openbox
Version: 3.5.0-7
Severity: minor
User: cont...@itopie.ch
Usertags: itopie.ch-installation
User: i...@codha.ch
Usertags: codha.ch-installation

Hi there!

gnome-screenshot should be added to the Suggests:, since the default
rc.xml uses it:
=
$ grep -A 2 Print /etc/xdg/openbox/rc.xml 
  !-- Take a screenshot of the current window with gnome-screenshot when 
Alt+Print are pressed --
  keybind key=A-Print
action name=Executecommandgnome-screenshot -w/command/action
  /keybind
--
  !-- Launch gnome-screenshot when Print is pressed --
  keybind key=Print
action name=Executecommandgnome-screenshot/command/action
  /keybind
$ 
=

Moreover, what is the rationale for the default action for Print not
being interactive?  I do not have a default GNOME installation right
now, but IIRC pressing PrintScreen launches 'gnome-screenshot -i'.

Thx, bye,
Gismo/Luca

-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openbox depends on:
ii  dpkg  1.16.15
ii  libc6 2.13-38+deb7u1
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libice6   2:1.0.8-2
ii  libobrender27 3.5.0-7
ii  libobt0   3.5.0-7
ii  libsm62:1.2.1-2
ii  libstartup-notification0  0.12-1
ii  libx11-6  2:1.5.0-1+deb7u1
ii  libxau6   1:1.0.7-1
ii  libxext6  2:1.3.1-2+deb7u1
ii  libxinerama1  2:1.1.2-1+deb7u1
ii  libxml2   2.8.0+dfsg1-7+nmu3
ii  libxrandr22:1.3.2-2+deb7u1
ii  libxrender1   1:0.9.7-1+deb7u1

Versions of packages openbox recommends:
ii  obconf  1:2.0.3+20110805+debian-1
pn  openbox-themes  none

Versions of packages openbox suggests:
pn  libxml2-dev  none
pn  menu none
ii  python   2.7.3-4+deb7u1
ii  ttf-dejavu   2.33-3

-- no debconf information


signature.asc
Description: Digital signature

Bug#754229: lxpanel: sound volume plugin does not start alsamixer

[Luca Capello]

Package: lxpanel
Version: 0.5.10-1
Severity: normal
User: cont...@itopie.ch
Usertags: itopie.ch-installation
User: i...@codha.ch
Usertags: codha.ch-installation

Hi there,

I was not able to get the volume plugin start alsamixer, even if the
latter is installed.  There are no useful messages in ~/.xsession-errors
nor if I start lxpanel from the command line or from gdb.

I have also tried to edit the /etc/xdg/lxsession/LXDE/desktop.conf file
(and the user one), adding the following line, but without success:

  audio_manager/command=alsamixer

I am open to any suggestion, in the meantime I ended up installing
volumeicon-alsa ;-)

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lxpanel depends on:
ii  libasound2  1.0.25-4
ii  libatk1.0-0 2.4.0-2
ii  libc6   2.13-38+deb7u1
ii  libcairo2   1.12.2-3
ii  libfontconfig1  2.9.0-7.1
ii  libfreetype62.4.9-1.1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-5
ii  libgtk2.0-0 2.24.10-2
ii  libiw30 30~pre9-8
ii  libmenu-cache1  0.3.3-1
ii  libpango1.0-0   1.30.0-1
ii  libwnck22   2.30.7-1
ii  libx11-62:1.5.0-1+deb7u1
ii  lxmenu-data 0.1.2-2

lxpanel recommends no packages.

Versions of packages lxpanel suggests:
ii  iceweasel [www-browser]  24.6.0esr-1~deb7u1
ii  lxsession0.4.6.1-4
ii  w3m [www-browser]0.5.3-8

-- no debconf information


signature.asc
Description: Digital signature

Bug#754231: volumeicon-alsa: should not hardcode xterm but x-terminal-emulator

[Luca Capello]

Package: volumeicon-alsa
Version: 0.4.6-1
Severity: important
User: cont...@itopie.ch
Usertags: itopie.ch-installation
User: i...@codha.ch
Usertags: codha.ch-installation

Hi there,

src/config.c hardocodes xterm without a Depends: on that (which IMHO
would be plain wrong), x-terminal-emulator should be used instead.

I will send a Git patch against the collab-maint repository as soon as
this bug gets its number ;-)

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages volumeicon-alsa depends on:
ii  alsa-base   1.0.25+3~deb7u1
ii  libasound2  1.0.25-4
ii  libc6   2.13-38+deb7u1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-5
ii  libgtk2.0-0 2.24.10-2
ii  libnotify4  0.7.5-1
ii  libx11-62:1.5.0-1+deb7u1

volumeicon-alsa recommends no packages.

Versions of packages volumeicon-alsa suggests:
pn  alsamixergui | aumix-gtk | kmix | gnome-alsamixer  none
pn  notify-osd | xfce4-nofityd | notification-daemon   none

-- no debconf information


signature.asc
Description: Digital signature

Bug#673360: Bug#674439: [Pkg-xfce-devel] Bug#674439: remove OnlyShowIn=XFCE from xfce4-power-manager.desktop file

[Luca Capello]

user cont...@itopie.ch
usertags 674439 + itopie.ch-installation
user i...@codha.ch
usertags 674439 + codha.ch-installation
thanks

Hi there!

On Thu, 24 May 2012 20:45:23 +0200, Yves-Alexis Perez wrote:
 On jeu., 2012-05-24 at 14:59 +0200, Maximilian Gerhard wrote:
  Package: xfce4-power-manager
  Version: 1.0.11-2
  Severity: wishlist upstream
  
  Please remove OnlyShowIn=XFCE; from xfce4-power-manager.desktop file.
  Or at least extend it to support other DEs too, e.g.
  OnlyShowIn=XFCE;LXDE;. If you want to use xfce4-power-manager with a
  different DE than Xfce there is no menu entry nor will it autostart if
  you placed the .desktop file in an xdg autostart folder.
  
  Seen with LXDE as DE.
  
  Even if I install a package/program from a different DE that has a GUI I
  assume that I will find it somewhere in the menu.
  
 Some people disagree: 
 
 * http://bugs.debian.org/673363
 * http://bugs.debian.org/673360
 
 To be honest, I don't really care, I just think the current situation is
 suboptimal for everyone, and people just have to get used to it until
 someone comes with a solution which everyone like. 

Fully agree, but...

 You should still be able to override what's provided (wether manually
 by copying the desktop file to .local/share/applications and editing it,
 or through some graphical app like alacarte).

...I have to configure xfce4-power-manager to be shown in the LXDE
preferences *system-wide*, not for each of the ~20 users that *could*
log in a machine (LDAP users here!).  Which means that adding files at
login is a no-op, as well as menu editing after login.

Modifications to /etc/xdg/autostart/xfce4-power-manager.desktop will
be preserved on upgrades, but it is a bit strange to tell people to
configure an application to be started at login and then logoff/login
to have it started for the first time...

AFAIK, there is no good power manager for LXDE and most of the time
the advice I have found on the net is to use XFCE's one (as for other
LXDE components).  For this reason, IMHO the submitter's suggestion is
a different beast that #673360 or #673363.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#754231: volumeicon-alsa: should not hardcode xterm but x-terminal-emulator

[Luca Capello]

tags 754231 + patch
thanks

Hi there!

On Tue, 08 Jul 2014 23:29:55 +0200, Luca Capello wrote:
 I will send a Git patch against the collab-maint repository as soon as
 this bug gets its number ;-)

Attached.

Thx, bye,
Gismo / Luca
From 0a127658a3f2c2c6bb1cf1bdd3635d79bcfc92c7 Mon Sep 17 00:00:00 2001
From: Luca Capello l...@pca.it
Date: Tue, 8 Jul 2014 23:43:41 +0200
Subject: [PATCH] debian/patches/002_replace-hardcoded-xterm.diff: new
 (#754231)

---
 debian/patches/002_replace-hardcoded-xterm.diff | 16 
 debian/patches/series   |  1 +
 2 files changed, 17 insertions(+)
 create mode 100644 debian/patches/002_replace-hardcoded-xterm.diff

diff --git a/debian/patches/002_replace-hardcoded-xterm.diff b/debian/patches/002_replace-hardcoded-xterm.diff
new file mode 100644
index 000..7105c98
--- /dev/null
+++ b/debian/patches/002_replace-hardcoded-xterm.diff
@@ -0,0 +1,16 @@
+Description: Replace hardcoded xterm with x-terminal-emulator
+Bug-Debian: 754231
+Author: Luca Capello l...@pca.it
+Last-Update: 2014-07-08
+
+--- a/src/config.c
 b/src/config.c
+@@ -59,7 +59,7 @@
+ static void config_load_default()
+ {
+ 	if(!m_helper_program)
+-		config_set_helper(xterm -e 'alsamixer');
++		config_set_helper(x-terminal-emulator -e 'alsamixer');
+ 	if(!m_channel)
+ 		config_set_channel(NULL);
+ 	if(!m_card)
diff --git a/debian/patches/series b/debian/patches/series
index cc58d98..25164d0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 001_remove-individual-glib-headers.diff
+002_replace-hardcoded-xterm.diff
-- 
2.0.0



signature.asc
Description: Digital signature

Bug#660887: gpointing-device-settings: OnlyShowIn Should Include XFCE

[Luca Capello]

user cont...@itopie.ch
usertags 660887 + itopie.ch-installation
user i...@codha.ch
usertags 660887 + codha.ch-installation
thanks

Hi there!

On Wed, 22 Feb 2012 12:14:32 -0500, Daniel Dickinson wrote:
 This package is also useful/applicable to XFCE, therefore OnlyShowIn
 should include XFCE.

The same is true for LXDE.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#690540: libvirt-bin: dnsmasq should not use option --bind-interfaces

[Luca Capello]

user cont...@itopie.ch
usertags 690540 + itopie.ch.it-virtualization
thanks

Hi Guido,

On Sun, 04 May 2014 13:56:15 +0200, Guido Günther wrote:
 On Mon, Oct 15, 2012 at 01:09:38PM +0200, Luca Capello wrote:
  Package: libvirt-bin
  Version: 0.9.12-5
  Severity: wishlist
  Tags: pca.it-virtualization
  
  Hi there!
  
  While debugging #689221, I experienced such a bug, which is actually the
  counterpart of #504605, which I still think it deserves a better
  solution ;-)
 
 It uses bind-dynamic nowadays. Is this more what you'd expected?
 Cheers,

What does nowadays mean?  And for whom, dnsmasq or libvirt?  The bug
is still present in wheezy-backports:
=
# cat /etc/os-release 
PRETTY_NAME=Debian GNU/Linux 7 (wheezy)
NAME=Debian GNU/Linux
VERSION_ID=7
VERSION=7 (wheezy)
ID=debian
ANSI_COLOR=1;31
HOME_URL=http://www.debian.org/;
SUPPORT_URL=http://www.debian.org/support/;
BUG_REPORT_URL=http://bugs.debian.org/;
# dpkg-query -W \*libvirt\*
libvirt-bin 1.2.4-1~bpo70+1
libvirt01.2.4-1~bpo70+1
# cat /var/lib/libvirt/dnsmasq/default.conf 
##WARNING:  THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY
TO BE
##OVERWRITTEN AND LOST.  Changes to this configuration should be made
using:
##virsh net-edit default
## or other application using the libvirt API.
##
## dnsmasq conf file created by libvirt
strict-order
pid-file=/var/run/libvirt/network/default.pid
except-interface=lo
bind-interfaces
listen-address=192.168.122.1
dhcp-range=192.168.122.2,192.168.122.254
dhcp-no-override
dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases
dhcp-lease-max=253
dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile
addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts
# 
=

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#726398: linux: Fail to work with USB wifi dongle TP-Link TL-WN725N V2 (USB id 0bda:8179)

[Luca Capello]

fixed 726398 3.13.7-1~bpo70+1
usertags 726398 + pca.it-installation
thanks

Hi there!

On Tue, 15 Oct 2013 17:24:23 +0200, Petter Reinholdtsen wrote:
 [Steve Cotton]
 Sorry for incorrect information.  Bjørn is correct.
 
 (I guess it's better to confirm this in the BTS log than not to).

 Yes, I tested it on Jessie too, so I can confirm that it do not work
 there either.  Trying to tag this in the BTS meta information.

It works with 3.13.7-1~bpo70+1, tested on two different wheezy machines,
the firmware is however non-free:
=
# dmesg
[...]
usb 4-1.1: new high-speed USB device number 5 using ehci-pci
usb 4-1.1: New USB device found, idVendor=0bda, idProduct=8179
usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 4-1.1: Product: 802.11n NIC
usb 4-1.1: Manufacturer: Realtek
usb 4-1.1: SerialNumber: 00E04C0001
Chip Version Info: CHIP_8188E_Normal_Chip_TSMC_A_CUT_1T1R_RomVer(0)
r8188eu 4-1.1:1.0: firmware: direct-loading firmware rtlwifi/rtl8188eufw.bin
R8188EU: Firmware Version 11, SubVersion 1, Signature 0x88e1
MAC Address = a0:f3:c1:14:4e:56
IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
r8188eu 4-1.1:1.0: firmware: direct-loading firmware rtlwifi/rtl8188eufw.bin
r8188eu 4-1.1:1.0: firmware: direct-loading firmware rtlwifi/rtl8188eufw.bin
r8188eu 4-1.1:1.0: firmware: direct-loading firmware rtlwifi/rtl8188eufw.bin
# uname -a
Linux tinello 3.13-0.bpo.1-amd64 #1 SMP Debian 3.13.7-1~bpo70+1 (2014-03-29) 
x86_64 GNU/Linux
# dpkg-query -W firmware-realtek
firmware-realtek0.41~bpo70+1
# 
=

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#641902: network-manager: please provide a *full* CLI (with a proper name)

[Luca Capello]

Hi there!

On Wed, 02 Apr 2014 22:25:23 +0200, Michael Biebl wrote:
 Version: 0.9.8.8-4

 I'm going to close this bug since the latest network-manager version has
 a vastly improvde CLI, including the ability to create new connections,
 a better man page and bash completion.

Thank you for the notice, I would have wanted to dig into the upstream
changelog to find out the first version that introduced the possibility
for nmcli to add a Wi-Fi connection, but RL delayed me :-(

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#603904: Fresh installation of mailman has wrong permissions, causes archiving to fail

[Luca Capello]

tag 603904 + patch
user cont...@itopie.ch
usertags 603904 + debian-packaging
thanks

Hi there!

On Sat, 08 Mar 2014 20:56:15 +0100, b...@debian.org wrote:
 I confirm the problem.  FYI here's the permissions at Gna(.org) that
 have been working for at least 2 years, more likely 10:

   drwxrws--- 4065 www-data list 139264 Mar  8 17:30 
 /var/lib/mailman/archives/private/

The above reflects both /usr/share/doc/mailman/mailman-install.txt.gz
From wheezy (1:2.1.15-1) and sid (1:2.1.16-2), as well as the online
documentation:

  http://www.gnu.org/software/mailman/mailman-install/node9.html

--8---cut here---start-8---
   4 Check your installation

   After you've run make install, you should check that your installation
   has all the correct permissions and group ownerships by running the
   check_perms script.
[...]
   Warning: If you're running Mailman on a shared multiuser system, and
   you have mailing lists with private archives, you may want to hide the
   private archive directory from other users on your system. In that
   case, you should drop the other execute permission (o-x) from the
   archives/private directory. However, the web server process must be
   able to follow the symbolic link in public directory, otherwise your
   public Pipermail archives will not work. To set this up, become root
   and run the following commands:

# cd prefix/archives
# chown web-server-user private
# chmod o-x private

   You need to know what user your web server runs as. It may be www,
   apache, httpd or nobody, depending on your server's configuration.
--8---cut here---end---8---

However, the above is still not the case on a default wheezy
(1:2.1.15-1) installation: list:www-data for private and root:list for
public.  And indeed, the current Debian settings cause a permission
error, everything is OK for www-data, but not for list:
=
root@maison:~# ls -l /var/lib/mailman/archives/*
/var/lib/mailman/archives/private:
total 16
drwxrwsr-x 2 root www-data 4096 Mar 29 15:28 mailman
drwxrwsr-x 2 root www-data 4096 Mar 29 15:28 mailman.mbox
drwxrwsr-x 2 www-data www-data 4096 Mar 29 18:02 test
drwxrwsr-x 2 www-data www-data 4096 Mar 29 18:02 test.mbox

/var/lib/mailman/archives/public:
total 0
lrwxrwxrwx 1 www-data list 38 Mar 29 18:02 test - 
/var/lib/mailman/archives/private/test
root@maison:/etc# ls -lR /var/lib/mailman/archives/*
/var/lib/mailman/archives/private:
total 16
drwxrwsr-x 2 root www-data 4096 Mar 29 15:28 mailman
drwxrwsr-x 2 root www-data 4096 Mar 29 15:28 mailman.mbox
drwxrwsr-x 2 www-data www-data 4096 Mar 29 18:02 test
drwxrwsr-x 2 www-data www-data 4096 Mar 29 18:02 test.mbox

/var/lib/mailman/archives/private/mailman:
total 4
-rw-rw-r-- 1 root www-data 573 Mar 29 15:28 index.html

/var/lib/mailman/archives/private/mailman.mbox:
total 0

/var/lib/mailman/archives/private/test:
total 4
-rw-rw-r-- 1 www-data www-data 564 Mar 29 18:02 index.html

/var/lib/mailman/archives/private/test.mbox:
total 0

/var/lib/mailman/archives/public:
total 0
lrwxrwxrwx 1 www-data list 38 Mar 29 18:02 test - 
/var/lib/mailman/archives/private/test
root@maison:~# 
=

Simply doing as Sylvain and upstream suggest is enough, which actually
reflects the public folder permissions:
=
root@maison:~# chown www-data:list /var/lib/mailman/archives/private/
root@maison:~# chgrp -R list /var/lib/mailman/archives/private/
=

Please note that Yubao Liu already pointed this out, both on this bug as
well as on the Debian Mailman list:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603904#10
  
http://lists.alioth.debian.org/pipermail/pkg-mailman-hackers/2011-December/003877.html

The patch is trivial:

--8---cut here---start-8---
diffstat for mailman-2.1.16 mailman-2.1.16

 changelog |9 +
 rules |2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff -Nru mailman-2.1.16/debian/changelog mailman-2.1.16/debian/changelog
--- mailman-2.1.16/debian/changelog 2014-02-03 14:01:47.0 +0100
+++ mailman-2.1.16/debian/changelog 2014-03-30 16:44:58.0 +0200
@@ -1,3 +1,12 @@
+mailman (1:2.1.16-3~fix603904.1) UNRELEASED; urgency=medium
+
+  * debian/rules:
++ fix ownership on /var/lib/mailman/archives/private as upstream
+  suggests, also reflecting group ownership for public archives
+  (Closes: #603904).
+
+ -- Luca Capello l...@pca.it  Sun, 30 Mar 2014 16:44:58 +0200
+
 mailman (1:2.1.16-2) unstable; urgency=medium
 
   * Upload to unstable, as requested by Thijs; we did not encounter
diff -Nru mailman-2.1.16/debian/rules mailman-2.1.16/debian/rules
--- mailman-2.1.16/debian/rules 2014-02-03 13:47:42.0 +0100
+++ mailman-2.1.16/debian/rules 2014-03-30 17:18:22.0 +0200
@@ -179,7 +179,7 @@
debian/mailman/usr/lib/$(package)/Mailman/Cgi/*
 
chmod o-rx debian/mailman/var/lib

Bug#339059: mailman: Mailman/debconf forgets answer to language list question at install time

[Luca Capello]

found 339059 1:2.1.13-5
found 339059 1:2.1.15-1
users cont...@itopie.ch
usertags 339059 + debian-packaging
thanks

Hi there!

On Sun, 15 Jul 2012 14:13:47 +0200, L.W. van Braam van Vloten wrote:
 Today I found that bug 339059 still exists in package
 version 1:2.1.13-5 (Squeeze)

Marked as such.

 I found no evidence in the changelog that the issue is resolved in the
 newest version (1:2.1.15-1; currently in testing).

It is not, marked as such.

 I can not judge the severity of this ug, but it is already open for a  
 long time...

/var/lib/dpkg/info/mailman.config contains:
--8---cut here---start-8---
# This script will be invoked by apt-get 2 times in a row, once when
# preconfiguring the package and a second time just before running the
# postinst script.  OTOH when installing the package with dpkg or when
# reconfiguring the package, it runs only once.
#
# It scans all mailing lists on a system for used languages which may
# be quite time consuming on systems with many lists; hence we better
# avoid to run that scan twice in a row.
# 
# The debconf template mailman/used_languages holds the result of the
# scan but is never presented to the user, instead its scanned flag
# indicates if it holds a fresh value and is reset by the postinst,
# while its seen flag is mainly used for cosmetical reasons to mark
# processed values in debconf-show output.

db_get mailman/used_languages || true
used_languages=${RET}
db_fget mailman/used_languages scanned || true
scanned=${RET}

if ! which list_lists /dev/null 21; then
  # For 1st time installers there is no used language.
  db_set  mailman/site_languages en
  db_set  mailman/used_languages 
  db_fset mailman/used_languages scanned false
else
[...]
--8---cut here---end---8---

I guess that at installation time the if is true (there is no list at
all) and thus mailman/site_languages is set by default without taking
into consideration the interactive or preseeded choice.

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#653679: mailman: Installation error when the script generates the languages ​​chosen

[Luca Capello]

fixed 653679 1:2.1.15-1
users cont...@itopie.ch
usertags 653679 + itopie.ch-lists
thanks

Hi there!

On Fri, 30 Dec 2011 09:08:56 +0100, Frederic LIETART wrote:
 Package: mailman
 Version: 1:2.1.13-5
 Severity: important

 When installing the mailman, after choosing the languages ​​available, then 
 the default language, the installation script failed.

I was not able to reproduce the bug with the current version in wheezy,
i.e. 1:2.1.15-1, thus closing this bug, feel free to reopen it in case.

Please note that there is a bug about languages at installation time,
but it is a Debian-packaging one:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339059#50

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#668304: [Pkg-mailman-hackers] Bug#668304: mailman: Translations should use unicode charset

[Luca Capello]

found 668304 1:2.1.15-1
user cont...@itopie.ch
usertags 668304 + itopie.ch-lists
thanks

Hi there!

On Wed, 07 Aug 2013 13:22:29 +0200, Thorsten Glaser wrote:
 On Wed, 7 Aug 2013, Ralf Jung wrote:

 Any news on this? Wheezy shipped with this issue still present.

 Yeah, sorry. I got it fixed in my local version, but that’s
 hi  mailman   1:2.1.13-4.1ssl i386Powerful, web-based 
 mailing list manager
 and I had not yet had the time to get back to merging
 this into the stock Debian package.

Ping?

This bug seems to be a bit more deeper than the simple translations,
given that any output to the terminal is not UTF-8-safe:
=
root@maison:~# locale
LANG=en_US.UTF-8
LANGUAGE=fr_CH:fr
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=fr_CH.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=it_IT.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=
root@maison:~# apt-get update
Atteint http://ftp.ch.debian.org wheezy Release.gpg
Réception de : 1 http://ftp.ch.debian.org wheezy-updates Release.gpg [836 B]
 ^
[...]
129 ko réceptionnés en 1s (117 ko/s)
^^
Lecture des listes de paquets... Fait
root@maison:~# dpkg-reconfigure mailman
[...]
Installing site language en  done.
Installing site language fr . done.
Installing site language it  done.
Pas de mise � jour n�cessaire.
^   ^
Site list for mailman missing (looking for list named 'mailman'). ... (warning).
Please create it; until then, mailman will refuse to start. ... (warning).
root@maison:~#
root@maison:~# check_perms
Les r�pertoires doivent �tre au moins en 02775 : /var/lib/mailman/logs
 ^  ^
[...]
root@maison:~# 
=

IMHO the severity of this bug is a bit more than normal, if not because
UTF-8 is enabled by default since etch, at least because UTF-8 has been
proposed as a release goal for jessie:

  http://lists.debian.org/20130812005152.ga28...@angband.pl
  https://wiki.debian.org/ReleaseGoals/utf-8

FYI, I added mailman to the list of UTF-8 broken apps:

  https://wiki.debian.org/UTF8BrokenApps?action=diffrev1=39rev2=40

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#695270: add support for disabling DPMS via preseeding

[Luca Capello]

Hi Cyril,

Sorry for being late, it has been a while I tried the Debian BabelBox on
a VM, especially considering that I do not have the Debian Events Box
anymore.

On Fri, 28 Feb 2014 13:58:45 +0100, Cyril Brulebois wrote:
 Cyril Brulebois k...@debian.org (2014-02-14):
 I've implemented support for dpms=false/dpms=true in rootskel-gtk:
   
 http://anonscm.debian.org/gitweb/?p=d-i/rootskel-gtk.git;a=commitdiff;h=ac4176a5a857b8f1ac7de82a479c7723908bea14
 […]
 It would probably be nice to check that this name doesn't conflict with
 any kernel-side parameters, and whether that's an appropriate name at
 all.

 No clash according to “git grep dpms -- Documentation” as of linux
 v3.14-rc4.

Thank you for your work and the follow-up.

 Luca, Holger, Per, any comments on the naming of the option?

Perfectly fine for me, I guess that if someday Linux will gain such an
option it will automatically do what we were looking for ;-)

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#740627: trac-email2trac: INSTALL file not included, but referred by README

[Luca Capello]

Package: trac-email2trac
Version: 2.4.7-1
Severity: normal
File: /usr/share/doc/trac-email2trac/README
Usertags: fetons-linux.ch-installation

Hi there!

/usr/share/doc/trac-email2trac/README says:

  See INSTALL for the how to setup the utilities

However, the package does not provide any INSTALL file or any other kind
of documentation, except for the delete_spam and email2trac manpages.

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages trac-email2trac depends on:
ii  python  2.7.3-4+deb7u1
ii  trac0.12.5-3~deb7u1

trac-email2trac recommends no packages.

trac-email2trac suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#568577: Please provide pam-auth-update rule for pam_mkhomedir

[Luca Capello]

usertags 568577 + fetons-linux.ch-authentication
thanks

Hi there!

First of all: Steve, any news on this bug?

On Wed, 22 May 2013 09:50:03 +0200, Petter Reinholdtsen wrote:
 [Luca Capello 2011-01-07]
 I thought about that as well, but why would you prefer that (a single
 package for a 7k module...) to preseeding, as you suggested in your
 first post?

 Preseeding only work when the package is installed.  And I would like to
 be able to enable pam_mkhomedir by just installing the set of packages
 needed for the task/profile I want to set up on the machine, also after
 it is already installed.

It seems my understanding of how debconf-set-selections works was wrong.
I was expecting that setting a value with it will result in such a value
being kept at the next dpkg-reconfigure run, which is not the case in
the following example:

  [/usr/share/pam-configs/mkhomedir with 'Default: no', otherwise as in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568577#15]
  # echo 'libpam-runtime libpam-runtime/profiles multiselect unix, ldap, 
mkhomedir' | debconf-set-selections
  # dpkg-reconfigure -phigh libpam-runtime
  [or DEBIAN_FRONTEND=noninteractive dpkg-reconfigure libpam-runtime]
  # debconf-show libpam-runtime | grep profiles:
  * libpam-runtime/profiles: unix, ldap

Am I missing something?

 =
 luca@gismo:~$ debconf-show libpam-runtime | grep profiles
 debconf: DbDriver passwords warning: could not open \
  /var/cache/debconf/passwords.dat: Permission denied
   libpam-runtime/no_profiles_chosen:
 * libpam-runtime/profiles: unix, ldap, smbpasswd-migrate, mkhomedir
 luca@gismo:~$ 
 =

 I believe these preseeding values do not really work when installing
 1500 packages in one tasksel run, where some of them are PAM modules,
 because not all of them will be installed and configured when
 pam-auth-update uses the preseed value, thus the machine might end up
 with the wrong setup, depending on installation order for the packages.

Which IMHO means that we need a way to add *consecutive* values to
libpam-runtime/profiles, not split PAM modules into small packages.

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#695325: document workaround for omitted script run_email2trac in package trac-email2trac

[Luca Capello]

block 695325 by 740627
usertags 695325 + fetons-linux.ch-installation
thanks

Hi there!

On Fri, 07 Dec 2012 06:27:56 +0100, Lukas Mueller wrote:
 The trac-email2trac package is missing the run_email2trac script. It is not
 strictly necessary but the workaround should be documented in the man pages 
 for
 email2trac.

While adding the INSTALL file could be enough (see #740627, thus the
blocking), IMHO having both run_email2trac and the full documentation
would be better:

  https://oss.trac.surfsara.nl/email2trac/wiki/Email2tracMta

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#740662: nslcd: missing escaping in pam_check_service_attr example

[Luca Capello]

Package: nslcd
Version: 0.8.10-4
Severity: normal
File: /usr/share/man/man5/nslcd.conf.5.gz
Tags: patch
Usertags: fetons-linux.ch-authentication

Hi there,

this could be considered a follow-up for #610925 ;-)

I was adding LDAP authentication against services (i.e. PADL's
pam_ldap's pam_check_service_attr) using the example in nslcd.conf.5:

--8---cut here---start-8---
pam_authz_search FILTER

   For example, to check that the user has a proper
   authorizedService value if the attribute is present (this almost
   emulates the pam_check_service_attr option in PADL's pam_ldap):

   ((objectClass=posixAccount)(uid=$username)\
 (|(authorizedService=$service)(!(authorizedService=*
--8---cut here---end---8---

However, the above allows authentication for users missing the attribute
and indeed the correct filter for `ldapsearch -x` seems to be...

  ((objectClass=posixAccount)(uid=$username)\
(|(authorizedService=$service)(!(authorizedService=\\*

...which translates to the following nslcd filter:

  ((objectClass=posixAccount)(uid=$username)\
(|(authorizedService=$service)(!(authorizedService=*

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nslcd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.49
ii  libc6  2.13-38+deb7u1
ii  libgssapi-krb5-2   1.10.1+dfsg-5+deb7u1
ii  libldap-2.4-2  2.4.31-1+nmu2

Versions of packages nslcd recommends:
ii  bind9-host [host]   1:9.8.4.dfsg.P1-6+nmu2+deb7u1
ii  host1:9.8.4.dfsg.P1-6+nmu2+deb7u1
ii  ldap-utils  2.4.31-1+nmu2
ii  libnss-ldapd [libnss-ldap]  0.8.10-4
ii  libpam-ldapd [libpam-ldap]  0.8.10-4
pn  nscdnone

Versions of packages nslcd suggests:
pn  kstart  none

-- debconf information:
  nslcd/ldap-sasl-realm:
* nslcd/ldap-starttls: false
  nslcd/ldap-sasl-krb5-ccname: /var/run/nslcd/nslcd.tkt
* nslcd/ldap-auth-type: simple
  nslcd/ldap-reqcert:
* nslcd/ldap-uris: ldap://ldap.fetons-linux.ch
  nslcd/ldap-sasl-secprops:
* nslcd/ldap-binddn: [REMOVED]
  nslcd/ldap-sasl-authcid:
  nslcd/ldap-sasl-mech:
* nslcd/ldap-base: dc=fetons-linux,dc=ch
  nslcd/ldap-sasl-authzid:


signature.asc
Description: PGP signature