Bug#1011456: ipv6toolkit: Update the package

[Octavio Alvarez]

On 23/05/22 05:00, Sophie Brun wrote:

Is it possible the update the package to include the latest upstream
changes? > I noticed that upstream has not made any tagged release since 2014 
but
they mentioned a version 2.1 in the CHANGES.TXT


As of today, Upstream version numbers can't be trusted. Please see [1] 
and [2].


I expect this to improve soon, as per comments in the issues.


If it can help, we (Kali developers) have updated the package last year [1].
It was named differently in Kali so we never noticed that the package
already exists in Debian. We just found out thanks to a bug report [2].
We will now use the package from Debian.


Thanks for bringing this up. Upstream should make a release soon and I 
will update Debian's package asap. This should bring Debian's up to par 
or ahead of Kali's so Kali's could be reliably dropped after that.


My only worry is the shebang patch you have [3] which reverts Upstream's 
[4] for issue [5]. If I follow Upstream, this change would be dropped. 
Is this OK with you?


Thanks,
Octavio.

[1] https://github.com/fgont/ipv6toolkit/issues/62

[2] https://github.com/fgont/ipv6toolkit/issues/77

[3] 
https://gitlab.com/kalilinux/packages/ipv6-toolkit/-/blob/kali/master/debian/patches/change-shebang-perl.patch


[4] 
https://github.com/fgont/ipv6toolkit/commit/f9ba6cec648b7f085d4c302f10e1a6a1202fff9d


[5] https://github.com/fgont/ipv6toolkit/pull/50

Bug#1016129: (no subject)

[Octavio Alvarez]

On 31/07/22 14:57, Thorsten Glaser wrote:

debdiff (±version) attached. Would you prefer for me to NMU, do a
maintainer-agreed regular upload (as -2), or handle this yourself,
Octavio?


I can handle it. By the way, did the fix work for you?


• the bullseye package, as-is, is broken, so this is an RC fix there
• buster “as-is” works but if libpcap0.8 is upgraded, either via
   buster-backports or by mixing buster and bullseye packages, it’ll
   break (and we cannot retrofit a matching Breaks to libpcap0.8 in
   bullseye any more now it’s released) so buster’s will either need
   the patch applied or a versioned depends on libpcap0.8 (<< 1.10)


The proposed fix should work with both libpcap versions, so that should 
be the way to go. I'll take a look at that too.



Will you communicate with the SRM or do you wish for me to handle that?


I may need help with that. I'll get back to you.

Thanks,
Octavio.

Bug#929005: superkb FTCBFS: upstream build system hard codes build architecture tools

[Octavio Alvarez]

On 5/22/19 7:59 AM, Helmut Grohne wrote:

On Wed, May 22, 2019 at 05:35:08AM -0500, Octavio Alvarez wrote:

First, in commit b364c89897 [1] I moved the help text outside of main.c into
a separate header file.


It seems to me that this commit misses the addition of the separate
header file.


Thank you for catching that. I added commit cf9a9bb3 [1] with the 
missing file.


Octavio.

[1] fix: added forgotten main-help-message.h
https://gitlab.com/alvarezp2000/superkb/commit/cf9a9bb303036085180181808078abe6ac652aff

Bug#929005: superkb FTCBFS: upstream build system hard codes build architecture tools

[Octavio Alvarez]

On 5/14/19 11:12 PM, Helmut Grohne wrote:

superkb fails to cross build from source, because the upstream build
system hard codes build architecture build tools (gcc and pkg-config).
The attached patch makes these tools substitutable,


Hi, Helmut,

Thank you for the patch! I applied it upstream.


but it doesn't make
superkb cross buildable due to its use of help2man. This is harder to
solve and not fixed here. Please consider applying the attached patch
anyway and close this bug when doing so even though superkb will
continue to fail cross building.


I also implemented a help2man fix upstream. It's done in two commits:

First, in commit b364c89897 [1] I moved the help text outside of main.c 
into a separate header file.


Then, in commit 6ba0933bd0 [2] I added a help stub: a Bash script that 
when takes the -h option it just processes the help message from the 
separate message file and outputs the help message. This stub is called 
from help2man instead of the application binary.


However, I clean the Bash script in a later commit (b5a418cc40 [3]) to 
use cpp -E instead of sed to parse the .h file. This is better because 
cpp is the proper parser for an .h file. Please confirm that this use of 
cpp does not break cross-compilation.


Because this technique is architecture independent it should work for
cross-compilation without having to build twice.

The three patches are upstream. Because I have not applied those to the 
Debian package I will keep the report open.


Thank you,
Octavio.

[1] Moved the help text outside of main.c
https://gitlab.com/alvarezp2000/superkb/commit/b364c8989773d68fb116fe2a8a5fd0c27b71bc18

[2] Add and use a help2man stub
https://gitlab.com/alvarezp2000/superkb/commit/6ba0933bd06d9ac5640aac42109f98ec1c2774fd

[3] help2man/superkb: way cleaner method to use main-help-message.h
https://gitlab.com/alvarezp2000/superkb/commit/b5a418cc4020b4ba276944b178235a9fb2373d8a

Bug#927091: linux-image-5.0.0-trunk-amd64: Broken scrollwheel after upgrade

[Octavio Alvarez]

I tested the patch and it works on my system.

I suppose this bug should be closed.

Thanks!
Octavio.

Bug#928397: linux-image-4.19.0-4-amd64: sky2 88E8040 network card does not detect link after hibernate

[Octavio Alvarez]

Package: src:linux
Version: 4.19.28-2
Severity: normal
Tags: upstream

Dear Maintainer,

After hibernation (using the power button on my laptop) my network card
does not detect link. It works fine in 4.9, it does not work in 4.19, it
still does not work in 5.1.0-rc7.

I bisected the kernel and this is the first bad commit:

commit bc976233a872c0f20f018fb1e89264a541584e25
Author: Thomas Gleixner 
Date:   Fri Dec 29 10:47:22 2017 +0100

genirq/msi, x86/vector: Prevent reservation mode for non maskable MSI

The new reservation mode for interrupts assigns a dummy vector when the
interrupt is allocated and assigns a real vector when the interrupt is
requested. The reservation mode prevents vector pressure when
devices with
a large amount of queues/interrupts are initialized, but only a minimal
subset of those queues/interrupts is actually used.

This mode has an issue with MSI interrupts which cannot be masked.
If the
driver is not careful or the hardware emits an interrupt before the
device
irq is requestd by the driver then the interrupt ends up on the dummy
vector as a spurious interrupt which can cause malfunction of the
device or
in the worst case a lockup of the machine.

Change the logic for the reservation mode so that the early
activation of
MSI interrupts checks whether:

 - the device is a PCI/MSI device
 - the reservation mode of the underlying irqdomain is activated
 - PCI/MSI masking is globally enabled
 - the PCI/MSI device uses either MSI-X, which supports masking, or
   MSI with the maskbit supported.

If one of those conditions is false, then clear the reservation mode
flag
in the irq data of the interrupt and invoke
irq_domain_activate_irq() with
the reserve argument cleared. In the x86 vector code, clear the
can_reserve
flag in the vector allocation data so a subsequent free_irq() won't
create
the same situation again. The interrupt stays assigned to a real vector
until pci_disable_msi() is invoked and all allocations are undone.

Fixes: 4900be83602b ("x86/vector/msi: Switch to global reservation
mode")

Thanks,
Octavio.


-- Package-specific info:
** Version:
Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc
version 8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-amd64
root=UUID=515d0602-7bc5-471d-92b8-9b5e655129c2 ro
memmap=0x1$0x0013556 memmap=0x1$0x0017556

** Not tainted

** Kernel log:
[  147.669537] smpboot: CPU 2 is now offline
[  147.693188] smpboot: CPU 3 is now offline
[  147.696387] PM: Creating hibernation image:
[  147.841906] PM: Need to copy 299141 pages
[  147.841911] PM: Normal pages needed: 299141 + 1024, available pages:
1745735
[  147.697007] PM: Restoring platform NVS memory
[  147.697197] ACPI: EC: EC started
[  147.697571] Enabling non-boot CPUs ...
[  147.697624] x86: Booting SMP configuration:
[  147.697625] smpboot: Booting Node 0 Processor 1 APIC 0x4
[  147.700198]  cache: parent cpu1 should not be sleeping
[  147.700563] CPU1 is up
[  147.700595] smpboot: Booting Node 0 Processor 2 APIC 0x1
[  147.703027]  cache: parent cpu2 should not be sleeping
[  147.703502] CPU2 is up
[  147.703535] smpboot: Booting Node 0 Processor 3 APIC 0x5
[  147.706000]  cache: parent cpu3 should not be sleeping
[  147.706422] CPU3 is up
[  147.708876] ACPI: Waking up from system sleep state S4
[  147.717775] ACPI: EC: interrupt unblocked
[  147.882229] usb usb1: root hub lost power or was reset
[  147.886234] ehci-pci :00:1a.0: cache line size of 64 is not supported
[  147.886261] usb usb2: root hub lost power or was reset
[  147.890243] ACPI: EC: event unblocked
[  147.890251] ehci-pci :00:1d.0: cache line size of 64 is not supported
[  147.891323] ath: phy0: ASPM enabled: 0x42
[  147.892583] sd 0:0:0:0: [sda] Starting disk
[  148.228697] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  148.228738] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  148.228774] ata5: SATA link down (SStatus 0 SControl 300)
[  148.234082] ata2.00: configured for UDMA/100
[  148.236704] ata1.00: configured for UDMA/133
[  148.241292] usb 1-1: reset high-speed USB device number 2 using ehci-pci
[  148.253277] usb 2-1: reset high-speed USB device number 2 using ehci-pci
[  148.697316] usb 1-1.1: reset high-speed USB device number 3 using
ehci-pci
[  148.905347] usb 2-1.2: reset low-speed USB device number 3 using ehci-pci
[  149.281350] usb 2-1.4: reset high-speed USB device number 4 using
ehci-pci
[  149.393227] PM: Basic memory bitmaps freed
[  149.393240] OOM killer enabled.
[  149.393244] Restarting tasks ... done.
[  149.416137] video LNXVIDEO:02: Restoring backlight state
[  149.416576] PM: hibernation exit
[  149.570128] wlan0: authenticate with 00:26:5a:f5:6a:de
[  149.589614] wlan0: send auth to 00:26:5a:f5:6a:de (try 1/3)
[  149.590945] wlan0: aborting authentication with 00:26:

Bug#927091: linux-image-5.0.0-trunk-amd64: Broken scrollwheel after upgrade

[Octavio Alvarez]

Hi,

I bisected the kernel to the following commit:

2dc702c991e3774af9d7ce410eef410ca9e2357e is the first bad commit
commit 2dc702c991e3774af9d7ce410eef410ca9e2357e
Author: Peter Hutterer 
Date:   Wed Dec 5 10:42:24 2018 +1000

HID: input: use the Resolution Multiplier for high-resolution scrolling

Windows uses a magic number of 120 for a wheel click. High-resolution
scroll wheels are supposed to use a fraction of 120 to signal smaller
scroll steps. This is implemented by the Resolution Multiplier in the
device itself.

If the multiplier is present in the report descriptor, set it to the
logical max and then use the resolution multiplier to calculate the
high-resolution events. This is the recommendation by Microsoft, see
http://msdn.microsoft.com/en-us/windows/hardware/gg487477.aspx

Note that all mice encountered so far have a logical min/max of 0/1, so
it's a binary "yes or no" to high-res scrolling anyway.

To make userspace simpler, always enable the REL_WHEEL_HI_RES bit. Where
the device doesn't support high-resolution scrolling, the value for the
high-res data will simply be a multiple of 120 every time. For
userspace,
if REL_WHEEL_HI_RES is available that is the one to be used.

Potential side-effect: a device with a Resolution Multiplier applying to
other Input items will have those items set to the logical max as well.
This cannot easily be worked around but it is doubtful such devices
exist.

Signed-off-by: Peter Hutterer 
Verified-by: Harry Cutts 
Signed-off-by: Benjamin Tissoires 

:04 04 fc4c9b48f3723ef6a8f36b768308bb3c99c9f882
475d4548b75765df6447e43992b07259b181f515 M  drivers
:04 04 dc356f23227a874721e6688445fc2b90f726e2a7
2190e33e4ad1bcaff0b35dc03194f29fbd9493c6 M  include

Bug#927091: linux-image-5.0.0-trunk-amd64: Broken scrollwheel after upgrade

[Octavio Alvarez]

Package: src:linux
Version: 5.0.2-1~exp1
Severity: normal

Dear Maintainer,

After upgrading from 4.19 to 5.0 (experimental) the scrollwheel is
slow. It takes about 20 steps to get the equivalent of a single step
from 4.19.

The mouse is a USB Microsft Wireless Mobile Mouse 3000:

Bus 002 Device 003: ID 045e:00e1 Microsoft Corp. Wireless Laser Mouse
6000 Receiver

(Please find lsusb -vvv information after the evtest info for the mouse)

I tried solaar, imwheel, resetmsmice, none worked. I ran evtest in both
versions and did two steps down and then two steps up:

Version 4.19:
$ sudo evtest
[sudo] password for alvarezp:
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:  AT Translated Set 2 keyboard
/dev/input/event1:  Microsoft Microsoft Notebook Receiver v2.0 Consumer
Control
/dev/input/event2:  Microsoft Microsoft Notebook Receiver v2.0 Mouse
/dev/input/event3:  ETPS/2 Elantech Touchpad
/dev/input/event4:  PC Speaker
/dev/input/event5:  Lid Switch
/dev/input/event6:  Power Button
/dev/input/event7:  Sleep Button
/dev/input/event8:  Power Button
/dev/input/event9:  Video Bus
/dev/input/event10: HDA Intel MID Mic
/dev/input/event11: HDA Intel MID Headphone
/dev/input/event12: HDA Intel MID HDMI/DP,pcm=3
/dev/input/event13: USB 2.0 PC Camera: WebCam SCB-0
Select the device event number [0-13]: 2
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x45e product 0xe1 version 0x111
Input device name: "Microsoft Microsoft Notebook Receiver v2.0 Mouse"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
Event code 272 (BTN_LEFT)
Event code 273 (BTN_RIGHT)
Event code 274 (BTN_MIDDLE)
Event code 275 (BTN_SIDE)
Event code 276 (BTN_EXTRA)
  Event type 2 (EV_REL)
Event code 0 (REL_X)
Event code 1 (REL_Y)
Event code 6 (REL_HWHEEL)
Event code 8 (REL_WHEEL)
  Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)
Properties:
Testing ... (interrupt to exit)
Event: time 1555288252.603793, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1555288252.603793, -- SYN_REPORT 
Event: time 1555288252.667781, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1555288252.667781, -- SYN_REPORT 
Event: time 1555288253.275651, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1555288253.275651, -- SYN_REPORT 
Event: time 1555288253.427623, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1555288253.427623, -- SYN_REPORT 


5.0:

$ sudo evtest
[sudo] password for alvarezp:
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:  AT Translated Set 2 keyboard
/dev/input/event1:  Microsoft Microsoft Notebook Receiver v2.0 Consumer
Control
/dev/input/event2:  Microsoft Microsoft Notebook Receiver v2.0 Mouse
/dev/input/event3:  ETPS/2 Elantech Touchpad
/dev/input/event4:  Lid Switch
/dev/input/event5:  Power Button
/dev/input/event6:  Sleep Button
/dev/input/event7:  Power Button
/dev/input/event8:  PC Speaker
/dev/input/event9:  Video Bus
/dev/input/event10: HDA Intel MID Mic
/dev/input/event11: HDA Intel MID Headphone
/dev/input/event12: HDA Intel MID HDMI/DP,pcm=3
/dev/input/event13: USB 2.0 PC Camera: WebCam SCB-0
Select the device event number [0-13]: 2
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x45e product 0xe1 version 0x111
Input device name: "Microsoft Microsoft Notebook Receiver v2.0 Mouse"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
Event code 272 (BTN_LEFT)
Event code 273 (BTN_RIGHT)
Event code 274 (BTN_MIDDLE)
Event code 275 (BTN_SIDE)
Event code 276 (BTN_EXTRA)
  Event type 2 (EV_REL)
