[00:30] <dtchen> cjwatson: at least from inspecting current git HEAD of anaconda, it seems the PAE is indeed quite straightforward: (from isys/isys.py:711)   if line.startswith("flags") and line.find("pae") != -1:
[00:30] <dtchen> err, "the PAE check"
[00:33] <cjwatson> dtchen: ok, thought so
[00:33] <cjwatson> my question about how the heck we're going to actually account for both sets of users on a single CD stands, though ...
[00:34] <cjwatson> (but I see Tim has answered. Fair enough. I guess time will tell)
[00:35] <cjwatson> (and any bugs I get about it will be unceremoniously reassigned to the kernel! :-) )
[00:41] <Sarvatt> is the default i386 generic kernel switching to PAE? or is there going to be a PAE flavor?
[00:42]  * Sarvatt hopes its not the former for the sake of all intel graphics users :D
[00:45] <Sarvatt> (because GEM doesnt work with PAE)
[00:48] <cjwatson> *blink* that's news to me
[00:48] <cjwatson> shame rtg left a while back ...
[00:49] <cjwatson> the proposal was to leave -generic alone but basically only offer it for netboot/DVD users; that may be a bit of a roadblock
[00:59] <jjohansen> it might be but there are work around patches that can be applied if the real fix doesn't land for .31
[01:04] <maxb> ogasawara: I don't agree with wontfixing that bug based on that mail link. The bug is about "Why are these packages no longer in the archive", the mail thread is about "How do I build these packages locally"
[01:04] <maxb> "Debug packages are so large that they are only built on the buildd's." does not explain why the debug packages built on the buildds are not then published to the archive
[01:05] <ogasawara> maxb: feel free to add a comment
=== cjwatson_ is now known as cjwatson
[01:07] <cjwatson> Sarvatt: I've brought the GEM issue up on the mail thread, thanks
[01:31] <Sarvatt> is there really alot of demand for the default kernel to be PAE on x86? I would think most everything with >4gb ram is going to be x64 compatable so it's down to NX vs the performance overhead and incompatability issues with PAE.. theres some discussion on it in this thread - http://thread.gmane.org/gmane.linux.kernel/843866
[01:38] <cjwatson> lots of people don't want to use amd64 on desktops because then they have to deal with 32-bit compatibility libraries and argh nightmare pain
[01:48] <cjwatson> but yeah, interesting comments from Linus there
[08:27] <ikepanhc> hi apw
[08:30] <apw> hi
[08:32] <ikepanhc> apw: could you look at https://bugs.launchpad.net/bugs/276949, is that ok?
[08:32] <ubot3> Malone bug 276949 in linux "No driver for HP Webcam - 15b8:6002" [Medium,Triaged] 
[08:37] <apw> ikepanhc, what do you need me to see?
[08:38] <ikepanhc> apw: the last comment I just sent
[08:38] <apw> ok, the statement seems factual
[08:39] <ikepanhc> I try to, I just afraid bug reporter will be disapoint
[08:42] <apw> they are always dissapointed when we cannot do everything for them
[08:42] <apw> if you have asked smb and he is against then thats that
[08:43] <apw> we will have a release before long, and have given them an unofficial kernel which supported the camera
[08:44] <ikepanhc> thanks, I will ask smb's story or viewpoint
[08:44] <apw> yep... he can aways comment on the bug if there is dissent
[08:44]  * apw looks if the patch is in stable
[08:45] <ikepanhc> that is not a short patch
[08:52] <apw> that indeed is the  issue, big patches == risk
[09:26] <smb> Ideally I would like a stable topic branch to be like the mainline builds. So you can install it simply to try out stuff
[09:27] <smb> and you could switch between the official one and the other
[09:27] <zeroprog> hey guys i just installed karmic koala and it says that it is built on kernel 2.6.30 but when i do uname -r it says 2.6.28....and i cannot find the source with the correct patches so that i can set up a proper driver dev environment
[09:28] <smb> If we got that, then a pocket in the kernel-team ppa might be the place to put it
[09:29] <smb> zeroprog, Was that a clean install/chroot/or upgrade?
[09:29] <zeroprog> clean install
[09:29] <apw> smb, yeah i tend to agree with all of that
[09:29] <apw> zeroprog, the kernel should indeed be 2.6.30
[09:30] <zeroprog> hmm.....it says 2.6.28-11.....which doesnt have a source package i guess
[09:30] <smb> zeroprog, exactly. the uname output comes from the kernel... Just to rule that out /proc/version says the same?
[09:31] <zeroprog> yes smb
[09:31] <apw> zeroprog, can you paste the output of cat /proc/version_signature please
[09:31] <smb> zeroprog, 2.6.28 is the Jaunty kernel
[09:31] <zeroprog> cat /proc/version
[09:31] <zeroprog> Linux version 2.6.28-11-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009
[09:31] <smb> That is the Jaunty release kernel
[09:31] <apw> how about the output of: dpkg -l | grep linux-image
[09:32] <zeroprog> dpkg -l |grep linux-image
[09:32] <zeroprog> ii  linux-image-2.6.28-11-generic              2.6.28-11.42                              Linux kernel image for version 2.6.28 on x86
[09:32] <zeroprog> ii  linux-image-generic                        2.6.28.11.15                              Generic Linux kernel image
[09:32] <smb> And maybe to check sanity, check what /etc/apt/source.list has as release
[09:32] <apw> and the output of: cat /etc/lsb-release
[09:33] <zeroprog> ok it says distrib is jaunty but i just bought an ubuntu book with a karmic koala cd
[09:34] <apw> finally check /etc/apt/sources.list
[09:34] <smb> apw, and yeas. I think we are on the same track there. I hope we can allocate a slot to think just about the versioning. The rest might be simple enough
[09:34] <apw> zeroprog, it claims to be karmic, thats not even released
[09:34] <smb> zeroprog, Interesting yeah ^^^
[09:34] <smb> Chances are rather that they have a Jaunty CD
[09:34] <zeroprog> really....it was supposed to be beta
[09:35] <smb> zeroprog, alpha
[09:35] <apw> karmic is only at alpha2
[09:35] <zeroprog> yes alpha sorry
[09:35] <apw> hmmm... then it is possible that the CD was taken at alpha1
[09:35] <apw> zeroprog, the easiest way forward is likely to run update-manager -d
[09:35] <apw> and then take the option to update to karmic
[09:35] <smb> apw, Not if sources.list is wrong
[09:36] <apw> update-manager will sort that out in theory
[09:36] <smb> Or aeh
[09:36] <smb> You are right
[09:36] <zeroprog> well id prefer to stay on jaunty because it is stable...but i still cannot get the source for it 
[09:36] <apw> zeroprog, ok so what is the actual issue?
[09:37] <apw> what source are you trying to get
[09:37] <zeroprog> i keep getting the invalid format when compiling a simple module .... extension is ko
[09:37] <apw> can you paste the commands you are doing and all of the output into a pastebin and point us to it
[09:38] <zeroprog> well i went to kernel.org and downloaded 2.6.28
[09:39] <zeroprog> http://pastebin.com/d21a8f2fd
[09:39] <smb> zeroprog, One thing (probably not really related) The kernel 2.6.28-11 looks like you never did any sort of update on that system. The current updates kernel would be 2.6.28-14.33
[09:39] <apw> zeroprog, so are you trying to enable something specific?
[09:40] <zeroprog> yes ive just installed this within the last two days after using hardy heron for a year
[09:40] <zeroprog> just the ability to write device drivers heh
[09:40]  * smb wonders wheter this might be "make menuconfig"
[09:40] <apw> ok that paste has no errors?
[09:40] <zeroprog> hardy is working fine on my alernative notebook but this one seems to be giving me trouble
[09:41] <smb> Though that should not be required to get an external module to build
[09:41] <zeroprog> there are no errors everything installs fine
[09:41] <apw> except you complained about errors?
[09:41] <zeroprog> invalid format hello.ko
[09:41] <apw> right that is an error, who says it where from what command
[09:41] <zeroprog> from make
[09:42] <smb> zeroprog, Does dmesg say something at the end
[09:42] <smb> like disagrees about version
[09:42] <zeroprog> yes 
[09:42] <apw> ok so when i asked for the command and the errors, those were the ones i was referring to
[09:43] <zeroprog> disagrees with symbol struct_module
[09:43] <apw> you need to be running your installed kernel
[09:43] <apw> before you can load up modules which you built for it]
[09:43] <apw> your uname says you are running the ubuntu kernel, not your built kernel there
[09:44] <smb> This might be just an external module tree. Not a complete kernel
[09:44] <zeroprog> it says im running a generic kernel
[09:45] <smb> zeroprog, the place you run the make commands. Is that just containing ou hello world module?
[09:45] <zeroprog> yes
[09:45] <apw> paste the uname -r output again
[09:45] <zeroprog> 2.6.28-11-generic
[09:46] <apw> that is not a generic kernel, that is the ubuntu generic flavour
[09:46] <apw> the mainline kernel would say 2.6.28
[09:46] <zeroprog> the vanilla kernel yes but that failed so i tried this one
[09:48] <apw> right but modules are specific to the kernel you built them for
[09:48] <apw> so you either need to be running the mainline kernel and make modules for that
[09:48] <apw> or you need to be running the ubuntu kernel and need to make modules for that
[09:48] <apw> the two will not mix in either combination
[09:49] <apw> you should be able to make modules for the ubuntu kernel using the headers
[09:49] <apw> they should contain enough to allow 'out of tree' compilation of a module
[09:49] <smb> Were there any linux-headers-generic installed?
[09:50] <zeroprog> i tried that also....how do i install the mainline kernel?
[09:50] <zeroprog> yes smb
[09:51] <apw> it sounds like you already did, from those commands
[09:51] <apw> when you say 'it failed' what does that mean
[09:51] <zeroprog> id get the invalid format hello.ko error
[09:51] <apw> so somehow you are not making the module for either kernel it seems
[09:53] <zeroprog> i am sketchy at makefiles but heres mine http://pastebin.com/d3a99a3cd
[09:53] <zeroprog> i just switched it to the headers 
[09:53] <smb> The danger lies in the absolute path for the headers
[09:54] <zeroprog> i dont see it
[09:54] <smb> normally you go through /lib/modules/$(uname -r)/build
[09:54] <smb> make -C /usr/src/linux-headers-2.6.28-11-generic M=$(PWD) modules
[09:55] <smb> ^ here you force it to use that path. That might not be your running kernel
[09:55] <apw> thats the one
[09:56] <apw> make -C /usr/src/linux-headers-`uname -r` M=`pwd` modules
[09:57] <smb> or "make -C /lib/modules/`uname -r`/build M=`pwd` modules"
[09:57] <smb> same for clean
[09:57] <zeroprog> i get target /path/to/my/src does not match target pattern
[09:59] <smb> That is another problem. You usually want to mask the all part when the kernel compile looks at the makefile
[09:59] <smb> hell what was that again
[10:00] <zeroprog> im sorry what do u mean by mask
[10:01] <smb> ifeq ($(KERNELRELEASE),)
[10:01] <smb> <here comes your all>
[10:01] <smb> else
[10:01] <smb> obj-m += hello.ko
[10:01] <smb> endif
[10:02] <smb> That way, when you run make, you go into the upper branch and call the kernel make
[10:02] <zeroprog> ahh ok
[10:03] <smb> then that sets KERNELRELEASE and calls your makefile again and only sees the obj-m
[10:03] <zeroprog> is there a separator or some sort or is it the way you typed it
[10:04] <smb> The part between ifeq and else certainly has to be replaced. The rest might or might not be correct, given I just typed from my head
[10:06] <zeroprog> yeah im getting a missing separator error
[10:07] <smb> And just another note: I really do not understand the "make menu config" part. That sounds slightly like useless (or even dangerous) voodoo
[10:07] <zeroprog> the tutorial i read on installing and setting up the kernel source said to do it 
[10:07] <zeroprog> actually it was the README
[10:08] <zeroprog> alright ive bothered u guys enough thanks for the help ill try to figure the rest out on my own
=== mdz_ is now known as mdz
[10:22] <tjaalton> hey, I have no 3G with my thinkpad in karmic, worked in jaunty (and with the jaunty kernel)
[10:23] <tjaalton> I wonder if the kernel thinks it's disabled or something
[10:24] <tjaalton> filed bug 386528, will attach the dmesg output now..
[10:24] <ubot3> Malone bug 386528 in linux "[karmic] No sierra 3G with 2.6.30, works with 2.6.28" [Undecided,New] https://launchpad.net/bugs/386528
[10:24] <smb> tjaalton, Is the 3G visible in lspci -vvvnn (and has a module loaded)?
[10:24] <mvo> hello! looking at https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-karmic-flavours its not entirely clear to me what the new names will be linux-generic (with PAE) and linux-legacy (without) - what about linux-386? is that going to go away? what about -server, -virtual? -rt? etc? 
[10:25] <smb> apw, Actually what was that ubuntu-bug incarnation that collects all kind of usefull data
[10:25] <tjaalton> smb: the module was listed in /etc/modules, so it's loaded, but can't see anything with lspci
[10:26] <apw> ubuntu-bug linux i thought
[10:26] <tjaalton> and the command is apport-collect ###, but I'd need to clear the lp auth first
[10:26] <apw> there is also apport-collect something to add it to another bug
[10:26] <tjaalton> where is the cookie stored?
[10:26] <smb> But given the fact it is not in lscpi looks a bit suspicious
[10:27] <smb> anyhow
[10:27] <tjaalton> I'll try .27
[10:27] <apw> mvo, the linux-386 version will remain in ports as far as i know
[10:27] <tjaalton> make that .28
[10:27] <smb> mvo, -rt has been a community kernel anyways
[10:28] <apw> mvo, the -server is likely to remain unchanged name wise.  -rt is a port flavour and not part of the review
[10:28] <smb> -386 a ports kernel (also community)
[10:29] <smb> I think that leaves virtual which anyways was a repackaged server kernel
[10:29] <tjaalton> smb: actually, it's a usb device, but lsusb doesn't show it either
[10:30] <mvo> thanks - so I will add code then that transitions from "generic" -> "legacy" if no PAE is available for now
[10:30] <smb> tjaalton, Heh, ok. Wrong lead then. Hm usb...
[10:31] <mvo> I'm still wondering what to do about -386 for people with old installs/upgrades. I guess it makes sense to transition them to -generic if they have PAE 
[10:31] <mvo> ?
[10:32] <smb> mvo, If they have PAE that would make sense. What we were not quite clear is people without and possibly cpus not even up to M586
[10:34] <mvo> right. if PAE is safe I start with that, if there is a additional combination of flags/information to look at, I'm happy to add them too
[10:34] <smb> tjaalton, Just a very wild guess as all the usb modules have been compiled in in jaunty too. maybe you could experiment with unbinding the (crap which one was usb1) ehci driver
[10:34] <mvo> I just want to be very careful not to transition people to a kernel that does not boot 
[10:34] <smb> mvo, We tried to start of with cpus whe have on that page.
[10:35] <mvo> smb: should I add info there as well for my machines (also I have mostly relatively recent ones)?
[10:35] <mvo> i.e. is that useful for you?
[10:36] <smb> mvo, Tentiatively it feels like getting info about the ones that might break (the older) being more helpful. apw, what would you say?
[10:36] <tjaalton> smb: ok I'll try. .28 shows it ok, sierra wireless 1199:6813
[10:37] <apw> smb, yeah agree with that
[10:38] <mvo> the oldest in use I have is a P3-mobile, I guess that is not really very helpful 
[10:38] <mvo> thanks, I think I got enough info to add basic transition support
[10:41] <tjaalton> smb: hmm you mean not building EHCI_HCD in the kernel?
[10:41] <apw> mvo, there were people who were transistioned onto the 386 ports kerenl who prolly should not have been when upgrading
[10:42] <apw> from pre hardy->hardy which are worth considering in the transition
[10:42] <smb> tjaalton, No, actually (without any experience) I thought it should be possible to use sysfs to unbind the driver from activeness...
[10:42] <mvo> apw: there is no code in update-manager that would do a transition like this, they probably had -386 installed before? 
[10:43] <mvo> apw: -386 -> -generic is done if they run a SMP kernel, but thats aobut all the magic there is currently
[10:43] <tjaalton> smb: ah. ok
[10:43] <apw> right, thats the issue.  older releases the i386 kernel was the default, they updated and ended up on the ports kernel, not thorough an action but through inaction
[10:44] <apw> you mentioned pulling them up to pae if they had support, it is worth considering pulling them up to -legacy if they have 586 and above
[10:44] <mvo> right, I know about this problem, I would love to fix it, but I need a reliable way to know what machines should not be transitioned
[10:44] <mvo> I do not want to transition everyone and end up with some machines no longer booting
[10:45] <mvo> ok, if 586 is good, I can certainly do that
[10:45] <smb> mvo, Yeah, we need the support of all low-level-cpu loving folks out there
[11:08] <tjaalton> smb: it's possible to unbind a device from the driver, but the device isn't bound anywhere..
[11:09] <cjwatson> can we please not call the non-PAE kernel "legacy"?
[11:10] <cjwatson> firstly, having names that are basically "old" and "new" runs into rather obvious trouble when you need a third; we found that with nvidia
[11:10] <cjwatson> descriptive names are *always* better
[11:10] <cjwatson> secondly, as I said in e-mail, I'm concerned about the likely performance of using PAE everywhere when it isn't necessary and I think "legacy" is considerably overoptimistic
[11:11] <apw> cjwatson, i thought the flip side was that the security people were very keen to have it turned on for NX
[11:11] <cjwatson> there are lots of considerations
[11:12] <cjwatson> but I don't think they're simple enough that we can just say "screw you guys, you're legacy"
[11:12] <apw> not trying to dismiss your concerns
[11:12] <cjwatson> I linked to a comment from Linus that was basically "people who turn on HIGHMEM64G are crackheads"
[11:12] <cjwatson> but anyway, why not just have value-neutral names?
[11:13] <cjwatson> Tim used -generic and -generic-pae in another place, which seemed reasonable
[11:13] <apw> yep, that part is separate and obvious
[11:14] <apw> as in i  htink we should separate the naming issues as against the how to choose the appropriate kernel issues
[11:14] <cjwatson> yes
[11:19] <apw> cjwatson, your thread as i see it has no mention of naming, we should inject that into that thread, as it seems to be the master discussion on this feature
[11:23] <cjwatson> that's because Tim's original mail in that thread used names I didn't object to :-)
[11:27] <cjwatson> apw: I've injected it now
[11:31] <apw> cjwatson, thanks thats excellent
[11:45] <tjaalton> smb: looks like the sierra doesn't work even with mainline 2.6.29.5
[11:53] <apw> cjwatson, in what form is the kernel on the CD image.  is there a full kernel install, as in the .deb installed?
[11:54] <cjwatson> which CD image?
[11:54] <apw> hrm, i was thinking of the live ones
[11:54] <cjwatson> the .deb's just installed in the live filesystem
[11:54] <apw> thats what i assumed, thanks
[11:54] <cjwatson> the only difference from a regular installation is that the actual kernel image is removed, because it's also on the ISO9660 filesystem
[11:55] <cjwatson> saves us several megabytes
[11:55] <cjwatson> and the installer is smart enough to copy it from the right place
[11:55] <cjwatson> but other than that it's as normal
[11:55] <apw> thanks
[12:39] <smb> tjaalton, It least that narrows down the pile. Though it probably still is the whole of usb-core to look at
[13:16] <alex_joni> cjwatson: is that also true for 8.04 LiveCDs ?
[13:17] <alex_joni> cjwatson: meaning if I install a custom kernel deb, and I install the kernel and initrd outside the squashfs, can I simply remove the kernel from /boot ?
[13:24] <AceLan> alex_joni: I can't understand what's your problem, could you describe more explicitly?
[13:28] <alex_joni> AceLan: see what cjwatson said above
[13:30] <cjwatson> alex_joni: no, I'm afraid this was added in 8.10
[13:30] <cjwatson> AceLan: I understood :-)
[13:30] <alex_joni> cjwatson: ok, thanks.. something to remember for 10.04 then
[13:31] <cjwatson> (and it went badly wrong when first introduced, resulting in world-writable kernel images, but we fixed that just before release ...)
[13:32] <alex_joni> world-writable (after the copy from the CD to the live system) ?
=== mdomsch is now known as mdomsch_bos
=== cjwatson_ is now known as cjwatson
[15:58] <rtg> soren: do we still need a 32 bit virtual kernel package for Karmic?
[16:34] <Keybuk> apw: Jan replied to the vfs union mount issue
[16:34] <apw> Keybuk, after the 'i'll look later' ?
[16:34] <Keybuk> Arrgh, it is the autofs crap that is killing us (see commit
[16:34] <Keybuk> 051d381259eb57d6074d02a6ba6e90e744f1a29f). They actually replace the nameidata
[16:34] <Keybuk> and therefore the inode operations when they see a symlink which isn't coming
[16:34] <Keybuk> from the filesystem of the parent directory. This is because their root dentry
[16:34] <Keybuk> is actually a symbolic link ...
[16:34] <Keybuk> Thanks for finding this,
[16:34] <Keybuk> Jan
[16:35] <apw> Keybuk, ahh yes
[16:35] <apw> so i guess we might get a fix sometime soon
[16:36] <Keybuk> yes
[16:36] <Keybuk> I didn't know whether the commit id was a fix or the cause
[16:36] <Keybuk> or which tree that was in
[16:36] <Keybuk> etc.
[16:36] <apw> looks to be the cause
[16:37] <apw>     [PATCH] autofs4: nameidata needs to be up to date for follow_link
=== shanix_ is now known as shang
[18:25] <cjwatson> alex_joni: after the copy from the CD to the *installed* system
[18:26] <cjwatson> alex_joni: but don't worry about it, it's fixed now
=== bjf is now known as bjf_lunch
[20:59] <alex_joni> cjwatson: heh, I have tons of confidence that you guys squash these bugs pretty fast
[21:17] <solarion> Can also do more than 2 channels?
[21:17] <solarion> ALSA, rather
[21:18] <solarion> (is what this amd guy is saying: http://blogs.amd.com/home/2009/06/16/turning-it-up-to-11/comment-page-1/#comment-224)
[21:18] <solarion> ah, perhaps I misread; he meant that the current driver only does 2channel audio
=== bjf_lunch is now known as bjf
[21:20] <cjwatson> alex_joni: where in this case "pretty fast" is "massive panic the day before release", yes :-/
[21:24] <alex_joni> cjwatson: don't we all work better under pressure and deadlines :D
[21:24] <alex_joni> errr.. not :D
[21:36] <dtchen> solarion: alsa does not place artificial limits on the number of channels available to software above it in the audio stack
=== dashua__ is now known as dashua