Bug#1052489: iproute2: broken formatting in manual pages due to hermetic-/usr changes

[Paul Wise]

Package: iproute2
Version: 6.5.0-4
Severity: minor
Usertags: formatting

The hermetic-/usr changes to the manual pages documenting the new
locations in /usr of the files previously in /etc and overridable
by user files in /etc broke the formatting in the manual pages.

The /usr paths have "or" appended to them instead of as a separate
word and the /etc paths have "(hasprecedenceifexists)" appended to
them instead of with spaces as a separate phrase.

Note that not all mentions of /usr and /etc paths have this issue.

There may be other formatting issues I haven't noticed yet.

   $ for f in $(dpkg -L iproute2 | grep 'man.*\.gz' ) ; do if output=$(man $f 
2> /dev/null | grep "hasprecedenceifexists") ; then echo "$f" ; echo "$output" 
; fi ; done
   /usr/share/man/man8/ip-address.8.gz
 the  scope of the area where this address is valid.  The 
available scopes are listed in /usr/lib/iproute2/rt_scopesor 
/etc/iproute2/rt_scopes(hasprecedenceifexists).  Pre‐
   /usr/share/man/man8/ip-link.8.gz
 specify the group the device belongs to.  The available groups 
are listed in /usr/lib/iproute2/groupor 
/etc/iproute2/group(hasprecedenceifexists).
   /usr/share/man/man8/ip-route.8.gz
/usr/lib/iproute2/rt_dsfieldor 
/etc/iproute2/rt_dsfield(hasprecedenceifexists).
the table to add this route to.  TABLEID may be a 
number or a string from /usr/lib/iproute2/rt_tablesor 
/etc/iproute2/rt_tables(hasprecedenceifexists).  If this pa‐
the realm to which this route is assigned.  REALMID may 
be a number or a string from /usr/lib/iproute2/rt_realmsor 
/etc/iproute2/rt_realms(hasprecedenceifexists).
/etc/iproute2/rt_scopes(hasprecedenceifexists).   If 
this parameter is omitted, ip assumes scope global for all gatewayed unicast 
routes, scope link for direct uni‐
the routing protocol identifier of this route.  RTPROTO 
may be a number or a string from  /etc/iproute2/rt_protosor  
/etc/iproute2/rt_protos(hasprecedenceifexists).
number  or  a string from 
/usr/lib/iproute2/rt_tablesor /etc/iproute2/rt_tables(hasprecedenceifexists).  
If vrftable is used, the argument must be a VRF
string  from  /usr/lib/iproute2/rt_tablesor 
/etc/iproute2/rt_tables(hasprecedenceifexists).  The argument must be a VRF 
device associated with the table
ber or a string from 
/usr/lib/iproute2/rt_tablesor /etc/iproute2/rt_tables(hasprecedenceifexists).  
The argument must be a VRF  device  associated  with

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iproute2 depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libbpf11:1.2.2-2
ii  libbsd00.11.7-4
ii  libc6  2.37-10
ii  libcap21:2.66-4
ii  libcap2-bin1:2.66-4
ii  libdb5.3   5.3.28+dfsg2-2
ii  libelf10.189-4
ii  libmnl01.0.4-3
ii  libselinux13.5-1
ii  libtirpc3  1.3.3+ds-1
ii  libxtables12   1.8.9-2

Versions of packages iproute2 recommends:
pn  libatm1  

Versions of packages iproute2 suggests:
pn  iproute2-doc  
ii  python3   3.11.4-5+b1

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Releasing linux/6.1.52-1 bookworm-security update without armel build, Image size problems

[Paul Wise]

On Sat, 2023-09-09 at 11:42 +0200, Bastian Blank wrote:

> The first one is the one with included size limitations, because those
> load the kernel from a pre-defined flash partition, whose size can't be
> easily changed by the user.  This one is now overflowing for the second
> to last documented one in the kernel package config.

Seems like this would be solvable by writing a bootloader to the flash
partition that would be able to load Linux from a normal filesystem?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Bug#1026335: Review of the initial packaging of the carl9170 firmware

[Paul Wise]

On Sun, 2023-08-13 at 11:51 +, John Scott wrote:

> Because carl9170 is largely under the GPL and we're obligated to
> distribute complete sources for our binaries, I've set Static-Built-
> Using on both gcc (because of libgcc) and Newlib.

FYI, that wasn't the correct thing to do.

Built-Using is for license compliance cases:

https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using

Static-Built-Using is for other static linking or embedding cases.

The static linking wiki page needs updates for Static-Built-Using
and the predecessors of it used by the Rust and Golang packages.

https://wiki.debian.org/StaticLinking

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#606713: unarchiving 606713, reopening 606713, found 606713 in 5.10.28-1

[Paul Wise]

On Fri, 2022-06-10 at 00:36 +0200, Diederik de Haas wrote:

> A year has passed and it has been quiet on the upstream bug for almost a year.
> Has there been progress which isn't visible in upstream or Debian's BTS?

There hasn't. I haven't had time to try this bug again but I will try
to make time to reproduce it towards the end of June.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1004667: linux-signed-arm64: Please enable CONFIG_TASK_DELAY_ACCT

[Paul Wise]

On Mon, 31 Jan 2022 15:18:49 +0100 Matthias Urlichs wrote:

> "iotop" complains:
> 
> CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %

For more recent Linux kernel versions you need this:

   sudo sysctl kernel.task_delayacct=1

I'm guessing that the patches changing this got backported to the Linux
kernel stable releases, which then got into Debian stable?

If so the patches to iotop-c and iotop-py* probably need backporting to
Debian stable.

*The iotop-py patches for #1004714 aren't in sid yet, waiting on
upstream permission and assistance to make a new release.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Bug#1002617: RFS: carl9170fw/1.9.9-399-gcd480b9-1 [ITP] -- firmware for AR9170 USB wireless adapters

[Paul Wise]

On Thu, 2022-01-13 at 20:54 +, John Scott wrote:

> You might like to have a look at this mail from Ben Hutchings:
> https://lists.debian.org/msgid-search/179d6d32466dd13962a3aab251c45242fbf2d8ae.ca...@decadent.org.uk
> The reason that none of the other Wi-Fi firmware packages have them is
> because they're all non-free (with the exception of ath9k_htc).

Thanks for the link, I'm not subscribed to that list. Makes sense.

> I wasn't sure if there was any established convention; my thread "Naming
> convention for udebs: -udeb/-installer suffix" didn't garner any
> pertinent responses. I've switched the name though.

I did a search of a Debian mirror filesystem and found that only the
linux and linux-signed-* source packages use the -di suffix, most use
the -udeb suffix. The -installer suffix seems to be used only for udeb
packages when the source package has the -installer suffix too, such as
bootloader installers like grub-installer, with a few exceptions for
other udebs that install things. I suggest using the -udeb suffix.

> These are all good catches, I'm working on incorporating them and doing
> a slow and careful review.

Recently on another project I noticed an upstream commit that added
copyright information in the middle of a file alongside the functions
that were copied from elsewhere. This sort of thing is hard to notice
during the manual review of file headers I usually do using mc (after
enabling the preview pane and arrow keys for navigation), but some of
the copyright review tools might be helpful. I actually detected the
list.h LGPL license using debmake -k (as run by check-all-the-things).
Apparently the best option is ScanCode but that isn't in Debian yet.

https://wiki.debian.org/CopyrightReviewTools

> I think you're mistaken here, you should take a look at
> /usr/share/dpkg/buildopts.mk which I include via an include directive in
> debian/rules. Basically, DEB_BUILD_OPTION_PARALLEL is a helper macro for
> the value of parallel from DEB_BUILD_OPTIONS; these are one and the
> same.

I see, I wasn't aware of this snippet/variable.

> That's true. My intent was that, since it's a hidden directory, it would
> help remind one that that directory gets created. It seems to've only
> caused confusion, so I'll pull it.

That seems reasonable if you want to keep it. Maybe add a comment.

> Indeed, the documentation is rather old and terse and doesn't address
> this issue. I'll probably ask the Reportbug folks and send them a MR
> updating the docs.

Great.

> > Please ask upstream to make a new release, it has been a very long time
> > since the last one.
> I will do after making some of the following important changes.

Thanks.

> > Please ask upstream to send FindUSB-1.0.cmake & libusb-zeropacket.diff
> > to libusb upstream and then remove them from carl9170fw.
> I will ask, but with all due respect, I think this is lower priority and
> that I'll have limited ability to help them.

Sure. TBH they don't appear to be used by carl9170fw so I'm not sure
why they are in the source repository at all.

> I do not have a grasp, let alone a good one, of CMake, so this may be a
> challenge.

The documentation for CMake is fairly comprehensive, until recently I
had never touched CMake and didn't understand it but when I needed to
figure it out I found it to be reasonable and well documented.

> I actually think I'll do one better: I submitted upstream an AppStream
> metadata file a while ago, and although they haven't responded to it
> yet, perhaps my sending them other changes will get their attention.
> AppStream metadata and Debian upstream metadata files have considerable
> overlap, and in my personal opinion having good AppStream metadata makes
> an upstream metadata file unnecessary, but I'm willing to entertain
> arguments to the contrary.

I haven't looked at AppStream but I got the feeling they had different
audiences or purposes or tools looking at them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Bug#1002617: RFS: carl9170fw/1.9.9-399-gcd480b9-1 [ITP] -- firmware for AR9170 USB wireless adapters

[Paul Wise]

On Sat, 2021-12-25 at 18:25 +, John Scott wrote:

> https://mentors.debian.net/debian/pool/main/c/carl9170fw/carl9170fw_1.9.9-399-gcd480b9-1.dsc

Some things that prevent the upload of this package:

I don't think udebs are needed for firmware packages, none of the other
WiFi firmware packages in Debian have them. If the package is actually
needed it should be named -udeb not -di, since other udebs use -udeb.

Several files have missing/incorrect information in debian/copyright,
please do a full audit of the code looking for copyright/license info.

 * tools/include/list.h is LGPL
 * tools/include/frame.h is partly from Linux, unknown copyright
 * include/shared/eeprom.h also contains ISC code

DEB_BUILD_OPTION_PARALLEL doesn't appear to be a standard variable,
please switch to DEB_BUILD_OPTIONS=parallel=N instead, see Debian
Policy, section 4.9.1 and debhelper(7) and dpkg-buildpackage(1).

Some things that would be nice to fix at some stage:

Nothing in debian/rules references .config so you can drop that from
before the execute_before_dh_auto_configure target.

It seems like the Homepage should be the carl9170.fw firmware wiki page
instead of the carl9170 driver wiki page.

https://wireless.wiki.kernel.org/en/users/drivers/carl9170.fw

I would express the license of include/shared/fwcmd.h etc as GPL-2-only
&& ISC rather than putting a copy of the ISC license in a comment.

bug-presubj isn't well wrapped. I'm not sure if wrapped or unwrapped is
the best option for this file though.

Please ask upstream to make a new release, it has been a very long time
since the last one.

Please ask upstream to update their copies of code from the Linux
kernel and other external sources to the latest versions.

Please ask upstream to send FindUSB-1.0.cmake & libusb-zeropacket.diff
to libusb upstream and then remove them from carl9170fw.

Please ask upstream to delete FindPackageHandleStandardArgs.cmake,
since that is now available from cmake upstream and from Debian cmake.
Potentially cmake_minimum_required will need to be bumped for this.

Please ask upstream to include the copyright information
for carlfw/src/memcpy.S and carlfw/src/memset.S in the files.

Please ask upstream to update the COPYRIGHT file.

Please send upstream some changes that would allow building the
upstream source using a pre-packaged toolchain like the Debian one.

Please also figure out how to eliminate the other debian/rules
workarounds.

It would be nice if the Linux kernel community or the Debian src:linux
package could split kconfig off into a reusable component.

Please add an upstream metadata file:

https://wiki.debian.org/UpstreamMetadata

I suggest these arguments to wrap-and-sort:

wrap-and-sort --short-indent --wrap-always --sort-binary-packages 
--trailing-comma --dry-run

These tests from check-all-the-things suggest some polishing for
upstream and or yourself: anorack codespell cppcheck cpuinfo debmake-k
duck http path-max proselint shellcheck spellintian todo

https://github.com/collab-qa/check-all-the-things

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#972968: linux-image-5.9.0-1-amd64: Bluetooth stopped working

[Paul Wise]

On Mon, 26 Oct 2020 18:59:16 +0100 Christian Britz  wrote:

> after upgrading my Debian testing installation to kernel 5.9.1,
> my bluetooth mouse does not work anymore.

The patch fixing this will be released in v5.10.6 and v5.11-rc1,
see the upstream bug for details:

https://bugzilla.kernel.org/show_bug.cgi?id=210279

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#962681: battery drain during system shutdown

[Paul Wise]

On Sat, 2020-06-13 at 20:39 +0800, Paul Wise wrote:

> After that you can use the Debian wayback machine to find out which
> Debian builds of the Linux kernel have this issue and which do not.

It seems you had trouble with this. I think the problem might be that
you are downloading all of the Linux binary packages instead of just
the one containing the normal Linux kernel image?

The files you want look like this:

linux-image-4.13.0-rc5-amd64_4.13~rc5-1~exp1_amd64.deb

So the pattern is this:

linux-image--amd64__amd64.deb

Ignore everything else, including -di or non _amd64 packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#962681: battery drain during system shutdown

[Paul Wise]

On Fri, 12 Jun 2020 12:45:47 +0530 Gopal Sharma wrote:

> I'm still facing the issue only in debian.

So on IRC we found that copying the Debian Linux kernel build config
from 5.6.14-2 to the mainline Linux kernel did not have the issue and
that booting the Debian Linux kernel build on Ubuntu did have the
issue. So the problem is caused by the Debian packaging or patches.

The next thing to do would be to install Debian and add the normal
reportbug output to the bug.

https://wiki.debian.org/DebianKernelReportingBugs

Since you didn't provide that in your initial message, I suggest you do
it by running this command and then attaching the report.txt file.

