Bug#727466: mpfi: update config.{sub,guess} for the AArch64 port

[Adam Conrad]

Package: mpfi
Version: 1.5.1-1
Followup-For: Bug #727466
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch



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

  * Use dh_autotools-dev to update config.{sub,guess} for new ports.

Given that it's a one-liner, I suspect it speaks for itself. :P

... Adam

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

Kernel: Linux 3.12.0-1-generic (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru mpfi-1.5.1/debian/changelog mpfi-1.5.1/debian/changelog
diff -Nru mpfi-1.5.1/debian/rules mpfi-1.5.1/debian/rules
--- mpfi-1.5.1/debian/rules	2012-05-25 19:52:32.0 -0600
+++ mpfi-1.5.1/debian/rules	2013-11-02 23:33:09.0 -0600
@@ -5,4 +5,4 @@
 endif
 
 %:
-	dh $@
+	dh $@ --with autotools_dev

Bug#728567: gnuchess: Using 100% from cpu and over than 257mb memory

[Tarcisio Oliveira]

I just play it. I close it, the thread still running and some minutes 
later my processor was using 100%. Was needed abort the process

Em 02-11-2013 23:58, Tarcisio Oliveira escreveu:

Package: gnuchess
Version: 6.0.2-1
Severity: normal

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

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

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



-- System Information:
Debian Release: 7.2
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: i386 (i686)

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

Versions of packages gnuchess depends on:
ii  dpkg  1.16.12
ii  install-info  4.13a.dfsg.1-10
ii  libc6 2.13-38
ii  libgcc1   1:4.7.2-5
ii  libstdc++64.7.2-5

Versions of packages gnuchess recommends:
ii  gnuchess-book  1.02-1

Versions of packages gnuchess suggests:
pn  xboard | eboard | scid  

-- 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#726760: e2fsprogs: resize2fs requires ext4 kernel module for ext3 resize

[Theodore Ts'o]

On Fri, Oct 18, 2013 at 07:50:48PM +0100, Ben Harris wrote:
> 
> I have a system with only ext3 filesystems.  When I tried to resize the
> root filesystem using resize2fs I got a surprising error message:
> 
> wraith:/tmp# resize2fs -p /dev/wraith/root
> resize2fs 1.42.8 (20-Jun-2013)
> Filesystem at /dev/wraith/root is mounted on /; on-line resizing required
> old_desc_blocks = 34, new_desc_blocks = 65
> resize2fs: Filesystem does not support online resizing

The "Filesystem does not support online resizing" message is emitted
when the resize_inode feature is not set on the file system.  This can
happen because the file system was created without the resize_inode
present, which reserves block group descriptors which are needed so we
can resize the file system with out requiring moving the inode table
blocks (which is not something we can do for an online resize).  It
can also happen if the file system was originally very small, or was
created with an insufficient number of reserved desriptor blocks, and
the file system has been grown to the point where the reserved
descriptor blocks have been all used up.

> I poked it with strace and discovered:
> 
> access("/sys/fs/ext4/features/meta_bg_resize", R_OK) = -1 ENOENT (No such 
> file or directory)

This was caused by the resize2fs program checking to see if we are
running with a kernel which is new enough to support a new style of
online resizing --- but this is something which is only supported if
the file system was mounted using ext4.

So the fact that it was failing was not because we needed to have the
ext4 kernel module loading --- it was because the file system did not
have any reserved descriptor blocks which was needed for online
resizing.

> Running "modprobe ext4" caused resize2fs to be more willing to run
> (but it failed later):
> 
> wraith:/tmp# resize2fs -p /dev/wraith/root
> resize2fs 1.42.8 (20-Jun-2013)
> Filesystem at /dev/wraith/root is mounted on /; on-line resizing required
> old_desc_blocks = 34, new_desc_blocks = 65
> Performing an on-line resize of /dev/wraith/root to 16785408 (1k) blocks.
> resize2fs: Inappropriate ioctl for device While trying to add group #1088

That's because resize2fs doesn't wasn't checking to see if the file
system was mounted using ext3 or ext4; the presence of the file
/sys/fs/ext4/features/meta_bg_resize means that if the file system was
mounted with ext4, the online resizing would work.

So this is arguably a bug in resize2fs; it should have checked
/proc/mounts or /etc/mtab, and if it determined the file system in use
was not ext4, it should not have checked for the meta_bg_resize
feature flag, and just failed the the online resize unconditionally
once it determined that the file system didn't have the required
reserved descriptor blocks.

In other words, the first failure was correct; the second failure was
caused by resize2fs getting confused after you loaded the ext4 kernel
module.

Regards,

- Ted


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

Bug#726382: Reverse dependencies still not ready

[Hideki Yamane]

Hi Luca,

On Sat, 2 Nov 2013 13:53:01 +0100
Luca Falavigna  wrote:
> Not ready yet:
> Checking reverse dependencies...

 Thanks!

> # Broken Build-Depends:
> chromium-browser: ttf-kochi-gothic
>   ttf-kochi-mincho
 
 It was already reported as 
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725800
 I'll raise its severity.

> lilypond: ttf-kochi-gothic
>   ttf-kochi-mincho

 Okay, I've reported it to upstream now...
 http://news.gmane.org/gmane.comp.gnu.lilypond.devel
 

> xfonts-mona: ttf-kochi-gothic

 Hmm, that's what I don't expected...
 Any idea? > Nobuhiro

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


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

Bug#725627: [pcp] Bug#725627: closed by Nathan Scott (Bug#725627: fixed in pcp 3.8.6)

[Nathan Scott]

3.8.8 has been uploaded to address this, finally, hopefully. :(

cheers.

--
Nathan


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

Bug#655924: /lib/udev/rules.d/60-cdrom_id.rules

[arne anka]

while i am still amazed about the stubborness and rude refusal to fix
something that obviously has been broken for no good reason, is there any
reason why

/lib/udev/rules.d/60-cdrom_id.rules

cannot be patched to include

KERNEL=="sr0", SYMLINK+="dvd", OPTIONS+="link_priority=-100"

i copied 60-cdrom_id.rules to /etc/udev/rules.d/, added above line and
called

udevadmin trigger all

and /dev/dvd is back. is there any _good_ reason not do it this way?


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

Bug#728567: gnuchess: Using 100% from cpu and over than 257mb memory

[Tarcisio Oliveira]

Package: gnuchess
Version: 6.0.2-1
Severity: normal

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

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

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



-- System Information:
Debian Release: 7.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: i386 (i686)

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

Versions of packages gnuchess depends on:
ii  dpkg  1.16.12
ii  install-info  4.13a.dfsg.1-10
ii  libc6 2.13-38
ii  libgcc1   1:4.7.2-5
ii  libstdc++64.7.2-5

Versions of packages gnuchess recommends:
ii  gnuchess-book  1.02-1

Versions of packages gnuchess suggests:
pn  xboard | eboard | scid  

-- 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#725627: closed by Nathan Scott (Bug#725627: fixed in pcp 3.8.6)

[Cyril Brulebois]

reopen 725627
found 725627 3.8.7
notfixed 725627 3.8.6
thanks

Debian Bug Tracking System  (2013-11-01):
> This is an automatic notification regarding your Bug report
> which was filed against the src:pcp package:
> 
> #725627: pcp: FTBFS on kfreebsd-*: trace.c:19:20: fatal error: probes.h: No 
> such file or directory
> 
> It has been closed by Nathan Scott .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Nathan Scott 
>  by
> replying to this email.

Still getting the very same build failure:
  https://buildd.debian.org/status/package.php?p=pcp&suite=sid

| gcc  -fPIC -fno-strict-aliasing -D_GNU_SOURCE -fstack-protector-all 
-D_FORTIFY_SOURCE=2 -I../../../src/pmcd/src -I../../../src/libpcp/src 
-DPMCD_INTERNAL -I/usr/include/nss -I/usr/include/nspr -Wall -O2 -g -DPCP_DEBUG 
-DPCP_VERSION=\"3.8.6\" -I../../../src/include -I../../../src/include/pcp   -c 
-o trace.o trace.c
| trace.c:19:20: fatal error: probes.h: No such file or directory
|  #include "probes.h"
| ^
| compilation terminated.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#728566: upstart: make upstart co-installable with sysvinit

[Osamu Aoki]

Package: upstart
Version: 1.6.1-1
Severity: wishlist

Please make upstart co-installable with sysvinit by removing sysvinit in
the "Conflicts:" stanza and offer separate upstart-sysv package for
replacing /sbin/init just as systemd does with systemd and systemd-sysv.

This eases testing and migration much easier.  I would like to install
all upstart/systemd/sysvinit together and switch my boot mode by setting
the kernel boot parameter like
 init=/usr/lib/upstart
 init=/usr/lib/systemd
 init=/sbin/init or init=/usr/lib/sysvinit

There may be some coordination needed with systemd and sysvinit but this
kind of technical measure will be good idea whatever init system is
chosen as default. (I did not look in how exactly systemd work with
sysvinit on supposedly overlapping commands like telinit etc.)

Background:
I installed upstart to my system.  It removed sysvinit as expected.
Although I faced some boot failure with upstart, I could get normal boot
by providing init=/usr/lib/systemd when booting since I had systemd
installed without removing sysvinit before.  (I did not have time to
debug...)

Also, dist-upgrade removes upstart as expected since it conflicts with
the essential package sysvinit.  This is annoying too.

For me to feel easy to come back to upstart to debug issues, I would
rather select boot mode via kernel parameter.  I also would like to have
no complication with dist-upgrade.  Then I can make benchmarking of boot
speed etc. without complication.


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

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

Versions of packages upstart depends on:
ii  ifupdown0.7.45
ii  initscripts 2.88dsf-43
ii  libc6   2.17-93
ii  libdbus-1-3 1.6.18-1
ii  libjson-c2  0.11-3
pn  libnih-dbus1
pn  libnih1 
ii  libselinux1 2.2-1
ii  libudev1204-5
pn  mountall
ii  sysv-rc 2.88dsf-43
ii  sysvinit-utils  2.88dsf-43
ii  udev204-5

upstart recommends no packages.

Versions of packages upstart suggests:
ii  bash-completion  1:2.0-1
pn  graphviz 
ii  python   2.7.5-5


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

Bug#687624: ITP: libdvdcss-pkg -- automated installer for libdvdcss

[Christoph Anton Mitterer]

Hi.

Anything new on this? Now that Debian has accepted stuff like libaacs,
this shouldn't be much more of a problem, should it?

And I guess it's one of THE reasons why people still need to use DMO.

Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#728539: elfutils: eu-readelf crashes when reading a shared library

[Kurt Roeckx]

On Sat, Nov 02, 2013 at 10:06:20PM +0100, Mark Wielaard wrote:
> On Sat, Nov 02, 2013 at 07:35:39PM +0100, Kurt Roeckx wrote:
> > So for me I have this problem with this combination:
> > elfutils 0.157-1
> > libdw1 0.157-1
> > libelf1 0.153-2
> > 
> > Upgrading libelf1 to 0.157-1 makes the problem go away for me.
> > 
> > This looks like some ABI breakage in libelf?
> 
> Although the public ABI of libelf is stable and should never break,
> the elfutils tools (at least readelf) also use some internals from
> libelf, which isn't public ABI/API. So the elfutils tools (if
> packaged separately from libelf) should depend on the exact same
> version of the elfutils libelf library being installed.
> 
> The same holds true for libdw/libasm if packaged separately.
> They always have to be upgraded in lockstep. Other packages that only
> use the public interfaces of libelf (or libdw/libasm) can use whatever
> version that provides the public symbols they are providing.

I'm not sure which symbols from libelf are exported but not public
then.

Anyway, we have all libraries in their own package, and the
dependencies are now generated depending on the symbols and the
last time a symbol got added in libelf was in 0.144 so that's
currently what other packages and elfutils depend on.  For libasm
that's minimum 0.132.  But for libdw we always have the same
version as it was build against because there is actually a
timestamp or something like that generate by configure that
the backend modules check.

We currently have this symbol mapping for libelf1:
 *@ELFUTILS_1.0 0.131
 *@ELFUTILS_1.1 0.131
 *@ELFUTILS_1.1.1 0.131
 *@ELFUTILS_1.2 0.131
 *@ELFUTILS_1.3 0.131
 *@ELFUTILS_1.4 0.132
 *@ELFUTILS_1.5 0.142
 *@ELFUTILS_1.6 0.144

That is if used a symbol with version ELFUTILS_1.6 it will depend
on at least 0.144.  If it uses a ELFUTILS_1.5 version on 0.142 and
so on, so that we get the lowest version that should provide the
symbols is good enough.  (The 0.131 version actually dropped some
symbols, which is why there is now a minimum depends on 0.131)

Anyway, does this make sense for other packages, or should all
package depend on the latest version?  Is it enough that elfutils
itself depends on the latest version?


Kurt


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

Bug#728565: gnustep: GNUstep packages are very out-of-date

[Michael P. Soulier]

Package: gnustep
Version: 7.7
Severity: wishlist

Dear Maintainer,

GNUstep, WindowMaker, and the .apps available for wheezy are very old, and in
some cases, broken. Please pick up the latest versions of everything.

Thanks.



-- System Information:
Debian Release: 7.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages gnustep depends on:
ii  gworkspace.app 0.9.1-1+131024
ii  preview.app0.8.5-9
ii  price.app  1.2.0-1+131024
ii  systempreferences.app  1.1.0-4+130918
ii  terminal.app   0.9.8-2+130814
ii  textedit.app   4.0+20130814
ii  zipper.app 1.5-1+131024

Versions of packages gnustep recommends:
ii  charmap.app   0.2-11+b1
ii  gnumail.app   1.2.0-2+131024
ii  gnustep-examples  1:1.3.0-1+131005
ii  gnustep-icons 1.0-5
ii  talksoup.app  1.0beta1-2+131024
ii  viewpdf.app   1:0.2dfsg1-4
ii  wmaker0.95.3-2

Versions of packages gnustep suggests:
pn  aclock.app 
ii  agenda.app 0.43.0-1+130817
pn  camera.app 
pn  cenon.app  
ii  cynthiune.app  1.0.0-2+131024
pn  edenmath.app   
ii  grr.app0.9.0-1
pn  lusernet.app   
pn  mpdcon.app 
pn  plopfolio.app  
pn  poe.app
ii  timemon.app4.1-2+b3
ii  volumecontrol.app  0.5-3.1+b1

-- 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#728361: xfce4: No working restart/shutdown buttons

[Jos van Wolput]

After upgrading policykit-1/0.105-4 (sid) to policykit-1/0.112-2
(experimental) lightdm 1.6.3-1 shows the same issue.


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

Bug#728563: ITP: golang-libgeoip -- Go implementation for lookups against GeoIP files

[Tonnerre LOMBARD]

Package: wnpp
Severity: wishlist
Owner: Tonnerre LOMBARD 

* Package name: golang-libgeoip
  Version : 0.0~git20130525-1
  Upstream Author : Nikola Ranchev 
* URL : https://github.com/nranchev/go-libGeoIP
* License : BSD-3-Clause
  Programming Lang: Go
  Description : Go implementation for lookups against GeoIP files

Go library which allows to look up IP adresses in GeoIP databases. At
this point, only IPv4 lookups are supported.


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

Bug#728562: libgpars-groovy-java, groovy: error when trying to install together: overwriting /usr/share/groovy/lib/gpars.jar

[Andreas Beckmann]

Package: libgpars-groovy-java,groovy
Version: 2.1.6+dfsg-1
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Architecture: amd64
Distribution: sid + experimental

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:

  Preparing to replace groovy 1.8.6-1 (using .../groovy_2.1.6+dfsg-1_all.deb) 
...
  Unpacking replacement groovy ...
  dpkg: error processing /var/cache/apt/archives/groovy_2.1.6+dfsg-1_all.deb 
(--unpack):
   trying to overwrite '/usr/share/groovy/lib/gpars.jar', which is also in 
package libgpars-groovy-java 0.10-1

This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/share/groovy/lib/gpars.jar

This bug is assigned to both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may
also register in the BTS that the other package is affected by the bug.

Cheers,

Andreas

PS: for more information about the detection of file overwrite errors
of this kind see http://edos.debian.net/file-overwrites/.


libgpars-groovy-java=0.10-1_groovy=2.1.6+dfsg-1.log.gz
Description: GNU Zip compressed data

Bug#671396: libtiff4: 3.9.6-3 hpcups crashes with signal 11

[Matías Bellone]

On Fri, Aug 9, 2013 at 3:07 PM, Brian Potkin  wrote:
> On Thu 03 May 2012 at 16:39:37 -0300, Matias A. Bellone wrote:
>
>> Updating libtiff4 from 3.9.6-2 to 3.9.6-5 made my HP 1006p USB printer
>> installed with hp-setup on CUPS stop working.
>>
>> The error log stated:
>>  (/usr/lib/cups/filter/hpcups) crashed on signal 11
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672129
>
> and
>
> https://bugs.launchpad.net/hplip/+bug/997225
>
> might provide some comfort.
>

I can confirm that the issue does not ocurr after upgrading to the
latest version of hplip that migrated to testing on October 18th.

You can close this bug marking it as resolved :D

Regards,
Matías


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

Bug#728561: node-carto: fails to upgrade from 'testing' - trying to overwrite /usr/share/man/man1/carto.1.gz

[Andreas Beckmann]

Package: node-carto
Version: 0.9.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Selecting previously unselected package node-carto.
  Unpacking node-carto (from .../node-carto_0.9.5-1_all.deb) ...
  dpkg: error processing /var/cache/apt/archives/node-carto_0.9.5-1_all.deb 
(--unpack):
   trying to overwrite '/usr/share/man/man1/carto.1.gz', which is also in 
package carto 0.4.6+ds1-3
  Errors were encountered while processing:
   /var/cache/apt/archives/node-carto_0.9.5-1_all.deb

Don't you need a transitional package to migrate existing users to the
new package name?

Anyway you need to add

Package: node-carto
Breaks: carto (<< 0.9.5)
Replaces: carto (<< 0.9.5)


cheers,

Andreas


carto=0.4.6+ds1-3_node-carto=0.9.5-1.log.gz
Description: GNU Zip compressed data

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

[Miguel Landaeta]

On Sat, Nov 02, 2013 at 09:55:39AM -0300, Miguel Landaeta wrote:
> I'll try to take a look at it later.

It looks like this bug is not going to be solved any time soon because
even the most recent Gradle 1.9 RC releases keep depending on Groovy 1.8.6.

-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#726733: av_register_all() segfaults on s390x in some cases (regression, causes FTBFS)

[Reinhard Tartler]

Hi Thibaut,

can you perhaps also provide a backtrace? It seems that there are no
public s390x porter machines where I could get that myself.

Also, I wonder why s390x would require -DPIC -fPIC in compilation
flags, but s390 would not.


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

Bug#727833: ITP: node-bytes -- Byte string parser and formatter - Node.js module

[Adam Borowski]

On Sun, Nov 03, 2013 at 01:30:15AM +0100, Jérémy Lal wrote:
> On 03/11/2013 00:56, Jean-Christophe Dubacq wrote:
> > I have looked at the code, and it seems to me that, again, we introduce
> > some code in debian that decide they can name the units any way they
> > like (see http://en.wikipedia.org/wiki/Binary_prefix).
> > 
> > They decide, for example, to use k, m and g prefixes for 2^10, 2^20 and
> > 2^30, where usage should point to at least k, M and G and correct usage
> > to Ki, Mi, Gi. They also call bytes 'b' (usage is more 'B').

> I agree the units are wrong and will fix it, and try to make
> upstream fix it too.

Please, don't break it.

A well-entrenched practice used for 60+ years has more weight than what a
random committee with delusions of importance decided a few years ago
asked by a couple of sleazy disk manufacturers wanting to weasel their
way out of lawsuits caused by lies of their marketing departments.

And that "binary prefix" crap is outright harmful: if 1 MB stands for
1048576 bytes like it does, what would "1 MiB" be?  That's intuitive,
1 _mi_llion, right?  Right??

-- 
A tit a day keeps the vet away.


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

Bug#728560: Potential debianization of asciidoctor 0.1.4

[brian m. carlson]

tags 728560 + patch
kthxbye

I've provided a potential debianization of the new upstream version in
the git repo at
.  It
does appear to build correctly and it produces reasonable output on some
tests I did with the git documentation.

Please feel free to use this or not, as you wish, but if you use it,
please update the changelog before uploading, since I am not a DD or DM.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Bug#728361: [Pkg-xfce-devel] Bug#728342: lightdm greeter hang and xfce4 polkit failure

[Ben Caradoc-Davies]

On 02/11/13 19:00, Yves-Alexis Perez wrote:

[I'm switching to #728361 for this case]
On Sat, 2013-11-02 at 08:19 +0800, Ben Caradoc-Davies wrote:

No, there are no local configuration changes. I am using a custom
~/.config/xfce4/xinitrc but all it adds is some xrandr and path
changes.

Hmhm, it might mess with the Debian way of doing thing (especially
running stuff from /etc/X11/Xsession.d, like consolekit stuff etc.).
Can you try without it at all?


Removing the custom user xinitrc does not fix the problem (greeter hang 
and disabled power button).


I also noticed that daemon.log contains following lines that coincide 
with the end of the greeter hang:


Nov  3 08:08:52 ripley dbus[2264]: [system] Activating service 
name='org.freedesktop.UPower' (using servicehelper)
Nov  3 08:08:52 ripley dbus[2264]: [system] Successfully activated 
service 'org.freedesktop.UPower'
Nov  3 08:08:52 ripley dbus[2264]: [system] Failed to activate service 
'org.freedesktop.ConsoleKit': timed out
Nov  3 08:08:52 ripley dbus[2264]: [system] Activating service 
name='org.freedesktop.ConsoleKit' (using servicehelper)
Nov  3 08:08:52 ripley dbus[2264]: [system] Successfully activated 
service 'org.freedesktop.ConsoleKit'
Nov  3 08:08:52 ripley console-kit-daemon[2709]: WARNING: Failed to 
acquire org.freedesktop.ConsoleKit
Nov  3 08:08:52 ripley console-kit-daemon[2709]: WARNING: Could not 
acquire name; bailing out


Kind regards,

--
Ben Caradoc-Davies 


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

Bug#728462: [Python-apps-team] Bug#728462: ocrfeeder: python-imaging (1.1.7-4 => 1.1.7+2.0.0-1.1) removes ocrfeeder (0.7.11-3)

[Alberto Garcia]

On Fri, Nov 01, 2013 at 04:17:52PM +0100, Cristian Ionescu-Idbohrn wrote:

> Looks like a dependency problem.

What happens is that python-imaging-sane was renamed to python-sane,
but the new package provides the old name, so it should work:

  The following NEW packages will be installed:
python-pil{a} python-sane{a}
  The following packages will be REMOVED:
python-imaging-sane{a}
  The following packages will be upgraded:
python-imaging
  1 packages upgraded, 2 newly installed, 1 to remove and 235 not upgraded.
  Need to get 314 kB of archives. After unpacking 488 kB will be freed.
  Do you want to continue? [Y/n/?]

Upstream is preparing a new release, so I'll update the dependency on
the ocrfeeder side as well.

Berto


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

Bug#728560: asciidoctor: new upstream version

[brian m. carlson]

Package: asciidoctor
Version: 0.1.3-1
Severity: wishlist

asciidoctor 0.1.4 is now available.  This version has support for
DocBook 5, which I would very much like to try out.  Would you please
consider updating the package to this version?

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

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

Versions of packages asciidoctor depends on:
ii  ruby  1:1.9.3
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.448-1
ii  ruby2.0 [ruby-interpreter]2.0.0.299-2

asciidoctor recommends no packages.

Versions of packages asciidoctor suggests:
ii  asciidoctor-doc  0.1.3-1

-- no debconf information

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Bug#727595: SPARC also

[Jo Shields]

Please note that SPARC support is also gone, and Mono packages should be
removed for SPARC.


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

Bug#685787: Praat has serious bug #713597

[Benjamin Drung]

On Sa, 2013-11-02 at 18:40 +0100, Rafael Laboissiere wrote:
> * Benjamin Drung  [2013-11-02 13:08]:
> 
> > On Sa, 2013-11-02 at 12:03 +0100, Rafael Laboissiere wrote:
> >> * Benjamin Drung  [2013-11-02 00:05]:
> >>>
> >>> I have just one recommendation/wish: It would be nice if test cases 
> >>> could be added for the new feature. The test cases should work offline.
> >>
> >> Would something along the lines of the very simple-minded shell script 
> >> attached below be appropriate?  Of course, it will need adaptation for 
> >> the shunit2 framework used in devscripts.
> >
> > Yes, that's exactly what I hoped for. We already have test/test_uscan, 
> > which contains one online test. This could be converted to an offline 
> > test with your test framework.
> >
> >> What this script does is (1) create a minimal Debian package directory, 
> >> containing minimal files debian/{changelog,watch,copyright}, (2) create a 
> >> minimal repository, containing a tarball (built on the fly), and (3) 
> >> start an HTTP server that works offline, using the SimpleHTTPServer 
> >> module of Python.
> >
> > Maybe this short description could be added to the test case as comment 
> > (for documentation).
> 
> Ok, I did it and also changed test/Makefile accordingly. The patch is 
> attached below.  Note that I also added an entry in debian/copyright, but 
> that may be wrong.  There is no need to build-depend on libpython-stdlib 
> (for the SimpleHTTPServer module), because python3-all pulls it in. This 
> patch works here inside my pbuilder.

The modification on debian/copyright is okay. I have some comments:

1) I like to have one test file for each script which contains one or
more tests. So the test file for uscan should be called test_uscan and
contain a test function testFileExclusion using shunit.

2) The test in test_uscan should be converted to an offline test or
test_uscan should be renamed to test_uscan_online.

3) The test could do more validity checks. It could compare the list of
files in the tarball with the expected content.

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Bug#717693: Bug#720591: Bug#717693: Bug#720591: apache2_invoke: configuration phpbb3 not supported in postinst

[David Prévot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: tags -1 - moreinfo
Control: reassign 720591 apache2
Control: unblock 720591 by -1
Control: forcemerge -1 720591
Control: affects -1 phpbb3

Le 02/11/2013 11:22, Arno Töll a écrit :

> Could either of you please test the patch I wrote [1].

Following up here after our exchange on IRC and a bit more tests: it
seems to do the trick, thanks a lot. Merging the phpbb3 bug into it
since it fixes the issue.

Regards

David


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJSdYjmAAoJEAWMHPlE9r08x7UH/3aaRbx28PMG3v3gnuJOnO8k
YkLPP1+I3Mqfy4O5bnbMviALBc6o1WNbqYJa/SPHYZfsYM4l5d8jGInNpJ7qDVz8
o7TKKElQTdoPTTiBGb8YaNGwG75jUH37QdMCJ6F9IGWvM9AYzZ0H0qqPRiA2OeZo
2pZ0vzdXqGnNDgPmBpUn8PkVowDQNH8nvbUVFKupVtGiq6WyHDAjRLv0vhVYA8Io
HSFxSlJ50XmkwPepPKCx1N+9ylwVGKzuBJ5qNJCjUk+5h5tax1noYMFdX9Gutjxw
zlbaK0Wceu5p1TSvEtz6ipQPJD6Z0ab2Q5qIWnw/yVAUiHc3c56ELHP1jgL7sBs=
=ZHtr
-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#727586: RM: libindicate [ia64] -- ANAIS; ia64 support removed from Mono

[Jo Shields]

On Sat, 2013-11-02 at 13:17 +0100, Luca Falavigna wrote:
> tags 727586 + moreinfo
> thanks
> 
> 
> There are still some rdeps (source packages) to handle:

If I understand the archive correctly, this one shouldn't actually need
any removals? Only the arch:all packages require Mono, so availability
of those arch:all packages shouldn't prevent Mono from being decrufted.
The IA64/SPARC packages in src:libindicate don't appear to be
Mono-related (mono-devel is in build-depends-indep)


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

Bug#728444: Work-around

[Rodrigo Campos]

Hi,

Besides is probably pretty clear from the bug report, I add this information
just in case is useful for someone else.

Downgrading the library to the previous version on testing makes xpdf work
again. I did this by adding:

deb http://snapshot.debian.org/archive/debian/20131029T094523Z/ testing 
main contrib non-free

To my sources.list and then running:

apt-get install fontconfig=2.10.2-2 fontconfig-config=2.10.2-2 
fonts-opensymbol=2:102.3+LibO4.1.1-1 libfontconfig1=2.10.2-2




Thanks a lot,
Rodrigo


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

Bug#728559: ITP: libterm-progressbar-quiet-perl -- extension to libterm-progressbar-perl to only show a progress meter if run interactively

[Florian Schlichting]

Package: wnpp
Severity: wishlist
Owner: Florian Schlichting 

* Package name: libterm-progressbar-quiet-perl
  Version : 0.31
  Upstream Author : Leon Brocard, a...@astray.com
* URL : https://metacpan.org/release/Term-ProgressBar-Quiet
* License : GPL-1+, Artistic
  Programming Lang: Perl
  Description : extension to libterm-progressbar-perl to only show a 
progress meter if run interactively

Term::ProgressBar is a wonderful module for showing progress bars on the
terminal. Term::ProgressBar::Quiet acts very much like that module when
it is run interactively. However, when it is not run interactively (for
example, as a cron job) then it does not show the progress bar.


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

Bug#726827: xen-utils-4.1: Xen doesn't start on a laptop with Nvidia Optimus graphics

[Samuel Thibault]

Hello,

Same problem here with Optimus graphics, same patch made things work for
me too, 

ii  xen-utils-4.34.3.0-3   amd64 XEN 
administrative tools


Samuel


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

Bug#728529: [DSE-Dev] Bug#728529: libselinux1: causes ld.so error in smartctl/smartd

[Laurent Bigonville]

retitle 728529 libselinux1: Missing explicit link against libpthread
severity 728529 grave
reassign 728507 libselinux1 2.2-2
reassign 728113 libselinux1 2.1.9-5
forcemerge 728529 728507 728113
thanks

Le Sat, 02 Nov 2013 17:04:31 +0100,
Sven Hartge  a écrit :

> Hi!

Hi,

> The recent upgrade auf libselinux1 to version 2.2-1 in unstable causes
> smartctl and smartd to fail with the following message:
> 
> system:~# smartctl
> Inconsistency detected by ld.so: dl-version.c: 224:
> _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
> 
> Downgrading libselinux1 to 2.1.13-3 solves the problem.

Thanks for the bugreport, explicitly linking libselinux against
libpthread seems to fix this.

> So far only smartctl/smartd is affected, but since this bug affects an
> unrelated package, the severity of critical seems correct.
> 
> Please also see and maybe merge bug #728507 against smartmontools.

Merged, I'm a bit puzzled about #728113 but it also seems related.

Cheers

Laurent Bigonville


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

Bug#719452: libforms-dev: xforms.info image links

[Jens Thoms Toerring]

Hi Kevin,

On Sun, Nov 03, 2013 at 09:02:12AM +1100, Kevin Ryde wrote:
> Jens Thoms Toerring  writes:
> >
> > pointing out the problem!
> 
> I since had a lintian test accepted which reports various packages with
> this

Good work!

> ... so you're not Robinson Crusoe :-)

Even though my cat is called "Friday"?;-)

> http://lintian.debian.org/tags/info-document-missing-image-file.html

I guess it's the same for them as it was for me - I never,
before you brought it up, used emacs for reading info files
(although I use emacs every day), so I never noticed this
(and neither did any of the users of the library - or at
last no-one mentioned it). But I don't seem to be in bad
company;-)

