Bug#747920: ITP: libdatabase-dumptruck -- document-oriented interface to a SQLite database

[gregor herrmann]

On Tue, 13 May 2014 12:13:21 +1200, Chris Bannister wrote:

> On Tue, May 13, 2014 at 12:56:34AM +0200, Lubomir Rintel wrote:

> > * Package name: libdatabase-dumptruck
> >   Version : 1.2
> >   Upstream Author : Lubomir Rintel 
> > * URL : https://metacpan.org/release/Database-DumpTruck
> > * License : Artistic or GPL-1+
> >   Programming Lang: Perl
> >   Description : document-oriented interface to a SQLite database

> Shouldn't the package name be "libdatabase-dumptruck-perl"?

Good catch.

Luckily the preliminary package has the right name already :)
http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libdatabase-dumptruck-perl.git

Cheers,
gregor 

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   BOFH excuse #189:  SCSI's too wide. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747933: libc6-dev: Recommends: (gcc | c-compiler) is problematic with cross-compilers

[Dima Kogan]

Package: libc6-dev
Version: 2.18-4
Severity: normal

Hi. Currently the libc6-dev package is

 Recommends: gcc | c-compiler

This is fine with native compilers. However, if I'm on an amd64 host,
and I try to install libc6-dev:armel with intent to use it with a
cross-compiler that targets armel, this recommendation is wrong.

By default, apt wants to install the Recommends, so if using aptitude to
install libc6-dev:armel, aptitude will try to install gcc:armel, which
clashes with gcc:amd64, since gcc is not Multi-Arch:same. Aptitude then
really tries to make that work by proposing to remove gcc in various
ways. You have to resolve this manually. This is arguably a deficiency
in aptitude, but maybe this Recommends can be loosened.

I don't believe Debian has any way to specify a Multi-Arch:foreign
virtual package (so the cross-compiler can't satisfy the c-compiler part
of this). Can we downgrade this Recommends to a Suggests, or maybe
remove it entirely? The user who installs libc6-dev likely already has a
compiler, and doesn't really benefit from this Recommends.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747911: New packages build by kernel-package depending on initramfs-tools even if the kernel is not using initram

[Klaus Ethgen]

Am Mo den 12. Mai 2014 um 23:18 schrieb Manoj Srivastava:
> > Newly build kernel depending on "initramfs-tools |
> > linux-initramfs-tool" even if the kernel does not use initram and have
> > no support for initramfs.
> 
> This should be harmless.  Whether or not you have these packages
>  installed should not change the behaviour, and a user can reasonably
>  expect to have initrd and non-initrd kernels on the same machine.

I'd like to only have needed packages installed and this is not.
Moreover, it brings more dependencies that are not needed.

The right way would be a recommend in this case, not a hard dependency.
Or even better, only have the dependency when the kernel need a initrd.

The dependency line from a kernel build with earlier version:
   Depends: coreutils (>= 5.96)

And with the current version:
   Depends: coreutils (>= 5.96), initramfs-tools | linux-initramfs-tool

The later one is wrong. Both kernels have the same configuration and
both have no support for initram.

> > As the build of initramfs is forced even in that cases and grub is
> > forced to use it, I think the severity of the bug is even higher as it
> > might prevent system from booting.
> 
> This is the bug.  If you did not use make-kpkg --initrd 
>  your kernel image postinst should have $initrd not equal to Yes; and
>  the postinst should export INITRD = No to the environment before
>  calling the postint.d.
> 
> Could you please attach the kernel image postinst file? Also, a
>  log of the installation run migh help.

I have no log but the postinst is attached to this mail.

> > Please revert the change to only depend and build initram fs if the
> > kernel need it and has support for it.
> 
> We always depended on intramfs tools; but the ones we depended
>  on became obsolete. But, since a use may have initramfs tools installed
>  anyway, this is not a solution.

As you see above, that is not true. With old kernel-package there was
only dependency to initramfs tool if a initram is in use.

Regards
   Klaus
-- 
Klaus Ethgen  http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
#! /usr/bin/perl
#  -*- Mode: Cperl -*-
# debian.postinst ---
# Author   : Manoj Srivastava ( sriva...@pilgrim.umass.edu )
# Created On   : Sat Apr 27 05:55:26 1996
# Created On Node  : melkor.pilgrim.umass.edu
# Last Modified By : Manoj Srivastava
# Last Modified On : Mon Apr 13 14:24:43 2009
# Last Machine Used: anzu.internal.golden-gryphon.com
# Update Count : 362
# Status   : Unknown, Use with caution!
# HISTORY  :
# Description  :
#
#$Id: image.postinst,v 1.125 2003/10/07 16:24:20 srivasta Exp $
#

#
#use strict; #for debugging
use Cwd 'abs_path';
use Debconf::Client::ConfModule qw(:all);
version('2.0');
my $capb = capb("backup");

$| = 1;

# Predefined values:
my $version   = "3.13.10";
my $move_image= ''; # target machine defined
my $kimage= "vmlinuz";   # Should be empty, mostly
my $image_dir = "/boot";   # where the image is located
my $clobber_modules   = ''; # target machine defined
my $initrd= "";   # initrd kernel
my $postinst_hook = ''; #Normally we do not
my $postrm_hook   = ''; #Normally we do not
my $preinst_hook  = ''; #Normally we do not
my $prerm_hook= ''; #Normally we do not
my $ignore_depmod_err = ''; # normally we do not
my $relink_src_link   = 'YES';  # There is no harm in checking the link
my $relink_build_link = 'YES';  # There is no harm in checking the link
my $force_build_link  = ''; # There is no harm in checking the link
my $arch  = "amd64";   #  should be same as dpkg 
--print-architecture
my $kernel_arch   = "x86_64";
my $package_name   = "linux-image-$version";
my $kernel_pkg_version = "13.007";

#known variables
my $image_dest = "/";
my $realimageloc   = "/$image_dir/";
my $have_conffile  = "";
my $silent_modules = '';
my $warn_reboot= 'Yes'; # Warn that we are installing a version of
# the kernel we are running

my $modules_base = '/lib/modules';
my $CONF_LOC = '/etc/kernel-img.conf';

# Ignore all invocations except when called on to configure.
exit 0 unless $ARGV[0] =~ /configure/;

my $DEBUG = 0;

# Do some preliminary sanity checks here to ensure we actually have an
# valid image dir
chdir('/') or die "could not chdir to /:$!\n";
die "Internal Error: ($image_dir) is not a directory!\n"
  unless -d $image_dir;

