Bug#819894: ITP Lin-guider

[Eduard Bloch]

Hallo,
* Rumen Bogdanovski [Sun, Apr 03 2016, 07:22:04PM]:
> Package: wnpp
> Owner: Rumen G. Bogdanovski 
> Severity: wishlist
> X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,
> debian-pyt...@lists.debian.org
> 
> 
> * Package name: lin-guider
>   Version : 3.2.2
>   Upstream Author : GM software 
> * URL : https://sourceforge.net/projects/linguider/
> * License : GPL3
>   Programming Lang: C++/Perl
>   Description : Lin-guider is an astronomical auto guiding software for
> Linux.

Linux-only? Debian isn't just Linux.

> Lin-guider is an astronomical auto guiding program for Linux. It supports

Please, please, start that sentense with some key words (supports
astrocams of the following types...) and format the list to some more
readable form. Otherwise the reader has to get through all this mess to
finally see the point.

>  Philips, Logitech, uvc webcams, QHY5, QHY6, DSI2PRO, QHY5L-II-M,
> QHY5L-II-C, QHY5-II, ATIK, Starlight Xpress, ZWO ASI astrocams for video
>  and FTDI chip-based, parallel port-based (LPT), GPIO-based, GPUSB
> devices, Nexstar-protocol based and QHY5, QHY6, QHY5L-II-M, QHY5L-II-C,
> QHY5-II, ATIK, Starlight Xpress, ZWO ASI astrocams for pulse guiding.

Best regards,
Eduard.

Bug#820067: RM: libjboss-common-java -- ROM; No longer used

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove libjboss-common-java, this package was a dependency of 
libjboss-vfs-java only
which is going to be removed (see #820066).

Thank you,

Emmanuel Bourg

Bug#806745: gegl --list-all crashes

[Marc J. Driftmeyer]

All clean. You can close it.

- Marc

On 04/04/2016 09:00 AM, Matteo F. Vescovi wrote:

Control: tag -1 + moreinfo

On 2016-04-04 at 15:58 (CEST), Marc J. Driftmeyer wrote:

I'm betting if I rebuild GEGL from trunk it will work. If that's the case, your 
build of GEGL needs investigating.

So?



--

Marc J. Driftmeyer

main: m...@reanimality.com 
book: m...@holoworlds.net 
main:www.reanimastudios.com 
book:www.holoworlds.net 

Bug#819703: you miss the point so much that you should stop shipping xscreensaver

[Axel Beckert]

Hi,

Eli the Bearded wrote:
> Like it or not, JWZ considers xscreensaver to be frontline system
> security. If it doesn't LOCK YOUR SCREEN, it's broken. If you don't
> want to track the security updates, you are (in his mind) harming users.

You seem not aware that Debian _tracks_ security updates in stable.
Just not features. We backport security fixes to the current version
in stable.

See e.g.
https://packages.qa.debian.org/x/xscreensaver/news/20160112T063226Z.html
for the last security update in Jessie (i.e. the aforementioned
version) and see https://packages.qa.debian.org/x/xscreensaver.html
for the remaining security updates in oldstable and oldoldstable (no
more supported now).

> That is why he specifically suggests Gnome's screensaver: it's a as
> hardened as a luggage lock. 

And once again: GNOME Screensaver is not alternative to xscreensaver
as it lacks features and pulls in a lot of GNOME stuff which is
unwanted for other desktop environments.

> At least, that's how I think you'll satisfy JWZ.

We should satisfy our users. And their demand is obvious.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#820062: [Debian-med-packaging] Bug#820062: orthanc and orthanc-doc: error when trying to install together

[Sébastien Jodogne]

Hello,

Thank for reporting this issue. However, I need help: I am indeed unable to 
reproduce it...

According to your report, the file 
"/usr/lib/orthanc/libModalityWorklists.so.1.0.0" lies both in package "orthanc" 
and "orthanc-doc":

>
/var/cache/apt/archives/orthanc-doc_1.0.0+dfsg-2_all.deb (--unpack):
 trying to overwrite '/usr/lib/orthanc/libModalityWorklists.so.1.0.0', which
 is also in package orthanc 1.0.0+dfsg-2
<

However, when I list the content of the "orthanc-doc" generated by my local 
pbuilder, this file is not present inside the package:

>
jodogne@unstable:~/Subversion/Debian/orthanc/debian$ dpkg -c 
/var/cache/pbuilder/result/orthanc-doc_1.0.0+dfsg-2_all.deb | grep 
ModalityWorklists
drwxr-xr-x root/root 0 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/
-rw-r--r-- root/root  7932 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/Plugin.cpp
-rw-r--r-- root/root  1561 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/README
drwxr-xr-x root/root 0 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/WorklistsDatabase/
-rw-r--r-- root/root   740 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/WorklistsDatabase/wklist2.wl
-rw-r--r-- root/root   748 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/WorklistsDatabase/wklist7.wl
-rw-r--r-- root/root   742 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/WorklistsDatabase/wklist5.wl
-rw-r--r-- root/root   756 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/WorklistsDatabase/wklist1.wl
-rw-r--r-- root/root   750 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/WorklistsDatabase/wklist6.wl
-rw-r--r-- root/root   752 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/WorklistsDatabase/wklist9.wl
-rw-r--r-- root/root   740 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/WorklistsDatabase/wklist3.wl
-rw-r--r-- root/root   467 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/WorklistsDatabase/Generate.py
-rw-r--r-- root/root   746 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/WorklistsDatabase/wklist10.wl
-rw-r--r-- root/root   752 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/WorklistsDatabase/wklist8.wl
-rw-r--r-- root/root   728 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/WorklistsDatabase/wklist4.wl
-rw-r--r-- root/root  1250 2016-04-04 15:20 
./usr/share/doc/orthanc/OrthancPluginSamples/ModalityWorklists/CMakeLists.txt
<

Could someone give me a hint? Is it because, as Ralf says at the end of his 
report, the packages are slightly out of sync?

TIA,
Sébastien-


- Mail original -
> De: "Ralf Treinen" 
> À: sub...@bugs.debian.org
> Envoyé: Mardi 5 Avril 2016 08:44:44
> Objet: [Debian-med-packaging] Bug#820062: orthanc and orthanc-doc: error  
> when trying to install together
> 
> Package: orthanc-doc,orthanc
> Version: orthanc-doc/1.0.0+dfsg-1
> Version: orthanc/1.0.0+dfsg-1+b1
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
> 
> Date: 2016-04-05
> 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:
> 
> 
> 
> Extracting templates from packages: 65%
> Extracting templates from packages: 100%
> Preconfiguring packages ...
> Selecting previously unselected package libwrap0:amd64.
> (Reading database ... 10944 files and directories currently installed.)
> Preparing to unpack .../libwrap0_7.6.q-25_amd64.deb ...
> Unpacking libwrap0:amd64 (7.6.q-25) ...
> Selecting previously unselected package gcc-5-base:amd64.
> Preparing to unpack .../gcc-5-base_5.3.1-13_amd64.deb ...
> Unpacking gcc-5-base:amd64 (5.3.1-13) ...
> Processing triggers for man-db (2.7.5-1) ...
> Setting up gcc-5-base:amd64 (5.3.1-13) ...
> (Reading database ... 10963 files and directories currently installed.)
> Preparing to unpack .../libstdc++6_5.3.1-13_amd64.deb ...
> Unpacking libstdc++6:amd64 (5.3.1-13) over (4.8.2-19) ...
> Processing triggers for libc-bin (2.22-5) ...
> Setting up libstdc++6:amd64 (5.3.1-13) ...
> Processing triggers for libc-bin (2.22-5) ...
> Selecting previously unselected package libcharls1:amd64.
> (Reading database ... 10977 files and directories currently installed.)
> Preparing to unpack .../libcharls1_1.0-6_amd64.deb ...
> Unpacking libcharls1:amd64 (1.0-6) ...
> Selecting previously unselected package libjbig0:amd64.
> Preparing to unpack .../libjbig0_2.1-3.1_amd64.de

Bug#820068: optipng: CVE-2016-2191: Invalid write while processing delta escapes without any boundary checking

[Salvatore Bonaccorso]

Source: optipng
Version: 0.6.4-1
Severity: important
Tags: security upstream fixed-upstream
Forwarded: https://sourceforge.net/p/optipng/bugs/59/

Hi,

the following vulnerability was published for optipng and is fixed
in 0.7.6 upstream.

CVE-2016-2191[0]:
Invalid write while processing delta escapes without any boundary checking

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-2191
[1] https://sourceforge.net/p/optipng/bugs/59/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1308550

Regards,
Salvatore

Bug#820031: kpartx: broken maintainer scripts prevent package removal

[Ritesh Raj Sarraf]

Control: tag -1 +confirmed

On Mon, 2016-04-04 at 23:11 +0200, Andreas Beckmann wrote:
> Package: kpartx
> Version: 0.5.0+git1.656f8865-8
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: affects -1 + lava-server
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to remove.
> 
> > 
> > From the attached log (scroll to the bottom...):
>   Removing kpartx (0.5.0+git1.656f8865-8) ...
>   preinst called with unknown argument `remove'
>   dpkg: error processing package kpartx (--remove):
>    subprocess installed pre-removal script returned error exit status 1

Thank you. I can confirm the bug. But I'm wondering what triggered this bug.
dpkg complains of the preinst script, which according to documentation should
only have been triggered during an install or upgrade operation.



rrs@learner:~$ sudo dpkg --purge kpartx
(Reading database ... 416244 files and directories currently installed.)
Removing kpartx (0.5.0+git1.656f8865-8) ...
preinst called with unknown argument `remove'
dpkg: error processing package kpartx (--purge):
 subprocess installed pre-removal script returned error exit status 1
Errors were encountered while processing:
 kpartx
2016-04-05 / 12:43:23 ♒♒♒  ☹  => 1  

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#819998: [Pkg-running-devel] Bug#819998: garmin-forerunner-tools: FTBFS on !linux after switch to libusb 1.0

[Christian PERRIER]

Quoting Andreas Beckmann (a...@debian.org):
> Source: garmin-forerunner-tools
> Version: 0.10repacked-8
> Severity: important
> 
> Hi,
> 
> the non-linux architectures have a different implementation for libusb,
> available from different packages. The recent switch to libusb 1.0
> caused a FTBFS since there is no libusb-1.0-0-dev.


Doh. I blindly followed instructions from the bug reporter for this
change.

I suppose that this probably affects several packages and not this
one, only. If so, are there guidelines somewhere about Doing The Right
Thing?




signature.asc
Description: PGP signature

Bug#820061: linux-image-amd64: kernel hangs since debian 8.4

[Bjørn Mork]

Benoît Tonnerre  writes:

> Apr  4 18:52:55 pci003-01 kernel: [   79.329223] RIP: 
> 0010:[]
> [] radeon_fence_ref+0xd/0x50 [radeon]
> Apr  4 18:52:55 pci003-01 kernel: [   79.330192] RSP: 0018:88003639fb18
> EFLAGS: 00010292
> Apr  4 18:52:55 pci003-01 kernel: [   79.331154] RAX:  RBX:
> 8802218f55f8 RCX: 8802218f4d08
> Apr  4 18:52:55 pci003-01 kernel: [   79.332125] RDX: 0001 RSI:
>  RDI: 
> Apr  4 18:52:55 pci003-01 kernel: [   79.333110] RBP: 8802218f5550 R08:
> 8802218f4000 R09: 
> Apr  4 18:52:55 pci003-01 kernel: [   79.334119] R10: 0002 R11:
> 88003639fe08 R12: 0020
> Apr  4 18:52:55 pci003-01 kernel: [   79.335117] R13: 88003639fbe0 R14:
> 88003639fbb0 R15: 8802218f55f8
> Apr  4 18:52:55 pci003-01 kernel: [   79.336120] FS:  7fd8f5323980()
> GS:88022dc6() knlGS:
> Apr  4 18:52:55 pci003-01 kernel: [   79.337143] CS:  0010 DS:  ES: 
> CR0: 80050033
> Apr  4 18:52:55 pci003-01 kernel: [   79.338142] CR2: 0008 CR3:
> 000223b3e000 CR4: 000407e0
> Apr  4 18:52:55 pci003-01 kernel: [   79.339125] Stack:
> Apr  4 18:52:55 pci003-01 kernel: [   79.340065]  a04900bc
> 0020 eea00100 88003639fcd0
> Apr  4 18:52:55 pci003-01 kernel: [   79.341006]  8802218f4000
> 8802216c0a20 8802216c0a20 0001
> Apr  4 18:52:55 pci003-01 kernel: [   79.341952]  
>   
> Apr  4 18:52:55 pci003-01 kernel: [   79.342899] Call Trace:
> Apr  4 18:52:55 pci003-01 kernel: [   79.343854]  [] ?
> radeon_sa_bo_new+0x25c/0x460 [radeon]

I believe this is fixed by commit f80be5a9b1cc ("Revert "drm/radeon:
hold reference to fences in radeon_sa_bo_new"") in v3.16.7-ckt26.


Bjørn

Bug#819676: ansible: CVE-2016-3096: Code execution vulnerability in ansible lxc_container

[Evgeni Golov]

Ohai,

On Fri, Apr 01, 2016 at 03:15:48PM +0200, Salvatore Bonaccorso wrote:
> There are now a partial fix
> 
> https://github.com/ansible/ansible-modules-extras/commit/da84e2e9b83be6ebebbfd3be6776f391622c02fe
> 
> and more in pull request at
> 
> https://github.com/ansible/ansible-modules-extras/pull/1941

Both have been pushed to all relevant stable branches of Ansible now.

FWIW, if you are already shipping updates to lxc_container.py, you
might consider also including
https://github.com/ansible/ansible-modules-extras/commit/6bfd2846f853b9beaeb01da6206d8ffa4abe7a4c

Greets
Evgeni

Bug#820008: Support for securelevel and Secure Boot

[Florian Weimer]

* Ben Hutchings:

> To ensure the integrity of the kernel, we should support a securelevel
> where all modules must be signed by a trusted key and all APIs
> allowing arbitrary memory writes are disabled.

What is a trusted key?  I'm not convinced we can align this with
Debian's principles.

> To meet Secure Boot requirements, we need to turn this on whenever
> booted with SB enabled.

I object to Microsoft Secure Boot support in Debian.  It has no clear
security objective, requires the use of Microsoft Windows and
Microsoft services to build boot loaders, and might harm our users in
the long term (e.g., users can only access the web from a Secure Boot
machine with a Firefox built by Mozilla, and Firefox promises web
sites not to enable the “Save as ...” context menu item).

Just support for UEFI signed boot loaders would be a different matter,
but then we don't need securelevel support in the kernel.

Maybe we should discuss this on debian-project?

Fedora has kernel patches for this, but they are not upstream, and are
unlikely to end up there ever.

Bug#819703:

[Sandbox Oliver-Kutschke]

As always. Bla bla bla! Don't talk! Fix it in stable or kick it! NOW!

Bug#820051: virtualbox: apt-get installation routine recommends package linux-image, which doesn't exist

[Gianfranco Costamagna]

control: reassign -1 dkms
control: found -1 2.2.0.3-2

Hi Harald, this seems to be dragged in by virtualbox-dkms, that depends on 
dkms, that drags linux-image

https://sources.debian.net/src/dkms/2.2.0.3-2/debian/control/

it is a virtual package in Ubuntu, and harmless in Debian I think.

I don't think it is worth a fix :)

cheers,

Gianfranco





Il Martedì 5 Aprile 2016 3:27, Harald N.  ha 
scritto:
Package: virtualbox
Version: 4.3.36-dfsg-1+deb8u1
Severity: minor
Tags: d-i

Dear Maintainer,


When installing Virtualbox, it recommends the package Linux-image, which cannot
be installed/doesn't exist

Here the log of my actions:


-> # apt-get install virtualbox

Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  cpp-4.8 dkms fakeroot gcc gcc-4.8 gcc-4.9 libasan0 libasan1 libatomic1 libc-
dev-bin libc6-dev libcilkrts5 libfakeroot libgcc-4.8-dev libgcc-4.9-dev
libgsoap5 libitm1 liblsan0 libtsan0 libubsan0 libvncserver0
  linux-compiler-gcc-4.8-x86 linux-headers-3.16.0-4-amd64 linux-
headers-3.16.0-4-common linux-headers-amd64 linux-kbuild-3.16 linux-libc-dev
manpages-dev virtualbox-dkms virtualbox-qt
Vorgeschlagene Pakete:
  gcc-4.8-locales gcc-multilib autoconf automake libtool flex bison gdb gcc-doc
gcc-4.8-multilib gcc-4.8-doc libgcc1-dbg libgomp1-dbg libitm1-dbg
libatomic1-dbg libasan0-dbg libtsan0-dbg libquadmath0-dbg
  gcc-4.9-multilib gcc-4.9-doc gcc-4.9-locales libasan1-dbg liblsan0-dbg
libubsan0-dbg libcilkrts5-dbg glibc-doc vde2 virtualbox-guest-additions-iso
Empfohlene Pakete:
  linux-image
Die folgenden NEUEN Pakete werden installiert:
  cpp-4.8 dkms fakeroot gcc gcc-4.8 gcc-4.9 libasan0 libasan1 libatomic1 libc-
dev-bin libc6-dev libcilkrts5 libfakeroot libgcc-4.8-dev libgcc-4.9-dev
libgsoap5 libitm1 liblsan0 libtsan0 libubsan0 libvncserver0
  linux-compiler-gcc-4.8-x86 linux-headers-3.16.0-4-amd64 linux-
headers-3.16.0-4-common linux-headers-amd64 linux-kbuild-3.16 linux-libc-dev
manpages-dev virtualbox virtualbox-dkms virtualbox-qt
0 aktualisiert, 31 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 49,1 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 197 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] y

