Bug#803623: RFS: audiotools/3.1.1-1 upstream bugfix #803229 #803230

[Eric Shattow]

Package: sponsorship-requests
Severity: normal

#803229 audiotools: uninstallable, name conflict with cdtool package
#803230 audiotools: In a default install the interactive (-I) option doesn't
work

Resolved with upstream bugfix and new package:
dget -x
http://mentors.debian.net/debian/pool/main/a/audiotools/audiotools_3.1.1-1.dsc

Changes:
   * Upstream release renames executables to avoid conflict with cdtool
package. (Closes: #803229)
   * Add python3-urwid to Recommends. (Closes: #803230)



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

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

Bug#803626: RFS[ITP]: edge-addition-planarity-suite -- Suite of planarity-related graph algorithms

[Julien Puydt]

Package: sponsorship-requests
Severity: wishlist

Hi,

I'm looking for a sponsor for my package:

 * Package name: edge-addition-planarity-suite
   Version : 3.0.0.4-1
   Upstream Author : John M. Boyer
 * URL : 
https://github.com/graph-algorithms/edge-addition-planarity-suite

 * License : BSD-3-clause
   Section : math
   Description : Suite of planarity-related graph algorithms
 This library contains the reference implementation of the
 Edge Addition Planarity Algorithm, which is the best
 linear-time method to embed a planar graph and isolate
 planarity obstructions.

 It builds those binary packages:

libplanarity-dev - Library of planarity-related graph algorithms 
(devel files)

 libplanarity0 - Library of planarity-related graph algorithms
 planarity  - Program for planarity-related graph algorithms

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


  http://mentors.debian.net/package/edge-addition-planarity-suite

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

dget -x 
http://mentors.debian.net/debian/pool/main/e/edge-addition-planarity-suite/edge-addition-planarity-suite_3.0.0.4-1.dsc



It is one of the deps of sagemath.

I packaged it within the debian-science team, as:
Vcs-Git: git://anonscm.debian.org/debian-science/packages/planarity.git
Vcs-Browser: 
https://anonscm.debian.org/cgit/debian-science/packages/planarity.git


Thanks,

Snark on #debian-science

Bug#803625: grub-common: 10_linux doesn't merge rootflags= from GRUB_CMDLINE_LINUX*

[Christoph Anton Mitterer]

Package: grub-common
Version: 2.02~beta2-29
Severity: important


Hi.

That's basically a follor-up or at least related to #803624.

When the root-fs is on a btrfs subvolume (and perhaps in other cases
as well), 10_linux adds a rootflags= to the kernel parameters, not
merging any possibly already set such option in
GRUB_CMDLINE_LINUX_DEFAULT or GRUB_CMDLINE_LINUX.


Now coming back to my degraded-RAID-should-still-boot scenario from
#803624, even when I manually set GRUB_CMDLINE_LINUX=rootflags=degraded
things won't work (and the boot fails when a disk is e.g. missing).

It results in a grub.cfg line like:
  linux   /root/boot/vmlinuz-4.2.0-1-amd64 
root=UUID=d430d7ee-8059-11e5-9834-502690aa641f ro rootflags=subvol=root 
rootflags=degraded
and apparently the 2nd rootflags= is simply ignored.


When I manually change the line to:
  linux   /root/boot/vmlinuz-4.2.0-1-amd64 
root=UUID=d430d7ee-8059-11e5-9834-502690aa641f ro rootflags=subvol=root,degraded
everything works (even though I don't know what would happen if there was a 
subvolume named "root,degraded",
so perhaps one needs some quoting in that case?).


Any ideas?

Cheers,
Chris.

Bug#803589: FTBFS with ruby2.2 (only)

[James McCoy]

On Sat, Oct 31, 2015 at 04:45:54PM +0100, Christian Hofstaedtler wrote:
> During a test build your package FTBFS in a ruby2.2-only
> environment, as availble in experimental right now. We'd like to
> switch to ruby2.2 really soon now, please see the transition bug
> #789077 for details.
> 
> Unfortunately the build output didn't give me a hint on what's going
> wrong.

This is because ruby-test-unit (the now standalone package) has
completely different behavior than the test/unit.rb that's in ruby2.1.

The subversion build runs, essentially, “ruby -I /path/to/include/files
/path/to/test/run-test.rb”.

With ruby2.2 + ruby-test-unit, this doesn't find any tests to run and
silently exits with return code 1, causing the build to fail.  If I
explicitly add “--collector=dir”, then tests run but various tests fail.

With ruby2.1 (and ruby-test-unit not installed separately), tests are
discovered automatically and all pass fine.

It looks like ruby2.1's test/unit.rb is really just a compatibility
wrapper, exposing an old test-unit API but using minitest underneath.
I'm not sure how easy it will be to port the test suite to either newer
test-unit or minitest.

This change in behavior is a bit surprising though, especially the
silent failure.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#666751: IPv6 Subnet Support

[John Franklin]

If this is the same as https://github.com/schweikert/postgrey/issues/11, then 
it is fixed in the current 1.36 release.

jf
-- 
John Franklin
frank...@sentaidigital.com





smime.p7s
Description: S/MIME cryptographic signature

Bug#803624: grub-common: btrfs-root-fs rootflags-kernelparameter problems

[Christoph Anton Mitterer]

Package: grub-common
Version: 2.02~beta2-29
Severity: wishlist


Hi.

There are two things about the rootflags parametr that 10_linux generates
automatically when the root fs is btrfs.


1) (And I haven't looked at this in depth):
The subvol, if any, seems to be intentionally made relative.
But does this take into account, that the subvol paths are relative to
the top level subvol (i.e. ID=5) and not to the current default subvol?
Cause if not, the relative path would probably break as soon as one changes
the default subvol.




2) I wanted to make one of my servers, which runs on a RAID1 btrfs more
resilient against disk losses; i.e. it should boot even though one of the
two disks failed.

a) When I set "degraded" as mount option in /etc/fstab, than this doesn't
have any effect.
The initramfs doesn't store (and use it) and grub doesn't consider it (i.e.
add it it to rootflags=) either in the generated grub.cfg.

But admittedly, I'm not really sure whether it should.


So perhaps a proper solution would be, if 10_linux takes up such mount-options
from /etc/fstab and appends them to rootflags=
Maybe even generally (and not just "degraded") as not all filesystems may
provide something like ext* where one can store the default mountoptions in the
fs superblock.
But then there should be an option (guess in /etc/default/grub) which disables
that auto-pickup for those people who may want to do more special things.


Cheers,
Chris.

Bug#803618: mysql-workbench, FTBFS on architectures where char is unsigned.

[Dmitry Smirnov]

On Saturday 31 October 2015 23:22:13 peter green wrote:
> To fix this I changed data type to signed char
> 
> I have successfully built the package with this change in a raspbian
> stretch-staging environment and uploaded to raspbian. I have not tested
> it beyond that. A debdiff can be found

Many thanks for this patch, Peter. Much appreciated.

-- 
Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

---

Odious ideas are not entitled to hide from criticism behind the human
shield of their believers' feelings.
-- Richard Stallman


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

Bug#799963: I can't access https://freqdbo.ncc.gov.tw/

[積丹尼 Dan Jacobson]

I can't access https://freqdbo.ncc.gov.tw/ due to this bug. OK I will
try a different browser.

Bug#636272: Tentative date for upload of libre

[Vasudev Kamath]

Simon Josefsson  writes:

> Libre has been in the new queue for 4 days. Thanks for taking care of
> those packages, they were next on my todo-list.

Great! thanks. And sorry for not looking at new queue.

Cheers,


signature.asc
Description: PGP signature

Bug#803539: dbconfig-common: [INTL:ru] Russian debconf templates translation update

[Yuri Kozlov]

Package: dbconfig-common
Version: 1.8.55
Severity: wishlist
Tags: l10n patch

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 ***

Russian debconf templates translation update is attached.

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

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


ru.po.gz
Description: application/gzip

Bug#803540: idGenerator fails on "{%sn[1-4]}{%givenName[12]}" if givenName is shorter than 12 chars

[Mike Gabriel]

Package: gosa
Severity: normal
Version: 2.7.4+reloaded2-5
User: debian-...@lists.debian.org
Usertags: debian-edu
X-Debbugs-Cc: debian-...@lists.debian.org

Hi all,

I have just discovered another issue with the idGenerator code in  
GOsa² (which might be a regression introduced by recent changes).


If the idGenerator is {%sn[1-4]}{%givenName[12]}, I'd expect this for  
a given fullname "Test User":


  tuser
  teuser
  tesuser
  testuser

But I get:

  t{%givenName[12]}
  te{%givenName[12]}
  tes{%givenName[12]}
  test{%givenName[12]}

I will take a look into this soon...

Mike
--

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

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

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


pgp6D9rNlj27e.pgp
Description: Digitale PGP-Signatur

Bug#704166:

[burak_ad_188]

Android için Outlook tarafından gönderildi

Bug#791187: libzeep: library transition may be needed when GCC 5 is the default

[Andreas Tille]

Hi,

Jonathan Wiltshire has reopened this bug without any explanation and I
think applying Julien's patch was to Simons and my opinion wrong since
my last upload IMHO did the transition.  As long as I do not get any
explanation why the bug is reopened I have no idea what to do since to
my opinion the transition is finished.

Kind regards

   Andreas.

On Fri, Oct 30, 2015 at 04:17:25PM +0100, Emilio Pozuelo Monfort wrote:
> This is a friendly ping wrt the libstdc++ ABI transition. Your package is 
> listed
> as needing a transition but has seen no action. It'd be good to get things 
> going
> so we can finish the transition soon.

-- 
http://fam-tille.de

Bug#803543: ITP: r-cran-praise -- GNU R praise users

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-praise
  Version : 1.0.0
  Upstream Author : Gabor Csardi 
* URL :  http://cran.r-project.org/web/packages/praise/
* License : MIT
  Programming Lang: R
  Description : GNU R praise users
 Build friendly R packages that praise their users if they have done
 something good, or they just need it to feel better.


Remark: The only reason to create this package is that it is a
Build-Dependency to upgrade r-cran-testthat.  It will be maintained
by the Debian Med team at
   svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-praise/

Bug#803482: ncurses: please make the build reproducible, take two

[Esa Peuha]

On Fri, Oct 30, 2015 at 10:44 PM, Sven Joachim  wrote:
> Certainly aclocal.m4 is _not_ a generated file in ncurses,

Not in the Debian package, but upstream must be generating it from
configure.in by running aclocal.

> Possible
> solutions are to run dh_strip_nondeterminism on the -dbg packages, or to
> just remove the static debug libraries (I don't think they actually
> work anyway, see #556378 for reasons).

I don't know if the static debug libraries work or not (wouldn't the
latter mean that #556378 isn't really fixed?), but I think
dh_strip_nondeterminism is probably the best option here.

Bug#802248: awesome: FTBFS: ldoc: Error: no suitable Lua interpreter found

[Uli Schlachter]

reassign 802248 lua-ldoc 1.4.3-4
retitle 802248 lua-ldoc does not work with lua5.1
tag 802248 patch
thanks

Hi,

lua-ldoc clearly uses lua-any, but claims to only work with lua5.2:

$ grep Lua-Versions /usr/bin/ldoc
-- Lua-Versions: 5.2

After uninstalling lua5.2 I thus get:

$ ldoc
Error: no suitable Lua interpreter found
Error: supported versions are: 5.2

A sudoedit later I get:

$ grep Lua-Versions /usr/bin/ldoc
-- Lua-Versions: 5.1 5.2
$ ldoc
ldoc: missing required parameter: file
[...]

So I'll (try to...) reassign this bug to lua-ldoc. Also, it should be obvious
how to fix this. :-)

Cheers,
Uli
-- 
"In the beginning the Universe was created. This has made a lot of
 people very angry and has been widely regarded as a bad move."

Bug#803554: FTBFS: xorg-wrapper.o: error adding symbols: Bad value

[Lorenzo]

Package: xserver-xorg-core
Version: 2:1.17.2-3
Severity: normal

Dear Maintainer,

I'm trying to build a deb package for xserver-xorg-core using the source 
provided by Debian, but the building process fails with the following error


