Bug#1068713: closing 1068713

[Vincent Danjean]

close 1068713 2.5.10-1
thanks

This bug is already fixed in upstream release 2.5.10

Bug#1020312: usrmerge: systemd file disappearing

[Vincent Danjean]

Le 20/09/2022 à 01:11, Vincent Danjean a écrit :

   Hi,

Le 19/09/2022 à 23:49, Luca Boccassi a écrit :

Are you sure the problem was not there beforehand?


Yes. Due to the numerous missing files, I'm sure the problem
comes from the apt upgrade. The FS is in a good state (no
corruption) with nearly 9GB free (so no out-of-space problem).
  My system was perfectly booting and working before.

  Note that usrmerge has really run: I see this package that
would be newly installed before starting the upgrade (and
I read its bug page and the links to the TC decisions because
initially I did not want to merge my /usr).
  So, I run 'ls /' in a terminal before and after the upgrade
and I saw the changes. Now:
vdanjean@eyak:~$ ls -l / | grep -- '->'
lrwxrwxrwx   1 root root  7 19 sept. 21:34 bin -> usr/bin
lrwxrwxrwx   1 root root 30 12 sept. 18:44 initrd.img -> 
boot/initrd.img-5.19.0-1-amd64
lrwxrwxrwx   1 root root 30 12 sept. 18:44 initrd.img.old -> 
boot/initrd.img-5.18.0-4-amd64
lrwxrwxrwx   1 root root  7 19 sept. 21:34 lib -> usr/lib
lrwxrwxrwx   1 root root  9 19 sept. 21:34 lib32 -> usr/lib32
lrwxrwxrwx   1 root root  9 19 sept. 21:34 lib64 -> usr/lib64
lrwxrwxrwx   1 root root 10 19 sept. 21:34 libx32 -> usr/libx32
lrwxrwxrwx   1 root root  8 19 sept. 21:34 sbin -> usr/sbin
lrwxrwxrwx   1 root root 27 12 sept. 18:44 vmlinuz -> 
boot/vmlinuz-5.19.0-1-amd64
lrwxrwxrwx   1 root root 27 12 sept. 18:44 vmlinuz.old -> 
boot/vmlinuz-5.18.0-4-amd64
vdanjean@eyak:~$


   I will re-run debsums (it seems that the "|&" polute the output
a litle bit, I want to be sure I reinstalled all required packages)


Missing files are sent to stderr by debsums, hence the mess
in my initial log.
After a rerun of debsums, I will have to reinstall
gitlab-ci-multi-runner but I need to manually download it
(it is not a package from Debian). All the others seem now
correct.

  Regards
Vincent



   I also put in attachement the dpkg log file (I do not see anything
special when I've done the initial "apt upgrade")
First is my "apt upgrade"
At 21:56, there is my "apt install --reinstall systemd"
At 22:19, I upgraded pipewire (not done before because this requires the 
removal of pulseaudio)
At 23:52, I reinstalled some package from the rescue system
At 00:18, I installed debsums
At 00:46, I reinstalled all problematic packages

   Regards,
     Vincent

Bug#1020312: usrmerge: systemd file disappearing

[Vincent Danjean]

Package: usrmerge
Version: 30+nmu2
Severity: serious
Justification: break other packages upgrades

When I upgraded my system to current unstable, usrmerge has
been pulled-in due to the init-system-helpers dependency.
But one package fails to upgrade (fetchmail) due to
/lib/systemd/system/sysinit.target missing.
Reinstalling the systemd package fixes the problem.

Feel free to reassign to systemd if you think the problem
comes from it but usrmerge is my first guess (without any
specific evidence)

Note that systemd does *not* upgrade today (see at the end
of the commands)

vdanjean@eyak:~$ sudo apt upgrade
[...]
Paramétrage de fetchmail (6.4.33-2) ...
insserv: warning: current stop runlevel(s) (empty) of script `fetchmail' 
overrides LSB defaults (0 1 6).
Failed to restart fetchmail.service: Unit sysinit.target not found.
invoke-rc.d: initscript fetchmail, action "restart" failed.
○ fetchmail.service - LSB: init-Script for system wide fetchmail daemon
 Loaded: loaded (/etc/init.d/fetchmail; generated)
 Active: inactive (dead)
   Docs: man:systemd-sysv-generator(8)

sept. 19 20:27:35 eyak systemd[1]: Starting LSB: init-Script for system wide 
fetchmail daemon...
sept. 19 20:27:35 eyak fetchmail[2556]: Not starting fetchmail daemon, disabled 
via /etc/default/fetchmail.
sept. 19 20:27:35 eyak systemd[1]: Started LSB: init-Script for system wide 
fetchmail daemon.
sept. 19 21:35:02 eyak systemd[1]: Stopping LSB: init-Script for system wide 
fetchmail daemon...
sept. 19 21:35:02 eyak fetchmail[22013]: Not starting fetchmail daemon, 
disabled via /etc/default/fetchmail.
sept. 19 21:35:02 eyak systemd[1]: fetchmail.service: Deactivated successfully.
sept. 19 21:35:02 eyak systemd[1]: Stopped LSB: init-Script for system wide 
fetchmail daemon.
dpkg: erreur de traitement du paquet fetchmail (--configure) :
 installed fetchmail package post-installation script subprocess returned error 
exit status 1
Des erreurs ont été rencontrées pendant l'exécution :
 fetchmail
vdanjean@eyak:~$ sudo systemctl cat fetchmail
# /run/systemd/generator.late/fetchmail.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/fetchmail
Description=LSB: init-Script for system wide fetchmail daemon
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=network-online.target
After=remote-fs.target
After=mail-transport-agent.target
After=postfix.service
After=exim4.service
After=nss-lookup.target
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/fetchmail start
ExecStop=/etc/init.d/fetchmail stop
vdanjean@eyak:~$ sudo systemctl restart fetchmail
Failed to restart fetchmail.service: Unit sysinit.target not found.
vdanjean@eyak:~$ sudo systemctl status sysinit.target
● sysinit.target
 Loaded: not-found (Reason: Unit sysinit.target not found.)
 Active: active since Mon 2022-09-19 20:27:32 CEST; 1h 16min ago
  Until: Mon 2022-09-19 20:27:32 CEST; 1h 16min ago

sept. 19 20:27:32 eyak systemd[1]: Reached target System Initialization.
vdanjean@eyak:~$ sudo systemctl daemon-reexec 
vdanjean@eyak:~$ sudo systemctl status sysinit.target
● sysinit.target
 Loaded: not-found (Reason: Unit sysinit.target not found.)
 Active: active since Mon 2022-09-19 20:27:32 CEST; 1h 17min ago
  Until: Mon 2022-09-19 20:27:32 CEST; 1h 17min ago

sept. 19 20:27:32 eyak systemd[1]: Reached target System Initialization.
vdanjean@eyak:~$ dpkg -S sysinit.target
udev: /lib/systemd/system/sysinit.target.wants/systemd-udevd.service
systemd: /lib/systemd/system/sysinit.target.wants/systemd-sysctl.service
systemd: /lib/systemd/system/sysinit.target.wants/dev-hugepages.mount
systemd: /lib/systemd/system/sysinit.target.wants/systemd-random-seed.service
systemd: /lib/systemd/system/sysinit.target.wants/systemd-sysusers.service
systemd: /lib/systemd/system/sysinit.target.wants/veritysetup.target
systemd: 
/lib/systemd/system/sysinit.target.wants/systemd-machine-id-commit.service
udev, systemd: /lib/systemd/system/sysinit.target.wants
udev: /lib/systemd/system/sysinit.target.wants/systemd-udev-trigger.service
systemd: /lib/systemd/system/sysinit.target.wants/systemd-journald.service
systemd: /lib/systemd/system/sysinit.target.wants/systemd-update-utmp.service
systemd: /lib/systemd/system/sysinit.target.wants/sys-kernel-debug.mount
systemd: /lib/systemd/system/sysinit.target.wants/sys-kernel-config.mount
systemd: /lib/systemd/system/sysinit.target
systemd: /lib/systemd/system/sysinit.target.wants/dev-mqueue.mount
systemd: /lib/systemd/system/sysinit.target.wants/sys-fs-fuse-connections.mount
systemd: 
/lib/systemd/system/sysinit.target.wants/systemd-ask-password-console.path
systemd: /lib/systemd/system/sysinit.target.wants/systemd-binfmt.service
systemd: 

Bug#1004769: Video not handled anymore for now

[Vincent Danjean]

Le 16/07/2022 à 18:50, Steven Robbins a écrit :

I would say that there may well be others in your situation so if you do find a
method please report back to this bug.


  For my personnal use, until upstream provides a correct fix, I recompile
digikam 7.7.0-1 (-2 was not pushed in the git ;-) ) with devel packages
of ffmpeg4 (from stable) installed (other build dependencies come from
unstable) [I only revert the commit that disable video and add a
changelog entry].
  The result is packages with video support, but using ffmpeg from
stable (version 4). So, it is ok for my personnal use (but unsuitable
for official Debian). If others are interested, you can look here:

http://people.debian.org/~vdanjean/debian/pool/main/d/digikam/

Note: no support is provided. So particular tests have been done, ...

  Regards,
Vincent

Bug#1004769: Video not handled anymore for now

[Vincent Danjean]

Le 16/07/2022 à 18:50, Steven Robbins a écrit :

Thank you for the suggestion.  I was completely unaware of "apt-listbugs".

I have just re-titled and changed the severity of this bug.


Great, it can help other users to avoid the upgrade if they want to.


Due to the large dependencies, it is probably very difficult to
downgrade digikam to a version with video support once 4:7.7.0-1
is installed. I did not try for now.


I haven't tried either, so I don't know.  Maybe one can just pull the packages
from the last stable release?  Build the 7.6 source package ?

I would say that there may well be others in your situation so if you do find a
method please report back to this bug.


Reading bug reports (in particular [1] and [2]), the root cause comes from
the ffmpeg transition in Debian. Trying to reverse this would be very
difficult leading to lots of downgrade of other packages (going back to
stable versions).

I'm also afraid that the older digikam would run with a upgraded
database. I'm not sure this won't corrupt some internal tables...

If I've time, I would probably try to build local ffmpeg4 packages
(or to install previous one if they are coinstallable) and rebuild
digikam with ffmpeg4. Of cause, this would be a local workaround,
not something sutable for Debian.

  Thanks for your work on digikam packaging

  Vincent

[1] https://bugs.kde.org/show_bug.cgi?id=453840
[2] https://bugs.kde.org/show_bug.cgi?id=448681

Bug#955488: nat-rtsp-dkms: Does not build with kernel >= 5.3

[Vincent Danjean]

Source: nat-rtsp
Version: 0.7+4.18-0.1
Followup-For: Bug #955488

I've been hit by this bug (trying to use it with the
kernel 5.7.0-0.bpo.2-amd64).
My workaround has been to manually apply the patch from
https://github.com/openwrt/packages/pull/11468

  Regards,
Vincent

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#959635: latex-make: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Vincent Danjean]

Le 11/05/2020 à 14:26, Andreas Tille a écrit :
> On Mon, May 11, 2020 at 01:53:10PM +0200, Vincent Danjean wrote:
>> Le 11/05/2020 à 13:48, Vincent Danjean a écrit :
>>> Le 11/05/2020 à 13:38, Andreas Tille a écrit :
>>>> BTW, I used routine-update on the packaging in salsa[1] and realised
>>>> that the package is using Python2 for no good reason.
>>
>> It should have been fixed in 2.3.0-3
>> "python" is used in upstream script, but a debian patch changes this in 
>> "python3".
>> Did I miss an occurrence ?
> 
> If you mean this patch
> 
> 
> https://salsa.debian.org/debian/latex-make/-/blob/master/debian/patches/python3.patch
>  
> 
> it is what I just pushed some hours ago.

I mean this one :
https://sources.debian.org/patches/latex-make/2.3.0-3/deb_specific__force-python3.patch/

That is probably nearly the same. I uploaded to Debian in January, but I forgot 
to push to salsa :-(
I'm really sorry.

  Regards,
Vincent

> Hope this helps
> 
> Andreas.
> 
> 

Bug#959635: latex-make: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Vincent Danjean]

Le 11/05/2020 à 13:48, Vincent Danjean a écrit :
> Le 11/05/2020 à 13:38, Andreas Tille a écrit :
>> BTW, I used routine-update on the packaging in salsa[1] and realised
>> that the package is using Python2 for no good reason.

It should have been fixed in 2.3.0-3
"python" is used in upstream script, but a debian patch changes this in 
"python3".
Did I miss an occurrence ?

  Regards,
Vincent

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




signature.asc
Description: OpenPGP digital signature

Bug#959635: latex-make: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Vincent Danjean]

  Hi,

Le 11/05/2020 à 13:38, Andreas Tille a écrit :
> Hi,
> 
> I tried to track down the issue and called `make -n` in my pbuilder
> chroot.  It seems the issue can be found somewhere here:
> 
> 
> /build/latex-make-2.3.0/examples# texmf/scripts/latex-make/svg2dev.py 
> -L pdftex fig/logo.svg fig/logo.pdftex
> Unable to init server: Could not connect: Connection refused
> Unknown option -z
> Traceback (most recent call last):
>   File "/usr/lib/python3.8/shutil.py", line 788, in move
> os.rename(src, real_dst)
> FileNotFoundError: [Errno 2] No such file or directory: 'fig/logo.pdftex_tex' 
> -> 'fig/logo.pdftex_t'
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "texmf/scripts/latex-make/svg2dev.py", line 41, in 
> main()
>   File "texmf/scripts/latex-make/svg2dev.py", line 36, in main
> create_image(input_filename, output_filename, svg2pdf)
>   File "texmf/scripts/latex-make/svg2dev.py", line 16, in create_image
> shutil.move(n1, n2)
>   File "/usr/lib/python3.8/shutil.py", line 802, in move
> copy_function(src, real_dst)
>   File "/usr/lib/python3.8/shutil.py", line 432, in copy2
> copyfile(src, dst, follow_symlinks=follow_symlinks)
>   File "/usr/lib/python3.8/shutil.py", line 261, in copyfile
> with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
> FileNotFoundError: [Errno 2] No such file or directory: 'fig/logo.pdftex_tex'
> 
> 
> I have no idea what server is tried to connect and whyt this all means
> but may be that's a place to start with further investigation.

  If I recall correctly, inskape is invoked non-interractively to do the
conversion. So it is probably inkscape that changes its options.

> BTW, I used routine-update on the packaging in salsa[1] and realised
> that the package is using Python2 for no good reason.  Astonishing there
> is no according bug but I tried to switch it to Python3 just in case.
> The result above is not different whether using Python2 or Python3.

  The compatibility is here for a long time (for ubuntu compatibility)
but I forget to change it in the Debian package. I will fix all of this.

  Thanks
Vincent

> Hope this helps a bit
> 
>  Andreas.
> 
> 
> [1] https://salsa.debian.org/debian/latex-make
> 


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

Bug#932299: closed by Vincent Danjean (Bug#932299: fixed in owfs 3.2p3+dfsg1-3)

[Vincent Danjean]

  Hi,

Le 05/08/2019 à 14:06, Bernhard Schmidt a écrit :
> On Thu, Jul 25, 2019 at 10:54:04AM +, Debian Bug Tracking System wrote:
> 
> Hi Vincent,
> 
>> This is an automatic notification regarding your Bug report
>> which was filed against the src:owfs package:
>>
>> #932299: owfs: FTBFS: relocation R_X86_64_32 against symbol `_Py_NoneStruct' 
>> can not be used
>>
>> It has been closed by Vincent Danjean .
> 
> It won't migrate to testing because it was not a source-only upload. See 
> 
> https://lists.debian.org/debian-release/2019/07/msg00053.html 
> 
> second paragraph.
> 
> Could you perform a source-only upload?

  Many thanks for the advise. I was on holidays for 3 weeks, so I just
saw your message. A source-only upload is on the way.

  Regards,
Vincent

> Thanks,
> Bernhard
> 


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

Bug#922350: udevd does not start after reboot

[Vincent Danjean]

Le 15/02/2019 à 08:01, Vincent Danjean a écrit :
> Le 14/02/2019 à 22:59, Felipe Sateler a écrit :
>> Is udev by any chance i386 instead of amd64?
> 
> I don't think so:
> vdanjean@eyak:~$ apt-cache policy udev:i386
> udev:i386:
>   Installé : (aucun)

However, systemd was installed as i386:
vdanjean@eyak:~$ apt-cache policy systemd:i386
systemd:i386:
  Installé : 240-5
  Candidat : 240-5
 Table de version :
 *** 240-5 500
500 http://ftp.fr.debian.org/debian testing/main i386 Packages
500 http://ftp.fr.debian.org/debian unstable/main i386 Packages
100 /var/lib/dpkg/status
 239-12~bpo9+1 100
100 http://ftp.fr.debian.org/debian stretch-backports/main i386 Packages
 232-25+deb9u8 500
500 http://security.debian.org stretch/updates/main i386 Packages
 232-25+deb9u6 500
500 http://ftp.fr.debian.org/debian stretch/main i386 Packages
vdanjean@eyak:~$ apt-cache policy systemd:amd64
systemd:
  Installé : (aucun)
  Candidat : 240-5
 Table de version :
 240-5 500
500 http://ftp.fr.debian.org/debian testing/main amd64 Packages
500 http://ftp.fr.debian.org/debian unstable/main amd64 Packages
 239-12~bpo9+1 100
100 http://ftp.fr.debian.org/debian stretch-backports/main amd64 
Packages
 232-25+deb9u8 500
500 http://security.debian.org stretch/updates/main amd64 Packages
 232-25+deb9u6 500
500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages

It probably comes from the fact that:
1) using apt-listbugs, I blocked the upgrade of systemd due to
   919231
2) the upgrade fails due to another package. So I've to go with
   'apt install -f'
3) 'apt install -f' alone was removing packages I would like to keep
   (such as digikam), so I forced some packages on the command line
4) due to (1), apt probably solved some problem by selecting the
   i386 version of systemd (I did not remark anything during the
   installation)

  So, the severity can be lowered and I will test with a reboot
as soon as possible.

  Regards,
    Vincent

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

Bug#922350: udevd does not start after reboot

[Vincent Danjean]

Le 14/02/2019 à 22:59, Felipe Sateler a écrit :
> Is udev by any chance i386 instead of amd64?

I don't think so:
vdanjean@eyak:~$ apt-cache policy udev:i386
udev:i386:
  Installé : (aucun)
  Candidat : 240-5
 Table de version :
 240-5 500
500 http://ftp.fr.debian.org/debian testing/main i386 Packages
500 http://ftp.fr.debian.org/debian unstable/main i386 Packages
 239-12~bpo9+1 100
100 http://ftp.fr.debian.org/debian stretch-backports/main i386 Packages
 232-25+deb9u8 500
500 http://security.debian.org stretch/updates/main i386 Packages
 232-25+deb9u6 500
500 http://ftp.fr.debian.org/debian stretch/main i386 Packages
vdanjean@eyak:~$ apt-cache policy udev:amd64
udev:
  Installé : 240-5
  Candidat : 240-5
 Table de version :
 *** 240-5 500
500 http://ftp.fr.debian.org/debian testing/main amd64 Packages
500 http://ftp.fr.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
 239-12~bpo9+1 100
100 http://ftp.fr.debian.org/debian stretch-backports/main amd64 
Packages
 232-25+deb9u8 500
500 http://security.debian.org stretch/updates/main amd64 Packages
 232-25+deb9u6 500
500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages

  Regards,
Vincent


> -- 
> 
> Saludos,
> Felipe Sateler


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

Bug#917527: linux-image-4.18.0-0.bpo.3-amd64: i915 module loading hangs

[Vincent Danjean]

Package: src:linux
Version: 4.18.20-2~bpo9+1
Severity: critical
Justification: breaks the whole system

  Hi,

  After upgrading from bpo.1, my system is unusable
with a black screen. The blackscreen starts at
boot time (way before kdm), when the resolution
usually changes.
  Using another computer, I was able to login remotely.
I can observe that i915 does not load. Trying to load
it with modprobe or even with insmod leads to the
command hanging (C-c is able to stop it).
I looked insmod with strace. The hang occurs in
finit_module.
  I see nothing with dmesg nor in /var/log/syslog

  I workaround the problem by installing the
current kernel (from testing), it 4.19.0-1-amd64

  Regards,
Vincent

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: EG45M-DS2H
product_version: 
chassis_vendor: Gigabyte Technology Co., Ltd.
chassis_version: 
bios_vendor: Award Software International, Inc.
bios_version: F5C N:071209
board_vendor: Gigabyte Technology Co., Ltd.
board_name: EG45M-DS2H
board_version: 

** Network interface configuration:

auto lo
iface lo inet loopback




iface static inet static
address 192.168.1.7
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
dns-search varennes.fr

iface dhcp inet dhcp

iface aure inet dhcp
pre-up ifconfig $IFACE up
pre-up iwlist $IFACE scan
wireless-essid Aure
wireless-key **
wireless-channel 11
wireless-ap F2:AD:66:40:52:E8