I definitely hope it works with the next release, at least
on my machine it seems to do that now (but not perfectly -
some of the larger pictures are not completely visible and
I haven't found a way around that yet, that must remain a
task for sometime when I have more time...)

Enjoy your spring and summer down under - here it starts
getting really bad, the days are getting shorter and shor-
ter, all trees lost their leaves and the weather gets
uglier with every day...
   Best regards, Jens
-- 
  \   Jens Thoms Toerring    j...@toerring.de
   \___  http://toerring.de


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

Bug#728558: ITP: libterm-progressbar-simple-perl -- simple but featureful terminal progress bar

[Florian Schlichting]

Package: wnpp
Severity: wishlist
Owner: Florian Schlichting 

* Package name: libterm-progressbar-simple-perl
  Version : 0.03
  Upstream Author : Edmund von der Burg 
* URL : https://metacpan.org/release/Term-ProgressBar-Simple
* License : GPL-1+, Artistic
  Programming Lang: Perl
  Description : simple but featureful terminal progress bar

Progress bars are handy - they tell you how much work has been done, how
much is left to do and estimate how long it will take. But they can be
fiddly! Term::ProgressBar::Simple module does the right thing in almost
all cases in a really convenient way.


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

Bug#728196: [Pkg-php-pecl] Bug#728196: Bug#728196: php-gearman is licensed under the PHP license, and is not php

