Bug#436267: Working DV video over firewire
I am not sure if this has progressed any more and if any decision has been drawn up, the thread has been a little quiet. I just wanted to express that from a user perspective I would be surprised if I installed a modern Linux distribution and I could no longer use a DV connection to edit my videos. I have been using etch to do this for a while now and it works fine. In fact I was using etch as I was having problems configuring the correct modules to use for 1394 on another distribution. I am all for change and development. but I have always looked to Debian to supply a sane, working and stable system. Currently I have that with etch and hope to have that for lenny. -- Daniel Phillips
Bug#489995: linux-image-2.6.24-1-amd64: Kernel NULL pointer dereference in NFS server
On Wed, Jul 09, 2008 at 07:09:35AM +0200, Fredrik Tolf wrote: > Package: linux-image-2.6.24-1-amd64 > Version: 2.6.24-7 > Severity: normal > > I'm not sure what triggers it (it seems completely random), but every > once in a while, my NFS server will log an Oops message in the kernel > NFS server. It does seem to be recoverable, but I doubt it's a good > thing. The dmesg from the event is as follows: > please install 2.6.25 from unstable and see if it fixes it for you. (installs just fine in testing) thanks -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#481104: [Pkg-cryptsetup-devel] /usr/sbin/update-initramfs: update-initramfs edits /etc/initramfs-tools/conf.d/cryptroot
On Sun, July 6, 2008 17:54, [EMAIL PROTECTED] wrote: > maximilian attems wrote: >> right send output of >> a) sh -x mkinitramfs -o /tmp/foo >> b) sh -x update-initramfs -u > > Sending requested outputs a) -> out1, b) -> out2 Ok, I see the problem. During the initramfs build, mkinitramfs will ln -s all config files into the build dir. Later when the cryptsetup hook is executed it will write config lines to the cryptroot config file in the build dir (which is linked to the /etc... file outside the build dir). I'm not 100% sure how we should solve this (why do you have a cryptroot file by the way? It's supposed to be a cryptsetup internal config file). Perhaps the best way to "handle" it would be to detect a symlink'ed config file in the cryptsetup initramfs hook and to explode...on the other hand, this is a problem in general since any other hook/script might also want to write config files from their hook script and the same problem will happen to them. An alternative solution would be to move the step where external config files are copied into the initramfs to a later stage in the mkinitramfs run and allow mkinitramfs to check if it's about to overwrite already written config filesmaks? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#481104: [Pkg-cryptsetup-devel] /usr/sbin/update-initramfs: update-initramfs edits /etc/initramfs-tools/conf.d/cryptroot
David Härdeman wrote: On Sun, July 6, 2008 17:54, [EMAIL PROTECTED] wrote: maximilian attems wrote: right send output of a) sh -x mkinitramfs -o /tmp/foo b) sh -x update-initramfs -u Sending requested outputs a) -> out1, b) -> out2 Ok, I see the problem. During the initramfs build, mkinitramfs will ln -s all config files into the build dir. Later when the cryptsetup hook is executed it will write config lines to the cryptroot config file in the build dir (which is linked to the /etc... file outside the build dir). I'm not 100% sure how we should solve this (why do you have a cryptroot file by the way? It's supposed to be a cryptsetup internal config file) If I understood your question well, my answer is this: I have /etc/initramfs-tools/conf.d/*cryptroot containing the line: **target=lukspace,source=/dev/hda3,key=none,lvm=vg-root* because I have my root partition sitting on LVM, which sits on LUKS. So, somehow the initrd image must know that it has to find a LUKS partition and ask me for its passphrase. I hope I'm not talking nonsense. When I tried to set up encrypted root partition, I used googling, a bit hacking and imagination. So, there is the possibility that an easier method eludes me. Cheers, Giorgos smime.p7s Description: S/MIME Cryptographic Signature
Bug#482074: linux-image-2.6.25-2-686: version 2.6.25-4 locks too
using linux-image-2.6.26-rc9-686 (2.6.26~rc9-1~experimental.1~snapshot.11810) for 2 days. It's as stable as 2.6.24. thanks, Marcello Nuccio 2008/7/8 Marcello Nuccio <[EMAIL PROTECTED]>: > linux-image-2.6.26-rc9-686 (2.6.26~rc9-1~experimental.1~snapshot.1) > works fine. > > thanks, > Marcello > > > 2008/7/4 maximilian attems <[EMAIL PROTECTED]>: >> On Thu, 29 May 2008, Marcello Nuccio wrote: >> >>> Package: linux-image-2.6.25-2-686 >>> Version: 2.6.25-4 >>> Followup-For: Bug #482074 >>> >>> same problem after the upgrade from 2.6.25-3. >>> 2.6.24-* works fine. >>> >>> Marcello Nuccio >> >> could you please try 2.6.26-rc8 linux images, >> see apt trunk lines >> -> http://wiki.debian.org/DebianKernel >> >> thanks >> >> -- >> maks >> > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#481104: [Pkg-cryptsetup-devel] /usr/sbin/update-initramfs: update-initramfs edits /etc/initramfs-tools/conf.d/cryptroot
On Wed, July 9, 2008 10:51, Giorgos D. Pallas wrote: > David Härdeman wrote: >> ... (why do you have a cryptroot file by the way? It's supposed >> to be a cryptsetup internal config file) > > If I understood your question well, my answer is this: I have > /etc/initramfs-tools/conf.d/*cryptroot containing the line: > **target=lukspace,source=/dev/hda3,key=none,lvm=vg-root* > because I have my root partition sitting on LVM, which sits on LUKS. So, > somehow the initrd image must know that it has to find a LUKS partition > and ask me for its passphrase. > > I hope I'm not talking nonsense. When I tried to set up encrypted root > partition, I used googling, a bit hacking and imagination. So, there is > the possibility that an easier method eludes me. Yes, the "correct" method would be to create a /etc/crypttab file with the mapping for your root device. See the documentation in /usr/share/doc/cryptsetup for details on how to do that. Once a proper crypttab is setup, cryptsetup will automagically generate initramfs config files for you. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Tue, 8 Jul 2008 09:15:14 +0200 maximilian attems <[EMAIL PROTECTED]> wrote: > > > > When a new stable *is* uploaded, D-I should be able to switch > > faster too (at least, if there's someone willing to do the initial > > kernel-wedge work) as the main criterium for D-I to switch to a new > > kernel version is: does the new version look about to be ready to > > migrate to testing, which current early uploads of the kernel to > > unstable effectively never are. > > > never seen that, d-i has always been dragging. > As a poor simple user, this seems mistaken. Correct me if I'm wrong, but isn't it the case that d-i quickly comes out once a kernel is in *testing* so the problem with "d-i dragging" is really that the kernel team doesn't support testing only unstable (from the sounds of it). I mean in another email max says that testing is on an unsupported kernel. WTF. .24 isn't that old and I'm not sure if .25 is even in testing yet (when I last checked it wasn't). Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org No more sea shells: Daniel's Webloghttp://cshore.wordpress.com signature.asc Description: PGP signature
Re: Selection of kernel for Lenny
Daniel Dickinson <[EMAIL PROTECTED]> writes: > On Tue, 8 Jul 2008 09:15:14 +0200 > maximilian attems <[EMAIL PROTECTED]> wrote: > >> > >> > When a new stable *is* uploaded, D-I should be able to switch >> > faster too (at least, if there's someone willing to do the initial >> > kernel-wedge work) as the main criterium for D-I to switch to a new >> > kernel version is: does the new version look about to be ready to >> > migrate to testing, which current early uploads of the kernel to >> > unstable effectively never are. >> >> >> never seen that, d-i has always been dragging. >> > > As a poor simple user, this seems mistaken. Correct me if I'm wrong, > but isn't it the case that d-i quickly comes out once a kernel is in > *testing* so the problem with "d-i dragging" is really that the kernel > team doesn't support testing only unstable (from the sounds of it). I > mean in another email max says that testing is on an unsupported > kernel. WTF. .24 isn't that old and I'm not sure if .25 is even in > testing yet (when I last checked it wasn't). For d-i matters if the kernel is ready (or almost ready) to migrate to testing since it's very problematic for us to break user installation using daily images during the Debian kernel stabilization effort that, today, is done in unstable. Testing kernel, nowadays, is indeed unsupported since to update it is much harder and risk since the kernel doesn't have a period of time on unstable (it needs to go throught testing-proposed-updates) before hitting testing. What we're proposing is a change on that. Leaving those first uploads some time on experimental and then moving to unstable when major problems were solve (as is done in many other teams as Xorg, KDE, GNOME, ...) and then reducing the time required for the kernel to migrate from unstable to testing. Doing that, it would allow us to move d-i much fastly to the unstable kernel since we'd be in a much safe bed. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#481104: [Pkg-cryptsetup-devel] /usr/sbin/update-initramfs: update-initramfs edits /etc/initramfs-tools/conf.d/cryptroot
David Härdeman wrote: > On Wed, July 9, 2008 10:51, Giorgos D. Pallas wrote: > >> David Härdeman wrote: >> >>> ... (why do you have a cryptroot file by the way? It's supposed >>> to be a cryptsetup internal config file) >>> >> If I understood your question well, my answer is this: I have >> /etc/initramfs-tools/conf.d/*cryptroot containing the line: >> **target=lukspace,source=/dev/hda3,key=none,lvm=vg-root* >> because I have my root partition sitting on LVM, which sits on LUKS. So, >> somehow the initrd image must know that it has to find a LUKS partition >> and ask me for its passphrase. >> >> I hope I'm not talking nonsense. When I tried to set up encrypted root >> partition, I used googling, a bit hacking and imagination. So, there is >> the possibility that an easier method eludes me. >> > > Yes, the "correct" method would be to create a /etc/crypttab file with the > mapping for your root device. See the documentation in > /usr/share/doc/cryptsetup for details on how to do that. > > Once a proper crypttab is setup, cryptsetup will automagically generate > initramfs config files for you. > Not to my surprise, you were right :-) I just deleted the /etc/initramfs-tools/conf.d/cryptroot file, and run again update-initramfs -u. Laptop boots fine. Btw, I already had /etc/crypttab correctly configured, so it seems that the cryptroot file was redundant. So, probably the bug has to be closed since it was a consequence of a wrong practice, if I got it right. Thanks for all, Giorgos smime.p7s Description: S/MIME Cryptographic Signature
Bug#385553: linux-modules-extra-2.6: Please provide pre-built ndiswrapper modules
Daniel Baumann wrote: > Any progress on ndiswrapper? > Kel Modderman wrote: > Vcs-Svn and Julian was planning to have an upload sponsored soon. I guess > he has been busy, I've just been patiently waiting for the transfer to occur. > > Julian, please let us know how we should proceed, we should get upstream > version 1.53 in the archive ASAP. Sorry, I wasn't at home in the last 2 weeks. Should get uploaded this week. I will do some final builds and tests and see if my AM sponsors it, else I will look for another sponsor. ETA: 3d (maximum) -- Julian Andres Klode, Fellow of the Free Software Foundation Europe Debian Maintainer | Developer | Ubuntu Member try Debian: http://www.debian.org/ | my site: http://jak-linux.org/ jabber: [EMAIL PROTECTED] | IRC: juliank (FreeNode, OFTC) languages: German | English signature.asc Description: OpenPGP digital signature
Bug#385553: linux-modules-extra-2.6: Please provide pre-built ndiswrapper modules
Julian Andres Klode wrote: > Sorry, I wasn't at home in the last 2 weeks. Should get uploaded this > week. I will do some final builds and tests and see if my AM sponsors it, > else I will look for another sponsor. take your time - there won't be a 2.6.25 upload anymore anyways; please directly head for 2.6.26. Regards, Daniel -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#490108: linux-2.6: please enable CONFIG_X86_P4_CLOCKMOD
Package: linux-2.6 Version: 2.6.25-6 Severity: wishlist Hi, desktop x86 cpus before Core 2 Duo don't have (enhanced) speedstep, so they can't use acpi-cpufreq nor speedstep-centrino to do frequency scaling. However, they can use p4-clockmod to do frequency throttling, which is not as good as frequency scaling but still can be useful. http://www.kernel.org/pub/linux/utils/kernel/cpufreq/hardware.html has a list of which hardware is supported for which module. So it'd be nice if CONFIG_X86_P4_CLOCKMOD (and CONFIG_P4_CLOCKMOD on i386 I guess) could be enabled. Cheers, -- Yves-Alexis Perez -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-rc9-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489190: ps/2 not working in 2.6.24
FWIW, I am having exactly the same problem. The mouse is not detected with the 2.6.24 and 2.6.22 amd64 kernel packages in Lenny. 2.6.18 works just fine though. The 2.6.18 kernel in etch works too.. Any information I can provide about this? I found this: http://bugzilla.kernel.org/show_bug.cgi?id=10382 But this is a regression *from* 2.6.24. I decided to mention it because you might have picked a patch from the broken tree. -- Guillaume Morin <[EMAIL PROTECTED]> Do you worry that you're not liked ? How long till you break ? (Our Lady Peace) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385553: Bug#484019: Bug#385553: linux-modules-extra-2.6: Please provide pre-built ndiswrapper modules
Hi Jak, Daniel,
(Dropped Bart from CC)
On Thursday 10 July 2008 05:16:20 Daniel Baumann wrote:
> Julian Andres Klode wrote:
> > Sorry, I wasn't at home in the last 2 weeks. Should get uploaded this
> > week. I will do some final builds and tests and see if my AM sponsors it,
> > else I will look for another sponsor.
No worries, I figured you were busy with life.
>
> take your time - there won't be a 2.6.25 upload anymore anyways; please
> directly head for 2.6.26.
The following patch will be required for 2.6.26, it has been submitted to
ndiswrapper upstream and requires testing. Jak, pick it up if you like.
Thanks, Kel.
---
Adapt to Linux 2.6.26 WEXT API change.
Add compat defines for iwe_stream_add_{event,point,value}() and
iwe_stream_lcp_len() in reaction to change in WEXT API [0] of Linux 2.6.26.
Based on patches committed to Madwifi [1,2].
[0]
http://git.kernel.org/?p=linux/kernel/git/davem/wireless-2.6.git;a=commitdiff;h=ccc580571cf0799d0460a085a7632b77753f083e
[1] http://madwifi.org/changeset/3750
[2] http://madwifi.org/changeset/3760
Signed-off-by: Kel Modderman <[EMAIL PROTECTED]>
---
--- a/driver/iw_ndis.c
+++ b/driver/iw_ndis.c
@@ -1015,7 +1015,16 @@
return 0;
}
-static char *ndis_translate_scan(struct net_device *dev, char *event,
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 26)
+#defineiwe_stream_add_event(a, b, c, d, e) iwe_stream_add_event(b,
c, d, e)
+#defineiwe_stream_add_point(a, b, c, d, e) iwe_stream_add_point(b,
c, d, e)
+#defineiwe_stream_add_value(a, b, c, d, e, f) \
+ iwe_stream_add_value(b, c, d, e, f)
+#defineiwe_stream_lcp_len(...) IW_EV_LCP_LEN
+#endif
+
+static char *ndis_translate_scan(struct net_device *dev,
+struct iw_request_info *info, char *event,
char *end_buf, void *item)
{
struct iw_event iwe;
@@ -1034,7 +1043,8 @@
iwe.u.ap_addr.sa_family = ARPHRD_ETHER;
iwe.len = IW_EV_ADDR_LEN;
memcpy(iwe.u.ap_addr.sa_data, bssid->mac, ETH_ALEN);
- event = iwe_stream_add_event(event, end_buf, &iwe, IW_EV_ADDR_LEN);
+ event = iwe_stream_add_event(info, event, end_buf, &iwe,
+IW_EV_ADDR_LEN);
/* add essid */
memset(&iwe, 0, sizeof(iwe));
@@ -1044,13 +1054,15 @@
iwe.u.data.length = IW_ESSID_MAX_SIZE;
iwe.u.data.flags = 1;
iwe.len = IW_EV_POINT_LEN + iwe.u.data.length;
- event = iwe_stream_add_point(event, end_buf, &iwe, bssid->ssid.essid);
+ event = iwe_stream_add_point(info, event, end_buf, &iwe,
+bssid->ssid.essid);
/* add protocol name */
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWNAME;
strncpy(iwe.u.name, network_type_to_name(bssid->net_type), IFNAMSIZ);
- event = iwe_stream_add_event(event, end_buf, &iwe, IW_EV_CHAR_LEN);
+ event = iwe_stream_add_event(info, event, end_buf, &iwe,
+IW_EV_CHAR_LEN);
/* add mode */
memset(&iwe, 0, sizeof(iwe));
@@ -1061,7 +1073,8 @@
iwe.u.mode = IW_MODE_INFRA;
else // if (bssid->mode == Ndis802_11AutoUnknown)
iwe.u.mode = IW_MODE_AUTO;
- event = iwe_stream_add_event(event, end_buf, &iwe, IW_EV_UINT_LEN);
+ event = iwe_stream_add_event(info, event, end_buf, &iwe,
+IW_EV_UINT_LEN);
/* add freq */
memset(&iwe, 0, sizeof(iwe));
@@ -1076,7 +1089,8 @@
/* convert from kHz to Hz */
iwe.u.freq.e += 3;
iwe.len = IW_EV_FREQ_LEN;
- event = iwe_stream_add_event(event, end_buf, &iwe, IW_EV_FREQ_LEN);
+ event = iwe_stream_add_event(info, event, end_buf, &iwe,
+IW_EV_FREQ_LEN);
/* add qual */
memset(&iwe, 0, sizeof(iwe));
@@ -1090,7 +1104,8 @@
iwe.u.qual.noise = WL_NOISE;
iwe.u.qual.qual = i;
iwe.len = IW_EV_QUAL_LEN;
- event = iwe_stream_add_event(event, end_buf, &iwe, IW_EV_QUAL_LEN);
+ event = iwe_stream_add_event(info, event, end_buf, &iwe,
+IW_EV_QUAL_LEN);
/* add key info */
memset(&iwe, 0, sizeof(iwe));
@@ -1101,11 +1116,12 @@
iwe.u.data.flags = IW_ENCODE_ENABLED | IW_ENCODE_NOKEY;
iwe.u.data.length = 0;
iwe.len = IW_EV_POINT_LEN;
- event = iwe_stream_add_point(event, end_buf, &iwe, bssid->ssid.essid);
+ event = iwe_stream_add_point(info, event, end_buf, &iwe,
+bssid->ssid.essid);
/* add rate */
memset(&iwe, 0, sizeof(iwe));
- current_val = event + IW_EV_LCP_LEN;
+ current_val = event + iwe_stream_lcp_len(info);
iwe.cmd = SIOCGIWRATE;
if (bssid->length > sizeof(*bssid))
nrates = NDIS_MAX_RATES_EX;
@@ -1115,26 +
Bug#481190: ps/2 mouse not working in 2.6.24
There is a similar report in the ubuntu bug tracker: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/95785 -- Guillaume Morin <[EMAIL PROTECTED]> I love you, I love you like a chocolate cake, like the trains, like the sea. See me loving you, please. (Dionysos) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