Event code 0 (REL_X)
Event code 1 (REL_Y)
Event code 6 (REL_HWHEEL)
Event code 8 (REL_WHEEL)
Event code 11 (?)
Event code 12 (?)
  Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)
Properties:
Testing ... (interrupt to exit)
Event: time 1555289094.577076, type 2 (EV_REL), code 11 (?), value -7
Event: time 1555289094.577076, -- SYN_REPORT 
Event: time 1555289094.841059, type 2 (EV_REL), code 11 (?), value -7
Event: time 1555289094.841059, -- SYN_REPORT 
Event: time 1555289095.273039, type 2 (EV_REL), code 11 (?), value 7
Event: time 1555289095.273039, -- SYN_REPORT 
Event: time 1555289095.481020, type 2 (EV_REL), code 11 (?), value 7
Event: time 1555289095.481020, -- SYN_REPORT 


lsusb -vvv information for this device:
Bus 002 Device 003: ID 045e:00e1 Microsoft Corp. Wireless Laser Mouse
6000 Receiver
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMa

Bug#813464: ITP: ciscocmd -- Expect script to send a set of commands to a set of Cisco devices

[Octavio Alvarez]

Package: wnpp
Severity: wishlist
Owner: Octavio Alvarez 

* Package name: ciscocmd
  Version : 1.11
  Upstream Author : Alain Degreffe 
* URL : http://cosi-nms.sourceforge.net/alpha-progs.html
* License : GPLv2
  Programming Lang: Expect/TCL
  Description : Expect script to send a set of commands to a set of
Cisco devices

 ciscocmd is a Tcl/Expect script. With this tool, you can send a set of
 command to a large number of ios target hosts and get a separated report
 for each node.

 I use this program on a day-to-day basis and I have contributed code
 to it.

 Because this program is a single-file Expect script, package maintenance
 should be simple. I plan to maintain it by myself.

 I will need a sponsor for this package, though.

Bug#813346: pius option -S is wrong in the manpage

[Octavio Alvarez]

Package: pius
Version: 2.2.1-2
Severity: normal

Dear Maintainer,

The manpage for pius is written by Debian. The -S option is incorrectly
documented. The manpage says thay -S is an alias for --mail-tls and
will make pius use STARTTLS when talking to the SMTP server. However,
pius --help shows that -S is equal to --no-mail-tls and will, instead,
not use STARTTLS when talking to the SMTP server. Also, there is no
--mail-tls option at all.

As a consequence, the documentation for -u states that -S is implied.
However, using -u and -S simultaneously will, instead, turn off -S,
as shown by the following warning:

> NOTE: -u is present, turning off -S.

Thank you.

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pius depends on:
ii  gnupg   1.4.19-6
ii  gnupg2  2.1.9-1
ii  python  2.7.9-1
pn  python:any  

pius recommends no packages.

pius suggests no packages.

-- no debconf information

Bug#794800: refcard: Incorrect Spanish translations

[Octavio Alvarez]

Source: refcard
Severity: normal
Tags: l10n patch

Dear Maintainer,

I have detected some mistakes in the Debian Reference Card Spanish translation.
I am attaching the following patches to fix them.

* Removed misplaced quotes to fix refcard compilation
* Replace "por omisión" with "por defecto"
* Replace "substituir" with "sustituir"
* Replace "órden" with "orden"
* Add space in "p.ej." abbreviations
* Fix gender-mismatch typo
* Translated "CD images"
* Added tar support for .xz format
* Removed a misplaced string

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

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From eabfbb66f14cd263b5a44a5aee3eb54a390519ae Mon Sep 17 00:00:00 2001
From: Octavio Alvarez 
Date: Thu, 6 Aug 2015 11:48:42 -0700
Subject: [PATCH 1/9] es.po: Removed misplaced quotes to fix compilation

Signed-off-by: Octavio Alvarez 
---
 po4a/es.po | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/po4a/es.po b/po4a/es.po
index ef87da9..615405e 100644
--- a/po4a/es.po
+++ b/po4a/es.po
@@ -79,7 +79,7 @@ msgid ""
 "version 3 or higher. The license text can be found at http://";
 "www.gnu.org/copyleft/gpl.html\">http://www.gnu.org/copyleft/gpl.html "
 "and /usr/share/common-licenses/GPL-3."
-msgstr "Este documento puede ser utilizado según los términos de la Licencia Pública General de GNU (GPL) versión 3 o posterior. Puede encontrar el texto de la licencia en http://\"www.gnu.org/copyleft/gpl.html\";>http://www.gnu.org/copyleft/gpl.htm y en /usr/share/common-licenses/GPL-3."
+msgstr "Este documento puede ser utilizado según los términos de la Licencia Pública General de GNU (GPL) versión 3 o posterior. Puede encontrar el texto de la licencia en http://www.gnu.org/copyleft/gpl.html\";>http://www.gnu.org/copyleft/gpl.htm y en /usr/share/common-licenses/GPL-3."
 
 #. type: Content of: 
 #: entries.dbk:31 entries.dbk:367
-- 
1.9.1

>From df32cd95b7b9d316ef910836ffcf27d3e4f3d9f8 Mon Sep 17 00:00:00 2001
From: Octavio Alvarez 
Date: Thu, 6 Aug 2015 11:24:40 -0700
Subject: [PATCH 2/9] =?UTF-8?q?es.po:=20Replace=20"por=20omisi=C3=B3n"=20w?=
 =?UTF-8?q?ith=20"por=20defecto"?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Although in widespread use, "por omisión" is not the correct form.
The correct form is "por defecto".

Reference:
* http://lema.rae.es/drae/srv/search?val=defecto
* http://www.wikilengua.org/index.php/por_defecto

Signed-off-by: Octavio Alvarez 
---
 po4a/es.po | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/po4a/es.po b/po4a/es.po
index 615405e..ad29a1b 100644
--- a/po4a/es.po
+++ b/po4a/es.po
@@ -340,7 +340,7 @@ msgid ""
 "Default text editor.  May be nano, emacs, vi, joe."
 msgstr ""
-"Editor de textos por omisión. Puede ser nano, "
+"Editor de textos por defecto. Puede ser nano, "
 "emacs, vi, joe."
 
 #. type: Content of: 
@@ -492,7 +492,7 @@ msgstr "/etc/default/"
 #. type: Content of: 
 #: entries.dbk:224
 msgid "Default values for many daemons and services."
-msgstr "Valores por omisión para muchos demonios y servicios."
+msgstr "Valores por defecto para muchos demonios y servicios."
 
 #. type: Content of: 
 #: entries.dbk:230
@@ -718,7 +718,7 @@ msgstr ""
 #. type: Content of: 
 #: entries.dbk:327
 msgid "Become another user, e.g. root."
-msgstr "Convertirse en otro usuario, por omisión en root."
+msgstr "Convertirse en otro usuario, por defecto en root."
 
 #. type: Content of: 
 #: entries.dbk:331
@@ -1291,7 +1291,7 @@ msgstr "Utiliza recursos de red SMB, consulta, sube y baja archivos, etc."
 #~ "interfaces y options."
 
 #~ msgid "Defines default virtual host."
-#~ msgstr "Define el servidor virtual por omisión."
+#~ msgstr "Define el servidor virtual por defecto."
 
 #~ msgid "Database (PostgreSQL)"
 #~ msgstr "Base de datos (PostgreSQL)"
-- 
1.9.1

>From d6a8271c769fb671c39bd2ecf20809590246bf1e Mon Sep 17 00:00:00 2001
From: Octavio Alvarez 
Date: Thu, 6 Aug 2015 11:26:36 -0700
Subject: [PATCH 3/9] es.po: Replace "substituir" with "sustituir"

Both are accepted but the "sus-" form is the recommended form.

Reference:
* http://lema.rae.es/dpd/srv/search?key=sustituir

Signed-off-by: Octavio Al

Bug#782001: general: access granted to /home files of another user

[Octavio Alvarez]

On 04/06/2015 08:20 AM, Adam Borowski wrote:

On Mon, Apr 06, 2015 at 12:46:30PM +0200, Björn wrote:

* What led up to the situation?
Created new user from a non-root account (using root password prompt within
non-root account).
Started that new user.
Tried to read files from /home of first user.
Succeeded.


This is not an error, works as designed.  You can "dpkg-reconfigure adduser"
to change this behaviour for newly added users (ie, not the first one),
existing users' homes need manual chmodding.


What about sane defaults? It could also be dpkg-reconfigured the other 
way around.


Best regards.


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

Bug#781904: [Pkg-dia-team] Bug#781904: Export to png gets text width wrong

[Octavio Alvarez]

On 04/04/2015 08:59 AM, Goswin von Brederlow wrote:

> In the PNG export some boxes are too small for the text they contain.

Hi. Can you please provide a sample diagram (in Dia format) and its
exported PNG version? [*] Also, which of all the available PNG export
filters is the one showing this behavior?

You mention "some boxes". Can you identify what kind of boxes are the
ones that get exported too small? Or, seen from another perspective,
what font, size and weight is the one being rendered too wide? Can you
narrow it down as if it is a specific kind of box or a specific kind of
font?

All this info will help find the root cause for the bug and be able to
fix it.

[*] Please remember that your sample document will be made publicly
available, so you may need to create a version that does not containt
sensitive information.

Thanks.


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

Bug#769907: A small suggestion on constructive engagement [Was, Re: Bug#769907: general: non-sysvinit init systems are made of fail]

[Octavio Alvarez]

On 19/11/14 21:32, Steve Langasek wrote:
>> 1) the problem with new feature in systemd which considers all 
>> filesystems in fstab vital for system boot and stops boot if they
>> fail. It's been decided that although it is a change in behaviour
>> that might render some systems unbootable it's technically correct
>> implementation and only enforces that non-vital filesystems are
>> marked as such in fstab which should have been the case from the
>> start.
>> 
> As regards the two issues you've described: the first is not a bug.
> It's a necessary change in how we view the boot in a truly
> event-driven system. There is no sane default policy for how to
> interpret entries in /etc/fstab on upgrade except to regard them as
> all mandatory - *but* it's important that the admin be given the
> opportunity to intervene to override this policy.

Question: is it safe to say that systemd doesn't yet support the full
/etc/fstab specification from util-linux [1]?

[1] man 5 fstab

Thanks.


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

Bug#714296: How about manually integrating the upstream patch?

[Octavio Alvarez]

Hi.

It appears that upstream has not released Dia 0.97.3 yet, and it may
take a while. Would it be possible if the Debian Dia Team picks the
patch that fixes this before Jessie is released?

https://git.gnome.org/browse/dia/commit/?id=226fb87f34d4b49e700fb9cb340b49b67fd59540

Of course, the patch would have to be dropped once the next version is
released for it not to FTBFS, but Dia would become useful again in the
meanwhile, with benefit to all Debian-derived distributions. If we
waited for the correct thing to happen, who knows when the kerning bug
be fixed by the Pangocairo team.

I attempted to pick the patch myself for the current version of the
Debian Dia package. I am attaching the resulting dquilt patch.

I tested debuild -us -uc and it builds. I installed the result to in
system and it behaves correctly.

Thanks.
--- a/plug-ins/cairo/diacairo-renderer.c
+++ b/plug-ins/cairo/diacairo-renderer.c
@@ -315,6 +315,15 @@
   DIAG_STATE(DIA_CAIRO_RENDERER (self)->cr)
 }
 
+/* There is a recurring bug with pangocairo related to kerning and font scaling.
+ * See: https://bugzilla.gnome.org/buglist.cgi?quicksearch=341481+573261+700592
+ * Rather than waiting for another fix let's try to implement the ultimate work
+ * around. With Pango-1.32 and HarfBuzz the kludge in Pango is gone and apparently
+ * substituted with a precision problem. If we now use huge fonts when talking
+ * to Pango and downscale these with cairo it should work with all Pango versions.
+ */
+#define FONT_SIZE_TWEAK (72.0)
+
 static void
 set_font(DiaRenderer *self, DiaFont *font, real height)
 {
@@ -327,7 +336,7 @@
 
 #ifdef HAVE_PANGOCAIRO_H
   /* select font and size */
-  pango_font_description_set_absolute_size (pfd, (int)(size * PANGO_SCALE));
+  pango_font_description_set_absolute_size (pfd, (int)(size * FONT_SIZE_TWEAK * PANGO_SCALE));
   pango_layout_set_font_description (renderer->layout, pfd);
   pango_font_description_free (pfd);
 #else
@@ -714,14 +723,17 @@
 pango_layout_iter_get_line_extents (iter, NULL, &extents);
 shift = alignment == ALIGN_CENTER ? PANGO_RBEARING(extents)/2 :
 alignment == ALIGN_RIGHT ? PANGO_RBEARING(extents) : 0;
+shift /= FONT_SIZE_TWEAK;
+bline /= FONT_SIZE_TWEAK;
 cairo_move_to (renderer->cr, pos->x - (double)shift / PANGO_SCALE, pos->y - (double)bline / PANGO_SCALE);
 pango_layout_iter_free (iter);
   }
   /* does this hide bug #341481? */
-  pango_cairo_update_context (renderer->cr, pango_layout_get_context (renderer->layout));
-  pango_layout_context_changed (renderer->layout);
+  cairo_scale (renderer->cr, 1.0/FONT_SIZE_TWEAK, 1.0/FONT_SIZE_TWEAK);
+  pango_cairo_update_layout (renderer->cr, renderer->layout);
 
   pango_cairo_show_layout (renderer->cr, renderer->layout);
+  /* restoring the previous scale */
   cairo_restore (renderer->cr);
 #else
   /* using the 'toy API' */

Bug#734617: #734617: cppcheck: new upstream version available

[Octavio Alvarez]

Hi.

Upstream for libtinyxml-2 accepted to use release tags on Github to
track version changes.

The Debian maintainer updated the Debian libtinyxml2-0.0.0 package and
is now available in unstable. This includes some changes that cppcheck
1.63 needs to compile.

So, it may be possible that 1.63 will compile again without requiring
modifications to the package and, instead of using the embedded copy of
TinyXML-2, using the Debian tinyxml2-0.0.0 package.

This should make it easier to have cppcheck 1.63 in the archive.


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

Bug#738700: libtinyxml2-0.0.0: An update to libtinyxml2-0.0.0 is needed

[Octavio Alvarez]

Upstream has accepted [1] to have releases by using tags [2] on the
Github repository:

[1] https://github.com/leethomason/tinyxml2/issues/31
[2] https://github.com/leethomason/tinyxml2/releases

This should help keep track of compatibility changes. Please consider
updating this library.

Thanks.


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

Bug#734617: new upstream cppcheck version

[Octavio Alvarez]

Hi.

There is a team (I think is the Debian Security team) that must be  
notified of this, the decision of using the embedded copy of the  
library.


The reason is that if some one finds a security bug in the library,  
embedded copies must be updated individually and manually.


Octavio.

(Written on my phone. Please excuse my brevity and if some error went  
through.)


On 13/03/2014, at 03:54, Gianfranco Costamagna > wrote:



Hi again Octavio and Reijo,

I was packaging the new release before looking at this bug and I did  
things a little bit differently.



Since the rules override was because of the debian library and since  
this library doesn't work anymore (incompatibility) I dropped  
everything from debian/rules, the CPP flags have been merged  
upstream, the man page command too and the libraries are already  
correctly handled in the Makefile.


the rules/build is now
"dh_make
make man"

and nothing more.

I also added this bug reference in changelog and uploaded on mentors  
[1].


I offer myself in comaintaing the package if needed, I would like to  
take care of it


[1] https://mentors.debian.net/package/cppcheck

thanks,

Gianfranco


--
To unsubscribe, send mail to 734617-unsubscr...@bugs.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#739202: avoid embedded copy of oui.txt

[Octavio Alvarez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/16/2014 09:51 AM, Luciano Bello wrote:
> Please, consider depends on ieee-data [1] instead of include the 
> file /usr/share/ipv6toolkit/oui.txt

Thank you for packaging ieee-data. It will certainly be useful.

This suggestion will most probably be picked up in the next revision
of the Debian package.

Saludos.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJTDiUsAAoJEDsli1MUcl7IlAcP/idby02rxLX/5A+VKwBkZ46r
6PZIe7tHq/zLLRGttAIWy/N/ulgAQ4XH58Kqac4RC4+ItiGgWL7VZiI0FN6wTR/6
CvWk5FCtgb7QYhRPKJUFbLsNfRkv7XRZUg2u2FWC6/zxKf4jBJEUVtj1sXl3qL2+
C3A1wDBdQv6vTlQ4FgFs1rMQO6/v8KISa7bfttIXytcoKudMs3RT4ZqhGKeyaFHD
6VeWwkkFEW8Ye8C7mXMQz3uHcQQujaYAg+DCOKodjNqGbXFjbh3WY78YtdX1EdCz
eAANb5jWGMSVhMO1eD5tdeIwUmBSTnYzzmAma6a1H1agoYLSRQU7mb8Y+rHFROVS
IDVhiIbq3R9a+HDwtmh2+pMTUSiTo+GnfLDGEHWLvKA3sAqWgBeQDb+WKx7VPQ/n
WqWuBTYOuAE1s91ke9q0CIbLH1K1EtgSBYVzcjliYm7un4Jp2N5lfYbJO6fKdZ4z
6Kg3mT4wy1LSZeQX3iDiO0dvHc0tuhWUklIHVexdYzvMCqAvEzTfQBA8qFgY/bjV
fl/P8jitdt+tYO270jJUlc0V1tKZnq14KaHB4qh7tdZVyUZIYipuH6ZFWLQHef6c
1rZ2QsZc5YWrsJQQ2pNINKQ7ygnCthclKd4vYIjYl/SYSoGloVL6/QJOPy2fY3S4
B/H8btHryE4uRw6TVLfJ
=l5ng
-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#735502: Sourceless file (BTS 735502)

[Octavio Alvarez]

Hello, dear maintainer.

I'm attaching a patch to remove htdocs/ from cppcheck's source package.
This should get rid of the website altogether and fix this bug.

There is a script called runastyle that still reference htdocs/ but I
didn't find a reference to it anywhere. I don't know how to fix this yet.

I provide this in the hope to help prevent cppcheck from being removed
from Testing. I frequently use cppcheck.

After doing these changes I had to use uscan to re-download the current
version and have it recreate the new, dfsg-compliant package. I ran
debuild -us -uc over a directory with htdocs/ removed and it worked.

Thanks.
diff -Nur cppcheck-1.61/debian/changelog cppcheck-1.61+dfsg/debian/changelog
--- cppcheck-1.61/debian/changelog	2013-08-04 01:04:20.0 -0700
+++ cppcheck-1.61+dfsg/debian/changelog	2014-02-11 23:43:41.397027340 -0800
@@ -1,3 +1,11 @@
+cppcheck (1.61+dfsg-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Removed htdocs from source package to prevent licensing issues with
+sourceless JavaScript files.
+
+ -- Octavio Alvarez   Tue, 11 Feb 2014 23:42:57 -0800
+
 cppcheck (1.61-1) unstable; urgency=low
 
   * New upstream release
diff -Nur cppcheck-1.61/debian/copyright cppcheck-1.61+dfsg/debian/copyright
--- cppcheck-1.61/debian/copyright	2013-01-19 12:32:08.0 -0800
+++ cppcheck-1.61+dfsg/debian/copyright	2014-02-11 23:41:59.366091810 -0800
@@ -1,6 +1,7 @@
-Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=166
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: cppcheck
 Source: https://sourceforge.net/projects/cppcheck
+Files-Excluded: htdocs
 
 Files: *
 Copyright:
diff -Nur cppcheck-1.61/debian/watch cppcheck-1.61+dfsg/debian/watch
--- cppcheck-1.61/debian/watch	2011-02-06 10:20:48.0 -0800
+++ cppcheck-1.61+dfsg/debian/watch	2014-02-11 23:42:23.953835291 -0800
@@ -1,2 +1,2 @@
 version=3
-http://sf.net/cppcheck/cppcheck-(.+)\.tar\.gz
+opts=dversionmangle=s/\+dfsg// http://sf.net/cppcheck/cppcheck-(.+)\.tar\.gz

Bug#734617: Compilation of 1.63 fails on cppcheck

[Octavio Alvarez]

Hi.

I tried compiling cppcheck 1.63 but I was not successful. A newer
version of TinyXML-2 is needed. I submitted a bug report to
libtinyxml2-0.0.0 maintainer with this request.

In the meanwhile, cppcheck 1.63 compiles if their own tinyxml2
implementation (included in externals/tinyxml2) is used.

Attached is a patch that lets me compile cppcheck 1.63 using its own
copy of tinyxml2.
--- cppcheck-1.61/debian/rules	2013-08-04 10:05:47.0 -0700
+++ cppcheck-1.63+dfsg/debian/rules	2014-02-11 11:34:06.399181350 -0800
@@ -14,7 +14,7 @@
 
 override_dh_auto_build:
 	sed -i.nocppflags -e 's/\$$(CXX) \$$(CXXFLAGS)/$$(CXX) $$(CPPFLAGS) $$(CXXFLAGS)/' Makefile
-	dh_auto_build -- HAVE_RULES=yes TINYXML=-ltinyxml2 INCLUDE_FOR_LIB=-Ilib INCLUDE_FOR_CLI=-Ilib INCLUDE_FOR_TEST="-Ilib -Icli"
+	dh_auto_build -- HAVE_RULES=yes INCLUDE_FOR_LIB="-Ilib -Iexternals/tinyxml" INCLUDE_FOR_CLI="-Ilib -Iexternals/tinyxml" INCLUDE_FOR_TEST="-Ilib -Icli -Iexternals/tinyxml"
 	$(XP) $(DB2MAN) man/cppcheck.1.xml
 
 override_dh_auto_clean:
@@ -22,10 +22,10 @@
 	[ ! -f Makefile.nocppflags ] || mv -f Makefile.nocppflags Makefile
 
 override_dh_auto_test:
-	dh_auto_test -- HAVE_RULES=yes TINYXML=-ltinyxml2 INCLUDE_FOR_LIB=-Ilib INCLUDE_FOR_CLI=-Ilib INCLUDE_FOR_TEST="-Ilib -Icli"
+	dh_auto_test -- HAVE_RULES=yes INCLUDE_FOR_LIB="-Ilib -Iexternals/tinyxml" INCLUDE_FOR_CLI="-Ilib -Iexternals/tinyxml" INCLUDE_FOR_TEST="-Ilib -Icli -Iexternals/tinyxml"
 
 override_dh_auto_install:
-	dh_auto_install -- HAVE_RULES=yes TINYXML=-ltinyxml2 INCLUDE_FOR_LIB=-Ilib INCLUDE_FOR_CLI=-Ilib INCLUDE_FOR_TEST="-Ilib -Icli"
+	dh_auto_install -- HAVE_RULES=yes INCLUDE_FOR_LIB="-Ilib -Iexternals/tinyxml" INCLUDE_FOR_CLI="-Ilib -Iexternals/tinyxml" INCLUDE_FOR_TEST="-Ilib -Icli -Iexternals/tinyxml"
 
 %:
 	dh $@

Bug#738700: libtinyxml2-0.0.0: An update to libtinyxml2-0.0.0 is needed

[Octavio Alvarez]

Package: libtinyxml2-0.0.0
Version: 0~git20120518.1.a2ae54e-1
Severity: normal

Dear Maintainer,

Due to some updates to TinyXML-2, newer versions of cppcheck won't
build. Specifically, the XMLParser constructor has a new optional
parameter which is used by cppcheck.

Please consider packaging a newer version of TinyXML-2.

Thank you very much.


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

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

Versions of packages libtinyxml2-0.0.0 depends on:
ii  libc6  2.17-97
ii  libgcc11:4.8.2-10
ii  libstdc++6 4.8.2-10
ii  multiarch-support  2.17-97

libtinyxml2-0.0.0 recommends no packages.

libtinyxml2-0.0.0 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#736105: Sourceless file

[Octavio Alvarez]

This page describes where it can be found:

http://freemind.sourceforge.net/wiki/index.php/Flash_browser#Source_code


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

Bug#496894: [PATCH] add a default Subject to the "Reply" link in the web interface

[Octavio Alvarez]

Hi!

Any news on this request?

I just missed putting a useful subject it in another report and people
rightfully corrected me. I thought adding ?subject=X to the Reply
link would help automate this and be easy to implement.

I'm glad to see somebody reported it before and even submitted a patch.

Thanks.


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

Bug#668573: coreutils: coreutils-dbg

[Octavio Alvarez]

On 10/06/2013 01:13 PM, Michael Stone wrote:
> On Sun, Oct 06, 2013 at 11:33:17AM -0700, Octavio Alvarez wrote:
> You seem to be creating overcomplicated possibilities. If we were to
> create a -dbg package, here's what would be different:

Only in my particular case, which inolves timeout and timer_create; but
please see the big picture. The whole point of this discussion is not to
fix my particular case, but to explain why it could have been important
and useful to an outsider to have the coreutils-dbg package. My case
might was an extremely simple one, and even with that, resulted in
overcomplication.

> Syscall param timer_create(evp) points to uninitialised byte(s)
>   at 0x4E36E1A: timer_create@@GLIBC_2.3.3 (timer_create.c:83)
>   by 0x402607: settimeout (timeout.c:144)
>   by 0x4022C5: main (timeout.c:468)
> Address 0x7ff0006b0 is on thread 1's stack
> 
> instead of:
> 
> Syscall param timer_create(evp) points to uninitialised byte(s)
>   at 0x4E36E1A: timer_create@@GLIBC_2.3.3 (timer_create.c:83)
>   by 0x402607: ??? (in /usr/bin/timeout)
>   by 0x4022C5: ??? (in /usr/bin/timeout)
>   by 0x5278994: (below main) (libc-start.c:260)
> Address 0x7ff0006b0 is on thread 1's stack

That was my expected result, yes.

> Does that make it any less necessary to look at the coreutils source?

No, but it surely makes it easier because it grounds away any uncertainty.

> FWIW, if you build from the debian package, you could run the relevant
> program out of the build directory, where it is not stripped. No need to
> "hack it" to strip the symbols; alternatively, you can build with the
> nostrip build option if you want to create a .deb.

A-ha! I didn't know that, thanks! Had I known I'd gone to that since the
beginning. These are the kind of stuff that would just make it slower
for me (and who knows how many others) than just being able to install
the package and be done with *this part* of the debugging process.

> But, as pointed out
> above, this isn't really going to tell you anything that a quick grep
> would not--timer_create is only called once in the timeout program..

Sure, I did it that way after finding out coreutils-dbg was not
available, and I found it unnecessary; most importantly, I did not have
enough certainty about what I was doing. Also, I wanted to breakpoint
inside timeout with gdb to make sure I was following the correct
execution path, but this turned out not possible at first glance, hence,
by bump on this report.

>> Each step that I have to learn as I go has a set of variables, and
>> each variable makes the problem more complex until I the time and work
>> needed is greater than my interest. I was initially willing to debug
>> and attempt a fix but now I'm not sure anymore.
> 
> See above. Now that you have the additional information that would be
> present in the -dbg package, does it help?

It helps a lot. It gives certainty to outsiders when debugging. There is
little *effective* difference, but it importantly lowers my contribution
barrier of entry.


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

Bug#668573: coreutils: coreutils-dbg

[Octavio Alvarez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/06/2013 09:24 AM, Bob Proulx wrote:
> You were claiming that reports were being rejected due to lack of
> a full backtrace.  This shocked us.  I haven't ever seen such
> cases. That isn't how it works.  We were asking for examples so
> that we could address the problem.  That is the next step.  Collect
> data.  And being part of upstream means that we could make amends
> for any just grievance.  But no examples have been provided.  I
> think you are thinking of a different upstream group.  Therefore
> that claim is completely unjustified for coreutils.

Oh! I should have chosen better words. Sorry about that.

I was speaking generically, not specifically about coreutils.

I have never touched coreutils upstream. I have touched other
upstreams, seen bug reports and how the reports just get forgotten
because of lack of information. Lack of symbols is a *typical* case.
My claim was that it happens so often in so many projects that I just
assumed it will happen everywhere.

It means that the standard practice of providing full information is
not possible with stock Debian and standard Debian practices in this
particular situation. Yes, I'm aware that I can download and compile
the source myself. I just thought this would not have been necessary,
that the lack of coreutils-dbg was just an omission, not deliberate.

I did not mean to claim rejection of patches from coreutils; sorry
about that.

>> But we digress. In breaf, what you are saying is: WONTFIX, is
>> this correct?
> 
> So far in this thread we have been discussing the justification for
> a dbg package.  And so far in the thread as far as I can read there
> has not been any justification for it.  (Apart from the original
> bug submitter.)  Without justification for it then I expect it will
> likely be that the dbg package won't happen.

As the discussion has evolved and I have learned more, my point is now
pretty much the same: a bug on eglibc. I was testing an app with
"valgrind timeout ./app" so problems that did not belong to my app
started appearing on the valgrind report. Fortunately I just did
"timeout valgrind ./app" instead.

However, this misstep revealed a leak in timer_create() from eglibc,
which I wanted to debug. This leak is most probably even affecting
your machine.

I have never used timer_create(). I currently don't know how to. I
will learn as I go. Most probably I will get it wrong the first N
times, so debugging with timeout is *by far* easier.

It's this simple: instead of "apt-get install coreutils-dbg" I have to
recompile coreutils (which may imply installing other packages). Oh,
wait, because it is not guaranteed to work in the exact same way (lack
of Debian patches). To guarantee it use the Debian package, so now I
have to hack it to not strip the symbols. It may be easy, but I don't
know how yet. Another thing to learn as I go.

Each step that I have to learn as I go has a set of variables, and
each variable makes the problem more complex until I the time and work
needed is greater than my interest. I was initially willing to debug
and attempt a fix but now I'm not sure anymore.

Just search for "timer_create() leak" in Google. You'll find a lot of
instances where people just suppresses or ignore the error because it
lies outside of their skill set. Many many applications now have this
leak.

In conclusion: your delimitation of "worth it or not" is leaving out
at least one long-reaching and important possibility. I spoke about
it, that doesn't imply I am the only one facing it.

That was my best shot. :)

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

iQIcBAEBAgAGBQJSUaztAAoJEDsli1MUcl7If80P/RkCR5NauOdSdffAroqgp0XH
e+EfMDQMiWrV+b0kLqja7Lp2JN/MGh+/qcJZ/fgwcovGsP/k/lOOYjGI0vhp6Z/O
quuzeYOCpXu/B/f/g1W/rwBD8YLd+P9lju8fxuxVx8ZbkbQNIo5mAJK0MVOgBL/t
yTWy5RERHKwqzNZsDwKljQ1QDL4Ae4XVIZddc3FNbVow7LlMjff0g1I3lXWWl0Q4
urZ7qU3Ltoxtac7rmhI0hIzJ5P8z5V4CKiEaB+78ZkIiv0fdcw1UTc7QkE/rMj+4
vp08DHC/g30PHJd7zq0fEjDKvNr9cYVqBdqx2wI92q0dDp4CWIYcFGYQRocVkKhj
Fm/hLfbNPj0Vcywx5MS7PUv2yW8uo3XKVXRkgd5bb3dpzitfvyHQOxpAqfjyrEEp
lr7OVPdhqLj2WvzaWrT1S0wvKE7/5R9LFDabUphyQZ36YkIAG0wE7MjJPrqw1Gu9
UQaBOFsBnMnm1HO4Dvpvoaao5T8r4kjqI8nToBOEesCPVvwVALwm9EVM8U0c0458
OVTV8O6WojWEHb05WOh8S+rjqi2oM9gEMDzjGbzrxxYIrclX/oBKCzDSw4CUATHk
w2nK84NkLsGwm+rCVw4EDsj6GXo4wkLg+qoH6ErXa0lruMmDGfumLetQiwKKaerg
+2CUermSHkdCEO2VL59K
=Ukyc
-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#668573: coreutils: coreutils-dbg

[Octavio Alvarez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/05/2013 10:51 PM, Bob Proulx wrote:
> Octavio Alvarez wrote:
>> Reporting the bug has turned pointless now; you know what
>> happens: incomplete debugging information makes it more difficult
>> for upstream. That's why if I report a bug without a full
>> backtrace, chances of the bug being disregarded as NEEDINFO raise
>> significantly. And upstream will just blame the reporter.
> 
> Which coreutils bug are we talking about here?

The one that I found to be in eglibc (and not coreutils' timeout): the
8-byte memory leak. This is not the same I mentioned earlier, but also
discovered via timeout.

==10767== 8 bytes in 1 blocks are definitely lost in loss record 1 of 1
==10767==at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10767==by 0x4E36FC4: timer_create@@GLIBC_2.3.3 (timer_create.c:63)
==10767==by 0x402607: ??? (in /usr/bin/timeout)
==10767==by 0x4022C5: ??? (in /usr/bin/timeout)
==10767==by 0x5278994: (below main) (libc-start.c:260)

(Should I stop CC-ing 668573? This is getting off-topic.)

> I looked for your address in the upstream lists but didn't see it 
> after a very brief search.  Perhaps I missed something?

No, I'm not part of upstream (eglibc nor coreutils).

But we digress. In breaf, what you are saying is: WONTFIX, is this
correct?

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

iQIcBAEBAgAGBQJSUQjyAAoJEDsli1MUcl7IT7QQALA5bSBzDAe4HRD18y4lZ2ch
krkF/t4b8lWDzpp27USJAptTgTn6OIEmL38MSpDhrLdTPNO6UJOKVyGOFaVWaYiV
RSsNE2yGnTccHstJ7+dYHsWq04qAKXZ7jaH7Gbev8TKqttSoEtzoznZXY8eKGuMh
SDpfmjVfN9J98r4zM2ACUEaga2l0m+sMeuqfMWUvNYhBYpMc+rYUZJA06mGiEIH7
I0UrsVui6Aepw50FchidgyHhCA2OL3mtnDlp6S7119mfx4KK9Snj+UahmmeGX9WF
pPlLWqhywu+iFkYmt8X4i9VTMOul3XEiuY6+/6RXMAyKYyZBgtV3oYD8HncPD0XV
vxp2OANn4chzfa5duYmr+mwVoI2Pwi+SJgkZfnyqiUgOb/AzWYHtPaYNOJwezdNE
pLZk6rijYeiTZKfrci8JaFm4Vv6+u/2lQFSBeJiUMwJJNC4kUcWssTHpjy+jKuOK
AnFJnqXIGwHU/XSRzEP4TNvPyoGFWAjrqsu2M+JDDX1Q+zPpPUHbFkhMKpmYQk3+
21lcvjxy/Bgt54Q1GyROetS6fu8KZ4bBDehwzGkP+BJfKZ2TVRjWOYDoPkFxWmsi
atPQfMO/RmBCAmTxze5DzChtirVmpXM8psyrYgaFmTzCu9SNzP/qSmfJKqxHYhUX
LmU3Kh/E+B9U6ld6CxDo
=NxfD
-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#668573: coreutils: coreutils-dbg (was: Any news on this bug)

[Octavio Alvarez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/05/2013 05:54 PM, Bob Proulx wrote:

> Hmm...  Regarding valgrind...  The coreutils gets run through
> valgrind routinely.  There are always lots of false positives.

Well... in this case the 8-byte unfreed region is not. The bug
apparently lies in eglibc, though.

About the uninitialized bytes, I don't know yet. It *looks* like a
false positive, but can't yet assert it.

>> But anyway, that was not even the point. The point was that
>> debugging and bug reporting is difficult because there are no
>> symbols to provide complete backtraces to developers.
> 
> Is there anyone that doesn't have the source code available?  By
> the time I am geared to up to debug something in coreutils I always
> have the source code available and will use it for the debugging.
> I am not sure there will be much return on investment for the work
> to create and maintain a dbg package.

I really don't know how much work is needed to create a -dbg package,
and I don't have the time to do it either. I know it is hard work and
I am certainly not demanding it. But just let me explain why it is
more important than just blowing it off with "meh... I don't think
it's not worth it".

Source code is good enough to do development, but not to encourage it.

Sure, I can check the source code... but once it starts to get harder
than my current skills I will just give up on it. At this moment, my
current skills include investigating and providing a good bug report,
even possibly to upstream. My skills don't include, yet, understanding
the exact implications of the INTERNAL_SYSCALL macro, for example.

Reporting the bug has turned pointless now; you know what happens:
incomplete debugging information makes it more difficult for upstream.
That's why if I report a bug without a full backtrace, chances of the
bug being disregarded as NEEDINFO raise significantly. And upstream
will just blame the reporter.

So "return of investment" is not delimited to you; it is for the whole
community. You help me, I help upstream, easier to have the bug fixed
for everybody ("everybody" >= Debian).

I'm also wondering if it is at all feasable that debuild automatically
creates it.

> And by the way...  It would be nice if the original subject were 
> maintained.  With just a ping about a bug number it means everyone 
> needs to go look up the bug number.  It would be nicer if it the 
> subject had told us coreutils-dbg as in the original report.

Will surely keep that in mind and suggest an easy fix to the Debian
BTS: append ?subject=SUBJECT to the "Reply" link. Thanks for pointing
it out.

Thanks.


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

iQIcBAEBAgAGBQJSUMeyAAoJEDsli1MUcl7I1R0P/0oTIOaHvRUyklpXX+hvImsq
MlRKeNJyn4aww3J9VQZSKaQ0BPkIVc16f0GQUS51gnmg2GJ20h71bvI0xrXTB0pq
lbkc0bf7iXv9MeWI9FKwQ2ou/KSFZdb6CCmB5nsKp4UXKEXSkrA3iBxtVGW33zly
+eoURodjaBqEAalqOjwcj0geS4+oCzJYCzJ3e1sFtzST2X5SsWDBZ6kKT1bt0XyM
9iUvftVTJ/f4by3wRWD0ls21mjvpwoqxjNcrWb4Dj6+OegCDsIYGYaMS1y1bvWwD
1P0b5iOobOYCyaQhx3nxdsjoz4iZda4OCpommQ8enavzlhLniiYvxmSwHY1liW8f
ffy6/u+/uUjV3KbBUDB6hJtK8H6yjE9+oPUPYTEccJpy8pg6+8dS4JLQJVh74doU
vDtoH6+qmLJjiVdS6qGYN2ANgLi4K3j0yBenIulgZASvSfTDbLxNlG3dXZiImayi
xyI4Vc+dtZT0wo9yBSLvHOv/aoPsPTOqrdovC5U94esfVNgcT8oRRULISfL7yypO
fPYhzVCRV8Z6GGUGWczgKp4coOWZ0mPOsSgKNJeyX/6CBmuXnldbNEExWa7zvB7n
lw0Wn6/h5uqoNodA65rD7VZRo4kGeFXuANXJctHt6QQkedb+n4QfxK0ozohrIole
ivh5GEu2R0z05pOz3828
=7HJa
-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#668573: Any news on this bug

[Octavio Alvarez]

On 10/05/2013 01:47 PM, Michael Stone wrote:
> Looks like a noise result. Definition of timer_create is:
> 
> int timer_create(clockid_t clockid, struct sigevent *sevp, timer_t
> *timerid);
> 
> coreutils has:
> 
> timer_t timerid;
> if (timer_create (CLOCK_REALTIME, NULL, &timerid) == 0)
> ...
> 
> So, yeah, timerid is unitialized--because it's just an allocated memory
> location for timer_create to initialize and return a value in.

Well, Valgrind says "timer_create(evp)", not timerid and the problem
apparently relies *inside* eglibc.

But anyway, that was not even the point. The point was that debugging
and bug reporting is difficult because there are no symbols to provide
complete backtraces to developers.


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

Bug#668573: Any news on this bug

[Octavio Alvarez]

On 10/05/2013 12:30 PM, Michael Stone wrote:
> On Sat, Oct 05, 2013 at 10:21:55AM -0700, you wrote:
>> I'd like to ask if there is any updates on this bug.
> 
> I see a big downside in potential complexity and fragility for the
> system without much upside. The only use case cited ended up being a
> library problem rather than a coreutils problem. Is there a better use
> case which would suggest that there's a good benefit to doing this?

Well, just today I found valgrind is reporting a "points to
uninitialised byte" and "definitely lost: 8 bytes in 1 blocks" in the
timeout tool.

Without -dbg, this is what I get in valgrind:

==32492== Syscall param timer_create(evp) points to uninitialised byte(s)
==32492==at 0x4E36E1A: timer_create@@GLIBC_2.3.3 (timer_create.c:83)
==32492==by 0x402607: ??? (in /usr/bin/timeout)
==32492==by 0x4022C5: ??? (in /usr/bin/timeout)
==32492==by 0x5278994: (below main) (libc-start.c:260)
==32492==  Address 0x7fefffe80 is on thread 1's stack

... which is useless to the devs (or even me, if I wanted to try fixing
it out).

Otherwise, "valgrind --leak-check=full timeout 30 ./app-to-test" will
always give me false positives that don't even have to do with app-to-test.

Thanks.


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

Bug#668573: Any news on this bug

[Octavio Alvarez]

Hi.

I'd like to ask if there is any updates on this bug.

Thanks.


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

Bug#522741: ieee-data: not actually including oui.txt

[Octavio Alvarez]

Hi.

I'd like to ask if there was any progress on this. I'd like to package  
ipv6-toolkit but the licensing of oui.txt is "unclear" (to say the best).


there's "progress" in the sense that licensing terms for ieee data are  
not still clear


Some say that it is not copyrightable for being a list of facts [1],  
others say that databases are copyrightable in some places [2], and some  
claim to have written to the IEEE and received a negative permission on  
redistribution of the file [3].


[1] http://lists.debian.org/debian-legal/2006/02/msg00175.html
[2] http://lists.debian.org/debian-legal/2006/02/msg00208.html
[3]  
https://blog.flameeyes.eu/2012/04/who-said-that-ids-wouldn-t-have-license-issues


What if this package downloaded the data live from the Internet like the  
flashplugin-nonfree does?


--
Octavio.


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

Bug#647877: Bug#717123: RFS: superkb/0.22-5 [ITP #647877] -- keyboard launcher with on-screen hints

[Octavio Alvarez]

Hi.

I uploaded a new version for Superkb, the package for which I'm trying to
get sponsorship.

The new version is 0.22-5 and this is what I changed:

superkb (0.22-5) unstable; urgency=low

* Added lintian override for no-upstream-changelog, because it is not
in English and this has been fixed upstream. Next upstream release
will properly include a changelog and this override will be removed.
* Fixed man page invocation to help2man for proper text in the NAME
section.
* Moved sample-config/superkbrc to debian/ and removed the patch.
* Include sample config files under /usr/share/doc/superkb/sample-config.
* Improved man page superkb.1.

So, technically, the package has no more lintian --pedantic warnings
unattended, and hopefully the next upstream version will have most patches
directly incorporated (because upstream is me) so the package will become
simpler in the future.

Even though I'm asking for sponsorship, I'd really appreciate a review
even if it's not sponsored.

Thanks in advance.

Octavio.


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

Bug#681917: RFP: ipv6-toolkit -- a portable IPv6 security assessment suite

[Octavio Alvarez]

Hi,

I'm attempting to package ipv6-toolkit and seem to have
made some progress.

Some minor changes are needed, at least lintian-wise.


--
Octavio.


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

Bug#717123: RFS: superkb/0.22-4 [ITP #647877] -- keyboard launcher with on-screen hints

[Octavio Alvarez]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,
 
  I am looking for a sponsor for my package "superkb". ITP# is 647877.
 
 * Package name: superkb
   Version : 0.22-4
   Upstream Author : Octavio Alvarez 
 * URL : http://superkb.sf.net/
 * License : GPL v2
   Section : x11
 
  It builds those binary packages:
 
superkb- Hotkey-based application launcher with on-screen hints


  Here I paste the description at the ITP:

This is a program I wrote to enable key bindings to work with the
Super key. Holding down the Super key for N seconds shows a keyboard
on screen with hints about available bound keys. Configuration is
stored in a flat text file. You can bind arbitrary scripts to your
keys.

It has been helpful to me because I can easily replicate my bindings
to another PC and, so I have my keyboard full of shortcuts, I can
check them when in doubt.

The "magic" key (Super_L/R by default) is not hardcoded; you can use
any other magic key, for example, in laptops that don't have it (like
the T42) without losing the key (it gets replayed to the current
window).
 

  To access further information about this package, please visit the following 
URL:
 
  http://mentors.debian.net/package/superkb


  BTW, The only lintian warning I left unresolved is the lack of upstream
  changelog because of a bug in the upstream package, but it has already
  been worked out and will be fixed once a new version is released.
 
 
  Alternatively, one can download the package with dget using this command:
 
dget -x 
http://mentors.debian.net/debian/pool/main/s/superkb/superkb_0.22-4.dsc
 
  More information about superkb can be obtained from http://superkb.sf.net and
http://superkb.org/wiki
 
 
  Regards,
   Octavio Alvarez
 


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

Bug#647877: ITP: superkb -- Keyboard-based launcher with unobtrusive on-screen graphical hints.

[Octavio Alvarez]

retitle 647877 ITP: superkb -- Keyboard-based launcher with unobtrusive  
on-screen graphical hints.

owner 647877 !
thanks

I am attempting once again to package it. This time I have already
uploaded a version to mentors.debian.net. It can be found at the
following URL:
 * http://mentors.debian.net/package/superkb

I think it's ready. I will request sponsorship for this package.

There were some caveats on release 0.22 that required some patching
of the upstream code. These changes will be incorporated in the
next release of the program.

--
Octavio.


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

Bug#712441: tircd no longer works after Twitter removed API 1.0. Patch available.

[Octavio Alvarez]

Package: tircd
Version: 0.21.2-2
Severity: grave
Tags: patch upstream
Justification: renders package unusable

Dear Maintainer,

Since Twitter removed the 1.0 API on June 11th, tircd
is no longer useful. The daemon receives connections
but the user only gets errors.

Fortunately, a patch is available. Although not from
official upstream, somebody already made it work again
and pushed it to his personal repo.

The patch is at the upstream bug report at
 * https://code.google.com/p/tircd/issues/detail?id=106#c7

I can confirm the patch works.

There is no official release yet with the changes.

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

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

Versions of packages tircd depends on:
ii  adduser   3.113+nmu3
ii  libhtml-parser-perl   3.71-1
ii  libjson-any-perl  1.28-1
ii  libnet-twitter-lite-perl  0.12002-3
ii  libpoe-filter-ircd-perl   2.42-1
ii  libpoe-perl   2:1.3540-1
ii  liburi-perl   1.60-1
ii  libwww-perl   6.04-1

tircd suggests no packages.

-- Configuration Files:
/etc/default/tircd changed [not included]
/etc/tircd.cfg changed [not included]

-- 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#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Octavio Alvarez]

On Wed, 19 Dec 2012 11:35:50 -0800, Alan Stern 
wrote:


As far as the OHCI hardware is concerned, there shouldn't be any
difference between runtime suspend and system suspend.  This strongly
suggests that the bug doesn't lie in the controller itself but in the
firmware (BIOS or ACPI).


Is there a way we can help to look for such a failing pattern, more
directly related to BIOS/ACPI instead of the OHCI controller, in lspci,
dmidecode or some other tool?

--
Octavio.


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

Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Octavio Alvarez]

On Wed, 19 Dec 2012 08:57:00 -0800, Alan Stern   
wrote:



You, the stupid end-user, would not see this message at all under
normal circumstances.  It uses the ohci_dbg macro and therefore will
not appear unless your kernel is built with CONFIG_USB_DEBUG enabled.


Shouldn't it be exposed to dmesg?


--
Octavio.


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

Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Octavio Alvarez]

On Wed, 19 Dec 2012 07:29:23 -0800, Alan Stern   
wrote:

+   ohci_dbg(ohci, "marked as bad wakeup.\n");


I'd prefer the message to be something more like "enabled nVidia/SiS
wakeup quirk".


To me, the stupid end-user, both messages are useless. I don't know
that that means or implies. I would go with:

"Disabled OHCI wakeup (USB) due to faulty controller (no-wakeup.txt)"

and have a file named no-wakeup.txt under Documentation with this:

"
Users have reported OHCI misbehavior consisting on false wakeups right
after suspend to RAM on some OHCI controllers, particularly from nVIDIA
and SiS. For those controllers, wakeups has been disabled.

The system will not be able to wake up the system from suspend
to RAM from an OHCI (USB) device.

To see the list of affected controllers do:

grep -B 3 ohci_quirk_bad_wakeup linux-pm/drivers/usb/host/ohci-pci.c

Bug is tracked at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677472
"

--
Octavio.


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

Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Octavio Alvarez]

On Thu, 13 Dec 2012 00:45:05 -0800, Lan Tianyu 
wrote:


diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index f034716..9335f1b 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2509,7 +2509,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
 * they only forward requests from the root hub.  Therefore
 * controllers should always be enabled for remote wakeup.
 */
-   device_wakeup_enable(hcd->self.controller);
+   if (!usb_hcd_wakeup_quirks(hcd->self.controller))
+   device_wakeup_enable(hcd->self.controller);
return retval;

 error_create_attr_group:
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index fdefd9c..ba847d3 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -12,6 +12,7 @@
  */

 #include 
+#include 
 #include 
 #include "usb.h"

@@ -226,3 +227,33 @@ void usb_detect_interface_quirks(struct usb_device
*udev)
quirks);
udev->quirks |= quirks;
 }
