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

[Vincent Danjean]

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

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

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

> Thanks,
> Logan
> 

  Regards,
Vincent

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

Bug#803720: sitesummary-client: Nagios plugin check_kernel_status fail with kernels "-ckt"

[Petter Reinholdtsen]

[Daniele Palumbo]
> The Nagios module to check kernel version number of running and
> installed kernels do not work with Canonical Kernel Team kernels.
> According to
> https://lists.debian.org/debian-kernel/2014/11/msg00154.html this must
> be done properly.

Thank you.

Note, the nagios-plugins-contrib package also contain a nagios module to
check kernel version, and we plan to move to this set of modules by
default, so you might want to look into that module too.

I'll add the patch to sitesummary now. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#820587: Barco contact

[Petter Reinholdtsen]

Control: owner -1
Control: retitle -1 RFP: clickshare -- Linux driver for ClickShare screen share 
system

Until it become legal for Debian to distribute the binary drivers, I change
the status of this request from ITP to RFP and drop myself as owner.

-- 
Happy hacking
Petter Reinholdtsen

Bug#776083: Request to take ownership

[Jonathon Love]

hi frederico,

i have packaged this package, and it is presently on alioth at:

/git/python-modules/packages/python-nanomsg.git

would you be happy for me to take over this ITP, and have the package 
submitted?


with thanks

jonathon

Bug#811779: fs-uae: FTBFS with GCC 6: narrowing conversion

[John Paul Adrian Glaubitz]

Control: tags -1 pending

Hi!

On 01/20/2016 02:59 AM, Martin Michlmayr wrote:
>> src/expansion.cpp:2537:1: error: narrowing conversion of '2148532225u' from 
>> 'unsigned int' to 'int' inside { } [-Wnarrowing]
>> (...)
>> src/expansion.cpp:2537:1: error: narrowing conversion of '2148532253u' from 
>> 'unsigned int' to 'int' inside { } [-Wnarrowing]
>> src/expansion.cpp:2537:1: warning: converting to non-pointer type 'int' from 
>> NULL [-Wconversion-null]
>> src/expansion.cpp:2537:1: warning: converting to non-pointer type 'int' from 
>> NULL [-Wconversion-null]
>> src/expansion.cpp:2537:1: error: narrowing conversion of '2148532233u' from 
>> 'unsigned int' to 'int' inside { } [-Wnarrowing]
>> src/expansion.cpp:2859:1: warning: converting to non-pointer type 'int' from 
>> NULL [-Wconversion-null]
>>  };
>>  ^
>>
>> Makefile:4156: recipe for target 'src/expansion.o' failed
>> make[3]: *** [src/expansion.o] Error 1

I have now looked into this and to fix it, it's enough to declare some
int variables found in 'struct expansionromtype' src/include/autoconf.h
and 'struct romdata' in src/include/rommgr.h as 'uae_u32'. I will
follow up with a patch and an updated package later though, my patch
needs to be cleaned up first.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#821907: RFS: fbless/0.2.3-1 ITP

[Mattia Rizzolo]

On Mon, May 16, 2016 at 11:37:46AM +0500, Andrey Rahmatullin wrote:
> Please build this in a clean sid chroot.
> 
> dpkg-query: no path found matching pattern /usr/share/hyphen/hyph_es_ANY.dic

FTR, that's our "fault", we renamed that file in the last upload to
es_ES.
That said I knew there were no rdeps of it, but of course I'd pay much
more attention when doing so if packages start build-depending on it.

Also, pretty confident 'hyph_es_ES.dic' is not going anywhere anytime
soon now, that's a quite relevant lang/country ;)


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#823322: please build "systemd-sysusers" binary

[Jean Baptiste Favre]

Le 15/05/2016 à 14:01, Michael Biebl a écrit :
> Can you clarify a bit more, why exactly rkt needs systemd-sysusers? 
Hello,
According to rkt developpers [1]:

rkt takes the systemd-sysusers binary from the host and put it in rkt's
stage1. It does not run it directly on the host. So if the Debian
systemd package was providing the systemd-sysusers binary without
enabling it (e.g. without packaging
/usr/lib/systemd/system/systemd-sysusers.service or
/usr/lib/sysusers.d/*), that would work for rkt.

I don't exactly know why they pick up binary from host instead of
providing it themselves, but, here we are.

Regards,
Jean Baptiste

[1]: https://github.com/coreos/rkt/issues/2571#issuecomment-216518273



signature.asc
Description: OpenPGP digital signature

Bug#824087: [Build-common-hackers] Bug#824087: strange output after update to 0.4.131

[Jonas Smedegaard]

Hi Michael,

Quoting Michael Biebl (2016-05-12 08:50:02)
> After the update to 0.4.131, I'm seeing weird output from cdbs when 
> building (GNOME) packages. Notice the odd line breaks and "\":

Thanks for reporting!

This is caused by a recent tidying to wrap most code at 72 chars in 
source.  Code written in the make language generally convert escaped 
newlines to spaces, but code written in shell (i.e. build rules) 
preserve newlines.

It should only be cosmetic, but should be corrected anyway.  I am 
currently going through the code and tidying its output (and doing a 
slew of smaller improvements on the way).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#811779: fs-uae: FTBFS with GCC 6: narrowing conversion

[Andrea Musuruane]

Hi!
I opened a bug report upstream about this issue:
https://github.com/FrodeSolheim/fs-uae/issues/108

A patch is already available.

BR,

Andrea

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

[John Paul Adrian Glaubitz]

Source: firefox
Version: 46.0.1-1
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

I have had a look at the firefox package on sparc64 and I was able to detect
two problems with platform definitions which prevent an almost successful
build on this architecture.

Firstly, the embedded version of protobuf contains the same bug that we
have already fixed in the protobuf package in Debian which is basically
a missing #ifdef for 'sparc64' [1]:

--- 
firefox-46.0.1.orig/toolkit/components/protobuf/src/google/protobuf/stubs/platform_macros.h
+++ 
firefox-46.0.1/toolkit/components/protobuf/src/google/protobuf/stubs/platform_macros.h
@@ -67,7 +67,7 @@
 #define GOOGLE_PROTOBUF_ARCH_32_BIT 1
 #elif defined(sparc)
 #define GOOGLE_PROTOBUF_ARCH_SPARC 1
-#ifdef SOLARIS_64BIT_ENABLED
+#if defined(SOLARIS_64BIT_ENABLED) || defined(__LP64__)
 #define GOOGLE_PROTOBUF_ARCH_64_BIT 1
 #else
 #define GOOGLE_PROTOBUF_ARCH_32_BIT 1

Note: This cannot be fixed by checking for '__sparc64__' as the compiler
does not generate this definition on sparc64:

root@landau:~# dpkg --print-architecture
sparc64
root@landau:~# echo | gcc -E -dM - |grep sparc64
root@landau:~#

Instead, we need to check for both __sparc__ and __arch64__:

root@landau:~# echo | gcc -E -dM - |grep __sparc__
#define __sparc__ 1
root@landau:~# echo | gcc -E -dM - |grep __arch64__
#define __arch64__ 1
root@landau:~#

Which will bring us also directly to the second problem which prevents
building of firefox on sparc64. It's actually the incorrect checking
for __sparc64__ in ipc/chromium which can be trivially fixed with:

--- firefox-46.0.1.orig/ipc/chromium/src/build/build_config.h
+++ firefox-46.0.1/ipc/chromium/src/build/build_config.h
@@ -81,7 +81,7 @@
 #elif defined(__ppc__) || defined(__powerpc__)
 #define ARCH_CPU_PPC 1
 #define ARCH_CPU_32_BITS 1
-#elif defined(__sparc64__)
+#elif defined(__sparc__) && defined(__arch64__)
 #define ARCH_CPU_SPARC 1
 #define ARCH_CPU_64_BITS 1
 #elif defined(__sparc__)

After applying both patches, the build *almost* finishes on sparc64,
in fact, it fails at dh_auto_install with [2]:

Executing /<>/build-browser/dist/bin/xpcshell -g 
/<>/build-browser/dist/bin/ -a 
/<>/build-browser/dist/bin/ -f 
/<>/toolkit/mozapps/installer/precompile_cache.js -e 
precompile_startupcache("resource://gre/");
Traceback (most recent call last):
  File "/<>/toolkit/mozapps/installer/packager.py", line 410, in 

main()
  File "/<>/toolkit/mozapps/installer/packager.py", line 404, in 
main
args.source, gre_path, base)
  File "/<>/toolkit/mozapps/installer/packager.py", line 161, in 
precompile_cache
errors.fatal('Error while running startup cache precompilation')
  File "/<>/python/mozbuild/mozpack/errors.py", line 103, in fatal
self._handle(self.FATAL, msg)
  File "/<>/python/mozbuild/mozpack/errors.py", line 98, in _handle
raise ErrorMessage(msg)
mozpack.errors.ErrorMessage: Error: Error while running startup cache 
precompilation

which seems to be the exact same problem which also prevents the build on hppa 
[3].

It would be great if the two above changes could be merged into the firefox 
package
in Debian plus someone should also forward this bug report upstream. Then we 
just
need to figure out what's wrong with the startup cache precompiliation and might
be able to fix firefox on both hppa and sparc64.

Cheers,
Adrian

> [1] 
> https://anonscm.debian.org/cgit/pkg-protobuf/pkg-protobuf.git/tree/debian/patches/02-fix-sparc64-builds.patch
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=firefox&arch=sparc64&ver=46.0.1-1&stamp=1463370916
> [3] 
> https://buildd.debian.org/status/fetch.php?pkg=firefox&arch=hppa&ver=46.0.1-1&stamp=1462743802

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#810919: libsane: libusb_bulk_write returns "Resource temporarily unavailable"

[Jörg Frings-Fürst]

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

Bug#811779: fs-uae: FTBFS with GCC 6: narrowing conversion

[John Paul Adrian Glaubitz]

Hi Andrea!

On 05/16/2016 10:10 AM, Andrea Musuruane wrote:
> I opened a bug report upstream about this issue:
> https://github.com/FrodeSolheim/fs-uae/issues/108

Great, I'll have a look later and merge it unless upstream makes
a point release with the fix which I could then just import
to Debian.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#823126: unable to cross build libgnatprj on i386 targeting 64bit archs

[Matthias Klose]

On 14.05.2016 08:43, YunQiang Su wrote:

It seems this problem has been solved?


no, all these cross compilers are just disabled.

Bug#821907: RFS: fbless/0.2.3-1 ITP

[Dmitry Bogatov]

> > > Please rename README to README.ru, preferably upstream.
> >=20
> > dh_install'ed
> >=20
> > > Please consider using hyphenation data from hyphen-* packages.
> >=20
> > dh_linktree'ed
> >=20
> > Please, review once more.
> Please build this in a clean sid chroot.
>
> dpkg-query: no path found matching pattern /usr/share/hyphen/hyph_es_ANY.dic
> dh_linktree: error: dpkg --search -- /usr/share/hyphen/hyph_de_DE.dic /usr/=
> share/hyphen/hyph_en_US.dic /usr/share/hyphen/hyph_es_ANY.dic /usr/share/hy=
> phen/hyph_fr.dic /usr/share/hyphen/hyph_it_IT.dic /usr/share/hyphen/hyph_ru=
> _RU.dic /usr/share/hyphen/hyph_uk_UA.dic gave error exit status 1

Fixed and rebuilt. New version is on mentors.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#800581: goldendict: CPU usage is more than expected

[Evgeny Kapun]

From the official bug tracker [1], I found that such behavior can be caused by 
full-text search indexing. And what? As soon as I went to settings and disabled 
full-text search, CPU usage dropped to zero. Moreover, while dictionaries are 
being indexed for full-text search, there is a label at the bottom of the main 
window telling this. So, I think that this report should be closed.

[1] https://github.com/goldendict/goldendict/issues/640

Bug#808940: Terraform WAS: Packer as Debian package

[Geert Stappers]

On Wed, May 04, 2016 at 02:05:05PM -0400, Tim Sattarov wrote:
> On 04/05/16 01:24 PM, Daniel Stender wrote:
> > Hi,
> >
> > wanted to drop the note that Packer is now available as Debian package:
> > https://packages.debian.org/unstable/packer
> Just recently discovered that. Thanks !
> How hard will it be to do the same with terraform ?
> I can help !

[0][1][2]

* Visit https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808940 which is the 
ITP of Terraform.
* Package one of its dependencies.


Groeten
Geert Stappers

Footnotes:
[0] Thanks for telling about https://www.terraform.io/  Infrastructure as code
Terraform provides a common configuration to launch infrastructure - from
physical and virtual servers to email and DNS providers
[1] The next two lines might be harsh. So be it.
[2] The offering of help is seen. Don't expect getting tasks assigned. Find 
tasks
that you can do. Report actual progress. When stuck, follow the guidelines
described in http://catb.org/~esr/faqs/smart-questions.html


signature.asc
Description: Digital signature

Bug#824426: FTBFS against libical2

[Andreas Henriksson]

Hello!

Some information below which might be useful

On Sun, May 15, 2016 at 09:37:24PM +0200, Michael Biebl wrote:
> Source: syncevolution
> Version: 1.4.99.4-5
> Severity: serious
> 
> Hi,
> 
> during the libical transition [1], your package syncevolution was
> rebuilt and it now FTBFS:
[...]
> src/syncevo/.libs/libsyncevolution.so: undefined reference to
> `ical_tzid_prefix'
[...]

I've quickly looked into this issue since it was discovered
(sorry I missed spotting it before the transition started).

The global variable referenced above is indeed gone (in general
libical seems to be moving away from global variables in 2.0.0
in favour of accessor methods). The new accessor function to
get the value is called icaltimezone_tzid_prefix(). See:
http://sources.debian.net/src/libical/2.0.0-0.4/src/libical/icaltimezone.c/?hl=150#L150

I looked upstream but there seemed to be very little activity in recent time.
Possibly there's some bug tracker or mailing list post somewhere, but I
didn't search that far.

The libical2 transition has already been done in fedora so for comparison
they're patching their syncevolution, see:
http://pkgs.fedoraproject.org/cgit/rpms/syncevolution.git/tree/syncevolution-1.5.1-libical2.patch

IMNSHO the fedora patch is an ugly hack since duplicating the information
instead of using accessor method isn't nice IMO. OTOH I've looked at
syncevolutions usage of the global variable and if we're going to replace
it we see it in two places. The one failing the build above + in the
syncevolution homebrew/duplicated evolution(-data-server?) API.
That one looks too scary to touch for me who has no way to test this
so I sympathize with fedoras patch and maybe it's better to go that
route. Also, the get accessor seems to be missing from the libical2.symbols
for some reason so might need fixes on the libical side to be properly
exported

Regards,
Andreas Henriksson

Bug#824450: scanbd does not find scanner

[Chris Laif]

Package: scanbd
Version: 1.4.0-2
Severity: important

I've got a Canon scanner, which perfectly worked with Squeeze's
scanbuttond. After upgrading to Jessie (fresh install, all packages up
to date) the scanner is not recognized by scanbd.

As root, everything works as expected (scanbd.conf unchanged from
dist, only loglevel=7):

lsusb|grep Cano:
Bus 007 Device 025: ID 04a9:220e Canon, Inc. CanoScan N1240U/LiDE 30

# scanimage -L
device `plustek:libusb:007:025' is a Canon CanoScan N1240U/LiDE30
flatbed scanner

# scanbd -f
scanbd: debug on: level: 7
scanbd: dropping privs to uid saned
scanbd: dropping privs to gid scanner
scanbd: group scanner has member:
scanbd: saned
scanbd: drop privileges to gid: 113
scanbd: Running as effective gid 113
scanbd: drop privileges to uid: 109
scanbd: Running as effective uid 109
scanbd: dbus_init
scanbd: dbus match type='signal',interface='org.freedesktop.Hal.Manager'
scanbd: sane version 1.0
scanbd: Scanning for local-only devices
scanbd: found device: plustek:libusb:007:025 Canon CanoScan
N1240U/LiDE30 flatbed scanner
scanbd: start_sane_threads
scanbd: Starting poll thread for plustek:libusb:007:025
scanbd: Thread started for device plustek:libusb:007:025
scanbd: sane_poll
scanbd: start dbus thread
[...]

When started with systemd, the scanner is NOT detected:

May 16 10:53:54 scanbd: /usr/sbin/scanbd: sane version 1.0
May 16 10:53:54 scanbd: /usr/sbin/scanbd: Scanning for local-only devices
May 16 10:53:54 scanbd: /usr/sbin/scanbd: start_sane_threads
May 16 10:53:54 scanbd: /usr/sbin/scanbd: start dbus thread
(notice the missing "found device" line)

scanbd keeps on logging these lines:
May 16 11:01:08 scanbd[3485]: /usr/sbin/scanbd: Iteration on dbus call
May 16 11:01:08 scanbd[3485]: /usr/sbin/scanbd: Iteration on dbus call
May 16 11:01:08 scanbd[3485]: /usr/sbin/scanbd: Iteration on dbus call
May 16 11:01:08 scanbd[3485]: /usr/sbin/scanbd: Iteration on dbus call

This already has been posted to debian-users, too
(https://lists.debian.org/debian-user/2015/03/msg00907.html)

Chris

Bug#824420: python-phply: Building with DEB_BUILD_OPTIONS="nocheck" causes parsetab.py not to be included

[Gianfranco Costamagna]

control: severity -1 important

Hi Cara,



>
>While checking this package with the reproducible builds[1] tool
>chain, I noticed that building the package with
>DEB_BUILD_OPTIONS="nocheck" set causes the file parsetab.py not to be
>included in the final .deb, because the tests are what cause
>parsetab.py to be generated.  Another PLY-based package,
>pycparser, has a specific file _build_tables.py[2] that's called by
>setup.py and by the debian version's rules[3] to build the parse
>tables during installation, so a similar solution would probably work
>for python-phply.


thanks a lot for the nice and useful bug report!

can you please share a patch for this issue?
I think I can grab a file, but I'm not sure I have your knowledge in doing that,
and I'm failing to apply the patch on python-phply.
e.g. there is some .py files and .cfg that aren't available here, and I'm still 
not
sure the issue is completely on phply and not on the ply dependency or 
somewhere else.

Furthermore such changes should be acked by upstream, I don't want to diverge 
from them
with new files such as a custom generator.

What do you think?

thanks a lot!

Gianfranco

Bug#682980: Delivery notification..(View the attachment for confirmation of your delivery address)

[FedEx Courier Service]

FedEx-Delivery Post (USA).docx
Description: MS-Word 2007 document

Bug#797074: libical2 transition now ready to start!

[Andreas Henriksson]

Hello release team!

On Tue, May 10, 2016 at 01:44:36PM +0200, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 06/05/16 09:44, Andreas Henriksson wrote:
> > Control: tags -1 =
> > 
> > The libical testsuite/FTBFS bugs should now be fixed in experimental
[...]
> Go ahead.

A quick followup from me to summarize where I think we are now:

The new libical was uploaded and Emilio triggered binNMU for the packages
which was suitable for that. They've now all built on all architectures.
Some sourceful uploads where done despite the ongoing transition, for
example gnome-todo, gnome-calendar. Also the required sourceful uploads
of citadel and webcit just happened. All of these might be useful to age.
The remaining problematic packages which should be possible to handle
via temporary removal from testing are syncevolution (#824426) and
ical2html (#822565).

If I've not made any mistakes as far as I see it you should now with
some force be able to push things into testing and finalize the
transition.

Regards,
Andreas Henriksson

Bug#823893: libarchive: CVE-2016-1541

[Simon McVittie]

Control: tags 823893 + pending
Control: tags 823984 + pending

On Tue, 10 May 2016 at 09:18:26 +0200, Andreas Henriksson wrote:
> I'm torn on uploading 3.2.0 to unstable now because of regressing on
> kfreebsd where we now have test failures because of FTBFS. Feel free to
> NMU to unstable as well if you think it's urgent to get it fixed and
> don't want to wait for giving kfreebsd porters time to look at the
> regression.

I think it would have been better to upload *something* with the security
fix immediately, if not 3.2.0 then a patched 3.1.2; either way, if it
had been high or medium urgency and had no new RC bugs, then testing
would not be vulnerable by now.

libarchive/stable is uninstallable in unstable due to the libnettle
transition, so to keep this moving, I've prepared an NMU which I have
uploaded to DELAYED/5. Diff attached, or available here:
ssh://alioth.debian.org/srv/home/users/smcv/public_git/libarchive.git

If you would like it accelerated or cancelled, please let me know; or
if you decide to go ahead with 3.2.0 or a 3.1.2-12 maintainer upload
in unstable so that my NMU is superseded and rejected, that's also fine
of course.

I'll open a separate bug for the test failure. Since you are the
libarchive maintainer, you get to decide whether you consider failures on
the non-release kFreeBSD architectures to be RC. Because the kFreeBSD
architectures aren't release architectures, I believe out-of-date
binaries on those architectures don't slow down testing migration,
so fixing the security vulnerability on Linux doesn't need to block on
fixing the tests on kFreeBSD.

S
>From 8be0f04dc6f9e8955e99346f234d1188b43ecf9b Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 16 May 2016 09:46:56 +0100
Subject: [PATCH] Make libarchive/unstable catch up with libarchive/stable
 (Closes: #823984)

* CVE-2016-1541: heap-based buffer overflow due to improper input
  validation (Closes: #823893)
---
 debian/changelog   | 12 
 .../Issue-656-Fix-CVE-2016-1541-VU-862384.patch| 65 ++
 debian/patches/series  |  1 +
 3 files changed, 78 insertions(+)
 create mode 100644 debian/patches/Issue-656-Fix-CVE-2016-1541-VU-862384.patch

diff --git a/debian/changelog b/debian/changelog
index 2f53cae..a982094 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+libarchive (3.1.2-11.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+- Make libarchive/unstable catch up with libarchive/stable
+  (Closes: #823984)
+
+  [ Salvatore Bonaccorso ]
+  * CVE-2016-1541: heap-based buffer overflow due to improper input
+validation (Closes: #823893)
+
+ -- Simon McVittie   Mon, 16 May 2016 09:46:05 +0100
+
 libarchive (3.1.2-11) unstable; urgency=medium
 
   * Add d/p/Add-ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS-option.patch
diff --git a/debian/patches/Issue-656-Fix-CVE-2016-1541-VU-862384.patch b/debian/patches/Issue-656-Fix-CVE-2016-1541-VU-862384.patch
new file mode 100644
index 000..22a1bb2
--- /dev/null
+++ b/debian/patches/Issue-656-Fix-CVE-2016-1541-VU-862384.patch
@@ -0,0 +1,65 @@
+From d0331e8e5b05b475f20b1f3101fe1ad772d7e7e7 Mon Sep 17 00:00:00 2001
+From: Tim Kientzle 
+Date: Sun, 24 Apr 2016 17:13:45 -0700
+Subject: [PATCH] Issue #656:  Fix CVE-2016-1541, VU#862384
+
+When reading OS X metadata entries in Zip archives that were stored
+without compression, libarchive would use the uncompressed entry size
+to allocate a buffer but would use the compressed entry size to limit
+the amount of data copied into that buffer.  Since the compressed
+and uncompressed sizes are provided by data in the archive itself,
+an attacker could manipulate these values to write data beyond
+the end of the allocated buffer.
+
+This fix provides three new checks to guard against such
+manipulation and to make libarchive generally more robust when
+handling this type of entry:
+ 1. If an OS X metadata entry is stored without compression,
+abort the entire archive if the compressed and uncompressed
+data sizes do not match.
+ 2. When sanity-checking the size of an OS X metadata entry,
+abort this entry if either the compressed or uncompressed
+size is larger than 4MB.
+ 3. When copying data into the allocated buffer, check the copy
+size against both the compressed entry size and uncompressed
+entry size.
+---
+ libarchive/archive_read_support_format_zip.c | 13 +
+ 1 file changed, 13 insertions(+)
+
+--- a/libarchive/archive_read_support_format_zip.c
 b/libarchive/archive_read_support_format_zip.c
+@@ -560,6 +560,11 @@ zip_read_mac_metadata(struct archive_rea
+ 
+ 	switch(rsrc->compression) {
+ 	case 0:  /* No compression. */
++		if (rsrc->uncompressed_size != rsrc->compressed_size) {
++			archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT,
++			"Malformed OS X metadata entry: inconsistent size");
++			return (ARCHIVE_FATAL);
++		}
+ #ifdef HAVE_ZLIB_H
+ 	case 8: /* D

Bug#824435: please enable CONFIG_EXYNOS_VIDEO

[Steinar H. Gunderson]

On Mon, May 16, 2016 at 01:44:38AM +0100, Ben Hutchings wrote:
> That has no useful effect, as it is a boolean option that only enables
> a menu of further options.
> 
> Please explain what changes are really needed.

Hm. I was trying to compile a kernel to verify this, but it took more than
overnight to build the packages...

This is ODROID's XU4 4.2 tree config:

https://github.com/tobetter/linux/blob/39fb8734966df320584f8c186652cec831e90054/arch/arm/configs/odroidxu4_defconfig

On a guess, the relevant parts would probably be

  CONFIG_EXYNOS_VIDEO=m
  CONFIG_EXYNOS_MIPI_DSI=m
  CONFIG_DRM_EXYNOS=m
  CONFIG_DRM_EXYNOS_MIXER=y  [not in that config, but _HDMI depends on it]
  CONFIG_DRM_EXYNOS_FIMD=y
  CONFIG_DRM_EXYNOS_DSI=y
  CONFIG_DRM_EXYNOS_DP=y
  CONFIG_DRM_EXYNOS_HDMI=y
  CONFIG_PHY_EXYNOS_MIPI_VIDEO=m
  CONFIG_PHY_EXYNOS_DP_VIDEO=m

There are also power management settings that I believe might be useful
(not related to display):

  CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU=y
  CONFIG_ARM_EXYNOS_CPUIDLE=y

and I guess also

  CONFIG_EXYNOS_ADC=m
  
I can try compiling a kernel with all of those set and see if I get any more
video, but if you have any tricks to make dpkg-buildpackage go faster
for kernel builds, please let me know :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#824451: libarchive: FTBFS on kFreeBSD: tar/test/test_option_older_than.c:70: File should exist

[Simon McVittie]

Source: libarchive
Version: 3.2.0-1
Severity: important
Tags: upstream
User: debian-...@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-...@lists.debian.org

As already reported to debian-bsd by the libarchive maintainer,
libarchive 3.2.0 fails to build from source on kFreeBSD due to this
test failure:

 40: test_option_older_than
 tar/test/test_option_older_than.c:70: File should exist: a/b/old.txt
 tar/test/test_option_older_than.c:83: File should exist: a/b/old.txt

This would normally be Severity: serious, but kFreeBSD isn't a release
architecture, so I'm filing it as important instead.

This test creates files named old.txt and middle.txt with mtimes in
sequence, using this pseudocode:

create old.txt
while old.txt's mtime in seconds >= time(NULL):
sleep 1
create middle.txt
while middle.txt's mtime in seconds >= time(NULL):
sleep 1

This looks as though it should work, and result in old.txt being strictly
older than middle.txt (even if timestamps are rounded down to the next
earlier second), which is strictly older than the time at which that
pseudocode ends. However, perhaps there's some kFreeBSD quirk that I'm
not aware of?

Alternatively, this could probably be addressed by artificially aging
old.txt and middle.txt, like I do in ikiwiki's test suite. For example,
it could use utimes() to make old.txt 2 years old and make middle.txt
1 year old. This might not be acceptable to upstream if utimes() is not
portable to all the platforms they care about, but a portable wrapper
could use _utime64() on Windows if desired.

Regards,
S

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

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

Bug#823893: libarchive: CVE-2016-1541

[Andreas Henriksson]

Hello Simon McVittie.

On Mon, May 16, 2016 at 10:12:19AM +0100, Simon McVittie wrote:
[...]
> uploaded to DELAYED/5. Diff attached, or available here:
> ssh://alioth.debian.org/srv/home/users/smcv/public_git/libarchive.git
> 
> If you would like it accelerated or cancelled, please let me know; or

Please feel free to go ahead with NMU without delay (as already mentioned
to Salvatore)!

> if you decide to go ahead with 3.2.0 or a 3.1.2-12 maintainer upload
> in unstable so that my NMU is superseded and rejected, that's also fine
> of course.

I'll focus on 3.2.0 myself which means I'll likely just ignore your NMU
if you base it on 3.1.2 when I feel 3.2.0 is ready to go to unstable
(unless you have strong opinions on having your NMU changelog entry
merged).

> 
> I'll open a separate bug for the test failure. Since you are the
> libarchive maintainer, you get to decide whether you consider failures on
> the non-release kFreeBSD architectures to be RC. Because the kFreeBSD
> architectures aren't release architectures, I believe out-of-date
> binaries on those architectures don't slow down testing migration,
> so fixing the security vulnerability on Linux doesn't need to block on
> fixing the tests on kFreeBSD.

Thanks. I don't consider kfreebsd a "real" blocker as this bug should
not be RC, but given that AFAIK libarchive has a pretty exploding
reverse dependency chain many important parts of the archive could
quickly become unbuildable I thought it would be nice to give the
kfreebsd porters a chance to reply to
https://lists.debian.org/debian-bsd/2016/05/msg00032.html
before proceeding. Not that I have super high hopes of getting a reply
and I'll certainly not wait forever... just giving them a chance (so
in another week or a bit more maybe I'll just upload).

Regards,
Andreas Henriksson

PS. Help maintaining libarchive welcome!

Bug#824204: libyajl-dev: Static linking doesn't work

[George Dunlap]

On 14/05/16 04:03, John Stamp wrote:
> Hi George,
> 
> It looks like it's just a problem with the link order of the sample
> command that you provided.
> 
> Can you confirm that this works?
> 
>   gcc -o p parse_config.c -lyajl_s

/me hangs his head in shame

Yes, it does work -- thanks. :-)

 -George

Bug#824390: Bug solved after upgrade

[Riccardo Lancellotti]

It looks like the problem was related to some incompatibility issue
with a previous version of some library (libecal-1.2 is my guess).

-- 
Saluti,
   Riccardo

Bug#824443: gtk-redshift: README.Debian has bad autostart instructions

[Ritesh Raj Sarraf]

Control: fixed -1 1.10-6

On Sun, 2016-05-15 at 21:24 -0500, Karl O. Pinc wrote:
> Package: gtk-redshift
> Version: 1.9.1-4
> Severity: minor
> 
> Hi,
> 
> The README.debian says:
> 
> If you want gtk-redshift autostarted please
> configure this in your specific desktop environment (e.g. by placing
> /usr/share/applications/gtk-redshift.desktop in
> $HOME/$XDG_CONFIG_HOME/autostart/
> (usually defaults to $HOME/.config/autostart).
> 
> This is wrong.  The user should install an autostart package.
> (e.g. gtk-redshift or redshift-plasmoid.)

This is not applicable to the current version in testing/unstable.
Given that it is a minor bug, at this time, fixing it for stable may not be that
important.

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


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

Bug#821187: uscan workaround

[Maximiliano Curia]

¡Hola Mr!

El 2016-05-15 a las 09:44 +, Mr riaas mokiem escribió:
I think it might be possible to work around the uscan bug by only having the 
URL for stable releases in the watch file. This means you no longer track the 
unstable releases but it should almost certainly work.



You may also be able to track both stable and unstable releases with 1 URL:
http://download.kde.org/(?:un)?stable/plasma/([\d.]+)/libksysguard-([\d.]+) 
\.tar\.xz 


Currently that only checks the unstable versions, as uscan decides which 
subtrees would visit on every pattern, in the (unstable|stable) case it simply 
selects unstable as its greater than stable.


Uscan would need to check every pattern alternative for this to work 
correctly, which is not main use case of uscan and can be easily become 
overkill.


In particular for the kde packages, I'm not sure if we want to track the 
unstable versions with uscan at all.


As mentioned before, I think this problem may affect many other KDE packages, 
mostly from Plasma and Frameworks. The KDE Applications seem to be fine since 
most of those only seem to track the stable URL.


I think that I've already removed the unstable paths from the watch files for 
framewors, plasma and apps, in my work in progress repos, that I'm planning to 
upload shortly.


Happy hacking,
--
"The sooner you start to code, the longer the program will take."
-- Roy Carlson
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature

Bug#823893: libarchive: CVE-2016-1541

[Simon McVittie]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 16 May 2016 at 11:25:31 +0200, Andreas Henriksson wrote:
> Please feel free to go ahead with NMU without delay (as already mentioned
> to Salvatore)!

Thanks, rescheduled to 0-day.

> I'll focus on 3.2.0 myself which means I'll likely just ignore your NMU
> if you base it on 3.1.2 when I feel 3.2.0 is ready to go to unstable
> (unless you have strong opinions on having your NMU changelog entry
> merged).

Not merging 3.1.2-11.1 is fine, as long as the BTS version-tracking is happy
(#823893 is already marked as fixed in 3.2.0, I'll mark #823984 as fixed
there too).

S
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJXOZQJAAoJEE3o/ypjx8yQpHcP/1aioiphA4HItEvUjPCZI5nu
frJn6ebrsrj5OmpCitT12xzF2fojeAzw+05+lEeqMRLydTOALFO6hDXpH++sB/mT
B4k3sGweEg+RpkK0HY76I1C+NLHmswqULNQ7WEbcPCwqkkDsPmMnLfLPZh68SvSq
zHuYG+miHlIUX9Jvn1Myr4XyfS1hv/z1I0u+XZzpIN3UJLbh9eg7onOqvMHqXMkA
1Ki2AJkL9mXB1o2V5yJtqpnNfB0qQTvuELZ0yo6kjE4A/A2lMvTPOrUkQcbx9yS9
Kqgw1s5Fo5gOW5AKNNXwYe1Y2FWLWKNEw6IxiU+ClNMOzXVYy1GodBMO9CidbMo9
eZGbhYoivdrEYqI7KC5k4/+asxmfG/SGNcLY1FWzRAlS5tlJbs6Qd4dkX7EhQcxw
kYTHxRj4xRu+hHvsXWT/KKvAwWeVg5iaIbMzk7Ovun4NRQDWUjN0OC5tv6jQCZqK
8sRAIVQg+cx3pYUSZbNYre79b/SJ89D66IZnW4mGEs0xBuhtA92dYsEVZ6yMgnOQ
fkj/qcl6ivPRh0yGbRJgc20gceWlrCip3ooQi0J2snerZUq+Blj8Ig5OzeXrfNa9
FjhS0mQnkaNLaWTQ6sdG0KlQAyHxc9VATOrxMGRHhXekkOF9ulnDMoGnLkaEsFfy
ktuNI/VIobQAoy/ejZGU
=Xr3y
-END PGP SIGNATURE-

Bug#823984: libarchive13/unstable is older than libarchive13/stable

[Simon McVittie]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Version: 3.2.0-1

On Wed, 11 May 2016 at 02:52:08 +0200, Vincent Lefevre wrote:
> libarchive13 from unstable is now older than the version from stable
> (due to a security update).

This will be fixed when a version based on 3.2.0 reaches unstable.
Updating the BTS version-tracking accordingly.

For a stop-gap solution until 3.2.0 is ready, I've done a non-maintainer
upload versioned 3.1.2-11.1 which will also close this bug.

S
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJXOZSUAAoJEE3o/ypjx8yQODwP/2NMI9317WwaKwzysF1ivUDX
Bscktrl+6L6yyI9TFYUPHkGhC3/ZhLWW1zAl9X5gY2r10rXIIB9DTnlVifmLNBg0
Z7NiCxZxfd3QD+4OgW2uiwiYu2YodA0qQAY4MpNUp7OHynjx2XG1yR2qzj5Dik+S
7j/GhRq/9y1OajmuewifMKOfaAovqzSvUDu30MXM20WthjolJzHGaE5LFZx6rRXl
koC6GgteTxsSAo0GJfCbTFKmT+5WlYugMVbAEBj/VAO3pxtJOYXnGyy+6eHcO4Qm
t6v/guMXptUGqJhrLvICpv5ICqGzdOzrhro+ewNNR0u3ARYyuHwrP5xLi7Eddamf
Tkv5YW7YAsJwrgDVtPe+nd+5AcCG1WSjRn+FHalCGoJLFvEkucIBgFZ8TciS+YLE
yQenuQXnRC4wXAJlvdgIRM/jFGPPhUceZmbRdPF0abDsipNIVrNvoZ+BoxKjons0
ZclKipq2lLdnhawAaCMeDbpdTJvrsOfEvtF6mcdTlGfVjUAnWrpxNr/DyD6CA2xX
cXDokIH6kreQtuf52f1n70z3ryfaYjMdMNvyo2aOY/uDUlImgG5ZlCbj5uZ1qQwQ
25fjSa0yXzVleqUtEtWsOYlt4aHcd1f4X+3MAbVVapMIM5jGRkxc0UYgy4T/ppUv
YoKAbuV5Tg7afeD7FwUy
=JmIL
-END PGP SIGNATURE-

Bug#824446: redshift: There is no documentation on where to place a config file

[Ritesh Raj Sarraf]

On Sun, 2016-05-15 at 22:00 -0500, Karl O. Pinc wrote:
> Package: redshift
> Version: 1.9.1-4
> Severity: normal
> 
> Hello,
> 
> The package includes a sample config file, but contains
> no information on where to put it.  Where does the config
> file go?

Actually, I just checked at realized that there is a section 5 manpage with the
same name.

But I agree with your bug report. IMO, it should be redshift.conf or something
like that.

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


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

Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Santiago Vila]

tags 824011 + patch
thanks

Patch attached.

In either case, I recommend that you still try to reproduce the bug to
fully understand it. Here is the way to reproduce it:

* Create a stretch chroot (with debootstrap).

* Install debhelper in the chroot. This will automatically install
  "automake" as a dependency.

* Then try to build warzone2100 with a command line like this:

sbuild -d stretch -A warzone2100_3.1.1-3

You will get a nice FTBFS like the one I attached in the initial bug report.

This is what happens: sbuild knows that it has to install automake1.11
because it's in the build-depends, so it does install it, but
then configure still detects normal automake (because nowhere it's said
that it has to be removed), and it fails.

When the Build-Conflicts is in place, sbuild knows that it has to remove
"automake" (in addition to installing automake1.11), and you can see
this in the build log:

The following packages will be REMOVED:
  automake*

As I said in the previous email, Build-Conflicts exist precisely
to deal with cases like this one.

Another solution would be to modify debian/rules so that automake1.11
is detected instead of automake when both are installed. I don't know
how to do that, but if you manage to do that way, it would also fix
the bug.

Hope this helps.

Thanks.--- a/debian/control
+++ b/debian/control
@@ -41,6 +41,8 @@ Build-Depends:
  xsltproc,
  xvfb,
  zip
+Build-Conflicts:
+ automake
 Standards-Version: 3.9.8
 Homepage: http://www.wz2100.net/
 Vcs-Svn: svn://anonscm.debian.org/pkg-games/packages/trunk/warzone2100/

Bug#824444: gtk-redshift: The README.debian has the wrong filename vis autostart

[Ritesh Raj Sarraf]

Control: merge -1 824443


I'm just going to merge this with the other one. THe status applies the same to
this bug too.

On Sun, 2016-05-15 at 21:27 -0500, Karl O. Pinc wrote:
> Package: gtk-redshift
> Version: 1.9.1-4
> Severity: minor
> 
> Hello,
> 
> The README.debian says to autostart install:
> 
> /usr/share/applications/gtk-redshift.desktop
> 
> This is wrong.   The correct filename is:
> 
> /usr/share/applications/redshift-gtk.desktop
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#805471: /usr/bin/optirun: optirun fails with "systemd-logind: failed to get session"

[Luca Boccassi]

On Tue, 2016-05-03 at 15:17 +0200, Giacomo Boffi wrote:
> Oh well... they stole my previous notebook, the one NVIDIA equipped —
> I would like to ask the burglar about xserver-xorg-legacy, and maybe
> another couple of questions, but I had no chances for that.
> I can tell you that after a while TORCS^H^H^H^H^Hbumblebee returned to
> work perfectly for me.  I think it was some regression due to the
> introduction of systemd that went away as the environment matured.
> Thanks a lot for your interest, ciao
>  gb

Sorry to hear that.
Given the situation, and the fact that I believe the Xorg binary fix
would have solved this, I'm going to close this bug.

> On Sun, May 1, 2016 at 5:59 PM, Luca Boccassi  wrote:
> > On 10 January 2016 at 19:50, Dariusz Dwornikowski
> >  wrote:
> >> On 08.01.16 00:40:40, Luca Boccassi wrote:
> >>> On Thu, 2016-01-07 at 20:26 +0100, Dariusz Dwornikowski wrote:
> >>> > On 19.11.15 11:58:58, Luca Boccassi wrote:
> >>> > > On Wed, 2015-11-18 at 15:21 +0100, Giacomo Boffi wrote:
> >>> > > > Package: bumblebee
> >>> > > > Version: 3.2.1-10
> >>> > > > Severity: important
> >>> > > > File: /usr/bin/optirun
> >>> > > >
> >>> > > > Dear Maintainer,
> >>> > > >
> >>> > > > I'm unable to use optirun on my Debian system, eg:
> >>> > > >
> >>> > > > $ optirun -vvv xterm
> >>> > > > [26394.265933] [DEBUG]Reading file: /etc/bumblebee/bumblebee.conf
> >>> > > > [26394.266265] [DEBUG]optirun version 3.2.1 starting...
> >>> > > >
> >>> > > > [26394.266276] [DEBUG]Active configuration:
> >>> > > > [26394.266296] [DEBUG] bumblebeed config file: 
> >>> > > > /etc/bumblebee/bumblebee.conf
> >>> > > > [26394.266301] [DEBUG] X display: :8
> >>> > > > [26394.266306] [DEBUG] LD_LIBRARY_PATH:
> >>> > > > /usr/lib/x86_64-linux-gnu/nvidia:/usr/lib/i386-linux-gnu/nvidia:/usr/lib/nvidia
> >>> > > > [26394.266314] [DEBUG] Socket path: /var/run/bumblebee.socket
> >>> > > > [26394.266334] [DEBUG] Accel/display bridge: auto
> >>> > > > [26394.266339] [DEBUG] VGL Compression: proxy
> >>> > > > [26394.266345] [DEBUG] VGLrun extra options:
> >>> > > > [26394.266350] [DEBUG] Primus LD Path:
> >>> > > > /usr/lib/x86_64-linux-gnu/primus:/usr/lib/i386-linux-gnu/primus:/usr/lib/primus:/usr/lib32/primus
> >>> > > > [26394.266381] [DEBUG]Using auto-detected bridge primus
> >>> > > > [26394.300436] [INFO]Response: No - error: [XORG] (EE) 
> >>> > > > systemd-logind:
> >>> > > > failed to get session: PID 24963 does not belong to any known 
> >>> > > > session
> >>> > > >
> >>> > > > [26394.300460] [ERROR]Cannot access secondary GPU - error: [XORG] 
> >>> > > > (EE)
> >>> > > > systemd-logind: failed to get session: PID 24963 does not belong to
> >>> > > > any known session
> >>> > > >
> >>> > > > [26394.300467] [DEBUG]Socket closed.
> >>> > > > [26394.300483] [ERROR]Aborting because fallback start is disabled.
> >>> > > > [26394.300489] [DEBUG]Killing all remaining processes.
> >>> > > > $
> >>> > > > Please tell me if I can submit further info to help solving this 
> >>> > > > problem.
> >>> > >
> >>> > > Hi,
> >>> > >
> >>> > > What's the output of:
> >>> > >
> >>> > > sudo systemctl status bumblebeed
> >>> > >
> >>> > > Also, could you please attach your:
> >>> > >
> >>> > > /etc/bumblebee/bumblebee.conf
> >>> > >
> >>> >
> >>> >
> >>> > I can confirm the same bug.
> >>> >
> >>> > tdi@blackstar:~ $ _ systemctl status bumblebeed
> >>> > ● bumblebeed.service - Bumblebee C Daemon
> >>> >Loaded: loaded (/lib/systemd/system/bumblebeed.service; enabled; 
> >>> > vendor preset: enabled)
> >>> >Active: active (running) since czw 2016-01-07 20:11:08 CET; 13min ago
> >>> >  Main PID: 4540 (bumblebeed)
> >>> >CGroup: /system.slice/bumblebeed.service
> >>> >└─4540 /usr/sbin/bumblebeed
> >>> >
> >>> > sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055043] 
> >>> > [ERROR][XORG] (EE) /dev/dri/card0: failed to set DRM interface version 
> >>> > 1.4: Permission denied
> >>> > sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055087] 
> >>> > [ERROR][XORG] (EE) [drm] Failed to open DRM device for 
> >>> > pci::01:00.0: -19
> >>> > sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055103] 
> >>> > [ERROR][XORG] (EE) No devices detected.
> >>> > sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055115] 
> >>> > [ERROR][XORG] (EE)
> >>> > sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055126] 
> >>> > [ERROR][XORG] (EE) no screens found(EE)
> >>> > sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055138] 
> >>> > [ERROR][XORG] (EE)
> >>> > sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055151] 
> >>> > [ERROR][XORG] (EE) Please also check the log file at 
> >>> > "/var/log/Xorg.8.log" for additional information.
> >>> > sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055172] 
> >>> > [ERROR][XORG] (EE)
> >>> > sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055182] 
> >>> > [ERROR][XORG] (EE) Server terminated with error (1). Closing lo

Bug#819546: vsftpd no longer starts with systemd because of listen_ipv6=NO from Bug: #803999

[Jörg Frings-Fürst]

Hi,

my hints about that:

the comparison between Apache and vsftpd isn't possible. Vsftpd give
access to the local user and can so used for attacks to get local
access. Especially if there are a open IPV6 port. Which is on mostly
systems not well configured.

And at times where git: must replace with https: the dogma for more
security must be "daemons starting only if needed and not starting
after install".

CU
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54538 Bausendorf

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#824452: python-certbot: please make the build reproducible

[Chris Lamb]

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

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that 
python-certbot could not be built reproducibly.

Patch attached & sent upstream via https://github.com/certbot/certbot/pull/3005.


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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/certbot/reporter.py b/certbot/reporter.py
index d509cb0..b7b4e78 100644
--- a/certbot/reporter.py
+++ b/certbot/reporter.py
@@ -55,12 +55,14 @@ class Reporter(object):
 self.messages.put(self._msg_type(priority, msg, on_crash))
 logger.info("Reporting to user: %s", msg)
 
-def atexit_print_messages(self, pid=os.getpid()):
+def atexit_print_messages(self, pid=None):
 """Function to be registered with atexit to print messages.
 
 :param int pid: Process ID
 
 """
+if pid is None:
+pid = os.getpid()
 # This ensures that messages are only printed from the process that
 # created the Reporter.
 if pid == os.getpid():

Bug#824453: gtk-gnutella: please make the build reproducible

[Chris Lamb]

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

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that 
gtk-gnutella could not be built reproducibly.

Patch attached.


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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/scripts/nm-list b/scripts/nm-list
index fbd280c..96efd59 100755
--- a/scripts/nm-list
+++ b/scripts/nm-list
@@ -54,7 +54,7 @@ da39a3ee5e6b4b0d3255bfef95601890afd80709) ;;
 *) SHA1SUM=$TOP/src/bin/sha1sum ;;
 esac
 
-date=`date`
+date=`date --utc`
 sha1=`$SHA1SUM $file 2>/dev/null | cut -f1 -d' '`
 case "$sha1" in
 '')echo "Failed to compute SHA1 of $file" >&2; exit 1;;

Bug#801262: RFS: ppsspp/1.1.1-1 [ITP] -- A portable PSP emulator

[Gianfranco Costamagna]

> I'm not sure yet what happened to fonts-droid package. If 
> fonts-droid-fallback is the substitute, where's DroidSansJapanese.ttf 
> for example?

apt-file knows
https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html

> 
> Also, anyone knows what package has NotoSansThai-Regular.ttf now?

https://packages.debian.org/sid/all/fonts-noto-hinted/filelist

g.

> 
> cheers,
> sergio-br2
> 
> 
> On Wed, 6 Apr 2016 18:49:52 +0200 Gianfranco Costamagna 
>  wrote:
>  > FYI: libpng-dev is now provided by libpng16 in unstable.
>  >
>  > Transition started a few minutes ago, so I expect some 
> uninstallabilities in the next few days, but ppsspp should become 
> installable by the end of this week.
>  >
>  > cheers,
>  >
>  > G.
>  >
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#824454: python-latexcodec: please make the build reproducible

[Chris Lamb]

Source: python-latexcodec
Version: 1.0.3-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that 
python-latexcodec could not be built reproducibly.

Patch attached.


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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/rules b/debian/rules
index 6f5204c..e06b214 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,7 @@
 #export DEB_BUILD_OPTIONS=nocheck
 export PYBUILD_NAME=latexcodec
 
-DEBDATE := $(shell dpkg-parsechangelog -Sdate | date -u +%F)
+DEBDATE := $(shell dpkg-parsechangelog -Sdate | date -u -f- +%F)
 
 %:
dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild

Bug#820501: libseccomp FTBFS on hppa (with patch)

[Luca BRUNO]

forwarded 820501 https://github.com/seccomp/libseccomp/issues/28
tags 820501 + upstream
thanks

On Sat, 9 Apr 2016 10:03:31 +0200 Helge Deller  wrote:

> Nevertheless, until the patch gets applied upstream, can you please 
> apply it to the next upload of libseccomp?

For reference:
 - Upstream tracking bug:
   https://github.com/seccomp/libseccomp/issues/28
 - Upstream patch review:
   https://groups.google.com/forum/#!topic/libseccomp/6O28XC3urtY

I would personally prefer to wait for upstream final review and merge, and 
then just cherry-pick that patch revision.

Ciao, Luca

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

Bug#824455: missing license in debian/copyright

[Thorsten Alteholz]

Package: irstlm
Version: 6.00.05-1
Severity: serious
User: alteh...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks

Dear Maintainer,

please add the missing license of:
 irstlm-6.00.05/doc/mdframed.sty
to your debian/copyright.

Thanks!
  Thorsten

Bug#737743: fixed

[Barak A. Pearlmutter]

I believe this issue has been resolved, see [2] in the report and the
page it refers to at
https://wiki.debian.org/UnifiedCommunications/DebianDevelopers/UserGuide/Linphone

--Barak.

Bug#811779: fs-uae: FTBFS with GCC 6: narrowing conversion

[John Paul Adrian Glaubitz]

On 05/16/2016 10:10 AM, Andrea Musuruane wrote:
> A patch is already available.

This patch isn't enough, it still fails to build from source:

src/expansion.cpp:2537:1: error: narrowing conversion of '2148532239u'
from 'unsigned int' to 'int' inside { } [-Wnarrowing]
 };
 ^
src/expansion.cpp:2537:1: error: narrowing conversion of '2148532225u'
from 'unsigned int' to 'int' inside { } [-Wnarrowing]
src/expansion.cpp:2537:1: error: narrowing conversion of '2148532230u'
from 'unsigned int' to 'int' inside { } [-Wnarrowing]
src/expansion.cpp:2537:1: error: narrowing conversion of '2148532232u'
from 'unsigned int' to 'int' inside { } [-Wnarrowing]
src/expansion.cpp:2537:1: error: narrowing conversion of '2148532237u'
from 'unsigned int' to 'int' inside { } [-Wnarrowing]
src/expansion.cpp:2537:1: error: narrowing conversion of '2148532238u'
from 'unsigned int' to 'int' inside { } [-Wnarrowing]
src/expansion.cpp:2537:1: error: narrowing conversion of '2148532244u'
from 'unsigned int' to 'int' inside { } [-Wnarrowing]
src/expansion.cpp:2537:1: error: narrowing conversion of '2148532241u'
from 'unsigned int' to 'int' inside { } [-Wnarrowing]
src/expansion.cpp:2537:1: error: narrowing conversion of '2148532250u'
from 'unsigned int' to 'int' inside { } [-Wnarrowing]
src/expansion.cpp:2537:1: error: narrowing conversion of '2148532251u'
from 'unsigned int' to 'int' inside { } [-Wnarrowing]
src/expansion.cpp:2537:1: error: narrowing conversion of '2148532252u'
from 'unsigned int' to 'int' inside { } [-Wnarrowing]
src/expansion.cpp:2537:1: error: narrowing conversion of '2148532253u'
from 'unsigned int' to 'int' inside { } [-Wnarrowing]
src/expansion.cpp:2537:1: warning: converting to non-pointer type 'int'
from NULL [-Wconversion-null]
src/expansion.cpp:2537:1: warning: converting to non-pointer type 'int'
from NULL [-Wconversion-null]
src/expansion.cpp:2537:1: error: narrowing conversion of '2148532233u'
from 'unsigned int' to 'int' inside { } [-Wnarrowing]
src/expansion.cpp:2859:1: warning: converting to non-pointer type 'int'
from NULL [-Wconversion-null]
 };
 ^
Makefile:4156: recipe for target 'src/expansion.o' failed

As I have mentioned in the github issue, I also don't think that
"unsigned int" is a good choice as it's not guaranteed to be 32 bits.

I suggest using uae_u32 which is declared in src/include/uae/types.h.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#824456: please clarify --show-upgraded and Apt::Get::Show-Upgraded

[Marc Haber]

Package: apt
Version: 1.2.12
Severity: minor
File: /usr/bin/apt-get

Hi,

for ages, I had Apt::Get::Show-Upgraded in my apt configuration. While
cleaning up, I tried to investigate what it does. After removing, I
have not noticed any difference in apt/apt-get behavior. And, I don't
see any difference in the output of apt-get upgrade and apt-get
--show-upgraded upgrade:

[5/505]mh@fan:~$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  gnome-icon-theme-symbolic gnome-mime-data libbind9-90 libdns100 libgcj15
  libgit2-23 libgnomevfs2-0 libgnomevfs2-common libical1a libisc95 libisccc90
  libisccfg90 libllvm3.7 liblwres90 linux-image-4.4.0-1-amd64
Use 'sudo apt autoremove' to remove them.
The following packages have been kept back:
  libreoffice libreoffice-avmedia-backend-gstreamer libreoffice-base
  libreoffice-base-core libreoffice-base-drivers libreoffice-calc
  libreoffice-core libreoffice-draw libreoffice-impress libreoffice-math
  libreoffice-report-builder-bin libreoffice-writer muon-discover
  muon-notifier muon-updater python3-uno
The following packages will be upgraded:
  bind9 bind9utils fonts-opensymbol kdelibs-bin kdelibs5-data kdelibs5-plugins
  kdiff3 kdiff3-doc kdoctools libgps22 libkcmutils4 libkde3support4
  libkdeclarative5 libkdecore5 libkdesu5 libkdeui5 libkdewebkit5 libkdnssd4
  libkemoticons4 libkfile4 libkhtml5 libkio5 libkjsapi4 libkjsembed4
  libkmediaplayer4 libknewstuff2-4 libknewstuff3-4 libknotifyconfig4 libkntlm4
  libkparts4 libkprintutils4 libkpty4 libkrosscore4 libktexteditor4
  libnepomuk4 libnepomukquery4a libnepomukutils4 libplasma3 libpstoedit0c2a
  libqapt3 libqapt3-runtime libreoffice-common libreoffice-help-en-us
  libreoffice-java-common libreoffice-style-galaxy
  libreoffice-style-hicontrast libreoffice-style-oxygen
  libreoffice-style-tango libsolid4 libthreadweaver4 p7zip p7zip-full pstoedit
  uno-libs3 ure
55 upgraded, 0 newly installed, 0 to remove and 16 not upgraded.
Need to get 54.2 MB/55.1 MB of archives.
After this operation, 1806 kB of additional disk space will be used.
Do you want to continue? [Y/n] ^C
[6/506]mh@fan:~$ sudo apt-get --show-upgraded upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  gnome-icon-theme-symbolic gnome-mime-data libbind9-90 libdns100 libgcj15
  libgit2-23 libgnomevfs2-0 libgnomevfs2-common libical1a libisc95 libisccc90
  libisccfg90 libllvm3.7 liblwres90 linux-image-4.4.0-1-amd64
Use 'sudo apt autoremove' to remove them.
The following packages have been kept back:
  libreoffice libreoffice-avmedia-backend-gstreamer libreoffice-base
  libreoffice-base-core libreoffice-base-drivers libreoffice-calc
  libreoffice-core libreoffice-draw libreoffice-impress libreoffice-math
  libreoffice-report-builder-bin libreoffice-writer muon-discover
  muon-notifier muon-updater python3-uno
The following packages will be upgraded:
  bind9 bind9utils fonts-opensymbol kdelibs-bin kdelibs5-data kdelibs5-plugins
  kdiff3 kdiff3-doc kdoctools libgps22 libkcmutils4 libkde3support4
  libkdeclarative5 libkdecore5 libkdesu5 libkdeui5 libkdewebkit5 libkdnssd4
  libkemoticons4 libkfile4 libkhtml5 libkio5 libkjsapi4 libkjsembed4
  libkmediaplayer4 libknewstuff2-4 libknewstuff3-4 libknotifyconfig4 libkntlm4
  libkparts4 libkprintutils4 libkpty4 libkrosscore4 libktexteditor4
  libnepomuk4 libnepomukquery4a libnepomukutils4 libplasma3 libpstoedit0c2a
  libqapt3 libqapt3-runtime libreoffice-common libreoffice-help-en-us
  libreoffice-java-common libreoffice-style-galaxy
  libreoffice-style-hicontrast libreoffice-style-oxygen
  libreoffice-style-tango libsolid4 libthreadweaver4 p7zip p7zip-full pstoedit
  uno-libs3 ure
55 upgraded, 0 newly installed, 0 to remove and 16 not upgraded.
Need to get 54.2 MB/55.1 MB of archives.
After this operation, 1806 kB of additional disk space will be used.
Do you want to continue? [Y/n] ^C
[7/507]mh@fan:~$

Was --show-upgraded converted to a no-op? If yes, was this an
intentional change? Please consider clarifying the documentation.

Greetings
Marc



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "false";
APT::Install-Suggests "false";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.5\.4-zgws1$";
APT::NeverAutoRemove:: "^linux-headers-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.5\.4-zgws1$";
APT::Neve

Bug#821714: src:simplepie: PHP 7.0 Transition

[Tanguy Ortolo]

As I maintain dokuwiki which depends on php-simplepie, I am concerned by 
this. I will try to NMU this.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Gianfranco Costamagna]

control: tags -1 moreinfo

Hi Eric, some questions on the changes:
1) why do you need both autotools-dev and autoreconf?

2) did you get an ack from maintainers to add yourself as uploader


3) +Replaces: gnustep-common (<< 2.6.8-1)

this is something I don't understand.

also, the control.in file removal is not documented I guess

maybe Aron (ccd), being the latest sponsor might give you an additional review 
and sponsor the package

thanks for the really nice work! I did a test build and the build logs looks 
good to be, as well as the built
binaries (however I didn't install them).

thanks

Gianfranco



Il Domenica 15 Maggio 2016 3:39, Eric Heintzmann  ha 
scritto:



Le 15/05/2016 03:26, Adam Borowski a écrit :
> On Sun, May 15, 2016 at 03:04:37AM +0200, Eric Heintzmann wrote:
>> Le 15/05/2016 02:46, Adam Borowski a écrit :
>>> On Sat, May 14, 2016 at 12:39:16PM +0200, Eric Heintzmann wrote:
   I am looking for a sponsor for my package "gnustep-make"

  * Package name: gnustep-make
Version : 2.6.8-1

 dget -x 
 https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc
>>> As there's LOADS of packaging changes, could you please push them to a VCS? 
>>> That'd make reviewing greatly easier.  From the new changelog I assume you
>>> used git, I just don't see anything new past 2.6.6-3 on any branches on
>>> pkg-gnustep/gnustep-make.git.
>> Sorry, but I've not used git nor any VCS because I work all alone
>> since I am the last active member of the Debian GNUstep maintainers.
>> If I had knew that make reviewing easier, I would have used Git.
>> If you want I can push my changes on pkg-gnustep/gnustep-make.git
>> but there will be only one big commit.
>> Sorry, I ve done a mistake how can I repair it ?
> Oif.  I guess trying to split this big commit would be far more work than
> just reviewing it the hard way, so there's nothing that can be done here.
> That's unfortunate as it raises the difficulty of review considerably.
>
> As gnustep-make is a complex package I'm not familiar with, I'm afraid
> I'll leave it to someone with more time and experience.
>
I think I can split this big commit in multiple commits, one for each file.
If needed I will do it.

Thanks

Bug#824457: strongswan: FTBFS in testing

[Santiago Vila]

Package: src:strongswan
Version: 5.4.0-1
Severity: serious

Dear maintainer:

This package currently fails to build from source in stretch:


In file included from /usr/include/libiptc/ipt_kernel_headers.h:13:0,
 from /usr/include/libiptc/libiptc.h:6,
 from connmark_listener.c:24:
/usr/include/linux/if.h:71:2: error: redeclaration of enumerator 'IFF_UP'
  IFF_UP= 1<<0,  /* sysfs */