ic -o Xorg.wrap xorg-wrapper.o  -laudit -lm
/usr/bin/ld: xorg-wrapper.o: relocation R_X86_64_32 against `.rodata.str1.1' 
can not be used when making a shared object; recompile with -fPIC
xorg-wrapper.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:799: recipe for target 'Xorg.wrap' failed
make[5]: *** [Xorg.wrap] Error 1
make[5]: Leaving directory 
'/home/ombra/src-nsd/xorg-server-1.17.3/build-main/hw/xfree86'
Makefile:845: recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory 
'/home/ombra/src-nsd/xorg-server-1.17.3/build-main/hw/xfree86'
Makefile:660: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory 
'/home/ombra/src-nsd/xorg-server-1.17.3/build-main/hw/xfree86'
Makefile:604: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory 
'/home/ombra/src-nsd/xorg-server-1.17.3/build-main/hw'
Makefile:771: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/ombra/src-nsd/xorg-server-1.17.3/build-main'
debian/rules:249: recipe for target 'stampdir/build-main' failed
make: *** [stampdir/build-main] Error 2
rm stampdir/configure-main
dpkg-buildpackage: error: debian/rules build gave error exit status 2

I have also tried with the source from experimental, same error.

thanks

Lorenzo



-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Oct  3  2012 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Oct  6 09:35 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Park [Mobility Radeon HD 5430] [1002:68e1]

Xorg X server configuration file status:

-rw-r--r-- 1 root root 2548 May 11  2014 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# /etc/X11/xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
# (Type "man /etc/X11/xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "Device"
Identifier  "radeon2400pro"
Driver  "radeon"#"radeon"  #vesa radeonhd 
BusID   "PCI:1:0:0"
VideoRam262144
#Option  "XAANoOffscreenPixmaps" "true"
Option  "RenderAccel" "true"   #non in knopp#
#Option  "AllowGLXWithComposite" "true"#knopp#
#Option  "EnablePageFlip" "true"#knopp#
#Option  "XaaNoScanlineImageWriteRect" "true"#knopp#
#Option  "XaaNoScanlineCPUToScreenColorExpandFill" "true"  #knopp#
#Option  "TripleBuffer" "true"   #paolinoland.it#
##Option  "DRI"   "true"
##Option  "AccelMethod""EXA"   #"XAA"  vecchio
#Option  "AddARGBGLXVisuals" "true" 
#Option  "DisableGLXRootClipping" "true"
#Option  "OnDemandVBlankInterrupts"  "True"
#Option  "PixmapCacheSize""10"
#Option  "AllowSHMPixmaps"  "0"
##Option  "AccelDFS"  "1"   #1/0 On for PCIE, off for AGP
#Option  "GARTSize"  "64"
Option  "EnablePageFlip" "1"  # 1/0 Increases 3D performance 
substantiall
Option  "ColorTiling" "1"   # 1/0 Increases 3D performance 
substantially

EndSection

#Section  "Screen"
#   Identifier "Default Screen"
#   Device "HD2400pro"
#   Monitor"Samsung910N"
#   DefaultDepth24
#EndSection

#Section "ServerLayout"
#Option  "AIGLX""true" # "Off"   "true"
#   Identifier  "Default Layout"
#   Screen  "Default Screen"
#   InputDevice "Generic Keyboard"
#   InputDevice "Configured Mouse"
#EndSection

Section "DRI"
Group "video"
Mode   0660
#   Mode0666 #vecchio setting
EndSection

Section "Extensions"
Option  "Composite""Enable" #"Off" "true" o "Enable" true 
in paolinoland#
EndSEction

/etc/X11/xorg.conf.d 

Bug#803555: pygame: FTBFS in experimental

[Andreas Beckmann]

Source: pygame
Version: 1.9.2~pre~r3348-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

pygame/exerimental FTBFS in a current sid+experimental environment:

[...]
 debian/rules build
dh build --with python2,python3
   dh_testdir
   dh_auto_configure
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu 
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode 
--disable-dependency-tracking
Using UNIX configuration...


Hunting dependencies...
SDL : found 1.2.15
FONT: found
IMAGE   : found
MIXER   : found
SMPEG   : found 0.4.5
PNG : found
JPEG: found
SCRAP   : found
PORTMIDI: found
PORTTIME: found
AVFORMAT: not found
SWSCALE : not found
FREETYPE: found 2.6.0


Warning, some of the pygame dependencies were not found. Pygame can still
compile and install, but games that depend on those missing dependencies
will not run. Would you like to continue the configuration? [Y/n]:Traceback 
(most recent call last):
  File "config.py", line 169, in 
if __name__ == '__main__': main()
  File "config.py", line 157, in main
deps = CFG.main()
  File "/tmp/buildd/pygame-1.9.2~pre~r3348/config_unix.py", line 232, in main
will not run. Would you like to continue the configuration?"""):
  File "/tmp/buildd/pygame-1.9.2~pre~r3348/config_unix.py", line 30, in confirm
reply = raw_input('\n' + message + ' [Y/n]:')
EOFError: EOF when reading a line
dh_auto_configure: ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=${prefix}/include --mandir=${prefix}/share/man 
--infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu 
--libexecdir=${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode 
--disable-dependency-tracking returned exit code 1
debian/rules:19: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


Andreas

Bug#803560: ppp: Enhanced arbitrary interface names (ifname)

[Adrian Ban]

Package: ppp
Version: 2.4.6-3.2
Severity: wishlist
Tags: patch

   * Tried to rename interfaces for each technology I'm using
   * Doing some different iptables setups based on the prefix of the 
interface


Based on the original Debian patch which is using ifname parameter to 
rename the interface
of the outgoing interfaces I've create 2 patches to solve the issue of 
the incomming connections

of different technologies I'm using on my routers: pptp, pppoe or l2tp.
I want to do differences between those thenologies and rename the 
interfaces in format like:

pptp0, pptp1, pppoes2, pppoes3, l2tp4.
I've changed the original patch and I've added a detection of the ifname 
format. If you put
"ifname pppoesN" the patch will detect the character 'N' and will rename 
the interfaces using

the prefix "pppoes" and add the unit of the ppp interface.
Then using a regex in radius plugin split the prefix part of the 
interface name (previously was
using a sscanf function) and extract the unit id and create correct 
NAS-port-id.


First I've tried to use ip-pre-up/ip-up scripts but I discover that 
radius plugin couldn't detect the interface
and also some parts of the ppp couldn't get the correct interface name. 
So I've decided to rename the interface

directly in ppp core.

Hope this patch will be useful for many administrators.

Here are the patches:
https://github.com/AdrianBan/ppp-debian/blob/master/debian/patches/ppp-2.4.6-radius-plugin-ifname-fix.patch
https://github.com/AdrianBan/ppp-debian/blob/master/debian/patches/ppp-2.4.2-ifname-enhanced.patch

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

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

Versions of packages ppp depends on:
ii  init-system-helpers  1.24
ii  libc62.19-22
ii  libpam-modules   1.1.8-3.1
ii  libpam-runtime   1.1.8-3.1
ii  libpam0g 1.1.8-3.1
ii  libpcap0.8   1.7.4-1
ii  procps   2:3.3.10-4

ppp recommends no packages.

ppp suggests no packages.

-- no debconf information
adrian@RouterFW:/opt/devel/ppp/ppp-2.4.6/debian/patches$ exit
exit
root@RouterFW:/opt/devel/ppp/ppp-2.4.6/debian/patches# cp 
/tmp/reportbug-ppp-20151031-22781-KhGO3b .

root@RouterFW:/opt/devel/ppp/ppp-2.4.6/debian/patches#
root@RouterFW:/opt/devel/ppp/ifname-enhanced# cat 
reportbug-ppp-20151031-22781-KhGO3b

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Adrian Ban <adr...@abtelecom.ro>
To: Debian Bug Tracking System <sub...@bugs.debian.org>
Subject: ppp: Enhanced arbitrary interface names (ifname)
Message-ID: 
<144629429023.22781.3037784529480381644.report...@routerfw.abtelecom.ro>

X-Mailer: reportbug 6.6.5
Date: Sat, 31 Oct 2015 14:24:50 +0200

Package: ppp
Version: 2.4.6-3.2
Severity: wishlist
Tags: patch

   * Tried to rename interfaces for each technology I'm using
   * Doing some different iptables setups based on the prefix of the 
interface


Based on the original Debian patch which is using ifname parameter to 
rename the interface
of the outgoing interfaces I've create 2 patches to solve the issue of 
the incomming connections

of different technologies I'm using on my routers: pptp, pppoe or l2tp.
I want to do differences between those thenologies and rename the 
interfaces in format like:

pptp0, pptp1, pppoes2, pppoes3, l2tp4.
I've changed the original patch and I've added a detection of the ifname 
format. If you put
"ifname pppoesN" the patch will detect the character 'N' and will rename 
the interfaces using

the prefix "pppoes" and add the unit of the ppp interface.
Then using a regex in radius plugin split the prefix part of the 
interface name (previously was
using a sscanf function) and extract the unit id and create correct 
NAS-port-id.


First I've tried to use ip-pre-up/ip-up scripts but I discover that 
radius plugin couldn't detect the interface
and also some parts of the ppp couldn't get the correct interface name. 
So I've decided to rename the interface

directly in ppp core.

Hope this patch will be useful for many administrators.

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

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

Versions of packages ppp depends on:
ii  init-system-helpers  1.24
ii  libc62.19-22
ii  libpam-modules   1.1.8-3.1
ii  libpam-runtime   1.1.8-3.1
ii  libpam0g 1.1.8-3.1
ii  libpcap0.8   1.7.4-1
i

Bug#755762: gdm3: obsolete-conffile found by adequate while upgrading to 3.12.2-2

[Paul Wise]

Package: gdm3
Version: 3.18.0-2
Followup-For: Bug #755762

I am seeing two more obsolete conffiles with the upgrade to 3.18.0-2:

$ pkg=gdm3 ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | grep 
obsolete
gdm3: obsolete-conffile /etc/dconf/db/gdm
gdm3: obsolete-conffile /etc/dconf/profile/gdm
 /etc/dconf/db/gdm 86de6bc0b37d8cd4e70b909f225e1247 obsolete
 /etc/dconf/profile/gdm f2bce15244e92ac57be682b149e2 obsolete

-- System Information:
Debian Release: stretch/sid
  APT prefers buildd-experimental
  APT policy: (1450, 'buildd-experimental'), (1400, 'experimental'), (1350, 
'buildd-unstable'), (1300, 'unstable'), (1250, 
'buildd-testing-proposed-updates'), (1230, 'testing-proposed-updates'), (1200, 
'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: armel, i386

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

Versions of packages gdm3 depends on:
ii  accountsservice  0.6.40-3
ii  adduser  3.113+nmu3
ii  aewm++ [x-window-manager]1.1.2-5
ii  amiwm [x-window-manager] 0.20.48-8
ii  awesome [x-window-manager]   3.5.6-1
ii  blackbox [x-window-manager]  0.70.1-28
ii  cinnamon [x-window-manager]  2.6.13-1
ii  cwm [x-window-manager]   5.6-4
ii  dconf-cli0.24.0-2
ii  dconf-gsettings-backend  0.24.0-2
ii  debconf [debconf-2.0]1.5.57
ii  dwm [x-window-manager]   6.0-8
ii  e17 [x-window-manager]   0.17.6-1
ii  evilwm [x-window-manager]1.1.1-1
ii  fluxbox [x-window-manager]   1.3.7-1~exp1
ii  flwm [x-window-manager]  1.02+git2015.04.29-1
ii  fvwm [x-window-manager]  1:2.6.5.ds-4
ii  fvwm-crystal [x-window-manager]  3.3.1+dfsg-1
ii  fvwm1 [x-window-manager] 1.24r-56
ii  gir1.2-gdm3  3.18.0-2
ii  gnome-session [x-session-manager]3.14.0-3
ii  gnome-session-bin3.14.0-3
ii  gnome-session-flashback [x-session-mana  3.14.0-4
ii  gnome-settings-daemon3.14.2-3
ii  gnome-shell  3.14.4-1
ii  gnome-terminal [x-terminal-emulator] 3.18.1-1
ii  gsettings-desktop-schemas3.18.1-1
ii  herbstluftwm [x-window-manager]  0.6.2-1
ii  i3-wm [x-window-manager] 4.11-1
ii  icewm [x-window-manager] 1.3.8+githubmod+20150914+fa3fdef-2
ii  icewm-experimental [x-window-manager]1.3.8+githubmod+20150914+fa3fdef-2
ii  icewm-lite [x-window-manager]1.3.8+githubmod+20150914+fa3fdef-2
ii  jwm [x-window-manager]   2.1.0+svn579-2
ii  kde-window-manager [x-window-manager]4:4.11.13-2
ii  konsole [x-terminal-emulator]4:4.14.2-1
ii  larswm [x-window-manager]7.5.3-6
ii  libaccountsservice0  0.6.40-3
ii  libaudit11:2.4.4-4
ii  libc62.21-0experimental2
ii  libcanberra-gtk3-0   0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libgdk-pixbuf2.0-0   2.32.1-1
ii  libgdm1  3.18.0-2
ii  libglib2.0-0 2.46.1-1
ii  libglib2.0-bin   2.46.1-1
ii  libgtk-3-0   3.18.2-1
ii  libpam-modules   1.1.8-3.1
ii  libpam-runtime   1.1.8-3.1
ii  libpam-systemd   227-2
ii  libpam0g 1.1.8-3.1
ii  librsvg2-common  2.40.11-1
ii  libselinux1  2.4-2
ii  libsystemd0  227-2
ii  libwrap0 7.6.q-25
ii  libx11-6 2:1.6.3-1
ii  libxau6  1:1.0.8-1
ii  libxdmcp61:1.1.2-1
ii  lsb-base 9.20150917
ii  lwm [x-window-manager]   1.2.2-5
ii  lxde-common [x-session-manager]  0.99.0-2
ii  lxsession [x-session-manager]0.5.1-2
ii  lxterminal [x-terminal-emulator] 0.2.0-1
ii  marco [x-window-manager] 1.8.3+dfsg1-3
ii  matchbox-window-manager [x-window-manag  1.2-osso21-1+b1
ii  mate-session-manager [x-session-manager  1.8.2-2
ii  mate-terminal [x-terminal-emulator]  1.10.1+gfdl1-2
ii  metacity [x-window-manager]  1:3.14.3-1
ii  miwm [x-window-manager]  1.1-3
ii  muffin [x-window-manager]2.6.1-3
ii  mutter [x-window-manager]3.14.4-2
ii  mwm [x-window-manager]   2.3.4-8
ii  notion 

Bug#794245: [Pkg-fonts-devel] Font build can't be done without new fontforge.

[Philippe Cochy]

Le samedi 31 octobre 2015 à 11:20 +0530, Vasudev Kamath a écrit :
> Philippe Cochy  writes:
> 
> > I apologize but I do not see the problem to generate this font with
> > the classic fontforge.  The new fontforge version brings many
> > regressions. I would hate an irresponsible forcing to early put
> > forward.
> 
> Did you try to build the font with fontforge?. If you are just assuming
> then please see below error. And also see upstream bug which I reported
> where a person confirm he is able to build with fontforge compiled from
> *source* (not one from Debian)
> 
> Here is what I see when I try to build the font in clean chroot
> environment.
> 
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building fonts-monoid using existing 
> ./fonts-monoid_0.60.orig.tar.gz
> dpkg-source: warning: ignoring deletion of file 
> Monoisome/Monoisome-Regular.ttf, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file 
> Utilities/WIP'n'test/MonoidTest-Retina.ttf, use --include-removal to override
> dpkg-source: info: building fonts-monoid in fonts-monoid_0.60-1.debian.tar.xz
> dpkg-source: info: building fonts-monoid in fonts-monoid_0.60-1.dsc
>  debian/rules build
> test -x debian/rules
> mkdir -p "."
> 
> WARNING: copyright-check disabled - touch debian/copyright_hints to enable.
> 
> touch debian/stamp-copyright-check
> touch debian/stamp-upstream-cruft
> /usr/bin/make  -C . CFLAGS="-g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -Wall" CXXFLAGS="-g -O2 -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall" CPPFLAGS="-D_FORTIFY_SOURCE=2" 
> LDFLAGS="-Wl,-z,relro"  all
> make[1]: Entering directory '/build/fonts-monoid-0.60'
> Scripts/build.py 1 0 Monoisome/Monoisome.sfdir
> Failed to find NameList: AGL For New Fonts
> Makefile:6: recipe for target 'all' failed
> make[1]: *** [all] Segmentation fault (core dumped)
> make[1]: Leaving directory '/build/fonts-monoid-0.60'
> /usr/share/cdbs/1/class/makefile.mk:47: recipe for target 
> 'debian/stamp-makefile-build' failed
> make: *** [debian/stamp-makefile-build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> E: Failed autobuilding of package
> W: no hooks of type C found -- ignoring
> I: unmounting dev/pts filesystem
> I: unmounting run/shm filesystem
> I: unmounting proc filesystem
>  -> Cleaning COW directory
>   forking: rm -rf /var/cache/pbuilder/build-sid/cow.30876 
> 
> I see error and a segmentation fault. Current version of fontforge in
> Debian is 20120731.b-5+b3

Sure! The sfdir (font.props) format was changed in the new fontforge.
I do not think the solution is in a headlong rush but to save the font
using the classic fontforge. Classic and new fontforge are for now
incompatible.
(It would be interesting to try with .sfd) 
What remained stable this is the ttf format that can be use with
both ;-)



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

Bug#784688: Thousands of "xen:balloon: Cannot add additional memory (-17) messages" despite dom0 ballooning disabled

[Andre']

Hello,

I'm seeing the same.

After a fresh boot before starting any guests xl shows:
root@tank0:~# xl list 0
NameID   Mem VCPUs  State   Time(s)
Domain-0 0  4096 8 r-   8.4

I did run "xl mem-set 0 4096" then started an guest.
This produced a load of the "xen:balloon: Cannot add additional memory (-17)"
messages.

xl now shows:
root@tank0:~# xl list 0
NameID   Mem VCPUs  State   Time(s)
Domain-0 0  4094 8 r-  24.4

Runnig "xl mem-set 0 4094" after the guest had started seems to have
stopped the messages for the moment.
(not running mem-set at this point continued to produce the messages in
some frequent irregular intervalls)

Xen options are "dom0_mem=4096M,max:4096M" .
Dom0 linux kernel options are "mem=4096" .
xl.conf got autoballoon="off" .

Have a nice day,
 Andre

Bug#801925: NULL pointer dereference: IP: [] sr_runtime_suspend+0xc/0x20 [sr_mod]

[Paul Menzel]

Control: notfound -1 3.19-1~exp1
Control: found -1 4.2.5-1


Am Dienstag, den 20.10.2015, 02:39 +0100 schrieb Ben Hutchings:
> On Fri, 2015-10-16 at 09:54 +0200, Paul Menzel wrote:
> [...]
> > > BUG: unable to handle kernel NULL pointer dereference at 0014
> > > IP: [] sr_runtime_suspend+0xc/0x20 [sr_mod]
> > > *pdpt = 3696e001 *pde = 00
> > > Oops:  [#1] SMB
> > > Modules linked in: sd_mod(+) sr_mod(+) cdrom ata_generic ohci_pci ahci 
> > > libahci pata_amd firwire_ohci firewire_core crc_iti_t forcedeth libata 
> > > scsi_mod ohci_hcd ehci_pci ehci_hcd usbcore usb_common fan thermal 
> > > thermal_sys floppy(+)
> > > CPU: 1 PID: 73 Comm: systemd-udevd Not tainted 4.2.0-1-686-pae #1 Debian 
> > > 4.2.3-1
> > > Hardware name: Packard Bell imedia S3210/WMCP78M, BIOs P01-B2 11/06/2009
> > > task: f68dd040 ti: f6988000 task.ti: f6988000
> > > EIP: 0060:[] EFLAGS: 00010246 CPU: 1
> > > EIP is at sr_runtime_suspend+0xc/0x20 [sr_mod]
> > > EAX:  EBX: f6a30cd8 ECX: f6c03d2c EDX: 
> > > ESI:  EDI: f828e100 EBP: f6989ba8 ESP: f6989b88
> > >  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> > > CR0: 8005003b CR2: 0014 CR3: 3696d780 CR4: 06f0
> > > Stack:
> > >  af83346c3  0001 fff5 f6a7d150 f6a30cd8 f6a30d3c 
> > >  f6989bbc c1390cb7 f6a30cd8 f8334660  f6989bd0 c1390d0f f6a30cd8
> > >  f8334660  f6989c0c c13916cb f694a614 f68dd040  0008
> > > Call Trace:
> > >  […] ? scsi_runtime_suspend+0x63/0xa0 [scsi_mod]
> > >  […] ? __rpm_callback+0x27/0x60
> > > […]
> [...]
> > Ben Hutchings asked me to test the patch below to get more debug
> > information.
> [...]
> 
> Well, that didn't help much.  Paul hit another oops, this time in
> sd_mod but again apparently related to runtime PM.  My patch only
> touched sr_mod.
> 
> This time he sent photos of the complete oops; see
> 
> and
> 

after backing up my data, I tested a little bit more, and using Linux
3.19 the drive is detected and the system boots.

Does anything stand out what changed in this area between Linux 3.19 and
4.1?


Thanks

Paul
-- 
go~mus | Besuchermanagement

▶ 18. – 20. November 2015 // Messe Köln – Stand D054

Besuchen Sie uns auf der EXPONATEC und lernen Sie die Software für
Besuchermanagement kennen, die von führenden Museumsverbänden in Europa
eingesetzt wird.

Mehr Infos über go~mus finden Sie unter https://www.gomus.de

~

GPG-Schlüssel: 33623E9B
Fingerabdruck = 0EB1 649D 4361 D04F 3C70  6F71 4DD7 BF75 3362 3E9B

Giant Monkey Software Engineering GmbH

Brunnenstr. 7D
10119 Berlin Mitte

Geschäftsführer Adrian Fuhrmann, Lion Vollnhals und Paul Menzel

USt-IdNr.: DE281524720
HRB 139495 B Amtsgericht Charlottenburg


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

Bug#803546: allegro4.4: please make the build reproducible

[Reiner Herrmann]

Source: allegro4.4
Version: 2:4.4.2-6
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that allegro4.4 could not be built reproducibly.
The permissions inside a tarball vary because of different umasks.

The attached patch tells tar to normalize the permissions.

Regards,
 Reiner

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

diff --git a/debian/rules b/debian/rules
index 1635ff2..a9ba95b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -58,7 +58,7 @@ override_dh_auto_install:
 # Create examples source tar.gz
 	rm -rf build/tmp; mkdir build/tmp
 	cp examples/*.c examples/*.h examples/*.dat examples/*.pcx examples/*.txt examples/*.ini tests/*.c build/tmp/
-	cd build/tmp; GZIP="-9n" tar zcvf source.tar.gz --mtime="$(BUILD_DATE)" *
+	cd build/tmp; GZIP="-9n" tar zcvf source.tar.gz --mtime="$(BUILD_DATE)" --mode=go=rX,u+rw,a-s *
 	cp build/tmp/source.tar.gz $(CURDIR)/debian/tmp/$(DOC_EXAMPLES_DIR)
 
 override_dh_makeshlibs:


signature.asc
Description: OpenPGP digital signature

Bug#803547: bbswitch: please make the build reproducible

[Reiner Herrmann]

Source: bbswitch
Version: 0.8-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that bbswitch could not be built reproducibly.
The permissions inside a tarball vary because of different umasks.

The attached patch tells tar to normalize the permissions.

Regards,
 Reiner

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

diff --git a/debian/rules b/debian/rules
index 7444be3..2776380 100755
--- a/debian/rules
+++ b/debian/rules
@@ -36,7 +36,7 @@ override_dh_auto_install:
 	done
 	find 'debian/$(name)-source/usr/src/modules' -depth -newermt '$(BUILD_DATE)' -print0 | \
 		xargs -0r touch --no-dereference --date='$(BUILD_DATE)'
-	cd debian/$(name)-source/usr/src && tar cfj $(name).tar.bz2 modules && rm -rf modules
+	cd debian/$(name)-source/usr/src && tar cfj $(name).tar.bz2 --mode=go=rX,u+rw,a-s modules && rm -rf modules
 
 override_dh_installchangelogs:
 	dh_installchangelogs NEWS


signature.asc
Description: OpenPGP digital signature

Bug#803504: dovecot pam authentication broken

[Nis Martensen]

Some more data points:

- Further simplification of the dovecot config (ssl = no) does not make
a difference.

- The problem is not reproducible on a different machine, using the
exact same content of /etc/dovecot.conf and /etc/pam.d/dovecot.

- On the machine where the problem persists, this pam config does not work:

--- /etc/pam.d/dovecot (non-working) ---
#%PAM-1.0

auth required pam_unix.so
account  required pam_unix.so
session  required pam_unix.so
password required pam_unix.so

--- EOF ---

whereas the problem goes away with this one:

--- /etc/pam.d/dovecot (working) ---
#%PAM-1.0

auth required pam_unix.so
account  required pam_unix.so
session  required pam_unix.so
password optional pam_warn.so
password required pam_unix.so

--- EOF ---

It does not matter to which type (auth/account/etc.) the pam_warn.so
line is added, using any of the four works.

So this might be a PAM problem, not necessarily a dovecot problem.
Open questions:

 - What difference between my test machines could potentially cause the
difference in behavior?

 - Why does the inclusion of pam_warn.so make a difference?

Appending "audit" to the pam_unix.so lines reveals that the username
passed to PAM is correct. However, PAM still logs "user unknown".

Bug#791965: ITP: openzwave -- API to use a Z-Wave controller

[Thorsten Alteholz]

Hi Lucas,

On Sat, 31 Oct 2015, Lucas Nussbaum wrote:

Have you made progress on this?


I uploaded the package and got a reject from paultag. In his eyes a 
license was non-free. I don't agree with him, but I didn't start a 
discussion as I also got information from the ZWave alliance. One argument 
to sell ZWave products is their certification and such everything works 
together with everything else. As openzwave does not really comply with 
their specification and even does not support every part of ZWave (e.g. 
the security stuff seems to be missing), the Alliance would be very 
critical of openzwave. If there will be complaints of users, I guess they 
will enforce their trademark.


So basically I stopped working on the package.

  Thorsten

Bug#803558: clang-tidy: fails to upgrade from 'testing' - trying to overwrite /usr/bin/clang-tidy

[Andreas Beckmann]

Package: clang-tidy
Version: 1:3.6-31
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

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

  Selecting previously unselected package clang-tidy-3.6.
  Preparing to unpack .../clang-tidy-3.6_1%3a3.6.2-3_amd64.deb ...
  Unpacking clang-tidy-3.6 (1:3.6.2-3) ...
  Selecting previously unselected package clang-tidy.
  Preparing to unpack .../clang-tidy_1%3a3.6-31_amd64.deb ...
  Unpacking clang-tidy (1:3.6-31) ...
  dpkg: error processing archive 
/var/cache/apt/archives/clang-tidy_1%3a3.6-31_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/clang-tidy', which is also in package clang 
1:3.5-26
  Errors were encountered while processing:
   /var/cache/apt/archives/clang-tidy_1%3a3.6-31_amd64.deb


cheers,

Andreas


clang=1%3.5-26_clang-tidy=1%3.6-31.log.gz
Description: application/gzip

Bug#803556: freedombox-setup: Avoid dpkg conffile prompts

[James Valleroy]

Package: freedombox-setup
Severity: wishlist
Tags: patch

Currently, Plinth will modify some conffiles like /etc/tor/torrc. This
prevents a few packages, like tor, from being upgraded by
unattended-upgrades.

The attached patch will set 2 dpkg options, --force-confdef and --force-
confold. With these options set, dpkg will upgrade configuration files
when it
could do so without a prompt. If a prompt would be required, then dpkg will
keep the current configuration file. So this will allow packages like
tor to be
upgraded, without attempting to upgrade the modified conffile.

Note that this is not a solution for configuration upgrades, but a
workaround
that will allow packages to be upgraded while we are still working on
solving
the configuration upgrade problem.

I have done only basic testing of building/running an image with this
change applied.

--
James
From d4331fd43afd4b3c771be2df80e7cd3182c29558 Mon Sep 17 00:00:00 2001
From: James Valleroy 
Date: Sat, 31 Oct 2015 07:59:41 -0400
Subject: [PATCH] Configure dpkg to avoid conffile prompt. If a prompt would be
 required, keep the current configuration file.

---
 data/etc/apt/apt.conf.d/99freedombox | 4 
 debian/freedombox-setup.install  | 1 +
 2 files changed, 5 insertions(+)
 create mode 100644 data/etc/apt/apt.conf.d/99freedombox

diff --git a/data/etc/apt/apt.conf.d/99freedombox b/data/etc/apt/apt.conf.d/99freedombox
new file mode 100644
index 000..e160f1e
--- /dev/null
+++ b/data/etc/apt/apt.conf.d/99freedombox
@@ -0,0 +1,4 @@
+Dpkg::Options {
+"--force-confdef";
+"--force-confold";
+}
diff --git a/debian/freedombox-setup.install b/debian/freedombox-setup.install
index f62c49d..4616cec 100644
--- a/debian/freedombox-setup.install
+++ b/debian/freedombox-setup.install
@@ -3,6 +3,7 @@ setup.d usr/lib/freedombox
 first-run.d usr/lib/freedombox
 lib/machine-detect usr/lib/freedombox
 data/etc/apache2/conf-available/freedombox.conf etc/apache2/conf-available
+data/etc/apt/apt.conf.d/99freedombox etc/apt/apt.conf.d
 data/etc/avahi/services/*.service etc/avahi/services
 data/etc/sudoers.d/freedombox etc/sudoers.d
 data/etc/sysctl.d/freedombox.conf etc/sysctl.d
-- 
2.6.2



signature.asc
Description: OpenPGP digital signature

Bug#803557: [fglrx-driver] fglrx installation should blacklist amdgpu kernel module

[José Antonio Insua]

Package: fglrx-driver
Version: 1:15.9-2
Severity: critical

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

Hello, 

after the latest kernel update in sid, the free "amdgpu" driver is available 
as a module and it gets automatically loaded at boot, conflicting with fglrx.

This module should probably be blacklisted like the "radeon" module by 
default.

I was hit by this issue and everything was solved by adding a file with 
"blacklist amdgpu" under /etc/modprobe.d/

Regards

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

Debian Release: stretch/sid
  500 unstableftp.de.debian.org 
  500 unstabledownload.jitsi.org 
  500 unstabledeb-multimedia.org 
  500 testing ftp.de.debian.org 
  500 stable  dl.google.com 

--- Package information. ---
Depends   (Version) | Installed
===-+-==
libfglrx  (= 1:14.6~betav1.0-1) | 
xorg-video-abi-15   | 
 OR xorg-video-abi-14   | 
 OR xorg-video-abi-13   | 
 OR xorg-video-abi-12   | 
 OR xorg-video-abi-11   | 
 OR xorg-video-abi-10   | 
 OR xorg-video-abi-8| 
 OR xorg-video-abi-6.0  | 
xserver-xorg-core   | 
glx-alternative-fglrx   (>= 0.4.1~) | 
libc6(>= 2.3.4) | 
libgl1-mesa-glx | 
 OR libgl1  | 
libx11-6| 
libxext6| 
libxrandr2  | 
libxrender1 | 
debconf   (>= 0.5)  | 
 OR debconf-2.0 | 
libfglrx  (= 1:14.6~betav1.0-1) | 
xorg-video-abi-15   | 
 OR xorg-video-abi-14   | 
 OR xorg-video-abi-13   | 
 OR xorg-video-abi-12   | 
 OR xorg-video-abi-11   | 
 OR xorg-video-abi-10   | 
 OR xorg-video-abi-8| 
 OR xorg-video-abi-6.0  | 
xserver-xorg-core   | 
glx-alternative-fglrx   (>= 0.4.1~) | 
libc6(>= 2.3.4) | 
libgl1-mesa-glx | 
 OR libgl1  | 
libx11-6| 
libxext6| 
libxrandr2  | 
libxrender1 | 
debconf   (>= 0.5)  | 
 OR debconf-2.0 | 


Package Status (Version) | Installed
-+-===
xserver-xorg | 1:7.7+12
xserver-xorg-core| 2:1.17.3-2
linux-headers| 
libdrm-radeon1   | 
xserver-xorg-video-ati   | 
xserver-xorg-video-radeon| 
ia32-libs| 


Recommends  (Version) | Installed
=-+-
===
fglrx-modules-dkms (= 1:14.6~betav1.0-1)  | 1:15.9-2
 OR fglrx-kernel-14.6-betav1.0| 
libgl1-fglrx-glx(= 1:14.6~betav1.0-1) | 
libgl1-fglrx-glx-i386 | 
fglrx-atieventsd  | 
fglrx-modules-dkms (= 1:14.6~betav1.0-1)  | 1:15.9-2
 OR fglrx-kernel-14.6-betav1.0| 
libgl1-fglrx-glx(= 1:14.6~betav1.0-1) | 
libgl1-fglrx-glx-i386 | 
fglrx-atieventsd  | 


Suggests(Version) | Installed
=-+-===
fglrx-control | 1:15.9-2
xvba-va-driver| 
amd-opencl-icd| 1:15.9-2
fglrx-control | 1:15.9-2
xvba-va-driver| 
amd-opencl-icd| 1:15.9-2




-8<---8<---8<---8<---8<---8<---8<---8<---8<--
Please attach the file:
  /tmp/reportbug-ng-fglrx-driver-T0tbkC.txt
to the mail. I'd do it myself if the output wasn't too long to handle.

  Thank you!
->8--->8--->8--->8--->8--->8--->8--->8--->8--

Bug#803292: prepare for giflib5

[Andreas Metzler]

Control: tags -1 fixed-upstream

On 2015-10-28 Matthias Klose  wrote:
> Package: src:wmaker
[...]
> Planning an update of giflib to the current version 5.1.1. Giflib slightly
> changes it's API, requiring soureful changes. There are some options for
> getting giflib5.1 support:
[...]

Hello,

this is fixed upstream, 0.96.7 builds against both giflib4 and
giflib5.1. I have doublechecked that 0.95.6-1.1 with the attached
patch from upstream git can be built against both versions of giflib,
so this could be uploaded to sid and wmaker would be NMU-able when
the new giflib hits sid.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
>From 7d09b2c04f99c25c6b02a93b8e12533312cc8bac Mon Sep 17 00:00:00 2001
From: Christophe CURIS 
Date: Sun, 26 Oct 2014 00:31:43 +0200
Subject: [PATCH] wrlib: add support for release 5.1.0 of the libgif

As reported by Andrew, the compilation of the WRaster broke because
there was an API change in libgif v5.1 versus the v5.0 (something had been
forgotten for DGifCloseFile to be easily used in wrappers for dynamic
languages).

Now, if we have detected that we're in 5.x release, we use the GIFLIB_MINOR
macro to see what the function prototype is (this macro was introduced only
in 4.1.6 so we cannot fully rely on it to detect the version of the
library).

The possible error code is not used because at the place we use the
function we would not be able do do anything more meaningful with it.

Signed-off-by: Christophe CURIS 
---
 wrlib/load_gif.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/wrlib/load_gif.c b/wrlib/load_gif.c
index 7a6cfc7..d70d044 100644
--- a/wrlib/load_gif.c
+++ b/wrlib/load_gif.c
@@ -81,7 +81,11 @@ RImage *RLoadGIF(const char *file, int index)
 	}
 
 	if (gif->SWidth < 1 || gif->SHeight < 1) {
+#if (USE_GIF == 5) && (GIFLIB_MINOR >= 1)
+		DGifCloseFile(gif, NULL);
+#else
 		DGifCloseFile(gif);
+#endif
 		RErrorCode = RERR_BADIMAGEFILE;
 		return NULL;
 	}
@@ -216,7 +220,11 @@ RImage *RLoadGIF(const char *file, int index)
 		free(buffer);
 
 	if (gif)
+#if (USE_GIF == 5) && (GIFLIB_MINOR >= 1)
+		DGifCloseFile(gif, NULL);
+#else
 		DGifCloseFile(gif);
+#endif
 
 	return image;
 }
-- 
2.6.1

Bug#803541: Fw: Re: broken links in the apt manual's area

[Holger Wansing]

Package: www.debian.org
Severity: minor

Since the html variants are working fine, I will remove the txt variants 
from the website for now.
Turning this into a bugreport, so that it doesn't get lost.



[Forwarded mail follows]

Date: Sun, 25 Oct 2015 12:30:01 +0100
From: Holger Wansing 
To: debian-...@lists.debian.org, debian-...@lists.debian.org
Cc: Jacob Fritz 
Subject: Re: broken links in the apt manual's area


[ Adding debian-doc into the loop; sorry for cross-posting ]


Hi,

Jacob Fritz  wrote:
> So I was going through the user manuals section of your website (
> https://www.debian.org/doc/user-manuals) and found that none of the apt
> manuals display plain text options, in spite of the fact that they have
> hyperlinks to them. I mean, I suppose I can copy and paste the HTML pages,
> but still...  Anyway, not sure if this was deliberate or not, so I just
> thought I'd mention it.

I have looked into this. Hopefully I got it right somehow:

For aptitude it seems the txt variant has to be removed from the webwml, 
since the aptitude-doc package does only contain html variants of the guide.


For apt-doc there are probably changes required in the package apt-doc, to get
a clean solution.
The APT User's Guide has the string "apt-guide" as identifier for building
the Debian website, which means the links for the text variant point to
../apt-guide/apt-guide.de.txt for German as example.
But the package does not contain such file ../apt-guide-... file, only
../guide-... files (without the apt- ).
Are there changings in the package needed to get that running?
Or is there some mechanism, that extracts the files out of the package
and renames it according to specific rules, before it gets loaded to the
Debian webserver?


Holger

-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

[Brian May]

Michael Biebl  writes:

> Can you attach your /etc/fstab please.

UUID=1308477f-22a4-48d7-9b82-8ff29e115234 /   ext4
errors=remount-ro 0   1
UUID=AC4D-F9EE  /boot/efi   vfatdefaults0   1
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0

/dev/sdc1   /btrfs   btrfs   defaults,noatime 0 0
/dev/sdc1   /homebtrfs   defaults,subvol=home,noatime 0 0
/dev/sdc1   /videos  btrfs   defaults,subvol=videos,noatime 0 0


> Also can you describe how your btrfs setup looks like.

/btrfs is mirrored on both /dev/sdb1 and /dev/sdc1

falidae#  btrfs filesystem show /btrfs 
Label: none  uuid: f77d6ce8-12bf-476a-8276-2031ce3e3c42
Total devices 2 FS bytes used 978.25GiB
devid1 size 1.82TiB used 981.03GiB path /dev/sdb1
devid2 size 1.82TiB used 981.03GiB path /dev/sdc1

Thought there was a way to show it was mirrored, can't remember it right
now.

> After the 90 second timeout, are you dumped into the emergency
> console?

Yes.

> Can you boot with systemd.log_level=debug on the kernel command line and
> attach the output of journalctl -alb.
>
> The output of udevadm info -e might be helpful as well.

Have a vague feeling I may have tried systemd.log_level=debug and it
didn't show anything useful. Not sure  now.

In any case, presumably you want these when it isn't working, so will
try to get it to fail again with the debug option and let you know.
-- 
Brian May 

Bug#794245: [Pkg-fonts-devel] Font build can't be done without new fontforge.

[Vasudev Kamath]

Philippe Cochy  writes:

>> I see error and a segmentation fault. Current version of fontforge in
>> Debian is 20120731.b-5+b3
>
> Sure! The sfdir (font.props) format was changed in the new fontforge.
> I do not think the solution is in a headlong rush but to save the font
> using the classic fontforge. Classic and new fontforge are for now
> incompatible.

In Debian we prefer to build from pristine source provided by
upstream. So I would not do the conversion and since upstream itself is
using newer fontforge, we don't know what we will loose trying to do
conversion and build using old fontforge.


signature.asc
Description: PGP signature

Bug#696851: attached fix

[Wolfgang Aigner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,
I've just made a fix for xdg directory.
Currently I try to fix a few annoying bugs in launchy. They can be found in:

https://github.com/wofwofwof/Launchy

- -- 
cheers

wof


commit 5d7967a258921f67ed8014f7b78cf2ea048263af
Author: wof 
Date:   Fri Oct 30 18:16:38 2015 +0100

honor XDGBaseDirectorySpecification from debian for config directories

diff --git a/trunk/Launchy_QT/platforms/unix/platform_unix.cpp 
b/trunk/Launchy_QT/platforms/unix/platform_unix.cpp
index a5394d2..75d0d30 100644
- --- a/trunk/Launchy_QT/platforms/unix/platform_unix.cpp
+++ b/trunk/Launchy_QT/platforms/unix/platform_unix.cpp
@@ -96,23 +96,29 @@ QList 
PlatformUnix::getDefaultCatalogDirectories() {
 QHash PlatformUnix::getDirectories() {
 QHash out;
 QDir d;
- -d.mkdir(QDir::homePath() + "/.launchy");
+
+QString xdg_config_home = qgetenv("XDG_CONFIG_HOME").constData();
+if (xdg_config_home.isEmpty()) {
+xdg_config_home = QDir::homePath() + "/.config/launchy";
+}
+
+d.mkdir(xdg_config_home);
 
 out["skins"] += qApp->applicationDirPath() + "/skins";
- -out["skins"] += QDir::homePath() + "/.launchy/skins";
+out["skins"] += xdg_config_home + "/skins";
 out["skins"] += SKINS_PATH;
 
 out["plugins"] += qApp->applicationDirPath() + "/plugins";
- -out["plugins"] += QDir::homePath() + "/.launchy/plugins";
+out["plugins"] += xdg_config_home + "/plugins";
 out["plugins"] += PLUGINS_PATH;
 
- -out["config"] += QDir::homePath() + "/.launchy";
+out["config"] += xdg_config_home;
 out["portableConfig"] += qApp->applicationDirPath();
 
 if (QFile::exists(out["skins"].last() + "/Default"))
- -   out["defSkin"] += out["skins"].last() + "/Default";
+out["defSkin"] += out["skins"].last() + "/Default";
 else
- -  out["defSkin"] += out["skins"].first() + "/Default";
+out["defSkin"] += out["skins"].first() + "/Default";
 
 out["platforms"] += qApp->applicationDirPath();
 out["platforms"] += PLATFORMS_PATH;


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWNJUpAAoJEG77w815zV8viCcP/RGlyUp8I6C8t1E6KSKvJseM
dbad4Z1oP9xybvGzLvKX5pVCV7XreT7bHb2GGqOaRaNY27PnwmO841wq29CIS+o+
RzOec15zu+pTpMUC2osoxRy6cJ4Oz6rcH7T0zI60XgvYJlpdwDu3kuH8KyD0jheV
lhrp27JjEwKfkk3rtFJ9QDxVUUJZZqbGOTk9W9bo7H9iC/Fbu09/AqFtjv3Pau1L
ooN9j3lrDVMlzbu8VBzSp4lQepW2WkUR7cLxDEsosLEKlnZHQRqOeq1SQQtfq3gt
z8erWQCkR4eCdP8HnyF0mjR4/nzyNoqegQ6VyELlOoHfr7oRiex+WhAS5Eu+26wV
I48U7bp5OAKThHDIE0iioUoErGW+nPHBa5vD2tVZgw3o+gbH4R9t9CzJl7Co3oZm
H6F6sze89l7F0rNv0P+N6QSSFAy+5oX9yX072+a2/FsfBm5Mv8eUSCKGwD98mcwO
ItHhFu2h57HXA7NpTL/PjQHtvBkRXtKhFOIFXD+YMZswZqmKglR1sS0aRq5shOii
oalVwzSRGb8qK/RsvgIOpCzG9TLxG0fs9l15xkuNX8FdZwMBSZHf62LA1gY0BM3d
d7PDKwG0HNARjH6Rh2YDuejDdYOjkK6O8FdJUVoKUdhLUZl4ibnlaXIzM6Ho5BO5
2n1y/U5w36NPA12RHI2X
=a3X3
-END PGP SIGNATURE-

Bug#803549: RM: ironic-discoverd -- ROM; duplicate package, renamed ironic-inspector

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal


Dear FTP masters,

Upstream for ironic-discoverd decided to rename the project as
ironic-inspector. Therefore, I have uploaded ironic-inspector
which is now in Sid. Ironic-discoverd is now useless and shall
be removed from Sid and Testging.

Thanks,

Thomas Goirand (zigo)

Bug#803550: rsem: uninstallable on architectures without bowtie

[Andreas Beckmann]

Package: rsem
Version: 1.2.22+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is not
installable in sid on most architectures:

rsem/i386 unsatisfiable Depends: bowtie | bowtie2
rsem/armel unsatisfiable Depends: bowtie | bowtie2
rsem/armhf unsatisfiable Depends: bowtie | bowtie2
rsem/mips unsatisfiable Depends: bowtie | bowtie2
rsem/mipsel unsatisfiable Depends: bowtie | bowtie2
rsem/powerpc unsatisfiable Depends: bowtie | bowtie2
rsem/s390x unsatisfiable Depends: bowtie | bowtie2

since bowtie/bowtie2 is only available on a restricted set of
architectures. This will prevent its migration to testing.


Cheers,

Andreas

Bug#803384: command-applet: Command Applet cuts off output string in the middle of multibyte characters

[Mike Gabriel]

Hi Axel,

On  Do 29 Okt 2015 14:57:23 CET, Axel wrote:


Package: mate-applets
Version: 1.8.1+dfsg1-3
Severity: normal
File: command-applet

Dear Maintainer,

Unfortunately Command Applet lacks configuration settings, e.g.  
whether and where to cut
off the string it is given by the program it calls. If strings are  
cut off, this seems
simply to be done along byte boundaries, causing the panel to  
display an ‘unknown
character’ mark (white question mark on black diamond) and  
/var/log/syslog to show:


org.mate.panel.applet.CommandAppletFactory[28797]:  
(command-applet:28910): Pango-WARNING **: Invalid UTF-8 string  
passed to pango_layout_set_text()




Could you be more descriptive on how to reproduce this issue?

What do you do?

What do you expect to happen?

What does really happen?

Presume that I don't know what the command applet is for and how to use it...

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/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de


pgpNRGIyhLWw4.pgp
Description: Digitale PGP-Signatur

Bug#799939: chromium: does not build / is not available for armhf

[Josua Mayer]

Hi everybody,

How about at least getting the armhf part in somewhere?
I tried to build this thing myself once more but I keep getting weird
compile errors so I'd love to see it build on one of the debian
buildbots.

br
Josua Mayer

2015-10-25 3:25 GMT+01:00 Michael Gilbert :
> On Wed, Oct 21, 2015 at 9:21 AM, Riku Voipio wrote:
>> Hi,
>>
>> Here's cleaned up patch against pkg-chromium git. I've now briefly tested the
>> built chromium runs on armhf hw and a bit more extensively on arm64 hw.
>>
>> Michael, how would you feel about sending at test build at experimental?
>
> These  changes are larger than I would like.  Please upstream them
> first, especially the assembly changes to openmax.
>
> Best wishes,
> Mike

Bug#803551: nmu: fcitx-sunpinyin_0.4.1-2

[Andreas Beckmann]

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

nmu fcitx-sunpinyin_0.4.1-2 . ANY . experimental . -m "Rebuild against 
libsunpinyin3v5."

let's finish the transition in experimental, too.


Andreas

Bug#803552: libeigen3-dev: Upgrade from 3.2.x to 3.3~alpha causes gnudatalanguage to FTBFS on arm64

[Axel Beckert]

Package: libeigen3-dev
Version: 3.3~alpha1-2
Severity: grave
Control: affects -1 src:gnudatalanguage
Justification: Makes package unusable on one release architecture

Hi,

with the most recent upload of gnudatalanguage (which just changed
documentation stuff), it deterministically FTBFS on arm64 -- and only
there (not counting non-release architectures which have different
issues):

https://buildd.debian.org/status/package.php?p=gnudatalanguage
https://buildd.debian.org/status/fetch.php?pkg=gnudatalanguage=arm64=0.9.5-3=1445723100

Example log excerpt:

In function 'float64x2_t vdupq_lane_f64(float64x1_t, int)',
inlined from 'Packet Eigen::internal::pmul(const Packet&, const Packet&) 
[with Packet = Eigen::internal::Packet1cd]' at 
/usr/include/eigen3/Eigen/src/Core/arch/NEON/Complex.h:329:22,
inlined from 'Packet Eigen::internal::pmadd(const Packet&, const Packet&, 
const Packet&) [with Packet = Eigen::internal::Packet1cd]' at 
/usr/include/eigen3/Eigen/src/Core/GenericPacketMath.h:450:14,
inlined from 'static void Eigen::internal::etor_product_packet_impl<0, -1, 
Lhs, Rhs, Packet, LoadMode>::run(Eigen::Index, Eigen::Index, const Lhs&, const 
Rhs&, Eigen::Index, Packet&) [with Lhs = 
Eigen::internal::evaluator, 16, Eigen::Stride<0, 0> > >; Rhs = 
Eigen::internal::evaluator, 16, Eigen::Stride<0, 0> > >; Packet = Eigen::internal::Packet1cd; int 
LoadMode = 0; Eigen::Index = long int]' at 
/usr/include/eigen3/Eigen/src/Core/ProductEvaluators.h:601:7,
inlined from 'const PacketType 
Eigen::internal::product_evaluator, ProductTag, 
Eigen::DenseShape, Eigen::DenseShape, typename Lhs::Scalar, typename 
Rhs::Scalar>::packet(Eigen::Index, Eigen::Index) const [with int LoadMode = 0; 
PacketType = Eigen::internal::Packet1cd; Lhs = 
Eigen::Map, 16, Eigen::Stride<0, 0> 
>; Rhs = Eigen::Map, 16, 
Eigen::Stride<0, 0> >; int ProductTag = 8; typename Rhs::Scalar = 
std::complex; typename Lhs::Scalar = std::complex; Eigen::Index 
= long int]' at /usr/include/eigen3/Eigen/src/Core/ProductEvaluators.h:493:5,
inlined from 'void 
Eigen::internal::generic_dense_assignment_kernel::assignPacket(Eigen::Index, Eigen::Index) 
[with int StoreMode = 16; int LoadMode = 0; PacketType = 
Eigen::internal::Packet1cd; DstEvaluatorTypeT = 
Eigen::internal::evaluator, 16, Eigen::Stride<0, 0> > >; SrcEvaluatorTypeT = 
Eigen::internal::evaluator, 16, Eigen::Stride<0, 0> >, 
Eigen::Map, 16, Eigen::Stride<0, 0> 
>, 1> >; Functor = Eigen::internal::assign_op; int 
Version = 0; Eigen::Index = long int]' at 
/usr/include/eigen3/Eigen/src/Core/AssignEvaluator.h:598:5,
inlined from 'void 
Eigen::internal::generic_dense_assignment_kernel::assignPacketByOuterInner(Eigen::Index, 
Eigen::Index) [with int StoreMode = 16; int LoadMode = 0; PacketType = 
Eigen::internal::Packet1cd; DstEvaluatorTypeT = 
Eigen::internal::evaluator, 16, Eigen::Stride<0, 0> > >; SrcEvaluatorTypeT = 
Eigen::internal::evaluator, 16, Eigen::Stride<0, 0> >, 
Eigen::Map, 16, Eigen::Stride<0, 0> 
>, 1> >; Functor = Eigen::internal::assign_op; int 
Version = 0; Eigen::Index = long int]' at 
/usr/include/eigen3/Eigen/src/Core/AssignEvaluator.h:612:5,
inlined from 'static void Eigen::internal::dense_assignment_loop::run(Kernel&) [with Kernel = 
Eigen::internal::generic_dense_assignment_kernel, 16, Eigen::Stride<0, 0> > >, 
Eigen::internal::evaluator, 16, Eigen::Stride<0, 0> >, 
Eigen::Map, 16, Eigen::Stride<0, 0> 
>, 1> >, Eigen::internal::assign_op, 0>]' at 
/usr/include/eigen3/Eigen/src/Core/AssignEvaluator.h:516:9,
inlined from 'void Eigen::internal::call_dense_assignment_loop(const 
DstXprType&, const SrcXprType&, const Functor&) [with DstXprType = 
Eigen::Map, 16, Eigen::Stride<0, 0> 
>; SrcXprType = Eigen::Product, 16, Eigen::Stride<0, 0> >, 
Eigen::Map, 16, Eigen::Stride<0, 0> 
>, 1>; Functor = Eigen::internal::assign_op]' at 
/usr/include/eigen3/Eigen/src/Core/AssignEvaluator.h:659:3:
/usr/lib/gcc/aarch64-linux-gnu/5/include/arm_neon.h:14027:10: error: lane 1 out 
of range 0 - 0
   return 

Bug#802688: sbuild does not honor setup.fstab

[Stephan Sürken]

Hi Marc!

On Do, 2015-10-22 at 18:19 +0200, Marc Haber wrote:
(...)
> mini-buildd uses the setup.fstab option in /etc/schroot/chroot.d/* to
> ask schroot to honor the fstab file from /etc/schroot/mini-buildd/fstab.
> 
> This does, for some strange reason, not work on a current sid system.
> 
> This, in turn, leaves the chroots without /var/lib/mini-buildd
> mounted, which in turn leads to the strange "apt_sources.list not
> found" errors in the build logs, which in turn leads to unbuildable
> packages when the package has a build dependency not in Debian, but in
> the mini-buildd archive.
> 
> I was able to work around this by exchanging
> "setup.fstab=mini-buildd/fstab" for "profile=mini-buildd" in
> /etc/schroot/chroot.d/mini-buildd*, setting the files immutable so
> that mini-buildd doesn't "fix" them any more, and copying nssdatabases
> and copyfiles from /etc/schroot/default to /etc/schroot/mini-buildd.

Uff, WTF ;)!

However, I just tried to produce this on my sid test environment, but I
could not, so I guess I am not getting something here.

So, do I understand correctly, when the bug happens,
'/etc/schroot/mini-buildd/fstab' _does_ have the line

--
/var/lib/mini-buildd/var  /var/lib/mini-buildd/var  none  rw,bind 0  0
--

but running something like

--
schroot --chroot mini-buildd-jessie-amd64 -- ls -la /var/lib/mini-buildd/var/
--

(as user mini-buildd) does not work?

Thx!

S

Bug#803462: Setting load-prefer-newer break Emacs startup

[Sam Halliday]

Looks like daylight savings kicking in.

Bug#796348: "no route to host" - which host?

[Stephan Sürken]

Hi Marc,

On Fr, 2015-08-21 at 15:05 +0200, Marc Haber wrote:
> Aug 21 14:57:32 spinturn mini_buildd.misc (0588): DEBUG   : Call 
> successful: gpg --homedir=/var/lib/mini-buildd/.gnupg --display-charset=UTF-8 
> --batch --armor --textmode --clearsign 
> --output=/var/lib/mini-buildd/var/spool/e60204c31c1ad87c372b2bb699d1ee00089b0b29/armhf/borgbackup_0.24.0-0~zgSID+3_mini-buildd-buildrequest_armhf.changes.signed
>  
> /var/lib/mini-buildd/var/spool/e60204c31c1ad87c372b2bb699d1ee00089b0b29/armhf/borgbackup_0.24.0-0~zgSID+3_mini-buildd-buildrequest_armhf.changes.asc
> Aug 21 14:57:32 spinturn mini_buildd.packager (0037): ERROR   : 
> borgbackup_0.24.0-0~zgSID+3: Buildrequest upload failed:  [Errno 113] No route to host>

this is fixed in 1.0.8; you should get some "can't get status..."
including the failing URL.

I.e., if I am not mistaken, this is actually an python urllib call
failing -- I would really be interested in why it does so, and if there
is anything in mbd that needs fixing here...

Thx!

S

Bug#798999: transition: python3.5 supported

[Andreas Beckmann]

Followup-For: Bug #798999

A few binNMUs for experimental:

nmu libselinux_2.4-2 . ANY . experimental . -m "Rebuild with python3.5 as a 
supported python3."
nmu libguestfs_1:1.29.50-1 . ANY . experimental . -m "Rebuild with python3.5 as 
a supported python3."
nmu python-apt_1.1.0~alpha3 . ANY . experimental . -m "Rebuild with python3.5 
as a supported python3."
nmu python-numpy_1:1.10.0~b1-1 . ANY . experimental . -m "Rebuild with 
python3.5 as a supported python3."


Andreas

Bug#803559: golang-go: fails to upgrade from 'jessie' - trying to overwrite /usr/lib/go/pkg/tool/linux_amd64/cover

[Andreas Beckmann]

Package: golang-go
Version: 2:1.5.1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

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

  Selecting previously unselected package golang-go.
  Preparing to unpack .../golang-go_2%3a1.5.1-3_amd64.deb ...
  Unpacking golang-go (2:1.5.1-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/golang-go_2%3a1.5.1-3_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/go/pkg/tool/linux_amd64/cover', which is also 
in package golang-go.tools 0.0~hg20140703-4
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/golang-go_2%3a1.5.1-3_amd64.deb


cheers,

Andreas


golang-go.tools=0.0~hg20140703-4_golang-go=2%1.5.1-3.log.gz
Description: application/gzip

Bug#803565: ure: removal of ure makes files disappear from libreoffice-common: /usr/lib/libreoffice/program/unorc

[Andreas Beckmann]

Package: ure
Version: 5.0.3~rc1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install libreoffice-common/jessie
  # (1)
  apt-get install ure/stretch
  apt-get remove ure/stretch
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /usr/lib/libreoffice/program/unorc

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
and also see the footnote that describes this incorrect behavior
https://www.debian.org/doc/debian-policy/footnotes.html#f53

The ure package has the following relationships with libreoffice-common:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  libreoffice-common (<< 1:4.4.0)

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

1m16.5s DEBUG: Modified(user, group, mode, size, target): 
/var/lib/dpkg/info/libreoffice-common.list expected(root, root, - 100644, 
236321, None) != found(root, root, - 100644, 236286, None)
1m16.5s ERROR: FAIL: After purging files have disappeared:
  /usr/lib/libreoffice/program/unorc owned by: ure

1m16.5s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/libreoffice-common.list not owned


cheers,

Andreas


libreoffice-common=1%4.3.3-2+deb8u1_ure=5.0.3~rc1-2.log.gz
Description: application/gzip

Bug#803564: python-mapnik uses wrong lib-directory

[Tobias Wendorff]

Package: python-mapnik
Version: 1:0.0~20151022-ab8b1f6-1 and others

I've just backported mapnik 3.0.8 from Debian Sid to Debian Jessie. Quiet
easy, but after installing python-mapnik, Mapnik complained about the
datasource plugin directories not being registered.

After doing some tests with mapnik-config, ldd and ctypes, I've found the
problem in paths.py in dist-/site-packages. The setup sets mapniklibpath
to lib_path + "/mapnik". On Debian, Mapnik3 gets installed to
''/usr/lib/mapnik/3.0"; the missing plugins are in its subdirectory input.
The installer sets the path to /usr/lib/mapnik[/input] instead of
/usr/lib/mapnik/3.0[/input], which leads to the problem reported.

Since mapnik-config finds the correct path, please use this output instead
of a hardcoded string in
https://github.com/mapnik/python-mapnik/blob/master/setup.py

Read more about it here:
https://github.com/mapnik/python-mapnik/issues/62

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

[Michael Biebl]

Control: tags -1 + moreinfo

Hi Brian

Am 31.10.2015 um 03:55 schrieb Brian May:
> Package: systemd
> Version: 215-17+deb8u2
> Severity: important
> 
> When my computer boots, it times out trying to mount /dev/sdc1 to /home.
> That is it takes more then 90 seconds.
> 
> Yet when I run "mount -a" by hand it takes a maximum of 2 seconds.
> 
> If I keep rebooting the computer by hand, eventually it works, and it is
> fast.
> 
> Wish I knew what systemd was doing when it says it is mounting the
> filesystem that is taking all that time. I don't know how to debug this
> however.

Can you attach your /etc/fstab please.
Also can you describe how your btrfs setup looks like.

After the 90 second timeout, are you dumped into the emergency console?

Can you boot with systemd.log_level=debug on the kernel command line and
attach the output of journalctl -alb.

The output of udevadm info -e might be helpful as well.



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



signature.asc
Description: OpenPGP digital signature

Bug#803354: ITP: dsfmt -- dSFMT pseudorandom number generator

[Paul Wise]

On Thu, Oct 29, 2015 at 11:09 AM, Peter Colberg wrote:

> This package replaces the embedded copy of dSFMT in the julia package, and
> is suited to substitute embedded copies in the xmds2 and shogun packages.

Please have the embedded copies documented:

https://wiki.debian.org/EmbeddedCodeCopies

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#803542: ITP: trnascan-se -- detection of transfer RNA genes in genomic sequence

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 

* Package name: trnascan-se
  Version : 1.3.1
  Upstream Author : Todd Lowe  and colleagues
* URL : http://lowelab.ucsc.edu/tRNAscan-SE
* License : GPL
  Programming Lang: C, Perl
  Description : detection of transfer RNA genes in genomic sequence

tRNAscan-SE identifies 99-100% of transfer RNA genes in DNA sequence while
giving less than one false positive per 15 gigabases. Two previously described
tRNA detection programs are used as fast, first-pass prefilters to identify
candidate tRNAs, which are then analyzed by a highly selective tRNA covariance
model. This work represents a practical application of RNA covariance models,
which are general, probabilistic secondary structure profiles based on
stochastic context-free grammars. tRNAscan-SE searches at ~ 30 000 bp/s.
Additional extensions to tRNAscan-SE detect unusual tRNA homologues such as
selenocysteine tRNAs, tRNA-derived repetitive elements and tRNA pseudogenes.

This package is useful for genome annotations and will be managed by the
Debian Med team.

Bug#791965: ITP: openzwave -- API to use a Z-Wave controller

[Lucas Nussbaum]

On 09/07/15 at 19:37 +0200, Thorsten Alteholz wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Thorsten Alteholz 
> 
> * Package name: openzwave
>   Version : 1.2.919-1
>   Upstream Author : Mal Lansell 
> * URL : https://github.com/OpenZWave/open-zwave
> * License : LGPL-3+
>   Programming Lang: C++
>   Description : API to use a Z-Wave controller
> 
>  OpenZWave is an open-source, cross-platform library designed to enable
>  anyone to add support for Z-Wave home-automation devices to their
>  applications, without requiring any in depth knowledge of the Z-Wave
>  protocol.

Hi Thorsten,

Have you made progress on this? I'm using openzwave, and would be
interested in helping with getting it packaged. I started looking at
the upstream-provided debian packaging.

Lucas

Bug#803207: gnome-settings-daemon: uses far too much memory (5.5GB currently)

[Stephen Kitt]

Control: affects -1 + gnome-shell

On Tue, 27 Oct 2015 23:52:01 +0100, Stephen Kitt  wrote:
> On my system, the instance of gnome-settings-daemon started for the
> login session uses more and more memory as time goes by (even though
> there's no activity on the login session). Currently, after two days,
> it's using 5.5GB; the daemons in the user sessions are up to 644MB and
> 22.6MB respectively:

A few days later, its RSS is down but its VSZ is up (and my system is using
11.2GB of swap):

Debian-+  7973  0.0 13.6 10954276 4472144 tty7 Sl+  Oct24   5:16 
/usr/lib/gnome-settings-daemon/gnome-settings-daemon

If it's any help, gnome-shell is exhibiting the same behaviour:

Debian-+  7912 41.2  7.6 4173604 2527448 tty7  Sl+  Oct24 4059:37 gnome-shell 
--mode=gdm --wayland --display-server

Regards,

Stephen


pgpi7lLCePFoi.pgp
Description: OpenPGP digital signature

Bug#803544: kde-full: screen flickering - shutdown timer window

[Natrayan]

Package: kde-full
Version: 5:90
Severity: normal
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?
 Click Shutdown. Shutdown countdown timer appears.  Bring the mouse cursor
to application launcher.  Screen starts flickering.
   * 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?
 Screen should not flicker.  Background menus should be disabled completely
and enabled only if i click cancel in the shutdown countdown timer.

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



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

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

Versions of packages kde-full depends on:
ii  kde-plasma-desktop  5:90
ii  kde-standard5:90
ii  kdeadmin4:4.12+5.90
ii  kdeartwork  4:15.08.0-1
ii  kdeedu  4:4.12+5.90
ii  kdegames4:4.12+5.90
ii  kdegraphics 4:4.12+5.90
ii  kdemultimedia   4:4.12+5.90
ii  kdenetwork  4:4.12+5.90
ii  kdepim  4:4.14.10-2
ii  kdeutils4:4.12+5.90

Versions of packages kde-full recommends:
ii  kdeaccessibility  4:4.12+5.90
ii  kdesdk4:4.12+dfsg+5.90
ii  kdetoys   4:4.12+5.90
ii  kdewebdev 4:15.08.0-1

Versions of packages kde-full suggests:
pn  calligra  
pn  kde-l10n  
ii  xorg  1:7.7+12

-- no debconf information

Bug#803538: thuban: small typo in (long) description

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Ambrose,

Thanks for reporting this issue. The typo is fixed in git and will be
included in the next upload.

If you're actually using the thuban package I strongly suggest to switch
to an alternative (qgis for example), because Thuban upstream
development died some time ago. We may not keep it in the archive much
longer.

Kind Regards,

Bas

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

Bug#803545: C++ header includes AES intrinsics

[Jeffrey Walton]

Package: g++
Version: 4:4.9.2-2
Severity: normal

**

I'm catching a compile failure when building a library (not a
program). The library is a crypto library called Crypto++
(https://cryptopp.com). Here's the project's bug report on the issue:
https://github.com/weidai11/cryptopp/issues/53 .

It appears GCC's  is including system files that include
AES intrinsics. Here's what one of the errors looks like:

$ g++ -DDEBUG -g2 -O2 -std=c++11  -fPIC -march=native -pipe -c cpu.cpp
cryptlib.h:864:39: error: ‘__m128i _mm_aesdeclast_si128(__m128i,
__m128i)’ conflicts with a previous declaration
  class CRYPTOPP_DLL CRYPTOPP_NO_VTABLE BufferedTransformation :
public Algorithm, public Waitable
   ^
In file included from
/usr/lib/gcc/x86_64-linux-gnu/4.9/include/x86intrin.h:43:0,
 from /usr/include/x86_64-linux-gnu/c++/4.9/bits/opt_random.h:33,
 from /usr/include/c++/4.9/random:50,
 from /usr/include/c++/4.9/bits/stl_algo.h:66,
 from /usr/include/c++/4.9/algorithm:62,
 from stdcpp.h:13,
 from cryptlib.h:85,
 from misc.h:11,
 from cpu.cpp:13:
/usr/lib/gcc/x86_64-linux-gnu/4.9/include/wmmintrin.h:52:1: note:
previous declaration ‘__m128i _mm_aesdeclast_si128(__m128i, __m128i)’
 _mm_aesdeclast_si128 (__m128i __X, __m128i __Y)
 ^
In file included from cpu.cpp:12:0:
cpu.h:89:1: note: -fabi-version=6 (or =0) avoids this error with a
change in mangling
 _mm_aesdeclast_si128 (__m128i a, __m128i b)
 ^

**

We test a matrix of configurations (debug, release, C++03/C++11,
santiziers, optimizations, etc). The issue shows up whenever C++11 is
used. C++03 is OK.

Something tastes a little off here. I've never seen this issue before.


**

$ uname -a
Linux core2 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5
(2015-10-09) x86_64 GNU/Linux

$ lsb_release
No LSB modules are available.

**

Possibly related (due to "note: -fabi-version=6 (or =0)..."):

* [Bug 65919] - GCC 5.1 with options "-g -std=c++14" fails to compile
multiple lambdas used as default function parameters,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65919
* [Bug 42748] - warnings about 'mangling of 'va_list' has changed in
GCC 4.4' not suppressed in sytem headers,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748

**

$ apt-cache show g++
Package: g++
Source: gcc-defaults (1.136)
Version: 4:4.9.2-2
Installed-Size: 34
Maintainer: Debian GCC Maintainers 
Architecture: amd64
Provides: c++-compiler
Depends: cpp (>= 4:4.9.2-2), gcc (>= 4:4.9.2-2), g++-4.9 (>=
4.6.4-1~), gcc-4.9 (>= 4.6.4-1~)
Suggests: g++-multilib
Description-en: GNU C++ compiler
 This is the GNU C++ compiler, a fairly portable optimizing compiler for C++.
 .
 This is a dependency package providing the default GNU C++ compiler.
Description-md5: 4d44b18774ae5123b7c3f70d940cf655
Build-Essential: yes
Tag: devel::compiler, devel::lang:c++, implemented-in::c,
 interface::commandline, role::dummy, role::metapackage, suite::gnu,
 works-with::software:source
Section: devel
Priority: optional
Filename: pool/main/g/gcc-defaults/g++_4.9.2-2_amd64.deb
Size: 1530
MD5sum: cd4aa68ba8cf582df806c324988e6a00
SHA1: 82a50c84e1105e1f0c767da82c09f2398ac2d4b2
SHA256: 6fb9842c6a0ad0cd5445b9f2f2cb3f738abcc83a6b8e0900aad441574f5cecee

Bug#784569: fpc: fpc on arm64

[Paul Gevers]

Hi Edmund,

On 29-10-15 11:09, Edmund Grimley Evans wrote:
>> Here's a recipe using the source in the Debian repo, if that counts.

> Do you now have a ppca64?

Yes, I do.

> Since the Debian build script expects to use fpcmake, but I don't know
> how to cross-compile fpcmake, probably the next thing to do is a
> native non-Debian build. I think you can copy the fpcsrc tree, as
> modified by fpcmake during the cross-compilation, over to an arm64
> system and then do:

I am not 100% sure what you meant, but I copied over the by fpcmake
generated Makefiles on my amd64 system (so, non-native Debian) and then
I was able to build an arm64 fpcmake (by turning off some parts of the
the regular clean operations in debian/rules). The full build still
failed for me, but at least I had both ppca64 and an arm64 fpcmake.

Using the newly build fpcmake and reverting most of my changes to
d/rules I just successfully ran dpkg-buildpackage -B -d on the arm64
porterbox (hooray). (I had to disable the "unexport FPC" line in
debian/rules and instead do "export FPC=/home/elbrus/ppca64" there.
Should I use PP=/home/elbrus/ppca64 instead?)

I will try to upload the arm64 packages and then I will upload
3.0.0~rc2+dfsg-2 to apply the arm64 patches and to fix the armhf FTBFS.
When that has landed, the arm64 package should be build natively.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#803548: RM: oslo-config -- ROM; duplicate source package

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal


Dear FTP masters,

We made a bunch of source package renames to make it more logic, as per
below:
- oslo.rootwrap -> python-oslo.rootwrap
- oslo.messaging -> python-oslo.messaging
- oslo-config -> python-oslo.config

As a consequence, the old source packages should be removed from Sid. To
be more explicit, I'd like these to be deleted, as they have now a new
replacement:
- oslo.rootwrap
- oslo.messaging
- oslo-config

Thanks in advance,
Cheers,

Thomas Goirand (zigo)

Bug#800681: Esc+ doesn't work twice in a row

[Arturo Borrero Gonzalez]

On 30 October 2015 at 13:27, Benno Schulenberg  wrote:
>
> On Fri, Oct 30, 2015, at 12:51, Arturo Borrero Gonzalez wrote:
>> I'm using nano 2.4.2-1.
>>
>> Using --ignore didn't work :-(
>>
>> When pressing the key combinations, a message is shown: [ Unknown Command ].
>
> Strange.  It shows that message for me only when I press
> Alt+Left and Alt+Right.
>
> What happens when you press Shift+Left and Win+Left?
> (For me those combinations work as if I pressed just Left.)
>
> Could you try and compile nano from source, and run
> ./configure --enable-debug, then run make, and then:
>
>   src/nano  README  2>TRAIL
>
> press Ctrl+Right three times, and Ctrl+Left twice,
> and then Ctrl+X and attach the TRAIL file here?
>

find it attached.

-- 
Arturo Borrero González


TRAIL
Description: Binary data

Bug#803563: libncurses5-dev, libncursesw5-dev: removal of libncurses5-dev makes files disappear from ncurses-bin

[Andreas Beckmann]

Package: libncurses5-dev,libncursesw5-dev
Version: 6.0+20151024-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install ncurses-bin/stretch
  # (1)
  apt-get install libncurses5-dev/sid
  apt-get remove libncurses5-dev/sid
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /usr/bin/ncurses5-config
  /usr/share/man/man1/ncurses5-config.1.gz

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
and also see the footnote that describes this incorrect behavior
https://www.debian.org/doc/debian-policy/footnotes.html#f53

The libncurses5-dev package has the following relationships with ncurses-bin:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  ncurses-bin (<< 6.0+20151017)

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

0m50.7s DEBUG: Modified(user, group, mode, size, target): 
/var/lib/dpkg/info/ncurses-bin.list expected(root, root, - 100644, 994, None) 
!= found(root, root, - 100644, 928, None)
0m50.7s ERROR: FAIL: After purging files have disappeared:
  /usr/bin/ncurses5-config   owned by: libncurses5-dev:amd64
  /usr/share/man/man1/ncurses5-config.1.gz   owned by: libncurses5-dev:amd64

0m50.7s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/ncurses-bin.listnot owned


A similar problem exists in the libncursesw5-dev package.


cheers,

Andreas


ncurses-bin=5.9+20140913-1+b1_libncurses5-dev=6.0+20151024-1.log.gz
Description: application/gzip

Bug#802517: Freecad bug

[Michael Zoran]

Hi, I solved the problem.  This appears to be an issue with gcc-5.  
When I recompile oce with gcc-4.9, all the regression tests of oce pass
and freecad seems to be working correctly.   If I compile oce with gcc-
5, some of the regression tests fail and freecad crashes.  
I noticed that the failing regression tests where removed from the -7
release of oce.

All I did was add these lines to the top of the rules file.

export CC := /usr/bin/gcc-4.9
export CXX := /usr/bin/g++-4.9
CFLAGS   := -g -O3
CXXFLAGS := -g -O3
LDFLAGS  := $(shell dpkg-buildflags --get LDFLAGS)

The CFLAGS and CXXFLAGS change is not important, and was just part of
trial and error.  I didn't have time to recompile and test without out.

The "export CC" and "export CXX" is the important part since it forces
the compile to use gcc-4.9.

I also changed the control file to add gcc-4.9 and g++-4.9 as "Build-
Depends".

Source: oce
Section: science
Priority: extra
Maintainer: Debian Science Maintainers 
Uploaders: "Adam C. Powell, IV" , Denis Barbier 
Standards-Version: 3.9.5
Build-Depends: debhelper (>= 9), quilt, cmake, gcc-4.9, g++-4.9,
 libx11-dev, libxmu-dev, libxext-dev, libfreetype6-dev, tcl8.5-dev,
tk8.5-dev,
 libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev,
 libgl2ps-dev, libfreeimage-dev
Homepage: https://github.com/tpaviot/oce/wiki
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=debian-science/package
s/oce.git
Vcs-Git: git://anonscm.debian.org/debian-science/packages/oce.git -b
debian


I was able to recompile oce with the changes with pbuilder on amd64.  
I'm compiling armhf with pbuilder now, but I think it's going to take a
long time for the compile to finish.

Bug#803505: [buildd-tools-devel] Bug#803505: sbuild: Run build-deps-failed-commands on apt-get-update fail stage too

[Luca Falavigna]

Hi!

2015-10-30 22:00 GMT+01:00 Johannes Schauer :
> What would the benefit be to have a --apt-get-update-failed-commands hook?
> Which hook would one like to run when "apt-get update" failed?

I have a local repository of built packages linked to my sbuild
instances. Everytime a build is successful, the repository indexes are
updated. In case of multiple builds, it could happen newer concurrent
builds start to update apt cache just in the middle of a
apt-ftparchive run, resulting in a "hash sum mismatch" error.

I would like to implement a simple locking mechanism using plain files
(it's definitely not the best approach, I welcome better ideas ;). I
acquire the lock in the chroot-setup and I should manage the removal
of the lock if something goes wrong in whatever stage. With the
current status, if sbuild fails in apt-get-update the lock is never
deleted because no commands are triggered.

-- 
Cheers,
Luca

Bug#803505: [buildd-tools-devel] Bug#803505: sbuild: Run build-deps-failed-commands on apt-get-update fail stage too

[Johannes Schauer]

Hi,

Quoting Luca Falavigna (2015-10-31 08:28:58)
> 2015-10-30 22:00 GMT+01:00 Johannes Schauer :
> > What would the benefit be to have a --apt-get-update-failed-commands hook?
> > Which hook would one like to run when "apt-get update" failed?
> 
> I have a local repository of built packages linked to my sbuild
> instances. Everytime a build is successful, the repository indexes are
> updated. In case of multiple builds, it could happen newer concurrent
> builds start to update apt cache just in the middle of a
> apt-ftparchive run, resulting in a "hash sum mismatch" error.
> 
> I would like to implement a simple locking mechanism using plain files
> (it's definitely not the best approach, I welcome better ideas ;). I
> acquire the lock in the chroot-setup and I should manage the removal
> of the lock if something goes wrong in whatever stage. With the
> current status, if sbuild fails in apt-get-update the lock is never deleted
> because no commands are triggered.

if you run multiple concurrent sbuild instances, would it not be a better idea
to always run sbuild with --no-apt-update and instead run "sbuild-update
-udcar" whenever it is actually needed? I imagine that lots of time is lost by
"apt-get update" being run on every build even if there is nothing new to
update.

cheers, josch


signature.asc
Description: signature

Bug#792096: borg packaging: Update

[Danny B. Edel]

Hello everyone,

borgbackup-0.27.0-1 has been packaged and uploaded, and is in the [new]
queue.  The package is being maintained in collab-maint, all extra
repositories and branches on collab-maint or github have been deleted.

Since python3-setuptools-scm will behave differently when called in a
git clone (it will attempt to construct a version number from the
current git commit, which will point to the debian packaging and not the
upstream code), a gbp.conf file has been added that makes use of the
[export-dir] mechanism.  That way, python3-setuptools-scm falls back to
reading the metadata files included in the directory (since it will be
called outside the git clone), creating the correct (upstream) version
number.

- Danny

[new]: https://ftp-master.debian.org/new.html
[export-dir]:
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.building.html#GBP.BUILDING.EXPORT

Bug#803553: ITP: php-sca-sdo -- Service Component Architecture (SCA) and Service Data Objects (SDO) for PHP

[Peter Sági]

Package: wnpp
Severity: wishlist
Owner: "Peter Sági" 


* Package name: php-sca-sdo
  Version : 1.2.4-3
  Upstream Author : Graham Charters , Caroline Maynard 
, Matthew Peters , Simon Laws 

* URL : https://pecl.php.net/package/SCA_SDO
* License : Apache 2.0
  Programming Lang: C++, PHP
  Description : Service Component Architecture (SCA) and Service Data 
Objects (SDO) for PHP

 Service Data Objects (SDOs) enable PHP applications to work with
 data from different sources (typically a database query or an
 XML file) using a single interface. SCA for PHP allows a PHP
 programmer to write reusable components (classes) in PHP, which
 can be called either locally, or in a variety of ways remotely
 (soap web services, xml-rpc, json-rpc, REST, etc), but always with
 the same interface.

Bug#803561: [INTL:da] Danish translation of the debconf templates dbconfig-common

[Joe Dalton]

Package: dbconfig-common
Severity: wishlist
Tags: l10n patch

Please include the attached Danish dbconfig-common translation

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

bye
Joe

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

Bug#803562: [lutz.press...@sernet.de: exim4 4.84-8 (jessie): crashes with MIME ACL used. Fixed package for point release? [TT#2150084]]

[Andreas Metzler]

Package: exim4
Version: 4.84-8
Severity: important

- Forwarded message from Lutz Preßler  -
Date: Mon, 26 Oct 2015 15:17:45 +0100
From: Lutz Preßler 
To: ametz...@debian.org, debian-packa...@zugschlus.de
Subject: exim4 4.84-8 (jessie): crashes with MIME ACL used. Fixed package for
point release? [TT#2150084]
Message-Id: 

Guten Tag! (Continuing in English in case to be forwarded into the bug tracker:)

After upgrading systems with exim4-daemon-heavy from wheezy to
jessie we're triggering crashes on setups with the MIME ACL feature
used.
Looking through the git history I find

commit 93cad488cb2c9a31aea345c8910a9f9c5815071c
 Author: Jeremy Harris 
 Date:   Fri Aug 29 14:11:50 2014 +0100

 Fix crash in mime acl when a parameter is zero-length

and later commits with descriptions regarding fixes in this area
(and see that there had been changes between the wheezy and jessie
versions).
Jessie release is based on version from 2014-08-09...

I have not been able to trigger the bug with a recent exim release.

What do you need to apply necessary fixes to 4.84 and release a
fixed version for jessie/the next point release?

Thanks for your work,
   Lutz Preßler

-- 
Lutz Preßler  http://www.SerNet.de/
SerNet Service Network GmbH, Bahnhofsallee 1b, D-37081 Göttingen
Tel.: +49-551-37-0,  FAX: +49-551-37-9
AG Göttingen, HRB 2816,  GF: Dr. Johannes Loxen

- End forwarded message -

Bug#803566: kmidimon: FTBFS: add_custom_target cannot create target "uninstall"

[Chris Lamb]

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

Dear Maintainer,

kmidimon fails to build from source in unstable/amd64:

  [..]

  -- checking for module 'drumstick-alsa>=0.5'
  --   found drumstick-alsa, version 0.5.0
  -- kmidimon 0.7.5 install prefix: /usr
  CMake Warning (dev) at /usr/lib/automoc4/Automoc4Config.cmake:179
  (get_directory_property):
Policy CMP0059 is not set: Do no treat DEFINITIONS as a built-in
directory
property.  Run "cmake --help-policy CMP0059" for policy details. 
Use the
cmake_policy command to set the policy and suppress this warning.
  Call Stack (most recent call first):
/usr/lib/automoc4/Automoc4Config.cmake:243 (_add_automoc4_target)
/usr/share/kde4/apps/cmake/modules/KDE4Macros.cmake:1026
(_automoc4_kde4_pre_target_handling)
src/CMakeLists.txt:68 (KDE4_ADD_EXECUTABLE)
  This warning is for project developers.  Use -Wno-dev to suppress it.
  
  CMake Error at CMakeLists.txt:135 (ADD_CUSTOM_TARGET):
add_custom_target cannot create target "uninstall" because another
target
with the same name already exists.  The existing target is a custom
target
created in source directory
"/home/lamby/temp/cdt.20151031125942.DIQJT2tM3F/kmidimon-0.7.5". 
See
documentation for policy CMP0002 for more details.
  
  
  -- Configuring incomplete, errors occurred!
  See also
  
"/home/lamby/temp/cdt.20151031125942.DIQJT2tM3F/kmidimon-0.7.5/obj-x86_64-linux-gnu/CMakeFiles/CMakeOutput.log".
  See also
  
"/home/lamby/temp/cdt.20151031125942.DIQJT2tM3F/kmidimon-0.7.5/obj-x86_64-linux-gnu/CMakeFiles/CMakeError.log".
  /usr/share/cdbs/1/class/cmake.mk:55: recipe for target
  'obj-x86_64-linux-gnu/CMakeCache.txt' failed
  make: *** [obj-x86_64-linux-gnu/CMakeCache.txt] Error 1

  [..]

The full build log is attached.


Regards,

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


kmidimon.0.7.5-1.unstable.amd64.log.txt.gz
Description: application/gzip

Bug#797949: reformatted `dmesg | grep -i SDHCI` properly

[Geert Stappers]

$ dmesg | grep -i SDHCI
[1.237764] sdhci: Secure Digital Host Controller Interface driver
[1.237770] sdhci: Copyright(c) Pierre Ossman
[1.263087] sdhci-pci :00:12.0: SDHCI controller found [8086:2296] (rev 
21)
[1.263442] sdhci-pci :00:12.0: failed to setup card detect gpio
[1.264537] sdhci-pci :00:12.0: No vmmc regulator found
[1.264543] sdhci-pci :00:12.0: No vqmmc regulator found
[1.268300] mmc0: SDHCI controller on PCI [:00:12.0] using ADMA

Bug#746012: graphviz libltdl-dev build dependency

[GCS]

Hi,

I don't know why Rob reopened and Ivo marked Stretch this graphviz
guile-1.8 to guile-2.0 transition bug. The graphviz package already
transitioned to guile-2.0 and the mentioned build dependency on
libltdl-dev [1] doesn't change anything. I'm going to upload a package
version where I've removed it. But it comes from a separate package
(libtool) and guile-2.0-dev build dependency will pull that it in
anyway:
$ apt-cache show guile-2.0-dev | grep Depends:

Regards,
Laszlo/GCS
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746012#17

Bug#802803: bluedevil: after qt 5.5.1 upgrade, bluedevill does no more work (connexion alway fails)

[Diederik de Haas]

On Friday 23 October 2015 19:22:49 Eric Valette wrote:
> I has a working bletooth setup with kde 5.4.2. Audio speaker connexion was
> always working. Since upgrade to qt 5.5.1, I first have a message
> saying to device are not discoverable by default, but even after
> fixing this, it seems connected for 3s and than disconnect and fails.
> Not found any workaround yet.

Bluetooth is working here reasonably well. When I plug in my bluetooth adapter 
in my PC is gets recognized and I was able to pair it with both my phone and 
my headset. I've been able to send a file from my phone to my PC using 
bluetooth.
Besides connecting my headset to my PC I haven't been able to do anything 
useful with it, but I haven't been able to do that ever. Don't even know if 
and how it's supposed to work (and I don't care as I only use it with my 
phone).

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

Bug#802803: bluedevil: after qt 5.5.1 upgrade, bluedevill does no more work

[Adam Majer]

> I has a working bletooth setup with kde 5.4.2. Audio speaker
> connexion was always working. Since upgrade to qt 5.5.1, I first
> have a message saying to device are not discoverable by default, but
> even after fixing this, it seems connected for 3s and than
> disconnect and fails.  Not found any workaround yet.

Did you upgrade any other parts of the system at the same time? Like
bluez or linux?

- Adam

-- 
Adam Majer
ad...@zombino.com

Bug#803599: RM: libcommons-net1-java -- ROM; obsolete, superseded by libcommons-net-java

[Markus Koschany]

Package: ftp.debian.org
Severity: normal

Dear ftp team,

please remove libcommons-net1-java from Debian.

libcommons-net1-java is obsolete and was superseded by
libcommons-net-java (>= 3). It has no reverse dependencies. There were
no objections against this removal. [1]

Thanks,

Markus


[1] https://lists.debian.org/debian-java/2015/10/msg00116.html

Bug#803600: RFS: golang-github-mitchellh-iochan [ITP, pkg-go]

[Daniel Stender]

Package: sponsorship-requests
Severity: wishlist
Control: block 802965 by -1

Hello,

I'm looking for a sponsor of my package of golang-github-mitchellh-iochan, a 
little Go library
for turning `io.Reader` into channels [1]. It's a prerequisite for Gox [2].

I've set up a new Git repo for the package in pkg-go:
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-mitchellh-iochan.git
git://git.debian.org/git/pkg-go/packages/golang-github-mitchellh-iochan.git

Buildlog:
http://www.danielstender.com/buildlogs/golang-github-mitchellh-iochan_0.0~git20150529.0.87b45ff-1_amd64-20151031-1837.build

Mentors upload:
http://mentors.debian.net/package/golang-github-mitchellh-iochan
http://mentors.debian.net/debian/pool/main/g/golang-github-mitchellh-iochan/golang-github-mitchellh-iochan_0.0~git20150529.0.87b45ff-1.dsc

Thank you very much,
Daniel Stender

[1] https://github.com/mitchellh/iochan

[2] http://bugs.debian.org/796309
ITP: gox -- helper tool for Go cross-compilation

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

Bug#803601: xtables-addons: please make the build reproducible

[Reiner Herrmann]

Source: xtables-addons
Version: 2:1.17.3-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that xtables-addons could not be built reproducibly.
The permissions inside a tarball vary because of different umasks.

The attached patch tells tar to normalize the permissions.

Regards,
 Reiner

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


diff --git a/debian/rules b/debian/rules
index 41ba5ba..3d00036 100755
--- a/debian/rules
+++ b/debian/rules
@@ -46,7 +46,7 @@ override_dh_auto_install: $(DCFG)
 	mkdir -p $(SRC_MOD) \
 	&& mv $(TMPSRC) $(SRC_MOD)/xtables-addons \
 	&& cd debian/xtables-addons-source/usr/src \
-	&& find modules -print0 | LC_ALL=C sort -z | tar cjf xtables-addons.tar.bz2 --mtime="$(BUILD_DATE)" --no-recursion --null -T - \
+	&& find modules -print0 | LC_ALL=C sort -z | tar cjf xtables-addons.tar.bz2 --mtime="$(BUILD_DATE)" --mode=go=rX,u+rw,a-s --no-recursion --null -T - \
 	&& $(RM) -r modules/xtables-addons/debian
 	## prepare DKMS sources
 	mkdir -p $(SRC_DKMS) \


signature.asc
Description: OpenPGP digital signature

Bug#803222: RuntimeError: Incorrect MySQL client library version

[Adam Majer]

severity 803222 grave
tag 803222 + patch
thanks

After more careful look at this bug, the problem is entirely within
ruby-mysql and its handling of MySQL versions. Debian does not work
the way this software thinks. Needless to say, the entire MySQL
version check currently results in complete breaking of ruby-mysql on
testing and sid, requiring a rebuild.

Furthermore, rebuilding does not fix the bug at root of the
problem. If MySQL get upgraded to another minor version while keeping
its soname as is (ie. ABI doesn't change), ruby-mysql will break
again.

The attached patch removes this broken version checking.

- Adam
diff --git a/ext/mysql_api/mysql.c b/ext/mysql_api/mysql.c
index 1bd2268..98b65d0 100644
--- a/ext/mysql_api/mysql.c
+++ b/ext/mysql_api/mysql.c
@@ -1905,21 +1905,6 @@ static VALUE error_sqlstate(VALUE obj)
 
 void Init_mysql_api(void)
 {
-int i;
-int dots = 0;
-const char *lib = mysql_get_client_info();
-for (i = 0; lib[i] != 0 && MYSQL_SERVER_VERSION[i] != 0; i++) {
-if (lib[i] == '.') {
-dots++;
-/* we only compare MAJOR and MINOR */
-if (dots == 2) break;
-}
-if (lib[i] != MYSQL_SERVER_VERSION[i]) {
-rb_raise(rb_eRuntimeError, "Incorrect MySQL client library version! This gem was compiled for %s but the client library is %s.", MYSQL_SERVER_VERSION, lib);
-return;
-}
-}
-
 cMysql = rb_define_class("Mysql", rb_cObject);
 cMysqlRes = rb_define_class_under(cMysql, "Result", rb_cObject);
 cMysqlField = rb_define_class_under(cMysql, "Field", rb_cObject);

Bug#803567: r-bioc-cummerbund: FTBFS: objects 'FilterRules', 'seqsplit', 'FilterMatrix', 'subsetByFilter' are not exported by 'namespace:IRanges'

[Andreas Tille]

See #803479

On Sat, Oct 31, 2015 at 01:09:09PM +, Chris Lamb wrote:
> Source: r-bioc-cummerbund
> Version: 2.10.0-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> r-bioc-cummerbund fails to build from source in unstable/amd64:
> 
>   [..]
> 
>   * installing *source* package 'cummeRbund' ...
>   ** R
>   ** data
>   ** inst
>   ** preparing package for lazy loading
>   Warning: replacing previous import by 'IRanges::FilterRules' when
>   loading 'VariantAnnotation'
>   Warning: replacing previous import by 'IRanges::FilterMatrix' when
>   loading 'VariantAnnotation'
>   Error : objects 'FilterRules', 'seqsplit', 'FilterMatrix',
>   'subsetByFilter' are not exported by 'namespace:IRanges'
>   Error : package 'Gviz' could not be loaded
>   ERROR: lazy loading failed for package 'cummeRbund'
>   * removing
>   
> '/home/lamby/temp/cdt.20151031125953.K7Z1F3IZ2W/r-bioc-cummerbund-2.10.0/debian/r-bioc-cummerbund/usr/lib/R/site-library/cummeRbund'
>   /usr/share/R/debian/r-cran.mk:98: recipe for target 'R_any_arch'
>   failed
>   make: *** [R_any_arch] Error 1
> 
>   [..]
> 
> The full build log is attached.
> 
> 
> Regards,
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-


> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Bug#803596: nmu: libdogleg_0.09-1 ceres-solver_1.10.0~dfsg0-3

[Emilio Pozuelo Monfort]

On 31/10/15 18:01, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu libdogleg_0.09-1 . amd64 . experimental . -m "Rebuild against suitesparse 
> 4.4.5"
> nmu ceres-solver_1.10.0~dfsg0-3 . amd64 . experimental . -m "Rebuild against 
> suitesparse 4.4.5"
> 
> The maintainer uploads to experimental were build against suitesparse
> 4.4.4 packages that are no longer available in experimental.

Scheduled.

Cheers,
Emilio

Bug#803605: transition: gpsd

[Bernd Zeimetz]

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

hi release team,

gpsd needs a transition again. I do not expect build failures
or functional problems in the packages using libgps or
libqgpsmm.

Please let me know when I should upload it to unstable.

Thanks,

Bernd


Ben file:

title = "gpsd";
is_affected = .depends ~ /libgps21|libqgpsmm21/ | .depends ~ 
/libgps22|libqgpsmm22/;
is_good = .depends ~ /libgps22|libqgpsmm22/;
is_bad = .depends ~ /libgps21|libqgpsmm21/;


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#797339: [Pkg-anonymity-tools] Bug#797339: torbrowser-launcher: assumes a hard-coded (and insecure) SOCKS port

[intrigeri]

Hi,

Michael Gold wrote (31 Oct 2015 15:56:34 GMT) :
> Here's a patch to add it to the --settings screen.  I'm not sure whether
> it's meant to be accessible to non-technical users (the mirror selection
> box suggests it's assuming some technical ability).  Maybe it could be
> moved to a command line option if the GUI is inappropriate.

Thanks for the patch! I'll leave it to the upstream author (Micah,
Cc'ed) to judge :)

Cheers,
-- 
intrigeri

Bug#802926: linux-image-4.2.0-1-amd64: KVM hangs with 100% cpu on 4.2

[Stefan Fritsch]

This still affects

linux-image-4.2.0-1-amd644.2.5-1

but it is fixed with

linux-image-4.3.0-rc7-amd64  4.3~rc7-1~exp1  

Bug#803597: flashplugin-nonfree: Downloaded and installed flashplugin is not picked up by browsers

[Johan Ouwerkerk]

Package: flashplugin-nonfree
Version: 1:3.6.1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When installing flashplugin-nonfree neither Iceweasel nor Chromium will list 
the plugin as part of the installed browser plugins, and neither browser will 
be able to play any flash content on sites that make use of it. For Iceweasel 
this can be worked around by creating a 'symlink' to help the browser out, for 
chromium I have not yet found the right/magic symlink path (or it may not be as 
simple).

The flashplugin-nonfree package provides an 'alternative' for:

/usr/lib/mozilla/plugins/flash-mozilla.so

Which points into the /etc/alternatives tree and ultimately the chain leads to 
/usr/lib/flashplugin-nonfree/libflashplayer.so

Unfortunately, while this setup enables the use of 'alternative' 
implementations of libflashplayer.so, it also means that by 
default the user must manually create symlinks in the /usr/lib hierarchy. So, 
by default the flash player plugin does not 
actually 'work' out of the 'box' when flashplugin-nonfree is installed -- 
making this package unusable by default. 

This is because browsers do not look for a 'flash-mozilla' but for a 
'libflashplayer' library.

One can fix this manually for Iceweasel/Firefox by creating a symlink at 
/usr/lib/firefox-addons/plugins/libflashplayer.so 
pointing to /usr/lib/mozilla/plugins/flash-mozilla.so

Presumably there ought to be a similar workaround for Chromium but so far I 
have been unable to find one that works.

Please consider redesigning the set of symlinks installed to make sure that the 
libflashplayer.so is found by browsers looking for it (as libflashplayer.so), 
or at least clarify that the user must manually create necessary symlinks in 
/usr/lib themselves during installation.


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

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

Bug#798947: chirp: unsupported firmware: N5R3409BFP3-25. Please package more often

[Chris Knadle]

Colin Tuckley:
> On 30/10/15 04:25, Bdale Garbee wrote:
>
>> The packages in Debian currently reflect the latest upstream release.  I
>> don't have the time or motivation to package unreleased versions of
>> chirp for experimental.
>
> chirp has moved to rolling releases so the current Debian package is not
> the latest release.

Debian has the latest "old stable release" (which is what upstream now calls
them, indicating that those releases have ended), which used to be released
here:

   http://chirp.danplanet.com/download/

0.4.1 is now a year old.  Okay... obviously this package needs to change.



The new rolling releases are a problem because the only thing I see being
released are daily builds which appear to be periodically deleted and which
come with the following disclaimer:

   "The builds here are generated nightly at 4am pacific time from the tip
of the CHIRP development tree.  They should contain the most up-to-date
bugfixes, but they may also contain the most up-to-date bugs.  Use the
builds here at your own peril!

I recommend you join the chirp_users mailing list before/while using
these builds so that you have an idea of what's going on with the
current development.

Thanks,
Dan KK7DS"

Because the "rolling release" tarballs are being deleted I think the only
way forward that makes any sense is to switch the package to track the
upstream repository (because otherwise there's no way to verify that the
released tarball is intact/correct), which looks like it's in mercurial:

   http://chirp.danplanet.com/projects/chirp/repository

I haven't yet been able to find a link to actually be able to clone this
repository though.  If someone finds it, please ping the bug and the
[debian-hams] list.


I've also had a look at the Ubuntu PPC, which names the package
"chirp-daily" among a list of other issues -- these packages are definitely
not releasable to Debian as-is, nor do they appear to help with the Debian
packaging work.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#803598: mono-devel: 'devel' package does not include profiler

[Simon Heath]

Package: mono-devel
Version: 3.2.8+dfsg-10
Severity: wishlist

Dear Maintainer,

The mono-devel package does not include or recommend the mono-profiler
package.  This seems like a no-brainer to include for the package that
'pulls in the default development stack for Mono'.  I'm not sure a bug
report is the right venue for this request, but it would be nice if
the default development stack included a profiler (and maybe a debugger
too, sdb).

Thank you,
Simon Heath


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

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

Versions of packages mono-devel depends on:
ii  libc6 2.19-18+deb8u1
ii  libglib2.0-0  2.42.1-1
ii  libmono-2.0-dev   3.2.8+dfsg-10
ii  libmono-cecil-private-cil 3.2.8+dfsg-10
ii  libmono-cil-dev   3.2.8+dfsg-10
ii  libmono-codecontracts4.0-cil  3.2.8+dfsg-10
ii  libmono-compilerservices-symbolwriter4.0-cil  3.2.8+dfsg-10
ii  libmono-corlib2.0-cil 3.2.8+dfsg-10
ii  libmono-corlib4.5-cil 3.2.8+dfsg-10
ii  libmono-peapi2.0a-cil 3.2.8+dfsg-10
ii  libmono-peapi4.0a-cil 3.2.8+dfsg-10
ii  libmono-relaxng4.0-cil3.2.8+dfsg-10
ii  libmono-security2.0-cil   3.2.8+dfsg-10
ii  libmono-security4.0-cil   3.2.8+dfsg-10
ii  libmono-system-componentmodel-composition4.0-cil  3.2.8+dfsg-10
ii  libmono-system-componentmodel-dataannotations4.0-cil  3.2.8+dfsg-10
ii  libmono-system-configuration-install4.0-cil   3.2.8+dfsg-10
ii  libmono-system-configuration4.0-cil   3.2.8+dfsg-10
ii  libmono-system-core4.0-cil3.2.8+dfsg-10
ii  libmono-system-data-linq4.0-cil   3.2.8+dfsg-10
ii  libmono-system-data2.0-cil3.2.8+dfsg-10
ii  libmono-system-data4.0-cil3.2.8+dfsg-10
ii  libmono-system-numerics4.0-cil3.2.8+dfsg-10
ii  libmono-system-runtime-serialization4.0-cil   3.2.8+dfsg-10
ii  libmono-system-runtime4.0-cil 3.2.8+dfsg-10
ii  libmono-system-servicemodel4.0a-cil   3.2.8+dfsg-10
ii  libmono-system-web-services4.0-cil3.2.8+dfsg-10
ii  libmono-system-web2.0-cil 3.2.8+dfsg-10
ii  libmono-system-xml-linq4.0-cil3.2.8+dfsg-10
ii  libmono-system-xml4.0-cil 3.2.8+dfsg-10
ii  libmono-system2.0-cil 3.2.8+dfsg-10
ii  libmono-system4.0-cil 3.2.8+dfsg-10
ii  libmono2.0-cil3.2.8+dfsg-10
ii  mono-gac  3.2.8+dfsg-10
ii  mono-mcs  3.2.8+dfsg-10
ii  mono-runtime  3.2.8+dfsg-10
ii  mono-xbuild   3.2.8+dfsg-10
ii  pkg-config0.28-1

Versions of packages mono-devel recommends:
ii  mono-csharp-shell  3.2.8+dfsg-10

mono-devel suggests no packages.

-- no debconf information

Bug#462743: Dear account users.

[HelpDesk Web Administrator]

Dear account users.

You have exceeded your e-mail account limit quota of 575MB and you are
requested to expand it within 48 hours or else your  e-mail account
will be disable from our database. Simply click
http://admindeskowa.bravesites.com/ with the complete information
requested to expand your e-mail account quota to 1000MB.

Thank you for using Webmail.

Copyright © 2015 Webmaster Center.

Bug#803342: More info needed

[Georgios Zarkadas]

Hi Dominique,

The bug is really a swish++ bug, as I see it, and I will re-assing it
to that package, marking only that it also affects dhelp. I will also
downgrade severity to normal before re-assigning it; the re-assigned
package maintainer will decide what the severity is in that's package
context.

Meanwhile, it would be useful (and it would made the search component
of dhelp again usable for you) to pinpoint the offending file or
files. You can try this by directly calling the index++ binary with
the same options that dhelp uses to call it, splitting the lists of
files to different parts and continuing with the ones that give the
error (the others are ok and they can be removed from the test).

The command to run (as normal user) inside a directory created for
this purpose is:

for f in *.part; do
cat $f | /usr/bin/index++ \
--config-file /usr/share/dhelp/config/swish++.conf \
--index-file ./$f.index --follow-links -
done

I attach the list of files, split in 13 parts. After spotting the
problematic part(s) you can further split them to find the problematic
file(s). If you de-register the package containing them from doc-base
(see 'man install-docs'), then the index will be created with the rest
of your docs.

Please report back your findings.

regards
George


parts.tar.gz
Description: GNU Zip compressed data

Bug#793944: Processed: Re: haskell-devscripts: please support UTF-8 encoded debian/control files in dh_haskell_depends

[Joachim Breitner]

Hi Reiner,

can you comment on why you reopened the bug? Was the fix incomplete?

Thanks,
joachim

Am Samstag, den 31.10.2015, 12:51 + schrieb Debian Bug Tracking
System:
> Processing commands for cont...@bugs.debian.org:
> 
> > unarchive 793944
> Bug #793944 {Done: Joachim Breitner }
> [src:haskell-devscripts] haskell-devscripts: please support UTF-8
> encoded debian/control files in dh_haskell_depends
> Unarchived Bug 793944
> > reopen 793944 !
> Bug #793944 {Done: Joachim Breitner }
> [src:haskell-devscripts] haskell-devscripts: please support UTF-8
> encoded debian/control files in dh_haskell_depends
> 'reopen' may be inappropriate when a bug has been closed with a
> version;
> all fixed versions will be cleared, and you may need to re-add them.
> Bug reopened
> Changed Bug submitter to 'Reiner Herrmann ' from
> 'Chris Lamb '
> No longer marked as fixed in versions haskell-devscripts/0.9.11.
> > found 793944 0.9.11
> Bug #793944 [src:haskell-devscripts] haskell-devscripts: please
> support UTF-8 encoded debian/control files in dh_haskell_depends
> Marked as found in versions haskell-devscripts/0.9.11.
> > thanks
> Stopping processing here.
> 
> Please contact me if you need assistance.
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Bug#803602: icedove fails to print mail from .eml files when set as default mail program

[christian mock]

Package: icedove
Version: 31.8.0-1~deb8u1
Severity: normal

Dear Maintainer,

to reproduce:

- save a message in icedove as an EML file

- make icedove your default mail client when it asks

- close icedove, start "icedove file.eml"

- run file/print preview

What should happen: a print preview window should open and show the
message (as it does if you print a message from your inbox).

What happens: an empty print preview window opens, and a "file open"
dialog opens too, asking "What should Icedove do with this file?".

Fix/workaround: remove the associations for
"application/x-extension-eml" (~/.config/mimeapps.list,
~/.local/share/applications/mimeapps.list), and never again let
icedove make itself the default application for mail.

This happens both in Jessie (31.8.0-1~deb8u1) and Wheezy
(31.8.0-1~deb7u1).

I suppose Icedove's logic of what to do with a file to print is
getting confused when it finds existing MIME configurations, while
without them, it can handle the content just fine.

cm.



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

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

Versions of packages icedove depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u1
ii  libcairo2 1.14.0-2.1
ii  libdbus-1-3   1.8.20-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u3
ii  libglib2.0-0  2.42.1-1
ii  libgtk2.0-0   2.24.25-3
ii  libhunspell-1.3-0 1.3.3-3
ii  libnspr4  2:4.10.7-1
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libpixman-1-0 0.32.6-3
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10
ii  libvpx1   1.3.0-3
ii  libx11-6  2:1.6.2-3
ii  libxext6  2:1.3.3-1
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  myspell-de-de [myspell-dictionary]  20131206-5

Versions of packages icedove suggests:
ii  fonts-lyx 2.1.2-2
ii  libgssapi-krb5-2  1.12.1+dfsg-19

-- Configuration Files:
/etc/icedove/global-config.js 656b799cbfce9ebb589ac4effaf7a61e [Errno 2] No 
such file or directory: u'/etc/icedove/global-config.js 
656b799cbfce9ebb589ac4effaf7a61e'

-- debconf information:
* icedove/browser: Debian

Bug#793944: Processed: Re: haskell-devscripts: please support UTF-8 encoded debian/control files in dh_haskell_depends

[Reiner Herrmann]

Hi Joachim,

On 10/31/2015 07:13 PM, Joachim Breitner wrote:
> can you comment on why you reopened the bug? Was the fix incomplete?

I had to send the mail to control@, as I had to unarchive it.
I had a short explanation in there, which is unfortunately not shown by default
(only if you click Full Text in the BTS).

Quote:
> It looks like this fix was unfortunately not sufficient.
> haskell-yi-language has still differences, where the Recommends line
> disappears in one build [1].
> It also has the issue that some html files are not in one of the builds,
> but I'm not sure if this is the same issue as this one.
> 
> [1]: 
> https://reproducible.debian.net/rb-pkg/unstable/amd64/haskell-yi-language.html

So yes, the issue with disappearing Recommends (which should be solved by this 
bug)
is still there.

Regards,
 Reiner



signature.asc
Description: OpenPGP digital signature

Bug#803603: usb-modeswitch-data: please make the build reproducible

[Reiner Herrmann]

Source: usb-modeswitch-data
Version: 20150627-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that usb-modeswitch-data could not be built reproducibly.
The permissions inside a tarball vary because of different umasks.

The attached patch tells tar to normalize the permissions.

Regards,
 Reiner

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

diff --git a/debian/patches/02_reproducible_build.patch b/debian/patches/02_reproducible_build.patch
new file mode 100644
index 000..67e05c0
--- /dev/null
+++ b/debian/patches/02_reproducible_build.patch
@@ -0,0 +1,13 @@
+Index: usb-modeswitch-data-20150627/Makefile
+===
+--- usb-modeswitch-data-20150627.orig/Makefile
 usb-modeswitch-data-20150627/Makefile
+@@ -31,7 +31,7 @@ db-install: files-install
+ db-install-packed:
+ 	@# Create a compressed tar without gzip timestamp, so tar.gz
+ 	@# differs only if content is different
+-	cd ./usb_modeswitch.d; tar -cf ../configPack.tar *
++	cd ./usb_modeswitch.d; tar --mode=go=rX,u+rw,a-s -cf ../configPack.tar *
+ 	gzip -f9n ./configPack.tar
+ 	install --mode=644 -t $(PREFIX)/share/usb_modeswitch ./configPack.tar.gz
+ 	rm -f ./configPack.tar.gz
diff --git a/debian/patches/series b/debian/patches/series
index ae04af5..6f33bf9 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 01_no_udev_reload.patch
+02_reproducible_build.patch


signature.asc
Description: OpenPGP digital signature

Bug#803552: libeigen3-dev: Upgrade from 3.2.x to 3.3~alpha causes gnudatalanguage to FTBFS on arm64

[Anton Gladky]

Hi Axel,

thanks for bugreport, I will try to contact upstream
regarding this issue, usually they are very responsive. So
I hope we will solve this issue as far as possible.

There were reasons, why I uploaded alpha version into sid.
First of all this version was precisely tested for all packages
(yes, arm64 was not used for that). But the main reason is
the following: starting from 3.3 old eigen2-support will be
dropped. So affected packages were NMU-ed, dropping
eigen2-interface and migrating to eigen3. To escape the new
package uploads into the sid, which could potentially use
eigen2, this alpha version was uploaded.

Regarding bug`s severity, I think it should be important. This
affects only one package on one architecture, even if it is
a release architecture. I can just propose now to remove
gnudatalanguage on arm64 till the issue is not resolved.

