Bug#815006: Renaming Iceweasel to Firefox

[Stefano Zacchiroli]

On Thu, Feb 18, 2016 at 07:48:25AM +0800, Paul Wise wrote:
> Mozilla's trademark policy isn't clear about how much modification
> requires Mozilla's written consent. Any written consent except for a
> clarification to Mozilla's trademark guidelines would be specific to
> Debian and thus would be in violation of DFSG item 8. Debian cannot
> make agreements with Mozilla about this that don't also apply to all
> distributors of modified versions of Mozilla's software.
> 
> What is the plan to solve this dilemma?

Let's take the worst case scenario: Mozilla's policy gets so extreme
that *every* derived works must be rebranded away from Mozilla's
marks---assuming for a moment that that is something that could be
enforced using trademark law in the first place. Such a policy would be
fine w.r.t. DFSG §4.

If a policy is less clear cut than that (as Mozilla's is), and we
(Debian) decide to use the marks anyhow, what we are doing is a risk
assessment exercise. We consider in good faith that the patches we will
apply will be OK w.r.t. the (unclear) policy and that therefore Mozilla
will not force us to rebrand. But we might be wrong, and Mozilla might
decide to force us to rebrand, which will be a PITA if it has to happen
in stable.

AFAIU there is no formal/contractual guarantee that Mozilla is giving
Debian here, nor they are giving us a trademark license. So DFSG §8 is
respected. Mozilla just recognizes that the kind of work that Debian
Firefox maintainers have done in the past, if continued in the future,
*should* be fine w.r.t. their trademark policy. As per my understanding
of trademark law, and given no trademark license is being given to
Debian, others (including our downstreams) will be able to apply the
same changes to Firefox without being forced to rebrand either.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#815046: owfs-fuse: Crash if fuse options provided

[Matthew Gabeler-Lee]

Package: owfs-fuse
Version: 3.1p1-2
Severity: important
Tags: patch upstream

If you pass --fuse-opt or --fuse-open-opt to the ofws fuse program, it will 
crash.

Submitted upstream as https://sourceforge.net/p/owfs/bugs/69/

Patch to fix this attached

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Contrary to quilt, dpkg-source does not handle correctly various EOL :-(
So, we store the whole diff here
--- a/module/owfs/src/c/fuse_line.c
+++ b/module/owfs/src/c/fuse_line.c
@@ -97,7 +97,7 @@
 	
 	orm.number = 1 ;
 	
-	ow_regcomp( _farg, "^\".+\"$", 0 ) ;
+	ow_regcomp( _farg, "^\"(.+)\"$", 0 ) ;
 	
 	if ( ow_regexec( _farg, opt_arg,  ) != 0 ) {
 		fprintf(stderr, "Put the %s value in quotes. \"%s\"", entryname, opt_arg);

Bug#815045: libmeanwhile1 connection error on 0x56502a049fa0 (reason: 3 description: Login verification down or unavailable) when trying to connect to sametime server

[Andreas Wagner]

Package: libmeanwhile1
Version: 1.0.2-7
 
I use pidgin to connect to our sametime server. When using libmeanwhile1 
version "1.0.2.-7" the following error "connection error on 0x56502a049fa0 
(reason: 3 description: Login verification down or unavailable)" occured. Error 
disappeard after downgraded libmeanwhile1 to version "1.0.2.-4".
 
Failed version:
Package: libmeanwhile1
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 229
Maintainer: Debian QA Group 
Architecture: amd64
Multi-Arch: same
Source: meanwhile
Version: 1.0.2-7
Depends: libc6 (>= 2.14), libglib2.0-0 (>= 2.24.0)
 
version with successfull connection:
Package: libmeanwhile1
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 248
Maintainer: Chris Vanden Berghe 
Architecture: amd64
Source: meanwhile
Version: 1.0.2-4
Depends: libc6 (>= 2.7), libglib2.0-0 (>= 2.24.0)
 
Debian version: 4.3.0-1-amd64 #1 SMP Debian 4.3.3-7 (2016-01-19) x86_64 
GNU/Linux
 
With kind regards,
Andreas Wagner

Bug#810814: libgnutls26: Encrypted LDAP connection doesn't work after libgnutls26 update

[Frederic Van Espen]

Hi Stan,

> are there any news how to fix this problem? I've added "TLSCipherSuite
> NORMAL:!ARCFOUR-128:!3DES-CBC:-VERS-SSL3.0" to my slapd.conf on LDAP server, 
> but it didn't change a
> thing.

In our case, we had to allow more ciphers on the client side. Not on
the server side. The client side was configured with SECURE256. After
removing that things started working again.

Cheers,

Frederic

Bug#815044: python-tidylib: UnicodeDecodeError with call to tidy_document

[Patrice Pillot]

Package: python-tidylib
Version: 0.2.4~dfsg-2
Severity: important
Tags: upstream

Dear Maintainer,

Since I updated my testing box to python-tidylib 0.2.4~dfsg-2, I nearly
can't use rawdog (RSS aggregator) anymore since most feed parsings break with :

Traceback (most recent call last):
  File "_ctypes/callbacks.c", line 314, in 'calling callback function'
  File "/usr/lib/python2.7/dist-packages/tidylib/sink.py", line 79, in put_byte
write_func(byte.decode('utf-8'))
  File "/usr/lib/python2.7/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xa9 in position 0: invalid 
start byte

This is an upstream bug : https://github.com/countergram/pytidylib/issues/11

Hope this helps,

phep

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

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

Versions of packages python-tidylib depends on:
ii  libtidy-0.99-0  20091223cvs-1.5
pn  python:any  

python-tidylib recommends no packages.

python-tidylib suggests no packages.

-- no debconf information

Bug#815026: Reopened for stable RM

[Scott Kitterman]

Unstable rm is done.

Scott K

Bug#815043: gitlab: Failed to start LSB: GitLab git repository management. (systemd)

[Viktor Malyarchuk]

Package: gitlab
Version: 8.4.3+dfsg-8
Severity: normal

Dear Maintainer,

look like gitlab.service is unable to start. Despite the error gitlab is 
functional.

sudo systemctl status gitlab.service
● gitlab.service - LSB: GitLab git repository management
   Loaded: loaded (/etc/init.d/gitlab; bad; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2016-02-16 18:38:10 CST; 1 day 
6h ago
 Docs: man:systemd-sysv-generator(8)
  Process: 661 ExecStart=/etc/init.d/gitlab start (code=exited, 
status=1/FAILURE)

Feb 16 18:38:10 radiance su[677]: Successful su for gitlab by root
Feb 16 18:38:10 radiance su[677]: + ??? root:gitlab
Feb 16 18:38:10 radiance su[677]: pam_unix(su:session): session opened for user 
gitlab by (uid=0)
Feb 16 18:38:10 radiance gitlab[661]: Starting gitlab (via systemctl): 
gitlab.serviceFailed to start gitlab.service: Interactive authentication requi
Feb 16 18:38:10 radiance gitlab[661]: See system logs and 'systemctl status 
gitlab.service' for details.
Feb 16 18:38:10 radiance gitlab[661]:  failed!
Feb 16 18:38:10 radiance systemd[1]: gitlab.service: Control process exited, 
code=exited status=1
Feb 16 18:38:10 radiance systemd[1]: Failed to start LSB: GitLab git repository 
management.
Feb 16 18:38:10 radiance systemd[1]: gitlab.service: Unit entered failed state.
Feb 16 18:38:10 radiance systemd[1]: gitlab.service: Failed with result 
'exit-code'.
lines 1-16/16 (END)

Best regards,
Viktor

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

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

Versions of packages gitlab depends on:
ii  adduser3.113+nmu3
ii  asciidoctor1.5.3-1
ii  bc 1.06.95-9+b1
ii  bundler1.10.6-2
ii  debconf [debconf-2.0]  1.5.58
ii  git1:2.7.0+next.20160112-1
ii  gitlab-shell   2.6.10-1
ii  gitlab-workhorse   0.6.3-1
ii  init-system-helpers1.28
ii  libjs-chartjs  1.0.2-1
ii  libjs-clipboard1.4.2-1
ii  libjs-fuzzaldrin-plus  0.3.1-1
ii  libjs-graphael 0.5+dfsg-1
ii  libjs-jquery-cookie10-2
ii  libjs-jquery-history   10-2
ii  libjs-jquery-nicescroll3.6.6-1
ii  nginx  1.9.10-1
ii  nginx-full [nginx] 1.9.10-1
ii  nodejs 5.6.0~dfsg-1
ii  postgresql 9.5+172
ii  postgresql-client-9.5 [postgresql-client]  9.5.1-1
ii  rake   10.4.2-2
ii  redis-server   2:3.2.0~rc3-1
ii  ruby   1:2.3~0
ii  ruby-ace-rails-ap  3.0.3-2
ii  ruby-activerecord-deprecated-finders   1.0.4-1
ii  ruby-activerecord-session-store0.1.1-3
ii  ruby-acts-as-taggable-on   3.5.0-2
ii  ruby-addressable   2.3.8-1
ii  ruby-after-commit-queue1.3.0-1
ii  ruby-allocations   1.0.3-1
ii  ruby-asana 0.4.0-1
ii  ruby-attr-encrypted1.3.4-1
ii  ruby-babosa1.0.2-1
ii  ruby-bootstrap-sass3.3.5.1-3
ii  ruby-browser   1.0.1-1
ii  ruby-cal-heatmap-rails 3.5.1+dfsg-1
ii  ruby-carrierwave   0.10.0+gh-2
ii  ruby-charlock-holmes   0.7.3+dfsg-2
ii  ruby-coffee-rails  4.1.0-2
ii  ruby-colorize  0.7.7-1
ii  ruby-connection-pool   2.2.0-1
ii  ruby-creole0.5.0-2
ii  ruby-d3-rails  3.5.6+dfsg-1
ii  ruby-default-value-for 3.0.1-1
ii  ruby-devise3.5.2-3
ii  ruby-devise-async  0.9.0-1
ii  ruby-devise-two-factor 2.0.0-1
ii  ruby-diffy 3.0.6-1
ii  ruby-doorkeeper2.2.1-1
ii  ruby-dropzonejs-rails  0.7.1-1
ii  ruby-email-reply-parser0.5.8-1
ii  ruby-fog   1.34.0-2
ii  ruby-fogbugz   0.2.1-2
ii  ruby-font-awesome-rails  

Bug#815042: POSTREMOVE hook fails when removing GOsa user templates

[Mike Gabriel]

Package: debian-edu-config
Severity: important
Version: 1.818

Hi

another issue around GOsa user templates. When removing a GOsa user  
template from LDAP through GOsa, Debian Edu's POSTREMOVE hook  
("gosa-remove") for user object fails.


The issue happens when the post remove hook tries to remove the  
template's home and cannot find it (there is an exit 1 in that hook  
script).


Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de


pgpYzU5vRbCeH.pgp
Description: Digitale PGP-Signatur

Bug#815041: gdpc: implicit function declarations causing errors in build log checks

[Logan Rosen]

Package: gdpc
Version: 2.2.5-4
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Hi,

As you can see in the build log checks for gdpc in Debian [1], the build logs
contain implicit function declarations due to the use of deprecated glib
functions. The implicit declaration of functions can cause problems on 64-bit
architectures, as described here [2].

Implicit function declarations actually cause an FTBFS on 64-bit architectures
in Ubuntu, which prompted the attached patch.

In Ubuntu, the attached patch was applied to achieve the following:

  * Merge from Debian unstable. Remaining changes:
- debian/patches/41_glib_deprecated_funcs.patch: Converted uses of
  deprecated glib functions, fixing FTBFS on 64-bit buildds.

Thanks for considering the patch.

Logan Rosen

[1] https://qa.debian.org/bls/packages/g/gdpc.html
[2] https://wiki.debian.org/ImplicitPointerConversions

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

Kernel: Linux 4.4.0-2-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru gdpc-2.2.5/debian/patches/41_glib_deprecated_funcs.patch gdpc-2.2.5/debian/patches/41_glib_deprecated_funcs.patch
--- gdpc-2.2.5/debian/patches/41_glib_deprecated_funcs.patch	1969-12-31 19:00:00.0 -0500
+++ gdpc-2.2.5/debian/patches/41_glib_deprecated_funcs.patch	2013-12-20 21:16:20.0 -0500
@@ -0,0 +1,44 @@
+Index: gdpc-2.2.5/main.c
+===
+--- gdpc-2.2.5.orig/main.c	2009-04-21 14:03:07.0 -0400
 gdpc-2.2.5/main.c	2013-04-07 21:21:46.208492431 -0400
+@@ -848,9 +848,9 @@
+ #endif
+ 
+   for (i=0;iframeready[i] = g_mutex_new();
++	g_mutex_init (params->frameready[i]);
+ 	g_mutex_lock (params->frameready[i]);
+-	params->framedrawn[i] = g_mutex_new();
++	g_mutex_init (params->framedrawn[i]);
+ 	g_mutex_unlock (params->framedrawn[i]);
+ 	params->framedata[i] = NULL;
+ }
+@@ -860,15 +860,15 @@
+ printf("Initialising filewait/EOF semaphores.\n");
+ #endif
+ 
+-params->filewait = g_mutex_new();
++g_mutex_init (params->filewait);
+ g_mutex_lock (params->filewait);
+-params->atEnd = g_mutex_new();
++g_mutex_init (params->atEnd);
+ 
+ #if Debug 
+ printf("Starting filereading thread.\n");
+ #endif
+ 
+-th_a = g_thread_create ((GThreadFunc) readinput, (gpointer) params, TRUE, NULL);
++th_a = g_thread_try_new ("some_thread", (GThreadFunc) readinput, (gpointer) params, NULL);
+ if (th_a == NULL) {
+ 	fprintf(stderr, "Creating read thread failed.\n");
+ 	gtk_main_quit ();
+@@ -927,8 +927,6 @@
+ /* Start gtk initialization. */
+ gtk_init (, );
+ 
+-g_thread_init(NULL);
+-
+ printf("\n gdpc version "GDPCVER", Copyright (C) 2000 Jonas Frantz\n");
+ printf(" gdpc comes with ABSOLUTELY NO WARRANTY; for details\n");
+ printf(" check out the documentation.  This is free software, and\n"); 
diff -Nru gdpc-2.2.5/debian/patches/series gdpc-2.2.5/debian/patches/series
--- gdpc-2.2.5/debian/patches/series	2016-01-24 15:50:17.0 -0500
+++ gdpc-2.2.5/debian/patches/series	2016-02-18 01:13:27.0 -0500
@@ -1,4 +1,5 @@
 20_Makefile_options.patch
 30_gdk_enable_deprecated.patch
 40_fix_gcc4.8_build.patch
+41_glib_deprecated_funcs.patch
 hardening.patch

Bug#808468: youtube-dl: new upstream 2016.01.23

[Matt Taggart]

I ran into a weird problem using youtube-dl to grab a video from vimeo 
today and I wanted to test a newer version to see if it's fixed. The 
current version on

https://rg3.github.io/youtube-dl/download.html

is 2016.02.13 and reading the git commit lots there are lots of fixes (and 
I had no idea how many sites youtube-dl supported!)

Please update when you can.

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#815040: Creating templates creates home dir "%uid"

[Mike Gabriel]

Package: debian-edu-config
Severity: important
Version: 1.818
Tags: patch

Hi,

when creating new user templates in Debian Edu's GOsa, the hook script  
gosa-create creates a home directory for this new user template. This  
is, of course, nonsense. Only real users need a home directory.


Also, a Kerberos account is created for that user template.

This can be fixed by modifying the search filter in gosa-create's  
ldapsearch in this way:


IS:
(&(uid=$USERID)(objectClass=posixAccount))

SHOULD BE:
(&(uid=$USERID)(objectClass=posixAccount)(!(objectClass=gosaUserTemplate)))

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de


pgpKT1U4zFiAE.pgp
Description: Digitale PGP-Signatur

Bug#815035: RM: trafficserver [armhf] -- RoM; FTBFS

[Adam D. Barratt]

On Thu, 2016-02-18 at 12:44 +0800, Aron Xu wrote:
> Package: ftp.debian.org
> User: release.debian@packages.debian.org
> Usertags: rm
> 
> I'd like to request removal of trafficserver's armhf packages from
> testing, to allow it's migration from unstable, it's not supported by
> upstream anymore.

For reference, you want them removed from /unstable/, in order for the
migration to be possible. (The state in unstable is what matters and in
any case there are no trafficserver packages in testing on _any_
architecture currently.)

Regards,

Adam

Bug#815026: RM: nautilus-pastebin/stable -- ROM; Project abandoned; RC buggy

[Adam D. Barratt]

Control; reassign -1 release.debian.org
Control: tags -1 + jessie pending

On Thu, 2016-02-18 at 00:30 +, Alessio Treglia wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> 
> Hi,
> 
> Please remove nautilus-pastebin from Debian, it should have been removed
> from Jessie before the past freeze to be honest. The project is abandoned,
> upstream does not intend to release any bugfixes or improvements.

{,old}stable removals are managed by the Release Team; reassigning.

Regards,

Adam

Bug#815039: RFS: normaliz 3.1.0+ds-1 [New Upstream Version] -- math computing tools

[Jerome Benoit]

Package: sponsorship-requests
Severity: normal

Dear Mentors:

I am looking for a sponsor for the normaliz package [1], a mathematical package
used by Singular. This package brings to Debian the latest version of normaliz.

Thanks in advance,
Jerome

[1] https://anonscm.debian.org/cgit/debian-science/packages/normaliz.git

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

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (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: sysvinit (via /sbin/init)

Bug#715505: Updated OpenChrome driver available

[Jeffrey Walton]

Hi Everyone,

I tested the updated OpenChrome driver tonight. The driver fixes the
crash I was experiencing under the existing driver.

I would strongly encourage Debian's Xorg team to get this driver into
Unstable or Testing as soon as possible.

Test results:

  * https://bugs.freedesktop.org/show_bug.cgi?id=94130#c4.

Git instructions:

  * 
https://lists.freedesktop.org/archives/openchrome-devel/2016-February/001753.html

Jeffrey Walton

Bug#814962: libreoffice: add support to timestamp servers requiring AUTH

[Fulano Diego Perez]

Rene Engelhard:
> Did you create a bugreport upstream or did you
> only report it here?

just here

Bug#814352: ITP: veracrypt -- Cross-platform on-the-fly encryption

[Mike Gabriel]

Hi Francesco,

On  Mi 17 Feb 2016 21:49:54 CET, Francesco Poli wrote:

On Wed, 17 Feb  
2016https://github.com/mhogomchungu/zuluCrypt/releases/download/4.8.0/zuluCrypt-4.8.0-debian-8-Jessie.tar.xz 11:39:00 + Mike Gabriel  
wrote:



On  Mi 17 Feb 2016 00:17:28 CET, Francesco Poli wrote:



Oh, I am sorry. With this mail, I have attached the latest
debian/copyright file as I have it now after having it reworked two
days ago. I should have sent an updated copy to debian-legal
immediately. Sorry for that.


Mmmmh, I cannot see any attachment. Was it forgotten or lost somehow?



As it seems, the VeraCrypt upstream people have come up with a new
license, the VeraCrypt license. See attached copyright file for details.


Please send the updated debian/copyright file...



Oh, I must have forgotten to attach that file. Here it comes.


And personally, I just tried out
zulucrypt-gui the second time and I could not get it running as
non-root. This is probably possible, I did not spend much time on
this, but honestly, I prefer a solution that works right away. Also
ZuluCrypt feels a little nerdy, not so user friendly as VeraCrypt
currently is.


Mmmmh, I see.


OT here, but for completing info on zuluCrypt:

I just learned from the zuluCrypt upstream maintainer, that  
zuluCrypt-gui will work as non-root user if zuluCrypt-cli and  
zuluMount-cli are installed setuid root, it is just that the Debian  
maintainers of zulucrypt-gui do not set those permissions in their  
packaging. (Though, personally, I agree on not having more setuid root  
executables on a Debian system than absolutely necessary).


Also zuluCrypt offers binary built .deb packages of their code on  
their homepage [1] without shipping a source package alongside. They  
install those mentioned executables as setuid root. So here we have a  
binary blob with no directly referenced source, doing filesystem  
crypto _and_ obtaining root privileges. Sigh...


[1] http://mhogomchungu.github.io/zuluCrypt/

Greets,
Mike


--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: veracrypt
Source: http://sourceforge.net/projects/truecrypt/

Files: *
Copyright: 2003-2011, TrueCrypt Developers Association
   2013-2015, IDRIX
License: VC

Files:  src/Common/Apidrvr.h
src/Common/Cache.*
src/Common/Cmdline.*
src/Common/Combo.*
src/Common/Crc.*
src/Common/Crypto.*
src/Common/Dlgcode.*
src/Common/Endian.*
src/Common/Fat.*
src/Common/Format.*
src/Common/Password.*
src/Common/Pkcs5.*
src/Common/Progress.*
src/Common/Random.*
src/Common/Tcdefs.h
src/Common/Tests.*
src/Common/Volumes.*
src/Core/FatFormatter.cpp
src/Driver/Ntdriver.*
src/Driver/Ntvol.*
src/Format/Tcformat.*
src/Mount/Mount.*
src/Setup/Dir.*
src/Setup/Setup.*
src/Setup/Wizard.*
Copyright: 1998-2000, Paul Le Roux
License: E4M

Files:  src/Common/GfMul.c
src/Common/GfMul.h
src/Crypto/Aescrypt.c
src/Crypto/Aes.h
src/Crypto/Aeskey.c
src/Crypto/Aesopt.h
src/Crypto/AesSmall.c
src/Crypto/AesSmall.h
src/Crypto/AesSmall_x86.asm
src/Crypto/Aestab.c
src/Crypto/Aestab.h
src/Crypto/Aes_x64.asm
src/Crypto/Aes_x86.asm
src/Crypto/Sha2.c
src/Crypto/Sha2.h
src/Crypto/Twofish.c
Copyright: 1998-2007, Brian Gladman, Worcester, UK
License: BSD-3-Clause

Files: src/Boot/Windows/Decompressor.c
Copyright: 2002-2004, Mark Adler
License: zlib

Files: debian/*
Copyright: 2013-2015, Unit 193 
   2016, Mike Gabriel 
License: BSD-3-Clause

License: VC
 VeraCrypt License
 .
 Software distributed under this license is distributed on an "AS IS"
 BASIS WITHOUT WARRANTIES OF ANY KIND. THE AUTHORS AND DISTRIBUTORS OF
 THE SOFTWARE DISCLAIM ANY LIABILITY. ANYONE WHO USES, COPIES, MODIFIES,
 OR (RE)DISTRIBUTES ANY PART OF THE SOFTWARE IS, BY SUCH ACTION(S),
 ACCEPTING AND AGREEING TO BE BOUND BY ALL TERMS AND CONDITIONS OF THIS
 LICENSE. IF YOU DO NOT ACCEPT THEM, DO NOT USE, COPY, MODIFY, NOR
 (RE)DISTRIBUTE THE SOFTWARE, NOR ANY PART(S) THEREOF.
 .
 VeraCrypt is governed by the TrueCrypt License version 3.0, a verbatim
 copy of this version of the TrueCrypt License can be found below.
 .
 Modifications and additions to the original source code (contained in
 this file)  and all other portions of this file are Copyright (c)
 2013-2015 IDRIX and are governed by the Apache License 2.0 the full text
 of which is contained in the file License.txt included in 

Bug#815038: edgar-data: Lots of missing sounds

[Ben Longbons]

Package: edgar-data
Version: 1.21-1
Severity: normal

Dear Maintainer,

When playing this game, there are a lot of errors of the form:

Failed to load sound sound/boss/boulder_boss/roll
Failed to load sound sound/common/rock_shatter

The exact filenames vary depending on which map you're on.

Many of these sounds are played before there is any visible effect,
so not having audible cues has a negative effect on gameplay.

I have not investigated whether something is wrong with Debian's
packaging or whether upstream simply hasn't found any open-source sounds
yet.


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

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

Versions of packages edgar-data depends on:
ii  ttf-dejavu-core  2.35-1

edgar-data recommends no packages.

edgar-data suggests no packages.

-- no debconf information

Bug#815037: "Microcode SW error detected. Restarting ..." every few seconds

[Yaroslav Halchenko]

Package: firmware-iwlwifi
Version: 20160110-1
Severity: normal

I don't remember since when it started but currently it seems to happen under
any load -- it does recover and manages to fetch the load but at slow speeds
and causing delayes, here is what is seen in messages:

Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: Microcode SW error detected. 
 Restarting 0x200.
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: CSR values:
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: (2nd byte of 
CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:CSR_HW_IF_CONFIG_REG: 
0X40489204
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:  CSR_INT_COALESCING: 
0X8000ff40
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: CSR_INT: 
0X
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:CSR_INT_MASK: 
0X
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:   CSR_FH_INT_STATUS: 
0X
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: CSR_GPIO_IN: 
0X
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:   CSR_RESET: 
0X
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:CSR_GP_CNTRL: 
0X080403cd
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:  CSR_HW_REV: 
0X0144
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:  CSR_EEPROM_REG: 
0X
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:   CSR_EEPROM_GP: 
0X8000
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:  CSR_OTP_GP_REG: 
0X803a
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: CSR_GIO_REG: 
0X001f0042
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:CSR_GP_UCODE_REG: 
0X
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:   CSR_GP_DRIVER_REG: 
0X
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:   CSR_UCODE_DRV_GP1: 
0X
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:   CSR_UCODE_DRV_GP2: 
0X
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: CSR_LED_REG: 
0X0060
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:CSR_DRAM_INT_TBL_REG: 
0X8843a242
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:CSR_GIO_CHICKEN_BITS: 
0X27800200
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: CSR_ANA_PLL_CFG: 
0Xd5d5
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:  CSR_MONITOR_STATUS_REG: 
0X3d0801bd
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:   CSR_HW_REV_WA_REG: 
0X0001001a
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:CSR_DBG_HPET_MEM_REG: 
0X0010
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: FH register values:
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 
FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X43add500
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:
FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X043add40
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:  
FH_RSCSR_CHNL0_WPTR: 0X0008
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 
FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80801114
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:  
FH_MEM_RSSR_SHARED_CTRL_REG: 0X00fc
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:
FH_MEM_RSSR_RX_STATUS_REG: 0X0703
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:
FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0:
FH_TSSR_TX_STATUS_REG: 0X07ff0001
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 
FH_TSSR_TX_ERROR_REG: 0X
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: Start IWL Error Log Dump:
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: Status: 0x, count: 6
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: Loaded firmware version: 
16.242414.0
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 0x2078 | 
ADVANCED_SYSASSERT  
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 0x00A00281 | uPc
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 0x | branchlink1
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 0x0B2C | branchlink2
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 0x00016A90 | interruptlink1
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 0x001C46DA | interruptlink2
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 0xDEADBEEF | data1
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 0xDEADBEEF | data2
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 0xDEADBEEF | data3
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 0x158099C9 | beacon time
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 0x6A82873B | tsf low
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 0x0001 | tsf hi
Feb 17 23:44:38 hopa kernel: iwlwifi :02:00.0: 0x | time gp1
Feb 17 23:44:38 hopa kernel: iwlwifi 

Bug#815036: transition: msgpack-c

[James McCoy]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

I'd like to start discussion of a msgpack-c (formerly msgpack)
transition.

msgpack-c 1.4.0-2 is in experimental and I'm ready to start trying to
get it into unstable & testing.  I don't know of any outstanding issues
other than it tickling a possible G++6 bug[0], but there's a possible
workaround already being looked at upstream[1].

[0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69853
[1]: 
https://github.com/redboltz/msgpack-c/commit/d1a9ddf80307c7fd8aa5bb060792523cf3e50482

Although there isn't an ABI bump, the 1.4.0 implements the new version
of the msgpack format and has some related API changes.  The old
libmsgpackc2 doesn't understand the new msgpack format, so packages
built against the new library won't run properly if they try to use some
of the newer types.

The libmsgpack3 packge is no longer relevant as the C++ interface is now
header-only.

I've done some test rebuilds of the reverse depends and here's the
breakdown:

FTBFS:

* webdis:
  + #811343 filed with patch
* tmate:
  + New upstream version is needed
  + Will file a bug for this
* kumofs:
  + configure script expects the C++ library (libmsgpack) and therefore
fails
  + Trivial patch to remove that expectation leads to a compile failure
due to mixing code with C and C++ linkage
  + No upstream activity in 5+ years
  + Debian maintainer MIA
* libdata-messagepack-stream-perl:
  + This likely needs a newer version of libdata-messagepack-perl, which
hasn't been uploaded yet
  + Needs to be adapted to new msgpack-c API.  I have some patches I can
send in that regard.

Good:

* groonga

I'll update this as I file bugs against the FTBFS packages, but I wanted
to get on the radar and see what feedback the team had.

I'm not quite sure about the Ben file, but I think it should be
sufficient.  From what I see, most current packages ended up getting
dependencies on libmsgpack3 so seeing them switch to libmsgpackc2 should
be good enough.  I don't think enforcing a minimum version of the
libmsgpackc2 dependency is accurate, since that depends on what part of
the API is being used.

Although it's most likely that anything build depending on
libmsgpack-dev has *some* binary package that will get a dependency on
libmsgpackc2 >= 1.0.0, not necessarily all of their binary packages
will.  For example, groonga's groonga-bin package has Depends
libmsgpackc2 (>= 0.5.1) after a rebuild but groonga-plugin-suggest gets
libmsgpackc2 (>= 1.0.0).

Cheers,
James

Ben file:

title = "msgpack-c";
is_affected = .build-depends ~ "libmsgpack-dev"
is_good = .depends ~ "libmsgpackc2";
is_bad = .depends ~ "libmsgpack3"


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

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

Bug#815035: RM: trafficserver [armhf] -- RoM; FTBFS

[Aron Xu]

Package: ftp.debian.org
User: release.debian@packages.debian.org
Usertags: rm

I'd like to request removal of trafficserver's armhf packages from
testing, to allow it's migration from unstable, it's not supported by
upstream anymore.

Regards.
Aron

Bug#815034: there was a maintenance release 2.39.0 - please update debian package

[Yaroslav Halchenko]

Package: python-boto
Version: 2.38.0-1
Severity: wishlist

https://github.com/boto/boto/tree/2.39.0
README wasn't updated for the release date, which was much more recent than
it states:

tag 2.39.0
Tagger: JordonPhillips 
Date:   Mon Jan 18 17:45:17 2016 -0800

Tagging 2.39.0 release.


Thank you in advance!


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

Kernel: Linux 4.4.0-rc1+ (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 python-boto depends on:
ii  python   2.7.9-1
ii  python-requests  2.8.1-1

python-boto recommends no packages.

python-boto suggests no packages.

-- no debconf information

Bug#815033: icewease: Cookie confirmation dialog removed in upstream Firefox 44.0

[Mart Rootamm]

Package: iceweasel
Version: 44.0+

That version has cookie confirmation dialogs removed, cookie settings
are then changed to default to 'Accept', and fine-grained cookie
permissions that were previously set, are gone, resulting in data loss
after upgrading. This reduces user privacy.

Relevant upstream bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=606655
Data loss reported at comment #44 there, and further comments are restricted.

Upstream discussion moved here:
https://mail.mozilla.org/pipermail/firefox-dev/2016-February/thread.html#3890

Ditto with upstream SeaMonkey:
https://bugzilla.mozilla.org/show_bug.cgi?id=1235199

Users can currently use Firefox up to 43.0.4 and 38.6.x ESR, and block
future upgrades. Though, in time, these browser versions will have
become outdated for the modern web of the future.

I'm afraid Firefox 45 ESR, to be released in early March 2016, won't
have the cookie confirmation dialogs either.

Upstream does not seem to be very interested in returning the cookie
confirmation dialogs, although I'd like them in future releases of
both GNU IceCat, Debian Iceweasel, and another browser based on
Firefox.

Bug#814959: Keyboard mapping broken with Qt5 apps in TightVNC, possibly due to missing XKEYBOARD extension

[James Lu]

Hi,

I can reproduce this with both the versions of Qt 5 in testing and
unstable (libqt5gui5 versions 5.5.1+dfsg-13 and 5.5.1+dfsg-14
respectively). tightvncserver has version 1.3.9-7 on this installation
of testing.

Best,
James

On 17/02/2016 2:41 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
> Control: tag -1 moreinfo
> 
> Can you test if it also happens with testing's qt5? If it doesn't I can
> submit a bug upstream, if it does work we would need to isolate the
> patches that fixed that.
> 
> -- 
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
> 



signature.asc
Description: OpenPGP digital signature

Bug#814789: rjava: FTBFS: configure: error: Cannot compile a simple JNI program. See config.log for details.

[Dirk Eddelbuettel]

Something is out of whack with openjdk-8-jdk and R. I need to talk to
upstream, and that may take a moment.

It all works if only one runs 'R CMD javareconf' but I don't see a way to
shoehorn that in as root.   Oh well.

The package has no reverse dependencies. So worst case we just remove it.

Dirk

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

Bug#812532: files with the same name installed in / and /usr

[Marco d'Itri]

On Jan 24, Marco d'Itri  wrote:

> I do not know exactly how yp-tools is supposed to work, but this kind of 
> setup is definitely not correct because both programs may be called by 
> different software depending on the $PATH, boot progress and explicit 
> paths.
> 
> If the files are not actually needed then they should not be installed 
> at all, but if they must be used instead of the ones provided by 
> hostname then yp-tools should divert these and install its own binaries 
> in /bin/.
Can you share how you want to solve this issue?
I do not mind producing a patch, if needed.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#739683: simple-scan should honour page size settings and remember page crop setting

[Jörg Frings-Fürst]

Hi,

no answer since 2014-07. So I close this bug.

If the bug still occurs feel free to file a new bug.

Thank you for spending your time helping to make Debian better with
this bug report. 

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#815032: RFS: hello/3.1-4 ITP

[Jason J. Herne]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

Package name: vizigrep
Version : 1.2-1
Upstream Author : Jason J. Herne (hern...@gmail.com)
URL : https://github.com/hernejj/vizigrep
License : GPL
Section : utils

Vizigrep is a graphical user interface for performing fast and powerful
searches inside a group of files.  Simply tell Vizigrep which folder you
want
to search and what you want to search for and it will quickly find all
occurrences of your search string within the files and folders you have
selected.  The search results are annotated to show you the lines containing
your search term and color coding is used to help you quickly lock your
eyes on
to what you are searching for. If simple search strings are not powerful
enough
Vizigrep also understands regular expressions.

To access further information about this package, please visit the
following URL:
http://mentors.debian.net/package/vizigrep

Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/v/vizigrep/vizigrep_1.0-1.dsc

More information on Vizigrep can be obtained from
https://github.com/hernejj/vizigrep and by reading the README file
included with the package.

Regards,
  Jason J. Herne

Bug#732113: Save file dialog occasionally goes blank.

[Jörg Frings-Fürst]

Hi,

the upstream bug was closed. So I close this bug too.

If the bug still occurs feel free to file a new upstream bug.

Thank you for spending your time helping to make Debian better with
this bug report. 

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#814544: wheezy-pu: package clamav/0.99+dfsg-0+deb7u1

[Scott Kitterman]

On Wednesday, February 17, 2016 08:22:23 PM Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2016-02-12 at 15:04 -0500, Scott Kitterman wrote:
> > This is the follow-up to #807969 for wheezy.  Equivalent debdiff will be
> > attached as a reply to the bug (since it's huge) to make sure the doesn't
> > get blocked.
> > 
> > As with Jessie, this will require a small transition.  Clamav and
> > libclamunrar will both need source uploads (prepared) and will hit New
> > due to bumped so name. I'll file a separate bug for libclamunrar. 
> > Additionally, four packages
> > will need binNMUs:
> Please go ahead.
> 
> Feel free to get the package name change fast-tracked through NEW. If
> you do, please let us know so that we can spot it appearing in p-u (as
> it'll bypass stable-new).

Thanks.  Both clamav and libclamunrar source uploads are done.  I'll see what 
I can get done about getting them pushed through New.

Scott K

Bug#815031: [pkg-wine-party] Bug#815031: wine: packaging depends fault

[Austin English]

On Wed, Feb 17, 2016 at 8:46 PM, Richard Jasmin  wrote:
> Source: wine
> Severity: critical
> Tags: newcomer
> Justification: breaks unrelated software
>
> Dear Maintainer,
>
> we have a SERIOUS depends issue going on with Jessie and multiarch(and any
> spins based of Jessie).
>
> I thought it was just skype being a dick. Its not.
> Try and install wine and you have the same scenario.
>
> What it boils down to is this:
>
> The installable package demands libav.
> Libav demands every other libav package.
> ASoundlibs are demanded.
>
> This demands (generic) openCL be installed, breaking any proprietary video
> setup you may have(or at least in part).These packages have no need for either
> libav, nor openCL.

Wine doesn't use or depend on libav, I'm not sure how you came to the
conclusion that this is a Wine bug.

> Only in rare cases is OpenCL needed. The wine apps that may need it, cannot 
> run
> it due to other requirements.Skype doesnt need it.
>
> This was reported prior to DECEMBER 2014.
> (http://ubuntuforums.org/showthread.php?t=2257502)

Ubuntu isn't Debian, and reports made on ubuntu forums aren't tracked
in Debian's bug system.

Bug#812894: nmu: lush and tulip, oprofile, tarantool

[Aaron M. Ucko]

Emilio Pozuelo Monfort  writes:

> tulip doesn't have a strict dependency on binutils anymore.

Per https://packages.debian.org/sid/tulip, tulip currently has

  Depends: binutils (>= 2.25.90.20160101), binutils (<< 2.25.90.20160102), ...

which is incompatible with binutils 2.26.  Please proceed to binNMU it.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#815019: xfce4-power-manager: uses much memory when running for several days

[Roland Hieber]

Package: xfce4-power-manager
Followup-For: Bug #815019

This issue may be somehow related to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778642, but I'm not using the
xfce-panel plugin. 

I tried valgrinding a 5-minute run of xfce4-power-manager with --leak-check=full
--trace-children=yes, but since there are no debugging symbols for
xfce4-power-manager, the information is probably of limited use.  I have
attached the log nevertheless.  During this run, I did a suspend, followed by
thaw and killing the power manager process.

 - Roland


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

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

Versions of packages xfce4-power-manager depends on:
ii  libc6 2.21-8
ii  libcairo2 1.14.6-1
ii  libdbus-1-3   1.10.6-1
ii  libdbus-glib-1-2  0.106-1
ii  libgdk-pixbuf2.0-02.32.3-1.2
ii  libglib2.0-0  2.46.2-3
ii  libgtk2.0-0   2.24.29-1
ii  libnotify40.7.6-2
ii  libpango-1.0-01.38.1-1
ii  libpangocairo-1.0-0   1.38.1-1
ii  libupower-glib3   0.99.3-1+b3
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxfce4ui-1-04.12.1-2
ii  libxfce4util7 4.12.1-2
ii  libxfconf-0-2 4.12.0-2+b1
ii  libxrandr22:1.5.0-1
ii  upower0.99.3-1+b3
ii  xfce4-power-manager-data  1.4.4-4

Versions of packages xfce4-power-manager recommends:
ii  libpam-systemd   228-6
pn  xfce4-power-manager-plugins  

xfce4-power-manager suggests no packages.

-- debconf-show failed
==32237== Memcheck, a memory error detector
==32237== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==32237== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==32237== Command: xfce4-power-manager
==32237== Parent PID: 19173
==32237== 
--32237-- WARNING: Serious error when reading debug info
--32237-- When reading debug info from /lib/x86_64-linux-gnu/ld-2.21.so:
--32237-- Ignoring non-Dwarf2/3/4 block in .debug_info
--32237-- WARNING: Serious error when reading debug info
--32237-- When reading debug info from /lib/x86_64-linux-gnu/ld-2.21.so:
--32237-- Last block truncated in .debug_info; ignoring
--32237-- WARNING: Serious error when reading debug info
--32237-- When reading debug info from /lib/x86_64-linux-gnu/ld-2.21.so:
--32237-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
--32237-- WARNING: Serious error when reading debug info
--32237-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.21.so:
--32237-- Ignoring non-Dwarf2/3/4 block in .debug_info
--32237-- WARNING: Serious error when reading debug info
--32237-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.21.so:
--32237-- Last block truncated in .debug_info; ignoring
--32237-- WARNING: Serious error when reading debug info
--32237-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.21.so:
--32237-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
--32237-- WARNING: Serious error when reading debug info
--32237-- When reading debug info from /lib/x86_64-linux-gnu/libm-2.21.so:
--32237-- Ignoring non-Dwarf2/3/4 block in .debug_info
--32237-- WARNING: Serious error when reading debug info
--32237-- When reading debug info from /lib/x86_64-linux-gnu/libm-2.21.so:
--32237-- Last block truncated in .debug_info; ignoring
--32237-- WARNING: Serious error when reading debug info
--32237-- When reading debug info from /lib/x86_64-linux-gnu/libm-2.21.so:
--32237-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
--32237-- WARNING: Serious error when reading debug info
--32237-- When reading debug info from /lib/x86_64-linux-gnu/librt-2.21.so:
--32237-- Ignoring non-Dwarf2/3/4 block in .debug_info
--32237-- WARNING: Serious error when reading debug info
--32237-- When reading debug info from /lib/x86_64-linux-gnu/librt-2.21.so:
--32237-- Last block truncated in .debug_info; ignoring
--32237-- WARNING: Serious error when reading debug info
--32237-- When reading debug info from /lib/x86_64-linux-gnu/librt-2.21.so:
--32237-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
--32237-- WARNING: Serious error when reading debug info
--32237-- When reading debug info from /lib/x86_64-linux-gnu/libresolv-2.21.so:
--32237-- Ignoring non-Dwarf2/3/4 block in .debug_info
--32237-- WARNING: Serious error when reading debug info
--32237-- When reading debug info from /lib/x86_64-linux-gnu/libresolv-2.21.so:
--32237-- Last block truncated in .debug_info; ignoring
--32237-- WARNING: Serious error when reading debug info

Bug#815031: wine: packaging depends fault

[Richard Jasmin]

Source: wine
Severity: critical
Tags: newcomer
Justification: breaks unrelated software

Dear Maintainer,

we have a SERIOUS depends issue going on with Jessie and multiarch(and any
spins based of Jessie).

I thought it was just skype being a dick. Its not.
Try and install wine and you have the same scenario.

What it boils down to is this:

The installable package demands libav.
Libav demands every other libav package.
ASoundlibs are demanded.

This demands (generic) openCL be installed, breaking any proprietary video
setup you may have(or at least in part).These packages have no need for either
libav, nor openCL.

Only in rare cases is OpenCL needed. The wine apps that may need it, cannot run
it due to other requirements.Skype doesnt need it.

This was reported prior to DECEMBER 2014.
(http://ubuntuforums.org/showthread.php?t=2257502)
It is now Feb 2016. The issue has not been resolved YET.

This needs to be fixed.



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

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

Bug#796895: www.debian.org: Release notes of Debian 8.1 seem to be in some other language alongwith English

[Martin Michlmayr]

* Martin Michlmayr  [2016-02-17 18:19]:
> * shirish  [2015-08-25 20:14]:
> > I was just going through the release notes
> > https://www.debian.org/releases/stable/amd64/release-notes.en.pdf and
> > see that some other language glyphs are interspered with English. I
> > tried with couple of other pdf readers as well but the answer was
> > same. Seems Russian by the looks of it.
> 
> I can confirm this issue.  It happens with all PDFs (regardless of the
> architecture).

Seems this is being discussed already:
https://lists.debian.org/debian-www/2016/02/msg00041.html

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

Bug#798033: www.debian.org: get.debian.org rejects HTTPS connections, but redirects to HTTPS site

[Luca Filipozzi]

On Wed, Feb 17, 2016 at 06:15:46PM -0800, Martin Michlmayr wrote:
> * The Wanderer  [2015-09-04 12:17]:
> > When I connect to http://get.debian.org/ in a Web browser, I am
> > redirected to https://www.debian.org/CD/, which is a HTTPS site.
> > However, the initial connection attempt is made over HTTP, and is
> > potentially subject to external observation.
> > 
> > When I connect to https://get.debian.org/, I get a near-instant
> > "connection refused" or "failed to connect" error.
> 
> > Initial testing seems to indicate that the same basic behavior occurs
> > with cdimage.debian.org, which is the old name for the service now
> > provided by get.debian.org.
> 
> debian-admin: can you help with this?

$ host get.debian.org
get.debian.org is an alias for ftp.acc.umu.se.

Carbon copying Niklas Edmundsson (maswan).

Niklas, I can get provide an X.509 certificate.

Let me know,

Luca

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian

Bug#770400: www.debian.org: https://www.debian.org loads insecure content

[James Murphy]

Confirmed as fixed.

Bug#770400: www.debian.org: https://www.debian.org loads insecure content

[Martin Michlmayr]

* James Murphy  [2014-11-20 17:20]:
> I think the chrome warning puts it best:
> 
> The page at 'https://www.debian.org/' was loaded over HTTPS, but is
> submitting data to an insecure location at
> 'http://search.debian.org/cgi-bin/omega': this content should also be
> submitted over HTTPS.

I believe this has been fixed.  Can you confirm?

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

Bug#796895: www.debian.org: Release notes of Debian 8.1 seem to be in some other language alongwith English

[Martin Michlmayr]

* shirish  [2015-08-25 20:14]:
> I was just going through the release notes
> https://www.debian.org/releases/stable/amd64/release-notes.en.pdf and
> see that some other language glyphs are interspered with English. I
> tried with couple of other pdf readers as well but the answer was
> same. Seems Russian by the looks of it.

I can confirm this issue.  It happens with all PDFs (regardless of the
architecture).

Javier, Holger, any idea?

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

Bug#798033: www.debian.org: get.debian.org rejects HTTPS connections, but redirects to HTTPS site

[Martin Michlmayr]

* The Wanderer  [2015-09-04 12:17]:
> When I connect to http://get.debian.org/ in a Web browser, I am
> redirected to https://www.debian.org/CD/, which is a HTTPS site.
> However, the initial connection attempt is made over HTTP, and is
> potentially subject to external observation.
> 
> When I connect to https://get.debian.org/, I get a near-instant
> "connection refused" or "failed to connect" error.

> Initial testing seems to indicate that the same basic behavior occurs
> with cdimage.debian.org, which is the old name for the service now
> provided by get.debian.org.

debian-admin: can you help with this?

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

Bug#815030: artikulate: cannot download any courses

[Paul Wise]

Package: artikulate
Version: 4:15.12.1-1
Severity: serious

I cannot download any courses with artikulate and it isn't useful without them.

I get this error in the download courses dialog:

Loading of providers from file: 
http://edu.kde.org/artikulate/downloads/providers.xml fail

The URL in that message works, as does the URL mentioned in providers.xml.

I see these messages in the terminal where I launched artikulate:

knewstuff: Initializing KNS3::Engine from ' "artikulate.knsrc" '
No frame loaded
No frame loaded
No frame loaded
knewstuff: Loading KNewStuff3 config:  "artikulate.knsrc"
knewstuff: Categories:  ()
knewstuff: Using registry file:  
"/home/pabs/.local/share/knewstuff3/artikulate.knsregistry"
knewstuff: Loading KNS2 registry of files for the component:  "artikulate"
knewstuff: Cache read... entries:  0
knewstuff: loading providers from  
"http://edu.kde.org/artikulate/downloads/providers.xml;
knewstuff: XmlLoader::load(): url:  
QUrl("http://edu.kde.org/artikulate/downloads/providers.xml;)
klauncher not running... launching kdeinit
klauncher not running... launching kdeinit
couldn't create slave: "Cannot talk to klauncher: The name org.kde.klauncher5 
was not provided by any .service files"

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (860, 'testing-proposed-updates'), (850, 
'buildd-testing-proposed-updates'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental'), (690, 'buildd-experimental'), (500, 
'unstable-debug'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages artikulate depends on:
ii  libc6  2.21-8
ii  libgcc11:5.3.1-8
ii  libkf5configcore5  5.16.0-1
ii  libkf5configgui5   5.16.0-1
ii  libkf5configwidgets5   5.16.0-1
ii  libkf5coreaddons5  5.16.0-1
ii  libkf5crash5   5.16.0-1
ii  libkf5declarative5 5.16.0-1
ii  libkf5i18n55.16.0-1
ii  libkf5newstuff55.16.0-1
ii  libkf5widgetsaddons5   5.16.0-1
ii  libkf5xmlgui5  5.16.0-1
ii  libqt5core5a   5.5.1+dfsg-13
ii  libqt5glib-2.0-0   1.2.0-3
ii  libqt5gstreamer-1.0-0  1.2.0-3
ii  libqt5gui5 5.5.1+dfsg-13
ii  libqt5qml5 5.5.1-3
ii  libqt5quickwidgets55.5.1-3
ii  libqt5sql5 5.5.1+dfsg-13
ii  libqt5widgets5 5.5.1+dfsg-13
ii  libqt5xml5 5.5.1+dfsg-13
ii  libqt5xmlpatterns5 5.5.1-2
ii  libstdc++6 5.3.1-8

artikulate recommends no packages.

artikulate suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#815029: artikulate: segfaults due to missing dependencies: qml-module-org-kde-kquickcontrolsaddons qml-module-qtqml-models2

[Paul Wise]

Package: artikulate
Version: 4:15.12.1-1
Severity: serious

There are two missing dependencies without which artikulate just
segfaults on startup:

qml-module-org-kde-kquickcontrolsaddons
qml-module-qtqml-models2

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (860, 'testing-proposed-updates'), (850, 
'buildd-testing-proposed-updates'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental'), (690, 'buildd-experimental'), (500, 
'unstable-debug'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages artikulate depends on:
ii  libc6  2.21-8
ii  libgcc11:5.3.1-8
ii  libkf5configcore5  5.16.0-1
ii  libkf5configgui5   5.16.0-1
ii  libkf5configwidgets5   5.16.0-1
ii  libkf5coreaddons5  5.16.0-1
ii  libkf5crash5   5.16.0-1
ii  libkf5declarative5 5.16.0-1
ii  libkf5i18n55.16.0-1
ii  libkf5newstuff55.16.0-1
ii  libkf5widgetsaddons5   5.16.0-1
ii  libkf5xmlgui5  5.16.0-1
ii  libqt5core5a   5.5.1+dfsg-13
ii  libqt5glib-2.0-0   1.2.0-3
ii  libqt5gstreamer-1.0-0  1.2.0-3
ii  libqt5gui5 5.5.1+dfsg-13
ii  libqt5qml5 5.5.1-3
ii  libqt5quickwidgets55.5.1-3
ii  libqt5sql5 5.5.1+dfsg-13
ii  libqt5widgets5 5.5.1+dfsg-13
ii  libqt5xml5 5.5.1+dfsg-13
ii  libqt5xmlpatterns5 5.5.1-2
ii  libstdc++6 5.3.1-8

artikulate recommends no packages.

artikulate suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#814728: upgrade to 4.9 or a quick update for 4.5?

[Samuel Thibault]

Hello,

tony mancill, on Tue 16 Feb 2016 21:24:17 -0800, wrote:
> I notice that you have been working on upgrading to a new upstream
> version.

Yes, but IIRC I didn't finish because it was making reverse
build-depends fail to build.

> Would you mind if I prepared an update of 4.5 and uploaded
> to address the FTBFS bug?

That would be useful, please feel free to do it.

> Or would you like to collaborate on the update to 4.9?

We can also do that, we just need to make sure that reverse
build-depends still build fine.

Samuel

Bug#809256: netbeans: HTML5 Parser Exception

[Markus Koschany]

Control: clone -1
Control: retitle -1 JavaScript support is incomplete for Base IDE

On Mon, 28 Dec 2015 14:35:21 -0500 Michael Cordingley
 wrote:
> Package: netbeans
> Version: 8.0.2+dfsg1-5
> Severity: important
> 
> Dear Maintainer,
> 
> With the bug, I am able to edit HTML, but cannot insert line breaks without 
> pasting them in. That is, the "enter" key effectively does not work. I also 
> note silent exceptions getting logged in my IDE. I have appended the stack 
> trace of that exception to this report.
> 
> It appears to affect PHP editing in that I am no longer able to use features 
> that depend on parsing PHP files, such as finding the usages of a class or 
> jumping to its definition. Normal editing, including use of the "enter" key 
> still works, as does syntax highlighting.
> 
> I am also able to edit my JavaScript files just fine, though I receive no 
> syntax highlighting on those files. It treats them as basically just 
> plain-text files. I don't know if this is related or not.


Hello,

this bug will be fixed soon since the new libhtml5parser-java package is
now available in Debian. I have tried several HTML documents and editing
with code completion should work again. I have cloned this bug report
because I think JavaScript support is another bug which we should be
able to fix in the near future.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#815027: RFS: ocrmypdf/4.0.1-1 [ITP] -- add an OCR text layer to PDF files

[Sean Whitton]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package ocrmypdf.

OCRmyPDF generates a searchable PDF/A file from a regular PDF containing
only images.  It uses the Tesseract OCR engine and so supports the 39
languages that Tesseract does.

It is a convenient wrapper around Tesseract, unpaper, qpdf and other
tools for processing scans, obviating the need for a user to construct a
haphazard shell script connecting these tools together.  There are many
such scripts floating around online, but ocrmypdf is much more carefully
put together.

* Package name: ocrmypdf
  Version : 4.0.1-1
  Upstream Author : James R. Barlow 
* URL : https://github.com/jbarlow83/OCRmyPDF
* License : MIT
  Section : graphics

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/o/ocrmypdf/ocrmypdf_4.0.1-1.dsc

Or build it with gbp:

git clone https://git.spwhitton.name/ocrmypdf
git checkout pristine-tar   # to create the branch locally, so gbp uses it
git checkout debian/4.0.1-1
git verify-tag debian/4.0.1-1 # if you have my key
gbp buildpackage

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#814757: [Pkg-alsa-devel] Bug#814757: alsa-base: dmix/software mixing doesn't work

[Andoru]

> > > Sometimes pulseaudio is the cause.
> >
> > $ apt-cache policy pulseaudio
> > pulseaudio:
> >   Installed: (none)
> >   Candidate: 7.1-2
> >   Version table:
> >  7.1-2 500
> > 500 http://ftp.debian.org/debian unstable/main amd64 Packages
>
> What tells:
>
> dpkg -l | egrep "(alsa|libaso)"

$ dpkg -l | egrep "(alsa|libaso)"
ii  alsa-base
1.0.27+1   all  dummy package to ease
purging of obsolete conffiles
ii  alsa-oss
1.0.28-1   amd64ALSA wrapper for OSS
applications
ii  alsa-tools
1.1.0-1amd64Console based ALSA
utilities for specific hardware
ii  alsa-tools-gui
1.1.0-1amd64GUI based ALSA
utilities for specific hardware
ii  alsa-utils
1.1.0-2amd64Utilities for
configuring and using ALSA
ii  alsamixergui
0.9.0rc2-1-9.1 amd64graphical soundcard
mixer for ALSA soundcard driver
ii  gstreamer0.10-alsa:amd64
0.10.36-2  amd64GStreamer plugin for
ALSA
ii  libalsaplayer0
0.99.81-1+b1   amd64alsaplayer plugin
library
ii  libasound2:amd64
1.1.0-1amd64shared library for ALSA
applications
ii  libasound2:i386
1.1.0-1i386 shared library for ALSA
applications
ii  libasound2-data
1.1.0-1all  Configuration files and
profiles for ALSA drivers
ii  libasound2-dev:amd64
1.1.0-1amd64shared library for ALSA
applications -- development files
ii  libasound2-plugins:amd64
1.1.0-1amd64ALSA library additional
plugins


> >
> > Did they disable search engine indexing on those lists? I wasn't able to
> > find much useful info for ALSA and this specific issue while searching.
> > Also no posts over on those mailing lists turned up...
>
> Just ask on those lists ;-)

Would've done that, but I wouldn't have wanted to be shunned for asking an
oft-asked question, since you said this issue was answered multiple times
before.

> And please ask your searchengine on how
> to use emailin mailing lists and learnwhat an email thread is.

Exactly how do you think I got to post on alsa's bug report and alsa-user
mailing lists?
I asked a completely different question by the way.

> > If I do that, I get no sound through the analog jack output. What
probably
> > happens is that the HDMI is used for sound output instead... Somebody at
> > the ALSA user mailing list suggested me to use config #2 (from my first
> > message in this bug report) just to set the default soundcard without
> > setting dmix, but it didn't work...
>
> Just do as user:
>
> $ mv $HOME/.asoundrc $HOME/.asoundrc.save

Don't have an ~/.asoundrc, so I'll assume I have to do that to
/etc/asound.conf

> $ cat < $HOME/.asoundrc
> defaults.pcm.!card PCH
> defaults.ctl.!card PCH
> EOF

That's exactly the same as configuartion #2 that I've tried, and which
didn't work... Read my initial message in this bug report, please.
But I gave it a spin this time again, in case I messed up something last
time (and I did, just not with ALSA).

>
> As root:
>
> # service alsa-utils restart

That gives me:
Failed to restart alsa-utils.service: Unit alsa-utils.service is masked.

So I used this instead:

# /etc/init.d/alsa-utils restart

Which unfortunately didn't seem to change anything, so probably the command
I issued didn't work.
But after restarting, the sound was the same, but I found out what was
causing all these issues:
In VLC I've set up a custom device for audio output instead of "Default",
and that seemed to hold the sound blocked to one app. After changing it
back to "Default", everything works as expected (multiple sound sources,
browser add-ons sounds work, WebM/HTML5 players have sound)

This can be now closed as it's no longer a bug. The message about missing
files led me to think that the ALSA package I got was broken, thus the bug
report.

Bug#813614: providing a patch

[Stéphane Blondon]

This is a diff of crontab.c providing a color change for comment lines
for the `crontab -l` output. You can see a demo with the provided
screenshot attached to this message too.

Note that the DEBIAN_HEADERS are not colorized. If you're interested, I
can patch the code for this part too.

I used space indentation only because the file mixes tabs and spaces
indentation so I didn't know what was the right choice.

I saw in the documentation that, in the future, cronie could be used
instead of the vixie cron. Perhaps I should push such a feature in
cronie instead? (Perhaps it's currently available in cronie, I didn't
check.)

-- 
Stéphane
--- crontab.c.orig	2016-02-18 01:12:36.253608497 +0100
+++ crontab.c	2016-02-18 01:18:31.655518325 +0100
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #ifdef USE_UTIMES
@@ -48,6 +49,10 @@
 
 #define NHEADER_LINES 3
 
+#define COMMENT_COLOR  "\x1B[34m"
+#define RESET_COLOR "\033[0m"
+
+
 enum opt_t	{ opt_unknown, opt_list, opt_delete, opt_edit, opt_replace };
 
 #if DEBUGGING
@@ -302,6 +307,7 @@
 	char	n[MAX_FNAME];
 	FILE	*f;
 	int	ch;
+int new_line = 1;
 #ifdef DEBIAN
 	int x;
 	char*ctnh;
@@ -345,8 +351,17 @@
 	}
 	  }
 #endif
-	while (EOF != (ch = get_char(f)))
-		putchar(ch);
+while (EOF != (ch = get_char(f))){
+if(new_line){
+if(ch == '#'){
+printf(COMMENT_COLOR);
+}else{
+printf(RESET_COLOR);
+}
+}
+putchar(ch);
+new_line = ch == '\n';
+}
 	fclose(f);
 }
 


signature.asc
Description: OpenPGP digital signature

Bug#814999: dovecot-core: dovecot.socket should (probably) not be enabled on installation

[Jaldhar H. Vyas]

On Wed, 17 Feb 2016, Apollon Oikonomopoulos wrote:


Package: dovecot-core
Version: 1:2.2.18-2+b1
Severity: normal

Dear Maintainer,

dovecot-core currently ships and enables (via dh_systemd_enable) two
units: dovecot.socket and dovecot.service. However, enabling
dovecot.socket by default is a bit problematic in this case, for the
following reasons:

- dovecot.socket makes assumptions about the listening sockets; it
  assumes an IMAP-only setup with dovecot listening on TCP ports 143
  and 993, which may or may not be the case. Note that this is done
  even if dovecot-imapd is not installed in the system.

- invoke-rc.d, as used in the maintainer scripts, does not handle
  socket units at all. This may cause unpredictable behavior during
  package upgrades on busy servers, since dovecot.service is stopped in
  prerm, but may be (re-)started anytime before the new packages have
  been (fully) unpacked if it is triggered by the socket unit.

- dh_systemd_start also does not start the socket unit by default,
  while the socket unit will be started on the next boot,
  differentiating boot-time and installation-time behavior.

- dovecot.service is enabled and started anyway during boot, so using
  socket activation for dovecot in this case seems to be redundant.

IMHO, it is okay for dovecot.socket to be shipped with the package, but
it should not be enabled by default. Instead it should be left inactive
and up to the admin to decide whether to explicitly enable it or not.



I must admit I am not up to speed on how systemd works.  I didn't know it 
was enabled. :-)  What is the best way to install it but leave it 
inactive?  Comment it out?  Move it somewhere? Or something else?


--
Jaldhar H. Vyas 

Bug#686777: libopus-custom, temporary workaround and suggestion.

[Ron]

On Wed, Feb 17, 2016 at 10:57:51PM +0100, Petter Reinholdtsen wrote:
> Hi.  Is there any hope to solve the jack/opus issue?  Been a while
> since the BTS report saw any update.

Well, my understanding from the conversations here and on IRC with
the Jack folk was that they misunderstood why they needed custom
modes in the first place, and their application doesn't really
need them at all (and no other user for custom modes like this
has since come up either).

So the "summary status" at this point is probably best described
here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686777#50

  Cheers,
  Ron

Bug#815026: RM: nautilus-pastebin/stable -- ROM; Project abandoned; RC buggy

[Alessio Treglia]

Package: ftp.debian.org
Severity: normal


Hi,

Please remove nautilus-pastebin from Debian, it should have been removed
from Jessie before the past freeze to be honest. The project is abandoned,
upstream does not intend to release any bugfixes or improvements.


Cheers!

Bug#815020: breaks coredump handling for systems without systemd-coredump

[Felipe Sateler]

On 17 February 2016 at 21:03, Wouter Verhelst  wrote:
> On Wed, Feb 17, 2016 at 06:33:59PM -0300, Felipe Sateler wrote:
>> On 17 February 2016 at 13:12, Wouter Verhelst  wrote:
>> > Package: systemd
>> > Version: 229-1
>> >
>> > Hi,
>> >
>> > systemd contains the following line (src/core/main.c):
>> >
>> > (void) 
>> > write_string_file("/proc/sys/kernel/core_pattern", "|/bin/false", 0);
>> >
>> > The intent is that at some later point, systemd-coredump is started,
>> > which then sets it to something more useful.
>>
>> Note that "systemd-coredump is started" means exactly "set it to
>> something more useful" systemd-coredump does not run as a daemon, but
>> rather is invoked by the kernel.
>
> That's not what the NEWS file seems to suggest, but I'll take your word
> for it.

Do you refer to the systemd service bit? The change mentioned is that
previously, the systemd-coredump binary would process the core file
itself while being invoked by the kernel. Now, it will instead trigger
a oneshot service that can be monitored with systemd, and thus can be
subject to resource limits, niceness, etc.

>
>> > However, in Debian, systemd-coredump is in a separate package that
>> > systemd itself does not depend on. As a result, if systemd is used as
>> > PID1, but systemd-coredump is not installed, all core dumps are thrown
>> > into the bit bucket; not just those that are generated during bootup,
>> > but all core dumps after boot, too.
>> >
>> > They're still generated, however, since systemd also sets the default
>> > soft resource limit on core file size ("ulimit -c") to the "unlimited"
>> > value, rather than having the hard limit be unlimited and the soft limit
>> > be set at 0.
>>
>> Apparently, if the core_pattern is a program, then the limit is
>> ignored by linux, and should instead be honored by the called program.
>
> yes, well, so they're generated at any rate, even if the limit is set
> :-)
>
>> > This is not an ideal situation:
>> > - Generating a core dump, especially in case of a program that uses a
>> >   lot of memory at the time where the dump is generated, requires some
>> >   processing. If the core dump is thrown away, this is wasted processing
>> >   time. If the system is loaded (e.g., because something is forking and
>> >   segfaulting a lot), this is problematic behaviour. By setting the soft
>> >   core file size resource limit to 0, core dumps aren't even generated,
>> >   improving performance.
>>
>> How much resources does this actually consume? If the receiving
>> process does nothing, I don't think there would be much effect going
>> on.
>>
>> According to this (anectodic) upstream list post, the cost is negligible
>>
>> http://article.gmane.org/gmane.comp.sysutils.systemd.devel/31244/match=core_pattern
>
> It may be "negligible", it won't be "nothing". If the system is under
> high load, thousands of "negligible" isn't that any longer.

Right, the question is whether this new load makes the system
noticeably worse than just the restart/abort loop.

>
>> > - The kernel.core_pattern sysctl setting is a system-wide setting; it is
>> >   not possible to modify this other than by using CAP_SYS_ADMIN (IIUC)
>> >   permissions. In contrast, the resource limits are per-process
>> >   configuration; any process can change its resource limits at will.
>> >   This allows the system to have a default of "no core dumps", but at
>> >   the same time, allows a developer or a system administrator to
>> >   temporarily enable core dumps for a particular process, without
>> >   requiring administrator capabilities.
>>
>> Because systemd-coredump respects rlimit, if systemd did not change
>> the rlimit then it wouldn't work by default: meaning that
>> systemd-coredump would have to somehow tell systemd (maybe at install
>> time) to change the default rlimit to something saner, but without
>> interfering with any admin changes.
>>
>> Because systemd conf snippets are always read after the main
>> configuration file, it means that systemd-coredump cannot ship a
>> system.conf snippet altering the default rlimit, because it would
>> override admin changes in system.conf.
>
> I'm not sure I understand this bit. Can you clarify?

Systemd-coredump, as of systemd 229, respects the rlimit of the
crashed process. This means that if the limit is not set to a positive
value, no coredumps will be stored.

This means that systemd-coredump should somehow instruct systemd to
set the default core rlimit to a high value when it is installed. This
cannot be done via a system.conf.d snippet, as that would override any
changes made by the admin in /etc/systemd/system.conf. I do not know
of any other way to set a system-wide rlimit other than telling pid1
to do it. I hope this is clearer now.

>
>> > I'm sure systemd-coredump replicates some of the above, but it isn't
>> > always the best choice to have a core dump be piped into a process, and
>> > therefore 

Bug#794410: Debian Jessie installer freezes during "Processing triggers for libc-bin"

[Carlos Alberto Lopez Perez]

On 17/02/16 21:04, Carlos Alberto Lopez Perez wrote:
[...]
> 
> Trying to read this very same information when /dev/bus/usb/003/002 appears 
> causes a freeze. 
> 
> 
> So, not sure what is going here, but this looks like either a kernel bug or a 
> firmware bug.
> 
> 

This seems very related to this bug reports:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1485057
http://thread.gmane.org/gmane.linux.usb.general/129790

Perhaps the same issue.





signature.asc
Description: OpenPGP digital signature

Bug#756599: printf(3) manpage: stray asterisk in "NAN*"

[Stéphane Aulery]

Le 17/02/2016 13:14, Michael Kerrisk (man-pages) a écrit :


On 17 February 2016 at 01:21, Stéphane Aulery  wrote:


About Debian Bug #756599 [1], I found this explanation [2][3] confirming
that * is not a selector :


I've removed the stray "*" (commit 4a66305922b197)

Thanks for the report, Jakub. And thanks for reminding me of this bug, Stéphane.


Nothing, it's always a pleasure :)

Regards,

--
Stéphane Aulery

Bug#756599: printf(3): stray asterisk in "NAN*"

[Stéphane Aulery]

tags 756599 + fixed-upsteam
stop
-

See commit 
http://git.kernel.org/cgit/docs/man-pages/man-pages.git/commit/man3/printf.3?id=4a66305922b1973a6607416a158ae6f6ed4ab94b


Fixed by Michael Kerrisk mtk.manpa...@gmail.com, 2016-02-17

Will be in man-pages-4.04.

--
Stéphane Aulery

Bug#815025: O: python-braintree

[Alessio Treglia]

Package: wnpp
Severity: normal


Hi,

Due to the lack of time I intend to orphan python-braintree.

Cheers!

Bug#815020: breaks coredump handling for systems without systemd-coredump

[Wouter Verhelst]

On Wed, Feb 17, 2016 at 06:33:59PM -0300, Felipe Sateler wrote:
> On 17 February 2016 at 13:12, Wouter Verhelst  wrote:
> > Package: systemd
> > Version: 229-1
> >
> > Hi,
> >
> > systemd contains the following line (src/core/main.c):
> >
> > (void) 
> > write_string_file("/proc/sys/kernel/core_pattern", "|/bin/false", 0);
> >
> > The intent is that at some later point, systemd-coredump is started,
> > which then sets it to something more useful.
> 
> Note that "systemd-coredump is started" means exactly "set it to
> something more useful" systemd-coredump does not run as a daemon, but
> rather is invoked by the kernel.

That's not what the NEWS file seems to suggest, but I'll take your word
for it.

> > However, in Debian, systemd-coredump is in a separate package that
> > systemd itself does not depend on. As a result, if systemd is used as
> > PID1, but systemd-coredump is not installed, all core dumps are thrown
> > into the bit bucket; not just those that are generated during bootup,
> > but all core dumps after boot, too.
> >
> > They're still generated, however, since systemd also sets the default
> > soft resource limit on core file size ("ulimit -c") to the "unlimited"
> > value, rather than having the hard limit be unlimited and the soft limit
> > be set at 0.
> 
> Apparently, if the core_pattern is a program, then the limit is
> ignored by linux, and should instead be honored by the called program.

yes, well, so they're generated at any rate, even if the limit is set
:-)

> > This is not an ideal situation:
> > - Generating a core dump, especially in case of a program that uses a
> >   lot of memory at the time where the dump is generated, requires some
> >   processing. If the core dump is thrown away, this is wasted processing
> >   time. If the system is loaded (e.g., because something is forking and
> >   segfaulting a lot), this is problematic behaviour. By setting the soft
> >   core file size resource limit to 0, core dumps aren't even generated,
> >   improving performance.
> 
> How much resources does this actually consume? If the receiving
> process does nothing, I don't think there would be much effect going
> on.
> 
> According to this (anectodic) upstream list post, the cost is negligible
> 
> http://article.gmane.org/gmane.comp.sysutils.systemd.devel/31244/match=core_pattern

It may be "negligible", it won't be "nothing". If the system is under
high load, thousands of "negligible" isn't that any longer.

> > - The kernel.core_pattern sysctl setting is a system-wide setting; it is
> >   not possible to modify this other than by using CAP_SYS_ADMIN (IIUC)
> >   permissions. In contrast, the resource limits are per-process
> >   configuration; any process can change its resource limits at will.
> >   This allows the system to have a default of "no core dumps", but at
> >   the same time, allows a developer or a system administrator to
> >   temporarily enable core dumps for a particular process, without
> >   requiring administrator capabilities.
> 
> Because systemd-coredump respects rlimit, if systemd did not change
> the rlimit then it wouldn't work by default: meaning that
> systemd-coredump would have to somehow tell systemd (maybe at install
> time) to change the default rlimit to something saner, but without
> interfering with any admin changes.
> 
> Because systemd conf snippets are always read after the main
> configuration file, it means that systemd-coredump cannot ship a
> system.conf snippet altering the default rlimit, because it would
> override admin changes in system.conf.

I'm not sure I understand this bit. Can you clarify?

> > I'm sure systemd-coredump replicates some of the above, but it isn't
> > always the best choice to have a core dump be piped into a process, and
> > therefore using the traditional "just dump everything to disk" logic can
> > still be beneficial.
> 
> It can still be restored via a sysctl.d snippet, and the rlimit via 
> system.conf.
> 
> Maybe this should be documented somewhere on upgrades?

Possibly.

An alternative solution would be that systemd-sysv shipped with a unit
which would set the core_pattern back to default, which could be
overridden or disabled by a unit shipped by a unit shipped with
systemd-coredump? That would be less surprising -- I have to say I spent
a long time tracking down what happened.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#815006: Renaming Iceweasel to Firefox

[Paul Wise]

On Wed, 17 Feb 2016 16:55:42 +0100 Sylvestre Ledru wrote:

> = About the Debian specific patches =

Mozilla's trademark policy isn't clear about how much modification
requires Mozilla's written consent. Any written consent except for a
clarification to Mozilla's trademark guidelines would be specific to
Debian and thus would be in violation of DFSG item 8. Debian cannot
make agreements with Mozilla about this that don't also apply to all
distributors of modified versions of Mozilla's software.

What is the plan to solve this dilemma?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#753800: tracker.debian.org: please give the details link some content

[Paul Wise]

On Thu, 2016-02-18 at 00:29 +0100, Francesco Poli wrote:

> Good guess! I unchecked the "Forbid @font-face" option in the NoScript
> extension, and the symbols are now correctly displayed even with
> disabled JavaScript.

It wasn't a guess, I have this problem too but don't want to enable web fonts :)

> I wonder whether there's a way to make the tracker symbols work without
> using @font-face (and consequently without preventing NoScript users
> from forbidding @font-face)...

The site could use proper  tags instead of weird Unicode PUA hacks.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#815024: RFS: autotalent/0.2-5

[Ross Gammon]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: autotalent
  Version : 0.2-5
  Upstream Author : Thomas A. Baran 
* URL : http://tombaran.info/autotalent.html
* License : BSD-3-clause
  Section : sound

It builds this binary package:

autotalent - pitch correction LADSPA plugin

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

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


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

dget -x
http://mentors.debian.net/debian/pool/main/a/autotalent/autotalent_0.2-5.dsc

Debian packaging can be found in the Debian Multimedia Team repository:
http://anonscm.debian.org/cgit/pkg-multimedia/autotalent.git

Changes since the last upload:

  * Change uploader from Alessio to me & update Vcs URLs
  * Improve package long description
Thanks to Justin B Rye (Closes: #785260)
  * Bump standards version, no changes required
  * Fix watch file

Regards,
Ross Gammon



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

Kernel: Linux 4.2.0-25-generic (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#814027: [pkg-gnupg-maint] Bug#814027: "ts209" d-i image failed to build due to size

[Martin Michlmayr]

* Werner Koch  [2016-02-16 08:33]:
> What about using a smaller version of libgcrypt for d-i?  My current 1.7
> version using standard options has a stripped size of 1.1 MiB.  By using
> these options:
> 
>   ./configure --enable-maintainer-mode \
>   --enable-ciphers=cast5,des,aes \
>   --enable-digests=sha1,sha256,sha512 \
>   --enable-kfds=s2k,pkdf2 \
>   --disable-padlock-support --disable-aesni-support \
>   --disable-drng-support \
>   --disable-avx-support --disable-avx2-support \
>   --disable-pclmul-support 
> 
> I get down to a stripped size of the SO of 551 KiB on amd64.
> 
> We would need to tweak GnuPG a bit to work with that version.  Right now
> it complains about missing MD5 at runtime.  But that should be fixed
> anyway.
> 
> Would that be a way forward?

I'm not sure if it will help in my particular case (I can try,
though), but I think this should be done anyway.  Do you (or Daniel)
want to file a bug on libgcrypt once GnuPG has been tweaked?

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

Bug#815012: one more package with cruft in debian

[Rene Engelhard]

Hi,

On Thu, Feb 18, 2016 at 12:25:31AM +0100, Matthias Klose wrote:
> On 17.02.2016 23:36, Rene Engelhard wrote:
> > On Wed, Feb 17, 2016 at 07:17:31PM +0100, Matthias Klose wrote:
> > That they are installed is intended, though.
> 
> thanks, this assumptions breaks any builders which don't yet use automatic
> dbgsym package generation. How big is this file that it can't be shipped in
> the library package?

Not big, but why should it be shipped in the library package? It's not needed
there.

It's for debugging only, and if you want that, you want the debugging symbols
anyway - which is what -dbg(sym) is for.

Regards,

Rene

Bug#753800: tracker.debian.org: please give the details link some content

[Francesco Poli]

On Thu, 18 Feb 2016 06:45:39 +0800 Paul Wise wrote:

> On Thu, Feb 18, 2016 at 6:19 AM, Francesco Poli wrote:
> 
> > since this change went online, I have experienced an awkward behavior
> > with Iceweasel: if I visit a tracker page with the JavaScript
> > interpreter disabled, I see many rectangles with unicode exadecimal
> > digits in them (as if the browser were trying to display characters
> > without finding an appropriate gliph among the installed fonts).
> > Please see the attached "tracker_on_iceweasel_no_js.png" screenshot.
> 
> This is because the icons are actually characters in the Unicode
> Private Use Area of the Octicons font, which is loaded over http. I
> guess you have disabled this to decrease your browser's attack
> surface.

Good guess! I unchecked the "Forbid @font-face" option in the NoScript
extension, and the symbols are now correctly displayed even with
disabled JavaScript.
Thanks a lot for the explanation!

I wonder whether there's a way to make the tracker symbols work without
using @font-face (and consequently without preventing NoScript users
from forbidding @font-face)...

> 
> > As soon as I enable the JavaScript interpreter for tracker.debian.org
> > (by using the NoScript Iceweasel extension), I see the correct symbols.
> > Please see the attached "tracker_on_iceweasel_with_js.png" screenshot.
> 
> I expect the JS enables a fall-back for people who disabled web fonts.

Frankly speaking, I have no idea: I am quite ignorant about
JavaScript...


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


pgp2k5LzFHxeo.pgp
Description: PGP signature

Bug#815012: one more package with cruft in debian

[Matthias Klose]

On 17.02.2016 23:36, Rene Engelhard wrote:
> On Wed, Feb 17, 2016 at 07:17:31PM +0100, Matthias Klose wrote:
> That they are installed is intended, though.

thanks, this assumptions breaks any builders which don't yet use automatic 
dbgsym package generation. How big is this file that it can't be shipped in the 
library package?

Bug#505253: www.debian.org: Logo page missing licenses

[Martin Michlmayr]

* Craig Small  [2008-11-18 08:14]:
> On Sat, Nov 15, 2008 at 05:58:57AM -0800, Alex Brotman wrote:
> > The images are hosted on the debian servers, but there is no license 
> > associated with them.
> Heh, mine's the only one with the license :)
> I would imagine the rest are the same but yes it is probably best to
> check.

Are you going to check the licenses of the other logos, or do you need
help?

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

Bug#815023: RFP: paperless -- Scan, index, and archive all of your paper documents

[James Valleroy]

Package: wnpp
Severity: wishlist

* Package name: paperless
  Upstream Author : Daniel Quinn 
* URL : https://github.com/danielquinn/paperless
* License : GPL
  Programming Lang: Python
  Description : Scan, index, and archive all of your paper documents

Paperless is a server application for indexing and archiving paper
documents.
It includes a consumption script to OCR scanned PDF files and index them
into a
local database, and a web frontend to search and download the files.

I think this would be a very useful to include in FreedomBox.




signature.asc
Description: OpenPGP digital signature

Bug#815022: [iceweasel] DNS Resolver crashes in iceweasel 45.0~b5-1

[Jens-Michael Siegl]

Package: iceweasel
Version: 45.0~b5-1
Severity: normal

--- Please enter the report below this line. ---

Since updating to 45.0~b5-1, iceweasel is crashing quite frequently.

The attached backtrace from one of the 13 coredumps that have been
created by 2 different user accounts on my system over the past 8
hours. Based on my inspection of random samples, the backtraces all
seem to be identical.

I replaced the hostname and a local search domain in the backtrace
for privacy reasons, so string lengths (if included) will not match
(if necessary, I could provide an unalterated backtrace by private
email).

Regards,
Jens

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.4.0-trunk-amd64

Debian Release: stretch/sid
  600 unstablewww.deb-multimedia.org 
  500 unstablehttpredir.debian.org 
1 experimentalhttpredir.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-===
libasound2  (>= 1.0.16) | 
libatk1.0-0 (>= 1.12.4) | 
libc6 (>= 2.17) | 
libcairo2(>= 1.2.4) | 
libdbus-1-3  (>= 1.0.2) | 
libdbus-glib-1-2  (>= 0.78) | 
libevent-2.0-5   (>= 2.0.10-stable) | 
libffi6  (>= 3.0.4) | 
libfontconfig1(>= 2.11) | 
libfreetype6 (>= 2.2.1) | 
libgcc1(>= 1:4.1.1) | 
libgdk-pixbuf2.0-0  (>= 2.22.0) | 
libglib2.0-0(>= 2.37.3) | 
libgtk2.0-0 (>= 2.24.0) | 
libhunspell-1.3-0(>= 1.3.3) | 
libnspr4  (>= 2:4.10.3) | 
libnss3   (>= 2:3.16.1) | 
libpango-1.0-0  (>= 1.14.0) | 
libsqlite3-0 (>= 3.7.12-1~) | 
libstartup-notification0   (>= 0.8) | 
libstdc++6 (>= 4.9) | 
libvpx1  (>= 1.3.0) | 
libx11-6| 
libxext6| 
libxrender1 | 
libxt6  | 
zlib1g (>= 1:1.2.0) | 
fontconfig  | 
procps  | 
debianutils   (>= 1.16) | 


Package's Recommends field is empty.

Suggests   (Version) | Installed
-+-===
fonts-stix   | 1.1.1-4
 OR otf-stix | 
fonts-oflb-asana-math| 000.907-6
fonts-mathjax| 2.6.1-1
mozplugger   | 
libgssapi-krb5-2 | 
 OR libkrb53 | 
libgnomeui-0 | 
libcanberra0 | 




#0  0x7f6e20d21529 in raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/pt-raise.c:36
resultvar = 0
pid = 
#1  0x7f6e1ce8d5af in nsProfileLock::FatalSignalHandler (signo=6, 
info=0x7f6deb2fc7b0, context=0x7f6deb2fc680) at 
/tmp/buildd/iceweasel-45.0~b5/toolkit/profile/nsProfileLock.cpp:185
unblock_sigs = {__val = {32, 0 }}
oldact = 
#2  
No locals.
#3  0x7f6e1ff06507 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55
resultvar = 0
pid = 17455
selftid = 17757
#4  0x7f6e1ff078da in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x4, sa_sigaction = 0x4}, 
sa_mask = {__val = {140110073940720, 140110693955514, 140110073940800, 
94489280512, 0, 0, 0, 21474836480, 140110073940952, 140110960232913, 
94368545874489, 140110960267536, 140109424885760, 0, 140110957944832, 
140110960248696}}, sa_flags = 333295880, sa_restorer = 0x7f6e13ddb160 
<__PRETTY_FUNCTION__.12022>}
sigs = {__val = {32, 0 }}
#5  0x7f6e1feff59d in __assert_fail_base (fmt=0x7f6e2003c778 "%s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f6e13ddb108 "(hp 
!= ((void *)0)) && (hp2 != ((void *)0))", file=file@entry=0x7f6e13ddb0a7 
"res_query.c", line=line@entry=262, function=function@entry=0x7f6e13ddb160 
<__PRETTY_FUNCTION__.12022> "__libc_res_nquery") at assert.c:92
str = 0x7f6dc48fa160 '\345' , "\360\241\217\304m\177"
total = 4096
#6  0x7f6e1feff652 in __GI___assert_fail 
(assertion=assertion@entry=0x7f6e13ddb108 "(hp != ((void *)0)) && (hp2 != 
((void *)0))", file=file@entry=0x7f6e13ddb0a7 "res_query.c", 
line=line@entry=262, function=function@entry=0x7f6e13ddb160 
<__PRETTY_FUNCTION__.12022> "__libc_res_nquery") at assert.c:101
No locals.
#7  0x7f6e13dd2ee8 in __GI___libc_res_nquery 

Bug#753800: tracker.debian.org: please give the details link some content

[Paul Wise]

On Thu, Feb 18, 2016 at 6:19 AM, Francesco Poli wrote:

> since this change went online, I have experienced an awkward behavior
> with Iceweasel: if I visit a tracker page with the JavaScript
> interpreter disabled, I see many rectangles with unicode exadecimal
> digits in them (as if the browser were trying to display characters
> without finding an appropriate gliph among the installed fonts).
> Please see the attached "tracker_on_iceweasel_no_js.png" screenshot.

This is because the icons are actually characters in the Unicode
Private Use Area of the Octicons font, which is loaded over http. I
guess you have disabled this to decrease your browser's attack
surface.

> As soon as I enable the JavaScript interpreter for tracker.debian.org
> (by using the NoScript Iceweasel extension), I see the correct symbols.
> Please see the attached "tracker_on_iceweasel_with_js.png" screenshot.

I expect the JS enables a fall-back for people who disabled web fonts.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#814881: nslcd is stopped after service restart

[Arthur de Jong]

Control: tags -1 + pending

On Tue, 2016-02-16 at 10:09 +0100, Michael Braun wrote:
> After installing some unrelated program using apt-get, it was
> discovered that nslcd needs a restart und I was promted to restart it
> (among other services).

Were you using needrestart for this?

I've had needrestart not correctly restart at least ntp, rpcbind and
mailman. I suspect there is a bug in needrestart and or the combination
with systemd but I've not been able to track it down.

> The logs when the error occured read:
> 
> Feb 15 12:12:01 gate nslcd[26487]: caught signal SIGTERM (15), shutting down
> Feb 15 12:12:01 gate nslcd[21177]: Stopping LDAP connection daemon: nslcd.
> Feb 15 12:12:01 gate nslcd[21302]: version 0.9.4 starting
> Feb 15 12:12:04 gate nslcd[26487]: thread 2 is still running, shutting down 
> anyway
> Feb 15 12:12:04 gate nslcd[26487]: version 0.9.4 bailing out
> Feb 15 12:12:06 gate nslcd[21302]: accepting connections
> Feb 15 12:12:06 gate nslcd[21231]: Starting LDAP connection daemon: nslcd.

The last line I think is systemd writing a log entry using the nslcd.
The lines are out of order for some reason and the new daemon in
started while the old one is still shutting down.

The problem could be that the init script is not called with restart
but with separate stop and start actions (this is slightly different).
I will update the init script to ensure that stop also only returns
when nslcd has actually stopped.

Thanks for pointing this out. This could also be the issue with some of
the other services that have not been restarted correctly.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



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

Bug#814757: [Pkg-alsa-devel] Bug#814757: alsa-base: dmix/software mixing doesn't work

[Elimar Riesebieter]

* Andoru  [2016-02-16 01:27 +0200]:

> > Sometimes pulseaudio is the cause.
> 
> $ apt-cache policy pulseaudio
> pulseaudio:
>   Installed: (none)
>   Candidate: 7.1-2
>   Version table:
>  7.1-2 500
> 500 http://ftp.debian.org/debian unstable/main amd64 Packages

What tells:

dpkg -l | egrep "(alsa|libaso)"
> 
> > According to http://alsa.opensrc.org/DmixPlugin you don't need to setup
> > dmix for analogue output. Dmix is enabled by default for soundcards which
> > don't support hardware mixing. You still need to set it up for digital
> > outputs.
> 
> If I don't set up dmix in the config file, it doesn't work either way.
> 
> > A better source for help is us...@lists.debian.org as this was discussed
> > multiple times in the past.
> 
> Did they disable search engine indexing on those lists? I wasn't able to
> find much useful info for ALSA and this specific issue while searching.
> Also no posts over on those mailing lists turned up...

Just ask on those lists ;-) And please ask your searchengine on how
to use emailin mailing lists and learnwhat an email thread is.

> > A good start is just to throw away all the asoud.conf and .asoundrc
> > stuff. It overconstrains your system. The latest alsa is very tough and
> > should do what you need.
> 
> If I do that, I get no sound through the analog jack output. What probably
> happens is that the HDMI is used for sound output instead... Somebody at
> the ALSA user mailing list suggested me to use config #2 (from my first
> message in this bug report) just to set the default soundcard without
> setting dmix, but it didn't work...

Just do as user:

$ mv $HOME/.asoundrc $HOME/.asoundrc.save
$ cat < $HOME/.asoundrc
defaults.pcm.!card PCH
defaults.ctl.!card PCH
EOF

As root:

# service alsa-utils restart

Elimar
-- 
  Excellent day for drinking heavily.
  Spike the office water cooler;-)

Bug#815012: one more package with cruft in debian

[Rene Engelhard]

On Wed, Feb 17, 2016 at 07:17:31PM +0100, Matthias Klose wrote:
> Package: src:librevenge
> Version: 0.0.4-3
> 
> $ find debian/librevenge-0.0-0-dbgsym
> debian/librevenge-0.0-0-dbgsym
> debian/librevenge-0.0-0-dbgsym/usr
> debian/librevenge-0.0-0-dbgsym/usr/share
> debian/librevenge-0.0-0-dbgsym/usr/share/gdb
> debian/librevenge-0.0-0-dbgsym/usr/share/gdb/auto-load
> debian/librevenge-0.0-0-dbgsym/usr/share/gdb/auto-load/usr
> debian/librevenge-0.0-0-dbgsym/usr/share/gdb/auto-load/usr/lib
> debian/librevenge-0.0-0-dbgsym/usr/share/gdb/auto-load/usr/lib/Makefile
> debian/librevenge-0.0-0-dbgsym/usr/share/gdb/auto-load/usr/lib/librevenge-0.0.py
> debian/librevenge-0.0-0-dbgsym/usr/share/gdb/auto-load/usr/lib/librevenge-stream.py.in
> debian/librevenge-0.0-0-dbgsym/usr/share/gdb/auto-load/usr/lib/Makefile.am
> debian/librevenge-0.0-0-dbgsym/usr/share/gdb/auto-load/usr/lib/librevenge.py.in
> debian/librevenge-0.0-0-dbgsym/usr/share/gdb/auto-load/usr/lib/Makefile.in
> debian/librevenge-0.0-0-dbgsym/usr/share/gdb/auto-load/usr/lib/librevenge-stream-0.0.py
> debian/librevenge-0.0-0-dbgsym/usr/share/librevenge
> debian/librevenge-0.0-0-dbgsym/usr/share/librevenge/python
> debian/librevenge-0.0-0-dbgsym/usr/share/librevenge/python/util
> debian/librevenge-0.0-0-dbgsym/usr/share/librevenge/python/util/printing.py
> debian/librevenge-0.0-0-dbgsym/usr/share/librevenge/python/util/__init__.py
> debian/librevenge-0.0-0-dbgsym/usr/share/librevenge/python/util/compatibility.py
> debian/librevenge-0.0-0-dbgsym/usr/share/librevenge/python/__init__.py
> debian/librevenge-0.0-0-dbgsym/usr/share/librevenge/python/v0_0
> debian/librevenge-0.0-0-dbgsym/usr/share/librevenge/python/v0_0/__init__.py
> debian/librevenge-0.0-0-dbgsym/usr/share/librevenge/python/v0_0/types.py
> debian/librevenge-0.0-0-dbgsym/usr/share/librevenge/python/v0_0/streams.py

Yeah, there's a rm -rf missing probably.
That they are installed is intended, though.

Regards,

Rene

Bug#753800: tracker.debian.org: please give the details link some content

[Francesco Poli]

Control: reopen -1


On Wed, 10 Feb 2016 12:04:05 +0100 Raphael Hertzog wrote:

[...]
> Instead of the expected octicons in the "versioned links" panel, we had
> a dump of the dict returned by the octicon function. Also you used
> "toggle-chevron" instead of "toggle_chevron" in two places.
> 
> I also made some other changes, cf attached patch.

Hello Raphael,
since this change went online, I have experienced an awkward behavior
with Iceweasel: if I visit a tracker page with the JavaScript
interpreter disabled, I see many rectangles with unicode exadecimal
digits in them (as if the browser were trying to display characters
without finding an appropriate gliph among the installed fonts).
Please see the attached "tracker_on_iceweasel_no_js.png" screenshot.

As soon as I enable the JavaScript interpreter for tracker.debian.org
(by using the NoScript Iceweasel extension), I see the correct symbols.
Please see the attached "tracker_on_iceweasel_with_js.png" screenshot.

I cannot understand why JavaScript should be needed: I hope that this
requirement may be dropped.
I am reopening the bug report.

Thanks for your time (and thanks for the many improvements that the
tracker has seen so far).


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


pgplsZD8w6Er9.pgp
Description: PGP signature

Bug#739768:

[Aaron C. de Bruyn]

Bug still exists on Debian 8.3.

Running:

chmod g+r /etc/krb5.keytab

fixes the issue.

-A

Bug#754121: AICCU not starting on boot in Debian

[Jeroen Massar]

On 2016-02-17 19:26, Mark Brown wrote:
> On Wed, Feb 17, 2016 at 05:46:53PM +0100, Jeroen Massar wrote:
>> On 2016-02-17 17:00, Mark Brown wrote:
> 
>>> Right, but I do think AICCU can deal better with this situation.  Not
>>> dealing with it makes system integration much harder as there are a
>>> range of options that users have for configuring their network in most
>>> distributions
> 
>> Which 'options' are not properly handled? What is the real actual
>> problem you are trying to solve?
> 
> The case that is most difficult for me to eliminate in my system is that
> where both the router and the modem (which are separate devices) are
> being started at the same time.  AICCU is running on the router, it will
> most likely have a connection to the modem prior to the modem uplink
> being ready.  I am particularly concerned about this for unattended
> boots (for example, after power loss) but it'd be nice if it worked in
> general.

Sounds like you need to wait for the network to be operational before
starting AICCU

No VPN-alike tool does such a thing. OpenVPN for instance also nicely
aborts as it can't do anything with that situation. SSH tunnels also
nicely state "no network".

>>> including off-system network connectivity like
>>> routers which the distribution has little chance to integrate with).
> 
>> You know this Internet thing, it is rather big, lots of routers are
>> involved in a typical connection, only few a user has control over, let
> 
> I am aware of this, thanks.
> 
>> alone zero that AICCU can do anything about.
> 
> I'd argue that AICCU can do things to help.

It is helping: it logs an error message stating you to fix your network.

It cannot guess what the problem is. Keeping on restarting is not the
answer that will solve all the situations, and it cannot know what the
situation is, or when it will be fixed.

If you "only start it 5 times", it might be that your network is ready
at attempt 6 or maybe very briefly at attempt 12.

>>> I disagree here.  While it is true that AICCU can not resolve this issue
>>> for itself I think it can handle it more gracefully, it can sit and keep 
>>> trying so that when the situation is resolved then AICCU will recover.
> 
>> How long should it keep on hammering on services for the situation to
>> resolve itself?
> 
> I'd expect it to try indefinitely.  I'd not expect it to hammer on
> things but rather to try periodically.

Your logs will love being spammed with that amount of activity.

It is not a solution in any way: fix your network instead.

>>> This is more in line with what other services like mail servers
> 
>> You mean a mail client (MUA) like Thunderbird I hope.
> 
>> Guess what that does, indeed, it shows an error to the user that the
>> connection fails.
> 
>> Mail servers are a quite different kind of beast, they do not sit at a
>> user end.
> 
> I actually mean both (basically, anything that maintains a queue could
> have such behaviour

AICCU, nor any kind of VPN, has any kind of "queue".

> - there are simple MTAs specifically designed for
> centralizing the mail queue on a system, this is useful as it allows
> utilities to do e-mail without requiring configuration duplication or
> wheel reinvention).

AICCU is not such a tool you are describing in any way or form.

> The text mail clients I use use a central MTA and
> just return as soon as they've handed over to it, Evolution just
> silently queues things for sending at a later time unless you've started
> an explicit sync operation (or did last time I checked anyway).

A MUAs send directly to a MTA. That your MTA keeps on retrying is one
thing, when your MUA can't reach the MTA though it will fail and state
that by logging an error or presenting it.

>>> or things like ypbind
> 
>> ypbind also nicely bails out when there is no connectivity. No need to
>> keep on trying something it cannot resolve.
> 
> No, it doesn't - it will just sit there in in the background and retry
> periodically.  Distro init scripts will tend to wait for it to bind in
> order to support other things that might want to use the binding but the
> daemon itself will happily sit there.  At least in the Debian case we
> wait for a while and then just carry on, leaving ypbind running in the
> background.

The most important differentiator is that ypbind is contacting servers
that you are controlling or are affiliated with. Hammering on that is
fine, doing that to other people's servers is not acceptable though.

>>> do - they start up, attempt to perform their
>>> functions and retry if those fail.  It's also more in line with what
>>> happens if there is a connectivity interruption after the daemon has
>>> started.
> 
>> I'll repeat it again AICCU handles connectivity failures AFTER start
>> (fetching the config from TIC) perfectly fine
> 
> Right, and what I'm saying is that it would be much more helpful if it
> were able to handle failures at startup in a similar fashion.

It handles it fine: it 

Bug#686777: libopus-custom, temporary workaround and suggestion.

[Petter Reinholdtsen]

Hi.  Is there any hope to solve the jack/opus issue?  Been a while
since the BTS report saw any update.
-- 
Happy hacking
Petter Reinholdtsen

Bug#808433:

[Arnout Engelen]

I've done a non-maintainer upload of an updated package:

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

Would love for someone to sponsor the upload!

On Tue, Feb 16, 2016 at 11:09 PM, S. G.  wrote:

> Another +1 for fixing in Jessie.
>
> I am badly missing this tool right now.
>
> On Sun, 24 Jan 2016 01:14:29 + Chris Bainbridge <
> chris.bainbri...@gmail.com> wrote:
> > +1 for fixing in Jessie.
> >
> > Also bug #811273 appears to be a dupe of this one.
> >
> >
>
>

Bug#796931: [pkg-gnupg-maint] Bug#796931: gnupg-agent: no longer writes $GNUPGHOME/gpg-agent-info-$(hostname) file

[Thorsten Glaser]

Daniel Kahn Gillmor dixit:

>Please let me know how this works for you.  I don't think anyone should

Didn’t I already post the code I’m using now, which works around
this bug?

bye,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Bug#815021: Acknowledgement (xen-create-image: update-grub in hook 82-install-grub-legacy does not update menu.lst)

[Brandon Bradley]

I found out how to fix the issue using this link.

https://linuxconfig.org/installation-of-deb-kernel-in-debian-chroot-environment

update-grub fails silently in chroot unless these mounts are done:

mount -o bind /proc ${prefix}/proc
mount -o bind /proc ${prefix}/dev

This is an upstream issue. I'll make a patch and submit there.

Cheers!
Brandon Bradley

On Wed, Feb 17, 2016 at 2:45 PM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Axel Beckert 
>
> If you wish to submit further information on this problem, please
> send it to 815...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 815021: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815021
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#813360: Overlayfs available on newer Linux kernel only

[Luca Falavigna]

Improved patch attached.

--
Cheers,
Luca
diff --git a/bin/sbuild-createchroot b/bin/sbuild-createchroot
index 2371999..4bfb73f 100755
--- a/bin/sbuild-createchroot
+++ b/bin/sbuild-createchroot
@@ -307,10 +307,23 @@ root-groups=root,sbuild
 profile=sbuild
 EOF
 } else {
+
+# Determine whether system has overlayfs capability
+my $uniontype = "union-type=none";
+if (lc("$^O") =~ /linux/) {
+system("/sbin/modprobe overlay");
+if (open(FILE, "/proc/filesystems")) {
+if (grep {/\soverlay$/} ) {
+$uniontype = "union-type=overlay";
+}
+close(FILE);
+}
+}
+
 $config_entry = <<"EOF";
 [$chrootname]
 type=directory
-union-type=overlay
+$uniontype
 description=Debian $suite/$arch autobuilder
 directory=$target
 groups=root,sbuild

Bug#815020: breaks coredump handling for systems without systemd-coredump

[Felipe Sateler]

On 17 February 2016 at 13:12, Wouter Verhelst  wrote:
> Package: systemd
> Version: 229-1
>
> Hi,
>
> systemd contains the following line (src/core/main.c):
>
> (void) 
> write_string_file("/proc/sys/kernel/core_pattern", "|/bin/false", 0);
>
> The intent is that at some later point, systemd-coredump is started,
> which then sets it to something more useful.

Note that "systemd-coredump is started" means exactly "set it to
something more useful" systemd-coredump does not run as a daemon, but
rather is invoked by the kernel.

>
> However, in Debian, systemd-coredump is in a separate package that
> systemd itself does not depend on. As a result, if systemd is used as
> PID1, but systemd-coredump is not installed, all core dumps are thrown
> into the bit bucket; not just those that are generated during bootup,
> but all core dumps after boot, too.
>
> They're still generated, however, since systemd also sets the default
> soft resource limit on core file size ("ulimit -c") to the "unlimited"
> value, rather than having the hard limit be unlimited and the soft limit
> be set at 0.

Apparently, if the core_pattern is a program, then the limit is
ignored by linux, and should instead be honored by the called program.

> This is not an ideal situation:
> - Generating a core dump, especially in case of a program that uses a
>   lot of memory at the time where the dump is generated, requires some
>   processing. If the core dump is thrown away, this is wasted processing
>   time. If the system is loaded (e.g., because something is forking and
>   segfaulting a lot), this is problematic behaviour. By setting the soft
>   core file size resource limit to 0, core dumps aren't even generated,
>   improving performance.

How much resources does this actually consume? If the receiving
process does nothing, I don't think there would be much effect going
on.

According to this (anectodic) upstream list post, the cost is negligible

http://article.gmane.org/gmane.comp.sysutils.systemd.devel/31244/match=core_pattern

> - The kernel.core_pattern sysctl setting is a system-wide setting; it is
>   not possible to modify this other than by using CAP_SYS_ADMIN (IIUC)
>   permissions. In contrast, the resource limits are per-process
>   configuration; any process can change its resource limits at will.
>   This allows the system to have a default of "no core dumps", but at
>   the same time, allows a developer or a system administrator to
>   temporarily enable core dumps for a particular process, without
>   requiring administrator capabilities.

Because systemd-coredump respects rlimit, if systemd did not change
the rlimit then it wouldn't work by default: meaning that
systemd-coredump would have to somehow tell systemd (maybe at install
time) to change the default rlimit to something saner, but without
interfering with any admin changes.

Because systemd conf snippets are always read after the main
configuration file, it means that systemd-coredump cannot ship a
system.conf snippet altering the default rlimit, because it would
override admin changes in system.conf.

>
> I'm sure systemd-coredump replicates some of the above, but it isn't
> always the best choice to have a core dump be piped into a process, and
> therefore using the traditional "just dump everything to disk" logic can
> still be beneficial.

It can still be restored via a sysctl.d snippet, and the rlimit via system.conf.

Maybe this should be documented somewhere on upgrades?

-- 

Saludos,
Felipe Sateler

Bug#810970: needrestarts suggests only dbus, but ignores other services

[Thomas Liske]

tag 810970 upstream fixed-upstream pending
severity 810970 grave
found 810970 2.3-1
thanks

Hi Andreas,

On Fri, Jan 15, 2016 at 12:02:20PM +0100, Andreas Schmidt wrote:
> Hi, Thomas!

sorry for the long delay... I was just to busy...

> On 01/14/2016 01:18:59 PM, Thomas Liske wrote:
> >Hi Andreas,
> >
> >could you please provide the output of `needrestart -r`? Please
> >provider another checkrestart output if you did restart the system in
> >the meantime.
> Here it is -- hope it helps!

The output of needrestart indeed did look very suspicious. It seems
that needrestart 2.3 - 2.5 did not report processes using obsolete
mapped files any more. Those processes being reported were detected
due to the interpreters heuristic. Looking at the code I've found a
dumb commit by myself which had killed the parsing of /proc/$PID/maps
completly :-/

Since needrestart did still report some process due to perl or python
updates the bug was not that obvious (to me).

This issue has been fixed upstream and I've released needrestart
2.6. Hopefully Patrick is going to upload it ASAP.


HTH,
Thomas

--

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#814805: pyscard: Dropped python-pyscard without explanation

[Ludovic Rousseau]

On Mon, 15 Feb 2016 16:12:00 +0100 =?utf-8?q?Rapha=C3=ABl_Hertzog?= 
 wrote:

Source: pyscard
Version: 1.9.2-1
Severity: serious
User: de...@kali.org
Usertags: origin-kali

This version of pyscard dropped the Python 2 version without any
explanation on why this was needed. In the process, you made
yubioath-desktop uninstallable (as well as another package
which is only available in Kali).


The move to Python 3 was not really needed. But since the upstream code is now 
working with Python 3 it was a good idea to provide python3-pyscard.


Please restore the Python 2 version of the module.


OK. I will try to work on it.

A patch for 
https://anonscm.debian.org/cgit/python-modules/packages/pyscard.git/ would 
greatly help.

Thanks

--
Dr. Ludovic Rousseau

Bug#815006: yay yay yay

[Holger Levsen]

Hi,

just wanted to say "yay" & big thanks to everyone involved!


cheers,
Holger

and we're not there yet… but… yay! :-)


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

Bug#815016: iceweasel: Crashes randomly when playing videos on YouTube

[Yuriy M. Kaminskiy]

Backtrace looks similar to (unresolved)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799632

Bug#813452: fpc-3.0 regression in armhf and armel architectures

[Paul Gevers]

Hmm, I was a tiny little bit wrong earlier.

I modified hedgewars a tiny bit (patch attached) and build in on
debomatic¹. You can see that the failing line reads:
"Lua test file specified: /<>/tests/lua/hellfire_burns.lua"

When I grep for the beginning of that line I get only one answer:
paul@ruapehu ~/tmp/packages/hedgewars $ rgrep "Lua test file specified" *
hedgewars/ArgParsers.pas:{--lua-test}35 : begin
cTestLua := true; SetSound(false); cScriptName :=
getstringParameter(arg, paramIndex, parseParameter); WriteLn(stdout,
'Lua test file specified: ' + cScriptName);end;

So it wasn't stderr, but stdout.

Anyways, it now fails for an access violation. I don't like this at all,
but it is hard to say if this is a fpc error or hedgewars'.

Paul

¹
http://debomatic-armhf.debian.net/distribution#unstable/hedgewars/0.9.22-dfsg-4+debug+elbrus/buildlog
Description: Writeln inside try/except statement
Author: Paul Gevers 
X-Dgit-Generated: 0.9.22-dfsg-4+debug+elbrus 
ad588659e3d59e33080149b6ce14f2f6f64fd2de

---

--- hedgewars-0.9.22-dfsg.orig/hedgewars/uUtils.pas
+++ hedgewars-0.9.22-dfsg/hedgewars/uUtils.pas
@@ -464,7 +464,16 @@ end;
 
 procedure WriteLn(var f: textfile; s: shortstring);
 begin
-system.writeln(f, s)
+   {$I+}
+   try
+   system.writeln(f, s);
+   except
+   on E: EInOutError do
+   begin
+   system.writeln('File handling error occurred. Details: ', E.ClassName, 
'/', E.Message);
+   system.writeln(s);
+   end;
+   end
 end;
 
 function StrLength(s: PChar): Longword;


signature.asc
Description: OpenPGP digital signature

Bug#794947: manpages-dev: printf(3) example: possible integer overflow

[walter harms]

Am 17.02.2016 13:40, schrieb Stéphane Aulery:
> retitle 794947 printf(3): possible integer overflow in make_message example
> severity 794947 wishlist
> tags 794947 + confirmed
> tags 794947 + upstream
> forwarded 794947 linux-...@vger.kernel.org
> stop
> 
> -
> 
> Hello Walter,
> 
> Jakub Wilk reported a possible integer overflow in make_message example :
> 
>> The example in the printf(3) manpages looks like this (with boring parts
>> omitted):
>>
>> int n;
>> /* ... */
>>   n = vsnprintf(p, size, fmt, ap);
>>/* ... */
>>if (n < 0) {
>>/* ... */
>>return NULL;
>>}
>>/* ... */
>>size = n + 1;
>>
>>
>> But vsnprintf could return INT_MAX, which would then cause "n + 1" to
>> overflow.
>>
>> (AFAICS, the glibc vsnprintf implementation never returns INT_MAX, but
>> it could in principle.)
>>
>> I'd suggest changing "n < 0" to "n < 0 || n == INT_MAX".
> 
> 

Hi,

the bug is real, the type of size should be size_t (in my original post it was 
int)
That would make the error check useless, so we would need to store
the vsnprintf return value in an int.

The problem is that the idea was to have a simple example and cluttering
it with error checks will make it hard to read. How many people would
notice that size_t is unsigned and n is signed ? (i added an comment).

IMHO we should simply add a sentence that "examples are examples and
will not check for every possible error condition."

re,
 wh

#include 
#include 
#include 

char *
make_message2 (const char *fmt, ...)
{
  int n = 0;
  size_t size=0;
  char *p = NULL;
  va_list ap;

  /* figure our required size */
  va_start (ap, fmt);
  n = vsnprintf (p, size, fmt, ap);
  va_end (ap);

  if (n < 0)
return NULL;

  /* size is unsigned */
  size=n;

  /* leave room for \0 */
  size++;
  p = malloc (size);
  if (p == NULL)
return NULL;

  va_start (ap, fmt);
  n = vsnprintf (p, size, fmt, ap);
  va_end (ap);

return p;
}




> Since this example has been modified by you (Walter Harms), after the
> bug #794947 [1] has been reported, I wanted to ask your opinion on the
> best option.
> 
> Should we add this test to good practice, or rather a comment to mention
> that the case is not taken into account because the example uses glibc?
> 
> Regards,
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794947
> 

Bug#814822: libpam-pkcs11: pam_pkcs11.so exit with error if on of multiple certificates

[Ludovic Rousseau]

Le 15/02/2016 18:14, Gabriel Sailer a écrit :

Package: libpam-pkcs11
Version: 0.6.8-4
Severity: normal

On my PKI Card are six certificates:

DEBUG:pkcs11_lib.c:1383: login as user CKU_USER
DEBUG:pkcs11_lib.c:1577: Saving Certificate #1:
DEBUG:pkcs11_lib.c:1579: - type: 00
DEBUG:pkcs11_lib.c:1580: - id:   be
DEBUG:pkcs11_lib.c:1577: Saving Certificate #2:
DEBUG:pkcs11_lib.c:1579: - type: 00
DEBUG:pkcs11_lib.c:1580: - id:   df
DEBUG:pkcs11_lib.c:1577: Saving Certificate #3:
DEBUG:pkcs11_lib.c:1579: - type: 00
DEBUG:pkcs11_lib.c:1580: - id:   3b
DEBUG:pkcs11_lib.c:1577: Saving Certificate #4:
DEBUG:pkcs11_lib.c:1579: - type: 00
DEBUG:pkcs11_lib.c:1580: - id:   39
DEBUG:pkcs11_lib.c:1577: Saving Certificate #5:
DEBUG:pkcs11_lib.c:1579: - type: 00
DEBUG:pkcs11_lib.c:1580: - id:   7b
DEBUG:pkcs11_lib.c:1577: Saving Certificate #6:
DEBUG:pkcs11_lib.c:1579: - type: 00
DEBUG:pkcs11_lib.c:1580: - id:   62
DEBUG:pkcs11_lib.c:1612: Found 6 certificates in token

Some of them are for email en-/decryption and one is for authenticaten (see
below).
The some certificates are expired, but are needed to read older encrypted 
emails.
The Problem is now, that pam_pkcs11.c returned an error after validating then
first certificate with 'certificate has expired':

DEBUG:pam_pkcs11.c:551: verifying the certificate #1
verifying certificate
DEBUG:cert_vfy.c:338: Adding hashdir lookup to x509_store
DEBUG:cert_vfy.c:350: Adding hash dir '/etc/pam_pkcs11/cacerts' to CACERT
checks
DEBUG:cert_vfy.c:357: Adding hash dir '/etc/pam_pkcs11/crls' to CRL checks
ERROR:pam_pkcs11.c:559: verify_certificate() failed: certificate is invalid:
certificate has expired
Error 2324: Certificate has expired
DEBUG:mapper_mgr.c:213: unloading mapper module list
DEBUG:mapper_mgr.c:137: calling mapper_module_end() mail
DEBUG:mapper_mgr.c:148: Module mail is static: don't remove
DEBUG:mapper_mgr.c:137: calling mapper_module_end() subject
DEBUG:mapper_mgr.c:148: Module subject is static: don't remove
DEBUG:mapper_mgr.c:137: calling mapper_module_end() digest
DEBUG:mapper_mgr.c:148: Module digest is static: don't remove
DEBUG:mapper_mgr.c:137: calling mapper_module_end() cn
DEBUG:mapper_mgr.c:148: Module cn is static: don't remove
DEBUG:pkcs11_lib.c:1443: logout user
DEBUG:pkcs11_lib.c:1450: closing the PKCS #11 session
DEBUG:pkcs11_lib.c:1456: releasing keys and certificates
Password:

I think this is an error. Invalid certificates should be removed from the
certificate array and the validation process should check the next certificate.

The second problem at this case is, that it seems not be possible to select the
certificate with pattern matching on the 'object label' e.g.:

Public Key Object; RSA 1024 bits
   label:  gabriel.sailer ENC 22
   ID: 
   Usage:  encrypt, verify, wrap
Public Key Object; RSA 2048 bits
   label:  gabriel.sailer AUT 10
   ID: 
   Usage:  encrypt, verify, wrap
Public Key Object; RSA 2048 bits
   label:  gabriel.sailer ENC 11
   ID: 
   Usage:  encrypt, verify, wrap
Public Key Object; RSA 2048 bits
   label:  gabriel.sailer ENC 21
   ID: 
   Usage:  encrypt, verify, wrap
Public Key Object; RSA 1024 bits
   label:  gabriel.sailer ENC 23
   ID: 
   Usage:  encrypt, verify, wrap
Public Key Object; RSA 2048 bits
   label:  gabriel.sailer ENC 24
   ID: 
   Usage:  encrypt, verify, wrap
Secret Key Object; unknown key algorithm 21
   label:  Challenge/Response 3DES Key 01
   ID: 43524b3031
   Usage:  verify
Certificate Object, type = X.509 cert
   label:  gabriel.sailer ENC 22
   ID: 
Certificate Object, type = X.509 cert
   label:  gabriel.sailer AUT 10
   ID: 
Certificate Object, type = X.509 cert
   label:  gabriel.sailer ENC 11
   ID: 
Certificate Object, type = X.509 cert
   label:  gabriel.sailer ENC 21
   ID: 
Certificate Object, type = X.509 cert
   label:  gabriel.sailer ENC 23
   ID: 
Certificate Object, type = X.509 cert
   label:  gabriel.sailer ENC 24
   ID: 

A pattern match with the string '.* AUT 10$' could select the right
certificate, also if there are more the on valid certificates are on the PKI
card.

There could be also a problem with the clr list, if they are only accessable 
via a user/password protected proxy server. This could be if a part of the 
company is outsourced and get an new domainname.
May be it should be possible to allow ignoring crl *on there own 

Bug#814875: [Debian-med-packaging] Bug#814875: libsis-jhdf5-java: FTBFS: jni.h:45:20: fatal error: jni_md.h: No such file or directory

[Michael Crusoe]

I've attached a patch
You'll need to make use of the `jvm_includes` variable that /usr/share/java/
java_defaults.mk defines.
On Wed, Feb 17, 2016 at 10:03 PM Andreas Tille  wrote:

> Sorry, but do you have a better hint for me since my attempt below did
> not change anything?
>
> Kind regards
>
>   Andreas.
>
> On Tue, Feb 16, 2016 at 01:42:29PM +0100, Andreas Tille wrote:
> > On Tue, Feb 16, 2016 at 11:44:20AM +0100, Emmanuel Bourg wrote:
> > > Le 16/02/2016 11:19, Andreas Tille a écrit :
> > >
> > > > I wonder whether this might be a missing symlink or so inside
> > > > openjdk-8-jdk?
> > >
> > > openjdk-8 changed some symlinks (see #760301). There is a make fragment
> > > available in /usr/share/java/java_defaults.mk defining the right
> include
> > > option for the current JDK.
> >
> > In case you wanted to provide a hint to do
> >
> > diff --git a/debian/rules b/debian/rules
> > index 86df809..57139da 100755
> > --- a/debian/rules
> > +++ b/debian/rules
> > @@ -8,7 +8,7 @@ export
> TESTCLASSPATH=/usr/share/java/junit4.jar:/usr/share/java/testng.jar:/usr/
> >
> >  DPKG_EXPORT_BUILDFLAGS = 1
> >  include /usr/share/dpkg/buildflags.mk
> > -
> > +include /usr/share/java/java_defaults.mk
> >
> >  %:
> > dh $@ --with javahelper
> >
> >
> > I need to admit this does not change the situation.  Any more precise
> > hint?
> >
> > Kind regards
> >
> >   Andreas.
> >
> > --
> > http://fam-tille.de
> >
> >
>
> --
> http://fam-tille.de
>
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>
-- 
Michael R. Crusoe CWL Community Engineer cru...@ucdavis.edu

Common Workflow Language projectUniversity of California, Davis
https://impactstory.org/MichaelRCrusoe http://twitter.com/biocrusoe


libsis-jhdf5-java.patch
Description: Binary data

Bug#814875: libsis-jhdf5-java: FTBFS: jni.h:45:20: fatal error: jni_md.h: No such file or directory

[Andreas Tille]

Sorry, but do you have a better hint for me since my attempt below did
not change anything?

Kind regards

  Andreas.

On Tue, Feb 16, 2016 at 01:42:29PM +0100, Andreas Tille wrote:
> On Tue, Feb 16, 2016 at 11:44:20AM +0100, Emmanuel Bourg wrote:
> > Le 16/02/2016 11:19, Andreas Tille a écrit :
> > 
> > > I wonder whether this might be a missing symlink or so inside
> > > openjdk-8-jdk?
> > 
> > openjdk-8 changed some symlinks (see #760301). There is a make fragment
> > available in /usr/share/java/java_defaults.mk defining the right include
> > option for the current JDK.
> 
> In case you wanted to provide a hint to do
> 
> diff --git a/debian/rules b/debian/rules
> index 86df809..57139da 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -8,7 +8,7 @@ export 
> TESTCLASSPATH=/usr/share/java/junit4.jar:/usr/share/java/testng.jar:/usr/
> 
>  DPKG_EXPORT_BUILDFLAGS = 1
>  include /usr/share/dpkg/buildflags.mk
> -
> +include /usr/share/java/java_defaults.mk
> 
>  %:
> dh $@ --with javahelper
> 
> 
> I need to admit this does not change the situation.  Any more precise
> hint?
> 
> Kind regards
> 
>   Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Bug#814352: ITP: veracrypt -- Cross-platform on-the-fly encryption

[Francesco Poli]

On Wed, 17 Feb 2016 11:39:00 + Mike Gabriel wrote:

[...]
> (taking debian-edu-pkg-team @ Alioth into the discussion loop, as that  
> would be the maintainer team for VeraCrypt in Debian)

OK, fine.

> 
> On  Mi 17 Feb 2016 00:17:28 CET, Francesco Poli wrote:
> 
> > On Wed, 10 Feb 2016 18:07:48 +0100 Mike Gabriel wrote:
> >
> > [...]
> >>  1.
> >>  Is VeraCrypt suitable for the non-free section of Debian?
> >
> > I am not sure: the TC-3.0 license is still fairly unclear (at least
> > to my eyes), so I cannot really speculate on its possible
> > implications...
> 
> Hmmm... ok. I think the ftpmasters would be glad about some guidance  
> on why you see veracrypt (not the TC 3.0 license, see below) unfit for  
> Debian non-free. I have already uploaded VeraCrypt to Debian  
> NEW/non-free and it is waiting approval/rejection from an ftpmaster.

I didn't say that veracrypt is clearly unfit for the non-free archive.

I said that the TC-3.0 license is unclear, and that I am consequently
not sure about the possibility to distribute a package including code
under such a license (even in the non-free archive).

I hope I clarified what I meant.

> 
> Also, it'd be interesting if the upstream people of VeraCrypt can  
> apply any change(s) to the upstream sources, their VeraCrypt license  
> or whatever, to make the software fit at least for Debian non-free.

If VeraCrypt upstream developers (IDRIX, I suppose) are in good terms
with the copyright holders for the Truecrypt version they forked from
(TrueCrypt Developers Association, I suppose) and can persuade them to
agree to a re-licensing of the code-base, the outcome could be
definitely interesting.
Everything re-licensed under the terms of the 3-clause-BSD license
would be a huge win for everyone, since it would mean the possibility
to upload veracrypt to Debian main (assuming no other showstopper comes
up).

[...]
> >>  3.
> >>  The new upstream maintainer also states that all novelties of the code
> >>  are licensed under the Apache-2.0 license, but as long as any line from
> >>  the original code sticks out, the licensing of the code is governed by
> >>  the original Truecrypt 3.0 license, right?
> > [...]
> >
> > Then I am not sure I understand why the debian/copyright file draft
> > you sent states
> >   Files: *
> >   Copyright: 2003-2011, TrueCrypt Developers Association
> >  2013-2014, IDRIX
> >   License: TC-3.0 or Ms-PL
> >
> > What's Ms-PL ? Shouldn't it be Apache-2.0 ?
> > Moreover, "or" means dual-licensing, but I understand this to be a
> > code-mixing case: I think "and" should be used instead.
> >
> > See
> > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> > for more details.
> 
> Oh, I am sorry. With this mail, I have attached the latest  
> debian/copyright file as I have it now after having it reworked two  
> days ago. I should have sent an updated copy to debian-legal  
> immediately. Sorry for that.

Mmmmh, I cannot see any attachment. Was it forgotten or lost somehow?

> 
> As it seems, the VeraCrypt upstream people have come up with a new  
> license, the VeraCrypt license. See attached copyright file for details.

Please send the updated debian/copyright file...

[...]
> > Anyway, without looking at any further details, a question arises:
> > why are you packaging veracrypt for the non-free archive? what does
> > it offer that tcplay doesn't?
> >
> > See
> > https://packages.debian.org/sid/tcplay
> > https://tracker.debian.org/pkg/tcplay
> 
> I have checked tcplay and also zulucrypt-gui again. We provide  
> veracrypt to teachers / students at school that come from the Windows  
> realm mainly. For them, it is essential to recognize some pieces of  
> software on our Linux environment that they have become so used to on  
> their Windows machines. VeraCrypt (for formerly TrueCrypt) is such an  
> application. Teachers here in Germany have to encrypt all personal  
> data that they carry around, so they need _one_ cross platform tool  
> for that. I'd be happy to provide that piece of software to other  
> people in Debian (Edu).
> 
> Working on the command line (tcplay) is not an option for the  
> teachers, we support here.

Then I hope someone will develop a GUI front-end for tcplay, if it is so
important for at least one category of users...

> And personally, I just tried out  
> zulucrypt-gui the second time and I could not get it running as  
> non-root. This is probably possible, I did not spend much time on  
> this, but honestly, I prefer a solution that works right away. Also  
> ZuluCrypt feels a little nerdy, not so user friendly as VeraCrypt  
> currently is.

Mmmmh, I see.


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


pgpZH9zK7itgB.pgp
Description: PGP signature

Bug#815021: xen-create-image: update-grub in hook 82-install-grub-legacy does not update menu.lst

[Brandon Bradley]

Package: xen-tools
Version: 4.5-1
Severity: important

Dear Maintainer,

I replaced 80-install-kernel hook with my own to modify kernel parameters. 
However,
when my image was built, the autogenerated GRUB entries with my kernel 
parameters
were not there. Running update-grub (on the guest) creates them as expected. So,
I rebuilt the image with `--verbose` and noticed that update-grub hangs during
82-install-grub-legacy. Here is the verbose output of that hook.


Running hook 82-install-grub-legacy 
['/usr/share/xen-tools/jessie.d/82-install-grub-legacy /tmp/sguSwihErx']
--
Script /usr/share/xen-tools/jessie.d/82-install-grub-legacy starting
Installing Debian packages --no-install-recommends grub-legacy to prefix 
/tmp/sguSwihErx
start-stop-daemon disabled / made a stub.
Reading package lists...
Building dependency tree...
Reading state information...
grub-legacy is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 14 not upgraded.
start-stop-daemon restored to working order.
Searching for GRUB installation directory ... found: /boot/grub
Script /usr/share/xen-tools/jessie.d/82-install-grub-legacy finished
--
Done


I've seen some old references to this happening, but they all had no replies.
No idea on this one.

Cheers!
Brandon Bradley


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

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

Versions of packages xen-tools depends on:
ii  debootstrap   1.0.67
ii  libconfig-inifiles-perl   2.83-3
ii  libdata-validate-domain-perl  0.10-1
ii  libdata-validate-ip-perl  0.24-1
ii  libdata-validate-uri-perl 0.06-1
ii  libfile-slurp-perl.19-4
ii  libfile-which-perl1.09-1
ii  libterm-ui-perl   0.42-1
ii  libtext-template-perl 1.46-1
ii  openssh-client1:6.7p1-5+deb8u1
ii  perl  5.20.2-3+deb8u3

Versions of packages xen-tools recommends:
ii  libexpect-perl   1.21-1
ii  rinse3.0.9
ii  xen-hypervisor-4.1-amd64 [xen-hypervisor-amd64]  4.1.4-3+deb7u5
ii  xen-hypervisor-4.4-amd64 [xen-hypervisor-amd64]  4.4.1-9+deb8u3
ii  xen-utils-4.1 [xen-utils]4.1.4-3+deb7u5
ii  xen-utils-4.4 [xen-utils]4.4.1-9+deb8u3

Versions of packages xen-tools suggests:
pn  btrfs-tools
pn  cfengine2  
pn  reiserfsprogs  
pn  xfsprogs   

-- Configuration Files:
/etc/xen-tools/xen-tools.conf changed [not included]

-- no debconf information

Bug#803249: needrestart: Restarts services in debconf noninteractive

[Thomas Liske]

tag 803249 upstream fixed-upstream -moreinfo
thanks

Hi,

On Fri, Jan 22, 2016 at 06:26:04PM -0700, Stephen Dowdy wrote:
> Thomas,
> 
> Summary:
> - using an auxiliary conf.d file seems to mostly work

but it was not perfect... it disables auto restart mode in case of
running noninteractive.

> - 'needrestart' should, however flag 'systemctl restart' notice with
> 'skipping' in this case?

It just lists the commands for copy'n'paste-on-demand ("Services to be
restarted:").

> - 'needrestart' should not prompt to read  on 'consider
> rebooting kernel' notification in this case

ACK


I've added a simple check in needrestart to handle debconf's
noninteractive frontend correctly. If noninteractive is used,
needrestart now behaves like there is no TTY attached to /dev/std*.


HTH,
Thomas
 
> (hostname)# cat /etc/needrestart/conf.d/debian_frontend_noninteractive.conf
> # Switch to list mode if debconf is running noninteractive
> # Ref: Bug#803249: needrestart: Restarts services in debconf noninteractive
> # Thomas Liske 
> 
> $nrconf{restart} = ( ($ENV{DEBIAN_FRONTEND} // '') eq 'noninteractive' ?
> 'l' : 'i');
> 
> 1;
> (changed it a tiny bit)
> 
> I ran an update on a system that hasn't been updated for quite some time,
> with :
> 
>19  DEBIAN_FRONTEND=noninteractive aptitude upgrade 2>&1 | tee
> /tmp/aptup.log
>20  grep -i -e restart -e systemctl /tmp/aptup.log
> 
> and nothing appeared in the log.  :-)
> 
> (hostname)# DEBIAN_FRONTEND='noninteractive' needrestart
> Scanning processes...
> Scanning candidates...
> Scanning kernel images...
> Services to be restarted:
> Skipping dbus.service...
> Skipping getty@tty1.service...
> Skipping kdm.service...
> Skipping NetworkManager.service...
> Skipping systemd-journald.service...
> systemctl restart acpid.service atd.service autofs.service
> console-kit-daemon.service cron.service dirmngr.service gpm.service
> inetd.service irqbalance.service mcelog.service mdmonitor.service
> nfs-common.service nis.service packagekit.service polkitd.service
> rpcbind.service sendmail.service smartd.service ssh.service udisks2.service
> upower.service user@0.service user@115.service user@3619.service
> 
> Looks like it's in list-only mode (still disconcerting to see the
> 'systemctl restart' line without a "Skipping"/"DEBUG" or other flagging
> prefix, but clearly it's not actually issuing restarts:
> 
> pomelo2:~# systemctl status acpid.service
> * acpid.service - ACPI event daemon
>Loaded: loaded (/lib/systemd/system/acpid.service; disabled)
>Active: active (running) since Sat 2015-11-28 10:30:26 MST; 1 months 24
> days ago
> ...
> 
> 
> (hostname)# needrestart
> Scanning processes...
> Scanning candidates...
> Scanning kernel images...
> 
> Graphic (curses) UI comes up, queries if i want to restart various services
> (i hit CANCEL)
> 
> BUT!
> (hostname)# DEBIAN_FRONTEND='noninteractive' needrestart -v
> ...
> Restarting the system to load the new kernel will not be handled
> automatically, so you should consider rebooting. [Return]
> ...
> 
> So, it still blocks there on a terminal read -- which it should not do if
> we're truly noninteractive (but, it obviously "Does The Right Thing(tm)"if
> stdin redirected from /dev/null.   Just would be nice if it did NOT prompt
> if it's non-interactive (even in verbose mode).
> 
> --stephen
> 
> On Fri, Jan 22, 2016 at 4:21 PM, Thomas Liske  wrote:
> 
> > Hi Stephen,
> >
> > On Fri, Jan 22, 2016 at 11:44:30AM -0700, Stephen Dowdy wrote:
> > > I believe the Felix is saying that 'needrestart' appears to be unaware of
> > > the common explicit DEBIAN_FRONTEND=noninteractive setting used to
> > indicate
> > > that package management should be non-interactive (and if not, then *I*
> > am)
> > >
> > > I will often use 'pdsh' to run forced package updates like so:
> > >
> > > $ cut -d: -f1 vulnerable.log | WCOLL=- pdsh -lroot 'aptitude update -q=2;
> > > DEBIAN_FRONTEND=noninteractive aptitude -q=2 safe-upgrade --assume-yes -o
> > > Dpkg::Options::="--force-confold"  > >
> > > Unfortunately, 'needrestart's 'isatty' style checks are insufficient for
> > my
> > > needs here, as STDERR/STDOUT are attached to a pty associated with the
> > > 'ssh' hitting all the systems i am updating...  I have no way of then
> > > telling 'needrestart' to not restart services
> > >
> > > So, i unexpectedly got a bunch of systemctl restart invocations, and i
> > find
> > > that often borks things badly.
> > >
> > > If 'needrestart' could also check ${DEBIAN_FRONTEND}, that would be
> > awesome.
> > >
> > > Otherwise, i suppose i will have to cfengine out a "Default No"
> > > needrestart.conf configuration to all my systems.
> >
> > you could try to put something like
> >
> > cat < > # Switch to list mode if debconf is running noninteractive
> > $nrconf{restart} = (exists($ENV{DEBIAN_FRONTEND}) &&
> > $ENV{DEBIAN_FRONTEND} eq 'noninteractive' ? 'l' : 'i');
> >
> > 1;
> > EOF
> >
> > into 

Bug#815020: breaks coredump handling for systems without systemd-coredump

[Wouter Verhelst]

Package: systemd
Version: 229-1

Hi,

systemd contains the following line (src/core/main.c):

(void) 
write_string_file("/proc/sys/kernel/core_pattern", "|/bin/false", 0);

The intent is that at some later point, systemd-coredump is started,
which then sets it to something more useful.

However, in Debian, systemd-coredump is in a separate package that
systemd itself does not depend on. As a result, if systemd is used as
PID1, but systemd-coredump is not installed, all core dumps are thrown
into the bit bucket; not just those that are generated during bootup,
but all core dumps after boot, too.

They're still generated, however, since systemd also sets the default
soft resource limit on core file size ("ulimit -c") to the "unlimited"
value, rather than having the hard limit be unlimited and the soft limit
be set at 0.

This is not an ideal situation:
- Generating a core dump, especially in case of a program that uses a
  lot of memory at the time where the dump is generated, requires some
  processing. If the core dump is thrown away, this is wasted processing
  time. If the system is loaded (e.g., because something is forking and
  segfaulting a lot), this is problematic behaviour. By setting the soft
  core file size resource limit to 0, core dumps aren't even generated,
  improving performance.
- The kernel.core_pattern sysctl setting is a system-wide setting; it is
  not possible to modify this other than by using CAP_SYS_ADMIN (IIUC)
  permissions. In contrast, the resource limits are per-process
  configuration; any process can change its resource limits at will.
  This allows the system to have a default of "no core dumps", but at
  the same time, allows a developer or a system administrator to
  temporarily enable core dumps for a particular process, without
  requiring administrator capabilities.

I'm sure systemd-coredump replicates some of the above, but it isn't
always the best choice to have a core dump be piped into a process, and
therefore using the traditional "just dump everything to disk" logic can
still be beneficial.

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-3
ii  libapparmor12.10-3
ii  libaudit1   1:2.4.5-1
ii  libblkid1   2.27.1-3
ii  libc6   2.21-8
ii  libcap2 1:2.24-12
ii  libcap2-bin 1:2.24-12
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20 1.6.5-2
ii  libgpg-error0   1.21-2
ii  libkmod222-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.27.1-3
ii  libpam0g1.1.8-3.2
ii  libseccomp2 2.2.3-3
ii  libselinux1 2.4-3
ii  libsystemd0 229-1
ii  mount   2.27.1-3
ii  util-linux  2.27.1-3

Versions of packages systemd recommends:
ii  dbus1.10.6-1
ii  libpam-systemd  229-1

Versions of packages systemd suggests:
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
ii  udev  229-1

-- no debconf information

Bug#814544: wheezy-pu: package clamav/0.99+dfsg-0+deb7u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2016-02-12 at 15:04 -0500, Scott Kitterman wrote:
> This is the follow-up to #807969 for wheezy.  Equivalent debdiff will be
> attached as a reply to the bug (since it's huge) to make sure the doesn't get
> blocked.
> 
> As with Jessie, this will require a small transition.  Clamav and libclamunrar
> will both need source uploads (prepared) and will hit New due to bumped so
> name. I'll file a separate bug for libclamunrar.  Additionally, four packages
> will need binNMUs:

Please go ahead.

Feel free to get the package name change fast-tracked through NEW. If
you do, please let us know so that we can spot it appearing in p-u (as
it'll bypass stable-new).

Regards,

Adam

Bug#812659: lex FTCBFS: runs tests even when DEB_BUILD_OPTIONS contains nockeck

[Manoj Srivastava]

tags 812659 + unreproducible moreinfo
thanks
Hi,

> I'm not sure what you changed here, but the issue persists after your
> upload, my patch is still applicable and it still fixes the issue.

Could you provide some details? When I ran
 DEB_BUILD_OPTIONS=nocheck ./debian/rules binary
  no tests were run; remove the variable setting and they are.

manoj
-- 
The flush toilet is the basis of Western civilization. Alan Coult
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Bug#815017: gdb info (thunar: Thunar segfaults when renaming a file)

[Kyle Bentley]

kyle@minilith:~$ gdb thunar
GNU gdb (Debian 7.10-1+b1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from thunar...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/thunar
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffed51e700 (LWP 915)]
[New Thread 0x7fffecd1d700 (LWP 916)]
[New Thread 0x7fffe7cce700 (LWP 918)]
[New Thread 0x7fffe4d78700 (LWP 923)]
[Thread 0x7fffe4d78700 (LWP 923) exited]
[New Thread 0x7fffe4d78700 (LWP 943)]
[Thread 0x7fffe7cce700 (LWP 918) exited]
[New Thread 0x7fffe7cce700 (LWP 948)]
[Thread 0x7fffe7cce700 (LWP 948) exited]

** (soffice:965): WARNING **: Invalidate all children called


** (soffice:965): WARNING **: Unknown event notification 38

** (soffice:965): WARNING **: Invalidate all children called

[Thread 0x7fffe4d78700 (LWP 943) exited]
[New Thread 0x7fffe4d78700 (LWP 989)]
[New Thread 0x7fffe7cce700 (LWP 990)]

Program received signal SIGSEGV, Segmentation fault.
__strcmp_sse2_unaligned () at
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:30
30../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such file
or directory.
(gdb) bt
#0  __strcmp_sse2_unaligned () at
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:30
#1  0x5559187d in thunar_file_compare_by_name ()
#2  0x5559fd8e in ?? ()
#3  0x74b76a04 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x74b76f4e in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x74b77d84 in g_sequence_insert_sorted_iter () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x74b77e4c in g_sequence_insert_sorted () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x5559fa48 in ?? ()
#8  0x74e32f45 in g_closure_invoke () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9  0x74e44f91 in ?? () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x74e4dd2c in g_signal_emit_valist () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x74e4e05f in g_signal_emit () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x555930be in ?? ()
#13 0x70433060 in ffi_call_unix64 () from
/usr/lib/x86_64-linux-gnu/libffi.so.6
#14 0x70432acb in ffi_call () from
/usr/lib/x86_64-linux-gnu/libffi.so.6
#15 0x74e33c95 in g_cclosure_marshal_generic_va () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#16 0x74e33174 in ?? () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x74e4d976 in g_signal_emit_valist () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x74e4e05f in g_signal_emit () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x7516f9d9 in ?? () from
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#20 0x74b5dfd7 in g_main_context_dispatch () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x74b5e230 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x74b5e552 in g_main_loop_run () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x76a1c587 in gtk_main () from
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#24 0x55577765 in ?? ()
#25 0x74573870 in __libc_start_main (main=0x55577330,
argc=1, argv=0x7fffe108, init=,
fini=, rtld_fini=,
stack_end=0x7fffe0f8) at libc-start.c:291
#26 0x5557789a in ?? ()
(gdb) quit
A debugging session is active.

Inferior 1 [process 911] will be killed.

Quit anyway? (y or n) y

Bug#794410: Debian Jessie installer freezes during "Processing triggers for libc-bin"

[Carlos Alberto Lopez Perez]

On 17/02/16 20:15, Carlos Alberto Lopez Perez wrote:
> 
> I wonder what can be causing this issue :\
> 
> I already had this issue when installing a fresh Debian 8 in another
> machine, but in that one only happened once. After a hard-reboot and a
> retry it worked. With this Intel NUC machine happened everytime of the 4
> times I tried to install it.

Seems the freeze is reproducible on the installed system (with Debian Jessie 
and the default 3.16.0-4-amd64 kernel) by running:

$ discover-modprobe

If i run it with -x i see that it freezes here:

 readlink -f /sbin/discover-modprobe
+++ '[' 0 = 1 ']'
++ FANCYTTY=
++ '[' -e /etc/lsb-base-logging.sh ']'
++ true
+ . /etc/default/rcS
+ '[' -d /var/discover ']'
+ nop=
+ verbose=false
+ getopts nv ch
+ shift 0
++ grep -E -v '^ *$'
+++ uname -r
++ /sbin/discover --data-path=linux/module/name 
--data-path=linux/module/options '--format=%s %s' --data-version=3.16.0-4-amd64 
all


And If i run the above comand with strace -f, then it freezes here:


read(3, "C Camera/Webcam controller'/>\n  "..., 4096) = 4096
brk(0x145e000)  = 0x145e000
read(3, "een'/>\n  \n  \n  \n  \n"..., 4096) = 1459
read(3, "", 4096)   = 0
read(3, "", 4096)   = 0
close(3)= 0
munmap(0x7f598aea2000, 4096)= 0
open("/proc/bus/usb/devices", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 5 entries */, 32768) = 120
close(3)= 0
openat(AT_FDCWD, "/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 5 entries */, 32768) = 120
getdents(3, /* 0 entries */, 32768) = 0
close(3)= 0
openat(AT_FDCWD, "/dev/bus/usb/003", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) 
= 3
getdents(3, /* 4 entries */, 32768) = 96
open("/dev/bus/usb/003/002", O_RDWR


It don't freezes always, only sometimes.

Comparing the straces from when it freezes which the straces when it doesn't I 
see the following difference:

* This is when it works ok (don't freezes):


openat(AT_FDCWD, "/dev/bus/usb/003", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) 
= 3
getdents(3, /* 3 entries */, 32768) = 72
open("/dev/bus/usb/003/001", O_RDWR)= 4


* This is when it freezes:

openat(AT_FDCWD, "/dev/bus/usb/003", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) 
= 3
getdents(3, /* 4 entries */, 32768) = 96
open("/dev/bus/usb/003/002", O_RDWR


Seems that when it freezes it finds 4 entries in the directory /dev/bus/usb/003 
instead of 3,
and when it tries to open the "ghost" entry it freezes completely.

ls -al /dev/bus/usb/003 gives 3 entries : (".", "..", "001")

I have been rebooting it a couple of times and doing an ls to see if I see 4 
entries.
And when i get 4 entries, trying to access it causes a freeze.

ls -al /dev/bus/usb/003
total 0
drwxr-xr-x 2 root root   80 Feb 17 20:51 .
drwxr-xr-x 5 root root  100 Feb 17 20:51 ..
crw-rw-r-- 1 root root 189, 256 Feb 17 20:51 001
crw-rw-r-- 1 root root 189, 257 Feb 17 20:51 002


$ lsusb
# <... freeze>

The information about /dev/bus/usb/003 is:

# lsusb -D /dev/bus/usb/003/001 
Device: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 3 
  bMaxPacketSize0 9
  idVendor   0x1d6b Linux Foundation
  idProduct  0x0003 3.0 root hub
  bcdDevice3.16
  iManufacturer   3 Linux 3.16.0-4-amd64 xhci_hcd
  iProduct2 xHCI Host Controller
  iSerial 1 :00:14.0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   31
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0004  1x 4 bytes
bInterval  12
bMaxBurst   0
Hub Descriptor:
  bLength  12
  

Bug#815019: xfce4-power-manager: uses much memory when running for several days

[Roland Hieber]

Package: xfce4-power-manager
Version: 1.4.4-4
Severity: normal

Dear Maintainer,

I use xfce4-power-manager on an awesome desktop, and I usually suspend my
computer into suspend-to-RAM at least daily.  I noticed that I have to restart
the power manager after it has been running for some days, since it tends to use
much memory.  For example, the current instance has been running for 7 days now,
and (according to top) is using about 446M RES. When I restart it, it is usually
about 15M RES.

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

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

Versions of packages xfce4-power-manager depends on:
ii  libc6 2.21-7
ii  libcairo2 1.14.6-1
ii  libdbus-1-3   1.10.6-1
ii  libdbus-glib-1-2  0.106-1
ii  libgdk-pixbuf2.0-02.32.3-1.2
ii  libglib2.0-0  2.46.2-3
ii  libgtk2.0-0   2.24.29-1
ii  libnotify40.7.6-2
ii  libpango-1.0-01.38.1-1
ii  libpangocairo-1.0-0   1.38.1-1
ii  libupower-glib3   0.99.3-1+b3
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxfce4ui-1-04.12.1-2
ii  libxfce4util7 4.12.1-2
ii  libxfconf-0-2 4.12.0-2+b1
ii  libxrandr22:1.5.0-1
ii  upower0.99.3-1+b3
ii  xfce4-power-manager-data  1.4.4-4

Versions of packages xfce4-power-manager recommends:
ii  libpam-systemd   228-6
pn  xfce4-power-manager-plugins  

xfce4-power-manager suggests no packages.

-- debconf-show failed

Bug#815018: q4wine: wizard does not preload debian default library paths

[Alberto Fuentes]

Package: q4wine
Version: 1.2-r2-1
Severity: normal

Debian should preload this values with the one used in debian. I was not able
to find the proper paths either.

I tried /usr/lib/i386-linux-gnu/wine/ without success

Thanks!



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

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

Versions of packages q4wine depends on:
ii  icoutils   0.31.0-3
ii  libc6  2.21-7
ii  libgcc11:5.3.1-7
ii  libqt5core5a   5.5.1+dfsg-13
ii  libqt5dbus55.5.1+dfsg-13
ii  libqt5gui5 5.5.1+dfsg-13
ii  libqt5network5 5.5.1+dfsg-13
ii  libqt5sql5 5.5.1+dfsg-13
ii  libqt5sql5-sqlite  5.5.1+dfsg-13
ii  libqt5widgets5 5.5.1+dfsg-13
ii  libqt5xml5 5.5.1+dfsg-13
ii  libstdc++6 5.3.1-7

Versions of packages q4wine recommends:
ii  sudo  1.8.15-1.1
ii  wget  1.17.1-1+b1
ii  wine  1.8-6
ii  wine-development  1.7.55-4
ii  winetricks0.0+20151116-1

Versions of packages q4wine suggests:
pn  fuseiso  

-- no debconf information

Bug#801253: Fwd: Re: reason not to upload new versions as fast as possible to unstable? (expect attempt to migrate to testing )

[toogley]

forgot to reply all


 Forwarded Message 
Subject: Re: reason not to upload new versions as fast as possible to 
unstable? (expect attempt to migrate to testing )

Date: Wed, 17 Feb 2016 19:59:02 +0100
From: toogley 
To: Gianfranco Costamagna 

Hey.

yeah, i've got my answer. :)

regarding the upload: why shows lintian in the offical debian build
still the

wicd-gtk

W command-in-menu-file-and-desktop-file
wicd-gtk usr/share/menu/wicd-gtk:5

bug? My local lintian doesn't report this issue.



Please note, a challenge for you/upstream.
http://debomatic-amd64.debian.net/distribution#unstable/wicd/1.7.4+tb2-1/buildlog
it seems to be failing when LANG is set to somewhat else:
Traceback (most recent call last):

[...]

dh_auto_build: python setup.py build --force returned exit code 1


I don't know how to fix this unfortunately!
maybe something like "if $LANG is set use, otherwise skip?"?




The next days, i'll have a look at this issue, maybe i can provide some
additional information.

Bug#814997: Reverting upstream commit 40ed879db fixes gnome-pkg-tools

[Andreas Henriksson]

Control: reassign -1 gnome-pkg-tools

Hello again.

On Wed, Feb 17, 2016 at 07:56:29PM +0100, santiag...@riseup.net wrote:
[...]
> grep is less and less tolerant against invalid unicode characters.
> Maybe are there invalid characters in the debian/* files where
> uploaders.mk get the info to fill the Uploaders field? 
[...]

You might actually be right here. (I was only thinking about the data
used as an argument for grep - not the standard input data.)

$ iconv -f utf-8 -t ascii < /usr/share/gnome-pkg-tools/pkg-gnome.team  | tail 
-n 2
iconv: illegal input sequence at position 713
Loic Minier ,

And indeed, dropping Loïc and Sebastian Dröge from the list fixes the
problem.

I'll take care of fixing this up on the gnome-pkg-tools side.
Sorry for bothering you and thanks for the help!

Regards,
Andreas Henriksson