iface dino inet dhcp
wireless-mode managed
wireless-essid dino
wireless-key1 **

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 4 Series Chipset DRAM Controller 
[8086:2e20] (rev 03)
Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5/GA-EG45M-DS2H 
Motherboard [1458:5000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series Chipset 
Integrated Graphics Controller [8086:2e22] (rev 03) (prog-if 00 [VGA 
controller])
Subsystem: Gigabyte Technology Co., Ltd GA-EG45M-DS2H Mainboard 
[1458:d000]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:02.1 Display controller [0380]: Intel Corporation 4 Series Chipset 
Integrated Graphics Controller [8086:2e23] (rev 03)
Subsystem: Gigabyte Technology Co., Ltd GA-EG45M-DS2H Mainboard 
[1458:d000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:1a.0 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB 
UHCI Controller #4 [8086:3a37] (prog-if 00 [UHCI])
Subsystem: Gigabyte Technology Co., Ltd Motherboard [1458:5004]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd

00:1a.1 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB 
UHCI Controller #5 [8086:3a38] (prog-if 00 [UHCI])
Subsystem: Gigabyte Technology Co., Ltd Motherboard [1458:5004]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd

00:1a.2 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB 
UHCI Controller #6 [8086:3a39] (prog-if 00 [UHCI])
Subsystem: Gigabyte Technology Co., Ltd Motherboard [1458:5004]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd

00:1a.7 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB2 
EHCI Controller #2 [8086:3a3c] (prog-if 20 [EHCI])
Subsystem: Gigabyte Technology Co., Ltd Motherboard [1458:5006]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:1b.0 Audio device [0403]: Intel Corporation 82801JI (ICH10 Family) HD Audio 
Controller [8086:3a3e]
Subsystem: Gigabyte Technology 

Bug#914332: "SyntaxError: invalid syntax" in postinst

[Vincent Danjean]

Package: pyzo
Version: 4.4.3-1
Severity: serious
Justification: Do not install on up-to-date systems

  With the current version of python3.7, the postinst of pyzo leads to the
following error:
=
$ sudo apt install pyzo
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances   
Lecture des informations d'état... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus 
nécessaires :
[...]
Paquets suggérés :
  pyzo-doc
Les NOUVEAUX paquets suivants seront installés :
  pyzo
0 mis à jour, 1 nouvellement installés, 0 à enlever et 2 non mis à jour.
Il est nécessaire de prendre 802 ko dans les archives.
Après cette opération, 3 364 ko d'espace disque supplémentaires seront utilisés.
Réception de:1 http://ftp.fr.debian.org/debian testing/main amd64 pyzo all 
4.4.3-1 [802 kB]
802 ko réceptionnés en 0s (4 201 ko/s)
Récupération des rapports de bogue… Fait
Analyse des informations Trouvé/Corrigé… Fait
/usr/share/apt-listchanges/apt_listchanges.py:540: FutureWarning: Possible 
nested set at position 25
  email_re = 
re.compile(r'([a-zA-Z0-9_\+\-\.]+)@(([[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)')
Sélection du paquet pyzo précédemment désélectionné.
(Lecture de la base de données... 869774 fichiers et répertoires déjà 
installés.)
Préparation du dépaquetage de .../archives/pyzo_4.4.3-1_all.deb ...
Dépaquetage de pyzo (4.4.3-1) ...
Traitement des actions différées (« triggers ») pour mime-support (3.61) ...
Traitement des actions différées (« triggers ») pour desktop-file-utils 
(0.23-4) ...
Paramétrage de pyzo (4.4.3-1) ...
  File "/usr/share/pyzo/pyzo/yoton/clientserver.py", line 81
def __init__(self, address, async=False, verbose=0):
^
SyntaxError: invalid syntax

dpkg: erreur de traitement du paquet pyzo (--configure) :
 installed pyzo package post-installation script subprocess returned error exit 
status 1
Traitement des actions différées (« triggers ») pour man-db (2.8.4-3) ...
Traitement des actions différées (« triggers ») pour gnome-menus (3.13.3-11) ...
Traitement des actions différées (« triggers ») pour hicolor-icon-theme 
(0.17-2) ...
Des erreurs ont été rencontrées pendant l'exécution :
 pyzo
=


  The error is linked to the new version of python3.7. Indeed, pyzo was
correctly installed on my machine. But, today, on upgrade, I got:
=
$ sudo apt full-upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances   
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus 
nécessaires :
[...]
Les paquets suivants ont été conservés :
  libsane-common
0 mis à jour, 0 nouvellement installés, 0 à enlever et 1 non mis à jour.
8 partiellement installés ou enlevés.
Après cette opération, 0 o d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] 
/usr/share/apt-listchanges/apt_listchanges.py:540: FutureWarning: Possible 
nested set at position 25
  email_re = 
re.compile(r'([a-zA-Z0-9_\+\-\.]+)@(([[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)')
Paramétrage de python3 (3.7.1-2) ...
running python rtupdate hooks for python3.7...
  File "/usr/share/pyzo/pyzo/yoton/clientserver.py", line 81
def __init__(self, address, async=False, verbose=0):
^
SyntaxError: invalid syntax

error running python rtupdate hook pyzo
dpkg: erreur de traitement du paquet python3 (--configure) :
 installed python3 package post-installation script subprocess returned error 
exit status 4
dpkg: des problèmes de dépendances empêchent la configuration de 
python3-all-dev :
 python3-all-dev dépend de python3 (= 3.7.1-2) ; cependant :
 Le paquet python3 n'est pas encore configuré.
[...]
Des erreurs ont été rencontrées pendant l'exécution :
 python3
 python3-all-dev
 python3-dev
 python3-all-dbg
 python3-all
 python3-dbg
 gnome-menus
 libboost-python1.67-dev
 libboost-python-dev
E: Sub-process /usr/bin/dpkg returned an error code (1)
=

  I workaround the upgrade problem by removing pyzo to complete the upgrade.
But, when installing pyzo again, I got the error reported at the top of this
message.

  Regards,
Vincent

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 4.19.0-rc7-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pyzo 

Bug#874882: [freeplayer] Future Qt4 removal from Buster

[Vincent Danjean]

On 21/10/2018 20:19, Moritz Mühlenhoff wrote:
> On Sun, Sep 10, 2017 at 01:43:08PM +0200, Vincent Danjean wrote:
>> severity 874882 grave
>> tag 874882 +help
>> thanks
>>
>>   Hi,
>>
>>   Unless someone step up to maintain (debian and upstream) this
>> program, I will ask for its removal. Upstream is long dead. I
>> kept this program in Debian while the work to maintain it was
>> minimal, I do not indent to do lots of work for this program.
>>   If someone is interested in taking care of it, just tell me.
>> I can sponsor the package is required.
> 
> Given noone has adopted it for over a year, let's remove?

ok for me.

  Regards,
Vincent

> 
> Cheers,
> Moritz
> 


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




signature.asc
Description: OpenPGP digital signature

Bug#902256: Bug#909285: [freshplayerplugin] update to the latest version

[Vincent Danjean]

es/freshwrapper-obj.dir/ppb_video_decoder.c.o] Error 1
make[3] : on quitte le répertoire « 
/home/vdanjean/debian/mainteneur/freshplayerplugin/build-area/freshplayerplugin-0.3.9/build
 »
make[2]: *** [CMakeFiles/Makefile2:330: 
src/CMakeFiles/freshwrapper-obj.dir/all] Error 2
make[2] : on quitte le répertoire « 
/home/vdanjean/debian/mainteneur/freshplayerplugin/build-area/freshplayerplugin-0.3.9/build
 »
make[1]: *** [Makefile:133: all] Error 2
make[1] : on quitte le répertoire « 
/home/vdanjean/debian/mainteneur/freshplayerplugin/build-area/freshplayerplugin-0.3.9/build
 »
dh_auto_build: cd build && make -j1 returned exit code 2
make: *** [debian/rules:23: build] Error 2
dpkg-buildpackage: erreur: debian/rules build subprocess returned exit status 2


  So, I will need to dig into it. But if you have free time, any help is 
welcome.
The current state is available here:
https://salsa.debian.org/debian/freshplayerplugin

  Regards,
Vincent

PS: I'm closing #909285. Use #902256 to make progress on this bug.


> --- System information. ---
> Architecture: 
> Kernel:   Linux 4.17.17-bootes0-iommu-p-1000
> 
> Debian Release: 9.5
>   990 stretch-backports ftp.debian.org 
>   990 stable  security.debian.org 
>   990 stable  ftp.fi.debian.org 
>   500 stable  dl.google.com 
>   500 stable  deb.torproject.org 
>   500 newstable   deb.i2p2.no 
>   101 stable-backports www.deb-multimedia.org 
>   101 stable  www.deb-multimedia.org 
>   100 testing ftp.fi.debian.org 
> 
> --- Package information. ---
> Package's Depends field is empty.
> 
> Package's Recommends field is empty.
> 
> Package's Suggests field is empty.
> 


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

Bug#907494: hgsvn: package is missing most of its files

[Vincent Danjean]

  Hi,

Le 28/08/2018 à 18:51, Nick Smallbone a écrit :
> Package: hgsvn
> Version: 0.1.8-1.1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> After installing hgsvn, I tried to run hgimportsvn but was greeted
> with:
> 
> % hgimportsvn
> zsh: command not found: hgimportsvn
> 
> A closer look reveals that the package does not actually install
> hgsvn. For some reason, it only includes the manpages and
> documentation. Here is the output of dpkg -L hgsvn - notice the empty
> /usr/bin directory:

Whaou! The package is in this state since several years
(as this is the version currently in stretch), since 2015-08-22
exactly (upload of the NMU version). And this is the first
bug report.

  I do not use it anymore and, as the upstream website changed,
I just see I'm several version late.


  I will try to update/redo this package. Any help is welcome.

  Regards,
Vincent

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

Bug#876692: owfs FTBFS with debhelper 10.9

[Vincent Danjean]

Le 02/10/2017 à 10:56, Michael Stapelberg a écrit :
> Thanks for taking care of it. I’ll let you handle it :)

  Uploaded. The changelog is longer than the fix ;-)

  Regards,
Vincent

> On Mon, Oct 2, 2017 at 1:35 AM, Vincent Danjean <vdanj...@debian.org> wrote:
>> Le 02/10/2017 à 09:49, Michael Stapelberg a écrit :
>>> Hi Vincent,
>>>
>> [...]
>>> Are you working on a fix for this or would you like help with it?
>>
>>   I forgot this bug. The testing autoremoval I received this morning
>> makes me remember it. It should not be difficult to patch. I plan
>> to fix it soon (probably this evening if I do not have too much
>> work) but if you want to prepare a patch for this bug, it will be
>> welcome.
>>   I will do a quick fix and upload for this bug (and perhaps another
>> upload later if there are other bugs or a new upstream version)
>>
>>   Regards,
>> Vincent
>>
>>> Asking because freeradius is marked for removal from testing due to this
>>> bug.
>>>
>>> Thanks!
>>>
>>
>>
>> --
>> Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
>> GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
>> Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
>> APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main
>>
> 
> 
> 

Bug#876692: owfs FTBFS with debhelper 10.9

[Vincent Danjean]

Le 02/10/2017 à 09:49, Michael Stapelberg a écrit :
> Hi Vincent,
> 
[...]
> Are you working on a fix for this or would you like help with it?

  I forgot this bug. The testing autoremoval I received this morning
makes me remember it. It should not be difficult to patch. I plan
to fix it soon (probably this evening if I do not have too much
work) but if you want to prepare a patch for this bug, it will be
welcome.
  I will do a quick fix and upload for this bug (and perhaps another
upload later if there are other bugs or a new upstream version)

  Regards,
Vincent

> Asking because freeradius is marked for removal from testing due to this
> bug.
> 
> Thanks!
> 


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

Bug#869214: Acknowledgement (gosa-plugin-mailaddress: Incompatible with gosa in stable)

[Vincent Danjean]

  Hi,

  The same change is also required in 
admin/groups/mailaddress/class_groupMail.inc

  I opened a pull request upstream:
https://github.com/gosa-project/gosa-plugin-mailaddress/pull/1

  Regards,
Vincent

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

Bug#869214: gosa-plugin-mailaddress: Incompatible with gosa in stable

[Vincent Danjean]

Package: gosa-plugin-mailaddress
Version: 0.99.5-2
Severity: serious
Tags: patch
Justification: do not work and forbid global gosa use if installed

  I just upgraded a system to stretch with gosa and this plugin installed.
Trying to add a new user fails with the following error:

Fatal error: Call to undefined method plugin::plugin() in
/usr/share/gosa/plugins/personal/mailaddress/class_mailAccount.inc on
line 65

  It seems that changing
plugin::plugin ($config,$dn);
into
plugin::__construct ($config,$dn);
in /usr/share/gosa/plugins/personal/mailaddress/class_mailAccount.inc on
line 65 fixes the problem.

  This small change should probably be pushed into the next stable update
point.

  Note that I did not look if other change are required.

  Regards,
   Vincent

