Bug#813676: libgtk2.0-0: applications crashing while opening system (e.g. save file) dialog

[Bernd Zeimetz]

Package: libgtk2.0-0
Version: 2.24.29-1
Severity: important
Tags: patch

Hi,

as reported in
https://bugzilla.gnome.org/show_bug.cgi?id=747280
various applications (like thunar, chromium, ...) crash while opening 
file dialogs. This is a rather annoying bug and unfortunately still not 
fixed by upstream, although there is a patch attached to the bug report.


Could you please patch this issue in Debian until upstream takes care of it?

Thanks,

Bernd


--
Mit freundlichen Grüßen


Bernd Zeimetz
Systems Engineer
Debian Developer

conova communications GmbH
Web| http://www.conova.com/
E-Mail | b.zeim...@conova.com

Zentrale Salzburg
Karolingerstraße 36A
5020 Salzburg

Tel | +43 (0) 662 22 00 - 313
Fax | +43 (0) 662 22 00 - 209

Es gelten die Allgemeinen Geschäftsbedingungen der
conova communications GmbH, http://www.conova.com/de/agb/


smime.p7s
Description: S/MIME cryptographic signature

Bug#813681: apt-listbugs starts browser as root

[Nick T.]

Package: apt-listbugs
Version: 0.1.17
Severity: wishlist
Tags: security

apt-listbugs when asked to display bug information in browser it starts the 
browser as root. Needless to say this is not a good idea and in specific 
circumstances a security issue.
listbugs should drop the superuser privileges before doing so. My 
recommendation is to launch the browser as 'nobody' by default and add a config 
option to set a custom user.

Regards,
Nick

Bug#813624: RFS: ismrmrd/1.3.2-2 [RC]

[Ghislain Vaillant]

Too late sorry. Although the failure on armhf is for a different reason
than all the others.

I'll try to investigate where the following error in armhf cames from:

fatal error in "test_acquisition_header": memory access violation at 
address: 0xbec5461a: invalid address alignment


Thanks for the heads-up.

Ghis


On 04/02/16 10:35, Gianfranco Costamagna wrote:

Hi, please not it still fails on armhf.

thanks

G.





Il Mercoledì 3 Febbraio 2016 20:45, Ghislain Vaillant  ha 
scritto:
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "ismrmrd"

* Package name: ismrmrd
Version : 1.3.2-2
Upstream Author : The ISMRMRD developers
* URL : http://ismrmrd.github.io/
* License : Expat
Section : science

It builds those binary packages:

ismrmrd-schema - ISMRM Raw Data format (ISMRMRD) - XML schema
ismrmrd-tools - ISMRM Raw Data format (ISMRMRD) - binaries
libismrmrd-dev - ISMRM Raw Data format (ISMRMRD) - development files
libismrmrd-doc - ISMRM Raw Data format (ISMRMRD) - documentation
libismrmrd1.3 - ISMRM Raw Data format (ISMRMRD) - shared library

To access further information about this package, please visit the
following URL:

   http://mentors.debian.net/package/ismrmrd

Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/i/ismrmrd/ismrmrd_1.3.2-2.dsc

Changes since the last upload:

