Bug#852657: ITP: node-espurify -- Clone new AST without extra properties

[Tushar Agey]

Package: wnpp
Severity: wishlist
Owner: Tushar Agey 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-espurify
  Version : 1.6.0
  Upstream Author : Takuto Wada 
(https://github.com/twada)
* URL : https://github.com/estools/espurify
* License : Expat
  Programming Lang: JavaScript
  Description : Clone new AST without extra properties
  ### var customizedCloneFunction = espurify.customize(options)
  Returns customized function for cloning AST, configured by custom `options`.
  .
  ### var purifiedAstClone = customizedCloneFunction(originalAst)
  Returns new clone of `originalAst` by customized function.

Bug#852656: RFP: lac -- new incarnation of a "classic" flight game GL-117

[Lev Lamberov]

Package: wnpp
Severity: wishlist

* Package name: lac
  Version : 3.42
  Upstream Author : Robert J. Bosen
* URL : 
http://askmisterwizard.com/FlightSimMovies/LAC/LacIntroFullPage.htm
* License : GPL-2+
  Programming Lang: C++
  Description : new incarnation of a "classic" flight game GL-117

LINUX AIR COMBAT is a free, open-source combat flight simulator developed by
AskMisterWizard.com for the LINUX community. It was derived from the well-known
"classic" flight game known as "GL-117", but this new incarnation has been
extensively re-written and improved.

* Free and open source distribution
* A growing list of World War II aircraft (now 17 different flyable aircraft)
* A theoretical Jet fighter with performance similar to the General Dynamics F16
* Very smooth, high-performance graphics yield high frame rates even on modest
  computer hardware
* 44 flight/view functions can be mapped to any detected joystick axis, button,
  or keyboard key
* Industry-standard "Air Warrior" style viewsystem is easily configurable for
  other view options
* Low-Speed Stalls
* High-Speed Compressibility
* High-G Blackouts and Redouts
* Realistic high-altitude degredation of engine performance
* Fuel consumption is proportional to engine load including WEP/Afterburner
  effects
* Simulated RADAR to help locate opponents
* Simulated IFF to help Identify Friend verses Foe
* Guns combat
* Missile combat
* Flares and Chaff operable as missile countermeasures
* Free flight mission
* Four tutorial missions with detailed audio narration to help beginners get
  a quick start
* Six Offline combat missions
* Online "Head to Head" mission suitable for air racing or combat (2 players
  only. No server required.)
* Six-player Internet mission in Pacific island terrain  (requires access to
  Linux Air Combat Server)
* Ten-player Internet mission in desert terrain (requires access to Linux Air
  Combat Server)
* Ten-player Internet mission in island terrain (requires access to Linux Air
  Combat Server)
* New "LAC Network Manager" helps you find friends and opponents for Internet
  play
* User-loadable graphic aircraft models support the venerable, well-known
  ".3ds" format
* User-loadable background music, sound effects, and narration files support
  industry-standard ".wav" format
* "Talking Cockpit" can verbalize target location so you can hear it without
  diverting your eyes
* Innovative "Network Router Panel" on cockpit shows network telemetry and
  comms data from other players
* Best-of-breed network user management with interplayer status messages on
  the cockpit panel
* Powerful integration with "Mumble" for world-class voice communication
  between players
* Dedicated Mumble server manages a rich heirarchy of voice radio channels
  and online help
* 16 Comms-related functions can be mapped to any keyboard key
* In active development and subject to frequent improvements

Bug#851834: [Pkg-pascal-devel] Bug#851834: mricron FTBFS on armhf: parconvert.s:3121: Error: co-processor offset out of range

[Graham Inggs]

The patch below adds line number information to the generated parconvert.s:

--- a/dcm2nii/dcm2nii.lpi
+++ b/dcm2nii/dcm2nii.lpi
@@ -482,6 +482,7 @@
 
   
   
+  
 
   
   

Because of the additional lines, this changes the assembler messages to:

(9009) Assembling parconvert
parconvert.s: Assembler messages:
parconvert.s:3775: Error: co-processor offset out of range
parconvert.s:3783: Error: co-processor offset out of range
parconvert.s:3880: Error: co-processor offset out of range
parconvert.s:3886: Error: co-processor offset out of range
parconvert.s:3892: Error: co-processor offset out of range
parconvert.s:3895: Error: co-processor offset out of range
parconvert.s:3899: Error: co-processor offset out of range
parconvert.s:3903: Error: co-processor offset out of range
parconvert.s:3918: Error: co-processor offset out of range
parconvert.s:3924: Error: co-processor offset out of range
parconvert.s:3930: Error: co-processor offset out of range
parconvert.s:4813: Error: co-processor offset out of range
parconvert.s:4817: Error: co-processor offset out of range
parconvert.s:4821: Error: co-processor offset out of range
parconvert.s:4825: Error: co-processor offset out of range
parconvert.s:4895: Error: co-processor offset out of range
parconvert.s:4899: Error: co-processor offset out of range
parconvert.pas(1375) Error: (9007) Error while assembling exitcode 1
parconvert.pas(1375) Fatal: (10026) There were 2 errors compiling
module, stopping
Fatal: (1018) Compilation aborted

The first error corresponds to the vstr instruction on line 3775 below:

# [593] lScanResX :=  round(readParFloat);
movr0,r11
blxPARCONVERT$_$READ_PAR2NII$crcDDE5A164_$$_READPARFLOAT$$DOUBLE
blxfpc_round_real
blxfpc_int64_to_double
vmov.f64d1,d0
subr0,r11,#143360
vstrd1,[r0, #-2528]

Which in turn, corresponds to line 593 of parconvert.pas:

  if lUpCaseStr = 'SCANRESOLUTION(XY)' then begin
 lScanResX :=  round(readParFloat);
 lScanResY :=  round(readParFloat);

readParFloat is a nested function returning double, starting on line
461 of parconvert.pas:

function readParFloat:double;//nested
var lStr: string;
begin
  lStr := '';
  result := 1;
...

Bug#852655: RFS: wxmaxima/16.12.2-1

[Gunter Königsmann]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: wxmaxima
   Version : 16.12.2-1
   Upstream Author : Andrej Vodopivec
 * URL : http://andrejv.github.io/wxmaxima/
 * License : GPL
   Section : math

It builds those binary packages:

  wxmaxima   - GUI for the computer algebra system Maxima

wxMaxima is a graphical user interface for Maxima, a full-fletched and
quite powerful Computer Algebra System: A program that is specialized on
finding the equation that solves a mathematical problems, not merely a
number. One simple example of what it does would be:

(%i2)   y=x^3;
(%o2)   y=x^3
(%i3)   solve(%,x);
(%o3)   [x=((sqrt(3)*%i-1)*y^(1/3))/2,x=-((sqrt(3)*%i+1)*y^(1/3))/2,x=y^(1/3)]

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

 * http://andrejv.github.io/wxmaxima/
 * http://maxima.sourceforge.net/


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

  dget -x
https://mentors.debian.net/debian/pool/main/w/wxmaxima/wxmaxima_16.12.2-1.dsc

Changes since the last upload:

  A completely new release with vastly improved drag


Regards,
   Gunter Königsmann

Bug#851834: [Pkg-pascal-devel] Bug#851834: mricron FTBFS on armhf: parconvert.s:3121: Error: co-processor offset out of range

[Graham Inggs]

I see the same failure with 0.20140804.1~dfsg.1-1.
According to reproducible builds [1], the last successful build on
armhf was on 2016-02-19.

Can we request removal of the armhf binary, so this can at least
migrate before the final freeze?
I have some ideas on how to debug this further.

[1] https://tests.reproducible-builds.org/debian/history/mricron.html

Bug#296493: SHIPPING DOCUMENT

[Masnaini Rusli (Trinity Ships)]

Dear sir,

Fyi we got an instruction from our client to contact you on the above
subject, please kindly take into quick consideration the attached shipping
documents before we proceed with shipment.

Kindly confirm that the details are correct and revert back to us asap

Regards
Shipping agent
Wan Hai Lines co.,ltd
600 minsheng road shanghai 200135 china
Tel:(86)-(21)-58834638
Fax:(86)-(21)-58832073
Zip code:200135Dear sir,

Fyi we got an instruction from our client to contact you on the above
subject, please kindly take into quick consideration the attached shipping
documents before we proceed with shipment.

Kindly confirm that the details are correct and revert back to us asap

Regards
Shipping agent
Wan Hai Lines co.,ltd
600 minsheng road shanghai 200135 china
Tel:(86)-(21)-58834638
Fax:(86)-(21)-58832073
Zip code:200135

RFQ_#947-13.gz
Description: application/gzip

Bug#824391: [Pkg-shadow-devel] Bug#824391: Pending fixes for bugs in the shadow package

[Christian PERRIER]

Quoting Bálint Réczey (bal...@balintreczey.hu):
> 2017-01-25 17:14 GMT+01:00 Steinar H. Gunderson :
> > On Wed, Jan 25, 2017 at 04:00:18PM +, 
> > pkg-shadow-de...@lists.alioth.debian.org wrote:
> >> The full diff can be seen at
> >> http://anonscm.debian.org/gitweb/?p=pkg-fonts/shadow.git;a=commitdiff;h=d779e83
> >
> > FWIW; this 404-s. pkg-fonts/shadow?
> 
> No, this is a bug in the scripts. :-)
> 
> Christian, could you please fix it in the following file?:
> /home/groups/pkg-shadow/scripts/git-tag-pending-bugs
> 
> I have no write access.

Done:
bubulle@moszumanska:/home/groups/pkg-shadow/scripts$ chmod g+w 
git-tag-pending-bugs
bubulle@moszumanska:/home/groups/pkg-shadow/scripts$ chmod g+w .




signature.asc
Description: PGP signature

Bug#852527: O: fnfx -- ACPI and hotkey daemon for Toshiba laptops

[Tobias Frost]

In a preparation of an QA upload I've created a repository in collab-
maint:

It should be there: 
https://anonscm.debian.org/cgit/collab-maint/fnfx.git

--
tobi

Bug#852521: [tex-live] unicode-math now unable to process $\widetilde{\mathbf{a}}$

[Norbert Preining]

Hi James,

> I've attached the tex file and output, including stdout and stderr

Hmm, is that from a working version? It doesn't look like.

Furthermore, it seems that something is going completely different on 
your side, because loads of different files are loaded. One reason
might be your texmf.cnf file:
/home/aragilar/.tex/tex-config/web2c/texmf.cnf
can you please tell me what is in there? Also you TEX* env vars.

And if you can, a *working* run (you said it is working with the
previous version to which you downgraded)!

Thanks

Norbert

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

Bug#852654: src:pbcopper: no point to releasing it without `unanimity`

[Afif Elghraoui]

Package: src:pbcopper
Version: 0.0.1+20161202-2
Severity: important

There is nothing actually wrong with pbcopper, but there is no sense in
releasing this package for stretch since it basically only exists to
support unanimity, which did not make the cutoff.

--
Afif Elghraoui

Bug#850951: [pkg-go] Bug#850951: CVE-2016-9962

[Tianon Gravi]

On 11 January 2017 at 07:21, Moritz Muehlenhoff  wrote:
> Please see:
> https://bugzilla.suse.com/show_bug.cgi?id=1012568
> https://github.com/docker/docker/compare/v1.12.5...v1.12.6
> https://github.com/opencontainers/runc/commit/50a19c6ff828c58e5dab13830bd3dacde268afe5

I've been working on backporting this patch to 0.1.1, and I think the
CVE actually doesn't apply to 0.1.1 (the version currently in
sid/stretch).  The file descriptor being closed in this patch isn't
being opened at all in 0.1.1 ("stateDirFD" doesn't exist yet).

https://github.com/opencontainers/runc/pull/886 is the upstream PR
which introduced this file descriptor, and it was not included in a
release until 1.0.0-rc2.

As a consequence, I think this bug should be closed (and probably the
security tracker updated to reflect the fact that this CVE doesn't
apply to our older version of runc).


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#836241: plasma-workspace: Digital clock widget wants qml-module-org-kde-kholidays

[? ??]

Still no pending changes?

Bug#852521: [tex-live] unicode-math now unable to process $\widetilde{\mathbf{a}}$

[James Tocknell]

Hi Norbert

I've attached the tex file and output, including stdout and stderr

James

On 26 January 2017 at 14:28, Norbert Preining  wrote:

> On Thu, 26 Jan 2017, James Tocknell wrote:
> > $\widetilde{\mathbf{a}}$). I've temporary reverted back to
> 2016.20161130-1,
> > as that version works. So this is a regression. Is there an easy way of
>
> Can you please:
> * add
> \listfiles
>   as first line (before \documentclass...)
> * run
> xelatex -recorder ...
> * send me the
> .log
> .fls
>   of the working versions.
>
> Thanks a lot
>
> Norbert
>
> --
> PREINING Norbert   http://www.preining.info
> Accelia Inc. +JAIST +TeX Live +Debian Developer
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
>



-- 
Don't send me files in proprietary formats (.doc(x), .xls, .ppt etc.). It
isn't good enough for Tim Berners-Lee
,
and it isn't good enough for me either. For more information visit
http://www.gnu.org/philosophy/no-word-attachments.html.

Truly great madness cannot be achieved without significant intelligence.
 - Henrik Tikkanen

If you're not messing with your sanity, you're not having fun.
 - James Tocknell

In theory, there is no difference between theory and practice; In practice,
there is.


tex_test.tar.gz
Description: GNU Zip compressed data

Bug#852646: task-xfce-desktop: please recommend atril not evince

[Christian PERRIER]

Quoting Adam Borowski (kilob...@angband.pl):
> Package: task-xfce-desktop
> Version: 3.39
> Severity: wishlist
> 
> Hi!
> Currently, the XFCE task pulls in evince, whose interface is really out of
> place outside of Gnome.  It'd be far better to install atril instead (from
> Mate) -- it blends in with XFCE seamlessly.  It also doesn't suffer from a
> number of weird decisions taken by the Gnome project that make the user
> interface really inconsistent with XFCE components.
> 
> Atril is a fork of Evince, so base functionality is the same.

As usual: what's the stance of Xfce packages maintainers about this?




signature.asc
Description: PGP signature

Bug#852653: Grub install failed on encrypted LVM disk

[laalaa]

Dear Maintainer:

Problem solved.  Mark "BOOT" flag in the encrypted disk.  Then grub install 
completed successfully.

Suggest to verify BOOT flag has been marked to allow proceeding to next 
installation stage.

Regards,

Alan

Bug#852612: Acknowledgement (linux-image-4.9.0-1-amd64: kernel 4.9.2-2 panics on boot)

[Robert Lange]

> I think this should be the same as #851928 addressed by 
>
>  - http://git.kernel.org/linus/20b1e22d01a4b0b11d3a1066e9feb04be38607ec
>  - http://git.kernel.org/linus/0100a3e67a9cef64d72cd3a1da86f3ddbee50363
>
> and already pending for the next upload of src:linux to unstable
> (4.9.6-1).
>

Confirmed. I applied those two patches, rebuilt the 4.9.2-2 package,
installed the new packages, and I was able to boot into 4.9.

Bug#852521: [tex-live] unicode-math now unable to process $\widetilde{\mathbf{a}}$

[Norbert Preining]

On Thu, 26 Jan 2017, James Tocknell wrote:
> $\widetilde{\mathbf{a}}$). I've temporary reverted back to 2016.20161130-1,
> as that version works. So this is a regression. Is there an easy way of

Can you please:
* add
\listfiles
  as first line (before \documentclass...)
* run
xelatex -recorder ...
* send me the
.log
.fls
  of the working versions.

Thanks a lot

Norbert

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

Bug#852652: [reportbug] crashes with TypeError: Couldn't find foreign struct converter for 'cairo.Context'

[Jean-Francois Pirus]

Package: reportbug
Version: 7.1.4
Severity: important

reportbug crashes with:
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'

Bug#852653: Grub install failed on encrypted LVM disk

[laalaa]

Package: installation-reports
Version: jessie rc1
Severity: critical
Justification: failed to install grub

Dear Maintainer,

   * What led up to the situation?
Failed installation of grub under KVM system with encrypted LVM disk.

   * What exactly did you do (or not do) that was effective (or ineffective)?
Source:
    netinst iso-cd weekly built on 2017-01-23, downloaded from debian 
website
System:
    Debian Jessie running qemu-kvm 1:2.1+dfsg-12+deb8u6
KVM hardware:
    1 x IDE CDROM (debian-testing netinst iso-cd)
    1 x 8GB virtio disk (vda)
1 x virtio network adapter
QXL display
Partition disks:
    Encrypte vda disk and setup with LVM:
    Encrypted volume (vda1_crypt) - 8.6GB
        #1  8.6GB    K    lvm
        LVM VG vg, LV lvhome - 4.1GB
            #1  4.1GB    K    ext4    /home
        LVM VG vg, LV lvroot - 4.1GB
            #1  4.1GB    K    ext4    /
        LVM VG vg, LV lvswap - 255.9MB
            #1  255.9MB  K    swap    swap
        Virtual disk 1 (vda) - 8.6GB Virtio Block Device
            #1  primary 8.6GB K crypto