The full build log is attached.

Thanks.

strongswan_5.4.0-1_amd64-20160516-1227.gz
Description: application/gzip

Bug#824458: xtables-addons: FTBFS in testing

[Santiago Vila]

Package: src:xtables-addons
Version: 2.10-1
Severity: serious

Dear maintainer:

This package currently fails to build from source in stretch:


make[7]: Entering directory '/<>/extensions/pknock'
  CC libxt_pknock.oo
In file included from /usr/include/xtables.h:16:0,
 from libxt_pknock.c:15:
/usr/include/linux/if.h:71:2: error: redeclaration of enumerator 'IFF_UP'
  IFF_UP= 1<<0,  /* sysfs */
  ^
/usr/include/net/if.h:44:5: note: previous definition of 'IFF_UP' was here
 IFF_UP = 0x1,  /* Interface is up.  */
 ^


The full build log is attached.

Thanks.

xtables-addons_2.10-1_amd64-20160516-1230.gz
Description: application/gzip

Bug#824460: torbrowser upgrades still broken with apparmor enabled

[Holger Levsen]

package: torbrowser-launcher
tags: + help
version: 0.2.4-1
user pkg-apparmor-t...@lists.alioth.debian.org
usertags: help-needed buggy-profile

Hi,

so it seems upgrades of torbrowser are still not working using the
apparmor rules from torbrowser-launcher in sid.

