date:20141104

severity 768119 wishlist
retitle 768119 warn of syntactic errors in version deps
thanks

On Wed, 05 Nov 2014, Norbert Preining wrote:
libwaei2 ((>= ${source:Upstream-Version})

double opening parenthesis, could be checked by lintian for this
kind of syntax errors.

Retitle, adjust severity

Thanks

Norbert


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



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

Bug#766459: please don't upload this to wheezy

2014-11-04 Thread Adam Borowski

Hi!

For reasons I explained in #767999, hacking debootstrap to configure
base-passwd and base-files in a specific order is neither sufficient nor
necessary.  It does work around the problem for those running debootstrap
from fully upgraded unstable (and if it was uploaded to stable, wheezy)
but doesn't help in any other use cases.

I have proposed a different fix to base-files.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


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

Bug#768119: lintian: false positive on weak-library-dev-dependency

Package: lintian
Version: 2.5.30
Severity: normal

I have
E: gwaei source: weak-library-dev-dependency libwaei-dev on libwaei2 
((>= ${source:Upstream-Version}), libwaei2 (<< ${source:Upstream-Version}+1~)

which is exactely what lintian suggests:

 Sometimes, such as for -dev packages that are architecture-independent to
 not break binNMUs or when one doesn't want to force a tight dependency, a
 weaker dependency is warranted.  Something like (>=
 ${source:Upstream-Version}), (<<
 ${source:Upstream-Version}+1~), possibly using
 ${source:Version} instead, is the right approach.  a

Thanks


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

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

Versions of packages lintian depends on:
ii  binutils   2.24.90.20141104-1
ii  bzip2  1.0.6-7
ii  diffstat   1.58-1
ii  file   1:5.20-1
ii  gettext0.19.3-1
ii  hardening-includes 2.6
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.29+b2
ii  libarchive-zip-perl1.39-1
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.37-1+b1
ii  libdigest-sha-perl 5.93-1
ii  libdpkg-perl   1.17.21
ii  libemail-valid-perl1.195-1
ii  libfile-basedir-perl   0.03-1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-2+b1
ii  libparse-debianchangelog-perl  1.2.0-1.1
ii  libtext-levenshtein-perl   0.11-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.64-1
ii  man-db 2.7.0.2-3
ii  patchutils 0.3.3-1
ii  perl [libdigest-sha-perl]  5.20.1-2
ii  t1utils1.38-1

Versions of packages lintian recommends:
ii  libautodie-perl 2.25-1
ii  libperlio-gzip-perl 0.18-3+b1
ii  perl5.20.1-2
ii  perl-modules [libautodie-perl]  5.20.1-2

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.17.21
ii  libhtml-parser-perl3.71-1+b2
ii  libtext-template-perl  1.46-1
ii  libyaml-perl   1.13-1
ii  xz-utils   5.1.1alpha+20120614-2

-- 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#768120: networking: /etc/init.d/networking fails to terminate when using static IP address

2014-11-04 Thread Gary Dale

Package: ifupdown
Version: 0.7.8
Severity: normal
File: networking

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
Some time back I switched a server to use a static IP address instead of using 
a 
DHCP address reserved for that machine. After a recent kernel update, I 
rebooted the
machine but it failed to restart. It stopped booting when bringing up the 
networking. It
was not hung as it would show messages on the screen when I plugged or 
unplugged USB
devices, but it wouldn't respond to keyboard input nor continue to a login 
prompt.

   * What exactly did you do (or not do) that was effective (or ineffective)?
I tried booting into single-user mode. This produced some more networking 
messages but
still wouldn't move past the networking.

Here's what was on the screen when the system stopped the boot process in 
single-user mode:
[  181.805309] r8169 :03:00.0: firmware: agent loaded rtl_nic/rtl8168e-3.fw 
into memory
[  181.917202] r8169 :03:00.0: eth0: link down
[  181.920948] r8169 :03:00.0: eth0: link down
[  181.928316] ADDRCONF(NETDEV_UP): eth0: link is not ready
[  184.284849] r8169 :03:00.0: eth0: link up
[  184.292178] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

I rebooted into sysrescuecd and removed the /etc/rcS.d/S13networking link then 
rebooted
into single-user mode again. After logging in as root, I ran 
/etc/init.d/networking start.
It again failed to complete, but I was able to kill the process and return to a 
command
prompt. ifconfig showed that the network had started so I logged out and 
continued the 
boot.

   * What was the outcome of this action?
The server is running normally now, but I can't reboot it remotely if needed 
because it
needs a local presence to start the networking.

   * What outcome did you expect instead?
The server is located in a different city and it didn't occur to me when I was 
there to
try reverting to DHCP to see if that fixes the problem. I don't want to try it 
remotely
since a failure would mean another trip.


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


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

Kernel: Linux 3.2.0-4-amd64 (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

Versions of packages ifupdown depends on:
ii  dpkg 1.16.15
ii  initscripts  2.88dsf-41+deb7u1
ii  iproute  20120521-3+b3
ii  libc62.13-38+deb7u6
ii  lsb-base 4.1+Debian8+deb7u1

ifupdown recommends no packages.

Versions of packages ifupdown suggests:
ii  isc-dhcp-client [dhcp-client]  4.2.2.dfsg.1-5+deb70u6
ii  net-tools  1.60-24.2
pn  ppp
pn  rdnssd 

-- 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#767999: base-files: fails to install with pre-jessie debootstrap

2014-11-04 Thread Adam Borowski

Control: retitle -1 base-files: fails to install with pre-jessie debootstrap
Control: reassign -1 base-files
Control: found -1 base-files/7.6
Control: tags -1 +patch

(TL;DR: there's a working patch attached)

On Tue, Nov 04, 2014 at 09:04:14AM +0100, Santiago Vila wrote:
> On Tue, Nov 04, 2014 at 01:05:11AM +0100, Adam Borowski wrote:
> > [...]
> > While #766459 fixed debootstrapping with jessie's debootstrap, I'm afraid
> > this doesn't solve most use cases that include upgrading, installation from
> > non-DI or installation in hosting scenarios.
> > 
> > For a long time, most versions of debootstrap in use will come from wheezy,
> > Red Hat or some random live-cd.  None of those can install jessie :(
> > 
> > Thus, I'm afraid that fixing *new* copies of debootstrap is not enough,
> > and this bug needs to be solved in base-files or base-passwd.
> 
> For the umpteenth time: This is a bug in debootstrap and that's where
> it should be fixed!!!

Even if it was, there's no way an updated version of debootstrap gets to
machines of a significant part of users.  An upload to stable can apply only
to those running an up-to-date version of wheezy.

How do you propose changing debootstrap on already burned CDs?  How do you
propose updating squeeze, current and past versions of Ubuntu, Knoppix,
GRML, etc (live CDs often get used to install Debian).  Heck, even Red Hat
does include debootstrap packages -- how can you update that?  And without
working debootstrap, forget about Debian containers, etc.

> (And you should really read the full logs for Bug#766459 to understand
> this instead of killing the messenger

The guilty party for this bug is either base-files or base-passwd.  Neither
dpkg nor debootstrap are at fault: that this problem did not show up before
was an issue akin to relying on hash order.

Thus, it can be possibly fixed only in base-files or base-passwd.  By a
literal reading of the policy it's more of a fault of the latter, however I
can't think of a fix there without some REALLY nasty side effects: that
package would need to ship /etc/passwd and /etc/group them somehow divert
them away so it's installed only the first time.  On the other hand, it is
easy to work around in base-files' postinst.

> base-files does not do anything which is not allowed by policy).

Policy 3.8.:
# all `essential' packages must supply all of their core functionality even
# when unconfigured

That's the core functionality of base-passwd.

> People who do not understand the essential flag keep filing bugs
> against base-files.

Please point out how I misread policy 3.8.

But, I did manage to prepare a patch that seems to be working.
As it's impossible for an admin to renumber system groups in the middle of
a debootstrap run, it's enough to use numeric values of groups base-files
need (root, staff, mail and utmp).  In the patch I'm proposing, these are
used if /etc/group is missing.  That's a hack, but a good deal better than
alternatives I can think of.

Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.
diff -Nurd base-files-7.10/debian/postinst.in base-files-7.10.new/debian/postinst.in
--- base-files-7.10/debian/postinst.in	2014-10-27 13:36:30.0 +0100
+++ base-files-7.10.new/debian/postinst.in	2014-11-05 05:35:03.801097773 +0100
@@ -1,12 +1,25 @@
 #!/bin/sh
 set -e

+# During debootstrap /etc/passwd and /etc/group may not exist yet.
+if [ -f /etc/group ]
+  then
+STAFF=staff
+MAIL=mail
+UTMP=utmp
+  else
+STAFF=50
+MAIL=8
+UTMP=43
+fi
+ROOT=0
+
 install_local_dir() {
   if [ ! -d $1 ]; then
 mkdir -p $1
   fi
   if [ -f /etc/staff-group-for-usr-local ]; then
-chown root:staff $1 2> /dev/null || true
+chown $ROOT:$STAFF $1 2> /dev/null || true
 chmod 2775 $1 2> /dev/null || true
   fi
 }
@@ -20,7 +33,7 @@
 install_directory() {
   if [ ! -d /$1 ]; then
 mkdir /$1
-chown root:$3 /$1
+chown $ROOT:$3 /$1
 chmod $2 /$1
   fi
 }
@@ -58,17 +71,17 @@
   install_from_default /usr/share/base-files/dot.bashrc/root/.bashrc
   install_from_default /usr/share/base-files/profile   /etc/profile
   install_from_default /usr/share/base-files/motd  /etc/motd
-  install_directory mnt   755 root
-  install_directory srv   755 root
-  install_directory opt   755 root
-  install_directory etc/opt   755 root
-  install_directory var/opt   755 root
-  install_directory media 755 root
-  install_directory var/mail 2775 mail
+  install_directory mnt   755 $ROOT
+  install_directory srv   755 $ROOT
+  install_directory opt   755 $ROOT
+  install_directory etc/opt   755 $ROOT
+  install_directory var/opt   755 $ROOT
+  install_directory media 755 $ROOT
+  install_directory var/mail 2775 $M

Bug#768118: [icedove] Errors in NEWS.Debian

2014-11-04 Thread Filipus Klutiero


Package: icedove
Version: 31.2.0-1
Severity: minor

NEWS.Debian.gz contains:

icedove (31.2.0-1) unstable; urgency=low

  Mozilla implemented TLS 1.2 in NSS version 3.15.1 and Thunderbird 31.0 uses
  this as the default. It won't fall back to older protocol versions.

  This means every connection from Thunderbird/Icedove to a mail server will
  using TLS 1.2 with no fall back if you have configured TLS/SSL or STARTTLS for
  your connections.

  Some users reported trouble by this behavior. In case you are unable to get
  or sent any mails anymore from or to your mail server please ensure that
  your email provider is fully supporting TLS 1.2 if possible.

  There were reports that this causes problems with some providers (Bug
  #761245). This is usually indicated by:

   "connection to SMTP server was lost in the middle of the transaction."

  For information on how to fix that check README.Debian.

 -- Carsten Schoenert   Wed, 15 Oct 2014 18:38:00 +0200


"will using" is incorrect. This could read "will use".

"Some users reported trouble by this behavior." should surely read "Some users 
reported trouble *with* this behavior."

"to get or sent" should read "to get or send".

In the last paragraph, a comma is missing after "that".

--
Filipus Klutiero
http://www.philippecloutier.com

Bug#767535: CVE-2014-8760

2014-11-04 Thread udoprog

I'm working on a patch for this here:

https://github.com/udoprog/pkg-ejabberd/commit/bca4b267ac2c90dd092adfcc7a365d37017f4774.patch

If everything looks all right we can bake a release soon.


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

Bug#764974: ejabberd: postinst uses /usr/share/doc content (Policy 12.3)

2014-11-04 Thread udoprog

Hey!

I've been working on a patch for this, it can be found here:

https://github.com/udoprog/pkg-ejabberd/commit/d1baef0327b2652f268b731f6dae215abe4d9678.patch

Tested with:

  dpkg --path-exclude=/usr/share/doc/ejabberd/examples/ejabberd.yml.example -i 



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

Bug#766464: gksu pluma sets the ownership of /run/user/1000/dconf/user to root:root

2014-11-04 Thread Linas Vepstas

Thanks Mike,

The package is "libpam-systemd". A number of packages depend on it,
even if one is not using systemd.

>> http://cgit.freedesktop.org/systemd/systemd/commit/?id=baae0358f349870544884e405e82e4be7d8add9f

Above really does seem to provide the fix, based on the commit
message, and comments in the code.

> After reassigning, you should also mail to the bug with details, so that the
> new bug addressees notice what we want from them.

The primary issue is that, when one says "su - root", the code (circa
line 385 of src/login/logind-dbus.c of the above patch) used to set
the environment variable XDG_RUNTIME_DIR to
XDG_RUNTIME_DIR=/run/user/1000 (or whatever your original login uid
was, if not 1000). This, in turn, can sometimes lead the ownership of
/run/user/1000/dconf/user to root:root ... for instance, if you start
pluma, as root, in that shell. When you starrt pluma, gtk
initializes, causes dconf to initialize, which writes and chowns
/run/user/1000/dconf/user to root.

All subsequent gtk apps/daemons/services, started under your normal
non-root uid will now fail, as they also gtk+dconf initialize, but
now, they no longer have access to /run/user/1000/dconf/user ...
which then triggers a large assortment and cascade of different
bugs/fails, as different gtk apps bomb in different ways when the
dconf init step fails.

Based on bug history in the older redhat-rawhide bugzilla, I'm
guessing that there are probably a dozen different debian bugs that
are dupes, but don't know it yet.

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

Bug#768047: [Aptitude-devel] Bug#768047: aptitude: doesn't inform a user that a package will no longer receive updates when it obsolete in the target suite, but not yet for an older suite

2014-11-04 Thread Axel Beckert

Control: severity -1 wishlist

Hi Christoph,

Christoph Anton Mitterer wrote:
> But since you seem to be neither member of the security team

It's correct that I'm no member of the security team.

> (and I guess even that is probably not the ultimate group to decided
> where the security tag applies to)

AFAIK they actually _are_ the ultimate group to decided where the
security tag applies to. But inbetween there comes the package's
maintainer(s)...

> or maintainer of aptitude (or did I miss something),...

It indeed seems as if you missed some facts:
https://alioth.debian.org/project/memberlist.php?group_id=30020

You may also want to have a look at who signed the latest and some
earlier uploads of aptitude: https://tracker.debian.org/pkg/aptitude

And as long as I'm the only aptitude team member who has an opinion
about this bug report, you should consider my opinion as being the
maintainer's opinion -- and respect it accordingly.

> Just because e.g. lcms1 is no longer upgraded in unstable, this
> should mean that aptitude proposes it to downgrade to a "new" older
> version, when a security update comes out.

I disagree. Such a behaviour would be wrong and should be considered a
bug if it appears with the default pinning. Changing aptitude's
behaviour into that direction is solely a job for pinning (you can
enforce downgrades through pinning if you really prefer that) and
hence the local system administrator's job.

The list of upgradable packages is controlled by pinning in similar
ways. And I don't think that aptitude should override pinning (be it
default or local) in any way unless the local admin overrides it
interactively or on the commandline. (Which IMHO is easier to do with
aptitude than with apt.)

Additionally downgrades are officially _not_ supported, even if that
downgrade may fix a security issue. Downgrades may or may not work
(see e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764503#12)
and I don't think, aptitude should by default suggest downgrades in a
prominent way unless they are officially supported. And very often
they are also impossible in the setup you described due dependency
conflicts(*).

The security tag is debatable. The said feature may involve security
updates under the circumstances you described. I know that this kind
of setup is not that uncommon(*), but it's still very specific and
especially _unsupported_. I still think we should not tag bug reports
as security if they only involve unsupported setups (unstable with
security updates from stable) and especially if they involve
officially unsupported features (downgrading).

I though agree that having a group showing "newer than in archive"
packages would be a helpful _feature_ in general. The fact that this
feature is not yet there is _not_ a bug and hence it does not deserve
any severity higher that wishlist -- also because you already can
search for according packages or limit the view to them as explained
in my previous mail.

(*) I have two machines with such setup myself. Downgrading
packages to stable usually leads to dependency conflicts. And
usually the only viable solution to fix such issues is to
uninstall the packages in question completely. This counts for
security updates in stable as well as other stable packages.

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#767994: cross-gcc-4.9-armhf: Will not build arm-linux-gnueabihf-4.9.

2014-11-04 Thread Peter Chubb

> "Wookey" == Wookey   writes:

Wookey> What version of gcc-4.9-source do you have installed. This
Wookey> dependency is not versionned in the current package and
Wookey> clearly should be as it needs 4.9.1-19 due to incompatible
Wookey> changes vs. previous 4.9.1 versions. I've fixed that in local
Wookey> git.

dpkg -l gcc-4.9-source
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  gcc-4.9-source 4.9.1-19 all  Source of the GNU Compiler Collec

I tried sanitising my environment before compiling, with
  env PATH=/bin:/usr/bin debuild -b

I get the same error as before.

In the end, just to get things to compile to completion, I did
 cd /usr/src
 sudo ln -s . debug


--
Dr Peter Chubb  peter.chubb AT nicta.com.au
http://www.ssrg.nicta.com.au  Software Systems Research Group/NICTA


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

Bug#768117: debian-policy: WSGI API must distinguish between Python 2 and 3

2014-11-04 Thread Brian May

Package: debian-policy
Severity: normal

The httpd-wsgi virtual name was added in response to #588497.

However, as per the following email:

https://lists.debian.org/debian-devel/2014/09/msg00719.html

"WSGI is an API, not a wire protocol. The Python version of the WSGI
server would also be the Python version the code is run under, so we
must distinguish between Python 2 and 3. The best way would probably be
to specify that httpd-wsgi is for Python 2 and create a httpd-wsgi3
virtual package for Python 3."

This means, as currently written, Python2 packages that depend on
httpd-wsgi might get a Python3 implementation of WSGI, which won't work.

Similarly, Python3 packages that depend on httpd-wsgi might get a
Python2 implementation of WSGI which also won't work.

We need two virtual package names, one for Python2 and one for Python3.

I raised this issue on debian-devel, but unfortunately got noreponse, so
am raising it here.

Thanks


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

Bug#712830: Change owner to Matthew Ernisse

2014-11-04 Thread Iain R. Learmonth

owner 712830 merni...@ub3rgeek.net
kthxbye

Hi,

Changing the owner of the bug to Matthew Ernisse as he has been working on
this package and it is basically ready for upload.

More details in this thread on the debian-hams mailing list:

  https://lists.debian.org/debian-hams/2014/11/msg1.html

Thanks,
Iain.

-- 
e: i...@fsfe.orgw: iain.learmonth.me
x: i...@jabber.fsfe.org t: +447875886930
c: MM6MVQ  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49


pgpo4J17__BQF.pgp
Description: PGP signature

Bug#660952: evince-gtk: Don't print bold font (PDF generated with TCPDF, font is supposed to be embedded)

2014-11-04 Thread Bzzzz

On Tue, 4 Nov 2014 14:23:43 +
Pedro Beja  wrote:

> Hey Jean,
> 
> this is an old bug.
> 
> Could you please still reproduce this issue with newer evince version
> like 3.4.0-3.1 or 3.14.1-1 ?
> 
> thanks
> regards
> althaser

Hi Pedro,

effectively, this is gone :)

Thanks & regards,
JY


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

Bug#768116: connman-vpn: fails to upgrade from 'wheezy' - trying to overwrite /usr/lib/x86_64-linux-gnu/connman/scripts/openvpn-script

Package: connman-vpn
Version: 1.21-1.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Selecting previously unselected package connman-vpn.
  Unpacking connman-vpn (from .../connman-vpn_1.21-1.1_amd64.deb) ...
  dpkg: error processing /var/cache/apt/archives/connman-vpn_1.21-1.1_amd64.deb 
(--unpack):
   trying to overwrite 
'/usr/lib/x86_64-linux-gnu/connman/scripts/openvpn-script', which is also in 
package connman 1.0-1.1+wheezy1+b1
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/connman-vpn_1.21-1.1_amd64.deb


cheers,

Andreas


connman=1.0-1.1+wheezy1+b1_connman-vpn=1.21-1.1.log.gz
Description: application/gzip

Bug#768115: ow-tools: fails to upgrade from 'wheezy' - trying to overwrite /usr/share/man/man1/owtap.1.gz

Package: ow-tools
Version: 2.9p5-1.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Selecting previously unselected package ow-tools.
  Unpacking ow-tools (from .../ow-tools_2.9p5-1.1_all.deb) ...
  dpkg: error processing /var/cache/apt/archives/ow-tools_2.9p5-1.1_all.deb 
(--unpack):
   trying to overwrite '/usr/share/man/man1/owtap.1.gz', which is also in 
package ow-shell 2.8p15-1
  Errors were encountered while processing:
   /var/cache/apt/archives/ow-tools_2.9p5-1.1_all.deb


cheers,

Andreas


ow-shell=2.8p15-1_ow-tools=2.9p5-1.1.log.gz
Description: application/gzip

Bug#768114: hhsuite-doc: fails to upgrade from 'wheezy' - trying to overwrite /usr/share/doc-base/hhsuite

Package: hhsuite-doc
Version: 2.0.16-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Selecting previously unselected package hhsuite-doc.
  Unpacking hhsuite-doc (from .../hhsuite-doc_2.0.16-3_all.deb) ...
  dpkg: error processing /var/cache/apt/archives/hhsuite-doc_2.0.16-3_all.deb 
(--unpack):
   trying to overwrite '/usr/share/doc-base/hhsuite', which is also in package 
hhsuite 2.0.15-1
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/hhsuite-doc_2.0.16-3_all.deb


cheers,

Andreas


hhsuite=2.0.15-1_hhsuite-doc=2.0.16-3.log.gz
Description: application/gzip

Bug#767842: ruby-actionpack-action-caching: fails to upgrade from 'wheezy' - trying to overwrite /usr/lib/ruby/vendor_ruby/action_controller/caching/actions.rb

Followup-For: Bug #767842

Similar problems exist with ruby-actionpack-3.2:

  Selecting previously unselected package ruby-actionpack.
  Unpacking ruby-actionpack (from .../ruby-actionpack_2%3a4.1.6-2_all.deb) ...
  Replacing files in old package ruby-actionpack-3.2 ...
  Selecting previously unselected package ruby-actionpack-action-caching.
  Unpacking ruby-actionpack-action-caching (from 
.../ruby-actionpack-action-caching_1.1.1-1_all.deb) ...
  dpkg: error processing 
/var/cache/apt/archives/ruby-actionpack-action-caching_1.1.1-1_all.deb 
(--unpack):
   trying to overwrite 
'/usr/lib/ruby/vendor_ruby/action_controller/caching/actions.rb', which is also 
in package ruby-actionpack-3.2 3.2.6-6+deb7u2
  Errors were encountered while processing:
   /var/cache/apt/archives/ruby-actionpack-action-caching_1.1.1-1_all.deb


Cheers,

Andreas


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

Bug#768113: mke2fs -c -c should also report total percentage

2014-11-04 Thread 積丹尼 Dan Jacobson

Package: e2fsprogs
Version: 1.42.12-1
Severity: wishlist
File: /sbin/mke2fs

mke2fs -c -c should also report total percentage.
Apparently it makes three passes, each time reporting just that pass'
percentage of completion. But then it just starts on the next pass.
The user is left with no idea of when it will end.
So it should do a better job of giving a user an idea of when it will
end.

Here we also see some other things, which I can't explain. Maybe
hardware problems?:

Weird, mke2fs succeeds but then fsck fails,

# mke2fs -t ext4 -c /dev/sdd2
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 512000 1k blocks and 128016 inodes
Filesystem UUID: 0e201fb0-72c5-457f-aef0-36641dbaac6f
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409

Checking for bad blocks (read-only test): done
Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

# fsck.ext4 /dev/sdd2
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdd2

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 
 or
e2fsck -b 32768 

(dmesg doesn't show anything special.)
(Also the tips to do dmesg|tail should also perhaps mention journalctl|tail)

# mke2fs -t ext4 -c -c /dev/sdd2
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 512000 1k blocks and 128016 inodes
Filesystem UUID: bd2c590f-bf83-4167-853d-ee1220055416
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409

Testing with pattern 0xaa: done
Reading and comparing: done
Testing with pattern 0x55: done
Reading and comparing: done
Testing with pattern 0xff: done
Reading and comparing: done
Testing with pattern 0x00: done
Reading and comparing: done
Allocating group tables: mke2fs: Could not allocate block in ext2 filesystem 
while trying to allocate filesystem tables

#

Wonder if that was bad.

Problem #2: -c -c prints several % done making the user think we're
almost done, only to begin on a different pattern.

Also the above 0/0/ error report lines disappeared with the final
carriage return, so I can't copy them here.

Odd, after this everything works fine.


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

Bug#768112: slurm-client: fails to upgrade from 'wheezy' - trying to overwrite /usr/bin/sinfo

Package: slurm-client
Version: 14.03.9-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Selecting previously unselected package slurm-client.
  Unpacking slurm-client (from .../slurm-client_14.03.9-3_amd64.deb) ...
  dpkg: error processing 
/var/cache/apt/archives/slurm-client_14.03.9-3_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/sinfo', which is also in package sinfo 0.0.46-2
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/slurm-client_14.03.9-3_amd64.deb

For more information also see https://bugs.debian.org/764441

clurm-client needs to mirror the conflict with sinfo


cheers,

Andreas


sinfo=0.0.46-2_slurm-client=14.03.9-3.log.gz
Description: application/gzip

Bug#768111: unblock: sphinx-testing/0.6.0-2

2014-11-04 Thread Kouhei Maeda

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

Please unblock package sphinx-testing

This package was added Build-Depends of follow packages newly,

* sphinxcontrib-blockdiag >= 0.8.0
* sphinxcontrib-actdiag >= 1.5.0
* sphinxcontrib-seqdiag >= 0.9.0
* sphinxcontrib-nwdiag >= 0.8.0

but this packages is not yet in the testing,
the above packages will drop from testing.

unblock sphinx-testing/0.6.0-2

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

Kernel: Linux 3.12-1-amd64 (SMP w/7 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
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#768110: wget: strange progress display with certain locale settings

2014-11-04 Thread Edward J. Shornock

Package: wget
Version: 1.16-1
Severity: normal

After the latest upgrade of wget in Sid, I see output like the following
when downloading files: http://imgbin.org/index.php?page=image&id=20771

I'm including a link to a screenshot because copying & pasting doesn't
reproduce what I see on the screen, e.g.

$ wget 
http://cdimage.debian.org/debian-cd/7.7.0/multi-arch/iso-cd/debian-7.7.0-amd64-i386-netinst.iso
--2014-11-05 03:55:59--  
http://cdimage.debian.org/debian-cd/7.7.0/multi-arch/iso-cd/debian-7.7.0-amd64-i386-netinst.iso
Selvitetään osoitetta cdimage.debian.org (cdimage.debian.org)... 
2001:6b0:e:2018::163, 2001:6b0:e:2018::173, 130.239.18.173, ...
Yhdistetään palvelimeen cdimage.debian.org 
(cdimage.debian.org)|2001:6b0:e:2018::163|:80... yhdistetty.
HTTP-pyyntö lähetetty, odotetaan vastausta... 302 Found
Sijainti: 
http://caesar.acc.umu.se/debian-cd/7.7.0/multi-arch/iso-cd/debian-7.7.0-amd64-i386-netinst.iso
 [seurataan]
--2014-11-05 03:55:59--  
http://caesar.acc.umu.se/debian-cd/7.7.0/multi-arch/iso-cd/debian-7.7.0-amd64-i386-netinst.iso
Selvitetään osoitetta caesar.acc.umu.se (caesar.acc.umu.se)... 
2001:6b0:e:2018::142, 130.239.18.142
Yhdistetään palvelimeen caesar.acc.umu.se 
(caesar.acc.umu.se)|2001:6b0:e:2018::142|:80... yhdistetty.
HTTP-pyyntö lähetetty, odotetaan vastausta... 200 OK
Pituus: 508559360 (485M) [application/x-iso9660-image]
Tallennetaan kohteeseen ”debian-7.7.0-amd64-i386-netinst.iso”

debian-7.7.0-amd64-i386-netinst.iso0%[  
]   1,10M  1,36MB/s 
 debian-7.7.0-amd64-i386-netinst.iso0%[ 
 ]   1,29M  1,27MB/s
  debian-7.7.0-amd64-i386-netinst.iso0%[
  ]   1,52M  1,25MB/s   
   debian-7.7.0-amd64-i386-netinst.iso0%[   
   ]   1,86M  1,31MB/s  
debian-7.7.0-amd64-i386-netinst.iso0%[  
]   2,24M  1,38MB/s 
 debian-7.7.0-amd64-i386-netinst.iso0%[ 
 ]   2,58M  1,42MB/s
  debian-7.7.0-amd64-i386-netinst.
 iso0%[ 
 ]   2,96M  1,47MB/s  
debian-7.7.0-amd64-i386-netinst.iso0%[  
]   3,31M  1,49MB/s 
 debian-7.7.0-amd64-i386-netinst.iso0%[ 
 ]   3,58M  1,48MB/s
  debian-7.7.0-amd64-i386-netinst.iso0%[
  ]   3,88M  1,48MB/s   
   debian-7.7.0-amd64-i386-netinst.iso0%[   
   ]   4,19M  1,48MB/s  
debian-7.7.0-amd64-i386-netinst.iso0%[  
]   4,50M  1,49MB/s   eta 
5m 23s debian-7.7.0-amd64-i386-netinst.iso0%[ 
  ]   4,79M  
1,52MB/s   eta 5m 23s debian-7.7.0-amd64-i386-netinst.iso1%[
  ]   5,09M 
 1,50MB/s   eta 5m 23s  ^C


I do not see this behavior with the the previous package 1.15-1+b1. I also do
not see output like this if I change my locale to en_US.UTF-8 or C.



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (999, 'unstable'), (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armel
mips
mipsel

Kernel: Linux 3.16-3-amd64 (SMP w/6 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages wget depends on:
ii  libc6  2.19-12
ii  libgnutls-deb0-28  3.3.8-3
ii  libidn11   1.29-1
ii  libnettle4 2.7.1-3
ii  libpsl00.5.1-1
ii  libuuid1   2.25.2-2
ii  zlib1g 1:1.2.8.dfsg-2

Versions of packages wget recommends:
ii  ca-certificates  20141019

wget 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#768107: ann: Fail of tests in debci (autopkgtest)

2014-11-04 Thread Lucas Kanashiro

Source: ann
Version: 1.1.2
Severity: normal
Tags: patch
User: autopkgtest-de...@lists.alioth.debian.org
Usertags: autopkgtest

Dear Maintainer,

The tests are failing in debci using autopkgtest. Below the
autopkgtest's log:

adt-run [23:12:48]: test build1: [---
cp: cannot stat ‘ann_test.cpp’: No such file or directory
adt-run [23:12:48]: test build1: ---]
adt-run [23:12:48]: test build1:  - - - - - - - - - - results - - - - -
- - - - -
build1   FAIL non-zero exit status 1
adt-run [23:12:49]: test build1:  - - - - - - - - - - stderr - - - - - -
- - - -
cp: cannot stat ‘ann_test.cpp’: No such file or directory
adt-run [23:12:50]: test build2: [---
cp: cannot stat ‘ann_test.cpp’: No such file or directory
adt-run [23:12:50]: test build2: ---]
adt-run [23:12:50]: test build2:  - - - - - - - - - - results - - - - -
- - - - -
build2   FAIL non-zero exit status 1
adt-run [23:12:50]: test build2:  - - - - - - - - - - stderr - - - - - -
- - - -
cp: cannot stat ‘ann_test.cpp’: No such file or directory

This occur because of the wrong path of files used in tests, to correct
this I only added de $TESTDIR (= debian/tests) variable before the name
of files, then all the tests can find the files and the suite test is
ok.

Thanks for consider it!

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

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -rupN ann-1.1.2+doc.orig/debian/tests/build1 ann-1.1.2+doc/debian/tests/build1
--- ann-1.1.2+doc.orig/debian/tests/build1	2014-11-04 14:25:57.552987031 -0200
+++ ann-1.1.2+doc/debian/tests/build1	2014-11-04 23:06:24.239266085 -0200
@@ -6,9 +6,10 @@ set -e
 
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
-cp ann_test.cpp $WORKDIR/
-cp rand.cpp $WORKDIR/
-cp rand.h $WORKDIR/
+TESTDIR="debian/tests"
+cp $TESTDIR/ann_test.cpp $WORKDIR/
+cp $TESTDIR/rand.cpp $WORKDIR/
+cp $TESTDIR/rand.h $WORKDIR/
 
 cd $WORKDIR
 
diff -rupN ann-1.1.2+doc.orig/debian/tests/build2 ann-1.1.2+doc/debian/tests/build2
--- ann-1.1.2+doc.orig/debian/tests/build2	2014-11-04 14:25:57.552987031 -0200
+++ ann-1.1.2+doc/debian/tests/build2	2014-11-04 23:04:58.458399428 -0200
@@ -6,9 +6,10 @@ set -e
 
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
-cp ann_test.cpp $WORKDIR/
-cp rand.cpp $WORKDIR/
-cp rand.h $WORKDIR/
+TESTDIR="debian/tests"
+cp $TESTDIR/ann_test.cpp $WORKDIR/
+cp $TESTDIR/rand.cpp $WORKDIR/
+cp $TESTDIR/rand.h $WORKDIR/
 
 cd $WORKDIR

Bug#768096: [Python-modules-team] python mysqldb on python 3

2014-11-04 Thread Collin Anderson

Hi Brian,

Thanks so much.

> There might be a problem because it looks like it conflicts with
python-mysqldb.
Yes, it's a 100% compatible fork intended to replace python-mysqldb. Same
python package name and everything. We could decide to only include it for
python3, or we could even have this completely replace the original
python-mysqldb on python2.

Thanks,
Collin


On Tue, Nov 4, 2014 at 5:47 PM, Brian May 
wrote:

> On 30 October 2014 04:50, Collin Anderson  wrote:
>
>> This mysqlclient library is now the recommend choice for using MySQL with
>> Django.
>>
>> https://docs.djangoproject.com/en/1.7/ref/databases/#mysql-db-api-drivers
>>
>> It's compatible with the current mysqldb package, except the current
>> package does not have python3 support. Could we package this as a
>> replacement?
>>
>
> I just submitted an ITP. #768096.
>
> There might be a problem because it looks like it conflicts with
> python-mysqldb.
>
> Please send follow-ups to 768...@bugs.debian.org
>
> Thanks.
>

Bug#768105: smoke-dev-tools: smokegen does not parse -I options correctly

2014-11-04 Thread Alan W. Irwin

Package: smoke-dev-tools
Version: 4:4.8.4-1
Severity: normal

I am helping to generate some smoke bindings for the PLplot library.
The command I first used to generate the source code was

/usr/bin/smokegen -config /usr/share/smokegen/qt-config.xml \
-smokeconfig \
/home/software/plplot/HEAD/plplot.git/bindings/qt_gui/smoke/smokeconfig.xml
\
-I"/home/software/plplot/HEAD/plplot.git/bindings/qt_gui/smoke" \
-I"/home/software/plplot/HEAD/plplot.git/include" \
-I"/home/software/plplot/HEAD/plplot.git/lib/qsastime" \
-I"/home/software/plplot/HEAD/plplot.git/lib/nistcd" \
-I"/home/software/plplot/HEAD/plplot.git/drivers" \
-I"/home/software/plplot/HEAD/build_dir" \
-I"/home/software/plplot/HEAD/build_dir/include" -- \
/home/software/plplot/HEAD/plplot.git/bindings/qt_gui/smoke/plplotqt.h

That generated valid but near empty code.  So I played around a bit
and discovered that smokgen silently drops all -I options that
are not followed by a space, so, e.g.,

/usr/bin/smokegen -config /usr/share/smokegen/qt-config.xml \
-smokeconfig \
/home/software/plplot/HEAD/plplot.git/bindings/qt_gui/smoke/smokeconfig.xml
\
-I "/home/software/plplot/HEAD/plplot.git/bindings/qt_gui/smoke" \
-I "/home/software/plplot/HEAD/plplot.git/include" \
-I "/home/software/plplot/HEAD/plplot.git/lib/qsastime" \
-I "/home/software/plplot/HEAD/plplot.git/lib/nistcd" \
-I "/home/software/plplot/HEAD/plplot.git/drivers" \
-I "/home/software/plplot/HEAD/build_dir" \
-I "/home/software/plplot/HEAD/build_dir/include" -- \
/home/software/plplot/HEAD/plplot.git/bindings/qt_gui/smoke/plplotqt.h

generated lots of (valid) code.

Even though smokegen --help documents that a space must
be between the -I option and corresponding directory, I
still view this as an egregous smokegen bug since (a) invalid options
should be noted rather than silently dropped, and (b) smokegen is
trying to mimic how compilers find headers, but (as far as I know)
compilers only honor -I options without a space between "-I" and the
directory name.  (For example, that is the only form documented by 
info g++.) 

So smokegen demanding a blank between the "-I" and the directory name
violates the principle of least surprise and therefore you should
expect most serious smokegen users (who normally must use at least one
-I option) to trip over this issue just like I did.  Violating the
principle of least surprise is just bad human engineering!

N.B. I only have access to Debian stable, but if this issue is not
solved in the latest smokegen you get with debian unstable, I am
virtually positive this is an upstream smokegen bug which I hope you
will propagate there.

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

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

Versions of packages smoke-dev-tools depends on:
ii  libc6  2.13-38+deb7u4
ii  libgcc11:4.7.2-5
ii  libqt4-xml 4:4.8.2+dfsg-11
ii  libqtcore4 4:4.8.2+dfsg-11
ii  libsmokebase3  4:4.8.4-1
ii  libstdc++6 4.7.2-5

smoke-dev-tools recommends no packages.

smoke-dev-tools 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#746578: libpam-systemd to flip dependencies - proposal

2014-11-04 Thread Josh Triplett

On Tue, 4 Nov 2014 17:54:53 + Ian Jackson  
wrote:
> I've been reading the messages from Josh about cgmanager etc., and
[snip]

Actually, I'd like to completely withdraw my concerns there, in light of
some new information.

Quoting Serge Hallyn, maintainer of cgmanager:
> Currently the cgmanager sytemd unit is installed inactive, so by default
> it will not interfere with systemd.  The user needs to specifically
> enable it.

So, both systemd-shim and cgmanager seem entirely harmless on systemd
systems; the former will not run at all under systemd, and the latter
will not run by default under systemd.  Based on that, I no longer have
any concerns about flipping the dependencies around, even though doing
so will likely pull those two packages in on systemd systems per
Christian Seiler's detailed analysis.

I don't see any obvious further steps that need to occur other than
flipping the dependency around.  (It might be a good idea for the
libpam-systemd dependency to bump its versioned dependency on
systemd-shim to (>= 8-4), but that's up to the libpam-systemd
maintainers.)

(This is still orthogonal to any discussions regarding switching on
upgrades, or regarding dependencies on systemd.)

- Josh Triplett

> Rationale (Constitution 6.1(5)):
> 
> 1. Currently libpam-systemd (which is pulled in by quite a few
>dependency chains) Depends on `systemd-sysv | systemd-shim (>= 8-2)'.
> 
> 2. The effect of this is that installing some packages which depend
>(directly or indirectly) on libpam-systemd can cause a user's init
>system to be switched to systemd, even on systems where a user has
>deliberately chosen not to use the default init system, and even
>when the switch is unnecessary.
> 
> 3. Swappping the order of these dependencies would avoid that and has
>no harmful effect:
> 
> 4. In particular, on systems that already have systemd-sysv installed,
>libpam-systemd will still not pull in systemd-shim, thus minimizing
>the risk of breakage on systemd systems.  However, on systems that
>intentionally do not have systemd installed, the installation of
>libpam-systemd will then prefer to pull in systemd-shim and keep
>the installed init system rather than switching to systemd-sysv.
> 
> Decision (Constitution 6.1(4)):
> 
> 5. We therefore overrule the decision of the maintainer of
>libpam-systemd binary package.  The Depends entry
>   systemd-sysv | systemd-shim (>= 8-2)
>should be replaced by 
>   systemd-shim (>= 8-2) | systemd-sysv
> 
> 6. For the avoidance of doubt, we do not intend to set this specific
>syntax in stone.  For example, if in future libpam-systemd needs to
>depend on a later systemd-shim, or needs a versioned rather than
>unversioned dependency on systemd-sysv, that is fine and would not
>contradict our decision.
> 
> Release (Constitution 6.1(5)):
> 
> 7. Our advice is that this change should be in jessie.  If necessary,
>this view should be conveyed to the Release Team, after the change
>is in unstable, by filing an unblock request in the usual way.
> 
> ===
> 
> 


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

Bug#741930: reportbug: add current init system information

2014-11-04 Thread Cameron Norman

On Tue, Nov 4, 2014 at 5:35 AM, Sandro Tosi  wrote:
> Hi Michael et al,
>
> On Mon, Nov 3, 2014 at 1:19 PM, Michael Biebl  wrote:
>>> provided above one requires to check a dir existence and the checking
>>> a command and then execute it to parse its output. it seems a bit
>>> fragile, and maybe only upstart check really the running processes
>>
>> The systemd system runtime directory is only created when systemd is the
>> active PID 1. Could you elaborate why you think this approach is
>> fragile? If those two tests (for systemd and upstart) would be brittle,
>> we'd have a problem, since they are used all over the place.
>
> well, mkdir can create it too :) but ok, those checks are so embedded
> that i can ignore if the reportbug check if fooled to thing theres
> another systems (there will be bigger problems indeed) so I will just
> mimik their logic in the code; I changed the sample scripts, attached,
> and it would be nice if you all could give it another round (thanks to
> everyone who already did!) in particular to those having an upstart
> init system.

A few notes I have:

1. With Jessie and on, with sysvinit /sbin/init //will// be a link,
not the true init file. This would lead to unknowns when the init was
actually sysv.
2. With Upstart, /sbin/init is not a link, so that third test would
give a false positive for sysvinit when it was actually Upstart
(assuming the Upstart check gave a false negative).
3. Maybe you should embed the check for Upstart, so that you do not
have to source all of the init functions, and if that file is ever not
available you still get the correct check.
4. There is a tiny typo in the Upstart check. It needs an extra right
parenthese at the end of the message.

Cheers,
--
Cameron Norman

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

Bug#768104: kfreebsd-9: CVE-2014-8476: getlogin kernel memory disclosure

2014-11-04 Thread Steven Chamberlain

Package: src:kfreebsd-9
Version: 9.0-10+deb70.7
Severity: grave
Tags: security patch upstream

Hi,

kfreebsd 9.0 (not officially supported upstream) seems vulnerable to an
issue just announced in 9.1 and later:

http://security.FreeBSD.org/advisories/FreeBSD-SA-14:25.setlogin.asc

kfreebsd-8 8.3 in wheezy, kfreebsd-10 in sid/jessie, and kfreebsd-11 in
experimental also seem to be affected by this.

-- System Information:
Debian Release: jessie/sid
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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#755977: Processed: reassign 755977 to cgmanager

2014-11-04 Thread josh

On Wed, Nov 05, 2014 at 12:17:56AM +, Serge Hallyn wrote:
> thanks for filing this bug.  I appreciate but reject your point of view.  To
> elaborate:
> 
> Currently the cgmanager sytemd unit is installed inactive, so by default it
> will not interfere with systemd.  The user needs to specifically enable it.

[snip remaining explanation]

Thanks, that's information I didn't previously have, and that's
sufficient to not worry about having cgmanager pulled in on systemd
systems by way of systemd-shim.

While it might potentially impact applications that depend on cgmanager
and expect to find it running, currently no such applications exist in
Debian other than systemd-shim, so I don't think it's worth worrying
about that scenario right now, *especially* since I don't actually use
cgmanager and thus only worry about how it will interact with systemd.
What you have in place today seems quite sufficient to ensure that
cgmanager will not break a running systemd system.

I'll pass this on to the relevant TC bug.

Thanks,
Josh Triplett

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

Bug#768069: apt command line package name interpretation

2014-11-04 Thread Jonathan David Amery

Julian Andres Klode writes:
> The only time an issue can appear is if you have two or more packages
> ending in + or - where one is a prefix of the other. As long as we
> do not have such packages in the archive, there is no issue.
> 
 I had a quick look in my (not complete) mirror and didn't see any
packages with a terminal -; however there are a number of packages with
terminal + or ++ that also have packages whose names are a prefix:

aewm   aewm++
bison  bison++
freefemfreefem++
gobjc  gobjc++
kimwitukimwitu++
libdb4.6   libdb4.6++
libdb4.7   libdb4.7++
libdb4.8   libdb4.8++
libdb5.1   libdb5.1++
libdb5.3   libdb5.3++
memtest86  memtest86+
minisatminisat+
pawpaw++
python-py  python-py++
swish  swish++
vera   vera++
wmweather  wmweather+
xgalagaxgalaga++

 In addition if there was no python-py++ package then that string
supplied to apt would match 290 packages in my mirror.

 J.


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

Bug#762942: No hyphenation for Czech too

2014-11-04 Thread Kepi

There is same problem for Czech users, no hyphenation possible at all.

I found a workaround which should work for Spanish too but this should
be somehow resolved. OpenOffice is probably using different
library/dictionaries because hyphenation works ok there.

Workaround for Czech language (under root):

apt-get install liblouis-data
cp /usr/share/liblouis/tables/hyph_cs_CZ.dic /usr/share/hyphen/hyph_cs.dic

For Spanish just use hyph_es_ES.dic as source and hyph_es.dic or
likewise for other languages that don't have hyphen- package.

Beware that (at least for Czech) file name have to be hyph_cs.dic not
hyph_cs_CZ.dic (not sure why). In later case it will appear in Scribus
as available language but doesn't work.

-- 
Kepi


pgpE650O98yN2.pgp
Description: PGP signature

Bug#768099: Compiling with older dpkg versions

2014-11-04 Thread Vagrant Cascadian

Control: tags -1 patch

On 2014-11-04, Norbert Lange wrote:
> Hello, I would like to be able to compile the package for Wheezy and this  
> requires a simple change in the rules,

Thanks for the bug report!

This points out that the package currently should have a versioned
"Build-Depends: dpkg-dev (>= 1.17.0)" with the current code in
debian/rules.


> replace the "export DEBIAN_REVISION.." line with:
> export DEBIAN_REVISION ?= $(shell dpkg-parsechangelog | sed -n -e  
> 's/^Version: [^+]*\(+[A-Za-z0-9.~-]*\).*/\1/p')
>
> Please include this change to allow easy compilation on systems with older  
> dpkg tools.

Sorry about that, I generally prefer to have packages be buildable on
stable when it's reasonably easy. Unfortunately, this may not be
important enough to warrant a freeze exception...


A slightly simpler patch that's a smaller (hopefully easier to read)
diff:

diff --git a/debian/rules b/debian/rules
index 86a475a..e893217 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,7 @@
 DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-export DEBIAN_REVISION ?= $(shell dpkg-parsechangelog --show-field Version | 
sed -e 's,.*+dfsg,+dfsg,')
+export DEBIAN_REVISION ?= $(shell dpkg-parsechangelog | sed -n -e 
's,^Version:.*+dfsg,+dfsg,p')

 ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
 export CROSS_COMPILE ?= $(DEB_HOST_GNU_TYPE)-




live well,
  vagrant


pgpLdyHCmkGCU.pgp
Description: PGP signature

Bug#766887: openssh-sftp-server: please mention in long description sftp protocol versions supported

On Sun, 2014-10-26 at 18:06 +0100, Jonas Smedegaard wrote: 
> According to
>  this implementation
> supports version 3 - but that information may be inaccurate or too old.
It should then probably also document, what is actually meant with
protocol version... I guess it refers to which of the obsolete
draft-ietf-secsh-filexfer is supported.

Unfortunately, I remember to have read, that some clients/servers may
have just picked some features of the newer versions of the ID.

Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#767967: Metapost: With prologues=1, produces lots of duplicate fontmap entries

Hi Taco,

there seems to be small problem with double inclusion of psfonts.map
again/still ...

Although in 1.800 announcement there was written something about fixing this,
the problem is still present as far as I see in current TeX Live svn,
which is also in Debian, see message below.

Is there anything we can do to fix that?

Thanks a lot

Norbert

On Mon, 03 Nov 2014, Dylan Thurston wrote:
> Package: texlive-binaries
> Version: 2014.20140926.35254-2
> Severity: normal
> 
> With 'prologues := 1', MetaPost produces lots and lots of 'duplicate
> fontmap' errors. Here is a minimal example, but basically
> any file will do it:
> 
> 
> prologues := 1;
> 
> beginfig(1);
> endfig;
> 
> beginfig(2);
> endfig;
> end
> 
> 
> The output for me starts
> 
> 
> dpt@tulip:/tmp$ mpost t > t.out
> dpt@tulip:/tmp$ head t.out
> This is MetaPost, version 1.999 (TeX Live 2015/dev/Debian) (kpathsea version 
> 6.2.1dev)
> (/usr/share/texlive/texmf-dist/metapost/base/mpost.mp
> (/usr/share/texlive/texmf-dist/metapost/base/plain.mp
> Preloading the plain mem file, version 1.005) ) (./t.mp [1{psfonts.map}] 
> [2{psf
> onts.map
> Warning: fontmap entry for `cob' already exists, duplicates ignored
> Warning: fontmap entry for `cobo' already exists, duplicates ignored
> Warning: fontmap entry for `com' already exists, duplicates ignored
> Warning: fontmap entry for `coo' already exists, duplicates ignored
> Warning: fontmap entry for `hv' already exists, duplicates ignored
> 
> 
> I notice that a similar bug appears in the bug logs for MetaPost: From
> http://www.tex.ac.uk/CTAN/graphics/metapost/base/CHANGES:
> 
> 
> [...]
> --
> What is new in MetaPost version 1.800:
> --
> [...]
> * Fixed a number of bugs where Metapost loaded the default font map
>   file multiple times, resulting in lots of "fontmap entry for 
>   `' already exists, duplicates ignored" warnings.
> [...]
> 


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



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

Bug#768103: RFP: dropwizard -- A Java library for building production-ready RESTful web services

2014-11-04 Thread Tim Potter

Package: wnpp
Severity: wishlist

* Package name: dropwizard
  Version : 0.7.1
  Upstream Author : Coda Hale 
* URL : https://github.com/dropwizard/dropwizard
* License : Apache-2.0
  Programming Lang: Java
  Description : A Java library for building production-ready RESTful web 
services

Dropwizard is a Java library that integrates existing high-quality Java 
libraries to create a framework for building RESTful web services.  It 
comes with out-of-the-box support for sophisticated configuration, 
application metrics, logging, operational tools and much more.

This would be a useful package to allow web applications written for
Dropwizard to be deployed on Debian systems.  Maintenance would be
performed by myself with support from the Debian Java packaging team.


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

Bug#755977: Processed: reassign 755977 to cgmanager

2014-11-04 Thread Serge Hallyn

thanks for filing this bug.  I appreciate but reject your point of view.  To
elaborate:

Currently the cgmanager sytemd unit is installed inactive, so by default it
will not interfere with systemd.  The user needs to specifically enable it.

When cgmanager finds that cgroups have been pre-mounted (by systemd or someone
else) it does not install release agents, so it does not interfere with the
previous mounter's administration of the cgroups.

When systemd-shim is not installed, cgmanager does nothing that will create
or destroy login sessions or scopes.  That's left entirely up to systemd.

The only way cgmanager will generally be used is to create sub-cgroups either
of /lxc or of a user's login session.  The actual configuration of cgroups
done by systemd will not be interfered with (apart from impact of /lxc,
which could be an interesting issue but in no way justifies a Conflicts)

When systemd becomes feature-full enough to satisfy the needs of lxc, I'll
definitely seek to implement a systemd backend so that cgmanager can be
considered conflicting with systemd.  We can also hope that cgroup namespaces
will make it upstream and obviate the need for cgmanager.  For now that's not
an option.

In the meantime, I'm going to claim that just because I run systemd on my
laptop does not mean that I cede full control of cgroups to systemd.  You
may use them if you insist and I won't even get in the way, but you may
not co-opt them entirely.

What you are basically asking for is that any software which needs the
features offered by cgmanager should be not installable alongside systemd.


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

Bug#767887: texlive-xetex should include etoolbox (from texlive-latex-extras)

On Mon, 03 Nov 2014, Felix Braun wrote:
> texlive-xetex includes polyglossia. Recent versions of polyglossia (such as 
> the one packaged here) depend on etoolbox.sty. Therefore, any attempt to use 
> polyglossia will fail if the user didn't install texlive-latex-extras 
> manually. Please move etoolbox.sty from texlive-latex-extras into 
> texlive-xetex.

I added a dependency texlive-xetex -> texlive-latex-extra

We follow upstream's collection splitting to the word, and don't move
anything unless absolutely necessary.

Will be in the next upload.

Norbert


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



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

Bug#767589: systemd: cryptdisks other than root/swap fail cryptsetup

2014-11-04 Thread Arnaud Installe

On Tue, 04 Nov 2014 13:52:16 +0100
Michael Biebl  wrote:

> Therefore re-assigning to initramfs-tools.
> Please followup on the bug report and include the version of
> initramfs-tools you have installed. As well as the version of
> cryptsetup.

initramfs-tools 0.118
cryptsetup  2:1.6.6-3

Thanks,

Arnaud

-- 
Arnaud Installe   +32 477 304199
ESAT - STADIUS, KULeuven iMinds Medical Information Technologies


pgpeqAYJoWqrz.pgp
Description: OpenPGP digital signature

Bug#764178: debsources: infobox CSS alignment problem with short files

2014-11-04 Thread Jason Pleau

Hello Stefano,


On 04/11/14 04:44 AM, Stefano Zacchiroli wrote:
> First of all: thanks a lot for your patch, Jason!
> 
> On Fri, Oct 31, 2014 at 07:42:23AM -0400, Jason Pleau wrote:
>> From 6cc9f15d51dd35a5afb82a2c3680e3e5dfc0f93b Mon Sep 17 00:00:00 2001
>> From: Jason Pleau 
>> Date: Fri, 31 Oct 2014 00:05:26 -0400
>> Subject: [PATCH] source_file: fix text overlapping the infobox
> 
> I'm no CSS expert, so I'm unable to comment on your patch at the
> moment. Matthieu: can you have a look and comment on Jason's approach at
> fixing #764178.
> 
> I've a separate comment though:
> 
>> When browsing a file's source on sources.debian.net, if the file
>> didn't contain enough text its content would overlap onto the infobox
>> to the right.
> 
> Your commit message essentially restates the bug report, rather than
> explaining how the corresponding change fixes it. The commit message
> should really do the latter, rather than the former.
> 

Thanks for the feedback ! I admit my commit doesn't explain what I did
to fix the issue I was fixing.

First, I'd like to note that there were two issues in the original post
(I think that's what brought up the confusion)

 * If the file was too short, the "infobox" seemed to expand outside
it's container. This was fixed already in
0ed831b256a91287ebfe63c9a52cbbb76816a293 [1] a few weeks ago.

 * If the file contained only one line with only a few characters (for
example, debian/compat is a one liner containing only one character),
the file content was displayed to the right (see my attached picture:
before.png). If the window browser was small, the text even overlapped
over the infobox.

> Particularly in this case, I see no obvious reason why changing the
> right padding of codetable (an horizontal spacing matter) would fix the
> bug (which seems to be a vertical spacing matter). I'm sure it *does*
> fix the bug, but the commit should explain why it does so, so that even
> CSS illiterates as myself could understand the rationale :-)
> 
> Jason: do you think you can update your patch to do so?
> 

My commit adds a padding-right to make sure that even if the file has
one short line, it's content will be left-aligned. The 450px that I've
written is a bit arbitrary. You can look at it in a more graphical way
in my attachment "after.png". The green part is the padding-right that
I've added.

I have attached a new patch, this time with a more descriptive text,
hopefully it will make more sense !


Thanks !


> Many thanks in advance,
> Cheers.
> 

[1]:
http://anonscm.debian.org/cgit/qa/debsources.git/commit/?id=0ed831b256a91287ebfe63c9a52cbbb76816a293

-- 
Jason Pleau
From 2570734fd05f369b1435be89bc830b00b7209279 Mon Sep 17 00:00:00 2001
From: Jason Pleau 
Date: Tue, 4 Nov 2014 18:36:10 -0500
Subject: [PATCH] source_file: fix the text alignment in short files

When browsing a file containing only short lines (for example debian/compat
files), its content was aligned to the right, very close to the infobox.

This commit adds a padding-right to the  element containing the
file's content  allowing it to be aligned to the left even on the problematic
files as described above.
---
 debsources/app/static/css/source_file.css  | 4 
 debsources/app/templates/source_file_code.inc.html | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/debsources/app/static/css/source_file.css b/debsources/app/static/css/source_file.css
index 58328bc..02ae1e8 100644
--- a/debsources/app/static/css/source_file.css
+++ b/debsources/app/static/css/source_file.css
@@ -39,6 +39,10 @@ License: GNU Affero General Public License, version 3 or above.
 
 /* LINE NUMBERS */
 
+#codetable #codecontainer{
+padding-right: 450px;
+}
+
 #codetable #sourceslinenumbers{
 text-align: right;
 border-right: 1px solid black;
diff --git a/debsources/app/templates/source_file_code.inc.html b/debsources/app/templates/source_file_code.inc.html
index 9ea5a88..f0a912d 100644
--- a/debsources/app/templates/source_file_code.inc.html
+++ b/debsources/app/templates/source_file_code.inc.html
@@ -23,7 +23,7 @@
 {%- endfor %}
 
 
-  {% for (line, highlight) in code -%}
   {% if highlight -%}
-- 
2.1.1



signature.asc
Description: OpenPGP digital signature

Bug#768047: aptitude: doesn't inform a user that a package will no longer receive updates when it obsolete in the target suite, but not yet for an older suite

I made a mistake here in testing (actually used the wheezy version and
not the jessie O:-). This time I grabbed the previous unstable version
from snapshot.d.o (and removed s.d.o again before doing anything)
So the following changes:

> aptitude -o "Aptitude::Pkg-Display-Limit=~i ?any-version(~Osecurity) !~U !~o"
as before, doesn't show anything at all.


> aptitude -o "Aptitude::Pkg-Display-Limit=~i ?any-version(!~O.) !~U !~o"
> same as above, nothing is shown at all.
Displays the two obsolete packages liblcms-utils and liblcms1.

Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#768102: debootstrap: start bind-mounting /proc on Hurd and add nobindmount variant

2014-11-04 Thread Gabriele Giacone

Package: debootstrap
Version: 1.0.64
Severity: wishlist

Dear Maintainer,

attached patch is pretty hurd-specific:

 - disconnect (orphan) TARGET/proc passive translator and start
   bind-mounting /proc along with /servers and /dev.
 - add "nobindmount" variant to create chroots without bind-mounting
   any filesystem. Main use case is chroot for subhurds [0].

[0] https://www.gnu.org/software/hurd/hurd/subhurd.html

Thanks for considering.

-- 
G..e
diff --git a/debootstrap b/debootstrap
index fef1ab5..9dced1e 100755
--- a/debootstrap
+++ b/debootstrap
@@ -100,7 +100,7 @@ usage()
  archive
   --variant=Xuse variant X of the bootstrap scripts
  (currently supported variants: buildd, fakechroot,
-  scratchbox, minbase)
+  scratchbox, minbase, nobindmount)
   --keyring=Kcheck Release files against keyring K
   --no-check-gpg avoid checking Release file signatures
   --no-resolve-deps  don't try to resolve dependencies automatically
diff --git a/debootstrap.8 b/debootstrap.8
index 2cf44ca..b448089 100644
--- a/debootstrap.8
+++ b/debootstrap.8
@@ -71,13 +71,14 @@ or apt, and that it is far better to specify the entire base system than
 rely on this option.
 With this option set, this behaviour is disabled.
 .IP
-.IP "\fB\-\-variant=minbase|buildd|fakechroot|scratchbox\fP"
+.IP "\fB\-\-variant=minbase|buildd|fakechroot|scratchbox|nobindmount\fP"
 Name of the bootstrap script variant to use.
 Currently, the variants supported are minbase, which only includes
 essential packages and apt; buildd, which installs the build-essential
 packages into
 .IR TARGET ;
-and fakechroot, which installs the packages without root privileges.
+nobindmount, which doesn't bind-mount any filesystem; and fakechroot,
+which installs the packages without root privileges.
 Finally there is variant scratchbox, which is for creating targets
 for scratchbox usage.
 The default, with no \fB\-\-variant=X\fP argument, is to create a base
diff --git a/functions b/functions
index 0d48390..07147c0 100644
--- a/functions
+++ b/functions
@@ -1064,10 +1064,13 @@ setup_devices () {
 
 setup_devices_hurd () {
 	# Use the setup-translators of the hurd package, and firmlink
-	# $TARGET/{dev,servers} to the system ones.
+	# $TARGET/{dev,servers,proc} to the system ones.
 	in_target /usr/lib/hurd/setup-translators -k
-	settrans -a $TARGET/dev /hurd/firmlink /dev
-	settrans -a $TARGET/servers /hurd/firmlink /servers
+	if ! doing_variant nobindmount; then
+		settrans -a $TARGET/dev /hurd/firmlink /dev
+		settrans -a $TARGET/servers /hurd/firmlink /servers
+		settrans -oa $TARGET/proc /hurd/firmlink /proc
+	fi
 }
 
 setup_devices_fakechroot () {
diff --git a/scripts/sid b/scripts/sid
index bf3404f..34089f7 100644
--- a/scripts/sid
+++ b/scripts/sid
@@ -1,7 +1,7 @@
 mirror_style release
 download_style apt
 finddebs_style from-indices
-variants - buildd fakechroot minbase scratchbox
+variants - buildd fakechroot minbase scratchbox nobindmount
 keyring /usr/share/keyrings/debian-archive-keyring.gpg
 
 if doing_variant fakechroot; then

Bug#768101: mate-media-gstreamer: asymmetric operation of mute/unmute

2014-11-04 Thread Arnaud Installe

Package: mate-media-gstreamer
Version: 1.8.0+dfsg1-3
Severity: important

Unmuting sound after muting it results in no sound.
This happens whether clicking the "mute" button twice on the keyboard, or
whether right-clicking mixer-applet2, and clicking "mute" twice.
It does not happen when using the "mute" button within pavucontrol.

What happens can be seen by opening "mate-volume-control":
_ Device is set to "HDA Intel MID (Alsa mixer)".
_ In the "playback" tab, vertical sliders are shown, with "enable/disable"
buttons underneath, for master, headphone, speaker, PCM, Mic Boost, and
internal mic boost.
_ When clicking "mute" the first time, to mute sound, master and speaker are
disabled.
_ When clicking "mute" the second time, to unmute sound, only master is re-
enabled, leaving speaker disabled.

Because of this asymmetric operation of mute/unmute, sound cannot be re-enabled
using the mute button. The speaker has to be re-enabled using the
enable/disable buttons in mate-volume-control.
By comparison, pavucontrol behaves correctly: clicking "mute" in its UI twice
results in master and speaker being disabled and re-enabled, respectively.



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

Kernel: Linux 3.16-3-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 mate-media-gstreamer depends on:
ii  dconf-gsettings-backend [gsettings-backend]   0.22.0-1
ii  gstreamer0.10-alsa [gstreamer0.10-audiosink]  0.10.36-2
ii  gstreamer0.10-plugins-bad [gstreamer0.10-audiosink]   0.10.23-7.4
ii  gstreamer0.10-plugins-base0.10.36-2
ii  gstreamer0.10-plugins-good [gstreamer0.10-audiosink]  0.10.31-3+nmu4+b1
ii  gstreamer0.10-pulseaudio [gstreamer0.10-audiosink]0.10.31-3+nmu4+b1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-12
ii  libcairo2 1.14.0-2.1
ii  libcanberra-gtk0  0.30-2.1
ii  libcanberra0  0.30-2.1
ii  libfontconfig12.11.0-6.1
ii  libfreetype6  2.5.2-2
ii  libgdk-pixbuf2.0-02.31.1-2+b1
ii  libglib2.0-0  2.42.0-2
ii  libgstreamer-plugins-base0.10-0   0.10.36-2
ii  libgstreamer0.10-00.10.36-1.4
ii  libgtk2.0-0   2.24.25-1
ii  libmate-desktop-2-17  1.8.1+dfsg1-2
ii  libmate-panel-applet-4-1  1.8.1+dfsg1-2
ii  libpango-1.0-01.36.8-2
ii  libpangocairo-1.0-0   1.36.8-2
ii  libpangoft2-1.0-0 1.36.8-2
ii  libstartup-notification0  0.12-4
ii  libx11-6  2:1.6.2-3
ii  libxml2   2.9.2+dfsg1-1
ii  marco-common  1.8.2+dfsg1-4
ii  mate-desktop  1.8.1+dfsg1-2
ii  mate-media-common 1.8.0+dfsg1-3
ii  x11-utils 7.7+2

Versions of packages mate-media-gstreamer recommends:
ii  alsa-utils   1.0.28-1
ii  sound-theme-freedesktop  0.8-1

mate-media-gstreamer 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#768047: aptitude: doesn't inform a user that a package will no longer receive updates when it obsolete in the target suite, but not yet for an older suite

Perhaps for open discussion:

I would think the proper definition for "obsolete package" would be:
A package that, under the current apt_preference policies, would no
longer be installed (in that version) and/or no longer receive updates.


If there's only one suite/repo, than this is of course equal to "cannot
be longer downloaded", which however is of little use for an admin.

Under multi-suite/repo configurations, with package pinning, complex
apt_preference configurations, etc. this definition would already match
for my lcms1 example:
# apt-cache policy liblcms-utils
liblcms-utils:
  Installed: 1.19.dfsg2-1.5+b2
  Candidate: 1.19.dfsg2-1.5+b2
  Version table:
*** 1.19.dfsg2-1.5+b2 0
100 /var/lib/dpkg/status
 1.19.dfsg-1.2 0
  1 http://ftp.de.debian.org/debian/ stable/main amd64 Packages

in contrast to:

# apt-cache policy aptitude 
aptitude:
  Installed: 0.6.11-1
  Candidate: 0.6.11-1
  Version table:
 *** 0.6.11-1 0
500 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
 0.6.8.2-1 0
  1 http://ftp.de.debian.org/debian/ stable/main amd64 Packages


Then clearly, liblcms-utils 1.19.dfsg2-1.5+b2 is only available locally
(no "500 http://ftp.de.debian.org/debian/ unstable/main amd64" line for
it) and 1.19.dfsg-1.2 isn't the candidate version either.
=> liblcms-utils won't receive any more updates (in the current config)
and should therefore be considered obsolete.

The package aptitude 0.6.11-1 however is not obsolete, the candidate
version is still available non-locally.



I think the problem is also, that obsoleteness is kinda defined for a
package only, while it should be defined for package+version
combination.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#768097: clamtk: Won't start.

2014-11-04 Thread Andreas Cadhalpun


Control: tags -1 unreproducible moreinfo

Hi Rob,

On 04.11.2014 23:34, rob wrote:

Running from terminal:

Icon 'gtk-new' not present in theme at /usr/share/perl5/ClamTk/GUI.pm line 262.


This is strange and I can't reproduce it.

The icon should be provide by the package gnome-icon-theme and clamtk 
depends on that.


Maybe your installation/disk is corrupt?

Please report the output of the following commands:
$ dpkg --verify gnome-icon-theme
$ find /usr/share/icons/gnome/ -name *gtk-new* | xargs file
$ find /usr/share/icons/gnome/ -name *document-new* | xargs file

Best regards,
Andreas


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


Mixing unstable and stable might cause problems.


Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14.4preempt (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages clamtk depends on:
ii  clamav  0.98.5~rc1+dfsg-3
ii  clamav-freshclam [clamav-data]  0.98.4+dfsg-2+b1


Is there a reason, why you updated clamav, but not clamav-freshclam?


ii  cron3.0pl1-127
ii  gnome-icon-theme3.12.0-1


You have the package installed, so the icon should be available.

Best regards,
Andreas


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

Bug#756076: Acknowledgement (does not cleanup sessions when user logs out: No such interface 'org.freedesktop.systemd1.Scope')

2014-11-04 Thread Martin Pitt

Control: tag -1 fixed-upstream pending

Martin Pitt [2014-11-04 16:16 +0100]:
> Indeed the cgroups get cleaned up properly, just nothing tells
> logind about that as there is currently no notify_on_release being
> set/used. I'm looking into that now.

The three last commits on https://github.com/desrt/systemd-shim/commits/master
("Clean up closing logind sessions" and the two previous ones)
implement this now.

Tomorrow I'll still look into https://bugs.debian.org/756247 (my
original patch does not work), then we'll have all bugs except #747821
(moreinfo) fixed.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Bug#768047: aptitude: doesn't inform a user that a package will no longer receive updates when it obsolete in the target suite, but not yet for an older suite