-- System Information:
Debian Release: buster/sid
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'unstable'), (500, 'testing'), 
(200, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gosa-plugin-mailaddress depends on:
pn  gosa  

gosa-plugin-mailaddress recommends no packages.

gosa-plugin-mailaddress suggests no packages.

Bug#866108: texlive-science-doc: Missing Replaces: on texlive-latex-extra-doc

[Vincent Danjean]

Package: texlive-science-doc
Version: 2016.20170123-5
Severity: serious
Justification: Breaks upgrades

  Hi,

  The texlive-science-doc is missing a Replaces: texlive-latex-extra-doc
(perhaps versionned) as /usr/share/doc/texlive-doc/latex/textgreek/README
was in the previous texlive-latex-extra-doc and also in the current
texlive-science-doc.

  Here is an extract from a plain "apt upgrade" (in French, sorry):
(Lecture de la base de données... 616290 fichiers et répertoires déjà 
installés.)
Suppression de texlive-latex-extra (2016.20170123-5) ...
dpkg: tentative de déconfiguration de texlive-latex-extra-doc, qui serait cassé 
par l'installation de texlive-science-doc...
dpkg: oui, déconfiguration de texlive-latex-extra-doc (cassé par 
texlive-science-doc).
(Lecture de la base de données... 611509 fichiers et répertoires déjà 
installés.)
Préparation du dépaquetage de .../texlive-science-doc_2017.20170623-1_all.deb 
...
Déconfiguration de texlive-latex-extra-doc (2016.20170123-5) ...
Dépaquetage de texlive-science-doc (2017.20170623-1) sur (2016.20170123-5) ...
dpkg: erreur de traitement de l'archive 
/var/cache/apt/archives/texlive-science-doc_2017.20170623-1_all.deb (--unpack) :
 tentative de remplacement de « 
/usr/share/doc/texlive-doc/latex/textgreek/README », qui appartient aussi au 
paquet texlive-latex-extra-doc 2016.20170123-5
dpkg-deb: erreur: le sous-processus coller a été tué par le signal (Relais 
brisé (pipe))
dpkg: tentative de déconfiguration de texlive-science-doc, qui serait cassé par 
l'installation de texlive-latex-extra-doc...
dpkg: oui, déconfiguration de texlive-science-doc (cassé par 
texlive-latex-extra-doc).
Préparation du dépaquetage de 
.../texlive-latex-extra-doc_2017.20170623-1_all.deb ...
Déconfiguration de texlive-science-doc (2016.20170123-5) ...
Dépaquetage de texlive-latex-extra-doc (2017.20170623-1) sur (2016.20170123-5) 
...
Des erreurs ont été rencontrées pendant l'exécution :
 /var/cache/apt/archives/texlive-science-doc_2017.20170623-1_all.deb

  Regards,
Vincent



-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 vdanjean vdanjean 44796 Mar 10 21:25 /home/vdanjean/texmf/ls-R
-rw-r--r-- 1 root root 1663 Jun  9 09:28 /var/lib/texmf/ls-R
-rw-rw-r-- 1 root staff 80 Aug 28  2012 /usr/local/share/texmf/ls-R
lrwxrwxrwx 1 root root 29 Jan 17 03:45 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Mar  4 07:53 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Mar  4 07:53 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 838 Jan 18 13:57 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Mar  4 07:53 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Mar  4 07:53 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 2864 Apr  3 16:39 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jun 26  2011 mktex.cnf
-rw-r--r-- 1 root root 838 Jan 18 13:57 texmf.cnf
##
 md5sums of 

Bug#864188: [Debian-med-packaging] Bug#864188: libbpp-core2v5: symbols removed without soname bump

[Vincent Danjean]

Le 06/06/2017 à 12:47, Julien Yann Dutheil a écrit :
> Dear Adrian,
> 
> These functions are now inline in the corresponding .h files, but their
> interfaces have not changed as far as I know. Does making a function
> inline break the interface??

  It is the difference between the API and the ABI. The API
(interface for the programmer) did not change. But the ABI
(binary interface) changed.
  Both (API and ABI) are related but not tightly coupled.

  The API has a backward incompatibility when sources that
compiled with the previous API do not compile any more with
the new API (this is not the case here).
  The ABI has a backward incompatibility when a program/lib
compiled against an old library will not work with the new
library. This is the case here: a (previously compiled) program
can try to use symbols that are not present anymore in the
new library. Recompiling the program would workaround the
problem (as the API did not change and the new compiled program
will not try to use the symbols anymore) but the correct fix is
to bump the soname so that the user knows without looking for
bugs if the program and the library are compatible.

  Regards,
Vincent

> J.
> 
> -- Forwarded message --
> From: *Adrian Bunk* >
> Date: Tue, Jun 6, 2017 at 11:48 AM
> Subject: Re: Bug#864188: libbpp-core2v5: symbols removed without soname bump
> To: Julien Yann Dutheil  >
> Cc: Andreas Tille >, 
> 864...@bugs.debian.org , GINDRAUD FRANCOIS 
> >
> 
> 
> On Tue, Jun 06, 2017 at 11:35:57AM +0200, Julien Yann Dutheil wrote:
>> Dear Andreas, Adrian,
>>...
>> - This error actually revealed an interface breakdown (essentially due to
>> our upgrade to c++11), and your suggestion is to reflect this change by
>> increasing the interface number (which would result in a change in package
>> name, such as libbpp-core2 -> libbpp-core3), am I correct?
> 
> This ABI breakage is unrelated to the C++ version used.
> 
> RandomTools::lnGamma() was removed from src/Bpp/Numeric/Random/RandomTools.cpp
> TextTools::startsWith() was removed from src/Bpp/Text/TextTools.cpp
> ApplicationTools::parameterExists() was removed from 
> src/Bpp/App/ApplicationTools.cpp
> ...
> 
> Removing any such function breaks the ABI in an incompatible way,
> and therefore requires a soname bump.
> 
>> Best,
>>
>> Julien.
> 
> cu
> Adrian
> 
>> On Mon, Jun 5, 2017 at 9:50 AM, Andreas Tille > > wrote:
>>
>> > Hi Julien,
>> >
>> > while I made a mistake to upload libbpp-core to unstable rather than
>> > experimental as it was planed this has probably lead to spot a bug
>> > earlier.  The problem is that the soversion needs to be bumped due to
>> > the ABI change.
>> >
>> >$ objdump -p ./libbpp-core.so.2.0.4   | sed -n 's/^.*SONAME *//p'
>> >libbpp-core.so.2
>> >
>> > I think you should bump the SOVERSION to reflect that change.
>> >
>> > Kind regards
>> >
>> >  Andreas.
>> >
>> > On Mon, Jun 05, 2017 at 02:42:58AM +0300, Adrian Bunk wrote:
>> > > Package: libbpp-core2v5
>> > > Version: 2.3.0-1~exp1
>> > > Severity: serious
>> > > Control: affects -1 libbpp-seq9v5 src:libbpp-phyl
>> > >
>> > > 2.3.0-1~exp1 in unstable (sic) removes symbols without changing soname,
>> > > causing the following FTBFS in libbpp-phyl:
>> > >
>> > > https://tests.reproducible-builds.org/debian/rb-pkg/ 
>> > > 
>> > unstable/amd64/libbpp-phyl.html
>> > >
>> > > ...
>> > > [ 93%] Linking CXX executable test_bowker
>> > > cd /build/1st/libbpp-phyl-2.2.0/obj-x86_64-linux-gnu/test &&
>> > /usr/bin/cmake -E cmake_link_script CMakeFiles/test_bowker.dir/link.txt
>> > --verbose=1
>> > > /usr/bin/c++   -Wall -Wshadow -Weffc++ -Wconversion  -Wl,-z,relro
>> > CMakeFiles/test_bowker.dir/test_bowker.cpp.o  -o test_bowker -rdynamic
>> > -lbpp-seq -lbpp-core -L../src -lbpp-phyl
>> > > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libbpp-seq.so:
>> > undefined reference to `bpp::RandomTools::lnGamma(double)'
>> > > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libbpp-seq.so:
>> > undefined reference to `bpp::TextTools::startsWith(
>> > std::__cxx11::basic_string> > std::allocator > const&, std::__cxx11::basic_string> > std::char_traits, std::allocator > const&)'
>> > > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libbpp-seq.so:
>> > undefined reference to `bpp::ApplicationTools::
>> > parameterExists(std::__cxx11::basic_string> > std::allocator > const&, std::map> > std::char_traits, std::allocator >, 
>> > std::__cxx11::basic_string> > std::char_traits, std::allocator >,
>> > 

Bug#734365: fixed in freeplayer 20070531+dfsg.1-4

[Vincent Danjean]

Le 12/05/2017 à 21:36, Adrian Bunk a écrit :
> On Tue, Oct 11, 2016 at 12:09:12AM +0200, Vincent Danjean wrote:
>> Le 10/10/2016 à 23:32, Antoine Musso a écrit :
>>> The bug still happens in Jessie which is stuck to 20070531+dfsg.1-3
>>>
>>>   * Fix vlc invocation (remove the "--http-charset=ISO-8859-1" option)
>>> (Closes: #734365)
>>>
>>> Is there a way to pick that patch and release an update for Jessie?
>>
>> The patch is very small. You can try it by editing (as root) the
>> /usr/bin/vlc-fbx script and remove the --http-charset=ISO-8859-1
>> options to the vlc invocation. Please, check this works (I do not
>> use freeplayer at all myself).
>>   Perhaps, a backport of the testing version would be better (other
>> vlc options are fixed)
> 
> It seems this is the only option difference between jessie and stretch,

For the contents, yes. But there are (small) differences in the
packaging (cleanup rules file and dependencies, rewrite of the
copyright file, ...)

> and the package in jessie is completely broken.
> 
> Could you make an update for jessie fixing it also there?
> Alternatively, I could fix it for jessie.

I just pushed my work at ssh://git.debian.org/git/collab-maint/freeplayer.git
I would be very pleased if you can handle yourself the fix
in jessie with the release team. And if you want to takeover
the package, feel free to do it (as I said, I do not use it
myself and upstream seems dead)

  Regards,
Vincent

>>   Regards,
>> Vincent
> 
> Thanks
> Adrian
> 


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

Bug#860011: xspim

[Vincent Danjean]

severity 860011 important
thanks

  Hi,

  Given that:
- this program has the same version has jessie (just a binary rebuild)
- the non-gui part seems working fine
- the gui part seems to have an easy workaround (xspim -font 6x10)
I do not think the reported bug must be release critical.

  Letting the bug RC would just mean that no spim at all would be
present in stretch (it is really late wrt the release and there is
no patch proposed), and not that a new patched package would magically
appear.
  Just looking at the bug (I do not use spim myself), the GUI has
clearly a bug. But the core of the software works with a CLI
program and the GUI bug seems to have an easy workaround. So I was
hesitating between a normal or important severity for this bug.
  Do not hesitate to propose a patch to the maintainer (or to help
him to package the new version for after stretch) if you want some
progress on this bug.

  Regards,
Vincent

Le 18/04/2017 à 19:58, Tim Retout a écrit :
> severity 860011 serious
> thanks
> 
> I can confirm the broken GUI.
> 
> I had to run "xspim -font 6x10" to get it to launch, as per a comment
> at the end of this Ubuntu issue, a different issue to #670949:
> https://bugs.launchpad.net/ubuntu/+source/spim/+bug/824084
> 
> Marking as 'serious' because at least the CLI program still works...
> 


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

Bug#859805: postfix-ldap: unsupported dictionary type: ldap after upgrade

[Vincent Danjean]

Package: postfix-ldap
Version: 3.1.4-4
Severity: grave
Justification: renders package unusable

  Hi,

  I just upgraded one of my system from jessie to strech. This system was using
postfix with ldap lookup table.
>From /var/log/dpkg.log, postfix-ldap has been upgraded from 2.11.3-1 to
3.1.4-4 on 2017-04-06

  I just discovered that, after the upgrade, ldap was not working anymore. I
got in my log lots of such messages:
Apr  7 16:22:01 chaman postfix/pickup[25203]: 9711A1FD73: uid=104 
from=
Apr  7 16:22:01 chaman postfix/cleanup[32362]: warning: 
ldap:/etc/postfix/ldap-canonical.cf is unavailable. unsupported dictionary 
type: ldap
Apr  7 16:22:01 chaman postfix/cleanup[32362]: warning: 
ldap:/etc/postfix/ldap-canonical.cf lookup error for "XXX@YYY"
Apr  7 16:22:01 chaman postfix/cleanup[32362]: warning: 9711A1FD73: 
canonical_maps map lookup problem for XXX@YYY -- message not accepted, try 
again later
Apr  7 16:22:01 chaman postfix/pickup[25203]: warning: maildrop/3FACF20B26: 
error writing 9711A1FD73: queue file write error

  I manually fixes the problem by executing these commands:
# . /usr/share/postfix/postinst.functions
# delmap ldap
# addmap ldap

Etckeeper show me the differences:
root@chaman:/etc# git diff
diff --git a/postfix/dynamicmaps.cf b/postfix/dynamicmaps.cf
index d953c54..c3bac41 100644
--- a/postfix/dynamicmaps.cf
+++ b/postfix/dynamicmaps.cf
@@ -4,4 +4,4 @@
 #  =   
 tcp/usr/lib/postfix/dict_tcp.sodict_tcp_open   
 sqlite /usr/lib/postfix/dict_sqlite.so dict_sqlite_open
-ldap   /usr/lib/postfix/dict_ldap.so   dict_ldap_open  
+ldap   postfix-ldap.so dict_ldap_open  


=> It seems that the postfix ldap plugin change its library name but the debian
configure script does not fix it. Reinstalling the package (apt-get install 
--reinstall)
or reconfiguring it (dpkg-reconfigure) do not help. As I read 'addmap', the
dynamicmaps.cf file is not modified if 'ldap' is found in the first column
(even if the next informations are now wrong).

  This bug needs to be fixed before the release, else postfix-ldap
would be unusable for any upgraded system.

Side note: it seems that this bug is larger. As shown before,
my dynamicmaps.cf also have two other entries (tcp and sqlite)
refering to non-existant files on my system:
# ls /usr/lib/postfix/
configure-instance.sh  libpostfix-dns.so libpostfix-master.so  
libpostfix-util.so  postfix_groups.pl  postfix-ldap.so.1.0.1  
postfix-sqlite.so.1.0.1
libmilter.alibpostfix-global.so  libpostfix-tls.so libxsasl.a   
   postfix-ldap.sopostfix-sqlite.so  sbin

/usr/lib/postfix/dict_sqlite.so should probably be replaced by postfix-sqlite.so
but I've no clues for /usr/lib/postfix/dict_tcp.so...

  Regards
Vincent


-- System Information:
Debian Release: 9.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(200, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

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

Bug#855930: Bug#853119: Request to take a look at #855930

[Vincent Danjean]

Le 27/02/2017 à 00:45, Norbert Preining a écrit :
>>> So lulaatex seems to really use the HOME directory.
> 
> Yes, of course, because it has to update the font database.
> 
> Complain to the author of the whole setup about extra
> font database in lua format (Hans Hagen of ConTeXt) for
> that requirement, but that is the way it is.
> 
> Lualatex maintains a database of all the otf/ttf fonts
> decomposed into lua code.
> 
> Ah and yes, that has been the case already since ages.

I just checked, it seems that my sbuild did not change the HOME
directory when I uploaded it on 2017-01-08, so I did not see
this issue.

I will ask for a freeze exception.

  Regards,
Vincent

> Best
> 
> Norbert
> 
> --
> PREINING Norbert   http://www.preining.info
> Accelia Inc. +JAIST +TeX Live +Debian Developer
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
> 


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

Bug#855930: Bug#853119: Request to take a look at #855930

[Vincent Danjean]

Le 26/02/2017 à 23:37, Vincent Danjean a écrit :
> I eventually succeeded in reproducing the bug: lualatex needs a
> writable HOME directory. On my plain (sid) system:
> $ cat lualatex-example.tex
> \documentclass{article}
> \usepackage{luacode}
> \begin{document}
> A random number:
> \begin{luacode}
> tex.print(math.random())
> \end{luacode}
> \end{document}
> $ lualatex lualatex-example.tex
> This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian)
> [...]
> Transcript written on lualatex-example.log.
> $ HOME=/non-existatn lualatex lualatex-example.tex
> This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian)
>  restricted system commands enabled.
> (./lualatex-example.tex
> LaTeX2e <2017/01/01> patch level 1
> 
> quiting: fix your writable cache path

And, for more info:
$ mkdir p
$ HOME=p lualatex lualatex-example.tex
This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian)
[...]
luaotfload | db : Font names database not found, generating new one.
luaotfload | db : This can take several minutes; please be patient.(compiling 
luc: /var/li
b/texmf/luatex-cache/generic/fonts/otl/lmroman10-regular.luc)(compiling luc: p/
.texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.luc)(sa
ve: p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.l
ua)(save: p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-reg
ular.luc)))
[...]
$ find p
p
p/.texlive2016
p/.texlive2016/texmf-var
p/.texlive2016/texmf-var/luatex-cache
p/.texlive2016/texmf-var/luatex-cache/generic
p/.texlive2016/texmf-var/luatex-cache/generic/names
p/.texlive2016/texmf-var/luatex-cache/generic/names/luaotfload-lookup-cache.luc
p/.texlive2016/texmf-var/luatex-cache/generic/names/luaotfload-names.lua.gz
p/.texlive2016/texmf-var/luatex-cache/generic/names/luaotfload-names.luc
p/.texlive2016/texmf-var/luatex-cache/generic/names/luaotfload-lookup-cache.lua
p/.texlive2016/texmf-var/luatex-cache/generic/fonts
p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl
p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.luc
p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.lua
$

So lulaatex seems to really use the HOME directory.

  Regards,
Vincent

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

Bug#855930: Bug#853119: Request to take a look at #855930

[Vincent Danjean]

Le 26/02/2017 à 22:37, Lucas Nussbaum a écrit :
> On 26/02/17 at 21:41 +0100, Vincent Danjean wrote:
>> Can you elaborate? I cannot reproduce this failure. It works
>> in my sbuild environment.
> 
> if you have a successful build with sbuild, please provide the build
> log: it's usually useful to just diff the build logs to compare list of
> packages.

Looking at the machine, it seems it was not a sbuild, but a build
in my new testing chroot (created with debootstrap, buildd variant).
  So, I just digged more into it as my sbuild invocation fails indeed.

The installed packages are the same (but sbuild-build-depends-core-dummy
and sbuild-build-depends-latex-make-dummy of course).

I eventually succeeded in reproducing the bug: lualatex needs a
writable HOME directory. On my plain (sid) system:
$ cat lualatex-example.tex
\documentclass{article}
\usepackage{luacode}
\begin{document}
A random number:
\begin{luacode}
tex.print(math.random())
\end{luacode}
\end{document}
$ lualatex lualatex-example.tex
This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian)
[...]
Transcript written on lualatex-example.log.
$ HOME=/non-existatn lualatex lualatex-example.tex
This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian)
 restricted system commands enabled.
(./lualatex-example.tex
LaTeX2e <2017/01/01> patch level 1

quiting: fix your writable cache path


  So Norbert, should I reassign this bug to texlive-luatex (it seems
a regression), so should I provide an (temporary empty) writable HOME
directory during the lualatex invocation?

  Regards,
Vincent

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

Bug#855930: Bug#853119: Request to take a look at #855930

[Vincent Danjean]

Le 26/02/2017 à 15:29, Tomasz Buchert a écrit :
> On 26/02/17 10:25, Norbert Preining wrote:
>> On Sun, 26 Feb 2017, Norbert Preining wrote:
>>> I will try to run it in a clean cowbuilder with only the build-deps
>>> installed and see what might be the reason.
> 
> Thanks for looking into it.
> Let's also move the discussion to #855930 :).

  I forgot to add this info to this bug report:
I installed a testing schroot to try to rebuild it with testing
dependencies with sbuild. And it works...
  I've no idea of the root cause of this. I checked in the
provided log that Lucas uses recent (testing) tex packages.

  Lucas: can you tell us how more on how the build environment
is generated ?

  In any case, I will probably downgrade the severity if
nobody is able to reproduce the problem. If needed, I can ask
the release team to accept a package with this test disabled
(lualatex support is a nice feature but if it does not work
in all environment, it does not warrant a package removal)

>> Just done this, too, worked without a hinch:
>> 'lualatex' '--interaction' 'errorstopmode' '--jobname' 'lualatex-example' 
>> '\RequirePackage[extension=.pdf]{texdepends}\input{lualatex-example.tex}'
>> [...]
> 
> However, if you build w sbuild, this seems to fail.

Can you elaborate? I cannot reproduce this failure. It works
in my sbuild environment.

> Can it be some
> failure in how tex packages are installed? Sbuild may create a very
> minimal environment that exposes this problem.
> 
>> One idea: is /var writable???
> 
> I'm afraid I don't understand this. Can you elaborate?
> 
>> Norbert
> 
> Thanks,
> Tomasz

  Regards,
Vincent

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

Bug#854719: [pkg-wpa-devel] Bug#854719: Bug#854719: hostapd: Failed to set beacon parameters

[Vincent Danjean]

  Hi,

Le 10/02/2017 à 00:21, Andrew Shadura a écrit :
> On 10/02/17 00:05, Vincent Danjean wrote:
>> I'm not using wpa_supplicant, so it does not seem the same bug.
>> Moreover, the proposed patch in
>> http://lists.infradead.org/pipermail/hostap/2017-January/037060.html
>> do not apply at all for the testing sources.
>> In the testing sources, in the wpa_driver_nl80211_set_ap function,
>> the "if (beacon_set)" test do not have any "else" clause to patch.
> 
> That doesn't sound good. Maybe try emailing the hostap mailing list?

I use git-bissect to find what makes hostapd 2.6 working on my hardware.
I found the ee298f1b1f7efd7eb5fd510f36b25ff88208017c. It fixes some
code just before the error in the provided log. So, I tried to
apply the following patch to the testing debian package (ie the
upstream commit + a change in build-dependency to use openssl 1.0)
and it seems to work.

  Regards
Vincent

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

diff --git a/debian/changelog b/debian/changelog
index 704f538..45f48d3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+wpa (2.5-2+v2.4-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Test with a patch backported from upstream
+
+ -- Vincent Danjean <vdanj...@debian.org>  Fri, 10 Feb 2017 10:21:51 +0100
+
 wpa (2.5-2+v2.4-3) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff --git a/debian/control b/debian/control
index c9a4aa0..beae8ee 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Section: net
 Priority: optional
 Build-Depends: debhelper (>> 9.20120115),
  libdbus-1-dev,
- libssl-dev,
+ libssl1.0-dev,
  libqt4-dev,
  libncurses5-dev,
  libpcsclite-dev,
diff --git a/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch 
b/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch
new file mode 100644
index 000..5a6408a
--- /dev/null
+++ b/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch
@@ -0,0 +1,54 @@
+nl80211: Do not add NL80211_ATTR_SMPS_MODE attribute if HT is disabled
+
+SMPS mode is applicable only for HT and including an attribute to
+configure it when HT is disabled could result in the AP start operation
+failing. Fix this by adding the attribute only in cases where HT is
+enabled.
+
+Upstream commit ee298f1b1f7efd7eb5fd510f36b25ff88208017c
+--- a/src/drivers/driver_nl80211.c
 b/src/drivers/driver_nl80211.c
+@@ -3419,24 +3419,26 @@
+   nla_put_u32(msg, NL80211_ATTR_CIPHER_SUITE_GROUP, suite))
+   goto fail;
+ 
+-  switch (params->smps_mode) {
+-  case HT_CAP_INFO_SMPS_DYNAMIC:
+-  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - dynamic");
+-  smps_mode = NL80211_SMPS_DYNAMIC;
+-  break;
+-  case HT_CAP_INFO_SMPS_STATIC:
+-  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - static");
+-  smps_mode = NL80211_SMPS_STATIC;
+-  break;
+-  default:
+-  /* invalid - fallback to smps off */
+-  case HT_CAP_INFO_SMPS_DISABLED:
+-  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - off");
+-  smps_mode = NL80211_SMPS_OFF;
+-  break;
++  if (params->ht_opmode != -1) {
++  switch (params->smps_mode) {
++  case HT_CAP_INFO_SMPS_DYNAMIC:
++  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - dynamic");
++  smps_mode = NL80211_SMPS_DYNAMIC;
++  break;
++  case HT_CAP_INFO_SMPS_STATIC:
++  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - static");
++  smps_mode = NL80211_SMPS_STATIC;
++  break;
++  default:
++  /* invalid - fallback to smps off */
++  case HT_CAP_INFO_SMPS_DISABLED:
++  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - off");
++  smps_mode = NL80211_SMPS_OFF;
++  break;
++  }
++  if (nla_put_u32(msg, NL80211_ATTR_SMPS_MODE, smps_mode))
++  goto fail;
+   }
+-  if (nla_put_u32(msg, NL80211_ATTR_SMPS_MODE, smps_mode))
+-  goto fail;
+ 
+   if (params->beacon_ies) {
+   wpa_hexdump_buf(MSG_DEBUG, "nl80211: beacon_ies",
diff --git a/debian/patches/series b/debian/patches/series
index c64ac14..35abe22 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -31,3 +31,4 @@ 
nl80211_dont_call_linux_iface_up_for_a_dedicated_p2p_device.patch
 do_not_wait_for_monitor_to_attach_if_no_control_interface.patch
 wpa_supplicant_do_not_wait_for_monitor_on_p2p_device_interface.patch
 openssl-initialise-pkcs-11.patch
+from-upstream-hostapd-fix-SMPS-mode.patch

Bug#854719: [pkg-wpa-devel] Bug#854719: hostapd: Failed to set beacon parameters

[Vincent Danjean]

Le 09/02/2017 à 23:20, Andrew Shadura a écrit :
> Hi,
> 
> On 9 February 2017 at 21:10, Vincent Danjean <vdanj...@debian.org> wrote:
>> Package: hostapd
>> Version: 1:2.5-2+v2.4-3+b1
>> Severity: grave
>> Justification: renders package unusable
>>
>>   Hi,
>>
>>   I just upgraded a machine from jessie to stretch. With the stretch
>> version of hostapd, the deamon does not start:
>> # hostapd /etc/hostapd/hostapd.conf
>> Configuration file: /etc/hostapd/hostapd.conf
>> Using interface wlan0 with hwaddr f4:ec:38:c5:fd:94 and ssid "dino-wpa1"
>> Failed to set beacon parameters
>> Interface initialization failed
>> wlan0: interface state UNINITIALIZED->DISABLED
>> wlan0: AP-DISABLED
>> wlan0: Unable to setup interface.
>> wlan0: interface state DISABLED->DISABLED
>> wlan0: AP-DISABLED
>> hostapd_free_hapd_data: Interface wlan0_2 wasn't started
>> wlan0: AP-DISABLED
>> hostapd_free_hapd_data: Interface wlan0_1 wasn't started
>> wlan0: AP-DISABLED
>> hostapd_free_hapd_data: Interface wlan0 wasn't started
>> nl80211: deinit ifname=wlan0 disabled_11b_rates=0
>> #
>>
>>   If I downgrade the hostapd package to the jessie version
>> (1:2.3-1+deb8u4), then it works perfectly:
>> # apt-get install --reinstall hostapd/jessie
>> [...]
>> Les paquets suivants seront mis à une VERSION INFÉRIEURE :
>>   hostapd
>> 0 mis à jour, 0 nouvellement installés, 1 remis à une version inférieure, 0 
>> à enlever et 44 non mis à jour.
>> [...]
>> Préparation du dépaquetage de .../hostapd_1%3a2.3-1+deb8u4_amd64.deb ...
>> Dépaquetage de hostapd (1:2.3-1+deb8u4) sur (1:2.5-2+v2.4-3+b1) ...
>> Paramétrage de hostapd (1:2.3-1+deb8u4) ...
>> [...]
>> #  hostapd /etc/hostapd/hostapd.conf
>> Configuration file: /etc/hostapd/hostapd.conf
>> Using interface wlan0 with hwaddr f4:ec:38:c5:fd:94 and ssid "dino-wpa1"
>> Using interface wlan0_1 with hwaddr f4:ec:38:c5:fd:95 and ssid "dino"
>> Using interface wlan0_2 with hwaddr f4:ec:38:c5:fd:96 and ssid
>> "dino-guess"
>> wlan0: interface state UNINITIALIZED->ENABLED
>> wlan0: AP-ENABLED
>> [.. and then authentifications from client...]
>>
>>   So, it seems there is a major regression in the hostapd package.
>> Feel free to ask more information if required.
> 
> I'm going to ask you to tell me what hardware you use.

>From lspci:
04:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter 
(PCI-Express) (rev 01)
If you need more information, just tell me where to look at.

> Also, please try
> and get more logs please, especially those wpa_supplicant produces with
> -dt (you can add it with a systemd override file).

I do not use wpa_supplicant. I only run hostapd. I use this computer
(and this wireless card) as an AP at home.
You can find in attachment the output of
# hostapd -dd /etc/hostapd/hostapd.conf
- for the testing version
- for the stable version
- for the unstable version

>>   Note that the unstable version works. So I will mark this bug as fixed
>> for the 1:2.6-3 version as soon as I get its number
> 
> That's pretty much a bad news, as 2.6 breaks networking for lot more
> people, it seems.
> 
> There's a thread about a related issue:
> http://lists.infradead.org/pipermail/hostap/2017-January/037042.html
> 
> Please have a look and let me know whether what you're observing is the
> same bug or not, and whether the patch works.

I'm not using wpa_supplicant, so it does not seem the same bug.
Moreover, the proposed patch in
http://lists.infradead.org/pipermail/hostap/2017-January/037060.html
do not apply at all for the testing sources.
In the testing sources, in the wpa_driver_nl80211_set_ap function,
the "if (beacon_set)" test do not have any "else" clause to patch.

  Regards,
Vincent

> 
> Thanks!
> 


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

random: Trying to read entropy from /dev/random
Configuration file: /etc/hostapd/hostapd.conf
ctrl_interface_group=0
rfkill: initial event: idx=0 type=1 op=0 soft=0 hard=0
rfkill: initial event: idx=1 type=2 op=0 soft=0 hard=0
nl80211: TDLS supported
nl80211: TDLS external setup
nl80211: Supported cipher 00-0f-ac:1
nl80211: Supported cipher 00-0f-ac:5
nl80211: Supported cipher 00-0f-ac:2
nl80211: Supported cipher 00-0f-ac:4
nl80211: Supported cipher 00-0f-ac:10
nl80211: Supported cipher 00-0f-ac:8
nl80211: Supported ciph

Bug#854719: hostapd: Failed to set beacon parameters

[Vincent Danjean]

Package: hostapd
Version: 1:2.5-2+v2.4-3+b1
Severity: grave
Justification: renders package unusable

  Hi,

  I just upgraded a machine from jessie to stretch. With the stretch
version of hostapd, the deamon does not start:
# hostapd /etc/hostapd/hostapd.conf
Configuration file: /etc/hostapd/hostapd.conf
Using interface wlan0 with hwaddr f4:ec:38:c5:fd:94 and ssid "dino-wpa1"
Failed to set beacon parameters
Interface initialization failed
wlan0: interface state UNINITIALIZED->DISABLED
wlan0: AP-DISABLED 
wlan0: Unable to setup interface.
wlan0: interface state DISABLED->DISABLED
wlan0: AP-DISABLED 
hostapd_free_hapd_data: Interface wlan0_2 wasn't started
wlan0: AP-DISABLED 
hostapd_free_hapd_data: Interface wlan0_1 wasn't started
wlan0: AP-DISABLED 
hostapd_free_hapd_data: Interface wlan0 wasn't started
nl80211: deinit ifname=wlan0 disabled_11b_rates=0
#

  If I downgrade the hostapd package to the jessie version
(1:2.3-1+deb8u4), then it works perfectly:
# apt-get install --reinstall hostapd/jessie
[...]
Les paquets suivants seront mis à une VERSION INFÉRIEURE :
  hostapd
0 mis à jour, 0 nouvellement installés, 1 remis à une version inférieure, 0 à 
enlever et 44 non mis à jour.
[...]
Préparation du dépaquetage de .../hostapd_1%3a2.3-1+deb8u4_amd64.deb ...
Dépaquetage de hostapd (1:2.3-1+deb8u4) sur (1:2.5-2+v2.4-3+b1) ...
Paramétrage de hostapd (1:2.3-1+deb8u4) ...
[...]
#  hostapd /etc/hostapd/hostapd.conf
Configuration file: /etc/hostapd/hostapd.conf
Using interface wlan0 with hwaddr f4:ec:38:c5:fd:94 and ssid "dino-wpa1"
Using interface wlan0_1 with hwaddr f4:ec:38:c5:fd:95 and ssid "dino"
Using interface wlan0_2 with hwaddr f4:ec:38:c5:fd:96 and ssid
"dino-guess"
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED 
[.. and then authentifications from client...]

  So, it seems there is a major regression in the hostapd package.
Feel free to ask more information if required.

  Note that the unstable version works. So I will mark this bug as fixed
for the 1:2.6-3 version as soon as I get its number

  Regards
Vincent

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (200, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages hostapd depends on:
ii  libc6  2.24-9
ii  libnl-3-2003.2.27-1
ii  libnl-genl-3-200   3.2.27-1
ii  libnl-route-3-200  3.2.27-1
ii  libssl1.0.01.0.2k-1~bpo8+1
ii  lsb-base   9.20161125

hostapd recommends no packages.

hostapd suggests no packages.

-- no debconf information

Bug#852914: closing 852914

[Vincent Danjean]

close 852914 2.2.3-1
thanks

The real bug was in texlive (see #853119)

Bug#853119: texlive-luatex: basic lualatex document does not compile anymore without additionnal dependencies

[Vincent Danjean]

Package: texlive-luatex
Version: 2016.20170123-1
Severity: serious
Justification: makes other packages FTBFS

  With the last uploaded version in sid (ie 2016.20170123-1), a very
simple lualatex file cannot be compiled anymore with only
texlive-luatex and texlive-latex-base (and their dependencies)
anymore. There are no problems with the testing version (ie
2016.20161130-1)

Minimal example:
=
\documentclass{article}
\begin{document}
aze
\end{document}
=

Compilation with texlive-luatex and texlive-latex-base from sid:
=
$ lualatex -recorder toto.tex 
This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian) 
 restricted system commands enabled.
(./toto.tex
LaTeX2e <2017/01/01>
(using cache: /var/lib/texmf/luatex-cache/generic)
luaotfload | main : initialization completed in 0.179 seconds
Babel <3.9r> and hyphenation patterns for 1 language(s) loaded.
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
! Font \TU/lmr/m/n/10=[lmroman10-regular]:mapping=tex-text; at 10pt not loadabl
e: metric data not found or bad.
 
relax 
l.54 \normalsize
  
? x
 257 words of node memory still in use:
   1 dir, 2 glue, 34 glue_spec, 2 if_stack nodes
   avail lists: 2:10,3:1,4:1,7:1

warning  (pdf backend): no pages of output.
Transcript written on toto.log.
=

Corresponding fls file:
=
PWD /home/vdanjean/build/luatex
INPUT /var/lib/texmf/web2c/luatex/lualatex.fmt
INPUT ./toto.tex
OUTPUT toto.log
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-basic.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-basic-merged.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-compat.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-extended.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-extended-merged.lua
OUTPUT /var/lib/texmf/m_t_x_t_e_s_t.tmp
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-characters.lua
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /var/lib/texmf/luatex-cache/generic/names/luaotfload-names.luc
=

After downgrading only the following three packages to the testing version:
texlive-base, texlive-luatex, and texlive-latex-base with
# apt-get install -o APT::Install-Recommends=no texlive-base/testing  
texlive-luatex/testing  texlive-latex-base/testing
[...]
Suggested packages:
  ghostscript xpdf-reader | pdf-viewer perl-tk gv | postscript-viewer
Recommended packages:
  lmodern texlive-latex-base-doc
The following packages will be DOWNGRADED:
  texlive-base texlive-latex-base texlive-luatex
0 upgraded, 0 newly installed, 3 downgraded, 0 to remove and 0 not upgraded.
Need to get 0 B/24.4 MB of archives.
After this operation, 339 kB disk space will be freed.
Do you want to continue? [Y/n] 
debconf: delaying package configuration, since apt-utils is not installed
dpkg: warning: downgrading texlive-luatex from 2016.20170123-1 to 
2016.20161130-1
(Reading database ... 20908 files and directories currently installed.)
Preparing to unpack .../texlive-luatex_2016.20161130-1_all.deb ...
Unpacking texlive-luatex (2016.20161130-1) over (2016.20170123-1) ...
dpkg: warning: downgrading texlive-latex-base from 2016.20170123-1 to 
2016.20161130-1
Preparing to unpack .../texlive-latex-base_2016.20161130-1_all.deb ...
Unpacking texlive-latex-base (2016.20161130-1) over (2016.20170123-1) ...
dpkg: warning: downgrading texlive-base from 2016.20170123-1 to 2016.20161130-1
Preparing to unpack .../texlive-base_2016.20161130-1_all.deb ...
Unpacking texlive-base (2016.20161130-1) over (2016.20170123-1) ...
Processing triggers for tex-common (6.06) ...
Running mktexlsr. This may take some time... done.
Processing triggers for mime-support (3.60) ...
Setting up texlive-base (2016.20161130-1) ...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXLIVEDIST... 
mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN... 
mktexlsr: Updating /var/lib/texmf/ls-R... 
mktexlsr: Done.
/usr/bin/tl-paper: setting paper size for dvips to a4.
/usr/bin/tl-paper: setting paper size for dvipdfmx to a4.
/usr/bin/tl-paper: setting paper size for xdvi to a4.
/usr/bin/tl-paper: setting paper size for pdftex to a4.
Processing triggers for tex-common (6.06) ...
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time... done.
Setting up texlive-luatex (2016.20161130-1) ...
Setting up texlive-latex-base (2016.20161130-1) ...
Processing triggers for tex-common (6.06) ...
Running updmap-sys. This may take some time... done.
Running mktexlsr 

Bug#840853: reopen

[Vincent Danjean]

Le 24/11/2016 à 16:10, Neil Williams a écrit :
> unarchive 840853
> reopen 840853
> found 840853 1:2.7+dfsg-3
> found 840853 1:2.7+dfsg-3~bpo8+2
> affects 840853 + libguestfs
> thanks
> 
> https://packages.debian.org/sid/qemu-system-x86 specifies the seabios
> dependency as:
> dep: seabios (>= 1.7.5~)
> 
> This has also been inherited into the 2.7 jessie-backport build (as
> seabios 1.9 does not have a jessie-backport),

I uploaded seabios 1.9 to jessie-backport on 2016-11-16 (see confirmation
in attachment). It seems it has not been validated (yet).

  Regards,
Vincent

> so now systems using
> jessie-backports are affected by this bug.


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

--- Begin Message ---
binary:seabios is NEW.
binary:seabios is NEW.
source:seabios is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will receive an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.html
--- End Message ---

Bug#844021: libnative-platform-java 0.11-4 is not compatible with programs built with 0.10*

[Vincent Danjean]

Package: libnative-platform-java
Followup-For: Bug #844021

  Hi,

  As already explained, as libnative-platform-java changed its ABI, the new
version does not work with (all) programs wrote for the previous version.
  In Debian, gradle is the only one reverse dependency of
libnative-platform-java (i.e. it is the only package that directly uses
libnative-platform-java).

  gradle 2.13 do not work with libnative-platform-java 0.11 (at least, not all
features of gradle can be used when libnative-platform-java 0.11 is intalled)
  But gradle 3.1 (currently in unstable) works with (and even requires)
libnative-platform-java 0.11.

  So, to close this bug, I propose this small patch:
diff --git a/debian/control b/debian/control
index 27cb23f..3b95fdd 100644
--- a/debian/control
+++ b/debian/control
@@ -19,6 +19,7 @@ Package: libnative-platform-java
 Architecture: all
 Depends: libnative-platform-jni (>= ${source:Version}), ${misc:Depends}
 Suggests: libnative-platform-java-doc
+Breaks: gradle (<< 3.1), libgradle-core-java (<< 3.1)
 Description: Java bindings for various native APIs
  A collection of cross-platform Java APIs for various native APIs.
  Supports OS X, Linux, Solaris and Windows.

  Applying it will ensure that, (when gradle and libnative-platform-java will
be migrated to testing) if a user does a partial upgrade from stable to
testing, it will not keep a (old) gradle with a (incompatible) new
libnative-platform-java package.

  Regards,
Vincent


-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(200, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

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

Versions of packages libnative-platform-java depends on:
ii  libnative-platform-jni  0.10+dfsg-2

libnative-platform-java recommends no packages.

libnative-platform-java suggests no packages.

-- no debconf information

Bug#840853: qemu 2.7 requires linuxboot_dma.bin but does not provide or depend on it

[Vincent Danjean]

Package: qemu-system-x86
Version: 1:2.7+dfsg-3+b1
Followup-For: Bug #840853

  Hi,

  Contrary to what the debian/changelog says, this bug has not been fixed yet.
In fact, looking at the git repo, the fix has just been commited by
the maintainer on 2016-11-09, ie *after* the 2.7+dfsg-3 version.
  It would be very pleasant if the jessie backport package could be remade
with this fix.
  For information, I just uploaded to jessie-backport a backported version
of seabios 1.9.3-2 (ie 1.9.3-2~bpo8+1)

  Regards,
Vincent

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(200, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

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

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu   1.0.0+git-20150424.a25a16d-1
ii  libaio1 0.3.110-3
ii  libasound2  1.1.2-1
ii  libbluetooth3   5.43-1
ii  libbrlapi0.65.4-2
ii  libc6   2.24-5
ii  libcacard0  1:2.5.0-2
ii  libfdt1 1.4.0+dfsg-2
ii  libgcc1 1:6.2.0-10
ii  libglib2.0-02.50.2-1
ii  libgnutls30 3.5.6-2
ii  libjpeg62-turbo 1:1.5.1-2
ii  libncurses5 6.0+20160917-1
ii  libnettle6  3.3-1
ii  libpixman-1-0   0.34.0-1
ii  libpng16-16 1.6.26-1
ii  libpulse0   9.0-5
ii  libsasl2-2  2.1.27~72-g88d82a3+dfsg-1
ii  libsdl1.2debian 1.2.15+dfsg1-4
ii  libseccomp2 2.3.1-2
ii  libspice-server10.12.8-1
ii  libtinfo5   6.0+20160917-1
ii  libusb-1.0-02:1.0.21-1
ii  libusbredirparser1  0.7.1-1
ii  libuuid12.29-1
ii  libvdeplug2 2.3.2+r586-2+b1
ii  libx11-62:1.6.3-1
ii  libxen-4.8  4.8.0~rc3-1
ii  libxenstore3.0  4.8.0~rc3-1
ii  qemu-system-common  1:2.7+dfsg-3+b1
ii  seabios 1.9.3-2
ii  zlib1g  1:1.2.8.dfsg-2+b3

Versions of packages qemu-system-x86 recommends:
ii  qemu-utils  1:2.7+dfsg-3+b1

Versions of packages qemu-system-x86 suggests:
ii  kmod  23-1
pn  ovmf  
pn  qemu-block-extra  
pn  samba 
pn  sgabios   
ii  vde2  2.3.2+r586-2+b1

-- no debconf information

Bug#844021: libnative-platform-java 0.11-4 is not compatible with programs built with 0.10*

[Vincent Danjean]

Le 14/11/2016 à 16:56, 殷啟聰 a écrit :
> Control: tags -1 moreinfo
> 
> Gradle 3.1 is now uploaded, looks like this bug is fixed?

The bug is not fixed (there is a incompatible change in the interface
without package rename).
However, for Debian, as gradle seems the only reverse dependency of
libnative-platform-java, this bug can probably be closed.

  Regards,
Vincent

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

Bug#844021: libnative-platform-java 0.11-4 is not compatible with programs built with 0.10*

[Vincent Danjean]

  Hi,

Le 12/11/2016 à 09:05, 殷啟聰 a écrit :
> Hi Vincent,
> 
> Thank you for the report. In fact I have patched
> libnative-platform-java/0.11-4 to work with gradle/2.13, see [1].

The fact is that this patch does not seem to be enough. Currently,
gradle/2.13 in testing/unstable do *not* work with
libnative-platform-java/0.11-4 (also in testing/unstable).

> Turns out the upstream developer suddenly renamed the class without
> any transition.
> 
> I do not make sure this patch works for gradle/2.13 building all
> packages, but I can make sure that it works when building gradle/3.1-1
> using gradle/2.13.
> 
> Now that everything is ready, we will upload gradle/3.1-1 soon, but
> I'm still waiting for Emmanuel's sponsor. Let's not flag
> libnative-platform-java/0.11-4 Breaks gradle (<< 3.1) for the time
> being, as it will render gradle and libnative-platform-java
> uninstallable.

  The current situation generates FTBFS from other packages (including
gradle 2.13 itself). And it blocks development on other java software.
  Do you know when gradle 3.1 will be uploaded? If it is longer that
one week, some other workarounds should be put in place in order to
get a working gradle in the archive in between (a libnative-plateform-java/
0.11-4+really0.10 for example)
  Emmanuel: do you think that gradle 3.1 can be uploaded?

  Regards,
Vincent

> [1]: 
> https://anonscm.debian.org/cgit/pkg-java/libnative-platform-java.git/tree/debian/additionalSrc/PosixFile.java?h=debian/0.11-4
> 


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

Bug#844021: libnative-platform-java 0.11-4 is not compatible with programs built with 0.10*

[Vincent Danjean]

Le 11/11/2016 à 22:38, Emmanuel Bourg a écrit :
> Thank you for the report Vincent. libnative-platform-java/0.11 should
> probably declare that it breaks gradle (<< 3.1~).

The rebuild of gradle 2.13 breaks during tests:
[...]
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':test'.
[...]

Is there an easy way to (temporary) disable tests in gradle build?

I would like to try:
- first: rebuild gradle 2.13
  * without tests
  * with libnative-platform-java/0.11 installed
  * using the gradle version in sid
- then: rebuild gradle 2.13
  * with tests
  * with libnative-platform-java/0.11 installed
  * using the previous gradle build

but I do not know how/what to desactivate the (currently failing)
tests in the first build.

  Regards,
Vincent

> Emmanuel Bourg
> 


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

Bug#844020: gradle 2.13 in unstable do not work with libnative-platform-java 0.11

[Vincent Danjean]

Package: gradle
Version: 2.13-4
Severity: serious
Justification: Generate FTBFS in other packages (and in gradle itself)

  Hi,

I'm not an expert of java/gradle but I package several java programs (mainly
within the debian-med team).

I'm working on #843686. It took me time to understand that
net.rubygrapefruit.platform.PosixFiles.stat comes from the
libnative-platform-java package that is pulled by gradle itself.

I suspected that gradle was built with libnative-platform-java 0.10 and
does not work with libnative-platform-java 0.11.

So, I tried to do a local rebuild of gradle itself, so that it "links"
correctly with the new libnative-platform-java version.

=> it fails. So, currently, gradle FTBFS (as htsjdk), and for the same
reason (see the gradle build log in my up-to-date sid chroot at the
end of this report)

On my system, I downgraded libnative-platform-java to 0.10 (thanks to
snapshots.debian.org). With this, htsjdk can be built.


  So, I think that, with the current (2.13-4) gradle version:
- currently gradle FTBFS
- some gradle features do not work (I do not know gradle enought to
  be able to say which ones exactly) 
  that leads to FTBFS of different packages (at least htsjdk #843686
  and gradle itself)
- gradle should have been more strict wrt to libnative-platform-java
  dependency. I.e, instead of
  Depends: libnative-platform-java (>= 0.10)
  it should have had
  Depends: libnative-platform-java (>= 0.10), libnative-platform-java (<< 0.11)
  (or libnative-platform-java should have done a library transition rename
  as the new version is not compatible with the previous one
  => I will also open a bug for libnative-platform-java )


  I saw in the git that you are working to package the 3.1 version
of gradle. However, as this bug has annoying side effects, it would
be great if you can try to upload a new version of gradle compiled
with libnative-platform-java 0.11.
  The difficulty will be that you will need that, as gradle use itself
to compile, you will need libnative-platform-java 0.10 installed
in your environment... :-( I do not know enought of gradle and
libnative-platform-java to know how to workaround this.

  Of course, if gradle 3.1 is to be uploaded very soon, you can
ignore this bug.

  Regards,
Vincent


Part of gradle 2.13-4 build log in current unstable:

[...]
gradle assemble startScripts javadocAll groovydocAll dslHtml samplesDocs -x 
:docs:releaseNotes -x :distributions:assemble --project-prop finalRelease=true 
--offline --stacktrace --gradle-user-home debian/.gradlehome --parallel 
--max-workers=1
Parallel execution is an incubating feature.
:buildSrc:clean UP-TO-DATE
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovySLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:/usr/share/java/gradle-core.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:/usr/share/gradle/lib/gradle-core-2.13.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type 
[org.gradle.logging.internal.slf4j.OutputEventListenerBackedLoggerContext]
warning: Implicitly compiled files were not subject to annotation processing.
  Use -proc:none to disable annotation processing or -implicit to specify a 
policy for implicit compilation.
1 warning

:buildSrc:processResources
:buildSrc:classes
:buildSrc:jar
:buildSrc:assemble
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy
:buildSrc:processTestResources
:buildSrc:testClasses
:buildSrc:test FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':test'.
> net.rubygrapefruit.platform.PosixFiles.stat(Ljava/io/File;)Lnet/rubygrapefruit/platform/PosixFile;

* Try:
Run with --info or --debug option to get more log output.

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':test'.
at 
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)
at 
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)
at 
org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35)
at 
org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:68)
at 
org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at 
org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:52)
at 
org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
at 
org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53)
at 

Bug#844021: libnative-platform-java 0.11-4 is not compatible with programs built with 0.10*

[Vincent Danjean]

Package: libnative-platform-java
Version: 0.11-4
Severity: serious
Justification: makes other package FTBFS

  Hi,

  gradle in unstable works with libnative-platform-java 0.10+dfsg-2 but does
not work with libnative-platform-java 0.11-4.

  A detailed explaination for gradle can be seen in #844020.

  This problematic situation leads to several packages FTBFS, at
least htsjdk (#843686) and gradle itself.

  Normaly, if a new version of a library do not works, by design,
with program compiled with the old version, a package rename (and
an SONAME bump for ELF libraries) is required in order to avoid
to silently break reverse dependencies.
  I do not know libnative-platform-java enough to know if this
breakage is known and normal (i.e. a package rename should have
been done) or if this is a plain bug.

  Regards,
Vincent


-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(200, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

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

Versions of packages libnative-platform-java depends on:
ii  libnative-platform-jni  0.10+dfsg-2

libnative-platform-java recommends no packages.

libnative-platform-java suggests no packages.

-- no debconf information

Bug#774082: What is the solution/workaround ?

[Vincent Danjean]

Le 31/10/2016 à 18:22, Benoit Plessis a écrit :
> 
> Hi,
> 
> I am also affected by this issue, where the initramfs only activate the
> root/usr lv's
> 
> what is the recommended jessie workaround, disabling lvmetad ?

The workaround I gave in my comment #74 [1] allows me to use
lvmetad on all my jessie machines. You can try it.

  Regards,
Vincent


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774082#74

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

Bug#734365: fixed in freeplayer 20070531+dfsg.1-4

[Vincent Danjean]

Le 10/10/2016 à 23:32, Antoine Musso a écrit :
> The bug still happens in Jessie which is stuck to 20070531+dfsg.1-3
> 
>   * Fix vlc invocation (remove the "--http-charset=ISO-8859-1" option)
> (Closes: #734365)
> 
> Is there a way to pick that patch and release an update for Jessie?

The patch is very small. You can try it by editing (as root) the
/usr/bin/vlc-fbx script and remove the --http-charset=ISO-8859-1
options to the vlc invocation. Please, check this works (I do not
use freeplayer at all myself).
  Perhaps, a backport of the testing version would be better (other
vlc options are fixed)

  Regards,
Vincent

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

Bug#829085: freeipmi: not binNMU safe

[Vincent Danjean]

Package: src:freeipmi
Followup-For: Bug #829085

  Hi,

  Due to this bug, other packages are marked for removal. So, I prepared a
quick fix (switching packages from arch:all to arch:any) that avoid too
invasive modifications (such as removing --link-doc and doing a symlink
transition).
  I intend to upload this NMU to delayed-7 today. Feel free to upload
another fix if you wish (I'm really *not* sure my proposal is the good one
as it means that data will be duplicated in the archive) but I would really
avoid conman to be removed from the archive (we need it on some specific
hardware)

  Regards,
Vincent

PS: the patch in attachment is created on top of your git tree, not on
top of the current sources (ie "Remove myself (Ferenc) from Uploaders"
was present).

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 3f280220d3ea2b714c6b2e1d65b023c028e84f2e Mon Sep 17 00:00:00 2001
From: Vincent Danjean <vdanj...@debian.org>
Date: Mon, 5 Sep 2016 10:29:45 +0200
Subject: [PATCH] Fix "not binNMU safe" (Closes: #829085)

freeipmi-common and freeipmi are now arch:any instead of arch:all
A better fix can be found later if required
Removing --link-doc would require a symlink transition, that is too invasive for an NMU
---
 debian/changelog |  8 
 debian/control   | 30 +++---
 2 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index cd286a1..2c7d179 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+freeipmi (1.4.11-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "not binNMU safe" (Closes: #829085) by making freeipmi-common
+arch:any instead of arch:all. A better fix can be found later if required.
+
+ -- Vincent Danjean <vdanj...@debian.org>  Mon, 05 Sep 2016 09:55:48 +0200
+
 freeipmi (1.4.11-1) unstable; urgency=medium
 
   * [186d83b] Merge tag 'upstream/1.4.11'
diff --git a/debian/control b/debian/control
index 27b2b01..508aa32 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Vcs-Browser: http://git.debian.org/?p=pkg-freeipmi/pkg-freeipmi.git
 Vcs-git: git://anonscm.debian.org/pkg-freeipmi/pkg-freeipmi.git
 
 Package: freeipmi-common
-Architecture: all
+Architecture: any
 Depends: ${misc:Depends}
 Pre-Depends: dpkg (>=1.15.7.2~)
 Suggests: freeipmi-tools
@@ -28,7 +28,7 @@ Description: GNU implementation of the IPMI protocol - common files
 
 Package: freeipmi-tools
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, freeipmi-common (= ${source:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, freeipmi-common (= ${binary:Version})
 Suggests: freeipmi-ipmidetect, freeipmi-bmc-watchdog
 Description: GNU implementation of the IPMI protocol - tools
  FreeIPMI is a collection of Intelligent Platform Management IPMI
@@ -57,7 +57,7 @@ Description: GNU implementation of the IPMI protocol - tools
 Package: freeipmi-bmc-watchdog
 Architecture: any
 Pre-Depends: dpkg (>=1.15.7.2~)
-Depends: ${shlibs:Depends}, ${misc:Depends}, freeipmi-tools, freeipmi-common (= ${source:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, freeipmi-tools, freeipmi-common (= ${binary:Version})
 Description: GNU implementation of the IPMI protocol - BMC watchdog
  FreeIPMI is a collection of Intelligent Platform Management IPMI
  system software. It provides in-band and out-of-band software and a
@@ -68,7 +68,7 @@ Description: GNU implementation of the IPMI protocol - BMC watchdog
 
 Package: freeipmi-ipmidetect
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, freeipmi-common (= ${source:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, freeipmi-common (= ${binary:Version})
 Pre-Depends: dpkg (>=1.15.7.2~)
 Description: GNU IPMI - IPMI node detection tool
  FreeIPMI is a collection of Intelligent Platform Management IPMI
@@ -81,7 +81,7 @@ Description: GNU IPMI - IPMI node detection tool
 Package: freeipmi-ipmiseld
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends},
- freeipmi-common (= ${source:Version}),
+ freeipmi-common (= ${binary:Version}),
  sysvinit-utils (>= 2.88dsf-50~),
 Pre-Depends: dpkg (>=1.15.7.2~)
 Description: GNU IPMI - IPMI node detection tool
@@ -96,7 +96,7 @@ Description: GNU IPMI - IPMI node detection tool
 Package: libfreeipmi16
 Section: libs
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, freeipmi-common (= ${source:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, freeipmi-common (= ${binary:Version})
 Description: GNU IPMI - libraries
 

Bug#827165: qct: FTBFS:

[Vincent Danjean]

13093157.saEWe2Ad2h.qct
>   GPG_TTY=/dev/console
>   QUILT_PATCHES=debian/patches
>   QUILT_NO_DIFF_INDEX=1
>   QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index
>   DEBEMAIL=la...@debian.org
>   DEBFULLNAME=Chris Lamb
>   EDITOR=vim
>   LESS=-cgiFx4M
>   BLASTER=A220 I5 D1 H5 P330 T6
>   _=/usr/bin/env
>   
>   
> **
>   ** Building qct 1.7-3 on amd64  
> **
>   
> **
>   
>dpkg-buildpackage -rfakeroot -D -us -uc -b
>   dpkg-buildpackage: info: source package qct
>   dpkg-buildpackage: info: source version 1.7-3
>   dpkg-buildpackage: info: source distribution unstable
>   dpkg-buildpackage: info: source changed by Vincent Danjean 
> <vdanj...@debian.org>
>dpkg-source --before-build qct-1.7
>   dpkg-buildpackage: info: host architecture amd64
>fakeroot debian/rules clean
>   test -x debian/rules
>   dh_clean 
>   /usr/bin/make -f debian/rules reverse-config
>   make[1]: Entering directory 
> '/home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7'
>   make[1]: 'reverse-config' is up to date.
>   make[1]: Leaving directory 
> '/home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7'
>   if [ -d "." ]; then \
> cd . && 
> QUILT_PATCHES=/home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7/debian/patches
>  quilt --quiltrc /dev/null pop -a -R || test $? = 2 ; \
>   fi
>   Removing patch disable-broken-git-support.patch
>   Restoring qctlib/vcs/cg.py
>   
>   Removing patch deb_specific__do-not-use_changeselect.py_has_program.patch
>   Restoring qctlib/changeselect.py
>   
>   No patches applied
>   rm -rf ./.pc
>   rm -f debian/stamp-patch*
>   cd . && python setup.py clean -a
>   running clean
>   'build/lib.linux-x86_64-2.7' does not exist -- can't clean it
>   'build/bdist.linux-x86_64' does not exist -- can't clean it
>   'build/scripts-2.7' does not exist -- can't clean it
>   rm -rf debian/python-module-stampdir
>   find "/home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7" -name 
> '*.py[co]' -delete
>   find "/home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7" -name 
> __pycache__ -type d -empty -delete
>   find "/home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7" -prune 
> -name '*.egg-info' -exec rm -rf '{}' ';'
>   rm -f qctlib/ui_dialog.py qctlib/ui_preferences.py
>   /usr/bin/make -C doc clean
>   make[1]: Entering directory 
> '/home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7/doc'
>   rm -f qct.1 qct.1.xml qct.1.html
>   make[1]: Leaving directory 
> '/home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7/doc'
>debian/rules build
>   test -x debian/rules
>   mkdir -p "."
>   mkdir -p debian/python-module-stampdir
>   /usr/bin/make -f debian/rules reverse-config
>   make[1]: Entering directory 
> '/home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7'
>   make[1]: 'reverse-config' is up to date.
>   make[1]: Leaving directory 
> '/home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7'
>   cd . && 
> QUILT_PATCHES=/home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7/debian/patches
>  quilt --quiltrc /dev/null push -a || test $? = 2
>   Applying patch deb_specific__do-not-use_changeselect.py_has_program.patch
>   patching file qctlib/changeselect.py
>   
>   Applying patch disable-broken-git-support.patch
>   patching file qctlib/vcs/cg.py
>   
>   Now at patch disable-broken-git-support.patch
>   touch debian/stamp-patched
>   /usr/bin/make -f debian/rules update-config
>   make[1]: Entering directory 
> '/home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7'
>   make[1]: 'update-config' is up to date.
>   make[1]: Leaving directory 
> '/home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7'
>   cd . && python setup.py build 
> --build-base="/home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7/./build"
>   running build
>   running build_py
>   creating /home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7/build
>   creating 
> /home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7/build/lib.linux-x86_64-2.7
>   creating 
> /home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7/build/lib.linux-x86_64-2.7/qctlib
>   copying qctlib/utils.py -> 
> /home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7/./build/lib.linux-x86_64-2.7/qctlib
>   copying qctlib/__init__.py -> 
> /home/lamby/temp/cdt.20160613093157.saEWe2Ad2h.qct/qct-1.7/./build/lib.linux-x86_64

Bug#821523: Bug#821691: fixed in owfs 3.1p1-4

[Vincent Danjean]

Le 16/05/2016 08:12, Logan Rosen a écrit :
> Hi,
> 
> On Sat, 07 May 2016 09:57:28 +0000 Vincent Danjean <vdanj...@debian.org> 
> wrote:
>> Source: owfs
>> Source-Version: 3.1p1-4
>>
>> We believe that the bug you reported is fixed in the latest version of
>> owfs, which is due to be installed in the Debian FTP archive.
> 
> This bug actually isn't totally fixed in owfs 3.1p1-4. libownet-php
> depends on php5 | php5-cli, which should be changed to php | php-cli.
> Can you please change the dependency accordingly?

Oups, sorry. I just uploaded 3.1p1-5 that should fix this:
$ debdiff owfs_3.1p1-4.dsc owfs_3.1p1-5.dsc
diff -Nru owfs-3.1p1/debian/changelog owfs-3.1p1/debian/changelog
--- owfs-3.1p1/debian/changelog 2016-05-07 11:09:23.0 +0200
+++ owfs-3.1p1/debian/changelog 2016-05-16 08:53:52.0 +0200
@@ -1,3 +1,9 @@
+owfs (3.1p1-5) unstable; urgency=medium
+
+  * really fix php dependencies (Thanks Logan Rosen)
+
+ -- Vincent Danjean <vdanj...@debian.org>  Mon, 16 May 2016 08:53:29 +0200
+
 owfs (3.1p1-4) unstable; urgency=medium

   * Remove php bindings. Swig do not support php7 (yet) and Debian not
diff -Nru owfs-3.1p1/debian/control owfs-3.1p1/debian/control
--- owfs-3.1p1/debian/control   2016-05-07 11:09:23.0 +0200
+++ owfs-3.1p1/debian/control   2016-05-16 08:53:52.0 +0200
@@ -227,7 +227,7 @@
 Package: libownet-php
 Architecture: all
 Section: web
-Depends: php5 | php5-cli,
+Depends: php | php-cli,
  ${misc:Depends}
 Description: Dallas 1-wire support: PHP OWNet library
  The 1-Wire bus is a cheap low-speed bus for devices like weather

> Thanks,
> Logan
> 

  Regards,
Vincent

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

Bug#808593: [Help]: Bug#808593: htsjdk: FTBFS: [testng] FAILED: testHTTPNotExist

[Vincent Danjean]

Le 14/03/2016 21:20, Vincent Danjean a écrit :
> Is it the correct way to build a package that requires java 8?

  I just saw that default-jre/jdk is 1.8 now, so I'm sure this
package need to be fixed. If someone can tell me how to do it
(or just point me to a package correctly written).

  Regards,
Vincent


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

Bug#808593: [Help]: Bug#808593: htsjdk: FTBFS: [testng] FAILED: testHTTPNotExist

[Vincent Danjean]

Le 11/02/2016 21:50, Emmanuel Bourg a écrit :
> Le 11/02/2016 21:01, Andreas Tille a écrit :
> 
>> any hint why this test that worked before might fail since end of
>> December?
> 
> I got a quick look and I can't explain this test failure. It doesn't
> seem very important though, you could just disable this test.

I just upgraded htsjdk (required for picard-tools). It does not seem to
FTBFS anymore (pushed in git).
  I plan to upload it when picard-tools will be ready but if someone
can take a look at it before, I would be pleased. In particular,
there is in debian/control:
===
Build-Depends: openjdk-8-jre-headless, openjdk-8-jdk, ...
Build-Conflicts: openjdk-7-jre-headless
===

And, in debian/rules:
===
  dh_auto_build -- -Dant.build.javac.source=1.8 -Dant.build.javac.target=1.8 ...
===

Is it the correct way to build a package that requires java 8?

I do not change this part myself and did not check the requirement,
but I just saw with picard-tools (same upstream authors) that java 8
is also required ( <> operator (>=7) and lambda expressions (>=8) )
so I would like to be sure to do the correct thing.

  Regards,
Vincent

> Emmanuel Bourg
> 


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

Bug#815979: dotclear: New minor releases with security fixes

[Vincent Danjean]

Package: dotclear
Version: 2.8.0+dfsg-1
Severity: serious
Tags: security
Justification: security

  Hi,

  I'm using Debian packages of dotclear (a php blogs engine) for a few years.
For 6 months, the package do not change, and I did not get any anwser to
my previous bug reports, including an important one (#797055) that probably
prevent any one to use the Debian package as-is.
  I just see today that two minor releases have been published that
fix security bugs. From upstream webpage:
===
News

2015 Oct 25 Dotclear 2.8.2

A new maintenance release which fixes one potential XSS vulnerability in
comments's list and enforce media extension before upload[1] (thanks to Tim
Coen, Curesec Gmbh, for reporting them) and two...

2015 Sep 23 Dotclear 2.8.1

A new maintenance release which fixes one potential XSS vulnerabilities
(thanks to Yuji Tounai of NTT Com Security (Japan) KK, via Keiko Yashiki from
JPCERT/CC) and two other bugfixes. Your dashboard...
===

  I tagged this bug with a serious severity so that, if dotclear is not
maintained anymore, it will be removed from testing (so admins tracking testing
will be notified and can manually install the upstream versions). If dotclear
is still maintained (I hope for that), then an update must be done.

  Note that I do not know if the security bugs also apply or not to the
jessie version.

  Regards,
Vincent

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'squeeze-lts'), (500, 
'oldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

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

Versions of packages dotclear depends on:
ii  apache2 [httpd]2.4.18-1
ii  dbconfig-common2.0.3
ii  debconf [debconf-2.0]  1.5.58
pn  libapache2-mod-php5 | php5 | php5-cgi  
ii  libjs-jquery   1.11.3+dfsg-4
ii  libjs-jquery-cookie10-2
ii  libjs-jquery-ui1.10.1+dfsg-1
pn  php5-cli   
pn  php5-mysql | php5-pgsql | php5-sqlite  
ii  sqlite33.11.0-2

Versions of packages dotclear recommends:
ii  apache2 [httpd] 2.4.18-1
pn  mysql-server | mariadb-server | postgresql  

dotclear suggests no packages.

-- debconf information excluded

Bug#814652: actually not fixed in freshplayerplugin 0.3.4-2

[Vincent Danjean]

Le 15/02/2016 12:59, Patrick Stokman a écrit :
> Hi,
> 
> Unfortunately, it appears that the wrong package has been build, it does not 
> contain the /usr/lib/mozilla/plugins directory.

Should be good in -3:
drwxr-xr-x root/root 0 2016-02-15 17:40 ./usr/lib/mozilla/
drwxr-xr-x root/root 0 2016-02-15 17:40 ./usr/lib/mozilla/plugins/

In -2, I added debian/browser-plugin-freshplayer-pepperflash.dir instead
of debian/browser-plugin-freshplayer-pepperflash.dirs...

  Regards,
Vincent

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

Bug#814652: actually not fixed in freshplayerplugin 0.3.4-2

[Vincent Danjean]

Le 15/02/2016 12:59, Patrick Stokman a écrit :
> Hi,
> 
> Unfortunately, it appears that the wrong package has been build, it does not 
> contain the /usr/lib/mozilla/plugins directory.

Argh, sorry. It was late when I uploaded the file and I remember
now I forgot to check my dirs file was correctly taken into account.
I will fix it this evening.

> $ dpkg-deb -c browser-plugin-freshplayer-pepperflash_0.3.4-2_amd64.deb
> drwxr-xr-x root/root 0 2016-02-13 23:57 ./
> drwxr-xr-x root/root 0 2016-02-13 23:57 ./usr/
> drwxr-xr-x root/root 0 2016-02-13 23:57 ./usr/share/
> drwxr-xr-x root/root 0 2016-02-13 23:57 ./usr/share/doc/
> drwxr-xr-x root/root 0 2016-02-13 23:57 ./usr/share/doc/browser-
> plugin-freshplayer-pepperflash/
> -rw-r--r-- root/root   563 2016-02-13 23:50 ./usr/share/doc/browser-
> plugin-freshplayer-pepperflash/changelog.Debian.gz
> -rw-r--r-- root/root  3850 2015-12-20 14:38 ./usr/share/doc/browser-
> plugin-freshplayer-pepperflash/freshwrapper.conf.example
> -rw-r--r-- root/root 26210 2016-02-13 23:57 ./usr/share/doc/browser-
> plugin-freshplayer-pepperflash/img-missing-pepflash.png
> -rw-r--r-- root/root  2651 2015-12-20 14:38 ./usr/share/doc/browser-
> plugin-freshplayer-pepperflash/README.md.gz
> -rw-r--r-- root/root  3743 2015-12-20 14:38 ./usr/share/doc/browser-
> plugin-freshplayer-pepperflash/known-issues.md
> -rw-r--r-- root/root  1595 2015-12-20 14:38 ./usr/share/doc/browser-
> plugin-freshplayer-pepperflash/changelog.gz
> -rw-r--r-- root/root 23350 2016-02-13 23:50 ./usr/share/doc/browser-
> plugin-freshplayer-pepperflash/copyright
> drwxr-xr-x root/root 0 2016-02-13 23:57 ./usr/lib/
> drwxr-xr-x root/root 0 2016-02-13 23:57 ./usr/lib/browser-plugin-
> freshplayer-pepperflash/
> -rw-r--r-- root/root   1061976 2016-02-13 23:57 ./usr/lib/browser-plugin-
> freshplayer-pepperflash/libfreshwrapper-flashplayer.so
> 
> Configuration of the package still fails because of it.
> 
> Regards,
> 
> Patrick Stokman
> 


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

Bug#811409: owfs: Package compiled without USB support

[Vincent Danjean]

severity 811409 normal
tag 811409 +moreinfo
thanks

Le 18/01/2016 18:37, Piotr Górski a écrit :
> Severity: grave
> Justification: renders package unusable

Only for some use cases (as for most bugs). I corrected the severity.


> Dear Maintainer,
> 
> Package available in Debian's APT repository has no USB support.

It is configurated with "--enable-usb". That said, the 3.1p0-2 version
tried to avoid the uneeded dependency on the old usb library and
it is possible that an error occurs.
  I do not have a USB adapter so I cannot test myself. I will need
your help.
  Can you:
- check which versions of owfs work (or not) with USB adapters
  http://snapshot.debian.org/package/owfs/ can help you to check
  older packages (take care to replace/install all owfs related
  packages, ie owfs-fuse, owserver, ..., not just only the owfs
  meta package)
- show me a trace example when USB works and when it does not
  (the owfs debug option will help you here)

> Package needs to be created locally using debuild to enable USB 
> support.

Did you change anything in the packaging before running debbuild?

If no, this is probably a build-depends problem (ie something
installed on your machine and not in the autobuilders).

  Regards,
Vincent

> Most users use USB to 1-Wire adaptors so package isn't 
> working "out-of-the-box".

> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: i386 (i686)
> 
> Kernel: Linux 4.3.0-1-686-pae (SMP w/1 CPU core)
> Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages owfs depends on:
> ii  owfs-fuse  3.1p0-2
> ii  owftpd 3.1p0-2
> ii  owhttpd3.1p0-2
> ii  owserver   3.1p0-2
> 
> owfs recommends no packages.
> 
> Versions of packages owfs suggests:
> ii  owfs-doc  3.1p0-2
> 
> -- no debconf information
> 


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

Bug#807645: ifupdown package fails to configure itself (by dpkg)

[Vincent Danjean]

Package: ifupdown
Version: 0.8.2
Severity: serious
Justification: fail to configure itself

  Hi,

  I just upgraded ifupdown and it fails to configure itself.
I've added "set -x" to /var/lib/dpkg/info/ifupdown.postinst and
a final "echo done $?" at the end of /lib/systemd/systemd-sysv-install. Here
are the results:

# LC_ALL=C dpkg -a --configure
Setting up ifupdown (0.8.2) ...
+ MYNAME=ifupdown.postinst
+ [ configure = configure ]
+ addgroup --quiet --system netdev
+ [ configure = configure ]
+ [ ! -f /etc/network/interfaces ]
+ [ configure = configure ]
+ [ -x /etc/init.d/networking ]
+ update-rc.d networking defaults
+ [ configure = configure ]
+ [ -e /etc/udev/rules.d/z60_ifupdown.rules ]
+ dpkg-maintscript-helper rm_conffile /etc/default/ifupdown 0.7~+ ifupdown -- 
configure 0.7.54
+ dpkg-maintscript-helper rm_conffile /etc/init.d/ifupdown 0.7~+ ifupdown -- 
configure 0.7.54
+ dpkg-maintscript-helper rm_conffile /etc/init.d/ifupdown-clean 0.7~beta1 
ifupdown -- configure 0.7.54
+ [ configure = configure -a -e /bin/systemctl ]
+ [ -z 0.7.54 ]
+ dpkg --compare-versions 0.7.54 lt 0.8
+ echo Enabling networking.service.
Enabling networking.service.
+ systemctl enable networking.service
Synchronizing state of networking.service with SysV init with 
/lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install enable networking
done 0
Failed to execute operation: File exists
dpkg: error processing package ifupdown (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 ifupdown
#

So, something is wrong with the "systemctl enable networking.service" call but
is is not the /lib/systemd/systemd-sysv-install invocation.

Using "strace -f -o /tmp/strace.out2 systemctl enable networking.service" did
not help me to find which file is already existing.

  Regards,
Vincent

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 4.3.0-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ifupdown depends on:
ii  adduser   3.113+nmu3
ii  iproute2  4.3.0-1
ii  libc6 2.19-22
ii  lsb-base  9.20150917

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.3.3-5

Versions of packages ifupdown suggests:
ii  ppp 2.4.7-1+1
pn  rdnssd  

-- no debconf information

Bug#807493: altree: Produces empty binary package

[Vincent Danjean]

  Hi,

Le 09/12/2015 16:31, Dominic Hargreaves a écrit :
> Source: altree
> Version: 1.3.1-3
> Severity: grave
> Justification: package not usable
> Tags: sid
> X-Debbugs-Cc: debian-p...@lists.debian.org
> 
> The last upload, fixing #807423, unfortunately started creating empty
> binary packages on most (but not all) architectures. See for example
> 
> https://packages.debian.org/sid/amd64/altree/filelist
> https://packages.debian.org/sid/armel/altree/filelist
> https://packages.debian.org/sid/armhf/altree/filelist
> https://packages.debian.org/sid/i386/altree/filelist
> 
> I can't see from a quick glance what is going on here; CC-ing
> debian-perl in case anyone can help.

  It is an error from me. altree files are now installed in debian/tmp
instead of directly debian/altree by debian/rules, so a debian/altree.install
file is required.
  I will fix this in a few hours if nobody do it before. And I will
reincorporate Andreas modifications that were all good.

  Regards,
Vincent

> Cheers,
> Dominic.
> 


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

Bug#801784: gitk de_DE.UTF-8: Error in startup script: bad menu entry index "Ansicht bearbeiten ..."

[Vincent Danjean]

Package: gitk
Version: 1:2.6.2-1
Followup-For: Bug #801784

  Hi,

  I see the same problem in French local:

$ gitk master
Error in startup script: bad menu entry index "Éditer la vue..."
while executing
".bar.view entryconf [mca "Edit view..."] -state normal"
invoked from within
"if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd ne {}} {
# create a view for the files/dirs specified on the command line
se..."
(file "/usr/bin/gitk" line 12442)
$ gitk --all
Error in startup script: bad menu entry index "Éditer la vue..."
while executing
".bar.view entryconf [mca "Edit view..."] -state normal"
invoked from within
"if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd ne {}} {
# create a view for the files/dirs specified on the command line
se..."
(file "/usr/bin/gitk" line 12442)
$ 

  That said, if I give no argument at all to gitk, it works:

$ gitk
$

  I can also workaround the bug by not using translations:
$ LC_MESSAGES=C gitk master
$ LC_MESSAGES=C gitk --all
$ 

  Regards,
Vincent


-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 4.3.0-rc7-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gitk depends on:
ii  git  1:2.6.2-1
ii  tk   8.6.0+8

gitk recommends no packages.

Versions of packages gitk suggests:
ii  git-doc  1:2.6.2-1

-- no debconf information

Bug#799698: [Debian-med-packaging] Bug#799698: samtools: Unknown command "faidx" on (kfreebsd-)i386

[Vincent Danjean]

severity #799698 important
thanks

Le 21/09/2015 17:58, Aaron M. Ucko a écrit :
> Package: samtools
> Version: 1.2-2
> Severity: serious
> Justification: fails to build from source

If I understand correctly for bug report, samtools correctly builds
from source, but python-pysam fails.
  So, I'm downgrading the severity for the samtools package.
  A bug should probably be opened on python-pysam (with the whole
failed build log), severity serious as this package cannot be
build in Debian anymore.

  One someone will have to check if the bug is in samtool or if the
new samtools did not work with the old python-pysam.
  In the later case, this bug will be fixed by just adding a
Breaks: python-pysam (<< version-that-fixe-pysam-with-new-samtools)
in the samtools package. But, python-pysam will then need to be
fixed/updated in order to work with the new samtools.

> Builds of python-pysam for i386 and kfreebsd-i386 failed:
> 
>samtools faidx ex1.fa
>Unknown command "faidx".
> 
> This error appears to indicate a deficiency in samtools; could you
> please take a look?

deficiency or removal/change of a old tool ? I did not checked into
samtools changelog yet.

  Regards,
Vincent

> Thanks!
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 


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

Bug#799322: pocl: FTBFS: (gcc5 related?) symbols mismatches + test failures

[Vincent Danjean]

Le 17/09/2015 22:45, Rebecca N. Palmer a écrit :
> Also, nearly all the tests failed: the build treats this as
> non-fatal, but it should probably be investigated.

Just for the record, failed tests are fatal but the failure is
postponed in order to get more info from build logs:

override_dh_auto_test:
# Failure in testsuite is delayed until symbols handling
# and all files are logged.
$(RM) debian/stamp-failed-testsuite
if ! dh_auto_test ; then \
[...]
touch debian/stamp-failed-testsuite; \
fi

override_dh_makeshlibs:
dh_makeshlibs
if test -f debian/stamp-failed-testsuite ; then \
grep '^ .*FAILED' < tests/testsuite.log ; \
exit 1 ; \
    fi

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

Bug#799322: pocl: FTBFS: (gcc5 related?) symbols mismatches + test failures

[Vincent Danjean]

Le 17/09/2015 22:45, Rebecca N. Palmer a écrit :
> Package: src:pocl
> Version: 0.10-10
> Severity: serious
> Control: found -1 0.10-12
> Control: block 794935 with -1
> 
> The binNMU of pocl for the llvm-toolchain-3.5 transition 
> (https://buildd.debian.org/status/fetch.php?pkg=pocl=amd64=0.10-10%2Bb1=1442439767)
>  failed with symbols mismatches, at least some of which look gcc-5 related 
> (though I haven't checked whether they all are, and pocl does have a history 
> of symbols issues), e.g.
> 
> - 
> (optional=templinst)_ZN4llvm12hash_combineINS_9hash_codeESsEES1_RKT_RKT0_@Base
>  0.10
> [...]
> +#MISSING: 0.10-10+b1# 
> (optional=templinst)_ZN4llvm12hash_combineINS_9hash_codeENS_9StringRefEEES1_RKT_RKT0_@Base
>  0.10
> + 
> _ZN4llvm12hash_combineINS_9hash_codeENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcES1_RKT_RKT0_@Base
>  0.10-10+b1
> 
> Also, nearly all the tests failed: the build treats this as non-fatal, but it 
> should probably be investigated.
> 
> A local build of 0.10-12 from experimental had far fewer (but not no) test 
> failures, but still FTBFS with the symbols issue.

pocl 0.10 is outdated. There is no interest into digging into it.
I started to package the new version but did not have time to finish
for now. Help welcome (I just pushed my initial work in collab-maint)

pocl 0.10 can be removed from testing for now if this help transitions.

And, for information, I plan to remove symbols tracking. This is a mess
due to C++ mangling and all C++ libraries are only used internally.
So, there is no interest at all into tracking the symbol list.


  Regards,
Vincent

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

Bug#734365: severity normal ?

[Vincent Danjean]

On 30/08/2015 21:20, Mathieu Malaterre wrote:
 Control: tags -1 grave
 
 I fail to understand how this package can be of any use because of -1 ? 
 Marking as grave.

The fix is described in the bug report, so I think that interested
people have fixed it manually.
  That said, I totally forgot about this bug report. Thanks for the
reminder. I just upload a fixed package with the offending option
removed.

  As I do not use it anymore, I would be very please if one user of
this package can confirm me that it is working again.

  Regards,
Vincent

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

Bug#780735: icedove: Segfault at startup, even in safe mode

[Vincent Danjean]

fixed 780735 38.0~b2-1
thanks

Le 06/05/2015 21:50, Carsten Schoenert a écrit :
 Hello Vincent,
 
 On Wed, Mar 18, 2015 at 03:44:45PM +0100, Vincent Danjean wrote:
 Package: icedove
 Version: 36.0~b1-1
 Severity: serious
 Justification: Segfault at startup

   After installing the last experimental version (36.0~b1-1), icedove
 segfault at startup, even in safe mode.
   Previous installed version (34.0~b1-2) worked correctly.
 
 did this happen with the recent version 38.0~b2 too?

  I tried with weekend and do not observe segfault at startup anymore.
It seems the bug is fixed in the last upload. Marking as such in the BTS.

 I can't reproduce such segfaults in any case so we need your help. If
 you create a gdb backtrace could you please do this with 'LANG= ' so we
 get a english output. Also please use 'bt thread apply all' for getting
 backtrace informations.

  Will do it if I experiment such segfault again.

PS: when I start icedove in a terminal, I see lots (about 30) of lines such as
Error: Couldn't find /softwarestudio.org/Olson_20011030_5/Europe/Paris
  Is it a problem that requires a bug report?

  Regards,
Vincent

 We plan to upload  a version 38.0~4 in the next days.
 
 Regards
 Carsten
 


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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773752: gdm3: GDM3 pollutes system logs with user session output under systemd

[Vincent Danjean]

Le 24/04/2015 12:38, Michael Biebl a écrit :
 Am 24.04.2015 um 12:21 schrieb Michael Biebl:
 An alternative to dropping the user messages, is to log them to a
 separate log file which has different log retention policies.
 
 For completeness sake, this would look like this:
 
 $ cat /etc/rsyslog.d/drop-user-messages.conf
 user.* /var/log/user.log
  stop
 
 
 The point here is, that those rsyslog.d snippets are included before the
 rules in /etc/rsyslog.conf are processed. So you can log to user.log and
 stop any further processing, i.e. avoid it ends up in syslog and messages.

Thank you very much for this tip. I will downgrade the bug severity
to its initial value (and add this config on all my machines)

  Regards,
Vincent

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782241: locales: On upgrade, generic locales as C.UTF-8 are lost in /etc/default/locale

[Vincent Danjean]

Package: locales
Version: 2.19-17
Severity: serious
Tags: patch
Justification: valid administator configuration is lost on upgrade

  Hi,

  The current debconf script for the 'locales' package does not allow to
choose the C.UTF-8 locale. Moreover, if an administrator write this valid
value for the LANG variable in /etc/default/locale, the value will be
overwritten as soon as the 'locales' package is reconfigurated.
  If I correctly follow the logic of the config script, one goal is to ensure
that the chosen value is correct (i.e. supported). So, the current value
is not always put in the debconf proposed list.
  However, the C.UTF-8 value is valid (as are C and POSIX but I'm less sure
of their value).

  So, either the C.UTF-8 value (and perhaps C and POSIX) should be proposed
when selecting the default environment locale, or, at very least, the config
script must allow to keep it when it has manually be put into
/etc/default/locale by the administrator.

  If you want to always allow this value, the current patch is enough:
===
--- locales.config  2015-03-14 10:30:53.0 +0100
+++ /tmp/locales.config 2015-04-09 15:05:40.257852467 +0200
@@ -547,9 +547,12 @@
 fi
 DEFAULT_LOCALES=$(echo $RET | sed -e 's/ [^ ]*,/,/g' -e 's/ [^ 
]*$//')
 if [ -n $DEFAULT_LOCALES ]; then
-db_subst locales/default_environment_locale locales 
$DEFAULT_LOCALES
-db_input medium locales/default_environment_locale || true
+DEFAULT_LOCALES=C, C.UTF-8, POSIX, $DEFAULT_LOCALES
+else
+DEFAULT_LOCALES=C, C.UTF-8, POSIX
 fi
+db_subst locales/default_environment_locale locales $DEFAULT_LOCALES
+db_input medium locales/default_environment_locale || true
 ;;
 *)
 break
===
  Feel free to adjust the list of always supported locales (ie C and POSIX)

  If you want to only allow the C, C.UTF-8, and POSIX locales when they
have been manually set up (so they do not show up on default install), I
can provide an updated patch. Just tell me.

  Regards,
Vincent

-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 3.19.0-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  libc-bin   2.19-17

locales recommends no packages.

locales suggests no packages.

-- debconf information:
  locales/default_environment_locale: None
  locales/locales_to_be_generated: fr_FR.UTF-8 UTF-8


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#781127: virt-manager: Missing version requirement declaration when importing VTE

[Vincent Danjean]

Package: virt-manager
Version: 1:1.0.1-4
Severity: serious
Tags: patch

As soon as you have several VTE library version installed in your system
and that you are using serial console (created by default), you cannot open
the window of a virtual machine (screen and details).

You get the message:
Error launching details: 'gi.repository.Vte' object has no attribute 
'TerminalCursorBlinkMode'

With the details:
rror launching details: 'gi.repository.Vte' object has no attribute 
'TerminalCursorBlinkMode'

Traceback (most recent call last):
  File /usr/share/virt-manager/virtManager/engine.py, line 813, in 
_show_vm_helper
details.activate_default_page()
  File /usr/share/virt-manager/virtManager/details.py, line 1389, in 
activate_default_page
self.activate_default_console_page()
  File /usr/share/virt-manager/virtManager/details.py, line 1383, in 
activate_default_console_page
self.console.activate_default_console_page()
  File /usr/share/virt-manager/virtManager/console.py, line 1607, in 
activate_default_console_page
self._show_serial_tab(name, serialidx)
  File /usr/share/virt-manager/virtManager/console.py, line 1666, in 
_show_serial_tab
serial = vmmSerialConsole(self.vm, target_port, name)
  File /usr/share/virt-manager/virtManager/serialcon.py, line 322, in __init__
self.init_terminal()
  File /usr/share/virt-manager/virtManager/serialcon.py, line 332, in 
init_terminal
self.terminal.set_cursor_blink_mode(Vte.TerminalCursorBlinkMode.ON)
  File /usr/lib/python2.7/dist-packages/gi/module.py, line 320, in __getattr__
return getattr(self._introspection_module, name)
  File /usr/lib/python2.7/dist-packages/gi/module.py, line 139, in __getattr__
self.__name__, name))
AttributeError: 'gi.repository.Vte' object has no attribute 
'TerminalCursorBlinkMode'


Googling shows me this:
https://bugzilla.redhat.com/show_bug.cgi?id=1114379
but also a very quick fix here:
https://wiki.archlinux.org/index.php/Talk:Libvirt

Quoting:
=
change the following line in /usr/share/virt-manager/virtManager/serialcon.py

BEFORE

from gi.repository import Vte

AFTER

#from gi.repository import Vte
import gi
gi.require_version('Vte', '2.90')
from gi.repository import Vte

to explicitely use a vte 290 terminal
=

  Indeed, when importing the python module, as vte has several API incompatible 
version,
we need to select the good (used) one.
  Live editing the file on my system as suggested above immediately (after a
restart of virt-manager) fixes the bug on my machine.

  Please, consider asking for a freeze exception (or a fix in the first
point-release): the fix is very small and the bug will hit more and more people
as soon as they install (due to other dependencie) a new vte library.

  Regards,
Vincent


-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 3.19.0-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.22.0-1
ii  gconf2   3.2.6-3
ii  gir1.2-gtk-3.0   3.14.5-1
ii  gir1.2-gtk-vnc-2.0   0.5.3-1.3
ii  gir1.2-libvirt-glib-1.0  0.1.9-4
ii  gir1.2-vte-2.90  1:0.36.3-1
ii  librsvg2-common  2.40.5-1
ii  python-dbus  1.2.0-2+b3
ii  python-gi3.14.0-1
ii  python-gi-cairo  3.14.0-1
ii  python-ipaddr2.1.11-2
ii  python-libvirt   1.2.9-1
ii  python-urlgrabber3.9.1-4.1
pn  python2.7:anynone
pn  python:any   none
ii  virtinst 1:1.0.1-4

Versions of packages virt-manager recommends:
ii  gir1.2-spice-client-gtk-3.0  0.25-1+b1
ii  gnome-icon-theme 3.12.0-1
ii  libvirt-daemon-system1.2.9-9

Versions of packages virt-manager suggests:
ii  gnome-keyring3.14.0-1+b1
ii  python-gnomekeyring  2.32.0+dfsg-3
pn  python-guestfs   none
ii  ssh-askpass  1:1.2.4.1-9
ii  virt-viewer  1.0-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780735: icedove: Segfault at startup, even in safe mode

[Vincent Danjean]

Package: icedove
Version: 36.0~b1-1
Severity: serious
Justification: Segfault at startup

  After installing the last experimental version (36.0~b1-1), icedove
segfault at startup, even in safe mode.
  Previous installed version (34.0~b1-2) worked correctly.

  Here is bellow a gdb backtrace of icedove in safe mode :
vdanjean@eyak:~/.icedove/5idnx5md.default$ gdb /usr/lib/icedove/icedove-bin 
core 
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
Type show configuration for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type help.
Type apropos word to search for commands related to word...
Reading symbols from /usr/lib/icedove/icedove-bin...Reading symbols from 
/usr/lib/debug//usr/lib/icedove/icedove-bin...done.
done.

warning: core file may not match specified executable file.
[New LWP 31559]
[New LWP 31562]
[New LWP 31563]
[New LWP 31564]
[New LWP 31565]
[New LWP 31568]
[New LWP 31561]
[New LWP 31586]
[New LWP 31590]
[New LWP 31570]
[New LWP 31566]
[New LWP 31577]
[New LWP 31573]
[New LWP 31581]
[New LWP 31571]
[New LWP 31618]
[New LWP 31587]
[New LWP 31572]
[New LWP 31567]
[New LWP 31580]
[New LWP 31576]
[New LWP 31614]
[New LWP 31574]
[New LWP 31619]
[New LWP 31569]
[New LWP 31607]
[New LWP 31600]
[New LWP 31609]
[New LWP 31582]
[New LWP 31575]
[New LWP 31585]
[New LWP 31623]
[New LWP 31616]
[New LWP 31584]
[New LWP 31588]
[New LWP 31589]
[New LWP 31608]
[New LWP 31595]
[New LWP 31591]
[New LWP 31615]
[New LWP 31578]
[New LWP 31617]
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
bt
Core was generated by `icedove -safe-mode'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x77bce79b in raise (sig=11) at 
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
37  ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: Aucun fichier ou dossier de 
ce type.
(gdb) bt
#0  0x77bce79b in raise (sig=11) at 
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1  0x73205f19 in nsProfileLock::FatalSignalHandler (signo=11, 
info=0x7fffa430, context=0x7fffa300)
at 
/build/icedove-T8nlns/icedove-36.0~b1/mozilla/profile/dirserviceprovider/nsProfileLock.cpp:180
#2  signal handler called
#3  0x71dd69fe in memcpy (__len=1624, __src=0x0, __dest=0x7fffba5a6808)
at /usr/include/x86_64-linux-gnu/bits/string3.h:51
#4  implementationnsISupports*, nsISupports*, unsigned long, unsigned long 
(aValues=0x0, aCount=203, aStart=0, 
aElements=0x7fffba5a6808) at 
/build/icedove-T8nlns/icedove-36.0~b1/mozilla/xpcom/glue/nsTArray.h:525
#5  AssignRangensISupports* (aValues=0x0, aCount=203, aStart=0, 
this=0x7fffa960)
at /build/icedove-T8nlns/icedove-36.0~b1/mozilla/xpcom/glue/nsTArray.h:1712
#6  nsTArray_ImplnsISupports*, 
nsTArrayInfallibleAllocator::AppendElementsnsISupports* 
(this=this@entry=0x7fffa960, 
aArray=aArray@entry=0x0, aArrayLen=aArrayLen@entry=203)
at /build/icedove-T8nlns/icedove-36.0~b1/mozilla/xpcom/glue/nsTArray.h:1314
#7  0x71dd7026 in nsCOMArray_base::Adopt (this=0x7fffa960, 
aElements=0x0, aSize=203)
at 
/build/icedove-T8nlns/icedove-36.0~b1/mozilla/xpcom/glue/nsCOMArray.cpp:316
#8  0x71d2ca61 in Adopt (aSize=optimized out, aElements=optimized 
out, this=0x7fffa960)
at ../../../dist/include/nsCOMArray.h:434
#9  mozilla::mailnews::EncodedHeader (aHeader=..., aCharset=0x7fffca7319c8 
ISO-8859-1)
at 
/build/icedove-T8nlns/icedove-36.0~b1/mailnews/mime/src/MimeHeaderParser.cpp:95
#10 0x71bb4565 in nsMsgDBView::FetchAuthor 
(this=this@entry=0x7fffbd2ab000, aHdr=0x7fffbcf0d040, aSenderString=...)
at 
/build/icedove-T8nlns/icedove-36.0~b1/mailnews/base/src/nsMsgDBView.cpp:406
#11 0x71bbebdf in nsMsgDBView::CellTextForColumn 
(this=this@entry=0x7fffbd2ab000, aRow=aRow@entry=573, 
aColumnName=aColumnName@entry=0x7fffd3404748 usenderCol, aValue=...)
at 
/build/icedove-T8nlns/icedove-36.0~b1/mailnews/base/src/nsMsgDBView.cpp:1948
#12 0x71bd0041 in nsMsgGroupView::CellTextForColumn 
(this=0x7fffbd2ab000, aRow=573, 
aColumnName=0x7fffd3404748 usenderCol, aValue=...)
at 
/build/icedove-T8nlns/icedove-36.0~b1/mailnews/base/src/nsMsgGroupView.cpp:882
#13 0x71bb3cbb in nsMsgDBView::GetCellText (this=0x7fffbd2ab000, 
aRow=573, aCol=0x7fffbab473c0, aValue=...)
at 
/build/icedove-T8nlns/icedove-36.0~b1/mailnews/base/src/nsMsgDBView.cpp:1924
#14 0x72f7146a in nsTreeBodyFrame::PaintText 