# remove multiple leading slashes; make sure there is at least one.
$realimageloc =~ s|^/*|/|o;
$realimageloc =~ s|/+|/|o;
die "Internal Error: ($realimageloc) is not a directory!\n"
  unless -d $realimageloc;

if ( -r "$CONF_LOC" && -f "$CONF_LOC" ) {
  if ( open( CONF, "$CONF_LOC" ) ) {
while () {
  chomp;
  s/\

Bug#747932: ITP: nft-sync -- nftables ruleset synchronization software

[Arturo Borrero Gonzalez]

Package: wnpp
Severity: wishlist

* Package name: nft-sync
* Version: 0.1-alpha
* Upstream Author: Pablo Neira Ayuso 
* URL : http://git.netfilter.org/nft-sync/
* License: AGPL3
* Description:

nft-sync is a tool to work with nftables in distributed environments.
In a firewall cluster, it allows you to keep your filtering policy in sync.
If spread firewall environment, you can use the repository mode, and
each client will contact
the nft-sync server and fetch/pull the ruleset.

-- 
Arturo Borrero González


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747920: ITP: libdatabase-dumptruck-perl -- document-oriented interface to a SQLite database

[Lubomir Rintel]

Package: wnpp
Severity: wishlist
Owner: Debian Perl Group 
Control: retitle -1 ITP: libdatabase-dumptruck-perl -- document-oriented
interface to a SQLite database
Control: summary -1 0

* Package name: libdatabase-dumptruck-perl
  Version : 1.2
  Upstream Author : Lubomir Rintel 
* URL : https://metacpan.org/release/Database-DumpTruck
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : document-oriented interface to a SQLite database

Database::DumpTruck is a simple document-oriented interface to a SQLite
database, modelled after Scraperwiki's Python dumptruck module. It
allows for easy (and maybe inefficient) storage and retrieval of
structured data to and from a database without interfacing with SQL. The
module attempts to identify the type of the data you're inserting and
uses an appropriate SQLite type.

I am packaging this so that it's conventiently available for use with
Morph  web scraping engine. It will be maintained by
the perl packaging team and needs a sponsor.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#685506: marked as done (copyright-format: new Files-Excluded field)

[Andreas Tille]

On Tue, May 13, 2014 at 08:24:46AM +0900, Charles Plessy wrote:
> I think that you closed the wrong bug: this one is about documenting the
> Files-Excluded field in the specification of machine-readable debian/copyright
> files, which is probably the next thing to do now that it has been implemented
> in devscripts.

Ahhh, thanks for watching us.  I added a line to

   https://wiki.debian.org/UscanEnhancements

explaining the nature of this bug.

Kind regards

  Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745706: sysdig: Group-accessible /dev/sysdig0

[Evgeni Golov]

Hi,

On Thu, Apr 24, 2014 at 01:19:28AM -0700, Dima Kogan wrote:

> It would be nice if /dev/sysdig* was owned by a group that isn't root.
> Then a properly-grouped non-root user can sysdig without sudo.

Upstream says [1] having access to /dev/sysdig is not enough, as you 
need access to /proc too [2]. I am therefore tagging this bug as wontfix 
for now as I do not want to implement halfworking things against 
upstreams will.

Greets
Evgeni

[1] https://github.com/draios/sysdig/issues/156
[2] 
https://github.com/draios/sysdig/wiki/How%20to%20Install%20Sysdig%20for%20Linux#use-sysdig-as-non-root


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#746900: qtdeclarative-opensource-src: ftbfs with GCC-4.9

[Yunqiang Su]

The attachment is build log of mips64el.

On mips64el, beside the same gcc-4.9 problem,
there are some more problems.

With this patch, I can build it on both amd64, mips64el, and i386.
While it still has some warnings.
I think that we should try to build it on experimental to determine the symbols
for archs.

on amd64: no warnings
on mips64el

--- debian/libqt5quickparticles5.symbols
(libqt5quickparticles5_5.2.1-5+mips64.1_mips64el)
+++ dpkg-gensymbolsGKlBFe 2014-05-13 14:02:42.189846293 +
@@ -1,5 +1,6 @@
 libQt5QuickParticles.so.5 libqt5quickparticles5 #MINVER#
 | libqt5quickparticles5 #MINVER#, qtdeclarative-abi-5-2-1
+ _ZN10QByteArray7reserveEi@Base 5.2.1-5+mips64.1
  (optional=templinst|arch=ia64
sparc)_ZN11QMetaMethod10fromSignalIM18QQuickTrailEmitterFv12QQmlV4HandleS2_EEES_T_@Base
5.2.0 1
  (optional=templinst|arch=ia64
sparc)_ZN11QMetaMethod10fromSignalIM20QQuickCustomAffectorFv12QQmlV4HandledEEES_T_@Base
5.2.0 1
  (optional=templinst|arch=ia64
sparc)_ZN11QMetaMethod10fromSignalIM21QQuickParticleEmitterFv12QQmlV4HandleEEES_T_@Base
5.2.0 1


on i386:
dpkg-gensymbols: warning: some new symbols appeared in the symbols
file: see diff output below
dpkg-gensymbols: warning: debian/libqt5qml5/DEBIAN/symbols doesn't
match completely debian/libqt5qml5.symbols
--- debian/libqt5qml5.symbols (libqt5qml5_5.2.1-5+mips64.1_i386)
+++ dpkg-gensymbolsvlHWhi 2014-05-13 05:56:04.078015536 +
@@ -353,6 +353,9 @@
  _ZN13QQmlValueType16staticMetaObjectE@Base 5.0.2 1
  _ZN13QQmlValueTypeC1EiP7QObject@Base 5.0.2 1
  _ZN13QQmlValueTypeC2EiP7QObject@Base 5.0.2 1
+ _ZN13QQmlValueTypeD0Ev@Base 5.2.1-5+mips64.1
+ _ZN13QQmlValueTypeD1Ev@Base 5.2.1-5+mips64.1
+ _ZN13QQmlValueTypeD2Ev@Base 5.2.1-5+mips64.1
  _ZN14QQmlExpression10clearErrorEv@Base 5.0.2
  _ZN14QQmlExpression11qt_metacallEN11QMetaObject4CallEiPPv@Base 5.0.2
  _ZN14QQmlExpression11qt_metacastEPKc@Base 5.0.2
@@ -2234,6 +2237,7 @@
  _ZN8QQmlTypeD2Ev@Base 5.0.2 1
  (optional=templinst|arch=ia64)_ZN8QVariant9fromValueIP9ListModelEES_RKT_@Base
5.2.0
  (arch=alpha armel mips mipsel powerpc ppc64
s390x)_ZN9QBitArray6setBitEi@Base 5.2.1
+ _ZN9QBitArray8clearBitEi@Base 5.2.1-5+mips64.1
  _ZN9QJSEngine10newQObjectEP7QObject@Base 5.0.2
  _ZN9QJSEngine11qt_metacallEN11QMetaObject4CallEiPPv@Base 5.0.2
  _ZN9QJSEngine11qt_metacastEPKc@Base 5.0.2
@@ -2804,6 +2808,7 @@
  (optional=templinst|arch=ia64
sparc)_ZNSt6vectorIN3JSC4Yarr8ByteTermESaIS2_EE13_M_insert_auxIIRKS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
5.2.0
  (optional=templinst|arch=ia64
sparc|subst)_ZNSt6vectorIN3JSC4Yarr8ByteTermESaIS2_EE7reserveE{size_t}@Base
5.2.0
  
(optional=templinst|subst)_ZNSt6vectorIS_IiSaIiEESaIS1_EE17_M_default_appendE{size_t}@Base
5.2.1
+ _ZNSt6vectorIcSaIcEE17_M_default_appendEj@Base 5.2.1-5+mips64.1
  (optional=templinst|arch=ia64
sparc)_ZNSt6vectorIiSaIiEE13_M_insert_auxIIRKiEEEvN9__gnu_cxx17__normal_iteratorIPiS1_EEDpOT_@Base
5.2.1
  
(optional=templinst|subst)_ZNSt6vectorIiSaIiEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPiS1_EE{size_t}RKi@Base
5.2.1
  (optional=templinst|arch=!ia64
!sparc)_ZNSt6vectorIiSaIiEE19_M_emplace_back_auxIIRKiEEEvDpOT_@Base
5.2.1
@@ -2821,7 +2826,9 @@
  (arch=alpha amd64 armel armhf hurd-i386 i386 kfreebsd-amd64
kfreebsd-i386 mips mipsel mips64 mips64el powerpc ppc64
s390x)_ZNSt6vectorItSaItEE13_M_insert_auxIJRKtEEEvN9__gnu_cxx17__normal_iteratorIPtS1_EEDpOT_@Base
5.2.0
  (arch=alpha amd64 armel armhf hurd-i386 i386 kfreebsd-amd64
kfreebsd-i386 mips mipsel mips64 mips64el powerpc ppc64
s390x)_ZNSt6vectorItSaItEE13_M_insert_auxIJtEEEvN9__gnu_cxx17__normal_iteratorIPtS1_EEDpOT_@Base
5.2.0
  (arch=alpha amd64 armel armhf hurd-i386 i386 kfreebsd-amd64
kfreebsd-i386 mips mipsel mips64 mips64el powerpc ppc64
s390x)_ZNSt6vectorItSaItEE19_M_emplace_back_auxIIRKtEEEvDpOT_@Base
5.2.0
+ _ZNSt6vectorItSaItEE19_M_emplace_back_auxIItEEEvDpOT_@Base 5.2.1-5+mips64.1
  (arch=alpha amd64 armel armhf hurd-i386 i386 kfreebsd-amd64
kfreebsd-i386 mips mipsel mips64 mips64el powerpc ppc64
s390x)_ZNSt6vectorItSaItEE19_M_emplace_back_auxIJRKtEEEvDpOT_@Base
5.2.0
+ _ZNSt6vectorItSaItEE19_M_emplace_back_auxIJtEEEvDpOT_@Base 5.2.1-5+mips64.1
  (optional=templinst|arch=ia64
sparc)_ZNSt6vectorItSaItEE6insertEN9__gnu_cxx17__normal_iteratorIPtS1_EERKt@Base
5.2.0
  
(optional=templinst|arch=sparc)_ZSt11__push_heapIN5QListI4QUrlE8iteratorEiS1_N12QQmlSequenceIS2_E14CompareFunctorEEvT_T0_S8_T1_T2_@Base
5.2.0 1
  
(optional=templinst|arch=sparc)_ZSt11__push_heapIN5QListI4QUrlE8iteratorEiS1_N12QQmlSequenceIS2_E21DefaultCompareFunctorEEvT_T0_S8_T1_T2_@Base
5.2.0 1
@@ -2868,8 +2875,10 @@
  
(optional=templinst|arch=ia64)_ZSt13__adjust_heapIN5QListIiE8iteratorExiEvT_T0_S4_T1_@Base
5.2.0 1
  
(optional=templinst|arch=ia64)_ZSt13__adjust_heapIN5QListIiE8iteratorExiN12QQmlSequenceIS1_E14CompareFunctorEEvT_T0_S7_T1_T2_@Base
5.2.0 1
  
(optional=templinst|arch=ia64)_ZSt13__adjust_heapIN5QListIiE8iteratorExiN12QQmlSequenceIS1_E21DefaultCompareFunctorEEvT_T0_S7_T1_T2_@Base
5.2.0 1
+ _ZS

Bug#747931: network-manager: very many IPV6 addresses on eth0

[Gunnar Thorburn]

Package: network-manager
Version: 0.9.4.0-10
Severity: normal
Tags: ipv6

Dear Maintainer,

These lines appear in /var/log/syslog every 5 min
May 12 07:52:11 sleipnir NetworkManager[6719]:  Policy set
'Wired connection 1' (eth0) as default for IPv4 routing and DNS.
May 12 07:52:11 sleipnir NetworkManager[6719]:  Policy set
'Wired connection 1' (eth0) as default for IPv6 routing and DNS.

When it happens, eth0 gets another IPV6 address, for example:
eth0  Link encap:Ethernet  HWaddr 00:0a:95:66:9c:38
  inet addr:192.168.8.14  Bcast:192.168.8.255  Mask:255.255.255.0
  inet6 addr: 2002::61ef:1:c20:268e:2d67:67a8/64 Scope:Global
  inet6 addr: 2002::61ef:1:188b:efac:7164:7dd8/64 Scope:Global
  inet6 addr: 2002::61ef:1:569:ac30:a77e:7b90/64 Scope:Global
  inet6 addr: 2002::61ef:1:503b:ffd9:1adc:c27c/64 Scope:Global
  inet6 addr: 2002::61ef:1:20a:95ff:fe66:9c38/64 Scope:Global
  inet6 addr: fe80::20a:95ff:fe66:9c38/64 Scope:Link
  inet6 addr: 2002::61ef:1:5441:2c23:a00b:cdd8/64 Scope:Global
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:24328 errors:0 dropped:0 overruns:0 frame:0
  TX packets:20851 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:3793711 (3.6 MiB)  TX bytes:5166528 (4.9 MiB)
  Interrupt:41 Base address:0x4800

This system was installed a few weeks ago. I believe I have made no
network configuration whatsoever -
just relying on standrad DHCP for IPv4 and Autoconfigure for IPv6.
I have one other Debain 7.5 system (an armv5tel system, not a PowerPC)
on the network, without this problem.
I have a very simple 6to4-configured OpenWRT router that advertises
the IPV6 network. The clients autoconfigure.
I also have several other computers with different operating systems
(Xubuntu, Mac OS X, Windows 7) on the
network - none of them have problems with several IPV6 addresses.

I noticed this problem because the avahi-deamon consumed 99% cpu when
I had almost 200 IPv6 addresses:
/var/log/syslog:
  (almost 200 lines like the next line)
May 11 07:44:28 sleipnir avahi-daemon[2350]: Withdrawing address
record for 2002::61ef:1:90d1:46d6:3b17:5f0a on eth0.
  (then)
May 11 07:44:28 sleipnir rsyslogd-2177: imuxsock begins to drop
messages from pid 2350 due to rate-limiting
May 11 07:44:45 sleipnir NetworkManager[2174]:  error monitoring
device for netlink events: No buffer space available
May 11 07:44:45 sleipnir minissdpd[3915]: recvmsg(s, &hdr, 0): No
buffer space available

I understand I may be better off without the avahi-daemon, but
switching it off does not fix the problem.
Restarting Network Manager brings me down to TWO IPV6-addresses (which
is one too much, as I understand it):
root@sleipnir:~# service network-manager restart ; /sbin/ifconfig
[ ok ] Stopping network connection manager: NetworkManager.
[ ok ] Starting network connection manager: NetworkManager.
eth0  Link encap:Ethernet  HWaddr 00:0a:95:66:9c:38
  inet addr:192.168.8.14  Bcast:192.168.8.255  Mask:255.255.255.0
  inet6 addr: 2002::61ef:1:20a:95ff:fe66:9c38/64 Scope:Global
  inet6 addr: fe80::20a:95ff:fe66:9c38/64 Scope:Link
  inet6 addr: 2002::61ef:1:8431:f293:326a:4e5/64 Scope:Global
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:35676 errors:0 dropped:0 overruns:0 frame:0
  TX packets:28823 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:5006172 (4.7 MiB)  TX bytes:6793477 (6.4 MiB)
  Interrupt:41 Base address:0x4800

According to syslog the problem appeared for the first time on 2014-05-09.
According to /etc/apt/history.log the system had not been updated
since 2014-05-01.
I updated it as soon as I found the problem, but with no success.
I belive the problem with TWO addresses has been present since I
installed the system. At that time
I just found it peculiar. But getting more and more addresses with
time is new since May 9.

This is an Apple PowerBook. The wireless network (eth1) is disabled.
The computer is on 24/7, acting as a test webserver.

Workaround: add to /etc/crontab
59 ** * *   rootservice network-manager restart

Restarting the computer also takes me down to two addresses, but does
not solve the problem.

Below is standard reportbug output, run as root, otherwise I got
permission error with:
/etc/polkit-1/localauthority/10-vendor.d/org.freedesktop.NetworkManager.pkla

I find this all strange enough to file a bug report.

Thank you all for making a fantastic job with Debian!

  Regards
  Gunnar

-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 3.2.0-4-powerpc
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions 

Bug#735502: cppcheck: diff for NMU version 1.61+dfsg-0.1

[Vincent Cheng]

tag 735502 + patch
tag 735502 + pending
thanks

Dear Maintainer,

I've prepared an NMU for cppcheck (versioned as 1.61+dfsg-0.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I should
delay it longer.

The following debdiff consists of changes made to the package aside
from the removal of htdocs/*, which generates too much noise to be of
any use in this diff:

Regards,
Vincent

diff -Nru orig/cppcheck-1.61/debian/changelog
cppcheck-1.61+dfsg/debian/changelog
--- orig/cppcheck-1.61/debian/changelog 2013-08-04 01:04:20.0 -0700
+++ cppcheck-1.61+dfsg/debian/changelog 2014-05-12 11:37:45.0 -0700
@@ -1,3 +1,13 @@
+cppcheck (1.61+dfsg-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Octavio Alvarez ]
+  * Removed htdocs from source package to prevent licensing issues with
+sourceless JavaScript files. (Closes: #735502)
+
+ -- Gianfranco Costamagna   Fri, 09
May 2014 16:22:26 +0200
+
 cppcheck (1.61-1) unstable; urgency=low

   * New upstream release
diff -Nru orig/cppcheck-1.61/debian/copyright
cppcheck-1.61+dfsg/debian/copyright
--- orig/cppcheck-1.61/debian/copyright 2013-01-19 12:32:08.0 -0800
+++ cppcheck-1.61+dfsg/debian/copyright 2014-05-09 07:22:16.0 -0700
@@ -1,6 +1,7 @@
-Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=166
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: cppcheck
 Source: https://sourceforge.net/projects/cppcheck
+Files-Excluded: htdocs

 Files: *
 Copyright:
diff -Nru orig/cppcheck-1.61/debian/watch cppcheck-1.61+dfsg/debian/watch
--- orig/cppcheck-1.61/debian/watch 2011-02-06 10:20:48.0 -0800
+++ cppcheck-1.61+dfsg/debian/watch 2014-05-09 07:22:23.0 -0700
@@ -1,2 +1,2 @@
 version=3
-http://sf.net/cppcheck/cppcheck-(.+)\.tar\.gz
+opts=dversionmangle=s/\+dfsg// http://sf.net/cppcheck/cppcheck-(.+)\.tar\.gz


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747930: mdadm doesn't work with kernel 3.x

[uhjb]

Package: mdadm
Version: 3.1.4-1+8efb9d1+squeeze1
Severity: important

Hi,

please update mdadm to the newest version or apply a patch:
https://bugs.archlinux.org/task/25371

Old mdadm fails with kernel 3.x, eg. mdadm -A says "no such device"


-- System Information:
Debian Release: 6.0.9
  APT prefers oldstable
  APT policy: (990, 'oldstable'), (10, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mdadm depends on:
ii  debconf 1.5.36.1 Debian configuration management sy
ii  libc6   2.11.3-4 Embedded GNU C Library: Shared lib
ii  lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
ii  makedev 2.3.1-89 creates device files in /dev
ii  udev164-3/dev/ and hotplug management daemo

Versions of packages mdadm recommends:
ii  exim4-daemon-light [mail 4.72-6+squeeze3 lightweight Exim MTA (v4) daemon
ii  module-init-tools3.12-2  tools for managing Linux kernel mo

mdadm suggests no packages.

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747292: gdm3: Unable to login after last upgrade (version 3.8.4-7): fails to start a GNOME session

[Pascal Obry]

Laurent,

> I think we have identified the issue, basically logind is
> started/activated too late. We'll try to fix this to preserve
> compatibility with other initsystem than systemd, but I guess it's a
> good occasion to start using it if you don't mind :)

Sure, ready for anything...

> I would suggest you to try booting using systemd by setting the init
> kernel parameter to /lib/systemd/systemd. If it's successful, you can
> install systemd-sysv and _purge_ systemd-shim and then again reboot.

Can you tell me more about the procedure? Is there some Web page
explaining that? I must say that this is beyond my current knowledge as
I've never change the kernel init parameters.

Thanks,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745761: [BTS#745761] templates://igtf-policy-bundle/{templates.in} : Final update for English review

[Christian PERRIER]

Dear Debian maintainer,

On Tuesday, April 29, 2014, I notified you of the beginning of a review process
concerning debconf templates for igtf-policy-bundle.

The debian-l10n-english contributors have now reviewed these templates,
and the final proposed changes are attached to this update to the
original bug report.

Please review the suggested changes, and if you have any
objections, let me know in the next 3 days.

However, please try to avoid uploading igtf-policy-bundle with these changes
right now.

The second phase of this process will begin on Friday, May 16, 2014, when I will
coordinate updates to translations of debconf templates.

The existing translators will be notified of the changes: they will
receive an updated PO file for their language.

Simultaneously, a general call for new translations will be sent to
the debian-i18n mailing list.

Both these calls for translations will request updates to be sent as
individual bug reports. That will probably trigger a lot of bug
reports against your package, but these should be easier to deal with.

The call for translation updates and new translations will run until
about Friday, June 06, 2014. Please avoid uploading a package with fixed or 
changed
debconf templates and/or translation updates in the meantime. Of
course, other changes are safe.

Please note that this is an approximative delay, which depends on my
own availability to process this work and is influenced by the fact
that I simultaneously work on many packages.

Around Saturday, June 07, 2014, I will contact you again and will send a final 
patch
summarizing all the updates (changes to debconf templates,
updates to debconf translations and new debconf translations).

Again, thanks for your attention and cooperation.


-- 


# These templates have been reviewed by the debian-l10n-english
# team
#
# If modifications/additions/rewording are needed, please ask
# debian-l10n-engl...@lists.debian.org for advice.
#
# Even minor modifications require translation updates and such
# changes should be coordinated with translators and reviewers.

Template: igtf-policy-@PROFILE@/install_profile
Type: boolean
Default: true
_Description: Trust IGTF @PROFILE@ CAs by default?
 Trusted IGTF Certification Authority certificates are installed in
 /etc/grid-security/certificates.
 .
 Accept this option to have certificates included by default unless they
 are explicitly excluded. Reject it to choose the reverse policy,
 excluding them unless explicitly included.
 .
 You will then have the opportunity to define the list of exceptions.

Template: igtf-policy-@PROFILE@/exclude_ca
Type: multiselect
Choices: ${exclude_ca}
_Description: Certificates to explicitly exclude:
 Please select which certificates should not be installed in
 /etc/grid-security/certificates.

Template: igtf-policy-@PROFILE@/include_ca
Type: multiselect
Choices: ${include_ca}
_Description: Certificates to explicitly include:
 Please select which certificates should be installed in
 /etc/grid-security/certificates.
Source: igtf-policy-bundle
Section: misc
Priority: extra
Maintainer: Dennis van Dok 
Build-Depends: debhelper (>= 8.0.0), po-debconf
Standards-Version: 3.9.5
Homepage: http://www.igtf.net/
Vcs-Git: git://g...@github.com:dvandok/igtf-policy-bundle.git
Vcs-Browser: https://github.com/dvandok/igtf-policy-bundle


Package: igtf-policy-classic
Architecture: all
Depends: ${misc:Depends}
Recommends: fetch-crl, openssl
Suggests: ca-certificates
Description: IGTF classic profile for Certificate Authorities
 The International Grid Trust Federation (IGTF) maintains a common trust
 base for the benefit of distributed science and research computing
 infrastructures. It provides a list of accredited trust anchors, with
 root certificates, certificate revocation list locations, contact
 information, and signing policies.
 .
 This package contains the trust anchors for the classic profile.

Package: igtf-policy-mics
Architecture: all
Depends: ${misc:Depends}
Recommends: fetch-crl, openssl
Suggests: ca-certificates
Description: IGTF MICS profile for Certificate Authorities
 The International Grid Trust Federation (IGTF) maintains a common trust
 base for the benefit of distributed science and research computing
 infrastructures. It provides a list of accredited trust anchors, with
 root certificates, certificate revocation list locations, contact
 information, and signing policies.
 .
 This package contains the trust anchors for the MICS (Member Integrated
 Credential Services) profile.

Package: igtf-policy-slcs
Architecture: all
Depends: ${misc:Depends}
Recommends: fetch-crl, openssl
Suggests: ca-certificates
Description: IGTF SLCS profile for Certificate Authorities
 The International Grid Trust Federation (IGTF) maintains a common trust
 base for the benefit of distributed science and research computing
 infrastructures. It provides a list of accredited trust anchors, with
 root certificates, certificate revocation list locations, contact
 inform

Bug#747927: qemu-utils: qemu-nbd blocks

[Michael Tokarev]

Control: reassign -1 linux-image-3.13-1-amd64 3.13.10-1

Your qemu-nbd process blocks in kernel mode, apparently while trying to
do some ext4 operation (and from your description I don't see what's
going on: you said qemu-nbd just exports an image with ext4 fs, it
should not do cause any ext4 calls itself).  This is something we
can't do anything with in userspace, it is a kernel problem.
Maybe it is something to do with the way you mount ntfs (fuse?).

Reassigning to linux-image.

But overall, what you do does not look sane.  It is just too many
(complex) levels of indirection for a task which requires streamlined
operations.  So I'd suggest to find a more clean way to do what you
want (maybe shrinking windows partition a bit and create a new linux
partition for your compiles; maybe avoiding qemu-nbd and whole nbd
layer and using a loop device instead (avoids extra kernel=>user=>
kernel trip), maybe something else).

Thanks,

/mjt

13.05.2014 06:42, Ernesto wrote:
> Package: qemu-utils
> Version: 2.0.0+dfsg-4
> Severity: normal
> 
> Dear Maintainer,
> 
> I use qemu-nbd to mount a ext4 filesystem from a virtual disk image which is 
> stored in an NTFS partition. I have more space in the NTFS partition than in 
> my native-linux ones, but I need ext4, so this is a good solution.
> 
> I use the virtual disk to compile source code, which grows up to 8-9 GB. I 
> mount it with:
> 
> modprobe nbd && qemu-nbd -c /dev/nbd0 /path_to_image/trunk.qcow2 && mount 
> /dev/nbd0 /path_to_mountpoint/mnt/
> 
> Now I often find out the compilation hangs. I can kill the processes, but 
> then I can't do ls. When I try to detach with:
> 
> qemu-nbd -d /dev/nbd0
> 
> also get a console blocked.
> 
> The system's performance feels degraded, and I have to shut down the system 
> by cutting power.
> 
> I get this on dmesg:
> 
> [44918.309453] INFO: task qemu-nbd:29898 blocked for more than 120 seconds.
> [44918.309458]   Tainted: G   O 3.13-1-amd64 #1
> [44918.309459] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [44918.309460] qemu-nbdD 88010679d350 0 29898  1 
> 0x
> [44918.309463]  88010679d010 0082 00014280 
> 00014280
> [44918.309465]  880107ce5fd8 88010679d010 88019fad4ac8 
> 88019fdc0068
> [44918.309467]  0002 811a7520 880107ce55b0 
> 
> [44918.309469] Call Trace:
> [44918.309475]  [] ? generic_block_bmap+0x50/0x50
> [44918.309479]  [] ? io_schedule+0x94/0x130
> [44918.309481]  [] ? sleep_on_buffer+0x5/0x10
> [44918.309483]  [] ? __wait_on_bit+0x54/0x80
> [44918.309485]  [] ? generic_block_bmap+0x50/0x50
> [44918.309487]  [] ? out_of_line_wait_on_bit+0x72/0x80
> [44918.309490]  [] ? autoremove_wake_function+0x30/0x30
> [44918.309511]  [] ? ext4_wait_block_bitmap+0xc0/0xd0 [ext4]
> [44918.309518]  [] ? ext4_mb_init_cache+0x20e/0x6e0 [ext4]
> [44918.309524]  [] ? ext4_mb_load_buddy+0x2ce/0x360 [ext4]
> [44918.309530]  [] ? 
> ext4_discard_preallocations+0x1e8/0x450 [ext4]
> [44918.309539]  [] ? ext4_clear_inode+0x21/0x80 [ext4]
> [44918.309541]  [] ? evict+0xa3/0x190
> [44918.309544]  [] ? dispose_list+0x31/0x40
> [44918.309546]  [] ? prune_icache_sb+0x3f/0x50
> [44918.309548]  [] ? super_cache_scan+0xea/0x150
> [44918.309551]  [] ? shrink_slab+0x1b6/0x350
> [44918.309554]  [] ? do_try_to_free_pages+0x3fd/0x550
> [44918.309556]  [] ? try_to_free_pages+0xe8/0x170
> [44918.309559]  [] ? __alloc_pages_nodemask+0x684/0x9d0
> [44918.309562]  [] ? alloc_pages_current+0x97/0x150
> [44918.309565]  [] ? sock_alloc_send_pskb+0x1fa/0x3b0
> [44918.309567]  [] ? __wake_up_sync_key+0x38/0x60
> [44918.309569]  [] ? unix_stream_sendmsg+0x263/0x3e0
> [44918.309571]  [] ? sock_sendmsg+0x86/0xc0
> [44918.309573]  [] ? poll_select_copy_remaining+0x130/0x130
> [44918.309575]  [] ? poll_select_copy_remaining+0x130/0x130
> [44918.309577]  [] ? ___sys_sendmsg+0x3c3/0x3d0
> [44918.309579]  [] ? wake_futex+0x55/0x70
> [44918.309581]  [] ? futex_wake+0x1a7/0x1d0
> [44918.309583]  [] ? do_futex+0x116/0xd10
> [44918.309585]  [] ? fsnotify+0x24e/0x330
> [44918.309588]  [] ? eventfd_ctx_read+0x55/0x210
> [44918.309590]  [] ? __sys_sendmsg+0x39/0x70
> [44918.309592]  [] ? system_call_fastpath+0x16/0x1b
> [44918.309594] INFO: task jbd2/nbd0-8:1138 blocked for more than 120 seconds.
> [44918.309596]   Tainted: G   O 3.13-1-amd64 #1
> [44918.309596] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [44918.309597] jbd2/nbd0-8 D 880141c05350 0  1138  2 
> 0x
> [44918.309599]  880141c05010 0046 00014280 
> 00014280
> [44918.309601]  880144eb1fd8 880141c05010 88019fad4ac8 
> 88019fdb4068
> [44918.309602]  0002 811a7520 880144eb1c80 
> 8801023adb80
> [44918.309604] Call Trace:
> [44918.309606]  [] ? generic_block_bmap+0x50/0x50
> [44918.309608]  [] ? io_schedule+0x94/

Bug#747257: linux-image-3.2.0-4-amd64: Wheezy kernel update in 7.5 won't resume from suspend correctly

[Jaimos Skriletz]

In the recent linux security DSA it appears the issue has been found,

"This update also fixes a regression in the isci
driver and suspend problems with certain AMD CPUs (introduced in the
updated kernel from the Wheezy 7.5 point release).
​"

I have installed the newest kernel and my few tests pm-suspend and resume
is working as it was before the point release.

jaimos

Bug#645883: [pkg-php-pear] Bug#645883: Current status of twig

[Daniel Beyer]

On Mon, 2014-05-12 at 11:15 +0200, Roland Mas wrote:
> Daniel Beyer, 2014-05-12 07:54:43 +0200 :
> 
> [...]
> 
> > I pushed everything I've done last week to anonscm.d.o [1] and
> > uploaded the package again to mentors [2].
> >
> > Roland, can you have an other look onto the package, especially the
> > new parts [3] regarding the newly added php-twig-doc package?
> 
>   I just did.  The package looks fine, and I uploaded it.  Thanks!
> 
>   Since I plan on using it for FusionForge, you may hear from me as a
> user in the not-too-distant future if I find bugs :-)
> 

That's just great. Really thanks a lot for the upload.



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

Bug#747928: libglib2.0-dev: fails to configure - unmet "python:any" dependency

[Lionel Elie Mamane]

On Tue, May 13, 2014 at 05:23:09AM +0200, Lionel Elie Mamane wrote:
> Package: libglib2.0-dev
> Version: 2.40.0-3
> Severity: serious

> libglib2.0-dev fails to configure:

> dpkg: dependency problems prevent configuration of libglib2.0-dev:
>  libglib2.0-dev depends on python:any (>= 2.6.6-7~).

> Well, the package name is "python", not "python:any". I thought it
> might be related to multiarch and maybe a newer dpkg would parse the
> "python:any", but nope, even with dpkg from unstable, still same error
> message.

Upgrading *python* helped. So it seems there is a missing dependency
on new-enough python. See e.g. https://bugs.debian.org/724705 for a
similar situation.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747929: fail to boot btrfs rootfs

[Jesse Sung]

Package: src:linux
Version: 3.14.2-1
Severity: important

Dear Maintainer,

After having upgraded to 3.14.2-1, system fails to boot with a btrfs 
root. It complains about unable to load btrfs.ko due to unknown symbols.


Comparing the depends of btrfs.ko in 3.13 and 3.14:
% sudo modinfo /lib/modules/3.13-1-amd64/kernel/fs/btrfs/btrfs.ko
filename:   /lib/modules/3.13-1-amd64/kernel/fs/btrfs/btrfs.ko
license:GPL
alias:  devname:btrfs-control
alias:  char-major-10-234
alias:  fs-btrfs
depends:libcrc32c,raid6_pq,xor
intree: Y
vermagic:   3.13-1-amd64 SMP mod_unload modversions

% sudo modinfo /lib/modules/3.14-1-amd64/kernel/fs/btrfs/btrfs.ko
filename:   /lib/modules/3.14-1-amd64/kernel/fs/btrfs/btrfs.ko
license:GPL
alias:  devname:btrfs-control
alias:  char-major-10-234
alias:  fs-btrfs
depends:raid6_pq,xor
intree: Y
vermagic:   3.14-1-amd64 SMP mod_unload modversions

By adding libcrc32c to /etc/initramfs-tools/modules, system boots again.

Regards,
Jesse


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747928: libglib2.0-dev: fails to configure - unmet "python:any" dependency

[Lionel Elie Mamane]

Package: libglib2.0-dev
Version: 2.40.0-3
Severity: serious

libglib2.0-dev fails to configure:

dpkg: dependency problems prevent configuration of libglib2.0-dev:
 libglib2.0-dev depends on python:any (>= 2.6.6-7~).

Well, the package name is "python", not "python:any". I thought it
might be related to multiarch and maybe a newer dpkg would parse the
"python:any", but nope, even with dpkg from unstable, still same error
message.

-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (500, 'stable'), (400, 'testing'), (300, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libglib2.0-dev depends on:
ii  libc6   2.17-3
ii  libglib2.0-02.40.0-3
ii  libglib2.0-bin  2.40.0-3
ii  libpcre3-dev1:8.31-2
ii  pkg-config  0.26-1
pn  python:any  
ii  zlib1g-dev  1:1.2.7.dfsg-13

libglib2.0-dev recommends no packages.

Versions of packages libglib2.0-dev suggests:
ii  libglib2.0-doc  2.33.12+really2.32.4-5

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#715278: intel-gpu-tools: "Couldn't map MMIO region: Resource temporarily unavailable" on intel_reg_read, after dist-upgrade

[Paul Wise]

On Mon, 2014-05-12 at 15:49 -0400, Brandon Simmons wrote:

> As a user who hasn't done any debian packaging, I'd love a slightly
> more hand-holdy explanation if a working package isn't forthcoming.
> Sorry I can't be of any help at the moment.

I translated the list I made before into a list of commands that may or
may not work, I haven't tested them:

sudo apt-get install build-essential devscripts
sudo apt-get install libcairo2-dev swig2.0 python3-dev
sudo apt-get build-dep intel-gpu-tools
apt-get source intel-gpu-tools
cd intel-gpu-tools-*/
uscan --verbose
uupdate ../intel-gpu-tools_1.6.orig.tar.gz
cd ../intel-gpu-tools-1.6
sed -i 's/^/#/' debian/patches/series
sed -i 's/Build-Depends: /Build-Depends: libcairo2-dev, swig2.0, python3-dev,/' 
debian/control
sed -i '/version.h/d' tests/Makefile.am
sed -i '/check-ndebug.h/d' tests/Makefile.am
sed -i '/intel_forcewaked/d debian/rules
echo usr/lib >> debian/intel-gpu-tools.install
debuild
sudo debi

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#723069: [www.debian.org] /misc/children-distros: broken link to Impi Linux