https://github.com/micahflee/torbrowser-launcher/issues/181 has some
details at the end indicating this.

Filing this bug so we (or some of us) don't believe there is no issue.

from that issue:

On Sun, May 15, 2016 at 02:21:01PM -0700, intrigeri wrote:
> > Intrigeri, there is no Debian bug open about apparmor upgrade problems, so 
> > I've been under the assumption that there is no problem.
> 
> Last time I filed such a bug report and attached a patch that (as I thought I 
> made clear back then) was probably not enough to fix the problem yet, and 
> needed more tests, the bug was closed by an upload that contained that 
> incomplete patch. And indeed, experience showed that it was not sufficient to 
> make the whole thing work. I lack time+energy+motivation to argue about how 
> bugs in this Debian package should be handled ("aggressive" closing vs. 
> confirming that the problem is really gone). So I took it easy, gave up 
> trying to keep the Debian BTS up-to-date on this topic, and focused on trying 
> to get something that really works for me, that I can send directly upstream 
> at some point. My hope is that it'll save everyone some boring paperwork, 
> allow me to keep contributing to fixing this problem in a relaxed way that 
> I'm comfortable with, and result in something that improves the actual TBL + 
> AppArmor user experience at some point.
> 
> > And in any case, this bug report is not helpful so I recommend to still 
> > close it.
> 
> Absolutely! :)
> 
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/micahflee/torbrowser-launcher/issues/181#issuecomment-219311346


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#824459: tango: FTBFS in testing