* d/control: use secure VCS-Git URI.
* Add patch fixing FTBFS in testsuite.
  File: Use-explicit-64-bit-shifts-in-testsuite.patch.
  Thanks to Emilio Pozuelo Monfort (Closes: #802172)
* Provide examples in doc package.
* d/control: cme fix, wrap and sort.
* Fix usage of embedded jquery.

Best regards,
Ghislain Vaillant

Bug#813684: libcaja-extension-dev: arch-dependent file in "Multi-Arch: same" package

[Jakub Wilk]

Package: libcaja-extension-dev
Version: 1.12.3-1
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

libcaja-extension-dev is marked as "Multi-Arch: same", but the following 
file is architecture-dependent:


/usr/share/gtk-doc/html/libcaja-extension/ix01.html

An example diff between i386 and amd64 is attached.

--
Jakub Wilk


libcaja-extension-dev_1.12.3-1.archdiff.gz
Description: application/gzip

Bug#813688: RM: pacemaker-mgmt -- ROM; unmaintained, outdated upstream

[Christoph Berg]

Package: ftp.debian.org
Severity: normal

Hi,

please remove the pacemaker-mgmt package. It has never been part of a
stable release in the 5.5a since it was first uploaded (and hasn't
seen any new upstream versions since), and the current upstream
version on github doesn't compile.

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: PGP signature

Bug#813580: [Pkg-netfilter-devel] Bug#813580: Bug#813580: Bug#813580: No Internet Connection with iptables-1.6.0-2

[Arturo Borrero Gonzalez]

Control: reassing -1 connman
Control: severity -1 important

On 4 February 2016 at 12:29, Tsu Jan  wrote:
>>
> Hi,
>
> My bad! I had another Debian with network-manager instead of connman. Last
> night I had time to upgrade it and no problem occurred. So, this is about
> connman and not iptables. Apparently, building connman-1.21 against
> libxtables11 wasn't enough for it to work with iptables-1.6.0.
>
> Should I write another bug report or you could reassign this one to connman
> (with high severity)?

Yeah, doing so now.

>
> I've attached my current iptables-save and dmesg logs. Sorry, I couldn't
> find the logs related to that specific boot and I can't upgrade now to
> reproduce the issue because this is my work system.
>

For the record, the ruleset you shared was generated with a previous
version of iptables? the file contains:
Generated by iptables-save v1.4.21 on Thu Feb  4 14:14:09 2016

Your dmesg contains logs from iptables, which indicates that the
ruleset was loaded to the kernel, and it is seing traffic.

Anyway, this bug is now in the connman side. I'm open to whatever help
is required on my side.

best regards.
-- 
Arturo Borrero González

Bug#813008: [Debian-ha-maintainers] Bug#813008: pacemaker-remote: The dummy RA belongs to the pacemaker package

[Ferenc Wágner]

In short, these files should be moved from pacemaker-remote to pacemaker
(and the agent description filled out eventually to generate a sensible
man page):

/usr/share/man/man7/ocf_pacemaker_remote.7.gz
/usr/lib/ocf/resource.d/pacemaker/remote

Additionally, the pacemaker-remote RPM contains logrotate and sysconfig.
Pacemaker-remote uses the same logging configuration as pacemaker, and
there is a separate sysconfig section for pacemaker-remote used by both.

The pacemaker and pacemaker-remote packages should Break/Conflict each
other (their daemons listen on the same socket, but pacemaker-remote
does not depend on the cluster stack), require some common files (DTDs?,
RNG schemas?, XSL transforms?, default config?) and recommend the CLI
utilities.  Or is it the utilities requiring the XML stuff?  The
/var/lib/pacemaker/* directories should be provided at least, but they
don't warrant a new package.

For some reason these are in the pacemaker RPM, not in pacemaker-cli:
crm_attribute
crm_master
crm_node
(with their man pages).

Should we move all other binaries except daemons into pacemaker-cli-utils?
/usr/sbin/attrd_updater
/usr/sbin/fence_pcmk
/usr/sbin/stonith_admin
and their man pages.

The above two groups are excluded from the pacemaker-cli RPM, probably
they use direct interfaces to the various sub-daemons and don't work over
pacemaker-remote.  But 4.3.5. of the Remote book states otherwise:

The pacemaker_remote daemon allows nearly all the pacemaker tools
(crm_resource, crm_mon, crm_attribute, crm_master, etc.) to work on
guest nodes natively.

/usr/lib/x86_64-linux-gnu/pacemaker/lrmd_test is shipped in the
pacemaker-cts RPM, which means we can simply drop it (we don't ship the
test framework now).

Beyond the above, inexplicably missing from the pacemaker RPM:
/usr/lib/ocf/resource.d/pacemaker/o2cb - but its man page is present
/usr/sbin/fence_legacy - though explicitly mentioned in the spec file

Extra in the pacemaker RPM:
/usr/share/pacemaker/nagios/plugins-metadata
  NAGIOS_METADATA_DIR defaults to /usr/share/nagios/plugins-metadata for
  us, and somebody should package
  https://github.com/ClusterLabs/nagios-agents-metadata to 
  provide the contents.  Our Nagios plugin dir is also defaulted to
  /usr/lib/x86_64-linux-gnu/nagios/plugins, which does not match the
  nagios-plugins-* packages, need to fix that, too.
/var/lib/pacemaker/cores
  Something seems to create it actually...  Better ship it, also for
  pacemaker-remote.

These are now in pacemaker, but probably dysfunctional on Debian, and
found in the pacemaker-cli RPM:
/usr/share/pacemaker/report.collector
/usr/share/pacemaker/report.common

Bug#813665: man-db: man -K gives irrelevant results

[Colin Watson]

Control: tag -1 fixed-upstream

On Thu, Feb 04, 2016 at 08:08:53AM +0100, B. Ruva wrote:
> man -K searches the nroff source, not the formatted manpages. Because
> of that "man -K california" gives a lot of hits (for commands like
> more, rev, whereis, ...) whose manpages don't contain the string
> "california" (it is contained in comments in the nroff source). This
> problematic behavior is not described in man(1).

Thanks for your report.  I'm afraid that this is necessary for
reasonable performance (searching the raw text of all pages on the
system can be made pretty quick; formatting all pages rather less so),
but you're correct that it ought to be documented.  I've pushed a
documentation fix for the next release:

  
http://git.savannah.gnu.org/cgit/man-db.git/commit/?id=21958e4509f6523250e3bad0ef1bc4097fdcf201

-- 
Colin Watson   [cjwat...@debian.org]

Bug#804547: [nvidia-driver] Outdated nvidia drivers

[Andreas Beckmann]

On 2016-02-04 10:55, Nick T. wrote:
> Hello Andreas,
> 
> The 355.11-1 version is 7 months old already which is way outdated already 
> for newer games(e.g. XCOM-2 comming out this Friday needs 355.63 and above) 
> the newest version on nvidias website is 358.16.
> And also according to #813565 the new driver is not compatible with sids X 
> abi.

With a reasonably recent driver in unstable and testing (352.79)
experimental was finally free for testing upstream reorganization (new
packages needed, new module build system, new kernel module), so at the
moment experimental is actually experimental :-)


Andreas

Bug#813691: make openmpi the default on s390x

[Ansgar Burchardt]

Control: tag -1 moreinfo

On Thu, 2016-02-04 at 12:59 +0100, Matthias Klose wrote:
> Package: src:mpi-defaults
> Version: 1.0.2+nmu2
> Tags: patch
> 
> please make openmpi the default on s390x. while mpi itself is not
> used that much 
> on s390x, it may be better to go with the implementation which is
> used for most 
> architectures.
> 
> patch at
> https://launchpad.net/ubuntu/+source/mpi-defaults/1.0.2+nmu2ubuntu1

OpenMPI is currently not built on s390x: it is not listed in the source
packages Architecture: field.

Ansgar

Bug#813677: debian-faq: correction to misspelled words, hints on contents to revise

[Markus Hiereth]

Package: debian-faq
Version: 5.0.3
Severity: normal

Dear Maintainer,

working on the German translation of the FAQ, I found 

- passages with outdated information

- confusing usage of words 
  e.g. "file system" when "directory structure" was meant
  e.g. "distribution" when "section" was meant

- redundancy, also on matter of minor importance 

- mistakes in shell commands

- misspelled words 


Find the attached sgml-files. They are edited, annotations and 
background are inserted as comments using .

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

Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


sgml_mh-2016-02-04.tgz
Description: application/gzip

Bug#813580: [Pkg-netfilter-devel] Bug#813580: Bug#813580: No Internet Connection with iptables-1.6.0-2

[Tsu Jan]

On Thu, 4 Feb 2016 08:51:57 +0100 Arturo Borrero Gonzalez 
 wrote:

> Hi Tsu,
>
> I would need you to provide additional info about this bug:
> * connman config
> * connman service systemd detailed log
> * connman own log? (if exists)
> * kernel log (the dmesg one)
> * iptables service systemd detailed log (if exists)
> * iptables ruleset (from iptables-save)
>
> thanks
> --
> Arturo Borrero González
>
>
Hi,

My bad! I had another Debian with network-manager instead of connman. 
Last night I had time to upgrade it and no problem occurred. So, this is 
about connman and not iptables. Apparently, building connman-1.21 
against libxtables11 wasn't enough for it to work with iptables-1.6.0.


Should I write another bug report or you could reassign this one to 
connman (with high severity)?


I haven't changed connman config -- it's the default Debian one.

I saved journalctl output before downgrading connman and iptables and 
there was no iptable line in it but its connman lines were so:


Feb 03 14:20:51 debian systemd[1]: connman.service: Main process exited, 
code=exited, status=1/FAILURE


Feb 03 14:20:51 debian systemd[1]: connman.service: Unit entered failed 
state.


Feb 03 14:20:51 debian systemd[1]: connman.service: Failed with result 
'exit-code'.


Feb 03 14:20:51 debian systemd[1]: connman.service: Service hold-off 
time over, scheduling restart.






Feb 03 14:20:57 debian systemd[1]: connman.service: Failed with result 
'start-limit'.


I've attached my current iptables-save and dmesg logs. Sorry, I couldn't 
find the logs related to that specific boot and I can't upgrade now to 
reproduce the issue because this is my work system.


Thanks, Tsu


-- Logs begin at Thu 2016-02-04 13:43:28 IRST, end at Thu 2016-02-04 14:25:05 
IRST. --
Feb 04 13:43:28 debian kernel: Initializing cgroup subsys cpuset
Feb 04 13:43:28 debian kernel: Initializing cgroup subsys cpu
Feb 04 13:43:28 debian kernel: Initializing cgroup subsys cpuacct
Feb 04 13:43:28 debian kernel: Linux version 4.3.0-1-amd64 
(debian-ker...@lists.debian.org) (gcc version 5.3.1 20160114 (Debian 5.3.1-6) ) 
#1 SMP Debian 4.3.3-7 (2016-01-19)
Feb 04 13:43:28 debian kernel: Command line: 
BOOT_IMAGE=/boot/vmlinuz-4.3.0-1-amd64 root=/dev/sda5
Feb 04 13:43:28 debian kernel: x86/fpu: xstate_offset[2]: 0240, 
xstate_sizes[2]: 0100
Feb 04 13:43:28 debian kernel: x86/fpu: Supporting XSAVE feature 0x01: 'x87 
floating point registers'
Feb 04 13:43:28 debian kernel: x86/fpu: Supporting XSAVE feature 0x02: 'SSE 
registers'
Feb 04 13:43:28 debian kernel: x86/fpu: Supporting XSAVE feature 0x04: 'AVX 
registers'
Feb 04 13:43:28 debian kernel: x86/fpu: Enabled xstate features 0x7, context 
size is 0x340 bytes, using 'standard' format.
Feb 04 13:43:28 debian kernel: x86/fpu: Using 'eager' FPU context switches.
Feb 04 13:43:28 debian kernel: e820: BIOS-provided physical RAM map:
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0x-0x0009c7ff] usable
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0x0009c800-0x0009] reserved
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0x000e-0x000f] reserved
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0x0010-0xb9862fff] usable
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xb9863000-0xb9869fff] ACPI NVS
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xb986a000-0xba0e3fff] usable
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xba0e4000-0xba383fff] reserved
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xba384000-0xc98c7fff] usable
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xc98c8000-0xc9ad0fff] reserved
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xc9ad1000-0xc9e02fff] usable
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xc9e03000-0xcab07fff] ACPI NVS
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xcab08000-0xcaffefff] reserved
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xcafff000-0xcaff] usable
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xcbc0-0xcfdf] reserved
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xf800-0xfbff] reserved
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xfec0-0xfec00fff] reserved
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xfed0-0xfed03fff] reserved
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xfed1c000-0xfed1] reserved
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xfee0-0xfee00fff] reserved
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0xff00-0x] reserved
Feb 04 13:43:28 debian kernel: BIOS-e820: [mem 
0x0001-0x00032f1f] usable
Feb 04 13:43:28 debian kernel: NX (Execute Disable) protection: active
Feb 04 

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Holger Levsen]

Lunar, 

also:

< josch> personally i'd be happy with Lunar's suggestion: Installed-Build-
Depends
< josch> i think the natural understanding of that term implies the 
transitivity as well as that it's not the closure that is meant
* h01ger likes Installed-Build-Depends too
< h01ger> | [12:14] < josch> i think the natural understanding of that term 
implies the transitivity as well as that it's not the closure that is meant
< h01ger> | agreed on that as well

and, yes, finding a proper name takes time, but is no bike shedding, instead 
it helps avoiding to understanding future confusions. If you don't like 
naming, don't participate, but don't dismiss other peoples work.


Holger


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

Bug#813690: ocserv: missing RADIUS support

[Mantas Mikulėnas]

Package: ocserv
Version: 0.10.10-1
Severity: wishlist

Dear Maintainer,

Could you include RADIUS authentication support in ocserv?

(This would need libfreeradius-client2 v1.1.7.)

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

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

Versions of packages ocserv depends on:
ii  dbus   1.10.6-1
ii  libc6  2.21-7
ii  libgnutls-deb0-28  3.3.20-1
ii  libhttp-parser2.1  2.1-2
ii  liblz4-1   0.0~r131-1
ii  libnl-3-2003.2.26-1
ii  libnl-route-3-200  3.2.26-1
ii  libopts25  1:5.18.7-3
ii  libpam0g   1.1.8-3.2
ii  libpcl11.6-1
ii  libprotobuf-c1 1.1.1-1
ii  libreadline6   6.3-8+b4
ii  libseccomp22.2.3-2
ii  libsystemd0228-4+b1
ii  libtalloc2 2.1.5-1
ii  libwrap0   7.6.q-25

Versions of packages ocserv recommends:
ii  ca-certificates  20160104
ii  ssl-cert 1.0.37

ocserv suggests no packages.

-- no debconf information

Bug#813232: debootstrap --second-stage doesn't work

[oleg]

Package: debootstrap
Version: 1.0.78
Followup-For: Bug #813232

Dear Maintainer,

In 1.0.77 and after update to 1.0.78 still doesn't retrive packages from 
--second-stage. In log just — mknod /dev/null failed. 
Thanks!

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

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

Versions of packages debootstrap depends on:
ii  wget  1.17.1-1+b1

Versions of packages debootstrap recommends:
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.20-1

debootstrap suggests no packages.

-- no debconf information

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Johannes Schauer]

Hi,

Quoting Jérémy Bobbio (2016-02-04 12:23:05)
> We have to educate them about .buildinfo file and what the various fields
> mean. We have to aim at field names that are as unambigious as possible to
> avoid laying traps on users.
> 
> For the particular case of “Installed-Transitive-Build-Depends”, it's easy
> enough to explain “these are the name and version of all packages which made
> building these binary packages possible”. Math geeks can get a more formal
> definition.

since we probably never want to record the explicitly non-transitive build
dependencies in the .buildinfo (because those are already recorded elsewhere),
adding "transitive" to the name is probably not necessary. On IRC I agreed with
Holger that using your original proposal and calling it Installed-Build-Depends
should be enough. I think even an uneducated reader would quickly figure out
that this field is not listing the direct but also the indirect (transitive)
depends.

Thanks and sorry for bikeshedding!

cheers, josch


signature.asc
Description: signature

Bug#813691: make openmpi the default on s390x

[Matthias Klose]

Package: src:mpi-defaults
Version: 1.0.2+nmu2
Tags: patch

please make openmpi the default on s390x. while mpi itself is not used that much 
on s390x, it may be better to go with the implementation which is used for most 
architectures.


patch at
https://launchpad.net/ubuntu/+source/mpi-defaults/1.0.2+nmu2ubuntu1

Bug#813691: make openmpi the default on s390x

[Matthias Klose]

Control: tag -1 - moreinfo

On 04.02.2016 13:08, Ansgar Burchardt wrote:

Control: tag -1 moreinfo

On Thu, 2016-02-04 at 12:59 +0100, Matthias Klose wrote:

Package: src:mpi-defaults
Version: 1.0.2+nmu2
Tags: patch

please make openmpi the default on s390x. while mpi itself is not
used that much
on s390x, it may be better to go with the implementation which is
used for most
architectures.

patch at
https://launchpad.net/ubuntu/+source/mpi-defaults/1.0.2+nmu2ubuntu1


OpenMPI is currently not built on s390x: it is not listed in the source
packages Architecture: field.


now filed #813694 for openmpi.

Bug#600262: apt: random_sleep should not be executed if anacron has started the cron.daily script

[Mathias Koehrer]

Hi,

I am running into the same issue.
When starting the system with anacron, the /etc/cron.daily/apt may block 
the whole cron.daily jobs.


My proposal is to detect if /etc/cron.daily/apt has been started by cron 
or just by anacron.


The attached patch should fix this by checking (by using pstree) if 
there is a plain 'cron' process in the list of the parents.


Regards

Mathias

--- cron.daily/apt.orig	2016-02-04 13:09:56.774148517 +0100
+++ cron.daily/apt	2016-02-04 13:10:11.221364868 +0100
@@ -422,7 +422,15 @@
 
 # sleep random amount of time to avoid hitting the 
 # mirrors at the same time
-random_sleep
+# However do only sleep if this job has been started by cron
+# and not by anacron
+if which pstree > /dev/null; then
+  if pstree -s $$ | grep -q -- '--cron--' ; then
+random_sleep
+  fi
+else
+  random_sleep
+fi  
 check_power || exit 0
 
 # include default system language so that "apt-get update" will

Bug#813580: [Pkg-netfilter-devel] Bug#813580: Bug#813580: Bug#813580: No Internet Connection with iptables-1.6.0-2

[Tsu Jan]

On Thu, 4 Feb 2016 13:17:15 +0100 Arturo Borrero Gonzalez 
 wrote:

> For the record, the ruleset you shared was generated with a previous
> version of iptables? the file contains:
> Generated by iptables-save v1.4.21 on Thu Feb 4 14:14:09 2016
>
>
Yes! As I said I had to downgrade iptables to have Internet connection 
with connman and I knew the ruleset might be of no use.
I'm pretty sure that this is a connman issue; otherwise it would also 
happen to my other system (with the latest iptables, network-manager and 
KDE but identical to this one in other respects).

Bug#812796: tokyocabinet: testsuite sometimes failes

[Tobias Frost]

Control: retitle -1 Segfault in tchmttest
> Source: tokyocabinet
> Followup-For: Bug #812796

> https://bugzilla.redhat.com/show_bug.cgi?id=572594,

This was already in our codebase, unfortunatly.

However, it seems that I've got an workaround, at least the segfaults are
going away, using the configure flag "--enable-uyield" : which purpose is
build for detecting race conditions... (which we likely have here...)

--
tobi

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Jérémy Bobbio]

Guillem Jover:
> On Sun, 2016-01-31 at 14:43:08 +0100, Jérémy Bobbio wrote:
> > Guillem Jover:
> > > > How about naming the field “Environment-Variables”?
> > > 
> > > Hmm, or Environment, or Build-Environment, which reminds me that I've
> > > found the usage of Build-Environment (as the list of transitively
> > > required packages) slightly confusing, precisely because the first
> > > thing that comes to mind with environment is the variable space.
> > > 
> > > Perhaps we should consider renaming that one? Say Build-Packages (but
> > > that might be confusing), Build-Depends-Used, or something else? We
> > > also already have a Built-Using field too (although for source
> > > packages not binary ones, with a name I've also found slightly
> > > confusing as being too generic).
> > 
> > Ok. What about “Environment” for the variables,
> 
> I'm not sure if it'd be better to be explicit about this being a build
> thing, and not just a random environment. Are you worried about confusion
> with the previous usage of the field with the same name?

I'm indeed worry about confusion. The file is called '.buildinfo', so I
think it's fine to imply that these were environment variables defined
during the time the .buildinfo was generated.


  .
 / \ We have entered
/ ! \bike shedding territory
~


-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#813692: ejabberd: Failed RPC connection to the node ejabberd@mercurius: timeout

[Dominik George]

Package: ejabberd
Version: 16.01-1~bpo8+1
Severity: normal

Upgrading to 16.01, postinst throws:

Failed RPC connection to the node ejabberd@mercurius: timeout

ejabberd was up and running and working perfectly before starting the update.

-- System Information:
Debian Release: 8.3
  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_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)

Versions of packages ejabberd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  erlang-asn11:18.0-dfsg-1
ii  erlang-base [erlang-abi-17.0]  1:18.0-dfsg-1
ii  erlang-crypto  1:18.0-dfsg-1
ii  erlang-inets   1:18.0-dfsg-1
ii  erlang-lager   2.0.3-1
ii  erlang-mnesia  1:18.0-dfsg-1
ii  erlang-odbc1:18.0-dfsg-1
ii  erlang-p1-cache-tab1.0.1-1~bpo8+1
ii  erlang-p1-iconv0.2016.01.05-1~bpo8+1
ii  erlang-p1-stringprep   1.0.0-1~bpo8+1
ii  erlang-p1-tls  1.0.0-1~bpo8+1
ii  erlang-p1-utils1.0.3-1~bpo8+1
ii  erlang-p1-xml  1.1.1-1~bpo8+1
ii  erlang-p1-yaml 1.0.0-1~bpo8+1
ii  erlang-p1-zlib 1.0.0-1~bpo8+1
ii  erlang-public-key  1:18.0-dfsg-1
ii  erlang-ssl 1:18.0-dfsg-1
ii  erlang-syntax-tools1:18.0-dfsg-1
ii  erlang-xmerl   1:18.0-dfsg-1
ii  init-system-helpers1.22
ii  openssl1.0.1k-3+deb8u2
ii  ucf3.0030

ejabberd recommends no packages.

Versions of packages ejabberd suggests:
pn  apparmor 
pn  apparmor-utils   
ii  ejabberd-contrib 0.2016.01.12~dfsg0-1~bpo8+1
pn  erlang-oauth2
ii  erlang-p1-mysql  0.2014.03.10-2
ii  erlang-p1-pam0.2014.05.05-2
ii  erlang-p1-pgsql  0.2014.04.30-1
ii  erlang-p1-sip0.2014.07.17-2
ii  erlang-p1-stun   0.2014.08.20-1
ii  erlang-redis-client  1.0.8-1
pn  erlang-sqlite3   
ii  imagemagick  8:6.8.9.9-5
ii  libunix-syslog-perl  1.1-2+b4

-- Configuration Files:
/etc/ejabberd/inetrc [Errno 13] Keine Berechtigung: u'/etc/ejabberd/inetrc'
/etc/ejabberd/modules.d/README.modules [Errno 13] Keine Berechtigung: 
u'/etc/ejabberd/modules.d/README.modules'

-- debconf information excluded

Bug#813693: ocaml-textutils: FTBFS: ocamlfind: Package `enumerate' not found - required by `core'

[Chris Lamb]

Source: ocaml-textutils
Version: 112.17.00-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ocaml-textutils fails to build from source in unstable/amd64:

  [..]

  ocaml setup.ml -build
  W: Cannot find source file matching module 'textutils' in library textutils
  ocamlfind ocamlopt unix.cmxa -I /usr/lib/ocaml/ocamlbuild 
/usr/lib/ocaml/ocamlbuild/ocamlbuildlib.cmxa -linkpkg myocamlbuild.ml 
/usr/lib/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild
  /usr/bin/ocamlfind ocamldep -syntax camlp4o -syntax camlp4o -syntax camlp4o 
-package threads -package sexplib.syntax -package sexplib -package 
pa_ounit.syntax -package pa_ounit -package core -modules lib/ascii_table.mli > 
lib/ascii_table.mli.depends
  + /usr/bin/ocamlfind ocamldep -syntax camlp4o -syntax camlp4o -syntax camlp4o 
-package threads -package sexplib.syntax -package sexplib -package 
pa_ounit.syntax -package pa_ounit -package core -modules lib/ascii_table.mli > 
lib/ascii_table.mli.depends
  ocamlfind: Package `enumerate' not found - required by `core'
  Command exited with code 2.
  E: Failure("Command ''/usr/bin/ocamlbuild' lib/textutils.cma 
lib/textutils.cmxa lib/textutils.a lib/textutils.cmxs -use-ocamlfind -tag 
debug' terminated with error code 10")
  debian/rules:25: recipe for target 'override_dh_auto_build' failed
  make[1]: *** [override_dh_auto_build] Error 1
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160204131153.gWejLS6NJx/ocaml-textutils-112.17.00'
  debian/rules:17: recipe for target 'build' failed
  make: *** [build] Error 2

  [..]

The full build log is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


ocaml-textutils.112.17.00-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#813695: apache 2.4 postinst whoes about service dependency nightmare

[Harald Dunkel]

Package: apache2
Version: 2.4.18-1

Apache2 refuses to be set up:

:
Performing actions...
Setting up apache2 (2.4.18-1) ...
insserv: FATAL: service checkroot is missed in the runlevels S to use service 
checkfs
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
:


Regards
Harri

Bug#813680: wireshark-qt: Restart of current capture use different interface

[Springsfeld, Christoph]

Package: wireshark-qt
Version: 2.0.1+g59ea380-3+b1
Severity: normal

Restarting a running capture by clicking on the button in the toolbar, doesn't
use the current interface for the new capture. Instead the configured default
interface is used.

Problem does not occur in the GTK version of Wireshark.

Regards,
Christoph



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

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

Versions of packages wireshark-qt depends on:
ii  libc62.21-7
ii  libgcc1  1:5.3.1-7
ii  libglib2.0-0 2.46.2-3
ii  libnl-3-200  3.2.26-1
ii  libnl-genl-3-200 3.2.26-1
ii  libnl-route-3-2003.2.26-1
ii  libpcap0.8   1.7.4-2
ii  libqt5core5a 5.5.1+dfsg-13
ii  libqt5gui5   5.5.1+dfsg-13
ii  libqt5multimedia55.5.1-3
ii  libqt5printsupport5  5.5.1+dfsg-13
ii  libqt5widgets5   5.5.1+dfsg-13
ii  libsbc1  1.3-1
ii  libstdc++6   5.3.1-7
ii  libwireshark62.0.1+g59ea380-3+b1
ii  libwiretap5  2.0.1+g59ea380-3+b1
ii  libwsutil6   2.0.1+g59ea380-3+b1
ii  wireshark-common 2.0.1+g59ea380-3+b1
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages wireshark-qt recommends:
ii  libqt5multimedia5-plugins  5.5.1-3

wireshark-qt suggests no packages.

-- no debconf information

Bug#813624: RFS: ismrmrd/1.3.2-2 [RC]

[Gianfranco Costamagna]

Hi,

> Hi, please not it still fails on armhf.


I know it was uploaded, this was a typo
"please note" not "please not" :)

I mean, please look at the build failure left on this arch ;)

thanks a lot!

Gianfranco

Bug#813436: Iqtree accepted in Debian

[Bui Quang Minh]

Hi Andreas,

> On Feb 2, 2016, at 9:37 AM, Andreas Tille  wrote:
> 
> Hi,
> 
> since you helped a lot getting iqtree into Debian I now have the good
> news that it was accepted yesterday in Debian[1] (finally - I would have
> loved if this would have taken less time).  For the moment the package
> resides in Debian unstable.  Once it might have migrated to Debian
> testing (which is the case if it stays in unstable for five days without
> any known release critical bug) I will also create a backport for the
> current stable release Jessie.
> 

thanks for the update!

> Unfortunately the package received three bug reports over night which is
> basically connected to gcc command line options and one name change.  I
> have created patches for all three bugs which you can find in the
> packaging Git[2].  Please inspect the patches after reading below.  Each
> patch has a header pointing with description and a link to the according
> bug report if you need some more verbose explanation.
> 
> Since I noticed that meanwhile new versions are released and I intend to
> upload the latest version with bug fixes.  So I downloaded 1.3.13

yes this version is desirable as it fixed 3 bugs compared with 1.3.11

> and
> tried to build this.  When trying to do so I was running into
> 
> 
> ...
> /usr/bin/c++   -DIQ_TREE -D_USE_PTHREADS -D__SSE3 -I/build/iqtree-1.3.13+dfsg 
> -I/build/iqtree-1.3.13+dfsg/obj-x86_64-linux-gnu -I/usr/include/eigen3  -g 
> -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2  -fopenmp-D__AVX  -o 
> CMakeFiles/avxkernel.dir/phylotreeavx.cpp.o -c 
> /build/iqtree-1.3.13+dfsg/phylotreeavx.cpp
> In file included from /build/iqtree-1.3.13+dfsg/phylotreeavx.cpp:9:0:
> /build/iqtree-1.3.13+dfsg/phylokernel.h:19:2: error: #error "You must compile 
> with SSE3 enabled!"
> #error "You must compile with SSE3 enabled!"
>  ^
> /build/iqtree-1.3.13+dfsg/phylotreeavx.cpp:15:2: error: #error "You must 
> compile this file with AVX enabled!"
> #error "You must compile this file with AVX enabled!"
>  ^
> In file included from /build/iqtree-1.3.13+dfsg/phylotreeavx.cpp:11:0:
> /build/iqtree-1.3.13+dfsg/phylokernelmixrate.h: In instantiation of 'double 
> PhyloTree::computeMixrateLikelihoodBranchEigenSIMD(PhyloNeighbor*, 
> PhyloNode*) [with VectorClass = Vec4d; int VCSIZE = 4; int nstates = 4]':
> /build/iqtree-1.3.13+dfsg/phylotreeavx.cpp:38:36:   required from here
> /build/iqtree-1.3.13+dfsg/phylokernelmixrate.h:802:27: error: no matching 
> function for call to 'horizontal_add(Vec4d [4])'
>lh_ptn = horizontal_add(vc_ptn) + VectorClass().load_a(_invar[ptn]);
>   ^
> ...
> 
> /build/iqtree-1.3.13+dfsg/phylokernelmixrate.h:802:27: error: invalid 
> conversion from 'Vec4d*' to 'int' [-fpermissive]
> In file included from 
> /build/iqtree-1.3.13+dfsg/vectorclass/vectorclass.h:41:0,
> from /build/iqtree-1.3.13+dfsg/phylokernel.h:12,
> from /build/iqtree-1.3.13+dfsg/phylotreeavx.cpp:9:
> /build/iqtree-1.3.13+dfsg/vectorclass/vectori128.h:1085:5: note:   
> initializing argument 1 of 'Vec8s::Vec8s(int)'
> Vec8s(int i) {^M
> ^
> 
> and a lot of similar errors.  From the preprocessor error message above
> it seems obvious that dropping sse3 and avx options is not intended and
> will break the build.  

that’s right, I have a C++ template that implements the core computational 
kernel of IQ-TREE. This C++ class is compiled twice, one under SSE3 and another 
under AVX. Then at run time, IQ-TREE will detect the CPU feature. Depending on 
the availability of AVX or not, the appropriate kernel will be used. In fact 
IQ-TREE also has a non-SSE kernel, that can be used. However, I thought that 
>95% of the computers nowadays support SSE anyway, thus I did not include this 
switch.

> Does this mean that you intend to support intel
> processors exclusively?  

no, I indeed want to support any CPU. I don’t have much knowledge in this deep 
aspect. Thus, can you advice us how that can be done?

> This can be specified in the package metadata
> and will prevent other architectures from trying to build the package.
> However, in the long run this might not be a good idea since
> architectures like arm64, ppc64 or others might play some rule in the
> future.  If you confirm for the moment my Intel-only assumption I will
> rewert the patches removing sse3 and avx and will close the bugs with
> the Intel-only restriction but please keep the hint in mind to rethink
> this decision from time to time.
> 

ok

> In any case I will keep the patch that adds the string "32" to the
> executable name[3] which IMHO makes no sense on Linux.

I wanted to make distinction between 64-bit and 32-bit binary, so that users 
can have both executables actually. But it’s fine if you think that is not 
necessary for Debian

> 
> Finally I would like to let you know that we now have packaged ncl
> library.  I remember 

Bug#813686: buildsystem python_distutils: no way to pass global options to setup.py on install

[Guido Günther]

Package: debhelper
Version: 9.20160115
Severity: wishlist

Hi,
when using --buildsystem=python_distutils there's no way to pass global options
to setup.py, so using:


   dh_auto_build -- --foo --bar

results in:

  python setup.py install --force --root=/build/.../debian/tmp --no-compile -O0 
 --foo --bar

but sometimes one needs the options prepended before the install target:

  python setup.py --foo --bar install --force --root=/build/.../debian/tmp 
--no-compile -O0

since the option is a global one on setup.py not for the install
distutils command. Looking at python_distutils.pm it seems optons are
always appended and can never be prepended.

This happened with recent virt-manage that needs:

  python setup.py --no-update-icon-cache --no-compile-schemas install --force 
--root=/build/virt-manager-1.3.2*/debian/tmp --no-compile -O0

Please add a way to allow for this.
Cheers,
 -- Guido

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

Kernel: Linux 4.1.0-2-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)