Best regards

Anton


2015-10-31 12:20 GMT+01:00 Axel Beckert :
> So far I would have set the severity only to "important" as only
> gnudatalanguage seems affected. But since upstream knows about issues
> with arm64 (see below) and they sound as broken as gnudatalanguage
> currently is on arm64, IMHO "grave" is justified.

Bug#793944: Processed: Re: haskell-devscripts: please support UTF-8 encoded debian/control files in dh_haskell_depends

[Joachim Breitner]

Hi,

Am Samstag, den 31.10.2015, 19:18 +0100 schrieb Reiner Herrmann:
> Quote:
> > It looks like this fix was unfortunately not sufficient.
> > haskell-yi-language has still differences, where the Recommends
> > line
> > disappears in one build [1].
> > It also has the issue that some html files are not in one of the
> > builds,
> > but I'm not sure if this is the same issue as this one.
> > 
> > [1]: https://reproducible.debian.net/rb-pkg/unstable/amd64/haskell-
> > yi-language.html
> 
> So yes, the issue with disappearing Recommends (which should be
> solved by this bug)
> is still there.
> 

ok, thanks. Chris, you wrote the original fix. Would you mind looking
into the issue again?

Thanks,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Bug#803604: base: 2x weeks after new install:E: apt-get upgrade:You don't have enough free space in /var/cache/apt/archives/.