[Santiago Vila]

Package: src:tango
Version: 8.1.2c+dfsg-7
Severity: serious

Dear maintainer:

This package currently fails to build from source in stretch:


In file included from ../../../../lib/cpp/server/w_attribute.cpp:61:0:
../../../../lib/cpp/server/w_attribute.cpp: In member function 'virtual bool 
Tango::WAttribute::check_rds_ala
rm()':
../../../../lib/cpp/server/tango_config.h:201:38: error: expected 
unqualified-id before '(' token
 #define Tango_isnan(A)  std::isnan(A)
  ^
../../../../lib/cpp/server/w_attribute.cpp:3421:11: note: in expansion of macro 
'Tango_isnan'
  if ( Tango_isnan(double_array_val[0]) || Tango_isnan(tmp_db[0]) )


The full build log is attached.

Thanks.

tango_8.1.2c+dfsg-7_amd64-20160516-1227.gz
Description: application/gzip

Bug#811779: fs-uae: FTBFS with GCC 6: narrowing conversion

[John Paul Adrian Glaubitz]

On 05/16/2016 12:29 PM, John Paul Adrian Glaubitz wrote:
> On 05/16/2016 10:10 AM, Andrea Musuruane wrote:
>> A patch is already available.
> 
> This patch isn't enough, it still fails to build from source:

WinUAE upstream has additionally made the following change in
src/include/autoconf.h:

{
const TCHAR *name;
const TCHAR *configname;
-   int romtype;
+   uae_u32 romtype;
int memory_mid, memory_pid;
uae_u32 memory_serial;
bool memory_after;
@@ -153,9 +153,9 @@ struct expansionromtype
const TCHAR *friendlymanufacturer;
DEVICE_INIT init, init2;
DEVICE_ADD add;
-   int romtype;
-   int romtype_extra;
-   int parentromtype;
+   uae_u32 romtype;
+   uae_u32 romtype_extra;
+   uae_u32 parentromtype;
int zorro;
bool singleonly;
const struct expansionsubromtype *subtypes;

I will merge this patch and the suggested change for src/includ
/rommgr.h, but with "uae_u32" instead of "unsigned int".

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#824461: apparmor: please remove me from uploaders

[Holger Levsen]

package: apparmor
severity: minor
version: 2.10-4

Hi,

please remove me from uploaders:, it's unrealistic since some time that
I'll get to spend any time on this. Sorry & keep up the good work!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#823895: RFS: lsm/1.0.4-1

[Gianfranco Costamagna]

control: tags -1 moreinfo

Not sure if Adam is going to sponsor the package, but I'm setting at least the 
moreinfo tag :)



g.


Il Domenica 15 Maggio 2016 1:57, Adam Borowski  ha scritto:
On Sun, May 15, 2016 at 01:45:32AM +0200, Adam Borowski wrote:
> Too bad, when actually trying to install the package:
> 
> [] Starting Link Monitor.: lsminvoke-rc.d: initscript lsm, action "start" 
> failed.
> dpkg: error processing package lsm (--install):
>  subprocess installed post-installation script returned error exit status 1
> Processing triggers for man-db (2.7.5-1) ...
> Errors were encountered while processing:
>  lsm

Failing to uninstall is even worse:
Removing lsm (1.0.4-1) ...
[] Stopping Link Monitor.: lsminvoke-rc.d: initscript lsm, action "stop" 
failed.
dpkg: error processing package lsm (--purge):
subprocess installed pre-removal script returned error exit status 1
Errors were encountered while processing:
lsm

Please either use --oknodo in the stop target or otherwise make it handle
the "wasn't running" case as success.  I see you attempt to do so, but "set
-e" breaks that.



Meow!
-- 
A tit a day keeps the vet away.

Bug#824462: apparmor-profiles-extra: please remove me from uploaders

[Holger Levsen]

package: apparmor-profiles-extra
severity: minor
version: 1.8

Hi,

please remove me from uploaders: it's unrealistic since some time that
I'll get to spend any time on this. Sorry & keep up the good work!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#824463: elektra: FTBFS in testing

[Santiago Vila]

Package: src:elektra
Version: 0.8.14-5
Severity: serious

Dear maintainer:

This package currently fails to build from source in stretch:


In file included from 
/<>/src/libgetenv/benchmarks/benchmark_getenv.cpp:11:0:
/<>/src/bindings/cpp/include/kdbtimer.hpp:33:15: error: 'vector' 
in namespace 'std' does not nam
e a template type
  typedef std::vector results_t;
   ^
/<>/src/bindings/cpp/include/kdbtimer.hpp:34:2: error: 'results_t' 
does not name a type
  results_t results;
  ^


The full build log is attached.

Thanks.

elektra_0.8.14-5_amd64-20160516-1227.gz
Description: application/gzip

Bug#824464: uswsusp: where is suspend-keygen?

[Fulano Diego Perez]

Package: uswsusp
Version: 1.0+20120915-6.1
Severity: normal

id like to change the key and find suspend-keygen


# /etc/uswsusp.conf(5) -- Configuration file for s2disk/s2both
resume device = /dev/disk/by-uuid/abc123
compress = y
early writeout = y
image size = 3796961116
RSA key file = /etc/uswsusp.key
shutdown method = platform


/etc/uswsusp.key does not exist


uswsusp/RSA_key_bits: 1024
this should be changed/increased...


i cannot find any reference to all of the above in debconf




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

Kernel: Linux 4.5.0-2-amd64
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages uswsusp depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libblkid1  2.28-1
ii  libc6  2.22-7
pn  liblzo2-2  
ii  libpci31:3.3.1-1.1
pn  libx86-1   

Versions of packages uswsusp recommends:
ii  initramfs-tools  0.125
ii  mount2.28-1

uswsusp suggests no packages.

-- debconf information:
  uswsusp/compress: true
  uswsusp/resume_device: /dev/disk/by-uuid/abc123
  uswsusp/RSA_key_bits: 1024
  uswsusp/max_loglevel:
  uswsusp/shutdown_method: platform
  uswsusp/continue_without_swap: true
  uswsusp/create_RSA_key: false
  uswsusp/resume_offset:
  uswsusp/RSA_key_file: /etc/uswsusp.key
  uswsusp/no_swap:
  uswsusp/no_snapshot:
  uswsusp/early_writeout: true
  uswsusp/compute_checksum: false
  uswsusp/encrypt: false
  uswsusp/suspend_loglevel:
  uswsusp/image_size: 3796961116
  uswsusp/snapshot_device:

Bug#824465: littler: FTBFS in testing

[Santiago Vila]

Package: src:littler
Version: 0.3.0-2
Severity: serious

Dear maintainer:

This package currently fails to build from source in stretch:


make[1]: Entering directory '/<>/src'
gcc -std=gnu99 -o r -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_S
OURCE=2 -g -I/usr/share/R/include littler.c  -Wl,--export-dynamic -fopenmp  
-L/usr/lib/R/lib -lR -lpcre -llzm
a -lbz2 -lz -lrt -ldl -lm -licuuc -licui18n -lblas -llapack 
-Wl,-rpath,/usr/lib/R/lib -Wl,-rpath,/usr/lib/x86
_64-linux-gnu -Wl,-rpath,/usr/lib/jvm/default-java/jre/lib/amd64/server 
-Wl,-rpath,/usr/lib/R/lib -Wl,-rpath,
/usr/lib/x86_64-linux-gnu 
-Wl,-rpath,/usr/lib/jvm/default-java/jre/lib/amd64/server 
-Wl,-rpath,/usr/lib/R/lib
 -Wl,-rpath,/usr/lib/x86_64-linux-gnu 
-Wl,-rpath,/usr/lib/jvm/default-java/jre/lib/amd64/server -Wl,-rpath,/u
sr/lib/x86_64-linux-gnu/libfakeroot -Wl,-rpath,/usr/lib64/libfakeroot 
-Wl,-rpath,/usr/lib32/libfakeroot 
/usr/bin/ld: cannot find -licuuc
/usr/bin/ld: cannot find -licui18n
collect2: error: ld returned 1 exit status
Makevars:29: recipe for target 'r' failed


The full build log is attached.

Thanks.

littler_0.3.0-2_amd64-20160516-1238.gz
Description: application/gzip

Bug#824460: testing using alpha versions?

[Holger Levsen]

Hi,

one problem debugging this is that this problem occurs only if+when
there is a new upstream version of torbrowser to be updated too, which
only happens every 6-8 weeks or so.

It just occured to me that this problem can probably be tested anytime
though, by 

- (enabling apparmor)
- launching torbrowser-launcher, which will install the latest stable
  torbrowser
- configuring torbrowser-launcher to use alpha-releases.
- launching torbrowser-launcher to upgrade to said alpha release.

Currently as per this bug, this should fail. Once the profiles has been
fixed, this should work.

The above procedure should be usable for testing this anytime.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#824456: please clarify --show-upgraded and Apt::Get::Show-Upgraded

[Julian Andres Klode]

On Mon, May 16, 2016 at 12:35:01PM +0200, Marc Haber wrote:
> Package: apt
> Version: 1.2.12
> Severity: minor
> File: /usr/bin/apt-get
> 
> Hi,
> 
> for ages, I had Apt::Get::Show-Upgraded in my apt configuration. While
> cleaning up, I tried to investigate what it does. After removing, I
> have not noticed any difference in apt/apt-get behavior. And, I don't
> see any difference in the output of apt-get upgrade and apt-get
> --show-upgraded upgrade:

It is the default since 0.5.10 in 2003:

commit 906fbf8886926eeb302332d997c9bd861291e155
Author: Arch Librarian 
Date:   Mon Sep 20 17:03:21 2004 +

* Make APT::Get::Show-Upgraded (aka apt-get -u) default...
Author: mdz
Date: 2003-08-22 02:46:09 GMT
* Make APT::Get::Show-Upgraded (aka apt-get -u) default to true.


(Unfortunately, we did not convert the Arch Librarian commits sanely
 when we moved APT from bzr to git, otherwise we'd have real author
 and date at the top)


-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#824466: RFS: setop/0.1-1 [ITP]

[Frank Stähr]

Package: sponsorship-requests
Severity: wishlist


Dear mentors,


I am looking for a sponsor for my package "setop":

 * Package name: setop
   Version : 0.1-1
   Upstream Author : Frank Stähr
 * URL : 
 * License : GPL-2+
   Section : utils


This mail is just for administration, as my last try didn’t open an RFS bug.

Bug#824467: [INTL:da] Danish translation of the debconf templates debian-security-support

[Joe Dalton]

Package: debian-security-support
Severity: wishlist
Tags: l10n patch

Please include the attached Danish debian-security-support translation

joe@pc:~/over/debian/debian-security-support$ msgfmt --statistics -c -v -o 
/dev/null da.po
da.po: 7 oversatte tekster.


bye
Joe

da.po.tar.gz
Description: application/gzip

Bug#824466: RFS: setop/0.1-1 [ITP]

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

that one is good.

So, please ping me and remove the moreinfo tag when you fixed the issues 
pointed on -mentors mail list!

thanks

G.




Il Lunedì 16 Maggio 2016 13:02, Frank Stähr  ha scritto:
Package: sponsorship-requests
Severity: wishlist


Dear mentors,


I am looking for a sponsor for my package "setop":

  * Package name: setop
Version : 0.1-1
Upstream Author : Frank Stähr
  * URL : 
  * License : GPL-2+
Section : utils


This mail is just for administration, as my last try didn’t open an RFS bug.

Bug#823828: phpmyadmin: fails to show login form (Uncaught TypeError: Cannot read property 'parentNode' of null)

[Michal Čihař]

Hi

Dne 9.5.2016 v 14:06 Alexandre Rossi napsal(a):
> This bug (which is fixed upstream[1]) has wasted some time ofr me, maybe it
> could be fixed in the next stable update.
> 
> Thanks,
> 
> Alexandre
> 
> [1] https://github.com/phpmyadmin/phpmyadmin/issues/11812

The upstream fix proven to be quite problematic, see:

*
https://github.com/phpmyadmin/phpmyadmin/commit/5b76c5eddfac79727ee39be91aed9ad8b57aa887
* https://github.com/phpmyadmin/phpmyadmin/issues/11820
* https://github.com/phpmyadmin/phpmyadmin/issues/11827

Not sure I found all related issues. How frequent do you hit this
problem? The upstream report seems that it's not that likely to hit this
bug...

-- 
Michal Čihař | http://cihar.com/ | https://weblate.org/



signature.asc
Description: OpenPGP digital signature

Bug#824468: [INTL:da] Danish translation of the debconf templates pluxml

[Joe Dalton]

Package: pluxml
Severity: wishlist
Tags: l10n patch

Please include the attached Danish pluxml translation

joe@pc:~/over/debian/pluxml$ msgfmt --statistics -c -v -o /dev/null da.po
da.po: 46 oversatte tekster.

bye
Joe

da.po.tar.gz
Description: application/gzip

Bug#824385: debian/initramfs-tools.bash-completion: Wrong path after 56dfe39 (breaks completion)

[Stephan Sürken]

Hi Ben,

On So, 2016-05-15 at 11:02 +0100, Ben Hutchings wrote:

(...)

> > (not sure why 'dh_bash-completion' eats this in the 1st place,
> > though;):
> It actually installs debian/initramfs-tools.bash-completion rather
> than
> the files listed there.  This is... not very helpful.  It's sort-of
> documented, though there seems to be no validation of what is a
> 'proper
> completion snippet'.