[Ondřej Surý]

Hi Herman,

thanks for getting back to us. Yes, they are, but you can check f.e. xcache (or 
was it xdebug?) how to adopt PHP license to your project.

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

> On 2. 11. 2013, at 9:16, "Herman J. Radtke III"  
> wrote:
> 
> I believe most pecl extensions are licensed this way. I will certainly look 
> into it though.
>> On Nov 1, 2013, at 3:38 AM, Lior Kaplan  wrote:
>> 
>> Hi James & Herman,
>> 
>> The PHP extension for Gearman has just got into the Debian archive. We've 
>> got the following reject about the license of the extension (see bellow).
>> 
>> Would you consider changing the license to another BSD style license? (well, 
>> just not the PHP license which is intended PHP itself)
>> 
>> Kaplan
>> 
>> 
>> 
>>> On Tue, Oct 29, 2013 at 2:20 PM, Paul Tagliamonte  
>>> wrote:
>>> Package: php-gearman
>>> Severity: serious
>>> User: paul...@debian.org
>>> Usertags: ftp
>>> X-Debbugs-CC: ftpmas...@ftp-master.debian.org
>>> thanks
>>> 
>>> From the REJECT faq:
>>> 
>>> /
>>> | You have a PHP add-on package (any php script/"app"/thing, not PHP
>>> | itself) and it's licensed only under the standard PHP license. That
>>> | license, up to the 3.x which is actually out, is not really usable for
>>> | anything else than PHP itself. I've mailed our -legal list about that
>>> | and got only one response, which basically supported my view on this.
>>> | Basically this license talks only about PHP, the PHP Group, and includes
>>> | Zend Engine, so its not applicable to anything else. And even worse,
>>> | older versions include the nice ad-clause.
>>> |
>>> | One good solution here is to suggest a license change to your upstream,
>>> | as they clearly wanted a free one. LGPL or BSD seems to be what they
>>> | want.
>>> \
>>> 
>>> Sorry this made it through NEW,
>>> 
>>> 
>>> Hope you're well, and thanks for your work,
>>>   Paul
>>> 
>>> --
>>>  .''`.  Paul Tagliamonte 
>>> : :'  : Proud Debian Developer
>>> `. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
>>>  `- http://people.debian.org/~paultag
>>> 
>>> ___
>>> Pkg-php-pecl mailing list
>>> pkg-php-p...@lists.alioth.debian.org
>>> https://lists.alioth.debian.org/mailman/listinfo/pkg-php-pecl
> 
> ___
> Pkg-php-pecl mailing list
> pkg-php-p...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-php-pecl

Bug#727698: Same message on su and console login

[John David Anglin]

After updating to 2:4.0.10+dfsg on hppa-unknown-linux-gnu, I see the  
message


	no talloc stackframe at ../source3/param/loadparm.c:4831, leaking  
memory


everytime I do a console login or su.

Dave
--
John David Anglin   dave.ang...@bell.net


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

Bug#719452: libforms-dev: xforms.info image links

[Kevin Ryde]

Jens Thoms Toerring  writes:
>
> pointing out the problem!

I since had a lintian test accepted which reports various packages with
this ... so you're not Robinson Crusoe :-)

http://lintian.debian.org/tags/info-document-missing-image-file.html



-- 
Events jargon elucidated for the layman:
"Wedding package" -- three times the price and non-refundable.


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

Bug#728557: imapproxy does not support passwords longer than 64 characters

[Luca Bigliardi]

Package: imapproxy
Version: 1.2.7-1.1
Severity: normal

Hi,

it looks like imapproxy defines the maximum password length as 64:

include/imapproxy.h:180:#define MAXPASSWDLEN64/* 
max passwd length   */

Please consider increasing the threshold to a higher value.
NetBSD for instance sets the value to 8192 , see:
http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/mail/imapproxy/patches/patch-bc


Thank you,

Luca


-- System Information:
Debian Release: 7.2
  APT prefers stable
  APT policy: (700, 'stable'), (500, 'stable-updates'), (500, 
'proposed-updates')
Architecture: i386 (i686)

Kernel: Linux 3.2.2-kvm-i386-20120306 (SMP w/1 CPU core)
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#728556: libnlopt0: new upstream release (2.4)

[Steven G. Johnson]

Package: libnlopt0
Version: 2.3+dfsg-2
Severity: wishlist

Version 2.4 of NLopt is available upstream (http://ab-initio.mit.edu/nlopt).

Also, there is now a git repository on github; if you have patches, please
consider submitting a pull request (https://github.com/stevengj/nlopt).

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


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

Bug#728539: elfutils: eu-readelf crashes when reading a shared library

[Mark Wielaard]

On Sat, Nov 02, 2013 at 07:35:39PM +0100, Kurt Roeckx wrote:
> So for me I have this problem with this combination:
> elfutils 0.157-1
> libdw1 0.157-1
> libelf1 0.153-2
> 
> Upgrading libelf1 to 0.157-1 makes the problem go away for me.
> 
> This looks like some ABI breakage in libelf?

Although the public ABI of libelf is stable and should never break,
the elfutils tools (at least readelf) also use some internals from
libelf, which isn't public ABI/API. So the elfutils tools (if
packaged separately from libelf) should depend on the exact same
version of the elfutils libelf library being installed.

The same holds true for libdw/libasm if packaged separately.
They always have to be upgraded in lockstep. Other packages that only
use the public interfaces of libelf (or libdw/libasm) can use whatever
version that provides the public symbols they are providing.

I guess this isn't really documented upstream. Sorry about that.

Cheers,

Mark


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

Bug#717647: [Pkg-ia32-libs-maintainers] Bug#717647: [ia32-libs] please transition from lesstif2 to motif

[Thijs Kinkhorst]

On Sat, November 2, 2013 19:53, Paul Gevers wrote:
> Hi,
>
> On 23-07-13 12:52, Graham Inggs wrote:
>> The lesstif2 package on which your package depends or build-depends is
>> destined to be removed from the archive before the release of Jessie.
>
> We are nearly there [1, 2]. Could you please remove or replace lesstif2
> in the dependency list of ia32-libs?

We could just remove the depenceny but, since we don't want to ship
ia32-libs-* with Jessie, I've rather just requested removal altogether:
#728555.


Thijs


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

Bug#728555: RM: ia32-libs, ia32-libs-gtk -- ROM; obsolete

[Thijs Kinkhorst]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove ia32-libs and ia32-libs-gtk from unstable. The transition to
multi-arch was completed with wheezy which contained these packages in
transitional form. There's no use to keep the transitional packages for
any longer and they block ongoing transitions.


thanks,
Thijs


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

Bug#728552: annex for photo archives: allow to store rescaled/thumbnails instead of missing links

[Joey Hess]

Enrico Zini wrote:
> This way the git repo is unaffected, and git-annex still has a way to
> see that the file is not really available here, because it can detect
> that what's in the annex really is just a symlink pointing to the
> degraded area.

I know a few people have mentioned wanting something like this. Nice
idea of Elena to handle it this way. I think she's just about right in
her design.

Questions I need to think through:

1. Should a symlink to the degraded file be used? It's unbeleivable how
   many people are somehow stuck using filesystems without symlinks,
   but there they are. Seems like a hard link would work as well.
   Except oops, half the world still doesn't have hardlinks yet either.

2. In either case, it needs to do an extra readlink or stat of either the
   symlink or the hardlink, or some kind of other flag file, where
   it currently just stats the object to see if it's present in the local
   annex. So a little extra work, which seems it's going to have the
   same cost no matter what is decided WRT #1.

3. How does the user provide degraded files to the annex? I suppose
   it could be something like:

   imagemagick file.jpg | git-annx degraded file.jpg

   And git-annex then can look at file.jpg to get the key, and slurp
   up the degraded content provided for it.

4. Should degraded content be stored as regular git-annex objects?
   I can see plusses (ability to copy them around, back them up etc)
   and minuses (makes it harder for git-annex to keep track of what's a
   degraded file and what's not; it would need a mapping if the degraded
   files are not stored in a special location). So far the
   minuses seem to outweigh the plusses.

5. Is a 1:1 mapping between objects and degraded files sufficient? 
   It's simple, but then maybe someone wants a common degraded file for
   *.png or even just for * (could be useful on those systems without
   symlinks, where the current "placeholder" is a regular file
   containing the symlink target).

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#728444: libfontconfig1: xpdf is broken by fontconfig version 2.11.0-1

[Michael Gilbert]

control: tag -1 patch

Hi, this results from upstream enabling pthreads in 2.11.  I've
attached a patch to disable pthreads until a more permanent solution
is found for xpdf.

Thanks for considering this.

Best wishes,
Mike
diff -Nru fontconfig-2.11.0/debian/changelog fontconfig-2.11.0/debian/changelog
--- fontconfig-2.11.0/debian/changelog	2013-10-20 18:07:16.0 +
+++ fontconfig-2.11.0/debian/changelog	2013-11-02 20:35:08.0 +
@@ -1,3 +1,9 @@
+fontconfig (2.11.0-1.1) UNRELEASED; urgency=low
+
+  * Disable pthreads (closes: #728444).
+
+ -- Michael Gilbert   Sat, 02 Nov 2013 20:34:52 +
+
 fontconfig (2.11.0-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru fontconfig-2.11.0/debian/patches/no-pthread.patch fontconfig-2.11.0/debian/patches/no-pthread.patch
--- fontconfig-2.11.0/debian/patches/no-pthread.patch	1970-01-01 00:00:00.0 +
+++ fontconfig-2.11.0/debian/patches/no-pthread.patch	2013-11-02 20:35:39.0 +
@@ -0,0 +1,12 @@
+Description: Disable pthreads
+Author: Michael Gilbert 
+--- fontconfig-2.11.0.orig/configure
 fontconfig-2.11.0/configure
+@@ -15444,6 +15444,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
+ 
+ 
+ fi
++have_pthread=false
+ if $have_pthread; then
+ 	LIBS="$PTHREAD_LIBS $LIBS"
+ 	CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
diff -Nru fontconfig-2.11.0/debian/patches/series fontconfig-2.11.0/debian/patches/series
--- fontconfig-2.11.0/debian/patches/series	2013-10-20 18:06:47.0 +
+++ fontconfig-2.11.0/debian/patches/series	2013-11-02 20:35:22.0 +
@@ -0,0 +1 @@
+no-pthread.patch

Bug#728360: RFS: open-axiom/1.5.0~svn3056-1

[Игорь Пашев]

Here it is: https://mentors.debian.net/package/open-axiom


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

Bug#709908: make-dfsg: diff for NMU version 3.81-8.3

[gregor herrmann]

tags 709908 + pending
thanks

Dear maintainer,

I've prepared an NMU for make-dfsg (versioned as 3.81-8.3) 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: Beatles
diff -u make-dfsg-3.81/debian/control make-dfsg-3.81/debian/control
--- make-dfsg-3.81/debian/control
+++ make-dfsg-3.81/debian/control
@@ -6,7 +6,7 @@
 Maintainer: Manoj Srivastava 
 Standards-Version: 3.8.3.0
 Homepage: http://www.gnu.org/software/make/
-Build-Depends: autoconf, automake | automaken, autopoint, file
+Build-Depends: autoconf, automake1.10 | automaken, autopoint, file
 
 Package: make
 Section: devel
diff -u make-dfsg-3.81/debian/changelog make-dfsg-3.81/debian/changelog
--- make-dfsg-3.81/debian/changelog
+++ make-dfsg-3.81/debian/changelog
@@ -1,3 +1,15 @@
+make-dfsg (3.81-8.3) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix "FTBFS with automake1.13: automatic de-ANSI-fication support has
+been removed":
+Adopt change done by Colin Watson in Ubuntu:
+- Temporarily prefer automake1.10, as the newest automake currently
+  available in the archive before 1.13; this version of make still
+  requires de-ANSI-fication support (closes: #709908).
+
+ -- gregor herrmann   Sat, 02 Nov 2013 21:11:53 +0100
+
 make-dfsg (3.81-8.2) unstable; urgency=low
 
   * Non-maintainer upload.


signature.asc
Description: Digital signature

Bug#728553: ITP: node-almond -- minimal AMD API implementation for use in optimized browser builds

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 

* Package name: node-almond
  Version : 0.2.6
  Upstream Author : James Burke 
* URL : https://github.com/jrburke/almond/archive/0.2.6.tar.gz
* License : dual BSD + MIT
  Programming Lang: Javascript
  Description : minimal AMD API implementation for use in optimized browser
builds
 Some developers like to use the AMD API to code modular JavaScript,
 but after doing an optimized build, they do not want to include a
 full AMD loader like RequireJS, since they do not need all that
 functionality.
 .
 Some use cases, like mobile, are very sensitive to file sizes.
 .
 By including almond in the built file, there is no need for
 RequireJS.  almond is around **1 kilobyte** when minified with
 Closure Compiler and gzipped.


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

Bug#728552: annex for photo archives: allow to store rescaled/thumbnails instead of missing links

[Enrico Zini]

Package: git-annex
Version: 4.20131002
Severity: wishlist

Hello, and thanks yet again for git-annex.

Since I've seen it for the first time, I have this use case:

 - I store my large, full-resolution photos in the annex.
 - I move them to the large USB hard drive, that's mostly offline.
 - But I'd still like to keep scaled-down versions on my laptop to show
   people when I travel, and on my space-limited server that publishes
   galleries online.
 - If I'm looking at a scaled-down photo and I feel like working on it,
   I can git-annex get it and git-annex will know where the full-res
   version is.

We talked about it in the past, but could not figure out a way to do it.
Now, thanks to a chat with Elena Valhalla, there is a new proposal.

The idea is: when deleting a file from the annex, if it matches some
rule the file is not just deleted, but replaced with a symlink pointing
to .git/annex/degraded/. Like so (SHAsum clipped for brevity):

A photo links to a file in the annex:
  ~/photos/2013-11-01.jpg
   -> 
.git/annex/objects/9M/zz/SHA256-s533603212--ffd0fe…/SHA256-s533603212--ffd0fe…

The file in the annex, when not available, currently just gets deleted:
  .git/annex/objects/9M/zz/SHA256-s533603212--ffd0fe…/SHA256-s533603212--ffd0fe…
   -> (missing)

When instead the file is not available but a degraded version is, the
file in the annex can be replaced with a symlink:
  .git/annex/objects/9M/zz/SHA256-s533603212--ffd0fe…/SHA256-s533603212--ffd0fe…
   -> 
../../../../reduced/9M/zz/SHA256-s533603212--ffd0fe…/SHA256-s533603212--ffd0fe…
  pointing to whatever is convenient to have as a file structure for
  this.

This way the git repo is unaffected, and git-annex still has a way to
see that the file is not really available here, because it can detect
that what's in the annex really is just a symlink pointing to the
degraded area.


Ciao,

Enrico

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

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

Versions of packages git-annex depends on:
ii  curl7.33.0-1
ii  git 1:1.8.4~rc3-1
ii  libc6   2.17-93
ii  libffi6 3.0.13-4
ii  libgmp102:5.1.2+dfsg-3
ii  libgnutls26 2.12.23-8
ii  libgsasl7   1.8.0-2
ii  libicu484.8.1.1-13
ii  libidn111.28-1
ii  libxml2 2.9.1+dfsg1-3
ii  libyaml-0-2 0.1.4-2
ii  openssh-client  1:6.2p2-6
ii  rsync   3.0.9-4
ii  wget1.14-4
ii  zlib1g  1:1.2.8.dfsg-1

Versions of packages git-annex recommends:
ii  bind9-host 1:9.8.4.dfsg.P1-6+nmu3
ii  git-remote-gcrypt  0.20130908-5
ii  gnupg  1.4.15-1.1
ii  lsof   4.86+dfsg-1
ii  quvi   0.4.2-1
ii  ssh-askpass1:1.2.4.1-9

Versions of packages git-annex suggests:
pn  bup  
ii  graphviz 2.26.3-15+b1
ii  libnss-mdns  0.10-3.2

-- no debconf information


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

Bug#728551: nautilus: Nautilus segfaults on generating media preview for empty file

[Mauro Torrez]

Package: nautilus
Version: 3.8.2-2
Severity: important

Dear Maintainer,

On opening a folder having a zero-byte file with extension .mp3, .m4a, .m4v,
..mp4, .ogg and the like, Nautilus segfaults and exits inmediately.

   * What led up to the situation?

Update Nautilus to the latest version

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

When "Show thumbnails" settings is "Never" the problem does not happen.

   * What was the outcome of this action?

Nautilus produces a Segmentation fault.

   * What outcome did you expect instead?

Nautilus showing a generic icon for the corresponding file.


** Steps to reproduce this bug:

1. Open Nautilus, make sure "Show thumbnails" setting is "local" or "always".
2. Navigate to any folder you want.
3. Create an empty file with extension ".mp3"
4. Nautilus tries to generate the thumbnail and after a short while segfaults.

Ath the end there's the output produced when running nautilus through GDB.

Thanks,
Mauro.


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

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

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.22-1
ii  gsettings-desktop-schemas  3.8.2-2
ii  gvfs   1.18.2-1
ii  libatk1.0-02.10.0-2
ii  libc6  2.17-93
ii  libcairo-gobject2  1.12.16-2
ii  libcairo2  1.12.16-2
ii  libexempi3 2.2.1-1
ii  libexif12  0.6.21-1
ii  libgail-3-03.10.2-1
ii  libgdk-pixbuf2.0-0 2.28.2-1
ii  libglib2.0-0   2.38.1-2
ii  libglib2.0-data2.38.1-2
ii  libgnome-desktop-3-7   3.8.4-2
ii  libgtk-3-0 3.10.2-1
ii  libnautilus-extension1a3.8.2-2
ii  libnotify4 0.7.6-1
ii  libpango-1.0-0 1.36.0-1
ii  libpangocairo-1.0-01.36.0-1
ii  libselinux12.2-1
ii  libtracker-sparql-0.16-0   0.16.2-1
ii  libx11-6   2:1.6.2-1
ii  libxml22.9.1+dfsg1-3
ii  nautilus-data  3.8.2-2
ii  shared-mime-info   1.0-1+b1

Versions of packages nautilus recommends:
ii  eject  2.1.5+deb1+cvs20081104-13
ii  gnome-icon-theme-symbolic  3.10.1-1
ii  gnome-sushi3.8.1-1
ii  gvfs-backends  1.18.2-1
ii  librsvg2-common2.40.0-1

Versions of packages nautilus suggests:
ii  brasero3.8.0-2
ii  eog3.10.1-1
ii  evince [pdf-viewer]3.10.0-1
ii  okular [pdf-viewer]4:4.11.2-1
ii  totem  3.8.2-3
ii  tracker0.16.2-1
ii  vlc [mp3-decoder]  2.1.0-2
ii  vlc-nox [mp3-decoder]  2.1.0-2
ii  xdg-user-dirs  0.15-1

-- no debconf information


* GDB output

LANG=C gdb nautilus

GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/nautilus...Reading symbols from 
/usr/lib/debug/usr/bin/nautilus...done.
done.
(gdb) run
Starting program: /usr/bin/nautilus 
warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x77ffa000
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffec233700 (LWP 9526)]
[New Thread 0x7fffea3ca700 (LWP 9527)]
[New Thread 0x7fffe99bd700 (LWP 9528)]
Initializing nautilus-dropbox 1.6.0
[New Thread 0x7fffd9a58700 (LWP 9529)]
Initializing nautilus-open-terminal extension
[New Thread 0x7fffce40a700 (LWP 9530)]
[New Thread 0x7fffccf10700 (LWP 9532)]
[New Thread 0x7fffbff57700 (LWP 9533)]
[New Thread 0x7fffbf756700 (LWP 9534)]
[Thread 0x7fffbf756700 (LWP 9534) exited]
[Thread 0x7fffea3ca700 (LWP 9527) exited]
[Thread 0x7fffccf10700 (LWP 9532) exited]
[New Thread 0x7fffccf10700 (LWP 9536)]
[New Thread 0x7fffcc061700 (LWP 9537)]
totem-video-thumbnailer couldn't open file 
'file:///home/mauro/T%C3%A9l%C3%A9chargements/a.mp3'

(nautilus:9522): GdkPixbuf-CRITICAL **: gdk_pixbuf_loader_close: assertion 
'GDK_IS_PIXBUF_LOADER (loader)' failed

(nautilus:9522): GdkPixbuf-CRITICAL **: gdk_pixbuf_loader_get_pixbuf: assertion 
'GDK_IS_PIXBUF_LOAD

Bug#728550: dkms: please remove quilt from build-depends

[Bob Bib]

Source: dkms
Source-Version: 2.2.0.3-1.2
Severity: minor

Dear Maintainer,

AFAIK, the 'dkms' source package has a '3.0 (quilt)' source format,
and it doesn't need a 'quilt' build-dependency in 'debian/control'.


Best wishes, Bob

Bug#728549: www.debian.org: Please correct antiharassment email address

[Raphael Walther]

Package: www.debian.org
Severity: normal

Dear Maintainer,
One of the  email addresses on the following page is incorrect:
http://www.debian.org/intro/organization.en.html

It is antiharassm...@debian.org and not antiharrassm...@debian.org.
   ^

Please find the untested patch I wrote on the file organization.data.
http://anonscm.debian.org/viewvc/webwml/webwml/english/intro/organization.data?revision=1.472&view=markup

--- organization.data   2013-11-02 20:46:05.292759340 +0100
+++ organization.data.new   2013-11-02 20:48:05.872759397 +0100
@@ -453,7 +453,7 @@
 Holger Levsen
 Moray Allan
 Gunnar Wolf
-  https://wiki.debian.org/AntiHarassment";>Anti-harassment> 
+  https://wiki.debian.org/AntiHarassment";>Anti-harassment> 
 Amaya Rodrigo
 Margarita Manterola
 Patty Langasek


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

Bug#728547: sheepdog: FTBFS on hppa -- zookeeper not supported

[John David Anglin]

Package: sheepdog
Version: 0.7.3-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Zookeeper depends on default-jdk (>= 1:1.6).  This in turn requires
openjdk which is not supported on hppa.

Built sheepdog by disabling zookeeper support.

-- System Information:
Debian Release: 7.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Versions of packages sheepdog depends on:
ii  debconf [debconf-2.0]  1.5.51
ii  dpkg   1.17.1+b1
ii  libc6  2.17-93
ii  libcfg41.4.4-3
ii  libcpg41.4.4-3
ii  libfuse2   2.9.2-4

Versions of packages sheepdog recommends:
pn  corosync  

sheepdog suggests no packages.

-- debconf information excluded


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

Bug#728548: python-coverage-dbg: Debug packages must be built specifically for debug build of Python

[Ben Finney]

Package: python-coverage-dbg
Severity: important
Version: 3.4-3
Control: submitter -1 Barry Warsaw 

On 02-Nov-2013, Barry Warsaw wrote:
> On Nov 02, 2013, at 09:27 AM, Ben Finney wrote:
> 
> >The debug symbols are created by stripping the debug symbols from the
> >normal object files, and installing them only in the debug package
> >https://wiki.debian.org/DebugPackage>, in our case by the
> >‘override_dh_strip’ and ‘install’ targets of the rules file.
> 
> Right, but for Python that's not enough.
> 
> https://wiki.debian.org/Python/DbgBuilds
> 
> That page is a little out of date (e.g. python-support) but the gist of
> it is still relevant. When you run python-dbg or python3-dbg, you're
> getting the debug build of Python. Since the debug build has a different
> ABI than the non-debug build, extension modules have to be built and
> provided for each. Debug build Python will refuse to import non-debug
> build extensions and vice versa, because of the different ABI. This was
> one of the main impetuses behind PEP 3149.
> 
> http://www.python.org/dev/peps/pep-3149/
> 
> As an example, take a look at dbus-python and especially the
> python{,3}-dbus-dbg binary packages. E.g. the latter contains the
> debugging symbols, but it also contains a /usr/lib/python3/dist-packages/
> _dbus_glib_bindings.cpython-33dm-x86_64-linux-gnu.so file. Note the
> '33dm' tag.
> 
> As is usual, Python 2 is different in some details, but essentially the
> same. In Debian, the debug build extensions have a non-standard _d.so
> suffix. Again, I think dbus-python is a good example.

Okay. This has been a bug for many releases of ‘python-coverage’, then.

Can we deal with this as “Severity: important” for the debug packages, but
wait until after uploading 3.7+dfsg.1-2 fixing bug#727711?

-- 
 \ “[W]e are still the first generation of users, and for all that |
  `\  we may have invented the net, we still don't really get it.” |
