Bug#531362: tasksel -> laptop reboot hangs on "Saving VESA state"

Package: vbetool

20090615 netinst
Dell Inspirioon 5000 laptop
Tasksel -> laptop gives rise to hang at "Saving VESA state" on reboot.
Tasksel -> standard gives OK start

Bug#524643: closed by Ben Hutchings <ben <at> decadent.org.uk> (Re: linux-2.6: enabling APIC on Asus M3A78 Pro motherboard causes disk i/o problems and corruption)

Just for anyone's interest, the problem was caused by not 
clearing/resetting the BIOS settings after upgrading the BIOS.

Regards,

Arthur.

Debian Bug Tracking System wrote, on 01/06/09 07:42:
> This is an automatic notification regarding your Bug report
> which was filed against the linux-2.6 package:
> 
> #524643: linux-2.6: enabling APIC on Asus M3A78 Pro motherboard causes disk i/o problems and corruption
> 
> It has been closed by Ben Hutchings <ben <at> decadent.org.uk>.
...
> Subject:
> Re: linux-2.6: enabling APIC on Asus M3A78 Pro motherboard causes disk 
> i/o problems and corruption
> From:
> Ben Hutchings <ben <at> decadent.org.uk>
> Date:
> Sun, 31 May 2009 23:07:50 +0100
> To:
> 524643-done <at> bugs.debian.org
> 
> To:
> 524643-done <at> bugs.debian.org
> 
> 
> I seem to remember that we discussed this bug on IRC, but the

Bug#531363: [cuneiform] amd64 version doesn't get build by buildd

Package: cuneiform
Version: 0.6.0+dfsg-1
Severity: normal

I noticed that your package is not build by buildd 
https://buildd.debian.org/pkg.cgi?pkg=cuneiform
When I build it per hand I will get a lintian warning about some magic in 
Architecture - magic-arch-in-arch-list. Maybe this has something todo with 
your source package.
--

-- 
Robert Wohlrab

Bug#531128: Confirmed

tags 531128 +confirmed
thanks

This is a known bug in bzr-git. Bazaar currently requires commit
builders to provide two code paths, one based around
``record_iter_changes'' and one around ``record_entry_contents''. The
first is already used in simple cases and the latter will be removed
at some point in the future in favor of the first. 

bzr-git only implements ``record_iter_changes'' and at the moment the
plan is to just wait for Bazaar to switch to using that for all
commits, rather than spending time implementing
``record_entry_contents''. 

Bug#511904: No idea how this happened?

Can you remember how tihs happened exactly? Maybe during a failed
upgrade or something like that?

I have no idea how this could happen so not sur ehow I should fix it...

--

-- 
+-------- .''`.     - -- ---+  +        - -- --- ---- ----- ------+
| wilmer : :'  :  gaast.net |  | OSS Programmer   www.bitlbee.org |
| lintux `. `~'  debian.org |  | Full-time geek  wilmer.gaast.net |
+--- -- -  ` ---------------+  +------ ----- ---- --- -- -        +

Bug#531244: pperl: FTBFS

* Ryan Niebur:

> This package fails to build from source under sbuild using up to
> date sid. Attached is the build log.

This is probably caused by the relatively long path to the build
directory.  As a result, pperl runs into the 109 character path name
limit for UNIX domain sockets.

Bug#531364: RFA: unhide -- Forensic tool to find hidden processes and ports

Package: wnpp
Severity: normal

I request an adopter for the unhide package.

The package description is:
 Unhide is a forensic tool to find processes and TCP/UDP ports hidden by
 rootkits, Linux kernel modules or by other techniques.  It includes two
 utilities: unhide and unhide-tcp.
 .
 unhide detects hidden processes using three techniques:
  - comparing the output of /proc and /bin/ps
  - comparing the information gathered from /bin/ps with the one gathered
    from system calls (syscall scanning)
  - full scan of the process ID space (PIDs bruteforcing)
 .
 unhide-tcp identifies TCP/UDP ports that are listening but are not listed in
 /bin/netstat through brute forcing of all TCP/UDP ports available.
 .
 This package can be used by rkhunter in its daily scans.

The package is in good shape and upstream is very nice and responsive.

One thing you may want to consider if you adopt this package is how to integrate
this version of unhide re-written in ruby which is said to be faster:

  https://launchpad.net/unhide.rb

Cheers,
Francois

Bug#531056: leaks memory when vlan subinterfaces present

On Sun, May 31, 2009 at 09:03:23AM +0200, Thomas Anders wrote:
> John Morrissey wrote:
> > Just tried this; snmpd does *not* leak when kernel IPv6 support is
> > absent.
> 
> Thanks for your great help so far. Do you also have a chance to test
> upstream's 5.4.x SVN and/or SVN trunk (with IPv6 support enabled again)?

5.4.x svn didn't leak. Found the upstream commit that fixed this; a debdiff
is attached.

john
--

-- 
John Morrissey          _o            /\         ----  __o
jwm <at> horde.net        _-< \_          /  \       ----  <  \,
www.horde.net/    __(_)/_(_)________/    \_______(_) /_(_)__

diff -u net-snmp-5.4.1~dfsg/debian/changelog net-snmp-5.4.1~dfsg/debian/changelog
--- net-snmp-5.4.1~dfsg/debian/changelog
+++ net-snmp-5.4.1~dfsg/debian/changelog
 <at>  <at>  -1,3 +1,11  <at>  <at> 
+net-snmp (5.4.1~dfsg-13) unstable; urgency=low
+
+  * Fix memory leak when multiple interfaces have the same IPv6 address,
+    such as link-local addresses when VLAN subinterfaces are in use.
+    (Closes: #531056)
+
+ -- John Morrissey <jwm <at> horde.net>  Sun, 31 May 2009 23:07:32 +0000
+

Bug#531219: bitlbee-dev: package is not binNMU-safe

forcemerge 530345 531219
thanks

Hello,

Philipp Kern wrote:
> ASAP.  (And by the way there are currently two other RC bugs open, both
> uncommented since three months.)
> 
Best of all, the one you're reporting is a dupe. 

But yeah, I should pay more attention to this; working on that now.

Wilmer.

--

-- 
+-------- .''`.     - -- ---+  +        - -- --- ---- ----- ------+
| wilmer : :'  :  gaast.net |  | OSS Programmer   www.bitlbee.org |
| lintux `. `~'  debian.org |  | Full-time geek  wilmer.gaast.net |
+--- -- -  ` ---------------+  +------ ----- ---- --- -- -        +

Bug#530345: bitlbee-dev currently uninstallable due to binNMUs

Looking at this now.

Depends: bitlbee (= ${binary:Version})

The dependency seems right already, it's a binary dep, not a source dep.
 I see other programs just make the dependency less tight by doing
something like

Depends: foo (>= ${source:Version})

Is that the best I can get? :-/

Wilmer.

--

-- 
+-------- .''`.     - -- ---+  +        - -- --- ---- ----- ------+
| wilmer : :'  :  gaast.net |  | OSS Programmer   www.bitlbee.org |
| lintux `. `~'  debian.org |  | Full-time geek  wilmer.gaast.net |
+--- -- -  ` ---------------+  +------ ----- ---- --- -- -        +