Followed by the output of the installation.

#
#


-> # apt-get install linux-image
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen Fertig
Package linux-image is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'linux-image' has no installation candidate

#
#

-> # cat /etc/apt/sources.list
#

# deb cdrom:[Debian GNU/Linux 8.3.0 _Jessie_ - Official amd64 DVD Binary-1
20160123-19:03]/ jessie contrib main

#deb cdrom:[Debian GNU/Linux 8.3.0 _Jessie_ - Official amd64 DVD Binary-1
20160123-19:03]/ jessie contrib main
#
#deb cdrom:[Debian GNU/Linux 8.3.0 _Jessie_ - Official amd64 DVD Binary-2
20160123-19:03]/ jessie contrib main

#deb cdrom:[Debian GNU/Linux 8.3.0 _Jessie_ - Official amd64 DVD Binary-3
20160123-19:03]/ jessie contrib main

deb http://security.debian.org/ jessie/updates main contrib
#deb-src http://security.debian.org/ jessie/updates main contrib

# jessie-updates, previously known as 'volatile'
# A network mirror was not selected during install.  The following entries
# are provided as examples, but you should amend them as appropriate
# for your mirror of choice.
#
deb http://ftp.debian.org/debian/ jessie-updates main contrib non-free
#deb-src http://ftp.debian.org/debian/ jessie-updates main contrib non-free



deb http://ftp.at.debian.org/debian/ jessie main contrib non-free
#
#

I hope, I did not just fail completely...

Yours,
H.




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

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

Versions of packages virtualbox depends on:
ii  adduser  3.113+nmu3
ii  libc62.19-18+deb8u4
ii  libcurl3-gnutls  7.38.0-4+deb8u3
ii  libgcc1  1:4.9.2-10
ii  libgsoap52.8.17-1
ii  libpng12-0   1.2.50-2+deb8u2
ii  libpython2.7 2.7.9-2
ii  libsdl1.2debian  1.2.15-10+b1
ii  libssl1.0.0  1.0.1k-3+deb8u4
ii  libstdc++6   4.9.2-10
ii  libvncserver00.9.9+dfsg2-6.1+deb8u1
ii  libvpx1  1.3.0-3
ii  libx11-6 2:1.6.2-3
ii  libxcursor1  1:1.1.14-1+b1
ii  libxext6 2:1.3.3-1
ii  libxml2  2.9.1+dfsg1-5+deb

Bug#819074: maven files for included jars

[Hans-Christoph Steiner]

Attached is a listing of relevant jars that are included when you
download the whole Android SDK, I think we're pretty close to having all
those available.  Here are maven files for some of the jars included in
this package:


https://jcenter.bintray.com/com/android/tools/build/builder/1.5.0/builder-1.5.0.pom

https://jcenter.bintray.com/com/android/tools/build/builder-model/1.5.0/builder-model-1.5.0.pom

https://jcenter.bintray.com/com/android/tools/build/gradle/1.5.0/gradle-1.5.0.pom

https://jcenter.bintray.com/com/android/tools/build/gradle-core/1.5.0/gradle-core-1.5.0.pom

https://jcenter.bintray.com/com/android/tools/build/manifest-merger/24.5.0/manifest-merger-24.5.0.pom



https://jcenter.bintray.com/com/android/tools/lint/lint/24.5.0/lint-24.5.0.pom

https://jcenter.bintray.com/com/android/tools/lint/lint-api/24.5.0/lint-api-24.5.0.pom

https://jcenter.bintray.com/com/android/tools/lint/lint-checks/24.5.0/lint-checks-24.5.0.pom

https://jcenter.bintray.com/com/android/tools/lint/lint-tests/24.5.0/lint-tests-24.5.0.pom



https://jcenter.bintray.com/com/android/tools/ddms/ddmlib/24.5.0/ddmlib-24.5.0.pom


https://jcenter.bintray.com/com/android/tools/dvlib/24.5.0/dvlib-24.5.0.pom


https://jcenter.bintray.com/com/android/tools/sdk-common/24.5.0/sdk-common-24.5.0.pom


https://jcenter.bintray.com/com/android/tools/sdklib/24.5.0/sdklib-24.5.0.pom



libs.txt.bz2
Description: application/bzip

Bug#819074: gradle plugin uses lots of these jars

[Hans-Christoph Steiner]

as for a package that depends on these jars, the gradle plugin for
Android relies on a lot of these jars, and that's packaged.  So the test
now is whether we can build an Android app using only `apt-get install
android-sdk`.

Bug#820069: dhcpcd5: configures interface without being asked to

[Christian Pernegger]

Package: dhcpcd5
Version: 6.0.5-2
Severity: normal

Hi,

this box has its network interface configured statically in
/etc/network/interfaces. dhcpcd5 is installed but should not be active
at this time. (I would have liked to use DHCP, but neither dhcpcd5 nor
isc-dhcp-client work properly on a machine that only wakes once per
day for a few minutes and usessystemd. Also I sometimes use a wireless
dongle and that needs DHCP.)


Anyway, last night the box woke up and ...

Apr 05 02:00:30 mrmackey kernel: Restarting tasks ... done.
Apr 05 02:00:30 mrmackey dhcpcd[622]: eth0: carrier lost
Apr 05 02:00:30 mrmackey dhcpcd[622]: eth0: deleting host route to 192.168.0.25 
via 127.0.0.1
Apr 05 02:00:30 mrmackey dhcpcd[622]: eth0: deleting route to 192.168.0.0/24
Apr 05 02:00:30 mrmackey dhcpcd[622]: eth0: deleting default route via 
192.168.0.1
Apr 05 02:00:30 mrmackey systemd-timesyncd[364]: System time changed. Resyncing.
Apr 05 02:00:30 mrmackey systemd-sleep[807]: System resumed.
Apr 05 02:00:30 mrmackey systemd[1]: Requested transaction contradicts existing 
jobs: File exists
Apr 05 02:00:30 mrmackey systemd-logind[543]: Operation finished.
Apr 05 02:00:32 mrmackey dhcpcd[622]: eth0: carrier acquired
Apr 05 02:00:32 mrmackey kernel: r8169 :02:00.0 eth0: link up
Apr 05 02:00:32 mrmackey dhcpcd[622]: eth0: soliciting an IPv6 router
Apr 05 02:00:32 mrmackey dhcpcd[622]: eth0: rebinding lease of 192.168.0.25
Apr 05 02:00:41 mrmackey dhcpcd[622]: eth0: leased 192.168.0.25 for 86400 
seconds
Apr 05 02:00:41 mrmackey dhcpcd[622]: eth0: adding host route to 192.168.0.25 
via 127.0.0.1
Apr 05 02:00:41 mrmackey dhcpcd[622]: eth0: adding route to 192.168.0.0/24
Apr 05 02:00:41 mrmackey dhcpcd[622]: eth0: adding default route via 192.168.0.1
Apr 05 02:00:44 mrmackey dhcpcd[622]: eth0: no IPv6 Routers available

 happily overwrote the manual interface configuration, causing the
box to get the wrong IP, breakage ensued.


There used to be log entries like:

Mär 31 10:30:43 mrmackey dhcpcd[543]: Not running dhcpcd because 
/etc/network/interfaces ... failed!
Mär 31 10:30:43 mrmackey dhcpcd[543]: defines some interfaces that will use a 
DHCP client ... failed!
Mär 31 10:30:43 mrmackey systemd[1]: dhcpcd.service: control process exited, 
code=exited status=6
Mär 31 10:30:43 mrmackey systemd[1]: Failed to start LSB: IPv4 DHCP client with 
IPv4LL support.
Mär 31 10:30:43 mrmackey systemd[1]: Unit dhcpcd.service entered failed state.

But that was the last one of this kind. dhcpcd ran without really
doing anything on the 1st and 2nd, then assigned the wrong IP on the
3rd, 4th and 5th. So it's basically on the fritz since the 8.4 update,
but the trigger may just as well have been the (rare) reboot that
followed it, not anything in the update itself.

/etc/network/interfaces is attached, I really don't see why it should
be running at all. I'm purging it for now, just to be sure, but I can
always reinstall it for tests.

Regards,
Christian



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

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

Versions of packages dhcpcd5 depends on:
ii  libc6  2.19-18+deb8u4

Versions of packages dhcpcd5 recommends:
pn  openresolv | resolvconf  

Versions of packages dhcpcd5 suggests:
pn  dhcpcd-gtk  

-- no debconf information
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#allow-hotplug eth0
auto eth0
#iface eth0 inet dhcp
iface eth0 inet static
  address 192.168.0.5
  netmask 255.255.255.0
  gateway 192.168.0.1
  mtu 9000
  ethernet-wol g

# wifi experiemnts
#allow-hotplug wlan0
#iface wlan0 inet dhcp
#  wpa-driver nl80211
#  wpa-ssid Southpark
#  wpa-psk XX

Bug#737316: bind9utils: Please install named-checkzone in user PATH

[Arturo Borrero Gonzalez]

On Sat, 01 Feb 2014 16:56:24 +0100 Christian Hofstaedtler
 wrote:
> Package: bind9utils
> Version: 1:9.9.3.dfsg.P2-4
> Severity: wishlist
>
> Dear Maintainer,
>
> named-checkzone is a helpful tool even for non-root.
> Please install it into the default PATH for non-root users.
>

+1

Dear Maintainer,

please ping me if you would like to see a patch for the package to address this.

best regards.

Bug#819982: mandos-client: bad gpgme_op_decrypt: GPGME: Decryption failed.

[Teddy Hogeborn]

Felix Koop  writes:

> when booting the client I get the following error message:
>
> bad gpgme_op_decrypt: GPGME: Decryption failed.
>
> I installed mandos-client and created the key on the client. Then
> included the resulting text in the clients.conf file on the server.
> Testing the key with the procedure described in the README file works
> flawlessly. When booting, I have to enter the key manually as
> I only get the above mentioned error message.
>
> Do you need any additional information?

So the client works in the normal system but fails in the initrd?  That
is odd.  I have a few suggestions to gather more data to help with
debugging:

1. Uncomment the line in /etc/mandos/plugin-runner.conf which says
   "--options-for=mandos-client:--debug", and rebuild the initramfs
   image with "update-initramfs -k all -u".  When booting, the Mandos
   client should now output debug information, including more details
   about the error you reported.

2. Unpack the initramfs image and list the files it contains - perhaps
   it is missing something important for some odd reason.  This is most
   easily done by running the "initramfs-unpack" script from the Mandos
   source tree, which will unpack all initramfs images to /tmp.  The
   script file is available here:
   
.

3. Boot your system with the additional kernel command line argument
   "break".  This will start an emergency shell.  First, run the command

chmod a=rwxt /tmp

   Then you should be able to run the /lib/mandos/plugin-runner program,
   and by running the command multiple times you should be able to debug
   the problem.  Also, the output of the "gpgconf" command in this mode
   should be informative, especially compared to its output when run in
   the normal system.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos


signature.asc
Description: PGP signature

Bug#722670: feed2imap: feed-item causes crash

[Christoph Feenders]

Hi Antonio,

yes, I still have this problem using Debian Jessie.

The troublesome feed is available here:
http://iopscience.iop.org/0295-5075/?rss=1

The web-site does not seem very responsive and I have the feeling that
the error/problem only occurs in some kind of timeout condition when the
server stops answering in the middle of a request (see current log for
the feed below).