ok, I see... And I also just found Bug #785271 on exactly that ;).

(...)
> > -bash_completion.d/initramfs-tools
> > +bash_completion.d/update-initramfs
> Applied, thanks.

Thanks Ben!

S

Bug#824456: please clarify --show-upgraded and Apt::Get::Show-Upgraded

[Marc Haber]

On Mon, May 16, 2016 at 12:57:09PM +0200, Julian Andres Klode wrote:
> On Mon, May 16, 2016 at 12:35:01PM +0200, Marc Haber wrote:
> > Package: apt
> > Version: 1.2.12
> > Severity: minor
> > File: /usr/bin/apt-get
> > 
> > Hi,
> > 
> > for ages, I had Apt::Get::Show-Upgraded in my apt configuration. While
> > cleaning up, I tried to investigate what it does. After removing, I
> > have not noticed any difference in apt/apt-get behavior. And, I don't
> > see any difference in the output of apt-get upgrade and apt-get
> > --show-upgraded upgrade:
> 
> It is the default since 0.5.10 in 2003:
> 
> commit 906fbf8886926eeb302332d997c9bd861291e155
> Author: Arch Librarian 
> Date:   Mon Sep 20 17:03:21 2004 +
> 
> * Make APT::Get::Show-Upgraded (aka apt-get -u) default...
> Author: mdz
> Date: 2003-08-22 02:46:09 GMT
> * Make APT::Get::Show-Upgraded (aka apt-get -u) default to true.
> 
> 
> (Unfortunately, we did not convert the Arch Librarian commits sanely
>  when we moved APT from bzr to git, otherwise we'd have real author
>  and date at the top)

Thansk for clarifying this.

Is there a corresponding --no-show-upgraded option to apt-get? Does
still having the --show-upgraded option still make sense?

Greetings
Marc

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

Bug#824469: should remove old (jessie) configs that produce duplicates

[Evgeni Golov]

Package: icinga2-common
Version: 2.4.7-1
Severity: important

Hi,

sev:important as this breaks the upgrade from Jessie to Stretch.

icinga2-common (2.1.1-1) in Jessie ships the following files:
/etc/icinga2/conf.d/hosts/localhost.conf
/etc/icinga2/conf.d/hosts/localhost/apt.conf
/etc/icinga2/conf.d/hosts/localhost/disk.conf
/etc/icinga2/conf.d/hosts/localhost/http.conf
/etc/icinga2/conf.d/hosts/localhost/icinga.conf
/etc/icinga2/conf.d/hosts/localhost/load.conf
/etc/icinga2/conf.d/hosts/localhost/procs.conf
/etc/icinga2/conf.d/hosts/localhost/ssh.conf
/etc/icinga2/conf.d/hosts/localhost/swap.conf
/etc/icinga2/conf.d/hosts/localhost/users.conf

These are not present in in the Stretch version (2.4.7-1) anymore.

But the Stretch version ships a /etc/icinga2/conf.d/services.conf which
will apply e.g. ssh to all Linux machines, and that clashes with 
/etc/icinga2/conf.d/hosts/localhost/ssh.conf and leads to a failed
icinga2 service restart.

Please remove those files on upgrade if they were not modified.

Greets
Evgeni

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

Kernel: Linux 4.5.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)

Bug#824465: littler: FTBFS in testing

[Dirk Eddelbuettel]

On 16 May 2016 at 12:58, Santiago Vila wrote:
| Package: src:littler
| Version: 0.3.0-2
| Severity: serious
| 
| Dear maintainer:
| 
| This package currently fails to build from source in stretch:
| 
| 
| make[1]: Entering directory '/<>/src'
| gcc -std=gnu99 -o r -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_S
| OURCE=2 -g -I/usr/share/R/include littler.c  -Wl,--export-dynamic -fopenmp  
-L/usr/lib/R/lib -lR -lpcre -llzm
| a -lbz2 -lz -lrt -ldl -lm -licuuc -licui18n -lblas -llapack 
-Wl,-rpath,/usr/lib/R/lib -Wl,-rpath,/usr/lib/x86
| _64-linux-gnu -Wl,-rpath,/usr/lib/jvm/default-java/jre/lib/amd64/server 
-Wl,-rpath,/usr/lib/R/lib -Wl,-rpath,
| /usr/lib/x86_64-linux-gnu 
-Wl,-rpath,/usr/lib/jvm/default-java/jre/lib/amd64/server 
-Wl,-rpath,/usr/lib/R/lib
|  -Wl,-rpath,/usr/lib/x86_64-linux-gnu 
-Wl,-rpath,/usr/lib/jvm/default-java/jre/lib/amd64/server -Wl,-rpath,/u
| sr/lib/x86_64-linux-gnu/libfakeroot -Wl,-rpath,/usr/lib64/libfakeroot 
-Wl,-rpath,/usr/lib32/libfakeroot 
| /usr/bin/ld: cannot find -licuuc
| /usr/bin/ld: cannot find -licui18n
| collect2: error: ld returned 1 exit status
| Makevars:29: recipe for target 'r' failed
| 

I just rebuilt, adding libicu-dev to Build-Depends (and will add to
r-base-dev where it belongs; longs like R added this) and get

make[1]: Entering directory '/build/littler-0.3.0/src'
gcc -std=gnu99 -o r -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-I/usr/share/R/include littler.c  -Wl,--export-dynamic -fopenmp  
-L/usr/lib/R/lib -lR -lpcre -llzma -lbz2 -lz -lrt -ldl -lm -licuuc -licui18n 
-lblas -llapack -Wl,-rpath,/usr/lib/R/lib -Wl,-rpath,/usr/lib/x86_64-linux-gnu 
-Wl,-rpath,/usr/lib/jvm/default-java/jre/lib/amd64/server 
-Wl,-rpath,/usr/lib/R/lib -Wl,-rpath,/usr/lib/x86_64-linux-gnu 
-Wl,-rpath,/usr/lib/jvm/default-java/jre/lib/amd64/server 
-Wl,-rpath,/usr/lib/R/lib -Wl,-rpath,/usr/lib/x86_64-linux-gnu 
-Wl,-rpath,/usr/lib/jvm/default-java/jre/lib/amd64/server 
-Wl,-rpath,/usr/lib/x86_64-linux-gnu/libfakeroot 
-Wl,-rpath,/usr/lib64/libfakeroot -Wl,-rpath,/usr/lib32/libfakeroot 

So all good.  Will ship a 0.3.0-3 fixing this. And fix r-base-dev.

Thanks for the report.

Dirk
 
| The full build log is attached.
| 
| Thanks.
| x[DELETED ATTACHMENT littler_0.3.0-2_amd64-20160516-1238.gz, application/gzip]

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#602861: upstream available + source package updates

[Lee Garrett]

Hi Andreas,

I'm currently going through my old bug reports, and noticed this gem :). pppoe
3.11 is available now. Looking at the bug reports for src:rp-pppoe, this
package is probably not quite getting the attention it could. Would you
sponsor an updated version of rp-pppoe if I prepare it?

Thanks in advance,
Lee

Bug#822325: [Pkg-rust-maintainers] Bug#822325: rustc: FTBFS in testing: test fail

[Santiago Vila]

On Sat, 14 May 2016, Luca BRUNO wrote:

> I just reproduced it via `systemd-run --scope -p TasksMax=512
> ./tcp-stress`.  Part of it is due to the tcp-stress test not
> checking for spawned thread, I've just submitted a PR to make that
> failure explicit: https://github.com/rust-lang/rust/pull/33640

Thanks a lot! Even if this is officially more a bug in systemd than a
bug in rustc, it's always a good thing that error messages are helpful
and explain what's the problem.

> If your sbuild is running as a daemon or in any other dedicated way, I think 
> you should ask for its TasksMax setting to be increased.

Yes, or just wait for syetemd 229-6 to enter testing.

The old default for TasksMax was not good for everybody (this FTBFS
problem is an example) so they have set it to infinity in systemd.

So I did the same in my hand-made autobuilder (which is triggered by
cron) to avoid this happening again.

Thanks.

Bug#824405: evince: scrollbar regression with libgtk-3-0 3.20

[Jason Crain]

On Sun, May 15, 2016 at 07:23:18PM +0200, Jörg-Volker Peetz wrote:
> Jason Crain wrote on 05/15/16 19:08:
> > On Sun, May 15, 2016 at 05:47:14PM +0200, Jörg-Volker Peetz wrote:
> >> keeping it sober, I use just openbox + lxpanel, no desktop theme set. In
> >> ~/.config/gtk-3.0/gtk.css I have, beside some color settings, these 
> >> defined:
> >>
> >> .scrollbar {
> >>   -GtkScrollbar-has-backward-stepper: true;
> >>   -GtkScrollbar-has-forward-stepper: true;
> >> }
> >> .scrollbar.trough {
> >>   background-color: Thistle2;
> >> }
> >>
> >> Concerning Adwaita or themes, all dependencies of libgtk-3-common are 
> >> installed.
> > 
> > The steppers have been missing from the default gnome theme for a while,
> > so this is more about how your css override has stopped working, right?
> > 
> 
> Yes.
> With gtk-3 3.18 this configuration works.
> I also see this problem with emacs24 and with the firefox version linked 
> against
> gtk-3.
> I wasn't able to find something helpful in the web.

They've changed the syntax of the CSS.  I think the new equivalent for
that is:

scrollbar {
  -GtkScrollbar-has-backward-stepper: true;
  -GtkScrollbar-has-forward-stepper: true;
  background-color: Thistle2;
}

And you might try setting the environment variable GTK_OVERLAY_SCROLLING=0

Bug#824470: DDPO: add last-upload and Standards-Version columns

[Joao Eriberto Mota Filho]

Package: qa.debian.org
Severity: wishlist

Dear Maintainer,

Please, add last-upload and Standards-Version columns. These columns will
provide an easiest mode to find and help very old packages, discover visually
MIA maintainers, predict future problems, etc.

For Standards-Version my suggestion for name is Std.

Thanks in advance.

Regards,

Eriberto

Bug#824446: redshift: There is no documentation on where to place a config file

[Karl O. Pinc]

On Mon, 16 May 2016 15:11:36 +0530
Ritesh Raj Sarraf  wrote:

> On Sun, 2016-05-15 at 22:00 -0500, Karl O. Pinc wrote:

> > The package includes a sample config file, but contains
> > no information on where to put it.  Where does the config
> > file go?  
> 
> Actually, I just checked at realized that there is a section 5
> manpage with the same name.

Thanks.  That manpage does say "~/.config/redshift.conf".
(It's not enough to know the filename.  The directory is key too.)

> But I agree with your bug report. IMO, it should be redshift.conf or
> something like that.

It may be enough to put a line like:

# Found in ~/.config/redshift.conf

at the top of the sample config file.


Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#824419: cups-filters: Please document pdfAutorotate in the README

[Brian Potkin]

On Sun 15 May 2016 at 19:20:19 +0100, Brian Potkin wrote:

> Although pdfAutorotate was introduced in cups-filters 1.0.25 it is not
> documented anywhere. I would suggest the README is as good a place as
> any. My suggestion is:
> 
>   A PDF file containing pages with page width greater than page height
>   (a landscape page) has such pages automatically rotated anticlockwise
>   by 90 degrees. To turn off the feature on a job-for-job basis use
> 
> lp -d  -o nopdfAutorotate 
> 
>   On a per queue basis use
> 
> -o nopdfAutorotate
> 
>   as an option to lpadmin.  
> 
>   Note that the 'landscape' and 'orientation-requested=4' options of
>   CUPS take precedence and are applied before 'pdfAutorotate' or
>   'nopdfAutorotate'.

The suggestion doesn't quite match the reality of cups-filters 1.0.83.
A corrected patch is:

A PDF file containing pages with page width greater than page height
(a landscape page) has such pages automatically rotated anticlockwise
by 90 degrees unless the PPD file has a *LandscapeOrientation line
saying 'Minus90', which results in a 90 degree rotation clockwise. To
turn off the feature on a job-for-job basis use

  lp -d  -o nopdfAutorotate 

On a per queue basis use

  -o nopdfAutorotate

as an option to lpadmin.

Note that the 'landscape' and 'orientation-requested=4' options of
CUPS take precedence and are applied before 'pdfAutorotate' or
'nopdfAutorotate'.

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

Le 16/05/2016 12:40, Gianfranco Costamagna a écrit :
> control: tags -1 moreinfo
>
> Hi Eric, some questions on the changes:
> 1) why do you need both autotools-dev and autoreconf?
Well autotools-dev already used. No changes here.
About autoreconf, I'm not familiar with it.
I installed it to test it. Since all seems ok, I've not removed it.

>
> 2) did you get an ack from maintainers to add yourself as uploader
Yes.
In addition, I've just asked them to post their ask on this list now.

>
>
> 3) +Replaces: gnustep-common (<< 2.6.8-1)
>
> this is something I don't understand.
 If you upgrade gnustep make bin package with old gnustep-common installed,
 we need to replace the gnustep-config.1 manpage.


>
> also, the control.in file removal is not documented I guess
Yes, this is a consequence of the debian/rules rewriting.
>
> maybe Aron (ccd), being the latest sponsor might give you an additional 
> review and sponsor the package

Thanks for the tip.


