[00:16] mjg59: does the modprobe in initramfs look after blacklists because vesafb is blacklisted in module-init-tools [00:16] and it writes that is not loaded [00:21] hi [00:22] hi caetano Tonho maskd :) [00:22] hlw [00:22] thotypous: you dont will do this sugestion [00:22] hey guys, I would like to ask if ubuntu would support a change from ALSA to OSS4 from 4tech-tech in it's official kernel [00:22] is stupid :~ likes theses users [00:23] Tonho, hey, please more respect [00:23] why, alioth is here o.O [00:23] thotypous: No [00:23] mjg59, why? [00:23] OSS is far more easy to develop than ALSA, and is portable (every UNIX uses OSS) [00:24] Because it would be an unnecessary divergence away from the direction everyone else is going [00:24] we thin that if ubuntu changed to OSS4, everyone else would rethink using ALSA [00:24] we think* [00:24] thotypous: I really doubt that [00:25] OSS is on the deprecation track. [00:25] rtg: The existing in-kernel code, yes [00:25] but not OSS4 [00:25] OSS has been maintained outside the kernel and is being picked up by Open Solaris [00:25] (Which I don't think is an especially compelling argument, given relative market share) [00:25] and the new OSS suports a good alsa emulation [00:26] the oss emulation from alsa is very poor [00:26] the guys at dracolinux recently adopted OSS4 besides ALSA, so the slackware users should support it [00:26] ubuntu support would result easily in debian support [00:27] No [00:27] slackware support -> arch support [00:27] Debian make their own decisions [00:27] arch support -> gentoo support [00:27] and going on [00:27] I'm wondering what the problem you're trying to solve is? [00:27] Once OSS4 is upstream, then there's a chance Ubuntu will adopt it [00:27] But while it's out of tree, no. Sorry. [00:27] you can easyly install the deb from oss4 [00:28] no problem at all, alsa is blacklisted then [00:28] thotypous: o.O wtf you want this? any special problem? [00:28] is very hard to work with sound in unix actually [00:28] yes [00:28] you've to program to unix, to linux and to windows [00:29] all unixes uses oss, but linux [00:29] yes, that's the point [00:29] the new oss4 is, I guess, very good, and full stuff [00:29] All Unixes other than Linux are irrelevant as far as the desktop is concerned [00:30] Other than MacOS. Which doesn't use OSS. [00:31] as far as the desktop is concerned i believe linux IS irrelevant... [00:31] but portability, simplicity and API homogeneity is always important [00:32] thotypous: And having us diverging from the rest of the Linux market would do nothing to improve API homogeneity. You're kidding yourself if you think Red Hat or Suse will ship OSS without it being in the upstream kernel. [00:32] I think Linus would be influenced by a Ubuntu decision [00:33] No. Really, no. [00:33] what about it if Mark Shuttleworth supported this decision? [00:33] Mark is one member of the technical board [00:33] (I'm another) [00:34] Right now, I wouldn't support this decision [00:34] so you can help us :D [00:34] in the technical board [00:34] So you'd have to convince the other two [00:35] and convince mjg59 too; he doesn't sound convinced. [00:35] ah, but now we know who to convince :D [00:35] and FWIW I haven't seen anything convincing in this discussion [00:37] mjg59, what do you think it needs to OSS for becoming mainstream again? [00:37] For a start, it needs alsa emulation that works - http://www.4front-tech.com/forum/viewtopic.php?t=2434 suggests that that really isn't the case at the moment [00:38] Then you need to convince Linus to accept it back into the kernel, and to do that you'll have to demonstrate that it's significantly better than alsa in ways that aren't easy to fix [00:39] hmmm thanks for the hints :) [01:05]

as far as the desktop is concerned i believe linux IS irrelevant... [01:06] actually, linux (total) officially has 1.5% market share on the Belgian desktop market ;) [01:07] (or had, almost a year ago) [01:10] :) [01:10] and Mac OS X dis have 1.8% of the market [01:10] s/dis/did/ [01:11] so linux is/was very close to the most-used unix-like OS... [01:13] and at that time, Vista did have 3.3% market share, and Ubuntu did have 0.3% market share... [01:15] this report was compiled from research conducted in March & April 2007 (so almost 1 year ago) [02:11] rtg: how about adding my patch to lum? === asac_ is now known as asac [05:49] moin === \sh_away is now known as \sh === \sh is now known as \sh_away === \sh_away is now known as \sh [11:24] BenC: did you get my initramfs-tools mail? [11:58] can some kernel developer review (and possibly approve) proposed blacklisting of garmin_gps, see bug 114565 [11:58] Launchpad bug 114565 in module-init-tools "native Garmin-USB no longer working" [Medium,Triaged] https://launchpad.net/bugs/114565 [12:02] hi rtg [12:07] rtg: when do you want to commit my patch? [12:51] amitk, rtg: http://users.tkk.fi/~tjaalton/dpkg/lrm.diff [12:52] obviously the version number is wrong [15:12] You gotta love this: "Note : The syntek USB 2.0 video camera driver for DC-1125 ans STK-1135 is currently being developed on Linux. This driver can do damages. Use this driver only if you know what you are doing." [15:12] what damages could a web cam do other then oops ? [15:19] hi rtg [15:19] Kano: I'm working on it. [15:19] well what is wrong with the patch? [15:19] Kano: nothing as far as I know. [15:20] did you look at dmraid45 too? [15:20] not yet [15:21] Kano: in fact, it slipped my mind because it didn't come through the kernel-team mailing list for general comment. [15:21] when i have got a makefile that creates 3 modules [15:21] MODULES := adv717x.o bt865.o em8300.o [15:22] do i just the same and write obj-m +=? [15:23] Kano: yep. But if you plan to submit these for inclusion in lum, I want one patch per driver. [15:23] thats really a bad idea... [15:24] it is one driver with 3 submodules === smb_away is now known as smb [15:25] Kano: then that appears to satisfy my criteria. [15:25] well i just would use internal header instead of global [15:25] as patch [15:28] but it needs firmware the em8300 driver [15:28] Do we have permission to distribute that firmware? [15:29] Hm. It seems to be in the em8300 package. [15:29] dont know, there are 2 ways, internal or external [15:30] We go with external [15:30] The firmware loader is there for a reason [15:31] or just as external package the driver, it is a bit uncommon [15:32] 0.16.4 would work === finer_recliner is now known as finerrecliner [15:34] but it is needed for vdr [15:34] when you want to use it as external device [15:34] thats nice because then you can use vdr over tv+remote control and do something else with the pc [15:40] the simple fix would be: fetch new em8300 package from sid (there is 0.16.4) [15:41] interestingly this is one module for inclusion in linux-modules-contrib-2.6... [15:45] do we have like a kernel of the day thing yet? [15:46] zul: it almost works, but I haven't turn it on for regular builds. I still need to mess with lum. [15:47] im just looking for -8 so I can update the drbd stuff [15:47] zul: -8 has some FTBS issues cause by dpkg that I'm working on. [15:48] x86 and x86_64 built OK. [15:48] just need x86 :) [15:48] zul: this is easy.just run 2 scripts ;) [15:49] uh, I better check that for sure. [15:50] zul: yes, x86* _did_ build. No lum/lrm/lbm etc yet. [15:50] just need the headers so I can do a test build locally shouldnt I? [15:51] lum does build too [15:51] zul: that ought to work. [15:51] rtg: thanks.. [16:22] tjaalton: I'll pick up the lrm changes as soon as I figure out the kernel FTBS on sparc/ia64/hppa. [16:26] rtg: ok, thanks! [16:27] nvidia-settings mess should be sorted now, finally.. [16:28] how do I check the module dependencies of a module? [16:30] tjaalton: you mean in modules.dep? [16:30] rtg: well, nvidia.ko, but I guess 'depmod nvidia.ko' or similar should work? [16:32] just to check if it depends on some other module, but.. wouldn't that violate GPL? [16:32] tjaalton: as long as its in the /lib/moduels/`uname -r` directory, it'll get sorted correctly. [16:33] I'm aware of that ;) [16:33] this is for envyNG [16:33] the patch uses insmod, and that fails unless all the dependancies are already loaded [16:34] ah right, I'll grep the modules.dep :) [16:34] tjaalton: oh, you didn't say that. Why wouldn't the patch use modprobe? [16:35] because it uses a special path [16:36] nvidia_legacy.ko doesn't depend on any other modules, but nvidia.ko and _new.ko depend on i2c-core.ko [16:37] <_MMA_> Hi guys. Alessio brought to my attention the desire to pull -rt into main. I have no objection. I just wonder if there's any foreseeable benefit? [16:37] tjaalton: hmm, there doesn't appear to be a way to specify a modprobe search order unless you use a modprobe.conf. [16:39] rtg: right.. but it seems that loading i2c-core before the driver is enough [16:39] so it's not a huge problem [16:39] _MMA_: uh, I think that was deferred to hardy+1 pending mainline inclusion of the -rt patchset. [16:40] <_MMA_> Oh sure, I just wonder to what end? What's the point? :) [16:40] tjaalton: so you just hardwire that in the patch? I mean 'modprobe i2c-core' just before the insmod. [16:40] tseliot: hey, we were discussing your patch. It seems that insmod would fail unless i2c-core is loaded before loading the driver [16:40] rtg: right [16:41] _MMA_: if the -rt patchset were upstream, then its a lot less work for maintainers. [16:42] <_MMA_> No no. "Main" as in our "main" repo. [16:42] <_MMA_> Why does it matter if its in Main or Universe? [16:43] _MMA_: well, it doesn't matter to me. I'm a kernel guy :) [16:43] tjaalton: I talked to mdomsch about this [16:45] and my patch shouldn't be necessary since the module is installed in /lib/modules/2.6.24-5-generic/updates/dkms [16:45] which should have higher priority [16:45] tseliot: oh [16:46] tjaalton: I'm trying to see if the problem is the fact that we use nvidia_new, legacy, etc. [16:46] otherwise it's module-init's fault [16:46] <_MMA_> rtg: Sure. I'm just chattin' here. Being in Universe now doesn't really lower its barrier to contribution and moving to Main wouldn't change that. We can build disks from Universe for Ubuntu Studio now. Also just because its in Main doesn't mean its Canonical supported. Just wondering the point of the move is all. [16:46] ok, so we'll put the patch on hold for now [16:47] tjaalton: I'll let you know if I manage to solve the problem myself [16:47] tseliot: ok [16:47] see you later [16:47] _MMA_: for that you'll have to consult someone politically wiser then myself in the ways of Debian. [16:48] <_MMA_> :P [16:48] * _MMA_ shoulda went to the meeting yesterday. [16:48] tjaalton: so, you gonna rip out the envy-dkms part of that patch? [16:49] of the lrm patch. I mean. [16:53] rtg: sure, a sec [16:54] tjaalton: no rush. I'm still working on kernel FTBS issues. [17:38] rtg: ok, done [17:38] same url [17:38] tjaalton: please email it to kernel-team also, so I don't lose it. [17:39] I sent an email there already, but I'm not on the list so it's queued [17:39] that was for the earlier patch, but the url is there [17:39] tjaalton: I know the list admin :) [17:40] hehe [17:40] so it seems to be there now === stefanb is now known as smb_away [17:45] tjaalton: I've just sent the new (ridiculously small patch) [17:46] together with a ridiculously long email :-P [18:15] mjg59: what do you know about asus-laptop v.s. asus_acpi ? https://bugs.edge.launchpad.net/ubuntu/+bug/184721 contends that asus_acpi should be blacklisted, though I see no signs that the kernel is deprecating this driver. [18:15] Launchpad bug 184721 in module-init-tools "linux-source-2.6.22-2.6.22 ships with deprecated asus_acpi.ko" [Medium,Triaged] [18:16] I'm under the impression that asus_laptop is the way forward [18:16] Ought I add it to lum then? [18:16] Probably, yeah [18:16] Though isn't it in-kernel already? [18:16] ok [18:16] That might just be .25 [18:17] no, only asus_acpi as far as I can tell. Would it be someplace other then acpi? [18:17] Yes [18:17] misc [18:18] ah, indeed. [18:18] amitk: I'm trying to get the linux-2.6.24-lpia kernel source package and I could not find it. where (deb-src URL) can I find it? [18:20] jayc: which ABI version do you want? [18:20] you can also pull it from git. [18:21] rtg: I'm looking for ABI -7 [18:22] rtg: I would like to get the orig.tgz file so that I could upload the source to ubuntu-mobile [18:22] jayc: one sec... [18:23] jayc: 'dget http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.24-7.12.dsc' [18:24] rtg:So I can get the orig.tgz from there? [18:24] dget will pull all of the files required to build. Until we have an official release candidate, I have not generated an orig.tar.gz. [18:25] the diffs are just too large, and therefore largely useless. [18:27] rtg:So then I will upload the entire hardy-ume kernel source to ubuntu-mobile PPA then. Thanks [18:28] jayc: yep. just do a 'dput *.changes' and it will figure it out. [18:28] rtg: got it :-) [18:29] jayc: there is a script in Hardy kernel that shows how to prepare a PPA upload: debian/scripts/misc/ppa-cron-job [18:29] its part of the daily kernel build infrastructure. [18:29] (which I have yet to turn on) [18:34] rtg:how can I use it, I don't upload to ppa regularly? you suggets me to just take a look at the script and see if it helps me? [18:35] jayc: yeah, its informational only. [18:35] ok [18:37] heya jayc, I see rtg has already helped you out [18:37] amitk: yes [18:37] amitk: slacker, ya been napping ? [18:38] rtg: it's called "keeping the significant-other engaged' [18:39] amitk: ah, she who must be obeyed :) [18:50] btw. did you see the new ati 8-02 driver [18:51] has aiglx support for xserver 1.4 [18:51] Kano: that is tjaalton's domain [18:52] i dont use lrm but you should fix compiz detection [18:52] and let fglrx work [18:52] after adding it.. [19:08] rtg: you can include it :) [19:08] changing the tarball is painful, btw [19:09] since there are changes outside the debian-directory [19:09] tjaalton: oh, feel free to do it :) I'm kind of buried. [19:09] hehe [19:09] rtg: ok, I'll see what I can do [19:10] with feature freeze approaching, I'm trying to get some last minute stuff done. [19:10] Kano: fglrx is already whitelisted [19:10] tjaalton: in the standard package or via fglrx override? [19:11] i mean when you add it to lrm, the 8-02 [19:11] for hardy [19:11] Kano: the compiz wrapper [19:11] WHITELIST="nvidia intel ati radeon i810 fglrx" [19:12] ok [19:12] but it doesn't seem to work that well, at least not for everyone [19:13] so hopefully this version is better in that regard [19:15] well best add Option "XAANoOffscreenPixmaps" [19:15] Kano: Nghno. [19:16] do what you like, i dont need lrm ;) [19:16] If you want to disable a large chunk of 2D acceleration, sure [19:16] But it's not terribly sensible in general [19:16] We've got code in the X server that effectively does that dynamically [19:16] but thats even faster when you disable it [19:17] At the cost of increasing CPU usage, perhaps [19:17] But that's very machine dependent [19:35] right, that option is not needed [19:36] ati webpage still shows the old driver [19:36] ah, updated now === smb_away is now known as stefanb [20:54] rtg: Thanks for looking into bug 188226, I've commented there - after/while reading some kernel documentation. [20:54] Launchpad bug 188226 in linux "Kernel should use CONFIG_FAIR_CGROUP_SCHED" [Wishlist,In progress] https://launchpad.net/bugs/188226 [20:57] blueyed: I'm waiting for some feed back from the server team as well. I think its probably too late to implement any userland support for this. Feature freeze is tomorrow. [21:01] rtg: did you see errors like http://www.linuxforums.org/forum/peripherals-hardware/53991-harddrive-errors.html [21:01] for your current kernel? [21:02] this happens for some users [21:03] also dma is off for my dvd drive (nforce3 chipset) [21:04] this is not the case when you use pata_nv instead [21:08] rtg: yeah, too bad.. would be quite simple though and only changing the config would be also better. [21:09] I've tried to get feedback on this for quite some time (since 2.6.24 entered hardy)... === AndyP_ is now known as AndyP === RemoteVi1wer is now known as RemoteViewer [23:03] rtg: when were you planning to do the linux-meta bump? I could update lrm in ~8h [23:35] scsi_mod: value -6917529019036584304 out of IMM22 range [23:35] FATAL: Error inserting scsi_mod (/lib/modules/2.6.15-51-mckinley/kernel/drivers/scsi/scsi_mod.ko): Invalid module format [23:35] * lamont grumbles at he dapper kernel;