---
F, [2016-04-05T05:02:07.759207 #18809] FATAL -- : Error while parsing
EPL: #http://responsivenews.co.uk/post/18948466399/cutting-the-mustard */

  /* Below is the original if statement, from the link above. I 
have
amended it to turn of JS on all IE browsers less than 10.
This is due to a function in the iop.jquery.toolbar line 
35/36.
Uses .remove which is not native js supported in IE9 or lower */
  /*if('querySelector' in document
&& 'localStorage' in window
&& 'addEventListener' in window)*/

  /* This is the updated selector, taken from:
https://justmarkup.com/log/2015/02/26/cut-the-mustard-revisited/ */
if('visibilityState' in document) {

/*! loadJS: load a JS. We are loading this command straight 
away,
before the body loads, so that IF a user has JS enabled, their show hide
panels will automatically be closed. */
/* If this isn't here, then these panels appear open while 
the
page is loading, then when the js loads at the bottom of the page, they
are shut. So the users sees open content, then hidden after a second or
2 when the js is loaded. Not nice */
document.write("">
/usr/lib/ruby/2.1.0/rexml/text.rb:155:in `block in check'
/usr/lib/ruby/2.1.0/rexml/text.rb:153:in `scan'
/usr/lib/ruby/2.1.0/rexml/text.rb:153:in `check'
/usr/lib/ruby/2.1.0/rexml/text.rb:120:in `initialize'
/usr/lib/ruby/2.1.0/rexml/parsers/treeparser.rb:46:in `new'
/usr/lib/ruby/2.1.0/rexml/parsers/treeparser.rb:46:in `parse'
/usr/lib/ruby/2.1.0/rexml/document.rb:287:in `build'
/usr/lib/ruby/2.1.0/rexml/document.rb:44:in `initialize'
/usr/lib/ruby/vendor_ruby/feedparser/feedparser.rb:64:in `new'
/usr/lib/ruby/vendor_ruby/feedparser/feedparser.rb:64:in `parse'
/usr/lib/ruby/vendor_ruby/feedparser/feedparser.rb:53:in `initialize'
/usr/lib/ruby/vendor_ruby/feed2imap/feed2imap.rb:229:in `new'
/usr/lib/ruby/vendor_ruby/feed2imap/feed2imap.rb:229:in `block in
initialize'
/usr/lib/ruby/vendor_ruby/feed2imap/feed2imap.rb:223:in `each'
/usr/lib/ruby/vendor_ruby/feed2imap/feed2imap.rb:223:in `initialize'
/usr/bin/feed2imap:48:in `new'
/usr/bin/feed2imap:48:in `'
...
Illegal character '&' in raw string "
  /*  Cutting the mustard -
http://responsivenews.co.uk/post/18948466399/cutting-the-mustard */

  /* Below is the original if statement, from the link above. I 
have
amended it to turn of JS on all IE browsers less than 10.
This is due to a function in the iop.jquery.toolbar line 
35/36.
Uses .remove which is not native js supported in IE9 or lower */
  /*if('querySelector' in document
&& 'localStorage' in window
&& 'addEventListener' in window)*/

  /* This is the updated selector, taken from:
https://justmarkup.com/log/2015/02/26/cut-the-mustard-revisited/ */
if('visibilityState' in document) {

/*! loadJS: load a JS. We are loading this command straight 
away,
before the body loads, so that IF a user has JS enabled, their show hide
panels will automatically be closed. */
/* If this isn't here, then these panels appear open while 
the
page is loading, then when the js loads at the bottom of the page, they
are shut. So the users sees open content, then hidden after a second or
2 when the js is loaded. Not nice */
document.write(""
Line: 62
Position: 1821
Last 80 unconsumed characters:

Bug#819990: [libnvidia-ml1] can not dlopen(libnvidia-ml.so) from app

[Luca Boccassi]

On Apr 5, 2016 08:55, "Christian Beer"  wrote:
>
>
>
> Luca Boccassi schrieb am 04.04.2016 18:59:
>
> >
> > boinc-client should dlopen libnvidia-ml.so.1, which is in the main
> > /usr/lib/*/ path.
> >
> > is the version package by Debian doing this? Or a custom application?
> >
>
>
> I tested this with upstream and dlopening libnvidia-ml.so.1 does the
trick. There is a pull request upstream:
https://github.com/BOINC/boinc/pull/1522 which will flow into the
boinc-client package soon after a new Client release.
>
> I CCed the Debian  BOINC maintainer list so they can adopt the patch
before that if they want to.

Great, thank you for taking it forward upstream!

Kind regards,
Luca Boccassi

Bug#820031: kpartx: broken maintainer scripts prevent package removal

[Andreas Beckmann]

On 2016-04-05 09:41, Ritesh Raj Sarraf wrote:
>>> From the attached log (scroll to the bottom...):
>>   Removing kpartx (0.5.0+git1.656f8865-8) ...
>>   preinst called with unknown argument `remove'
>>   dpkg: error processing package kpartx (--remove):
>>subprocess installed pre-removal script returned error exit status 1
> 
> Thank you. I can confirm the bug. But I'm wondering what triggered this bug.
> dpkg complains of the preinst script, which according to documentation should
> only have been triggered during an install or upgrade operation.

dpkg complains about the prerm script. The prerm script itself claims to
be the preinst script. Maybe something was incorrectly renamed?


Andreas

Bug#819998: garmin-forerunner-tools: FTBFS on !linux after switch to libusb 1.0

[Andreas Beckmann]

On 2016-04-05 09:33, Christian PERRIER wrote:
> Quoting Andreas Beckmann (a...@debian.org):
>> Source: garmin-forerunner-tools
>> Version: 0.10repacked-8
>> Severity: important
>>
>> Hi,
>>
>> the non-linux architectures have a different implementation for libusb,
>> available from different packages. The recent switch to libusb 1.0
>> caused a FTBFS since there is no libusb-1.0-0-dev.
> 
> 
> Doh. I blindly followed instructions from the bug reporter for this
> change.
> 
> I suppose that this probably affects several packages and not this
> one, only. If so, are there guidelines somewhere about Doing The Right
> Thing?

I don't know the details ... Cc:ing Steven who might help with the
kfreebsd side.


Andreas

Bug#819703: you miss the point so much that you should stop shipping xscreensaver

[Marc Haber]

> Like it or not, JWZ considers xscreensaver to be frontline system
> security. If it doesn't LOCK YOUR SCREEN, it's broken. If you don't
> want to track the security updates, you are (in his mind) harming users.

If there is such a bug in xscreensaver in stable, why is the release
not tagged as critical security release, and why was the issue not
communicated more clearly, maybe even with a reproducer and a patch?

> A version, today, over about five months old is going to have at least
> one security hole: you can crash out of the password prompt (at least in
> some cases) by hot swapping monitors at a critical time.

CVE number?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#816272: [Pkg-clamav-devel] Bug#816272: Bug#816272: clamav-freshclam: logrotate errors out with "gzip: stdin: file size changed while zipping"

[Christian Pernegger]

Hi,

no error e-mail this week, yay!

It looks like this is/was a duplicate of #788652 in the end (at least
the clamav-freshclam part of it). If you agree, please close & merge
as appropriate.

Thank you,
Christian

Bug#819894: ITP Lin-guider

[Rumen Bogdanovski]

Hi Eduard,

On Tue, Apr 5, 2016 at 9:56 AM, Eduard Bloch  wrote:

> Hallo,
> * Rumen Bogdanovski [Sun, Apr 03 2016, 07:22:04PM]:
> > Package: wnpp
> > Owner: Rumen G. Bogdanovski 
> > Severity: wishlist
> > X-Debbugs-Cc: debian-de...@lists.debian.org,
> debian-as...@lists.debian.org,
> > debian-pyt...@lists.debian.org
> >
> >
> > * Package name: lin-guider
> >   Version : 3.2.2
> >   Upstream Author : GM software 
> > * URL : https://sourceforge.net/projects/linguider/
> > * License : GPL3
> >   Programming Lang: C++/Perl
> >   Description : Lin-guider is an astronomical auto guiding software
> for
> > Linux.
>
> Linux-only? Debian isn't just Linux.
>
Yes unfortunately Lin-guider is Linux only for various reasons. I have an
idea to port it to MacOSX, but I just have no time to complete it,
however I do not think mas port would be of Debian's interest. Never tested
it on FreeBSD, and most probably it would need some porting in order to
work mainly because of video for linux which is used in some parts. Is that
a problem that is Linux only?



>
> > Lin-guider is an astronomical auto guiding program for Linux. It supports
>
> Please, please, start that sentense with some key words (supports
> astrocams of the following types...) and format the list to some more
> readable form. Otherwise the reader has to get through all this mess to
> finally see the point.
>
How do i format it? Plain text, HTML, markdown etc?


>
> >  Philips, Logitech, uvc webcams, QHY5, QHY6, DSI2PRO, QHY5L-II-M,
> > QHY5L-II-C, QHY5-II, ATIK, Starlight Xpress, ZWO ASI astrocams for video
> >  and FTDI chip-based, parallel port-based (LPT), GPIO-based, GPUSB
> > devices, Nexstar-protocol based and QHY5, QHY6, QHY5L-II-M, QHY5L-II-C,
> > QHY5-II, ATIK, Starlight Xpress, ZWO ASI astrocams for pulse guiding.
>
> Best regards,
> Eduard.
>

Bug#766746: [pkg-wpa-devel] Bug#766746: wpasupplicant: install interface-specific systemd service file

[Enrico Rossi]

Dear Maintainer,

In order to start using systemd-networkd with wpasupplicant, the
mentioned service file is needed. I also have installed the file by hand
and make things work, but I would have preferred to find it in the
package.

I suggest you to reconsider this bug. I don't think a whishlist severity
is appropriate anymore.

Thanks for your effort.
E.

On Sun, 26 Oct 2014 11:06:25 +0100 Alessandro Ghedini  wrote:
> Well, right now I installed the file manually so there's no urgency.

-- 
GPG Key: 4096R/F2133176 2010-10-19 Enrico Rossi 


signature.asc
Description: PGP signature

Bug#811185: root cause: antlr

[olivier sallou]

The update of antlr from 3.2-11 to 3.5.2 introduces the issue.
antlr behaves differently and does not produce the same code.

Bug#818407: fixed in unixodbc 2.3.1-4.1

[John Paul Adrian Glaubitz]

Hi Steve!

On 04/05/2016 12:39 AM, Steve Langasek wrote:
> Ummm what?  What do you think you're doing?  Where is the NMU patch for
> this, which in all cases must be sent to the BTS *before* you upload?  And
> since when is a 0-day NMU for a two-week-old FTBFS that doesn't previously
> have a patch attached appropriate?

Sorry, that was an oversight, I meant to add --delayed=3 but that
somehow slipped. Attaching the patch which is very minimal, I tried
to keep the changelog entry formatted the way you format them,
but I forgot the additional space in front of "Closes:". You might
want to fix this silently on the next upload.

There is just really a long list of reverse dependencies which need
unixodbc directly or transitively which is why I started to get
worried.

Sorry,

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -u unixodbc-2.3.1/Makefile.am unixodbc-2.3.1/Makefile.am
--- unixodbc-2.3.1/Makefile.am
+++ unixodbc-2.3.1/Makefile.am
@@ -1,5 +1,3 @@
-ACLOCAL_AMFLAGS=-I libltdl/m4
-
 SUBDIRS = \
 	extras \
 	log \
diff -u unixodbc-2.3.1/configure.in unixodbc-2.3.1/configure.in
--- unixodbc-2.3.1/configure.in
+++ unixodbc-2.3.1/configure.in
@@ -1,5 +1,6 @@
 dnl Process this file with autoconf to produce a configure script.
 AC_INIT(unixODBC, 2.3.1, n...@unixodbc.org )
+AC_CONFIG_MACRO_DIR([libltdl/m4])
 dnl AC_CONFIG_AUX_DIR([libltdl/config])
 
 AM_INIT_AUTOMAKE(unixODBC, 2.3.1)
diff -u unixodbc-2.3.1/debian/changelog unixodbc-2.3.1/debian/changelog
--- unixodbc-2.3.1/debian/changelog
+++ unixodbc-2.3.1/debian/changelog
@@ -1,3 +1,12 @@
+unixodbc (2.3.1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use AC_CONFIG_MACRO_DIR([libltdl/m4]) in configure.in
+instead of ACLOCAL_AMFLAGS=-I libltdl/m4 in Makefile.am
+to add libltdl/m4 macro directory. Closes: #818407.
+
+ -- John Paul Adrian Glaubitz   Mon, 04 Apr 2016 23:51:00 +0200
+
 unixodbc (2.3.1-4) unstable; urgency=medium
 
   * odbcinst/_SQLGetInstalledDrivers.c: don't open /etc/odbcinst.ini for


signature.asc
Description: OpenPGP digital signature

Bug#819990: [libnvidia-ml1] can not dlopen(libnvidia-ml.so) from app

[Gianfranco Costamagna]

thanks to you both! I just uploaded the fix on Debian.

cheers,

G.




Il Martedì 5 Aprile 2016 10:21, Luca Boccassi  ha 
scritto:




On Apr 5, 2016 08:55, "Christian Beer"  wrote:
>
>
>
> Luca Boccassi schrieb am 04.04.2016 18:59:
>
> >
> > boinc-client should dlopen libnvidia-ml.so.1, which is in the main
> > /usr/lib/*/ path.
> >
> > is the version package by Debian doing this? Or a custom application?
> >
>
>
> I tested this with upstream and dlopening libnvidia-ml.so.1 does the trick. 
> There is a pull request upstream: https://github.com/BOINC/boinc/pull/1522 
> which will flow into the boinc-client package soon after a new Client release.
>
> I CCed the Debian  BOINC maintainer list so they can adopt the patch before 
> that if they want to.
Great, thank you for taking it forward upstream!
Kind regards,
Luca Boccassi


-- 
pkg-boinc-devel mailing list
pkg-boinc-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel

Bug#820070: regression: fails to build c++ headers

[Maximiliano Curia]

Package: dh-acc
Version: 1.99.14-1
Severity: important

Hi,

I've been using dh-acc as part of the KDE autopkgtests for a while now, sadly 
the new version seems to fail C++ projects, where the version in stable works 
fine.

I'm using the following acc file:





5.4.0



/usr/include/KF5/KCoreAddons/



/usr/lib/x86_64-linux-gnu/libKF5CoreAddons.so



-fPIC
-std=c++11
-I/usr/include/x86_64-linux-gnu/qt5
-include /usr/include/x86_64-linux-gnu/qt5/QtCore/QString




The output generated is:

cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not 
for C
In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:41:0,
 from /usr/include/x86_64-linux-gnu/qt5/QtCore/QString:1,
 from :1:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:42:1: error: unknown type name 
‘class’
 class QString;
 ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:46:1: error: expected 
specifier-qualifier-list before ‘public’
 public:
 ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:56:1: warning: data definition 
has no type or storage class
 class Q_CORE_EXPORT QChar {
 ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:56:1: warning: type defaults 
to ‘int’ in declaration of ‘class’ [-Wimplicit-int]
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:56:21: error: expected ‘,’ or 
‘;’ before ‘QChar’
 class Q_CORE_EXPORT QChar {
 ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:537:1: warning: data 
definition has no type or storage class
 Q_DECLARE_TYPEINFO(QChar, Q_MOVABLE_TYPE);
 ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:537:1: warning: type defaults 
to ‘int’ in declaration of ‘Q_DECLARE_TYPEINFO’ [-Wimplicit-int]
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:537:1: warning: parameter 
names (without types) in function declaration
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:539:35: error: expected ‘=’, 
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘:’ token
 Q_DECL_CONSTEXPR inline char QChar::toLatin1() const { return ucs > 0xff ? 
'\0' : char(ucs); }
   ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:540:25: error: unknown type 
name ‘QChar’
 Q_DECL_CONSTEXPR inline QChar QChar::fromLatin1(char c) { return 
QChar(ushort(uchar(c))); }
 ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:540:36: error: expected ‘=’, 
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘:’ token
 Q_DECL_CONSTEXPR inline QChar QChar::fromLatin1(char c) { return 
QChar(ushort(uchar(c))); }
^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:542:18: error: expected ‘=’, 
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘:’ token
 inline void QChar::setCell(uchar acell)
  ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:544:18: error: expected ‘=’, 
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘:’ token
 inline void QChar::setRow(uchar arow)
  ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:547:25: error: unknown type 
name ‘bool’
 Q_DECL_CONSTEXPR inline bool QChar::isSpace(uint ucs4)
 ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:547:35: error: expected ‘=’, 
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘:’ token
 Q_DECL_CONSTEXPR inline bool QChar::isSpace(uint ucs4)
   ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:553:25: error: unknown type 
name ‘bool’
 Q_DECL_CONSTEXPR inline bool QChar::isLetter(uint ucs4)
 ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:553:35: error: expected ‘=’, 
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘:’ token
 Q_DECL_CONSTEXPR inline bool QChar::isLetter(uint ucs4)
   ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:558:25: error: unknown type 
name ‘bool’
 Q_DECL_CONSTEXPR inline bool QChar::isNumber(uint ucs4)
 ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:558:35: error: expected ‘=’, 
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘:’ token
 Q_DECL_CONSTEXPR inline bool QChar::isNumber(uint ucs4)
   ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:560:25: error: unknown type 
name ‘bool’
 Q_DECL_CONSTEXPR inline bool QChar::isLetterOrNumber(uint ucs4)
 ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:560:35: error: expected ‘=’, 
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘:’ token
 Q_DECL_CONSTEXPR inline bool QChar::isLetterOrNumber(uint ucs4)
   ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:566:25: error: unknown type 
name ‘bool’
 Q_DECL_CONSTEXPR inline bool QChar::isDigit(uint ucs4)
 ^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:566:35: error: expected ‘=’, 
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘:’ token
 Q_DECL_CONSTEXPR inline bool QChar::isDigit(uint ucs4)
   

Bug#783063: Xen domU freeze with "Guest Rx stalled"

[Wolodja Wentland]

Hello,

we have been observing this behaviour over the last couple of months and
can report that it still happens with recent kernels in
wheezy-backports.

In particular the following kernels where used:

Dom0: 3.16.7-ckt11-1+deb8u6~bpo70+1
DomU: 3.16.7-ckt20-1+deb8u3~bpo70+1

We still only see this with PV guests. How could we investigate this
further and/or solve the issue?
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC

Bug#820071: bugs.debian.org: #812948 lost the connection to the corresponding source package

[Andreas Beckmann]

Package: bugs.debian.org
Severity: important

Hi,

https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=libbson

lists no bugs at all, but I knew I had filed one some time ago:

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

which also doesn't indicate a source package at all.

PTS: https://packages.qa.debian.org/libb/libbson.html

Maybe it's related to libbson only being in experimental, not in sid.


Andreas

Bug#819703: you miss the point so much that you should stop shipping xscreensaver

[Daniel Shahaf]

Marc Haber wrote on Tue, Apr 05, 2016 at 10:38:16 +0200:
> Eli the Bearded wrote:
> > A version, today, over about five months old is going to have at least
> > one security hole: you can crash out of the password prompt (at least in
> > some cases) by hot swapping monitors at a critical time.
> 
> CVE number?

I'm not Eli, but I believe he's referring to CVE-2015-8025 (#802914),
which was fixed in 5.30-1+deb8u1 that was uploaded to jessie-security on
2015-10-25.

I don't know how long the fix had been publicly available for before it
was uploaded to jessie-security.

Cheers,

Daniel

Bug#820072: synfig: please make the build reproducible (timestamps)

[Alexis Bienvenüe]

Source: synfig
Version: 1.0.2-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

While working on the “reproducible builds” effort [1], we have noticed
that 'synfig' could not be built reproducibly.

The attached patch removes build date from info output. Once applied,
synfig can be built reproducibly in our current experimental framework.

Regards,
Alexis Bienvenüe.

 [1]: https://wiki.debian.org/ReproducibleBuilds


diff -Nru synfig-1.0.2/debian/patches/series synfig-1.0.2/debian/patches/series
--- synfig-1.0.2/debian/patches/series	2015-11-27 10:31:17.0 +0100
+++ synfig-1.0.2/debian/patches/series	2016-04-05 10:36:15.0 +0200
@@ -1,2 +1,3 @@
 c++11.patch
 #no-mod_ffmpeg.patch
+strip-build-date.patch
diff -Nru synfig-1.0.2/debian/patches/strip-build-date.patch synfig-1.0.2/debian/patches/strip-build-date.patch
--- synfig-1.0.2/debian/patches/strip-build-date.patch	1970-01-01 01:00:00.0 +0100
+++ synfig-1.0.2/debian/patches/strip-build-date.patch	2016-04-05 10:37:25.0 +0200
@@ -0,0 +1,27 @@
+Description: Strip build date from source
+ Strip build date from source, to get reproducible build.
+ see https://wiki.debian.org/ReproducibleBuilds
+Author: Alexis Bienvenüe 
+
+--- synfig-1.0.2.orig/src/synfig/main.cpp
 synfig-1.0.2/src/synfig/main.cpp
+@@ -110,7 +110,7 @@ synfig::get_version()
+ const char *
+ synfig::get_build_date()
+ {
+-	return __DATE__;
++	return "Unknown";
+ }
+ 
+ bool
+--- synfig-1.0.2.orig/src/tool/optionsprocessor.cpp
 synfig-1.0.2/src/tool/optionsprocessor.cpp
+@@ -193,7 +193,7 @@ void OptionsProcessor::process_info_opti
+ #ifdef DEVEL_VERSION
+ 			cout << endl << DEVEL_VERSION << endl << endl;
+ #endif
+-		cout << "Compiled on " __DATE__ /* " at "__TIME__ */;
++cout << "Compiled ";
+ #ifdef __GNUC__
+ 		cout << " with GCC " << __VERSION__;
+ #endif

Bug#819877: xserver-xorg-video-intel: mixxx application crashes with error "i915BindProgram: Assertion `p->on_hardware == 0' failed"

[Julien Cristau]

On Sun, Apr  3, 2016 at 13:46:34 +0200, David Nadasi wrote:

> Package: xserver-xorg-video-intel
> Version: 2:2.99.917-2~bpo8+1
> Severity: normal
> 
> Dear Maintainer,
> 
> The application "mixxx" crashes on startup with the following message :
> mixxx: ../../../../../../../src/mesa/
> drivers/dri/i915/i915_fragprog.c :1273 : i915BindProgram: Assertion
> `p->on_hardware == 0' failed
> 
> I've compiled the last stable source code of mixxx and tried to run it, the
> same crash occurs.
> Searching on the mixxx forums lead me to try the following command :
> QT_GL_USE_OPENGL1ENGINE=1 mixxx
> In this case, the application starts well, but the interface remains buggy
> : trying to start 2 tracks on same time and the app crash again with the
> same message.
> In mixxx forums, ubuntu users seems to correct this with the installation
> of the intel i915 driver. This is why I report the bug here.
> I've also installed the jessie-backport package wich doesn't resolve the
> problem.
> 
That sounds like a GL issue rather than an X issue...

Cheers,
Julien

Bug#820062: orthanc and orthanc-doc: error when trying to install together

[Andreas Beckmann]

Control: reassign -1 src:orthanc 1.0.0+dfsg-2
Control: retitle -1 building only arch:all packages broken: orthanc-doc 
contains everything

On Tue, 5 Apr 2016 09:06:57 +0200 (CEST) =?utf-8?Q?S=C3=A9bastien?= Jodogne 
 wrote:
> Hello,
> 
> Thank for reporting this issue. However, I need help: I am indeed unable to 
> reproduce it...
> 
> According to your report, the file 
> "/usr/lib/orthanc/libModalityWorklists.so.1.0.0" lies both in package 
> "orthanc" and "orthanc-doc":
> 
> >
> /var/cache/apt/archives/orthanc-doc_1.0.0+dfsg-2_all.deb (--unpack):
>  trying to overwrite '/usr/lib/orthanc/libModalityWorklists.so.1.0.0', which
>  is also in package orthanc 1.0.0+dfsg-2
> <
> 
> However, when I list the content of the "orthanc-doc" generated by my local 
> pbuilder, this file is not present inside the package:

Try an binary-indep-only build ... like it is done on the buildds

-rw-r--r-- 1 beckmann beckmann   175168 Dec 16 14:54 
orthanc-doc_1.0.0+dfsg-1_all.deb
-rw-r--r-- 1 beckmann beckmann 10117292 Apr  4 18:42 
orthanc-doc_1.0.0+dfsg-2_all.deb

https://buildd.debian.org/status/fetch.php?pkg=orthanc&arch=all&ver=1.0.0%2Bdfsg-2&stamp=1459787146


Andreas

Bug#820073: diaspora-common: modified shipped files: /usr/share/diaspora-common/{database.yml, diaspora.conf}

[Andreas Beckmann]

Package: diaspora-common
Version: 0.5.7.1+debian2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package modifies files it has
shipped in /usr.

>From the attached log (scroll to the bottom...):

1m54.3s ERROR: FAIL: debsums reports modifications inside the chroot:
  /usr/share/diaspora-common/database.yml
  /usr/share/diaspora-common/diaspora.conf


cheers,

Andreas
~  


diaspora-common_0.5.7.1+debian2.log.gz
Description: application/gzip

Bug#819703: you miss the point so much that you should stop shipping xscreensaver

[Hilko Bengen]

* Daniel Shahaf:

> I'm not Eli, but I believe he's referring to CVE-2015-8025 (#802914),
> which was fixed in 5.30-1+deb8u1 that was uploaded to jessie-security on
> 2015-10-25.
>
> I don't know how long the fix had been publicly available for before it
> was uploaded to jessie-security.

Since there is no public VCS, all we can go by is the date stamp from
xscreensaver-5.34/utils/version.h: 24-Oct-2015.

Cheers,
-Hilko

Bug#820071: bugs.debian.org: #812948 lost the connection to the corresponding source package

[Andreas Beckmann]

Also the list of Bugs in packages maintained by no one (packages without
maintainers)
  https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=
has suddenly grown to > 1000 bugs. IIRC, less than a month ago this has
been down to about a dozen bugs.


Andreas

Bug#820074: debian-installer: installer fails on "select an install software" on systemd package

[twied]

Package: debian-installer
Severity: important
Tags: d-i

Dear Maintainer,

I tried to install Debian Testing in a VM, which failed in the "select and
install software" step.

Installer iso (sha1sum):
c672951a58e47f1adaf780b1879d236fbe68484a  debian-stretch-DI-
alpha5-amd64-netinst.iso

VM config:
/usr/bin/kvm  -soundhw es1370 -k de -enable-kvm -m 1024 -localtime -cdrom
debian-stretch-DI-alpha5-amd64-netinst.iso -hda test.hdd -boot once=d,menu=off
-net nic,vlan=0 -net user,vlan=0 -name "Debian"

Steps taken / items selected:
"Graphical Install" (happens in text mode, too)
Language: English
Location: United States
Keymap: American English
Hostname: debian
Domainname:
Root password: root
User full name: user
username: user
User password: user
Time zone: Eastern
Parition disks: Guided / use entire disk (SCSI1 (0,0,0) (sda) - 10.7 GB ATA
QEMU HARDDISK) / All files in one partition
Archive mirror: United States (ftp.us.debian.org)
HTTP proxy:

"Select and install software"
Installation step failed
An installation step failed. You can try to run the failing item again from the
menu, or skip it and choose something else. The failing step is: Select and
install software
(Continue and retry that step fails again)

Ctrl-Alt-F4:
...
in-target: update-initramfs: Generating /boot/initrd.img-4.3.0-1-amd64
in-target: Errors were encountered while processing:
in-target:  systemd
kernel: [...] ISO 9660 Extensions: Microsoft Joliet Level 3
kernel: [...] ISO 9660 Extensions: RRIP_1991A
main-menu[343]: WARNING **: Configuring 'pkgsel' failed with error code 100
main-menu[343]: WARNING **: Menu item 'pkgsel' failed.

Ctrl-Alt-F2:

chroot target
bash
apt-get install systemd
(some output, including warnings about me not having mounted /dev/pts;
otherwise installs just fine)
exit
exit

Ctrl-Alt-F5:
Continue, Continue -> everything works, next step is "Configuring popularity-
contest"



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#819425: debian-games: d/control is autogenerated but instructions are wrong

[Andreas Tille]

Fixed in Git.

On Mon, Mar 28, 2016 at 03:58:07PM +0200, Markus Koschany wrote:
> Control: reassign -1 src:blends
> Control: severity -1 minor
> 
> Am 28.03.2016 um 15:41 schrieb Markus Koschany:
> > Control: reassign -1 src:blends-dev
> > Control: severity -1 minor
> > 
> > Am 28.03.2016 um 13:58 schrieb Tobias Frost:
> >> Source: debian-games
> >> Version: 1.2
> >> Severity: normal
> >>
> >> Hi Markus,
> >>
> >> d/control reads:
> >> # This file is autogenerated via make -f debian/rules dist.  Do not edit!
> >>
> >> However the indicated command fails:
> >> make -f debian/rules dist
> >> dh dist
> >> dh: Unknown sequence dist (choose from: binary binary-arch binary-indep 
> >> build build-arch build-indep clean install install-arch install-indep)
> >> /usr/share/blends-dev/rules:33: recipe for target 'dist' failed
> >> make: *** [dist] Error 25
> >>
> >> Installed version of blends-dev:
> >>
> >> i  blends-dev 0.6.92.5 all  Debian Pure 
> >> Blends common files for developing me
> >>
> >>
> >> (This can be of course a bug in blends-dev, I'm not familiar with that 
> >> tool)
> > 
> > Hi Tobi,
> > 
> > the correct command is "make dist" unless someone created a dist target
> > in debian/rules. I think it is just a documentation bug in
> > src:blends-dev. This string should possibly be updated in devtools/Makefile.
> > 
> > Regards,
> > 
> > Markus
> 
> Should be src:blends of course.
> 
> 
> 
> 
> 




-- 
http://fam-tille.de

Bug#820075: debian-edu-config: fails to purge: rmdir: failed to remove '/var/lib/dovecot': No such file or directory

[Andreas Beckmann]

Package: debian-edu-config
Version: 1.819
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to purge.
According to policy 7.2 you cannot rely on the depends being available
during purge, only the essential packages are available for sure.

Filing this as important because a.) it's a clear policy violation (to
not clean up at purge) b.) having a piuparts clean archive is a release
goal since lenny and c.) this package being piuparts buggy blocks
packages depending on it from being tested by piuparts (and thus
possibly the detection of more severe problems).

>From the attached log (scroll to the bottom...):

  Removing debian-edu-config (1.819) ...
  Purging configuration files for debian-edu-config (1.819) ...
  rmdir: failed to remove '/var/lib/dovecot': No such file or directory
  dpkg: error processing package debian-edu-config (--purge):
   subprocess installed post-removal script returned error exit status 1
  Errors were encountered while processing:
   debian-edu-config


cheers,

Andreas


debian-edu-config_1.819.log.gz
Description: application/gzip

Bug#820038: Copy signatures into udebs

[Ben Hutchings]

On Mon, 2016-04-04 at 22:20 -0700, Jose R R wrote:
> Thus, in practice it means that an out of Linux source tree module,
> like Reiser4, will be a reason for Debian-Installer (d-i) to baulk at
> install?

If Secure Boot is enabled, all unsigned modules will be rejected by the
kernel.  But this is better than the current state where we don't boot
at all - only those users that need or want OOT modules will need to
disable it.

Debian could apply a similar signing procedure to binary packages of
OOT modules - if they're in the archive.  Unofficial and non-free
packages will surely not be signed by Debian.

I intend to look at and maybe include (depending on how invasive it is)
David Howells' patchset, included in Red Hat distributions, that allows
the kernel to load trusted certificates from EFI variables.  That would
allow users to enrol trusted certificates for other OOT modules in the
boot loader (shim).

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot


signature.asc
Description: This is a digitally signed message part

Bug#820077: get-iplayer: Seems to have stopped working altogether

[Axel]

Package: get-iplayer
Version: 2.94-1
Severity: important

Dear Maintainer,

programme listings (“last_week.xml”) are longer downloaded and neither are any 
programmes.

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

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

Versions of packages get-iplayer depends on:
ii  libwww-perl 6.08-1
ii  libxml-simple-perl  2.20-1
ii  perl5.20.2-3+deb8u4
ii  rtmpdump2.4+20150115.gita107cef-1

Versions of packages get-iplayer recommends:
ii  atomicparsley 0.9.2~svn110-4
ii  id3v2 0.1.12-2.1
ii  libmp3-info-perl  1.24-1

Versions of packages get-iplayer suggests:
ii  libav-tools 6:11.6-1~deb8u1
ii  mplayer2 [mplayer]  2.0-728-g2c378c7-4+b1

-- no debconf information

Bug#820076: tt-rss: fails to purge - command ucf in postrm not found

[Andreas Beckmann]

Package: tt-rss
Version: 15.7+git20151123+dfsg-4
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to purge due
to a command not found. According to policy 7.2 you cannot rely on the
depends being available during purge, only the essential packages are
available for sure.

Please see the manpages ucf(1), ucfr(1) and the example maintainer
scripts under /usr/share/doc/ucf/examples/ for correct usage of ucf.

Filing this as important because a.) it's a clear policy violation (to
not clean up at purge) b.) having a piuparts clean archive is a release
goal since lenny and c.) this package being piuparts buggy blocks
packages depending on it from being tested by piuparts (and thus
possibly the detection of more severe problems).

>From the attached log (scroll to the bottom...):

  Removing tt-rss (15.7+git20151123+dfsg-4) ...
  Purging configuration files for tt-rss (15.7+git20151123+dfsg-4) ...
  /var/lib/dpkg/info/tt-rss.postrm: 42: /var/lib/dpkg/info/tt-rss.postrm: ucf: 
not found
  dpkg: error processing package tt-rss (--purge):
   subprocess installed post-removal script returned error exit status 127
  Errors were encountered while processing:
   tt-rss


cheers,

Andreas


tt-rss_15.7+git20151123+dfsg-4.log.gz
Description: application/gzip

Bug#819587: vite: Please consider packaging a fresh svn version

[Samuel Thibault]

Samuel Thibault, on Mon 04 Apr 2016 10:34:04 +0200, wrote:
> Martin Quinson, on Wed 30 Mar 2016 23:07:45 +0200, wrote:
> > The r1430 is already almost 2 years old, and we start advising to our users 
> > to
> > not go for the debian package but for the svn version. This is somehow
> > suboptimal, and I'd be thankful if you could update the package at some 
> > point.
> 
> I'm wondering: what makes you request to use the svn version?  AFAIK
> The svn contains only 3 new commits: an option for using qt5 (which
> we already use in Debian), a fix for segfault at application closing,
> and a fix for a "crash when doing stats on states which don't have a
> container", which IIRC only happens on bogus traces.

And that fix is already applied as a patch in Debian.

So I'm really wondering what a newer upstream snapshot would bring :)

Samuel

Bug#820008: Support for securelevel and Secure Boot

[Ben Hutchings]

On Tue, 2016-04-05 at 09:34 +0200, Florian Weimer wrote:
> * Ben Hutchings:
> 
> > 
> > To ensure the integrity of the kernel, we should support a securelevel
> > where all modules must be signed by a trusted key and all APIs
> > allowing arbitrary memory writes are disabled.
> What is a trusted key?  I'm not convinced we can align this with
> Debian's principles.

The built-in trusted key will be created by the Debian FTP team - just
like the keys they use to sign releases..

(For initial testing, I'm using my own key pair so we can work in
parallel.)

[...]
> Maybe we should discuss this on debian-project?
[...]

This has been discussed many times over the past years.  A short
summary of what was agreed at DebConf 13:

https://lists.debian.org/<1376427261.11676.35.ca...@deadeye.wl.decadent.org.uk>

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot

signature.asc
Description: This is a digitally signed message part

Bug#820078: pass: wanna keepass2csv2pass.py

[Shell.Xu]

Package: pass
Version: 1.6.5-3
Severity: wishlist

Dear Maintainer,
I use keepassx and it can export just keepass2 csv format.
keepass2csv2pass.py is the migreating utilite for that format. I found it in
main page (https://www.passwordstore.org/), but not in debian package. Can you
add this file in debian package?
Thank you for your time.
 Sincerely
  Shell.Xu



-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages pass depends on:
ii  gnupg   1.4.20-4
ii  gnupg2  2.1.11-6
ii  pwgen   2.07-1.1
ii  tree1.7.0-3

Versions of packages pass recommends:
ii  git 1:2.8.0~rc3-1
ii  gnupg2  2.1.11-6
ii  xclip   0.12+svn84-4

Versions of packages pass suggests:
pn  libxml-simple-perl  
ii  perl5.22.1-9
ii  ruby1:2.3.0+1

-- no debconf information

Bug#820079: pcmanfm-qt: missing dependancy: dbus-x11

[twied]

Package: pcmanfm-qt
Severity: normal

Dear Maintainer,

without the package "dbus-x11" installed, pcmanfm-qt does not start.
The package is not installed when installing the packages "xorg" and "lxqt"
without recommends.

Unrelated warning in the terminal:
** Message: x-terminal-emulator has very limited support, consider choose
another terminal

Regards,
Tim



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#820071: bugs.debian.org: #812948 lost the connection to the corresponding source package

[Adam D. Barratt]

On 2016-04-05 10:06, Andreas Beckmann wrote:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=libbson

lists no bugs at all, but I knew I had filed one some time ago:

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

which also doesn't indicate a source package at all.

PTS: https://packages.qa.debian.org/libb/libbson.html

Maybe it's related to libbson only being in experimental, not in sid.


That would make at least some sense, given the recent archive changes. 
Specifically, bugs-master:/srv/bugs.debian.org/home/update-sources 
appears to look for {Packages,Sources}.gz and spawn zcat.


Regards,

Adam

Bug#820081: libreoffice-writer: can't open LibreOffice Writer

[Pierre Crescenzo]

Package: libreoffice-writer
Version: 1:5.1.2~rc1-1
Severity: important

Hello,

I can't open LibreOffice Writer. I always have the "Récupération de documents
LibreOffice" ("LibreOffice Document Recovery") windows, with no document. And
Writer crashes without message.

And if i try to open an existing document (odf or doc or docx), I always have
the same "Récupération de documents LibreOffice" ("LibreOffice Document
Recovery") windows, with this document. And the recovery fails. And Writer
crashes without message.

I have delete the ".config/libreoffice" directory but no change.

No problem with other LibreOffice parts: Calc or Impress are OK.

Thank you!



-- System Information:
Debian Release: stretch/sid
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-rt-686-pae (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libreoffice-writer depends on:
ii  libabw-0.1-1   0.1.1-2
ii  libc6  2.22-5
ii  libe-book-0.1-10.1.2-2+b1
ii  libetonyek-0.1-1   0.1.6-1
ii  libgcc11:5.3.1-13
ii  libicu55   55.1-7
ii  libmwaw-0.3-3  0.3.7-1
ii  libodfgen-0.1-10.1.6-1
ii  libreoffice-base-core  1:5.1.2~rc1-1
ii  libreoffice-core   1:5.1.2~rc1-1
ii  librevenge-0.0-0   0.0.4-4
ii  libstdc++6 5.3.1-13
ii  libwpd-0.10-10 0.10.1-1
ii  libwpg-0.3-3   0.3.1-1
ii  libwps-0.4-4   0.4.3-1
ii  libxml22.9.3+dfsg1-1
ii  uno-libs3  5.1.2~rc1-1
ii  ure5.1.2~rc1-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages libreoffice-writer recommends:
ii  libreoffice-math  1:5.1.2~rc1-1

Versions of packages libreoffice-writer suggests:
ii  default-jre [java5-runtime]2:1.8-57
ii  fonts-crosextra-caladea20130214-1
ii  fonts-crosextra-carlito20130920-1
ii  gcj-4.8-jre [java5-runtime]4.8.5-4
ii  gcj-4.9-jre [java5-runtime]4.9.3-12
ii  gcj-5-jre [java5-runtime]  5.3.1-13
ii  gcj-jre [java5-runtime]4:5.3.1-1
ii  libreoffice-base   1:5.1.2~rc1-1
pn  libreoffice-gcj
ii  libreoffice-java-common1:5.1.2~rc1-1
ii  openjdk-7-jre [java5-runtime]  7u95-2.6.4-1~deb8u1
ii  openjdk-8-jre [java5-runtime]  8u72-b15-4

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.4
ii  fonts-opensymbol  2:102.7+LibO5.1.2~rc1-1
ii  libboost-date-time1.58.0  1.58.0+dfsg-5+b1
ii  libc6 2.22-5
ii  libcairo2 1.14.6-1
ii  libclucene-contribs1v52.3.3.4-4.1
ii  libclucene-core1v52.3.3.4-4.1
ii  libcmis-0.5-5v5   0.5.1-2
ii  libcups2  2.1.3-5
ii  libcurl3-gnutls   7.47.0-1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.106-1
ii  libdconf1 0.24.0-2
ii  libeot0   0.01-3
ii  libexpat1 2.1.1-1
ii  libexttextcat-2.0-0   3.4.4-1
ii  libfontconfig12.11.0-6.4
ii  libfreetype6  2.6.3-3
ii  libgcc1   1:5.3.1-13
ii  libgl1-mesa-glx [libgl1]  11.1.2-1
ii  libglew1.13   1.13.0-2
ii  libglib2.0-0  2.48.0-1
ii  libgltf-0.0-0v5   0.0.2-4+b1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgraphite2-31.3.7-1
ii  libharfbuzz-icu0  1.0.1-1+b1
ii  libharfbuzz0b 1.0.1-1+b1
ii  libhunspell-1.3-0 1.3.3-4
ii  libhyphen02.8.8-2
ii  libice6   2:1.0.9-1+b1
ii  libicu55  55.1-7
ii  libjpeg62-turbo   1:1.4.2-2
ii  liblangtag1   0.5.7-2
ii  liblcms2-22.6-3+b3
ii  libldap-2.4-2 2.4.42+dfsg-2+b2
ii  libmythes-1.2-0   2:1.2.4-1
ii  libneon27-gnutls  0.30.1-3
ii  libnspr4  2:4.12-1
ii  libnss3   2:3.23-1
ii  libodfgen-0.1-1   0.1.6-1
ii  libpcre3  2:8.38-3.1
ii  libpng12-01.2.54-4
ii  librdf0   1.0.17-1+b1
ii  libreoffice-common1:5.1.2~rc1-1
ii  librevenge-0.0-0  0.0.4-4
ii  libsm62:1.2.2-1+b1
ii  libssl1.0.2   1.0.2g-1
ii  libstdc++65.3.1-13
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxml2   2.9.3+dfsg1-1
ii  libxrandr22:1.5.0-1
ii  libxrender1   1:0.9.9-2
ii  libxslt1.11.1.28-2.1
ii  uno-libs3 5.1.2~rc1-1
ii  ure   5.1.2~rc1-1
ii  zlib1g1:1.2.8.dfsg-2+b1

-- no debconf information

Bug#819943: really should add an unforbid-version command

[Manuel A. Fernandez Montecelo]

2016-04-05 04:09 積丹尼 Dan Jacobson:

So indeed in the man page

  To remove the forbidden version without installing the
  candidate version, the current version should be appended: "install
  =".


is utterly totally wrong. Please remove it.



 # aptitude search --disable-columns -F '%c%a%M %p %v %V' debian-keyring
 i  debian-keyring 2016.01.20 2016.03.22

 # aptitude forbid-version debian-keyring=2016.03.22
 No packages will be installed, upgraded, or removed.
 0 packages upgraded, 0 newly installed, 0 to remove and 185 not upgraded.
 Need to get 0 B of archives. After unpacking 0 B will be used.

 # aptitude search --disable-columns -F '%c%a%M %p %v %V' debian-keyring
 iF debian-keyring 2016.01.20 2016.03.22

 # aptitude install debian-keyring=2016.01.20
 debian-keyring is already installed at the requested version (2016.01.20)
 debian-keyring is already installed at the requested version (2016.01.20)
 No packages will be installed, upgraded, or removed.
 0 packages upgraded, 0 newly installed, 0 to remove and 184 not upgraded.
 Need to get 0 B of archives. After unpacking 0 B will be used.
 Current status: 185 (+1) upgradable.

 # aptitude search --disable-columns -F '%c%a%M %p %v %V' debian-keyring
 i  debian-keyring 2016.01.20 2016.03.22

Q.E.D.

I.e., works as intended and documented.



set debian-reference-en
aptitude forbid-version $@
aptitude search $@ #shows F
aptitude install $@=2.59 # abort with n, we don't want to install it.
aptitude search $@ #still F


Exactly, because by saying "n" you didn't complete the action to "remove
the forbid on that version".

Installing a version that it's already installed is harmless, so you
don't need to say no.

So again it works as expected and documented.  You wouldn't want the
state modified if you reply "no" to a question to modify the state, that
would be a much more serious bug.



Please change it to

  Currently there is no way to remove the forbidden version without 
installing the
  candidate version.

Or better

  Currently there is no way to remove the forbidden version NOTATION 
without installing the
  candidate version.


Nope.


Also, more in general, it would be useful if you stop reporting
duplicate bugs reported only weeks ago (often by you, e.g. 773023 and
804103) or looking for unexisting problems, then discussing to death and
looking for further things to modify in the same bug report so they can
never be closed.

That keeps maintainers wasting time chasing and handling bug reports
rather than working on more important problems, and wasting time
repeating again and again the reasons why they don't want to change
things that you suggest.

If the reason why you don't try to avoid duplicate bugs is
"but... but... there are too many!", consider whether your actions
submitting dozens of inane bugs or duplicates to aptitude without
searching for them is contributing to piling lots of bugs that then are
difficult to triage and search; or if they are of any benefit to the
advancement of aptitude as a whole to deal with these inane and
duplicate reports rather than working on more important issues.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#820082: libmono-security4.0-cil: fails to reinstall: mv: cannot stat '/usr/share/.mono/*': No such file or directory

[Andreas Beckmann]

Package: libmono-security4.0-cil
Version: 4.2.1.102+dfsg2-6
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

0m44.8s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmp8B6HJN', 
'apt-get', '-y', 'install', '--reinstall', 
'libmono-security4.0-cil=4.2.1.102+dfsg2-6']
0m46.2s DUMP: 
  Reading package lists...
  Building dependency tree...
  Reading state information...
  debconf: delaying package configuration, since apt-utils is not installed
  0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
  Need to get 0 B/126 kB of archives.
  After this operation, 0 B of additional disk space will be used.
  (Reading database ... 
(Reading database ... 7740 files and directories currently installed.)
  Preparing to unpack .../libmono-security4.0-cil_4.2.1.102+dfsg2-6_all.deb ...
  Found cert store in old location, moving to /etc/mono/certstore
  mv: cannot stat '/usr/share/.mono/*': No such file or directory
  dpkg: error processing archive 
/var/cache/apt/archives/libmono-security4.0-cil_4.2.1.102+dfsg2-6_all.deb 
(--unpack):
   subprocess new pre-installation script returned error exit status 1
  Errors were encountered while processing:
   /var/cache/apt/archives/libmono-security4.0-cil_4.2.1.102+dfsg2-6_all.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)
0m46.2s ERROR: Command failed (status=100): ['chroot', 
'/tmp/piupartss/tmp8B6HJN', 'apt-get', '-y', 'install', '--reinstall', 
'libmono-security4.0-cil=4.2.1.102+dfsg2-6']

This problem was observed while reinstalling the same version of
the package, again.

cheers,

Andreas


libmono-security4.0-cil_4.2.1.102+dfsg2-6.log.gz
Description: application/gzip

Bug#820080: libpetsc{-, complex-}3.6.3-dev: leaves alternatives after purge: /etc/alternatives/libpetsc_{real, complex}.so

[Andreas Beckmann]

Package: libpetsc-complex-3.6.3-dev,libpetsc3.6.3-dev
Version: 3.6.3.dfsg2-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

The leftover files are actually alternatives that were installed by the
package but have not been properly removed.

While there is ongoing discussion how to remove alternatives correctly
(see https://bugs.debian.org/71621 for details) the following strategy
should work for regular cases:
* 'postinst configure' always installs the alternative
* 'prerm remove' removes the alternative
* 'postrm remove' and 'postrm disappear' remove the alternative
In all other cases a maintainer script is invoked (e.g. upgrade,
deconfigure) the alternatives are not modified to preserve user
configuration.
Removing the alternative in 'prerm remove' avoids having a dangling link
once the actual file gets removed, but 'prerm remove' is not called in
all cases (e.g. unpacked but not configured packages or disappearing
packages) so the postrm must remove the alternative again
(update-alternatives gracefully handles removal of non-existing
alternatives).

Note that the arguments for adding and removing alternatives differ, for
removal it's 'update-alternatives --remove  '.

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

1m25.9s ERROR: FAIL: Package purging left files on system:
  /etc/alternatives/libpetsc_complex.so -> 
/usr/lib/x86_64-linux-gnu/libpetsc_complex.so.3.6.3   not owned
  /usr/lib/x86_64-linux-gnu/libpetsc_complex.so -> 
/etc/alternatives/libpetsc_complex.so not owned

1m39.6s ERROR: FAIL: Package purging left files on system:
  /etc/alternatives/libpetsc_real.so -> 
/usr/lib/x86_64-linux-gnu/libpetsc_real.so.3.6.3 not owned
  /usr/lib/x86_64-linux-gnu/libpetsc_real.so -> 
/etc/alternatives/libpetsc_real.so   not owned


cheers,

Andreas


libpetsc-complex-3.6.3-dev_3.6.3.dfsg2-1.log.gz
Description: application/gzip

Bug#796058: libreoffice: app seems to hang itself

[Rene Engelhard]

Hi,

[ > 6 months later ...]

> I don't believe so.
> 
> > open a document. edit something. save it. make a new document.
> > (copy-paste some html page, nobody really cares from where.)
> 
> Only with copy-paste some html page? That was a recipe for disaster a few
> times already Or also with "normal" usage?
> 
> > now minimize libreoffice for while. You are no longer able to return to the
> > editor. It acts like vram is messed up or dodgy and fails to redraw itself.
> > maximize, minimize, all for nothing. Its dead Jim.
> 
> Hmm. That also was symptoms ("hang") in the above back in the past. You don't
> even need to minimize it.
> 
> > Note: I am using the autolauncher. It seems to help loading times.
> > It should also be prelinked and preloaded as both packages are setup and
> > running.

The "quickstarter" will be removed in next upload. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819878.

Does it make a difference if you don't use the Quickstarter?

> a VM or somesuch) but I honestly doubt this is as severe and grave you
> make it look it is... Especially as noone reported it so far the time this
> was in unstable and then testing

Do you still have it?

Otherwise I am seriously pondering to just close this...

Regards,

Rene

Bug#820083: gridengine-drmaa-dev: fails to install: update-alternatives: error: alternative path /usr/lib/gridengine-drmaa/lib/libdrmaa.so doesn't exist

[Andreas Beckmann]

Package: gridengine-drmaa-dev
Version: 8.1.8+dfsg-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package gridengine-drmaa-dev.
  (Reading database ... 
(Reading database ... 7660 files and directories currently installed.)
  Preparing to unpack .../gridengine-drmaa-dev_8.1.8+dfsg-3_amd64.deb ...
  Unpacking gridengine-drmaa-dev (8.1.8+dfsg-3) ...
  Setting up gridengine-drmaa-dev (8.1.8+dfsg-3) ...
  update-alternatives: error: alternative path 
/usr/lib/gridengine-drmaa/lib/libdrmaa.so doesn't exist
  dpkg: error processing package gridengine-drmaa-dev (--configure):
   subprocess installed post-installation script returned error exit status 2
  Errors were encountered while processing:
   gridengine-drmaa-dev


cheers,

Andreas


gridengine-drmaa-dev_8.1.8+dfsg-3.log.gz
Description: application/gzip

Bug#820084: chroot default value in master.cf changed from yes to no in Postfix 3.0 - init script needs to reflect this

[Marcel Meckel]

Package: os-prober
Version: 3.0.4-5
Severity: normal

when upgrading postfix from jessie to (yet unreleased stretch) postfix 
warns
that master.cf my contain default value '-' for the chroot column but 
the default

of that chroot value depends on postfix setting 'compatibility_level'.

Please see http://www.postfix.org/COMPATIBILITY_README.html#chroot for 
more details.


postfix init.d script contains this:

---snip---
config_dir=$($POSTCONF -h config_directory)
# see if anything is running chrooted.
NEED_CHROOT=$(awk '/^[0-9a-z]/ && ($5 ~ "[-yY]") { print "y"; exit}' 
${config_dir}/master.cf)

---snip---

This needs to be modified to take the output of 'postconf 
compatibility_level'

into account.

If compatibility_level < 2 then the default '-' equals do chroot.
If compatibility_level >= 2 then the default '-' equals don't chroot.

Marcel

Bug#819587: vite: Please consider packaging a fresh svn version

[Martin Quinson]

On Tue, Apr 05, 2016 at 11:54:13AM +0200, Samuel Thibault wrote:
> Samuel Thibault, on Mon 04 Apr 2016 10:34:04 +0200, wrote:
> > Martin Quinson, on Wed 30 Mar 2016 23:07:45 +0200, wrote:
> > > The r1430 is already almost 2 years old, and we start advising to our 
> > > users to
> > > not go for the debian package but for the svn version. This is somehow
> > > suboptimal, and I'd be thankful if you could update the package at some 
> > > point.
> > 
> > I'm wondering: what makes you request to use the svn version?  AFAIK
> > The svn contains only 3 new commits: an option for using qt5 (which
> > we already use in Debian), a fix for segfault at application closing,
> > and a fix for a "crash when doing stats on states which don't have a
> > container", which IIRC only happens on bogus traces.
> 
> And that fix is already applied as a patch in Debian.
> 
> So I'm really wondering what a newer upstream snapshot would bring :)

Actually, it seemed to me that the debian package is at svn1430, and
checking on https://gforge.inria.fr/scm/browser.php?group_id=1596 it
seems that the svn is at r1604, which is more than just a few patches
forward.

Commit 1430 seems to be from Fri May 9 13:42:51 2014 UTC (22 months, 3
weeks ago). So, the addition of almost 2 years and over 150 commits
make me think that the package could be updated.

Another argument was that one of our user was experiencing issues with
Vite, leading me to check whether the package was uptodate. But it
turns out that the error was on his side, not on Vite side.

To summarize, you know the package better than I do. Feel free to
close the bug (and pardon me) if you think that I misjudged the
situation.

Bye, Mt.

-- 
VI VI VI The editor of the beast.


signature.asc
Description: PGP signature

Bug#820085: courier-maildrop: fails to install: ln: failed to create symbolic link '/etc/courier/maildroprc': No such file or directory

[Andreas Beckmann]

Package: courier-maildrop
Version: 2.8.3+0.75.0-17
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package courier-maildrop.
  (Reading database ... 
(Reading database ... 7735 files and directories currently installed.)
  Preparing to unpack .../courier-maildrop_2.8.3+0.75.0-17_all.deb ...
  Unpacking courier-maildrop (2.8.3+0.75.0-17) ...
  Setting up courier-maildrop (2.8.3+0.75.0-17) ...
  ln: failed to create symbolic link '/etc/courier/maildroprc': No such file or 
directory
  dpkg: error processing package courier-maildrop (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   courier-maildrop

Please ship /etc/courier as an empty directory in teh package,
*do not* create it manually.


cheers,

Andreas


courier-maildrop_2.8.3+0.75.0-17.log.gz
Description: application/gzip

Bug#816081: dspdfviewer: FTBFS on big-endian architectures (testsuite): 4287168392 != 4294936831

[Danny Edel]

On Sat, 27 Feb 2016 12:27:44 +0100 Danny Edel  wrote:
> I will investigate further and report back here.

I cannot determine the exact cause why it fails on big-endian emulation.
 Also, trying to load any GUI through the emulator just results in a
blank window, so I cannot even check if the resulting binary is all
right (false-positive).  My best guess is that Qt uses OpenGL to
accelerate drawing, which cannot be emulated correctly, meaning this
could be a test failure without anything being wrong.

As a temporary workaround, I have disabled unittests on big-endian
hardware in v1.15-1 (to be uploaded today), until someone with access to
a hardware machine with X11 can help in checking the exact situation.

[help needed]
If you have a big-endian machine with X11 running, please try executing
the software and check if the resulting UI looks okay or the colors are
messed up -- seeing as how blue was always 0xFF, all output should look
blue-tainted if the test suite diagnosed a problem correctly.

If you want to donate some time to this, you can re-activate the
unittests by appending -DRunUnitTestsOnBigEndian=ON to the
dh_auto_configure call in d/rules.

- Danny



signature.asc
Description: OpenPGP digital signature

Bug#820079: [pkg-lxqt-devel] Bug#820079: pcmanfm-qt: missing dependancy: dbus-x11

[陳昌倬]

Control: tags -1 newcomer

On Tue, Apr 05, 2016 at 12:04:06PM +0200, twied wrote:
> without the package "dbus-x11" installed, pcmanfm-qt does not start.
> The package is not installed when installing the packages "xorg" and "lxqt"
> without recommends.

Thanks for the report, I think this one is suitable for newcomer.

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D
  BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#820086: antlr3: v3.5 breaks existing grammars

[olivier sallou]

Package: antlr3
Version: 3.5.2-4
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 switch version to 3.5 from 3.2
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Logol package fails to build. Logol uses antlr to generate some
grammar files. With v3.2, package worked. When upgraded to 3.5, the
generated grammar (parser/lexer) is different with a different behaviour.

I cannot give a specific test, as my grammar rules are quite complex, and
after investigation, I still cannot find the root cause, except the antlr
implication.
It seems this releases introduced new parsing behavior that affects
existing grammars.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages antlr3 depends on:
ii  default-jre-headless [java6-runtime-headless]2:1.8-57
ii  libantlr3-runtime-java   3.5.2-4
ii  libstringtemplate4-java  4.0.8-2
ii  openjdk-8-jre-headless [java6-runtime-headless]  8u77-b03-3

Versions of packages antlr3 recommends:
pn  libstringtemplate-java  

antlr3 suggests no packages.

-- no debconf information

Bug#819998: [Pkg-running-devel] Bug#819998: garmin-forerunner-tools: FTBFS on !linux after switch to libusb 1.0

[Steven Chamberlain]

# waiting on more info from me; see last paragraph
tags 819998 + moreinfo
thanks

Hi!

Christian PERRIER wrote:
> I suppose that this probably affects several packages and not this
> one, only. If so, are there guidelines somewhere about Doing The Right
> Thing?

On kfreebsd we have a libusb2-dev, a different codebase that
provides an interface generally compatible with libusb-1.0 (and others).

Although it has a Provides: libusb-1.0-0-dev, that can only work if the
Build-Depends: libusb-1.0-0-dev doesn't specify a version constrain, and
in this case it does.

This is quite common.  So I typically recommend this:

Build-Depends: libusb-1.0-0-dev (>= 1.0.9) [!kfreebsd-any], libusb2-dev 
[kfreebsd-any]

and I perhaps should add this to some porting FAQ.  Or, perhaps
someone can suggest something better we could do than the Provides:.
(Also note the comma between the alternative dependencies;  a pipe does
not do the obvious thing).

For hurd, there is no USB stack yet, so... I guess there is no solution
at the mooment.  When there is, I'm not sure what the Build-Depends will
need to be.  With the above, it would stay BD-Uninstallable on hurd,
waiting on libusb-1.0-0-dev, which is nice for porters to see clearly it
is waiting on USB support.  The out-of-date package can be decrufted on
hurd-i386 if it is non-functional without USB.


On kfreebsd, the next problem is that garmin-forerunner-tools
./configure uses /usr/bin/$(DEB_HOST_GNU_TYPE)-pkg-config and not the
regular pkg-config.  It scans only the multiarch path such as:

/usr/lib/x86_64-linux-gnu/pkgconfig/libusb-1.0.pc

but on kfreebsd it cannot find the libusb-1.0.pc provided by
libusb2-dev:

/usr/lib/pkgconfig/libusb-1.0.pc

because we did not convert libusb2-dev to multiarched paths yet.

This is the first time I'm seeing this;  I suppose it is caused by
--host=$(DEB_HOST_GNU_TYPE).   I could multiarch libusb2-dev, but I
worry some other packages do the opposite, and look in only
/usr/lib/pkgconfig and not the multiarch paths...

I think I should look into that, do some test rebuilds of reverse-deps
in the archive, and then get back to you.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#820055: Fwd: [pkg-wpa-devel] Bug#820055: wpa_cli interface_add/interface_remove interface_name fails with "UNKNOWN COMMAND"

[Pičugins Arsenijs]

Hello!

I don't think you've understood the situation. I do understand how interfaces 
are added in the system, and I do have two wireless interfaces on my system - 
wlan0 and wlan1. Both are tested and working.
Wpa_supplicant supports managing multiple wireless cards simultaneously - there 
are fancy command line switches for it and so on. There's a "interface_add" 
command which can be passed to a running wpa_supplicant instance which is 
already managing one card, and that command tells it it has one more interface 
to manage. From what I've understood, wpa_cli accepts this command, passes it 
through a control socket to a running wpa_supplicant instance and receives an 
"UNKNOWN COMMAND" reply message for some reason. That's the problem I'm dealing 
with.

Best regards,
Arsenijs.

I'm trying to add an interface (already added to the system),
05.04.2016, 07:58, "Stefan Lippers-Hollmann" :
>  Hi
>
>  On 2016-04-05, Pičugins Arsenijs wrote:
>>   Package: wpa
>>   Version: 2.3
>>
>>   I want to use wpa_cli to add/remove a wireless interface to a running 
>> wpa_supplicant instance. I try to use "wpa_cli interface_add wlan1" and it 
>> prints out "UNKNOWN COMMAND". Same if I use wpa_cli command line. If I use 
>> "interface_add" without arguments, it asks me to use at least one argument. 
>> If I use "wpa_cli interface_list", it doesn't print out any interface (which 
>> is weird, since "wpa_cli interface" prints an interface which was supplied 
>> to wpa_supplicant by /etc/network/interfaces using wpa_conf directive).
>>   I grepped through wpa 2.3 source and this message appears in 
>> wpa_supplicant ctrl_iface.c file, but I can't quite figure out what are the 
>> circumstances when it is returned as a reply.
>>
>>   I am using Debian GNU/Linux 8.0, kernel 4.1.19-v7+ and glibc6 2.4. It's 
>> Raspbian, if that's important. I can check it on a Debian PC if necessary.
>
>  You can't add an "interface", that's a given based on your hardware/
>  respectively the kernel (ignoring virtual interfaces for a moment),
>  you can only add a network. Use the interactive mode of wpa_cli to get
>  accustomed to it (it has a decent help interface and tab expansion,
>  not to forget its manpage), but in short:
>
>>   add_network
>
>  7
>>   set_network 7 ssid "foo"
>
>  OK
>>   set_network 7 psk "secretpassphrase"
>
>  OK
>>   enable_network 7
>
>  OK
>>   save_config
>
>  OK
>
>  Regards
>  Stefan Lippers-Hollmann

Bug#820087: chrony: prompting due to modified conffiles which were not modified by the user: /etc/chrony/chrony.keys

[Andreas Beckmann]

Package: chrony
Version: 2.2.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

>From the attached log (scroll to the bottom...):

  Setting up chrony (2.2.1-1) ...
  
  Configuration file '/etc/chrony/chrony.keys'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** chrony.keys (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
chrony (--configure):
   end of file on stdin at conffile prompt
  Processing triggers for libc-bin (2.22-5) ...
  Processing triggers for systemd (229-3) ...
  Errors were encountered while processing:
   chrony


This was observed during an upgrade test from jessie to sid.


cheers,

Andreas


chrony_2.2.1-1.log.gz
Description: application/gzip

Bug#798789: netperf: fix for FTBFS

[Sascha Steinbiss]

Control: tags 798789 + patch

Dear maintainer,

I've prepared a patch for netperf (versioned as 2.6.0-2.1) which
fixes the FTBFS.

Best regards,
Sascha

diff -Nru netperf-2.6.0/debian/changelog netperf-2.6.0/debian/changelog
--- netperf-2.6.0/debian/changelog  2013-05-08 21:13:43.0 +
+++ netperf-2.6.0/debian/changelog  2016-04-05 10:02:33.0 +
@@ -1,3 +1,10 @@
+netperf (2.6.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Adjust inline statements to fix FTBFS (Closes: #798789)
+
+ -- Sascha Steinbiss   Tue, 05 Apr 2016 10:02:00 +
+
 netperf (2.6.0-2) unstable; urgency=low
 
   * [cbaabea7] [rules] removed explicit call of patchsys-quilt.mk
diff -Nru netperf-2.6.0/debian/patches/11_inline_statement.patch 
netperf-2.6.0/debian/patches/11_inline_statement.patch
--- netperf-2.6.0/debian/patches/11_inline_statement.patch  1970-01-01 
00:00:00.0 +
+++ netperf-2.6.0/debian/patches/11_inline_statement.patch  2016-04-05 
10:02:58.0 +
@@ -0,0 +1,25 @@
+Description: move around inline statement
+Author: Sascha Steinbiss 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798789
+--- a/src/netlib.c
 b/src/netlib.c
+@@ -4026,7 +4026,7 @@
+inline directive has to appear in netlib.h... */
+ void demo_interval_tick(uint32_t units)
+ #else
+-  inline void demo_interval_tick(uint32_t units)
++  void demo_interval_tick(uint32_t units)
+ #endif
+ {
+   double actual_interval = 0.0;
+--- a/src/netlib.h
 b/src/netlib.h
+@@ -504,7 +504,7 @@
+ extern void   demo_rr_interval(uint32_t units);
+ extern void   demo_rr_setup(uint32_t units);
+ extern void   demo_stream_interval(uint32_t units);
+-extern void   demo_interval_tick(uint32_t units);
++extern inline void   demo_interval_tick(uint32_t units);
+ extern void   demo_interval_final();
+ #endif
+ #endif 
diff -Nru netperf-2.6.0/debian/patches/series 
netperf-2.6.0/debian/patches/series
--- netperf-2.6.0/debian/patches/series 2013-05-08 21:13:43.0 +
+++ netperf-2.6.0/debian/patches/series 2016-04-05 10:03:06.0 +
@@ -1,2 +1,3 @@
 20_fix_debug_file_location.diff
 10_man_fix_unknown_macro.diff
+11_inline_statement.patch

Bug#816101: petsc: FTBFS on mipsel - broken openmpi breaks petsc build

[Drew Parsons]

block 816101 by 818909
severity 816101 important
retitle 816101 FTBFS on mipsel - broken openmpi breaks petsc build
thanks

openmpi on mips seems to be in a sorry state at the moment.

Indeed, even though the petsc builds halts on the fortran test, there
is an mpicc segfault earlier in the log at "TESTING: checkCCompiler":


TEST checkCCompiler from 
config.setCompilers(/«PKGBUILDDIR»/config/BuildSystem/config/setCompilers.py:538)
TESTING: checkCCompiler from 
config.setCompilers(/«PKGBUILDDIR»/config/BuildSystem/config/setCompilers.py:538)
  Locate a functional C compiler
Checking for program /usr/local/sbin/mpicc...not found
Checking for program /usr/local/bin/mpicc...not found
Checking for program /usr/sbin/mpicc...not found
Checking for program /usr/bin/mpicc...found
Defined make macro "CC" to "mpicc"
Pushing language C
  All intermediate test results are stored in 
/tmp/petsc-QnNaJd/config.setCompilers
Executing: mpicc -c -o /tmp/petsc-QnNaJd/config.setCompilers/conftest.o 
-I/tmp/petsc-QnNaJd/config.setCompilers -g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
/tmp/petsc-QnNaJd/config.setCompilers/conftest.c 
Possible ERROR while running compiler: exit code 35584
stderr:
[mipsel-manda-02:10115] *** Process received signal ***
[mipsel-manda-02:10115] Signal: Segmentation fault (11)
[mipsel-manda-02:10115] Signal code: Address not mapped (1)
[mipsel-manda-02:10115] Failing at address: 0x1aadf988
[mipsel-manda-02:10115] *** End of error message ***
Segmentation fault

I'm downgrading this bug to "Important" since it will clear as soon as
Bug#818909 is fixed (i.e. the bug is in openmpi, not in petsc).

Bug#819988: screen: Add udeb support to GNU/screen

[Axel Beckert]

Hi Roger,

Roger Shimizu wrote:
> I'm going to add GNU/screen support into debian-installer [0].
> It would be useful when install debian via serial console or
> network-console (SSH).

Yay, thanks a lot! This will become an awesome D-I feature! :-)

> Enclosed patch to add screen-udeb in debian/control.

Unfortunately it doesn't apply anymore to the current git HEAD
anymore, so I had to slightly adapt your patch.

Main change: Less code duplication with regards to the CFLAGS setting.
:-) The remaining change was only the updated debian/changelog.

Unfortunately there are further issues I need to investigate:

The change

-   dh_auto_build -Ddoc
+   dh_auto_build --builddirectory build -Ddoc

broke the info pages. Lintian warns:

I: screen: package-contains-empty-directory usr/share/info/

And indeed, debdiff confirms that:

Files in first .deb but not in second
-
-rw-r--r--  root/root   /usr/share/info/screen.info-1.gz
-rw-r--r--  root/root   /usr/share/info/screen.info-2.gz
-rw-r--r--  root/root   /usr/share/info/screen.info-3.gz
-rw-r--r--  root/root   /usr/share/info/screen.info-4.gz
-rw-r--r--  root/root   /usr/share/info/screen.info-5.gz
-rw-r--r--  root/root   /usr/share/info/screen.info-6.gz
-rw-r--r--  root/root   /usr/share/info/screen.info.gz

But I suspect I just need to update debian/info accordingly, too.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#820080: libpetsc{-, complex-}3.6.3-dev: leaves alternatives after purge: /etc/alternatives/libpetsc_{real, complex}.so

[Drew Parsons]

You're quick :)

Thanks for the tips.  I'm intending to remove the links in /usr/lib,
converting alternative petsc.so to petsc.so.multiarch (i.e. use only
pure multiarch links with no legacy links.)  Hopefully your discussions
can help sort that out.

Drew

Bug#819840: aptitude: Segfaults if suspended and foregrounded on virtual linux console

[Axel Beckert]

Hi Manuel,

Manuel A. Fernandez Montecelo wrote:
> >aptitude segfaults under the following circumstances:
> >
> >1. Log in as root on a Linux virtual console, i.e. after pressing
> >  Ctrl-Alt-F1.
> >
> >2. Start aptitude in TUI mode, i.e. without any options or parameters.
> >
> >3. Press Ctrl-Z to suspend aptitude.
> >
> >4. Enter "fg" on the commandline and press Enter to bring aptitude back
> >  to the foreground.
> >
> >5. Segfault.
> >
> >This does not happen, if
> >
> >* if tried inside an xterm
> >* if just TERM is set to "linux", but the terminal is no virtual linux
> > console, i.e. "env TERM=linux aptitude" does not exhibit the issue.
> 
> What's "TERM" in the vt console?

linux

> Mine is "linux", and as you noted, it works fine. 

I didn't say that. I just said that in a non-virtual-console (i.e. an
xterm), "env TERM=linux aptitude" does not crash. I didn't say, that
TERM=linux in general prevents the crash. It's just not sufficient to
provoke the crash.

But if you don't get the crash on the vt console, I wonder what else
is needed to provoke the crash as I was able to reproduce it on two Sid
machines with different architectures out of the box.

Is there a chance that LC_CHAR is involved? That's usually set to
something with .UTF-8 at the end for me, either en_{GB,US,DK}.UTF-8 or
C.UTF-8.

> If I "unset TERM" or set it to the empty string, aptitude refuses to
> start ("Error opening terminal: unknown"). If I set it to "linux",
> "xterm" or "xterm-256color" it works fine. "vt100" works fine, but
> no colours.

Did you try these variants inside an terminal emulator under X or on a
Linux virtual console?

> In any case, I couldn't get it to crash by suspending and restoring.

Can you cross-check if you really had the same environment (vt
console)? It seems there may have been some misunderstanding wrt. just
setting $TERM vs the really used type of terminal. The latter matters,
the former is either irrelevant or at least not sufficient.

> None of the functions which name appears are from aptitude, cwidget or
> apt, unfortunately.

Oops. So this might be somewhere deeper down?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#820046: guitarix: does not respect DEB_BUILD_OPTIONS=parallel max value

[Hermann Meyer]

Ups, sorry, you need to pass -j $(NUMJOBS) to the build command, not to 
configure.


regards
hermann

Bug#820088: /usr/bin/crontab still has the setgid bit set

[Alexander Kurtz]

Package: systemd-cron
Version: 1.5.4-1

Hi!

I think this is one setgid bit too much:

alexander@shepard:~$ ls -la /usr/bin/crontab /lib/systemd-cron/crontab_setgid 
-rwxr-sr-x 1 root crontab 10552 Jan 28 09:44 /lib/systemd-cron/crontab_setgid
-rwxr-sr-x 1 root crontab 12824 Jan 28 09:44 /usr/bin/crontab
alexander@shepard:~$ 

Best regards

Alexander Kurtz

signature.asc
Description: This is a digitally signed message part

Bug#820086: More info

[olivier sallou]

After digging, issue seems related to optional tokens.

In my grammar I have:

op=(',' | ';'  | '|')? {  }

If I force op to be mandatory, and adap a little the rest of my grammar to
match, it works fine.
With op being optional it seems this version of antlr tries to bypass the
token. It behaves differently from previous releases.

Bug#820089: RM: stacks [armhf mips powerpc s390x] -- ROM; Build-Dependency for some architectures not in testing

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi,

the latest version of package stacks Build-Depends from samtools which
is not available for the named architectures.  According to

   https://tracker.debian.org/pkg/stacks

the testing migration is prevented because of these architectures.

Kind regards

 Andreas.

Note: this was a request for a partial removal from testing, converted in one 
for unstable

Bug#819816: ITP: debops -- Ansible based server management utility

[Maciej Delmanowski]

Hello,

The base repository contains just scripts which are a frontend and glue
between Ansible and playbooks/roles. Any ideas how the rest of the project,
meaning the playbooks and roles themselves, should be handled, if at all, in
Debian?

Having a .deb package per role (separate git repository) seems a little
overkill, and the number of roles would only grow over time. On the other
hand, preparing a 'debian/' directory for easier packaging of all of the roles
should be easily doable. The roles could alternatively be bundled some broad
categories which would reduce number of packages involved, however that might
be tricky when each role is tracked separately with its own version tags.

Is there any precedence in Debian similar to this issue?

Thanks,
Maciej

Bug#819859: sawfish: Sawfish quits immediately after shown up

[David Riley]

I tried copying the wallpaper.jl from
https://github.com/SawfishWM/sawfish/tree/master/lisp/sawfish/wm/ext
into /usr/share/sawfish/lisp/sawfish/wm/ext/ and with that it starts up.

I don't know if anything else is missing but it looks ok from a very
quick test.

Bug#820091: Switch from php-mongo to php-mongodb is needed

[Ondřej Surý]

Package: php-horde-mongo
Version: 1.0.3-4
Severity: grave

Dear maintainers,

php-mongo is obsolete with PHP 7.0 and it's going to be removed from
Debian unstable.

This is RC bug to make sure that php-horde-mongo gets removed from
testing, so we can remove php-mogno, and then gets updated to use the
new mongodb extension packaged as php-mongodb.

Cheers,
Ondrej

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#820090: chroot default value in master.cf changed from yes to no in Postfix 3.0 - init script needs to reflect this

[Marcel Meckel]

Package: postfix
Version: 3.0.4-5
Severity: important

when upgrading postfix from jessie to (yet unreleased stretch) postfix
warns that master.cf my contain default value '-' for the chroot
column but the default of that chroot value depends on postfix setting
'compatibility_level'.

Please see

  http://www.postfix.org/COMPATIBILITY_README.html#chroot

for more details.

postfix init.d script contains this:

---snip---
config_dir=$($POSTCONF -h config_directory)
# see if anything is running chrooted.
NEED_CHROOT=$(awk '/^[0-9a-z]/ && ($5 ~ "[-yY]") { print "y"; exit}' 
${config_dir}/master.cf)

---snip---

This needs to be modified to take the output of
`postconf compatibility_level' into account.

If compatibility_level  < 2, default value '-' equals to: do chroot.
If compatibility_level >= 2, default value '-' equals to: don't chroot.

Marcel

Bug#819650: mirror submission for mirror.ba

[Emir Beganovic]

Hi Donald,

Our application might have been mistaken a little bit - we're applying only
for Debian CD archive, not the Debian packages archive. We'd like to appear
only on the debian-cd archives list: https://www.debian.org/CD/http-ftp/

The /debian-cd/ directory should now be current and updating, please
re-check. I've also reconfigured it so it syncs twice a day. :-)

The available bandwidth of the mirror is 100 Mbit/s.

Regards,
Emir Beganovic

On Mon, Apr 4, 2016 at 7:01 PM Donald Norwood  wrote:

> control: tag -1 +moreinfo
>
> Hello Emir,
>
> Thank you for your interest in mirroring Debian.
>
> There are a few items that need resolution for your mirror entry.
>
> The /debian/ directory need not hold /debian-cd/. The archive is served
> as /debian/ for the Debian archive and /debian-cd/ for the Debian CD
> archive. I.E.  /debian/ and /debian-cd/
>
> The /debian-cd/ directory is not current, please update.
>
> Archive mirrors need to update 4 times per 24 hours, the CD mirrors do
> not need to as the images don't change that often. :) Twice a day is fine.
>
> What is the available bandwidth of the mirror?
>
>
> Looking forward to hearing from you.
>
> Best regards,
>
> Donald Norwood
> -Debian Mirrors team
>
>
>
>
>
> On Thu, 31 Mar 2016 13:16:21 + "Emir Beganovic"
>  wrote:
> > Package: mirrors
> > Severity: wishlist
> > User: mirr...@packages.debian.org
> > Usertags: mirror-submission
> >
> > Submission-Type: new
> > Site: mirror.ba
> > Aliases: debian.mirror.ba
> > Type: leaf
> > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> > CDImage-ftp: /debian/debian-cd/
> > CDImage-http: /debian/debian-cd/
> > CDImage-rsync: debian-cd/
> > IPv6: no
> > CDImage-upstream: cdimage.debian.org
> > Updates: four
> > Maintainer: Emir Beganovic 
> > Country: BA Bosnia and Herzegovina
> > Location: Sarajevo, Bosnia and Herzegovina
> >
> >
>
>

Bug#819146: [Pkg-php-pecl] Bug#819146: PHP 7 transition and moving to pkg-php-pecl team

[Ondřej Surý]

Hi László,

I am in process of dh-php5 removal, so it would be nice if we can get
rid of php-mongo (and just filled RC bug on the only r-dep
php-horde-mongo).

Also on second thought, we really don't need transitional packages as
the name would be changed anyway, so I'll suggest just reassigning this
to ftp.debian.org as ROM.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

On Thu, Mar 24, 2016, at 09:46, László Böszörményi (GCS) wrote:
> Ondřej, please don't Cc submit@...
> 
> On Thu, Mar 24, 2016 at 8:37 AM, Ondřej Surý  wrote:
> > Nah, the new MongoDB extension is called mongodb.
>  Exactly.
> 
> > Just remove this package and I'll do transitional package from
> > src:php-mongodb
>  Just noted Mathieu about it. :)
> Should the removal and transition start immediately?
> 
> Laszlo/GCS

Bug#820084: please remove

[Marcel Meckel]

Hi,

the bug should have been filed with the postfix package
and not os-prober - my mistake.

Please remove/close/invalid this bug. I resent the bug
report with the right package name in it so there is no
need to assign this bug report to the postfix package.

Thanks

Marcel

Bug#820088: /usr/bin/crontab still has the setgid bit set

[Alexandre Detiste]

control: tag -1 confirmed

> Hi!
>
> I think this is one setgid bit too much:
>
> -rwxr-sr-x 1 root crontab 12824 Jan 28 09:44 /usr/bin/crontab

This remains from previously installed (vixie-)cron.

The kernel will ignore setgid bit on scripts;
so it's just ugly but doesn't hurt in any way;
it will get fixed.

Alexandre Detiste

Bug#797999: sddm fails to start whereas kdm works correctly

[Hans-J. Ullrich]

Package: sddm
Version: 0.13.0-1
Followup-For: Bug #797999

Dear Maintainer,

I can confirm this, too.

It maybe, SDDM might work bad with nvidia. I am running testing/amd64, the
nvidia proprietrary drivers are installed by the installer from nvidia. As my
card is no more supperted by the debian packages (GeForce 8600M GS), I had to
do that way.

When sddm is started, I get a dark screen (looks like the X-Server is started,
but sddm shows no graphics).

The process sddm is running and can be killed by using killall sddm.

At the moment I reverted back to kdm, which is still working like a charm.

Hope this helps a little bit.

Best regards

Hans-J. Ullrich



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

Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sddm depends on:
ii  adduser   3.114
ii  debconf [debconf-2.0] 1.5.59
ii  libc6 2.22-5
ii  libgcc1   1:5.3.1-13
ii  libpam0g  1.1.8-3.2
ii  libqt5core5a  5.5.1+dfsg-16
ii  libqt5dbus5   5.5.1+dfsg-16
ii  libqt5gui55.5.1+dfsg-16
ii  libqt5network55.5.1+dfsg-16
ii  libqt5qml55.5.1-3
ii  libqt5quick5  5.5.1-3
ii  libstdc++65.3.1-13
ii  libsystemd0   229-3
ii  libxcb-xkb1   1.11.1-1
ii  libxcb1   1.11.1-1
ii  qml-module-qtquick2   5.5.1-3
ii  sddm-theme-breeze [sddm-theme]4:5.4.3-2
ii  sddm-theme-circles [sddm-theme]   0.13.0-1
ii  sddm-theme-elarun [sddm-theme]0.13.0-1
ii  sddm-theme-maldives [sddm-theme]  0.13.0-1
ii  sddm-theme-maui [sddm-theme]  0.13.0-1

Versions of packages sddm recommends:
ii  libpam-systemd  229-3

Versions of packages sddm suggests:
ii  libpam-kwallet5  5.4.3-1

-- debconf-show failed

Bug#820086: More info

[Emmanuel Bourg]

Le 5/04/2016 13:35, olivier sallou a écrit :

> With op being optional it seems this version of antlr tries to bypass
> the token. It behaves differently from previous releases.

Hi Olivier,

I suggest using the antlr3.2 package. Jython was affected by a
regression with antlr 3.5 too and I uploaded the previous release as a
separate package to address this issue.

Emmanuel Bourg

Bug#816446: nginx: Please use systemd confinement features

[Nicolas Braud-Santoni]

On Thu, Mar 31, 2016 at 10:14:20AM +0300, Christos Trochalakis wrote:
> I also believe it makes sense to enable the security features for
> systemd users. `ProtectHome` is a bit tricky as it could possibly break
> some setups, we could use `read-only` there.
> 
> Currently we are a bit overwhelmed with the dynamic modules support,
> but we 'll discuss it with Mike and get back to it after 1 or 2 weeks.

That's great news (both the dynamic module support & that you will
  have a look later).

Thanks


signature.asc
Description: PGP signature

Bug#820092: libcgi-pm-perl

[Marcel Meckel]

Package: backuppc
Version: 3.3.1-2
Severity: normal

when upgrading the server that hosts backuppc from jessie to
(yet unreleased stretch), backuppc will produce HTTP 500 errors
when trying to view the perl-based backuppc dashboard from
a web browser.

The error logged in the webservers logfile is:

Can't locate CGI.pm in @INC (you may need to install the
CGI module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.22.1
/usr/local/share/perl/5.22.1
/usr/lib/x86_64-linux-gnu/perl5/5.22
/usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.22
/usr/share/perl/5.22
/usr/local/lib/site_perl
/usr/lib/x86_64-linux-gnu/perl-base)
at /usr/share/backuppc/lib/realindex.cgi line 50.:
/usr/share/backuppc/cgi-bin/index.cgi