Bug#774815: php-monolog: Versionned Provides field

[Vincent Danjean]

On 08/01/2015 00:44, David Prévot wrote:
 On Wed, Jan 07, 2015 at 10:23:24PM +0100, Vincent Danjean wrote:
 Package: php-monolog
 Version: 1.12.0-1
 Severity: serious
 Justification: Policy 7.1

   Your package in experimental declare a versionned Provides field.
 
 Indeed, as supported by apt since 1.0.7 (#758153) and dpkg since
 1.17.11.

I'm very glad to learn that this feature seems supported by
apt and dpkg now. I did not know.


 It is wrong
 
 Not really, but the lack of support in (soon to be old)stable makes it
 annoying.

It also against the current policy:
From https://www.debian.org/doc/debian-policy/ch-relationships.html:
 All of the fields except for Provides may restrict their applicability to
 particular versions of each named package.

So a bug should probably be filled against the policy (and then against
lintian to remove or fix the current check).

   This bug is present for one week. Can you correct it quickly? The reason
 is that apt-get complain about it:
 
 There are at least three other options I can think of:
 - not using an experimental repository in a stable environment;
 - using a more recent apt on machine where an experimental repository is
   needed;

Note that using experimental (ie installing packages from experimental)
is not required to suffer from the problem. Just having experimental
in sources.list is enough.

 - make apt (or apticron) ignore such error and get this change accepted
   in the next stable update.

As the relation ship was not an error as I was thinking but
the use of a new future feature, I will find local workaround.

 The third possibility may make sense in the near future, so we can start
 benefiting of this feature early in Strech development, without people
 using Wheezy being bored by the same kind of error messages if they have
 an unstable or testing repository in their sources.list
 
   I agree that, per se, this bug is a very little bug for php-monolog
 
 Indeed, keeping it open if you wish to reassign it to apt.
 (“bts reopen 758153 , reassign 774815 apt , forcemerge 758153 774815 , \
   affects 758153 php-monolog” could be another option.)

I do not have enough time today. If nobody does it before, I will try
to do it in a few days (and also opening bugs against policy and lintian)

  Regards,
Vincent

 Regards
 
 David
 


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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774815: php-monolog: Versionned Provides field

[Vincent Danjean]

Package: php-monolog
Version: 1.12.0-1
Severity: serious
Justification: Policy 7.1

  Hi,

  Your package in experimental declare a versionned Provides field.
It is wrong, and this has been catched by lintian:
https://lintian.debian.org/maintainer/pkg-php-p...@lists.alioth.debian.org.html#php-monolog
https://lintian.debian.org/tags/versioned-provides.html

  This bug is present for one week. Can you correct it quickly? The reason
is that apt-get complain about it:
# apt-get update
[...]
W: Ignoring Provides line with DepCompareOp for package 
php-psr-log-implementation
W: Vous pouvez lancer « apt-get update » pour corriger ces problèmes.
#

  So, for one week, for each machine where I use apticron with the
experimental repo listed in my sources, I get a mail per day about this error.

  I agree that, per se, this bug is a very little bug for php-monolog (ie no
local consequences). But, as it is catched by apt-get and leads to spurious
output, it has consequences on other unrelated software (especially apticron in
my case). So I would be very pleased if you can fix it quickly.

  Regards,
Vincent

-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 3.18.0-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774080: udev: /dev/dvd symlink changed while a program using it was running

[Vincent Danjean]

reopen #774080
thanks

On 28/12/2014 15:40, m...@linux.it (Marco d'Itri) wrote:
 On Dec 28, Vincent Danjean vdanj...@debian.org wrote:
 
 In my situation, inserting a CD in the second hardware should not have 
 modified the /dev/dvd symlink that was used by a script and that was 
 pointing to a valid device.
 Sorry, I do not think that there is anything we can do about this.

There is no way to avoid to modify an existing valid symlink?

This is a pity, but, if this is really the case, you can at least
document the situation (hence the reopen). As said initially,
jessie fresh install wont even have a 70-persistent-cd.rules template
to adapt to workaround the bug.
  Hiding/closing the bug wont dismiss it. And, when it hits me, it
tooks me some times to identify it whereas I think I'm not so bad
about system administration.
  Having /dev/dvd that flips depending on the last inserted disk
is really silly.

  Regards,
Vincent

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773232: libjpeg-progs: Try to override files from other package at upgrade

[Vincent Danjean]

Package: libjpeg-progs
Version: 1:9a-2
Severity: grave
Justification: renders package unusable

  On upgrade, libjpeg-progs tries to override a file from the (old)
libjpeg-turbo-progs (see the apt log below).
  Even if libjpeg-turbo-progs is scheduled to be removed, it is not yet removed
at unpack time of libjpeg-progs. A Replaces (+Breaks?) relationship is
probably missing.

  Regards,
Vincent

APT log:
# apt-get dist-upgrade
[...]
Préparation du dépaquetage de .../libjpeg-progs_1%3a9a-2_amd64.deb ...
Dépaquetage de libjpeg-progs (1:9a-2) sur (1:1.3.1-3) ...
dpkg: erreur de traitement de l'archive 
/var/cache/apt/archives/libjpeg-progs_1%3a9a-2_amd64.deb (--unpack) :
 tentative de remplacement de « /usr/share/man/man1/djpeg.1.gz », qui 
appartient aussi au paquet libjpeg-turbo-progs 1:1.3.1-3
Traitement des actions différées (« triggers ») pour man-db (2.7.0.2-2) ...
Des erreurs ont été rencontrées pendant l'exécution :
 /var/cache/apt/archives/libjpeg-progs_1%3a9a-2_amd64.deb


-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

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

Versions of packages libjpeg-progs depends on:
ii  libc6 2.19-13
ii  libjpeg9  1:9a-2

libjpeg-progs recommends no packages.

libjpeg-progs suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773232: libjpeg-progs: Try to override files from other package at upgradeo

[Vincent Danjean]

  Hi Bill,

On 15/12/2014 21:54, Bill Allombert wrote:
 On Mon, Dec 15, 2014 at 09:41:28PM +0100, Vincent Danjean wrote:
   On upgrade, libjpeg-progs tries to override a file from the (old)
 libjpeg-turbo-progs (see the apt log below).
 
 Hello Vincent,
 libjpeg-turbo-progs is not part of wheezy.
 The version of libjpeg-turbo-progs you have installed on your system
 is RC buggy and has been superseded by a fixed version.
 libjpeg-progs is not strictly required to cover for old broken
 packages in testing that never went to a stable release.

Even if it is possible, I do not recall having manually installed
libjpeg-turbo-progs. So, it probably comes from a dependency in
a partial upgrade to testing.
  In any case, partial upgrade from testing to testing must be
supported by Debian. And the fix is really simple.

  That said, I agree that the bug will hit far less people than
what I though initially. So do what you want/what the release team
wants.

  For my part, I succeeded in completing my upgrade with the
help of --force-depends of dpkg (to force the removal of
libjpeg-turbo-progs before installing the new version of
libjpeg-progs)

  Regards,
Vincent

 
 Cheers,
 Bill.
 


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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768115: ow-tools: fails to upgrade from 'wheezy' - trying to overwrite /usr/share/man/man1/owtap.1.gz

[Vincent Danjean]

  Hi,

On 05/11/2014 04:06, Andreas Beckmann wrote:
 during a test with piuparts I noticed your package fails to upgrade from
 'wheezy'.
 It installed fine in 'wheezy', then the upgrade to 'jessie' fails
 because it tries to overwrite other packages files without declaring a
 Breaks+Replaces relation.

  Thanks for the report. As this bug is in testing for a long time,
I will wait one day so that the unstable-testing transition of
2.9p8-4 occurs. Then I will upload a fix with Breaks+Replaces
added and ask for a freeze exception for this little modification.

  Regards
Vincent

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765371: owfs is marked for autoremoval from testing

[Vincent Danjean]

On 29/10/2014 05:39, Debian testing autoremoval watch wrote:
 owfs 2.9p5-1.1 is marked for autoremoval from testing on 2014-11-13
 
 It is affected by these RC bugs:
 765371: python-ow: Import fails - error parsing version (fixed upstream)

  Hi,

  This bug is fixed in unstable.
  I  did not take time to initially downgrade the bug severity as I did a quick
upload to unstable. However, due to problem with FreeBSD, I will probably
need to ask for a freeze exception.
  But, in any case, this bug is not a grave one. Python bindings are
only a very little aspect of owfs and a such a bug do not justify such
a severity.

  Regards,
Vincent

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#766242: dpkg: consumes all available RAM and crashes, during configure phase

[Vincent Danjean]

Package: dpkg
Version: 1.17.19
Followup-For: Bug #766242

  Hi,

  I'm also suffering from this bug. As I do not have dpkg symbols, the
gdb backtrace is not really useful. I give you nonetheless in case you
still have the debug symbols: with the adresses in the backtrace, you
will be able to find the functions.

  Note that I've been hit by this big several times today while doing a
relatively important upgrade on my system (about 900 packages). Sometimes (not
sure always), C-c does not do anything. I must kill (SIGTERM) dpkg to stop it.

  Regards,
Vincent

root@eyak:/home/vdanjean# gdb /usr/bin/dpkg  16442
GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
Type show configuration for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type help.
Type apropos word to search for commands related to word...
Reading symbols from /usr/bin/dpkg...(no debugging symbols found)...done.
Attaching to program: /usr/bin/dpkg, process 16442
Reading symbols from /lib/x86_64-linux-gnu/libselinux.so.1...(no debugging 
symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libselinux.so.1
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from 
/usr/lib/debug//lib/x86_64-linux-gnu/libc-2.19.so...done.
done.
Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6
Reading symbols from /lib/x86_64-linux-gnu/libpcre.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libpcre.so.3
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...Reading symbols from 
/usr/lib/debug//lib/x86_64-linux-gnu/libdl-2.19.so...done.
done.
Loaded symbols for /lib/x86_64-linux-gnu/libdl.so.2
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from 
/usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...Reading symbols 
from /usr/lib/debug//lib/x86_64-linux-gnu/libpthread-2.19.so...done.
done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
Loaded symbols for /lib/x86_64-linux-gnu/libpthread.so.0
0x004111eb in ?? ()
(gdb) bt
#0  0x004111eb in ?? ()
#1  0x004144cd in ?? ()
#2  0x00410849 in ?? ()
#3  0x00410ccf in ?? ()
#4  0x00403580 in ?? ()
#5  0x77830b45 in __libc_start_main (main=0x403400, argc=3, 
argv=0x7fffe6d8, init=optimized out, fini=optimized out, 
rtld_fini=optimized out, stack_end=0x7fffe6c8) at libc-start.c:287
#6  0x00403651 in ?? ()
(gdb) b sbrk
Breakpoint 1 at 0x778ed710: file sbrk.c, line 34.
(gdb) c
Continuing.

Breakpoint 1, __GI___sbrk (increment=135168) at sbrk.c:34
34  sbrk.c: Aucun fichier ou dossier de ce type.
(gdb) bt
#0  __GI___sbrk (increment=135168) at sbrk.c:34
#1  0x7788d5a9 in __GI___default_morecore (increment=optimized out) 
at morecore.c:47
#2  0x77889754 in sysmalloc (av=0x77bb1620 main_arena, nb=32) at 
malloc.c:2462
#3  _int_malloc (av=0x77bb1620 main_arena, bytes=24) at malloc.c:3800
#4  0x7788ae20 in __GI___libc_malloc (bytes=24) at malloc.c:2891
#5  0x0041d089 in ?? ()
#6  0x00409055 in ?? ()
#7  0x00411030 in ?? ()
#8  0x004144cd in ?? ()
#9  0x00410849 in ?? ()
#10 0x00410ccf in ?? ()
#11 0x00403580 in ?? ()
#12 0x77830b45 in __libc_start_main (main=0x403400, argc=3, 
argv=0x7fffe6d8, init=optimized out, fini=optimized out, 
rtld_fini=optimized out, stack_end=0x7fffe6c8) at libc-start.c:287
#13 0x00403651 in ?? ()
(gdb) info threads
  Id   Target Id Frame 
* 1Thread 0x77fb5800 (LWP 16442) dpkg __GI___sbrk (increment=135168) 
at sbrk.c:34


-- System Information:
Debian Release: jessie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armel
mipsel

Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-7
ii  libc62.19-11
ii  liblzma5 5.1.1alpha+20120614-2
ii  libselinux1  2.3-2
ii  tar  1.27.1-2
ii  zlib1g   1:1.2.8.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.0.9.3

Bug#766242: dpkg: consumes all available RAM and crashes, during configure phase

[Vincent Danjean]

Package: dpkg
Version: 1.17.19
Followup-For: Bug #766242

  Hi (again)

  Looking at the trace I sent you, it seems that the perl package was involve.
As any --configure call to dpkg (directly or indirectly with apt) was blocking,
I tried to manually explicitely configure perl:
njean@eyak:~$ sudo dpkg --configure perl
dpkg: des problèmes de dépendances empêchent la configuration de perl :
 perl dépend de perl-modules (= 5.20.1-2) ; cependant :
 Le paquet perl-modules n'est pas encore configuré.

dpkg: erreur de traitement du paquet perl (--configure) :
 problèmes de dépendances - laissé non configuré
Des erreurs ont été rencontrées pendant l'exécution :
 perl
vdanjean@eyak:~$ sudo dpkg --configure perl-modules
dpkg: des problèmes de dépendances empêchent la configuration de perl-modules :
 perl-modules dépend de perl (= 5.20.1-1) ; cependant :
 Le paquet perl n'est pas encore configuré.

dpkg: erreur de traitement du paquet perl-modules (--configure) :
 problèmes de dépendances - laissé non configuré
Des erreurs ont été rencontrées pendant l'exécution :
 perl-modules
vdanjean@eyak:~$ sudo dpkg --configure --force-depends perl-modules
Paramétrage de perl-modules (5.20.1-2) ...
vdanjean@eyak:~$ sudo dpkg --configure -a 
Paramétrage de perl (5.20.1-2) ...
Paramétrage de kdelibs5-data (4:4.14.2-1) ...
Paramétrage de kdelibs5-plugins (4:4.14.2-1) ...
Paramétrage de libimage-exiftool-perl (9.74-1) ...
Paramétrage de libmodule-corelist-perl (5.20141020-1) ...
[...]
Paramétrage de cups (1.7.5-5) ...
Updating PPD files for cups ...
Updating PPD files for foomatic-db-compressed-ppds ...
Traitement des actions différées (« triggers ») pour libc-bin (2.19-11) ...
Traitement des actions différées (« triggers ») pour menu (2.1.47) ...
vdanjean@eyak:~$ 

So, it works. The problem was triggered by the perl/perl-modules dependency
loop.

  Regards,
Vincent

-- System Information:
Debian Release: jessie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armel
mipsel

Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-7
ii  libc62.19-11
ii  liblzma5 5.1.1alpha+20120614-2
ii  libselinux1  2.3-2
ii  tar  1.27.1-2
ii  zlib1g   1:1.2.8.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.0.9.3

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764571: libpoclu-dev and uthash-dev: error when trying to install together

[Vincent Danjean]

  Hi,

On 10/10/2014 16:54, Bastian Blywis wrote:
 Dear Vincent,
 
 you can find an updated version of the package here if you need a more recent 
 one:
 http://mentors.debian.net/package/uthash

pocl is using versin 1.9.4 whereas Debian already have 1.9.7, so... ;-)
Moreover, after talking to pocl upstream, utlist.h is not used at all by
pocl headers. So I just remove the file from the pocl package.

 I will try to get in contact with my sponsor to get 1.9.9 (which
 is long overdue) released as soon as possible.