[Paul Wise]

On Tue, May 13, 2014 at 3:58 AM, Holger Wansing wrote:

> http://www.debian.org/misc/children-distros is somewhat outdated.
> There is very little activity on that site.
> I would volunteer for merging that information in
> https://wiki.debian.org/Derivatives/Census
> and dropping the content from www.debian.org,

The two pages serve very different purposes so I don't think that
would be helpful. The wiki page has a very specific purpose[1] and is
internal facing; it gathers data to be used for presentation to Debian
members/contributors on various Debian infrastructure. The web page on
the other hand seems to be the opposite, I'm not sure of the history
of that page so I can't really infer the purpose of it. Searching the
mists of time for what links to it and to the related_links page
(where the content originally was) it seems it originated in 1998[2]
but no rationale was given for adding it to the site. The person who
added it to the site appears to be MIA and I doubt he would remember
the reason for adding it anyway and it might no longer be valid since
a lot of time has passed and things have changed a fair bit since
1998. The page therefore doesn't have a known and agreed on purpose so
we need the Debian community to define one, probably with a discussion
on debian-project.

1. https://wiki.debian.org/Services/DerivativesCensus
2. 
https://anonscm.debian.org/viewvc/webwml/webwml/english/related_links.wml?r1=1.4&r2=1.5

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747927: qemu-utils: qemu-nbd blocks

[Ernesto]

Package: qemu-utils
Version: 2.0.0+dfsg-4
Severity: normal

Dear Maintainer,

I use qemu-nbd to mount a ext4 filesystem from a virtual disk image which is 
stored in an NTFS partition. I have more space in the NTFS partition than in my 
native-linux ones, but I need ext4, so this is a good solution.

I use the virtual disk to compile source code, which grows up to 8-9 GB. I 
mount it with:

modprobe nbd && qemu-nbd -c /dev/nbd0 /path_to_image/trunk.qcow2 && mount 
/dev/nbd0 /path_to_mountpoint/mnt/

Now I often find out the compilation hangs. I can kill the processes, but then 
I can't do ls. When I try to detach with:

qemu-nbd -d /dev/nbd0

also get a console blocked.

The system's performance feels degraded, and I have to shut down the system by 
cutting power.

I get this on dmesg:

[44918.309453] INFO: task qemu-nbd:29898 blocked for more than 120 seconds.
[44918.309458]   Tainted: G   O 3.13-1-amd64 #1
[44918.309459] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[44918.309460] qemu-nbdD 88010679d350 0 29898  1 0x
[44918.309463]  88010679d010 0082 00014280 
00014280
[44918.309465]  880107ce5fd8 88010679d010 88019fad4ac8 
88019fdc0068
[44918.309467]  0002 811a7520 880107ce55b0 

[44918.309469] Call Trace:
[44918.309475]  [] ? generic_block_bmap+0x50/0x50
[44918.309479]  [] ? io_schedule+0x94/0x130
[44918.309481]  [] ? sleep_on_buffer+0x5/0x10
[44918.309483]  [] ? __wait_on_bit+0x54/0x80
[44918.309485]  [] ? generic_block_bmap+0x50/0x50
[44918.309487]  [] ? out_of_line_wait_on_bit+0x72/0x80
[44918.309490]  [] ? autoremove_wake_function+0x30/0x30
[44918.309511]  [] ? ext4_wait_block_bitmap+0xc0/0xd0 [ext4]
[44918.309518]  [] ? ext4_mb_init_cache+0x20e/0x6e0 [ext4]
[44918.309524]  [] ? ext4_mb_load_buddy+0x2ce/0x360 [ext4]
[44918.309530]  [] ? ext4_discard_preallocations+0x1e8/0x450 
[ext4]
[44918.309539]  [] ? ext4_clear_inode+0x21/0x80 [ext4]
[44918.309541]  [] ? evict+0xa3/0x190
[44918.309544]  [] ? dispose_list+0x31/0x40
[44918.309546]  [] ? prune_icache_sb+0x3f/0x50
[44918.309548]  [] ? super_cache_scan+0xea/0x150
[44918.309551]  [] ? shrink_slab+0x1b6/0x350
[44918.309554]  [] ? do_try_to_free_pages+0x3fd/0x550
[44918.309556]  [] ? try_to_free_pages+0xe8/0x170
[44918.309559]  [] ? __alloc_pages_nodemask+0x684/0x9d0
[44918.309562]  [] ? alloc_pages_current+0x97/0x150
[44918.309565]  [] ? sock_alloc_send_pskb+0x1fa/0x3b0
[44918.309567]  [] ? __wake_up_sync_key+0x38/0x60
[44918.309569]  [] ? unix_stream_sendmsg+0x263/0x3e0
[44918.309571]  [] ? sock_sendmsg+0x86/0xc0
[44918.309573]  [] ? poll_select_copy_remaining+0x130/0x130
[44918.309575]  [] ? poll_select_copy_remaining+0x130/0x130
[44918.309577]  [] ? ___sys_sendmsg+0x3c3/0x3d0
[44918.309579]  [] ? wake_futex+0x55/0x70
[44918.309581]  [] ? futex_wake+0x1a7/0x1d0
[44918.309583]  [] ? do_futex+0x116/0xd10
[44918.309585]  [] ? fsnotify+0x24e/0x330
[44918.309588]  [] ? eventfd_ctx_read+0x55/0x210
[44918.309590]  [] ? __sys_sendmsg+0x39/0x70
[44918.309592]  [] ? system_call_fastpath+0x16/0x1b
[44918.309594] INFO: task jbd2/nbd0-8:1138 blocked for more than 120 seconds.
[44918.309596]   Tainted: G   O 3.13-1-amd64 #1
[44918.309596] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[44918.309597] jbd2/nbd0-8 D 880141c05350 0  1138  2 0x
[44918.309599]  880141c05010 0046 00014280 
00014280
[44918.309601]  880144eb1fd8 880141c05010 88019fad4ac8 
88019fdb4068
[44918.309602]  0002 811a7520 880144eb1c80 
8801023adb80
[44918.309604] Call Trace:
[44918.309606]  [] ? generic_block_bmap+0x50/0x50
[44918.309608]  [] ? io_schedule+0x94/0x130
[44918.309610]  [] ? sleep_on_buffer+0x5/0x10
[44918.309612]  [] ? __wait_on_bit+0x54/0x80
[44918.309614]  [] ? generic_block_bmap+0x50/0x50
[44918.309616]  [] ? out_of_line_wait_on_bit+0x72/0x80
[44918.309618]  [] ? autoremove_wake_function+0x30/0x30
[44918.309624]  [] ? 
jbd2_journal_commit_transaction+0xda9/0x17d0 [jbd2]
[44918.309629]  [] ? kjournald2+0xaf/0x240 [jbd2]
[44918.309631]  [] ? prepare_to_wait_event+0xf0/0xf0
[44918.309635]  [] ? commit_timeout+0x10/0x10 [jbd2]
[44918.309638]  [] ? kthread+0xc1/0xe0
[44918.309639]  [] ? kthread_create_on_node+0x180/0x180
[44918.309642]  [] ? ret_from_fork+0x7c/0xb0
[44918.309643]  [] ? kthread_create_on_node+0x180/0x180
[44918.309647] INFO: task kworker/u16:0:7511 blocked for more than 120 seconds.
[44918.309648]   Tainted: G   O 3.13-1-amd64 #1
[44918.309648] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[44918.309649] kworker/u16:0   D 880195924350 0  7511  2 0x
[44918.309653] Workqueue: writeback bdi_writeback_workfn (flush-43:0)
[44918.309654]  880195924010 0046 00014280 
00014280
[44918.309656]  f

Bug#747851: [Pkg-sysvinit-devel] Bug#747851: invoke-rc.d does not execute action if a package only has an upstart job and a systemd unit

[Steve Langasek]

On Mon, May 12, 2014 at 10:17:10AM +0200, Martin Pitt wrote:
> When running under systemd and a package only has an upstart job and a
> systemd unit, the "testexec" in invoke-rc.d will be false and
> is_upstart as well, thus the actions are never run in this case. This
> causes invoke-rc.d to just exit with code 102 without actually doing
> anything.

> I realize that this is a corner case in Debian as packages are
> required to have an init.d script; but it currently is quite common in
> Ubuntu, so it would be nice if this could be fixed in Debian as well.
> It's also quite an obvious omission from the "if" statement, as the
> subsequent inner case distinction between the init systems includes
> is_systemd as well.

Note that any such package is in violation of Debian policy, which requires
an init script as the least common denominator interface.

The change itself appears to straightforwardly do what's intended, but I
leave it for someone else to decide if we should apply this in support of
policy-violating packages in Ubuntu.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#746709: transition: python3 -- change the default to 3.4

[Scott Kitterman]

On Friday, May 02, 2014 20:07:00 Matthias Klose wrote:
> Package: release.debian.org
> 
> Jessie should ship with Python 3.4 as the default, and with 3.4 as the only
> Python3 version.  So lets start with making 3.4 the default.  Two months
> ago, the archive was buildable with 3.4 as the default (not directly
> checked with unstable, but with the Ubuntu development release at this
> time).  The majority of the bugs seen with 3.4 [1] has been fixed in the
> archive.  A bug for python3.4 should be fixed for the release (#732703,
> Barry Warsaw is working on this), and dh-python needs some updates.
> Rebuilding extensions might affect ongoing transitions, but we don't have
> yet that many for Python3.
> 
>   Matthias
> 
> [1]
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.4;users=debian-pyt
> h...@lists.debian.org

Looking at the Packages.qz for main/i386 I came up with this list of packages 
that need uploads/binNMUs once python3.4 is default (none of them support 
multiple python versions, so it can't be done in advance as the packages are 
now).  It seems quite manageable to me.

blender  - binNMU after 3.4 default
gdb - binNMU after 3.4 default
geis - binNMU after 3.4 default
yafaray - binNMU after 3.4 default
libpeas - binNMU after 3.4 default
libreoffice - binNMU after 3.4 default
libsigrokdecode - binNMU after 3.4 default
postgresql-9.3 - binNMU after 3.4 default
pyqt5  - binNMU after 3.4 default
znc - binNMU after 3.4 default
morse-simulator - Needs source upload after 3.4 is default

I think we can do this anytime after the current libreoffice and pyqt5 uploads 
migrate.

Scott K

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

Bug#747901: devscripts: uscan breaks git-import-orig --uscan

[James McCoy]

On Mon, May 12, 2014 at 07:42:10PM +0200, gregor herrmann wrote:
> The reason is that uscan's output changed, which is parsed by gbp.
> 
> In 2.14.1:
> 
> % uscan --dehs  
> …
> libfile-mimeinfo-perl_0.26.orig.tar.gz
> Successfully downloaded updated package File-MimeInfo-0.26.tar.gz 
> and symlinked libfile-mimeinfo-perl_0.26.orig.tar.gz to it
> 
> 
> 
> In 2.14.2:
> 
> % uscan --dehs
> …
> ../libfile-mimeinfo-perl_0.26.orig.tar.gz
> Successfully downloaded updated package File-MimeInfo-0.26.tar.gz
> Successfully symlinked ../File-MimeInfo-0.26.tar.gz to 
> ../libfile-mimeinfo-perl_0.26.orig.tar.gz.
> 

Arguably, the new output is more correct.  It's unfortunate that the
previous behavior embedded an assumption about the location of the
archive instead of actually giving the path.

I'll fix it to avoid breaking any other tools.

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


signature.asc
Description: Digital signature

Bug#747926: ITP: android-platform-system-core -- Core libraries for the Android platform

[Hans-Christoph Steiner]

Package: wnpp
Severity: wishlist
Owner: "Hans-Christoph Steiner" 

* Package name: android-platform-system-core
  Version : r21
  Upstream Author : Google, Inc.
* URL : https://android.googlesource.com/platform/system/core
* License : Apache 2.0
  Programming Lang: C, Java, Bash
  Package source  :
http://anonscm.debian.org/gitweb/?p=android-tools/android-platform-system-core.git
  Description : Core libraries for the Android platform

This is a huge collection of libraries that provide the core of the Android
platform.  Only a handful of these are needed on Debian because some of the
utilities for working with Android rely on some of these libraries.
Currently, this package includes liblog, libutils, and libcutils.

Android's system/ directory is intended for pieces of the world that are the
core of the embedded linux platform at the heart of Android.  These
essential bits are required for basic booting, operation, and debugging.



signature.asc
Description: OpenPGP digital signature

Bug#728524: gradle: Groovy 2.1.x breaks Gradle

[Miguel Landaeta]

tags 728524 + wontfix
thanks

On Mon, May 12, 2014 at 12:06:24PM +0200, Emmanuel Bourg wrote:
> Since we are now heading toward separate packages for Groovy 2 and
> Gradle 2 I guess we can mark this bug as won't fix.

I agree, thanks for reminding me about this.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at
http://db.debian.org/fetchkey.cgi?fingerprint=4CB7FE1E280ECC90F29A597E6E608B637D8967E9
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#662128: (no subject)

[Drew Parsons]

it's /dev/shm that's triggering as "suspicious": 
Message-ID: <20140513005940.30413.65861.report...@schumann.anu.edu.au>
X-Mailer: reportbug 6.5.0
Date: Tue, 13 May 2014 10:59:40 +1000

Warning: Suspicious file types found in /dev:
 /dev/shm/pulse-shm-1963598897: data
 /dev/shm/mono.4102: data
 /dev/shm/pulse-shm-4256995607: data

Is it normal for these kinds of files to trigger a warning?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#574798: zlib: Please ship minizip as a shared library

[Jonathan Nieder]

Michael Gilbert wrote:
> On Mon, May 12, 2014 at 4:05 PM, Mark Brown  wrote:

 Please discuss this with upstream.
>>>
>>> If you have bug reports in upstream's libminizip support, I'm happy to
>>> work on them upstream.  Last time I checked, it Just Worked (tm).
>
> I'm also willing to help if needed.  Chromium currently uses embeded
> minizip, and I did this work to be able to link against it.

Let's try to add symbol versioning.  (Feel free to contact me
privately if that helps coordinate work.)

I don't think that blocks packaging what already exists, though.

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727504: scrub: run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4

[Adam Conrad]