+
+struct pci_hcd {
+   u32 vendor;
+   u32 device;
+};
+
+static struct pci_hcd hcd_wakeup_qrk[] = {
+   {PCI_VENDOR_ID_NVIDIA, 0x026d}, /* MCP51 OHCI */
+   {PCI_VENDOR_ID_NVIDIA, 0x0aa5}, /* MCP79 OHCI */
+   {PCI_VENDOR_ID_NVIDIA, 0x0aa7}, /* MCP79 OHCI */
+   { }
+};
+
+int usb_hcd_wakeup_quirks(struct device *dev)
+{
+   struct pci_dev *pdev;
+   int i;
+
+   if (dev->bus != (struct bus_type *)&pci_bus_type)
+   return 0;
+
+   pdev = to_pci_dev(dev);
+   for (i = 0; hcd_wakeup_qrk[i].vendor || hcd_wakeup_qrk[i].device; i++)
+   if ((hcd_wakeup_qrk[i].vendor == pdev->vendor) &&
+   (hcd_wakeup_qrk[i].device == pdev->device)) {
+   return 1;
+   }
+
+   return 0;
+}


I would informing the user via dmesg output about the applied quirk
and a point him to relevant documentation. Something like this:

"Detected OHCI controller ID :, which requires no-wakeup quirk.
See Documentation/quirks/ohci-no-wakeup.txt"