GRUB installation:
    Install the GRUB boot loader to the master boot record --> Yes
    Device for boot loader installation: /dev/vda
    Force GRUB installation to the EFI removable media path? Yes

   * What was the outcome of this action?
Error message:
    Unable to install GRUB in /dev/vda
    Executing 'grub-install /dev/vda' failed.
    This is a fatal error.

   * What outcome did you expect instead?
Installation of grub completed.

-- System Information:
Debian Release: stretch/sid
Architecture: amd64

Bug#852651: [gnome-packagekit] gpk-update-viewer stalls and does not finish updates when a config file has changed

[Jean-Francois Pirus]

Package: gnome-packagekit
Version: 3.22.1-2
Severity: important

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

If a package owned config file has been changed, /etc/pulse/daemon.conf 
in this example, you never get to see a gui version of the below.

(I also get this with openssh updates and others)

This is on XFCE if it makes a difference.

You need to kill gpk-update-viewer then manually fix it as follows:

root@Tosh:~# apt upgrade
E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to 
correct the problem.

root@Tosh:~# dpkg --configure -a
Setting up pulseaudio (10.0-1) ...

Configuration file '/etc/pulse/daemon.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** daemon.conf (Y/I/N/O/D/Z) [default=N] ?
Installing new version of config file 
/etc/xdg/autostart/pulseaudio.desktop ...




--- System information. ---
Architecture: Kernel:   Linux 4.9.0-1-amd64

Debian Release: 9.0
  500 unstable-debug  debug.mirrors.debian.org   500 unstable 
mirror.akl.tmnetwork.co.nz   500 unstableftp.nz.debian.org   500 
unstableftp.debian.org   500 stable 
repository.spotify.com   500 all liveusb.info

--- Package information. ---
Depends (Version) | Installed
=-+-==
gnome-packagekit-data   (>= 3.22.1-2) | 3.22.1-2
packagekit (>= 1.0.4) | 1.1.5-1
dconf-gsettings-backend   | 0.26.0-2
 OR gsettings-backend | libatk1.0-0 
  (>= 1.12.4) | 2.22.0-1
libc6(>= 2.4) | libcairo-gobject2 
 (>= 1.10.0) | libcairo2  (>= 1.2.4) | 
libcanberra-gtk3-0  (>= 0.25) | libcanberra0 
(>= 0.2) | libfontconfig1  (>= 2.11) | libfreetype6 
  (>= 2.2.1) | libgdk-pixbuf2.0-0(>= 
2.22.0) | libglib2.0-0  (>= 2.37.3) | libgtk-3-0 
   (>= 3.16.2) | libnotify4 (>= 0.7.0) | 
libpackagekit-glib2-18 (>= 0.9.4) | libpango-1.0-0 
 (>= 1.14.0) | libpangocairo-1.0-0   (>= 1.14.0) | 
libpolkit-gobject-1-0  (>= 0.101) | libsqlite3-0 
  (>= 3.5.9) | libsystemd0   | libx11-6 
 |


Recommends   (Version) | Installed
==-+-===
software-properties-gtk| 0.96.20.2-1


Package's Suggests field is empty.

Bug#851826: pulseaudio: USB headset detected, but no sound

[Michael Haag]

Sorry I didn't get back sooner on this. I've been busy the last few
days, not to mention futzing about with your suggestions and my
equipment trying to figure out the puzzle.

Anyway, I am able to switch to a VT when playing the game, so I assume I
use pactl to change things up? If that's the case, I'll need to spend
some time familiarizing myself with that tool.

I'm using Virtualbox rather the QEMU for the Windows VM. Previously,
I've always had more trouble using pulseaudio in Virtualbox than using
ALSA. Anyway, I tried switching to the pulseaudio driver and had the
same problem.

It's not just USB, either. At least not for the VM. In the VM, both USB
and legacy audio work, with pulseaudio OR ALSA. Doesn't seem to make
much difference. Also, the problem seems to be with the audio stream
coming from the microphone. Playback through the headphones doesn't seem
to be affected.

In short, there is excessive white noise when using the legacy audio
jacks, while there seems to be some kind of latency issue when using
USB--some stuttering and/or slight garbling, but only with the
microphone.

I suspect it must be due to the headphones use of "surround sound"
processing, since I did not have any issues with my older "stereo"
headset. I just don't get why it seems to be affecting the microphone
rather than the headphones. Guess I'll just have to buy another headset.

Thanks for your time on this, and your suggestions. If nothing else, I
learned a bit more than I knew before. I apologize for wasted time on
your part.

On Mon, Jan 23, 2017, at 20:13, Felipe Sateler wrote:
> On 22 January 2017 at 02:37, Michael Haag  wrote:
> > That works in most instances, but it doesn't work in my use case. I have
> > an older OpenGL/OpenAL/OSS game that takes control of the keyboard and
> > mouse when it loads. This means I cannot access pulseaudio to change
> > devices.
> 
> Can you switch to a different VT? You can try this by using
> ctrl+alt+fN (with N from 1 to 7). There it should be possible to login
> to a text console and query pulseaudio there.
> 
> If that doesn't work, setting up ssh in that computer and logging in
> via that should give you a shell with which we can inspect what
> pulseaudio is doing.
> 
> > Oddly, there is no need to do this when my headset is plugged
> > in using the legacy audio jacks. Sound is directed to BOTH my speakers
> > and my headset.
> 
> This sounds like those are picked up by the system as a single
> surround output rather than two distinct devices.
> 
> >
> > The other case is when I use a Windows-only language learning
> > application which I run in a VM. The headset works with both legacy and
> > USB connections, but the sound quality with USB is so poor the
> > application cannot match my spoken pronunciation to the recorded voice,
> > making it impossible to use the program.
> 
> Is the quality only bad with qemu? Did you set the qemu output driver
> to pulseaudio? https://wiki.archlinux.org/index.php/QEMU#Host
> 
> > Maybe neither of the above can be attributed soley to pulseaudio, but I
> > didn't have this problem with my legacy headset. I can get by with the
> > legacy audio jacks, but the USB problem means I can't use some of the
> > headset features, such as surround sound.
> 
> It doesn't sound like there is any bug in pulseaudio. From what I can
> tell, you just haven't told your app to output to the correct device
> (which is hard because it grabs the mouse and keyboard).
> 
> Also, have you tried to run your OSS program through padsp? This may
> make your app better behaved.
> 
> -- 
> 
> Saludos,
> Felipe Sateler


-- 
"Democracy is ... a form of religion; it is the worship of jackals by
jackasses." -- H. L. Mencken

Bug#779892: workaround: disable join dialog

[Mike Kupfer]

Mattia Rizzolo wrote:

> I happen to be the new hexchat maintainer in Debian :)

Hi, pleased to meet you. :-)

> You haven't provide this "improved" stack trace, but more importantly,
> there is now a quite new version I'd like you to try, 2.12.4.  Could
> you?

Yeah, sorry about never getting the improved stack trace.

Sure, I can try 2.12.4.  I see it's in testing, so I'll update my
testing VM and give it a spin.  I'll try to find time this weekend.

cheers,
mike

Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc//stat utime,stime,etc. reported

[Tom Lee]

Just an update: I am still encountering similar performance issues with the
4.9.0-1 kernel that was recently promoted to testing. In fact, the 4.9.0-1
kernel may be the worst yet in terms of this specific issue, with IntelliJ
starting so slowly as to be effectively unusable. One time the entire
system appeared to become completely unresponsive & a hard reset was
required.

The most recent kernel with which I've experienced problems:

$ apt-cache show linux-image-4.9.0-1-amd64
Package: linux-image-4.9.0-1-amd64
Source: linux-signed (4)
Version: 4.9.2-2
Installed-Size: 183299

This problem does *not* seem to occur with a vanilla 4.9.2 kernel, implying
something Debian-specific:

$ uname -a
Linux desktop.local 4.9.2 #1 SMP Wed Jan 25 04:28:29 PST 2017 x86_64
GNU/Linux

If you're aware of any Debian patches that might be suspect, I'm happy to
try some custom builds. Reproducing the issue is trivial on my end when a
kernel is "bad".


On Sun, Nov 20, 2016 at 2:24 PM, Tom Lee  wrote:

> Also potentially relevant: kworker/0:0 has 421h on-cpu time reported per
> htop (the TIME+ column) and top. /proc//stat output for PID=4
> (kworker/0:0) vs PID=63 (kworker/1:1):
>
> tom@desktop ~ $ cat /proc/63/stat
> 63 (kworker/1:1) S 2 0 0 0 -1 69238880 0 0 0 0 0 0 0 0 20 0 1 0 82 0 0
> 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 1 0 0 184 0 0 0 0
> 0 0 0 0 0 0
> tom@desktop ~ $ cat /proc/4/stat
> 4 (kworker/0:0) S 2 0 0 0 -1 69238880 0 0 0 0 151836336 0 0 0 20 0 1 0 10
> 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0
>
> In fact, kworker:0:0 seems to be the only process with on-cpu stats
> reported (forgive the shell abuse, quick and dirty):
>
> $ for pid in $(ls /proc | awk '/^[0-9]*$/'); do [ -d /proc/$pid ] && awk
> '$14 != "0" { print $2 }' /proc/$pid/stat; done
> (kworker/0:0)
> $
>
>
> On Sun, Nov 20, 2016 at 2:12 PM, Tom Lee  wrote:
>
>> Tried 4.8.0-1 with similar results. Perhaps slightly better, but not much.
>>
>> $ uname -a
>> Linux desktop 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64
>> GNU/Linux
>>
>> Like 4.7, can't see what's hogging the CPUs as per-process CPU stats
>> don't appear to be correctly reported in /proc//stat.
>>
>> 4.6.x continues to be perfect with respect to both overall performance
>> and the correctness of /proc//stat.
>>
>>
>> On Sat, Nov 12, 2016 at 8:23 PM, Ben Hutchings 
>> wrote:
>>
>>> Control: tag -1 moreinfo
>>>
>>> On Sun, 2016-11-06 at 00:02 -0700, Tom Lee wrote:
>>> [...]
>>> > Downgrading to linux-image-4.6.0-1-amd64 fixed all symptoms. Haven't
>>> yet
>>> > tried 4.8.0-1 from unstable, not sure if it's impacted.
>>> [...]
>>>
>>> Please do.
>>>
>>> Ben.
>>>
>>> --
>>> Ben Hutchings
>>> Nothing is ever a complete failure; it can always serve as a bad
>>> example.
>>>
>>>
>>
>>
>> --
>> *Tom Lee */ http://tomlee.co / @tglee 
>>
>>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee 
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee 

Bug#852650: slony1-2: Recommend time-daemon as an alternative to ntp

[Vincent Blut]

Package: slony1-2
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Slony-I individually recommends chrony or openntpd as an alternative to 
ntp, but these two are part of the time-daemon virtual package so you 
may want to directly set it as an alternative to ntp. Git formatted 
patch attached!

Cheers,
Vincent

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

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

-BEGIN PGP SIGNATURE-

iQJLBAEBCgA1FiEE/VQBlxWoTJPh4vI5ipzudlpxp4AFAliJTCkXHHZpbmNlbnQu
ZGViaWFuQGZyZWUuZnIACgkQipzudlpxp4DJXhAAuSLcnsUGbCzKvvt2ZVhX+P+w
EqqPyzUC9rgO5oMhqTpT3gZj3VioSQVYEEAD659Hk0OU/hpt23QivqvpESkAnuRS
9MhiBhTV9/Vulcwdzh55H/d9HFOPNUAlcubZ9cpfp7on1mEBUrA6kOeSGf9W+vRy
ynlgBeZNx9KUgvta7Wtw6ReC/j0yr0ERDQ4TlXaunGiNiYZDGdsEksXnBjwRa7+O
FToc8tpIM0gyEZhZdlu/yo2eslSVVCZc80V/V84MIeF5ZvKLKYHiAi1S4aD+86HZ
lznURmteWzubEOROb/VMSEih7BLcwAjB55IHRnn4IfDKtnGnQgbxvAiohTES+aGd
2TWYKhiWv09ubb7L2KsddRaUgyztLdNmGbmkVjCDRHFrJ9bvvH2mu4bwY4+oNoKW
N7SUUg9IozC3/XCSKa57BlE4Jh09nIB3XTGGIBAAgwmZv0are5kdmmHH6Y7FqZlo
eHwyayPm5CkeJpTRvQFwg9CLTWlk1W2b0CvtSB6R6IJ22+qRtJ/OI+9YZYeQsJZk
VQVzRaaIurUblpHbs9lQcisKUrMUoYRVlsuO5HYkLLBlocuAVTba+rEHw8+viTmr
ffMb7ubSqGZ1FxbV9vaVyoiCRjiGY6kI2trpQyL8NwdEULBZ+LR8J052lUT6RZdo
m/MlGBX6HGoum+OnSzM=
=SmnN
-END PGP SIGNATURE-
>From e565469f8c94fc0f9348f2eb9ed0e8f57afdb6bb Mon Sep 17 00:00:00 2001
From: Vincent Blut 
Date: Thu, 26 Jan 2017 01:53:52 +0100
Subject: [PATCH] Recommend time-daemon as an alternative to ntp

chrony and openntpd are both part of this virtual package.
---
 debian/control| 2 +-
 debian/control.in | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 0aa58bb..ce75443 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ XS-Testsuite: autopkgtest
 Package: slony1-2-bin
 Architecture: any
 Depends: logrotate ${logrotate:version}, postgresql-common, ${misc:Depends}, 
${perl:Depends}, ${shlibs:Depends}
-Recommends: ${module:Recommends}, libdbd-pg-perl, ntp | openntpd | chrony
+Recommends: ${module:Recommends}, libdbd-pg-perl, ntp | time-daemon
 Suggests: slony1-2-doc, libpg-perl
 Provides: slony1-bin
 Conflicts: slony1-bin
diff --git a/debian/control.in b/debian/control.in
index 61008f4..015cf5e 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -14,7 +14,7 @@ XS-Testsuite: autopkgtest
 Package: slony1-2-bin
 Architecture: any
 Depends: logrotate ${logrotate:version}, postgresql-common, ${misc:Depends}, 
${perl:Depends}, ${shlibs:Depends}
-Recommends: ${module:Recommends}, libdbd-pg-perl, ntp | openntpd | chrony
+Recommends: ${module:Recommends}, libdbd-pg-perl, ntp | time-daemon
 Suggests: slony1-2-doc, libpg-perl
 Provides: slony1-bin
 Conflicts: slony1-bin
-- 
2.11.0

Bug#852649: live-build: Mouse speed on the default live distrubution can be too fast without an xorg.conf hack

[IJ.L.]

Source: live-build
Severity: normal
Hi. I believe there is serious usability issue with the default live 
distribution. The one I use is the regular GNOME jessie live. The slowest speed 
possible on a high-DPI mouse from the GUI configuration inside GNOME may be 
much faster than needed. The user has to actually edit the xorg.conf and 
restart the X server in order to get a slower slowest speed for the mouse 
pointer. I believe that should not be the default behavior at all. Other OSes 
start-off with a much slower mouse speed on high-DPI mouse. It can make the 
live distribution nearly unusable to several people.


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

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#852398:

[allan]

Can duplicate on 32-bit Sid.  Extensions are broken.

Bug#852187: diaspora: current installation report

[Pirate Praveen]

On Sun, 22 Jan 2017 11:41:13 + Julian Gilbey  wrote:
> Here's a report on issues I've found trying to install the current
> (0.6.0.0+debian-8) version of diaspora.

Thanks for testing. I have uploaded a new version with fixes.

> (1) The diaspora preinst reads on line 15:
> 
> if su diaspora -s /bin/sh -c "psql  diaspora_production -c ''"
> 
> Unfortunately, this may fail as the diaspora user is not created
> until the diaspora-common *postinst*, and the diaspora preinst may
> be run before this.  Instead, you probably want to change the user
> to be "su postgres" as the postgres user (if it exists at this
> point) will certainly be able to run this command.  (If postgres
> has not been installed, then dbexist will remain undefined.)
> 
> I'd also add a "-" to the su command, and lose the output:
> 
> su - postgres -c "psql diaspora_production -c ''" >&/dev/null
> 
> Actually, if the diaspora package assumes that the backing
> database will be postgresql, (which may or may not be the case -
> I'm not sure), then it needs to Depends or Pre-Depends on an
> appropriate postgresql package - diaspora-common only depends on a
> choice of mysql or postgres.  And the diaspora-common package
> gives the option of psql or mysql, so this could be a problem.

This check is now removed. It was there from early days when we only
supported postgres. Also we just skip db initialization if a database
already exist.

> (2) This is a serious bug, and renders diaspora not fit for testing;
> I'm not setting the severity right now to give the current
> unstable version a chance to enter testing, as the bug in the
> current testing version is even worse.

thanks :)