Ok. If your sponsor does not answer before Wednesday, contact me
so that I can upload your package in time before the freeze.

  Regards,
Vincent

 Kind regards,
 
 Bastian
 
 
 On 09.10.2014 09:06, Vincent Danjean wrote:
Hi,

 On 09/10/2014 08:28, Ralf Treinen wrote:
 Package: uthash-dev,libpoclu-dev
 Version: uthash-dev/1.9.7-1
 Version: libpoclu-dev/0.10-3
 Severity: serious
 User: trei...@debian.org
 Usertags: edos-file-overwrite
 Thank for the report. I think (I will check) that this is the same file.
 I did not know that this header was already packaged. I will remove
 it from libpoclu-dev and add a dependency.

Regards,
  Vincent

 Date: 2014-10-09
 Architecture: amd64
 Distribution: sid

 Hi,

 automatic installation tests of packages that share a file and at the
 same time do not conflict by their package dependency relationships has
 detected the following problem:


 Selecting previously unselected package ocl-icd-libopencl1:amd64.
 (Reading database ... 10872 files and directories currently installed.)
 Preparing to unpack .../ocl-icd-libopencl1_2.2.3-1_amd64.deb ...
 Unpacking ocl-icd-libopencl1:amd64 (2.2.3-1) ...
 Selecting previously unselected package libpoclu1:amd64.
 Preparing to unpack .../libpoclu1_0.10-3_amd64.deb ...
 Unpacking libpoclu1:amd64 (0.10-3) ...
 Selecting previously unselected package opencl-headers.
 Preparing to unpack .../opencl-headers_1.2-2014.04.13-1.1_all.deb ...
 Unpacking opencl-headers (1.2-2014.04.13-1.1) ...
 Selecting previously unselected package libpoclu-dev.
 Preparing to unpack .../libpoclu-dev_0.10-3_amd64.deb ...
 Unpacking libpoclu-dev (0.10-3) ...
 Selecting previously unselected package uthash-dev.
 Preparing to unpack .../uthash-dev_1.9.7-1_all.deb ...
 Unpacking uthash-dev (1.9.7-1) ...
 dpkg: error processing archive 
 /var/cache/apt/archives/uthash-dev_1.9.7-1_all.deb (--unpack):
   trying to overwrite '/usr/include/utlist.h', which is also in package 
 libpoclu-dev 0.10-3
 Processing triggers for man-db (2.7.0.2-1) ...
 Errors were encountered while processing:
   /var/cache/apt/archives/uthash-dev_1.9.7-1_all.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 cow-shell unlink .ilist: No such file or directory


 This is a serious bug as it makes installation fail, and violates
 sections 7.6.1 and 10.1 of the policy. An optimal solution would
 consist in only one of the packages installing that file, and renaming
 or removing the file in the other package. Depending on the
 circumstances you might also consider Replace relations or file
 diversions. If the conflicting situation cannot be resolved then, as a
 last resort, the two packages have to declare a mutual
 Conflict. Please take into account that Replaces, Conflicts and
 diversions should only be used when packages provide different
 implementations for the same functionality.

 Here is a list of files that are known to be shared by both packages
 (according to the Contents file for sid/amd64, which may be
 slightly out of sync):