/usr/share/reportbug/handle_bugscript /usr/share/bug/linux-image-*/script 
report.txt

After that you can use the Debian wayback machine to find out which
Debian builds of the Linux kernel have this issue and which do not.

https://wiki.debian.org/DebianKernel/GitBisect
https://wiki.debian.org/BisectDebian
https://snapshot.debian.org/
https://snapshot.debian.org/package/linux/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#962134: add Sound Open Firmware

[Paul Wise]

On Wed, 2020-06-03 at 21:34 -0400, Mark Pearson wrote:

> Hi Paul - I'm afraid it does (not something of Lenovo's choosing to my 
> knowledge...).

Interesting, is it Intel doing the restrictions on Lenovo hardware?
ISTR reading on one of the bugs that some hardware doesn't have the
restrictions, so it is strange that Intel restricts some hardware
vendors but not others. If you are able to push back on these Intel
restrictions, it would be very much appreciated.

> My understanding is the SOF team didn't want to use intel-firmware but 
> I'm trying to find the discussion on the SOF mailing list as to why.

I'm not sure what you mean by intel-firmware. Based on the Repology
website I guess you mean the Intel CPU microcode, which is shipped in
Debian in the intel-microcode package.

https://repology.org/project/intel-firmware/packages
https://repology.org/project/intel-microcode/packages

> I think it was related to there being topology files and debug files and 
> wanting to keep everything together - and the other two files didn't 
> belong in intel-firmware.

Since intel-firmware is mostly about CPU microcode, I agree that SOF
doesn't belong in the intel-firmware/intel-microcode packages.

> There were also concerns about it moving outside of their control. Their 
> solution was the sof-bin repository 
> (https://github.com/thesofproject/sof-bin)

OK, I guess that this repository should be packaged in Debian non-free. 

I am surprised that they created a new repo instead of using upstream
linux-firmware repository, I guess they wanted more control though.

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/

This is going to be annoying because it means that every distro has to
package sof-bin instead of just updating their linux-firmware package.

> I have to admit - I hadn't considered the freedoms issues of that.

It is seriously annoying, since it means you can't fix bugs and then
immediately test them, you have to go through Intel SOF releases.

> Is having a sof-firmware repository that is non-free the same way as 
> intel-firmware? I'm guessing Debian doesn't want to increase the number 
> of non-free packages?

Debian is generally pragmatic about including new non-free packages,
where it is necessary, someone who cares will usually end up doing it.
We would obviously prefer everything to be fully free software, but we
don't live in an ideal world so we make do with what we get. So a new
sof-bin package (sof folks should rename that to sof-firmware-signed)
should be fine to include in Debian. Hopefully someone will also
package a build of the firmware source code for folks who can run
unsigned or debug firmware builds.

> I know the SOF team wanted to work with Debian on this issue a few 
> months ago - I will dig up that email and point them at this bug so they 
> can contribute to the conversation without me muddying the waters about 
> their decisions (I was on their mailing list but not involved in the 
> decision making)

Interesting, thanks for that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#962134: add Sound Open Firmware

[Paul Wise]

On Wed, 3 Jun 2020 18:02:50 +0200 Moritz Mühlenhoff wrote:

> This is free software and could go into main or am I missing something?

SOF is free software, but many devices require binaries that are signed
by Intel's keys, so the free license/source code much less useful and
the binaries going into linux-firmware are needed for most people.

More details in the links on this page:

https://wiki.debian.org/Firmware/Open

Mark, do Lenovo Laptops require the Intel-signed blobs?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#931058: linux: enable CONFIG_USB_DUMMY_HCD=m for simulating USB UDCs for USB gadgets

[Paul Wise]

Package: src:linux
Severity: wishlist

I would like the CONFIG_USB_DUMMY_HCD=m option to be enabled, so that I
can experiment with USB gadgets on x86 desktop systems where a USB UDC
is not available. The other gadget-related config options are already
enabled in the Debian version of the Linux kernel. More info about
using dummy-hcd for experimenting with USB gadgets here:

https://www.collabora.com/news-and-blog/blog/2019/06/24/using-dummy-hcd/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Re: Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Paul Wise]

On Tue, 2019-05-14 at 13:57 +0100, Ben Hutchings wrote:

> Does user-mode-linux need to be a separate source package at all?

I guess it is separate to not require building yet another variant.

Looks like merging it was discussed in 2016:

https://bugs.debian.org/837920

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Re: Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Paul Wise]

Control: notforwarded -1
 
On Tue, 2019-05-14 at 14:36 +0530, Ritesh Raj Sarraf wrote:

> I submitted this fix upstream to the kernel some time ago. I don't
> recollect if the 4.19 kernel is what had it included.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9ca19a3a3e2482916c475b90f3d7fa2a03d8e5ed

That patch is already applied in the Debian user-mode-linux package:

debian/patches/fix-port-helper-path.patch

I noticed that the path embedded in the binary has an extra slash in it
compared to what the patch changes it to so I think the problem is that
the OS_LIB_PATH variable isn't defined correctly on amd64.

There seems to be some sort of confusion about the CONFIG_64BIT var but
it seems like the paths and variables in the sources are correct so I'm
not sure what is going on.

BTW, is it possible to do source-only uploads so that the build logs
are available on amd64, or do the versioned binaries mean no logs? If
so I think it would be good to only upload i386 binary packages so that
we get the build logs for the most used architecture.

~/linux-4.19.37 $ grep -rC1 OS_LIB_PATH 
arch/um/drivers/xterm.c-char *argv[] = { terminal_emulator, 
title_switch, title, exec_switch,
arch/um/drivers/xterm.c: OS_LIB_PATH 
"/uml/port-helper", "-uml-socket",
arch/um/drivers/xterm.c- file, NULL };
--
arch/um/include/shared/os.h-#ifdef CONFIG_64BIT
arch/um/include/shared/os.h:#define OS_LIB_PATH "/usr/lib64/"
arch/um/include/shared/os.h-#else
arch/um/include/shared/os.h:#define OS_LIB_PATH "/usr/lib/"
arch/um/include/shared/os.h-#endif
--
arch/um/os-Linux/main.c-
arch/um/os-Linux/main.c:#define UML_LIB_PATH":" OS_LIB_PATH "/uml"
arch/um/os-Linux/main.c-

~/user-mode-linux-4.19-1um $ grep -r CONFIG_64BIT
config.i386:# CONFIG_64BIT is not set
config.amd64:CONFIG_64BIT=y

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

upstream help needed for Linux USB gadget userland tools (libusbgx, gt, gadgetd)

[Paul Wise]

Hi all,

I've been discussing with upstream the userland tools (libusbgx, gt,
gadgetd) for the Linux USB gadget feature that allows for management of
the Linux APIs that ARM/etc boards can use to flexibly present USB
interfaces to other devices. Upstream mentioned that they have mainly
been focussing on libusbgx due to a lack of time.

Is anyone interested in helping out with these and related tools?

https://github.com/libusbgx/libusbgx: C library & example commands
https://github.com/kopasiak/gt: command-line tools
https://github.com/gadgetd/gadgetd: dbus based daemon for UIs to contact

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#916774: linux-perf metapackage fails to upgrade due to file conflict between linux-perf-4.18 & linux-perf-4.19

[Paul Wise]

Package: linux-perf-4.19
Version: 4.19.9-1
Severity: serious

I had the linux-perf metapackage fail to upgrade due to a file conflict
between linux-perf-4.18 & linux-perf-4.19:

$ sudo apt install -t unstable linux-perf
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following package was automatically installed and is no longer required:
  linux-perf-4.18
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
  linux-perf-4.19
Suggested packages:
  linux-doc-4.19
The following NEW packages will be installed:
  linux-perf-4.19
The following packages will be upgraded:
  linux-perf
1 upgraded, 1 newly installed, 0 to remove and 338 not upgraded.
Need to get 0 B/1,491 kB of archives.
After this operation, 6,614 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Reading changelogs... Done
Selecting previously unselected package linux-perf-4.19.
(Reading database ... 456870 files and directories currently installed.)
Preparing to unpack .../linux-perf-4.19_4.19.9-1_amd64.deb ...
Unpacking linux-perf-4.19 (4.19.9-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/linux-perf-4.19_4.19.9-1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/perf/examples/bpf/5sec.c', which is also in 
package linux-perf-4.18 4.18.20-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Preparing to unpack .../linux-perf_4.19+101_all.deb ...
Unpacking linux-perf (4.19+101) over (4.18+100) ...
Errors were encountered while processing:
 /var/cache/apt/archives/linux-perf-4.19_4.19.9-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

$ echo $?
100

$ sudo dpkg --force-all --purge linux-perf-4.18
(Reading database ... 456869 files and directories currently installed.)
Removing linux-perf-4.18 (4.18.20-2) ...
Processing triggers for man-db (2.8.4-3) ...

$ sudo apt --fix-broken install -t unstable 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  linux-perf-4.19
Suggested packages:
  linux-doc-4.19
The following NEW packages will be installed:
  linux-perf-4.19
0 upgraded, 1 newly installed, 0 to remove and 338 not upgraded.
1 not fully installed or removed.
Need to get 0 B/1,484 kB of archives.
After this operation, 6,614 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Selecting previously unselected package linux-perf-4.19.
(Reading database ... 45 files and directories currently installed.)
Preparing to unpack .../linux-perf-4.19_4.19.9-1_amd64.deb ...
Unpacking linux-perf-4.19 (4.19.9-1) ...
Setting up linux-perf-4.19 (4.19.9-1) ...
Processing triggers for man-db (2.8.4-3) ...
Setting up linux-perf (4.19+101) ...

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), 
LANGUAGE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-perf-4.19 depends on:
ii  libbabeltrace1  1.5.6-2
ii  libc6   2.28-2
ii  libdw1  0.175-1
ii  libelf1 0.175-1
ii  liblzma55.2.2-1.3
ii  libnuma12.0.12-1
ii  libperl5.28 5.28.1-3
ii  libpython3.73.7.2~rc1-1
ii  libslang2   2.3.2-1+b1
ii  libunwind8  1.2.1-8
ii  perl5.28.1-3
ii  python3 3.6.7-1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages linux-perf-4.19 recommends:
ii  linux-base  4.5

Versions of packages linux-perf-4.19 suggests:
pn  linux-doc-4.19  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#906189: linux-image-4.17.0-1-amd64: Laptop does not suspend in 4.17 - worked up to 4.16

[Paul Wise]

On Wed, 15 Aug 2018 12:32:16 +0200 Christoph Haas wrote:

> Booting into 4.16.0-2-amd64 works well.
> 
> Linux kernel image 4.17.0-2 shows the mentioned problem.

This sounds like a job for git bisect:

https://wiki.debian.org/DebianKernel/GitBisect

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#906180: linux: regression: drm: cmdline EDID override mechanisms no longer work since 4.15

[Paul Wise]

Package: src:linux
Version: 4.15~rc5-1~exp1
Severity: important

My monitor lost its VGA EDID a long time ago, so I retrieved a copy of
it from backups of Xorg logs and I have to use the Linux kernel's EDID
override mechanisms. In order to get the right mode early in boot,
I use the Linux kernel cmdline option for this and put the required
firmware file into the initramfs so my cryptsetup prompt is right:

drm_kms_helper.edid_firmware=VGA-1:edid/VGA-1

Linux 4.15 deprecates this option:

kernel: [drm] drm_kms_firmware.edid_firmware is deprecated, please use 
drm.edid_firmware intead.

So I switched to the new option:

drm.edid_firmware=VGA-1:edid/VGA-1

This did not produce any warnings or errors in dmesg but also did not
result in the EDID override file being applied.

I added both the override options to the Linux kernel command-line in
grub and this did not work in the newer versions of Linux.

I also tried this without the VGA-1: connector specifier and this did
not improve the situation but did prevent the LVDS screen from working:

drm.edid_firmware=edid/VGA-1 drm_kms_helper.edid_firmware=edid/VGA-1

I tested the Linux kernel builds on snapshot.debian.org and version
4.15~rc5-1~exp1 came up as the first broken one.

I confirmed that overrides do not work with the latest Linux kernel
version in Debian buster (4.17.8-1).

I then git bisected the issue and came up with 53fd40a90f3c as bad.
I also checked that the following commit ac6c35a4d8c7 was also bad.

https://wiki.debian.org/DebianKernel/GitBisect

53fd40a90f3c0bdad86ec266ee5df833f54ace39 is the first bad commit
commit 53fd40a90f3c0bdad86ec266ee5df833f54ace39
Author: Jani Nikula 
Date:   Tue Sep 12 11:19:26 2017 +0300

drm: handle override and firmware EDID at drm_do_get_edid() level

Handle debugfs override edid and firmware edid at the low level to
transparently and completely replace the real edid. Previously, we
practically only used the modes from the override EDID, and none of the
other data, such as audio parameters.

This change also prevents actual EDID reads when the EDID is to be
overridden, but retains the DDC probe. This is useful if the reason for
preferring override EDID are problems with reading the data, or
corruption of the data.

Move firmware EDID loading from helper to core, as the functionality
moves to lower level as well. This will result in a change of module
parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which
arguably makes more sense anyway.

Some future work remains related to override and firmware EDID
validation. Like before, no validation is done for override EDID. The
firmware EDID is validated separately in the loader. Some unification
and deduplication would be in order, to validate all of them at the
drm_do_get_edid() level, like "real" EDIDs.

v2: move firmware loading to core

v3: rebase, commit message refresh

Cc: Abdiel Janulgue 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Tested-by: Abdiel Janulgue 
Reviewed-by: Ville Syrjälä 
Acked-by: Dave Airlie 
Signed-off-by: Jani Nikula 
Link: 
https://patchwork.freedesktop.org/patch/msgid/1e8a710bcac46e5136c1a7b430074893c81f364a.1505203831.git.jani.nik...@intel.com

:04 04 2c9c6a97a18f6993af1097c69b9e36b1f98add40 
60822020c6c58e6f46d659d321e082a62a530639 M  Documentation
:04 04 f75d443482650cd4359868e1e453087f92543dab 
d737bdb8758b3cdfc5e8ca2b3808328b63939ea8 M  drivers