> The diaspora process writes to /usr, which is expressly forbidden
> by policy: /usr might be on a read-only filesystem.  See the FHS,
> very beginning of chapter 4:
> 
> Chapter 4. The /usr Hierarchy
> 
> Purpose
> 
> /usr is the second major section of the filesystem. /usr is
> shareable, read-only data. That means that /usr should be
> shareable between various FHS-compliant hosts and must not be
> written to. Any information that is host-specific or varies
> with time is stored elsewhere.
> 
> To be more precise, it stores temporary information in
> /usr/share/diaspora/tmp, rather than /var/run/diaspora.
> I *think* this can be solved by putting in a symlink
> /usr/share/diaspora/tmp -> /var/run/diaspora, but
> /var/run/diaspora would have to be created and owned by
> diaspora:nogroup before starting diaspora.  I haven't determined
> when this directory is and is not used, though - there's something
> weird going on on my machine regarding this, and I'm not convinced
> that this solution works.
> 

I have added symlinks for all directories and files for which diaspora
needs write access.

Same for 3.

For 4 and 5. We use environment variables in /etc/diaspora.conf.




signature.asc
Description: OpenPGP digital signature

Bug#848931: Requesting feedback on cmd_push_source implementation

[Ian Jackson]

Sean Whitton writes ("Bug#848931: Requesting feedback on cmd_push_source 
implementation"):
> I've implemented cmd_push_source in the 'push-source' branch of repo
> .
> 
> My new command is entirely untested.  I'd like feedback on the
> refactoring I've done before proceeding to test the new command.  This
> is to avoid having to repeat all testing in the event that the
> refactoring I've done isn't idiomatic.

Right.  Thanks.  I have emailed the patches to myself "From" you and
will reply as if they were mailing list patch submissions.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#852250: [lua-socket] luasocket was not compiled with UNIX sockets support

[Courtney Bane]

On Wed, Jan 25, 2017 at 10:48:43PM +0100, Mathieu Parent wrote:
> Will look at a fix inside lua-socket (preserving both
> compatibilities), but please relax your rules to help find a fix for
> all cases.

I just opened a pull request[1] with upstream that adds backwards
compatibility wrappers. It should be simple to adapt it to the version
currently in Debian.

[1] https://github.com/diegonehab/luasocket/pull/207

Bug#852647: git signed push GIT_PUSH_CERT_KEY has truncated keyid

[Ian Jackson]

Package: git
Version: 1:2.11.0-2
Control: block 848678 by -1

I'm playing about with signed pushes, which I hope to use to allow the
dgit git server to be used for general git hosting (pushable by DDs
and DMs).

However, I see this:

  GIT_PUSH_CERT_KEY=A3DBCBC039B13D8A

There is almost no purpose for which this 64-bit keyid can be safely
used.  The full key fingerprint should be provided instead.

Although this might be an incompatible change, I think it is essential
because anyone who is relying on this info right now is insecure.

(Arguably this bug should have a higher severity than `normal'; but, I
suspect nearly no-one is using this feature.)

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#852646: task-xfce-desktop: please recommend atril not evince

[Adam Borowski]

Package: task-xfce-desktop
Version: 3.39
Severity: wishlist

Hi!
Currently, the XFCE task pulls in evince, whose interface is really out of
place outside of Gnome.  It'd be far better to install atril instead (from
Mate) -- it blends in with XFCE seamlessly.  It also doesn't suffer from a
number of weird decisions taken by the Gnome project that make the user
interface really inconsistent with XFCE components.

Atril is a fork of Evince, so base functionality is the same.


-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.5+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#820549: anarchism: Typo in section H1

[ju]

X-Debbugs-Cc: j...@riseup.net

Package: anarchism
Version: 15.0-1
Followup-For: Bug #820549

Hi,

> In section H.1 of the faq, I read «These critiques contain may
> important ideas
> and so are worth summarising», where "may" is probably a "many"
> mispelled.

Or maybe they wanted to say <>?

> I just thought it was a typo, and that it would have been nice to
> report
> it. I also downloaded the version proposed in #773529, and I can
> confirm this
> bug still applies.

Now that #773529 is closed and the bug still applies, maybe is better a
PR to the repository where the sources are now?.

Cheers,
ju.

Bug#848729: reportbug UnicodeDecodeError: possible patch, please test

[Nis Martensen]

Can you please test if the attached patch fixes this bug?

(This bug already has multiple duplicates -- Bugs #848729, #849358,
#850687, #851865, #852129 all seem related.)
>From f1bbfcfd8ef09ae86f06ea1aa815e0a4c4e51e92 Mon Sep 17 00:00:00 2001
From: Nis Martensen 
Date: Thu, 26 Jan 2017 00:09:43 +0100
Subject: [PATCH] reportbug/utils.py: do not fail on decoding errors

The dpkg status database and the reportbug configuration file might use
character sets different from the current locale. This can be
problematic when reading and decoding the file contents: The default
decoding error handler ("strict") errors out in such cases. Picking a
different one is more robust.
---
 reportbug/utils.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/reportbug/utils.py b/reportbug/utils.py
index 5c06afb..2de91ae 100644
--- a/reportbug/utils.py
+++ b/reportbug/utils.py
@@ -496,7 +496,7 @@ class AvailDB(object):
 
 def get_dpkg_database():
 try:
-fp = open(STATUSDB)
+fp = open(STATUSDB, errors="backslashreplace")
 if fp:
 return AvailDB(fp=fp)
 except IOError:
@@ -976,7 +976,7 @@ def parse_config_files():
 for filename in FILES:
 if os.path.exists(filename):
 try:
-lex = our_lex(open(filename), posix=True)
+lex = our_lex(open(filename, errors="backslashreplace"), posix=True)
 except IOError as msg:
 continue
 
@@ -1235,7 +1235,7 @@ def exec_and_parse_bugscript(handler, bugscript):
 isattachments = False
 headers = pseudoheaders = text = ''
 attachments = []
-fp = open(filename)
+fp = open(filename, errors="backslashreplace")
 for line in fp.readlines():
 # we identify the blocks for headers and pseudo-h
 if line == '-- BEGIN HEADERS --\n':
-- 
2.1.4

Bug#839992: libmath-quaternion-perl: autopkgtest failure: not ok 48 - rotation_angle works

[Santiago Vila]

severity 839992 important
retitle 839992 libmath-quaternion-perl: FTBFS randomly (not ok 48 - 
rotation_angle works)
thanks

This actually happens when the package is being built (see attach).

On Sat, 8 Oct 2016, gregor herrmann wrote:

> On Fri, 07 Oct 2016 10:54:55 +0300, Niko Tyni wrote:
> 
> >   not ok 48 - rotation_angle works
> >   #   Failed test 'rotation_angle works'
> >   #   at t/001_basic.t line 357.
> >   not ok 55 - rotation_axis works
> >   #   Failed test 'rotation_axis works'
> >   #   at t/001_basic.t line 378.
> 
> > It works for me on current sid. This is probably [rt.cpan.org #93159]:
> > the test suite has random inputs which sometimes cause failures.
> 
> I can reproduce the failure from CPAN RT#93159 by running
> t/001_basic.t in a loop, and the failure is not surprising:
> 
> my $exponent = int rand 100;
> my $q1manual = $q1;
> for (1..($exponent-1))  { $q1manual = 
> Math::Quaternion::multiply($q1,$q1manual); }
> 
> 'int rand 100' returns results between 0 and 99, and with 0 and 1,
> the for loop is not run.

So it fails deliberately once every 50 times?

> Ok, after applying the proposed patch from CPAN RT, I don't get this
> problem anymore, and I now also get the failures we're seeing on
> ci.d.n. But it takes quite some time to trigger them; possible
> cuplrit in the code:
> 
> 353: my $theta = rand(0.25*$pi);
> 
> which could be 0.
> 
> 
> So far for today :)

Would be possible to apply the patch for stretch?

Thanks.

libmath-quaternion-perl_0.07-1_amd64-20170125T112508Z.gz
Description: application/gzip

Bug#794466: VIrtualBox future in Debian

[Jeremy Bicha]

Sorry for the long post, but it does give a walkthrough of how this is
working now in Stretch…


I installed Debian Stretch today using the January 23 weekly
netinstall image. I installed to a VirtualBox guest (the host is
Ubuntu 17.04 Alpha). The install went well except for two issues.

1. I chose to install the GNOME desktop. tasksel had some kind of
error near the end of downloading packages. Maybe some transient
network error. When I re-ran the task, it suggested I install some
virtualbox-ose-something package. The install completed successfully.

2. When I rebooted after install, gdm did not start and my console was
flickering really bad. Along with the console flickering, I could not
reliably enter my password since keypresses were getting dropped. I
tried booting into recovery mode but since I did not set a root
password (I prefer to use sudo), Debian gave me an error about the
root account being locked and after I pressed Enter as prompted, it
continued a normal boot. After about 5 minutes, the flickering
stopped. I guess this is systemd eagerly retrying a failed service
until it reaches its timeout.

journalctl -xb revealed that gdm ""could not find drm kms device". I
couldn't find anything useful by searching for that message on Google.
I then checked to see whether the VirtualBox guest utils were
installed. They weren't. So I had to enable unstable in my apt
sources, then
sudo apt -t unstable install virtualbox-guest-utils virtualbox-guest-x11
sudo reboot

gdm works great now.

Suggestions
=
3. Something needs to be done about whatever in the installer suggests
installing the virtualbox-ose package. Since I clicked OK, I thought
it *did* install something useful for VirtualBox but I don't think it
did.

4. I have not had the #2 problem with other distros. Ubuntu includes
some minimal VirtualBox-compatible driver as part of its default
kernel. Could Debian do the same so that Debian will actually run on
VirtualBox?

5. As far as the drivers go, if they aren't in a Debian release, then
once someone actually gets Debian running, I guess they'll either just
keep whatever drivers they installed the first time. Or maybe they'll
use VirtualBox's guest additions iso to install the drivers. Neither
way offers automatic update of drivers. I feel this situation is worse
from a security perspective than having a Debian package that is at
least updated on major new Debian releases.

Why can't the Security Team treat VirtualBox like how it's been
treating WebKit1? Still have it in the archives but with a prominent
notice that Debian does not provide security updates.

6. Assuming that VirtualBox won't be in the next stable Debian
release, I guess we need a page like mozilla.debian.net for it?

Thanks,
Jeremy Bicha

Bug#852645: dafny: FTBFS

[Santiago Vila]

Package: src:dafny
Version: 1.9.7-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with cli
   dh_testdir -i
   dh_update_autotools_config -i
   dh_auto_configure -i
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
cp -a /usr/lib/boogie/* Binaries
mkdir -p Source/Dafny/bin/Checked
cp -a /usr/lib/boogie/* Source/Dafny/bin/Checked
xbuild Source/Dafny.sln
XBuild Engine Version 14.0
Mono, Version 4.6.2.0
Copyright (C) 2005-2013 Various Mono authors

[... snipped ...]

Resolver.cs(2197,57): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(2871,44): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(3394,41): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(4399,82): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(4932,29): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(4940,29): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(4968,49): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(5114,37): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(5598,28): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(6255,45): error CS0246: The type or namespace name `Boogie' 
could not be found. Are you missing an assembly reference?
Resolver.cs(7070,38): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(7197,23): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(7300,30): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(7394,56): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(7525,47): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(7536,51): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(8316,38): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(8316,95): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(8552,40): error CS0246: The type or namespace name `Boogie' 
could not be found. Are you missing an assembly reference?
Resolver.cs(9085,59): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(9379,35): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(845,29): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(853,35): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(2250,16): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(2253,53): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(2543,34): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(3311,43): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(3435,28): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(9448,23): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Resolver.cs(9460,36): error CS0246: The type or namespace name `IToken' 
could not be found. Are you missing an assembly reference?
Rewriter.cs(34,31): error CS0246: The type or namespace name `Boogie' 
could not be found. Are 

Bug#846882:

[André Wolski]

Hello,

I'm using debian jessie with some backports too and I think I am
affected by the same underlying issue, I'm not quite sure if "change
linearly without light off" means what I'll describe as "flickering".
I am using an IBM Lenovo ThinkPad T61 and gnome 3.14.

When I upgraded xserver-xorg-video-intel from
2:2.99.917+git20160706-1~bpo8+1 to 2:2.99.917+git20161105-1~bpo8+1 I
noticed a "flickerig" in the backlight brightness whenever I changed
it via the hot keys. It is still occuring with
2:2.99.917+git20161206-1~bpo8+1.

As the upstream bug report has the staus NEEDINFO and it is requested
to "reproduce using *only*
/sys/class/backlight/intel_backlight/brigthness directly" I played
arround with different methods of brightness adjustion.


First of all a better description of what I mean with "flickering": on
each key press of the hot key the brightness is adjusted, however
there is a short period (maybe 1/10th of a second) where the backlight
is set to some other level. This is happening in both directions, but
not when the minimum or maximum is reached.


When I write values to either
/sys/class/backlight/intel_backlight/brigthness or
/sys/class/backlight/acpi_video0/brightness this flickering doesn't
occur. Also, when I fade the brightness in the gnome menu (upper right
corner for me, below the volume settings) it changes perfectly without
flickering. This lets me assume that is not a (pure) upstream issue,
but more likely an issue with the hot key management and its
interaction with xserver-xorg-video-intel (I assume that happens
somewhere else and no in xserver-xorg-video-intel, doesn't it?).
Therefore I share this findings here and not in the upstream bug. If
you'd like I can also post it there.



1. tune down brightness in gnome and hit brightnessdown key multiple
times to get to a dark state

root@my-host:~# cat /sys/class/backlight/acpi_video0/brightness
0
root@my-host:~# cat /sys/class/backlight/intel_backlight/brightness
0


2. tune brightness up to maximum in the gnome menu (backlight changes
seamlessly to the brightest state)

root@my-host:~# cat /sys/class/backlight/acpi_video0/brightness
0
root@my-host:~# cat /sys/class/backlight/intel_backlight/brightness
12056655


3. hit brightnessdown key few times (extreme flickering: backlight is
always shortly dark)

root@my-host:~# cat /sys/class/backlight/acpi_video0/brightness
0
root@my-host:~# cat /sys/class/backlight/intel_backlight/brightness
9042444


4. hit brightnessup key few times (less extreme flickering)

root@my-host:~# cat /sys/class/backlight/acpi_video0/brightness
2
root@my-host:~# cat /sys/class/backlight/intel_backlight/brightness
10248157


5. go back to default level, as in 1.

root@my-host:~# cat /sys/class/backlight/acpi_video0/brightness
0
root@my-host:~# cat /sys/class/backlight/intel_backlight/brightness
0


6. tune brightness up via echo to intel_backlight (backlight is in its
brightest state)

root@my-host:~# echo 12056655 > /sys/class/backlight/intel_backlight/brightness
root@my-host:~# cat /sys/class/backlight/acpi_video0/brightness
0
root@my-host:~# cat /sys/class/backlight/intel_backlight/brightness
12056655


7. hit brightnessdown key once (backlight is immediately dark)

root@my-host:~# cat /sys/class/backlight/acpi_video0/brightness
0
root@my-host:~# cat /sys/class/backlight/intel_backlight/brightness
0




8. tune brightness up via echo to acpi_video0 (backlight is in its
brightest state)

root@my-host:~# cat /sys/class/backlight/acpi_video0/brightness
15
root@my-host:~# cat /sys/class/backlight/intel_backlight/brightness
12056655



9. hit brightnessdown key once (backlight is immediately dark)


root@my-host:~# cat /sys/class/backlight/acpi_video0/brightness
14
root@my-host:~# cat /sys/class/backlight/intel_backlight/brightness
0




So the problem seems that the brightness levels are inconsistently
changed by the hot keys.

I noticed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801348#12
and added Option "Backlight" "intel_backlight" to the Device Section
in xorg.conf, however that made no difference.


dmesg
Description: Binary data
[58.549] 
X.Org X Server 1.16.4
Release Date: 2014-12-20
[58.550] X Protocol Version 11, Revision 0
[58.550] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[58.550] Current Operating System: Linux my-host 4.8.0-0.bpo.2-amd64 #1 SMP Debian 4.8.15-2~bpo8+2 (2017-01-17) x86_64
[58.550] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.8.0-0.bpo.2-amd64 root=UUID=401764f9-f506-4c34-8b8e-ec62d39ec231 ro quiet
[58.550] Build Date: 11 February 2015  12:32:02AM
[58.550] xorg-server 2:1.16.4-1 (http://www.debian.org/support) 
[58.550] Current version of pixman: 0.32.6
[58.550] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[58.550] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, 

Bug#852521: [tex-live] unicode-math now unable to process $\widetilde{\mathbf{a}}$

[James Tocknell]

Hi Norbert

Yes, I can confirm this has worked before, on the 10th on January this year
(that's the latest version of a document which has
$\widetilde{\mathbf{a}}$). I've temporary reverted back to 2016.20161130-1,
as that version works. So this is a regression. Is there an easy way of
bisecting over texlive to find the breaking change?

James

On 26 January 2017 at 02:06, Norbert Preining  wrote:

> Dear James,
>
> I guess you haven't seen the answer on the TeX Live mailing list,
> so I add it here.
>
> It seems that this has been the case before, too, and is well known:
>
>
> *** answer from Ulrike Fischer *
>
> The problem is that \mathbf doesn't use a font with math table and
> accent commands don't like this. You can find quite a number of
> questions about this on tex.sx. E.g.
> http://tex.stackexchange.com/questions/214570/try-to-use-
> ams-blackboard-bold-font-together-with-texgyrepagella
>
> The correct input would be \symbf. Or you must hide the \mathbf in a
> box:
>
> \documentclass{article}
> \usepackage{unicode-math}
>
> \begin{document}
>   $\widetilde{\symbf{a}} \widetilde{\mbox{$\mathbf{a}$}}$
> \end{document}
>
> (\widetilde{\text{$\mathbf{a}$}} with amsmath work too)
>
> 
>
> Can you confirm that this *has* worked before, say in the last
> half year or so?
>
> If not, I will probably close this bug report as usage error
> or upupstream problem.
>
> All the best and hope that helps
>
> Norbert
>
> --
> PREINING Norbert   http://www.preining.info
> Accelia Inc. +JAIST +TeX Live +Debian Developer
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
>



-- 
Don't send me files in proprietary formats (.doc(x), .xls, .ppt etc.). It
isn't good enough for Tim Berners-Lee
,
and it isn't good enough for me either. For more information visit
http://www.gnu.org/philosophy/no-word-attachments.html.

Truly great madness cannot be achieved without significant intelligence.
 - Henrik Tikkanen

If you're not messing with your sanity, you're not having fun.
 - James Tocknell

In theory, there is no difference between theory and practice; In practice,
there is.

Bug#852644: lyskom-server: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: lyskom-server
Version: 2.1.2-14
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for lyskom-server's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

lyskom-server_2.1.2-14_pt.po.gz
Description: application/gzip

Bug#852643: libbfio FTBFS on armel/armhf/mips*: bfio_test_handle.c:803 result (1) != -1

[Adrian Bunk]

Source: libbfio
Version: 20170123-1
Severity: serious

https://buildd.debian.org/status/package.php?p=libbfio

...
make  check-TESTS
make[3]: Entering directory '/«PKGBUILDDIR»/tests'
make[4]: Entering directory '/«PKGBUILDDIR»/tests'
FAIL: test_library.sh
PASS: test_write_functions.sh

   libbfio 20170123: tests/test-suite.log


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

.. contents:: :depth: 2

FAIL: test_library.sh
=

Testing: error  (PASS)
Testing: support  (PASS)
bfio_test_handle.c:803 result (1) != -1
Unable to run test: libbfio_handle_initialize
Testing: handle with input: input/raw/test.raw (FAIL)
FAIL test_library.sh (exit status: 1)


Testsuite summary for libbfio 20170123

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

See tests/test-suite.log
Please report to joachim.m...@gmail.com

Makefile:1014: recipe for target 'test-suite.log' failed
make[4]: *** [test-suite.log] Error 1

Bug#852642: scoop: FTBFS randomly (sbuild hangs)

[Santiago Vila]

Package: src:scoop
Version: 0.7.1.1-1
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3,sphinxdoc --buildsystem=pybuild
   dh_testdir -i -O--buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py config 
running config
I: pybuild base:184: python3.5 setup.py config 
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:184: /usr/bin/python setup.py build 
running build
running build_py
creating /<>/.pybuild/pythonX.Y_2.7/build/scoop

[... snipped ...]

copying scoop/shared.py -> /<>/.pybuild/pythonX.Y_3.5/build/scoop
copying scoop/utils.py -> /<>/.pybuild/pythonX.Y_3.5/build/scoop
copying scoop/__main__.py -> /<>/.pybuild/pythonX.Y_3.5/build/scoop
copying scoop/futures.py -> /<>/.pybuild/pythonX.Y_3.5/build/scoop
copying scoop/encapsulation.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop
copying scoop/fallbacks.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop
creating /<>/.pybuild/pythonX.Y_3.5/build/scoop/bootstrap
copying scoop/bootstrap/__init__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/bootstrap
copying scoop/bootstrap/__main__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/bootstrap
creating /<>/.pybuild/pythonX.Y_3.5/build/scoop/launch
copying scoop/launch/__init__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/launch
copying scoop/launch/workerLaunch.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/launch
copying scoop/launch/brokerLaunch.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/launch
creating /<>/.pybuild/pythonX.Y_3.5/build/scoop/broker
copying scoop/broker/__init__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/broker
copying scoop/broker/__main__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/broker
copying scoop/broker/brokertcp.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/broker
copying scoop/broker/structs.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/broker
copying scoop/broker/brokerzmq.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/broker
creating /<>/.pybuild/pythonX.Y_3.5/build/scoop/_comm
copying scoop/_comm/scooptcp.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/_comm
copying scoop/_comm/__init__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/_comm
copying scoop/_comm/scoopzmq.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/_comm
copying scoop/_comm/scoopexceptions.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/_comm
creating /<>/.pybuild/pythonX.Y_3.5/build/scoop/discovery
copying scoop/discovery/__init__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/discovery
copying scoop/discovery/minusconf.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/discovery
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
PYBUILD_SYSTEM=custom \
PYBUILD_TEST_ARGS="cd {dir}/test; {interpreter} tests.py" \
dh_auto_test
I: pybuild base:184: cd /<>/test; python2.7 tests.py
.
--
Ran 77 tests in 49.575s

OK
I: pybuild base:184: cd /<>/test; python3.5 tests.py
.
--
Ran 77 tests in 52.916s

OK
E: Build killed with signal TERM after 60 minutes of inactivity


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/scoop/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

Thanks.

Bug#852641: libplack-app-proxy-perl: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:libplack-app-proxy-perl
Version: 0.29-1
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep
   dh_testdir -i
   dh_update_autotools_config -i
   dh_auto_configure -i
perl -I. Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
"LD=x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro"
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Plack::App::Proxy
Writing MYMETA.yml and MYMETA.json
   dh_auto_build -i
make -j1
make[1]: Entering directory '/<>'

[... snipped ...]

#   Failed test at t/middleware/rewrite.t line 36.
#  got: undef
# expected: 'http://perl.org/'
# Looks like you failed 2 tests of 16.
t/middleware/rewrite.t .. 
not ok 1
ok 2
not ok 3
ok 4
ok 5
ok 6
ok 7 - got right status for request at /foo
ok 8 - got right proxied redirect URL
ok 9 - got right non-proxied redirect URL
ok 10 - got right status for request at /foo
ok 11 - got right proxied redirect URL
ok 12 - got right non-proxied redirect URL
ok 13
ok 14 - Location header should be rewritten
ok 15
ok 16 - Location header should be rewritten
1..16
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/16 subtests 
t/status.t .. 
ok 1
ok 2
1..2
ok

Test Summary Report
---
t/middleware/rewrite.t(Wstat: 512 Tests: 16 Failed: 2)
  Failed tests:  1, 3
  Non-zero exit status: 2
Files=11, Tests=155,  3 wallclock secs ( 0.06 usr  0.01 sys +  2.79 cusr  0.64 
csys =  3.50 CPU)
Result: FAIL
Failed 1/11 test programs. 2/155 subtests failed.
Makefile:804: recipe for target 'test_dynamic' failed
make[1]: *** [test_dynamic] Error 255
make[1]: Leaving directory '/<>'
dh_auto_test: make -j1 test TEST_VERBOSE=1 returned exit code 2
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/libplack-app-proxy-perl/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

Thanks.

Bug#852640: apache-mime4j: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:apache-mime4j
Version: 0.7.2-4
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=maven --with javahelper
   dh_testdir -i -O--buildsystem=maven
   dh_update_autotools_config -i -O--buildsystem=maven
   dh_auto_configure -i -O--buildsystem=maven
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compiler/*/*.jar': No 
such file or directory
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compilers/*/*.jar': No 
such file or directory
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-containers/*/*.jar': No 
such file or directory
mh_patchpoms -plibapache-mime4j-java --debian-build --keep-pom-version 
--maven-repo=/<>/debian/maven-repo
   jh_linkjars -i -O--buildsystem=maven
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build -- install javadoc:aggregate
/usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar
 -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/<> 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian 
-Dmaven.repo.local=/<>/debian/maven-repo install javadoc:aggregate 
-DskipTests -Dnotimestamp=true -Dlocale=en_US

[... snipped ...]

Running org.apache.james.mime4j.dom.MessageServiceFactoryTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec - in 
org.apache.james.mime4j.dom.MessageServiceFactoryTest
Running org.apache.james.mime4j.dom.ExampleMessagesRoundtripTest
Tests run: 79, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.301 sec - in 
org.apache.james.mime4j.dom.ExampleMessagesRoundtripTest
Running org.apache.james.mime4j.dom.MessageCompleteMailTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec - in 
org.apache.james.mime4j.dom.MessageCompleteMailTest

Results :

Failed tests: 
  org.apache.james.mime4j.message.StringInputStreamTest#testBufferedRead 
AssertionFailedError

Tests run: 405, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache JAMES Mime4j Project  SUCCESS [  0.175 s]
[INFO] Apache JAMES Mime4j (Core) . SUCCESS [  6.578 s]
[INFO] Apache JAMES Mime4j (DOM) .. FAILURE [  5.005 s]
[INFO] Apache JAMES Mime4j (Storage) .. SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 14.299 s
[INFO] Finished at: 2017-01-24T00:47:16+00:00
[INFO] Final Memory: 10M/27M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on 
project apache-mime4j-dom: There are test failures.
[ERROR] 
[ERROR] Please refer to /<>/dom/target/surefire-reports for the 
individual test results.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :apache-mime4j-dom
dh_auto_test: /usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar
 -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/<> 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian 
-Dmaven.repo.local=/<>/debian/maven-repo test returned exit code 1
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/apache-mime4j/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough 

Bug#852639: tigervnc-standalone-server: mouse pointer stuck in upper left corner

[Aaro Koskinen]

Package: tigervnc-standalone-server
Version: 1.7.0+dfsg-2
Severity: important

Dear Maintainer,

VNC server is honoring the mouse movement, but the pointer is always
displayed/stuck in the upper left corner regardless what the actual
position is.

Server started with: vncserver :0 -geometry 1280x1024 -depth 16 -localhost

And $HOME/.vnc/xstartup is:

#!/bin/sh
xrdb $HOME/.Xresources
xsetroot -solid grey
uxterm &
LANG=C x-window-manager &

A.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

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

Versions of packages tigervnc-standalone-server depends on:
ii  libaudit1 1:2.6.7-1
ii  libc6 2.24-8
ii  libgcc1   1:6.2.1-5
ii  libgcrypt20   1.7.5-3
ii  libgl1-mesa-glx [libgl1]  13.0.3-1
ii  libgnutls30   3.5.8-1
ii  libjpeg62-turbo   1:1.5.1-2
ii  libpam0g  1.1.8-3.5
ii  libpixman-1-0 0.34.0-1
ii  libselinux1   2.6-3
ii  libstdc++66.2.1-5
ii  libsystemd0   232-8
ii  libx11-6  2:1.6.4-2
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.2-1.1
ii  libxfont2 1:2.0.1-3
ii  libxshmfence1 1.2-1
pn  perl:any  
ii  x11-xkb-utils 7.7+3
ii  xauth 1:1.0.9-1
ii  xkb-data  2.18-1
ii  zlib1g1:1.2.8.dfsg-4

Versions of packages tigervnc-standalone-server recommends:
pn  libgl1-mesa-dri
ii  tigervnc-common1.7.0+dfsg-2
ii  x11-xserver-utils  7.7+7
ii  xfonts-base1:1.0.4+nmu1

Versions of packages tigervnc-standalone-server suggests:
ii  xfonts-100dpi1:1.0.4+nmu1
ii  xfonts-75dpi 1:1.0.4+nmu1
pn  xfonts-scalable  

-- no debconf information

Bug#852638: bluez-alsa: New source compatible with bluez 5

[Jean-Krikri]

Package: bluez-alsa
Version: 4.99-2
Severity: wishlist

Dear Maintainer,

As I don't use Pulseaudio, I found a development of bluez-alsa here:

https://github.com/Arkq/bluez-alsa

I successfully built it and had it work with alsa, bluez 5.43-1  and blueman.

It would be nice to have it packaged in Debian

Regards

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

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

Bug#837623: [firefox-esr] text with background in the HTML is printing without it

[Enrique Garcia]

 I found an option that allows this. In the printing pop-up window there is an 
"Options" tab with a checkbox that allows printing of the background.

 I guess this ticket can be closed. Sorry for the extra noise.

Bug#836556: menu entries with no icons

[Enrique Garcia]

 After some updates in my Debian testing it looks like version 4:16.08.3-1 is 
now properly setting the icon in the system tray.

 Still there might be some issues with the icons, since there are some entries 
in the application menu which don't show an icon. For instance the "Delete 
Wallet" entry under the "File" menu has no icon, whereas in Jessie there is a 
trash icon for that.

Bug#852127: qcontrold is not started on default

[Thomas Pircher]

On 2017-01-23 20:00, Ian Campbell wrote:

[0] https://git.hellion.org.uk/?p=qcontrol.git;a=tree;f=systemd;h=f9b3c
358a84915b10bb780e0a8becdfa47604924;hb=HEAD


Ok, I haven't managed to get the service files working. I copied the 
service and socket files to /usr/lib/systemd/user and enabled them with 
systemctl enable.


The qcontrol.service seems to work fine, but for the qcontrold.service I 
got an warning message that the WantedBy is missing. As a test I have 
copied the section from qcontrol.service, but the service then didn't 
start (hung on a systemctl start, presumably waiting for some 
prerequisites which never activated).


I'm afraid this is as far as my knowledge as systemd user goes. I can 
try tinkering a bit more after reading up on service files, but that 
might not happen very soon due to time constraints.

Bug#764432: FTBFS on sparc, segfault in TestAlignment

[James Clarke]

Control: tags -1 patch

On Wed, Oct 08, 2014 at 03:10:57AM +, Mike Gabriel wrote:
> Package: freerdp
> Version: 1.1.0~git20140921.1.440916e+dfsg1-2
> Severity: important
>
> Hi Aurelien, hi other porters,
>
> The freerdp version 1.1.0~git20140921.1.440916e+dfsg1-2 still shows FTBFS
> symptoms on Sparc architecture.
>
> """
> [...]
>
> 99% tests passed, 1 tests failed out of 89
>
> Total Test time (real) =   3.07 sec
>
> The following tests FAILED:
> Errors while running CTest
>16 - TestAlignment (SEGFAULT)
> make[1]: *** [test] Error 8
> Makefile:140: recipe for target 'test' failed
> make[1]: Leaving directory
> '/«BUILDDIR»/freerdp-1.1.0~git20140921.1.440916e+dfsg1/obj-sparc-linux-gnu'
> make: *** [debian/stamp-makefile-check] Error 2
> dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
> /usr/share/cdbs/1/class/makefile.mk:67: recipe for target
> 'debian/stamp-makefile-check' failed
> """
>
> Any help to dig this out is appreciated...
>
> Thanks,
> 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/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

I had a look at it today. It isn't actually segfaulting, it's getting a
bus error, but somewhere in the testing framework this gets treated the
same as a segfault. The problem lies because the _aligned_offset_malloc
code doesn't ensure that the *header* is aligned, and it then tries to
dereference an unaligned header pointer, if a non-zero offset is given
(well, if you give offset as a multiple of 8, that's fine, since it
won't break the alignment). The attached patch ensures that the header
is always pointer-size-aligned. In fact, since Debian uses gcc, it could
use __alignof__(struct _aligned_meminfo) instead of sizeof(void *), but
that's not portable.

Regards,
James
Description: Ensure the _aligned_meminfo pointer itself is sufficiently aligned
Author: James Clarke 

--- a/winpr/libwinpr/crt/alignment.c
+++ b/winpr/libwinpr/crt/alignment.c
@@ -73,15 +73,20 @@ void* _aligned_offset_malloc(size_t size
if (alignment < sizeof(void*))
alignment = sizeof(void*);
 
-   /* malloc size + alignment to make sure we can align afterwards */
-   tmpptr = malloc(size + alignment + sizeof(struct _aligned_meminfo));
+   /* malloc size + alignment to make sure we can align afterwards.
+* Include an extra sizeof(void*) to ensure there's always space to 
align
+* ameminfo downwards, in case malloc doesn't align to sizeof(void*). 
This
+* could be dropped if there was a portable way to get alignof(struct
+* _aligned_meminfo), but instead we have to overestimate with
+* sizeof(void*). */
+   tmpptr = malloc(size + alignment + sizeof(struct _aligned_meminfo) + 
sizeof(void*));
if (!tmpptr)
return NULL;
 
 
-   memptr = (void *)size_t)((PBYTE)tmpptr + alignment + offset + 
sizeof(struct _aligned_meminfo)) & ~(alignment - 1)) - offset));
+   memptr = (void *)size_t)((PBYTE)tmpptr + alignment + offset + 
sizeof(struct _aligned_meminfo) + sizeof(void*)) & ~(alignment - 1)) - offset));
 
-   ameminfo = (struct _aligned_meminfo *) (((size_t)((PBYTE)memptr - 
sizeof(struct _aligned_meminfo;
+   ameminfo = (struct _aligned_meminfo *) (((size_t)((PBYTE)memptr - 
sizeof(struct _aligned_meminfo))) & ~(sizeof(void*)-1));
ameminfo->base_addr = tmpptr;
ameminfo->size = size;
 
@@ -107,7 +112,7 @@ void* _aligned_offset_realloc(void* memb
if (!newmem)
return NULL;
 
-   ameminfo = (struct _aligned_meminfo *) (((size_t)((PBYTE)memblock - 
sizeof(struct _aligned_meminfo;
+   ameminfo = (struct _aligned_meminfo *) (((size_t)((PBYTE)memblock - 
sizeof(struct _aligned_meminfo))) & ~(sizeof(void*)-1));
memcpy(newmem, memblock, ameminfo->size);
_aligned_free(memblock);
return newmem;
@@ -129,7 +134,7 @@ void _aligned_free(void* memblock)
if (!memblock)
return;
 
-   ameminfo = (struct _aligned_meminfo *) (((size_t)((PBYTE)memblock - 
sizeof(struct _aligned_meminfo;
+   ameminfo = (struct _aligned_meminfo *) (((size_t)((PBYTE)memblock - 
sizeof(struct _aligned_meminfo))) & ~(sizeof(void*)-1));
 
free(ameminfo->base_addr);
 }

Bug#852637: xul-ext-sieve: should depend on thunderbird | icedove

[Achim Schaefer]

Package: xul-ext-sieve
Version: 0.2.3h+dfsg-1
Severity: important

Dear Maintainer,

debian is currently roling out thunderbird as "replacement" of icedova.
So this extension should debpend on one of these 2, but not only icedove.

Otherwise one can't install thunderbird and this extension at the sam etime

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

Versions of packages xul-ext-sieve depends on:
ii  icedove   1:45.6.0-2
ii  libjs-jquery  3.1.1-2

xul-ext-sieve recommends no packages.

xul-ext-sieve suggests no packages.

-- no debconf information

Bug#851989: release.debian.org: de-branding Icedove, Thunderbird packages in Stretch?

[Carsten Schoenert]

One more minor note,

On Tue, Jan 24, 2017 at 08:07:02AM +0100, Carsten Schoenert wrote:
...
> So maybe some extension may break now simply because the package
> dependencies are now to strict. Such packages should be easy to find as
> if the icedove package is referenced the thunderbird package needed to
> be provided as well. Christoph could (and should) address such problems
> in his announcement.

this statement is not fully true from a backview.
We need to ship the transitional icedove package for Stretch at all
times so a dependency on 'icedove' will end in the reverse dependency on
'thunderbird' and the extension will work. For Stretch+1 we need to proof
the xul-ext packages for depending on thunderbird then.

Christoph will check which reverse depends on icedove-dev we have.

Regards

Bug#815170: love: New upstream version available

[Markus Koschany]

Control: noowner -1 !

On 25.01.2017 21:56, Alexandre Detiste wrote:
>> Hi,
>>
>> It is also rather suboptimal that love embeds so
>> many libraries like box2d or enet which are available in Debian. This
>> should be documented [1] and improved but it is not critical for Stretch.
> 
> I will continue working on this after this upload.
> 
>> If you can fix d/copyright today, we can still get 0.10.2 into Stretch
>> (provided that there are no other show-stoppers) but it would be too
>> late tomorrow.
> 
> Ok, I've uploaded these fixes.


I don't think the package is ready yet. But in case someone else
disagrees please go ahead with the upload.

debian/copyright is still incomplete. It is missing at least

src/libraries/luasocket/libluasocket
src/libraries/lz4/lz4.c
src/libraries/stb
src/libraries/luautf8/lutf8lib.h
src/libraries/glad/gladfuncs.hpp
src/libraries/ddsparse/ddsparse.h
src/libraries/Wuff/wuff_internal.h
platform/unix/install-sh
src/libraries/noise1234/noise1234.cpp
src/platform/unix (GPL-2, GPL3, Expat)

For mrrescue:

Missing upstream tag, missing pristine-tar commit, Standards-Version is
3.9.8.




signature.asc
Description: OpenPGP digital signature

Bug#852250: [lua-socket] luasocket was not compiled with UNIX sockets support

[Mathieu Parent]

2017-01-25 22:15 GMT+01:00 Michael Meskes :
> Control: reassign -1 lua-socket
>
> I don't think this is the way to go. There is no grave bug in prosody-modules,
> it's lua-socket that changed its API during freeze. The way I understand our
> freeze policy this is a no-go, but feel free to check with the release team.

The way you want will make prosody-modules break when someone start to
use lua-socket from stretch-backports.

The unix socket API is not stable nor documented yet [1], being tied
to an API that we know will change on buster is not very solid either.

As for the freeze definition, the updated lua-socket was uploaded
during soft freeze. I agree that this could be seen as a "transition"
as the API was changed.

Will look at a fix inside lua-socket (preserving both
compatibilities), but please relax your rules to help find a fix for
all cases.

[1]: https://github.com/diegonehab/luasocket/pull/199#issuecomment-275220892

Regards
-- 
Mathieu

Bug#796609: fcoe-utils: Has init script in runlevel S but no matching service file

[Jacob Luna Lundberg]

Hi Felipe,

On Wed, Jan 25, 2017 at 03:00:29PM -0300, Felipe Sateler wrote:
> > It is plenty usable, just not if you are using systemd.  Yes, I am aware
> > policy at this point requires systemd support.
> 
> OK, sorry. The impression I had from your earlier message is that it
> didn't work[1].

Ahh, I see.  No, the package provides the utilities necessary to mount 
FCoE volumes, it just does not work when you try to mount them 
automatically at boot time.  I would be curious how systemd accomplishes 
the necessary ordering if that is working with the systemd units.  If 
so, when I have some time I will have to try and understand what systemd 
is doing.

As far as I can tell this problem is not well solved, at least in 
sysvinit.  NFS has a special arrangement.  FCoE and iSCSI can't work as 
far as I can tell because the network must come up in order to discover 
volumes, but aside from NFS, volumes are mounted before the network is 
brought up.  If Debian has a provision to mark f.e. an ext4 volume as a 
network volume in /etc/fstab, I do not know about it.  Additionally, in 
sysvinit the network is stopped before unmounting volumes, so when the 
system attempts to unmount the FCoE volumes, the network is already down 
and the system waits forever for the volumes to unmount.  Both of these 
problems can be worked around with kludgy init hacks that are not really 
a high enough quality to ship in Debian.  Resolving these problems the 
right way is what I was referring to when I said the init scripts need 
work.

> 0030-fcoe.service-Add-foreground-to-prevent-fcoemon-to-be.patch
> 
> => Seems to me it is better to change the unit to Type=forking
> instead? This way, systemd would know when the monitor is ready.

Given the description of Type=forking that does sound sensible.

> debian/rules:
> 
> => it seems weird to me that the socket is not started by default.

Maybe something to do with the hack-y version of dealing with forking?

Thanks,
-Jacob

Bug#852636: RFS: llmnrd/0.3-1

[Pali Rohár]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: llmnrd
   Version : 0.3-1
   Upstream Author : Tobias Klauser 
 * URL : https://github.com/tklauser/llmnrd
 * License : GPL-2
   Section : net

It builds those binary packages:

  llmnrd - Link-Local Multicast Resolution (LLMNR) Daemon for Linux

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

  https://mentors.debian.net/package/llmnrd


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

  dget -x https://mentors.debian.net/debian/pool/main/l/llmnrd/llmnrd_0.3-1.dsc

More information about llmnrd can be obtained from 
https://github.com/tklauser/llmnrd.

Changes since the last upload:

 * New upstream release
 * Do not change CFLAGS in debian/ruls (upstream fixed *FLAGS support)
 * Update debian/watch (upstream does not provide PGP signed tarballs)


Regards,
 Pali Rohár


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

Bug#848931: Requesting feedback on cmd_push_source implementation

[Sean Whitton]

Hello,

I've implemented cmd_push_source in the 'push-source' branch of repo
.

My new command is entirely untested.  I'd like feedback on the
refactoring I've done before proceeding to test the new command.  This
is to avoid having to repeat all testing in the event that the
refactoring I've done isn't idiomatic.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#852635: kodi: Does not play DVD iso from remote location when libdvdcss is installed

[Bálint Réczey]

Package: kodi
Version: 2:17.0~rc3+dfsg1-2
Severity: minor
Tags: confirmed

When libdvdcss is installed opening DVDs from remote locations fails,
but playing DVDs from local filesystem still works.

Without libdvdcss now Kodi plays DVDs from remote and local locations.

Cheers,
Balint

Bug#852634: please add mod_auth_dovecot

[Michael Meskes]

Package: prosody-modules
Severity: wishlist

I've been running mod_auth_dovecot flawlessly for ages and would prefer to not
need a manual installation. Except for the latest and yet to be fixed API
change in lua-socket it should work out of the box.

Thanks

Michael

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

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

Versions of packages prosody-modules depends on:
pn  lua-ldap  
pn  prosody   

prosody-modules recommends no packages.

prosody-modules suggests no packages.

Bug#852261: profanity FTBFS on armel/armhf/mips/mipsel: prof_whole_occurrences_tests failed

[Jack Henschel]

I created an upstream bug report at:
https://github.com/boothj5/profanity/issues/901

Greetings,
Jack



signature.asc
Description: OpenPGP digital signature

Bug#852250: [lua-socket] luasocket was not compiled with UNIX sockets support

[Michael Meskes]

Control: reassign -1 lua-socket

I don't think this is the way to go. There is no grave bug in prosody-modules,
it's lua-socket that changed its API during freeze. The way I understand our
freeze policy this is a no-go, but feel free to check with the release team.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Bug#851479: chrome-gnome-shell: Use python3 instead of python

[Jeremy Bicha]

On 25 January 2017 at 13:21, Ritesh Raj Sarraf  wrote:
> Regarding the python3 change, do you want to revise the patch ?
> It is okay to have python3 support too. But that shouldn't discount python2.

No, please see the Debian Python policy.

https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html

My opinion is that chrome-gnome-shell is more of a program than a
library. But even it we consider it a library, Debian policy says it's
ok to drop python2 if no reverse dependencies need python2 support.
There is nothing in Debian or elsewhere that needs
chrome-gnome-shell's python2 support.

Thanks,
Jeremy Bicha

Bug#852625: unrar-free is useless and should be removed

[Ying-Chun Liu (PaulLiu)]

Let me say more clear. unrar-free currently isn't useless. Many GUI programs 
are still calling /usr/bin/unrar

And unrar-free converts those calls to unar. Unless all the programs in main 
callls unar or unar provides a compatible /usr/bin/unrar, unrar-free are still 
useful.

Please correct me or I'll lower the severity of the bug.

Thanks a lot,
Paul

Bug#815170: love: New upstream version available

[Markus Koschany]

On 25.01.2017 21:56, Alexandre Detiste wrote:
>> Hi,
>>
>> It is also rather suboptimal that love embeds so
>> many libraries like box2d or enet which are available in Debian. This
>> should be documented [1] and improved but it is not critical for Stretch.
> 
> I will continue working on this after this upload.
> 
>> If you can fix d/copyright today, we can still get 0.10.2 into Stretch
>> (provided that there are no other show-stoppers) but it would be too
>> late tomorrow.
> 
> Ok, I've uploaded these fixes.

Ok, I will take a look at it. Please push all tags and the pristine-tar
commits for mrrescue though.




signature.asc
Description: OpenPGP digital signature

Bug#815170: love: New upstream version available

[Alexandre Detiste]

> Hi,
> 
> It is also rather suboptimal that love embeds so
> many libraries like box2d or enet which are available in Debian. This
> should be documented [1] and improved but it is not critical for Stretch.

I will continue working on this after this upload.

> If you can fix d/copyright today, we can still get 0.10.2 into Stretch
> (provided that there are no other show-stoppers) but it would be too
> late tomorrow.

Ok, I've uploaded these fixes.

Alexandre

Bug#852633: tigervnc-standalone-server: The -once option is no more honored

[Christophe Lohr]

Package: tigervnc-standalone-server
Version: 1.7.0+dfsg-2
Severity: normal
Tags: upstream

Dear Maintainer,
  Please accept my apologies. The recent issue I'm facing is not due to 
the -once option but more probably caused by the -inetd option (I use 
both for the typical "inetd" scenario).


So, you can cancel this ticket.
Sorry for the inconvenience.

Best regards.
Christophe

On 24/01/2017 09:20, Christophe Lohr wrote:

Package: tigervnc-standalone-server
Version: 1.7.0+dfsg-2
Severity: normal
Tags: upstream

Dear Maintainer,
   The last release of Xtigervnc does no more honor the -once option
(Xvnc TigerVNC 1.7.0 - built Jan  5 2017 22:35:23)

Test:
- In one terminal type  Xtigervnc -query localhost -once SecurityTypes=none :2
- In another terminal type: vncviewer localhost:2
- Close the vncviewer session
- Look at the first terminal: Xtigervnc is still runnin!
- Restart another vncviewer localhost:2, Xtigervnc accepts it
...


Best regards
Christophe


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

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

Versions of packages tigervnc-standalone-server depends on:
ii  libaudit1 1:2.6.7-1
ii  libc6 2.24-8
ii  libgcc1   1:6.2.1-5
ii  libgcrypt20   1.7.5-2
ii  libgl1-mesa-glx [libgl1]  13.0.2-3
ii  libgnutls30   3.5.8-1
ii  libjpeg62-turbo   1:1.5.1-2
ii  libpam0g  1.1.8-3.5
ii  libpixman-1-0 0.34.0-1
ii  libselinux1   2.6-3
ii  libstdc++66.2.1-5
ii  libsystemd0   232-8
ii  libx11-6  2:1.6.4-2
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.2-1.1
ii  libxfont2 1:2.0.1-3
ii  libxshmfence1 1.2-1
pn  perl:any  
ii  x11-xkb-utils 7.7+3
ii  xauth 1:1.0.9-1
ii  xkb-data  2.18-1
ii  zlib1g1:1.2.8.dfsg-4

Versions of packages tigervnc-standalone-server recommends:
ii  libgl1-mesa-dri13.0.2-3
ii  tigervnc-common1.7.0+dfsg-2
ii  x11-xserver-utils  7.7+7
ii  xfonts-base1:1.0.4+nmu1

Versions of packages tigervnc-standalone-server suggests:
ii  xfonts-100dpi1:1.0.4+nmu1
ii  xfonts-75dpi 1:1.0.4+nmu1
ii  xfonts-scalable  1:1.0.3-1.1

-- no debconf information

Bug#838860: Version 32+ Flash (SWF) files detected as 'application/octet-stream' (data), not 'application/x-shockwave-flash' by file (libmagic1)

[Christoph Biedl]

Laurence Parry wrote...

> Perhaps, though the SWF format does not make it easy . . .

Thanks a lot for your input, and sorry for the long delay. I'll try to
find a solution that covers at least the vast majority of the files that
are around there. Frankly speaking, file(1) cannot be perfect and will
never be. But we can at least aim.

> == FWS ==
(...)

> On the plus side, "FrameSize RECT always has Xmin and Ymin value of 0." So
> we could create 31 cases depending on the value of the ninth octet equating
> to a particular bitmask and then check for 0-values for Xmin and Xmax [which
> vary in length and, for Ymin, position, depending on their length].
> 
> In other words, in this particular case, we check in bitstream order for:
> [01011|000|xxx|00]
> [mask |   Xmin   |   Xmax   |   Ymin  ]
> 
> I foresee lots of & and ^, unfortunately. But it should be possible. Could
> short-cut it a bit, since for all but the 1- and 2-bit cases, the rest of
> the ninth octet must be 0 in order to match Xmin, so it's not necessary to
> mask the ninth octet to match the first five bits.

That is something to work on. Most notably, a mask len of six and above
requires the following octet has a value of 0x1f the most, i.e.
non-printable. This leaves six cases to examine, that's feasible.


> == ZLIB  (CWS) ==

> CM (compression method) nibble is always 8, and the CINFO (compression info)
> nibble which defines the base-2 logarithm of the LC77 window size, minus
> eight, must be 7 or below. In all the files I have examined, it is 7;
> however it could theoretically be something else. This means the ninth byte
> of a CWS file is 0xN8 , where N <= 7; and commonly it is 0x78 ('x'). [Note:
> it is perfectly possible for an uncompressed FWS file to have an 0x78 in the
> 9th position.]

You brought back old memories. I remember I had to detect compressed
files before, might have been git's packed files. However, this is one
of the places where I'd sacrifice perfection for a solution that is good
enough for the most cases.

> == LZMA (ZWS) ==

> I don't have any of these SWF files to hand, but the specification above
> notes that LZMA Utils only creates files with lz/lp/pb values 3/0/2. This
> would correspond to a properties byte of 0x5d (9th octet). There is also a
> little-endian dictionary size and a file length, which may be all FF if it
> is unknown. For comparison, one bare .lzma file looks like this:
> 
>   5d 00 00 80 00 ff ff ff  ff ff ff ff ff 00 16 e9
> |]...|

So we'll have to guess here anyway. For all three I'll try to come up
with something suitable within the next hours (uploads targetting
stretch should be done be tomorrow). Upstreaming them will be my job,
too.

> Perhaps it's possible to delegate to the LZMA and ZLIB magic to test this?

I'll keep that in mind. It might require a major change in file's
architecture.

Christoph


signature.asc
Description: Digital signature

Bug#852625: unrar-free is useless and should be removed

[PaulLiu]

Exactly,

But the problem is how many other programs depends on unrar's command line.
unar doesn't support unrar and that means other programs has to re-program.

Take an example, Package "unp" doesn't call unar but call unrar.

Yours,
Paul


On Thu, Jan 26, 2017 at 2:00 AM, Adrian Bunk  wrote:

> Package: unrar-free
> Version: 1:0.0.1+cvs20140707-1
> Severity: serious
> Tags: stretch sid
>
> unrar-free itself supports only ancient versions of the RAR format,
> and for any archives created with WinRAR during the past 15 years
> all it does is to call unar.
>

Bug#745553: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Daniel Kahn Gillmor]

On Wed 2017-01-25 15:09:47 -0500, Jens Lechtenboerger wrote:
> On 2017-01-25, at 18:19, Lars Ingebrigtsen wrote:
>
>> Daniel Kahn Gillmor  writes:
>>
>>> So in the scenario above, Bob's cert is still overall valid (because it
>>> has a valid certification over the correct UserID+key from Alice), even
>>> though the ca...@example.org UserID is invalid.
>>>
>>> I don't know mml-mode or elisp well enough to dig into the code and fix
>>> this part of the problem quickly, but if someone has patches that i can
>>> look at that would point to where it might be changed, i'd be happy to
>>> try to review them.
>>
>> I'm also mostly unfamiliar with the mml encryption code, but perhaps
>> Jens could take a peek at this?
>
> mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
> nowadays.  I certainly wouldn’t object if the default value was
> changed, but lots of long-term users might be surprised.

It's also possible that lots of long-term users might be surprised to
find that refreshing one key in their keyring is likely to cause a
change in behavior for the use of other keys in their keyring.  this is
a silent surprise, which seems worse than a public surprise.

> Also, nowadays, if multiple keys are available for a recipient, the
> user is asked which key to use and whether to store that choice.

And how is that choice stored?  How and when can it be revisited by the
user?  What happens if that choice becomes invalid in the future
(e.g. the primary key, or the encryption-capable subkey is revoked,
expired, etc)?

> Then, EasyPG is responsible for calling GnuPG.  Maybe something
> needs to be adjusted there as well.  What is the expected command
> line behavior?

Modern versions of GnuPG automatically select the key which GnuPG knows
to have the best validity among all matches for the selector, thanks to
work put in by Justus Winter (cc'ed), so letting GnuPG make the decision
would relieve emacs of most of the hard work here, and would also mean
that any changes that the user makes to their GnuPG keyring would
automatically take effect in emacs without mml-mode needing to do
anything.

Modern versions of GnuPG also provide a "tofu" mechanism to store and
track that kind of decision in.  Neal Walfield (also cc'ed here) put in
a lot of that implementation, so he might have some suggestions for the
best way to handle it.

Thanks for looking into this, Lars and Jens!

 --dkg



signature.asc
Description: PGP signature

Bug#814454: Bug: reportbug 7.1.2

[Sandro Tosi]

On Wed, Jan 25, 2017 at 2:02 PM, R Rijkhoff  wrote:
> I'm getting a similar error on Debian Stretch (also using reportbug
> 7.1.2).

No, this is not similar at all.

> I'm not sure if this is relevant, but when I selected 'Reportbug' from
> the Mate menu nothing happened. When I ran reportbug in a terminal
> emulator I got the standard set-up wizard. I encountered no errors at
> that stage.
>
> Selecting 'Reportbug' from the Mate menu still doesn't do anything, and
> when I now run reportbug in the terminal I get the following:
>
> $ reportbug reportbug
> Traceback (most recent call last):
>   File "/usr/bin/reportbug", line 2233, in 
> main()
>   File "/usr/bin/reportbug", line 1084, in main
> if newui.initialize():
>   File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line
> 1580, in initialize gi.require_version('Vte', '2.91')
>   File "/usr/lib/python3/dist-packages/gi/__init__.py", line 118, in
> require_version raise ValueError('Namespace %s not available' %
> namespace) ValueError: Namespace Vte not available

this is fixed in 7.1.3 or later, wait for it to be available on
stretch and upgrade.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#828154: RFP: spacemacs -- Emacs configuration to get best of Emacs and Vim

[Sean Whitton]

Dear Lev,

On Wed, Jan 25, 2017 at 11:49:23PM +0500, Lev Lamberov wrote:
> I've wrote a small and ugly Python script which somewhat "parses" (setq
> *-packages [...]) declarations from Spacemacs source code and
> (currently) creates a list of dictionaries with package names as keys
> and booleans (representing built-in status of a given package as defined
> in Spacemacs source code) as values. You can find it in my repository [0].
> 
> If you find the script somehow useful, feel free to contribute and/or
> comment on it. For example, I'm not sure about the format of output. And
> should it be the output for the whole Spacemacs source code without
> duplicates, or a bunch of separate outputs for each packages.el file?

Thank you for working on this.

We don't need the list of packages to be machine-readable.  We just need
it to generate a "to-do list" for pkg-emacsen team members.  So how
about outputting it in ikiwiki's table format?[1]  Then we can add it to
our team wiki[2] (after enabling the table plug-in).

> By the way, I think I've spotted that possibly not all packages are
> declared in the mentioned declarations. So, I also plan to write
> functions to "parse" (use-package `pkg-name' [...]) declarations in
> Spacemacs source code.

Good.  It sounds we need to add those to our list.

[1]  https://ikiwiki.info/ikiwiki/directive/table/
[2]  http://pkg-emacsen.alioth.debian.org/spacemacs/

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#848935: [Pkg-samba-maint] Bug#848935: Bug#848935: Bug#848935: libnss-winbind: winbind authentication and wbinfo --uid-info no longer work after uprading to 4.5.2+dfsg-1

[Mathieu Parent]

2017-01-07 20:41 GMT+01:00 Stéphane Pgt :
>> Unfortunately I wasn't able to reproduce the problem after downgrading to
>> 4.5.2+dfsg-2.
>> I then tried starting from a fresh install of 4.5.2+dfsg-1 (with current
>> version of base system and dependencies) but again, the problem no longer
>> appears.
>> If necessary, I can retrieve at a later time a snapshot of the virtual
>> machine on which I was able to reproduce the problem two weeks ago.
>
> I first restored the snapshot from December, 21th 2016, when I reproduced
> the problem.
> Surprisingly, the problem was not there anymore, the mapped UID all were in
> the configured range.
>
> I then restored the same snapshot again and set the BIOS date and time to
> the
> time at which the VM was last powered off (2016-12-21 00:19:15 CET) before
> booting the OS.
> This time, I was able to reproduce:
>
> root@v-smb-fs:~# getent passwd
> root:x:0:0:root:/root:/bin/bash
> daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
> 
> administrator:*:100500:100513:Administrator:/data/administrator:/bin/false
> testusr:*:101103:100513:testusr:/data/testusr:/bin/false
> krbtgt:*:100502:100513:krbtgt:/data/krbtgt:/bin/false
> guest:*:100501:100514:Guest:/data/guest:/bin/false
>
> root@v-smb-fs:~# wbinfo --user-info testusr
> testusr:*:101103:100513:testusr:/data/testusr:/bin/false
>
> root@v-smb-fs:~# wbinfo --uid-info 101103
> failed to call wbcGetpwuid: WBC_ERR_DOMAIN_NOT_FOUND
> Could not get info for uid 101103
>
> Which may highlight, as you suggested, a caching issue.
>
> At this point, without upgrading nor restarting anything, if I simply flush
> the winbind cache, the mapped UID are now in the correct range, and the
> issue goes away:
>
> root@v-smb-fs:~# net cache flush
>
> root@v-smb-fs:~# getent passwd
> root:x:0:0:root:/root:/bin/bash
> daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
> 
> administrator:*:1:10003:Administrator:/data/administrator:/bin/false
> testusr:*:10001:10003:testusr:/data/testusr:/bin/false
> krbtgt:*:10002:10003:krbtgt:/data/krbtgt:/bin/false
> guest:*:10003:10004:Guest:/data/guest:/bin/false
>
> root@v-smb-fs:~# wbinfo --user-info testusr
> testusr:*:10001:10003:testusr:/data/testusr:/bin/false
>
> root@v-smb-fs:~# wbinfo --uid-info 10001
> testusr:*:10001:10003:testusr:/data/testusr:/bin/false
>
> If you are interested, I could share some files or a complete archive of the
> VM on which the problem was reproduced.

I don't know. I'm tempted to close the bug, but maybe Jelmer or Andrew
have some time to go a bit deeper?

Regards

-- 
Mathieu

Bug#745553: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Lars Ingebrigtsen]

Daniel Kahn Gillmor  writes:

> So in the scenario above, Bob's cert is still overall valid (because it
> has a valid certification over the correct UserID+key from Alice), even
> though the ca...@example.org UserID is invalid.
>
> I don't know mml-mode or elisp well enough to dig into the code and fix
> this part of the problem quickly, but if someone has patches that i can
> look at that would point to where it might be changed, i'd be happy to
> try to review them.

I'm also mostly unfamiliar with the mml encryption code, but perhaps
Jens could take a peek at this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Bug#852326: libreoffice-common: Please add Multi-Arch: foreign

[Elrond]

On Tue, Jan 24, 2017 at 17:45:18 +0100, Rene Engelhard wrote:
[...]
> Exactly my point since years. I don't see the need in multi-arch since
> years.
[...]

Okay, I do still think, that we have some technical
discrepancies in our thinkings, but from what I read here,
this can be summarized as:

You don't want to consider multi-arch at all, so you're
tagging this wontfix.

I give up here.


Cheers

Elrond

Bug#745553: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Jens Lechtenboerger]

On 2017-01-25, at 18:19, Lars Ingebrigtsen wrote:

> Daniel Kahn Gillmor  writes:
>
>> So in the scenario above, Bob's cert is still overall valid (because it
>> has a valid certification over the correct UserID+key from Alice), even
>> though the ca...@example.org UserID is invalid.
>>
>> I don't know mml-mode or elisp well enough to dig into the code and fix
>> this part of the problem quickly, but if someone has patches that i can
>> look at that would point to where it might be changed, i'd be happy to
>> try to review them.
>
> I'm also mostly unfamiliar with the mml encryption code, but perhaps
> Jens could take a peek at this?

mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
nowadays.  I certainly wouldn’t object if the default value was
changed, but lots of long-term users might be surprised.

Also, nowadays, if multiple keys are available for a recipient, the
user is asked which key to use and whether to store that choice.

Then, EasyPG is responsible for calling GnuPG.  Maybe something
needs to be adjusted there as well.  What is the expected command
line behavior?

Best wishes
Jens

Bug#814454: Bug: reportbug 7.1.2

[R Rijkhoff]

I'm getting a similar error on Debian Stretch (also using reportbug
7.1.2).

I'm not sure if this is relevant, but when I selected 'Reportbug' from
the Mate menu nothing happened. When I ran reportbug in a terminal
emulator I got the standard set-up wizard. I encountered no errors at
that stage.

Selecting 'Reportbug' from the Mate menu still doesn't do anything, and
when I now run reportbug in the terminal I get the following:

$ reportbug reportbug
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2233, in 
main()
  File "/usr/bin/reportbug", line 1084, in main
if newui.initialize():
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line
1580, in initialize gi.require_version('Vte', '2.91')
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 118, in
require_version raise ValueError('Namespace %s not available' %
namespace) ValueError: Namespace Vte not available


I can run the following:

$ reportbug -q --template -T none -s none -S normal -b --list-cc none
-q reportbug
Detected character set: UTF-8
Please change your locale if this is incorrect.