/usr/include/utlist.h

 This bug has been filed against both packages. If you, the maintainers of
 the two packages in question, have agreed on which of the packages will
 resolve the problem please reassign the bug to that package. You may then
 also register in the BTS that the other package is affected by the bug.

 -Ralf.

 PS: for more information about the detection of file overwrite errors
 of this kind see http://edos.debian.net/file-overwrites/.


 


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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764571: libpoclu-dev and uthash-dev: error when trying to install together

[Vincent Danjean]

  Hi,

On 09/10/2014 08:28, Ralf Treinen wrote:
 Package: uthash-dev,libpoclu-dev
 Version: uthash-dev/1.9.7-1
 Version: libpoclu-dev/0.10-3
 Severity: serious
 User: trei...@debian.org
 Usertags: edos-file-overwrite

Thank for the report. I think (I will check) that this is the same file.
I did not know that this header was already packaged. I will remove
it from libpoclu-dev and add a dependency.

  Regards,
Vincent

 Date: 2014-10-09
 Architecture: amd64
 Distribution: sid
 
 Hi,
 
 automatic installation tests of packages that share a file and at the
 same time do not conflict by their package dependency relationships has
 detected the following problem:
 
 
 Selecting previously unselected package ocl-icd-libopencl1:amd64.
 (Reading database ... 10872 files and directories currently installed.)
 Preparing to unpack .../ocl-icd-libopencl1_2.2.3-1_amd64.deb ...
 Unpacking ocl-icd-libopencl1:amd64 (2.2.3-1) ...
 Selecting previously unselected package libpoclu1:amd64.
 Preparing to unpack .../libpoclu1_0.10-3_amd64.deb ...
 Unpacking libpoclu1:amd64 (0.10-3) ...
 Selecting previously unselected package opencl-headers.
 Preparing to unpack .../opencl-headers_1.2-2014.04.13-1.1_all.deb ...
 Unpacking opencl-headers (1.2-2014.04.13-1.1) ...
 Selecting previously unselected package libpoclu-dev.
 Preparing to unpack .../libpoclu-dev_0.10-3_amd64.deb ...
 Unpacking libpoclu-dev (0.10-3) ...
 Selecting previously unselected package uthash-dev.
 Preparing to unpack .../uthash-dev_1.9.7-1_all.deb ...
 Unpacking uthash-dev (1.9.7-1) ...
 dpkg: error processing archive 
 /var/cache/apt/archives/uthash-dev_1.9.7-1_all.deb (--unpack):
  trying to overwrite '/usr/include/utlist.h', which is also in package 
 libpoclu-dev 0.10-3
 Processing triggers for man-db (2.7.0.2-1) ...
 Errors were encountered while processing:
  /var/cache/apt/archives/uthash-dev_1.9.7-1_all.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 cow-shell unlink .ilist: No such file or directory
 
 
 This is a serious bug as it makes installation fail, and violates
 sections 7.6.1 and 10.1 of the policy. An optimal solution would
 consist in only one of the packages installing that file, and renaming
 or removing the file in the other package. Depending on the
 circumstances you might also consider Replace relations or file
 diversions. If the conflicting situation cannot be resolved then, as a
 last resort, the two packages have to declare a mutual
 Conflict. Please take into account that Replaces, Conflicts and
 diversions should only be used when packages provide different
 implementations for the same functionality.
 
 Here is a list of files that are known to be shared by both packages
 (according to the Contents file for sid/amd64, which may be
 slightly out of sync):
 
   /usr/include/utlist.h
 
 This bug has been filed against both packages. If you, the maintainers of
 the two packages in question, have agreed on which of the packages will
 resolve the problem please reassign the bug to that package. You may then
 also register in the BTS that the other package is affected by the bug.
 
 -Ralf.
 
 PS: for more information about the detection of file overwrite errors
 of this kind see http://edos.debian.net/file-overwrites/.
 


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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764561: Bug#764563: pocl: FTBFS: test suite errors and FTBFS on ppc64el