commit ac6c35a4d8c77083525044a192cb1a8711381e94 (HEAD)
Author: Jani Nikula 
Date:   Mon Sep 18 21:20:03 2017 +0300

drm: add backwards compatibility support for drm_kms_helper.edid_firmware

Add drm_kms_helper.edid_firmware module parameter with param ops hooks
to set drm.edid_firmware instead, for backwards compatibility.

Suggested-by: Ville Syrjälä 
Cc: Abdiel Janulgue 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Acked-by: Dave Airlie 
Signed-off-by: Jani Nikula 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20170918182003.22238-2-jani.nik...@intel.com

-- Package-specific info:
** Version:
Linux version 4.15.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-3)) #1 SMP Debian 4.15.4-1 (2018-02-18)

** Command line:
BOOT_IMAGE=/vmlinuz-4.15.0-1-amd64 root=/dev/mapper/chianamo-root ro 
drm_kms_helper.edid_firmware=VGA-1:edid/VGA-1 
drm.edid_firmware=VGA-1:edid/VGA-1 quiet

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

** Model information
sys_vendor: LENOVO
product_name: 0831CTO
product_version: ThinkPad X201 Tablet
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: 6QET62WW (1.32 )
board_vendor: LENOVO
board_name: 0831CTO
board_version: Not Available

** Loaded modules:
fuse
ctr
ccm
ebtable_filter
ebtables
ip6table_filter
ip6_tables
iptable_filter
devlink

Re: armel not to be released anymore? (was: armel/marvell kernel size)

[Paul Wise]

On Wed, Mar 28, 2018 at 3:21 AM, W. Martin Borgert wrote:
> Quoting Ben Hutchings:
>>
>> Still, as armel will not be a release architecture any more, I suppose
>> it can diverge further from the normal configuration.
>
> I didn't know, that this already has been decided.
> Could you point to the emails about this? Thanks!

https://lists.debian.org/msgid-search/20180207184636.ukfil2kybr7jc...@betterave.cristau.org
https://lists.debian.org/msgid-search/20170914024001.kitowt4moob5h...@tack.einval.com

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#883363: linux-compiler-gcc-7-x86: incorrect GCC version number in package description

[Paul Wise]

Package: linux-compiler-gcc-7-x86
Version: 4.14.2-1
Severity: minor

The linux-compiler-gcc-7-x86 package depends on GCC 7 but
declares in the description that it depends on GCC 6:

Package: linux-compiler-gcc-7-x86
Depends: gcc-7
Description: Compiler for Linux on x86 (meta-package)
 This package depends on gcc 6 of the appropriate architecture for Linux on
 amd64, i386 and x32.

I suggest changing the information to something like this:

Package: linux-compiler-gcc-x86
Depends: gcc-7
Description: Compiler for Linux on x86 (meta-package)
 This package depends on GCC of the appropriate version and architecture
 for Linux on amd64, i386 and x32.

I changed the package name and description thus:

/Package/s/gcc-7/gcc/ 
The version number is in depends already, not needed in package name?
This probably doesn't need to happen until the package name is next changed.

/Description/{n;s/gcc/GCC/}
GCC is an acronym for GNU Compiler Collection so it should be capitalised.

/Description/{n;s/ 6 / /;s/appropriate/& version and/}
Don't hard-code the version number so it never needs updating.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#859066: linux-image-*: recommend firmware-ath9k-htc

[Paul Wise]

Source: linux
Version: 4.10~rc6-1~exp1
Severity: wishlist
X-Debbugs-CC: open-ath9k-htc-firmw...@packages.debian.org

Now that open-ath9k-htc-firmware has been accepted into Debian
unstable, please add "Recommends: firmware-ath9k-htc" to the
metadata for the linux-image-* packages in Debian experimental.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#845942: Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later

[Paul Wise]

On Sun, 2016-11-27 at 08:27 +0100, Salvatore Bonaccorso wrote:

> This was an intentional change in 4.8.4-1~exp1 afaict, from the
> changelog entry:

I wonder if this should be promoted to a NEWS.Debian entry?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#845942: Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later

[Paul Wise]

Control: close -1

On Sun, 2016-11-27 at 08:27 +0100, Salvatore Bonaccorso wrote:

> This was an intentional change in 4.8.4-1~exp1 afaict, from the
> changelog entry:
> 
>   * [amd64] Enable LEGACY_VSYSCALL_NONE instead of LEGACY_VSYSCALL_EMULATE.
> This breaks (e)glibc 2.13 and earlier, and can be reverted using the 
> kernel
> parameter: vsyscall=emulate

Hmm, I guess we are going to have to run the buildds with that
parameter, at least until wheezy LTS runs out.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#845942: Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later

[Paul Wise]

Package: src:linux
Version: 4.8.5-1
Severity: important
Control: found -1 linux/4.8.7-1

After upgrading and rebooting to Linux 4.8.5-1 (now running 4.8.7-1),
I can no longer create wheezy chroots because dpkg inside the chroot
segfaults. In addition, for existing chroots, bash segfaults and so
does the apt-get http helper and a variety of other executables.
Confusingly, not every binary crashes, just a few important ones.
This does not happen with jessie/stretch/sid chroots and does not
happen with wheezy i386 chroots.