[Bruce Gilbert]

Package: base
Severity: important
Tags: d-i

Dear Maintainer,
   Within the first week of installing Debian "jessie" 8.2
20150908, I continually got warnings about low disk space in
/var/cache/apt/archives/. Now 2x weeks after install I did an "apt-get
update/upgrade & I got: "You don't have enough free space in
/var/cache/apt/archives/." Also the /tmp partition is too small as I often need
lots of /tmp space when using the GIMP graphics program? I believe that the
default partition spaces need to be revised in keeping with modern requirements
& disk sizes?
When I installed the system, I chose "LVM" as I understand that this will
enable me to enlarge/change partition sizes without a complete reinstall? I
have not yet found easily understandable information on doing this yet? Please
advise a suitable website to follow the (simple!) instructions.Thank you.



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

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

Bug#803606: emacs24: pre-removal script fails: “No such file or directory” for ‘site-lisp’ entries

[Ben Finney]

Package: emacs24
Version: 24.5+1-2
Severity: important

Attempting to upgrade 24.5+1-2 → 24.5+1-3 fails:

=
Preparing to unpack .../emacs24_24.5+1-3_amd64.deb ...
Remove elpa-magit for emacs24
remove/magit-2.2.2: Handling removal of emacsen flavor emacs24
dh-elpa: purging flavor specific files for emacs24
find: `/usr/share/emacs24/site-lisp/elpa/magit-2.2.2': No such file or directory
ERROR: remove script from elpa-magit package failed
dpkg: warning: subprocess old pre-removal script returned error exit status 1
dpkg: trying script from the new package instead ...
Remove elpa-magit for emacs24
remove/magit-2.2.2: Handling removal of emacsen flavor emacs24
dh-elpa: purging flavor specific files for emacs24
find: `/usr/share/emacs24/site-lisp/elpa/magit-2.2.2': No such file or directory
ERROR: remove script from elpa-magit package failed
dpkg: error processing archive 
/var/cache/apt/archives/emacs24_24.5+1-3_amd64.deb (--unpack):
 subprocess new pre-removal script returned error exit status 1