[Vincent Danjean]

  Hi,

On 09/10/2014 04:57, Aaron M. Ucko wrote:
 Source: pocl
 Version: 0.10-3
 Severity: serious
 Justification: fails to build from source
 
 The builds of pocl for i386 and (32-bit) powerpc both failed with test
 suite errors: three unexpected failures on i386 and 80 (!) on
 powerpc.  Could you please take a look?  You can find the full logs at
 
 https://buildd.debian.org/status/logs.php?pkg=poclver=0.10-3suite=sid
 
 (So far, most of the remaining failures were due to pocl's configure
 script rejecting the architecture as unsupported; you might want to
 tighten its architecture field in debian/control accordingly.)

Thank for your report. As pocl is a new package, do you really think
it deserve a serious bug (that block migration to testing?) Upstream
is really interested on the results (they cannot test pocl on all Debian
architecture before) but if bugs are filled with a serious severity I will
immediately completely disable non standard architectures in order
to allow pocl in jessie (and the work to try to support other architectures
will be done after jessie release instead of before the freeze).

  Regards,
Vincent

 Thanks!
 


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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762224: clang: Breaks but forgot to Replaces clang-3.3

[Vincent Danjean]

Package: clang
Version: 1:3.4-23
Severity: serious
Justification: break upgrades

  Hi,

  In unstable/testing, clang is missing the Replaces of clang-3.3 (it seems
fixed in experimental) and that can lead to upgrade aborted as shown in the
following example:

vdanjean@eyak:~/debian/mainteneur/system-utils/upstream/git$ sudo apt-get 
install clang
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances   
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés : 
  clang-3.4 libclang-common-3.4-dev
Paquets suggérés :
  gnustep gnustep-devel clang-3.4-doc
Les paquets suivants seront ENLEVÉS :
  clang-3.3
Les NOUVEAUX paquets suivants seront installés :
  clang-3.4 libclang-common-3.4-dev
Les paquets suivants seront mis à jour :
  clang
1 mis à jour, 2 nouvellement installés, 1 à enlever et 1 non mis à jour.
Il est nécessaire de prendre 19,7 Mo dans les archives.
Après cette opération, 46,3 Mo d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] 
Réception de : 1 http://ftp.fr.debian.org/debian/ testing/main 
libclang-common-3.4-dev amd64 1:3.4.2-8 [542 kB]
Réception de : 2 http://ftp.fr.debian.org/debian/ testing/main clang amd64 
1:3.4-23 [4 792 B]
Réception de : 3 http://ftp.fr.debian.org/debian/ testing/main clang-3.4 amd64 
1:3.4.2-8 [19,2 MB]
19,7 Mo réceptionnés en 21s (933 ko/s)  

   
Récupération des rapports de bogue… Fait
Analyse des informations Trouvé/Corrigé… Fait
Bogues de gravité grave sur clang-3.4 (→ 1:3.4.2-8) Resolved in some Version
 b1 - #759303 - Does not have multiarch include paths on !linux (Corrigé : 
llvm-toolchain-3.4/1:3.4.2-9~exp2 llvm-toolchain-3.5/1:3.5-2~exp1)
Résumé :
 clang-3.4(1 bogue)
Êtes-vous certain de vouloir installer/mettre à jour les paquets ci-dessus ? 
[Y/n/?/...] 
Lecture des fichiers de modifications (« changelog »)... Terminé 
Sélection du paquet libclang-common-3.4-dev précédemment désélectionné.
(Lecture de la base de données... 608307 fichiers et répertoires déjà 
installés.)
Préparation du dépaquetage de .../libclang-common-3.4-dev_1%3a3.4.2-8_amd64.deb 
...
Dépaquetage de libclang-common-3.4-dev (1:3.4.2-8) ...
Préparation du dépaquetage de .../clang_1%3a3.4-23_amd64.deb ...
Dépaquetage de clang (1:3.4-23) sur (1:3.3-21+nmu1) ...
dpkg: erreur de traitement de l'archive 
/var/cache/apt/archives/clang_1%3a3.4-23_amd64.deb (--unpack) :
 tentative de remplacement de « /usr/bin/clang-tblgen », qui appartient aussi 
au paquet clang-3.3 1:3.3-16
Traitement des actions différées (« triggers ») pour debian-security-support 
(2014.09.07) ...
Traitement des actions différées (« triggers ») pour man-db (2.6.7.1-1) ...
Des erreurs ont été rencontrées pendant l'exécution :
 /var/cache/apt/archives/clang_1%3a3.4-23_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
vdanjean@eyak:~/debian/mainteneur/system-utils/upstream/git$ 

  Regards,
Vincent

-- System Information:
Debian Release: jessie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armel
mipsel

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

Versions of packages clang depends on:
ii  clang-3.3  1:3.3-16

clang recommends no packages.

clang suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755513: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

[Vincent Danjean]

On 02/09/2014 16:43, Graham Inggs wrote:
 On 01/09/2014 17:00, Vincent Danjean wrote:
 Here is what I put in the package I will upload this evening:

 Package: ocl-icd-opencl-dev
 [...]
 Conflicts: opencl-dev
 Breaks: ocl-icd-libopencl1 ( 2.1.3-5~), nvidia-libopencl1 (304.88-7~), 
 amd-libopencl1 (1:13.4-4~)
 Replaces: opencl-dev, ocl-icd-libopencl1 ( 2.1.3-5~), nvidia-libopencl1 
 (304.88-7~), amd-libopencl1 (1:13.4-4~)
 [...]

 Version number are based on the data you provide into the bugreport
 (thank you very much for this). nvidia-opencl-dev and
 amd-opencl-dev probably needs both the same list of
 Conflicts/Breaks/Replaces wrt. the libOpenCL.so symlink move.
 
 I'm pretty sure nvidia-opencl-dev and amd-opencl-dev will only need:
 
 Breaks: ocl-icd-libopencl1 ( 2.1.3-5~)
 Replaces: ocl-icd-libopencl1 ( 2.1.3-5~)
 
 ...as they already conflict on each other because of the opencl-dev
 virtual package, and conflicts is a stronger relationship than
 breaks/replaces.

Yes for -dev packages. But what if a user with nvidia-libopencl1/stable
installed (ie *not* the -dev package) tries to install
amd-opencl-dev/testing ?
Are you sure that nvidia-libopencl1 will be removed (not just
unconfigurated) before amd-opencl-dev is unpacked ?

Both nvidia-libopencl1/stable and amd-opencl-dev/testing contains
the .so symlink.

  Regards,
Vincent

PS: note that policy 7.6.2 gives as example the mail-transport-agent
virtual package where Provides, Conflicts *and* Replaces are used.

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755513: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

[Vincent Danjean]

On 19/08/2014 15:52, Graham Inggs wrote:
 Hi Vincent
 
 I am preparing a NMU for bug #757961 in nvidia-cuda-toolkit and I'd like to 
 include a fix for #755513 if needed.
 Since Intel are now shipping libOpenCL.so.1.2, can libOpenCL.so be moved from 
 ocl-icd-libopencl1 to ocl-icd-opencl-dev?
 
 Are the following changes what is needed for nvidia-opencl-dev and 
 amd-opencl-dev?
 
 Breaks: ocl-icd-libopencl1 ( 2.1.3-5)
 Replaces: ocl-icd-libopencl1 ( 2.1.3-5)

Add a tilde to allow backports.

Here is what I put in the package I will upload this evening:

Package: ocl-icd-opencl-dev
[...]
Conflicts: opencl-dev
Breaks: ocl-icd-libopencl1 ( 2.1.3-5~), nvidia-libopencl1 (304.88-7~), 
amd-libopencl1 (1:13.4-4~)
Replaces: opencl-dev, ocl-icd-libopencl1 ( 2.1.3-5~), nvidia-libopencl1 
(304.88-7~), amd-libopencl1 (1:13.4-4~)
[...]

Version number are based on the data you provide into the bugreport
(thank you very much for this). nvidia-opencl-dev and
amd-opencl-dev probably needs both the same list of
Conflicts/Breaks/Replaces wrt. the libOpenCL.so symlink move.

 Would you be willing to sponsor my upload?

  Yes, I can do it if regular maintainers do not oppose and do
not react to your proposed patch.

  Regards,
Vincent

 Regards
 Graham


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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755513: Processed: Re: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

[Vincent Danjean]

On 13/08/2014 20:00, Graham Inggs wrote:
 Is this correct?

Sorry, I was on vacations without Internet access. I will read all my
mails. You can expect answers and/or new upload for ocl-icd in a
few days.

  Regards,
Vincent

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755513: Processed: Re: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

[Vincent Danjean]

On 09/08/2014 10:21, Graham Inggs wrote:
 Considering that by shipping libOpenCL.so, ocl-icd-libopencl1 is the
 package breaking policy, and that you indicated libOpenCL.so might
 move to the ocl-icd-opencl-dev package, I believe it is simpler for
 this bug to be fixed in ocl-icd-libopencl1 alone without affecting
 amd-opencl-dev and nvidia-opencl-dev as well.

  I agree with you about the fix to get a proper testing.
  However, in order to ensure a smooth upgrade from stable to
testing, we need in addition 'Replaces' (possibly versionned)
in all new (testing) packages. Conflicts or Breaks are not enough.

  Regards,
Vincent

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757571: owfs: FTBFS on kfreebsd-*

[Vincent Danjean]

On 09/08/2014 15:34, Sebastian Ramacher wrote:
 Source: owfs
 Version: 2.9p5-1
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)
 
 owfs failed to build on kfreebsd-* with symbol errors:
 | dh_makeshlibs --no-package libow-php5 --no-package libow-tcl
 | dpkg-gensymbols: warning: some symbols or patterns disappeared in the 
 symbols file: see diff output below
 | dpkg-gensymbols: warning: debian/libow-2.9-5/DEBIAN/symbols doesn't match 
 completely debian/libow-2.9-5.symbols
 | --- debian/libow-2.9-5.symbols (libow-2.9-5_2.9p5-1_kfreebsd-amd64)
 | +++ dpkg-gensymbolsmVBLFz   2014-08-07 04:19:46.0 +
 | @@ -180,7 +180,7 @@
 |   DNSServiceRefSockFD@Base 2.8p4
 |   DNSServiceRegister@Base 2.8p4
 |   DNSServiceResolve@Base 2.8p4
 | - DS1410_detect@Base 2.8p4
 | +#MISSING: 2.9p5-1# DS1410_detect@Base 2.8p4

Argh. I do not know why this symbol is not here for this
architecture. That said, as all soname are new, a quick fix
is to update the symbols files for architectures that require
it for this new upstream version.
  I wont be able to work on it until 2 weeks (and I not sure I
will be even able to read my mail). So 0-days NMU are welcome.

  Regards,
Vincent

 |   DS2480_detect@Base 2.8p4
 |   DS2480_level_docheck_errors@Base 2.8p4
 |   DS2480_read_fd_isset@Base 2.8p4
 | Use of uninitialized value in numeric eq (==) at /usr/bin/dh_makeshlibs 
 line 251.
 | Use of uninitialized value in numeric eq (==) at /usr/bin/dh_makeshlibs 
 line 251.
 | dh_makeshlibs: failing due to earlier errors
 | make[1]: *** [override_dh_makeshlibs] Error 2
 
 Full build logs are available from
 https://buildd.debian.org/status/logs.php?pkg=owfsver=2.9p5-1. Please
 take  look.
 
 Cheers
 


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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755513: Processed: Re: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

[Vincent Danjean]

  Hi,

  I do not understand this reassign.