Versions of packages debhelper depends on:
ii  autotools-dev20150820.1
ii  binutils 2.26-2
ii  dh-strip-nondeterminism  0.015-1
ii  dpkg 1.18.4
ii  dpkg-dev 1.18.4
ii  file 1:5.25-2
ii  libdpkg-perl 1.18.4
ii  man-db   2.7.5-1
ii  perl 5.22.1-4
ii  po-debconf   1.0.19

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201604

-- no debconf information

Bug#813601: closed by Ben Hutchings <b...@decadent.org.uk> (Re: linux-image-3.16: kernel panic when umounting rootfs)

[Nicolas Dichtel]

Le 04/02/2016 11:19, Nicolas Dichtel a écrit :

Le 04/02/2016 05:24, Debian Bug Tracking System a écrit :

This is an automatic notification regarding your Bug report
which was filed against the src:linux package:

#813601: linux-image-3.16: kernel panic when umounting rootfs

It has been closed by Ben Hutchings .


I've misread the commit log. I was thinking that the panic can be triggered by
a privileged user in a container.
Thank you for taking time to answer.


Ok got it, this upstream patch b2f5d4dc38e0 ("umount: Disallow unprivileged
mount force") has been backported in the debian kernel, which explains why only
the 'global root' can trigger this panic.

Bug#813601: closed by Ben Hutchings <b...@decadent.org.uk> (Re: linux-image-3.16: kernel panic when umounting rootfs)

[Nicolas Dichtel]

Le 04/02/2016 05:24, Debian Bug Tracking System a écrit :

This is an automatic notification regarding your Bug report
which was filed against the src:linux package:

#813601: linux-image-3.16: kernel panic when umounting rootfs

It has been closed by Ben Hutchings .


I've misread the commit log. I was thinking that the panic can be triggered by
a privileged user in a container.
Thank you for taking time to answer.

Bug#813689: letsencrypt-renewer raises a TypeError

[Alexander Schier]

Package: letsencrypt
Version: 0.3.0-1
Severity: normal

Dear Maintainer,
letsencrypt-renewer raises a type error, probably when it finds a
certificate eligible for renewal:

$ letsencrypt-renewer 
Processing [redacted].conf
/usr/lib/python2.7/dist-packages/urllib3/connectionpool.py:732: 
InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
certificate verification is strongly advised. See: 
https://urllib3.readthedocs.org/en/latest/security.html (This warning will only 
appear once by default.)
  InsecureRequestWarning)
Traceback (most recent call last):
  File "/usr/bin/letsencrypt-renewer", line 9, in 
load_entry_point('letsencrypt==0.3.0', 'console_scripts', 
'letsencrypt-renewer')()
  File "/usr/lib/python2.7/dist-packages/letsencrypt/renewer.py", line 203, in 
main
renew(cert, old_version)
  File "/usr/lib/python2.7/dist-packages/letsencrypt/renewer.py", line 97, in 
renew
new_certr, new_chain, new_key, _ = le_client.obtain_certificate(sans)
  File "/usr/lib/python2.7/dist-packages/letsencrypt/client.py", line 264, in 
obtain_certificate
csr = crypto_util.init_save_csr(key, domains, self.config.csr_dir)
  File "/usr/lib/python2.7/dist-packages/letsencrypt/crypto_util.py", line 78, 
in init_save_csr
csr_pem, csr_der = make_csr(privkey.pem, names)
  File "/usr/lib/python2.7/dist-packages/letsencrypt/crypto_util.py", line 118, 
in make_csr
value=", ".join("DNS:%s" % d for d in domains)
  File "/usr/lib/python2.7/dist-packages/OpenSSL/crypto.py", line 651, in 
__init__
extension = _lib.X509V3_EXT_nconf(_ffi.NULL, ctx, type_name, value)
TypeError: initializer for ctype 'char *' must be a str or list or tuple, not 
unicode

the original certificate was created with the webroot method and no automatic 
configuration of webservers.


-- System Information:
Debian Release: 8.3
  APT prefers stable
  APT policy: (900, 'stable'), (100, 'stable-updates'), (100, 'experimental'), 
(100, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 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: sysvinit (via /sbin/init)

Versions of packages letsencrypt depends on:
ii  dialog  1.2-20140911-1
ii  python-letsencrypt  0.3.0-1
pn  python:any  

letsencrypt recommends no packages.

Versions of packages letsencrypt suggests:
pn  python-letsencrypt-apache  
pn  python-letsencrypt-doc 

-- no debconf information

Bug#812508: fixed in d-shlibs 0.63

[peter green]

tags 812508 +patch
thanks

> * Extend quirk for GnuTLS.
>   Closes: bug#812508  
. Thanks to Andreas 
Metzler.
[...]

Looks like the fix did not work, ucommon failed with exactly the same
Seems a small mistake was made when extending the quirk pattern. The new 
quirk pattern will match libgnutls-30 but the package is actually called 
libgnutls30 (no dash). I fixed this, uploaded to raspbian stretch and 
was then able to successfully rebuild ucommon.


Debdiff at 
http://debdiffs.raspbian.org/main/d/d-shlibs/d-shlibs_0.63%2brpi1.debdiff . 
No intent to NMU in Debian.

Bug#813690: ocserv: missing RADIUS support

[Nikos Mavrogiannopoulos]

Note that libradcli can also be used. It is available in debian testing.

On Thu, Feb 4, 2016 at 12:55 PM, Mantas Mikulėnas  wrote:
> Package: ocserv
> Version: 0.10.10-1
> Severity: wishlist
>
> Dear Maintainer,
>
> Could you include RADIUS authentication support in ocserv?
>
> (This would need libfreeradius-client2 v1.1.7.)
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (500, 'testing-updates'), (500, 
> 'stable-updates'), (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages ocserv depends on:
> ii  dbus   1.10.6-1
> ii  libc6  2.21-7
> ii  libgnutls-deb0-28  3.3.20-1
> ii  libhttp-parser2.1  2.1-2
> ii  liblz4-1   0.0~r131-1
> ii  libnl-3-2003.2.26-1
> ii  libnl-route-3-200  3.2.26-1
> ii  libopts25  1:5.18.7-3
> ii  libpam0g   1.1.8-3.2
> ii  libpcl11.6-1
> ii  libprotobuf-c1 1.1.1-1
> ii  libreadline6   6.3-8+b4
> ii  libseccomp22.2.3-2
> ii  libsystemd0228-4+b1
> ii  libtalloc2 2.1.5-1
> ii  libwrap0   7.6.q-25
>
> Versions of packages ocserv recommends:
> ii  ca-certificates  20160104
> ii  ssl-cert 1.0.37
>
> ocserv suggests no packages.
>
> -- no debconf information
>

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Holger Levsen]

Hi Josch,

On Donnerstag, 4. Februar 2016, Johannes Schauer wrote:
> maybe we can merge Lunar's original suggestion Installed-Build-Depends (a
> name which is missing the transitive/recursive-ness) with the new
> suggestion and make it:
> 
> Installed-Transitive-Build-Depends
> 
> This way it would not be confused with the *actual* transitive build
> depends

I'm sorry, but I think the opposite will be the case, this will cause *more* 
confusion: what are "installed transitive build depends" vs "actual transitive 
build depends"? 

I know that *you* have grasped the concept of transitive build depends very 
well, but I'm pretty sure that 97% of the DD population have no idea what 
transitive build depends are, especially compared to build-depends or 
alternative build-depends. And even 70% were too many.
 (AFAIK transitive build-depends are all possible build depends, so if a 
package build depends on python2 || python3 both python versions will be part 
of the transitive build depends. (Is that even correct?)

Also see $(torsocks dict transitive) - what does this word even mean? ;-)


cheers,
Holger


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

Bug#813617: virtualbox 5.0.14 for kernel 4.3.0-1-686-pae needs vboxdrv

[Gianfranco Costamagna]

Control: tags -1 moreinfo

Hi, can you please run
apt-get install --reinstall virtualbox-dkms

and then post the apt log and build.log?
/var/lib/dkms/virtualbox/5.0.14/build/make.log should be the right location for 
the file.

thanks

Gianfranco




Il Mercoledì 3 Febbraio 2016 19:12, Thomas Schmidt  ha scritto:
Package: virtualbox
Version: 5.0.14-dfsg-1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Using kernel 4.3.0-1-686-pae

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

starting virtualbox

   * What was the outcome of this action?

Kernel driver not installed (rc=-1908)

The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a 
permission problem with /dev/vboxdrv. Please install virtualbox-dkms package 
and load the kernel module by executing
'modprobe vboxdrv'
as root. If it is available in your distribution, you should install the DKMS 
package first. This package keeps track of Linux kernel changes and recompiles 
the vboxdrv kernel module if necessary.

where: suplibOsInit what: 3 VERR_VM_DRIVER_NOT_INSTALLED (-1908) - The support 
driver is not installed. On linux, open returned ENOEN

   * What outcome did you expect instead?