--
Octavio.


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

Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Octavio Alvarez]

On Thu, 13 Dec 2012 07:35:55 -0800, Frank Schäfer
 wrote:


I write a quirk patch. Can you test?


Yes, that makes it work !


I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy
hcd id via "lspci -nnvvv"?
Thanks.


I have the MCP61 (rev. A2) with id 10de:03f1.

Further NVIDIA OHCI HCD IDs can be found at
http://openbenchmarking.org/linux/PCI/0c03.
But I'm not sure that we should blacklist them all. Maybe this bug has
been fixed in newer chipset revisions / generations ?
Where did you get the ID for the MCP79 from ? Is it confirmed that this
device still suffers from the same bug ?

I also wonder if this could be an BIOS / ACPI issue.
So far, all boards I've seen were form ASUSTeK (Octavio: A8N-VM, me:
M2N-VM DH, and I remember having seen the same bug on another M2N board
with MCP55 a while ago).


These are 4 machines I found reported. I don't know what is the
exact PCI ID needed, so I compiled links and information.

MACHINE 1: DELL XPS 1340
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=43081

The bug doesn't have system information, but a search on the Internet
[1][2] suggest that it's an MCP79 chipset, integrated by Dell itself.
[1] http://ubuntuforums.org/showthread.php?t=1927427
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/969755

The lspci for [2] is at:
https://launchpadlibrarian.net/99189829/Lspci.txt


MACHINE 2 and 3: ASUS P4S8X and P4S8X-MX mainboards
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=47991
lspci: https://bugzilla.kernel.org/attachment.cgi?id=81331

Both are mostly unrelated to nVidia, except for the graphics card in one
of them. Both have SiS-based chipsets. Enough device information in bug
report.

MACHINE 4: ASUS 1201N
Bug: https://bugs.launchpad.net/linux/+bug/952080
lspci: https://launchpadlibrarian.net/96828581/Lspci.txt

Also an nVidia MCP79-based device. All device info in bug report.



--
Octavio.


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

Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Octavio Alvarez]

On Wed, 12 Dec 2012 12:28:16 -0800, Frank Schäfer  
 wrote:



Good information. Attaching device makes hc work abnormally during
entering into s3 since without device it can work, right?


Right.
The system successfully enters S3 (machine switches off = fan stops,
light off etc.) but it resumes immediately.
No errors in the log, it looks like this:


A while ago I did some tests, and I got no errors whatsoever, not even
with PM_DEBUG. System is successfully suspended but immediately awaken.

--
Octavio.


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

Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Octavio Alvarez]

On 10/05/2012 07:56 AM, Alan Stern wrote:

On Mon, 9 Jul 2012, Octavio Alvarez wrote:


What happens if you unplug only the keyboard, or only the mouse?


The only thing I can confirm for now is that with both disconnected
the system consistently suspends and that I have seen the system NOT
suspend with either one connected.

Having said that, I have also seen the system suspend, but I don't
quite trust these tests. I think I may have failed to make sure
the settings were appropriate for the test (wrong kernel or wakeup
disabled).


Did anything ever happen with this?



Well, there was the workaround:

echo disabled > /sys/devices/pci:00/:00:0b.0/power/wakeup

... which I applied on startup at /etc/rc.local and has worked 
beautifully for me since.


Further testing started to get us nowhere. As far as conclusions 
regarding hardware, we got to "the PC is doing something fishy or is 
weirdly wired up". I also concluded that it wasn't actually a 
"regression" because on 3.1, enabling "0:0:0b.0/power/wakeup" also made 
the system autoresume. It's just that the policy changed and that's how 
my system got broken, but the policy can be tweaked on /etc/rc.local.


I went on vacation and forgot after that.

However, I also started to distrust my pen drive, as it has been 
randomly acting up other Linux systems. This causes it to unmount by 
itself, throw journal errors, etc. Not sure if the pen drive is damaged, 
or the kernel has problem, as my iPhone does similar things sometimes 
and that's not damaged. In any case, conclusions drawn from the pen 
drive might be incorrect now and we might have to retest.


So, theories:

a. My MCP51 is damaged.
b. The MCP51 designer or manufacturer's brain is damaged.
c. The kernel programming is wrong for MCP51.

And options:

a. Somehow "blacklist" power/wakeup for this device and call it a day.
b. Continue testing the weird stuff until we squash the sucker, which 
I'm more than willing to do. We can re-test from scratch if necessary to 
rebuild the whole test matrix. I may need detailed instructions for some 
tests.


I would get a new pendrive just to get that out of the way. There are 
some cheap Kingstons out there I can get.


Thanks.


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

Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Octavio Alvarez]

On Sun, 08 Jul 2012 17:28:25 -0700, Alan Stern   
wrote:



>> Removing my pen drive cleared CCS on [6].
>
> Okay, that explains that.  More or less.  Is this an old USB-1.1 pen
> drive?  If it is USB-2.0 then I would expect it to connect to the EHCI
> controller, not the OHCI controller.

I don't know... Is there a way to know that? The device is a

Bus 001 Device 011: ID 0781:5406 SanDisk Corp. Cruzer Micro U3


That doesn't mean much by itself.  But the lsusb output you included
confirms that the pen drive was running at high speed -- which means
that it should never have been connected to the OHCI controller at all.
Another mystery.  It appears that your computer's USB hardware is kind
of funky.


Alan, take a look at this:

Bus#  2
`-Dev#   1 Vendor 0x1d6b Product 0x0001 Linux Foundation 1.1 root hub
  |-Dev#  18 Vendor 0x046d Product 0xc05a Logitech, Inc. Optical Mouse M90
  `-Dev#  19 Vendor 0x046d Product 0xc31d Logitech, Inc.
Bus#  1
`-Dev#   1 Vendor 0x1d6b Product 0x0002 Linux Foundation 2.0 root hub
  `-Dev#  18 Vendor 0x0781 Product 0x5406 SanDisk Corp. Cruzer Micro U3

For some reason, my USB drive is now on EHCI!


What happens if you unplug only the keyboard, or only the mouse?


The only thing I can confirm for now is that with both disconnected
the system consistently suspends and that I have seen the system NOT
suspend with either one connected.

Having said that, I have also seen the system suspend, but I don't
quite trust these tests. I think I may have failed to make sure
the settings were appropriate for the test (wrong kernel or wakeup
disabled).


--
Octavio.



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

Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Octavio Alvarez]

On Sun, 08 Jul 2012 07:40:49 -0700, Alan Stern 
wrote:


On Sat, 7 Jul 2012, Octavio Alvarez wrote:

On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern  


wrote:

>> roothub.portstatus [4] 0x0303 LSDA PPS PES CCS
>> roothub.portstatus [5] 0x0303 LSDA PPS PES CCS
>> roothub.portstatus [6] 0x0101 PPS CCS
>
> That's normal, except for the status of port 6 (which actually is port
> 7, since we normally count ports starting from 1).  The port shows
> Current Connect Status, so something is connected to it -- but what?

It looks like it was my pendrive. Disconnecting the mouse and keyboard
cleared CCS on [4] and [5] (not necesariliy in that order).

Removing my pen drive cleared CCS on [6].


Okay, that explains that.  More or less.  Is this an old USB-1.1 pen
drive?  If it is USB-2.0 then I would expect it to connect to the EHCI
controller, not the OHCI controller.


I don't know... Is there a way to know that? The device is a

Bus 001 Device 011: ID 0781:5406 SanDisk Corp. Cruzer Micro U3

Does it make sense to think that some ports are OHCI and some are
EHCI, particularly if some of them are on the back and some on the
front?


This is the continuation of the previous dmesg, starting on second 178,
when I pressed the power button.

(done without my pen drive)


The suspending part is normal.  The resuming part is not...


[  181.394398] usb usb2: usb resume
[  181.394403] ohci_hcd :00:0b.0: wakeup root hub
[  181.394426] usb usb1: usb resume
[  181.394430] ehci_hcd :00:0b.1: resume root hub
[  181.428035] ehci_hcd :00:0b.1: port 6 low speed --> companion


That shouldn't have happened.  It's not actually _wrong_, but it
indicates that the USB controllers did not maintain their states
properly while the system was suspended.


Considering that this happens while the system is already resuming,
do you think is in some way related with the bug?


[  181.472105] hub 2-0:1.0: port 6: status 0301 change 0003
[  181.524028] ehci_hcd :00:0b.1: GetStatus port:6 status 003402 0
ACK POWER OWNER sig=k CSC
[  181.540030] hub 1-0:1.0: hub_resume
[  181.540040] ehci_hcd :00:0b.1: GetStatus port:1 status 001020 0
ACK POWER sig=se0 OCC
[  181.540051] ehci_hcd :00:0b.1: GetStatus port:2 status 001020 0
ACK POWER sig=se0 OCC
[  181.540061] ehci_hcd :00:0b.1: GetStatus port:3 status 001020 0
ACK POWER sig=se0 OCC
[  181.540071] ehci_hcd :00:0b.1: GetStatus port:4 status 001020 0
ACK POWER sig=se0 OCC
[  181.540086] ehci_hcd :00:0b.1: GetStatus port:7 status 001020 0
ACK POWER sig=se0 OCC
[  181.540095] ehci_hcd :00:0b.1: GetStatus port:8 status 001020 0
ACK POWER sig=se0 OCC


These messages are highly suspicious.  They indicate a low-level
hardware problem in the wiring of the USB controllers or support
components.

I won't go into further detail.  The remaining events all seem to flow
from these underlying problems.

Just out of curiosity, what happens if you suspend with the mouse and
keyboard unplugged, i.e., no USB devices attached at all?  (To
forestall possible questions, you run a little shell script that sleeps
for 10 seconds, during which you unplug the keyboard and mouse, and
then initiates a system suspend.)


I'm using the power button to suspend and resume, so this test is
actually easy.

It's weird, but without K & M connected, even with the pendrive
connected, the system suspends! (The keyboard leds go off and all,
though)


Also, what happens if you unload ehci-hcd before suspending (with the
keyboard and mouse plugged in as normal)?


It doesn't suspend. I tested this a while ago. It's pretty much specific
to ohci_hcd.


Not sure if this is helpful but:

[Sun Jul 08 10:02:31 -0700 -- alvarezp@octavio:~]
$ sudo lsusb -

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB   2.00
bDeviceClass9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize064
idVendor   0x1d6b Linux Foundation
idProduct  0x0002 2.0 root hub
bcdDevice3.02
iManufacturer   3 Linux 3.2.0-3-686-pae ehci_hcd
iProduct2 EHCI Host Controller
iSerial 1 :00:0b.1
bNumConfigurations  1
Configuration Descriptor:
  bLength 9
  bDescriptorType 2
  wTotalLength   25
  bNumInterfaces  1
  bConfigurationValue 1
  iConfiguration  0
  bmAttributes 0xe0