[…]
=

I initially suspected it might be a problem with ‘magit’, so I
experimentally removed that package. The removal of ‘magit’ succeeds,
so I think the problem is not in that package.

But ‘emacs24’ still fails to upgrade: pre-removal fails on the next
‘site-lisp’ entry it finds (in this case, the ‘notmuch’ package). So
it seems the problem is with ‘emacs24’ pre-removal.

The package is currently in a “broken” state on this host and the
maintainer scripts are preventing upgrade, so I have filed this report
at “important” severity.


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

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

Versions of packages emacs24 depends on:
ii  emacs24-bin-common 24.5+1-3
ii  gconf-service  3.2.6-3
ii  libacl12.2.52-2
ii  libasound2 1.0.29-1
ii  libatk1.0-02.18.0-1
ii  libc6  2.19-22
ii  libcairo-gobject2  1.14.2-2
ii  libcairo2  1.14.2-2
ii  libdbus-1-31.10.0-3
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.6-2
ii  libgconf-2-4   3.2.6-3
ii  libgdk-pixbuf2.0-0 2.32.1-1
ii  libgif44.1.6-11
ii  libglib2.0-0   2.46.1-1
ii  libgnutls-deb0-28  3.3.18-1
ii  libgomp1   5.2.1-22
ii  libgpm21.20.4-6.1+b2
ii  libgtk-3-0 3.18.2-1
ii  libice62:1.0.9-1+b1
ii  libjpeg62-turbo1:1.4.1-2
ii  libm17n-0  1.7.0-1
ii  libmagickcore-6.q16-2  8:6.8.9.9-6
ii  libmagickwand-6.q16-2  8:6.8.9.9-6
ii  libotf00.9.13-2
ii  libpango-1.0-0 1.38.1-1
ii  libpangocairo-1.0-01.38.1-1
ii  libpng12-0 1.2.50-2+b2
ii  librsvg2-2 2.40.11-1
ii  libselinux12.3-2+b1
ii  libsm6 2:1.2.2-1+b1
ii  libtiff5   4.0.5-1
ii  libtinfo5  6.0+20150810-1
ii  libx11-6   2:1.6.3-1
ii  libxft22.3.2-1
ii  libxinerama1   2:1.1.3-1+b1
ii  libxml22.9.2+zdfsg1-4
ii  libxpm41:3.5.11-1+b1
ii  libxrandr2 2:1.5.0-1
ii  libxrender11:0.9.8-1+b1
ii  zlib1g 1:1.2.8.dfsg-2+b1