Nothing like that .-)

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'oldstable-updates'), 
(500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 4.3.0-1-686-pae (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 virtualbox depends on:
ii  adduser   3.113+nmu3
ii  init-system-helpers   1.24
ii  libc6 2.21-7
ii  libcurl3-gnutls   7.47.0-1
ii  libgcc1   1:5.3.1-7
ii  libgsoap7 2.8.22-2
ii  libpng12-01.2.54-1
ii  libpython2.7  2.7.11-3
ii  libsdl1.2debian   1.2.15-12
ii  libssl1.0.2   1.0.2f-2
ii  libstdc++65.3.1-7
ii  libvncserver1 0.9.10+dfsg-3+b1
ii  libvpx3   1.5.0-2
ii  libx11-6  2:1.6.3-1
ii  libxcursor1   1:1.1.14-1+b1
ii  libxext6  2:1.3.3-1
ii  libxml2   2.9.3+dfsg1-1
ii  libxmu6   2:1.1.2-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.11-3
ii  python2.7.11-1
ii  python2.7 2.7.11-3
pn  python:any
ii  virtualbox-dkms [virtualbox-modules]  5.0.14-dfsg-1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages virtualbox recommends:
ii  libgl1-mesa-glx [libgl1]  11.1.1-2
ii  libqt4-opengl 4:4.8.7+dfsg-5
ii  libqtcore44:4.8.7+dfsg-5
ii  libqtgui4 4:4.8.7+dfsg-5
ii  virtualbox-qt 5.0.14-dfsg-1

Versions of packages virtualbox suggests:
ii  vde22.3.2+r586-2+b1
pn  virtualbox-guest-additions-iso  

-- no debconf information

Bug#813683: unittest2: build loop with python{3}-linecache2.

[Héctor Orón Martínez]

Source: unittest2
Version: 1.1.0-6
Severity: normal

Hello,

  src:unittest2 package needs python{3}-linecache2 for build, and 
src:python-linecache2 needs python{3}-unittest2 for build. That introduces a 
build loop cycle which are undesired for different reasons.

  Could that build cycle be avoided? Or at least introduce a staging build to 
help break such cycle?

Regards

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

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

Bug#813674: Acknowledgement (zoom-player: fails with "X Error of failed request: BadMatch (invalid parameter attributes)")

[Alexandre Detiste]

PS:

This happens exactly in the second call to  display_get_pix_colour(int
x, int y).

Having this function return a dummy value early make it working
past the first screen.

Well, this is not the right fix obviously.

diff --git a/src/xdisplay.c b/src/xdisplay.c
index 0eff1c2..f55c79e 100644
--- a/src/xdisplay.c
+++ b/src/xdisplay.c
@@ -2971,7 +2971,8 @@ int display_get_pix_colour(int x, int y)
   XColor out;

   int res;
-
+  return 100;
+  printf("HERE\n");
   teeny = XGetImage(x_display, x_pixmap, x, y, 1, 1, AllPlanes, XYPixmap);
   px = XGetPixel(teeny, 0, 0);
   XDestroyImage(teeny);
@@ -2979,6 +2980,7 @@ int display_get_pix_colour(int x, int y)
   out.pixel = px;
   XQueryColor(x_display, DefaultColormap(x_display, x_screen),
  );
+  printf("HERE2\n");

Bug#813492:

[Andreas Matthus]

Hallo,

now I confirmed the bug on a real machine without kvm.

If a user is loged in with kde-gui you can see it fastly by

for ((i=1;i++;i<999)) do ssh -i mykey user@pc_ip ls >/dev/null ; done

user can be the own one or a other. pc_ip can be the IP over LAN, WAN or
localhost.

On this systems running debian stable.

with regards
Andreas Matthus

-- 
Dipl.-Phys. Andreas Matthus
Netzwerkadministrator

Technische Universität Dresden
Fakultät Architektur
01062 Dresden
Tel.: +49 (351) 463-33909
Fax: +49 (351) 463-36120
E-Mail: andreas.matt...@tu-dresden.de




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#813678: blktap-dkms: fails to build with mainline 4.4 based kernels

[Andy Whitcroft]

Package: blktap-dkms
Version: 2.0.93-0.5
Severity: important
Tags: patch
User: a...@ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Mainline 4.4 switches how we detect atomicity.  Follow that change when
compiling against 4.4 based kernels.  We are using this in Ubuntu with
our latest kernels.

Thanks for considering the patch.

-apw

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-2-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru blktap-dkms-2.0.93/debian/patches/series blktap-dkms-2.0.93/debian/patches/series
--- blktap-dkms-2.0.93/debian/patches/series	2015-12-17 08:41:17.0 +
+++ blktap-dkms-2.0.93/debian/patches/series	2016-02-04 09:42:41.0 +
@@ -3,3 +3,4 @@
 bi_sector-fix.patch
 mempool_resize.patch
 disallow_mempools_with_ctor.patch
+use-gfpflags_allow_blocking-when-available.patch
diff -Nru blktap-dkms-2.0.93/debian/patches/use-gfpflags_allow_blocking-when-available.patch blktap-dkms-2.0.93/debian/patches/use-gfpflags_allow_blocking-when-available.patch
--- blktap-dkms-2.0.93/debian/patches/use-gfpflags_allow_blocking-when-available.patch	1970-01-01 01:00:00.0 +0100
+++ blktap-dkms-2.0.93/debian/patches/use-gfpflags_allow_blocking-when-available.patch	2016-01-22 15:26:56.0 +
@@ -0,0 +1,28 @@
+Description: use gfpflags_allow_blocking when available
+ Follow changes in mainline 4.4 which moves to using
+ gfpflags_allow_blocking() to identify critical sections.
+Author: Andy Whitcroft 
+
+--- blktap-dkms-2.0.93.orig/request.c
 blktap-dkms-2.0.93/request.c
+@@ -26,6 +26,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include "blktap.h"
+ 
+@@ -338,8 +339,11 @@ static void*
+ __mempool_page_alloc(gfp_t gfp_mask, void *pool_data)
+ {
+ 	struct page *page;
+-
++#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 4, 0)
+ 	if (!(gfp_mask & __GFP_WAIT))
++#else
++if (!gfpflags_allow_blocking(gfp_mask))
++#endif
+ 		return NULL;
+ 
+ 	page = alloc_page(gfp_mask);

Bug#804547: [nvidia-driver] Outdated nvidia drivers

[Nick T.]

Hello Andreas,

The 355.11-1 version is 7 months old already which is way outdated already for 
newer games(e.g. XCOM-2 comming out this Friday needs 355.63 and above) the 
newest version on nvidias website is 358.16.
And also according to #813565 the new driver is not compatible with sids X abi.

Regards,
Nick

-- 

Bug#806595: stupid by design?

[Marcel Partap]

Uhhm.. so why does it try to write to a dir calculably owned by root
with dropped privileges in the first place? Somewhat bothersome :/

Bug#813679: nettle: CVE-2015-8803 CVE-2015-8804 CVE-2015-8805

[Salvatore Bonaccorso]

Source: nettle
Version: 2.7.1-1
Severity: important
Tags: security upstream patch

Hi,

the following vulnerabilities were published for nettle.

CVE-2015-8803[0]:
secp256 calculation bug

CVE-2015-8804[1]:
Miscalculations on secp384 curve

CVE-2015-8805[2]:
miscomputation bugs in secp-256r1 modulo functions

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2015-8803
[1] https://security-tracker.debian.org/tracker/CVE-2015-8804
[2] https://security-tracker.debian.org/tracker/CVE-2015-8805

Regards,
Salvatore

Bug#804547: [nvidia-driver] Outdated nvidia drivers

[Luca Boccassi]

On 4 February 2016 at 09:55, Nick T.  wrote:
> Hello Andreas,
>
> The 355.11-1 version is 7 months old already which is way outdated already 
> for newer games(e.g. XCOM-2 comming out this Friday needs 355.63 and above) 
> the newest version on nvidias website is 358.16.
> And also according to #813565 the new driver is not compatible with sids X 
> abi.

Hi Nick,

We know, Andreas is working through all major versions so that they
are all in the archive. If you noticed, 343 through 352 went into
unstable in rapid succession.

355 was next in the list and that's why it went to experimental, and
we just tested 358 and it works fine so I guess it will most likely be
next in queue for experimental.

Note that there is no 355.63 on Linux - I guess newer games will
require 358 or 361 (which is just a beta for now, it needs some major
packaging changes due to libraries reorganizations so it's not ready
yet).

Please be patient.

Kind regards,
Luca Boccassi

Bug#813685: php5-intl: Invalid dependencies on php5-intl package

[Pascal Wacker]

Package: php5-intl
Severity: serious
Tags: d-i
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

I tried to install php5-intl using `sudo apt-get install php5-intl` on a Ubuntu
14.04 server. Aptitude said, that php5-intl requires the package `libicu48`,
which it isn't able to locate (there ain't no intallation candidate).

I then tried to install `libicu-dev` which infact installs `libicu52`.
Unfortunately, that didn't help. I solved the problem on the server by
downloading `libicu48` from http://packages.ubuntu.com/de/precise/libicu48,
then installing it, using `dpkg`. After that the installation of `php5-intl`
worked as expected.

Hopefully the problem will be solved by updating the dependencies to
`libicu52`, but I have no idea, how to do and test that.

Thanks for looking into the issue (:



-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-27-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#773287: [PKG-OpenRC-Debian] Bug#773287: openrc: Please enable SELinux support

[Benda Xu]

Laurent Bigonville  writes:

> Hi again,
>
>> Could it be possible to enable openrc selinux support?
>>
>> The attached patch should achieve this.
>
> Please find here a new patch, it's also adding PAM and audit support

Ack and thanks a lot.  I will review and include your patch in the next
release.

Benda

Bug#638049: aptitude forgets which packages were installed automatically

[Harald Dunkel]

I think I know how to reproduce:

- install minimal Debian unstable (a container or chroot should do)
- boot it or chroot to it
- configure networking
- enter aptitude and install a package with a huge list of
  dependencies (e.g. owncloud)
- leave aptitude
- enter aptitude
- mark "owncloud" to be removed (using "_")
- hit "g" once to get the list of packages to be removed
- mark "php5" to be kept (using "+")
- press q

Now the dependencies of php5 should have lost their "automatically
installed" flag.

Maybe you already knew, but I never saw it happening live before.


Regards
Harri

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Holger Levsen]

no thanks for totally dismissing what I said…

and making funny signs about the crap I said. very funny.


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

Bug#813694: build openmpi on s390x

[Matthias Klose]

Package: src:openmpi
Version: 1.10.2-3
Tags: patch

Please build openmpi on s390x. while mpi itself is not used that much on s390x, 
it may be better to go with the implementation which is used for most architectures.


patch at
http://launchpadlibrarian.net/236138435/openmpi_1.10.2-3_1.10.2-3ubuntu1.diff.gz

Bug#813682: simple-scan: set default format documents

[Pol Hallen]

Package: simple-scan
Version: 3.19.2-1
Severity: wishlist

Howdy,
is it possibile add an option to set default saving of documents format? (jpg / 
pdf)
thanks!

-- Package-specific info:

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

Kernel: Linux 3.13-1-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages simple-scan depends on:
ii  adwaita-icon-theme   3.18.0-2
ii  dbus-x11 1.10.6-1
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  libatk1.0-0  2.18.0-1
ii  libc62.19-22
ii  libcairo-gobject21.14.6-1
ii  libcairo21.14.6-1
ii  libcolord2   1.2.12-1
ii  libgdk-pixbuf2.0-0   2.32.3-1
ii  libglib2.0-0 2.46.2-3
ii  libgtk-3-0   3.18.6-1
ii  libgusb2 0.2.8-1
ii  libpackagekit-glib2-18   1.0.11-1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libsane  1.0.24-9
ii  libsqlite3-0 3.9.2-1
ii  libusb-1.0-0 2:1.0.20-1
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

simple-scan recommends no packages.

simple-scan suggests no packages.

-- no debconf information
[+0.00s] DEBUG: simple-scan.vala:674: Starting Simple Scan 3.19.2, PID=1478
[+0.00s] DEBUG: Connecting to session manager
[+0.21s] DEBUG: ui.vala:2018: Loading state from 
/home/max/.cache/simple-scan/state
[+0.21s] DEBUG: ui.vala:1986: Restoring window to 947x403 pixels
[+0.21s] DEBUG: autosave-manager.vala:64: Loading autosave information
[+0.21s] DEBUG: autosave-manager.vala:259: Waiting to autosave...
[+0.21s] CRITICAL: gtk_event_controller_reset: assertion 
'GTK_IS_EVENT_CONTROLLER (controller)' failed
[+0.29s] DEBUG: scanner.vala:1447: sane_init () -> SANE_STATUS_GOOD
[+0.29s] DEBUG: scanner.vala:1453: SANE version 1.0.24
[+0.29s] DEBUG: scanner.vala:1514: Requesting redetection of scan devices
[+0.29s] DEBUG: scanner.vala:803: Processing request
[+0.31s] DEBUG: autosave-manager.vala:281: Autosaving book information
[+0.41s] DEBUG: ui.vala:2109: Saving state to /home/max/.cache/simple-scan/state
[+6.46s] DEBUG: simple-scan.vala:404: Requesting scan at 150 dpi from device 
'(null)'
[+6.46s] DEBUG: scanner.vala:1560: Scanner.scan ("(null)", dpi=150, 
scan_mode=ScanMode.COLOR, depth=8, type=ScanType.SINGLE, paper_width=2100, 
paper_height=2970, brightness=-56, contrast=0)
[+10.89s] DEBUG: scanner.vala:338: sane_get_devices () -> SANE_STATUS_GOOD
[+10.89s] DEBUG: scanner.vala:350: Device: name="epson2:/dev/sg3" 
vendor="Epson" model="GT-7000" type="flatbed scanner"
[+10.89s] DEBUG: scanner.vala:803: Processing request
[+10.89s] DEBUG: scanner.vala:864: sane_open ("epson2:/dev/sg3") -> 
SANE_STATUS_GOOD
[+10.89s] DEBUG: scanner.vala:885: sane_get_option_descriptor (0)
[+10.89s] DEBUG: scanner.vala:735: Option 0: name='(null)' title='Number of 
options' type=int size=4 cap=soft-detect
[+10.89s] DEBUG: scanner.vala:738:   Description: Read-only option that 
specifies how many options a specific devices supports.
[+10.89s] DEBUG: scanner.vala:885: sane_get_option_descriptor (1)
[+10.89s] DEBUG: scanner.vala:735: Option 1: name='(null)' title='Scan Mode' 
type=group size=4
[+10.89s] DEBUG: scanner.vala:738:   Description: 
[+10.89s] DEBUG: scanner.vala:885: sane_get_option_descriptor (2)
[+10.89s] DEBUG: scanner.vala:735: Option 2: name='mode' title='Scan mode' 
type=string size=8 values=["Lineart", "Gray", "Color"] 
cap=soft-select,soft-detect
[+10.89s] DEBUG: scanner.vala:738:   Description: Selects the scan mode (e.g., 
lineart, monochrome, or color).
[+10.89s] DEBUG: scanner.vala:885: sane_get_option_descriptor (3)
[+10.89s] DEBUG: scanner.vala:735: Option 3: name='depth' title='Bit depth' 
type=int size=4 values=[8] cap=soft-select,soft-detect,inactive
[+10.89s] DEBUG: scanner.vala:738:   Description: Number of bits per sample, 
typical values are 1 for "line-art" and 8 for multibit scans.
[+10.89s] DEBUG: scanner.vala:885: sane_get_option_descriptor (4)
[+10.89s] DEBUG: scanner.vala:735: Option 4: name='halftoning' 
title='Halftoning' type=string size=26 values=["None", "Halftone A (Hard 
Tone)", "Halftone B (Soft Tone)", "Halftone C (Net Screen)", "Dither A (4x4 
Bayer)", "Dither B (4x4 Spiral)", "Dither C (4x4 Net Screen)", "Dither D (8x4 
Net Screen)", "Text Enhanced Technology", "Download pattern A", "Download 
pattern B"] 

Bug#802361: unittest2: FTBFS: FAIL: test_loadTestsFromName__relative_malformed_name

[Hector Oron]

Hello,

On Mon, Oct 19, 2015 at 07:16:34PM +0100, Chris West (Faux) wrote:
> Source: unittest2
> Version: 1.1.0-6
> Severity: serious
> Justification: fails to build from source

Note this is not the optimum solution however, package builds when tests are 
run with python27 instead python35 (default interpreter).

--- unittest2-1.1.0/debian/rules2015-07-09 11:06:19.0 +0200
+++ unittest2-1.1.0/debian/rules2016-02-04 11:28:07.0 +0100
@@ -12,4 +12,4 @@
 # Tests cannot run without unittest2 running them.
  # See: https://code.google.com/p/unittest-ext/issues/detail?id=93 for details
   override_dh_auto_test:
   -   dh_auto_test -- --system=custom --test-args='{interpreter} -m 
unittest2'
   +   dh_auto_test -- --system=custom --test-args='python2.7 -m unittest2'

Regards
-- 
  Hector Oron


signature.asc
Description: PGP signature

Bug#813624: RFS: ismrmrd/1.3.2-2 [RC]

[Gianfranco Costamagna]

Hi, please not it still fails on armhf.

thanks

G.





Il Mercoledì 3 Febbraio 2016 20:45, Ghislain Vaillant  ha 
scritto:
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "ismrmrd"

* Package name: ismrmrd
   Version : 1.3.2-2
   Upstream Author : The ISMRMRD developers
* URL : http://ismrmrd.github.io/
* License : Expat
   Section : science

It builds those binary packages:

   ismrmrd-schema - ISMRM Raw Data format (ISMRMRD) - XML schema
   ismrmrd-tools - ISMRM Raw Data format (ISMRMRD) - binaries
   libismrmrd-dev - ISMRM Raw Data format (ISMRMRD) - development files
   libismrmrd-doc - ISMRM Raw Data format (ISMRMRD) - documentation
   libismrmrd1.3 - ISMRM Raw Data format (ISMRMRD) - shared library

To access further information about this package, please visit the 
following URL:

  http://mentors.debian.net/package/ismrmrd

Alternatively, one can download the package with dget using this command:

   dget -x 
http://mentors.debian.net/debian/pool/main/i/ismrmrd/ismrmrd_1.3.2-2.dsc

Changes since the last upload:

   * d/control: use secure VCS-Git URI.
   * Add patch fixing FTBFS in testsuite.
 File: Use-explicit-64-bit-shifts-in-testsuite.patch.
 Thanks to Emilio Pozuelo Monfort (Closes: #802172)
   * Provide examples in doc package.
   * d/control: cme fix, wrap and sort.
   * Fix usage of embedded jquery.

Best regards,
Ghislain Vaillant

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Jérémy Bobbio]

Holger Levsen:
> I know that *you* have grasped the concept of transitive build depends very 
> well, but I'm pretty sure that 97% of the DD population have no idea what 
> transitive build depends are, especially compared to build-depends or 
> alternative build-depends. And even 70% were too many.

Sorry Holger but we are introducing new concepts. So sure, 97% of the DD
population have no idea what we are talking about, but that's fine.

We have to educate them about .buildinfo file and what the various
fields mean. We have to aim at field names that are as unambigious as
possible to avoid laying traps on users.

For the particular case of “Installed-Transitive-Build-Depends”,
it's easy enough to explain “these are the name and version of all
packages which made building these binary packages possible”. Math
geeks can get a more formal definition.

“Built-Using” is already taken with a very precise meaning (and is there
for license-compliance reasons), but that would be the simpliest way to
sum up the short statement above. Given these are .buildinfo files, I
would be bold and suggest just “Using”.


I need to state that I care more about not drowning ourselves in bike
shedding than finding the perfect name.


-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#813599: systemd - systemd-random-seed.service fails to start in clean install

[Michael Biebl]

Control: tags -1 - moreinfo

Am 04.02.2016 um 21:07 schrieb Bastian Blank:
> On Thu, Feb 04, 2016 at 03:04:39AM +0100, Michael Biebl wrote:
>> For some reasons, this fails on your system. Any idea why? When exactly
>> did you get this error?
> 
> Actually I found it in the meantime.  /, including /var, was read-only.
> 
> The resppnsible code reads:
> 
> | seed_fd = open(RANDOM_SEED, O_RDWR|O_CLOEXEC|O_NOCTTY|O_CREAT, 0600);
> | if (seed_fd < 0) {
> | seed_fd = open(RANDOM_SEED, O_RDONLY|O_CLOEXEC|O_NOCTTY);
> 
> So it ignores the error given by the first call (EROFS), which would be
> a clear indication, and only provides the useless second one.

True, it should probably log the error message. Will forward this issue
upstream.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#813731: starpu-contrib: FTBFS: undefined reference to `leveldb::DB::Open

[Samuel Thibault]

Hello,

Mattia Rizzolo, on Thu 04 Feb 2016 19:13:03 +, wrote:
> ../src/.libs/libstarpu-1.2.so: undefined reference to 
> `leveldb::DB::Open(leveldb::Options const&, std::string const&, 
> leveldb::DB**)'

#813173 says it's a problem of gcc-4.x-built starpu link against
gcc-5.x-built leveldb (recently uploaded)

The current version of CUDA in unstable does not support gcc-5, that's
why the hardcoded gcc 4.x. That will however be fixed with newer
versions of CUDA. In the meanwhile we can't build starpu-contrib. If
that becomes a problem for some transitions, please feel free to request
binary removals from testing from ftpmaster (this very bug will prevent
it from reentering testing again).

Samuel

Bug#812994: apt 1.2.1 fails to configure packages

[Guillem Jover]

On Thu, 2016-02-04 at 08:39:30 -0500, James McCoy wrote:
> On Thu, Feb 04, 2016 at 12:56:53AM +0100, Guillem Jover wrote:
> > On Wed, 2016-02-03 at 09:22:51 -0500, James McCoy wrote:
> > > I had a similar problem today.
> > 
> > > ...
> > > Selecting previously unselected package libn32atomic1-mips64el-cross.
> > > Preparing to unpack .../libjpeg62-turbo_1%3a1.4.2-2_amd64.deb ...
> > > Unpacking libn32atomic1-mips64el-cross (5.3.1-7cross1) ...
> > > ...
> > > dpkg: error processing package libjpeg62-turbo:amd64 (--configure):
> > >  package libjpeg62-turbo:amd64 is already installed and configured
> > > ...
> > 
> > The first and third lines come supposedly from the .deb control file,
> > the second from the filename.
> > 
> > If this is just a problem with wrong strings, then libjpeg62-turbo:amd64
> > in theory would not be already configured, just unpacked (but I might be
> > missing context here).
> 
> Well, version 1:1.4.1-2 of libjpeg62-turbo was already configured and
> since the newer version wasn't unpacked (libn32atomic1-mips64el-cross
> was instead), there was nothing to configure.

My reasoning was all based on conjectures. But this is my thinking,
since libjpeg62-turbo_1%3a1.4.2-2 is the version shown on the string,
assuming that was the correct package being processed, if that was
actually being unpacked, then I'd assume it would be upgrading from an
older version than 1:1.4.1-2, and then the package would end up in the
unpacked state. (But the log you provided might be missing other
context, I assume the package was not previously configured too.)

If the wrong string was libjpeg62-turbo_1%3a1.4.2-2_amd64.deb, and the
correct information was coming from the .deb control file, then I guess
you should have libn32atomic1-mips64el-cross installed? In which case
that would be a very strong hint that the .deb provided by apt was not
what it was supposed to be.

> > > >From /var/log/dpkg.log:
> > > 
> > > 2016-02-03 08:53:33 startup archives unpack
> > > ...
> > > 2016-02-03 08:53:40 install libn32atomic1-mips64el-cross:all  
> > > 5.3.1-7cross1
> > > 2016-02-03 08:53:40 status half-installed 
> > > libn32atomic1-mips64el-cross:all 5.3.1-7cross1
> > > 2016-02-03 08:53:40 status unpacked libn32atomic1-mips64el-cross:all 
> > > 5.3.1-7cross1
> > > 2016-02-03 08:53:40 status unpacked libn32atomic1-mips64el-cross:all 
> > > 5.3.1-7cross1
> > 
> > Just to make sure, if you have the libjpeg62-turbo_1%3a1.4.2-2_amd64.deb
> > around could you check that it really contains the libjpec62-turbo
> > package inside with say dpkg-deb, or manually with ar+tar?
> 
> I don't, but I've now disabled apt's automatic removal of the .deb when
> a package is installed.  I'll do this on all my hosts so next time I hit
> the issue I'll be able to answer this question.

Perfect thanks!

> > If you have the previous status file in /var/backups, and you could
> > try to reproduce this that would be great, otherwise, sending it here
> > or to me and the apt maintainers in case of privacy concerns might help
> > too.
> 
> I downgraded libjpeg62-turbo and performed an upgrade again, but that
> specific scenario didn't reproduce.

Assuming this is not dependent on the state of the apt cache or
something similar, what I'd do would be either debootstrap a new
system and place the backed up status there before the issue, and try
to upgrade using a snapshot from the same time. Or the slighly more
dangerious option, for which I don't want to be responsible, ;) would
be to backup your current status file, replace it with the one from
before the issue and perform the above snapshotted upgrade. Once you
are done you should be able to restore the status file, and reinstall
any affected package.

> > > I'm not sure if this is something to do with how apt is driving dpkg or
> > > dpkg itself is getting confused, but hopefully this helps.
> > 
> > (It could well be dak being confused perhaps? But… :)
> 
> That would have broader visibility, though, wouldn't it?

Yeah, and would mean that it can be easily reproduced. A compromised
mirror does not seem likely either. Just grasping at straws I guess.

Thanks,
Guillem

Bug#813750: RM: libpam-foreground -- RoQA; no longer needed

[Michael Biebl]

Package: ftp.debian.org
Severity: normal

Hi,

please remove the libpam-foreground package.

It's a transitional package which is no longer necessary.
The transition was already completed in squeeze (oldstable).

There is no point keeping it around anymore.

Regards,
Michael

Bug#813745: RFA: consolekit -- framework for defining and tracking users, sessions and seats

[Michael Biebl]

Package: wnpp
Severity: normal

I request an adopter for the consolekit package.

My attempts to find a new maintainer weren't successful as it seems.
While Robert Millan agreed to take over as maintainer, there wasn't any
real follow up maintenance work.

I therefor moved the package from pkg-utopia to collab-maint [1] and I'm
looking for a new maintainer now.

consolekit itself is abandoned upstream and has been replaced by logind
(on Linux). Anyone taking over consolekit would be pretty much upstream
for it.

[1] https://anonscm.debian.org/cgit/collab-maint/consolekit.git/

Bug#811918: [Debian-astro-maintainers] Bug#811918: gnudatalanguage: FTBFS with GCC 6: misc errors

[Axel Beckert]

Control: forwarded -1 https://sourceforge.net/p/gnudatalanguage/bugs/686/ 
http://sourceforge.net/p/gnudatalanguage/bugs/688/

Hi,

Martin Michlmayr wrote:
> > /<>/src/typedefs.hpp: In member function 'Guard& 
> > Guard::operator=(Guard&)':
> > /<>/src/typedefs.hpp:238:21: error: return-statement with no 
> > value, in function returning 'Guard&' [-fpermissive]
> >  if(  == this) return;
> >  ^~

This part is now fixed upstream in
http://gnudatalanguage.cvs.sourceforge.net/viewvc/gnudatalanguage/gdl/src/typedefs.hpp?r1=1.76=1.77

> > In file included from /<>/src/datatypes.hpp:499:0,
> >  from /<>/src/dstructdesc.cpp:22:
> > /<>/src/specializations.hpp: At global scope:
> > /<>/src/specializations.hpp:537:65: error: 'operator>>' is not 
> > a template function
> >  std::istream& operator>>(std::istream& i, Data_& data_);

For these types of errors, a separate upstream bug has been filed at
http://sourceforge.net/p/gnudatalanguage/bugs/688/. This is not yet
fixed, hence neither marking as fixed-upstream nor as having a patch.

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#810379: [Xen-devel] [BUG] pci-passthrough generates "xen:events: Failed to obtain physical IRQ" for some devices

[Tommi Airikka]

Hi,

I patched the deb8u2 source with all four patches and built a new deb.

As two of the patches make some changes on the pcifront, I thought it could
be a good idea to first upgrade the domU 'bug' with the new linux-image.

domU 'bug' "uname -a":
Linux bug 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2a~test
(2016-02-04) x86_64 GNU/Linux

dom0 "uname -a":
Linux dom0 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02)
x86_64 GNU/Linux

At first, all seemed to be as expected. I still got the "Failed to obtain
physical IRQ" as the dom0 is not upgraded with the new linux-image.
But after a couple of minutes, I got "INFO: task khubd:205 blocked for more
than 120 seconds." with a call trace in dmesg (and there is a new call
trace periodically every 120 seconds).

domU 'bug' "dmesg":
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org)
(gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian
3.16.7-ckt20-1+deb8u2a~test (2016-02-04)
[0.00] Command line: root=/dev/xvda2 ro elevator=noop
root=/dev/xvda2 ro
[0.00] ACPI in unprivileged domain disabled
[0.00] 1-1 mapping on 8000->10
[0.00] Set 1015808 page(s) to 1-1 mapping
[0.00] 1-1 mapping on 10->800
[0.00] e820: BIOS-provided physical RAM map:
[0.00] Xen: [mem 0x-0x0009] usable
[0.00] Xen: [mem 0x000a-0x000f] reserved
[0.00] Xen: [mem 0x0010-0x07ff] usable
[0.00] Xen: [mem 0x0800-0xf1de3fff] unusable
[0.00] Xen: [mem 0xf1de4000-0xf1dedfff] ACPI data
[0.00] Xen: [mem 0xf1dee000-0xf7ff] reserved
[0.00] Xen: [mem 0xfec0-0xfeef] reserved
[0.00] Xen: [mem 0xff80-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] DMI not present or invalid.
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x8000 max_arch_pfn = 0x4
[0.00] Base memory trampoline at [8809a000] 9a000 size 24576
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] init_memory_mapping: [mem 0x07e0-0x07ff]
[0.00]  [mem 0x07e0-0x07ff] page 4k
[0.00] BRK [0x01b02000, 0x01b02fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x0400-0x07df]
[0.00]  [mem 0x0400-0x07df] page 4k
[0.00] BRK [0x01b03000, 0x01b03fff] PGTABLE
[0.00] BRK [0x01b04000, 0x01b04fff] PGTABLE
[0.00] BRK [0x01b05000, 0x01b05fff] PGTABLE
[0.00] BRK [0x01b06000, 0x01b06fff] PGTABLE
[0.00] BRK [0x01b07000, 0x01b07fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x0010-0x03ff]
[0.00]  [mem 0x0010-0x03ff] page 4k
[0.00] RAMDISK: [mem 0x01f18000-0x04a4efff]
[0.00] NUMA turned off
[0.00] Faking a node at [mem 0x-0x07ff]
[0.00] Initmem setup node 0 [mem 0x-0x07ff]
[0.00]   NODE_DATA [mem 0x07fe7000-0x07febfff]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x1000-0x00ff]
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x0009]
[0.00]   node   0: [mem 0x0010-0x07ff]
[0.00] On node 0 totalpages: 32671
[0.00]   DMA zone: 56 pages used for memmap
[0.00]   DMA zone: 21 pages reserved
[0.00]   DMA zone: 3999 pages, LIFO batch:0
[0.00]   DMA32 zone: 392 pages used for memmap
[0.00]   DMA32 zone: 28672 pages, LIFO batch:7
[0.00] SFI: Simple Firmware Interface v0.81
http://simplefirmware.org
[0.00] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
[0.00] nr_irqs_gsi: 16
[0.00] PM: Registered nosave memory: [mem 0x000a-0x000f]
[0.00] e820: [mem 0xf800-0xfebf] available for PCI devices
[0.00] Booting paravirtualized kernel on Xen
[0.00] Xen version: 4.4.1 (preserve-AD)
[0.00] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1
nr_node_ids:1
[0.00] PERCPU: Embedded 27 pages/cpu @880007c0 s80896 r8192
d21504 u2097152
[0.00] pcpu-alloc: s80896 r8192 d21504 u2097152 alloc=1*2097152
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Node order, mobility grouping on.
Total pages: 32202
[0.00] Policy zone: DMA32
[

Bug#812994: apt 1.2.1 fails to configure packages

[Julian Andres Klode]

On 4 February 2016 at 23:44, Guillem Jover  wrote:
> On Thu, 2016-02-04 at 08:39:30 -0500, James McCoy wrote:
>> On Thu, Feb 04, 2016 at 12:56:53AM +0100, Guillem Jover wrote:
>> > On Wed, 2016-02-03 at 09:22:51 -0500, James McCoy wrote:
>> > > I had a similar problem today.
>> >
>> > > ...
>> > > Selecting previously unselected package libn32atomic1-mips64el-cross.
>> > > Preparing to unpack .../libjpeg62-turbo_1%3a1.4.2-2_amd64.deb ...
>> > > Unpacking libn32atomic1-mips64el-cross (5.3.1-7cross1) ...
>> > > ...
>> > > dpkg: error processing package libjpeg62-turbo:amd64 (--configure):
>> > >  package libjpeg62-turbo:amd64 is already installed and configured
>> > > ...
>> >
>> > The first and third lines come supposedly from the .deb control file,
>> > the second from the filename.
>> >
>> > If this is just a problem with wrong strings, then libjpeg62-turbo:amd64
>> > in theory would not be already configured, just unpacked (but I might be
>> > missing context here).
>>
>> Well, version 1:1.4.1-2 of libjpeg62-turbo was already configured and
>> since the newer version wasn't unpacked (libn32atomic1-mips64el-cross
>> was instead), there was nothing to configure.
>
> My reasoning was all based on conjectures. But this is my thinking,
> since libjpeg62-turbo_1%3a1.4.2-2 is the version shown on the string,
> assuming that was the correct package being processed, if that was
> actually being unpacked, then I'd assume it would be upgrading from an
> older version than 1:1.4.1-2, and then the package would end up in the
> unpacked state. (But the log you provided might be missing other
> context, I assume the package was not previously configured too.)
>
> If the wrong string was libjpeg62-turbo_1%3a1.4.2-2_amd64.deb, and the
> correct information was coming from the .deb control file, then I guess
> you should have libn32atomic1-mips64el-cross installed? In which case
> that would be a very strong hint that the .deb provided by apt was not
> what it was supposed to be.
>
>> > > >From /var/log/dpkg.log:
>> > >
>> > > 2016-02-03 08:53:33 startup archives unpack
>> > > ...
>> > > 2016-02-03 08:53:40 install libn32atomic1-mips64el-cross:all  
>> > > 5.3.1-7cross1
>> > > 2016-02-03 08:53:40 status half-installed 
>> > > libn32atomic1-mips64el-cross:all 5.3.1-7cross1
>> > > 2016-02-03 08:53:40 status unpacked libn32atomic1-mips64el-cross:all 
>> > > 5.3.1-7cross1
>> > > 2016-02-03 08:53:40 status unpacked libn32atomic1-mips64el-cross:all 
>> > > 5.3.1-7cross1
>> >
>> > Just to make sure, if you have the libjpeg62-turbo_1%3a1.4.2-2_amd64.deb
>> > around could you check that it really contains the libjpec62-turbo
>> > package inside with say dpkg-deb, or manually with ar+tar?
>>
>> I don't, but I've now disabled apt's automatic removal of the .deb when
>> a package is installed.  I'll do this on all my hosts so next time I hit
>> the issue I'll be able to answer this question.
>
> Perfect thanks!
>
>> > If you have the previous status file in /var/backups, and you could
>> > try to reproduce this that would be great, otherwise, sending it here
>> > or to me and the apt maintainers in case of privacy concerns might help
>> > too.
>>
>> I downgraded libjpeg62-turbo and performed an upgrade again, but that
>> specific scenario didn't reproduce.
>
> Assuming this is not dependent on the state of the apt cache or
> something similar, what I'd do would be either debootstrap a new
> system and place the backed up status there before the issue, and try
> to upgrade using a snapshot from the same time. Or the slighly more
> dangerious option, for which I don't want to be responsible, ;) would
> be to backup your current status file, replace it with the one from
> before the issue and perform the above snapshotted upgrade. Once you
> are done you should be able to restore the status file, and reinstall
> any affected package.
>
>> > > I'm not sure if this is something to do with how apt is driving dpkg or
>> > > dpkg itself is getting confused, but hopefully this helps.
>> >
>> > (It could well be dak being confused perhaps? But… :)
>>
>> That would have broader visibility, though, wouldn't it?
>
> Yeah, and would mean that it can be easily reproduced. A compromised
> mirror does not seem likely either. Just grasping at straws I guess.
>
> Thanks,
> Guillem
>

On IRC it was mentioned that bug #813000 mentions that the update can
generate Packages files in the APT dir with messed up contents. I'm
not entirely sure it's related, but maybe it is. That must be a very
unlikely incarnation of that bug though (two packages would need their
Filename and various hash sum fields replaced by that of another
package).

We cannot reproduce that one yet, but I'm working on it (running apt
update manually now, and backing up lists before update).

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Bug#813698: qemu-user-static: qemu-ppc64le-static segfaults in ppc64el chroot

[Daniel Stender]

Thank you very much for quick reply, background info and the workaround. Great!

DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#813728: boinc-client: spews "No protocol specified" every second when active

[Preston Maness]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Howdy howdy,

I suspect this is related to XOpenDisplay() calls failing during idle
detection (due to the Xserver being inaccessible for some reason). It
shouldn't be harming performance of the boinc-client in any way, but
I'll look into suppressing the log spam when the relevant calls fail.
I had already pushed all the debug log info to an optional,
non-default flag, but it looks like the XSS library might have a
hard-coded printf somewhere.

The "idle_detection_debug" log flag can be put in cc_config.xml file:


  
1
1
1
1
1
  


See

https://github.com/BOINC/boinc/pull/1453

for the relevant pull request where I reinstated and improved the
XSS-based idle detection.

Cheers,
Preston Maness

On 02/04/2016 01:00 PM, Aaron M. Ucko wrote:
> Package: boinc-client Version: 7.6.22+dfsg-3 Severity: minor
> 
> Since upgrading to boinc-client 7.6.22+dfsg-3 last night (when it
> hit testing), I've observed it to log "No protocol specified" once
> a second, except when suspended, per the log excerpt below.  As far
> as I can tell, it otherwise continues to work fine, but these
> messages are getting to be a nuisance.
> 
> Could you please take a look?
> 
> Thanks!
> 
> Feb  4 09:54:09 ghostwheel boinc[13404]: No protocol specified Feb
> 4 09:54:10 ghostwheel boinc[13404]: No protocol specified Feb  4
> 09:54:11 ghostwheel boinc[13404]: No protocol specified Feb  4
> 09:54:12 ghostwheel boinc[13404]: 04-Feb-2016 09:54:12 [---]
> Suspending computation - computer is in use Feb  4 10:04:17
> ghostwheel boinc[13404]: No protocol specified Feb  4 10:04:17
> ghostwheel boinc[13404]: 04-Feb-2016 10:04:17 [---] Resuming
> computation Feb  4 10:04:18 ghostwheel boinc[13404]: No protocol
> specified Feb  4 10:04:19 ghostwheel boinc[13404]: No protocol
> specified Feb  4 10:04:20 ghostwheel boinc[13404]: No protocol
> specified
> 
> -- Package-specific info: -- Contents of
> /etc/default/boinc-client: # This file is
> /etc/default/boinc-client, it is a configuration file for the #
> /etc/init.d/boinc-client init script.
> 
> # Set this to 1 to enable and to 0 to disable the init script. 
> ENABLED="1"
> 
> # Set this to 1 to enable advanced scheduling of the BOINC core
> client and # all its sub-processes (reduces the impact of BOINC on
> the system's # performance). SCHEDULE="1"
> 
> # The BOINC core client will be started with the permissions of
> this user. BOINC_USER="boinc"
> 
> # This is the data directory of the BOINC core client. 
> BOINC_DIR="/var/lib/boinc-client"
> 
> # This is the location of the BOINC core client, that the init
> script uses. # If you do not want to use the client program
> provided by the boinc-client # package, you can specify here an
> alternative client program. #BOINC_CLIENT="/usr/local/bin/boinc" 
> BOINC_CLIENT="/usr/bin/boinc"
> 
> # Here you can specify additional options to pass to the BOINC core
> client. # Type 'boinc --help' or 'man boinc' for a full summary of
> allowed options. #BOINC_OPTS="--allow_remote_gui_rpc" 
> BOINC_OPTS=""
> 
> # Scheduling options
> 
> # Set SCHEDULE="0" if prefering to run with upstream default
> priority # settings.
> 
> # Nice levels. When systems are truly busy, e.g. because of too
> many active # scientific applications started by the boinc client,
> there is a chance for # the boinc client not to be granted
> sufficient opportunity to check for # scientific applications to be
> alive and make the (wrong) decision to # terminate the scientific
> app. This is particularly an issue with many # apps started in
> parallel on modern multi-core systems and extra overheads # for the
> download and uploads of files with the project servers. Another #
> concern is the latency for scientific applications to communicate
> with the # graphics card, which should be low. All such values
> should be set and # controled from within the BOINC client. The
> Debian init script also sets # extra constrains via chrt on real
> time performance and via ionice on # I/O performance, which is
> beyond the regular BOINC client. It then was # too easy to use that
> code to also constrain minimal nice levels. We still # think about
> how to best distinguish GPU applications from regular apps. 
> BOINC_NICE_CLIENT=10 BOINC_NICE_APP_DEFAULT=19 
> #BOINC_NICE_APP_GPU=5# not yet used
> 
> # ionice classes. See manpage of ionice (1) in the util-linux
> package. BOINC_IONICE_CLIENT=3# idle 
> #BOINC_IONICE_APP_DEFAULT=3  # idle, not yet used 
> #BOINC_IONICE_APP_GPU=2  # best effort, not yet used
> 
> 
> -- System Information: Debian Release: stretch/sid APT prefers
> testing APT policy: (500, 'testing'), (500, 'stable'), (300,
> 'unstable') Architecture: amd64 (x86_64) Foreign Architectures:
> i386
> 
> Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale:
> LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell:
> /bin/sh linked to /bin/dash Init: systemd (via
> /run/systemd/system)
> 
> 

Bug#813748: breaks Google Maps links

[積丹尼 Dan Jacobson]

X-debbugs-Cc: perl...@katspace.com
Package: txt2html
Version: 2.51-1
Severity: wishlist

Not sure of where to send bug reports to.

Google map links now all include a @.

But txt2html by default assumes URLs stop at this character.

Bug#813742: vorbis-tools: French translation

[Damien / vauss]

Package: vorbis-tools
Version: 1.4.0-6
Severity: wishlist
Tags: l10n

Dear Maintainer,

Please find attached the french po translation, proofread by the
debian-l10n-french mailing list contributors.

Best regards,

Damien / vauss



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

Kernel: Linux 3.16.0-4-686-pae (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 vorbis-tools depends on:
ii  libao4   1.1.0-3
ii  libc62.19-18+deb8u2
ii  libcurl3-gnutls  7.38.0-4+deb8u3
ii  libflac8 1.3.0-3
ii  libogg0  1.3.2-1
ii  libspeex11.2~rc1.2-1
ii  libvorbis0a  1.3.4-2
ii  libvorbisenc21.3.4-2
ii  libvorbisfile3   1.3.4-2

vorbis-tools recommends no packages.

vorbis-tools suggests no packages.

-- no debconf information
# vorbis-tools French translation
# Copyright (C) 2015 Debian French l10n team 
# This file is distributed under the same license as the vorbis-tools package.
# Translators: 
# Martin Quinson , 2002, 2003.
# Damien Escoffier , 2015, 2016.
#
# # Choix de traduction :
#   bitrate = débit
#   bits= bits
#   samples = échantillons
#   chanel  = canaux
#   chunk   = tronçon (comme Guillaume Allègre a mis dans la trad de png)
#   cutpoint= point de césure (utilisé pour l'outil vcut)
#   downmix = démultiplexe (c'est en fait la conversion stéréo -> mono)
#   frame aspect= format d'image
#   headers = entêtes
#   illegal = non permis
#   invalid = non valide
#   low-pass= passe-bas (terme de traitement du signal. Définition plus complète
# de granddictionnaire.com : Filtre qui laisse passer les signaux de 
# basse fréquence)
#  managed bitrate mode = mode de gestion du débit
#   parse   = analyse
#   playtime= durée d'écoute
#   raw = brut [adjectif]
#   sample rate = taux d'échantillonnage
#   streaming   = diffusion en flux (streaming)
#
# # Problématiques :
#   granulepos  = granulepos (c'est en fait le nom propre d'un index spécial dans le
# format vorbis, les développeurs m'ont déconseillé de traduire)
msgid ""
msgstr ""
"Project-Id-Version: vorbis-tools 1.4.0\n"
"Report-Msgid-Bugs-To: https://trac.xiph.org/\n;
"POT-Creation-Date: 2010-03-26 03:08-0400\n"
"PO-Revision-Date: 2016-01-24 14:09+0100\n"
"Last-Translator: Damien Escoffier \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: ogg123/buffer.c:117
#, c-format
msgid "ERROR: Out of memory in malloc_action().\n"
msgstr "Erreur : plus de mémoire dans malloc_action().\n"

#: ogg123/buffer.c:364
#, c-format
msgid "ERROR: Could not allocate memory in malloc_buffer_stats()\n"
msgstr ""
"Erreur : impossible d'allouer de la mémoire dans malloc_buffer_stats()\n"

#: ogg123/callbacks.c:76
msgid "ERROR: Device not available.\n"
msgstr "Erreur : périphérique indisponible.\n"

#: ogg123/callbacks.c:79
#, c-format
msgid "ERROR: %s requires an output filename to be specified with -f.\n"
msgstr "Erreur : %s a besoin d'un fichier de sortie à spécifier avec -f.\n"

#: ogg123/callbacks.c:82
#, c-format
msgid "ERROR: Unsupported option value to %s device.\n"
msgstr "Erreur : valeur d'option invalide pour le périphérique %s.\n"

#: ogg123/callbacks.c:86
#, c-format
msgid "ERROR: Cannot open device %s.\n"
msgstr "Erreur : impossible d'ouvrir le périphérique %s.\n"

#: ogg123/callbacks.c:90
#, c-format
msgid "ERROR: Device %s failure.\n"
msgstr "Erreur : erreur de périphérique %s.\n"

#: ogg123/callbacks.c:93
#, c-format
msgid "ERROR: An output file cannot be given for %s device.\n"
msgstr ""
"Erreur : impossible d'attribuer un fichier de sortie pour le périphérique %"
"s.\n"

#: ogg123/callbacks.c:96
#, c-format
msgid "ERROR: Cannot open file %s for writing.\n"
msgstr "Erreur : impossible d'ouvrir le fichier %s en écriture.\n"

#: ogg123/callbacks.c:100
#, c-format
msgid "ERROR: File %s already exists.\n"
msgstr "Erreur : le fichier %s existe déjà.\n"

#: ogg123/callbacks.c:103
#, c-format
msgid "ERROR: This error should never happen (%d).  Panic!\n"
msgstr "Erreur : cette erreur ne devrait jamais se produire (%d). Panique !\n"

#: ogg123/callbacks.c:128 ogg123/callbacks.c:133
msgid "ERROR: Out of memory in new_audio_reopen_arg().\n"
msgstr "Erreur : plus de mémoire dans new_audio_reopen_arg().\n"

#: ogg123/callbacks.c:179
msgid "Error: Out of memory in new_print_statistics_arg().\n"

Bug#760029: systemd: doesn't initialise RANDOM_SEED upon installation

[Michael Biebl]

Hi

Am 04.02.2016 um 09:11 schrieb Michael Biebl:
> Am 04.02.2016 um 07:42 schrieb Raphael Geissert:
>> On Feb 4, 2016 3:11 AM, "Michael Biebl"  wrote:
> 
>> Oh, it must have fallen through the cracks.
>> Anyway, the problem at hand is the lack of entropy during first boot. Think
>> about a raspberry pi for an example.
> 
> Ok, what exactly is the problem here. I mean, we shipped the current
> setup with jessie and I don't remember any entropy related bug reports.
> I installed systemd on my PI without problems.
> What exactly happens/can happen, if we don't (pre)initialize the random
> seed? Do you have any bug reports, which are still valid with modern
> Linux kernels?

So, I thought about this a bit more: Say we do the following in postinst

if [ -z "$2" ] ; then
   /lib/systemd/systemd-random-seed save
fi

This would create /var/lib/systemd/random-seed upon first installation.

What happens though, if someone uses debootstrap to create an image
which is the deployed on 100s of machines.
Those images would all ship an identical /var/lib/systemd/random-seed.
Isn't that a problem?

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#760029: systemd: doesn't initialise RANDOM_SEED upon installation

[Raphael Geissert]

Hi Michael,

On 4 February 2016 at 22:36, Michael Biebl  wrote:
> Am 04.02.2016 um 09:11 schrieb Michael Biebl:
>> Ok, what exactly is the problem here. I mean, we shipped the current
>> setup with jessie and I don't remember any entropy related bug reports.
>> I installed systemd on my PI without problems.
>> What exactly happens/can happen, if we don't (pre)initialize the random
>> seed? Do you have any bug reports, which are still valid with modern
>> Linux kernels?

"modern" linux kernels attempt to add more entropy from early boot,
using clock info and others. This might not enough, however, whenever
there is simply no clock that has been initialized at that point.

> So, I thought about this a bit more: Say we do the following in postinst
>
> if [ -z "$2" ] ; then
>/lib/systemd/systemd-random-seed save
> fi
>
> This would create /var/lib/systemd/random-seed upon first installation.

That's what I had in mind, yes.

> What happens though, if someone uses debootstrap to create an image
> which is the deployed on 100s of machines.
> Those images would all ship an identical /var/lib/systemd/random-seed.
> Isn't that a problem?

Given that systemd-random-seed writes to urandom, it only adds data to
the input pools. It does not attempt to alter the kernel's entropy
estimate, which would be done by using the RNDADDENTROPY ioctl.

Having an identical random-seed from systemd should not be any worse
than not having one, pretty much as it should not be any worse for
some random process running as "nobody" writing 0s to u/random.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Bug#813747: Annual ping for Joachim Wiedorn (DM)

[Joachim Wiedorn]

Package: debian-maintainers
Severity: normal

Here is my annual ping. 
Still have interest in maintaining my packages.

Fondest regards,
 Joachim Wiedorn


pgp8uoro2LVsB.pgp
Description: Digitale Signatur von OpenPGP

Bug#813681: apt-listbugs starts browser as root

[Francesco Poli]

On Thu, 04 Feb 2016 12:24:09 +0200 Nick T. wrote:

> Package: apt-listbugs
> Version: 0.1.17
> Severity: wishlist
> Tags: security

Hello Nick,
thanks for your bug report.

> 
> apt-listbugs when asked to display bug information in browser it starts the 
> browser as root.

Yes, it does so (when run as root).

> Needless to say this is not a good idea and in specific circumstances a 
> security issue.

I am aware of the possible security implications, but the matter is not
easy. There used to be a user-switching feature for the browser
invocation, but it had to be disabled: please see
https://bugs.debian.org/662865
for the details.

In addition to that,
https://bugs.debian.org/662983
https://bugs.debian.org/671728
may also be of interest...

> listbugs should drop the superuser privileges before doing so. My 
> recommendation is to launch the browser as 'nobody' by default and add a 
> config option to set a custom user.

Mmmmh, I have to think about this possible approach.
I'll let you know as soon as possible: please stay tuned.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpAGw_RPLEp8.pgp
Description: PGP signature

Bug#809417: Pleae don't depend on libvirt-bin

[Michael Biebl]

Am 04.02.2016 um 10:17 schrieb Michael Biebl:
> Am 04.02.2016 um 10:07 schrieb Guido Günther:
>> On Thu, Feb 04, 2016 at 09:23:38AM +0100, Michael Biebl wrote:
>>> The changes need to go to debian/control.in as well, otherwise they are
>>> removed on make clean. Please update the debdiff accordingly.
>>
>> Thanks for having a look! Updated debdiff attached. Haven't touched any
>> of Debian's GNOME packages for years, sorry for the omission.
> 
> np, thanks for the updated debdiff
> 
>> Updated debdiff attached. With this fixed can I upload a version
>> directly to unstable skipping delayed/7.
> 
> Sure, feel free to go ahead.
> 
> 

Applied your debdiff to the pkg-gnome SVN

Thanks.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#813749: mozjs24: Unsatisfiable Build-Depends and Build-Conflicts

[Daniel Schepler]

Source: mozjs24
Version: 24.2.0-3
Severity: serious

>From my pbuilder build log:

...
 -> Attempting to satisfy build-dependencies
-> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude -
created by pbuilder
This package was created automatically by pbuilder to satisfy the
build-dependencies of the package being currently built.
Depends: debhelper (>= 9), dh-autoreconf, libffi-dev, libnspr4-dev (>=
2:4.9.2), pkg-config, pkg-kde-tools, python, zip
Conflicts: python3-minimal, python3.3-minimal, python3.4-minimal
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 11893 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but
configuring anyway as you requested:
pbuilder-satisfydepends-dummy depends on debhelper (>= 9); however:
 Package debhelper is not installed.
pbuilder-satisfydepends-dummy depends on dh-autoreconf; however:
 Package dh-autoreconf is not installed.
pbuilder-satisfydepends-dummy depends on libffi-dev; however:
 Package libffi-dev is not installed.
pbuilder-satisfydepends-dummy depends on libnspr4-dev (>= 2:4.9.2); however:
 Package libnspr4-dev is not installed.
pbuilder-satisfydepends-dummy depends on pkg-config; however:
 Package pkg-config is not installed.
pbuilder-satisfydepends-dummy depends on pkg-kde-tools; however:
 Package pkg-kde-tools is not installed.
pbuilder-satisfydepends-dummy depends on python; however:
 Package python is not installed.
pbuilder-satisfydepends-dummy depends on zip; however:
 Package zip is not installed.

Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
pbuilder-satisfydepends-dummy is already installed at the requested
version (0.invalid.0)
pbuilder-satisfydepends-dummy is already installed at the requested
version (0.invalid.0)
The following NEW packages will be installed:
 autoconf{a} automake{a} autopoint{a} autotools-dev{a} bsdmainutils{a}
debhelper{a} dh-autoreconf{a} dh-python{a} dh-strip-nondeterminism{a}
file{a} gettext{a} gettext-base{a} groff-base{a} intltool-debian{a}
libarchive-zip-perl{a} libcroco3{a} libexpat1{a}
 libffi-dev{a} libffi6{a} libfile-stripnondeterminism-perl{a}
libglib2.0-0{a} libicu55{a} libmagic1{a} libmpdec2{a} libnspr4{a}
libnspr4-dev{a} libpipeline1{a} libpython-stdlib{a}
libpython2.7-minimal{a} libpython2.7-stdlib{a} libpython3-stdlib{a}
 libpython3.5-minimal{a} libpython3.5-stdlib{a} libsigsegv2{a}
libssl1.0.2{a} libtool{a} libunistring0{a} libxml2{a} m4{a} man-db{a}
mime-support{a} pkg-config{a} pkg-kde-tools{a} po-debconf{a} python{a}
python-minimal{a} python2.7{a} python2.7-minimal{a}
 python3{a} python3-minimal{a} python3.5{a} python3.5-minimal{a} zip{a}
The following packages are RECOMMENDED but will NOT be installed:
 curl libglib2.0-data libltdl-dev libmail-sendmail-perl libwww-perl
lynx-cur shared-mime-info unzip wget xdg-user-dirs xml-core
0 packages upgraded, 53 newly installed, 0 to remove and 0 not upgraded.
Need to get 23.5 MB/30.3 MB of archives. After unpacking 113 MB will be used.
The following packages have unmet dependencies:
pbuilder-satisfydepends-dummy : Conflicts: python3-minimal but 3.5.1-1
is to be installed.
Unable to resolve dependencies!  Giving up...
The following NEW packages will be installed:
 autoconf{a} automake{a} autopoint{a} autotools-dev{a} bsdmainutils{a}
debhelper{a} dh-autoreconf{a} dh-python{a} dh-strip-nondeterminism{a}
file{a} gettext{a} gettext-base{a} groff-base{a} intltool-debian{a}
libarchive-zip-perl{a} libcroco3{a} libexpat1{a}
 libffi-dev{a} libffi6{a} libfile-stripnondeterminism-perl{a}
libglib2.0-0{a} libicu55{a} libmagic1{a} libmpdec2{a} libnspr4{a}
libnspr4-dev{a} libpipeline1{a} libpython-stdlib{a}
libpython2.7-minimal{a} libpython2.7-stdlib{a} libpython3-stdlib{a}
 libpython3.5-minimal{a} libpython3.5-stdlib{a} libsigsegv2{a}
libssl1.0.2{a} libtool{a} libunistring0{a} libxml2{a} m4{a} man-db{a}
mime-support{a} pkg-config{a} pkg-kde-tools{a} po-debconf{a} python{a}
python-minimal{a} python2.7{a} python2.7-minimal{a}
 python3{a} python3-minimal{a} python3.5{a} python3.5-minimal{a} zip{a}
The following packages are RECOMMENDED but will NOT be installed:
 curl libglib2.0-data libltdl-dev libmail-sendmail-perl libwww-perl
lynx-cur shared-mime-info unzip wget xdg-user-dirs xml-core
0 packages upgraded, 53 newly installed, 0 to remove and 0 not upgraded.
Need to get 23.5 MB/30.3 MB of archives. After unpacking 113 MB will be used.
Abort.
E: pbuilder-satisfydepends failed.

The issue is that mozjs24 Build-Depends on 

Bug#813698: qemu-user-static: qemu-ppc64le-static segfaults in ppc64el chroot

[Daniel Stender]

Howto fix Sbuild: http://www.danielstender.com/blog/qemu-ppc64el-trouble.html

Cheers,
DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#796835: release.debian.org: Transition: ncurses-6.0

[Emilio Pozuelo Monfort]

On 24/08/15 20:17, Sven Joachim wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-CC: ncur...@packages.debian.org
> Control: block 230990 by -1
> 
> For quite some time, ncurses had the option to be built with a new ABI
> that enables applications to use mouse wheels, among other good things
> (see #230990).  Switching to this ABI had been stalled due to the lack
> of symbol versioning and the rather large number of ncurses' reverse
> dependencies, with quite a few libraries among them.
> 
> In the latest ncurses release (6.0), symbol versioning was added to the
> libraries, and we would like to see ncurses' reverse dependencies to be
> rebuilt during the Stretch release cycle so that the long requested ABI
> change becomes possible after the Debian 9 release.
> 
> The new ncurses version has already migrated to testing, and there is no
> hurry to rebuild reverse dependencies right away, but I would like to
> see a mass rebuild some time before the Stretch freeze and set up a
> tracker in the meantime.
> 
> Suggested ben file (only lightly tested, please check):
> 
> title = "ncurses-6.0";
> is_affected = .depends ~ /libncursesw?5|libtinfo5/;
> is_good = .depends ~ /libncursesw?5 \(>= 6|libtinfo5 \(>= 6/;
> is_bad = .depends ~ /libncursesw?5 \(>= 5|libtinfo5(,|$)|libtinfo5\(>= 5/;

This is basically done. There's just 4store missing, which FTBFS on arm64. Also
there is joe which got built against the old ncurses on i386 by the maintainer.
Unfortunately that doesn't prevent migration, so that's likely to happen again.

Cheers,
Emilio

Bug#813426: [Pkg-gmagick-im-team] Bug#813426: warning: /etc/alternatives/compare is dangling; it will be updated with best choice

[Vincent Fourmond]

control: unmerge -1
control: reassign -1 src:imagemagick

  Reassigning this bug to imagemagick. There are two problems:

  * the problem with the alternatives
  * the problem with dir to symlink

  The latter is clearly a dpkg bug (already reported), but the former
is an imagemagick bug, and should be tracked separately.

  Bastien, I'm handling the alternatives problem right now. Shall we
revert the dir-to-symlink change as of now ?

  Regards,

  Vincent

On Wed, Feb 3, 2016 at 5:19 PM, 積丹尼 Dan Jacobson  wrote:
>>> BTW, you show a very long list of warning messages, did they stop by
>>> themselves ? If yes, I'm very curious why.
>
> Oops I'm sorry I neglected to truncate them for my bug post.
>
> No I had to use ^C to stop them.

Bug#813743: pitivi: Fresh install of Pitivi failing to start with missing dependencies

[Richard Decal]

Package: pitivi
Version: 0.93-4.2
Severity: important

Dear Maintainer,

I just installed pitivi on Debian running LXDE. When I try to start it I get
this error:

 ~ pitivi
Failed to initialize modules:  No module named gi.repository
ERROR - The following hard dependencies are unmet:
==
- Clutter not found on the system
- ClutterGst not found on the system
- Gst not found on the system
- GES not found on the system
- Gtk not found on the system
- Gio not found on the system
Traceback (most recent call last):
  File "/usr/bin/pitivi", line 135, in 
_check_requirements()
  File "/usr/bin/pitivi", line 111, in _check_requirements
if not check_requirements():
  File "/usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/check.py", line 219, in
check_requirements
dependency.check()
  File "/usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/check.py", line 62, in
check
self.component = self._try_importing_component()
  File "/usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/check.py", line 144, in
_try_importing_component
from gi.repository import Gst
ImportError: No module named gi.repository


As per this closed bug (https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=743692) I tried apt-get installing gir1.2-clutter-gst-2.0
but that did not fix my problem.



-- System Information:
Debian Release: 8.3
  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/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pitivi depends on:
ii  gir1.2-clutter-1.0  1.20.0-1
ii  gir1.2-clutter-gst-2.0  2.0.12-1
ii  gir1.2-gdkpixbuf-2.02.31.1-2+deb8u4
ii  gir1.2-ges-1.0  1.2.1-1
ii  gir1.2-glib-2.0 1.42.0-2.2
ii  gir1.2-gst-plugins-base-1.0 1.4.4-2
ii  gir1.2-gstreamer-1.01.4.4-2
ii  gir1.2-gtk-3.0  3.14.5-1+deb8u1
ii  gir1.2-gtkclutter-1.0   1.6.0-1
ii  gir1.2-pango-1.01.36.8-3
ii  gnome-icon-theme3.12.0-1
ii  gstreamer1.0-gnonlin1.2.1-1
ii  gstreamer1.0-plugins-bad [gstreamer1.0-videosink]   1.4.4-2.1+b1
ii  gstreamer1.0-plugins-base   1.4.4-2
ii  gstreamer1.0-plugins-good [gstreamer1.0-videosink]  1.4.4-2
pn  gstreamer1.0-pulseaudio | gstreamer1.0-audiosink
ii  gstreamer1.0-x [gstreamer1.0-videosink] 1.4.4-2
ii  libc6   2.19-18+deb8u2
ii  libcairo2   1.14.0-2.1
ii  python  2.7.9-1
ii  python-cairo1.8.8-1+b2
ii  python-dbus 1.2.0-2+b3
ii  python-gi   3.14.0-1
ii  python-gi-cairo 3.14.0-1
ii  python-gst-1.0  1.2.1-1.1
ii  python-matplotlib   1.4.2-3.1
ii  python-numpy1:1.8.2-2
ii  python-xdg  0.25-4

pitivi recommends no packages.

Versions of packages pitivi suggests:
ii  frei0r-plugins 1.4-3
ii  gir1.2-gnomedesktop-3.03.14.1-1
ii  gir1.2-notify-0.7  0.7.6-2
ii  gstreamer1.0-libav 1.4.4-2
ii  gstreamer1.0-plugins-ugly  1.4.4-2+b1

-- no debconf information

Bug#813744: ITP: ed25519 -- Python bindings to the Ed25519 public-key signature system

[Richard Ulrich]

Package: wnpp
Owner: Richard Ulrich 
Severity: wishlist

* Package name: ed25519
  Version : 1.4
  Upstream Author : Brian Warner 
* URL : https://pypi.python.org/pypi/ed25519
* License : Expat
  Programming Lang: python
  Description : Python bindings to the Ed25519 public-key signature
system
 This offers a comfortable python interface to a C implementation of
the
 Ed25519 public-key signature system (http://ed25519.cr.yp.to/), using
the
 portable 'ref' code from the 'SUPERCOP' benchmarking suite.
 .
 This system provides high (128-bit) security, short (32-byte) keys,
short
 (64-byte) signatures, and fast (2-6ms) operation. Please see the
README for
 more details.


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

Bug#813566: Patch

[Vincent Fourmond]

On Thu, Feb 4, 2016 at 1:29 PM, Diederik de Haas  wrote:
> tags 813566 patch
> thanks
>
> Created a patch which expands the description of the package saying which
> image formats can be found in the -extra package.
> I have created the patch, made with 'git format-patch', against the
> debian/6.9.2.10+dfsg-2 branch as that was the one which was modified the
> latest. I hope that that is correct.

  Thanks, I'm slightly changing the wording.

> I have to say that the repository has a LOT of branches with names which I'd
> normally expect as tags ...

  That's the best way to work with gitpkg, which doesn't work as
git-buildpackage. In the end, it doesn't really change anything.

  Cheers,

  Vincent
>
> Regards,
>   Diederik

Bug#810025: O: ninja-build

[Felix Geyer]

Hi,

On Tue, 05 Jan 2016 12:27:53 -0600 Gary Kramlich  wrote:
> Package: wnpp
> Severity: normal
> 
> I am orphaning the ninja-build and ninja-build-doc packages, because I 
> haven't used it and no long have the time to maintain it.  The packaging is 
> available here https://bitbucket.org/rw_grim/ninja-build-debian-packaging/src
> 
> The description reads:
> 
> Description-en: small build system closest in spirit to Make
>  Ninja is yet another build system. It takes as input the interdependencies of
>  files (typically source code and output executables) and orchestrates
>  building them, quickly.

I'll adopt the package.
New packaging repo is: 
https://anonscm.debian.org/cgit/collab-maint/ninja-build.git

Cheers,
Felix



signature.asc
Description: OpenPGP digital signature

Bug#813746: ruby-hipchat: FTBFS: Real HTTP connections are disabled. Unregistered request: GET

[Chris Lamb]

Source: ruby-hipchat
Version: 1.5.2-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ruby-hipchat fails to build from source in unstable/amd64:

  [..]
  
  
RUBYLIB=/home/lamby/temp/cdt.20160204233035.u8eNtVVitE/ruby-hipchat-1.5.2/debian/ruby-hipchat/usr/lib/ruby/vendor_ruby:.
 
GEM_PATH=/home/lamby/.gem/ruby/2.2.0:/var/lib/gems/2.2.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.2.0:/usr/share/rubygems-integration/2.2.0:/usr/share/rubygems-integration/2.2:/usr/share/rubygems-integration/all:debian/ruby-hipchat/usr/share/rubygems-integration/all
 ruby2.2 -S rake -f debian/ruby-tests.rake
  /usr/bin/ruby2.2 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb
  warning: coveralls gem not found; skipping coverage
  .FF...
  
  Failures:
  
1) HipChat (API V2) #statistics is successful without custom options
   Failure/Error: expect(room.statistics()).to be_truthy
   WebMock::NetConnectNotAllowedError:
 Real HTTP connections are disabled. Unregistered request: GET 
https://api.hipchat.com/v2/room/Hipchat/statistics?auth_token=blah==_id=Hipchat=
 with headers {'Accept'=>'application/json', 'Content-Type'=>'application/json'}
 
 You can stub this request with the following snippet:
 
 stub_request(:get, 
"https://api.hipchat.com/v2/room/Hipchat/statistics?auth_token=blah==_id=Hipchat=;).
   with(:headers => {'Accept'=>'application/json', 
'Content-Type'=>'application/json'}).
   to_return(:status => 200, :body => "", :headers => {})
 
 registered request stubs:
 
 stub_request(:get, 
"https://api.hipchat.com/v2/room/Hipchat/statistics?auth_token=blah_id=Hipchat;)
 
 
   # ./lib/hipchat/room.rb:269:in `statistics'
   # ./spec/hipchat_api_v2_spec.rb:61:in `block (3 levels) in '
  
2) HipChat (API V2) #statistics is successful from fetched room
   Failure/Error: expect(subject.rooms.first.statistics).to be_truthy
   WebMock::NetConnectNotAllowedError:
 Real HTTP connections are disabled. Unregistered request: GET 
https://api.hipchat.com/v2/room/Hipchat/statistics?auth_token=blah==_id=Hipchat=
 with headers {'Accept'=>'application/json', 'Content-Type'=>'application/json'}
 
 You can stub this request with the following snippet:
 
 stub_request(:get, 
"https://api.hipchat.com/v2/room/Hipchat/statistics?auth_token=blah==_id=Hipchat=;).
   with(:headers => {'Accept'=>'application/json', 
'Content-Type'=>'application/json'}).
   to_return(:status => 200, :body => "", :headers => {})
 
 registered request stubs:
 
 stub_request(:get, 
"https://api.hipchat.com/v2/room/Hipchat/statistics?auth_token=blah_id=Hipchat;)
 stub_request(:get, "https://api.hipchat.com/v2/room?auth_token=blah;).
   with(:body => "",
:headers => {'Accept'=>'application/json', 
'Content-Type'=>'application/json'})
 
 
   # ./lib/hipchat/room.rb:269:in `statistics'
   # ./spec/hipchat_api_v2_spec.rb:69:in `block (3 levels) in '
  
  Finished in 0.17968 seconds (files took 0.60475 seconds to load)
  74 examples, 2 failures
  
  Failed examples:
  
  rspec ./spec/hipchat_api_v2_spec.rb:58 # HipChat (API V2) #statistics is 
successful without custom options
  rspec ./spec/hipchat_api_v2_spec.rb:64 # HipChat (API V2) #statistics is 
successful from fetched room
  
  /usr/bin/ruby2.2 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb failed
  ERROR: Test "ruby2.2" failed. Exiting.
  dh_auto_install: dh_ruby --install 
/home/lamby/temp/cdt.20160204233035.u8eNtVVitE/ruby-hipchat-1.5.2/debian/ruby-hipchat
 returned exit code 1
  debian/rules:15: recipe for target 'binary' failed
  make: *** [binary] Error 1

  [..]

The full build log is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


ruby-hipchat.1.5.2-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#809329: Thank you for resolving the issue

[Eran Blumenthal]

Hi,
Thank you for acknowledging and taking care of this issue.

Best Regards,
Eran

Bug#760029: systemd: doesn't initialise RANDOM_SEED upon installation

[Martin Pitt]

Hey Raphael,

Raphael Geissert [2016-02-04 23:20 +0100]:
> > What happens though, if someone uses debootstrap to create an image
> > which is the deployed on 100s of machines.
> > Those images would all ship an identical /var/lib/systemd/random-seed.

Right, and these days with live system installers and much more so
cloud images this does sound like a security trap.

> > Isn't that a problem?
> 
> Given that systemd-random-seed writes to urandom, it only adds data to
> the input pools. It does not attempt to alter the kernel's entropy
> estimate, which would be done by using the RNDADDENTROPY ioctl.
> 
> Having an identical random-seed from systemd should not be any worse
> than not having one, pretty much as it should not be any worse for
> some random process running as "nobody" writing 0s to u/random.

I'm afraid I need some more convincing about this. The point of
saving/restoring the seed on shutdown/boot is to add "good" entropy to
the RNG. I know that by adding zeros to the pool you don't actually
make the resulting numbers worse, but the point I'm really not sure
about: doesn't adding a seed also increase the pool size? I. e. my
concern is, if you inject a "bad" (because copied) seed, wouldn't that
make /dev/random block less, or not at all?

The following scenario sounds possible to me:

 - Create many cloud instances which come with the same random-seed.
 - On first start, SSH generates host keys, using /dev/random.
 - Without a seed, this would block until the system gathered enough
   entropy.
 - With a seed, this would block less/not at all as it thinks it
   already has a good RNG seed.

I'm really afraid of another instance of "Thousands of Debian
instances ship with breakable SSH host keys", we all still remember
the SSL disaster. Do you have some convincing arguments/references
that the above cannot happen?

I think a much better answer than creating it in the postinst (where
*both* the current RNG state *and* the eventual fate of that file are
totally unknown) is to create the seed in d-i in finish-install, when
the system ran long enough. Similarly, cloud-init could use pollinate
or a similar technology to snitch some entropy from the host. In
general, IMHO the right thing is to do this per machine/instance, not
per image.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#813740: ITP: semver -- Python package to work with Semantic Versioning

[Richard Ulrich]

Package: wnpp
Owner: Richard Ulrich 
Severity: wishlist

* Package name: semver
  Version : 2.3.1
  Upstream Author : Konstantine Rybnikov 
* URL : https://pypi.python.org/pypi/semver
* License : BSD
  Programming Lang: python
  Description : Python package to work with Semantic Versioning
 Simple module for comparing versions as noted at http://semver.org





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

Bug#813741: please add a check that libraries are installed in /usr/lib instead of /usr/lib/DEB_HOST_MULTIARCH

[Matthias Klose]

Package: lintian

please add a check that libraries are installed in /usr/lib instead of 
/usr/lib/DEB_HOST_MULTIARCH.


The best solution for such issues would be to make both the dev and the library 
package M-A same.   If that can not be done, make just the library package M-A 
same.  If for some reason even the library package cannot be made M-A same, then 
at least we know that the package maintainer looked at the issue, and just moved 
the libs (which shouldn't make any difference). So we gain a warning on packages 
which are not looked at for multiarch issues.

Bug#813769: perf-tools-unstable: Propose to keep up with upstream.

[Takahide Nojima]

Package: perf-tools-unstable
Version: 0.0.1~20150130+git85414b0-2
Severity: normal

Hello Maintainer,

I would be glad to keep up with upstream version of perf-tools.

Currently in debian sid, perf tools are probably ones almost 1 years before.
The perf tools of this version doesn't support USDT(use user-level statically
defined tracing), so it doesn't have enough functionarity to current version of
kernel of debian sid. I think USDT is very good kernel function, so it is
unfortunate that perf tool of debian sid can't use USDT.

Thank you in advance,
Takahide Nojima







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

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

Versions of packages perf-tools-unstable depends on:
ii  linux-perf  4.3+70

perf-tools-unstable recommends no packages.

perf-tools-unstable suggests no packages.

-- no debconf information

Bug#751570:

[Dylan]

OpenBUGS cannot integrate Debian because its core (i.e.
libOpenBUGS.so) is written in BlackBox Component Pascal which is
impossible to compile on Linux for the moment.

Bug#811802: povray: FTBFS with GCC 6: multiple errors

[Ralf Corsépius]

On Fri, 22 Jan 2016 12:18:06 -0800 Martin Michlmayr  wrote:

* Andreas Beckmann  [2016-01-21 03:06]:
> I haven't looked into this, yet, but the most prominent change seems to
> be the default switch to -std=c++14. Have you tried rebuilding the
> failing packages with g++-6 -std=c++11/c++03/c++98/.../gnuXX (not sure
> whether the old ones are correctly spelled) to see if that succeeds
> somewhere? If additionally information is given like "But it builds
> successfully with g++6 -std=c++11" or "And it also fails with g++-6
> -std=c++AA/BB/CC/gnuXX/YY/ZZ" that should narrow the place where to
> start looking for this problem.

Sorry, I haven't done that.  I filed over 500 bugs so I cannot look at
every package in detail.  I could do it for yours but it sounds like
you have a pbuilder with g++-6 ready already (or ready soon) :)


FYI: GCC-6 with -std=c++03 seems to work on Fedora. -std=c++11 doesn't.

Ralf

Bug#813770: gitlab_url for gitlab-shell is set incorrectly only GITLAB_HOST is set and host is not set in gitlab.yml

[Pirate Praveen]

package: gitlab
severity: grave
version: 8.4.0+dfsg-2

though a simple fix exist, it makes the default installation unusable.
If you change gitlab_url in /usr/share/gitlab-shell/config.yml, things
start working.



signature.asc
Description: OpenPGP digital signature

Bug#813771: reportbug: It can't unselect item in 'Do any of the following apply to this report' page.

[Takahide Nojima]

Package: reportbug
Version: 6.6.6
Severity: normal

Hello maintainer,

 In using gui of reportbug, The page of 'Do any of the following apply to this
report' lacks functionarity that all item set to unselecting. If you would
select a item mistakenly, all item can't set to unselecting.

 I would appreciate if it would be fixed.

Thank you in advance,
Takahide Nojima



-- Package-specific info:
** Environment settings:
INTERFACE="gtk2"

** /home/nojima/.reportbugrc:
reportbug_version "6.6.6"
mode advanced
ui gtk2
realname "Takahide Nojima"
smtphost "smtp.gmail.com:587"
smtpuser "nozzy123no...@gmail.com"
smtptls

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

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

Versions of packages reportbug depends on:
ii  apt   1.2.1
ii  python-reportbug  6.6.6
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
ii  emacs24-bin-common 24.5+1-6+b1
ii  exim4  4.86-7
ii  exim4-daemon-light [mail-transport-agent]  4.86-7+b2
ii  file   1:5.25-2
ii  gnupg  1.4.20-1
ii  python-gtk22.24.0-4
pn  python-gtkspellcheck   
pn  python-urwid   
ii  python-vte 1:0.28.2-5+b1
ii  xdg-utils  1.1.1-1

Versions of packages python-reportbug depends on:
ii  apt   1.2.1
ii  file  1:5.25-2
ii  python-debian 0.1.27
ii  python-debianbts  2.6.0
pn  python:any

python-reportbug suggests no packages.

-- no debconf information

Bug#813374: general: Menus and window popup does not work after recent upgrade

[Thomas Goirand]

On 02/04/2016 05:35 AM, Vincent Danjean wrote:
> Le 03/02/2016 12:31, Thomas Goirand a écrit :
>> Vincent,
>>
>> This sounds like issues with your window manager, since you mostly
>> complain about issues with window placements and dispositions. Just to
>> be sure, you're using XFCE, right?
> 
> Yes.
> But is the WM involved in (the placement of) application menus ?
> If yes, xfce seems indeed a good target.
> 
>   Regards,
> Vincent

In X-Window, menus (once you click on a title of it) are also windows
who open, so it's well possible that it is the case that XFCE is
involved, yes. It well could be a GTK issue too, which is why you should
try to use the fault applications with another window manager and see
what happens.

I hope this helps,
Cheers,

Thomas Goirand (zigo)

Bug#813761: dh-linktree: Typo in package description: "unconditionnaly"

[Olly Betts]

Package: dh-linktree
Version: 0.4
Severity: minor

"unconditionnaly" in long description should be "unconditionally".

Cheers,
Olly


signature.asc
Description: PGP signature

Bug#813768: fbreader: installation does not create a launch menu entry

[john]

Package: fbreader
Version: 0.12.10dfsg-10
Severity: minor

Dear Maintainer,
on my system it seems like the installation of the fbreader package does not
create a application launch menu entry for FBReader.

I get this behaviour with version 0.12.10dfsg-10 of the fbreader package on
a 32 bit Debian testing with a minimal LXDE desktop.

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

Kernel: Linux 4.3.0-1-686-pae (SMP w/2 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)

Versions of packages fbreader depends on:
ii  libc6  2.21-7
ii  libgcc11:5.3.1-7
ii  libsqlite3-0   3.10.2-1
ii  libstdc++6 5.3.1-7
ii  libzlcore0.13  0.12.10dfsg-10
ii  libzltext0.13  0.12.10dfsg-10
ii  libzlui-qt40.12.10dfsg-10

fbreader recommends no packages.

fbreader suggests no packages.

-- no debconf information

Bug#813566: imagemagick-6.q16: missing package dependency to librsvg2-bin

[Vincent Fourmond]

control: tag -1 pending

  Dear Takahide,

On Fri, Feb 5, 2016 at 7:08 AM, Takahide Nojima  wrote:
>>  We cannot have the libmagickcore-6.q16-2-extra package installed by
>> default, the best we could do is to clarify for what the -extra
>> package is needed in the package description.
>
> I agree with that. I would be glad if the package descripiton say some
> hint of -extra package.

  Yep, the fix has been comitted to the git repository, but it will be
along while before it even hits unstable.

  Cheers,

  Vincent

>
> Takahide Nojima
>
>

Bug#813772: ITP: openssl-ibmca -- libica based hardware acceleration engine for OpenSSL

[Dimitri John Ledkov]

Package: wnpp
Owner: Dimitri John Ledkov 
Severity: wishlist

* Package name: openssl-ibmca
  Version : 1.3.0
  Upstream Author : openCryptoki Project 
* URL or Web page : 
http://sourceforge.net/projects/opencryptoki/files/libica%20OpenSSL%20Engine/
* License : OpenSSL-like BSD-4-Clause-like
  Description : libica based hardware acceleration engine for OpenSSL

This package provides an OpenSSL engine to enable hardware acceleration
of cryptographic functions in OpenSSL, and all applications that use
OpenSSL.

This package is specific for s390x architecture.

Regards,

Dimitri.

Bug#813721: transition: libsodium

[GCS]

On Thu, Feb 4, 2016 at 6:55 PM, Emilio Pozuelo Monfort  wrote:
> On 04/02/16 18:48, László Böszörményi (GCS) wrote:
>> A small transition of libsodium. It has soname 13 in Sid and 18 in 
>> experimental.
>
> Go ahead.
 It was strage as -2 was compiled on all architectures in
experimental, but a no change -3 failed on non-x32/x64 ones. This is
now fixed and libsodium built on all architectures in Sid. The binNMUs
may start.

Thanks,
Laszlo/GCS

Bug#813599: systemd - systemd-random-seed.service fails to start in clean install

[Bastian Blank]

On Thu, Feb 04, 2016 at 10:38:35PM +0100, Michael Biebl wrote:
> > So it ignores the error given by the first call (EROFS), which would be
> > a clear indication, and only provides the useless second one.
> True, it should probably log the error message. Will forward this issue
> upstream.

The utmp writer and tmpfiles creation have similar problems.  I did not
look at the code yet, but they fail without indication what is going on.

Bastian

-- 
In the strict scientific sense we all feed on death -- even vegetarians.
-- Spock, "Wolf in the Fold", stardate 3615.4

Bug#813773: RM: sibyl -- ROM; kernel removed

[Martin Michlmayr]

Package: ftp.debian.org

Please remove sibyl: this is a boot loader for SB1 Broadcom devices
which are no longer supported in Debian.  The kernel was removed in
August 2015.

I confirmed with the maintainer that he's ok with the removal:

12:05  no. I don't think anyone is still using that..

Kernel removal was done in 4.2~rc8-1~exp1 (24 Aug 2015):

  * [mips,mips64] Remove r4k-ip22, r5k-ip32 and sb1-bcm91250a flavours.
  * [mipsel,mips64el] Remove sb1-bcm91250a flavour.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#813774: RM: sibyl-installer -- ROM; kernel removed

[Martin Michlmayr]

Package: ftp.debian.org

Please remove sibyl-installer: this is a d-i udeb for the boot boot
loader for SB1 Broadcom devices which are no longer supported in
Debian.  The kernel was removed in August 2015.

I confirmed with the maintainer that he's ok with the removal:

12:05  no. I don't think anyone is still using that..

Kernel removal was done in 4.2~rc8-1~exp1 (24 Aug 2015):

  * [mips,mips64] Remove r4k-ip22, r5k-ip32 and sb1-bcm91250a flavours.
  * [mipsel,mips64el] Remove sb1-bcm91250a flavour.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#813760: ebtables: Lock file should probably be moved from /var/lib/ebtables to /run

[Laurent Bigonville]

tag 813760 + patch
thanks

On Fri, 05 Feb 2016 02:40:43 +0100 Laurent Bigonville  
wrote:

> Hi,
>
> ATM, everytime ebtables is run, a lock file is created in
> /var/lib/ebtables/.

Fedora apply the attached patch
diff -up ebtables-v2.0.10-4/ebtables.8.lockdirfix ebtables-v2.0.10-4/ebtables.8
--- ebtables-v2.0.10-4/ebtables.8.lockdirfix	2016-01-18 11:13:21.707069702 -0500
+++ ebtables-v2.0.10-4/ebtables.8	2016-01-18 11:13:40.554953365 -0500
@@ -1103,7 +1103,7 @@ arp message and the hardware address len
 .br
 .SH FILES
 .I /etc/ethertypes
-.I /var/lib/ebtables/lock
+.I /run/ebtables.lock
 .SH ENVIRONMENT VARIABLES
 .I EBTABLES_ATOMIC_FILE
 .SH MAILINGLISTS
diff -up ebtables-v2.0.10-4/INSTALL.lockdirfix ebtables-v2.0.10-4/INSTALL
--- ebtables-v2.0.10-4/INSTALL.lockdirfix	2016-01-18 11:15:31.458268826 -0500
+++ ebtables-v2.0.10-4/INSTALL	2016-01-18 11:15:53.890130367 -0500
@@ -31,7 +31,7 @@ WHAT GETS INSTALLED AND WHAT OPTIONS ARE
   copied to /etc/rc.d/init.d (change with option INITDIR)
 - The ebtables configuration file (ebtables-config) is copied to /etc/sysconfig
 - ebtables can use a lock file to enable concurrent execution of the ebtables
-  tool. The standard location of the lock file is /var/lib/ebtables/lock.
+  tool. The standard location of the lock file is /run/ebtables.lock.
   Include LOCKFILE=<> if you want to use another file.
 
 That's all
diff -up ebtables-v2.0.10-4/libebtc.c.lockdirfix ebtables-v2.0.10-4/libebtc.c
--- ebtables-v2.0.10-4/libebtc.c.lockdirfix	2016-01-18 11:12:14.347485472 -0500
+++ ebtables-v2.0.10-4/libebtc.c	2016-01-18 11:13:06.515163472 -0500
@@ -134,8 +134,8 @@ void ebt_list_extensions()
 }
 
 #ifndef LOCKFILE
-#define LOCKDIR "/var/lib/ebtables"
-#define LOCKFILE LOCKDIR"/lock"
+#define LOCKDIR "/run"
+#define LOCKFILE LOCKDIR"/ebtables.lock"
 #endif
 static int lockfd = -1, locked;
 int use_lockfd;
diff -up ebtables-v2.0.10-4/Makefile.lockdirfix ebtables-v2.0.10-4/Makefile
--- ebtables-v2.0.10-4/Makefile.lockdirfix	2016-01-18 11:14:10.715767201 -0500
+++ ebtables-v2.0.10-4/Makefile	2016-01-18 11:15:20.506336425 -0500
@@ -5,7 +5,7 @@ PROGRELEASE:=4
 PROGVERSION_:=2.0.10
 PROGVERSION:=$(PROGVERSION_)-$(PROGRELEASE)
 PROGDATE:=December\ 2011
-LOCKFILE?=/var/lib/ebtables/lock
+LOCKFILE?=/run/ebtables.lock
 LOCKDIR:=$(shell echo $(LOCKFILE) | sed 's/\(.*\)\/.*/\1/')/
 
 # default paths

Bug#813743: pitivi: Fresh install of Pitivi failing to start with missing dependencies

[Sebastian Dröge]

On Do, 2016-02-04 at 13:13 -0800, Richard Decal wrote:
> Package: pitivi
> Version: 0.93-4.2
> Severity: important
> 
> Dear Maintainer,
> 
> I just installed pitivi on Debian running LXDE. When I try to start
> it I get
> this error:
> 
>  ~ pitivi
> Failed to initialize modules:  No module named gi.repository
> [...]
> Versions of packages pitivi depends on:
> ii  python-gi   3.14.0-1

This is a weird problem. Can you import gi.repository in a Python REPL
just fine, but it fails for pitivi?
Probably a problem with that package.

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

Bug#813752: ebtables: Please do not remove ebtables-restore/save

[Laurent Bigonville]

Package: ebtables
Version: 2.0.10.4-3
Severity: normal

Hello,

Are there any reasons you are removing ebtables-restore and
ebtables-save during the build process?

Otherwise, please readd them, firewalld 0.4.0 needs them

Cheers,

Laurent Bigonville

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

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

Versions of packages ebtables depends on:
ii  libc6  2.21-7

Versions of packages ebtables recommends:
ii  iptables  1.6.0-2
ii  kmod  22-1

ebtables suggests no packages.

-- no debconf information