Bug#670405: ekiga: During start up segfault in `libopal.so.3.10.4`

[Michael Gilbert]

> The original closure report only closed the bug for the version in
> experimental, the bug was still listed as open in unstable:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ekiga;dist=unstable
>
> reopening is not the way to indicate it effects specific versions, rather 
> please
> use the 'found' element of bts.

It distorts udd views.  I'm fixing that so we have a better view of
what needs really needs fixing:
http://udd.debian.org/bugs.cgi?release=wheezy_and_sid&merged=ign&done=only&fnewerval=7&rc=1&sortby=id&sorto=asc&ctags=1&cdeferred=1


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

Bug#692189: iceowl-extension: cannot be made the default application for calendars under gnome

[debian wheezy]

Package: iceowl-extension
Version: 10.0.10-1
Severity: normal

Dear Maintainer,
This incapability is two-fold. The value for the default for "Calendar"
from gnome-control-center is not available for Iceowl, nor will Iceowl be
opend from GNOME's panel's "Open Calendar". This lack of functionality
inhibits Iceowl from being used like most other programs for calendars. I
can't remember the functionality of GNOME2 and the default for "Calendar".
Ubuntu has the same issue or similar. [1] They're seem to be work-arounds.
[2][3] Perhaps iceweasel-extension needs an iceweasel.desktop which would
be a copy of icedove.desktop with a mime-type for calendar, or just adding
the mime-type for icedove.desktop within the installation of Icedove. [4]

[1] - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/841409
[2] - http://forums.fedoraforum.org/showthread.php?t=270376
[3] -
http://unix.stackexchange.com/questions/41670/how-can-i-make-the-gnome3-calendar-use-thunderbird-instead-of-evolution
[4] -
https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/841409/comments/5

EXTRANEOUS LINKS
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=689288
[2] - https://addons.mozilla.org/en-US/thunderbird/addon/evolution-mirror/
[3] - http://forums.linuxmint.com/viewtopic.php?f=151&t=85318


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

Kernel: Linux 3.2.0-3-amd64 (SMP w/2 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 iceowl-extension depends on:
ii  calendar-timezones  10.0.10-1
ii  icedove 10.0.10-1
ii  libc6   2.13-35
ii  libnspr42:4.9.2-1
ii  libnspr4-0d 2:4.9.2-1
ii  libstdc++6  4.7.1-7

Versions of packages iceowl-extension recommends:
ii  calendar-google-provider  10.0.10-1

Versions of packages iceowl-extension suggests:
ii  fonts-lyx  2.0.3-3

-- no debconf information

Bug#670405: ekiga: During start up segfault in `libopal.so.3.10.4`

[Michael Gilbert]

control: reopen -1

This issue still apparently affects unstable, so reopening to track
the fact that it needs fixing there.

Best wishes,
Mike


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

Bug#691893: RFS: roundup/1.4.20-2 [RC]

[Salvatore Bonaccorso]

Hi Kai, hi Mike

On Fri, Nov 02, 2012 at 06:35:16PM -0400, Michael Gilbert wrote:
> On Fri, Nov 2, 2012 at 6:24 PM, Kai Storbeck wrote:
> > Hi Mike,
> >
> > Thanks for your prompt review.
> >
> > It seems I wasn't fully aware of the Freeze Policy. I was under a wrong
> > assumtion that I could make the package's state better during the freeze.
> >
> > I've spoken with Salvatore who proposed an NMU for only the RC bug. I
> > hope he can find the time to upload his proposed patch before the
> > deadline of the 7th.
> 
> According to the latest traffic in #689257, It sounds like he is
> deferring to you in terms of uploading a fixed package.

Kai had spoken to me regarding the NMU after the last BTS entry
yesterday, saying it's fine if I do the upload for only the RC bug. I
will upload the NMU this weekend to fix the open RC bug.

Regards,
Salvatore


signature.asc
Description: Digital signature

Bug#677042: icedove: New upstream (16.0)

[Daniel Baumann]

On 11/03/2012 01:16 AM, Carsten Schoenert wrote:

with the last push from Guido we are right in front with thr current
upstream version. ;)


yes, thanks, much appreciated.

--
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/


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

Bug#692188: RM: ruby-pgplot/0.1.3-2

[Michael Gilbert]

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

Please remove ruby-pgplot.  It has all kind of unfixed build issues
and multiple failed attempts at uploads to get the package in a
working state after rc fix for #675390:
https://buildd.debian.org/status/package.php?p=ruby-pgplot

It is a leaf package in contrib and has not yet been in a stable release.

Best wishes,
Mike


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

Bug#677146: python-uno uses unopkg from libreoffice-common in preinst without declaring Pre-Depends

[Michael Gilbert]

control: reopen -1

A lot going on in this bug report, but after a cursory look, it seems
that unstable would still be affected, and being an rc bug, I'm
reopening to appropriately track it as an unfixed issue there.

Best wishes,
Mike


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

Bug#692101: nmu

[Michael Gilbert]

On Sat, Nov 3, 2012 at 1:19 AM, Yaroslav Halchenko wrote:
> although patch should also take care about Hurd to be complete if would
> build there nicely... or better just remove that conditioning

Hurd isn't a release architecture, so it isn't urgent and probably
wouldn't be appreciated by the release team since they expect minimal
changes now.

Best wishes,
Mike


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

Bug#692101: nmu

[Yaroslav Halchenko]

although patch should also take care about Hurd to be complete if would
build there nicely... or better just remove that conditioning

On Sat, 03 Nov 2012, Yaroslav Halchenko wrote:

> Thanks! if interested -- re-upload without delay!

> On Sat, 03 Nov 2012, Michael Gilbert wrote:

> > control: tag -1 patch

> > Hi, I've uploaded an nmu fixing these issues to delayed/5.  Please see
> > attached patch.

> > Best wishes,
> > Mike
-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


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

Bug#692101: nmu

[Yaroslav Halchenko]

Thanks! if interested -- re-upload without delay!

On Sat, 03 Nov 2012, Michael Gilbert wrote:

> control: tag -1 patch

> Hi, I've uploaded an nmu fixing these issues to delayed/5.  Please see
> attached patch.

> Best wishes,
> Mike



-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


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

Bug#691179:

[James Peach]

I applied Konstantinos' patch upstream in 
https://issues.apache.org/jira/browse/TS-1560

J


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

Bug#691641: debdelta: Packages whose version number contains a colon not upgraded

[Carlos Maddela]

Dear A,

I have upgraded to the 0.50+1 and still experience the same problem.

What I failed to mention last time was that I use a proxy.  If no proxy 
is used, indeed
the deltas are downloaded, but with a proxy, the deltas are reported as 
not being present.
While the patch I suggested fixes the problem when a proxy is used, it 
also messes

things up when no proxy is used.

Another problem that is probably related to this one, is i386 deltas not 
being downloaded,

but I'm still looking into it.

I'm not sure what the protocol is for following up on a bug that has 
already been closed.


Thanks,

Carlos

A Mennucc wrote:

Dear Carlos,

thanks for reporting!

I analyzed the problem, but it is not as you thought: indeed the URL is
encoded properly, using urllib2.quote(); and the server logs show that
epoch-ed deltas are correctly downloaded.

I rather think that you had seen a different problem! There was bug that
occoured with many KDE packages: those contain a broken symlink, and
'debdelta-upgrade' would consider them damaged, and not update them. We
noted this some weeks ago, I prepared a patch, and tested it, and now it
is in the new 0.50+1 version that soon will be in wheezy.

a.

On 27/10/2012 23:09, Carlos Maddela wrote:

Package: debdelta
Version: 0.50
Severity: normal

Dear Maintainer,

Not sure if this is a configuration problem on the debdeltas.debian.net
server, but packages whose version number contains a colon, such as
those found in pool/main/k/kde4libs, are not upgraded.  debdelta-upgrade
will report that their debdeltas are not present on the server, even
though they are in fact available.

The problem is that the debdeltas are stored with URL encoding on the
server.  For example, a debdelta file name would be:

 kdelibs-bin_4%3a4.8.4-3_4%3a4.8.4-4_amd64.debdelta

instead of the expected:

 kdelibs-bin_4:4.8.4-3_4:4.8.4-4_amd64.debdelta

If the former is how debdeltas should be stored on the server, then
debdelta-upgrade should instead request the above example as:

 kdelibs-bin_4%253a4.8.4-3_4%253a4.8.4-4_amd64.debdelta

I have attached a patch to fix this problem, should this be the case.
Otherwise, the server should be reconfigured.


-- System Information:
Debian Release: wheezy/sid
   APT prefers unstable
   APT policy: (990, 'unstable'), (500, 'stable')
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 debdelta depends on:
ii  binutils2.22-7.1
ii  bzip2   1.0.6-4
ii  libbz2-1.0  1.0.6-4
ii  libc6   2.13-36
ii  python  2.7.3-3
ii  zlib1g  1:1.2.7.dfsg-13

Versions of packages debdelta recommends:
ii  bsdiff   4.3-14
ii  gnupg-agent  2.0.19-1
ii  gnupg2   2.0.19-1
ii  lzma 9.22-2
ii  python-apt   0.8.8
ii  xdelta   1.1.3-9
ii  xdelta3  3.0.0.dfsg-1
ii  xz-utils [lzma]  5.1.1alpha+20120614-1

Versions of packages debdelta suggests:
ii  debdelta-doc  0.50

-- 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#692101: nmu

[Michael Gilbert]

control: tag -1 patch

Hi, I've uploaded an nmu fixing these issues to delayed/5.  Please see
attached patch.

Best wishes,
Mike


pyepl.patch
Description: Binary data

Bug#692187: file conflict between iptables and libxtables9, failing upgrades

[Michael Biebl]

Package: libxtables9
Version: 1.4.16.3-3
Severity: serious

libxtables9 has been moved into a separate binary package.
The package fails to upgrade due to missing versioned Breaks/Replaces.
See debian policy §7.6.1, "Overwriting files in other packages".


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

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

Versions of packages libxtables9 depends on:
ii  libc6  2.13-36

libxtables9 recommends no packages.

libxtables9 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#692186: pnmtofiasco can't read valid PNM files created by netpbm

[Andrew Buckeridge]

Package: netpbm
Version: 2:10.0-12.2+b1

pnmtofiasco: bad magic number - not a ppm, pgm, or pbm file
with output of pnmnorm, but this same output was accepted by pnmtojpeg

Steps to reproduce:

# pngtopnm file.png | pnmnorm -bpercent 1 -wpercent 1 | pnmtojpeg --quality=70 
--dct=float --progressive --optimize --sample=2x2 >file.jpg

JPEG works.

# pngtopnm file.png | pnmnorm -bpercent 1 -wpercent 1 | pnmtofiasco >file.wfa

> pnmtofiasco: bad magic number - not a ppm, pgm, or pbm file

# ls -l file.*
-rw-r--r-- 1 andrewb andrewb 39448 Nov  3 11:18 file.jpg
-rw-r--r-- 1 andrewb andrewb 42249 Nov  3 11:17 file.png
-rw-r--r-- 1 andrewb andrewb 0 Nov  3 11:19 file.wfa

See https://bugzilla.redhat.com/show_bug.cgi?id=227283

> Width and height of images must be even numbers.

If I make the input an even numbered seekable file, I still get no
output.

> *** glibc detected *** pnmtofiasco: corrupted double-linked list: 0x1067e0d8 
> ***
> === Backtrace: =
> /lib/libc.so.6(+0x83224)[0xfde2224]
> /lib/libc.so.6(+0x84eb8)[0xfde3eb8]
> /lib/libc.so.6(cfree+0x8c)[0xfde789c]
> pnmtofiasco[0x10026dd8]
> pnmtofiasco[0x1000ae9c]
> pnmtofiasco[0x10012ad8]
> pnmtofiasco[0x100133e8]
> pnmtofiasco[0x100133e8]
> pnmtofiasco[0x100133e8]
> pnmtofiasco[0x100133e8]
> pnmtofiasco[0x100133e8]
> pnmtofiasco[0x100133e8]
> pnmtofiasco[0x100133e8]
> pnmtofiasco[0x100133e8]
> pnmtofiasco[0x100133e8]
> pnmtofiasco[0x10004588]
> pnmtofiasco[0x10001950]
> /lib/libc.so.6(+0x1f69c)[0xfd7e69c]
> /lib/libc.so.6(+0x1f860)[0xfd7e860]
> === Memory map: 
> 0010-00103000 r-xp  00:00 0  [vdso]
> 0fd5f000-0fec9000 r-xp  03:02 214468 /lib/libc-2.11.3.so
> 0fec9000-0fed9000 ---p 0016a000 03:02 214468 /lib/libc-2.11.3.so
> 0fed9000-0fedd000 r--p 0016a000 03:02 214468 /lib/libc-2.11.3.so
> 0fedd000-0fede000 rw-p 0016e000 03:02 214468 /lib/libc-2.11.3.so
> 0fede000-0fee1000 rw-p  00:00 0 
> 0fef1000-0ff9b000 r-xp  03:02 214472 /lib/libm-2.11.3.so
> 0ff9b000-0ffab000 ---p 000aa000 03:02 214472 /lib/libm-2.11.3.so
> 0ffab000-0ffae000 r--p 000aa000 03:02 214472 /lib/libm-2.11.3.so
> 0ffae000-0ffaf000 rw-p 000ad000 03:02 214472 /lib/libm-2.11.3.so
> 0ffbf000-0ffdd000 r-xp  03:02 197624 /usr/lib/libnetpbm.so.10.0
> 0ffdd000-0ffed000 ---p 0001e000 03:02 197624 /usr/lib/libnetpbm.so.10.0
> 0ffed000-0fff rw-p 0001e000 03:02 197624 /usr/lib/libnetpbm.so.10.0
> 1000-1002b000 r-xp  03:02 347315 /usr/bin/pnmtofiasco
> 1003b000-1003c000 rw-p 0002b000 03:02 347315 /usr/bin/pnmtofiasco
> 1003c000-10071000 rwxp  00:00 0 
> 105f3000-106be000 rwxp  00:00 0  [heap]
> 4800-4802 r-xp  03:02 214480 /lib/ld-2.11.3.so
> 4802-48021000 rw-p  00:00 0 
> 48021000-48022000 r--p 00021000 03:02 214480 /lib/ld-2.11.3.so
> 48022000-48023000 rw-p 00022000 03:02 214480 /lib/ld-2.11.3.so
> 48041000-483c5000 rw-p  00:00 0 
> 4840-48421000 rw-p  00:00 0 
> 48421000-4850 ---p  00:00 0 
> bfda7000-bfdbc000 rw-p  00:00 0  [stack]
> Aborted


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

Bug#623106: Bug #623106: weather crash conky

[Vincent Cheng]

Hi Thomas,

Upstream has suggested that this patch[1] should fix this issue. It
seems to work for me (conky no longer spontaneously crashes with
multiple weather objects), but as I don't typically use ${weather} in
my own conkyrc, would it also be possible for you to test and confirm
this?

Regards,
Vincent

[1] 
http://git.omp.am/?p=conky.git;a=commitdiff;h=cbc131ea6c601beecb40439eb86f7e6d48b72167


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

Bug#692185: Please support Alpha on python-greenlet

[Michael Cree]

Source: python-greenlet
Version: 0.4.0-1
Severity: wishlist
User: debian-al...@lists.debian.org
Usertags: alpha
X-Debbugs-CC: debian-al...@lists.debian.org
Tags: patch

python-greenlet FTBFS on Alpha due to missing architecture support.  The 
attached patch provides the missing function needed to compile python-greenlet 
on Alpha.  With the patch the build passes all the tests in the included test 
suite.

Cheers
Michael.
diff -Nurp python-greenlet-0.4.0.orig/platform/switch_alpha_unix.h python-greenlet-0.4.0/platform/switch_alpha_unix.h
--- python-greenlet-0.4.0.orig/platform/switch_alpha_unix.h	1970-01-01 12:00:00.0 +1200
+++ python-greenlet-0.4.0/platform/switch_alpha_unix.h	2012-11-03 16:01:56.0 +1300
@@ -0,0 +1,39 @@
+/*
+ * this is the internal transfer function.
+ *
+ * HISTORY
+ * 2012-11-01 M. J. Cree
+ *  Ported from extant code for other arches.
+ */
+
+#define STACK_REFPLUS 1
+
+#ifdef SLP_EVAL
+
+#define STACK_MAGIC 0
+
+
+#define REGS_TO_SAVE "$9", "$10", "$11", "$12", "$13", "$14", "$15", \
+   "$26"
+
+static int
+slp_switch(void)
+{
+register int *stackref, stsizediff;
+__asm__ __volatile__ ("" : : : REGS_TO_SAVE);
+__asm__ ("mov $sp, %0" : "=r" (stackref) : );
+{
+SLP_SAVE_STATE(stackref, stsizediff);
+__asm__ __volatile__ (
+"addq $sp, %0, $sp\n"
+"addq $fp, %0, $fp\n"
+: /* no outputs */
+: "r" (stsizediff)
+);
+SLP_RESTORE_STATE();
+}
+__asm__ __volatile__ ("" : : : REGS_TO_SAVE);
+return 0;
+}
+
+#endif
diff -Nurp python-greenlet-0.4.0.orig/slp_platformselect.h python-greenlet-0.4.0/slp_platformselect.h
--- python-greenlet-0.4.0.orig/slp_platformselect.h	2012-05-13 08:56:32.0 +1200
+++ python-greenlet-0.4.0/slp_platformselect.h	2012-11-03 16:01:49.0 +1300
@@ -32,4 +32,6 @@
 #include "platform/switch_arm32_gcc.h" /* gcc using arm32 */
 #elif defined(__GNUC__) && defined(__mips__) && defined(__linux__)
 #include "platform/switch_mips_unix.h" /* Linux/MIPS */
+#elif defined(__GNUC__) && defined(__alpha__)
+#include "platform/switch_alpha_unix.h" /* Alpha AXP */
 #endif

Bug#691140: libmagickcore-dev uses out of date libtiff4-dev

[David Prévot]

Control: reassign -1 src:xastir
Control: forcemerge 666589 -1
Control: affects 666589 libgeotiff-dev

On Wed, Oct 24, 2012 at 12:02:30PM +0200, Bastien ROUCARIES wrote:

> I do not believe it is a bug but reassign to libgeotiff
> 
> In fact imagemagick is depending on libtiff of the day and until
> transition is done it is libtiff4. So libgeotiff need to depend on
> libtiff4 (except if not possible)

The affected package (xastir) has been removed from testing three months
ago. Merging this bug with the FTBFS one, that already contains a
workaround, including a patch against libgeotiff-dfsg (thus the
affects).

Regards

David


signature.asc
Description: Digital signature

Bug#692184: pyepl: creates empty packages when built with gcc 4.7

[Michael Gilbert]

package: pyepl
version: 1.1.0-3
severity: serious

The pyepl packages are empty when built with gcc 4.7,
code/hardware/eeg/pulse/parallel.h needs "#include "

Best wishes,
Mike


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

Bug#692182: libxtables9: file conflict with iptables 1.4.16.3-1

[Jonathan Nieder]

Jonathan Nieder wrote:

> --- i/debian/control
> +++ w/debian/control
> @@ -23,6 +23,8 @@ Description: administration tools for packet filtering and 
> NAT
>  Package: libxtables9
>  Architecture: any
>  Depends: ${misc:Depends}, ${shlibs:Depends}
> +Breaks: iptables (= 1.4.16.3-1), iptables (= 1.4.16.3-2)
> +Replaces: iptables (= 1.4.16.3-1), iptables (= 1.4.16.3-2)

Oops, I can read, really.

Here's a corrected patch.

diff --git i/debian/changelog w/debian/changelog
index 549281d5..b3db8ddb 100644
--- i/debian/changelog
+++ w/debian/changelog
@@ -1,3 +1,10 @@
+iptables (1.4.16.3-3.1) local; urgency=low
+
+  * Added breaks and replaces by libxtables9 against iptables 1.4.16.3-1.
+Prevents file conflicts during upgrade.
+
+ -- Jonathan Nieder   Fri, 02 Nov 2012 20:05:05 -0700
+
 iptables (1.4.16.3-3) unstable; urgency=low
 
   * Added versioned libxtables dependency 
diff --git i/debian/control w/debian/control
index 2e4c9e56..78b1c4e6 100644
--- i/debian/control
+++ w/debian/control
@@ -23,6 +23,8 @@ Description: administration tools for packet filtering and NAT
 Package: libxtables9
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
+Breaks: iptables (= 1.4.16.3-1)
+Replaces: iptables (= 1.4.16.3-1)
 Description: netfilter xtables library
  The user-space interface to the Netfilter xtables kernel framework.
 


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

Bug#692183: unblock: gdebi/0.8.7

[Luca Falavigna]

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

Please unblock package gdebi

This upload fixes RC bug #691998, plus some crashes bugs reported in Launchpad:
* Do not set a busy cursor if there is no X11 window
   https://launchpad.net/bugs/1055181
* Define apt.Cache in class initialization
   https://launchpad.net/bugs/1072799
* Add file to gdebi-core dependencies
   https://launchpad.net/bugs/1067306

I'm attaching a debdiff of the changes introduced.

unblock gdebi/0.8.7

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
=== modified file 'GDebi/GDebi.py'
--- GDebi/GDebi.py	2012-10-11 19:21:07 +
+++ GDebi/GDebi.py	2012-10-11 20:09:07 +
@@ -145,13 +145,19 @@
 self.synaptic_config = apt_pkg.Configuration()
 
 if file != "" and os.path.exists(file):
-self.window_main.get_window().set_cursor(Gdk.Cursor.new(Gdk.CursorType.WATCH))
+self.open(file)
+self.window_main.set_sensitive(True)
+
+def _show_busy_cursor(self, show_busy_cursor):
+win = self.window_main.get_window()
+if not win:
+return
+if show_busy_cursor:
+win.set_cursor(Gdk.Cursor.new(Gdk.CursorType.WATCH))
 while Gtk.events_pending(): 
 Gtk.main_iteration()
-self.open(file)
-self.window_main.get_window().set_cursor(None)
-
-self.window_main.set_sensitive(True)
+else:
+win.set_cursor(None)
 
 def gio_progress_callback(self, bytes_read, bytes_total, data):
 self.progressbar_download.set_fraction(bytes_read/float(bytes_total))
@@ -224,14 +230,12 @@
 path = self._get_file_path_from_dnd_dropped_uri(uri)
 #print 'path to open', path
 if path.endswith(".deb"):
-self.window_main.get_window().set_cursor(Gdk.Cursor.new(Gdk.CursorType.WATCH))
-while Gtk.events_pending(): 
-Gtk.main_iteration()
 self.open(path)
-self.window_main.get_window().set_cursor(None)
 
 def open(self, file, downloaded=False):
+self._show_busy_cursor(True)
 res = GDebiCommon.open(self, file, downloaded)
+self._show_busy_cursor(False)
 if res == False:
 self.show_alert(Gtk.MessageType.ERROR, self.error_header, self.error_body)
 return False

=== modified file 'GDebi/GDebiCli.py'
--- GDebi/GDebiCli.py	2012-10-11 19:23:54 +
+++ GDebi/GDebiCli.py	2012-11-02 13:29:24 +
@@ -122,10 +122,7 @@
 iprogress = apt.progress.base.InstallProgress()
 try:
 res = self._cache.commit(fprogress,iprogress)
-except apt.cache.FetchFailedException, e:
-sys.stderr.write(_("Error during install: '%s'") % e)
-return 1
-except SystemError, e:
+except (apt.cache.FetchFailedException, SystemError), e:
 sys.stderr.write(_("Error during install: '%s'") % e)
 return 1
 

=== modified file 'GDebi/GDebiCommon.py'
--- GDebi/GDebiCommon.py	2012-09-12 21:28:17 +
+++ GDebi/GDebiCommon.py	2012-11-02 13:29:24 +
@@ -52,6 +52,7 @@
 # cprogress may be different in child classes
 def __init__(self, datadir, options, file=""):
 self.cprogress = None
+self._cache = None
 self.deps = ""
 self.version_info_title = ""
 self.version_info_msg = ""