>
> thanks for the really nice work! 
Thanks, I worked hard last week with upstream.
> I did a test build and the build logs looks good to be, as well as the built
> binaries (however I didn't install them).
I tested it with latest upstream version of gnustep-base, gnustep-gui
and and gnustep-back,
 and all seems okay. I
 tried it with several GNUstep related debian packages and all seems to
works fine.
 I also tried to rebuild several debian gnustep packages with it and I
did not find any FTBFS.

Eric

Bug#821714: src:simplepie: PHP 7.0 Transition

[Tanguy Ortolo]

Tanguy Ortolo, 2016-05-16 12:39+0200:
As I maintain dokuwiki which depends on php-simplepie, I am concerned 
by this. I will try to NMU this.


NMU done, without delay considering this is an RC bug.  Marcelo, I have 
put my changes on a Git repository of mine, so you want you can merge 
them at your convenience, with:


   $ git pull https://git.ortolo.eu/git/contrib-pkg-simplepie.git

Librement,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#824262: Fwd: Re: gnustep-make ack

[Eric Heintzmann]

Ack from Gurkan.
Yavor doesn't reply to email.

 Message transféré 
Return-Path:gur...@phys.ethz.ch
Received:   from zimbra89-e15.priv.proxad.net (LHLO
zimbra89-e15.priv.proxad.net) (172.20.243.140) by
zimbra89-e15.priv.proxad.net with LMTP; Mon, 16 May 2016 13:52:13 +0200
(CEST)
Received:   from phd-imap.ethz.ch (mx15-g26.priv.proxad.net
[172.20.243.85]) by zimbra89-e15.priv.proxad.net (Postfix) with ESMTP id
BFD2E3085DC for ; Mon, 16 May 2016 13:52:12
+0200 (CEST)
Received:   from phd-imap.ethz.ch ([129.132.80.51]) by mx1-g20.free.fr
(MXproxy) with ESMTPS for heintzmann.e...@free.fr (version=TLSv1/SSLv3
cipher=AES256-GCM-SHA384 bits=256); Mon, 16 May 2016 13:52:09 +0200 (CEST)
X-ProXaD-SC:state=HAM score=0
Received:   from localhost (phd-mailscan.ethz.ch [192.168.127.2]) by
phd-imap.ethz.ch (Postfix) with ESMTP id 3r7f2h1CwNzjc2 for
; Mon, 16 May 2016 13:52:12 +0200 (CEST)
X-Virus-Scanned:Debian amavisd-new at phys.ethz.ch
Received:   from phd-mxin.ethz.ch ([IPv6::::192.168.127.53]) by
localhost (phd-mailscan.ethz.ch [:::192.168.127.2]) (amavisd-new,
port 10024) with LMTP id fFYxFNg-qXuB for ;
Mon, 16 May 2016 13:52:12 +0200 (CEST)
Received:   from [10.0.1.14] (84-73-61-124.dclient.hispeed.ch
[84.73.61.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256
bits)) (No client certificate requested) (Authenticated sender:
gur...@phd-mxin.ethz.ch) by phd-mxin.ethz.ch (Postfix) with ESMTPSA id
3r7f2h0CRBzQ50 for ; Mon, 16 May 2016 13:52:12
+0200 (CEST)
From:   Gürkan Myczko 
Content-Type:   text/plain; charset=utf-8
Content-Transfer-Encoding:  quoted-printable
Mime-Version:   1.0 (1.0)
Subject:Re: gnustep-ameke ack
Message-Id: <4397053c-73d5-4402-adc6-8f5c8fa5f...@phys.ethz.ch>
Date:   Mon, 16 May 2016 13:52:11 +0200
References: <5739ae33.40...@free.fr>
In-Reply-To:<5739ae33.40...@free.fr>
To: Eric Heintzmann 
X-Mailer:   iPhone Mail (13F68)



Hi eric

I am glad if you do so, thank you!

Gürkan


> On May 16, 2016, at 13:25, Eric Heintzmann  wrote:
> 
> Hi Gurkan,
> 
> Can you give an ack to add myself as uploader of gnustep-make ? At:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824262
> 
> Thanks
> 
> Eric
> 

Bug#824471: context: luatex finds an undefined control sequence in conf file

[Giacomo Boffi]

Package: context
Version: 2015.05.18.20150601-2
Severity: normal

Dear Maintainer,

I was installing context and apt-get printed

> Setting up context (2015.05.18.20150601-2) ...
> Running mtxrun --generate. This may take some time... done.
> Pregenerating ConTeXt MarkIV format. This may take some time...

It took a while, so I started another activity and, a few hours later,
when I came back to the terminal running apt-get, I still read

> Pregenerating ConTeXt MarkIV format. This may take some time...

some time is ok, a few hours is too much so I looked for the process
that was running forever and I found  it was

  luatex --ini --lua=/usr/share/texmf/tex/context/base/luat-cod.lua
/usr/share/texmf/tex/context/base/cont-en.mkiv dump

I killed it, and the installation continued and ended, with message

> W: Operation was interrupted before it could finish

I tried to run the command I've killed from the admin prompt

% luatex --ini --lua=/usr/share/texmf/tex/context/base/luat-cod.lua
/usr/share/texmf/tex/context/base/cont-en.mkiv dump
This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian)  (INITEX)
 system commands enabled.