Using 'R Rijkhoff <nos...@beepmode.co.uk>' as your from address.
Getting status for reportbug...
Will send report to Debian (per lsb_release).
Maintainer for reportbug is 'Reportbug Maintainers
<reportbug-ma...@lists.alioth.debian.org>'. Looking up dependencies of
reportbug... Getting status for related package python3-reportbug...
Looking up 'depends' of related package python3-reportbug...
Looking up 'suggests' of related package python3-reportbug...
Getting changed configuration files...

Rewriting subject to 'reportbug: none'
Gathering additional data, this may take a while...
Saving a backup of the report
at /tmp/reportbug-reportbug-backup-20170125-2209-wuhr2l77 Content-Type:
text/plain; charset="us-ascii" MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: R Rijkhoff <nos...@beepmode.co.uk>
To: Debian Bug Tracking System <sub...@bugs.debian.org>
Subject: reportbug: none
X-Debbugs-Cc: none

Package: reportbug
Version: 7.1.2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
** /home/rijkhoff/.reportbugrc:
reportbug_version "7.1.2"
mode standard
ui gtk2
email "nos...@beepmode.co.uk"
smtphost "server.beepmode.co.uk"
smtpuser "nos...@beepmode.co.uk"
smtptls

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

Kernel: Linux 4.9.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 reportbug depends on:
ii  apt1.4~beta3
ii  python3-reportbug  7.1.2
pn  python3:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
ii  claws-mail 3.14.1-3
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs23-bin-common | emacs24-bin-common
ii  exim4  4.88-4
ii  exim4-daemon-light [mail-transport-agent]  4.88-4
ii  file   1:5.29-2
ii  gir1.2-gtk-3.0 3.22.6-1
pn  gir1.2-vte-2.91
ii  gnupg  2.1.17-2
ii  python3-gi 3.22.0-2
pn  python3-gtkspellcheck  
pn  python3-urwid  
ii  xdg-utils  1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.4~beta3
ii  file   1:5.29-2
ii  python3-debian 0.1.29
ii  python3-debianbts  2.6.1
ii  python3-requests   2.12.4-1
pn  python3:any