_o__)   —Douglas Adams |
Ben Finney 


signature.asc
Description: Digital signature

Bug#728546: snmpd: aptitude purge does not remove /var/agentx/master

[Kevin Mitchell]

Package: snmpd
Version: 5.7.2~dfsg-8.1+b1
Severity: normal


If you install and then uninstall the snmpd package, you are left with a the 
file /var/agentx/master which was created by the installation. Would it be 
possible for the pre/post rm scripts to remove this file.


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

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

Versions of packages snmpd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.51
ii  libc6  2.17-93
ii  libmysqlclient18   5.5.33+dfsg-1
ii  libsnmp-base   5.7.2~dfsg-8.1
ii  libsnmp30  5.7.2~dfsg-8.1+b1
ii  libwrap0   7.6.q-24
ii  lsb-base   4.1+Debian12
ii  zlib1g 1:1.2.8.dfsg-1

snmpd recommends no packages.

snmpd suggests no packages.

-- Configuration Files:
/etc/snmp/snmpd.conf [Errno 13] Permission denied: u'/etc/snmp/snmpd.conf'
/etc/snmp/snmptrapd.conf [Errno 13] Permission denied: 
u'/etc/snmp/snmptrapd.conf'

-- debconf information:
  snmpd/upgradefrom521:


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