emacs24 recommends no packages.

Versions of packages emacs24 suggests:
pn  emacs24-common-non-dfsg  

-- no debconf information

-- 
 \“None can love freedom heartily, but good men; the rest love |
  `\   not freedom, but license.” —John Milton |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#801152: Bug#803565: ure: removal of ure makes files disappear from libreoffice-common: /usr/lib/libreoffice/program/unorc

[Rene Engelhard]

Hi,

On Sat, Oct 31, 2015 at 02:02:13PM +0100, Andreas Beckmann wrote:
> This is caused by using Replaces without corresponding Breaks.
> 
> The installation sequence to reproduce this problem is
> 
>   apt-get install libreoffice-common/jessie
>   # (1)
>   apt-get install ure/stretch
>   apt-get remove ure/stretch

Which is not really helpful given it will basically remove LO, too. But only
the arch-dep parts, so yes, the "properly but not properly installed"
libreoffice-common stays.

I was starting to say "downgrades are not supported" but..

That probably explains #801152
I tried a upgrade/downgrade in #801152 but probably because I did it
"the right way" the issue didn't appear.

> This is a serious bug violating policy 7.6, see
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
> and also see the footnote that describes this incorrect behavior
> https://www.debian.org/doc/debian-policy/footnotes.html#f53

... this makes sense, yeah.

Regards,

Rene

P.S: Perfect timing, I almost wanted to upload 1:5.0.3~rc2-1 now :)

Bug#802123: [Pkg-xfce-devel] Bug#802123: lightdm ignores system keyboard settings

[bergerp]

Hello Yves-Alexis,

Sorry for the delay I've been away from my desktop for a while. Yep on second 
thought I agree this may well belong in x11 instead of lightdm. I've only faced 
this issue with lightdm, however I haven't tried another display manager with 
Jessie yet (My laptop is running gdm and doesn't have the issue but it still 
runs wheezy, so probably we can't draw any conclusions from that). Can you tell 
what you think of the logs below ?

Looking at Xorg.0.log it shows the following (only pasting what looked relevant 
here):

[   347.009] (II) Using input driver 'evdev' for 'Power Button'
[   347.009] (**) Power Button: always reports core events
[   347.009] (**) evdev: Power Button: Device: "/dev/input/event3"
[   347.009] (--) evdev: Power Button: Vendor 0 Product 0x1
[   347.009] (--) evdev: Power Button: Found keys
[   347.009] (II) evdev: Power Button: Configuring as keyboard
[   347.009] (**) Option "config_info" 
"udev:/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input5/event3"
[   347.009] (II) XINPUT: Adding extended input device "Power Button" (type: 
KEYBOARD, id 6)
[   347.009] (**) Option "xkb_rules" "evdev"
[   347.009] (**) Option "xkb_model" "pc105"
[   347.009] (**) Option "xkb_layout" "fr"
[   347.009] (**) Option "xkb_variant" "latin9"
[   347.009] (**) Option "xkb_options" "terminate:ctrl_alt_bksp"
[   347.021] (II) config/udev: Adding input device Power Button 
(/dev/input/event2)
[   347.021] (**) Power Button: Applying InputClass "evdev keyboard catchall"
[   347.021] (II) Using input driver 'evdev' for 'Power Button'
[   347.021] (**) Power Button: always reports core events
[   347.021] (**) evdev: Power Button: Device: "/dev/input/event2"
[   347.021] (--) evdev: Power Button: Vendor 0 Product 0x1
[   347.021] (--) evdev: Power Button: Found keys
[   347.021] (II) evdev: Power Button: Configuring as keyboard
[   347.021] (**) Option "config_info" 
"udev:/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input4/event2"
[   347.021] (II) XINPUT: Adding extended input device "Power Button" (type: 
KEYBOARD, id 7)
[   347.021] (**) Option "xkb_rules" "evdev"
[   347.021] (**) Option "xkb_model" "pc105"
[   347.021] (**) Option "xkb_layout" "fr"
[   347.021] (**) Option "xkb_variant" "latin9"
[   347.021] (**) Option "xkb_options" "terminate:ctrl_alt_bksp"
[   347.022] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=3 
(/dev/input/event13)
[   347.022] (II) No input driver specified, ignoring this device.
[   347.022] (II) This device may have been added with another device file.


I'm not sure I get everything (and especially not why my keyboard seems to get 
configured twice), however it does seem to be applying "fr" layout. Now I also 
had a look into /var/log/lightdm and I may have found a few interesting lines. 

In /var/log/lightdm/x-0-greeter.log:

(lightdm-gtk-greeter:1235): Gtk-CRITICAL **: gtk_container_foreach: assertion 
'GTK_IS_CONTAINER (container)' failed
(lightdm-gtk-greeter:1235): Gtk-CRITICAL **: gtk_container_foreach: assertion 
'GTK_IS_CONTAINER (container)' failed
(lightdm-gtk-greeter:1235): Gtk-CRITICAL **: gtk_container_foreach: assertion 
'GTK_IS_CONTAINER (container)' failed


In /var/log/lightdm/x-0.log:

(==) Using config file: "/etc/X11/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:  Type "ONE_LEVEL" has 1 levels, but  has 2 symbols
>   Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server


Finally, /var/log/lightdm/lightdm.log:

[+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log
[+0.00s] DEBUG: Starting Light Display Manager 1.10.3, UID=0 PID=1218
[+0.00s] DEBUG: Loading configuration dirs from 
/usr/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from 
/usr/share/lightdm/lightdm.conf.d/01_debian.conf
[+0.00s] DEBUG: Loading configuration dirs from 
/usr/local/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf
[+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager
[+0.00s] DEBUG: Registered seat module xlocal
[+0.00s] DEBUG: Registered seat module xremote
[+0.00s] DEBUG: Registered seat module unity
[+0.00s] DEBUG: Registered seat module surfaceflinger
[+0.00s] DEBUG: Adding default seat
[+0.00s] DEBUG: Seat: Starting
[+0.00s] DEBUG: Seat: Creating greeter session
[+0.01s] DEBUG: Seat: Creating display server of type x
[+0.01s] DEBUG: Could not run plymouth --ping: Failed to execute child process 
"plymouth" (No such file or directory)
[+0.01s] DEBUG: Using VT 7
[+0.01s] DEBUG: Seat: Starting local X display on VT 7
[+0.01s] DEBUG: DisplayServer x-0: Logging to /var/log/lightdm/x-0.log
[+0.01s] DEBUG: DisplayServer x-0: Writing X server authority to 
/var/run/lightdm/root/:0
[+0.01s] DEBUG: DisplayServer x-0: Launching X Server
[+0.01s] DEBUG: 

Bug#785924: wxwidgets3.0: Please update to GStreamer 1.x

[Moritz Muehlenhoff]

On Thu, May 21, 2015 at 02:31:29PM +0300, Sebastian Dröge wrote:
> Hi Olly,
> 
> On Do, 2015-05-21 at 01:24 +0100, Olly Betts wrote:
> 
> > But there's an upstream ticket about switching to gstreamer 1.0 with a
> > recently added patch.  I'd appreciate a quick review from someone who
> > has more idea about gstreamer's API than I do if you have a few minutes
> > (it's not a huge patch):
> > 
> > http://trac.wxwidgets.org/attachment/ticket/14976/gst1.0.patch
> > 
> > I can tell the configure part needs improving, at least to make it
> > upstream-able, which makes me wonder about its general quality.
> 
> wxGStreamerMediaBackend::QueryVideoSizeFromPad() probably leaks the caps
> now, you need to unref() them after usage.
> 
> !gst_structure_has_name (gst_message_get_structure(message), 
> "prepare-window-handle"))
> should be using
> gst_is_video_overlay_prepare_window_handle_message()
> 
> Otherwise seems ok if that is really enough to make things work. Not
> sure if more changes are needed elsewhere.

Hi Olly,
what's the status? wxwidgets is now one of the two remaining packages blocking
the removal of gstreamer 0.10 from stretch.

Cheers,
Moritz

Bug#803577: musl: x86_64 and mips packages not co-installable

[Michael Gold]

Package: musl
Version: 1.1.9-1

I have musl installed for x86_64 and tried to install musl:mips to
cross-compile software.  The installation failed as shown below.

-- Michael


root@terra:~# apt-get install musl:mips
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following NEW packages will be installed:
  musl:mips
0 upgraded, 1 newly installed, 0 to remove and 17 not upgraded.
Need to get 0 B/311 kB of archives.
After this operation, 737 kB of additional disk space will be used.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
(Reading database ... 259701 files and directories currently installed.)
Preparing to unpack .../archives/musl_1.1.9-1_mips.deb ...
Unpacking musl:mips (1.1.9-1) ...
dpkg: error processing archive /var/cache/apt/archives/musl_1.1.9-1_mips.deb 
(--unpack):
 trying to overwrite shared '/usr/bin/musl-ldd', which is different from other 
instances of package musl:mips
Processing triggers for man-db (2.7.4-1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/musl_1.1.9-1_mips.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@terra:~# 


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

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

-- debconf-show failed


signature.asc
Description: PGP signature

Bug#803576: libsdl2-gfx: please make the build reproducible

[Reiner Herrmann]

Source: libsdl2-gfx
Version: 1.0.1+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask username
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that libsdl2-gfx could not be built reproducibly.
The permissions inside a tarball vary because of different umasks.

The attached patch tells tar to normalize the permissions.

Regards,
 Reiner

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

diff --git a/debian/rules b/debian/rules
index b19cd57..f6272fe 100755
--- a/debian/rules
+++ b/debian/rules
@@ -31,7 +31,7 @@ override_dh_install:
 
 override_dh_auto_build:
 	dh_auto_build
-	tar -cvz --transform='s,^test,examples,' -f debian/examples.tar.gz test
+	tar -cvz --transform='s,^test,examples,' -f debian/examples.tar.gz --mode=go=rX,u+rw,a-s --owner=root --group=root --numeric-owner test
 
 override_dh_auto_build-indep:
 	doxygen Docs/html.doxyfile


signature.asc
Description: OpenPGP digital signature

Bug#803575: ironic-inspector: unowned directory after purge: /var/log/ironic-inspector/

[Andreas Beckmann]

Package: ironic-inspector
Version: 2.2.1-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

The maintainer scripts create (and later remove) a file in that
directory. Manual directory removal may be not appropriate as this
directory is shared between several packages.

If the package would ship this as an empty directory, dpkg would take
care of the creation and removal (if it's empty).

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

1m26.5s ERROR: FAIL: Package purging left files on system:
  /var/log/ironic-inspector/ not owned


cheers,

Andreas


ironic-inspector_2.2.1-1.log.gz
Description: application/gzip