=== modified file 'debian/changelog'
--- debian/changelog	2012-10-11 20:07:12 +
+++ debian/changelog	2012-11-02 16:36:21 +
@@ -1,3 +1,23 @@
+gdebi (0.8.7) unstable; urgency=low
+
+  [ Michael Vogt ]
+  * GDebi/GDebi.py:
+- do not set a busy cursor if there is no X11 window (LP: #1055181).
+
+  [ Jason Conti ]
+  * GDebi/GDebiCommon.py:
+- Define apt.Cache in class initialization (LP: #1072799).
+
+  [ Luca Falavigna ]
+  * gdebi-kde:
+- Do not use unicode in help options (Closes: #691998, LP: #1063114).
+  * GDebi/GDebiCli.py:
+- Improve exception handling.
+  * debian/control:
+- Add file to gdebi-core dependencies (LP: #1067306).
+
+ -- Luca Falavigna   Fri, 02 Nov 2012 17:36:06 +0100
+
 gdebi (0.8.6) unstable; urgency=low
 
   * gdebi, GDebi/GDebiCli.py:

=== modified file 'debian/control'
--- debian/control	2012-09-12 21:17:04 +
+++ debian/control	2012-11-02 12:30:07 +
@@ -16,7 +16,8 @@
 Depends: ${python:Depends},
  ${misc:Depends},
  python-apt (>= 0.7.97),
-	 python-debian (>= 0.1.15)
+ python-debian (>= 0.1.15),
+ file
 Suggests: xz-utils | xz-lzma
 Description: simple tool to install deb files
  gdebi lets you install local deb packages resolving and installing 

=== modified file 'gdebi-kde'
--- gdebi-kde	2012-09

Bug#692182: libxtables9: file conflict with iptables 1.4.16.3-1

[Jonathan Nieder]

Package: libxtables9
Version: 1.4.16.3-3
Tags: patch

Hi,

From today's upgrade:

| Unpacking libxtables9 (from .../libxtables9_1.4.16.3-3_amd64.deb) ...
| dpkg: error processing 
//var/cache/apt/archives/libxtables9_1.4.16.3-3_amd64.deb (--install):
|  trying to overwrite '/lib/libxtables.so.9.0.0', which is also in package 
iptables 1.4.16.3-1

How about this patch?

I'll send a symbols file to make the package policy §8.6 compliant
later tonight.

diff --git i/debian/changelog w/debian/changelog
index 549281d5..db52ea4f 100644
--- i/debian/changelog
+++ w/debian/changelog
@@ -1,3 +1,11 @@
+iptables (1.4.16.3-3.1) local; urgency=low
+
+  * Added breaks and replaces by libxtables9 against iptables versions
+that contained libxtables.so.9. Prevents file conflicts during
+upgrade.
+
+ -- Jonathan Nieder   Fri, 02 Nov 2012 20:03:18 -0700
+
 iptables (1.4.16.3-3) unstable; urgency=low
 
   * Added versioned libxtables dependency 
diff --git i/debian/control w/debian/control
index 2e4c9e56..fad3d2c8 100644
--- i/debian/control
+++ w/debian/control
@@ -23,6 +23,8 @@ Description: administration tools for packet filtering and NAT
 Package: libxtables9
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
+Breaks: iptables (= 1.4.16.3-1), iptables (= 1.4.16.3-2)
+Replaces: iptables (= 1.4.16.3-1), iptables (= 1.4.16.3-2)
 Description: netfilter xtables library
  The user-space interface to the Netfilter xtables kernel framework.
 


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

Bug#692173: aptitude.8: doesn't that line referrs to the show command?

[Daniel Hartwig]

Control: tags -1 + confirmed

On 3 November 2012 08:56, Regid Ichira  wrote:
> $ man aptitude | grep -B2 'listed following the search command'
>show
>Displays detailed information about one or more packages,
>listed following the search command. If a package name
>
> - With the patch:
>show
>Displays detailed information about one or more packages,
>listed following the show command. If a package name

The second part doesn't really make sense either way and should be
removed, though I don't want to disturb the translations at this point
so might leave this until after Wheezy.

Regards


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

Bug#639405: nmu

[Michael Gilbert]

Hi, I've uploaded an nmu fixing this issue.  Please see attached
patch, which might not be that meaningful since its just removing
files from the upstream tarball.

Best wishes,
Mike


python.patch
Description: Binary data

Bug#692132: tt-rss: Can not login

[Sebastian Reichel]

tags 692132 moreinfo
thanks

Hi Benedikt,

> On a fresh squeeze install when I try to log in I get this error: 
> {"error":{"code":7}}.
> Apache error log: 
> "File does not exist: /usr/share/tt-rss/www/lib/dojo/tt-rss-layer.js, 
> referer: mydomain/tt-rss"

This is not the actual problem. I will fix this in the next version :)

> How to reproduce this issue:
> apt-get install libjs-dojo-dijit/testing php-htmlpurifier/testing 
> libjs-dojo-core/testing
> apt-get install tt-rss/unstable

Please check the following things:

 * PHP's display_errors must be turned off for tt-rss, because of
   warnings printed by html purifier. These warnings invalidate
   the generated JSON.
 * If this is ok, please check your browser's javascript console
   for any errors.

-- Sebastian


signature.asc
Description: Digital signature

Bug#692154: Shouldn't description mention also 3.2 kernels?

[Jonathan Nieder]

severity 692154 minor
tags 692154 + patch
quit

Regid Ichira wrote:

>   Package description mentions 2.6 kernels.  These days, Debian also
> have 3.2 kernels.  Shouldn't the description mention those kernels
> too?

How about this patch?

Thanks,
Jonathan

Index: changelog
===
--- changelog   (révision 5364)
+++ changelog   (copie de travail)
@@ -1,6 +1,9 @@
 eglibc (2.13-37) UNRELEASED; urgency=low
 
-  * 
+  [ Jonathan Nieder ]
+  * control.in/opt: remove outdated reference to 2.6 kernel from
+description of i686 variant.  Thanks to Regid Ichira.  Closes:
+#692154.
 
  -- Aurelien Jarno   Fri, 26 Oct 2012 19:26:34 +0200
 
Index: control.in/opt
===
--- control.in/opt  (révision 5364)
+++ control.in/opt  (copie de travail)
@@ -11,10 +11,10 @@
  library and the standard math library, as well as many others.
  .
  This set of libraries is optimized for i686 machines, and will only be
- used if you are running a 2.6 kernel on an i686 class CPU (check the 
- output of `uname -m').  This includes Pentium Pro, Pentium II/III/IV, 
- Celeron CPU's and similar class CPU's (including clones such as AMD 
- Athlon/Opteron, VIA C3 Nehemiah, but not VIA C3 Ezra).  
+ used on an i686 class CPU (check the output of `uname -m').  This includes 
+ Pentium Pro, Pentium II/III/IV, Celeron CPU's and similar class CPU's
+ (including clones such as AMD Athlon/Opteron, VIA C3 Nehemiah, but not VIA 
+ C3 Ezla).  
 
 Package: libc6-xen
 Architecture: i386


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

Bug#692181: libnet-amazon-s3-perl: HTTPRequest.pm incomplete S3 protocol support

[Erik Anderson]

Package: libnet-amazon-s3-perl
Version: 0.53-1
Severity: minor
Tags: patch

As seems to often be the case, attempts to use a library beyond its stated 
capabilities results in discoveries of incomplete coding.

I do recognize there is a newer version of this library, however looking over 
it appears to indicate similar business rules in this area.

Proposed feature changes to HTTPRequest.pm:

Methods
Old rule: permits DELETE, GET, HEAD, PUT
New rule: permits DELETE, GET, HEAD, PUT, POST

Sub-resources
Old rule: permits one of acl, torrent, location
New rule: permits one each of acl, lifecycle, location, logging, notification, 
partNumber, policy, requestPayment, torrent, uploadId, uploads, versionId, 
versioning, versions, website

Sample code:

sub initiateMultipartUpload
{
  my $path = shift;
  my $newUpload = Net::Amazon::S3::HTTPRequest->new({
s3 => $s3,
method => 'POST',
# $s3->_urlescape escapes dots and slashes, uri_escape_utf8 escapes 
slashes.  Why?
path => $config->path . uri_escape_utf8($path, '^A-Za-z0-9\-\._~\x2f') . 
'?uploads'
  });

  my $newUploadReq = $newUpload->http_request;
  #die $newUploadReq->as_string;
  my $xpc = $s3->_send_request($newUploadReq);
  # Amazon isn't returning a Content-Type for this request, so it likely won't 
be parsed for us
  $xpc = $s3->_xpc_of_content($xpc) if ( $xpc && !ref($xpc) );
  return undef unless $xpc && !$s3->_remember_errors($xpc);

  my $bucket = $xpc->findvalue("//s3:Bucket");
  my $key = $xpc->findvalue("//s3:Key");
  my $uploadID = $xpc->findvalue("//s3:UploadId");

  return {
bucket => $bucket,
key => $key,
upload_id => $uploadID
  };
}

Please note that perl is not my first language, I would be very suprised if 
there were not issues with style or not doing things "the perl way"

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

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

Versions of packages libnet-amazon-s3-perl depends on:
ii  libclass-accessor-perl 0.34-1Perl module that automatically gen
ii  libdata-stream-bulk-pe 0.07-1N at a time iteration API
ii  libdatetime-format-htt 0.39-1Perl module for date conversion wi
ii  libdatetime-format-iso 0.06-2Perl module to parse ISO8601 date 
ii  libdigest-hmac-perl1.02+dfsg-1   module for creating standard messa
ii  libdigest-md5-file-per 0.07-1Perl extension for getting MD5 sum
ii  liblwp-useragent-deter 1.04-1LWP useragent that retries errors
ii  libmoose-perl  1.09-2modern Perl object system framewor
ii  libmoosex-strictconstr 0.10-1Make your object constructors blow
ii  libmoosex-types-dateti 0.03-1Perl DateTime related constraints 
ii  libregexp-common-perl  2010010201-1  module with common regular express
ii  liburi-perl1.54-2module to manipulate and access UR
ii  libwww-perl5.836-1   Perl HTTP/WWW client/server librar
ii  libxml-libxml-perl 1.70.ds-1 Perl interface to the libxml2 libr
ii  perl   5.10.1-17squeeze3 Larry Wall's Practical Extraction 

libnet-amazon-s3-perl recommends no packages.

libnet-amazon-s3-perl suggests no packages.

-- no debconf information
*** /usr/share/perl5/Net/Amazon/S3/HTTPRequest-old.pm	2012-11-02 01:04:25.0 -0700
--- /usr/share/perl5/Net/Amazon/S3/HTTPRequest.pm	2012-11-02 18:17:15.0 -0700
***
*** 10,16 
  my $METADATA_PREFIX  = 'x-amz-meta-';
  my $AMAZON_HEADER_PREFIX = 'x-amz-';
  
! enum 'HTTPMethod' => qw(DELETE GET HEAD PUT);
  
  has 's3' => ( is => 'ro', isa => 'Net::Amazon::S3', required => 1 );
  has 'method' => ( is => 'ro', isa => 'HTTPMethod',  required => 1 );
--- 10,16 
  my $METADATA_PREFIX  = 'x-amz-meta-';
  my $AMAZON_HEADER_PREFIX = 'x-amz-';
  
! enum 'HTTPMethod' => qw(DELETE GET HEAD PUT POST);
  
  has 's3' => ( is => 'ro', isa => 'Net::Amazon::S3', required => 1 );
  has 'method' => ( is => 'ro', isa => 'HTTPMethod',  required => 1 );
***
*** 24,29 
--- 24,48 
  
  __PACKAGE__->meta->make_immutable;
  
+ # list of sub-resources that must be included (if they are specified) in any cannonical string
+ %__PACKAGE__::sub_resources = (
+   'acl' => 1,
+   'lifecycle' => 1,
+   'location' => 1,
+   'logging' => 1,
+   'notification' => 1,
+   'partNumber' => 1,
+   'policy' => 1,
+   'requestPayment' => 1,
+   'torrent' => 1,
+   'uploadId' => 1,
+   'uploads' => 1,
+   'versionId' => 1,
+   'versioning' => 1,
+   'versions' => 1,
+   'website' => 1
+ );
+ 
  # make the HTTP::Request object
  sub http_request {
  my $self = shift;
***
*** 134,150 
  }
  }
  
! # don't include anything after the first ? in the resource...
! 

Bug#665199: fix for rc bug #665199

[Michael Gilbert]

On Fri, Nov 2, 2012 at 10:11 AM, gustavo panizzo  wrote:
> hello, i've prepared  an updated version of slapd package which fix
> the bug #665199

Hi, I've just reviewed this, and it looks reasonable.  However, the
changelog note is not really descriptive enough:

  * Fix a bug while upgrading from squeeze to wheezy (Closes: #665199).

Could you be a bit clearer?  Something along the lines of "regenerate
slapd database in postinst during upgrade process" would be good.

Thanks,
Mike


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

Bug#692180: PS: My workaround stopped working

[Kingsley G. Morse Jr.]

PS: My workaround stopped working.

Changing the file's base name also worked
temporarily.

I hope that helps,
Kingsley


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

Bug#692180: Passing file names with the extension .JPG on the command line hangs openshot

[Kingsley G. Morse Jr.]

Package: openshot
Version: 1.4.3-1
Severity: normal


Thanks for maintaining Debian's openshot package.

I like it.

I happened to notice that running openshot on the
command line and passing it a file ending with the
uppercase extension ".JPG" throws openshot into a
loop.

For example

$ openshot file.JPG


Window after window is opened saying

"Would you like to import file.JPG as an image sequence?

YesNo"


I let it keep running for about half a minute and
it showed no sign of stopping opening windows or
of becoming usable.

I revealed openshot's PID with

$ ps aux | egrep openshot

and put it out of its misery with 

$ kill -9 

A workaround for the bug is to copy or rename the
file to one with a lower case extension.

For example:

$ cp file.JPG file.jpg

$ openshot file.jpg

I hope that helps,
Kingsley

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

Kernel: Linux 3.0.0-1-686-pae (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/bash

Versions of packages openshot depends on:
ii  fontconfig  2.8.0-3  generic font configuration library
ii  gtk2-engines-pixbuf 2.24.10-2pixbuf-based theme for GTK+ 2.x
ii  librsvg2-common 2.36.1-1 SAX-based renderer library for SVG
ii  melt1:0.8.0-dmo2 command line media player and vide
ii  python  2.7.2-9  interactive high-level object-orie
ii  python-gtk2 2.24.0-2 Python bindings for the GTK+ widge
ii  python-httplib2 0.7.4-2  comprehensive HTTP client library 
ii  python-imaging  1.1.7-4  Python Imaging Library
ii  python-mlt5 1:0.8.0-dmo2 multimedia framework (python bindi
ii  python-pygoocanvas  0.14.1-1+b3  GooCanvas Python bindings
ii  python-support  1.0.14   automated rebuilding support for P
ii  python-xdg  0.19-3   Python library to access freedeskt

Versions of packages openshot recommends:
ii  frei0r-plugins 1.1.22git20091109-1.2 minimalistic plugin API for video 
ii  openshot-doc   1.4.2-dmo1Help manual for OpenShot Video Edi

Versions of packages openshot suggests:
ii  blender   2.63-1 Very fast and versatile 3D modelle
pn  inkscape   (no description available)

-- 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#692179: fusedav: fix flush and release of open files

[Eric Wong]

Package: fusedav
Version: 0.2-3
Severity: normal
Tags: upstream patch

This is a two-part fix

Subject: [PATCH 12/13] implement dav_flush to avoid race from dav_release

dav_release unlinks a file from the cache before syncing,
allowing a concurrent thread to open a new cached entry
against stale file data.  So ensure we implement dav_flush
as libfuse2 will always flush before release.

Subject: [PATCH 13/13] fix release() with multiple open() to the same path

dav_release() should not unlink a file from the cache until its
ref count drops to zero.  The ref count may be non-zero after
release because because dav_open() may be called multiple times
without a dav_release() in between, so relying on a boolean dead
flag is problematic.

Instead of relying on a boolean dead flag, rely on the ref count
of the file and only unlink it when the counter drops to zero.



Btw, all my patches are available in my git repository at
 git://bogomips.org/fusedav.git

I have made the "bugfix-only" branch for things I consider bugfixes
(including Sebastian's existing patches in Debian).  I also have "home"
for whatever I'm running at home (which may have more experimental
changes).
>From ad701acac54f8dcc60b697332c1a3ca1971cbc63 Mon Sep 17 00:00:00 2001
From: Eric Wong 
Date: Thu, 1 Nov 2012 23:24:36 +
Subject: [PATCH 12/13] implement dav_flush to avoid race from dav_release

dav_release unlinks a file from the cache before syncing,
allowing a concurrent thread to open a new cached entry
against stale file data.  So ensure we implement dav_flush
as libfuse2 will always flush before release.
---
 src/fusedav.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/src/fusedav.c b/src/fusedav.c
index 6a92799..69fed1b 100644
--- a/src/fusedav.c
+++ b/src/fusedav.c
@@ -549,7 +549,7 @@ finish:
 return r;
 }
 
-static int dav_fsync(const char *path, __unused int isdatasync, __unused 
struct fuse_file_info *info) {
+static int flush_internal(const char *fn, const char *path, __unused struct 
fuse_file_info *fi) {
 void *f = NULL;
 int r = 0;
 ne_session *session;
@@ -558,7 +558,7 @@ static int dav_fsync(const char *path, __unused int 
isdatasync, __unused struct
 
 path = path_cvt(path);
 if (debug)
-fprintf(stderr, "fsync(%s)\n", path);
+fprintf(stderr, "%s(%s)\n", fn, path);
 
 if (!(session = session_get(1))) {
 r = -EIO;
@@ -566,7 +566,7 @@ static int dav_fsync(const char *path, __unused int 
isdatasync, __unused struct
 }
 
 if (!(f = file_cache_get(path))) {
-fprintf(stderr, "fsync() called for closed file\n");
+fprintf(stderr, "%s() called for closed file\n", fn);
 r = -EFAULT;
 goto finish;
 }
@@ -590,6 +590,14 @@ finish:
 return r;
 }
 
+static int dav_flush(const char *path, struct fuse_file_info *fi) {
+   return flush_internal("flush", path, fi);
+}
+
+static int dav_fsync(const char *path, __unused int isdatasync, struct 
fuse_file_info *fi) {
+   return flush_internal("fsync", path, fi);
+}
+
 static int dav_mknod(const char *path, mode_t mode, __unused dev_t rdev) {
 char tempfile[PATH_MAX];
 int fd;
@@ -1167,6 +1175,7 @@ static struct fuse_operations dav_oper = {
 .chmod   = dav_chmod,
 .truncate   = dav_truncate,
 .utime   = dav_utime,
+.flush   = dav_flush,
 .open   = dav_open,
 .read   = dav_read,
 .write  = dav_write,
-- 
1.8.0.3.gdd57fab.dirty

>From 6fb7e3cf48c1cd4d07c4807e2ff3bd0fd6f14fb9 Mon Sep 17 00:00:00 2001
From: Eric Wong 
Date: Fri, 2 Nov 2012 23:56:24 +
Subject: [PATCH 13/13] fix release() with multiple open() to the same path

dav_release() should not unlink a file from the cache until its
ref count drops to zero.  The ref count may be non-zero after
release because because dav_open() may be called multiple times
without a dav_release() in between, so relying on a boolean dead
flag is problematic.

Instead of relying on a boolean dead flag, rely on the ref count
of the file and only unlink it when the counter drops to zero.
---
 src/filecache.c | 44 ++--
 src/filecache.h |  2 --
 src/fusedav.c   | 13 +
 3 files changed, 23 insertions(+), 36 deletions(-)

diff --git a/src/filecache.c b/src/filecache.c
index f291e15..eded0aa 100644
--- a/src/filecache.c
+++ b/src/filecache.c
@@ -57,7 +57,7 @@ struct file_info {
 
 int modified;
 
-int ref, dead;
+int ref;
 
 pthread_mutex_t mutex;
 
@@ -68,6 +68,7 @@ struct file_info {
 static struct file_info *files = NULL;
 static pthread_mutex_t files_mutex = PTHREAD_MUTEX_INITIALIZER;
 
+static void file_cache_unlink(struct file_info *fi);
 static int file_cache_sync_unlocked(struct file_info *fi);
 
 static void* file_cache_get_unlocked(const char *path) {
@@ -76,7 +77,7 @@ static void* file_cache_get_unlocked(const char *path) {
 for (f = files; f; f = f->next) {
 
 pthread_

Bug#692178: fusedav: [PATCH] filecache: clear modified flag after PUT sync

[Eric Wong]

Package: fusedav
Version: 0.2-3
Severity: wishlist
Tags: patch upstream

This prevents a redundant PUT for apps which call fsync()
before calling close().
>From fa8c3aca4178f7f6b8453dbfbcef34202b6ce96b Mon Sep 17 00:00:00 2001
From: Eric Wong 
Date: Thu, 25 Oct 2012 20:31:12 +
Subject: [PATCH 11/13] filecache: clear modified flag after PUT sync

This prevents a redundant PUT for apps which call fsync()
before calling close().
---
 src/filecache.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/filecache.c b/src/filecache.c
index f9b4075..f291e15 100644
--- a/src/filecache.c
+++ b/src/filecache.c
@@ -398,6 +398,7 @@ int file_cache_sync_unlocked(struct file_info *fi) {
 goto finish;
 }
 
+fi->modified = 0;
 stat_cache_invalidate(fi->filename);
 dir_cache_invalidate_parent(fi->filename);
 
-- 
1.8.0.3.gdd57fab.dirty

Bug#692177: fusedav: [PATCH] fix truncate (it was completely broken)

[Eric Wong]

Package: fusedav
Version: 0.2-3
Severity: normal
Tags: upstream patch

[PATCH] fix truncate (it was completely broken)

dav_truncate(): add braces to prevent early exit,
previously all calls to dav_truncate() were no-ops

file_cache_truncate(): set the fi->modified flag to ensure
file_cache_sync_unlocked() picks up the change.
Additionally, we need to update the fi->present offset
as we no longer have the truncated data cached.

load_up_to_unlocked(): limit retrieval to fi->length.  If we
truncate a file locally, we don't want to reload the data on the
server, instead we want to leave holes in the file if we write
beyond the truncation point.

I used the following Ruby test script to test this behavior.

 8< 
require 'test/unit'
class TestTruncate < Test::Unit::TestCase

  # Ideally this directory should be mounted with the auto_cache
  # FUSE mount option
  TEST_DIR = ENV["TEST_DIR"] or abort "TEST_DIR env needs to be set"

  def test_truncate
Dir.chdir(TEST_DIR) do
  File.open("truncate", "w") do |f|
f.write("HELLO WORLD")
  end
  assert system("sync") # try to work around lack of auto_cache

  File.open("truncate", "r+") do |f|
f.sync = true
f.truncate(0)
f.seek(5)
f.write "!"
  end
  assert system("sync") # try to work around lack of auto_cache
  assert_equal "\0\0\0\0\0!", File.read("truncate")
end
  end
end
 8< 
Usage: TEST_DIR=/path/to/fusedav/mount ruby /path/to/this_script.rb
>From d4b6e7b53634ac2577e64325ffadba2530bb98b8 Mon Sep 17 00:00:00 2001
From: Eric Wong 
Date: Thu, 25 Oct 2012 19:10:42 +
Subject: [PATCH 10/13] fix truncate (it was completely broken)

dav_truncate(): add braces to prevent early exit,
previously all calls to dav_truncate() were no-ops

file_cache_truncate(): set the fi->modified flag to ensure
file_cache_sync_unlocked() picks up the change.
Additionally, we need to update the fi->present offset
as we no longer have the truncated data cached.

load_up_to_unlocked(): limit retrieval to fi->length.  If we
truncate a file locally, we don't want to reload the data on the
server, instead we want to leave holes in the file if we write
beyond the truncation point.

I used the following Ruby test script to test this behavior.

 8< 
require 'test/unit'
class TestTruncate < Test::Unit::TestCase

  # Ideally this directory should be mounted with the auto_cache
  # FUSE mount option
  TEST_DIR = ENV["TEST_DIR"] or abort "TEST_DIR env needs to be set"

  def test_truncate
Dir.chdir(TEST_DIR) do
  File.open("truncate", "w") do |f|
f.write("HELLO WORLD")
  end
  assert system("sync") # try to work around lack of auto_cache

  File.open("truncate", "r+") do |f|
f.sync = true
f.truncate(0)
f.seek(5)
f.write "!"
  end
  assert system("sync") # try to work around lack of auto_cache
  assert_equal "\0\0\0\0\0!", File.read("truncate")
end
  end
end
 8< 
Usage: TEST_DIR=/path/to/fusedav/mount ruby /path/to/this_script.rb
---
 src/filecache.c | 6 ++
 src/fusedav.c   | 3 ++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/filecache.c b/src/filecache.c
index 08071fe..f9b4075 100644
--- a/src/filecache.c
+++ b/src/filecache.c
@@ -265,6 +265,9 @@ static int load_up_to_unlocked(struct file_info *fi, off_t 
l) {
 return -1;
 }
 
+if (l > fi->length)
+l = fi->length;
+
 if (l > fi->server_length)
 l = fi->server_length;
 
@@ -353,6 +356,9 @@ int file_cache_truncate(void *f, off_t s) {
 
 fi->length = s;
 r = ftruncate(fi->fd, fi->length);
+fi->modified = 1;
+if (fi->present > s)
+fi->present = s;
 
 pthread_mutex_unlock(&fi->mutex);
 
diff --git a/src/fusedav.c b/src/fusedav.c
index 4c95ea3..6a92799 100644
--- a/src/fusedav.c
+++ b/src/fusedav.c
@@ -710,9 +710,10 @@ static int dav_truncate(const char *path, off_t size) {
 if (debug)
 fprintf(stderr, "truncate(%s, %lu)\n", path, (unsigned long) size);
 
-if (!(session = session_get(1)))
+if (!(session = session_get(1))) {
 r = -EIO;
 goto finish;
+}
 
 if (!(f = file_cache_get(path))) {
 fprintf(stderr, "truncate() called for closed file\n");
-- 
1.8.0.3.gdd57fab.dirty

Bug#692176: arandr: does not provide menu file

[Claude Rubinson]

Package: arandr
Version: 0.1.6-1
Severity: normal

arandr does not register a menu entry in the Debian menu system

-- Package-specific info:
Output of /usr/share/bug/arandr:
$ xrandr --version
xrandr program version   1.3.5
Server reports RandR version 1.3
$ xrandr --query --current
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192
LVDS1 connected (normal left inverted right x axis y axis)
   1440x900   60.0 +   59.9 50.0  
   1360x768   59.8 60.0  
   1152x864   60.0  
   1024x768   60.0  
   800x60060.3 56.2  
   640x48059.9  
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm 
x 301mm
   1280x1024  60.0*+   75.0  
   1152x864   75.0  
   1024x768   75.1 60.0  
   800x60075.0 60.3  
   640x48075.0 60.0  
   720x40070.1  
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)
$ xrandr --query --current --verbose
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192
LVDS1 connected (normal left inverted right x axis y axis)
Identifier: 0x41
Timestamp:  13253657
Subpixel:   horizontal rgb
Clones:
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
EDID:
000030ae3640
00120103801e1378eae59593564f9028
2850540001010101010101010101
010101010101c129a0e451841a303020
36002fbe1019de22a02c51847e30
302036002fbe1019000f0095
0a32950a281e09004ca3425400fe
004c544e3134314254303830303100cb
BACKLIGHT: 0 (0x)   range:  (0,15)
Backlight: 0 (0x)   range:  (0,15)
scaling mode:   Full aspect
supported: None Full Center   Full aspect 
  1440x900 (0x49)  106.9MHz -HSync -VSync +preferred
h: width  1440 start 1488 end 1520 total 1924 skew0 clock   55.6KHz
v: height  900 start  903 end  909 total  926   clock   60.0Hz
  1440x900 (0x4a)  106.5MHz -HSync +VSync
h: width  1440 start 1520 end 1672 total 1904 skew0 clock   55.9KHz
v: height  900 start  903 end  909 total  934   clock   59.9Hz
  1440x900 (0x4b)   89.3MHz -HSync -VSync
h: width  1440 start 1488 end 1520 total 1740 skew0 clock   51.3KHz
v: height  900 start  903 end  909 total 1026   clock   50.0Hz
  1360x768 (0x4c)   84.8MHz -HSync +VSync
h: width  1360 start 1432 end 1568 total 1776 skew0 clock   47.7KHz
v: height  768 start  771 end  781 total  798   clock   59.8Hz
  1360x768 (0x4d)   72.0MHz +HSync -VSync
h: width  1360 start 1408 end 1440 total 1520 skew0 clock   47.4KHz
v: height  768 start  771 end  781 total  790   clock   60.0Hz
  1152x864 (0x4e)   81.6MHz -HSync +VSync
h: width  1152 start 1216 end 1336 total 1520 skew0 clock   53.7KHz
v: height  864 start  865 end  868 total  895   clock   60.0Hz
  1024x768 (0x4f)   65.0MHz -HSync -VSync
h: width  1024 start 1048 end 1184 total 1344 skew0 clock   48.4KHz
v: height  768 start  771 end  777 total  806   clock   60.0Hz
  800x600 (0x50)   40.0MHz +HSync +VSync
h: width   800 start  840 end  968 total 1056 skew0 clock   37.9KHz
v: height  600 start  601 end  605 total  628   clock   60.3Hz
  800x600 (0x51)   36.0MHz +HSync +VSync
h: width   800 start  824 end  896 total 1024 skew0 clock   35.2KHz
v: height  600 start  601 end  603 total  625   clock   56.2Hz
  640x480 (0x52)   25.2MHz -HSync -VSync
h: width   640 start  656 end  752 total  800 skew0 clock   31.5KHz
v: height  480 start  490 end  492 total  525   clock   59.9Hz
VGA1 disconnected (normal left inverted right x axis y axis)
Identifier: 0x42
Timestamp:  13253657
Subpixel:   unknown
Clones:
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
HDMI1 connected 1280x1024+0+0 (0xc3) normal (normal left inverted right x axis 
y axis) 376mm x 301mm
Identifier: 0x43
Timestamp:  13253657
Subpixel:   unknown
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC:   1
 

Bug#692175: fusedav: concurrent dav_open can result in duplicate cache entries

[Eric Wong]

Package: fusedav
Version: 0.2-3
Severity: normal
Tags: patch upstream

[PATCH] file_cache: prevent duplicate entries on concurrent open

Calling file_cache_open() concurrently with the same path can
result in duplicate entries.  Instead, hold onto the files_mutex
lock through the check and insertion.

To maximize concurrency with slow HEAD requests, we only insert
a locked dummy entry while files_mutex, and slowly populate the
new entry when files_mutex is unlocked (but fi->mutex is still
held).  Holding fi->mutex for the new entry will prevent
thundering herds on the WebDAV server if we are hit by many
opens at once.
>From 8ddaa7a0a9d19d913b9acf92f6056aea72267d83 Mon Sep 17 00:00:00 2001
From: Eric Wong 
Date: Thu, 25 Oct 2012 01:56:27 +
Subject: [PATCH 09/13] file_cache: prevent duplicate entries on concurrent
 open

Calling file_cache_open() concurrently with the same path can
result in duplicate entries.  Instead, hold onto the files_mutex
lock through the check and insertion.

To maximize concurrency with slow HEAD requests, we only insert
a locked dummy entry while files_mutex, and slowly populate the
new entry when files_mutex is unlocked (but fi->mutex is still
held).  Holding fi->mutex for the new entry will prevent
thundering herds on the WebDAV server if we are hit by many
opens at once.
---
 src/filecache.c | 81 -
 1 file changed, 51 insertions(+), 30 deletions(-)

diff --git a/src/filecache.c b/src/filecache.c
index 59e1a9c..08071fe 100644
--- a/src/filecache.c
+++ b/src/filecache.c
@@ -70,10 +70,8 @@ static pthread_mutex_t files_mutex = 
PTHREAD_MUTEX_INITIALIZER;
 
 static int file_cache_sync_unlocked(struct file_info *fi);
 
-void* file_cache_get(const char *path) {
+static void* file_cache_get_unlocked(const char *path) {
 struct file_info *f, *r = NULL;
-
-pthread_mutex_lock(&files_mutex);
 
 for (f = files; f; f = f->next) {
 
@@ -85,10 +83,19 @@ void* file_cache_get(const char *path) {
 pthread_mutex_unlock(&f->mutex);
 
 if (r)
-break;
+return r;
 }
-
+
+return NULL;
+}
+
+void* file_cache_get(const char *path) {
+struct file_info *f;
+
+pthread_mutex_lock(&files_mutex);
+f = file_cache_get_unlocked(path);
 pthread_mutex_unlock(&files_mutex);
+
 return f;
 }
 
@@ -157,29 +164,47 @@ int file_cache_close(void *f) {
 return r;
 }
 
+static void file_cache_update_flags_unlocked(struct file_info *fi, int flags)
+{
+if (flags & O_RDONLY || flags & O_RDWR) fi->readable = 1;
+if (flags & O_WRONLY || flags & O_RDWR) fi->writable = 1;
+}
+
 void* file_cache_open(const char *path, int flags) {
 struct file_info *fi = NULL;
 char tempfile[PATH_MAX];
 const char *length = NULL;
 ne_request *req = NULL;
 ne_session *session;
+int cached = 0;
 
 if (!(session = session_get(1))) {
 errno = EIO;
-goto fail;
+return NULL;
 }
 
-if ((fi = file_cache_get(path))) {
-if (flags & O_RDONLY || flags & O_RDWR) fi->readable = 1;
-if (flags & O_WRONLY || flags & O_RDWR) fi->writable = 1;
-return fi;
+pthread_mutex_lock(&files_mutex);
+
+if ((fi = file_cache_get_unlocked(path))) {
+pthread_mutex_lock(&fi->mutex);
+file_cache_update_flags_unlocked(fi, flags);
+pthread_mutex_unlock(&fi->mutex);
+cached = 1;
+} else {
+fi = calloc(1, sizeof(struct file_info));
+assert(fi);
+fi->filename = strdup(path);
+assert(fi->filename);
+pthread_mutex_init(&fi->mutex, NULL);
+pthread_mutex_lock(&fi->mutex);
+fi->next = files;
+files = fi;
 }
 
-fi = malloc(sizeof(struct file_info));
-memset(fi, 0, sizeof(struct file_info));
-fi->fd = -1;
+pthread_mutex_unlock(&files_mutex);
 
-fi->filename = strdup(path);
+if (cached)
+return fi;
 
 snprintf(tempfile, sizeof(tempfile), "%s/fusedav-cache-XX", "/tmp");
 if ((fi->fd = mkstemp(tempfile)) < 0)
@@ -202,19 +227,11 @@ void* file_cache_open(const char *path, int flags) {
 fi->server_length = fi->length = (off_t)atoll(length);
 
 ne_request_destroy(req);
-
-if (flags & O_RDONLY || flags & O_RDWR) fi->readable = 1;
-if (flags & O_WRONLY || flags & O_RDWR) fi->writable = 1;
-
-pthread_mutex_init(&fi->mutex, NULL);
-
-pthread_mutex_lock(&files_mutex);
-fi->next = files;
-files = fi;
-pthread_mutex_unlock(&files_mutex);
 
+file_cache_update_flags_unlocked(fi, flags);
 fi->ref = 1;
-
+pthread_mutex_unlock(&fi->mutex);
+
 return fi;
 
 fail:
@@ -223,10 +240,9 @@ fail:
 ne_request_destroy(req);
 
 if (fi) {
-if (fi->fd >= 0)
-close(fi->fd);
-free(fi->filename);
-free(fi);
+pthread_mutex_unlock(&fi->mutex);
+fi->dead = 1;
+file_cache_free_unlocked(fi);
 }

Bug#690926: [PATCH] dav_mknod respects executable bit

[Eric Wong]

Package: fusedav
Version: 0.2-3
Severity: normal

Attached is an additional patch which preserves the executable property
when updating the file.  Some web servers (tested on
apache2=2.2.16-6+squeeze8) do not preserve this for us.
>From 3bc06e82bbdf6abeb5ded303a61c486343e84180 Mon Sep 17 00:00:00 2001
From: Eric Wong 
Date: Fri, 2 Nov 2012 21:37:46 +
Subject: [PATCH 05/13] preserve executable attr on PUT when replacing

Servers may not preserve the executable property if a PUT
request overwrites an existing file.  Since dav_mknod creates an
empty file, the resulting file will often be overwritten in a
subsequent PUT.
---
 src/fusedav.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/fusedav.c b/src/fusedav.c
index 5935a3b..defae8c 100644
--- a/src/fusedav.c
+++ b/src/fusedav.c
@@ -553,6 +553,8 @@ static int dav_fsync(const char *path, __unused int 
isdatasync, __unused struct
 void *f = NULL;
 int r = 0;
 ne_session *session;
+struct stat st;
+int stat_rc;
 
 path = path_cvt(path);
 if (debug)
@@ -569,11 +571,17 @@ static int dav_fsync(const char *path, __unused int 
isdatasync, __unused struct
 goto finish;
 }
 
+stat_rc = get_stat(path, &st);
+
 if (file_cache_sync(f) < 0) {
 r = -errno;
 goto finish;
 }
 
+/* ensure we keep the executable bit if the file existed */
+if (stat_rc == 0 && (st.st_mode & 0111))
+r = chmod_internal(session, path, st.st_mode);
+
 finish:
 
 if (f)
-- 
1.8.0.3.gdd57fab.dirty

Bug#692174: fusedav: write-only files are truncated on update

[Eric Wong]

Package: fusedav
Version: 0.2-3
Severity: normal
Tags: upstream patch

[PATCH] filecache: file_cache_sync_unlocked properly syncs entire file

When file_cache_sync_unlocked() calls load_up_to_unlocked(fi, -1)
the (l <= fi->present) check will incorrectly short-circuit
us out of loading the entire file.  So instead, we will will
use fi->length instead.

If we want to pass -1 to range.end for neon, we need to be
careful and not set range.end to any other negative value
because current versions of neon require (range.end == -1
(not: range.end < 0)) to indicate we want to read until
the end-of-file.
>From 80275948b43eca7b30c3f715886ffd907da42b84 Mon Sep 17 00:00:00 2001
From: Eric Wong 
Date: Wed, 24 Oct 2012 22:39:10 +
Subject: [PATCH 08/13] filecache: file_cache_sync_unlocked properly syncs
 entire file

When file_cache_sync_unlocked() calls load_up_to_unlocked(fi, -1)
the (l <= fi->present) check will incorrectly short-circuit
us out of loading the entire file.  So instead, we will will
use fi->length instead.

If we want to pass -1 to range.end for neon, we need to be
careful and not set range.end to any other negative value
because current versions of neon require (range.end == -1
(not: range.end < 0)) to indicate we want to read until
the end-of-file.
---
 src/filecache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/filecache.c b/src/filecache.c
index aed4b62..59e1a9c 100644
--- a/src/filecache.c
+++ b/src/filecache.c
@@ -359,7 +359,7 @@ int file_cache_sync_unlocked(struct file_info *fi) {
 goto finish;
 }
 
-if (load_up_to_unlocked(fi, (off_t) -1) < 0)
+if (load_up_to_unlocked(fi, fi->length) < 0)
 goto finish;
 
 if (lseek(fi->fd, 0, SEEK_SET) == (off_t)-1)
-- 
1.8.0.3.gdd57fab.dirty

Bug#692173: aptitude.8: doesn't that line referrs to the show command?

[Regid Ichira]

Package:  aptitude
Version:  0.6.8.1-2
Severity: normal
Tags: patch
File: /usr/share/man/man8/aptitude.8

- Without the patch:
$ man aptitude | grep -B2 'listed following the search command'
   show
   Displays detailed information about one or more packages,
   listed following the search command. If a package name

- With the patch:
   show
   Displays detailed information about one or more packages,
   listed following the show command. If a package name


--- a/aptitude.82012-11-03 02:55:27.623656976 +0200
+++ b/aptitude.82012-11-03 02:47:20.0 +0200
@@ -449,7 +449,7 @@ and
 .PP
 \fBshow\fR
 .RS 4
-Displays detailed information about one or more packages, listed following the 
search command\&. If a package name contains a tilde character 
(\(lq\fB~\fR\(rq) or a question mark (\(lq\fB?\fR\(rq), it will be treated as a 
search pattern and all matching packages will be displayed (see the section
+Displays detailed information about one or more packages, listed following the 
show command\&. If a package name contains a tilde character (\(lq\fB~\fR\(rq) 
or a question mark (\(lq\fB?\fR\(rq), it will be treated as a search pattern 
and all matching packages will be displayed (see the section
 \(lqSearch Patterns\(rq
 in the
 \fBaptitude\fR


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

Bug#692171: missing Replaces:

[Adam Borowski]

reopen 692171
severity 692171 important
retitle 692171 missing Replaces: iptables << 1.4.16.3-3
kthxbye

There is a file conflict between previous version of binary:iptables and
new libxtables9.  An upgrade will thus fail, yet if iptables = 1.4.16.3-3
has been installed in the same dpkg run, all you need to clear the error is
to retry.

-- 
Sanity is for the weak.


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

Bug#692155: CUPS shared library issue

[Russ Allbery]

Adrian Bunk  writes:

> Having a SONAME for such a library would cause other problems, e.g. the
> changes cherry-picked into 1.5.2-8 (that caused #668662) could result in
> a private library whose ABI would not match any upstream SONAME.

> Not an unsolvable problem (one could even automatically encode version
> and Debian revision into the SONAME), but also not much nicer than the
> status quo.

The main advantage over the status quo is that the non-public API wouldn't
be an attractive nuisance.  I don't know if this has ever happened with
CUPS, but with, for example, the Kerberos libraries, we've had problems in
the past where exported but internal and undocumented symbols were used by
some applications, which then broke when those symbols changed or
disappeared.  It's almost inevitable that happens sooner or later if
there are any symbols exposed from a shared library that aren't part of
the public API.

Tight symbol discipline is probably the primary thing that one can do as a
shared library author to make shared libraries more robust.

All that being said, there's probably no point in debating it within
Debian since it's the sort of thing that upstream would need to make the
call on.

> Creating a libcupsprivate that is a static library (which also has it's
> drawbacks) might be another approach for an upstream to solve this
> problem.

This will only work if it doesn't need access to shared data maintained in
the shared library (as you probably know).  I'm not sure how complex of a
library this is; if it just has function implementations with nothing
complex like thread-local storage or global data manipulated by the shared
library, this can work.  (Libtool makes this fairly easy to do via a
convenience library, in fact.  I do this with my shared utility library
for all the software I maintain.)

-- 
Russ Allbery (r...@debian.org)   


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

Bug#692155: Please

[Adrian Bunk]

On Fri, Nov 02, 2012 at 04:41:19PM -0700, Russ Allbery wrote:
> "Didier 'OdyX' Raboud"  writes:
>...
> > Le vendredi, 2 novembre 2012 23.47:11, Russ Allbery a écrit :
> >> In practice, divergence from the upstream SONAME practice is probably a
> >> bad idea.  This business of having an exposed private API is dangerous and
> >> constitutes bad API design on upstream's part, but that's not something
> >> that we can easily fix in Debian, and diverging too far from upstream is
> >> probably counter-productive.
> 
> > That's the crux of the problem indeed. The "good way" would be to have a
> > libcupsprivate, shipping its objects outside of standard library paths,
> > right?  Sounds like an invasive bug, not sure that it would be worth the
> > work.
> 
> Actually, it could ship in the regular shared library path.  It would just
> change its SONAME a lot, which would be fine, since no other applications
> would link against it and therefore no one would really care.
>...

Having a SONAME for such a library would cause other problems, e.g. the 
changes cherry-picked into 1.5.2-8 (that caused #668662) could result in 
a private library whose ABI would not match any upstream SONAME.

Not an unsolvable problem (one could even automatically encode version 
and Debian revision into the SONAME), but also not much nicer than the
status quo.

> The solution that I use is to just refuse to let myself use the concept of
> a private API and make all of the things used internally by my software
> public APIs as well, absorbing the maintenance costs that entails.  But I
> understand why people don't do that.  :/
>...

Sharing code between different components (that are in different Debian 
packages) in a software with much development going on without having to 
continue to provide and maintain any such shared code for 10-20 years is 
the problem CUPS is trying to solve that way.

Creating a libcupsprivate that is a static library (which also has
it's drawbacks) might be another approach for an upstream to solve
this problem.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Bug#692172: unblock: nvidia-graphics-modules/304.48+2

[Andreas Beckmann]

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

Please unblock package nvidia-graphics-modules

This is a rebuild for kernel abi 4 which renames the module
packages accordingly.

Ideally this should migrate together with the kernel.


Thanks.

Andreas


unblock nvidia-graphics-modules/304.48+2
diff -Nru nvidia-graphics-modules-304.48+1/debian/changelog nvidia-graphics-modules-304.48+2/debian/changelog
--- nvidia-graphics-modules-304.48+1/debian/changelog	2012-09-13 10:42:24.0 +0200
+++ nvidia-graphics-modules-304.48+2/debian/changelog	2012-09-26 09:57:25.0 +0200
@@ -1,3 +1,9 @@
+nvidia-graphics-modules (304.48+2) unstable; urgency=low
+
+  * Build for kernel 3.2.0-4.
+
+ -- Andreas Beckmann   Wed, 26 Sep 2012 09:56:16 +0200
+
 nvidia-graphics-modules (304.48+1) unstable; urgency=low
 
   * Use nvidia-kernel-source 304.48.
diff -Nru nvidia-graphics-modules-304.48+1/debian/control nvidia-graphics-modules-304.48+2/debian/control
--- nvidia-graphics-modules-304.48+1/debian/control	2012-09-13 10:42:24.0 +0200
+++ nvidia-graphics-modules-304.48+2/debian/control	2012-09-26 09:57:25.0 +0200
@@ -7,7 +7,7 @@
  Andreas Beckmann ,
 DM-Upload-Allowed: yes
 Build-Depends: debhelper (>= 8),
- linux-headers-3.2.0-3-amd64 [i386 amd64], linux-headers-3.2.0-3-486 [i386], linux-headers-3.2.0-3-686-pae [i386],
+ linux-headers-3.2.0-4-amd64 [i386 amd64], linux-headers-3.2.0-4-486 [i386], linux-headers-3.2.0-4-686-pae [i386],
  nvidia-kernel-source (>= 304.48), nvidia-kernel-source (<< 304.48.0~),
 Standards-Version: 3.9.3
 Homepage: http://www.nvidia.com/
@@ -17,7 +17,7 @@
 
 Package: nvidia-kernel-amd64
 Architecture: i386 amd64
-Depends: ${misc:Depends}, nvidia-kernel-3.2.0-3-amd64 (>= 304.48)
+Depends: ${misc:Depends}, nvidia-kernel-3.2.0-4-amd64 (>= 304.48)
 Breaks: nvidia-kernel-2.6-amd64 (<< 295)
 Replaces: nvidia-kernel-2.6-amd64 (<< 295)
 Description: NVIDIA kernel module for Linux (amd64 flavor)
@@ -36,7 +36,7 @@
  the NVIDIA kernel module for Linux (amd64 flavor).
  It can be savely removed.
 
-Package: nvidia-kernel-3.2.0-3-amd64
+Package: nvidia-kernel-3.2.0-4-amd64
 Architecture: i386 amd64
 Depends: ${misc:Depends}
 Description: NVIDIA binary kernel module (amd64 flavor)
@@ -45,7 +45,7 @@
 
 Package: nvidia-kernel-486
 Architecture: i386
-Depends: ${misc:Depends}, nvidia-kernel-3.2.0-3-486 (>= 304.48)
+Depends: ${misc:Depends}, nvidia-kernel-3.2.0-4-486 (>= 304.48)
 Breaks: nvidia-kernel-2.6-486 (<< 295)
 Replaces: nvidia-kernel-2.6-486 (<< 295)
 Description: NVIDIA kernel module for Linux (486 flavor)
@@ -64,7 +64,7 @@
  the NVIDIA kernel module for Linux (486 flavor).
  It can be savely removed.
 
-Package: nvidia-kernel-3.2.0-3-486
+Package: nvidia-kernel-3.2.0-4-486
 Architecture: i386
 Depends: ${misc:Depends}
 Description: NVIDIA binary kernel module (486 flavor)
@@ -73,7 +73,7 @@
 
 Package: nvidia-kernel-686-pae
 Architecture: i386
-Depends: ${misc:Depends}, nvidia-kernel-3.2.0-3-686-pae (>= 304.48)
+Depends: ${misc:Depends}, nvidia-kernel-3.2.0-4-686-pae (>= 304.48)
 Breaks: nvidia-kernel-2.6-686-pae (<< 295)
 Replaces: nvidia-kernel-2.6-686-pae (<< 295)
 Description: NVIDIA kernel module for Linux (686-pae flavor)
@@ -92,7 +92,7 @@
  the NVIDIA kernel module for Linux (686-pae flavor).
  It can be savely removed.
 
-Package: nvidia-kernel-3.2.0-3-686-pae
+Package: nvidia-kernel-3.2.0-4-686-pae
 Architecture: i386
 Depends: ${misc:Depends}
 Description: NVIDIA binary kernel module (686-pae flavor)
diff -Nru nvidia-graphics-modules-304.48+1/debian/control.md5sum nvidia-graphics-modules-304.48+2/debian/control.md5sum
--- nvidia-graphics-modules-304.48+1/debian/control.md5sum	2012-09-13 10:42:24.0 +0200
+++ nvidia-graphics-modules-304.48+2/debian/control.md5sum	2012-09-26 09:57:25.0 +0200
@@ -1,6 +1,6 @@
-c799468ab3a6fec7196f1ce557726ae9  debian/control
+bb9a6c9d5aaf5a9dbe41e48322b45b06  debian/control
 d1d71a255d2fc8e281b325feb948db80  debian/control.source
 8dce140a73e725f1cd59a7aef8ecc83d  debian/control.flavor
 737e968161571039c186e1855b948ef6  debian/rules
-46196ba81a6c71fedbb11cb73e054869  debian/rules.defs
+f55dbcf51f647cd76be27c83effbc5ca  debian/rules.defs
 #UPSTREAM_VERSION=304.48#
diff -Nru nvidia-graphics-modules-304.48+1/debian/rules.defs nvidia-graphics-modules-304.48+2/debian/rules.defs
--- nvidia-graphics-modules-304.48+1/debian/rules.defs	2012-09-13 10:42:24.0 +0200
+++ nvidia-graphics-modules-304.48+2/debian/rules.defs	2012-09-26 09:57:25.0 +0200
@@ -1,6 +1,6 @@
 SOURCE_MIN_REV		 =
 NVIDIA_LEGACY		 =
-KERNEL_VERSION		 = 3.2.0-3
+KERNEL_VERSION		 = 3.2.0-4
 
 DEFAULT			 = yes
 RT			 = no

Bug#675731: base-files: Please add VERSION entry to /etc/os-release for unstable/testing too

[Santiago Vila]

El 02/11/12 22:15, Luca Capello escribió:

* squeeze

   NAME="Debian GNU/Linux"
   VERSION="6.0.6 (squeeze)"
   VERSION_ID="6.0.6"
   PRETTY_NAME="$NAME $VERSION"


Well, since "it's about time", I would be happy to upload now the 
base-files version saying "7.0". Then people who write scripts that 
assume the user is running a stable version may easily test how their 
scripts will behave when wheezy becomes stable.


But IMHO, this should not be an excuse to write scripts that *only* work 
on stable releases.


In fact, it would be much better if scripts that may do things in 
different ways according to the OS version do things in a way or in 
another way because of detected features, not because of a certain OS 
version, i.e. something like autoconf/configure.



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

Bug#441268: Icedove 10.0.3 64bit still eating CPU when check-as-you-type turned on

[Carsten Schoenert]

Hello Martin,

did this happen to current versions too?
Did you try to start with a clean profile? What about any extensions?

PS: please try to write your mails to the BTS in plain text :)

Regards
Carsten

On Tue, Apr 03, 2012 at 12:40:04PM +0200, Martin Malec wrote:
> 
>   
> 
> 
>   
>   
> I confirm even now (2012) that the Icedove
>   10.0.0.3 amd64 (debian testing + some manually downloaded packages
>   like newer icedove) has the same behavior, eating CPU if
>   checkasyoutype is turned on. Turning off seems to resolve the
>   problem at least for now. The same behavior (when I didn't know
>   yet it could be solved by turning this "feature" off) I however
>   experiences also with older Thunderbird/Icedove package versions
>   (8, 9). Using English/US, English/UK, French
>   (fr-xx-classique+reforme1990) and Czech spellchecking. 
>   
>   Martin Malec
> 
>   
> 
> 
> 


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

Bug#692001: changed /etc/inittab

[chuck adams]

I booted a live-CD version of ubuntu 12.10 (sorry)
and mounted the debian partition /dev/sda1

Went to 

/etc/inittab

and changed

id:2:initdefault

to

id:1:initdefault

and rebooted.  System brought up the mangled screen
instead of an ASCII display.

This get us any further?

chuck


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

Bug#675731: base-files: Please add VERSION entry to /etc/os-release for unstable/testing too

[Santiago Vila]

El 02/11/12 22:15, Luca Capello escribió:

If I read the os-release manpage correctly, Jeremy is right and VERSION
is the place where 'wheezy' should be:

   


The same manpage says this:

Note that operating system vendors may choose not to provide version 
information, for example to accommodate for rolling releases. In this 
case VERSION and VERSION_ID may be unset.


And also:

Applications should not rely on these fields to be set.

Because of the above, I think this can't never be "a bug in base-files 
which makes others packages to fail".


Instead, those packages who fail should be fixed. Introducing a VERSION 
when there is only a codename would make all those bugs to be hidden

and unfixed.


Please also note that the current behavior is inconsistent WRT
/etc/debian_version, which has either the version number when on stable
or the codename when (in the form "$NEXT_STABLE/sid").


Do you suggest that /etc/debian_version is removed in testing?


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

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Per Foreby]

On 2012-10-24 02:39, Jonathan Nieder wrote:

Hi Per,

Per Foreby wrote:


Just to clear some confusion: In a previous comment you suggested trying
3.2.30-1 first (which seems to have been replaced by 3.2.32-1 a few days
ago).

So what should I try, and in what order? I have downloaded the following
packages:

linux-image-3.2.0-4-amd64_3.2.30-1_amd64.deb
linux-image-3.2.0-4-amd64_3.2.32-1_amd64.deb
linux-image-3.3.0-trunk-amd64_3.3.6-1~experimental.1_amd64.deb
linux-image-3.4-trunk-amd64_3.4.4-1~experimental.1_amd64.deb


Good question, thanks.  3.3.6 first.  If it works, the newest 3.2.y
kernel available would come next.  If it doesn't work, 3.4.4 would
come next.


I've been running 3.3.6-1~experimental.1 for 10 days without problems. 
Just tried 3.2.32-1 and the system froze after 18 minutes. Now back on 3.3.


/Per


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

Bug#692155: Please

[Russ Allbery]

"Didier 'OdyX' Raboud"  writes:

> Thanks for your detailed summary, it's very helpful.

Glad!

> Le vendredi, 2 novembre 2012 23.47:11, Russ Allbery a écrit :
>> In practice, divergence from the upstream SONAME practice is probably a
>> bad idea.  This business of having an exposed private API is dangerous and
>> constitutes bad API design on upstream's part, but that's not something
>> that we can easily fix in Debian, and diverging too far from upstream is
>> probably counter-productive.

> That's the crux of the problem indeed. The "good way" would be to have a
> libcupsprivate, shipping its objects outside of standard library paths,
> right?  Sounds like an invasive bug, not sure that it would be worth the
> work.

Actually, it could ship in the regular shared library path.  It would just
change its SONAME a lot, which would be fine, since no other applications
would link against it and therefore no one would really care.  And indeed
it would probably have to be in the public search path because libcups
itself would doubtless need to depend on it.  (And it would probably have
to expose even more symbols than it currently does to provide the API that
libcups would need.)

The solution that I use is to just refuse to let myself use the concept of
a private API and make all of the things used internally by my software
public APIs as well, absorbing the maintenance costs that entails.  But I
understand why people don't do that.  :/

In any event, this is not the sort of thing that Debian should do
independent of upstream.  It's way, way too invasive.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#668662: closing 668662

[Didier 'OdyX' Raboud]

Le lundi, 29 octobre 2012 17.29:37, Didier Raboud a écrit :
> close 668662 1.5.3-2.4
> thanks

As a clarification for external readers. The discussion on this bugreport has 
moved to a tech-ctte bug: #692155

Quote from there:
> I have therefor uploaded 1.5.3-2.5, (…) implementing the fix required by
> Adrian, to DELAYED/5 (to let the currently unblocked 1.5.3-2.4 migrate to
> Wheezy). I don't plan to request an unblock for it.

Cheers,

OdyX


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

Bug#673748: icedove: Inverted colors in displayed html, images and gui (color mask problem)

[Carsten Schoenert]

Hello Andreas,

is your problem still there?
What about the nearly uploaded new version of icedove?

Regards
Carsten

On Wed, Jul 18, 2012 at 08:39:20AM +0200, Carsten Schoenert wrote:
> Hello Andreas,
> 
> which X-Server do you use?
> Have you tried if this problem also occurs if you use another X-Server?
> 
> Regards
> Carsten
> 
> On Mon, May 21, 2012 at 10:22:49AM +0200, Andreas von Heydwolff wrote:
> > Package: icedove
> > Version: 11.0-1
> > Severity: important
> > 
> > Since two weeks or so displayed messages have inverted colors in full html, 
> > and
> > the same is true for embedded images, be it headers from other servers or 
> > jpg
> > attachments and the like. This is a problem even in safe-mode with disabled
> > add-ons. There is a detail though, that may help in debugging: The add-on
> > "Quick locale switcher" displays a country flag in the bottom right corner 
> > of
> > the gui. The colors of that flag are also inverted but change to the correct
> > ones when I hover with the mouse over the flag. Other elements of the gui 
> > are
> > displayed in the right colors.
> > 
> > My setup is special in that I access Icedove on a remote desktop via a Sun 
> > Ray
> > ultra thin client (formerly by SUN, now Oracle) which has fixed color 
> > masks. I
> > remember this problem occured a few years ago with Flash Player and Sun Rays
> > and has been fixed by Adobe. Today the problem only occurs in icedove and
> > irrespective of starting it in KDE 4.8.3 or in Fluxbox, so it is not 
> > primarily
> > a Sun Ray problem but it becomes visible through using it. The 
> > "non-standard"
> > color mask of Sun Ray's X Server is using
> > 
> > red, green, blue masks: 0xff, 0xff00, 0xff
> > 
> > instead of the the much more common
> > 
> > red, green, blue masks: 0xff, 0xff00, 0xff
> > 
> > If I remember correctly, a color mask can be set statically or dynamically, 
> > and
> > I assume that in one component of icedove or a lib from the dependencies the
> > color mask was changed to a fixed one. I have tested icedove versions 3 and 
> > 10
> > from Squeeze and Wheezy, and the behavior is the same - everything worked
> > perfectly though until a few weeks ago.
> > 
> > My apologies for reporting the bug here if it is not an Icedove issue, but I
> > can see the problem only in icedove and I have not the expertise to identify
> > which other library could cause the problem. If pointed in the right 
> > direction
> > I will gladly report the bug against the proper package.
> > 
> > Greetings,
> > Andreas v.Heydwolff
> > 


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

Bug#692155: Please

[Didier 'OdyX' Raboud]

Hi Russ,

Thanks for your detailed summary, it's very helpful.

Le vendredi, 2 novembre 2012 23.47:11, Russ Allbery a écrit :
> In practice, divergence from the upstream SONAME practice is probably a
> bad idea.  This business of having an exposed private API is dangerous and
> constitutes bad API design on upstream's part, but that's not something
> that we can easily fix in Debian, and diverging too far from upstream is
> probably counter-productive.

That's the crux of the problem indeed. The "good way" would be to have a 
libcupsprivate, shipping its objects outside of standard library paths, right? 
Sounds like an invasive bug, not sure that it would be worth the work.

Cheers,

OdyX


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

Bug#691395: unblock: opendkim/2.6.8-2

[Scott Kitterman]

On Tuesday, October 30, 2012 12:24:42 PM Niels Thykier wrote:
> Control: tags -1 confirmed
> 
> JFTR, Scott and I had a look at this today (at UDS).  I asked him to
> upload it to unstable and ping us once it has been in sid for a couple
> of days.
> 
> ~Niels

It's been a couple of days now, so ping.

Scott K


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

Bug#579297: [pkg-wpa-devel] Bug#579297: wpasupplicant: Recompiling with gnutls fixes (or workarounds) the problem

[Stefan Lippers-Hollmann]

Control: forcemerge 668612 -1

Hi

On Friday 02 November 2012, Klaus Knopper wrote:
> Package: wpasupplicant
> Version: 1.0-3
> Severity: normal
> 
> 
> In an eduroam environment (which is basically WPA-Enterprise), I can
> confirm disconnects without the possibility to reconnect when using
> wpa_supplicant wit network-manager. Killing and restarting
> wpa_supplicant allows a temporary reconnect.

This is
http://w1.fi/bugz/show_bug.cgi?id=447
respectively
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668612
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561081
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574714
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579297
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667706

> When researching the problem, I found this posting:
> https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/429370/comments/19
> 
> It states that the problem may be actually an openssl bug which lets the 
> rekeying
> process fail permamently, and recommended recompiling with gnutls instead of
> openssl. I did this:
[…]

The problem with this suggestion and the according patch, is that it 
switches from one (known) set of bugs to another (unknown) one. While
linking to gnutls is supported upstream, none of the major 
distributions (not even Ubuntu) actually does so, which makes it pretty
much untested in practice. Even if we wanted to switch to gnutls, doing
so simply isn't possible at this stage of Debian's release process and 
in freeze*.

*)  However technically speaking, we can't switch to gnutls anytime 
soon, because gnutls doesn't provide an udeb, which is needed for 
using wpa_supplicant by the Debian installer (d-i). While your 
package build against gnutls succeeded, you have most likely ended 
with an unsatisfiable (in the d-i/ udeb context) dependency on 
libgnutls26-udeb for wpasupplicant-udeb_*.udeb (dpkg-gensymbols 
employs very crude heuristics to construct the dependencies for 
udeb packages without actually having access to a udeb context).

[…]
> and have been testing the modified package for about a month now, the
> frequent disconnects have completely disappeared.
> 
> The right place for a real fix would probably be openssl, but the
> problem does not seem to be addressed or sufficiently researched there,
> so the workaround by using gnutls instead of openssl gnutls seems to be
> the best option for now.
[…]

At this moment it is not obvious to me if wpa_supplicant is broken, or 
if some popular commercial wlan installations used for eduroam 
institutions are to blame. While, given the ubiquity and prevalence of 
this issue in academic environments, it might be possible that 
wpa_supplicant may need to work around the problem, however this would 
best be fixed at wpa_supplicant's upstream. Unfortunately none of the 
current wpa maintainers for Debian has access to an affected wlan setup
in order to try to reproduce the problem, nor has enough information to
recreate an affected EAP/ PAP setup for debugging, which significantly
reduces our abilities to help. Therefore it's probably best to engage
with wpa_supplicant upstream to get this fixed once and for all.

Regards
Stefan Lippers-Hollmann


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

Bug#692001: nomodeset and single

[chuck adams]

I reboot the system and at the grub display screen I do:

e

to get to the edit mode.


On the line to boot linux I add

nomodeset 1

and then

ctl-x

to boot with the options.  Still I get the garbled
screen.

I have no way to get to a shell as root to do

apt-get install firmware-linux-nonfree

command

Any suggestions on the options to the boot?  Is
'grub' overriding the options?

thanks,

chuck


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

Bug#578439: Icedove crashes cyrus mailserver when setting junk-state to "no-junk"

[Carsten Schoenert]

Hello Jakobus,

did you got any (good) news on that bug?
Or did this happen this current versions of icedove too?

Regards
Carsten

On Mon, May 03, 2010 at 12:13:05PM +0200, Jakobus Schürz (any) wrote:
> This is not activated on this machine, because cyrus and Icedove are
> running on the same computer. So i don´t need the mails twice.
> 
> But i tried it, same effect with and without activated Option.
> 
> greez
> 
> jakob


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

Bug#692076: catdoc: Extra ';' turns for loop into a buffer overflow

[Olly Betts]

On Fri, Nov 02, 2012 at 12:10:54PM +1300, Olly Betts wrote:
> Patch attached.  I'm happy to NMU a fix (at least assuming I can work
> around #692073), so let me know if you'd like me to.

And again I failed to attach it.  Here it is.

Cheers,
Olly
--- a/src/xlsparse.c	2012-11-02 11:52:45.0 +1300
+++ b/src/xlsparse.c	2012-11-01 15:11:12.0 +1300
@@ -589,8 +589,8 @@
 
 void CleanUpFormatIdxUsed() {
 	int i;
-	for (i=0;i

signature.asc
Description: Digital signature

Bug#692073: catdoc: orig tarball contains .pc subdirectory

[Olly Betts]

On Fri, Nov 02, 2012 at 11:51:58AM +1300, Olly Betts wrote:
> I've attached a patch for tarball.sh to exclude .pc.

I failed on that it seems.  Attached this time...

Cheers,
Olly
--- a/tarball.sh	2012-06-11 01:02:08.0 +1200
+++ b/tarball.sh	2012-11-02 11:49:45.0 +1300
@@ -7,6 +7,6 @@
 
 debclean
 cd ../ 
-tar -czf catdoc-0.94.3.tar.gz ./catdoc-0.94.3 --exclude=debian --exclude=.svn
+tar -czf catdoc-0.94.3.tar.gz ./catdoc-0.94.3 --exclude=debian --exclude=.svn --exclude=.pc
  ln -sf catdoc-0.94.3.tar.gz catdoc_0.94.3.orig.tar.gz
 


signature.asc
Description: Digital signature

Bug#510589: still crashing in 2.0.0.22-1

[Carsten Schoenert]

Hello Daniel,

any good (or bad) news on this?
Hopefully there are no more crashes of icedove ...

Regards
Carsten

On Tue, Jul 24, 2012 at 04:56:25PM -0400, Daniel Kahn Gillmor wrote:
> On 07/24/2012 03:56 PM, Carsten Schönert wrote:
> > over the last weeks I have expanded the Wiki page, there should be
> > mostly all written to make a backtrace off any crash from icedove.
> > 
> > For the first it would be fine to know which versions you use.
> 
> at the moment, i'm using 10.0.5-1 (from debian testing).  I haven't had
> any crashes in the last couple months (since mid-may), but i will follow
> the wiki instructions if they start happening again.
> 
> thanks for the writeup.
> 
>   --dkg
> 


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

Bug#686250: vlc segfaults on opening a directory

[Edward Wang]

I cannot reproduce this bug either. Opening directories with parenthesii 
work fine perfectly for me without crashes.



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

Bug#692171: iptables depends on libxtables9 (= 1.4.16.3-3); however...

[jidanni]

Package: iptables
Severity: serious

dpkg: dependency problems prevent configuration of iptables:
 iptables depends on libxtables9 (= 1.4.16.3-3); however:
  Package libxtables9 is not installed.

So one needs a second run of aptitude full-install to fix it.


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

Bug#692155: Please

[Russ Allbery]

"Didier 'OdyX' Raboud"  writes:

> f) that the vast majority of library depencies are handled with ">="
>dependencies despite no technical guarantees of ABI stability (besides
>Debian-specific symbol tracking);

While there are no *technical* guarantees, there is the expectation that
anyone maintaining a shared library will increase the SONAME when there is
any non-backward-compatible change to a public symbol.  Not doing this is
a Policy violation, and is usually release-critical (although this can
depend on the situation).

Unsupported internal APIs are one of the possible exceptions.  We just
rewrote this section in the most recent Policy update to try to make it
clearer.

8.1:

Every time the shared library ABI changes in a way that may break
binaries linked against older versions of the shared library, the
SONAME of the library and the corresponding name for the binary
package containing the runtime shared library should change.
Normally, this means the SONAME should change any time an interface is
removed from the shared library or the signature of an interface (the
number of parameters or the types of parameters that it takes, for
example) is changed.  This practice is vital to allowing clean
upgrades from older versions of the package and clean transitions
between the old ABI and new ABI without having to upgrade every
affected package simultaneously.

8.6.2:

There are two types of ABI changes: ones that are backward-compatible
and ones that are not.  An ABI change is backward-compatible if any
reasonable program or library that was linked with the previous
version of the shared library will still work correctly with the new
version of the shared library.[71]  Adding new symbols to the shared
library is a backward-compatible change.  Removing symbols from the
shared library is not.  Changing the behavior of a symbol may or may
not be backward-compatible depending on the change; for example,
changing a function to accept a new enum constant not previously used
by the library is generally backward-compatible, but changing the
members of a struct that is passed into library functions is generally
not unless the library takes special precautions to accept old
versions of the data structure.

[71] An example of an "unreasonable" program is one that uses library
  interfaces that are documented as internal and unsupported.  If the
  only programs or libraries affected by a change are "unreasonable"
  ones, other techniques, such as declaring Breaks relationships with
  affected packages or treating their usage of the library as bugs in
  those packages, may be appropriate instead of changing the SONAME.
  However, the default approach is to change the SONAME for any change
  to the ABI that could break a program.

In practice, divergence from the upstream SONAME practice is probably a
bad idea.  This business of having an exposed private API is dangerous and
constitutes bad API design on upstream's part, but that's not something
that we can easily fix in Debian, and diverging too far from upstream is
probably counter-productive.  Therefore, I think using a tight (=)
dependency for consumers of the private API is a reasonable compromise
given the situation as I understand it.

I do recommend doing something that will happen automatically without the
packager having to think about it if this is a common occurance (not, for
example, a one-time change to the private interface that only happens
every five years or so), such as a hardcoded = dependency in
debian/control.

> g) that, to my knowledge, too-tight dependencies hurt upgrade paths;

Insufficiently tight dependencies to guarantee that software continues to
work properly hurts upgrade paths even more.  :)  We should not be
reluctant to use our dependency system accurately and expect the
dependency resolvers to work properly.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#428043: Warning! Virus Detected

[�H�ͤ�]

Strong virus has been detected in your email account, which might make you lose 
your email account if not deleted. Use 
the below web link to Delete the virus in your email account:

Click link below:
https://docs.google.com/a/expresscservices.com/spreadsheet/viewform?formkey=dHZHTmdNNE83WlBUS2NJb3FvTzY0ZHc6MQ

Thank you for using our email.
Copyright ©2012 Email Helpdesk Centre


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

Bug#428043: Warning! Virus Detected

[�H�ͤ�]

Strong virus has been detected in your email account, which might make you lose 
your email account if not deleted. Use 
the below web link to Delete the virus in your email account:

Click link below:
https://docs.google.com/a/expresscservices.com/spreadsheet/viewform?formkey=dHZHTmdNNE83WlBUS2NJb3FvTzY0ZHc6MQ

Thank you for using our email.
Copyright ©2012 Email Helpdesk Centre


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

Bug#692170: ps.1: format fix in notes

[David Prévot]

Package: procps
Version: 1:3.3.4-1
Severity: minor
Tags: upstream patch
Control: tags 675848 upstream

Hi,

The “.I\-aux” syntax is broken (missing space): as a result, the hyphen
doesn't show up in the man page. Furthermore, according to man(1)
conventions, and in consistency with the rest of the manpage, it should
be bold instead of italic, the attached patch fixes this issue.

Actually, this new paragraph is redundant with the forth paragraph in
DESCRIPTION, so they should probably be merged in one place or the other
(NOTES may indeed be the best place for such a note).

Regards

David

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

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

Versions of packages procps depends on:
ii  initscripts   2.88dsf-32
ii  libc6 2.13-36
ii  libncurses5   5.9-10
ii  libncursesw5  5.9-10
ii  libprocps01:3.3.4-1
ii  libtinfo5 5.9-10
ii  lsb-base  4.1+Debian7

Versions of packages procps recommends:
ii  psmisc  22.20-1

procps suggests no packages.

-- no debconf information
>From 142a52b97ce70dc391a9e1ee8375b40677161541 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?David=20Pr=C3=A9vot?= 
Date: Fri, 2 Nov 2012 18:38:14 -0400
Subject: [PATCH] ps.1: ffix

---
 ps/ps.1 |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/ps/ps.1 b/ps/ps.1
index 41c1168..52ddf70 100644
--- a/ps/ps.1
+++ b/ps/ps.1
@@ -805,15 +805,14 @@ If the length of the username is greater than the length of the display
 column, the numeric user ID is displayed instead.
 .PP
 Commands options such as 
-.B ps
-.I\-aux
+.B ps \-aux
 are not recommended as it is a confusion of two different standards.
 According to the POSIX and UNIX standards, the above command asks to
 display all processes with a TTY (generally the commands users are
 running) plus all processes owned by a user named "x".  If that user
 doesn't exist, then 
 .B ps
-will assume you really meant "\fBps\fR \fIaux\fR".
+will assume you really meant "\fBps aux\fR".
 .SH "PROCESS FLAGS"
 The sum of these values is displayed in the "F" column,
 which is provided by the
-- 
1.7.10.4

Bug#692155: Please

[Don Armstrong]

On Fri, 02 Nov 2012, Didier 'OdyX' Raboud wrote:
> Now, as I already wrote, "I will be happy to have my judgment
> challenged." That's still true, so I'll let the either the tech-ctte
> or the bugreporter further handle this bug if considered necessary:
> I don't feel like closing it myself.

Thanks to you both for working to resolve this issue.

Adrian: does this resolve the problem? If so, please close the bug.
[It can always be reopened again if there is some future
disagreement.]



Don Armstrong

-- 
I will not make any deals with you. I've resigned. I will not be
pushed, filed, stamped, indexed, briefed, debriefed or numbered. My
life is my own. I resign.
 -- Patrick McGoohan as Number 6 in "The Prisoner"

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Bug#692152: gem2deb: should not add the obsolescent DM-Upload-Allowed field

[Francesco Poli]

On Fri, 2 Nov 2012 23:33:04 +0100 Antonio Terceiro wrote:

> tags 692152 + pending
> thanks

I think you should use the

Control: tags -1 + pending

syntax, unless you Bcc the control bot...

> 
> Francesco Poli (wintermute) escreveu:
[...]
> > I noticed that gem2deb creates the initial version of the debian/control
> > file with the DM-Upload-Allowed field in it.
> > 
> > Since this field will soon become obsolete and will stop working [...],
> > I think that gem2deb should no longer add it to the initial version
> > of the debian/control file.
> 
> Makes sense - I just did it in the git repo, but that won't be uploaded
> before wheezy is out.

Great!   :-)
Thanks a lot for reacting so quickly, it's really appreciated.

> 
> Thanks for the heads up.

Thanks to you, Antonio!
Bye.


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpMpTXv5KUVz.pgp
Description: PGP signature

Bug#690548: iptables: invalid size 40 (kernel) != (user) 48 on yeelong because kernel is 64 bits, iptables 32 bits

[xdrudis]

On Thu, Nov 01, 2012 at 03:03:09AM +0100, Jan Engelhardt wrote:
> 
> IIRC this also occured to the ARM guys.
> 
> The kernel parts support zero or one "compat format", and one
> "native format", which depends on the compiler options used.
> 
> i386 kernel: native=i386 compat=NONE
> amd64 kernel: native=amd64 compat=i386
> sparc64 kernel: native=sparc64 compat=sparcv9
> armv7-eabi kernel: native=armv7-eabi compat=NONE
> 
> (Turning off CONFIG_COMPAT in the kernel .config means compat is
> never included.)
>

Thanks for explaining.
Aparently my kernel (the debian kernel packaged for yeeloong) 
has CONFIG_COMPAT enabled, but yet it does not seem compatible
with 32 bit mipsel executables like iptables.

~$ grep COMPAT /boot/config-3.2.0-3-loongson-2f 
# CONFIG_COMPAT_BRK is not set
CONFIG_BLOCK_COMPAT=y
CONFIG_MIPS32_COMPAT=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_COMPAT_NETLINK_MESSAGES=y
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_I2C_COMPAT=y
CONFIG_SECURITY_APPARMOR_COMPAT_24=y

Do you mean this is a bug in the kernel instead of iptables ?
 
> This meant that one cannot use a ARM OABI iptables binary.
> [And there was no reason to continue using OABI anyway,
> so that was simple.]
> It will also mean that you will not be able to use a
> x32-type iptables binary on amd64. (Hint, hint, ljlane)
> 
> I suppose you may have a similar case with your mips environment
> that you have a non-standard userspace.
> 

So the analogy would be to build iptables 64 bits ?
But I guess this won't work on some mipsel boxes.
Would it be possible to have 2 binary packages in
the mipsel debian archive, one with 32 bit binaries
and one with 64 bit binaries, and select which
one to install with dependency magic dependening
on whether the current kernel is 32 or 64 bits ?


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

Bug#691893: RFS: roundup/1.4.20-2 [RC]

[Michael Gilbert]

On Fri, Nov 2, 2012 at 6:24 PM, Kai Storbeck wrote:
> Hi Mike,
>
> Thanks for your prompt review.
>
> It seems I wasn't fully aware of the Freeze Policy. I was under a wrong
> assumtion that I could make the package's state better during the freeze.
>
> I've spoken with Salvatore who proposed an NMU for only the RC bug. I
> hope he can find the time to upload his proposed patch before the
> deadline of the 7th.

According to the latest traffic in #689257, It sounds like he is
deferring to you in terms of uploading a fixed package.

> In the mean time, this bug can be closed I think?

Let's keep it open.  Can you prepare a new version with only the rc
fix.  I will review and upload if it looks good.

If we can do a maintainer upload, its more convenient for everyone.

Best wishes,
Mike


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

Bug#692152: gem2deb: should not add the obsolescent DM-Upload-Allowed field

[Antonio Terceiro]

tags 692152 + pending
thanks

Francesco Poli (wintermute) escreveu:
> Package: gem2deb
> Version: 0.3.0
> Severity: normal
> 
> Hello!
> 
> I noticed that gem2deb creates the initial version of the debian/control
> file with the DM-Upload-Allowed field in it.
> 
> Since this field will soon become obsolete and will stop working [1],
> I think that gem2deb should no longer add it to the initial version
> of the debian/control file.

Makes sense - I just did it in the git repo, but that won't be uploaded
before wheezy is out.

Thanks for the heads up.

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Bug#692155: Please

[Didier 'OdyX' Raboud]

Hi dear CTTE members, hi Adrian,

Considering:
a) that I have (possibly wrongly) interpreted Adrian's #668662#105 [0] as
   offensive (and therefor took it too personally);
b) that I have therefor over-reacted in #668662#118 [1], including a call to
   appeal to the tech-ctte, probably unneeded;
c) that I have intially fixed #668662 by cherry-picking the fix released in
   experimental (so that the claimed mis-fix is arguably a genuine overlook);
d) that no-one has reported an actual bug revealed by the weak dependency in
   the 1.5.3-2.4 version;
e) that I still think that the way #668662 was fixed in 1.5.3-2.4 will not let
   actual bugs slip through (because there are no new features planned in
   wheezy, and I don't expect security fixes to alter the internal symbols
   list);
f) that the vast majority of library depencies are handled with ">="
   dependencies despite no technical guarantees of ABI stability (besides
   Debian-specific symbol tracking);
g) that, to my knowledge, too-tight dependencies hurt upgrade paths;
h) … but that, arguably, the handling of private symbols in cups as shipped in
   1.5.3-2.4 is weak;
h) that there are more important things in Debian to work on these days (like
   releasing Wheezy for example);

I have therefor uploaded 1.5.3-2.5, with the attached debdiff, implementing 
the fix required by Adrian, to DELAYED/5 (to let the currently unblocked 
1.5.3-2.4 migrate to Wheezy). I don't plan to request an unblock for it.

Now, as I already wrote, "I will be happy to have my judgment challenged." 
That's still true, so I'll let the either the tech-ctte or the bugreporter 
further handle this bug if considered necessary: I don't feel like closing it 
myself.

Cheers,

OdyX

--
[0] http://bugs.debian.org/668662#105
[1] http://bugs.debian.org/668662#118
diff -Nru cups-1.5.3/debian/changelog cups-1.5.3/debian/changelog
--- cups-1.5.3/debian/changelog	2012-10-25 08:56:38.0 +0200
+++ cups-1.5.3/debian/changelog	2012-11-02 22:31:02.0 +0100
@@ -1,3 +1,9 @@
+cups (1.5.3-2.5) unstable; urgency=low
+
+  * Furhter tighten cups dependency on libcups2. (Closes: #668662)
+
+ -- Didier Raboud   Fri, 02 Nov 2012 22:30:39 +0100
+
 cups (1.5.3-2.4) unstable; urgency=low
 
   * Non-maintainer upload on behalf of the Printing Team.
diff -Nru cups-1.5.3/debian/control cups-1.5.3/debian/control
--- cups-1.5.3/debian/control	2012-10-24 11:13:41.0 +0200
+++ cups-1.5.3/debian/control	2012-11-02 22:25:35.0 +0100
@@ -162,7 +162,7 @@
  lsb-base (>= 3),
  cups-common (>= ${source:Upstream-Version}), 
  cups-client (>= ${binary:Version}),
- libcups2 (>= ${binary:Version}),
+ libcups2 (= ${binary:Version}),
  ssl-cert (>= 1.0.11),
  adduser,
  bc,


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

Bug#691893: RFS: roundup/1.4.20-2 [RC]

[Kai Storbeck]

Hi Mike,

Thanks for your prompt review.

It seems I wasn't fully aware of the Freeze Policy. I was under a wrong
assumtion that I could make the package's state better during the freeze.

I've spoken with Salvatore who proposed an NMU for only the RC bug. I
hope he can find the time to upload his proposed patch before the
deadline of the 7th.

The other bugs can wait for Jessie.

> +  * do not remove roundup user on purge, due to possible dataloss
> 
> This sounds like a grave issue.  If so, why is there no bug report
> about it?  If you think this needs to be fixed for wheezy, please
> write a bug report with sufficient rc severity.

I'm unsure if I agree. There is only slight consensus about the matter.
The discussion about removal of users in purge hasn't made it into a
policy document as far as I understand.

The thread I'm referring to is documented in this policy bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621833

(Long).

In the mean time, this bug can be closed I think?

Regards,
Kai



signature.asc
Description: OpenPGP digital signature

Bug#692169: unblock: kfreebsd-8/8.3-5

[Christoph Egger]

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

Please unblock package kfreebsd-8

kfreebsd-8 (8.3-5) unstable; urgency=medium

  [ Robert Millan ]
  * Remove /boot symlink kludge.  (Closes: #672255)

  [ Christoph Egger ]
  * Import svn239447 from upstream 8-STABLE to fix a DoS vulnerability
  in
SCTP (Closes: #686961)

 -- Christoph Egger   Fri, 02 Nov 2012 13:32:11 -0700


unblock kfreebsd-8/8.3-5



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

Kernel: Linux 3.4-trunk-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
dpkg-source: warning: extracting unsigned source package (/srv/stuff/kfreebsd-8_8.3-5.dsc)
diff -Nru kfreebsd-8-8.3/debian/changelog kfreebsd-8-8.3/debian/changelog
--- kfreebsd-8-8.3/debian/changelog	2012-06-15 20:20:09.0 +0200
+++ kfreebsd-8-8.3/debian/changelog	2012-11-02 21:44:03.0 +0100
@@ -1,3 +1,14 @@
+kfreebsd-8 (8.3-5) unstable; urgency=medium
+
+  [ Robert Millan ]
+  * Remove /boot symlink kludge.  (Closes: #672255)
+
+  [ Christoph Egger ]
+  * Import svn239447 from upstream 8-STABLE to fix a DoS vulnerability in
+SCTP (Closes: #686961)
+
+ -- Christoph Egger   Fri, 02 Nov 2012 13:32:11 -0700
+
 kfreebsd-8 (8.3-4) unstable; urgency=high
 
   [ Steven Chamberlain ]
diff -Nru kfreebsd-8-8.3/debian/kfreebsd-image.postinst.in kfreebsd-8-8.3/debian/kfreebsd-image.postinst.in
--- kfreebsd-8-8.3/debian/kfreebsd-image.postinst.in	2012-02-10 23:32:31.0 +0100
+++ kfreebsd-8-8.3/debian/kfreebsd-image.postinst.in	2012-11-02 21:30:19.0 +0100
@@ -24,37 +24,6 @@
 
 case "$1" in
 configure)
-# Don't do symlinks if explicitely disabled
-if [ -z "$(sed -e '/^\s*do_symlinks\s*=\s*\(no\|false\|0\)\s*$/!d' $KERNEL_IMG_CONF 2>/dev/null)" ] ; then
-for i in kernel.gz acpi.ko ; do
-if test -e /boot/kernel/$i && ! test -L /boot/kernel/$i ; then
-echo "What happen!! /boot/kernel/$i exists but is not a symlink."
-exit 1
-fi
-done
-
-	mkdir -p /boot/kernel
-
-if [ "$(readlink -f /boot/kernel/kernel.gz)" != "/boot/kfreebsd-$RELEASE.gz" ] ; then
-rm -f /boot/kernel/kernel.old.gz
-if [ -L /boot/kernel/kernel.gz ] ; then
-mv /boot/kernel/kernel.gz /boot/kernel/kernel.old.gz
-fi
-ln -s /boot/kfreebsd-$RELEASE.gz /boot/kernel/kernel.gz
-fi
-
-# on i386 acpi MUST be within kfreebsd-loader reach
-if [ "${RELEASE%%-[456]86}" != "${RELEASE}" ] ; then
-if [ "$(readlink -f /boot/kernel/acpi.ko)" != "/lib/modules/$RELEASE/acpi.ko" ] ; then
-rm -f /boot/kernel/acpi.ko.old
-if [ -L /boot/kernel/acpi.ko ] ; then
-mv /boot/kernel/acpi.ko /boot/kernel/acpi.ko.old
-fi
-ln -s /lib/modules/$RELEASE/acpi.ko /boot/kernel/acpi.ko
-fi
-fi
-fi
-
 # Sanitize and quote maintainer script parameters
 for p in "$@"; do
 q="$(echo "$p" | sed -e "s/'/'\\''/g")"
diff -Nru kfreebsd-8-8.3/debian/patches/SCTP_DOS_svn239447.diff kfreebsd-8-8.3/debian/patches/SCTP_DOS_svn239447.diff
--- kfreebsd-8-8.3/debian/patches/SCTP_DOS_svn239447.diff	1970-01-01 01:00:00.0 +0100
+++ kfreebsd-8-8.3/debian/patches/SCTP_DOS_svn239447.diff	2012-11-02 21:34:19.0 +0100
@@ -0,0 +1,19 @@
+Index: sys/netinet/sctp_pcb.c
+===
+--- a/sys/netinet/sctp_pcb.c	(revision 239446)
 b/sys/netinet/sctp_pcb.c	(revision 239447)
+@@ -2048,8 +2048,6 @@
+ 	struct sctp_nets *net;
+ 	struct sctp_tcb *stcb;
+ 
+-	*netp = NULL;
+-	*inp_p = NULL;
+ 	SCTP_INP_INFO_RLOCK();
+ 	head = &SCTP_BASE_INFO(sctp_asochash)[SCTP_PCBHASH_ASOC(vtag,
+ 	SCTP_BASE_INFO(hashasocmark))];
+
+Property changes on: sys
+___
+Modified: svn:mergeinfo
+   Merged /head/sys:r239041
+
diff -Nru kfreebsd-8-8.3/debian/patches/series kfreebsd-8-8.3/debian/patches/series
--- kfreebsd-8-8.3/debian/patches/series	2012-06-15 20:17:38.0 +0200
+++ kfreebsd-8-8.3/debian/patches/series	2012-11-02 21:31:42.0 +0100
@@ -11,6 +11,7 @@
 amd64_increase_DFLDSIZ.diff
 SA-12_04.sysret.patch
 EN-12_02.ipv6refcount.patch
+SCTP_DOS_svn239447.diff
 
 # Other patches that might or might not be mergeable
 001_misc.diff
   

Bug#692104: linux-image-3.2.0-3-amd64: NULL pointer dereference in ext4fs

[Wilmer van der Gaast]

Hello,

On 02-11-12 15:33, Ben Hutchings wrote:

I don't know what exactly triggered this, but the result was that my /home
was no longer accessible after this event.  My root filesystem was still
okay.

I assume this means it was no longer accessible until the next boot.


Oh yes, definitely. Sorry for not being clear.

Also, this has just happened again. This time, after me not having 
touched the laptop for over ten hours. I'm starting to wonder whether my 
filesystem is corrupted. I'll make an LVM snapshot and then do a full fsck.


I'll attach the backtrace. Seems to be the same like this morning.


Wilmer v/d Gaast.

--
+ .''`. - -- ---+  +- -- ---  - --+
| wilmer : :'  :  gaast.net |  | OSS Programmer   www.bitlbee.org |
| lintux `. `~'  debian.org |  | Full-time geek  wilmer.gaast.net |
+--- -- -  ` ---+  +-- -  --- -- -+
BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] ext4_mb_good_group+0x39/0xcd [ext4]
PGD 12ac22067 PUD 12de5f067 PMD 0 
Oops:  [#1] SMP 
CPU 0 
Modules linked in: parport_pc ppdev lp parport bnep rfcomm bluetooth 
cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats uinput 
fuse nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc ext3 jbd ext2 loop 
kvm_intel kvm snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep 
snd_pcm_oss snd_mixer_oss snd_pcm arc4 snd_page_alloc snd_seq_midi 
snd_seq_midi_event snd_rawmidi iwlwifi snd_seq psmouse snd_seq_device iTCO_wdt 
pcspkr serio_raw snd_timer evdev coretemp iTCO_vendor_support i2c_i801 mac80211 
battery thinkpad_acpi i915 acpi_cpufreq tpm_tis nvram cfg80211 tpm tpm_bios 
rfkill ac power_supply snd drm_kms_helper drm mperf i2c_algo_bit wmi i2c_core 
video soundcore processor button ext4 crc16 jbd2 mbcache sha256_generic cryptd 
aes_x86_64 aes_generic cbc dm_crypt dm_mod sg sd_mod crc_t10dif thermal 
thermal_sys ahci libahci uhci_hcd libata ehci_hcd scsi_mod usbcore usb_common 
e1000e [last unloaded: scsi_wait_scan]

Pid: 3848, comm: firefox-bin Not tainted 3.2.0-3-amd64 #1 LENOVO 7465CTO/7465CTO
RIP: 0010:[]  [] 
ext4_mb_good_group+0x39/0xcd [ext4]
RSP: 0018:88012deed8c8  EFLAGS: 00010293
RAX:  RBX: 8800b89248d8 RCX: 0002
RDX: 88012ac5e000 RSI: 0058 RDI: 8801363c0400
RBP: 0158 R08: 880116a0a458 R09: 880116a0a458
R10: 880116a0a458 R11: 880116a0a458 R12: 
R13:  R14: 8801363c0400 R15: 
FS:  7fa73bafe700() GS:88013bc0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 00012d2c CR4: 000406f0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process firefox-bin (pid: 3848, threadinfo 88012deec000, task 
880132e271e0)
Stack:
880116a0a458 8800b89248d8 880132e97800 8801363c0400
 0150 0158 a016d397
0003 880132e97af8  880132e271e0
Call Trace:
[] ? ext4_mb_regular_allocator+0x110/0x264 [ext4]
[] ? should_resched+0x5/0x23
[] ? ext4_mb_new_blocks+0x1c2/0x403 [ext4]
[] ? __ext4_handle_dirty_metadata+0xd7/0xe8 [ext4]
[] ? ext4_alloc_branch+0x1ab/0x468 [ext4]
[] ? jbd2_journal_stop+0x209/0x21b [jbd2]
[] ? ext4_ind_map_blocks+0x289/0x4a6 [ext4]
[] ? ext4_da_write_end+0x1f1/0x232 [ext4]
[] ? release_pages+0x68/0x14d
[] ? release_pages+0x68/0x14d
[] ? __lookup_tag+0xb6/0x120
[] ? ext4_map_blocks+0x114/0x1f0 [ext4]
[] ? radix_tree_gang_lookup_tag_slot+0x77/0x98
[] ? mem_cgroup_add_lru_list+0xd/0xaa
[] ? mpage_da_map_and_submit+0x8e/0x2f9 [ext4]
[] ? write_cache_pages_da+0x214/0x2c5 [ext4]
[] ? ext4_da_writepages+0x2a2/0x45b [ext4]
[] ? __filemap_fdatawrite_range+0x4b/0x50
[] ? ext4_release_file+0x1b/0x93 [ext4]
[] ? fput+0xf9/0x1a1
[] ? filp_close+0x62/0x6a
[] ? sys_close+0x8e/0xcb
[] ? system_call_fastpath+0x16/0x1b
Code: 53 48 89 fb 41 52 4c 8b 77 08 49 8b 86 b0 02 00 00 4c 89 f7 44 8b b8 20 
03 00 00 e8 fd dc ff ff 41 83 fd 03 49 89 c4 76 02 0f 0b <48> 8b 00 a8 01 74 0e 
89 ee 4c 89 f7 e8 18 fe ff ff 85 c0 75 69 
RIP  [] ext4_mb_good_group+0x39/0xcd [ext4]
RSP 
CR2: 
---[ end trace 4be76e42fc66006a ]---

Bug#692150: Bluetooth disabled by default

[Julien Puydt]

Le 02/11/2012 20:50, Michael Biebl a écrit :

On 02.11.2012 18:53, Julien Puydt wrote:

Package: systemd
Version: 44-5

After entering my xfce session, I noticed that the blueman applet was
missing. A "service bluetooth start" made the applet appear, so systemd
should probably have started that service sooner.

Perhaps the problem is due to my bluetooth adapter being an usb one?


Can't reproduce the problem. Bluetooth works fine here.
Can you attach the output of
systemctl status bluetooth.service
after the boot?


After the boot, that command says that bluetooth.service is loaded but 
disabled, and inactive dead... and indeed, I have to "service bluetooth 
start" by hand.


Snark on #debian-science


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

Bug#692168: [d-i beta3 btrfs] Unable to install lilo or grub, when / partition is btrfs

[Holger Wansing]

Package: installation-reports

Boot method: booting virtual machine from CD
http://cdimage.debian.org/cdimage/wheezy_di_beta3/i386/iso-cd/debian-wheezy-DI-b3-i386-netinst.iso

Date: 02. Nov 2012

Machine: Virtualbox VM
Partitions: guided partitioning, using the whole disk, all files in one 
partition, format the / partition as btrfs

Partition table:
/dev/sda1   Linux
/dev/sda2   Extended
/dev/sda5   Swap


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

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

Comments/Problems:

Installation went fine so far, installing basesystem and additional
task ('Standard system') works fine, until it came to installing a
boot loader.

First I tried to install lilo, I selected to install into the MBR.
This lead to the error  /sbin/lilo failed with error code "1"
syslog contains this:
Unpacking lilo (from .../l/lilo/lilo_23.2-4_i386.deb) ...
Processing triggers for man-db ...
Setting up lilo (1:23.2-4) ...
WARNING: Added option 'large-memory', please run 'lilo' before you 
reboot.
+ boot = /dev/disk/by-id/ata-VBOX_HARDDISK_VBf9b9608c-a59c7d6e
+ root = "UUID=5400ffbc-ecod-47de-8103-32f2de035311"
WARNING: If boot / root options were converted, please run 'lilo' 
before you reboot.
Running lilo ...
Warning:
LBA32 addressing assumed
Fatal.  
Trying to map files from unnamed device 0x0013 (NFS/RAID mirror down ?)
dpkg: error processing lilo (--configure):
subprocess installed post-installation script returned error exit 
status 1
Error were encountered while processing:
lilo
E
:
Sub-process /usr/bin/dpkg returned an error code (1)


Then I tried grub, but it failed too:
syslog is not very verbose here:
grub-installer: info: Calling 'apt-install grub-pc' failed
WARNING **: Configuring 'grub-installer' failed with error code 1
WARNING **: Menu item 'grub-installer' failed.



I am unsure, what is the reason here, since I am trying to install into
the MBR, so the type of the root filesystem should be of no interest?

Don't know if this is relevant here, but probably btrfs-tools should be 
installed somehow? (in this case it is not installed.)


Holger



-- 
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Created with Sylpheed 3.0.2
under  D e b i a n   G N U / L I N U X   6.0  ( S q u e e z e )
Registered LinuxUser #311290 - http://counter.li.org/
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =


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

Bug#692147: nmu

[Michael Gilbert]

control: tag -1 patch

Hi, I've uploaded an nmu fixing this issue to delayed/5.  Please see
attached patch.

Best wishes,
Mike


javamorph.patch
Description: Binary data

Bug#691508: [PATCH] ovs-vsctl: Allow command-specific options to mingle with global options.

[Ben Pfaff]

On Fri, Nov 02, 2012 at 04:21:56PM -0500, Adam Heath wrote:
> On 11/02/2012 04:19 PM, Ben Pfaff wrote:
> > I still don't understand.  Why would an existing script call ovs-vsctl
> > with --may-exist as a global option?  The call would not do anything
> > useful, because it would exit with a fatal error every time.  Taking
> > this argument to its logical conclusion, one must never extend any
> > program by adding a new option, because it could break some existing
> > script that tries to use that (nonexistent) option.
> 
> Exactly.  Your patch breaks existing scripts, by suddenly allowing for
> --may-exist to work where it used to not.

You still haven't explained why an existing script would call
ovs-vsctl with --may-exist as a global option.  Why would it do that?

> I'm saying you should just change the error message, but do not allow
> for it to be used as a global option.

It's an option, and it's easier to do than the alternative patch that
I sent out, but I don't understand why you think it will break any
real script.  Who is in the habit of writing useless scripts that do
nothing but provoke errors?


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

Bug#691508: [PATCH] ovs-vsctl: Allow command-specific options to mingle with global options.

[Adam Heath]

On 11/02/2012 04:19 PM, Ben Pfaff wrote:
> I still don't understand.  Why would an existing script call ovs-vsctl
> with --may-exist as a global option?  The call would not do anything
> useful, because it would exit with a fatal error every time.  Taking
> this argument to its logical conclusion, one must never extend any
> program by adding a new option, because it could break some existing
> script that tries to use that (nonexistent) option.

Exactly.  Your patch breaks existing scripts, by suddenly allowing for
--may-exist to work where it used to not.

I'm saying you should just change the error message, but do not allow
for it to be used as a global option.


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

Bug#691257: Freeze exception request for js_of_ocaml 1.2-2

[Niels Thykier]

On 2012-10-26 10:35, Stéphane Glondu wrote:
> Dear Release Team,
> 
> Bug #691257 made me realize that the upstream tarball of the Debian
> package is not the same as the one currently available on the upstream
> website, and the contents does not match tag 1.2 in the upstream
> repository either.
> 
> There is one commit missing. It changes only changelog and version, and
> I would like to update the Debian package with it. Attached is a debdiff.
> 
> 
> Cheers,
> 

Hi,

It does not seem important, but given it is a doc-only change I am
willing to accept it if you are still willing to upload it.  If you do
upload it, please file an unblock bug after it has been in unstable for
a couple of days.

~Niels


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

Bug#673582: x11-xserver-utils: xsetroot -def doesn't

[Stephan Seidl]

Hi,
I recently upgraded from Lenny to Squeeze and got back what I always had,
adding the line

test -e /usr/include/X11/bitmaps/root_weave && xsetroot -bitmap 
/usr/include/X11/bitmaps/root_weave

to the file /etc/X11/xdm/Xsetup. May be that this is a workaround for you, too. 
`root_weave' looks
nice but makes some DVI extenders crazy, possibly the reason to use black as 
the default now.
Best regards,
Stephan


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

Bug#691508: [PATCH] ovs-vsctl: Allow command-specific options to mingle with global options.

[Ben Pfaff]

On Fri, Nov 02, 2012 at 03:40:20PM -0500, Adam Heath wrote:
> On 11/02/2012 12:49 PM, Ben Pfaff wrote:
> > On Mon, Oct 29, 2012 at 03:03:13PM -0500, Adam Heath wrote:
> >> On 10/29/2012 11:34 AM, Ben Pfaff wrote:
> >>> Until now, a command like "ovs-vsctl --may-exist add-br br0" yielded a
> >>> confusing error message.  Users had to realize that the correct form was
> >>> "ovs-vsctl -- --may-exist add-br br0", but instead they often reported a
> >>> bug or gave up in frustration.  Even though the behavior was documented, 
> >>> it
> >>> was counterintuitive.
> >>>
> >>> This commit allows command-specific options to be mixed with global
> >>> options, making both forms of the command listed above equally acceptable.
> >>
> >> Tbh, I would actually prefer to have command-specific options that
> >> appear in the global area issue an error.
> >>
> >> ==
> >> one-vsctl: Found command-specific --may-exist in global area, please
> >> use -- instead.
> >> ==
> >>
> >> See (1) for a reason why I'd prefer it the way I suggested above.
> >>
> >> 1: http://lwn.net/Articles/520198/
> >>you might need to wait a few days for it to become publically
> >>available.
> > 
> > OK, it's available now, and I skimmed over it, but the analogy to
> > ovs-vsctl isn't really obvious to me.  Can you elaborate?
> 
> Providing variants for valid parameter processing makes it harder to
> understand.  Instead, a warning/error should be issued saying the arg
> is not understood(and if it appears to be a per-cmd option in global
> space, then a message saying such should be displayed), but allowing
> for per-option to work for global is actually *breaking* existing
> scripts that error out.
> 
> Any existing script that places --may-exist in global space, without
> --, will currently have an error.  Your patch changes that.  So, that
> is bad.  Instead, if you just change the error message displayed in
> those cases, then there isn't any breakage.

I still don't understand.  Why would an existing script call ovs-vsctl
with --may-exist as a global option?  The call would not do anything
useful, because it would exit with a fatal error every time.  Taking
this argument to its logical conclusion, one must never extend any
program by adding a new option, because it could break some existing
script that tries to use that (nonexistent) option.


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

Bug#675731: base-files: Please add VERSION entry to /etc/os-release for unstable/testing too

[Luca Capello]

user eve...@debian.org
usertags 675731 + events-hardware
thanks

Hi there!

I discovered this bug while working on a script to automatize the
installation of the d-i BabelBox for the Debian Events Box:

  .

On Fri, 13 Jul 2012 16:38:44 +0200, Raphael Hertzog wrote:
> On Sun, 03 Jun 2012, Santiago Vila wrote:
>> If you want "wheezy", why can't you do this if VERSION is empty?
>> 
>> echo $PRETTY_NAME | awk '{ print $3 }' | sed -e 's#/.*##'
>
> To avoid such hackery, you could export a DEBIAN_CODENAME variable.
> /etc/os-release allows for vendor-specific fields.

If I read the os-release manpage correctly, Jeremy is right and VERSION
is the place where 'wheezy' should be:

   

  Options

  The following OS identifications parameters may be set using
  /etc/os-release:

  NAME=

A string identifying the operating system, without a version
component, and suitable for presentation to the user. If not set
defaults to NAME=Linux. Example: NAME=Fedora or NAME="Debian
GNU/Linux".

  VERSION=

A string identifying the operating system version, excluding any OS
name information, possibly including a release code name, and
suitable for presentation to the user. This field is
optional. Example: VERSION=17 or VERSION="17 (Beefy Miracle)".

  [...]

  VERSION_ID=

A lower-case string (mostly numeric, no spaces or other characters
outside of 0-9, a-z, ".", "_" and "-") identifying the operating
system version, excluding any OS name information or release code
name, and suitable for processing by scripts or usage in generated
file names. This field is optional. Example: VERSION_ID=17 or
VERSION_ID=11.04.

  PRETTY_NAME=

A pretty operating system name in a format suitable for presentation
to the user. May or may not contain a release code name or OS
version of some kind, as suitable. If not set defaults to
PRETTY_NAME="Linux". Example: PRETTY_NAME="Fedora 17 (Beefy
Miracle)".

IMHO the above translates to:

* squeeze

  NAME="Debian GNU/Linux"
  VERSION="6.0.6 (squeeze)"
  VERSION_ID="6.0.6"
  PRETTY_NAME="$NAME $VERSION"

* wheezy

  NAME="Debian GNU/Linux"
  VERSION="wheezy/sid"
  PRETTY_NAME="$NAME $VERSION"

Please also note that the current behavior is inconsistent WRT
/etc/debian_version, which has either the version number when on stable
or the codename when (in the form "$NEXT_STABLE/sid").

Thx, bye,
Gismo / Luca


pgpnEXYCWAZRw.pgp
Description: PGP signature

Bug#692070: Issue solved

[Harald Tlatlik]

Dear Vincent,

thanks to your hint it's working again. I had a years-old
manual installation in my local tree which I could not remember at all.
For some reasons I don't know it was "re-activated" during my system
actualisation.

Once more, thanks for helping so fast. How can I close this thread?

Harald


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

Bug#692167: ITP: notion-scripts -- Contributed scripts for the Notion window manager

[Dima Kogan]

Package: wnpp
Severity: wishlist
Owner: Dima Kogan 

* Package name: notion-scripts
  Version : 20121023
  Upstream Author : Various people
* URL : http://notion.sourceforge.net/
* License : Multiple. Each script is contributed and licensed separately
  Programming Lang: Lua
  Description : Contributed scripts for the Notion window manager
Provides user-contributed add-ons to the Notion window manager,
Including:
 * scripts that can alter Notion's window management behaviour
 * monitors for Notion's statusbar to monitor disk usage, network
   traffic, battery and more.
 * multiple themes that change Notion's look


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

Bug#692166: udev: Signal 11 (SEGV) caught by ps (procps-ng version 3.3.4)

[Gollum1]

Package: udev
Version: 175-7
Severity: important

Dear Maintainer,

Sorry for my bad English. 

My system don't start correctly, when finished system loading, I can not 
login on the systema (graphical whit KDM access), because the keyboard and the
mouse are not available.

During the boot process I saw a error signal by udev.

I restart the system in safe mode, and when I logged in, I tried to manually
start udev:

/etc/init.d/udev

the response:

Signal 11 (SEGV) caught by ps (procps-ng version 3.3.4)
ps:display.c:59: please report this bug
[warn] udev does not support container, not started ... (warning)


This is my first report bug, I hope my description is correct.

Tnx&Byez
Gollum1 (aka Mauro Zanardi) - gollum1.smeag...@gmail.com


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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages udev depends on:
ii  debconf [debconf-2.0]  1.5.46
ii  libc6  2.13-36
ii  libselinux12.1.9-5
ii  libudev0   175-7
ii  lsb-base   4.1+Debian7
ii  procps 1:3.3.3-2
ii  util-linux 2.20.1-5.2

Versions of packages udev recommends:
ii  pciutils  1:3.1.9-5
ii  usbutils  1:005-3

udev suggests no packages.

-- debconf information:
  udev/new_kernel_needed: false
  udev/title/upgrade:
  udev/reboot_needed:
  udev/sysfs_deprecated_incompatibility:


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

Bug#692156: Wheezy upgrade. No text, no icons and no menus. PowerPC GeForce FX 5200 Ultra

[Sven Joachim]

On 2012-11-02 21:21 +0100, Milan Kupcevic wrote:

> On 11/02/2012 03:30 PM, Sven Joachim wrote:
>> On 2012-11-02 20:19 +0100, Milan Kupcevic wrote:
>>>
>>> Even though there are no menus, icons and text in X, I can start xterm
>>> by pressing alt+F2 and typing 'xterm'. Text is displayed fine inside the
>>> xterm window. 3D rendering seems to work fine. Gears of glxgears are
>>> displayed perfectly well. It renders 189 FPS in full screen.
>> 
>> Even though glxgears works fine, the 3D driver is known to cause severe
>> display corruption on GeForce FX 5200¹.  Does it help to disable it?
>> E.g. run "echo LIBGL_ALWAYS_SOFTWARE=1 >> /etc/environment" and restart
>> your display manager to do so.
>> 
>
> No. It does not help. Text, icons and menus are still not displayed at
> all.

Too bad. :-(

> LIBGL_ALWAYS_SOFTWARE=1 degraded 3D rendering performance to 13 FPS
> in full screen.

That's to be expected.

> Just want to note that I had working wheezy desktop machine which got
> unusable after 'apt-get upgrade'. Can we get the same default
> functionality we had before the upgrade?

If somebody figures out the root of the bug and finds a solution,
certainly.  I suspect some endianness problem, since it would have been
reported earlier if it occured on x86 as well.

Meanwhile, either disable acceleration (boot with nouveau.noaccel=1) or
downgrade to version 1:0.0.16+git20120322+ab7291d-1.

Cheers,
   Sven


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

Bug#692165: closed by "Adam D. Barratt" (Re: Bug#692165: RM: sea-defender/0.9-2)

[Michael Gilbert]

From: "Adam D. Barratt" 
> That bug is less than 24 hours old at this point. On the other hand, the
> package was orphaned 48 hours before that and hasn't been touched in
> nearly two years. :-(

I considered it from the perspective of how long it would likely take
to figure out the real licensing of snoutlib.  With it not being very
clear, its very likely to take longer than the time its going to take
to release.

> Removal hint added.

Thanks!

Mike


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

Bug#691990: unblock: wicd/1.7.2.4-3 (pre-approval)

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2012-11-01 at 00:34 +0100, David Paleino wrote:
> I'm requesting pre-approval for an upload of wicd to unstable (targeted to
> testing). Please see the attached patch.

Please go ahead, and get back to us once the package has been in
unstable for a few days; thanks.

Regards,

Adam


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

Bug#691508: [PATCH] ovs-vsctl: Allow command-specific options to mingle with global options.

[Adam Heath]

On 11/02/2012 12:49 PM, Ben Pfaff wrote:
> On Mon, Oct 29, 2012 at 03:03:13PM -0500, Adam Heath wrote:
>> On 10/29/2012 11:34 AM, Ben Pfaff wrote:
>>> Until now, a command like "ovs-vsctl --may-exist add-br br0" yielded a
>>> confusing error message.  Users had to realize that the correct form was
>>> "ovs-vsctl -- --may-exist add-br br0", but instead they often reported a
>>> bug or gave up in frustration.  Even though the behavior was documented, it
>>> was counterintuitive.
>>>
>>> This commit allows command-specific options to be mixed with global
>>> options, making both forms of the command listed above equally acceptable.
>>
>> Tbh, I would actually prefer to have command-specific options that
>> appear in the global area issue an error.
>>
>> ==
>> one-vsctl: Found command-specific --may-exist in global area, please
>> use -- instead.
>> ==
>>
>> See (1) for a reason why I'd prefer it the way I suggested above.
>>
>> 1: http://lwn.net/Articles/520198/
>>you might need to wait a few days for it to become publically
>>available.
> 
> OK, it's available now, and I skimmed over it, but the analogy to
> ovs-vsctl isn't really obvious to me.  Can you elaborate?

Providing variants for valid parameter processing makes it harder to
understand.  Instead, a warning/error should be issued saying the arg
is not understood(and if it appears to be a per-cmd option in global
space, then a message saying such should be displayed), but allowing
for per-option to work for global is actually *breaking* existing
scripts that error out.

Any existing script that places --may-exist in global space, without
--, will currently have an error.  Your patch changes that.  So, that
is bad.  Instead, if you just change the error message displayed in
those cases, then there isn't any breakage.

The article applies to this senario, because your new patch will break
existing scripts.  The article also applies because ovs-vsctl should
have had better handling of border conditions in arg processing, by
providing more concise error messages.

==
ovs-vsctl: Found an unrecognized option(--may-exist) in the global
option area; perhaps you need to use -- to start a per-command option
area?
==


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

Bug#692162: X-Debbugs-Cc emails on bug submission not sent

[Don Armstrong]

Control: tag -1 moreinfo unreproducible

On Fri, 02 Nov 2012, Adrian Bunk wrote:
> In bug #692155 the X-Debbugs-Cc emails on bug submission were not
> sent (I've now manually forwarded the email).

That bug was sent on to debian-bugs-dist@lists.debian.org,
o...@debian.org, pkg-cups-de...@lists.alioth.debian.org, Technical
Committee , and the other groups that
   >it's supposed to go to.

2012-11-02 18:54:04 1TUMNY-8B-51 <= debb...@buxtehude.debian.org U=debbugs 
P=local S=6680 id=handler.692155.b.135188230631...@bugs.debian.org
2012-11-02 18:54:06 1TUMNY-8B-51 => tech-c...@packages.qa.debian.org 
R=dnslookup T=remote_smtp H=quantz.debian.org [206.12.19.122] 
X=TLS1.0:RSA_AES_256_CBC_SHA1:32
2012-11-02 18:54:09 1TUMNY-8B-51 => bugs=692...@lists.debian.org 
R=dnslookup T=remote_smtp H=bendel.debian.org [82.195.75.100] 
X=TLS1.0:RSA_AES_256_CBC_SHA1:32 DN=
2012-11-02 18:54:09 1TUMNY-8B-51 -> debian-c...@lists.debian.org 
R=dnslookup T=remote_smtp H=bendel.debian.org [82.195.75.100] 
X=TLS1.0:RSA_AES_256_CBC_SHA1:32 DN=
2012-11-02 18:54:09 1TUMNY-8B-51 -> debian-bugs-dist@lists.debian.org 
R=dnslookup T=remote_smtp H=bendel.debian.org [82.195.75.100] 
X=TLS1.0:RSA_AES_256_CBC_SHA1:3
2012-11-02 18:54:09 1TUMNY-8B-51 => pkg-cups-de...@lists.alioth.debian.org 
R=dnslookup T=remote_smtp H=lists.alioth.debian.org [217.196.43.134] C="250 OK 
id=1TUMNc
2012-11-02 18:54:10 1TUMNY-8B-51 => did...@raboud.com R=dnslookup 
T=remote_smtp H=mx.phpnet.org [195.144.11.40] C="250 ok 1351882450 qp 23289" 
QT=6s DT=1s
2012-11-02 18:54:10 1TUMNY-8B-51 Completed

If there's somewhere else it should have been sent, you'll have to
provide more information.



Don Armstrong

-- 
The major difference between a thing that might go wrong and a thing
that cannot possibly go wrong is that when a thing that cannot
possibly go wrong goes wrong it usually turns out to be impossible to
get at or repair.
 -- Douglas Adams  _Mostly Harmless_

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Bug#688712: wesnoth: needs to handle symlink to directory change of /usr/share/doc/wesnoth

[Vincent Cheng]

tag 688712 + patch
thanks

Hi Rhonda,

On Mon, Sep 24, 2012 at 4:07 PM, Andreas Beckmann  wrote:
> Package: wesnoth
> Version: 1:1.10.3-2
> Severity: important
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package partially overwrites
> wesnoth-1.8-data in squeeze to wheezy upgrades.
>
> /usr/share/doc/wesnoth is a link to wesnoth-1.8-data in squeeze and a
> regular directory in wheezy. dpkg does not replace symlinks with
> directories and vice versa, therefore maintainer scripts need to be
> used.

Since both wesnoth-1.10 and wesnoth-1.10-core are symlinks to
/usr/share/doc/wesnoth-1.10-data, I'm assuming that your intention was
for /usr/share/doc/wesnoth to be a symlink to
/usr/share/doc/wesnoth-1.10-data as well, right? Assuming that this is
correct, I propose the following patch (which I've also committed into
the git repo). It creates the symlink in the rules file, and includes
a postinst script for the wesnoth package to overwrite the
/usr/share/doc/wesnoth directory as a symlink for users who already
have the current wesnoth package in wheezy installed (heavily based on
libpipeline's postinst script).

(I admit I haven't tested this yet, but I'll do so ASAP.)

Regards,
Vincent


wesnoth-1.10_1.10.3-3.debdiff
Description: Binary data

Bug#683142: unblock: bdii/5.2.5-2+wheezy3

[Ansgar Burchardt]

I have accepted bdii/5.2.5-2+wheezy3 from NEW, however there are still
some things that maybe should be improved:

There is an empty /etc/sysconfig directory.

The postinst uses chown on files in non-root-owned directories.

I am not sure if including the symlink
/var/lib/bdii/gip/ldif/default.ldif -> /usr/share/bdii/default.ldif is
correct.

Ansgar


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

Bug#662169: couriergraph: diff for NMU version 0.25-4.2

[Salvatore Bonaccorso]

Control: tags 662169 + pending

I have cancelled the previous upload and also added the updated
Brazilian Portuguese debconf templates translation. Still uploaded to
DELAYED/3.

Regards,
Salvatore
diff -u couriergraph-0.25/debian/changelog couriergraph-0.25/debian/changelog
--- couriergraph-0.25/debian/changelog
+++ couriergraph-0.25/debian/changelog
@@ -1,3 +1,20 @@
+couriergraph (0.25-4.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Don't provide /var/run/servergraph in binary package.
+Fix "Ships a folder in /var/run or /var/lock (Policy Manual section
+9.3.2)". Create /var/run/servergraph in initscript if
+/var/run/servergraph is not present.
+Thanks to Thomas Goirand  (Closes: #689884)
+  * Check if daemon pid file is present and don't start daemon.
+Check if daemon pid is present. If pid file is present assume the daemon
+is still running and do not start another instance.
+This is otherwise a Debian Policy 9.3.2 violation. (Closes: #692157)
+  * Update Brazilian Portuguese debconf templates translation.
+Thanks to Adriano Rafael Gomes  (Closes: #662169)
+
+ -- Salvatore Bonaccorso   Fri, 02 Nov 2012 21:22:11 +0100
+
 couriergraph (0.25-4.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u couriergraph-0.25/debian/dirs couriergraph-0.25/debian/dirs
--- couriergraph-0.25/debian/dirs
+++ couriergraph-0.25/debian/dirs
@@ -4 +3,0 @@
-var/run/servergraph
diff -u couriergraph-0.25/debian/init couriergraph-0.25/debian/init
--- couriergraph-0.25/debian/init
+++ couriergraph-0.25/debian/init
@@ -14,7 +14,8 @@
 DESC="Courier login Statistics"
 DAEMON=/usr/sbin/couriergraph.pl
 
-PIDFILE=/var/run/servergraph/couriergraph.pid
+PIDDIR=/var/run/servergraph
+PIDFILE=$PIDDIR/couriergraph.pid
 RRD_DIR=/var/lib/couriergraph
 RRD_NAME=couriergraph
 
@@ -23,14 +24,25 @@
 if [ -f $CONFIG ]; then
 . $CONFIG
 fi
- 
+
+if [ ! -d $PIDDIR ]; then
+	mkdir -p $PIDDIR
+	chown daemon:root $PIDDIR
+fi
+
 case "$1" in
   start)
 	echo -n "Starting $DESC: "
-	start-stop-daemon --start --quiet --pidfile $PIDFILE \
-		--exec $DAEMON -N 15 -c daemon:adm -- \
-		-l $MAIL_LOG -d --daemon_rrd=$RRD_DIR --rrd_name=$RRD_NAME
-	echo "$NAME."
+	# If pid file is present the daemon is probably running
+	if [ -f "$PIDFILE" ]; then
+		echo "already running."
+		exit 1
+	else
+		start-stop-daemon --start --quiet --pidfile $PIDFILE \
+			--exec $DAEMON -N 15 -c daemon:adm -- \
+			-l $MAIL_LOG -d --daemon_rrd=$RRD_DIR --rrd_name=$RRD_NAME
+		echo "$NAME."
+	fi
   ;;
 
   stop)
diff -u couriergraph-0.25/debian/postinst couriergraph-0.25/debian/postinst
--- couriergraph-0.25/debian/postinst
+++ couriergraph-0.25/debian/postinst
@@ -27,7 +27,6 @@
 # installation fails and the `postinst' is called with `abort-upgrade',
 # `abort-remove' or `abort-deconfigure'.
 
-RUNDIR=/var/run/servergraph
 DATADIR=/var/lib/couriergraph
 CACHEDIR=/var/cache/couriergraph
 DEFAULTS=/etc/default/couriergraph
@@ -35,9 +34,6 @@
 case "$1" in
 configure)
 
-	mkdir -p $RUNDIR || true
-	chown daemon:root $RUNDIR
-
 	if [ ! -d $DATADIR ]; then mkdir $DATADIR; fi
 	chown root:adm $DATADIR
 	chmod 775 $DATADIR
diff -u couriergraph-0.25/debian/po/pt_BR.po couriergraph-0.25/debian/po/pt_BR.po
--- couriergraph-0.25/debian/po/pt_BR.po
+++ couriergraph-0.25/debian/po/pt_BR.po
@@ -1,25 +1,19 @@
-#
-#Translators, if you are not familiar with the PO format, gettext
-#documentation is worth reading, especially sections dedicated to
-#this format, e.g. by running:
-# info -n '(gettext)PO Files'
-# info -n '(gettext)Header Entry'
-#
-#Some information specific to po-debconf are available at
-#/usr/share/doc/po-debconf/README-trans
-# or http://www.debian.org/intl/l10n/po-debconf/README-trans
-#
-#Developers do not need to manually edit POT or PO files.
+# Debconf translations for couriergraph.
+# Copyright (C) 2012 THE couriergraph'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the couriergraph package.
+# Andr?? Lu??s Lopes , 2004.
+# Adriano Rafael Gomes , 2012.
 #
 msgid ""
 msgstr ""
-"Project-Id-Version: couriergraph\n"
+"Project-Id-Version: couriergraph 0.25-4.1\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2007-01-15 23:41+0100\n"
-"PO-Revision-Date: 2004-10-19 18:34+0200\n"
-"Last-Translator: Andr?? Lu??s Lopes \n"
-"Language-Team: Debian-BR Project \n"
-"Language: \n"
+"PO-Revision-Date: 2012-02-26 13:39-0300\n"
+"Last-Translator: Adriano Rafael Gomes \n"
+"Language-Team: Brazilian Portuguese \n"
+"Language: pt_BR\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
@@ -28,7 +22,7 @@
 #. Description
 #: ../templates:1001
 msgid "Should CourierGraph start on boot?"
-msgstr "O CourierGraph deve ser iniciado na inicializao da m??quina ?"
+msgstr "O CourierGraph deve ser iniciado na inicializao da m??quina?"
 
 #. Type: boolean
 #. Description
@@ -37,9 +31,9 @@
 

Bug#692165: RM: sea-defender/0.9-2

[Michael Gilbert]

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

Please remove sea-defender.  I includes a few non-free files
(#692078).  It is a leaf package and has not been included in a stable
release yet.

Best wishes,
Mike


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

Bug#692156: Wheezy upgrade. No text, no icons and no menus. PowerPC GeForce FX 5200 Ultra

[Milan Kupcevic]

On 11/02/2012 03:30 PM, Sven Joachim wrote:
> On 2012-11-02 20:19 +0100, Milan Kupcevic wrote:
>>
>> Even though there are no menus, icons and text in X, I can start xterm
>> by pressing alt+F2 and typing 'xterm'. Text is displayed fine inside the
>> xterm window. 3D rendering seems to work fine. Gears of glxgears are
>> displayed perfectly well. It renders 189 FPS in full screen.
> 
> Even though glxgears works fine, the 3D driver is known to cause severe
> display corruption on GeForce FX 5200¹.  Does it help to disable it?
> E.g. run "echo LIBGL_ALWAYS_SOFTWARE=1 >> /etc/environment" and restart
> your display manager to do so.
> 

No. It does not help. Text, icons and menus are still not displayed at
all. LIBGL_ALWAYS_SOFTWARE=1 degraded 3D rendering performance to 13 FPS
in full screen.

Just want to note that I had working wheezy desktop machine which got
unusable after 'apt-get upgrade'. Can we get the same default
functionality we had before the upgrade? It was running fine with Gnome
Classic, but now it does not.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#692149: xulrunner-16.0: depends on libnspr4 AND (instead of OR) libnspr4-0d

[Mike Hommey]

On Fri, Nov 02, 2012 at 08:15:35PM +0100, Armin Haas wrote:
> On Fri, Nov 02, 2012 at 07:41:40PM +0100, Mike Hommey wrote:
> > On Fri, Nov 02, 2012 at 06:50:36PM +0100, Armin Haas wrote:
> > > Package: xulrunner-16.0
> > > Version: 16.0.2-1
> > > Severity: minor
> > > 
> > > Dear Maintainer,
> > > 
> > > please change xulrunner's dependency from libnspr4 AND libnspr4-0d to
> > > libnspr4 | libnspr4-0d (the second being the transitional package
> > > for the first) like you already did with libnss3 | libnss3-1d.
> > 
> > The dependencies are automatically generated, and older libnspr4-0d
> > doesnt contain the symbols xulrunner-16.0 requires. Adding a dependency
> > to a transitional package for the sake of it is useless.
> > 
> > Mike
> 
> Sorry for being unclear in my description. xulrunner-16.0 already depends on
> both libnspr4 and libnspr4-0d. What I wanted is the absolute dependency on
> libnspr4-0d to go away. So if libnspr4 is already present on the system,
> xulrunner-16.0 shouldn't require the transitional package libnspr4-0d to be
> present as well.

ah


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

Bug#692164: dpkg-dev: dpkg-source should throw an error on quilt format packages with upstream tarballs already containing a .pc directory

[Michael Gilbert]

package: dpkg-dev
version: 1.16.9
severity: important
control: affects 692073

Hi, dpkg-source will have trouble dealing with upstream tarballs
containing pre-existing .pc directories.  For example, see:
http://bugs.debian.org/692073

Since results can be unpredictable in these situations, I think the
ideal solution is for dpkg-source to throw and error when it comes
across a tarball with .pc already existing.

Best wishes,
Mike


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

Bug#689453: Pre-approval request, Gnuplot 4.6.1 for Wheezy

[Niels Thykier]

On 2012-10-02 22:03, Anton Gladky wrote:
> Thanks, Torquil, for the information.
> 


Hi,

Sorry for the delay in getting back to you.

> Dear release-team, would you agree to unblock
> Gnuplot 4.6.1 for the Wheezy, if it will be packaged?
> [...]

We generally do not make decisions based on the changelogs alone.
Please send us a debdiff including the upstream changes[1] and we will
have a look.
  If the diff is relatively large, please double check it actually
reaches the list when you send it.  We have had a number of cases, where
the mail never reached us because lists.d.o /silently/ dropped the mail.
 However, keep in mind that if the diff is this huge, we usually cannot
review it and will default to a "no".
  In this case, we may still consider accepting a subset of the changes
(cherry-picked fixes) for various bugs.

~Niels

[1] Feel free to filter out .po files and auto-generated files like
autoconf's configure via filterdiff if such appear in the diff.  Though
please mention if you do apply such a filter.


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

Bug#692163: bsnes: /usr/games/bsnes executable fails (bsnes-bin not found)

[Rafael Cunha de Almeida]

Package: bsnes
Version: 0.088-5
Severity: normal

Dear Maintainer,

/usr/games/bsnes calls bsnes-bin, assuming bsnes-bin is on PATH.
Unless you have /usr/games on your PATH, executing /usr/games/bsnes
will fail. Please consider using the full path for bsnes-bin on
bsnes script.

Moreover, I see in debian policy state that games binaries should
be installed in /usr/games. However, it does not seem to define
what a game is. Is an emulator a game? Also, policy does not seem
to say one should not create a link to /usr/bin from
/usr/game/ is that considered a bad thing?

FYI: I'm running bsnes on a sid chroot inside a squeeze system.
However, I don't think this would make a difference for this
report.

Regards,
Rafael


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

Kernel: Linux 2.6.32-5-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 bsnes depends on:
ii  libao41.1.0-2
ii  libasound21.0.25-4
ii  libatk1.0-0   2.4.0-2
ii  libc6 2.13-36
ii  libcairo2 1.12.2-2
ii  libfontconfig12.9.0-7
ii  libfreetype6  2.4.9-1
ii  libgcc1   1:4.7.2-4
ii  libgdk-pixbuf2.0-02.26.1-1
ii  libgl1-mesa-glx [libgl1]  8.0.4-2
ii  libglib2.0-0  2.33.12+really2.32.4-3
ii  libgtk2.0-0   2.24.10-2
ii  libopenal11:1.14-4
ii  libpango1.0-0 1.30.0-1
ii  libpulse0 2.0-6
ii  libsdl1.2debian   1.2.15-5
ii  libstdc++64.7.2-4
ii  libx11-6  2:1.5.0-1
ii  libxext6  2:1.3.1-2
ii  libxv12:1.0.7-1

bsnes recommends no packages.

Versions of packages bsnes suggests:
pn  laevateinn  

-- 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#692150: Bluetooth disabled by default

[Michael Biebl]

On 02.11.2012 18:53, Julien Puydt wrote:
> Package: systemd
> Version: 44-5
> 
> After entering my xfce session, I noticed that the blueman applet was 
> missing. A "service bluetooth start" made the applet appear, so systemd 
> should probably have started that service sooner.
> 
> Perhaps the problem is due to my bluetooth adapter being an usb one?

Can't reproduce the problem. Bluetooth works fine here.
Can you attach the output of
systemctl status bluetooth.service
after the boot?




-- 
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