Bug#728545: [mumble] request for new version

[Chris Knadle]

Package: mumble
Version: 1.2.3-349-g315b5f5-2.2
Severity: wishlist

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

I would like to see a new version of Mumble in Debian -- the current version 
is 17 months old.  Upstream released a new Stable version (1.2.4) 5 months 
ago, and I think it makes sense to upgrade to this for starters.  I have a 
Debian package built using this version and have been using it for a month for 
both client and server.  If someone would like to see the package just ask and 
I'll post a URL to it, otherwise I plan to try to get an NMU sponsored for 
upload to a DELAYED queue in a week or so.

  -- Chris

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


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

Bug#728539: Re[2]: Bug#728539: elfutils: eu-readelf crashes when reading a shared library

[Vadim Zeitlin]

On Sat, 2 Nov 2013 19:35:39 +0100 Kurt Roeckx  wrote:

KR> So for me I have this problem with this combination:
KR> elfutils 0.157-1
KR> libdw1 0.157-1
KR> libelf1 0.153-2
KR> 
KR> Upgrading libelf1 to 0.157-1 makes the problem go away for me.

 Sorry, I was wrong in my initial bug report: it does indeed work correctly
with all of 0.153, 0.154, 0.157 and the latest git master if I run it
properly, i.e. by setting LD_LIBRARY_PATH, from the source tree. When I
tested git sources initially, I hadn't realized that I was still using the
packaged version of libelf1 (and libdw1 too).

 Retesting with the correct versions, I see the bug with 0.148 I build
myself and here is the backtrace:

Starting program: /home/zeitlin/build/elfutils/src/readelf -N --debug-dump=loc 
"/home/zeitlin/build/wx-gtkud/lib/libwx_baseu-3.0.so" > /dev/null

Program received signal SIGSEGV, Segmentation fault.
print_block (n=33477184, block=0x77231000) at 
/home/zeitlin/mirrors/elfutils/src/readelf.c:3803
3803   printf (" %02x", *data++);
(gdb) bt
#0  print_block (n=33477184, block=0x77231000) at 
/home/zeitlin/mirrors/elfutils/src/readelf.c:3803
#1  0x0040cf62 in print_ops (dwflmod=, dbg=, indent=50, indentrest=50, addrsize=, offset_size=4, 
len=18446744073707981979, data=0x7721e242 "\037\200")
at /home/zeitlin/mirrors/elfutils/src/readelf.c:4200
#2  0x0040d42f in print_debug_loc_section (dwflmod=, 
ebl=, ehdr=, scn=, shdr=, dbg=0x623380) at /home/zeitlin/mirrors/elfutils/src/readelf.c:6140
#3  0x00409682 in print_debug (dwflmod=, ebl=0x6230d0, 
ehdr=0x7fffde90) at /home/zeitlin/mirrors/elfutils/src/readelf.c:6732
#4  0x004116e8 in process_elf_file (dwflmod=, 
fd=) at /home/zeitlin/mirrors/elfutils/src/readelf.c:698
#5  0x00412749 in process_dwflmod (dwflmod=0x622f30, 
userdata=, name=0x7778edf0 <_IO_stdfile_1_lock> "", 
base=4284098, arg=0x0) at /home/zeitlin/mirrors/elfutils/src/readelf.c:526
#6  0x77bc5eae in dwfl_getmodules (dwfl=0x621030, callback=0x4126f0 
, arg=0x7fffe080, offset=1) at 
/home/zeitlin/mirrors/elfutils/libdwfl/dwfl_getmodules.c:103
#7  0x00404243 in process_file (only_one=true, fname=, 
fd=) at /home/zeitlin/mirrors/elfutils/src/readelf.c:596
#8  main (argc=, argv=) at 
/home/zeitlin/mirrors/elfutils/src/readelf.c:277

 But this was fixed since then and so it looks like there is nothing much
to do here, knowing that Wheezy has 0.152 which does work (just tested in a
chroot).

 Sorry again for the initial confusion!
VZ


pgpJMOQa26wGN.pgp
Description: PGP signature

Bug#728544: gnome-user-share: three autostart entries with identical names and comments

[Martin Kourim]

Package: gnome-user-share
Version: 3.8.3-1
Severity: minor

Hi,

there are three autostart entries with identical names ("Personal File 
Sharing") and comments ("Launch Personal File Sharing if enabled") in the 
"Statrup Applications Preferences" setting dialog. This is potentially 
confusing.

These entries commes from three different files 
(gnome-user-share-obexftp.desktop, gnome-user-share-obexpush.desktop and 
gnome-user-share-webdav.desktop) so the names and comments should be distinct 
as well even though the executable is still the same.

Thanks,
Martin Kourim


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

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

Versions of packages gnome-user-share depends on:
ii  apache2-bin  2.4.6-3
ii  dconf-gsettings-backend [gsettings-backend]  0.18.0-1
ii  gnome-bluetooth  3.8.1-2
ii  libapache2-mod-dnssd 0.6-3.1
ii  libatk1.0-0  2.10.0-2
ii  libc62.17-93
ii  libcairo-gobject21.12.16-2
ii  libcairo21.12.16-2
ii  libcanberra-gtk3-0   0.30-2
ii  libcanberra0 0.30-2
ii  libdbus-1-3  1.6.16-1
ii  libdbus-glib-1-2 0.100.2-1
ii  libgdk-pixbuf2.0-0   2.28.2-1
ii  libglib2.0-0 2.36.4-1
ii  libgnome-bluetooth11 3.8.1-2
ii  libgtk-3-0   3.8.4-1
ii  libnautilus-extension1a  3.4.2-2
ii  libnotify4   0.7.6-1
ii  libpango-1.0-0   1.32.5-5+b1
ii  libpangocairo-1.0-0  1.32.5-5+b1
ii  libselinux1  2.1.13-3
ii  libx11-6 2:1.6.2-1
ii  obex-data-server 0.4.5-1+b3

gnome-user-share recommends no packages.

gnome-user-share 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#728527: openbox-xdg-autostart is executed twice

[Mateusz Łukasik]

On 02.11.2013 at 15:45 Eugenio 'g7' Paolantonio  wrote:


Package: openbox
Version: 3.5.2-4
Tags: patch

It seems that this ([1]) patch makes openbox execute
openbox-xdg-autostart twice, as openbox-xdg-autostart is already
executed by
openbox-autostart.

I'm attaching a simple patch that fixes the issue, by removing the
openbox-xdg-autostart call from openbox-autostart.


Kind regards,
Eugenio

[1]
https://github.com/mati75/openbox-debian/blob/master/debian/patches/644628_fix_autostart.patch



Control: tags patch
Control: thanks


I will add it to next upload.


Mateusz


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

Bug#690669: This bug also affects me

[Tommy Butler]

I have the same problem.  I confirm that this bug is also happening to
me.  Is there a real solution or fix?


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

Bug#728360: RFS: open-axiom/1.5.0~svn3056-1

[Игорь Пашев]

Hi, Boris!
Thanks awfully :-)

I've committed changes that you suggested:
http://anonscm.debian.org/gitweb/?p=pkg-open-axiom/pkg-open-axiom.git

And uploaded some screenshots (not approved yet):
http://screenshots.debian.net/package/open-axiom

Source package is now lintian clean.

Now I'm rebuilding binaries for checking, and will upload sources shortly.


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

Bug#717647: [ia32-libs] please transition from lesstif2 to motif

[Paul Gevers]

Hi,

On 23-07-13 12:52, Graham Inggs wrote:
> The lesstif2 package on which your package depends or build-depends is
> destined to be removed from the archive before the release of Jessie.

We are nearly there [1, 2]. Could you please remove or replace lesstif2
in the dependency list of ia32-libs?

Paul

[1] http://release.debian.org/transitions/html/motif.html
[2]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=lesstif2motif;users=openmo...@packages.debian.org



signature.asc
Description: OpenPGP digital signature

Bug#728509: Pending fixes for bugs in the fonts-arphic-uming package

[pkg-fonts-devel]

tag 728509 + pending
thanks

Some bugs in the fonts-arphic-uming package are closed in revision
54ce1606ff7358a3392195da92d10f4c4d0cde24 in branch 'master' by
Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-arphic-uming.git;a=commitdiff;h=54ce160

Commit message:

Properly remove obsolete configuration file 
/etc/fonts/conf.avail/25-arphic-uming-nobitmaps.conf Closes: #728509


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

Bug#728543: caff: missing dependencie to libnet-smtp-ssl-perl

[Carsten Schoenert]

Package: signing-party
Version: 1.1.4-1
Severity: normal

Dear Maintainer,

caff is not possible to send emails via smtps because the package
libnet-smtp-ssl-perl is needed for this. signing-party doesn't even
have not a Recommends entry for this package. But I think signing-party
should depend on this because some user won't send mails without
smtps support.

I found this issue while I set up a additional line to my .caffrc.
> $CONFIG{'mailer-send'} =  [ 'smtps', Server => 'securesmtp.t-online.de', Auth 
> => ['[my-name]@t-online.de', 'very-secret'] ];

After installing libnet-smtp-ssl-perl everything goes well.

Regards
Carsten

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

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

Versions of packages signing-party depends on:
ii  gnupg  1.4.12-7+deb7u2
ii  libc6  2.13-38
ii  libclass-methodmaker-perl  2.18-1+b1
ii  libgnupg-interface-perl0.45-1
ii  libmailtools-perl  2.09-1
ii  libmime-tools-perl 5.503-1
ii  libterm-readkey-perl   2.30-4+b2
ii  libtext-template-perl  1.45-2
ii  perl   5.14.2-21+deb7u1
ii  qprint 1.0.dfsg.2-2

Versions of packages signing-party recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.80-7
ii  libgd-gd2-noxpm-perl   1:2.46-2+b1
ii  libpaper-utils 1.1.24+nmu2
ii  libtext-iconv-perl 1.7-5
ii  whiptail   0.52.14-11.1

Versions of packages signing-party suggests:
ii  imagemagick8:6.7.7.10-5+deb7u2
ii  mutt   1.5.21-6.2+deb7u1
pn  texlive-latex-recommended  
pn  wipe   

-- 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#726472: [Pkg-samba-maint] Bug#726472: share passwords not working after upgrade from samba3

[Andrew Bartlett]

On Sat, 2013-11-02 at 11:27 +0100, Ivo De Decker wrote:
> Hi Steve,

> I added the code from samba-libs.preinst to libpam-smbpass.preinst as well.
> Given that Jelmer convinced me yesterday to add a link instead of doing a
> simple move, the code is idempotent, so it doesn't matter if it runs multiple
> times in multiple maintainer scripts.
> 
> When the preinst fails, libpam-smbpass will not be upgraded, and the old
> version will stay on the system. In samba 3.6, libpam-smbpass was
> self-contained and didn't need any shared libraries from other samba packages.
> This means that the old libpam-smbpass module will keep working, even when the
> upgrade fails: users are still able to login to pam-enabled services (like
> ssh) using credentials that are only stored in passdb.tdb.
> 
> The only scenario where this is relevant, is when the tdb-files in
> /var/lib/samba/private already exist before the upgrade. This is only
> possible if we broke something in some older version of samba (I still haven't
> found any evidence of anything referencing /var/lib/samba/private in our old
> packages). In that case, the only thing we can do is fail with a clear
> message, instead of silently using the wrong user data. With these latest
> changes, the pam module will keep working, even in this case.
> 
> That said, given that a race condition during the upgrade is easily
> reproducible, I am pretty convinced that the problem in the original
> submission of this bug was caused by such a race condition. That case should
> be fixed by the earlier changes.

Thank you so much for you diligent attention to this difficult problem. 

Andrew Bartlett

-- 
Andrew Bartletthttp://samba.org/~abartlet/
Authentication Developer, Samba Team   http://samba.org


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

Bug#728539: elfutils: eu-readelf crashes when reading a shared library

[Kurt Roeckx]