(/usr/share/texmf/tex/context/base/cont-en.mkiv
(/usr/share/texmf/tex/context/base/context.mkiv
(/usr/share/texmf/tex/context/base/syst-ini.mkiv
! Undefined control sequence.
l.1020 \pdfoutput
 \zerocount
?

and I had to kill also this process too...

Thank you in advance
 gb


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

Kernel: Linux 4.5.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 context depends on:
ii  dpkg1.18.7
ii  lmodern 2.004.5-3
ii  ruby1:2.3.0+4
ii  ruby2.2 [ruby-interpreter]  2.2.4-1
ii  ruby2.3 [ruby-interpreter]  2.3.1-1
ii  tex-common  6.05
ii  tex-gyre20150923-3
ii  texlive-base2016.20160512-1
ii  texlive-binaries2016.20160513.41080-1
ii  texlive-metapost2016.20160512-1

Versions of packages context recommends:
ii  context-modules   20150601-2
pn  fonts-freefont
ii  fonts-gfs-artemisia   1.1-5
ii  fonts-gfs-baskerville 1.1-5
ii  fonts-gfs-bodoni-classic  1.1-5
ii  fonts-gfs-didot   1.1-6
ii  fonts-gfs-didot-classic   1.1-5
ii  fonts-gfs-gazis   1.1-5
ii  fonts-gfs-neohellenic 1.1-6
ii  fonts-gfs-olga1.1-5
ii  fonts-gfs-porson  1.1-6
ii  fonts-gfs-solomos 1.1-5
ii  fonts-gfs-theokritos  1.1-5
ii  fonts-sil-gentium 20081126:1.03-1

Versions of packages context suggests:
ii  context-doc-nonfree  2012.06.27-4
ii  context-nonfree  2007.03.22-1
ii  fontforge20120731.b-7.2
ii  libxml-parser-perl   2.44-1+b1
ii  perl-tk  1:804.033-1+b2

-- no debconf information

Bug#824428: cinnamon: touchpad scrolling defaults now to reversed order?

[Margarita Manterola]

Hi!

El Domingo 15 Mayo 2016 22:33 CEST, Christoph Anton Mitterer 
 Ha escrito:
> While this is nice, it seems to be default to the reversed order.
> Any reason for that?
> The old behaviour seemed to be more intuitive...

The reason is that upstream maintainers have decided that they want this
as the default... Apparently, other non-free operating systems are using
this as the default (influenced by smartphones and tablets) and so some
maintainers are also switching the default.

I agree with you that this is not intuitive and that it's not a nice thing to
change the default for a user when doing an upgrade.  We will be reverting
the default to the classic scrolling mode in the next upload.

Thanks for the report!

--
Marga

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

>> also, the control.in file removal is not documented I guess
> Yes, this is a consequence of the debian/rules rewriting.
I mean I've removed control target in debian/rules file,
thus I removed control.in which was not needed any longer.

Thanks
Eric

Bug#824472: torch3: please make the build reproducible (fileordering)

[Alexis Bienvenüe]

Source: torch3
Version: 3.1-2.1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

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

The attached patch fixes the order in which *.o files are merged. Once
applied, torch3 can be built reproducibly in our current experimental
framework.

Regards,
Alexis Bienvenüe.

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




--- Makefile.modules.orig
+++ Makefile.modules
@@ -14,9 +14,9 @@
 
 $(LIBTORCH): $(STATICOBJS)
 	@echo "Archiving..."
-	$(AR) $(LIBTORCH) $(STATICOBJSDIR)/*.o
+	$(AR) $(LIBTORCH) $(sort $(wildcard $(STATICOBJSDIR)/*.o))
 $(LIBSOTORCH): $(DYNAMICOBJS)
-	$(CC) -shared -Wl,-soname=libtorch.so.3 -o $(LIBSOTORCH) $(DYNAMICOBJSDIR)/*.o
+	$(CC) -shared -Wl,-soname=libtorch.so.3 -o $(LIBSOTORCH) $(sort $(wildcard $(DYNAMICOBJSDIR)/*.o))
 	
 
 $(OBJS_DIR)/static/%.o: %.cc

Bug#412060: Reply:

[MonicaBrown]

RE: Reply;

fw..docx
Description: Binary data

Bug#798102: ams: Lots of kworker activity after wake from hibernate on Powerbook

[Michael Hanselmann]

On 15.05.2016 21:06, Michael Hanselmann wrote:
> I'll try to give it another spin on a PowerBook6,8 with the I2C version
> of the sensor

Sadly the machine does not wake up in a usable state from hibernation
with linux-image-powerpc 4.5+72~bpo8+1 (also after blacklisting the ams
module). Memory pages are restored, and the caps lock key appears to
work, but the backlight remains turned off and the barely-visible UI is
nonresponsive.

This is clearly outside the scope of ams and I unfortunately do not have
the resources to go deeper.

Michael



signature.asc
Description: OpenPGP digital signature

Bug#824358: ITP: freerdp2 -- RDP client/server for Windows Terminal Services

[Andreas Henriksson]

Hello Mike Gabriel.

Thanks for looking at packaging a newer freerdp snapshot! I have
some questions and doubts below...

On Sun, May 15, 2016 at 12:53:07AM +0200, Mike Gabriel wrote:
[...]
> * Package name: freerdp2
>   Version : 2.x (Git snapshot)
[...]
>  The new major upstream version (well, upstream is not tagging versions,
>  but we have one upstream dev on the packaging team who recommends Git
>  snapshots) provides new ABI/API. This new source will supercede the
>  currently available Debian source package "freerdp".

With new API/ABI a transition is needed (and hopefully upstream properly
handles SONAME despite not doing releases), but renaming the source
package is not normally how you do a transition.

>  .
>  From now on, upstream will support parallel installations of multiple
>  major upstream releases.

This bit is quite confusing as you just said upstream doesn't do releases.

>  So shipping both FreeRDP versions in Debian unstable for a while is
>  possible.

Given the lack of followup on existing bug reports do you really
think you have the resources to support multiple versions?!

Please explain a bit more about how you intend to support multiple
versions? For example how do you intend to handle the naming
of pkg-config files, rename or make the -dev packages conflict?

>  However, only freerdp2 will be made available in Debian 9.

Apparently not and you seem to underestimate the amount of work
needed to get something removed from the archive! Are you sure
you'll manage to get down to only one version again before the
stretch release? How?
As mentioned renaming the source package is not how you normally do a
transtion (only when you want to support multiple versions which you
apparently don't want). Please consider handling this like a normal
transition.

>  .
>  Packages depending on FreeRDP shared libraries should start migrating
>  their packages to the new ABI/API for FreeRDP 2.x.

Again, please share some information on how you intend to package
to make it possible to prepare. Likely you're creating extra work
here when not following the normal transition workflow.

>  .
>  A transition bug will be file for monitoring this change-over,
>  once the freerdp2 src:package has landed in unstable.

An automatic tracker would be available on
https://release.debian.org/transitions/
if you followed the normal transition workflow which would be
even better.

Looking forward to hearing more details about your plans to be able to
prepare for the transition.

Regards,
Andreas Henriksson

Bug#823773: jhighlight: FTBFS: [javadoc] javadoc: error - The -encoding option may be specified no more than once.

[Emmanuel Bourg]

Control: reassign -1 ant
Control: affects -1 jhighlight

This is a bug caused by the patch to make the javadocs reproducible in
ant/1.9.7-1. jhighlight sets the javadoc encoding with an extra argument
() instead of the 'encoding' attribute of the
javadoc task, and the patch doesn't handle this case.

Bug#824435: please enable CONFIG_EXYNOS_VIDEO

[Steinar H. Gunderson]

On Mon, May 16, 2016 at 11:14:26AM +0200, Steinar H. Gunderson wrote:
> On a guess, the relevant parts would probably be
> 
>   CONFIG_EXYNOS_VIDEO=m
>   CONFIG_EXYNOS_MIPI_DSI=m
>   CONFIG_DRM_EXYNOS=m
>   CONFIG_DRM_EXYNOS_MIXER=y  [not in that config, but _HDMI depends on it]
>   CONFIG_DRM_EXYNOS_FIMD=y
>   CONFIG_DRM_EXYNOS_DSI=y
>   CONFIG_DRM_EXYNOS_DP=y
>   CONFIG_DRM_EXYNOS_HDMI=y
>   CONFIG_PHY_EXYNOS_MIPI_VIDEO=m
>   CONFIG_PHY_EXYNOS_DP_VIDEO=m
> 
> There are also power management settings that I believe might be useful
> (not related to display):
> 
>   CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU=y
>   CONFIG_ARM_EXYNOS_CPUIDLE=y
> 
> and I guess also
> 
>   CONFIG_EXYNOS_ADC=m

CONFIG_ARM_EXYNOS_CPUIDLE=y seems to cause problems, so I turned that off.
Apart from that, setting the variables above on 4.6.0 gives me wonderful
fbcon on the XU4.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#819291: pitivi: 0.95-1+b1 segfaults against gtk+3.0 3.20

[Ville Korhonen]

Hi,

On Tue, 29 Mar 2016 10:05:25 +0300 Sebastian =?ISO-8859-1?Q?Dr=F6ge?= <
sl...@debian.org> wrote:
> On Mo, 2016-03-28 at 22:52 -0700, Marc J. Driftmeyer wrote:
> >Â
> > Program received signal SIGABRT, Aborted.
> > 0x76d04478 in __GI_raise (sig=sig@entry=6) at
> > ../sysdeps/unix/sysv/linux/raise.c:55
> > 55Â Â Â  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> > (gdb)
>
> Now just run "bt" after the crash to get a backtrace. You might have to
> install debug packages for various libraries.
>
> Also this time you got an assertion, not a segfault.

I also had segmentation fault (start Pitivi, click "New" (project)),
backtrace attached below. This is with Pitivi 0.95-1+b1 on testing/stretch.

pitivi:
  Installed: 0.95-1+b1
  Candidate: 0.95-1+b1
  Version table:
 *** 0.95-1+b1 500
500 http://httpredir.debian.org/debian stretch/main amd64 Packages
350 http://httpredir.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
 0.93-4.2 500
500 http://httpredir.debian.org/debian jessie/main amd64 Packages

libgtk-3-0:
  Installed: 3.20.4-1
  Candidate: 3.20.4-1
  Version table:
 *** 3.20.4-1 500
500 http://httpredir.debian.org/debian stretch/main amd64 Packages
350 http://httpredir.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
 3.14.5-1+deb8u1 500
500 http://httpredir.debian.org/debian jessie/main amd64 Packages



Regards,

Ville


$ gdb python3

(gdb) run /usr/bin/pitivi
Starting program: /usr/bin/python3 /usr/bin/pitivi
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe7cbc700 (LWP 31427)]
[New Thread 0x7fffe74bb700 (LWP 31428)]
[New Thread 0x7fffe6cba700 (LWP 31429)]
Missing soft dependency:
- pycanberra not found on the system
-> enables sound notifications when rendering is complete
Missing soft dependency:
- GnomeDesktop not found on the system
-> file thumbnails provided by GNOME's thumbnailers
Missing soft dependency:
- Notify not found on the system
-> enables visual notifications when rendering is complete
[New Thread 0x7fffd2a00700 (LWP 31430)]
Traceback (most recent call last):
  File "/usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/titleeditor.py",
line 394, in tabSwitchedCb
self._connect_signals()
  File "/usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/titleeditor.py",
line 326, in _connect_signals
self.app.gui.viewer.target.connect(
AttributeError: 'NoneType' object has no attribute 'viewer'

(pitivi:31426): GLib-GIO-CRITICAL **: g_action_print_detailed_name:
assertion 'g_action_name_is_valid (action_name)' failed

(pitivi:31426): Gtk-CRITICAL **: gtk_application_set_accels_for_action:
assertion 'detailed_action_name != NULL' failed

(pitivi:31426): GLib-GIO-CRITICAL **: g_action_print_detailed_name:
assertion 'g_action_name_is_valid (action_name)' failed

(pitivi:31426): Gtk-CRITICAL **: gtk_application_set_accels_for_action:
assertion 'detailed_action_name != NULL' failed

(pitivi:31426): GLib-GIO-CRITICAL **: g_action_print_detailed_name:
assertion 'g_action_name_is_valid (action_name)' failed

(pitivi:31426): Gtk-CRITICAL **: gtk_application_set_accels_for_action:
assertion 'detailed_action_name != NULL' failed

(pitivi:31426): GLib-GIO-CRITICAL **: g_action_print_detailed_name:
assertion 'g_action_name_is_valid (action_name)' failed

(pitivi:31426): Gtk-CRITICAL **: gtk_application_set_accels_for_action:
assertion 'detailed_action_name != NULL' failed

(pitivi:31426): Gtk-WARNING **: Allocating size to GtkToggleToolButton
0x1d42b80 without calling gtk_widget_get_preferred_width/height(). How does
the code know the size to allocate?
[New Thread 0x7fffc7b28700 (LWP 31433)]
[New Thread 0x7fffc6d06700 (LWP 31434)]
[New Thread 0x7fffc6505700 (LWP 31435)]
[New Thread 0x7fffc5afe700 (LWP 31436)]
[New Thread 0x7fffc52fd700 (LWP 31437)]
[New Thread 0x7fffc4afc700 (LWP 31438)]
[New Thread 0x7fffa700 (LWP 31439)]
[Thread 0x7fffc5afe700 (LWP 31436) exited]
[Thread 0x7fffa700 (LWP 31439) exited]
[New Thread 0x7fffa700 (LWP 31440)]
[New Thread 0x7fffc5afe700 (LWP 31441)]
[New Thread 0x7fffad529700 (LWP 31442)]
[New Thread 0x7fffacb20700 (LWP 31443)]

(pitivi:31426): Gtk-WARNING **: Allocating size to GtkBox 0x1e243c0 without
calling gtk_widget_get_preferred_width/height(). How does the code know the
size to allocate?

(pitivi:31426): Gtk-WARNING **: Allocating size to
pitivi+viewer+TransformationBox 0x1ce36e0 without calling
gtk_widget_get_preferred_width/height(). How does the code know the size to
allocate?

Program received signal SIGSEGV, Segmentation fault.
0x7fffea942ce1 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
(gdb) bt
#0  0x7fffea942ce1 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1  0x7fffea8f0bf1 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#2  0x765fe060 in ffi_call_unix64 () from
/usr/lib/x86_64

Bug#824473: tcc: error: ',' expected (got "�")

[Valentin Lorentz]

Package: tcc
Version: 0.9.27~git20140923.9d7fb33-3

Hi,

I am trying to build fakechroot (downloaded here:
)
with tcc.

When running make, I get this:

  CC   __lxstat.lo
In file included from __lxstat.c:34:
readlink.h:27: error: ',' expected (got "�")
make[2]: *** [Makefile:804: __lxstat.lo] Error 1


The line readlink.h:27 is:
wrapper_proto(readlink, READLINK_TYPE_RETURN, (const char *, char *,
READLINK_TYPE_ARG3()));



Using gcc instead of tcc works fine.

Regards,
Valentin



signature.asc
Description: OpenPGP digital signature

Bug#824375: Please update to latest upstream

[Dmitry Shachnev]

Control: tags -1 +pending

Hi Julien,

On Sun, May 15, 2016 at 07:57:21AM +0200, Julien Puydt wrote:
> Hi,
>
> could you please upgrade to latest upstream?

The packaging is already available in Git, I want upstream to review my
pull request [1] before doing the upload though.

Also, the upload will target experimental first.

Anything in particular you want from the new release? If it's easily
backportable to 1.3, it may be faster to go that route instead.

[1]: https://github.com/sphinx-doc/sphinx/pull/2532

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#781154: ITP: libphpcpp -- a C++ library for developing PHP extensions

[Tzafrir Cohen]

Update: I needed this library for internal use, and therefore wrote
packaging for it. The result is the branch 'debian' (well, also 'rpm')
in:

https://git.tzafrir.org.il/cgit/php-cpp.git/

Both should build with git-buildpackage (-rpm).

I did not attempt to push my changes to Stretch as the library is
incompatible with PHP7 (At least so far. I haven't asked Upstream yet
about their plans).

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Bug#824471: context: luatex finds an undefined control sequence in conf file

[Norbert Preining]

clone 824471 -1
reassigne -1 texlive-binaries
retitle -1 needs to conflict with context << 2016
thanks

> l.1020 \pdfoutput
>  \zerocount

Indeed, old context and new luatex is not good.

I will upload a newer context soon, and will also upload a texlive-binarie
that conflicts with context.

Thanks

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#823322: please build "systemd-sysusers" binary

[Luca BRUNO]

On Sun, 15 May 2016 14:01:20 +0200 Michael Biebl  wrote:

> Can you clarify a bit more, why exactly rkt needs systemd-sysusers?

rkt (aka stage0) supports several stage1 flavors (the component responsible 
for running the containerized-app/stage2). Debian package currently defaults 
to the "host" stage1 flavor, which will just re-use systemd components from 
the host instead of rebuilding everything from scratch.
 
> Fwiw, I share the same concerns as Felipe about increasing the footprint
> about ~308 kB for everyone, especially since sysusers isn't used
> anywhere else atm.
> Splitting it out is something I'm not keen about either.

If you are concerned about size and don't plan to use systemd-sysusers in the 
near future, what about putting it in the "systemd-container" binary package?
That way it will not clutter minimal setup, but it will be available for other 
consumers (sysusers.d may be skipped for the moment, if nothing else need it).
If at some point you decide to start using it, you can just move it to the 
main binary and activate the service unit.

Cheers, Luca

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

Bug#824475: python-mne: FTBFS: TraitError: The 'input' trait of a QuadricDecimation instance is 'read only'.

[Chris Lamb]

Source: python-mne
Version: 0.11+dfsg-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,

python-mne fails to build from source in unstable/amd64:

  [..]

  copying mne/time_frequency/__init__.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency
  copying mne/time_frequency/_stockwell.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency
  copying mne/time_frequency/ar.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency
  copying mne/time_frequency/tfr.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency
  copying mne/time_frequency/psd.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency
  copying mne/time_frequency/stft.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency
  copying mne/time_frequency/csd.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency
  copying mne/time_frequency/multitaper.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency
  creating build/lib.linux-x86_64-2.7/mne/time_frequency/tests
  copying mne/time_frequency/tests/test_psd.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency/tests
  copying mne/time_frequency/tests/__init__.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency/tests
  copying mne/time_frequency/tests/test_stockwell.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency/tests
  copying mne/time_frequency/tests/test_csd.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency/tests
  copying mne/time_frequency/tests/test_multitaper.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency/tests
  copying mne/time_frequency/tests/test_ar.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency/tests
  copying mne/time_frequency/tests/test_stft.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency/tests
  copying mne/time_frequency/tests/test_tfr.py -> 
build/lib.linux-x86_64-2.7/mne/time_frequency/tests
  creating build/lib.linux-x86_64-2.7/mne/realtime
  copying mne/realtime/__init__.py -> build/lib.linux-x86_64-2.7/mne/realtime
  copying mne/realtime/mockclient.py -> build/lib.linux-x86_64-2.7/mne/realtime
  copying mne/realtime/epochs.py -> build/lib.linux-x86_64-2.7/mne/realtime
  copying mne/realtime/stim_server_client.py -> 
build/lib.linux-x86_64-2.7/mne/realtime
  copying mne/realtime/fieldtrip_client.py -> 
build/lib.linux-x86_64-2.7/mne/realtime
  copying mne/realtime/client.py -> build/lib.linux-x86_64-2.7/mne/realtime
  creating build/lib.linux-x86_64-2.7/mne/realtime/tests
  copying mne/realtime/tests/__init__.py -> 
build/lib.linux-x86_64-2.7/mne/realtime/tests
  copying mne/realtime/tests/test_fieldtrip_client.py -> 
build/lib.linux-x86_64-2.7/mne/realtime/tests
  copying mne/realtime/tests/test_stim_client_server.py -> 
build/lib.linux-x86_64-2.7/mne/realtime/tests
  copying mne/realtime/tests/test_mockclient.py -> 
build/lib.linux-x86_64-2.7/mne/realtime/tests
  creating build/lib.linux-x86_64-2.7/mne/decoding
  copying mne/decoding/__init__.py -> build/lib.linux-x86_64-2.7/mne/decoding
  copying mne/decoding/base.py -> build/lib.linux-x86_64-2.7/mne/decoding
  copying mne/decoding/time_gen.py -> build/lib.linux-x86_64-2.7/mne/decoding
  copying mne/decoding/mixin.py -> build/lib.linux-x86_64-2.7/mne/decoding
  copying mne/decoding/transformer.py -> build/lib.linux-x86_64-2.7/mne/decoding
  copying mne/decoding/ems.py -> build/lib.linux-x86_64-2.7/mne/decoding
  copying mne/decoding/csp.py -> build/lib.linux-x86_64-2.7/mne/decoding
  creating build/lib.linux-x86_64-2.7/mne/decoding/tests
  copying mne/decoding/tests/__init__.py -> 
build/lib.linux-x86_64-2.7/mne/decoding/tests
  copying mne/decoding/tests/test_csp.py -> 
build/lib.linux-x86_64-2.7/mne/decoding/tests
  copying mne/decoding/tests/test_ems.py -> 
build/lib.linux-x86_64-2.7/mne/decoding/tests
  copying mne/decoding/tests/test_transformer.py -> 
build/lib.linux-x86_64-2.7/mne/decoding/tests
  copying mne/decoding/tests/test_time_gen.py -> 
build/lib.linux-x86_64-2.7/mne/decoding/tests
  copying mne/commands/utils.py -> build/lib.linux-x86_64-2.7/mne/commands
  copying mne/commands/mne_coreg.py -> build/lib.linux-x86_64-2.7/mne/commands
  copying mne/commands/__init__.py -> build/lib.linux-x86_64-2.7/mne/commands
  copying mne/commands/mne_make_scalp_surfaces.py -> 
build/lib.linux-x86_64-2.7/mne/commands
  copying mne/commands/mne_browse_raw.py -> 
build/lib.linux-x86_64-2.7/mne/commands
  copying mne/commands/mne_flash_bem.py -> 
build/lib.linux-x86_64-2.7/mne/commands
  copying mne/commands/mne_compute_proj_ecg.py -> 
build/lib.linux-x86_64-2.7/mne/commands
  copying mne/commands/mne_show_fiff.py -> 
build/lib.linux-x86_64-2.7/mne/commands
  copying mne/commands/mne_watershed_bem.py -> 
build/lib.linux-x86_64-2.7/mne/commands
  copying mne/commands/mne_surf2bem.py -> 
build/lib.linux-x86_64-2.7/mne/commands
  copying mne/commands/mne_report.py -> build/lib.linux-x86_64-2.7/mne/commands
  copying mne/commands/mne_maxfilter.py -> 
build/lib.linux-x

Bug#824260: texlive-bin: FTBFS on mips, mipsel & sparc64 due to test failures

[Sebastiaan Couwenberg]

On 05/16/2016 05:34 AM, Norbert Preining wrote:
> I am travelling so I cannot actually test-build it. If someone could do
> a test run, here is a test package that sets the 
>   U_IS_BIG_ENDIAN=0 
> for C(XX)FLAGS on these architectures.
> 
> http://www.preining.info/debian/texlive-bin_2016.20160513.41080-2~1.debian.tar.xz
> http://www.preining.info/debian/texlive-bin_2016.20160513.41080-2~1.dsc
> 
> (.orig.tar.xz is in the normal Debian pool).
> 
> Thanks for any testing

I had to change the the CFLAGS option to use += -DU_IS_BIG_ENDIAN=0
otherwise the build fails because CFLAGS references itself.

With that change the build still fails on mipsel porterbox:

FAIL: luajiterr.test
===
   luajit for TeX Live 2.1.0-beta2: ./test-suite.log
===

# TOTAL: 2
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: luajiterr
===

1,4c1
< ./luajittry: (command line):1: test
< stack traceback:
<   [C]: in function 'error'
<   (command line):1: in main chunk
---
> luajit: attempt to call a function value
FAIL luajiterr.test (exit status: 1)

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#824476: Consider backportgin https://codereview.qt-project.org/#/c/157499/ to Jessie

[Lisandro Damián Nicanor Pérez Meyer]

Source: qtbase-opensource-src
Version: 5.5.1+dfsg-16+b1
Severity: important
Tags: patch

https://codereview.qt-project.org/#/c/157499/ has a patch for timezone handling.
Wait for it to be merged and then try to backport it to Jessie.

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

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

Bug#824260: texlive-bin: FTBFS on mips, mipsel & sparc64 due to test failures

[Norbert Preining]

Hi Bas,

thanks a lot for testing. I there a porter box where I can test
it myself?

> I had to change the the CFLAGS option to use += -DU_IS_BIG_ENDIAN=0
> otherwise the build fails because CFLAGS references itself.

Ahhh, I had the strange feeling that make and bash are different in
this respect ... sorry.

> With that change the build still fails on mipsel porterbox:

Bad, but this is at least a *different* error now, not related to
the ICE and upmendex/xetex, which is a bit better.

Did the test run at least over the upmendex and xetex tests?

What if you disable luajittex by removing it from the 
LUAJIT_GOOD_ARCHS
list? After that it should compile without a problem???Hopefully.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#824435: please enable CONFIG_EXYNOS_VIDEO

[Steinar H. Gunderson]

On Mon, May 16, 2016 at 02:43:06PM +0200, Steinar H. Gunderson wrote:
> CONFIG_ARM_EXYNOS_CPUIDLE=y seems to cause problems, so I turned that off.
> Apart from that, setting the variables above on 4.6.0 gives me wonderful
> fbcon on the XU4.

Scratch that, the culprit was CONFIG_ARM_BIG_LITTLE_CPUIDLE=y.
CONFIG_ARM_EXYNOS_CPUIDLE=y doesn't have issues from what I can see.
However, /sys/devices/system/cpu/cpuidle/current_driver says “none”,
so perhaps it's a noop on this platform. I'd probably leave it out for now.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Gianfranco Costamagna]

Hi Eric,



>Well autotools-dev already used. No changes here.

>About autoreconf, I'm not familiar with it.
>I installed it to test it. Since all seems ok, I've not removed it.


https://wiki.debian.org/Autoreconf

I was talking more about removing autotools-dev

>In addition, I've just asked them to post their ask on this list now.


nice!
>
>
> 3) +Replaces: gnustep-common (<< 2.6.8-1)
>
> this is something I don't understand.
If you upgrade gnustep make bin package with old gnustep-common installed,
we need to replace the gnustep-config.1 manpage.


that file is currently inside gnustep-common

and you moved into gnustep-make
https://packages.debian.org/sid/alpha/gnustep-common/filelist

you probably need some more keywords to ensure a good upgrade path
https://wiki.debian.org/PackageTransition
>Yes, this is a consequence of the debian/rules rewriting.


line 25, you could add something like "remove control.in file, useless now"
or similar wording, that one was my question


>I tested it with latest upstream version of gnustep-base, gnustep-gui
>and and gnustep-back,
>and all seems okay. I
>tried it with several GNUstep related debian packages and all seems to
>works fine.
>I also tried to rebuild several debian gnustep packages with it and I
>did not find any FTBFS.


nice indeed, so please wait some more time, and ping me back in 7-15 days if 
nobody
picked up the work in the meanwhile.

thanks!

Gianfranco

Bug#824427: cinnamon: bell sound appears in all kinds of places

[Margarita Manterola]

Hi!

El Domingo 15 Mayo 2016 22:27 CEST, Christoph Anton Mitterer 
 Ha escrito:
> Not sure whether this can be considered a "bug"...
> Since 3.0, in all kinds of things the "bell" sound appears
> in all kinds of places, where it didn't before...

I believe this is part of an accessibility effort done by upstream.
However, the default is still false as far as I could find.

Can you please show the output of:
dconf read /org/cinnamon/desktop/wm/preferences/audible-bell

> That's quite annoying and I didn't find a way to get rid of
> it via the sound applet,...

As this is an accessibility feature, the setting is located in the
Accessibility settings panel, in the Keyboard tab.

Can you confirm that you had this set to true and that setting it
to false makes this go away?

Thanks.

--
Cheers,
Marga