Workaround:

manually install package

  libcgi-pm-perl

In current stable Debian jessie the package 'perl-modules'
contains the file CGI.pm.

CGI.pm is not shipped in perl-modules-5.22 anymore.

Marcel

Bug#820093: tiptop: does not display any task when running as root

[Lucas Nussbaum]

Package: tiptop
Version: 2.2-2
Severity: important

Hi Tomasz!

When trying to run tiptop on Grid'5000 (jessie-x64-min environment), as root,
it does not display any tasks. (it says "Tasks:   0 total,   0 displayed" at
the top)

When running as a normal user, it works fine.

I tried to compile version 2.3, and the problem also occurs.

However, on my laptop (4.4.0-1-amd64 kernel), everything works as expected.

Please let me know if you need help to reproduce this bug.

- Lucas


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages tiptop depends on:
ii  libc62.19-18+deb8u4
ii  libncurses5  5.9+20140913-1+b1
ii  libtinfo55.9+20140913-1+b1
ii  libxml2  2.9.1+dfsg1-5+deb8u1

tiptop recommends no packages.

tiptop suggests no packages.

-- no debconf information

Bug#820081: libreoffice-writer: can't open LibreOffice Writer

[Rene Engelhard]

tag 820081 + moreinfo
thanks

Hi,