On Sat, Nov 02, 2013 at 07:28:27PM +0100, Kurt Roeckx wrote:
> On Sat, Nov 02, 2013 at 07:11:46PM +0100, Mark Wielaard wrote:
> > On Sat, Nov 02, 2013 at 06:23:14PM +0100, Vadim Zeitlin wrote:
> > > I'm trying to use abi-dumper tool for analyzing the ABI of my own shared
> > > library. This tools uses eu-readelf to actually read the library symbols
> > > but eu-readelf crashes, making it unusable:
> > > 
> > >   % eu-readelf -N --debug-dump=loc libwx_baseu-3.0.so > /dev/null
> > >   [2]16820 segmentation fault (core dumped)  eu-readelf -N 
> > > --debug-dump=loc  > /dev/null
> > 
> > Could you run under gdb and provide a backtrace? And/Or could you post the
> > libwx_baseu-3.0.so file you are using somewhere so someone else can help
> > debugging?
> 
> What I see is:
> Program received signal SIGSEGV, Segmentation fault.
> 0x00419bcb in openbackend (elf=elf@entry=0x62a6f0, 
> emulation=emulation@entry=0x0, machine=62) at eblopenbackend.c:311
> 311 result->data = elf->state.elf32.ehdr->e_ident[EI_DATA];
> (gdb) bt
> #0  0x00419bcb in openbackend (elf=elf@entry=0x62a6f0, 
> emulation=emulation@entry=0x0, machine=62) at eblopenbackend.c:311
> #1  0x00419ed5 in ebl_openbackend (elf=elf@entry=0x62a6f0) at 
> eblopenbackend.c:408
> #2  0x00415454 in process_elf_file (dwflmod=dwflmod@entry=0x62a110, 
> fd=7) at readelf.c:803
> #3  0x00417d36 in process_dwflmod (dwflmod=0x62a110, 
> userdata=, name=, base=, 
> arg=0x7fffe940) at readelf.c:690
> #4  0x77bbce11 in dwfl_getmodules () from 
> /usr/lib/x86_64-linux-gnu/libdw.so.1
> #5  0x00407955 in process_file (fd=fd@entry=7, fname=, 
> only_one=only_one@entry=true) at readelf.c:775
> #6  0x00403c34 in main (argc=3, argv=0x7fffeb38) at readelf.c:295
> 
> The weird thing is that in the source tree with
> LD_LIBRARY_PATH=libelf it works, and without it fails.  If I copy
> that file to /usr/lib/x86_64-linux-gnu/libelf.so.1 it works.  While
> /usr/lib/x86_64-linux-gnu/libelf.so.1 really should just be a
> stripped version of the same file.

So for me I have this problem with this combination:
elfutils 0.157-1
libdw1 0.157-1
libelf1 0.153-2

Upgrading libelf1 to 0.157-1 makes the problem go away for me.

This looks like some ABI breakage in libelf?


Kurt


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

Bug#728539: Re[2]: Bug#728539: elfutils: eu-readelf crashes when reading a shared library

[Vadim Zeitlin]

On Sat, 2 Nov 2013 18:50:04 +0100 Kurt Roeckx  wrote:

KR> On Sat, Nov 02, 2013 at 06:46:44PM +0100, Kurt Roeckx wrote:
KR> > On Sat, Nov 02, 2013 at 06:23:14PM +0100, Vadim Zeitlin wrote:
KR> > > Package: elfutils
KR> > > Version: 0.148-1
KR> > > Severity: important
KR> > > 
KR> > > I'm trying to use abi-dumper tool for analyzing the ABI of my own shared
KR> > > library. This tools uses eu-readelf to actually read the library symbols
KR> > > but eu-readelf crashes, making it unusable:
KR> > > 
KR> > > % eu-readelf -N --debug-dump=loc libwx_baseu-3.0.so > /dev/null
KR> > > [2]16820 segmentation fault (core dumped)  eu-readelf -N 
--debug-dump=loc  > /dev/null
KR> > 
KR> > I can at least reproduce this with any shared library.
KR> 
KR> I even seem to be able to do this with any binary with the 0.156-1
KR> version, but 0.153-2 working without a problem for me.
KR> 
KR> Is that 0.148-1 version right?

 I've tested both 0.148-1 (from Debian) and the latest 0.157 (from their
Git). Thanks for the hint about 0.153, I'm going to try this a.s.a.p. to
see if it works for me.

 And thanks for looking at this!
VZ


pgp0jQkvlZ3ul.pgp
Description: PGP signature

Bug#728539: elfutils: eu-readelf crashes when reading a shared library

[Kurt Roeckx]

On Sat, Nov 02, 2013 at 07:11:46PM +0100, Mark Wielaard wrote:
> On Sat, Nov 02, 2013 at 06:23:14PM +0100, Vadim Zeitlin wrote:
> > I'm trying to use abi-dumper tool for analyzing the ABI of my own shared
> > library. This tools uses eu-readelf to actually read the library symbols
> > but eu-readelf crashes, making it unusable:
> > 
> > % eu-readelf -N --debug-dump=loc libwx_baseu-3.0.so > /dev/null
> > [2]16820 segmentation fault (core dumped)  eu-readelf -N 
> > --debug-dump=loc  > /dev/null
> 
> Could you run under gdb and provide a backtrace? And/Or could you post the
> libwx_baseu-3.0.so file you are using somewhere so someone else can help
> debugging?

What I see is:
Program received signal SIGSEGV, Segmentation fault.
0x00419bcb in openbackend (elf=elf@entry=0x62a6f0, 
emulation=emulation@entry=0x0, machine=62) at eblopenbackend.c:311
311 result->data = elf->state.elf32.ehdr->e_ident[EI_DATA];
(gdb) bt
#0  0x00419bcb in openbackend (elf=elf@entry=0x62a6f0, 
emulation=emulation@entry=0x0, machine=62) at eblopenbackend.c:311
#1  0x00419ed5 in ebl_openbackend (elf=elf@entry=0x62a6f0) at 
eblopenbackend.c:408
#2  0x00415454 in process_elf_file (dwflmod=dwflmod@entry=0x62a110, 
fd=7) at readelf.c:803
#3  0x00417d36 in process_dwflmod (dwflmod=0x62a110, 
userdata=, name=, base=, 
arg=0x7fffe940) at readelf.c:690
#4  0x77bbce11 in dwfl_getmodules () from 
/usr/lib/x86_64-linux-gnu/libdw.so.1
#5  0x00407955 in process_file (fd=fd@entry=7, fname=, 
only_one=only_one@entry=true) at readelf.c:775
#6  0x00403c34 in main (argc=3, argv=0x7fffeb38) at readelf.c:295

The weird thing is that in the source tree with
LD_LIBRARY_PATH=libelf it works, and without it fails.  If I copy
that file to /usr/lib/x86_64-linux-gnu/libelf.so.1 it works.  While
/usr/lib/x86_64-linux-gnu/libelf.so.1 really should just be a
stripped version of the same file.


Kurt


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

Bug#705611: This bug is also affecting me

[Tommy Butler]

I can confirm that this bug is also affecting me on my Debian Wheezy stable
installation.  At the lock screen I can no longer unlock my computer
because the left monitor turns blue and I get no visible password prompt
dialog

Bug#728542: ITP: libpolyclipping -- polygon clipping, polygon offsetting and polyline offsetting library

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: libpolyclipping
  Version : 6.0.0
  Upstream Author : Angus Johnson 
* URL : http://sourceforge.net/projects/polyclipping
* License : GPL, BSD, MIT, Boost
  Programming Lang: C++
  Description : polygon clipping, polygon offsetting and polyline 
offsetting library

The Clipper library performs polygon clipping, polygon offsetting and polyline
offsetting. All four boolean clipping operations are supported - intersection,
union, difference and exclusive-or. Also, there are no restrictions on the
types of polygons that can be clipped - they can have holes, be
self-intersecting, have coincident edges etc.

It is written in several languages; only the C++ version is part of 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#728163: closed by Francois Marier (Bug#728163: fixed in txlibravatar 1.1-6)

[Andreas Beckmann]

Control: found -1 1.1-6

On 2013-11-01 10:51, Debian Bug Tracking System wrote:
>  txlibravatar (1.1-6) unstable; urgency=low
>  .
>* Add Replaces/Conflicts to debian/control (closes: #728163)

That doesn't work ... because it made the transitional package
uninstallable (this will also prevent migration to testing)

Use

Package:  txlibravatar
Breaks:   python-twisted-libravatar (<< 1.1.5)
Replaces: python-twisted-libravatar (<< 1.1.5)

instead.


Andreas


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

Bug#728539: elfutils: eu-readelf crashes when reading a shared library

[Mark Wielaard]

On Sat, Nov 02, 2013 at 06:23:14PM +0100, Vadim Zeitlin wrote:
> I'm trying to use abi-dumper tool for analyzing the ABI of my own shared
> library. This tools uses eu-readelf to actually read the library symbols
> but eu-readelf crashes, making it unusable:
> 
>   % eu-readelf -N --debug-dump=loc libwx_baseu-3.0.so > /dev/null
>   [2]16820 segmentation fault (core dumped)  eu-readelf -N 
> --debug-dump=loc  > /dev/null

Could you run under gdb and provide a backtrace? And/Or could you post the
libwx_baseu-3.0.so file you are using somewhere so someone else can help
debugging?

> FWIW I've tried the latest git elfutils sources (elfutils-0.157-8-g3cf491e)
> and the bug is still present in them, so it's not a Debian bug per se, but
> I'm reporting it here because I didn't find any other place to do it (the
> project has a Trac but there are no tickets there at all), please let me
> know if I should do it in some other place.

Upstream (ab)uses the Fedora bugtracker since they are on fedorahosted.org
at http://bugzilla.redhat.com/ but really should have its own tracker
one of these days. Till that happens this is as good a place as any :)
You could also just post to the developer mailinglist.

Cheers,

Mark (one of the upstream hackers)


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

Bug#693992: cross references are just removed in the manual pages

[GUO Yixuan]

Control: forwarded -1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58974

Hi,

On Thu, Nov 22, 2012 at 06:02:03PM +0100, Matthias Klose wrote:
> Package: gcc-4.7-doc
> 
> Same for the other packages too. See
> https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1069550
> 
> Maybe make the texi2pod better about these cross references.

This doesn't seem to be as easy as several lines of diff...
I've just forwarded it.

Regards,

GUO Yixuan


signature.asc
Description: Digital signature

Bug#518834: mdadm: I still regulary see these mismatches

[Andreas Beckmann]

Control: notfound -1 3.1.4-1+8efb9d1
Control: close -1

On 2013-11-02 17:53, Michael Tokarev wrote:
> Since this is a kernel issue, and the only issue per se is the mismatch_cnt
> itself, not data safety, and since there's nothing mdadm can do here, and
> since I don't see how this issue has been "fixed upstream", marking this
> (newly reopened) bug as "wontfix".

Thanks for clarification :-) These two merged bugs were too unclear to
me to properly fix them up for archival.

> Ths version graph looks quite fun at this time.
> Initially the issue has been reported for 2.5.6-7.
> In 3.1.2-1 it were reported to be fixed.
> And now in 3.1.4-1 it exists again.
> So the _kernel_ issue has been fixed in mdadm between
> versions 3.1.2 and 3.1.4, earlier and later versions
> are buggy.  So be it.

There was also http://bugs.debian.org/405919#78 that looked like it was
missing a reopen ...

(IIRC the two merged bugs even had disagreeing sets of found+fixed versions)

OK, closing and fixing up the history so that this ancient bug can be
archived finally in 4 weeks :-)


Andreas


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

Bug#728541: Please support mips64el and mipsn32el

[YunQiang Su]

Package: ext3grep

Please add mips64el and mipsn32el to arch table in debian/control
I can confirm that it can be built on mips64el

It seems that you disabled mips(eb). Is it because that this package
don't support big endian?

-- 
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#728523: kdelibs-bin conflict with kdelibs4c2a prevents use of older kde programs

[Lisandro Damián Nicanor Pérez Meyer]

On Saturday 02 November 2013 11:50:37 bns_robson wrote:
> Package: kdelibs-bin
> Version: 4:4.10.5-1+b1
> Severity: grave
> Justification: renders package unusable
> 
> nb I've selected severity grave as this bug renders kdelibs4c2a (and
> everything that depends on it) unusable, not because it makes kdelibs-bin
> unusable.
> 
> kdelibs4c2a is a part of kde3 and is required by kde3 programs. It was last
> shipped by debian as part of squeeze. Neither the kdelibs-bin in squeeze
> or the kdelibs-bin in wheezy conflicts with kdelibs4c2a.  However, the
> current kdelibs-bin in jessie does conflict with kdelibs4c2a which prevents
> the use of kde3 programs on jessie.
> 
> I've looked at
> http://packages.debian.org/wheezy/i386/kdelibs-bin/filelist
> http://packages.debian.org/jessie/i386/kdelibs-bin/filelist
> and the conflict appears to have been added as two files
> (/usr/bin/kmailservice and /usr/bin/ktelnetservice) have been introduced
> which already exist in
> http://packages.debian.org/squeeze/i386/kdelibs4c2a/filelist
> 
> On previous occasions instead of introducing a conflict a '4' was added to
> the filename e.g /usr/bin/kshell4 to avoid a conflict with /usr/bin/kshell
> thereby allowing the continued use of kde3 programs.
> 
> I'd like kdelibs-bin in jessie changed so that it uses filenames
> /usr/bin/kmailservice4 and /usr/bin/ktelnetservice4, thereby removing the
> conflict and allowing the use of old kde3 programs on jessie.

Pino has marked this bug as wishlist, but I think it should be simply closed 
as invalid. We do not support KDE3 nor it's related apps anymore since a long 
time ago.

Having to rename binaries causes more burdens on the maintainer's side, 
diverging from upstream for little to no gain.

Kinds regards, Lisandro.

-- 
18: Como se pueden evitar los problemas de alimentacion electrica
* No coma cerca de un enchufe
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#526984: shapelib 1.3.0

[Arto Jantunen]

Kurt Roeckx  writes:
> I wanted a newer version, so I've prepared a package for myself
> and put it up at:
> http://people.debian.org/~kroeckx/shapelib/
>
> I really dislike that they dropped the support for a shared
> library.

They never had a shared library, it's a Debian modification. I have a
version of this package done that keeps the shared lib (and bumps the
soname) waiting for comments from the rest of the team before I push it
out.

A copy of the source package is available at
http://people.debian.org/~viiru/shapelib/shapelib_1.3.0-1.dsc

-- 
Arto Jantunen


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

Bug#728535: debian-kernel-handbook: document rebuilding a single kernel module

[Geert Stappers]

Op 2013-11-02 om 18:09 schreef Geert Stappers:
> 
> But I miss a paragraph how to (re)build a single kernel module.
> 
> Typical use case is having a USB device with a supported chip set,
> but USB-IDs not enumerated in the driver.
> 
> In other words:
> How to do simple driver development as adding USB-IDs?
> 
> Please document which steps should be taken to have
> only a single module compiled that can be "insmod" to
> the Debian kernel.
> 

Say I have a new webcam and want to build "sunplus"
because I have added an extra USB-ID to drivers/media/usb/gspca/sunplus.c

What options should I provide to `make`?



Groeten
Geert Stappers
-- 
Leven en laten leven


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

Bug#728080: initramfs password prompt wording can be improved

[Joachim Breitner]

Control: tag -1 + patch

Hi,