Self Powered
Remote Wakeup
  MaxPower0mA
  Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting   0
bNumEndpoints 

Bug#680707: [3.4-rc5 -> 3.4-rc6 regression] Asus P5NSLI: lockup on resume from suspend

[Octavio Alvarez]

On Sun, 08 Jul 2012 02:04:32 -0700, Jonathan Nieder   
wrote:



So presumably it's the new writes to the ACPI_BITREG_ARB_DISABLE
register that cause trouble.  The patch below tests that guess.


Given the complexity of the ACPI_DEBUG logging (particularly the
console part), I decided to give your patch a shot directly.

Result: the system no longer locks up. I paste the following info
so you can make sure I'm working with the correct commit:

[Sun Jul 08 02:41:37 -0700 -- alvarezp@octavio:~/src/linux]
$ git status
# Not currently on any branch.
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working  
directory)

#
#   modified:   drivers/acpi/acpica/hwsleep.c
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#   arch/x86/tools/relocs
no changes added to commit (use "git add" and/or "git commit -a")

[Sun Jul 08 02:41:41 -0700 -- alvarezp@octavio:~/src/linux]
$ git log HEAD^..HEAD
commit 2feec47d4c5f80b05f1650f5a24865718978eea4
Author: Bob Moore 
Date:   Tue Feb 14 15:00:53 2012 +0800

ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl  
registers


Adds sleep and wake support for systems with these registers.
One new file, hwxfsleep.c

Signed-off-by: Bob Moore 
Signed-off-by: Len Brown 

[Sun Jul 08 02:41:49 -0700 -- alvarezp@octavio:~/src/linux]
$ git diff
diff --git a/drivers/acpi/acpica/hwsleep.c b/drivers/acpi/acpica/hwsleep.c
index 59a2a6b..66dd2b8 100644
--- a/drivers/acpi/acpica/hwsleep.c
+++ b/drivers/acpi/acpica/hwsleep.c
@@ -241,18 +241,6 @@ acpi_status acpi_hw_legacy_sleep(u8 sleep_state)
return_ACPI_STATUS(status);
}

-   if (sleep_state != ACPI_STATE_S5) {
-   /*
-* Disable BM arbitration. This feature is contained  
within an

-* optional register (PM2 Control), so ignore a BAD_ADDRESS
-* exception.
-*/
-   status = acpi_write_bit_register(ACPI_BITREG_ARB_DISABLE,  
1);

-   if (ACPI_FAILURE(status) && (status != AE_BAD_ADDRESS)) {
-   return_ACPI_STATUS(status);
-   }
-   }
-
/*
 * 1) Disable/Clear all GPEs
 * 2) Enable all wakeup GPEs
@@ -498,16 +486,6 @@ acpi_status acpi_hw_legacy_wake(u8 sleep_state)
[ACPI_EVENT_POWER_BUTTON].
status_register_id, ACPI_CLEAR_STATUS);

-   /*
-* Enable BM arbitration. This feature is contained within an
-* optional register (PM2 Control), so ignore a BAD_ADDRESS
-* exception.
-*/
-   status = acpi_write_bit_register(ACPI_BITREG_ARB_DISABLE, 0);
-   if (ACPI_FAILURE(status) && (status != AE_BAD_ADDRESS)) {
-   return_ACPI_STATUS(status);
-   }
-
acpi_hw_execute_SST(ACPI_SST_WORKING);
return_ACPI_STATUS(status);
 }



Now for a complaint.  This would have been a lot easier if cleanups
that do not change behavior were split into separate commits --- one
commit per change.  That makes it easy to verify that each patch
correctly does what it promises with no unintended side effects.


I have to back you up on this one. This patch could have been 3 easily.
Git bisect would have done a better job.

The question is: if he had dont it that way, would the kernel have
compiled in intermediate commits?

diff --git i/drivers/acpi/acpica/hwsleep.c  
w/drivers/acpi/acpica/hwsleep.c

index 0ed85cac3231..615996a36bed 100644
--- i/drivers/acpi/acpica/hwsleep.c
+++ w/drivers/acpi/acpica/hwsleep.c
@@ -95,18 +95,6 @@ acpi_status acpi_hw_legacy_sleep(u8 sleep_state, u8  
flags)

return_ACPI_STATUS(status);
}
-   if (sleep_state != ACPI_STATE_S5) {
-   /*
-* Disable BM arbitration. This feature is contained within an
-* optional register (PM2 Control), so ignore a BAD_ADDRESS
-* exception.
-*/
-   status = acpi_write_bit_register(ACPI_BITREG_ARB_DISABLE, 1);
-   if (ACPI_FAILURE(status) && (status != AE_BAD_ADDRESS)) {
-   return_ACPI_STATUS(status);
-   }
-   }
-
/*
 * 1) Disable/Clear all GPEs
 * 2) Enable all wakeup GPEs
@@ -364,16 +352,6 @@ acpi_status acpi_hw_legacy_wake(u8 sleep_state, u8  
flags)

[ACPI_EVENT_POWER_BUTTON].
status_register_id, ACPI_CLEAR_STATUS);
-   /*
-* Enable BM arbitration. This feature is contained within an
-* optional register (PM2 Control), so ignore a BAD_ADDRESS
-* exception.
-*/
-   status = acpi_write_bit_register(ACPI_BITREG_ARB_DISABLE, 0);
-   if (ACPI_FAILURE(status) && (status != AE_BAD_ADDRESS)) {
-   return_ACPI_STATUS(status);
-

Bug#680707: [3.4-rc5 -> 3.4-rc6 regression] Asus P5NSLI: lockup on resume from suspend

[Octavio Alvarez]

On Sat, 07 Jul 2012 19:57:30 -0700, Jonathan Nieder   
wrote:



commit 2feec47d4c5f80b05f1650f5a24865718978eea4
Author: Bob Moore 
Date:   Tue Feb 14 15:00:53 2012 +0800

 ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl
registers

[...]

Yes, okay, that is indeed totally separate.  You should bring that
issue up with Bob Moore and Len Brown on the linux-acpi mailing list.


The Debian bug for this one is .
Please cc me or 680...@bugs.debian.org if bringing it up with ACPI
folks so we can track the discussion.


Jonathan, so I decided to continue the discussion of the wakeup-lockup
bug here, so I can Cc: 680707 and the commit author. I have adjusted
the subject to the new subject you stated in the cloned Debian bug.

I removed Ben Hutchings and Alan Stern from the Cc. Please feel free
to add them back.

Hello, Bob!

This is a follow-up email on Debian bug 680707.

I am experiencing lock-ups in my machine. You will notice the bug
initially refers to a different problem. That's because this bug
was discovered by accident on my machine, while testing for a
different suspend bug with a newer kernel version.

The problem is a full system lock-up on resume. The HD led stays on.
The 5-sec power-button cycle isn't enough to get the system back.
It requires a full mechanical power cycle from the power supply.

I bisected the problem as requested by Alan Stern, and tracked it
down to the following commit:

commit 2feec47d4c5f80b05f1650f5a24865718978eea4
Author: Bob Moore 
Date:   Tue Feb 14 15:00:53 2012 +0800

ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl  
registers


Adds sleep and wake support for systems with these registers.
One new file, hwxfsleep.c

Signed-off-by: Bob Moore 
Signed-off-by: Len Brown 

There is already some information already captured in the Debian
bug log.

Is there anything I can do to help get this fixed?

Thanks!!

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



--
Octavio.



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

Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Octavio Alvarez]

On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern   
wrote:



> Also, what does the "lspci -vv" output show for the controller if you
> run it with superuser permissions?

[Sat Jul 07 12:50:10 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
$ sudo lspci -vv -s :00:0b.1


0b.1 is the EHCI controller.  We want to see the OHCI controller, 0b.0.


Sorry about that.

[Sat Jul 07 20:41:28 -0700 -- alvarezp@octavio:~]
$ sudo lspci -vv -s :00:0b.0
00:0b.0 USB controller: NVIDIA Corporation MCP51 USB Controller (rev a2)  
(prog-if 10 [OHCI])

Subsystem: ASUSTeK Computer Inc. A8N-VM CSM Mainboard
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-  
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 20
Region 0: Memory at d5006000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA  
PME(D0+,D1+,D2+,D3hot+,D3cold+)

Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: ohci_hcd


I also bisected the "3.2 doesn't sleep due to ohci" problem and found  
this:


commit a6eeeb9f45b5a417f574f3bc799b7122270bf59b
Author: Alan Stern 
Date:   Mon Sep 26 11:23:38 2011 -0400

 USB: Update USB default wakeup settings


Yes, that commit enables wakeup for USB host controllers by default.
Before that, you had to enable wakeup by hand.  The question is: Why
does the controller think it needs to wake up the system?

Can you also post a dmesg log showing a full suspend/immediate-resume
cycle with CONFIG_USB_DEBUG enabled?


Will do as soon as I reboot into a suitable kernel.

Thanks for your help.

--
Octavio.



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

Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Octavio Alvarez]

Hi, Alan!

So, after about more than a week of bisecting, and thanks to Jonathan  
Nieder's

more-than-precise instructions, the results are in.

On Mon, 25 Jun 2012 11:41:31 -0700, Alan Stern   
wrote:



On Mon, 25 Jun 2012, Octavio Alvarez wrote:

On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern  


wrote:

> What happens if Octavio disables wakeup for that controller before
> suspending?
>
>echo disabled >/sys/bus/pci/devices/:00:0b.0/power/wakeup

On kernel 3.2, it lets suspend work again.


If you build a kernel with CONFIG_USB_DEBUG enabled, what
shows up in /sys/kernel/debug/usb/ohci/*/registers?


[Sat Jul 07 12:49:27 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
$ grep . ohci/*/registers
bus pci, device :00:0b.0
OHCI Host Controller
ohci_hcd
OHCI 1.0, NO legacy support registers, rh state running
control 0x68f RWE RWC HCFS=operational IE PLE CBSR=3
cmdstatus 0x0 SOC=0
intrstatus 0x0024 FNO SF
intrenable 0x804a MIE RHSC RD WDH
ed_controlhead 2edac040
hcca frame 0x5fce
fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf
fmremaining 0x80002e53 FRT FR=0x2e53
periodicstart 0x2a2f
lsthresh 0x0628
hub poll timer off
roothub.a 01000208 POTPGT=1 NPS NDP=8(8)
roothub.b  PPCM= DR=
roothub.status 8000 DRWE
roothub.portstatus [0] 0x0100 PPS
roothub.portstatus [1] 0x0100 PPS
roothub.portstatus [2] 0x0100 PPS
roothub.portstatus [3] 0x0100 PPS
roothub.portstatus [4] 0x0303 LSDA PPS PES CCS
roothub.portstatus [5] 0x0303 LSDA PPS PES CCS
roothub.portstatus [6] 0x0101 PPS CCS
roothub.portstatus [7] 0x0100 PPS



And what shows up in /sys/kernel/debug/usb/devices?


