Bug#676176: trac: Unable to show changeset : TypeError: expecting an integer for the buffer size

[Phillip Hellewell]

On Tue, Sep 17, 2013 at 8:26 AM, Daniel Kahn Gillmor
 wrote:
> bug 676176 is assigned to the trac package, but the version number
> you're citing seems to be a python-subversion version number.

I don't have trac installed; I'm not using trac at all.  I'm seeing
the problem with viewvc 1.1.5-1.4 and python-subversion
1.6.17dfsg-4+deb7u3.

> should the bug be reassigned?

Yeah, probably.  I don't know about trac, but I think there is still a
bug in python-subversion; I see the error in viewvc and I have to
patch the /usr/share/pyshared/libsvn/core.py from python-subversion
(as mentioned in message #10) to fix it.

I think the gist is that there are two files in the python-subversion
package with basically the same bug, and someone already fixed #1 (see
patch in message #51), but they never fixed #2 (see patch in message
#10).
1. /usr/share/pyshared/svn/core.py
2. /usr/share/pyshared/libsvn/core.py

> What would you like to be done to the trac package to solve the problem?

Nothing.

> Have you tried to replicate the problem with trac 1.0.1-2 from unstable?

No, not using trac.

Phillip


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

Bug#723259: cln link with -L/usr/lib

[Richard B. Kreckel]

Hi,

Thanks for submitting this bug report.

On 09/17/2013 12:30 PM, YunQiang Su wrote:
> Package: cln
> Version: 1.3.3-1
> X-Debbugs-CC: wzss...@gmail.com
> 
> This package has one or more -L/usr/lib in its build system,
> which will make it ftbfs if there is libraries under /usr/lib,
> while is not the default architecture, mips* for example.

The only place I'm aware of is in m4/gmp.m4:119, but only if configure
is invoked with --with-gmp=/some/other/prefix, which is not the case for
the Debian package build.

The intent of that M4 macro is to make CLN's uintD match GMP's mp_limb_t
in size.

> The attachement is the buildlog of this package on mips64el platform.

Let's see: configure tests sizeof(mp_limb_t) and appears to find that it
is the same as sizeof(long), so it defines GMP_DEMANDS_UINTD_LONG.

Later, in the conversion error where it bails out, the compiler claims a
uintD* is an unsigned int*. Shouldn't include/cln/types.h:120 have
defined it as an unsigned long*?

I think that should be clarified first. Please try to find that out.
(Sorry, I don't see what it has to do with -L/usr/lib.)

Best
  -richy.
-- 
  .''`.  Richard B. Kreckel
 : :' :  
 `. `'   
   `-


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

Bug#693150: iceowl-l10n-fr: Dependency with iceowl-extension is broken

[Ralf Treinen]

Raising severity to grave now since the iceowl-l10n-* packages are no longer 
installable in sid and need to migrate to newer iceowl.

-Ralf.


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

Bug#722580: 722580 reopen

[Andrew Chant]

This update made my system unbootable due to no devices being created
by udev.  However, I believe your fix won't work on my system.

chant@zbz:~$ zcat /proc/config.gz | grep DEVTMP
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set

this configuration was enough to cause the problem.


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

Bug#723628: file: [Documentation] Man page does not document --apple flag

[Brett Nash]

Package: file
Version: 1:5.14-2
Severity: minor

Dear Maintainer,

man page does not document what the --apple flag does (does mention it
in a todo).

Regards,
nash

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

Kernel: Linux 3.11.0-rc1-wl+ (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 file depends on:
ii  libc6  2.17-92+b1
ii  libmagic1  1:5.14-2
ii  zlib1g 1:1.2.8.dfsg-1

file recommends no packages.

file 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#655975: [PATCH] Support :any architecture qualifiers for multiarch

[Niels Thykier]

On 2013-09-17 22:34, Adam D. Barratt wrote:
> [Dropped -python CC; replaced -release with an existing bug relating to
> britney and multi-arch]
> 
> On Mon, 2013-09-16 at 15:02 +0100, Colin Watson wrote:
>>   i18nspector/i386 unsatisfiable Depends: python3:any (>= 3.2.3-3~)
>>
>> I've fixed this for Ubuntu's britney instance with the following patch.
> 
> Thanks very much!
> 

Thanks indeed,

>> I'm afraid I haven't had a chance to rebase it on top of Debian or to
>> test it there, but that should hopefully not be very much work, and
>> certainly easier than recreating all this from scratch ...
> 
> Indeed. I've done the rebasing (which was mostly handling the fact that
> Debian has a "consts" module) and attached the result.
> 
> The resulting britney successfully passes our test-suite, including the
> four "live-data" datasets. Admittedly none of those tests involve
> multi-arch dependencies, but it does at least demonstrate a lack of
> regressions.
> 
> Regards,
> 
> Adam
> 

I think we should take this opportunity to get rid of the "empty"
PREDEPENDS slot (i.e. have the MULTIARCH field replace PREDEPENDS).
There is no point in having the empty slot for PREDEPENDS; yours truly
was just too lazy to figure out how to remove it from the C code when I
merged PREDEPENDS into DEPENDS.

~Niels


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

Bug#722898: benchmarks

[Christian PERRIER]

(let's drop CC: I believe that all participants to this discussion are
subscribed to debian-boot, that receves the bug contributions for D-I packages)

Quoting Thiemo Nagel (thiemo.na...@gmail.com):

> > It currently reads: "Erasing data on ${DEVICE}". Maybe something like
> > "Erasing data on ${DEVICE}. To continue without ereasing press
> > 'Cancel'." How do others feel about this?
> 
> Maybe "Skip" would be more precise than "Cancel"?

You probably can't change this as the 'Cancel' button comes from the
cdebconf interface.

> Also I think "erasing" doesn't quite hit the mark because it leads
> users to believe that the step isn't necessary for a new drive or if
> they don't care about securely deleting its previous contents. How
> about something along the lines of: "Overwriting ${DEVICE} with random
> data to prevent meta-information leaks from the encrypted volume. This
> step may be skipped at the expense of a slight reduction of the
> quality of the encryption."

Though I'm never enthusiast when rewriting debconf messages (because
it needs some translation updates, which is always a PITA with more
than 60 translations), I'm OK with that wording.



signature.asc
Description: Digital signature

Bug#723626: RFS: worklog/1.8-7 [ITA]

[Jon Daley]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "worklog", which was orphaned 
by ema@debian a while back, and due to some recent interest in the package 
by people other than myself, I've packaged up some bug fixes and 
ema@debian says he is too busy to sponsor it, and so I'm hoping someone 
else can take this on.


 * Package name: worklog
   Version : 1.8-7
   Upstream Author : trux...@truxton.com
 * URL : http://www.truxton.com/~trux/software/
 * License : Public domain
   Section : misc

  It builds those binary packages:

worklog- Keep Track of Time worked on Projects

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

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


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

dget -x 
http://mentors.debian.net/debian/pool/main/w/worklog/worklog_1.8-7.dsc

  Changes since the last upload:

  * New maintainer (Closes: #628157)
  * Fix extra second added (Closes: #548349)
  * Fix rounding error (Closes: #548347)
  * Use negative times correctly (Closes: #571718)


Thanks.


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

Bug#723180: some more testing

[Brian Silverman]

I had some time today, so I set up a QEMU VM to work on reproducing this,
and I found some interesting things. First of all, I can reproduce it
pretty consistently in the VM with this kernel (the -rt one), but I can't
reproduce it at all with linux-image-3.2.0-4-amd64 (the default Wheezy one).

Also, I've discovered 2 ways to reproduce the problem (they were both
working in the VM, but then I rebooted it and the first one stopped
working). They're both sequences of commands to enter in GDB after starting
it with the mutex_test file that I attached earlier (`gdb mutex_test`):

Version 1 (This is roughly how I first found the problem, but sometimes it
misses the kernel bug or something like that and (I think) just goes into
an infinite loop in my buggy code):
set follow-fork-mode child
b mutex_test.cpp:43
run
record
cont

Version 2 (This one seems to reproduce the kernel bug more reliably):
set detach-on-fork off
b main
run
record
cont

I also figured out the bug in my code: I had the logic flipped on whether
the fastpath atomic 0->TID succeeded, so it was calling into the kernel
when it had already locked the futex in userspace.

Bug#722604: Workaround patch

[Michael Biebl]

Am 18.09.2013 02:45, schrieb sacrificial-spam-addr...@horizon.com:
>> Or you just update to 204-4 which has been uploaded a few hours ago.
> 
> Well, yes, thank you, but it wasn't even in the BTS when I started work
> on the bug, and it still isn't on ftp.debian.org as of a few seconds
> before I send this message.
> 
> ftp> ls udev_*
> 200 PORT command successful. Consider using PASV.
> 150 Here comes the directory listing.
> -rw-r--r--1 1176 1176   760246 Sep 11 22:45 udev_204-3_amd64.deb
> -rw-r--r--1 1176 1176   744706 Sep 12 03:11 udev_204-3_armel.deb
> -rw-r--r--1 1176 1176   744204 Sep 12 00:56 udev_204-3_armhf.deb
> -rw-r--r--1 1176 1176   762282 Sep 11 23:10 udev_204-3_i386.deb
> -rw-r--r--1 1176 1176   931828 Sep 11 23:40 udev_204-3_ia64.deb
> -rw-r--r--1 1176 1176   753796 Sep 12 04:26 udev_204-3_mips.deb
> -rw-r--r--1 1176 1176  1093170 Sep 12 02:26 udev_204-3_mipsel.deb
> -rw-r--r--1 1176 1176   757232 Sep 11 23:25 udev_204-3_powerpc.deb
> -rw-r--r--1 1176 1176   756502 Sep 11 23:10 udev_204-3_s390.deb
> -rw-r--r--1 1176 1176   755510 Sep 11 23:15 udev_204-3_s390x.deb
> -rw-r--r--1 1176 1176   738086 Sep 11 23:45 udev_204-3_sparc.deb
> 226 Directory send OK.
> 
> I'll compare 204-4 when I can find a copy.

Should happen with the next mirror push, usually within 3 hours.
As for the changes, you can have a look at
http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=shortlog;h=refs/heads/debian


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



signature.asc
Description: OpenPGP digital signature

Bug#723624: libpython3.3-stdlib: upgrade to 3.3.2-6 overwrites file from libpython3.3-minimal 3.3.2-5

[Steve Cotton]

Package: libpython3.3-stdlib
Version: 3.3.2-6
Severity: serious
Justification: Policy 7.4 (the "must" is in wheezy/rc_policy.txt/Dependencies)

The upgrade from 3.3.2-5 to -6 failed the first time.  It succeeded on a later 
upgrade run, so the severity may be "normal".

Preparing to replace python3.3 3.3.2-5 (using .../python3.3_3.3.2-6_amd64.deb) 
...
Unpacking replacement python3.3 ...
Preparing to replace python3.3-minimal 3.3.2-5 (using 
.../python3.3-minimal_3.3.2-6_amd64.deb) ...
Unpacking replacement python3.3-minimal ...
Preparing to replace libpython3.3 3.3.2-5 (using 
.../libpython3.3_3.3.2-6_amd64.deb) ...
Unpacking replacement libpython3.3:amd64 ...
Preparing to replace libpython3.3-stdlib 3.3.2-5 (using 
.../libpython3.3-stdlib_3.3.2-6_amd64.deb) ...
Unpacking replacement libpython3.3-stdlib:amd64 ...
dpkg: error processing 
/var/cache/apt/archives/libpython3.3-stdlib_3.3.2-6_amd64.deb (--unpack):
 trying to overwrite 
'/usr/lib/python3.3/lib-dynload/_ssl.cpython-33m-x86_64-linux-gnu.so', which is 
also in package libpython3.3-minimal 3.3.2-5
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Preparing to replace libpython3.3-minimal 3.3.2-5 (using 
.../libpython3.3-minimal_3.3.2-6_amd64.deb) ...
Unpacking replacement libpython3.3-minimal:amd64 ...

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

Kernel: Linux 3.11.0-local-dirty (SMP w/6 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 libpython3.3-stdlib depends on:
ii  libbz2-1.01.0.6-5
ii  libc6 2.17-92+b1
ii  libdb5.1  5.1.29-7
ii  libffi6   3.0.13-4
ii  liblzma5  5.1.1alpha+20120614-2
ii  libncursesw5  5.9+20130608-1
ii  libpython3.3-minimal  3.3.2-6 (after the rerunning the upgrade)
ii  libreadline6  6.2+dfsg-0.1
ii  libsqlite3-0  3.8.0.2-1
ii  libssl1.0.0   1.0.1e-3
ii  libtinfo5 5.9+20130608-1
ii  mime-support  3.54
ii  multiarch-support 2.17-92+b1

libpython3.3-stdlib recommends no packages.

libpython3.3-stdlib 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#719847: Update and Solved sorta

[Peter Verschoor]

 I got the second quad core   processor and installed it this weekend.
I built various kernels between the 3.2.0 series and the 3.10.2 series.  I
traced the problem to a change in the file i2c-i801.c that occurred between
3.7.10 and 3.8.1 where they defaulted to enabling interrupts.  I found some
leads in the kernel forums that suggested to disable the interrupts for
that driver.  By creating a file in /etc/modprobe.d named i2c-i801.conf
with the line options i2c_i801 disable_features=0x10 the interrupts are
disabled, the problem goes away and the system loads correctly.  This
apparently disables access to the SMBus which is what is causing the
problem.

from dmesg
[clip]
[   16.754217] i801_smbus :00:1f.3: Interrupt disabled by user
[clip]

lspci reports
[clip]
00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI
Express Root Port 1 (rev 09)
00:1c.1 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI
Express Root Port 2 (rev 09)
00:1d.0 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI
USB Controller #1 (rev 09)
00:1d.1 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI
USB Controller #2 (rev 09)
00:1d.2 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI
USB Controller #3 (rev 09)
00:1d.3 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI
USB Controller #4 (rev 09)
00:1d.7 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI
USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC
Interface Controller (rev 09)
00:1f.2 IDE interface: Intel Corporation 631xESB/632xESB/3100 Chipset SATA
IDE Controller (rev 09)
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus
Controller (rev 09)
[clip]

If anybody needs more info I can get it

 I also got to test the stock kernel on the following systems all of
which work correctly.
IBM x346 2x 3.2 Xeon
SUNV20Z 2x 2.2 Opteron
DELL   1850 2x 3.2 Xeon
HP   DL380   2x 3.6 Xeon
HP   DL385   2x 2.6 Opteron dual core

Pete

Bug#722604: Workaround patch

[sacrificial-spam-address]

> Or you just update to 204-4 which has been uploaded a few hours ago.

Well, yes, thank you, but it wasn't even in the BTS when I started work
on the bug, and it still isn't on ftp.debian.org as of a few seconds
before I send this message.

ftp> ls udev_*
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
-rw-r--r--1 1176 1176   760246 Sep 11 22:45 udev_204-3_amd64.deb
-rw-r--r--1 1176 1176   744706 Sep 12 03:11 udev_204-3_armel.deb
-rw-r--r--1 1176 1176   744204 Sep 12 00:56 udev_204-3_armhf.deb
-rw-r--r--1 1176 1176   762282 Sep 11 23:10 udev_204-3_i386.deb
-rw-r--r--1 1176 1176   931828 Sep 11 23:40 udev_204-3_ia64.deb
-rw-r--r--1 1176 1176   753796 Sep 12 04:26 udev_204-3_mips.deb
-rw-r--r--1 1176 1176  1093170 Sep 12 02:26 udev_204-3_mipsel.deb
-rw-r--r--1 1176 1176   757232 Sep 11 23:25 udev_204-3_powerpc.deb
-rw-r--r--1 1176 1176   756502 Sep 11 23:10 udev_204-3_s390.deb
-rw-r--r--1 1176 1176   755510 Sep 11 23:15 udev_204-3_s390x.deb
-rw-r--r--1 1176 1176   738086 Sep 11 23:45 udev_204-3_sparc.deb
226 Directory send OK.

I'll compare 204-4 when I can find a copy.


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

Bug#723623: update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults

[jidanni]

Package: acpid
Version: 1:2.0.20-1

Setting up acpid (1:2.0.20-1) ...
update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
[ ok ] Starting ACPI services


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

Bug#722604: Workaround patch

[Michael Biebl]

Am 18.09.2013 01:30, schrieb sacrificial-spam-addr...@horizon.com:
> Control: tags 722604 + patch
> 
> udev 204-3 will work, with a hand-rolled kernel and no initramfs,
> if you do the following:

Or you just update to 204-4 which has been uploaded a few hours ago.


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



signature.asc
Description: OpenPGP digital signature

Bug#626391: venkman removal?

[David Prévot]

Hi,

On Sun, Sep 23, 2012 at 05:27:28PM +0200, intrigeri wrote:
> jon  wrote:
> > Venkman locks up when manually stepping through scripts.
> 
> Can this bug be reproduced using current Wheezy's xul-ext-venkman
> 0.9.89-1?

The question still stands (I’m not myself a venkman user).

> Arne Wichmann wrote (16 Jun 2012 20:23:34 GMT) :
> > This RC bug is now open for more than a year. Even though it is an
> > upstream bug, it might be worthwile to reconsider the situation.
> 
> Given the lack of reverse-dependencies and the relatively low popcon,
> worst case if nothing happens is, I guess, a removal from testing.

That happened almost a year ago, and upstream seems stalled: no activity
in their bug tracker, no new upstream release (so this upstream RC bug
is pretty much unlikely to ever be fixed, so this package will never
make it in stable anymore).

Given the package description (JavaScript Debugger), I guess that
firebug and webdeveloper are (packaged and upstream-maintained)
alternatives worth considering.

Would anyone disagree if we ask for its removal from unstable too?

Regards

David




signature.asc
Description: Digital signature

Bug#721649: O: libpcapnav -- wrapper to libpcap

[Eriberto]

Package was moved from SVN to GIT (collab-maint).

Please, see http://anonscm.debian.org/gitweb/?p=collab-maint/libpcapnav.git

Regards,

Eriberto


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

Bug#723592: youtube-dl: unable to download video encrypted signature 85

[shirish शिरीष]

Package: youtube-dl
Version: 2013.08.29-1
Severity: normal

Dear Maintainer,
 I was trying to download a video but it didn't work and in
fact crashed.

$ youtube-dl --verbose -c -f 22 LrUvu1mlWco
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['--verbose', '-c', '-f', '22', 'LrUvu1mlWco']
[debug] youtube-dl version 2013.08.29
[debug] Python version 2.7.5+ - Linux-3.10-3-amd64-x86_64-with-debian-jessie-sid
[debug] Proxy map: {}
[youtube] Setting language
[youtube] LrUvu1mlWco: Downloading video webpage
[youtube] LrUvu1mlWco: Downloading video info webpage
[youtube] LrUvu1mlWco: Extracting video information
[youtube] LrUvu1mlWco: Encrypted signatures detected.
[youtube] encrypted signature length 85 (43.41), itag 46, html5 player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 37, html5 player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 45, html5 player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 22, html5 player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 44, html5 player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 35, html5 player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 43, html5 player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 34, html5 player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 18, html5 player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 5, html5 player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 36, html5 player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 17, html5 player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 137, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 248, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 136, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 247, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 135, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 244, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 245, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 246, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 134, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 243, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 133, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 242, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 160, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 139, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 140, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 141, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 171, html5
player vfldJ8xgI
[youtube] encrypted signature length 85 (43.41), itag 172, html5
player vfldJ8xgI
ERROR: unable to download video
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/youtube_dl/YoutubeDL.py",
line 573, in download
videos = self.extract_info(url)
  File "/usr/lib/python2.7/dist-packages/youtube_dl/YoutubeDL.py",
line 339, in extract_info
return self.process_ie_result(ie_result, download=download)
  File "/usr/lib/python2.7/dist-packages/youtube_dl/YoutubeDL.py",
line 422, in process_ie_result
for r in ie_result['entries']
  File "/usr/lib/python2.7/dist-packages/youtube_dl/YoutubeDL.py",
line 369, in process_ie_result
self.process_info(ie_result)
  File "/usr/lib/python2.7/dist-packages/youtube_dl/YoutubeDL.py",
line 550, in process_info
raise UnavailableVideoError(err)
UnavailableVideoError: HTTP Error 403: Forbidden

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

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

Versions of packages youtube-dl depends on:
ii  python  2.7.5-4

Versions of packages youtube-dl recommends:
ii  ffmpeg  6:0.8.7-1
ii  libav-tools 6:0.8.7-1
ii  mplayer2 [mplayer]  2.0-554-gf63dbad-1+b1
ii  rtmpdump2.4+20121230.gitdf6c518-1

youtube-dl suggests no packages.

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17


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

Bug#714185: rheolef: Vcs-Svn does not work

[Pierre Saramito]

Hi Sebastian,

> From Sebastian:
> Sorry, my bad. I always forget that anonscm doesn't need svn in the
> URLs. It should be
> svn://anonscm.debian.org/debian-science/packages/rheolef/trunk/.
> 
> The rationale for the change is explained in lintian's
> vcs-fields-not-canonical tag and the referenced mail there.

Many thanks: the debian/control file is now fixed in svn,
it will be ready for the next upload together with the
forthcoming upstream release rheolef-6.5.

Regards,

Pierre
-- 
pierre.saram...@imag.fr
Directeur de Recherche CNRS
Laboratoire Jean Kuntzmann, Grenoble, France
http://www-ljk.imag.fr/membres/Pierre.Saramito


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

Bug#723611: libthunar-vfs-1-2 has broken dependencies to libxfce4util4

[Martin Krüger]

Package: libthunar-vfs-1-2
Version: 1.2.0-3+b1
Severity: normal

Dear Maintainer,

i tried to install libthunar-vfs-1-2 on amd64. That was not possible due to a  
dependency to libxfce4util4 which semms to be not existent any more in sid and 
amd64/i386. 
I solved the issue by installing the libxfce4util4 from wheezy, but in some way 
that's not what i call a root cause analysis. 

If this report should more belong to the libxfceutil4 package, could you 
forward it? 

Thanks for the help,
Martin Krüger

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

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


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

Bug#723605: dgit build does not put upstream tarball into place

[Joey Hess]

Package: dgit
Version: 0.15
Severity: normal

joey@darkstar:~/tmp/git-remote-gcrypt[sid]>dgit build
dpkg-buildpackage: source package git-remote-gcrypt
dpkg-buildpackage: source version 0.20130908-3
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Joey Hess 
dpkg-buildpackage: host architecture amd64
 dpkg-source -i\.git/ -I.git --before-build git-remote-gcrypt
 fakeroot debian/rules clean
dh clean
   dh_testdir
   debian/rules override_dh_auto_clean
make[1]: Entering directory `/home/joey/tmp/git-remote-gcrypt'
true
make[1]: Leaving directory `/home/joey/tmp/git-remote-gcrypt'
   dh_clean
 dpkg-source -i\.git/ -I.git -b git-remote-gcrypt
dpkg-source: warning: no source format specified in debian/source/format, see 
dpkg-source(1)
dpkg-source: info: using source format `1.0'
dpkg-source: warning: source directory 'git-remote-gcrypt' is not 
- 'git-remote-gcrypt-0.20130908'
dpkg-source: info: building git-remote-gcrypt in 
git-remote-gcrypt_0.20130908-3.tar.gz
dpkg-source: info: building git-remote-gcrypt in 
git-remote-gcrypt_0.20130908-3.dsc

dpkg-source was left to build a (wrong) tar.gz because dgit build did not
arrange to get the real .orig.tar.gz and put it in place. This is particularly
strange to me since I found the tarball in .git/dgit/unpack/

joey@darkstar:~/tmp/git-remote-gcrypt/.git/dgit/unpack>ls -la
total 36K
drwxr-xr-x 3 joey joey 4.0K Sep 16 16:10 ./
drwxr-xr-x 3 joey joey 4.0K Sep 16 16:10 ../
drwxr-xr-x 4 joey joey 4.0K Sep 16 16:10 git-remote-gcrypt-0.20130908/
-rw-r--r-- 1 joey joey  22K Sep 16 16:10 
git-remote-gcrypt_0.20130908.orig.tar.gz

-- 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.10-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dgit depends on:
ii  devscripts 2.13.3
ii  dpkg-dev   1.17.1
ii  git [git-core] 1:1.8.4~rc3-1
ii  libdpkg-perl   1.17.1
ii  libwww-perl6.05-1
ii  perl [libdigest-sha-perl]  5.18.1-4
ii  realpath   1.18

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:6.2p2-6

Versions of packages dgit suggests:
pn  sbuild  

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#721763: brltty grabs tty from CP2102/CP2109 device disconnecting default kernel driver

[Samuel Thibault]

Tjeerd Pinkert, le Wed 18 Sep 2013 00:15:07 +0200, a écrit :
> I have machines running Ubuntu and as a quick way of installing the
> bulk of the software I use, I have simply installed the packages on my
> Debian system that dpkg --get-selections gave on the Ubuntu system.

Ah, that explains everything: the Ubuntu way is different: they assume
brltty is to be installed on all systems, but it is not enabled by
default; while on Debian brltty is not to be installed by default, but
when installed, it is enabled by default.

Samuel


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

Bug#712095: sadt++

[James McCoy]

On Tue, Sep 17, 2013 at 01:54:53PM +0100, Ian Jackson wrote:
> I've just become aware of sadt, and of this report.  As the original
> author of autopkgtest, I would like to applaud the existence of a
> simple alternative to adt-run.

Thanks for prodding.

> Having read the docs for sadt, I can sympathise with Stuart Prescott's
> views in comment #13.
> 
> If Jakub intends to continue to maintain sadt then I think having it
> in devscripts is a really good idea.

Agreed.  Jakub, do you want to handle adding this to devscripts?

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


signature.asc
Description: Digital signature

Bug#719659: acpid 2.0.20 released

[Ted Felix]

  This has been fixed in acpid 2.0.20 just released today.

http://sourceforge.net/projects/acpid2


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

Bug#554976:

[Jackson Doak]

 dh_autoreconf should fix this, i'll work on it this week.


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

Bug#723622: php-wikidiff2: Configuration sent as output instead of executing

[Matthew Gabeler-Lee]

Package: php-wikidiff2
Version: 0.0.1+svn109581-1+b1
Severity: important

Using a default installation of Debian testing, with Apache 2.4, the
contents of /etc/mediawiki-extensions/extensions-available/wikidiff2.php are
being sent as output instead of executing.  AFAICT, this is because the file
starts with "

Bug#722761: coinor-osi link with -L/usr/lib

[Miles Lubin]

Dear YunQiang,

I am currently in the process of updating and adopting this package. I
believe this specific issue is fixed in the new version, which will be
available soon in the experimental distribution. When it is uploaded,
I will ask you to test and confirm the issue is fixed.


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

Bug#722604: Workaround patch

[sacrificial-spam-address]

Control: tags 722604 + patch

udev 204-3 will work, with a hand-rolled kernel and no initramfs,
if you do the following:

1. Enable CONFIG_DEVTMPFS=y.  DEVTMPFS_MOUNT is not required.
2. Apply the following patch to /etc/init.d/udev.

There are five parts to this patch:

1. Add the quotes to `mount -n -o "$dev_mount_options"` so that an empty
   $dev_mount_options string will not produce a syntax error.
2. Change from mounting tmpfs on /dev to devtmpfs
3. Check for the existence of devtmpfs in /proc/filesystems
4. Update error messages to reflect devtmpfs
5. Update comments and rename the "mount_tmpfs" shell function to
   "mount_devtmpfs" to reflect the preceding change.  This part is
   purely cosmetic.

--- /etc/init.d/udev.dpkg-dist  2013-09-17 18:42:58.0 -0400
+++ /etc/init.d/udev2013-09-17 18:58:50.0 -0400
@@ -8,7 +8,7 @@
 # Short-Description: Start udevd, populate /dev and load drivers.
 ### END INIT INFO
 
-# we need to unmount /dev/pts/ and remount it later over the tmpfs
+# we need to unmount /dev/pts/ and remount it later over the devtmpfs
 unmount_devpts() {
   if mountpoint -q /dev/pts/; then
 umount -n -l /dev/pts/
@@ -19,15 +19,15 @@
   fi
 }
 
-# mount a tmpfs over /dev, if somebody did not already do it
-mount_tmpfs() {
+# mount a devtmpfs over /dev, if somebody did not already do it
+mount_devtmpfs() {
   if grep -E -q "^[^[:space:]]+ /dev (dev)?tmpfs" /proc/mounts; then
-mount -n -o remount,${dev_mount_options} -t tmpfs tmpfs /dev
+mount -n -o remount,${dev_mount_options} -t devtmpfs devtmpfs /dev
 return
   fi
 
-  if ! mount -n -o $dev_mount_options -t devtmpfs devtmpfs /dev; then
-log_failure_msg "udev requires tmpfs support, not started"
+  if ! mount -n -o "$dev_mount_options" -t devtmpfs devtmpfs /dev; then
+log_failure_msg "udev requires devtmpfs support, not started"
 log_end_msg 1
   fi
 
@@ -113,8 +113,8 @@
   log_end_msg 1
 fi
 
-if ! grep -q '[[:space:]]tmpfs$' /proc/filesystems; then
-  log_failure_msg "udev requires tmpfs support, not started"
+if ! grep -q '[[:space:]]devtmpfs$' /proc/filesystems; then
+  log_failure_msg "udev requires devtmpfs support, not started"
   log_end_msg 1
 fi
 
@@ -165,7 +165,7 @@
 
 if [ -z "$TMPFS_MOUNTED" ]; then
unmount_devpts
-   mount_tmpfs
+   mount_devtmpfs
[ -d /proc/1 ] || mount -n /proc
 fi
 

More changes would be desirable, such as actually using the $tmpfs_size
variable, using $udev_root consistently, etc.

I'd also really appreciate more details in the error message about
running /etc/init.d/udev from a tty explaining exactly what will
happen instead of what I expect.

I also wonder if the test on that warn_if_interactive is correct.
It skips the test if /dev/.udev exists or if /run/udev exists.
Isn't that exactly the case that udev is already running, when you
*do* want the test?  And skip it if udev *isn't* running?

-if [ ! -e "$udev_root/.udev/" -a ! -e "/run/udev/" ]; then
+if [ -d "$udev_root/.udev/" -o -d /run/udev/ ]; then


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

Bug#721566: qupzilla: FTBFS on kfreebsd-amd64: fprintf and stderr not declared

[Aaron M. Ucko]

found 721566 1.4.4-1
thanks

The problem is now with cerr:

  main.cpp:129:2: error: 'cerr' is not a member of 'std'

I see main.cpp includes  only under Linux at present.  Please
have it do so unconditionally, and consider enabling the signal handlers
for other platforms as well.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu


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

Bug#723621: cubemap: FTBFS on non-Linux: needs epoll, SO_MARK, maybe other Linuxisms

[Aaron M. Ucko]

Source: cubemap
Version: 1.0.0-1
Severity: serious
Justification: fails to build from source

The kFreeBSD and Hurd builds of cubemap have been failing:

  server.h:7:23: fatal error: sys/epoll.h: No such file or directory
   #include 
 ^
  compilation terminated.
  client.cpp: In constructor 'Client::Client(const ClientProto&, Stream*)':
  client.cpp:77:35: error: 'SO_MARK' was not declared in this scope

Please either fix cubemap to make do without these APIs if necessary
or explicitly declare its architecture to be linux-any.

Thanks!


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

Bug#723619: cubemap: FTBFS on 32-bit Linux: off_t* vs. loff_t in call to sendfile

[Aaron M. Ucko]

Source: cubemap
Version: 1.0.0-1
Severity: serious
Justification: fails to build from source

Builds of cubemap on 32-bit Linux have been failing:

  server.cpp:436:72: error: cannot convert 'loff_t* {aka long long int*}' to 
'off_t* {aka long int*}' for argument '3' to 'ssize_t sendfile(int, int, 
off_t*, size_t)'

Please change offset's type to off_t per sendfile's actual prototype.

Thanks!


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

Bug#723620: mediawiki: Default installation does not work (Apache 2.4 problem)

[Matthew Gabeler-Lee]

Package: mediawiki
Version: 1:1.19.8+dfsg-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Installed clean new Debian wheezy system.  Installed Apache 2.4 with default
options.  Installed mediawiki with default options.  Enabled mediawiki
apache configuration, including alias configuration.  Attempted to access
http://localhost/mediawiki/

   * What was the outcome of this action?

Attempting to access the page produces a 403 Forbidden error, and this
message in the apache error log:
AH01630: client denied by server configuration: /var/lib/mediawiki/

   * What outcome did you expect instead?

Default install should work!

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

The problem seems to do with the change in syntax for Apache 2.4 allow/deny
rules.  Prior bug#669832 mentions a fix that worked for me (change in the
allow/deny syntax in /etc/mediawiki/apache.conf).  However, that bug was
marked closed without such a fix being applied to the mediawiki package.

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

Kernel: Linux 3.9.2 (SMP w/12 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#723604: Please remove me from uploaders

[Luk Claes]

Package: mailutils
Severity: wishlist

Hi Jordi

As I've lost interest in mailutils packaging, please remove me from uploaders.

Cheers

Luk


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

Bug#723615: dillo: mailcap for image/png,gif,jpeg

[Kevin Ryde]

Package: dillo
Version: 3.0.3-6
Severity: wishlist

As a suggestion, dillo could helpfully have /etc/mailcap entries for
image/gif, image/png and image/jpeg since it can display those.  Various
other browsers such as iceape have such entries.  Perhaps something like
the debian/mime file below (to become /usr/lib/mime/packages/dillo).

Currently update-mime crunches /usr/share/applications/dillo.desktop
"MimeType" into an /etc/mailcap entry

text/xml; dillo %s; test=test -n "$DISPLAY"

Is this generic XML?  Does dillo do anything with that, or does text/xml
mean xhtml?  If so then an entry for that in this mime file, or if not
then maybe dillo.desktop would be reduced.

# Dillo 3.0.3 requires HTML or XHTML in a filename "foo.html", hence
# nametemplate here for use when "see" reads stdin or similar.
# Other filenames such as "foo.xhtml" are taken to be plain text and
# displayed raw.
#
# ENHANCE-ME: Is there an option to dillo to force it to take an
# arbitrary filename as html or as the image types below?
#
text/html; /usr/bin/dillo %s; description=HTML Text;  test=test -n 
"$DISPLAY"; nametemplate=%s.html
application/xhtml+xml; /usr/bin/dillo %s; description=XHTML Text; test=test -n 
"$DISPLAY"; nametemplate=%s.html

# Dillo 3.0.3 uses the .gif etc in the filename to determine the image
# type.  So for instance a gif file called foo.png is not displayed.
# Hence nametemplate here for use when "see" reads stdin or similar.
#
# "priority=2" for images here the same as other web browsers and
# below dedicated image viewer programs at default priority=5.
# Dillo 3.0.3 can only display gif, png and jpeg (see its DIC_Gif etc
# enum in src/dicache.c).
#
image/png;  /usr/bin/dillo %s; description=PNG Image;  test=test -n "$DISPLAY"; 
nametemplate=%s.png;  priority=2
image/jpeg; /usr/bin/dillo %s; description=JPEG Image; test=test -n "$DISPLAY"; 
nametemplate=%s.jpeg; priority=2
image/gif;  /usr/bin/dillo %s; description=GIF Image;  test=test -n "$DISPLAY"; 
nametemplate=%s.gif;  priority=2



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-486
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages dillo depends on:
ii  libc62.17-92
ii  libfltk1.3   1.3.2-3
ii  libgcc1  1:4.6.1-3
ii  libjpeg8 8d-1
ii  libpng12-0   1.2.49-4
ii  libssl1.0.0  1.0.1e-3
ii  libstdc++6   4.6.1-3
ii  libx11-6 2:1.6.1-1
ii  wget 1.14-2
ii  zlib1g   1:1.2.8.dfsg-1

Versions of packages dillo recommends:
ii  perl  5.14.2-21
ii  perl-modules  5.14.2-21

dillo suggests no packages.

-- no debconf information

Bug#723614: netsurf-gtk: /etc/mailcap of filenames

[Kevin Ryde]

Package: netsurf-gtk
Version: 2.9-2
Severity: normal

mime-support turns /usr/share/applications/netsurf-gtk.desktop into
entries in /etc/mailcap like

text/html; netsurf-gtk %s; test=test -n "$DISPLAY"

but they don't work since netsurf requires a url on the command line,
not a filename.

I see bug 577136 asks for filenames on the command line, but unless or
until that's done then perhaps a debian/mime file (to become
/usr/lib/mime/packages/netsurf-gtk) like below.  It uses liburi-perl for
filename->uri, which would create a dependency on that package.
Or perhaps there's an easier way.

# Netsurf takes a URI on the command line.  Must turn a filename into
# file://... including escaping any "%"s in the filename etc.

text/html; /usr/bin/netsurf-gtk `perl -MURI::file -e 'print 
URI::file->new_abs($ARGV[0])' %s`; description=HTML Text; test=test -n 
"$DISPLAY"
application/xhtml+xml; /usr/bin/netsurf-gtk `perl -MURI::file -e 'print 
URI::file->new_abs($ARGV[0])' %s`; description=XHTML Text; test=test -n 
"$DISPLAY"
text/xml;  /usr/bin/netsurf-gtk `perl -MURI::file -e 'print 
URI::file->new_abs($ARGV[0])' %s`; description=XML Text; test=test -n "$DISPLAY"

# "priority=2" for images here the same as other web browsers use and
# which is below dedicated image viewer programs at default priority=5.
# Types GIF,PNG,JPEG same as /usr/share/applications/netsurf-gtk.desktop.
# Also ms-dos BMP works.
#
image/png;  /usr/bin/netsurf-gtk `perl -MURI::file -e 'print 
URI::file->new_abs($ARGV[0])' %s`; description=PNG Image;  test=test -n 
"$DISPLAY"; priority=2
image/jpeg; /usr/bin/netsurf-gtk `perl -MURI::file -e 'print 
URI::file->new_abs($ARGV[0])' %s`; description=JPEG Image; test=test -n 
"$DISPLAY"; priority=2
image/gif;  /usr/bin/netsurf-gtk `perl -MURI::file -e 'print 
URI::file->new_abs($ARGV[0])' %s`; description=GIF Image;  test=test -n 
"$DISPLAY"; priority=2
image/x-ms-bmp; /usr/bin/netsurf-gtk `perl -MURI::file -e 'print 
URI::file->new_abs($ARGV[0])' %s`; description=BMP Image;  test=test -n 
"$DISPLAY"; priority=2


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-486
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages netsurf-gtk depends on:
ii  libc6   2.17-92
ii  libcairo2   1.12.2-3
ii  libcurl37.32.0-1
ii  libgdk-pixbuf2.0-0  2.28.2-1
ii  libglade2-0 1:2.6.4-1
ii  libglib2.0-02.36.4-1
ii  libgtk2.0-0 2.24.20-1
ii  libjpeg88d-1
ii  libpango1.0-0   1.32.5-5+b1
ii  libpng12-0  1.2.49-4
ii  librsvg2-2  2.36.4-2
ii  libssl1.0.0 1.0.1e-3
ii  libxml2 2.9.1+dfsg1-3
ii  netsurf-common  2.9-2
ii  zlib1g  1:1.2.8.dfsg-1

Versions of packages netsurf-gtk recommends:
ii  mime-support  3.54

netsurf-gtk suggests no packages.

-- no debconf information

Bug#720785: tagging 720785, tagging 662323, tagging 684149

[Lionel Le Folgoc]

Hi Sebastian,

On Mon, Sep 16, 2013 at 06:40:48PM +0200, Sebastian Ramacher wrote:
> Hi Lionel,
> 
> On 2013-09-15 22:25:38, Lionel Le Folgoc wrote:
> > I'd appreciate your help to upload it: the packaging is available at
> >  and you can
> > also dget
> > .
> > It builds fine in a clean sid chroot and I've been using it for some
> > time and it works fine here.  If you don't have time or are not able to
> > do it, no problem, I'll upload it to debian-mentors and search for a
> > sponsor there.
> > Thanks!
> 
> Looks good to me except for the following two issues:
> 
>  - Current Standards-Version is 3.9.4. Please check what has changed
>between 3.9.2 and 3.9.4 and update the package accordingly.
>  - lintian emits
> 
> W: libffmpegthumbnailer4: hardening-no-relro 
> usr/lib/libffmpegthumbnailer.so.4.0.8
> W: ffmpegthumbnailer: hardening-no-relro usr/bin/ffmpegthumbnailer
> 
>Please have a look at these warnings.
> 
> Please let me know once the issues are fixed and I'll upload the package
> for you.
> 

I've done the changes needed so these issues should be fixed (same urls
as above).  Thanks for your help.

Best,
-- 
Lionel


signature.asc
Description: Digital signature

Bug#723312: fmtools link with -L/usr/lib

[Ben Pfaff]

On Tue, Sep 17, 2013 at 06:34:35PM +0800, YunQiang Su wrote:
> Package: fmtools
> Version: 2.0.6
> X-Debbugs-CC: wzss...@gmail.com
> 
> This package has one or more -L/usr/lib in its build system,
> which will make it ftbfs if there is libraries under /usr/lib,
> while is not the default architecture, mips* for example.
> 
> On mips* systems, /usr/lib is defined as place to hold O32
> libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.
> 
> Beside the way, on the multiarch system like Debian, user may install
> libraries under /usr/lib by hand.
> 
> Please use the default search path if you can, and please consider fix
> this.
> 
> I will try to fix this bug, while if you can help to fix it, 
> It will be very appreciative.

I don't understand your description of the bug.  The failure in your
attached build log is:

make[2]: *** No rule to make target `test-fm.at', needed by 
`testsuite'.  Stop.

What does this have to do with -L/usr/lib?  Furthermore, the string
/usr/lib doesn't appear in the build log anywhere.


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

Bug#723613: udev in jessie requires a kernel with CONFIG_DEVTMPFS=y

[Michael Biebl]

Package: release-notes
Severity: normal
Tags: jessie

udev 176 and newer requires a kernel with devtmpfs support since it no
longer creates any device nodes itself [1].
The Debian provided kernels in wheezy and jessie do have CONFIG_DEVTMPFS=y
already, so are not affected by this change. Users with self-compiled
kernels should check their kernel configuration and update if needed.

We should add a section about this new kernel requirement to the jessie
release notes.


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

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

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


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

Bug#723616: gyp command does not work. needs python-pkg-resources

[Nobuhiro Iwamatsu]

Package: gyp
Version: 0.1~svn1729-1
Severity: serious
Tags: patch

Dear Maintainer,

When exectute gyp commands, I got errer message following:

$ gyp 
Traceback (most recent call last):
 File "/usr/bin/gyp", line 5, in 
 from pkg_resources import load_entry_point


gyp requires python-pkg-resources.
Please add python-pkg-resources to Depends.

Best regards,
  Nobuhiro

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

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

Versions of packages gyp depends on:
ii  python  2.7.5-5

gyp recommends no packages.

gyp suggests no packages.

-- no debconf information
diff -Nru gyp-0.1~svn1729/debian/changelog gyp-0.1~svn1729/debian/changelog
--- gyp-0.1~svn1729/debian/changelog	2013-09-17 08:55:50.0 +0900
+++ gyp-0.1~svn1729/debian/changelog	2013-09-18 08:05:58.0 +0900
@@ -1,3 +1,10 @@
+gyp (0.1~svn1729-1.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Add python-pkg-resources to Depends.
+
+ -- Nobuhiro Iwamatsu   Wed, 18 Sep 2013 08:05:42 +0900
+
 gyp (0.1~svn1729-1) unstable; urgency=low
 
   * Upstream update svn revision 1729. (Closes: #722678)
diff -Nru gyp-0.1~svn1729/debian/control gyp-0.1~svn1729/debian/control
--- gyp-0.1~svn1729/debian/control	2013-07-23 07:59:30.0 +0900
+++ gyp-0.1~svn1729/debian/control	2013-09-18 08:05:39.0 +0900
@@ -10,7 +10,7 @@
 
 Package: gyp
 Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
+Depends: ${python:Depends}, ${misc:Depends}, python-pkg-resources
 Description: Cross-platform build script generator
  GYP (Generate Your Projects) is a tool to generate native Visual Studio,
  Xcode, SCons and make build files from a description of a project in a

Bug#723593: New version available (1.5.1)

[Marcelo Jorge Vieira]

Package: python-django-tinymce
Version: 1.5-3
Severity: wishlist


A new version of django-tinymce is available, please consider
packaging it ;)

Thanks for your work.


Cheers,

-- 
Marcelo Jorge Vieira
xmpp:me...@jabber-br.org
http://metaldot.alucinados.com


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

Bug#723143: debian-edu-doc: should provide images downscaled to max width 800

[David Prévot]

Control: tags -1 confirmed

Hi Wolfgang,

On Mon, Sep 16, 2013 at 10:18:58PM +0200, Wolfgang Schweer wrote:
> 
> on the wiki the images are forced to a maximum width of 800. The HTML
> manual version contains images with a width far beyond that size.
> 
> To be able to ship the images in d-e-doc with a max width of 800 too,
> the attached patch could be applied.

Thanks for your feedback and for your patch. As agreed on IRC with you
and Holger, we’ll look at including such a change in the Jessie branch
instead of introducing a build change a few days before we release
Wheezy.

> +   for i in $$LANGPATH/images/*.png ; do \
> + if [ -f $$i ] ; then \
> + convert $$i -resize 800\> $$i ; \
> + fi ; \
> +   done ; \

Instead of degrading the image quality while resizing it directly, I’d
prefer to just display it with a reduced size, as done in the wiki
(). I don’t know yet how to introduce that with
our DocBook sources, but we’ll see.

> + cd $(DESTDIR)/debian-edu-doc-en/$(DESTPATH)/debian-edu-doc-en ; \
> +   for i in images/*.png ; do \
> + convert $$i -resize 800\> $$i ; \
> +   done ; \

That should not be needed: we already take care of the images size of
the PDF in documentation/common/pdf.xsl:

maxwidth=15.5cm,maxheight=12cm

Regards

David




signature.asc
Description: Digital signature

Bug#721763: brltty grabs tty from CP2102/CP2109 device disconnecting default kernel driver

[Tjeerd Pinkert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15-09-13 21:22, Samuel Thibault wrote:
> Tjeerd Pinkert, le Tue 03 Sep 2013 22:30:18 +0200, a ￩crit :
>> brltty unexpectedly replaced the default kernel driver with it's
>> own USB Braille terminal driver. Since the Seika Braille reader
>> uses the CP2102/CP2109 default vid/pid, brltty addressed the SPEC
>> board as such.
> 
> Yes, this is unfortunately *expected*, actually.

I conclude, only if the user installed brltty (which is assumed to be
on purpose).

>> To resolve the issue I uninstalled the brltty package.
> 
> Yes, that's the proper way currently.  What we would need to
> understand is how brltty got installed on your system.  We don't
> expect systems without a braille device to have brltty installed.
> That way, we can make some of these nasty devices actually work
> easily without workarounds.  The bug really is why brltty ended up
> being installed on your computer.

Uhm, yes, good question (blush). There are two possible answers.

I have machines running Ubuntu and as a quick way of installing the
bulk of the software I use, I have simply installed the packages on my
Debian system that dpkg --get-selections gave on the Ubuntu system.

While uninstalling brltty on the Ubuntu system I got the message:
- ---
The following actions will resolve these dependencies:

 Remove the following packages:
1) brltty-x11

 Leave the following dependencies unresolved:
2) ubuntu-desktop recommends brltty
- ---
so it might have been installed by default on Ubuntu 12.04 LTS?  A
second Ubuntu system had the brltty package installed too, no *brl*
processes running, no ubuntu-desktop dependency complaint on removal.

A second possibility is that I might have pulled the package in
(having to install new systems lately, going through the huge package
list and installing all what seems usefull) myself on the Ubuntu side
and then having applied the above copy action.

To be sure about this I would need to either reinstall, or find a way
of seeing what Ubuntu installs as a minimum. Most probably I'm the
fault here.

So this means the bug could be closed for Debian, since it is not a
fault in the distro, and most probably caused by myself installing
something I should not have done, although there is a real problem
with some devices which would have solved this on forehand in an ideal
world.

>> I have had contact with: The devellopers, among others Eric van
>> der Bij and Tomasz Wlostowski, of the SPEC board, whose strong
>> conviction is that the default kernel driver should be used to
>> yield a ttyUSB device, and that changing to a custom vid/pid for
>> this harware will cause confusion.
> 
> Why would this cause confusion?  This vid/pid designates a serial
> port converter.  Using another vid/pid to more precisely describe
> the device would be useful.

The chip (on the SPEC) is used as serial port, so the defaults are
correct.

> Anyway, the SPEC board is not an isolated case.  Whatever serial
> device, which a user would connect through a USB-to-serial
> converter, would have just the same issue. Which is crazily crazy.
> USB has *given* us a way for a device to identify itself in a
> perfectly safe way, and thus permits to have real safe plug&play
> support, which was an extremely great addition for the 
> accessibility of the debian installer, for instance.

Indeed, one could say it is a manufacturer induced problem, if a
device is not meant to be a serial port.

> Yes, we can't do anything for the already-produced devices, we'll
> have to live with them.  It'd however be really good to manage to
> convince Seika & such that having a separate vid/pid is a really
> important detail for accessibility everywhere on the long term.

That would be best indeed... I have notified them of the bug report
here. I hope it is picked up. Maybe active contact from the actual
user community would help here?

>> My expectation of the outcome is: the default kernel driver
>> being respected for the default vid/pid of USB to serial
>> convertors, but a possibility to enable the use of brltty if
>> needed will be provided. If possible, clear communication to the
>> blind users of brltty is given on forehand, that specific devices
>> will become disabled because of this issue.
> 
> This is actually already what we have: brltty is not supposed to
> be installed on usual systems, and blind users know that they have
> to install brltty (or get it automatically installed by the
> installer run in braille mode) in order to get their braille device
> working.

I would argue differently, it can get installed somehow... However,
the (Debian?) view on the issue is more clear and I think the bug can
thus be closed.

Tjeerd
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlI41GoACgkQ9xQaBfeouapDaQCfc2IMZ7WQ9EiOE/7bbU7yVHSy
p3cAnixaq8s71iWzEJ

Bug#723483: lua5.1 link with -L/usr/lib

[Enrico Tassi]

On Tue, Sep 17, 2013 at 06:48:59PM +0800, YunQiang Su wrote:
> Package: lua5.1
> Version: 5.1.5-5
> X-Debbugs-CC: wzss...@gmail.com
> 
> This package has one or more -L/usr/lib in its build system,

True, and the .pc file is also wrong and this percolates to all
other lua libraries.

Cheers
-- 
Enrico Tassi


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

Bug#723605: dgit build does not put upstream tarball into place

[Ian Jackson]

retitle 723605 docs should discuss files downloaded to ..
thanks

Joey Hess writes ("Bug#723605: dgit build does not put upstream tarball into 
place"):
> Ian Jackson wrote:
> > I think dgit fetch probably downloaded it earlier.  Is it possible
> > that you deleted it yourself between fetch and build ?
> 
> Very likely, yes.

Right.  I'm afraid I think this is poor documentation (or, if you
prefer, user error).  You shouldn't delete the things that dgit leaves
in the parent directory (unless you know they're not going to be
needed).

It would be nice if dgit would operate a cache, but the files in the
.git/dgit directory aren't a cache because that directory is
frequently wiped.

But thanks for the report.

Ian.


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

Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386

[Thomas Orgis]

Am Sat, 31 Aug 2013 16:02:45 +0200
schrieb Reinhard Tartler : 

> The attached patch seems to do the right thing on Debian
> kFreeBSD/i386, i386 and amd64. I've therefore uploadedit to Debian
> unstable.

Sadly, that patch still is not quite right. Now Linux/i386 mixes long
and off_t with 64 bit. The solution is to frame the declarations of the
aliased functions with alias_t, which is long in this case, not off_t.
Applying the attached patch in addition should fix this for all debian
variants. This version is going to be released as 1.16.0 soon, and
upgrading to this one highly recommened. Of course, any testing
insights before release are welcome, too, best using the full thing from

http://mpg123.org/snapshot

Performance should be considerably improved, too.


Alrighty then,

Thomas
Index: src/libmpg123/mpg123lib_intern.h
===
--- src/libmpg123/mpg123lib_intern.h	(Revision 3398)
+++ src/libmpg123/mpg123lib_intern.h	(Revision 3399)
@@ -16,30 +16,8 @@
 #include "config.h" /* Load this before _anything_ */
 #include "intsym.h" /* Prefixing of internal symbols that still are public in a static lib. */
 
-/* ABI conformance for other compilers.
-   mpg123 needs 16byte-aligned stack for SSE and friends.
-   gcc provides that, but others don't necessarily. */
-#ifdef ABI_ALIGN_FUN
-#ifndef attribute_align_arg
-#if defined(__GNUC__) && (__GNUC__ > 4 || __GNUC__ == 4 && __GNUC_MINOR__>1)
-#define attribute_align_arg __attribute__((force_align_arg_pointer))
-/* The gcc that can align the stack does not need the check... nor does it work with gcc 4.3+, anyway. */
-#else
+#include "abi_align.h"
 
-#define attribute_align_arg
-/* Other compilers get code to catch misaligned stack.
-   Well, except Sun Studio, which accepts the aligned attribute but does not honor it. */
-#if !defined(__SUNPRO_C)
-#define NEED_ALIGNCHECK
-#endif
-
-#endif
-#endif
-#else
-#define attribute_align_arg
-/* We won't try the align check... */
-#endif
-
 /* export DLL symbols */
 #if defined(WIN32) && defined(DYNAMIC_BUILD)
 #define BUILD_MPG123_DLL
Index: src/libmpg123/lfs_alias.c
===
--- src/libmpg123/lfs_alias.c	(Revision 3398)
+++ src/libmpg123/lfs_alias.c	(Revision 3399)
@@ -39,10 +47,6 @@
 
 #if _FILE_OFFSET_BITS+0 == LFS_ALIAS_BITS
 
-/* The native functions are actually _with_ suffix, so let the mpg123 header use large file hackery to define the correct interfaces. */
-#include "mpg123.h"
-/* Don't forget to undef the function symbols before usage... */
-
 /* The native functions have suffix, the aliases not. */
 #define NATIVE_SUFFIX MACROCAT(_, _FILE_OFFSET_BITS)
 #define NATIVE_NAME(func) MACROCAT(func, NATIVE_SUFFIX)
@@ -50,10 +54,6 @@
 
 #else
 
-/* Native functions are without suffix... */
-#define MPG123_NO_LARGENAME
-#include "mpg123.h"
-
 /* The alias functions have suffix, the native ones not. */
 #define ALIAS_SUFFIX MACROCAT(_, LFS_ALIAS_BITS)
 #define ALIAS_NAME(func) MACROCAT(func, ALIAS_SUFFIX)
@@ -61,9 +61,14 @@
 
 #endif
 
-/* Now get the rest of the infrastructure on speed, namely attribute_align_arg, to stay safe. */
-#include "mpg123lib_intern.h"
+/* Copy of necessary definitions, actually just forward declarations. */
+struct mpg123_handle_struct;
+typedef struct mpg123_handle_struct mpg123_handle;
 
+
+/* Get attribute_align_arg, to stay safe. */
+#include "abi_align.h"
+
 /*
 	Extract the list of functions we need wrappers for, pregenerating the wrappers for simple cases (inline script for nedit):
 perl -ne '
@@ -85,9 +90,7 @@
 	$nargs = "Human: figure me out." if($nargs =~ /\(/);
 	print  4 || __GNUC__ == 4 && __GNUC_MINOR__>1)
+#define attribute_align_arg __attribute__((force_align_arg_pointer))
+/* The gcc that can align the stack does not need the check... nor does it work with gcc 4.3+, anyway. */
+#else
+
+#define attribute_align_arg
+/* Other compilers get code to catch misaligned stack.
+   Well, except Sun Studio, which accepts the aligned attribute but does not honor it. */
+#if !defined(__SUNPRO_C)
+#define NEED_ALIGNCHECK
+#endif
+
+#endif
+#endif
+#else
+#define attribute_align_arg
+/* We won't try the align check... */
+#endif
+
+#endif


signature.asc
Description: PGP signature

Bug#723520: kmix: KMix 4.3 on KDE 4.10.5 leaks memory

[Kitty Box]

I've done as instructed by the previous commenter I note changes are listed
on the bug report page to solve this issue.

Kitty


On Tue, Sep 17, 2013 at 11:49 PM, Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> wrote:

> tags 723520 upstream
> thanks
>
> Hello,
>
> the bug you reported is a KDE bug. Please report it via
> Help -> Report bug... menu item of the respective application
> or by visiting https://bugs.kde.org/ and following instructions
> to report a new bug.
>
> Debian Qt/KDE maintainers do not have resources to deal with
> non Debian-specific bugs and therefore it is unlikely that
> your bug will be solved if you do not report it to KDE developers
> directly (unless it is/has been reported by somebody else).
>
> Whenever you open a bug report on the KDE bug tracking system, or
> you find that the bug has been already reported on it, you can couple
> both this Debian bug and the KDE bug together by sending the mail with
> the text below to cont...@bugs.debian.org (replace KDE-BUG-URL with
> the address of the bug report on https://bugs.kde.org/)
>
> [ copy this ]
> forwarded 723520 KDE-BUG-URL
> thanks
> [ copy this ]
>
> Thank you,
> --
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
>

Bug#722960: [pkg-horde] Bug#722960: [php-horde] hook uses /usr/bin/grep instead of /bin/grep

[Mathieu Parent]

forwarded 722960 https://github.com/horde/horde/pull/63
tag 722960 + confirmed patch
thanks

2013/9/14 Lars Kruse :

> The file /etc/horde/horde/hooks.php contains a reference to /usr/bin/grep
> instead of the correct path /bin/grep.
>
> An error message is visible when running "horde-alarms":
>  sh: 1: /usr/bin/grep: not found
>
> Additionally the same error message appears periodically in the error log of 
> the
> webserver.
Thanks for your report.

I have proposed a fix upstream: https://github.com/horde/horde/pull/63

I will patch the package itself in the meantime (if I have time).

Regards
-- 
Mathieu


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

Bug#723569: transition: evolution-data-server 3.8 ready to start?!

[Andreas Henriksson]

Hello!

On Tue, Sep 17, 2013 at 04:04:56PM +0200, Michael Biebl wrote:
[...]
> The rough plan looks like this
> - Upload libgweather 3.8 and gtkhtml 4.6 to unstable (ready in
>   experimental)
> - Upload evolution-data-server 3.8 to unstable (ready in experimental)
> - Upload evolution 3.8, folks 0.9 and telepathy-farstream 0.6 to
>   unstable (ready in experimental)

Following mbiebls excellent laid out plan. It's been smooth sailing so far
and I've built the above packages. I'm ready to sign and upload.

Does anyone see any reason to not start this transition right away?

> - binNMU above packages
> - upload or remove the remaining packages:
[...]

(I've already posted my removal suggestions and I have a rough plan
for how to deal with the rest. I probably need to figure out a few details
along the way. I'll get back to you with binNMU requests.)

-- 
Andreas Henriksson


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

Bug#723198: udevd not copied to initrd, system unbootable

[Michael Biebl]

severity 723198 important
thanks

Am 17.09.2013 17:55, schrieb Michael Biebl:
> tags 723198 + moreinfo unreproducible
> thanks
> 
> Am 17.09.2013 14:38, schrieb Michael Biebl:
>> Can you attach the output of
>> "grep udevd /usr/share/initramfs-tools -R"
> 
> I've checked all packages installing an initramfs hook.
> None of that calls udevd directly:
> 
> # grep udevd /usr/share/initramfs-tools/ -R
> /usr/share/initramfs-tools/scripts/init-bottom/udev:# Stop udevd, we'll miss 
> a few events while we run init, but we catch up
> /usr/share/initramfs-tools/scripts/init-top/udev:/lib/systemd/systemd-udevd 
> --daemon --resolve-names=never
> /usr/share/initramfs-tools/scripts/functions: if command -v udevd >/dev/null 
> 2>&1; then
> /usr/share/initramfs-tools/hooks/udev:copy_exec /lib/systemd/systemd-udevd
>   /lib/systemd
> 
> 
> So I'm having a hard time reproducing the problem you are seeing.
> Can you attach a more verbose error log from your boot process?

Downgrading severity since the problem is not reproducible and no
further information was provided so far.


Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#723569: transition: evolution-data-server 3.8 removal candidates

[Andreas Henriksson]

Hello!

I've assembled a list of removal candidates:

evolution-mapi (FTBFS fixed in 3.8.5-1 from exp, blocked by samba4 / samba 
reunification, RM from testing for the time being)
evolution-exchange (FTBFS, dead upstream, superseded by evolution-ews, RM bug 
filed)
evolution-webcal (FTBFS, , unmaintained, dead upstream RM?)
dates (FTBFS) dropped in Ubuntu
eweouz (FTBFS) dropped in Ubuntu
hdate-applet (FTBFS) dropped in Ubuntu
ruby-revolution (FTBFS) dropped in Ubuntu
tasks (FTBFS) dropped in Ubuntu
sflphone (FTBFS - conflicting b-deps)
 http://bugs.debian.org/716855
syncevolution (FTBFS) needs upgrading to 1.2.99.4
jana (FTBFS - missing b-dep on libgconf2-dev)
gnome-phone-manager (FTBFS)
 https://launchpad.net/ubuntu/+source/gnome-phone-manager/+changelog


If anyone think it's worth delaying the transition over any of these,
please speak up (or even better send a fix to the package bug report).

-- 
Andreas Henriksson


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

Bug#723580: kytea: bad package description

[Justin B Rye]

Package: kytea
Version: 0.4.6+dfsg-2
Severity: wishlist
Tags: patch

This package has a terrible package description.  (I'm still only
calling this a wishlist bug, though.)

> Package: kytea
[...]
> Description: morphological analysis system with pointwise predictors

Not bad, but the implementation details aren't worth putting in the
synopsis.  What it does need to establish in the synopsis is that this
is for morphological analysis in the linguistic sense, rather than the
biological or marketing senses - see:
http://en.wikipedia.org/wiki/Morphological_analysis
The easy way to do that is to insert the word "text".

>  KyTea is morphological analysis system based on pointwise predictors.
   ^
Missing article: KyTea is *a* morphological analysis system.

Implementation details are okay here, but talking about "pointwise
predictors" is excruciatingly esoteric.  "Pointwise classifier" is
already specialist jargon; and stretching it you can talk about
pointwise classifier-based analyses making "pointwise predictions"
(though it's rather weird to talk about morphological judgements as
"predictions").  But you'll notice if you google the expression that
almost the entire top page of results is versions of this package
description!  The home page has some clearer explanations that avoid
the phrase, and I recommend using some of that text.

>  It separetes sentences into words, tagging and predict pronunciations.
   ^  ---   ^
Spelling: "separAtes".

"Tagging" on its own can be unclear; I would suggest "tagging parts of
speech".

"Predict" should be "predicting", or preferably (as on the home page)
"estimating".  It's only a prediction if the word has never been
spoken before!

>  The pronunciation of KyTea is same as cutie.
^
Missing article, and awkward phrasing - you could simply say when you
first mention KyTea that it's "pronounced 'cutie'".  In fact, you
could start by explaining the name - it would at least serve to
distract slightly from the fact that somebody has made a rather bad
prediction of how "kytea" would be pronounced.  The mention of Kyoto
would also be useful for another reason: the description so far gives
no hint of the fact that KyTea is specifically designed to handle
(unromanised, unspaced) Japanese script.  That may seem obvious to
you, but if somebody is looking for a tool to do POS-tagging on the 
collected works of Shakespeare then it's the job of this package
description to let them know that KyTea isn't what they're after.

>  .
>  This package contains predictor and training tool.
 
Likewise for the other packages in the set:

> Package: libkytea0
[...]
> Description: library of KyTea

Standardise these synopses.

>  KyTea is morphological analysis system based on pointwise predictors.
>  It separetes sentences into words, tagging and predict pronunciations.
>  The pronunciation of KyTea is same as cutie.

As above.

>  .
>  This package contains shared libraries of KyTea.

Missing article.  I would also make it "for" rather than "of".

> Package: libkytea-dev
[...]
> Description: library of KyTea : development files

As above.  Colons in English never have preceding space, but I'd
recommend using a dash anyway.

>  KyTea is morphological analysis system based on pointwise predictors.
>  It separetes sentences into words, tagging and predict pronunciations.
>  The pronunciation of KyTea is same as cutie.
>  .
>  This package contains development files of KyTea.

All as above.

My recommended replacement text:

| Package: libkytea0
[...]
|  Description: text morphological analysis system - libraries
|  The Kyoto Text Analysis toolkit (KyTea, pronounced "cutie") is a general
|  morphological analysis system with a focus on Japanese, Chinese, and
|  other languages requiring word or morpheme segmentation. It uses a
|  pointwise classifier-based approach to split sentences into words,
|  tagging parts of speech and estimating pronunciations.
|  .
|  This package contains the shared libraries for KyTea.
| 
| Package: kytea
[...]
| Description: text morphological analysis system - binaries
|  The Kyoto Text Analysis toolkit (KyTea, pronounced "cutie") is a general
|  morphological analysis system with a focus on Japanese, Chinese, and
|  other languages requiring word or morpheme segmentation. It uses a
|  pointwise classifier-based approach to split sentences into words,
|  tagging parts of speech and estimating pronunciations.
|  .
|  This package contains the predictor and training tool for KyTea.
| 
| Package: libkytea-dev
[...]
| Description: text morphological analysis system - development libraries
|  The Kyoto Text Analysis toolkit (KyTea, pronounced "cutie") is a general
|  morphological analysis system with a focus on Japanese, Chinese, and
|  other languages requiring word or morpheme segmentation. It uses a
|  pointwise classifier-based approach to split sentences into words,
|  tagging 

Bug#711071: bitlbee: please port to libotr5-dev

[intrigeri]

Hi,

Cyril Brulebois wrote (17 Sep 2013 18:14:34 GMT) :
> looks good to me (that's at least what came to mind while reading the
> beginning of the thread).

Thanks.

> Do you have a patch handy, or should I take care of that now?

I don't, feel free to take care of that :)

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


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

Bug#723605: dgit build does not put upstream tarball into place

[Joey Hess]

Ian Jackson wrote:
> I think dgit fetch probably downloaded it earlier.  Is it possible
> that you deleted it yourself between fetch and build ?

Very likely, yes.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#722660: libgraphviz-dev and blt-dev: error when trying to install together

[David Claughton]

reassign 722660 blt
thanks

Hi,

I'm reassigning this to blt as it looks like this might be a
regression.  The changelog for version 2.4z-3 says the following:

"Moved the man pages and HTML docs for the BLT commands from the blt-dev
package to the blt package, where they really belong. Left just the man
pages for the BLT C API calls in the blt-dev package. Renamed the
command man pages to have the extension .3blt (I wanted to use .3tcl,
but that caused a conflict with the tcllib package)."

This appears to be the case up to the latest version, where the files
seem to be back in the dev package and are no longer renamed .3blt.  I
can't see anything in the more recent changelog entries that would
suggest that this is deliberate.

Cheers,

David.

On 13/09/13 07:10, Ralf Treinen wrote:
> Package: blt-dev,libgraphviz-dev
> Version: blt-dev/2.4z-6
> Version: libgraphviz-dev/2.26.3-15+b1
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
>
> Date: 2013-09-13
> Architecture: amd64
> Distribution: sid
>
> 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:
>
>
> WARNING: The following packages cannot be authenticated!
>   libdrm2 libffi6 libglapi-mesa libllvm3.2 libxau6 libxdmcp6 libxcb1
>   libxcb-dri2-0 libgbm1 libwayland-client0 libwayland-server0 libx11-data
>   libx11-6 libx11-xcb1 libxcb-render0 libxcb-shape0 libxcb-xfixes0
>   libegl1-mesa libexpat1 libfreetype6 ucf fonts-dejavu-core ttf-dejavu-core
>   fontconfig-config libfontconfig1 libxcb-glx0 libxfixes3 libxdamage1 libxext6
>   libxxf86vm1 libgl1-mesa-glx libpixman-1-0 libpng12-0 libxcb-shm0 libxrender1
>   libcairo2 libdatrie1 libjpeg8 libjbig0 libtiff4 libvpx1 libxpm4 libgd3
>   libglib2.0-0 libgraphite2-3 libharfbuzz0a libltdl7 libthai-data libthai0
>   fontconfig libpango-1.0-0 libpangoft2-1.0-0 libpangocairo-1.0-0 libxft2
>   x11-common libxss1 tcl8.5 tk8.5 blt libc-dev-bin linux-libc-dev libc6-dev
>   libcdt4 libcgraph5 libexpat1-dev zlib1g-dev libfreetype6-dev pkg-config
>   libfontconfig1-dev libgraph4 libpathplan4 libxdot4 libgvc5 libgvpr1
>   libltdl-dev libgraphviz-dev libpthread-stubs0 libpthread-stubs0-dev
>   xorg-sgml-doctools x11proto-core-dev libxau-dev libxdmcp-dev
>   x11proto-input-dev x11proto-kb-dev xtrans-dev libxcb1-dev libx11-dev
>   x11proto-xext-dev libxext-dev x11proto-render-dev libxrender-dev libxft-dev
>   x11proto-scrnsaver-dev libxss-dev tcl8.5-dev tk8.5-dev blt-dev
>
> Extracting templates from packages: 30%
> Extracting templates from packages: 61%
> Extracting templates from packages: 92%
> Extracting templates from packages: 100%
> Preconfiguring packages ...
> Authentication warning overridden.
> Selecting previously unselected package libdrm2:amd64.
> (Reading database ... 10882 files and directories currently installed.)
> Unpacking libdrm2:amd64 (from .../libdrm2_2.4.46-2_amd64.deb) ...
> Selecting previously unselected package libffi6:amd64.
> Unpacking libffi6:amd64 (from .../libffi6_3.0.13-4_amd64.deb) ...
> Selecting previously unselected package libglapi-mesa:amd64.
> Unpacking libglapi-mesa:amd64 (from .../libglapi-mesa_9.1.6-2+b1_amd64.deb) 
> ...
> Selecting previously unselected package libllvm3.2:amd64.
> Unpacking libllvm3.2:amd64 (from .../libllvm3.2_1%3a3.2repack-11_amd64.deb) 
> ...
> Selecting previously unselected package libxau6:amd64.
> Unpacking libxau6:amd64 (from .../libxau6_1%3a1.0.8-1_amd64.deb) ...
> Selecting previously unselected package libxdmcp6:amd64.
> Unpacking libxdmcp6:amd64 (from .../libxdmcp6_1%3a1.1.1-1_amd64.deb) ...
> Selecting previously unselected package libxcb1:amd64.
> Unpacking libxcb1:amd64 (from .../libxcb1_1.9.1-3_amd64.deb) ...
> Selecting previously unselected package libxcb-dri2-0:amd64.
> Unpacking libxcb-dri2-0:amd64 (from .../libxcb-dri2-0_1.9.1-3_amd64.deb) ...
> Selecting previously unselected package libgbm1:amd64.
> Unpacking libgbm1:amd64 (from .../libgbm1_9.1.6-2+b1_amd64.deb) ...
> Selecting previously unselected package libwayland-client0:amd64.
> Unpacking libwayland-client0:amd64 (from 
> .../libwayland-client0_1.2.1-1_amd64.deb) ...
> Selecting previously unselected package libwayland-server0:amd64.
> Unpacking libwayland-server0:amd64 (from 
> .../libwayland-server0_1.2.1-1_amd64.deb) ...
> Selecting previously unselected package libx11-data.
> Unpacking libx11-data (from .../libx11-data_2%3a1.6.1-1_all.deb) ...
> Selecting previously unselected package libx11-6:amd64.
> Unpacking libx11-6:amd64 (from .../libx11-6_2%3a1.6.1-1_amd64.deb) ...
> Selecting previously unselected package libx11-xcb1:amd64.
> Unpacking libx11-xcb1:amd64 (from .../libx11-xcb1_2%3a1.6.1-1_amd64.deb) ...
> Selecting previously unselected package libxcb-render0:amd64.
> Unpacking libxcb-render0:amd64 (from .../libxcb-render0_1.9.1-3_amd64.deb) ...
> Selecting previously unselected package libxcb-shape0:amd64.
> 

Bug#721137: ghostscript: ps2pdf produces bad pdf on x86_64 (unreadeable text)

[whoami314]

> Evince can also display Postscript.  For the garbled PDFs, do the 
> corresponding Postscript look fine in Evince?

Yes, the above test.ps is displayed nicely by evince (or gv, or whatever).
When displaying tp2A_scilab_N1.ps in evince, the display is ok, but I get
some warnings:
 GPL Ghostscript 9.05: Error: Font Renderer Plugin ( FreeType ) return code = -1
Not sure whether these warnings are related with the current issue...

> If not, this seems not a Ghostscript bug, but a TeX (or user) bug to me.

Well, obviously many things could be at fault here :
 - the postscript creator indeed (latex + dvips) 
 - ps2pdf
 - the pdf viewers
Or any combination of the three :-(.
Anyway, it's just a wild guess, but the garbled evince + the error msgs in xpdf
make me suspicious about the content of these pdf files.

Btw, what would you call a user bug ? I've used this kind of tex sources with T1
fontenc for ages without issues up to now.

Thanks for your help

Pierre


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

Bug#723589: [DRE-maint] Bug#723589: ruby-nokogiri: nokoiri missing nokogiri/nokogiri.rb

[Hleb Valoshka]

On 9/17/13, James Michael DuPont  wrote:

> /usr/lib/ruby/vendor_ruby/nokogiri.rb:28:in `require': no such file to load
> -- nokogiri/nokogiri (LoadError)
> from /usr/lib/ruby/vendor_ruby/nokogiri.rb:28
> from /usr/bin/nokogiri:6:in `require'
> from /usr/bin/nokogiri:6

Ruby 1.8 is scheduled to be removed, so it's not supported by current
ruby-nokogiri package. Please, use ruby 1.9.1 or 2.0 instead.


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

Bug#721882: amarok: Built without support for QtScript

[Ralf Jung]

Hi,

this bug also prevents the lyrics script from working on my system.
According to upstream (https://bugs.kde.org/show_bug.cgi?id=325006)

> The Amarok package was built without having the Qt Script Bindings installed 
> at compile time. This is why none of the scripts work. It's a packaging 
> error. 
This leads me to the conclusion that the patch
debian_disable_qtscriptbindings_check_fix.diff is incorrect. I am
currently trying to re-build the package without that patch, and with
the qtscript packages as build dependencies, to see if that fixes the
problem.

Kind regards,
Ralf


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

Bug#722054: Pending fixes for bugs in the fonts-ebgaramond package

[pkg-fonts-devel]

tag 723159 + pending
tag 722054 + pending
thanks

Some bugs in the fonts-ebgaramond package are closed in revision
046252cf2b64edb5a4df6ab2c15074a13118f22b in branch 'master' by Scott
Howard

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-ebgaramond.git;a=commitdiff;h=046252c

Commit message:

Documented the license for tests/test-microtype.tex (lppl-1.3c) Closes: 
#723159 Thanks Paul Tagliamonte; Split Initials and ttf into 
fonts-ebgaramond-extra (Closes: #722054)


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

Bug#717157: blktap-dkms: Fails to build against Linux 3.10

[Ritesh Raj Sarraf]

Package: blktap-dkms
Followup-For: Bug #717157

I picked the commits from upstream. You should consider pushing it to
the archive.


root@ibmx3650m2-210-147:/usr/src/blktap-2.0.91# diff -Naru ring.c
/tmp/ring.c 
--- ring.c  2013-09-17 11:47:27.46820 -0400
+++ /tmp/ring.c 2013-09-17 11:47:56.83620 -0400
@@ -210,7 +210,7 @@
 
pgoff = 1 + request->usr_idx * BLKTAP_SEGMENT_MAX;
 
-   addr = do_mmap_pgoff(filp, addr, len, prot, flags, pgoff);
+   addr = vm_mmap(filp, addr, len, prot, flags, pgoff <<
PAGE_SHIFT);
 
return IS_ERR_VALUE(addr) ? addr : 0;
 }
@@ -230,8 +230,7 @@
addr  = MMAP_VADDR(ring->user_vstart, request->usr_idx, 0);
len   = request->nr_pages << PAGE_SHIFT;
 
-   err = do_munmap(current->mm, addr, len);
-
+   err = vm_munmap(addr, len);
WARN_ON_ONCE(err);
 }
 


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

Kernel: Linux 3.11-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (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#719106: RFA: passwdqc -- password strength checking and policy enforcement toolset

[Jackson Doak]

It's a regression, but i think it's because the updates allow it to be
found by lintian.

On Wed, Sep 18, 2013 at 6:30 AM, martin f krafft  wrote:
> also sprach Antoine Beaupré  [2013.09.17.1625 +0200]:
>> Or is this a regression?
>
> It's a regression, but obviously I don't want to spoil Jackson's
> fun. It's just a Lintian warning too, so I suppose we should upload
> and then solve it.
>
> I am on the road. Unless someone else does, I can look at this on
> Friday.
>
> --
>  .''`.   martin f. krafft   Related projects:
> : :'  :  proud Debian developer   http://debiansystem.info
> `. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
>   `-  Debian - when you have better things to do than fixing systems


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

Bug#719534: [libapache2-mod-fcgid] "sufficient number instances" in extended description

[Felix Geyer]

On 12.08.2013 22:50, Filipus Klutiero wrote:
> Note that this still doesn't give a valid sentence. I suggest:
> 
>> This package contains mod_fcgid, a high-performance alternative to mod_cgi 
>> or mod_cgid. It
>> starts a sufficient number of instances of the CGI program to handle 
>> concurrent requests. These
>> programs remain running to handle further incoming requests.

Yes, definitely much better. Thanks.
I will include the improved description in the next upload.

Felix


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

Bug#720783: Patch for this NMU

[Reinhard Tartler]

tags 720783 +patch

The attached patch fixes the compilation of dvswitch.

If you agree, I'm willing to upload it, but I'd appreciate to hear
your opinion on this.

-- 
regards,
Reinhard


dvswitch.nmu
Description: Binary data

Bug#655975: [PATCH] Support :any architecture qualifiers for multiarch

[Adam D. Barratt]

[Dropped -python CC; replaced -release with an existing bug relating to
britney and multi-arch]

On Mon, 2013-09-16 at 15:02 +0100, Colin Watson wrote:
>   i18nspector/i386 unsatisfiable Depends: python3:any (>= 3.2.3-3~)
> 
> I've fixed this for Ubuntu's britney instance with the following patch.

Thanks very much!

> I'm afraid I haven't had a chance to rebase it on top of Debian or to
> test it there, but that should hopefully not be very much work, and
> certainly easier than recreating all this from scratch ...

Indeed. I've done the rebasing (which was mostly handling the fact that
Debian has a "consts" module) and attached the result.

The resulting britney successfully passes our test-suite, including the
four "live-data" datasets. Admittedly none of those tests involve
multi-arch dependencies, but it does at least demonstrate a lack of
regressions.

Regards,

Adam
commit b9f6417351021f88a71970deea1312ab0940b9a2
Author: Colin Watson 
Date:   Mon Sep 16 15:02:55 2013 +0100

Support :any architecture qualifiers for multiarch

Multiarch adds a Depends: foo:any syntax, permitted only if the
target of the dependency is "Multi-Arch: allowed".  This has
been supported by dpkg and apt for some time and is now safe to
use in unstable.

[Adam D. Barratt: adjusted to use consts.py]

Signed-off-by: Adam D. Barratt 

diff --git a/britney.py b/britney.py
index 25eb6ba..037645f 100755
--- a/britney.py
+++ b/britney.py
@@ -218,7 +218,7 @@ from britney_util import (old_libraries_format, same_source, undo_changes,
   eval_uninst, newly_uninst, make_migrationitem)
 from consts import (VERSION, SECTION, BINARIES, MAINTAINER, FAKESRC,
SOURCE, SOURCEVER, ARCHITECTURE, DEPENDS, CONFLICTS,
-   PROVIDES, RDEPENDS, RCONFLICTS)
+   PROVIDES, RDEPENDS, RCONFLICTS, MULTIARCH)
 
 __author__ = 'Fabio Tranchitella and the Debian Release Team'
 __version__ = '2.0'
@@ -524,6 +524,7 @@ class Britney(object):
 pkg, 
 version,
 get_field('Architecture'),
+get_field('Multi-Arch'),
 None, # Pre-depends - leave as None for the C-code
 deps,
 ', '.join(final_conflicts_list) or None,
@@ -824,7 +825,7 @@ class Britney(object):
 binaries = self.binaries[suite][arch][0]
 for pkg in binaries:
 output = "Package: %s\n" % pkg
-for key, k in ((SECTION, 'Section'), (ARCHITECTURE, 'Architecture'), (SOURCE, 'Source'), (VERSION, 'Version'), 
+for key, k in ((SECTION, 'Section'), (ARCHITECTURE, 'Architecture'), (MULTIARCH, 'Multi-Arch'), (SOURCE, 'Source'), (VERSION, 'Version'), 
   (DEPENDS, 'Depends'), (PROVIDES, 'Provides'), (CONFLICTS, 'Conflicts')):
 if not binaries[pkg][key]: continue
 if key == SOURCE:
@@ -880,12 +881,19 @@ class Britney(object):
 
 # for every package, version and operation in the block
 for name, version, op in block:
+if ":" in name:
+name, archqual = name.split(":", 1)
+else:
+archqual = None
+
 # look for the package in unstable
 if name in binaries[0]:
 package = binaries[0][name]
-# check the versioned dependency (if present)
+# check the versioned dependency and architecture qualifier
+# (if present)
 if op == '' and version == '' or apt_pkg.check_dep(package[VERSION], op, version):
-packages.append(name)
+if archqual is None or (archqual == 'any' and package[MULTIARCH] == 'allowed'):
+packages.append(name)
 
 # look for the package in the virtual packages list and loop on them
 for prov in binaries[1].get(name, []):
@@ -893,7 +901,9 @@ class Britney(object):
 package = binaries[0][prov]
 # A provides only satisfies an unversioned dependency
 # (per Policy Manual §7.5)
-if op == '' and version == '':
+# A provides only satisfies a dependency without an
+# architecture qualifier (per analysis of apt code)
+if op == '' and version == '' and archqual is None:
 packages.append(prov)
 
 return (len(packages) > 0, packages)
diff --git a/consts.py b/consts.py
index 47670b2..eba22d2 100644
--- a/consts.py
+++ b/consts.py
@@ -29,11 +29,12 @@ FAKESRC = 4
 SOURCE = 2
 SOURCEVER = 3
 ARCHITECTURE = 4
-# PREDEPENDS = 5 - No longer used by the python code
+MULTIARCH = 5
+# PREDEPENDS = 6 - No longer used by the python code
 #  - The C-code needs it for alignment reasons and still check it
 #but ignore it if it is None (so keep it None).
-DEPENDS = 6

Bug#722898: benchmarks

[Thiemo Nagel]

> If we are changing this anyway, maybe it's a good time to also make the
> template partman-crypto/progress/erase a bit more explicit about
> canceling.

I fully agree!

> It currently reads: "Erasing data on ${DEVICE}". Maybe something like
> "Erasing data on ${DEVICE}. To continue without ereasing press
> 'Cancel'." How do others feel about this?

Maybe "Skip" would be more precise than "Cancel"?

Also I think "erasing" doesn't quite hit the mark because it leads
users to believe that the step isn't necessary for a new drive or if
they don't care about securely deleting its previous contents. How
about something along the lines of: "Overwriting ${DEVICE} with random
data to prevent meta-information leaks from the encrypted volume. This
step may be skipped at the expense of a slight reduction of the
quality of the encryption."

> Several bug reports show that
> it's apparently not clear to many users that they can cancel the
> operation and what happens if they select cancel.

I can back this up with my own experience.


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

Bug#723467: [Pkg-xfce-devel] Bug#723467: libxfcegui4 link with -L/usr/lib

[Yves-Alexis Perez]

On mar., 2013-09-17 at 18:47 +0800, YunQiang Su wrote:
> Package: libxfcegui4
> Version: 4.10.0-2
> X-Debbugs-CC: wzss...@gmail.com
> 
> This package has one or more -L/usr/lib in its build system,
> which will make it ftbfs if there is libraries under /usr/lib,
> while is not the default architecture, mips* for example.
> 
> On mips* systems, /usr/lib is defined as place to hold O32
> libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.
> 
> Beside the way, on the multiarch system like Debian, user may install
> libraries under /usr/lib by hand.
> 
> Please use the default search path if you can, and please consider fix
> this.
> 
> I will try to fix this bug, while if you can help to fix it, 
> It will be very appreciative.
> 
> The attachement is the buildlog of this package on mips64el platform.

Well, I can't see a -L/usr/lib in the build log, so I'm not sure what
you mean here.

Regards,
-- 
Yves-Alexis


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

Bug#723610: python-rpy2: segfault upon import rpy2.robjects

[Dirk Eddelbuettel]

On 17 September 2013 at 16:15, Yaroslav Halchenko wrote:
| Package: python-rpy2
| Version: 2.3.6-1
| Severity: important
| 
| Dear Maintainer,
| *** Please consider answering these questions, where appropriate ***
| 
|* What led up to the situation?
| 
|unittesting of python-mvpa2 pkg
| 
|* What exactly did you do (or not do) that was effective (or
|  ineffective)?
| 
| $> python -c 'import rpy2.robjects'
| Error: 'rho' must be an environment not NULL: detected in C-level eval
| Segmentation fault
| 
|* What was the outcome of this action?
| 
|segfault
| 
|* What outcome did you expect instead?
| 
|not to segfault ;)
| 
| *** End of the template - remove these lines ***
| 
| this seems to be related to having r-base-core 3.0.1.20130915-1 (ok with
| 3.0.1-6) but not sure if that is RPy2's issue or R's, thus filing here as were
| produced (R starts fine)

We often need a rebuild for a new R version.  

And "3.0.1.20130915" is my first build of R 3.0.2 scheduled for Sep 25.

Until then, pin your rpy2 to R 3.0.1 from testing.

Dirk


| 
| -- System Information:
| Debian Release: jessie/sid
|   APT prefers unstable
|   APT policy: (500, 'unstable')
| Architecture: amd64 (x86_64)
| 
| Kernel: Linux 3.10-1-amd64 (SMP w/2 CPU cores)
| Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
| Shell: /bin/sh linked to /bin/dash
| 
| Versions of packages python-rpy2 depends on:
| ii  libc6 2.17-92+b1
| ii  python2.7.5-5
| ii  python-numpy  1:1.7.1-3
| ii  r-base-core   3.0.1.20130915-1
| 
| python-rpy2 recommends no packages.
| 
| Versions of packages python-rpy2 suggests:
| pn  python-rpy-docs  
| 
| -- no debconf information

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


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

Bug#719106: RFA: passwdqc -- password strength checking and policy enforcement toolset

[martin f krafft]

also sprach Antoine Beaupré  [2013.09.17.1625 +0200]:
> Or is this a regression?

It's a regression, but obviously I don't want to spoil Jackson's
fun. It's just a Lintian warning too, so I suppose we should upload
and then solve it.

I am on the road. Unless someone else does, I can look at this on
Friday.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#721882: amarok: Built without support for QtScript

[Ralf Jung]

Hi,

as pinotree said on IRC that the solution I suggested above would not be
accepted, I tried fixing the patch instead. After compiling Amarok with
attached patch, QtScripts work fine for me (I compiled with pbuilder, so
the bindings were definitely not installed while creating the package).
Please let me know if there's anything else I can do get this fix to
unstable.

Kind regards
Ralf
From: Modestas Vainius 
Subject: [PATCH] Disable QtScriptBindings check
Forwarded; not-needed
Origin: vendor
Last-Update: 2011-07-06

QtScriptBindings is a runtime dependency which is not needed at build time.
Just make cmake think that QtScriptBindings is available.

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -95,8 +95,6 @@
 # QCA2 is required for the Script Updater
 find_package( QCA2 )
 
-find_package( QtScriptQtBindings )
-
 macro_optional_find_package( LibLastFm )
 set( LIBLASTFM_MIN_VERSION "1.0.0" )
 if( LIBLASTFM_FOUND )
@@ -132,8 +130,6 @@
 
 macro_log_feature( QT_QTOPENGL_FOUND "QtOpenGL" "Required for the spectrum analyzer" "http://qt-project.org"; FALSE "" "" )
 
-macro_log_feature( QTSCRIPTQTBINDINGS_FOUND "qtscript-qt" "QtScript Qt Bindings" "http://code.google.com/p/qtscriptgenerator/"; FALSE "" "" )
-
 find_package(MySQLAmarok REQUIRED)
 if( WITH_MYSQL_EMBEDDED )
 set( BUILD_MYSQLE_COLLECTION TRUE )
--- a/shared/config.h.cmake
+++ b/shared/config.h.cmake
@@ -15,9 +15,6 @@
 /* have QtCrypto the Qt crypto architecture */
 #cmakedefine QCA2_FOUND 1
 
-/* have Qt bindings */
-#cmakedefine QTSCRIPTQTBINDINGS_FOUND 1
-
 /* have QtOpenGL */
 #cmakedefine QT_QTOPENGL_FOUND 1
 
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -25,9 +25,7 @@
 #don't use our own libplasma anymore, but still pick up our applets/engines/containments
 add_subdirectory( context )
 add_subdirectory( services )
-if( QTSCRIPTQTBINDINGS_FOUND )
-add_subdirectory( scripts )
-endif( QTSCRIPTQTBINDINGS_FOUND )
+add_subdirectory( scripts )
 add_subdirectory( aboutdialog/libattica-ocsclient )
 add_subdirectory( transcoding )
 add_subdirectory( kconf_update )
--- a/src/MainWindow.cpp
+++ b/src/MainWindow.cpp
@@ -1123,9 +1123,7 @@
 m_toolsMenu.data()->addAction( Amarok::actionCollection()->action("bookmark_manager") );
 m_toolsMenu.data()->addAction( Amarok::actionCollection()->action("cover_manager") );
 m_toolsMenu.data()->addAction( Amarok::actionCollection()->action("equalizer_dialog") );
-#ifdef QTSCRIPTQTBINDINGS_FOUND
 m_toolsMenu.data()->addAction( Amarok::actionCollection()->action("script_manager") );
-#endif
 #ifdef DEBUG_BUILD_TYPE
 m_toolsMenu.data()->addAction( Amarok::actionCollection()->action("network_request_viewer") );
 #endif // DEBUG_BUILD_TYPE
--- a/src/scriptengine/ScriptImporter.cpp
+++ b/src/scriptengine/ScriptImporter.cpp
@@ -47,9 +47,7 @@
 ScriptImporter::loadQtBinding( const QString& binding )
 {
 QSet allowedBindings;
-#ifdef QTSCRIPTQTBINDINGS_FOUND
 allowedBindings << "qt.core" << "qt.gui" << "qt.sql" << "qt.webkit" << "qt.xml" << "qt.uitools" << "qt.network";
-#endif
 if( allowedBindings.contains( binding ) )
 {
 if( !m_importedBindings.contains( binding ) )

Bug#723601: Please remove me from uploaders

[Luk Claes]

Package: rpcbind
Version: 0.2.0-8.2
Severity: wishlist

Hi

As I've lost interest in NFS packaging, please remove me from uploaders.

Cheers

Luk


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

Bug#723603: Please remove me from uploaders

[Luk Claes]

Package: curl
Version: 7.32.0-1
Severity: wishlist

Hi

As I've lost interest in curl packaging, please remove me from uploaders.

Cheers

Luk


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

Bug#715672: [Mayhem] Bug report on rheolef: bamg crashes with exit status 139

[Pierre Saramito]

Hi Alexandre,

> From Alexandre Rebert:
> Package: rheolef
> 
> bamg crashes with exit status 139. We confirmed the crash by
> re-running it in a fresh debian unstable installation.

Many thanks for your help: the bug is now fixed in the forthcoming
rheolef-6.5 that will be available with the next upload.

The command now exit cleanly with error status 1.

 % bamg -g A -H
bamg: missing argument for option `-H'
HINT: see documentation or enter bamg -h
 % echo $?
1

Regards,

Pierre
-- 
pierre.saram...@imag.fr
Directeur de Recherche CNRS
Laboratoire Jean Kuntzmann, Grenoble, France
http://www-ljk.imag.fr/membres/Pierre.Saramito

-- 
pierre.saram...@imag.fr
Directeur de Recherche CNRS
Laboratoire Jean Kuntzmann, Grenoble, France
http://www-ljk.imag.fr/membres/Pierre.Saramito


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

Bug#723597: RFA: fatattr

[Luk Claes]

Package: wnpp
Severity: normal

Hi

As I've lost interest I'm looking for a new maintainer for fatattr and some 
other filesystem related packages.

Cheers

Luk


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

Bug#723594: RFA: aufs-tools

[Luk Claes]

Package: wnpp
Severity: normal

Hi

As I've lost interest in the package, I'm looking for a new maintainer for 
aufs-tools and some other filesystem related packages.

Cheers

Luk


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

Bug#723598: RFA: logfs-tools

[Luk Claes]

Package: wnpp
Severity: normal

Hi

As I've lost interest I'm looking for a new maintainer for logfs-tools and some 
other filesystem related packages.

Cheers

Luk


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

Bug#699854: RFS: openctm

[Teemu Ikonen]

retitle 699854 ITP: openctm -- Open Compressed Triangle Mesh file format
thanks

I just uploaded openctm packages to the Debian Science git repo at
http://anonscm.debian.org/gitweb/?p=debian-science/packages/openctm.git
and mentors.d.o:
http://mentors.debian.net/debian/pool/main/o/openctm/openctm_1.0.3-1.dsc

The package is lintian clean etc., but checking and sponsoring the upload
would still be needed.

Best,
Teemu

Bug#723600: RFA: squashfs-tools

[Luk Claes]

Package: wnpp
Severity: normal

Hi

As I've lost interest I'm looking for a new maintainer for squashfs-tools and 
some other filesystem related packages.

Cheers

Luk


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

Bug#723599: RFA: nilfs-tools

[Luk Claes]

Package: wnpp
Severity: normal

Hi

As I've lost interest I'm looking for a new maintainer for nilfs-tools and some 
other filesystem related packages.

Cheers

Luk


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

Bug#723354: hp48cc link with -L/usr/lib

[Roberto Lumbreras]

Hi,

Could you give me more information? I'm unable to find any -L in your log
or in the package sources. The package uses ./configure and cdbs to build
binaries, so I'm puzzled...

Regards,
Roberto Lumbreras
Debian developer

Bug#723602: Please remove me from uploaders

[Luk Claes]

Package: nfs-utils
Severity: wishlist

Hi

As I've lost interest in NFS packaging, please remove me from uploaders.

Cheers

Luk


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

Bug#723595: RFA: ecryptfs-utils

[Luk Claes]

Package: wnpp
Severity: normal

Hi

As I've lost interest I'm looking for a new maintainer for ecryptfs-utils and 
some other filesystem related packages.

Cheers

Luk


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

Bug#723596: RFA: f2fs-tools

[Luk Claes]

Package: wnpp
Severity: normal

Hi

As I've lost interest I'm looking for a new maintainer for f2fs-tools and some 
other filesystem related packages.

Cheers

Luk


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

Bug#723470: libzdb link with -L/usr/lib

[Jack Bates]

reassign 723470 libpq5
forcemerge 706849 723470
thank you

On 17/09/13 03:47 AM, YunQiang Su wrote:

This package has one or more -L/usr/lib in its build system,
which will make it ftbfs if there is libraries under /usr/lib,
while is not the default architecture, mips* for example.


Hi and thank you for reporting this issue,

Where is libpq.so (PostgreSQL client library) installed on your system? 
I suspect the offending line is libzdb-2.11.3/configure.ac line 268:


LDFLAGS="-L`$PGCONFIG --libdir` $LDFLAGS"

I think bug #706849 (libpq5: enable multi-arch) will move libpq.so out 
of /usr/lib and I think that will resolve this bug as well.


I will therefore merge this bug with bug #706849, so that this bug will 
get automatically closed when bug #706849 is resolved. If this is a 
mistake or you think it should be done differently, please let me know.


Thank you!


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

Bug#723180: linux-image-3.2.0-4-rt-amd64: kernel oops with futexes and gdb reverse-next

[Brian Silverman]

I can see (and download) them both at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723180. I'm just going to
paste the backtrace in here, but that won't work for the executable, and
I'm not sure what to do differently to get the attachments to work right.

Also, I forgot to mention before: if it would help, I'd be happy to send
the source code for the executable. I can also give details of how my code
is misusing futexes once I figure that out.

Here's the stacktrace:

Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445219] CPU 2
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445220] Modules linked
in: aes_x86_64 aes_generic parport_pc ppdev lp parport bnep rfcomm
cpufreq_stats cpufreq_userspace cpufreq_conservative cpufreq_powersave
binfmt_misc uinput fuse nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc
ext2 mbcache loop kvm_intel kvm uvcvideo videodev v4l2_compat_ioctl32 media
arc4 snd_hda_codec_hdmi joydev btusb snd_hda_codec_realtek bluetooth crc16
iwlwifi coretemp i915 snd_hda_intel snd_hda_codec drm_kms_helper snd_hwdep
drm snd_pcm snd_page_alloc snd_seq i2c_algo_bit snd_seq_device i2c_i801
dell_wmi snd_timer psmouse sparse_keymap serio_raw acpi_cpufreq mperf
dell_laptop mac80211 cfg80211 crc32c_intel snd dcdbas i2c_core
ghash_clmulni_intel wmi iTCO_wdt iTCO_vendor_support video evdev soundcore
rfkill pcspkr ac battery power_supply cryptd processor button xfs dm_mod sg
sr_mod sd_mod cdrom crc_t10dif usbhid hid thermal thermal_sys ahci libahci
libata scsi_mod r8169 xhci_hcd mii ehci_hcd usbcore usb_common [last
unloaded: scsi_wait_scan]
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445277]
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445279] Pid: 13661,
comm: mutex_test Not tainted 3.2.0-4-rt-amd64 #1 Debian 3.2.46-1+deb7u1
Dell Inc.  Dell System Inspiron N4110/05TM8C
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445283] RIP:
0010:[]  []
native_irq_enable_sysexit+0x10/0x10
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445289] RSP:
0018:  EFLAGS: 00010146
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445291] RAX:
00e0 RBX: f7d06cd4 RCX: 0d696910
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445293] RDX:
cd94 RSI: f7fe8da6 RDI: f7d13a30
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445295] RBP:
cd2c R08:  R09: 
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445296] R10:
 R11:  R12: 
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445298] R13:
 R14:  R15: 
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445300] FS:
 () GS:88013f10(0063) knlGS:f7cff700
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445302] CS:  0010 DS:
002b ES: 002b CR0: 8005003b
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445304] CR2:
fff8 CR3: a669a000 CR4: 000406e0
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445306] DR0:
 DR1:  DR2: 
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445308] DR3:
 DR6: 4ff0 DR7: 0400
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445310] Process
mutex_test (pid: 13661, threadinfo 8800745ac000, task 880135b42440)
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445312]
 88013f105e40 81621298  88013f105f58
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445316]
  0ac0  0040
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445318]
 81010d8b 880135b42440  88013f105eb8
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445327]
 [] ? show_registers+0xac/0x209
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445331]
 [] ? __die+0x99/0xd6
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445333]
 [] ? die+0x3f/0x5b
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445336]
 [] ? do_double_fault+0x5a/0x5c
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445338]
 [] ? double_fault+0x25/0x30
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445341]
 [] ? native_irq_enable_sysexit+0x10/0x10
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.445367]  RSP
<>
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.512886] ---[ end trace
0002 ]---
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.513030] [
cut here ]
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.513036] WARNING: at
/build/linux-iWNI5S/linux-3.2.46/debian/build/source_rt/kernel/smp.c:325
smp_call_function_single+0x75/0x12e()
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.513038] Hardware name:
Dell System Inspiron N4110
Sep 16 22:14:41 dell-inspiron-linux kernel: [250336.513

Bug#721603: [pkg-horde] Bug#721603: Workaround: Install missing package via PEAR

[Mathieu Parent]

2013/9/2 Markus Wagner :
>
> As a workaround you can install the missing package via PEAR from
> pear.horde.org
> (Make sure, you have the channel registered):
>
> pear install horde/horde_smtp
>
> But I am sure, this is not the correct debian way.
>
> This has been confirmed by another user via PM.

FYI: The correct way (the php-horde-smtp package) is on its way to the
new queue.

-- 
Mathieu


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

Bug#723581: firebird2.5: allow parallel building

[Aron Xu]

Package: src:firebird2.5
Severity: wishlist

Building firebird2.5 takes  somehow a long time on slow architectures
(takes 4 hours and 48 minutes on armhf, it's much slower than
firebird3.0 which uses 69 minutes on the same arch). It can support
parallel building to get the benefit of multi-core/cpu configurations.

Attached is a patch doing so. It will deal with DEB_BUILD_OPTIONS and
to find if there is something like "parallel=N". This is a standard
environment variable, and if the value isn't set it will default to 1.

Thanks,
Aron


firebird2.5_2.5.2.26540.ds4-3.diff
Description: Binary data

Bug#721441: O: hlbrw -- assistant to help make new rules to HLBR

[Eriberto]

Package was moved from SVN to GIT (collab-maint).

Please, see http://anonscm.debian.org/gitweb/?p=collab-maint/hlbrw.git

Regards,

Eriberto


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

Bug#723605: dgit build does not put upstream tarball into place

[Ian Jackson]

Joey Hess writes ("Bug#723605: dgit build does not put upstream tarball into 
place"):
> Package: dgit
> Version: 0.15
> Severity: normal

I think dgit fetch probably downloaded it earlier.  Is it possible
that you deleted it yourself between fetch and build ?

Ian.


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

Bug#723583: RFS: avt/0.2-1 ITP

[Fernando]

Package: sponsorship-requests
Severity: normal 

Dear mentors,

I am looking for a sponsor for my package "avt"

* Package name: avt
 Version : 0.2-1
 Upstream Author : Fernando Iazeolla 
* URL : http://github.com/elboza/avt
* License : GPL
 Section : utilities

It builds those binary packages:

  avt   - Aviation Tools. metar and taf command line.

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

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


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

  dget -x http://mentors.debian.net/debian/pool/main/a/avt/avt_0.2-1.dsc

More information about avt can be obtained from http://github.com/elboza/avt.

Changes since the last upload:

avt (0.2-1) unstable; urgency=low

* Initial release (Closes: #)  

-- Fernando Iazeolla   Sun, 15 Sep 2013 22:58:17 +0200



Regards,
 Fernando Iazeolla

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

Bug#723582: RFS: metar/0.2-1 ITP

[Fernando]

Package: sponsorship-requests
Severity: normal 

Dear mentors,

I am looking for a sponsor for my package "metar"

* Package name: metar
 Version : 0.2-1
 Upstream Author : Fernando Iazeolla 
* URL : http://githib.com/elboza/metar
* License : GPL
 Section : utilities

It builds those binary packages:

  metar - a simple command line metar and taf.

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

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


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

  dget -x http://mentors.debian.net/debian/pool/main/m/metar/metar_0.2-1.dsc

More information about metar can be obtained from 
http://github.com/elboza/metar.

Changes since the last upload:

metar (0.2-1) unstable; urgency=low

* Initial release (Closes: #)  

-- Fernando Iazeolla   Mon, 09 Sep 2013 22:32:41 +0200



Regards,
 Fernando Iazeolla

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

Bug#723606: jardiff and libjnlp-servlet-java: error when trying to install together

[Ralf Treinen]

Package: libjnlp-servlet-java,jardiff
Version: libjnlp-servlet-java/20120126-1
Version: jardiff/0.2-3
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2013-09-17
Architecture: amd64
Distribution: sid

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:


WARNING: The following packages cannot be authenticated!
  libkeyutils1 libkrb5support0 libk5crypto3 libkrb5-3 libgssapi-krb5-2
  libavahi-common-data libavahi-common3 libdbus-1-3 libavahi-client3 libcups2
  libexpat1 libffi6 libfreetype6 ucf fonts-dejavu-core ttf-dejavu-core
  fontconfig-config libfontconfig1 libglib2.0-0 libjpeg8 liblcms2-2 libnspr4
  libnss3 libpcsclite1 openjdk-7-jre-lib openssl ca-certificates java-common
  default-jre-headless ca-certificates-java tzdata-java openjdk-7-jre-headless
  unzip java-wrappers libapache-pom-java libasm3-java libcommons-parent-java
  libcommons-lang-java libcommons-cli-java libservlet2.5-java
  libjnlp-servlet-java jardiff

Extracting templates from packages: 71%
Extracting templates from packages: 100%
Preconfiguring packages ...
Authentication warning overridden.
Selecting previously unselected package libkeyutils1:amd64.
(Reading database ... 10882 files and directories currently installed.)
Unpacking libkeyutils1:amd64 (from .../libkeyutils1_1.5.6-1_amd64.deb) ...
Selecting previously unselected package libkrb5support0:amd64.
Unpacking libkrb5support0:amd64 (from 
.../libkrb5support0_1.11.3+dfsg-3_amd64.deb) ...
Selecting previously unselected package libk5crypto3:amd64.
Unpacking libk5crypto3:amd64 (from .../libk5crypto3_1.11.3+dfsg-3_amd64.deb) ...
Selecting previously unselected package libkrb5-3:amd64.
Unpacking libkrb5-3:amd64 (from .../libkrb5-3_1.11.3+dfsg-3_amd64.deb) ...
Selecting previously unselected package libgssapi-krb5-2:amd64.
Unpacking libgssapi-krb5-2:amd64 (from 
.../libgssapi-krb5-2_1.11.3+dfsg-3_amd64.deb) ...
Selecting previously unselected package libavahi-common-data:amd64.
Unpacking libavahi-common-data:amd64 (from 
.../libavahi-common-data_0.6.31-2_amd64.deb) ...
Selecting previously unselected package libavahi-common3:amd64.
Unpacking libavahi-common3:amd64 (from .../libavahi-common3_0.6.31-2_amd64.deb) 
...
Selecting previously unselected package libdbus-1-3:amd64.
Unpacking libdbus-1-3:amd64 (from .../libdbus-1-3_1.6.14-1_amd64.deb) ...
Selecting previously unselected package libavahi-client3:amd64.
Unpacking libavahi-client3:amd64 (from .../libavahi-client3_0.6.31-2_amd64.deb) 
...
Selecting previously unselected package libcups2:amd64.
Unpacking libcups2:amd64 (from .../libcups2_1.6.3-1_amd64.deb) ...
Selecting previously unselected package libexpat1:amd64.
Unpacking libexpat1:amd64 (from .../libexpat1_2.1.0-4_amd64.deb) ...
Selecting previously unselected package libffi6:amd64.
Unpacking libffi6:amd64 (from .../libffi6_3.0.13-4_amd64.deb) ...
Selecting previously unselected package libfreetype6:amd64.
Unpacking libfreetype6:amd64 (from .../libfreetype6_2.4.9-1.1_amd64.deb) ...
Selecting previously unselected package ucf.
Unpacking ucf (from .../ucf_3.0027+nmu1_all.deb) ...
Moving old data out of the way
Selecting previously unselected package fonts-dejavu-core.
Unpacking fonts-dejavu-core (from .../fonts-dejavu-core_2.33+svn2514-3_all.deb) 
...
Selecting previously unselected package ttf-dejavu-core.
Unpacking ttf-dejavu-core (from .../ttf-dejavu-core_2.33+svn2514-3_all.deb) ...
Selecting previously unselected package fontconfig-config.
Unpacking fontconfig-config (from .../fontconfig-config_2.10.2-2_all.deb) ...
Selecting previously unselected package libfontconfig1:amd64.
Unpacking libfontconfig1:amd64 (from .../libfontconfig1_2.10.2-2_amd64.deb) ...
Selecting previously unselected package libglib2.0-0:amd64.
Unpacking libglib2.0-0:amd64 (from .../libglib2.0-0_2.36.4-1_amd64.deb) ...
Selecting previously unselected package libjpeg8:amd64.
Unpacking libjpeg8:amd64 (from .../libjpeg8_8d-1_amd64.deb) ...
Selecting previously unselected package liblcms2-2:amd64.
Unpacking liblcms2-2:amd64 (from .../liblcms2-2_2.2+git20110628-2.2_amd64.deb) 
...
Selecting previously unselected package libnspr4:amd64.
Unpacking libnspr4:amd64 (from .../libnspr4_2%3a4.10-1_amd64.deb) ...
Selecting previously unselected package libnss3:amd64.
Unpacking libnss3:amd64 (from .../libnss3_2%3a3.15.1-1_amd64.deb) ...
Selecting previously unselected package libpcsclite1:amd64.
Unpacking libpcsclite1:amd64 (from .../libpcsclite1_1.8.8-4+b1_amd64.deb) ...
Selecting previously unselected package openjdk-7-jre-lib.
Unpacking openjdk-7-jre-lib (from .../openjdk-7-jre-lib_7u25-2.3.12-4_all.deb) 
...
Selecting previously unselected package openssl.
Unpacking openssl (from .../openssl_1.0.1e-3_amd64.deb) ...
Selecting previously unselected package ca-certificates.
Unpacking ca-certificates (from .../ca-certificates_20130906_all.deb) ...
Selecting previous

Bug#723584: RFS: dcl/0.1-1 ITP

[Fernando]

Package: sponsorship-requests
 Severity: normal 

 Dear mentors,

 I am looking for a sponsor for my package "dcl"

* Package name: dcl
  Version : 0.1-1
  Upstream Author : Fernando Iazeolla 
* URL : http://github.com/elboza/dcl
* License : GPL
  Section : utilities

 It builds those binary packages:

   dcl   - D-cleaner (Disk && Directory Cleaner)

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

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


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

   dget -x http://mentors.debian.net/debian/pool/main/d/dcl/dcl_0.1-1.dsc

 More information about dcl can be obtained from http://github.com/elboza/dcl.

 Changes since the last upload:

dcl (0.1-1) unstable; urgency=low

 * Initial release (Closes: #)  

-- Fernando Iazeolla   Sun, 15 Sep 2013 23:21:52 +0200



 Regards,
  Fernando Iazeolla

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

Bug#723610: python-rpy2: segfault upon import rpy2.robjects

[Yaroslav Halchenko]

Package: python-rpy2
Version: 2.3.6-1
Severity: important

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

   * What led up to the situation?

   unittesting of python-mvpa2 pkg

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

$> python -c 'import rpy2.robjects'
Error: 'rho' must be an environment not NULL: detected in C-level eval
Segmentation fault

   * What was the outcome of this action?

   segfault

   * What outcome did you expect instead?

   not to segfault ;)

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

this seems to be related to having r-base-core 3.0.1.20130915-1 (ok with
3.0.1-6) but not sure if that is RPy2's issue or R's, thus filing here as were
produced (R starts fine)

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

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

Versions of packages python-rpy2 depends on:
ii  libc6 2.17-92+b1
ii  python2.7.5-5
ii  python-numpy  1:1.7.1-3
ii  r-base-core   3.0.1.20130915-1

python-rpy2 recommends no packages.

Versions of packages python-rpy2 suggests:
pn  python-rpy-docs  

-- 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#723607: tstools and opencaster: error when trying to install together

[Ralf Treinen]

Package: opencaster,tstools
Version: opencaster/3.2+dfsg-1
Version: tstools/1.11-1
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2013-09-17
Architecture: amd64
Distribution: sid

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:


WARNING: The following packages cannot be authenticated!
  libdvbcsa1 libexpat1 libffi6 libpython2.7-minimal python2.7-minimal
  mime-support libpython2.7-stdlib python2.7 python-minimal libpython-stdlib
  python opencaster tstools
Authentication warning overridden.
Selecting previously unselected package libdvbcsa1:amd64.
(Reading database ... 10882 files and directories currently installed.)
Unpacking libdvbcsa1:amd64 (from .../libdvbcsa1_1.1.0-2_amd64.deb) ...
Selecting previously unselected package libexpat1:amd64.
Unpacking libexpat1:amd64 (from .../libexpat1_2.1.0-4_amd64.deb) ...
Selecting previously unselected package libffi6:amd64.
Unpacking libffi6:amd64 (from .../libffi6_3.0.13-4_amd64.deb) ...
Selecting previously unselected package libpython2.7-minimal.
Unpacking libpython2.7-minimal (from 
.../libpython2.7-minimal_2.7.5-7_amd64.deb) ...
Selecting previously unselected package python2.7-minimal.
Unpacking python2.7-minimal (from .../python2.7-minimal_2.7.5-7_amd64.deb) ...
Selecting previously unselected package mime-support.
Unpacking mime-support (from .../mime-support_3.54_all.deb) ...
Selecting previously unselected package libpython2.7-stdlib.
Unpacking libpython2.7-stdlib (from .../libpython2.7-stdlib_2.7.5-7_amd64.deb) 
...
Selecting previously unselected package python2.7.
Unpacking python2.7 (from .../python2.7_2.7.5-7_amd64.deb) ...
Selecting previously unselected package python-minimal.
Unpacking python-minimal (from .../python-minimal_2.7.5-5_amd64.deb) ...
Selecting previously unselected package libpython-stdlib:amd64.
Unpacking libpython-stdlib:amd64 (from .../libpython-stdlib_2.7.5-5_amd64.deb) 
...
Selecting previously unselected package python.
Unpacking python (from .../python_2.7.5-5_amd64.deb) ...
Selecting previously unselected package opencaster.
Unpacking opencaster (from .../opencaster_3.2+dfsg-1_amd64.deb) ...
Selecting previously unselected package tstools.
Unpacking tstools (from .../tstools_1.11-1_amd64.deb) ...
dpkg: error processing /var/cache/apt/archives/tstools_1.11-1_amd64.deb 
(--unpack):
 trying to overwrite '/usr/share/man/man1/m2ts2ts.1.gz', which is also in 
package opencaster 3.2+dfsg-1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for man-db ...
Errors were encountered while processing:
 /var/cache/apt/archives/tstools_1.11-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (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/bin/m2ts2ts
  /usr/share/man/man1/m2ts2ts.1.gz

This bug has been filed against 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 then
also register in the BTS that the other package is affected by the bug.

-Ralf.

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


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

Bug#721080: RFS: vpcs/0.4b2-1 [ITP]

[Daniel Lintott]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

retitle 721080 RFS: vpcs/0.4b2-1 [ITP]
thanks

Dear mentors,

Following some advice on Debian Mentors, I have re-uploaded the vpcs
package to mentors.

* Package name: vpcs
   Version : 0.4b2-1
   Upstream Author : Paul Meng 
 * URL : http://sourceforge.net/projects/vpcs/
 * License : BSD
   Section : net

It builds those binary packages:

vpcs  - Virtual PC Simulator

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

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

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

dget -x
http://mentors.debian.net/debian/pool/main/v/vpc/vpcs_0.4b2-1.dsc

Changes since the last upload:
vpcs (0.4b2-1) unstable; urgency=low

  * Initial release (Closes: #720196)

 -- Daniel Lintott   Tue, 17 Sep 2013 19:44:40 +0100

Regards

Daniel Lintott

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJSOK9ZAAoJEMw/9yOWzAkJ32EH/09OJYIrae8UFBpAB9H6/sPa
dXLh/B9r+dFhNrCBJjn+sYN3EEaiGtp6hGgVbVlOwa7L24l0trhpSLIzRrog2S9x
NCbkROI7uKkB3EIEJCNdzeofNhrdjeUlGL7yQGewJLPjcwFtfQCUSsI1JQWgHqzS
BJ9wiHNF/nQqbNl8XcVng27r2/306ktY3asID+MNqPvrG1ib6qs1yTDZvS9/ayGY
za47bTgJVcOzWtAU752VPNOaaj3u1/tSRTNrCkdUdHHF0dbJZqf2MU7m0ipvMyBm
DVr9QhIxZvOnSxtNhgqS6d/AbJKgVjZeXKmlPE8J3B9pQo4Av8IRTRqOJuJY9V0=
=2T1W
-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#722604: I also had a non-booting machine...

[sacrificial-spam-address]

Just to send a "me, too!", I also recently bumped udev to the
systemd version and also had a non-booting machine.

Now, most of my machines had a sufficiently well-populated static /dev
that I could boot and actually didn't notice the lack of udevd.

On the non-booting machine, it was getting somewhere into the init
scripts, but I noticed some "command line syntax error" complaints from
mount when I hit scroll lock at the appropriate time.

Fortunately, I managed to boot with init=/bin/bash and MAKEDEV or mknod
the necessary device nodes.  So now it's running without udev either.
I spent a long time digging through /etc/init.d/mountkernfs trying to
find the problem before I came across this bug.

The question before me is whether to proceed to fix udev or just remove
the PoS from my ststem.

I've been running Debian on this machine with hand-compiled kernels since
the late 1990s, updating unstable at least weekly, and this is the first
time an update has failed to boot to at least a single-user shell.
I've had sshd break, which was pretty bad, but this is the worst.
The initial introduction of udev didn't cause this kind of mess.

When an essential early-boot utility is adding a kernel config dependency,
I expect *prominent* notice in changelog and the NEWS file.  But I notice,
despite the reference to it in the 204-1 changelog.Debian entry, no such
file is packaged with udev.

And finding it in the systemd source tree, there's no mention of the new
requirement there.

Hunting through the systemd git tree logs, I find that the requriement was
added in commit 220893b3cbdbf8932f95c44811b169a8f0d33939 (udev version
176), and the old udev NEWS file which documented it was deleted in
commit 3e2147858f21943d5f4a781c60f33ac22c6096ed.

Gosh, maybe that could be hidden more thoroughly?

Because Debian jumped from 175-7.2 to 204, there was literally no
opportunity to see it.

(This is primarily upstream's fault.  While it would have been highly
deisrable for the Debian maintainer to notice and reinstate things,
this cavalier destruction of important history is reprehensible.
Cc: to Kay Sievers to vent my ire in the correct direction.)


The init.d/udev problem causing the mount syntax errors appears to be
someone using `-o $dev_mount_options` rather than `-o "$dev_mount_options"`,
which works fine with a null options string.


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

Bug#723609: ITP: blogofile-blog -- Blogofile plugin implementing a basic blog engine

[Jakob Haufe]

Package: wnpp
Severity: wishlist
Owner: Jakob Haufe 

* Package name: blogofile-blog
  Version : 0.8b1
  Upstream Author : Ryan McGuire 
* URL : http://www.blogofile.com/
* License : MIT
  Programming Lang: Python
  Description : Blogofile plugin implementing a basic blog engine

 This is a plugin for Blogofile that impleents a basic blog engine.

 It provides a collection of Mako template files along with CSS and ancillary
 files, all derived from the HTML5Boilerplate project.
 It also provided Blogofile_ configuration, controllers, filters, and commands
 to allow you to create a simple blog engine that requires no database and no
 special hosting environment.

 The templates include features like:

 * Custom web fonts from Google
 * Disqus comments
 * Google Analytics tracking code stub
 * seaofclouds jQuery twitter plugin







   * plugin


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

Bug#723300: epdfview link with -L/usr/lib

[Yves-Alexis Perez]

On mar., 2013-09-17 at 18:33 +0800, YunQiang Su wrote:
> 
> This package has one or more -L/usr/lib in its build system,
> which will make it ftbfs if there is libraries under /usr/lib,
> while is not the default architecture, mips* for example.

Could you actually look at the build logs? This is completely unrelated,
I'm inclined to just close those bogus bug reports until they've been
actually looked at.

Regards,
-- 
Yves-Alexis


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

Bug#617613: [077e969] Fix for Bug#617613 committed to git

[Anton Gladky]

tags 617613 + pending
thanks

Hello,

 The following change has been committed for this bug by
 Anton Gladky  on Tue, 17 Sep 2013 22:07:31 +0200.
 The fix will be in the next upload. 

Build against BSD-version of soqt. (Closes: #617613)




You can check the diff of the fix at:

;a=commitdiff;h=077e969


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

Bug#722898: benchmarks

[Gaudenz Steinlin]

Hi

Thiemo Nagel  writes:

> Hello Gaudenz,
>
> thank you for your email!
>
> Any reason why you choose 512k? If I understand your benchmarks right,
>> doubling this to 1M yelds about another 27% gain.
>
>
> I'm sorry, I forgot to mention that I've re-run the benchmarks. After
> removing O_SYNC, the performance was identical for block sizes in the range
> of 32k to 16M. I chose 512k (16 times larger than the lowest value that
> I've tested) with the intent to exclude a block size penalty for devices up
> to 16x faster than my md raid1 setup, which comes in at around 80MB/s.
>
> Except for low-memory installs, I'm not aware of any obstacle to increasing
> the buffer even more. (And of course, there's always the option to test for
> available memory and chose the buffer size depending on that.)
>
>
>> > #2blockdev-wipe: Reduce progress indicator granularity to 1/1000
>>
>> This still sounds like a lot of granularity. IMO this could be reduced
>> to 1/100. Do we really need progress updates for less than 1%?
>>
>
> For a large device, wipe times still can be many hours. At a granularity of
> 1/1000, the progress indicator would advance every 10-50 seconds (order of
> magnitude), which I don't consider excessive. (Of course, this only holds
> true if the graphical frontend supports this kind of granularity, which I
> don't know.)

I don't know about the graphical frontend, but I'm pretty sure the console
based frontend is not able to display a finer granularity than 1/100.

If we are changing this anyway, maybe it's a good time to also make the
template partman-crypto/progress/erase a bit more explicit about
canceling.

It currently reads: "Erasing data on ${DEVICE}". Maybe something like 
"Erasing data on ${DEVICE}. To continue without ereasing press
'Cancel'." How do others feel about this? Several bug reports show that
it's apparently not clear to many users that they can cancel the
operation and what happens if they select cancel.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


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

Bug#723608: tiled: bump to version 0.9.1

[Ben Longbons]

Package: tiled
Version: 0.9.0-1
Severity: wishlist

Dear Maintainer,

Tiled 0.9.1 has been released for a while, there are no new releases
planned on the 0.9 branch, and it will be a few months until the next
major release.

0.9.1 contains several bugfixes, and one change of a really confusing UI.

Thanks.

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

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

Versions of packages tiled depends on:
ii  libc6 2.17-92+b1
ii  libgcc1   1:4.8.1-10
ii  libgl1-mesa-glx [libgl1]  9.1.6-2
ii  libqt4-opengl 4:4.8.5+dfsg-4
ii  libqtcore44:4.8.5+dfsg-4
ii  libqtgui4 4:4.8.5+dfsg-4
ii  libstdc++64.8.1-10
ii  zlib1g1:1.2.8.dfsg-1

tiled recommends no packages.

tiled 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