Bug#697580: connman: CVE-2012-6459

[Moritz Muehlenhoff]

Package: connman
Severity: grave
Tags: security

Please check, whether the version/configuration in Debian is affected:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-6459
https://bugs.tizen.org/jira/browse/TIVI-211
http://git.kernel.org/?p=network/connman/connman.git;a=commit;h=01126286f96856aab6b0de171830f4e8e842e1da

Cheers,
Moritz


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

Bug#697579: unblock: kanatest/0.4.8-2.1

[Evgeni Golov]

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

Dear RT,

Hideki uploaded an NMU of kanatest back in september, but apparently never
asked for an unblock for it. I know it's way to late for such an unblock,
but maybe you would still consider it (I won't cry if not) :)
It's just a packaging change, depending on other fonts. The debdiff folows.

diff -u kanatest-0.4.8/debian/control kanatest-0.4.8/debian/control
--- kanatest-0.4.8/debian/control
+++ kanatest-0.4.8/debian/control
@@ -13,8 +13,8 @@
 Package: kanatest
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends: ttf-kochi-mincho | ttf-kochi-gothic
-Suggests: ttf-mikachan
+Recommends: fonts-ipafont-mincho | fonts-japanese-mincho
+Suggests: fonts-mikachan
 Description: beginner's drill game to learn Japanese kana characters
  Kanatest is a simple hiragana and katakana drill game. It checks your
  knowledge of Japanese kana characters.
diff -u kanatest-0.4.8/debian/changelog kanatest-0.4.8/debian/changelog
--- kanatest-0.4.8/debian/changelog
+++ kanatest-0.4.8/debian/changelog
@@ -1,3 +1,11 @@
+kanatest (0.4.8-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/control
+- Update to use appropriate Japanese font (Closes: #642941)
+
+ -- Hideki Yamane   Wed, 12 Sep 2012 07:49:02 +0900
+
 kanatest (0.4.8-2) unstable; urgency=low
 
   * debian/control:

unblock kanatest/0.4.8-2.1

TIA
Evgeni

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

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


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

Bug#696844: patch is valid

[Larry Doolittle]

I reviewed the pmw-4.24 code, and Thorsten Glaser's patch.
His analysis and patch is correct.  After the patch, the code
is correct even in the presence of ASLR.

At least every Debian system, and probably every POSIX system,
will unmap page zero to make sure null pointer dereferences
are trapped.  Since 256 is less than every known page size,
these "small integers" are guaranteed not to be valid pointers
of the kind created in tables.c to populate out_mftable_ps[].
So after casting this "pointer" to unsigned long (guaranteed by
the C standard to fit), the test p < 256 will work as intended.

I can't reproduce the later error reported by Ghostscript.

  - Larry


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

Bug#697578: unblock: abyss/1.3.4-3

[Andreas Tille]

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

Please unblock package abyss

Build without POPCNT to make sure the program will run on any i686 box.

unblock abyss/1.3.4-3

-- System Information:
Debian Release: 6.0.6
Architecture: i386 (i686)

Kernel: Linux 2.6.36-xenU-4814-i386 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru abyss-1.3.4/debian/changelog abyss-1.3.4/debian/changelog
--- abyss-1.3.4/debian/changelog	2012-06-01 08:40:38.0 +0200
+++ abyss-1.3.4/debian/changelog	2013-01-04 11:09:04.0 +0100
@@ -1,3 +1,13 @@
+abyss (1.3.4-3) unstable; urgency=low
+
+  * Disable POPCNT
+Closes: #697344
+  * Add debian/README.debian to inform users about this change asking
+for some comparison of the speed to consider other means for better
+performance
+
+ -- Andreas Tille   Fri, 04 Jan 2013 11:07:10 +0100
+
 abyss (1.3.4-2) unstable; urgency=low
 
   * Team upload
diff -Nru abyss-1.3.4/debian/README.Debian abyss-1.3.4/debian/README.Debian
--- abyss-1.3.4/debian/README.Debian	1970-01-01 01:00:00.0 +0100
+++ abyss-1.3.4/debian/README.Debian	2013-01-04 11:09:04.0 +0100
@@ -0,0 +1,24 @@
+Abyss for Debian
+
+
+Due to
+
+   http://bugs.debian.org/697344
+
+this package was compiled using --disable-popcnt.  If you need to profit
+from extra speed enhancement you could create a local package by doing
+the following:
+
+   $ apt-get source abyss
+   $ dch -i
+   local build enabling POPCNT
+   $ vi debian/rules
+   remove '--disable-popcnt' from configure options
+   $ debuild
+   $ dpkg -i ../abyss*.deb
+
+Please inform us (= Debian Med team) about the gain of speed compared
+to the packaged version to enable us to try some better means to get
+the best out of your hardware.
+
+ -- Andreas Tille   Fri, 04 Jan 2013 11:07:10 +0100
diff -Nru abyss-1.3.4/debian/rules abyss-1.3.4/debian/rules
--- abyss-1.3.4/debian/rules	2012-06-01 08:40:38.0 +0200
+++ abyss-1.3.4/debian/rules	2013-01-04 11:09:04.0 +0100
@@ -6,7 +6,7 @@
 	dh  $@
 
 override_dh_auto_configure:
-	dh_auto_configure -- --with-mpi=/usr/lib/openmpi
+	dh_auto_configure -- --with-mpi=/usr/lib/openmpi --disable-popcnt
 
 override_dh_auto_install:
 	dh_auto_install --destdir=debian/tmp

Bug#697525: Invalid profile file: org.dbdoclet.trafo.tokenizer.TokenizerException

[Michael Fuchs]

Hello Mathieu,

the error message is not correct. Not the profile file is invalid, but
my tokenizer has a problem with the comment
.
I will fix the tokenizer and the error message asap.

Thanks,
Michael


Am 06.01.2013 16:18, schrieb Mathieu Malaterre:
> Package: herold
> Version: 6.0.4-1
> Severity: normal
>
> herold 6.0.4 stops working after 6.0.3 upgrades. It now fails with:
>
> $ herold -i p.html -o p.xml
> [FATAL] Invalid profile file: 
> org.dbdoclet.trafo.tokenizer.TokenizerException: 
> [org.dbdoclet.trafo.xml.tokenizer.parser.TokenMgrError] Lexical error at line 
> 233, column 18.  Encountered: "-" (45), after : "

Bug#697577: apt: default pkgProblemResolver::Scores prioritise Priority: important over Priority: required

[Paul Wise]

Package: apt
Version: 0.8.10.3
Severity: important

A note on the version information for this bug: it is present in both
wheezy and squeeze and probably earlier.

The default pkgProblemResolver::Scores::Important is greater than
pkgProblemResolver::Scores::Required. According to my reading of the
Debian policy document, Priority: required should be higher than
Priority: important:

http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Priority
http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities

Code that needs to be adjusted here is PrioMap in
pkgProblemResolver::MakeScores() in apt-pkg/algorithms.cc and if you
change the order then probably you also need to adjust the order in
PrioList in ./apt-pkg/deb/deblistparser.cc.

static debListParser::WordList PrioList[] = 
{{"important",pkgCache::State::Important},
   {"required",pkgCache::State::Required},
   {"standard",pkgCache::State::Standard},
   {"optional",pkgCache::State::Optional},
   {"extra",pkgCache::State::Extra},
   {}};

void pkgProblemResolver::MakeScores()
{
   unsigned long Size = Cache.Head().PackageCount;
   memset(Scores,0,sizeof(*Scores)*Size);

   // Important Required Standard Optional Extra
   int PrioMap[] = {
  0,
  _config->FindI("pkgProblemResolver::Scores::Important",3),
  _config->FindI("pkgProblemResolver::Scores::Required",2),
  _config->FindI("pkgProblemResolver::Scores::Standard",1),
  _config->FindI("pkgProblemResolver::Scores::Optional",-1),
  _config->FindI("pkgProblemResolver::Scores::Extra",-2)
   };

pabs@chianamo ~ $ sudo apt-get -o Debug::pkgProblemResolver=yes -o 
Debug::pkgProblemResolver::ShowScores=yes dist-upgrade 2>&1 | head -n30
Reading package lists...
Building dependency tree...
Reading state information...
Starting
Settings used to calculate pkgProblemResolver::Scores::
  Important => 3
  Required => 2
  Standard => 1
  Optional => -1
  Extra => -2
  Essentials => 100
  InstalledAndNotObsolete => 1
  Depends => 1
  Recommends => 1
  AddProtected => 1
  AddEssential => 5000
Show Scores
24475 libc6 [ amd64 ] < 2.13-37 -> 2.13-38 | 2.16-0experimental1 > ( libs )
12428 multiarch-support [ amd64 ] < 2.13-37 -> 2.13-38 | 2.16-0experimental1 > 
( libs )

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#697576: unbound: FTBFS with multiarch python headers

[Micah Gersten]

Package: unbound
Version: 1.4.19-1
Severity: normal
Tags: patch
User: debian-pyt...@lists.debian.org
Usertags: origin-ubuntu raring ubuntu-patch multiarch

A simple addition in the acx_python.m4 file allows this package to build with 
python multiarch headers.  I removed the single-debian-patch option to make 
this a disparate change, but feel free to ignore that part of the diff.

*** /tmp/tmpQOtvso/bug_body

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


  * Include python multiarch path in CPPFLAGS; Fixes FTBFS
- add debian/patches/fix-python-multiarch.patch
- update debian/patches/series
  * Remove source options as it only contains 'single-debian-patch' since we
should have the Ubuntu changes separate from the Debian changes
- drop debian/source/options


Thanks for considering the patch.


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

Kernel: Linux 3.2.0-35-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru unbound-1.4.19/debian/changelog unbound-1.4.19/debian/changelog
diff -Nru unbound-1.4.19/debian/control unbound-1.4.19/debian/control
diff -Nru unbound-1.4.19/debian/patches/fix-python-multiarch.patch unbound-1.4.19/debian/patches/fix-python-multiarch.patch
--- unbound-1.4.19/debian/patches/fix-python-multiarch.patch	1969-12-31 18:00:00.0 -0600
+++ unbound-1.4.19/debian/patches/fix-python-multiarch.patch	2013-01-07 00:31:40.0 -0600
@@ -0,0 +1,19 @@
+Description: Include python multiarch header path
+Author: Micah Gersten 
+
+--- unbound-1.4.19.orig/acx_python.m4
 unbound-1.4.19/acx_python.m4
+@@ -90,7 +90,12 @@ $ac_distutils_result])
+ if test -n "${python_path}"; then
+ python_path="-I$python_path"
+ fi
+-PYTHON_CPPFLAGS=$python_path
++python_multiarch_path=`$PYTHON -c "import distutils.sysconfig; \
++print distutils.sysconfig.get_python_inc(plat_specific=1);"`
++if test -n "${python_multiarch_path}"; then
++python_multiarch_path="-I$python_multiarch_path"
++fi
++PYTHON_CPPFLAGS="$python_path $python_multiarch_path"
+ fi
+ AC_MSG_RESULT([$PYTHON_CPPFLAGS])
+ AC_SUBST([PYTHON_CPPFLAGS])
diff -Nru unbound-1.4.19/debian/patches/series unbound-1.4.19/debian/patches/series
--- unbound-1.4.19/debian/patches/series	2012-12-14 20:35:48.0 -0600
+++ unbound-1.4.19/debian/patches/series	2013-01-07 00:32:13.0 -0600
@@ -1 +1,2 @@
 debian-changes
+fix-python-multiarch.patch
diff -Nru unbound-1.4.19/debian/source/options unbound-1.4.19/debian/source/options
--- unbound-1.4.19/debian/source/options	2012-12-14 20:34:01.0 -0600
+++ unbound-1.4.19/debian/source/options	1969-12-31 18:00:00.0 -0600
@@ -1 +0,0 @@
-single-debian-patch

Bug#693623: #696421: unblock: icedtea-web/1.3.1-2

[Drew Parsons]

Niels Thykier wrote:
> FTR, I have requested permission to upload a version fixing this bug to
> unstable (targeting Wheezy).  For more information on this, please see
> #696421[1].


Hi Niels, while we're waiting to hear back about #696421, could you
consider uploading the fixed version to experimental?

This bug has financial implications, and for me it's causing iceweasel
(10.0.11esr-1) to crash completely (cf. bug#678240, unless that is a
separate bug).  My crash trace is:

$ iceweasel
java version "1.7.0_03"
OpenJDK Runtime Environment (IcedTea7 2.1.3) (7u3-2.1.3-1)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)
Unable to find class net.sourceforge.jnlp.security.VariableX509TrustManagerJDK7
java.net.MalformedURLException: unknown protocol: chrome
at java.net.URL.(URL.java:592)
at java.net.URL.(URL.java:482)
at java.net.URL.(URL.java:431)
at 
sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:491)
at 
sun.applet.PluginStreamHandler.handleMessage(PluginStreamHandler.java:232)
at 
sun.applet.PluginMessageHandlerWorker.run(PluginMessageHandlerWorker.java:78)
java.lang.RuntimeException: Failed to handle message: tag 
chrome://browser/content/browser.xul  for instance 1
at 
sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:560)
at 
sun.applet.PluginStreamHandler.handleMessage(PluginStreamHandler.java:232)
at 
sun.applet.PluginMessageHandlerWorker.run(PluginMessageHandlerWorker.java:78)
Caused by: java.net.MalformedURLException: unknown protocol: chrome
at java.net.URL.(URL.java:592)
at java.net.URL.(URL.java:482)
at java.net.URL.(URL.java:431)
at 
sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:491)


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

Bug#697575: unbound: Incomplete dh_python2 conversion

[Micah Gersten]

Package: unbound
Version: 1.4.19-1
Severity: normal
Tags: patch
User: debian-pyt...@lists.debian.org
Usertags: origin-ubuntu raring ubuntu-patch

It seems that a couple things were missed when the package was converted to 
dh_python2.
Per http://wiki.debian.org/Python/TransitionToDHPython2, XS-Python-Version: all 
is no longer supported with dh_python2 and python-support isn't needed

*** /tmp/tmp_KbhwE/bug_body

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

  * Drop unneeded python-support build-dep and 'XS-Python-Version: all' since
the package is using dh_python2
- update debian/control


Thanks for considering the patch.


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

Kernel: Linux 3.2.0-35-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru unbound-1.4.19/debian/changelog unbound-1.4.19/debian/changelog
diff -Nru unbound-1.4.19/debian/control unbound-1.4.19/debian/control
--- unbound-1.4.19/debian/control	2012-12-14 20:34:01.0 -0600
+++ unbound-1.4.19/debian/control	2013-01-07 00:48:10.0 -0600
@@ -5,12 +5,11 @@
 Build-Depends: dpkg-dev (>= 1.16.1~), debhelper (>= 9~), doxygen,
  autoconf, automake, autotools-dev, libtool, flex, bison, libldns-dev (>= 1.6.13~),
  libssl-dev, libevent-dev, libexpat1-dev, python-all-dev (>= 2.6.6-3~),
- python-support, swig
+ swig
 Standards-Version: 3.9.3
 Homepage: http://www.unbound.net/
-XS-Python-Version: all
 Vcs-Browser: http://git.debian.org/?p=users/edmonds/unbound.git
 Vcs-Git: git://git.debian.org/~edmonds/unbound.git
 
 Package: unbound
 Architecture: any

Bug#695130: First commits in git repository on Alioth [ Was: Re: openmotif is now LGPL, retirement of lesstif in jessie?]

[Graham Inggs]

On 6 January 2013 16:44, Paul Gevers  wrote:

> [ Graham, should I drop direct e-mail to you, i.e. do you receive the
> mail via the PTS anyway? ]
>

I'm receiving bug mail via the PTS for openmotif, but I don't think for
this (695130) bug.

- Did you make any changes to be able to upgrade the standard version
>   (I always note the changes in the changelog, even if there are none)
>

No changes.


> - Do I understand correctly that you replaced autotools by a dependency
>   on dh_autoconf? (Please note these things in the changelog).
>

I replaced the dependency on autotools-dev with one on dh-autoreconf.


> - Could we propose a configuration flag for the demo stuff, so that
>   upstream can keep track of the demo programs and we don't have to
>   patch the source?
>

That makes sense.  I'll see if I can come up with a suitable patch to
configure.ac.


> - My fix [3] for "format not a string literal and no format arguments"
>   is slightly different for sprintf cases. Shouldn't it be better to
>   replace the sprintf by a simple strcpy?
>

I don't mind.  I suppose the only reason to stay with sprintf would be one
of style.
If upstream decided to make MSG__0113 (referred to in the first change in
line 267 of lib/Mrm/Mrmhier.c) more informative by changing "Could not open
buffer - UID version mismatch" to "Could not open buffer - UID version
mismatch (%d)" then they would have to use sprintf instead of strcpy.

- d/motif-client.links is not useful now, I suggest you remove it.
>

Ah, thanks!

Do you need me to upload the above changes to my PPA?


> I would like you to do the git push of the 2.3.4 stuff. Do you want to
> wait until you have access to collab-maint, or do you want me to commit
> your changes, and contribute my changes as well?
>

Please go ahead and commit my changes as well as any others as you see fit.

Bug#683584: security update ready for squeeze (3.1.8)

[Yves-Alexis Perez]

On lun., 2013-01-07 at 00:35 +0100, Daniel Pocock wrote:
> Yes, the 3.1.8 security fix from upstream has been packaged and has
> been waiting for security team to process through to the archive

Can you elaborate on that?
-- 
Yves-Alexis


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

Bug#686020: acpi-support-base: Please downgrade consolekit recommend into a suggestion

[I. Schrey]

Hi,

are there any particular reasons why this change hasn't found its way 
into Wheezy yet?



Regards
Ingmar


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

Bug#659440: ITP: primus -- Low-overhead client-side GPU offloading

[Vincent Cheng]

On Sun, Jan 6, 2013 at 12:33 AM, Mathieu Malaterre  wrote:
> On Sun, Jan 6, 2013 at 2:41 AM, Vincent Cheng  wrote:
>> On Thu, Jan 3, 2013 at 11:53 PM, Mathieu Malaterre  wrote:
>>> On Thu, Jan 3, 2013 at 10:30 PM, Aron Xu  wrote:
 Hi Cheng,

 On Sun, Dec 30, 2012 at 6:11 PM, Vincent Cheng  
 wrote:
> Hi everyone,
>
> I just wanted to chip in and share the work I've done on primus'
> packaging, since there aren't any readily-available .debs (or a
> repository) for primus on Debian (at least, I haven't found any yet).
> The packaging is definitely a work-in-progress, but IMHO primus itself
> is pretty mature, and the only regression it has compared to
> optirun/VirtualGL (that I've found) is that it doesn't seem to work
> with nvidia-settings (a few games that I have which crash using
> primusrun also crash with optirun, so no loss there).
>
> http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/index.html
>
> (or a direct link to the .dsc:
> http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primus_0~20121211-1~vc1.dsc)
>

 I haven't tried your package yet, but I invite you to help me maintain
 this package. There are many things on my plate already and it would
 be good to work with you, ;-)

 I plan to work on packaging/uploading bumblebee after 9th this month,
 it's not so urgent as bbswitch is still in NEW. Again, help is
 appreciated!
>>>
>>> Since both packages are related to NVidia technologies, why not
>>> maintain them under the Debian NVIDIA Maintainers
>>>  group ?
>>>
>>> See:
>>> http://qa.debian.org/developer.php?login=pkg-nvidia-de...@lists.alioth.debian.org
>>>
>>> 2cts,
>>
>> I'm indifferent to maintaining the set of packages that bumblebee
>> requires either within or outside of pkg-nvidia. On one hand,
>> virtualgl/primus is only being considered in Debian right now for
>> bumblebee support, but these technologies are not specifically tied to
>> Nvidia. Then again, bumblebee and co. will only be necessary with the
>> proprietary nvidia drivers once prime/dma-buf support for nouveau is
>> fully implemented and mature (I'm unsure about what the current status
>> of optimus support with the free drivers are, at this moment).
>>
>> I'll hold off on uploading my primus packaging until we come to some
>> sort of consensus...
>
> Please dont. My suggestion to use the pkg-nvidia-devel umbrella group
> was simply a mean of going thing going, not stopping them.
>
> I work within other umbrealla group and this help in situations such
> as (p-n-d makes it as easy chanel for discussion):
> - request DD upload from a DM
> - discussion on p-n-d@d.o on complex dependencies for package. If your
> package is a leaf in the dependency tree, then this does not apply to
> you.

I generally agree that maintaining packages in a team is better than
not doing so, when there are multiple people willing to work on the
package. For primus specifically however, I'm still not quite sure
which approach everyone would prefer; Aron has already said that he
thinks that primus should be maintained outside the team, and I don't
think anyone who's currently in the pkg-nvidia team (Russ/Andreas?)
has commented on whether or not they'd like to have primus maintained
within the team.

Being able to use pkg-nvidia-devel@lists.a.d.o rather than having to
setup another mailing list is certainly very convenient though.

> If you feel confidant, then please upload as-is.

I'm just a DM, so I'll need a sponsor once the package is fit for the
archives. (I've worked with Aron on a number of other packages before,
so presumably he'd be willing to sponsor my package, regardless of
whether primus ends up being team-maintained or not.)

How about this: I'll upload my work to collab-maint for now, and if we
decide later that we do in fact want primus maintained in pkg-nvidia,
we could always just switch over. :)