On Tue, Apr 05, 2016 at 12:11:15PM +0200, Pierre Crescenzo wrote:
> I can't open LibreOffice Writer. I always have the "Récupération de documents
> LibreOffice" ("LibreOffice Document Recovery") windows, with no document. And
> Writer crashes without message.
> 
> And if i try to open an existing document (odf or doc or docx), I always have
> the same "Récupération de documents LibreOffice" ("LibreOffice Document
> Recovery") windows, with this document. And the recovery fails. And Writer
> crashes without message.

Well, I don't think anyone can check this with "just" that info.

What does gdb and/or strace say (see README.Debian and
https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_an_strace_log

If it was a general problem it'd have been reported already *and* as you
say below it's even writer-specific...

> No problem with other LibreOffice parts: Calc or Impress are OK.

Interesting.

(In this case you probably want to run soffice --writer for strace instead
of "just" soffice)

Regards,

Rene

Bug#820094: Doesn't support PHP 7

[Ondřej Surý]

Source: php-facedetect
Version: 1.1.0+git20140717-2
Severity: grave

Dear maintainers,

php-facedetect doesn't support PHP 7.0 and it should be either updated
to have PHP 7.0 support (which doesn't support in upstream) or the
package should be removed from the archive (I can fill the RM bug if
you don't have time).

Cheers,
Ondrej

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#820096: vlc: crash when pressing stop on YouTube video

[Paul Wise]

Package: src:vlc
Version: 2.2.2-5
Severity: normal
Usertags: crash

I got the following crash after pressing stop on this youtube video.
If the backtrace isn't useful, please close the bug report.

$ gdb -batch -n -ex 'set height 0' -ex run -ex bt -ex 'thread apply all bt 
full' --args vlc 'https://www.youtube.com/watch?v=t2zb_iZC6nI'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
VLC media player 2.2.2 Weatherwax (revision 2.2.2-0-g6259d80)
[New Thread 0x7fffeb29c700 (LWP 27640)]
[New Thread 0x7fffef712700 (LWP 27641)]
[New Thread 0x7fffe2a99700 (LWP 27642)]
[New Thread 0x7fffe2998700 (LWP 27643)]
[Thread 0x7fffe2a99700 (LWP 27642) exited]
[New Thread 0x7fffe2a99700 (LWP 27645)]
[006079a8] core libvlc: Running vlc with the default interface. Use 
'cvlc' to use vlc without interface.
[New Thread 0x7fffdd96b700 (LWP 27664)]
[New Thread 0x7fffdc888700 (LWP 27668)]
[Thread 0x7fffe2998700 (LWP 27643) exited]
[New Thread 0x7fffe2998700 (LWP 27669)]
[New Thread 0x7fffda787700 (LWP 27670)]
[New Thread 0x7fffda47e700 (LWP 27671)]
[Thread 0x7fffda47e700 (LWP 27671) exited]
[0061c228] core playlist: stopping playback
[New Thread 0x7fffda47e700 (LWP 27685)]
[New Thread 0x7fffd1d01700 (LWP 27686)]
[Thread 0x7fffda47e700 (LWP 27685) exited]
[Thread 0x7fffd1d01700 (LWP 27686) exited]
[Thread 0x7fffda787700 (LWP 27670) exited]
[New Thread 0x7fffda787700 (LWP 27687)]
[New Thread 0x7fffd1d01700 (LWP 27688)]
[Thread 0x7fffd1d01700 (LWP 27688) exited]
[New Thread 0x7fffc69e4700 (LWP 27696)]
[New Thread 0x7fffc61e3700 (LWP 27697)]
[New Thread 0x7fffc59e2700 (LWP 27698)]
[New Thread 0x7fffc51e1700 (LWP 27699)]
[New Thread 0x7fffd1d01700 (LWP 27700)]
[New Thread 0x7fffda47e700 (LWP 27701)]
[New Thread 0x7fffc168c700 (LWP 27705)]
libva info: VA-API version 0.39.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
[New Thread 0x7fffbcac8700 (LWP 27706)]
[Thread 0x7fffd1d01700 (LWP 27700) exited]
[Thread 0x7fffc69e4700 (LWP 27696) exited]
[Thread 0x7fffc61e3700 (LWP 27697) exited]
[Thread 0x7fffc59e2700 (LWP 27698) exited]
[Thread 0x7fffc51e1700 (LWP 27699) exited]
[Thread 0x7fffda47e700 (LWP 27701) exited]
[Thread 0x7fffda787700 (LWP 27687) exited]
[Thread 0x7fffc168c700 (LWP 27705) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffbcac8700 (LWP 27706)]
0x7fffc0cd5628 in ?? ()
#0  0x7fffc0cd5628 in  ()
#1  0x0136cbd0 in  ()
#2  0x019cdef0 in  ()
#3  0x01238620 in  ()
#4  0x in  ()

Thread 23 (Thread 0x7fffbcac8700 (LWP 27706)):
#0  0x7fffc0cd5628 in  ()
#1  0x0136cbd0 in  ()
#2  0x019cdef0 in  ()
#3  0x01238620 in  ()
#4  0x in  ()

Thread 9 (Thread 0x7fffe2998700 (LWP 27669)):
#0  0x779aa04f in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7719be15 in vlc_cond_wait (p_condvar=, 
p_mutex=) at posix/thread.c:387
#2  0x7719c5f5 in vlc_timer_thread (data=0x7edda0) at posix/timer.c:63
canc = 
now = 
misses = 
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, 
-3879837640095203817, 0, 140736911024271, 3, 140736911024768, 
3879790648816008727, 3879818142782684695}, __mask_was_saved = 0}}, __pad = 
{0x7fffe2997df0, 0x0, 0x779a3529 <__nptl_deallocate_tsd+137>, 0x0}}
__cancel_routine = 0x7719c4d0 
__cancel_arg = 0x7eddd8
__not_first_call = 
#3  0x779a4454 in start_thread (arg=0x7fffe2998700) at 
pthread_create.c:334
__res = 
pd = 0x7fffe2998700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140736995100416, 
-3879837640095203817, 0, 140736911024271, 3, 140736911024768, 
3879790648792940055, 3879819246625455639}, mask_was_saved = 0}}, priv = {pad = 
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
__PRETTY_FUNCTION__ = "start_thread"
#4  0x774ddedd in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 8 (Thread 0x7fffdc888700 (LWP 27668)):
#0  0x774d4e4d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x74e15382 in _xcb_conn_wait (__timeout=-1, __nfds=1, 
__fds=0x7fffdc887c40) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
ret = 
fd = {fd = 12, events = 1, revents = 0}
#2  0x74e15382 in _xcb_conn_wait (c=c@entry=0x75f2f0, 
cond=cond@entry=0x75f330, vector=vector@entry=0x0, count=count@entry=0x0) at 
../../src/xcb_conn.c:459
ret = 
fd = {fd = 12, events = 1, revents = 0}
#3  0x74e16ff7 in xcb_wait_for_event (c=0x75f2f0) at 
../../src/xcb_in.c:693
ret = 0x0
#4