On 08/08/2014 17:03, Debian Bug Tracking System wrote:
 Processing commands for cont...@bugs.debian.org:
 
 reassign 755513 ocl-icd-libopencl1 2.1.0-1
 Bug #755513 [nvidia-opencl-dev,ocl-icd-libopencl1] nvidia-opencl-dev: binary 
 conflict with ocl-icd-libopencl1
 Bug reassigned from package 'nvidia-opencl-dev,ocl-icd-libopencl1' to 
 'ocl-icd-libopencl1'.
 No longer marked as found in versions ocl-icd-libopencl1/2.1.3-4 and 
 nvidia-opencl-dev/5.5.22-4.

For what I remember, both these packages have the libOpenCL.so file
so they are buggy (should declare a conflict directly or indirectly)

 Ignoring request to alter fixed versions of bug #755513 to the same values 
 previously set
 Bug #755513 [ocl-icd-libopencl1] nvidia-opencl-dev: binary conflict with 
 ocl-icd-libopencl1
 Marked as found in versions ocl-icd/2.1.0-1.

There is nothing new in this package related to this problem.

  So, please, explain your reassign or revert it back.

  Regards,
Vincent

 thanks
 Stopping processing here.
 
 Please contact me if you need assistance.
 


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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755513: Bug#679228: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

[Vincent Danjean]

On 30/07/2014 20:13, Graham Inggs wrote:
 Hi Vincent
 
 On 30 July 2014 18:23, Vincent Danjean vdanjean...@free.fr wrote:
   As this bug remains me this situation, I'm proposing that we move
 the libOpenCL.so symlink into the dev package.
[...]
   If you agree, we will have to go through all OpenCL packages to
 put correct conflicts/replaces where required.
 
 What changes would be required to all OpenCL packages if you moved the
 libOpenCL.so symlink into the dev package?
 
 Surely if ocl-icd-libopencl1 ships libOpenCL.so then it should
 conflict with all other opencl -dev packages (i.e. those that also
 ship libOpenCL.so), and if it stops shipping libOpenCL.so then it is
 just a matter of removing those conflicts?

all *-libopencl1 conflict/replace themselves as they provide the same
binary (libOpenCL.so.1)
And we need to put the correct conflict/replace for the libOpenCL.so.
It is not hard but this file is (was?) not handled the same way by all
OpenCL packagers. It is just a matter to list all packages (in wheezy
and testing) that provide it. This will avoid to wait for users to
detect missing conflict/replace and upload fixed packages.

  Regards
Vincent

 Regards
 Graham
 


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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755513: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

[Vincent Danjean]

  Hi,

  In #755513, there is a missing 'replaces' about the libopencl.so
file.
  Due to Intel (see #679228), ocl-icd ship the libOpenCL.so symlink
into the ocl-icd-libopencl package (ie the lib package, not the
development package).

  As this bug remains me this situation, I'm proposing that we move
the libOpenCL.so symlink into the dev package. Intel told me long
ago that they will fix their license so that we can redistribute
their implementation. But nothing occurs to my knowledge.
  Moreover, it would be easy to document what need to be fixed
(ie add a libOpenCL.so symlink or install an OpenCL dev package) in
order to execute binary compiled with the Intel OpenCL environment.
We will gain a cleaner situation about OpenCL file layout with
respect to the library packaging.

  If you agree, we will have to go through all OpenCL packages to
put correct conflicts/replaces where required.

  Regards,
Vincent

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752804: Perl 5.20 transition imminent

[Vincent Danjean]

  Hi,

On 28/07/2014 22:37, Damyan Ivanov wrote:
 Control: severity -1 serious
 
 Perl 5.20 is planned to hit unstable around the 12th of August, at which
 point your package will become unbuildable and/or uninstallable.
 
 We plan to start doing NMUs to DELAYED/5 of all the packages which have
 a patch attached on or about 2nd of August, but a maintainer upload
 would be warmly appreciated.

  I will take care of the upload this WE (together with a new upstream
version). The package is nearly ready.

  Regards,
Vincent

 -- dam
Debian Perl Group
 


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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749797: papi: FTBFS as non-root: ldconfig not in PATH

[Vincent Danjean]

severity #749797 whishbug
thanks

On 29/05/2014 23:06, Michael Tautschnig wrote:
 Package: papi
 Version: 5.3.0-3
 Severity: serious

Are you kidding ?
If you build a package in a non-standard environment, there is
no certitude that it will build correctly. There is way too much
building environments to support all of them.
  You might ask for support for another one with a whishbug
but do to try to remove the software from Debian if it does not
build in your non-standard environment!

  Note that using fakeroot should be a very quick workaround and
I'm sure that *lots* of packages do not build without fakeroot.

 As non-root builds should not fail,

  Where does this should come from? Policy?
  And *non-root build does not fail* if you use fakeroot (I never
build my packages as root myself!) and it should  probably also work
(not tested) if /sbin is added in your PATH.

 please use the full path here.

  I'm really not convinced with your argument. If I do this
modification, it wont be possible to test another ldconfig
implementation with just adjusting the PATH envvar.

  Regards,
Vincent

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749797: papi: FTBFS as non-root: ldconfig not in PATH

[Vincent Danjean]

  Hi,

On 30/05/2014 11:47, Michael Tautschnig wrote:
 Hello Vincent,
 
 [...]
 Are you kidding ? If you build a package in a non-standard environment, 
 there is no certitude that it will build correctly. There is way too much 
 building environments to support all of them. You might ask for support for 
 another one with a whishbug but do to try to remove the software from Debian 
 if it does not build in your non-standard environment!
 
 I'm well aware that there may be specifics to my build environment and 
 certainly I wouldn't have filed an RC bug if it were to be attributed to such 
 an aspect.

The fact is that, to my knowledge, the package successfully builds
on all Debian build machines.
  Note that I was not arguing against the fact that this is a bug,
only about the severity. Seeing with your answer that the bug is still
there with dpkg-buildpackage -rfakeroot I would give it the normal
or important severity. But not more (ie not RC) as official Debian
build machine correctly work.

 Well, the change was just a proposal, you might want to go for an entirely 
 different solution. (Indeed I'm not sure why ldconfig is being run at all.)

Look at the sources, I'm not sure myself. The call has been added
by Andreas so I will wait for him to comment.

  Regards,
Vincent

 So let's try to work out the (non-)standard build environment first. Here's 
 what I now did:
 
 ssh m...@barriere.debian.org (pick any porterbox of your choice) schroot -c 
 sid (install wget, build-deps of papi) dget 
 http://ftp.de.debian.org/debian/pool/main/p/papi/papi_5.3.0-3.dsc dpkg-source 
 -x *.dsc cd papi-5.3.0/ dpkg-buildpackage -rfakeroot (...) make[1]: Entering 
 directory '/home/mt/papi-5.3.0' find 
 debian/libpapi5.3/usr/lib/x86_64-linux-gnu -type l -name 'libpapi.so.*' | 
 xargs -r rm -v removed 
 'debian/libpapi5.3/usr/lib/x86_64-linux-gnu/libpapi.so.5.3.0' removed 
 'debian/libpapi5.3/usr/lib/x86_64-linux-gnu/libpapi.so.5' ldconfig -n -v 
 debian/libpapi5.3/usr/lib/x86_64-linux-gnu make[1]: ldconfig: Command not 
 found debian/rules:46: recipe for target 'override_dh_shlibdeps' failed 
 make[1]: *** [override_dh_shlibdeps] Error 127 make[1]: Leaving directory 
 '/home/mt/papi-5.3.0' debian/rules:24: recipe for target 'binary' failed 
 make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules 
 binary gave error exit status 2 (sid_amd64-dchroot)mt@barriere:~/papi-5.3.0$
 
 
 In my opinion that should qualify as a standard build environment, but 
 arguably it's not sbuild.
 
 Thanks a lot, Michael
 


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#747720: FTBFS: install: cannot stat './libOpenCL.html': No such file or directory

[Vincent Danjean]

severity 747720 minor
block 747720 by 747078
thanks

On 11/05/2014 14:09, Christian Hofstaedtler wrote:
 Dear Maintainer,
 
 During a rebuild of ruby-related packages your package failed to
 build with these errors:
[...]
 Makefile:366: recipe for target 'install-htmldocDATA' failed
  /usr/bin/install -c -m 644 ./libOpenCL.7 ./libOpenCL.so.7 
 '/«PKGBUILDDIR»/debian/tmp/usr/share/man/man7'
 /usr/bin/install: cannot stat './libOpenCL.7': No such file or directory
 /usr/bin/install: cannot stat './libOpenCL.so.7': No such file or directory
 make[4]: *** [install-man7] Error 1
[...]
 Please find the full build log attached.
[...]
+ exec faketime -f 2014-02-06 22:23:27+00:00 asciidoc -d manpage -b xhtml11 
-olibOpenCL.html libOpenCL.7.txt
shm_open: Bad address
[...]

  In some setup, faketime does not work. See #747078 for more
information for example.
  faketime is required to ensure the exact same file on all
architectures as the package is multi-arch same.
  If you want ocl-icd build into your environment, please work on
747078 (or give me another way to ensure idempotent documentation
build). I do not plan to take time to fix this issue myself (too much
other things to do, sorry).

  Regards,
Vincent

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739409: [ocl-icd-libopencl1] Broken symbols file

[Vincent Danjean]

.
In this case, ocl-icd will still keep its versioned symbols but I
will need to talk with NVidia maintainer so that we stop using the
same virtual packages (that were here to denote a binary compatibility).

  Regards,
Vincent

 Best regards,
 Andreas
 
 
 1: https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
 2: http://bugs.debian.org/729203


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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739409: [ocl-icd-libopencl1] Broken symbols file

[Vincent Danjean]

 and 1.1.
Their provides line reflect this:
apt-cache show ocl-icd-libopencl1/unstable | grep Provides
Provides: libopencl-1.1-1, libopencl-1.2-1, libopencl1
apt-cache show nvidia-libopencl1/unstable | grep Provides
Provides: libopencl-1.1-1, libopencl1
apt-cache show amd-libopencl1/unstable | grep Provides
Provides: libopencl-1.1-1, libopencl-1.2-1, libopencl-2.0-1, libopencl1


What is not solved by current dependencies is what occurs if
an OpenCL application uses 1.2 symbols and try to load a 1.1 ICD.
There is no standard way to know (by libOpenCL) which functions
are supported by ICDs. Just looking at version standard is not
enought (Intel ICD report 1.1 while most of 1.2 functions are
implemented but not all of them...)


So, do you think we can close this bug? Else, what is your
precise problem?

  Regards,
Vincent

PS: the stange part libopencl-1.1-1 [!x32], libopencl1 [x32], in your
logs perhaps comes from #737731 fixed in 2.1.3-3 for ocl-icd (but
that needs a binary rebuild of all reverse dependencies to fix
dependencies (and to allow installation of non-free implementation)


 Thank
 
 Bastien
 


-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732009: avahi-daemon: Require a kernel = 3.9, break partial upgrades

[Vincent Danjean]

Package: avahi-daemon
Version: 0.6.31-3
Severity: serious
Justification: break partial upgrades

  Hi,

  At compilation time, in avahi-core/socket.c, if SO_REUSEPORT is defined,
setsockopt(..., SO_REUSEPORT, ..) is called.
  But, if, at runtime, SO_REUSEPORT is not available (with a kernel = 3.9, ie
a wheezy kernel), the function fails and seems to lead to a quick exits of
avahi-daemon. Log file says :

Dec 12 11:20:48 plume avahi-daemon[22508]: Found user 'avahi' (UID 105) and 
group 'avahi' (GID 111).
Dec 12 11:20:48 plume avahi-daemon[22508]: Successfully dropped root privileges.
Dec 12 11:20:48 plume avahi-daemon[22508]: avahi-daemon 0.6.31 starting up.
Dec 12 11:20:48 plume avahi-daemon[22508]: Successfully called chroot().
Dec 12 11:20:48 plume avahi-daemon[22508]: Successfully dropped remaining 
capabilities.
Dec 12 11:20:48 plume avahi-daemon[22508]: No service file found in 
/etc/avahi/services.
Dec 12 11:20:48 plume avahi-daemon[22508]: SO_REUSEPORT failed: Protocol not 
available
Dec 12 11:20:48 plume avahi-daemon[22508]: SO_REUSEPORT failed: Protocol not 
available
Dec 12 11:20:48 plume avahi-daemon[22508]: Failed to create server: No suitable 
network protocol available
Dec 12 11:20:48 plume avahi-daemon[22508]: avahi-daemon 0.6.31 exiting.

Just upgrading the kernel (from the wheezy one to the current testing one)
fixes the problem.

Perhaps, the reuseaddr() function in avahi-core/socket.c should not fail if
setsockopt(..., SO_REUSEPORT, ..) fails (or only if errno is not set to
EINVAL)?

  Regards,
Vincent

-- System Information:
Debian Release: jessie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armel
mipsel

Kernel: Linux 3.12-rc7-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages avahi-daemon depends on:
ii  adduser  3.113+nmu3
ii  bind9-host [host]1:9.9.3.dfsg.P2-4
ii  dbus 1.6.18-1
ii  host 1:9.9.3.dfsg.P2-4
ii  init-system-helpers  1.13
ii  libavahi-common3 0.6.31-2
ii  libavahi-core7   0.6.31-2
ii  libc62.17-93
ii  libcap2  1:2.22-1.2
ii  libdaemon0   0.14-2
ii  libdbus-1-3  1.6.18-1
ii  libexpat12.1.0-4
ii  lsb-base 4.1+Debian12

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.10-3.2

Versions of packages avahi-daemon suggests:
ii  avahi-autoipd  0.6.31-2

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725270: Intention to use NMU to fix the bug

[Vincent Danjean]

Le 15/10/2013 10:03, Sergei Golovan a écrit :
 Hi!
 
 I've bumped the severity of this bug to serious to ensure Tcl/Tk 8.4
 will not go to jessie when it'll become stable.
 
 I'm planning to use NMU to fix this bug if there's no objection for that.

You're welcome (for yaz (#725270) and zebra (#725331)) with NMU.
Both of these packages require some time from me to package a new
upstream version but I'm lacking free time. So, go with MNU, I
will ack them when I will prepare and upload a new version.

  Regards and thanks for you work,
Vincent


 Cheers!
 


-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#720804: Small patch to fix FTBFS

[Vincent Danjean]

tag 720804 +patch
thanks

  Hi,

  This really small patch seems to work (and neon upstream does not
announce API or ABI break)

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

diff --git a/debian/changelog b/debian/changelog
index 375f1d0..41f0daa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+sitecopy (1:0.16.6-4.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Extend 20-bts549721-add-compatibility-for-neon-0.29.0.patch
+to also allow neon 0.30.0 (Closes: 720804)
+
+ -- Vincent Danjean vdanj...@debian.org  Wed, 09 Oct 2013 09:50:01 +0200
+
 sitecopy (1:0.16.6-4) UNRELEASED; urgency=low
 
   [Kartik Mistry]
diff --git 
a/debian/patches/20-bts549721-add-compatibility-for-neon-0.29.0.patch 
b/debian/patches/20-bts549721-add-compatibility-for-neon-0.29.0.patch
index 66356c4..0b53e2e 100644
--- a/debian/patches/20-bts549721-add-compatibility-for-neon-0.29.0.patch
+++ b/debian/patches/20-bts549721-add-compatibility-for-neon-0.29.0.patch
@@ -1,5 +1,5 @@
 From: Sandro Tosi mo...@debian.org
-Subject: Add support for libneon 0.29.0
+Subject: Add support for libneon 0.29.0 and 0.30.0
 
 diff -urNad sitecopy~/configure.in sitecopy/configure.in
 --- sitecopy~/configure.in 2008-07-20 18:21:15.0 +0200
@@ -10,8 +10,8 @@ diff -urNad sitecopy~/configure.in sitecopy/configure.in
  
 -# Support neon 0.24 through 0.28
 -NE_REQUIRE_VERSIONS([0], [24 25 26 27 28])
-+# Support neon 0.24 through 0.29
-+NE_REQUIRE_VERSIONS([0], [24 25 26 27 28 29])
++# Support neon 0.24 through 0.30
++NE_REQUIRE_VERSIONS([0], [24 25 26 27 28 29 30])
  
  dnl But we don't use zlib or ACL support
  NEON_WITHOUT_ZLIB

Bug#723964: Proposed fix for 723964

[Vincent Danjean]

tags 723964 +patch
thanks

  Hi,

  To fix 723964, you just need to allow autoreconf to install new
files. For example, instead of autoreconf, you can put
autoreconf -vif in debian/rules.

  Another possibility to fix this bug is to use the dh-autoreconf
package (build-depends on it and call dh with --with autoreconf
  = this will invoke autoreconf with good option, this will take
care of the restoration of removed files (Makefile.in, ...) and
modified files (config.{guess,sub}, ...)
I think it would be better for long-term maintainability but it
involves more modification (mainly simplification of debian/rules)

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#720431: [Oar-devel] Bug#720431: oar: diff for NMU version 2.5.2-3.1

[Vincent Danjean]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

  Hi,

Le 31/08/2013 02:06, gregor herrmann a écrit :
 For 2.5.2-3.1, we are fine if you push it to Debian's repo as a NMU. If you 
 think it's preferable however, we can package 2.5.2-4, but this will require 
 me to get sponsored (Vincent Danjean can help me with that) as a Debian 
 Maintainer for the package.
 
 For newer versions anyway, I will need to become DM for the package.
 
 It's your decision in the end. My proposal is to let the 2.5.2-3.1 in (I can 
 also move it to 0-day for immediate acceptance), then this issue is out of 
 the way; and then you have all the time you need to prepare 2.5.3-1 and sort 
 out the maintainer and DM questions.

  Go ahead with 0-day NMU. I will sort out maintainer and DM questions
with Pierre during the next days/weeks.

  Thanks for your patch
  Regards,
Vincent
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIVAwUBUiGCr9T1zgD6DpudAQh7OA/+OcH3sw4pEZbJArH8k5IjiBZtacgku0/z
r4OyWJ9J2PUEbVEU7TNwN8vV+SSrIhGKeMa95jxFTjLgTHuG375SGNOzwiwvbLrg
FJ5tnGUmb4/x8zuSAIuV5w0nGmiNawceisU8SoDJkT9qcMfVBGYNZ+ODg+8nFKnG
FZPrdU7TgY2w9Np8MFYH9pRDF2D18b3G5UrOyQEehQFpDrc+YX9IjceN7x/U/+Sc
ZHyJVxGHXthdbaEhqWhO7kuJ5GITRYznWAR4hvPJgxMyRTJ9lZ9SjuEuSEdbKmn2
FYowXE8f32Lm1Xz1S5CD/XM9rOS8bNNUXyZY1cnthVIWarYLiZC/3jn/9KwVTepX
VxuXVXAOnv5jfmKn6JLGn/8KzE53MxCYZw41qmhG+j/JYROQSogt8JKqVAXHF1FB
lilZA5XsN9MK48FDcgJEeQaGSFvALBWYyG5BLSKpNaUmWLx/eFfbqTOEize0kKkK
tekTQbK0Xpl5wIEk8+KNws+M6P5imKISBv9G6p4DXBNyHTaCJge+01KaC+SHwoKV
X15ZJS49isNFBxWuFNbnU+6rBz4xrVmO+2CgNI+dVsEBHHazrC12zCkmNWIkEzT/
LGtMu2Wv4n6c+XRjNBAXaJYaxH0LXSGGpdW1abyhEGLAGLNknCcUsjjwwtO1HaOZ
BmT1HGYnOAo=
=kuw0
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713333: ocl-icd: FTBFS: /usr/share/automake-1.13/am/ltlibrary.am: warning: 'libOpenCL.la': linking libtool libraries using a non-POSIX

[Vincent Danjean]

  Hi,

  Thanks for the report. automake 1.13 is less tolerant than
previous verions.
I just fixed this upstream. I will create an new version
and package it for Debian soon.

  Regards,
Vincent

Le 22/06/2013 14:52, Lucas Nussbaum a écrit :
 Source: ocl-icd
 Version: 1.3-3
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20130620 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.
 
 Relevant part:
 make[1]: Entering directory `/«PKGBUILDDIR»'
 ./bootstrap
 + autoreconf -vi -Wall
 autoreconf: Entering directory `.'
 autoreconf: configure.ac: not using Gettext
 autoreconf: running: aclocal --warnings=all -I m4
 autoreconf: configure.ac: tracing
 autoreconf: running: libtoolize --force --copy
 libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
 libtoolize: copying file `build-aux/ltmain.sh'
 libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
 libtoolize: copying file `m4/libtool.m4'
 libtoolize: copying file `m4/ltoptions.m4'
 libtoolize: copying file `m4/ltsugar.m4'
 libtoolize: copying file `m4/ltversion.m4'
 libtoolize: copying file `m4/lt~obsolete.m4'
 autoreconf: running: autoconf --warnings=all
 autoreconf: running: autoheader --warnings=all
 autoreconf: running: automake --add-missing --copy --no-force --warnings=all
 automake: warnings are treated as errors
 /usr/share/automake-1.13/am/ltlibrary.am: warning: 'libOpenCL.la': linking 
 libtool libraries using a non-POSIX
 /usr/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 
 'configure.ac'
 Makefile.am:18:   while processing Libtool library 'libOpenCL.la'
 /usr/share/automake-1.13/am/ltlibrary.am: warning: 'libdummycl.la': linking 
 libtool libraries using a non-POSIX
 /usr/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 
 'configure.ac'
 Makefile.am:82:   while processing Libtool library 'libdummycl.la'
 Makefile.am:89: warning: compiling 'run_dummy_icd.c' with per-target flags 
 requires 'AM_PROG_CC_C_O' in 'configure.ac'
 parallel-tests: installing 'build-aux/test-driver'
 autoreconf: automake failed with exit status: 1
 make[1]: *** [override_dh_auto_configure] Error 1
 
 The full build log is available from:
http://aws-logs.debian.net/ftbfs-logs/2013/06/20/ocl-icd_1.3-3_unstable.log
 
 A list of current common problems and possible solutions is available at 
 http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
 
 About the archive rebuild: The rebuild was done on EC2 VM instances from
 Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
 failed build was retried once to eliminate random failures.
 


-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#693604: avahi-daemon takes 100% CPU right after boot and at every restart of CUPS

[Vincent Danjean]

Package: avahi-daemon
Version: 0.6.31-2
Followup-For: Bug #693604

  I've been hit by the same bug (cups 1.6 with lots of printers that leads
to a avahi-daemon at 100% CPU and a IPv6 flood of mdns packets).
  Recompiling the package with the cited patch fixe my problem.

  Note for others: the fix is not in the avahi-daemon binary package. Only
upgrading it does not fix the problem. I did not check exactly then, but
upgrading all installed avahi binary package fix the problem (ie
the fix is probably in one of the library libavahi-*)

  Regards
   Vincent

-- System Information:
Debian Release: jessie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386 armel mipsel

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

Versions of packages avahi-daemon depends on:
ii  adduser3.113+nmu3
ii  bind9-host [host]  1:9.8.4.dfsg.P1-6+nmu2
ii  dbus   1.6.10-1
ii  host   1:9.8.4.dfsg.P1-6+nmu2
ii  libavahi-common3   0.6.31-2
ii  libavahi-core7 0.6.31-2
ii  libc6  2.17-1
ii  libcap21:2.22-1.2
ii  libdaemon0 0.14-2
ii  libdbus-1-31.6.10-1
ii  libexpat1  2.1.0-3
ii  lsb-base   4.1+Debian9

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.10-3.2

Versions of packages avahi-daemon suggests:
ii  avahi-autoipd  0.6.31-2

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org