Vincent


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

Bug#697485: xvfb: example in Xvfb(1) does not work

[Daniel Kahn Gillmor]

On Sat 2013-01-05 19:16:53 -0500, Daniel Kahn Gillmor wrote:

> Xvfb(1) says:
>
> EXAMPLES
>Xvfb :1 -screen 0 1600x1200x32
>The server will listen for connections as server number 1,  and
>screen 0 will be depth 32 1600x1200.
>
>
> but in practice:
>
> 
> 0 dkg@alice:~/tmp$ Xvfb :1 -screen 0 1600x1200x32
>
> Fatal server error:
> Couldn't add screen 0
> 1 dkg@alice:~/tmp$ 
> 
>
> So either Xvfb is broken, or the man page is wrong.


In practice, it looks like the choice of bitdepth parameters has an
effect here.  the following three invocations work as expected:

  Xvfb :1 -screen 0 1600x1200x8
  Xvfb :1 -screen 0 1600x1200x16
  Xvfb :1 -screen 0 1600x1200x24

so maybe the manpage just needs a tuneup?

   --dkg


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

Bug#697035: installer: kb and mouse don't work on a decTop (NSC geode processor)

[Ben Hutchings]

On Fri, 2013-01-04 at 00:37 -0800, Phil McCracken wrote:
> Hello,
> 
> On Fri, 2013-01-04 at 04:06 +, Steven Chamberlain wrote:
> 
> > I have some AMD Geode NX / CS5535-based devices (Wyse Sx0) which only
> > allow me to enter the BIOS menu with a *specific* USB keyboard out of
> > about 3 or 4 that I tried.  (A cheap and uninteresting one branded
> > "SWEEX" works;  a more expensive Cherry and some others didn't).
> >
> > It would be interesting to see your output of `lsusb -v` when the
> > keyboard is working.
> 
> ok, I just reinstalled lenny, so here goes:
[...]
> Bus 001 Device 003: ID 0518:0002 EzKEY Corp. EZ-9900C Keyboard
[...]

As I suspected - this wants the special hid-ezkey driver, and we are not
including this in the installer.

I'll add that and check for other special HID keyboard/mouse drivers at
the same time.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.


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

Bug#697357: bridging broken over bond interfaces

[Ben Hutchings]

Forwarding this to netdev since the bug is still present in Linux 3.7.1.
For those joining us, this thread is archive at
.

On Fri, 2013-01-04 at 13:40 +0100, Peter Palfrader wrote:
> On Fri, 04 Jan 2013, Bastian Blank wrote:
> 
> > On Fri, Jan 04, 2013 at 12:17:12PM +0100, Peter Palfrader wrote:
> > > I tried to set up a new KVM host in the usual way:
> > >   - have a bond0 interface over all physcial eth* interfaces
> > >   - create a br0 over that bond0 and any vnet* interfaces for the
> > > guests.
> 
> Also, arp works through the bridge, forgot to mention that.
> 
> > > *   Manually switching the eth* to promiscious mode makes stuff work.
> > 
> > Okay, so a workaround is available.
> > 
> > When did it last work? Does it work with the kernel from experimental?
> 
> It works nicely on stable, e.g. pasquini.debian.org:
> 
> | weasel@pasquini:~$ sudo brctl show
> | bridge name bridge id   STP enabled interfaces
> | br0 8000.e83935a9ec10   no  bond0
> | tap0
> | tap1
> | tap2
> | br1 8000.e83935a9ec10   no  bond0.221
> | br2 8000.da1343affe92   no  bond0.3301
> | tap3
> 
> And there the bond interface is promisc automatically:
> weasel@pasquini:~$ ip a | grep -i bond
> | 2: eth0:  mtu 1500 qdisc pfifo_fast 
> master bond0 state UP qlen 1000
> | 3: eth1:  mtu 1500 qdisc pfifo_fast 
> master bond0 state UP qlen 1000
> | 4: bond0:  mtu 1500 qdisc 
> noqueue state UP 
> | 7: bond0.221@bond0:  mtu 1500 qdisc 
> noqueue state UP 
> | 9: bond0.3301@bond0:  mtu 1500 
> qdisc noqueue state UP 
> 
> Likewise it works as expected when one does br directly on eth0, without any
> bonding.
> 
> It's also broken with 
> linux-image-3.7-trunk-amd64_3.7.1-1~experimental.1_amd64.deb.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.


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

Bug#697574: qcontrol: please load local config files

[Hanno Hecker]

Package: qcontrol
Version: 0.4.2+svn-r40-3
Severity: wishlist
Tags: patch

Hi Ian,

the attached patch loads "/etc/qcontrol/local.lua" if it exists and has no
errors. Maybe this should not be only for ts41x.lua :)

Hanno

-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: armel (armv5tel)

Kernel: Linux 3.2.0-4-kirkwood
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages qcontrol depends on:
ii  libc62.13-37
ii  liblua5.1-0  5.1.5-4
ii  udev 175-7

qcontrol recommends no packages.

qcontrol suggests no packages.

-- Configuration Files:
/etc/qcontrol/ts41x.lua changed [not included]

-- no debconf information
--- ts41x.lua.OLD	2012-11-25 12:59:02.0 +0100
+++ ts41x.lua	2013-01-06 19:24:15.912821093 +0100
@@ -134,3 +134,25 @@
 		setfan("silence")
 	end
 end
+
+function load_local_conf ()
+	local conf_file = "/etc/qcontrol/local.lua"
+	local res
+
+	local data, err = loadfile(conf_file)
+	if data == nil then
+		logprint("error with "..conf_file..": "..err)
+		return
+	end
+
+	res, err = pcall(data)
+	if not res then
+		logprint("error calling "..conf_file..": "..err)
+		return
+	end
+
+	logprint("successfully loaded "..conf_file)
+	return
+end
+
+load_local_conf()

Bug#697270: PC 32-bit programs fails to work on amd64

[Ben Hutchings]

On Fri, 2013-01-04 at 13:03 +, Colin Watson wrote:
> On Thu, Jan 03, 2013 at 06:59:49PM +, Ben Hutchings wrote:
> > dpkg --add-architecture i386
> > apt-get update
> > 
> > The installer doesn't AFAIK provide even the option to do this.  (The
> > i386/amd64 installer images might at least be usable as multiarch APT
> > sources though.)  So this is a usability regression in wheezy.
> 
> I don't think I got round to updating apt-setup for the new
> --add-architecture scheme; but the apt-setup/multiarch template does
> exist and I think that at this point it would count as a bug-fix to make
> it work properly.  Given that, you could at least boot the installer
> with apt-setup/multiarch=i386.

Yes, please.

> I think that apt-setup/multiarch=i386 should be the default on amd64;
> but I'm less sure that I could convince anyone that that deserves a
> freeze exception.

I'm convinced, but I don't count. :-)

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.


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

Bug#697490: cloud: 697490: use sudoers.d

[Bromberger, James]

This (sudoers.d) looks completely sensible to me (and indeed, I saw the same 
issue and realized the danger of overwriting the sudoers file accidentally 
removing access to the host). Perhaps time to start to get ready to re-roll the 
image with accrued fixes. (this one, Libc6, etc). if anyone needs access to the 
AWS account for resource access in order to test, please let me know.

  James
PS: If you do overwrite /etc/sudoers, then you can recover it by stopping the 
host (not terminate), present the root volume to another host, mounting it, 
edit the sudoers file, unmount, unpresent, and then start the host again. But 
sudoers/d may be neater. ;)



James Bromberger | Solution Architect | Amazon Web Services
E: jame...@amazon.com 



-Original Message-
From: Anders Ingemann [mailto:and...@ingemann.de] 
Sent: Monday, 7 January 2013 8:18 AM
To: Chris Fordham
Cc: Charles Plessy; 697...@bugs.debian.org
Subject: Bug#697490: cloud: 697490: use sudoers.d

On 6 January 2013 22:55, Chris Fordham  wrote:
> This is a good example of why template-based configuration is better 
> used rather than regex/stream based editing.

well. d'uh! :-P
I did not know about sudoers.d when I wrote it, otherwise I can assure you that 
we wouldn't be talking about this to begin with ;-)


--
To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/camcogxhnnz_mgmdu_upwmrfqrcpmfdbu7r8b5eqjaxvumho...@mail.gmail.com

Bug#695182: Write couple of 1GB files for OOM crash

[Ben Hutchings]