pabs@chianamo ~ $ sudo debootstrap --include=apt --variant=buildd 
--force-check-gpg wheezy $(pwd)/tmp-test-debootstrap 
http://deb.debian.org/debian
I: Retrieving InRelease 
I: Retrieving Release 
I: Retrieving Release.gpg 
I: Checking Release signature
I: Valid Release signature (key id ED6D65271AACF0FF15D123036FB2A1C265FFB764)
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Found additional required dependencies: insserv libbz2-1.0 libdb5.1 
libsemanage-common libsemanage1 libslang2 libustr-1.0-1 
I: Found additional base dependencies: binutils bzip2 cpp cpp-4.7 
debian-archive-keyring dpkg-dev g++ g++-4.7 gcc gcc-4.7 gnupg gpgv 
libapt-pkg4.12 libc-dev-bin libc6-dev libclass-isa-perl libdpkg-perl libgdbm3 
libgmp10 libgomp1 libitm1 libmpc2 libmpfr4 libquadmath0 libreadline6 libstdc++6 
libstdc++6-4.7-dev libswitch-perl libtimedate-perl libusb-0.1-4 linux-libc-dev 
make patch perl perl-modules readline-common 
I: Checking component main on http://deb.debian.org/debian...
I: Retrieving libacl1 2.2.51-8
I: Validating libacl1 2.2.51-8
...
I: Chosen extractor for .deb packages: dpkg-deb
I: Extracting libacl1...
...
I: Installing core packages...
W: Failure trying to run: chroot /home/pabs/tmp-test-debootstrap dpkg 
--force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb
W: See /home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log for details
pabs@chianamo ~ $ less 
/home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log
pabs@chianamo ~ $ cat 
/home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log
gpgv: Signature made Sat Jun  4 19:51:09 2016 AWST
gpgv:using RSA key 8B48AD6246925553
gpgv: Good signature from "Debian Archive Automatic Signing Key (7.0/wheezy) 
"
gpgv: Signature made Sat Jun  4 19:51:09 2016 AWST
gpgv:using RSA key 7638D0442B90D010
gpgv: Good signature from "Debian Archive Automatic Signing Key (8/jessie) 
"
gpgv: Signature made Sat Jun  4 19:56:53 2016 AWST
gpgv:using RSA key 6FB2A1C265FFB764
gpgv: Good signature from "Wheezy Stable Release Key 
"
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 missing description
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 missing architecture
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy bash
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy apt-get update
E: Method http has died unexpectedly!
E: Sub-process http received a segmentation fault.
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ dnsdomainname
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ gunzip
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ gzexe
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ login
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ rbash
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ su
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ uncompress
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zcat
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zcmp
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zdiff
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zegrep
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zfgrep
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zforce
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zgrep
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zless
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zmore
Segmentation fault (core 

Re: Bug#841261: ulogd2: reliably crashes (SIGSEGV) on Debian's new arm64 nodes: acker/aagaard

[Paul Wise]

Control: reassign -1 src:linux 4.8~rc8-1~exp1
Control: retitle -1 linux: 4.8 causes crashes in ulogd2 due to bug in netfilter 
code

On Thu, 2016-10-20 at 11:00 +0200, Julien Cristau wrote:

> I think this should just be reassigned, there's not much point working
> around a kernel bug.

Doing that with this mail.

Linux folks: please close this bug when this netfilter patch for Linux
4.8 reaches Debian.

https://patchwork.ozlabs.org/patch/680773/

It is needed for acker.d.o and aagaard.d.o, which run the Linux 4.8
version from Debian experimental.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#826191: linux: build variant for kvmtool aka Clear Containers

[Paul Wise]

Source: linux
Severity: wishlist
X-Debbugs-CC: 817...@bugs.debian.org

It would be nice to have support for Clear Containers in Debian.

https://clearlinux.org/features/clear-containers
http://lwn.net/Articles/644675/

This requires kvmtool (packaged) and a suitable Linux kernel build:

https://sources.debian.net/src/kvmtool/unstable/README

The libguestfs folks have a configuration for that available here:

http://git.annexia.org/?p=libguestfs-talks.git;a=blob;f=2016-kvm-forum/kernel-config-minimal

There is a paper from a future talk of the libguestfs folks here:

http://oirase.annexia.org/tmp/paper.pdf
http://git.annexia.org/?p=libguestfs-talks.git;a=tree;f=2016-kvm-forum

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#821761: linux-image-4.5.0-1-amd64: [regression] switching from gdm Xorg vt to normal virtual console corrupts display until reboot

[Paul Wise]

Control: reopen -1

On Thu, 2016-04-21 at 13:04 +0800, Paul Wise wrote:

> I will reopen if I see this next time I reboot.

I did a bunch of reboot testing with Linux 4.6 from experimental and on
about two-thirds of the reboots I got the problem occurring. During one
boot where the problem did not occur I stopped gdm and started it again
and the problem occurred again. Any thoughts about debugging this?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#821761: linux-image-4.5.0-1-amd64: [regression] switching from gdm Xorg vt to normal virtual console corrupts display until reboot

[Paul Wise]

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

When I upgraded to linux 4.5.1 I found that switching from a gdm Xorg
vt to normal virtual console corrupts the display until I reboot. The
display corruption is not static and is mostly black with some fuzz
around the sides and sometimes pixels from the gdm vt are in the top of
the display. This happens both with and without an external display
plugged into the VGA port on the laptop. This does not happen with 4.4
but it does happen with 4.6 from experimental. I couldn't find any way
to work around this issue other than a reboot.

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 0831CTO
product_version: ThinkPad X201 Tablet
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: 6QET62WW (1.32 )
board_vendor: LENOVO
board_name: 0831CTO
board_version: Not Available

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller 
[8086:0044] (rev 02)
Subsystem: Lenovo Core Processor DRAM Controller [17aa:2193]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor 
Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo Core Processor Integrated Graphics Controller 
[17aa:215a]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ 
TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit 
Latency L0s <1us, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ 
DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- 
Surprise-
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- 
LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- 
Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- 
Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- 
CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID , PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF 
Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, 
OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, 
EqualizationComplete-, EqualizationPhase1-
 EqualizationPhase2-, EqualizationPhase3-, 
LinkEqualizationRequest-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address:   Data: 
Capabilities: [90] Subsystem: Lenovo 5 Series/3400 Series Chipset PCI 
Express Root Port 1 [17aa:2164]
Capabilities: [a0] 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: pcieport
Kernel modules: shpchp

00:1c.4 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI 
Express Root Port 5 [8086:3b4a] (rev 06) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-

Bug#815563: initramfs-tools: conffiles not removed

[Paul Wise]

Package: initramfs-tools
Version: 0.123
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by dh_installdeb
to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
http://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ pkg=initramfs-tools ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg 
| grep obsolete
initramfs-tools: obsolete-conffile /etc/bash_completion.d/initramfs-tools
 /etc/bash_completion.d/initramfs-tools 7eeb7184772f3658e7cf446945c096b1 
obsolete

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (860, 'testing-proposed-updates'), (850, 
'buildd-testing-proposed-updates'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental'), (690, 'buildd-experimental'), (500, 
'unstable-debug'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages initramfs-tools depends on:
ii  initramfs-tools-core  0.123
ii  linux-base4.0

initramfs-tools recommends no packages.

Versions of packages initramfs-tools suggests:
ii  bash-completion  1:2.1-4.2

-- debconf-show failed

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Re: ITP: freefall -- daemon to protect disk for laptops with supported sensors

[Paul Wise]

On Mon, 18 May 2015 12:36:04 +0800 Jesse Sung wrote:

 * Package name : freefall
 * URL :
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/laptops/freefall.c
 * License : GPL
 Description : daemon to protect disk for laptops with supported sensors
 
 The accelerometer drivers for HP and DELL laptops are already available
 in the linux kernel for a while. A daemon is required to handle the
 events generated by the drivers.
 
 This program is included in the kernel source. It will do the user-space
 jobs: to park/un-park disk head when something happens, and make LEDs
 blink accordingly.

I don't think you need to file an ITP for a package that will be built
from the linux source package already in Debian.

I notice that there is another implementation of this idea that supports
more laptops than the Linux one, should these two be merged or what?

https://packages.debian.org/sid/hdapsd

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Re: retiring from security team

[Paul Wise]

On Fri, 2014-09-26 at 14:02 -0600, dann frazier wrote:

  I've been unable to find time to work on kernel security updates for
 some time now and - since I don't see that changing - it is time I
 officially retire from the team. DSA, please remove me from the
 appropriate groups.

Thanks for all your work! Looks like we forgot to remove you from the
team. I've now removed you from the security group in LDAP and applied
Thijs' patch to remove you from the security team mail aliases.

BTW: you might want to transfer kernel.debian.net to a current member of
Debian's Linux kernel team.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Re: Proper way for vendors to build deb packages of kernels.

[Paul Wise]

On Sat, Dec 6, 2014 at 8:24 AM, peter green wrote:

 Does anyone have any other suggestions on what the best way for a vendor to
 take a kernel source tree (not debian derived) and produce deb packages and
 a debian source package from it?

Personally, I think the most useful way to do this would be to get the
needed code/drivers/devicetree into Linux mainline, get that into
Debian backports (or experimental during the freeze) and then build
that version of Linux for Raspbian.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6gpy6qmqhi0suxgkrwt9uejaqr5ms3sggktfis5yrp...@mail.gmail.com

Bug#766195: [PATCH] ipv6: reuse ip6_frag_id from ip6_ufo_append_data

[Paul Wise]

On Fri, 31 Oct 2014 16:36:09 + Ben Hutchings wrote:

 We're going to document the live migration issue rather than fixing it.

At work we are using libvirt guest suspend rather than shutdown across
host reboots. It appears this feature uses migration because now we
cannot start any of our VMs (error below). I am going to do a downgrade
and upgrade dance to work around this bug but I really think that this
issue should be have been fixed rather than documented :(

kvm: Features 0x300fffe3 unsupported. Allowed features: 0x711fbbe3
qemu: warning: error while loading state for instance 0x0 of device 
':00:03.0/virtio-net'

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Re: Removing some kernel-related virtual packages

[Paul Wise]

Do you also plan to get rid of these? They appear to be designed to
block auto-removal of installed linux-image-* and linux-header-*
packages.

/etc/kernel/postinst.d/apt-auto-removal
/etc/apt/apt.conf.d/01autoremove-kernels

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6gqcgeh+ywq_ja64xqhbv3p+76+qvcagtddnscsgn4...@mail.gmail.com

Bug#584656: Closing

[Paul Wise]

Control: reopen -1
Control: reassign -1 src:linux

On Sat, 2013-07-06 at 18:00 +0200, Moritz Mühlenhoff wrote:

 We don't have the ressources to reproduce the complete backlog of all older 
 kernel
 bugs, so we're closing this bug for now. If you can reproduce the bug with 
 Debian Wheezy
 or a more recent kernel from testing or unstable, please reopen the bug by 
 sending
 a mail to cont...@bugs.debian.org with the following three commands included 
 in the
 mail:

I can reproduce this with linux-image-3.10-rc7-amd64 on a completely
different laptop (Thinkpad X201t vs Dell Inspiron). I guess it is a
general problem with Linux on laptops.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#572754: Closing

[Paul Wise]

Control: reopen -1
Control: found -1 3.9.4-1

The bug is still reproducible with Linux from jessie.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#703209: linux: Please Add multiplatform flavour to armhf

[Paul Wise]

On Sun, Mar 17, 2013 at 9:23 AM, Ben Hutchings wrote:

 I would much prefer a name that will provide a more useful distinction
 in future (and not be too long!).  Perhaps it should refer to the CPU
 requirement like the flavours for some other architectures.

How about the same scheme as on other arches?

linux-image-`uname -r`-armel
linux-image-`uname -r`-armhf
linux-image-`uname -r`-arm64

Or maybe the CPU is better:

linux-image-`uname -r`-armv4
linux-image-`uname -r`-armv7
linux-image-`uname -r`-armv8

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#703209: linux: Please Add multiplatform flavour to armhf

[Paul Wise]

On Tue, 2013-03-19 at 15:05 +, Ian Campbell wrote:

 I think the question here is what the `uname -r` bit should be.
 Specifically the $FLAVOUR in 3.x.y-z-$FLAVOUR.

Woops, I missed that uname -r includes the flavour bit.

 I think there is an argument for making the multiplatform case be the
 default no-flavour flavour i.e. $FLAVOUR is armhf/arm64 etc. Or
 maybe that's what you are suggesting having not realised that `uname
 -r` currently includes the -$FLAVOUR suffix. Hrm, I think we may
 actually be talking about the same thing ;-)

Right, my suggestion is just to use the architecture for the flavour, as
is done on the other architectures.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: FYI: open-ath9k-htc-firmware

[Paul Wise]

On Wed, Mar 13, 2013 at 10:13 AM, Hideki Yamane wrote:

  Okay, but they are using patched gcc and binutils for build it.
  So I guess, first it should be merged to upstream gcc/binutils, then
  be added to firmware git repo, right?

No, that is not how the firmware-free source package works. It just
ships pre-built firmware and source but doesn't build anything from
source. So it isn't nessecary to care about if the firmware is
buildable at all. So if you patch the source, you will not get a fixed
version of the firmware.

Personally I think this is the wrong way to go about packaging free software.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#664715: kerneloops: default submission site dead, should not be shipped in wheezy

[Paul Wise]

Package: kerneloops-daemon
Severity: serious
Tags: wheezy sid
X-Debbugs-CC: debian-kernel@lists.debian.org

The default submission site for kerneloops-daemon is dead and does not
appear to be coming back any time soon, despite recentish interest:

https://lkml.org/lkml/2011/6/1/436
https://lkml.org/lkml/2012/2/14/360

Either the package should be removed or the default submission site
should be replaced with one run by the Debian kernel team so that the
package does something useful by default.

Fedora have removed the package since abrt provides similar services
(but Fedora-specific):

http://pkgs.fedoraproject.org/gitweb/?p=kerneloops.git;a=blob;f=dead.package

-- 
bye,
pabs

http://wiki.debian.org/PaulWise



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

Re: Bug#652015: pu: package iotop/0.4-2

[Paul Wise]

On Wed, 2011-12-14 at 19:25 +, Adam D. Barratt wrote:

 Please go ahead; thanks.

Uploaded.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: taskstats capability check in stable

[Paul Wise]

On Wed, 2011-12-14 at 02:12 +, Ben Hutchings wrote:

 This change is likely to be included in 2.6.32.y and, by default, in our
 next stable point release.  As Linus says, this means that unprivileged
 accounts won't be able to run iotop, but this is probably correct
 behaviour.

Thanks for the heads up.

 It appears that older versions of iotop do not report this error in a
 helpful way (#644616).  So I think that if we apply this change to the
 kernel then iotop should also be updated in stable.

It appears the iotop patch applies to the stable version with no
changes. Should I prepare an update and propose it to the release team?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#652015: pu: package iotop/0.4-2

[Paul Wise]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: debian-kernel@lists.debian.org

iotop bug #644616 needs to be fixed in stable because the elevant change
in Linux has been added to the 2.6.32 longterm tree, which the Debian
Linux kernel team intends[1] to add to the next Debian stable point
release. The change in Linux addresses a security issue (CVE-2011-2494)
by removing access to the taskstats interface for non-root users.
Unfortunately iotop relies on this file and therefore it can only run as
root. With the debdiff below iotop will output a friendly message
instead of crashing with a Python traceback.

 1. http://lists.debian.org/1323828773.2825.166.camel@deadeye

--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+iotop (0.4-2+squeeze1) stable; urgency=low
+
+  * Backport patch to give a helpful error instead of crashing when Linux
+denies permission to read the taskstats files (Closes: #644616)
+
+ -- Paul Wise p...@debian.org  Wed, 14 Dec 2011 14:33:20 +0800
+
 iotop (0.4-2) unstable; urgency=low
 
   * Correct bug number in the changelog for previous version.
--- a/debian/patches/0001-Explain-that-iotop-now-requires-root.patch
+++ b/debian/patches/0001-Explain-that-iotop-now-requires-root.patch
@@ -0,0 +1,33 @@
+From: Guillaume Chazarain guic...@gmail.com
+Date: Sat, 15 Oct 2011 18:39:32 +0200
+Origin: upstream, 
http://repo.or.cz/w/iotop.git/commitdiff/635b5838e95ed85767434207e463173fd91b6040
+Bug-Debian: http://bugs.debian.org/644616
+Subject: Explain that iotop now requires root.
+ https://lkml.org/lkml/2011/10/1/170
+ 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1a51410abe7d0ee4b1d112780f46df87d3621043
+--- a/iotop/ui.py
 b/iotop/ui.py
+@@ -446,10 +446,19 @@
+ ui.run()
+ 
+ def run_iotop(options):
+-if options.batch:
+-return run_iotop_window(None, options)
+-else:
+-return curses.wrapper(run_iotop_window, options)
++try:
++if options.batch:
++return run_iotop_window(None, options)
++else:
++return curses.wrapper(run_iotop_window, options)
++except OSError, e:
++if e.errno == errno.EPERM:
++print  sys.stderr, e
++print  sys.stderr, ('iotop requires root or the NET_ADMIN '
++  'capability.')
++sys.exit(1)
++else:
++raise
+ 
+ #
+ # Profiling
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 0001-Do-not-report-requirements-that-are-available.patch
 0002-Document-the-requirement-for-CONFIG_VM_EVENT_COUNTER.patch
+0001-Explain-that-iotop-now-requires-root.patch
 
-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: taskstats capability check in stable

[Paul Wise]

On Wed, 2011-12-14 at 04:32 +, Ben Hutchings wrote:

 Please do.

Proposed in #652015

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#647958: linux 3.1: debconf prompts for iwlwifi-135-IWL135_UCODE_API_MAX.ucode firmware instead of iwlwifi-135-6.ucode

[Paul Wise]

Package: linux-2.6
Version: 3.1.0-1~experimental.1
Severity: normal

I just installed the Linux 3.1 image from experimental and it prompted
for the installation of these firmware files:

iwlagn: iwlwifi-135-IWL135_UCODE_API_MAX.ucode, iwlwifi-105-5.ucode,  
iwlwifi-2030-5.ucode, iwlwifi-2000-5.ucode

The first one is a bug that is fixed by this patch:

http://article.gmane.org/gmane.linux.kernel.wireless.general/77203

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#550534: firmware-iwlwifi: 550534, 626965: new upstream version fixes microcode restarts

[Paul Wise]

On Mon, 2011-07-04 at 03:47 +0100, Ben Hutchings wrote:

 How is an upgrade to the 6000-family microcode going to fix a bug
 reported on a 4965 chip?

Obviously it isn't, but it will fix the same symptoms on 6000-family
chips, so an update would be appreciated.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#550534: firmware-iwlwifi: 550534, 626965: new upstream version fixes microcode restarts

[Paul Wise]

usertags 550534 + bittenby
usertags 626965 + bittenby
thanks

I had this issue with the iwlwifi firmware and constant microcode
software restarts. I reported it upstream and they asked me to try the
latest version. I tried iwlwifi-6000-ucode-9.221.4.1.tgz and found that
it seems to fix the issue for me. Please upgrade to the new version.

http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2300

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#628547: [regression] Debian 2.6.39 reboots when attempting to resume after hibernate

[Paul Wise]

Package: linux-2.6
Version: 2.6.39-1+b1
Severity: important

Whenever I try to resume after hibernate, Debian 2.6.39 reboots instead
of resuming. When I built upstream 2.6.39 I didn't experience this
specific issue (I did get random other problems though). When I try this
on Debian 2.6.38 there are no issues. This leads me to believe that one
of the following is at fault.

  * The diff between the Debian config and the one I used. This is
unlikely, diff below.
  * One of the Debian patches. If there were a git branch of then I
could do a bisect.
  * One of the out-of-tree modules that I used with the Debian
kernel but not the upstream kernel, because I didn't install the
kernel headers package from it. I will test this theory soon.

pabs@chianamo:~$ diff -Naur /boot/config-2.6.39-1-amd64 /boot/config-2.6.39
--- /boot/config-2.6.39-1-amd64 2011-05-24 22:46:30.0 +0800
+++ /boot/config-2.6.39 2011-05-29 10:17:23.0 +0800
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux/x86 2.6.39 Kernel Configuration
-# Tue May 24 13:47:26 2011
+# Linux/x86_64 2.6.39 Kernel Configuration
+# Sun May 29 08:06:49 2011
 #
 CONFIG_64BIT=y
 # CONFIG_X86_32 is not set
@@ -3871,6 +3871,7 @@
 CONFIG_SND_OXYGEN=m
 CONFIG_SND_CS4281=m
 CONFIG_SND_CS46XX=m
+CONFIG_SND_CS46XX_NEW_DSP=y
 CONFIG_SND_CS5530=m
 CONFIG_SND_CS5535AUDIO=m
 CONFIG_SND_CTXFI=m
@@ -4603,6 +4604,8 @@
 CONFIG_XVMALLOC=y
 CONFIG_ZRAM=m
 # CONFIG_ZRAM_DEBUG is not set
+# CONFIG_WLAGS49_H2 is not set
+# CONFIG_WLAGS49_H25 is not set
 # CONFIG_FB_SM7XX is not set
 # CONFIG_VIDEO_DT3155 is not set
 # CONFIG_CRYSTALHD is not set
@@ -5028,7 +5031,6 @@
 CONFIG_ENABLE_MUST_CHECK=y
 CONFIG_FRAME_WARN=2048
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_MAGIC_SYSRQ_DEFAULT_MASK=0x01b6
 CONFIG_STRIP_ASM_SYMS=y
 CONFIG_UNUSED_SYMBOLS=y
 CONFIG_DEBUG_FS=y

-- Package-specific info:
** Version:
Linux version 2.6.39-1-amd64 (Debian 2.6.39-1) 
(buildd_amd64-bra...@buildd.debian.org) (gcc version 4.4.6 (Debian 4.4.6-3) ) 
#1 SMP Tue May 24 14:34:19 UTC 2011

** Command line:
BOOT_IMAGE=/vmlinuz-2.6.39-1-amd64 root=/dev/mapper/chianamo-root ro quiet 
loglevel=0 init=/bin/systemd

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

** Kernel log:
[   66.656600] modem-manager[1985]: info  Loaded plugin Ericsson MBM
[   66.656814] modem-manager[1985]: info  Loaded plugin Nokia
[   66.657038] modem-manager[1985]: info  Loaded plugin Novatel
[   66.657261] modem-manager[1985]: info  Loaded plugin Samsung
[   66.657483] modem-manager[1985]: info  Loaded plugin AnyData
[   66.657708] modem-manager[1985]: info  Loaded plugin Huawei
[   66.657952] modem-manager[1985]: info  Loaded plugin Option High-Speed
[   66.658183] modem-manager[1985]: info  Loaded plugin Generic
[   66.658412] modem-manager[1985]: info  Loaded plugin MotoC
[   66.658687] modem-manager[1985]: info  Loaded plugin Longcheer
[   66.658911] modem-manager[1985]: info  Loaded plugin X22X
[   66.659140] modem-manager[1985]: info  Loaded plugin Wavecom
[   66.748176] polkitd[1989]: started daemon version 0.101 using authority 
implementation `local' version `0.101'
[   66.754220] NetworkManager[1701]: info monitoring kernel firmware 
directory '/lib/firmware'.
[   66.754232] NetworkManager[1701]: SCPlugin-Ifupdown: init!
[   66.754241] NetworkManager[1701]: SCPlugin-Ifupdown: update_system_hostname
[   66.754248] NetworkManager[1701]: SCPluginIfupdown: management mode: 
unmanaged
[   66.754255] NetworkManager[1701]: SCPlugin-Ifupdown: devices added (path: 
/sys/devices/pci:00/:00:19.0/net/eth0, iface: eth0)
[   66.754264] NetworkManager[1701]: SCPlugin-Ifupdown: device added (path: 
/sys/devices/pci:00/:00:19.0/net/eth0, iface: eth0): no ifupdown 
configuration found.
[   66.754275] NetworkManager[1701]: SCPlugin-Ifupdown: devices added (path: 
/sys/devices/pci:00/:00:1c.4/:02:00.0/net/wlan0, iface: wlan0)
[   66.754286] NetworkManager[1701]: SCPlugin-Ifupdown: device added (path: 
/sys/devices/pci:00/:00:1c.4/:02:00.0/net/wlan0, iface: wlan0): no 
ifupdown configuration found.
[   66.754296] NetworkManager[1701]: SCPlugin-Ifupdown: devices added (path: 
/sys/devices/virtual/net/lo, iface: lo)
[   66.754305] NetworkManager[1701]: SCPlugin-Ifupdown: device added (path: 
/sys/devices/virtual/net/lo, iface: lo): no ifupdown configuration found.
[   66.754313] NetworkManager[1701]: SCPlugin-Ifupdown: devices added (path: 
/sys/devices/virtual/net/vboxnet0, iface: vboxnet0)
[   66.754436] NetworkManager[1701]: SCPlugin-Ifupdown: device added (path: 
/sys/devices/virtual/net/vboxnet0, iface: vboxnet0): no ifupdown configuration 
found.
[   66.754477] NetworkManager[1701]: SCPlugin-Ifupdown: end _init.
[   66.754522] NetworkManager[1701]: info Loaded plugin ifupdown: (C) 2008 
Canonical Ltd.  To report bugs please use the NetworkManager mailing list.
[   66.755161] NetworkManager[1701]: info Loaded plugin keyfile: (c) 

Bug#628547: [regression] Debian 2.6.39 reboots when attempting to resume after hibernate

[Paul Wise]

retitle 628547 breaks resume from hibernate with Linux 2.6.39
reassign 628547 virtualbox-ose-dkms
thanks

On Mon, 2011-05-30 at 10:44 +0800, Paul Wise wrote:

   * One of the out-of-tree modules that I used with the Debian
 kernel but not the upstream kernel, because I didn't install the
 kernel headers package from it. I will test this theory soon.

Looks like this theory was correct, when I remove the VirtualBox kernel
modules this issue no longer occurs. Reassigning there.

It appears this might be fixed with version 4.0.6 of VirtualBox.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#625279: [regression] drm-nouveau-Use-pci_dma_mapping_error.patch causes GPU lockup on boot

[Paul Wise]

retitle 625279 [regression] drm-nouveau-Use-pci_dma_mapping_error.patch causes 
GPU lockup on boot
thanks

On Thu, 2011-05-05 at 22:19 +0800, Paul Wise wrote:

 I conclude that it is an issue with the Debian patches.

Mainline 2.6.39 rc5 plus the following patch to gives GPU lockup:

debian/patches/bugfix/all/drm-nouveau-Use-pci_dma_mapping_error.patch

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Debian linux-2.6 configs moved from http://merkel.debian.org/~jurij/?

[Paul Wise]

Hi all,

So merkel is now down and the KernelFAQ wiki pages all indicate that
Debian linux-2.6 configs are on http://merkel.debian.org/~jurij/. Have
they moved somewhere else or are Debian kernel configuration files no
longer available on the web? The merkel URL is the first result for
debian kernel config so it would be good to have a replacement.

In addition this repository seems to be outdated, maybe something for
some cleanup?

http://kernel.alioth.debian.org/debian/

-- 
bye,
pabs

http://bonedaddy.net/pabs3/


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

Re: Debian linux-2.6 configs moved from http://merkel.debian.org/~jurij/?

[Paul Wise]

On Tue, 2011-04-05 at 23:38 +0100, Ben Hutchings wrote:

 I uploaded the current configs for squeeze (release architectures) and
 sid (all defined architectures) to:
 
 http://kernel.alioth.debian.org/config/

Thanks, updated the KernelFAQ wiki pages.

Jurij's page provided a nice introduction and table of versions and
architectures, it would be nice if you could copy that:

http://google.com/search?q=cache:merkel.debian.org/~jurij/

Jurij's script for this is here too:

http://googlecom/search?q=cache:merkel.debian.org/~jurij/sw/getconfig.py

It would also be great to provide all the old configs, maybe grabbing
stuff from snapshot.d.o would help there.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#616639: context menu key does not work on Thinkpad X201 Tablet

[Paul Wise]

Package: linux-2.6
Version: 2.6.37-2
Severity: normal

The context menu key on my keyboard for my new Thinkpad X201 Tablet does
not work, according to evtest and xev it triggers the WakeUp keycode.
Below is an evtest log of me pressing the menu key 10 times and then
Ctrl+C to kill evtest. The data below is for Linux 2.6.38-rc6 from
experimental but it happens with 2.6.37 in unstable too.

# evtest /dev/input/event0
Input driver version is 1.0.1
Input device ID: bus 0x11 vendor 0x1 product 0x1 version 0xab54
Input device name: AT Translated Set 2 keyboard
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
Event code 1 (Esc)
Event code 2 (1)
Event code 3 (2)
Event code 4 (3)
Event code 5 (4)
Event code 6 (5)
Event code 7 (6)
Event code 8 (7)
Event code 9 (8)
Event code 10 (9)
Event code 11 (0)
Event code 12 (Minus)
Event code 13 (Equal)
Event code 14 (Backspace)
Event code 15 (Tab)
Event code 16 (Q)
Event code 17 (W)
Event code 18 (E)
Event code 19 (R)
Event code 20 (T)
Event code 21 (Y)
Event code 22 (U)
Event code 23 (I)
Event code 24 (O)
Event code 25 (P)
Event code 26 (LeftBrace)
Event code 27 (RightBrace)
Event code 28 (Enter)
Event code 29 (LeftControl)
Event code 30 (A)
Event code 31 (S)
Event code 32 (D)
Event code 33 (F)
Event code 34 (G)
Event code 35 (H)
Event code 36 (J)
Event code 37 (K)
Event code 38 (L)
Event code 39 (Semicolon)
Event code 40 (Apostrophe)
Event code 41 (Grave)
Event code 42 (LeftShift)
Event code 43 (BackSlash)
Event code 44 (Z)
Event code 45 (X)
Event code 46 (C)
Event code 47 (V)
Event code 48 (B)
Event code 49 (N)
Event code 50 (M)
Event code 51 (Comma)
Event code 52 (Dot)
Event code 53 (Slash)
Event code 54 (RightShift)
Event code 55 (KPAsterisk)
Event code 56 (LeftAlt)
Event code 57 (Space)
Event code 58 (CapsLock)
Event code 59 (F1)
Event code 60 (F2)
Event code 61 (F3)
Event code 62 (F4)
Event code 63 (F5)
Event code 64 (F6)
Event code 65 (F7)
Event code 66 (F8)
Event code 67 (F9)
Event code 68 (F10)
Event code 69 (NumLock)
Event code 70 (ScrollLock)
Event code 71 (KP7)
Event code 72 (KP8)
Event code 73 (KP9)
Event code 74 (KPMinus)
Event code 75 (KP4)
Event code 76 (KP5)
Event code 77 (KP6)
Event code 78 (KPPlus)
Event code 79 (KP1)
Event code 80 (KP2)
Event code 81 (KP3)
Event code 82 (KP0)
Event code 83 (KPDot)
Event code 85 (Zenkaku/Hankaku)
Event code 86 (102nd)
Event code 87 (F11)
Event code 88 (F12)
Event code 89 (RO)
Event code 90 (Katakana)
Event code 91 (HIRAGANA)
Event code 92 (Henkan)
Event code 93 (Katakana/Hiragana)
Event code 94 (Muhenkan)
Event code 95 (KPJpComma)
Event code 96 (KPEnter)
Event code 97 (RightCtrl)
Event code 98 (KPSlash)
Event code 99 (SysRq)
Event code 100 (RightAlt)
Event code 102 (Home)
Event code 103 (Up)
Event code 104 (PageUp)
Event code 105 (Left)
Event code 106 (Right)
Event code 107 (End)
Event code 108 (Down)
Event code 109 (PageDown)
Event code 110 (Insert)
Event code 111 (Delete)
Event code 112 (Macro)
Event code 113 (Mute)
Event code 114 (VolumeDown)
Event code 115 (VolumeUp)
Event code 116 (Power)
Event code 117 (KPEqual)
Event code 118 (KPPlusMinus)
Event code 119 (Pause)
Event code 121 (KPComma)
Event code 122 (Hanguel)
Event code 123 (Hanja)
Event code 124 (Yen)
Event code 125 (LeftMeta)
Event code 126 (RightMeta)
Event code 128 (Stop)
Event code 139 (Menu)
Event code 140 (Calc)
Event code 141 (Setup)
Event code 142 (Sleep)
Event code 143 (WakeUp)
Event code 152 (Coffee)
Event code 153 (Direction)
Event code 155 (Mail)
Event code 156 (Bookmarks)
Event code 157 (Computer)
Event code 158 (Back)
Event code 159 (Forward)
Event code 163 (NextSong)
Event code 164 (PlayPause)
Event code 165 (PreviousSong)
Event code 166 (StopCD)
Event code 172 (HomePage)
Event code 173 (Refresh)
Event code 184 (F14)
Event code 185 (F15)
Event code 217 (Search)
Event code 226 (Media)
Event code 464 (?)
  Event type 4 (Misc)
Event code 4 (ScanCode)
  Event type 17 (LED)
Event code 0 (NumLock)
Event code 1 (CapsLock)
Event code 2 (ScrollLock)
  Event type 20 (Repeat)
Testing ... (interrupt to exit)
Event: time 1299396921.696436, type 4 (Misc), code 4 (ScanCode), value dd
Event: time 1299396921.696445, type 1 (Key), code 143 (WakeUp), value 1
Event: time 1299396921.696446, -- Report Sync 
Event: time 1299396921.751279, type 4 (Misc), code 4 (ScanCode), value dd
Event: time 1299396921.751289, type 1 (Key), code 143 

Bug#520049: linux-2.6: 520049: images with debugging for iwlwifi?

[Paul Wise]

usertags 520049 + bittenby
thanks 

I noticed that my new laptop (Thinkpad X201t) gets a lot of crashes in
the iwlwifi firmware. I would like to report these issues upstream but
Intel wants the CONFIG_IWLWIFI_DEBUG option to be set. Please reconsider
the wontfix tag on this bug and add kernel images with this config
option turned on to wheezy. I imagine there are a lot of other similar
options in other drivers that would be useful to users having problems
with flaky firmware or newer hardware with different quirks.

http://intellinuxwireless.org/?n=fw_error_report

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#572754: renaming, also occurs on radeon

[Paul Wise]

On Sat, 2010-11-20 at 12:14 +0100, Tomáš Pospíšek wrote:

 I assume this problem is still present with the latest sqeeze kernel?

Yes, even with 2.6.36 from experimental. It is also present on other
architectures, distros and graphics cards. I get it on my OpenMoko
FreeRunner phone (S-Media Glamo GPU) running Debian with 2.6.29-34 and
SHR with 2.6.34. I think I have seen it with nouveau in 2.6.36 too.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Oracle’s Unbreakable Enterprise Kernel - is th ere more to it?

[Paul Wise]

On Wed, Sep 22, 2010 at 4:44 PM, Fabian Greffrath fab...@greffrath.com wrote:

 Oracle recently announced [1] their own 2.6.32-based Unbreakable Enterprise
 Kernel for their RHEL derivative called Oracle Linux. The announcement
 promises severe performance improvements compared to the stock RHEL kernel.

 Do you know what patches they applied to the kernel and if they (or parts of
 them) are acceptable for Debian's linux-2.6 kernel as well?

Some details about that are in the comments on the LWN article:

http://lwn.net/Articles/406199/#Comments
http://lwn.net/Articles/406242/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimyha-n-cpxf3rbtl-z32jpl5a6jk8khge7x...@mail.gmail.com

Re: Bug#594561: firmware-ralink: fails to detect APs at frequency 2.472GHz

[Paul Wise]

On Sat, 2010-08-28 at 17:21 +0200, k...@otaku42.de wrote:

 I have not disappeared.

My apologies, I hadn't received any RFS mail so I incorrectly assumed.

 Nothing was ever sponsored, though multiple permutations of working
 packages were produced and annoying problems were found and discussed
 to no avail.

According to my memory, the packages were ready to upload, just waiting
for you to commit to maintaining them and request that someone upload
them. Would you like me to upload them? What about getting them into
squeeze?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Bug#594561: firmware-ralink: fails to detect APs at frequency 2.472GHz

[Paul Wise]

On Fri, 2010-08-27 at 10:15 +0200, Uwe Kleine-König wrote:

 This might be related to
 
   http://thread.gmane.org/gmane.linux.debian.devel.kernel/54624/
 
 ?  Any news there?

Kel Modderman seems to have disappeared, haven't heard from him in a
long time.

If anyone else wants to join pkg-wpa and step up to maintain the
packaging for crda, I'd be happy to re-issue my offer of sponsorship to
them if pkg-wpa doesn't have sufficient people capable of uploading
directly to Debian. Those who want to test them can do the following:

apt-get install build-essential devscripts debhelper libnl-dev libssl-dev 
pkg-config openssl python python-m2crypto
svn co svn://svn.debian.org/pkg-wpa/crda/trunk crda
cd crda/
uscan --download-current-version
debuild
sudo debi
cd ..
svn co svn://svn.debian.org/pkg-wpa/wireless-regdb/trunk wireless-regdb
cd wireless-regdb/
uscan --download-current-version
debuild
sudo debi
cd ..

I've been using the crda/wireless-regdb packages Kel created for a while
and they seem fine but they need someone to step up to maintain them and
get them into Debian. I don't have time to do that myself but would be
willing to help folks who are interested in doing that.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#584656: linux-image-2.6.32-3-amd64: caps lock key doesn't toggle caps lock LED on virtual console

[Paul Wise]

Package: linux-2.6
Version: 2.6.32-9
Severity: minor

When I switch to a virtual console and press the Caps Lock key, I expect
the Caps Lock LED on my laptop to toggle on and off. The Caps Lock key
does make all the other keys use upper case, just the LED doesn't switch
on. On virtual consoles the Num Lk and Scroll Lk keys both toggle their
LEDs on and off. In Xorg under GNOME the Caps Lock key toggles its LED
on and off fine.

-- Package-specific info:
** Version:
Linux version 2.6.32-3-amd64 (Debian 2.6.32-9) (m...@debian.org) (gcc version 
4.3.4 (Debian 4.3.4-8) ) #1 SMP Wed Feb 24 18:07:42 UTC 2010

** Command line:
BOOT_IMAGE=/vmlinuz-2.6.32-3-amd64 root=/dev/mapper/chianamo-root ro quiet 
loglevel=0 video=i915

** Not tainted

** Kernel log:
[26758.500518] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[26758.720193] [drm] TV-14: set mode NTSC 480i 0
[26758.860598] [drm] TV-14: set mode NTSC 480i 0
[26769.497665] [drm] TV-14: set mode NTSC 480i 0
[26769.638023] [drm] TV-14: set mode NTSC 480i 0
[26773.568196] [drm] TV-14: set mode NTSC 480i 0
[26773.708565] [drm] TV-14: set mode NTSC 480i 0
[26810.040213] [drm] TV-14: set mode NTSC 480i 0
[26810.180225] [drm] TV-14: set mode NTSC 480i 0
[26816.716378] [drm] TV-14: set mode NTSC 480i 0
[26816.856755] [drm] TV-14: set mode NTSC 480i 0
[26823.971862] [drm] TV-14: set mode NTSC 480i 0
[26824.112333] [drm] TV-14: set mode NTSC 480i 0
[26826.068805] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[26828.720452] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[26828.940761] [drm] TV-14: set mode NTSC 480i 0
[26829.082010] [drm] TV-14: set mode NTSC 480i 0
[26836.148505] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27108.932511] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27109.153847] [drm] TV-14: set mode NTSC 480i 0
[27109.294173] [drm] TV-14: set mode NTSC 480i 0
[27119.933153] [drm] TV-14: set mode NTSC 480i 0
[27120.073851] [drm] TV-14: set mode NTSC 480i 0
[27126.457543] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27176.756497] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27176.995037] [drm] TV-14: set mode NTSC 480i 0
[27177.138811] [drm] TV-14: set mode NTSC 480i 0
[27187.764127] [drm] TV-14: set mode NTSC 480i 0
[27187.904579] [drm] TV-14: set mode NTSC 480i 0
[27207.324499] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27209.736493] [drm] TV-14: set mode NTSC 480i 0
[27209.877048] [drm] TV-14: set mode NTSC 480i 0
[27230.284499] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27234.508502] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27234.728149] [drm] TV-14: set mode NTSC 480i 0
[27234.868529] [drm] TV-14: set mode NTSC 480i 0
[27239.824594] [drm] TV-14: set mode NTSC 480i 0
[27239.965238] [drm] TV-14: set mode NTSC 480i 0
[27241.224504] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27242.296797] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27242.516221] [drm] TV-14: set mode NTSC 480i 0
[27242.656582] [drm] TV-14: set mode NTSC 480i 0
[27253.280656] [drm] TV-14: set mode NTSC 480i 0
[27253.420968] [drm] TV-14: set mode NTSC 480i 0
[27261.372488] [drm] TV-14: set mode NTSC 480i 0
[27261.512870] [drm] TV-14: set mode NTSC 480i 0
[27281.580615] [drm] TV-14: set mode NTSC 480i 0
[27281.721135] [drm] TV-14: set mode NTSC 480i 0
[27284.152493] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27362.244520] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27362.464374] [drm] TV-14: set mode NTSC 480i 0
[27362.604752] [drm] TV-14: set mode NTSC 480i 0
[27373.252298] [drm] TV-14: set mode NTSC 480i 0
[27373.392690] [drm] TV-14: set mode NTSC 480i 0
[27389.480469] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27390.772500] [drm] TV-14: set mode NTSC 480i 0
[27390.912930] [drm] TV-14: set mode NTSC 480i 0
[27416.700496] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27431.900544] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27432.136638] [drm] TV-14: set mode NTSC 480i 0
[27432.277017] [drm] TV-14: set mode NTSC 480i 0
[27438.601021] [drm] TV-14: set mode NTSC 480i 0
[27438.741463] [drm] TV-14: set mode NTSC 480i 0
[27440.964775] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27442.292178] [drm] TV-14: set mode NTSC 480i 0
[27442.432221] [drm] TV-14: set mode NTSC 480i 0
[27501.412496] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27502.824502] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27503.045169] [drm] TV-14: set mode NTSC 480i 0
[27503.186453] [drm] TV-14: set mode NTSC 480i 0
[27504.760328] [drm] TV-14: set mode NTSC 480i 0
[27504.900406] [drm] TV-14: set mode NTSC 480i 0
[27506.816631] sr0: CDROM not ready.  Make sure there is a disc in the drive.
[27508.128179] [drm] TV-14: set mode NTSC 480i 0

Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Paul Wise]