python3-reportbug suggests no packages.

-- no debconf information

Bug#847682: [Pkg-samba-maint] Bug#847682: winbind: New install message pam_unix: internal module error (retval = PAM_AUTHINFO_UNAVAIL(9)

[Mathieu Parent]

2016-12-10 16:44 GMT+01:00 Duncan Hare :
> Package: winbind
> Version: 2:4.2.10+dfsg-0+deb8u3
> Severity: normal

Hi,

Do you still reproduce it on latest jessie?

Do you have more info? This bug report lacks information.

WHat is your nsswitch.conf?

Regards

-- 
Mathieu Parent

Bug#852632: mozo clashes with Mate's preferred applications

[R Rijkhoff]

Package: mozo
Version: 1.16.0-1

When opening the properties dialogue of a menu item mozo writes
a .desktop file to ~/.local/share/applications (even if you make no
changes and select 'Close'). As a result the application will no longer
be an option in the 'Preferred Applications' menu.

To reproduce:
* Install Claws Mail and set it as the preferred mail reader via
  Control Centre > Preferred Applications > Internet > Mail Reader
* Open mozo (Control Centre > Main Menu) and open the properties for
  Claws Mail
* Go back to the Preferred Applications menu - Claws Mail will no
  longer be selected, nor will it be an option.

Selecting 'Revert' from the Main Menu window will remove all files in
~/.local/share/applications, and applications such as Claws Mail can
then be set as a preferred application again. (Interestingly, if you
follow the above steps Claws Mail will be the preferred mail reader
again).

This effectively means that mozo and the preferred applications
function are incompatible: you can change the properties of menu items
_or_ set an applications as a preferred application - but you can't do
both.

I'm using Debian Stretch with Mate 1.16.1 and the 4.9.0-1-amd64 kernel.

Apologies if this bug has been reported already (I couldn't find any
bugs for mozo).

Thanks,

R Rijkhoff

Bug#852631: bzr-git: FTBFS: NotImplementedError:

[Chris Lamb]

Source: bzr-git
Version: 0.6.13-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

bzr-git fails to build from source in unstable/amd64:

  […]

  if self._determine_file_mode():
File "/usr/lib/python2.7/dist-packages/dulwich/repo.py", line 189, in 
_determine_file_mode
  raise NotImplementedError(self._determine_file_mode)
  NotImplementedError: >>
  
  ==
  ERROR: 
bzrlib.plugins.git.tests.test_push.InterToGitRepositoryTests.test_instance
  --
  Traceback (most recent call last):
  testtools.testresult.real._StringException: Empty attachments:
log
  
  Traceback (most recent call last):
File "«BUILDDIR»/tests/test_push.py", line 45, in setUp
  format=format_registry.make_bzrdir("git"))
File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 
2756, in make_repository
  made_control = self.make_bzrdir(relpath, format=format)
File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 
2743, in make_bzrdir
  return format.initialize_on_transport(t)
File "«BUILDDIR»/dir.py", line 231, in initialize_on_transport
  repo = TransportRepo.init(transport, bare=self.bare)
File "«BUILDDIR»/transportgit.py", line 396, in init
  ret._init_files(bare)
File "/usr/lib/python2.7/dist-packages/dulwich/repo.py", line 198, in 
_init_files
  if self._determine_file_mode():
File "/usr/lib/python2.7/dist-packages/dulwich/repo.py", line 189, in 
_determine_file_mode
  raise NotImplementedError(self._determine_file_mode)
  NotImplementedError: >>
  
  ==
  ERROR: 