On Mon, 2013-01-07 at 14:03 +1100, paul.sz...@sydney.edu.au wrote:
> Dear Jonathan,
> 
> > Here's a quick review from a non-expert (i.e., me). ...
> 
> Thanks!
> 
> > ... When the patch
> > seems ready to you, please send it inline in a message to
> > linux...@kvack.org, cc-ing linux-ker...@vger.kernel.org and Ben and me
> > (or this bug log) so we can track it.  The mm folks will probably have
> > more feedback, and we can take it from there.
> 
> I was hoping that Ben would take that on; but OK, will do (first waiting
> for maybe Ben's comments, and your reply to my questions below).
[...]

I think Jonathan's covered everything.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.


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

Bug#694035: JSON based API to query available AMIs

[Bromberger, James]

Nice.

Only question - with marketplace not available in ap-southeast-2 (Sydney), do 
we want ot put in the AMIs for the 32 and 64 bit AMIs that sit inside our 
Debian AWS  Account?

  James

James Bromberger | Solution Architect | Amazon Web Services
E: jame...@amazon.com   P: +61 422 166 708



-Original Message-
From: Charles Plessy [mailto:ple...@debian.org] 
Sent: Sunday, 6 January 2013 9:59 AM
To: 694...@bugs.debian.org
Subject: Bug#694035: JSON based API to query available AMIs

Le Sun, Nov 25, 2012 at 09:31:28PM +0800, James Bromberger a écrit :
> 
> Any AMI list could be done as a CloudFront template - see the example 
> on http://wiki.debian.org/Cloud/AmazonEC2Image/Squeeze. This example 
> can be put into an AWS Bucket for public distribution. We could also 
> chose to publish the "mappings" section similarly for inclusion into other 
> templates.

Hi James and everybody,

in order to experience myself with parsing remote JSON data, I have copied the 
mapping of image identifiers of Cloud/AmazonEC2Image/Squeeze to 
Cloud/AmazonEC2Image/Squeeze/JSON.

Here is what I added to the Cloud/AmazonEC2Image/Squeeze page.

It is planned to provide a machine-readable version of the above list of
images. For the sake of the brainstorm, a JSON version is temporarly placed 
at
Cloud/AmazonEC2Image/Squeeze/JSON. However, the structure is very likely to
change, see #694035 for details. Here is a naive example on how to query the
list. euca-describe-images $(curl --silent
http://wiki.debian.org/Cloud/AmazonEC2Image/Squeeze/JSON?action=raw | 
jsonpipe
| awk '/Debian606.ap-northeast-1.64/ {print $2}' | sed 's/"//g')

Have a nice week-end,

--
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130106015915.ga21...@plessy.org


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

Bug#696965: support for HW_SKIP_CONSOLE breaks use by blind people

[Peter Hutterer]

On Sat, Jan 05, 2013 at 07:06:05PM +0100, Samuel Thibault wrote:
> Michal Suchanek, le Sat 05 Jan 2013 18:55:28 +0100, a écrit :
> > On 5 January 2013 02:10, Samuel Thibault  wrote:
> > > Alan Coopersmith, le Mon 31 Dec 2012 17:46:47 -0800, a écrit :
> > >> On 12/31/12 05:36 PM, Samuel Thibault wrote:
> > >> > Michal Suchanek, le Mon 31 Dec 2012 19:22:13 +0100, a écrit :
> > >> >> why is that patch needed?
> > >> >>
> > >> >> It is quite non-obvious why would dummy driver require a console under
> > >> >> any circumstances. It does not render anything anywhere so does not
> > >> >> use console for anything.
> > >> >
> > >> > The console *is* needed for keyboard input.
> > >> >
> > >> > Again, the use case is blind people who have use of possessing an 
> > >> > actual
> > >> > screen, and thus don't have any, and thus have to use the dummy driver.
> > >>
> > >> So it sounds like that should be handled by the input driver, not the
> > >> output driver.
> > >
> > > Ok, that makes sense. Input drivers however don't currently have a way
> > > to request the core to callxf86OpenConsole, similar to the absence of
> > > the HW_SKIP_CONSOLE flag in the case of video drivers.
> > >
> > > What do you recommend to add to the InputDriverRec? A driverFunc method
> > > like video drivers? Something else?
> > 
> > I still don't understand the problem. The evdev driver opens the evdev
> > device when loaded and reads input there. That happens even with dummy
> > video driver so long as you do not carefully prevent the evdev driver
> > from loading, does it not?
> 
> It does not. See for instance the attached xorg.conf, then I run from
> vt1
> 
> xinit /usr/bin/fvwm -- :1
> 
> there is no VT switch, and pressing ^C 5s later kills the server (while
> we'd want ^C to just go to the server). The resulting Xorg.1.log is
> attached.

while it shows the issue, this is not a good example. the config section for
the keyboard isn't referenced from the layout so it doesn't apply, and the
config for the mouse is ignored because input hotplugging is enabled. so
only the dummy driver section applies, the rest of this config has no effect.

> What I understand is that evedev does open things, but since no VT was
> allocated, the evdev driver does not eat keypresses, i.e. from its point
> of view it's as if we had switched away from an allocated VT.

evdev reads data off /dev/input/eventX and it doesn't need a console.

but without xf86OpenConsole() and ioctl(KDSKBMODE), the events are also
sent to the console. this is your real problem, since both get the event and
you can kill your server. we've had this issue years back after switching to
evdev as standard driver, and then when we removed the EVIOCGRAB from evdev.

> So what Alan suggested is that the evdev driver simply tells the core
> that it needs a VT to work properly. I'm now just asking which way that
> should be done.

I'm not sure this is the right approach. evdev doesn't need a VT to work
properly, I've got a use-case here (automated testing) that works perfectly
well without a VT. plus, with hotplugging you don't actually know if and
when an evdev device will be added.

so the solution here would be to only call xf86OpenConsole() when a keyboard
device comes up. on the plus side, if the evdev driver is broken this would
allow you to Ctrl+C the server. On the minus side, there's a window where
you can Ctrl+C the server until the device has been added.

your use-case (or mine, depending on your POV) seems to need not a console
switch but an option to enable/disable keyboard input from being sent to the
console. this is the solution we should be looking at, imo.

Cheers,
   Peter


> Section "InputDevice"
>   Identifier  "Generic Keyboard"
>   Driver  "evdev"
>   Option  "XkbModel"  "geniuskb19e"
>   Option  "XkbLayout" "fr,brai"
>   Option  "XkbVariant""oss,"
>   Option  "XkbOptions"
> "compose:lwin,compose:rwin,nbsp:level3n,grp:shift_caps_toggle"
> EndSection
> 
> Section "InputDevice"
>   Identifier  "Configured Mouse"
>   Driver  "mouse"
>   Option  "CorePointer"
>   Option  "Device""/dev/gpmdata"
>   Option  "Protocol"  "IntelliMouse"
>   Option  "Emulate3Buttons"   "true"
> EndSection
> 
> Section "Device"
>   Identifier  "Configured Video Device"
>   Driver  "dummy"
> EndSection
> 
> Section "Monitor"
>   Identifier  "Configured Monitor"
> EndSection


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

Bug#697565: lintian: dsc field original-maintainer is unknown to lintian

[Nick Black]

Russ Allbery left as an exercise for the reader:
> We do have a mechanism for adding information about derivatives in the
> form of profiles.  I don't know if SprezzOS already has one, or if that
> facility would handle this particular case.  (I'm a bit behind in
> following recent development.)

Yeah, I saw that Ubuntu had one in there. There didn't seem to be any
mechanism by which one could specify data for "all derivatives" though, so
it was a choice of adding a SprezzOS section for this (and then adding it to
all other such sections), or a global recognition.

-- 
nick black http://www.sprezzatech.com -- unix and hpc consulting
to make an apple pie from scratch, you need first invent a universe.


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

Bug#697565: lintian: dsc field original-maintainer is unknown to lintian

[Russ Allbery]

Nick Black  writes:
> Russ Allbery left as an exercise for the reader:

>> I certainly have no objections to recognizing the header for derivatives,
>> where it serves a very useful purpose.

> Outstanding. I'm sorry if I misunderstood you! In that case, rather than
> forking, I'll just maintain this as a patch in the SprezzOS package.

We do have a mechanism for adding information about derivatives in the
form of profiles.  I don't know if SprezzOS already has one, or if that
facility would handle this particular case.  (I'm a bit behind in
following recent development.)

-- 
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#695182: Write couple of 1GB files for OOM crash

[Jonathan Nieder]

paul.sz...@sydney.edu.au wrote:

>>> +/* Easy call: do "echo 3 > /proc/sys/vm/drop_caches" */
>>
>> I don't understand this comment.  What does "Easy call" mean?
>>
>>> +void easy_drop_caches(void)
[...]
>> This should be declared in some appropriate header (e.g.,
>> include/linux/mm.h).
>
> I added one new call, so I could easily call it from elsewhere without
> having to (cross?)-declare many things; in fact would have preferred to
> call iterate_supers() and drop_slab() directly.
>
> Yes, easy_drop_caches() might be declared in some include file, but
> should that be  or ? Would add another file to
> those changed, seemed more direct this way.

Remember that once your patch is applied, it is part of the Linux
kernel that other people develop against.  So it is best to optimize
for readability of the result, not readability of the patch.  Another
file changed is not a big deal.

The existing drop_caches functionality is declared in linux/mm.h, so I
think this new function would be easiest to find there.

> Should I change something?

Please clarify the comment to explain what the function is meant
to do.  It will help future readers.

[...]
>>> +   /* Subtract min_free_kbytes */
>>> +   if (min_free_kbytes > 0)
>>> +   y = min_free_kbytes >> (PAGE_SHIFT - 10);
>>
>> Why the "if"?
>
> Sanity-check paranoia: because I do not trust the input values. Maybe
> should have
>   BUG_ON(min_free_kbytes < 0);
> but that does not belong there.

Elsewhere the code assumes that min_free_kbytes is nonnegative.  If
you want to check that assertion here, that's fine.  An assertion test
would be spelled as

if (!WARN_ON(min_free_kbytes < 0))

since it's possible for the kernel to recover for additional debugging
when it fails.

[...]
>>> setpoint = (freerun + limit) / 2;
>>> -   x = div_s64((setpoint - dirty) << RATELIMIT_CALC_SHIFT,
>>> +   x = div_s64(((s64)setpoint - (s64)dirty) << RATELIMIT_CALC_SHIFT,
>>> limit - setpoint + 1);
>>
>> Why are 'setpoint' and 'dirty' of type unsigned long instead of long
>> in the first place?  What happens if one of their values overflows a
>> long?
>
> I guess because most other such things are also unsigned long; and I
> guess they were so when they meant memory addresses. These are now page
> counts, cannot overflow (with current limit of 64GB RAM).

This could be worth a comment and WARN_ON to document the assumption
so other readers don't have to be distracted by the same question.
Something like

/*
 * Since memory addresses fit in an unsigned long, page
 * counts cannot overflow a "long" and a cast to s64 is safe.
 */
WARN_ON(setpoint > LONG_MAX || dirty > LONG_MAX);
BUILD_BUG_ON(sizeof(long) > sizeof(s64));

x = div_s64(((s64)setpoint - ...

[...]
>>> --- mm/vmscan.c.old 2012-10-17 13:50:15.0 +1100
>>> +++ mm/vmscan.c 2013-01-06 09:50:49.0 +1100
>> [...]
>>> @@ -2726,9 +2731,87 @@ loop_again:
>>> nr_slab = shrink_slab(&shrink, sc.nr_scanned, 
>>> lru_pages);
>>> sc.nr_reclaimed += 
>>> reclaim_state->reclaimed_slab;
>>> total_scanned += sc.nr_scanned;
>>> +   if (unlikely(
>>> +   i == 1 &&
>>> +   nr_slab < 10 &&
>>> +   (reclaim_state->reclaimed_slab) < 10 &&
>>> +   zone_page_state(zone, NR_SLAB_RECLAIMABLE) 
>>> > 10 &&
[...]
>> This is getting really deeply nested.  Would it be possible to split
>> out a function so this code could be more easily contemplated in
>> isolation?
>
> Hmm... I would much prefer to leave it as is.

Can you say a little about why?  At this point in the function, the
context is

static unsigned long balance_pgdat()
{
...
for (priority = DEF_PRIORITY; priority >= 0; priority--) {
...
for (i = 0; i <= end_zone; i++) {
...
if (!zone_watermark_ok_safe(zone, order, ...) {
...
if (unlikely(i == 1 && ...) {

It is easy to lose track at this point in a long function.  As
Documentation/CodingStyle explains:

Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen.  The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.

and:

Functions should be short and sweet, and do just one thing.  They should
fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
as we all know), and do one thing and do that well.

The maximum length of a f

Bug#9063: Is this bug still present?

[Olly Betts]

On Sat, Jul 10, 1999 at 02:27:49PM -0400, Ben Pfaff wrote:
> Is this bug, in which the last message recorded is from May 1997,
> still relevant?  If not, please let me know so that I can close it.

The patch hasn't been applied by upstream, but in newer autoconf releases,
autoheader (now rewritten in Perl) supports command line options to allow
you to add entries to the search path.  If you run recent autoheader with
"--prepend-include=." then it should find acconfig.h in the current
directory, which is apparently what the patch aims to accomplish.

Looking at the krb5 package, src/configure in 1.10.1+dfsg-3 has:

# Generated by GNU Autoconf 2.67 for Kerberos 5 1.10.1.

And debian/patches/0010-autoreconf.patch suggests that's been regenerated
by the debian maintainer, and upstream used 2.65, so it looks like krb no
longer needs a patched autoconf.

So it seems to me this bug should probably just be closed now.

Cheers,
Olly


signature.asc
Description: Digital signature

Bug#697565: lintian: dsc field original-maintainer is unknown to lintian

[Nick Black]

Russ Allbery left as an exercise for the reader:
> But it may be that I'm overthinking this; I suppose it's hard to see what

I'd like to think that's the case.

> I certainly have no objections to recognizing the header for derivatives,
> where it serves a very useful purpose.

Outstanding. I'm sorry if I misunderstood you! In that case, rather than
forking, I'll just maintain this as a patch in the SprezzOS package.

-- 
nick black http://www.sprezzatech.com -- unix and hpc consulting
to make an apple pie from scratch, you need first invent a universe.


signature.asc
Description: Digital signature

Bug#637207: New upstream release: 1.2

[Mitchell Smith]

Hi,

Unfortunately this package has fallen behind the upstream release significantly.

I hoped to get a 1.2 release included in wheezy, but I was too late.

The upstream maintainer has now release 1.3, and it would be great to
bring the Debian package up to the latest upstream release.

I could prepare a 1.3 package ready for review this week, please
advise how you would like to proceed on this.

Thanks



On 1/7/13, Eugene V. Lyubimkin  wrote:
> 2013-01-06 19:00, Alessio Treglia:
>> Eugene, could you please mail the MIA team about this bug?
>
> Done.
>
> --
> Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
> C++ GNU/Linux userspace developer, Debian Developer
>


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

Bug#697573: freecad: drawing templates missing

[W. Martin Borgert]

Package: freecad
Version: 0.13~20121120.git5082ae2-2~exp2

In 0.12, there are two files
/usr/share/freecad/Mod/Drawing/Templates/A3_Landscape.svg
and
/usr/share/freecad/Mod/Drawing/Templates/A4_Simple.svg
that are missing from 0.13. The current git contains even
more drawing templates, that should be in the package.


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

Bug#695182: Write couple of 1GB files for OOM crash

[paul . szabo]

Dear Jonathan,

> Here's a quick review from a non-expert (i.e., me). ...

Thanks!

> ... When the patch
> seems ready to you, please send it inline in a message to
> linux...@kvack.org, cc-ing linux-ker...@vger.kernel.org and Ben and me
> (or this bug log) so we can track it.  The mm folks will probably have
> more feedback, and we can take it from there.

I was hoping that Ben would take that on; but OK, will do (first waiting
for maybe Ben's comments, and your reply to my questions below).

>> Also included are several minor fixes:
> Those should go in separate patches, but if you're just seeking
> comments then lumping them with the main change in a patch with
> [RFC/PATCH] in the subject line is fine.

In a sense, I am seeking comments on why lowmem is ever polluted with
caches and why slabs are not cleared up without dropping pagecache, as
I feel that the "real bug" is lurking there. - I admit that I do not
understand MM, it seems a mess to my un-educatedf eyes. - Some of those
comments are questions, some others I am sure are bugs.

OK, will use [RFC/PATCH] in the subject.

>> +/* Easy call: do "echo 3 > /proc/sys/vm/drop_caches" */
>
> I don't understand this comment.  What does "Easy call" mean?
>
>> +void easy_drop_caches(void)
>> +{
>> +iterate_supers(drop_pagecache_sb, NULL);
>> +drop_slab();
>> +}
>
> This should be declared in some appropriate header (e.g.,
> include/linux/mm.h).

I added one new call, so I could easily call it from elsewhere without
having to (cross?)-declare many things; in fact would have preferred to
call iterate_supers() and drop_slab() directly.

Yes, easy_drop_caches() might be declared in some include file, but
should that be  or ? Would add another file to
those changed, seemed more direct this way.

Should I change something?

>> --- mm/page-writeback.c.old  2012-10-17 13:50:15.0 +1100
>> +++ mm/page-writeback.c  2013-01-06 21:54:59.0 +1100
>> @@ -39,7 +39,8 @@
>>  /*
>>   * Sleep at most 200ms at a time in balance_dirty_pages().
>>   */
>> -#define MAX_PAUSE   max(HZ/5, 1)
>> +/* Might as well be max(HZ/5,4) to ensure max_pause/4>0 always */
>> +#define MAX_PAUSE   max(HZ/5, 4)
>
> This is one of the "while at it"s rather than the main point of
> the patch, right?

Yes, it was one of the unimportant oddities I noticed.

> [...]
>> @@ -343,11 +344,26 @@ static unsigned long highmem_dirtyable_m
>>  unsigned long determine_dirtyable_memory(void)
>>  {
>>  unsigned long x;
>> +int y = 0;
>> +extern int min_free_kbytes;
>
> Probably should be declared in a header like mm/internal.h, but
> there's precedent for the ad-hoc declaration, so meh.

Yes, I noticed some precedents.

> [...]
>> +/*
>> + * Seems that highmem_is_dirtyable is only used here, in the
>> + * calculation of limits and threshholds of dirtiness, not in deciding
>> + * where to put dirty things. Is that so? Is that as should be?
>> + * What is the recommended setting of highmem_is_dirtyable?
>> + */
>>  if (!vm_highmem_is_dirtyable)
>>  x -= highmem_dirtyable_memory(x);
>
> I dunno.  See 195cf453d2c3 (mm/page-writeback: highmem_is_dirtyable
> option, 2008-02-04) and the thread surrounding
> .

That made my head spin... Thanks for the pointers, will go through them
sometime.

>> +/* Subtract min_free_kbytes */
>> +if (min_free_kbytes > 0)
>> +y = min_free_kbytes >> (PAGE_SHIFT - 10);
>
> Why the "if"?

Sanity-check paranoia: because I do not trust the input values. Maybe
should have
  BUG_ON(min_free_kbytes < 0);
but that does not belong there.

> If I were doing it, I think I'd unconditionally set 'y' here, for
> clarity and to avoid bugs if some later patch reuses the var for
> something else.
>
>   y = min_free_kbytes >> (PAGE_SHIFT - 10);
>   x -= min(x, y);

Do you think I should change my patch? To me, it seemed clearer the way 
I had it.

> [...]
>> @@ -559,7 +578,7 @@ static unsigned long bdi_position_ratio(
>>   * => fast response on large errors; small oscillation near setpoint
>>   */
>>  setpoint = (freerun + limit) / 2;
>> -x = div_s64((setpoint - dirty) << RATELIMIT_CALC_SHIFT,
>> +x = div_s64(((s64)setpoint - (s64)dirty) << RATELIMIT_CALC_SHIFT,
>>  limit - setpoint + 1);
>
> Why are 'setpoint' and 'dirty' of type unsigned long instead of long
> in the first place?  What happens if one of their values overflows a
> long?

I guess because most other such things are also unsigned long; and I
guess they were so when they meant memory addresses. These are now page
counts, cannot overflow (with current limit of 64GB RAM).

>> @@ -995,6 +1014,13 @@ static unsigned long bdi_max_pause(struc
>>   * The pause time will be settled within range (max_pause/4, max_pause).
>>   * Apply a minimal value of 4 to get a non-zero max_pause/4.
>>   */
>> +/*
>> + * O

Bug#624343: data corruption: md changes max_sector setting of running md devices

[NeilBrown]

On Sun, 6 Jan 2013 12:31:46 +0100 (CET) bug556...@arcor.de wrote:

> Alan Woodland:
> > If I've understood this correctly one possible workaround for this
> > (for the time being) would be to add a boot parameter that lets you
> > artificially limit max_hw_sectors? In this case it seems forcing all
> > md devices down from 248 to 240 would probably avoid potential data
> > loss issues without large performance degradation or big intrusive
> > changes. Is that sane?
> 
> 
> In lieu of a proper upstream bug tracker?: 
> https://bugs.launchpad.net/mdadm/+bug/320638 :

The upstream bug tracker is
   mailto:linux-r...@vger.kernel.org

> Problem: md changes max_sector setting of an already running and busy
> md device, when a (hotplugable) device is added or removed. However, the
> device mapper and filesystem layer on top of the raid can not (always?)
> cope with that.
> 
> Observations:
> * "bio too big device mdX (248 > 240)" messages in the syslog
> * read/write errors (some dropped silently, no noticable errors 
> reported during operation, until things like dhcpclient looses its IP etc.)
> 
> Expected:
> Adding and removing members to running raids (hotplugging) should not
> change the raid device characteristics. If the new member supports only
> smaller max_sector values, buffer and split the data steam, until the raid 
> device can be set up from a clean state with a more appropriate 
> max_sector value. To avoid buffering and splitting in the future, md could 
> save the smallest max_sector value of the known members in the 
> superblock, and use that when setting up the raid even if that member is 
> not present.

This really needs to be fixed by cleaning up the bio path so that big bios
are split by the device that needs the split, not be the fs sending the bio.

I would not be at all happy to have md do the extra buffering and splitting
that you suggest.
Maybe the best interim fix is to reject the added device is its limits are
too low.

NeilBrown


> 
> Note: This is reproducible in much more common scenarios as the 
> original reporter had (e.g. --add a USB (3.0 these days) drive to an 
> already running SATA raid1 and grow the number of devices).



signature.asc
Description: PGP signature

Bug#686113: Fails to configure with emacs24 / causes emacs24 upgrade to fail

[Norbert Preining]

Hi Rob,

I ping another time ... any idea?

On Do, 13 Dez 2012,  wrote:
> Hi Rob,
> 
> I would like to ask for your help concerning bug #686113. It is somehow
> strange that the byte compile doe snot work.
> 
> I reduced it to the following minimal example:
>   ; from the path.el generatd in the emacsen install script
>   (setq load-path (cons "." load-path))
>   (setq byte-compile-warnings nil)
>   ;
>   ; the next two lines are in the org-mu4.el file that do not compile
>   ; this line works
>   (require 'org nil 'noerror)
>   ; this line breaks
>   (require 'org-exp nil 'noerror)
> 
> In principle when the mu4e .el files are compiled, what happens is
>   emacs24 -no-site-file -q -batch -l path.el -f batch-byte-compile ...
> wher path.el contains the first two code lines.
> 
> Now the above example always breaks with
>   In toplevel form:
>   bla.el:9:9:Error: Can't find library org
> where line 9 is the line with (require 'org-exp nil 'noerror)
> but only if emacs24-el is *not* installed. As soon as I install 
> emacs24-el, all is fine.
> 
> Do you have any idea what could be the reason for that?
> 
> I include the original bug report below, for completeness.
> 
> Thanks a lot and all the best
> 
> Norbert
> 
> 
> On Di, 28 Aug 2012, Axel Beckert wrote:
> > Package: mu4e
> > Version: 0.9.8.5-3
> > Severity: serious
> > 
> > Not sure in which order I initially installed mu4e and emacs24, but
> > emacs24 fails to upgrade (from 24.1+1-2 to 24.1+1-4) with the
> > following messages:
> > 
> > ---snip---
> > Install mu4e for emacs24
> > install/mu4e: Handling install for emacsen flavor emacs24
> > Problems while trying to load feature `org-jsinfo'
> > OVERVIEW
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-about.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-actions.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-compose.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-headers.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-main.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-mark.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-meta.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-proc.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-speedbar.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-utils.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-vars.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-view.elc
> > 
> > In toplevel form:
> > org-mu4e.el:31:30:Error: Can't find library org
> > ERROR: install script from mu4e package failed
> > dpkg: Fehler beim Bearbeiten von emacs24 (--install):
> >  Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 
> > zurück
> > ---snap---
> > 
> > Removing mu4e from the system solves the issue. Trying to install it
> > again afterwards fails with the same symptoms:
> > 
> > ---snip---
> > Vormals nicht ausgewähltes Paket mu4e wird gewählt.
> > (Lese Datenbank ... 699721 Dateien und Verzeichnisse sind derzeit 
> > installiert.)
> > Entpacken von mu4e (aus .../mu4e_0.9.8.5-3_all.deb) ...
> > Trigger für install-info werden verarbeitet ...
> > mu4e (0.9.8.5-3) wird eingerichtet ...
> > Install mu4e for emacs
> > Install mu4e for emacs23
> > install/mu4e: Handling install for emacsen flavor emacs23
> > OVERVIEW
> > Wrote /usr/share/emacs23/site-lisp/mu4e/mu4e-about.elc
> > Wrote /usr/share/emacs23/site-lisp/mu4e/mu4e-actions.elc
> > Wrote /usr/share/emacs23/site-lisp/mu4e/mu4e-compose.elc
> > Wrote /usr/share/emacs23/site-lisp/mu4e/mu4e.elc
> > Wrote /usr/share/emacs23/site-lisp/mu4e/mu4e-headers.elc
> > Wrote /usr/share/emacs23/site-lisp/mu4e/mu4e-main.elc
> > Wrote /usr/share/emacs23/site-lisp/mu4e/mu4e-mark.elc
> > Wrote /usr/share/emacs23/site-lisp/mu4e/mu4e-meta.elc
> > Wrote /usr/share/emacs23/site-lisp/mu4e/mu4e-proc.elc
> > Wrote /usr/share/emacs23/site-lisp/mu4e/mu4e-speedbar.elc
> > Wrote /usr/share/emacs23/site-lisp/mu4e/mu4e-utils.elc
> > Wrote /usr/share/emacs23/site-lisp/mu4e/mu4e-vars.elc
> > Wrote /usr/share/emacs23/site-lisp/mu4e/mu4e-view.elc
> > Wrote /usr/share/emacs23/site-lisp/mu4e/org-mu4e.elc
> > Install mu4e for emacs24
> > install/mu4e: Handling install for emacsen flavor emacs24
> > Problems while trying to load feature `org-jsinfo'
> > OVERVIEW
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-about.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-actions.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-compose.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-headers.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-main.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-mark.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-meta.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-proc.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-speedbar.elc
> > Wrote /usr/share/emacs24/site-lisp/mu4e/mu4e-utils.elc

Bug#697565: lintian: dsc field original-maintainer is unknown to lintian

[Russ Allbery]

Nick Black  writes:

> I can assure you that close to 90% of SprezzOS packages use the flag, as
> do a great many Ubuntu packages. Furthermore, anyone following the Debian
> documentation at

>   http://wiki.debian.org/Derivatives/Guidelines

> is going to use this field. Please see "Packages", second line:

> "When modifying source packages, rename the Maintainer field to
>  XSBC-Original-Maintainer and add a new Maintainer field."

> If we're not going to know about this field in lintian, perhaps it
> oughtn't be recommended to all derivatives. The field being useful,
> however, I hope it will be retained.

Just to clarify, the only thing I was objecting to was to allowing the
header globally, as opposed to only in derivative profiles.  I'm not sure
that it makes sense to introduce it into Debian proper, and personally
would like to have Lintian warn me if I had the header in my packaging.
But it may be that I'm overthinking this; I suppose it's hard to see what
actual harm the header causes in Debian proper and one person seems to
find it useful.

I certainly have no objections to recognizing the header for derivatives,
where it serves a very useful purpose.

-- 
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#697572: Regression in mysqldump with security update DSA 2581-1

[Dan Wallis]

Package: mysql-client-5.1
Version: 5.1.66-0+squeeze1

The security update DSA 2581-1 introduced a regression in the
mysqldump utility. The regression is already reported upstream, and a
patch has been proposed there: http://bugs.mysql.com/bug.php?id=65670

$ mysql -se 'show variables like "version"'
Variable_name   Value
version 5.0.51a-24+lenny5-log
$ mysqldump --version
mysqldump  Ver 10.13 Distrib 5.1.66, for debian-linux-gnu (x86_64)
$ mysqldump --opt --quick mysql > /dev/null
Error: Couldn't read status information for table general_log ()
mysqldump: Couldn't execute 'show create table `general_log`': Table
'mysql.general_log' doesn't exist (1146)
$


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

Bug#697571: openbox hangs when removing display from dual-head configuration with xrandr

[Sebastian Reichel]

Package: openbox
Version: 3.5.0-6
Severity: important

Hi,

openbox hangs with 100% CPU usage, when removing a display from a dual
head configuration. This only happens when removing the second display
while some windows are still displayed on it. If all windows are
positioned on the first display openbox does not hang after removing
the second display.

The bug can be reproduced using the following steps:

 $ xrandr --output HDMI2 --right-of LVDS1 --auto
 # start some X program and move it's window to the new display
 $ xrandr --output HDMI2 --off

-- Sebastian

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armhf

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

Versions of packages openbox depends on:
ii  dpkg  1.16.9
ii  libc6 2.13-37
ii  libglib2.0-0  2.33.12+really2.32.4-3
ii  libice6   2:1.0.8-2
ii  libobrender27 3.5.0-6
ii  libobt0   3.5.0-6
ii  libsm62:1.2.1-2
ii  libstartup-notification0  0.12-1
ii  libx11-6  2:1.5.0-1
ii  libxau6   1:1.0.7-1
ii  libxext6  2:1.3.1-2
ii  libxinerama1  2:1.1.2-1
ii  libxml2   2.8.0+dfsg1-7
ii  libxrandr22:1.3.2-2
ii  libxrender1   1:0.9.7-1

Versions of packages openbox recommends:
ii  obconf  1:2.0.3+20110805+debian-1
ii  openbox-themes  1.0.2

Versions of packages openbox suggests:
ii  libxml2-dev  2.8.0+dfsg1-7
ii  menu 2.1.46
ii  python   2.7.3~rc2-1
ii  ttf-dejavu   2.33-3

-- 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#697565: lintian: dsc field original-maintainer is unknown to lintian

[Nick Black]

[ I've added Paul Wise as a CC, as he's a very knowledgeable and thoughtful
  liason to the Derivatives community. This seems better than CC'ing the
  entire derivatives list. Paul, any contributions? ]

Russ Allbery left as an exercise for the reader:
> I don't believe there's any history of using this header in Debian, so I
> disagree with this point.  The semantics of the field do not fit the way

Indeed, Debian would be less likely to use a derivative tag than its
derivatives. There's no history for it because the history of large-scale
Debian derivatives is only now being written.

I can assure you that close to 90% of SprezzOS packages use the flag, as
do a great many Ubuntu packages. Furthermore, anyone following the Debian
documentation at

http://wiki.debian.org/Derivatives/Guidelines

is going to use this field. Please see "Packages", second line:

"When modifying source packages, rename the Maintainer field to
 XSBC-Original-Maintainer and add a new Maintainer field."

If we're not going to know about this field in lintian, perhaps it oughtn't
be recommended to all derivatives. The field being useful, however, I hope
it will be retained.

Note that for some SprezzOS packages, we're deriving from Ubuntu or even
unofficial PPAs. These reference the proper source in XSBC-Orig-Maint. The
only packages without such a field are those I've created myself from
scratch.

> that Debian packages are maintained; Debian never systematically imports
> packages from another source, and the package maintainer in Debian is

It never systematically does so because there were never sources to
systematically import APT packages from. I have seen multiple Debian
packages, however, start off with "importing Ubuntu package". While it might
not be systematic, it does occur. Furthermore, when it does not occur, the
field can just be left out.

If you'd like, as I mentioned, I can enlarge the patch so that it only
applies to derivatives, based on dpkg-vendor output (or someone else can,
which I would prefer). It'd be nice for lintian not to warn on behavior
explicitly requested by Debian, though.

> wholly responsible for the contents of the package.  A Debian package may
> be a derivative work of packaging done elsewhere, but that's not the same
> thing as the semantics of the field in Ubuntu (who invented the field and
> which I assume other derivatives are using for inspiration).

I am using for inspiration only the Debian Derivatives Guidelines as
maintained on the Debian wiki. I have no idea how Shuttleworth's crew is
operating (thank you for the details, though! I was unaware).

> There are 10 instances of this header in Debian unstable right now, of
> which eight are by the same maintainer (Chris Grzegorczyk
> ) who appears to be an unusual outlier (and seven of
> those all list the same person as Original-Maintainer).  Of the other two
> instances, one (mffm-fftw) is completely nonsensical (it lists the Debian
> QA Group as the Original-Maintainer).  The last is fatresize, which lists
> Philippe Coval in both Uploaders and Original-Maintainer, which seems a
> little strange.

As I noted in the original bug filing, this is a case we likely want to go
ahead and flag as being incorrect.

Thanks for your detailed response. Having read your thoughts, I would still
appreciate the change being made. I will otherwise likely fork lintian for
SprezzOS, which I would really rather avoid doing.

Have a great day!

-- 
nick black http://www.sprezzatech.com -- unix and hpc consulting
to make an apple pie from scratch, you need first invent a universe.


signature.asc
Description: Digital signature

Bug#696386: makedumpfile fails with elf_readall error : more information

[John Wright]

On Thu, Dec 20, 2012 at 02:39:09PM +0100, Bouchard Louis wrote:
> I have just completed a subsequent test on Ubuntu 13.04 Raring, which
> uses the same version of makedumpfile and libelf1. To my surprize, it
> DOES work correctly on Ubuntu.
> 
> Could this be related the the build of the library ?

Interesting.  That's a possibility, but tracking down the specific
difference in Ubuntu's and Debian's toolchains is going to be tricky.
Does it work in Ubuntu with Debian's kernel, or vice versa?

-- 
John Wright 


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

Bug#696909: chromium segfaults on startup on armhf

[Jonathan Nieder]

Hi Peter,

peter green wrote:

> Patch to make the package use bfd rather than gold on armel and armhf is
> attached. I may or may not upload this as a NMU.

If you'll have time to continue working on chromium:arm in the future,
it would probably be better to just add yourself to pkg-chromium on
alioth.

Thanks for your work,
Jonathan


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

Bug#695182: Write couple of 1GB files for OOM crash

[Jonathan Nieder]

Hi Paul,

Paul Szabo wrote:

> I changed the proposed patch accordingly, scripts/checkpatch.pl produces
> just a few warnings. I had my patch in use for a while now, so I believe
> it is suitably tested.

Thanks much --- this is easier to read.

Here's a quick review from a non-expert (i.e., me).  When the patch
seems ready to you, please send it inline in a message to
linux...@kvack.org, cc-ing linux-ker...@vger.kernel.org and Ben and me
(or this bug log) so we can track it.  The mm folks will probably have
more feedback, and we can take it from there.

> Avoid OOM when filesystem caches fill lowmem and are not reclaimed,
> doing drop_caches at that point. The issue is easily reproducible on
> machines with over 32GB RAM. The patch correctly protects against OOM.
> The added call to drop_caches has been observed to trigger "needlessly"
> but on quite rare occasions only.

Sounds like a reasonable strategy.

> Also included are several minor fixes:

Those should go in separate patches, but if you're just seeking
comments then lumping them with the main change in a patch with
[RFC/PATCH] in the subject line is fine.

[...]
> Signed-off-by: Paul Szabo 

Thanks.

> --- fs/drop_caches.c.old  2012-10-17 13:50:15.0 +1100
> +++ fs/drop_caches.c  2013-01-04 21:52:47.0 +1100
> @@ -65,3 +65,10 @@ int drop_caches_sysctl_handler(ctl_table
>   }
>   return 0;
>  }
> +
> +/* Easy call: do "echo 3 > /proc/sys/vm/drop_caches" */

I don't understand this comment.  What does "Easy call" mean?

> +void easy_drop_caches(void)
> +{
> + iterate_supers(drop_pagecache_sb, NULL);
> + drop_slab();
> +}

This should be declared in some appropriate header (e.g.,
include/linux/mm.h).

> --- mm/page-writeback.c.old   2012-10-17 13:50:15.0 +1100
> +++ mm/page-writeback.c   2013-01-06 21:54:59.0 +1100
> @@ -39,7 +39,8 @@
>  /*
>   * Sleep at most 200ms at a time in balance_dirty_pages().
>   */
> -#define MAX_PAUSEmax(HZ/5, 1)
> +/* Might as well be max(HZ/5,4) to ensure max_pause/4>0 always */
> +#define MAX_PAUSEmax(HZ/5, 4)

This is one of the "while at it"s rather than the main point of
the patch, right?

[...]
> @@ -343,11 +344,26 @@ static unsigned long highmem_dirtyable_m
>  unsigned long determine_dirtyable_memory(void)
>  {
>   unsigned long x;
> + int y = 0;
> + extern int min_free_kbytes;

Probably should be declared in a header like mm/internal.h, but
there's precedent for the ad-hoc declaration, so meh.

[...]
> + /*
> +  * Seems that highmem_is_dirtyable is only used here, in the
> +  * calculation of limits and threshholds of dirtiness, not in deciding
> +  * where to put dirty things. Is that so? Is that as should be?
> +  * What is the recommended setting of highmem_is_dirtyable?
> +  */
>   if (!vm_highmem_is_dirtyable)
>   x -= highmem_dirtyable_memory(x);

I dunno.  See 195cf453d2c3 (mm/page-writeback: highmem_is_dirtyable
option, 2008-02-04) and the thread surrounding
.

> + /* Subtract min_free_kbytes */
> + if (min_free_kbytes > 0)
> + y = min_free_kbytes >> (PAGE_SHIFT - 10);

Why the "if"?

If I were doing it, I think I'd unconditionally set 'y' here, for
clarity and to avoid bugs if some later patch reuses the var for
something else.

y = min_free_kbytes >> (PAGE_SHIFT - 10);
x -= min(x, y);

[...]
> @@ -559,7 +578,7 @@ static unsigned long bdi_position_ratio(
>* => fast response on large errors; small oscillation near setpoint
>*/
>   setpoint = (freerun + limit) / 2;
> - x = div_s64((setpoint - dirty) << RATELIMIT_CALC_SHIFT,
> + x = div_s64(((s64)setpoint - (s64)dirty) << RATELIMIT_CALC_SHIFT,
>   limit - setpoint + 1);

Why are 'setpoint' and 'dirty' of type unsigned long instead of long
in the first place?  What happens if one of their values overflows a
long?

>   pos_ratio = x;
>   pos_ratio = pos_ratio * x >> RATELIMIT_CALC_SHIFT;
> @@ -995,6 +1014,13 @@ static unsigned long bdi_max_pause(struc
>* The pause time will be settled within range (max_pause/4, max_pause).
>* Apply a minimal value of 4 to get a non-zero max_pause/4.
>*/
> + /*
> +  * On large machine it seems we always return 4,
> +  * on smaller desktop machine mostly return 5 (rarely 9 or 14).
> +  * Are those too small? Should we return something fixed e.g.
> + return (HZ/10);
> +  * instead of this wasted/useless calculation?
> +  */
>   return clamp_val(t, 4, MAX_PAUSE);

Another "while at it", I guess.

>  }
>  
> @@ -1109,6 +1135,11 @@ static void balance_dirty_pages(struct a
>   }
>   pause = HZ * pages_dirtied / task_ratelimit;
>   if (unlikely(pause <= 0)) {
> + /*
> +  * Not unlikely: often we get zero.
> +

Bug#697488: debootstrap: wrong default mirror

[Cyril Brulebois]

Michal Suchanek  (06/01/2013):
> I tried to bootstrap a chroot and in the chroot that sources.list is
> pre-filled with the US mirror.
> 
> Since the recommended mirrror is http://http.debian.net the default
> should perhaps reflect this.

Not an official service (yet).

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#697565: lintian: dsc field original-maintainer is unknown to lintian

[Russ Allbery]

Nick Black  writes:

> It seems that, even in the case of Debian, this field might be correctly
> used when e.g. importing packages that originated in SprezzOS, Ubuntu,
> or any other derivative that correctly sets the Maintainer field on new
> packages.  Thus, this field ought be globally allowed.

I don't believe there's any history of using this header in Debian, so I
disagree with this point.  The semantics of the field do not fit the way
that Debian packages are maintained; Debian never systematically imports
packages from another source, and the package maintainer in Debian is
wholly responsible for the contents of the package.  A Debian package may
be a derivative work of packaging done elsewhere, but that's not the same
thing as the semantics of the field in Ubuntu (who invented the field and
which I assume other derivatives are using for inspiration).

There are 10 instances of this header in Debian unstable right now, of
which eight are by the same maintainer (Chris Grzegorczyk
) who appears to be an unusual outlier (and seven of
those all list the same person as Original-Maintainer).  Of the other two
instances, one (mffm-fftw) is completely nonsensical (it lists the Debian
QA Group as the Original-Maintainer).  The last is fatresize, which lists
Philippe Coval in both Uploaders and Original-Maintainer, which seems a
little strange.

-- 
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#696909: chromium segfaults on startup on armhf

[peter green]

I can confim that using bfd instead of gold fixes the issue on armhf.

armel seems to be sufering from the same issue but I have not yet tried 
a build with bfd on armel.


I will do an armel (but on armv7 hardware, I don't have any armv4t or 
armv5 hardware to test on and all my armv6 stuff is running raspbian) 
build and test once I have finished doing the one for raspbian, 
unfortunately each build takes days on my imx53 (I have an odriod u2 on 
order which should speed things up)


Patch to make the package use bfd rather than gold on armel and armhf is 
attached. I may or may not upload this as a NMU.
diff -Nru chromium-browser-22.0.1229.94~r161065+dfsg/debian/changelog 
chromium-browser-22.0.1229.94~r161065+dfsg/debian/changelog
--- chromium-browser-22.0.1229.94~r161065+dfsg/debian/changelog 2012-12-31 
20:02:00.0 +
+++ chromium-browser-22.0.1229.94~r161065+dfsg/debian/changelog 2013-01-05 
12:54:20.0 +
@@ -1,3 +1,10 @@
+chromium-browser (22.0.1229.94~r161065+dfsg-0.2) unstable; urgency=low
+
+  * Change build-depends/build-conflicts to avoid gold linker on arm* as it 
+seems to be causing segfaults (Closes: 696909)
+
+ -- Peter Michael Green   Sat, 05 Jan 2013 12:52:12 +
+
 chromium-browser (22.0.1229.94~r161065+dfsg-0.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru chromium-browser-22.0.1229.94~r161065+dfsg/debian/control 
chromium-browser-22.0.1229.94~r161065+dfsg/debian/control
--- chromium-browser-22.0.1229.94~r161065+dfsg/debian/control   2012-10-17 
23:19:01.0 +
+++ chromium-browser-22.0.1229.94~r161065+dfsg/debian/control   2013-01-05 
12:56:07.0 +
@@ -63,7 +63,7 @@
libxt-dev,
libxtst-dev,
libpam0g-dev,
-   binutils-gold,
+   binutils-gold [!armel !armhf],
libflac-dev,
libwebp-dev,
autotools-dev,
@@ -80,6 +80,8 @@
subversion,
libudev-dev,
libssl-dev
+Build-Conflicts: 
+   binutils-gold [armel armhf]
 Standards-Version: 3.9.2
 
 Package: chromium-browser

Bug#697570: mention use Math::Trig qw(rad2deg);

[jidanni]

Package: perl-doc
Version: 5.14.2-16
Severity: wishlist
File: /usr/share/man/man3/Math::Trig.3perl.gz

Found one needed not only
use Math::Trig qw(deg2rad);
as in the examples, but also
use Math::Trig qw(rad2deg);
which is missing, in order to make the examples really work.

P.S., a cooler way to write the examples would be with shift:
sub NESW   { deg2rad( shift ), deg2rad( 90 - shift ) }
sub unNESW { rad2deg( shift ), 90 - rad2deg( shift ) }

Which I suppose are correct.
In fact they would be better than what is mentioned in my other
messages today...


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

Bug#697569: add details to show how one arrives at "69 N 89 E, in the frozen wastes of Siberia."

[jidanni]

Package: perl-doc
Version: 5.14.2-16
Severity: wishlist
File: /usr/share/man/man3/Math::Trig.3perl.gz

To avoid a "leap of logic" at

my @M = great_circle_midpoint(@L, @T);

#   or about 69 N 89 E, in the frozen wastes of Siberia.

please add something like:

sub unNESW { rad2deg($_[0]), 90 - rad2deg($_[1]) }

print "$_\n" for unNESW @M;


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

Bug#697568: SEE ALSO header missing?

[jidanni]

Package: perl-doc
Version: 5.14.2-16
Severity: wishlist
File: /usr/share/man/man3/Math::Trig.3perl.gz

We see
   computations even when the arguments are not. This, however, cannot be
   completely avoided if we want things like asin(2) to give an answer
   instead of giving a fatal runtime error.

   Do not attempt navigation using these formulas.
(*isn't "SEE ALSO" missing here?*)
   Math::Complex

AUTHORS


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

Bug#697566: great_circle_waypoint $way need not be 0..1; add example

[jidanni]

Package: perl-doc
Version: 5.14.2-16
Severity: wishlist
File: /usr/share/man/man3/Math::Trig.3perl.gz

Regarding
   great_circle_waypoint
 use Math::Trig 'great_circle_waypoint';

 ($thetai, $phii) =
   great_circle_waypoint($theta0, $phi0, $theta1, $phi1, $way);

   Where the $way is a value from zero ($theta0, $phi0) to one ($theta1,
   $phi1).  Note that antipodal points (where their distance is pi
   radians) do not have waypoints between them (they would have an an
   "equator" between them), and therefore "undef" is returned for
   antipodal points.  If the points are the same and the distance
   therefore zero and all waypoints therefore identical, the first point
   (either point) is returned.


Please note this should be modified to mention
1) have no waypoints: you mean instead of being able to return one
waypoint, there is instead an infinite number of waypoints that could be
returned.
2) zero to one: However one can use any number positive or negative.
(And the man page doesn't even have an example for
great_circle_waypoint, so perhaps use:)

"Let's go from London to Tokyo, and not stop there but instead continue
on to see where double the distance will take us:"

sub unNESW { rad2deg( $_[0] ), 90 - rad2deg( $_[1] ) }
print "$_\n" for unNESW great_circle_waypoint @L, @T, 2;

174 E 45 S near New Zealand.


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

Bug#697567: reveal exactly what special case great_circle_midpoint is

[jidanni]

Package: perl-doc
Version: 5.14.2-16
Severity: wishlist
File: /usr/share/man/man3/Math::Trig.3perl.gz

Say instead of
   The great_circle_midpoint() is just a special case of

   The great_circle_midpoint() is just a special case ($way=0.5) of

Thanks.


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

Bug#697565: lintian: dsc field original-maintainer is unknown to lintian

[Nick Black]

Package: lintian
Version: 2.5.10.3
Severity: normal
Tags: patch

Dear Maintainer,

The lintian tool doesn't appear to be aware of XSBC-Original-Maintainer, the
source field recommended in the Debian Derivatives Best Practices document. As
a result, it flags all of our (SprezzOS's) packages with a warning.

It seems that, even in the case of Debian, this field might be correctly used
when e.g. importing packages that originated in SprezzOS, Ubuntu, or any other
derivative that correctly sets the Maintainer field on new packages. Thus, this
field ought be globally allowed. It might be worthwhile to add a check
verifying that it doesn't show up twice, and/or that the value is not
equivalent to that in the Maintainer field, but I've not done that.

This patch, taken against lintian 2.5.11 from experimental, appears to resolve
the issue. Please apply. Thanks!

[skynet](0) $ cat xsbc-original-maintainer.diff
diff -ur lintian-2.5.11/data/common/source-fields
/media/build/world/lintian-2.5.11/data/common/source-fields
--- lintian-2.5.11/data/common/source-fields2012-12-11 15:09:58.0
-0500
+++ /media/build/world/lintian-2.5.11/data/common/source-fields 2013-01-06
19:25:11.170590237 -0500
@@ -18,6 +18,7 @@
 homepage
 maintainer
 origin
+original-maintainer
 package-list
 python-version
 ruby-versions
[skynet](0) $



-- System Information:
Debian Release: 1 (von Neumann)
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.7.1 (SMP w/8 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 lintian depends on:
ii  binutils   2.23.1-SprezzOS1
ii  bzip2  1.0.6-SprezzOS1
ii  diffstat   1.55-3
ii  file   5.11-SprezzOS1
ii  gettext0.18.2-SprezzOS1
ii  hardening-includes 2.3
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.26+b1
ii  libarchive-zip-perl1.30-6
ii  libc-bin   2.16-SprezzOS1
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.31-1+b2
ii  libdpkg-perl   1.16.9-SprezzOS1
ii  libemail-valid-perl0.190-1
ii  libipc-run-perl0.92-1
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.60-1
ii  locales2.16-SprezzOS1
ii  locales-all [locales]  2.16-SprezzOS1
ii  man-db 2.6.3-3
ii  patchutils 0.3.2-1.1
ii  perl [libdigest-sha-perl]  5.14.2-16

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.23.1-SprezzOS1
ii  dpkg-dev   1.16.9-SprezzOS1
ii  libhtml-parser-perl3.69-2
pn  libperlio-gzip-perl
ii  libtext-template-perl  1.45-2
ii  man-db 2.6.3-3
ii  xz-utils [lzma]5.1.1alpha+20120614-2

-- no debconf information
diff -ur lintian-2.5.11/data/common/source-fields /media/build/world/lintian-2.5.11/data/common/source-fields
--- lintian-2.5.11/data/common/source-fields	2012-12-11 15:09:58.0 -0500
+++ /media/build/world/lintian-2.5.11/data/common/source-fields	2013-01-06 19:25:11.170590237 -0500
@@ -18,6 +18,7 @@
 homepage
 maintainer
 origin
+original-maintainer
 package-list
 python-version
 ruby-versions

Bug#507901: Also can't rip here

[Filipus Klutiero]

A problem with ripping was already reported in 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507901 however that was 
with an unofficial transcode. The report is probaly not valid [anymore].


I also can't rip DVDs but the failure is different. transcode's output 
clearly shows something going wrong. I reported my issue against 
transcode in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697558



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

Bug#697490: cloud: 697490: use sudoers.d

[Chris Fordham]

On Mon, 07 Jan 2013 11:17:57 +1100, Anders Ingemann   
wrote:


On 6 January 2013 22:55, Chris Fordham   
wrote:
This is a good example of why template-based configuration is better  
used

rather than regex/stream based editing.


well. d'uh! :-P
I did not know about sudoers.d when I wrote it, otherwise I can assure
you that we wouldn't be talking about this to begin with ;-)
Can still configure /etc/sudoers by template as there may be other  
directives and comments not relevant for sudoers.d, e.g.  
https://github.com/opscode-cookbooks/sudo/blob/master/templates/default/sudoers.erb  
:)


--

Chris Fordham

Backline Support Engineer
RightScale Technical Services


Direct: +1 805 243 0252

Cell: +61 423 003 417

Skype: chris.fordham.rs

Email: chris.ford...@rightscale.com


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

Bug#697490: cloud: 697490: use sudoers.d

[Anders Ingemann]

On 6 January 2013 22:55, Chris Fordham  wrote:
> This is a good example of why template-based configuration is better used
> rather than regex/stream based editing.

well. d'uh! :-P
I did not know about sudoers.d when I wrote it, otherwise I can assure
you that we wouldn't be talking about this to begin with ;-)


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

Bug#697490: Passwordless sudo without modifying /etc/sudoers ?

[Bob Proulx]

Guido Trotter wrote:
> Note that debian's default sudo (at least in wheezy, I haven't checked
> squeeze now) includes files /etc/suders.d/
> So dropping a file with the additional line you need there is a way to
> add sudo rules without modifying /etc/sudoers.

Yes.  I do exactly that.  But note that order matters.  The last entry
has highest priority.  Therefore name the file such that it will sort
later than any other entry.  I use /etc/sudoers.d/zz-local-sudoers
with a "zz" prefix.

Bob


signature.asc
Description: Digital signature

Bug#697564: nautilus-python: FTBFS with python multiarch headers

[Micah Gersten]

Package: nautilus-python
Version: 1.1-3
Severity: normal
Tags: patch
User: debian-pyt...@lists.debian.org
Usertags: origin-ubuntu raring ubuntu-patch multiarch

*** /tmp/tmp1Ob06B/bug_body

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

  * Fix FTBFS with python multiarch headers; Add dh-autoreconf to control;
Add autoreconf to rules
- update debian/control
- update debian/rules
- add debian/patches/02_python_multiarch_path.patch
- update debian/patches/series


Thanks for considering the patch.


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

Kernel: Linux 3.2.0-35-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru nautilus-python-1.1/debian/changelog nautilus-python-1.1/debian/changelog
diff -Nru nautilus-python-1.1/debian/control nautilus-python-1.1/debian/control
--- nautilus-python-1.1/debian/control.in	2011-12-14 17:52:05.0 -0600
+++ nautilus-python-1.1/debian/control.in	2013-01-06 18:05:37.0 -0600
@@ -4,14 +4,15 @@
 Maintainer: Debian GNOME Maintainers 
 Uploaders: @GNOME_TEAM@
 Build-Depends: debhelper (>= 8),
+   dh-autoreconf,
cdbs,
gnome-pkg-tools,
python-dev,
python-gi-dev,
libnautilus-extension-dev (>= 3.0)
 Standards-Version: 3.9.2
 Vcs-Svn: svn://anonscm.debian.org/svn/pkg-gnome/packages/unstable/nautilus-python
 Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-gnome/packages/unstable/nautilus-python/
 
 Package: python-nautilus
 Architecture: any
diff -Nru nautilus-python-1.1/debian/patches/02_python_multiarch_path.patch nautilus-python-1.1/debian/patches/02_python_multiarch_path.patch
--- nautilus-python-1.1/debian/patches/02_python_multiarch_path.patch	1969-12-31 18:00:00.0 -0600
+++ nautilus-python-1.1/debian/patches/02_python_multiarch_path.patch	2013-01-06 17:55:00.0 -0600
@@ -0,0 +1,15 @@
+Description: Include Python multiarch headers
+ Use python-config to find the python include dirs
+Author: Micah Gersten 
+
+--- nautilus-python-1.1.orig/m4/python.m4
 nautilus-python-1.1/m4/python.m4
+@@ -45,7 +45,7 @@ AC_MSG_CHECKING(for headers required to
+ dnl deduce PYTHON_INCLUDES
+ py_prefix=`$PYTHON -c "import sys; print(sys.prefix)"`
+ py_exec_prefix=`$PYTHON -c "import sys; print(sys.exec_prefix)"`
+-PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}"
++PYTHON_INCLUDES=`python-config --includes`
+ if test "$py_prefix" != "$py_exec_prefix"; then
+   PYTHON_INCLUDES="$PYTHON_INCLUDES -I${py_exec_prefix}/include/python${PYTHON_VERSION}"
+ fi
diff -Nru nautilus-python-1.1/debian/patches/series nautilus-python-1.1/debian/patches/series
--- nautilus-python-1.1/debian/patches/series	2011-12-14 17:46:10.0 -0600
+++ nautilus-python-1.1/debian/patches/series	2013-01-06 17:55:33.0 -0600
@@ -1,2 +1,3 @@
 00git_open_terminal_example_GI.patch
 01_port_examples_to_GI.patch
+02_python_multiarch_path.patch
diff -Nru nautilus-python-1.1/debian/rules nautilus-python-1.1/debian/rules
--- nautilus-python-1.1/debian/rules	2011-12-14 17:46:10.0 -0600
+++ nautilus-python-1.1/debian/rules	2013-01-06 17:57:56.0 -0600
@@ -5,6 +5,7 @@
 include /usr/share/cdbs/1/class/gnome.mk
 include /usr/share/gnome-pkg-tools/1/rules/uploaders.mk
 -include /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk
+include /usr/share/cdbs/1/rules/autoreconf.mk
 
 DEB_INSTALL_EXAMPLES_python-nautilus := $(wildcard examples/*.py) examples/README
 DEB_DH_MAKESHLIBS_ARGS_python-nautilus += --no-act

Bug#689150: Upgrade xul-ext-firebug to version 1.11.0

[Christoph Anton Mitterer]

As of firebug 1.10, firecookie is part of it[0].

So in addition, a new version of this package must replace
xul-ext-firecookie and the later can be removed then from the Debian
repos.

Cheers,
Chris.


[0] https://addons.mozilla.org/en-US/firefox/addon/firecookie/


smime.p7s
Description: S/MIME cryptographic signature

Bug#679326: debian-policy: DMUA should covered more explicitly

[Charles Plessy]

Le Mon, Nov 26, 2012 at 09:30:43PM +0100, Guillem Jover a écrit :
> > +
> > +   
> > + The following fields have been obsoleted and may be found in packages
> > +  conforming with previous versions of the Policy.
> 
> (Formatting nitpick, these two lines are not aligned.)

Corrected

> > +   
> > +
> > +   
> > + DM-Upload-Allowed
> > +
> > + 
> > +   Indicates that Debian Maintainers may upload this package to
> > +   the Debian archive.  The only valid value is yes.  This
> 
> Maybe these sentences should be switched to past tense?

I was not sure so I did not change the text.

I have pushed the branch bug679326-plessy and will merge it unless somebody
finds corrections to apply.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Bug#697563: pu: package swi-prolog/5.10.1-1+b1

[Євгеній Мещеряков]

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

The version of swi-prolog in squeeze has two unfixed minor security
vulnerabilities, buffer overflows CVE-2012-6089 and CVE-2012-6090,
bug #697416. The security team decided that there will be no DSA for
those issues. It was proposed to fix those issues via stable updates.

The proposed debdiff is attached. The new version adds two patches
taken from RedHat bugzilla (one refreshed) and changes the Maintainer
field in debian/control.

Regards,
Eugeniy Meshcheryakov

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

Kernel: Linux 3.7-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru swi-prolog-5.10.1/debian/changelog swi-prolog-5.10.1/debian/changelog
--- swi-prolog-5.10.1/debian/changelog	2010-08-02 07:01:49.0 +0200
+++ swi-prolog-5.10.1/debian/changelog	2013-01-07 00:07:27.0 +0100
@@ -1,3 +1,14 @@
+swi-prolog (5.10.1-2) stable; urgency=low
+
+  * Update Maintainer field in debian/control 
+  * New patches (taken from RedHat bugzilla, closes: #697416):
+- CVE-2012-6089.diff - fix for CVE-2012-6089 - possible buffer overrun in
+  path canonisation code 
+- CVE-2012-6090.diff - fix for CVE-2012-6090 - Possible buffer overflows
+  when expanding file-names with long paths 
+
+ -- Євгеній Мещеряков   Mon, 07 Jan 2013 00:02:00 +0100
+
 swi-prolog (5.10.1-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru swi-prolog-5.10.1/debian/control swi-prolog-5.10.1/debian/control
--- swi-prolog-5.10.1/debian/control	2010-08-02 07:01:49.0 +0200
+++ swi-prolog-5.10.1/debian/control	2013-01-07 00:07:27.0 +0100
@@ -1,7 +1,7 @@
 Source: swi-prolog
 Section: interpreters
 Priority: optional
-Maintainer: Chris Lamb 
+Maintainer: Євгеній Мещеряков 
 Build-Depends: debhelper (>= 5), autoconf, autotools-dev, libncurses5-dev, libreadline-dev, libgmp3-dev, libjpeg-dev, libx11-dev, libxpm-dev, libxt-dev, x11proto-core-dev, chrpath, unixodbc-dev, openjdk-6-jdk [alpha amd64 armel i386 ia64 mips mipsel powerpc s390 sparc], libxft-dev, libxext-dev, libice-dev, libxinerama-dev
 Standards-Version: 3.9.1
 Vcs-Git: git://git.chris-lamb.co.uk/debian/pkg-swi-prolog.git
diff -Nru swi-prolog-5.10.1/debian/patches/CVE-2012-6089.diff swi-prolog-5.10.1/debian/patches/CVE-2012-6089.diff
--- swi-prolog-5.10.1/debian/patches/CVE-2012-6089.diff	1970-01-01 01:00:00.0 +0100
+++ swi-prolog-5.10.1/debian/patches/CVE-2012-6089.diff	2013-01-07 00:07:27.0 +0100
@@ -0,0 +1,90 @@
+From 6149f39ada50f7ebc6b0cb7756490a0fea967bd1 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
+Date: Fri, 4 Jan 2013 13:33:11 +0100
+Subject: [PATCH 1/2] Fix CVE-2012-6089
+
+Upstream fix ported to 5.10.2:
+
+From a9a6fc8a2a9cf3b9154b490a4b1ffaa8be4d723c Mon Sep 17 00:00:00 2001
+From: Jan Wielemaker 
+Date: Sun, 16 Dec 2012 18:13:17 +0100
+Subject: [PATCH] FIXED: Possible buffer overrun in patch canonisation code.
+
+Pushes pointers on an automatic array without checking for overflow.
+Can be used for DoS attacks.  Will be extremely hard to make it execute
+arbitrary code.
+---
+ src/pl-buffer.h |  2 ++
+ src/pl-os.c | 19 +++
+ 2 files changed, 13 insertions(+), 8 deletions(-)
+
+--- a/src/pl-buffer.h
 b/src/pl-buffer.h
+@@ -79,6 +79,8 @@
+   sizeof((b)->static_buffer))
+ #define emptyBuffer(b)   ((b)->top  = (b)->base)
+ #define isEmptyBuffer(b) ((b)->top == (b)->base)
++#define popBuffer(b,type) \
++	((b)->top -= sizeof(type), *(type*)(b)->top)
+ 
+ #define discardBuffer(b) \
+ 	do \
+--- a/src/pl-os.c
 b/src/pl-os.c
+@@ -1078,8 +1078,7 @@
+ char *
+ canoniseFileName(char *path)
+ { char *out = path, *in = path, *start = path;
+-  char *osave[100];
+-  int  osavep = 0;
++  tmp_buffer saveb;
+ 
+ #ifdef O_HASDRIVES			/* C: */
+   if ( in[1] == ':' && isLetter(in[0]) )
+@@ -1107,7 +1106,8 @@
+ in += 2;
+   if ( in[0] == '/' )
+ *out++ = '/';
+-  osave[osavep++] = out;
++  initBuffer(&saveb);
++  addBuffer(&saveb, out, char*);
+ 
+   while(*in)
+   { if (*in == '/')
+@@ -1123,15 +1123,15 @@
+ 	  }
+ 	  if ( in[2] == EOS )		/* delete trailing /. */
+ 	  { *out = EOS;
+-	return path;
++	goto out;
+ 	  }
+ 	  if ( in[2] == '.' && (in[3] == '/' || in[3] == EOS) )
+-	  { if ( osavep > 0 )		/* delete /foo/../ */
+-	{ out = osave[--osavep];
++	  { if ( !isEmptyBuffer(&saveb) )		/* delete /foo/../ */
++	{ out = popBuffer(&saveb, char*);
+ 	  in += 3;
+ 	  if ( in[0] == EOS && out > start+1 )
+ 	  { out[-1] = EOS;		/* delete trailing / */
+-		return path;
++		goto out;
+ 	  }
+ 	  goto again;
+ 	} else if (	start[0] == '/' && out == start+1 )
+@@ -1145,12 +1145,15 @@
+ 	in++;
+   if ( ou

Bug#697562: tpu: python-keyring/0.7.1-1+deb7u1

[Sebastian Ramacher]

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

Hi release team,

please consider the attached debdiff for an upload to
testing-proposed-updated. It fixes CVE-2012-4571 (#675379) and
CVE-2012-5578 (#696736).

To fix CVE-2012-4571 I've backported CryptedFileKeyring from 0.9.3-1.
The fix for CVE-2012-5578 is the same as applied in 0.9.2-1.1.

Regards
-- 
Sebastian Ramacher
diff -Nru python-keyring-0.7.1/debian/changelog python-keyring-0.7.1/debian/changelog
--- python-keyring-0.7.1/debian/changelog	2012-02-14 20:22:10.0 +0100
+++ python-keyring-0.7.1/debian/changelog	2013-01-06 21:56:14.0 +0100
@@ -1,3 +1,16 @@
+python-keyring (0.7.1-1+deb7u1) testing-proposed-updates; urgency=low
+
+  * Team upload.
+  * debian/patches:
+- CVE-2012-4571.patch: backport CryptedFileKeyring from 0.9.3 to fix
+  CVE-2012-4571. (Closes: #675379)
+- 696736-Fix-insecure-permissions-on-database-files.patch: backport fix
+  from 0.9.2-1.1 to fix insecure permissions on database files. Fix
+  CVE-2012-5577 and CVE-2012-5578. Thanks Salvatore Bonaccorso. (Closes:
+  #696736)
+
+ -- Sebastian Ramacher   Sun, 06 Jan 2013 21:55:50 +0100
+
 python-keyring (0.7.1-1) unstable; urgency=low
 
   * New upstream version (Closes: #656680, #624690)
diff -Nru python-keyring-0.7.1/debian/patches/696736-Fix-insecure-permissions-on-database-files.patch python-keyring-0.7.1/debian/patches/696736-Fix-insecure-permissions-on-database-files.patch
--- python-keyring-0.7.1/debian/patches/696736-Fix-insecure-permissions-on-database-files.patch	1970-01-01 01:00:00.0 +0100
+++ python-keyring-0.7.1/debian/patches/696736-Fix-insecure-permissions-on-database-files.patch	2013-01-02 17:41:19.0 +0100
@@ -0,0 +1,56 @@
+Description: set appropriate file permissions on database file.
+Bug: https://bitbucket.org/kang/python-keyring-lib/issue/67/set-go-rwx-on-keyring_passcfg
+Bug: https://bitbucket.org/kang/python-keyring-lib/issue/76/insecure-database-file-permissions
+Bug-Debian: http://bugs.debian.org/696736
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/python-keyring/+bug/1031465
+Forwarded: yes
+Author: Marc Deslauriers 
+Reviewed-by: Salvatore Bonaccorso 
+Last-Update: 2013-01-02
+
+--- a/keyring/backend.py
 b/keyring/backend.py
+@@ -6,6 +6,7 @@
+ 
+ import getpass
+ import os
++import stat
+ import sys
+ import ConfigParser
+ import base64
+@@ -342,6 +343,7 @@
+ storage_root = os.path.dirname(self.file_path)
+ if storage_root and not os.path.isdir(storage_root):
+ os.makedirs(storage_root)
++os.chmod(storage_root, stat.S_IWRITE | stat.S_IREAD | stat.S_IEXEC)
+ 
+ 
+ class UncryptedFileKeyring(BasicFileKeyring):
+--- a/keyring/util/loc_compat.py
 b/keyring/util/loc_compat.py
+@@ -1,5 +1,6 @@
+ import os
+ import shutil
++import stat
+ import sys
+ 
+ def relocate_file(old_location, new_location):
+@@ -24,4 +25,6 @@
+ # ensure the storage path exists
+ if not os.path.isdir(os.path.dirname(new_location)):
+ os.makedirs(os.path.dirname(new_location))
++os.chmod(os.path.dirname(new_location),
++stat.S_IWRITE | stat.S_IREAD | stat.S_IEXEC)
+ shutil.move(old_location, new_location)
+--- a/keyring/tests/test_backend.py
 b/keyring/tests/test_backend.py
+@@ -336,7 +336,8 @@
+ def setUp(self):
+ super(FileKeyringTests, self).setUp()
+ self.keyring = self.init_keyring()
+-self.keyring.file_path = self.tmp_keyring_file = tempfile.mktemp()
++self.keyring.file_path = self.tmp_keyring_file = os.path.join(
++tempfile.mkdtemp(), "test_pass.cfg")
+ 
+ def tearDown(self):
+ try:
diff -Nru python-keyring-0.7.1/debian/patches/CVE-2012-4571.patch python-keyring-0.7.1/debian/patches/CVE-2012-4571.patch
--- python-keyring-0.7.1/debian/patches/CVE-2012-4571.patch	1970-01-01 01:00:00.0 +0100
+++ python-keyring-0.7.1/debian/patches/CVE-2012-4571.patch	2013-01-06 20:26:46.0 +0100
@@ -0,0 +1,508 @@
+Description: backport CryptedFileKeyring from 0.9.3
+ Use a random IV to initialize AES cipher. Also use PBKDF2 to derive the AES key
+ from the user provided password.
+Origin: backport,
+ https://bitbucket.org/kang/python-keyring-lib/commits/576e21a,
+ https://bitbucket.org/kang/python-keyring-lib/commits/46e94a7,
+ https://bitbucket.org/kang/python-keyring-lib/commits/2e66ff2,
+ https://bitbucket.org/kang/python-keyring-lib/commits/6481eb6,
+ https://bitbucket.org/kang/python-keyring-lib/commits/168830d,
+ https://bitbucket.org/kang/python-keyring-lib/commits/1cf1b06,
+ https://bitbucket.org/kang/python-keyring-lib/commits/8751161,
+ https://bitbucket.org/kang/python-keyring-lib/commits/cd5cdda,
+ https://bitbucket.org/kang/python-keyring-lib/commits/2e97206,
+ https://bitbucket.org/kang/python-keyring-lib/commits/7b324f0,
+ https://bitbucket.org/kang/python-keyring-lib/commits/8881c7d,
+ https://bitbucket.org/kang/python

Bug#683584: security update ready for squeeze (3.1.8)

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 05/01/13 16:21, Salvatore Bonaccorso wrote:
> Hi Daniel
> 
> On Wed, Aug 15, 2012 at 05:49:00PM +, Daniel Pocock wrote:
>> Upstream have released 3.1.8 which only differs from 3.1.7 by
>> adding the fix for the security issue
>> 
>> It has now been pushed to the git.debian.org VCS for building
>> the Ganglia package
>> 
>> It is on the squeeze branch and ready for someone to build and
>> upload a binary package
> 
> I was looking at current open RC bugs and stumbled over #683584
> for Squeeze. If I'm reading correctly, this is both high severity
> but still open in Squeeze. I haven't looked a the details; is there
> an update planned for ganglia in Squeeze?
> 

Yes, the 3.1.8 security fix from upstream has been packaged and has
been waiting for security team to process through to the archive
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJQ6gpEAAoJEOm1uwJp1aqD8f4P/3qeSRMj9t2KDxCxODgeOs7F
rZywn4uqA1PBtfoNXMEI/6lvd4BSfhisfnYL0+vIEl2zctzqpWv6dB64uGpDhI2g
C68CVJ3by+/kcLTagi7//p3xbyowP0EYWMHSoUJt6srT7s5rH7IZMI1O/J8t/4Gg
Vs8PYcjUCPzWVfHYWwnWoRo2cY909YhhQ3gc0knbPg3wDBJgKqmIFnf3D8gr3V4A
V2rx2mgiF83nF81iHnuMuivWJ0vhHDU+Zov26HdEP8z9/ExztPdUqZQiTeW8k9Ni
IylErKFhqTSCfQm70Sk0paIbidiCbS4W9J+gz0ImPR0vjF/Cot9xuqmjD0iQ+8lB
eHf5ITQkc1JkC9XZbqp8pKzizjLsFWXy8ADszLAPutnEd+HqenmOVMAKf8k+l4Ac
Fk5MtOcQZwG+UWk4TLwCi/MtHBZmXt9YJA31xx9lZ5/q9M3vcsi9r0otnzSWaQyI
XFetfKW61EWUWaY7MlxhmbBOTP3kqK+yPpYSncdU07UbOlMLSnyPwoj5At2sKaFc
9DEGt3BQDCPRVD4LuedQD+wY0RTaPWFzpJ4Qwy+tz/IBiQDYBDnrGSk2qViqaQ4q
nS45jZ21s2uFny0ZKAbjWtffiKNL4boCs2pK07o4LWiWs4fpFaUMx1c44BJbPsde
EcaWfYkLWNWnmmGUfWN8
=shmf
-END PGP SIGNATURE-


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

Bug#697560: openvpn: versioned build-depends on dpkg-dev (>= 1.16.1) for dpkg-buildflags --export=configure

[Vagrant Cascadian]

Package: openvpn
Version: 2.2.1-8
Severity: normal
Tags: patch

While attempting to backport openvpn to squeeze, openvpn failed to build
because debian/rules uses "dpkg-buildpackage --export=configure", which was not
introduced until dpkg-dev 1.16.1.

Patch below.

live well,
  vagrant

--- control.orig2013-01-06 14:57:04.006081847 -0800
+++ control 2013-01-06 14:57:30.538213402 -0800
@@ -2,7 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: Alberto Gonzalez Iniesta 
-Build-Depends: debhelper (>= 7.0.50~), libssl-dev (>> 0.9.8g-9), liblzo2-dev, 
libpam0g-dev, libpkcs11-helper1-dev
+Build-Depends: debhelper (>= 7.0.50~), libssl-dev (>> 0.9.8g-9), liblzo2-dev, 
libpam0g-dev, libpkcs11-helper1-dev, dpkg-dev (>= 1.16.1)
 Standards-Version: 3.9.2
 Homepage: http://www.openvpn.net/


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

Bug#695182: linux-image-3.2.0-4-686-pae: Write couple of 1GB files for OOM crash

[Paul Szabo]

Dear Ben,

> Please read Documentation/SubmittingPatches, use scripts/checkpatch.pl
> and try to provide a patch that is suitable for upstream inclusion.
> Also, your name belongs in the patch header, not in the code.

I changed the proposed patch accordingly, scripts/checkpatch.pl produces
just a few warnings. I had my patch in use for a while now, so I believe
it is suitably tested.

Please let me know if I need to do anything else.

Cheers, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia
Avoid OOM when filesystem caches fill lowmem and are not reclaimed,
doing drop_caches at that point. The issue is easily reproducible on
machines with over 32GB RAM. The patch correctly protects against OOM.
The added call to drop_caches has been observed to trigger "needlessly"
but on quite rare occasions only.

Also included are several minor fixes:
 - Comment about highmem_is_dirtyable that seems used only to calculate
   limits and threshholds, not used in any decisions.
 - In determine_dirtyable_memory() subtract min_free_kbytes from
   returned value. I believe this is "right", that min_free_kbytes is
   not intended for dirty pages.
 - In bdi_position_ratio() get difference (setpoint-dirty) right even
   when it is negative, which happens often. Normally these numbers are
   "small" and even with left-shift I never observed a 32-bit overflow.
   I believe it should be possible to re-write the whole function in
   32-bit ints; maybe it is not worth the effort to make it "efficient";
   seeing how this function was always wrong and we survived, it should
   simply be removed.
 - Comment in bdi_max_pause() that it seems to always return a too-small
   value, maybe it should simply return a fixed value.
 - Comment in balance_dirty_pages() about a test marked unlikely() but
   which I observe to be quite common.
 - Comment in __alloc_pages_slowpath() about did_some_progress being
   set twice, but only checked after the second setting, so the first
   setting is lost and wasted.
 - Comment in zone_reclaimable() that maybe should return true with
   non-zero NR_SLAB_RECLAIMABLE.
 - Comment about all_unreclaimable which may be set wrongly.
 - Comments in global_reclaimable_pages() and zone_reclaimable_pages()
   about maybe adding or including NR_SLAB_RECLAIMABLE.

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Reported-by: Paul Szabo 
Reference: http://bugs.debian.org/695182
Signed-off-by: Paul Szabo 

--- fs/drop_caches.c.old	2012-10-17 13:50:15.0 +1100
+++ fs/drop_caches.c	2013-01-04 21:52:47.0 +1100
@@ -65,3 +65,10 @@ int drop_caches_sysctl_handler(ctl_table
 	}
 	return 0;
 }
+
+/* Easy call: do "echo 3 > /proc/sys/vm/drop_caches" */
+void easy_drop_caches(void)
+{
+	iterate_supers(drop_pagecache_sb, NULL);
+	drop_slab();
+}
--- mm/page-writeback.c.old	2012-10-17 13:50:15.0 +1100
+++ mm/page-writeback.c	2013-01-06 21:54:59.0 +1100
@@ -39,7 +39,8 @@
 /*
  * Sleep at most 200ms at a time in balance_dirty_pages().
  */
-#define MAX_PAUSE		max(HZ/5, 1)
+/* Might as well be max(HZ/5,4) to ensure max_pause/4>0 always */
+#define MAX_PAUSE		max(HZ/5, 4)
 
 /*
  * Estimate write bandwidth at 200ms intervals.
@@ -343,11 +344,26 @@ static unsigned long highmem_dirtyable_m
 unsigned long determine_dirtyable_memory(void)
 {
 	unsigned long x;
+	int y = 0;
+	extern int min_free_kbytes;
 
 	x = global_page_state(NR_FREE_PAGES) + global_reclaimable_pages();
 
+	/*
+	 * Seems that highmem_is_dirtyable is only used here, in the
+	 * calculation of limits and threshholds of dirtiness, not in deciding
+	 * where to put dirty things. Is that so? Is that as should be?
+	 * What is the recommended setting of highmem_is_dirtyable?
+	 */
 	if (!vm_highmem_is_dirtyable)
 		x -= highmem_dirtyable_memory(x);
+	/* Subtract min_free_kbytes */
+	if (min_free_kbytes > 0)
+		y = min_free_kbytes >> (PAGE_SHIFT - 10);
+	if (x > y)
+		x -= y;
+	else
+		x = 0;
 
 	return x + 1;	/* Ensure that we never return 0 */
 }
@@ -541,6 +557,9 @@ static unsigned long bdi_position_ratio(
 
 	if (unlikely(dirty >= limit))
 		return 0;
+	/* Never seen this happen, just sanity-check paranoia */
+	if (unlikely(freerun >= limit))
+		return 16 << RATELIMIT_CALC_SHIFT;
 
 	/*
 	 * global setpoint
@@ -559,7 +578,7 @@ static unsigned long bdi_position_ratio(
 	 * => fast response on large errors; small oscillation near setpoint
 	 */
 	setpoint = (freerun + limit) / 2;
-	x = div_s64((setpoint - dirty) << RATELIMIT_CALC_SHIFT,
+	x = div_s64(((s64)setpoint - (s64)dirty) << RATELIMIT_CALC_SHIFT,
 		limit - setpoint + 1);
 	pos_ratio = x;
 	pos_ratio = pos_ratio * x >> RATELIMIT_CALC_SHIFT;
@@ -995,6 +1014,13 @@ static unsigned long bdi_max_pause(struc
 	 * The pause time will be settled within range (max_pause/4, max_pause).
 	 * Ap

Bug#697213: python-keyring: CryptedFileKeyring always forces keyring initalization

[Sebastian Ramacher]

Control: severity -1 important
Control: retitle -1 python-keyring: CryptedFileKeyring: incomplete migration, 
broken unlock logic

On 2013-01-03 02:15:09, Sebastian Ramacher wrote:
> While preparing a tpu upload for the CVEs and testing the migration code, I
> came to the conclusion that without this patch is really necessary. Otherwise
> the keyring is created over and over again.
> 
> Furthermore the commit [2] released in 0.9.3 is also required. So if you don't
> mind I'd like to prepare a team upload of 0.9.3 with the patch for this bug 
> for
> unstable (including the changes from the NMU of course). After that I'll
> continue to work in the tpu.

It was too late when I wrote that mail. Here are more details.

Without the commit from [2] an existing keyring is not converted correctly. In
the case of a call to get_password the keyring is moved to the new location but
then one gets the following traceback:

  File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 37, in 
get_password
return _keyring_backend.get_password(service_name, username)
  File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 375, in 
get_password
password = self.decrypt(password_encrypted).decode('utf-8')
  File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 549, in 
decrypt
data = json.loads(password_encrypted)
  File "/usr/lib/python2.7/json/__init__.py", line 326, in loads
return _default_decoder.decode(s)
  File "/usr/lib/python2.7/json/decoder.py", line 365, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python2.7/json/decoder.py", line 383, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded

LP #1042754 contains an example of this case.

As this leaves python-keyring with an existing
pre-0.9.2-CryptedFileKeyring keyring unusable, I'm raising the severity to
important.

Kind regards
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature

Bug#697434: pu: package gzip/1.3.12-9+deb6u0

[Niels Thykier]

On 2013-01-06 23:32, Adam D. Barratt wrote:
> Control: tags -1 + confirmed squeeze
> 
> On Sat, 2013-01-05 at 11:47 +0100, Niels Thykier wrote:
>> I would like to upload a patched version of gzip to fix #627121
>> (grave; use of memcpy with overlapping memory regions).
> 
> +gzip (1.3.12-9+deb6u0) UNRELEASED; urgency=low
> +
> +  * Non-maintainer upload to stable.
> +  * Backport upstream patch to avoid using memcpy on overlapping
> +memory regions.  (Closes: #627121)
> 
> Despite what dev-ref implies, we've still been using +squeeze for
> stable. Other than that, assuming the resulting package has been tested
> on a squeeze system, please go ahead; thanks.
> 
> Regards,
> 
> Adam
> 
> 

Uploaded as gzip_1.3.12-9+squeeze1, been tested in a run of the Lintian
2.4.3+squeeze1 test suite in Squeeze 6.0.6.  :)

~Niels


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

Bug#642314: c_rehash and "trusted certificates" another regression

[Stefan Skoglund]

Regarding the usage of "BEGIN TRUSTED CERT".

This header is created when using the '-trustout' arg to x509(1ssl)

The change as such means breaks for example  :
'openssl verify -CApath /etc/ssl/certs'

if one of the certs in the chain has this header. 

The trust functionality as such is in x509(1ssl) marked as experimental.

But i did got a little peeve when my carefully created root ca cert
didnt appear as i think it should 


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

Bug#624694: Please try unhide.rb

[Yago Jesus]

Hi,

There is a bug in sysinfo, some kernel schedulers are not reliable. You can
try the latest version of Unhide (not yet released)  where this test is
removed

http://sourceforge.net/projects/unhide/files/unhide_20121229.tgz/download


2013/1/6 xiscu 

> The result is:
>
> # unhide.rb -v
> Scanning for hidden processes...
> No hidden processes found!
>
> __**_
> forensics-devel mailing list
> forensics-devel@lists.alioth.**debian.org
> http://lists.alioth.debian.**org/cgi-bin/mailman/listinfo/**
> forensics-devel
>

Bug#694329: pu: package xnecview/1.35-5.2

[Adam D. Barratt]

Control: tags -1 + squeeze pending

On Tue, 2012-11-27 at 21:51 +0100, Evgeni Golov wrote:
> On Sun, Nov 25, 2012 at 07:34:48PM +, Adam D. Barratt wrote:
> > On Sun, 2012-11-25 at 15:41 +0100, Evgeni Golov wrote:
> > > +  * Non-maintainer upload.
> > > +  * Take my own patch from 1.35-7.1.
> > > +  * R0 is already taken as a register name on armel, rename xnecview's
> > > +constant to DEFFAULTR0.
> > > +Closes: #621392
> > 
> > Do we know what changed in the toolchain to cause the breakage? Looking
> > at the upload history, I see the version in squeeze would have been
> > built with lenny's toolchain. :(
> 
> No, I do not. But I know that the breakage is fixed in Wheezy and could 
> grep a bit if you want me to (and that helps).
> But yes, the version in stable (-5.1) was built on Lenny in early 2009.

Flagged for acceptance in to p-u; 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#697558: [transcode] Crashes trying to rip a DVD ("transcode: munmap_chunk(): invalid pointer: ")

[Filipus Klutiero]

Package: transcode
Version: 3:1.1.7-3
Severity: important

transcode seems to crash whenever I try to rip a DVD here. Here is an 
extract from what happens with a DVD that has no bad sectors:




*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
encoding=1 frame=19397 first=0 last=-1 fps=62.277 done=-1.00 
timestamp=809.017 timeleft=-1 decodebuf=7 filterbuf=2 encodebuf=11

*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
*** libdvdread: CHECK_VALUE failed in nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***
encoding=1 frame=19560 first=0 last=-1 fps=62.449 done=-1.00 
timestamp=815.815 timeleft=-1 decodebuf=0 filterbuf=8 encodebuf=12
*** glibc detected *** /usr/bin/transcode: munmap_chunk(): invalid 
pointer: 0xe51e6189 ***

=== Backtrace: =
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x70f01)[0xf72d6f01]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x7217e)[0xf72d817e]
/usr/lib/i386-linux-gnu/i686/cmov/libavutil.so.51(av_freep+0x12)[0xe442eeb2]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xf727ce46]
/usr/bin/transcode[0x8054bed]


That DVD was made in 2004 to store personal videos. I do not know which 
software was used. I also tried with a commercial DVD-ROM (2009) and had 
the same result. I'm attaching a script of my attempt to rip the 
commercial DVD.


Several hits show this problem is not new, and presumably an upstream 
problem:

http://www.mail-archive.com/transcode-users@exit1.org/msg01673.html
http://us.generation-nt.com/answer/problem-k3b-help-208070751.html
https://bugs.archlinux.org/task/26208

I have not tried with other ffmpeg versions.

This seems to make it impossible to rip a DVD using K3b.

--- System information. ---
Architecture: i386
Kernel: Linux 3.2.0-4-amd64

Debian Release: 7.0
990 testing security.debian.org
990 testing debian.mirror.iweb.ca
500 unstable debian.mirror.iweb.ca
1 experimental debian.mirror.iweb.ca

--- Package information. ---
Depends (Version) | Installed
==-+-===
mawk | 1.3.3-17
OR gawk |
xterm | 278-4
OR x-terminal-emulator |
liba52-0.7.4 | 0.7.4-16
libasound2 (>= 1.0.16) | 1.0.25-4
libavcodec53 (>= 6:0.8.3-1~) | 6:0.8.4-1
OR libavcodec-extra-53 (>= 6:0.8.3) |
libavformat53 (>= 6:0.8.3-1~) | 6:0.8.4-1
libc6 (>= 2.12) | 2.13-37
libdv4 | 1.0.0-6
libdvdread4 | 4.2.0+20120521-2
libfreetype6 (>= 2.2.1) | 2.4.9-1.1
libgomp1 (>= 4.2.1) | 4.7.2-4
libice6 (>= 1:1.0.0) | 2:1.0.8-2
libjpeg8 (>= 8c) | 8d-1
liblzo2-2 | 2.06-1
libmagickcore5 (>= 8:6.7.7.10) | 8:6.7.7.10-5
libmagickwand5 (>= 8:6.7.7.10) | 8:6.7.7.10-5
libmp3lame0 | 3.99.5+repack1-3
libmpeg2-4 | 0.4.1-3
libogg0 (>= 1.0rc3) | 1.3.0-4
libpostproc52 (>= 6:0.8.3-1~) | 6:0.8.4-1
libquicktime2 (>= 2:1.2.2) | 2:1.2.4-3
libsdl1.2debian (>= 1.2.11) | 1.2.15-5
libsm6 | 2:1.2.1-2
libtheora0 (>= 0.0.0.alpha7.dfsg) | 1.1.1+dfsg.1-3.1
libvorbis0a (>= 1.1.2) | 1.3.2-1.3
libvorbisfile3 (>= 1.1.2) | 1.3.2-1.3
libx11-6 | 2:1.5.0-1
libxaw7 | 2:1.0.10-2
libxext6 | 2:1.3.1-2
libxml2 (>= 2.7.4) | 2.8.0+dfsg1-7
libxpm4 | 1:3.5.10-1
libxt6 | 1:1.1.3-1
libxv1 | 2:1.0.7-1
zlib1g (>= 1:1.1.4) | 1:1.2.7.dfsg-13


Recommends (Version) | Installed
-+-===
sox | 14.4.0-3
transcode-doc | 3:1.1.7-3
twolame | 0.3.13-1


Suggests (Version) | Installed
=-+-===
mjpegtools | 1:2.0.0+debian-2
xvid4conf |


typescript
Description: Binary data

Bug#675913: fixed in resource-agents 1:3.9.3+git20121009-2

[gregor herrmann]

On Sun, 06 Jan 2013 23:43:01 +0100, Martin Gerhard Loschwitz wrote:

> >> On Tue, 01 Jan 2013 20:39:28 +, Adam D. Barratt wrote:
> >> If the maintainer is busy, I can upload to t-p-u.
> >> Debdiff attached (just the patch from unstable).
> > I've not seen a followup from the maintainer, but from my side that
> > would be appreciated; thanks.
> Go ahead and upload pretty please. Thanks a lot, much appreciated!

Thanks to both of you; uploaded.


I'm attaching the final debdiff in case you want to import it into a
VCS.


Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Rolling Stones: Youwin
diff -Nru resource-agents-3.9.2/debian/changelog resource-agents-3.9.2/debian/changelog
--- resource-agents-3.9.2/debian/changelog	2011-11-15 18:22:49.0 +0100
+++ resource-agents-3.9.2/debian/changelog	2013-01-06 23:49:52.0 +0100
@@ -1,3 +1,16 @@
+resource-agents (1:3.9.2-5+deb7u1) testing-proposed-updates; urgency=low
+
+  * Non-maintainer upload.
+  * Backport patch from unstable (refreshed to fix offset).
+Original changelog entry:
+
+  [ Martin Loschwitz ]
+  * debian/patches/fix-gethostinfo-v2.patch: Applied a patch by Zang 
+MingJie, edited by Ruben Laban, to fix a problem related to IPv6 in
+ldirectord (Closes: #675913)
+
+ -- gregor herrmann   Sun, 06 Jan 2013 23:49:21 +0100
+
 resource-agents (1:3.9.2-5) unstable; urgency=high
 
   * debian/control: Fix the Conflicts and Replaces lines of resource-agents
diff -Nru resource-agents-3.9.2/debian/patches/fix-gethostinfo-v2.patch resource-agents-3.9.2/debian/patches/fix-gethostinfo-v2.patch
--- resource-agents-3.9.2/debian/patches/fix-gethostinfo-v2.patch	1970-01-01 01:00:00.0 +0100
+++ resource-agents-3.9.2/debian/patches/fix-gethostinfo-v2.patch	2013-01-02 04:42:04.0 +0100
@@ -0,0 +1,73 @@
+--- a/ldirectord/ldirectord.in
 b/ldirectord/ldirectord.in
+@@ -827,8 +827,7 @@
+ use Pod::Usage;
+ #use English;
+ #use Time::HiRes qw( gettimeofday tv_interval );
+-use Socket;
+-use Socket6;
++use Socket qw( :DEFAULT inet_pton getaddrinfo getnameinfo NI_NUMERICHOST NI_NUMERICSERV NI_NAMEREQD );
+ use Sys::Hostname;
+ use POSIX qw(setsid :sys_wait_h);
+ use Sys::Syslog qw(:DEFAULT setlogsock);
+@@ -4013,7 +4012,7 @@
+ {
+ 	my ($v, $r, $force) = (@_);
+ 
+-	if ($r->{failcount} > 0) {
++	if (defined($r->{failcount}) && $r->{failcount} > 0) {
+ 		ld_log("Resetting soft failure count: " . $r->{server} . ":" .
+ 		   $r->{port} . " (" . get_virtual_id_str($v) . ")");
+ 	}
+@@ -5039,17 +5038,21 @@
+ 	if ($name =~ /\[(.*)\]/) {
+ 		$name = $1;
+ 	}
+-	my @host = getaddrinfo($name, 0, $af);
+-	if (!defined($host[3])) {
+-		return undef;
+-	}
+-	my @ret = getnameinfo($host[3], NI_NUMERICHOST | NI_NUMERICSERV);
+-	if ($host[0] == AF_INET6) {
+-		return "[$ret[0]]";
+-	}
+-	else {
+-		return $ret[0];
++	my %hints = ( family => $af );
++	my ( $err, @res ) = getaddrinfo($name, 0, \%hints);
++	return undef if ($err);
++	while( my $ai = shift @res ) {
++		my ( $err, $hostname, $servicename ) = getnameinfo( $ai->{addr}, NI_NUMERICHOST );
++		if (!$err) {
++			if ($ai->{family} == AF_INET6) {
++return "[$hostname]";
++			}
++			else {
++return $hostname;
++			}
++		}
+ 	}
++	return undef;
+ }
+ 
+ # ld_gethostbyaddr
+@@ -5064,13 +5067,13 @@
+ 	my ($ip)=(@_);
+ 
+ 	$ip = &ld_strip_brackets($ip);
+-	my @host = getaddrinfo($ip,0);
+-	if (!defined($host[3])) {
+-		return undef;
++	my ( $err, @res ) = getaddrinfo($ip,0);
++	return undef if ($err);
++	while( my $ai = shift @res ) {
++		my ( $err, $host, $service ) = getnameinfo($ai->{addr}, NI_NAMEREQD);
++		return $host unless($err);
+ 	}
+-	my @ret = getnameinfo($host[3], NI_NAMEREQD);
+-	return undef unless(scalar(@ret) == 2);
+-	return $ret[0];
++	return undef;
+ }
+ 
+ # ld_getservbyname
diff -Nru resource-agents-3.9.2/debian/patches/series resource-agents-3.9.2/debian/patches/series
--- resource-agents-3.9.2/debian/patches/series	2011-10-20 13:50:50.0 +0200
+++ resource-agents-3.9.2/debian/patches/series	2013-01-02 04:35:00.0 +0100
@@ -2,3 +2,4 @@
 02_spelling_fixes.patch
 CVE-2010-3389--bug598549.patch
 mysql-path.patch
+fix-gethostinfo-v2.patch


signature.asc
Description: Digital signature

Bug#697531: Finally found the culprit

[Ingo Hadan]

Finally, I found the culprit!
debian/patches/warnings contains a patch for NedMainWindow::draw(...) in
mainwindow.cpp that was intended to fix a warning about an unused
variable. The patch moves the two lines 

cairo_scaled_font_t *scaled_font;
scaled_font = NedResource::getScaledFont(m_current_zoom_level);

into the

#ifdef HAS_SET_SCALED_FONT

The getScaledFont() method, however, has a side effect in that it calls
NedResource::createScaledFont(int zoom_level) (contained in
resources.cpp) (which itself contains several #ifdef HAS_SET_SCALED_FONT).

Obviously, createScaledFont must be called, whatever the value of
HAS_SET_SCALED_FONT is, because if I revert the patch then the PDF
export works as expected.


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

Bug#697557: unblock: swi-prolog/5.10.4-5

[Євгеній Мещеряков]

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

Please unblock package swi-prolog

This version fixes two security issues, CVE-2012-6089 and CVE-2012-6090,
both possible buffer overflows. See also bug #697416.

The full list of changes in this version:

  * New patches (taken from RedHat bugzilla, closes: #697416):
- CVE-2012-6089.diff - fix for CVE-2012-6089 - possible buffer overrun in
  path canonisation code
- CVE-2012-6090.diff - fix for CVE-2012-6090 - Possible buffer overflows
  when expanding file-names with long paths
  * Urgency "medium" because of a fix for a security bug
 
The debdiff against package in testing is attached.

unblock swi-prolog/5.10.4-5

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

Kernel: Linux 3.7-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru swi-prolog-5.10.4/debian/changelog swi-prolog-5.10.4/debian/changelog
--- swi-prolog-5.10.4/debian/changelog	2012-10-08 21:55:23.0 +0200
+++ swi-prolog-5.10.4/debian/changelog	2013-01-05 03:44:17.0 +0100
@@ -1,3 +1,14 @@
+swi-prolog (5.10.4-5) unstable; urgency=medium
+
+  * New patches (taken from RedHat bugzilla, closes: #697416):
+- CVE-2012-6089.diff - fix for CVE-2012-6089 - possible buffer overrun in
+  path canonisation code
+- CVE-2012-6090.diff - fix for CVE-2012-6090 - Possible buffer overflows
+  when expanding file-names with long paths 
+  * Urgency "medium" because of a fix for a security bug
+
+ -- Євгеній Мещеряков   Sat, 05 Jan 2013 03:43:46 +0100
+
 swi-prolog (5.10.4-4) unstable; urgency=medium
 
   * Build-conflict with libncursesw5-dev, so it will not be used during build
diff -Nru swi-prolog-5.10.4/debian/patches/CVE-2012-6089.diff swi-prolog-5.10.4/debian/patches/CVE-2012-6089.diff
--- swi-prolog-5.10.4/debian/patches/CVE-2012-6089.diff	1970-01-01 01:00:00.0 +0100
+++ swi-prolog-5.10.4/debian/patches/CVE-2012-6089.diff	2013-01-05 03:44:17.0 +0100
@@ -0,0 +1,97 @@
+Author: Jan Wielemaker 
+Description: Fix for CVE-2012-6089 - Possible buffer overrun in path canonisation code
+ The patch was taken from RedHat bugzilla, file locations were adjusted.
+Origin: vendor, RedHat
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6089
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697416
+---
+From 6149f39ada50f7ebc6b0cb7756490a0fea967bd1 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
+Date: Fri, 4 Jan 2013 13:33:11 +0100
+Subject: [PATCH 1/2] Fix CVE-2012-6089
+
+Upstream fix ported to 5.10.2:
+
+From a9a6fc8a2a9cf3b9154b490a4b1ffaa8be4d723c Mon Sep 17 00:00:00 2001
+From: Jan Wielemaker 
+Date: Sun, 16 Dec 2012 18:13:17 +0100
+Subject: [PATCH] FIXED: Possible buffer overrun in patch canonisation code.
+
+Pushes pointers on an automatic array without checking for overflow.
+Can be used for DoS attacks.  Will be extremely hard to make it execute
+arbitrary code.
+---
+ src/pl-buffer.h |  2 ++
+ src/pl-os.c | 19 +++
+ 2 files changed, 13 insertions(+), 8 deletions(-)
+
+--- a/src/os/pl-buffer.h
 b/src/os/pl-buffer.h
+@@ -83,6 +83,8 @@
+   sizeof((b)->static_buffer))
+ #define emptyBuffer(b)   ((b)->top  = (b)->base)
+ #define isEmptyBuffer(b) ((b)->top == (b)->base)
++#define popBuffer(b,type) \
++	((b)->top -= sizeof(type), *(type*)(b)->top)
+ 
+ #define discardBuffer(b) \
+ 	do \
+--- a/src/os/pl-os.c
 b/src/os/pl-os.c
+@@ -1081,8 +1081,7 @@
+ char *
+ canoniseFileName(char *path)
+ { char *out = path, *in = path, *start = path;
+-  char *osave[100];
+-  int  osavep = 0;
++  tmp_buffer saveb;
+ 
+ #ifdef O_HASDRIVES			/* C: */
+   if ( in[1] == ':' && isLetter(in[0]) )
+@@ -1110,7 +1109,8 @@
+ in += 2;
+   if ( in[0] == '/' )
+ *out++ = '/';
+-  osave[osavep++] = out;
++  initBuffer(&saveb);
++  addBuffer(&saveb, out, char*);
+ 
+   while(*in)
+   { if (*in == '/')
+@@ -1126,15 +1126,15 @@
+ 	  }
+ 	  if ( in[2] == EOS )		/* delete trailing /. */
+ 	  { *out = EOS;
+-	return path;
++	goto out;
+ 	  }
+ 	  if ( in[2] == '.' && (in[3] == '/' || in[3] == EOS) )
+-	  { if ( osavep > 0 )		/* delete /foo/../ */
+-	{ out = osave[--osavep];
++	  { if ( !isEmptyBuffer(&saveb) )		/* delete /foo/../ */
++	{ out = popBuffer(&saveb, char*);
+ 	  in += 3;
+ 	  if ( in[0] == EOS && out > start+1 )
+ 	  { out[-1] = EOS;		/* delete trailing / */
+-		return path;
++		goto out;
+ 	  }
+ 	  goto again;
+ 	} else if (	start[0] == '/' && out == start+1 )
+@@ -1148,12 +1148,15 @@
+ 	in++;
+   if ( out > path && out[-1] != '/' )
+ 	*out++ = '/';
+-  osave[osavep++] = out;
++  addBuffer(&saveb, out, char*);
+ } else
+   *out++ = *in++;
+   }

Bug#675913: fixed in resource-agents 1:3.9.3+git20121009-2

[Martin Gerhard Loschwitz]

Am 06.01.13 23:42, schrieb Adam D. Barratt:
> On Wed, 2013-01-02 at 04:50 +0100, gregor herrmann wrote:
>> On Tue, 01 Jan 2013 20:39:28 +, Adam D. Barratt wrote:
>>
 This bug is also present in wheezy. The patch that fixes it in sid, cleanly
 applies to the version in wheezy. Will you prepare an upload for
 testing-proposed-updates?
>>> Ping?
>>
>> If the maintainer is busy, I can upload to t-p-u.
>> Debdiff attached (just the patch from unstable).
> 
> I've not seen a followup from the maintainer, but from my side that
> would be appreciated; thanks.
> 
> Regards,
> 
> Adam
> 

Go ahead and upload pretty please. Thanks a lot, much appreciated!

best regards
Martin

-- 
Martin Gerhard Loschwitz
Debian GNU/Linux Developer


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

Bug#693924: unblock: ltsp/5.4.2-4

[Julien Cristau]

On Wed, Nov 21, 2012 at 12:02:39 -0800, Vagrant Cascadian wrote:

> +- Fix initramfs udhcp hook to use /run instead of /tmp, which allows the 
> +  booting from a network using PXE ProxyDHCP (Closes: #693746).

This requires initramfs-tools 0.99 AFAICT, there's no /run before that.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#675913: fixed in resource-agents 1:3.9.3+git20121009-2

[Adam D. Barratt]

On Wed, 2013-01-02 at 04:50 +0100, gregor herrmann wrote:
> On Tue, 01 Jan 2013 20:39:28 +, Adam D. Barratt wrote:
> 
> > > This bug is also present in wheezy. The patch that fixes it in sid, 
> > > cleanly
> > > applies to the version in wheezy. Will you prepare an upload for
> > > testing-proposed-updates?
> > Ping?
> 
> If the maintainer is busy, I can upload to t-p-u.
> Debdiff attached (just the patch from unstable).

I've not seen a followup from the maintainer, but from my side that
would be appreciated; 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#696778: pu: package portmidi/1:184-2

[Niels Thykier]

Control: tags -1 pending

On 2013-01-06 17:36, Alessio Treglia wrote:
> On Sun, Jan 6, 2013 at 3:55 PM, Adam D. Barratt
>  wrote:
>> fwiw, -2+squeeze1 would be more conventional than -2+squeeze0.1
> 
> Uploaded, moreover I set the versioning as suggested by Adam.
> 
> Cheers!
> 

Flagged acceptance, thanks.

~Niels


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

Bug#697434: pu: package gzip/1.3.12-9+deb6u0

[Adam D. Barratt]

Control: tags -1 + confirmed squeeze

On Sat, 2013-01-05 at 11:47 +0100, Niels Thykier wrote:
> I would like to upload a patched version of gzip to fix #627121
> (grave; use of memcpy with overlapping memory regions).

+gzip (1.3.12-9+deb6u0) UNRELEASED; urgency=low
+
+  * Non-maintainer upload to stable.
+  * Backport upstream patch to avoid using memcpy on overlapping
+memory regions.  (Closes: #627121)

Despite what dev-ref implies, we've still been using +squeeze for
stable. Other than that, assuming the resulting package has been tested
on a squeeze system, please go ahead; 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#686502: pxz produces archives broken for busybox's unxz

[Bastian Blank]

On Thu, Dec 27, 2012 at 10:08:07PM +0100, Abou Al Montacir wrote:
> + if (r == XZ_STREAM_END) {
> + /* Eat padding. Stream never starts with zeros, and 
> padding is 32 aligned */
> + while ((iobuf.in_pos < iobuf.in_size) && 
> (iobuf.in[iobuf.in_pos] == 0)) {
> + iobuf.in_pos += 1;
> + }
> + /* Reached end of buffer. Fill it again from stream */
> + if (iobuf.in_pos == iobuf.in_size) {
> + continue;
> + }
> + if(iobuf.in_pos % 4){

Are you sure this is correct? in_pos is the position in tht buffer, not
the file. Also look out for coding style.

> + if (r == XZ_STREAM_END) {

Again the same check?

>   if (r == XZ_STREAM_END) {
> - break;
> + xz_dec_end(state);
> + /* Look for any other streams */
> + continue;

Why do you have three XZ_STREAM_END checks in this state machine?

Bastian

-- 
There are always alternatives.
-- Spock, "The Galileo Seven", stardate 2822.3


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

Bug#663575: sawzall: FTBFS: error: 'sawzall::Proc::Proc' names the constructor, not the type

[Daniel T Chen]

Package: sawzall
Version: 1.0-1
Followup-For: Bug #663575
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu raring ubuntu-patch

In Ubuntu, the attached patch can be applied to achieve the following:

  * Add fix_erroneous_contructor patch from upstream changeset #38 to
resolve FTBFS (Closes: #663575)


Thanks for considering the patch.

Please note that there are additional issues that cause further FTBFS;
this patch addresses this specific issue.


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

Kernel: Linux 3.2.0-35-generic (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
diff -Nru sawzall-1.0/debian/changelog sawzall-1.0/debian/changelog
diff -Nru sawzall-1.0/debian/control sawzall-1.0/debian/control
--- sawzall-1.0/debian/control	2010-12-02 16:34:09.0 -0500
+++ sawzall-1.0/debian/control	2013-01-06 17:14:39.0 -0500
@@ -1,7 +1,8 @@
 Source: sawzall
 Section: devel
 Priority: optional
-Maintainer: Gustavo Franco 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Gustavo Franco 
 Build-Depends: debhelper (>= 7), autotools-dev, protobuf-compiler, libpcre3-dev, libssl-dev, libicu-dev, libstdc++6-4.4-dev, libprotoc-dev
 Standards-Version: 3.8.3
 Homepage: http://code.google.com/p/szl/
diff -Nru sawzall-1.0/debian/patches/fix_erroneous_contructor sawzall-1.0/debian/patches/fix_erroneous_contructor
--- sawzall-1.0/debian/patches/fix_erroneous_contructor	1969-12-31 19:00:00.0 -0500
+++ sawzall-1.0/debian/patches/fix_erroneous_contructor	2013-01-06 16:54:07.0 -0500
@@ -0,0 +1,13 @@
+Index: sawzall-1.0/src/engine/symboltable.cc
+===
+--- sawzall-1.0.orig/src/engine/symboltable.cc	2010-08-15 18:04:14.0 -0400
 sawzall-1.0/src/engine/symboltable.cc	2013-01-06 16:54:00.071962463 -0500
+@@ -44,7 +44,7 @@
+ // --
+ // Implementation of SymbolTable
+ 
+-Proc::Proc* SymbolTable::init_proc_ = NULL;
++Proc* SymbolTable::init_proc_ = NULL;
+ 
+ List* SymbolTable::table_types_ = NULL;
+ TableType* SymbolTable::collection_type_ = NULL;
diff -Nru sawzall-1.0/debian/patches/series sawzall-1.0/debian/patches/series
--- sawzall-1.0/debian/patches/series	2010-11-05 17:00:53.0 -0400
+++ sawzall-1.0/debian/patches/series	2013-01-06 16:53:18.0 -0500
@@ -1 +1,2 @@
 debian-changes-1.0-1
+fix_erroneous_contructor

Bug#686502: pxz produces archives broken for busybox's unxz

[Bastian Blank]

On Sun, Jan 06, 2013 at 09:40:00PM +0100, Bastian Blank wrote:

This was the wrong mail.

Bastian

-- 
Oblivion together does not frighten me, beloved.
-- Thalassa (in Anne Mulhall's body), "Return to Tomorrow",
   stardate 4770.3.


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

Bug#697556: blueman: FTBFS with python multiarch headers

[Micah Gersten]

Package: blueman
Version: 1.23-1
Severity: normal
Tags: patch
User: debian-pyt...@lists.debian.org
Usertags: origin-ubuntu raring ubuntu-patch multiarch


*** /tmp/tmpUXMJV7/bug_body

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

  * Fix for python multiarch paths; Add build dep on dh-autoreconf; Add
autoreconf.mk to rules
- update debian/control
- add debian/rules
- add debian/patches/03_python_multiarch_include.patch
- update debian/patches/series


Thanks for considering the patch.


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

Kernel: Linux 3.2.0-35-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru blueman-1.23/debian/changelog blueman-1.23/debian/changelog
diff -Nru blueman-1.23/debian/control blueman-1.23/debian/control
--- blueman-1.23/debian/control	2012-08-07 22:49:03.0 -0500
+++ blueman-1.23/debian/control	2013-01-06 16:17:15.0 -0600
@@ -10,7 +9,7 @@
libgtk2.0-dev (>= 2.16), libstartup-notification0-dev,
python-gobject-dev, libbluetooth-dev (>= 4.0), intltool,
python-dev (>= 2.6.6-3~), python-pyrex, python-gtk2-dev,
-   python-notify, python-dbus
+   python-notify, python-dbus, dh-autoreconf
 
 Package: blueman
 Architecture: any
diff -Nru blueman-1.23/debian/patches/03_python_multiarch_include.patch blueman-1.23/debian/patches/03_python_multiarch_include.patch
--- blueman-1.23/debian/patches/03_python_multiarch_include.patch	1969-12-31 18:00:00.0 -0600
+++ blueman-1.23/debian/patches/03_python_multiarch_include.patch	2013-01-06 02:33:30.0 -0600
@@ -0,0 +1,15 @@
+Description: Add python multiarch include dirs
+ Use python-config to get proper include dirs
+Author: Micah Gersten 
+
+--- blueman-1.23.orig/acinclude.m4
 blueman-1.23/acinclude.m4
+@@ -90,7 +90,7 @@ AC_MSG_CHECKING(for headers required to
+ dnl deduce PYTHON_INCLUDES
+ py_prefix=`$PYTHON -c "import sys; print sys.prefix"`
+ py_exec_prefix=`$PYTHON -c "import sys; print sys.exec_prefix"`
+-PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}"
++PYTHON_INCLUDES=`python-config --includes`
+ if test "$py_prefix" != "$py_exec_prefix"; then
+   PYTHON_INCLUDES="$PYTHON_INCLUDES -I${py_exec_prefix}/include/python${PYTHON_VERSION}"
+ fi
diff -Nru blueman-1.23/debian/patches/series blueman-1.23/debian/patches/series
--- blueman-1.23/debian/patches/series	2012-08-07 22:59:07.0 -0500
+++ blueman-1.23/debian/patches/series	2013-01-06 02:33:59.0 -0600
@@ -1,2 +1,3 @@
 01_dont_autostart_lxde.patch
 02_dont_crash_on_non-bluetooth_card.patch
+03_python_multiarch_include.patch
diff -Nru blueman-1.23/debian/rules blueman-1.23/debian/rules
--- blueman-1.23/debian/rules	2012-08-07 22:49:03.0 -0500
+++ blueman-1.23/debian/rules	2013-01-06 02:30:44.0 -0600
@@ -6,6 +6,7 @@
 # Note that this class inherits from autotools.mk and docbookxml.mk,
 # so you don't need to include those too.
 include /usr/share/cdbs/1/class/gnome.mk
+include /usr/share/cdbs/1/rules/autoreconf.mk
 
 DEB_CONFIGURE_EXTRA_FLAGS := --disable-runtime-deps-check
 

Bug#697479: Critical bug fixes to be2net driver

[Ben Hutchings]

On Sat, 2013-01-05 at 20:11 +, Bandi,Sarveshwar wrote:
> Please find attached patches for 13 critical fixes. These patches have
> been accepted upstream.  The patches also contain the upstream commit
> id thanks to Ben Hutchings' git-format-patch-for-backport script .

These all look reasonable.  I've commited them to svn and they should be
in our package version 3.2.36-1.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.


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

Bug#694052: Bug#695642: pu: package magpierss/0.72-8+squeeze2

[Niels Thykier]

Control: tags 695642 confirmed squeeze

On 2012-12-11 04:52, Marcelo Jorge Vieira wrote:
> Package: release.debian.org
> Tags: squeeze
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> 
> Hi!
> 
> Please unblock package magpierss, it fix #694052.
> Attached you will find a debdiff.
> 
> 
> Cheers.
> 

Looks good; please let us know when you have uploaded it.

~Niels


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

Bug#697547: unblock: tpu (pre-approval) qcontrol/0.4.2-7+wheezy2

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Sun, 2013-01-06 at 20:03 +, Ian Campbell wrote:
> Please unblock package qcontrol
> 
> The fix in +wheezy1 (unblock request #694267) was incomplete because it relied
> on the --direct flag which was only present in the version of qcontrol in sid.
> This new upload back ports that option, which will really close #693263 693263
> in testing.

Thanks. It looks okay to me, but then so did the previous
versions. :-( Doing the CC-for-a-d-i-ack too in case there are any
comments from that side.

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#687779: release.debian.org: New NMU fixing #679966

[Adam D. Barratt]

On Wed, 2013-01-02 at 22:18 +0100, John Paul Adrian Glaubitz wrote:
> On Wed, Jan 02, 2013 at 09:05:37PM +, Adam D. Barratt wrote:
> > The version information for #679966 looks like it might have got broken
> > at some point; is the bug still present in the unstable package?
> 
> Yes, the bug is present in the unstable version:
[...]
> However, it has been fixed in the latest upstream version tagged as
> version "2012-08-24". So I suggest unblocking my updated version for
> testing and then the original maintainer should update the unstable
> version to the latest upstream version.

Thanks for the confirmation. In general, we prefer that the fixes are
applied and verified in unstable first, as it's generally easier to fix
up in the event of any issues. (I saw your offer to sponsor an upload to
unstable; that's appreciated, 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#697450: grub-common: insmod part_gpt included twice

[Colin Watson]

On Sat, Jan 05, 2013 at 03:00:47PM +0100, Laurens Blankers wrote:
> When installing GRUB on a disk with GUID partition table (GPT) the 
> entry for loading the support module appears twice. This does
> not cause any problems, not even an error message, but I wanted
> to report it in case this issues masks a bigger issue.

This is unlikely to be a problem, and we don't consider the duplication
to be a bug; but please attach the entirety of /boot/grub/grub.cfg so
that it's possible to make sure.  I can't tell from just the extract you
posted.

Thanks,

-- 
Colin Watson   [cjwat...@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#697555: libtokyocabinet9: missing watchfile

[Nick Black]

Package: libtokyocabinet9
Version: 1.4.47-2
Severity: normal
Tags: patch

Dear Maintainer,

During development of SprezzOS 1, a Debian derivative, it was determined that
the tokyocabinet package is missing a watchfile. We've authored one, and used
it to discover a missing update. We'd like to add it back to Debian.


[skynet](0) $ cat packaging/tokyocabinet/debian/watch
version=3
http://fallabs.com/tokyocabinet/tokyocabinet-([\d\.]+)\.tar\.gz
[skynet](0) $



-- System Information:
Debian Release: 1 (von Neumann)
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.7.1 (SMP w/8 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 libtokyocabinet9 depends on:
ii  libbz2-1.0 1.0.6-SprezzOS1
ii  libc6  2.16-SprezzOS1
ii  multiarch-support  2.16-SprezzOS1
ii  zlib1g 2:1.2.7-SprezzOS1

libtokyocabinet9 recommends no packages.

libtokyocabinet9 suggests no packages.
version=3
http://fallabs.com/tokyocabinet/tokyocabinet-([\d\.]+)\.tar\.gz

Bug#697490: cloud: 697490: use sudoers.d

[Chris Fordham]

On Sun, 06 Jan 2013 21:58:51 +1100, Anders Ingemann   
wrote:



You are right, sudoers.d should be used, this would also fix the
problem with wheezy, where my sed command does not work, because the
layout of the file has changed.
This is a good example of why template-based configuration is better used  
rather than regex/stream based editing.



Anders


On 6 January 2013 10:16, Charles Plessy  wrote:
forwarded 697490  
https://github.com/andsens/ec2debian-build-ami/issues/43

quit

Le Sun, Jan 06, 2013 at 07:58:25PM +1100, Chris Fordham a écrit :

>
Did you test that with setting DEBIAN_FRONTEND=noninteractive first ?


No, I am running the upgrade interactively, and I would like to be able  
to
answer relevant questions if any.  Therefore, if it is possible to have  
good
defaults that remove the need for some of the existing questions, it  
will leave

more time and focus for the remaining ones.

I have forwarded my suggestion on GitHub's page for  
ec2debian-build-ami.  Let's

see Anders' response.

Cheers,

--
Charles


--
To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact  
listmas...@lists.debian.org
Archive:  
http://lists.debian.org/20130106091622.gc13...@falafel.plessy.net





--
To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact  
listmas...@lists.debian.org
Archive:  
http://lists.debian.org/camcogxfqccy04ugot6nevtqbt3gnjk2mt7c4wsxmahqvunr...@mail.gmail.com





--

Chris Fordham

Backline Support Engineer
RightScale Technical Services


Direct: +1 805 243 0252

Cell: +61 423 003 417

Skype: chris.fordham.rs

Email: chris.ford...@rightscale.com


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

Bug#697220: Please enable C++11 threading

[Stephen Kitt]

Hi Max,

On Wed, 2 Jan 2013 21:33:13 +0100, Max Kellermann  wrote:
> According to /usr/include/c++/4.6/i686-w64-mingw32/bits/c++config.h,
> the C++11 threading library (std::mutex and others) has been disabled
> at compile time.  Please enable it to allow compiling multi-threaded
> C++ applications.

It's disabled automatically during the build because it's not supported on
Windows using gcc 4.6. Once I switch to gcc 4.7 or 4.8 it should be enabled
automatically. (But I'll check to make sure!)

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#694260: Fwd: Re: [Bug-freedink] Bug#694260: freedink: Stack corruption

[Bas Wijnen]

On 06-01-13 21:42, Manuel A. Fernandez Montecelo wrote:
> 2013/1/6 Bas Wijnen :
>>> I tried to use the "save4.dat" but the hero doesn't appear in front of
>>> any cave, but inside castle walls, with "screen locked", and I have to
>>> kill monsters through walls (!?!?) so the screen unlocks and I can get
>>> out of the castle.  Still, no caves.
>>
>> The instruction for that one was only meant for Sylvain, who knows how
>> to install and run "d-mods". I created the "minibug" dmod to make it
>> easier for you. ;-)
> 
> Yep, I know, and I appreciate it.  I was trying to use "save4.dat"
> since I wasn't getting any enlightening info with your dmod.

Well, here are the instructions:
Get http://files.dinknetwork.com/dmod/etrnscd0.dmod
It's a bzip2'd tar archive. Unpack it.
copy save4.dat into the new directory etrnscd0
run freedink -w -g etrnscd0
Select continue and the (only) save file there is.

Now you should be in front of a cave. :-)
I don't think it helps much, though.

Thanks,
Bas



signature.asc
Description: OpenPGP digital signature

Bug#664068: USB MIDI keyboard fails to initialize

[Jonathan Nieder]

tags 664068 - moreinfo
quit

Olivier MATZ wrote:

> I'm running a 3.7.1 kernel. I first checked that the issue was still
> present in this kernel: it failed 4 times among 5 tests.
>
> Then I applied the 2 patches that you provided on top of the same
> kernel (3.7.1), and I can confirm that it worked 5 times among 5.

Nice to hear.  It's been a pleasure.


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

Bug#697531: ntedfont and all characters from that font not included in PS-File

[Ingo Hadan]

Meanwhile I dug a bit deeper into the problem and compared the postscript
files generated by the squeeze and the wheezy versions of nted. In the
wheezy version all characters from nted's special font
/usr/share/nted/ntedfont.pfa are dropped by the postscript generator.
In particular, not only note heads are missing but also clefs, signs,
rests etc. The font itself isn't included either.

Also, I tried the squeeze nted executable in my wheezy installation:
That one worked! This rules out any configuration issues as well as
differences in the dynamic libraries, in particular, it probably has
nothing to do with fontconfig, as I guessed.


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

Bug#543296: RFP: python-pycdio -- Python interface to libcdio optical media control library

[Ross Burton]

On Sunday, 6 January 2013 at 11:56, Martin Michlmayr wrote:
> * Jonas Smedegaard mailto:d...@jones.dk)> [2010-07-06 20:56]:
> > Yes, I stil am interested in this for the morituri package. I can
> > package it, but if you are interested, I already have my hands pretty
> > full so would appreciate if you take over! :-)
> 
> 
> Ross, are you still planning to package python-pycdio? I noticed that
> morituri suggests python-pycdio, even though it's not in Debian.

I don't really have the time at present, sorry.

Ross 


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

Bug#697554: kdeartwork: debian/copyright file seems to be outdated and/or incomplete

[Francesco Poli (wintermute)]

Source: kdeartwork
Version: 4:4.8.4-2
Severity: serious
Justification: Policy 2.3

Hello and thanks for maintaining this package!

It seems to me that the debian/copyright file is outdated and/or incomplete.

For instance:

 (A) the debian/copyright file talks about "Files under kworldclock/", but
 I couldn't find this directory in the source package: could you please
 confirm that those files have been dropped from the package? this
 is really important, as their DFSG-freeness is not clear to me...

 (B) the source package seems to include files under the WeatherWallpapers/ ,
 HighResolutionWallpapers/ , and aurorae/ , but I cannot see any
 verbatim copy of their copyright information and distribution licenses
 in the debian/copyright file: could you please confirm that I am not
 overlooking anything?

These issues (and possibly others), if confirmed, should be fixed by updating
the debian/copyright file to reflect the current content of the package.

Please let me know.
Thanks a lot for your time.


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

Bug#599099: pidgin-microblog: Twitter crashes

[Adrian Fita]

Package: pidgin-microblog
Version: 0.3.0-3
Followup-For: Bug #599099

I also experienced this crash. But after checking Issue 266[1] on
microblog-purple project's issue tracker, I managed to connect by using
u...@api.twitter.com as username instead of the email address usually
used when connecting to the twitter.com webapp.

 1/ http://code.google.com/p/microblog-purple/issues/detail?id=266


-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.5-trunk-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/dash

Versions of packages pidgin-microblog depends on:
ii  libatk1.0-0 2.4.0-2
ii  libc6   2.13-38
ii  libcairo2   1.12.2-2
ii  libfontconfig1  2.9.0-7.1
ii  libfreetype62.4.9-1.1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-3
ii  libgtk2.0-0 2.24.10-2
ii  libpango1.0-0   1.30.0-1
ii  libpurple0  2.10.6-2

pidgin-microblog recommends no packages.

pidgin-microblog 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#624694: Please try unhide.rb

[xiscu]

The result is:

# unhide.rb -v
Scanning for hidden processes...
No hidden processes found!


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

Bug#697553: RFA: nqc -- Not Quite C compiler for LEGO Mindstorms RCX

[Ben Pfaff]

Package: wnpp

The LEGO Mindstorms RCX is a Hitachi microcontroller embedded into a
LEGO brick.  This package lets you write programs in a C-like language
and download them to your RCX using the serial or USB infrared tower
included with the RCX.

I am seeking a new maintainer for this package because I no longer have
access to the RCX hardware required to test it.  I suspect that there
are few potential maintainers for this package because of its low
ranking in the Debian popularity-contest.


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

Bug#697552: exim4-base: watchfile is broken

[Nick Black]

Source: exim4-base
Version: 4.80
Severity: normal
Tags: patch

Dear Maintainer,

During development of SprezzOS 1, a Debian derivative, it was discovered that
the exim watchfile is out-of-date and broken. We've fixed the watchfile, and
would like to provide it back to Debian. Here it is:


[skynet](2) $ cat packaging/exim4/debian/watch
version=3
ftp://ftp.exim.org/pub/exim/exim4/exim-(4[\.\d]+)\.tar\.bz2
[skynet](0) $

Thanks!



-- System Information:
Debian Release: 1 (von Neumann)
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.7.1 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
version=3
ftp://ftp.exim.org/pub/exim/exim4/exim-(4[\.\d]+)\.tar\.bz2

Bug#697551: Nested KVM guests don't work on qemu-system but run fine on qemu-kvm

[Sakari Ailus]

Package: qemu-system
Version: 1.1.2+dfsg-3

Nested KVM guests don't work with qemu-system (qemu-system-x86_64) on
amd64 arch. When the nested guest is started, the guest on physical host
crashes (and consumes all available CPU time available from it from this
onwards). There are no error messages, just a hard crash.

Nested KVM guests run fine if the guest on physical hardware uses
qemu-kvm (same version) instead.

To use nested guests, one must pass nested=1 argument to kvm-intel (or
kvm-amd I guess) to enable nested guests and use -cpu core2duo,+vmx
option for qemu-kvm to the guest that's to be run on the physical
machine. This machine has an Intel Core 2 Duo CPU.

While this issue as itself isn't grave and might well be a property of
the upstream QEMU, I guess that eventually qemu-kvm will be replaced by
qemu-system, so it might be worth tracking this to ensure nested guests
work fine at that time. Other than that, I'm happily using
qemu-system-x86_64 for my KVM guests where I don't need nested guest.

Thanks.

-- 
Kind regards,

Sakari Ailus
sakari.ai...@iki.fi


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

Bug#697199: cannot find ../lib/clang/3.2/lib/linux/libclang_rt.ubsan-x86_64.a: No such file or directory

[Sylvestre Ledru]

severity 697199 normal
thanks

On 06/01/2013 21:15, Mathieu Malaterre wrote:
> On Sun, Jan 6, 2013 at 8:48 PM, Sylvestre Ledru  wrote:
>> On 06/01/2013 20:32, Mathieu Malaterre wrote:
>>> On Sun, Jan 6, 2013 at 7:19 PM, Sylvestre Ledru  
>>> wrote:

>> Both:
>>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697199#10
> 

Sorry, I missed that message.

Anyway, as you said previously, it seems it needs the cmake build system
and we are currently using the autotools for now...

I haven't tried to use the cmake build system but I might give it a try
at some point.

Sorry,
Sylvestre


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

Bug#637207: New upstream release: 1.2

[Eugene V. Lyubimkin]

2013-01-06 19:00, Alessio Treglia:
> Eugene, could you please mail the MIA team about this bug?

Done.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer


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

Bug#650981: Re: Memory leak on Quagga 0.99.20

[Emmanuel DECAEN]

Hello,

Yes, it has long been fixed in Quagga  0.99.21...
But, current Debian Stable release contains Quagga 0.99.20.

I you plan to close this bug, could you please solve the bug before.

Regards
-- 
Emmanuel DECAEN

Le 06/01/2013 17:11, Christian Hammers a écrit :
> Hello
>
> This has long been fixed in Quagga 0.99.21.
>
> bye,
>
> -christian-


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

Bug#697548: linux-image-3.7-trunk-amd64: temperatures are too high on Lenevo T420

[gpe]

Le Sun, 06 Jan 2013 20:30:09 +
Ben Hutchings  a écrit:

> Control: tag -1 moreinfo
> 
> On Sun, 2013-01-06 at 21:04 +0100, gpe wrote:
> > Package: src:linux
> > Version: 3.7.1-1~experimental.2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> >* What led up to the situation?
> > 
> >updating with kernel 3.7.1. My machine is a Lenovo T420 (model
> >4180AT9)
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > 
> >  starting the system and logging into gnome session
> > 
> >* What was the outcome of this action?
> > 
> >sensors reports temperatures for cores and thermal zone which are
> >between 52°C and 60°C
> 
> This is not really very hot.

In absolute not but for an idle state ...

> 
> >* What outcome did you expect instead?
> > 
> >when running with kernel 3.6.9 the temperatures are under 42°C
> [...]
> 
> Did you test this immediately after rebooting?  I would expect an
> upgrade and reboot to make the CPU heat up.  You would have to leave it
> idle for some minutes to make a proper comparison.

Yes it's that I've done. I've switched several between 3.6.9 and 3.7.1 and
each the temperatures are significantly higher with 3.7.1.

> 
> If the temperature really stays higher with the newer kernel version
> then please install linux-tools-3.7 and generate a performance report:
> 
> # running as root:
> perf record -g -a sleep 60
> perf report -g > perf.txt

Could you confirm the last command please ?

Regards.


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