Bug#820095: libgdk-pixbuf2.0-dev: Please relax dependency with libpng12-dev

[Hideki Yamane]

Package: libgdk-pixbuf2.0-dev
Version: 2.33.2-1
Severity: normal
Tags: patch

Hi,

 During build gnome-todo pacakge with experimental packages, I've got
 a build failure with missing libpng12-dev that is cauase by 
libgdk-pixbuf2.0-dev.

> checking for GNOME_TODO... no
> configure: error: Package requirements (gmodule-export-2.0
>   gio-2.0 >= 2.43.4
>   glib-2.0 >= 2.43.4
>   goa-1.0 >= 3.2.0
>   gtk+-3.0 >= 3.19.5
>   libecal-1.2 >= 3.13.90
>   libedataserver-1.2 >= 3.17.1
>   libedataserverui-1.2 >= 3.17.1
>   libical >= 0.43
>   libpeas-1.0 >= 1.17) were not met:
> 
> Package 'libpng12', required by 'gdk-pixbuf-2.0', not found

 Yes, /usr/lib/x86_64-linux-gnu/pkgconfig/gdk-pixbuf-2.0.pc says

> Name: GdkPixbuf
(snip)
> Requires.private: gmodule-no-export-2.0 libpng12

 But Its package dependency is

> Package: libgdk-pixbuf2.0-dev
> Source: gdk-pixbuf
> Version: 2.33.2-1
(snip)
> Depends: libc6 (>= 2.4), libgdk-pixbuf2.0-0 (= 2.33.2-1), libglib2.0-0 (>= 
> 2.37.6),
> libpng12-0 (>= 1.2.13-4), gir1.2-gdkpixbuf-2.0 (= 2.33.2-1), libglib2.0-dev 
> (>= 2.37.6),
> libx11-dev, libpng-dev, shared-mime-info
  ^^

 There's only libpng-dev (there should be libpng12-dev, too). Probably 