Am Freitag, den 01.11.2013, 17:52 +0100 schrieb Jonas Meurer:
> A patch would be perfect. I'm rather busy at the moment, thus it's
> hard to me to keep up with cryptsetup maintenance work.  I think that
> you last option should be prefered: print $cryptsource only if it's
> not a UUID.

patch attached; verified by running qemu on my real harddrive while
runnig (and then not unlocking the disk :-)))

Greetigs,
Joachim

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


Index: cryptroot-script
===
--- cryptroot-script	(Revision 976)
+++ cryptroot-script	(Arbeitskopie)
@@ -248,12 +248,20 @@
 		fi
 
 		if [ -z "$cryptkeyscript" ]; then
-			cryptkey="Unlocking the disk $cryptsource ($crypttarget)\nEnter passphrase: "
+			if [ ${cryptsource#/dev/disk/by-uuid/} != $cryptsource ]
+			then
+# UUIDs are not very helpful
+diskname="$crypttarget"
+			else
+diskname="$cryptsource ($crypttarget)"
+			fi
 			if [ -x /bin/plymouth ] && plymouth --ping; then
 cryptkeyscript="plymouth ask-for-password --prompt"
-cryptkey=$(printf "$cryptkey")
+# Plymouth will add a : if it is a non-graphical prompt
+cryptkey="Please unlock disk $diskname"
 			else
 cryptkeyscript="/lib/cryptsetup/askpass"
+cryptkey="Please unlock disk $diskname: "
 			fi
 		fi
 


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

Bug#700476: Small english manpage grammar fixes

[GUO Yixuan]

Control: forward -1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58973
Control: tag -1 + upstream

Hi,

On Tue, Feb 12, 2013 at 10:12:03PM -0500, Paul Tagliamonte wrote:
> Package: gcc-4.7-doc
> Severity: minor
> thanks
> 
> Hi there, folks
> 
> 
> As seen in 2925 / 2930 of ./gcc/doc/invoke.texi (among other places):
> 
> The phrase "Make all warnings into errors." could be better said as
> "Turn all warnings into errors." or similar. The phrasing seems a skitch
> awkward.
> 
> Thanks!
> 
> -- 
>  .''`.  Paul Tagliamonte 
> : :'  : Proud Debian Developer
> `. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
>  `- http://people.debian.org/~paultag

Thank you, I just forwarded it to the upstream.

Cheers,

GUO Yixuan


signature.asc
Description: Digital signature

Bug#726123: Side Effect of 726156 Fixes

[Martin Gallant]

This problem appears to have been exposed by the update to apt
0.9.12.1 (0.9.12.1)

I have made three changes to the unattended-upgrade script to dig into this:
See enclosed patch.

1. Initialized return code to eliminate referenced before assignment
in the exception path
2. Added tracback code to see root cause of error in handler

I now get the following traceback information, which points me to 726156:

Exception: could not convert string to float: amd64Traceback (most
recent call last):
  File "/usr/bin/unattended-upgrade", line 701, in do_install
logfile_dpkg, options.verbose or options.debug)
  File "/usr/bin/unattended-upgrade", line 319, in upgrade_normal
res = cache.commit(install_progress=iprogress)
  File "/usr/lib/python2.7/dist-packages/apt/cache.py", line 504, in commit
res = self.install_archives(pm, install_progress)
  File "/usr/lib/python2.7/dist-packages/apt/cache.py", line 467, in
install_archives
res = install_progress.run(pm)
  File "/usr/lib/python2.7/dist-packages/apt/progress/base.py", line 206, in run
res = self.wait_child()
  File "/usr/lib/python2.7/dist-packages/apt/progress/base.py", line
276, in wait_child
self.update_interface()
  File "/usr/bin/unattended-upgrade", line 173, in update_interface
apt.progress.base.InstallProgress.update_interface(self)
  File "/usr/lib/python2.7/dist-packages/apt/progress/base.py", line
253, in update_interface
if float(percent) != self.percent or status_str != self.status:
ValueError: could not convert string to float: amd64

-- 
Marty
38d37
< import traceback
682d680
< pkg_install_success = False
705d702
< traceback.print_exc()

Bug#728539: elfutils: eu-readelf crashes when reading a shared library

[Kurt Roeckx]

On Sat, Nov 02, 2013 at 06:46:44PM +0100, Kurt Roeckx wrote:
> On Sat, Nov 02, 2013 at 06:23:14PM +0100, Vadim Zeitlin wrote:
> > Package: elfutils
> > Version: 0.148-1
> > Severity: important
> > 
> > I'm trying to use abi-dumper tool for analyzing the ABI of my own shared
> > library. This tools uses eu-readelf to actually read the library symbols
> > but eu-readelf crashes, making it unusable:
> > 
> > % eu-readelf -N --debug-dump=loc libwx_baseu-3.0.so > /dev/null
> > [2]16820 segmentation fault (core dumped)  eu-readelf -N 
> > --debug-dump=loc  > /dev/null
> 
> I can at least reproduce this with any shared library.

I even seem to be able to do this with any binary with the 0.156-1
version, but 0.153-2 working without a problem for me.

Is that 0.148-1 version right?


Kurt


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

Bug#728539: elfutils: eu-readelf crashes when reading a shared library

[Kurt Roeckx]

On Sat, Nov 02, 2013 at 06:23:14PM +0100, Vadim Zeitlin wrote:
> Package: elfutils
> Version: 0.148-1
> Severity: important
> 
> I'm trying to use abi-dumper tool for analyzing the ABI of my own shared
> library. This tools uses eu-readelf to actually read the library symbols
> but eu-readelf crashes, making it unusable:
> 
>   % eu-readelf -N --debug-dump=loc libwx_baseu-3.0.so > /dev/null
>   [2]16820 segmentation fault (core dumped)  eu-readelf -N 
> --debug-dump=loc  > /dev/null

I can at least reproduce this with any shared library.


Kurt


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

Bug#685787: Praat has serious bug #713597

[Rafael Laboissiere]

* Benjamin Drung  [2013-11-02 13:08]:


On Sa, 2013-11-02 at 12:03 +0100, Rafael Laboissiere wrote:

* Benjamin Drung  [2013-11-02 00:05]:


I have just one recommendation/wish: It would be nice if test cases 
could be added for the new feature. The test cases should work offline.


Would something along the lines of the very simple-minded shell script 
attached below be appropriate?  Of course, it will need adaptation for 
the shunit2 framework used in devscripts.


Yes, that's exactly what I hoped for. We already have test/test_uscan, 
which contains one online test. This could be converted to an offline 
test with your test framework.


What this script does is (1) create a minimal Debian package directory, 
containing minimal files debian/{changelog,watch,copyright}, (2) create a 
minimal repository, containing a tarball (built on the fly), and (3) 
start an HTTP server that works offline, using the SimpleHTTPServer 
module of Python.


Maybe this short description could be added to the test case as comment 
(for documentation).


Ok, I did it and also changed test/Makefile accordingly. The patch is 
attached below.  Note that I also added an entry in debian/copyright, but 
that may be wrong.  There is no need to build-depend on libpython-stdlib 
(for the SimpleHTTPServer module), because python3-all pulls it in. This 
patch works here inside my pbuilder.


Cheers,

Rafael Laboissière

>From 23bd86aad69f15f83effb133237fcdd9c48daae5 Mon Sep 17 00:00:00 2001
From: Rafael Laboissiere 
Date: Sat, 2 Nov 2013 18:15:54 +0100
Subject: [PATCH] Add test for the file exclusion feature of uscan

---
 debian/copyright   |  2 ++
 test/Makefile  |  1 +
 test/test_uscan_file_exclusion | 73 ++
 3 files changed, 76 insertions(+)
 create mode 100755 test/test_uscan_file_exclusion

diff --git a/debian/copyright b/debian/copyright
index 515cb94..1e28919 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -62,9 +62,11 @@ License: GPL-3
 
 Files: doc/what-patch.1
scripts/what-patch.sh
+   test/test_uscan_file_exclusio
 Copyright: 2009,  Jonathan Patrick Davies 
2006-2008, Kees Cook 
2007-2008, Siegfried-Angel Gevatter Pujals 
+   2013,  Rafael Laboissiere 
 License: GPL-3+
  This program is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
diff --git a/test/Makefile b/test/Makefile
index 7b10a5c..75ca9ff 100644
--- a/test/Makefile
+++ b/test/Makefile
@@ -5,6 +5,7 @@ test:
 	./test_debchange
 	./test_debdiff
 	./test_licensecheck
+	./test_uscan_file_exclusion
 
 online-test:
 	./test_uscan
diff --git a/test/test_uscan_file_exclusion b/test/test_uscan_file_exclusion
new file mode 100755
index 000..f3a3db2
--- /dev/null
+++ b/test/test_uscan_file_exclusion
@@ -0,0 +1,73 @@
+#!/bin/sh
+
+# Copyright (C) 2013, Rafael Laboissiere 
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the
+# Free Software Foundation; either version 3 of the License, or (at your
+# option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
+# Public License for more details.
+#
+# On Debian systems, the complete text of the GNU General Public License
+# version 3 can be found in the /usr/share/common-licenses/GPL-3 file.
+
+# This script tests the Files-Excluded feature of uscan, which allows the
+# selective exclusion of files from thje upstream tarball before repacking
+# it.
+#
+# This script does the following: (1) create a minimal Debian package
+# directory, containing minimal files debian/{changelog,watch,copyright},
+# (2) create a minimal repository, containing a tarball (built on the fly),
+# (3) start an HTTP server that works offline, using the SimpleHTTPServer
+# module of Python, and (4) run uscan inside that minimal universe.
+
+export PERLLIB="$PWD/.."
+COMMAND="$PWD/../scripts/uscan.pl"
+
+TMPDIR=$(mktemp -d)
+
+cleanup(){
+rm -rf $TMPDIR
+kill -9 $pid
+}
+
+trap cleanup 1 2 3 13 15
+
+mkdir -p $TMPDIR/foo/debian
+
+cat < $TMPDIR/foo/debian/watch
+version=3
+http://localhost:8000/foo-(\d).tar.gz
+END
+
+cat < $TMPDIR/foo/debian/changelog
+foo (0-1) unstable; urgency=low
+
+  * Initial release
+
+ -- Joe Developer   Mon, 02 Nov 2013 22:21:31 -0100
+END
+
+cat < $TMPDIR/foo/debian/copyright
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Files-Excluded: exclude-this
+END
+
+mkdir -p $TMPDIR/repo/foo
+touch $TMPDIR/repo/foo/include-this
+touch $TMPDIR/repo/foo/exclude-this
+cd $TMPDIR/repo
+tar cfvz foo-1.tar.gz foo
+
+python -m SimpleHTTPServer 8000 &
+pid=$!
+
+( cd $TMPDIR/foo ; $COMMAND )
+
+( cd $TMPDIR ; tar tfvz foo_1+dfsg.ori

Bug#724013: Acknowledgement (Gui is not shown)

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Thomas,

I am not sure what you mean by "tray icon". I'm runnings
plain fvwm, no KDE or Gnome or other fancy GUIs. The
problem is still reproducible.

Seems that the suggested reportbug tool created a new bug
report. Sorry, I did not expect that. Anyway, hopefully
you find the requested information.


Regards
Harri

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iQEcBAEBCAAGBQJSdTkRAAoJEAqeKp5m04HL0SQH/iYSXYtHA0RHfHMUTbZ75xpD
YnFZ8n//4UDAkLIWn0IiruCjEKZyj2kCRGTfkIVsnM9oy3dYwdn60AoJ5G5KGo+u
RXRoC/h0Y/C2lUTIzfQTSRpN+h7wa7te2mXmkCIMW0sSmGdUgn+TDdaSERYXlivF
2leAX6U0HADbCjRUx5Au88Yn3xreORv+DmZPEJ5JFiwPZD9ubjQSnaZiFTB3ZUiT
0ghw1nXEzMVqMlu+9oKkKskwKk/En43OBKsAVgLQXNftUrNi/YTRuBOamB9nHzVA
6sVQ1vQJHCyleHALjHTFFNrr63q8AKsxhNuGOM0hLyTY+HTHBToPRcD68ScogV8=
=a0o5
-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#728539: elfutils: eu-readelf crashes when reading a shared library

[Vadim Zeitlin]

Package: elfutils
Version: 0.148-1
Severity: important

I'm trying to use abi-dumper tool for analyzing the ABI of my own shared
library. This tools uses eu-readelf to actually read the library symbols
but eu-readelf crashes, making it unusable:

% eu-readelf -N --debug-dump=loc libwx_baseu-3.0.so > /dev/null
[2]16820 segmentation fault (core dumped)  eu-readelf -N 
--debug-dump=loc  > /dev/null

FWIW I've tried the latest git elfutils sources (elfutils-0.157-8-g3cf491e)
and the bug is still present in them, so it's not a Debian bug per se, but
I'm reporting it here because I didn't find any other place to do it (the
project has a Trac but there are no tickets there at all), please let me
know if I should do it in some other place.


-- System Information:
Debian Release: 6.0.7
  APT prefers oldstable
  APT policy: (900, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-full (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/bash

Versions of packages elfutils depends on:
ii  libasm1   0.148-1library with a programmable assemb
ii  libc6 2.11.3-4   Embedded GNU C Library: Shared lib
ii  libdw10.148-1library that provides access to th
ii  libelf1   0.148-1library to read and write ELF file

elfutils recommends no packages.

elfutils 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#728540: sisu-sqlite: switch from libsqlite3-ruby1.9.1 to ruby-sqlite3

[Andreas Beckmann]

Package: sisu-sqlite
Version: 4.2.9-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

sisu-sqlite is no longer installable in sid after the transitional
package libsqlite3-ruby1.9.1 has been dropped. Please switch to its
successor ruby-sqlite3.


Andreas


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

Bug#707681: Happens also with 1.18.2-1

[Emilio Pozuelo Monfort]

Heya,

On 31/10/13 09:03, Yves-Alexis Perez wrote:
> On Thu, 2013-10-31 at 00:36 +0100, Emilio Pozuelo Monfort wrote:
>> OK, I assumed it was gvfsd-gphoto2 as that's what #707681 was about.
> 
> Do you think this is unrelated and want me to open another bug report?

I think this is unrelated yes, but at this point I don't really mind if we keep
using this bug for your crash, particularly given the OP hasn't followed up in a
long time and his crash may be fixed in 1.18 which should hit sid soonish.

So, feel free to provide a backtrace with debugging symbols when you manage to
catch it :-)

Thanks,
Emilio


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

Bug#728538: nmu: flush_0.9.12-3

[Andreas Beckmann]

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

nmu flush_0.9.12-3 . ALL . -m "Rebuild against libtorrent-rasterbar 0.16.11"

flush depends on the no longer available libtorrent-rasterbar6


Andreas


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

Bug#728537: ITP: libtry-tiny-byclass-perl -- selectively catch exceptions by class names

[Vasudev Kamath]

Package: wnpp
Severity: wishlist
Owner: Vasudev Kamath 

* Package name: libtry-tiny-byclass-perl
  Version : 0.01
  Upstream Author : Lukas Mai 
* URL : https://metacpan.org/pod/Try::Tiny::ByClass
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : selectively catch exceptions by class names

 This module is a simple wrapper around Try::Tiny, which see. It
 re-exports try, catch, and finally.  In addition, it provides a way to
 catch only some exceptions by filtering on the class (including
 superclasses and consumed roles) of an exception object.

 This module is dependency for libcatmandu-perl
-- 
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4  C96B 6C8F 74AE 8770 0B7E


signature.asc
Description: Digital signature

Bug#728396: Fwd: pcscd: When upgrading from Squeeze to Wheezy, my smartcard reader was no longer working: further info

[Ludovic Rousseau]

Le 02/11/2013 18:00, li...@wansing-online.de a écrit :


Dear Ludovic,

this is the output of 'pcsc_scan' with pcscd/libpcsclite1 from Squeeze (first
with only cardreader connected,


On Squeeze:
0: Lenovo Integrated Smart Card Reader (SD101317913) 00 00

This reader is 0x17EF:0x1003


And following is the same output with the packages from Wheezy:


On Wheezy:
0: KOBIL EMV CAP - SecOVID Reader III (SD101317913) 00 00

This reader is 0x0D46:0x3010

You do not use the same reader in the two configurations. Is that expected?

I guess the Lenovo reader is not real but the result of a bug in pcsc-lite. The two 
readers have the exact same serial number "SD101317913".

If your banking application can't see the reader I would say it is a bug in the 
application.

Note that the pcsc library is now at /usr/lib/i386-linux-gnu/libpcsclite.so.1 
instead of /usr/lib/libpcsclite.so.1
If the libpcsclite is dynamically linked to the application you have nothing to 
do.
If the libpcsclite is dynamically loaded at runtime maybe you can change this 
configuration.

Bye

--
 Dr. Ludovic Rousseau


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

Bug#728536: ITP:ruby-client-side-validations --Automatically extracts and applies validation rules defined on the server to the client

[Padma]

Package: wnpp
Severity: wishlist
Owner: Padma 
* Package name : ruby-client-side-validations
 Version : 3.2.6
 Upstream Author : Brian Cardarella
* URL : https://github.com/bcardarella/client_side_validations
* License : GPL-2+
Description : Automatically extracts and applies validation rules
defined on the server to the client. Supports custom validations, wide
browser compliancy and client side validation callbacks.


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

Bug#633849: Me too

[Vincent Lefevre]

Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=71168

On 2013-11-02 09:22:02 +0100, Eugen Dedu wrote:
> Do you know if the upstream is informed about all these bugs?

I've just reported this bug upstream.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

Bug#728535: debian-kernel-handbook: document rebuilding a single kernel module

[Geert Stappers]

Package: debian-kernel-handbook
Version: 1.0.15
Severity: wishlist

Hello,

The Debian kernel handbook has a chapter "Common kernel-related tasks".
Which has paragraphs as "Rebuilding official Debian kernel packages",
"Building a custom kernel from Debian kernel source"
and "Building out-of-tree kernel modules".

But I miss a paragraph how to (re)build a single kernel module.

Typical use case is having a USB device with a supported chip set,
but USB-IDs not enumerated in the driver.

In other words:
How to do simple driver development as adding USB-IDs?

Please document which steps should be taken to have
only a single module compiled that can be "insmod" to
the Debian kernel.



Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: Digital signature

Bug#728534: nmu: nxlog-ce_2.4.1054-1

[Andreas Beckmann]

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

nmu nxlog-ce_2.4.1054-1 . amd64 . -m "Rebuild against perl 5.18"

This was uploaded to NEW before the perl transition started.


Andreas


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

Bug#724576: libgl1-mesa-glx: libGL error: failed to load driver: nouveau

[John Paul Adrian Glaubitz]

On 10/25/2013 10:07 PM, Sven Joachim wrote:
>> Well, I haven't figured out yet why exactly the module fails to load. I
>> just know that it does when using libgl1-mesa-dri from experimental.
>> I'll maybe check if I can get more verbose debugging output with
>> the libgl1-mesa-dri-dbg package instead.
> 
> So, do you still have that problem with mesa 9.2.2-1?

Yes, still seeing the problem unfortunately. Just did a full
dist-upgrade which updated mesa to 9.2.2-1 and the problem
still persists.

>> I did lots of testing already before I could localize it to that
>> particular package. Granted, I wasn't working purposively when
>> doing that, but I was trying to resolve different issues with
>> the PowerMac G5 I was testing this on, too.
> 
> I would expect this to be a powerpc specific problem, but Thomas is
> actually running amd64.  OTOH, mesa 9.2.2 has been in unstable for three
> days now, and apparently nobody else has complained so far.

Well, I'll meet Thomas in a few days during an open source meetup and
ask him about the status. And, I'd rather think it's a problem specific
to the nVidia card in use. I have GeForce 210 on my main desktop
running unstable and I don't see the problem there.

Adrian

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


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

Bug#678687: initramfs scripts fail with LABEL= or UUID=

[Rodolfo García Peñas]

Hi,

I think I have a patch. Could you try it? I am not using LVM.

I added a new function in the initramfs script, to change the device given to a 
/dev/mapper device (if exists), so now LVM can boot the resume partition 
independently if is /dev/mapper/x /dev/dm-x or /dev/otherthing. This patch 
supports UUID and LABEL devices, the script translate it to /dev device.

I changed the severity to critical because if LVM cannot handle other devices 
names than /dev/mapper and the image is stored in /dev/dm-x, the system cannot 
boot. The user needs edit the boot configuration and set the flag "noresume", 
else the system won't boot forever.

Cheers,
kix
-- 
 .''`.  Rodolfo García Peñas (kix) 
: :'  : Proud Debian Developer
`. `'`  4096R / 3F48 0B8C C385 AD41 9E28  006A 7B1F 5490 72B7 4923
 `- Debian - when you have better things to do than fixing systems
#!/bin/sh -x

PREREQ="mdadm mdrun multipath"

prereqs()
{
echo "$PREREQ"
}

case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac

label_to_dev()
{
local dev="$1"

local link1
local link2

if [ -d /dev/disk/by-label ]; then
dev="${dev#LABEL=}"
if [ "$dev" != "$1" ]; then
link1="/dev/disk/by-label/"${dev}
if [ -e $link1 ]; then
link2=$(readlink -f "$link1")
echo $link2
return 0
fi
fi
fi

return 1
}

uuid_to_dev()
{
local dev="$1"

local link1
local link2

if [ -d /dev/disk/by-uuid ]; then
dev="${dev#UUID=}"
if [ "$dev" != "$1" ]; then
link1="/dev/disk/by-uuid/"${dev}
if [ -e $link1 ]; then
link2=$(readlink -f "$link1")
echo $link2
return 0
fi
fi
fi

return 1
}

# Get the /dev/mapper device for a /dev given
device_to_mapper()
{
local dev="$1"

local link1
local link2
local path

if [ -d /dev/mapper ]; then
link1=$(readlink -f "$dev")

for path in /dev/mapper/*; do
link2=$(readlink -f "$path")
if [ "$link1" = "$link2" ]; then
echo "$path"
return 0
fi
done
fi

return 1
}

activate_vg()
{
local dev="$1"
local ndev

# Make sure that we have a non-empty argument
if [ -z "$dev" ]; then
return 1
fi

# Take care of lilo boot arg, risky activating of all vg
case "$dev" in
fe[0-9]*)
lvm vgchange -aly --ignorelockingfailure
exit 0
;;
# FIXME: check major
/dev/root)
lvm vgchange -aly --ignorelockingfailure
exit 0
;;
esac

# Make sure that we have a d-m path
ndev=$(label_to_dev "$dev")
if [ $? = 0 ]; then
dev=$ndev
fi

ndev=$(uuid_to_dev "$dev")
if [ $? = 0 ]; then
dev=$ndev
fi

ndev=$(device_to_mapper "$dev")
if [ $? != 0 ]; then
return 1
fi

eval $(dmsetup splitname --nameprefixes --noheadings --rows "$ndev")

if [ "$DM_VG_NAME" ] && [ "$DM_LV_NAME" ]; then
lvm lvchange -aly --ignorelockingfailure 
"$DM_VG_NAME/$DM_LV_NAME"
rc=$?
if [ $rc = 5 ]; then
echo "Unable to find LVM volume $DM_VG_NAME/$DM_LV_NAME"
fi
fi
}

if [ ! -e /sbin/lvm ]; then
exit 0
fi

modprobe -q dm-mod

activate_vg "$ROOT"
activate_vg "$resume"

exit 0


signature.asc
Description: Digital signature

Bug#726838: mplayer depends upon old libavutil under unstable

[Christoph Anton Mitterer]

severity 726838 grave
stop

Raising severity, since the issue makes the package uninstallable and
thus unusable.


Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#728396: Fwd: pcscd: When upgrading from Squeeze to Wheezy, my smartcard reader was no longer working: further info

[li...@wansing-online.de]

Dear Ludovic,

this is the output of 'pcsc_scan' with pcscd/libpcsclite1 from Squeeze (first
with only cardreader connected,

but without card, then I inserted card):

 



holger@pc1:~$ pcsc_scan
PC/SC device scanner
V 1.4.20 (c) 2001-2011, Ludovic Rousseau 
Compiled with PC/SC lite version: 1.8.3
Using reader plug'n play mechanism
Scanning present readers...
0: Lenovo Integrated Smart Card Reader (SD101317913) 00 00

Sat Nov  2 17:31:26 2013
Reader 0: Lenovo Integrated Smart Card Reader (SD101317913) 00 00
  Card state: Card removed,

Sat Nov  2 17:31:40 2013
Reader 0: Lenovo Integrated Smart Card Reader (SD101317913) 00 00
  Card state: Card inserted,
  ATR: 

ATR: 
+ TS = 3B --> Direct Convention
+ T0 = FF, Y(1): , K: 15 (historical bytes)
  TA(1) = 96 --> Fi=512, Di=32, 16 cycles/ETU
    25 bits/s at 4 MHz, fMax for Fi = 5 MHz => 312500 bits/s
  TB(1) = 00 --> VPP is not electrically connected
  TC(1) = FF --> Extra guard time: 255 (special value)
  TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1
-
  TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1
-
  TA(3) = FE --> IFSC: 254
  TB(3) = 45 --> Block Waiting Integer: 4 - Character Waiting Integer: 5
+ Historical bytes: 65 63 06 07 52 02 50 00 10 30 2F 21 92 06 40
  Category indicator byte: 65 (proprietary format)
+ TCK = 60 (correct checksum)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):

  .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    Debit card (Germany): ec-cash, GeldKarte(EUR), Maestro, Cirrus, ...

===
 
 
 
And following is the same output with the packages from Wheezy:
 
 
---
holger_w@home:~$ pcsc_scan
PC/SC device scanner
V 1.4.20 (c) 2001-2011, Ludovic Rousseau 
Compiled with PC/SC lite version: 1.8.3
Using reader plug'n play mechanism
Scanning present readers...
0: KOBIL EMV CAP - SecOVID Reader III (SD101317913) 00 00

Sat Nov  2 18:39:45 2013
Reader 0: KOBIL EMV CAP - SecOVID Reader III (SD101317913) 00 00
  Card state: Card removed,

Sat Nov  2 18:39:49 2013
Reader 0: KOBIL EMV CAP - SecOVID Reader III (SD101317913) 00 00
  Card state: Card inserted,
  ATR: 

ATR: 
+ TS = 3B --> Direct Convention
+ T0 = FF, Y(1): , K: 15 (historical bytes)
  TA(1) = 96 --> Fi=512, Di=32, 16 cycles/ETU
    25 bits/s at 4 MHz, fMax for Fi = 5 MHz => 312500 bits/s
  TB(1) = 00 --> VPP is not electrically connected
  TC(1) = FF --> Extra guard time: 255 (special value)
  TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1
-
  TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1
-
  TA(3) = FE --> IFSC: 254
  TB(3) = 45 --> Block Waiting Integer: 4 - Character Waiting Integer: 5
+ Historical bytes: 65 63 06 07 52 02 50 00 10 30 2F 21 92 06 40
  Category indicator byte: 65 (proprietary format)
+ TCK = 60 (correct checksum)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):

 .. .. .. .. .. .. .. .. .. .. .. .. .. ..
        Debit card (Germany): ec-cash, GeldKarte(EUR), Maestro, Cirrus, ...

--
 
 
 I have removed the ATR in the command outputs; I hope this is ok for you
(don't know if this is sensible data, I looked like a good idea to me).
The removed data was exactly identical in both outputs (Squeeze and Wheezy
package versions).

 
 
Greetings
Holger
 


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

Bug#526984: shapelib 1.3.0

[Kurt Roeckx]

Hi,

I wanted a newer version, so I've prepared a package for myself
and put it up at:
http://people.debian.org/~kroeckx/shapelib/

I really dislike that they dropped the support for a shared
library.


Kurt


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

Bug#518834: mdadm: I still regulary see these mismatches

[Michael Tokarev]

Control: tag -1 + wontfix - fixed-upstream

Since this is a kernel issue, and the only issue per se is the mismatch_cnt
itself, not data safety, and since there's nothing mdadm can do here, and
since I don't see how this issue has been "fixed upstream", marking this
(newly reopened) bug as "wontfix".

Ths version graph looks quite fun at this time.
Initially the issue has been reported for 2.5.6-7.
In 3.1.2-1 it were reported to be fixed.
And now in 3.1.4-1 it exists again.
So the _kernel_ issue has been fixed in mdadm between
versions 3.1.2 and 3.1.4, earlier and later versions
are buggy.  So be it.

(Cc'ing to anbe@ because apparently the tagging were done on his request)

Thanks,

/mjt


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