Package: scrub
Version: 2.5.2-2
Followup-For: Bug #727504
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu utopic ubuntu-patch



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

  * Use dh_autotools_dev to update config.{sub,guess} (Closes: #727504)

Despite doko's retitling of this bug, your package doesn't appear to
need dh_autoreconf, using dh_autotools_dev works just fine, and I've
patched it to do just that.  Applying this trivial patch in Debian
would be great.

... Adam

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

Kernel: Linux 3.15.0-0-generic (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru scrub-2.5.2/debian/changelog scrub-2.5.2/debian/changelog
diff -Nru scrub-2.5.2/debian/rules scrub-2.5.2/debian/rules
--- scrub-2.5.2/debian/rules	2013-01-30 14:12:53.0 -0700
+++ scrub-2.5.2/debian/rules	2014-05-12 18:23:18.0 -0600
@@ -1,5 +1,5 @@
 #!/usr/bin/make -f
 %:
-	dh $@
+	dh $@ --with autotools_dev
 	
 override_dh_auto_test:

Bug#574798: zlib: Please ship minizip as a shared library

[Michael Gilbert]

On Mon, May 12, 2014 at 4:05 PM, Mark Brown  wrote:
>> > Please discuss this with upstream.
>
>> If you have bug reports in upstream's libminizip support, I'm happy to
>> work on them upstream.  Last time I checked, it Just Worked (tm).

I'm also willing to help if needed.  Chromium currently uses embeded
minizip, and I did this work to be able to link against it.

>> I don't think it would make sense to go upstream and say "Mark Brown
>> is not happy with how contrib/minizip deals with the shared library.
>> Discuss" without further details. ;-)
>
> Well, figuring out if they realise it is building a shared library and
> understand the stable ABI requirements that Unix like systems have would
> be the main thing I guess.  The comments in MiniZip64_info.txt about the
> changes for 64 bit are a bit worrying here but seem to mostly refer to
> the on disk format rather than the interfaces for users of the library.

Fedora has shipped minizip packages [0] since version 19, which has
been out for almost a year now, and they seem to be able to make it
work, which probably indicates that upstream isn't being too
disruptive with respect to the ABI now.

Also, it sounds like the minizip64 changes are now in the past, and
there isn't anything obvious that would be so disruptive in the near
future anyway.

Best wishes,
Mike

[0] https://apps.fedoraproject.org/packages/minizip


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747925: kernel-package: depends on legacy grub packages

[Christoph Anton Mitterer]

Package: kernel-package
Version: 13.008
Severity: normal


Hi.

kernel-package depends on the no existing "grub" package and the
transistional "grub2" package... so perhaps drop it altogether
(why does kernel-package need it anyway) or suggest:
grub-pc | grub-coreboot | grub-efi-amd64 | 


Cheers,
Chris.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747924: haskell-lens: build from source runs test suite twice

[Anders Kaseorg]

Source: haskell-lens
Version: 4.1.2-1
Priority: minor

(This is probably a haskell-devscripts bug, but I’ll file it here first to 
be safe.)

When building haskell-lens from source, the test suite is run twice, once 
during debian/rules build-arch, and once during debian/rules binary-arch.  
See

https://buildd.debian.org/status/fetch.php?pkg=haskell-lens&arch=i386&ver=4.1.2-1%2Bb5&stamp=1399748040

The relevant sequence of actions is

 debian/rules build-arch
debian/hlibrary.setup configure --ghc -v2 \
…
debian/hlibrary.setup build --builddir=dist-ghc
touch build-ghc-stamp
debian/hlibrary.setup test --builddir=dist-ghc
Running 5 test suites...
touch check-ghc-stamp
 fakeroot debian/rules binary-arch
debian/hlibrary.setup build --builddir=dist-ghc
touch build-ghc-stamp
debian/hlibrary.setup test --builddir=dist-ghc
Running 5 test suites...
touch check-ghc-stamp
debian/hlibrary.setup copy --builddir=dist-ghc --destdir=debian/tmp-inst-ghc

Anders


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#600488: #600488 - gdm3: Should provide shortcuts and configuration snippets to enable accessibility

[Samuel Thibault]

Hello,

althaser, le Tue 06 May 2014 21:10:59 +0100, a écrit :
> Could you please still reproduce this issue with newer gnome-settings-daemon
> version like 3.4.2+git20121218.7c1322-3+deb7u3 or 3.8.5-2 ?

Yes.

> is any shortcut already set to enable accessibility ?

I don't know of any, and the documentation still does not talk about
one.

Samuel


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#672546: [PATCH] openchrome: Do not require libdrm

[Samuel Thibault]

We can build without it.

Proper non-fatal finer libdrm detection is already done below this.

Signed-off-by: Samuel Thibault 

diff --git a/configure.ac b/configure.ac
index b13cb2c..9e77dc8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -80,7 +80,7 @@ XORG_DRIVER_CHECK_EXT(XF86DRI, xextproto x11)
 XORG_DRIVER_CHECK_EXT(DPMSExtension, xextproto)
 
 # Checks for pkg-config packages
-PKG_CHECK_MODULES(XORG, [xorg-server xproto fontsproto libdrm glproto 
$REQUIRED_MODULES])
+PKG_CHECK_MODULES(XORG, [xorg-server xproto fontsproto glproto 
$REQUIRED_MODULES])
 PKG_CHECK_MODULES(XEXT, [xextproto >= 7.0.99.1],
  HAVE_XEXTPROTO_71="yes"; AC_DEFINE(HAVE_XEXTPROTO_71, 1, [xextproto 7.1 
available]),
  HAVE_XEXTPROTO_71="no")


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747923: transition: colord

[Christopher James Halse Rogers]

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

The new release from the new stable branch of colord, 1.2.0, contains an
SONAME bump.

Although it contains some API changes from the existing 1.0 packages, they're
all dropping long-deprecated symbols; none of the packages in archive use
them.

The list of rdepends is:
  weston
  simple-scan
  gtk+3.0
  gnome-settings-daemon
  gnome-control-center
  gnome-color-manager
  darktable
  colorhug-client
  colord-gtk

All of these test-build successfully against libcolord2 and libcolorhug2 on
amd64. The transition should be completable with just binNMUs.

Ben file:

title = "colord";
is_affected = .depends ~ "libcolord1" | .depends ~ "libcolorhug1" | .depends ~ 
"libcolord2" | .depends ~ "libcolorhug2";
is_good = .depends ~ "libcolord2" | .depends ~ "libcolorhug2";
is_bad = .depends ~ "libcolord1" | .depends ~ "libcolorhug1";

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

Kernel: Linux 3.13.0-24-generic (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747922: kernel hang during boot on s390x in a virtual machine under z/VM when logged on to a terminal

[Stephen Powell]

Package: linux
Version: 3.10.1-1
Severity: normal

I have discovered a bug in the Linux kernel.
This bug only occurs for the s390x port, only
when running in a virtual machine under z/VM, only with conmode=3215,
and only when the virtual machine is logged on to a 3270 terminal (not
disconnected).  I am using TERM=dumb as a kernel boot parameter, and
the console definition in /etc/inittab looks like this:

   T0:23:respawn:/sbin/getty -L --noclear ttyS0 9600 dumb

The problem is that the kernel hangs during boot.  The last message
displayed on the console during boot before the hang varies.  One
common freeze point for the 3.13 kernel is

   PID hash table entries: 2048 (order: 2, 16384 bytes)

Pressing the Enter key a couple of times gets it going again.  Pressing
it once puts the virtual machine into a "VM READ" state.  Pressing it
the second time causes console output to resume.  However, due to
buffering, I don't think the above message is indicative of where the
kernel actually is in its processing.  Many of the messages have time
stamps on them.  By comparing the time stamps, I can tell where the
long pause actually was.  In a recent boot, for example, I saw the
following sequence of messages:

-

               Begin: Loading essential drivers ... done.
               Begin: Running /scripts/init-premount ... done.
               Begin: Mounting root file system ...
               Begin: Running /scripts/local-top ... done.
               Begin: Running /scripts/local-premount ...
[    1.973615] PM: Starting manual resume from disk
               done.
[    1.999199] EXT4-fs (dasdc1): mounting ext3 file system using the ext4 
subsystem
[    2.042526] EXT4-fs (dasdc1): mounted filesystem with ordered data mode. 
Opts: (null)
               Begin: Running /scripts/local-bottom ... done.
               done.
               Begin: Running /scripts/init-bottom ... done.

               INIT: version 2.88 booting


               Using makefile-style concurrent boot in runlevel S.

               Starting the hotplug events dispatcher: udevd.

               Synthesizing the initial hotplug events...
[  164.525332] systemd-udevd[277]: starting version 204
               done.

               Waiting for /dev to be fully populated...

-

(I have reformatted the above messages so that messages without a timestamp
prefix and messages with a timestamp prefix line up starting with the main
message text.)  As you can see, there is a huge time gap between 2.042526
and 164.525332.  That is where it was hung, waiting for me to press the
Enter key.  It is somewhere between mounting the permanent root file system
read only and starting the second instance of the udev daemon.  (The first
instance of the udev daemon starts shortly after mounting the initial RAM
file system.)

By bisecting the kernel using official Debian kernel image packages only,
it appears that the problem exists between 3.9.8-1 and 3.10.1-1.  That is,

   linux-image-3.9-1-s390x_3.9.8-1_s390x.deb     works, and
   linux-image-3.10-1-s390x_3.10.1-1_s390x.deb   fails.

And every version I have tried since 3.10.1-1 fails also.
It should be noted that a kernel which fails does not always fail.
Sometimes it does not hang.  But it hangs the majority of the time.
If the virtual machine is disconnected, that is, not logged on to a
real terminal, it seems to always boot fine, whether the virtual
machine has a SECUSER or not.  When logged on to a terminal, the chances
of failure are increased if the kernel is explicitly selected from the
boot menu, such as with

   #CP VINPUT VMSG 1

as opposed to letting a timeout occur and letting the default kernel
boot via a timeout.  I don't know why that matters, but that has been
my experience.


I will be more than happy to assist in debugging this.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747664: julia--get-object breaks because of mapcan

[Juliusz Chroboczek]

> (eval-when-compile
>   (require 'cl)); in Emacs <= 23.x for (mapcan .)

I'm not sure that's enough.  Mapcan is a DEFSUBST for cl-mapcan,
which itself is an ordinary DEFUN in cl-extra.  So unless you require
cl-extra at runtime, you're still going to get an undefined function.
(You won't see the issue in interpreted code.)

I would suggest that you avoid the overhead of loading cl or cl-extra
by rewriting

  (mapcan (lambda ...) list)

as

  (apply #'nconc (mapcar (lambda ...) list))

-- Juliusz


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741485: xserver-xorg-video-ati: System hang at boot with kernel 3.12+ with ati 4650 and xserver-xorg-video-ati

[Julien Cristau]

Control: reassign -1 src:linux 3.14~rc5-1~exp1
Control: severity -1 important

On Mon, Mar 17, 2014 at 13:04:34 +0900, Michel Dänzer wrote:

> On Fre, 2014-03-14 at 11:50 +0200, Alex wrote:
> > 
> > So i have 2 dmesg one is when i boot normally with 3.14rc5 which i get the
> > issueof booting up but black screen a cursor and it constantly tries to fix 
> > it
> > self but comes back to black screen.(dmesg)
> > The 2nd dmesg is with radeon.dpm=0 on kernel 3.14rc5 which it successfully
> > opens with correct graphics (at least as i see it) but only with kernel 
> > 3.14rc5
> > and not with kernels 3.13 and 3.12(dmesgnodpm)
> 
> Please file an upstream bug report at
> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI , component
> DRM/Radeon, and report back the resulting bug number here.
> 
> 
> P.S. This bug report should be reassigned to the kernel packages.
> 
Doing so now.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#685506: marked as done (copyright-format: new Files-Excluded field)

[Charles Plessy]

Control: reopen -1

> Date: Mon, 12 May 2014 16:33:35 +0200
> From: Joachim Breitner 
> To: Andreas Tille 
> Cc: Devscripts Devel Team ,
>  685506-d...@bugs.debian.org
> Subject: Re: mk-origtargz: Use the already parsed $data to check for
>  Files-Excluded
> Message-ID: <1399905215.19455.12.camel@kirk>
> X-Mailer: Evolution 3.12.1-1 
> 
> Version: 2.14.2
> 
> Hi,
> 
> Am Montag, den 12.05.2014, 09:59 +0200 schrieb Andreas Tille:
> > I realised that the latest devscripts upload now also includes the
> > --compression option.  Thanks for all your work on this.  While I think
> > that even the previous version fixed #685506 I wonder whether you kept
> > this bug open intentionally.  From my point of view it can be closed.
> 
> I agree, that makes two of us, closing.

Hello Joachim,

I think that you closed the wrong bug: this one is about documenting the
Files-Excluded field in the specification of machine-readable debian/copyright
files, which is probably the next thing to do now that it has been implemented
in devscripts.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741127: Please include support for solidrun cubox-i

[Vagrant Cascadian]

Control: tags -1 pending

On Fri, Apr 18, 2014 at 01:25:08AM -0700, Steve Langasek wrote:
> On Thu, Apr 17, 2014 at 11:15:07PM -0700, Steve Langasek wrote:
> > Yes, I've started rebasing the patches on 2014.04 per your request. 
> > Unfortunately, a naive rebase gives me a working SPL that hangs before it
> > loads u-boot.  So it looks like it's going to take me a little bit to get
> > this back on its feet.
> 
> Oh, well, that wasn't too hard after all.  An updated branch has been pushed
> to alioth/cubox-i.

Patches are included in git, I've also been able to test that they work on a
cubox-i4pro, and that they don't break the wandboard-quad.

live well,
  vagrant


signature.asc
Description: Digital signature

Bug#747921: Please use an explicit section for libavcodec-extra

[Stefan Lippers-Hollmann]

Package: libavcodec-extra
Version: 6:10.1-1
Severity: minor
Tags: patch

Hi

Without an explicit section declaration, libavcodec-extra inherits
Section: libs from the source stanza of debian/control and gets flagged
as obsolete by tools like deborphan. An alternative is setting another
section like metapackages or video explicitly, the attached patch uses
"metapackages" as introduced in Debian Policy 3.9.3.

Regards
Stefan Lippers-Hollmann

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

Kernel: Linux 3.14-3.slh.2-aptosid-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libavcodec-extra depends on:
ii  libavcodec-extra-55  6:10.1-1

libavcodec-extra recommends no packages.

libavcodec-extra suggests no packages.

-- no debconf information
From 946d34f4af500d8287f485887dd21ddc24292b47 Mon Sep 17 00:00:00 2001
From: Stefan Lippers-Hollmann 
Date: Tue, 13 May 2014 00:49:55 +0200
Subject: [PATCH] libavcodec-extra: declare as Section: metapackages

Without an explicit section declaration, libavcodec-extra inherits
Section: libs from the source stanza of debian/control and gets flagged
as obsolete by tools like deborphan. Pick "metapackages" as introduced
in Debian Policy 3.9.3, which is handled specially by apt frontends; an
alternative would be "video" like libav-tools.

Signed-off-by: Stefan Lippers-Hollmann 
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 80c9e5a..01363bf 100644
--- a/debian/control
+++ b/debian/control
@@ -396,6 +396,7 @@ Description: Libav codec library (additional codecs)
  GPL version 3 or later.
 
 Package: libavcodec-extra
+Section: metapackages
 Priority: extra
 Architecture: all
 Depends:
-- 
2.0.0.rc2



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

Bug#747920: ITP: libdatabase-dumptruck -- document-oriented interface to a SQLite database

[Lubomir Rintel]

Package: wnpp
Severity: wishlist
Owner: Debian Perl Group 

* Package name: libdatabase-dumptruck
  Version : 1.2
  Upstream Author : Lubomir Rintel 
* URL : https://metacpan.org/release/Database-DumpTruck
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : document-oriented interface to a SQLite database

Database::DumpTruck is a simple document-oriented interface to a SQLite
database, modelled after Scraperwiki's Python dumptruck module. It allows
for easy (and maybe inefficient) storage and retrieval of structured data
to and from a database without interfacing with SQL.

The module attempts to identify the type of the data you're inserting and
uses an appropriate SQLite type.

I am packaging this so that it's conventiently available for use with Morph
 web scraping engine. It will be maintained by the perl
packaging team and needs a sponsor.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747618:

[Sergio Oller]

retitle 747618 RFS: festvox-us-slt-hts -- US English voice for
Festival. 32kHz sample rate, HTS
thanks


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747628: perl: module deprecations / removals in 5.20

[Dominic Hargreaves]

On Sat, May 10, 2014 at 04:44:14PM +0300, Niko Tyni wrote:
> Package: perl
> 
> As of 5.19.11, the following modules are becoming deprecated in 5.20:
> 
> cpan/CGI/lib/CGI.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Apache.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Carp.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Cookie.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Fast.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Pretty.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Push.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Switch.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Util.pm:use if $] >= 5.019, 'deprecate';
> cpan/Module-Build/lib/Module/Build.pm:use if $] >= 5.019, 'deprecate';
> cpan/Module-Build/lib/inc/latest.pm:use if $] >= 5.019, 'deprecate';
> cpan/Module-Build/lib/inc/latest/private.pm:use if $] >= 5.019, 'deprecate';
> cpan/Package-Constants/lib/Package/Constants.pm:use if $] >= 5.019006, 
> 'deprecate';
> 
> So we need to package Package-Constants separately, and start recommending
> libcgi-pm-perl, libmodule-build-perl, and libpackage-constants-perl.
> 
> Module-Build deprecation warnings are probably going to be numerous in
> build logs.
> 
> I'm not quite sure how we should treat those modules that have been
> removed between 5.18 and 5.20. In #702096 I wrote
> 
> > We probably need to package all of these separately. If jessie is going
> > to release with Perl 5.18, adding them as recommendations to the perl
> > package should be enough. If we release with something later we probably
> > need real dependencies for one release cycle.
> 
> Now that we're aiming for 5.20 in jessie, do we need to bite the bullet
> and add the hard dependencies? I sort of think recommendations might
> be enough after all.
> 
> AIUI, the concern is that without the dependencies, users upgrading from
> wheezy will have their programs silently broken by disappeared modules,
> as they are skipping those upstream releases with deprecation warnings.
> But why aren't recommendations adequate for that? Users that have
> configured apt to ignore recommendations have explicitly indicated that
> they prefer disk space savings over safety guards, IMO.
> 
> The other POV is that upstream manages module removals carefully, making
> sure that users will see the warnings, and we should be as careful not
> undermine that.
> 
> A full list of relevant removals is
> 
>  libarchive-extract-perl 
>  libb-lint-perl
>  libcpanplus-perl
>  libfile-checktree-perl
>  liblog-message-perl
>  libmodule-pluggable-perl
>  libobject-accessor-perl
>  libpod-latex-perl
>  libterm-ui-perl
>  libtext-soundex-perl
> 
> (I note that we don't have a separate package for Version::Requirements,
>  the only module that was removed in 5.18. This is as discussed in
>  
> http://lists.alioth.debian.org/pipermail/perl-maintainers/2013-March/003495.html
> )

Hmm, for 5.14 we ended up with Depends for the reasons you describe, but
I think your point is a fair one; Recommends is probably strong enough.
The other way of looking at it is whether there are situations in which
having them as Depends would be actively harmful. It does feel slightly
wrong that we are forcing packages of code which is being explicitly
removed from core to be installed again on all systems, so I'd be happy
to go with Recommends in the absence of specific issues which would
merit Depends.

Dominic.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#744278: [Pkg-scala-maint] Bug#744278: scala: Packaging of Scala 2.10.4

[Martin Quinson]

Hello,

On Mon, May 12, 2014 at 08:27:46PM +0200, Lucas Satabin wrote:
> Hi Martin
> 
> On 10/05/2014 23:08, Martin Quinson wrote:
> >
> > the bootstraping process in Scala is very far from packager-friendly.
> >
> >and here are the ones of 2.11 (from Lucas's current git)
> >(obtained by running >>cat `find -name "*desired.sha1"`<< from root dir)
> >
> >e737b123d31eede5594ceda07caafed1673ec472 *code.jar -> same as 2.9
> >1b11ac773055c1e942c6b5eb4aabdf02292a7194 ?instrumented.jar -> new version
> >981392dbd1f727b152cd1c908c5fce60ad9d07f7 *enums.jar-> same
> >cd33e0a0ea249eb42363a2f8ba531186345ff68c *nest.jar -> same
> >346d3dff4088839d6b4d163efa2892124039d216 ?jsoup-1.3.1.jar  -> 1.7.3 is 
> >already packaged
> >02fe2ed93766323a13f22c7a7e2ecdcd84259b6c *annotations.jar  -> same
> >be8454d5e7751b063ade201c225dcedefd252775 *methvsfield.jar  -> same
> >3794ec22d9b27f2b179bd34e9b46db771b934ec3 ?macro210.jar -> new thing
> >b1ec8a095cec4902b3609d74d274c04365c59c04 *genericNest.jar  -> same
> >0392ecdeb306263c471ce51fa368223388b82b61 ?jsr166_and_extra.jar -> same
> >ddd7d5398733c4fbbb8355c049e258d47af636cf ?forkjoin.jar -> new version
> >a1883f4304d5aa65e1f6ee6aad5900c62dd81079 ?push.jar -> same
> >
> 
> I started to look how to make the build work without downloading anything.
> Several dependencies are used to runs tests or to publish new jars, I think
> we can cut them off for now.
> I already did it for some of them but I need to finish this and test it more
> thoroughly.
> To bootstrap the all stuff, maybe we need to momentarily commit some jars
> into the git repository.

What about removing those "*desired.sha1" files altogether (with a
patch, for example), and change the rest so that it works without
downloading those jars in any way? I have the feeling that the build
process only downloads the jars that are described with a desired.sha1

In a perfect world, we'd use the version of those jars that are
already packaged in Debian, and maybe put a symlink from their
system-wide location to their location in the tree, so that the build
process finds them. That would be really great.

Adding those jars to the git (as it seems to be done for 2.9 -- Medhi,
am I wrong?) seems ugly to me. I'd prefer to consider this as the last
alternative only. It was unavoidable for versions older than 2.11 since
scala depended on scala to bootstrap, but this has improved since then.

Bye, Mt.

-- 
Testis unus, testis nullius.


signature.asc
Description: Digital signature

Bug#747628: perl: module deprecations / removals in 5.20

[Dominic Hargreaves]

On Sun, May 11, 2014 at 04:38:24PM +0300, Niko Tyni wrote:
> block 747628 by 747731
> thanks
> 
> On Sat, May 10, 2014 at 04:44:14PM +0300, Niko Tyni wrote:
>  
> > As of 5.19.11, the following modules are becoming deprecated in 5.20:
> 
> > So we need to package Package-Constants separately, and start recommending
> > libcgi-pm-perl, libmodule-build-perl, and libpackage-constants-perl.
> 
> libpackage-constants-perl is now in NEW. We might want to add the
> corresponding Provides/Breaks/Replaces in the 5.18 packages too.

Good point, I will add this.

Thanks,
Dominic.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#665720: iptables-persistent: unusable with systemd

[Jakub Warmuz]

Package: iptables-persistent
Followup-For: Bug #665720

Thanks, works for me now :)



signature.asc
Description: OpenPGP digital signature

Bug#741998: RM: vavoom/1.33-4

[Axel Beckert]

Hi,

gustavo panizzo  wrote on 18 Mar 2014:
> i was the primary maintainer for vavoom, nowadays i don't have the
> time to maintain it anymore, i does not work when is rebuild in current
> sid. (#740988, #740989) upstream is not active and i don't have the 
> knowledge or time to fix it.
> 
> if anyone cares enough packaging could be found at
> http://anonscm.debian.org/gitweb/?p=pkg-games/vavoom.git

gustavo panizzo  wrote:
> > So please consider removing vavoom/1.33-5 from experimental, too.
> 
> i would prefer to leave it, if somebody wants it he/she can get it, of
> course is unsupported/non fully working

If someone wants to adopt and fix the package, it will be still
available at http://anonscm.debian.org/gitweb/?p=pkg-games/vavoom.git
as well as http://snapshot.debian.org/package/vavoom/. So your work is
not lost if the package is also removed from experimental. But people
won't try to install it and then complain to you that it's broken.

So I see no reason to keep the package experimental if it was removed
for the above mentioned reasons from unstable.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#723982: [amd64/g++] Suspected toolchain bug causing dlopen to segfault

[Yann Dirson]

Thanks much Aurelien for the analysis!

Just had a look, and there are several things to note:
* the cpuid calls occur from OGDF, and the latest snapshot still has
  the same code
* the variables set using cpuid info are never used in the OGDF subset
  shipped with tulip
* the code calling cpuid is inside "#if !defined(OGDF_DLL) ||
  !defined(OGDF_SYSTEM_UNIX)".  OGDF_DLL is defined only for win32 for
  some reason, and strangely OGDF_SYSTEM_UNIX is not: we're apparently
  just using that useless faulty code by mistake...

But setting OGDF_DLL causes other errors in basic.cpp: the case where
OGDF_DLL is defined but not OGDF_SYSTEM_WINDOWS is obviously missing
the closing brace for 'extern "C"' clause - this problem is fixed in
the latest OGDF snapshot (by removing this useless extra clause).

After all this, it finally builds, and as expected does not crash any
more.

On Tue, May 06, 2014 at 10:25:45PM +0200, Aurelien Jarno wrote:
> reassign 723982 tulip
> thanks
> 
> On Sat, Feb 01, 2014 at 02:27:49PM +0100, Yann Dirson wrote:
> > [resend with bugs CC'd]
> > 
> > Hello,
> > 
> > Context:
> > 
> > http://bugs.debian.org/734318 - tulip: [amd64] segfaults inside dlopen when 
> > loading plugins
> > http://bugs.debian.org/723982 - dlopen: segfaults right inside call_init
> > 
> > What we get here is a number of plugins that when dlopen'd cause an
> > obscure segfault inside libc code.  Upstream (CC'd) say they have
> > heard of such problems (on Ubuntu 13.10), that people have worked
> > around by downgrading the compiler.
> > 
> > This sounds like either a toolchain regression, or possibly some
> > edge-case that worked by chance with old compilers and now fail.
> 
> This is exactly that the bug is in tulip and up to know it worked only by 
> chance on x86_64. The segfault occurs in dl-init.c when call_init is
> calling all the init functions from DT_INIT_ARRAY. This is done in C by
> this code:
> 
> |  addrs = (ElfW(Addr) *) (init_array->d_un.d_ptr + l->l_addr);
> |  for (j = 0; j < jm; ++j)
> |((init_t) addrs[j]) (argc, argv, env);
> 
> which is translated in assembly code into:
> 
> |0x77deb926 <+134>:   lea0x8(%rbx,%rax,8),%r14
> |0x77deb92b <+139>:   nopl   0x0(%rax,%rax,1)
> |0x77deb930 <+144>:   mov%r13,%rdx
> |0x77deb933 <+147>:   mov%r12,%rsi
> |0x77deb936 <+150>:   mov%ebp,%edi
> |0x77deb938 <+152>:   callq  *(%rbx)
> |0x77deb93a <+154>:   add$0x8,%rbx
> |0x77deb93e <+158>:   cmp%r14,%rbx
> |0x77deb941 <+161>:   jne0x77deb930 
> |0x77deb943 <+163>:   pop%rbx
> |0x77deb944 <+164>:   pop%rbp
> |0x77deb945 <+165>:   pop%r12
> |0x77deb947 <+167>:   pop%r13
> |0x77deb949 <+169>:   pop%r14
> |0x77deb94b <+171>:   retq
> 
> 
> As you can see the value of addrs is stored in %rbx and is incremented
> by 8 at each loop. The segfault occurs at address 0x77deb938
> when trying to dereference %rbx. When it happens, %rbx has its upper
> 32 bits clobbered and thus point to the lower 32-bit of addrs[j].
> 
> Tracing that with GDB, it appeared %rbx is clobbered in the System::init
> constructor from tulip. This code probes among other things uses the
> CPUID instruction using assembly code:
> 
> |__asm__ __volatile__ ("xchgl%%ebx,%0\n\t"
> |"cpuid  \n\t"
> |"xchgl  %%ebx,%0\n\t"
> |: "+r" (b), "=a" (a), "=c" 
> (c), "=d" (d)
> |: "1" (infoType), "2" (c));
> 
> As you can see %ebx is saved with xchgl before the %cpuid instruction
> and restored after the same way. While that works correctly on x86, on
> x86_64 the 32 upper bits get zeroed. BOOM !
> 
> I would suggest to use  (which is available since GCC 4.4)
> instead of this buggy assembly code to probe the CPU. In the meantime I
> am reassigning the bug to tulip.
> 
> Aurelien
> 
> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#723069: [www.debian.org] /misc/children-distros: broken link to Impi Linux

[David Prévot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Le 12/05/2014 15:58, Holger Wansing a écrit :

> I would volunteer for merging that information in 
> https://wiki.debian.org/Derivatives/Census
> and dropping the content from www.debian.org, simply placing a link to the
> wiki.
> 
> That would lose the 8 translated versions
[…]
> Would that be an improvement?

I don’t think so (quite the contrary to be honest).

Regards

David


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJTcU48AAoJEAWMHPlE9r08iQ0H/2inOsxSv7R2P9II4TM7uP+/
n6QAFxQX+3dVEkV14I0Exm53/OoSHfRpJiR8PgTZx6GPcf88RLUCtw/7W1MlTxbe
VdH5Zf5Hv6A9ZiIZDpXqkfLTOuO0kBlq+yA0peRgW4ajjL44bFkuW9ZiS8EkKbqH
d14fegf531e+VkXsc7djqhQXvu3RbvTCNPDSl56XhtTEk0l3led5tWJuA1E52vRF
qlvuZ/58fkI/9n9PwBblY3+ax6j5BRsp+4kL30+gIwI/SdXGmi49E+34dMOl9LlA
QisdPVQIe5Ov87gptmt6KQ+oIaKgjHo7Jh08itUUiYF8Bi5+yCd1wfVDWyrZBoI=
=1og2
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747911: New packages build by kernel-package depending on initramfs-tools even if the kernel is not using initram

[Manoj Srivastava]

tags 747911 +moreinfo
thanks

Hi,
On Mon, May 12 2014, Klaus Ethgen wrote:


> Newly build kernel depending on "initramfs-tools |
> linux-initramfs-tool" even if the kernel does not use initram and have
> no support for initramfs.

This should be harmless.  Whether or not you have these packages
 installed should not change the behaviour, and a user can reasonably
 expect to have initrd and non-initrd kernels on the same machine.
 
> As the build of initramfs is forced even in that cases and grub is
> forced to use it, I think the severity of the bug is even higher as it
> might prevent system from booting.

This is the bug.  If you did not use make-kpkg --initrd 
 your kernel image postinst should have $initrd not equal to Yes; and
 the postinst should export INITRD = No to the environment before
 calling the postint.d.

Could you please attach the kernel image postinst file? Also, a
 log of the installation run migh help.

> Please revert the change to only depend and build initram fs if the
> kernel need it and has support for it.

We always depended on intramfs tools; but the ones we depended
 on became obsolete. But, since a use may have initramfs tools installed
 anyway, this is not a solution.

> -- Configuration Files:
> /etc/kernel-pkg.conf changed:
> maintainer := Klaus Ethgen
> email := kl...@ethgen.de
> priority := Low
> pgp := Klaus Ethgen
> config_target := menuconfig
> root_cmd := fakeroot
> do_clean := NO

manoj
-- 
An economist is a man who would marry Farrah Fawcett for her
money. Edgar R. Fiedler
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signature

Bug#747919: gddrescue: require something like "--no-logfile" to avoid newbie mistakes

[Eric Cooper]

Package: gddrescue
Version: 1.17-1
Severity: wishlist

Since use of a logfile is strongly recommended, it should be the
default.  Please require an extra step for those who know what they're
doing and want to omit the logfile, like an explicit option "--no-logfile"


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747687: wheezy-pu: package py3dns/3.0.2-1+deb7u2

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2014-05-11 at 17:24 -0400, Scott Kitterman wrote:
> On Sunday, May 11, 2014 17:08:23 Adam D. Barratt wrote:
> > On Sat, 2014-05-10 at 20:39 -0400, Scott Kitterman wrote:
> > > This package has two bugs that can cause significant issues.  Both result
> > > in a failure of a DNS lookup; one with a timeout that should not occur and
> > > the other with a traceback.
> > > 
> > > The fixes are trivial in complexity/risk so I would like to fix wheezy.
> > 
> > Please go ahead; thanks.
> 
> Uploaded.

Flagged for acceptance into p-u.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747061: wheezy-pu: package catfish/0.3.2-2+deb7u1.1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2014-05-11 at 21:14 -0700, Vincent Cheng wrote:
> On Sun, May 11, 2014 at 9:04 AM, Adam D. Barratt
>  wrote:
> > On Mon, 2014-05-05 at 00:15 -0700, Vincent Cheng wrote:
> >> The following debdiff (provided by Andreas Rönnquist) fixes a regression
> >> (#746251) in catfish introduced in version 0.3.2-2+deb7u1. Thanks!
> >
> > Please go ahead; thanks.
> >
> 
> Uploaded, thanks!

Flagged for acceptance.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747842: [Pkg-xfce-devel] Bug#747842: xfce4-weather-plugin_0.8.3-1~bpo70+1_i386.changes is NEW

[Yves-Alexis Perez]

On Mon, May 12, 2014 at 08:28:41AM -0700, Andres Salomon wrote:
> FYI, this is to deal with https://bugs.debian.org/747842, in case anyone
> else is having the same problem.

I think it'd be more helpful to update the current patch fixing the
issue, it's likely to affect more people…
> 
> 
> On Mon, 12 May 2014 10:07:16 +
> Debian FTP Masters  wrote:
> 
> > binary:xfce4-weather-plugin is NEW.
> > source:xfce4-weather-plugin is NEW.
> > 
> > Your package has been put into the NEW queue, which requires manual
> > action from the ftpteam to process. The upload was otherwise valid
> > (it had a good OpenPGP signature and file hashes are valid), so
> > please be patient.
> > 
> > Packages are routinely processed through to the archive, and do feel
> > free to browse the NEW queue[1].
> > 
> > If there is an issue with the upload, you will recieve an email from a
> > member of the ftpteam.
> > 
> > If you have any questions, you may reply to this email.
> > 
> > [1]: https://ftp-master.debian.org/new.html
> 
> ___
> Pkg-xfce-devel mailing list
> pkg-xfce-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xfce-devel

-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Bug#747918: psi-plus-plugins: otr fails if the other side uses two clients (laptop + handy)

[Rolf Wuerdemann]

Package: psi-plus-plugins
Version: 0.16.330-1
Severity: normal
Tags: upstream

Dear Maintainer,

a colleauge of mine uses either his handy and/or his laptop for xmpp
with otr. If he has both devices online with same priority,
the otr-handshake fails and he has to start/refresh the connection
several times. Clients: Gajim 0.15.4 with otr plugin 1.7.7 on
ubuntu 10.04, xabber on cyanogenmod.

Refresh from my side does not help.

Kind regs,

   rowue

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

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages psi-plus-plugins depends on:
ii  libc6   2.18-5
ii  libgcc1 1:4.9.0-2
ii  libgcrypt11 1.5.3-4
ii  libotr5 4.0.0-3
ii  libqt4-dbus 4:4.8.6+dfsg-1
ii  libqt4-network  4:4.8.6+dfsg-1
ii  libqt4-xml  4:4.8.6+dfsg-1
ii  libqtcore4  4:4.8.6+dfsg-1
ii  libqtgui4   4:4.8.6+dfsg-1
ii  libqtwebkit42.2.1-7
ii  libstdc++6  4.9.0-2
ii  libtidy-0.99-0  20091223cvs-1.3
ii  libx11-62:1.6.2-1
ii  psi-plus0.16.330-1

psi-plus-plugins recommends no packages.

psi-plus-plugins suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747292: gdm3: Unable to login after last upgrade (version 3.8.4-7): fails to start a GNOME session

[Laurent Bigonville]

Le Mon, 12 May 2014 12:02:12 +0200,
Benjamin Menant  a écrit :

> Hello Laurent,
> 
> I upgraded my system and got gdm3:amd64 3.8.4-8.1 installed. After
> reboot, I opened a VC to strace systemd-logind, then I tried to login
> through gdm.
> I attached the log results.
> 
> Eventually, I got back to 3.8.4-6.
> 
> Bob, are you talking about the Gnome Flashback session? I will give
> it a try next time.
> 
> Pascal, I also successfully tried lightdm. I got your point, and thank
> you very much for your messages.
> However, since GDM3 comes with Gnome 3, I am pretty sure it would be
> comfy for most users to just get GDM3 working & stable without
> installing any other package (even if those packages are better in any
> way; it is not the point).
> Also, I am using the **unstable** distribution, and I knew this
> distribution comes with issues. That’s fine. By the way, I guess my
> humble role as a GNU/Debian user is to report bugs, and give the most
> information I can to Maintainers so they can fix those bugs (or not).
> So, IMHO, running away to install an alternative is not a
> solution. ;-)
> 

I think we have identified the issue, basically logind is
started/activated too late. We'll try to fix this to preserve
compatibility with other initsystem than systemd, but I guess it's a
good occasion to start using it if you don't mind :)

I would suggest you to try booting using systemd by setting the init
kernel parameter to /lib/systemd/systemd. If it's successful, you can
install systemd-sysv and _purge_ systemd-shim and then again reboot.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747917: Error: Unknown error matching regexp (code -28)

[Daniel Kahn Gillmor]

Package: apertium-es-pt
Version: 1.0.3-2.1
Severity: normal

here are three attempts to use apertium-es-pt:

0 dkg@alice:~$ echo hola | apertium es-pt 
olá
0 dkg@alice:~$ echo holad | apertium es-pt 
*holad
0 dkg@alice:~$ echo viajes | apertium es-pt 
Error: Unknown error matching regexp (code -28)
0 dkg@alice:~$ 

I think there are two problems with the final request:

 a) apertium should produce some reasonable output, even if it doesn't
know a given word, such as reproducing the word with a * before it,
as it does in the earlier command.

 b) when there is an internal failure, apertium should produce a
non-zero return code (the shell prompt shows the return code,
which is 0 even on an error)

Thanks for maintaining apertium in debian!

Regards,

   --dkg

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

Kernel: Linux 3.14-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

Versions of packages apertium-es-pt depends on:
ii  apertium   3.1.0-2
ii  lttoolbox  3.1.0-1.1

apertium-es-pt recommends no packages.

apertium-es-pt suggests no packages.

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733564: pu: apache2 with ECDHE support

[Adam D. Barratt]

On Mon, 2014-05-12 at 23:29 +0200, Kurt Roeckx wrote:
> On Wed, May 07, 2014 at 10:34:43PM +0100, Adam D. Barratt wrote:
> > +  * Actually restart the services when restart-without-asking is set.
> > +(Closes: #745801)
> > 
> > That change wasn't previously mentioned and is not fixed in the unstable
> > package yet; is there an ETA for doing so? (I tried to check the repo
> > mentioned in Vcs-*, but it doesn't appear to have been updated since
> > February.)
> 
> It's now uploaded to unstable, and everything should be in svn now.

Great; +deb7u8 flagged for acceptance.

> I'd also like to upload the fix for CVE-2014-0198 to
> wheezy-security.

That I can't do much about. ;)

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#695473: NMU'ing util-linux to workaround wipefs bug that affects gnome-disk-utility? (#695473)

[Adam Conrad]

On Mon, May 12, 2014 at 11:08:05PM +0200, intrigeri wrote:
> 
> Without any indication that I should not proceed, e.g.
> because a better fix will be ready soon, I intend to upload to
> DELAYED/10 between May 24 and May 31.

If you've prepared and tested the NMU, go ahead and upload without
using the delayed queue, and thanks in advance for doing so.

... Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747221: maxima fails to plot through gnuplot

[Camm Maguire]

Greetings, and thanks so much for your report!  

As you notice, Debian unstable is 'unstable' in the sense that new code
is tested in this venue.  Thanks to reports like yours, bugs can be
caught and fixed before Debian release.

The issue is a change to gcl, in which gcl sets the stack resource
limits too aggressively.  gnuplot is silently dying with insufficient
stack as a subprocess, launched by popen().  Would be great if there was
better error reporting here.

This patch fixes it:
=
diff --git INDEX:/gcl/o/alloc.c WORKDIR:/gcl/o/alloc.c
index b172d31..69b9ed0 100644
--- INDEX:/gcl/o/alloc.c
+++ WORKDIR:/gcl/o/alloc.c
@@ -1030,7 +1030,6 @@ gcl_init_alloc(void *cs_start) {
 #if defined(BSD) && defined(RLIMIT_STACK)
   {
 struct rlimit rl;
-unsigned long mss;
   
   /* Maybe the soft limit for data segment size is lower than the
* hard limit.  In that case, we want as much as possible.
@@ -1041,12 +1040,9 @@ gcl_init_alloc(void *cs_start) {
   massert(!setrlimit(RLIMIT_DATA, &rl));
 }
 
-mss=rl.rlim_cur/64;
 massert(!getrlimit(RLIMIT_STACK, &rl));
-if (rl.rlim_max != RLIM_INFINITY && rl.rlim_max < mss)
-  mss=rl.rlim_max;
-if (rl.rlim_cur == RLIM_INFINITY || rl.rlim_cur != mss) {
-  rl.rlim_cur=mss;
+if (rl.rlim_cur!=RLIM_INFINITY && (rl.rlim_max == RLIM_INFINITY || 
rl.rlim_max > rl.rlim_cur)) {
+  rl.rlim_cur = rl.rlim_max == RLIM_INFINITY ? rl.rlim_max : 
rl.rlim_max/64;
 #ifdef __MIPS__
   if (setrlimit(RLIMIT_STACK,&rl))
fprintf(stderr,"Cannot set stack rlimit\n");/*FIXME work around make 
bug on mips*/
=

I will be uploading a new Debian version with this included and
rebuilding maxima shortly.  But first, I need let acl2 finish
autobuilding, which might take a week.

If you see anything else, please let me know.

Take care,

Andres Cimmarusti  writes:

> I went upstream with this bug report and here's what we found out:
>
> http://sourceforge.net/p/maxima/mailman/message/32317553/
>
> Bottom line is: every time gcl gets updated, maxima needs to be
> rebuilt so things work as expected. Maxima was last rebuilt on
> 2014-04-15, by then the Debian archive had version 2.6.10-4 or
> 2.6.10-5 of gcl. Since then, there's been 5 new versions of gcl
> uploaded (even if they are just 2.6.11pre test versions).
>
> I hope this fixes the problem. I will attempt to rebuild myself when I
> have some time and report back.
>
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747916: synaptic: Missing dependencies python-gtk2 and python-glade2 to display messages

[Tuxicoman]

Package: synaptic
Version: 0.81.1
Severity: important

Dear Maintainer,

Synaptic has sometimes to display messages during installation of packages 
(like maintener warnings)
If python-gtk2 and python-glade2 are not present, the installation process is 
stucked as the user has to validate the message. The message is shown instead 
in the console, but the console is hidden by default so the user has no clue to 
know why the install is stalled and what he has to do. Therefore to get the 
normal synaptic experience, I think the packages needed to popup the messages 
during installation should part of the dependencies of the synaptic package



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

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages synaptic depends on:
ii  hicolor-icon-theme   0.13-1
ii  libapt-inst1.5   1.0.3
ii  libapt-pkg4.12   1.0.3
ii  libatk1.0-0  2.12.0-1
ii  libc62.18-5
ii  libcairo-gobject21.12.16-2
ii  libcairo21.12.16-2
ii  libept1.4.12 1.0.12
ii  libgcc1  1:4.9.0-2
ii  libgdk-pixbuf2.0-0   2.30.7-1
ii  libglib2.0-0 2.40.0-3
ii  libgtk-3-0   3.12.1-1
ii  libpango-1.0-0   1.36.3-1
ii  libpangocairo-1.0-0  1.36.3-1
ii  libstdc++6   4.9.0-2
ii  libvte-2.90-91:0.36.0-2
ii  libx11-6 2:1.6.2-1
ii  libxapian22  1.2.17-1
ii  libxext6 2:1.3.2-1
ii  zlib1g   1:1.2.8.dfsg-1

Versions of packages synaptic recommends:
ii  gksu   2.0.2-6
ii  libgtk2-perl   2:1.249-2
ii  policykit-10.105-5
ii  rarian-compat  0.8.1-5

Versions of packages synaptic suggests:
pn  apt-xapian-index 
pn  deborphan
pn  dwww 
ii  menu 2.1.46
pn  software-properties-gtk  
ii  tasksel  3.20

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747915: clamav: [INTL:pt] Portuguese translation for debconf messages (update)

[Américo Monteiro]

Package: clamav
version: 0.98.3+dfsg-1
Tags: l10n, patch
Severity: wishlist

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

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro


clamav_0.98.3+dfsg-1_pt.po.gz
Description: GNU Zip compressed data

Bug#733564: pu: apache2 with ECDHE support

[Kurt Roeckx]

On Wed, May 07, 2014 at 10:34:43PM +0100, Adam D. Barratt wrote:
> On Thu, 2014-05-01 at 15:59 +0200, Kurt Roeckx wrote:
> > On Mon, Apr 14, 2014 at 09:57:21PM +0200, Stefan Fritsch wrote:
> > > Am Montag, 14. April 2014, 21:18:46 schrieb Philipp Kern:
> > > > So I'd say that we should go and add ECDHE support to Apache as
> > > > suggested and also patch OpenSSL for the OS X bug as the
> > > > fingerprinting landed upstream and we would merely replicate
> > > > current upstream behavior.
> [...]
> > I've just uploaded it.
> 
> +  * Actually restart the services when restart-without-asking is set.
> +(Closes: #745801)
> 
> That change wasn't previously mentioned and is not fixed in the unstable
> package yet; is there an ETA for doing so? (I tried to check the repo
> mentioned in Vcs-*, but it doesn't appear to have been updated since
> February.)

It's now uploaded to unstable, and everything should be in svn now.

I'd also like to upload the fix for CVE-2014-0198 to
wheezy-security.


Kurt


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#746404: Fwd: Bug#746404: dtv-scan-tables: /usr/share/dvb/dvb-t/fr-all file : invalid enum and no DVB-T services found

[Olliver Schinagl]

Apologies to all involved, I overlooked this e-mail. I patched it to fix 
the casing as suggested in the e-mail and pushed it upstream. Can you 
please test it?


Olliver

On 04/29/2014 11:57 PM, Jonathan McCrohan wrote:

Hi Oliver,

Please find Debian bug report from fredboboss regarding
dtv-scan-tables below.

Thanks,
Jon

On Tue, 29 Apr 2014 19:50:57 +0200, fredboboss wrote:

Package: dtv-scan-tables
Version: 0+git20140326.cfc2975-1
Severity: normal

Dear Maintainer,

Dear Debian Maintainer,

when performing a DVB-T frequency scan with the /usr/bin/scan utility (dvb-apps 
package) and the /usr/share/dvb/dvb-t/fr-All frequency file (dtv-scan-tables 
packages) the following 2 problems occur :

1) file parsing error :
ERROR: invalid enum value '8MHZ'
ERROR: invalid enum value '8K'

2) in the end no DVB-T services are found with a Hauppauge NOVA-TD-500 DVB-T 
card.

Those problems seem to come from the /usr/share/dvb/dvb-t/fr-All file.

The following changes are proposed in this file :

For 1) :
- 8MHZ changed by 8MHz
- 8K changed by 8k

For 2) :
- change FEC_HI parameter by AUTO

Thus the 1st frequency line of the file would be changed like that :
-T 47400 8MHZ 2/3 NONE QAM64 8K 1/32 NONE #Channel UHF 21
+T 47400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 21

(Please refer to the end of the mail for the complete modified file).

Thanks to those modifications I successfully performed a DVB-T scan with the 
NOVA TD-500 card.

In case more information is needed don't hesitate to contact me.

Best regards,
Fred

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

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information

Modified file :
# France ALL (All channel 21 to 60)
# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
T 47400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 21
T 48200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 22
T 49000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 23
T 49800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 24
T 50600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 25
T 51400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 26
T 52200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 27
T 53000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 28
T 53800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 29
T 54600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 30
T 55400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 31
T 56200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 32
T 57000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 33
T 57800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 34
T 58600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 35
T 59400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 36
T 60200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 37
T 61000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 38
T 61800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 39
T 62600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 40
T 63400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 41
T 64200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 42
T 65000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 43
T 65800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 44
T 66600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 45
T 67400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 46
T 68200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 47
T 69000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 48
T 69800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 49
T 70600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 50
T 71400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 51
T 72200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 52
T 73000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 53
T 73800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 54
T 74600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 55
T 75400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 56
T 76200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 57
T 77000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 58
T 77800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 59
T 78600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 60



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747914: autopkgtest: LXC containers built with adt-build-lxc fail on missing networking

[Olivier Berger]

Package: autopkgtest
Version: 2.16
Severity: normal

Dear Maintainer,

adt-build-lxc invokes lxc-create, but created containers don't have networking, 
which results in messages like :

Err http://cdn.debian.net sid InRelease
  
Err http://cdn.debian.net sid Release.gpg
  Could not resolve 'cdn.debian.net'

It seems to me that default options for LXC containers miss a networking type 
in /var/lib/lxc/adt-sid/config :
lxc.network.type = empty

Thanks in advance.

Best regards,
-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages autopkgtest depends on:
ii  apt-utils  1.0.3
ii  debhelper  9.20140228
ii  libdpkg-perl   1.17.9
ii  python 2.7.5-5
ii  python-debian  0.1.21+nmu3

autopkgtest recommends no packages.

Versions of packages autopkgtest suggests:
pn  autopkgtest-xenlvm  
ii  lxc 1.0.0-8
ii  qemu-system 2.0.0+dfsg-4
ii  qemu-utils  2.0.0+dfsg-4
pn  schroot 

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747664: julia--get-object breaks because of mapcan

[Martin Maechler]

Thank you Dirk et al.

Hmm, I had added

(eval-when-compile
  (require 'cl)); in Emacs <= 23.x for (mapcan .)


r5951 | maechler | 2013-12-30 09:27:03 +0100 (Mon, 30 Dec 2013) | 2 lines

need 'cl  at least in emacs 23.4

(too late for 13.09-x)
already.

Unfortunately,  [TAB] completion has been completely broken in
*julia* buffers for me, so I now can no longer test if the
(eval-when-compile )  is sufficient.

A simple  (require 'cl)  gives a warning during compilation :

ess-julia.el:42:1:Warning: cl package required at runtime

and that's why I (assume I) used the  (eval-when-compile ...) clause.

ESS corers: Any idea why  [TAB] completion fails in  *julia*,
e.g. after

xyz = 1:10

xy[TAB]

nothing happens, but a message   "no completion on ."

Martin


On Mon, May 12, 2014 at 2:43 PM, Dirk Eddelbuettel  wrote:
>
> Hi ESSers,
>
> Could you please have a look at this which was filed at my end, but is of
> course an upstream issue?
>
> Thanks,  Dirk
>
> On 10 May 2014 at 22:36, Juliusz Chroboczek wrote:
> | Package: ess
> | Version: 13.09-1-1
> |
> | Typing TAB in an iESS buffer in Julia mode sometimes breaks because
> | mapcan is not defined.  A simple workaround is to (load 'cl), but it
> | would perhaps be better to use nconc(mapcar) instead.
> |
> | I am running emacs24 24.3+1-3.
> |
> | Here's a backtrace:
> |
> | Debugger entered--Lisp error: (void-function mapcan)
> |   mapcan(#[(mod) "\303 \304\232\203   julia--get-objects(# 
> nil)
> |   julia-object-completion()
> |   completion--capf-wrapper(julia-object-completion all)
> |   run-hook-wrapped(completion--capf-wrapper julia-object-completion all)
> |   completion-at-point()
> |   call-interactively(completion-at-point nil nil)
> |
> | ___
> | ESS-Debian mailing list
> | ess-deb...@r-project.org
> | https://stat.ethz.ch/mailman/listinfo/ess-debian
>
> --
> Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
>
> ___
> ESS-Debian mailing list
> ess-deb...@r-project.org
> https://stat.ethz.ch/mailman/listinfo/ess-debian
>


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#695473: NMU'ing util-linux to workaround wipefs bug that affects gnome-disk-utility? (#695473)

[intrigeri]

Hi,

Fabian Greffrath wrote (19 Nov 2013 13:01:41 GMT) :
> Reassigning to util-linux. Raising severity, because this affects other 
> packages.

I've been experiencing the pain that comes with this bug on an
up-to-date sid system for a while. I confirm that the patch nicely
forwarded here by Fabian almost six months ago fixes the problem
for me.

Martin Pitt has applied this patch to Ubuntu in September 2012, and
I have found no trace of issues it may have caused there since then.
Moreover, according to Martin, this patch can be dropped once
util-linux 2.21 reaches Debian. So, I think we should just apply it to
Debian too.

Lamont, or anyone else, would you mind if I do a NMU with this patch
applied, based on Fabian's patch (that is attached to this bug
report), of course with the version number updated?

Without any indication that I should not proceed, e.g.
because a better fix will be ready soon, I intend to upload to
DELAYED/10 between May 24 and May 31.

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747553: asciidoc default iconsdir is empty

[Joseph Herlant]

Control: owner -1 !
Control: tags -1 moreinfo

Hi Wesley,

Thanks for the report.
What's weird is that I have exactly the same version as you do but
don't have the same things:

> The following error messages appear, which points to the problem:
> asciidoc: WARNING: xxx.txt: line 53: {sys:"/usr/bin/python" -u -c "import 
> base64,sys; base64.encode(sys.stdin,sys.stdout)" < 
> "/etc/asciidoc/images/icons/important.png"}: non-zero exit status

I have:
$ asciidoc -a data-uri -a icons /tmp/test.adoc
$ asciidoc -a data-uri -a icons -v /tmp/test.adoc
asciidoc: reading: /etc/asciidoc/asciidoc.conf
asciidoc: reading: /tmp/test.adoc
asciidoc: reading: /etc/asciidoc/xhtml11.conf
asciidoc: include1: /etc/asciidoc/stylesheets/asciidoc.css
asciidoc: test.adoc: line 9: ifeval: "source-highlight"=="pygments": False
asciidoc: include1: /etc/asciidoc/javascripts/asciidoc.js
asciidoc: reading: /etc/asciidoc/filters/graphviz/graphviz-filter.conf
asciidoc: reading: /etc/asciidoc/filters/source/source-highlight-filter.conf
asciidoc: test.adoc: line 9: ifeval:
"source-highlight"=="source-highlight": True
asciidoc: test.adoc: line 9: ifeval: "source-highlight"=="highlight": False
asciidoc: test.adoc: line 9: ifeval: "source-highlight"=="pygments": False
asciidoc: reading: /etc/asciidoc/filters/music/music-filter.conf
asciidoc: reading: /etc/asciidoc/filters/code/code-filter.conf
asciidoc: reading: /etc/asciidoc/filters/latex/latex-filter.conf
asciidoc: reading: /etc/asciidoc/lang-en.conf
asciidoc: writing: /tmp/test.html
asciidoc: test.adoc: line 21: evaluating:
{eval:os.path.join(r"/tmp",r"/etc/asciidoc/images/icons/warning.png")}
asciidoc: test.adoc: line 21: evaluating: {sys:"/usr/bin/python" -u -c
"import base64,sys; base64.encode(sys.stdin,sys.stdout)" <
"/etc/asciidoc/images/icons/warning.png"}
asciidoc: test.adoc: line 21: shelling: "/usr/bin/python" -u -c
"import base64,sys; base64.encode(sys.stdin,sys.stdout)" <
"/etc/asciidoc/images/icons/warning.png" > "/tmp/tmpsCVwMV"
asciidoc: test.adoc: line 58: evaluating: {counter:table-number}

And the icons are showing correctly.
Could you send me the same command result using "-v" option please?
Could you attach the xxx.txt file you used and the backend
configuration file too please?

> /etc/asciidoc/images is a symlink to /usr/share/asciidoc/images, which
> sounds correct. However, /usr/share/asciidoc/images/icons is completely
> empty.

I have:
$ ll /usr/share/asciidoc/images/icons
lrwxrwxrwx 1 root root 8 Mar 11 22:46 /usr/share/asciidoc/images/icons
-> ../icons
$ ll /usr/share/asciidoc/images/icons/
total 48K
drwxr-xr-x 2 root root 4.0K Mar 30 19:14 callouts
-rw-r--r-- 1 root root 2.7K Mar  7  2009 caution.png
-rw-r--r-- 1 root root 2.6K Mar  7  2009 example.png
-rw-r--r-- 1 root root 1.4K Oct 29  2007 home.png
-rw-r--r-- 1 root root 3.0K Mar  7  2009 important.png
-rw-r--r-- 1 root root 1.3K Oct 29  2007 next.png
-rw-r--r-- 1 root root 2.5K Mar  7  2009 note.png
-rw-r--r-- 1 root root 1.4K Oct 29  2007 prev.png
-rw-r--r-- 1 root root  226 Oct 29  2007 README
-rw-r--r-- 1 root root 2.7K Mar  7  2009 tip.png
-rw-r--r-- 1 root root 1.3K Oct 29  2007 up.png
-rw-r--r-- 1 root root 3.2K Mar  7  2009 warning.png


> The icons are actually found in /usr/share/doc/images/icons, which
> doesn't seem to be the correct location for them, since although they
> are referenced by the asciidoc documentation, they also need to be
> available in order to use "-a data-uri -a icons"

I have:
$ ll /usr/share/doc/images/icons
ls: cannot access /usr/share/doc/images/icons: No such file or directory

But I think you mean:
$ ll /usr/share/doc/asciidoc/images/icons
lrwxrwxrwx 1 root root 23 Mar 11 22:46
/usr/share/doc/asciidoc/images/icons -> ../../../asciidoc/icons

So it's /usr/share/doc/asciidoc/images/icons that points to
/usr/share/asciidoc/icons

There has been a lot of modification of symlinks in the last packages
steps. Could you try and reinstall asciidoc (using purge):
sudo apt-get purge asciidoc
sudo apt-get install asciidoc

and tell me if the issue is still there please?

Thanks in advance,
Joseph


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#708550: auctex: fails when first visited file is plain tex (rather than latex or context)

[Samuel Bronson]

Control: tag -1 + patch
Control: severity -1 important

This was fixed upstream, but hasn't made it into a release yet:


I've adapted the patch for you; see below or just pull from:

 git://anonscm.debian.org/users/naesten-guest/auctex.git master

if it's too hard to apply it directly.

>From dcb5c5c5b6cfb64591b1591222c613d92362615f Mon Sep 17 00:00:00 2001
From: Samuel Bronson 
Date: Mon, 12 May 2014 01:46:33 -0400
Subject: [PATCH] Import upstream patch "Fix typo of plain-TeX-abbrev-table"

Closes: #708550
---
 .../0007-Fix-plain-TeX-abbrev-table-name.patch | 31 ++
 debian/patches/series  |  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 debian/patches/0007-Fix-plain-TeX-abbrev-table-name.patch

diff --git a/debian/patches/0007-Fix-plain-TeX-abbrev-table-name.patch b/debian/patches/0007-Fix-plain-TeX-abbrev-table-name.patch
new file mode 100644
index 000..9a743ac
--- /dev/null
+++ b/debian/patches/0007-Fix-plain-TeX-abbrev-table-name.patch
@@ -0,0 +1,31 @@
+From 1a5d4475fb7c82dfca46dfdb39c9167ca8c624e7 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Mos=C3=A8=20Giordano?= 
+Date: Wed, 17 Apr 2013 21:59:40 +0200
+Subject: [PATCH] Fix plain TeX abbrev table name.
+
+2013-04-17  Mosè Giordano  
+
+	* plain-tex.el (plain-TeX-common-initialization): Fix typo in
+	abbrev table name.
+
+Origin: upstream, http://git.savannah.gnu.org/cgit/auctex.git/commit/?id=1a5d4475fb7c82dfca46dfdb39c9167ca8c624e7
+---
+ plain-tex.el | 2 +-
+ 2 files changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/plain-tex.el b/plain-tex.el
+index 476976b..3df6196 100644
+--- a/plain-tex.el
 b/plain-tex.el
+@@ -142,7 +142,7 @@ of plain-TeX-mode-hook."
+   "Common initialization for plain TeX like modes."
+   (VirTeX-common-initialization)
+   (set-syntax-table TeX-mode-syntax-table)
+-  (setq local-abbrev-table latex-mode-abbrev-table)
++  (setq local-abbrev-table plain-tex-mode-abbrev-table)
+   (setq paragraph-start
+ 	(concat
+ 	 "\\(^[ \t]*$"
+-- 
+1.9.2
+
diff --git a/debian/patches/series b/debian/patches/series
index 5c13931..1cd3b4f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@
 0004-TeX-view-program-selection-Customize-for-Debian.patch
 0005-TeX-auto-global-Customize-for-Debian.patch
 0006-preview-image-type-Customize-for-Debian.patch
+0007-Fix-plain-TeX-abbrev-table-name.patch
-- 
1.9.2


-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Bug#692933: pgflibrarytikztrees is broken

[Hilmar Preusse]

forwarded 692933 https://sourceforge.net/p/pgf/bugs/311/
reassign 692933 texlive-pictures
stop

On 11.11.12 wanne (wannes...@googlemail.com) wrote:

Hi,

> pgflibrarytikztrees.sty includes a File
> "pgflibrarytikztrees.code.tex" which dosn't exists.  Since
> pgflibrarytikztrees is deprecated this is not a big issue.  But
> replacing it with \usetikzlibrary{trees} would be a simple
> solution.
> 
Forwarded to upstream. Reassign to texlive-pictures.

H.
-- 
sigmentation fault


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747912: ITP: golang-uuid --

[Sergio Schvezov]

Package: wnpp
Severity: wishlist
Owner: Sergio Schvezov 

* Package name: golang-uuid
  Version : 0.0~hg20140512-1
  Upstream Author : Paul Borman 
* URL : https://code.google.com/p/go-uuid/
* License : BSD-3-Clause
  Programming Lang: Go
  Description : Go bindings to work with UUIDs

Generates and inspects UUIDs based on RFC 4122 and DCE 1.1: Authentication
and Security Services.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747911: New packages build by kernel-package depending on initramfs-tools even if the kernel is not using initram

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: kernel-package
Version: 13.007
Severity: normal

Newly build kernel depending on "initramfs-tools |
linux-initramfs-tool" even if the kernel does not use initram and have
no support for initramfs. As the build of initramfs is forced even in
that cases and grub is forced to use it, I think the severity of the bug
is even higher as it might prevent system from booting.

Please revert the change to only depend and build initram fs if the
kernel need it and has support for it.

- -- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (600, 'oldstable'), (110, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.2 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) (ignored: LC_ALL set to 
de_DE)
Shell: /bin/sh linked to /bin/dash

Versions of packages kernel-package depends on:
ii  bc   1.06.95-8
ii  binutils 2.24.51.20140425-1
ii  build-essential  11.6
ii  debianutils  4.4
ii  file 1:5.18-1
ii  gettext  0.18.3.2-1
ii  kmod 17-2
ii  make 4.0-5
ii  po-debconf   1.0.16+nmu2
ii  util-linux   2.20.1-5.7

Versions of packages kernel-package recommends:
ii  cpio   2.11+dfsg-2
pn  docbook-utils  
pn  uboot-mkimage  

Versions of packages kernel-package suggests:
ii  btrfs-tools   3.14.1-1
ii  bzip2 1.0.6-5
ii  dracut [linux-initramfs-tool] 037-1
ii  e2fsprogs 1.42.9-3
ii  grub-legacy [grub]0.97-67
pn  jfsutils  
pn  liblz4-tool   
ii  libncurses5-dev [libncurses-dev]  5.9+20140118-1
pn  linux-source  
pn  mcelog
pn  oprofile  
pn  pcmciautils   
pn  ppp   
ii  procps1:3.3.9-4
pn  quota 
pn  reiserfsprogs 
ii  squashfs-tools1:4.2+20130409-2
ii  udev  204-10
ii  xfsprogs  3.1.9
pn  xmlto 

- -- Configuration Files:
/etc/kernel-pkg.conf changed:
maintainer := Klaus Ethgen
email := kl...@ethgen.de
priority := Low
pgp := Klaus Ethgen
config_target := menuconfig
root_cmd := fakeroot
do_clean := NO


- -- no debconf information

- -- 
Klaus Ethgen  http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQGcBAEBCgAGBQJTcS/cAAoJEKZ8CrGAGfasPlUL/0WtR1X8FeWjmgHPmcXoGR6m
9TT987KO0T0+lHBb5lCEKSxf2a+RSP7B1+y7mO4440YBeWOjD+IBVJMII011D7X+
s/63hGuyR3tBEOX2uzlUxxrxqtTMiyjrPhFUIi88Fbdf+LFhE9SFDjIhVlgJGR/Y
LpectGxwHK2IhM2swidMDaR9xzX1yEzK3IQ9HPI6abm4GuNBp533GalrgawZnUVo
Lsmq1yPjHjx5K/wjURPlAp40Izl1S3p2045dvXdwy97RnzcIpmg+wGC03zEGSMrp
QAmJlH2alzcMmy7KX5eulMq67T765fWr+BY4x++nPPBzL1n86CCi5b6mBeEFynCy
qZQ0+8hvMnbz89tmcKuhihDeuy6NR+4VZBDAmb+aua3ddZkDhf76mroVvymo45A6
y2G2UJ0zuxnaMWi+B23GvXikIyFmlsnsGIA6G//y0VaFUp5rAnhnHA+IWj/U2shY
DeNnG90OlM9jUxd7ASwBIhZUHnaLT14Ji74qXiOprw==
=3zFk
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747803: libmrss: FTBFS: configure: line 12750: syntax error near unexpected token `NXML,'

[Joseph Herlant]

Control: owner -1 !

Hi David,

Thanks for pointing that out.
That's weird, I didn't made any changes in the package in the last few month.
Maybe a change in the reconfigure helper needs new rules/syntax. I'll
check that this week-end.

Best regards,
Joseph


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741127: Tester

[Rainer Dorsch]

Hi Vagrant,

my Cubox is on its way, so I volunteer as tester if you have the patch 
applied :-)


Thanks,
Rainer


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747910: Please add support for additional OpenSSL options SSL_OP_NO_TLSv1_2 and SSL_OP_NO_TLSv1_1

[David F. Skoll]

Package: sendmail
Version: 8.14.4-4
Severity: minor

Sendmail on Wheezy sometimes has interoperability problems with other
SSL implementations.  Some of these can be fixed by disabling TLS 1.1
and TLS 1.2.  Sendmail 8.14.8 supports SSL options to do this, but
Sendmail 8.14.4-4 does not.  Could we backport this patch from 8.14.8 to
8.14.4-4 so that we can use SSL_OP_NO_TLSv1_2 and SSL_OP_NO_TLSv1_1 ?

Regards,

David.


--- sendmail-8.14.7/sendmail/readcf.c   2013-03-15 18:54:12.0 +0100
+++ sendmail-8.14.8/sendmail/readcf.c   2013-11-22 21:51:56.0 +0100
@@ -2373,6 +2385,12 @@ static struct ssl_options
 #ifdef SSL_OP_NO_TLSv1
{ "SSL_OP_NO_TLSv1",SSL_OP_NO_TLSv1 },
 #endif
+#ifdef SSL_OP_NO_TLSv1_2
+   { "SSL_OP_NO_TLSv1_2",  SSL_OP_NO_TLSv1_2   },
+#endif
+#ifdef SSL_OP_NO_TLSv1_1
+   { "SSL_OP_NO_TLSv1_1",  SSL_OP_NO_TLSv1_1   },
+#endif
 #ifdef SSL_OP_PKCS1_CHECK_1
{ "SSL_OP_PKCS1_CHECK_1",   SSL_OP_PKCS1_CHECK_1},
 #endif


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#746708: missing license in debian/copyright

[Andreas Tille]

Hi Thiago,

On Mon, May 12, 2014 at 04:39:31PM -0300, Thiago Franco Moraes wrote:
> Fixed with the help of cme and this link [1]. It was a problem with the
> license short name and a grammar error. I think it's all ok now.

Sounds good.  I left the package as "UNRELEASED" and tagged the bug as
pending to let others know that we dealt with the problem.  I think we
can wait with the final upload until there might be some other reason
for an upload (or some time has passed - without waiting too long to let
the package migrate to testing).

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#709803: zlib: Please ship minizip as a shared library

[Mark Brown]

On Mon, May 12, 2014 at 12:02:26PM -0700, Jonathan Nieder wrote:
> Mark Brown wrote:

> > This doesn't address the issue in the original report: this isn't
> > something we should be doing off our own back in Debian, it's something
> > that upstream should be doing.  The issue isn't that it's hard to build
> > shared libraries, the issue is that it's hard to maintain them and so it
> > needs to be something that upstream are engaged with.

> I'm a little puzzled.  Upstream has rules for installing libminizip at
> contrib/minizip/Makefile.am.  Are you saying that they are buggy or
> unmaintained?

No, I'm saying that I wasn't aware that this had now been done - I
didn't check given that there didn't seem to be anything addressing the
content of the discussion in the original report.

I do note that this has not been added to the standard Makefile
though, that is still static only, so it's not clear to me that the
developer (who is mostly a Windows guy) is really aware of this or
understands shared libraries on Unix.  I'm also not seeing symbol
versioning which would be nice but I guess shouldn't be a blocker.

> > Please discuss this with upstream.

> If you have bug reports in upstream's libminizip support, I'm happy to
> work on them upstream.  Last time I checked, it Just Worked (tm).

> I don't think it would make sense to go upstream and say "Mark Brown
> is not happy with how contrib/minizip deals with the shared library.
> Discuss" without further details. ;-)

Well, figuring out if they realise it is building a shared library and
understand the stable ABI requirements that Unix like systems have would
be the main thing I guess.  The comments in MiniZip64_info.txt about the
changes for 64 bit are a bit worrying here but seem to mostly refer to
the on disk format rather than the interfaces for users of the library.


signature.asc
Description: Digital signature

Bug#746708: missing license in debian/copyright

[Thiago Franco Moraes]

Hi Andreas,

Fixed with the help of cme and this link [1]. It was a problem with the
license short name and a grammar error. I think it's all ok now.

Thanks!

[1] - http://spdx.org/licenses/WXwindows


On Mon, May 12, 2014 at 4:20 PM, Andreas Tille  wrote:

> Hi Thiago,
>
> you should probably try
>
> cme fix dpkg-copyright
>
> If this does not help I can easily fix it in SVN - but this is probably
> a good learning lession about cme (see Debian Med policy document what
> packages you need to install).
>
> Kind regards
>
>  Andreas.
>
>
> On Mon, May 12, 2014 at 01:57:16PM -0300, Thiago Franco Moraes wrote:
> > Hi Andreas,
> >
> > Sorry! I was out for some time. I added the copyright info about
> > invesalius\gui\widgets\platebtn.py. I don't know if its correct, since
> I'm
> > getting a lintian warning about the license name
> > (field-name-typo-in-dep5-copyright licence).
> >
> > Thanks!
> >
> >
> > On Mon, May 12, 2014 at 11:32 AM, Andreas Tille 
> wrote:
> >
> > > Hi Thiago,
> > >
> > > did you noticed this bug report?
> > >
> > > Kind regards
> > >
> > > Andreas.
> > >
> > > --
> > > http://fam-tille.de
> > >
>
> --
> http://fam-tille.de
>

Bug#747908: [libtuxcap] [transition blocker] Please allow to compile with imagemagick/experimental

[bastien ROUCARIES]

Package: libtuxcap
Severity: important
control: block -1 by  747907
control: block 740495 by -1
control: tags -1 + patch

Hi,

Please allow  libtuxcap to compile with newer imagemagick.

I have a patch to test but due to cmake bug I could not yet test.
--- a/tuxcap/CMakeLists.txt	2008-11-24 11:03:09.0 +0100
+++ a/tuxcap/CMakeLists.txt	2014-05-12 14:09:28.0 +0200
@@ -1,10 +1,105 @@
-PROJECT(libtuxcap)
+#include some macros from another file...
+INCLUDE(${libtuxcap_SOURCE_DIR}/tuxcap/CMakeMacros/IJMacros.txt)
 
-cmake_minimum_required(VERSION 2.4)
-if(COMMAND cmake_policy)
-  cmake_policy(SET CMP0003 OLD)
-endif(COMMAND cmake_policy)
+SET(CMAKE_MODULE_PATH "${libtuxcap_SOURCE_DIR}/tuxcap/CMakeModules" )
 
-SET (CMAKE_BUILD_TYPE RELEASE)
+SET(CMAKE_C_FLAGS_RELEASE "-DNDEBUG -O3")
+SET(CMAKE_C_FLAGS_DEBUG "-Wall -g -O0")
+SET(CMAKE_CXX_FLAGS_RELEASE "-DNDEBUG -O3")
+SET(CMAKE_CXX_FLAGS_DEBUG "-Wall -g -O0")
+
+INCLUDE(FindImageMagick)
+INCLUDE(FindSDL)
+INCLUDE(FindOpenGL)
+INCLUDE(FindSDL_mixer)
+INCLUDE(FindPythonLibs)
+
+Find_Package ( SDL REQUIRED )
+Find_Package ( SDL_mixer REQUIRED )
+Find_Package ( ImageMagick COMPONENTS Magick++ MagickWand MagickCore REQUIRED )
+Find_Package ( OpenGL REQUIRED )
+
+FIND_PACKAGE(AudiereLib)
+IF(AUDIERELIB_FOUND)
+   MESSAGE("DBG lib Audiere found. ${AUDIERELIB_INCLUDE_DIR} ${AUDIERELIB_LINK_DIRECTORIES} ${AUDIERELIB_LIBRARIES}")
+   LINK_DIRECTORIES(${AUDIERELIB_LINK_DIRECTORIES})
+ENDIF(AUDIERELIB_FOUND)
+
+SET(MY_LINK_LIBS
+   ${SDL_LIBRARY}
+   ${SDLMIXER_LIBRARY}
+   ${OPENGL_LIBRARIES}
+   ${ImageMagick_LIBRARIES} 
+   ${ImageMagick_Magick++_LIBRARIES} 
+)
+
+IF (PYTHON_LIBRARIES)
+ MESSAGE("Python development libraries found, building TuxCap Python bindings and examples")   
+ MESSAGE("Python libraries ${PYTHON_LIBRARIES} include path ${PYTHON_INCLUDE_PATH}")   
+ SET(MY_LINK_LIBS${MY_LINK_LIBS} ${PYTHON_LIBRARIES})   
+ SET(MY_DIRS${MY_DIRS} pythondemo1 pythondemo2 pythondemo_template)
+ELSE (PYTHON_LIBRARIES)
+ MESSAGE("No Python development libraries found, skipping building of TuxCap Python bindings")   
+ENDIF (PYTHON_LIBRARIES)
+
+SET (MY_DIRS ${MY_DIRS}
+lib
+demo1
+demo2 
+demo3 
+demo4 
+demo5 
+physicsdemo 
+physicsdemo2 
+physicsdemo3 
+physicsdemo4
+physicsdemo5 
+physicsdemo6 
+physicsdemo7 
+particledemo
+hungarr 
+)
+
+IF(AUDIERELIB_FOUND)
+SET(MY_LINK_LIBS${MY_LINK_LIBS} audiere)
+ENDIF(AUDIERELIB_FOUND)
+
+link_libraries (
+${MY_LINK_LIBS}
+)
+
+IF(SDL_FOUND)
+MESSAGE("libSDL found. ${SDL_INCLUDE_DIR} ${SDL_LIBRARY}")
+ELSE(SDL_FOUND)
+MESSAGE(FATAL_ERROR "libSDL requested but not found.")
+ENDIF(SDL_FOUND)
+
+IF(ImageMagick_FOUND)
+MESSAGE("lib ImageMagick found. ${ImageMagick_INCLUDE_DIR} ${ImageMagick_LIBRARIES} ${ImageMagick_Magick++_LIBRARIES}")
+ELSE(ImageMagick_FOUND)
+MESSAGE(FATAL_ERROR "lib ImageMagick requested but not found.")
+ENDIF(ImageMagick_FOUND)
+
+IF(SDLMIXER_FOUND)
+MESSAGE("libSDL_mixer found. ${SDLMIXER_INCLUDE_DIR} ${SDLMIXER_LIBRARY}")
+ELSE(SDLMIXER_FOUND)
+MESSAGE(FATAL_ERROR "libSDL_mixer requested but not found.")
+ENDIF(SDLMIXER_FOUND)
+
+IF(OPENGL_FOUND)
+MESSAGE("OpenGL found. ${OPENGL_INCLUDE_DIR} ${OPENGL_LIBRARIES}")
+ELSE(OPENGL_FOUND)
+MESSAGE(FATAL_ERROR "OpenGL requested but not found.")
+ENDIF(OPENGL_FOUND)
+
+SET ( MY_INCLUDE_DIRS  
+#/usr/include/swfdec-0.5 /usr/include/glib-2.0 /usr/lib/glib-2.0/include 
+{SDL_INCLUDE_DIR} ${ImageMagick_INCLUDE_DIRS} ${SDLMIXER_INCLUDE_DIR} ${OPENGL_INCLUDE_DIR} ${PYTHON_INCLUDE_PATH} )
+IF(AUDIERELIB_FOUND)
+SET ( MY_INCLUDE_DIRS ${MY_INCLUDE_DIRS} ${AUDIERELIB_INCLUDE_DIR} )
+ENDIF(AUDIERELIB_FOUND)
+
+INCLUDE_DIRECTORIES ( ${MY_INCLUDE_DIRS} )
+
+SUBDIRS( ${MY_DIRS} )
 
-SUBDIRS( tuxcap )

Bug#747857: add release

[Bastien ROUCARIES]

control: block 740495 by -1

Add blocker


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#746228: libmagickcore-dev: build failure on digikam

[Bastien ROUCARIES]

control: reassign -1 src:digikam
control: retitle -1 [transition blocker] Digikam FTBFS with
imagemagick/experimental
control: severity -1 important

Hi,

On Mon, Apr 28, 2014 at 12:06 PM, Ritesh Raj Sarraf  wrote:
> Package: libmagickcore-dev
> Version: 8:6.8.8.9-3
> Severity: normal
>
> I am trying to build digikam, that uses imagemagic, and have run into
> the following build failure, which looks like an ImageMagick problem.
>
>
> [ 42%] Building CXX object 
> extra/kipi-plugins/videoslideshow/magickiface/CMakeFiles/magickiface.dir/magickiface.cpp.o
> cd 
> "/tmp/buildd/digikam-4.0.0~beta4/obj-x86_64-linux-gnu/extra/kipi-plugins/videoslideshow/magickiface"
>  && /usr/bin/c++   -DAREA_CODE_GENERAL=51000 -DAREA_CODE_LOADING=51
> 001 -DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=11 -DKDE_DEFAULT_DEBUG_AREA=51000 
> -DKDE_DEPRECATED_WARNINGS -DQT_NO_CAST_TO_ASCII -DQT_NO_STL 
> -DQT_USE_FAST_CONCATENATION -DQT_USE_FA
> ST_OPERATOR_PLUS -D_BSD_SOURCE -D_REENTRANT -D_XOPEN_SOURCE=500 -g -O2 
> -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security 
> -D_FORTIFY_SOURCE=2  -
> Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall 
> -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS 
> -fno-check-new -fno-
> common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden 
> -Werror=return-type -fvisibility-inlines-hidden -DNDEBUG -DQT_NO_DEBUG 
> -I"/tmp/buildd/digikam-4.0.
> 0~beta4/obj-x86_64-linux-gnu/extra/kipi-plugins/videoslideshow/magickiface" 
> -I"/tmp/buildd/digikam-4.0.0~beta4/extra/kipi-plugins/videoslideshow/magickiface"
>  -I"/tmp/buil
> dd/digikam-4.0.0~beta4/extra/kipi-plugins/common/libkipiplugins" 
> -I"/tmp/buildd/digikam-4.0.0~beta4/obj-x86_64-linux-gnu/extra/kipi-plugins/common/libkipiplugins"
>  -I"/tmp
> /buildd/digikam-4.0.0~beta4/extra/kipi-plugins/common/libkipiplugins/dialogs" 
> -I"/tmp/buildd/digikam-4.0.0~beta4/extra/kipi-plugins/common/libkipiplugins/widgets"
>  -I"/tmp
> /buildd/digikam-4.0.0~beta4/extra/kipi-plugins/common/libkipiplugins/tools" 
> -I"/tmp/buildd/digikam-4.0.0~beta4/extra/kipi-plugins/common/libkipiplugins/tools/imageio"
>  -I"
> /tmp/buildd/digikam-4.0.0~beta4/obj-x86_64-linux-gnu" -I/usr/include/opencv 
> -I/usr/include/KDE -I/usr/include/qt4/phonon -I/usr/include/qt4/QtXmlPatterns 
> -I/usr/include/q
> t4/QtXml -I/usr/include/qt4/QtWebKit -I/usr/include/qt4/QtUiTools 
> -I/usr/include/qt4/QtTest -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtSql 
> -I/usr/include/qt4/QtScriptT
> ools -I/usr/include/qt4/QtScript -I/usr/include/qt4/QtOpenGL 
> -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtHelp 
> -I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtDec
> larative -I/usr/include/qt4/QtDBus -I/usr/include/qt4/Qt3Support 
> -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -I/usr/include/qt4/Qt 
> -I/usr/share/qt4/mkspecs/default
>  -I/usr/include/qt4 -I/usr/include/ImageMagick-6-D_GNU_SOURCE 
> -D_LARGEFILE64_SOURCE -fPIC -fPIC -o 
> CMakeFiles/magickiface.dir/magickiface.cpp.o -c "/tmp/buildd/digika
> m-4.0.0~beta4/extra/kipi-plugins/videoslideshow/magickiface/magickiface.cpp"
> In file included from /usr/include/ImageMagick-6/magick/MagickCore.h:29:0,
>  from /usr/include/ImageMagick-6/magick/api.h:24,
>  from 
> /tmp/buildd/digikam-4.0.0~beta4/obj-x86_64-linux-gnu/extra/kipi-plugins/videoslideshow/magickiface/../../../../../extra/kipi-plugins/videoslideshow/
> magickiface/magickiface.h:40,
>  from 
> /tmp/buildd/digikam-4.0.0~beta4/obj-x86_64-linux-gnu/extra/kipi-plugins/videoslideshow/magickiface/magickiface.moc:9,
>  from 
> /tmp/buildd/digikam-4.0.0~beta4/extra/kipi-plugins/videoslideshow/magickiface/magickiface.cpp:26:
> /usr/include/ImageMagick-6/magick/magick-config.h:21:38: fatal error: 
> magick/magick-baseconfig.h: No such file or directory
>  #include "magick/magick-baseconfig.h"
>   ^
> compilation terminated.
> extra/kipi-plugins/videoslideshow/magickiface/CMakeFiles/magickiface.dir/build.make:80:
>  recipe for target 
> 'extra/kipi-plugins/videoslideshow/magickiface/CMakeFiles/magickiface.dir/magickiface.cpp.o'
>  failed
> make[3]: *** 
> [extra/kipi-plugins/videoslideshow/magickiface/CMakeFiles/magickiface.dir/magickiface.cpp.o]
>  Error 1
> make[3]: Leaving directory 
> '/tmp/buildd/digikam-4.0.0~beta4/obj-x86_64-linux-gnu'
> CMakeFiles/Makefile2:7229: recipe for target 
> 'extra/kipi-plugins/videoslideshow/magickiface/CMakeFiles/magickiface.dir/all'
>  failed
> make[2]: *** 
> [extra/kipi-plugins/videoslideshow/magickiface/CMakeFiles/magickiface.dir/all]
>  Error 2
> /usr/bin/cmake -E cmake_progress_report 
> "/tmp/buildd/digikam-4.0.0~beta4/obj-x86_64-linux-gnu/CMakeFiles"
> make[2]: *** Waiting for unfinished jobs

The bug is on cmake and is a transition blocker. I have reassigned to
digikam and add a blocker bug on cmake.

Thanks

Bastien


-- 
To UNSUBSCRIBE, email to debi

Bug#723069: [www.debian.org] /misc/children-distros: broken link to Impi Linux

[Holger Wansing]

Hi,

Filipus Klutiero  wrote:
> http://www.debian.org/misc/children-distros#impi reads:
> > Impi Linux was a South African Linux distribution based on Debian (and 
> Knoppix). It was created from the best software available in the open 
> source world, to give South African users a stable, virus free and very 
> cost effective business operating system. It focused on providing an 
> office desktop system. More information available at http://www.impi.org.za/
> 
> http://www.impi.org.za/ doesn't reply, probably since Impi Linux is 
> discontinued.
> 
> There are lots of issues in this page. I suggest to merge the page with 
> the information in the wiki, which would ease contributions.

http://www.debian.org/misc/children-distros is somewhat outdated.
There is very little activity on that site.
I would volunteer for merging that information in 
https://wiki.debian.org/Derivatives/Census
and dropping the content from www.debian.org, simply placing a link to the
wiki.

That would lose the 8 translated versions though (I can only take care about 
the english wiki page).

Comments? Would that be an improvement? Or would the content also get
as much outdated in the wiki? (don't know about the manpower on the wiki)



Holger


-- 

Created with Sylpheed 3.2.0 under the new
D E B I A N   L I N U X   7 . 0   W H E E Z Y !

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



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747857: add release

[Bastien ROUCARIES]

control: block 740495 by- 1

Add blocker


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734571: mc: [copy&] paste adds extra characters

[Egmont Koblinger]

Mainstream vte-0.36.2 release fixes the bug.

On Tue, May 6, 2014 at 3:50 PM, Egmont Koblinger  wrote:
> A fix for VTE is available at
> https://bugzilla.gnome.org/show_bug.cgi?id=729533 -- it used to handle
> bracketed paste mode differently than other terminals.
>
> I might create a patch for MC too (after all, it should work with current
> VTE), but after a first glimpse it doesn't look trivial.
>
>
> egmont


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747909: autopkgtest: Support docker.io virtualization for running tests

[Olivier Berger]

Package: autopkgtest
Version: 2.16
Severity: wishlist

Dear Maintainer,

It would be great to be able to run tests inside docker containers. AFAIU, this 
shouldn't differ too much from LXC, as docker uses Linux containers.

Thanks in advance.

Best regards,

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils  1.0.3
ii  debhelper  9.20140228
ii  libdpkg-perl   1.17.9
ii  python 2.7.5-5
ii  python-debian  0.1.21+nmu3

autopkgtest recommends no packages.

Versions of packages autopkgtest suggests:
pn  autopkgtest-xenlvm  
ii  lxc 1.0.0-8
ii  qemu-system 2.0.0+dfsg-4
ii  qemu-utils  2.0.0+dfsg-4
pn  schroot 

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#715278: intel-gpu-tools: "Couldn't map MMIO region: Resource temporarily unavailable" on intel_reg_read, after dist-upgrade

[Brandon Simmons]

On Mon, Mar 17, 2014 at 2:49 AM, Paul Wise  wrote:
> Control: tags -1 fixed-upstream
>
> On Sun, Jul 07, 2013 at 06:44:41PM -0400, Brandon Simmons wrote:
>
>> Actually I think the whole package is FUBAR for me:
>>
>>$ sudo intel_gpu_top
>>Couldn't map MMIO region: Resource temporarily unavailable
>>$ sudo intel_backlight --help
>>Couldn't map MMIO region: Resource temporarily unavailable
>
> I encountered this locally and fixed it by doing this:
>
>   * Upgrade to the latest upstream version (1.6)
>   * Comment out all of debian/patches
>   * Add libcairo2-dev, swig2.0, python3-dev to the build-depends
>   * Remove version.h and check-ndebug.h lines from tests/Makefile.am
>   * Remove the intel_forcewaked line from debian/rules
>   * Add usr/lib to debian/intel-gpu-tools.install
>   * Rebuild and install
>

As a user who hasn't done any debian packaging, I'd love a slightly
more hand-holdy explanation if a working package isn't forthcoming.
Sorry I can't be of any help at the moment.

Thanks,
Brandon

> --
> bye,
> pabs
>
> http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#649718: Guile language support in make

[Thorsten Glaser]

Andreas Schwab dixit:

>Thorsten Glaser  writes:
>
>> and the guile-2.0 Build-Depends on m68k because guile does not
>> work there (and nobody appears capable enough to debug it)?
>
>Index: guile-2.0.9/libguile/gsubr.c

Thanks Andreas!

Rob: I’ll try building guile-2.0 with the attached debdiff
and report success or failure afterwards. Can you please
review it if it’s okay for inclusion, if it indeed fixes
the bug? (And of course feeding back to upstream.)

bye,
//mirabilos
-- 
[00:02]  gecko: benutzt du emacs ?
[00:03]  nö  [00:03]  nur n normalen mac
[00:04]  argl   [00:04]  ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)diff -Nru guile-2.0-2.0.11+1/debian/changelog 
guile-2.0-2.0.11+1/debian/changelog
--- guile-2.0-2.0.11+1/debian/changelog 2014-04-23 19:19:00.0 +0200
+++ guile-2.0-2.0.11+1/debian/changelog 2014-05-12 21:34:12.0 +0200
@@ -1,3 +1,10 @@
+guile-2.0 (2.0.11+1-1+m68k.1) unreleased; urgency=low
+
+  * Apply patch from Andreas Schwab to fix bogus alignment
+assumptions and using the wrong register. (Closes: #649718)
+
+ -- Thorsten Glaser   Mon, 12 May 2014 21:33:08 +0200
+
 guile-2.0 (2.0.11+1-1) unstable; urgency=low
 
   * Incorporate upstream version 2.0.11.
diff -Nru 
guile-2.0-2.0.11+1/debian/patches/9000-Fix-alignment-and-m68k-registers.patch 
guile-2.0-2.0.11+1/debian/patches/9000-Fix-alignment-and-m68k-registers.patch
--- 
guile-2.0-2.0.11+1/debian/patches/9000-Fix-alignment-and-m68k-registers.patch   
1970-01-01 01:00:00.0 +0100
+++ 
guile-2.0-2.0.11+1/debian/patches/9000-Fix-alignment-and-m68k-registers.patch   
2014-05-12 21:32:47.0 +0200
@@ -0,0 +1,52 @@
+From sch...@linux-m68k.org Mon May 12 18:37:51 2014
+From: Andreas Schwab 
+Message-ID: <87y4y7uf4y@igel.home>
+To: Thorsten Glaser 
+Cc: Manoj Srivastava , debian-...@lists.debian.org
+Date: Mon, 12 May 2014 18:37:49 +0200
+X-Original-Subject: Re: Guile language support in make
+Subject: Fix alignment and registers for m68k
+
+Fix bogus alignment assumptions (on some architectures, “natural”
+alignment is not used, which means even an uint64_t is possibly
+unaligned, or aligned to only a 2 byte (m68k) or 4 byte boundary).
+
+Also, fix register name for m68k.
+--
+
+Thorsten Glaser  writes:
+
+> and the guile-2.0 Build-Depends on m68k because guile does not
+> work there (and nobody appears capable enough to debug it)?
+
+--- a/libguile/gsubr.c
 b/libguile/gsubr.c
+@@ -213,7 +213,7 @@
+ */
+ static const struct
+ {
+-  scm_t_uint64 dummy; /* ensure 8-byte alignment; perhaps there's a better 
way */
++  scm_t_uint64 dummy SCM_ALIGNED (sizeof (scm_t_uint64)); /* ensure 8-byte 
alignment; perhaps there's a better way */
+   const scm_t_uint8 bytes[121 * (sizeof (struct scm_objcode) + 16
+  + sizeof (struct scm_objcode) + 32)];
+ } raw_bytecode = {
+@@ -317,7 +317,7 @@ static const struct
+ 
+ static const struct
+ {
+-  scm_t_uint64 dummy; /* alignment */
++  scm_t_uint64 dummy SCM_ALIGNED (sizeof (scm_t_uint64)); /* alignment */
+   scm_t_cell cells[121 * 2]; /* 11*11 double cells */
+ } objcode_cells = {
+   0,
+--- a/libguile/vm-engine.h
 b/libguile/vm-engine.h
+@@ -74,7 +74,7 @@
+ #define FP_REG asm("%r16")
+ #endif
+ #ifdef __mc68000__
+-#define IP_REG asm("a5")
++#define IP_REG asm("a3")
+ #define SP_REG asm("a4")
+ #define FP_REG
+ #endif
diff -Nru guile-2.0-2.0.11+1/debian/patches/series 
guile-2.0-2.0.11+1/debian/patches/series
--- guile-2.0-2.0.11+1/debian/patches/series2014-04-23 19:11:29.0 
+0200
+++ guile-2.0-2.0.11+1/debian/patches/series2014-05-12 21:31:13.0 
+0200
@@ -1,2 +1,3 @@
 0001-Change-guile-to-guile-X.Y-for-info-pages.patch
 0002-Mark-mutex-with-owner-not-retained-threads-test-as-u.patch
+9000-Fix-alignment-and-m68k-registers.patch

Bug#747907: [cmake] [block transition][FTBFS with experimental] Imagemagick detection is completly screwed

[bastien ROUCARIES]

Package: cmake
Version: 2.8.12.1-1.2
Severity: important
control: block 740495 by -1
control: block 746228 by -1
control: block 740495 by 746228

Hi,

FindImageMagick.cmake is completly screwed and lead to FTBFS with imagemagick 
from experimental.

At least you should add CFLAGS and arch include dir in order to avoid :
/usr/include/ImageMagick-6/magick/magick-config.h:21:38: fatal error: 
magick/magick-baseconfig.h: No such file or directory

See #746228 for more detail.

Preferably you should use pkg-config in order to configure libs, cflags and 
libpath.

Bastien


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747535: systemd-fsck?

[Bas Wijnen]

On Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett wrote:
> > In other words: what isn't handled properly?  What should happen, and what 
> > does
> > happen?
> 
> Consider a system which has systemd installed, systemd-sysv *not* installed,
> and systemd used as PID 1 via init=/bin/systemd.  Since systemd-sysv is not
> already installed, "systemd-shim | systemd-sysv" will pull in systemd-shim
> instead, which will atttempt to supply services that conflict with systemd's.

Sounds like those packages should conflict with each other.  It isn't a reason
to uninstall anything.

More generally, the order of dependencies doesn't matter for what options the
user can choose.  If one of those options is buggy, it shouldn't be an option.

> we want to make sure that only the users who specifically *want* a
> non-default init run one,

I, as a user, did not expect to be moved over to systemd, and given the
discussions about it and the older TC decisions about network manager getting
its dependencies right (to stop forcing all of gnome onto the user's system),
it felt to me as something that was sneaked past me.  I don't want Debian to do
that.  I don't really care about what init system I use, but I do care that I
can trust my system.  When this happened, I was thinking "what else are they
going to force onto my system when I'm not watching closely enough?"  That's my
default attitude towards any install or upgrade on a proprietary system, and I
most certainly don't want to grow it for Debian users.

> It's easy enough for any user who *does* care to select a different set of
> installed packages.

It's not so much about caring which init system to use.  It's about being in
control over your own computer.  There are many packages that I use and while I
like them being upgraded to new versions, I don't like them to be replaced with
different programs.  Not unless I ask for it.

The exception is when the program I use is no longer supported.  When that
happens, I'll need something else, and using whatever is default on new
installs is a good choice in that case.  But again, as long as other init
systems are supported, I don't want to do anything to continue using them.  Not
even something "easy".

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747879: ben: allow to query Packages and Sources without a ben.cache file

[Johannes Schauer]

Hi,

Quoting Mehdi Dogguy (2014-05-12 20:51:21)
> Actually, after having checked the source code, "ben query" distinguish
> between Packages files and Sources files. Admittedly, its heuristics is based
> on the name of the package and the regexp could be extended but at least it
> is there.

I see it now too. Let me suggest to either make it case insensitive or at least

[Ss]ources

It would be nice if this was documented.

> If I understood your request correctly, you report contain two feature
> wishes:
> 1) the first one is already there

Correct.

> 2) the second one is ability to read from a local directory containing
> all files.

No, I just mentioned that because other tools can read appropriately named
Packages and Sources files from the cache-dir. I dont think this is an
important feature. Listing all Packages and Sources files one wants to query on
the commandline is absolutely sufficient in my opinion.

I think after documenting (and possibly) the regex you can close this bug.

cheers, josch


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747343: odt2txt: invalid media type in mailcap file

[Joerg Schiermeier, Bielefeld/Germany]

Package: odt2txt
Version: 0.4+git20100620-1.1
Followup-For: Bug #747343

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Confirmed.

The error occures in
/usr/lib/mime/packages/odt2txt (last line):

- -- application/application/vnd.sun.xml.writer; /usr/bin/sxw2txt '%s'; 
copiousoutput; description="OpenOffice.org/StarOffice Text"; 
nametemplate=%s.sxw; priority=0

++ application/vnd.sun.xml.writer; /usr/bin/sxw2txt '%s'; copiousoutput; 
description="OpenOffice.org/StarOffice Text"; nametemplate=%s.sxw; priority=0

That's the trick.

Yours sincerely
Joerg


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

Kernel: Linux 3.14-1-rt-amd64 (SMP w/1 CPU core; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages odt2txt depends on:
ii  libc62.18-5
ii  libzip2  0.11.2-1
ii  zlib1g   1:1.2.8.dfsg-1

odt2txt recommends no packages.

odt2txt suggests no packages.

- -- no debconf information

- -- debsums errors found:
debsums: changed file /usr/lib/mime/packages/odt2txt (from odt2txt package)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJTcR0eAAoJEOst77aRCakY7bEH/3ljICvCYJkLZzzOijU0n+t1
cqFbbVZlsqhDuz/dp7lMI1EtVfPnHfxLWH955t/4XYFwN55KDasHweJHs22TjLdm
4AiA7T0+zke0iOYvvqO8l5srvVrgepBU9/HyW36HqLnqdQ+b2EosQWaSZDwAqsAW
nnHR0ORdTmi5n8Gmxx5lg7aynDLxxBEgdtemza7DiuGgyVw67AkOyxEXjVgEOx7F
FCifEihPMIlbczahWzbvl3b2lMY03TJUSE7DmKDZDT9hc2/i2ry2Cud9AFkt4o+7
JGmL7CubU+cWCktNBnKe+WXqBJEFOqRLjr1B0nxBCp90ey483XPitxnKEVpeTNA=
=+VJl
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#746708: missing license in debian/copyright

[Andreas Tille]

Hi Thiago,

you should probably try

cme fix dpkg-copyright

If this does not help I can easily fix it in SVN - but this is probably
a good learning lession about cme (see Debian Med policy document what
packages you need to install).

Kind regards

 Andreas.


On Mon, May 12, 2014 at 01:57:16PM -0300, Thiago Franco Moraes wrote:
> Hi Andreas,
> 
> Sorry! I was out for some time. I added the copyright info about
> invesalius\gui\widgets\platebtn.py. I don't know if its correct, since I'm
> getting a lintian warning about the license name
> (field-name-typo-in-dep5-copyright licence).
> 
> Thanks!
> 
> 
> On Mon, May 12, 2014 at 11:32 AM, Andreas Tille  wrote:
> 
> > Hi Thiago,
> >
> > did you noticed this bug report?
> >
> > Kind regards
> >
> > Andreas.
> >
> > --
> > http://fam-tille.de
> >

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747906: kmix: almost always does not autostart on boot

[Nikita Pichugin]

Package: kmix
Version: 4:4.12.2-2
Severity: important

Dear Maintainer,

Roughly 9 out of 10 computer boots KDE does not load up completely: Kmix and
Klipper does not show up in tray, I can't end session or reboot/shutdown
computer through KDE menu (though "Ctrl+Alt+Backspace", "systemctl reboot" etc.
works), my keyboard backlight does not work (but screen backlight works), and
the main menu takes 5-10 seconds to show up after I click on the button. If I
hit Ctrl+Alt+Backspace, then the X server restarts, I log into KDE again and
everything is good. Rarely all components are loaded as it should be straight
after the boot. Looks like a race condition occurs somewhere during the KDE
load, I don't know.

I found a possibly related bug here:
https://bugs.kde.org/show_bug.cgi?id=323340
I disabled KmixD, I don't use Kwallet, I have no Pulseaudio installed (though
libpulse0 was installed as a dependency and I also get the annoying ".pulse"
directory in my home directory all the time). But still, the problem remains.

Thanks in advance!

P.S. Excuse me, please, if I filed a bug against a wrong package. In the linked
discussion maintainers suggested that it's probably a Kmix's problem, so I
filed a bug against kmix package.



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

Kernel: Linux 3.14-1-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

Versions of packages kmix depends on:
ii  kde-runtime  4:4.12.4-1
ii  libasound2   1.0.27.2-3
ii  libc62.18-5
ii  libcanberra0 0.30-2
ii  libkdecore5  4:4.12.4-1
ii  libkdeui54:4.12.4-1
ii  libplasma3   4:4.12.4-1
ii  libpulse-mainloop-glib0  5.0-2
ii  libpulse05.0-2
ii  libqt4-dbus  4:4.8.6+dfsg-1
ii  libqt4-xml   4:4.8.6+dfsg-1
ii  libqtcore4   4:4.8.6+dfsg-1
ii  libqtgui44:4.8.6+dfsg-1
ii  libsolid44:4.12.4-1
ii  libstdc++6   4.9.0-2

kmix recommends no packages.

kmix suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747875: ben: position of --config argument matters

[Johannes Schauer]

Hi,

Quoting Mehdi Dogguy (2014-05-12 20:28:17)
> Le 2014-05-12 16:39, Johannes Schauer a écrit :
> > Package: ben
> > Version: 0.6.11
> 
> This version is not released yet. The BTS should be confused now :)

whoops, sorry. As you can imagine that happened because I had ben packages
compiled from git installed.

> Yeah, and it doesn't look like a surprise, at least for me. A .ben file
> should be considered as way to put command-line options into a file. So in
> your example, "--config test.ben" is equivalent to "--archs armel".  Hence
> the described result.

I usually expect that configuration file values can be overwritten by command
line arguments. Naturally ben's way of interpreting the --config argument makes
sense as well but then I'd argue that it should be documented.

Classical case of: it's not a bug, it's a feature! :)

cheers, josch


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#715278: Any attempt to have intel-gpu-tools 1.6 which fixes this bug ?

[John Paul Adrian Glaubitz]

Hi!

>> Is there any attempt to get intel-gpu-tools 1.6 which fixes the bug ?
>>
>Not really, no.

Do you guys need help? Updating the package to the latest upstream
version should be a no-brainer using the Debian git packaging tools
unless I am missing something here.

I'd be happy to NMU.

Adrian

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#719329: vlc: Crackling sound at the begining of anything that VLC plays.

[Ross Vandegrift]

Package: vlc
Version: 2.0.3-5
Followup-For: Bug #719329


Hello,

This problem is reproducible on my laptop with vlc 2.0.3-5.  Like the original
poster, vlc is the only software affected.  Unlike the original poster, the
crackling only lasts a few seconds.  I've attached the log from "vlc
--extraintf=logger --log-verbose=2147483647 --logfile=vlc.log test.ogg"

I tried vlc 2.1.2-2+b3 in a jessie chroot.  There is a new kind of artifact at
the beginning of playback, but this problem is gone.

Ross

-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (500, 'stable'), (50, 'unstable'), (40, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.13-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages vlc depends on:
ii  dpkg  1.16.14
ii  fonts-freefont-ttf20120503-1
ii  libaa11.4p5-40
ii  libavcodec53  6:0.8.10-1
ii  libavutil51   6:0.8.10-1
ii  libc6 2.13-38+deb7u1
ii  libcaca0  0.99.beta18-1
ii  libfreetype6  2.4.9-1.1
ii  libfribidi0   0.19.2-3
ii  libgcc1   1:4.7.2-5
ii  libgl1-mesa-glx [libgl1]  8.0.5-4+deb7u2
ii  libice6   2:1.0.8-2
ii  libqtcore44:4.8.2+dfsg-11
ii  libqtgui4 4:4.8.2+dfsg-11
ii  libsdl-image1.2   1.2.12-2
ii  libsdl1.2debian   1.2.15-5
ii  libsm62:1.2.1-2
ii  libstdc++64.7.2-5
ii  libtar0   1.2.16-1+deb7u2
ii  libva-x11-1   1.0.15-4
ii  libva11.0.15-4
ii  libvlccore5   2.0.3-5
ii  libx11-6  2:1.5.0-1+deb7u1
ii  libxcb-composite0 1.8.1-2+deb7u1
ii  libxcb-keysyms1   0.3.9-1
ii  libxcb-randr0 1.8.1-2+deb7u1
ii  libxcb-render01.8.1-2+deb7u1
ii  libxcb-shape0 1.8.1-2+deb7u1
ii  libxcb-shm0   1.8.1-2+deb7u1
ii  libxcb-xfixes01.8.1-2+deb7u1
ii  libxcb-xv01.8.1-2+deb7u1
ii  libxcb1   1.8.1-2+deb7u1
ii  libxext6  2:1.3.1-2+deb7u1
ii  libxinerama1  2:1.1.2-1+deb7u1
ii  libxpm4   1:3.5.10-1
ii  vlc-nox   2.0.3-5
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages vlc recommends:
ii  vlc-plugin-notify  2.0.3-5
ii  vlc-plugin-pulse   2.0.3-5
ii  xdg-utils  1.1.0~rc1+git20111210-6

Versions of packages vlc suggests:
pn  videolan-doc  

Versions of packages vlc-nox depends on:
ii  dpkg   1.16.14
ii  liba52-0.7.4   0.7.4-16
ii  libasound2 1.0.25-4
ii  libass40.10.0-3
ii  libavahi-client3   0.6.31-2
ii  libavahi-common3   0.6.31-2
ii  libavc1394-0   0.5.4-2
ii  libavcodec53   6:0.8.10-1
ii  libavformat53  6:0.8.10-1
ii  libavutil516:0.8.10-1
ii  libbluray1 1:0.2.2-1
ii  libc6  2.13-38+deb7u1
ii  libcddb2   1.3.2-3
ii  libcdio13  0.83-4
ii  libcrystalhd3  1:0.0~git20110715.fdd2f19-9
ii  libdbus-1-31.6.8-1+deb7u1
ii  libdc1394-22   2.2.0-2
ii  libdca00.0.5-5
ii  libdirac-decoder0  1.0.2-6
ii  libdirac-encoder0  1.0.2-6
ii  libdirectfb-1.2-9  1.2.10.0-5
ii  libdvbpsi7 0.2.2-1
ii  libdvdnav4 4.2.0+20120524-2
ii  libdvdread44.2.0+20120521-2
ii  libebml3   1.2.2-2
ii  libfaad2   2.7-8
ii  libflac8   1.2.1-6
ii  libfontconfig1 2.9.0-7.1
ii  libfreetype6   2.4.9-1.1
ii  libfribidi00.19.2-3
ii  libgcc11:4.7.2-5
ii  libgcrypt111.5.0-5+deb7u1
ii  libgnutls262.12.20-8+deb7u1
ii  libgpg-error0  1.10-3.1
ii  libiso9660-8   0.83-4
ii  libkate1   0.4.1-1
ii  liblircclient0 0.9.0~pre1-1
ii  liblua5.1-05.1.5-4
ii  libmad00.15.1b-7
ii  libmatroska5   1.3.0-2
ii  libmodplug11:0.8.8.4-3+deb7u1+git20130828
ii  libmpcdec6 2:0.1~r459-4
ii  libmpeg2-4 0.4.1-3
ii  libmtp91.1.3-35-g0ece104-5
ii  libncursesw5   5.9-10
ii  libogg01.3.0-4
ii  libpng12-0 1.2.49-1
ii  libpostproc52  6:0.8.10-1
ii  libproxy0  0.3.1-6
ii  libraw1394-11  2.0.9-1
ii  libresid-builder0c2a   2.1.1-14
ii  libsamplerate0 0.1.8-5
ii  libschroedinger-1.0-0  1.0.11-2
ii  libshout3  2.2.2-8
ii  libsidplay22.1.1-14
ii  libsmbclient   2:3.6.6-6+deb7u3
ii  libspeex1  1.2~rc1-7
ii  libspeexdsp1   1.2~rc1-7
ii  libstdc++6 4.7.2-5
ii  libswscale26:0.8.10-1
ii  libtag1c2a 1.7.2-1
ii  libtheora0 1.1.1+dfsg.1

Bug#747261: apt: Please add support for cross-architecture conflicts

[David Kalnischkies]

Version: 0.9.7.2
Control: notfound -1 1.0.3

Hi,

On Tue, May 06, 2014 at 11:22:00PM +0200, Aurelien Jarno wrote:
> Could you please therefore add support for cross-architecture conflicts?

This is already supported – even in apt/wheezy – so I wonder how you
come to the conclusion that it is ignored. It is commit cef094c2ec8
if you want to have a look and/or don't trust me, but until further
notice I will close the bug as resolved because of this.

If you can demonstrate that it doesn't work I am all ears of course.


!
!! BEWARE !!!
!

Just that APT is supporting it doesn't make it magically supported by
everyone or even provides even the slightest hint that anyone will
try to support it, too (MultiArch itself being the best example).

So I have no idea at the moment what the status quo is in all the other
software dealing with dependencies! Attached is a small apt testcase with
which I have checked that dpkg supports it, but I have only run it on sid.
(if you want to run it yourself, build apt and run the script in
 /path/to/apt-source-tree/test/integration/ )
Not even the slightest idea what lintian/dak/buildds/… will make of it.


Note also that to the best of my knowledge this is documented/specified
nowhere. The MultiArchSpec [1] mentions it only as future work area.
APT supports it mainly because it was ridiculously easy to do it as the
heavy lifting is actually needed to support the non-specific conflicts.
(I am reasonably sure I had support for it in 2010 already, but broke it
 while refactoring and just reintroduced it in 2012 with a test)


Best regards

David Kalnischkies

[1] 
https://wiki.ubuntu.com/MultiarchSpec#Architecture-specific_Conflicts.2BAC8-Replaces
#!/bin/sh
set -e

TESTDIR=$(readlink -f $(dirname $0))
. $TESTDIR/framework
setupenvironment
configarchitecture 'amd64' 'sparc' 'armel'

buildsimplenativepackage 'libc6' 'amd64,sparc,armel' '1' 'stable' 'Multi-Arch: 
same'
buildsimplenativepackage 'libc6-i386' 'amd64' '1' 'stable' 'Conflicts: 
libc6:sparc'

setupaptarchive

testsuccess aptget install 'libc6:amd64' 'libc6:sparc' -y
testdpkginstalled 'libc6:amd64' 'libc6:sparc'
testdpkgnotinstalled 'libc6-i386' 'libc6:armel'

testsuccess aptget install libc6-i386 -y
testdpkginstalled 'libc6:amd64' 'libc6-i386'
testdpkgnotinstalled 'libc6:sparc' 'libc6:armel'

testsuccess aptget install libc6:armel -y
testdpkginstalled 'libc6:amd64' 'libc6:armel' 'libc6-i386'
testdpkgnotinstalled 'libc6:sparc'

testsuccess aptget install libc6:sparc -y
testdpkginstalled 'libc6:amd64' 'libc6:armel' 'libc6:sparc'
testdpkgnotinstalled 'libc6-i386'

testsuccess aptget purge 'libc6:*' 'libc6-i386' -y
testdpkgnotinstalled 'libc6:amd64' 'libc6:armel' 'libc6:sparc' 'libc6-i386'

# check that (the actually simpler) single arch is fine, too
configarchitecture 'amd64'
testfailure aptget install libc6:sparc -s
testsuccess aptget install libc6 libc6-i386 -y


signature.asc
Description: Digital signature

Bug#709803: zlib: Please ship minizip as a shared library

[Jonathan Nieder]

Hi Mark,

Mark Brown wrote:
> On Sun, May 11, 2014 at 08:29:46PM -0400, Michael Gilbert wrote:

>> I was in the process of putting together a patch addressing both of
>> these requests, and hadn't yet finished this mail, which has the
>> desired context.
>
> This doesn't address the issue in the original report: this isn't
> something we should be doing off our own back in Debian, it's something
> that upstream should be doing.  The issue isn't that it's hard to build
> shared libraries, the issue is that it's hard to maintain them and so it
> needs to be something that upstream are engaged with.

I'm a little puzzled.  Upstream has rules for installing libminizip at
contrib/minizip/Makefile.am.  Are you saying that they are buggy or
unmaintained?

> Please discuss this with upstream.

If you have bug reports in upstream's libminizip support, I'm happy to
work on them upstream.  Last time I checked, it Just Worked (tm).

I don't think it would make sense to go upstream and say "Mark Brown
is not happy with how contrib/minizip deals with the shared library.
Discuss" without further details. ;-)

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org