gdk-pixbuf
 was built with unstable chroot, however, libpng-dev is only in experimental,
 so built package has a conflict information. 


 patch attached.

diff -urN gdk-pixbuf-2.32.3.orig/debian/control.in 
gdk-pixbuf-2.32.3/debian/control.in
--- gdk-pixbuf-2.32.3.orig/debian/control.in2016-01-28 02:24:01.0 
+0900
+++ gdk-pixbuf-2.32.3/debian/control.in 2016-04-05 10:47:01.439479341 +0900
@@ -69,7 +69,7 @@
  gir1.2-gdkpixbuf-2.0 (= ${binary:Version}),
  libglib2.0-dev (>= 2.37.6),
  libx11-dev,
- libpng-dev,
+ libpng-dev | libpng12-dev,
  shared-mime-info
 Description: GDK Pixbuf library (development files)
  The GDK Pixbuf library provides:

Bug#820086: More info

[olivier sallou]

Le mar. 5 avr. 2016 à 14:13, Emmanuel Bourg  a écrit :

> Le 5/04/2016 13:35, olivier sallou a écrit :
>
> > With op being optional it seems this version of antlr tries to bypass
> > the token. It behaves differently from previous releases.
>
> Hi Olivier,
>
> I suggest using the antlr3.2 package. Jython was affected by a
> regression with antlr 3.5 too and I uploaded the previous release as a
> separate package to address this issue.
>