bzrlib.plugins.git.tests.test_git_remote_helper.OpenLocalDirTests.test_from_dir
  --
  Traceback (most recent call last):
  testtools.testresult.real._StringException: Empty attachments:
log
  
  Traceback (most recent call last):
File "«BUILDDIR»/tests/test_git_remote_helper.py", line 61, in test_from_dir
  self.make_branch_and_tree('.', format='git')
File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 
3021, in make_branch_and_tree
  b = self.make_branch(relpath, format=format)
File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 
2711, in make_branch
  repo = self.make_repository(relpath, format=format)
File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 
2756, in make_repository
  made_control = self.make_bzrdir(relpath, format=format)
File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 
2743, in make_bzrdir
  return format.initialize_on_transport(t)
File "«BUILDDIR»/dir.py", line 231, in initialize_on_transport
  repo = TransportRepo.init(transport, bare=self.bare)
File "«BUILDDIR»/transportgit.py", line 396, in init
  ret._init_files(bare)
File "/usr/lib/python2.7/dist-packages/dulwich/repo.py", line 198, in 
_init_files
  if self._determine_file_mode():
File "/usr/lib/python2.7/dist-packages/dulwich/repo.py", line 189, in 
_determine_file_mode
  raise NotImplementedError(self._determine_file_mode)
  NotImplementedError: >>
  
  ==
  ERROR: 
bzrlib.plugins.git.tests.test_push.InterToGitRepositoryTests.test_pointless_fetch_refs_old_mapping
  --
  Traceback (most recent call last):
  testtools.testresult.real._StringException: Empty attachments:
log
  
  Traceback (most recent call last):
File "«BUILDDIR»/tests/test_push.py", line 45, in setUp
  format=format_registry.make_bzrdir("git"))
File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 
2756, in make_repository
  made_control = self.make_bzrdir(relpath, format=format)
File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 
2743, in make_bzrdir
  return format.initialize_on_transport(t)
File "«BUILDDIR»/dir.py", line 231, in initialize_on_transport
  repo = TransportRepo.init(transport, bare=self.bare)
File "«BUILDDIR»/transportgit.py", line 396, in init
  ret._init_files(bare)
File "/usr/lib/python2.7/dist-packages/dulwich/repo.py", line 198, in 
_init_files
  if self._determine_file_mode():
File "/usr/lib/python2.7/dist-packages/dulwich/repo.py", line 189, in 
_determine_file_mode
  raise NotImplementedError(self._determine_file_mode)
  NotImplementedError: >>
  
  ==
  ERROR: 

Bug#852543: apache and sysvinit

[Tom H]

apache2ctl should check for "/run/systemd/system" not for "/run/systemd"

Bug#852506: Command-line option to import file

[Jeffrey Ratcliffe]

> Please consider adding a command-line option such as --import-all
> that takes a PDF file and then simply imports all the pages therein
> into a new gscan2pdf session. Another option --import could first
> display the dialog to select the page range.

1.7.0 already has this. I'll upload it to unstable when stretch is
released. Until then, get it off sourceforge, or launchpad.

Bug#852250: [lua-socket] luasocket was not compiled with UNIX sockets support

[Mathieu Parent]

Control: reassign -1 prosody-modules
Control: tag -1 + patch upstream confirmed


On Wed, 25 Jan 2017 13:04:02 +0100 Enrico Tassi
 wrote:
> On Wed, Jan 25, 2017 at 10:24:25AM +0100, Michael Meskes wrote:
> > > Hopefully somebody is prepared to fix all rdepends.
> >
> > Or better reverts the API change.
>
> The bug is definitely important.
>
> Mathieu can you take care of it?

Can you test the attached patch on prosody-modules? It's future-proof
and inspired by Courtney's patch on ekeyd.

Regards.

Mathieu Parent
From 6e1199cd1b19361a03bbd2d2243246bd1f75921b Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Wed, 25 Jan 2017 20:42:56 +0100
Subject: [PATCH] Fix compatibility problems with Unix domain sockets in newer
 versions of luasocket

Inspired by a similar patch on ekeyd by Courtney Bane.
---
 mod_auth_dovecot/auth_dovecot/sasl_dovecot.lib.lua | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/mod_auth_dovecot/auth_dovecot/sasl_dovecot.lib.lua b/mod_auth_dovecot/auth_dovecot/sasl_dovecot.lib.lua
index a6f1958..8e2f1cf 100644
--- a/mod_auth_dovecot/auth_dovecot/sasl_dovecot.lib.lua
+++ b/mod_auth_dovecot/auth_dovecot/sasl_dovecot.lib.lua
@@ -26,7 +26,11 @@ local m_random = math.random;
 local tostring, tonumber = tostring, tonumber;
 
 local socket = require "socket"
-pcall(require, "socket.unix");
+function tryload_unix()
+   socket.unix = require "socket.unix"
+end
+pcall(tryload_unix);
+local sock = socket.unix.stream or socket.unix.tcp or socket.unix
 local base64 = require "util.encodings".base64;
 local b64, unb64 = base64.encode, base64.decode;
 local jid_escape = require "util.jid".escape;
@@ -54,9 +58,9 @@ local function connect(socket_info)
 		conn = socket.tcp();
 		ok, err = conn:connect(socket_host, socket_port);
 		socket_path = ("%s:%d"):format(socket_host, socket_port);
-	elseif socket.unix then
+	elseif sock then
 		socket_path = socket_info;
-		conn = socket.unix();
+		conn = sock();
 		ok, err = conn:connect(socket_path);
 	else
 		err = "luasocket was not compiled with UNIX sockets support";
-- 
2.11.0

Bug#852612: Acknowledgement (linux-image-4.9.0-1-amd64: kernel 4.9.2-2 panics on boot)

[Salvatore Bonaccorso]

Control: forcemerge 851928 -1

Hi Robert,

On Wed, Jan 25, 2017 at 01:17:05PM -0500, Robert Lange wrote:
> This bug is almost certainly related to this patch, which I believe is not
> in the currently packaged kernel:
> 
> https://git.kernel.org/cgit/linux/kernel/git/efi/efi.git/commit/?h=next=b2a91a35445229
> 
> The machine referenced in that patch is the Lenovo ThinkPad w541, which is a
> minor hardware upgrade of my w540.

I think this should be the same as #851928 addressed by 

 - http://git.kernel.org/linus/20b1e22d01a4b0b11d3a1066e9feb04be38607ec
 - http://git.kernel.org/linus/0100a3e67a9cef64d72cd3a1da86f3ddbee50363

and already pending for the next upload of src:linux to unstable
(4.9.6-1).

Regards,
Salvatore

Bug#158969: [PATCH] doc: emphasize that config.h must be first

[Eric Blake]

* doc/autoconf.texi (C and Posix Variants, System Services):
Remind user to include config.h first.
(Configuration Headers): Give another reason why config.h must be
first, and mention that only .c files need it.
Based on discussion on bugs.debian.org/158969

Signed-off-by: Eric Blake 
---

I'm still waiting for mirabilos to post an updated version of
his patch to AC_SYS_LARGEFILE docs, but my contribution seems to
be worth pushing on its own right now, once I've expanded it to
cover more places as mentioned by Zack.

 doc/autoconf.texi | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 07f238d..e510323 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -3268,7 +3268,12 @@ Configuration Headers

 The package should @samp{#include} the configuration header file before
 any other header files, to prevent inconsistencies in declarations (for
-example, if it redefines @code{const}).
+example, if it redefines @code{const}, or if it defines a macro like
+@code{_FILE_OFFSET_BITS} that affects the behavior of system
+headers). Note that it is okay to only include @file{config.h} from
+@file{.c} files; the project's @file{.h} files can rely on
+@file{config.h} already being included first by the corresponding
+@file{.c} file.

 To provide for VPATH builds, remember to pass the C compiler a @option{-I.}
 option (or @option{-I..}; whichever directory contains @file{config.h}).
@@ -8595,7 +8600,9 @@ System Services
 @code{off_t} is wider than @code{long int}, since this is common when
 large-file support is enabled.  For example, it is not correct to print
 an arbitrary @code{off_t} value @code{X} with @code{printf ("%ld",
-(long int) X)}.
+(long int) X)}.  Also, when using this macro in concert with
+@code{AC_CONFIG_HEADERS}, be sure that @file{config.h} is included
+before any system header.

 The LFS introduced the @code{fseeko} and @code{ftello} functions to
 replace their C counterparts @code{fseek} and @code{ftell} that do not
@@ -8632,11 +8639,13 @@ C and Posix Variants
 @anchor{AC_USE_SYSTEM_EXTENSIONS}
 @defmac AC_USE_SYSTEM_EXTENSIONS
 @acindex{USE_SYSTEM_EXTENSIONS}
-If possible, enable
-extensions to C or Posix on hosts that normally disable the extensions,
-typically due to standards-conformance namespace issues.  This should be
-called before any macros that run the C compiler.  The following
-preprocessor macros are defined where appropriate:
+If possible, enable extensions to C or Posix on hosts that normally
+disable the extensions, typically due to standards-conformance namespace
+issues.  This should be called before any macros that run the C
+compiler.  Also, when using this macro in concert with
+@code{AC_CONFIG_HEADERS}, be sure that @file{config.h} is included
+before any system header.  The following preprocessor macros are defined
+where appropriate:

 @table @code
 @item _GNU_SOURCE
-- 
2.9.3

Bug#850620: [Pkg-utopia-maintainers] Bug#850620: [network-manager] does not update lifetime of temporary ipv6 addresses anymore, resulting in connection breakage

[Maximilian Engelhardt]

On Sonntag, 8. Januar 2017 17:34:09 CET Michael Biebl wrote:
> Hi
> 
> Am 08.01.2017 um 16:48 schrieb Maximilian Engelhardt:
> > Package: network-manager
> > Version: 1.4.4-1
> > Severity: important
> > 
> > --- Please enter the report below this line. ---
> > 
> > After updating to network-manger 1.4.4-1 I noticed a lot of breakages in
> > ssh connections.  It turned out this is related to temporary ipv6
> > addresses being deprecated, deleted and newly created at a rapid rate,
> > thus after a short time the address used by my ssh connection vanishes.
> > 
> > Having a closer look with "ip addr show" explained what is going on. My
> > router advertisements have a short lifetime configured. A new router
> > advertisement does only update the lifetime of the mngtmpaddr but not the
> > temporary addresses. This causes them to time out and permanently being
> > deleted and newly created.
> > 
> > Disabling network-manager doesn't show this problem. Also downgrading
> > network- manager to version 1.4.2-3 fixes this issue for me.
> 
> This doesn't look like a downstream specific issue, so it would be great
> if you can file this upstream at
> https://bugzilla.gnome.org/enter_bug.cgi?product=NetworkManager
> 
> You might check if it has already been reported at
> https://bugzilla.gnome.org/page.cgi?id=browse.html=NetworkManager
> 
> Once you have an upstream bug number, please report back so we can mark
> this bug accordingly.
> 
> Regards,
> Michael

I can confirm this is fixed by the upstream patch.

It would be great to get this fixed for stretch. In my test I just had to 
backport the upstream fix.

Thanks,
Maxi

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

Bug#852630: inadyn: --drop-privs option causes inadyn to terminate with exit code 112 (daemon fails)

[Jo Valentine-Cooper]

Package: inadyn
Version: 1.99.4-1
Severity: important


On armel (possibly other archs, but I haven't tested them), the
--drop-privs option for inadyn does not work; it causes inadyn to
terminate with exit code 112:

$ sudo inadyn --config /etc/inadyn.conf --drop-privs
debian-inadyn:debian-inadyn ; echo $?
112

This is a problem because the init script for inadyn makes use of this
option in its DAEMON_ARGS. The practical upshot of this is that inadyn
fails to start at all as a daemon on my armel system unless
/etc/init.d/inadyn is edited to remove that argument.

Hope this helps!



-- System Information:
Debian Release: 8.6
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 3.16.0-4-kirkwood
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 inadyn depends on:
ii  adduser  3.113+nmu3
ii  libc62.19-18+deb8u7

inadyn recommends no packages.

inadyn suggests no packages.

-- Configuration Files:
/etc/default/inadyn changed:
RUN_DAEMON="yes"
RUN_IPUP="no"
USER="debian-inadyn"
GROUP="debian-inadyn"

/etc/inadyn.conf [Errno 13] Permission denied: u'/etc/inadyn.conf'

-- no debconf information

Bug#158969: autoconf: AC_SYS_LARGEFILE documentation misleading

[Zack Weinberg]

On Wed, Jan 25, 2017 at 2:06 PM, Eric Blake  wrote:
>
> I also think we can try harder to point out the need for config.h to
> appear first.  How about the following counter-proposal:
...

If we're going to warn people about this in the context of specific
macros we should do the same for AC_USE_SYSTEM_EXTENSIONS as well.  I
don't *think* there are any other stock macros that put
feature-selection #defines into config.h but I could have missed
something.

zw

Bug#852617: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

[Thorsten Glaser]

On Wed, 25 Jan 2017, Zack Weinberg wrote:

> > Interesting, as I recall seeing -D_FILE_OFFSET_BITS=64 on various
> > compiler command lines when working under GNU. (I normally work
> > under BSD at home, so I don’t know where exactly.)
> 
> Is it possible that those programs were not using a config.h?

Hm right, that could have been possible… although I also vaguely
recall seeing it on short compile lines, so there would have been
very few -DHAVE_* on it (but that’s not impossible either).

> 2000-06-08.  According to NEWS, it was not in 2.13 (which was released
> 1999-05-01), but it was in the very next release, 2.50 (2001-05-21).
> The ChangeLog entry for the addition says "Import AC_SYS_LARGEFILE
> from largefile.m4 serial 12", so that sounds like there was an add-on
> .m4 file with the same functionality floating around prior to that - I

Hm, possible as well then. (I mostly use 2.13 for old software,
2.61 for new software, when building on my BSD. Debian has more
up-to-date autoconf, and only that, nowadays.)

> don't know where to find copies of that file.

Me either. Well, if it’s this obscure… I could almost say this
issue can be closed, especially since we seem to be going for‐
wards with the documentation issue. (It can still be confusing
for people switching from no config.h to using config.h, but
the suggested documentation change addresses this somewhat
explicitly.)

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#852629: O: xmldiff -- tree to tree correction between xml documents

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of xmldiff is apparently not active anymore.  Therefore, 
I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

More information about this package:

http://tracker.debian.org/pkg/xmldiff


Package: xmldiff
Binary: xmldiff, xmldiff-xmlrev
Version: 0.6.10-2.3
Maintainer: Alexandre Fayolle 
Uploaders: Sylvain Thenault , Alexandre Fayolle 
, Emile Anclin , Alain 
Leufroy 
Build-Depends: debhelper (>= 5.0.38), dh-python, python (>= 2.4.6-2), 
python-dev (>= 2.4.6-2)
Architecture: any all
Standards-Version: 3.8.3
Format: 1.0
Files:
 b96356dbb9d2b3a8628ff734abc66993 1963 xmldiff_0.6.10-2.3.dsc
 a61e6e95a130e3bd53f5ea5616cc5314 45827 xmldiff_0.6.10.orig.tar.gz
 ec7047c94864cc07bfb1e4ff40aeb861 4608 xmldiff_0.6.10-2.3.diff.gz
Checksums-Sha256:
 03889bef72ed456c522fa8202b1d9fae417b412a786ec905d311547b0b5465a7 1963 
xmldiff_0.6.10-2.3.dsc
 83aba252df2f760c8bf008b9c5d3080911eab2d2b39c371d3b47f67abf4b4ec5 45827 
xmldiff_0.6.10.orig.tar.gz
 b0c9d8849c049b4f72c64ee46208da6b3dcaa1a54a49104881ba2d2d57b9e941 4608 
xmldiff_0.6.10-2.3.diff.gz
Homepage: http://www.logilab.org/project/xmldiff
Package-List: 
 xmldiff deb misc optional arch=any
 xmldiff-xmlrev deb misc optional arch=all
Directory: pool/main/x/xmldiff
Priority: source
Section: text

Package: xmldiff
Version: 0.6.10-2.3
Installed-Size: 217
Maintainer: Alexandre Fayolle 
Architecture: amd64
Replaces: python2.3-xmldiff
Depends: python (<< 2.8), python (>= 2.7~), python:any (<< 2.8), python:any (>= 
2.7.5-5~), libc6 (>= 2.4)
Suggests: xmldiff-xmlrev, python-psyco
Conflicts: python2.3-xmldiff
Description-en: tree to tree correction between xml documents
 Xmldiff is a utility for extracting differences between two xml
 files.  It returns a set of primitives to apply on source tree to
 obtain the destination tree.
 .
 The implementation is based on _Change detection in hierarchically
 structured - information_, by S. Chawathe, A. Rajaraman,
 H. Garcia-Molina and J. Widom, - Stanford University, 1996
Description-md5: be2a6777e438b3b00da5e32aaf0e2a89
Homepage: http://www.logilab.org/project/xmldiff
Python-Version: 2.7
Tag: devel::lang:python, implemented-in::python, interface::commandline,
 role::program, use::synchronizing, works-with-format::xml
Section: text
Priority: optional
Filename: pool/main/x/xmldiff/xmldiff_0.6.10-2.3_amd64.deb
Size: 43790
MD5sum: ab8b83fe3a9680e3f0b33ce04054221d
SHA256: 8a2e90e2adc3bce36ff1383ec6407377b5b11a85363481b8ee3d9adc1c14f13a

Package: xmldiff-xmlrev
Source: xmldiff
Version: 0.6.10-2.3
Installed-Size: 30
Maintainer: Alexandre Fayolle 
Architecture: all
Depends: xmldiff, libxml2-utils, xsltproc, opensp
Recommends: docbook-xsl
Description-en: xmldiff output formatter
 xmlrev can be used to display the differences between two XML
 documents computed by xmldiff as an HTML document.
Description-md5: 2b3b10bb6c18ccceee91920525e498ba
Homepage: http://www.logilab.org/project/xmldiff
Tag: implemented-in::python, interface::commandline, role::program,
 scope::utility, use::converting, use::synchronizing,
 works-with-format::html, works-with-format::xml, works-with::text
Section: misc
Priority: optional
Filename: pool/main/x/xmldiff/xmldiff-xmlrev_0.6.10-2.3_all.deb
Size: 8688
MD5sum: 7e55fd6d46fb136140604a219e4d23c7
SHA256: 50e322358cfdcc4f0196e1b4cb010cf08e215898cc97a8c3d6d54e5eca6f08fb

Bug#158969: autoconf: AC_SYS_LARGEFILE documentation misleading

[Thorsten Glaser]

On Wed, 25 Jan 2017, Eric Blake wrote:

> Thanks; that's helpful.  I'm still thinking we may want to iterate on

Yes, of course; you know autoconf much better than I do.

> You're deleting all mention that the macro may modify CC (true, it
> doesn't do it on most platforms, but the code is still there that does
> it for Irix)

