date:20120818

Package: xz-utils
Version: 5.1.1alpha+20120614-1
Severity: minor
Justification: policy §2.5
Tags: patch

Hi,

xz-utils has Priority: required but no pseudo-essential package
depends on it:

$ grep-dctrl -sPackage -Fpriority required \
  -a -FDepends,Pre-Depends 'xz-utils' \
  /var/lib/cupt/lists/*_debian_dists_wheezy_main_binary-i386_Packages |
  wc -l
0

The priority should be 'important' or lower as discussed at [1]
and [2].  This could help people building tiny systems to make
them smaller.  Patch attached.

[1] http://bugs.debian.org/452393
[2] http://thread.gmane.org/gmane.linux.debian.devel.release/55821
From: Jonathan Nieder jrnie...@gmail.com
Date: Sat, 23 Jun 2012 17:44:04 -0500
Subject: debian/control: xz-utils is not pseudo-essential any more

Since dpkg 1.16.4~6 (libdpkg: Add liblzma compression support,
2012-06-07), the xz command is no longer needed in a minimal Debian
system.

Based on its list of reverse-dependencies, it is even safe to lower
the priority to optional.  Let's make it standard, since it is not
part of the traditional Unix toolset but is a useful component even in
reasonably small character-mode systems.
---
 debian/changelog |1 +
 debian/control   |1 +
 2 files changed, 2 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index a69f889..56563e1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
 xz-utils (5.1.1alpha+20120614-1.1) unstable; urgency=low
 
+  * Lower priority of xz-utils to standard.
   * xz-utils/README.Debian: Document differences from upstream.
 
  -- Jonathan Nieder jrnie...@gmail.com  Fri, 17 Aug 2012 19:57:24 -0700
diff --git a/debian/control b/debian/control
index 986f0c1..281931e 100644
--- a/debian/control
+++ b/debian/control
@@ -29,6 +29,7 @@ Description: XZ-format compression library
  format, use the p7zip package instead.)
 
 Package: xz-utils
+Priority: standard
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Multi-Arch: foreign
-- 
1.7.9.6 (Apple Git-31.1)

Bug#681121: [Pkg-kde-extras] Bug#681121: Bug#681121: amarok: attempts to upgrade MySQL database on every application start

2012-08-18 Thread Modestas Vainius

Control: severity -1 normal
Control: title -1 amarok database is stuck at version 7 (amarok 2.2.0)
Control: tags -1 upstream

Hello,

On Thursday 12 July 2012 15:02:44 Ira Rice wrote:
 020   A   C   K soh nul nul nul nul soh nul dc1 nul   ~  nl   D   B
4341014b000100110afe4244
 040   _   V   E   R   S   I   O   N bel nul nul nul soh nul nak nul
565f524549534e4f000700010015
 
It seems that your database is at version 7 (which is amarok 2.2.0) while 
current version is 14. Apparently, amarok has not fully succeeded in updating 
the database since then...

So each time amarok starts, it runs (or not) 7 upgrade scripts some of which 
have already been completed probably. Since the code does not appear to have a 
sence of database transactions (as far as I can tell anyway, I might be 
wrong), your database might already be in inconsistent state. Therefore, I 
strongly recommend to backup and purge database, then start from scratch (and 
export playlists/other data to external files beforehand).

Alternatively you could run:

$ amarok --debug --nofork 21 | tee amarok-debug.log

wait for amarok to start, close it and then attach amarok-debug.log. What is 
more, take notice of which statement amarok gets stuck at if any. However, I 
doubt this will take us far since the only way to fix your dabatase is to hack 
it manually.

I'm marking this bug as normal since 2.2.0 has never been in stable (first 
version in stable is 2.4.3) and iirc,  2.3 series had some nasty bugs which 
might have led to this state after all.


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

Bug#640499: libxvmc: please add multiarch support

2012-08-18 Thread Ralf Jung

Hi,

 Have the upgrade and install paths paths of this scenario been tested? And 
 the 
 case of locally modified/removed config files?
 
 I'll take libfoo as an example package that ships /etc/foo.conf
 
[snip]
 
 Just curious ...
Whatever happens here is not specific to libxvmc - see libpam-modules as
another example for an MA: same package shipping a conffile. As long as
the conffile shipped in the packages is the same across all
architectures, there should be nothing to worry about (besides dpkg
bugs, of course).
If you meant this as general question, not specific for libxvmc, then
asking at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684776 might
give you a better chance of someone knowing he answer ;-) (esp. if you
put Guillem in CC).

Kind regards,
Ralf


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

Bug#682905: can't import signatures

2012-08-18 Thread Daniel Pocock



On 18/08/12 08:22, Daniel Pocock wrote:
 
 Hmm, that may make it harder to reproduce it. Can you please send me
 your enigmail settings in the problematic profile:

 egrep -i enigmail|pgp ~/.icedove/*/prefs.js
 
 I attach prefs from the bad profile and the good profile
 
 Do any of the prefs look unusual?
 


Just a further update

I stopped icedove, manually edited prefs.js to remove all the settings
that don't exist in the good prefs.js from the other profile, and then
started icedove again.

However, it did not fix the problem.

Does that egrep statement definitely find all relevant prefs?

Are these related?

user_pref(mail.identity.id1.defaultEncryptionPolicy, 0);
user_pref(mail.identity.id1.encryptionpolicy, 0);


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

Bug#685199: Freeze exception for ns3

Control: merge 683753 -1

On Sat, 2012-08-18 at 15:13 +0800, YunQiang Su wrote:
 Please consider unblock ns3 to testing.

There's already a request for that - #683753; please check before filing
new ones.

 The current version of ns3 in unstable is uploaded before freeze,
 while blocked by FTBFS on mipsel and mips due to lack of memory
 on these two architectures.
 
 I have asked ftp-master to deleted it from testing [bug: #682201], and
 except it to migrate to testing automatically, but it didn't work.

There are two problems with that - a) ftp-master don't remove things
from testing (and indeed that bug doesn't actually request that anyway)
and b) #673623 was still marked as affecting the version in unstable.

Apparently the versions on #673623 were wrong, but by the time that was
fixed the automatic freeze exception had expired.  We're now six weeks
in to the freeze and ns3 hasn't been in testing for about 10 months, so
is effectively a new package.  I realise the circumstances are
unfortunate but at this stage of the freeze we generally wouldn't be
looking at adding new packages.

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#668109: rhythmbox: shuffle mode (play songs randomly) pauses with ogg files

2012-08-18 Thread YunQiang Su

For me, it paused when play flac files.

-- 
YunQiang Su


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

Bug#674039: [Pkg-sysvinit-devel] Bug#674039: mount -a still required

2012-08-18 Thread Stephan Lohse

Hi,

I have the same problem as Matthijs.
I believe the problem is caused by the NetworkManager setting ADDRFAM
to NetworkManager in /etc/NetworkManager/dispatcher.d/01ifupdown.
That script calls the scripts in /etc/network/if-*.d
When I change the previously mentioned line in
/etc/network/if-up.d/mountnfs to
[ $ADDRFAM = inet ] || [ $ADDRFAM = inet6 ] || [ $ADDRFAM =
NetworkManager ] || exit 0
it works for me.
However, I don't know what other side effects that might have, I hope
someone who knows more about NetworkManager can comment on that.

Regards,
Stephan


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

Bug#685195: unblock: aptitude/0.6.8-2

Control: tags -1 + moreinfo

On Sat, 2012-08-18 at 12:03 +0800, Daniel Hartwig wrote:
 Please unblock package aptitude
 
 Includes non-intrusive changes for multi-arch support.  Without the
 first of these aptitude is effectively broken on multi-arch systems
 due to #672340.  Changelog entry:

-2 doesn't appear to be in the archive yet?

[...]
 Unblock lines for all packages built from the aptitude source, only
 aptitude, -common, and -dbg are changed in this version.
 
 unblock aptitude/0.6.8-2
 unblock aptitude-common/0.6.8-2

Only the first of those is required (or even possible) - unblocks are
source-based; one can't migrate just one binary package from a new
version.

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#685204: dnsmasq: trying to overwrite config files in dnsmasq-base

2012-08-18 Thread Neil Williams

Package: dnsmasq
Version: 2.63-1
Severity: serious
Justification: Fails to install

Upgrading dnsmasq to 2.63-1 fails:

E: /var/cache/apt/archives/dnsmasq-base_2.63-1_amd64.deb: trying to overwrite 
'/etc/dbus-1/system.d/dnsmasq.conf', which is also in package dnsmasq 2.62-3

Looks like a missing Replaces or an accidental move of the
config file?

http://lists.debian.org/debian-devel/2008/10/msg00624.html


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

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

Versions of packages dnsmasq depends on:
ii  adduser   3.113+nmu3
ii  dnsmasq-base  2.62-3
ii  netbase   5.0

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
pn  resolvconf  none

-- Configuration Files:
/etc/dnsmasq.conf changed:
interface=usb0
dhcp-range=10.1.1.2,10.1.1.2,1m
domain=tcldomain.office


-- 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#666267: liferea: Search folders with unread items not marked as such

2012-08-18 Thread Tathar aucun

Package: liferea
Version: 1.8.6-1
Followup-For: Bug #666267

I have the same bug that Michal Politowski since version 1.8. *

the search folder not working properly. the item does not appear or
dissparaisse aussitot.the number of items does not match.
the problem also affects the folder unread.

eee4b10ff4992c2959eead6343ecbdcd42c6fb42 version of the deposit is the
latest
version git functional