I could patch the logol code to work with antlr 3.5, even if I do not
understand why it does not work nicely on optional token. I gonna push the
patch on logol anyway to try to keep pace with available packages, but I
keep in mind this 3.2 package in case other regressions where to be found
as fallback mechanism.

Thanks

Olivier


>
> Emmanuel Bourg
>
>

Bug#820095: libgdk-pixbuf2.0-dev: Please relax dependency with libpng12-dev

[Rene Engelhard]

On Tue, Apr 05, 2016 at 09:01:12PM +0900, Hideki Yamane wrote:
> diff -urN gdk-pixbuf-2.32.3.orig/debian/control.in 
> gdk-pixbuf-2.32.3/debian/control.in
> --- gdk-pixbuf-2.32.3.orig/debian/control.in2016-01-28 02:24:01.0 
> +0900
> +++ gdk-pixbuf-2.32.3/debian/control.in 2016-04-05 10:47:01.439479341 +0900
> @@ -69,7 +69,7 @@
>   gir1.2-gdkpixbuf-2.0 (= ${binary:Version}),
>   libglib2.0-dev (>= 2.37.6),
>   libx11-dev,
> - libpng-dev,
> + libpng-dev | libpng12-dev,
>   shared-mime-info
>  Description: GDK Pixbuf library (development files)
>   The GDK Pixbuf library provides:

No, this is wrong, and still would get the build failure.

The correct solution iy to make gdk-pixbuf mention libpng.pc in Requires,
which would work for both 12 and 16.

Regards,

Rene

Bug#814159: avian: (Build-)Depends on OpenJDK 7

[Mattia Rizzolo]

Dear Xerxes,

On Sun, Apr 03, 2016 at 05:48:51PM +, Mattia Rizzolo wrote:
> On Mon, Feb 08, 2016 at 08:27:22PM +, Matthias Klose wrote:
> > Package: src:avian
> > Usertags: openjdk-8-transition
> > 
> > The package build-depends or depends one an openjdk-7-* package,
> > which is scheduled for removal for stretch.  Please do not depend
> > on a specific openjdk version, but on one of the default-java,
> > default-java-headless or default-jdk packages instead.
> 
> 
> Well, this is actually a package of yours :)
> 
> It seems to me that this is java-7 specific, so if there is no port for
> it it should be removed from the archive (as you did in Ubuntu?).

They made me notice this is mainly a work of yours, so I'm asking
directly to you if you're interested in porting avian to openjdk-8.

If you are not interested, or you don't reply timely (notice that the
original request that you already received is dated Feb 08, i.e. nearly
2 months ago) I'm going to proceed with the removal of this package, as
it is one of the few remaining blocker for openjdk-7 removal.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#762932: aptitude Bug#762932: With Aptitude::ProblemResolver::SolutionCost=removals, aptitude full-upgrade chooses to downgrade a package

[Manuel A. Fernandez Montecelo]

Control: severity -1 wishlist
Control: tags -1 + wontfix


Hi,

2015-09-21 12:43 Manuel A. Fernandez Montecelo:


If I ask aptitude to upgrade a package and the dependencies cannot be
fulfilled (as explained above for unstable), it is natural that aptitude
tries to come up with weird solutions.  That includes downgrading.  So
if I want to upgrade the version of 10 packages in unstable, and they
depend on the new libstdc++6, and there is one dependency from
experimental (libmad1.1) which had been compiled against the old
libstdc++6 while there is "libmad1.0" in unstable compiled against the
new libstdc++6, is is natural and reasonable that aptitude offers me a
downgrade -- it is the easiest way to satisfy upgrading 10 packages and
just downgrading one, without removals or other also negative effects.

I am the master juggling blades, I am using unstable and experimental, I
tweak the resolver parameters to my heart's content, I ask to upgrade
things in the middle of a terribly complicated transition, and aptitude
does not treat me like as an idiot: it *offers* me a *possible solution*
to the conflicting states after an action that I *requested*, that
includes downgrades.  It didn't break my system just casually like
sitting there on the filesystem, or while doing "aptitude update", or
when reinstalling a package, or upgrading from one stable to the next.

I don't see anything wrong with that, that is part of the core function
of aptitude, to put me in charge.  In fact, I would be disappointed if
aptitude didn't offer me slightly awkward solutions that would fit the
bill sometimes.

[...]

According to the documentation, "removal" means: "Counts the number of
packages that the solution removes".

I assume that this works as intended and doesn't like solutions like
removing obsolete libraries (of which there are lots lately, specially
after the *v5 mass-renaming for example and with gcc-5 adding lots of
"breaks" to some packages), so maybe it doesn't have better options (in
terms of "resolver costs") than to downgrade.



So after studying this for a while, this is normal behaviour when using
"removals", which only pays attention to minimise the number of
removals, no matter any other considerations like upgrades, downgrades,
or prefering packages with higher priorities.

Using the default ("safety, priority") puts dangerous actions like
downgrades or changing to other non-default versions in a different
"safety" level, so they are not offered as the first solutions.

"safety, removals" can probably be used to avoid having downgrades while
minimising removals.


Even in this case, the fact that it was offering downgrades instead of
upgrades at the time when this was reported was because of the chaos
caused by the GCC-5/C++11 transition (the worst in a decade).

So only when the combination of all these unlikely cases happen
simultaneously, downgrades are offered.  Downgrades are highlighted and
have to be confirmed explicitly by the sysadmin.

It's working as documented and not a bug.



By default it probably does, because I can't remember if I was ever
offered a downgrade.  Again, you were using non-default options.

Note also about full-upgrade:

  full-upgrade

  Upgrades installed packages to their most recent version, removing
  or installing packages as necessary. This command is less
  conservative than safe-upgrade and thus more likely to perform
  unwanted actions. However, it is capable of upgrading packages
  that safe-upgrade cannot upgrade.

So, in short, if you don't want surprises, probably you should use
"safe-upgrade" and not "full-upgrade -y".

[...]

No, the best solution is to require the user to solve the problem
manually.


Well, it idoes, it offered you a solution, as far as I am aware, for
you to decide.  Only when passing "-y" it didn't, and rightly so.


Ditto.



Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#820041: [PATCH] dracut-init.sh: Add detached module signatures if present

[Ben Hutchings]

Control: tag -1 upstream patch
---
Also disable stripping modules that have detached signatures.

Signed-off-by: Ben Hutchings 
---
--- a/dracut-init.sh
+++ b/dracut-init.sh
@@ -886,6 +886,10 @@ install_kmod_with_fw() {
 
 inst_simple "$1" "/lib/modules/$kernel/${1##*/lib/modules/$kernel/}"
 ret=$?
+if (($ret == 0)) && [[ -f "$1.sig" ]]; then
+inst_simple "$1.sig" 
"/lib/modules/$kernel/${1##*/lib/modules/$kernel/}.sig"
+ret=$?
+fi
 [[ $DRACUT_KERNEL_LAZY_HASHDIR ]] && \
 [[ -d "$DRACUT_KERNEL_LAZY_HASHDIR" ]] && \
 echo $ret > "$DRACUT_KERNEL_LAZY_HASHDIR/${1##*/}"
@@ -948,12 +952,16 @@ dracut_kernel_post() {
 (
 if [[ $DRACUT_INSTALL ]] && [[ -z $_moddirname ]]; then
 xargs -r $DRACUT_INSTALL ${initdir:+-D "$initdir"} 
${loginstall:+-L "$loginstall"} -a < "$DRACUT_KERNEL_LAZY_HASHDIR/lazylist.dep"
+sed 's/$/.sig/' "$DRACUT_KERNEL_LAZY_HASHDIR/lazylist.dep" | 
xargs -r $DRACUT_INSTALL -o ${initdir:+-D "$initdir"} ${loginstall:+-L 
"$loginstall"}
 else
 while read _modpath || [ -n "$_modpath" ]; do
 local _destpath=$_modpath
 [[ $_moddirname ]] && _destpath=${_destpath##$_moddirname/}
 _destpath=${_destpath##*/lib/modules/$kernel/}
 inst_simple "$_modpath" 
"/lib/modules/$kernel/${_destpath}" || exit $?
+if [[ -f "${_modpath}.sig" ]]; then
+inst_simple "${_modpath}.sig" 
"/lib/modules/$kernel/${_destpath}.sig" || exit $?
+fi
 done < "$DRACUT_KERNEL_LAZY_HASHDIR/lazylist.dep"
 fi
 ) &
--- a/dracut.sh
+++ b/dracut.sh
@@ -1596,7 +1596,7 @@ if [[ $do_strip = yes ]] && ! [[ $DRACUT
 find "$initdir" -type f -path '*/lib/modules/*.ko' -print0 \
 | while read -r -d $'\0' f || [ -n "$f" ]; do
 SIG=$(tail -c 28 "$f")
-[[ $SIG == '~Module signature appended~' ]] || { printf "%s\000" "$f"; 
}
+[[ $SIG == '~Module signature appended~' ]] || [[ -f "$f.sig" ]] || { 
printf "%s\000" "$f"; }
 done | xargs -r -0 strip -g
 
 dinfo "*** Stripping files done ***"


signature.asc
Description: Digital signature

Bug#819988: screen: Add udeb support to GNU/screen

[Axel Beckert]

Control: tag -1 + pending

Hi,

Axel Beckert wrote:
> The change
> 
> -   dh_auto_build -Ddoc
> +   dh_auto_build --builddirectory build -Ddoc
> 
> broke the info pages. 
[...]
> But I suspect I just need to update debian/info accordingly, too.

That was necessary, but didn't suffice. They even weren't build
anymore. This was additionally needed:

-dh_auto_build --builddirectory build -Ddoc
+dh_auto_build --sourcedirectory build/doc

I've fixed this and added some minor cleanups in this commit:
https://anonscm.debian.org/cgit/collab-maint/screen.git/commit/?h=screen-udeb&id=4e3403d21fb6848b62cde55771f275d581dda239

The changes are currently tracked in the screen-udeb branch on Alioth:
https://anonscm.debian.org/cgit/collab-maint/screen.git/log/?h=screen-udeb

Despite the libtinfo5-udeb is not yet available, I was able to still
build the package. So I wonder if that "Fix blocked by 819397: Add
udeb support to libtinfo5" is really correct/necessary. Because I'm
tempted to upload this support with the next upload. (Planned to do
one on Sunday, but didn't manage it.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#820099: RFA: storaged -- Disk Manager

[Andreas Henriksson]

Package: wnpp
Severity: normal

Hello!

This is a borderline RFA/RFH. I've already packaged storaged, which is
a fork of udisks2 but more targeted at supporting advanced "enterpricy"
storage solutions. It's currently sitting in experimental, since I don't
have time to properly maintain it myself and thus shouldn't upload it
targeted at testing/stretch.
Many backends are currently disabled since their dependencies are
currently not available in Debian.
I've also not properly tested that it's functional, but TTBOMK it is.

Further information can be found at:
https://tracker.debian.org/pkg/storaged

Like the packaging vcs at:
https://anonscm.debian.org/cgit/collab-maint/pkg-storaged.git

There's also interest from upstream to see Debian support and their
bug tracker has an issue for this, see:
https://github.com/storaged-project/storaged/issues/41#issuecomment-205769607

Upstream has packaged the dependencies which are not available in Debian
in separate Ubuntu PPAs and updated the storaged package in an Ubuntu PPA
to enable the new backends, which should serve as a very good base for
someone willing to maintain these in Debian!

If you'd like to see storaged (which is an optional but quite central
dependency of cockpit-project.org) in a future stable Debian release,
then this is your chance to help out!

Get in touch if you'd like to be the primary maintainer of storaged
in Debian. I'm willing to assist as a co-maintainer and can also sponsor
you if you're not already a Debian Developer.

Regards,
Andreas Henriksson

Bug#820097: imagej: No JVM found to run ImageJ

[Kai Wohlfahrt]

Package: imagej
Version: 1.50d+dfsg-1
Severity: important
Tags: patch

Dear Maintainer,

After installing openjdk-8 alongside openjdk-7 (as part of apt-get 
dist-upgrade), imagej no longer starts with the following error:

  $ imagej
  Open other images in this ImageJ panel as follows:
imagej -p 1  [ ... ]
  
  No JVM found to run ImageJ
  Please apt-get install a JVM to run ImageJ or 
  set JAVA_HOME if it's not a JVM from a Debian Package.

The attached patch resolves the issue for me, though I have not confirmed 
whether it works in the old situation (only openjdk-7 installed).

Please let me know if I can be more useful.

Best wishes,
Kai

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages imagej depends on:
ii  default-jre2:1.8-57
ii  openjdk-7-jre  7u91-2.6.3-1

imagej recommends no packages.

imagej suggests no packages.

-- no debconf information
--- imagej_old	2016-04-05 13:53:26.108638252 +0100
+++ /usr/bin/imagej	2016-04-05 13:53:01.176246828 +0100
@@ -29,7 +29,7 @@
 
 if [ -z "$JAVA_HOME" ] ; then
 # This does not work see #505315
-JAVA_HOME=$(/usr/sbin/update-java-alternatives -l | grep openjdk | sort | tail -1 | cut -d' ' -f 3)
+JAVA_HOME=$(/usr/sbin/update-java-alternatives -l | grep openjdk | sort | tail -1 | tr -s ' ' | cut -d' ' -f 3)
 # Reverted to old version - see #558222 (Andreas Tille)
 # JAVA_HOME=$(dirname $(dirname $(dirname $(readlink /etc/alternatives/java
 # Also suggested by From: JR Coding ; To: 740...@bugs.debian.org

Bug#819988: screen: Add udeb support to GNU/screen

[Roger Shimizu]

On Tue, Apr 5, 2016 at 10:02 PM, Axel Beckert  wrote:
> Control: tag -1 + pending
>
> Hi,
>
> Axel Beckert wrote:
>> The change
>>
>> -   dh_auto_build -Ddoc
>> +   dh_auto_build --builddirectory build -Ddoc
>>
>> broke the info pages.
> [...]
>> But I suspect I just need to update debian/info accordingly, too.
>
> That was necessary, but didn't suffice. They even weren't build
> anymore. This was additionally needed:
>
> -dh_auto_build --builddirectory build -Ddoc
> +dh_auto_build --sourcedirectory build/doc

Thank you for helping on these issues I didn't notice.
I'm fine with these changes.

> I've fixed this and added some minor cleanups in this commit:
> https://anonscm.debian.org/cgit/collab-maint/screen.git/commit/?h=screen-udeb&id=4e3403d21fb6848b62cde55771f275d581dda239
>
> The changes are currently tracked in the screen-udeb branch on Alioth:
> https://anonscm.debian.org/cgit/collab-maint/screen.git/log/?h=screen-udeb
>
> Despite the libtinfo5-udeb is not yet available, I was able to still
> build the package. So I wonder if that "Fix blocked by 819397: Add
> udeb support to libtinfo5" is really correct/necessary. Because I'm
> tempted to upload this support with the next upload. (Planned to do
> one on Sunday, but didn't manage it.)

You can use "dpkg-deb -I " command to check the built udeb.
I guess it depends on libc6-udeb and libtinfo5, which should be libtinfo5-udeb.

So it's better to wait #819397 resolving first.
Of course you can make a release without udeb support, since other
changes seems also has a long list already.

Thanks again for taking care of screen!
I'm a user for 10+ years.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1