Ah, okay. Let’s change that then.

> I also think we can try harder to point out the need for config.h to
> appear first.  How about the following counter-proposal:
> 
> diff --git i/doc/autoconf.texi w/doc/autoconf.texi
> index 55f96a3..2901937 100644
> --- i/doc/autoconf.texi
> +++ w/doc/autoconf.texi
> @@ -8584,9 +8584,10 @@ System Services
>  Arrange for 64-bit file offsets, known as
>  @uref{http://@/www.unix-systems@/.org/@/version2/@/whatsnew/@/lfs20mar.html,
>  large-file support}.  On some hosts, one must use special compiler
> -options to build programs that can access large files.  Define,
> -by calling @code{AC_DEFINE_UNQUOTED},
> -@code{_FILE_OFFSET_BITS} and @code{_LARGE_FILES} if necessary.
> +options to build programs that can access large files, and this macro
> +modifies the output variable @code{CC} in that case.  This macro will
> +additionally define @code{_FILE_OFFSET_BITS} and @code{_LARGE_FILES} if
> +necessary, by calling @code{AC_DEFINE_UNQUOTED}.

Nice, but I think I can improve on that a bit (later, I’m almost
dropping down due to tiredness), it still confuses me a bit ;)

>  Large-file support can be disabled by configuring with the
>  @option{--disable-largefile} option.
> @@ -8595,7 +8596,9 @@ System Services
>  @code{off_t} is wider than @code{long int}, since this is common when
>  large-file support is enabled.  For example, it is not correct to print
>  an arbitrary @code{off_t} value @code{X} with @code{printf ("%ld",
> -(long int) X)}.
> +(long int) X)}.  Also, when using this macro in concert with
> +@code{AC_CONFIG_HEADERS}, be sure that @file{config.h} is included
> +before any system header.

Making that explicit is good, yes. Thank you.


On Wed, 25 Jan 2017, Zack Weinberg wrote:

> If we're going to warn people about this in the context of specific
> macros we should do the same for AC_USE_SYSTEM_EXTENSIONS as well.  I

Feel free to… but that’s outside of my scope; I never heard of that
particular macro ;)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#158969: autoconf: AC_SYS_LARGEFILE documentation misleading

[Eric Blake]

On 01/25/2017 11:30 AM, Thorsten Glaser wrote:
> On Wed, 25 Jan 2017, Eric Blake wrote:
> 
>> Please propose a patch to the documentation, rather than just telling me
>> that it is wrong, so that we have a concrete proposal for a wording
>> improvement that we can discuss.
> Oh okay, I’ll cater for lazy upstreams this time ;-)

It's not necessarily laziness :)

> See the attached git format-patch.
> 

Thanks; that's helpful.  I'm still thinking we may want to iterate on
the wording, in particular:

> +++ b/doc/autoconf.texi
> @@ -8584,8 +8584,8 @@ if the system supports @samp{#!}, @samp{no} if not.
>  Arrange for 64-bit file offsets, known as
>  @uref{http://@/www.unix-systems@/.org/@/version2/@/whatsnew/@/lfs20mar.html,
>  large-file support}.  On some hosts, one must use special compiler
> -options to build programs that can access large files.  Append any such
> -options to the output variable @code{CC}.  Define

You're deleting all mention that the macro may modify CC (true, it
doesn't do it on most platforms, but the code is still there that does
it for Irix); I don't think we want the change to be that drastic.

> +options to build programs that can access large files.  Define,
> +by calling @code{AC_DEFINE_UNQUOTED},
>  @code{_FILE_OFFSET_BITS} and @code{_LARGE_FILES} if necessary.

I also think we can try harder to point out the need for config.h to
appear first.  How about the following counter-proposal:

diff --git i/doc/autoconf.texi w/doc/autoconf.texi
index 55f96a3..2901937 100644
--- i/doc/autoconf.texi
+++ w/doc/autoconf.texi
@@ -8584,9 +8584,10 @@ System Services
 Arrange for 64-bit file offsets, known as
 @uref{http://@/www.unix-systems@/.org/@/version2/@/whatsnew/@/lfs20mar.html,
 large-file support}.  On some hosts, one must use special compiler
-options to build programs that can access large files.  Define,
-by calling @code{AC_DEFINE_UNQUOTED},
-@code{_FILE_OFFSET_BITS} and @code{_LARGE_FILES} if necessary.
+options to build programs that can access large files, and this macro
+modifies the output variable @code{CC} in that case.  This macro will
+additionally define @code{_FILE_OFFSET_BITS} and @code{_LARGE_FILES} if
+necessary, by calling @code{AC_DEFINE_UNQUOTED}.

 Large-file support can be disabled by configuring with the
 @option{--disable-largefile} option.
@@ -8595,7 +8596,9 @@ System Services
 @code{off_t} is wider than @code{long int}, since this is common when
 large-file support is enabled.  For example, it is not correct to print
 an arbitrary @code{off_t} value @code{X} with @code{printf ("%ld",
-(long int) X)}.
+(long int) X)}.  Also, when using this macro in concert with
+@code{AC_CONFIG_HEADERS}, be sure that @file{config.h} is included
+before any system header.

 The LFS introduced the @code{fseeko} and @code{ftello} functions to
 replace their C counterparts @code{fseek} and @code{ftell} that do not


-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Bug#852250: [lua-socket] luasocket was not compiled with UNIX sockets support

[Mathieu Parent]

On Wed, 25 Jan 2017 13:37:41 +0100 Enrico Tassi
 wrote:
> On Wed, Jan 25, 2017 at 10:24:25AM +0100, Michael Meskes wrote:
> > > Hopefully somebody is prepared to fix all rdepends.
> >
> > Or better reverts the API change.
>
> I gave a quick look at the problem.
>
> I don't know why Mathieu packaged a new upstream snapshot exactly,
> I hope it is not for the new unix.tcp/udp feature.  If so, reverting the
> API change is as simple as reverting
>
>   aa1b8cc9bc35e56de15eeb153c899e4c51de82a8
>
> There is just a trivial conflict on the makefile.
>
> Mathieu, does luasandbox need the new unix sockets?

Yes. I need both TCP and UDP socket.

Regards.

Mathieu Parent

Bug#852617: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

[Paul Eggert]

On 01/25/2017 10:24 AM, Zack Weinberg wrote:

The ChangeLog entry for the addition says "Import AC_SYS_LARGEFILE
from largefile.m4 serial 12", so that sounds like there was an add-on
.m4 file with the same functionality floating around prior to that - I
don't know where to find copies of that file.


It's from gnulib, which in turn got it from coreutils.

Gnulib still has m4/largefile.m4, although now it's merely a copy of 
what's in (the next version of) Autoconf. That is, people use the Gnulib 
largefile.m4 because they don't want to wait for the next release of 
Autoconf to come out.

Bug#828154: RFP: spacemacs -- Emacs configuration to get best of Emacs and Vim

[Lev Lamberov]

Hi Axel and Sean,

I've wrote a small and ugly Python script which somewhat "parses" (setq
*-packages [...]) declarations from Spacemacs source code and
(currently) creates a list of dictionaries with package names as keys
and booleans (representing built-in status of a given package as defined
in Spacemacs source code) as values. You can find it in my repository [0].

If you find the script somehow useful, feel free to contribute and/or
comment on it. For example, I'm not sure about the format of output. And
should it be the output for the whole Spacemacs source code without
duplicates, or a bunch of separate outputs for each packages.el file?

By the way, I think I've spotted that possibly not all packages are
declared in the mentioned declarations. So, I also plan to write
functions to "parse" (use-package `pkg-name' [...]) declarations in
Spacemacs source code.

Cheers!
Lev

[0] https://github.com/dogsleg/spacemacs-pkgs



signature.asc
Description: OpenPGP digital signature

Bug#852626: RFS: h5py/2.7.0~rc3-1 [RC]

[Gianfranco Costamagna]

Hello,

>I am on it :)
not sure, I probably uploaded it before you?


G:

Bug#852627: lcms2: CVE-2016-10165: heap OOB read parsing crafted ICC profile

[Salvatore Bonaccorso]

Control: severity -1 grave

Actually raising the severity to RC, think this should go into stretch
and the patch is simple. 

Regards,
Salvatore

Bug#852628: guacamole: make mh_resolve_dependencies work

[Dominik George]

Source: guacamole
Version: 0.9.9+dfsg-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

mh_resolve_dependencies --non-interactive --offline -pguacamole 
--base-directory=/build/guacamole-client-0.9.9\+dfsg --non-explore
Analysing extensions/guacamole-auth-noauth/pom.xml...
Analysing guacamole-common-js/pom.xml...
Analysing guacamole-common/pom.xml...
Analysing guacamole-ext/pom.xml...
Analysing guacamole/pom.xml...
Analysing pom.xml...
> dpkg --search 
> /usr/share/maven-repo/org/glyptodon/guacamole/guacamole-common-js/*/* 
dpkg failed to execute successfully
Offline mode. Give up looking for package containing 
/usr/share/maven-repo/org/glyptodon/guacamole/guacamole-common-js
Nov 27, 2016 3:42:26 PM org.debian.maven.packager.DependenciesSolver$ToResolve 
resolve
SEVERE: Cannot resolve dependencies in 
/build/guacamole-client-0.9.9+dfsg/guacamole/pom.xml: Dependency not found 
org.glyptodon.guacamole:guacamole-common-js:zip:0.9.9
ERROR:
guacamole/pom.xml: dependency is not packaged in the Maven repository for 
Debian: org.glyptodon.guacamole:guacamole-common-js:0.9.9

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

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

-BEGIN PGP SIGNATURE-

iQJ4BAEBCABiFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAliI74wxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYxIcbmlrQG5h
dHVyYWxuZXQuZGUACgkQt5o8FqDE8pZeORAAzIrMa7qaNr/u8Zy1qhW5eUuLJs/m
iWSe3JosCsSDEpsCpNzNzNoX04dDsH5kQ0aAxeoGFD8YUv9Uifv6nRvrMf24GYql
msn7KAJfgkcBJEFf+hTlqv52EwL5RcvmUzqvtdKdmGpUAu21uL9gKkuX3Sfc8QkX
Oy7jfeF6gD/M00boHSnN7zRddIzANP9rPVFdvb9UZneuR5G7mgtHnvrKh8Y3Wzzd
Kh2FQWPuDTPWTDpbpgTbpu2hoUUIka29JOmLl+pwfGcefMlowSBbofYUnWnyCQ+C
aJ1l/nFImbDso6FqR3xsIdw8B+XCaGI4tWntf1aMawxTaUTLWcC7XaAK7kYFjBLZ
gRxutpdrJPlUUe4s6pP9HD916rxiS675dEr5mpsEssSyEDI8ae/wVEAgdkP+zDmK
g7vXDIGN5PgWr0yFZH42MR2F4tG7yGA3TN3FRzyikj5hovIwXh4h3vTLkUXFFstr
Ss/oFXL1YX0WsSinazU5v41SUyfRmvNs/rjOnOnemHXTEaHgVkCj75QR0PUp8jyZ
EQWo+qfPjo6DYVWbQ70HPk1WFN+59bWVFmMwPSTgs1WChVGSJzlPUn1ZWIHpxe43
RPcGOHKnGqAZsoYt1+xhMbT4Jz385kv/HCd0esSchLDEDuvRp+CMBTBqSz/Y0d9E
lelZwB9miJkbvlo=
=4TzE
-END PGP SIGNATURE-

Bug#851444: ITP: python-xarray -- N-D labeled arrays and datasets in Python

[Ghislain Vaillant]

control: block -1 by 851520

Bug#851444: ITP: python-xarray -- N-D labeled arrays and datasets in Python

[Ghislain Vaillant]

control: block -1 by 851444

Bug#852295: RFS: freecell-solver/4.8.0-1 NMU

[Shlomi Fish]

Hi Gergely,

thanks for your message.

On Tue, 24 Jan 2017 17:45:25 +0100
Gergely Risko  wrote:

> Hey Guys,
> 
> Sorry, don't have the time to followup on the whole discussion again.
> 
> As many times I told Shlomi Fish, I'm happy to help with this package,
> but yes, I have a very busy life nowadays and if I miss things, I
> asked to be emailed privately either on ri...@debian.org or
> gerg...@risko.hu.
> 

ah, I didn't recall it. I'll try to keep it in mind from now on.

> If someone tells me what's the current state and if you just need a
> version update ASAP, then I can do this over the weekend.
> 

Thanks!

> Any other bugs to handle that makes this complicated?
> 

None that I am aware of.

-- Shlomi Fish

> Cheers,
> Gergely
> 
> On 2017-01-23 16:12 (Monday), Gianfranco Costamagna
>  writes:
> > Hello
> >  
> >>This makes me angry and disappointed. I reported  
> >  
> >>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841445 many months ago and
> >>posted "ping replies" and nothing was done to resolve it - either by the
> >>maintainer, who was missing-in-action and not for the first time - or by a
> >>different Debian contributor. And now you tell me that the new release of
> >>Debian will ship an old version of freecell-solver with some documented
> >>crashes and freezes and other bugs.  
> >
> > for sure you should have opened an NMU request months ago, posting your
> > willingness to upload and a deadline to the maintainer.
> >
> > However, the maintainer had already a MIA process, is inactive since 9
> > months, and upstream is asking us to update because of bugs/crashes.
> > Since we can't ignore upstream, I think in this case we should just upload
> > it.
> >
> > (the changes looks fine, but something needs adjustememnt)
> > 1) the library is public, and maybe the ABI changed but there are no
> > reverse-deps, so I don't care too much
> > 2) there is an useless "debhelper," dependency in control file
> >
> > 3) kaz_tree.c and +kaz_tree.h are not reflected in debian/copyright
> >
> > the packaging looks complicate, but we can't fix this in an NMU :)
> >
> > I'm going to open a MIA process right now
> >
> > Andrey, do you agree with me? you started the review, I don't want to steal
> > your package or break rules too much :)
> >
> > Gianfranco  

Bug#852617: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

[Zack Weinberg]

On Wed, Jan 25, 2017 at 1:02 PM, Thorsten Glaser  wrote:
> On Wed, 25 Jan 2017, Zack Weinberg wrote:
>
>> As far as I can tell from the Git history, AC_SYS_LARGEFILE has
>> *always* used AC_DEFINE_UNQUOTED to define the various preprocessor
>> macros that it can define (_FILE_OFFSET_BITS, _LARGE_FILES, and
>> _DARWIN_USE_64_BIT_INODE).
>
> Interesting, as I recall seeing -D_FILE_OFFSET_BITS=64 on various
> compiler command lines when working under GNU. (I normally work
> under BSD at home, so I don’t know where exactly.)

Is it possible that those programs were not using a config.h?

>> That part of the code has been unchanged
>> since AC_SYS_LARGEFILE was added to specific.m4.
>
> Interesting, when was that? (That is, before 2.13? Anything before
> that, even I consider ancient ☻)

2000-06-08.  According to NEWS, it was not in 2.13 (which was released
1999-05-01), but it was in the very next release, 2.50 (2001-05-21).
The ChangeLog entry for the addition says "Import AC_SYS_LARGEFILE
from largefile.m4 serial 12", so that sounds like there was an add-on
.m4 file with the same functionality floating around prior to that - I
don't know where to find copies of that file.

zw