thank you



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (980, 'stable-updates'), (980, 'stable'),
(90, 'experimental'), (90, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages liferea depends on:
ii  gconf-service   3.2.5-1
ii  gconf2  3.2.5-1
ii  libatk1.0-0 2.4.0-2
ii  libc6   2.13-33
ii  libcairo2   1.12.2-2
ii  libgconf-2-43.2.5-1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.32.3-1
ii  libgtk2.0-0 2.24.10-2
ii  libice6 2:1.0.8-2
ii  libjson-glib-1.0-0  0.14.2-1
ii  libnotify4  0.7.5-1
ii  libpango1.0-0   1.30.0-1
ii  libsm6  2:1.2.1-2
ii  libsoup2.4-12.38.1-2
ii  libsqlite3-03.7.13-1
ii  libunique-1.0-0 1.1.6-4
ii  libwebkitgtk-1.0-0  1.8.1-2
ii  libxml2 2.8.0+dfsg1-5
ii  libxslt1.1  1.1.26-13
ii  liferea-data1.8.6-1

Versions of packages liferea recommends:
ii  dbus  1.6.0-1
ii  dbus-x11  1.6.0-1
ii  wget  1.13.4-3

Versions of packages liferea suggests:
ii  network-manager  0.9.4.0-5

Bug#685092: Wheezy/Testing LAMP and Magento 1.5.1

2012-08-18 Thread Arno Töll

On 16.08.2012 19:48, YorYor@SeordCast wrote:
 [Fri Aug 17 09:41:32 2012] [notice] child pid 5177 exit signal
 Segmentation fault (11)

This is PHP crashing, not Apache. If you can reproduce this for every
request provide a back trace (see README.backtrace in your Apache doc
directory) to PHP maintainers and reassing this bug to them.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#685195: unblock: aptitude/0.6.8-2

2012-08-18 Thread Daniel Hartwig

On 18 August 2012 16:48, Adam D. Barratt a...@adam-barratt.org.uk wrote:
 Control: tags -1 + moreinfo

 On Sat, 2012-08-18 at 12:03 +0800, Daniel Hartwig wrote:
 Please unblock package aptitude

 Includes non-intrusive changes for multi-arch support.  Without the
 first of these aptitude is effectively broken on multi-arch systems
 due to #672340.  Changelog entry:

 -2 doesn't appear to be in the archive yet?

Wanted to get approval first, in case of changes being requested.
Available on mentors.d.n:

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

http://mentors.debian.net/debian/pool/main/a/aptitude/aptitude_0.6.8-2.dsc


 [...]
 Unblock lines for all packages built from the aptitude source, only
 aptitude, -common, and -dbg are changed in this version.

 unblock aptitude/0.6.8-2
 unblock aptitude-common/0.6.8-2

 Only the first of those is required (or even possible) - unblocks are
 source-based; one can't migrate just one binary package from a new
 version.

Thanks, I wasn't sure about that.


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

Bug#685205: runsnakerun: OSError: Unable to determine user's application-data directory

2012-08-18 Thread Jakub Wilk


Package: runsnakerun
Version: 2.0.2a1-2
Severity: important
Usertags: serious

If $HOME/.config/ doesn't exist, runsnake fails with unhelpful error 
message:


$ runsnake
Traceback (most recent call last):
  File /usr/bin/runsnake, line 9, in module
load_entry_point('RunSnakeRun==2.0.2a1', 'gui_scripts', 'runsnake')()
  File /usr/lib/python2.7/dist-packages/runsnakerun/runsnake.py, line 781, in 
main
app = RunSnakeRunApp(0)
  File /usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py, line 
7981, in __init__
self._BootstrapApp()
  File /usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py, line 
7555, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/runsnakerun/runsnake.py, line 718, in 
OnInit
frame = MainFrame( config_parser = load_config())
  File /usr/lib/python2.7/dist-packages/runsnakerun/runsnake.py, line 767, in 
load_config
filename = config_file()
  File /usr/lib/python2.7/dist-packages/runsnakerun/runsnake.py, line 761, in 
config_file
directory = config_directory()
  File /usr/lib/python2.7/dist-packages/runsnakerun/runsnake.py, line 755, in 
config_directory
base = homedirectory.appdatadirectory()
  File /usr/lib/python2.7/dist-packages/runsnakerun/homedirectory.py, line 
69, in appdatadirectory
raise OSError( Unable to determine user's application-data directory )
OSError: Unable to determine user's application-data directory


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

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

Versions of packages runsnakerun depends on:
ii  python 2.7.3-2
ii  python-setuptools  0.6.24-1
ii  python-squaremap   1:1.0.1-1
ii  python2.6  2.6.8-0.2
ii  python2.7  2.7.3-3

--
Jakub Wilk


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

Bug#684265: Still with us -- Re: Bug#684265: (installation-reports: yaboot.conf missing existing root partitions -- sources.list still has deb cdrom from installation)

2012-08-18 Thread Rick Thomas

I just downloaded and burned the PowerPC Netinst CD and did an install  
with it.

Specifically,

http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/arch-latest/powerpc/iso-cd/debian-testing-powerpc-netinst.iso
Daily build #3 for powerpc, using installer build from sid
This build finished at Fri Aug 17 09:39:24 UTC 2012.

The first problem noted in bug#684265 is still there -- the installer  
still does not put the existing root partitions into the generated  
yaboot.conf.


When I installed os-prober and ran it on the installed system, it  
found and listed the existing root partitions, as expected.  So the  
problem is in the installer, not os-prober...


The other problem noted in bug#684265 -- The installer was not  
commenting out the deb cdrom line for the installer CD -- has  
apparently gone away.


Attached is a (hopefully) relevant extract from the installation  
syslog file.


Enjoy!

Rick



syslog.extract
Description: Binary data

Bug#685206: libwrap0:amd64: hosts_{options,access}.5.gz inconsistencies on format

2012-08-18 Thread Edward Welbourne

Package: libwrap0
Version: 7.6.q-23
Severity: normal

Dear Debian Maintainer,

I tried to configure /etc/hosts.{allow,deny} using what man pages told
me; hosts.allow and hosts.deny alias to hosts_access in man.  This told
me I could use lines of form
 daemon_list : client_list [ : shell_command ]
but, in fact, I got errors logged by sshd when I used this format, due
to sshd actually using the format described in man hosts_options
  daemon_list : client_list : option : option ...
(which should clearly be written as
  daemon_list : client_list [ : option ...]
or similar, since options are optional).  It was not immediately clear
what sshd was complaining about, of course - I only found out this was
the problem after writing to Wietse Venema for help ! - but once I'd got
the right information it was indeed possible to get what I wanted.

I thus find the man pages to be somewhat confusing - the one I get
naturally tells me a format that isn't actually supported; it does tell
me there's an extended version of the language, but doesn't make clear
that this is what's actually in use.  I initially used
ALL : ALL : /usr/bin/logger -p auth.warning -- 'Denied %c (%n) access to %d on 
%r'
in my hosts.deny but got error messages which didn't really (given only
the hosts_access man page's content) help me to make sense of what the
error really was; everything in the man page fitted with this being a
valid line to include.  Changing to
ALL : ALL : severity auth.warning
did solve the problem.  The hosts_access man page did say that
hosts_options supersedes shell_command support; but I, at least, failed
to recognise this as a clue that this was why my shell command wasn't
being recognised.

Further, given that the two syntaxes are incompatible, everything I can
see tells me that reading of /etc/hosts.{allow,deny} is up to each
application independently, so I have no way (as administrator of my box)
to know how I can avoid problems with my setup if some applications
choose to support the hosts_access format instead of the hosts_options
format.  Likewise, an application developer has no indication of which
format they should support, to be compatible with configurations
administrators are apt to set up, or of how they should avoid getting
into trouble if the administrator has used the other format than the one
they've chosen to parse.

I can (now that I've tracked down what supplied these man pages) make an
educated guess that libwrap0 provides a library that deals with the
parsing on behalf of applications, but neither man page advises
application developers to use it, nor even mentions the existence of
such a library - as they clearly should.  There should be a man page for
the APIs provided by the library and it should be referenced by the man
pages reached by man hosts.{allow,deny}, since that's where a
developer is apt to start trying to find out how to honour the system
configuration specified in these files.

Given that the extended format is now (apparently) what's supported by
default (in particular, it's what sshd expects - developers of other
applications are particularly likely to take their lead from sshd), it
seems to me that it would make sense to amalgamate the two man pages and
either remove all mention of the shell_command syntax or relegate it to
a historical / backwards-compatibility section, with advice on what to
do with files using this syntax, if encountered.  The format now in
normal use should no longer be described as extended.

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash

Versions of packages libwrap0:amd64 depends on:
ii  libc6  2.13-33
ii  multiarch-support  2.13-33

Versions of packages libwrap0:amd64 recommends:
ii  tcpd  7.6.q-23

libwrap0:amd64 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#685207: tcltrf: source contains non-DFSG-free msvcrt.dll

2012-08-18 Thread Stephen Kitt

Package: tcltrf
Version: 2.1.4-dfsg-2
Severity: serious
Justification: Policy 2.3

Dear Maintainer,

The tcltrf source code contains a copy of msvcrt.dll from Visual
Studio 97, without the accompanying EULA. I believe this file does not
meet the DFSG's requirements and should be removed from the source
tarballs...

Regards,

Stephen


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 
'experimental')
Architecture: i386 (i686)
Foreign Architectures: mingw64-i386

Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores)
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#685195: unblock: aptitude/0.6.8-2

2012-08-18 Thread Philipp Kern

On Sat, Aug 18, 2012 at 12:03:36PM +0800, Daniel Hartwig wrote:
 Another version, 0.6.9.1-1, is in experimental which has further
 improvements to multi-arch support and general usability, including
 some notable bug fixes.  Those are entangled with significant changes
 to the command line interface.  Work is still underway to salvage that
 release.

FWIW I tested 0.6.9.1-1 on wheezy and it still responds to conflicts with the
removal of all i386 binaries on an amd64 system.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Bug#685208: dkms_packages.py crashed with AssertionError in _assert_bin_mode(): file stream must be in binary mode

2012-08-18 Thread rrs

Package: dkms
Version: 2.2.0.3-1.1


=

ProblemType: Crash
Architecture: amd64
Date: Sat Aug 18 14:56:06 2012
Dependencies:
 binutils 2.22-7.1
 coreutils 8.13-3.2
 cpp 4:4.7.1-1
 cpp-4.7 4.7.1-7
 dpkg 1.16.8
 gcc 4:4.7.1-1
 gcc-4.7 4.7.1-7
 gcc-4.7-base 4.7.1-7
 kmod 9-1
 libacl1 2.2.51-8
 libattr1 1:2.4.46-8
 libbz2-1.0 1.0.6-4
 libc-bin 2.13-35
 libc6 2.13-35
 libgcc1 1:4.7.1-7
 libgmp10 2:5.0.5+dfsg-2
 libgomp1 4.7.1-7
 libitm1 4.7.1-7
 libkmod2 9-1
 liblzma5 5.1.1alpha+20120614-1
 libmpc2 0.9-4
 libmpfr4 3.1.0-5
 libquadmath0 4.7.1-7
 libselinux1 2.1.9-5
 libstdc++6 4.7.1-7
 lsb-base 4.1+Debian7
 make 3.82-1
 module-init-tools 9-1
 multiarch-support 2.13-35
 patch 2.6.1.136-31a7-1
 tar 1.26-4
 zlib1g 1:1.2.7.dfsg-13
DistroRelease: Debian 7.0
ExecutablePath: /usr/share/apport/package-hooks/dkms_packages.py
InterpreterPath: /usr/bin/python2.7
Package: dkms 2.2.0.3-1.1
PackageArchitecture: all
ProcCmdline: python /usr/share/apport/package-hooks/dkms_packages.py -m 
iscsitarget -v 1.4.20.2 -k 3.5-trunk-amd64
ProcEnviron:
 LC_PAPER=en_IN.UTF-8
 LC_ADDRESS=en_IN.UTF-8
 LC_MONETARY=en_IN.UTF-8
 SHELL=/bin/bash
 TERM=xterm
 LC_NUMERIC=en_IN.UTF-8
 LC_TELEPHONE=en_IN.UTF-8
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 LC_MEASUREMENT=en_IN.UTF-8
 LANGUAGE=en_US:en
 LC_TIME=en_IN.UTF-8
 LC_NAME=en_IN.UTF-8
ProcMaps:
 0040-00658000 r-xp  08:06 4456504
/usr/bin/python2.7
 00857000-00858000 r--p 00257000 08:06 4456504
/usr/bin/python2.7
 00858000-008c1000 rw-p 00258000 08:06 4456504
/usr/bin/python2.7
 008c1000-008d4000 rw-p  00:00 0 
 017ec000-01edc000 rw-p  00:00 0  [heap]
 7ff487376000-7ff487577000 rw-p  00:00 0 
 7ff4875f8000-7ff487979000 rw-p  00:00 0 
 7ff487979000-7ff489232000 rw-p  08:06 4209708
/var/cache/apt/pkgcache.bin
 7ff489232000-7ff489273000 rw-p  00:00 0 
 7ff4892f5000-7ff48931e000 r--p  08:06 4458823
/usr/lib/girepository-1.0/GLib-2.0.typelib
 7ff48931e000-7ff48932b000 r--p  08:06 4464223
/usr/lib/girepository-1.0/GObject-2.0.typelib
 7ff48932b000-7ff489373000 r--p  08:06 4464225
/usr/lib/girepository-1.0/Gio-2.0.typelib
 7ff489373000-7ff4893b4000 rw-p  00:00 0 
 7ff4893b4000-7ff4893d4000 r-xp  08:06 6315150
/usr/lib/python2.7/dist-packages/gi/_gobject/_gobject.so
 7ff4893d4000-7ff4895d3000 ---p 0002 08:06 6315150
/usr/lib/python2.7/dist-packages/gi/_gobject/_gobject.so
 7ff4895d3000-7ff4895d7000 rw-p 0001f000 08:06 6315150
/usr/lib/python2.7/dist-packages/gi/_gobject/_gobject.so
 7ff4895d7000-7ff489618000 rw-p  00:00 0 
 7ff489618000-7ff489628000 r-xp  08:06 6315151
/usr/lib/python2.7/dist-packages/gi/_glib/_glib.so
 7ff489628000-7ff489828000 ---p 0001 08:06 6315151
/usr/lib/python2.7/dist-packages/gi/_glib/_glib.so
 7ff489828000-7ff48982b000 rw-p 0001 08:06 6315151
/usr/lib/python2.7/dist-packages/gi/_glib/_glib.so
 7ff48982b000-7ff48983e000 r-xp  08:06 1179988
/lib/x86_64-linux-gnu/libresolv-2.13.so
 7ff48983e000-7ff489a3d000 ---p 00013000 08:06 1179988
/lib/x86_64-linux-gnu/libresolv-2.13.so
 7ff489a3d000-7ff489a3e000 r--p 00012000 08:06 1179988
/lib/x86_64-linux-gnu/libresolv-2.13.so
 7ff489a3e000-7ff489a3f000 rw-p 00013000 08:06 1179988
/lib/x86_64-linux-gnu/libresolv-2.13.so
 7ff489a3f000-7ff489a41000 rw-p  00:00 0 
 7ff489a41000-7ff489a5f000 r-xp  08:06 1179737
/lib/x86_64-linux-gnu/libselinux.so.1
 7ff489a5f000-7ff489c5e000 ---p 0001e000 08:06 1179737
/lib/x86_64-linux-gnu/libselinux.so.1
 7ff489c5e000-7ff489c5f000 r--p 0001d000 08:06 1179737
/lib/x86_64-linux-gnu/libselinux.so.1
 7ff489c5f000-7ff489c6 rw-p 0001e000 08:06 1179737
/lib/x86_64-linux-gnu/libselinux.so.1
 7ff489c6-7ff489c61000 rw-p  00:00 0 
 7ff489c61000-7ff489c9d000 r-xp  08:06 1182916
/lib/x86_64-linux-gnu/libpcre.so.3.13.1
 7ff489c9d000-7ff489e9d000 ---p 0003c000 08:06 1182916
/lib/x86_64-linux-gnu/libpcre.so.3.13.1
 7ff489e9d000-7ff489e9e000 rw-p 0003c000 08:06 1182916
/lib/x86_64-linux-gnu/libpcre.so.3.13.1
 7ff489e9e000-7ff489fe9000 r-xp  08:06 4459474
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.3200.3
 7ff489fe9000-7ff48a1e8000 ---p 0014b000 08:06 4459474
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.3200.3
 7ff48a1e8000-7ff48a1ec000 r--p 0014a000 08:06 4459474
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.3200.3

Bug#684227: reportbug: --source command-line option does not work

2012-08-18 Thread Sandro Tosi

Hello Ian,

On Wed, Aug 8, 2012 at 1:25 AM, Ian Bruce ian_br...@fastmail.net wrote:
 This does not work:

 $ reportbug --source debian-installer
 No package specified or we were unable to find it in the apt cache; 
 stopping.

Well, it's written in the error message: either the pkg doesn't exit
or the *apt cache* doesn't know it, and if you want to report a bug
against a source package you'd have to have the corresponding deb-src
like in the sources.list for the apt cache to know it. Even if it's
pretty clear to me, I'll add a mention of it in the manpage.

 What does appear to work is this:

 reportbug src:package-name

that's a workaround, given it will generate several warning menus for
non-existing pkg and end up with a Package: src:package-name in
the report.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

Bug#683720: unblock: rrdtool/1.4.7-2

2012-08-18 Thread Sebastian Harl

Hi,

sorry, I must have missing this E-mail somehow :-/

On Sat, Aug 04, 2012 at 04:48:02PM +0100, Adam D. Barratt wrote:
 On Fri, 2012-08-03 at 10:28 +0200, Sebastian Harl wrote:
  Please unblock package rrdtool
  
  The current version in unstable (1.4.7-2) fixes an RC bug (#664724)
  causing RRDCacheD (the RRDtool Caching Daemon) to segfault on startup if
  the daemon's data directory does not exist. This bug had been addressed
  by an NMU by creating the default directories in the init script. I've
  later added a patch fixing the issue in the daemon in order to provide a
  general fix for the underlying issue.
 
 This change appears not to be documented in the changelog:
 
 --- rrdtool-1.4.7/debian/control
 +++ rrdtool-1.4.7/debian/control
 @@ -8,7 +8,7 @@
 [...]
 - tcl-dev (= 8.5), tcl (= 8.5),
 + tcl-dev (= 8), tcl-dev (= 9),

Yes, this was a minor fix which was applied to the Debian Git tree in
between our last upload to unstable and the 1.4.7-1.1 NMU and thus kinda
accidentally ended up in the current upload.

The former restriction (depend on = 8.5) was used for a test-build
against newer versions of Tcl but is not imposed by RRDtool. Removing
that restriction does not harm building RRDtool but, in contrast, makes
backporting easier.

I'm sorry that I missed the change on the last upload but imho it's
perfectly safe to let that into Wheezy. Anyway, if you would not prefer
to let that in during the freeze, please tell me whether you prefer a
new upload to unstable reverting that or an upload to -p-u only
including the other (documented) changes.

Thanks in advance,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#683378: CVE-2012-0283

2012-08-18 Thread Tanguy Ortolo


Tanguy Ortolo, 2012-08-17 11:04+0200:
I have just had a look to the code: squeeze is affected. I shall 
prepare an update by hand.


Well, after looking more closely, it appears that in fact, it is not. 
The fix for version 0.0.20120125 in testing does apply to 0.0.20091225 
in stable after some modifications, but:

1. it breaks some functionnality;
2. it is useless, because it is meant to cover a use case that did not 
   exist at the time (the code to process the POST argument do=media fo 
   the possible attack is only present in 0.0.20120125).


So, sorry for my hesitation with this bug…

--
 ,--.
: /` )   Tanguy Ortolo  xmpp:tan...@ortolo.eu
| `-'Debian Developer   irc://irc.oftc.net/Tanguy
 \_


signature.asc
Description: Digital signature

Bug#432095: 2.5 should be compatible with 3.0

2012-08-18 Thread Fabio

According to this two FAQ:
http://wiki.creativecommons.
org/Frequently_Asked_Questions#Which_Creative_Commons_ShareAlike_license_versions_are_compatible_with_each_other.
3F
http://wiki.creativecommons.
org/License_versions#Compatible_licenses_may_be_used_for_adaptations_of_works_originally_offered_under_CC_ShareAlike_licenses

CC-BY-SA since 2.0 should be compatible with 3.0, so Debian could just 
relicense to it.  However they speak only of adaptations, so I don't know if 
the unmodified data can be released to 3.0. Maybe it should be discussed in 
debian-legal.


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

Bug#684453: [pkg-eucalyptus-maintainers] Bug#684453: Bug#684453: hand over packaging to debian-java team

2012-08-18 Thread Steffen Möller

Hello,

 Original-Nachricht 
 Datum: Sat, 18 Aug 2012 11:05:51 +0900
 Von: Charles Plessy ple...@debian.org
 An: Thomas Koch tho...@koch.ro, 684...@bugs.debian.org
 Betreff: [pkg-eucalyptus-maintainers] Bug#684453: Bug#684453: hand over   
 packaging to debian-java team

 Le Fri, Aug 10, 2012 at 08:45:40AM +0200, Thomas Koch a écrit :
  
  I'll have some time again in two weeks to continue working on gwt and
 would like
  to salvage[3] the package then under the debian-java umbrella. Please
 respond to
  this bug if you disagree (or agree).
 
 In my understading, the consensus is that Thomas goes ahead with
 transferring
 the package to the debian-java team, where many of us are already members,
 with
 a bit of care of not making an upload that would break eucalyptus while we
 are
 still considering asking for a freeze exception.

We had not talked about it, but knowing of everyone's ambition to integrate as 
much as reasonably possible with the Open Source world, I do not see why to 
object about it - but there is no autoroute to a freeze exception.

It would be nice for you to test that indeed there is no disturbance of any 
reverse dependencies by your changes. Pleae be aware, the update of hibernate 
by pkg-java has killed the upload of Eucalyptus 1.6 to Squeeze before by a 
situation just like this should be compatible. It was not. I would hence 
object any freeze exception unless Brian confirms also the runtime 
compatibility. Talk to Brian directly about everything, please.
 
 Thomas, thank you very much for your patience.
Yip! Needs more of it, though.

Steffen


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

Bug#685195: unblock: aptitude/0.6.8-2

2012-08-18 Thread Daniel Hartwig

On 18 August 2012 17:27, Philipp Kern pk...@debian.org wrote:
 FWIW I tested 0.6.9.1-1 on wheezy and it still responds to conflicts with 
 the
 removal of all i386 binaries on an amd64 system.

The fix is only recent and was not present in that version. There is
positive feedback for multiarch-conflicts.patch:

http://bugs.debian.org/672340#38
http://bugs.launchpad.net/bugs/831768

Regards


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

Bug#682905: can't import signatures

2012-08-18 Thread Willi Mann

Hi!

Am 2012-08-18 10:35, schrieb Daniel Pocock:
 
 
 On 18/08/12 08:22, Daniel Pocock wrote:

 Hmm, that may make it harder to reproduce it. Can you please send me
 your enigmail settings in the problematic profile:

 egrep -i enigmail|pgp ~/.icedove/*/prefs.js

 I attach prefs from the bad profile and the good profile

 Do any of the prefs look unusual?


No, as far as I can see, nothing unusual.

 
 Just a further update
 
 I stopped icedove, manually edited prefs.js to remove all the settings
 that don't exist in the good prefs.js from the other profile, and then
 started icedove again.
 
 However, it did not fix the problem.
 
 Does that egrep statement definitely find all relevant prefs?
 
 Are these related?
 
 user_pref(mail.identity.id1.defaultEncryptionPolicy, 0);
 user_pref(mail.identity.id1.encryptionpolicy, 0);

Yes, defaultEncryptionPolicy is also from enigmail (see
extensions/enigmail/ui/content/enigmailEditIdentity.js in the source).
However, I also have it set to 0, so this is nothing unusual.
encryptionpolicy is not from enigmail, at least not from current
versions as I cannot find the string in the source. However, this value
is also set to 0 in my profile, so it cannot be the culprit.

Do you use IMAP or POP3?

WM


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

Bug#682905: can't import signatures

2012-08-18 Thread Daniel Pocock


 Do you use IMAP or POP3?

It is IMAP


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

Bug#685182: screen: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

2012-08-18 Thread Axel Beckert

Hi Adriano,

Adriano Rafael Gomes wrote:
 Please, Could you update the Brazilian Portuguese
 Translation?

Will do it if current version in Wheezy stays in Wheezy (which is not
the plan). The version in Sid no more needs debconf and hence no more
needs translations.

Is there a way so that translators see that the current version in Sid
no more needs translations to prevent unnecessary work?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert a...@debian.org, 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#685209: unblock: ball/1.4.1+20111206-4

2012-08-18 Thread Steffen Moeller

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

Please unblock package ball

The uploader is upstream who kindly added a patch to fix a FTBFS.
The buildd are happy now, the package as a good rate of acceptance
on popcon http://qa.debian.org/popcon.php?package=ball
and also scientifically won a series of prices over the last months.
We should expect the number of installations to raise further.

With upstream involving many groups from at (now) many different
institutions, the free license is intrinsic to their development.
Debian Med helps with the distribution of the science, but upstream
is more with Ubuntu and more a virtual-image type of user of Debian
and so the one to blame for the late upload is mostly me who I did
not communicate the freeze in time.

Paired with all the extra funding they get for their research,
also for adopting the very latest hardware from the processor
makers, it is good for Debian to have that link and it would be
sad not to see this structural biology environment in Wheezy.

Many thanks

Steffen

unblock ball/1.4.1+20111206-4

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

Kernel: Linux 3.5-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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#670046: still buggy in Wheezy

2012-08-18 Thread Ingo

Problems still persist in xfce4-sensors-plugin (version 1.2.5-1+b1) in
Wheezy, maybe showing up in a different way.

For some reason package 'hddtemp' is installed automatically, despite I
do not need it. My PC does not have any rotational HD, just an Intel
520series SSD which does not contain any temperature sensor (at least
those S.M.A.R.T. attributes are missing).

In this situation at every login to XFCE desktop I got a warning like
this (in German):

  WARNUNG: Laufwerk /dev/sda scheint keinen Temperatur-Sensor zu haben.
  WARNUNG: Das bedeutet nicht, dass es keinen besitzt.
  WARNUNG: Falls Sie sicher sind, dass es einen besitzt, kontaktieren
Sie mich bitte (hddt...@guzu.net).
  WARNUNG: Siehe Optionen --help, --debug und --drivebase.
  /dev/sda: INTEL SSDSC2CW120A3: kein Sensor

To get rid of this I edited /etc/default/hddtemp and set:
  DISKS_NOPROBE=/dev/sda

That did not help either as well as un-installing 'hddtemp'. Without
hddtemp installed sensors-plugin complaions about hddtemp missing.

Then I did edit the user configuration of the sensors-plugin in
  ~/.config/xfce4/panel/xfce4-sensors-plugin-36.rc

and set:
  Suppress_Hddtemp_Message=false- true

This as well did not help. I finally recognized that this user
configuration file gets overwritten at any login and the option is reset
to false!

A current workaround I found meanwhile:
make sure you are not logged in to any XFCE session (i.e. switch to a
console at light-dm) and edit your
~/.config/xfce4/panel/xfce4-sensors-plugin-36.rc. this at least
suppresses the popup's at every login, but does not solve the problem
that sensors-plugin does insist on checking for a non existent
HDD-temperature using hddtemp.


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

Bug#685210: RM: afio [armel armhf i386 ia64 mips mipsel powerpc s390 s390x sparc] -- ANAIS; non-free, it shouldn't have been autobuilt

2012-08-18 Thread Luca Falavigna

Package: ftp.debian.org
Severity: normal

afio has been recently moved to non-free, but got autobuilt because overrides
for main packages were not immediately removed. Hence, autobuilt packages
should be removed.

See https://lists.debian.org/debian-wb-team/2012/08/msg9.html for further
reference.


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

Bug#683299: please unblock: open-vm-tools/2:8.8.0+2012.05.21-724730-4

2012-08-18 Thread Ivo De Decker

Hi all,

On Tue, Aug 14, 2012 at 04:24:52PM +0200, Thijs Kinkhorst wrote:
 As it seems, Daniel has uploaded a version of open-vm-tools that reverts
 the contentious changes. This version has been in unstable for 11 days now
 and no bugs have been reported since.
 
 Can you please review and unblock?

I attached a debdiff between the version in testing
(8.8.0+2012.05.21-724730-1) and the version in unstable
(8.8.0+2012.05.21-724730-4).

The remaining changes are:

+  [ Thijs Kinkhorst ]
+  * Updating dkms.conf to make modules build again, thanks to H.A.J.
+Koster (Closes: #679886).

+  * Calling dh_dkms with version argument (Closes: #677503).


Cheers,

Ivo

diff -Nru open-vm-tools-8.8.0+2012.05.21-724730/debian/changelog open-vm-tools-8.8.0+2012.05.21-724730/debian/changelog
--- open-vm-tools-8.8.0+2012.05.21-724730/debian/changelog	2012-06-14 12:05:21.0 +0200
+++ open-vm-tools-8.8.0+2012.05.21-724730/debian/changelog	2012-08-02 21:35:44.0 +0200
@@ -1,3 +1,36 @@
+open-vm-tools (2:8.8.0+2012.05.21-724730-4) unstable; urgency=low
+
+  * Reverting switch to xz compression to ease wheezy unblock.
+  * Reverting to load modules through kmod instead of initscript to ease
+wheezy unblock.
+  * Reverting added sleep during restart in initscript to ease wheezy
+unblock.
+  * Reverting removing old dpkg trigger for update-initramfs to ease
+wheezy unblock.
+  * Reverting update of GPL boilerplate in copyright file to ease wheezy
+unblock.
+
+ -- Daniel Baumann daniel.baum...@progress-technologies.net  Thu, 02 Aug 2012 21:32:52 +0200
+
+open-vm-tools (2:8.8.0+2012.05.21-724730-3) unstable; urgency=low
+
+  [ Thijs Kinkhorst ]
+  * Updating dkms.conf to make modules build again, thanks to H.A.J.
+Koster (Closes: #679886).
+
+ -- Daniel Baumann daniel.baum...@progress-technologies.net  Mon, 16 Jul 2012 22:06:58 +0200
+
+open-vm-tools (2:8.8.0+2012.05.21-724730-2) unstable; urgency=low
+
+  * Switching to xz compression.
+  * Loading modules through kmod instead of initscript.
+  * Adding sleep during restart in initscript.
+  * Removing old dpkg trigger for update-initramfs.
+  * Updating GPL boilerplate in copyright file.
+  * Calling dh_dkms with version argument (Closes: #677503).
+
+ -- Daniel Baumann daniel.baum...@progress-technologies.net  Sat, 30 Jun 2012 04:55:23 +0200
+
 open-vm-tools (2:8.8.0+2012.05.21-724730-1) unstable; urgency=low
 
   * Merging upstream version 8.8.0+2012.05.21-724730.
diff -Nru open-vm-tools-8.8.0+2012.05.21-724730/debian/open-vm-dkms.dkms open-vm-tools-8.8.0+2012.05.21-724730/debian/open-vm-dkms.dkms
--- open-vm-tools-8.8.0+2012.05.21-724730/debian/open-vm-dkms.dkms	2012-06-14 12:04:17.0 +0200
+++ open-vm-tools-8.8.0+2012.05.21-724730/debian/open-vm-dkms.dkms	2012-07-16 22:05:12.0 +0200
@@ -1,26 +1,48 @@
 PACKAGE_NAME=open-vm-tools
 PACKAGE_VERSION=#MODULE_VERSION#
 
+MAKE_CMD_TMPL=make VM_UNAME=\$kernelver \
+   MODULEBUILDDIR=$dkms_tree/$PACKAGE_NAME/$PACKAGE_VERSION/build
+
+MAKE[0]=$MAKE_CMD_TMPL -C vmblock;\
+ $MAKE_CMD_TMPL -C vmci;   \
+ $MAKE_CMD_TMPL -C vmhgfs; \
+ $MAKE_CMD_TMPL -C vmsync; \
+ $MAKE_CMD_TMPL -C vmxnet; \
+ $MAKE_CMD_TMPL -C vsock
+CLEAN[0]=$MAKE_CMD_TMPL -C vmblock clean;\
+  $MAKE_CMD_TMPL -C vmci clean;   \
+  $MAKE_CMD_TMPL -C vmhgfs clean; \
+  $MAKE_CMD_TMPL -C vmsync clean;\
+  $MAKE_CMD_TMPL -C vmxnet clean; \
+  $MAKE_CMD_TMPL -C vsock clean
+
 BUILT_MODULE_NAME[0]=vmblock
+BUILT_MODULE_LOCATION[0]=vmblock/
 DEST_MODULE_LOCATION[0]=/updates/dkms/
 AUTOINSTALL=yes
 
 BUILT_MODULE_NAME[1]=vmci
+BUILT_MODULE_LOCATION[1]=vmci/
 DEST_MODULE_LOCATION[1]=/updates/dkms/
 AUTOINSTALL=yes
 
 BUILT_MODULE_NAME[2]=vmhgfs
+BUILT_MODULE_LOCATION[2]=vmhgfs/
 DEST_MODULE_LOCATION[2]=/updates/dkms/
 AUTOINSTALL=yes
 
 BUILT_MODULE_NAME[3]=vmsync
+BUILT_MODULE_LOCATION[3]=vmsync/
 DEST_MODULE_LOCATION[3]=/updates/dkms/
 AUTOINSTALL=yes
 
 BUILT_MODULE_NAME[4]=vmxnet
+BUILT_MODULE_LOCATION[4]=vmxnet/
 DEST_MODULE_LOCATION[4]=/updates/dkms/
 AUTOINSTALL=yes
 
 BUILT_MODULE_NAME[5]=vsock
+BUILT_MODULE_LOCATION[5]=vsock/
 DEST_MODULE_LOCATION[5]=/updates/dkms/
 AUTOINSTALL=yes
diff -Nru open-vm-tools-8.8.0+2012.05.21-724730/debian/rules open-vm-tools-8.8.0+2012.05.21-724730/debian/rules
--- open-vm-tools-8.8.0+2012.05.21-724730/debian/rules	2012-06-14 12:04:17.0 +0200
+++ open-vm-tools-8.8.0+2012.05.21-724730/debian/rules	2012-08-02 21:32:07.0 +0200
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+VERSION = $(shell dpkg-parsechangelog | awk '/^Version: / { print $$2 }' | sed -e 's|^.*:.*+||' -e 's|-.*$$||')
+
 %:
 	dh ${@} --with autotools_dev,dkms
 
@@ -49,6 +51,9 @@
 override_dh_builddeb:
 	dh_builddeb -- -Zgzip -z9
 
+override_dh_dkms:
+	dh_dkms -V $(VERSION)
+
 override_dh_fixperms:
 	dh_fixperms -Xsbin/mount.vmhgfs

Bug#685211: unblock: postgresql-9.1/9.1.5-1

2012-08-18 Thread Martin Pitt

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

Hello release team,

yesterday, PostgreSQL announced new security/bug fix microreleases:

  http://www.postgresql.org/about/news/1407/

I uploaded 9.1.5 into unstable with priority medium:

  http://packages.qa.debian.org/p/postgresql-9.1/news/20120817T223635Z.html

The package successfully passes the upstream as well as the
postgresql-common integration tests and built fine on most
architectures except of mipsel where it is still needs-build.

There are no packaging changes except debian/changelog. Do you want an
unfiltered/filtered upstream diff, etc?

Thank you for considering!

Martin

unblock postgresql-9.1/9.1.5-1

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


signature.asc
Description: Digital signature

Bug#685207: tcltrf: source contains non-DFSG-free msvcrt.dll

2012-08-18 Thread Sergei Golovan

Hi Stephen!

On Sat, Aug 18, 2012 at 12:23 PM, Stephen Kitt st...@sk2.org wrote:

 The tcltrf source code contains a copy of msvcrt.dll from Visual
 Studio 97, without the accompanying EULA. I believe this file does not
 meet the DFSG's requirements and should be removed from the source
 tarballs...

I'll remove it on the next upload. Should it be removed from stable as well?

Cheers!
-- 
Sergei Golovan


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

Bug#678904: bouncycastle: FTBFS with gcj

2012-08-18 Thread Damien Raude-Morvan


Hi all,

I haven't seen that bouncycastle package was under pkg-java team 
maintainance, so I'll fix this myself (Team upload) and prepare a new 
upload real soon now.


Cheers,

On 17/08/2012 00:26, Damien Raude-Morvan wrote:

reopen 678904
found 678904 1.46+dfsg-6
thanks

Hi,

It seems that bouncycastle still FTBFS with GCJ after 1.46+dfsg-6 upload.
However, this is a different failure :

[...]

 [javac] 822. ERROR in /build/buildd-bouncycastle_1.46+dfsg-6-kfreebsd-
amd64-0I1Ozr/bouncycastle-1.46+dfsg/build/artifacts/jdk1.5/bcprov-
jdk15-146/src/org/bouncycastle/jce/ECPointUtil.java
 [javac]  (at line 3)
 [javac]import java.security.spec.ECFieldF2m;
 [javac]   ^
 [javac] The import java.security.spec.ECFieldF2m cannot be resolved

[...]

So there is some missing classes from GCJ classpath, like
java.security.spec.ECFieldF2m (linked to elliptic curve ciffer which is in JDK
API since 1.5).

For now, so you might to Build-Depends on default-jdk (= 1:1.6) and request
removal of binaries on kfreebsd-*

Regards,



--
Damien - Debian Developper
http://wiki.debian.org/DamienRaudeMorvan


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

Bug#684240: lenovo t61 laptop fails to shutdown

Hi Luis,

Luis Mochan wrote:

 I tried, but after blacklisting nvidia, commenting out
 nvidia-kernel-common.conf and running update-initramfs -u to avoid
 nvidia being loaded, the noveau driver was loaded instead and the
 video of my laptop became useless. I couldn't use nor X nor the text
 consoles. I had to boot from a live CD to revert my changes and load
 nvidia again.

Does blacklisting both nvidia and nouveau work?

Can you say a little more about how nouveau makes your laptop
video useless (preferably with logs, e.g. if you can ssh in)?  That
would be another, important bug.

Thanks and hope that helps,
Jonathan


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

Bug#685182: screen: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

2012-08-18 Thread Christian PERRIER

Quoting Axel Beckert (a...@debian.org):
 Hi Adriano,
 
 Adriano Rafael Gomes wrote:
  Please, Could you update the Brazilian Portuguese
  Translation?
 
 Will do it if current version in Wheezy stays in Wheezy (which is not
 the plan). The version in Sid no more needs debconf and hence no more
 needs translations.
 
 Is there a way so that translators see that the current version in Sid
 no more needs translations to prevent unnecessary work?


The status pages should tell them as they're based un unstable.

http://www.debian.org/international/l10n/po-debconf/pot

Of course, when translation teams started to work on a given package,
they don't check the status pages every day..:-)




signature.asc
Description: Digital signature

Bug#684841: wagon2: FTBFS: missing org.bouncycastle:bcprov:jar:debian

2012-08-18 Thread Damien Raude-Morvan


Hi,

On 14/08/2012 09:36, Lucas Nussbaum wrote:

Missing:
--
1) org.bouncycastle:bcprov:jar:debian

   Try downloading the file manually from the project website.

   Then, install it using the command:
   mvn install:install-file -DgroupId=org.bouncycastle -DartifactId=bcprov 
-Dversion=debian -Dpackaging=jar -Dfile=/path/to/file

   Alternatively, if you host your own repository you can deploy the file there:
   mvn deploy:deploy-file -DgroupId=org.bouncycastle -DartifactId=bcprov 
-Dversion=debian -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] 
-DrepositoryId=[id]

   Path to dependency:
1) org.apache.maven.wagon:wagon-ssh-external:jar:2.2
2) org.bouncycastle:bcprov:jar:debian


Maybe there is a missing versionned depends on libbcprov-java (since I 
need at least 1.44+dfsg-3 with maven artifacts) but I'm now waiting for 
a fix for #678904 to allow transition of new bouncycastle to wheezy.


Thanks for you report.
--
Damien


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

Bug#685209: unblock: ball/1.4.1+20111206-4

Control: tags -1 + moreinfo

On Sat, 2012-08-18 at 12:05 +0200, Steffen Moeller wrote:
 The uploader is upstream who kindly added a patch to fix a FTBFS.

A patch is somewhat of a misnomer, given:

 patches/0001-Adjust-compiler-settings.patch |   22 
 patches/0001-missingSigned.patch|   36 
 patches/0002-fix_python_sip_const.patch |   52 
 patches/0003-Add-Copyconstructor-to-String.patch|   40 
 patches/0004-Fix-compilation-of-hashMap.h-on-gcc-4.7.patch  |   35 
 patches/0005-Modify-BALL_RELEASE_STRING-macro.patch |   22 
 patches/0006-Fix-compilation-of-binaryFileAdaptor-with-gcc-4.7.patch|   79 
 patches/0007-Fixed-the-FPT-version-of-bond-order-assignment.patch   |  447 

 patches/0008-Added-MAX_PENALTY-option-to-bond-order-assignment.patch|  975 
++
 patches/0009-Fixed-a-bug-in-the-AssignBondOrderProcessor.patch  |  271 
++
 patches/0010-Fix-compilation-of-FTPBondOrderStrategy-Fixes-451.patch|  138 
+
 patches/0011-Fix-compilation-of-Python-bindings-with-new-sip-vers.patch |   25 
 patches/fix_python_sip_const.patch  |   41 
 patches/missingSigned.patch |   26 

The last two appear to have been replaced by the second and third, which
is annoying but not the end of the world.  The first patch seems to have
disappeared entirely.

There's also a change to maintainers / uploaders which isn't mentioned.

While I'm happy to believe that a number of the patches are required to
fix building with gcc-4.7, these at least don't look like they are:

 patches/0007-Fixed-the-FPT-version-of-bond-order-assignment.patch   |  447 

 patches/0008-Added-MAX_PENALTY-option-to-bond-order-assignment.patch|  975 
++
 patches/0009-Fixed-a-bug-in-the-AssignBondOrderProcessor.patch  |  271 
++

Indeed some of those look like they may well introduce ABI changes if
the changes are reflected in libball.

This obviously isn't a gcc 4.7 fix:

 patches/0011-Fix-compilation-of-Python-bindings-with-new-sip-vers.patch |   25 

It may well be needed for the package to build in unstable now, but it's
certainly not covered by Fix compilation with g++ = 4.7.

Was simply forcing building with gcc 4.6 considered as an option?

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#640499: hardening, too

2012-08-18 Thread Cyril Brulebois

Hi Adam,

Adam Borowski kilob...@angband.pl (18/08/2012):
 I just got bit by the lack of multiarch here (wine is broken on amd64
 if nvidia is involved), and wrote a multiarchification patch before
 realizing there's already one here.  It's redundant, except for one
 bit: since an upload is needed anyway

given the intrusiveness of that patch [libxvmc/multiarch], I'm pretty
sure it's going to be considered too late in the release cycle. I'm
also pretty sure that we (release team) said that already for similar
packages.

[cc: release team for other opinions.]

 you could just as well add the hardening flags (another release goal).
 It's a trivial change, but git am is still faster than doing that
 yourself...

Thanks, but please note that requesting unrelated features in a given
bug report isn't too nice.

BTW, you call it trivial but you lost -Wall…

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#685212: service --status-all incorrectly detect availability of service status in initscript

2012-08-18 Thread Alexander Golovko

package: sysvinit-utils
version: 2.88dsf-13.1+squeeze1
tags: patch

service --status-all incorrectly detect availability of service
status in initscript and show ?. For example, it show ? for cron.
Problem in incorrect regex for detect, that initscript has status
command.


$ service --status-all 21 |grep cron
 [ ? ]  cron

$ /etc/init.d/cron status
Checking periodic command scheduler...done (running).


-- 
with best regards,
Alexander Golovko
email: alexan...@ankalagon.ru
xmpp: alexan...@ankalagon.ru
--- debian/service/service.orig	2012-08-18 15:03:54.953060728 +0400
+++ debian/service/service	2012-08-18 15:04:19.725061121 +0400
@@ -74,7 +74,7 @@
   *)
 if ! is_ignored_file ${SERVICE} \
 		 [ -x ${SERVICEDIR}/${SERVICE} ]; then
-if ! grep -qs \Wstatus) $SERVICE; then
+if ! grep -qs \(^\|\W\)status) $SERVICE; then
   #printf  %s %-60s %s\n [?] $SERVICE: unknown 12
   echo  [ ? ]  $SERVICE 12
   continue


signature.asc
Description: PGP signature

Bug#685213: unblock: tcltrf/2.1.4-dfsg1-1

2012-08-18 Thread Sergei Golovan

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


Please unblock package tcltrf

It fixes a DFSG violation (distributing non-distributable MS DLL, see bug
#685207 [1] for detail). The diff between current 2.1.4-dfsg-3 and
2.1.4-dfsg1-1 is attached. The 2.1.4-dfsg1-1 is already accepted into
unstable.

Thank you!


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685207

unblock tcltrf/2.1.4-dfsg1-1

-- System Information:
Debian Release: 6.0.5
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-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/bash
diff -Nru tcltrf-2.1.4-dfsg/debian/changelog tcltrf-2.1.4-dfsg1/debian/changelog
--- tcltrf-2.1.4-dfsg/debian/changelog	2012-08-18 15:00:10.0 +0400
+++ tcltrf-2.1.4-dfsg1/debian/changelog	2012-08-18 15:00:10.0 +0400
@@ -1,3 +1,9 @@
+tcltrf (2.1.4-dfsg1-1) unstable; urgency=low
+
+  * Removed non-DFSG-free msvcrt.dll from the source tarball (closes: #685207).
+
+ -- Sergei Golovan sgolo...@debian.org  Sat, 18 Aug 2012 14:37:06 +0400
+
 tcltrf (2.1.4-dfsg-3) unstable; urgency=low
 
   * Reimplemented MD2 hash after it was removed from the OpenSSL
diff -Nru tcltrf-2.1.4-dfsg/debian/rules tcltrf-2.1.4-dfsg1/debian/rules
--- tcltrf-2.1.4-dfsg/debian/rules	2012-08-18 15:00:10.0 +0400
+++ tcltrf-2.1.4-dfsg1/debian/rules	2012-08-18 15:00:10.0 +0400
@@ -169,8 +169,10 @@
 	CURDIR=`pwd`  TMPDIR=`mktemp -d /tmp/tcltrf.XX`  \
 	cd $$TMPDIR  \
 	wget -O - http://heanet.dl.sourceforge.net/sourceforge/tcltrf/trf$(version).tar.gz | tar zx  \
-	rm -rfv trf$(version)/generic/haval trf$(version)/generic/haval.1996  \
-	tar -zcf $$CURDIR/tcltrf_$(version)-dfsg.orig.tar.gz trf$(version)  \
+	rm -rfv trf$(version)/generic/haval \
+		trf$(version)/generic/haval.1996 \
+		trf$(version)/win/msvcrt.dll  \
+	tar -zcf $$CURDIR/tcltrf_$(version)-dfsg1.orig.tar.gz trf$(version)  \
 	rm -rf $$TMPDIR
 
 get-orig-source-cvs:
Binary files /tmp/03Upc0G2ft/tcltrf-2.1.4-dfsg/win/msvcrt.dll and /tmp/FBu69NG0aq/tcltrf-2.1.4-dfsg1/win/msvcrt.dll differ

Bug#685214: libpython3.3-stdlib: arch-dependent files in Multi-Arch: same package

2012-08-18 Thread Jakub Wilk


Package: libpython3.3-stdlib
Version: 3.3.0~b2-1
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

libpython3.3-stdlib is marked as Multi-Arch: same, but the following 
files are architecture-dependent:


/usr/lib/python3.3/lib-dynload/_bz2.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_codecs_cn.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_codecs_hk.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_codecs_iso2022.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_codecs_jp.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_codecs_kr.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_codecs_tw.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_crypt.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_csv.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_ctypes.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_ctypes_test.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_curses.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_curses_panel.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_dbm.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_decimal.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_hashlib.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_json.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_lsprof.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_lzma.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_multibytecodec.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_multiprocessing.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_sqlite3.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_ssl.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_testbuffer.cpython-33m.so
/usr/lib/python3.3/lib-dynload/_testcapi.cpython-33m.so
/usr/lib/python3.3/lib-dynload/audioop.cpython-33m.so
/usr/lib/python3.3/lib-dynload/cmath.cpython-33m.so
/usr/lib/python3.3/lib-dynload/fpectl.cpython-33m.so
/usr/lib/python3.3/lib-dynload/mmap.cpython-33m.so
/usr/lib/python3.3/lib-dynload/nis.cpython-33m.so
/usr/lib/python3.3/lib-dynload/ossaudiodev.cpython-33m.so
/usr/lib/python3.3/lib-dynload/parser.cpython-33m.so
/usr/lib/python3.3/lib-dynload/readline.cpython-33m.so
/usr/lib/python3.3/lib-dynload/resource.cpython-33m.so
/usr/lib/python3.3/lib-dynload/termios.cpython-33m.so
/usr/lib/python3.3/lib-dynload/xxlimited.cpython-33m.so
/usr/lib/python3.3/lib2to3/Grammar3.3.0.beta.2.pickle
/usr/lib/python3.3/lib2to3/PatternGrammar3.3.0.beta.2.pickle

--
Jakub Wilk


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

Bug#685215: Apt pinning is broken

Package: apt
Version: 0.9.7.4
Severity: important
Tags: confirmed

I took liberty to mark this as confirmed, as it very well is and will as
such hopefully jump at the willing contributors from the top of the
outstanding bugs list. Maintainers' sympathy kindly appreciated.

I know this is kind of TL;DR, but I don't have a blog, and this is a valid
issue report with accompanying observations and proposals. Please bear
with me...


Facing it now: apt pinning, other than general pinning on release
(i.e. Package: * \n Pin: release...), is **broken.**

Per-package pinning doesn't work intuitively (countless forum posts around,
several bug reports below), version pinning suffers serious bugs (doesn't
work, doesn't glob() properly [4])...

This important bug spans 9 years (since 2003), several directly-related bug
reports:

 [1] http://bugs.debian.org/254820 ,
 [2] http://bugs.debian.org/387218 ,
 [3] http://bugs.debian.org/443565 ,
 [4] http://bugs.debian.org/454080 ,
 [5] http://bugs.debian.org/554773 ,
 [6] http://bugs.debian.org/620249 ,

several directly-related bug reports that were nonchalantly demoted to
wishlist-items (?!) by Matt Zimmerman:

 [7] http://bugs.debian.org/216688 ,
 [8] http://bugs.debian.org/239247 ,
 [9] http://bugs.debian.org/242738 ,
[10] http://bugs.debian.org/276602 ,
[11] http://bugs.debian.org/483147 ,
[12] http://bugs.debian.org/312589 ,

and many apt-cache policy, general pinning and its documentation related
bugs:

[13] http://bugs.debian.org/166032 ,
[14] http://bugs.debian.org/308445 ,
[15] http://bugs.debian.org/301464 ,
[16] http://bugs.debian.org/405262 ,
[17] http://bugs.debian.org/557637 ,
[18] http://bugs.debian.org/602094 ,
[19] http://bugs.debian.org/623706 ,
[20] http://bugs.debian.org/673760 . (...)



All these (and possibly other, merged) bug reports, and countless forum
posts [21] desperately say one thing:

  ** Fix `apt-pkg/policy.cc` and rewrite documentation pertaining it! **

Let's do it once and for all?


I don't know who first 'invented' pinning as implemented now, but she
most certainly did it wrong, mainly by making it counter-intuitive.
The argument that just RTFM, the specification is such and is correct, in
spite of being unable to satisfy a most common use case —that is, simple
package pinning— is a non-argument!


The problem lies in assigning priorities. The per-package/version priorities
aren't even priorities in the general sense, but rather some kind of minimum
priority required, as detailed in Carlo Wood's comprehensive pinning
documentation  errata [22], the author of which reported [2]. This
limitation is a serious usability issue.

Furthermore, one cannot even use an external EDSP/CUDF dependency solver and
expect coherent results, with APT::Solver::Strict-Pinning set to false or
otherwise, since package (or version) pins aren't even properly propagated
into EDSP/CUDF dumps, that because policy.cc simply doesn't account for
those pins correctly.

I kindly ask you to spare the discouragement warnings in this instance:
apparently there are valid use cases for pinning ([1-12, 21])!


The problematic policy.cc code may be extremely hard to fix if one is not
well versed in C++ (which I'm not), especially with so few convenience
dependencies, but fuck me if somebody is not up to the challenge.

Whoever fixes this does not only get to enjoy a crate of virtual beer (and
eternal satisfaction by the houri, acknowledged contribution one can put
in her résumé, etc. other immaterial pleasures), but I vow to
Flattr/PayPal/Kickstarter $50 myself, and I am only a poor student.

Since this is not a release-critical bug, there's enough time for testing
until the next freeze.


[21] http://www.google.com/search?q=apt+pinning+doesn't+work
[22] http://carlo17.home.xs4all.nl/howto/debian.html#errata


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

Bug#685209: unblock: ball/1.4.1+20111206-4

2012-08-18 Thread Steffen Möller

Hello,

On 08/18/2012 12:48 PM, Adam D. Barratt wrote:
 Control: tags -1 + moreinfo
 
 On Sat, 2012-08-18 at 12:05 +0200, Steffen Moeller wrote:
 The uploader is upstream who kindly added a patch to fix a FTBFS.
 
 A patch is somewhat of a misnomer, given:
 
  patches/0001-Adjust-compiler-settings.patch |   
 22 
  patches/0001-missingSigned.patch|   
 36 
  patches/0002-fix_python_sip_const.patch |   
 52 
  patches/0003-Add-Copyconstructor-to-String.patch|   
 40 
  patches/0004-Fix-compilation-of-hashMap.h-on-gcc-4.7.patch  |   
 35 
  patches/0005-Modify-BALL_RELEASE_STRING-macro.patch |   
 22 
  patches/0006-Fix-compilation-of-binaryFileAdaptor-with-gcc-4.7.patch|   
 79 
  patches/0007-Fixed-the-FPT-version-of-bond-order-assignment.patch   |  
 447 
  patches/0008-Added-MAX_PENALTY-option-to-bond-order-assignment.patch|  
 975 ++
  patches/0009-Fixed-a-bug-in-the-AssignBondOrderProcessor.patch  |  
 271 ++
  patches/0010-Fix-compilation-of-FTPBondOrderStrategy-Fixes-451.patch|  
 138 +
  patches/0011-Fix-compilation-of-Python-bindings-with-new-sip-vers.patch |   
 25 
  patches/fix_python_sip_const.patch  |   
 41 
  patches/missingSigned.patch |   
 26 
 
 The last two appear to have been replaced by the second and third, which
 is annoying but not the end of the world.  The first patch seems to have
 disappeared entirely.
 
 There's also a change to maintainers / uploaders which isn't mentioned.

The main guy is the same. You are referring to the Debian Med maintenance.
Hm. Right, this could have been mentioned in the changelog. The Debian
source code always resided there, though, it is not really a change.
Andreas of Debian Med had asked for it publicly on the list.

 While I'm happy to believe that a number of the patches are required to
 fix building with gcc-4.7, these at least don't look like they are:
 
  patches/0007-Fixed-the-FPT-version-of-bond-order-assignment.patch   |  
 447 
  patches/0008-Added-MAX_PENALTY-option-to-bond-order-assignment.patch|  
 975 ++
  patches/0009-Fixed-a-bug-in-the-AssignBondOrderProcessor.patch  |  
 271 ++
 
 Indeed some of those look like they may well introduce ABI changes if
 the changes are reflected in libball.
 
 This obviously isn't a gcc 4.7 fix:
 
  patches/0011-Fix-compilation-of-Python-bindings-with-new-sip-vers.patch |   
 25 
 
 It may well be needed for the package to build in unstable now, but it's
 certainly not covered by Fix compilation with g++ = 4.7.

From the description of those bugs I tend to agree that indeed that is more
than the FTBFS required. Upstream mostly works on version 2 of BALL now, so
knowing whatever ships with Wheezy now to be worked with for a while, I presume
Andreas (upstream) to just have wanted some of the later experiences
backported. A respective description in the changelog is missing.

 Was simply forcing building with gcc 4.6 considered as an option?

I did not know myself this was allowed for anything in stable. The bond-order
changes were apparently important. With my Debian Med hat on, I am always
eager to have such close ties with upstream so Debian gets the best that is
possible, not only something that compiles.

I understand that you see difficulties to accept the package for Wheezy
as it is. Would it help you to have the debian/changelog updated with the
maintainer change and a description about those changes to the bond order?

Many thanks and regards,

Steffen


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

Bug#685216: RM: bouncycastle [kfreebsd-i386 kfreebsd-amd64] -- RoM; ANAIS; need openjdk to build

2012-08-18 Thread Damien Raude-Morvan

Package: ftp.debian.org
Severity: normal

Hi,

Lastest release of bouncycastle package (1.46+dfsg) need some classes which 
are only available in openjdk {6,7} and not in GCJ. To achieve this, we now 
Build-Depends on default-jdk (= 1:1.6) which is not available on kfreebsd-*.

Could you please remove old binary packages from kfreebsd-* (= GCJ AOT 
compiled packages).

Cheers,
-- 
Damien - Debian Developper
http://wiki.debian.org/DamienRaudeMorvan


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

Bug#682736: unblock: vmware-manager/0.2.0-2

On Mon, 2012-08-13 at 15:38 +1000, Alexander Zangerl wrote:
 sorry for the late response: after digging through this a few more times
 i've got an explanation for the debdiff output.
[...]
 the problem is that the debian diff doesn't represent file deletions,
 and that i rather should have left the vmm filename intact and just 
 installed it with its new name via debian/rules (hindsight and all that).
 
 net effect: a newly unpacked 0.2.0-2 includes the correct vwm file,
 but also a superfluous and unused vmm file from the orig tarball, 
 which of course reflects only the state before the -1 changes were made.

Okay.  Assuming an upload could be made fairly quickly, I think I'd
prefer a -3 which made the POD changes to the original binary and
installed it under the new name.  Thanks for working on this.

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#685207: tcltrf: source contains non-DFSG-free msvcrt.dll

2012-08-18 Thread Stephen Kitt

Hi Sergei,

On Sat, Aug 18, 2012 at 01:28:58PM +0300, Sergei Golovan wrote:
 On Sat, Aug 18, 2012 at 12:23 PM, Stephen Kitt st...@sk2.org wrote:
  The tcltrf source code contains a copy of msvcrt.dll from Visual
  Studio 97, without the accompanying EULA. I believe this file does not
  meet the DFSG's requirements and should be removed from the source
  tarballs...
 
 I'll remove it on the next upload. Should it be removed from stable as well?

That was fast! I'm guessing it should be removed from stable too; the
version in oldstable is OK.

Thanks,

Stephen


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

Bug#672959: kfreebsd-*: panic: vm_fault_copy_wired

2012-08-18 Thread Axel Beckert

Hi,

here are my observations so far after several hours and evenings of
rebooting my kFreeBSD EeeBox again and again.

I've unfortunately not yet found the real cause or an solution, but
maybe some of my observations spark ideas at others. I'll continue
debugging the issue on Monday evening as I'm not at home for the
weekend.

Roger Leigh wrote:
Looking at the screenshot you attached, I can't see any obvious
reason for fsck to make the kernel panic. There's no indication
of odd scripts (other than geli) running in parallel here.

Same here. But compared to
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=30;filename=vm_fault_copy_wired.png;att=1;bug=672959
and
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=35;filename=kfreebsdcrash.png;att=1;bug=672959
where crash happens after 4 and 6 seconds, my fsck runs around 7
_minutes_ before it crashes. So I doubt that after 7 minutes
uptime a job running parallel _to_ checkroot causes this.

One of the screenshots also hints that the crash is after checkroot.sh
and my experience confirms that, also because my fsck always runs more
than 6 minutes and I think that this means it's likely caused by
something which comes after the checkroot.sh.

Interestingly pressing Ctrl-C during the fsck gives you (after
entering the root password) a working shell and starting
/etc/init.d/checkroot.sh start manually there works without issues.
Exiting the shell reboots (cleanly) and then the system comes up
cleanly again. (Should work as workaround without any preparations
like creating shell scripts to run be instead of init or a live CD to
run the fsck manually. Just be quick enough if your fsck just takes a
few seconds. :-)

So I added set -x to all init.d scripts and (unfortunately) the
crash seems to always happen after the last line of checkroot.sh which
is :, i.e. the last line shown always was + : and the second last
line was + rm -f /dev/rootdev.

So I commented out the removal of /dev/rootdev, but that didn't change
anything either.

I also played around with additional dependencies based on guessing
(e.g. added dependencies on devd or urandom) to at least all the
scripts which have checkroot as direct dependencies to reduce the
parallelism after checkroot.sh, but that didn't change anything
either so far.

Regards, Axel
--
,''`. | Axel Beckert a...@debian.org, 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#684748: Arduino Ethernet library fix, needs testing

2012-08-18 Thread Scott Howard

On Sat, Aug 18, 2012 at 3:32 AM, Marco Righi marco.ri...@gmail.com wrote:
 do you ask about this?

 Command 36 of 1 $avr-gcc --verbose
 Using built-in specs.
 COLLECT_GCC=avr-gcc
 COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.0/lto-wrapper
 Target: avr
 Configured with: ../src/configure -v --enable-languages=c,c++
 --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man
 --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared
 --with-system-zlib --enable-long-long --enable-nls
 --without-included-gettext --disable-libssp --build=x86_64-linux-gnu
 --host=x86_64-linux-gnu --target=avr
 Thread model: single
 gcc version 4.7.0 (GCC)

thanks, helps a lot (looks right...) - i'll keep looking at it


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

Bug#685217: xz-utils: please clarify relationship to upstream

Package: xz-utils
Version: 5.1.1alpha+20120614-1
Severity: important
Tags: patch

xz-utils/sid has been tracking the 5.1.y branch since the start of the
wheezy cycle to help with that branch's stabilization, and although
except for threading support that branch is quite stable, no official
stable release has been cut from it.  As a result, the packaged
version of XZ Utils that will most likely be in wheezy has a
confusingly alarming version number with alpha in the middle.

An ideal fix would have been to improve documentation and polish
enough that the current upstream version could be called stable, but
that won't help with wheezy anyway since we patch out the threading
support.  For now the best we can do is to clarify what patches have
been applied that make the difference between upstream's alpha version
and Debian's soon-to-be-stable one.

Documenting the patches applied is a good practice, anyway (idea
taken from Matthias's gcc packages).
From: Jonathan Nieder jrnie...@gmail.com
Date: Wed, 4 Jul 2012 16:18:05 -0500
Subject: xz-utils/README.Debian: Document patches

Given that we are packaging an alpha release, end-users and other
distributors might wonder how a stable release is made out of that and
how the packaged code differs from the original code.

Add some words describing each patch to README.Debian to help such
people, imitating the gcc packaging.  This information does not go in
the package description because it is more relevant when using the
package than when deciding whether to install it.  The package
description already mentions that threads are not supported.

Thanks to Andrew Pollock, Thorsten Glaser, and Lasse Collin for
advice.
---
 debian/changelog  |6 ++
 debian/xz-utils.README.Debian |   28 +---
 2 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 8936da7..a69f889 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+xz-utils (5.1.1alpha+20120614-1.1) unstable; urgency=low
+
+  * xz-utils/README.Debian: Document differences from upstream.
+
+ -- Jonathan Nieder jrnie...@gmail.com  Fri, 17 Aug 2012 19:57:24 -0700
+
 xz-utils (5.1.1alpha+20120614-1) unstable; urgency=low
 
   * New snapshot, taken from upstream commit f1675f76.
diff --git a/debian/xz-utils.README.Debian b/debian/xz-utils.README.Debian
index 819be5c..b79248a 100644
--- a/debian/xz-utils.README.Debian
+++ b/debian/xz-utils.README.Debian
@@ -3,8 +3,9 @@ XZ Utils for Debian
 
 Contents:
  1. History
- 2. LZMA Utils compatibility
- 3. Configuration
+ 2. Differences from standard XZ Utils
+ 3. LZMA Utils compatibility
+ 4. Configuration
 
 History
 ---
@@ -14,6 +15,27 @@ The old .lzma file format has some problems, worst of which 
is the lack
 of magic number, but it gets enough use to still need to be supported.
 See /usr/share/doc/xz-utils/history.txt.gz for the full story.
 
+Differences from standard XZ Utils
+--
+
+XZ Utils 5.1.y upstream has some experimental features which are
+disabled in Debian to allow the interfaces to evolve.  The Debian
+package also modifies liblzma to avoid breakage when a binary links
+indirectly to liblzma from Debian 6.0 (squeeze) and 7.0 (wheezy) at
+the same time.
+
+abi-threaded-encoder:
+  Disable threaded compression in liblzma and xz.
+
+abi-version-script:
+  liblzma: Do not pretend to satisfy dependencies on XZ_5.1.2alpha.
+
+abi-liblzma2-compat, configure-liblzma2-compat:
+  liblzma: Do not check reserved space past the historical end of
+  the lzma_stream structure if liblzma.so.2 is loaded in the same
+  process image.  Likewise when building statically.
+  (See bug #649522.)
+
 LZMA Utils compatibility
 
 
@@ -44,4 +66,4 @@ following to your environment (e.g., in ~/.profile):
 
 See the Memory usage section of the xz(1) manual page for details.
 
- -- Jonathan Nieder jrnie...@gmail.com  Fri, 18 May 2012 01:14:16 -0500
+ -- Jonathan Nieder jrnie...@gmail.com  Fri, 17 Aug 2012 23:37:47 -0700
-- 
1.7.9.6 (Apple Git-31.1)

Bug#685209: unblock: ball/1.4.1+20111206-4

On Sat, 2012-08-18 at 13:17 +0200, Steffen Möller wrote:
 On 08/18/2012 12:48 PM, Adam D. Barratt wrote:
  On Sat, 2012-08-18 at 12:05 +0200, Steffen Moeller wrote:
  The uploader is upstream who kindly added a patch to fix a FTBFS.
[...]
  While I'm happy to believe that a number of the patches are required to
  fix building with gcc-4.7, these at least don't look like they are:
  
   patches/0007-Fixed-the-FPT-version-of-bond-order-assignment.patch   |  
  447 
   patches/0008-Added-MAX_PENALTY-option-to-bond-order-assignment.patch|  
  975 ++
   patches/0009-Fixed-a-bug-in-the-AssignBondOrderProcessor.patch  |  
  271 ++
  
  Indeed some of those look like they may well introduce ABI changes if
  the changes are reflected in libball.

Some comment on this, possibly from upstream, would be helpful.  I
realise that nothing outside of ball uses the libraries, but they (I
missed libballview) are shipped as public soversioned libraries and
nothing in the package dependencies appears to ensure that the packages
are upgraded in step.

  This obviously isn't a gcc 4.7 fix:
  
   patches/0011-Fix-compilation-of-Python-bindings-with-new-sip-vers.patch |  
   25 
  
  It may well be needed for the package to build in unstable now, but it's
  certainly not covered by Fix compilation with g++ = 4.7.
 
 From the description of those bugs I tend to agree that indeed that is more
 than the FTBFS required. Upstream mostly works on version 2 of BALL now, so
 knowing whatever ships with Wheezy now to be worked with for a while, I 
 presume
 Andreas (upstream) to just have wanted some of the later experiences
 backported. A respective description in the changelog is missing.

At the very least, yes.

  Was simply forcing building with gcc 4.6 considered as an option?
 
 I did not know myself this was allowed for anything in stable. The bond-order
 changes were apparently important. With my Debian Med hat on, I am always
 eager to have such close ties with upstream so Debian gets the best that is
 possible, not only something that compiles.

In general, I'd agree.  The focus on changes during a freeze is somewhat
narrower, however.

 I understand that you see difficulties to accept the package for Wheezy
 as it is. Would it help you to have the debian/changelog updated with the
 maintainer change and a description about those changes to the bond order?

A description of those patches would certainly help.  As would an
explanation as to why they're so important that they either meet the
published freeze guidelines or merit an exception.

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#685218: unblock: xserver-xorg-video-nouveau/1:1.0.1-3

2012-08-18 Thread Sven Joachim

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

Please unblock xserver-xorg-video-nouveau, it fixes bug #675161 which
has made the version in testing unusable for the past three months.  The
version in unstable had been blocked from migrating by bug #679566 which
only got solved in testing today.

unblock xserver-xorg-video-nouveau/1:1.0.1-3


That was the good part, now to the bad and the ugly: upstream rewrote
the nouveau parts of libdrm and large parts of the driver between the
versions in testing and unstable, resulting in a *huge* diff:

,
|  ChangeLog  |  405 +
|  configure.ac   |4 +-
|  debian/NEWS.Debian |9 +
|  debian/changelog   |   47 ++
|  debian/patches/02-drm-nouveau-newabi.patch | 2285 

|  debian/patches/series  |1 +
|  debian/rules   |2 +-
|  debian/watch   |4 +
|  src/Makefile.am|   47 +-
|  src/compat-api.h   |   96 +++
|  src/drmmode_display.c  |   48 +-
|  src/nouveau_dri2.c |   59 +-
|  src/nouveau_exa.c  |  143 +++--
|  src/nouveau_local.h|  186 --
|  src/nouveau_wfb.c  |4 +-
|  src/nouveau_xv.c   |   90 ++-
|  src/nv04_accel.h   |   93 +++
|  src/nv04_exa.c |  525 -
|  src/nv04_xv_blit.c |  262 -
|  src/nv10_exa.c |  863 +--
|  src/nv30_exa.c |  979 
---
|  src/nv30_shaders.c |  347 ---
|  src/nv30_shaders.h |   72 ---
|  src/nv30_xv_tex.c  |  302 --
|  src/nv40_exa.c |  998 

|  src/nv40_xv_tex.c  |  293 --
|  src/nv50_accel.c   |  695 --
|  src/nv50_accel.h   |   69 ++-
|  src/nv50_exa.c |  954 
+++---
|  src/nv50_xv.c  |  381 +---
|  src/nv_accel_common.c  |  588 ++-
|  src/nv_const.h |2 +
|  src/nv_dma.c   |  119 +++-
|  src/nv_dma.h   |4 +-
|  src/nv_driver.c|  135 ++---
|  src/nv_include.h   |   13 +-
|  src/nv_proto.h |   17 +-
|  src/nv_shadow.c|3 +-
|  src/nv_type.h  |   66 ++-
|  src/nvc0_accel.c   |  876 
+++-
|  src/nvc0_accel.h   |  124 ++--
|  src/nvc0_exa.c | 1033 
+
|  src/nvc0_shader.h  |  444 ++
|  src/nvc0_xv.c  |  374 +---
|  src/nve0_shader.h  |  440 ++
|  src/vl_hwmc.c  |6 +-
|  46 files changed, 8833 insertions(+), 5674 deletions(-)
`

The patch 02-drm-nouveau-newabi.patch pulls in the new libdrm_nouveau
into the driver source, since upgrading the system libdrm is not
possible due to mesa and plymouth still needing the old API.  Definitely
nothing to be proud of, but it seems to work.

I very much wish this unblock request were not necessary; if somebody
comes up with a miraculous fix for #666468, it can be ignored, but I do
not expect this to happen anytime soon.

Cheers,
   Sven


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

Bug#685209: unblock: ball/1.4.1+20111206-4

2012-08-18 Thread Steffen Möller

Dear Adam,

On 08/18/2012 01:34 PM, Adam D. Barratt wrote:
 On Sat, 2012-08-18 at 13:17 +0200, Steffen Möller wrote:
 On 08/18/2012 12:48 PM, Adam D. Barratt wrote:
 On Sat, 2012-08-18 at 12:05 +0200, Steffen Moeller wrote:
 The uploader is upstream who kindly added a patch to fix a FTBFS.
 [...]
 While I'm happy to believe that a number of the patches are required to
 fix building with gcc-4.7, these at least don't look like they are:

  patches/0007-Fixed-the-FPT-version-of-bond-order-assignment.patch   |  
 447 
  patches/0008-Added-MAX_PENALTY-option-to-bond-order-assignment.patch|  
 975 ++
  patches/0009-Fixed-a-bug-in-the-AssignBondOrderProcessor.patch  |  
 271 ++

 Indeed some of those look like they may well introduce ABI changes if
 the changes are reflected in libball.
 
 Some comment on this, possibly from upstream, would be helpful.  I
 realise that nothing outside of ball uses the libraries, but they (I
 missed libballview) are shipped as public soversioned libraries and
 nothing in the package dependencies appears to ensure that the packages
 are upgraded in step.
 
 This obviously isn't a gcc 4.7 fix:

  patches/0011-Fix-compilation-of-Python-bindings-with-new-sip-vers.patch |  
  25 

 It may well be needed for the package to build in unstable now, but it's
 certainly not covered by Fix compilation with g++ = 4.7.

 From the description of those bugs I tend to agree that indeed that is more
 than the FTBFS required. Upstream mostly works on version 2 of BALL now, so
 knowing whatever ships with Wheezy now to be worked with for a while, I 
 presume
 Andreas (upstream) to just have wanted some of the later experiences
 backported. A respective description in the changelog is missing.
 
 At the very least, yes.
 
 Was simply forcing building with gcc 4.6 considered as an option?

 I did not know myself this was allowed for anything in stable. The bond-order
 changes were apparently important. With my Debian Med hat on, I am always
 eager to have such close ties with upstream so Debian gets the best that is
 possible, not only something that compiles.
 
 In general, I'd agree.  The focus on changes during a freeze is somewhat
 narrower, however.
 
 I understand that you see difficulties to accept the package for Wheezy
 as it is. Would it help you to have the debian/changelog updated with the
 maintainer change and a description about those changes to the bond order?
 
 A description of those patches would certainly help.  As would an
 explanation as to why they're so important that they either meet the
 published freeze guidelines or merit an exception.

If you were the ftpmasters then I would now have suggested to reject the
upload for Andreas to upload a corrected version. Actually I had already
formulated that sentence when I realised that the package already is in
unstable :o/

@Andreas: Since everything is already uploaded and went through the
buildds and was shipped to all the mirrors and your pending explanations
now are mostly for the release team to decide, please first formulate
an email to Adam outlining your reasoning on those non gcc
4.7-associated changes. Trusting you in your initial reasoning
I have some remaining hope for the package to be acceptable nonetheless,
at least we/you will learn if the bond-bits can remain in or if you rather
have the version currently in testing removed because of those bond issues
you now know about.

Many thanks to Adam for his constructive review and regards to all

Steffen


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

Bug#674448: CVE-2012-2098

2012-08-18 Thread Jonathan Wiltshire

Package: libcommons-compress-java

Dear maintainer,

Recently you fixed one or more security problems and as a result you closed
this bug. These problems were not serious enough for a Debian Security
Advisory, so they are now on my radar for fixing in the following suites
through point releases:

squeeze (6.0.6) - use target stable

Please prepare a minimal-changes upload targetting each of these suites,
and submit a debdiff to the Release Team [0] for consideration. They will
offer additional guidance or instruct you to upload your package.

I will happily assist you at any stage if the patch is straightforward and
you need help. Please keep me in CC at all times so I can
track [1] the progress of this request.

For details of this process and the rationale, please see the original
announcement [2] and my blog post [3].

0: debian-rele...@lists.debian.org
1: http://prsc.debian.net/tracker/674448/
2: 201101232332.11736.th...@debian.org
3: http://deb.li/prsc

Thanks,

with his security hat on:
--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


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

Bug#685215: Apt pinning is broken

Since I opened this new bug, I'd like to add my specific use case as well:

Naturally, I want my system stable. Perhaps some time into the release
cycle, I want my user apps updated for the sake of new features, so I pull
them from testing. Chromium and Iceweasel, perhaps with more stable
(supposedly) upstream development, I want on the bleeding edge.
Perhaps I want to stay on Gnome 2 before I move to Xfce for good.
Thus, I end with the following apt preferences:

-- /etc/apt/preferences --

Explanation: I want the base of my system stable.
Package: *
Pin: release a=stable
Pin-Priority: 503

Package: *
Pin: release a=testing
Pin-Priority: 502

Package: *
Pin: release a=unstable
Pin-Priority: 501

Explanation: In some apps, I prefer features over stability.
Package: gimp libreoffice pidgin vlc
Pin: release a=testing
Pin-Priority: 505

Explanation: Other apps may be stable by design. Or I don't really care. D:
Package: chromium iceweasel
Pin: release a=unstable
Pin-Priority: 505

Explanation: But under no condition ever install default gnome (3) package.
Package: gnome
Pin: version 3*
Pin-Priority: -1

-- end /etc/apt/preferences --

But hey!, you say, that gimp and pidgin pull a hell of a long dependency
chain from testing as well...

True. But my kernel, my init scripts, daemons, desktop, ... likely all
remain stable.

With above preferences, with all that software initially installed, running
apt-get upgrade, I should end with gimp, libreoffice, pidgin, and vlc from
testing, unstable chromium and iceweasel, and gnome3 (likely with some of
its apps) nowhere to be seen.

Except that that doesn't work because all those package pins have dependencies
in their respective releases and those dependencies aren't pinned highly
enough as well, so, unless packages were initially installed with -t switch,
apt determines upgrade request to be unsolvable.

(BTW, I'd like to report that the external dependency solver called 'apt'
seems to pay no regard to the APT::Solver::Strict-Pinning setting.)

But that's what external dependency solvers are for! Using the above apt
configuration line, I can tell my sophisticated solver (really just a greedy
one) to get dependencies top-down: What it can satisfy from stable, from
stable; what it can't satisfy from stable but can from testing, from testing,
and the remaining from unstable, all according to the specified release pins.

Behold, awe the Debian mixed system, the truly Universal OS that is itself a
multi-level rolling release.



Argument

What you're saying above can be easily achieved with pinning as implemented
now, and a careful use of apt-get command line, namely `-t` switch or
`pkgname/release` parameter.

Counter-argument

Say package A (from testing) depends on packages B, C, D, E, F, G. The
versions of these dependencies are such that versions of B, C, D, and E
could be satisfied from stable, but F and G need to be from testing as well.
All release pins as in above preferences.
Either:
$ sudo apt-get install A/testing
fails, because F and G are pinned to stable, but those two can't satisfy the
requirement of A. Or:
$ sudo apt-get -t testing install A
works, but it pulls all those packages from testing, possibly and
unnecessarily (!) making the system less stable.
Ergo, to satisfy above prefer stable, but adapt if needed requirement, an
external solver (with Strict-Pinning=false) is required to operate on a
working pinning implementation.
(The alternative is to install each dependency separately, which then really
turns the process into a PITA.)


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

Bug#683049: binNMU

2012-08-18 Thread Neil Williams

Just to help those scanning the RC bug lists, the binNMU request for
bobcat is #683244. The binNMU for c++-annotations would need to be
requested later.

I've done a simple test in a pbuilder chroot and the principle of the
request does fix these two RC bugs.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpoBtC7tlWnE.pgp
Description: PGP signature

Bug#685219: grub-pc: grub installation failed(core.img too large)

2012-08-18 Thread Tobias Unsleber

Package: grub-pc
Version: 1.99-22.1
Severity: normal
Tags: d-i

Dear Maintainer,

1. I did a standard install(amd64,btrfs) with a netboot installer on an usb 
stick.
At the installation point of grub, the installer reported an error installing 
grub.

2. I rebooted with a rescue system and installed grub manually using 
grub-install.
I got the error message:

/usr/sbin/grub-setup: warn: Your core.img is unusally large. It won't fit in 
the embedding area..

3. I checked the used module list for removing not needed modules, but the only 
used modules are:
biosdisk, btrfs, part_msdos

4. I tried to upgrade grub to debian unstable, but no new version is available 
there

5. The size of core img.is 38237 Bytes (I just replaced the btrfs.mod by 
ext2.mod in 
   /usr/lib/grub/i386-pc/, because ext2.mod its smaller, just to see if the 
size would 
   be small enough with the ext2.mod. The new size is 34383 Bytes and 
grub-install reports
   this as too big again as before.

6. Maybe it's still the issue reported in Bug #562953 ?

regards,
Tobias

-- Package-specific info:

*** WARNING grub-setup left core.img in filesystem

*** BEGIN /proc/mounts
/dev/sde /livemnt/boot vfat 
ro,relatime,fmask=0133,dmask=0022,codepage=cp437,iocharset=ascii,shortname=mixed,errors=remount-ro
 0 0
/dev/loop0 /livemnt/squashfs squashfs ro,relatime 0 0
/dev/sda3 / btrfs rw,relatime,space_cache 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/usb-Kingston_DataTraveler_II+_5B690B864327-0:0
(hd1)   /dev/disk/by-id/ata-SAMSUNG_HD250HJ_S0URJ9CPC62208
(hd2)   /dev/disk/by-id/ata-SAMSUNG_HD320KJ_S10MJ1KP402451
*** END /boot/grub/device.map

*** BEGIN /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] 
[raid10] 
unused devices: none
*** END /proc/mdstat

*** BEGIN /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root  9 Aug 18 13:09 ata-SAMSUNG_HD250HJ_S0URJ9CPC62208 - 
../../sda
lrwxrwxrwx 1 root root 10 Aug 18 13:09 ata-SAMSUNG_HD250HJ_S0URJ9CPC62208-part1 
- ../../sda1
lrwxrwxrwx 1 root root 10 Aug 18 13:09 ata-SAMSUNG_HD250HJ_S0URJ9CPC62208-part2 
- ../../sda2
lrwxrwxrwx 1 root root 10 Aug 18 13:09 ata-SAMSUNG_HD250HJ_S0URJ9CPC62208-part3 
- ../../sda3
lrwxrwxrwx 1 root root 10 Aug 18 13:09 ata-SAMSUNG_HD250HJ_S0URJ9CPC62208-part4 
- ../../sda4
lrwxrwxrwx 1 root root  9 Aug 18 13:09 ata-SAMSUNG_HD320KJ_S10MJ1KP402451 - 
../../sdb
lrwxrwxrwx 1 root root 10 Aug 18 13:09 ata-SAMSUNG_HD320KJ_S10MJ1KP402451-part1 
- ../../sdb1
lrwxrwxrwx 1 root root  9 Aug 18 13:09 scsi-SATA_SAMSUNG_HD250HJS0URJ9CPC62208 
- ../../sda
lrwxrwxrwx 1 root root 10 Aug 18 13:09 
scsi-SATA_SAMSUNG_HD250HJS0URJ9CPC62208-part1 - ../../sda1
lrwxrwxrwx 1 root root 10 Aug 18 13:09 
scsi-SATA_SAMSUNG_HD250HJS0URJ9CPC62208-part2 - ../../sda2
lrwxrwxrwx 1 root root 10 Aug 18 13:09 
scsi-SATA_SAMSUNG_HD250HJS0URJ9CPC62208-part3 - ../../sda3
lrwxrwxrwx 1 root root 10 Aug 18 13:09 
scsi-SATA_SAMSUNG_HD250HJS0URJ9CPC62208-part4 - ../../sda4
lrwxrwxrwx 1 root root  9 Aug 18 13:09 scsi-SATA_SAMSUNG_HD320KJS10MJ1KP402451 
- ../../sdb
lrwxrwxrwx 1 root root 10 Aug 18 13:09 
scsi-SATA_SAMSUNG_HD320KJS10MJ1KP402451-part1 - ../../sdb1
lrwxrwxrwx 1 root root  9 Aug 18 13:09 usb-0416_USB_MS_SD_Card_Readdr. - 
../../sdc
lrwxrwxrwx 1 root root  9 Aug 18 13:09 
usb-SanDisk_U3_Cruzer_Micro_051017035233-0:0 - ../../sde
lrwxrwxrwx 1 root root  9 Aug 18 13:09 wwn-0x5f001b402451 - ../../sdb
lrwxrwxrwx 1 root root 10 Aug 18 13:09 wwn-0x5f001b402451-part1 - 
../../sdb1
lrwxrwxrwx 1 root root  9 Aug 18 13:09 wwn-0x5f009bc62208 - ../../sda
lrwxrwxrwx 1 root root 10 Aug 18 13:09 wwn-0x5f009bc62208-part1 - 
../../sda1
lrwxrwxrwx 1 root root 10 Aug 18 13:09 wwn-0x5f009bc62208-part2 - 
../../sda2
lrwxrwxrwx 1 root root 10 Aug 18 13:09 wwn-0x5f009bc62208-part3 - 
../../sda3
lrwxrwxrwx 1 root root 10 Aug 18 13:09 wwn-0x5f009bc62208-part4 - 
../../sda4
*** END /dev/disk/by-id

*** BEGIN /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 Aug 18 13:09 1CDC58E0DC58B5AC - ../../sda1
lrwxrwxrwx 1 root root  9 Aug 18 13:09 3493-83FC - ../../sde
lrwxrwxrwx 1 root root 10 Aug 18 13:09 37847b13-cd21-4681-a438-bde898d8e04a - 
../../sda3
lrwxrwxrwx 1 root root 10 Aug 18 13:09 3eed3732-7738-403a-a2d3-eecac1b41296 - 
../../sdb1
lrwxrwxrwx 1 root root 10 Aug 18 13:09 d795a777-153a-420d-b16a-3fe3f873b4cc - 
../../sda4
*** END /dev/disk/by-uuid

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

Kernel: Linux 3.2.23-std281-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default

Bug#685220: xz-utils: fixes from 5.1.2alpha

Source: xz-utils
Version: 5.1.1alpha+20120614-1
Severity: normal
Tags: upstream patch fixed-upstream

Please consider the following fixes from 5.1.2alpha (aka patches
man-date, man-xz-lvv-minver, xz-lvv-empty-block-minver,
decoder-check-first-0x00 from debian/patches in commit c3301d0d of the
packaging repo):

  The documentation xz --robot -lvv format leaves out the minimum
  version required to decompress field.

  xz -lvv reports that version 5.0.3 of liblzma is the minimum
  version of xz that can decompress files with blocks with zero
  uncompressed_size, but 5.0.2 works.

  liblzma tolerates malformed range encoded data with 0x00 as first
  byte instead of erroring out.

The first is just a documentation bugfix, but it's low-risk.  The
second and third make Debian xz match upstream more closely without
introducing new interfaces.  Other patches from 5.1.2alpha
(example-usage, xz-block-list, build-doc-symvers,
configure-clarify-symvers, doc-threads-and-fork, version-5.1.2,
news-5.1.2) are not urgent so let's stick to these three for now.

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#685206: libwrap0:amd64: hosts_{options,access}.5.gz inconsistencies on format

2012-08-18 Thread Marco d'Itri

On Aug 18, Edward Welbourne e...@chaos.org.uk wrote:

The current documentation has worked well enough for the past 15-20 
years or so, but if you really believe that younger sysadmins may be as 
confused as you are then please send me a patch for hosts_access(5) 
which removes references to the old syntax.

 Further, given that the two syntaxes are incompatible, everything I can
 see tells me that reading of /etc/hosts.{allow,deny} is up to each
 application independently, so I have no way (as administrator of my box)
 to know how I can avoid problems with my setup if some applications
 choose to support the hosts_access format instead of the hosts_options
You are seriously misunderstanding how libwrap works: it is a library, 
and it parses the hosts files by itself.
So maybe you will just want to close this bug instead.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#685215: Apt pinning is broken

Namely, what I, as a user, would like only is that pinning per package
(wildcarded) name or version works, and that those more specific pins are
propagated to EDSP/CUDF dumps, i.e. in the EDSP dump, the APT-Pin field for
package=chromium,version=whatever-is-available-in-unstable stanza says
505 (as per above /etc/apt/preferences) instead of 501 as it does now.

If I got it wrong, and the current implementation is indeed correct, I'd
very much care for having the broad ideas behind it explained to me.
(Though I doubt it as maintainers have before admitted to behavior being
kind of fuzzy.)


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

Bug#685221: unblock: xen/4.1.3-1

2012-08-18 Thread Bastian Blank

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

Please unblock xen/4.1.3-1. It updates the package to the release. By
doing this it fixes two security bugs, error handling in exceptional
conditions, missing access control and adds hardware support.

It also includes a build fix (removal of asmlinkage, which is a larger
fraction of the overall patch) for gcc 4.7 that was already fixed for
Debian in a different way.

xen (4.1.3-1) unstable; urgency=medium

  * New upstream release: (closes: #683286)
- Don't leave the x86 emulation in a bad state. (closes: #683279)
  CVE-2012-3432
- Only check for shared pages while any exist on teardown.
  CVE-2012-3433
- Fix error handling for unexpected conditions.
- Update CPUID masking to latest Intel spec.
- Allow large ACPI ids.
- Fix IOMMU support for PCI-to-PCIe bridges.
- Disallow access to some sensitive IO-ports.
- Fix wrong address in IOTLB.
- Fix deadlock on CPUs without working cpufreq driver.
- Use uncached disk access in qemu.
- Fix buffer size on emulated e1000 device in qemu.
  * Fixup broken and remove applied patches.

 -- Bastian Blank wa...@debian.org  Fri, 17 Aug 2012 11:25:02 +0200

diff -x .pc -urN xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/.hg_archival.txt 
xen-4.1.3/.hg_archival.txt
--- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/.hg_archival.txt 2012-06-14 
10:39:57.0 +
+++ xen-4.1.3/.hg_archival.txt  2012-08-09 20:08:04.0 +
@@ -1,5 +1,4 @@
 repo: ab039beb22dc9d53f224a5ef2ef88d534b561898
-node: a9c0a89c08f2a1c92f64f001b653d7c02fbc852c
+node: ce7195d2b80e4df9857e434fa29689fd678a2341
 branch: default
-latesttag: 4.1.3-rc1
-latesttagdistance: 13
+tag: RELEASE-4.1.3
diff -x .pc -urN xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/.hgsigs 
xen-4.1.3/.hgsigs
--- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/.hgsigs  2012-06-14 
10:39:57.0 +
+++ xen-4.1.3/.hgsigs   2012-08-09 20:08:04.0 +
@@ -16,3 +16,5 @@
 24041ed83728ac6c26d3c32d29d7d08eb8433149 0 
iQEcBAABAgAGBQJOjxDqAAoJEIP+FMlX6CvZohIH/2krgh6rTz6hjsv6HOFWQkekqHjZyyQBgdl3tfgSN/vSd3rJPN6mvaYjh8ZltmBbcHcRCmriTr7KK9e6kOChU7hyTCBDmtGxNN5TgMoAf27pSMrFN1HvK0ohQzGXvqKLAepTXW2ew+Abno3OgKRwUMpQJVlq+ZUCuqKODYI9nRE10XV6ORAejgE5mDYNn3BbvcI07Cjmqgm7bJzi5Hv0wzscPuJxQjz4vrJ+5ne65TYOzFPNkIFKeRETP+Shd9Gkw2/w9sbzQ2hzTH/02sUrsxolXD2wexfxgVz07rTe7qgbqKruCBOPtbcnGMAbs3e5NB7V6H3HnkTRtHQ4BosUMnE=
 3eca5bf65e6cca881d599c68f2305f865e0f9fd0 0 
iQEcBAABAgAGBQJOoE3xAAoJEIP+FMlX6CvZ0P4IALamOXJi4s9OzfutsjD//V5QYU972Y+NxBo2j7VNKnRaFwZ57RbxLE8dzsAufvxx/886ScyvdehAfWkpqhU+brLfKNftG54Bm3DFd+mDCdcTvHOGkKw768YUPBNjOhQZ8voVSnalrQaOlbibluRTYGK1Y4lcWXwP8SSCCR7bpm8VLrSKQoatiaPtc/OxBO+9UOlHFUR2tWt5YY4a5NczaXJ2xGERMnOssE83GjxSD/07+y9aDLNjnQiYqQfSkF46Gv4s94hPv8KeHEiGDMoZF/YqHr+4YxDCt8y39TXiQfT67O3o9xx6VfynTIHRo9CZ0qGrEqz7o8GK1vWhlfq3T5M=
 da64f68730cf1c42c06919578e70d8bc01041051 0 
iQEcBAABAgAGBQJPp8OUAAoJEIP+FMlX6CvZRkEIAKp5iVEADZyijVw0Jwj1vUWKqHJYVONzNjzRcnavWAEzsuwbAxQ6QfMJIai2ThjF79M2w7fPXY03S/vCV4/bXVE9R9s2/IUmS9B6pK+DAhw3ExuNUfsxq9UZd3Iul6hWifjjouYnBmgUtpF7O5z4pfQ+r1+z58FpIYPrv39NARt5YW7tcPeUJh4gOJ0ugORc5CclZqLLiljjIbVY6DN+jJDzjqCAwbWLGbkVw4kEGAeWI6aP3/5ZDpnk9Yytp9GpZ8d3BpmlHaR/kY6xepmZUqBPFGKUGY437+1jKWGgUYPLt2RC0S88W4iLRW6b9HXd7u3bhrn36ERz8XZ10KqjH7A=
+acbd3617691397911f34e4574d03385c08aec900 0 
iQEcBAABAgAGBQJP3zbaAAoJEIP+FMlX6CvZoMUH/1TQcdw+e/7BmxtXBnMIrpiTJ7/tffSBYurcoQFq1cTaJJgz5in8iq1JWHgru/ToYQ9PaWY0wVQcb1Yj40rCGNnASlSzQqgRQbYMmZpKd0+TESDtMkl6q1FXECrs8ag/HMHwkVYsgdAEmQ/7IouRK4kBOXXzSWhMRU24YkHdJAnQCcXD9L99Yjmrr5oxF/fgVG7WnhfTGlhpu7FaUeWlDjBRlIuw6HeNnXMwubAn569dGXyPdwJnbU0nCLRrQGjQn7DsmeN25gL4R5Pz+uhp4eeGB7ORYT/mj5+xeS2Cjb3XfptV3qAW2FJVYRLit7lp5cmsKvtBnr8mAO8GS0R+8Pg=
+5cdcfed7b5b129843e1602b5d43c7651de337092 0 
iQEcBAABAgAGBQJQDB6TAAoJEIP+FMlX6CvZ+H8IAJbWR4PrKOt3gMpgEYdADts96vtduD3oet5C+l8FSlo0pDPtF32wPQ5tQz+Ll8OtCFckSIzobsw+9IMrZ38nRwP1UM2LgLUuo6WVVwYZ4DKVIntDrC1DV6Us1CmGiHiTHqPNDypBB2NponJ21rlD8zRY4Q661BgdKXVwqq5H6SDtxNRSn7RPDYnsIvavabr0fvcR38YOHVG4TvfXP+uge0UfEvIurGEBnTn25E0vadLG9la9SGKeEm8HuTDnzuxQmSic7tPdodQ0oQYQ5AAj+/mdW2B9uaCDsmOeP4udDNcV4yXxdLxNA2GkeSSJ/+U0hj2HBaHZvd+hvAeHBZGdMAU=
diff -x .pc -urN xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/.hgtags 
xen-4.1.3/.hgtags
--- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/.hgtags  2012-06-14 
10:39:57.0 +
+++ xen-4.1.3/.hgtags   2012-08-09 20:08:04.0 +
@@ -63,3 +63,5 @@
 24041ed83728ac6c26d3c32d29d7d08eb8433149 4.1.2-rc3
 3eca5bf65e6cca881d599c68f2305f865e0f9fd0 RELEASE-4.1.2
 da64f68730cf1c42c06919578e70d8bc01041051 4.1.3-rc1
+acbd3617691397911f34e4574d03385c08aec900 4.1.3-rc2
+5cdcfed7b5b129843e1602b5d43c7651de337092 4.1.3-rc3
diff -x .pc -urN xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/Config.mk 
xen-4.1.3/Config.mk
--- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/Config.mk2012-08-18 
11:44:33.0 +
+++ xen-4.1.3/Config.mk 2012-08-18 11:44:27.0 +
@@ -179,7 +179,7 @@
 # CONFIG_QEMU ?=

Bug#685222: system installed with LVM XFS fails to reboot, unix module is missing

2012-08-18 Thread Damjan Zemljič

Package: installation-reports

Boot method: installation from CD
Image version: debian-wheezy-DI-b1-amd64-CD-1.iso
Date: 17.8.2012 2pm

Machine:IBM Thinkpad W510, but installed in VirtualBox (4.1.18) as a guest,
default settings
Processor: only one core assigned
Memory: 4 GB assigned
Partitions: default LVM scheme with partitions and encryption proposed in
the graphic installer. However, all filesystems except swap (of course)
were changed to XFS.

Output of lspci -knn (or lspci -nn):

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E ]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:
During the installation of the Debian Beta 1 as a VirtualBox guest (18GB
disk allocated for it), default settings are accepted, except:
- locale US, keyboard Slovenian (SI),
- LVM with proposed partitions and encryption is chosen, but all filesystem
types changed to XFS

After installation is finished and reboot is proposed, reboot fails.
Screenshot is attached.

Another thing I've spotted is the size of a swap proposed - less than 1GB
(having 4GB of RAM). Shouldn't that be at least 4GB (how is hibernation
done)?

Br,
Damjan
attachment: Screenshot at 2012-08-18 14:03:40.png

Bug#670017: libpam-modules: arch-dependent files in multiarch: same package

2012-08-18 Thread Julien Cristau

On Mon, Aug 13, 2012 at 13:20:05 +0200, Ralf Jung wrote:

 fixed 670017 libpam-modules/1.1.3-7.1
 thanks
 
 This is fixed by 1.1.3-7.1: Gettext was in the mean time patched to fix this 
 problem.
 
This bug had nothing to do with gettext afaik.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#685215: Apt pinning is broken

I'd like to propose a new policy view.
This is the current output of apt-cache policy (modified from [22]):

-- apt-cache policy package-name --

package-name:
  Installed: installed-version
  Candidate: version-installed-when-doing-apt-get-upgrade
  Package-Pin: version-of-Pin-in-etc-apt-preferences
  Version table:
 *** version-available-in-repos-12 more-specific-priority
   priority-of-source-1  repository-1
   priority-of-source-2  repository-2
 other-version-available-in-repos-34 more-specific-priority
   priority-of-source-3  repository-3
   priority-of-source-4  repository-4

-- end apt-cache policy package-name --

The breakdown of the three dubious fields is this:

version-of-Pin-in-etc-apt-preferences
  This field marks the version that corresponds to the first-matched more
  specific rule (e.g. with Package: package-name and/or Pin: version
  3*). This version has the priority more-specific-priority.
  IMHO, this field is completely redundant.

more-specific-priority
  This field is the Pin-Priority that corresponds with the first-matched
  more specific form (Package: package-name and/or Pin: version 3*).
  This field too, IMHO, is a design flaw, is redundant and should be removed.

priority-of-source-X
  This field corresponds to the Pin-Priority of the whole
  release/archive/origin set with wildcard Package: * (called a general
  form in the manual).

I kindly challenge your views on two IMHOs above.

I propose a a new apt-cache policy output:

-- new apt-cache policy package-name --

package-name:
  Installed: installed-version
  Candidate: version-installed-when-doing-apt-get-upgrade
  [Package-Pin: general|specific]
  Version table:
 *** version-available-in-repos-12
   priority-of-source-1  repository-1
   priority-of-source-2  repository-2
 other-version-available-in-repos-34
   priority-of-source-3  repository-3
   priority-of-source-4  repository-4

-- end new apt-cache policy package-name --

Package-Pin property is marked optional, and it only tells whether the
package is being pinned at all and whether the pin is only a general form
(release-wide) pin, or a more specific pin for that package/version is in
effect.

The breakdown of the dubious field here is:

priority-of-source-X
  The cumulative all-things-considered priority of package package-name
  (set with specific form pin stanza), version
  version-available-in-repos-Y (set with specific form pin stanza) from
  repository-Z (set with general form pin stanza or APT::Default-Release).

Thus, a single priority is set for each triplet package, version, source
(which is supposed to be but absolutely not the case currently, and
is instead more like what cupt does). Among the highest
priority-of-source-X the one with the highest
version-available-in-repos-Y wins and becomes the Candidate.

As presented in the follow-up algorithm pseudo code, this is easily achieved
if the policy regarding rules being first-match is reversed and
instead the last general rule wins and is overwritten by the last relevant
specific rule (if such exists).

Everything else regarding priorities and policy remains as currently
documented.


Backward-compatibility notice  Disclaimer
--
AFAIK, current implementation didn't allow for complicated apt_preferences
setups that could have break under this new policy.
I don't know how else these priorities are used internally throughout the apt
suite, and who else relies on apt-cache policy output being exactly as is.


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

Bug#684930: [Pkg-octave-devel] Bug#684930: unblock (pre-approval): octave/3.6.2-5

2012-08-18 Thread Sébastien Villemot

Rafael Laboissiere raf...@laboissiere.net writes:

 [Cc:ing to the DOG mailing list.]

 * Adam D. Barratt a...@adam-barratt.org.uk [2012-08-16 22:13]:

 Control: tags -1 + moreinfo
 
 [snip]

 +--- a/src/mkoctfile.in
  b/src/mkoctfile.in
 +@@ -77,7 +77,7 @@
 [...]
 +-: ${XTRA_CXXFLAGS=%OCTAVE_CONF_XTRA_CXXFLAGS%}
 ++: ${XTRA_CXXFLAGS=-I/usr/include/mpi %OCTAVE_CONF_XTRA_CXXFLAGS%}
 
 Does this have any side-effects in the case where the MPI variant wasn't
 installed?

AFAIK, it does not. mkoctfile being essentially a wrapper around gcc,
this change results in an additional -I flag on GCC command line. When
/usr/include/mpi does not exists, this has no effect. If
/usr/include/mpi exists but libhdf5-{openmpi,mpich2}-dev is not
installed, it should not have any effect either, because Octave files
don't include MPI headers.

Also note that a similar changeset was accepted by the RT during the
development cycle of Squeeze, and it had no bad consequence:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598227#29

As explained in that message, our initial intention was to support only
the serial version of HDF5 for Wheezy, but we finally changed our mind
because of user complaints and impossibility of packaging some Octave
add-ons.

Thanks for your review,

-- 
 .''`.Sébastien Villemot
: :' :Debian Maintainer
`. `' http://www.dynare.org/sebastien
  `-  GPG Key: 4096R/381A7594


pgp6kQUX3PK0Z.pgp
Description: PGP signature

Bug#678409: xpra: mouse position out of sync

2012-08-18 Thread أحمد المحمودي

Hello,

On Thu, Jun 21, 2012 at 04:27:48PM +0200, Hramrach wrote:
 I tried running firefox in xpra, and I could not click most UI elements.
 
 Examining closely I found that the mouse pointer is way more to the right
 (like 50~100px) than what xpra thinks.
 
 Minimizing the firefox window and restoring seems to fix the issue.
---end quoted text---

  According to http://xpra.org/trac/ticket/158, upstream might have been 
  able to fix your issue, could you try to see if xpra 0.3.6 fixes your 
  problem ? The upstream tarball can be found at: 
  http://winswitch.org/src/xpra-0.3.6.tar.bz2

-- 
 ‎أحمد المحمودي (Ahmed El-Mahmoudy)
  Digital design engineer
 GPG KeyID: 0xEDDDA1B7
 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: Digital signature

Bug#685215: Apt pinning is broken

I'd like to propose an algorithm that, if I'm not mistaken, results in above
policy.

Presuppositions
---
A general form rule or stanza is one that has Package: * AND Pin:
anything-except version.

A specific form rule or stanza is one that has Package: package-list OR
Pin: version where package-list is a space-separated list of glob() or
regular expressions.

Above is in accordance with current documentation.

Algorithm
-
Input = list of actionable packages, e.g. the space-separated list of
packages passed to apt-get install/remove/... along with all dependencies

Preferences = parse all Dir::Etc::preferences and Dir::Etc::preferencesparts,
sorting all general forms before all specific forms. Preferences must also
contain rules for APT::Default-Release or matching command-line switch.

for package in Input:
  for rule in Preferences.general_form_rules:
if contains(rule.source, package):
  set_priority(package,
package_version_in(package, rule.source),
rule.source, rule.priority)

  # more specific rules may overwrite general ones
  for rule in Preferences.specific_form_rules:
if (rule.is_version_pin 
versions_match(package, rule.version)):
  if matches(package, rule.name):
for source in get_sources_for(package,
  versions_match(package,
 rule.version)):
  set_priority(package,
versions_match(package, rule.version),
source, rule.priority)
else:  # not rule.is_version_pin
  if matches(package, rule.name):
set_priority(package,
  package_version_in(package, rule.source),
  rule.source, rule.priority)

  package.candidate = max_version(max_priority(package))


  # the rest is as currently implemented...
  if (package.candidate.version  package.installed_version 
  package.candidate.priority  1000):
error 'need priority over 1000 to downgrade'
  ...


I'd like to comment briefly on some of the above functions:
package_version_in(pkg, src) --- returns the version of pkg in src
versions_match(pkg, ver) --- returns pkg versions that matches ver glob if any
get_sources_for(pkg, ver) --- returns sources that contain pkg with version
in ver
matches(pkg, name) --- name can be a list of glob-like expressions

This is my take on what the algorithm roughly could look like. I agree it
looks kind of scripty, and I don't know exactly how easily this translates to
C++. Further, I'm not sure the algorithm works with all apt actions besides
simple install or upgrade. But I promise to implement an external solver
working as proposed in comment #2 if someone fixes the policy so that
EDSP/CUDF dump contains appropriate package pins.

I believe that with above-like algorithm, and some further documentation
effort, the bugs listed in OP can be finally marked as fixed, apt leading
Debian, as it always has, to an even brighter future.

But I fully admit to having little knowledge about apt inner working, Debian
packaging, Debian packaging policy, Debian release cycle, etc., I just want
to help the issue get resolved. :-)

Please contribute your views, questions, concerns, ideas...
And my $50 offer remains wide open. Please feel free to chip in.


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

Bug#624525: -T parameter

2012-08-18 Thread Marco van de Voort

FPC doesn't pass -T on purpose, since that would mean certain distro 
specific directories might not be found (IIRC specially /lib vs /lib64 
on biarchs):


http://www.freepascal.org/faq.var#unix-ld219

If sb has a gold testing situation, it might be also worthwhile to test 
both simple programs and programs that link to libc or libc using 
libraries. There are two different ELF startup
code files for that (crt0 replacements), and a difference between those 
two scenario's might be an hint.



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

Bug#616515: gnucash: uses excessive memory after saving

2012-08-18 Thread Sébastien Villemot

Jayen Ashar j...@yahoo.com writes:

 Unfortunately not without giving you my entire financial data.

 However, it seems to be happenning with gzipped XML and not sqlite3. 
 (sqlite3 did increase the memory usage by 20MB, but just the first
 save, and not every save.)

 FWIW, my file is 22MB unzipped XML or 12MB sqlite3.

I suggest that you try the following:

- install the valgrind and gnucash-dbg packages

- run gnucash with the following command:

valgrind --leak-check=full --log-file=/tmp/valgrind-gnucash.log gnucash

  Note that gnucash will be *very slow* and take a long time to start.
  This is to be expected when running a program through valgrind.

- perform several saves so that the memory usage increases abnormally

- send us back the contents of /tmp/valgrind-gnucash.log

If we are lucky, this could help upstream debug what seems to be a
memory leak.

Thanks,

-- 
 .''`.Sébastien Villemot
: :' :Debian Maintainer
`. `' http://www.dynare.org/sebastien
  `-  GPG Key: 4096R/381A7594


pgpPKHtv3cPO8.pgp
Description: PGP signature

Bug#685209: unblock: ball/1.4.1+20111206-4

2012-08-18 Thread Hildebrandt, Prof. Dr. Andreas

Hi everyone,

First of all, thank you for your comments! I'll try to clarify some
things, but I am not sure yet if I understood everything correctly.

First, about the change of the maintainer email. I was absolutely
convinced that I'd put that in the changelog, but as I just noticed, I've
forgotten to do that in the hurry of the last few days.

Then, about the patches. Concerning the bond order stuff (patches 0007,
0008, and 0009), this was a difficult decision. In upstream, we first had
a rewrite of the bond order code and then fixed the gcc problems. It would
be relatively simple to write a small patch based on the old version of
the code that gets it to *compile* with gcc 4.7. However, the new compiler
exposed some memory issues in the code that made the code *crash* when
running a gcc 4.7 - compiled version. So I've tried to isolate, from the
rewrite in upstream, those parts that fixed the problem. The rewrite in
upstream was unfortunately not really granular, so getting this stuff
untangled turned out to be a bit of a nightmare. Sorry, I should have
mentioned that in the changelog, but the last days were a little hectic.

Now, when I got the package to compile on testing with gcc 4.7, I noticed
that a change in sip also broke the build. So I've added a quick patch to
change that (0011), but probably also forgot to mention that in the
changelog. Sorry about that!

Best regards,

Andreas

Am 18.08.12 13:52 schrieb Steffen Möller unter steffen_moel...@gmx.de:

Dear Adam,

On 08/18/2012 01:34 PM, Adam D. Barratt wrote:
 On Sat, 2012-08-18 at 13:17 +0200, Steffen Möller wrote:
 On 08/18/2012 12:48 PM, Adam D. Barratt wrote:
 On Sat, 2012-08-18 at 12:05 +0200, Steffen Moeller wrote:
 The uploader is upstream who kindly added a patch to fix a FTBFS.
 [...]
 While I'm happy to believe that a number of the patches are required
to
 fix building with gcc-4.7, these at least don't look like they are:

  patches/0007-Fixed-the-FPT-version-of-bond-order-assignment.patch
   |  447 
  patches/0008-Added-MAX_PENALTY-option-to-bond-order-assignment.patch
   |  975 ++
  patches/0009-Fixed-a-bug-in-the-AssignBondOrderProcessor.patch
   |  271 ++

 Indeed some of those look like they may well introduce ABI changes if
 the changes are reflected in libball.
 
 Some comment on this, possibly from upstream, would be helpful.  I
 realise that nothing outside of ball uses the libraries, but they (I
 missed libballview) are shipped as public soversioned libraries and
 nothing in the package dependencies appears to ensure that the packages
 are upgraded in step.
 
 This obviously isn't a gcc 4.7 fix:

  
patches/0011-Fix-compilation-of-Python-bindings-with-new-sip-vers.patch
 |   25 

 It may well be needed for the package to build in unstable now, but
it's
 certainly not covered by Fix compilation with g++ = 4.7.

 From the description of those bugs I tend to agree that indeed that
is more
 than the FTBFS required. Upstream mostly works on version 2 of BALL
now, so
 knowing whatever ships with Wheezy now to be worked with for a while,
I presume
 Andreas (upstream) to just have wanted some of the later experiences
 backported. A respective description in the changelog is missing.
 
 At the very least, yes.
 
 Was simply forcing building with gcc 4.6 considered as an option?

 I did not know myself this was allowed for anything in stable. The
bond-order
 changes were apparently important. With my Debian Med hat on, I am
always
 eager to have such close ties with upstream so Debian gets the best
that is
 possible, not only something that compiles.
 
 In general, I'd agree.  The focus on changes during a freeze is somewhat
 narrower, however.
 
 I understand that you see difficulties to accept the package for Wheezy
 as it is. Would it help you to have the debian/changelog updated with
the
 maintainer change and a description about those changes to the bond
order?
 
 A description of those patches would certainly help.  As would an
 explanation as to why they're so important that they either meet the
 published freeze guidelines or merit an exception.

If you were the ftpmasters then I would now have suggested to reject the
upload for Andreas to upload a corrected version. Actually I had already
formulated that sentence when I realised that the package already is in
unstable :o/

@Andreas: Since everything is already uploaded and went through the
buildds and was shipped to all the mirrors and your pending explanations
now are mostly for the release team to decide, please first formulate
an email to Adam outlining your reasoning on those non gcc
4.7-associated changes. Trusting you in your initial reasoning
I have some remaining hope for the package to be acceptable nonetheless,
at least we/you will learn if the bond-bits can remain in or if you rather
have the version currently in testing removed because of those bond issues
you now know about.

Many thanks to Adam for his constructive review and regards to all

Bug#685223: does not properly expand with tar long options

2012-08-18 Thread Marc Haber

Package: bash-completion
Version: 1:2.0-1
Severity: normal

tar --extract --file tarfiTAB does not work even if a tarfile.tar is
present in the current directory. On the other hand, tar xf tarfiTAB
works. Looks like long option processing was omitted when the
completion rules for tar were written.

Greetings
Marc

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

Kernel: Linux 3.5.1-zgws1 (SMP w/6 CPU cores; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages bash-completion depends on:
ii  bash  4.2-5
ii  dpkg  1.16.8

bash-completion recommends no packages.

bash-completion 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#685224: can't configure for hidden SSID wlan

2012-08-18 Thread Daniel Pocock

Package: network-manager-gnome
Version: 0.9.4.1-1+b1
Severity: important

I've just done a fresh install of wheezy using the beta1 DVD for amd64

It has the gnome desktop

When I click the network icon at the top right hand corner of the
screen, I can see the list of wifi networks

However, there is no longer an option to configure a hidden wifi network
manually.  Such an option existed in squeeze.

If I right click the icon at the top right corner, it displays the same
menu that I get form a left click.  This is different from the behavior
under squeeze, which gives different menus for left and right click.

If I click the `Network Settings' option, it puts me in the settings
window.  the `Options...' button is gray, and I can't find any way to
add a hidden wireless network.

(also, I understand hidden SSID is not a significant security mechanism,
but this is not an unusual configuration and many of them exist)


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

Bug#685225: RFA: xmotd

2012-08-18 Thread Marcin Owsiany

Package: wnpp
Severity: normal

I'm no longer interested in maintaining this package.


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

Bug#670017: libpam-modules: arch-dependent files in multiarch: same package

2012-08-18 Thread Ralf Jung

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

 This is fixed by 1.1.3-7.1: Gettext was in the mean time patched
 to fix this problem.
 
 This bug had nothing to do with gettext afaik.
Oops, indeed, it was another generator, sorry - but in any case, the
bug seems to be fixed.

Kind regards,
Ralf

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQL5DjAAoJEEAdTZ0mjB1WjwgIAKK/+acopIxVfMbayjW14zrZ
m9D2YxzSNMnRoeR8y5ERjRlZo2KgpSfGzNAtFscHWXDa0omHxYl+qqWLnfdxlD0U
quoZeAJUNhACjQGQHiKzVAuwq7o14Be8KSlUvKFo6VraY0JuGqG2vWDba8Vq9dfe
9dClKb+VwUX+/ugOx0H9i5mz/ebNpL9ST5xAahcMAXYJzYYleuZHccQcRMecNWXH
4fFUK8JctmcRah/ULWUe34qXGY1lddG9j81OvUvBiYyFKBaRWy8fLb1hoqCwGtGX
Vg2t9jbg7tOIRNitrEKB+GGp1xyY7lQdYJhC3M6kijaISbFDjV/QvuS6TEKxmh0=
=pRx9
-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#678409: xpra: mouse position out of sync

2012-08-18 Thread Antoine Martin


On 08/18/2012 06:56 PM, أحمد المحمودي wrote:

Hello,

On Thu, Jun 21, 2012 at 04:27:48PM +0200, Hramrach wrote:

I tried running firefox in xpra, and I could not click most UI elements.

Examining closely I found that the mouse pointer is way more to the right
(like 50~100px) than what xpra thinks.

Minimizing the firefox window and restoring seems to fix the issue.

---end quoted text---

   According to http://xpra.org/trac/ticket/158, upstream might have been
   able to fix your issue, could you try to see if xpra 0.3.6 fixes your
   problem ? The upstream tarball can be found at:
   http://winswitch.org/src/xpra-0.3.6.tar.bz2


FYI, You can find the source tarballs here (xpra only - nothing else):
https://www.xpra.org/src/

I don't think this bug is fixed either in 0.3.x, 0.4.x or even trunk. 
But please do give it a try to confirm.


Since I am not able to reproduce it and the questions have not been 
answered, I will probably have to close this bug as 'needinfo'.


Cheers
Antoine


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

Bug#680465: reportbug: crash if tilde (~) is used in output file path -- data lost!

2012-08-18 Thread Sandro Tosi

Hello Fritz,
(I really hope that the email I'm writing will be read, given the
unhappy spamexpire-201207 part in the email address.. please
consider Debian BTS is highly based on emails exchange, so if you
jeopardize this channel, it's unlikely your bugs get
addressed/resolved).

On Fri, Jul 6, 2012 at 5:44 AM, Fritz Wuehler
fr...@spamexpire-201207.rodent.frell.theremailer.net wrote:
 When invoking bugreport --output=~/myreport.txt, everything is normal
 long enough for the user to spend time writing a report, then in the
 end it crashes, losing all data that was composed.  This is serious.
 Someone takes the time to fill out a report, and all their work is
 lost.

 At the end, the faulty output looks like this:

   Report will be saved as ~/myreport.txt
   Submit this report on libgdata7 (e to edit) [Y|n|a|c|e|i|l|m|p|q|d|t|s|?]?
   Traceback (most recent call last):
 File /usr/bin/reportbug, line 2098, in module
   main()
 File /usr/bin/reportbug, line 1045, in main
   return iface.user_interface()
 File /usr/bin/reportbug, line 2090, in user_interface
   self.options.draftpath)
 File /usr/lib/pymodules/python2.6/reportbug/submit.py, line 331, in 
 send_report
   fh.write(message.as_string())
   AttributeError: 'str' object has no attribute 'as_string'

In the latest version of reportbug (as available in unstable) you
won't get a crash but this warning:

Report will be saved as ~/myreport.txt
Submit this report on release.debian.org (e to edit)
[Y|n|a|c|e|i|l|m|p|q|d|t|s|?]?
Writing to ~/myreport.txt failed; using instead
/tmp/reportbug-release.debian.org-20120818-12792-sf7_gQ
Bug report written as /tmp/reportbug-release.debian.org-20120818-12792-sf7_gQ

 The workaround is to use $HOME instead of ~.

because $HOME is expanded by the shall you're calling reportbug from;
the proper fix is to expand ~ in the reportbug code, which I'm about
to do.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

Bug#683284: graphicsmagick: diff for NMU version 1.3.16-1.1

2012-08-18 Thread gregor herrmann

tags 683284 + patch
tags 683284 + pending
thanks

Dear maintainer,

I've prepared an NMU for graphicsmagick (versioned as 1.3.16-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
 .''`.  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
   `-   NP: John Lennon
diff -u graphicsmagick-1.3.16/debian/changelog graphicsmagick-1.3.16/debian/changelog
--- graphicsmagick-1.3.16/debian/changelog
+++ graphicsmagick-1.3.16/debian/changelog
@@ -1,3 +1,14 @@
+graphicsmagick (1.3.16-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * [SECURITY] Fix CVE-2012-3438: apply patch from upstream repo:
+http://graphicsmagick.hg.sourceforge.net/hgweb/graphicsmagick/graphicsmagick/rev/d6e469d02cd2
+coders/png.c: Some typecasts were inconsistent with libpng-1.4 and
+later.
+(Closes: #683284)
+
+ -- gregor herrmann gre...@debian.org  Sat, 18 Aug 2012 15:08:57 +0200
+
 graphicsmagick (1.3.16-1) unstable; urgency=low
 
   * New upstream version 1.3.16.
only in patch2:
unchanged:
--- graphicsmagick-1.3.16.orig/coders/png.c
+++ graphicsmagick-1.3.16/coders/png.c
@@ -1360,7 +1360,11 @@
 }
 
 #ifdef PNG_USER_MEM_SUPPORTED
-static png_voidp png_IM_malloc(png_structp png_ptr,png_uint_32 size)
+#if PNG_LIBPNG_VER = 14000
+static png_voidp png_IM_malloc(png_structp png_ptr,png_alloc_size_t size)
+#else
+static png_voidp png_IM_malloc(png_structp png_ptr,png_size_t size)
+#endif
 {
   (void) png_ptr;
   return MagickAllocateMemory(png_voidp,(size_t) size);
@@ -6169,12 +6173,22 @@
   (void) printf(writing raw profile: type=%.1024s, length=%lu\n,
 profile_type, (unsigned long)length);
 }
-  text=(png_textp) png_malloc(ping,(png_uint_32) sizeof(png_text));
+#if PNG_LIBPNG_VER = 14000
+  text=(png_textp) png_malloc(ping,(png_alloc_size_t) sizeof(png_text));
+#else
+  text=(png_textp) png_malloc(ping,(png_size_t) sizeof(png_text));
+#endif
   description_length=strlen((const char *) profile_description);
   allocated_length=(png_uint_32) (length*2 + (length  5) + 20
   + description_length);
-  text[0].text=(png_charp) png_malloc(ping,allocated_length);
-  text[0].key=(png_charp) png_malloc(ping, (png_uint_32) 80);
+#if PNG_LIBPNG_VER = 14000
+   text[0].text=(png_charp) png_malloc(ping,
+  (png_alloc_size_t) allocated_length);
+   text[0].key=(png_charp) png_malloc(ping, (png_alloc_size_t) 80);
+#else
+   text[0].text=(png_charp) png_malloc(ping, (png_size_t) allocated_length);
+   text[0].key=(png_charp) png_malloc(ping, (png_size_t) 80);
+#endif
   text[0].key[0]='\0';
   (void) strcat(text[0].key, Raw profile type );
   (void) strncat(text[0].key, (const char *) profile_type, 61);
@@ -7620,7 +7634,12 @@
 
   if (*attribute-key == '[')
 continue;
-  text=(png_textp) png_malloc(ping,(png_uint_32) sizeof(png_text));
+#if PNG_LIBPNG_VER = 14000
+text=(png_textp) png_malloc(ping,
+ (png_alloc_size_t) sizeof(png_text));
+#else
+text=(png_textp) png_malloc(ping,(png_size_t) sizeof(png_text));
+#endif
   text[0].key=attribute-key;
   text[0].text=attribute-value;
   text[0].text_length=strlen(attribute-value);


signature.asc
Description: Digital signature

Bug#685226: mpich2: build using blcr on armhf too

2012-08-18 Thread Julian Taylor

Package: mpich2
Version: 1.4.1-1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu quantal ubuntu-patch

blcr is built on armhf so mpich2 could use it as checkpointing library on that
platform too.
Attached patch should archive this.

It is not particularly important as blcr does not work with current kernels,
but maybe it is of use for people running debian with older kernels (see bug
638339).



-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise-proposed'), (500, 'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-29-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru mpich2-1.4.1/debian/changelog mpich2-1.4.1/debian/changelog
diff -Nru mpich2-1.4.1/debian/control mpich2-1.4.1/debian/control
--- mpich2-1.4.1/debian/control	2011-08-25 21:37:45.0 +0200
+++ mpich2-1.4.1/debian/control	2011-12-05 20:18:55.0 +0100
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Debian Science Maintainers debian-science-maintain...@lists.alioth.debian.org
 Uploaders: Lucas Nussbaum lu...@debian.org, Torquil Macdonald Sørensen torq...@gmail.com
-Build-Depends: debhelper (= 7), cdbs, gfortran, txt2man, libxt-dev, x11proto-core-dev, default-jdk, quilt, procps, libhwloc-dev, hwloc-nox, libcr-dev [amd64 armel i386 powerpc], automake
+Build-Depends: debhelper (= 7), cdbs, gfortran, txt2man, libxt-dev, x11proto-core-dev, default-jdk, quilt, procps, libhwloc-dev, hwloc-nox, libcr-dev [amd64 armel armhf i386 powerpc], automake
 Standards-Version: 3.9.2
 Homepage: http://www.mcs.anl.gov/research/projects/mpich2/
 Vcs-Browser: http://git.debian.org/?p=debian-science/packages/mpich2.git;a=summary
@@ -55,7 +55,7 @@
 Package: libmpich2-dev
 Architecture: any
 Section: libdevel
-Depends: libmpich2-3 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}, libcr-dev [amd64 armel i386 powerpc]
+Depends: libmpich2-3 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}, libcr-dev [amd64 armel armhf i386 powerpc]
 Recommends: mpich2 (= ${binary:Version})
 Description: Development files for MPICH2
  MPICH2 is a high-performance and widely portable implementation of the
diff -Nru mpich2-1.4.1/debian/rules mpich2-1.4.1/debian/rules
--- mpich2-1.4.1/debian/rules	2011-08-27 09:06:32.0 +0200
+++ mpich2-1.4.1/debian/rules	2011-12-05 20:19:38.0 +0100
@@ -26,7 +26,7 @@
 	--with-hwloc-prefix=system
 
 # BLCR checkpointing support
-ifneq (,$(findstring $(DEB_HOST_ARCH),amd64 armel i386 powerpc))
+ifneq (,$(findstring $(DEB_HOST_ARCH),amd64 armel armhf i386 powerpc))
 	DEB_CONFIGURE_EXTRA_FLAGS += --enable-checkpointing --with-hydra-ckpointlib=blcr
 endif

Bug#657407: Bug#682265: mootools: build-depends on node-uglify, not in wheezy

2012-08-18 Thread Julien Cristau

On Sat, Jul 21, 2012 at 17:59:14 +0200, Salvatore Bonaccorso wrote:

 Hi Julien
 
 On Fri, Jul 20, 2012 at 10:19:18PM +0200, Julien Cristau wrote:
  Either mootools needs to be removed from wheezy (along with its reverse
  dependencies zoneminder and wims), or it needs to lose its build-dep on
  node-uglify.
 
 Note: I'm neither part of the Debian Javascripts Maintainers nor
 Maintainer of one of the other packages. But I'm interested to have
 zoneminder released together with wheezy.
 
FWIW mootools is now back in testing, but zoneminder isn't, because of
#657407.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#685227: unblock: ztex-bmp/20120314-1

2012-08-18 Thread Steffen Moeller

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

Please unblock package ztex-bmp

The upload closes a FTBFS issues that appeared along the update of the
free pascal compiler. It was directly provided by upstream. The package
is not in the archive for too long and but anyway the adoption was
rather minimal http://qa.debian.org/popcon.php?package=ztex-bmp .
Should this late update not be acceptable, I only recently got my gpg
keys back in the archive a few days ago, then I kindly ask to remove
the package from Wheezy.

unblock ztex-bmp/20120314-1

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

Kernel: Linux 3.5-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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#685228: Support for Haiku x86_64 in os-prober

2012-08-18 Thread Alex Smith

Package: os-prober
Version: 1.54
Severity: wishlist

The attached patch modifies os-prober's Haiku detection to also detect
an x86_64 installation of Haiku - the kernel is named kernel_x86_64
rather than kernel_x86, so the patch changes it to check for both of
these.

Thanks,
Alex


os-prober-1.54-haiku-x86_64.patch
Description: Binary data

Bug#640499: hardening, too

2012-08-18 Thread Adam Borowski

On Sat, Aug 18, 2012 at 01:04:42PM +0200, Cyril Brulebois wrote:
 Adam Borowski kilob...@angband.pl (18/08/2012):
  I just got bit by the lack of multiarch here (wine is broken on amd64
  if nvidia is involved), and wrote a multiarchification patch before
  realizing there's already one here.  It's redundant, except for one
  bit: since an upload is needed anyway
 
 given the intrusiveness of that patch [libxvmc/multiarch], I'm pretty
 sure it's going to be considered too late in the release cycle. I'm
 also pretty sure that we (release team) said that already for similar
 packages.

It stops a prominent package [wine] from working for a good part of users,
so that's quite a motivation.  It's your package, your call, of course.

 [cc: release team for other opinions.]

And theirs.

  you could just as well add the hardening flags (another release goal).
  It's a trivial change, but git am is still faster than doing that
  yourself...
 
 Thanks, but please note that requesting unrelated features in a given
 bug report isn't too nice.

I wanted to have them in one place, as both are release goals.

 BTW, you call it trivial but you lost -Wall…

Good point, that's not a case where hardening is really important too...
so scratch this part.



 Mraw,
Hell yeah, mraw!
 KiBi.
1KB (the real pre-committee 1024 :p).

-- 
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition.  For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623


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

Bug#662103: Pausing and resuming in Amarok changes volume to 100%

2012-08-18 Thread Modestas Vainius

Hello,

On Wednesday 08 August 2012 13:57:24 Robert Keevil wrote:
 reopen 662103
 thanks
 
 Hi,
 
 Just to confirm that the problem still exists with the
 0.5.0+14.g382da0d-2 version.

Please retest with 0.6.0-1. It will hit unstable soon.

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

Bug#581786: [mount] Re: mount can hang, in an unkillable state

2012-08-18 Thread Omega Weapon

I have retested the old discs that caused this problem, and it doesnt 
recur - however I note a new problem on the original disc - only the 
first session is mounted, the following is logged in the syslog:


==

UDF-fs: warning (device loop0): udf_load_vrs: No anchor found

==

So presumably the UDF code is more error-tolerant now. I've also noticed 
that in today's kernel update (from my perspective, that I havent 
applied yet):


==

- udf: Improve sanity checking of filesystem metadata (CVE-2012-3400)
  + udf: Avoid run away loop when partition table length is corrupted
  + udf: Fortify loading of sparing table
Debian package: linux (3.2.23-1), actual changelog 
http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.22


==

So Douglas, it might handle your issue better now.

I have found a similar mount 100% kernel mode CPU usage issue when 
attempting to mount an invalid iso9660 filesystem that I am looking into 
now.



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

Bug#683720: unblock: rrdtool/1.4.7-2

2012-08-18 Thread Sebastian Harl

Hi,

On Sat, Aug 18, 2012 at 12:10:18PM +0100, Adam D. Barratt wrote:
 On Sat, 2012-08-18 at 11:36 +0200, Sebastian Harl wrote:
  sorry, I must have missing this E-mail somehow :-/
  
  On Sat, Aug 04, 2012 at 04:48:02PM +0100, Adam D. Barratt wrote:
   This change appears not to be documented in the changelog:
   
   --- rrdtool-1.4.7/debian/control
   +++ rrdtool-1.4.7/debian/control
   @@ -8,7 +8,7 @@
   [...]
   - tcl-dev (= 8.5), tcl (= 8.5),
   + tcl-dev (= 8), tcl-dev (= 9),
  
  Yes, this was a minor fix which was applied to the Debian Git tree in
  between our last upload to unstable and the 1.4.7-1.1 NMU and thus kinda
  accidentally ended up in the current upload.
 
 Ah.
 
  The former restriction (depend on = 8.5) was used for a test-build
  against newer versions of Tcl but is not imposed by RRDtool. Removing
  that restriction does not harm building RRDtool but, in contrast, makes
  backporting easier.
 
 Thanks for the explanation.  It would be nice if the changelog could be
 fixed up for a future upload, but I've unblocked the package as-is.

Thanks! I've fixed the changelog in Git for the next upload.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#685227: unblock: ztex-bmp/20120314-1