[Sat Jul 07 12:49:54 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
$ cat devices

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12   MxCh= 8
B:  Alloc= 29/900 us ( 3%), #Int=  3, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0001 Rev= 3.03
S:  Manufacturer=Linux 3.3.0+ ohci_hcd
S:  Product=OHCI Host Controller
S:  SerialNumber=:00:0b.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=02 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#=  2 Spd=1.5  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=046d ProdID=c05a Rev=54.00
S:  Manufacturer=Logitech
S:  Product=USB Optical Mouse
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 98mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   6 Ivl=10ms

T:  Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#=  3 Spd=1.5  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=046d ProdID=c31d Rev=66.00
S:  Manufacturer=Logitech
S:  Product=USB Keyboard
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 90mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=82(I) Atr=03(Int.) MxPS=   4 Ivl=255ms

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 8
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 3.03
S:  Manufacturer=Linux 3.3.0+ ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=:00:0b.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms



Also, what does the "lspci -vv" output show for the controller if you
run it with superuser permissions?


[Sat Jul 07 12:50:10 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
$ sudo lspci -vv -s :00:0b.1
00:0b.1 USB controller: NVIDIA Corporation MCP51 USB Controller (rev a2)  
(prog-if 20 [EHCI])

Subsystem: ASUSTeK Computer Inc. A8N-VM CSM Mainboard
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-  
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Latency: 0 (750ns min, 250ns max)
Interrupt: pin B routed to IRQ 22
Region 0: Memory at d5007000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port: BAR=1 offset=0098
Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA  
PME(D0+,D1+,D2+,D3hot+,D3cold+)

Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: ehci_hcd

I also bisected the "3.2 doesn't sleep due to ohci" problem and found this:

commit a6eeeb9f45b5a417f574f3bc799b7122270bf59b
Author: Alan Stern 
Date:   Mon Sep 26 11:23:38 2011 -0400

USB: Update USB default wakeup settings

This patch (as1486) implements the kernel's new wakeup policy for USB
host controllers.  Since they don't generate wakeup requests on their
but m

Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Octavio Alvarez]

On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern 
wrote:


What happens if Octavio disables wakeup for that controller before
suspending?

echo disabled >/sys/bus/pci/devices/:00:0b.0/power/wakeup


On kernel 3.2, it lets suspend work again.

For kernel 3.4, I'll break it into two parts: the going asleep and the
wakening back.

For the going asleep part, it works just like 3.2. It previously went
"almost" asleep, but with "echo disabled > wakeup" it suspends correctly.

For the wakening back part, with both settings the PC locks up requiring a
mechanical (power supply switch) power cycle to bring the computer back.
Not even the 5-sec power button cycle helps. I guess this is a different
bug, so I'll try to troubleshoot it and open a different one.


--
Octavio.



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

Bug#677472: More information

[Octavio Alvarez]

Under normal circumstances the system simply does not suspend. It appears  
to go all the way to suspension (screen off, disks off, etc.) but when it  
appears that it is going to go off, something prevents it. System doesn't  
hang, it just fails at the very last moment of suspension.


I tried debugging using pm_test. I set it to "core" but suspend_stats  
doesn't catch anything:


# cat /sys/kernel/debug/suspend_stats
success: 12
fail: 0
failed_freeze: 0
failed_prepare: 0
failed_suspend: 0
failed_suspend_noirq: 0
failed_resume: 0
failed_resume_noirq: 0
failures:
  last_failed_dev:  

  last_failed_errno:0
0
  last_failed_step: 

Even with pm_test set to "none", suspend_stats increases the "success"  
value.


As I said earlier, removing ohci_hcd lets suspend work again.

Also, I didn't find anything wrong in /var/log/pm-suspend.log. I may paste  
it in another message if you want because it's 4000 lines long.




--
Octavio.



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

Bug#677472: linux-image-3.2.0-2-686-pae: ohci_hcd module prevents PC from suspending

[Octavio Alvarez]

Package: src:linux
Version: 3.2.20-1
Severity: normal

Dear Maintainer,

Since upgrading to kernel 3.2, I'm unable to suspend my PC. I configured
the button to do something like what pm-suspend does.

Kernel 3.1 (linux-image-3.1.0-1-686-pae version 3.1.8-2) does NOT exhibit
this problem. As of today, I'm falling back to that version to be able
to suspend my PC.

If I remove the ohci_hcd module, pm-suspend works again. Of course, I lose
my keyboard, mouse and sometimes my flash drive (I *think* I saw it picked
up by ehci_hcd, but I'm really not sure if this makes sense at all).

Thank you very much!


-- Package-specific info:
** Version:
Linux version 3.2.0-2-686-pae (Debian 3.2.20-1) 
(debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-7) ) #1 SMP 
Mon Jun 11 18:27:04 UTC 2012

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.2.0-2-686-pae 
root=UUID=f8b60c34-b27c-4517-be16-efe785260da8 ro quiet splash vmalloc=256M

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[8.439477] [drm] radeon: 1024M of VRAM memory ready
[8.439479] [drm] radeon: 512M of GTT memory ready.
[8.439503] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[8.439505] [drm] Driver supports precise vblank timestamp query.
[8.439555] radeon :01:00.0: irq 45 for MSI/MSI-X
[8.439562] radeon :01:00.0: radeon: using MSI.
[8.439596] [drm] radeon: irq initialized.
[8.439602] [drm] GART: num cpu pages 131072, num gpu pages 131072
[8.440444] [drm] Loading CEDAR Microcode
[8.921180] [drm] PCIE GART of 512M enabled (table at 0x0004).
[8.921293] radeon :01:00.0: WB enabled
[8.938654] [drm] ring test succeeded in 1 usecs
[8.938835] [drm] radeon: ib pool ready.
[8.938923] [drm] ib test succeeded in 0 usecs
[8.939970] [drm] Radeon Display Connectors
[8.939973] [drm] Connector 0:
[8.939975] [drm]   HDMI-A
[8.939977] [drm]   HPD2
[8.939979] [drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 
0x644c
[8.939982] [drm]   Encoders:
[8.939984] [drm] DFP1: INTERNAL_UNIPHY1
[8.939986] [drm] Connector 1:
[8.939987] [drm]   DVI-I
[8.939989] [drm]   HPD4
[8.939991] [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 
0x646c
[8.940024] [drm]   Encoders:
[8.940026] [drm] DFP2: INTERNAL_UNIPHY
[8.940028] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[8.940030] [drm] Connector 2:
[8.940031] [drm]   VGA
[8.940034] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 
0x643c
[8.940036] [drm]   Encoders:
[8.940038] [drm] CRT2: INTERNAL_KLDSCP_DAC2
[8.940069] [drm] Internal thermal controller with fan control
[8.940119] [drm] radeon: power management initialized
[9.083327] [drm] fb mappable at 0xC0142000
[9.083331] [drm] vram apper at 0xC000
[9.08] [drm] size 8294400
[9.083335] [drm] fb depth is 24
[9.083336] [drm]pitch is 7680
[9.083432] fbcon: radeondrmfb (fb0) is primary device
[9.334673] ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 23
[9.334681] snd_hda_intel :00:10.1: PCI INT B -> Link[AAZA] -> GSI 23 
(level, low) -> IRQ 23
[9.334684] hda_intel: Disabling MSI
[9.334710] snd_hda_intel :00:10.1: setting latency timer to 64
[9.339256] Console: switching to colour frame buffer device 160x64
[9.345989] fb0: radeondrmfb frame buffer device
[9.345991] drm: registered panic notifier
[9.346014] [drm] Initialized radeon 2.12.0 20080528 for :01:00.0 on 
minor 0
[   10.118176] input: HDA Digital PCBeep as 
/devices/pci:00/:00:10.1/input/input6
[   10.268374] ACPI: PCI Interrupt Link [APC6] enabled at IRQ 16
[   10.268382] snd_hda_intel :01:00.1: PCI INT B -> Link[APC6] -> GSI 16 
(level, low) -> IRQ 16
[   10.268466] snd_hda_intel :01:00.1: irq 46 for MSI/MSI-X
[   10.268494] snd_hda_intel :01:00.1: setting latency timer to 64
[   10.492653] HDMI status: Codec=0 Pin=3 Presence_Detect=0 ELD_Valid=0
[   10.492786] input: HD-Audio Generic HDMI/DP,pcm=3 as 
/devices/pci:00/:00:02.0/:01:00.1/sound/card1/input7
[   12.859283] Adding 1956180k swap on /dev/sda6.  Priority:-1 extents:1 
across:1956180k 
[   13.472146] EXT3-fs (sda5): using internal journal
[   19.924011] kjournald starting.  Commit interval 5 seconds
[   19.924272] EXT3-fs (sda2): using internal journal
[   19.924278] EXT3-fs (sda2): mounted filesystem with ordered data mode
[   20.013076] FAT-fs (sdb2): utf8 is not a recommended IO charset for FAT 
filesystems, filesystem will be case sensitive!
[   20.081292] kjournald starting.  Commit interval 5 seconds
[   20.081524] EXT3-fs (sda1): using internal journal
[   20.081530] EXT3-fs (sda1): mounted filesystem with ordered data mode
[   20.281715] EXT4-fs (sda7): mounted filesystem with ordered data mode. Opts: 
(null)
[   24.191895] fuse init (API version 7.17)
[   25.180850] Netfilter messages via NETLINK v0.30.
[   25.4

Bug#658676: iceweasel-l10n-es-mx: iceweasel doesn't work with the l10n-es-mx package

[Octavio Alvarez]

It looks like the localization file is not up to date with version 10.

If you unzip this file

/usr/lib/iceweasel/extensions/langpack-es...@iceweasel.mozilla.org.xpi

and add the ENTITY to browser.dtd like this:




and re-zip the plugin and install it, and re-run Iceweasel, you'll
get the same error but for a different missing entity.

I changed about 6 and I just keep getting new missing entities.

Regards.


On Sat, 04 Feb 2012 19:47:09 -0800, Fernando C. Estrada
 wrote:


Package: iceweasel-l10n-es-mx
Version: 1:10.0-1
Severity: important

Hi,

I don't know if this issue is related with bug #652950 but since
upgrade to version 10, iceweasel didn't work with the l10n-es-mx package
and just display the following message (screenshot attached):

Error de lectura XML: entidad no definida
Ubicación: chrome://browser/content/browser.xul
Número de línea 553, columna 7:



--
Octavio.

Twitter: @alvarezp2000 -- Identi.ca: @alvarezp



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

Bug#658676: iceweasel-l10n-es-mx: iceweasel doesn't work with the l10n-es-mx package

[Octavio Alvarez]

On Sun, 05 Feb 2012 01:35:02 -0800, Mike Hommey  wrote:

Error de lectura XML: entidad no definida
Ubicación: chrome://browser/content/browser.xul
Número de línea 553, columna 7:


Did that really happen with 10.0-1, or was the l10n-es-mx package
outdated?


ii  iceweasel 10.0-1
ii  iceweasel-l10n-es-mx  1:10.0-1

I see it too, with this.

--
Octavio.



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

Bug#632850: network-manager: It happens too me too.

[Octavio Alvarez]

Package: network-manager
Version: 0.9.2.0-1
Followup-For: Bug #632850

Dear Maintainer,

This bugs bites me too. Contrary to the OP:
 - I'm using Sid.
 - I'm not using nVIDIA graphics cards.
 - I'm directly using the power button set to suspend.

In my case, on resume, the Network Manager icon (GNOME 3
fallback) shows no connection. However, the network is
actually up, except that no DNS is set in /etc/resolv.conf.

If I do echo nameserver 192.168.2.1 >> /etc/resolv.conf I
get my network back, but outside of Network manager, which
still shows the network as disconnected. Sometimes I lose
IPv6 connectivity.

Also, the NM menu shows all of my network cards, so it
appears not to be a driver problem.

In the same way as the OP:
 - /etc/init.d/network-manager restart fixes the problem.
Sometimes I have to reconnect and I get full connectivity
again.

All of the above happens randomly.

--- SOME LOG INFO IN SUSPEND ---
Jan  8 12:46:36 localhost NetworkManager[11723]:  sleep requested 
(sleeping: no  enabled: yes)
Jan  8 12:46:36 localhost NetworkManager[11723]:  sleeping or disabling...
Jan  8 12:46:36 localhost NetworkManager[11723]:  (eth1): now unmanaged
Jan  8 12:46:36 localhost NetworkManager[11723]:  (eth1): device state 
change: unavailable -> unmanaged (reason 'sleeping') [20 10 37]
Jan  8 12:46:36 localhost NetworkManager[11723]:  (eth1): cleaning up...
Jan  8 12:46:36 localhost NetworkManager[11723]:  (eth1): taking down 
device.
Jan  8 12:46:36 localhost NetworkManager[11723]:  (eth0): now unmanaged
Jan  8 12:46:36 localhost NetworkManager[11723]:  (eth0): device state 
change: activated -> unmanaged (reason 'sleeping') [100 10 37]
Jan  8 12:46:36 localhost NetworkManager[11723]:  (eth0): deactivating 
device (reason 'sleeping') [37]
Jan  8 12:46:37 localhost NetworkManager[11723]:  (eth0): canceled DHCP 
transaction, DHCP client pid 11823
Jan  8 12:46:37 localhost NetworkManager[11723]: 
(nm-netlink-utils.c:417):nm_netlink_foreach_route: runtime check failed: (cache 
!= NULL)
Jan  8 12:46:37 localhost NetworkManager[11723]:  (2) failed to find 
interface name for index
Jan  8 12:46:37 localhost NetworkManager[11723]:  (eth0): cleaning up...
Jan  8 12:46:37 localhost NetworkManager[11723]:  (2) failed to find 
interface name for index
Jan  8 12:46:37 localhost NetworkManager[11723]: 
(nm-system.c:679):nm_system_iface_is_up: runtime check failed: (iface != NULL)
Jan  8 12:46:37 localhost NetworkManager[11723]:  [1326055597.173937] 
[nm-system.c:681] nm_system_iface_is_up(): (unknown): failed to get interface 
link object
Jan  8 12:46:37 localhost dbus[1421]: [system] Activating service 
name='org.freedesktop.nm_dispatcher' (using servicehelper)
Jan  8 12:46:37 localhost dbus[1421]: [system] Successfully activated service 
'org.freedesktop.nm_dispatcher'
Jan  8 12:46:38 localhost anacron[12041]: Anacron 2.3 started on 2012-01-08
Jan  8 12:46:38 localhost anacron[12041]: Normal exit (0 jobs run)
Jan  8 12:46:38 localhost kernel: [23238.411932] EXT4-fs (sda7): re-mounted. 
Opts: commit=0
Jan  8 12:46:39 localhost kernel: [23238.914515] PM: Syncing filesystems ... 
done.
Jan  8 12:46:39 localhost kernel: [23238.926794] PM: Preparing system for mem 
sleep


--- SOME LOG INFO ON RESUME ---

Jan  8 12:47:02 localhost kernel: [23241.498481] PM: Finishing wakeup.
Jan  8 12:47:02 localhost kernel: [23241.498483] Restarting tasks ... done.
Jan  8 12:47:02 localhost NetworkManager[11723]:  (eth0): carrier now OFF 
(device state 10)
Jan  8 12:47:02 localhost NetworkManager[11723]:  (eth0): carrier now ON 
(device state 10)
Jan  8 12:47:02 localhost dbus[1421]: [system] Activating service 
name='org.freedesktop.PackageKit' (using servicehelper)
Jan  8 12:47:03 localhost dbus[1421]: [system] Successfully activated service 
'org.freedesktop.PackageKit'
Jan  8 12:47:03 localhost anacron[12365]: Anacron 2.3 started on 2012-01-08
Jan  8 12:47:03 localhost anacron[12365]: Normal exit (0 jobs run)
Jan  8 12:47:03 localhost anacron[12422]: Anacron 2.3 started on 2012-01-08
Jan  8 12:47:03 localhost anacron[12422]: Normal exit (0 jobs run)
Jan  8 12:47:03 localhost kernel: [23242.193541] EXT4-fs (sda7): re-mounted. 
Opts: commit=0
Jan  8 12:47:03 localhost NetworkManager[11723]:  wake requested 
(sleeping: yes  enabled: yes)
Jan  8 12:47:03 localhost NetworkManager[11723]:  waking up and 
re-enabling...
Jan  8 12:47:03 localhost NetworkManager[11723]:  WWAN now enabled by 
management service
Jan  8 12:47:03 localhost NetworkManager[11723]:  (eth1): now managed
Jan  8 12:47:03 localhost NetworkManager[11723]:  (eth1): device state 
change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Jan  8 12:47:03 localhost NetworkManager[11723]:  (3) failed to find 
interface name for index
Jan  8 12:47:03 localhost NetworkManager[11723]: 
(nm-system.c:679):nm_system_iface_is_up: runtime check failed: (iface != NULL)
Jan  8 12:47:03 localhost NetworkManager[11723]:  [1326055623.634254] 
[nm-system.c:681] nm_system_iface_is_up(

Bug#647877: ITP: superkb -- Keyboard-based launcher with unobtrusive on-screen graphical hints.

[Octavio Alvarez]

Package: wnpp
Severity: wishlist
Owner: Octavio Alvarez 

* Package name: superkb
  Version : 0.22
  Upstream Author : Octavio Alvarez 
* URL : http://superkb.sourceforge.net/
* License : GPLv2
  Programming Lang: C
  Description : Keyboard-based launcher with unobtrusive on-screen 
graphical hints.

Hi. This is a program I wrote to enable key bindings to work with the
Super key. Holding down the Super key for N seconds shows a keyboard
on screen with hints about available bound keys. Configuration is
stored in a flat text file. You can bind arbitrary scripts to your
keys.

It has been helpful to me because I can easily replicate my bindings
to another PC and, so I have my keyboard full of shortcuts, I can
check them when in doubt.

The Super key is not fixed, so you can use any "magic" key in laptops
that don't have the key (like the T42) without losing it.

I am also learning to package for Debian. I am very willing to learn
and become a maintainer in the near future, and potentially a developer.



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

Bug#647436: Failure to boot on plain /dev/sdaN unless scsi_mod.scan=sync or rootdelay=60

[Octavio Alvarez]

Package: initramfs-tools
Version: 0.99
Severity: critical

Hi. On a freshly-installed squeeze, and then upgraded to wheezy, upgrading to
kernel 3.0.0-1 (amd64) makes the server fail to boot.

I set to critical because it matches the "breaks the whole system" criteria on
reportbug. The server was running lenny and squeeze perfectly.

This is what appears on screen:
 transcription 
[0.376354] pci_root PNP0A08:00: address space collision: host bridge window 
[mem 0x000c8000-0x800d] conflicts with Video ROM [mem 0x000c-0x000cafff]
Loading, please wait...
Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/disk/by-uuid/b5b45032-88a2-49d9-a598-1e53d3aed2ab does not exist.
Dropping to a shell!


BusyBox [blah blah].
Enter 'help' for [blah blah]..

/bin/sh: can't access tty: job control turned off
(initramfs)
-

Partition is plain /dev/sda6. No LVM.

Following the suggestion of BTS #616689 (thanks babilen!) I added 
scsi_mod.scan=sync and removed rootdelay=60 and the server rebooted correctly.

$ lspci | grep RAID
02:00.0 RAID bus controller: Adaptec AAC-RAID (Rocket) (rev 02)


-- Package-specific info:
-- initramfs sizes
-- /proc/cmdline
placeholder root=UUID=b5b45032-88a2-49d9-a598-1e53d3aed2ab ro 
scsi_mod.scan=sync quiet

-- resume
RESUME=UUID=a6a8734d-eb17-477c-9dd7-cc3ebdbd9541
-- /proc/filesystems
ext3

-- lsmod
Module  Size  Used by
xt_tcpudp  12570  1 
xt_physdev 12515  4 
iptable_filter 12536  1 
ip_tables  22131  1 iptable_filter
x_tables   19024  4 xt_tcpudp,xt_physdev,iptable_filter,ip_tables
xen_netback27130  0 [permanent]
xen_blkback17971  0 [permanent]
bridge 66612  0 
stp12435  1 bridge
xen_evtchn 13009  2 
xenfs  17714  1 
loop   22711  4 
radeon652630  1 
ibmpex 12802  0 
ibmaem 13363  0 
ipmi_msghandler35981  2 ibmpex,ibmaem
evdev  17558  1 
psmouse55656  0 
snd_pcm68104  0 
snd_timer  22581  1 snd_pcm
snd52823  2 snd_pcm,snd_timer
ttm52979  1 radeon
drm_kms_helper 27216  1 radeon
drm   163280  3 radeon,ttm,drm_kms_helper
soundcore  13152  1 snd
i2c_algo_bit   12850  1 radeon
snd_page_alloc 13043  1 snd_pcm
shpchp 31343  0 
power_supply   13475  1 radeon
i5000_edac 12832  0 
serio_raw  12846  0 
pcspkr 12579  0 
i2c_i801   16870  0 
ics932s401 13080  0 
edac_core  35343  3 i5000_edac
ioatdma37495  12 
i5k_amb12970  0 
i2c_core   23909  6 
radeon,drm_kms_helper,drm,i2c_algo_bit,i2c_i801,ics932s401
rng_core   12696  0 
pci_hotplug27232  1 shpchp
dca13245  1 ioatdma
processor  27942  0 
button 12930  0 
thermal_sys17949  1 processor
ext3  114399  2 
jbd43355  1 ext3
mbcache13066  1 ext3
ses13158  0 
enclosure  13307  1 ses
sd_mod 36259  4 
crc_t10dif 12348  1 sd_mod
sg 25985  0 
sr_mod 21811  0 
cdrom  35093  1 sr_mod
ata_generic12479  0 
uhci_hcd   26787  0 
ehci_hcd   40090  0 
ata_piix   25358  0 
libata149043  2 ata_generic,ata_piix
usbcore   128338  3 uhci_hcd,ehci_hcd
aacraid72143  3 
scsi_mod  162442  6 ses,sd_mod,sg,sr_mod,libata,aacraid
bnx2   67715  0 

-- /etc/initramfs-tools/modules

-- /etc/kernel-img.conf
# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
do_bootloader = no
do_initrd = yes
link_in_boot = no

-- /etc/initramfs-tools/initramfs.conf
MODULES=most
BUSYBOX=y
KEYMAP=n
COMPRESS=gzip
BOOT=local
DEVICE=
NFSROOT=auto

-- /etc/initramfs-tools/update-initramfs.conf
update_initramfs=yes
backup_initramfs=no

-- mkinitramfs hooks
/etc/initramfs-tools/hooks/:

/usr/share/initramfs-tools/hooks:
busybox
dmsetup
keymap
klibc
thermal
udev


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

Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.

Bug#635604: Suggested usability design for dnet-common configuration dialog.

[Octavio Alvarez]

It bit me as well. I had a static DHCP bind by MAC address in order to use  
port forwarding to my PC which made my PC unreachable. The MAC address  
change also made it un-WoL-able by MAC address.


So, applications like Blender are indirectly depending on libdnet, and, on  
systems which convert Recommends: to Depends:, makes them dependent on  
dnet-common. I think that libdnet should only *suggest* dnet-common, would  
help, but that would be a libdnet bug, not a dnet-common bug.


That said, I also found the configuration dialog for dnet-common has  
serious issues.


The dnet-common configuration dialog currently says:

You can configure your system as a DECnet node now or later. If you have  
already set up your system to use DECnet you can skip this and leave the  
configuration as it is.


If you choose to configure now this will set up your system. This  
operation needs to change the MAC address of your network cards, it may  
work directly or it may require a reboot. Please
close all open connections such as ssh sessions and downloads before you  
continue.


If you opt to configure later you can run this configure step again  
with: dpkg-reconfigure dnet-common


If you are unsure, select 'configure later' and contact your system  
administrator.


Configure DECnet now:

[ configure now ]
[ configure later ]
[ skip and leave config as it is ] **default**


There are some issues with it:

1. All three options change the MAC address and start the DECnet service.  
This is a serious bug.


2. Although it does state that MAC address will change, it is merely said  
as a justification for "it may work directly or it may require a reboot".  
It does not stand out whatsoever by itself.


3. It says "if you are unsure, select "configure later", but the default  
option is "skip and leave config as it is". This happens even if there is  
not any previous dnet-common configuration.


4. Even if there is no DECnet-related configuration, the "skip and leave  
config as it is" option appears on screen.


5. The options are confusing. I actually wanted a "configure never", so,  
knowing that there was no previous configuration I chose "skip and leave  
config as it is". Also, both "configure later" and "skip..." seems to  
conceptually be equivalent. If there is a configuration already, both will  
leave it as it is. If there is no configuration, both should not touch the  
system. Any special cases?



I suggest the following design to the configuration box:

You can configure your system as a DECnet node now or later. If you have  
already set up your system to use DECnet you can skip this and leave the  
configuration as it is.


WARNING: Configuring your system as a DECnet node requires chaning the  
MAC address of your network cards! By default, all network cards will  
have the same MAC address which may lead to serious addressing conflicts  
on your network!


Due to this, should you choose to configure it now, it may work directly  
or it may require a reboot. Please close all open connections such as  
ssh sessions and downloads before you continue.


If you wish to configure DECnet later you can run this configure step  
again with: dpkg-reconfigure dnet-common


If you are unsure, select 'No' and contact your system or network  
administrator.


Configure DECnet now?

a) [ Yes, proceed to DECnet configuration ]
b) [ No, don't touch the system configuration ] **default


If option a) is chosen, DECnet configuration should proceed to ask the  
address or the area/node combination, and, have an button to "[ Cancel ]"  
address configuration and jump back to this dialog.


If option b) is chosen, nothing will be touched, at all.





--
Octavio.



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

Bug#550014: Dangerous aspect of this bug

[Octavio Alvarez]

Hello.

This bug is particularly dangerous on remote administration
scenarios, where the operator will, unexpectedly, get locked
out of the box, requiring physical access to the server.

It is expected that "/etc/init.d/networking restart" would
actually start again all those interfaces that were already
up, if they are available.

If you reconfigure an interface to add an IP alias, interfaces
will be shut down but will not be brought up again.



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

Bug#532042: ITP: monica -- A monitor calibration tool.

[Octavio Alvarez]

On Sun, 23 May 2010 14:57:54 -0700, Larry Lade   
wrote:



Any progress on this? I'd like to see this included in Debian.


I registered it in Debian Mentors, but it wasn't interesting enough for  
any sponsor to pick it up.



The upstream source seems to have disappeared.


You might want to try this link:

http://mentors.debian.net/debian/pool/main/m/monica/


--
Octavio.



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

Bug#296258: freemind: Integration into GNOME/KDE

[Octavio Alvarez]

Please excuse if I say something stupid here, but this is the first time
I touch the /usrs/hare/mime/packages files.

I added the following lines to my /usr/share/mime/packages/freemind.xml:





and ran the update-* commands.

Now Nautilus is correctly distinguishes freemind against troff-mm
files (at least the sample file I have here).

Does this help to get the bug fixed?



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

Bug#532042: ITP: monica -- A monitor calibration tool.

[Octavio Alvarez]

Package: wnpp
Severity: wishlist
Owner: Octavio Alvarez 


* Package name: monica
  Version : 3.7
  Upstream Author : As per AUTHORS file:

Tilo Riemer  (versions to 1.11)
Paul Sherman  (version 2.0->3.6)
Philip Heuer  (version 3.6->3.7 patch)

* URL : http://www.pcbypaul.com/software/monica.html
* License : BSD
  Programming Lang: C++
  Description : A simple monitor calibration tool.

  Monica is a monitor calibration tool using the FLTK library.
  It works as frontend to xgamma to alter the gamma correction
  for XFree86 or Xorg. The black point, gray and color blocks
  help to find usable settings for a target of 2.2 gamma, the
  Web and sRGB standard.



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

Bug#490068:

[Octavio Alvarez]

> It's like saying that 1 + 1 could be different than 0.

I meant "1 - 1".

It's like saying that 1 - 1 could be different than 0.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#490068:

[Octavio Alvarez]

> > Apparently splashy left /etc/lsb-base-logging.sh installed.

> As it should on remove. You probably didn't purge splashy.

It's insane not to think that given a working system, "apt-get install
splashy; apt-get remove splashy" allows the system to be kept in an
unworking state.

It's like saying that 1 + 1 could be different than 0.





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#479115: It broke gedit.

[Octavio Alvarez]

Just for the record, it broke gedit through python-gtksourceview2.

--

[EMAIL PROTECTED]:~# apt-get install gedit
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:

The following packages have unmet dependencies.
  gedit: Depends: python-gtksourceview2 (>= 2.2.0) but it is not going
to be installed
E: Broken packages


[EMAIL PROTECTED]:~# apt-get install python-gtksourceview2
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:

The following packages have unmet dependencies.
  python-gtksourceview2: Depends: libffi4 but it is not going to be
installed
E: Broken packages


[EMAIL PROTECTED]:~# apt-get install libffi4  
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:

The following packages have unmet dependencies.
  libffi4: Depends: gcc-4.3-base (= 4.3.0-3) but 4.3.0-4 is to be
installed
E: Broken packages





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#467196: [Pkg-sysvinit-devel] Bug#467196: initscripts: GDM no longer start automagically on Lenny

[Octavio Alvarez]

I have the same problem.

/etc/X11/default-display-manager has /usr/bin/gdm, even when it's
installed in /usr/sbin/gdm. However, correcting it did not help.

However, the following modification helped me:

--- gdm.old 2008-04-07 00:10:45.0 -0700
+++ gdm 2008-04-07 00:02:42.0 -0700
@@ -39,7 +39,9 @@
[ "$CONFIGURED_DAEMON" != gdm ] ; then
 log_action_msg "Not starting GNOME Display Manager; it
is not the default display manager"
 else
+   set +e
 log_daemon_msg "Starting GNOME Display Manager" "gdm"
+   set -e
 start_daemon $DAEMON
 log_end_msg $?
 fi

There is some "pidof splashy" code in /etc/lsb-base-logging.sh failing,
returning 1 and quitting the script because of set -e.





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#473204: libmhash-dev: pollutes autotools namespace

[Octavio Alvarez]

Package: libmhash-dev
Version: 0.9.9-1
Severity: normal
Tags: patch


When compiling an application that uses includes  and uses
autotools, it gives the following mhash-related warnings:

In file included from audiosum.c:30:
.../config.h:41:1: warning: "PACKAGE" redefined
In file included from /usr/include/mutils/mhash.h:29,
 from /usr/include/mhash.h:10,
 from audiosum.c:28:
/usr/include/mutils/mhash_config.h:186:1: warning: this is the location of the 
previous definition
In file included from audiosum.c:30:
.../config.h:44:1: warning: "PACKAGE_BUGREPORT" redefined
In file included from /usr/include/mutils/mhash.h:29,
 from /usr/include/mhash.h:10,
 from audiosum.c:28:
/usr/include/mutils/mhash_config.h:189:1: warning: this is the location of the 
previous definition
In file included from audiosum.c:30:
.../config.h:47:1: warning: "PACKAGE_NAME" redefined
In file included from /usr/include/mutils/mhash.h:29,
 from /usr/include/mhash.h:10,
 from audiosum.c:28:
/usr/include/mutils/mhash_config.h:192:1: warning: this is the location of the 
previous definition
In file included from audiosum.c:30:
.../config.h:50:1: warning: "PACKAGE_STRING" redefined
In file included from /usr/include/mutils/mhash.h:29,
 from /usr/include/mhash.h:10,
 from audiosum.c:28:
/usr/include/mutils/mhash_config.h:195:1: warning: this is the location of the 
previous definition
In file included from audiosum.c:30:
.../config.h:53:1: warning: "PACKAGE_TARNAME" redefined
In file included from /usr/include/mutils/mhash.h:29,
 from /usr/include/mhash.h:10,
 from audiosum.c:28:
/usr/include/mutils/mhash_config.h:198:1: warning: this is the location of the 
previous definition
In file included from audiosum.c:30:
.../config.h:56:1: warning: "PACKAGE_VERSION" redefined
In file included from /usr/include/mutils/mhash.h:29,
 from /usr/include/mhash.h:10,
 from audiosum.c:28:
/usr/include/mutils/mhash_config.h:201:1: warning: this is the location of the 
previous definition


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages libmhash-dev depends on:
ii  libc6-dev 2.7-9  GNU C Library: Development Librari
ii  libmhash2 0.9.9-1Library for cryptographic hashing 

libmhash-dev recommends no packages.

-- no debconf information
diff -x configure -x config.guess -x config.sub -x 'Makefile.*' -Nru 
mhash-0.9.9.orig/configure.in mhash-0.9.9/configure.in
--- mhash-0.9.9.orig/configure.in   2007-04-04 19:22:28.0 -0700
+++ mhash-0.9.9/configure.in2008-03-29 00:21:24.0 -0800
@@ -6,6 +6,7 @@
 AM_INIT_AUTOMAKE
 
 AC_DEFINE([MHASH_VERSION], PROGRAM_VERSION, "MHash Version")
+AC_CONFIG_HEADER([include/mutils/config.h])
 AC_CONFIG_HEADER([include/mutils/mhash_config.h])
 
 
diff -x configure -x config.guess -x config.sub -x 'Makefile.*' -Nru 
mhash-0.9.9.orig/include/mutils/config.h.in 
mhash-0.9.9/include/mutils/config.h.in
--- mhash-0.9.9.orig/include/mutils/config.h.in 1969-12-31 16:00:00.0 
-0800
+++ mhash-0.9.9/include/mutils/config.h.in  2008-03-29 00:48:22.0 
-0800
@@ -0,0 +1,22 @@
+/* Name of package */
+#undef PACKAGE
+
+/* Define to the address where bug reports for this package should be sent. */
+#undef PACKAGE_BUGREPORT
+
+/* Define to the full name of this package. */
+#undef PACKAGE_NAME
+
+/* Define to the full name and version of this package. */
+#undef PACKAGE_STRING
+
+/* Define to the one symbol short name of this package. */
+#undef PACKAGE_TARNAME
+
+/* Define to the version of this package. */
+#undef PACKAGE_VERSION
+
+/* Version number of package */
+#undef VERSION
+
+
diff -x configure -x config.guess -x config.sub -x 'Makefile.*' -Nru 
mhash-0.9.9.orig/include/mutils/mhash_config.h.in 
mhash-0.9.9/include/mutils/mhash_config.h.in
--- mhash-0.9.9.orig/include/mutils/mhash_config.h.in   2008-03-29 
00:23:29.0 -0800
+++ mhash-0.9.9/include/mutils/mhash_config.h.in2008-03-29 
00:06:41.0 -0800
@@ -181,24 +181,6 @@
 /* Define to 1 if your C compiler doesn't accept -c and -o together. */
 #undef NO_MINUS_C_MINUS_O
 
-/* Name of package */
-#undef PACKAGE
-
-/* Define to the address where bug reports for this package should be sent. */
-#undef PACKAGE_BUGREPORT
-
-/* Define to the full name of this package. */
-#undef PACKAGE_NAME
-
-/* Define to the full name and version of this package. */
-#undef PACKAGE_STRING
-
-/* Define to the one symbol short name of this package. */
-#undef PACKAGE_TARNAME
-
-/* Define to the version of this package. */
-#undef PACKAGE_VERSION
-
 /* Define t

Bug#394318: Any updates on this?

[Octavio Alvarez]

Any updates on this bug?

--or--

Is xorg-server 1.2 going to be used in the next release? (it was fixed  
before 1.2).


--
Octavio.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]