#ubuntu-kernel 2005-10-01 <jbailey> BenC: Not if he's seeing it in colony 5. Have to pnt this bacak to mjg59 <mjg59> Nngh. <mjg59> What? <BenC> 16327 <BenC> it's a problem where e100 NIC is not working after resume <BenC> I thought updated scripts were supposed to handle that properly <fabbione> yo <fabbione> BenC: yeah.. volatile is l-r-m business <zul> morning <zul> meh...i was sick again this weekend.. <zul> sheesh you guys are quiet for once <BenC> *belch* <zul> heh..how is it going ben? <BenC> not too bad <BenC> you? <zul> good...went to a hockey game last night but ok <zul> what are you working on this week so we can coordinate it or something <desrt> jbailey; ping <BenC> working on doing an upload later today <BenC> I am going through some P2 level bugs to clear out my bug queue <jbailey> desrt: pong <jbailey> zul: The weather changes have been a bit insane around here too. <desrt> jbailey; just bugging you about ubug 14456 :) <desrt> i hate to nag, but it's so tempting :) <jbailey> Eh? <jbailey> HTH did you get a kernel feature put in this late? =) <desrt> IN_MASK_ADD <desrt> i have dirt on benc <jbailey> I can only assume. =) <zul> jbailey: its been raining here all day from what i can tell ;) * BenC wont mention the favors desrt did to get that in <fabbione> BenC: ping? <BenC> ? <BenC> fabbione: I did a full kernel package build in 40 minutes on the e3k <fabbione> neat :) <BenC> fabbione: I want to give you initial access to set things up, but be aware that the machine will go down for a few days within the next week while I finish moving <fabbione> BenC: if i could get ssh access to the box, i can setup the buildd <BenC> msg me your pub ssh key <fabbione> BenC: sure, we can wait after the move if you prefer <fabbione> BenC: i did setup another buildd on saturday so we are catching up pretty fast <BenC> that would probably be best <fabbione> sure <fabbione> that works for me <BenC> /dev/mapper/debian-org <BenC> 236G 287M 224G 1% /org <BenC> FYI :) <fabbione> tsk <fabbione> root@trider-g7:~ # vgs <fabbione> VG #PV #LV #SN Attr VSize VFree <fabbione> mofo 1 21 0 wz--n 1.09T 129.62G <fabbione> *grins* <fabbione> ehehe <BenC> mine was free, how much ws yours? :) <doko> BenC: while you are here ... mind fixing gcc-4.1 biarch, so you can test-rebuild the archive with 4.1? ;-P <fabbione> actually.. not thay much ;) <BenC> doko: fix it in what way? <fabbione> approx 8000DKK that would be around 1200USD i think <BenC> not too bad <fabbione> + another 800GB on another box <doko> BenC: that the patches apply again and the biarch-compiler builds <BenC> doko: URL to source? <BenC> I can start a build and get you something tonight <doko> BenC: gcc-snapshot package, enable biarch in debian/rules.defs <fabbione> doko: yeah.. gcc-snapshot farted on me today <BenC> debian or ubuntu archive? <doko> shouldn't matter <fabbione> but it did stall on a test suite for more than 150 minutes <fabbione> and buildd did kill it <fabbione> so it might as well being looping there for nothing <doko> yes, I should update the snapshot package as well <BenC> 20050904? <fabbione> doko: try to get a working gcc-4.0 for dapper my friend because we need to switch the kernel <fabbione> and there are way too many ICE's on sparc <fabbione> BenC: btw #ubuntu-toolchain is available as well as #ubuntu-sparc <doko> BenC: yes <doko> fabbione: what is wrong? <fabbione> doko: are gcc ICE's ok? <BenC> doko: the sparc-biarch patch seems to apply with only a little fuzz <BenC> I'll try a build and see what happens <doko> BenC: yes, I did try to update the patch, but it did fail the build, so obviously my update wasn't correct <doko> fabbione: ICE's are ok as long as you can work around them. preprocessed source would be helpful <fabbione> doko: you got it already :) <fabbione> but i am more worried for the kernel <fabbione> in terms of miscompilation <fabbione> where it builds, but it builds crap <doko> :-/ <fabbione> and the kernel is good and bad as test case <fabbione> given that it builds almost always on gcc-40 <fabbione> but it miscopiles <fabbione> so very difficult problems to hunt down <fabbione> but than.. that's why we have you * fabbione heads to bed <fabbione> good night guys <doko> well, unfortunately the kernel is the only piece of software compiled with -m64 ... <BenC> libc6 <doko> ok, s/built/tested/ <doko> maybe an experimental sparc64 arch wouldn't be bad <BenC> I've done a lot with libc6-sparc64 in the past <BenC> but not recently <BenC> built X against it once <BenC> and ran it :) * BenC warns everyone about the upload of 9.18 <BenC> ../../../src/libiberty/cplus-dem.c:55: error: conflicting types for 'malloc' <BenC> doko: that's the error I see, and that isn't related to sparc at all <fabbione> doko: well i am not talking only about sparc for the kernel.. here is morelikely arch: all <doko> BenC: I hope I can find some time to look at it this week, but that's not the thing I did see in the past <BenC> well, I'm gonna manually fix that and continue the build <doko> fabbione: sure, I wouldn't trust gcc-4.0 too much for the kernel <fabbione> doko: fix it :P <fabbione> anyway i am off for real <fabbione> good night <fabbione> BenC: nice upload.. i will let you know tomorrow if it did build on sparc (if you haven't test it yet) <BenC> it does <BenC> I built it before upload <fabbione> eheheh cool <BenC> doko: I can't even get libiberty to build, so there's some inherent problem <BenC> doko: things like HAVE_SYS_STAT aren't defined <BenC> I wonder if it has something to do with the biarch patches autoconf rerun #ubuntu-kernel 2005-10-02 <FireCat> I'm having poblems with a compile with Breezy on AMD64-SMP. It's complaining that Module.symvers is missing from linux-headers. <crimsun> you've installed linux-headers-$(uname -r) ? <FireCat> Yes <crimsun> hmm <crimsun> I presume you mean you're trying to compile an external kernel module? <FireCat> I also deinstalled them and the kernel, and reapplied them in synaptic <FireCat> crimsun: Yes, the Accelleration module for qemu <crimsun> did you install gcc-3.4-base and gcc-3.4? <FireCat> Yes, even though it recommends gcc-3 I thought I'd give 3.4 a shot since I had already installed it <crimsun> did you override $(CC)? <FireCat> Yes, I symlinked it in /usr/bin/gcc I think it was. <FireCat> If there is a better way to do it than that I'm all ears <crimsun> if the acceleration module uses a Makefile with CC defined, then you need to override it there or as an environment variable prior to compilation of the module <FireCat> Yep, how do you override it with an environment variable, I'd rather not be making symlinks <crimsun> CC=gcc-3.4 make <crimsun> etc. <FireCat> ok, I just noticed something, let me try it again, looks like the path might be wrong <crimsun> -headers should contain that file <crimsun> (it does here) <calc> BenC: wrt #7299 i'll try updating the laptop and see what happens <zul> hey <zul> aie make the email stop!! :) <zul> BenC, i seen bug reports for 10834 as well, i dont have a fix for it yet <crimsun> speaking of which, I'm working on 15031, will provide a dpatch soon * ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | http://www.ubuntulinux.org/wiki/KernelTeam | The kernel is not in, please leave a message after the beep...OOPS, unable to handle kernel paging request | http://davidhull@example.net/ playground: kernel-debian--mainline--2.6.12 <jorgp> anyone else getting unsolved symbols issue with 2.6.12-9 breezy kernel when trying to load madwifi driver? <BenC> what symbols? <BenC> is madwifi linux-restricted-modules? <jorgp> no <BenC> ok, what symbols? <jorgp> I'll have to report it tomorrow I guess, left the laptop at work <jorgp> but the netgear wg511t wireless card does not work in 2.6.12-9 <jorgp> worked fine with 2.6.10 in hoary, upgraded to breezy today <jorgp> sorry wish I could be more help BenC <BenC> no problem <mjg59> madwifi is linux-restricted-modules <mjg59> It's non-free <BenC> that's what I thought <BenC> just file a bug on l-r-m <jorgp> ok * ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | http://www.ubuntulinux.org/wiki/KernelTeam | The kernel is not in, please leave a message after the beep...OOPS, unable to handle kernel paging request | http://davidhull@example.net/ playground: kernel-debian--mainline--2.6.12 (preX,19) <fabbione> BenC: kernel is up :) <crimsun> yep, I just booted into it <fabbione> crimsun: sparc? <crimsun> oh, no. i386. <fabbione> BenC: i saw you did open a .14 branch. it would be nice if you could publish your orig.tar.gz somewhere <BenC> fabbione: I haven't even really started it yet <BenC> fabbione: but I'll get the linux-source-2.6.14 under universe as soon as I do (that's the proper place, right?) <BenC> probably put it on people.u.c before then <fabbione> BenC: eheh ok <fabbione> i suggest to wait dapper before uploading <fabbione> or use people <fabbione> but yeah.. a new kernel would land in universe <BenC> yeah, I guess at first I'll just keep my own repo under people until it can go into dapper <fabbione> so that gives us the freedom to slam it a bit <fabbione> BenC: just one hint.. check the diff.gz of the old kerenl. there is a one liner that cannot go into debian/ <BenC> yeah, I saw that <fabbione> and it is sort of usefull to avoid trashing debian/ dir on cleanup :) <BenC> actually, what is the problem with our .orig.tar.gz having just the tarball in it? <fabbione> it does i think... <BenC> no I mean, unpacking linux-source-2.6.1x would give you linux-source-2.6.x-2.6.x/linux-2.6.x.tar.bz2 <fabbione> ah no <fabbione> i mean i don't really mind that <fabbione> it's just easier to apt-get source and have the code there readable <fabbione> but it's your package :) <BenC> the reason I ask is that once already I accidentally uploaded a kernel with a change in the .diff.gz to the main source <fabbione> so if you want to go that direction i am not going to object <BenC> and twice I almost did (because I check now) <fabbione> BenC: i think we could use a completely different approach <fabbione> if we need to push our kernel to kernel.org <fabbione> we can just kill dpatch to a certain extent <fabbione> and just keep the tree patched <fabbione> that something we need to discuss <BenC> that's one thing I want to discuss at UBAZ <BenC> UBZ <fabbione> otherwise we will have 2 trees to handle <BenC> I need to finish my kernel agenda for UBZ <fabbione> yeah <fabbione> BenC: remember to add all that stuff to the LinuxKernelRoadMap on the wiki <fabbione> because that'd be part of a spec <fabbione> brb <fabbione> ahh coffee :) <fabbione> we can also consider to switch RCS <fabbione> if that's required to push our kernel to kernel.org <fabbione> we need to be careful not to specs too much <fabbione> that was a mistake at UDU <BenC> yeah, git is something I want to discuss <fabbione> yeah <desrt> what's the story with sk98lin? <desrt> should i suspect it of causing crashes? <BenC> it shouldn't <BenC> then again, it isn't well tested <BenC> with ubuntu atleast <desrt> it looks like it's been getting a lot of changes lately <desrt> anyway... i use that driver and i was getting random lockups a kernel rev or two ago <desrt> just looking for something to blame :) <zul> brb <zul> holy lag batman <zul> how is it going everyone? <jbailey_> zul: I'm alive! I'm alert! I FEEL GREAT! <fabbione> yo <jbailey> Heya Favio <jbailey> s/v/b/ <jbailey> mjg59: 9092 seems to not make sense, but since Colin reported it and confirmed it, I probably ought to not close it as UBD <fabbione> :) <jbailey> mjg59: Apparently processor.ko tells it that it should work very hard, very fast, and consqeuently, very hot. <desrt> <jbailey> i'm wide awake, it's morning <mjg59> jbailey: That's very odd <mjg59> jbailey: I'll see if I can take a look at Colin's <jbailey> Thanks. <mjg59> Ah. Except Colin doesn't have one now. * lamont commits a driver panic fix (hppa specific) for -19 <jbailey> lamont: I thought that the hppa patches were pulled from the parisc tree? <jbailey> Aren't we generally up to date with that? <jbailey> Willy said before that he doesn't know git at all, so I suspect nothing new has gone upstream for a bit. <mkrufky> you dont need to know git to send stuff upstream <mkrufky> akpm takes patches <jbailey> mkrufky: No idea. =) <jbailey> mkrufky: I'm just a cute little glibc hacker ;) <lamont> jbailey: the patch was from pacvs <mkrufky> jbailey: oops, sorry i was away ... i was trying to say.... for those that dont use git, but wish to send in patches, andrew morton takes normal patches via email... no need to learn git <mkrufky> jbailey: I was only telling u for the sake of conversation ;-) <jbailey> =) <spayne> it works! <spayne> the ndiswrapper problem is solved! <spayne> yes! <spayne> jbailey: ping <spayne> BenC: ping <jbailey> spayne: pong <jbailey> Eh? <jbailey> What was it/ <spayne> it works! the ndiswrapper problem is solved <spayne> the 2.6.12-9 kernel solved it! * jbailey blinks <jbailey> Really? <spayne> yes! <spayne> you are surprised as i am! <spayne> a fresh install today <spayne> i will do some more testing BEFORE closing the bug? <jbailey> Please. =) <BenC> ? <BenC> yeah, 9.18 should have fixed ndiswrapper on amd64 <spayne> hmm - this is getting weird <spayne> you have try and believe me <spayne> it WORKS when it is plugged into my USB keyboard <spayne> but not directly into my laptop <spayne> it works, gets a DHCPed address <lamont> BenC: pls ping me before you upload a new kernel - trying to fix a bug or 2 <BenC> well, it's compiling correctly now, so any other bugs with ndiswrapper are going to be upstream :) <BenC> lamont: sorry, but I'll be doing another by weeks end <lamont> BenC: no, that's good... I just want to have the chance to say "wait an hour" :) <lamont> assuming I'm that close when you get ready <BenC> so if you can get me patches by Friday, they'll get in <BenC> ok :) <lamont> right <lamont> that's today's and tomorrow's work <spayne> jbailey: i also discovered that there is a RT2500 driver for Ubuntu which is native <spayne> jbailey: i wonder if i should give this a go :) <BenC> spayne: if you have problems with ndiswrapper, would you be able to test v1.2 from upstream? <spayne> yes <spayne> you mean from Debian? <BenC> either way <BenC> I didn't know it was in Debian <spayne> well, there is no 1.2 - they are now onto 1.4rc1 <spayne> and i can't get the tarballs for anything else <dilinger> that's 1.3rc1 <dilinger> that's in debian <spayne> what i am talking about <spayne> install from debain upstream <spayne> or ndiswrapper source? <dilinger> did they actually release 1.3? <dilinger> or did they just skip right to 1.4rc1? <spayne> http://sourceforge.net/projects/ndiswrapper/ <spayne> stable 1.4-rc1 September 27, 2005 <bagpuss_thecat> have there been any changes to the rivafb options in the most recent 2.6.12 k7 kernels? <spayne> BenC: ?? <spayne> BenC: 1.4rc1 is looking A LOT better <spayne> it works! properly, in the laptop, no fuss! <spayne> jbailey: ping <jbailey> spayne: Still here. =) <spayne> jbailey: it seems 1.4rc1 solves it completly, thanks to someone on #ndiswrapper <spayne> i compiled it and added the line to /etc/modules <spayne> even NetworkManager works! <jbailey> Cool! <jbailey> What do you need us to do? <spayne> well <BenC> 1.4rc1? <spayne> yes <BenC> spayne: can you try a release version, like 1.3? <spayne> BenC: it has gone from SF <spayne> Yes, it defiantly works <spayne> 100% A OK <BenC> spayne: send me a link to v1.4rc1 and I'll see what I can do <spayne> BenC: although, I normally run 'make deb' which failed but 'make' worked <BenC> davidhull@example.net <BenC> I'm off for lunch/dinner, but I'll check it out when I get back <spayne> BenC: if you want me to, i will do a complete format with a fresh install and start from scratch <spayne> jbailey: i am doing a fresh install with nothing on <spayne> jbailey: and see if it works with that * jbailey blinks. <jbailey> My mind is in the gutter, obviously. <jbailey> =) <spayne> no, i'd seriously do it for you guys <mkrufky> lol <mkrufky> spayne: read between the lines, and laugh <spayne> mkrufky: as jbailey knows, i've been moaning about this for months <mkrufky> yes, i saw u talk about this before <mkrufky> i usually stay quiet, but sometimes i just cant resist <spayne> jbailey: mmp_l is the guy on #ndiswrapper who got it working <jbailey> mmp_l: \o/ <mmp_l> just helped... <spayne> jbailey: but as he will say, there are some big changes going on which may cause problems <mmp_l> and it was just a gues.. <jbailey> spayne: Keep in mind, that I'm still not the kernel guy. =) All I've done so far is tell you that it's not your initramfs. =) <spayne> :-) <spayne> we'd probally be better waiting until BenC gets back <mmp_l> for more info you should ask at mailing list... . I don't have complete information and haven't beed at #ndiswrapper for quite loing time... <mmp_l> *long <spayne> but basically, mmp_l was saying that there are some rewrites in 1.4 <mmp_l> yes <spayne> which may cause problems <spayne> if it goes into Breezy.... <jbailey> Right, if that's the case, it might be best to just not do it for now. <spayne> mmp_l: do you have any idea from lists when 1.4 might come <jbailey> Since we're about 2 weeks from release. =) <spayne> jbailey: which is the ultimate deadline for this stuff? <jbailey> spayne: About 6 weeks ago. <spayne> jbailey: (cough)kernel upload today(cough) <jbailey> The thing this trips is UpstreamVersionFreeze. <jbailey> You'll notice the kernel is still 2.6.12 =) <mkrufky> i have a suggestion <jbailey> https://wiki.ubuntu.com/BreezyReleaseSchedule <mkrufky> mmp_l: is the fix due to a single patch? <spayne> mkrufky: shoot <jbailey> spayne: Basically the first 3 months of the release cycle is us madly merging stuff, and then 3 months fixing what we broke in the process. <jbailey> =) <mkrufky> i think BenC would be happier to include the single patch against the stable release, as opposed to the rc <mkrufky> but i cannot speak for him <mkrufky> this is just my opinion <spayne> mkrufky: this is where it gets interesting <spayne> mkrufky: look at http://sourceforge.net/mailarchive/forum.php?thread_id=8321710&forum_id=36471 <jbailey> A single patch we can definetly do. =) <mmp_l> spayne: just looked into mailing list: <mmp_l> If no major issues are reported with 1.4-rc1, 1.4 will be released <mmp_l> soon (within few days). <jbailey> Although the last kernel upload is Sched for the 29th. =) <spayne> mkrufky: it looks like a majority has been rewritten for 1.4rc1 <spayne> "There won't be 1.3 release" - this helps a bit <mkrufky> hmm... in that case, you should email BenC the info like he asked <spayne> mkrufky: other stuff like WPA2 looks interesting <mkrufky> but i know it is easier to get a single patch in as opposed to an entire upgrade <spayne> mkrufky: it looks considerably more than a single patch <mkrufky> thats my point exactly <mkrufky> they are in code freeze <mkrufky> they are only trying to fix stuff now <spayne> but are some issues (like mine) with the current version <mkrufky> jbailey: am i correct? <jbailey> mkrufky: Yup <jbailey> mkrufky: And at this point it has to be provably low impact <mkrufky> and THATS why i suggested to isolate the sinle patch that fixes your problem <spayne> jbailey, mkrufky: i have the supcious feeling that 1.1 isn't supported in the 2.6.12 kernel <mkrufky> but it seems that might be difficult <mkrufky> spayne: have you tried vanilla 6585208393 ? <spayne> jbailey, mkrufky: "Support for new kernels added. <spayne> mkruky: i have been at this since 6585208393! <spayne> mkrufky: what you could do is provide a deb will the latest 1.4 in IF it is needed <mmp_l> spayne: I'm going to send an email asking for where could one get version 1.2 ... <spayne> mkrufky: i just have the feeling once the majority start shifting to breezy, problems like mine will/may arise and there is nothing we can do <spayne> mmp_l: 1.2 does not work <spayne> mmp_l: i have test it in the past <spayne> mmp_l: nor did 1.3rc1 - 1.4rc1 is the FIRST released to solve this bug <mkrufky> spayne: i'm not the guy to convince... i do v4l/dvb stuff <spayne> :-) <mkrufky> also, ndiswrapper doesnt live inside the kernel <mkrufky> so, IMHO <mkrufky> i agree with your idea about putting the .deb in the repos <mkrufky> even still, i dont have that power <spayne> something like ndiswrapper-1.4.deb <mkrufky> i think that if you can wait, 1.4 final will be released soon enough <spayne> the standard ndiswrapper-utils could stay where whereas ndiswrpper-1.4 could install the deb and the module <mkrufky> and they shouldnt have any problem adopting it <spayne> mkrufky: but the last kernel upload is the 29th <jbailey> Assuming Ben chooses to do another one. I don't know his plans. <mkrufky> jbailey: you guys package ndiswrapper with your kernel??? <spayne> giri - the main developer has just come online <jbailey> mkrufky: I think so, yeah. <mkrufky> interesting.... but im sure it's being compiled as a module <mkrufky> most of the distros have ndiswrapper in a separate package, if at all <spayne> SUSE has a single package <spayne> Fedora has a module and a utils one * dilinger would still like to know wtf happened to ndiswrapper-1.4 <mkrufky> u mean 1.3 <dilinger> er, yea, 1.3 <mkrufky> maybe they got bored and wanted to make people wonder <jbailey> Maybe it got NEtscape 5'd? =) <mkrufky> i do that sometimes with my version #'s davidhull@example.net... people get excited when the version numbers skip, lol <mkrufky> hahaha netscape 5'd !!! <dilinger> i hope it's not one of those "we're not releasing stable releases anymore, so they're all gonna be RCs" type of thing <jbailey> dilinger: Feh. It's clearly worked well for glibc. =) <jbailey> *sigh* <dilinger> jbailey: exactly what i was thinking :/ <mmp_l> spayne: going off; good night; 2all: good luck with next release:-) <spayne> giri is helping me mmp_l <mmp_l> spayne: I know and hope you'll find the solution of problem... <lamont> BenC: btw, there appear to be new questions in -9.19... <spayne> mkrufky: the ndiswrapper dev. person says that 1.4rc1 shouldn't be included as it is only out today and has no testing <spayne> mkrufky: so i'm grabbing 1.2 from CVS <spayne> it is tagged <spayne> so, i will grab 1.2 and see if that solves the problem * spayne wonders when BenC will be back <lamont> BenC: 133a134 <lamont> > CONFIG_ACPI_DEV=m <mkrufky> spayne: sorry, i was away <mkrufky> spayne: i thought you said you've already tried 1.2 and it didnt work <spayne> mkrufky: the plot deepens <lamont> BenC: but then, I plan to completely overhaul said options <spayne> mkrufky: right - the whole USB layer was rewritten between 1.2 and 1.4 which has greatly improved stability and compatibility <spayne> mkrufky: which means the whole thing works a lot better with the 2.6.12 kernel <spayne> mkrufky: BUT it was only released today so i think the best solution <mkrufky> ...is to wait * mkrufky is sorry <spayne> mkrufky: is to make a new 'ndiswrapper1.4' universe package which may be able to be updated to final <spayne> mkrufky: at least things gives the option of having a working system <mkrufky> i wouldnt be against that <mkrufky> but, once again, i remind you that i have NO power herte <mkrufky> s/herte/here * spayne can wait another 40 min for BenC before he will be so tired me can't get up tomorrow <spayne> it is 11:01pm here in the UK <mkrufky> lol <mkrufky> spayne: did you email BenC like he asked <mkrufky> i think you should do that... he'll get back to u <spayne> sent him two - the origianl with the link and second telling him what i told you <spayne> but i'll wait anyway <mkrufky> so, dont worry about it <spayne> worry! i have been waiting months for this. every single day having to faff on with my adaptor. when i'm this close, i won't give up :) <mkrufky> if you haven't noticed.... it doesnt matter how stable they say ubuntu is... there are always bugs to be fixed, and there are always new packages up on the repositories #ubuntu-kernel 2005-10-03 <mkrufky> so, deadline or no deadline........ * spayne is training to become a MOTU as well! <mkrufky> MOTU ? <spayne> Universe Packager? <mkrufky> oh <crimsun> universe/multiverse maintainers <crimsun> see #ubuntu-motu <mkrufky> i'm what they call an "upstream guy" <crimsun> you're more than welcome to join, mkrufky <mkrufky> hmmm <mkrufky> until that last comment i was GOING to say, "heh.. i just like to write code.... i'll leave the packaging to you guys" .... but since u put it this way <mkrufky> maybe i might just have to investigate ;-) <mkrufky> crimsun: i dont think we've met yet, btw <crimsun> well the ideal situation is of course if the coder packages it, since (s)he can deal directly with bug reports ;-) <mkrufky> i am a maintainer of upstream v4l & dvb kernel subsystems <mkrufky> im not *THE* maintainer... just one of the few <crimsun> mkrufky, excellent. Pleased to meet you. I help out with ALSA in Ubuntu. <mkrufky> great <mkrufky> i told them i would help to backport newer code to their next kernel.... <mkrufky> but i dont think this involves any packaging <crimsun> probably not, I think lamont and benc will handle that <mkrufky> but there's always new stuff to learn, and im always interested <mkrufky> anyway, its about that time to go home now... nice to meet u crimsun and spayne .... <mkrufky> tty guys later... good luck <spayne> keep in touch :) <crimsun> thanks, cya 'round <mkrufky> :-)... i can always be found in both #v4l and #linuxtv ... (and usually here as well) <mkrufky> ttyl <spayne> BenC: ping me if you are back :) <lamont> mjg59: care to take a guess as to which acpi patch breaks ia64? <lamont> as in. most invasive patch, etc. <lamont> jbailey: any reason not to throw out initramfs for ia64 as well as hppa? <spayne> BenC: ? <jbailey> Throw out, like not use? <jbailey> The biggest reason is that those machines are then stuck with 2.6.12 until you get it working. <jbailey> So you're only buying yourself 2 weeks or so. <BenC> spayne? <BenC> anyone know why isapnp would be reserving memory that was reserved for a PCI device? <BenC> user has an 8139 that has 0xde00-0xdeff reserveed for I/O, and isapnp grabs 0xde00-0xde03 on bootup <BenC> if they boot with noisapnp, the device works ok <BenC> otherwise, it complains about not being able to reserve the io region <mkrufky> this may or may not help: <mkrufky> recently, on lkml, there was talk about pci memory allocation to the wrong memory area.... <mkrufky> something to do with overwriting memory thats SUPPOSED to be reserved for the bios <mkrufky> i believe the talk was before 2.6.13 got rreleased, so i dont know if its related or not <mkrufky> but i remember that it was GregKH that was talking about it.... you may want to search lkml <mkrufky> i know that isnt the exact situation that you're describing, but it COULD be related <jbailey> mjg59: Around? <BenC> mkrufky: well the same memory area is listed for 2.6.10 (where it's working) and 2.6.12 (where pnp grabs part of it) <BenC> the only difference is that in 2.6.12, isapnp beats 8139 to reserving the memory, even though /proc/ioports clearly knows that the memory region is for the PCI device <BenC> and lspci -v shows it too <mkrufky> hmm <BenC> 16371 if you want to look at it <BenC> I think isapnp is just broken in this case, unless the guys bios is setup wrong <mkrufky> i'll take a look... but i think this means that the bug *i* was talking about is probabl;y unrelated <mkrufky> ...sorry <BenC> yeah, sounds like it <BenC> no problem <mkrufky> hmm... he didnt include dmesg without noisapnp <mkrufky> oops... i see it <BenC> doesn't seem that isapnp was disabled like i thought it would be <BenC> 2.6.10 dmesg shows isapnp just not doing anything since there are no pnp devices <BenC> just the parallel port <BenC> at 0x378, like it should be <mkrufky> ya <mkrufky> hmmm... what a mess <BenC> maybe I need to disable pnpacpi <mkrufky> that could be something to try <mkrufky> hmmm.... it's not really clear what is going on in the inline dmesg output... i assumed that was 2.6.12 without the noisapnp <mkrufky> and then you said, "doesn't seem that isapnp was disabled like i thought it would be" <mkrufky> i assume that you're referring to: <mkrufky> [4294670.791000] isapnp: Scanning for PnP cards... <mkrufky> [4294671.145000] isapnp: No Plug & Play device found <BenC> that's 2.6.10 <mkrufky> ah <mkrufky> so does he show us 2.6.12 nywhere? <BenC> there's a 2.6.12 inline, original, and a 2.6.12 with isapnp (attachment) <BenC> ... <mkrufky> looks like he is only showing 2.6.12 with noisapnp <BenC> "dmesg output whit noisapnp" <BenC> that's all we need <BenC> 2.6.10 works <BenC> 2.6.12 with noisapnp I meant <BenC> just asked him to try some other options <mkrufky> ok <fabbione> morning guys <spayne> mornin' all <spayne> BenC: ping <fabbione> spayne: BenC is asleep at this time <spayne> fabbione: where abouts is he? <fabbione> US <fabbione> so i guess he will be around in 6 hours + o - <spayne> fabbione: thanks <spayne> fabbione: i'm just darn excitied to get this bug squashed <spayne> :) <infinity> spayne : Which bug is that? <spayne> the ndiswrapper one <infinity> Oh, dang. I was hoping it would somehow relate to USB being goofy. <spayne> right, well <spayne> the newest version released yesterday (1.4rc1) fixes the bug as the whole USB layer has been rewrittrn to work better with the 2.6.12 kernel as well as fixing hundreds of bugs since 1.2 <spayne> 1.3 was never released <spayne> so... <spayne> the solutions arer <spayne> a.) Do Nothing - Will cause problems when Breezy released as many others way have this sort of problem which is fixed in 1.4rc1 <spayne> b.) Wait until 1.4 is released - This could be a week or just a few days <spayne> c.) Put it into the Kernel - not a good idea as it has had little testing and bugs will/may be found <spayne> d.) Make a Seperate Universe Packaging for 1.4 - This seems a good comprimise as this could be updated before Breezy is released with 1.4 final and means those who need it can use it <spayne> infinity: what do you think? <infinity> Hrm. How would the seperate universe package work?... dpkg-divert the USB modules from the kernel? <infinity> Icky, but I guess it's not technically difficult. <spayne> a single package which will install both the modules and the utils <infinity> Right, but we also have USB module in the kernel package, so you'd need to divert those elsewhere. <Mithrandir> that'll be fun <spayne> well, what are your suggestions? <spayne> infinity: what would you do? <Mithrandir> diverting the modules will work, it's just ugly. <spayne> brb <infinity> Hey, if diverting modules works for lrm-nvidia-legacy (it diverts modules from lrm), it can work for this, too. :) <spayne> i wouldn't know where to begin <spayne> i'm JUST learning how to package from Debian :-) <spayne> s/Debian/Ubuntu <infinity> I do have an interest in having the USB stuff not be buggered, but perhaps the better answer is to get it in the kernel proper and get VERY widespread testing in the next week. <infinity> On my machine, USB seems to magically take out my PCI NIC, which is pretty cool. <spayne> infinity: shall we see what BenC says? (or do you have the power? <infinity> It'll be up to BenC as a first line approval, and mdz to swat it down after that. <infinity> Both of whom ar ein the US, so wait for them to wake up and get to work. :) <spayne> i got a day off school :) Speech Day this evening :) <infinity> This close to a release, we're obviously rather cautious, but this is a pretty nasty regression for some. <spayne> i know <infinity> I just wish I'd noticed it earlier. I hadn't booted or upgraded that machine for a couple of months, so I have no idea when the bugs started hitting it. <spayne> sigh - it is very difficult <spayne> but 1.4rc1 was only released yesterday which solved these bugs <spayne> look at http://sourceforge.net/mailarchive/forum.php?thread_id=8321710&forum_id=36471 <infinity> Oh, wait, you were just talking about ndiswrapper-usb, not the general kernel USB layer. <infinity> That may not be my bug anyway, then. :) <spayne> yes <infinity> Since ndiswrapper shouldn't even be loaded on my system. <spayne> lol * spayne thought he had a mutal friend <infinity> Including an updated ndiswrapper would be much less scary than an updated USB layer. <spayne> oh yeh <spayne> just i think this is importnat - the Laptop Testing Scheme <spayne> so laptops should work better <spayne> USB works fine for me :) <spayne> for everything else <spayne> just moving to my workstation <spayne> brb <spayne> back <spayne> infinity: all we can done is wait <spayne> back <spayne|> ping anyone <BenC> hey spayne <fabbione> hey BenC <spayne> BenC: at alst! been waiting all morning :-) <fabbione> pitti said to wait with that security patch <fabbione> BenC: linus rejected it <spayne> BenC: did you get my emails? <spayne> BenC: i spent around two hours talking with the main ndiswrapper about this problem <spayne> BenC: what do you think? <fabbione> BenC: sparc is fully installable now <fabbione> (at least ubuntu-desktop is) <fabbione> BenC: are you aware of any problem runnign discover on it? <fabbione> it seems that it can't find PCI video cards... <fabbione> (discover1) <spayne> ubuntu works on sparc? <fabbione> yes <fabbione> as of today <fabbione> but it's not a supported architecture <spayne> will this be another archiecture <spayne> oh right <fabbione> it's there.. but it won't be supported <spayne> this isn't going to be another debian> <BenC> fabbione: only thing to make sure of is that ubuntu discover or upstream discover has the sbus patches <\sh> http://bugzilla.ubuntu.com/show_bug.cgi?id=16539 <- if somebody can confirm this...it's really strange <BenC> fabbione: right now the installer doesn't autodetect the network driver and scsi driver on my e3k <BenC> spayne: I think updated ndiswrapper will have to wait <fabbione> BenC: ok <spayne> BenC: not even an extra package idea? <fabbione> \sh: buy better hw <\sh> fabbione: har har ;) that's ogra not me <\sh> fabbione: the sony is new :) <\sh> fabbione: and it's not mine actually :( <BenC> spayne: well, I don't have time for the extra package, so someone else would have to do it <spayne> BenC: what about if i write a Wiki doc (i am joining the Wiki team) on this problem and how to install ndiswrapper 1.4rc1 <spayne> BenC: and something in the release notes? <BenC> spayne: an errata would be called for, yes <BenC> probably talk to mdz about it <spayne> will do <spayne> you mean an update once breezy is released? <BenC> hopefully <fabbione> sorry BenC .. you said that discover1 in Debian fixes the sparc problems_? <BenC> want the release to be solid and tested, and we can try to get some testing on ndsiwrapper v1.4 afterwards and backport it to breezy's kernel <BenC> fabbione: yes, I know it works <fabbione> ok thanks <BenC> don't know if upstream got the patches <fabbione> i have pci devices so i can check <fabbione> here it detects nothing <BenC> odd, it used to detect PCI on my blade 100 <fabbione> the one from debian works <fabbione> the one on ubuntu segfaults badly <fabbione> the point is to figure how intrusive the changes are <fabbione> our version is very old <fabbione> otherwise we need to think something really hoorible to get it into the archive <fabbione> hell everything is working <fabbione> we can't crap out on one package <BenC> it wouldn't be so bad if the installer would add the modules I manually selected to /etc/initramfs/modules <BenC> atleast the storage module <\sh> BenC: hmmm....#16539 <- AltGR is also not working on the console...so which is the right package? <BenC> \sh: console keyboard mappings are handled by the kernel, but it's a userspacr tool that loads the keymap based on what keyboard you selected during install <BenC> which I _think_ is console-tools <infinity> console-tools and console-data, yes. <infinity> (tools does the work, data has the keymaps) <BenC> then it's probably -data that has the bug, but I'll let the maintainer take care of that <\sh> BenC: funny thing about it, that it's working on my horrible broken breezy install...but not on a new warty->hoary->breezy upgrade...I'll do a new install of breezy tonight on my other laptop so if this is issue reoccur then I can confirm this issue for sure... <BenC> \sh: sounds like an upgrade issue with console-data <BenC> \sh: you should add that to the bug report, it would be very helpful in pinpointing it <infinity> \sh : Can you fix it with dpkg-reconfigure console-data? <infinity> (Note that after reconfiguring it, you may have to reboot, as the kernel is sometimes a bit anal about hanging onto a loaded keymap) <\sh> infinity: I don't have the sony here anymore (colleague went home...tomorrow I can check it) and this evening with the new install..yes.. <infinity> Yes, reconfiguring it works? <infinity> Or, "yes, this yes doesn't belong at the end of my sentence, I just put it there for dramatic effect"? <\sh> infinity: that I can test it this evening -> yes , right now I don't have the possibility.. <\sh> infinity: that the point...dramatic effect ,-) <infinity> Alright. If you can get the output of "debconf-show console-data" on a broken system, then try to dpkg-reconfigure it, and if that fixes your issue, the debconf-show afterward too? <\sh> infinity: will do <infinity> (Attach both to the bug) <\sh> BenC: I just did a new install...this strange keyboard behaviour doesn't appear for me...(todays iso) <\sh> BenC: so something else must be wrong...upgrade issues? <fabbione> an upgrade issue doesn't affect the kernel <fabbione> the kernel image is the same either via installing or upgrading <\sh> fabbione: yes I know...so could it be the console-*? during upgrade? <\sh> hmmm....w8 <\sh> I'm using uk layout on my laptop...lets check after dinner how it behaves with german keyboard layout ;) <fabbione> yes.. console-data relies on config files <fabbione> something the kernel doesn't for the keyboard <\sh> sounds like I have to reinstall the sony tomorrow <\sh> or take it with home over the weekend...to check properly what's wrong... <lamont> SCORE! <lamont> if I start with our kernel, and debian's 2.6.12 config, and hit return to every question, it appears to boot. Now to find the evil option <jbailey> lamont: Still initrd or with initramfs too? <lamont> initrd <lamont> jbailey: first we get a booting kernel, then we worry about initramfs <lamont> since I have a trivial workaround for the latter, and no workaround for the former <jbailey> No prob, I'm just tracking what's going on. =) <fabbione> BenC, jbailey: ping? <jbailey> fabbione: 'sup? <fabbione> meh <fabbione> hey BenC <fabbione> BenC: can you please test on the fly the discover1 pkg and lib from http://people.ubuntu.com/~fabbione/ <fabbione> it has the sparc bug fixes <fabbione> it works for me <fabbione> but i need you to check with multiple sbus thing <fabbione> BenC: please? <fabbione> can you test it <BenC> hold a sec <fabbione> sure <fabbione> if you can test <fabbione> discover all <fabbione> with both the old and the new <fabbione> you should be able to see the difference <lamont> btw, CONFIG_ACPI_TC1100 is going to need to be added in more than just i386/amd64 configs.... <lamont> and I assume it wants to be a module everywhere <lamont> any reason I shouldn't make it =m on hppa/ia64/sparc/ppc? <fabbione> sparc doesn't have ACPI? <fabbione> like ppc... <lamont> ah, that could do it... <lamont> ia64 does though, but I'm overhauling that config atm <fabbione> :) <lamont> # unless you want to implement ACPI on PA-RISC ... ;-) <lamont> config PM <lamont> bool * lamont giggles <BenC> fabbione: waiting for the e3k to boot <fabbione> BenC: no rush <fabbione> i am pretty sure the fix is right <fabbione> but i want to be triple sure since discover1 is main <fabbione> so one upload > two uploads <BenC> wow, minicom reports it was compiled on my birthday <BenC> I feel special :) <fabbione> ahahah <BenC> ok, the new one sees my happy meal <BenC> but neither listed my esp scsi <fabbione> that's weird <fabbione> because i have SBUS stuff here <fabbione> and the new one can see them <fabbione> the SBUS code is identical to debian <BenC> it sees my scsi drive <BenC> but esp is already loaded <fabbione> BenC: can you check using the debian one from sid <BenC> --module only shows sunhme <fabbione> and see if it can actually see the esp? <BenC> yeah <fabbione> i am curious.. becuae they might as weel force esp to load <BenC> 1.7.13 doesn't, and it sees my sunhme <BenC> 1.7.7 from debian doesn't see either one <fabbione> so the output from 1.7.13 is the same as mine... <fabbione> right? <BenC> yes <fabbione> perfect <BenC> esp is listed in the discover db <fabbione> in both of them? <fabbione> i mean both debian and mine. <fabbione> i wonder if that could be a problem solved by discover1-data * fabbione uploads discover1 in the meantime <fabbione> # wrapper for discover command that can distinguish Discover 1.x and 2.x <fabbione> discover_hw () { <fabbione> 1) <fabbione> case "$SUBARCH" in <fabbione> sparc/*) sbus=",sbus" ;; <fabbione> the hack is in hw-detect <fabbione> (in the installer <fabbione> i will need to talk with Kamion about it <fabbione> anyway i am off for a sleep <fabbione> thanks Ben #ubuntu-kernel 2005-10-04 <BenC> how do you disable dma for ide on the kernel command line? * netjoined: irc.freenode.net -> zelazny.freenode.net <lamont> [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held <lamont> [drm:drm_unlock] *ERROR* Process 5356 using kernel context 0 <lamont> top-of-branch * lamont needs to figure out the best/simplest way to have hppa&ia64 use mkinitrd instead of mkinitramfs for 2.6.12 <lamont> that is, so that virgin installs do the right thing (and boot) <lamont> because not booting is, well,m bad * lamont scratches his head <lamont> hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01) <lamont> kew;l * lamont-away finally gets home <fabbione> ehhe <kikov> sorry by this stupid question: how is the official package name for kernel in Ubuntu? <kikov> kernel-image or linux-image? <kikov> well, kernel or linux? <kikov> or both? <kikov> which are the differences? <mjg59> kikov: linux-image <kikov> ok.. and why kernel-patch-vserver depends on kernel-sources? ( instead linux-sources ) <kikov> well.. not depend, suggest: Suggests: util-vserver, kernel-source-2.4.27 | kernel-source-2.6.8 | kernel-source-2.6.11 <mjg59> Because it's been imported from Debian without modification <kikov> ok.. thx <kikov> I'm going to play a little bit with it <kikov> if everything is OK with 2.6.12, we could add Suggests: linux-source-2.6.12 to suggestions <fabbione> BenC: ping? <kikov> umm, the diff file should be included <kikov> mjg59, and another question.. how can I know the version of the linux-sources? <kikov> well.. 2.6.12 is good, but I still need the other microversion <kikov> 6585208393 and so... <fabbione> .6 <fabbione> check the changelo <fabbione> +g <zul> bleah <fabbione> hey zul <zul> hey fabbione <fabbione> what's up? <zul> bleha...work <zul> is dapper sources published somewhere? <fabbione> nope <fabbione> there is no dapper yet :) <zul> okie dokie <fabbione> BenC: unping.. <zul> have i been missing alot? <fabbione> zul: the end of the world? <BenC> anyone know who davidhull@example.net is? <zul> jdthood <fabbione> BenC: yeah.. alsa guy <zul> he is on -devel <zul> er #ubuntu-devel <fabbione> BenC: i got the fixes for hw-detection ready for upload.. waiting approval <fabbione> BenC: also.. fixed console-data <BenC> cool <fabbione> BenC: and got davem to install Ubuntu sparc :) <BenC> sweet :) <fabbione> BenC: time to start building a community <BenC> yeah, I've told him I moved to ubuntu, and that we will do it right :) <fabbione> #ubuntu-sparc is open for business :) <fabbione> BenC: yeah.. he thought that you did all of it :) <fabbione> but yes.. we have a playground area <BenC> I couldn't do sparc right with Debian simply because no one believed the technical arguments dave and I were pushing <fabbione> and given we are 3 sane people <BenC> lol <fabbione> so yes. we can do whatever we want (or almost <fabbione> I need to talk with Mark to get the buildd's in place <BenC> so sparc will actually be "stable" with breezy, just not supported, right? <BenC> you did a kick ass job getting all that done, btw <BenC> I remember how much work that was when I took over debian-sparc <BenC> not fun at all <fabbione> BenC: yes.. we should be able to release together with Breezy <fabbione> stable, but not supported <fabbione> hoary didn't make it for a package <BenC> IBM R30 laptops seem to have the most trouble right now <BenC> maybe I need to get one <fabbione> BenC: eheh why buying crappy hw? <fabbione> i will probable buy a powerbook before UBZ <fabbione> my laptop is falling apart <fabbione> (hw-detect fixes uploaded) <fabbione> BenC: tomorrow it will be a very good day to test the installer <fabbione> i don't remember if hw-detect is downloaded or part of d-i <fabbione> in the latter case we need to wait a d-i upload <fabbione> BenC: http://people.ubuntu.com/~fabbione/sparc.diff <- this should fit all possible SBUS crack <zul> is there a bootable cd-rom yet? <fabbione> zul: yes <fabbione> http://cdimage.ubuntu.com/ports/daily/current/ <- <fabbione> but it doesn't contain all the fixes from today <zul> wohoo...a reason to use my sparc again <fabbione> that are sort of important <fabbione> zul: what sparc do you have? <zul> ultra 5 i think <fabbione> ok.. <fabbione> it should be fine <fabbione> jbailey has one iirc <fabbione> zul: if you could sacrifice your sparc as test install machine, that would be really rad <fabbione> anyway.. time to go to school <fabbione> later fellas <zul> fabbione: sure.. <zul> it ran gentoo on it so yeah it should be ok <BenC> fabbione: ping? <jbailey> fabbione: I have a U5, yes. * jbailey misses his old U10. <jbailey> It was so lovely and special. <jbailey> Hard to find cheap *quiet* Sun hardware, though. <BenC> never heard of quiet sun hardware <BenC> the U5 wasn't too bad, but everything else I've used was hot and loud <zul> mine has sucky hard drive and ram * lamont-away prepares to upload a new kernel-package, which the -9.19 kernel will depend on.... <lamont-away> my SS20 isn't all that loud,.. :0) <jbailey> lamont-away: Nor are the little sunblades. =) <jbailey> I tried to acquire one of those from my previous employer, and couldn't get away with it. <jbailey> And then the U10 I was supposed to get died. <lamont-away> :-( <jbailey> I have a U5 here, it does the job (enough that I can do the glibc builds and stuff) <mkrufky> jbailey: question... are you only responsible for glibc stuff, or is it other userspace stuff too? <jbailey> I am responsible for some other userpsace stuff. <jbailey> In Ubuntu we don't have a Big Maintainer Lock on packages. <mkrufky> ok... i thought of another issue that may or may not come up: <jbailey> We all update what we need to. <mkrufky> oh, i see <jbailey> Some people are just more skilled at things so tend to get the bugs to fix. <mkrufky> ah that makes a lot of sense <mkrufky> what estimated percentage of ubuntu userbase would you guess to be americans? <jbailey> We have no way of knowing. <jbailey> The US is a hard market to crack. <mkrufky> yes this can be true <mkrufky> actually, i heard of ubuntu b/c i got a cd in the mail <mkrufky> i dont know how i got it <mkrufky> but i got 4 <mkrufky> and i gave 3 of them out to co-workers, now we all use it <mkrufky> so your promotions team is doing SOMETHING right :-) <mkrufky> anyway, the reason why i ask: <jbailey> *lol* <mkrufky> there is a package... i'm sure ubuntu has it, but i didnt look yet, called dvb-apps <mkrufky> this package contains userspace apps for testing dvb cards <mkrufky> but it only has programs that work with DVB standard <mkrufky> but, us silly americans had to be different <jbailey> dvb-utils - Viewer programs for DVB cards <mkrufky> and, just like how we dont use the metric system, America doesnt use DVB standard either... instead we have a stanbdard called ATSC <mkrufky> yes <jbailey> Isn't it NTSC? <jbailey> No, that's instead of PAL. <mkrufky> NTSC is for analog video <mkrufky> instead of PAL, correct <mkrufky> and we have ATSC for digital, instead of DVB <mkrufky> however, DVB linux project covers all standards <mkrufky> but the userspace apps currently dont have ATSC support <mkrufky> it is, however, in cvs <mkrufky> dvb-apps cvs, on linuxtv.org <mkrufky> i spoke to the guy responsible
{'channel': 'ubuntu-kernel', 'month': 10}