On Mon, 2010-03-01 at 10:47 -0500, John W. Linville wrote:

 FWIW, I don't create the tarballs.  Perhaps we could ask Johannes to
 do something in his scripts that create them?  Beyond that I don't
 see much point in checking-in a ChangeLog.

It definitely shouldn't be checked into git, but rather generated from
the git commit logs; with git2cl, git log or similar. With an autotools
based build system you would add a command to the Makefile.am so that
automake runs git2cl during 'make dist' / 'make distcheck'. For
non-autotools based projects you usually won't have a standard 'make
dist' so it would need to be added to whatever script is the equivalent.

 Do you like that git2cl output?  It seems rather ugly to me...

Its the standard ancient GNU form for a ChangeLog. I have no opinion on
its aesthetics and I don't think it matters what format it has really.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Paul Wise]

On Tue, 2010-03-02 at 04:44 +0200, Faidon Liambotis wrote:
 Luis R. Rodriguez wrote:
  Can you guys upstream a package into Debian with a gitweb URL reference?
 If I'm understanding the question correctly, yes. We have Vcs-$VCS (i.e.
 Vcs-Git) and Vcs-Browser pseudo-headers. Both are optional.

The Vcs-* fields are for the Debian package VCS.

There is an emerging project to add upstream metadata to Debian source
packages:

http://wiki.debian.org/UpstreamMetadata

 I agree with Kel here, git2cl et al are unimportant details.

Indeed, that is why the relevant lintian warning is marked pedantic.
Personally I think this part of Debian policy needs a review, I don't
have the time or energy to bring it up on debian-policy though.

 Kel, mail me in private when you have something ready for review 
 upload, as usual.

Check this thread:

http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2010-March/thread.html#2541

He already created almost perfect packages that are pretty-much ready to
be uploaded, just a couple of minor issues.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Paul Wise]

On Sat, 2010-02-27 at 23:59 +0200, Faidon Liambotis wrote:

 I'm a member of pkg-wpa-devel and I've been sponsoring Kel for almost 4
 years. I have absolute trust in him and I've even offered to advocate
 him to the NM process multiple times.

I'd definitely agree with your assessment here and would also encourage
Kel to apply for NM.

 I'd be happy to review and sponsor the uploads of crda/wireless-regdb,
 if Paul doesn't have a problem with this.

Definitely no problem there.

 I usually prefer team maintenance, so I think it'd be best if this
 happened in pkg-wpa; my offer to sponsor is independent of that, though.

Agreed, whoever wants to help maintain this should join pkg-wpa.

So, summary of the main issues with Kel's current package:

He doesn't have time to maintain it and needs folks to join pkg-wpa,
take ownership of the crda RFP (#536502) and work to get both crda and
wireless-regdb uploaded.

It combines crda  wireless-regdb into one source package. While
upstream keeps them separate, we should do the same.

A few other issues that are easy to fix:

http://lists.debian.org/debian-kernel/2010/02/msg00336.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Paul Wise]

On Thu, 2010-02-18 at 09:19 -0800, Luis R. Rodriguez wrote:

 Upstream does not do the same. Ubuntu packages these two together
 right now but it was because it made life easier for packaging.
 
 John, do you guys package wireless-regdb and crda together on Fedora
 land? Was this because of the dynamic key building per package? If so
 what is the restriction on using two packages?

 Thanks John. So -- not sure if Kel will have time to split these, I
 gather he is still pretty busy with his move. Paul, is this a
 requirement for inclusion? If so we'll need to request for some help.

I wouldn't upload it to Debian like that, you might find other people in
Debian who would be willing to do so though.

  nl80211.h looks like it comes from Linux, can't you just build-depend on
  the linux-libc-dev package and do #include linux/nl80211.h ? Comparing
  the crda one and the one from Linux 2.6.32 reveals quite a few changes
  since you copied nl80211.h into crda.
 
 nl80211 is designed to allow userspace applications to either ship
 their own nl80211.h based on the most recent kernel or to ship it and
 ifdef around a feature instead of the kernel version.
...
 For CRDA then we ship our own nl80211.h and it doesn't matter much as
 we only use only one command, and the API that can't change anyway.
 When CRDA wants to make use of something new we can just re-synch,
 just as we do with iw.

Hmm, OK. I guess that makes sense.

  Even after manually ensuring that sha1sum.txt reflects the sha1sum of
  db.txt with sha1sum db.txt  sha1sum.txt, the wireless-regdb Makefile
  still seems to generate a new Debian RSA key pair. If the db.txt hasn't
  changed, there is no reason to auto-generate and install a key pair.
 
 wireless-regdb is designed so that you do not have to run make at all
 if you just intend on using John's key. So running make even if db.txt
 has not changed will generate the keys for you and sign the
 regulatory.bin with the new key.

Hmm, OK. So the Debian packaging should check that db.txt is unchanged,
instead of the upstream Makefile doing that check? I guess that means
Fedora, Gentoo, Ubuntu etc all need to do the same thing.

  dpkg-shlibdeps complains that neither crda and regdbdump use symbols
  from libssl, it looks like this might be a false positive though:
 
  dpkg-shlibdeps: warning: dependency on libssl.so.0.9.8 could be avoided if 
  debian/crda/sbin/regdbdump debian/crda/sbin/crda were not uselessly 
  linked against it (they use none of its symbols).
 
 They are not uselessly linking against libssl if indeed signature
 checking is done.

It looked like a false positive to me, I didn't investigate too closely
though.

  I'd suggest that 'make dist' should include a ChangeLog file in the
  tarball, generated with git2cl or git log or whatever. A NEWS file
  summarising the user-visible changes in each version would also be a
  good idea for both crda and wireless-regdb.
 
 I see little point to maintaining a ChangeLog on these two upstream
 git projects, is this something that has to be done on the package
 debian/* stuff itself then? Is this required for inclusion into
 Debian?

The point is that upstream are already maintaining a ChangeLog with git
and it'd be nice if they included that in the release tarballs (which
don't include the git history) by doing git2cl or git log or whatever in
'make dist' when they create the tarball.

The NEWS file is a separate, hand-maintained file summarising
user-visible changes between different releases.

  I assume that the Debian installer should definitely install
  crda/wireless-regdb on systems that have a wireless card.
 
 Yes, all new wireless devices would use this.
 
  Should it also
  be installed on other systems by default, in case a wireless card gets
  installed?
 
 Yes, I would just always install it, sort of like firmware_request udev stuff.
 
  There is also existing systems to consider, how would you
  recommend crda/wireless-regdb be pulled in? Currently I'm thinking the
  Linux kernel images should Recommend crda; this would pull it in by
  default for those using Debian kernel images but allow those who do not
  need it to remove it. People compiling their own kernel will need to
  install it manually.
 
 That seems fine logic.

Once it is uploaded, I'll be sure to file a bug asking for it to be
added as a recommends of the Linux image packages, thanks for the
advice.

 From what I gather Kel is busy, although he has done all the work for
 this package. How can we request help for this package? I was offering
 to do it but all the new debian/* magic makes me think its best for
 someone else familiar with modern debian packages.

 Please let me know if there is anything I can do to help upstream wise
 to help get this packaged up into Debian.

Hmm, not really sure. We have processes to request help for stuff
already in Debian, but not really anything for new packages that
no-one . You could try emailing the debian-devel list asking for

Re: TCP SYN cookies and Bug #520668

[Paul Wise]

On Sun, Feb 14, 2010 at 2:08 AM, Marco d'Itri m...@linux.it wrote:
 On Feb 13, Ben Hutchings b...@decadent.org.uk wrote:

 The upstream default is that they are disabled.  The onus is on
 proponents to argue why this should be changed.

 The proposed rationale for the change is that SYN cookies are not used
 until the SYN queue is full and at that point it is more useful to have
 new TCP sessions without window scaling than no new TCP sessions at all.
 Do you disagree?

It might be instructive to look at the upstream netdev list, I found a
recentish thread about this topic:

http://lists.openwall.net/netdev/2009/10/16/74

Kinda a dissapointing thread, but it reveals a few points:

http://lkml.indiana.edu/hypermail/linux/kernel/0807.3/0050.html
http://lists.openwall.net/netdev/2009/10/21/42
http://lkml.org/lkml/2008/2/5/167
http://lists.openwall.net/netdev/2009/10/21/70

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Paul Wise]

On Fri, 2010-02-05 at 15:11 -0800, Luis R. Rodriguez wrote:

 And after reviewing this again, I conclude Kel already did all the
 work :) So any mentors / DDs willing to take his package up?
 
 I think its at:
 
 dget -ux http://sidux.net/kelmo/sidux/crap/crda/crda_1.1.1-1.dsc

Ok, here are my comments:

I very much like that it is based on the new shiny debhelper 7 stuff and
dpkg-source v3.

I don't really like that it merges the two packages. I don't think that
is appropriate unless upstream is going to do the same.

nl80211.h looks like it comes from Linux, can't you just build-depend on
the linux-libc-dev package and do #include linux/nl80211.h ? Comparing
the crda one and the one from Linux 2.6.32 reveals quite a few changes
since you copied nl80211.h into crda.

Even after manually ensuring that sha1sum.txt reflects the sha1sum of
db.txt with sha1sum db.txt  sha1sum.txt, the wireless-regdb Makefile
still seems to generate a new Debian RSA key pair. If the db.txt hasn't
changed, there is no reason to auto-generate and install a key pair.

The package FTBFS when built twice in a row:

dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building crda using existing 
./crda_1.1.1.orig-wireless-regdb-20091125.tar.bz2 ./crda_1.1.1.orig.tar.bz2
dpkg-source: error: cannot represent change to 
crda-1.1.1/wireless-regdb-20091125/regulatory.bin: binary file contents changed
dpkg-source: error: add wireless-regdb-20091125/regulatory.bin in 
debian/source/include-binaries if you want to store the modified binary in the 
debian tarball
dpkg-source: error: unrepresentable changes to source

After working around this issue and building again, I get some files in
debian/patches, you probably need to remove .custom on clean:

p...@chianamo:~/tmp/crda-1.1.1$ tail -n4 debian/patches/debian-changes-1.1.1-1
--- /dev/null
+++ crda-1.1.1/wireless-regdb-20091125/.custom
@@ -0,0 +1 @@
+Debian.key.pub.pem

dpkg-shlibdeps complains that neither crda and regdbdump use symbols
from libssl, it looks like this might be a false positive though:

dpkg-shlibdeps: warning: dependency on libssl.so.0.9.8 could be avoided if 
debian/crda/sbin/regdbdump debian/crda/sbin/crda were not uselessly linked 
against it (they use none of its symbols).

V=1 needs to be set on the make command-line so that the buildds
verbosely print all the commands used to build everything.

There are two lintian complaints:

P: crda: no-upstream-changelog
N: 
N:The package does not install an upstream changelog file. If upstream
N:provides a changelog, it should be accessible as
N:/usr/share/doc/pkg/changelog.gz.
N:
N:It's currently unclear how best to handle multiple binary packages from
N:the same source. Some maintainers put a copy of the upstream changelog
N:in each package, but it can be quite long. Some include it in one
N:package and add symlinks to the other packages, but this requires there
N:be dependencies between the packages. Some only include it in a
N:central binary package and omit it from more ancillary packages.
N:
N:Refer to Debian Policy Manual section 12.7 (Changelog files) for
N:details.
N:
N:Severity: pedantic, Certainty: wild-guess
N: 

I'd suggest that 'make dist' should include a ChangeLog file in the
tarball, generated with git2cl or git log or whatever. A NEWS file
summarising the user-visible changes in each version would also be a
good idea for both crda and wireless-regdb.

W: crda: new-package-should-close-itp-bug
N: 
N:This package appears to be the first packaging of a new upstream
N:software package (there is only one changelog entry and the Debian
N:revision is 1), but it does not close any bugs. The initial upload of a
N:new package should close the corresponding ITP bug for that package.
N:
N:This warning can be ignored if the package is not intended for Debian or
N:if it is a split of an existing Debian package.
N:
N:Refer to Debian Developer's Reference section 5.1 (New packages) for
N:details.
N:
N:Severity: normal, Certainty: certain
N: 

Someone needs to step up to be the maintainer of the package, retitle
#536502 to an ITP (intent to package) and set themselves as the owner:

http://bugs.debian.org/536502

I assume that the Debian installer should definitely install
crda/wireless-regdb on systems that have a wireless card. Should it also
be installed on other systems by default, in case a wireless card gets
installed? There is also existing systems to consider, how would you
recommend crda/wireless-regdb be pulled in? Currently I'm thinking the
Linux kernel images should Recommend crda; this would pull it in by
default for those using Debian kernel images but allow those who do not
need it to remove it. People compiling their own kernel will need to
install it manually.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Paul Wise]

On Mon, 2010-02-01 at 09:58 -0800, Luis R. Rodriguez wrote:

 I can help with this only if no one else is up for it. I personally
 however find building a key on the fly for each build pretty pointless
 and would like to know if a package would be acceptable upstream on
 Debian if OpenSSL is used to allow administrators to add their own
 keys into the /etc/wireless-regdb/pubkeys/ dir for CRDA and from the
 start only trust John's key.

As part of upstream, you're probably the best person to do the packaging
stuff for Debian.

The idea was that by default there would be no Debian key installed
because the text and binary databases would be unmodified. The build
system would detect if Debian had patched the databases and if so
generate a new key, sign the binary database with it and install the
public key to the /etc/wireless-regdb/pubkeys/ dir. Debian might need to
patch the database for the stable release.

Thanks for all the information about how wireless card firmware and
drivers interact with regulatory information.

  Hmmm, OK. I guess that makes sense. I imagine it will definitely be the
  source of some annoyance for users in the future though.
 
 Tell me about it, but changing that would mean first getting
 regulatory agencies to allow regulatory compliance to fall down to the
 user when they customize a device's regulatory settings. As it stands
 that is not the case so all we can do upstream for now is allow users
 to enhance compliance, never allow more. There is also the complexity
 of calibration involved in allowing new channels but that is a
 separate topic as well.

There is also the opportunity for user-based advocacy for change in the
regulations. Whenever someone comes to the kernel wireless folks with a
situation where they have been prevented from connecting to a wireless
network because of restrictive wireless regulatory data, explain the
issue and give them a form letter they can send to their local
regulatory agency complaining about the situation and suggesting change.
A list of relevant regulatory agency contact details would be useful
here too I think.

Ideally the manufacturer should be obligated to give users hardware that
can be compliant for any level of radio license and defaults to being
compliant for the default radio license for the whole population. It
would then be up to individual users to comply with the relevant radio
license(s). Such a situation would then turn into a much bigger
enforcement problem, I guess that is the main reason it doesn't work
this way.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Paul Wise]

On Fri, 2010-01-29 at 10:54 -0800, Luis R. Rodriguez wrote:

 Exactly, this is already taken care of upstream with OpenSSL. The
 default directory is /etc/wireless-regdb/pubkeys/

Excellent.

 Patches for this are welcomed upstream on CRDA. Is this a requirement
 for Debian to package CRDA?

No, that was just my personal opinion.

Given the OpenSSL stuff in crda 1.1.1, I don't think there are any
technical roadblocks before crda/wireless-regdb can be uploaded to
Debian (once the packaging implements what I suggested). Debian just
needs someone to be the maintainer for it. IIRC Kel doesn't have the
time. I don't really want to take on yet more packages, but I could
probably offer sponsorship if Kel or others wanted to join pkg-wpa to do
the work. Someone on the Debian kernel team might also be willing to do
either sponsoring or maintainer-ship on this.

Please note that the Debian freeze for the squeeze release is planned
for March, so this stuff needs to be done soon.

 Some embedded solutions might make use of this but even today's
 embedded solutions like openwrt do use CRDA through userspace. The
 CFG80211_INTERNAL_REGDB motivational effort actually came out of the
 incentive to support new 2.6.32 drivers backported on older kernels
 which do not have generic netlink supported. If you want to backport
 proper CRDA support to older kernels and you will deal with proper
 kernel upgrades when regulatory updates are made this is a nice
 option. It also is a good way to finally remove the old crappy
 regulatory stuff we had which had only 3 static regulatory domains
 built in, instead now you can have properly updated static regulatory
 domains based on the same wireles-regdb db.txt.

OK, I guess that sounds reasonable.

 I know of no users yet of this, including on embedded systems. The way
 it works is it will first use the local database first and then call
 CRDA. If CRDA is present then it will update the regulatory
 information based on CRDA.

Great.

  Any idea what proportion of wireless card firmware will respect what
  Linux and crda tell it?
 
 All wireless drivers respect this, regardless of if you have firmware or not.

Cool, but I would imagine ultimately it is up to the firmware to decide
if it will use its own regulatory data or trust what Linux says? 

 Actually all wireless drivers do benefit from it. Note that all new
 wireless drivers upstream are expected to be either cfg80211 based or
 mac80211 based, that's it. The new regulatory infrastructure is part
 of cfg80211 and since all mac80211 drivers are cfg80211 drivers that
 means *every* wireless driver benefits from this and uses it.

Excellent.

 I should note though that some firmware already have their regulatory
 stuff built-in to the firmware, just as some cards are configured on
 their EEPROM to use only one country. In those cases the regulatory
 infrastructure just helps regulatory compliance further, it would
 never allow more channels, for instance.

Hmmm, OK. I guess that makes sense. I imagine it will definitely be the
source of some annoyance for users in the future though.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Paul Wise]

[Please keep me in CC for this thread]

There is a technical change coming in Debian that may mean one key for
the pkg-wpa folks will be more problematic; it is planned that
maintainer-built .debs are to be thrown away on upload (but still
required) and all packages rebuilt on the buildds. There will probably
be the possibility to have exceptions though, so this may turn out to be
a non-issue or less of an issue.

Also, IIRC I wasn't fully happy with the way the signature stuff worked.
My main issue was that the trusted RSA public keys are/were embedded
into the crda binary at build time. I would have much preferred that
they be split out into a set of directories. Something
like /etc/crda/keys/ could be the default. This allows packages to drop
new keys in and for sysadmins to also do that as needed, as well as for
sysadmins to disable keys that have been compromised or similar. With
the dir list and the upcoming buildd change, Debian could use something
like Fedora's option;

  * wireless-regdb could check at build time if the source database
has been modified and a new binary database been rebuilt
  * If so
  * generate a new temporary key at build time
  * sign the new binary database with the temporary
key
  * install the temporary public key
to /etc/crda/keys/
  * throw away the temporary private key
  * If not
  * install the (unmodified) pre-built binary
database

I imagine the OpenSSL stuff in crda 1.1.1 would enable this kind of
option. In addition, crda should have a directory for the sysadmin to
drop in a replacement binary database if for example they wanted to
replace their distro's binary database with a newer version from John
Linville. Since the distros should install John's RSA key, new versions
of the pre-built binary database would be trusted. If the sysadmin
wanted to build their own binary database they would install the
temporary key generated above as well as their new database.

What is the point of having the CFG80211_INTERNAL_REGDB option? That
sounds like a silly thing to do since there is crda and wireless-regdb.
Since 2.6.33 isn't yet released, I assume there is time to change the
behaviour of CFG80211_INTERNAL_REGDB (or remove it). Does
CFG80211_INTERNAL_REGDB mean that crda will be consulted first and if it
cannot be contacted, then the internal copy will be used? You mentioned
the embedded world, I suppose that is the target for it?

Any idea what proportion of wireless card firmware will respect what
Linux and crda tell it? I guess users of old wireless cards with
abandoned or hard-coded firmware will not benefit from crda 
wireless-regdb. I speak here as a user of the ar6000 on the OpenMoko
FreeRunner and a friend of people with ipw2x00-based cards on laptops.
I'm using an iwl3945-based card, do you know if Intel plan to implement
support for this stuff in their firmware?

I thank you very much for working on this stuff.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Paul Wise]

On Fri, 2010-01-29 at 10:57 +0800, Paul Wise wrote:

   * wireless-regdb could check at build time if the source database
 has been modified and a new binary database been rebuilt
   * If so
   * generate a new temporary key at build time
   * sign the new binary database with the temporary
 key
   * install the temporary public key
 to /etc/crda/keys/
   * throw away the temporary private key
   * If not
   * install the (unmodified) pre-built binary
 database

Woops, should have read your references, it seems that something like
this is already enabled by the patch from[1] that is merged upstream?

 1. http://bugs.debian.org/536502

-- 
bye,
pabs

http://bonedaddy.net/pabs3/


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

Re: Xen support on Squeeze

[Paul Wise]

On Sun, Jan 3, 2010 at 9:21 AM, Ben Hutchings b...@decadent.org.uk wrote:
 On Sun, Jan 03, 2010 at 12:01:40PM +1100, Brian May wrote:
 2) I believe KVM needs CPU support, and this is not yet available on all
 modern computers.

 It does require virtualisation extensions, but most x86 processors sold in
 the last few years have them.

With the major exception of most netbooks. A couple of years ago
market segmentation was also an issue, especially with Intel CPUs,
does anyone know if that still occurs?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Bits from the kernel team

[Paul Wise]

On Mon, Dec 21, 2009 at 12:50 AM, Ben Hutchings b...@decadent.org.uk wrote:

  OSS
  ---
 
  This has been a deprecated kernel interface for some time and will be
  disabled for squeeze

 Done.

  with mechanisms put in place to deal with legacy users.

 Er, not sure.

I guess oss4-dkms will be enough to take care of these users,
hopefully it will reach squeeze in time.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#559442: linux-image-2.6.32-rc8-amd64: does not turn screen on after laptop lid close and reopen on virtual consoles

[Paul Wise]

Package: linux-2.6
Version: 2.6.30-8
Severity: normal

When I switch to a virtual console, close the laptop lid and reopen it
again, Linux doesn't turn the LCD screen back on. When I switch to an X
session it gets turned on again. My laptop is a Dell Inspiron 6400 with
Intel GPU. I'm not using KMS yet. This issue occurs with 2.6.32 rc8,
2.6.31, 2.6.30 and I think earlier versions too. The below info is for
2.6.32 rc8, marking the bug as found in 2.6.30 since that is the
earliest version I recently reproduced it in.

-- Package-specific info:
** Version:
Linux version 2.6.32-rc8-amd64 (Debian 2.6.32~rc8-1~experimental.1) 
(wa...@debian.org) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Sat Nov 21 
22:12:25 UTC 2009

** Command line:
BOOT_IMAGE=/vmlinuz-2.6.32-rc8-amd64 root=/dev/mapper/chianamo-root ro quiet 
loglevel=0

** Not tainted

** Kernel log:
[7.929805] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[7.929813]  sdb: sdb1 sdb2
[   11.603418] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[   11.603425] sd 2:0:0:0: [sdb] Attached SCSI disk
[   49.309923] Intel AES-NI instructions are not detected.
[   50.123842] PM: Starting manual resume from disk
[   50.236171] kjournald starting.  Commit interval 5 seconds
[   50.236183] EXT3-fs: mounted filesystem with ordered data mode.
[   53.926143] udev: starting version 146
[   54.744827] dcdbas dcdbas: Dell Systems Management Base Driver (version 
5.6.0-3.2)
[   54.797671] ACPI: WMI: Mapper loaded
[   54.808192] ACPI: AC Adapter [AC] (on-line)
[   55.007580] ACPI: SSDT 5f6d4134 00244 (v01  PmRef  Cpu0Ist 3000 
INTL 20050624)
[   55.008079] ACPI: SSDT 5f6d3ee9 001C6 (v01  PmRef  Cpu0Cst 3001 
INTL 20050624)
[   55.033964] ACPI Warning for \_SB_.BAT0._BIF: Converted Buffer to expected 
String at index 9 (20090903/nsrepair-132)
[   55.033974] ACPI Warning for \_SB_.BAT0._BIF: Converted Buffer to expected 
String at index 10 (20090903/nsrepair-132)
[   55.033981] ACPI Warning for \_SB_.BAT0._BIF: Converted Buffer to expected 
String at index 11 (20090903/nsrepair-132)
[   55.033989] ACPI Warning for \_SB_.BAT0._BIF: Converted Buffer to expected 
String at index 12 (20090903/nsrepair-132)
[   55.034317] processor LNXCPU:00: registered as cooling_device1
[   55.252123] ACPI: SSDT 5f6d4378 000C4 (v01  PmRef  Cpu1Ist 3000 
INTL 20050624)
[   55.259288] ACPI: SSDT 5f6d40af 00085 (v01  PmRef  Cpu1Cst 3000 
INTL 20050624)
[   55.259484] ACPI: Battery Slot [BAT0] (battery present)
[   55.260236] processor LNXCPU:01: registered as cooling_device2
[   55.435226] Synaptics Touchpad, model: 1, fw: 6.2, id: 0x180b1, caps: 
0xa04713/0x20
[   55.470941] input: SynPS/2 Synaptics TouchPad as 
/devices/platform/i8042/serio1/input/input9
[   56.216457] cfg80211: Using static regulatory domain info
[   56.216461] cfg80211: Regulatory domain: US
[   56.216463]  (start_freq - end_freq @ bandwidth), (max_antenna_gain, 
max_eirp)
[   56.216468]  (2402000 KHz - 2472000 KHz @ 4 KHz), (600 mBi, 2700 mBm)
[   56.216472]  (517 KHz - 519 KHz @ 4 KHz), (600 mBi, 2300 mBm)
[   56.216477]  (519 KHz - 521 KHz @ 4 KHz), (600 mBi, 2300 mBm)
[   56.216481]  (521 KHz - 523 KHz @ 4 KHz), (600 mBi, 2300 mBm)
[   56.216485]  (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm)
[   56.216489]  (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm)
[   56.216807] cfg80211: Calling CRDA for country: US
[   56.218787] i801_smbus :00:1f.3: PCI INT B - GSI 17 (level, low) - IRQ 
17
[   56.462176] intel_rng: FWH not detected
[   57.418004] Bluetooth: Core ver 2.15
[   57.418086] NET: Registered protocol family 31
[   57.418088] Bluetooth: HCI device and connection manager initialized
[   57.418093] Bluetooth: HCI socket layer initialized
[   57.591200] Bluetooth: Generic Bluetooth USB driver ver 0.6
[   57.592280] usbcore: registered new interface driver btusb
[   57.920033] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection 
driver for Linux, 1.2.26ks
[   57.920038] iwl3945: Copyright(c) 2003-2009 Intel Corporation
[   57.920181] iwl3945 :0b:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
[   57.920197] iwl3945 :0b:00.0: setting latency timer to 64
[   57.989740] iwl3945 :0b:00.0: Tunable channels: 13 802.11bg, 4 802.11a 
channels
[   57.989745] iwl3945 :0b:00.0: Detected Intel Wireless WiFi Link 3945ABG
[   57.989865]   alloc irq_desc for 26 on node -1
[   57.989869]   alloc kstat_irqs on node -1
[   57.989907] iwl3945 :0b:00.0: irq 26 for MSI/MSI-X
[   58.064671] phy0: Selected rate control algorithm 'iwl-3945-rs'
[   58.142627] HDA Intel :00:1b.0: PCI INT A - GSI 21 (level, low) - IRQ 
21
[   58.142670] HDA Intel :00:1b.0: setting latency timer to 64
[   58.277752] input: HDA Intel Mic at Ext Right Jack as 
/devices/pci:00/:00:1b.0/sound/card0/input10
[   58.277941] input: HDA Intel HP Out at Ext Right Jack as 

Re: Coordinating efforts to get a new kernel in testing?

[Paul Wise]

On Sun, Jul 12, 2009 at 5:29 AM, Frans Pop elen...@planet.nl wrote:

 Like FTBFS of linux-modules-extra-2.6 on 3 architectures I guess? That
 seemed to me like a valid reason not to want to migrate .29 to testing.

Also the armel linux-2.6 FTBFS:

https://buildd.debian.org/fetch.cgi?pkg=linux-2.6;ver=2.6.30-2;arch=armel;stamp=1247068753

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#529719: linux-2.6: please set CONFIG_IDE_TASK_IOCTL=y in Linux build configuration

[Paul Wise]

forcemerge 390616 529719
thanks

On Thu, 2009-05-21 at 12:27 +0200, maximilian attems wrote:

 i don't have the time right now,
 but irc this has been discussed before and it was disabled
 due to troubles in the ide core.
 
 it's worth to search d-kernel for this.

Thanks for the info, merging with the old bug.

Once I upgrade to sid again I'll try to test this option.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#529719: linux-2.6: please set CONFIG_IDE_TASK_IOCTL=y in Linux build configuration

[Paul Wise]

Source: linux-2.6
Severity: wishlist

According to the comments at the URLs below, CONFIG_IDE_TASK_IOCTL=y is
needed to allow hdparm to issue the Secure Erase command to ATA hard
drives. Please add it to the kernel build configuration.

http://freshmeat.net/projects/hdparm/comments
http://www.ocztechnologyforum.com/forum/showthread.php?t=55173

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: add firmware-ipw2x00 to lenny?

[Paul Wise]

On Sun, Jan 4, 2009 at 11:45 PM, Moritz Muehlenhoff j...@inutil.org wrote:


  firmware-nonfree (0.14) unstable; urgency=low
  .
* Generate license acceptation prompt, based on sun-java5. (closes: 
 #504668)
* Add Intel Pro 2100 firwmare, version 1.3. (closes: #504671)
* Add Intel Pro 2200/2915 firwmare, version 3.0. (closes: #449235)

 Indeed, it works very well with my ipw2200.

Unblocked by Maulkin :D

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

add firmware-ipw2x00 to lenny?

[Paul Wise]

Hi all,

Would it be possible to unblock firmware-nonfree 0.14 from unstable?
This would add a firmware-ipw2x00 package so that users with old Intel
wireless on their laptops can have it work out of the box. This is the
kind of thing that might be added to lennyandahalf, but we may as well
add it before the release IMO. I've verified that this makes the
wireless work on an old thinkpad have with me. The changelog is this:

 firmware-nonfree (0.14) unstable; urgency=low
 .
   * Generate license acceptation prompt, based on sun-java5. (closes: #504668)
   * Add Intel Pro 2100 firwmare, version 1.3. (closes: #504671)
   * Add Intel Pro 2200/2915 firwmare, version 3.0. (closes: #449235)

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#506628: linux-2.6: please add usbmon module to the amd64 kernel image

[Paul Wise]

Package: linux-2.6
Severity: wishlist

usbmon.ko is available on most platforms, but it seems to have been
overlooked on amd64. I would like to have it for reverse engineering USB
protocols. I switched from i386 to amd64 since the last time I was doing
that and was surprised to find it was not available.

http://packages.debian.org/file:usbmon.ko

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: firmware-nonfree : ipw2200 ?

[Paul Wise]

On Mon, Oct 27, 2008 at 11:54 PM, Thadeu Lima de Souza Cascardo
[EMAIL PROTECTED] wrote:
 If I've read the FAQ (posted earlier in this thread) correctly, if
 Debian uses a centralized location for license files, which
 /usr/share/doc/packagename/copyright is, then Debian should be able to
 put the license there and does not need to put a copy in the same
 directory as the firmware files.

The FAQ clearly emphasises (with the phrase in addition) that you
still have to place a copy of the license in the same directory as the
firmware even when placing a copy of the license in /usr/share/doc.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#421730: linux-image-2.6.20-1-686: fails to boot from external usb HD - doesn't wait long enough for root device to show up

[Paul Wise]

Package: linux-image-2.6.20-1-686
Version: 2.6.20-1
Severity: normal

I run Debian sid on an external hard drive, which I then move between
machines and boot off it whereever I am able. I've not been able to boot
it with the 2.6.20 images showed up in Debian sid, so I am still using
2.6.18-4. The problem seems to be that the system does not wait for the
root device (/dev/sda1) before attempting to launch init. So, it drops
me into an initramfs prompt whenever booting a 2.6.20 image. I'd rather
not have to use 2.6.18 since it won't receive any updates in Debian sid.

-- System Information:

Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

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

Versions of packages linux-image-2.6.20-1-686 depends on:
ii  initramfs-tools [linux-initra 0.87b  tools for generating an initramfs
ii  module-init-tools 3.3-pre4-2 tools for managing Linux kernel mo
ii  yaird [linux-initramfs-tool]  0.0.12-20  Yet Another mkInitRD

Versions of packages linux-image-2.6.20-1-686 recommends:
pn  libc6-i686none (no description available)

-- debconf information:

  linux-image-2.6.20-1-686/postinst/depmod-error-initrd-2.6.20-1-686: false
  linux-image-2.6.20-1-686/postinst/old-initrd-link-2.6.20-1-686: true
  linux-image-2.6.20-1-686/preinst/already-running-this-2.6.20-1-686:
  linux-image-2.6.20-1-686/preinst/failed-to-move-modules-2.6.20-1-686:
  linux-image-2.6.20-1-686/postinst/create-kimage-link-2.6.20-1-686: true
  linux-image-2.6.20-1-686/preinst/lilo-has-ramdisk:
  linux-image-2.6.20-1-686/prerm/removing-running-kernel-2.6.20-1-686: true
  linux-image-2.6.20-1-686/postinst/bootloader-test-error-2.6.20-1-686:
  linux-image-2.6.20-1-686/preinst/initrd-2.6.20-1-686:
  linux-image-2.6.20-1-686/preinst/lilo-initrd-2.6.20-1-686: true
  linux-image-2.6.20-1-686/postinst/old-system-map-link-2.6.20-1-686: true
  linux-image-2.6.20-1-686/prerm/would-invalidate-boot-loader-2.6.20-1-686: true
  linux-image-2.6.20-1-686/preinst/abort-install-2.6.20-1-686:
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.20-1-686/preinst/overwriting-modules-2.6.20-1-686: true
  linux-image-2.6.20-1-686/preinst/abort-overwrite-2.6.20-1-686:
  linux-image-2.6.20-1-686/preinst/bootloader-initrd-2.6.20-1-686: true
  linux-image-2.6.20-1-686/postinst/bootloader-error-2.6.20-1-686:
  linux-image-2.6.20-1-686/preinst/elilo-initrd-2.6.20-1-686: true
  linux-image-2.6.20-1-686/postinst/kimage-is-a-directory:
  linux-image-2.6.20-1-686/postinst/depmod-error-2.6.20-1-686: false
  linux-image-2.6.20-1-686/postinst/old-dir-initrd-link-2.6.20-1-686: true

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#421730: linux-image-2.6.20-1-686: fails to boot from external usb HD - doesn't wait long enough for root device to show up

[Paul Wise]

On Tue, 2007-05-01 at 19:10 +1000, Paul Wise wrote:

 I run Debian sid on an external hard drive, which I then move between
 machines and boot off it whereever I am able. I've not been able to boot
 it with the 2.6.20 images showed up in Debian sid

I was able to boot linux-image-2.6.20-1-686 2.6.20-3. If I'm able to
boot properly for the rest of this week I'll close this bug.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

fix for console gone with debian 2.6.14/13 kernels

[Paul Wise]

Hi,

I had a problem with the console not working with recent kernels
(debian's 2.6.14/13 images). I found out this is fixed by adding fbcon
to the yaird configs:

pabs3 trave11er: adding fbcon to yaird configs fixed lack of console
trave11er pabs3: good
trave11er pabs3: make sure yaird people are aware of that
trave11er and initramfs-tools
pabs3 k
trave11er i think the consensus has formed by now that it should be
just added to initrd

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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